ASP.NET Core 2.1.0-preview2替换libuv为Sockets相关技术疑问

嘿，这几个问题问到点子上了，刚好是ASP.NET Core早期网络栈演进里的核心疑问，我给你逐个掰扯清楚：

为啥最初ASP.NET Core没采用Sockets？ #

早期ASP.NET Core（1.x到2.0版本）敲定用libuv，其实是当时的技术背景决定的。那时候.NET Core刚起步，跨平台的网络API还没打磨到位——虽然.NET Framework里早就有Socket类，但它在非Windows平台上的支持很鸡肋，不管是性能还是稳定性都没法满足Kestrel服务器的需求。

而libuv呢？这货是Node.js用的底层异步IO库，跨平台能力已经经过大量验证，能稳定处理TCP、UDP甚至文件IO，在Windows、Linux、macOS上都能跑起来。对于当时急需一个可靠跨平台网络底座的ASP.NET Core团队来说，libuv是现成的最优解。另外，那时候.NET的Sockets API在异步操作、跨平台一致性上还存在不少短板，优化程度远不如libuv成熟，所以先拿libuv过渡是很合理的选择。

Sockets在各操作系统中的含义是否一致？ #

这个得分两层看：首先，底层操作系统的socket实现是不一样的——Windows用的是Winsock，Linux和macOS用的是BSD风格的socket，它们的底层机制（比如Windows的IOCP、Linux的epoll）差异不小。但.NET给我们封装了System.Net.Sockets.Socket这个抽象层，把这些底层差异都给抹平了。

也就是说，你在代码里调用的Bind()、Listen()、AcceptAsync()这些方法，在不同操作系统上的行为逻辑是完全一致的，不用你去适配不同平台的API。当然，有些平台特有的高级功能（比如Linux的SO_REUSEPORT选项、Windows的IOCP高级配置）还是会有区别，但绝大多数通用的网络场景下，你完全不用关心底层的差异，.NET已经帮你搞定了。

Sockets是否比libuv性能更快？ #

没错，而且在高并发场景下优势还挺明显的。主要原因有两个：

• 少了一层中间开销：用Sockets栈直接调用操作系统原生的socket API，去掉了libuv这个中间封装层，减少了不必要的调度和转换成本。
• 更贴合.NET运行时的优化：微软针对.NET的Sockets栈做了大量定制优化，比如深度整合CLR的异步状态机，充分利用各操作系统的原生异步IO机制（Windows IOCP、Linux epoll），性能比经过libuv中转要好不少。

根据当时微软公布的性能测试数据，在高并发的Web请求场景下，Sockets栈的吞吐量和延迟都比libuv表现更优，尤其是在Linux平台上的提升更为显著。不过也要说句公道话，libuv本身性能并不差，但.NET的Sockets栈更适配CLR的运行环境，所以整体表现更胜一筹。

内容的提问来源于stack exchange，提问作者Code OverFlow