前言

想象一下，当你寄出一封信，如果不借助其他通信渠道，即使邮差弄丢了你的信，你也无从得知，这便是UDP的局限。为了确保消息的传达，如果一段时间后没有收到回信以确认，你就再次寄出，循环往复，直到对方给出答复，这便是tcp的哲学。

数据包

在网络通信中，每份数据会被切成小块，每一块叫做一个数据包。

每个包都带着各自的发出方与接收方信息

包括

发送方的端口、接收方的端口、数据包总长、校验和、数据

负责搬运这些包的则是 IP 协议

但通信从来不保证顺利。包可能丢失、可能乱序、可能重复。

如果数据包在没能成功送达，发送方要如何知晓？

每收到一份数据，接收方就回一句「收到了」。发送方等不到这句答复，就认定数据丢了，原样再发一次。

重发会不会导致重复？不会。每个包都带序号，接收方按序号把包重新拼起来：

丢的能发现，乱的能重排，重的能合并。

这就像两个人打电话，一句一句对账。你说收到，我再说下一句。

代价也很明显：每一次确认都要跑个来回，时间就耗在这上面。

正式对话开始前，双方要先对一次。客户端发起连接请求，服务端接住，客户端才开始发数据。这就是常说的「三次握手」。

三次往返，是为了让两边都确认：我说的话你能听见，你说的话我也能听见。

结束的时候同样不能悄悄走掉，双方要互相道别，连接才算真正断开。

一次 TCP 对话，有头有尾，说一不二，只是每一步都要等一个回音。

UDP 选了另一套做法：没有握手，没有确认，没有重传，连序号都没有。

它把数据包往网络里一扔，能到就到，到不了就算了。

包与包之间也不保证顺序，后发的可能比先发的先到。

这像寄一张明信片：写完就投，不挂号，不签收，也不保证经过谁的手。

换来的是极小的代价——几乎不附加任何协议开销，也没有等待。

TCP 和 UDP 对应两种需求。

要考虑的是：数据是丢不起，还是等不起

网页、邮件、文件，一个字节都不能少，一般交给 TCP。通话、游戏、直播，卡一下重发反而更糟，往往由 UDP 处理——丢一帧画面没人察觉，多等 200 毫秒，团战已经打完了。

所以，通信协议之间往往没有绝对的优劣，只是为了适配实际需求，在可靠性与便捷性之间寻求平衡。