type
Post
status
Published
date
Oct 12, 2025
slug
network3
summary
tags
技术探索
category
icon
password
引言作为一名后端或前端开发者，我们每天都在和 HTTP 打交道。但真正重要的是什么？是你在排查线上 Bug 时的网络体感，是你对底层 RPC 框架网络原理的理解，以及你对协议设计中“性能与安全”取舍的深度思考。
一、 HTTP 状态码：别光背数字，聊聊“排障体感”
在真实的线上业务中，看到这些状态码你的第一反应是什么：
1. 200 (OK)：一切静好
最常见的成功状态码，表示请求已被正常处理，没啥好说的。
2. 301 与 302：重定向的深渊
- 301 (Moved Permanently)：永久重定向。 告诉浏览器“这家店彻底搬了，以后直接去新地址”。浏览器会缓存这个跳转记录，对 SEO 极为友好。
- 302 (Found)：临时重定向。 告诉浏览器“我们家正在装修，临时在隔壁营业”。通常用于未登录用户的页面拦截跳转等场景，不建议乱用，否则容易引发重定向循环。
3. 4xx 客户端错误：前端的四大金刚
- 400 (Bad Request)： 俗称“前端背锅码”。通常是参数格式校验失败、JSON 解析报错，后端根本无法理解你的请求。
- 401 (Unauthorized)： 没带门票。比如 Token 过期或未携带身份认证信息。
- 403 (Forbidden)： 有门票但级别不够。身份验证通过了，但当前账号没有权限操作该核心业务（比如普通用户试图调用管理员接口）。
- 404 (Not Found)： 路径写错，或者对应的资源确实被删除了。
4. 5xx 服务端错误：后端与运维的噩梦
- 500 (Internal Server Error)： 纯纯的后端代码 Panic（比如 Go 里的未捕获 panic）或者抛出了严重的异常，赶紧去看服务端日志。
- 502 (Bad Gateway)： 网关错误。通常发生在 Nginx 等反向代理层，说明 Nginx 活得好好的，但它转发给下游微服务时，下游服务挂了或者无响应。
二、 GET 与 POST 的区别：跳出“切图仔”思维
如果被问到这个区别，千万别只回答“GET 参数在 URL 上，POST 在 Body 里”，这是最底层的表象。在传输层的 TCP 协议看来，它们根本没有任何区别。我们需要从 RESTful 语义、安全性、幂等性 来进行降维打击：
对比维度 | GET 请求 | POST 请求 | 💡 核心话术总结 |
语义动作 | 获取资源（Read） | 提交/创建资源（Write） | GET 侧重于“索取”，POST 侧重于“改变”。 |
幂等性 | 幂等 | 非幂等 | GET 执行一次和一万次，对服务器资源的影响是一样的；POST 每次都会创建或修改新数据。 |
安全性 | 安全（指不修改数据） | 不安全 | GET 不改变服务器状态，可被浏览器安全地缓存、加入书签；POST 通常不能被缓存。 |
传参限制 | URL 长度通常受限 | Body 理论无限制 | URL 长度受限于浏览器和服务器配置（通常 2K~8K），而 Body 可传大文件。 |
三、 HTTPS 加密原理：混合加密的艺术
“既然非对称加密极其安全，为什么不直接全用非对称加密？”
答案就在于性能。HTTPS 的核心思想是兼顾绝对的安全与极致的性能，它巧妙地结合了对称加密与非对称加密。
四、 HTTP 版本演进：围绕“性能痛点”做减法
网络协议的演进，其实就是一部与网络 I/O 瓶颈作斗争的血泪史。看重你对底层协议演进的了解，其实是在考察你构建高并发系统时的前瞻性。
1. HTTP/1.0 -> 1.1：解决“连接建立成本”
- 痛点： 1.0 版本每次发请求都要重新进行 TCP 三次握手和四次挥手，网络成本极高。
- 进化方案： 1.1 默认开启了
Keep-Alive长连接，允许在一个 TCP 连接上发送多个 HTTP 请求，大幅降低了延迟。
2. HTTP/1.1 -> 2.0：解决“HTTP 队头阻塞”
- 痛点： 1.1 虽然是长连接，但请求必须串行响应，前面的大文件卡住，后面的请求全得排队（HTTP 层的队头阻塞）。且 Header 是纯文本，冗余极大。
- 进化方案： 2.0 引入了二进制分帧和多路复用。同一个 TCP 连接里，多个请求和响应可以交错并行发送，互不干扰，配合 HPACK 头部压缩。
- (思考延伸)：比如现代的高性能 RPC 框架（像你可能平时参与开源贡献比较熟悉的基于 Dubbo 生态的 Dubbo Triple 协议，或者是 gRPC），其底层之所以能支撑极高的并发吞吐量，正是重度依赖了 HTTP/2 的多路复用与流式传输特性。
3. HTTP/2.0 -> 3.0：解决“TCP 基因级缺陷”
- 痛点： 2.0 虽然解决了 HTTP 层的阻塞，但底层由于依然是 TCP，一旦发生严重的物理网络丢包，TCP 的重传机制会导致整个连接上的所有多路复用请求全部卡死挂起（TCP 层的队头阻塞）。
- 进化方案： 3.0 进行了大换血，直接把底层可靠的 TCP 换成了不可靠的 UDP，并在 UDP 之上构建了全新的 QUIC 协议。QUIC 在应用层自己实现了可靠传输、内置加密（0-RTT 握手），彻底消灭了队头阻塞，还支持网络切换（如 Wi-Fi 切 5G）时的平滑连接迁移。
分享