深入探索 Linux listen() 函数 backlog 的含义

灰太狼 2022-01-05 07:07 234阅读 0赞

> 转载至：[https://blog.csdn.net/yangbodong22011/article/details/60399728][https_blog.csdn.net_yangbodong22011_article_details_60399728]

## 1：listen()回顾以及问题引入 ##

`listen()`函数是网络编程中用来**使服务器端开始监听端口**的系统调用，首先来回顾下`listen()`函数的定义：

![这里写图片描述][20170305011015638]

有关于第二个参数含义的问题网上有好几种说法，我总结了下主要有这么3种：

1.  Kernel会为`LISTEN状态`的socket维护**一个队列**，其中存放`SYN RECEIVED`和`ESTABLISHED`状态的套接字，`backlog`就是这个队列的大小。
2.  Kernel会为`LISTEN状态`的socket维护**两个队列**，一个是`SYN RECEIVED`状态，另一个是`ESTABLISHED`状态，而`backlog`就是这两个队列的大小之和。
3.  第三种和第二种模型一样，但是`backlog`是队列`ESTABLISHED`的长度。

有关上面说的两个状态`SYN RECEIVED`状态和`ESTABLISHED`状态，是`TCP三次握手`过程中的状态转化，具体可以参考下面的图（在新窗口打开图片）：

![这里写图片描述][20170305084830550]

## 2：正确的解释 ##

那上面三种说法到底哪个是正确的呢？我下面的说法翻译自这个链接：

### [http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html][http_veithen.github.io_2014_01_01_how-tcp-backlog-works-in-linux.html] ###

下面我翻译下作者的文章：

> When an application puts a socket into LISTEN state using the listen syscall, it needs to specify a backlog for that socket. The backlog is usually described as the limit for the queue of incoming connections.

当一个应用使用`listen`系统调用让`socket`进入`LISTEN`状态时，它需要为该套接字指定一个`backlog`。`backlog`通常被描述为连接队列的限制。

> Because of the 3-way handshake used by TCP, an incoming connection goes through an intermediate state SYN RECEIVED before it reaches the ESTABLISHED state and can be returned by the accept syscall to the application (see the part of the TCP state diagram reproduced above). This means that a TCP/IP stack has two options to implement the backlog queue for a socket in LISTEN state：

由于TCP使用的3次握手，连接在到达`ESTABLISHED`状态之前经历中间状态`SYN RECEIVED`，并且可以由`accept`系统调用返回到应用程序。这意味着`TCP / IP`堆栈有两个选择来为`LISTEN`状态的套接字实现`backlog`队列：

（备注：一种就是两种状态在一个队列，一种是分别在一个队列）

> 1 : The implementation uses a single queue, the size of which is determined by the backlog argument of the listen syscall. When a SYN packet is received, it sends back a SYN/ACK packet and adds the connection to the queue. When the corresponding ACK is received, the connection changes its state to ESTABLISHED and becomes eligible for handover to the application. This means that the queue can contain connections in two different state: SYN RECEIVED and ESTABLISHED. Only connections in the latter state can be returned to the application by the accept syscall.

1：使用单个队列实现，其大小由`listen syscall`的`backlog`参数确定。 当收到`SYN`数据包时，它发送回`SYN/ACK`数据包，并将连接添加到队列。 当接收到相应的`ACK`时，连接将其状态改变为已建立。 这意味着队列可以包含两种不同状态的连接：`SYN RECEIVED`和`ESTABLISHED`。 只有处于后一状态的连接才能通过`accept syscall`返回给应用程序。

> 2 : The implementation uses two queues, a SYN queue (or incomplete connection queue) and an accept queue (or complete connection queue). Connections in state SYN RECEIVED are added to the SYN queue and later moved to the accept queue when their state changes to ESTABLISHED, i.e. when the ACK packet in the 3-way handshake is received. As the name implies, the accept call is then implemented simply to consume connections from the accept queue. In this case, the backlog argument of the listen syscall determines the size of the accept queue.

2 ： 使用`两个队列`实现，一个`SYN`队列（或半连接队列）和一个`accept`队列（或完整的连接队列）。 处于`SYN RECEIVED`状态的连接被添加到`SYN`队列，并且当它们的状态改变为`ESTABLISHED`时，即当接收到3次握手中的`ACK`分组时，将它们移动到`accept`队列。 显而易见，`accept`系统调用只是简单地从完成队列中取出连接。 在这种情况下，`listen syscall`的backlog参数表示`完成队列`的大小。

> Historically, BSD derived TCP implementations use the first approach. That choice implies that when the maximum backlog is reached, the system will no longer send back SYN/ACK packets in response to SYN packets. Usually the TCP implementation will simply drop the SYN packet (instead of responding with a RST packet) so that the client will retry.

历史上，[BSD][] 派生系统实现的`TCP`使用第一种方法。 该选择意味着当达到最大`backlog`时，系统将不再响应于`SYN分组`发送回`SYN/ACK`分组。 通常，`TCP`的实现将简单地丢弃`SYN分组`，使得客户端重试。

> On Linux, things are different, as mentioned in the man page of the listen syscall:  
> The behavior of the backlog argument on TCP sockets changed with Linux 2.2. Now it specifies the queue length for completely established sockets waiting to be accepted, instead of the number of incomplete connection requests. The maximum length of the queue for incomplete sockets can be set using /proc/sys/net/ipv4/tcp\_max\_syn\_backlog.

在**Linux**上，是和上面不同的。如在`listen`系统调用的手册中所提到的：  
在Linux内核2.2之后，`socket backlog`参数的形为改变了，**现在它指等待`accept`的`完全建立`的套接字的队列长度**，而不是不完全连接请求的数量。 **不完全连接**的长度可以使用`/proc/sys/net/ipv4/tcp_max_syn_backlog`设置。

> This means that current Linux versions use the second option with two distinct queues: a SYN queue with a size specified by a system wide setting and an accept queue with a size specified by the application.

这意味着当前Linux版本使用上面第二种说法，有两个队列：具有由系统范围设置指定的大小的`SYN队列` 和 应用程序（也就是backlog参数）指定的`accept`队列。

OK，说到这里，相信backlog含义已经解释的非常清楚了，下面我们用实验验证下这种说法：

## 3：实验验证 ##

验证环境：

> RedHat 7  
> Linux version 3.10.0-514.el7.x86\_64

验证思路：

1：客户端开多个线程分别创建socket去连接服务端。  
2：服务端在`listen`之后，不去调用`accept`，也就是不会从`已完成队列`中取走`socket`连接。  
3：观察结果，到底服务端会怎么样？处于`ESTABLISHED`状态的套接字个数是不是就是`backlog`参数指定的大小呢？

我们定义`backlog`的大小为`5`:

> \# define BACKLOG 5

看下我系统上默认的`SYN`队列大小：

![这里写图片描述][20170305100714800]

也就是我现在两个队列的大小分别是 ：

`SYN`队列大小：256  
`ACCEPT`队列大小：5

看看我们的服务端程序 `server.c` :

#include<stdio.h>
    #include<sys/types.h>
    #include<sys/socket.h>
    #include<sys/time.h>
    #include<netinet/in.h>
    #include<arpa/inet.h>
    #include<errno.h>
    #include<stdlib.h>
    #include<string.h>
    #include<unistd.h>
    
    #define PORT 8888 //端口号
    #define BACKLOG 5 //BACKLOG大小
    
    void my_err(const char* msg,int line) 
    { 
        fprintf(stderr,"line:%d",line);
        perror(msg);
    }
    
    
    int main(int argc,char *argv[])
    { 
        int conn_len;
        int sock_fd,conn_fd;
        struct sockaddr_in serv_addr,conn_addr;
    
    
        if((sock_fd = socket(AF_INET,SOCK_STREAM,0)) == -1) {  
            my_err("socket",__LINE__); 
            exit(1);
        }
    
        memset(&serv_addr,0,sizeof(struct sockaddr_in));
        serv_addr.sin_family = AF_INET;
        serv_addr.sin_port = htons(PORT);
        serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
    
    
        if(bind(sock_fd,(struct sockaddr *)&serv_addr,sizeof(struct sockaddr_in)) == -1) { 
            my_err("bind",__LINE__);
            exit(1);
        }
    
        if(listen(sock_fd,BACKLOG) == -1) { 
            my_err("sock",__LINE__);
            exit(1);
        }
    
        conn_len = sizeof(struct sockaddr_in);
    
    
        sleep(10);                  //sleep 10s之后接受一个连接
        printf("I will accept one\n");
        accept(sock_fd,(struct sockaddr *)&conn_addr,(socklen_t *)&conn_len);
    
        sleep(10);                  //同理，再接受一个
        printf("I will accept one\n");
        accept(sock_fd,(struct sockaddr *)&conn_addr,(socklen_t *)&conn_len);
    
        sleep(10);                  //同理，再次接受一个
        printf("I will accept one\n");
        accept(sock_fd,(struct sockaddr *)&conn_addr,(socklen_t *)&conn_len);
    
    
        while(1) { }  //之后进入while循环,不释放连接
        return 0;
    }

客户端程序 `client.c`：

#include<stdio.h>
    #include<sys/types.h>
    #include<sys/socket.h>
    #include<netinet/in.h>
    #include<arpa/inet.h>
    #include<string.h>
    #include<strings.h>
    #include<stdlib.h>
    #include<unistd.h>
    #include<pthread.h>
    
    #define PORT 8888
    #define thread_num 10 //定义创建的线程数量
    
    struct sockaddr_in serv_addr;
    
    void *func() 
    { 
        int conn_fd;
        conn_fd = socket(AF_INET,SOCK_STREAM,0);
        printf("conn_fd : %d\n",conn_fd);
    
        if( connect(conn_fd,(struct sockaddr *)&serv_addr,sizeof(struct sockaddr_in)) == -1) { 
            printf("connect error\n");
        }
    
        while(1) { }
    }
    
    int main(int argc,char *argv[])
    { 
        memset(&serv_addr,0,sizeof(struct sockaddr_in));
        serv_addr.sin_family = AF_INET;
        serv_addr.sin_port = htons(PORT);
        inet_aton("192.168.30.155",(struct in_addr *)&serv_addr.sin_addr); //此IP是局域网中的另一台主机
        int retval;
    
        //创建线程并且等待线程完成
        pthread_t pid[thread_num];
        for(int i = 0 ; i < thread_num; ++i)
        { 
            pthread_create(&pid[i],NULL,&func,NULL);
    
        }
    
        for(int i = 0 ; i < thread_num; ++i)
        { 
            pthread_join(pid[i],(void*)&retval);
        }
    
        return 0;
    }

编译运行程序，并用`netstat`命令监控服务端`8888`端口的情况：

> $ gcc server.c -o server  
> $ gcc client.c -o client -lpthread -std=c99  
> watch -n 1 “netstat -natp | grep 8888” //root执行  
> //watch -n 1 表示每秒显示一次引号中命令的结果  
> //netstat n: 以数字化显示 a:all t:tcp p:显示pid和进程名字 然后我们grep端口号8888就行了。  
> $ ./server  
> $ ./client

结果如下：

首先是`watch`的情况：

![这里写图片描述][20170305105458725]

*  因为我们客户端用10个线程去连接服务器，因此服务器上有10条连接。
 *  第一行的`./server`状态是`LISTEN`，这是服务器进程。
 *  倒数第三行的`./server`是服务器已经执行了一次`accept`。
 *  6条`ESTABLISHED`状态比我们的`BACKLOG`参数`5`大1。
 *  剩余的`SYN_RECV`状态即使收到了`客户端第三次握手回应的ACK`也不能成为`ESTABLISHED`状态，因为`BACKLOG`队列中没有位置。

然后过了`10s`左右，等到服务器执行了第二个`accept`之后，服务器情况如下，它执行了第二个`accept`：

![这里写图片描述][20170305110617159]

此时`watch`监控的画面如下:

![这里写图片描述][20170305110659597]

*  和上面相比，服务器再次`accept`之后，多了一条`./server`的连接。
 *  有一条连接从`SYN_RECV`状态转换到了`ESTABLISHED`状态，原因是`accept`函数从`BACKlOG`完成的队列中取出了一个连接，接着有空间之后，`SYN`队列的一个链接就可以转换成`ESTABLISHED`状态然后放入`BACKlOG`完成队列了。

好了，分析到这里，有关`BACKLOG`的问题已经解决了，至于继续上面的实验将`backlog`的参数调大会怎么样呢？我试过了，就是`ESTABLISHED`状态的数量也会增大，值会是`BACKLOG+1`，**至于为什么是`BACKLOG+1`呢？？？**我也没有搞懂。欢迎指教。

当然，还有别的有意思的问题是 : 如果`ESTABLISHED`队列满了，可是有连接需要从`SYN`队列转移过来时会发生什么？

请参考：[如果ESTABLISHED队列满了，可是有连接需要从SYN队列转移][ESTABLISHED_SYN]

[https_blog.csdn.net_yangbodong22011_article_details_60399728]: https://blog.csdn.net/yangbodong22011/article/details/60399728
[20170305011015638]: /images/20211229/5196b2d4d1a24382b1a3707bbeb30a32.png
[20170305084830550]: /images/20211229/c77aa1e60edf4e3d919a42247efa7dc1.png
[http_veithen.github.io_2014_01_01_how-tcp-backlog-works-in-linux.html]: http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html
[BSD]: http://baike.baidu.com/item/BSD/3794498
[20170305100714800]: /images/20211229/00e8eb41670247618d3a439380a3d568.png
[20170305105458725]: /images/20211229/50dc98bfd8d94aab88559b607926479e.png
[20170305110617159]: /images/20211229/869ba60690d0456b9f632f5784ec58d6.png
[20170305110659597]: /images/20211229/1681b5d3700c4ab9b1373874a1ea9039.png
[ESTABLISHED_SYN]: https://blog.csdn.net/zanda_/article/details/93378808