好一个Time_Wait状态(TCP/IP)

首先简单介绍一下Time_Wait是个什么鬼:

在TCP/IP协议中,我们都知道有三次握手四次挥手的过程,先来一个简单的图:

各个状态和基本的过程想必了解过TCP/IP协议的人都清楚,本次介绍的主题只有Time_Wait状态。(Ps:本文统一将主动断开连接方称A,被动断开连接方称B)

1,Time_Wait状态是什么结点产生的?

  在A发送Fin被B接收到,B会发送ACK紧接着发送Fin以后,A接收到另一方发过来的Fin信号,就会将自身的状态设置为Time_Wait状态,并返回一个ACK。

2,为什么需要有一个Time_Wait状态?

  主要有两个原因:⑴ 可靠地实现TCL全双工连接的终止;⑵允许老的重复分节在网络中消逝。

3,分别解释一下上述两种具体的实现过程?

  ⑴ A发送最后一次ACK后,会处于Time_Wait状态下,此时并没有断开连接,若最后一次ACK没有正常发送给B,则B检测超时后会再次发送确认的Fin,此时A处于Time_Wait状态就能正常接收并再次发送确认ACK,以确保服务器能正常断开连接。Time_Wait(2MSL)时间超时后,A端就会自动关闭端口。

  ⑵ 假设已经有A与B建立了链接,此时A主动断开连接后,这时候发出的一个ACK,如果没有Time_Wait(2MSL)时间,直接断开连接后立即启用一个新的网络连接,如果有一个来自上个连接的数据包,会直接对当前连接连接造成影响,所以必须进行一个2MSL的等待时间。

4,为什么是2MSL时间:

  MSL时间是一个数据包在网络中最大的存活时间。如果超过这个时间,就会在网络传输中消失。一般这个时间在Window环境下就是2分钟,所以2MSL就是4分钟,这个具体的时间根据环境不同有所减少。而之所以是2MSL,主要原因在两个端口之间进行传输,从传输到B端口再从B端口传回来,至少需要2个包,所以规定的时间为2MSL。

5,若是在Time_Wait时间内,还是由于一些原因(路由异常,数据处理延迟,等待超时),造成最后一个ACK没能正常到达,服务器会怎么样?

  首先,若服务器多次发Fin得不到回应,根据项目不同,必然是有响应的超时异常处理,但一般情况下不会很少出现这种极端情况,所以哪怕在A端已经关闭,B端发送一个Fin之后,A端也会反馈一个RST分节,这个数据包会在B端被识别成异常错误。

6,如果在Time_Wait状态ACK数据丢失,那A与B如果再次进行数据确认?

  TCP协议提供一种超时重传机制,主要根据TCP提供的定时器进行控制,而这种情况下的重传,时间为RRT(数据往返时间),由于路由器和网络流量均会变化,所以RRT时间也是经常变动的。这个时间长短的变动同样是TCP进行监控修改的。具体算法请参考TCP/IP详解:卷一。

7,Time_Wait状态必须等待2MSL时间吗?

  当然不是,某些特殊情况A端需要进行大量并且快速的建立连接-断开连接的操作,所以我们有时候不能接受2-4分钟左右的重新等待时间,这时候可以通过设置TCP的配置文件 /etc/sysctl.conf 来改变Time_Wait状态的时间,具体修改内容如下:

编辑文件,加入以下内容:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30

然后执行/sbin/sysctl -p让参数生效。

net.ipv4.tcp_syncookies = 1表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;

net.ipv4.tcp_tw_reuse = 1表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;

net.ipv4.tcp_tw_recycle = 1表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。

net.ipv4.tcp_fin_timeout修改系統默认的TIMEOUT时间

修改之后,再用命令查看TIME_WAIT连接数netstat -ant |grep “TIME_WAIT” |wc –l

在没有nat情况下还需要设置net.ipv4.tcp_timestamps = 1才能生效。

8,若设置了上述时间,我们如何确保Time_Wait的两个作用?

  若要设置快速重用的属性,前提也必须设置net.ipv4.tcp_timestamps = 1,TCP就会为数据包添加两个”字节时间字段”,第一个4字节记录发送该数据包的时间,第二个4字节字段用来保存最近一次接受对方发送到数据的时间。有了时间段,我们就可以通过计算时间,来防止延迟的数据到达。但确保双关性可能会出现问题,但就算A段快速关闭,数据丢失下B段重发Fin,会回复一个RST包,表达是异常。

上述大部分都是通过TCP/IP协议与博客了解,部分是通过与朋友讨论总结,若出现错误,请大神们指点

时间: 2024-11-03 20:59:36

好一个Time_Wait状态(TCP/IP)的相关文章

TCP/IP TIME_WAIT状态原理

TIME_WAIT状态原理 ---------------------------- 通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个ack后,然后会进入TIME_WAIT状态,再停留2个MSL时间(后有MSL的解释),进入CLOSED状态. 下图是以客户端主动关闭连接为例,说明这一过程的. TIME_WAIT状态存在的理由 ---------------------------- TCP/IP协议就是这样设计的,是不可避免的.主

TCP/IP中TIME_WAIT状态详解

TIME_WAIT状态原理: 通信双方建立连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个ACK确认,然后就会进入TIME_WAIT状态,再停留2MSL,就会进入CLOSED状态. 接下来我们看一张图,来说明这一过程: 上图是TCP"四次挥手"的过程,相信你们都会很了解,下面我们来说说为什么要存在TIME_WAIT状态 TIME_WAIT状态存在的理由如下: (1)可靠地实现TCP全双工连接的终止 TCP协议在关闭连接的四次挥手中,最终的

TCP/IP状态图的TIME_WAIT作用

在TCP/IP状态图中,有很多种的状态,它们之间有的是可以互相转换的,也就是说,从一种状态转到另一种状态,但是这种转换不是随便发送的,是要满足一定的条件.TCP/IP状态图看起来更像是自动机.下图即为TCP/IP状态. 由上图可以看出,一共有11种不同的状态.这11种状态描述如下: CLOSED:关闭状态,没有连接活动或正在进行: LISTEN:监听状态,服务器正在等待连接进入: SYN_RCVD:收到一个连接请求,尚未确认: SYN_SENT:已经发出连接请求,等待确认: ESTABLISHE

TCP协议(二)——TIME_WAIT状态

当TCP主动关闭套接字时,采用四步握手机制来彻底关闭连接.如图: 客户端主动关闭连接,发送FIN段到服务端.TCP状态由ESTABLISHED(连接状态)转为FIN_WAIT1(表示,发送的FIN需要确认). 服务端接受FIN后,服务端的TCP状态由ESTABLISHED转为CLOSE_WAIT,并且回送ACK. 客户端接受确认ACK后,TCP状态由FIN_WAIT1转化为FIN_WAIT2(表示已经确认FIN,等待来自服务端的FIN请求). 服务端发送FIN,TCP状态CLOSE_WAIT转为

Windows操作系统error10048端口释放问题TIME_WAIT状态的TCP连接快速回收时间

本文来自于https://blog.csdn.net/stillfantasy1988/article/details/43196627?tdsourcetag=s_pcqq_aiomsg.http://www.huawei.com/ecommunity/bbs/10221255.html 1.问题 大规模Windows环境下,采用Nginx反向代理服务后,操作系统会产生较多TIME_WAIT的TCP(Transmission Control Protocol)连接,操作系统默认TIME_WAI

TIME_WAIT状态原理(转)

---------------------------- 转自:http://elf8848.iteye.com/blog/1739571 通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个ack后,然后会进入TIME_WAIT状态,再停留2个MSL时间(后有MSL的解释),进入CLOSED状态. 下图是以客户端主动关闭连接为例,说明这一过程的. TIME_WAIT状态存在的理由 --------------------------

TCP/IP 3握手4挥手

转:摘自<图解TCP/IP>P204 三次握手与四次挥手的状态转移图如下: 如图,由于第二次握手接收端发送SYN+ACK信号所以握手只用了三次,挥手由于接收端ACK和FIN分两次发的,所以挥手需要四次. 最后接收端需要一个TIME_WAIT状态,如果TCP client端最后一次发送的ACK丢失了,它将重新发送.TIME_WAIT状态中所需要的时间是依赖于实现方法的.典型的值为30秒.1分钟和2分钟.等待之后连接正式关闭,并且所有的资源(包括端口号)都被释放. 整个Client(发送端)状态图

第三篇:关于TIME_WAIT状态

前言 为何TCP ”四次分手“ 的过程中会有一个TIME_WAIT状态?这个状态有什么意义呢?这是网络中的一个经典问题,本文将给出精简的回答. 什么是TIME_WAIT状态 这是TCP通信协议中出现的一个状态,端点会在这个状态停留2MSL( 最长分节生命期 ),参见下图: 左下方的那个状态即是. TIME_WAIT状态存在意义之一 假设上图中,最后的那个ack分节传递失败了,那么服务器端会要求客户端再传递一次这个分节.如果没有此状态( 客户端直接退出 ),那就无法重传这段丢失了的分节( 所有对客

网络基础tcp/ip协议一

计算机网络: 硬件方面:通过线缆将网络设备和计算机连接起来 软件方面:操作系统,应用软件,应用程序通过通信线路互连 实现资源共享,信息传递 计算机网络的功能: 数据通信 资源共享 增加可靠性 提高系统处理能力 网络协议与标准:一组控制数据通信的规则 协议三要素: 语法 语义 同步 标准;一致同意的规则可以理解为标准 ISO   (国际标准化组织) ANSI  (美国国家标准局) ITU-T (国际电信联盟-电信标准部) IEEE  (电气和电子工程师学会) WAN与LAN 广域网(WAN) 范围