ASP.NET Core での Web サーバーの実装

作成者: Tom DykstraSteve SmithStephen HalterChris Ross

ASP.NET Core アプリは、インプロセス HTTP サーバー実装を使用して実行されます。 サーバーの実装では、HTTP 要求がリッスンされ、HttpContext に構成された要求機能のセットとしてアプリに公開されます。

ASP.NET Core には次のものが付属しています。

IIS または IIS Express を使用すると、アプリは次のどちらかで実行されます。

ASP.NET Core モジュールはネイティブの IIS モジュールであり、IIS とインプロセス IIS HTTP サーバーまたは Kestrel の間のネイティブ IIS 要求が処理されます。 詳細については、「IIS の ASP.NET Core モジュール (ANCM)」を参照してください。

Kestrel と HTTP.sys

Kestrel は、次のような点が HTTP.sys より優れています。

  • よりよいパフォーマンスとメモリ使用率
  • クロス プラットフォーム
  • 機敏性。OS から独立して開発され、パッチが適用されます。
  • プログラムによるポートと TLS の構成
  • PPv2 や代替トランスポートなどのプロトコルを使用できる拡張性。

HTTP.sys は、kestrel にはない次の機能を備えた共有カーネル モード コンポーネントとして動作します。

ホスティング モデル

インプロセス ホスティング モデルを使用する場合、ASP.NET Core アプリはその IIS ワーカー プロセスと同じプロセスで実行されます。 インプロセス ホスティングは、パフォーマンスの点でアウトプロセス ホスティングよりも優れています。要求がループバック アダプター (発信されたネットワーク トラフィックを同じコンピューターに送り返すネットワーク インターフェイス) を介してプロキシされることがないからです。 IIS では Windows プロセス アクティブ化サービス (WAS) を使用してプロセス管理が処理されます。

アウト プロセス ホスティングでは ASP.NET Core アプリは IIS ワーカー プロセスとは独立したプロセスで実行され、プロセス管理はモジュールによって処理されます。 モジュールでは、最初の要求が届いたときに ASP.NET Core アプリのプロセスが開始され、プロセスがシャットダウンまたはクラッシュした場合はアプリが再起動されます。 この動作は、インプロセスで実行されるアプリであり、WAS (Windows プロセス アクティブ化サービス) によって管理されるアプリと基本的に同じです。 別のプロセスを使用することで、同じアプリ プールから複数のアプリをホストすることも可能になります。

詳細および構成のガイダンスについては、次のトピックを参照してください:

Kestrel

Kestrel サーバーは、クロスプラットフォーム HTTP サーバーの既定の実装です。 Kestrel を使用すると、最高のパフォーマンスとメモリ使用率が提供されますが、HTTP.sys の高度な機能の一部は提供されません。 詳細については、このドキュメントの「Kestrel と HTTP.sys」を参照してください。

Kestrel を使用して次のことを行います。

  • これ自体で、インターネットを含むネットワークから直接要求を処理するエッジ サーバーとして。

    リバース プロキシ サーバーなしでインターネットと直接通信する Kestrel

  • インターネット インフォメーション サービス (IIS)NginxApache などのリバース プロキシ サーバーと共に。 リバース プロキシ サーバーでは、インターネットから HTTP 要求を受け取り、Kestrel に転送します。

    IIS、Nginx、または Apache などのリバース プロキシ サーバーを介してインターネットと間接的に通信する Kestrel

リバース プロキシ サーバーの有無に関わらず、いずれのホスティング構成もサポートされています。

Kestrel の構成ガイダンスと、リバース プロキシ構成で Kestrel を使用するときの情報については、「ASP.NET Core への Kestrel Web サーバーの実装」をご覧ください。

ASP.NET Core には次のものが付属しています。

IIS または IIS Express を使用すると、アプリは Kestrel サーバーを使用して IIS ワーカー プロセスとは異なるプロセス内で実行されます ("プロセス外")。

ASP.NET Core アプリは IIS ワーカー プロセスとは独立したプロセスで実行されるため、プロセス管理はモジュールによって処理されます。 モジュールでは、最初の要求が届いたときに ASP.NET Core アプリのプロセスが開始され、プロセスがシャットダウンまたはクラッシュした場合はアプリが再起動されます。 この動作は、インプロセスで実行されるアプリであり、WAS (Windows プロセス アクティブ化サービス) によって管理されるアプリと基本的に同じです。

次の図は、IIS (ASP.NET Core モジュール) とアウトプロセスでホストされるアプリとの間のリレーションシップを示しています。

ASP.NET Core モジュール

要求は、Web からカーネル モードの HTTP.sys ドライバーに到着します。 ドライバーは、Web サイトの構成ポート (通常は 80 (HTTP) または 443 (HTTPS)) で IIS への要求をルーティングします。 モジュールでは、アプリのランダムなポート (ポート 80 または 443 ではありません) で Kestrel に要求が転送されます。

モジュールによってスタートアップ時に環境変数を介してポートが指定されると、IIS 統合ミドルウェアによって http://localhost:{port} をリッスンするようにサーバーが構成されます。 追加のチェックが実行され、モジュールから発生していない要求は拒否されます。 モジュールでは HTTPS 転送がサポートされていないため、要求は HTTPS を介して IIS によって受信された場合でも、HTTP を介して転送されます。

Kestrel によってモジュールから要求が取り込まれた後、その要求は ASP.NET Core ミドルウェア パイプラインにプッシュされます。 ミドルウェア パイプラインは要求を処理し、HttpContext インスタンスとしてアプリのロジックに渡します。 IIS 統合によって追加されたミドルウェアでは、Kestrel への要求の転送を考慮して、スキーム、リモート IP、およびパスベースが更新されます。 アプリの応答が IIS に戻され、IIS はその応答を、要求を開始した HTTP クライアントに返します。

IIS と ASP.NET Core モジュールの構成のガイダンスについては、次のトピックをご覧ください。

Nginx と Kestrel

Kestrel のリバース プロキシ サーバーとして Linux で Nginx を使用する方法については、「Nginx 搭載の Linux で ASP.NET Core をホストする」を参照してください。

Apache と Kestrel

Kestrel のリバース プロキシ サーバーとして Linux で Apache を使用する方法については、「Apache 搭載の Linux で ASP.NET Core をホストする」を参照してください。

HTTP.sys

Windows 上で ASP.NET Core アプリを実行する場合は、HTTP.sys を Kestrel の代わりに使用できます。 Kestrel で使用できない機能がアプリに必要な場合を除き、HTTP.sys よりも Kestrel をお勧めします。 詳細については、「HTTP.sys web server implementation in ASP.NET Core」 (ASP.NET Core への HTTP.sys Web サーバーの実装) を参照してください。

インターネットと直接通信する HTTP.sys

HTTP.sys は、内部ネットワークにのみ公開されるアプリにも使用できます。

内部ネットワークと直接通信する HTTP.sys

HTTP.sys の構成のガイダンスについては、「ASP.NET Core での HTTP.sys Web サーバーの実装」を参照してください。

ASP.NET Core サーバー インフラストラクチャ

Startup.Configure メソッドで使用可能な IApplicationBuilder は、IFeatureCollection 型の ServerFeatures プロパティを公開します。 Kestrel および HTTP.sys では、それぞれ単独の機能 IServerAddressesFeature のみが公開されますが、サーバーの実装が異なると追加機能が公開される場合があります。

IServerAddressesFeature を使用すれば、実行時にサーバー実装がバインドされたポートを見つけることができます。

カスタム サーバー

組み込みサーバーがアプリの要件に合わない場合は、カスタム サーバー実装を作成できます。 Nowin ベースの IServer 実装の作成方法については、Open Web Interface for .NET (OWIN) のガイドを参照してください。 実装を必要とするのは、アプリで使用される機能のインターフェイスのみです。ただし、少なくとも IHttpRequestFeatureIHttpResponseFeature はサポートされている必要があります。

サーバーの起動

統合開発環境 (IDE) またはエディターでアプリが開始されると、サーバーが起動されます。

コマンド プロンプトからプロジェクトのフォルダーでアプリを起動すると、dotnet run によってアプリとサーバーが起動されます (Kestrel および HTTP.sys のみ)。 この構成は、Debug (既定) または Release のどちらかに設定された -c|--configuration オプションによって指定されます。

launchSettings.json ファイルは、dotnet run または Visual Studio などのツールに組み込まれたデバッガーを使用してアプリを起動するときの構成を提供します。 起動プロファイルが launchSettings.json ファイルに存在する場合は、dotnet run コマンドで --launch-profile {PROFILE NAME} オプションを使用するか、Visual Studio でプロファイルを選択します。 詳しくは、「dotnet run」および「.NET Core の配布パッケージ」をご覧ください。

HTTP/2 のサポート

HTTP/2 は、次の展開シナリオでの ASP.NET Core でサポートされます。

  • Kestrel
    • オペレーティング システム
      • Windows Server 2016/Windows 10 以降†
      • OpenSSL 1.0.2 以降を使用した Linux (Ubuntu 16.04 以降など)
      • 将来のリリースでは HTTP/2 が macOS 上でサポートされるようになります。
    • ターゲット フレームワーク: .NET Core 2.2 以降
  • HTTP.sys
    • Windows Server 2016/Windows 10 以降
    • ターゲット フレームワーク:HTTP.sys の展開には適用できません。
  • IIS (インプロセス)
    • Windows Server 2016/Windows 10 以降、IIS 10 以降
    • ターゲット フレームワーク: .NET Core 2.2 以降
  • IIS (アウトプロセス)
    • Windows Server 2016/Windows 10 以降、IIS 10 以降
    • 一般向けのエッジ サーバー接続では HTTP/2 を使用しますが、Kestrel へのリバース プロキシ接続では HTTP/1.1 を使用します。
    • ターゲット フレームワーク:IIS アウトプロセスの展開には適用できません。

†Kestrel では、Windows Server 2012 R2 および Windows 8.1 上での HTTP/2 のサポートは制限されています。 サポートが制限されている理由は、これらのオペレーティング システムで使用できる TLS 暗号のスイートのリストが制限されているためです。 TLS 接続をセキュリティで保護するためには、楕円曲線デジタル署名アルゴリズム (ECDSA) を使用して生成した証明書が必要になる場合があります。

  • Kestrel
    • オペレーティング システム
      • Windows Server 2016/Windows 10 以降†
      • OpenSSL 1.0.2 以降を使用した Linux (Ubuntu 16.04 以降など)
      • 将来のリリースでは HTTP/2 が macOS 上でサポートされるようになります。
    • ターゲット フレームワーク: .NET Core 2.2 以降
  • HTTP.sys
    • Windows Server 2016/Windows 10 以降
    • ターゲット フレームワーク:HTTP.sys の展開には適用できません。
  • IIS (インプロセス)
    • Windows Server 2016/Windows 10 以降、IIS 10 以降
    • ターゲット フレームワーク: .NET Core 2.2 以降
  • IIS (アウトプロセス)
    • Windows Server 2016/Windows 10 以降、IIS 10 以降
    • 一般向けのエッジ サーバー接続では HTTP/2 を使用しますが、Kestrel へのリバース プロキシ接続では HTTP/1.1 を使用します。
    • ターゲット フレームワーク:IIS アウトプロセスの展開には適用できません。

†Kestrel では、Windows Server 2012 R2 および Windows 8.1 上での HTTP/2 のサポートは制限されています。 サポートが制限されている理由は、これらのオペレーティング システムで使用できる TLS 暗号のスイートのリストが制限されているためです。 TLS 接続をセキュリティで保護するためには、楕円曲線デジタル署名アルゴリズム (ECDSA) を使用して生成した証明書が必要になる場合があります。

  • HTTP.sys
    • Windows Server 2016/Windows 10 以降
    • ターゲット フレームワーク:HTTP.sys の展開には適用できません。
  • IIS (アウトプロセス)
    • Windows Server 2016/Windows 10 以降、IIS 10 以降
    • 一般向けのエッジ サーバー接続では HTTP/2 を使用しますが、Kestrel へのリバース プロキシ接続では HTTP/1.1 を使用します。
    • ターゲット フレームワーク:IIS アウトプロセスの展開には適用できません。

HTTP/2 接続では、アプリケーション レイヤー プロトコルのネゴシエーション (ALPN) および TLS 1.2 以降を使用する必要があります。 詳細については、ご利用のサーバーの展開シナリオに関連するトピックを参照してください。

その他の技術情報