TCP 坚持定时器 保活定时器

22章坚持定时器

2.坚持定时器：persistenttimer
专门为对付零窗口通知而设计的
当发送端收到零窗口的确认时，就启动坚持定时器。当坚持定时器截止期到时，发送端就发送一个特殊的报文段，叫探测报文段
这个报文段只有一个字节的数据。
探测报文段有序号，但是序号永远不需要确认，甚至在计算对其他部分数据的确认时这个序号也被忽略。探测报文段提醒接收端TCP，确认已丢失，必须重传。
坚持定时器的截止期设置为重传的时间值，若没有收到接收端来的响应，则发送另一个探测报文段，并将坚持定时器的值加倍并复位。
发送端继续发送探测报文段，将坚持定时器的值加倍和复位，直到这个值增大到阈值为止（通常为60s）。
之后发送端每隔60s就发送一个报文段，直到窗口重新打开为止。

可能会出现死锁的情况：
1）接收端向发送端发送了零窗口报文段后不久，接收端的接收缓存有空间了。
2）于是，接收端发送了一个非零窗口大小的报文段，但是这个报文丢失了。
3）发送端没有收到该报文，就一直等待接收端发送非零窗口的报文通知。
4）接收端不知道报文丢了，而是觉得已经发过去了。就一直等待发送端发送数据，这样如果没有任何措施的话就会产生死锁。

坚持定时器时间到了就会发送一个零窗口检测报文段，之后会出现三种情况：
1）对方在收到探测报文段后，在对该报文段的确认中给出现在的窗口值。如果窗口值仍为0，则收到这个报文段的一方将坚持定时器的值加倍并重启。（最大只能增加到60s，之后每次收到零窗口通知就还是60s）
2）对方收到了探测报文段，回复的窗口值不为0，那么死锁的僵局就被打破了。
3）该探测报文发出后，会同时重新启动重传定时器。如果重传定时器的时间到期，还没有收到响应，就超时重传探测报文。


---------------------------------分割线-------------------------------------

22.1引言
我们知道TCP通过让接收方指明希望从发送方接收的数据字节数（即窗口大小）来进行流量控制。如果窗口为0了，发送方将无法发送数据，直到窗口变成非0了。
注意上面所说死锁的情况，

为了防止死锁的情况，发送方使用一个坚持定时器来周期性的向接收方查询，以便发现窗口是否增大。这些从发送方发出的报文段称为窗口探查（window probe）

22.2 一个例子
计算坚持定时器时使用了普通的TCP指数退避。

22.3 糊涂窗口综合征

// ----------百度百科 begin---------
定义（来源百度百科）：指当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢，或二者都有；就会使应用进程间传送的报文段很小，特别是有效荷载很小的情况下；
极端情况下，有效荷载只能有一个字节；传输开销有四十个字节（20ip头 20tcp头）。

解决方法是防止发送端的TCP逐个字节的发送数据。必须强迫发送端的TCP收集数据，然后用一个更大的数据块来发送。
这样的话发送端的TCP需要等待多长时间呢，过长会导致整个过程产生较大的延时。过段就可能发送一个较小的报文段。
Nagle算法就是专门处理这个情况的。

// ----------百度百科 end---------



可以在任何一端采取措施避免出现糊涂窗口综合征:
1）接收方不通告小窗口。通常的做法是接收方不通告一个比当前窗口大的窗口，除非窗口可以增加一个报文段大小或者可以增加接收方缓存空间的一半。
2）发送方避免这个综合征的措施是满足下列条件之一才发送数据：
a：可以发送一个满长度的报文段
b：可以发送至少是接收方通告窗口大小一半的报文段（主要是对付那些总是通告小窗口的主机）
c：可以发送任何数据并且不希望接收ACK（也就是我们没有未被确认的数据）或者该连接上不能使用Nagle算法。

22.4 小结
在连接的一方需要发送数据但对方已通告窗口大小为0时，就需要设置TCP的坚持定时器。发送方使用与第21章类似的重传间隔时间，不断的探查已关闭的窗口，这样探查过程将一直持续下去。



// 可以参考 http://blog.csdn.net/j6915819/article/details/40431917
23章 TCP的保活定时器
23.1 引言
我们已启动一个客户端与服务器建立连接，然后离去数小时，或几个月，而连接依然保持。
这意味着两个应用进程—客户端和服务器都没有使用应用级的定时起来检测非活动状态，而这种非活动状态可以导致应用进程中的任何一个终止其活动。

许多时候一个服务器希望知道客户主机是否崩溃并关机或者崩溃又重启。许多实现提供的保活定时器可以提供这种能力。
保活并不是TCP规范中的一部分。保活定时器是一个有争论的功能，有人认为不该在TCP中提供，而应该由应用程序来完成


保活功能主要是为服务器应用程序提供的。服务器应用程序需要知道客户主机是否崩溃，从而可以代表客户使用资源。



23.2描述
一般称使用保活选项的异端为服务器，另一端为客户端。其实客户端也能使用这个选项，如果双方都特别需要知道对方是否消失，则双方都可以使用这个选项。

如果一个给定的连接在两个小时之内没有任何动作，则服务器就向客户发送一个踏查报文段，客户主机必须处于以下4中状态之一：
1）客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方是正常工作的。服务器在两小时以后将保活定时器复位。
如果两个小时定时器到时间之前有应用程序的通信量通过此连接，则定时器在交换数据后的未来2小时再复位。（这种情况下应用程序感觉不到保活探测的发生，全部由TCP层做了）
2）客户已经崩溃了，并且关闭或正在重启。在任何一种情况下，客户的TCO都没有响应，服务器将不能收到对探查的响应，并在75s后超时。
服务器总共发送10个这样的探查，每个间隔75s，如果服务器没有收到一个响应，就认为客户机已经关闭并终止连接。
3）客户主机崩溃并已经重启。这时服务器将收到一个与其保活探查的响应，但是这样响应是一个复位，使得服务器终止这个连接。
4）客户机正常运行，但是从服务器不可达。这个跟状态2一样，不能区分状态4和状态2的区别，处理也都一样。

两个小时的空闲时间是可以改变的，保活间隔时间是系统级的变量，改变它会影响所有使用该功能的用户。