2. TCP端口复用场景：高并发Web服务器、微服务网关、负载均衡器中的端口复用实践

端口复用这个词，听起来好像就是把一个端口重复用几次。但实际落地的时候，坑比想象中多得多。我最早接触这个场景，是在一次线上Web服务器的性能调优中——当时Nginx的worker进程数一上去，端口冲突的问题就冒出来了。

说白了，TCP端口复用就是让多个socket绑定到同一个IP和端口上。内核在收到数据包时，会根据一些规则决定交给谁处理。这个机制在高并发架构里几乎是标配，但用不好，就是灾难。

2.1 高并发Web服务器中的端口复用

先说说最常见的场景：Web服务器。不管是Nginx、Apache还是Caddy，它们都面临一个问题——怎么处理成千上万的并发连接？

我个人的习惯是，先搞清楚Web服务器的进程模型。以Nginx为例，它采用master-worker多进程架构。每个worker进程都会监听同一个端口（比如80或443）。这里的关键就是SO_REUSEADDR和SO_REUSEPORT这两个socket选项。

我记得有一次，一个同事在配置Nginx时，忘了在listen指令里加reuseport参数。结果呢？worker进程一多，新连接全卡在了一个进程上，CPU利用率严重不均。你想想看，明明有8个核，结果只有一个在干活，其他7个闲着——这谁受得了？

# Nginx配置示例：启用SO_REUSEPORT
http {
    server {
        listen 80 reuseport;
        listen [::]:80 reuseport;
        # 其他配置...
    }
}

2.2 微服务网关中的端口复用实践

微服务网关是另一个端口复用的重灾区。像Kong、APISIX、Envoy这些网关，通常要处理来自多个上游服务的流量。它们怎么做到一个端口接所有请求？

说白了，就是靠SO_REUSEPORT配合多worker进程。但这里有个坑——网关的worker进程数怎么设？

我曾经在一个项目里，把Envoy的worker数设成了和CPU核数一样。结果呢？高并发下，连接建立失败率飙升。排查了半天，发现是SO_REUSEPORT在内核层面做连接分发时，哈希冲突太严重了。

微服务网关还有一个特殊场景——TLS终止。当网关同时处理HTTPS和HTTP流量时，端口复用就更复杂了。我一般建议的做法是：

• 443端口只做TLS终止，内部转发到80端口的HTTP服务
• 或者用SNI（Server Name Indication）做多域名复用
• 避免在同一个端口上混用TLS和明文协议

# Envoy配置示例：端口复用 + TLS终止
static_resources:
  listeners:
  - name: listener_https
    address:
      socket_address: { address: 0.0.0.0, port_value: 443 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        config:
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: service_backend }
      transport_socket:
        name: envoy.transport_sockets.tls
        config:
          common_tls_context:
            tls_certificates:
            - certificate_chain: { filename: "/etc/certs/server.crt" }
              private_key: { filename: "/etc/certs/server.key" }

2.3 负载均衡器中的端口复用

负载均衡器是端口复用最极致的场景。不管是硬件F5还是软件LVS、HAProxy，它们都要在同一个端口上接收海量流量，然后分发到后端。

这里我要重点说一下LVS的FullNAT模式。它用了两个层面的端口复用：

1. 前端监听：LVS的Director在VIP上监听，用SO_REUSEPORT让多个worker进程共享端口
2. 后端转发：Director和后端RS之间建立连接时，复用源端口

为什么会这样设计？因为LVS要处理的是几十万甚至上百万的并发连接。如果每个连接都用不同的源端口，端口号很快就用完了。所以它必须复用端口——同一个源IP+源端口，可以对应多个不同的后端连接。

# 负载均衡器端口复用相关内核参数优化
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.core.somaxconn = 65535

HAProxy的端口复用策略又不一样。它默认使用SO_REUSEADDR，但如果你想让多个HAProxy实例绑定同一个端口，就得用SO_REUSEPORT。我记得有一次做HAProxy热升级，就是因为没开SO_REUSEPORT，新进程启动时端口被占用，导致服务中断了几秒钟。

2.4 三种场景的对比总结

我把这三种场景的核心差异整理成了表格，方便你对照参考：

场景	复用类型	核心参数	常见坑
高并发Web服务器	SO_REUSEPORT	listen reuseport	worker数过多导致哈希冲突
微服务网关	SO_REUSEPORT + TLS	worker数 ≤ CPU核数×1.5	TLS和明文混用端口
负载均衡器	SO_REUSEADDR + 源端口复用	ip_local_port_range, tcp_tw_reuse	端口范围太小导致分配失败

2.5 端口复用核心逻辑图

下面这张图展示了三种场景下端口复用的核心流程和关键决策点：

嗯，这张图把三种场景的端口复用路径画清楚了。从内核分发开始，到不同中间件的处理方式，再到各自的关键参数和避坑点。你部署的时候，对着这张图走一遍，基本不会漏掉什么。