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

    这个简直是每次面试必问的一个知识点了,又三次握手四次挥手的过程能带出一大堆问题来,个个都能问得你猝不及防,什么第三次确认的必要性,什么time_wait的作用啦,什么主动关闭被动关闭啦,什么发送内容啦,等等等等。今天我们就来好好总结一下这整个的过程。

    建立TCP需要三次握手才能建立,而断开连接则需要四次握手。整个过程如下图所示:

    先来看看如何建立连接的:

    首先Client端发送连接请求报文,Server段接受连接后回复ACK报文,并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文,并分配资源,这样TCP连接就建立了。

    那如何断开连接呢?简单的过程如下:

    【注意】中断连接端可以是Client端,也可以是Server端。

    假设Client端发起中断连接请求,也就是发送FIN报文。Server端接到FIN报文后,意思是说"我Client端没有数据要发给你了",但是如果你还有数据没有发送完成,则不必急着关闭Socket,可以继续发送数据。所以你先发送ACK,"告诉Client端,你的请求我收到了,但是我还没准备好,请继续你等我的消息"。这个时候Client端就进入FIN_WAIT状态,继续等待Server端的FIN报文。当Server端确定数据已发送完成,则向Client端发送FIN报文,"告诉Client端,好了,我这边数据发完了,准备好关闭连接了"。Client端收到FIN报文后,"就知道可以关闭连接了,但是他还是不相信网络,怕Server端不知道要关闭,所以发送ACK后进入TIME_WAIT状态,如果Server端没有收到ACK则可以重传。“,Server端收到ACK后,"就知道可以断开连接了"。Client端等待了2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,我Client端也可以关闭连接了。Ok,TCP连接就这样关闭了!

    整个过程Client端所经历的状态如下:

    而Server端所经历的过程如下:

    【注意】 在TIME_WAIT状态中,如果TCP client端最后一次发送的ACK丢失了,它将重新发送。TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。等待之后连接正式关闭,并且所有的资源(包括端口号)都被释放。

    【问题1】为什么TCP需要三次握手,两次为啥不行?

    答:TCP的三次握手最主要是防止已过期的连接再次传到被连接的主机。如果采用两次的话,会出现下面这种情况。

    比如是A机要连到B机,结果发送的连接信息由于某种原因没有到达B机;
    于是,A机又发了一次,结果这次B收到了,于是就发信息回来,两机就连接。
    传完东西后,断开。

    结果这时候,原先没有到达的连接信息突然又传到了B机,于是B机发信息给A,然后B机就以为和A连上。

    除此之外,还有可能发生死锁:

    假定B给A发送一个连接请求分组,A收到了这个分组,并发送了确认应答分组。按照两次握手的协定,A认为连接已经成功地建立了,可以开始发送数据分组。可是,B在A的应答分组在传输中被丢失的情况下,将不知道A是否已准备好,不知道A建议什么样的序列号,B甚至怀疑A是否收到自己的连接请求分组。在这种情况下,B认为连接还未建立成功,将忽略A发来的任何数据分组,只等待连接确认应答分组。而A在发出的分组超时后,重复发送同样的分组。这样就形成了死锁

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

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

    答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

    【问题4】TIME_WAIT有什么作用?

    答:主动关闭的Socket端会进入TIME_WAIT状态,并且持续2MSL时间长度,MSL就是maximum segment lifetime(最大分节生命期),这是一个IP数据包能在互联网上生存的最长时间,超过这个时间将在网络中消失。MSL在RFC 1122上建议是2分钟,而源自berkeley的TCP实现传统上使用30秒,因而,TIME_WAIT状态一般维持在1-4分钟。

        TIME_WAIT状态存在的理由:
    1)可靠地实现TCP全双工连接的终止
        在进行关闭连接四路握手协议时,最后的ACK是由主动关闭端发出的,如果这个最终的ACK丢失,服务器将重发最终的FIN,因此客户端必须维护状态信息允许它重发最终的ACK。如果不维持这个状态信息,那么客户端将响应RST分节,服务器将此分节解释成一个错误(在java中会抛出connection reset的SocketException)。因而,要实现TCP全双工连接的正常终止,必须处理终止序列四个分节中任何一个分节的丢失情况,主动关闭的客户端必须维持状态信息进入TIME_WAIT状态。

    2)允许老的重复分节在网络中消逝  
        TCP分节可能由于路由器异常而“迷途”,在迷途期间,TCP发送端可能因确认超时而重发这个分节,迷途的分节在路由器修复后也会被送到最终目的地,这个原来的迷途分节就称为lost duplicate。在关闭一个TCP连接后,马上又重新建立起一个相同的IP地址和端口之间的TCP连接,后一个连接被称为前一个连接的化身 (incarnation),那么有可能出现这种情况,前一个连接的迷途重复分组在前一个连接终止后出现,从而被误解成从属于新的化身。为了避免这个情况,TCP不允许处于TIME_WAIT状态的连接启动一个新的化身,因为TIME_WAIT状态持续2MSL,就可以保证当成功建立一个TCP连接的时候,来自连接先前化身的重复分组已经在网络中消逝。

     参考资料:

    http://www.cnblogs.com/li-hao/archive/2011/12/08/2280678.html

    http://www.cnblogs.com/zhuxiongfeng/archive/2011/05/08/2040534.html

    http://blog.csdn.net/whuslei/article/details/6667471/

  • 相关阅读:
    Go语言对etcd的基本操作
    etcd命令行基本操作
    etcd集群部署
    第二十一天python3 python的正则表达式re模块学习
    第二十天python3 正则表达式
    jenkins多分支构建选择
    第十九天python3 json和messagepack
    华为交换机设置ntp时间同步
    交换机端口光衰问题排查
    第十八天python3 序列化和反序列化
  • 原文地址:https://www.cnblogs.com/SarahLiu/p/5956055.html
Copyright © 2011-2022 走看看