tcp/ip学习笔记--第22章 TCP persist timer

简介

TCP的接收方通过发送通告窗口大小来控制字节流的传输。如果发送的窗口大小为0，那么发送方将停止发送数据，等待接收方发送更新窗口的报文。

但是，如果接收方发送的更新窗口的报文丢了会发生什么呢？这个时候双方都会进入无限的等待状态：发送方等待更新窗口的报文，接收方等待发送方发送数据。

为了解决这个问题，增加了一个坚持定时器：当通告窗口变为0之后，就周期性的发送窗口探查报文，接收方接收到窗口探查报文后再次通告窗口大小。

窗口探查报文只包含一个字节的数据，而且这个字节的数据就是下一个要发送的数据。那么如果没有要发送的数据，又该发送什么呢？书上没有提及，也没有找到相关的资料，猜测是发送一个没有数据的报文吧。（** 这个标记表示此处有疑问，方便以后全文搜索）

窗口探测报文发送的时间间隔也遵守指数避让。即1.5，3，6，12，24，48，60，60......

但是由于TCP坚持定时器要求区间在5-60之间，所以变成了：5，5，6，12，24，48，60，60......

糊涂窗口综合症

表现为不断的发送长度很小的报文段，而不是最大长度的报文段。

发送方和接收方都可能导致这个问题：发送方发送小块的数据，而不是等数据积累到一定的长度再发送。接收方通告大小很小的窗口，而不是等窗口增加到一定大小再通告。

发送方和接收方都执行一些措施来避免这种情况的发生。（书上这一段写的有点晦涩，我试着写得更有条理一些）

 接收方：不能通告太小的窗口。必须满足以下条件之一：1.窗口大小超过一个完整的报文段，2.窗口的大小超过缓冲区的一半。

发送方：实施nagle算法。

之前有介绍过nagle算法，算法内容如下：发送方只能有一个已经发送的，而未被确认的小报文段。当收到已发送的小报文段的ack确认时，才能再发送小段文段。当然值得注意的是ack确认不受此限制，而且ack确认可以携带数据。

那么问题来了，多小的报文算小呢？跟对接收方的限制一样，必须满足以下条件之一：1.窗口大小超过一个完整的报文段，2.窗口的大小超过接收方曾经广播过的最大的窗口大小（那不就是接收方缓冲区大小嘛）的一半。

当然，发送方可以选择关闭nagle算法，关闭了这个算法，想发多大的数据就发多大的数据。

其他知识点

1.尽管发送发和接收方都采取了措施来避免，但是还是会出现接收方通告小窗口的情况，这是因为：

比如说接收方B通告了一个大小为1500的窗口，但是发送方A只发送了1024个字节，如果这时候A通告一个大小为0的窗口，那么发送方的滑动窗口就会收缩（shrink），这是不被允许的，所以只能发送通告窗口大小为476的报文。

2.书上p329最后一段提到，接收方在接收到报文13（通告窗口大小为509）后，并没有立即发送数据，而是进行了一个坚持定时器溢出周期的等待（5s），然而奇怪的是nagle算法并没有这个限制，因为此时并没有任何未被确认的数据。不知道是什么规则施加的这个限制。

为什么不简单的让接收方重新发送更新窗口报文呢？