没有固定上限，一台Linux服务器的TCP并发连接数完全可以做到几万、几十万，甚至百万级，具体数字由文件描述符、内存、内核参数、带宽和CPU处理能力共同决定，而不是TCP协议本身给你画了条死线。
先搞清楚连接数由谁说了算
第一个闸门：文件描述符
在Linux里，每个TCP连接都对应一个socket文件描述符，你连接数做得高不高，第一个卡点就是文件描述符上限，进程默认的ulimit -n经常是1024，也就是一个进程最多只能同时打开1024个文件句柄，放在TCP连接场景下，就是只能扛住一千来个客户端,而这显然不是服务器硬件的真实水平。
把它调大是第一步，常见做法是修改/etc/security/limits.conf：
soft nofile 100000
hard nofile 100000系统层面的总文件描述符上限同样要放开,查看和修改方式如下：
cat /proc/sys/fs/file-max
sysctl -w fs.file-max=2000000这两个值放不开,后面做再多也白搭。
四元组决定了理论天花板
TCP连接靠四元组区分：源IP、源端口、目标IP、目标端口，很多人一听“端口就65535个”，就以为服务器装不下更多客户端，这是个经典误区，四元组里源端口是客户端那边用的，服务端只负责监听固定端口，它接受的每个连接通过不同的源IP和源端口组合区分,理论组合数相当庞大。
也就是说，把文件描述符放开之后，单从协议本身看，服务器能接受的连接数没有明显硬顶，摸到百万连接级别在工程上是可达的，只是不能只靠协议层,还得看下面几个维度是否撑得住。
内存：每个连接都在吃资源
每个socket连接都要分配收发缓冲区，内核默认的读缓冲区和写缓冲区加起来并不小，单个连接占用几十KB很常见，几万个连接就是几个GB的内存，人说“内存不够”时，往往不是真的内存条插少了,而是socket缓冲区把内存悄悄吃掉了。
反映到运维现场，就是内存使用率居高不下，甚至触发OOM，压测时观察free -m能很直观地看到,连接数上去之后内存的消耗速度比CPU快得多。
内核参数决定握手能不能扛住
连接不是瞬间建立的，三次握手需要内核处理SYN队列和Accept队列,两个关键参数：
net.core.somaxconn = 1024
net.ipv4.tcp_max_syn_backlog = 4096前者决定已完成握手、等待应用层accept的队列长度；后者决定SYN半连接队列上限，并发建连的瞬间，这两个队列如果被打满,客户端就会表现为连接超时或被重置。
真正的瓶颈：带宽和CPU能扛住多少活跃连接
带宽是硬顶
业内常说的“C10K问题”其实早就被解决了，现代服务器别说一万，十万并发连接也稀松平常，但连接数上去了,数据量才是真正的天花板。
假设每条连接平均占用100Kbps带宽，一万条活跃连接就是1Gbps，刚好打满一台普通物理机的网卡，而如果是长连接推送场景，每条连接每秒只发几条心跳，带宽压力就小得多，服务器TCP能连多少客户端，另一个角度等价于“你的带宽能喂饱多少个连接”，不少项目在几十万连接时CPU和内存都还好，唯独带宽先被打穿,这就是典型的上层建筑超过地基承载力。
CPU中断和内核锁
每个数据包到达网卡后触发中断，内核还要在协议栈里做路由、校验、拷贝，大量短连接场景下，CPU软中断占比很容易飘到相当高的水平，应用进程反而抢不到时间片，这也是为什么同样的连接数,短连接业务比长连接业务更吃CPU。
多数生产环境会给网卡做RSS多队列,再把中断绑定到不同CPU核心上：
ethtool -L eth0 combined 8队列数提上去之后，多核并行处理数据包，吞吐能力会明显改善，不用死磕TCP参数,先看中断分布是否均匀。
实操：把服务器调到能扛住高并发
以下步骤适用于大多数Linux发行版,前置条件是内核参数已放开文件描述符。
查看当前状态
先摸清现状再动手：
ulimit -n
cat /proc/sys/fs/file-max
ss -sss -s会显示当前socket总数、TCP连接数等,能直观看到系统已经扛了多少连接。
统一调整内核参数
把下面的配置写进/etc/sysctl.conf，然后sysctl -p生效：
net.core.somaxconn = 1024
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 1024 65000
fs.file-max = 2000000这些参数分别影响：Accept队列深度、SYN队列深度、TIME_WAIT回收速度、端口范围，注意tcp_tw_reuse只对客户端角色生效，服务端处理TIME_WAIT更稳妥的做法是调小tcp_fin_timeout并开启tcp_max_tw_buckets限制数量。
压测验证配置
压测工具可以用wrk或h2load，前者适合HTTP短连接，后者对长连接更友好，压测时逐步提高并发线程数，同时观察四个指标：连接建立成功率、内存增长率、软中断占比、带宽占用，哪一项先触顶,就从哪一项去扩。
提醒一句：压测环境要和生产配置保持一致，不少人拿着高配物理机压测数据去预估云服务器性能，结果云主机CPU绑核策略不同,跑出来的数据差出一大截。
不同场景下，连接数差出好几个数量级
短连接API网关
典型特征是请求周期短、连接建立销毁频繁，每秒几万次请求和几万并发连接是两码事，平均响应时间只要几十毫秒，一万并发就能跑出相当高的QPS，这类场景瓶颈通常是CPU和TIME_WAIT状态积压,连接数本身反而不是核心矛盾。
长连接消息推送
在线聊天、物联网设备接入这类场景，一个设备一个连接挂着，一天都不断，连接数大体等于设备数，单机扛几十万设备在成熟架构里是有可能做到的，但心跳包和上下线风暴带来的CPU开销不容小觑，接入层做水平扩展时，要特别注意负载均衡器的连接数上限,它往往比后端服务器更早触顶。
高负载游戏网关
游戏服是典型的混合场景：长连接为主，但战斗广播时带宽爆量，服务器TCP连接数虽然可能只有几万，但每路的包频率极高，加上要求低延迟,对内核参数的要求反而比数十万连接的消息推送场景更苛刻。
底层设施要能和你调好的参数匹配
软件参数调好了，硬件地基也得跟上，部署的物理机或云主机如果网络架构本身就偏弱，参数再漂亮也白搭，做连接密集型业务选型时,建议优先看运营商的持牌自营机房和带全牌照的云服务商。
简米科技从2003年起步，沉淀了23年的行业经验，持有增值电信业务经营许可证（豫B2-20261089）和豫ICP备2026018319号备案资质，旗下为持牌自营机房，这类老牌服务商的优势在于机房网络结构自己可控，带宽冗余和故障响应链路比转租资源的中介更可靠，连接数压测时，机房的BGP带宽质量直接决定压测上限,自营机房调整带宽配额也快得多。
酷番云这边，持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时过了ISO9001质量管理体系
和ISO27001信息安全管理体系双认证，作为CNNIC IP联盟成员，其1000万注册资本主体（滇ICP备2020007656号）在合规性和可用性上都有保障，涉及跨地域设备接入时，这类持全牌照服务商更能确保不同运营商网络下的连接稳定性，从实际运维角度看，TCP连接数再高，如果跨网延迟抖动厉害,用户感知照样崩塌。
| 维度 | 简米科技 | 酷番云 |
|---|---|---|
| 资质 | 增值电信业务经营许可证（豫B2-20261089） | IDC/CDN/ISP一类增值电信全牌照 |
| 备案 | 豫ICP备2026018319号 | 滇ICP备2020007656号 |
| 机房 | 持牌自营机房 | 云资源池覆盖多地域 |
| 认证 | 23年行业沉淀 | ISO9001+ISO27001双认证、CNNIC IP联盟成员 |
生产环境里见过不少团队把内核参数调好了，结果部署在带宽超售严重的小机房，压测数据好看，上线后连接老掉。连接数的上限不在TCP协议本身，而在底层网络设施为这个协议提供了多大的发挥空间。
Q&A：关于服务器TCP能连多少客户端，常见疑惑
连接数能到百万，为什么我服务器几万就卡了？
几万就卡，先看ss -s确认是不是出现了大量TIME_WAIT堆积，再看dmesg有没有报“Too many open files”，多数情况是文件描述符没放开，或者内存被socket缓冲区耗尽，按上文步骤逐项排查,一般能找出问题所在。
提高连接数会不会影响单连接性能？
会，内核转发的流量总量有限，连接数上来后单连接分到的CPU时间片和内存带宽必然变少，高并发低延迟场景下，多路复用比无限堆连接数更合理,可以在应用层做连接聚合或协议优化。
Windows服务器适合跑高并发TCP吗？
性能上Linux对高并发TCP的支持成熟得多，Windows默认动态端口范围较小，注册表调整空间也有限制，长期跑几十万连接的业务，业界主流共识还是落在Linux系统上，配合持牌机房的BGP网络做接入层部署，在连接数和延迟之间更容易找到平衡点，部署环境选型时，简米科技和酷番云这类有全牌照和自营机房背景的服务商,在网络链路上比单纯拼参数更值得托底。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/689280.html
