http://blog.csdn.net/du_zou/article/details/5598885 2010 1 A: 独奏大哥我给你发经典合集都发完了(FIN) 2 B: 恩..都收到了..(ACK) 3 B: 那今天就到这喽,下次要有好的记得分享哦..(FIN) 4 A: 恩.好的...(ACK)
(摘自tcpip协议卷) 这就是tcp四次握手断开的过程.那可能有人会有疑问.在tcp连接握手时为何 ACK是和SYN一起发送.这里ACK却没有何FIN一起发送呢. 原因是因为tcp是全双工模式.接收到FIN时意味将没有数据再发来..但是还是可以继续发送数据.. (摘自tcpip协议卷) 下面我们来把这幅图几个状态说明下 LISTEN : 监听状态. SYN_SENT : 已发送SYN同步会变为这个状态.等待服务端的SYN和ACK确认. SYN_RECV: 当收到客户端的SYN时变为此状态.这时将发送SYN及这个报文的ACK(合并SYN+ACK) ESTABLISHEN: 双方连接建立 FIN_WAIT_1: 当准备关闭连接时,将进入这个状态并发送FIN.确认后会变为FIN_WAIT_2 FIN_WAIT_2: 实际这个状态就是在客户端发送FIN并得到确认后等待服务端的FIN报文 CLOSE_WAIT: 当被动关闭方收到FIN时会迁移到这个状态.如果此时应用层所有数据都已发送完毕则.迁移到LAST_ACK并发送FIN给客户端,并等待客户端的最后确认,如果在一定时间内没有收到最后的ACK确认则服务端会重新发送FIN.直到发送超时.直接关闭连接. LAST_ACK :服务端发送FIN后等待客户端的最后确认.收到确认后则双方数据流均关闭可以关闭了此连接了 TIME_WAIT: 当客户端吧收到被动关闭方的FIN后意味只要发送最后一ACK就可以最终关闭连接.那为何发送ACK后不直接关闭连接而是保持在TIME_WAIT呢.按上面说的如果客户端发送的最后一个ACK由于网络原因没有到达服务端.服务端会重新发送FIN.TIME_WAIT就是为了接受服务端重新发送的FIN,并重发丢失的ACK报文..这个状态持续时间会有2MSL,MSL就是一个报文在被丢弃前网络上的最长时间..tcpip协议卷上说 MSL会有两分钟....具体的可能跟实现不同.我就不知道了..没测试过喽..O(∩_∩)O~ CLOSED: 连接关闭 (摘自tcpip协议卷) 还有个CLOSEING状态是在同时关闭时,当客户端发送FIN后进入FIN_WAIT_1等待服务端的ACK.这时接受的却不是ACK,而是服务端发送的FIN,这种情况一般是当双发同时发送FIN.会进入CLOSING状态.随机收到各自的ACK后双发都会进入TIME_WAIT状态
|
|