HTTP
HTTP 定义请求与响应的通信语义。本文负责协议版本、连接复用、超时与重试。
1. 面试核心
先记住这几条，再读正文- HTTP/1.1 连接复用。 HTTP/1.1 默认持久连接，同一连接按请求顺序返回响应。
- HTTP/2 多路复用。 HTTP/2 用 stream 多路复用连接，仍受 TCP 队头阻塞影响。卡 · HTTP/1.1 持久连接
- HTTP/3 流隔离。 HTTP/3 基于 QUIC，流之间独立交付，但共享连接拥塞控制。
- 超时预算。 读写超时约束局部阶段，deadline 约束整个调用预算。卡 · 超时设置
- 幂等语义。 GET、PUT 和 DELETE 具有幂等语义，POST 可使用业务幂等键。
2. HTTP/1.1 持久连接
HTTP/1.1 默认复用 TCP 连接，减少重复建连。请求和响应通过消息长度等规则确定边界。客户端应读完响应体，或关闭该连接。否则残留响应数据会妨碍后续复用。
流水线允许连续发出多个请求。服务端仍要按请求顺序返回响应。前一个响应阻塞时，后续响应也要等待。客户端可用多条连接并发请求。
3. HTTP/2 多路复用
HTTP/2 把消息拆成二进制帧。不同 stream 的帧可以交错传输。HPACK 用静态表、动态表等机制压缩字段。
响应在 HTTP 层按各自 stream 交付。底层 TCP 仍按连接字节序交付。缺失字节之后的数据要等重传，相关流随之等待。
HTTP/2 对 DATA 帧实施流级和连接级流量控制。发送量同时受两级窗口约束。接收端通过 WINDOW_UPDATE 补充窗口。并发流数量还受 SETTINGS_MAX_CONCURRENT_STREAMS 约束。
4. HTTP/3 与 QUIC
HTTP/3 运行在 QUIC 之上，并用 QPACK 压缩字段。QUIC 基于 UDP 提供可靠、有序的流。一个流缺失字节时，其他流已完整到达的数据可继续交付。
多个流仍共享连接带宽和拥塞控制。丢包引起的拥塞响应会影响整体发送速度。QPACK 的动态表依赖也会造成头部解码等待。
QUIC 集成 TLS 1.3 握手。连接 ID 支持在地址变化后识别连接。迁移还要受对端策略和路径验证约束。
5. 连接池
连接池限制活跃连接数和等待时间。HTTP/2、HTTP/3 还需限制并发流数量。池容量耗尽时，请求先在客户端排队。
空闲连接和最大寿命决定连接保留多久。连接存活过久时，旧实例摘流和网络设备超时会影响复用。连接数增加也会扩大内存和服务端压力。
容量应结合请求耗时、并发量与服务端能力验证。分段指标用于判断瓶颈是否出在池等待。
6. 超时设置
| 超时 | 约束范围 |
|---|---|
| 连接池等待 | 等待可用连接或并发流名额。 |
| 连接建立 | 建立传输连接。 |
| TLS 握手 | 协商密钥与验证端点。 |
| 读取或写入 | 客户端定义的单次或阶段等待。 |
| 空闲超时 | 连接连续没有活动的时间。 |
| deadline | 包含排队和重试的总时间预算。 |
DNS、TLS 是否计入 connect timeout，要看客户端定义。读取超时也有单次读取和完整响应之分。配置时必须核对所用客户端的接口语义。
假设总预算为 800ms。排队已用 200ms，首次尝试又用 400ms。后续尝试连同退避最多只剩 200ms。每次重试重新获得 800ms 会突破调用方预算。
7. 重试
幂等方法重复执行后，预期服务端效果相同。GET 属于安全方法，PUT 和 DELETE 则允许改变状态。DELETE 再次返回 404，也可以满足幂等语义。
响应超时后，服务端的提交结果仍需核对。POST 写操作可用稳定业务幂等键去重。重试前还需保留可再次发送的请求体。
对已确认尚未发出的请求，可重新尝试发送。对结果不明的请求，需要幂等语义或结果查询。重试还应限制次数，加入退避和抖动。调用链只在选定层重试，以免放大流量。
8. 分段耗时指标
分别记录池等待、DNS、建连、TLS 和首字节时间。再记录读取响应的耗时、重试次数和服务端耗时。HTTP/2 还应观察活动流数和流量窗口。
客户端慢而服务端快时，先看排队和建连。随后检查重传、代理等待和重试。阶段指标能区分客户端等待与业务处理。
9. 常见问题
9.1 HTTP/2 的连接数量
单连接能承载多个流。目标地址、代理策略和并发限制仍会带来多条连接。连接数量应结合故障隔离和容量选择。
9.2 读取超时与调用截止时间
读取超时的范围由客户端定义。deadline 则限制整个调用的结束时间。调用方应向下游传播剩余预算，并取消过期工作。
10 · 面试题卡片
10.1 HTTP/1.1、HTTP/2 和 HTTP/3 如何处理并发请求
出现公司：腾讯、字节跳动
考察重点
- 持久连接、多路复用和 stream 的关系。
- HTTP/2 的 TCP 队头阻塞与 HTTP/3 的改进。
- 协议能力与连接池、超时、重试之间的边界。
相关内容：HTTP/1.1 持久连接至重试。
参考回答
HTTP/1.1 通过持久连接复用 TCP。
流水线响应仍按请求顺序返回。HTTP/2 用 stream 交错传输帧，底层仍有 TCP 队头阻塞。
HTTP/3 用 QUIC 实现流之间的独立交付。丢包仍影响共享拥塞控制，QPACK 也存在动态表依赖。三个版本都要结合连接容量和总 deadline 使用。
10.2 设置 800ms 读取超时后，为什么调用还能超过 800ms？
出现公司：暂无已核验的公开来源（本站自测）
考察重点：局部超时、总预算和安全重试。
参考回答
读取超时只覆盖客户端定义的读取阶段。
连接池排队、建连与重试还会消耗时间。应设置 800ms 总 deadline，并在每次尝试前扣除已用时间。结果不明的写请求还需幂等键或结果核对。
10.3 HTTP/2 已经多路复用，为什么发送仍会等待？
出现公司：暂无已核验的公开来源（本站自测）
考察重点：双层流量窗口与并发限制。
相关内容：HTTP/2 多路复用。
参考回答
DATA 帧同时受流窗口和连接窗口约束。
任一窗口耗尽，相关发送就需等待 WINDOW_UPDATE。并发流上限还会限制新流创建。TCP 拥塞控制和有序交付也继续生效。