大多数网络工作者都了解延迟对TCP会话的可怕影响。TCP必须在等待ack时暂停数据传输。网络延迟越多，暂停时间就越长。然而，许多人，包括大多数其他IT专业人员，不理解这个问题。他们认为所有东西都以1Gbps连接．另外，TCP窗口大小——主机在等待/发送ACK之前将发送/接收多少数据——也会显著影响传输速率。遗憾的是，大多数TCP会话甚至无法接近1Gbps，特别是在广域网上。我有一个特殊的情况来证明这一点。我们在美国海岸对面的两个主要办事处之间有一个OC-3 (155Mbps)。往返延迟为75ms。这个用户打开一个罚单，抱怨两个办公室之间的文件传输很慢。他的传输速率只有196kbps (1.568 Mbps)。他确信网络有问题，因为他确信他可以更快地传输。所以，我询问了源和目的IP地址，并在我自己的PC上做了一个测试，同时进行数据包捕获。 First, I downloaded a file to my PC with Ethereal running from the remote server. My PC (Windows XP) started the TCP session by advertising a large TCP window size (64,512), but the server returns a small window of 9,280:
http [SYN] Seq=0 Ack=0 Win=64512 Len=0 MSS=1160 http > 4176 [SYN, Ack] Seq=0 Ack=1 Win=9280 Len=0 MSS=1460 4176 > http [Ack] Seq=1 Ack=1 Win=64512 Len=0 因此，服务器在等待我的PC的ACK之前只发送9280字节。现在，几个数据包之后，当HTTP 200回复来自服务器时，TCP窗口增长到16,384，但它从来没有变大:
协议信息HTTP HTTP/1.1 200 OK (application/zip)源端口:HTTP(80)目的端口:4176(4176)序列号:1(相对序列号)下一个序列号:1161(相对序列号)确认号:428(相对ack号)头长:20字节标志:0x0010 (ack)窗口大小:16384校验和:0x7183[正确]超文本传输协议媒体类型:应用程序/zip(762字节)几秒钟后，当TCP稳定，它创建了一个情况，服务器发送14包，然后等待ACK从我的PC。由于两个局之间的往返时间约为75ms，数据传输在ACK运行时暂停。一旦接收到ACK，数据传输将再次开始。我可以在痕迹中一次又一次地看到这一点。让我们做一些数学运算。服务器正在发送每个1214字节的数据包。接收14个数据包并发送一个ACK总共需要大约85毫秒。所以:14个数据包* 1,214字节= 16,996字节(有一个完整的TCP窗口)所以，在85ms，服务器发送16,996字节。现在做一个比例来找出在1秒(1000毫秒)发送了多少:
16,996 X --------- = --------- 85 1,000 85X = 1,699,6000 X = 199,952.94现在转换为千字节:199,952.94/ 1024 = 195.26 KBps看起来熟悉吗?这就是我的用户报告的问题的确切值。网络和TCP运行良好。如果你能让两端使用最大TCP窗口大小(65,536)与85ms RTT，你的理论最大传输速率是:
65,536 X --------- = --------- 85 1,000 85X = 65,536,000 X = 771,011.76现在转换为kilobytes: 771,011.76/ 1024 = 752.94 KBps作为一个网络专家，我把所有东西都转换成比特，所以理论上广域网的最大速率是:
752.94 KBps * 8 = 6023.52 KBps = 6Mbps当您处理数据包跟踪时，这是一个非常简单的数学问题。它是向用户展示网络良好的一种强大方式。不幸的是，您将无法为您的用户增加光速。
更多来自Field博客的>:
去思科子网浏览更多思科新闻、博客、论坛、安全警报、图书赠品等。