三次握手四次挥手



握手和挥手的话题恒古不变,笔者看完链路帧、IP数据报、TCP/UDP的具体格式才对其有了较良好的理解,学习果然要注重基础


1. 前提

此笔记默认已经熟悉TCP协议头的首部格式了,因为握手和挥手是建立的TCP协议上的,具体来说是建立在其内部的各种字段上


三次握手四次挥手

​ 图出自《图解TCP/IP》


SYN:请求建立连接,初始化随机序列号,其ACK为0(其余情况ACK都为1)
FIN:希望断开连接
ACK:大写表示控制位

ack:确认应答号,表示下次该收到的数据序列号
seq:序列号





2. 三次握手

三次握手四次挥手

第一次:

Client:发送SYN包(SYN=1,ACK=0,seq=客户端随机),并进入SYN-SENT 状态

Server:收到SYN=1后知道Client要请求连接


第二次:

Server:返回应答报文ACK(ack=对方的seq+1)

Server:发送SYN包(SYN=1,ACK=1,seq=服务器随机)

以上两步骤合并起一步发送,然后进入SYN-RCVD 状态


第三次:

Client:验证对方ack,然后返回应答报文ACK(ack= 对方seq+1),且可携带数据,前两次不可

Server:验证对方ack,ACK是否=1,建立连接

以上两步分别都进入ESTABLISHED 状态



2.2 为什么是三次握手不是二次或四次


原因一:防止失效的请求连接报文传到服务器

假设两次握手的情况:Client第一次发送连接请求因网络延迟没有到达服务器,被认为失效,

然后Client第二次发送请求,这时成功两次握手并建立连接(假设情况),数据传送完毕断开连接。

此时第一次发送的请求连接这时才到达服务器,服务器收到请求后因为是两次握手,Server直接发送确认报文并建立连接,但此刻Client并没有请求所以不响应,导致资源白白浪费


原因二:三次握手才能确保双方序列号被同步

第一次客户端发送自己的随机序列号,第二次服务端确认应答,第三次服务器将自己的随机序列号发送给客户端,第四次客户端确认应答表示收到。由于第二三次可以合并,所以成为了三次握手不是四次





3. 四次挥手

三次握手四次挥手

第一次:

Client:发送FIN包,并进入FIN_WAIT_1状态


第二次:

Server:接收FIN包后,就向客户端发送ACK应答报文,并进入CLOSED_WAIT状态

Client:收到服务端的ACK应答报文后,之后进入FIN_WAIT_2状态。


第三次:

Server:处理完数据后,也向客户端发送FIN包,并进入LAST_ACK状态


第四次:

Client:收到FIN报文,回应ACK应答报文,进入TIME_WAIT状态

Client:经过2MSL时间后,自动进入CLOSE状态,完成连接的关闭

Server:服务器收到了 ACK应答报文后,就进入了CLOSE状态,完成连接的关闭


注意:主动关闭连接的,才有 TIME_WAIT 状态

注意:MSL是报文最大生存时间,TTL是IP数据报最大经过路由数,而MSL大于等于 TTL消耗为0的时间



3.1 为什么需要四次

Client请求关闭仅表示自己不会发送数据,Server数据可能还没发完,所以得先发送应答,等数据传完了再发送关闭请求。客户端请求FIN,服务端确认应答、服务端发送FIN,客户端确认应答。一来一回四次(与握手不同第二三次是分开的)


3.2 为什么主动关闭端需要等待2MSL

MSL是报文最大生存时间,是从客户端接收到 FIN 后发送 ACK 开始计时的:客户端需要保证最后一次发送的ACK报文到服务器,如果服务器未收到会重发FIN包,这样客户端还有时间再发ACK确认应答,重启2MSL计时。


3.3 TIME-WAIT状态其存在的原因

其一:保证「被动关闭连接」的一方能被正确的关闭,即保证最后的 ACK 能让被动关闭方接收,从而帮助其正常关闭


其二:防止已失效的连接请求报文段出现在本连接中。

假如客户端发送关闭连接包FIN前服务器有个数据包被延迟了,此时连接已经关闭,然后有个新的连接重新开启,端口等一样则被复用,这次被延迟的数据才到达则会二者不同连接被混乱。出现了TIME-WAIT足以让两个方向上的数据包都被丢弃,则原连接的数据包在网络中都自然消失了,再出现的数据包一定都是新建立连接所产生的



上一篇:第七周作业


下一篇:四次挥手