上次分析了TCP的三次握手连接和四次挥手断链过程,这里抛出几个关于TCP的问题:
1.TCP的洪水攻击的原理是什么和诊断处理?
2.TCP的滑动窗口机制原理和作用?
3.TCP如何是如何处理网络发送小包问题和提高传输效率的?
一、关于第一个问题,TCP洪水攻击只要是利用了TCP协议三次握手连接的缺陷。TCP洪水攻击做了大量的假冒IP去请求同步SYN被攻击服务器,被攻击的服务器向攻击者返回ACK确认,由于IP是假冒不存在的,所以不可能接收到服务器的ACK确认信号。导致被攻击服务器的链接状态大量处于SYN_RECV(半链接转态),并且大量超时重复ACK确认,堵塞TCP等待队列,资源耗尽,让正常的请求链接不进来。
诊断:对外的web服务响应漫长,ssh连接不上,CPU负载高。查询linux系统日志:,
# tail -f /var/log/messages
Apr 18 11:21:56 web5 kernel: possible SYN flooding on port 80. Sending cookies.
统计tcp连接状态数量:
# netstat -n |awk '/^tcp/ {++S[$NF]} END {for(a in S)print a,S[a] }'
TIME_WAIT 16855
CLOSE_WAIT 21
SYN_SENT 99
FIN_WAIT1 15
FIN_WAIT2 113
ESTABLISHED 8826SYN_RECV 48965
CLOSING 3
LAST_ACK 313
发现服务端链接状态大量处于SYN_RECV 半链接状态。
使用 netstat -n >aa.txt 保存现场证据,通过防火墙屏蔽部分ip访问。
可以在/etc/sysctl.conf中设置参数tcp_synack_retries=0来加快服务器的半链接状态回收速率,同时设置参数tcp_syn_max_backlog=32000 加大等待队列长度来应对部分洪水攻击。
二、TCP滑动窗口机制的作用主要有:1.TCP的流量控制:窗口大小随着链路动态变化;2.提供TCP可靠性:对发送的数据进行确认。
滑动窗口原理:
滑动窗口原理图
(1)滑动窗口大小:无需等待ACK可以发送的数据大小,上面的滑动窗口大小Windows_size=4000字节(4段);
(2)发送前4段,可以直接发送,无需等待ACK;
(3)收到一个ACK后,滑动窗口向后移动,继续发送第5段数据;
(4)操作系统内核为了维护这个滑动窗口,需要开辟发送缓冲区来记录当前还有哪些数据没有应答,只有应答的数据才会从缓冲区中删除;
(5)滑动窗口越大,TCP传输的吞吐量越大;
(6)滑动窗口是建立在"重发确认"机制上的,发送窗口只有收到对端对于本段发送窗口内字节的ACK确认,才会移动发送窗口的左边界。
三、Nagle算法的基本定义是任意时刻,最多只能有一个未被确认的小段。 所谓“小段”,指的是小于MSS尺寸的数据块,所谓“未被确认”,是指一个数据块发送出去后,没有收到对方发送的ACK确认该数据已收到。这样小包数据会先发送到缓存区里面,等到满足MSS尺寸,才发送出去,减少网络带宽损失。
还可以开通delayAck延迟机制,接收端不是一接收到数据就马上回复ACK确认。而是启动一个定时器,当定时器超时时看是否有数据要发送,如果有数据要发送给Client端,顺便削带ACK,如果没有直接回复ACK。