TCP vs UDP
在互联网上传输数据的两种方式。TCP 建起一条可靠、有序的数据流，丢了就重传；UDP 只管把数据报发出去，也接受其中一些永远到不了。下面把两者的区别并排摆出来。
两种模型，逐一对照
建立
→
发送
→
确认
→
重传
→
送达或丢弃
在互联网上传输数据的两种方式。TCP 建起一条可靠、有序的数据流，丢了就重传；UDP 只管把数据报发出去，也接受其中一些永远到不了。下面把两者的区别并排摆出来。
TCP 与 UDP 是互联网的两大传输协议。它们都在应用之间搬运数据，却做出截然相反的承诺。TCP 承诺数据完整、按序到达；UDP 什么也不承诺——它只管发。
其它一切差异都由这个选择衍生出来。为了守住承诺，TCP 必须建立连接、给每个字节编号并确认、把丢失的重传；为了保持轻量，UDP 把这一切全省掉，所以仍有一些应用偏爱它。
用两块面板并排看最清楚：一边是带序号、被确认的数据流，另一边是没有回复、彼此独立的数据报。摆在一起后，可靠与速度之间的取舍就一目了然。
传输任何数据之前，TCP 先握手，让双方商定起始序号。这一步要多花一个往返，但正因如此，两端才能把数据当作一条连续的流来跟踪。
TCP 把数据切成数据段，并给每个字节编号。接收方靠这些编号把数据段重新排好、发现缺口，并回送确认，让发送方知道哪些已经到了。
如果迟迟收不到确认，发送方就认为该数据段丢失并重传。对应用来说，这看起来就是一条干净、有序的数据流——重传与重排都藏在底下。
UDP 没有握手，也不保存状态。发送方只是给每个数据报写上地址就发出。没有任何需要建立的东西，所以第一条消息可以立刻出发，协议本身也又小又快。
由于 UDP 从不确认任何内容，途中被丢掉的数据报就此消失，双方都收不到通知。数据报还可能乱序到达或被重复，所以需要可靠性时，只能由应用自己加。
需要正确性时用 TCP——网页、文件、邮件，凡是每个字节都必须到达的场合。需要及时性时用 UDP——实时音视频、游戏，或像 DNS 这样的一次性查询。到底选哪个，取决于迟到的包和丢失的包哪种更让人难受。
当速度比完美更重要、而且应用能容忍或自己弥补丢包时：实时音视频、在线游戏、流媒体，以及像 DNS 这样的短问答查询。迟到的数据包往往比丢失的还糟。
UDP 本身不提供任何保证：数据报可能丢失、重复或乱序，而且它不会告诉你。这并不代表它不好——只是说一旦需要可靠性，就得由应用自己加上去。
一次 DNS 查询通常就是一个小问题加一个小答案。先建立连接会白白多一个往返，所以常见情形就是一个数据报。若答案太大或回复丢失，DNS 可以回退到 TCP。
可以，在它之上再加一层即可。像 QUIC 这样的协议就在 UDP 上补上连接建立、确认与重传，既得到可靠性，又避开 TCP 的队头阻塞，这正是现代 HTTP/3 采用它的原因。
UDP 的开销通常更小，因为它省掉了连接建立与逐段确认。但“更快”取决于任务：在干净可靠的链路上 TCP 的额外工作并不贵，而当 TCP 需要重传时，UDP 反而会显得占优。