1. 端口复用初探：什么是端口复用？为什么需要端口复用？

各位同学好，我是老赵。今天咱们开始聊端口复用——这个在网络编程里既基础又容易被忽视的话题。

先问大家一个问题：你在一台服务器上启动了两个 Web 服务，都监听 80 端口，会发生什么？

答案很简单：第二个服务会报错，说端口已被占用。这就是端口的基本特性——一个端口在同一时刻只能被一个 socket 绑定。

但现实世界哪有这么理想？我当年在维护一个电商平台时，单台机器上跑了 Nginx、Tomcat、还有几个内部监控服务。如果每个服务都得独占一个端口，那端口号很快就用光了。更麻烦的是，防火墙策略、域名备案、客户端配置全都要跟着改——想想就头大。

端口复用，说白了就是打破「一个端口一个服务」的限制。它让多个 socket 可以共享同一个端口号，内核在收到数据包时，根据 IP 地址、协议类型等条件，把数据分发给正确的 socket。

端口复用的核心定义：允许多个 socket 绑定到同一个 IP 地址和端口号，由内核负责数据分发。

我总结下来，主要有三个驱动力：

端口资源有限——TCP/UDP 端口号只有 65535 个，其中 0-1023 还是特权端口。大型系统动辄几十个服务，不用复用根本不够分。
运维复杂度降低——统一用 80/443 端口，防火墙规则、负载均衡配置、域名绑定都简单得多。你想想看，如果每个微服务都用一个独立端口，光写 iptables 规则就能写到手抽筋。
高可用和热迁移——在 Kubernetes 或容器环境下，同一个 Pod 里的多个容器经常需要共享端口。没有复用机制，容器编排根本玩不转。

我的经验：曾经有个项目，因为端口规划不合理，导致线上扩容时新节点无法注册到服务发现中心。排查了半天，发现是端口冲突。从那以后，我习惯在项目初期就画好端口复用规划图。

光说理论没意思，咱们看两个最常见的场景。

典型的架构是这样的：

客户端 → Nginx（80端口）→ Tomcat1（8080）
                         → Tomcat2（8080）
                         → Tomcat3（8080）

这里 Nginx 监听 80 端口，三个 Tomcat 实例都监听 8080 端口。等等，三个 Tomcat 都绑 8080 不会冲突吗？

嗯，这里有个关键点：端口复用通常需要配合地址复用（SO_REUSEADDR）。Tomcat 实例如果绑定在不同的 IP 上（比如 127.0.0.1:8080 和 192.168.1.10:8080），或者使用不同的协议（TCP vs UDP），就可以共存。

我见过一个极端案例：某公司一台物理机上跑了 12 个 Nginx 实例，全部监听 80 端口，靠不同的虚拟 IP 区分。这就是端口复用的威力。

数据库连接池是另一个典型场景。应用服务器和数据库之间会建立大量长连接，如果每个连接都独占一个端口，那连接数稍微一多端口就不够用了。

连接池的做法是：多个客户端连接复用同一个数据库端口。比如 MySQL 默认端口 3306，应用服务器上的 100 个连接都连到 3306，但每个连接的源端口不同。内核根据「源 IP + 源端口 + 目标 IP + 目标端口」四元组来区分这些连接。

注意：连接池的端口复用和 socket 层面的端口复用不是一回事。连接池是应用层的复用，而 socket 层面的 SO_REUSEADDR/SO_REUSEPORT 是内核机制。两者经常配合使用，但概念上要分清。

下面这张图能帮你理清端口复用的整体脉络：

聊到具体实现，Linux 下主要有两个 socket 选项：

选项	作用	典型场景
`SO_REUSEADDR`	允许重用处于 TIME_WAIT 状态的端口，也允许多个 socket 绑定到不同 IP 的同一端口	服务器重启、虚拟主机
`SO_REUSEPORT`	允许多个 socket 绑定到完全相同的 IP+端口，内核做负载均衡	多进程/多线程服务器、Nginx 多 worker

避坑指南：我曾经在调试一个高并发服务时，发现新启动的进程总是绑定端口失败。查了半天，原来是上一个进程退出后 socket 还处于 TIME_WAIT 状态。加上 SO_REUSEADDR 后问题立刻解决。嗯，这个坑我踩过，你们就别再踩了。

端口复用不是什么高深技术，但它贯穿了整个网络编程体系。从单机多服务部署，到分布式系统的高可用设计，都离不开它。

这一章咱们先建立整体认知。后面我会带大家深入 SO_REUSEADDR 和 SO_REUSEPORT 的源码实现，手把手教你如何在项目中正确使用端口复用。