TCP全连接/半连接队列

什么是半连接队列，全连接队列？

    Linux内核协议栈为一个tcp连接管理使用两个队列，一个是半链接队列（用来保存处于SYN_SENT和SYN_RECV状态的请求），一个是全连接队列（accpetd队列）（用来保存处于established状态，但是应用层没有调用accept取走的请求）。

• 在讲全连接和半连接之前，先来讲讲TCP连接基本概念：

TCP连接的基本概念：

三次握手：

    1、第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；

    2、第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

    3、第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

四次分手：

    1、客户端向服务器发送一个FIN为1 的TCP报文

    2、服务器返回给客户端一个确认ACK报文

    3、服务器同时发送一个FIN报文

    4、客户机回复ACK报文后（四次握手），连接结束。

好了，基本概念介绍完毕，下面看图说话：

（图片来源：http://www.cnxct.com/something-about-phpfpm-s-backlog/）

上图中可以看到两个蓝色的队列：syns queue, accept queue;

• syns queue（半连接队列) 是服务器收到客户端的 第一次握手请求SYN后，将连接加入到队列中，当收到客户端的ACK后，从队列中移出。

• accept queue（全连接队列）是服务器收到客户端ACK后，加入到队列中，在连接进行了accept处理后，从队列中移出。

这样应该对这两个queue的作用应该讲清楚了。下面引入新的问题，既然是一个队列，那自然是要有大小的吧。这两个queue的大小是多少呢？

• 全连接队列的大小取决于：min(tcp_max_syn_backlog, net.core.somaxconn)

• 半连接队列的大小取决于：max(64, tcp_max_syn_backlog)

全连接队列、半连接队列溢出很容易忽视，对于一些短连接应用（比如Nginx、PHP）更容易爆发。一旦溢出，Server端从cpu、线程状态看负载正常，但压力上不去。而Client端看来,请求耗时较高，但server端记录的服务响应又很短，同时客户端会不定期出现连接超时、socket 读写超时 的现象。

那如何应对队列溢出呢？

客户端调整思路

    对TCP连接失败，增加重试机制和超时时间

    启用长连接机制 (可减少连接环节开销,从而降低延时)

服务端调整思路

    修改内核参数，适当调整 net.core.somaxconn (调整全队列长度)

    修改内核参数，适当调整 tcp_max_syn_backlog (调整半队列长度)

黑客攻防——SYN洪水（SYN FLOOD）

    SYN攻击属于DOS攻击的一种，它利用TCP协议缺陷，通过发送大量的SYN请求，而不回复ACK，占用大量服务器的半连接队列资源，进而导致队列溢出，无法响应正常的连接请求，耗费CPU和内存资源。

    

    处理措施：调大somaxconn的值，调大tcp_max_syn_backlog，增大tcp半连接队列的长度，降低tcp_synack_retries的值，可以设成0，使得半连接可以快速的释放。开启防火墙，限制单ip的syn包的频率。如单个ip 3s内最多发送60个syn包。

完活，东西不多，也比较好理解，若有表述有误的欢迎大神留言指正。