tcp 连接详细关闭过程
来源:互联网 发布:linux安装tar.xz文件 编辑:程序博客网 时间:2024/05/29 03:20
简单说来是 “先关读,后关写”,一共需要四个阶段。以客户机发起关闭连接为例:
1.服务器读通道关闭
2.客户机写通道关闭
3.客户机读通道关闭
4.服务器写通道关闭
关闭行为是在发起方数据发送完毕之后,给对方发出一个FIN(finish)数据段。直到接收到对方发送的FIN,且对方收到了接收确认ACK之后,双方的数据通信完全结束,过程中每次接收都需要返回确认数据段ACK。
详细过程:
这是标准的TCP关闭两个阶段,服务器和客户机都可以发起关闭,完全对称。
FIN标识是通过发送最后一块数据时设置的,标准的例子中,服务器还在发送数据,所以要等到发送完的时候,设置FIN(此时可称为TCP连接处于半关闭状态,因为数据仍可从被动关闭一方向主动关闭方传送)。如果在服务器收到FIN(i)时,已经没有数据需要发送,可以在返回ACK(i+1)的时候就设置FIN(j)标识,这样就相当于可以合并第二步和第三步。
服务器端首先执行 LISTEN 原语进入被动打开状态( LISTEN ),等待客户端连接;
当客户端的一个应用程序发出 CONNECT 命令后,本地的 TCP 实体为其创建一个连接记录并标记为 SYN SENT 状态,然后给服务器发送一个 SYN 报文段;
服务器收到一个 SYN 报文段,其 TCP 实体给客户端发送确认 ACK 报文段同时发送一个 SYN 信号,进入 SYN RCVD 状态;
客户端收到 SYN + ACK 报文段,其 TCP 实体给服务器端发送出三次握手的最后一个 ACK 报文段,并转换为 ESTABLISHED 状态;
服务器端收到确认的 ACK 报文段,完成了三次握手,于是也进入 ESTABLISHED 状态。
在此状态下,双方可以自由传输数据。当一个应用程序完成数据传输任务后,它需要关闭 TCP 连接。假设仍由客户端发起主动关闭连接。
客户端执行 CLOSE 原语,本地的 TCP 实体发送一个 FIN 报文段并等待响应的确认(进入状态 FIN WAIT 1 );
服务器收到一个 FIN 报文段,它确认客户端的请求发回一个 ACK 报文段,进入 CLOSE WAIT 状态;
客户端收到确认 ACK 报文段,就转移到 FIN WAIT 2 状态,此时连接在一个方向上就断开了;
服务器端应用得到通告后,也执行 CLOSE 原语关闭另一个方向的连接,其本地 TCP 实体向客户端发送一个 FIN 报文段,并进入 LAST ACK 状态,等待最后一个 ACK 确认报文段;
客户端收到 FIN 报文段并确认,进入 TIMED WAIT 状态,此时双方连接均已经断开,但 TCP 要等待一个 2 倍报文段最大生存时间 MSL ( Maximum Segment Lifetime ),确保该连接的所有分组全部消失,以防止出现确认丢失的情况。当定时器超时后, TCP 删除该连接记录,返回到初始状态( CLOSED )。
服务器收到最后一个确认 ACK 报文段,其 TCP 实体便释放该连接,并删除连接记录,返回到初始状态( CLOSED )。
- tcp 连接详细关闭过程
- TCP连接关闭过程笔记
- TCP连接与关闭过程
- TCP连接关闭过程笔记
- TCP连接关闭过程笔记
- TCP连接关闭过程笔记
- TCP连接关闭过程笔记
- TCP连接的关闭过程
- 深入理解tcp关闭连接的过程
- TCP连接和关闭的过程
- TCP三次握手和连接关闭过程详解
- TCP建立/关闭连接时握手过程中的状态情况
- TCP关闭过程
- tcp的关闭过程
- TCP连接关闭总结
- 关闭tcp连接
- TCP连接的关闭
- TCP连接关闭
- C++ 迭代器类型
- 使用scp在windows和Linux之间互传文件
- UNIX 高手的 10 个习惯
- hdu3033(分组背包二次dp处理)
- weblogic10.3 java.lang.OutOfMemoryError: PermGen space
- tcp 连接详细关闭过程
- VS2010中各种文件的说明
- 启动文件选取的按钮
- 【TFS】TFS中定义自己的工作项(WorkItems)模板
- 工程在release下报错,但是在debug下正常执行
- MSSQL 自定义函数详解
- Flex模型对象的数据绑定
- word 2007中的公式编辑器
- 多文档的一些操作:启动时不自动打开一个空文档、启动时主窗体最大化显示、打开一个子窗体时最大化显示