首先我们必须明白,处于“LISTENING”状态的TCP socket,有两个独立的队列:
这两个术语有时也被称为“reqsk_queue”,“ACK backlog”,“listen backlog”,甚至“TCP backlog”,但是这篇文章中我们使用上面两个术语以免造成混淆。 SYN队列SYN队列存储了收到SYN包的连接(对应内核代码的结构体:struct inet_request_sock)。它的职责是回复SYN+ACK包,并且在没有收到ACK包时重传,直到超时。在Linux下,重传的次数为: 1 $ sysctl net.ipv4.tcp_synack_retries 2 net.ipv4.tcp_synack_retries = 5 文档中对tcp_synack_retries的描述如下: 1 tcp_synack_retries - int整型 2 3 对于一个被动TCP连接,重传SYNACKs的次数。该值不能超过255。 4 默认值为5,如果初始RTO是1秒,那么对应的最后一次重传是31秒。 5 对应的最后一次超时是63秒之后。 发送完SYN+ACK之后,SYN队列等待从客户端发出的ACK包(也即三次握手的最后一个包)。当收到ACK包时,首先找到对应的SYN队列,再在对应的SYN队列中检查相关的数据看是否匹配,如果匹配,内核将该连接相关的数据从SYN队列中移除,创建一个完整的连接(对应内核代码的结构体:struct inet_sock),并将这个连接加入Accept队列。 Accept队列Accept队列中存放的是已建立好的连接,也即等待被上层应用程序取走的连接。当进程调用accept(),这个socket从队列中取出,传递给上层应用程序。 这就是Linux处理SYN包的一个简单描述。顺便一提,当socket开启了 队列大小限制应用程序通过调用系统调用listen(2),传入backlog参数,来设置SYN队列和Accept队列的最大大小。比如下面这样,将SYN队列和Accept队列的最大大小同时设置为1024: 1 listen(sfd, 1024) 注意,在4.3版本之前的内核,SYN队列的大小是用另一种方式计算。 SYN队列的最大大小以前是用 1 $ sysctl net.core.somaxconn 2 net.core.somaxconn = 16384 队列设置为多大合适知道了上面这些信息后,你可能会问,队列设置为多大合适?队列设置为多大合适 答案是:看情况。对于大多数的TCP服务来说,这并不太重要。比如,Go语言1.11版本之前,并没有提供设置队列大小的方法。 尽管如此,也存在一些合理的原因,需要增大队列的大小:
但是,将backlog设置的过大也会带来不好的影响:
linux下,如果想查看SYN队列的当前状态,我们可以使用ss命令来查询 1 $ ss -n state syn-recv sport = :80 | wc -l 2 119 3 $ ss -n state syn-recv sport = :443 | wc -l 4 78 假如程序调用accept()不够快?还可以通过我们的SystemTap脚本来观察这个数据:resq.stp 如果程序调用accept()不够快会发生什么呢?
发生这种情况时,我们只能寄希望于程序的处理性能稍后能恢复正常,客户端重新发送被服务端丢弃的包。 内核的这种表现对于大部分服务来说是可接受的。顺便一提,可以通过调整 可以通过查看nstat的计数来观察Accept队列溢出的状态: 1 $ nstat -az TcpExtListenDrops 2 TcpExtListenDrops 49199 0.0 但是这是一个全局的计数。观察起来不够直观,比如有时我们观察到它在增长,但是所有的服务程序看起来都是正常的。此时我们可以使用ss命令来观察单个监听端口的Accept队列大小: 1 $ ss -plnt sport = :6443|cat 2 State Recv-Q Send-Q Local Address:Port Peer Address:Port 3 LISTEN 0 1024 *:6443 *:*
这是因为我们的程序只是周期性的短暂卡住不处理新的连接,而非永久性的不处理,过段时间程序又恢复了正常。这种情况下,用ss命令比较难观察这种现象,因此我们写了一个SystemTap脚本,它会hook进内核,把被丢弃的SYN包打印出来: $ sudo stap -v acceptq.stp time (us) acceptq qmax local addr remote_addr 1495634198449075 1025 1024 0.0.0.0:6443 10.0.1.92:28585 1495634198449253 1025 1024 0.0.0.0:6443 10.0.1.92:50500 1495634198450062 1025 1024 0.0.0.0:6443 10.0.1.92:65434 ... 通过上面的操作,可以观察到哪些SYN包被ListenDrops影响了。从而我们也就可以知道哪些程序在丢失连接。 |
|