Tcp连接超时（tcp连接超时由哪些原因导致）

为了简化描述，我们先考虑没有启用tcp_syncookies的情况。

三次握手的状态图，从用户态的视角如下：

本篇文档中，只描述服务器侧的处理。当server端调用listen()设置监听端口时，服务器端是会预先建立两个队列，而这两个队列是用来完成三次握手的整个过程的。在用户没有调用accept时，就有可能三次握手已经完成，图1中的后两个包的交互过程是由内核来完成的。因此需要用户调用accept之前，就能管理这些收到的syn包，和已经完成建议连接的socket。

两个队列分别是：

request_sock_queue->listen_sock->syn_table:(命名为半连接队列)

request_sock_queue->request_sock_queue（命名为全连接队列）

当调用listen()函数时，就已经对这两个队列的长度进行了限定。

半连接队列：min(backlog,

somaxconn, tcp_max_syn_backlog)

全连接队列：min(backlog,somaxcon)

当服务器端收到一个syn请求时，会将相应的syn请求放到半连接队列中，syn请求在内核中是以数据结构request_sock来表示的。

函数调用关系如下：

tcp_rcv_state_process（）

|switch(sk->state)

|case TCP_LISTEN: // We received SYN

|conn_request -> tcp_v4_conn_request

tcp_v4_conn_request()中

1．首先判断半连接队列是否已满。若满，则并输出告警信息。possible SYN flooding on port…

2．判断全连接队列是否已满。若满，则丢弃这个请求。

3．处理syn的option。

4．创建syn的ack包，并发送。

5．将syn的request_sock加到半连接队列中。

当服务器端收到三次握手的最后一个ACK时，会创建一个独立完整的socket，放到全连接队列中。同时将半连接中的request_sock删除掉。新的socket等待accept的调用。函数调用关系如下：

tcp_v4_do_rcv()

|case TCP_LISTEN:

|

tcp_v4_hnd_req

|inet_csk_search_req

|

tcp_check_req // update request_sock to icsk_accept_queue

|syn_recv_sock -> tcp_v4_syn_recv_sock //create clild socket.

| inet_csk_reqsk_queue_unlink//将request_sock从半连接队列中删除

| inet_csk_reqsk_queue_removed//更新计数值

| inet_csk_reqsk_queue_add//将新建的socket放到全连接队列中

tcp_v4_syn_recv_sock()是核心函数：

1.调用sk_acceptq_is_full来判断全队列是否已经满。队列最大长度是sk_max_ack_backlog(即min(backlog,somaxcon))，这个是在listen时，确定下来的。如果溢出，增加ListenOverflows计数值，并且丢弃这个应答包。

2.创建一个新的socket，并进行初始化。

从以上可以得知，如果出现ListenOverFlow这个值的增加，则对用户的影响是很大的。因为从三次握手流程可以看到，从客户端发送SYN包开始收到最后一个ACK被丢弃，经历了1.5个RTT时间。对于延时很大的网络，比如跨国际网络，移动网络等高延时网络，以400ms的RTT计算。假设第一次重传后则成功完成了连接。则总共开销时间是RTT*400ms+RTO=3.4s。（RTO：超时时间。Window系列，linux系列都是3s的超时时间）。系统中有一个参数tcp_abort_on_overflow，这个参数默认值是0，表示不启用。如果开启的话，出现全连接队列溢出时，则不是无声的丢弃收到的包，而是发送RESET包终止这个连接。

对于启用tcp_syncookies的时候，是怎么处理的呢？当前系统下，默认是开启这个功能的。因此更有必要了解下这个功能的作用，处理逻辑。之前已经了解到收到syn包后，我们会在内核中建立一个数据结构来管理这个syn包。如果有大量请求的话，半连接队列会被撑爆。

考虑极端情况，队列长度无限，则内核耗光；syn攻击，正常请求会被排除在半连接队列之外，正常的访问会受到影响。Syncookie就是解决这个问题的。启用syn cookie的话，理论上是没有队列长度的。Syn cookie的工作原理是：

1.当收到syn请求后，如果半连接队列未满，则与上述相同的处理逻辑。如果满了，则不会丢弃这个syn请求，而是根据4元组（源地址，源端口，本地地址，本地端口），MSS选项和当前时间来计算出一个新的序列号，这个序列号就是syn+ack包的序列号。同时不新建一个结构来保存收到的syn请求。

2.如果收到ACK包，则会对收到的应答包的应答序列号进行验证。验证的方法是先得到之前发送的序列号。直接将应答序列号减1就可以了。有专门的解密函数，来解密这个序列号中所包含的时间信息，端口等信息。验证成功，则完成三次握手。否则，则丢弃这个包。

注意:syncookie只管半连接队列。如果收到syn时，全连接队列已经满了，则请求也会被丢掉的。

总结：

从原理可以得出，队列的长度是有限的。

如果队列中的请求不能及时被取走，则会导致队列中请求的积压。

新进入的请求则会被丢弃掉。

有下面的规避方案：

1.调大3个参数值：

listen的backlog参数；somaxconn； tcp_max_syn_backlog。

使用ss命令来查看当前socket的实际值。

（netstat命令查看不了）

对于Listen状态的socket，发送队列有着特殊的含义，这个就是表示全连接队列的实际长度。

2.程序优化，加速accept，直到没有ListenOverflows计数