可以改进 QUIC 流以进行文件传输吗？答案

【问题标题】：Can QUIC streams be improved upon for file transfer?可以改进 QUIC 流以进行文件传输吗？
【发布时间】：2019-06-22 10:53:04
【问题描述】：

如果我理解，QUIC 的存在是为了在同一个 UDP 通道上多路复用多个流，包括相同的密钥交换。

有没有人考虑过使用这种不可靠模式或另一种“不太可靠”模式的 QUIC 的“文件”传输模式？文件传输是否会从比 QUIC 流支持的更少的有序传输中受益更多？

有一个 bittorrent 变体 µTP (BEP-29)，它的存在部分是为了减少对住宅互联网的干扰，但支持 bittorrent 通常高度无序的交付。

我认为 QUIC 的文件传输协议也可以通过接受来自多个发送者的数据包大小的块来类似于 bittorren，但这是另一个主题。

【问题讨论】：

µTP 保留顺序传递，它与 TCP 的主要区别在于拥塞控制器。
libswift 可能很有趣。它将bittorrent-link协议烘焙到传输协议中（在某种程度上使其成为以内容为中心的网络）。 cs.kent.edu/~javed/class-P2P13F/papers-2013/…github.com/libswift/libswift

【解决方案1】：

无序、不可靠的文件传输协议的一个优点是它们不需要支付内存成本来保持随着连接的 BDP 增长的重传缓冲区。这些缓冲区的大小不正确可能会导致高 BDP 链路的性能显着下降。

用于两端文件的随机访问持久存储允许在应用程序级别处理重新排序和重新传输。

没有线头阻塞也可能会稍微提高 IO 利用率。

但这些问题都是极端情况。对于在一个大陆内批量传输单个大文件，QUIC 的可靠流模式可能会在吞吐量最佳值附近执行。

【讨论】：

谢谢！我有 1-5 个节点的小组，大约每 5-10 秒为所有 1k 到 5k 个其他节点提供不同的 1-5kb 小文件。所有 1-5k 节点都接收一个不同的文件，但它们可以从一个小组中的 1-5 个节点中的任何一个接收它。我认为数以千计的持续连接很快就会淹没 TCP 的缓冲区，因此 UDP/QUIC 是有意义的。然而，小文件可能比大文件更喜欢 QUIC 流。同时，从技术上讲，我们确实有 1-5 个发件人，所以如果我们相信它能给我们带来什么，我们可能会在 QUIC 上开发一个通用的类似 bittorrent 的协议。
啊，小文件传输并没有从无序、不可靠的传输中获得太多好处。但它可以从其他 QUIC 方面受益，例如并发传输/多路复用或 0RTT 会话恢复作为保活的替代方案。但是对于使用基于事件的套接字 io（epoll、kqueue、io_uring 等）的现代 TCP 堆栈和服务器来说，处理 1 - 5K 个 TCP 连接将不是问题。与 QUIC 相比，它可能无法提供最佳延迟，但应该能够在每个连接每几秒发送几 kB。