HTTP协议中的60秒魔咒：一个不规范响应引发的性能谜案

导语

运维工程师盯着监控屏幕上的60秒加载进度条，眉头紧锁。一个不足400KB的JS文件，却在浏览器中卡顿整整60秒。网络抓包显示SSL网关与后端服务器之间上演着奇特的TCP关闭三部曲，而一切根源都指向那个被忽视的HTTP协议细节——当响应既无Content-Length头，也未启用Chunked编码时，数字世界的通信规则悄然改变…

协议困境：响应完整性的判定规则

在HTTP协议中，要判断响应完整性，判定方式随内容类型有所不同。

---

静态内容的精准计量（Content-Length）

对于静态资源类型（如CSS/JS），能够预先计算出响应报文大小，此时可通过在响应头携带中Content-Length来告知完整响应尺寸

GET /static/main.css

HTTP/1.1 200 OK
Content-Length: 1024 #完整body为1024字节，接收到1024字节后即明确响应接收完毕

……

动态内容的进度播报（Transfer-Encoding: chunked）

对于动态资源类型（如实时报表/流数据），由于无法预先计算出响应报文大小，此时可以通过Chunked编码方式来传递信号，当收到尾块时即明确响应接收完毕

GET /live-report  
Transfer-Encoding: chunked  

1F4  // 500字节数据块
C8   // 200字节摘要
0    // 尾块=传输结束，收到尾即明确响应接收完毕

传统困境终极信号（连接关闭）

然而当响应既不包含Content-Length头，也未启用Chunked编码，上述两套机制将同时失效，此时要怎么判断响应是否接收完整呢？

HTTP/1.0 200 OK
Content-Type: text/css

……

此时需要依赖于底层的TCP连接关闭事件作为响应结束标志：

在这种特殊场景下，SSL网关陷入两难境地：既不能主动断开连接（可能截断响应)，也不能无限等待，于是会催生出三种TCP关闭场景。

---

三重关闭场景全解析

场景一：立即关闭连接

如果应用严格遵循该范式，在响应结束后立即关闭TCP连接，SSL网关就能在毫秒级完成响应转发。遗憾的是，实际场景中这类情况虽然居多，但并非100％。

场景二：60秒内被动关闭连接

SSL网关接收超时为60秒，在60秒内浏览器不再等待响应，主动关闭了与SSL网关的TCP连接，这导致SSL网关再继续等待Web应用响应已经没有意义了，故主动关闭与应用的TCP连接。这就好比顾客（浏览器）下单外卖后饿得直拍桌子，商家（Web应用）则忙着备餐但不告知当前进度，骑手（SSL网关）举着餐盒在商铺前焦急等待，顾客（浏览器）等候7秒后果断退单（发FIN）。看到顾客（浏览器）取消了订单，骑手（SSL网关）无奈告诉商家（Web应用）：“老板，别做了，顾客退单了”（发FIN给商家）。

此时对应的SSL网关日志：

2024-05-14 14:29:11 [warn] 19839#0: *345 epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while reading upstream……

场景三：60秒超时关闭连接

SSL网关接收超时配置为60秒，直到60秒超时，Web应用都没告知SSL网关响应是否发送完毕，触发超时后SSL网关主动关闭与Web应用的连接。

这就是导致浏览器加载一个不足400KB的JS文件耗时却长达60秒的场景，SSL网关日志清晰记录着：

2024-05-14 14:29:32 [error] 24132#0: *31 upstream timed out (110: Connection timed out) while reading upstream……

故障溯源：不完整响应的连锁反应

通过对比三种场景，问题症结浮出水面：

1. Web服务缺陷：返回响应时，既未设置Content-Length头，也未采用Chunked编码

2. 协议规范约束：根据HTTP协议要求，此时接收方必须等待连接关闭事件到来以确认响应接收完毕

3. 超时机制碰撞：

   • 浏览器连接超时>60秒
   • SSL网关proxy_read_timeout=60s
   • 后端TCP连接保持连接>60秒

三方共同制造了这个精确的60秒延迟：

Web应用 ────────> SSL网关60秒超时关闭连接 ────────> 浏览器加载不足400KB资源耗时60秒

后记

Content-Length的标尺与Chunked编码的量杯，原是数字汪洋中指引航程的灯塔，纵使现实的惊涛拍打其基座，依旧散射着破晓的微光。当六十秒的沙漏成为命运的标尺：服务器明明已释放出完整的篇章，代理组件却仍在焦灼等待，导致浏览器在熵增深渊爬行——三方共舞虽偶入混沌星域，却让规则的边界绽放新生：每一次超时警报的铮鸣，都是人类对未知深渊的探索，纵使熵增的浪潮终将舔舐岩石，丈量者的足迹已在深渊中留下不朽坐标。

更多精彩内容

微信搜一搜：爻渡