Asp.Net Core中的Web服务器

一、前言

　上一篇文章中记录了对IIS部署应用时相关配置项的设置；那么Asp.Net Core有那些Web服务器呢？各种Web服务器有什么区别呢？实际应用中应该选择哪个呢？

二、常用的Web服务器类型

　1、Asp.Net Core当前常用的Web服务器为以下类型：

类型	Windows	macOS	Linux
Kestrel	√	√	√
HTTP.sys	√	×	×
IIS	√	×	×

　2、接下来分别说明：

• Kestrel：

　　　Kestrel 服务器是默认跨平台 HTTP 服务器实现。 Kestrel 提供了最佳性能和内存利用率，但它没有 HTTP.sys 中的某些高级功能。.NET Core 支持的所有平台和版本均支持 Kestrel

　　　Kestrel 支持以下方案：

• • HTTPS
  • HTTP/2
  • 用于启用 WebSocket 的升级
  • 用于获得 Nginx 高性能的 Unix 套接字

　　　可以单独使用 Kestrel，也可以将其与反向代理服务器（如IIS、Nginx 或 Apache）结合使用。 反向代理服务器接收来自网络的 HTTP 请求，并将这些请求转发到 Kestrel。

Kestrel 用作边缘（面向 Internet）Web 服务器：

Kestrel 用于反向代理配置：

　　　无论配置是否使用反向代理服务器，都是受支持的托管配置。

　　　如果在没有反向代理服务器的情况下将 Kestrel 用作边缘服务器，则不支持在多个进程间共享相同的 IP 和端口。 如果将 Kestrel 配置为侦听某个端口，Kestrel 会处理该端口的所有流量（无视请求的 Host 标头）。

　　　可以共享端口的反向代理能在唯一的 IP 和端口上将请求转发至 Kestrel。

　　　即使不需要反向代理服务器，使用反向代理服务器可能也是个不错的选择。

反向代理：

• • 可以限制所承载的应用中的公开的公共外围应用。
  • 提供额外的配置和防护层。
  • 可以更好地与现有基础结构集成。
  • 简化了负载均和和安全通信 (HTTPS) 配置。 仅反向代理服务器需要 X.509 证书，并且该服务器可使用普通 HTTP 在内部网络上与应用服务器通信。

• HTTP.sys

　　　HTTP.sys 是仅在 Windows 上运行的适用于 ASP.NET Core 的 Web 服务器。 HTTP.sys 是 Kestrel 服务器的替代选择，提供了一些 Kestrel 不提供的功能。 与 HTTP.sys 相比，建议使用 Kestrel，除非应用需要 Kestrel 未提供的功能。　
　　　HTTP.sys 与 ASP.NET Core 模块不兼容，无法与 IIS 或 IIS Express 结合使用。　

　　　HTTP.sys 支持以下功能：

• • Windows 身份验证
  • 端口共享
  • 具有 SNI 的 HTTPS
  • 基于 TLS 的 HTTP/2（Windows 10 或更高版本）
  • 直接文件传输
  • 响应缓存
  • WebSocket（Windows 8 或更高版本）

　受支持的 Windows 版本：

• • Windows 7 或更高版本
  • Windows Server 2008 R2 或更高版本

　　　HTTP.sys 应用场景：

• • 需要将服务器直接公开到 Internet 而不使用 IIS 的部署。

    

  • 内部部署需要 Kestrel 中没有的功能。 

    

　HTTP.sys 是一项成熟的技术，可以抵御多种攻击，并提供可靠、安全、可伸缩的全功能 Web 服务器。 IIS 本身作为 HTTP.sys 之上的 HTTP 侦听器运行。

　Kestrel与HTTP.sys比较：　

Kestrel	HTTP.sys
更好的性能和内存利用率。 跨平台 灵活性，它是独立于操作系统进行开发和修补的。 编程端口和 TLS 配置 扩展性，允许 PPv2 等协议和备用传输。	Http.Sys 作为共享内核模式组件运行，具有 kestrel 不具备的以下功能： 端口共享 内核模式 Windows 身份验证。 Kestrel 仅支持用户模式的身份验证。 通过队列传输的快速代理 直接文件传输 响应缓存

• IIS(托管)　

　　1、Asp.Net Core 模块：是插入 IIS 管道的本机 IIS 模块，能让 ASP.NET Core 应用程序通过 IIS 运行。 使用以下任一方式通过 IIS 运行 ASP.NET Core 应用：

• • 在 IIS 工作进程 (w3wp.exe) 内托管 ASP.NET Core 应用，称为进程内托管模型。
  • 将 Web 请求转发到运行 Kestrel 服务器的后端 ASP.NET Core 应用，称为进程外托管模型。

　　2、进程内托管模型：

　　　　进程内托管在与其 IIS 工作进程相同的进程中运行 ASP.NET Core 应用。 进程内承载相较进程外承载提供更优的性能，因为请求并不通过环回适配器进行代理，环回适配器是一个网络接口，用于将传出的网络流量返回给同一计算机。

　　　　下图为 IIS、ASP.NET Core 模块和进程内托管的应用之间的关系：

　　　请求的常规流程如下：

1. 请求从 Web 到达内核模式 HTTP.sys 驱动程序。
2. 驱动程序将本机请求路由到网站的配置端口上的 IIS，通常为 80 (HTTP) 或 443 (HTTPS)。
3. ASP.NET Core 模块接收本机请求，并将其传递给 IIS HTTP 服务器 (IISHttpServer)。 IIS HTTP 服务器是将请求从本机转换为托管的 IIS 进程内服务器实现。

　　　在 IIS HTTP 服务器处理请求后：

1. 请求被发送到 ASP.NET Core 中间件管道。
2. 中间件管道处理该请求并将其作为 HttpContext 实例传递给应用的逻辑。
3. 应用的响应通过 IIS HTTP 服务器传递回 IIS。
4. IIS 将响应发送到发起请求的客户端。

　　　设置方式：

<PropertyGroup>
  <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup

　　3、进程外托管模型：

　　　由于运行 ASP.NET Core 的进程与 IIS 工作进程分开，因此 ASP.NET Core 模块会负责进程管理。 该模块在第一个请求到达时启动 ASP.NET Core 应用的进程，并在应用关闭或崩溃时重新启动该应用。 这基本上与在 Windows 进程激活服务 (WAS) 托管的进程内运行的应用中出现的行为相同。

　　　下图为IIS、ASP.NET Core 模块和进程外托管的应用之间的关系：

　　　请求流程：

1. 请求从 Web 到达内核模式 HTTP.sys 驱动程序。
2. 驱动程序将请求路由到网站的配置端口上的 IIS。 配置的端口通常是 80 (HTTP) 或 443 (HTTPS)。
3. 此模块将该请求转发到应用的随机端口上的 Kestrel。 随机端口不是 80 或 443。

　　　设置方式：　　

<PropertyGroup>
  <AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>

 三、总结

　1、Asp.Net Core的服务器建议使用Kestrel；集群部署时可使用反向代理服务器(IIS、Nginx等)实现。

　2、在Windows下如果需要使用HTTP.sys的高级功能(windows身份认证、端口共享)时，则采用HTTP.sys方式

　3、Windows中IIS部署Asp.Net Core项目也是推荐的方式。