TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Datagram Protocol，用户数据报协议）是互联网上两种最基础的传输层协议。一句话概括：TCP 保证数据完整、按顺序送达，UDP 只负责尽快把数据发出去，不管有没有送到、顺序对不对。
一个寄挂号信，一个拿喇叭喊
TCP 像寄挂号信：先确认双方都在（三次握手建立连接），每封信编号，收件人要签收（确认应答 ACK），信丢了就重寄（超时重传），到得乱了帮你按序号排好。代价是慢半拍——建连接至少等一个往返，丢一个包整条队伍都得停下来等它补齐。
UDP 像在嘈杂操场上拿喇叭喊话：不建连接、不编号、不签收，喊完就忘。它的头部只有 8 字节，TCP 头部最少 20 字节，开销差距从第一个字节就开始了。丢一个包？那就是丢了，协议本身不管。
实时通话为什么偏爱 UDP
因为对声音和画面来说，“晚到”等于“没到”。语音通常几十毫秒发一包，一个包丢了，等重传回来可能已经过去两三百毫秒——播放器这时早已播到后面去了，补一个旧音节只会造成卡顿。所以它宁可不管，用丢包隐藏（PLC）拿前面的音频外推一小段糊过去；视频同理，宁可某一帧花掉，也不能整幅画面冻住两秒。
WebRTC 这类实时通信框架默认走 UDP，再把“可靠性”按需加回来：前向纠错（FEC）多发一点冗余数据，只对关键帧做有限重传。不是不要可靠，而是只在对体验有好处的地方要。
文件传输和 API 调用为什么离不开 TCP
因为这里一个字节都不能错。少一段文件就损坏，顺序乱了 JSON 就解析失败，一个请求丢了却没人重发，前端就会一直转圈。HTTP/HTTPS（在 HTTP/3 之前）、文件传输、数据库连接几乎都架在 TCP 上，应用层自己不用操心重传和排序。
| 维度 | TCP | UDP |
|---|---|---|
| 连接 | 先握手建立连接 | 无连接，直接发 |
| 可靠性 | 确认 + 重传，不丢不重 | 尽力而为，允许丢包 |
| 顺序 | 保证按序交付 | 不保证 |
| 开销 | 头部大，有拥塞控制 | 头部小，几乎无状态 |
| 典型场景 | 文件、网页、API 调用 | 语音、视频、游戏、直播 |
一句话怎么选
问自己：这份数据晚到一秒还有价值吗？有，就用 UDP；没有，就用 TCP。做 AI 产品时，调模型接口、传数据集、拉日志走 TCP；语音对话、实时字幕、数字人推流走 UDP 系（QUIC 也算这一类，它在 UDP 之上重建了可靠传输与加密）。
补充一句：UDP 并不等于“更快”，它只是“更不啰嗦”。在网络质量差的环境里，TCP 反复重传反而可能更慢——这也是实时场景坚持用 UDP 的现实理由。具体实现细节与浏览器支持情况，以官方文档为准。