weblogic多次连接后tcp服务堵塞_TCP的几个问题，你知道么？

上次分析了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。