引言：打破“学术黑话”的结界
在学习计算机网络时，你一定被这几个词折磨过：“服务访问点（SAP）”、“服务原语”、“协议数据单元（PDU）”、“服务数据单元（SDU）”。
字都认识，连在一起却像天书。为什么教材非要搞出这种“不说人话”的名词？
其实，这些词根本不是什么玄学，它们是对真实操作系统（如 Linux）底层网络代码最精准的概括。
今天，我们就把这些学术黑话全部“反编译”成大白话，带你用一线开发者的视角，彻底看透数据在网络底层到底是怎么流转的！
一、 实体（Entity）：究竟是谁在通信？
在网络体系结构中，经常出现一个词叫“实体”。
说白了，实体就是任何可以发送或接收信息的硬件（如网卡）或软件进程（如浏览器进程、微信进程）。
而通信双方在相同层次中的实体，被称为“对等实体（Peer Entity）”。比如你的浏览器和远端的 Apache 服务器，就是应用层的对等实体。
(图：通信双方相同层次的小方格，互为对等实体)
🔥 极客核心考点：点到点 vs 端到端
这里藏着一个极其高维的架构认知：数据在传输时，要经过无数个路由器。
路由器只有最底下的三层（物理层、数据链路层、网络层）。所以在转发时，这三层的对等实体是一直在变的（主机交给路由 A，路由 A 交给路由 B）。这叫作“点到点（Point-to-Point）通信”。
但是！路由器解不开“运输层”和“应用层”的包裹。所以无论中间隔了多少个路由器，你电脑的运输层和服务器的运输层，永远是直接对话的对等实体。这叫作“端到端（End-to-End）通信”。
二、 协议（Protocol）：跨国沟通的三大法则
协议，就是控制两个“对等实体”进行逻辑通信的规则集合。（注意是水平方向的通信）
就像一个中国人和一个日本人谈生意，双方必须统一规定用英语交流，而且要规定好谁先说话。计算机网络协议必须包含三大核心要素（协议三要素）：
1. 语法：定义交换信息的格式
语法只管“排版”。比如下面这张 IP 数据报的格式图，它严格规定了哪个字段占多少位（比如源地址占 32 位），谁在前面谁在后面。只有格式对齐了，对方的底层代码才能把这串 0 和 1 成功切割识别出来。
2. 语义：定义看懂之后该做什么动作
例如：主机要访问Web服务器，它会构建一个HTTP的GET请求报文，然后将其发送给Web服务器，web服务器收到该报文并进行解析，知道这是一个HTTP的GET请求报文。于是就在自身内部查找所请求的内容，并将所找到的内容封装在一个HTTP响应报文中发回给主机，主机收到HTTP响应报文后，对其进行解析。取出所请求的内容并由浏览器解析显示。
这个例子就可以体现出通信双方收到分组后完成怎样的操作，这是HTTP协议的语义所定义的（对于本例）。
大白话说：如果说语法是规定了什么内容占多少位，怎么排序，通信双方才能看懂，那语义就是当看懂内容后应该干什么，做出怎样的动作
3. 同步：定义通信双方的时序关系
请注意，这里并不是指时钟频率同步，这种先后顺序的“时序关系”，在真实的包结构中，是通过 TCP 首部里的 序号 (seq) 和 确认号 (ack) 这两个字段来物理记录和强制保证的。没有这两个字段，就无法维持同步规则。
例如：这是TCP采用“三报文握手”建立连接的过程，要想进行运输层TCP实体间的逻辑通信，首先必须建立连接，从连接建立的过程就可以看出，TCP客户端和TCP服务器之间的时序关系，以及各自的状态转换，只有双方建立连接后，才能进行TCP数据传输。
- 第一步：客户端对服务器发起TCP连接请求，然后进入同步已发送状态等待回复（注意：这个等待回复过程并不是监听）
- 第二步：一直处于监听状态下的服务器，收到了客户端的TCP连接请求，但是它还要再确认一遍，然后给客户端发送了TCP连接请求的确认。这时的服务器就从监听状态进入了同步已接收状态。（注意：即使进入同步已接收状态，服务器本身依然还在监听是否有其他客户端发送连接请求）
- 第三步：客户端收到了服务器发送的TCP连接请求的确认，知道服务器已经准备好了，最后给服务器发送了TCP确认。当最后的TCP确认送达后，双方就变成了连接已建立状态，这时候就可以进行TCP数据传输了
- 从上面的TCP三次握手可以看出，整个过程就是先后顺序的过程，谁先说话，谁回复，这种先后顺序可以称为
同步/时序
三、 服务（Service）与系统调用
协议是水平的（我和对面的你定规矩），而服务是垂直的（下层为上层打工）。
(图：下层为上层提供服务，上层享受服务)
在 IT 架构中，下层协议对上层是“透明”的。应用层的老板（Nginx）不需要懂底层的光纤是怎么发光的，它只需要闭着眼睛“享受”下层提供的服务即可。
这里有两个极其变态但又极其重要的名词：
🚪 1. 服务访问点（SAP）
书上说：“SAP 是相邻两层实体交换信息的逻辑接口”。
大白话翻译：SAP 就是 PDU 头部里，用来确认把包裹分发给上层哪个具体部门的【门牌号】！
链路层的 SAP 是
类型 (Type)字段（决定给 IPv4 还是 IPv6）。网络层的 SAP 是
协议 (Protocol)字段（决定给 TCP 还是 UDP）。运输层的 SAP 是
端口号 (Port)（决定给微信还是网页）。
💡 架构师视角：发数据时的 SAP 藏在哪？
接收数据时，SAP 是物理刻在包裹上的标签。但在发送数据（自上向下交接）时，上层的纯净数据里是没有端口号的。这时候 SAP 去哪了？
答案是：它变成了调用底层 API 函数时的**“传参（参数）”**！应用层把数据和目标端口 80 作为参数一起丢给底层 TCP，TCP 秘书再负责把这个 80 刻在真实的包裹壳上。
🗣️ 2. 服务原语（Service Primitives）
书上说：“上层使用下层服务必须交换命令，称为服务原语。”
大白话翻译：这就是程序员写的 API 函数调用！老板总不能靠脑电波指挥秘书干活吧？上层进程必须调用操作系统的基础 API（请求、指示、响应、确认），来命令底层网卡发包或收包。
四、 PDU 与 SDU：网络底层的“电梯换装魔术”
这是整个计算机网络中最容易绕晕、但弄懂后最爽的两个概念。
(图：各层的 PDU 与纵向交接的 SDU)
PDU（协议数据单元）：就是加了本层外壳、贴好快递单，能在对等层之间直接交流的“成品包裹”。（比如应用层的报文、运输层的报文段、网络层的 IP 数据报、链路层的帧）。
SDU（服务数据单元）：就是同一系统内，上下层之间交接时的“纯净裸数据”。
🌟 记住这个宇宙不变的“走廊理论”：
只要数据安稳地停在某层楼的办公室里（无论是正在加壳还是拆壳），它就是这层楼的PDU。
只要数据离开了办公室，在上下楼交接的电梯/走廊里，它就是脱掉了当前层外套的纯净货物，统一叫作SDU。
底层封包的终极公式：本层的 PDU = 本层的壳 (Header) + 上（下）层交接的 SDU。这就是一个严密的俄罗斯套娃！
🪓 碎纸机与打包机（SDU 的合并与划分）
千万不要以为老板交下来的 SDU，和秘书发出去的 PDU 永远是 1对1 的！
划分（1 拆 N）：你下载 1GB 电影（超大 SDU），网卡一次只能发 1500 字节（MTU 限制）。底层秘书只能把它切碎，套上无数个外壳，变成几十万个小 PDU 发出去。
合并（N 合 1）：你在终端里敲一个字母（极小 SDU），为了不浪费包装费，底层的Nagle 算法会让你等一等，攒够了一批字母，再套上一个外壳当成 1 个 PDU 发走。(如果你打游戏或用微信嫌弃这种延迟，代码里可以开启
TCP_NODELAY强行废除合并，不计成本地发包！)
读到这里，你眼里的计算机网络，是不是已经从“枯燥的考研八股文”，变成了一条精密运转、充满智慧博弈的工业流水线了？
本文理论模型、专用术语与图解，学习整理自优质网络公开课，由本人记录笔记交于AI进行，行文排版与大白话润色，特此致谢。主要内容来源：B站 湖科大教书匠《计算机网络微课堂》
