TCP连接的四次挥手
来源:互联网 发布:淘宝对中国经济的影响 编辑:程序博客网 时间:2024/06/02 22:43
1) socket 客户端 FIN_WAIT_2,而设备端显示CloseWait
这个原因是服务器端没有及时CloseSocket;
下面讲解下socket的断开流程:
TCP报文段首部格式:
序号:本报文段所发送的数据的第一个字节的序号。
确认号ack:期待收到对方下一个报文段的第一个数据字节的序号
确认ACK:占1位,仅当ACK=1时,确认号字段才有效。ACK=0时,确认号无效
同步SYN:连接建立时用于同步序号。当SYN=1,ACK=0时表示:这是一个连接请求报文段。 若同意连接,则在响应报文段中使得SYN=1,ACK=1。因此,SYN=1表示这是一个连接请求,或连接接受报文。终止FIN:用来释放一个连接。FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接;
建立TCP连接为什么需要三次握手?
还要再发送一次确认是为了,防止已失效的连接请求报文段突然又传到了B,因而产生错误。
已失效的报文段:正常情况下:A发出连接请求,但因为丢失了,故而不能收到B的确认。于是A重新发出请求,然后收到确认,建立连接,数据传输完毕后,释放连接,A发了2个,一个丢掉,一个到达,没有“已失效的报文段”,但是,某种情况下,A的第一个在某个节点滞留了,延误到达,本来这是一个早已失效的报文段,但是在A发送第二个,并且得到B的回应,建立了连接以后,这个报文段竟然到达了,于是B就认为,A又发送了一个新的请求,于是发送确认报文段,同意建立连接,假若没有三次的握手,那么这个连接就建立起来了(有一个请求和一个回应),此时,A收到B的确认,但A知道自己并没有发送建立连接的请求,因为不会理睬B的这个确认,于是呢,A也不会发送任何数据,而B呢却以为新的连接建立了起来,一直等待A发送数据给自己,此时B的资源就被白白浪费了。但是采用三次握手的话,A就不发送确认,那么B由于收不到确认,也就知道并没有要求建立连接。
TIME_WAIT 是主动关闭 TCP 连接的那一方出现的状态,系统会在 TIME_WAIT 状态下等待 2MSL(maximumsegment lifetime)后才能释放连接(端口)。
CLOSE_WAIT 是被动关闭 TCP 连接时产生的,如果收到另一端关闭连接的请求后,本地不关闭相应套接字就会导致本地套接字进入这一状态。如果存在大量的 CLOSE_WAIT,说明客户端并发量大,且服务器未能正常感知客户端的退出,也并未及时 close 这些套接字。
本文转自:http://blog.csdn.net/smilestone322/article/details/8703654
- TCP连接的四次挥手
- TCP连接四次挥手
- tcp关闭连接时的四次挥手
- tcp断开连接时的四次挥手
- TCP连接的三次握手,四次挥手
- TCP的三次连接和四次挥手
- TCP连接释放的四次挥手过程?
- TCP的四次挥手
- TCP关闭连接(四次挥手)
- TCP四次挥手释放连接
- TCP的四次挥手(TCP的连接释放)
- TCP学习(3)--TCP释放连接的过程(四次挥手)
- TCP/IP的三次握手连接和四次挥手关闭
- socket中TCP的四次挥手释放连接详解
- TCP协议建立连接的三次握手四次挥手机制
- TCP连接的“三次握手”与“四次挥手”
- TCP连接的三次握手和四次挥手
- TCP连接的终止(四次挥手)图解
- DataSet 操作 XML 文件的方法
- c语言,模仿js中split方法的函数
- Fedora18下怎么设置开机命令行窗口
- 深入理解redo之1
- vs2008下DShow开发环境配置
- TCP连接的四次挥手
- hadoop学习笔记(9)-Number of Under-Replicated Blocks问题
- Project configuration is not up-to-date with pom.xml. Run Maven->Update Project or use Quick Fix.
- collabnet 配置
- 原型模式
- 实现Android 版网页快照功能
- C语言:malloc()函数与alloc()函数
- 2013腾讯编程马拉松初赛第一场(3月21日) 解题报告 (HDU 4505 HDU4506 HDU4507 HDU4508 HDU4509)
- hadoop1.0.4 eclipse插件编译