《TCP_IP状态变迁图和TCP三次握手与四次挥手.doc》由会员分享，可在线阅读，更多相关《TCP_IP状态变迁图和TCP三次握手与四次挥手.doc（8页珍藏版）》请在三一文库上搜索。
1、TCP/IP状态变迁图:开培应用进池被动JT开;发送:无USFE(SYN收到X冶严进稼关3 或務时应Hi进程发：1!收:(发送：1无1*1FENWAHWAJT.1发：5YN.ACF _,同时打开亠4收：FIN - WCLOGE-WAff)!g：ACK . SJ1数撫传送憨旌用进釋关闭:发! HN ：III(LASACK V? - J发送：无收:HN 同时关用、S：ack收:FINACK IMSLgW 王族南 说明笄户的正常狀态变迁 说坍砥殍薯旳正常状态变廿收:发送扎CK 无TIMEWATTCLOSJNG ；应用进程说羽当应用执行某坤理作时发主的状态变辻_收：说明当收到TC曝文段时状态的变迁：厂
2、4严皆単联掘发：说期为了进行某个状态变迁要发送的Tcpffi文UL LL/.com各状态详细描述:CLOSED表示初始状态。对服务端和C客户端双方都一样LISTEN表示监听状态。服务端调用了 listen函数，可以开始accept连接了SYN_SENT表示客户端已经发送了 SYNE文。当客户端调用connect函数发起连接时，首先发SY给服务端，然后自己进入SYN_SEN状态，并等待服务端发送ACK+SYNSYN_RCVD表示服务端收到客户端发送SY服文。服务端收到这个报文后，进入 SYN_RCVD态，然后发送ACK+SY给客户端。ESTABLISHED表示连接已经建立成功了。服务端发送完 A
3、CK+SY后进入该状态，客户端收到ACI后也进入该状态。FIN_WAIT_1表示主动关闭连接。无论哪方调用close函数发送FIN报文都会进入这个这个状态。FIN_WAIT_2表示被动关闭方同意关闭连接。主动关闭连接方收到被动关闭方返回的AC后，会进入该状态。TIME_WAIT表示收到对方的FIN报文并发送了 AC报文，就等2MS后即可回到CLOSE状态了。如果 FIN_WAIT_状态下，收到对方同时带FIN标志和AC标志的报文时，可以直接进入TIME_WAI状态，而无须经 过 FIN_WAIT_状态。CLOSING表示双方同时关闭连接。如果双方几乎同时调用close函数，那么会出现双方同时发
4、送FIN报文的情况，就会出现CLOSIN状态，表示双方都在关闭连接。CLOSE_WAIT表示被动关闭方等待关闭。当收到对方调用close函数发送的FIN报文时，回应对方AC报文，此时进入CLOSE_WA状态。LAST_ACK表示被动关闭方发送FIN报文后，等待对方的ACI报文状态，当收到AC后进入CLOSE状态。1. 连接建立1) Clie nt当Client端调用socket函数调用时，相当于Client端产生了一个处于Closed状态的套接字。Client端又调用connect函数调用，系统为Client随机分配一个端口，连同传入connect中的参数 (Server的IP和端口)，这就形
5、成了一个连接四元组，connect调用让Client端的socket处于SYN_SEN状态。当Server返回确认，并发送SYN Client返回确认及SY后，套接字处于ESTABLISHED段，此时双方的 连接已经可以进行读写操作。2) Server当Server端调用socket函数调用时，相当于Server端产生了一个处于Closed状态的监听套接字， Server端调用bind操作，将监听套接字与指定的地址和端口关联，然后又调用listen函数，系统会为其分配未完成队列和完成队列，此时的监听套接字可以接受Client的连接，监听套接字状态处于LISTEN犬态。当Server端调用acc
6、ept操作时，会从完成队列中取出一个已经完成的client连接，同时在server这端会产生一个会话套接字，用于和client端套接字的通信，这个会话套接字的状态是 ESTABLISH2. 连接关闭与连接建立分为server/client不同，连接关闭并没有绝对的server/client 之分，连接关闭分为主动关闭和被动关闭。Server和client都可以担任这两个角色中的任意一个。如 client可以关闭它与server的 连接，同样的server 一样也可以关闭一些长时间无读写事件发生的连接。既然这么说了，下面就会分成两 个部分：client主动关闭，server主动关闭。Client
7、主动关闭，Server被动关闭：Client主动关闭，Server被动关闭的情况还是蛮多的，比如说短连接中，当一次会话结束时，client就可以关闭它与server之间的连接。我们这边直接说close而非shutdown。当client想要关闭它与server之间的连接，首先client这边会首先调用close函数，client端会发送一 个FIN到server 端，client 端处于 FIN_WAIT状态。当 server 端返回给 clientACK 后，client 处于 FIN_WAIT2 状态，server 处于CLOSE_WAIT态。当server端检测到client端的关闭操作
8、（read返回为0），server端也需要调用close操作，server端会 向client端发送一个FIN。此时server的状态为LAST_AC，当client 收到来自server的FIN后，client端的 套接字处于TIME_WAI状态，它会向server端再发送一个ack确认，此时server端收到ack确认后，此套接字 处于CLOSES态。Server端主动关闭的流程与Client端关闭类似，就不再多讲，下面还需要关注的是TIME_WAI这个状态，分别按照client/server 两个部分讲述。首先说一下TCP/IP详解中描述的关于TIME_WAI的描述及其存在的必要性：主动
9、关闭的socket当收到对端的FIN操作后，该socket就会处于TIME_WAI状态，处于TIME_WAI状态的 socket 会存活 2MSL（Max Segment Lifetime）,之所以存活这么长时间是有理由的：一方面是可靠的实现TC全双工连接的终止，也就是当最后的 AC丢失后，被动关闭端会重发FIN,因此 主动关闭端需要维持状态信息，以允许它重新发送最终的ACK另一方面TC在2MS等待期间，定义这个连接（4元组）不能再使用，任何迟到的报文都会丢弃。设想如 果没有2MS的限制，恰好新到的连接正好满足原先的4元组，这时候连接就可能接收到网络上的延迟报文就 可能干扰最新建立的连接。重复
10、的分节在网络中消逝。3. Server端的监听套接字与会话套接字的不同：当server端的socket调用bind和listen之后，监听套接字的状态就会变为LISTEN犬态，监听套接字的 工作决定了它只是监听连接。当server端调用accept，相当于从套接字的完成队列中取出一个 client的连接，此时可以确定四元组，即：client的IP和port;server的IP和port，双方各有一个套接字进行交互，这里需要说一下 server端 的socket，我称server端accept后产生的套接字为会话套接字，这个套接字一出生的状态就是 ESTABLISH 由server端得四元组我们
11、可以看出，一个server从理论上可以接收的连接数量取决于文件描述符的个数。4, 状态为TIME_WAI是不是所有执行主动关闭的socket都会进入TIME_WAI状态呢？有没有什么情况使主动关闭的socket直接进入CLOSE状态呢？主动关闭的一方在发送最后一个 ack后就会进入TIME_WAIT状态 停留2MSL（max segment lifetime）时间，这个是TCP/IP必不可少的，也就是“解决”不了的。也就是 TCP/IP设计者本来是这么设计的。主要有两个原因：1。 防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL上一次连接中所有的重复包都 会消失）2。 可靠的关闭
12、TC连接。在主动关闭方发送的最后一个 ack（fin），有可能丢失，这时被动方会重新发fin, 如果这时主动方处于CLOSED犬态，就会响应rst而不是ack。所以主动方要处于TIME_WAIT 状态，而不能是 CLOSEDo特别提示的是：为什么TIME_WAI状态还需要等待2MS才能回到CLOSE状态？或者为什么TC要引入TIME_WAI 状态？TCP/IP详解中如此解释：当TC执行一个主动关闭，并发回最后一个 ACI后，该连接必须在TIME_WAI状态停留的时间为2倍的MSL这样可以让TCP!次发送最后的AC以防止这个AC丢失（另一端超时 重发最后的FIN） o附注：MSL（Maximum
13、 Segment Lifetime）即最大生存时间，RFC 79沖指出MS为2分钟，但是实现中的常用值为30秒、1分钟或者2分钟。建立TC连接（三次握手）由于TC协议提供可靠的连接服务，于是采用有保障的三次握手方式来创建一个TCP!接。三次握手的具体过程如下：客户端发送一个带SY标志的TCP艮文（报文1）到服务器端，表示希望建立一个TCPS接。服务器发送一个带AC标志和SY标志的TCP艮文（报文2）给客户端，ACI用于对报文1的回应，SY!用于询 问客户端是否准备好进行数据传输。客户端发送一个带AC标志的TCP艮文（报文3），作为报文2的回应。至此，一个TCP!接就建立起来了。终止TC连接（四
14、次挥手）由于TC连接是全双工的，因此每个方向都必须单独进行关闭。原则是主动关闭的一方（如已传输完所有数据等原因）发送一个FIN报文来表示终止这个方向的连接，收到一个 FIN意味着这个方向不再有数据流 动，但另一个方向仍能继续发送数据，直到另一个方向也发送FIN报文。四次挥手的具体过程如下:客户端发送一个FIN报文（报文4）给服务器，表示我将关闭客户端到服务器端这个方向的连接。服务器收到报文4后，发送一个ACI报文（报文5）给客户端，序号为报文4的序号加1。服务器发送一个FIN报文（报文6）给客户端，表示自己也将关闭服务器端到客户端这个方向的连接。客户端收到报文6后，发回一个ACI报文（报文7）
15、给服务器，序号为报文6的序号加1。至此，一个TC连接就关闭了。（4次挥手不是关闭TC连接的唯一办法，见下文Q3疑问）TCP三次握手，四次挥手的时序图:ClientServerGlwnt StatmESTABLISHEDF卅理ArT)F1M WAIT-2Receive Ciec* Signal From App.Send FwvWait for ACK and FIN From ServerACKWail for Server RMTIME-WAJTReceive FIN. Send ACKwiit For Doubl*Maximum SegmentUfe (M SL) TimeNarmal O
16、perationRecetve HN.Send计Tll App To CIxm j(Wait for App)App itTqi pCtose, Send AW (,W罩it伽AUK to FtNReceive ACK rCLOSED曰 tablishe可TCP相关疑问几个常见的TCP/IP相关的疑问:Q1为什么在TC协议里，建立连接是三次握手，而关闭连接却是四次握手呢？A1因为当处于LISTEN状态的服务器端SOCKET收到SY服文（客户端希望新建一个TCP!接）后，它可以 把ACK应答作用）和SYN同步作用）放在同一个报文里来发送给客户端。但在关闭 TCP!接时，当收到对方的 FIN报文时
17、，对方仅仅表示对方没有数据发送给你了，但未必你的所有数据都已经全部发送给了对方，所以 你大可不必马上关闭SOCKETS送一个FIN报文），等你发送完剩余的数据给对方之后，再发送 FIN报文给对 方来表示你同意现在关闭连接了，所以通常情况下，这里的AC服文和FIN报文都是分开发送的。Q2为什么TIME_WAIT状态还需要等2*MSI秒之后才能返回到CLOSED犬态呢?A2因为虽然双方都同意关闭连接了，而且握手的 4个报文也都发送完毕，按理可以直接回到 CLOSED犬 态（就好比从SYN_SEN犬态到ESTABLISH犬态那样），但是我们必须假想网络是不可靠的，你无法保证你 （客户端）最后发送的A
18、C报文一定会被对方收到，就是说对方处于 LAST_ACK犬态下的SOCKETT能会因为超 时未收到AC报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的 AC报文。Q3关闭TC连接一定需要4次挥手吗？A3不一定，4次挥手关闭TC连接是最安全的做法。但在有些时候，我们不喜欢 TIME_WAIT状态（如当 MS数值设置过大导致服务器端有太多TIME_WAPR态的TCI连接，减少这些条目数可以更快地关闭连接，为 新连接释放更多资源），这时我们可以通过设置SOCKET量的SO_LINGE标志来避免SOCKE在close（）之后进 入TIME_WAI状态，这时将通过发送RST虽制终止TCI连接（取代正常的TCI四次握手的终止方式）。但这并不 是一个很好的主意，TIME_WA IT对于我们来说往往是有利的。