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

Question

I just realized that ASP.NET Core apps are not pure CLR apps - they always depend on additional binary libraries: libuv through Kestrel or, probably way less used, http.sys.

I find this surprising as I would have thought there to be already enough networking api under .NET Core (and so .NET Standard) to make a decent performing web server with asynchronous IO purely in .NET - yet they didn't go that route.

So:

• Why is using libuv making stuff faster? "Because async IO" alone can't be all there's to it, as .NET already has that.
• Why does Kestrel not have the option to run on top of .NET's IO stack? In most cases the speed difference can't be that important, right?
• What kind of IO exactly does go through the better performing libuv? I reckon that's only the inbound requests. Outgoing requests through WebClient, HttpRequest or HttpClient wouldn't use libuv, correct?

EDIT:

I had a look at the Kestrel sources and besides an assembly called Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv there also is an assembly called Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets. The corresponsing NuGet package for the sockets assembly is in preview only though. (The sockets assembly doesn't depend on libuv of course.)

Answer 1

The plan is to switch to Sockets but it may not make it in time for Net Core 2.1 but could be available for the public.

It seems that as of December 2017 they had to switch back from Sockets to Libuv due to performance issues:

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