摘要

  • Header-Last 是 RFC 1963 的默认格式：发送端可先看到压缩后的大小，再决定当前 SDTP 分组是串行帧的开头、中段、结尾还是完整单帧。
  • RFC 1963 的分段位是 B/F，E 表示是否存在 CS 扩展头，SDTP 本身没有 sequence 字段；B/E/sequence 是 RFC 1990 PPP Multilink 的另一套格式。
  • Length 只划定 compound frame 内各 SDTP 分组的范围，Port 只提供协商后的复用标签；二者都不证明片段齐全、端口身份、压缩成功或接收业务恢复。

通常，头部先于数据，因为它告诉解析器后面的字节应当怎样读取。1996 年 8 月发布的 RFC 1963 反其道而行。PPP Serial Data Transport Protocol 的默认分组先放传输数据，最后才放终端适配头；头部字节的顺序也随之倒转。接收端必须同时从前端和尾端理解一个分组。

这个选择服务于发送时序。RFC 1963 来自同步数据压缩的工作，设想把 HDLC 类同步串行帧或异步串行数据带入 PPP。若一个串行帧经过压缩后可能跨越多个 SDTP 分组，发送端在压缩输出形成之前未必知道应在哪里切断。若头部在前，它必须提前宣布边界；若头部在后，它可以先观察压缩后的大小，再决定这个分组是否结束原帧，然后把描述该决定的头部继续交给压缩器。

因此，Header-Last 并不是一种装饰性的倒序。它把“何时知道分段结果”直接写进了分组布局。Header-First 仍可通过 SDCP 协商，适合不跨分组切分、没有与压缩结合，或硬件更适合传统顺序的情况。协商成功只说明双方采用同一种解析方式，不说明压缩率、压缩器状态或最终重建结果。

数据发送还有前置条件：PPP 必须进入 Network-Layer Protocol 阶段，SDCP 必须进入 Opened。IANA 为 SDTP 登记的 PPP 协议字段是 0x0049，为 SDCP 登记的是 0x8049。Opened 是格式共识的收据，不是数据交付的收据。

默认情况下，一个 PPP Information 字段只包含一个 SDTP 分组，而且没有 SDTP Length 字段。若双方同时成功协商 SDTP 的 Length-Field-Present 与 RFC 1570 的 LCP Compound-Frames，一个 PPP Information 字段才可以容纳多个 SDTP 分组。每个 Length 覆盖自身、可选 Port、适配头、传输数据以及可能的 Odd-Pad。单字节 Length 的有效合计范围为 2 至 255；双字节可到 65535；零表示占据 PPP Information 字段的剩余部分。

Length 解决的是“下一个 SDTP 分组从哪里开始”。它不回答“这个串行帧是否已经完整”。compound frame 中相邻的 SDTP 分组可能属于不同片段、不同原帧或不同端口。边界可解析，只能证明解析器有切分依据，不能补回未到达的片段。

Port 也一样。未协商 Multi-Port 时，所有分组都属于默认 Port 0，线上没有 Port 字节。协商成功后，每个 SDTP 分组都带一个端口号。0 至 254 用于数据端口，255 保留为控制用途；部分配置选项按端口生效，而 Port 255 的流控消息可作用于全部端口。

这个编号是一套共同约定的复用命名空间，不是身份证明。RFC 1963 没有用密码学把 Port 7 绑定到某根电缆、某台设备、某位客户或某项业务。接收端只能依赖自己的映射状态去分流。映射是否正确、是否已变更、是否仍对应预期物理端口，需要另一份证据。

真正描述串行帧分段的是 H 头部中的 B 与 F。同步 HDLC 类模式下，B 表示开头，F 表示结尾；两者都不置位表示中段，两者同时置位表示一个分组内的完整帧。异步模式要求两者同时置位。E 的作用完全不同：它说明可选的 CS 扩展头是否存在。把 E 当作 ending，会把另一份 RFC 的语义误搬进来。

RFC 1990 PPP Multilink 才使用 B/E 与 12 位或 24 位 sequence number，并在 bundle 的多条成员链路上定义丢失推断和重组。RFC 1963 没有这样的 sequence 字段，也没有按序号前进判断缺片的规则。SDTP 的开头和结尾标记可以帮助拼接已经收到的材料，却不能证明材料之间没有空洞。

原文还留下一个值得谨慎对待的排版问题：B/F 表格把 Begin Frame 与 Final Frame 都印成了 1,0，而紧邻表格上方的定义明确说 F 置位表示最终部分。本文以文字定义说明 B/F，不把重复表格行包装成第二条规则。若要判断某个实现怎样处理这一处，必须查代码、测试或抓包；现有来源没有提供这些材料。

FCS 选项把证据边界说得更清楚。对于传输的 HDLC 类帧，SDTP 只搬运两个 Flag 之间的内容，Flag 本身不搬运；内部 FCS 默认随帧传输。协商 FCS-Type 后，发送端可以移除 FCS，由接收端重新生成。RFC 1963 随即警告：除非启用 PPP Reliable Transmission 或另有能够可靠通知丢包的下层，否则不应重新生成 FCS；实现也不得把不完整或错误的帧配上新的正确 FCS 后交给用户。

这条警告等于承认：SDTP 自己的 B/F、Length 与 Port 不是完整性证明。丢失一个中间分组而没有外部丢包通知时，接收端可能看见一个外形完整、语法可解析的结果。若此时再生成正确校验值，缺失会被伪装成整洁。

RFC 1663 用另行协商的 Numbered-Mode、窗口、确认和重传处理可靠串行链路；RFC 1962 处理压缩算法协商与 Reset。它们都不属于本文的 SDTP 线格式。Header-Last 只是配合压缩器作出分段决定的时机，不是压缩协议本身，更不是可靠交付机制。

按照 Lu Heng 对“声明”与“可执行证据”的区分，RFC 1963 的贡献是一套最小公共语法：字段在哪里、怎样确定扩展、怎样标出边界、怎样划分长度、怎样选择端口。运行系统仍要分别证明到达顺序、丢失处理、缓存清理、端口映射、FCS 策略与用户侧交付。格式可以让问题变得可判定，但不能替接收端给出答案。

来源