计算机网络
网络世界的坐标系 MAC地址与IP地址
一、 核心架构：为什么需要物理与逻辑两套寻址体系？
在网络工程架构中，MAC 地址与 IP 地址的共存并非冗余，而是为了解决网络规模扩展时的寻址效率与物理硬件解耦问题。
MAC 地址（物理寻址，平面架构）：工作在数据链路层。MAC 地址是扁平化的（Flat Addressing），它仅唯一标识网络节点的硬件接口（网卡 NIC），不包含任何拓扑位置信息。如果互联网仅依赖 MAC 地址进行路由，全球所有的路由器必须维护一张包含数十亿条目的转发表，这在内存寻址和路由收敛上是完全不可行的。
IP 地址（逻辑寻址，层次化架构）：工作在网络层。IP 地址是层次化的（Hierarchical Addressing），包含了网络前缀（Network Prefix）和主机标识（Host ID）。路由器仅需根据网络前缀进行聚合路由（如 BGP 路由表），大幅降低了路由表的规模。
结论：IP 地址负责提供端到端（End-to-End）的全局路由拓扑定位，而 MAC 地址负责在单跳（Hop-by-Hop）的局域网物理介质中完成帧的精确交付。
二、 MAC 地址 (Media Access Control Address)
MAC 地址是数据链路层中以太网（IEEE 802.3）和 Wi-Fi（IEEE 802.11）等网络技术的硬件标识。
1. 结构与格式
MAC 地址长度为 48 bits（6 字节），通常以十六进制表示（如 00:1A:2B:3C:4D:5E）。它被严格划分为两部分：
OUI (Organizationally Unique Identifier，24 bits)：组织唯一标识符，由 IEEE 分配给硬件制造商。
UAA (Universally Administered Address，24 bits)：厂商自行分配的流水号。
首字节控制位深度解析：
OUI 的第一个字节的最低两位具有特殊的控制指令含义：
I/G 位 (Individual/Group, 第 0 位)：
0表示单播（Unicast）地址，1表示组播（Multicast）或广播（Broadcast）地址（如FF:FF:FF:FF:FF:FF）。U/L 位 (Universal/Local, 第 1 位)：
0表示全局唯一（出厂烧录），1表示本地管理（Local Administered）。当操作系统通过软件修改 MAC 地址时，通常会将此位置1。
2. 交换机转发机制 (CAM 表)
局域网内的二层交换机通过维护 MAC 地址表（CAM 表，内容寻址存储器） 实现精确转发。
源地址学习：当帧进入交换机端口时，交换机记录帧的源 MAC 地址与入端口的映射关系。
未知单播泛洪 (Unknown Unicast Flooding)：当目标 MAC 地址不在 CAM 表中时，交换机会将该帧复制并向除入端口外的所有端口广播。
安全风险：MAC 泛洪攻击 (MAC Flooding)
攻击者伪造大量具有随机源 MAC 地址的以太网帧发送给交换机，耗尽 CAM 表内存空间。此时交换机将退化为集线器（Hub），对所有数据帧进行泛洪处理，攻击者借此可进行局域网流量嗅探。防御方案通常为配置端口安全（Port Security），限制单端口允许学习的 MAC 数量。
三、 IP 地址 (Internet Protocol Address)
IP 地址是网络层的核心，用于跨越不同异构网络的端到端通信。目前主流版本为 IPv4 与 IPv6。
1. IPv4 与无类域间路由 (CIDR)
IPv4 地址长度为 32 bits，采用点分十进制表示。现代网络已废弃传统的 A/B/C 类地址划分，全面采用 CIDR（无类域间路由）。
子网掩码 (Subnet Mask)：用于通过按位与（Bitwise AND）运算，将 IP 地址划分为网络地址与主机地址。
CIDR 记法：如
192.168.1.100/24，表示前 24 位为网络前缀。
显示可视化演示
高频安全测试/特殊 IPv4 地址：
127.0.0.0/8：本地回环接口（Loopback）。数据包不会触碰物理网卡，由操作系统网络栈直接内部处理。169.254.0.0/16：链路本地地址（APIPA）。在云原生安全（如 AWS/Aliyun）中，169.254.169.254经常被部署为实例元数据服务（IMDS），是 SSRF（服务端请求伪造） 漏洞获取高权限凭证的重点攻击目标。私有网段（RFC 1918）：
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16。需配合 NAT 技术访问公网。
2. IPv6：下一代互联网协议
IPv6 地址长度扩展至 128 bits，采用冒号十六进制表示，从根本上解决了 IPv4 地址枯竭问题。
格式简化规则：
每组前导零可省略（如
0DB8可写为DB8）。连续的全零组可使用双冒号
::替代（一个地址中仅允许使用一次）。
核心地址类型：
全局单播地址 (Global Unicast)：类似于 IPv4 公网地址，前缀通常为
2000::/3。链路本地地址 (Link-Local)：以
fe80::/10开头。IPv6 要求每个接口必须具备链路本地地址，用于同一链路内的邻居发现（NDP）和路由发现。组播地址 (Multicast)：以
ff00::/8开头。IPv6 废弃了广播（Broadcast），所有的广播功能均由组播替代，降低了网络整体的干扰。
SLAAC 与 EUI-64：
IPv6 支持无状态地址自动配置（SLAAC）。主机可利用路由器的前缀通告（RA），结合自身 MAC 地址生成接口标识符（EUI-64 规范：在 48 位 MAC 地址中间插入 FF:FE 并翻转第 7 位控制位），自动组装成 128 位全局可达地址。
四、 ARP 协议 (Address Resolution Protocol)
在同一局域网内，网络层封装完成 IP 数据报后，数据链路层需要知道目标硬件的 MAC 地址才能进行帧的物理发送。ARP 协议（RFC 826）即扮演了将 IP 地址解析为 MAC 地址的桥梁角色。
1. ARP 交互流程
ARP Request（广播）：主机 A 查询路由表，发现目标 IP
192.168.1.2位于同网段。A 封装 ARP 请求报文，以广播 MAC 地址FF:FF:FF:FF:FF:FF发送：“谁是192.168.1.2？请将你的 MAC 地址回复给192.168.1.1。”ARP Reply（单播）：主机 B 收到广播后，发现目标 IP 与自身匹配。B 封装 ARP 应答报文，直接单播回复主机 A：“我是
192.168.1.2，我的 MAC 地址是00:1A:2B:XX:XX:XX。”ARP Cache：主机 A 收到回复后，将该 IP-MAC 映射关系写入本地 ARP 缓存表，并在随后的数据传输中直接调用。
2. 免费 ARP (Gratuitous ARP)
发送方主动发送目标 IP 为自身 IP 的 ARP 请求包。主要用于：
IP 冲突检测：主机刚分配到 IP 时，探测局域网内是否有设备使用了相同 IP。
高可用性集群 (HA) 故障转移：当备用服务器接管主服务器的 VIP（虚拟 IP）时，主动发送免费 ARP 刷新全网交换机和主机的 ARP 缓存表。
安全风险：ARP 欺骗 (ARP Spoofing/Poisoning)
ARP 协议是**无状态（Stateless）**且缺乏身份验证机制的。攻击者可向目标主机发送伪造的 ARP Reply 报文，宣称自己是网关。目标主机接收后会覆写本地 ARP 缓存，导致后续所有的公网出口流量被劫持到攻击者机器，形成中间人攻击（MITM）。
五、 数据转发的全过程推演 (路由机制)
理解网络通信的核心，在于明确数据包在穿越异构网络时，各层头部的动态变化规律。
场景设定：主机 PC (192.168.1.100, MAC_A) 请求公网服务器 S (8.8.8.8, MAC_S)，途经本地网关路由器 R (内网接口 MAC_R1，外网接口 MAC_R2)。
步骤 1：主机端路由决断与封装
网络层决断：PC 将目标 IP
8.8.8.8与本地子网掩码进行按位与运算，发现目标不在本地网段。查路由表：PC 查找本地路由表，命中默认路由（
0.0.0.0/0），确认下一跳 IP 为网关地址192.168.1.1。数据链路层封装：PC 通过 ARP 缓存获取网关 MAC_R1。封装数据帧：
源 IP：
192.168.1.100| 目的 IP：8.8.8.8源 MAC：MAC_A | 目的 MAC：MAC_R1
步骤 2：路由器解封装与跳步转发 (Hop-by-Hop)
解帧与校验：网关路由器 R 收到物理信号，校验帧的目的 MAC 为 MAC_R1，接收该帧并剥离以太网帧头。
路由查表：路由器提取 IP 数据报，检查目的 IP
8.8.8.8，依据自身路由表（利用最长前缀匹配原则）确定出接口及下一跳路由器的 IP。重写帧头并发送：路由器 R 通过其外网接口所在的网络重新封装数据链路层帧。此时关键变化发生：
源 IP：
192.168.1.100（保持不变，暂不考虑 NAT 转换） | 目的 IP：8.8.8.8（保持不变）新源 MAC：MAC_R2 （路由器的外网接口 MAC） | 新目的 MAC：下一跳路由器的 MAC
核心路由定律：
在端到端的网络通信中（忽略 NAT 穿透场景），网络层 IP 报文的源与目的 IP 始终保持不变，用于标识通信的绝对起点与终点；而数据链路层的源与目的 MAC 地址在每一次经过路由器（每一跳）时，均会被剥离并重写，用于指引当前物理链路的传输方向。
六、 总结与对比矩阵
| 维度 | **MAC 地址 ** | IP 地址 |
|---|---|---|
| 工作层次 | 数据链路层 | 网络层 |
| 寻址范围 | 单一物理网段 / 广播域内 | 全球异构网络互联 / 端到端跨网 |
| 地址属性 | 扁平化架构，固化于硬件 (可软件伪造) | 层次化架构，基于拓扑动态分配 |
| 长度与格式 | 48 bits (十六进制) | IPv4: 32 bits / IPv6: 128 bits |
| 传输动态 | 逐跳重写 (Hop-by-Hop Rewritten) | 端到端保持不变 (End-to-End Preserved) |
| 解析关联 | 通过 ARP 将已知 IP 解析为 MAC | 通过 DNS 将域名解析为 IP |
| 典型安全威胁 | MAC Spoofing, MAC 泛洪, ARP 欺骗 | IP Spoofing, SSRF, DDoS |
HTTP与HTTPS
一、 HTTP 协议基础与报文解构
HTTP 是一种无状态（Stateless）、基于文本的请求-响应（Request-Response）协议。它通常运行在 TCP 协议之上（HTTP/3 除外，运行在基于 UDP 的 QUIC 之上），默认端口为 80。
1. HTTP 报文的字节级结构
HTTP 的解析高度依赖于回车换行符（CRLF，即 \r\n）。无论是请求还是响应，报文均被严格划分为四个部分：
以一个真实的 HTTP/1.1 GET 请求为例（Raw 数据）：
HTTP
1 | GET /api/v1/user/profile?id=1001 HTTP/1.1\r\n |
结构逐行拆解：
请求行 (Request Line)：
方法 URI 协议版本\r\n。定义了动作的意图。请求头 (Headers)：以
Key: Value\r\n的格式呈现，提供关于请求的元数据。在 HTTP/1.1 中，Host字段是唯一强制要求的请求头（用于单台物理服务器处理多个虚拟主机域名）。空行 (Blank Line)：一个孤立的
\r\n。这是 HTTP 协议的边界标识符，告诉解析引擎：“头部结束，下面是正文数据”。请求体 (Body)：实际传输的业务数据（如 JSON、表单数据）。
响应报文结构（Response）：
HTTP
1 | HTTP/1.1 200 OK\r\n |
响应报文的首行被称为状态行 (Status Line)，包含协议版本、状态码（Status Code）及其简短描述（Reason Phrase）。
2. HTTP 的致命缺陷：明文传输
HTTP 设计之初并未考虑复杂的网络安全威胁，所有数据（包括 Cookie、Authorization 凭证、个人隐私）在 TCP 连接中均以**明文（Plaintext）**形式流动。这导致其面临三大核心威胁：
窃听风险 (Eavesdropping)：中间节点（路由器、代理、运营商）可轻易使用 Wireshark 等工具截获数据包，获取敏感凭证。
篡改风险 (Tampering)：中间人可拦截并修改报文内容（如运营商劫持注入广告、恶意篡改支付金额），通信双方无法察觉。
冒充风险 (Spoofing)：缺乏身份验证机制，客户端无法确认通信的服务器是否为真实的宿主（如 DNS 劫持导致的钓鱼网站）。
二、 HTTPS 的安全基石：TLS 密码学体系
为了解决上述三大威胁，HTTPS 应运而生。HTTPS 并非一个全新的协议，而是 HTTP 运行在 TLS (Transport Layer Security，传输层安全协议) 及其前身 SSL 之上。默认端口为 443。
TLS 构建了一个防窃听、防篡改、防伪造的安全隧道。其底层依赖于现代密码学的三大支柱：
1. 对称加密 (Symmetric Cryptography) —— 解决窃听
原理：加密和解密使用同一把密钥（如 AES、ChaCha20 算法）。
优势：计算速度极快，适合海量 HTTP 业务数据的加密传输。
困境：如何将这把对称密钥安全地跨越不安全的互联网交到对方手里？（即密钥分发难题）。
2. 非对称加密 (Asymmetric Cryptography) —— 解决密钥分发与身份验证
原理：生成一对数学相关的密钥：公钥（Public Key，公开）与私钥（Private Key，严格保密）。公钥加密的数据仅能用私钥解密；反之，私钥加密（签名）的数据仅能用公钥解密（验签）。常见的算法包括 RSA、ECC（椭圆曲线）。
在 TLS 中的应用：服务器将公钥明文发给客户端，客户端生成一个随机的“对称密钥”，用服务器的公钥加密后发给服务器。由于只有服务器拥有私钥，中间人即使截获了加密后的对称密钥也无法解密。
劣势：计算极其缓慢，消耗大量 CPU 资源，因此仅用于握手阶段的密钥协商，不用于加密庞大的 HTTP 报文。
3. 哈希算法与数字证书 (PKI 体系) —— 解决篡改与冒充
哈希算法 (Hash)：如 SHA-256，将任意长度的数据映射为固定长度的摘要。结合对称密钥生成 MAC（消息认证码），保证报文完整性，防篡改。
数字证书 (Digital Certificate)：如果黑客一开始就截获了通信，把自己的公钥冒充成服务器的公钥发给客户端（中间人攻击），非对称加密将形同虚设。为了防伪装，服务器必须向受信任的 CA（证书颁发机构） 申请数字证书。
证书内包含：服务器的公钥、域名、有效期，以及 CA 对该证书内容的数字签名（使用 CA 的私钥加密的 Hash 值）。
客户端（操作系统/浏览器）内置了根 CA 的公钥，可通过解密签名来验证证书的合法性，从而确保收到的服务器公钥是真实的。
三、 TLS 1.2 握手全景解构 (The TLS Handshake)
TLS 握手是 HTTPS 建立的核心阶段。它的目标是通过上述密码学工具，在极度不安全的网络环境中，让客户端与服务端安全地协商出一条唯一的主密钥（Master Secret）。
TLS 1.2 握手核心步骤提炼：
Client Hello：客户端发送支持的 TLS 版本、密码套件列表（Cipher Suites，如
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384），以及一个客户端随机数 (Client Random)。Server Hello & Certificate：服务端确认 TLS 版本和密码套件，生成一个服务端随机数 (Server Random)，并将包含其公钥的数字证书发送给客户端。
Client Key Exchange：
客户端验证证书合法性。
客户端生成第三个随机数，称为 预主密钥 (Pre-Master Secret)。
客户端使用提取出的服务器公钥对预主密钥进行非对称加密，发送给服务端。
Master Secret Generation：服务端利用自己的私钥解密，获得预主密钥。此时，客户端和服务端同时拥有了三个随机数（Client Random, Server Random, Pre-Master Secret）。双方使用相同的伪随机函数（PRF），结合这三个随机数计算出最终的对称加密密钥——主密钥 (Master Secret/Session Key)。
Finished：双方互发
Finished消息（被主密钥加密），验证加密通道连通性。随后正式开始 HTTP 应用层数据的对称加密传输。
四、 总结与对比
| 维度 | HTTP | HTTPS |
|---|---|---|
| 协议栈层次 | Application (应用层) | Application (基于 TLS 安全隧道) |
| 默认端口 | TCP 80 |
TCP 443 |
| 数据状态 | 明文 (Plaintext) | 密文 (Ciphertext, 对称加密) |
| 连接建立开销 | TCP 三次握手 (1-RTT) | TCP 握手 + TLS 握手 (通常需 3-RTT，TLS 1.3 优化至 2-RTT) |
| 身份验证机制 | 无验证 (极易遭受 DNS/ARP 劫持) | PKI 数字证书体系 (强制校验服务器身份) |
| 性能消耗 | 极低 | 存在 CPU 密码学计算开销（现代硬件下影响极小） |
| 现代协议演进 | HTTP/1.1 (Keep-Alive, 队头阻塞问题) | HTTP/2 (多路复用, 必须强制开启 TLS), HTTP/3 (QUIC, 放弃 TCP 转向 UDP) |
TCP的握手挥手
TCP 运行在传输层，其核心设计目标是提供面向连接的、可靠的、基于字节流的传输服务。
1. TCP 报文首部核心字段解构
TCP 通过复杂的报文头部来实现其控制逻辑，标准头部长度为 20 字节。
源端口与目的端口 (Source/Destination Port)：各 16 bits。结合 IP 地址，构成唯一的通信套接字（Socket）四元组
(Src IP, Src Port, Dst IP, Dst Port)。序列号 (Sequence Number, SEQ)：32 bits。TCP 将发送的字节流进行整体编号，SEQ 表示当前报文段第一个字节的序号。用于解决网络包乱序和重复问题。
确认号 (Acknowledgment Number, ACK)：32 bits。期望收到对方下一个报文段的第一个字节序号。表示该序号之前的所有数据均已正确接收。用于解决丢包问题。
控制标志位 (Flags)：
SYN (Synchronize)：发起一个新连接。
ACK (Acknowledgment)：确认号有效标志。
FIN (Finish)：释放一个连接，表示发送方没有数据要发送了。
RST (Reset)：强制重置连接（通常在异常或拒绝连接时发生）。
窗口大小 (Window Size)：16 bits。用于流量控制，告知对方本机当前的接收缓冲区还能容纳多少字节。
2. TCP 连接建立：三次握手 (Three-Way Handshake)
TCP 连接的建立不仅是确认双方在线，更核心的目的是同步双方的初始序列号 (ISN, Initial Sequence Number)。
第一次握手 (SYN)：客户端选择一个随机初始序列号
seq = x，设置 SYN=1，发送给服务端。客户端进入SYN_SENT状态。第二次握手 (SYN + ACK)：服务端收到后，同样选择自己的随机初始序列号
seq = y，并确认客户端的序列号ack = x + 1，设置 SYN=1, ACK=1，回复客户端。服务端进入SYN_RCVD状态。第三次握手 (ACK)：客户端收到服务端的 SYN+ACK，回复确认包
ack = y + 1,seq = x + 1，设置 ACK=1。客户端进入ESTABLISHED状态。服务端收到此包后也进入ESTABLISHED状态。此时连接正式建立。
硬核拷问：为什么必须是三次握手，两次不行吗？ 核心原因是为了防止已失效的连接请求报文段突然又传送到了服务端，从而产生错误。 假设仅需两次握手：客户端发出 SYN，因网络延迟滞留。客户端超时重发 SYN，服务端收到并建立连接，通信完毕后断开。此时，最初那个滞留的 SYN 突然到达服务端。服务端误以为客户端又发起了新连接，回复 SYN+ACK 并直接进入 ESTABLISHED 状态。但客户端此刻根本没有建连意图，会直接丢弃该报文。而服务端会一直等待客户端发送数据，导致服务端资源（端口、内存）被白白消耗。三次握手赋予了客户端在最后关头“拒绝无效连接”的权力。
3. TCP 连接释放：四次挥手 (Four-Way Teardown)
TCP 是全双工 (Full-Duplex) 的，允许单向关闭（半关闭 Half-Close）。因此断开连接需要双方独立发送 FIN 并被对方 ACK。
第一次挥手 (FIN)：客户端发送
FIN=1, seq=u，表示客户端没有数据要发送了。进入FIN_WAIT_1状态。第二次挥手 (ACK)：服务端收到 FIN，回复
ACK=1, ack=u+1。服务端进入CLOSE_WAIT状态。客户端收到后进入FIN_WAIT_2状态。此时连接处于半关闭状态，客户端无法发数据，但服务端如果还有剩余数据，仍可继续发送给客户端。第三次挥手 (FIN)：服务端数据发送完毕，发送
FIN=1, seq=w。进入LAST_ACK状态。第四次挥手 (ACK)：客户端收到 FIN，回复
ACK=1, ack=w+1。客户端进入TIME_WAIT状态。服务端收到后进入CLOSED状态。
硬核拷问：深度解析 TIME_WAIT 状态（2MSL） 客户端在发送完最后一个 ACK 后，必须等待 2MSL（Maximum Segment Lifetime，报文最大生存时间，通常 Linux 默认 60 秒）才能进入 CLOSED 状态释放端口。 原因一：保证可靠的全双工连接终止。 如果最后的 ACK 丢失，服务端会触发超时重传，重新发送 FIN。如果客户端不等待直接关闭，收到重传的 FIN 时会回复 RST，导致服务端非正常关闭。TIME_WAIT 确保客户端有时间响应可能重传的 FIN。 原因二：防止历史报文段干扰新连接。 网络中可能残留属于该连接的延迟数据包。等待 2MSL 可确保本次连接产生的所有报文段在网络中彻底消亡，避免相同端口对（Tuple）建立新连接时，被旧的残留数据包干扰。
UDP
2.1 UDP 的核心特性
UDP（User Datagram Protocol）是无连接、不可靠、数据报的协议，发送前不需要建立连接，尽力而为地传输，不保证到达，不保证顺序，不保证不重复。
1 | 无连接：直接发送，不握手不可靠：没有确认、重传、排序机制数据报：有边界，一次发送就是一个完整的数据报，接收方一次收一个低开销：首部只有 8 字节，处理速度快 |
2.2 UDP 报文结构
UDP 的结构极其简单，首部固定只有 8 字节：
1 | ┌─────────────────────────────┬─────────────────────────────────┐│ 源端口号（16位） │ 目的端口号（16位） │├─────────────────────────────┼─────────────────────────────────┤│ 长度（16位） │ 校验和（16位） │├─────────────────────────────┴─────────────────────────────────┤│ 数据部分 │└───────────────────────────────────────────────────────────────┘ |
| 字段 | 大小 | 说明 |
|---|---|---|
| 源端口 | 16位 | 可选，不需要回复时可填 0 |
| 目的端口 | 16位 | 必须，标识接收进程 |
| 长度 | 16位 | UDP 首部+数据的总长度，最小值 8 |
| 校验和 | 16位 | 可选，用于差错检测，IPv4 中可置 0 跳过 |
| 对比 TCP 的 20 字节最小首部，UDP 只有 8 字节，处理开销极小。 |
2.3 UDP 没有的东西
理解 UDP 最好的方式是列出它不具备的 TCP 特性，以及为什么：
| TCP 特性 | UDP 有无 | 影响 |
|---|---|---|
| 三次握手 | 无 | 无连接延迟，但无法确认对方在线 |
| 确认机制 | 无 | 发完不管，不知道对方有没有收到 |
| 重传机制 | 无 | 丢包不重发 |
| 序号/排序 | 无 | 多包乱序不纠正 |
| 流量控制 | 无 | 可能淹没接收方 |
| 拥塞控制 | 无 | 网络拥塞时仍全速发送 |
| 全双工 | 有 | 双方都可发送 |
3. 区别
| 维度 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（需握手） | 无连接（直接发） |
| 可靠性 | 可靠，保证到达、有序、不重复 | 不可靠，尽力而为 |
| 数据单位 | 字节流（无边界） | 数据报（有边界） |
| 首部大小 | 最小 20 字节 | 固定 8 字节 |
| 速度 | 慢（确认、重传、拥塞控制开销） | 快（无额外机制） |
| 拥塞控制 | 有 | 无 |
| 广播/多播 | 不支持 | 支持 |
| 适用场景 | 要求数据完整 | 要求低延迟 |
4. 各自的适用场景
4.1 TCP 适合
对数据完整性要求高、可以接受延迟的场景：
- HTTP/HTTPS：网页传输，数据缺失直接显示错误
- FTP：文件传输，文件损坏不可接受
- SSH：远程登录，指令不能乱序或丢失
- SMTP/POP3：邮件传输
- 数据库连接：MySQL、PostgreSQL 等
4.2 UDP 适合
对实时性要求高、少量丢包可以接受的场景：
- DNS：查询短小，一来一回，不需要连接开销
- 视频直播/音视频通话：丢几帧比卡顿更能接受（WebRTC 基于 UDP）
- 在线游戏：位置同步，旧数据丢了没关系，要的是最新状态
- DHCP：获取 IP 地址，广播场景
- QUIC（HTTP/3）：Google 设计的基于 UDP 的传输协议，在应用层自己实现可靠性，避免 TCP 的队头阻塞
HTTP 报文的封装与解封装
以一段真实封装来理解
第一阶段：应用层 (Application Layer) —— 原始字节流的诞生
根据 HTTP/1.1 规范，在内存中分配了一块缓冲区，构造出了一段纯文本格式的字节流。
1 | GET /index.html HTTP/1.1\r\n |
此时，这段数据没有任何寻址能力。浏览器通过触发系统调用（如 send() 或 write()），将这段字节流拷贝到操作系统**内核态（Kernel Space）**的 Socket 发送缓冲区中。应用层的工作到此结束。
第二阶段：传输层 (Transport Layer) —— 端口注入与可靠性序列化
内核的 TCP 协议栈接管了这段数据（Payload）。 如果 Payload 大于 MSS（最大报文段长度，通常为 1460 字节），TCP 会将其切割。随后，TCP 为数据块强制注入 20 字节的 TCP 首部。
TCP Header 核心注入字段：
Source Port: 54321|Destination Port: 80（定义端到端的进程寻址）Sequence Number: 1000（当前报文段在整个字节流中的绝对偏移量编号）Acknowledgment Number: 1（全双工通信中，期望对方回复的下一个编号）Flags: ACK=1, PSH=1（PSH 标志位指令接收方内核：收到此包后立即推入应用层，禁止在缓冲区延迟等待）
当前 PDU 形态：TCP 报文段 (Segment) 结构：[TCP Header (20B)] + [HTTP Payload]
第三阶段：网络层 (Network Layer) —— 全局路由寻址注入
TCP 模块将 Segment 移交给 IP 模块。IP 模块并不关心里面装的是 HTTP 还是 FTP，它的唯一任务是为数据包注入全局路由逻辑。IP 模块在前方注入 20 字节的 IPv4 首部。
IP Header 核心注入字段：
Source IP: 192.168.1.100|Destination IP: 93.184.216.34TTL: 64（生存时间，防止路由环路，每经过一个三层设备减 1）Protocol: 6（多路复用标识！ 6 代表上层载荷是 TCP 协议。这为接收方的解封装提供了唯一的指路明灯）
当前 PDU 形态：IP 数据报 (Packet / Datagram) 结构：[IP Header (20B)] + [TCP Header] + [HTTP Payload]
第四阶段：数据链路层 (Data Link Layer) —— 物理介质精确寻址
IP 数据报被送入网卡驱动程序。在局域网以太网标准下，驱动程序需要确定下一跳的物理 MAC 地址。
驱动检查目的 IP
93.184.216.34，发现不在192.168.1.0/24子网内。查找路由表，确定下一跳为默认网关
192.168.1.1。查询本机 ARP 缓存表，获取网关的 MAC 地址
11:22:33:44:55:66。
驱动程序在前方注入 14 字节的以太网帧头，在尾部追加 4 字节的 FCS（帧检验序列）。
Ethernet II Header 核心注入字段：
Destination MAC: 11:22:33:44:55:66（注意：这里绝不是目标服务器的 MAC！而是网关的 MAC）Source MAC: AA:BB:CC:DD:EE:FFEtherType: 0x0800（多路复用标识！ 告知接收方硬件，该帧内部封装的是 IPv4 报文）
当前 PDU 形态：以太网帧 (Frame) 结构：[Eth Header (14B)] + [IP Header] + [TCP Header] + [HTTP Payload] + [FCS (4B)]
第五阶段：物理层 (Physical Layer) —— 模数转换与发送
网卡（NIC）硬件通过 DMA（直接内存访问）技术将内核中的 Frame 拷贝到网卡显存，将其转化为电平差分信号或光信号，以 010101 比特流的形式压入传输介质。
路由中转
入站拆帧：路由器接收物理电信号还原为帧。校验 FCS 通过后，直接剥弃原来的以太网帧头与帧尾，露出 IP 数据报。
网络层决断：读取 IP 头部的目的 IP
93.184.216.34。在路由表中利用最长前缀匹配算法查找到下一跳路由器的 IP 及出口网卡。处理 TTL 与 Checksum：将 IP 头的 TTL 减 1。由于 TTL 改变，必须重新计算 IP 首部校验和。(如果在我们的设定中，该路由器是家用的 NAT 网关，它还会在这里将源 IP 替换为公网 IP
203.0.113.10)。出站重装帧：路由器通过出口网卡的 ARP 表查到下一跳路由器的 MAC 地址。生成一个全新的以太网帧头（源 MAC 变为本路由器的出口 MAC，目的 MAC 变为下一跳路由器 MAC），再次发送。
数据到达目标服务器后，按照与封装完全相反的顺序，每一层剥掉自己的头部，把数据交给上层：
物理层：接收信号，还原比特流
1 | 物理介质上的电信号/光信号 |
数据链路层：解析以太网帧
1 | 收到比特流，按以太网帧格式解析 |
网络层：解析 IP 数据包
1 | 收到IP数据包，解析IP首部 |
传输层：解析 TCP 报文段
1 | 收到TCP报文段，解析TCP首部 |
应用层：解析 HTTP 报文
1 | 收到HTTP报文数据 |
七、完整流程总览
1 | 应用层 HTTP报文 |
最后这里加深印象 我自己讲一遍当我输入一个域名在浏览器中去请求服务时 宏观架构与微观协议做了什么
以x为例 x.com 浏览器发现没有协议头 查询本地的 HSTS表 如果有的话浏览器就强制改写为https协议 然后浏览器会查询自身dns缓存 看看能否直接找到ip 不行的话 会去找操作系统的 DNS 缓存 都不行的话 则需要关联上UDP 去查找ip DNS通过快速递归去找到ip 这时候目标清晰了 则开始到了协议的部分
传输层的TCP链路 TLS加密通道 需要在三次握手 密码学握手后建立
这时候应用层封装 TLS加密 进到TCP模块传输层 IP模块网络层 链路层 依次打上加密 端口 ip MAC 通过路由器多次转送数据 到达x的网关 依次剥离验证 TLS终结 得到明文 在x内获得服务