前几天，一位朋友跑来问我一个问题：“小米，我们的系统准备使用 WebSocket 支持10万用户同时在线。可是 WebSocket 不是要占用端口吗？那10万人在线，是不是就得准备10万个端口？端口不够用了怎么办？”

我听完差点笑出声来，这就好比你开了一家大型餐厅，门口只有一个入口，里面却有10万个顾客。难道你要给每个顾客修一扇独立的大门吗？

当然不用！网络通信的设计，可比我们想象中聪明得多。今天，咱们就从这个问题出发，把 WebSocket 的端口分配、TCP 连接、操作系统资源，以及10万人在线背后的技术原理，一次性讲透。

Part 01

先搞清楚：WebSocket 到底需不需要端口？

答案是：需要，但不是每个 WebSocket 客户端都需要一个服务器端口。

WebSocket 通常基于 TCP 建立连接，常见的连接地址是这样的：

• ws://example.com/chat

• wss://example.com/chat

其中，ws 类似于 HTTP，通常使用80端口；wss 则是基于 TLS 加密的 WebSocket，通常使用443端口。

假设我们有一个 Java 服务，监听8080端口，对外提供 WebSocket 服务。

注意看，所有客户端都可以连接同一个服务器 IP 的8080端口。

这就像一栋办公大楼，只有一个总入口，但里面可以有成千上万个独立办公室。门口的号码是固定的，真正区分不同连接的，是每一条 TCP 连接的身份信息。

所以，第一个误区就被拆穿了：10万人在线，并不意味着服务器需要10万个监听端口，那问题来了，既然大家都连接8080端口，服务器又怎么知道收到的数据应该发给谁呢？

别急，真正的主角马上登场。

Part 02

TCP 四元组：每条连接都有自己的身份证

TCP 连接不是单纯由端口决定的。操作系统通常使用下面这四项信息来识别一条 TCP 连接：

• 源 IP 地址

• 源端口

• 目的 IP 地址

• 目的端口

这四项合起来，就叫作 TCP 四元组。

举个例子，假设有三个客户端连接同一台服务器。

你会发现，三条连接的目的端口都是8080，但源 IP 或源端口不同，因此它们是不同的 TCP 连接，服务器收到数据后，操作系统能够根据连接信息找到对应的 TCP 连接，再由应用程序处理数据。

这里有一个重要细节：服务器的监听端口和已建立连接的本地端口是两回事，监听套接字负责接收新连接请求；连接建立后，操作系统会为这条连接维护独立的 TCP 状态和相关资源，但本地端口仍然可以是8080。

也就是说，一台服务器完全可以在同一个 IP 的8080端口上，同时维护大量 TCP 连接，这就像酒店前台只有一个，入住的客人却可以有几千甚至几万个。前台负责接待，房间号和入住记录负责区分每位客人。

不过，这里还有一个值得注意的地方：客户端的源端口通常由客户端操作系统自动选择，而不是由 WebSocket 服务端给每个用户分配一个专属端口，客户端连接服务器时，可能使用类似下面的信息：

源端口通常从操作系统允许使用的临时端口范围中选择。具体范围取决于操作系统配置、网络环境以及端口占用情况。

因此，10万客户端连接同一服务器时，真正需要解决的不是“服务器如何分配10万个监听端口”，而是如何高效管理10万条连接。

Part 03

那10万条连接，会不会把端口耗尽？

既然服务器不需要为每个客户端分配独立的监听端口，为什么有些系统仍然会遇到端口耗尽的问题呢？

关键在于：端口资源限制和 TCP 连接数量限制，不是一回事，咱们分两种情况来看。

第一种：服务器作为服务端，接受10万个客户端连接。

假设服务器 IP 是 10.0.0.1，监听端口是8080。即使有10万个客户端同时连接，只要连接的 TCP 四元组各不相同，就可以共享这个监听端口。

第二种：服务器主动向其他服务发起大量 TCP 连接。

例如，某个 Java 服务需要同时连接另一个服务器上的大量 TCP 服务。这时，本机的源 IP、源端口以及目标地址组合就会影响可建立的连接数量。

如果目标 IP 和目标端口固定，本机可用的源端口范围就可能成为限制因素。端口被占用、连接处于特定 TCP 状态，或者受到操作系统资源限制，都可能导致新连接建立失败。

还有一种常见场景：大量用户通过 NAT 网关或负载均衡器访问服务。此时，网关自身的连接跟踪表、可用端口映射以及连接容量，也可能成为瓶颈。

所以，我们不能简单地认为“端口有65535个，最多只能连接65535个用户”，TCP 端口号是16位的，理论上有65536个编号，但0号端口保留，实际可用范围还受到系统配置和使用规则影响。这个端口编号空间并不等于服务器能够承载的 TCP 连接总数。

Part 04

真正的瓶颈：10万条连接要消耗多少资源？

好了，端口问题搞明白了，新的问题又来了：既然端口可以共享，服务器是不是就能轻松承载10万人在线？

答案依然是：不一定，因为每一条已建立的 TCP 连接，都需要维护相应的内核状态、缓冲区及其他资源。Java 应用还可能为每个 WebSocket 会话维护用户信息、消息队列、心跳状态和业务数据。

我们来看一下主要的资源消耗。

假设每个在线连接平均占用应用层和内核层合计约20KB的可归因内存，那么10万条连接就需要：

注意，这只是一个用于估算的示例，并不是所有服务器都固定占用20KB。实际开销会随操作系统、TCP 缓冲区配置、JDK、框架实现和业务对象大小而变化。

更重要的是，10万人在线不代表10万人同时发消息，如果10万人只是偶尔接收通知，系统的压力可能相对较低；如果每个人每秒发送一条消息，服务端每秒就要处理10万条入站消息。假设每条消息还要广播给大量用户，网络和业务处理压力就会迅速放大。

连接数衡量的是在线规模，消息吞吐量衡量的是实时处理压力，两者必须分开评估。

Part 05

Java 如何支撑10万条 WebSocket 连接？

在 Java 生态中，常见的选择包括 Netty、Spring WebSocket，以及基于 Servlet 容器的 WebSocket 实现，它们的核心思路是利用操作系统的网络 I/O 能力，避免为每条连接都分配一个长期阻塞的线程。

以 Netty 为例，它采用事件驱动架构，可以通过少量 I/O 线程管理大量连接。对于 Linux 系统，底层通常可以利用 epoll 等机制监测多个套接字的 I/O 就绪状态。

传统的“一连接一线程”模式，就像给每位顾客配一个专职服务员。人数增加后，光是管理服务员就会产生大量开销，而 Netty 的事件循环，更像一组经验丰富的服务员，同时照看许多桌客人：谁需要服务，就处理谁的事件，不必让每张桌子都长期占着一个专人。

不过，事件驱动并不意味着可以无限扩容。假如某个 I/O 线程执行了耗时的数据库查询，其他连接的网络事件也可能受到影响。因此，耗时业务通常应交给合适的业务线程池或异步流程处理，避免阻塞 I/O 事件循环。

实际部署时，可以重点检查以下配置：

• 文件描述符限制： 检查进程的 ulimit -n，并结合系统限制评估容量。

• 连接队列： 合理配置监听队列和相关内核参数，避免突发连接时出现接入压力。

• 内存预算： 按连接数、单连接内存、业务缓存和消息积压量估算总内存。

• 心跳机制： 及时发现失效连接，同时避免所有客户端在同一时刻集中发送心跳。

• 反压与限流： 为慢客户端设置有界发送队列，必要时丢弃非关键消息或断开异常连接。

• 水平扩容： 通过负载均衡将连接分散到多个 WebSocket 实例，并解决跨实例消息路由问题。

特别提醒：WebSocket 是长连接。负载均衡器必须正确支持连接升级，并为长连接设置合适的超时策略。对于多实例广播，可以使用 Redis Pub/Sub、消息队列或其他消息分发机制，但具体方案要结合消息可靠性、顺序和吞吐量要求选择。

Part 06

面试官追问：一台服务器到底能承载多少连接？

这道题最容易踩的坑，就是直接给出一个固定数字，实际上，一台服务器能承载多少 WebSocket 连接，取决于硬件配置、操作系统参数、JVM 内存、框架实现，以及业务消息的频率和大小。

如果只是维持空闲连接，经过合理优化的服务器可能承载数万甚至更多连接；但这不意味着同样的服务器能够稳定处理同等规模用户的高频消息。

真正做容量评估时，应当使用接近生产环境的压测模型，分别测试连接建立速率、稳定在线数量、消息吞吐量、广播扇出、延迟分位数和异常断连恢复能力。同时观察文件描述符、RSS 内存、堆内存、GC、CPU、网络带宽和发送队列长度。

面试时，可以用下面这段话总结：

WebSocket 通常基于 TCP，一个服务端监听端口就可以接收大量客户端连接，并不需要为每个用户分配一个独立的服务器端口。TCP 通过源 IP、源端口、目的 IP 和目的端口组成的四元组区分连接。真正限制10万人在线的，通常是文件描述符、内存、CPU、网络带宽以及业务处理能力。因此，系统设计应重点关注 I/O 模型、连接资源管理、消息分发和水平扩容，而不是简单计算服务器端口数量。

END

阅读原文：点击这里​