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


ASP.NET Core and Kestrel design decision: Why do they use libuv?

我刚刚意识到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程序包仅处于预览状态。 (套接字程序集当然不依赖于libuv。)

计划是切换到Sockets，但它可能无法在Net Core 2.1上及时发布，但可能对公众可用。

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

请参阅https://github.com/aspnet/KestrelHttpServer/issues/2220

相关讨论