TCP滑动窗口

假设A和B之间新建立了一条TCP连接。设备A需要传送一长串数据流，但设备B无法一次全部接收，所以它限制设备A每次发送分段指定数量的字节数，直到分段中已发送的字节数得到确认。之后，设备A可以继续发送更多字节。每一个设备都对发送，接收及确认数据进行追踪。

TCPbuffer中数据可以分为以下四类

1.已发送已确认 数据流中最早的字节已经发送并得到确认。这些数据是站在发送设备的角度来看的。如下图所示，31个字节已经发送并确认。
2. 已发送但尚未确认 已发送但尚未得到确认的字节。发送方在确认之前，不认为这些数据已经被处理。下图所示14字节为第2类。
3. 未发送而接收方已Ready 设备尚未将数据发出，但接收方根据最近一次关于发送方一次要发送多少字节确认自己有足够空间。发送方会立即尝试发送。如图，第3类有6字节。
4. 未发送而接收方Not Ready 由于接收方not ready，还不允许将这部分数据发出。

发送方和接收方必须就它们将要为数据流中的字节指定的sequence number达成一致。这一过程称为同步，在TCP连接建立时完成。为了简化假设第一个字节sequence number是1

发送窗口与可用窗口

发送窗口：接收方允许发送方一次能容纳的未确认的字节数
可用窗口：考虑到正在传输的数据量，发送方仍被允许发送的数据量。实际上等于第3类的大小。

确认处理

确认应答号：过了一段时间，目标设备向发送方传回确认信息。目标设备不会特别列出它已经确认的字节，因为这会导致效率低下。目标设备会发送自上一次成功接收后的最长字节数。

当以发送但尚未确认得字节收到确认之后，这时根据窗口大小向右移动，从而第二类被移动到了第一类。

TCP窗口调整与流控

当服务器从客户端接收数据，它就将数据放在缓存中，服务器必须对数据做以下两步操作：
确认：服务器必须将确认信息发回客户端以表明数据接收。
传输：服务器必须处理数据，将它传递给目标应用程序处理。

区分开这两件事情是非常重要的。关键在于基本的滑动窗口机制中，数据于接收时确认，但并不一定立即从缓存中传输出去。也就意味着当接收数据速度快于接收TCP处理速度时，缓存有可能被填满。当这一情况发生时，接收设备需要调整窗口大小已防止缓存过载。

通过增加或缩小窗口大小，服务器和客户端能够确保对端发送数据的速度等同于处理速度。

减小窗口大小以降低发送速率：

假设客户端传输140字节数据给服务器且客户端的发送窗口为360字节。
一段时间后，服务器接收到140字节，并把它们放入缓存中，确认之后从缓存移除。这种情况服务器处理的速度与数据进入速度相同，窗口大小保存在360字节。将360字节窗口向右移动140字节。由于现在未确认字节数为0，因此客户端又可以发送360字节数据。

假设我们接收到140字节，但只能发送40字节给应用程序，缓存中剩下100字节。当发送140字节的确认信息，服务器将发送窗口缩小100字节，至260字节。当客户端从服务器接收到这一片段，它将会看到140字节的确认信息并将窗口向右滑动140字节。在滑动过程中，将大小缩减至260字节。可以认为将窗口左端滑动140字节，但右端仅滑动40字节。新的稍小一些的窗口保证服务器从客户端接收最多260字节数据，以适应接收缓存中的剩余空间。

缩减发送窗口以停止发送新数据

如果服务器无法接收任何新数据会怎么样呢？假设客户端下一次传输180字节，但是服务器太忙碌而无法对其进行处理。这种情况下，服务器将这180字节缓存下来，并且在确认信息中，将窗口大小从260字节缩减为80字节。当客户端接收到180字节的确认信息，它也会看到窗口缩减了180字节，它会滑动与缩减同样的大小，告知服务器：我确认接收180字节数据，但不允许你再发送新的数据。也可以看作窗口左端滑动180字节，但右端维持不动。只要右端不移动，客户端就无法发送更多数据。