Kestrel与IIS性能差异解析：C# Async/Await场景下的困惑

这个问题问到点子上了——很多刚上手ASP.NET Core的开发者都会有这个疑惑：既然Async/Await已经能让代码非阻塞，为啥Kestrel还能在吞吐量和性能上压IIS一头？咱们用大白话拆解清楚：

1. 两者的底层“底子”完全不一样 #

IIS是Windows生态里的老牌服务器，它的架构是为传统.NET Framework时代的场景设计的，身上带着不少历史包袱：

• 它要兼容一堆老特性：比如ISAPI扩展、集成管道、Windows身份验证的各种复杂逻辑，这些模块就算你不用，也会在请求处理管线里占着资源，带来额外的开销。
• IIS的请求调度依赖Windows的线程池，就算你用了Async/Await释放线程，线程池的线程调度、上下文切换还是有成本——比如线程从等待队列唤醒、切换执行上下文，这些都是隐形的性能损耗。

而Kestrel是从头为ASP.NET Core打造的轻量级服务器，底层用的是libuv的单线程事件循环模型：

• 它没有多余的历史包袱，所有设计都围绕“高效处理Web请求”来做，管线极简，没有不必要的中间层。
• 事件循环就像一个超级专注的前台：它单线程盯着所有IO事件（比如客户端的连接、请求数据到达、响应发送完成），不用频繁切换线程，也不用线程池的调度开销，能以极低的资源消耗处理大量并发请求。

2. Async/Await是“应用层”的非阻塞，服务器是“底层”的调度器 #

你写的Async/Await代码是让你的业务逻辑不阻塞线程，但服务器本身的请求处理流程是另一回事：

• 在IIS里，就算你的代码异步释放了线程，IIS本身处理请求的入口、管线流转还是要经过它的传统机制，这些步骤的开销是绕不开的。
• 在Kestrel里，从客户端连接建立到请求到达你的代码，整个流程都是基于事件循环的非阻塞处理，和你的Async/Await代码完美契合，相当于从底层到应用层都是“高效非阻塞”的组合，没有中间的性能浪费。

举个接地气的例子：

• IIS就像一家有很多服务员（线程）的餐厅，服务员可以在客人没下单的时候去收拾桌子（Async/Await释放线程做其他事），但服务员之间换班、领班分配任务（线程池调度）还是要花时间。
• Kestrel就像一个全能的前台经理（事件循环），同时盯着所有桌子的需求，客人一抬手就立刻响应，不用喊服务员，也不用来回跑，效率自然更高。

3. 实际场景中的差异会被并发放大 #

当并发量上来的时候，这种底层设计的差异会变得非常明显：

• IIS的线程池如果遇到大量并发请求，线程切换的开销会急剧增加，甚至可能出现线程池耗尽的情况（就算用了Async/Await，也架不住底层调度的瓶颈）。
• Kestrel的事件循环可以轻松应对上万级的并发连接，因为它不需要为每个连接分配线程，只用一个或少数几个线程就能处理所有IO事件，资源占用极低。

当然，现在最佳实践是用IIS作为反向代理，后面挂Kestrel——这样既利用了IIS的安全、管理特性，又能享受Kestrel的高性能。但如果单独用IIS托管ASP.NET Core应用，确实会比直接用Kestrel慢不少。

内容的提问来源于stack exchange，提问作者saurabh vats