Linux的TCP连接数量最大不能超过65535个,那服务器是如何应对百万千万并发的?

大家好，我是良许。

前几天在技术群里，有个朋友面试时被问懵了："你说你们系统能扛百万并发，可Linux的TCP连接数不是只有65535个上限吗？这不矛盾吗？"

他当场支支吾吾答不上来，面试最终凉凉。

其实很多人都误以为65535是服务器连接数的铁律，觉得服务器最多只能支撑6万多个连接，这其实是个典型的认知误区。

65535的真实含义：仅限制客户端端口

首先要明确，65535这个数字和服务器能承载的并发连接数压根不是一回事。

它的本质是TCP协议中端口号的上限——因为端口号是16位无符号整数，2¹⁶=65536，所以端口范围是0到65535。

但这仅针对客户端主动发起连接的场景：当一台机器作为客户端向外发起连接时，可用的临时端口数量会受这个数值限制，而非服务器端。

TCP连接的核心是四元组（源IP、源端口、目标IP、目标端口），服务器通常监听在固定端口（比如nginx监听80端口），客户端连接时的四元组为（客户端IP、客户端随机端口、服务器IP、80）。

只要客户端IP或端口有一个不同，就是完全不同的连接。

哪怕只有1万个不同IP的客户端，每个客户端能使用6万多个端口，理论上服务器就能支撑10000×65535个连接，这个数字早已破亿。

服务器并发的真正瓶颈：硬件与系统资源

实际生产环境中，限制服务器并发连接数的从来不是端口数量，而是三大硬核指标：

1. 内存：每个TCP连接会占用内核内存（发送/接收缓冲区、连接状态信息等），每个连接约消耗几KB到几十KB内存，100万个连接就需要数GB内存，还不算应用层开销；
2. 文件描述符：Linux中每个socket连接对应一个文件描述符，系统默认单进程fd上限仅1024，即便通过ulimit -n调大，也有上限；
3. CPU调度：连接数增多会导致内核处理的网络事件剧增，上下文切换、中断处理的开销会急剧上升，拖慢系统。

百万并发系统的核心优化思路

真正能扛住百万、千万并发的系统，靠的是一套"组合拳"：

1. 多机负载均衡：前端部署LVS或F5，将流量分散到数十、上百台服务器，单台扛几万连接，集群就能达到百万级别；
2. 单机IO多路复用：用epoll替代传统多线程模型，一个线程就能管理成千上万个连接，只有有数据到达的连接才会被处理，空闲连接几乎不消耗CPU；
3. 内核参数调优：调整net.core.somaxconn（监听队列长度）、net.ipv4.tcp_max_syn_backlog（半连接队列）、fs.file-max（全局fd上限）等保守的默认参数；
4. 连接复用：客户端与服务器保持长连接，多个请求复用同一个TCP连接，减少连接建立和销毁的开销。

65535的实际应用场景

回到65535这个数字，它真正限制的是客户端场景。

比如单台机器的爬虫程序作为客户端主动发起连接时，可用临时端口通常在32768到65535之间（实际可用更少），若想从单台机器发起超3万并发连接访问同一服务器，就得绑定多个本地IP或用多台机器分布式爬取。

但对服务器端而言，这个限制完全不存在。

无论是nginx、Java应用还是Go服务，只要硬件资源（内存、CPU、文件描述符）充足，监听在固定端口的服务器就能接收无数连接，65535从来都不是服务器并发的"天花板"。

END

来源：良许Linux