HTTP — 无状态协议与连接复用

一句话总结

HTTP 是每个请求对应一个响应的无状态协议，其性能演进史就是如何在此基础上节省 TCP 连接的历史。

为什么需要它

HTTP/1.0 每个请求都新建并关闭 TCP 连接。加载含 30 张图片的页面就要建立 30 次连接。每条连接至少增加一次往返，使用 TLS 时还要两三次，延迟会直接影响用户体验。

工作原理

HTTP/1.1 的 keep-alive 在响应后保持连接并供下一请求复用，大幅减少往返，但同一连接的响应必须按请求顺序返回。前面的请求慢，后面的就等待，形成应用层队头阻塞。浏览器以每域名约 6 条连接规避，甚至催生把资源分散到多个域名的技巧。

HTTP/2 在一条连接内以流多路复用请求，并压缩首部，解决了应用层排队。但它仍使用一条 TCP 连接，丢失一个数据包会让后续所有流一起停止。 传输层排队仍然存在。

HTTP/3 转移到 QUIC（基于 UDP）之上，实现流之间独立交付；一个流的丢包不会阻塞其他流。

方法语义也是协议的一部分。GET 安全（无副作用）且幂等；PUT、DELETE 不安全但幂等；POST 两者都不是。幂等性直接决定能否重试。 超时时无法知道请求是否到达服务器，贸然重试非幂等请求可能生成两笔订单，所以支付 API 要求幂等键。

状态码也不能混为一谈。4xx 表示请求需修正；5xx 表示服务器问题，可能值得重试。尤其 502、503、504 原因不同：502 是网关从后端收到无效响应，503 是服务表示无法承载，504 是网关等待后端超时。日志不区分三者就会排查错误位置。

实际工作中的表现

连接池配置是常见事故点。客户端想以 keep-alive 复用连接，而服务器或中间负载均衡器的空闲超时更短时，就可能恰好向服务器刚关闭的连接发送请求。症状是间歇性连接重置，与负载无关地按固定比例出现。标准做法是把客户端空闲超时设得比服务器短。

后续测验将确认什么

确认你能说明各版本解决了什么、还留下什么，以及为什么幂等性是重试设计的前提。