Async是Ruby生态中基于fibonacci协程思想实现的一个成熟异步IO框架，它使用Fiber代替线程来处理并发任务，单线程内即可支撑数万并发连接。Async::HTTP::Server作为框架内置的HTTP服务器实现，默认情况下会接受所有进入的连接，不做任何数量上的限制。这在面对突发流量、慢客户端或者恶意连接洪泛攻击时非常危险：每一个被接受的连接都会占用内存和一个fiber执行上下文，当连接数无限增长时，进程内存持续膨胀，最终可能导致整个服务不可用。因此为服务器设置最大并发连接数保护，是生产环境部署中不可缺少的一环。
为什么默认不限制连接是危险的
Async::HTTP::Server处理请求的模式是：acceptor接受TCP连接之后，为每个连接分配一个独立的Fiber，连接在整个生命周期内由该Fiber负责读取请求和写出响应。虽然Fiber比线程轻量得多，单个Fiber的开销大约只有几KB，但这并不意味着资源是无限的。
首先，每个TCP连接在操作系统层面都占有一个文件描述符，Linux默认的进程fd限制通常在1024到几十万之间，超出后accept会直接抛出异常。其次，如果客户端只建立连接而不发送数据（典型的慢速攻击Slowloris模式），服务端的Fiber会阻塞在read上，白白消耗内存和协程槽位。最后，下游依赖如数据库连接池是有限的，上游连接数不受控会导致下游资源被耗尽，形成雪崩效应。这三点叠加起来，说明并发连接数必须有一个明确的硬上限。
使用Async::Semaphore限制并发连接数
Async框架提供了一个开箱即用的信号量实现Async::Semaphore，它允许最多N个任务同时进入临界区，超出的任务会排队等待。将它包装在接受连接的逻辑外层，就能实现最大并发连接数保护。当达到上限时，新的连接请求会在信号量上排队，而不是立即消耗资源；一旦有连接释放，排队的连接才会继续处理。
require 'async'
require 'async/http/server'
require 'async/http/endpoint'
MAX_CONNECTIONS = 500
# 创建一个最多允许500个并发任务的信号量
semaphore = Async::Semaphore.new(MAX_CONNECTIONS)
endpoint = Async::HTTP::Endpoint.parse('http://127.0.0.1:3000')
Async do
server = Async::HTTP::Server.for(endpoint) do |request|
Protocol::HTTP::Response[200, {'content-type' => 'text/plain'}, ['ok']
end
# 包装accept循环，用信号量控制并发
Async(:name => "acceptor") do |task|
while true
peer = server.endpoint.accept do |io|
semaphore.acquire do
server.accept_client(io)
end
end
end
end
end</code>更实用的做法是在中间件层做准入控制，直接对请求级别限流，语义更清晰也更容易测试。下面这个自定义中间件在没有拿到信号量槽位时返回503，客户端能立即感知到服务繁忙：
class ConnectionLimiter
def initialize(app, limit: 500)
@app = app
@semaphore = Async::Semaphore.new(limit)
end
def call(request)
if @semaphore.available?
@semaphore.acquire do
@app.call(request)
end
else
# 并发已满，快速失败返回服务不可用
Protocol::HTTP::Response[503,
{'content-type' => 'text/plain'},
['server busy, try again later']
]
end
end
end
# 使用方式
app = ConnectionLimiter.new(your_rack_app, limit: 500)
Async do
endpoint = Async::HTTP::Endpoint.parse('http://127.0.0.1:3000')
server = Async::HTTP::Server.new(app, endpoint)
server.run
end这种方案的核心优势是快速失败：与其让第501个连接排队等待拖慢整体响应，不如直接告诉客户端服务已饱和，让负载均衡器把流量调度到其他实例。需要注意的是，信号量的limit数值应该结合下游容量设置，比如数据库连接池大小是20，那么把HTTP并发上限设为几千就没有意义，瓶颈根本不在网络层。
配合操作系统层面的连接堆积控制
应用层的信号量控制的是已被Ruby进程接受并处理的连接，而在accept之前，操作系统内核会维护一个半连接和全连接队列，队列长度由listen的backlog参数决定。Async::HTTP::Endpoint允许显式指定这个参数：
endpoint = Async::HTTP::Endpoint.parse( 'http://127.0.0.1:3000', reuse_port: true, # backlog指定内核连接队列长度，超出队列的连接会被拒绝 backlog: 1024 )
backlog设置得过小，在瞬时连接风暴下客户端会收到connection refused；设置得过大，则大量连接堆积在内核队列里排队，客户端等待超时体验更差。一般建议设为预期峰值并发数的1到2倍，同时开启reuse_port让多个进程分担接受压力。
除了backlog，还应该为每个连接设置合理的超时时间，避免慢客户端长期占用信号量槽位。可以在响应头处理时配合Async::Clock监控请求处理耗时，对超过阈值的连接主动关闭：
class TimeoutMiddleware
def initialize(app, timeout: 10)
@app = app
@timeout = timeout
end
def call(request)
response = nil
# 用子任务和超时保护请求处理
Async(transient: true) do |task|
Async do |inner|
response = @app.call(request)
inner.stop
end
task.sleep(@timeout)
raise TimeoutError, 'request processing timed out'
end.wait
response
end
end同时在部署层面，还可以通过systemd的LimitNOFILE、ulimit -n或容器编排平台的资源限制来约束进程可打开的文件描述符数量，形成应用层信号量、内核backlog、操作系统fd限制这三层防线，任何一层失效都有兜底。
监控与动态调整的最佳实践
固定不变的连接上限很难适应流量波动，生产环境建议对信号量的使用情况进行持续监控。可以在定时任务中周期性输出当前并发数与等待数，也可以将指标暴露给Prometheus等监控系统：
class MonitoredLimiter
attr_reader :semaphore
def initialize(limit)
@semaphore = Async::Semaphore.new(limit)
@counter = 0
@lock = Mutex.new
end
def acquire(&block)
@lock.synchronize { @counter += 1 }
@semaphore.acquire(&block)
ensure
@lock.synchronize { @counter -= 1 }
end
def stats
{ current: @counter, limit: @semaphore.limit }
end
end当监控数据显示并发长期贴近上限且503比例升高时，说明需要扩容实例或者调整limit值。反之如果并发长期只用到上限的一小部分，可以适当下调以节省资源预留。另一个实践是把连接限制与熔断器（如circuitbox gem）结合，当下游依赖出现故障时主动收紧上游并发，防止故障放大。
总结来说，Async::HTTP::Server本身没有内置的连接数上限配置，但借助Async::Semaphore实现应用层准入控制、通过backlog控制内核队列、再辅以超时保护和系统级fd限制，完全可以构建出一套层次分明、防御充分的并发连接保护体系，让Ruby异步服务在高压场景下保持稳定可控。
Ruby AsyncHTTP Server并发连接数修改时间：2026-09-01 15:58:49