TCP的四种定时器

         TCP提供可靠的端到端数据传输，保证端到端的方法之一就是确认从另一端收到的数据。但数据和ACK在传输的过程中有可能会丢失。TCP通过在发送时设置一个定时器来解决这种问题。

        对于每个连接，TCP管理4个不同的定时器。

        1，重传定时器：适用于希望收到另一端的确认ACK

        2，坚持定时器：使窗口大小信息保持不断流动，即使另一端关闭了其接收窗口

        3，保活定时器：可检测一个空闲连接的另一端何时崩溃或重启

        4，2MSL定时器：测量一个连接处于TIME_WAIT状态的事件

一：重传定时器

        TCP协议是一种面向连接的可靠的传输层协议，它保证数据可靠传输的基本原理是在发送一个数据之后，就开启一个定时器，若是在这个时间内没有收到刚才发送数据的ACK确认报文（是通过确认序号的方式进行确认，即刚才发送数据的序列号+1），则对该报文进行重传。如果一直失败，满一定次数后就会放弃并发送一个复位信号。如果在定时器溢出之前收到了对应报文的ACK，则会删除该报文对应的重传定时器。

主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B。
如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发。 

反过来，如果主机A没收到确认应答也可能是ACK丢失了，如下图所示。

这种情况下, 主机B会收到很多重复数据。

那么TCP协议需要识别出哪些包是重复的, 并且把重复的丢弃。那TCP是如何去重的呢？

答案就是序列号(TCP将每个字节的数据都进行的编号)，如下图所示：

每次主机B的确认应答都带有对应的确认序列号, 用来告知主机A, 我已经收到了哪些数据（收到的数据为确认序列号-1以下的字节数据），下一次你要从哪里开始发送，而已经接收的数据序列号会缓存在本地等待上层应用程序消费，如果已经重复了，则会丢弃。

比如, 主机A向主机B发送了1005字节的数据, 服务器返回给客户端的确认序号是1003, 那么说明服务器只收到了1-1002的数据. 1003的数据肯定没有收到，至于1004, 1005则不确定，即使收到了，也会暂时缓存， 等主机A重发1003收到后，直接向主机A确认应答，此时确认序列号应该为1006。

二：坚持定时器

        当发送方太快或者接收方的应用程序取数据太慢，这就导致接收方的缓冲区满了，这会接收方会发送一个ACK（不带任何数据的确认），该ACK携带窗口大小为0，发送方若收到窗口大小为0的ACK，此时会暂停发送数据包，直到窗口变为非0为止，这时候接收方会发送一个非零的ACK给发送方，这时候发送方就可以继续发送数据

        但是假如发生了这么一种情况，当发送了窗口为0的ACK给发送方后，一会缓冲区里的数据被应用程序取走了，此时接收方会发送一个非0窗口的ACK给发送方通知发送方可以继续发送数据了，但是如果此通知的ACK半路丢失了咋办，这时候接收方在等，发送方没有收到该ACK也在等，形成了死锁。

        为防止这种死锁的发生，发送方不再时被动的死等，会使用一个坚持定时器(persist timer)来周期性地向接收方查询，以便及时发现窗口是否为非零。这些从发送方发出的报文段成为窗口探查(window probe)

        那坚持定时器什么时候启用呢，其使用的步骤如下

        1，发送方收到接收方发来的一个窗口为0的ACK，此时启用坚持定时器

        2，在定时器溢出之前还没有收到一个窗口扩大的ACK，此时发送方发送窗口探查报文

        3，如果在规定的时间内仍然没有收到窗口扩大的ACK，此时会隔断时间发送一个窗口探查报文，时间间隔大概在5s，6s，12s，24s，48s，60s。达到60s后仍然没有收到就会一直以60s的间隔发送，直到窗口打开或者连接被终止。

        与超时重传定时器不同的是，坚持的状态是TCP从不放弃发送窗口探查。

三：保活定时器

        保活定时器看名字就大概能猜到这定时器是干啥用的，探测对方是否还活着。想象一种场景，当客户端和服务器建立起了一个TCP连接，这时候客户端突然宕机了或者重启了，这时候客户端完全就不知道前世还有这么一个TCP连接存在，而服务器那头还在一直傻傻的等着，这时候的TCP连接就处于一种半开放的状态，这种半开放的TCP已经不能双向传输数据了，但是还会占着服务器的资源，如果这种半开放的TCP越来越多，服务器会浪费很多资源严重的会导致崩溃。

        保活功能就是试图让服务器检测到这种半开放的TCP连接。

        通常使用保活功能的是服务器一侧，但是客户端也不是不让用，只不过大部分场景是服务器设置该功能。如果有需要对端都可以开启保活功能。

        如果一个正常建立起来的TCP连接，在两个小时之内没有任何的动作，则服务器一侧会发送一个探查报文。客户端必须处于以下4个状态之一：

        1，客户端仍然如初，正常运行，并且中间链路没有问题。客户端正常发送响应报文，服务器这时候知道对方是正常工作的。如果在两个小时定时器溢出之前有数据传输，则定时器在交换数据后的两小时再复位。

        2，客户端已挂或者正在重启中，在任何一种情况下，客户端的TCP都没有响应，服务器将不能收到对探查报文的响应，并在75秒后超时。服务器总共发送10个这样的探查报文，每个间隔75秒。如果服务器没有收到一个响应，它就认为客户端主机已经关闭，这时候会关闭该连接并删除该连接的相关资源。

        3，客户端主机崩溃并且已经重启启动，这时候服务器会收到一个对其保活探查的响应，但是这个响应只是通知，服务器说我们再也回不到过去了，你已经不是当初的你了，服务器会终止该连接。

        4，客户端活得好好的，但是中间链路不通，服务器不可达。这时候就和牛郎织女一样了，但是服务器可不会等，它这边发出的探查报文没有响应，和场景2是一样的。

        在第一种场景下，服务器的应用程序没有感觉到保活探查的发生，TCP默默承担了这一切，这个过程对应用程序时透明的。

        后面三种情况，服务器的应用程序将会收到TCP的差错报告。在第2种情况下差错时诸如“连接超时”之类的信息，第3种情况则为“连接被对方终止”，第4种情况时连接超时，，也可根据是否收到与连接有关的ICMP差错来返回其他的差错。

四：2MSL定时器       

         以上为四次挥手的过程，当Server给Client发送FIN报文，Client接收到该报文后进入TIME_WAIT状态，并发送一个ACK响应该FIN报文，但是假设一种情况，该ACK丢失了，如果没有任何保护措施，那Server则进入不了CLOSE状态，该TCP连接无法正常关闭。这时候2MSL定时器登场了。

        MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。2MSL即两倍的MSL，TCP的TIME_WAIT状态也称为2MSL等待状态，当TCP的一端发起主动关闭，在发出最后一个ACK包后，即第3次握手完成后发送了第四次握手的ACK包后就进入了TIME_WAIT状态，必须在此状态上停留两倍的MSL时间，等待2MSL时间主要目的是怕最后一个ACK包对方没收到，那么对方在超时后将重发第三次握手的FIN包，主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME_WAIT状态时两端的端口不能使用，要等到2MSL时间结束才可继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃