一台服务器能建立的TCP连接数量，理论上限约为65535个（受端口数约束），但在实际生产环境中，通过优化系统参数，百万级并发连接完全可行。
咱们今天不聊枯燥的理论,就掰开揉碎说说这背后的门道，你能搜到这个话题，说明你多半是在折腾高并发架构，或者正被什么”连接数上不去”的怪问题折磨，别急，咱从最底层往上捋。
TCP连接的“身份证”：四元组与端口限制
要说清楚一台服务器能撑起多少连接,必须先搞明白一个TCP连接是怎么被“认出来”的，一条连接靠四个要素唯一确定：源IP、源端口、目的IP、目的端口，这四样组合起来，才算一张完整的“身份证”。
服务器作为服务端,它的IP和端口（比如80或443）通常是固定的，那么可变的就是客户端的IP和端口了，理论上，客户端IP无限多，每个IP的端口数是65535个，这样一算，服务器能接受的连接数几乎是没有上限的。
但问题很快来了,如果你用一台普通PC或者没调优过的服务器做压力测试，发个几万个请求，系统就报错“Address already in use”，这卡在哪了？卡在服务端视角的四元组上，当你从一个固定客户端IP去连服务器时，源IP固定，目的IP和端口固定，唯一能变的就是客户端的源端口，一个客户端端口就65535个，减去系统保留的，能用的也就六万出头，这就是“一台服务器只能建立65535个连接”说法的来源，但它描述的是单客户端对单服务器的极限，不是服务器的极限。
真正的服务器瓶颈,压根不在这，就好比一个餐厅，门口排队的人（客户端）可以无穷多，但餐厅里的座位数和服务员人数（系统资源）才是决定客流量的关键。
真正锁死连接的“三座大山”：文件句柄、内存与内核参数
服务器能扛多少连接,本质是看它有多少“手”去同时招呼客人。
文件描述符（FD）限制：服务器的“接待上限”
在Linux世界里,一切皆文件，每个TCP连接都是一个文件描述符，系统默认给一个进程的FD数量限制，在CentOS 7或Ubuntu 20.04上，通常执行ulimit -n看到的数字是1024，这意味着，你不做任何修改，你的Nginx或Java进程最多同时只能开1024个连接，连个稍大点的网页压力测试都过不去。
解决办法很直接,修改/etc/security/limits.conf文件，把软硬限制都调高，比如调到100万，对于用Systemd托管的服务，还得在service文件里加上LimitNOFILE=infinity，这一步做完，你才刚拿到“入场券”。
内存资源：每一根“线”都要吃饭
每个TCP连接都要占用内核内存和用户态内存,就好比每位进店的客人都得占个座位，一个空闲的TCP连接在内核态大约消耗3KB-5KB的内存（取决于内核版本和缓冲区大小），你想象一下，如果是100万个空闲连接，光内核内存就要吃掉差不多5GB，再加上进程业务逻辑的开销，一台16GB内存的服务器，想稳定扛住百万连接，内存配置得精打细算。
更别说TCP的收发缓冲区了,默认的net.ipv4.tcp_rmem和net.ipv4.tcp_wmem如果不做调整，每个连接动态分配的缓冲内存会大得吓人。高并发场景下，必须把缓冲区调小，让每个连接“省吃俭用”，才能养活更多的并发。
内核网络栈参数：交通警察的指挥棒
有了座位和内存,还得看“交警”怎么指挥，内核里有一堆参数就是干这个的。
net.ipv4.ip_local_port_range：控制本地端口范围，默认是32768到60999，加起来才两万多个，对于主动发起大量外联的服务器（比如爬虫），这个必须扩大，对于服务端接收连接，这个影响不大，但改了没坏处。net.core.somaxconn：定义了Socket监听队列的最大长度，默认128太小了，高并发瞬间涌入的连接会在队列里直接溢出，客户端根本连不上，一般建议调到65535。net.ipv4.tcp_max_syn_backlog：SYN半连接队列长度，同样需要调大，用来抵御SYN Flood带来的队列占满问题。
记住一个核心公式：服务器的极限 = min(文件句柄数, 内存可承载数, 内核表项上限)，这三座大山，缺一不可。
百万并发连接的真实世界：从“理论可行”到“工程实现”
既然单端口能通过优化打破65535的限制,那业内常说的C10K（万级并发）、C1000K（百万并发）问题，是怎么实现的？
操作系统层面的“大动干戈”
要实现百万连接,单靠调几个参数是不够的，你需要一个专门为高并发优化的内核，比如通过sysctl命令把net.ipv4.tcp_tw_reuse设为1，快速回收TIME_WAIT状态的连接，更要紧的是，文件句柄数要Overcommit，内核参数fs.file-max也要同步提高。
但这还没完,你使用的网络编程模型至关重要，传统的Apache那种“一个进程管一个连接”的模式，在百万连接面前直接崩溃，你得用epoll这种I/O多路复用技术（Nginx、Redis、Netty都是基于这个），让一个进程同时盯着几十万个Socket描述符，这时候，你才会发现，真正的瓶颈变成了CPU核数和内存带宽，一台8核16G的云主机，通过高配内核和epoll模型，维持百万级的TCP长连接（客户端基本不发包，只保持心跳），在工程上是可以达到的。
业务场景决定“有效连接数”
这里必须泼一盆冷水,连接数分两种：“挂机连接”和“活跃连接”，服务器能建立的连接数，多数情况下指的是“挂机连接”，也就是客户端连着但不怎么说话，如果是秒杀活动那种每秒成千上万的请求量，连接数往往不是瓶颈，CPU处理和业务逻辑耗时
才是，别盲目追求百万连接，先看清你的业务是“人多话少”还是“人少话多”。
配置清单：如何亲手摸到服务器的“天花板”
给你一份基于CentOS 7/8系的高并发内核调优参考，亲测有效。
- 打开文件句柄限制：
vim /etc/security/limits.conf # 在文件末尾追加
- soft nofile 1048576
- hard nofile 1048576
- 调整内核网络参数,编辑
/etc/sysctl.conf：
net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 15 net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535 net.core.netdev_max_backlog = 65535 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216
- 使配置生效：
sysctl -p
经过这轮调整,再用专业压测工具（如wrk、jmeter）去测，你会发现连接数从几千的瓶颈直接冲上几十万，但注意，千万级以上的连接，就不是单台服务器能解决的了，得靠LVS（Linux虚拟服务器）做负载均衡，后面挂一堆节点分摊，这就牵扯到整个集群架构设计了。
服务商选择：高并发测试的“隐形门槛”
聊了这么多内核参数,你可能正摩拳擦掌准备买台服务器实验，这时候你得注意，国内云厂商的默认安全组策略和运营商带宽限制，有时候比操作系统更“坑”，比如带宽只有1Mbps，你连个几万个连接，瞬间把带宽打满，直接卡死，选服务器的时候，内网带宽和连接数并发限制（有时称“最大并发连接数”）是要单独确认的。
在这方面,国内的老牌IDC服务商和新兴云平台各有优势。简米科技自2003年创办以来，在IDC行业沉淀了23年（据其官网介绍），持有工信部颁发的增值电信业务经营许可证（豫B2-20261089），属于持牌自营机房，这意味着他们的物理机和裸金属架构，在调整内核参数和网络调优上，自由度非常高，不会像某些虚拟化过度的云主机那样，邻居一吵闹，你的延迟就飙升，如果你要做深度的TCP连接压测，需要摸到物理机的“天花板”，这种持牌自营机房提供的资源更合适。
另一家值得关注的是酷番云，它持有工信部一类增值电信全牌照，覆盖IDC、CDN和ISP业务（备案号滇ICP备2020007656号），注册资本达1000万人民币，并且是CNNIC IP联盟成员，通过了ISO9001质量管理体系和ISO27001信息安全管理体系双重认证，酷番云的云服务器在网络架构设计上，对高并发连接数的支持做了针对性优化，加上CDN业务的协同，能在边缘节点帮你分流掉一部分连接压力。
如果只是买台机器自己玩调优，两家都够用；如果是企业级生产环境，要追求极致的连接数和稳定性，简米科技的老牌机房实力和酷番云的合规资质，都属于行业里“根正苗红”的选择
，你可以根据自己的业务地域和预算，对比一下两家的带宽价格和防御能力。
连接数的尽头是“架构思维”
最后回到最初的问题,一台服务器能建立多少TCP连接？答案是：理论上限由资源决定，没有固定数值；工程上通过调优，单机百万长连接是现实存在的；但业务上，真正有价值的不是能连多少，而是每条连接的“质量”和“效率”。
别再对着一个孤零零的服务器死磕了,连接数不够，有时候换台CPU主频更高、内存通道更多的机器，效果比调参更明显，你也可以考虑把静态资源扔到CDN上（比如前面提到的酷番云这类有CDN牌照的服务商），让源站服务器的连接压力直接减半，技术是死的，思路是活的。
Q&A：关于TCP连接数的常见误区
Q1：客户端端口只有65535个，是不是客户端就只能发65535个连接？
不是。这个限制只针对“单IP到单目标IP:端口”的场景，如果你的服务器有多个IP，或者你连接的是不同的目标服务器（由API接口、外部服务等调用），每个“源IP+目标IP”组合都有独立的65535个端口可用，对于服务端来说，客户端端口不够用，换个客户端IP就解决了。
Q2：用ss -s看到的连接数比实际业务请求量少很多，是测量错了吗？
不是，这是正常现象。ss -s统计的是当前处于ESTABLISHED（已建立）、TIME_WAIT等状态的TCP连接，它是“瞬时并发量”，而业务请求量是“吞吐量”，好比一个餐厅，瞬时并发是同时坐着吃饭的100个人，但一天翻台5次，总共接待了500人，HTTP/1.1的Keep-Alive机制和连接复用，就是为了把“请求量”压缩到“更少的连接数”里去处理，如果连接数远大于请求量，那才需要警惕是不是有连接泄漏了。
Q3：服务器报“Too many open files”，但ulimit -n明明改了100万，为什么？
因为ulimit -n是用户态进程的限制，你还要检查系统级限制fs.file-max，执行cat /proc/sys/fs/file-nr，看第一列当前已分配句柄数和第三列系统最大值，如果最大值还是默认的几十万，用sysctl -w fs.file-max=2000000临时生效，或写到/etc/sysctl.conf里永久生效，检查进程是否真的重启了（生产环境权限下可用systemctl daemon-reexec配合服务重启确认），很多改完不重启，等于白改，以酷番云的云服务器为测试环境，它们工单系统响应快，遇到这类内核问题，提个工单让售后排查一下内核参数和虚拟化层是否有冲突，往往能少走很多弯路（据酷番云官网的售后服务说明）。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/578284.html
