TCP的滑动窗口机制，谈谈其设计演化过程( 三 ) _TCP

发送方需要等到有新的确认包到达，才会有可用的窗口可以继续发送数据。

文章插图

确认消息之后窗口的变化接收方成功接收了数据之后，会给发送方返回一个确认包。在确认包中，包含了一个确认序号，用于通知发送方，在这个序号之前的数据都已经成功接收了。（确认序号的主要作用，是用来解决不丢包问题。通知接收端已经接收了哪些数据。）
假设，已发送未确认部分（第32到第45字节），是由4个TCP报文段进行传输的。每个报文段的范围分别为：

第一段为32~34字节；
第二段为35~36字节;
第三段为37~41字节;
第四段为42~45字节。

假设第一段、第二段和第四段，都已经成功的发送给接收方了。但是，第三段还没有送达。
那么，接收方将只能确认第一段和第二段，即第32到第36字节已经接收成功了。而对于第四段，还不能进行确认。
这是因为，TCP采用的是累积确认的机制，确认序号表示在这个序号之前（确认序号值减去1）的数据都已经被成功接收。
由于第三段接收方还没有收到，因此不能越过这部分，去确认第四段。否则，发送方会认为第三段也已经被成功的接收了。
（事实上，现在的TCP支持SACK机制，如果启用了，可以支持确认非连续的数据块。）

文章插图

发送方在接收到确认包之后，窗口将会向右移动5个字节（第32到36共确认5个字节）。而第32到36字节，将会合并到第一部分，变为已发送已确认状态。
由于确认了5个字节，窗口右移之后，又新建了一个5个字节的可用窗口（第52到56字节）。
这个过程会在每次发送方接收到确认包时发生，然后窗口会进行相应的移动，以调整缓冲区各部分的大小。（滑动窗口很形象）

文章插图

有了滑动窗口机制，就可以使用一个确认序号来确认一整段数据。这为TCP面向字节流的服务，提供了可靠性支持，并且不需要为每一个序号的确认而耗费时间。
丢失确认之后窗口的变化发送方在发送了第52到56字节的数据之后，就停下来不再发送数据了。因为被卡在了第37到41字节上，这个范围的字节仍然没有返回确认包。
当然，和PAR机制类似的，TCP也支持超时检测和重传数据包。
因此，在计时器超时之后，发送方将重发已丢失的报文段，并希望这一次能够到达目的地。
非常不幸的是，TCP的累积确认机制，仍存在一个缺点，它并不会独立的确认每个报文段。
这意味着，TCP有可能会重复发送那些实际已经被接收方成功接收的报文段。
在我们的例子中，第四段（第42到45字节）已经被成功接收。但只要第三段没有被确认，当超时进行重发时，第四段也会被重发。

【TCP的滑动窗口机制，谈谈其设计演化过程】