2. 边缘设备网络基础：TCP/IP协议栈回顾、边缘设备网络拓扑、NAT穿透技术简介
好，咱们进入第二章。这一章我把它叫做“地基中的地基”。你想想看，边缘计算设备要跟云端通信，要跟其他设备组网，要建立安全隧道——这一切都建立在网络基础之上。如果网络这块搞不清楚，后面所有的VPN和隧道技术都是空中楼阁。
我个人习惯，在讲任何高级技术之前，先花点时间把底层网络模型再过一遍。别嫌啰嗦，很多线上故障，追根溯源都是TCP/IP协议栈上的小问题。
2.1 TCP/IP协议栈回顾
咱们先聊聊TCP/IP协议栈。这东西你肯定学过，但咱们今天换个角度——从边缘设备的视角来看。
TCP/IP模型分四层：应用层、传输层、网络层、网络接口层。边缘设备里，每一层都有它的“坑”。
| 层级 | 核心协议 | 边缘设备常见问题 |
|---|---|---|
| 应用层 | HTTP, MQTT, CoAP | 协议开销大，不适合低带宽场景 |
| 传输层 | TCP, UDP | TCP三次握手在弱网环境下延迟高 |
| 网络层 | IP, ICMP | NAT导致设备无法被直接访问 |
| 网络接口层 | 以太网, Wi-Fi, 4G/5G | 物理链路不稳定，丢包率高 |
嗯，这里要注意。边缘设备跟服务器不一样。服务器跑在数据中心，网络环境稳定得很。边缘设备呢？可能放在工厂车间，可能装在移动车辆上，甚至挂在野外的电线杆上。网络质量千差万别。
传输层的选择，我个人建议优先考虑UDP。为什么？
- TCP虽然可靠，但三次握手+拥塞控制，在丢包率高的链路上性能惨不忍睹。
- UDP无连接，开销小，配合应用层的重传机制，反而更灵活。
- 很多VPN隧道技术（比如WireGuard）就是基于UDP的。
2.2 边缘设备网络拓扑
聊完协议栈，咱们看看边缘设备在实际中是怎么组网的。我见过的大多数边缘部署，拓扑结构无非这么几种：
2.2.1 星型拓扑
这是最常见的。所有边缘设备直接连接到中心节点（比如一个边缘网关或者云服务器）。
- 优点： 结构简单，管理方便。
- 缺点： 中心节点是单点故障，一旦挂了，整个网络瘫痪。
- 适用场景： 智能家居、小型工厂。
2.2.2 网状拓扑
设备之间两两互联，不依赖中心节点。
- 优点： 可靠性高，一条链路断了可以走另一条。
- 缺点： 配置复杂，维护成本高。
- 适用场景： 工业物联网、军事通信。
2.2.3 混合拓扑
实际项目中，我很少见到纯粹的星型或网状。大多数是混合的——设备组成几个小星型，星型之间再通过网状互联。
2.3 NAT穿透技术简介
好，终于到了这一章的重头戏——NAT穿透。为什么边缘设备特别需要这个？
你想想看，大多数边缘设备部署在私有网络里，用的是192.168.x.x或者10.x.x.x这样的内网IP。这些IP在公网上是不可路由的。设备可以主动访问云端，但云端想主动访问设备？没门。NAT（网络地址转换）把内网IP映射成公网IP，但映射关系是动态的，而且有超时时间。
这就带来了一个问题：如何让公网上的服务主动连接到内网里的边缘设备？
我遇到过好几次这种情况：设备部署好了，远程运维需要SSH进去，结果发现设备在NAT后面，根本连不上。后来不得不派人去现场。嗯，这就是典型的NAT穿透问题。
2.3.1 常见的NAT类型
先搞清楚NAT的分类，因为不同的NAT类型，穿透难度不一样。
| NAT类型 | 特点 | 穿透难度 |
|---|---|---|
| 完全锥型NAT | 只要映射过一次，任何外网主机都可以通过该映射访问内网设备 | 容易 |
| 限制锥型NAT | 只有内网设备曾经访问过的外网主机才能回访 | 中等 |
| 端口限制锥型NAT | 在限制锥型基础上，还限制了端口 | 较难 |
| 对称型NAT | 每次请求都使用不同的映射，外网无法预测 | 极难 |
2.3.2 常用的NAT穿透技术
针对不同的NAT类型，业界有几种成熟的穿透方法：
- UDP打洞（UDP Hole Punching）： 最经典的方法。通过一个公网信令服务器交换双方的NAT映射信息，然后直接向对方的公网地址发送UDP包，建立双向通道。
- TCP打洞： 原理类似UDP打洞，但TCP的状态机更复杂，成功率低一些。
- STUN（Session Traversal Utilities for NAT）： 让设备自己去问STUN服务器“我的公网IP和端口是什么？”，然后把这个信息告诉对端。
- TURN（Traversal Using Relays around NAT）： 当打洞失败时，通过一个中继服务器转发所有流量。这是最后的保底方案。
- ICE（Interactive Connectivity Establishment）： 综合使用STUN和TURN，自动选择最优路径。WebRTC就是用的这个。
在实际的边缘计算项目中，我建议优先尝试UDP打洞。如果不行，再降级到TURN中继。ICE框架可以帮你自动完成这个决策过程。
2.3.3 一个简单的UDP打洞示例
光说不练假把式。咱们看一个简化的UDP打洞流程：
设备A（内网：192.168.1.10:5000）
设备B（内网：10.0.0.5:6000）
信令服务器（公网：203.0.113.1:7000）
步骤1：A和B分别向信令服务器注册
A -> 信令服务器: "我是A，我的内网地址是192.168.1.10:5000"
信令服务器记录A的公网映射: 203.0.113.2:12345
B -> 信令服务器: "我是B，我的内网地址是10.0.0.5:6000"
信令服务器记录B的公网映射: 203.0.113.3:23456
步骤2：信令服务器交换双方的映射信息
信令服务器 -> A: "B的公网地址是203.0.113.3:23456"
信令服务器 -> B: "A的公网地址是203.0.113.2:12345"
步骤3：A和B同时向对方的公网地址发送UDP包
A -> 203.0.113.3:23456: "Hello B"
B -> 203.0.113.2:12345: "Hello A"
此时，双方的NAT设备都认为对方是“合法”的通信方，通道建立成功。
2.4 小结
这一章咱们回顾了TCP/IP协议栈在边缘设备上的特殊性，梳理了常见的网络拓扑，最后深入聊了NAT穿透技术。说白了，边缘设备的网络环境比数据中心复杂得多，NAT穿透是建立安全隧道必须跨过的第一道坎。
下一章，咱们会基于这些网络基础，开始动手搭建真正的VPN隧道。到时候你会发现，今天讲的NAT穿透知识，会反复用到。