6.6 网络层与传输层：寻址与可靠搬运

6.6 网络层与传输层：寻址与可靠搬运

应用层靠语言说话，底下两层要托住：网络层（IPv4/IPv6）管寻址，传输层（TCP/UDP）管可靠不丢。本节拆它们在物联网世界的取舍：IPv6 为什么比 IPv4 更适合海量设备？TCP 丢包重传，UDP 不管不丢，物联网场景里选哪边？

这两层像承重墙，先认账

阅读完本节，你应当能够：

1. 说出 IPv4 地址枯竭对物联网的现实影响，以及 IPv6 为什么能解决它。
2. 对比 TCP 与 UDP 在功耗、可靠性、开销上的差异。
3. 判断"传感数据上报"和"实时控制指令"各选传输层哪一端更好。

一、网络层：IPv4 与 IPv6，地址够不够用决定未来

网络层最核心的事，就是给每一台物联网设备一个"全世界唯一认得出"的地址，方便报文找对门。地址这件事，互联网走了 IPv4，快走完了，物联网刚好是新用户：

• IPv4：总共有约 43 亿个地址，早在十几年前就不够分了，现在靠 NAT 复用挤位置。对海量物联网设备，NAT 会让设备无法直连，地址资源越挤越难受。
• IPv6：把地址空间从 32 位拉到 128 位，几乎所有物联网设备都能直接分配公网地址，不用再靠 NAT 挤来挤去。同时 IPv6 报头更简洁，路由更简单，更适合低功耗传输。

为什么这对物联网重要？简单说：你给一百万台水表上网，IPv4 就算挤得下水，每台要地址都得 NAT 来回转；IPv6 随便给每台分配一个，天下平摊，不用折腾。所以新的大规模物联网项目，推荐优先上 IPv6，地址枯竭的未来风险一次解决。

二、传输层：TCP 与 UDP，取舍在可靠与功耗

传输层要解决的问题简单：报文丢了，要不要重传，重传的代价是什么。TCP 和 UDP 给出了两种完全不同的答案：

取舍总结一句话

• 要可靠、不能丢、少发不频繁 → TCP，如配置下发、确认应答。
• 要轻、要快、丢几个无伤大雅 → UDP，如定期传感上报。

常见踩坑教训

有人怕丢，给所有传感报文都上 TCP 长连接，结果功耗直接炸。因为 TCP 长连接要保活握手，设备没法彻底睡过去，本来该活五年的电池，一年就没电。所以越是低频上报，越是要给 UDP 一个机会——丢一两次不影响全局，电池却能多活好几年。反之，控制指令怕丢，必须走 TCP 给重传。

三、一句话总结两层关系

把应用、传输、网络连起来，就看到一个完整的管道拼图：

CoAP 天生跑 UDP 就是这个道理：本来就是给受限设备轻量请求，用 UDP 更省。MQTT 天生跑 TCP：发布订阅要可靠的 broker 连接，TCP 负责把连接稳住。两者在传输层的选择，都是为了迎合上层需求。

四、落到现场：设备地址到底怎么给

"用 IPv6"听着简单，落地时地址还得有来路。设备拿到地址靠两条主流路子：

• DHCP：设备连网时自动向网络申请，动态、集中、好管理，适合可频繁加入/离场的批量部署。
• 静态分配 / 6LoWPAN SLAAC：设备预先写死或按接口协商出地址，适合地址要固定、便于运维定位的设备。

对海量低功耗节点，动态分配省人工、减少误配，是默认首选；只有要"把某台设备当作稳定对外端点"时，才值得给它一个固定地址。把"地址从哪来"也一并想清楚，IPv6 的优势才真正落地，而不是停在"地址很多"的口号上。

五、传输层一张小抄：TCP 还是 UDP

把第三节的取舍压成一张可直接照抄的小抄，现场选层时扫一眼就走：

上报周期传感数据       → UDP（丢一两次无伤，省下一大笔握手与保活）
配置下发 / 关键指令    → TCP（不能丢、要重传、要顺序）
视频 / 大量流          → 看封装（多数流协议自己管重传，可不必依赖 TCP）
对时延敏感的工业控制   → UDP 短小 + 上层补重传（宁快勿卡）
SSL/TLS 加密连接       → 几乎总走 TCP（TLS 需要面向连接的稳定信道）
​

这张小抄提醒两件事：其一，选层不是"一律 TCP 最稳"，而是按"丢不丢得起"标价；其二，TCP/UDP 与上层协议是绑定的——MQTT 锁 TCP、CoAP 锁 UDP，改一头就要重新权衡。这里切不可只盯着"速率"，把"功耗与实现复杂度"交给小抄帮你看着。

六、IPv6 的 128 位长什么样：地址写法与压缩

IPv6 把地址从 IPv4 的 32 位拉到 128 位，写法也变了，第一次看见会不习惯。它用冒号分隔的 8 组十六进制，例如：

2001:0db8:85a3:0000:0000:8a2e:0370:7334
​

两种缩写规则：每组开头的 0 可省略（0000 → 0）；一组或多组全 0 可压缩成 ::（只能在地址里出现一次）。连续零特别多的局域网地址写出来就会短很多，比如 fe80::1 实际就是 fe80:0000:...:0001 的缩写。对物联网这种地址数量极其重要的场景，IPv6 的"地址几乎取之不尽"就是把 IPv4 时代那句"NAT 挤地址、设备出不了内网"的老账彻底翻篇。

落到受限链路，还有一层 6LoWPAN 的压缩要懂：IPv6 报文头在无损链路上几十字节，对只有几百字节一帧的 802.15.4 传感网太大。6LoWPAN 会把 IPv6 头、UDP 头大幅压缩，把"公用上下文"里的地址缩写掉，硬是把头开销压到十几甚至就几个字节。这让低功耗 6LoWPAN 传感网能跑完整的 IPv6 语义——设备有真地址、可直接被从任何地方寻址，而不是靠 NAT 藏在内网。这正是 IPv6 在物联网"不只多地址，而是能端到端寻址"的深层价值。

七、传输层上常被忽略的两道暗沟

选完 TCP/UDP 还没完，有两个传输层细节经常在项目后期才冒出来：

• MTU 与分片：UDP 报头小，但底层链路帧大小（MTU）有限。一条超长 UDP 报文会被链路层分片，中间任何一片丢了整条就废。传感数据普遍很小通常没事，可一旦升级固件、传输较大包，就要用前面 CoAP 的 Blockwise 之类机制去配合，别让 UDP 单包硬撑。
• TCP 半开连接：设备掉电但没发 FIN，TCP 连接会卡在"半开"状态长期占资源。设备反复异常断电时，这类僵尸连接会悄悄把网关和服务器耗尽。解决靠应用层的心跳/超时回收（比如 MQTT 的 Keep Alive 这种机制兜底），传输层本身不救命。

两道暗沟都不在你选 UDP/TCP 的那一刻暴露，却会在弱网/大包/断电频发的实操里集体演出。把它们写进测试清单，比等量产后返工强得多。

八、IPv4 与 IPv6 的共存桥接：过渡期怎么活

理想情况下都上 IPv6，现实里网络还是 IPv4 的天下，两者要共存。这层桥接机制常被物联网项目忽略，却在跨网关接入时躲不开：

• 双栈（Dual Stack）：设备同时配 IPv4 和 IPv6 两套地址，能连哪种就谈哪种。最平滑，但也耗一点资源，受限节点要掂量。
• 隧道（Tunneling）：把 IPv6 报文封装进 IPv4 包里穿过去，适合"广域还是 IPv4、部分节点想跑 IPv6"的过渡期。
• 翻译（如 NAT64）：在边界上把 IPv4/IPv6 地址互相翻译，让只懂一种的双方也能互通，但常伴随应用层部分功能损失。

对一台物联网设备，关键不是把三种机制都实现，而是确认上游平台和网关支持你的地址族：如果你的设备只有 IPv6，而云平台或 CDN 只提供 IPv4 端点，没有翻译机制就会"明明联网却连不上"。所以上 IPv6 前，把"两头到底支不支持同一族地址 / 中间有没有翻译"这条链路跑通，比纠结哪种机制更高级更重要。IPv6 的优势要建立在"整条链都认它"的基础上，否则优势会被桥接的那点别扭抵消大半。

本节要点回顾

• 地址危机：IPv4 总地址不够，海量物联网设备优先走 IPv6。
• IPv6 优势：公网地址直接给，不用 NAT，报头简化，省电。
• TCP 取舍：握手连接 + 重传 → 可靠但费电；适合控制指令。
• UDP 取舍：无连接 + 发完走 → 轻省但不保证；适合传感上报。
• 上下对齐：CoAP 配 UDP，MQTT 配 TCP，都是天生的。

到这一章结束，全书所有层已经讲完——从一颗传感数据的诞生，到物理传输、组网、上层协议，最后抵达平台，全链路通了。