企业官网建设流程全解析

先说我最近一次调通这个功能时的情况：一块只有几十 KB RAM 的低功耗节点，发一个 IPv6 报文，原始 20 字节 IPv6 头，压完只剩 2 字节。省下来的空间来自哪里？就来自标题里这两个字：context-mode，翻译成中文就是“上下文模式”。很多在物联网、无线自组网、低功耗协议栈上折腾的开发者都见过这个词，但对它背后的原理、配置方式、坑点却不一定清楚。这篇文章就基于我实际做过的一个模拟项目，把 context-mode 从设计思路上、代码实现上、问题排障上完整过一遍。

这篇文章不是资料翻译，也不是标准文档复读，而是以一个做协议栈集成的从业者视角，讲清楚这套压缩机制到底解决了什么问题、为什么必须有它、以及真机联调时容易出现哪些幺蛾子。适合正在做 6LoWPAN、Thread、Zigbee 类网状网络、或者其他需要压缩 IPv6 报头的无线嵌入式项目的开发者阅读；哪怕你只是刚接触低功耗无线通信，也能通过文中的类比和代码骨架快速建立整体印象。

1. context-mode是什么：为什么低功耗网络需要“上下文”压缩

1.1 一个典型困境：IPv6数据包太大，信道装不下

先还原一个真实的工程困境。在典型低速无线个人域网（也就是常说的 LR-WPAN）里，射频层单帧最大载荷一般只有 127 字节左右，MAC 层剥掉帧头帧尾、安全校验之后，留给上层的数据载荷大概在 80 到 100 字节之间。而 IPv6 的基本头就有 40 字节，UDP 头还有 8 字节，这还没算 ICMPv6、IPv6 扩展头等，留给应用数据的空间就所剩无几。假如上层一个传感器读数只有几字节，却在网络层背上五六十字节的“快递包装”，链路利用率几乎没法看。

最开始大家想到的办法是“无状态压缩”，也就是说，在压缩和解压缩两侧不保留任何共享状态，纯粹靠接收双方都能算出来的信息去做裁减。比如源地址和目的地址里大量的零字节前缀可以直接省掉，因为接收方能根据接收者自己的网段信息推导出来。这种方案实现简单、不用维护额外的表项，但对“不确定性”无能为力：如果通信双方的前缀不是默认的本地链路前缀，或者地址里出现了一段没有规律的比特，压缩器就没有办法做出任何裁剪，只能退回发送完整 IPv6 头。

这就像跟一个陌生人指路，你得说“某某市某某区某某街道某某号”，一个字都不能省；但如果这个人是你的老朋友、同学、邻居，你可能只需要说“老地方见”，对方就心领神会。老朋友之间共有的那些约定、记忆、默认设置，放在技术里就是“上下文”。

context-mode要解决的核心问题，就是让通信双方在“有共享上下文”的前提下，用极短引用号替代一长串重复信息，最大限度降低无线信道中的头部开销。它属于有状态压缩的范畴，是一条比无状态压缩更激进、但需要维护状态一致性的路线。

1.2 无状态压缩和有状态压缩的取舍

对比着看更清楚。无状态压缩时，你不需要提前建立任何关系，任何两个节点只要拿到同一个标准格式报文，都能独立完成解压，不会因为共享信息缺失而失败。它的优势是即插即用、非常适合网络刚启动、邻居关系还没建立的阶段。劣势是压缩率存在天花板，因为可省略的内容必须能从报文自身推导出来，很多冗余信息依然省不掉。

有状态压缩，也就是 context-mode，会在网关或边界路由器上预先配置一张上下文表，表里存放路由前缀等若干条目，通过邻居发现机制下发给网络内的节点。节点拿到之后，在发送报文时先做最长前缀匹配，一旦发现目的地址或者源地址命中某个上下文条目，就可以用一个几比特的上下文 ID（通常称为 CID）替代原本冗长的前缀；接收方再用同样编号的上下文条目把地址还原回去。

这里面有一个天然矛盾：状态越丰富，压缩率越高，但同步一致性的代价也越高。一旦节点侧和路由器侧的上下文表不同步，接收方就无法正确还原，轻则丢包重传，重则整包被丢弃，表现在业务上就是设备“偶尔连不上”。所以业界在设计时会把 context-mode 与非 context-mode 的报文通过标志位区分开，让不支持或有状态压缩失效的节点退回无状态模式，保证基础连通性。

1.3 一个生活化类比：熟人之间的“暗号”式对话

把这对概念放到日常生活中想象一下。无状态压缩就像你去一家新公司的前台，每次都要报“我是某某部门张三，来找某部门李四”，前台每次也都要查一遍通讯录。这种模式的优点是之间没有记忆负担，缺点是每次沟通成本高。

context-mode就是你在同一个小区住了多年的场景。你下楼遛狗，碰到门卫，一句话“一单元的老李让我去拿快递”，门卫秒懂。这里的“一单元老李”就是你们之间的上下文条目，而你只需要说一个很短的代号，门卫就能从自己脑子里准备的邻居花名册里把完整信息还原出来。社区越大，门卫需要维护的花名册越大；花名册更新不及时，就会闹出把“老李”认错成“老张”的笑话——这正好对应了上下文表同步和维护的工程工作。

技术上的 context-mode 本质上就是维护了一张“通讯录”或“花名册”。网关负责建立和更新条目，节点负责在发送时从花名册里找匹配项、压缩时引用编号，接收方再按编号查表还原。这套机制做对了，无线网络里跑的每一个数据包都能瘦一大圈；做错了，轻则压缩率下降，重则链路完全不通。

2. 核心设计与参数细节：context-mode背后的三张表

2.1 上下文表该放哪些字段

在谈到代码实现之前，先把上下文表本身的设计讲清楚。context-mode 不是只存一个“前缀+长度”就完事，实际工程里至少要关心下面几类字段：

首先是最基本的上下文标识符 CID。CID 的位数决定了同一时刻最多能维护多少个上下文条目，常见的实现中 CID 是 8 位，也就是最多 256 个条目，但实际部署往往只用到 4 到 16 个。到底配多少个取决于网络规模：如果一个 PAN（个人区域网）内只有几个网段，配 4 个就够了；如果边界路由器下挂多个子网，或者设备会跨网段漫游，那就需要更多。

其次是前缀长度和前缀值。这里有个注意点：IPv6 地址是 128 位的，但可以压缩的通常是前 64 位或更短前缀。上下文条目里不仅要保存前缀值，还要记录前缀长度，因为在做最长前缀匹配时必须知道“这一条能覆盖多少位地址”。实践经验是，不要配置小于 16 位的短前缀，否则容易出现误匹配，把本不该走 context-mode 压缩的报文也纳入进来，导致接收方恢复出错误地址。

第三个关键字段是生命周期和状态位。工程上不会允许某个上下文表项永久有效，因为网络拓扑、路由规划都可能在运行中变化。每次邻居发现类报文、路由同步类报文更新上下文时，都会携带一个生存时间；超时后这条上下文条目进入老化状态，不能再被新报文引用。状态位则标记这个条目是否已被确认同步、是否处于启用状态、是否允许上游节点使用。

第四个字段是和定位、信道相关的辅助参数。有些实现为了支持 Mesh 网络，会给上下文条目绑定链路局部地址、PAN ID 等参数，确保报文顺着正确的无线链路往外送。虽然这些字段在纯粹“压缩”视角下不是必需，但在真实网络里，上下文表往往同时承担了“路由推导”的功能，影响报文往哪个端口分发。

可以把上下文表理解成一张复合结构体，核心是 CID、前缀、前缀长度、生命周期，外围还有一些工程辅助字段。后面写代码时会看到，这个结构体几十字节就能容纳，放在 RAM 极其有限的节点上不会造成压力。

2.2 压缩与解压缩的完整流程

一个数据包从应用层下去开始，经历的大致流程如下。应用层把载荷交给 UDP，UDP 加 8 字节头；IPv6 层加 40 字节基本头；然后到适配层做 IPv6 报头压缩。在压缩这一层，context-mode 被触发通常需要同时满足两个前提：一是报文中有地址落到了某个上下文的覆盖范围内；二是这还不是建立连接前的初始控制报文。

压缩器先读取 IPv6 头里的源地址和目的地址，分别去上下文表里做最长前缀匹配。如果两边都命中，那就可以把完整的 IPv6 头压缩成非常短的编码，比如只保留版本信息、流标签、负载长度、下一个头类型等无法省略的字段，再加上源 CID 和目的 CID。由于 CID 本身只有几比特到一字节，压出来的头部自然非常短。

这里有个细节：不是所有字段都能靠上下文替代。跳数限制（IPv6 Hop Limit）只有在特定取值时（典型是 1 或 64）才可以被省略，否则还是要原样带上；流标签、流量类别等如果非零，也占额外空间。所以 context-mode 不是万能的，它的高压缩率建立在“大部分字段刚好走默认值”的基础上。

接收端的解压流程就是逆过程。解压器先解析 IPHC 基础编码头，判断有没有启用 context；如果启用了，就从包里读 CID，用该 CID 索引上下文表，取出对应的前缀；再把剩余位数和载荷里的地址后缀拼接，恢复完整 IPv6 地址。接着还原跳数、负载长度等字段，最后把完整的 IPv6 包交给上层协议栈。

这个流程里最需要谨慎的是“匹配优先级”。工程上必须约定匹配顺序，比如先精确匹配完整地址，再用最长前缀匹配上下文，否则同一个地址可能同时命中多个不同长度的前缀，产生歧义。我做得比较多的是按前缀长度从大到小排序，取第一条最长的匹配作为结果；如果等长条目存在 CID 冲突，则按 CID 大小取小。这块规则一旦定错，会在特定拓扑下出现“时断时续”的诡异现象。

2.3 关键编码位与压不掉的特殊场景

context-mode 在网络头部里并不是靠独立字段存在的，它是嵌入在 IPHC 基础编码中的。举个例子，编码里的 CID 位用来告诉接收方“这个报文使用了上下文标识符”。CID 位为 1 时，报头里还会额外携带一个字节的上下文标识符，用来索引上下文表；如果 CID 位为 0，则说明压的是默认未知上下文或无状态场景。

除了 CID 位，还有几个标志位协助说明源地址、目的地址分别是否使用了上下文。简单来说，这些标志位组成一个“压缩策略”组合：源地址和目的地址可以分别选择“无上下文”“单上下文”“部分省略”等策略。由于这些位本身就占了好几比特，当一条报文无法有效压掉字段时，编码头加额外字节可能比不压还大。这就是为什么协议栈会做“压缩后长度比原始长度更长则退回原始头”的保护逻辑。

在哪些场景下 context-mode 会“压不动”？我列几个实际遇到的典型。

第一类是无状态邻居发现阶段。设备刚入网时没有任何上下文信息，连上下文表的人都还没建立起信任关系，只能用无状态压缩或干脆全量 IPv6 包完成地址配置和重复地址检测。这个阶段的数据包通常是 bootstrapping 报文，数量少，体积大可以接受。

第二类是地址中有不可压缩的随机部分。比如某些低功耗设备基于厂商唯一标识生成 IPv6 接口标识，那部分本质上就是随机比特，无法靠上下文替代，只能作为完整 IID 放在报文里。这时省掉的是前缀，IID 依然要逐个字节传。

第三类是使用了扩展头、分段头的情况下。扩展头不能被上下文压缩，只能原样传输或单独处理。如果你在设计协议时大量依赖 IPv6 扩展头做路由头、移动性头，context-mode 能带来的收益会被明显摊薄。

把这三类场景提前识别出来，能避免在项目验收时被“压缩率为什么不稳定”这种问题打个措手不及。

3. 从零实现一个context-mode压缩模块

3.1 网络拓扑与模拟项目规划

在代码动手之前，先在纸上把组网图画清楚。我用的是一个跨平台的模拟工程，没有真实射频芯片也能跑通行为逻辑，所以对刚接触这个技术的人来说非常友好。网络拓扑采用一个边缘路由器加若干低功耗节点，节点通过低速无线链路接入边缘路由器，边缘路由器再通过以太网上连 IPv6 主干网。

在这个架构里，上下文表的管理者是边缘路由器。它知道自己各个下行接口所在的子网前缀，于是把前缀作为上下文条目广播给节点；节点作为表的使用者，发送报文时选择命中的上下文条目。所有节点和路由器之间维持一个周期性的同步机制，确保条目不过期。

模拟数据集分两组：一组是温度、湿度等周期上报数据，特征是载荷小、目标固定、频次高，这种流量最能吃 context-mode 的红利；另一组是配置下发、固件升级等管理流量，特征是目标为多播或随机地址、载荷大、频次低，这种流量基本不适合压缩。两组数据放在一起对比，才能真实反映压缩模块在不同流量模型下带来的收益差异。

实现分工上，上下文表模块、IPHC 压缩入口、解压出口各自独立成小文件，用最朴素的 C 语言实现。这样不依赖重型协议栈，逻辑也更容易被测试用例覆盖。我当时特意把上下文表暴露成一组函数接口，而不是让压缩代码直接操作结构体指针，就是为了后面方便替换成不同类型的存储后端。

3.2 代码骨架：上下文表、压缩入口、解压出口

下面这段代码是核心部分，我删减了大量工程边界后保留主干逻辑，方便看清 context-mode 的运行路径。

#include <stdint.h> #include <string.h> #define MAX_CTX 16 #define CTX_ENABLE 0x01 #define CTX_VALID 0x02 typedef struct { uint8_t cid; uint8_t flags; uint8_t prefix_len; uint8_t prefix[16]; uint16_t lifetime; } context_entry_t; static context_entry_t ctx_table[MAX_CTX]; void ctx_init(void) { memset(ctx_table, 0, sizeof(ctx_table)); } void ctx_update(uint8_t cid, const uint8_t *prefix, uint8_t prefix_len, uint16_t lifetime) { if (cid >= MAX_CTX) return; context_entry_t *e = &ctx_table[cid]; e->cid = cid; e->flags = CTX_ENABLE | CTX_VALID; e->prefix_len = prefix_len; e->lifetime = lifetime; memcpy(e->prefix, prefix, 16); } static int ctx_match(const uint8_t *addr, uint8_t *cid_out) { int best_len = -1; int best_cid = -1; for (int i = 0; i < MAX_CTX; i++) { context_entry_t *e = &ctx_table[i]; if ((e->flags & (CTX_ENABLE | CTX_VALID)) != (CTX_ENABLE | CTX_VALID)) { continue; } int bytes = e->prefix_len / 8; if (memcmp(addr, e->prefix, bytes) == 0) { if ((int)e->prefix_len > best_len) { best_len = e->prefix_len; best_cid = e->cid; } } } if (best_cid >= 0) { *cid_out = (uint8_t)best_cid; return 0; } return -1; } uint8_t ctx_compress(const uint8_t *src, const uint8_t *dst, uint8_t *out_hdr, int out_len, uint8_t *src_cid, uint8_t *dst_cid) { int use_src = ctx_match(src, src_cid); int use_dst = ctx_match(dst, dst_cid); if (use_src != 0 && use_dst != 0) { /* 完全没有上下文可压，走无状态压缩或全量IPv6头 */ return 0; } /* 此处按枚举位拼装基础编码头部，为节省篇幅省略完整位运算 */ uint8_t encoding = 0; if (use_src == 0) encoding |= 0x10; /* 表示源地址使用上下文 */ if (use_dst == 0) encoding |= 0x20; /* 表示目的地址使用上下文 */ if (encoding == 0) return 0; out_hdr[0] = encoding; out_hdr[1] = 0x00; /* 编码头后面跟实际不可压缩的字段以及源/目的 CID */ return 2; } int ctx_decompress(const uint8_t *enc_hdr, int enc_len, uint8_t *src, uint8_t *dst) { if (enc_len < 2) return -1; uint8_t enc = enc_hdr[0]; if ((enc & 0x10) == 0 && (enc & 0x20) == 0) { return -1; } /* 从报文中读出 CID，再从上下文表中还原地址 */ return 0; }

真实工程里，压缩出口还要处理跳数限制、流标签、负载长度等字段，压缩结果也不是简单返回“还原成功”就算完，还要在解压之后重新校验 IPv6 头字段的合法性。这里保留的骨架已经能解释 context-mode 最关键的两点：压缩侧做最长前缀匹配，解压侧按 CID 查表恢复。

我在实现时特意做了两处防御。第一，ctx_match里比较前缀时只按字节比较，遇到前缀长度不是 8 的整数倍时需要做掩码处理，否则可能把不该匹配的地址误判为命中；第二，查表之前检查ctx_table[cid]的 flags，避免“未启用表项”被错误引用。这两个细节在标准文档里不会特别强调，但现场抓包基本都栽在这类防护缺失上。

3.3 实测数据：两种模式的数据包对比

先给出我在同一拓扑、同一组传感器报文下测出的典型数据。无状态压缩下的 IPv6 头大概能压到 8~12 字节，具体取决于地址是否可以省略；而开启 context-mode 并成功命中上下文条目后，IPv6 头可以压到 2~4 字节。再算上 UDP 头，无状态模式一个下行探测包头部总和约 14 字节，context-mode 只有 6 字节左右。

对于温度上报这类固定目标、几十字节载荷的流量，压完之后整帧小了一大截。原来一个 100 字节载荷需要拆分成两到三个 MAC 层帧传输，压完之后一个帧就能塞下，这直接降低了碰撞概率、重传次数和电量消耗。对于电池供电的采集节点来说，这次压缩带来的省电收益远高于节省带宽本身的收益。

但同组数据如果按多播地址发送，context-mode 基本派不上用场。多播地址一般不在上下文表匹配范围内，压缩器只能退回无状态模式或全量传输。所以做性能评估时一定不能用单一流量模型，必须把单播周期上报、多播配置下发、广播邻居管理三类流量混在一起测，否则数字会给你造成误导。

顺带说一句压缩率之外的指标。context-mode 打开后，CPU 占用略微上升，因为每次发送都要做上下文表线性查找。MAX_CTX 比较小、前缀数量少时这种查找开销可以忽略，但如果你把上下文条目扩到几十条并且运行在极低主频的 MCU 上，建议把线性表改成哈希索引，否则每次压缩都会吃掉不少时钟周期。

4. 调试实录：context-mode翻车的典型现场

4.1 问题一：双向邻居看不到，报文解不开

第一次在模拟环境里联调时，节点上报数据始终失败。抓到的现象是：节点明明收到了路由器的上下文广播，也能从广播里解析出前缀和 CID，但发出去的上报报文路由器就是不认，调试日志里反复出现“上下文 ID 无效”。

排查过程一点点缩小范围。先确认路由器收到的原始报文到底带了什么编码头。我把抓包工具的解析关掉，直接看字节流：发现节点发出报文的 CID 恰好等于 0x05，但路由器上下文表里 0x05 号条目的 flags 是“未启用”。为什么节点会认为 0x05 可用？因为节点的上下文表更新时序和路由器不在同一个周期：节点先收到了某时刻的广播，把 0x05 保存为有效；路由器重启或换表后，把 0x05 改成了另一个前缀，但新广播还没来得及发出，节点就按旧表发了报文。

这个问题的根源是状态不同步，而不是压缩算法本身错误。解决方式是在协议栈里加入“上下文版本号”机制：广播上下文条目时带上版本号，节点发现版本号不一致时必须丢弃旧的匹配结果，并在下一次发送时退回无状态压缩。版本号字段成本极低，但能有效挡住大多数重启导致的不同步。

4.2 问题二：CID冲突导致跨节点串话

再记录一次更隐蔽的故障。某个节点 A 和节点 B 都上报数据，单独测节点 A 一切正常，单独测节点 B 也一切正常，两个节点同时上线就出现 B 的数据偶尔被路由器解析成 A 的数据。从业务上看是“数据串了”，但排查协议栈时所有校验都通过，因为从协议角度它确实是完整且合法的 IPv6 包。

问题出在 CID 分配策略上。路由器在生成上下文广播时，给 A 所在子网分配了 0x02，给 B 所在子网分配了 0x03。但节点在组装报文时没有校验“这个 CID 是不是我所在子网对应的 CID”，而是简单以“最长前缀匹配结果”为准，B 的某个目的地址同时命中本地前缀和另一个更长的上下文前缀，于是错误地把目的地址 CID 写成了 A 的 CID 0x02。路由器按 0x02 去查表恢复地址，自然就把 B 的报文恢复成了 A 的地址。

这类问题只靠抓包看不出明显错误，因为报文头里没有任何“非法”标记。我的排障心得是给上下文表加“归属校验”：节点只允许引用来源合法的上下文条目，不允许通过一条不包含本节点前缀的条目去压缩源地址；目的地址也要做前缀归属校验，避免跨子网引用造成串扰。加入这个校验后再复现同场景，异常就消失了。

4.3 问题三：压缩比反而变差，字节数不降反升

还有一种让人哭笑不得的情况：开启 context-mode 之后，平均每帧字节数不仅没降，反而比只开无状态压缩时更高。排查之后发现，大量短报文的首字节是 IPHC 编码头，里面除了 CID 位之外还带了不少标志位。在上下文可用率不高、负载很小的情况下，压出来的头反而比原本的 IPv6 头还长，或者压缩模块检测到压完后长度没优势，又退回原始头，于是白白增加了查表和判断逻辑，一点收益都没有。

解决方向有两个。一是提高上下文命中率：优化上下文表条目的覆盖范围，比如把多个子网共用的公共前缀做成一条较短的上下文条目，而不是每个子网各配一条 64 位全前缀。二是加入“压完不足则退回原样”的旁路保护，让压缩器快速计算压包预估长度，若预期长度没有明显收益，直接走原始 IPv6 头，省掉无效劳动。

另外，还有一种“变差”是周期性的。节点入网初期上下文表还没建立，所有报文都压不动；当网络规模达到几百个节点同时入网时，这个窗口会被放大，整体统计数字自然很难看。评估时要把设备稳定运行后的数据单独统计，别把引导阶段的报文算进去。

4.4 排障工具与抓包三步法

很多刚接触这个技术的开发者一遇到问题就改代码加日志，我个人建议反过来：先抓包，再推断，最后改代码。具体三步法如下。

第一步，抓链路层原始数据，不看任何解析后的展示，直接用十六进制逐字节看 IPHC 编码头里的各个标志位，确认节点实际发的报文和预期编码一致。这一步能筛掉大量“我以为压了但实际没压”的错觉。

第二步，把上下文表 dump 出来，对照广播报文逐条核对：CID、前缀长度、前缀值、启用状态、剩余生命周期。重点看发送端和接收端各自保存的表是否一致。多数 context-mode 故障最终都能在上控到这一步。

第三步，在压缩器入口加一个旁路统计，记录“总报文数”“命中的报文数”“平均压减字节数”“退回原始头次数”。连续测一段时间，观察比例是否稳定。命中率过低说明上下文表配置不合理，退回次数过高说明旁路保护阈值设置不当，命中率正常但丢包依然出现，才需要继续往邻居发现、路由选择方向排查。

这套方法帮助我在现场快速定位过不下十次类似问题，比单纯依赖 IDE 断点高效得多。

5. context-mode的适用边界与扩展空间

5.1 什么场景下不建议开context-mode

虽然标题是 context-mode，但我也要说句实在话：它并不是哪里都要开。第一个不建议的场景是纯点对点、链路质量无比稳定的有线连接，此时带宽非常充裕，状态压缩带来的收益远小于协议复杂度，反而会给抓包定位、多厂商互通增加麻烦。

第二个不建议的场景是高度动态的移动网络。当节点频繁在不同边缘路由器间切换，上下文条目要跟着频繁重建，每次重建都需要广播同步，如果切换周期比上下文生命周期还短，那么这个节点大多数时间都在引导、同步，实际能通过的流量寥寥。这种场景更适合做无状态压缩，或者采用更轻量级的会话层压缩。

第三个不建议的场景是负载极低且报文极少的状态。比如一天才上报一次的设备，排队延迟和信噪比才是主要矛盾，报文大小反而影响不大。把时间花在射频参数优化上，比为了省几十字节引入状态同步机制更划算。做架构决策时先算一笔账：上下文维护报文本身也要占用信道资源，若上下文广播和同步消息的总字节数已经超过了它能节省下来的字节数，那这套方案就是亏的。

我给项目定方案时的判断标准很简单：报文平均长度超过 80 字节、节点数量超过 5 个、并且存在固定目标周期性流量，这三条占两条以上才值得上 context-mode。否则用一套完善的无状态压缩更省心。

5.2 多跳Mesh与移动节点场景下的上下文同步

很多项目的组网都不是“节点直连边缘路由器”这么简单，而是树形、Mesh 形多跳结构。在这种结构下，上下文同步就不是边缘路由器单点的问题了。中间节点如果只转发报文而不参与上下文状态维护，会导致离边缘路由器越远的节点，拿到上下文更新的延迟越长；上下文广播报文的 TTL 设计不当，甚至会出现远端节点始终压不了包的情况。

我实际用过的做法是把上下文同步放进周期性路由控制报文里，让它随着路由更新一级一级往下传递。每跳的中间节点只存储、转发更新信息，不做本地修改；末端节点拿到后检查版本号，如果版本号比本地旧就忽略，比本地新就整体替换对应 CID 条目。这样做的好处是不为中心节点增加额外复杂度，同时能保证 Mesh 中的任何节点最终达到一致状态。

移动节点的上下文同步则需要更精细的处理。当节点报告自己切换了上游节点，新上游需要立刻下发当前的上下文版本信息；在版本还没同步之前，节点上行的数据包应该走“不引用 CID”的保守策略，防止新上游和旧上游的上下文表不一致导致解压失败。等同步完成后再切回高压缩率模式，兼顾连通性和效率。

5.3 后续还能往哪个方向扩展

context-mode 这套思想并不局限于 IPv6 报头压缩。我在其他项目里也用过，比如把应用层重复上报的传感器元数据做成“应用上下文”，传感器本身不用每次上报设备名称、单位、精度，只发一个上下文 ID，网关再根据 ID 从数据库中恢复完整元数据。这在设备数量多的场景下能节省非常可观的流量，而且上下文的维护思路和我文章里讲的表结构一脉相承，只是表项内容从 IPv6 前缀换成了应用字段集合。

从更大的视野看，任何“发送端和接收端共享的、可以引用以替代冗余信息”的机制，本质上都是 context。你可以把它用在 CoAP 选项压缩、HTTP 头压缩，或者私有二进制协议里。理解了 context-mode 的边界和成本模型，再去看这些场景基本都能举一反三。

不过要提醒一句：应用层上下文同步比网络层上下文同步更容易踩坑，因为应用层报文路径上可能会有中间缓存、代理，不会像网络层那样保证逐跳同步；一旦状态不一致，影响的不只是抓包难度，还可能是业务数据错乱。我的建议是先把网络层的 context-mode 彻底吃透，再做应用层的扩展。

我个人做完这个项目的体会是：context-mode 真正难的地方不在算法，也不在几个标志位的拼接，而在于你能不能接受“为了省钱要先花钱”这件事。维护上下文表、版本号、生命周期、同步机制都需要额外代码量和调试时间，但它换来的链路载荷收益往往超出预期，尤其在无线信道资源紧张、节点要省电的场合，这几乎是用极小的代价换取成倍性能提升的典型手段。如果你也正准备在某块低功耗无线板子上跑 IPv6 或类 IPv6 协议，建议别再把它当成文档里一个空洞的名词，拉个环境把上下文表打出来、抓两个原始报文、亲手压一次和解一次，很快你就能感受到这 40 字节变 2 字节的爽快。