第4章网络协议基础

4、网络协议基础：TCP/IP协议栈回顾、UDP与TCP在边缘场景下的取舍、QUIC协议简介

聊边缘计算，绕不开网络协议。说白了，数据要从边缘节点上到云端，中间那根“管子”怎么传、传得稳不稳、快不快，全看协议选得好不好。

我刚开始做边缘项目时，总觉得协议这东西是底层的事，上层业务写好了就行。结果有一次，设备端上报的数据在弱网环境下反复重传，云端收到的全是乱序包，业务逻辑直接崩了。嗯，从那以后，我老老实实把TCP/IP协议栈重新啃了一遍。

这一章，咱们就回顾一下TCP/IP的核心，聊聊UDP和TCP在边缘场景下怎么选，再介绍一下QUIC这个“新秀”。

TCP/IP协议栈，说白了就是互联网的“通用语言”。它分四层：应用层、传输层、网络层、网络接口层。每一层各司其职，上层依赖下层提供服务。

我习惯把传输层看作“快递公司”。TCP是顺丰，可靠但慢；UDP是普通快递，快但可能丢件。网络层（IP）负责“地址填写”，确保包裹能送到正确的城市。网络接口层则是“最后一公里配送”，把数据从网线、Wi-Fi、4G/5G这些物理介质上发出去。

咱们重点看传输层，因为边缘场景下，选TCP还是UDP，直接影响上云体验。

我的小习惯：排查边缘节点上云延迟问题时，我通常先看传输层。很多“应用层慢”的假象，其实是TCP重传或窗口太小导致的。

边缘场景有个特点：网络环境复杂。可能是工厂车间里的Wi-Fi，可能是户外的4G基站，也可能是车联网里的移动网络。延迟、丢包、带宽波动都很大。

这时候，TCP和UDP的取舍就变得很关键。

TCP提供可靠传输，有三次握手、拥塞控制、重传机制。这些机制在稳定网络里是优势，但在边缘弱网环境下，反而成了拖累。

我曾经在项目里遇到过：边缘设备通过4G上报视频流，用了TCP。结果网络一抖动，TCP就开始慢启动、窗口缩减，视频卡成PPT。用户投诉说“你们这系统还不如对讲机”。

TCP的问题在于：它为了“不丢一个包”，宁愿牺牲吞吐量。这在实时性要求高的场景（比如视频监控、工业控制）里，很难接受。

UDP没有握手，没有重传，发出去就不管了。延迟低，开销小，适合实时性要求高的场景。

但UDP的“裸”也是双刃剑。它不保证顺序，不保证不丢包。如果业务层不做处理，数据可能乱序到达，甚至丢失。

我个人的经验是：UDP适合“丢了就丢了，不影响大局”的数据。比如传感器温度读数，每秒上报一次，丢一两个没关系。但如果是控制指令，丢了可能出事故，那就得用TCP或者自己加可靠性层。

避坑指南：我曾经在车联网项目里，用UDP传输车辆定位数据，结果因为网络丢包，云端收到的轨迹全是跳变的。后来在应用层加了简单的序列号和重传逻辑，才解决问题。记住：UDP不保证可靠，但你可以自己实现“轻量级可靠”。

TCP太慢，UDP太裸。有没有一种协议，既有TCP的可靠性，又有UDP的低延迟？

有，QUIC（Quick UDP Internet Connections）。

QUIC是Google设计的，基于UDP的传输协议。它把TCP的可靠性、TLS的安全性和UDP的低延迟结合在了一起。说白了，就是“用UDP的壳，装TCP的心”。

QUIC有几个核心优势，特别适合边缘场景：

我最近在做一个边缘AI推理项目，设备端采集视频流，通过QUIC上传到云端推理。效果比TCP好很多，尤其是在4G网络下，延迟降低了30%以上。

  核心观点：QUIC不是银弹，但它确实解决了TCP在弱网环境下的很多痛点。如果你的边缘节点需要频繁上云、网络环境不稳定、或者需要快速连接迁移，QUIC值得一试。

这一章我们回顾了TCP/IP协议栈，重点讨论了TCP和UDP在边缘场景下的取舍。TCP可靠但慢，UDP快但裸。QUIC作为“新秀”，在UDP基础上实现了可靠传输，是边缘上云的一个好选择。

我个人建议：如果你的业务对实时性要求高、网络环境差，优先考虑QUIC。如果业务简单、网络稳定，TCP也够用。UDP则适合那些“丢了无所谓”的数据。

嗯，协议选型没有标准答案，关键看你的业务场景。下一章咱们聊聊边缘节点的网络架构设计，到时候会用到这些协议知识。