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的大小是多少呢?

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

那如何应对队列溢出呢?

客户端调整思路

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

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

服务端调整思路

修改内核参数,适当调整 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包。

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

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20180705G0NYL000?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券