这里提到的连接到底是啥？

TCP通过上面提到的各种机制实现了数据的可靠性。这些机制背后是通过一个个数据结构来实现的逻辑。而为了实现这套逻辑，操作系统内核需要在两端代码里维护一套复杂的状态机（三次握手，四次挥手，RST，closing等异常处理机制），这套状态机其实就是所谓的"连接"。这其实就是TCP的连接机制，而UDP用不上这套状态机，因此它是"无连接"的。

网络环境链路很长，还复杂，数据丢包是很常见的。

我们平常用TCP做各种数据传输，完全对这些事情无感知。

哪有什么岁月静好，是TCP替你负重前行。

这就是TCP三大特性"面向连接、可靠的、基于字节流"中"可靠"的含义。

不信你改用UDP试试，丢包那就是真丢了，丢到你怀疑人生。

用UDP就一定比用TCP快吗？

这时候UDP就不服了："正因为没有这些复杂的TCP可靠性机制，所以我很快啊"

嗯，这也是大部分人认为UDP比TCP快的原因。

实际上大部分情况下也确实是这样的。这话没毛病。

那问题就来了。

有没有用了UDP但却比TCP慢的情况呢？

其实也有。

在回答这个问题前，我需要先说下UDP的用途。

实际上，大部分人也不会尝试直接拿裸udp放到生产环境中去做项目。

那UDP的价值在哪？

在我看来，UDP的存在，本质是内核提供的一个最小网络传输功能。

很多时候，大家虽然号称自己用了UDP，但实际上都很忌惮它的丢包问题，所以大部分情况下都会在UDP的基础上做各种不同程度的应用层可靠性保证。比如王者农药用的KCP，以及最近很火的QUIC（HTTP3.0），其实都在UDP的基础上做了重传逻辑，实现了一套类似TCP那样的可靠性机制。

教科书上最爱提UDP适合用于音视频传输，因为这些场景允许丢包。但其实也不是什么包都能丢的，比如重要的关键帧啥的，该重传还得重传。除此之外，还有一些乱序处理机制。举个例子吧。

打音视频电话的时候，你可能遇到过丢失中间某部分信息的情况，但应该从来没遇到过乱序的情况吧。

比如对方打网络电话给你，说了："我好想给小白来个点赞在看！"

这时候网络信号不好，你可能会听到"我….点赞在看"。

但却从来没遇到过"在看小白好想赞"这样的乱序场景吧？

所以说，虽然选择了使用UDP，但一般还是会在应用层上做一些重传机制的。

于是问题就来了，如果现在我需要传一个特别大的数据包