HTTP/2 GOAWAY 与 RST_STREAM——连接重置和代理限制

HTTP/2 故障可能很难诊断，因为一个 TCP 连接可以承载许多流。单个请求可能会因“RST_STREAM”而失败，整个连接可能会收到“GOAWAY”，或者 gRPC 客户端可能会报告“UNAVAILABLE”、“INTERNAL”、“CANCELLED”或“stream Reset”。当日志未说明客户端、代理、负载均衡器或服务器是否结束流时，用户搜索“HTTP2 GOAWAY pcap”、“RST_STREAM 分析”、“gRPC 流重置数据包捕获”、“HTTP/2 代理重置”和“ALPN HTTP2 故障排除”。

PCAP 手术非常有用，因为 HTTP/2 证据必须保留 TLS、ALPN、连接计时、流重置和 TCP 关闭行为。如果 TLS 已加密且密钥不可用，数据包捕获仍会显示计时、TCP 重置、连接重用，有时仅在受控环境中显示解密的 HTTP/2。

HTTP/2 连接与流

HTTP/2 通过一个连接复用多个流。流重置与 TCP 连接重置不同。

• RST_STREAM：一个流被取消或失败。
• GOAWAY：端点正在关闭或耗尽 HTTP/2 连接。
• TCP FIN/RST：底层连接关闭或中止。

应用程序通常会将这些问题合并为一个错误。数据包证据和日志应该将它们分开。

ALPN协商

HTTP/2 over TLS 通常依赖于 ALPN。 TLS 握手协商“h2”或其他协议。如果 ALPN 不协商 HTTP/2，客户端和服务器可能会回退或失败。

保存：

• ClientHello ALPN 扩展。
• 服务器选择的 ALPN（如果可见）。
• TLS 警报。
• TCP 在握手期间重置。

如果 HTTP/2 从未协商过，请不要调试“RST_STREAM”。

GOAWAY

“GOAWAY”告诉对等方不应在该连接上创建新的流。在正常耗尽、部署、代理连接老化或负载均衡器行为期间，这可能是正常的。当客户端错误地重用耗尽连接或在活动请求期间出现 GOAWAY 时，就会出现问题。

重要问题：

• 谁发送了GOAWAY？
• 最后一个流 ID 是什么？
• 活动流是否失败？
• 客户端是否重试新连接？
• 固定连接年龄是否会发生 GOAWAY？

RST_STREAM

RST_STREAM 终止一个 HTTP/2 流。原因包括：

• 客户取消。
• 服务器拒绝请求。
• 代理超时。
• 流量控制问题。
• 最大流限制。
• 超出 gRPC 截止日期。
• 由代理翻译的后端重置。

流 ID 和时间很重要。没有它们，数据包的故事就不完整。

TCP层仍然很重要

HTTP/2 位于 TCP 之上。如果底层连接有重传、零窗口、重置、MTU 问题或空闲超时，HTTP/2 错误可能是次要的。

关联：

• 流重置时间。
• 重置前的 TCP 重传。
• FIN/RST 发送方。
• 空闲间隔。
• TLS close_notify（如果可见）。

Checklist

使用此工作流程：

1. 保留 DNS、TCP 和 TLS 握手。
2. 确认 ALPN 协商的 HTTP/2。
3. 确定故障是流级还是连接级。
4. 寻找 GOAWAY 时间和发件人。
5. 在解密的跟踪或日志中查找 RST_STREAM 计时和流 ID。
6. 与代理/负载平衡器日志关联。
7. 检查 TCP 重传、零窗口、FIN 和 RST。
8. 检查客户端重试是否正确。
9. 修剪时保留数据包时序。
10. 加密时将 pcap 证据与 HTTP/2 调试日志结合起来。

最终诊断

HTTP/2 GOAWAY 和 RST_STREAM 错误不是一般的网络故障。它们是流和连接控制信号，必须与 ALPN、代理行为、gRPC 截止日期、TCP 运行状况和连接重用相关。

PCAP 手术有助于保留时间线，以便可以将 HTTP/2 和 gRPC 故障减少到正确的层：TLS 协商、流重置、连接耗尽、代理超时或 TCP 传输故障。