- 第一次握手:客户端发送连接请求报文,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