鉴于楼上说的手动 tcp 方案太扯淡了，本来想简单吐槽一句，结果没忍住还是把这个事情说清楚吧。

我这么说是有理论和实践经验做支撑的，tcp 手动发包几乎没有统计学上的有效性。这类需求前些年几乎是外包市场仅次于网站开发的业务，钱多门槛低。我自己做得很少，基本上是给别人指导一下，不做的原因主要是业务容易擦边，再就是现在多数大平台的都从抢的逻辑变成抽签逻辑了。

先解释一下为什么有人认为“手动发包”是个有意义的方案。

因为按照一般的“抢”的逻辑，以某个时刻为分界线，在此时刻之后某个特定资源就生效了。在此时刻之前到达服务器的请求是无效的，你希望你的请求恰好在这个时刻之后到达服务器。

那么我们有能力确定服务器的时间吗？绝大多数时间不能。（少数情况下可以通过触发服务器错误等等获得一个相对时间差，然后加上网络延迟做一个粗略估计。）即使能够确定服务器时间，实际应用里也没有太大意义。“上线”这个事情 99% 不是自动化的而是人为的。

因此所有人的策略都做出调整了，用大量链接去覆盖资源上线的可能时段。只要保证资源上线之后有一部分请求以尽量低的延迟到达服务器即可。

这个时候 tcp 手动发包好像就体现出优势了？提前建立好（大量）连接，然后看情况开始发数据。注意这里的潜台词是，网站卡的原因在于 tcp 连接数不够，而且新建立连接会多 1RTT 的延时。

但是这个思路是不是有点眼熟？如果很多人都是这样做，或者某个人控制机器人程序这样做，在服务器看来，客户端只连接不发数据，这连接还不会主动关闭，那它是不是就是 DoS 攻击？（这一类攻击有个专门的名字叫 Slowloris ）

这里设定个非常简单也非常普遍的模型，来看看这个做法有没有可行性。或者说“连接数不够”这个假设是不是真的符合现实。

就非常普通的单服务器 nginx 做 ssl offloading 和反代，配置近似默认，upstream 大概是某种动态语言的服务端。网络请求在闲时 10 QPS 忙时 10000 QPS 这样。（意思就是，规模不大，用户量有限。服务器网络带宽不是瓶颈，nginx 也大概率不是瓶颈，瓶颈在后端应用，挂号服务基本上就是这个水平。）

这里套不套应用层防火墙差别非常大。一旦套一层 cf 之类的服务，手动 tcp 发包就没意义了。因为 cf 之类的服务会缓存请求然后回源，不可能在这个层面预先抢占 tcp 连接。

如果退一步讲，服务器裸跑。这个时候你通过手动 tcp 发包，那能够获得的时间窗口有多长？

在 tcp 层面，理论上 keepalive 是无限长的。但是实际上以国内的网络环境来说，经过 NAT 之后中间设备的映射缓存大概就是 150 秒这个水平。实践里可以找公网服务器、代理来绕开这个限制。提这个限制的意思是，利用 keepalive 机制几乎不需要你在程序层面上做很大的改动。

但是在 nginx 服务器层面上，时间窗口就小得多。这类服务器默认对慢速攻击有应对，tcp 连接建立后，headers/body 的默认容忍延迟基本在 60 秒。（但凡看过一点点所谓的优化经验，这个值应该不会超过 10 秒）

那就又回到之前的问题上了，你本来打算预先抢占 tcp 连接，结果时间窗口太小，当所有人的策略都是提前覆盖可能的时段，你的连接会被淹没在海量连接里面。

这里有个非常极端的情况，这个 tcp 手动发包，利用 tcp 的机制，强行把 headers 分成多个包发送，然后每个发送间隔卡在目标服务器的限制之内。（这里就不提这个程序的复杂性了，要么魔改底层网络库，要么纯手写然后一直处理到应用层协议）

但问题是 nginx 这类服务器的反代，一样会先缓存请求，在收到完整请求之后，再转发给 upstream 服务器。也就是说，你抢占了本地到 nginx 的连接，而没有能力抢占 nginx 的 upstream 的连接。

现在回到核心的问题上，服务器在高并发的时候变卡的核心原因是什么？

核心是服务端应用要对特定资源加锁，业务逻辑在高并发的情况下只能等。

由于一般网站的瓶颈都在后端应用服务器上，nginx 能承载的客户端连接数远大于 nginx 到 upstream 的连接数。

当应用服务器不需要处理锁事务的时候，平均响应可以做到很低。但是一旦遇到加锁资源的时候，这个响应时间会成倍增加，理论 QPS 就大幅下降。而此时所有人会更加疯狂地反复刷新，这时候 nginx 到 upstream 的连接就会长期占满。

所以体感上就是，网站先变卡，因为 nginx 在等 upstream 释放出新的连接。等 nginx 撑不住了才会 502 错误。而从客户端来说，没有任何手段能保证你优先获得到 upstream 的连接。

所以说 tcp 手动发包这个事情……别挣扎了。