HTTP1.1与TCP长连接差异及相关技术故障排查咨询

首先明确核心差异：

• TCP连接是传输层的双向字节流通道，建立需三次握手、关闭需四次挥手，是HTTP协议的底层传输载体；
• HTTP/1.1长连接是应用层的复用机制：复用已建立的TCP连接发送多组HTTP请求/响应，避免重复建立TCP连接的开销。HTTP/1.1默认开启长连接，无需额外声明（除非显式关闭）。

你的三个问题解答 #

1. 哪一方会发送HTTP/1.1的Keep-Alive: param请求头？ #

客户端和服务器都可以发送：

• 客户端发送是在请求中告知服务器自己期望的长连接参数（如超时时间、最大请求数）；
• 服务器发送是在响应中告知客户端自身实际采用的参数，且服务器有权忽略客户端的参数，返回自己的配置。

2. 当客户端与服务器使用HTTP/1.1时，客户端是否会发送TCP长连接探测包？ #

HTTP/1.1协议本身未定义TCP探测机制，是否发送取决于客户端实现：

• 部分HTTP客户端库（如Apache HttpClient、OkHttp）会开启TCP层的SO_KEEPALIVE选项，在空闲连接上发送保活探测包，但这属于TCP层行为，并非HTTP协议规定；
• 若客户端未启用TCP保活，空闲期间不会主动发送任何数据包。

3. 要使用HTTP/1.1长连接，客户端必须设置Connection: Keep-Alive或Keep-Alive: param吗？ #

不需要。HTTP/1.1默认启用长连接，仅当需要关闭长连接时，才需发送Connection: close头；
客户端发送Connection: Keep-Alive属于冗余声明（服务器会兼容处理），Keep-Alive: param仅用于协商长连接的具体参数，不是启用长连接的必要条件。

针对你遇到的2小时后请求无响应问题的排查方向 #

从抓包结果（无FIN包、服务器未收到第二次请求）来看，问题大概率出在中间网络设备（路由器、防火墙、负载均衡）的空闲连接超时机制：

1. 中间设备会主动断开长时间空闲的TCP连接（部分设备可能配置为2小时超时），但未发送FIN/RST包，导致客户端和服务器都误以为连接仍存活；
2. 客户端再次发送请求时，数据包被中间设备丢弃，因此服务器收不到请求，客户端也无法收到响应。

建议的解决和优化方案：

• 检查中间网络设备的TCP空闲超时配置，确认是否存在2小时的断开规则；
• 在客户端或服务器开启TCP保活：启用SO_KEEPALIVE选项，设置合理的保活间隔（如10分钟），通过定期发送探测包避免连接被中间设备判定为空闲断开；
• 调整HTTP长连接的timeout参数：在请求或响应中设置Keep-Alive: timeout=300（如5分钟），让客户端或服务器在连接空闲超过5分钟时主动关闭，下次请求重新建立新连接；
• 客户端实现连接有效性校验：发送请求前先检查连接状态，或在请求超时未响应时主动重试并建立新连接。

内容的提问来源于stack exchange，提问作者Tiina