1. 从一道“送命题”说起
做网络开发、运维或者后端服务的同学，几乎都遇到过这样一幕：面试官漫不经心地问一句“TCP/UDP端口的范围为什么是0到65535，总共65536个？为什么不是65535个？”——注意，这里已经有一个很容易混淆的点：端口数量是65536个，但端口号的最大值是65535。标题里说“65535个”，严格讲指的是编号的上限。不过大家平时都这么说习惯了，我下面也会按“端口数量上限65535”的约定俗成来展开，但心里要清楚：编号从0到65535，一共是65536个编号。
为什么偏偏是65535？这要往底层挖，核心就两个字：字段。TCP报文头里有一个“源端口”字段和一个“目的端口”字段，每个字段占16比特。16个二进制位能表示多少种组合？2的16次方，也就是65536种，编号从0到65535。这就是端口的“宿命”来源——不是某个组织拍脑袋定的，而是TCP/IP协议栈在设计报文格式的时候就定死的。
但如果你以为这就是全部答案，那就太小看这个问题了。面试官真正想听的，往往不是“2的16次方”，而是你能不能把协议头结构、链路层MTU、端口复用、系统参数限制、NAT、安全策略这一整条线串起来。这篇文章我不打算只背教科书，而是从底层原理一路讲到实战中跟“端口不够用”“端口被占”“端口扫描”有关的那些坑，尽量让你看完之后，既能应付面试，也能真正解决线上问题。
2. 16比特字段是如何“锁死”端口的
2.1 TCP报文头里的端口字段
先看TCP报文头的标准结构。TCP头部最短20字节，其中前4个字节就是两个端口字段：
- 源端口（Source Port）：16位，标识发送方的应用进程。
- 目的端口（Destination Port）：16位，标识接收方的应用进程。
紧接着是32位的序号（Sequence Number），然后是32位的确认号（Acknowledgment Number），再往后是头部长度、保留位、标志位、窗口大小、校验和、紧急指针等。UDP头更短，只有8字节，但它的源端口和目的端口同样是各16位。这说明“16位端口号”是TCP和UDP共同遵守的约定，是整个传输层设计的基础。
16个比特，每一位都有两种取值（0或1），所以总取值空间是2^16 = 65536。如果端口号从0开始编号，那最大值自然是65535。为什么从0开始？这是计算机世界的通用习惯——数组下标从0开始，二进制计数也是从0开始。如果你硬要从1开始编号，那浪费一个组合不说，还会让“全0”这个特殊值失去意义。实际上，端口号0确实有特殊含义：在客户端主动连接时，如果本地端口指定为0，操作系统会自动分配一个1024到65535之间的临时端口；在服务端监听时，端口0通常意味着让系统挑选空闲端口，这在写测试代码时经常用到。
2.2 为什么不用32位或8位
有人会问：既然IPv4地址都用了32位，为什么端口不用32位？这样端口数量不就海量了？这确实是个好问题。答案要从协议设计的背景和成本来看。
1970年代设计TCP/IP时，内存、带宽、CPU都是极其昂贵的资源。TCP头要尽量精简，每多一个字节，都会增加传输开销和硬件处理的复杂度。端口号的作用是“在一台主机上区分不同的应用进程”，16位（65536个端口）在当时看来已经非常充裕——一台机器能同时跑上万甚至十几万个网络应用进程，在很多时候只是理论可能，因为还要考虑文件描述符数量、内存占用、操作系统的进程表大小。
另外，端口不是一个全局性的标识，它只在“一台主机内部”有意义。两个不同主机的服务端口可以完全一样，比如A机器上的Tomcat监听8080，B机器上的Tomcat也监听8080，互不影响。真正需要全局唯一的是IP地址。既然端口只需要在主机内唯一，那16位的空间是“够用”的，协议设计者没有必要为了一个局部标识去浪费宝贵的报文头空间。
而且从工程角度看，端口字段如果扩展成32位，会破坏整个TCP/IP协议栈的兼容性：所有报文头的解析逻辑、校验和计算、NAT设备的状态表、防火墙规则全都要改。这在今天是灾难性的修改。所以，你去看很多协议演进的历史，凡是加了新功能的，要么新增可选项字段，要么在IPv6里重新来——但即便IPv6，TCP和UDP的端口字段依然倔强地保持16位。这就是“向后兼容”的代价，也是16位端口号能一直延续到今天的原因。
2.3 一次性算清楚：2的16次方与端口号0
很多人记住“65535”就以为端口总数是65535。这是一个高频错误，面试时你如果脱口而出“65535个端口”，面试官会立刻追问：“那0端口呢？”说实话，我自己在早期跟人讨论的时候也经常犯这个错。
正确的算法很简单：
2^16 = 65536
端口编号范围：0 到 65535，总共 65536 个编号。
为什么总觉得是65535？因为很多书和资料都在说“端口范围是0到65535”，大家下意识把最大值当成了数量。其实“最大编号”和“数量”之间差着一个1。这个细节在奇葩场景下会坑到人：如果你写代码遍历所有端口，循环变量习惯性地for (int port = 0; port < 65535; port++)，那你就会漏掉65535这个真实存在的端口。正确写法应该是for (int port = 0; port <= 65535; port++)或者port < 65536。
另外，虽然编号有65536个，但真正能自由使用的端口并没有这么多。IANA（互联网号码分配局）把端口分为三类：
- 公认端口（Well-Known Ports）：0~1023，也叫特权端口。这些端口通常绑定系统级服务，比如HTTP的80、HTTPS的443、SSH的22、FTP的21。在类Unix系统上，普通用户绑定1024以下的端口通常需要root权限。
- 注册端口（Registered Ports）：1024~49151，用于用户态应用，比如MySQL的3306、Tomcat的8080、Redis的6379。
- 动态/私有端口（Dynamic/Private Ports）：49152~65535，一般是客户端发起连接时由操作系统临时分配的“临时端口”（Ephemeral Ports）。
所以，真正给普通应用随便用的“宽松区”主要集中在1024到49151，而客户端临时端口往往从49152以上的区间分配。这也就埋下了“端口不够用”的隐患——如果一台机器上有大量出站连接，临时端口池会被快速消耗。
3. 从物理链路到系统调用：65535的层层“投影”
端口数量的上限是协议层定的，但在实际操作中，你能同时使用的端口数量往往远小于65535。因为还有一堆因素在跟着掺和，我把它们从底到上捋一遍，你就会知道为什么“理论值”和“实际值”差了那么多。
3.1 四元组决定连接，端口只是其中一个维度
先搞清楚一个关键概念：一个TCP连接，不是由“端口”单独标识的，而是由四元组唯一确定：
（源IP，源端口，目的IP，目的端口）
这意味着什么？意味着同一台服务器上的同一个端口，理论上可以同时接收来自成千上万个客户端的连接。举个例子：你启动一个Nginx监听80端口，Nginx进程里的多线程/多进程可以同时处理很多客户端连接，每个连接的源IP和源端口各不相同，所以即使目的端口都是80，它们依然是不同的连接。
这也说明一个问题：服务端监听一个端口，不代表只能有一个并发连接。真正的并发上限，受制于操作系统的文件描述符限制（ulimit -n）、内存大小（每个socket要占用内核缓冲区）、CPU处理能力等。所以，“端口数量65535”对于服务端来说，从来不是并发上限的瓶颈。对于客户端来说就不一样了，客户端要发起出站连接，需要自己占一个本地端口，如果出站连接非常多，本地临时端口不够用，就会看到Cannot assign requested address之类的报错。
3.2 出站连接把“65535”打回原形
假设一台内网机器要访问外部的很多服务，比如爬虫服务器、监控采集端、消息队列消费者，它每建立一条出站连接，内核就要给它分配一个本地端口（ephemeral port）。如果该机器对外访问的“目的IP + 目的端口”组合比较集中，那么能够用的连接数就会受到本地端口数的限制。
很多人会有疑问：既然四元组里源端口只是其中一个维度，就算本地端口只有一起去，难道不能用不同的目的端口去扩展吗？理论上可以，但现实中，你的业务往往是访问同一个服务的同一个端口（比如都去访问目标Redis的6379），这时候本地端口数就变成了硬约束。
Linux系统里，临时端口范围由net.ipv4.ip_local_port_range控制，默认通常是32768 60999，也就是只有大约28000多个可用临时端口。这个数字远小于65535。如果你的服务需要维护超过这个数量的出站连接，就必须调大这个范围，或者是让多个目标IP/端口分担压力。我之前调过一台高并发采集服务器的参数，把临时端口范围改成了1024 65535，才勉强缓解了 TIME_WAIT 堆积和端口耗尽的问题。
3.3 NAT对端口数量的“放大”和“限制”
再聊一个跟端口数量强相关但也常被误解的场景：NAT（网络地址转换），尤其是家用路由器或者云环境里常用的SNAT/NAPT。
在内网里，很多设备只有私有IP，比如192.168.x.x。它们访问外网的时候，NAT设备会把内网IP+内网端口转换成一个公网IP+公网端口。NAT设备会维护一张映射表，记录“内网IP:端口 -> 公网IP:端口”。所有内网设备共享一个公网IP，那么可用的公网端口最多也就是65536个。如果内网同时发起的外出连接太多，NAT设备上的公网端口都不够用，新连接就会失败。
这就更凸显了16位端口号在现代网络里的“瓶颈感”。解决办法往大了说就是多公网IP、升级IPv6；往小了说就是合理配置NAT的端口复用策略、缩短TCP连接空闲超时等。所以在面试或者做网络规划的时候，不能只盯着单机端口数，要把NAT这一层也算进去。
3.4 为什么65535端口经常和“最高隐私”绑定
网上经常有“关闭65535端口防入侵”之类的说法，其实多半是江湖谣言。端口号本身没有善恶之分，任何端口都可以被恶意软件利用。只不过因为65535是最后一个端口，一些扫描器在扫描时可能以它作为参照点，或者有些木马为了避免撞上常见端口的默认策略，故意选择高编号端口来隐藏通信。但从技术上说，扫描器扫的是整个IP段的端口范围，从1到65535都会看，不会因为端口号大就视而不见。
这也提醒我们，判断端口是否危险，主要看“哪个进程在监听、监听在0.0.0.0还是127.0.0.1、有没有防火墙规则保护”。比如之前因为SMB漏洞导致勒索病毒爆发的445端口，本身是一个合法的Windows文件共享端口，但它在公网暴露就非常危险。所以，与其纠结某个端口是不是“高危端口”，不如养成“最小暴露面”的习惯：非必要端口不对外监听，防火墙默认拒绝访问，需要开放时再做严格的源IP白名单。
4. 底层实现里藏着更多细节
4.1 系统如何维护端口与进程的关系
知道了端口号的范围，再来看看操作系统是怎么管理和记录端口的。Linux内核里，所有端口的使用情况都集中在内核的socket哈希表中。每一套网络连接（socket）在内核里都有一个唯一的四元组标识，其中端口是重要的key。当一个socket通过bind()绑定本地端口、通过listen()/connect()建立连接时，内核会把这个四元组插入哈希表；连接关闭时再从中移除。
如果你做一个网络端口扫描，比如用nmap对目标IP做全端口扫描，扫的就是这个目标IP上的端口有没有进程在监听，并根据TCP握手行为做状态判断。nmap扫描的核心原理其实也不神秘：
- TCP Connect扫描：主动和目标端口完成三次握手，如果握手成功说明端口开放。
- SYN半开扫描：发SYN包，收到SYN+ACK则说明端口开放，再回RST断开，不建立完整连接。
- UDP扫描：发UDP包，若无响应且无ICMP端口不可达，则判断端口可能是开放的（UDP无连接，判断比较暧昧）。
正因为端口范围上限是65535，nmap这类工具才能做到“全端口扫描”，如果端口范围是2^32，那全量扫描的耗时会极其恐怖。这也算是16位端口号对安全测试领域的影响——我们能在可接受的时间内完成对一台主机所有端口的检查。
4.2 TIME_WAIT、端口复用与65535的相爱相杀
再深入一点，所有网络开发人员都绕不过一个“TIME_WAIT”。主动关闭连接的一方，在发送完最后一个ACK后，会进入TIME_WAIT状态，默认要等待2个MSL（最长报文段寿命），在Linux里通常为60秒。TIME_WAIT期间，对应的四元组不能立即被重用。
上节提到，客户端出站连接的本地端口是临时分配的，如果客户端频繁地短连接访问同一个目标端口，每次连接都会有一个四元组在TIME_WAIT里滞留60秒。当你每秒建立几百个连接，60秒后会累积上万条TIME_WAIT记录，本地临时端口就会被耗尽，然后抛出“Cannot assign requested address”。
解决办法不只是调大ip_local_port_range，更常用的是开起tcp_tw_reuse：
sysctl -w net.ipv4.tcp_tw_reuse=1 sysctl -w net.ipv4.tcp_timestamps=1tcp_tw_reuse允许内核在满足条件时（基于TCP时间戳）复用TIME_WAIT状态的连接，让新连接直接使用旧的临时端口。这个选项对客户端出站连接有效，服务端一般不建议依赖它，而应该通过长连接、连接池来降低建连频率。类似的问题在HTTP/1.1里的Keep-Alive、在数据库连接池里也都有体现——无脑调整端口范围只能延缓问题，真正健康的做法是减小连接的新建/关闭频率。
所以你会发现：虽然端口号理论上有65536个，但在高并发出站场景里，实际可用量大概就是ip_local_port_range那两万多个；再叠加TIME_WAIT，可能连几千个并发都撑不住。这就解释了为什么很多中间件会有“连接池”这种设计，本质上不是为了省网络带宽，而是为了省临时端口和系统资源。
4.3 服务端监听“端口0”的特殊玩法
在开发中用端口0来获取空闲端口是个非常实用的小技巧，特别适合测试场景。比如你写一个单元测试，想临时启动一个HTTP服务，又不想关心哪个端口被占，就可以把监听端口设为0，然后从socket对象里读出实际分配的端口。
import socket sock = socket.socket() sock.bind(('0.0.0.0', 0)) # 端口0 = 系统自动分配 port = sock.getsockname()[1] print('分配到的端口:', port)# 用nc试一下，也可以看到自动分配的效果 nc -l 0 & # 然后查看监听状态 ss -tlnp | grep nc这背后的逻辑就是：当bind端口为0时，内核从临时端口范围内找一个空闲端口分配给这个socket。利用这个特性，测试框架里可以不用硬编码端口，避免并行跑测试时端口冲突。生产环境一般不会绑0端口，因为那样外部客户端无法提前知道端口号，但对于某些内部自动注册机制（比如服务启动后上报端口给注册中心）来说，“绑0拿到实际端口再上报”也是个可行的思路。
5. 从“端口被占”到“配置交换机端口安全”：实战避坑指南
5.1 端口被占用系列问题的排查套路
日常定位问题时，最常用的就是 “端口被占” 这一类。Windows 和 Linux 下我都试过比较顺手的方式，整理成一套标准操作流程：
Linux下：
# 查看某个端口是否被监听 ss -lntp | grep 8080 # 查看所有监听端口 ss -lntp # 查看某个端口的详细连接状态 netstat -antp | grep 8080 # 找出占用进程并杀掉 lsof -i :8080Windows下：
netstat -ano | findstr 8080 tasklist | findstr <PID> taskkill /PID <PID> /F“端口被占” 有时候不是真有一个进程在监听，而是出现了端口范围冲突。比如你启动服务时发现端口起不来，但ss -tlnp里看不到监听，这时候要检查是不是有进程处于 TIME_WAIT 状态，尤其是大量短连接的情况下。TIME_WAIT 的连接可能在ss -ant里能看到，它们不会阻止bind()一个监听端口，但会因为四元组冲突影响出站连接。
再有一种情况在云环境里很常见：安全组规则没放行，但从服务器本机测试是通的，这叫 “端口通、防火墙堵”。所以排查时必须区分“本机连通性”和“外部连通性”。本机测试用curl 127.0.0.1:8080，外部测试用telnet <服务器公网IP> 8080，如果本机通、外部不通，十有八九是安全组或者云防火墙的问题。
5.2 telnet、nmap、nc：验证端口通不通的工具选择
很多老手都知道，测试一个远程IP的端口通不通，最简单的是telnet ip port：
telnet 192.168.1.100 3306如果端口开放，终端会显示连接成功，甚至直接进入类似空白的交互界面；如果端口不通，会一直卡住直到超时，或者直接提示Connection refused。Connection refused其实意味着目标IP可达，但目标端口没有进程监听；而超时则说明包被丢掉，可能是防火墙拦截，也可能是目标IP不可达。
telnet 虽然方便，但在有些最小化安装的系统里没有。替代方案很多：
nc -zv <ip> <port>：-z表示只扫描不发送数据，-v显示详细信息。nmap -p <port> <ip>：功能更强大，支持端口状态的多类判断。/dev/tcp方案：bash内置的虚拟设备，不用装任何东西：
timeout 3 bash -c 'echo >/dev/tcp/192.168.1.100/3306' && echo "open" || echo "closed"这个命令的本质就是让bash尝试建立一个TCP连接，成功就返回0，失败返回非0。我在排查某些精简容器镜像里的网络连通性时，这个方法非常管用，因为容器里可能连telnet和nc都没有。
5.3 修改端口时的安全策略：以3389、445为例
聊到端口，经常会有人问“怎么修改Windows远程桌面3389端口”“怎么关闭445端口”。修改3389端口的方法是修改注册表项HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber，把它从默认的3389改成其他端口，然后重启服务。注意：Windows防火墙要放行新端口，否则改了也是白改。
至于445端口，它是SMB服务使用的端口。如果是个人电脑，确实不建议对外网暴露445端口。最简单的做法是入站规则里显式阻止445端口的入站连接，而不是把整个SMB服务禁用——因为在局域网共享文件时你可能还需要它。操作路径是：Windows防火墙 -> 高级设置 -> 入站规则 -> 新建规则 -> 端口 -> TCP 445 -> 阻止连接。这样既不影响局域网内正常访问（如果你同时允许内网IP段访问的话），又防止公网的人扫描到SMB端口。
这里要强调一下：关闭端口不是目的，是手段。真正的目的永远是“哪些服务该暴露，哪些不该暴露”，以及对暴露的服务做好访问控制和监控。很多安全事件不是因为端口开得多，而是因为某个端口上的服务存在漏洞又不设防。
5.4 华为交换机端口安全配置：从“网络端口”到“硬件端口”
还有一个容易混淆的话题：交换机的“端口”和TCP/UDP的“端口”完全是两码事。交换机端口是物理硬件上的接口，比如华为交换机上的 GE0/0/1、10GE1/0/1 等。配置端口安全的意思是限制接入这个接口的设备MAC地址，防止有人随便接一台设备就进入内网。
华为交换机的基本配置思路是这样的：
interface GigabitEthernet0/0/1 port-security enable port-security max-mac-num 1 port-security mac-address sticky port-security protect-action restrict这段配置的意思是：在GE0/0/1接口上启用端口安全，最多只允许学习1个MAC地址，并且把动态学习到的MAC地址sticky（粘住），也就是之后这个接口只认这台设备。如果超出了最大MAC数，按restrict动作处理——丢弃非法报文并产生告警，或者也可以配置成shutdown直接把端口关闭。
这类配置常用于接入层交换机，配合园区网的准入控制，可以有效防止私接路由器和终端仿冒。虽然它跟“TCP端口数65535”没什么直接关系，但既然热词里出现了，我还是提一句，免得做数通的朋友觉得这一篇只聊协议端口，没聊他们熟悉的东西。
6. 端口范围对应用架构的连锁影响
6.1 数据库、缓存等中间件的端口选型
在生产架构中，端口选型看似小事，却能影响安全策略和排障效率。我见过不少团队默认用3306跑MySQL、5379跑Redis，然后整个办公网都能直接访问，出事了才想起来加白名单。合理的端口规划应该遵循几个原则：
- 区分“内部管理端口”和“外部业务端口”。
- 内部组件（数据库、缓存、消息队列、注册中心）集群之间访问，应通过内网网段和防火墙白名单加以限制，不要把端口裸奔到公网。
- 尽可能避免使用大家都知道的默认端口，或者至少在使用默认端口的时候，用防火墙规则把来源IP限制死。改端口只能防扫描器，不能防真正的攻击者，但能降低被自动化脚本批量扫描的概率。
- 对于注册中心、配置中心这类组件，nacos、eureka、zookeeper 都有默认端口。多实例部署时，要特别小心端口冲突，比如nacos 2.x 默认8848，同时还会占用9848（gRPC端口）和9849。升级到新版本时，这些额外的偏移端口如果不注意，很容易漏放防火墙或者被其他进程占用。
6.2 短连接与长连接：端口耗尽的两种解法
短连接场景下，客户端频繁建立新连接，临时端口很容易被TIME_WAIT拖垮。我优化过一套采集服务，原本每秒向目标服务发起几百个HTTP请求，每个请求都新建连接，结果跑十几分钟就报Cannot assign requested address。当时我做了三件事：
一是启用连接池，让底层的HTTP客户端复用连接，把每秒新建连接数降了一个数量级；
二是开启了tcp_tw_reuse，让TIME_WAIT的端口可以被快速复用；
三是把ip_local_port_range从默认的32768 60999调整为1024 65535，多扩了一倍的临时端口池。
改完之后，同样的并发量下，端口占用率从99%降到了30%左右，整个过程没有动一行业务代码，只是调整了网络开销的模式和内核参数。这就是理解端口底层原理之后的收益——你知道瓶颈在哪，就知道该从哪里下手。
6.3 端口与安全策略的“最小暴露面”
最后聊一下安全策略。基于IP和端口的安全策略是防火墙、安全组、网络ACL最核心的配置模型。设计规则时，我通常按“正向放行、默认拒绝”的方式：
- 对于面向公网的入口，只放行需要的业务端口（如80/443），其他端口都拒绝。
- 对于内网之间的访问，按“哪台机器访问哪台机器的哪个端口”来细化，避免大段IP互通的粗放规则。
- 监控和运维类的端口（如SSH、监控agent端口）单独限制源IP，最好是跳板机的IP，不要直接对所有网段开放。
这些规则都是围绕“端口”这个维度在操作。理解了端口有65535这个边界，你就能理解为什么安全组里可以枚举规则，为什么一个公网IP上不能同时给几十万个用户映射不同的服务端口——资源是有限的，设计时要提前规划。
7. 再深挖一层：为什么NAT环境里端口经常不够用
NAT是另一个能把65535“放大”或者“制约”的地方。家用宽带里，一台路由器把几十台设备的内网IP映射到一个公网IP上。当多个设备同时访问外网时，路由器需要为每一条会话分配一个公网端口。如果公网IP只有一个，那么理论上最多同时存在65535条NAT映射（不考虑端口复用策略的话）。看起来很多，但现代智能设备联网数量惊人：手机、平板、笔记本、电视、智能音箱、摄像头、家电，每个设备里又有多个应用在跑，几百上千条会话很常见。遇到BT下载、直播、多路视频流这类的应用，单个连接占用的端口和资源更多，NAT表很容易被塞满。
缓解手段通常有几种：
- 开启NAT的端口复用，让同一端口可被多个内网IP的不同连接复用，只要四元组不一样就行。
- 减少不必要的后台联网，比如让部分智能设备离线控制。
- 升级到光猫/路由器支持公网IPv6，用IPv6的海量地址空间绕开NAT限制。
这也让我想到：生活中大多数用户并没有直接触碰到“65535个端口”这个概念，但他们会真切地感受到“网不好使、打不开网页、游戏掉线”，底层原因很可能就是NAT端口表耗尽。端口这个东西，站在用户侧看不见摸不着，但站在技术侧，它是整个网络治理无法回避的基础单元。
8. 个人经验总结与留下的几个思考
做了这么多年网络和应用架构，我越发觉得“端口数量65535”这个问题像是一个隐喻：它看起来是一个简单的数学题，但背后是协议设计的历史、操作系统资源管理的艺术、网络安全攻防的博弈，以及现代分布式架构在扩展性上的挣扎。
我个人在排查网络问题时，最常挂嘴边的习惯是：先分清楚“是哪一层不通”——链路层通不通、IP层通不通、TCP端口通不通、服务进程是否在监听。这一套顺序捋下来，基本能消灭80%的疑难杂症。而这一切的起点，都要回到那句朴素的话：端口号就是16个比特，2的16次方就是65536，编号到65535为止。记住这个，再去看内核参数、去看防火墙规则、去看NAT映射表，很多配置参数就不再是需要死记硬背的表格，而是有逻辑推导依据的自然结果。
如果你现在写网络程序，可以顺手做一个小实验：在自己的Linux机器上执行ss -s，看看当前系统的socket总数和TCP连接数，再对比一下临时端口范围的默认值，你会很直观地感受到“65535这个数字到底是被谁限制的”。再进一步，用nmap扫一下本机回环地址的1到65535端口，看看你能发现哪些意料之外的监听进程——但注意，别拿公网IP乱扫，这是法律和道德都不允许的行为。
最后再留一个开放问题给你思考：如果当初TCP手册把端口字段定为32位，今天我们的网络世界会有什么不同？你会怎么设计一个向后兼容的扩展方案？这些问题没有标准答案，但想明白它们，你对“65535”这个数字的理解，就真的不只是“2的16次方减1”了。
