目录
[端口号（Port） vs 进程ID（PID）](#端口号（Port） vs 进程ID（PID）)
一、局域网通信机制的简介
- 广播特性：局域网内通信时，数据帧会被所有设备接收（物理层广播）
- MAC地址过滤：设备根据数据帧的目的MAC地址判断是否接收：若与自身MAC一致：接收并上传至上层协议栈；若不一致：直接丢弃
- 交换机作用：交换机通过MAC地址学习 构建转发表，实现了数据的按需转发 ，从而隔离了冲突域。它允许网络内多对节点同时并行通信，这是区别于集线器共享带宽的本质特征，也是以太网从共享介质迈向交换架构的核心飞跃
二、跨网通信与路由器
路由器核心功能
工作在网络层（IP层），屏蔽底层网络差异（如以太网、Wi-Fi）：
接收底层数据帧 → 解包提取IP数据报 → 根据目的IP选择路径 → 重新封装为新数据帧（替换源/目MAC地址）转发至下一跳
IP地址与MAC地址的区别
| 特性 | IP地址 | MAC地址 |
|---|---|---|
| 作用范围 | 全局唯一（端到端逻辑地址） | 局部唯一（单跳物理地址） |
| 变化性 | 跨网络时保持不变 | 每经过一个路由器均被替换 |
| 功能 | 标识源/目主机，用于路由选择 | 标识相邻设备（上一站/下一站） |
跨局域网时，原数据帧的源/目MAC地址会被路由器丢弃，替换为当前跳的MAC地址
IP协议的作用
- 通过路由器实现底层网络差异化屏蔽（如以太网、PPP、Wi-Fi统一为IP层）
- 构建全球主机的软件虚拟层，所有通信抽象为"IP报文传输"
- 依赖IP地址实现逻辑寻址（源IP/目的IP始终不变，指导端到端路径选择）
三、网络通信本质：进程间通信
- 用户通过应用层进程（如浏览器、微信）发起通信
- 进程将网络视为共享资源，通过协议栈（操作系统内核实现）封装/解包数据
- 本质是跨主机的进程间通信（IPC），依赖网络协议栈协调底层硬件
分层协作目标
- 数据链路层：解决相邻节点可靠传输；
- 网络层：解决跨网络寻址与路由；
- 传输层：解决端到端可靠传输（如TCP重传、流量控制）；
- 共同确保数据安全、可靠送达远端进程。
网络通信的本质是一条从物理设备到具体指令的逐级寻址链条 ：数据帧通过MAC地址 在局域网内找到下一跳设备；解封后，IP地址 在互联网范围内定位目标主机；抵达主机后，端口号 在传输层将数据交付给目标进程；最终进入进程内部，由操作系统根据PID等标识将数据引导至具体的执行流或线程。每一层地址只为解决"这一跳该找谁"的问题，层层递进，直至数据被正确消费
四、端口号
定义
- 所属层次：传输层（TCP/UDP协议）
- 数据类型：2字节（16位）无符号整数
- 数值范围：0 ~ 65535（2的16次方）
- 核心功能：进程标识
它是操作系统用来区分不同网络应用程序（进程）的逻辑接口。
数据包到达主机后，操作系统根据端口号将数据交给对应的进程（如QQ、浏览器、微信）。
端口号（Port） vs 进程ID（PID）
| 维度 | 进程ID (PID) | 端口号 (Port) |
|---|---|---|
| 作用域 | 主机内部（操作系统内核可见） | 全网/网络层（跨主机可见） |
| 唯一性 | 标识主机内所有进程（包括不联网的） | 仅标识正在进行网络通信的进程 |
| 必要性 | 所有进程都必须有PID（哪怕不上网） | 仅网络进程需要Port |
| 耦合度 | 与操作系统调度紧密耦合 | 与网络协议栈耦合，独立于OS内核细节 |
| 本质 | 操作系统的进程身份证 | 网络通信的哈希地址/索引 |
都是唯一标识进程，为什么还要再设计端口号？
- 按需分配：不是所有进程都需要网络功能（如后台日志进程），如果强制用PID做网络标识，会浪费资源且暴露系统内部结构
- 降低耦合：网络协议栈（TCP/IP）不需要知道操作系统内部复杂的进程管理机制，网络层只需要把数据扔给"端口号"，由操作系统内核负责查表映射到具体的PID，这样操作系统内核升级（如PID分配算法改变）不影响网络协议；网络协议升级不影响进程管理
- 哈希地址特性：端口号实际上是操作系统维护的一张哈希表（或查找表）的Key，内核通过端口号快速索引到对应的Socket缓冲区和进程PCB（进程控制块），效率极高
套接字Socket：全网唯一通信端点
- IP地址 ：公网/局域网层面，唯一标识一台主机（Host）
- 端口号 （Port）：主机层面，唯一标识一个进程（Process）
- Socket = (IP地址, 端口号)
- IP+Port 组合在一起，实现了全网范围内对一个正在通信的进程的唯一标识
Socket是IP+Port的封装，是应用层程序员唯一需要关心的接口， 程序员不需要关心底层是PID多少，也不需要关心网卡MAC是什么，只需要操作Socket，操作系统内核会自动完成剩下的映射和封装，即Socket让程序员专注于"与谁通信、发什么数据"，而把"怎么找到对方、怎么传过去"的复杂问题，完全交给操作系统内核去处理
端口号占用规则
一个进程可以绑定多个端口号
一个Web服务器进程（如Nginx）可以同时监听 80 (HTTP) 和 443 (HTTPS)
一个数据库进程可以监听 3306 (MySQL) 和 X (管理端口)
绝对禁止多个进程同时绑定（监听）同一个端口号后果：会报错 Address already in use（地址已被占用）
原因：如果两个进程都监听80端口，当数据包到达时，操作系统无法决定交给谁，产生歧义
注：虽然可以通过 SO_REUSEADDR 或 SO_REUSEPORT 实现多进程共享端口（负载均衡），但在内核底层处理上，它们仍被视为不同的socket实例或由内核进行分发，而非简单的"重复绑定"。
进程如何获知对方的端口号
进程获知对方端口号的方式主要分为约定 和协商 两种。对于常见的客户端-服务器模型，服务器使用"周知端口号"（Well-Known Ports） ，这些端口（如HTTP的80、HTTPS的443）是固定分配并广为人知的，客户端在发起连接前就已经通过协议约定知晓；而客户端的端口号则由操作系统临时动态分配，在建立连接时通过TCP/UDP报文头告知服务器，实现双向通信
五、传输层协议的简介
传输层协议概览
传输层位于网络层（IP）之上，应用层之下。它的核心职责是负责端到端（进程到进程）的数据传输
主要协议有TCP （传输控制协议）、UDP（用户数据报协议）
核心作用是通过端口号找到进程后，决定"怎么传"数据
TCP协议：传输控制协议
- 有连接 ：在传输数据之前，通信双方必须通过三次握手建立连接，确认彼此的发送与接收能力正常
- 可靠传输 ：TCP承诺数据不丢失、不重复、按顺序到达
- 面向字节流 ：TCP不关心发送的是什么类型的数据，它将应用层传来的所有数据视为一串连续的字节序列 。就像往水管里注水一样，数据被拆分成一个个数据段发送，接收方只管按顺序读取字节流，但这也意味着应用层需要自己处理消息边界问题
UDP协议：用户数据报协议
- 无连接 ：UDP在发送数据之前不需要建立连接。应用程序想发就发，直接把数据扔给网络。就像写个纸条塞进邮筒，不需要提前和对方打招呼确认对方是否准备好
- 不可靠传输 ：不保证数据一定能送达，也不保证顺序、不保证不重复
- 面向数据报 ：应用层交给UDP的每个数据包，都被当作独立的整块数据 发送。UDP保留消息边界：发送方发几次，接收方就必须收几次
| 特性 | TCP | UDP |
|---|---|---|
| 连接性 | 有连接（需握手） | 无连接（直接发） |
| 可靠性 | 可靠（确认、重传、排序） | 不可靠（尽力而为） |
| 传输方式 | 面向字节流（无边界） | 面向数据报（有边界） |
| 速度/效率 | 较慢（头部大，机制复杂） | 极快（头部小，无额外开销） |
| 头部大小 | 20字节（最小） | 8字节（固定） |
| 应用场景 | 文件传输、网页、邮件、SSH | 视频直播、语音通话、DNS、游戏 |
选 TCP：不能容忍数据错误或丢失（如转账、下载软件、网页加载）
选 UDP：更在意实时性，能容忍少量丢失（如王者荣耀语音、抖音直播、DNS查询）
TCP：连接可靠字节流，三次握手慢如牛
UDP：无连不可靠数据报，多快好省不回头