一台服务器究竟能支撑多少条 TCP 连接？从内核参数到百万并发的深度拆解

理解“一台机器最大能支撑多少 TCP 连接”这个问题，不能一概而论。我们需要将“服务端”与“客户端”分开讨论，因为二者消耗的资源有本质区别。同样，还要考虑连接是仅处于 ESTABLISHED 的空闲状态，还是在进行频繁的数据收发与业务处理。

在深入探讨之前，我们需要先了解一个根本限制：Linux 系统中，一切皆文件，Socket 也不例外。所以，先搞清楚一台服务器能打开多少文件，是理解其网络连接上限的钥匙。

一、一台服务器最大能打开多少个文件？

Linux 系统对文件打开数量的限制，主要由以下三个参数控制：

• fs.file-max (系统级)：定义了整个系统层面可以打开的最大文件数。需要注意的是，root 用户的操作不受此限制。比如，即使当前系统打开的文件描述符已经达到 fs.file-max，root 用户仍能执行 ps、kill 等命令来管理进程。
• soft nofile (进程级)：限制单个进程可打开的最大文件数。这个参数只能在系统全局层面配置一次，无法为不同的用户设置不同的值。
• fs.nr_open (进程级)：同样限制单个进程可打开的最大文件数，但它允许为不同用户配置不同的限额。

这三个参数之间存在耦合关系，配置时务必注意以下三点：

1. 如果想调大 soft nofile，必须同步调整 hard nofile 的值。实际生效的值会取二者中的最小值。如果 hard nofile 设得很低，soft nofile 设得再高也毫无意义。
2. 如果调大了 hard nofile，那么 fs.nr_open 也必须随之调整，且 fs.nr_open 的值必须大于 hard nofile 的值。如果不小心把 hard nofile 设得比 fs.nr_open 还大，会导致该用户无法登录系统；若配置是针对所有用户（用 * 通配符）的，后果则是所有用户都无法登录。
3. 虽然可以通过 echo "xxx" > /proc/sys/fs/nr_open 来临时修改 fs.nr_open 的值，刚改完可能没事，但机器一重启，这个值就会失效，从而再次引发无法登录的问题。因此，强烈不建议用 echo 命令直接修改内核参数！

调整服务器能打开的最大文件数示例

假设我们的目标是让一个进程能打开 100 万个文件描述符，通过修改配置文件来实现是最稳妥的做法，可以参考以下步骤：

编辑系统内核参数文件：

vim /etc/sysctl.conf

写入以下配置：

fs.file-max=1100000 // 系统级设置成110万，多留点buffer
fs.nr_open=1100000  // 进程级设置成110万，一定要保证比 hard nofile 大

使配置生效：

sysctl -p

编辑安全限制配置文件：

vim /etc/security/limits.conf

写入以下配置：

// 用户进程级别都设置成100万
soft nofile 1000000
hard nofile 1000000

二、一台服务器最大能支持多少连接？

TCP 连接的根本，是客户端与服务端在各自内存中维护的一组 socket 内核对象，它由一个唯一的 TCP 四元组（源IP、源端口、目标IP、目标端口）来标识。只要双方能通过这个四元组找到彼此，一条连接就建立了。那么，一台服务器理论上能建立多少条连接呢？

• 从理论上讲，最大连接数应该是 2^32 (IP数) * 2^16 (端口数)，约等于两百多万亿条。
• 但在现实中，受限于硬件（主要是 CPU 和内存），一台服务器不可能达到这个理论值。

假如我们只考虑 ESTABLISH 状态的连接，即连接已建立，但既不收发数据，也不处理业务逻辑。以一台 4GB 内存的服务器为例：

• 在这种情况下，连接数主要取决于内存容量。因为空闲的 ESTABLISH 连接基本不消耗 CPU（保活心跳包的影响微乎其微，可忽略不计）。
• 一条 ESTABLISH 状态的连接大约消耗 3.3KB 的内存。简单计算一下，一台 4GB 内存的服务器，可以容纳 100 万条以上的 TCP 连接。当然，这只是理想化估算。在真实业务场景中，一旦涉及数据收发和处理（数据收发需要申请内存，数据处理则消耗 CPU），内存和 CPU 的开销将急剧上升，并发数自然远达不到百万级别。

归根结底一句话：服务器的开销大头，往往并非连接本身，而是每条连接上的数据收发和业务逻辑处理！ 因此，一台服务器能支撑多少连接，必须结合具体业务场景来分析，脱离业务谈并发，是不切实际的。

三、一台客户端机器最多能发起多少条连接？

客户端每建立一个连接，就会消耗掉一个本地端口。客户端的端口范围是 0 ~ 65535，排除掉许多系统保留端口后，实际可用的可能只有 64,000 个左右。那是不是意味着，一台客户端最多只能向某一台服务器发起 6 万多个连接呢？

根据 TCP 四元组的特性，只要四元组中任意一个元素不同，就是不同的连接。所以，能否打破 65535 的限制，要分情况看：

• 情况一：客户端仅有一个 IP，服务端也只有一个 IP 并仅监听一个端口。此时四元组中唯一可变的只有源端口，其范围是 0 ~ 65535。所以，此种情况下最大连接数是 65535 个。

• 情况二：客户端有多个 IP（假设有 n 个），服务端只有一个 IP 并仅监听一个端口。此时四元组中可变的是源 IP 和 源端口。一个 IP 能建立 65535 个连接，n 个 IP 便能建立 n * 65535 个连接。为公司内部的测试机多分配几个 IP，并非难事。

• 情况三：客户端仅有一个 IP，但服务端启动了多个程序并监听了 m 个不同端口。此时四元组中可变的是目标端口和源端口。源端口范围是 0 ~ 65535，每条连接对应一个不同的目标端口，所以最大连接数量为 65535 * m 个。

其他情况可以依此类推。另外，客户端的可用端口范围受内核参数 net.ipv4.ip_local_port_range 限制，修改该参数即可调整它。所以结论是：不仅服务端能接收 100万+ 的连接，通过合理配置，一台客户端也完全可以发出 100万+ 的连接。

四、深入理解相关技术与内核机制

• 在 TCP 三次握手中，内核 通过 net.core.somaxconn 参数来控制 Socket 的全连接队列长度，默认值通常为 128。当两台机器距离很近但建连并发量极高时，可能导致半连接队列或全连接队列溢出，导致服务端丢弃握手包。客户端超时重传握手包（至少 1 秒后），引起建连耗时过长。调大 net.core.somaxconn 可以增加全连接队列长度，从而缓解丢包问题。

• 有时我们用 Ctrl + C 终止了一个进程，重启时却发现端口仍被占用，这通常是因为操作系统还没来得及回收该端口。稍等片刻再启动应用一般就能解决。

• 客户端程序在与服务端建立连接时，如果不调用 bind 方法指定端口，系统会随机选择一个可用端口。一旦客户端调用了 bind 并传入指定端口，就会强制使用该端口建立连接。这实际上改变了内核选择端口的策略，所以不建议客户端程序主动调用 bind 方法。

  public static void main(String[] args) throws IOException {
      SocketChannel sc = SocketChannel.open();
      // 客户端还可以调用bind方法
      sc.bind(new InetSocketAddress("localhost", 9999));
      sc.connect(new InetSocketAddress("localhost", 8080));
      System.out.println("waiting..........");
  }

• 在 Linux 中，打开一个 Socket 会创建多个内核对象，这自然要消耗内存。出于安全考虑，避免有进程恶意耗尽系统资源，系统才会在多个层面限制可打开的文件描述符数量。

• 内核通过哈希表来管理所有已建立连接的 Socket，以便在收到数据包时，能通过 TCP 四元组快速地查找到对应的内核 Socket 对象。

• 在 epoll 模型中，所有被管理的 Socket 对象都被组织在一棵红黑树中，以此在 Socket 的增、删、查操作上取得高效的平衡。

五、实战：解析几个常见的实际问题

在网络开发与运维工作中，不少人始终对“一台机器最多能支撑多少条 TCP 连接”这个问题认识模糊。由于客户端和服务端对端口的使用模式截然不同，将二者分开讨论会清晰得多。需要注意，“客户端”和“服务端”只是逻辑角色。比如，我们的应用在响应客户端请求时是服务端，但当它向 MySQL 发起请求时，它又变成了客户端。

1. “too many open files” 报错是怎么回事？如何解决？

这是一个常见的线上故障。它的产生原理是：每打开一个文件（包括 Socket）都会消耗内存。为防止单个进程不受限制地打开文件导致系统崩溃，Linux 设置了文件描述符数量的限制。一旦进程触及内核设定的这个天花板，“too many open files” 错误就出现了。

修复方案很明确：通过修改 fs.file-max、soft nofile、fs.nr_open 这三个参数来提升进程可打开的最大文件描述符数。但要再次强调，修改时务必留心它们之间的耦合关系。

2. 一台服务端机器最大究竟能支持多少条连接？

为了探寻最大上限，我们先排除数据收发和处理逻辑，只聚焦于 ESTABLISH 状态的空闲连接。那么，核心结论是：

• 在仅维持空闲连接的情况下，一台服务器可支持的 TCP 最大连接数，基本由内存大小决定。
• 单从四元组的理论组合来计算，数字会大得离谱，没有实际指导意义。文件描述符限制，本质上是内核的自我保护机制，可以通过调整参数来放宽。
• 一个 Socket 大约消耗 3KB 内存，因此，真正构成硬性约束的是内存。对于一台 4GB 内存的服务器，其支持的 TCP 连接数大概在 100 万这个量级。

3. 一台客户端机器最大究竟能支持多少条连接？

客户端每建立一条连接就消耗一个本地端口，端口号是 16 位整数，范围 0~65535。这似乎给客户端连接数判了“死刑”。但我们有两种方式可以绕开这个限制：

• 方式一：为客户端机器配置多个 IP 地址。
• 方式二：让客户端分别连接服务端的不同端口或不同 IP。

所以，客户端同样可以轻松发起百万级连接。

4. 做长连接推送产品，支撑 1 亿用户需要多少台机器？

假设你需要设计一个类似推送服务的系统，在服务端与客户端保持长连接，绝大部分时间连接都是空闲的，每天只推送一两次消息。总用户规模预计达到 1 亿，如何进行服务器资源评估？

• 对于这种产品，给客户端推送数据是低频操作，CPU 开销几乎可以忽略不计。
• 主要还是从内存角度进行估算。假设单台服务器拥有 128GB 内存，大约可以支撑 500 万条并发连接。这 500 万个连接对应的 Socket 大约会消耗掉不到 20GB 内存，剩余的 100GB 以上内存用于处理接收、发送缓冲区以及其他系统开销，绰绰有余。
• 因此，支撑 1 亿用户，仅需 20 台 这样的服务器就基本够用了。