高并发服务器拥塞控制算法（很早写的未完成的文章，再不发就会被遗忘了）

摘要
本文针对应用服务器的一般性拥塞峰值问题，描述了一种基于窗口的应用层拥塞控制算法。其目的主要解决kiwi应用服务器在大并发的业务场景下的高可用行。
需要特别提出的是，本文所描述的应用层拥塞控制与TCP/IP底层的拥塞控制属于不同层次，不同性质的问题。
IP协议采用“尽力而为”(Best Effort)的策略，在网络繁忙时，由于中间节点在速率上的不匹配，出现缓冲区上溢而造成的丢包，导致网络拥塞。在加大了中间设备的缓冲区后虽不会造成丢包，但出现严重的延时现象。
本文描述的是应用服务器在大并发访问时，由于大量的请求蜂拥而至，在极端情况下造成服务器内存耗尽、cpu耗尽、请求处理超时、连接超时等拒绝服务。

问题提出
在没有良好的拥塞控制的情况下，应用服务器出现如下几种蜂拥问题。
1） 恶意程序大量发起tcp连接，从而导致客户端无法正常连接服务器（TCP全连接攻击）
2） 个别客户端的请求霸占服务器处理队列，导致服务器内存、cpu、数据库连接资源耗尽，导致其他客户端的请求处理超时（公平性）
3） 业务规模扩大，客户端数量剧增，而服务器没有任何限制，导致服务器不堪重负，内存、cpu达到极限而崩溃，无法正常运行。（容量控制）
4） 个别客户端的请求霸占服务器的网络带宽，导致其他客户端的请求发送超时（带宽控制）

解决思路
拥塞控制算法应该遵循如下设计原则。
1） 公平性
服务器对每个客户端连接应给予同等的服务质量。不能因为一个客户端的大量请求导致服务器不能给其他客户端提供服务，类似传统的拒绝服务攻击，只是在性质上是非恶意 的。
2） 资源最大化利用
在服务器空闲、资源充足时，如果采用简单的平均分配原则为每个客户端分配适量的资源，大部分客户端仅使用了很小的一部分，而余下的那部分又不能分配个个别任务繁重的客户端，从而导致任务繁重的客户端的处理时间延长，而资源没有得到充分利用。

具体问题具体分析
1）TCP全连接攻击
TCP半连接攻击(SYN Flood)采用防火墙的SYN cookie即可轻松解决。
但TCP全连接能越过防火墙，与服务器建立真正的tcp连接，大量的恶意连接同样会占用服务器的内存。应用服务器也需要为其分配通道处理器来处理数据的收发。
解决此类问题的思路是只有当连接建立并且收到数据后，accept函数才返回新连接套接字，并为其创建通道处理器。
通过设置TCP_DEFER_ACCEPT（延迟接收）选项，如下所示：
setsockopt(listen_socket, SOL_TCP, TCP_DEFER_ACCEPT, &val, sizeof(val))
其中val是一个数字，它代表一个时间，字面上理解，在这个时间过去后仍没有数据到来的话就会在不指派服务进程(accept不返回)的情况下断开连接

2）最大连接数控制
在service上加个max_conn_count配置项
Accept返回时检测连接数，若连接溢出，直接关闭新连接

3）公平性
采用共享队列算法。即系统设置一个全局消息队列g_recv_queue，大小可配，默认为系统内存的80%。按照客户端通道数为每个客户端平均分配消息队列资源，即每个客户端通道占总队列的1/n(n为通道数)。所有客户端通道共享同一个队列，每个通道可以视为一个逻辑子队列。

当由于消息入队造成水位标达到上水位（已满），且仍然收到了消息，则消息强制入队（不采用阻塞等待的策略，因此消息是通过底层线程入队的，若采用阻塞，则会阻塞整个通信，控制报文也将无法发送出去），并且发送HWW（流量控制报文，向对端发送上水位报警消息）。对端收到HWW则应立即停止发送消息

全局消息队列中存放的是未被调度（处理）的消息即待处理消息。一但消息被分配到处理线程（任务）上，则消息将会出队，全局队列（通道子队列）的空间被释放。

当由于消息出队，水位标由上水位到达下水位，则向对端发送LWN（流量控制报文，向对端发送下水位达到通知）。对端收到LWN则可以恢复消息发送

上水位：默认为队列上限
下水位：默认为队列大小的80%

测试方法：
通过某一个客户端对服务器施压，分别观察在无拥塞控制和有拥塞控制的情况下服务器对其他客户端请求的响应情况。

4）消息保序
消息发送方给需要按序接收和处理的一组消息设置同一个时序键。时序键大小为4字节
接收方根据时序键映射（hash）为处理线程id。
共享队列上的线程池保证消息被正确的线程处理。

5）消息优先级

6）带消息优先级的保序