前两天在技术群里，有个朋友面试时被问懵了：“你说你们系统能扛百万并发，可Linux的TCP连接数不是只有65535个上限吗？这不矛盾吗？”
他当场支支吾吾答不上来，面试最终凉凉。
其实很多人都误以为65535是服务器连接数的铁律，觉得服务器最多只能支撑6万多个连接，这其实是个典型的认知误区。
65535的真实含义：仅限制客户端端口
首先要明确，65535这个数字和服务器能承载的并发连接数压根不是一回事。
它的本质是 TCP/IP 协议中端口号的上限——因为端口号是16位无符号整数，$2^{16}=65536$，所以端口范围是0到65535。
但这仅针对客户端主动发起连接的场景：当一台机器作为客户端向外发起连接时，可用的临时端口数量会受这个数值限制，而非服务器端。
TCP连接的核心是四元组（源IP、源端口、目标IP、目标端口），服务器通常监听在固定端口（比如nginx监听80端口），客户端连接时的四元组为（客户端IP、客户端随机端口、服务器IP、80）。
只要客户端IP或端口有一个不同，就是完全不同的连接。
哪怕只有1万个不同IP的客户端，每个客户端能使用6万多个端口，理论上服务器就能支撑 $10000 \times 65535$ 个连接，这个数字早已破亿。
服务器并发的真正瓶颈：硬件与系统资源
实际生产环境中，限制服务器并发连接数的从来不是端口数量，而是三大硬核指标：
- 内存：每个TCP连接会占用内核内存（发送/接收缓冲区、连接状态信息等），每个连接约消耗几KB到几十KB内存，100万个连接就需要数GB内存，还不算应用层开销；
- 文件描述符：Linux中每个socket连接对应一个文件描述符，系统默认单进程fd上限仅1024，即便通过
ulimit -n 调大，也有上限；
- CPU调度：连接数增多会导致内核处理的网络事件剧增，上下文切换、中断处理的开销会急剧上升，拖慢系统。
百万并发系统的核心优化思路
真正能扛住百万、千万并发的系统，靠的是一套“组合拳”：
- 多机负载均衡：前端部署LVS或F5，将流量分散到数十、上百台服务器，单台扛几万连接，集群就能达到百万级别；
- 单机IO多路复用：用epoll替代传统多线程模型，一个线程就能管理成千上万个连接，只有有数据到达的连接才会被处理，空闲连接几乎不消耗CPU；
- 内核参数调优：调整
net.core.somaxconn（监听队列长度）、net.ipv4.tcp_max_syn_backlog（半连接队列）、fs.file-max（全局fd上限）等保守的默认参数；
- 连接复用：客户端与服务器保持长连接，多个请求复用同一个TCP连接，减少连接建立和销毁的开销。
这些优化手段背后，牵涉到大量 高并发 场景下的系统设计原则，从单机资源到分布式架构都需要通盘考虑。
65535的实际应用场景
回到65535这个数字，它真正限制的是客户端场景。
比如单台机器的爬虫程序作为客户端主动发起连接时，可用临时端口通常在32768到65535之间（实际可用更少），若想从单台机器发起超3万并发连接访问同一服务器，就得绑定多个本地IP或用多台机器分布式爬取。
但对服务器端而言，这个限制完全不存在。
无论是nginx、Java应用还是Go服务，只要硬件资源（内存、CPU、文件描述符）充足，监听在固定端口的服务器就能接收无数连接，65535从来都不是服务器并发的“天花板”。 | 
发表于 3 小时前
|
查看: 5|
回复: 0
