-
TCP三次握手的过程?每一步的状态变化?
-
三次握手:第一次握手,客户端主动打开连接,发送SYN报文,并生成随机序列号,客户端状态从CLOSED变为SYN_SENT,第二次握手,服务端收到SYN后,同意建立连接,然后发送SYN-ACK报文(确认号,服务端自己的序列号)作应答,状态从LISTEN变为SYN_RCVD,第三次握手,客户端收到SYN-ACK后,检查确认号是否正确,然后状态从SYN_SENT变为ESRTABLISHED,然后发送一个ACK报文做最终确认,这个时候,连接就建立了,可以携带数据进行传输了,服务端收到ACK后
SYN_RCVD变为**ESTABLISHED** -
为什么需要三次握手?两次不行吗?
-
-不行,两次握手会导致问题。 核心原因是为了防止已失效的连接请求报文段突然又传到服务端,从而产生错误。
-
如果是两次握手,在第一次握手时,客户端发的SYN报文由于网络拥堵超时了没有到达,然后客户端重新发SYN报文,然后服务端收到这个SYN报文,建立了连接,然后那个由于网络拥堵的SYN这个时候到达,服务端以为是新连接,然后又和这个请求建立了连接,于是直接进入
ESTABLISHED状态,发送SYN-ACK(这实际上是浪费资源),并等待客户端发送数据。但客户端知道并没有请求建立新连接,不会理会这个SYN-ACK。服务端却一直在等,造成资源空耗(半开连接) -
三次握手的话,服务端收到旧的SYN,回复的SYN-ACK被客户端收到,发现确认号不认识,不是自己的,就发送RST复位报文告诉服务端没有建立这个连接的请求,服务端收到后就不会再对其进行等待了
康复训练 6
keep intensify2026-03-17 13:51