曾经有人问我套接字编程中listen
的第二个参数backlog
是什么意思?多大的值合适?我不假思索地回答它表示服务器能够接受的并发请求的最大值。然而事实真的是这样的吗?
TCP
经过三次握手创建链接的过程应该都不陌生了。从服务器的角度看,它分为如下几步html
TCP
状态设置为LISTEN
状态,开启监听客户端的链接请求SYN
报文后,TCP
状态切换为SYN RECEIVED
,并发送SYN ACK
报文ACK
报文后,TCP
三次握手完成,状态切换为ESTABLISHED
在Unix
系统中,开启监听是经过listen
完成。linux
int listen(int sockfd, int backlog)
listen
有两个参数,第一个参数sockfd
表示要设置的套接字,本文主要关注的是其第二个参数backlog
;git
<Unix 网络编程>将其描述为已完成的链接队列(ESTABLISHED
)与未完成链接队列(SYN_RCVD
)之和的上限。编程
通常咱们将ESTABLISHED
状态的链接称为全链接,而将SYN_RCVD
状态的链接称为半链接ubuntu
当服务器收到一个SYN
后,它建立一个子链接加入到SYN_RCVD
队列。在收到ACK
后,它将这个子链接移动到ESTABLISHED
队列。最后当用户调用accept()
时,会将链接从ESTABLISHED
队列取出。小程序
listen
只是posix
标准,不是TCP
的标准!不是TCP
标准就意味着不一样的内核能够有本身独立的实现服务器
POSIX是这么说的:cookie
The
backlog
argument provides a hint to the implementation which the implementation shall use to limit the number of outstanding connections in the socket's listen queue.
Linux
是什么行为呢 ? 查看listen
的man page
网络
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.
什么意思呢?就是说的在Linux 2.2
之后, backlog
只限制完成了三次握手,处于ESTABLISHED
状态等待accept
的子链接的数目了。并发
真的是这样吗?因而我决定抄一个小程序验证一下:
服务器监听50001
端口,而且设置backlog = 4
。注意,我为了将队列塞满,没有调用accept
。
#include <stdio.h> #include <unistd.h> #include <string.h> #include <sys/socket.h> #include <netinet/in.h> #define BACKLOG 4 int main(int argc, char **argv) { int listenfd; int connfd; struct sockaddr_in servaddr; listenfd = socket(PF_INET, SOCK_STREAM, 0); bzero(&servaddr, sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_addr.s_addr = htonl(INADDR_ANY); servaddr.sin_port = htons(50001); bind(listenfd, (struct sockaddr *)&servaddr, sizeof(servaddr)); listen(listenfd, BACKLOG); while(1) { sleep(1); } return 0; }
客户端的代码
#include <stdio.h> #include <string.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <unistd.h> int main(int argc, char **argv) { int sockfd; struct sockaddr_in servaddr; sockfd = socket(PF_INET, SOCK_STREAM, 0); bzero(&servaddr, sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_port = htons(50001); servaddr.sin_addr.s_addr = inet_addr("127.0.0.1"); if (0 != connect(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr))) { printf("connect failed!\n"); } else { printf("connect succeed!\n"); } sleep(30); return 1; }
为了排除syncookie
的干扰,我首先关闭了syncookie
功能
echo 0 > /proc/sys/net/ipv4/tcp_syncookies
因为我设置的backlog = 4
而且服务器始终不会accept
。所以预期会创建 4 个全链接, 但实际倒是
root@ubuntu-1:/home/user1/workspace/client# ./client & [1] 12798 root@ubuntu-1:/home/user1/workspace/client# connect succeed! ./client & [2] 12799 root@ubuntu-1:/home/user1/workspace/client# connect succeed! ./client & [3] 12800 root@ubuntu-1:/home/user1/workspace/client# connect succeed! ./client & [4] 12801 root@ubuntu-1:/home/user1/workspace/client# connect succeed! ./client & [5] 12802 root@ubuntu-1:/home/user1/workspace/client# connect succeed! ./client & [6] 12803 root@ubuntu-1:/home/user1/workspace/client# connect succeed! ./client & [7] 12804 root@ubuntu-1:/home/user1/workspace/client# connect succeed! ./client & [8] 12805 root@ubuntu-1:/home/user1/workspace/client# connect succeed! ./client & [9] 12806 root@ubuntu-1:/home/user1/workspace/client# connect succeed! ./client & [10] 12807 root@ubuntu-1:/home/user1/workspace/client# connect failed!
看!客户器居然显示成功创建了 9 次链接!
用netstat
看看TCP
链接状态
> netstat -t Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 localhost:50001 localhost:55792 ESTABLISHED tcp 0 0 localhost:55792 localhost:50001 ESTABLISHED tcp 0 0 localhost:55798 localhost:50001 ESTABLISHED tcp 0 1 localhost:55806 localhost:50001 SYN_SENT tcp 0 0 localhost:50001 localhost:55784 ESTABLISHED tcp 0 0 localhost:50001 localhost:55794 SYN_RECV tcp 0 0 localhost:55786 localhost:50001 ESTABLISHED tcp 0 0 localhost:55800 localhost:50001 ESTABLISHED tcp 0 0 localhost:50001 localhost:55786 ESTABLISHED tcp 0 0 localhost:50001 localhost:55800 SYN_RECV tcp 0 0 localhost:55784 localhost:50001 ESTABLISHED tcp 0 0 localhost:50001 localhost:55796 SYN_RECV tcp 0 0 localhost:50001 localhost:55788 ESTABLISHED tcp 0 0 localhost:55794 localhost:50001 ESTABLISHED tcp 0 0 localhost:55788 localhost:50001 ESTABLISHED tcp 0 0 localhost:50001 localhost:55790 ESTABLISHED tcp 0 0 localhost:50001 localhost:55798 SYN_RECV tcp 0 0 localhost:55790 localhost:50001 ESTABLISHED tcp 0 0 localhost:55796 localhost:50001 ESTABLISHED
整理一下就是下面这样
从上面能够看出,一共有5条链接对是ESTABLISHED<->ESTABLISHED
链接, 但还有4条链接对是SYN_RECV<->ESTABLISHED
链接, 这表示对客户端三次握手已经完成了,但对服务器尚未! 回顾一下TCP
三次握手的过程,形成这种链接对缘由只有多是服务器将客户端最后发送的握手ACK
被丢弃了!
还有一个问题,我明明设置的backlog
的值是 4,可为何还能创建5个链接 ?!
我实验用的机器内核是
4.4.0
前面提到过已完成链接队列和未完成链接队列这两个概念, Linux
有这两个队列吗 ? Linux
既有又没有! 说有是由于内核中能够获得两种链接各自的长度; 说没有是由于 Linux
只有已完成链接队列实际存在, 而未完成链接队列只有长度的记录!
每个LISTEN
状态的套接字都有一个struct inet_connection_sock
结构, 其中的accept_queue
从名字上也能够看出就是已完成三次握手的子链接队列.只是这个结构里还记录了半链接
请求的长度!
struct inet_connection_sock { // code omitted struct request_sock_queue icsk_accept_queue; // code omitted } struct request_sock_queue { // code omitted atomic_t qlen; // 半链接的长度 atomic_t young; // 通常状况, 这个值 = qlen struct request_sock *rskq_accept_head; // 已完成链接的队列头 struct request_sock *rskq_accept_tail; // 已完成链接的队列尾 // code omitted };
因此通常状况下链接创建时,服务端的变化过程是这样的:
SYN
报文, qlen
++,young
++ACK
报文, 三次握手完成,将链接加入accept
队列,qlen
--,young
--accept
,将链接从accept
取出.再来看内核收到SYN
握手报文时的处理, 因为我关闭了syncookie
,因此一旦知足了下面代码中的两个条件之一就会丢弃报文
int tcp_conn_request(struct request_sock_ops *rsk_ops, const struct tcp_request_sock_ops *af_ops, struct sock *sk, struct sk_buff *skb) if ((net->ipv4.sysctl_tcp_syncookies == 2 || inet_csk_reqsk_queue_is_full(sk)) && !isn) { // 条件1: 半链接 >= backlog want_cookie = tcp_syn_flood_action(sk, skb, rsk_ops->slab_name); if (!want_cookie) goto drop; } if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) { // 条件2: 全链接 > backlog 而且 半链接 > 1 NET_INC_STATS(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS); goto drop; } // code omitted
下面是收到ACK
握手报文时的处理
struct sock *tcp_v4_syn_recv_sock(const struct sock *sk, struct sk_buff *skb, struct request_sock *req, struct dst_entry *dst, struct request_sock *req_unhash, bool *own_req) { // code omitted if (sk_acceptq_is_full(sk)) // 全链接 > backlog, 就丢弃 goto exit_overflow; newsk = tcp_create_openreq_child(sk, req, skb); // 建立子套接字了 // code omitted }
因此这样就能够解释实验现象了!
backlog
= 4, 半链接数目 = 0 sk_acceptq_is_full
的判断条件是>
而不是>=
,因此依然能够创建全链接backlog
,因此仍是能够继续回复SYNACK
,但收到ACK
后已经不能再建立子套接字了,因此TCP
状态依然为SYN_RECV
.同时半链接的数目也增长到backlog
.而对于客户端,它既然能收到SYNACK
握手报文,所以它能够将TCP
状态变为ESTABLISHED
,backlog
,所以,这个SYN
报文会被丢弃.从以上的现象和分析中,我认为内核存在如下问题
accept
队列是否满的判断用>=
比>
更合适, 这样才能体现backlog
的做用accept
队列满了,就应该拒绝半链接了,由于即便半链接握手完成,也没法加入accept
队列,不然就会出现SYN_RECV--ESTABLISHED
这样状态的链接对!这样的链接是不能进行数据传输的!问题2
在16年的补丁中已经修改了! 因此若是你在更新版本的内核中进行相同的实验, 会发现客户端只能链接成功5次了,固然这也要先关闭syncookie
但问题1
尚未修改! 若是之后修改了,我也不会意外
(完)