HTTP 丢包

Posted 2023-03-14

【中文标题】HTTP 丢包

【英文标题】：Packet Loss over HTTP

【发布时间】：2015-10-30 12:08:05

【问题描述】：

在一家视频会议公司实习时，有很多关于丢包的话题。***声明如下：

丢包通常是由网络拥塞引起的。

我了解，由于视频需要通过网络发送如此大量的数据，因此数据包肯定会丢失。

我不明白为什么在 HTTP 请求和 AJAX 调用等其他情况下不会出现丢包。如果丢包真的是网络拥塞造成的，为什么我自己的 HTTP 请求从来没有遇到过呢？

HTTP 连接是否不会丢失数据包，或者我发送的请求太小而不会受到影响。如果 HTTP 对丢包免疫，为什么会这样？

【问题讨论】：

HTTP 和许多其他协议底层的 TCP/IP 层检测到数据包丢失，并将重新传输丢失的数据包，直到它们被确认。在应用程序级别，这并不表现为丢失数据，而是表现为延迟/抖动增加。因此，除非您仔细注意时间安排，否则您不会注意到它。

@JimLewis 有趣。现在有什么原因没有在视频等更密集的通信中实施吗？我认为重新发送数据包的成本太高，或者因为每秒帧数太快而丢弃的数据包几乎不会引起注意。

@BrianTracy：音频/视频通常使用 UDP 而不是 TCP 传输。就其本质而言，UDP 是有损的。音频/视频可能会丢失数据包而不会严重降低整体体验，一些丢失量通常是可以接受的。 TCP 协议并非如此，例如 HTTP，任何数据丢失都是致命的。

【参考方案1】：

任何基于 IP 的协议都可能发生拥塞丢包。如果两台机器之间出现拥塞，路由器可以丢弃 IP 数据报，因为 IP 是一种尽力而为的协议。

区别在于视频通常通过UDP协议传输，而HTTP通过TCP协议传输。 IP是第3层协议。 TCP 和 UDP 是第 4 层协议的两种类型。

UDP 既不面向连接也不可靠。这意味着如果数据报在中间被丢弃，没有端点节点意识到这一点（除非有实现可靠性的高层协议）。数据报丢失。

TCP 是一种面向连接的可靠协议。用一种简单的方式解释，接收 TCP 段的节点将对接收到的数据发送确认。如果中间丢失了一个 TCP 段，接收节点将不会发送 ACK（确认），并且发送节点会在一定时间后超时。超时后，发送节点将重新传输丢失的数据。这就是为什么接收节点要么接收整个 HTTP 消息，要么在极端情况下，应用程序中会出现错误，告诉您“连接断开”之类的信息（这意味着如果两端都存在问题会意识到的）。