详解linux里的backlog参数

问题

我们在linux上服务器起了一个serversocket，并且设置了backlog为2，并没有让serversock.accept()

在客户端上，我们一个一个的启动了连接socket, 当连接数目超过3的时候，客户端依然可以继续新建连接。

什么是backlog

说起backlog, 都会想起socket编程中的listen backlog 参数,而这个backlog 是linux内核中处理的backlog么？

listen 中的backlog解释

the backlog argument defines the maximum length to which the queue of pending connections for sockfd may grow. if a connection request arrives when the queue is full, the client may receive an error with an indication of econnrefused or, if the underlying protocol supports retransmission, the request may be ignored so that a later reattempt at connection succeeds.

实际上在linux内核2.2版本以后，backlog参数控制的是已经握手成功的还在accept queue的大小。

握手过程中的结构体

首先在linux里可以简单的认为有2个队列，一个就是在握手过程中的队列，而另一个就是握手成功的队列

简单的描述一下3个结构体

request_sock

 是每一个client的连接（无论是握手成功，还是不成功） 里面的 expires代表的是这个request在队列里的存活时间，而 *sk 就是连接成功的socket的数目

request_sock_queue

rskq_accept_head 队列，也就是握手成功的队列，*listen_opt 是指listen过程中的sock

listen_sock

*syn_table 是指握手没有成功的队列，而qlen,qlen_young 分别指的是队列的长度和队列新成员的个数

在结构体中，我们已经清楚的看到了一个listen_sock中的syn_table，另一个是request_sock_queue中的rskq_accept_head，这就是我们刚才说的两个队列，一个是为正在握手的队列，另一个是已经握手成功的队列。

我们在上面都看到了结构体中只是看到了未握手的队列的长度，并没有看到握手的队列长度统计，实际上握手成功的队列长度是在sock 结构中

sock

当握手成功后每一个client就是一个sock, sk_ack_backlog 是队列长度，而sk_max_ack_backlog是指最大的队列长度

在这里我们会有疑问，难道是没个连接上的 sock都会保留队列的长度么？实际上在此时的sock 代表的是server端listen 的sock而不是客户端的sock,也就是在握手没有成功的过程中，在linux使用的sock都是server的listen的sock, 对客户端只是保留成request_sock

tcp握手的几个阶段

收到客户端的syn请求 ->将这个请求放入syn_table中去->服务器端回复syn-ack->收到客户端的ack->放入accept queue中

我们把整个过程分为5个部分，其中将请求放入syn_table和accept queue中的过程也是backlog相关的，在下面我们会详细阐述。

我们先简单的描述一下几个tcp的操作函数，下面针对的也是ip4协议的

在刚才所说的两个步骤，也就是结构体中的 conn_request 和 syn_recv_sock,  所对应的函数是 tcp_v4_conn_request 和 tcp_v4_syn_recv_sock

我们所重点关注的主要是方法中的drop逻辑

tcp_v4_conn_request 函数

1. inet_csk_reqsk_queue_is_full(sk)

判断的是  queue->listen_opt->qlen >> queue->listen_opt->max_qlen_log;

这里有个 qlen 代表的是listen_opt的 syn_table的长度，那什么是max_qlen_log呢？

也就是max_qlen 是listen 传入的backlog和sysctl_max_syn_backlog最小值，并且一定大于16 , roudup_pow_of_two 代表着找最靠近nr_table_entries＋1的2的倍数 sysctl_max_syn_backlog 就是我们熟悉的

/proc/sys/net/ipv4/tcp_max_syn_backlog

我们看一下listen 函数在kernel的实现

我们清楚的看到backlog 并不是按照你调用listen的所设置的backlog大小，实际上取的是backlog和somaxconn的最小值

somaxconn的值定义在

/proc/sys/net/core/somaxconn

2.sk_acceptq_is_full

就是等于我们刚才在前面部分看到的listen中的值

3.inet_csk_reqsk_queue_young

在判断sk_acceptq_is_full 的情况下，同是也要求了判断inet_csk_reqsk_queue_young>1,也就是刚才的结构体listen_sock的qlen_young

qlen_young 是对syn_table的计数,进入 syn_table 加1，出了syn_table  -1

有的人可能会有疑问了

如果accept queue满了，那么qlen_young不就是一直增加，而新来的客户端都会被条件if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) 而drop syn的ack包，那么客户端会出现connected timeout, 而实际上你在测试linux的环境中会发现并没有出现这样的情况。

实际上linux在server起socket的时候会调用tcp_keepalive_timer启动tcp_synack_timer，会调用函数inet_csk_reqsk_queue_prune

而inet_csk_reqsk_queue_prune会在去检查syn的table, 而删除一些这个request 过期后并且完成retry 的syn ack包的请求

为了提高inet_csk_reqsk_queue_prune的效率，在request_sock 里加入了 expires(才前面的结构体中已经提到过) , 这个expires初始值是hardcode的3hz 时间， inet_csk_reqsk_queue_prune会轮训syn_table里的已经exprie request, 发现如果还没有到到retry的次数,那么会增加expire的时间直到重试结束，而expire的时间为剩余retry 次数*3hz ，并且不大于120hz

关于retry, retry的参数可以通过设置 

/proc/sys/net/ipv4/tcp_syn_retries

当然你可以通过设置

/proc/sys/net/ipv4/tcp_abort_on_overflow 为1 不允许syn ack 重试

因为被inet_csk_reqsk_queue_prune函数清除了syn_table，在没有并发的前提下基本上不会出现inet_csk_reqsk_queue_young>1的情况，也就是说不会出现drop sync的情况，在客户端表现，不会出现connect timeout 的情况（这里的实现linux和mac的实现有很大的不同）而刚开始的问题也能得到合理的解释了

通过函数tcp_v4_conn_request的分析，在linux的设计初衷是尽力的允许新的连接握手，而期望服务器端能更快的响应accept.

我们也许会问，刚才的服务器syn ack回去后，如果客户端也回复了ack的话，而此时accept的queue满了，将会如何处理

我们回到前面提到的步骤，处理客户端的ack 函数也就是

tcp_v4_syn_recv_sock 函数

我们看到了熟悉的函数 sk_acceptq_is_full， 而在此时在无函数inet_csk_reqsk_queue_young>1来保护，也就是说在此时如果发现queue是满的，将直接丢弃只是统计了参数linux_mib_listenoverflows，linux_mib_listendrops而这些参数的值可以通过

netstat -s 来查看到

在函数tcp_v4_syn_recv_sock中我们看到tcp_create_openreq_child，此时才clone出一个新的socket ,也就是只有通过了3次握手后，linux才会产生新的socket, 而在3次握手中所传的socket 实际上是server的listen的 socket, 那也就是说这个socket 只有一个状态tcp_listen

netstat的状态

通过在tcp_rcv_state_process可以置socket 的状态，而我们通常使用netstat 中看到这些socket的状态

我们看到从 syn_recv的状态直接设置成established，也就是当server收到client的ack回来，状态置为 tcp_syn_recv，而马上进入tcp_rcv_state_process函数置为状态established，基本没有tcp_syn_recv 的状态期，但我们通过netstat  的使用，还是会发现有部分socket 还是会处于syn_recv状态，实际上这通常是在syn_table的request, 为了显示还没有通过三次握手的连接的状态，这时候request 还在syn table里，并且还没有属于自己的socket对象，linux 把这些信息写到了

/proc/net/tcp

而在tcp_seq_state_openreq 的情况下（就是 syn synack ack）的3个状态下都显示成tcp_syn_recv

而对established状态，并不需要server.accept，只要在accept queue里就已经变成状态established

到此这篇关于详解linux里的backlog参数的文章就介绍到这了。希望对大家的学习有所帮助，也希望大家多多支持。