简单理解TCP的三次握手及SYN Flood风险原因分析

TCP的三次握手

如上图所示，在TCP/IP协议中,TCP协议提供可靠的连接服务，采用三次握手建立一个连接：

1. 第一次握手：建立建立连接时，客户端主动发起请求，向服务端发送SYN包（SYN=1，seq=x，其中SYN为发起一个新连接的标志，seq为序号，发起方对数据的一个标志）,并等待服务器确认；
2. 第二次握手：服务器收到客户端发来的SYN包，并确认客户端确认接收到（ACK=1，ack=x+1，其中ACK=1表示确认序号有效，ack为确认序号）,同时自己也发送一个SYN包（SYN=1，seq=y），即向客户端发送SYN+ACK包，等待客户端回应；
3. 第三次握手：客户端接收到服务端发送来的SYN+ACK包，然后对服务端发送确认包（ACK=1，ack=y+1，seq=x+1）,当服务端接受到该确认包是，完成三次握手，客户端和服务端进入数据传输阶段。

TCP三次握手补充:SYN Flood风险

由于TCP三次握手存在SYN超时问题，即服务端收到客户端的SYN包时，回复SYN-ACK包的时候未收到ACK包确认（第三次握手服务端未收到客户端发送的确认包），服务端不断尝试向客户端发送SYN-ACK包并等待确认，直到超时（即在Linux下默认尝试五次，以1,2,4,8,16的间隔发送数据包，最后一次等待32，最终等待63秒才断开连接）。
恶意程序会向服务器发送SYN包，然后该程序会断开连接，通过耗尽服务器的SYN队列，让服务器不能处理正常的连接请求。

解决方案：

当SYN队列满时，TCP通过对源地址端口，目标地址端口，时间戳组成Sequence Number，简称SYN Cookie，对正常连接发送SYN Cookie,由于SYN Cookie不在队列中，即使队列满了，依然可以建立连接。

保活机制

保活机制，即建立连接后，客户端出现故障不能进行数据传输时，服务端向客户端发送保活探测报文，如果服务端未收到响应则继续发送，直到尝试次数达到保活探测数，若仍为收到响应着中断连接。