TCP-IP详解卷1-22：TCP的坚持定时器（persist timer ）

TCP-IP详解卷1-22：TCP的坚持定时器（persist timer ）

一：介绍
    假定接收TCP宣布了窗口大小为零。发送TCP就停止传送报文段，直到接收TCP发送确认并宣布一个非零的窗口大小。但这个确认可能会丢失。
    我们知道在TCP中，对确认是不需要发送确认的。若确认丢失了，接收TCP并不知道，而是会认为它已经完成任务了，并等待着发送TCP接着会发送更多的报文段。但发送TCP由于没有收到确认，就等待对方发送确认来通知窗口的大小。双方的TCP都在永远地等待着对方。
    要打开这种死锁，TCP为每一个连接使用一个坚持计时器。当发送TCP收到一个窗口大小为零的确认时，就启动坚持计时器。当坚持计时器期限到时，发送TCP就发送一个特殊的报文段，叫做探测报文段（window probes）。这个报文段只有一个字节的数据。它有一个序号，但它的序号永远不需要确认；甚至在计算对其他部分的数据的确认时该序号也被忽略。探测报文段提醒对端：确认已丢失，必须重传。
    坚持计时器的值设置为重传时间的数值。但是，若没有收到从接收端来的响应，则需发送另一个探测报文段，并将坚持计时器的值加倍和复位。发送端继续发送探测报文段，将坚持计时器设定的值加倍和复位，直到这个值增大到门限值（通常是60秒）为止。在这以后，发送端每隔60秒就发送一个探测报文段，直到窗口重新打开。

二：糊涂窗口综合症
    1： 起因来自于短分组。接收方的TCP软件在TCP连接建立后将为该连接申请一定的缓冲空间，用于存放刚刚接收，且未被应用程序读取的数据。
        这个缓冲区的空闲区间决定了通知窗口的大小。
    2： 如果接收缓冲区被数据填满，而应用程序每次却只从中读取很少的数据，比如1个八位组，于是，缓冲区就空闲出1个八位组的空间。
        于是，接收方就会通知发送方有一个八位组的空间可用，即通知窗口大小为1。这将导致发送方在发送报文段时，数据区只能为1个八位组。与一个报文段的TCP首部的几十个八位组相比，数据传输显得效率十分低下。
        这种由于每个确认报文通告少量可用空间而导致每个报文段仅能携带少量数据的现象，称为糊涂窗口综合症。
    3： 该现象可发生在两端中的任何一端：接收方可以通告一个小的窗口（而不是一直等到有大的窗口时才通告），而发送方也可以发送少量的数据（而不是等待其他的数据以便发送一个大的报文段）。

三：避免糊涂窗口综合症
    1： 从接收方解决问题
        A： 当接收方收到报文段后立即进行确认，但是要等到缓冲区可用空间至少达到总空间的一半或达到最大报文段长度之后才发送更新的窗口通告。
        B： 推迟确认技术。在窗口大小不足以避免低效率的传输时，则推迟发送确认。
            这种方法的优点是可以降低通信量，提高吞吐率。
            但是其缺点是如果推迟时间太长，会导致报文段重传。反而浪费网络带宽，降低吞吐率。
    2： 从发送方解决问题
        A： 组块发送：发送方的策略是在已经传输出去的数据还没有得到确认之前，允许发送应用程序多次调用写数据操作，但是此时并不将数据立即发送出去，而是等数据收集形成一个较长的报文段或者之前发送数据的确认到达时才发送，这项技术称为组块技术。