解决连接数过多和半开攻击

目录

解决TCP连接数过多的问题 .............................................................................. 1

解决方法：.................................................................................................... 4

解决半开攻击的方法............................................................................................ 5

解决方法：.................................................................................................... 8

解决TCP连接数过多的问题

TCP状态迁移，CLOSE_WAIT & FIN_WAIT2 的问题

TCP状态迁移

对netstat -a命令很熟悉，但是，你有没有注意到STATE一栏呢，基本上

显示着established,time_wait,clo_wait等

大家很明白TCP初始化连接三次握手吧：发SYN包，然后返回SYN/ACK

包，再发ACK包，连接正式建立。但是这里有点出入，当请求者收到SYS

/ACK包后，就开始建立连接了，而被请求者第三次握手结束后才建立连接。

但是大家明白关闭连接的工作原理吗？关闭连接要四次握手：发FIN包，A

CK 包，FIN包，ACK包，四次握手！！为什么呢，因为TCP连接是全双工，

我关了你的连接，并不等于你关了我的连接。

客户端TCP状态迁移：

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_W

AIT->CLOSED

服务器TCP状态迁移：

CLOSED->LISTEN->SYN收到 ->ESTABLISHED->CLOSE_WAIT->LAST_ACK->

CLOSED

当客户端开始连接时，服务器还处于LISTENING，

客户端发一个SYN包后，他就处于SYN_SENT状态,服务器就处于SYS收

到状态,

然后互相确认进入连接状态ESTABLISHED.

1

当客户端请求关闭连接时,客户端发送一个FIN包后,客户端就进入FIN

_WAIT_1状态,等待对方的确认包,

服务器发送一个ACK包给客户,客户端收到ACK包后结束FIN_WAIT_1状

态,进入FIN_WAIT_2状态,等待服务器发过来的关闭请求,

服务器发一个FIN包后,进入CLOSE_WAIT状态,

当客户端收到服务器的FIN包,FIN_WAIT_2状态就结束,然后给服务器

端的FIN包给以一个确认包,客户端这时进入TIME_WAIT,

当服务器收到确认包后,CLOSE_WAIT状态结束了,

这时候服务器端真正的关闭了连接.但是客户端还在TIME_WAIT状态下,

什么时候结束呢.我在这里再讲到一个新名词:2MSL等待状态,其实TIME

_WAIT就是2MSL等待状态,

为什么要设置这个状态,原因是有足够的时间让ACK包到达服务器端,如

果服务器端没收到ACK包，超时了，然后重新发一个FIN包，直到服务器

收到ACK 包.

TIME_WAIT状态等待时间是在TCP重新启动后不连接任何请求的两倍.

大家有没有发现一个问题:如果对方在第三次握手的时候出问题,如发F

IN包的时候,不知道什么原因丢了这个包,然而这边一直处在FIN_WAIT_2状

态,而且TCP/IP并没有设置这个状态的过期时间,那他一直会保留这个状

态下去,越来越多的FIN_WAIT_2状态会导致系统崩溃.

上面我碰到的这个问题主要因为TCP的结束流程未走完，造成连接未释

放。现设客户端主动断开连接，流程如下

如上图所示，

Client 消息

Server

clo()

------ FIN ------->

FIN_WAIT1

CLOSE_WAIT

<----- ACK -------

FIN_WAIT2

clo()

<------ FIN ------

2

TIME_WAIT

LAST_ACK

----

-- ACK ------->

CLOSED

CLOSED

由于Server的Socket在客户端已经关闭时而没有调用关闭，

造成服务器端的连接处在“挂起”状态，而客户端则处在等待应答的状

态上。

此问题的典型特征是：

一端处于FIN_WAIT2 ，而另一端处于CLOSE_WAIT.

不过，根本问题还是程序写的不好，有待提高

-------------------------------------------------------------

------------

CLOSE_WAIT，TCP的癌症，TCP的朋友。

CLOSE_WAIT状态的生成原因

首先我们知道，如果我们的服务器程序APACHE处于CLOSE_WAIT状态的

话，说明套接字是被动关闭的！

因为如果是CLIENT端主动断掉当前连接的话，那么双方关闭这个TCP

连接共需要四个packet：

Client ---> FIN ---> Server

Client <--- ACK <--- Server

这时候Client端处于FIN_WAIT_2状态；而Server 程序处于CLOSE_WA

IT状态。

Client <--- FIN <--- Server

这时Server 发送FIN给Client，Server 就置为LAST_ACK状态。

Client ---> ACK ---> Server

Client回应了ACK，那么Server 的套接字才会真正置为CLOSED状态。

Server 程序处于CLOSE_WAIT状态，而不是LAST_ACK状态，说明还没

有发FIN给Client，那么可能是在关闭连接之前还有许多数据要发送或者

其 他事要做，导致没有发这个FIN packet。

3

解决方法：

修改/etc/添加

_keepalive_time = 3600

established状态保持时间为3600秒

_keepalive_probes = 6

established状态保持时间到期后请求次数

_keepalive_intvl = 25

每次请求的间隔时间为25秒

然后保存文件

sysctl –p 使修改的文件立即生效

4

解决半开攻击的方法

TIMEWAIT状态本身 和应用层的客户端或者服务器是没有关系的。仅仅

是主动关闭的一方，在使用FIN|ACK|FIN|ACK四分组正常关闭TCP连接的时

候 会出现这个TIMEWAIT。服务器在处理客户端请求的时候，如果你的程序

设计为服务器主动关闭，那么你才有可能需要关注这个TIMEWAIT状态过多的

问题。如果你的服务器设计为被动关闭，那么你首先要关注的是

CLOSE_WAIT。

原则

TIMEWAIT并不是多余的 。 在TCP协议被创造， 经历了大量的实际

场景实践之后 ，TIMEWAIT 出现了，因为TCP主 动关闭连接的一方需要

TIMEWAIT状态，它是我们的朋友。这是 《 》的作者----Steven

UNIX网络编程

对TIMEWAIT的态度。

TIMEWAIT是友好的

TCP 要保证在所有可能的情况下使得所有的数据都能够被正确送

达。当你关闭一个 socket 时，主动关闭一端的 socket 将进

入 TIME_WAIT 状态，而被动关闭一方则转入CLOSED状态，这的确能够保

证所有的数据都被传输。当一个socket关闭的时候，是通过两端四次握手完成的，

当一端调用clo()时，就说明本端没有数据要发送了。这好似看来在握手完成以

后，socket就都可以处于初始的CLOSED状态了，其实不然。原因是这样安排

状态有两个问题， 首先，我们没有任何机制保证最后的一个ACK能够正常传

输，第二，网络上仍然有可能有残余的数据包(wandering duplicates)，我们也必

须能够正常处理。

TIMEWAIT就是为了解决这两个问题而生的。

1.假设最后一个 ACK 丢失了，被动关闭一方会重发它的 FIN。 主动

关闭一方必须维持一个有效状态信息（TIMEWAIT状态下维持），以便能够重

发 ACK。 如果主动关闭的socket不维持这种状态而进入CLOSED状态，那

么主动关闭的socket在处于CLOSED状态时， 接收到FIN后将会响应一个RST。

被动关闭一方接收到RST后会认为出错了。如果TCP协议想要正常完成必要的

操作而终止双方的数据流传输，就必须完全正确的传输四次握手的四个节，不能

5

有任何的丢失。这就是为什么socket在关闭后，仍然处于TIME_WAIT状态的第

一个原因，因为他要等待以便重发ACK。

2.假设 目前连接的通信双方都已经调用了 clo() ，双方同时进

入 CLOSED的终结状态，而没有走 TIME_WAIT 状态。会出现如下问题，

现在有一个新的连接被建立起来，使用的IP地址与端口与先前的完全相同，后

建立的连接是原先连接的一个完全复用。还假定原先的连接中有数据报残存于网

络之中，这样新的连接收到的数据报中有可能是先前连接的数据报。为了防止这

一点，TCP不允许新连接复用TIME_WAIT状态下的socket。处于TIME_WAIT

状态的socket在等待两倍的MSL时间以后（之所以是两倍的MSL，是由于MSL

是一个数据报在网络中单向发出到认定丢失的时间，一个数据报有可能在发送途

中或是其响应过程中成为残余数据报，确认一个数据报及其响应的丢弃的需要两

倍的MSL），将会转变为CLOSED状态。这就意味着，一个成功建立的连接，

必然使得先前网络中残余的数据报都丢失了。

大量TIMEWAIT在某些场景中导致的令人头疼的业务 问题

大量TIMEWAIT出现，并且需要解决 的场景

在高并发短连接的TCP服务器上，当服务器处理完 请求后立刻按照主

动正常 关闭连接。。。这个场景下， 会出现大量socket处

于 TIMEWAI T 状态。如果客户端的并发量持续很高， 此时部分客户端就

会显示 连接不上。

我来解释下这个场景。 主动正常关闭TCP连接，都会出 现TIMEWAIT。为

什么我们要关注这个高并发短连接呢？有两个方面需要注意 ：

1. 高并发可以让服务器在短时间范围内同时 占用大量端口，而端口有个

0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少

了 。

2. 在这个场景中，短连接表示“业务处理+传输数据的时间 远远小于

TIMEWAIT超时的时间”的连接。这里有个相对长短 的概念，比如，取一个

web页面，1秒钟的http 短连接处理完业务， 在关闭连接之后，这个业务用

过的端口 会停留在TIMEWAIT状态几分钟，而这几分钟，其他HTTP请求来

临的时候是无法占用此端口的 。单用这个业务计算服务器的利用率会发现，服

务器干正经事的时间和端口（资源） 被挂着无法被使用的时间的比例是 1：几

百，服务器资源严重浪费。（说个题外话，从这个意义出发来考虑服务器性能调

优的话， 长连接业务的服务 就不需要考虑TIMEWAIT状态。同时，假如你

对服务器业务场景非常熟悉，你会发现，在实际业务场景中， 一般长连接对应

的业务的并发量并不会很高 ）

6

综合这两个方面，持续的到达一定量的 高并发短连接，会使服务器因端口资源

不足而拒绝为一 部分客户服务。同时，这些端口都是服务器临时分配，无法用

SO_ REUSEADDR选项解决这个问题:(

一对矛盾

TIMEWAIT既友好，又令人头疼。

但是我们还是要抱着一个友好的态度来看待它，因为它尽它的能力保证了服务器

的健壮性。

可行而且必须存在， 但是不符合原则的解决方式

1. linux没有在sysctl或者proc文件系统暴露修改 这个TIMEWAIT超时时

间的接口 ，可以修改内核协议栈代码中关于这个TIMEWAIT的超时时间参数，

重编内核，让它缩短超时时间，加快回收；

2. 利用SO_LINGER选项的强制关闭方式，发RST而不是FIN，来越过

TIMEWAIT状态，直接进入CLOSED状态。详见我的博 文

《TCP之选

项SO_LINGER》

。

我如何看待这个问题

为什么说上述两种解决方式我觉得可行，但是不符合原则？

我首先认为，我要依靠TIMEWAIT状态来保证我的服务器程序健壮，网络上发

生的乱七八糟的问题太多了，我先要服务功能正常。

那是不是就不要性能了呢？并不是。如果服务器上跑的短连接业务量到了我真的

必须处理这个TIMEWAIT状态过多的问题的时候，我的原则是 尽量 处理，

而不是跟TIMEWAIT干上，非先除之而后快：）如果 尽量 处理了，还是解决

不了问题，仍然拒绝服务 部分请求 ，那我会采取分机器的方法 ，让多台机

器来抗 这些高 并发的短 请求。持续十万并发的短连接请求，两台机器，每

台5万个，应该够用了吧。一般的业务量以及国内大部分网站其实并不需要关注

这个问题，一句话，达不到需要关注这个问题的访问量。

真正地必须使用 上述我认为不合理的方式 来解决这个问题的场景有没有呢？

答案是有。

像淘宝、百度、 新浪、京东商城这样的站点，由于有很多静态小图片业务，如

7

果过度分服会导致需要上线大量机器，多买机器多花钱，得多配机房，多配备运

维工程师来守护这些机器，成本增长非常严重。。。这个时候就要尽一切可能去优

化。

题外话，服务器上的技术问题没有绝对，一切都是为业务需求服务的。

解决方法：

修改/etc/ 添加

_tw_reu = 1

_tw_recycle = 1

sysctl –p 使修改的文件立即生效

将系统的TIMEWAIT重用和快速回收

8