TCP的三次握手与四次挥手

342次阅读
没有评论

共计 3331 个字符,预计需要花费 9 分钟才能阅读完成。

TCP的三次握手与四次挥手

TCP的三次握手

TCP的三次握手与四次挥手

  • 第一次握手
        客户端将TCP报文标志位SYN置为1,随机产生一个序号值seq=X,保存在TCP首部的序列号(Sequence Number)字段里,并将该数据包发送给服务器端,发送完毕后,客户端进入SYN_SENT状态,等待服务器端确认。TCP规定,SYN报文段(SYN=1的报文段)不能携带数据,但需要消耗掉一个序号。这个三次握手中的开始。表示客户端想要和服务端建立连接。
  • 第二次握手
        服务器端收到数据包后由标志位SYN=1知道客户端请求建立连接,服务器端将TCP报文标志位SYN和ACK都置为1,ack=X+1,随机产生一个序号值seq=Y,并将该数据包发送给客户端以确认连接请求,服务器端进入SYN_RCVD状态。
  • 第三次握手
        客户端收到确认后,检查ack是否为X+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=Y+1,并将该数据包发送给服务器端,服务器端检查ack是否为Y+1,ACK是否为1,如果正确则连接建立成功,客户端和服务器端进入ESTABLISHED状态,完成三次握手,随后客户端与服务器端之间可以开始传输数据了。
  • 为什么要三次握手,两次不行么

第一次握手a发给b,此时b知道ab是通的,但a还不知道。
第二次握手是b发给a,此时a知道ab和ba都是通的,但b只知道ab通,不知道ba通不通。
第三次握手是a发给b,此时b也知道ba通的,完毕。
举例:
客户端发送了第一个连接的请求报文,但是由于网络不好或者发送完关闭客户端,这个请求没有立即到达服务端,而是在某个网络节点中滞留了,直到某个时间才到达服务端,本来这已经是一个失效的报文,但是服务端接收到这个请求报文后,还是会向客户发出确认的报文,表示同意连接。
假如不采用三次握手,那么只要服务发出确认,新的建立就连接了,但其实这个请求是失效的请求,客户端是不会理睬服务的确认信息,也不会向服务端发送确认的请求,因为客户端关闭了,或者认为没连上服务端。但是服务端认为新的连接已经建立起来了,并一直等待客户端发来数据,这样服务端的很多资源就没白白浪费掉了,采用三次握手就是为了防止这种情况的发生,服务端会因为收不到确认的报文,就知道客户端并没有建立连接。这就是三次握手的作用。

TCP的四次挥手

四次挥手即终止TCP连接,就是指断开一个TCP连接时,需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中,这一过程由客户端或服务端任一方执行close来触发。由于TCP连接是全双工的,因此,每个方向都必须要单独进行关闭,这一原则是当一方完成数据发送任务后,发送一个FIN来终止这一方向的连接,收到一个FIN只是意味着这一方向上没有数据流动了,即不会再收到数据了,但是在这个TCP连接上仍然能够发送数据,直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭,而另一方则执行被动关闭。
TCP的三次握手与四次挥手
挥手请求可以是Client端,也可以是Server端发起的,我们假设是Client端发起:

  • 第一次挥手

Client端发起挥手请求,向Server端发送标志位是FIN=1,seq=u的报文段,此时,Client端进入FIN_WAIT_1状态,这表示Client端没有数据要发送给Server端了。TCP规定,FIN报文段即使不携带数据,也要消耗一个序号

  • 第二次挥手:

Server端收到了Client端发送的FIN报文段,向Client端返回一个标志位是ACK=1,ack=u+1的报文段,Client端进入FIN_WAIT_2状态,Server端告诉Client端,我确认并同意你的关闭请求。
TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)

  • 第三次挥手

Server端向Client端发送标志位是FIN=1,ack=u+1,的报文段,请求关闭连接,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。

  • 第四次挥手 :

   Client端收到Server端的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过**2MSL**(最长报文段寿命)的时间后则证明Server端已正常关闭,那好,Client端也可以关闭连接了。

  • 为什么挥手需要四次

为了确保数据能够完成传输。关闭连接时,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送给你了;但未必你所有的数据都全部发送给对方了,所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方来表示你同意现在可以关闭连接了,所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。可能有人会有疑问,tcp握手的时候为何ACK(确认)和SYN(建立连接)是一起发送。挥手的时候为什么是分开的时候发送呢。因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭 SOCKET,所以只能先回复一个ACK报文,告诉Client端,”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步挥手

  • 客户端突然挂掉了怎么办

 正常连接时,客户端突然挂掉了,如果没有措施处理这种情况,那么就会出现客户端和服务器端出现长时期的空闲。解决办法是在服务器端设置保活计时器,每当服务器收到客户端的消息,就将计时器复位。超时时间通常设置为2小时。若服务器超过2小时没收到客户的信息,他就发送探测报文段。若发送了10个探测报文段,每一个相隔75秒,还没有响应就认为客户端出了故障,因而终止该连接。

  • 为什么要等待2MSL

MSL:报文段最大生存时间,它是任何报文段被丢弃前在网络内的最长时间。
有以下两个原因:

  1. 保证TCP协议的全双工连接能够可靠关闭
        由于IP协议的不可靠性或者是其它网络原因,导致了Server端没有收到Client端的ACK报文,那么Server端就会在超时之后重新发送FIN,如果此时Client端的连接已经关闭处于CLOESD状态,那么重发的FIN就找不到对应的连接了,从而导致连接错乱,所以,Client端发送完最后的ACK不能直接进入CLOSED状态,而要保持TIME_WAIT,当再次收到FIN的收,能够保证对方收到ACK,最后正确关闭连接。
  2. 第二点:保证这次连接的重复数据段从网络中消失
        如果Client端发送最后的ACK直接进入CLOSED状态,然后又再向Server端发起一个新连接,这时不能保证新连接的与刚关闭的连接的端口号是不同的,也就是新连接和老连接的端口号可能一样了,那么就可能出现问题:如果前一次的连接某些数据滞留在网络中,这些延迟数据在建立新连接后到达Client端,由于新老连接的端口号和IP都一样,TCP协议就认为延迟数据是属于新连接的,新连接就会接收到脏数据,这样就会导致数据包混乱。所以TCP连接需要在TIME_WAIT状态等待2倍MSL,才能保证本次连接的所有数据在网络中消失。

正文完
 0
yangleduo
版权声明:本站原创文章,由 yangleduo 于2023-04-25发表,共计3331字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。