免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 6219 | 回复: 2

TCP/IP状态转换图的分析 [复制链接]

论坛徽章:
0
发表于 2010-01-26 10:36 |显示全部楼层

file:///D:/My%20Documents/绘图3.jpg
file:///D:/My%20Documents/绘图1.jpg
状态转换图中状态的描述:
CLOSED:无连接是活动的或正在进行
LISTEN:服务器在等待进入呼叫
SYN_RECV:一个连接请求已经到达,等待确认
SYN_SENT:应用已经开始,打开一个连接
ESTABLISHED:正常数据传输状态
FIN_WAIT1:应用说它已经完成
FIN_WAIT2:另一边已同意释放
ITMED_WAIT:等待所有分组死掉
CLOSING:两边同时尝试关闭
TIME_WAIT:另一边已初始化一个释放
LAST_ACK:等待所有分组死掉
TCP/IP状态转换图的分析
    其中,EATABLISHED是数据的传送状态。我们主要分析主动关闭这个框内的转换状态。
    当客户端应用程序主动请求关闭时,调用close或shutdown关闭连接,这时应用程序发送FIN,然后进入FIN_WAIT_1状态,等待服务器端发送确认包ACK,接受到服务器端的ACK以后,然后客户端进入FIN_WAIT_2状态,等待服务器端调用close,并发送FIN,当客户端接受到FIN后,发送ACK,进入最终的TIME_WAIT状态,这结合着TCP关闭连接时的分组交换连接图可以更加的明白。需要注意的是,执行主动关闭的那一端进入TIME_WAIT状态。留在TIME_WAIT的持续的时间是MSL(最长分节生命周期 maximum segment lifttime)时间的两倍,也就是2MSL. MSL一般情况下是30秒到2分种,所以TIME_WAIT的时间一般为1-4分种。

   下面是(《Unix 网络编程第一卷》关于TIME_WAIT状态存在的理由)
   存在TIME_WAIT状态有两个理由:
1.  实现终止TCP全双工连接的可靠性
假设最终的ACK丢失,服务器将重发最终的FIN,因此客户必须维护状态信息以允许它重发最终的ACK,如果不维护状态信息,它将响应以RST,而服务器则把该分节解释成一个错误,如果TCP打算执行所有必要的工作以彻底终止某个连接上两个方向的数据流,那么它必须,能够处理连接终止序列四个分节中任何一个分节的丢失的情况,主动关闭的那一端必须进入TIME_WAIT状态,因为它可能不得不重发最终的ACK。
2.  允许老的重复分节的网络中消失。
我们假设206.62.226.33端口1500和198.162.10.2端口21之间有一个TCP连接,我们关闭这个连接后,在以后某个时候又重新建立起相同的IP地址和端口之间的TCP连接。后一个连接称为前一个连接的化身,因为它们的IP地坛和端口号是相同的,TCP必须防止来自某个连接的老重复分组在连接终止后再现,从而被误解成属于同一个连接的化身。要实现这种功能TCP不能给处于TIME_WAIT状态的启动新的化身,既然TIME_WAIT状态的待续时间是2MLS,这就足够让某个方向上的分组最多存活MSL秒即被丢弃,另一个方向上的应答最多存活MSL秒也被丢弃,通过实施这个规则,我们就能保证当成功建立一个TCP连接时,来自该连接先前的化身的老重复分组都已在网络中消逝了。



本文来自ChinaUnix博客,如果查看原文请点:http://blog.chinaunix.net/u3/104447/showart_2160636.html

论坛徽章:
0
发表于 2011-07-19 23:31 |显示全部楼层
谢谢!

论坛徽章:
0
发表于 2011-09-06 10:30 |显示全部楼层
支持了
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP