Page 142 - Web性能权威指南
P. 142
即便与运营商网络仍维持着（两端间）连接不中断，无线模块也可以处于低耗电状
态。外部网络的分组到来时，运营商无线网络会通知设备，使其无线模块切换到连
接状态，从而恢复数据传输。
明白了吗，应用不必让无线模块“活动”也可以保持连接不被断开。但不必要的长
连接也有可能极大地消耗电量，而且由于人们对移动网络无线通信的误解，这种情
况经常发生。这里可以参考 7.4.2 节中的“物理层连接与应用层连接”和 7.5 节“移
动网络中的分组流”。
大多数移动运营商的 NAT 连接超时时间为 5~30 分钟。因此，为了在空闲
状态下保持连接，可能需要周期性（每 5 分钟）发送一次 Keep-Alive。如
果你觉得自己的 Keep-Alive 发送太过频繁，需要先检查自己的服务器、代
理和负载均衡器配置！
8.3 预测网络延迟上限
在移动网络中，一个 HTTP 请求很可能会导致一连串长达几百甚至上几千 ms 的网
络延迟。这一方面是因为有往返延迟，另一方面也不能忘记 DNS、TCP、TLS 及控
制面的延迟（图 8-2）。
RRCၹฆ DNSֱკ TCP TLS HTTP൩൱
50ċ2500 ms 1ْྫݓ 1ْྫݓ 1~2ْྫݓ 1~nْྫݓ
图 8-2：一个“简单的”HTTP 请求的构成
最好的情况，就是无线模块处于最高功率状态、DNS 已经提前解析完成，而且 TCP
连接是现成的（客户端可以重用已有的连接，不用再花时间去建立新连接）。可是，
如果连接繁忙，或不存在，那就必须在发送数据前经历额外的往返。
为说明额外的网络往返有多大影响，我们假设理想情况下 4G 网络的往返时间为 100 ms，
3.5G+ 网络的往返时间为 200 ms。
在 3G 网络中，仅 RRC 控制面延迟一项就可以给重建无线通信环境增加几百到几
千 ms 的延迟！无线模块活动后，可能还需要解析主机名和 IP 地址，然后进行 TCP
握手，这又是两次往返。然后，如果需要安全信道，可能还需要额外两次网络往返
（参见 4.3 节）。最后，才能发送 HTTP 请求，这最少又是一次往返（表 8-1）。
126 ｜ 第 8 章
