listen()函数的第二个参数详解

首先声明：我个人是在CentOS 7平台中运行的所有

int listen(int sockfd, int backlog)

功能：listen函数会把sockfd的套接字标记为被动的监听listen状态，之后服务端与客户端通信的整个流程中sockfd只有listen和closed两种状态，第二个参数backlog代表等待队列的最大长度。（backlog这个参数后面会详细讲解）

注意：closed状态是假想的状态

客户端：

当connect到来的时候无论等待队列有没有空余地方在客户端眼里都是连接成功的，因为一开始调用connect函数SYN请求，服务端立刻给予客户端SYN＋ACK确认，客户端连接状态从SYN_SENT转换到ESTABLISHED之后再向服务端发ACK确认。也就是所谓的三次握手过程

服务端：

当客户端connect来到时，服务端进入SYN_RCVD状态并给予SYN＋ACK响应。当下次客户端完成三次握手，收到客户端的ACK时：如果队列中有空间，则服务端的连接也建立成功，否则服务端眼里没有成功。每建立成功一次，要往队列中放入刚才建立好的连接，也就是队列空间－1，服务端状态从SYN_RCVD变为ESTABLISHED，如果不成功还是原来的SYN_RCVD状态。当服务端调用accept成功时，又是队列空间＋1，从队列中拿走一个连接。

这里我在网上找了一张大体流程图方便大家理解：

三次握手过程：

我们这边写了一些客户端与服务端的多进程版本代码。

先让一个客户端连接起来，正常情况为：

然后我们把listen的第二个参数设置为1，并且把accept函数屏蔽掉，不让执行下去。这样保证迟早队列中会没有地方，导致有的连接不成功。

我一共开了4个客户端，但从上图中可以看到只有两个服务端是成功的，另外两个还在上一个状态中，但是所有的客户端都是成功的。所以说明最大队列个数是backlog＋1。

下面给你们分享我测试用的客户端和服务端代码：https://github.com/214058830/Network-programming/tree/master/Multi%20process%20TCP