TCP - WAIT状态及其对繁忙的服务器的影响

TCP有一个TIME—WAIT状态.通常有2分钟。在一个繁忙的网站,2分钟常常有数千个访问请求.假设服务器A的处理能力比B大两倍,但服务器A有数千个TIME~wAIT状态.那么服务器B将在这2分钟内承受巨大的压力.

下面我来解释一下 TIME_WAIT 状态:

MSL(最大分段生存期)指明TCP报文在Internet上最长生存时间,每个具体的TCP实现都必须选择一个确定的MSL值。RFC 1122建议是2分钟。
TIME_WAIT 状态最大保持时间是2 * MSL,也就是1-4分钟。 IP头部有一个TTL,最大值255。尽管TTL的单位不是秒(根本和时间无关),我们仍需 假设,TTL为255的TCP报文在Internet上生存时间不能超过MSL。 TCP报文在传送过程中可能因为路由故障被迫缓冲延迟、选择非最优路径等等,结果发送方TCP机制开始超时重传。前一个TCP报文可以称为"漫游TCP重复报文",后一个TCP报文可以称为"超时重传TCP重复报文",作为面向连接的可靠协议,TCP实现必须正确处理这种重复报文,因为二者可能最终都到达。

一个通常的TCP连接终止可以用图描述如下:

当一个socket关闭的时候,是通过两端互发信息的四次握手过程完成的,当一端调用close()时,就说明本端没有数据再要发送了。这好似看来在握手完成以后,socket就都应该处于关闭CLOSED状态了。但这有两个问题,
第一:我们没有任何机制保证最后的一个ACK能够正常送达
第二:网络上仍然有可能有残余的数据包(wandering duplicates,或老的重复数据包),我们也必须能够正常处理。

假设最后一个ACK丢失了,服务器会重发它发送的最后一个FIN,所以客户端必须维持一个状态信息,以便能够重发ACK;如果不维持这种状态,客户端在接收到FIN后将会响应一个RST,服务器端接收到RST后会认为这是一个错误。如果TCP协议能够正常完成必要的操作而终止双方的数据流传输,就必须完全正确的传输四次握手的四个节,不能有任何的丢失。这就是为什么socket在关闭后,仍然处于 TIME_WAIT状态,因为他要等待以便重发ACK。
如果目前连接的通信双方都已经调用了close(),假定双方都到达CLOSED状态,而没有TIME_WAIT状态时,就会出现如下的情况。现在有一个新的连接被建立起来,使用的IP地址与端口与先前的完全相同,后建立的连接又称作是原先连接的一个化身。还假定原先的连接中有数据报残存于网络之中,这样新的连接收到的数据报中有可能是先前连接的数据报。为了防止这一点,TCP不允许从处于TIME_WAIT状态的socket建立一个连接。处于TIME_WAIT状态的socket在等待两倍的MSL时间以后(之所以是两倍的MSL,是由于MSL是一个数据报在网络中单向发出到认定丢失的时间,一个数据报有可能在发送图中或是其响应过程中成为残余数据报,确认一个数据报及其响应的丢弃的需要两倍的MSL),将会转变为CLOSED状态。这就意味着,一个成功建立的连接,必然使得先前网络中残余的数据报都丢失了。
由于TIME_WAIT状态所带来的相关问题,我们可以通过设置SO_LINGER标志来避免socket进入TIME_WAIT状态,这可以通过发送RST而取代正常的TCP四次握手的终止方式。但这并不是一个很好的主意,TIME_WAIT对于我们来说往往是有利的。

TIME_WAIT状态对HTTP影响

根据TCP协议,主动发起关闭的一方,会进入TIME_WAIT状态,持续2MSL(Max Segment Lifetime),缺省为240秒。值得一说的是,对于基于TCP的HTTP协议,关闭TCP连接的是Server端,这样,Server端会进入TIME_WAIT状态,可想而知,对于访问量大的Web Server,会存在大量的TIME_WAIT状态,假如server一秒钟接收1000个请求,那么就会积压2401000=240,000个TIME_WAIT的记录,维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些TIME_WAIT,所以对于新的TCP连接请求,判断是否hit中一个TIME_WAIT不会太费时间,但是有这么多状态要维护总是不好。

RFC793指出,MSL的值是2分钟,但是在实际的实现中,常用的值有以下三种:30秒,1分钟,2分钟。注意一个问题,进入TIME_WAIT状态的一般情况下是客户端,大多数服务器端一般执行被动关闭,不会进入TIME_WAIT状态,当在服务器端关闭某个服务再重新启动时,它是会进入TIME_WAIT状态的。

HTTP协议1.1版规定default行为是Keep-Alive,也就是会重用TCP连接传输多个request/response,一个主要原因就是发现了这个问题。还有一个方法减缓TIME_WAIT压力就是把系统的2*MSL时间减少,因为240秒的时间实在是忒长了点,对于Windows,修改注册表,在HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetServices TcpipParameters上添加一个DWORD类型的值TcpTimedWaitDelay,一般认为不要少于60,不然可能会有麻烦。

在做Socket 编程时,我们经常会要问,单机最多可以建立多少个 TCP 连接,介绍如何调整系统参数来调整单机的最大TCP连接数。Windows 下单机的TCP连接数有多个参数共同决定,下面一一介绍:

最大TCP连接数

[HKEY_LOCAL_MACHINE System CurrentControlSet Services Tcpip Parameters] TcpNumConnections = 0x00fffffe (Default = 16,777,214)

以上注册表信息配置单机的最大允许的TCP连接数,默认为 16M。这个数值看似很大,这个并不是限制最大连接数的唯一条件,还有其他条件会限制到TCP 连接的最大连接数。

最大动态端口数

TCP客户端和服务器连接时,客户端必须分配一个动态端口,默认情况下这个动态端口的分配范围为 1024-5000 ,也就是说默认情况下,客户端最多可以同时发起3977 个Socket 连接。我们可以修改如下注册表来调整这个动态端口的范围

[HKEY_LOCAL_MACHINE System CurrentControlSet Services Tcpip Parameters] MaxUserPort = 5000 (Default = 5000, Max = 65534)

最大TCB 数量

系统为每个TCP 连接分配一个TCP 控制块(TCP control block or TCB),这个控制块用于缓存TCP连接的一些参数,每个TCB需要分配 0.5 KB的pagepool 和 0.5KB 的Non-pagepool,也就说,每个TCP连接会占用 1KB 的系统内存。

系统的最大TCB数量由如下注册表设置决定

[HKEY_LOCAL_MACHINE System CurrentControlSet Services Tcpip Parameters] MaxFreeTcbs = 2000 (Default = RAM dependent, but usual Pro = 1000, Srv=2000)

非Server版本,MaxFreeTcbs 的默认值为1000 (64M 以上物理内存)

Server 版本,这个的默认值为 2000。

也就是说,默认情况下,Server 版本最多同时可以建立并保持2000个TCP 连接。

最大TCB Hash table 数量

TCB 是通过Hash table 来管理的,下面注册表设置决定了这个Hash table 的大小

HKEY_LOCAL_MACHINE System CurrentControlSet services Tcpip Parameters] MaxHashTableSize = 512 (Default = 512, Range = 64-65536)

这个值指明分配 pagepool 内存的数量,也就是说,如果MaxFreeTcbs = 1000 , 则 pagepool 的内存数量为 500KB

那么 MaxHashTableSize 应大于 500 才行。这个数量越大,则Hash table 的冗余度就越高,每次分配和查找 TCP 连接用时就越少。这个值必须是2的幂,且最大为65536.

MaxUserPort = 65534 (Decimal)MaxHashTableSize = 65536 (Decimal)MaxFreeTcbs = 16000 (Decimal)

这里我们可以看到 MaxHashTableSize 被配置为比MaxFreeTcbs 大4倍,这样可以大大增加TCP建立的速度。

时间: 2024-10-21 21:58:18

TCP - WAIT状态及其对繁忙的服务器的影响的相关文章

TCP连接状态详解及TIME_WAIT过多的解决方法

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

TCP连接状态详解

tcp状态:   LISTEN:侦听来自远方的TCP端口的连接请求 SYN-SENT:再发送连接请求后等待匹配的连接请求 SYN-RECEIVED:再收到和发送一个连接请求后等待对方对连接请求的确认 ESTABLISHED:代表一个打开的连接 FIN-WAIT-1:等待远程TCP连接中断请求,或先前的连接中断请求的确认 FIN-WAIT-2:从远程TCP等待连接中断请求 CLOSE-WAIT:等待从本地用户发来的连接中断请求 CLOSING:等待远程TCP对连接中断的确认 LAST-ACK:等待

Centos查看apache,nginx并发连接数和TCP连接状态命令

netstat命令和awk来查看web服务器的并发连接数以及TCP连接状态.  代码如下 复制代码 netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'   或者:  netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"t",state[key]}' FIN_WAIT2        38 CLOSING  

查看Apache并发请求数及其TCP连接状态

[文章作者:张宴 本文版本:v1.1 最后修改:2007.07.27 转载请注明出处:http://blog.s135.com] 这两天搭建了一组Apache服务器,每台服务器4G内存,采用的是prefork模式,一开始设置的连接数太少了,需要较长的时间去响应用户的请求,后来修改了一下Apache 2.0.59的配置文件httpd.conf: # prefork MPM# StartServers: number of server processes to start# MinSpareSer

replication server-Sybase RS 配置过程中连接状态不正常,备服务器状态显示为none

问题描述 Sybase RS 配置过程中连接状态不正常,备服务器状态显示为none 各位好: Sybase RS 配置过程中连接状态不正常,显示如下信息: admin logical_status [102] SYBASE_P.gcard [102] SYBASE_P.gcard Active/None None [16777317] HBTS_RS None None 1> admin who_is_down 2> go Spid Name State Info ---- ---------

IIS 状态代码的含义_win服务器

该状态代码记录在IIS日志中,同时也可能在Web浏览器或FTP客户端显示.状态代码可以指明具体请求是否已成功,还可以揭示请求失败的确切原因. 更多信息 日志文件的位置 在默认状态下,IIS把它的日志文件放在%WINDIR\System32\Logfiles文件夹中.每个万维网(WWW)站点和FTP站点在该目录下都有一个单独的目录.在默认状态下,每天都会在这些目录下创建日志文件,并用日期给日志文件命名(例如,exYYMMDD.log). HTTP 1xx-信息提示 这些状态代码表示临时的响应.客户

关于TCP连接状态修改问题,LIST和datagridview

问题描述 有一个LIST里面存放了连接的客户端IP地址比如里面存放了两个IP地址这个是不固定的.可能会有多个然后有一个datagridview中也存放了多个IP地址我如何判断LIST中的IP地址是否在datagridview中存在,如果存在,那么修改datagridview中的状态参数图标.希望给出具体代码谢谢本人新手.我写的代码如下可是每次如果有新的IP上线总会覆盖掉前面已经成功连接的IP地址我不知道我代码是否判断有问题希望指教foreach(variteminipaddrssList){fo

IIS W3C日志记录字段和HTTP状态代码的说明_win服务器

像新网的部分服务器ftp目录有这个文件,但是就是提示没权限查看也没有权限下载,还得必须给他们打电话才能要到. 做为网站拥有者,我们应该关注IIS日志,从里面我们不仅仅可以看到网站的访问记录和搜索引擎的抓取记录,还可以看到哪些网站盗链本站的哪些资源.部分死链接以及其他出错信息.其实对于我们来说,蜘蛛抓取记录和相关出错信息是我们最想关注的.哪些蜘蛛什么时间抓取了什么页面,返回的什么结果,是否正常,都可以从日志里清楚的看到. 下面说说IIS W3C格式日志中记录的字段及说明(一般都是选择的W3C格式日

服务器会影响网站优化排名不

我在服务器的选择上没少栽跟头,除了经济上蒙受损失之外,精力也被损耗殆尽.其中,最具代表的就是关于.xml文件的抓取.不知道朋友们是否遇到过这样的问题,当使用google管理员工具提交自己站点的sitemap.xml地图文件时,总是提示搜索引擎蜘蛛无法抓取.我曾一度尝试对sitemap.xml文件进行修正,可结果还是一样.后来经过无数次的测试和资料的查询,才知道问题出自服务器,是因为服务器上的配置不正确或者硬件防火墙设置导致的.所以在选择服务器时,请一定要试用,建立标准格式的.xml文件来测试抓取