1.选型总思路
- 要“必须送到、顺序正确”——选 TCP有连接、可靠重传、流量控制、拥塞控制，代价是首包慢、开销大。
- 要“尽量实时、丢一点无妨”——选 UDP无连接、首部仅 8 B，无重传与拥塞算法，时延小但丢包靠应用层自救。
- 要“同时要实时又要可靠”——上层再封装典型如 QUIC、RTP + FEC、SRT 等，把 UDP 当“裸信道”自行加重传或纠错。
2.TCP 的典型应用场景
场景 | 为什么用 TCP |
Web 访问（HTTP/HTTPS） | 浏览器/SEO/中间件生态 + 内容必须全到位 |
文件传输（FTP、SFTP、SCP、rsync） | 一字节也不能缺；窗口 + 慢启动可充分利用带宽 |
数据库长连接（MySQL、PostgreSQL、MongoDB…） | 事务一致性、顺序强依赖 |
电子邮件（SMTP、POP3、IMAP） | 收件内容完整性 > 延迟 |
远程登录（SSH、Telnet、RDP） | 字节流交互、错一字崩盘 |
消息队列 / 业务 RPC（HTTP/2、gRPC、Thrift over TCP） | 需要严格 ack 与重试；TCP Keep-Alive 便于健康探测 |
物联网固件升级、配置下发 | 固件包完整性要求高 |
区块链节点同步（Bitcoin、Ethereum） | 区块/交易必须严格递送 |
3.UDP 的典型应用场景
场景 | 关键诉求 | UDP 如何匹配 |
实时语音 / 视频（VoIP、WebRTC、RTSP/RTP） | 延迟 < 150 ms，丢 1% 可忽略 | 无重传，边播边丢也不卡；上层可自带 FEC |
在线游戏（FPS、MOBA） | 帧间隔 16–33 ms，需要极低抖动 | 丢一帧位置包玩家几乎感觉不到 |
直播推流（RTP、SRT、QUIC） | “越实时越好”，遇丢包亏画质也行 | UDP + 自研 ARQ/FEC |
DNS（53/UDP） | 查询包通常 < 512 B，失败可重发 | 成本低、QPS 高 |
DHCP / BOOTP | 需要广播/组播、无连接 | TCP 无法广播 |
NTP 时钟同步 | 请求小，追求毫秒级延迟 | UDP 单往返即可 |
局域网广播（UPnP、mDNS、SSDP） | 发现设备/服务 | UDP 原生广播/组播 |
SNMP、Syslog | 监控日志，允许部分丢失 | 轻量无连接 |
高频交易、证券行情 | 微秒级行情推送 | 专网 + UDP 单播，应用自校验 |
NAT 打洞 / P2P（STUN、TURN） | 需在对称 NAT 中传数据 | UDP 更易穿透 |
4.混合 & 演进场景
技术 | 说明 |
QUIC (HTTP/3) | 基于 UDP，但自带 0-RTT、可靠传输与多路复用 → “UDP 皮，TCP 心” |
RTP + RTCP + SRTP | 流媒体主包走 RTP，控制包 RTCP，安全包 SRTP |
SRT / UDT | 视频链路上层 ARQ，UDP 仅做承载 |
gRPC over QUIC | 兼顾双向流与长 Bidi Stream |