窗口大小和ACK编号

• Receiver indicates the window size is 3000 
• Transfer goes ahead 
• Acknowledge every 3000 bytes 
• Receiver increases window size to 4000 
• 4000 bytes will be transferred before the next acknowledgement 

#1 楼

我教TCP，经常碰到有人误解说只有在达到窗口大小时才发送ACK的人。这不是真的。 （要真正透明起见，在我也了解得更多之前，我也错误地教了这个，所以我完全理解了这个错误）。注意TCP是双向的，并且双方都保持窗口大小。

窗口大小（接收方设置）是发送方可以发送多少个字节的硬限制，而不必强制停止等待进行确认。

窗口大小不能确定接收方应多久发送一次确认消息。最初，TCP协议要求在接收到每个段之后发送确认。后来，对TCP进行了优化，以使接收方可以跳过ACK并每隔一个（或更多）其他数据包发送一个ACKnowledgment。

TCP的目标是使发送方连续不断地发送数据包，而不会产生延迟。或中断，因为它不断收到ACKnowledgements，因此“传输中的字节数”始终小于“窗口大小”。如果发件人在任何时候都发送了等于窗口大小的字节数而没有收到ACK，则它被迫暂停发送并等待。

在所有这一切中要考虑的重要事项是往返时间。通常，当您通过有线方式学习TCP时，您只会看到TCP会话中一方的观点，这使得很难推断或真正“看到” RTT的效果。为了说明RTT的效果，请看一下这两个捕获。它们都捕获相同的会话，通过HTTP下载2MB的文件，但一个是从客户端的角度来看的，另一个是从服务器的角度来看的。

注意：它更易于分析如果关闭Wireshark功能“允许子分解器重新组合TCP流”，则为TCP

请注意，从服务器端捕获（谁是文件的发送方）开始，服务器在接收到数据包＃14中的第一个ACK之前，连续发送了8个完整数据包（数据包编号6-13）。该ACK，请注意客户端的确认是针对数据包＃7中发送的段。客户端在数据包20中发送的ACK来自数据包＃9中发送的段。

了解客户端实际上如何确认其他所有数据包。但似乎几乎是在承认他们“迟到”。但是实际上，这仅仅是往返时间的影响。发送方能够在第一个段到达客户端以及客户端的ACK到达服务器之前发送7〜个段。如果从客户端的角度看捕获，它看起来非常“干净”，也就是说，它接收到的每第二个数据包都会发送一个ACK。

请注意在发生什么情况Packet＃23。服务器已发送所有可能的消息，因为“传输中的字节数”达到了“窗口大小”，因此被迫停止发送。直到下一个ACK到达。由于ACK收到的所有其他段中都将出现。每个ACK允许发送方在窗口再次充满之前再次发送两个新的段，并且服务器再次被迫暂停。这种情况一直持续到第51个数据包，此时客户端（接收方）显着增加了窗口大小，从而允许服务器（发送方）再次开始传输不受抑制的数据……至少直到第一个数据包＃175，即新窗口填满。 br />

#2 楼

窗口大小用于防止接收器处的拥塞（与试图阻止网络中的拥塞的拥塞窗口相反）。

它的功能相对简单：接收方将其窗口大小通知发送方，窗口大小通常表示可用的缓冲区大小。因此，每当一个新的数据包到达接收器时，这个数目就应该减少，而每当一个数据包在接收器中被处理时，这个数目应该增加。

在发送方，发送方尝试确保在任何给定时间，他/她在传输中的字节数不超过最后收到的广告窗口的字节数，因此降低了泛洪接收器的可能性。

现在，从wireshark输出中，我们可以看到您的窗口大小相对较大，因此传输没有受到限制，并且您发送的每个数据包都会收到一个ACK（通常情况下应该如此）不使用ACK聚合的情况）。当前，以太网帧最常用的最大大小为1500字节。如果删除所有标头，您将看到剩余的字节实际上是增加ACK的数量。