4.1.2　问题2：WAN连接中的巨大延迟

网络延迟（数据包的“往返时延”）对Windows类协议如TCP协议，包括通用Internet文件系统（Common Internet File System,CIFS），它是Microsoft Windows用来实现主机间文件共享的一个协议或邮件撰写应用程序接口（Messaging Application Programming Interface,MAPI），被Microsoft Outlook/Exchange调用的一个协议，这样一些请求——响应类协议的性能及吞吐量有着直接影响。高往返时延会特别降低“聊天”类应用的性能，即便在每一个对话中实际传递的信息量并不是特别多。

当整体吞吐量有限而往返时延已经达到临界点，或者网络问题是由时延引起而与带宽无关时，靠增加带宽（或减少数据发送）并不能改善系统性能。由图4-1的说明可知，连接的性能最初与带宽线性相关，但当延时超过临界点时，性能将呈指数急剧下降。很容易从直观上来解释这个结果：C/S应用程序为串行执行方式，因此程序的效率与客户端到服务器端往返时延成反比，如果C/S应用程序被阻塞在某一串行化操作处（例如，聊天应用），这一阻塞将导致双倍时延，并使得整体性能双倍下降——每一步都将需要双倍时间完成（因为客户端在等待服务器端的响应，而服务器端也同样需等待客户端的请求）。

如果不是聊天类应用，而是基于Window的协议的C/S软件（如TCP），也会面临同样的命运。我们可以通过建立一个简单的往返时间（Round-Trip Time,RTT）与协议窗口（Window,W）之间的等式来解释。协议窗口的大小是发送者无需接收者确认而可以一次发送的最大数据量，一旦协议窗口写满了，发送者就必须等待直到它收到接收者确认信息。收到接收者确认信息需要耗费双倍往返时间，因此数据发送速率由窗口大小除以往返时延得到：

TCP协议必须要知道怎么确定窗口的大小，最佳方案要考虑以下几方面因素。为了很好地适应不同条件的网络状况，TCP将依据当前网络容量确定窗口W的大小，假设当前网络容量（或者TCP发起者共享带宽）大致为每秒B个字节，那么发送端窗口大小将被设置为B×RTT：

图　4-1　时延增加对连接性能的影响示意

也即，网络吞吐量等同于可得速率。不幸的是现实并非如此简单。包括TCP和CIFS在内，很多协议其本身就已经确定了窗口大小的上界。比方说，在Windows操作系统中，CIFS规定请求上限为64KB。最早的TCP协议其头部通告窗口的大小为16字节，受限于此，TCP窗口大小上界也同样为64KB，现代TCP堆栈可通过应用RFC 1323标准窗口来突破这个限制，但是由于一些历史遗留原因，仍然有许多TCP产品在连接协商设置时并不支持窗口扩展。而更多的像CIFS这样一类协议，它们除了受到TCP窗口大小限制，还要受应用层的约束。在实际应用中，吞吐量由最大窗口尺寸决定（Maximum Window Size,MWS）：

更麻烦的是吞吐量还要受其他源自TCP阻塞算法本身的因素限制。当WAN的带宽在千兆级之上时，就无法再忽视这类局限了。这也可能是为什么经常企业在对支干网络进行升级后，却看不到非聊天应用性能有明显的改善的关键原因。

性能有限的根源来自TCP阻塞算法与高时延环境的冲突。当探测到包丢失现象时，TCP将迅速做出反应，显然这将引起过度的安全顾虑（例如，为防止TCP连接过载形成网络阻塞）。为了探测可用带宽，TCP会动态调整传输速率，时不时地使网络偶尔处于丢包状态，然后又主动回退。在高时延环境中，缓慢的响应时间降低了吞吐量，直到最近这些年，研究人员才开始意识到这个问题，90年代晚期，人们找到了模拟由TCP引起的丢包率函数：

此公式说明平均拥塞窗口大小基本可由包的大小（S）与丢包速率（P）确定，由此可得一个TCP上客户-服务器应用的实际吞吐量为：

这个公式显示WAN的时延对性能的影响要比LAN的时延更为明显。通常，应用程序等待确认产生的时延会导致系统瓶颈，尽管效率高的应用可以通过调整TCP窗口尺寸来克服瓶颈问题。此外，如果系统中包含高带宽链接，拥塞控制机制也会限制单个链接的速度以填平链路间的速度鸿沟。这三类时延瓶颈将极大影响你的系统性能。图4-2解释了一个WAN上的应用是如何受制于四类主要因素的影响，一旦克服了这些障碍，应用程序的性能就将飞涨，用户效率也会更高。

图　4-2　云应用的四个瓶颈