The Kestrel web server is a new web server as part of ASP.NET Core. It is now the preferred web server for all new ASP.NET applications. In this article, we will review what it is, how to use it, and the differences between Kestrel vs IIS.
Why Do We Need the New Kestrel Web Server? What about IIS?
If you have been developing ASP.NET applications for a while, you are probably familiar with Internet Information Services (IIS). It does literally anything and everything as a web server. It is infinitely configurable with ASP.NET handlers & modules via the ASP.NET integrated pipeline. It has robust management APIs for configuration and deployment. It is even an FTP server.
The same codebase that has to support the original “.asp” pages from 15+ years ago now also handles new technologies like async ASP.NET. Like most software, as it ages it gets modified over time, they carry a lot of weight and bloat. IIS does everything, but it is not the fastest web server around. Lightweight web servers like Node.js and Netty make IIS look old and slow.
A Chance to Start Over
By creating the Kestrel web server, the .NET community was able to start over from scratch. They no longer had to worry about backward compatibility for technologies that were 15+ years old. They could take all of their past knowledge to build the simplest and fastest web server possible. That is exactly what they did. Kestrel and ASP.NET Core were built for speed.
Kestrel is more than just a new web server. ASP.NET Core & Kestrel combined are a whole new request pipeline for how ASP.NET requests work. Things like HTTP modules & handlers have been replaced with simple middleware. The entire System.Web namespace is gone. Another big advantage is designing a web server to take advantage of async from the ground up. Performance is now a feature of ASP.NET.
Built for Speed
One of the big problems with IIS and the existing ASP.NET pipeline was the performance of it. For most real world applications, the performance is perfectly fine. However, it lagged way behind in benchmarks. The combination of Kestrel & ASP.NET Core has been shown to be many times faster. It is great to see the team putting performance as a top priority.
Granted, benchmarking an ASP.NET request that says “hello world” is not comparable to most real applications that do multiple SQL queries, cache calls, and web service calls in a single request. ASP.NET makes it easy to do most I/O operations asynchronously. ASP.NET Core & Kestrel have been designed from the ground up to take advantage of async. Most real world apps should perform better if the developers follow good best practices around using async.
Cross Platform
If the goal was to get ASP.NET running on Linux, that meant porting IIS to Linux or making ASP.NET work without IIS. Kestrel solved this problem. As a developer, I can write my ASP.NET application and deploy it to Windows or Linux either one. Kestrel works as my web server on both. However, it is still recommended to use IIS, Apache, or NGINX as a reverse proxy in front of it. Next, we will discuss why that is.
Comparing Kestrel Web Server vs IIS
IIS does almost everything. Kestrel does as little as possible. Because of this, Kestrel is much faster but also lacks a lot of functionality. I would think of Kestrel as really more of an application server. It is recommended to use another web server in front of it for public web applications. Kestrel is designed to run ASP.NET as fast as possible. It relies on a full fledged web server to do deal with things like security, management, etc.
Microsoft suggests always using another web server in front of Kestrel for public websites.
Feature Comparison for Kestrel vs IIS
Here is an IIS vs Kestrel comparison of some key features. This should help you better understand the limitations of Kestrel. You can overcome these limitations by pairing it up with IIS or NGINX.
| IIS | Kestrel | |
| Platform Support | Windows | Windows/Linux/Mac |
| Static Files | Yes | Yes |
| HTTP Access Logs | Yes | No |
| Port Sharing / Multiple apps* | Yes | No |
| SSL Certificates | Yes | Internal** |
| Windows Authentication | Yes | No |
| Management Console | Yes | No |
| Process Activation (start it up) | Yes | No |
| Application Initialization (warm it up) | Yes | No |
| Configuration API | Yes | No |
| Request Filtering & Limits | Yes | No |
| IP & Domain Restrictions | Yes | No |
| HTTP Redirect Rules | Yes | No |
| WebSocket Protocol | Yes | Middleware |
| Response Output Caching | Yes | No |
| Compression | Optional | Optional |
| FTP Server | Yes | No |
* Port Sharing is a big limitation! This means you can’t host “site1.stackify.com” and “site2.stackify.com” both on port 80 on the same server, running different ASP.NET applications.
** Only works with internal SSL traffic between the reverse proxy web server and ASP.NET.