zoukankan      html  css  js  c++  java
  • 三次握手四次挥手

    双各自向对方发送FIN,再各自向对方发送ACK 

    中间的两次交互可能合并为一个(在特殊情况下仅仅是可能,所以有些情况下是三次挥手)

    第一次挥手,client:我说完了
    第二次挥手,server:我知道了(但此时server可能还有话要说)
    第三次挥手,server:我也说完了
    第四次挥手,client:我知道了,(双方挂了电话)
    为什么要四次挥手?
    答:根本原因是,一方发送FIN只表示自己发完了所有要发的数据,但还允许对方继续把没发完的数据发过来。

    举个例子:

    A和B打电话,通话即将结束后,A说“我没啥要说的了”,B回答“我知道了”,但是B可能还会有要说的话,A不能要求B跟着自己的节奏结束通话,于是B可能又巴拉巴拉说了一通,最后B说“我说完了”,A回答“知道了”,这样通话才算结束。

    常见面试题
    第一次挥手:客户端首先向服务器发送断开连接消息,这时TCP头部中的FIN标识位值为1,序号是seq=u,u为客户端前面正常发送数据最后一个字节序号加1得到的,消息发送后客户端进入FNI_WAIT_1状态,FIN=1的报文段不能携带数据,但要消耗一个序号。
    第二次挥手:服务器收到客户端的断开连接请求需要发出确认消息,这时TCP头部中的ACK标识位值为1,确认号为ack=u+1,而自己的序号为seq=v,v为服务端前面正常发送数据最后一个字节序号加1得到的,然后服务器进入CLOSE_WAIT状态,此时就关闭了客户端到服务器的连接,客户端无法再给服务器发数据,但是服务器仍然可以给客户端发数据(此处存疑),同时服务器端通知上方应用层,处理完成后被动关闭连接。然后客户端收到服务器的确认信息后,就进入了FIN_WAIT_2状态。
    第三次挥手:服务器端应用层处理完数据后,通知关闭连接,服务器向客户端发送关闭连接的消息,这时TCP头部中的FIN和ACK标识位值均为1,确认号ack=u+1,自己的序号为seq=w,(服务器发出确认消息后又发送了一段数据,此处存疑),消息发送后服务器进入LACK_ACK状态。
    第四次挥手:客户端收到服务器的断开连接的消息后,需要发送确认消息,这是这时TCP头部中的ACK标识位值为1,确认号ack=w+1,序号为u+1(因为客户端向服务器发送断开连接的消息时消耗了一个消息号),然后客户端进入TIME_WAIT状态,若等待时间经过2MSL后,没有收到服务器的重传请求,则表明服务器收到了自己的确认,客户端进入CLOSED状态,服务器收到客户端的确认消息后则直接进入CLOSED状态。至此TCP成功断开连接。
    【问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?

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

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

    答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在客户端发送出最后的ACK回复,但该ACK可能丢失。服务器端如果没有收到ACK,将不断重复发送FIN片段。所以客户端不能立即关闭,它必须确认服务器端接收到了该ACK。客户端会在发送出ACK之后进入到TIME_WAIT状态。客户端会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么客户端会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,客户端都没有再次收到FIN,那么客户端推断ACK已经被成功接收,则结束TCP连接。

    【问题3】为什么不能用两次握手进行连接?

    答:3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。

        现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发 送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S 是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分 组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。

    【问题4】如果已经建立了连接,但是客户端突然出现故障了怎么办?

    TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。

    推荐阅读相关博客:https://www.cnblogs.com/cenglinjinran/p/8482412.html

  • 相关阅读:
    清空map
    读取图片的DLL
    利用SysMailer发送邮件
    使用维度显示
    获取用户所属仓库与库位 Owner 所属仓位
    使用电子邮件模板
    使用SQL获取TableID
    导入数据到excel
    ax附件存取研究
    两步转移 过账
  • 原文地址:https://www.cnblogs.com/hetaoyuan/p/11238390.html
Copyright © 2011-2022 走看看