zoukankan      html  css  js  c++  java
  • TCP连接的建立与关闭

    TCP是主机对主机层的传输控制协议:建立连接要三个握手,断开连接要四次挥手。

    位码即TCP标志位,有6种标示:SYN(synchronous建立联机),ACK(acknowledgement 确认),PSH(push传送),FIN(finish结束),RST(reset重置),URG(urgent紧急),Sequence number(顺序号码),Acknowledge number(确认号码)

    各个状态的意义如下: 
    LISTEN - 侦听来自远方TCP端口的连接请求; 
    SYN-SENT -在发送连接请求后等待匹配的连接请求; 
    SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认; 
    ESTABLISHED- 代表一个打开的连接,数据可以传送给用户; 
    FIN-WAIT-1 - 等待远程TCP的连接中断请求,或先前的连接中断请求的确认;
    FIN-WAIT-2 - 从远程TCP等待连接中断请求; 
    CLOSE-WAIT - 等待从本地用户发来的连接中断请求; 
    CLOSING -等待远程TCP对连接中断的确认; 
    LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认; 
    TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认; 
    CLOSED - 没有任何连接状态;

    下图所示的:主动发起连接和关闭连接的是Client方,被动的是Server方。

    http://dl2.iteye.com/upload/attachment/0077/6058/5d4e8c89-fc42-3862-bdb8-399bc982f410.png

    从上面可以看到,主动发起关闭连接的操作的一方将达到TIME_WAIT状态,而且这个状态要保持Maximum Segment Lifetime的两倍时间。为什么要这样做而不是直接进入CLOSED状态?

    原因有二:
    一、保证TCP协议的全双工连接能够可靠关闭
    二、保证这次连接的重复数据段从网络中消失

    先说第一点,如果Client直接CLOSED了,那么由于IP协议的不可靠性或者是其它网络原因,导致Server没有收到Client最后回复 的ACK。那么Server就会在超时之后继续发送FIN,此时由于Client已经CLOSED了,就找不到与重发的FIN对应的连接,最后 Server就会收到RST而不是ACK,Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失,但是却导致TCP协议不符 合可靠连接的要求。所以,Client不是直接进入CLOSED,而是要保持TIME_WAIT,当再次收到FIN的时候,能够保证对方收到ACK,最后 正确的关闭连接。

    再说第二点,如果Client直接CLOSED,然后又再向Server发起一个新连接,我们不能保证这个新连接与刚关闭的连接的端口号是不同的。 也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题,但是还是有特殊情况出现:假设新连接和已经关闭的老连接端口号是一样的,如果 前一次连接的某些数据仍然滞留在网络中,这些延迟数据在建立新连接之后才到达Server,由于新连接和老连接的端口号是一样的,又因为TCP协议判断不 同连接的依据是socket pair,于是,TCP协议就认为那个延迟的数据是属于新连接的,这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态 等待2倍MSL,这样可以保证本次连接的所有数据都从网络中消失。

  • 相关阅读:
    记一次与用户的亲密接触
    拨开障目的叶,一览CMDB庐山真面目
    广通软件获“2016年度中国最具影响力IT运维管理软件提供商”殊荣
    CMDB三大绝招,助我站稳运维之巅
    datetime module总结
    Python time module总结
    IPMItool小结
    Python selenium 延时的几种方法
    Python 字典操作
    YUM 配置
  • 原文地址:https://www.cnblogs.com/mcahkf/p/5158328.html
Copyright © 2011-2022 走看看