TCP内部使用的定时器

TCP需定期按照某算法对某事件进行触发，此时需要定时器进行实现。

TCP定时器Timer也称为计时器，TCP在建立连接之后，可能会启动4个定时器：

• 重传定时器 Retransmission Timer
• 坚持定时器 Persistent Timer
• 保活定时器 Keeplive Timer
• 2MSL定时器 Time_Wait Timer

建立连接定时器

建立连接定时器connection-establishment timer，是在建立连接的时候使用。

建立连接

TCP建立连接需3次握手，建立连接的过程中，在发送“请求建立连接SYN包”时，会启动一个定时器，默认为3秒。若SYN包丢失，3秒后会重新发送SYN包并启动一个新的定时器，并设置为6秒超时。

SYN 
请求建立连接，把含有SYN标识的报文称为同步报文段。
同步`SYN=1`时表示一个连接请求或连接接收报文

# 设置重发SYN包次数
$ cat /proc/sys/net/ipv4/tcp_syn_retries

重传定时器

重传定时器（Retransmission Timer，RTO）在TCP发送数据时设定，在计时器超时后，没有收到返回确认的ACK时，发送端会重新发送队列中需重传的报文段。

RTO是用来计算TCP报文段的超时重传时间，每发送一个报文段就会启动RTO，如果在定时器到期还没收到对该报文段的确认，就重传该报文段，并将RTO复位，并进行一次计算。

为了控制丢失或丢弃的报文段，即对报文段确认的等待时间。当TCP发送报文段时，会创建RTO，可能发生两种情况：

1. 若在RTO超时之前收到对报文段的确认则撤销RTO
2. 若收到对特定报文段的确认之前RTO超时则重传该报文段并将RTO复位

重传时间 = 2 * RTT

使用RTO重传计时器规则

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

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

延迟应答定时器

延迟应答定时器（Delayed ACK Timer）也被称为捎带ACK，为什么要延迟应答呢？是为了提高网络传输的效率。

例如，服务器收到客户端的数据后，不是立即回ACK给客户端，而是等待一段时间，一般最大为200ms。此时如果服务端要是有数据需要发给客户端，这个ACK就可以和服务端数据一起发给客户端，比立即会给客户端一个ACK节省了一个数据包。

坚持定时器

坚持定时器（Persist Timer）

保活定时器

保活定时器（Keepalive Timer）是为了应对TCP连接间出现长时间没有数据传输的情况。

服务器每收到一次客户端的数据，会复位保活定时器并重设，默认为2小时。若2小时后没有收到客户端数据，服务端会每隔75秒发送发送一个探测报文，若连续10次后仍无响应，服务器则认为客户端出现故障，最终会终止这个连接。

在TCP建立连接时，在应用进程中设置了socket的SO_KEEPALIVE选项时，保活定时器才会生效。

FTP或HTTP服务器都有Session Time机制，因为TCP是面向连接的，所以会出现只连接不传输的“半开放连接”，服务器检测到这种连接并在某些情况下释放，这就是保活定时器的引用场景之一。

如果客户端和服务器长时间没有数据交互，那么需要保活定时器来判断是否对端是否还活着，建议实现心跳包而不是依赖保活定时器。

保活定时器又被称为TCP的Keepalive，实际使用时，在应用层没有数据传输的时候，一定时间tcp_keepalive_time发送一次保持心跳包，默认为2小时。如果发送成功则继续保持端口活跃，如果没有正常返回，则在指定次数内tcp_keepalive_probes（默认为9次）指定间隔时间tcp_keepalive_intval（默认17s）发送心跳包。如果最后都没有获得正常的ACK，那么才算连接失败。

2MSL定时器

2MSL用在四次挥手之后，主动发起TCP断开的一方需要保持2MSL的TIME_WAIT状态，保持方会开启2MSL定时器来计算TIME_WAIT的状态保持时间。

为什么存在2MSL的TIME_WAIT呢？主要是考虑到四次挥手的最后一个ACK包对方没有收到，对方会重发FIN包，一来一回就是2倍的MSL时长。

2MSL测量一个连接处于TIME_WAIT状态的时间，是为了让TCP有时间发送最后一个ACK，以防止该ACK丢失。

2MSL定时器主要解决2种情况

TIME_WAIT确保有足够时间让对端收到ACK，如果被动关闭方没有收到ACK会触发被动端重发FIN。因为最后一次确认应答ACK报文段很有可能会丢失，因而使被动关闭方处于LIST_ACK状态的，此时被动关闭方会重发FIN+ACK报文段，在等待的2MSL时间内，主动关闭方重新受到被动关闭方重发的FIN+ACK报文段。因此，主动关闭方会重新发送确认应答信息，从而重新启动2MSL计时器，直到通信双方都进入CLOSED状态。如果主动关闭方在TIME_WAIT状态不等待一段时间就直接释放连接并进入CLOSED状态，那么关闭方无法收到来自被动关闭方重发的FIN+ACK报文段，也就不会再发送一次确认ACK报文段，因此被动关闭方就无法正常进入CLOSED状态。

• TCP头部为什么放的是端口的信息呢
• 三次握手有没有可能被恶意的使用呢
• 消息确认机制有没有什么弱点呢