私信太多无法一一回复，请各位见谅。这个问题特别有讨论的价值，分享给有兴趣的同学。当计算机接收到报文时，需要将这个报文递交(Deliver)给某个特定的进程。计算机操作系统管理进程的方法，和公安系统管理人口很类似。为了唯一地识别一个公民，每个公民都有一个独一无二的身份证号，比如31010xxxxxxxxxxx，每个号码都是唯一的，这个身份证号就是人口管理系统的主键(Master Key)。只要把任意一个合法的身份证号输入查询系统，返回值一定是一个，而不能是多个。如果有多个返回值，那么这个系统估计是假的！操作系统，也给每个进程分配一个独一无二的进程号(Process ID)，其中包括操作系统自身的系统进程，以及由用户执行的用户进程。如果报文里携带进程号，操作系统(TCP/IP协议栈)只要把报文转交给该进程号对应的进程就可以了。但是遗憾的是，报文里无论是以太帧头、IP头、TCP头、以及应用层并没有携带进程号，那么操作系统如何能将报文准确无误地转交给真正的接收进程？这难不住机智而聪明的操作系统设计大师，大师给每个进程提前喊话：各位老少爷们，如果各位想与外界通信，必须使用Bind(address，port)函数，将自己的进程号与本地的IP地址、端口号绑定起来。否则，后果自负！ 注释：上文的外界，可以是同一台计算机上的其它进程，也可以是互联网上的任何计算机上的进程。小弟(进程)听到老大(操作系统)发话，个个严格遵守规则。有一个进程A是这么做的：Bind (‘1.1.1.1’, 50007)，这个系统调用消息携带该进程的进程号ID= 165364，发给了操作系统TCP/IP协议栈。操作系统懒洋洋地拿出一个本子记录一下：(1.1.1.1，50007)--------165364注释：1.1.1.1 是IP地址，50007是端口号稍后当操作系统TCP/IP协议栈接收到一个IP报文，通过提取目的IP地址(位于IP头)、目的端口号(位于TCP头)，这两者的组合恰好为(1.1.1.1，50007)。操作系统查询一下小本子，立马就得知这是进程号= 165364进程A的，然后通知该进程A前来将报文取走。进程B也想如法炮制：Bind (‘1.1.1.1’, 50007)，很遗憾，操作系统拒绝了。拒绝的消息如下：“builtins.OSError: [WinError 10048] 通常每个套接字地址(协议/网络地址/端口)只允许使用一次。”意味着(1.1.1.1， 50007)这个组合能唯一识别一个进程，这两者的组合就是一个主键(Master Key)。通俗地说，在数据库管理系统，主键可以唯一锁定一条记录。进程B(进程ID= 168323)心有不甘，发现计算机还有其它接口地址2.2.2.2，于是通过Bind (‘2.2.2.2’, 50007)，这次成功了。操作系统老爷爷又颤颤巍巍掏出小本子记录了下来：(2.2.2.2，50007)--------168323这样当有(2.2.2.2 ， 50007)组合报文到达时，操作系统可以将其转交给进程号= 168323的进程B。问题来了，进程A与进程B是什么关系？进程A、B可以是代码完全不同的程序，也可以是代码相同的程序，在自己独立的内存空间运行的不同实列(Instance)。好比你同时打开多个Word程序，这些Word程序使用相同的代码，但是他们是多个Word实例。问题又来了，如果进程A的代码真的是那样编码，如果放到其它计算机上执行，会遇到问题，因为其它计算机的IP地址可能≠1.1.1.1。为了提高代码的健壮性、可移植性，通常会使用这样的代码：Bind (‘ ’, 50007)其中‘ ’表示任何IP地址。换句话说，不Care计算机的接口IP地址。这个IP地址可以是127.0.0.1，也可以是1.1.1.1， 也可以是192.168.1.1，随便多少都行。那么这个程序可以放到任何计算机上执行。在同一台机器上一个进程B也这样执行：Bind (‘ ’, 50007)，可以哇？不可以，因为与进程A冲突！进程B可以Bind (‘ 1.1.1.1’, 50007)，可以哇？同样不可以，依然与进程A冲突。因为1.1.1.1是所有IP地址的子集。进程B心慌了，那怎么可以呢？操作系统老爷爷不紧不慢地说，只要别再使用端口50007就可以了。进程B于是执行代码如下：Bind (‘ ’, 50008)，可以哇？恭喜你，当然可以！通常服务器代码，都使用类似Bind (‘ ’, 50007) 方式执行，所以50007这个端口号可以唯一识别一个进程，这就是端口号可以唯一识别进程号的由来！