.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自带有如下特性:
- Kestrel服务器 是默认的,跨平台的HTTP服务器实现。
- 对于IIS来说,IIS HTTP服务器是 进程内服务器。
- HTTP.sys server 是仅用在Windows平台下的HTTP服务器,其基于HTTP.sys kernel driver and HTTP Server API。
当使用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的时,服务器便会加载:
- Visual Studio – 启动配置文件可用于以IIS Express/ASP.NET Core 模块 或者 控制台 来开启app以及服务。
- Visual Studio Code – app 以及服务被Omnisharp启动,它会激活CoreCLR 调试器。
- Visual Studio for Mac – app 以及服务被Mono Soft-Mode Debugger 启动。
当在工程文件夹中从命令提示符加载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及 后续版本。更多信息,请参考与服务器部署方案相关的主题。
额外资源