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

Question

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

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

所以：

• 为什么使用 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 包仅处于预览状态。（当然，套接字程序集不依赖于 libuv。）

Answer 1

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

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

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