TCP、UDP、QUIC 与常见应用协议：如何选型和排查网络故障

协议选型先看它位于哪一层。TCP、UDP 和 QUIC解决“数据怎样传输”，HTTP、SSE、WebSocket、gRPC 和 MQTT 解决“应用怎样交流”，Kafka 则是服务端事件流平台，不是浏览器或设备直接使用的网络替代品。

先看协议地图

1
2
3
4
5

应用层：HTTP | SSE | WebSocket | gRPC | MQTT | Kafka Client Protocol
安全层：TLS
传输层：TCP | UDP | QUIC
网络层：IP
链路层：Ethernet | Wi-Fi | 蜂窝网络

协议可以组合。例如 HTTPS 通常是 HTTP over TLS over TCP；HTTP/3 运行在 QUIC 之上，而 QUIC 基于 UDP 实现自己的可靠传输与加密机制。

TCP、UDP 与 QUIC

UDP 不是“更快的 TCP”。它只是约束更少，丢包、重传、排序和拥塞控制要由上层协议按业务需要处理。

应用协议怎么选

AI 对话逐字输出通常适合 SSE；在线协作和游戏更常使用 WebSocket；设备遥测适合 MQTT；跨服务事件流水线适合 Kafka。

分层排障流程

1
2
3
4
5
6
7
8

1. 域名能否解析
2. IP 路由是否可达
3. 目标端口是否监听且防火墙放行
4. TCP/QUIC 连接能否建立
5. TLS 证书与握手是否正常
6. 反向代理和路由是否命中
7. 应用是否超时或报错
8. 缓存、数据库和下游是否健康

常用检查命令：

1
2
3
4

dig example.com
curl -v https://example.com/health
nc -vz example.com 443
openssl s_client -connect example.com:443 -servername example.com

ping 不通不能直接证明网站不可访问，因为 ICMP 可能被禁用；curl 成功也不能证明所有业务接口正常。

从现象快速定位

设计时保留可观测性

客户端、网关和应用应使用同一个请求 ID 串联日志，并分别记录 DNS、连接、TLS、首字节和总耗时。只有“接口耗时 3 秒”时，很难判断时间究竟花在网络、排队、数据库还是下游接口。

延伸阅读

• MDN：Server-sent events
• MDN：WebSocket API
• RFC 9000：QUIC