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項目也是推薦的方式。