2、边缘设备网络基础：TCP/IP协议栈回顾、边缘设备常见的网络拓扑、NAT穿透与防火墙问题
好，咱们进入第二章。这一章我把它定位为「地基」。你想想看，边缘设备要跟云端通信，要跟其他设备组网，如果对底层的网络基础一知半解，后面选CoAP还是HTTP，很容易选错。
我个人习惯，讲任何协议之前，先带大家把TCP/IP协议栈过一遍。不是为了背七层模型，而是搞清楚：我们的数据，到底是怎么从传感器，一路跑到云端的？
2.1 TCP/IP协议栈回顾——别小看这四层
很多刚入行的朋友，总觉得TCP/IP是「老掉牙」的东西。我在项目中遇到过不止一次，有人把MQTT的QoS等级调成2，结果网络一抖，设备疯狂重传，把网关搞崩了。追根溯源，就是没理解TCP的拥塞控制机制。
咱们快速过一下四层模型，重点看边缘设备相关的部分：
| 层级 | 核心协议 | 边缘设备关注点 |
|---|---|---|
| 应用层 | HTTP, CoAP, MQTT, LwM2M | 数据格式、交互模型、功耗 |
| 传输层 | TCP, UDP, DTLS | 可靠性 vs 实时性、连接开销 |
| 网络层 | IPv4, IPv6, 6LoWPAN | 地址分配、路由、分片 |
| 链路层 | Wi-Fi, BLE, LoRa, 以太网 | 带宽、距离、功耗、冲突检测 |
这里我想强调一点：边缘设备往往不是「全功能」的TCP/IP实现。比如一个基于ESP32的传感器节点，它的RAM可能只有520KB，你不可能跑一个完整的Linux TCP栈。所以很多物联网协议栈会做裁剪，比如去掉TCP的某些高级特性，或者直接用UDP。
核心观点：边缘设备的协议栈选型，本质是在「功能完整度」和「资源消耗」之间做权衡。没有银弹。
2.2 边缘设备常见的网络拓扑——你设备在哪个位置？
搞边缘计算，第一件事就是搞清楚你的设备在网络拓扑里扮演什么角色。我见过最典型的错误，是把一个本该做「叶子节点」的设备，硬塞进了「网关」的角色，结果性能扛不住。
常见的拓扑有这么几种：
2.2.1 星型拓扑
这是最常用的。所有终端设备直接连到中心网关。比如你家里的智能灯泡，每个灯泡都连到Wi-Fi路由器。优点是简单，缺点是网关压力大，单点故障。
2.2.2 树型拓扑
边缘网关下面挂子网关，子网关下面挂终端。我在一个工厂项目里用过这种结构：车间级网关汇总产线数据，再上报到厂级边缘服务器。好处是分层管理，坏处是延迟会叠加。
2.2.3 网状拓扑
设备之间可以互相转发数据。典型的就是ZigBee或者Thread网络。每个节点既是终端也是中继。嗯，这里要注意：网状拓扑的功耗和延迟都不稳定，不适合对实时性要求高的场景。
2.2.4 点对点拓扑
两个设备直接通信，不经过中间节点。比如用蓝牙连接手机和手环。简单，但覆盖范围有限。
我的建议：如果你在做产品选型，先画一张拓扑图。把设备标出来，哪些是「数据源」，哪些是「汇聚点」，哪些是「执行器」。拓扑决定了你的通信协议是走HTTP还是CoAP，是走TCP还是UDP。
2.3 NAT穿透与防火墙问题——边缘设备上云的「拦路虎」
好，这部分是重点。很多边缘设备部署在家庭或企业内网，它们拿到的IP是私有的（比如192.168.x.x）。当设备想主动连接云端服务器时，问题不大。但反过来，云端想主动给设备发指令，就麻烦了。
为什么会这样？因为NAT（网络地址转换）设备会维护一张映射表。只有内网设备主动发出去的包，NAT才会在表中建立一条记录。外网主动发来的包，如果没有对应记录，直接丢弃。
我曾经在一个智能门锁项目里踩过这个坑。门锁在家里，用户想通过手机APP远程开门。APP发指令到云端，云端想推给门锁，结果门锁在内网，云端根本连不上。嗯，那之后我花了整整一周研究NAT穿透方案。
2.3.1 常见的NAT类型
不是所有NAT都一样。穿透难度取决于NAT的严格程度：
| NAT类型 | 行为描述 | 穿透难度 |
|---|---|---|
| 全锥型 | 只要建立过映射，任何外网IP都能访问 | 容易 |
| 受限锥型 | 只允许曾经通信过的外网IP访问 | 中等 |
| 端口受限锥型 | 限制外网IP+端口 | 较难 |
| 对称型 | 每次通信都使用不同的端口映射 | 极难 |
说白了，对称型NAT基本没法做传统的P2P穿透。遇到这种网络环境，你就别想着设备之间直连了，老老实实走中继。
2.3.2 防火墙的「潜规则」
除了NAT，防火墙也会拦截流量。很多企业网络只开放80和443端口。你如果用CoAP的默认端口5683，大概率被墙。
我建议的做法是：
- 优先使用HTTPS（443端口），兼容性最好，防火墙基本都放行
- 如果必须用CoAP，考虑CoAP over WebSocket，或者把CoAP封装在DTLS over 443
- 不要依赖UDP打洞，成功率只有60%-80%，生产环境要留后路
警告：千万不要在产品手册里写「支持NAT穿透」就以为万事大吉。我曾经在一个项目中，设备在80%的用户家里能正常工作，剩下20%死活连不上。最后发现是运营商级别的CGN（运营商级NAT）导致的。这种场景下，唯一可靠的方案是：设备主动发起长连接（WebSocket或MQTT），云端通过这个长连接下推指令。
2.3.3 实际选型建议
基于上面的分析，我给出一个简单的决策树：
- 设备在公网或有公网IP：HTTP/CoAP随便选，直接通信
- 设备在内网，但可以主动连接云端：用MQTT或WebSocket，设备做客户端，云端做服务端
- 设备在内网，且需要P2P通信：尝试UDP打洞，但必须准备中继方案作为降级
- 设备在多层NAT后（比如4G/5G网络）：放弃P2P，全部走云端中继
你想想看，如果一开始没搞清楚网络拓扑和NAT情况，等设备量产了才发现连不上云，那改造成本可就大了。所以，第二章的内容，我建议你反复看，尤其是NAT穿透那部分。后面讲CoAP和HTTP选型时，我会反复引用这里的结论。
一句话总结：边缘设备的网络基础，决定了你能用什么协议、怎么通信、会不会掉线。别急着写代码，先把网络环境摸清楚。