74、移动 IP 与头部压缩技术解析

time3

于 2025-10-31 09:23:14 发布

阅读量17

点赞数

CC 4.0 BY-SA版权

分类专栏：互联网协议深度解析文章标签：移动IP 头部压缩隧道传输

本文链接：https://blog.youkuaiyun.com/time3/article/details/154228056

互联网协议深度解析专栏收录该内容

75 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

移动 IP 与头部压缩技术解析

1. 移动 IP 概述

移动 IP 允许节点在不改变其 IP 地址的情况下，改变其与互联网的连接点。这不仅简化了配置，还能在节点移动时促进应用层的持续连接。

1.1 移动 IP 的需求

当主机物理位置改变时，传统的路由更新方式（即通过网络分发路由以声明节点新位置并更新路由表）扩展性较差。因为随着移动主机数量的增加，在互联网核心维护每个移动主机的特定路由表变得不切实际。

IETF 开发的解决方案是通过协议扩展，将目标为移动主机的数据包发送到其归属网络，再传递给称为归属代理的静态节点。移动主机向归属代理注册其实际位置，归属代理负责将数据包转发给主机。
- 若移动主机在归属网络，转发就是普通的 IP 转发。
- 若主机漫游，数据包必须通过隧道穿越互联网发送到移动主机向外部代理注册的转交地址，在转交地址处，数据包再转发给移动主机。

值得注意的是，隧道传输仅在一个方向上需要，移动主机发送的数据包可使用标准 IP 程序进行路由。虽然移动 IP 可解决任何 IP 移动性问题，但在无线局域网和移动电话网络中，链路层（即 IP 子层）程序（如链路层切换）可能更适用，这些过程通常内置于链路层机制中，且开销比移动 IP 小。不过，这些过程要求移动主机在其地址所属的 IP 子网内保持逻辑连接。

另外，移动 IP 中隧道传输的替代方案包括：
- 源路由 ：IPv4 虽有可选扩展支持源路由，但许多已部署的 IPv4 节点不支持，因此在现有 IPv4 网络中开发移动 IP 服务用处不大，不过在新建网络中可能更有用。
- IPv6 ：通过使用路由扩展头为移动 IP 提供了隧道传输的替代方案，移动节点可与归属代理建立通信，然后利用所学信息直接将数据包路由到目的地，绕过归属代理，这使得 IPv6 成为移动 IP 部署的热门选择。

1.2 协议扩展

为使移动节点能向归属代理或远程外部代理注册，需要进行特定的协议交换。移动节点向外部代理注册后，还需向归属代理进行进一步注册，以使其重定向流量并提供转交地址。外部代理可宣传其功能，以便连接到它们的移动节点知道可以选择进行移动 IP 注册。相关消息在 RFC 3344 中有描述。

移动节点通过 ICMP 路由器发现过程的扩展来发现可用的归属代理和外部代理。代理通过新的 TLV（类型 - 长度 - 值）在 ICMP 路由器通告消息中宣传其移动 IP 功能，TLV 给出代理的功能、可用转交地址集和注册有效期。代理能力标志的含义如下表所示：
| 标志 | 含义 |
| — | — |
| R | 移动节点必须完成注册程序才能使用此外部代理 |
| B | 代理繁忙，不接受额外移动节点的注册 |
| H | 此代理在发送此代理通告消息的链路上提供归属代理服务 |
| F | 此代理在发送此代理通告消息的链路上提供外部代理服务 |
| M | 此代理支持接收使用 RFC 2004 定义的最小封装的隧道数据报（来自归属代理） |
| G | 此代理支持接收使用 RFC 2784 定义的 GRE 封装的隧道数据报（来自归属代理） |
| r | 保留（必须为零） |
| T | 此代理支持 RFC 3024 定义的反向隧道 |

移动节点使用基于 UDP 传输的新迷你协议向归属代理告知其转交地址，UDP 端口号 434 保留给代理监听来自移动节点的传入注册请求。注册是一个简单的请求 - 回复交换，注册消息中的能力位从 ICMP 通告消息标志继承并有所修改，其精确含义如下表所示：
| 标志 | 含义 |
| — | — |
| S | 此位表示移动节点请求此绑定补充而非替换先前的绑定 |
| B | 移动节点请求将广播数据报与专门寻址到它的数据报一起通过隧道发送给它 |
| D | 移动节点将自行解封装隧道传输到转交地址的数据报，即移动节点与转交地址共置 |
| M | 移动节点请求使用 RFC 2004 定义的最小封装隧道传输 |
| G | 移动节点请求使用 RFC 2784 定义的 GRE 封装隧道传输 |
| r | 保留（必须为零） |
| T | 移动节点请求使用 RFC 3024 定义的反向隧道 |
| x | 保留（必须为零） |

请求/响应标识是一个 64 位随机数，用于防止恶意代理的重放攻击。回复消息中的回复代码表示请求的成功或失败，具体如下表所示：
| 回复代码 | 含义 |
| — | — |
| 0 | 注册接受 |
| 1 | 注册接受，但不支持同时的移动性绑定 |
| 来自外部代理的拒绝 | |
| 64 | 原因未指定 |
| 65 | 管理禁止 |
| 66 | 资源不足 |
| 67 | 移动节点认证失败 |
| 68 | 归属代理认证失败 |
| 69 | 请求的有效期过长 |
| 70 | 请求格式错误 |
| 71 | 回复格式错误 |
| 72 | 请求的封装不可用 |
| 73 | 保留且不可用 |
| 74 | 请求的反向隧道不可用 |
| 75 | 反向隧道是必需的，但 T 位未设置 |
| 76 | 移动节点距离过远 |
| 77 | 无效的转交地址 |
| 78 | 注册超时 |
| 79 | 传递方式不支持 |
| 80 | 归属网络不可达（收到 ICMP 错误） |
| 81 | 归属代理主机不可达（收到 ICMP 错误） |
| 82 | 归属代理端口不可达（收到 ICMP 错误） |
| 88 | 归属代理不可达（收到其他 ICMP 错误） |
| 来自归属代理的拒绝 | |
| 128 | 原因未指定 |
| 129 | 管理禁止 |
| 130 | 资源不足 |
| 131 | 移动节点认证失败 |
| 132 | 外部代理认证失败 |
| 133 | 注册标识不匹配 |
| 134 | 请求格式错误 |
| 135 | 同时的移动性绑定过多 |
| 136 | 未知的归属代理地址 |
| 137 | 请求的反向隧道不可用 |
| 138 | 反向隧道是必需的，但 T 位未设置 |
| 139 | 请求的封装不可用 |

请求和回复消息的扩展用于传达认证细节，扩展定义为 TLV，用于移动 IP 网络不同组件之间的通信，包括移动 - 归属认证、移动 - 外部认证和外部 - 归属认证。

下面是移动 IP 数据包转发的流程图：

graph LR
    A[远程主机] -->|数据包| B[归属网络]
    B --> C[归属代理]
    subgraph 移动主机在归属网络
        D[移动主机（在家）]
    end
    subgraph 移动主机漫游
        E[移动主机（外出）]
        F[外部代理]
        G[转交地址]
    end
    C -->|移动主机在家| D
    C -->|移动主机外出| H(隧道)
    H --> F
    F --> G
    G --> E

1.3 反向隧道

在某些环境中，路由器在决定如何转发数据包时，不仅会检查目标 IP 地址，还会检查源 IP 地址，以过滤欺骗性数据包。但在移动 IP 中，移动节点发送的数据包的源 IP 地址在外部网络环境中可能意外，从而被路由器丢弃。为克服这个问题，可将数据包从移动节点通过隧道返回归属代理，再由归属代理转发，此过程称为反向隧道，它有效地反转了发送到移动节点的数据包的路径。

理想情况下，反向隧道应由移动节点建立，但这仅在移动节点与转交地址共置时有效。如果使用外部代理提供转交地址，则反向隧道由外部代理管理，有两种选择：
1. 直接传递方式 ：移动节点将数据包直接发送到作为默认路由器的外部代理，让外部代理拦截并将其隧道传输到归属代理。
2. 封装传递方式 ：移动节点使用隧道将数据包发送到外部代理，外部代理解封装数据包，再将其重新隧道传输到归属代理。

反向隧道的信令扩展在 RFC 3024 中定义，主要涉及表 15.3 和 15.4 中显示的 T 位以及表 15.5 中显示的回复代码 74 - 76、79 和 137 - 139。

1.4 安全问题

移动 IP 标准要求在移动节点和其归属代理之间的注册过程中使用强认证加密技术，因为这是移动 IP 过程中最脆弱的部分，若被拦截或欺骗，可能导致所有从归属代理代表远程联系人发送到移动节点的流量被拦截或转移。强认证也可用于移动节点与外部代理之间以及外部代理与归属代理之间。由于目前没有基于 IP 的认证密钥分发协议，代理发现消息不进行认证。

参与移动 IP 的主机之间交换的数据也可加密，有三种模型：
1. 源加密 ：数据的源端对其进行加密，通过归属代理发送到移动节点，移动节点再解密。
2. 归属代理选择加密 ：归属代理根据移动节点是否外出选择是否对转发的数据进行加密，这样转发给漫游移动节点的数据在网络未知部分进行加密，由移动节点解密。
3. IPsec 隧道 ：使用 IPsec 作为归属代理和外部代理之间的隧道协议，移动节点无需具备加密/解密能力。

移动 IP 与头部压缩技术解析

2. 头部压缩

大量的数据流量可能是由传输这些流量的协议引入的开销。例如，使用 RTP、UDP 和 IP 时，每个数据包可能需要 40 字节的控制数据。如果数据只是一个短音频样本（可能只有 16 字节），那么开销将达到 70%，这可能导致在慢速链路上无法提供足够的服务，出现失真和丢失等不可接受的质量问题。为了解决这个问题，人们想出了许多方法来减少协议开销，同时保留其中重要的信息，协议头部压缩就是一种流行的解决方案。

2.1 选择压缩头部

头部压缩的好处显而易见：可以增加数据流量与协议开销的比例，从而提高数据吞吐量。然而，头部压缩是一种点对点技术，它依赖于在一对网络节点之间，协议信息从一个数据包到下一个数据包只有微小的变化，并且这些变化在很大程度上是可预测的。每个节点仍然需要解压缩协议头部信息，以确定如何处理每个数据包，这就要求每个节点都必须具备处理压缩和解压缩的能力，并且在网络的每一跳都会引入显著的处理开销。

如果链路带宽有限且有足够的处理能力，头部压缩可能会显著提高服务质量。头部压缩通常作为一对节点之间的二层网络连接的质量进行协商，这是因为二层网络知道链路的带宽能力，并且该层以上的所有内容都可以被压缩，因此对等节点知道是否使用压缩非常重要。例如，CSLIP 和 PPP 使用连接时的参数协商来确定是否在它们管理的链路上使用头部压缩。

2.2 IP 头部压缩

可以想象，存在一种按流的压缩算法，不需要为每个数据包重新传输这些不变的字段。此外，IP 数据包长度和 UDP 长度这两个字段在大多数网络技术中可以被视为冗余，因为网络层（如以太网、PPP 等）也会携带整个数据包长度的指示，因此可以安全地从传输的数据包中删除这两个字段。

还有一个 IP 字段和两个 RTP 字段是可预测的。IP 分片 ID 和 RTP 序列号会随着每个发送的数据包递增，RTP 时间戳会根据 RTP 会话参数中的数据包速率增加，这三个字段也可以被排除。

检查上图中显示的所有字段，会发现只剩下一个字段：IP 头部校验和。但如果 IP 头部中没有其他字段需要，也可以删除这个字段。不过，这有点过于简化了。

压缩数据包的接收者（解压缩器）必须能够重构头部，以便 IP 和更高层软件能够处理数据包。为此，它必须以未压缩的形式（即包含所有头部）接收第一个数据包，并在数据包流的上下文中将这些字段存储在状态块中。当每个新的压缩数据包到达时，解压缩器可以使用存储的数据重建头部。

压缩数据包发送时，开头会有一个标志，指示使用的是 8 位还是 16 位 CID，然后是 CID 本身。

虽然 IP 分片 ID 和 RTP 序列号是可预测的，但它们并非完全冗余，因为它们用于发现乱序或丢失的数据包。不过，这个处理可以合理地减少到仅 4 位，仍然提供相同的功能。

下面是 IP 头部压缩和解压缩的流程图：

graph LR
    A[发送端] --> B(初始完整数据包)
    B --> C(存储不变字段到状态块)
    B --> D(使用冗余长度字段携带 CID)
    A --> E(后续压缩数据包)
    E --> F(携带 CID 标志和 CID)
    G[接收端] --> H(接收初始完整数据包)
    H --> I(存储不变字段到状态块)
    G --> J(接收压缩数据包)
    J --> K(根据 CID 从状态块恢复头部)
    K --> L(处理数据包)

综上所述，移动 IP 和头部压缩技术在提高网络效率和移动性方面都有着重要的作用。移动 IP 解决了主机移动时的连接问题，而头部压缩则减少了协议开销，提高了数据传输效率。在实际应用中，需要根据具体的网络环境和需求来选择合适的技术和配置。