第20章 TCP的成块数据流
20.4 窗口大小
由接收方提供的窗口的大小通常可以由接收进程控制，这将影响 T C P的性能。4 . 2 B S D默认设置发送和接受缓冲区的大小为2 0 4 8个字节。在4 . 3 B S D中双方被增加为4 0 9 6个字节。正如我们在本书中迄今为止所看到的例子一样， SunOS 4.1.3、B S D / 3 8 6和S V R 4仍然使用4 0 9 6字节的默认大小。其他的系统，如Solaris 2.2、4 . 4 B S D和AIX3.2则使用更大的默认缓存大小，如8192或16384等。
插口A P I允许进程设置发送和接收缓存的大小。接收缓存的大小是该连接上所能够通告的最大窗口大小。有一些应用程序通过修改插口缓存大小来增加性能。[Mogul 1993]显示了在改变发送和接收缓存大小（在单向数据流的应用中，如文件传输，只需改变发送方的发送缓存和接收方的接收缓存大小）的情况下，位于以太网上的两个工作站之间进行文件传输时的一些结果。它表明对以太网而言，默认的 4 0 9 6字节并不是最理想的大小，将两个缓存增加到 1 6 3 8 4个字节可以增加约 4 0 %左右的吞吐量。在 [ P a p a d o p o u l o s和Parulkar 1993]中也有相似的结果。
在2 0 . 7节中，我们将看到在给定通信媒体带宽和两端往返时间的情况下，如何计算最小的缓存大小。
一个例子
可以使用s o c k程序来控制这些缓存的大小。我们以如下方式调用服务器程序：
bsdi % sock -i -s -R6144 5555
该命令设置接收缓存为 6 1 4 4个字节（- R选项）。接着我们在主机s u n上启动客户程序并使之发送8 1 9 2个字节的数据：
sun % sock -i -n1 -w8192 bsdi 5555
图2 0 - 7显示了结果。
首先注意到的是在报文段 2中提供的窗口大小为6 1 4 4字节。由于这是一个较大的窗口，因此客户立即连续发送了 6个报文段（4 ~ 9），然后停止。报文段 1 0确认了所有的数据（从第 1到6 1 4 4字节），但提供的窗口大小却为 2 0 4 8，这很可能是接收程序没有机会读取多于 2 0 4 8字节的数据。报文段11和1 2完成了客户的数据传输，且最后一个报文段带有 F I N标志。
报文段1 3包含与报文段1 0相同的确认序号，但通告了一个更大的窗口大小。报文段 1 4确认了最后的 2 0 4 8字节的数据和 F I N，报文段1 5和1 6仅用于通告一个更大的窗口大小。报文段1 7和1 8完成通常的关闭过程。
