Page 279 - Web性能权威指南

最后，就是我们自己部署并管理的基础设施，需要经常关注和调优。就跟我们经常
抱怨客户和外部网络一样，我们自己家的问题其实一点也不少。通信路径上的每一
台负载均衡器、路由器和 Web 服务器都必须针对长时连接进行调优。

例如，Nginx 1.3.13+ 可以代理 WebSocket 通信，但默认设置了激进的 60 秒超时！
为了突破这个限制，我们必须明确定义更长的超时：

location /websocket {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 3600; ➊
proxy_send_timeout 3600; ➋
}
➊ 设置两次读操作间的超时为 60 分钟
➋ 设置两次写操作间的超时为 60 分钟

类似地，Nginx 服务器前面经常少不了要部署一台负载均衡器，比如 HAProxy。毫
不奇怪，在此也要采取相同的策略，以 HAProxy 为例：

defaults http
timeout connect 30s
timeout client 30s
timeout server 30s
timeout tunnel 1h ➊

➊ 为专用信道设置 60 分钟的不活动超时

前面例子的关键在于额外的“信道”超时。对 HAProxy 来说，connect、client 和
server 超时只适用于初始的 HTTP Upgrade 握手，而一旦升级完成，超时就会由信
道（tunnel）值控制。

Nginx 和 HAProxy 只是我们数据中心内几百种服务器、代理和负载均衡器中的两
种。我不可能在这里把所有可能的配置项都罗列出来。前面的例子只是为了说明大
多数基础设施都需要自定义的配置，才能顺利处理长时会话。请记住，在实现应用
的持久连接之前，首先要保证基础设施的配置正确。

长时连接和空闲会话会占用所有中间设备及服务器的内存和套接字资源。
实际上，短超时经常被视为安全、资源管理及运维的预防措施。无论部署
WebSocket、SSE，还是 HTTP 2.0，都有赖于长时会话，都会对运维提出
新的挑战。

268 ｜ 第 17 章