TCP3次握手和backlog溢出

TCP3次握手，实际上可分为4步：

1 客户端发起connect()，发送SYN j

2 服务器从SYN queue中建立条目，响应SYN k, ACK J+1

3 客户端connect()成功返回，响应ACK K+1

4 服务器将socket从SYN queue移入accept queue，accept()成功返回

注：SYN/FIN各占一个序列号，ACK/RST不占序列号

SYN queue长度由tcp_max_syn_backlog指定，accept queue则由net.core.somaxconn决定，listen(fd, backlog)的backlog上限由somaxconn决定；

Backlog解释

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 the tcp_max_syn_backlog sysctl.

When syncookies are enabled there is no logical maximum length and this sysctl setting is ignored.

If the socket is of type AF_INET, and the backlog argument is greater than the constant SOMAXCONN (128 default), it is silently truncated to SOMAXCONN.

客户端connect()返回不代表TCP连接建立成功，有可能此时服务器accept queue已满，OS会直接丢弃后续ACK请求；

客户端以为连接已建立，开始后续调用(譬如send)等待直至超时；

服务器则等待ACK超时，会重传SYN k, ACK J+1给客户端(重传次数受限net.ipv4.tcp_synack_retries)；

注：accept queue溢出，即便SYN queue没有溢出，新连接请求的SYN也可能被drop

Accept backlog is full. If we have already queued enough of warm entries in SYN queue, drop request. It is better than clogging SYN queue with openreqs with exponentially increasing timeout.

clog:阻碍；堵塞。

exponential： 指数的，幂数的；越来越快的。

如何查看accept queue溢出

Netstat -s | grep LISTEN 返回***SYNS to LISTEN sockets ignored

以下案例全部来自维信公众号”基础架构快报”的”TCP三次握手之backlog”，感兴趣的可以加微信阅读原文。

案例1

Nginx作为7层反向代理，客户端HTTP请求 – NGINX – 透明代理，透明代理接口存在大量慢请求；

思路

抓包，客户端同nginx通信，nginx立即返回ACK(1ms)，但是3s后才返回响应数据；

Nginx同后端通信，发送SYN请求等待3s后端才响应；

结论

Backlog设置过小，导致accept queue溢出，SYN被丢弃导致3s重传；

将backlog从50增加到512，somaxconn=512；

案例2

Testserver随机生成RAR/ZIP文件，testclient访问testserver获取生成文件，所有调用采用block方式；

运行一段时间后程序永久阻塞，strace发现testclient阻塞在recvmsg；

思路

抓包观察3次握手协议，服务器返回SYN+ACK，客户端响应ACK，可服务器再次发送同样的SYN+ACK；

客户端响应的ACK丢包，而net.ipv4.tcp_synack_retries = 1；

结论

三次握手最后一步失败，server保持SYN_RECV状态等待接收ACK，client发送ACK状态变为ESTABLISHED，其认为connect()成功故接着调用recvmsg()；

Syn+ack被设置为只重传一次，若这次重传仍失败，则客户端永久阻塞；

其他案例1

Backlog过大，连接积压在accept queue，nginx由于连接超时而断开，PHP accept返回时连接已被客户端close，故报告PHP write Broken pipe；

其他案例2

Backlog过小，accept queue溢出，握手第3步的ACK被丢弃，但client认为连接成功并发送数据，造成所谓慢请求；


http://jaseywang.me/2014/07/20/tcp-queue-%E7%9A%84%E4%B8%80%E4%BA%9B%E9%97%AE%E9%A2%98/

http://blog.itpub.net/15480802/viewspace-1399303/