在测试apache freebsd服务器时,被同台测试机ip太多而失败烦了一阵子,看了这篇文章,觉得很好。
作者:Morgan
TIME_WAIT状态
根据TCP协议,主动发起关闭的一方,会进入TIME_WAIT状态,持续2*MSL(Max Segment Lifetime),缺省为240秒,在这个post中简洁的介绍了为什么需要这个状态。
值得一说的是,对于基于TCP的HTTP协议,关闭TCP连接的是Server端,这样,Server端会进入TIME_WAIT状态,可想而知,对于访问量大的Web Server,会存在大量的TIME_WAIT状态,假如server一秒钟接收1000个请求,那么就会积压240*1000=240,000个TIME_WAIT的记录,维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些TIME_WAIT,所以对于新的TCP连接请求,判断是否hit中一个TIME_WAIT不会太费时间,但是有这么多状态要维护总是不好。
HTTP协议1.1版规定default行为是Keep-Alive,也就是会重用TCP连接传输多个request/response,一个主要原因就是发现了这个问题。还有一个方法减缓TIME_WAIT压力就是把系统的2*MSL时间减少,因为240秒的时间实在是忒长了点,对于Windows,修改注册表,在HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters上添加一个DWORD类型的值TcpTimedWaitDelay,一般认为不要少于60,不然可能会有麻烦。
对于大型的服务,一台server搞不定,需要一个LB(Load Balancer)把流量分配到若干后端服务器上,如果这个LB是以NAT方式工作的话,可能会带来问题。假如所有从LB到后端Server的IP包的source address都是一样的(LB的对内地址),那么LB到后端Server的TCP连接会受限制,因为频繁的TCP连接建立和关闭,会在server上留下TIME_WAIT状态,而且这些状态对应的remote address都是LB的,LB的source port撑死也就60000多个(2^16=65536,1~1023是保留端口,还有一些其他端口缺省也不会用),每个LB上的端口一旦进入Server的TIME_WAIT黑名单,就有240秒不能再用来建立和Server的连接,这样LB和Server最多也就能支持300个左右的连接。如果没有LB,不会有这个问题,因为这样server看到的remote address是internet上广阔无垠的集合,对每个address,60000多个port实在是够用了。
一开始我觉得用上LB会很大程度上限制TCP的连接数,但是实验表明没这回事,LB后面的一台Windows Server 2003每秒处理请求数照样达到了600个,难道TIME_WAIT状态没起作用?用Net Monitor和netstat观察后发现,Server和LB的XXXX端口之间的连接进入TIME_WAIT状态后,再来一个LB的XXXX端口的SYN包,Server照样接收处理了,而是想像的那样被drop掉了。翻书,从书堆里面找出覆满尘土的大学时代买的《UNIX Network Programming, Volume 1, Second Edition: Networking APIs: Sockets and XTI》,中间提到一句,对于BSD-derived实现,只要SYN的sequence number比上一次关闭时的最大sequence number还要大,那么TIME_WAIT状态一样接受这个SYN,难不成Windows也算BSD-derived?有了这点线索和关键字(BSD),找到这个post,在NT4.0的时候,还是和BSD-derived不一样的,不过Windows Server 2003已经是NT5.2了,也许有点差别了。
做个试验,用Socket API编一个Client端,每次都Bind到本地一个端口比如2345,重复的建立TCP连接往一个Server发送Keep-Alive=false的HTTP请求,Windows的实现让sequence number不断的增长,所以虽然Server对于Client的2345端口连接保持TIME_WAIT状态,但是总是能够接受新的请求,不会拒绝。那如果SYN的Sequence Number变小会怎么样呢?同样用Socket API,不过这次用Raw IP,发送一个小sequence number的SYN包过去,Net Monitor里面看到,这个SYN被Server接收后如泥牛如海,一点反应没有,被drop掉了。
按照书上的说法,BSD-derived和Windows Server 2003的做法有安全隐患,不过至少这样至少不会出现TIME_WAIT阻止TCP请求的问题,当然,客户端要配合,保证不同TCP连接的sequence number要上涨不要下降。
分享到:
相关推荐
### 大量TIME_WAIT状态的连接解决方法 在Linux系统中,当服务器处理大量网络连接时,可能会遇到TIME_WAIT状态的连接过多导致的问题。TIME_WAIT是TCP连接的一个正常终止状态,但若数量过多则可能会影响到服务器性能...
本文将深入解析如何有效解决MySQL出现大量TIME_WAIT状态的问题,通过调整系统内核参数、优化数据库配置以及合理管理连接池策略,确保服务器性能的稳定与高效。 ### 一、理解TIME_WAIT TIME_WAIT是TCP协议中的一个...
当服务器之间的通信过于频繁,如通过REST请求互相调用时,Java服务器可能无法及时回收TCP连接,导致TIME_WAIT状态的连接积累。 TIME_WAIT状态是TCP连接生命周期的一部分,它确保数据完全传输并且防止旧的数据包被误...
在深入探讨如何有效释放TIME_WAIT状态的连接之前,我们首先需要理解TIME_WAIT状态的基本概念及其在TCP协议中的作用。TIME_WAIT是一种TCP连接的状态,当一个TCP连接被主动关闭时,客户端会进入TIME_WAIT状态,目的是...
在 Linux 服务器中,TIME_WAIT 状态是一种常见的网络连接状态。然而,出现大量的 TIME_WAIT 状态可能会对服务器的性能产生影响。本文将详细介绍大量 TIME_WAIT 状态的成因、影响和解决方法。 TIME_WAIT 状态的成因 ...
这是因为TCP不允许处于TIME_WAIT状态的连接启动新的化身,因为TIME_WAIT状态持续2MSL,这样可以保证当成功建立TCP连接时,来自前一个连接的重复分组已经在网络中消逝。 然而,TIME_WAIT状态也会带来一些问题,例如...
在 TCP 连接中,客户端和服务器端都可以处于不同的状态,例如 ESTABLISHED、CLOSE_WAIT、FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT 等 trạng thái。 CLOSE_WAIT 状态是 TCP 连接中的一种状态,它表示服务器端已经收到了...
在TCP/IP通信中,TIME_WAIT状态是TCP连接生命周期的一部分,用于确保数据的可靠传输。当一个TCP连接被关闭后,连接的两端不会立即释放资源,而是进入TIME_WAIT状态,等待一段时间以确保所有发送的数据都被确认接收。...
TIME_WAIT状态是TCP连接生命周期的一部分,用于确保数据传输的可靠性,但过多的TIME_WAIT连接会消耗系统资源,特别是端口资源。 TIME_WAIT状态的产生主要有两个原因: 1. Nginx作为负载均衡器,与PHP-FPM通信时通常...
在Linux系统中,进行网络编程时,TCP连接的TIME_WAIT状态是至关重要的一个环节。TIME_WAIT状态是TCP连接生命周期中的最后一个阶段,对于理解和优化网络应用性能有着直接的影响。本资源"TIME_WAIT.rar"包含了关于这个...
当我们看到netstat输出中存在大量的TCP连接处于TIME_WAIT状态时,这通常意味着系统可能存在一些性能问题或者配置上的挑战。本篇文章将深入探讨TIME_WAIT状态的原因以及如何解决。 TCP(传输控制协议)是一种面向...
为什么要有TIME_WAIT状态? TIME_WAIT状态存在的主要原因是确保TCP的可靠性和防止旧数据包的干扰。当TCP连接的一方发送FIN包表示关闭连接后,它进入TIME_WAIT状态。在这个状态下,该方等待足够长的时间(2MSL,即两...
在time_wait状态下,连接不会立即关闭,而是等待一段时间,以确保任何可能在网络中漂浮的数据包能被正确处理。 1. time_wait状态产生条件 time_wait状态只会在主动关闭连接的一方出现,即发起FIN(结束)的那端。在...
在Linux服务器环境中,当TCP/IP连接关闭后,服务器端的端口可能会进入TIME_WAIT状态,这是TCP协议设计的一部分。TIME_WAIT状态的目的是确保网络中不存在旧的、可能重复的数据包,从而避免对新连接造成干扰,并确保...
在客户端主动断开连接时,客户端会发送FIN包给服务器端,服务器端则会响应ACK包,并进入CLOSE_WAIT状态。但是,如果服务器端没有正确关闭连接,那么连接将保持CLOSE_WAIT状态,而客户端则会等待服务器端的响应。 ...
TCP TIME_WAIT状态是TCP连接生命周期中的一个重要阶段,它发生在主动关闭连接的一方(通常称为客户端)在连接关闭后等待一段时间,以确保所有在网络中可能残留的数据片段都被接收并确认。这个阶段的存在是为了避免旧...
在分析“服务端长连接与客户端短连接引起Nginx产生大量‘TIME_WAIT’状态的线程”的问题之前,我们先来了解一下几个关键知识点:Nginx连接处理方式、长连接与短连接、TIME_WAIT状态以及TLS session重用(resumption...