使用 UDP 并行化 HTTP 读取答案

【问题标题】：using UDP to parallelize HTTP reads使用 UDP 并行化 HTTP 读取
【发布时间】：2014-08-27 18:50:55
【问题描述】：

显然，即使在多个物理接口 (NIC) 上发出真正现代的请求，我也无法在同一服务器上真正并行读取不同 URL。

我认为问题可能在于 HTTP 协议是面向连接的，然后请求在较低级别被序列化到 TCP/IP 堆栈中（这是正确的措辞吗？）。

尝试使用无连接架构（如 UDP）“重新实现”高级 HTTP 请求并自己处理数据包寻址以加速流传输是否有意义？

【问题讨论】：

标签： http udp

【解决方案1】：

HTTP 请求是独立的。它们可以是任意多个独立连接的问题。 HTTP 没有对并发性施加限制。

你达到了一些资源限制。也许您的客户端库限制了并发调用的数量。也许服务器会。也许网络已被充分利用。可能服务器使用的后端资源已经用完了。

找到瓶颈并消除它。传输协议不是问题。改变它无济于事。

不同的网址

URL 是否不同没有区别，除非服务器实施了一些特殊的限制。极不可能。

在多个物理接口 (NIC) 上。

你可能没有网络绑定。

请求在较低级别被序列化到 TCP/IP 堆栈中

没有。连接管理不是 HTTP 的一部分。客户端决定使用多少个连接。重新配置客户端。

【讨论】：

谢谢。我很确定我是网络绑定的，因为我将两个接口上的带宽限制在 DSL 速度以下，并观察到当我发出 2 个并行读取时速度减半
另外，我正在使用 libCURL，除了允许我在每个请求上指定接口之外，显然不限制客户端的数量。可能是序列化请求的 Ubuntu TCP 堆栈实现吗？
好的，那么你可能是网络绑定的。您始终有多少并发请求未完成，每秒获得多少？平均响应有多大。确保启用了keep-alive。您可能会受到延迟限制。 TCP 堆栈不会序列化独立连接。
你在某处搞错了。一旦解决，就可以期待无限的可扩展性。 TCP 和 HTTP 对您来说都不是问题。

【解决方案2】：

尝试使用无连接架构（如 UDP）“重新实现”高级 HTTP 请求并自己处理数据包寻址以加速流传输是否有意义？

您将不得不自己重新实现 TCP 协议的流量控制、分段分片、重传等功能。然后你的 HTTP 实现将与标准的不兼容。

所以不，这没有多大意义。

对于流媒体，您可能喜欢使用专为流媒体设计的协议，例如WebRTC。

【讨论】：