服务器time_wait状态原因

通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态

TIME_WAIT状态的时间是2倍的MSL(最大生存时间),在TIME_WAIT状态TCP连接实际上已经断掉,但是该插口又不能被新的连接实例使用。这种情况一般都是程序中建立了大量的短连接。

那么http 服务是谁主动关闭连接呢?

http 1.0时代,如果不设置KeepAlive,默认都是短连接,服务器主动关,否则就看本地浏览器和web各自的设置了,基本都是某个间隔不活跃就断开,两边都可以。HTTP 1.1时代,默认就是长连接,类似HTTP 1.0外加KeepAlive,那边主动关都可以,依然看本地浏览器设置和web服务器设置。
在http1.1协议中,对于客户端(browser)的一个请求,如果返回Connection:Close,不是告诉客户端让客户端关闭连接,而是服务端之后主动关闭连接

http://www.zhihu.com/question/24338653
HTTP是请求-响应模式的,而有时候会以关闭连接来表示数据发送完毕,所以在其协议定义中有个字段来表示谁关闭连接。

HTTP1.0/1.1都支持持久连接

在1.1中,如果客户端在请求中使用Connection: Close ,服务器端就会在发送完响应后从容关闭连接。但是即使客户端要求使用持久连接,但是服务器也有权在响应完请求后主动关闭连接,但是要在响应头在包含Connection: Close 。

1.0和1.1一样,但是HTTP1.1默认是持久连接的,而且HTTP1.0不是
考虑两种方式:持久连接和非持久连接
这两种连接方式首先取决于http服务器是否支持
标准HTTP服务器支持这两种方式,特殊HTTP服务器只支持非持久连接

持久连接和非持久连接都是服务器端/IE端均可控制的
控制方式是用Connection : xxxxx字段
Connection: Close告诉对方这次传输结束以后关闭socket
Connection: Alive告诉对方这次传输结束以后可以再次利用这个socket

以下模拟持久连接:
IE Request 包含Connection:Alive -> HTTP服务器返回网页,HTTP头部包含 Connection: Alive -> IE在HTTP头部描述的字节数接收完毕以后提交下一个请求,其中继续包含 Connection: Alive -> HTTP服务器继续返回网页

以下模拟非持久连接:
IE Request 包含Connection:Alive -> HTTP服务器返回网页,HTTP头部包含 Connection: Close,表示自己无视IE的Alive请求 -> IE在HTTP头部描述的字节数接收完毕以后关闭socket

需要说明的是,对于持久连接,Server返回的HTTP头部必须包含一个内容大小字段用来确定IE需要接收的data字节,否则持久连接就会发生问题,因为IE无法获知自己什么时候应该发送下一个请求.所以无法确定data字段大小的时候,服务器必须在适当的时候(通常是data发送结束)主动关闭socket
时间: 2024-11-15 14:07:03

服务器time_wait状态原因的相关文章

TCP/IP协议--TIME_WAIT状态存在的原因

1. 实际问题         初步查看发现,无法对外新建TCP连接时,线上服务器存在大量处于TIME_WAIT状态的TCP连接(最多的一次为单机10w+,其中引起报警的那个模块产生的TIME_WAIT约2w),导致其无法跟下游模块建立新TCP连接. TIME_WAIT涉及到TCP释放连接过程中的状态迁移,也涉及到具体的socket api对TCP状态的影响,下面开始逐步介绍这些概念. 2. TCP状态迁移        面向连接的TCP协议要求每次peer间通信前建立一条TCP连接,该连接可抽

处于CLOSE_WAIT和TIME_WAIT状态连接的原因及解决

常用的三个状态是:ESTABLISHED   TIME_WAIT   CLOSE_WAIT ESTABLISHED 表示正在通信,TIME_WAIT 表示主动关闭,CLOSE_WAIT 表示被动关闭. 具体每种状态什么意思,其实无需多说,看看下面这种图就明白了,注意这里提到的服务器应该是业务请求接受处理的一方: 这么多状态不用都记住,只要了解到我上面提到的最常见的三种状态的意义就可以了.一般不到万不得已的情况也不会去查看网络状态,如果服务器出了异常,百分之八九十都是下面两种情况: 1.服务器保持

最简单的回射客户/服务器程序、time_wait 状态

下面通过最简单的客户端/服务器程序的实例来学习socket API. echoser.c 程序的功能是从客户端读取字符然后直接回射回去. C++ Code 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 6

TIME_WAIT状态及存在原因

1. 客户端与服务器端建立TCP/IP连接后关闭SOCKET后,服务器端连接的端口状态为TIME_WAIT: 2. 主动关闭的Socket端会进入TIME_WAIT状态,并且持续2MSL时间长度,MSL就是maximum segment lifetime(最大分节生命期):     这是一个IP数据包能在互联网上生存的最长时间,超过这个时间将在网络中消失.     MSL在RFC 1122上建议是2分钟,而源自berkeley的TCP实现传统上使用30秒,因而,TIME_WAIT状态一般维持在1

LINUX下解决netstat查看TIME_WAIT状态过多问题(转)

原文连接:www.itokit.com/2012/0516/73950.html # netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c 16 CLOSING     130 ESTABLISHED     298 FIN_WAIT1      13 FIN_WAIT2       9 LAST_ACK       7 LISTEN     103 SYN_RECV    5204 TIME_WAIT 状态:描述 CLOSED:无连接是活动的或正在进行

TIME_WAIT状态原理(转)

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

TCP四次挥手时TIME_WAIT状态以及端口号的分类

TIME_WAIT(时间等待计时器)状态是什么? 简单来说,TIME_WAIT状态是四次挥手中服务器向客户端发送FIN终止连接后进入的状态. 四次挥手的过程: 可以看到TIME_WAIT状态存在于客户端收到服务器FIN并返回ACK时的状态. 当处于TIME_WAIT状态时,我们无法创建新的连接,因为端口被占用. 2. 为什么会有TIME_WAIT状态? 原因如下两点: <1> 可靠的终止TCP连接 若处于TIME_WAIT的客户端发送给服务器确认报文段丢失的话,服务器将在此重新发送FIN报文

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

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