神奇的三次握手和四次挥手详解

【前言】

       其实早在一年前的这段时间我有写过一篇类似的文章,后来因为要忙毕业,此文就只写了三次握手,也没有后续更新了。过了这么久,今天再来回忆回忆,把文章补充完整吧。

【相关的一些名词】

报文:是网络中交换与传输的数据单元,即站点一次性要发送的数据块。报文包含了将要发送的完整的数据信息

TCP传输控制协议(Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议。

TCP/IP协议:互联网协议(Internet Protocol Suite)是一个网络通信模型。tcp/ip提供点对点的链接机制,将数据应该如何封装、定址、传输、路由以及在目的地如何接收,都加以标准化.

SYN同步序列编号(Synchronize Sequence Numbers)是TCP/IP建立连接时使用的握手信号,1为请求建立连接。

ACK确认字符(Acknowledgement)在TCP/IP协议中,服务器收到客户机发来的SYN后回复的一个数据,用来确定发来的数据已经接受。

SEQ序列号(sequence number),下一个seq是当前seq和包大小加的。

(关于包含SYN和ACK的TCP报文头部请移步这里:TCP报文头部

【三次握手】

  • 第一次握手:Client端会发送一个SYN标记为1的包,并随机取了一个随机数SEQ(c)=x为自己的初始序列号,发送完后进入SYN-SEND状态。
  • 第二次握手:Server端收到了SYN=1的标记,知道了Client端想要和自己建立连接,此时进入LISTEN状态。于是发送包含一个确认标记ACK(ACK=SEQ(c)+1),一个建立连接标记SYN=1,并且随机产生自己的序列书SEQ(s)=y的包,发送完后进入SYN-RECV状态。
  • 第三次握手:Client端收到Server端发来的包之后,检查ACK的值是否等于SEQ(c)+1以及SYN是否为1,确认无误后,再发送包含一个ACK=SEQ(s)+1,一个SEQ=z,此时双方进入ESTABLISHED状态,TCP连接建立。

       其实在握手和结束时确认号(ACK)应该是对方序列号加1,传输数据时则是对方序列号加上对方携带应用层数据的长度。

       另外,如果对方没有数据过来,则自己的确认号不变,序列号为上次的序列号加上本次应用层数据发送长度。

生活中最类似的情况:

买手机的时候试通话功能的时候:

老手机打给新手机 : 喂 , 听到了吗 ?

新手机回复老手机 : 听到了 , 你听到了吗 ?

老手机 : 听到了听到了…

然后就开始愉快的通话了…

 

1、为什么需要进行三次握手呢?

       其实建立三次握手都是因为Client端发进行了再次确认(第一次确认是Server端确认收到了Client端发送的连接请求),目的是为了防止Server收到已经失效的连接请求报文就立即建立连接。

       假如只有一次确认,Client端发送了第一个请求报文A给Server端,此时A丢失了,然后Client再发送一次请求报文给Server端,这个时候成功达到,建立了连接,进行数据传输,看起来很完美。但是,如果第一个请求报文A并没有丢失,而是被堵在路上了,但是Client已经认为它失效了,此时Client发送了第二个请求报文B并且和Server建立了连接,完成传输后断开。这个时候,第一个请求报文A(已经被Client认为失效了)经过了长时间的堵塞道道了Server端,Server端以为Client再一次发起了请求,并立即发送确认报文给到Client,然鹅Client并不会发送数据进行传输,这样一来就占用了资源,显然是不好的。

       采用三次握手如果Server给Client端发送确认报文,然而Client并没有回答确认,Server端就知道Client的这次请求并不是真的想要建立连接,如此一来,就不会浪费资源傻傻等Client发送数据进行传输了。

 

【四次挥手】

四次挥手有两种情况,这里我选取客户端主动发起关闭请求来讲解。

  • 第一次挥手:Client端主动断开连接,并发送一个包含FIN=1,SEQ=u(等于前面已经传送过来的数据的最后一个字节的序号加1,因为TCP协议规定FIN报文段即使不携带数据,也要消耗一个序号)的请求断开报文,发送完后进入FIN-WAIT-1状态
  • 第二次挥手:Server端收到了断开请求报文,便发送一个包含ACK=u+1,SEQ=z的确认报文,发送完后进入CLOSE-WAIT状态。Client端收到Server端的确认报文后,Client端进入FIN-WAIT-2状态,继续接受Server端发送的最后的报文;
  • 第三次挥手:等所有的数据传送完毕后,Server端发送一个包含FIN=1,SEQ=w,ACK=u+1的连接断开报文,此时Server端进入LAST-ACK状态。
  • 第四次挥手:Client端收到断开连接报文后,必须要发送一个包含ACK=w+1,SEQ=u+1的确认断开报文,此时Client端进入TIME-WAIT状态,Server端进入CLOSED状态,等待2MSL(最长报文寿命)时间后,Server端进入CLOSED状态,双方正式断开连接。

1、为什么连接的时候是三次握手,关闭的时候却是四次握手?

       因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

2、为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

       虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在TIME_WAIT状态中,如果TCP client端最后一次发送的ACK丢失了,它将重新发送。TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。等待之后连接正式关闭,并且所有的资源(包括端口号)都被释放。

 

  • 22
    点赞
  • 129
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

hobby云说

你的鼓励将是我最大的动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值