.NET 6 中有哪些具体网络性能优化措施？
- 内容介绍
- 文章标签
- 相关推荐
本文共计3091个文字，预计阅读时间需要13分钟。
原文+ | Mário Pichová 翻译+ | 邱子铭 对 .NET 的每个新版本，我们都希望发布一篇博客文章，重点介绍网络的某些变化和改进。在这篇文章中，我非常高兴讨论 .NET 6 中的变化。这篇文章的+代表：
原文 | Máňa Píchová
翻译 | 郑子铭
对于 .NET 的每个新版本，我们都希望发布一篇博客文章，重点介绍网络的一些变化和改进。在这篇文章中，我很高兴谈论 .NET 6 中的变化。
这篇文章的上一个版本是 .NET 5 网络改进。
HTTP HTTP/2 窗口缩放随着 HTTP/2 和 gRPC 的兴起，我们的客户发现 SocketsHttpHandler 的 HTTP/2 下载速度在连接到具有显着网络延迟的地理位置较远的服务器时无法与其他实现相提并论。在具有高带宽延迟产品的链路上，与其他能够利用链路物理带宽的实现相比，一些用户报告了 5 到 10 倍的差异。举个例子：在我们的一个基准测试中，curl 能够达到特定跨大西洋链路的最大 10 Mbit/s 速率，而 SocketsHttpHandler 的速度最高为 2.5 Mbit/s。除其他外，这严重影响了 gRPC 流式处理方案。
问题的根本原因是固定大小的 HTTP/2 接收窗口，当以高延迟接收 WINDOW_UPDATE 帧时，它的 64KB 大小太小而无法保持网络繁忙，这意味着 HTTP/2 自己的流量控制机制正在停止网络链接。
我们考虑了“廉价”选项来解决这个问题，例如定义一个固定大小的大窗口——这可能会导致不必要的高内存占用——或者要求用户根据经验观察手动配置接收窗口。这些似乎都不令人满意，因此我们决定实现一种类似于 TCP 或 QUIC 中的自动窗口大小调整算法 (dotnet/runtime#54755)。
结果证明效果很好，将下载速度提升到接近其理论最大值。但是，由于 HTTP/2 PING 帧用于确定 HTTP/2 连接的往返时间，因此我们必须非常小心，以免触发服务器的 PING 泛洪保护机制。
本文共计3091个文字，预计阅读时间需要13分钟。
原文+ | Mário Pichová 翻译+ | 邱子铭 对 .NET 的每个新版本，我们都希望发布一篇博客文章，重点介绍网络的某些变化和改进。在这篇文章中，我非常高兴讨论 .NET 6 中的变化。这篇文章的+代表：
原文 | Máňa Píchová
翻译 | 郑子铭
对于 .NET 的每个新版本，我们都希望发布一篇博客文章，重点介绍网络的一些变化和改进。在这篇文章中，我很高兴谈论 .NET 6 中的变化。
这篇文章的上一个版本是 .NET 5 网络改进。
HTTP HTTP/2 窗口缩放随着 HTTP/2 和 gRPC 的兴起，我们的客户发现 SocketsHttpHandler 的 HTTP/2 下载速度在连接到具有显着网络延迟的地理位置较远的服务器时无法与其他实现相提并论。在具有高带宽延迟产品的链路上，与其他能够利用链路物理带宽的实现相比，一些用户报告了 5 到 10 倍的差异。举个例子：在我们的一个基准测试中，curl 能够达到特定跨大西洋链路的最大 10 Mbit/s 速率，而 SocketsHttpHandler 的速度最高为 2.5 Mbit/s。除其他外，这严重影响了 gRPC 流式处理方案。
问题的根本原因是固定大小的 HTTP/2 接收窗口，当以高延迟接收 WINDOW_UPDATE 帧时，它的 64KB 大小太小而无法保持网络繁忙，这意味着 HTTP/2 自己的流量控制机制正在停止网络链接。
我们考虑了“廉价”选项来解决这个问题，例如定义一个固定大小的大窗口——这可能会导致不必要的高内存占用——或者要求用户根据经验观察手动配置接收窗口。这些似乎都不令人满意，因此我们决定实现一种类似于 TCP 或 QUIC 中的自动窗口大小调整算法 (dotnet/runtime#54755)。
结果证明效果很好，将下载速度提升到接近其理论最大值。但是，由于 HTTP/2 PING 帧用于确定 HTTP/2 连接的往返时间，因此我们必须非常小心，以免触发服务器的 PING 泛洪保护机制。