1. TCP 的核心应用场景原则数据错一个字节都不行延迟几百毫秒可以忍。场景分类具体应用为什么必须用 TCPWeb 浏览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也可)但连麦必须 500msDNS 查询域名解析 (默认)请求/响应通常 512 字节一次 UDP 往返即可完成IoT / 传感器MQTT-SN, CoAP, 工业遥测设备资源受限心跳/状态上报允许偶尔丢失网络时间同步NTP, PTP时间戳本身就有有效期重传旧时间毫无意义广播/组播局域网发现, IPTV, 股票行情推送TCP 不支持一对多UDP 天然支持广播/组播语音对讲对讲机 App, 游戏内语音人耳对短暂丢包不敏感但对延迟极度敏感3. 特殊场景TCP 与 UDP 混合使用很多现代应用并非二选一而是按数据类型分流应用TCP 负责UDP 负责设计逻辑网络游戏登录、聊天、商城、好友列表移动、射击、技能释放社交数据要可靠战斗数据要实时视频会议信令(入会/离会)、文件共享、白板音视频流、屏幕共享控制指令不能丢媒体流不能卡直播平台弹幕、点赞、礼物、用户信息音视频流互动消息需可靠送达画面优先流畅智能家居设备配网、固件升级、历史记录实时视频、传感器心跳关键操作走 TCP持续流媒体走 UDPQUIC/HTTP3—全部(含原 TCP 场景)在 UDP 上重建可靠性兼顾两者优势4. 选型决策树当你不确定该用哪个时可以问自己三个问题你的业务能容忍数据丢失吗 ├── 绝对不能 → TCP └── 可以容忍少量丢失 ├── 能容忍 1秒 延迟 → TCP (更稳定、开发简单) └── 必须 500ms 延迟 → UDP ├── 需要加密/可靠 → QUIC / WebRTC / SRT └── 纯裸数据/广播 → 原生 UDP5. 2026 年趋势变化QUIC 正在吞噬 TCP 领地Chrome/Safari/Firefox 已默认启用 HTTP/3Cloudflare、AWS CloudFront 等 CDN 全面支持。未来 Web API、微服务通信将逐步从 TCP 迁移到 QUIC。WebRTC 成为实时通信事实标准几乎所有浏览器原生支持无需插件统一了音视频通话的技术栈。SRT/RIST 替代 RTMP专业直播推流领域基于 UDP 的 SRT 因抗弱网能力强正快速取代基于 TCP 的 RTMP。TCP 不会消失在内网、数据中心、金融交易等稳定网络环境中TCP 的成熟度和性能仍无可替代。核心记忆点TCP 保对错UDP 保快慢。没有最好的协议只有最匹配业务的协议。
TCP 和 UDP的应用场景
1. TCP 的核心应用场景原则数据错一个字节都不行延迟几百毫秒可以忍。场景分类具体应用为什么必须用 TCPWeb 浏览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也可)但连麦必须 500msDNS 查询域名解析 (默认)请求/响应通常 512 字节一次 UDP 往返即可完成IoT / 传感器MQTT-SN, CoAP, 工业遥测设备资源受限心跳/状态上报允许偶尔丢失网络时间同步NTP, PTP时间戳本身就有有效期重传旧时间毫无意义广播/组播局域网发现, IPTV, 股票行情推送TCP 不支持一对多UDP 天然支持广播/组播语音对讲对讲机 App, 游戏内语音人耳对短暂丢包不敏感但对延迟极度敏感3. 特殊场景TCP 与 UDP 混合使用很多现代应用并非二选一而是按数据类型分流应用TCP 负责UDP 负责设计逻辑网络游戏登录、聊天、商城、好友列表移动、射击、技能释放社交数据要可靠战斗数据要实时视频会议信令(入会/离会)、文件共享、白板音视频流、屏幕共享控制指令不能丢媒体流不能卡直播平台弹幕、点赞、礼物、用户信息音视频流互动消息需可靠送达画面优先流畅智能家居设备配网、固件升级、历史记录实时视频、传感器心跳关键操作走 TCP持续流媒体走 UDPQUIC/HTTP3—全部(含原 TCP 场景)在 UDP 上重建可靠性兼顾两者优势4. 选型决策树当你不确定该用哪个时可以问自己三个问题你的业务能容忍数据丢失吗 ├── 绝对不能 → TCP └── 可以容忍少量丢失 ├── 能容忍 1秒 延迟 → TCP (更稳定、开发简单) └── 必须 500ms 延迟 → UDP ├── 需要加密/可靠 → QUIC / WebRTC / SRT └── 纯裸数据/广播 → 原生 UDP5. 2026 年趋势变化QUIC 正在吞噬 TCP 领地Chrome/Safari/Firefox 已默认启用 HTTP/3Cloudflare、AWS CloudFront 等 CDN 全面支持。未来 Web API、微服务通信将逐步从 TCP 迁移到 QUIC。WebRTC 成为实时通信事实标准几乎所有浏览器原生支持无需插件统一了音视频通话的技术栈。SRT/RIST 替代 RTMP专业直播推流领域基于 UDP 的 SRT 因抗弱网能力强正快速取代基于 TCP 的 RTMP。TCP 不会消失在内网、数据中心、金融交易等稳定网络环境中TCP 的成熟度和性能仍无可替代。核心记忆点TCP 保对错UDP 保快慢。没有最好的协议只有最匹配业务的协议。
