1、端口冲突的本质：什么是端口、TCP/UDP端口号范围、端口冲突的底层原理
各位好，我是老张。做网络排障这么多年，我见过最坑的故障之一就是端口冲突。明明服务配好了，就是起不来，查半天发现是端口被占了。今天咱们就把端口这事儿彻底聊透。
1.1 端口到底是什么？
先问个问题：一台服务器上跑着Web服务、数据库、邮件服务，数据包到了服务器网卡，系统怎么知道该交给谁？
答案就是端口。端口是一个16位的数字，范围从0到65535。它就像大楼里的房间号——IP地址是楼栋地址，端口就是具体的门牌号。
核心概念：端口是传输层（TCP/UDP）用来区分不同应用程序的逻辑标识。它不是物理接口，是操作系统内核里的一张表。
我习惯把端口理解成「进程的通信入口」。一个进程可以绑定多个端口，但一个端口在同一时刻只能被一个进程独占（除非用了SO_REUSEADDR这类特殊选项）。
1.2 TCP/UDP端口号范围
端口号分三段，这个分类是IANA定的，但实际用起来有讲究。
| 分类 | 范围 | 典型用途 | 我踩过的坑 |
|---|---|---|---|
| 知名端口 | 0 - 1023 | HTTP(80)、HTTPS(443)、SSH(22) | 有人把Web服务绑在1024以下端口，忘了用root权限启动，服务一直起不来 |
| 注册端口 | 1024 - 49151 | MySQL(3306)、Redis(6379)、Docker(2375) | 两个中间件抢同一个端口，我排查了半小时才发现配置冲突 |
| 动态/私有端口 | 49152 - 65535 | 客户端临时端口、NAT转换端口 | 防火墙只开了前1024个端口，结果应用用了50000+端口，业务全被拦截 |
嗯，这里要注意：0号端口是保留的，不能用。1024以下的端口需要root权限才能绑定，这是Linux的安全机制。
1.3 端口冲突的底层原理
说白了，端口冲突就是两个进程想同时占用同一个端口号。但底层到底发生了什么？我画张图给你看。
你看这张图就清楚了。进程A先绑定了端口80，内核就在端口表里记了一笔。进程B也想绑80，内核一查表——有人占了，直接返回EADDRINUSE错误。进程B的bind()调用就失败了。
为什么会这样？因为端口是独占资源。你想想看，如果两个Web服务都监听80端口，数据包来了该给谁？系统没法判断，所以干脆不让绑。
1.4 端口冲突的几种常见场景
我在项目中遇到过不少奇葩情况，总结下来就这几类：
- 服务重复启动：Nginx挂了自动重启，旧进程还没完全退出，新进程就抢端口。我见过有人写脚本没加PID检查，结果起了20个Nginx进程全卡在端口上。
- 配置冲突：两个服务配了同一个端口。比如MySQL默认3306，但有人把Redis也配成了3306。
- TIME_WAIT残留：进程退出了，但端口还在TIME_WAIT状态。默认要等2分钟才能释放。我曾经在压测时频繁重启服务，每次都报端口被占用。
- Docker端口映射冲突：宿主机端口被多个容器映射。比如两个容器都把80映射到宿主机8080，第二个就起不来。
避坑指南：我曾经在生产环境遇到过一个问题——服务A正常跑着，服务B启动时报端口被占用。查了半天发现，服务A的进程其实已经挂了，但端口因为TIME_WAIT状态没释放。解决方案是等2分钟，或者用netstat -tulpn | grep 端口号确认状态。如果实在着急，可以调整/proc/sys/net/ipv4/tcp_fin_timeout缩短等待时间，但别设太短，会影响数据可靠性。
1.5 端口冲突与TCP/UDP的区别
TCP和UDP的端口空间是独立的。什么意思？就是TCP 80和UDP 80可以同时被不同进程占用，互不干扰。
| 特性 | TCP端口 | UDP端口 |
|---|---|---|
| 连接状态 | 有状态（ESTABLISHED, TIME_WAIT等） | 无状态 |
| 端口释放 | 需要等2MSL（TIME_WAIT） | 进程退出立即释放 |
| 冲突检测 | bind()时检查，严格 | bind()时检查，但可复用 |
| 典型场景 | HTTP、SSH、MySQL | DNS、DHCP、视频流 |
嗯，这里有个细节：UDP虽然无状态，但bind()时同样会检查端口是否被占用。只不过UDP没有TIME_WAIT，进程退出后端口立刻可用。
1.6 怎么快速判断端口被谁占了？
我个人的三板斧：
# 第一板斧：看谁在监听
netstat -tulpn | grep :80
# 第二板斧：看具体进程
lsof -i :80
# 第三板斧：用ss（更快，推荐）
ss -tulpn | grep :80输出里能看到PID和进程名。如果PID是「-」，说明是内核线程或者权限不够，加sudo再试。
小技巧：我习惯用ss -tulpn代替netstat，因为ss直接从内核读取socket信息，速度比netstat快一个数量级。尤其在服务器上有几千个连接时，差距特别明显。
1.7 端口冲突的底层数据结构
最后聊点深层的。内核怎么管理端口？其实就一张哈希表。
每个socket在bind()时，内核会计算端口号的哈希值，插入到哈希表的对应桶里。冲突时遍历桶里的链表，检查有没有相同的五元组。如果有，返回EADDRINUSE。
你想想看，如果端口号是65536个，哈希表桶数一般是1024或2048。平均每个桶挂64个或32个条目。查找效率是O(1)到O(n/桶数)，基本不影响性能。
但有一种情况会出问题——大量短连接。每个连接都占用一个临时端口（49152-65535），如果短时间内建立几万个连接，端口池可能耗尽。这时候新连接会报错：Cannot assign requested address。这不是端口冲突，是端口枯竭，但表现很像。
好了，端口的基础就聊到这儿。记住一句话：端口是进程的通信入口，冲突就是两个进程抢同一个入口。后面咱们用Wireshark抓包，看看端口冲突在网络上到底长什么样。