详解TCP/IP的三次握手和四次挥手

·  阅读 269

本文正在参与 “网络协议必知必会”征文活动

我们知道TCP协议也被称为好人协议,是可靠传输的,TCP数据包没有长度限制,理论上可以无限长,但是为了保证网络的效率,通常TCP数据包的长度不会超过IP数据包的长度,以确保单个TCP数据包不必再分割。

基于TCP协议的通信,客户端与服务端必须建立一个双向通信的通道,客户端和服务端在建立双向连接时需要进行三次握手,断开连接时则需要四次挥手

下面就对三次握手和四次挥手进行详细的解释:

三次握手

下图是客户端与服务端建立双向连接时进行三次握手的图解:

img

上述图片用语言文字来表达就是:

1 客户端向服务端发送一段TCP报文---请求连接 标记位:SYN,表示请求建立连接 序号:seq=x 客户端进入SYN_SENT阶段

2 服务端从半连接池中取出来自客户端的连接请求,结束LISTEN状态,返回一段TCP报文给客户端: 标记位:ACK=x+1:表示确认收到了客户端的连接序列号seq=x,并将x+1作为确认号返回给客户端 标记位:SYN(seq=y):确认收到连接请求的同时,向客户端发送连接请求,序号为seq=y 客户端进入EATABLISHED阶段,服务端进入SYN_RCVD阶段

3 客户端接收到从服务端发送的确认收到收到请求的结果(ACK=x+1)及服务端发起的连接请求(SYN seq=y),并向服务端发送确认连接。 标记位:ACK=y+1,表示确认收到了服务端的连接请求seq=y,并建立连接,将y+1作为确认号返回给服务端 服务端进入EATABLISHED阶段

如果你觉得上述描述不是很容易理解,我们可以与日常生活中的实际例子进行对比理解,比如将把客户端比作男孩,服务器比作女孩。用他们的交往来说明“三次握手”过程:

(1)男孩喜欢女孩,于是写了一封信告诉女孩:我爱你,请和我交往吧!;写完信之后,男孩焦急地等待,因为不知道信能否顺利传达给女孩。

(2)女孩收到男孩的情书后,心花怒放,原来我们是两情相悦呀!于是给男孩写了一封回信:我收到你的情书了,也明白了你的心意,其实,我也喜欢你!我愿意和你交往!; 写完信之后,女孩也焦急地等待,因为不知道回信能否能顺利传达给男孩。

(3)男孩收到回信之后很开心,因为发出的情书女孩收到了,并且从回信中知道了女孩喜欢自己,并且愿意和自己交往。然后男孩又写了一封信告诉女孩:你的心意和信我都收到了,谢谢你,还有我爱你! 女孩收到男孩的回信之后,也很开心,因为发出的情书男孩收到了。由此男孩女孩双方都知道了彼此的心意,之后就快乐地交流起来了~~

img

客户端与服务端建立连接时为什么需要进行三次握手来建立双向通信连接呢?为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。 也可以这样理解:“第三次握手”是客户端向服务器端发送数据,这个数据就是要告诉服务器,客户端有没有收到服务器“第二次握手”时传过去的数据。若发送的这个数据是“收到了”的信息,接收后服务器就正常建立TCP连接,否则建立TCP连接失败,服务器关闭连接端口。由此减少服务器开销和接收到失效请求发生的错误。 由于网络传输是有延时的(要通过网络光纤和各种中间代理服务器),在传输的过程中,比如客户端发起了SYN=1创建连接的请求(第一次握手)。 如果服务器端就直接创建了这个连接并返回包含SYN、ACK和Seq等内容的数据包给客户端,这个数据包因为网络传输的原因丢失了,丢失之后客户端就一直没有接收到服务器返回的数据包。 客户端可能设置了一个超时时间,时间到了就关闭了连接创建的请求。再重新发出创建连接的请求,而服务器端是不知道的,如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话, 服务器端是不知道客户端有没有接收到服务器端返回的信息的。

四次挥手

四次挥手对应的是客户端与服务端的连接断开,断开连接由哪一方先提出都可以,如下图所示

img

比如是客户端主动断开连接,上图用语言文字描述为:

1 首先客户端想要断开连接,向服务器端发送一段TCP报文--请求断开连接

标记位:FIN,表示请求断开连接 

序号:seq=x+2 

客户端此时处于FIN_WAIT_1阶段,即半关闭状态,停止客户端向服务端发送数据,但是服务端仍然能够向客户端发送数据。 
复制代码

2 服务端接收到从客户端发出的TCP报文即断开连接请求,服务端会返回确认收到客户端想要关闭连接

标记位:ACK:表示收到客户端的断开连接请求 

序号:ACK=x+3 

服务端由ESTABLISHED状态进入CLOSE_WAIT半关闭状态,并开始准备释放服务端到客户端的连接 客户端结束FIN_WAIT_1阶段,进入FIN_WAIT_2阶段 
复制代码

3 服务端向客户端传输数据已完成,再次向客户端发送断开连接的请求

标记位:FIN 

序号:seq=y+1 
复制代码

服务端结束CLOSE_WAIT状态,进入LAST_ACK状态,并停止服务端到客户端的数据传输,但是客户端可以向服务端传输数据(前提是客户端通向服务端的连接没有关闭)

4 客户端接收从服务端发出的TCP报文,确认了服务端已经做好断开连接的准备,向服务端发送确认断开连接的报文

标记位:ACK:表示接收到服务端断开连接的请求 

序号:ACK=y+2 

客户端结束FIN_WAIT_2阶段,进入TIME_WAIT阶段,随后客户端开始在TIME_WAIT阶段等待2MSL 服务器端收到从客户端发出的TCP报文之后结束LAST-ACK阶段,进入CLOSED阶段。由此正式确认关闭服务器端到客户端方向上的连接。
复制代码

客户端等待完2MSL之后,结束TIME-WAIT阶段,进入CLOSED阶段,由此完成“四次挥手”。

如果还用男生女生谈恋爱来通俗的表示四次挥手的过程,则可以通俗的理解为:

把客户端比作男孩,服务器比作女孩。通过他们的分手来说明“四次挥手”过程。

"第一次挥手":日久见人心,男孩发现女孩变成了自己讨厌的样子,忍无可忍,于是决定分手,随即写了一封信告诉女孩。

“第二次挥手”:女孩收到信之后,知道了男孩要和自己分手,怒火中烧,心中暗骂:你算什么东西,当初你可不是这个样子的!于是立马给男孩写了一封回信:分手就分手,给我点时间,我要把你的东西整理好,全部还给你!男孩收到女孩的第一封信之后,明白了女孩知道自己要和她分手。随后等待女孩把自己的东西收拾好。

“第三次挥手”:过了几天,女孩把男孩送的东西都整理好了,于是再次写信给男孩:你的东西我整理好了,快把它们拿走,从此你我恩断义绝!

“第四次挥手”:男孩收到女孩第二封信之后,知道了女孩收拾好东西了,可以正式分手了,于是再次写信告诉女孩:我知道了,这就去拿回来! 这里双方都有各自的坚持。 女孩自发出第二封信开始,限定一天内收不到男孩回信,就会再发一封信催促男孩来取东西! 男孩自发出第二封信开始,限定两天内没有再次收到女孩的信就认为,女孩收到了自己的第二封信;若两天内再次收到女孩的来信,就认为自己的第二封信女孩没收到,需要再写一封信,再等两天…..

倘若双方信都能正常收到,最少只用四封信就能彻底分手!这就是“四次挥手”。

四次挥手时客户端必须在TIME-WAIT状态下等待2MSL,原因就是要确认服务器端是否收到客户端发出的ACK确认报文,当客户端发出最后的ACK确认报文时,并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后,会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime:一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。 服务器端在1MSL内没有收到客户端发出的ACK确认报文,就会再次向客户端发出FIN报文; 如果客户端在2MSL内,再次收到了来自服务器端的FIN报文,说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文,计时器重置,重新开始2MSL的计时; 否则客户端在2MSL内没有再次收到来自服务器端的FIN报文,说明服务器端正常接收了ACK确认报文,客户端可以进入CLOSED阶段,完成“四次挥手”。 所以,客户端要经历时长为2SML的TIME-WAIT阶段;这也是为什么客户端比服务器端晚进入CLOSED阶段的原因。

结语

文章首发于微信公众号程序媛小庄,同步于掘金知乎

码字不易,转载请说明出处,走过路过的小伙伴们伸出可爱的小指头点个赞再走吧(╹▽╹)

分类:
后端
分类:
后端