首页 资讯 应用 高压 设计 行业 低压 电路图 关于

通信网络

旗下栏目: 电力电子 通信网络 RFID LED

TCP的状态转化过程(11种状态)以及TIME_WAIT状态

通信网络 | 发布时间:2018-06-10 | 人气: | #评论# | 本文关键字:TCP,TIME_WAIT,状态转化
摘要:TCP中的三次握手,四次挥手是我们所熟知的,可是,我们熟悉里面的各种状态吗? (SYN_SENT, ESTABLISHED, CLOSE_WAIT.............),试问一句,我们了解里面的状态转化吗??? 1,大家先看一个简单的

TCP中的三次握手,四次挥手是我们所熟知的,可是,我们熟悉里面的各种状态吗?(SYN_SENT,   ESTABLISHED,    CLOSE_WAIT.............),试问一句,我们了解里面的状态转化吗???

1,大家先看一个简单的通信图(图片转载与:UNIX网络编程,page:36,图2-5)

      通信图

     可以很明显的看到,在通信双方,客户端,服务端的状态变化过程,有人可能会说:我们上面不是说,有11状态吗??为什么到啦这里变成了只有10种

1,(主动打开:SYN_SENT)  2,ESTABLISHED        3,(主动关闭:FIN_WAIT_1)     4,FIN_WAIT_2    5,TIME_WAIT     6,SYN_RCVD     7,CLOSE_WAIT(被动关闭)     8,LAST_ACK    9,CLOSED   10,LISTEN)

       为什么不是11个呢?哈哈,其实还有一种状态叫做:CLOSING(这个状态产生的原因比较特殊,后面分析)接下来我们分析一下,这些状态的变化过程,,,

           主动套接口:用来发起连接                            被动套接口:用来接受连接

      1,对于服务器端来说:

           当调用socket函数创建一个套接字时,状态是CLOSED,它被假设为一个主动套接字,也就是说,它是一个将调用connect发起连接的客户套接字。listen函数把一个未连接的套接字转化成一个被动套接字,指示内核应接受指向该套接字的连接请求。结合TCP的状态转化图:调用listen函数导致套接字从:CLOSED状态转化为:LISTEN状态

       2,对于客户端来说:

             调用socket函数创建一个套接口时,状态也是CLOSED,同样的,它也被假设为一个主动套接字,紧接着,调用connect主动打开套接口,并且一直阻塞着,等待三次握手的完成,我们把这个状态称之为:主动套接口当客户端发起了三次握手的第一次(SYN   J,MSS = 536)的时候,套接口的状态变成了:SYN_SENT(主动打开)

       3,对于服务器端而言,调用了listen之后,然后状态就变成了LISTEN状态,接着调用accept函数,使自身一直保持阻塞的状态,直到三次握手的第一次来到(来自TCP协议栈的TCP的第一个分节),即接收到(SYN  J,MSS = 536),此刻状态由:LISTEN转变为SYN_RCVD

       4,对于客户端来说,刚才发送了TCP协议栈中TCP三次握手的第一个分节,此刻应该接受来自服务器发送过来的TCP三次握手的第二个分节,这时服务器发送过来:(SYN K, ACK J+1, MSS = 1460),此刻,服务器的状态不变,还是SYN_RCVD,然后,客户端接受服务器发送过来的TCP三次握手的第二次分节,此刻状态由之前的:SYN_SENT转变为ESTABLISHED,(客户端已经建立完成),这时,connect函数返回

       5,然后客户端保持ESTABLISHED状态,并且发出TCP协议栈中TCP三次握手的第三个分节(ACK  K+1)服务端的状态由:SYN_RCVD转变为:ESTABLISHED,从未完成的队列中取出队首的第一个连接放在已完成队列,这样accept函数就会返回。此刻,两者都建立完成,这个时候可以完成通信了

       6,那么接下来就是连接终止的四次握手,当双方都变成ESTABLISHED状态之后,双方就可以通信了,在双方通信的过程中,由于状态都没有变化,所以这里,我们暂且不讨论。在通信的时候呢,双方都可以主动发起关闭,那么:我们假定客户端发起一个关闭请求(调用close函数):会向服务端发送一个TCP分节(TCP协议栈中四次握手的的第一个分节:FIN M)然后客户端的状态会变成:FIN_WAIT_1(主动关闭)此刻,服务端接收到这个TCP分节后,并且会对刚才发过来的连接进行确认(ACK M+1),服务端的状态会变成 CLOSE_WAIT(被动关闭)当,客户端接收到这个确认之后(ACK M+1),客户端的状态转变为:FIN_WAIT_2   , 只有当服务端的read函数返回为0的时候,服务端才需要,也是才可以发起关闭请求(FIN  N),发送完成之后,就变成了: LAST_ACK,  当客户端接受到了这个关闭请求之后,状态会变成了:TIME_WAIT(会经过2MSL(TCP报文端最大生存周期的两倍时间)之后,转变为:CLOSED),紧接着客户端会发送最后一次确认:(ACK N+1),等到服务端接收到这个确认后,服务端的状态会变成:CLOSED

           关于CLOSING:该状态产生的原因是:对于客户端和服务端而言,两者同时关闭的情况(这种情况并不多见),如下图:

             1528605926240547.png

、              两者同时关闭,后状态同时变成了FIN_WAIT_1,然后当另外一端接收到关闭分节后,状态同时变成CLOSING,然后都对刚才那个分节进行确认,当对端收到之后,两者又都变成了TIME_WAIT,所以说:在关闭的过程中,不一定可以必须要经过FIN_WAIT_2这个状态。 

关于TIME_WAIT:

         1,我们可以从上面的状态分析中得知,对于TIME_WAIT状态而言,是执行主动关闭的那端经历了这个状态。该端点停留在这个状态的持续时间是最长分节生命期(MAXIMUM  SEGMENT  LIFETIME, msl)的两倍,有时候称之为:2MSL

    任何TCP实现都必须为MSL选择一个值,RFC1122的建议值是2分钟,而源自Berkeley的实现传统上改用30秒这个值,又因为:信息的传送是需要一个来回,着也就说明,TIME_WAIT状态的持续时间是1分钟到4分钟之间。而MSL是任何IP数据报能够在因特网中存活的最长时间。我们也知道这个时间是有限的,因为每个数据报含有一个跳限(hop limit)的8位字段,它的最大值是255。尽管这是一个跳数限制而不是真正的时间限制,我们仍然假设:具有最大跳限(255)的分组在网络中存在的时间不可能超过MSL秒。               

  分组在网络中“迷途”通常是路由异路的结果。某个路由器崩溃或某两个路由器之间的某个链路断开时,路由协议需要花数秒钟到数分钟的时间才能稳定并找出另一条通路。在这段时间内可能发生路由循环(路由器A把分组发送给路由器B,而B再把它们发送给A),我们关心的分组可能就此陷入这样的循环。假设迷途的分组是一个TCP分节,在它迷途期间,发送端TCP超时重传该分组,而重传的分组却通过某条候选路径到达最终目的。然而不久后(自迷途的分组开始其旅程起最多MSL秒以内)路由循环修复,早先迷失在这个循环中的分组最终也被送到目的地。TCP必须正确处理这些重复的分组。

    TIME_WAIT状态存在的两个理由:1,可靠的实现TCP全双工连接的终止(更好的完善TCP的可靠性)2,允许老的重复分节在网络中消逝

   

责任编辑:TIME_WAIT
首页 | 电气资讯 | 应用技术 | 高压电器 | 电气设计 | 行业应用 | 低压电器 | 电路图 | 关于我们 | 版权声明

Copyright 2017-2018 电气自动化网 版权所有 辽ICP备17010593号-1

电脑版 | 移动版 原创声明:本站大部分内容为原创,转载请注明电气自动化网转载;部分内容来源网络,如侵犯您的权益请发送邮件到[email protected]联系我们删除。

Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。