TCP状态机与定时器

本文中部分内容引用自以下文章列表：

https://blog.csdn.net/wdscq1234/article/details/52505191
https://blog.csdn.net/whgtheone/article/details/80970292
https://blog.csdn.net/u013929635/article/details/82623611
https://blog.csdn.net/xiaofei0859/article/details/52794576
https://www.cnblogs.com/bewolf/p/11100532.html

TCP状态机是理解TCP机制的一个比较好的途径，另外在TCP中还有多种定时器，本文我们结合状态机来详细说明各种定时器的作用以及为什么存在。

TCP中的状态说明

TCP状态机如下图：

TCP连接的建立过程如下图：

TCP连接的释放过程如下图：

TCP定时器说明

TCP定时器包括以下类型：

建立连接定时器(connection-establishment timer)

重传定时器(retransmission timer)

延迟应答定时器(delayed ACK timer)

坚持定时器(persist timer)

保活定时器(keepalive timer)

FIN_WAIT_2定时器(FIN_WAIT_2 timer)

TIME_WAIT定时器 (TIME_WAIT timer, 也叫2MSL timer)

1.建立连接定时器(connection-establishment timer)

目的：防止建立连接时无限等待。

定时器机制：顾名思义，这个定时器是在建立连接的时候使用的， 我们知道，TCP建立连接需要3次握手。建立连接的过程中，在发送SYN时， 会启动一个定时器(默认应该是3秒)，如果SYN包丢失了， 那么3秒以后会重新发送SYN包的(当然还会启动一个新的定时器， 设置成6秒超时)，当然也不会一直没完没了的发SYN包， 在/proc/sys/net/ipv4/tcp_syn_retries 可以设置到底要重新发送几次SYN包。

对应状态机：未超时：SYN_SENT->ESTABLISHED，超时：SYN_SENT->CLOSED。

2.重传定时器(retransmission timer)

目的：保证数据可靠性。

定时器机制：重传定时器在TCP发送数据时设定，在计时器超时后没有收到返回的确认ACK，发送端就会重新发送队列中需要重传的报文段。使用RTO重传计时器一般有如下规则：

当TCP发送了位于发送队列最前端的报文段后就启动这个RTO计时器；
如果队列为空则停止计时器，否则重启计时器；
当计时器超时后，TCP会重传发送队列最前端的报文段；
当一个或者多个报文段被累计确认后，这个或者这些报文段会被清除出队列。

    重传计时器保证了接收端能够接收到丢失的报文段，继而保证了接收端交付给接收进程的数据始终的有序完整的。因为接收端永远不会把一个失序不完整的报文段交付给接收进程。

对应状态机：无法体现。不管定时器是否超时，都处于ESTABLISHED状态。

备注：RTT和RTO的说明如下：
RTT(Round Trip Time)：一个连接的往返时间，即数据发送时刻到接收到确认的时刻的差值；
RTO(Retransmission Time Out)：重传超时时间，即从数据发送时刻算起，超过这个时间便执行重传。
关于RTO的计算方式，可参考RFC 6298。

3.延迟应答定时器(delayed ACK timer)

目的：减少ACK包的数量，提高传输效率。（单独的ACK包有效荷载占比太低了）

定时器机制：延迟应答也被成为捎带ACK， 这个定时器是在延迟应答的时候使用的。 为什么要延迟应答呢？ 延迟应答是为了提高网络传输的效率。
    举例说明，比如服务端收到客户端的数据后，不是立刻回ACK给客户端，而是等一段时间(一般最大200ms)，这样如果服务端要是有数据需要发给客户端，那么这个ACK就和服务端的数据一起发给客户端了，这样比立即回给客户端一个ACK节省了一个数据包。

对应状态机：无法体现。不管定时器是否超时，都处于ESTABLISHED状态。

4.坚持定时器(persist timer)

目的：防止零窗口后无法恢复。

定时器机制：我们已经知道TCP通过让接收方指明希望从发送方接收的数据字节数（即窗口大小）来进行流量控制。如果窗口大小为 0会发生什么情况呢？这将有效地阻止发送方传送数据，直到窗口变为非0为止。接收端窗口变为非0后，就会发送一个确认ACK指明需要的报文段序号以及窗口大小。
    如果这个确认ACK丢失了，则双方就有可能因为等待对方而使连接终止：接收方等待接收数据（因为它已经向发送方通告了一个非0的窗口），而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器 (persist timer)来周期性地向接收方查询，以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查 (window probe)。
    坚持计时器的截止期设置为重传时间的值，但若没有收到从接收端来的响应，则发送另一个探测报文段，并将坚持计时器的值加倍和并复位，发送端继续发送探测报文段，将坚持计时器的值加倍和复位，直到这个值增大到阈值为止（通常为60秒）。之后，发送端每隔60s就发送一个报文段，直到窗口重新打开为止；

对应状态机：无法体现。不管定时器是否超时，都处于ESTABLISHED状态。

5.保活定时器(keepalive timer)

目的：防止产生死链接。

定时器机制：在TCP连接建立的时候指定了SO_KEEPALIVE，保活定时器才会生效。
    每当服务器收到客户的信息，就将keeplive timer复位，超时通常设置2小时，若服务器超过2小时还没有收到来自客户的信息，就发送探测报文段，若发送了10个探测报文段（每75秒发送一个）还没收到响应，则终止连接。

对应状态机：未超时：ESTABLISHED，超时：ESTABLISHED->FIN_WAIT_1。

备注：这个其实很不实用，因为默认是2小时没有数据交互才探测，时间实在是太长了。如果你真的要确认对端是否活着， 那么应该自己实现心跳包，而不是依赖于这个保活定时器。

6.FIN_WAIT_2定时器(FIN_WAIT_2 timer)

目的：防止close过程中出现异常，导致资源无法释放。

定时器机制：主动关闭的一端调用完close以后（即发FIN给被动关闭的一端， 并且收到其对FIN的确认ACK）则进入FIN_WAIT_2状态。如果这个时候因为网络突然断掉、被动关闭的一段宕机等原因，导致主动关闭的一端不能收到被动关闭的一端发来的FIN，主动关闭的一段总不能一直傻等着，占着资源不撒手吧？这个时候就需要FIN_WAIT_2定时器出马了， 如果在该定时器超时的时候，还是没收到被动关闭一端发来的FIN，那么不好意思， 不等了，直接释放这个链接。FIN_WAIT_2定时器的时间可以从/proc/sys/net/ipv4/tcp_fin_timeout中查看和设置。

对应状态机：未超时：FIN_WAIT_2->TIME_WAIT，超时：FIN_WAIT_2->CLOSED。

7.TIME_WAIT定时器 (TIME_WAIT timer, 也叫2MSL timer)

目的：1.防止被动断开的一方无法收到最后1个ACK，无法释放资源；2.防止刚释放的端口被新连接使用，有老连接的报文延迟后发送到新连接上。

定时器机制：TIME_WAIT是主动关闭连接的一端最后进入的状态， 而不是直接变成CLOSED的状态， 为什么呢？第一个原因是万一被动关闭的一端在超时时间内没有收到最后一个ACK， 则会重发最后的FIN，2MSL（报文段最大生存时间）等待时间保证了重发的FIN会被主动关闭的一段收到且重新发送最后一个ACK；另外一个原因是在2MSL等待时间时，任何迟到的报文段会被接收并丢弃，防止老的TCP连接的包在新的TCP连接里面出现。不可避免的，在这个2MSL等待时间内，不会建立同样(源IP, 源端口，目的IP，目的端口)的连接。
    主动关闭方在这等待的2MSL时间内，如果重新收到被动关闭方重发的 FIN+ACK 报文段，主动关闭方会重新发送确认应答信息，并重新启动2MSL计时器，直到通信双方都进入 CLOSED 状态。

对应状态机：未超时：TIME_WAIT->TIME_WAIT，超时：TIME_WAIT->CLOSED。