引言：除了连通，我们还需要安全和效率
之前的章节，我们掌握了 PPP 如何建立链路（LCP）和配置网络（NCP）。但只通了是不够的。
- 安全怎么办？ 如果网络里都是明文的密码，那这个网络就是个筛子。
- 效率怎么办？ 如果在 56k 的“蜗牛”电话线路上，每次发一个 1 字节的确认包，还得带上 40 字节的网络包裹信息，效率低得令人发指。
今天这两页书，正是 PPP 协议组在解决这两大核心痛点的重磅方案。
第一部分：从“举手宣誓”到“加密暗号”—— PPP 安全认证的终极进化
我们上次提到了 PAP 的致命弱点——直接把密码贴在脑门上。为了弥补这个漏洞，PPP 协议群引进了两位真正的“安全保镖”：CHAP 和 EAP。
1.1 CHAP：挑战与应答的“加密暗号”
CHAP（质询握手认证协议） 彻底抛弃了“说密码”的方式，转而采用一种数学暗号。
- 它的工作流程（非常像间谍对暗号）：
- 发起挑战：服务器随机生成一串数字（我们叫它“挑战值”），发给客户端。
- 计算响应：客户端收到这个挑战值后，用自己私有的密码和这个挑战值，通过一个单向哈希算法，计算出一个结果（哈希值），发回给服务器。注意：在这个过程中，客户端并没有发送真正的密码！它发送的只是算出来的结果。
- 验证结果：服务器手里也存着这个客户端对应的正确密码。它用同样的方法，用挑战值和密码算出结果，和客户端发来的结果一比对。如果一致，认证通过。
- 为什么它牢不可破？ 因为每次认证时，服务器发给客户端的“挑战值”都是随机的。即使有黑客抓取到了这次连接的所有数据包，他也无法拿着这次的“结果”去冒充，因为下一次服务器会发给客户端一个全新的随机挑战值。这就是 “防重放攻击”。
1.2 EAP：万能插槽与 RADIUS 服务器
如果说 CHAP 是一种具体的加密算法，那么 EAP（可扩展认证协议） 就是一个“万能认证插槽”。它自己不认证，但它定义了认证信息该如何封装和传输。
- 万能插槽：EAP 框架支持无数种认证方法。不管你是用最基础的 PAP/CHAP，还是用高级的 智能卡、生物指纹识别、数字证书，都可以通过 EAP 的格式打包。
- 与 RADIUS 的黄金搭档：在大型企业或 ISP 中，常常会把 EAP 认证信息转发给后端的 RADIUS 认证服务器。这种方式把“接入网络”和“身份验证”分离开了。路由器只管负责放行，验证账号密码这种事交给后端的专业服务器去跑。这就是目前所有现代 ISP 进行宽带接入认证（如 PPPoE）的首选标准方案。
第二部分：给无线路由数据包做一次“极速瘦身”—— 头部压缩（VJ 与 ROHC）
当你切到第 97 页，你会看到关于头部压缩的精彩论述。这个技术在当时慢速拨号网络中，就是救命的“神药”。
为什么必须压缩？
想象一下，TCP 协议在传输数据时，为了保证可靠性，接收方每收到一个包，都要给发送方回一个只有一个字节的 ACK（确认包）。但是，这个 ACK 包本身要带上 20 字节的 IP 头和 20 字节的 TCP 头——总共 40 字节！
这就像你为了寄一封 1 页纸的信，却必须用一个大几十斤的实木箱子包装，这在慢速拨号线路上是巨大的浪费。
2.1 VJ 压缩（Van Jacobson 压缩）：老神兵
> 【图片占位符：VJ 压缩前后数据包大小对比图】
此处建议插入一张对比图：上半部分是压缩前，一个 40 字节的 TCP/IP 头部；下半部分是压缩后，显示只有 3-4 字节的压缩头，并辅以“一个数据包中大部分字段是不变的，仅发送变化的字段”的图解说明。
VJ 压缩基于一个非常简单却极为敏锐的观察：在同一个 TCP 连接中，连续发送的数据包，它们的 IP 地址、端口号、协议号等字段几乎是一模一样的，极少变化！ 真正变化的只有 TCP 序列号和数据长度。
- 做法：发送方不再重复发送那固定的 40 字节头，而是只在包前面带一个极小的“编码标签”。接收方根据这个标签，结合之前已经建立好的“上下文”，自己把 40 字节的头部给还原出来。
- 效果：一个原本 40 字节的头部，被压缩到了 3 到 4 个字节。对于慢速串行链路，效果立竿见影。
2.2 从 VJ 到 ROHC：现代火箭级别压缩
随着网络协议变得越来越复杂（比如有了 IPv6，各种 UDP 流媒体），老式的 VJ 压缩显得不够用了。
- IPHC（IP 头部压缩）：它是 VJ 压缩的升级版，支持了更多协议。
- ROHC（鲁棒性头部压缩）：这是现在移动网络（4G/5G）和卫星通讯都在用的顶级压缩技术。它不仅压缩极好，而且非常“皮实”。即使在网络传输过程中丢失了很多包（上下文丢失），它也能迅速自我恢复，不会因为丢包导致整个传输卡死。
第三部分：跑完链路层，接下来跑什么？—— NCP 与 IPCP/IPv6CP 的加入
回到第 96 页，我们不能只停留在链路层。PPP 的终极目标，还是要支撑网络层（IP、IPv6）的通信。
当 LCP 协商通过，且安全认证（如 CHAP）成功后，PPP 会立即启动 NCP（网络控制协议）。针对不同的网络层协议，PPP 提供了不同的控制协议：
- IPCP（IP 控制协议）：这就像是在 PPP 链路上“跑 IPv4 的发动机”。IPCP 会协商两个极其重要的参数：
- IP 地址：服务器会给拨号的客户端分配一个具体的 IP 地址。
- DNS 服务器：客户端会通过 IPCP 从服务器获取 DNS 的 IP 地址。
- IPV6CP（IPv6 控制协议）：这是 IPv6 的专用发动机。它会通过协商，为客户端分配一个 64 位的接口标识符（类似于 IPv6 地址的后半段）。
第四部分：一场真实的“拨号舞会”—— 拆解书中的 Linux 配置日志
在这一页的最后，作者给我们展示了一段极其宝贵的真实世界日志。这段日志记录了一台运行 Windows Vista 的计算机，通过调制解调器拨号，连接上一台运行 Linux（pppd）的服务器的完整过程。我们来逐行拆解，看看刚才讲的那些理论是如何一步步落地的。
日志分析（按时间线）：
这段短短的日志，完美地融合了我们前面讲过的所有概念：物理连上 -> LCP 握手 -> 协商多链路/回拨 -> CHAP 安全认证 -> IPCP 分配 IP 和 DNS。 这不仅仅是代码，这是互联网拨号时代的浪漫与严谨。
结语：拨号时代的精彩终章
今天我们这趟旅程，从安全（CHAP/EAP）讲到了效率（VJ/ROHC 头部压缩），最后通过一段真实的 Linux 日志，让无数书本上的缩写和理论，在现实世界中一一落位。
PPP 看似古老，但它确立的“链路层握手 -> 认证 -> 网络层配置”的哲学，深刻影响了后来的各种 VPN、宽带接入（PPPoE）和移动网络底层。当你下次看到家里的光猫弹出“LCP 协商成功”、“获取 IP 地址”时，你要知道，这正是今天这段旅程中，那些技术逻辑在今天依然跳动的心跳。
