TCP连接队列

Posted 2021-10-26 vector6_

TCP连接队列

通常情况下，一个并行的服务器会为每一个客户端分片一个新的进程或线程，并准备着处理下一个到来的连接请求，然而，在侦听服务器繁忙处理连接请求，或者被伪造的连接请求攻击时，TCP应当是如何处理的呢？

连接的两种状态

在被用于应用程序之前新的连接可能会处于下述两个状态：

1.连接尚未完成但是已经接收到SYN（即处于SYN_RCVD状态）。

2.连接已经完成了三次握手并且处于ESTABLISHED状态，但还未被应用程序接受。

linux对连接的限制

现代Linux内核中，使用连接队列来限制完全形成的等待处理的连接数目。主要规则有：

1.当一个连接请求到达（SYN报文段），检查参数 net.ipv4.tcp_max_syn_backlog(默认值1000)。如果处于SYN_RCVD状态的连接数目超过了这一阈值，进入的连接将会被拒绝。

2.每一个处于侦听状态下的节点都拥有一个固定长度的连接队列。其中的连接已经被TCP完全接受（即三次握手已经完成），但未被应用程序接受。这就是我们说的未完成连接(backlog)。backlog 的最大值 net.core.somaxconn，默认值为128。

backlog的数值指出了一个侦听节点中排队连接的最大数目，所有这些连接已经被TCP接受并等待应用程序接受。backlog不会对系统所允许的已经建立连接的最大数目以及并发服务器所能同时处理的客户端数目造成影响。

3.我们知道TCP连接位于传输层，所以只有直到接收到三次握手中的第3个报文段之后，与侦听节点相关的应用程序才会知道新的连接。

4.如果连接队列已没有空间可分配，TCP将会延迟对SYN做出响应，从而给应用程序一个跟上节奏的机会。Linux 内核对此场景的策略是在坚持在能力允许的范围内不忽略进入的连接。一种特殊的行为是如果系统控制变量 net.ipv4.tcp_abort_on_已被设定，新进入的连接会被重置报文段重新置位。（默认不不开启此功能，因为若客户端在握手期间收到RST，可能会误认为目标服务器不存在）。

正常的TCP机制是如果一台侦听服务器始终无法抽出时间来接受那些已经被TCP接受却超出队列保存上限的连接，那么，客户端的主动连接将会最终超时。即由于侦听节点的队列已满，服务器端的TCP忽略了该SYN报文段。客户端根据二进制指数退避机制重新传输了它的SYN报文段。

TCP服务器应用程序可以中断客户端的主动连接操作吗

在借助伯克利套接字实现的TCP中，当应用程序被告知一条连接已经到达时，TCP的三次握手过程已经完成。上述行为也意味着一个TCP服务器无法让一个客户端的主动打开操作失败。当一个新的客户端连接传达至服务器应用程序时，TCP的三次握手过程已经结束，而且客户端的主动打开操作已经成功完成。如果之后服务器检查客户端的IP与端口决定不提供相关服务，那它只能发送FIN关闭或发送RST重置这条连接。