.NET Core 服务器

此为系列文章，对MSDN ASP.NET Core 的官方文档进行系统学习与翻译。其中或许会添加本人对 ASP.NET Core 的浅显理解。

       一个ASP.NET Core程序以一个进程内的HTTP 服务器实现来运行。这个服务器实现监听HTTP请求，并将它们以包含进HttpContext 对象的一组请求特性的形式呈现给应用程序。

Kestrel

       Kestrel 是由ASP.NET Core项目模板指定的默认的Web服务器。

       使用Kestrel：

  • 作为边缘服务器来处理直接来源于网络的请求，包括Internet。
  • 使用反向代理服务器，比如Internet Information Services (IIS)，Nginx， Apache。反向代理服务器接受来自于Internet的HTTP请求并将其进一步转交给Kestrel。

        

        任何一个宿主配置——不管其是否具有反向代理服务器——都是支持的。

        关于Kestrel配置指南以及在一个反向代理配置中何时使用Kestrel的更多信息，请参考Kestrel web server implementation in ASP.NET Core。

        ASP.NET Core自带有如下特性：

       当使用IIS 或者 IIS Express时，app会以以下两种方式之一运行：

  • 以IIS HTTP服务的形式，运行在与IIS工作者进程相同的进程中。进程内运行是推荐的配置。
  • 以Kestrel服务 的形式运行在与IIS 工作者进程分离的进程中。

       ASP.NET Core Module 是一个本地的IIS模块，其用来处理IIS 与 进程内IIS服务，以及IIS 与 Kestrel 之间的本地IIS请求。     

寄宿模块

       使用进程内寄宿，ASP.NET Core app 运行在与IIS工作者进程相同的进程中。进程内寄宿比进程外寄宿提供了更优化的性能，这是因为请求不通过环回适配器进行代理，环回适配器是一个网络接口，它将传出的网络流量返回到同一台计算。IIS使用Windows Process Activation Service (WAS)来处理进程管理。

       使用进程外寄宿，ASP.NET Core app 运行在一个与IIS工作者进程不同的进程中，模块来处理进程管理。当第一次请求到达时，模块会为ASP.NET Core app开启一个进程，并在其关闭或者崩溃时重启app。如你所见，这本质上是与运行在进程内的app是相同的行为，只不过它们是通过Windows Process Activation Service (WAS) 来管理的。

       更多信息以及配置指南，请参考如下主题：   

 HTTP.sys

      如果ASP.NET Core app运行在Windows上，那么HTTP.sys是Kestrel的一个代替选项。通常我们推荐Kestrel以获取最佳的性能。在这样的场景下，我们可以使用HTTP.sys：app暴漏给了Internet，并且HTTP.sys具有所需要的功能而Kestrel却并没有此功能。更多信息，请参考HTTP.sys web server implementation in ASP.NET Core。

                                    

       HTTP.sys也可以用于仅仅暴漏给内部网络的app。

                                

        关于HTTP.sys的配置指南，请参考HTTP.sys web server implementation in ASP.NET Core。

 ASP.NET Core 服务器基础设施

        在Startup.Configure中可用的 IApplicationBuilder暴漏了类型IFeatureCollection 的 ServerFeatures 属性。Kestrel 和HTTP.sys各自仅仅暴漏了一个单独的特性：IServerAddressesFeature，但是不同的服务器实现或许会暴漏额外的功能。

        IServerAddressesFeature 可以用来找出在运行时，服务器实现绑定了哪个端口。

自定义服务器

        如果内置的服务器不能满足app的需求，那么可以创建一个自定义的服务器。Open Web Interface for .NET (OWIN) guide 演示了如何写一个 基于Nowin 的 IServer 实现。虽然IHttpRequestFeature 和 IHttpResponseFeature 必须被支持，然而只有app使用的特性接口需要实现。

服务器启动

       当整合开发环境或者编辑器启动app的时，服务器便会加载：

       当在工程文件夹中从命令提示符加载app时，dotnet run 命令会加载app 以及服务（仅限于Kestrel 和 HTTP.sys）。配置选项-c|-- 会指定配置，它会被设置为 Debug（默认） 或者 Release。

       当以dotnet run命令或者是工具内置的调试器（比如 Visual Studio）加载app时，这个文件launchSettings.json 提供了所需的配置。如果启动配置文件出现在launchSettings.json 文件中，请和 dotnet run 命令一起使用--launch-profile {PROFILE NAME} 选项，或者在Visual Studio中选择配置文件。更多信息，请参考dotnet run 和.NET Core distribution packaging。

HTTP/2 支持

      ASP.NET Core在以下场景支持HTTP/2：

  • Kestrel
    • 操作系统
      • Windows Server 2016/Windows 10 及以后
      • OpenSSL 1.0.2 及后续版本的Linux（比如Ubuntu 16.04及以后版本）
      • macOS在将来的版本会支持HTTP/2
    • 目标框架：.NET Core 2.0 及以后。
  • HTTP.sys
    • Windows Server 2016/Windows 10 及以后
    • 目标框架：不适用HTTP.sys 部署
  • IIS (in-process)
    • Windows Server 2016/Windows 10 及以后；IIS 10 及以后
    • 目标框架：.NET Core 2.2及以后
  • IIS (out-of-process)
    • Windows Server 2016/Windows 10 及以后；IIS 10 及以后
    • 使用HTTP/2的面向公共的边缘服务器连接，但对于Kestrel的反向代理连接使用HTTP/1.1
    • 目标框架：不适用于IIS进程外部署
       

        在Windows Server 2012 R2 及 Windows 8.1 上，Kestrel对于HTTP/2的支持有限。支持是有限的，那是因为在这些操作系统中，支持的可用TLS密码套件是有限的。可能需要使用椭圆曲线数字签名算法（ECDSA）生成的证书来保护TLS连接。

       一个HTTP/2连接必须使用Application-Layer Protocol Negotiation (ALPN) 和 TLS 1.2及 后续版本。更多信息，请参考与服务器部署方案相关的主题。

额外资源

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/qianxingmu/p/12463483.html