数据链路层 — 把会出错的线变成无差错的链路¶

这一章讲一件事: 物理层交上来的只是一串可能传错的比特,链路层怎么把它加工成上层能放心用的「无差错链路」。答案是五个机制:成帧(把比特流切成一帧一帧)、检错(给每帧配 CRC 校验码)、确认重传(收对了回话、丢了重发)、编号(区分新帧和重传帧)、流量控制(别让发方把收方淹没)。这一章也是全书第一次完整走一遍「协议怎么设计」:从理想假设出发,每拿掉一个假设就补一个机制, 最后得到能跑在真实链路上的实用协议。

1. 为什么需要这一层¶

物理层传比特,但它不知道比特的意义和结构,也不能对传输进行控制和管理¹。真实线路上的问题,书里列了五类:

差错——噪声让某些比特传错、甚至整帧丢失;
速率不匹配——发方快、收方慢,收方的缓冲区溢出,数据被丢;
寻址——多点线路(一根总线挂多台机器)上,得让每台机器知道这帧是不是给自己的;
帧同步——收方得能从连续的比特流里认出「一帧从哪开始、到哪结束」;
链路管理——通信前要通知对方做准备,结束后要释放资源²。

链路层的合同因此是: 把「原始的、有差错的物理线路」变成对网络层表现的「一条无差错的数据链路」³。注意「表现」二字——底下照样错,只是错的部分全被这一层拦住、补掉了,网络层完全看不见。

2. 顶层全景:协议设计的五步推导¶

主线例子(贯穿本章): 结点 A 向结点 B 传一个文件,链路是 64Kb/s、传播时延 270ms 的卫星信道(书里的例 3-4 同款参数),帧长 4000bit。我们就用这个「又慢又远」的链路, 把链路层协议从零推导出来:

  第 0 版:信道理想(不出错、收方永远来得及)── 直接发,不需要协议
  第 1 版:拿掉「收方来得及」 ── 每发一帧等一个确认(停等),流量控制诞生
  第 2 版:再拿掉「不出错」 ── 错帧重传 + 超时计时器,差错控制诞生
  第 3 版:帧会丢、确认会丢 ── 帧编号,解决重复帧;超时时间要选好
  第 4 版:等确认太浪费 ── 连续发 N 帧(滑动窗口),ARQ 家族诞生

下面 3.3 到 3.6 就是这条推导,3.7 给它算效率账,3.8 看真实协议长什么样。

3. 核心原理¶

3.1 链路层站在哪:模型与三种服务¶

链路层的业务环境:它下面是一条(可能出错的)物理链路,上面是网络层; 它给网络层提供的服务分三档⁴:

服务	建连接?	每帧确认?	谁在用
已确认的面向连接服务	要(建链、传数据、释链三阶段)	要	大多数广域网通信子网
已确认的无连接服务	不要	要(每帧编号+确认)	有确认需求的不可靠信道
未确认的无连接服务	不要	不要(错了由高层管)	大多数局域网、误码率低且实时性要求高的场景

第三档值得停一下:以太网就是「未确认的无连接服务」——网卡发完一帧就不管了, 没有确认、没有重传,错了由高层(TCP 或应用自己)负责。这是后文第 04 章的重要伏笔: 局域网误码率低(<10⁻⁸),为每一帧付确认的开销不划算;而广域网链路 historically 误码率高, 所以链路层就地把可靠性做足。

3.2 差错检测:给数据配「验错的尾巴」¶

差错从哪来。 热噪声(电子热运动)造成孤立的随机错;冲击噪声(外界电磁干扰, 一次电火花约 10ms)造成成片连续的突发错误——在 4800b/s 的线路上, 10ms 就是连续 48 个比特全错⁵。突发错误的严重度用「突发长度」描述: 从第一个错码到最后一个错码之间的比特数。

两条检错路线⁶:

纠错码(FEC,前向纠错):冗余信息多到收方自己能定位并改正错误。好处是不回传, 坏处是冗余大、实现难——只在单工信道(如深空通信)等无法请对方重传的场合用;
检错码:冗余只够收方判断「这帧错了」,然后请求重传。实现简单、速度快, 是计算机网络的主流。代价是要一条「回话」的信道——双向链路才有条件用。

衡量检错码的指标是编码效率 R = k/(k+r):k 个信息位,r 个冗余位, R 越大信道利用率越高⁷。

奇偶校验是最简单的检错码:7 位 ASCII 后加 1 位,让整组 1 的个数恒为奇数(奇校验)或偶数(偶校验),收方数一遍就知道有没有一位出错。三个版本层层加码⁸:

垂直奇偶校验:每个字符(每列)配一位——能查出一列里的奇数个错,漏检率接近 1/2 (突发错误里奇偶位错概率几乎各半),编码效率 8/9;
水平奇偶校验:按行配校验位——能检出突发长度 ≤ p(行数)的突发错,漏检率大幅下降; 缺点是整个信息块到齐才能算校验位,必须缓冲;
水平垂直(纵横)校验:两个方向同时校——能检出所有 3 位以内错、突发长度 ≤ p+1 的突发错,还能纠正单比特错(行列交叉定位),可使误码率降到原来的 1/100~1/10000。

CRC(循环冗余码)是真正扛活的那位。 奇偶校验漏检率太高,网络实际用的是 CRC, 它的数学外衣是多项式:任何一个二进制串都唯一对应一个 0/1 系数的多项式 (如 1010111 ↔ X⁶+X⁴+X²+X+1)⁹。操作三步:

收发双方预先约定一个生成多项式 G(X)(r 次,共 r+1 位),如 CRC-32;
发送方:把 k 位信息位 K(X) 后面补 r 个 0,用模 2 除法(=异或运算,不进位不借位) 除以 G(X),得的 r 位余数就是冗余位 R(X),拼在信息位后发出——整串 T(X) = XʳK(X)+R(X) 必能被 G(X) 整除¹⁰;
接收方:把收到的串同样除以 G(X),余数为 0 就认为没错,非 0 必有错,丢弃并请重传。

书里的例 3-1 走一遍全过程¹¹:信息位 1011001(K(X)=X⁶+X⁴+X³+1),G(X)=X⁴+X³+1(11001), 补 4 个 0 得 10110010000,模 2 除 11001,得余数 1010——这就是冗余位; 发出的码字是 10110011010。收方拿它再除 11001,余 0,通过。

为什么有效: 若传输引入差错 E(X),收到的就是 T(X)+E(X)(模 2 加); 若 E(X) 不能被 G(X) 整除,余数非零,检出¹²。理论上可以证明 CRC 能检出: 所有奇数位错、所有 ≤r 位的突发错¹³。生成多项式的位数越多校验能力越强, 但不是随便一个数都行——广泛使用的几个:CRC-16(IBM)、CRC-16(CCITT)、CRC-32 (后者就是以太网帧校验和背后的多项式,第 04 章会见到它的工作岗位)¹⁴。

为什么用模 2 运算: 模 2 加减都是异或,没有进位借位,硬件用一个移位寄存器加异或门就能并行算完——CRC 校验器是纯粹的硬件,不耗 CPU。「复杂数学 + 简单硬件」是 CRC 统治链路层四十年的原因。

3.3 停等协议:每发一帧,等一声「收到」¶

现在回到主线例子的推导。第 1 版:拿掉「收方永远来得及」。 如果发方一口气把帧全倒给收方,收方缓冲区一溢出,后面的帧全丢。最简单的办法:发方每发一帧就停下来,等收方回一个确认帧(ACK),收到确认才发下一帧¹⁵。发方的发送速率因此被收方的处理速率钳住——这就是流量控制:用反馈机制, 让接收方控制发送方的节奏。

第 2 版:再拿掉「信道不出错」。 帧可能传错,收方验出 CRC 错就回一个否认帧(NAK), 发方重传该帧;为此发方必须保留已发帧的副本,直到确认到达¹⁶。

第 3 版:帧和确认都会丢。 帧丢了,收方根本不知道要回确认;确认自己也可能丢—— 发方永远等下去,死锁。解法:超时计时器。发方每发一帧启动一个计时器, 超时未收到确认就重传¹⁷。

超时时间怎么定?书里给的原则:略大于「从发送完毕到收到确认的平均时间」¹⁸。太长则浪费时间,太短则确认还在路上就重传,白白制造重复帧。

重复帧怎么办:帧编号。 确认丢了→超时重传→收方会收到两个一模一样的帧, 如果照单全收,数据就重复了。解法:每帧带一个发送序号,收方发现序号重复, 就丢弃副本(但仍然回一个确认——因为发方显然没收到上次的确认)¹⁹。序号占的比特越少开销越小;停等协议一次只有一帧在路上,1 比特序号(交替 0/1)就够—— 这是「协议状态最少需要多少信息」的第一个实例,后面 TCP 的 32 位序号是它的直系后代。

停等协议的四种情况(书里的图 3-8):正常送达;帧出错(NAK 重传);帧丢失(超时重传); 确认丢失(超时重传,收方靠编号去重)。实用停等协议的全部秘密,就在这张图里²⁰。

3.4 滑动窗口:别干等,一次发一批¶

停等协议的毛病主线例子立刻暴露:卫星链路传播时延 270ms、往返 540ms, 而 4000bit 的帧在 64Kb/s 上发送只要 62.5ms。发一帧 62.5ms、干等 540ms, 链路利用率只有 10% 左右(书里的例 3-4 算出 E≈0.104)²¹。光缆上跑停等,等于花大钱修了高速路然后只允许一辆车上去。

滑动窗口协议的解法是允许连续发送:发方维护一个「发送窗口」——一组连续的帧号, 窗口内的帧可以不等待确认连续发;每收到一个确认,窗口前沿就向前滑一格, 新的帧号落进窗口继续发²²。收方对称地维护「接收窗口」,只有落在窗口内的帧才收。

窗口尺寸 = 还没收到确认时,发方最多能发多少帧——它直接就是流量控制的旋钮, 也是信道上「同时在飞」的帧数上限。回到第 01 章的时延带宽积: 窗口能开多大,物理上受「带宽 × 往返时延」限制;协议上则受「序号空间」限制,下面 3.6 会看到。

3.5 ARQ 两兄弟:错了之后,回退多少¶

连续发送之后,出错怎么办?两种策略,也就是两个协议:

连续 ARQ(回退 N 帧 ARQ)。收方只按顺序接收;一旦发现第 2 号帧有错, 第 2 号之后已正确到达的 3、4、5、6…… 号帧也全部丢弃,发方超时后从第 2 号开始整批重传²³。条件:接收窗口 = 1。代价看起来浪费(白收了的帧被扔),实现却极简单: 收方不需要缓冲任何失序帧,错一个就回 NAK2 或对 2 号沉默等超时,发方一律「从 2 号重来」。

发送窗口的上限在这里出现:n 位序号(共 2ⁿ 个号),发送窗口最大只能 2ⁿ−1。书里给了一个非常具体的反例²⁴:n=3(序号 0~7),若窗口取 8,推进到窗口含「1,2,3,4,5,6,7,0」时收到一个 ACK1——它可能表示「1 号已收,请发 2 号起的新帧」 (全部 8 帧都收妥),也可能表示「1 号刚收」(其余都没收到)。发方无法区分, 协议就塌了。窗口取 7 则永远能区分新旧——这就是为什么序号空间必须比窗口大 1。

选择重传 ARQ。如果收方窗口也开大(>1),失序到达的正确帧先存进缓冲区, 只请发方重传出错的那一帧,凑齐后再按序上交高层²⁴。代价是收方要缓冲、协议更复杂, 换来的是链路利用率的大幅提升。

三个协议一张表(书里的表 3-1)²⁵:

协议	发送窗口	接收窗口	出错时的动作
停止等待	1	1	重传这一帧
连续 ARQ	>1	1	从出错帧起全部重传
选择重传 ARQ	>1	>1	只重传出错帧

选择重传的窗口上限更严:接收窗口最大只能是序号空间的一半(2ⁿ⁻¹)。书里的例 3-3 演示了违反它的灾难²⁶:收发窗口都取 7、序号 3 位,确认丢失后重传的旧 0 号帧, 恰好落在新接收窗口(7,0,1,2,3,4,5)里,被误当成新帧收下——旧帧当新帧,数据损坏。窗口取一半,新窗口和旧窗口就永远不会重叠,旧帧永远不会被误认为新帧。

3.6 效率分析:把「等确认」折算成利用率¶

协议好不好,账要算得出来。停等协议的利用率推导(书里式 3-1 到 3-8)²⁷: 设帧的发送时间 tf(帧长÷速率)、传播时延 tp,则一帧「发完 + 确认回来」的周期 tT = tf + 2tp。无差错时利用率:

  E = tf / tT = 1 / a,   其中 a = tT / tf = 1 + 2tp/tf

记主线例子的账:tf = 4000bit ÷ 64Kb/s = 62.5ms,tT = 62.5 + 2×270 = 602.5ms, a ≈ 9.64,E ≈ 0.104——卫星链路上跑停等,九成时间在等²⁸。 a 接近 1(传播时延远小于发送时延,比如同机房的短网线)时效率才高。这条公式解释了一个经验法则:「链路越长越快,停等越没法用」。

有差错时,设帧出错(含丢失)概率 P、重传不限次,成功一帧平均要 1/(1−P) 个周期, E 再乘一个 (1−P)²⁹。

连续 ARQ 的效率书里给了归一化有效数据率公式(式 3-10)³⁰:

  U = ld/(ld+lh) × (1−P) / (1+(a−1)P) ≤ 1
  (ld = 帧的数据位,lh = 帧的控制位)

两个因子各有含义:前一个因子是帧长对效率的影响——帧越短,固定长度的头尾占比越大, 有效利用率越低;后一个因子是差错的影响。它还解释了为什么以太网既规定最短帧长 (64B,为冲突检测,第 04 章)又规定最长帧长(1500B 数据上限,防止个别帧霸占信道): 太短效率低,太长出错重传一次的代价大。帧长是两头受气的中间最优。

3.7 HDLC:一个面向比特的真实协议¶

ARQ 是思想,HDLC(高级数据链路控制)是落地。它 1974 年由 IBM 的 SDLC 演化而来, ISO 收编为国际标准,CCITT 改出 LAP/LAPB——X.25 网的链路层就是 LAPB³¹。

HDLC 的帧结构是「标志—地址—控制—信息—校验—标志」六段³²:

  01111110 | 地址 A(8位) | 控制 C(8位) | 信息 Info(变长) | FCS(16位) | 01111110
  ─ 标志F ─┴──────── 校验区间 ────────┴──────────

  图说:首尾两个标志就是帧的栅栏;FCS 用 CRC-16(x¹⁶+x¹²+x⁵+1),校验地址、控制、信息三段。

两个精巧的设计:

帧边界与透明传输——0 比特填充。标志是 01111110,如果数据里恰好出现这个模式, 就会被误当帧尾。HDLC 的办法:发送方发现数据里有 5 个连续的 1,就强制插入一个 0; 接收方看到 5 个 1 后的 0 就删掉³³。这样不管数据是什么比特组合,都不可能冒充标志—— 这就是 3.1 说的「透明传输」问题的解法(协议功能五:数据和控制信息的识别)。
控制字段一物三用。C 字段前两位把帧分成三类:信息帧 I(带编号 N(S)、确认编号 N(R))、监督帧 S、无编号帧 U。S 帧四种³⁴:

S 帧	含义	扮演的角色
RR 接收就绪	确认 N(R)−1 及以前全部收到	ACK
RNR 接收未就绪	同上确认,但「暂停喂我」	带确认的流控
REJ 拒绝	从 N(R) 起都重来	连续 ARQ 的 NAK
SREJ 选择拒绝	只重传 N(R) 这一帧	选择重传的 NAK

链路建立与释放(平衡配置):任一方发 SABM 命令,对方回 UA 确认,链路建好; 任一方发 DISC,对方回 UA,链路释放³⁵。

3.8 PPP:Internet 的链路层¶

HDLC 是历史课本,PPP(点到点协议)至今活着。它是 Internet 正式标准(RFC 1661), 1980 年代的 SLIP 的替代者——SLIP 没有差错检测、不支持多种协议,PPP 全补上³⁶。

PPP 的三个组成部分:

成帧:把 IP 数据报封装进串行链路,既支持异步链路也支持同步链路, 信息字段上限受 MRU(最大接收单元,默认 1500B)限制;
LCP(链路控制协议):建立、配置、测试链路连接,双方协商选项(最大帧长、认证协议等);
NCP(网络控制协议):为每一种网络层协议(IP、IPX、AppleTalk……)各配一个, 配置其选项、建立逻辑连接——一条 PPP 链路上可以同时跑多种网络层协议³⁷。

PPP 的帧格式像 HDLC 的字节版³⁸:标志 0x7E、地址固定 0xFF(广播地址,点到点链路无所谓寻址)、控制固定 0x03(无编号帧,默认不用序号和确认)、协议字段 2 字节(0x0021=IP 数据报, 0xC021=LCP 数据)、FCS 2 字节。

透明传输按链路性质分两派:同步链路用 HDLC 同款 0 比特填充(硬件做); 异步链路用字节填充——数据里的 0x7E 换成 (0x7D,0x5E),0x7D 换成 (0x7D,0x5D), 小于 0x20 的控制字符前也加 0x7D 并改码³⁹。

PPP 的工作状态机(书里的图 3-17)是本节最该带走的东西, 因为它展示了「一个协议 = 一张状态图」的通用形态:

  静止(无物理连接) ──载波检测到──▶ 建立 ──LCP 协商成功──▶ 身份验证(可选)
      ▲                                                    │
      └──载波停止── 终止 ◀──LCP 释放── 打开 ◀──NCP 配置成功──┘
                                   (数据传输在这里)

  图说:物理连接先建立;LCP 协商链路和认证;NCP 分配临时 IP;然后才进入数据传输。

主线例子的现实版: 你的电脑通过 PPPoE 拨号上网,走的就是这条流水线—— Modem 确认(物理层)、LCP 协商和运营商认证(用户名密码)、NCP 分给你一个临时公网 IP、然后浏览器的数据包才能上路;下线时 NCP 收回 IP、LCP 拆链路、最后断载波⁴⁰。 PPPoE 做的事只有一件:把 PPP 帧再套进以太网帧(RFC 2516), 于是「以太网的便利 + PPP 的接入控制与计费」兼得——小区宽带二十多年的标配⁴¹。

PPP 不提供纠错——只有 CRC 检错、错了就丢帧,没有序号和确认⁴²。「尽力而为」的哲学从 IP 下沉到了链路层:误码率极低的光纤时代,链路层纠错是多余的开销, 可靠性统一由端到端的 TCP 收拾。

3.9 链路层六功能与 PPP 状态机的细节补遗¶

六功能逐条(3.1 的清单展开)⁴⁶:

链路管理:面向连接服务专属——建链(交换必要信息)、维持(传输中)、释链(释放缓冲区与变量);
帧同步:收方必须能从比特流里认出帧的首尾(标志、前导码等机制);
流量控制:反馈机制——「我忙,别发了」「我有空了,继续」;
差错控制:检错(奇偶/CRC)+ 重传(ARQ),把位错与帧错都压住;
透明传输:数据里出现与控制信息相同的比特组合时,不许被误读为控制信息 (0 比特填充/字节填充就是干这个);
寻址:让帧到达正确的机器,并让收方知道是谁发的。

滑动窗口的八步图解(书里的图 3-9,发送窗口 2、接收窗口 1)⁴⁷:

  ① 初态:发送窗口前后沿重合(没帧在飞);接收方打开 0 号窗等 0 号帧
  ② 发 0 号:发送窗口含 {0},等确认
  ③ 发 1 号:窗口满 {0,1},停发
  ④ 收 0 号:接收窗口滑到 {1}
  ⑤ 收 ACK0:发送窗口滑到 {1,2},0 号从重传表删除
  ⑥ 发 2 号:窗口 {1,2} 又满
  ⑦ 收 1 号:接收窗口滑到 {2}
  ⑧ 收 ACK1:发送窗口滑到 {2,3}

规律一眼可见:发送窗口的滑动由「收到确认」驱动,接收窗口的滑动由「收到帧」驱动; 窗口不动,发送方就停——流量控制与可靠性共用一套机制,这是滑动窗口设计最经济的地方。

PPP 的链路质量监控(LCP 的隐藏职责)⁴⁸:PPP 不只是「拨号上网」的别名。 LCP 协商的 11 种分组里包括链路质量报告——运行中可以双方互报丢包统计, 链路太差时主动拆链。结合 NCP 的多协议支持,PPP 的设计哲学一句话: 「链路上没有什么是不能协商的」——地址、认证方式、最大帧长、甚至魔法数(检测环路)。这套「先协商、后干活」的握手范式,后来几乎成了所有拨号与点对点链路协议的标准开场。

4. 作者的判断与证据¶

「检错码优于纠错码」:依据是 FEC 实现困难而检错码「原理简单、实现容易、编码与解码速度快」——这是链路层的技术选型判断,不是数学结论⁴³。
「选择重传优于回退 N」的隐含立场:书里明说连续 ARQ「效率很低」并大篇幅介绍选择重传,但随即指出其窗口受限更严——两个机制是权衡关系,不是替代关系⁴⁴。
PPP「不可靠」是特性不是缺陷:书末点明不提供纠错、不用序号确认⁴⁵, 与第 01 章「端到端可靠性」的立场完全自洽——可以看作全书主线的又一次兑现。

5. 边界与局限¶

ARQ 效率公式是理想模型:饱和发送、差错独立分布,实际链路的突发错误会让回退 N 的表现比公式差得多。
HDLC/LAPB 今天只剩存量:X.25 网基本退役,这一节的价值在于「看一个完整协议怎么组织帧格式、状态机、监督帧」——后来几乎每个链路/传输协议都有它的影子。
选择重传的缓冲区管理一笔带过:真实的实现要处理「缓冲区满时新到帧怎么办」, 书里停在原理层。
没有讲以太网的 MAC 子层(那是第 04 章的主角),也没有讲 Wi-Fi 的链路层确认 (802.11 其实是有确认的链路层,与以太网相反)——「局域网大多用无确认服务」的说法有例外,读第 04 章时要留意。

判断(我们的,不是书里的): 这一章教的其实是「协议设计方法论」本身: 从理想假设出发逐条拿掉、每拿掉一条补一个机制、最后给每个机制算效率账。这套推导法比 HDLC 的帧格式值钱得多——写任何通信协议(包括应用层的自定义协议) 都该走一遍同样的五步。另外,停等协议 10% 利用率那个算例,是理解后面 TCP 滑动窗口与拥塞控制的物理地基:窗口的存在意义,就是消灭「发一帧等一圈」的空转。 如果错,会错在: 真实系统越来越多地把可靠性交给端到端(TCP/QUIC), 链路层 ARQ 的教学权重正在下降;若读者只面向现代以太网,本章的卫星链路场景会显得遥远——但窗口/序号的数学约束(TCP 一样遵守)不会因场景变化而失效。

6. 可带走的¶

链路层的合同:把会出错的物理线路,变成对上层无差错的逻辑链路;
五大问题五机制:差错→CRC+重传,速率不匹配→停等/窗口,多点寻址→地址字段, 帧同步→标志+填充,链路管理→建链/释链状态机;
CRC 的本质是「模 2 除法求余」:发的串能被 G(X) 整除,余数非 0 必有错; 检所有奇数位错和所有 ≤r 位突发错;
停等协议的利用率 E = 1/a,a = 1+2tp/tf——传播时延大时链路九成时间在空转;
帧编号 1 比特就够(停等),连续 ARQ 窗口 ≤ 2ⁿ−1,选择重传窗口 ≤ 2ⁿ⁻¹—— 序号空间必须能区分新旧窗口;
回退 N 简单费带宽,选择重传省带宽费缓冲——按链路误码率选;
HDLC 的 0 比特填充解决「数据冒充标志」;S 帧四种 = ACK / 流控 / 两种 NAK;
PPP = 成帧 + LCP(链路协商) + NCP(网络层配置);不提供纠错,可靠性交给上层;
PPPoE = PPP 帧套以太网帧,为了接入控制与计费——你家宽带背后的协议;
「协议 = 状态图 + 帧格式 + 计时器」:PPP 的静止/建立/验证/打开/终止是通用样板。

7. 原文地图¶

主题	原书章	原文位置
为什么设链路层、五大问题	第3章数据链路层	`text/03-ch03.txt:15`(搜「差错问题」) · `text/03-ch03.txt:25`(搜「物理层仅接收和传输位流」)
三种链路服务	第3章数据链路层	`text/03-ch03.txt:42`(搜「已确认的面向连接服务」) · `text/03-ch03.txt:50`(搜「未确认的无连接服务」)
差错起因:随机错与突发错	第3章数据链路层	`text/03-ch03.txt:100`(搜「冲击噪声」) · `text/03-ch03.txt:107`(搜「48 位」)
检错码 vs 纠错码、编码效率	第3章数据链路层	`text/03-ch03.txt:114`(搜「纠错码」) · `text/03-ch03.txt:123`(搜「编码效率」)
奇偶校验三种	第3章数据链路层	`text/03-ch03.txt:141`(搜「垂直奇偶校验」) · `text/03-ch03.txt:162`(搜「水平奇偶校验」) · `text/03-ch03.txt:191`(搜「水平垂直奇偶校验」)
CRC 原理、例 3-1/3-2、生成多项式	第3章数据链路层	`text/03-ch03.txt:214`(搜「循环冗余码」) · `text/03-ch03.txt:227`(搜「例 3-1」) · `text/03-ch03.txt:287`(搜「检错能力」) · `text/03-ch03.txt:297`(搜「CRC32」)
停等协议推导、超时、帧编号	第3章数据链路层	`text/03-ch03.txt:311`(搜「停止等待协议」) · `text/03-ch03.txt:325`(搜「每发送一帧数据就停下来等待」) · `text/03-ch03.txt:389`(搜「超时计时器」) · `text/03-ch03.txt:396`(搜「帧编号」)
滑动窗口	第3章数据链路层	`text/03-ch03.txt:410`(搜「滑动窗口」) · `text/03-ch03.txt:422`(搜「发送窗口」)
连续 ARQ 与窗口上限 2ⁿ−1	第3章数据链路层	`text/03-ch03.txt:464`(搜「连续 ARQ 协议的基本思想」) · `text/03-ch03.txt:484`(搜「回退 N 帧」) · `text/03-ch03.txt:487`(搜「2n−1」)
选择重传与窗口上限一半、例 3-3	第3章数据链路层	`text/03-ch03.txt:494`(搜「选择重传 ARQ 协议」) · `text/03-ch03.txt:530`(搜「例 3-3」) · `text/03-ch03.txt:545`(搜「一半」)
三协议对比表	第3章数据链路层	`text/03-ch03.txt:552`(搜「3 种协议的区别」)
停等效率公式与例 3-4	第3章数据链路层	`text/03-ch03.txt:564`(搜「停等协议的效率」) · `text/03-ch03.txt:631`(搜「0.104」)
连续 ARQ 效率公式	第3章数据链路层	`text/03-ch03.txt:635`(搜「连续 ARQ 协议的效率」) · `text/03-ch03.txt:655`(搜「帧长对信道利用率的影响」)
HDLC 帧结构、0 比特填充、S 帧	第3章数据链路层	`text/03-ch03.txt:661`(搜「高级数据链路控制」) · `text/03-ch03.txt:678`(搜「帧结构」) · `text/03-ch03.txt:702`(搜「0 比特填充」) · `text/03-ch03.txt:731`(搜「RR」)
SABM/UA 建链释放	第3章数据链路层	`text/03-ch03.txt:747`(搜「SABM」)
PPP 组成、帧格式、字节填充	第3章数据链路层	`text/03-ch03.txt:757`(搜「PPP」) · `text/03-ch03.txt:764`(搜「3 个组成部分」) · `text/03-ch03.txt:777`(搜「帧格式」) · `text/03-ch03.txt:816`(搜「字符填充」)
PPP 工作状态与 PPPoE	第3章数据链路层	`text/03-ch03.txt:821`(搜「工作状态」) · `text/03-ch03.txt:848`(搜「PPPoE」)
PPP 不提供纠错	第3章数据链路层	`text/03-ch03.txt:834`(搜「不提供纠错」)

出处:「数据链路层的基本概念」第 25 段(text/03-ch03.txt:25,搜「物理层仅接收和传输位流」)。 ↩
出处:「数据链路层的基本概念」第 13–24 段(text/03-ch03.txt:14,搜「主要包括以下几个方面」;text/03-ch03.txt:19,搜「寻址问题」;text/03-ch03.txt:22,搜「链路管理问题」)。 ↩
出处:「数据链路层的基本概念」第 3 段(text/03-ch03.txt:3,搜「无差错的数据链路」)。 ↩
出处:「数据链路层的基本概念」第 40–53 段(text/03-ch03.txt:42,搜「已确认的面向连接服务」;text/03-ch03.txt:50,搜「未确认的无连接服务」)。 ↩
出处:「差错的起因和检测」第 99–109 段(text/03-ch03.txt:107,搜「48 位」)。 ↩
出处:「差错的起因和检测」第 113–121 段(text/03-ch03.txt:114,搜「纠错码」;text/03-ch03.txt:116,搜「检错码」)。 ↩
出处:「差错的起因和检测」第 123–129 段(text/03-ch03.txt:123,搜「编码效率」)。 ↩
出处:「常用的简单差错检测编码」第 139–213 段(text/03-ch03.txt:144,搜「垂直奇偶校验」;text/03-ch03.txt:161,搜「漏检率接近」;text/03-ch03.txt:191,搜「水平垂直奇偶校验」;text/03-ch03.txt:210,搜「误码率降至」)。 ↩
出处:「循环冗余码」第 219–222 段(text/03-ch03.txt:220,搜「多项式」)。 ↩
出处:「循环冗余码」第 232–241 段(text/03-ch03.txt:222,搜「生成多项式」;text/03-ch03.txt:239,搜「模 2」)。 ↩
出处:「循环冗余码」例 3-1(text/03-ch03.txt:227,搜「例 3-1」;text/03-ch03.txt:245,搜「1010」)。 ↩
出处:「循环冗余码」例 3-2 与差错模式分析(text/03-ch03.txt:262,搜「例 3-2」;text/03-ch03.txt:286,搜「漏检」)。 ↩
出处:「循环冗余码」第 287–290 段(text/03-ch03.txt:288,搜「奇数位错」)。 ↩
出处:「循环冗余码」第 291–297 段(text/03-ch03.txt:297,搜「CRC32」)。 ↩
出处:「具有简单流量控制的数据链路层协议」第 323–328 段(text/03-ch03.txt:325,搜「每发送一帧数据就停下来等待」)。 ↩
出处:「实用的停等协议」第 363–369 段(text/03-ch03.txt:367,搜「否认帧」;text/03-ch03.txt:369,搜「副本」)。 ↩
出处:「实用的停等协议」第 371–375 段(text/03-ch03.txt:375,搜「死锁」)。 ↩
出处:「实用的停等协议」第 389–394 段(text/03-ch03.txt:394,搜「平均时间」)。 ↩
出处:「实用的停等协议」第 396–406 段(text/03-ch03.txt:400,搜「发送序号」;text/03-ch03.txt:406,搜「一个比特」)。 ↩
出处:「实用的停等协议」第 361–375 段(text/03-ch03.txt:363,搜「4 种情况」)。 ↩
出处:「协议的效率分析」例 3-4(text/03-ch03.txt:631,搜「0.104」;text/03-ch03.txt:624,搜「62.5」)。 ↩
出处:「滑动窗口协议」第 410–426 段(text/03-ch03.txt:422,搜「发送窗口」;text/03-ch03.txt:424,搜「接收窗口」)。 ↩
出处:「连续 ARQ 协议」第 462–484 段(text/03-ch03.txt:480,搜「丢弃」;text/03-ch03.txt:484,搜「回退 N 帧」)。 ↩
出处:「连续 ARQ 协议」第 487–493 段(text/03-ch03.txt:493,搜「2n−1」)。 ↩↩
出处:「选择重传 ARQ 协议」第 494–560 段(text/03-ch03.txt:550,搜「表 3-1」)。 ↩
出处:「选择重传 ARQ 协议」例 3-3(text/03-ch03.txt:530,搜「例 3-3」;text/03-ch03.txt:545,搜「一半」)。 ↩
出处:「协议的效率分析」第 564–622 段(text/03-ch03.txt:591,搜「tout」;text/03-ch03.txt:601,搜「1− P」)。 ↩
出处:「协议的效率分析」例 3-4(text/03-ch03.txt:631,搜「0.104」)。 ↩
出处:「协议的效率分析」第 597–606 段(text/03-ch03.txt:601,搜「tT」)。 ↩
出处:「连续 ARQ 协议的效率」第 645–655 段(text/03-ch03.txt:650,搜「链路容量」)。 ↩
出处:「高级数据链路控制协议」第 663–673 段(text/03-ch03.txt:669,搜「SDLC」;text/03-ch03.txt:672,搜「LAPB」)。 ↩
出处:「HDLC 的帧结构」第 675–695 段(text/03-ch03.txt:678,搜「帧结构」;text/03-ch03.txt:699,搜「标志字段」)。 ↩
出处:「HDLC 的帧结构」第 701–706 段(text/03-ch03.txt:702,搜「0 比特填充」)。 ↩
出处:「HDLC 的帧结构」第 723–727 段(text/03-ch03.txt:725,搜「信息帧」)与表 3-2(text/03-ch03.txt:731,搜「RR」)。 ↩
出处:「HDLC 的帧结构」第 746–751 段(text/03-ch03.txt:747,搜「SABM」)。 ↩
出处:「Internet 的数据链路层协议」第 754–763 段(text/03-ch03.txt:759,搜「SLIP」;text/03-ch03.txt:763,搜「RFC 1661」)。 ↩
出处:「Internet 的数据链路层协议」第 764–775 段(text/03-ch03.txt:764,搜「3 个组成部分」;text/03-ch03.txt:769,搜「LCP」)。 ↩
出处:「PPP 的帧格式」第 777–788 段(text/03-ch03.txt:785,搜「0x7E」)。 ↩
出处:「PPP 的链路控制」第 815–819 段(text/03-ch03.txt:817,搜「0x7D」)。 ↩
出处:「PPP 的链路控制」第 821–840 段(text/03-ch03.txt:826,搜「建立状态」;text/03-ch03.txt:830,搜「临时的 IP 地址」)。 ↩
出处:「PPP 的应用」第 844–855 段(text/03-ch03.txt:848,搜「RFC 2516」)。 ↩
出处:「PPP 的链路控制」第 834 段(text/03-ch03.txt:834,搜「不提供纠错」)。 ↩
出处:「差错的起因和检测」第 119–121 段(text/03-ch03.txt:120,搜「实现困难」)。 ↩
出处:「连续 ARQ 协议的效率」第 637–638 段(text/03-ch03.txt:637,搜「效率很低」)。 ↩
出处:「PPP 的链路控制」第 834 段(text/03-ch03.txt:834,搜「不可靠的传输协议」)。 ↩
出处:「数据链路层的基本概念」第 55–89 段(text/03-ch03.txt:61,搜「建立、维持和释放」;text/03-ch03.txt:63,搜「帧同步」;text/03-ch03.txt:84,搜「透明传输」)。 ↩
出处:「滑动窗口协议」第 427–460 段(text/03-ch03.txt:436,搜「初态」)。 ↩
出处:「Internet 的数据链路层协议」第 764–769 段(text/03-ch03.txt:770,搜「11 种类型」)。 ↩