网络编程协议研究

1. 协议关系总览

传输层
├── TCP（内核）
│   └── TLS（用户态）
│       ├── HTTP/1.1
│       ├── HTTP/2 ─── gRPC
│       ├── WebSocket（HTTP Upgrade 后全双工）
│       ├── SSE（HTTP 长连接单向推送）
│       └── MQTT（也可 over WebSocket）
│
└── UDP（内核）
    ├── QUIC（用户态，内建 TLS 1.3）
    │   └── HTTP/3 ─── WebTransport
    └── KCP（用户态可靠库，非 Web 标准）

协议	分层	实现位置	承载
TCP	传输层	内核	IP
UDP	传输层	内核	IP
QUIC	传输层语义	用户态	UDP
KCP	传输层语义	用户态库	UDP
TLS	安全层	用户态（为主）	TCP；或内置于 QUIC
HTTP/1.1、HTTP/2	应用层	用户态	TCP + TLS
HTTP/3	应用层	用户态	QUIC
WebSocket	应用层	用户态	TCP（先 HTTP 升级）
SSE	应用层	用户态	HTTP
gRPC	应用层 RPC	用户态	通常 HTTP/2
MQTT	应用层消息	客户端 + Broker	TCP / TLS / WebSocket
WebTransport	应用层 API	浏览器 + 服务端	HTTP/3

要点：

TCP / UDP：操作系统提供的传输能力。
QUIC / KCP：在 UDP 之上自己做可靠、拥塞、多路等，更像「传输层替代方案」。
HTTP / WebSocket / MQTT / gRPC：应用协议，不负责底层丢包重传（除非底下是 QUIC/KCP）。

2. 实现位置怎么理解

位置	含义	工程含义
内核	OS 协议栈（TCP/UDP）	通过 socket 使用；调优多靠内核参数
用户态	进程内协议实现（QUIC、多数应用协议）	行为随实现版本变化；升级不必等内核
中间件	网关、CDN、Broker、反向代理	协议常在这里终结或转发

3. 传输层

3.1 TCP

项	说明
原理	面向连接的可靠字节流。三次握手建连、四次挥手断开；用序号与 ACK 确认数据；丢包重传；滑动窗口做流量控制；内核实现拥塞控制（如 Cubic、BBR）。连接身份是四元组（源 IP、源端口、目标 IP、目标端口）——换网导致地址变化时，旧连接通常失效。数据是连续字节流，不保留「消息边界」。
应用场景	Web / API / 后台服务；数据库与缓存客户端（MySQL、PostgreSQL、Redis 等）；邮件（SMTP/IMAP）；SSH/远程桌面；绝大多数需要可靠有序的业务底座。
实现位置	内核传输层。
优点	兼容性最强；基础设施与排障工具最成熟。
注意	自身不加密（需叠 TLS）；单连接存在传输层队头阻塞；移动换网易断。

3.2 UDP

项	说明
原理	无连接数据报：发出去就算完，不保证到达、顺序、去重。每个数据报有边界，但无重传、无拥塞控制——这些都交给上层（若需要）。
应用场景	DNS 查询；实时音视频（WebRTC 媒体、VoIP）；在线游戏状态同步；直播推流底层；P2P / NAT 打洞；服务发现与心跳探测；以及作为 QUIC / KCP 的承载。
实现位置	内核传输层；可靠性策略由上层用户态实现。
优点	延迟低、无连接状态、适合自定义可靠策略。
注意	业务要自己处理丢包、乱序、拥塞；部分防火墙/NAT 对 UDP 更挑剔。

3.3 QUIC

项	说明
原理	跑在 UDP 上的现代传输协议。用 Connection ID 标识连接（可与 IP/端口解耦，支持连接迁移）；一条连接上多条独立 stream；强制 TLS 1.3（握手与加密一体化）；某条 stream 丢包通常不阻塞其他 stream，从而缓解 TCP 级队头阻塞；支持 0-RTT 降低建连延迟。
应用场景	手游 / 对战与实时同步（弱网、切网）；移动 App 长连接与推送通道；公网 CDN / 站点加速（HTTP/3）；直播与低延迟媒体接入；VPN / 安全隧道类产品；WebTransport 与部分自研实时协议。
实现位置	多为用户态（浏览器、CDN、服务端库）；内核一般只提供 UDP。
优点	换网不断连、默认加密、多路且流间阻塞更轻、建连更快。
注意	UDP 可能被限制；中间件成熟度低于 TCP；公网部署通常需 HTTP/2 回落。

为何游戏更常看 QUIC（TCP 很难搞定的两点）：

网络不稳定 / 常换网（手游 WiFi ↔ 4G/5G、弱网抖动）
TCP 连接绑死四元组，地址一变就断，要重连、重鉴权，对局里会「闪一下」。QUIC 用 Connection ID，换网后往往能接着打。
丢几个包不该拖垮整条体验
TCP 单连接队头阻塞：丢 1 个包，后面所有数据都可能卡住等重传——信令、状态、资源下载互相拖累。QUIC 多 stream 相对独立，一条流丢包通常不堵死其他流；关键可靠通道与可容忍延迟的通道可以分开，丢包对整体手感的影响小得多。

补充：若业务本身就是「这个状态包丢了就算了、下一帧覆盖」，还可叠加 QUIC datagram / 不可靠通道；那是「允许丢」的语义。上面第 2 点强调的是：即便要可靠传输，也不该像 TCP 那样「一丢全停」。

3.4 KCP

项	说明
原理	基于 UDP 的用户态可靠传输库。通过可配置的 ARQ/重传追求弱网下更低延迟；无内建 TLS，也无标准 HTTP/Web 映射——加密与业务帧需自行设计。
应用场景	强实时对战手游（帧同步/状态同步）；网游加速与专有客户端弱网通道；直播互动中的低延迟自定义链路；内网/专线可控双端的实时同步。
实现位置	用户态库（业务进程内）。
优点	弱网延迟可控、参数可调。
注意	浏览器不能原生使用；不是 IETF Web 标准；不要与 QUIC/HTTP/3 混为一谈。

传输层对比

能力	TCP	UDP	QUIC	KCP
可靠有序	是	否	是（按流）	可配置
内建加密	否（靠 TLS）	否	是	否
多路复用	需上层	自行实现	原生	自行/上层
队头阻塞	有	无	流间基本无	取决于用法
连接迁移	弱	无状态	强	需自行做
浏览器原生	是	受限	是（HTTP/3 等）	否
标准化	极高	极高	高（IETF）	库级方案

4. 安全层

4.1 TLS

项	说明
原理	在传输之上提供加密、完整性校验、证书身份认证。常见组合：`TCP + TLS` → HTTPS / WSS。在 QUIC 中，TLS 1.3 内嵌强制启用，不是「先建 TCP 再套一层」的模型。
应用场景	HTTPS / WSS 公网流量；OpenAPI 与开放平台接入；支付与登录等敏感接口；企业内部 mTLS；服务网格（Sidecar 间互信）；邮件提交加密（SMTPS）等。
实现位置	用户态为主；也可内核 TLS。QUIC 实现内部绑定 TLS 1.3。
端口习惯	`443` HTTPS；`8883` MQTT over TLS（常见约定）。

正确表述：TCP 本身不加密，安全依赖上层 TLS；QUIC 把 TLS 做成传输的一部分并强制启用。不要写成「TCP 一定不安全」。

5. 应用层（TCP 系）

5.1 HTTP/1.1

项	说明
原理	请求-响应模型。默认 keep-alive 复用同一 TCP 连接；但同连接上请求大致串行——前一个响应慢，后面容易堵住（应用层队头阻塞）。头部是明文文本，重复开销大。浏览器常靠多连接并行弥补。
应用场景	REST / CRUD API；表单提交与传统网站；静态资源与文件下载；Webhook 回调；老旧客户端 / 企业代理兼容；抓包调试友好的接口。
实现位置	用户态（Web 服务器 / 应用进程）。

5.2 HTTP/2

项	说明
原理	把 HTTP 语义改成二进制分帧：一条连接上多路复用多个请求/响应；用 HPACK 压缩头部。解决了 HTTP/1.1 的应用层队头阻塞，但底层仍是一条 TCP——丢一个包仍可能拖慢整连接上的所有流。
应用场景	现代网站与 SPA 资源加载；API 网关南北向流量；移动 App 后端 API；gRPC 默认承载；代理与服务网格中的 h2 通信。
实现位置	用户态（HTTP 栈 / 代理 / CDN）。

5.3 gRPC

项	说明
原理	应用层 RPC 框架。接口用 IDL（通常 Protobuf）定义；默认跑在 HTTP/2 上，利用其流与二进制帧。通信模式：Unary（普通调用）、服务端流、客户端流、双向流。
应用场景	微服务同步调用；多语言团队共享 IDL 契约；服务端流式推送（行情片段、日志、推理结果）；客户端大批量上报；双向流（实时对讲控制面、交互式会话）；内部高 QPS 接口。
实现位置	用户态（IDL 生成代码 + 运行时）。
注意	浏览器通常不能直连原生 gRPC，需 gRPC-Web 或网关转码；依赖端到端 HTTP/2。

5.4 WebSocket

项	说明
原理	先走 HTTP Upgrade 握手；成功后协议切换为全双工消息帧通道，之后不再是请求-响应语义。双方可随时发文本或二进制帧。协议本身不管帧里是什么内容。
应用场景	IM / 群聊；在线文档与白板协同（光标、操作广播）；证券/外汇行情推送；游戏大厅与轻量信令；客服坐席；设备远程控制台；后台管理实时刷新。
实现位置	用户态（应用服务器）；经反向代理时需开启 Upgrade / 长连接。
注意	消息格式、心跳、重连、连接管理通常要业务自己做。

5.5 SSE（Server-Sent Events）

项	说明
原理	本质仍是 HTTP：服务端返回持久响应，`Content-Type: text/event-stream`，持续写入事件流。浏览器 `EventSource` 支持自动重连，并可带 `Last-Event-ID` 做断点续传。模型是单向：服务器 → 客户端。
应用场景	LLM / AI 对话 token 流式输出；任务进度条与导入导出进度；运维日志 / 构建日志尾随；站内通知与告警条；比分/状态看板；审批结果推送。
实现位置	用户态；普通 HTTP 长响应即可。
何时选 SSE	只需服务端推送；想复用 HTTP 鉴权、网关、CDN。
何时仍选 WebSocket	需要真正双向、二进制帧、自定义子协议。

5.6 MQTT

项	说明
原理	发布/订阅消息协议。客户端连到 Broker，按主题发布或订阅；QoS 0/1/2 提供不同可靠级别；可保持会话。经典跑在 TCP/TLS 上；浏览器场景常用 MQTT over WebSocket。
应用场景	智能家居与工业 IoT；车联网遥测；电表/传感器周期上报；共享设备状态同步；边缘网关汇聚；需要遗嘱消息（Last Will）与离线会话的设备链路。
实现位置	用户态客户端 + Broker（消息中间件）。
分工	MQTT 擅长主题订阅与海量设备；纯 Web 管理端实时通知，WebSocket / SSE 往往更直接。

6. 应用层（UDP / QUIC 系）

6.1 HTTP/3

项	说明
原理	HTTP 的方法、状态码、头、正文语义不变，但映射到 QUIC streams 上传输。保留 HTTP/2 的多路复用能力，并借助 QUIC 缓解 TCP 级队头阻塞；握手与加密一体化，建连通常更快。
应用场景	公网站点与静态资源加速（尤其移动弱网）；电商 / 资讯 App 首屏与接口加速；跨国访问降延迟；浏览器大量小资源并行加载；常与 HTTP/2 回落并存（如 Alt-Svc 发现）。
实现位置	用户态；部署上常由 CDN / 网关终结 HTTP/3。
注意	需要 UDP（常见 443）；内网微服务未必优先上 h3，除非有明确延迟/丢包收益。

与 HTTP/2 的关键差异：

HTTP/2 over TCP:
  多个请求复用一条 TCP
  └─ 丢 1 个 TCP 包 → 整条连接上的多个流都可能等待

HTTP/3 over QUIC:
  多个请求对应多个 QUIC stream
  └─ 某 stream 丢包 → 主要影响该 stream，其他 stream 通常可继续

6.2 WebTransport

项	说明
原理	浏览器提供的现代传输 API，主要基于 HTTP/3 / QUIC。可开多条可靠流，也支持不可靠 datagram；双向、可配置性比 WebSocket 更接近「传输能力」。
应用场景	浏览器端低延迟游戏与互动直播；云游戏 / 云桌面控制通道；多人协作里「位置可丢、操作需可靠」的混合通道；自定义实时协议需要多流隔离时。
实现位置	浏览器 API + 服务端用户态实现。
注意	生态相对新；常需回落 WebSocket。

WebSocket vs WebTransport

维度	WebSocket	WebTransport
底层	TCP + TLS	QUIC / HTTP/3
不可靠消息	不支持	支持 datagram
多流	需自行拆	原生多 stream
队头阻塞	受 TCP 影响	更好
生态	非常成熟	相对新
兜底	广泛可用	常回落 WS

7. 场景选型

场景	更合适	备选
普通 REST / CRUD	HTTP/1.1 或 HTTP/2	HTTP/3（公网接入）
后台管理 / 开放 Webhook	HTTP/1.1	HTTP/2
现代网站大量小资源并行	HTTP/2	HTTP/3（公网）
微服务 RPC / 多语言契约	gRPC（HTTP/2）	REST
AI 对话流式输出 / 任务进度	SSE	WebSocket
IM、协同编辑、行情双向推	WebSocket	WebTransport
浏览器云游戏 / 要不可靠包	WebTransport	WebSocket + 自研
手游 / 对战：弱网、切网、丢包别卡死	QUIC	KCP / 自定义 UDP（极致可控双端）
极致弱网、双端可控非浏览器	KCP	QUIC
IoT / 车联网 / 传感器上报	MQTT	HTTP 短轮询
数据库、缓存、SSH 等可靠通道	TCP（+TLS）	—
DNS / 音视频媒体 / P2P 打洞	UDP	QUIC（若要可靠+加密一体）
公网 Web / App 接入加速	HTTP/3	HTTP/2 回落
手机 App 长连接（切网多）	QUIC	TCP + 应用重连
支付 / 登录等敏感公网接口	TCP + TLS（HTTPS）	—
企业内网受控环境	TCP 系	QUIC 可能被限制

决策顺序

客户端是谁？ 浏览器 / APP / 服务间 / 设备
传输层： 要最大兼容 → TCP；要换网不断 / 弱网多路 → 评估 QUIC（并准备回落）
是否要标准生态？ 要 → HTTP 族 / WS / MQTT / gRPC；否且双端可控 → 可考虑 KCP
单向还是双向？ 单向推送 → SSE；双向 → WebSocket / WebTransport / gRPC stream
要不要不可靠通道？ 要 → WebTransport datagram / 纯 UDP

实用默认：

默认：TCP + TLS + HTTP/2 / WebSocket / gRPC
公网加速：HTTP/3 为主 + HTTP/2 回落
单向推送：优先 SSE，不够再上 WebSocket
仅双端可控且标准不够用时，再引入 KCP / 自定义 UDP

目录

1. 协议关系总览

2. 实现位置怎么理解

3. 传输层

3.1 TCP

3.2 UDP

3.3 QUIC

3.4 KCP

传输层对比

4. 安全层

4.1 TLS

5. 应用层（TCP 系）

5.1 HTTP/1.1

5.2 HTTP/2

5.3 gRPC

5.4 WebSocket

5.5 SSE（Server-Sent Events）

5.6 MQTT

6. 应用层（UDP / QUIC 系）

6.1 HTTP/3

6.2 WebTransport

WebSocket vs WebTransport

7. 场景选型

决策顺序