2026 一台服务器能撑多少 WebSocket 长连接：卡住上限的往往不是带宽

把"能撑多少"拆成四件事

问一台服务器能撑多少条 WebSocket 长连接，其实是在问四件事：这个进程能开多少个文件描述符、每条连接常驻多少内存、心跳每秒要打多少个包、内核那几个参数卡在哪一档。这四个量每一个都能单独算出量级，而"带宽够不够"通常排在第五位甚至更靠后。

能开多少个 fd：这是硬上限，超了直接报 too many open files，表现不是变慢，而是新连接直接失败。

每条连接吃多少内存：应用层的连接对象和业务上下文一般几 KB 到几十 KB，乘上连接数就是常驻内存，超了不会报错，而是被 OOM 杀掉进程，所有连接一起掉。

心跳每秒多少包：单个心跳帧只有几十字节，但乘上连接数之后，压力落在每秒包数（PPS）和网卡中断上，而不是字节数上。

内核参数卡在哪一档：fd 上限、缓冲区间、连接队列、TIME_WAIT 处理，各管一段，任何一段卡住都会让连接数停在一个莫名其妙的整数上。

把问题拆成这四件事之后，"这台机器能不能撑 10 万"就不再是拍脑袋，而是可以先在纸上算一遍、再用压测去验证的工程量。真实跑起来以后，绝大多数团队先撞到的是前两道墙：fd 和内存。带宽跑满的场景几乎只出现在一种情况下——业务消息本身在疯狂广播，而不是因为连接多。

这个结论对选型影响很大。很多人在采购时把预算压在带宽上，结果机器买回来，千兆口只跑到几十 Mbps，连接数却卡在几万上不去。钱花错了地方，问题一点没解决。

一条长连接到底占什么：fd、缓冲区、应用对象、TLS 会话

先算清单个连接的账。一条 WebSocket 长连接在服务端至少占下面几样东西，每一样都能单独估值。

一个文件描述符。这是最直观的一项，一条连接一个 fd，accept 成功就消耗一个，close 之后才释放。如果中间有代理层或者四层负载均衡，链路上每一跳都要各自消耗一个。

内核里的 socket 结构与读写缓冲区。接收缓冲和发送缓冲受 tcp_rmem、tcp_wmem 这类内核参数控制，但注意它不是一开始就按最大值占满——Linux 有自动调节机制，一条安静的长连接实际占用通常远小于配置上限，只有当对端真的在发大包、或者己方堆积了没发出去的消息时，缓冲区才会涨上去。这也是为什么"按最大缓冲乘连接数"算出来的内存往往偏大，但它仍然是必须算的一笔账，因为突发时刻就是按最大值涨的。

应用层的连接对象与业务上下文。这一项通常是大头。连接对象本身不大，真正占地方的是挂在它上面的上下文：用户标识、鉴权信息、订阅的频道或房间列表、未确认消息队列、压缩上下文、各种定时器。轻量实现可以压到几 KB，业务复杂一点、或者用了语言默认的对象结构，几十 KB 也很常见。压测前先把这个数字测出来，后面所有估算都建立在这个数上。

TLS 会话状态。如果走的是加密连接，每个会话还要额外占一份会话状态，量级在 KB 级，具体和加密套件、是否开启会话复用有关。开了会话复用之后，重连时的握手开销能明显下降，但会话缓存本身也要占内存，缓存多大、保留多久都要按连接数算。

把这几项加在一起，一条连接的常驻开销就有了量级：内核侧几 KB 起步、应用层几 KB 到几十 KB、TLS 再加一点。下面所有的反推都基于这个账本。需要强调的是，这些是典型量级的估算起点，不是实测结果，不同语言、不同框架、不同业务复杂度下差异很大，真正的数字要用压测把进程 RSS 除以连接数测出来。

第一道墙是文件描述符，而且有两层

fd 是长连接服务最常撞的第一道墙，而且它有两层限制，很多人只调了其中一层，然后困惑地发现还是报 too many open files。

进程级限制：ulimit -n，也就是当前 shell 或当前进程能打开的 fd 数。很多发行版的默认软限制是 1024，这个值对长连接服务来说低得离谱，一千条连接就到顶了。它由软限制和硬限制组成，软限制可以在进程内自己往上调，但调不过硬限制。

系统级限制：fs.file-max 决定整机总共能分配多少 fd，fs.nr_open 决定单个进程能开到多少。整机上限受内存约束，内核会按内存大小给一个默认值，通常是几万到几十万的量级。单进程上限在很多发行版上是百万量级。

两层的关系很直接：一个进程实际能开的 fd 数，取的是进程级硬限制与 fs.nr_open 里更小的那个，同时所有进程加起来不能超过 fs.file-max。任何一层没动，连接数就停在那儿。

真正的坑在第三个地方：服务如果是用 systemd 拉起来的，只在 /etc/security/limits.conf 里改 ulimit 往往不生效，得在 service 文件里写 LimitNOFILE，或者在 systemd 的全局默认里改。limits.conf 只对 PAM 登录会话起作用。这个坑每年都要绊倒一批人，表现是"我明明在命令行里看到 ulimit -n 是 100 万，服务起来还是 1024"。

还有一点容易被忽略：fd 不是只给客户端连接用的。监听 socket 要占，日志文件要占，到数据库、缓存、消息中间件的连接要占，临时文件和各种句柄也要占。留 20% 到 30% 的余量是必要的，别把 fd 上限按目标连接数卡得死死的。

第二道墙是内存：按每条连接的开销反推

内存这道墙比 fd 温和一点，它不会让新连接直接失败，而是让进程越来越胖，直到某次分配失败或者被 OOM 杀掉——后者更糟，是一次性全掉。

反推的公式很简单：

总内存需求 ≈ 连接数 ×（内核侧每连接开销 + 应用层每连接开销 + TLS 会话开销）× 余量系数

余量系数建议取 1.5 到 2，涵盖堆碎片、GC 或分配器的额外占用、缓冲区在突发时涨上去的那部分，以及重连风暴时的瞬时堆积。用 GC 语言写的连接层尤其要留够，堆越大，停顿的影响范围越大。

按应用层每连接 10 KB 这个量级举例（再次说明，这是估算示例不是实测）：1 万连接约 100 MB，10 万连接约 1 GB，50 万连接约 5 GB。这还只是应用层这一项，内核侧的 socket 缓冲、sk_buff 池、TLS 会话状态都要另算，加起来在活跃时段可能再翻一倍。所以 10 万连接配 32 GB 内存不算奢侈，50 万连接往 64 GB 以上走更从容。

反过来看，如果只有 8 GB 内存，却指望单机撑 50 万连接，那不管 fd 调到多大、网卡多好，最后一定是 OOM 收场。内存这条线是最容易提前算出来的，别等到线上崩了再回头补。

应用层那部分开销是可以主动压下来的：把业务上下文里的大对象外移到共享存储或缓存里，只留必要标识；订阅关系用紧凑结构而不是哈希表的哈希表；未确认消息队列设上限，别让它无限制堆积；定时器用时间轮而不是每条连接一个系统定时器。每压下来 1 KB，10 万连接就是 100 MB。

心跳才是带宽和 CPU 的真变量：PPS 怎么算

心跳是长连接服务里唯一稳定存在、且规模随连接数线性增长的流量。它的特点是单包极小、数量极大，所以压力落在 PPS 和中断上，不在字节数上。

算法很朴素：单向 PPS ≈ 连接数 ÷ 心跳间隔。如果要算上服务端回应，双向再翻一倍。

举个算例：10 万连接、每 30 秒一次心跳，单向就是 100000 ÷ 30 ≈ 3333 个包每秒；把间隔改成 5 秒，就是约 2 万个包每秒。听上去 2 万 PPS 不算多，但如果这些包全被同一块网卡的同一个队列收上来、交给同一个核处理软中断，那个核很可能先被打满。

带宽这一侧按同样口径算：一个心跳帧加上 IP 头、TCP 头、WebSocket 帧头和以太网开销，量级在 100 字节上下。3333 PPS × 100 字节约等于 2.7 Mbps，2 万 PPS 约等于 16 Mbps。放在千兆或者万兆链路上，这点流量连零头都算不上。这就是为什么说带宽往往是最后一个瓶颈——它通常在 PPS 和 CPU 出问题之前，根本没被用起来。

那带宽什么时候会真的成为瓶颈？业务消息本身。一次全量广播，10 万连接每连接 1 KB，瞬时就是 100 MB 的数据要往外写，发送缓冲瞬间堆满，网卡队列排长队。这种压力跟心跳完全不是一个量级，需要在应用层做限流、分片发送和批量合并，而不是靠加带宽硬扛。

心跳频率怎么定？别无脑调快。心跳越密，PPS 和 CPU 线性上升，收益却只是"掉线检测更快"。常见的取舍是：服务端发心跳的间隔参考链路上的 NAT 老化时间——移动网络下运营商的 NAT 会话老化时间从几十秒到几分钟不等，心跳间隔要短于它才能保活，30 秒到 60 秒是常见区间；同时用"连续 N 次无响应判定掉线"来控制检测时延，而不是靠缩短单次间隔。客户端侧的心跳可以更稀疏一些，省电省流量。另外要允许业务在检测到空闲时临时放宽间隔，别让几万台没人操作的终端白白贡献 PPS。

PPS 上来了之后，网卡的处理方式很关键：选支持多队列（RSS）的网卡，把中断分散到多个核；必要时开 RPS/RFS 做软分发；把心跳处理线程和业务线程绑到不同的核上，避免相互抢。判断依据也很直接——看 top 里 si 这一项是不是集中在某一个核上打满，看 /proc/net/softnet_stat 里的丢包计数有没有在涨。

断线重连风暴：最容易被忽略的瞬间峰值

稳态跑得好好的系统，往往死在一次抖动上。机房网络闪断、进程重启、负载均衡切换、甚至一次发布，都会让大批连接在同一秒断开，然后客户端几乎同时发起重连。

瞬时新建连接速率的算法同样简单：连接数 ÷ 重连窗口。10 万连接如果在 5 秒内全部重连，就是 2 万新建每秒。这个数字放在稳态下毫无意义——稳态根本没有新建——但它决定了抖动那几秒机器会不会被打穿。

重连风暴同时冲击三个点。CPU：如果开了 TLS，每一次重连都是一次完整握手，非对称运算的开销集中爆发，CPU 会在几秒内冲到顶。连接队列：SYN 队列和 accept 队列同时排满，超出的包被丢弃，客户端表现为连接超时，然后它又重试，形成正反馈。后端依赖：每条新连接都要做鉴权、拉订阅关系、恢复会话，这些请求会一起打到缓存和数据库上，把后端的容量也一起吃掉。

应对要客户端和服务端一起做。客户端侧必须有退避，而且必须带随机抖动——纯指数的退避会让所有客户端在 1 秒、2 秒、4 秒这些整点上再次对齐，形成第二次、第三次风暴，加上 jitter 把重连时间点打散，才能真的削峰。服务端侧要对新建连接限速，超出的排队或直接拒绝并给出重试时间；进程下线要走优雅流程，先停止接受新连接，主动发关闭帧让客户端按各自的退避节奏重连，再分批重启，而不是一次性 kill。发布时按批次摘流量，每批之间留观察窗口。

容量规划上也要给重连留余量：稳态 CPU 建议控制在 30% 到 50%，剩下的就是留给握手的。这个余量不是浪费，是买保险。

内核参数各管哪一段（不写万能最优值）

网上流传的各种"最优内核参数"可以直接忽略，因为每一项的合理值都跟连接规模、单连接数据量、内存大小强相关，抄来的值多半不适合你。真正有用的是搞清楚每个参数管的是哪一段，然后按自己的规模调整并压测验证。改的时候一次只改一处，改完重跑同一套加压脚本对比，否则你永远不知道是哪一项起了作用。

管 fd 总量的：fs.file-max 是整机上限，fs.nr_open 是单进程上限，进程级是 ulimit -n 或 systemd 的 LimitNOFILE。三者要一起调，缺一个就卡住。

管本地端口的：ip_local_port_range。这里有个常见误解——入站的长连接并不消耗本地端口范围，同一个监听端口靠四元组区分成千上万条连接。端口范围真正影响的是服务端对外发起的连接，比如访问缓存、数据库、内部回调。如果服务本身还要往外发大量请求，这一项才需要放大。

管单连接缓冲与整机 TCP 内存的：tcp_rmem、tcp_wmem 给出单连接读写缓冲的最小值、默认值和最大值，tcp_mem 给出整机 TCP 内存池的三个水位。调大能抗住突发，但要记住它是按连接数放大的：单连接缓冲上限提高 1 倍，活跃连接的内存占用就接近翻倍。长连接服务一般是"连接数极多、单连接数据量很小"，盲从大缓冲配置是典型错误。

管新建连接排队的：somaxconn、tcp_max_syn_backlog，以及应用里 listen 时传的 backlog 参数。这三个在重连风暴时就是生死线，应用里的 backlog 不能小于系统值，否则系统值再大也没用。

管断线后残留的：tcp_fin_timeout、tcp_max_tw_buckets、TIME_WAIT 复用相关的开关。长连接服务本身断开不频繁，但一旦发生重连风暴，TIME_WAIT 会在短时间内堆积，占住内存和端口，需要按规模设上限。

管收包排队的：netdev_max_backlog、网卡 ring buffer 大小、RPS 相关配置。PPS 高但 CPU 还有余量却已经在丢包，多数是这一段堵了。

容易被忘的一项：如果链路上用了 iptables 或者 NAT 模式的负载均衡，nf_conntrack_max 会成为另一个隐形上限，连接跟踪表满了之后新连接直接被丢，而且它自己也要吃内存。走四层转发时务必检查这一项。

单机撑不住之后：横向扩容、会话保持、发布订阅、状态外移

当单机到顶，唯一能线性扩展的路就是加机器。但长连接的横向扩容跟无状态 Web 服务不是一回事，有四个点必须提前设计好。

连接层的负载均衡要考虑会话保持。长连接一旦断开重连，如果落到另一台机器，那台机器上没有这个用户的上下文，就得重新鉴权、重新拉订阅关系、重新补未送达的消息。一致性哈希是常用做法，但哈希键要选对——用用户 ID 或设备 ID，而不是源 IP，移动端切基站、切 Wi-Fi 之后 IP 会变，用 IP 哈希会频繁错配。摘流量时也要优雅：先禁止新连接进来，等存量连接自然退出或超时，而不是直接摘掉。

负载均衡自己也是瓶颈。四层转发同样受 fd、PPS、连接跟踪表的限制，而且它一端进一端出，同样的连接数在它这里是双份 PPS。所以转发层要能水平扩，常见做法是多台转发节点配合 ECMP 或者 DNS 轮询。别只扩了后端，忘了转发层。

把广播做成发布订阅。单机广播是 O(N) 的写放大，扩到 N 台之后，如果每台都去拉全量消息再各自广播，扇出量是 N 倍，消息中间件和内网带宽都会被放大打爆。正确做法是用发布订阅中间件做扇出，每台连接机只收自己需要的那一份，再分发给本机的连接。Redis 发布订阅、Kafka、NATS、RocketMQ 都能承担这个角色，选哪个看吞吐和延迟要求。

把状态外移。会话、订阅关系、未送达消息队列，能外移到缓存或消息中间件就外移，让连接层尽量无状态。无状态的好处是扩缩容和故障转移都很轻——少一台，剩下的机器接住就行，不需要迁移状态。

按业务分片。按租户、房间、区域做分片，让单台机器只承载一部分连接，既降低单机压力，也缩小故障影响范围。目标连接数不要贴着单机极限跑，留 30% 到 50% 余量，这样一台挂掉时，其他机器还能接住它那部分连接。

服务器怎么配：内存 > 网卡 PPS > CPU 核数 > 磁盘

长连接服务的硬件优先级跟普通 Web 服务不一样，排序是内存第一、网卡的 PPS 能力第二、CPU 核数第三、磁盘最后。

内存优先。配置直接由连接数反推：先测出单条连接的应用层开销，乘以目标连接数，再乘 1.5 到 2 的余量系数。10 万连接配 32 GB 是比较常见的落点，50 万连接建议 64 GB 起步。内存不够，其他配置再好也白搭。

网卡看 PPS 能力而不是只看带宽。前面算过，10 万连接每 30 秒心跳只占几 Mbps 带宽，但那是 3000 多个包每秒的处理量。真正要关注的是网卡的队列数、是否支持 RSS 把中断分散到多核、在多小包场景下的转发能力。万兆和 25G 的多队列网卡是长连接场景的主流选择，选型时把队列数和中断分布能力列进对比项。一万网络深耕 IDC 19 年（成立于 2007 年），在挑这类机型时可以直接按"目标连接数 → 内存容量 + 网卡队列能力"这条链去比配置，具体机型与费用以官网实时信息为准。

CPU 核数比主频更关键。TLS 握手、心跳帧解析、协议解析、软中断，这些活都能并行，核多就能摊开。单核性能再高，一个核扛不住 2 万 PPS 的软中断也白搭。另外开启 TLS 会话复用能显著降低重连时的握手开销，代价是一份会话缓存内存，这笔账按连接数算清楚就行。

磁盘够日志写就行。长连接服务本身不怎么写盘，但日志会。接入日志、断开日志、错误日志按连接数乘以频次增长，重连风暴时日志量会瞬间翻几倍。用 NVMe SSD 扛住突发写，日志走异步写、按级别可降级，别让同步落盘拖住事件循环——这是长连接服务里少数几个会因为磁盘把整体拖垮的地方。

上线前怎么验证：加压、看四条曲线、做重连风暴演练

先说清楚：本文不给实测数据，只给压测方法与观察指标。每台机器的实际上限取决于业务代码、语言运行时、内核版本和硬件，抄别人的数字没有任何意义，能复用的是方法。

压测机本身要先达标。压测客户端也要调 fd 和端口范围，而且必须分散在多台机器上——单机起不了 10 万连接，它自己的 fd 和 PPS 会先撑不住。压测机到被测机的链路也要确认不是瓶颈，否则你测的是压测机的上限。

逐步加压，别一步到位。按 1 万、5 万、10 万、再到目标值的 1.5 倍分档，每档稳定跑 10 到 30 分钟。长连接的问题很多是缓慢积累的——内存缓慢上涨、文件描述符缓慢泄漏、定时器越堆越多，短时间压测看不出来。

盯住四条曲线。第一条 fd 使用：/proc/sys/fs/file-nr 看整机，进程 fd 目录计数看单进程，ss -s 看 socket 汇总。第二条内存：进程 RSS、/proc/net/sockstat 里的 TCP 内存占用、系统可用内存，重点看增速是不是线性的、有没有平台期之后的二次上翘。第三条 PPS 与中断：sar -n DEV 看收发包速率，/proc/net/softnet_stat 看有没有丢包，top 看 si 是不是集中在单核。第四条 CPU：区分 us、sy、si，长连接服务的 sy 和 si 占比通常比 Web 服务高，这本身正常，但如果某一个核长期 100%，那就是队列没分散开。

记录拐点，而不是记录最大值。在哪一档开始出现 fd 接近上限、内存增长斜率变大、软中断丢包计数上涨、单核 CPU 打满，那个点就是这台机器的实际可用上限。理论值是算出来的，可用上限是压出来的，规划容量要用后者，再打七折。

做重连风暴演练。主动 kill 进程、重启服务、拔网线、把机器从负载均衡上摘掉再挂回去，观察新建连接速率曲线、握手耗时、后端依赖的负载，以及完全恢复需要多久。这个演练要定期做，因为代码和依赖会变，上一次能扛住不代表这一次也能。演练时把日志级别和监控采样调高，事后复盘才有料。

调内核参数时遵守一条纪律：一次只改一处，改完重跑同一套加压脚本，对比四条曲线。批量改参数的结果是，出了问题不知道该回退哪一个。

长连接服务的物理机配置参考在哪儿找

把前面的结论收成一句选型顺序：先定内存容量，再定网卡的队列与 PPS 能力，然后看 CPU 核数，最后按日志量给磁盘兜个底。这条顺序跟挑通用 Web 服务器的思路是反的——后者往往先看 CPU 和带宽。

一万网络这边能对应的，是裸金属和物理机的内存档位与网卡规格比选：目标 10 万连接就把 32 GB 以上内存和多队列万兆网卡列为硬条件，目标 50 万就把内存抬到 64 GB 以上、网卡考虑 25G 并确认队列数够用。至于具体机型、是否含 BGP 多线与免费 DDoS 防护、以及当下报价，以官网实时信息为准，未明示的部分按需实时询价处理。配置单让服务商按连接数目标来出，比自己按 CPU 核数挑要靠谱得多。

七个从工单里冒出来的疑问

带宽明明没跑满，为什么连接数就是上不去了？

因为卡住你的多半是 fd 或内存。先查进程级 ulimit 和系统级 fs.file-max 这两层是不是都调了，再看进程 RSS 是不是已经接近机器内存。判断方法很直接：连接建立时报 too many open files 就是 fd，内存曲线随着连接数线性上升然后 OOM 就是内存。带宽在这个阶段通常只用了百分之几，它是最后一个会出问题的资源。

ulimit 调了，为什么还是报 too many open files？

三个常见原因。一是只在 /etc/security/limits.conf 里改，但服务是 systemd 拉起来的，得在 service 文件里写 LimitNOFILE 才生效。二是只调了进程级，fs.file-max 或 fs.nr_open 还在低位，实际生效值取的是几者里最小的那个。三是 fd 被别的东西吃掉了——日志句柄没关、到缓存或数据库的连接池膨胀、临时文件泄漏，都会把 fd 用光。用进程 fd 目录计数看一下，到底是谁在占。

心跳多久一次合适？

不要追求越密越好，PPS 和 CPU 是随频率线性涨的。服务端心跳间隔要短于链路上 NAT 的老化时间，移动网络下常见取值在 30 秒到 60 秒；掉线检测时延靠"连续几次无响应判定掉线"来调，而不是靠缩短间隔。客户端侧可以更稀疏。别忘了加随机抖动，避免所有客户端的心跳在同一秒对齐。

TLS 要不要开，开销有多大？

要开。长连接里传输的是业务数据，明文跑在公网链路上风险太高。开销分两部分：每个会话多一份会话状态，量级在 KB 级，按连接数乘进内存账里；每次握手要算非对称运算，稳态下分摊到长连接生命周期里几乎可以忽略，但在重连风暴时是 CPU 尖峰的主要来源。开会话复用能显著降低重连开销，代价是会话缓存占内存，这笔账按连接数算清楚即可。

10 万连接要不要上集群？

单机能不能扛得住，取决于单条连接的应用层开销和机器内存。如果压测出来的实际可用上限明显高于 10 万且留了三到五成余量，单机可以先跑。但要不要上集群不只看容量，还看故障影响面：单机挂掉就是 10 万连接一起掉，业务能不能接受这个损失。多数线上业务到这个量级都会拆成多台，顺带把状态外移、转发层也一起规划了。

断线重连怎么防风暴？

客户端和服务端各出一半力。客户端必须做指数退避，而且必须加随机抖动，否则会在整点二次对齐形成连续风暴；服务端对新建连接限速并给出建议重试时间。进程下线走优雅流程：先禁新连接，主动发关闭帧让客户端按各自节奏重连，再分批重启。容量上给重连留 30% 到 50% 的 CPU 余量，并且定期做重连演练验证。

长连接服务和普通 Web 服务能不能放一台机器？

能，但不建议。两者争抢的是同一批资源：Web 服务突发请求会抢 CPU 和 fd，长连接服务需要稳定的内存和软中断处理能力。更麻烦的是故障耦合——Web 侧一个死循环或者一次 GC 停顿，可能让几万条长连接集体心跳超时。运维上也不方便，长连接服务要优雅摘流量才能重启，Web 服务通常直接滚动发布就行。资源紧张时至少要做进程隔离和资源限额，最好是物理分开。

先数 fd 和内存，再看带宽

回到最初那个问题。一台服务器能撑多少长连接，答案不在带宽那一栏，而在 fd 上限和内存账本里。先把进程级和系统级的 fd 两层都调对，再按"单连接开销 × 连接数 × 余量系数"把内存算出来，然后用心跳频率算一遍 PPS 确认中断不会集中在单核，最后才轮到带宽。这个顺序不能倒。

上限也不是算出来的，是压出来的。逐步加压，盯住 fd、内存、PPS、CPU 四条曲线，找到拐点，再打七折作为规划容量；然后定期做重连风暴演练，确认抖动场景下 CPU 和连接队列还有余量。做到这些，"能撑多少"这个问题就不再是拍脑袋，而是一份能拿出来说清楚的容量结论。

文中的估算是方法不是实测

本文出现的所有数字——单条连接几 KB 到几十 KB 的应用层开销、10 KB/条 的量级示例、1 万 / 10 万 / 50 万连接对应的内存与心跳包数、内核参数的作用范围——都是基于典型量级的估算方法和算例，用来说明应该怎么算，不是任何环境下的实测结果。不同语言运行时、不同框架、不同业务复杂度下，同一个数字可能相差数倍。

真正要拿去指导采购和容量规划的数字，必须自己压测得到：测出单条连接的实际开销，压出这台机器的实际拐点，测出重连风暴下的恢复曲线。本文能提供的只是这套方法本身，以及"先看 fd 和内存、最后才看带宽"这个判断顺序。

以上为按典型量级的估算方法示例，非实测数据，实际以压测结果为准。