微软已经开放了 HTTP/3 中使用的 QUIC 协议的实现

微软 宣布了 关于打开库代码 奎奇 随着网络协议的实现 QUIC。 该代码是用 C 编写的, 分发者 根据麻省理工学院的许可。 该库是跨平台的,不仅可以在 Windows 上使用,还可以在 Linux 上使用 频道 或用于 TLS 1.3 的 OpenSSL。 未来计划支持其他平台。

该库基于 Windows 10 内核(Insider Preview)中提供的 msquic.sys 驱动程序代码,以启用 HTTP 和 SMB 在 QUIC 之上。 该代码还用于在内部 Windows 堆栈和 .NET Core 中实现 HTTP/3。 MsQuic 库的开发将完全在 GitHub 上进行,使用公共同行评审、拉取请求和 GitHub 问题。 已经准备好基础设施,用于在 4000 多个测试中检查每个提交和拉取请求。 开发环境稳定后,计划接受第三方开发者的变更。

MsQuic 已可用于创建服务器和客户端,但目前并非 IETF 规范中定义的所有功能都可用。 例如,不支持 0-RTT、客户端迁移、路径 MTU 发现或服务器首选地址控制。 在实现的功能中,值得注意的是优化以实现最大吞吐量和最小延迟、支持异步输入/输出、RSS(接收端缩放)以及组合输入和输出 UDP 流的能力。 MsQuic 实现已经过与 Chrome 和 Edge 浏览器实验版本的兼容性测试。

回想一下,HTTP/3 标准化了 QUIC 协议作为 HTTP/2 传输的使用。 协议 QUIC (快速 UDP 互联网连接)由 Google 自 2013 年起开发,作为 Web 的 TCP+TLS 组合的替代方案,解决了 TCP 连接建立和协商时间长的问题,并消除了数据传输过程中数据包丢失时的延迟。 QUIC是UDP协议的扩展,支持多个连接的复用,并提供相当于TLS/SSL的加密方法。

产品特点 快速:

  • 类似于 TLS 的高安全性(本质上 QUIC 提供了通过 UDP 使用 TLS 1.3 的能力);
  • 流量完整性控制,防止丢包;
  • 能够立即建立连接(0-RTT,在大约 75% 的情况下,可以在发送连接建立数据包后立即传输数据)并在发送请求和接收响应之间提供最小的延迟(RTT,往返时间);
    微软已经开放了 HTTP/3 中使用的 QUIC 协议的实现

  • 重传数据包时不使用相同的序列号,这可以避免识别接收到的数据包时出现歧义并消除超时;
  • 数据包丢失仅影响与其关联的流的传送,并且不会停止通过当前连接传输的并行流中数据的传送;
  • 纠错功能可最大限度地减少因重传丢失数据包而导致的延迟。 在数据包级别使用特殊的纠错码可以减少需要重传丢失的数据包数据的情况。
  • 密码块边界与QUIC数据包边界对齐,减少丢包对后续数据包内容解码的影响;
  • 不存在TCP队列阻塞的问题;
  • 支持连接标识符,减少移动客户端重新建立连接的时间;
  • 连接高级连接拥塞控制机制的可能性;
  • 采用单向吞吐量预测技术,确保数据包以最佳速率发送,防止数据包拥塞而导致丢包;
  • 可感知的 发展 与 TCP 相比的性能和吞吐量。 对于 YouTube 等视频服务,QUIC 已被证明可以将观看视频时的重新缓冲操作减少 30%。

来源: opennet.ru

添加评论