三亩地 三亩地SAN MU DI · CODE DIARY
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天,欢迎挑你感兴趣的翻一翻。

TCP 和 UDP的应用场景

TCP 和 UDP的应用场景

1. TCP 的核心应用场景

原则:数据错一个字节都不行,延迟几百毫秒可以忍。

场景分类具体应用为什么必须用 TCP
Web 浏览HTTP/HTTPS (HTTP/1.1, HTTP/2)网页文本、CSS、JS 丢失会导致页面白屏或功能失效
文件传输FTP, SFTP, SCP, BT种子(控制信令)文件校验失败等于传输作废,必须重传
电子邮件SMTP, POP3, IMAP邮件内容不能丢字、乱序,附件必须完整
数据库MySQL, PostgreSQL, Redis, MongoDBSQL 指令或查询结果丢失会导致数据不一致或事务失败
远程管理SSH, Telnet, RDP命令输入必须准确送达,屏幕像素需无损还原
API 通信RESTful API, gRPC, GraphQL后端服务间调用要求请求/响应严格匹配
消息队列RabbitMQ, Kafka (元数据/控制面)消息投递确认、消费者偏移量提交不容有失
区块链节点同步、交易广播区块数据和交易哈希必须绝对准确

注意:HTTP/3 已迁移至 QUIC(基于 UDP),但截至 2026 年,全球仍有约 70% 的 Web 流量使用 TCP 承载的 HTTP/1.1 和 HTTP/2。

2. UDP 的核心应用场景

原则:迟到的正确数据 = 垃圾,宁可丢帧也不能卡顿。

场景分类具体应用为什么选 UDP
实时音视频通话Zoom, Teams, FaceTime, 微信视频延迟 >300ms 对话就会重叠,丢帧比卡顿体验好
在线游戏FPS (CS2, Valorant), MOBA (LOL), 赛车玩家位置/操作指令过时即无效,重传导致"瞬移"
直播推流/连麦OBS 推流, 抖音/B站连麦互动单向观看可容忍 1-3s 延迟(TCP也可),但连麦必须 <500ms
DNS 查询域名解析 (默认)请求/响应通常 <512 字节,一次 UDP 往返即可完成
IoT / 传感器MQTT-SN, CoAP, 工业遥测设备资源受限,心跳/状态上报允许偶尔丢失
网络时间同步NTP, PTP时间戳本身就有有效期,重传旧时间毫无意义
广播/组播局域网发现, IPTV, 股票行情推送TCP 不支持一对多,UDP 天然支持广播/组播
语音对讲对讲机 App, 游戏内语音人耳对短暂丢包不敏感,但对延迟极度敏感

3. 特殊场景:TCP 与 UDP 混合使用

很多现代应用并非二选一,而是按数据类型分流

应用TCP 负责UDP 负责设计逻辑
网络游戏登录、聊天、商城、好友列表移动、射击、技能释放社交数据要可靠,战斗数据要实时
视频会议信令(入会/离会)、文件共享、白板音视频流、屏幕共享控制指令不能丢,媒体流不能卡
直播平台弹幕、点赞、礼物、用户信息音视频流互动消息需可靠送达,画面优先流畅
智能家居设备配网、固件升级、历史记录实时视频、传感器心跳关键操作走 TCP,持续流媒体走 UDP
QUIC/HTTP3全部(含原 TCP 场景)在 UDP 上重建可靠性,兼顾两者优势

4. 选型决策树

当你不确定该用哪个时,可以问自己三个问题:

你的业务能容忍数据丢失吗? ├── 绝对不能 → TCP └── 可以容忍少量丢失 ├── 能容忍 >1秒 延迟? → TCP (更稳定、开发简单) └── 必须 <500ms 延迟? → UDP ├── 需要加密/可靠? → QUIC / WebRTC / SRT └── 纯裸数据/广播? → 原生 UDP

5. 2026 年趋势变化

  • QUIC 正在吞噬 TCP 领地:Chrome/Safari/Firefox 已默认启用 HTTP/3,Cloudflare、AWS CloudFront 等 CDN 全面支持。未来 Web API、微服务通信将逐步从 TCP 迁移到 QUIC。
  • WebRTC 成为实时通信事实标准:几乎所有浏览器原生支持,无需插件,统一了音视频通话的技术栈。
  • SRT/RIST 替代 RTMP:专业直播推流领域,基于 UDP 的 SRT 因抗弱网能力强,正快速取代基于 TCP 的 RTMP。
  • TCP 不会消失:在内网、数据中心、金融交易等稳定网络环境中,TCP 的成熟度和性能仍无可替代。

核心记忆点:TCP 保"对错",UDP 保"快慢"。没有最好的协议,只有最匹配业务的协议。

← 返回列表