TCP和UDP协议有办法管理它们的饱和度吗？
当我写入饱和时，我的意思是网络拥塞：如果服务器的缓冲区已满并且客户端向服务器发送数据报 UDP/TCP 会发生什么？
这些协议是否有处理这种情况的方法，否则数据会丢失？
这是一个关于TCP/UDP基础知识的问题。出于这个原因，这个答案不会是一个完整的TCP和UDP指南。
低级协议的网络拥塞
在网络拥塞的情况下，数据发送者通常会因为数据发送API的失败而注意到它(例如BSD函数send()和sendto()(。
例如，我有GPRS上的TCP/IP的个人经验，其中网络问题导致数据发送API失败。在这种情况下，由发送方保留其数据，以便尽快发送。
接收器侧拥堵
这就是提问者实际上的想法。
让我们从UDP开始。非常简短的回答：根据其自己的设计，发送到拥塞服务器的数据将丢失。来自维基百科，英文：
[...]它没有握手对话框，因此暴露了用户的 对底层网络的任何不可靠性进行编程;没有 保证交付，订购或重复保护[...]
最后是TCP。它旨在提供 UDP 中缺少的内容。来自维基百科，英文：
TCP 提供可靠、有序且经过错误检查的流传递 在通信的主机上运行的应用程序之间的八位字节数 通过 IP 网络
这些功能是如何实现的？我无法在此答案中提供完整的TCP教程，但我可以列出实现可靠性的三个TCP基本特征：
数据包- 是有编号的(每个数据包，但我们可以说每个字节都有一个特定的序列号(
- 转播。接收方为其收到的每个数据包(但我们可以说每个字节(发送确认(ACK(。因此，发送方了解数据包尚未收到，并且可以重新传输它(允许的重新传输次数根据不同的输入和用户设置而有所不同(
- 滑动窗口。让我们用简单的方式描述它：每个对等体当前都会通知远程对等方其窗口，以及它能够接收的字节数。一旦发生拥塞，对等方就可以减少窗口，以便发送方放慢速度，直到拥塞结束。
回答OP的问题：在TCP连接的情况下服务器拥塞的情况下，协议确保重新传输和吞吐量动态管理，从而在合理的时间内保留任何发送的数据。
我希望这个简单的描述有所帮助。它可能提出了更多的问题，在这种情况下，我建议在真正的来源加深你的研究：
- RFC 768 (UDP(
- RFC 793 (TCP(