Appearance
通信协议概览
通信协议是网络中通信双方为了完成数据交换所约定的格式、顺序、动作和差错处理规则。一次完整的网络通信会同时涉及多层协议，每一层只关心自己负责的事情。理解协议先从分层入手，再针对每一层展开。
一、网络分层模型
工程中常用的两个模型：
| 层级 | OSI 七层 | TCP/IP 四层 | 代表协议 |
|---|---|---|---|
| 7 | 应用层 | 应用层 | HTTP/HTTPS、WebSocket、SSE、DNS、SMTP、FTP、SSH、gRPC |
| 6 / 5 | 表示层 / 会话层 | （并入应用层） | TLS、SSL |
| 4 | 传输层 | 传输层 | TCP、UDP、QUIC |
| 3 | 网络层 | 网络层 | IP、ICMP、ARP |
| 2 / 1 | 数据链路层/物理层 | 网络接口层 | Ethernet、Wi-Fi |
物理层管"信号怎么跑"，网络层管"包怎么寻址"，传输层管"端到端可不可靠"，应用层管"数据怎么用"。
二、传输层
应用层协议都跑在传输层之上，先把传输层这两兄弟搞清楚。
TCP（Transmission Control Protocol）
面向连接、可靠、有序、字节流。
核心机制
- 三次握手建立连接，四次挥手断开连接
- 序号 + 确认号保证有序、不丢失、不重复
- 滑动窗口做流量控制
- 拥塞控制（慢启动、拥塞避免、快速重传、快速恢复）
- 超时重传
适用场景：HTTP、HTTPS、WebSocket、数据库连接、文件传输等任何"丢一字节都不行"的场景。
代价：握手有 RTT 开销，重传和拥塞控制带来延迟，队头阻塞（HOL Blocking）。
UDP（User Datagram Protocol）
无连接、不可靠、保留消息边界。
核心特点
- 没有握手，直接发包
- 不保证到达、不保证顺序、不去重
- 头部只有 8 字节，开销小
- 天然支持广播、多播
适用场景：DNS、视频会议、实时游戏、音视频直播、物联网遥测、QUIC 的底层。
何时选 UDP：能容忍少量丢包、要低延迟、要广播多播、可靠性可以在应用层自己做。
QUIC
Google 提出、IETF 标准化的传输层协议，跑在 UDP 之上，是 HTTP/3 的底座。
关键特性
- 0-RTT / 1-RTT 握手，比 TCP+TLS 的 2~3 个 RTT 快得多
- 内置 TLS 1.3，加密是默认而不是可选
- 多路复用且没有 TCP 的队头阻塞
- 连接迁移：手机从 Wi-Fi 切到 4G 不会断流
TCP vs UDP 速查
| 维度 | TCP | UDP |
|---|---|---|
| 是否连接 | 面向连接 | 无连接 |
| 可靠性 | 可靠 | 不可靠 |
| 顺序 | 保证 | 不保证 |
| 速度 | 较慢 | 快 |
| 头部开销 | 20~60 字节 | 8 字节 |
| 流量控制 | 有 | 无 |
| 拥塞控制 | 有 | 无 |
| 数据边界 | 字节流，无边界 | 保留报文边界 |
| 典型协议 | HTTP、HTTPS | DNS、QUIC、SNMP |
三、应用层
HTTP（HyperText Transfer Protocol）
万维网的基石，请求-响应模型，明文传输，无状态。
版本演进
| 版本 | 传输层 | 关键变化 |
|---|---|---|
| HTTP/0.9 | TCP | 只支持 GET，只能传 HTML |
| HTTP/1.0 | TCP | 引入头部、状态码、Content-Type，每请求新建连接 |
| HTTP/1.1 | TCP | 长连接（Keep-Alive）、管线化、Host 头、分块传输 |
| HTTP/2 | TCP+TLS | 二进制分帧、多路复用、头部压缩（HPACK）、服务端推送 |
| HTTP/3 | QUIC | 基于 UDP 的 QUIC，解决 TCP 队头阻塞，握手更快，连接迁移 |
特点
- 无状态：靠 Cookie / Token / Session 维持状态
- 半双工：客户端发起请求，服务端被动响应，不能反向推送
- 通用性强，所有浏览器、CDN、代理都原生支持
HTTPS（HTTP over TLS）
HTTPS 不是新协议，是 HTTP + TLS。在 HTTP 和 TCP 之间插了一层 TLS。
TLS 解决三个问题
- 机密性：对称加密保护内容
- 完整性：MAC / AEAD 防篡改
- 身份认证：证书 + CA 体系防止中间人
握手过程（TLS 1.3）
- ClientHello：客户端发支持的密码套件、随机数、密钥交换参数
- ServerHello：服务端选定密码套件、返回证书和密钥交换参数
- 双方各自计算出会话密钥
- 完成握手，开始加密通信
TLS 1.3 把握手从 2-RTT 压到 1-RTT，会话恢复时还能做到 0-RTT。
WebSocket（WS / WSS）
为浏览器和服务器之间提供全双工通信而生，弥补 HTTP 不能服务端主动推送的短板。
关键点
- 通过 HTTP 的
Upgrade头握手，握手后切换协议，复用同一个 TCP 连接 - 握手完成后是独立的二进制帧协议，不再走 HTTP
- WS 走 80 端口（明文），WSS 走 443 端口（TLS 加密）
- 全双工：客户端和服务端可以同时主动发送数据
典型场景：聊天、实时协作、行情推送、在线游戏、实时通知。
HTTP 和 WebSocket 的对比单独写了一篇：http-vs-websocket.md
SSE（Server-Sent Events）
基于 HTTP 的单向服务端推送协议，浏览器通过 EventSource API 使用。
特点
- 跑在 HTTP 之上，本质是一个
Content-Type: text/event-stream的长连接 - 只能服务端推客户端，客户端要发数据还是走普通 HTTP
- 浏览器原生支持自动重连和断点续传（
Last-Event-ID） - 文本协议，调试简单
何时选 SSE 而不是 WebSocket
- 只需要服务端推、不需要客户端高频回传
- 想直接复用 HTTP/2 多路复用、CDN、鉴权中间件
- 想省去 WebSocket 的协议升级和心跳逻辑
典型应用：股票行情、日志流、ChatGPT 那种逐字输出的 AI 流式响应。
其他常见应用层协议
| 协议 | 传输层 | 用途 |
|---|---|---|
| DNS | UDP/TCP | 域名解析 |
| FTP / SFTP | TCP | 文件传输 |
| SMTP/IMAP/POP3 | TCP | 邮件 |
| SSH | TCP | 远程登录、隧道 |
| MQTT | TCP | 物联网消息推送，发布订阅模型 |
| gRPC | HTTP/2 | 高性能 RPC，基于 Protobuf |
| WebRTC | UDP | 浏览器端到端音视频通信，NAT 穿透 |
四、嵌入式与工业通信协议
前面讲的都是互联网世界的协议，跑在以太网/Wi-Fi 上。嵌入式和工业现场是另一套体系：受限于 MCU 算力、功耗、布线成本，用的是更简单、更接近硬件的协议。
板内/近距离总线
| 协议 | 物理层 | 速率 | 距离 | 关键特性 |
|---|---|---|---|---|
| UART/串口 | TX/RX 两根线 | 9600~3 Mbps | 几米 | 异步、点对点、最简单。RS-232 是电平标准，UART 是协议 |
| RS-485 | 差分两根线 | 10 Mbps | 1.2 km | UART 套差分电平，支持多机、抗干扰强 |
| I²C | SCL+SDA | 100k/400k/3.4 M | <1 m | 主从、多设备共享两线，地址寻址 |
| SPI | 4 线（含片选） | 几十 Mbps | <1 m | 全双工、速度快、无寻址，靠片选切换 |
| 1-Wire | 1 根线 | 16.3 kbps | 几十米 | 一根线既供电又通信，DS18B20 温度传感器经典 |
| CAN | 差分两根线 | 1 Mbps | 数十米 | 多主、消息优先级仲裁，汽车电子标准 |
工业现场总线 / 工业以太网
| 协议 | 基础 | 用途 |
|---|---|---|
| Modbus RTU | RS-485 | 最广泛的工业从站协议，简单、易实现 |
| Modbus TCP | TCP/IP | Modbus 套到以太网上，工厂上位机标配 |
| Profibus | RS-485 | 西门子主导的现场总线 |
| Profinet | 以太网 | Profibus 的以太网继任者，PLC 实时通信 |
| EtherCAT | 以太网 | 实时性极强的工业以太网，运动控制首选 |
| OPC UA | TCP/IP | 工业互联网信息建模与通信，承上启下 |
| LIN | 单线 | 汽车低速从网，CAN 的低成本补充 |
| FlexRay | 双通道差分 | 汽车线控、X-by-Wire |
物联网无线协议
| 协议 | 频段/标准 | 距离 | 速率/特性 |
|---|---|---|---|
| BLE 低功耗蓝牙 | 2.4 GHz | 10~100 m | 低功耗、可穿戴、Mesh |
| Zigbee | 802.15.4 | 10~100 m | 低功耗 Mesh，智能家居 |
| LoRa / LoRaWAN | sub-GHz | 数 km | 低功耗广域，远距离低速率 |
| NB-IoT / Cat-M | 蜂窝 | 蜂窝覆盖 | 运营商级低功耗广域 |
| Thread/Matter | 802.15.4 | 屋内 | IPv6 over Mesh，智能家居新标准 |
详细说明、电平时序、典型代码示例和选型建议见单独一篇：嵌入式与工业通信协议详解
五、选型速查
| 需求 | 推荐 |
|---|---|
| 普通 Web 接口、对外 API | HTTPS（HTTP/2 或 HTTP/3） |
| 浏览器实时双向通信 | WebSocket（WSS） |
| 服务端单向推流（AI 流式输出、日志） | SSE |
| 微服务内部 RPC | gRPC |
| 实时音视频 | WebRTC + UDP |
| 物联网设备上报 | MQTT |
| 对延迟敏感、可丢包 | UDP / QUIC |
| 对可靠性要求极高 | TCP |
| 弱网、移动端、要切网保活 | HTTP/3（QUIC） |
六、关于 "SSR"
SSR（Server-Side Rendering）是服务端渲染，是一种前端架构模式，不是通信协议。它本质上还是用 HTTP 把渲染好的 HTML 返回给浏览器。如果要找"服务端推送"的协议，请看 SSE 或 WebSocket。