Kestrel 是一个跨平台的适用于 ASP.NET Core 的 Web 服务器ASP.NET Core模板项目使用Kestrel作为默认的web服务器

何时结合使用 Kestrel 和反向代理

Kestrel 是一个跨平台的适用于 ASP.NET Core 的 Web 服务器。ASP.NET Core模板项目使用Kestrel作为默认的web服务器。

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

Kestrel 用作边缘(面向 Internet)Web 服务器:

Kestrel 直接与 Internet 通信,不使用反向代理服务器

Kestrel 用于反向代理配置:

Kestrel 通过反向代理服务器(如 IIS、Nginx 或 Apache)间接与 Internet 进行通信

无论配置是否使用反向代理服务器——,都是从 Internet 接收请求的 ASP.NET Core 2.1 或更高版本应用的支持托管配置。

在没有反向代理服务器的情况下用作边缘服务器的 Kestrel 不支持在多个进程间共享相同的 IP 和端口。 如果将 Kestrel 配置为侦听某个端口,Kestrel 会处理该端口的所有流量(无视请求的 Host 标头)。 可以共享端口的反向代理能在唯一的 IP 和端口上将请求转发至 Kestrel。

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

反向代理:

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

 

 

.Net Core的托管模式主要分2种:进程内托管和进程外托管 

默认为OutOfProcess进程外托管模式

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

用于 ASP.NET Core 的最常见进程管理器是:

  • Linux
    • Nginx
    • Apache
  • Windows
    • IIS
    • Windows 服务

 

选择哪种托管模式取决于个人,但是一般推荐使用 “进程内托管” 模式,使用 “进程内托管”可依托 IIS 获得更高的吞吐量,下面来了解一下两种不同的托管模式的区别,选择不同的托管模式可通过修改配置文件 web.config 来完成配置选择:

  • 首先看一个标准的 Asp.Net Core web.config 配置文件
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" 
             path="*" verb="*" 
             modules="AspNetCoreModuleV2" 
             resourceType="Unspecified" />
      </handlers>      
      <aspNetCore processPath="dotnet" 
                  arguments=".\Deploy.IIS.dll" 
                  stdoutLogEnabled="false" 
                  stdoutLogFile=".\logs\stdout" 
                  hostingModel="outofprocess" />
    </system.webServer>
  </location>
</configuration>
<!--ProjectGuid: ea8ea1cd-a655-48c6-ad48-1cca646c2db7-->

 

  • 在节点 system.webServer/aspNetCore.hostingModel 中,可以选择的值为:inprocess(进程内托管)/outofprocess(进程外托管),通过设置 hostingModel 的值来选择不同的托管模式

  • 进程内托管

选择进程内托管,意味着将 .NetCore 应用程序的工作进程托管到 IIS 的工作进程 w3wp.exe 中,使用的 IIS 进程内服务器,即使用的是:IISHttpServer。

  • 进程外托管

选择进程外托管时,web.config 配置节点 system.webServer/aspNetCore.hostingModel 的值必须设置为:outofprocess,选择进程外托管,实际上就是告诉 IIS ,当前应用程序不使用 IISHttpServer,改为使用 Kestrel 服务器

  • 不同托管模式下代码的变化

当你在 Program.cs 中使用默认的代码创建服务器的时候,不管使用的是 inprocess 还是 outofprocess ,代码是无需改变的,就像下面的代码,其中,要关注的代码是:WebHost.CreateDefaultBuilder(args),表示使用默认的构建

  public class Program
    {
        public static void Main(string[] args)
        {
            CreateWebHostBuilder(args).Build().Run();
        }

        public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                   .UseStartup<Startup>();
    }

 

但是,当你使用 outofprocess(进程外托管模型)时,如果是使用自定义构建服务器时,就必须注意,比如,下面的代码 new WebHostBuilder().UseKestrel(),这个时候,就必须显式的指定 UseKestrel ;否则,服务器将无法启动,如果使用了 UseKestrel 又想切换到 inprocess(进程内托管),就必须移除 .UseKestrel(),官网的介绍是在 .UseKestrel() 后面紧跟 .UseIISIntegration(),这样你就可以愉快的切换来切换去了(但是我测试的结果是必须移除);
或者,像下面的代码,使用

.UseKestrel()
.UseIIS()
.UseIISIntegration()

 

  • 强烈建议使用 WebHost.CreateDefaultBuilder(args) 的默认构造,别去踩那么多的坑
    public class Program
    {
        public static void Main(string[] args)
        {
            CreateWebHostBuilder(args).Build().Run();
        }

        public static IWebHostBuilder CreateWebHostBuilder(string[] args)
        {
            return new WebHostBuilder()
                .UseKestrel()
                .UseIIS()
                .UseIISIntegration()
                .UseStartup<Startup>();
        }
    }

 

 

 

 

 

ASP.Net Core使用的是自托管web服务器:Kestrel

ASP.Net 使用的是web服务器:IIS Express

发布.Net Core程序的时候,应用程序池选择了无托管代码并不是以前的托管代码,所以IIS并不会去处理你的程序,他只处理你的请求,所以IIS目前对于.Net Core程序只充当反向代理的角色,转发请求到Kestrel;  

与ASP.NET时代不同,ASP.NET Core不再是由IIS工作进程(w3wp.exe)托管,而是使用自托管Web服务器(Kestrel)运行,IIS则是作为反向代理的角色转发请求到Kestrel不同端口的ASP.NET Core程序中,随后就将接收到的请求推送至中间件管道中去,处理完你的请求和相关业务逻辑之后再将HTTP响应数据重新回写到IIS中,最终转达到不同的客户端(浏览器,APP,客户端等)。

而配置文件和过程都会由些许调整,中间最重要的角色便是AspNetCoreModule,它是其中一个的IIS模块,请求进入到IIS之后便立即由它转发,并迅速重定向到ASP.NET Core项目中,所以这时候我们无需设置应用程序池来托管我们的代码,它只负责转发请求而已。

(部署之前要确保你的IIS上已经安装了AspNetCoreModule托管模块)

分享图片

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


在开发中,有时候生成验证码的场景目前还是存在的,本篇演示不依赖第三方组件,生成随机验证码图片。 先添加验证码接口 public interface ICaptcha { /// &lt;summary&gt; /// 生成随机验证码 /// &lt;/summary&gt; /// &lt;para
后端技术 .net code 官方文档 https://docs.microsoft.com/zh-cn/aspnet/core/mvc/models/file-uploads?view=aspnetcore-3.1 上传方式:multipart/form-data 其他参数:Name,Versio
在上一篇文章中,我们比较出单表插入9999行数据,Freesql &gt;&#160;Dapper &gt; EfCore。在本文中,我们来看看级联插入 构建9999行数据 List&lt;Entity&gt; datas = new List&lt;Entity&gt;(); for (int i
需求:导入9999行数据时Dapper, Ef core, Freesql&#160;谁的性能更优,是如何执行的,级联增加谁性能更佳。 确认方法:sql server&#160;的 sys.dm_exec_query_stats SELECT TOP 1000 (select [text] from
资料整理 1.sp-api介绍:https://developer.amazonservices.com/ 2.github文档:https://github.com/amzn/selling-partner-api-docs 3.github代码:https://github.com/amzn/s
最近时间在整SM2算法,在网上看到不少代码,基本都是使用BouncyCastle库,现在这个版本算比较好的拿来分享给大家。 首先引入包&#160;Portable.BouncyCastle 完整代码见Gitee:https://gitee.com/Karl_Albright/CryptoHelper
在上文中,我介绍了事件驱动型架构的一种简单的实现,并演示了一个完整的事件派发、订阅和处理的流程。这种实现太简单了,百十行代码就展示了一个基本工作原理。然而,要将这样的解决方案运用到实际生产环境,还有很长的路要走。今天,我们就研究一下在事件处理器中,对象生命周期的管理问题。事实上,不仅仅是在事件处理器
上文已经介绍了Identity Service的实现过程。今天我们继续,实现一个简单的Weather API和一个基于Ocelot的API网关。 回顾 《Angular SPA基于Ocelot API网关与IdentityServer4的身份认证与授权(一)》 Weather API Weather
最近我为我自己的应用开发框架Apworks设计了一套案例应用程序,并以Apache 2.0开源,开源地址是:https://github.com/daxnet/apworks-examples,目的是为了让大家更为方便地学习和使用.NET Core、最新的前端开发框架Angular,以及Apwork
HAL(Hypertext Application Language,超文本应用语言)是一种RESTful API的数据格式风格,为RESTful API的设计提供了接口规范,同时也降低了客户端与服务端接口的耦合度。很多当今流行的RESTful API开发框架,包括Spring REST,也都默认支
在前面两篇文章中,我详细介绍了基本事件系统的实现,包括事件派发和订阅、通过事件处理器执行上下文来解决对象生命周期问题,以及一个基于RabbitMQ的事件总线的实现。接下来对于事件驱动型架构的讨论,就需要结合一个实际的架构案例来进行分析。在领域驱动设计的讨论范畴,CQRS架构本身就是事件驱动的,因此,
HAL,全称为Hypertext Application Language,它是一种简单的数据格式,它能以一种简单、统一的形式,在API中引入超链接特性,使得API的可发现性(discoverable)更强,并具有自描述的特点。使用了HAL的API会更容易地被第三方开源库所调用,并且使用起来也很方便
何时使用领域驱动设计?其实当你的应用程序架构设计是面向业务的时候,你已经开始使用领域驱动设计了。领域驱动设计既不是架构风格(Architecture Style),也不是架构模式(Architecture Pattern),它也不是一种软件开发方法论,所以,是否应该使用领域驱动设计,以及什么时候使用
《在ASP.NET Core中使用Apworks快速开发数据服务》一文中,我介绍了如何使用Apworks框架的数据服务来快速构建用于查询和管理数据模型的RESTful API,通过该文的介绍,你会看到,使用Apworks框架开发数据服务是何等简单快捷,提供的功能也非常多,比如对Hypermedia的
在上一讲中,我们已经完成了一个完整的案例,在这个案例中,我们可以通过Angular单页面应用(SPA)进行登录,然后通过后端的Ocelot API网关整合IdentityServer4完成身份认证。在本讲中,我们会讨论在当前这种架构的应用程序中,如何完成用户授权。 回顾 《Angular SPA基于
Keycloak是一个功能强大的开源身份和访问管理系统,提供了一整套解决方案,包括用户认证、单点登录(SSO)、身份联合、用户注册、用户管理、角色映射、多因素认证和访问控制等。它广泛应用于企业和云服务,可以简化和统一不同应用程序和服务的安全管理,支持自托管或云部署,适用于需要安全、灵活且易于扩展的用
3月7日,微软发布了Visual Studio 2017 RTM,与之一起发布的还有.NET Core Runtime 1.1.0以及.NET Core SDK 1.0.0,尽管这些并不是最新版,但也已经从preview版本升级到了正式版。所以,在安装Visual Studio 2017时如果启用了
在上文中,我介绍了如何在Ocelot中使用自定义的中间件来修改下游服务的response body。今天,我们再扩展一下设计,让我们自己设计的中间件变得更为通用,使其能够应用在不同的Route上。比如,我们可以设计一个通用的替换response body的中间件,然后将其应用在多个Route上。 O
不少关注我博客的朋友都知道我在2009年左右开发过一个名为Apworks的企业级应用程序开发框架,旨在为分布式企业系统软件开发提供面向领域驱动(DDD)的框架级别的解决方案,并对多种系统架构风格提供支持。这个框架的开发和维护我坚持了很久,一直到2015年,我都一直在不停地重构这个项目。目前这个项目在
好吧,这个题目我也想了很久,不知道如何用最简单的几个字来概括这篇文章,原本打算取名《Angular单页面应用基于Ocelot API网关与IdentityServer4ʺSP.NET Identity实现身份认证与授权》,然而如你所见,这样的名字实在是太长了。所以,我不得不缩写“单页面应用”几个字