TCP/IP(六)TCP的连接管理(三)半连接

一  半连接和全连接

内容参考小林coding

说明： 普通'中小'厂不会问的这么'深',这么'细',但是当'性能调优'阶段必须掌握'原理'

①  内容提纲

②  概念

说明： '半连接'只是一个'中间'状态

②  图谱

二  半连接

①  查看 TCP 半连接队列长度

root '用户' 执行  --> netstat -antp | grep SYN_RECV | wc -l

说明： 系统'不繁忙'的话一般结果是'0'

②   增大 TCP 半连接队列

nginx TCP backlog 分析优化和性能相关经验汇总

③   模拟 TCP 半连接队列溢出场景

DDOS概念

④  被ddos攻击时现象

⑤  使用 hping3 工具模拟 SYN 攻击

背景： 本次'模拟实验'假定是'没有'开启 tcp_syncookies

步骤'1'： Centos7.7通过'epel'源安装hping3 '仿真'工具

步骤'2': 客户端使用'hping3'工具'模拟'SYN攻击

⑥  服务端观察

观察1： 此时'半连接'队列的大小

观察'2'： 通过 netstat -s 观察'半连接队列溢出'的情况,也即'溢出 drop'了多少

netstat -s | grep "SYNs to LISTEN"

推荐： watch '持续' 观察

隔'几秒'执行几次,如果有'上升'的趋势,说明当前存在'半连接队列溢出'的现象

⑦  哪些因素影响半连接队列的大小  探究1

纠正'误区'1： tcp_max_syn_backlog '不是' 半连接队列大小

内核 tcp_ipv4.c 代码中 TCP 半连接队列溢出的处理逻辑

强调： 以下'3'种场景触发'都'会'SYN'报文丢弃

 Linux '2.6.32' 内核版本, 'max_syn_backlog'、'somaxconn'、'backlog' 三者的关系

⑧  处于 SYN_RECV 状态的最大个数不是理论值 max_qlen_log

⑨  原因探究

说明： 该探究接上'⑧'

根据'前面的源码'分析,我们可以计算出'半连接队列' max_qlen_log 的最大值为 '256'

操作1： 客户端执行 hping3 发起 'SYN' 攻击

hping3 -S -p 8080 --flood 192.168.3.200

操作2： 服务端执行'如下命令'查看处于 'SYN_RECV' 状态的'最大'个数

netstat -antp | grep SYN_RECV | wc -l

分析'条件3'产生'193'的原因

'小结'

⑩  如果 SYN 半连接队列已满,只能丢弃连接吗?

内核参数： /proc/sys/net/ipv4/tcp_syncookies  '0'、'1'、'2' 含义

'开启' syncookies 功能就可以在'不使用 SYN 半连接队列'的情况下'成功'建立连接

三   如何防御 SYN 攻击?

①  什么是半连接的SYN攻击

DDOS攻击概念

②  半连接和全连接队列正常工作流程

Linux 内核的 SYN 队列 '半连接队列'与 Accpet 队列'全连接队列' 是'如何'工作的

③  避免 SYN 攻击四种方式

方式'1'： 调大 netdev_max_backlog

备注： 这个'基本'没有'听说过',也'未'经验证,先做'记录'吧

方式'2'： 增大 TCP '半连接'队列

条件： '不开启' net.ipv4.tcp_syncookies前提下

具体细节见上

方式'3'： '开启' net.ipv4.tcp_syncookies

方式'4'： 减少 'SYN+ACK' 重传次数

内核参数： tcp_synack_retries

④   答疑解惑

思考： 'syncookies 1 启用'后就不需要半链接了？那'请求的数据'会存在哪里？