同一个长连接站点, 用着用着浏览器突然把所有请求都”重连”了一遍, 页面整体刷新一次才恢复, 然后又正常一段时间, 接着再来一次。这种规律性的”集体重连”经常被误判成代理IP 出口抽风, 但它更像是 HTTP/2 的 GOAWAY 帧在背后作怪——只有代理IP 链路把它原样转好, 业务侧才不会被它打扰。
GOAWAY 帧、优雅关闭、连接迁移
GOAWAY 是 HTTP/2 协议层的一个控制帧, 服务端在决定不再接收新请求时主动发出, 告诉客户端”我已经处理的请求会跑完, 新请求请换一条连接”。这是一个”先把离开说清楚再走”的过程, 不会把还在飞的请求直接掐掉, 业内把它叫做优雅关闭 (Graceful Shutdown)。
优雅关闭的好处是业务侧几乎无感知。客户端收到 GOAWAY 后会主动把后续请求迁移到新连接上, 这个动作叫做连接迁移 (Connection Migration), 整个过程对上层应用透明, 不需要重连握手、不需要重新鉴权, 只要底层连接池里还有可用连接就行。
GOAWAY 帧在 HTTP/2 协议里是公开规范, 所有合规的实现都认得。但代理IP 链路上能不能”端到端”传递它, 取决于代理是否正确维护了上下游的流 ID 映射——这一点决定了业务侧看到的是”平滑迁移”还是”集体重连”。
为什么代理IP 环境下 GOAWAY 容易被”卡住”
代理IP 链路把一条 HTTP/2 连接拆成两段: 客户端到代理一段, 代理到目标站一段。GOAWAY 帧是协议层消息, 代理要正确转发, 需要同时维护”流 ID 映射”和”连接状态”, 任何一个环节判断错, 业务侧的表现都会跑偏。常见四种状况:
- 代理正确透传: 主流 HTTP/2 代理在识别到 GOAWAY 帧后会原样转发, 客户端顺利迁移, 业务侧无感。
- 代理吞掉不转: 部分代理只做字节层转发, 收到 GOAWAY 帧后没有把”我也要关了”这个信号继续往客户端方向送, 客户端继续复用老连接, 直到老连接真断时才发现, 这时表现就是”集体重连”。
- 代理关自身而不关上游: 代理收到上游 GOAWAY 后自己关掉对客户端的连接, 但没有去关代理到目标站的连接, 后续的请求依然发到代理处被拒, 表现为请求失败 + 重试风暴。
- 链路多跳放大: 链路越长, 任何一环的 GOAWAY 都会被多段连接放大, 重连代价 (新建两段连接 + 鉴权 + 流 ID 重建) 远高于直连时的单次握手。
业务侧最常见的”莫名其妙重连”现象, 多半就是这四类之一。判断方法: 在客户端 F12 Network 里看”Connection ID”或”RST_STREAM”字段, 如果重连前出现 GOAWAY 字样, 就是它在背锅; 否则可能只是出口抖动, 不要冤枉代理IP。
GOAWAY 本身是 HTTP/2 协议设计的得体离场, 代理IP 链路要做的只是把”离场通告”原原本本传过去。理解了这一点, 那些偶发的”集体重连”就有了清晰的归因方向, 而不是一味地怀疑出口质量。
把离开说得清清楚楚, 才算得体离场——GOAWAY 帧是 HTTP/2 协议层的一次得体离场, 代理IP 链路把它原样传好, 业务侧几乎不需要为它做什么。