ASP.NET Core 和 Kestrel 设计决策：他们为什么使用 libuv？

Question

我刚刚意识到 ASP.NET Core 应用程序不是纯粹的 CLR 应用程序 - 它们总是依赖于额外的二进制库：通过 Kestrel 的 libuv 或者可能较少使用的 http.sys。

我觉得这很令人惊讶，因为我原以为 .NET Core（以及 .NET Standard）下已经有足够的网络 api，可以在 .NET 中创建一个性能不错的具有异步 IO 的 Web 服务器 - 但他们没有走那条路。

所以：

• 为什么使用 libuv 会更快？ “因为异步 IO”本身并不能说明一切，因为 .NET 已经具备了这一点。
• 为什么 Kestrel 没有在 .NET 的 IO 堆栈上运行的选项？在大多数情况下，速度差异并没有那么重要，对吧？
• 究竟什么样的 IO 会通过性能更好的 libuv？我认为这只是入站请求。通过WebClient、HttpRequest 或HttpClient 发出的请求不会使用 libuv，对吗？

编辑：

我查看了 Kestrel 的源代码，除了一个名为 Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv 的程序集之外，还有一个名为 Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets 的程序集。套接字程序集的相应 NuGet 包仅处于预览状态。 （当然，sockets 组件不依赖于 libuv。）

Answer 1

计划是切换到 Sockets，但它可能无法及时用于 Net Core 2.1，但可以向公众提供。

似乎从 2017 年 12 月起，由于性能问题，他们不得不从 Sockets 切换回 Libuv：

见https://github.com/aspnet/KestrelHttpServer/issues/2220