【网络基础系列】03网络通信：实体、协议与 PDU/SDU 的流转真相

引言打破“学术黑话”的结界在学习计算机网络时你一定被这几个词折磨过“服务访问点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 作为参数一起丢给底层 TCPTCP 秘书再负责把这个 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站 湖科大教书匠《计算机网络微课堂》