博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
tcp断开四次握手
阅读量:4881 次
发布时间:2019-06-11

本文共 1160 字,大约阅读时间需要 3 分钟。

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状态

转载于:https://www.cnblogs.com/chasu/p/3286317.html

你可能感兴趣的文章
python使用httplib2访问REST服务的例子
查看>>
经典代码(01)
查看>>
生成ico格式图标
查看>>
并查集hdu4424
查看>>
【异常】IOException parsing XML document from class path resource [xxx.xml]
查看>>
第五周作业
查看>>
COJ 2135 Day10-例1
查看>>
jdbc之分页查询
查看>>
PHP手动环境搭建之WAMP
查看>>
COJ 1003 WZJ的数据结构(三)ST表
查看>>
sbrk and coreleft
查看>>
树型DP
查看>>
怎么在ubuntu上使用pidgin登陆QQ
查看>>
思维的惰性
查看>>
2018-2019-2 网络对抗技术 20165115 Exp3 免杀原理与实践
查看>>
【Android】学习记录<1> -- 初识ffmpeg
查看>>
定位页面元素的位置
查看>>
关于IAsyncResult接口的CompletedSynchronously属性
查看>>
Python:一篇文章掌握Numpy的基本用法
查看>>
序列化与ArrayList 的elementData的修饰关键字transient
查看>>