TCP三次握手

• 第一次握手：客户端发送连接请求报文，SYN=1，选择一个初始序列号seq=x，此时客户端处于SYN_SEND状态
• 第二次握手：服务端收到客户端的请求，如果同意建立连接，会向客户端发送确认报文，SYN=1，ACK=1，确认号为x+1，同时也会发送一个初始序列号seq=y，此时服务端处于SYN_RECV状态
• 第三次握手：客户端收到服务端的连接同意报文后，还要再发送一个确认包给服务端，ACK=1，序列号为x+1，确认号为y+1，服务端收到客户端的确认信息后，建立连接，客户端和服务端都处于ESTABLISHED状态

为什么不是两次握手？

如果是两次握手的话，当客户端发送连接请求给服务端，由于网络阻塞，服务端一直没有收到客户端的连接请求，客户端会连接超时，重新再发送一个连接请求，如果服务器正常确认连接，并开始通信，通信结束后释放资源。此时，如果刚才阻塞的那个连接请求到达了服务端，因为只有两次握手，服务端就会确认客户端的连接，等待客户端发送数据。但此时客户端已经通信完成，处于关闭状态，因此服务端会一直等待下去，浪费连接资源

为什么不是四次握手？

因为三次握手就能解决问题了，就不需要四次握手了

四次握手的话，第二三步可以合并，就变成了三次握手

第三次握手失败会发生什么？

服务端收不到客户端的ACK，会在一段时间内超时重传，默认五次

SYN泛洪攻击 DDos攻击

伪装的ip向服务器发生一个SYN请求，然后服务器对该ip回复SYN和ACK，但是找不到对应的ip主机，当超时时，服务器会超时重发，当大量的攻击者请求建立连接时，服务器就会存在大量未完成三次握手的连接，服务器主机backlog被耗尽而不能响应其它连接

防范措施：

降低SYN timeout时间，使得主机尽快释放半连接的占用

采用SYN cookie设置，如果短时间内连续收到某个IP的重复SYN请求，则认为受到了该IP的攻击，丢弃来自该IP的后续请求报文

在网关处设置过滤，拒绝将一个源IP地址不属于其来源子网的包进行更远的路由

参考链接https://blog.csdn.net/XSF50717/article/details/47280825