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

作成者: Tom Dykstra、Steve Smith、Stephen Halter、Chris Ross

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

Windows

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

• Kestrel サーバーは、クロスプラットフォーム HTTP サーバーの既定の実装です。 Kestrel を使用すると、最高のパフォーマンスとメモリ使用率が提供されますが、HTTP.sys の高度な機能の一部は提供されません。 詳細については、Windows タブの「Kestrel とHTTP.sys」を参照してください。
• IIS HTTP サーバーは、IIS 用のインプロセス サーバーです。
• HTTP.sys サーバーは、HTTP.sys カーネル ドライバーおよび HTTP サーバー API に基づく Windows 専用の HTTP サーバーです。

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

• IIS HTTP サーバーを使用して IIS ワーカー プロセスと同じプロセス内 (インプロセス ホスティング モデル)。 "インプロセス" が推奨される構成です。
• Kestrel サーバーを使用して IIS ワーカー プロセスとは異なるプロセス内 (プロセス外ホスティング モデル)。

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 にはない次の機能を備えた共有カーネル モード コンポーネントとして動作します。

• ポート共有
• カーネル モードの Windows 認証。 Kestrel でサポートされているのは、ユーザー モード認証のみです。
• キュー転送による高速プロキシ
• 直接ファイル伝送
• 応答キャッシュ

ホスティング モデル

次のようなホスティング モデルを使用できます。

• Kestrel セルフホスティング: Kestrel Web サーバーは、IIS や HTTP.sys などの他の外部 Web サーバーを必要とせずに実行されます。

• HTTP.sys セルフホスティングは Kestrel の代替手段です。 Kestrel で使用できない機能がアプリに必要な場合を除き、HTTP.sys よりも Kestrel をお勧めします。

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

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

詳細については、「

• Kestrel とHTTP.sys
• IIS を使用した Windows での ASP.NET Core のホスト
• IIS の ASP.NET Core モジュール (ANCM)

macOS

ASP.NET Core には、既定のクロスプラットフォーム HTTP サーバーである Kestrel サーバーが付属しています。

Linux

ASP.NET Core には、既定のクロスプラットフォーム HTTP サーバーである Kestrel サーバーが付属しています。

Kestrel

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

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

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

  

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

  

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

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

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 の構成のガイダンスについては、「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) のガイドを参照してください。 実装を必要とするのは、アプリで使用される機能のインターフェイスのみです。ただし、少なくとも IHttpRequestFeature と IHttpResponseFeature はサポートされている必要があります。

サーバーの起動

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

• Visual Studio: 起動プロファイルを使用して、IIS Express/ASP.NET Core モジュールまたはコンソールで、アプリとサーバーを開始できます。
• Visual Studio Code: CoreCLR デバッガーをアクティブにする Omnisharp によって、アプリとサーバーが開始されます。
• Visual Studio for Mac: アプリとサーバーは、Mono Soft-Mode Debugger によって開始されます。

コマンド プロンプトからプロジェクトのフォルダーでアプリを起動すると、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 以降など)
    • macOS 10.15 以降
  • ターゲット フレームワーク: .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/2 接続では、アプリケーション レイヤー プロトコルのネゴシエーション (ALPN) および TLS 1.2 以降を使用する必要があります。 詳細については、ご利用のサーバーの展開シナリオに関連するトピックを参照してください。

その他のリソース

• ASP.NET Core の Kestrel Web サーバー
• IIS の ASP.NET Core モジュール (ANCM)
• IIS を使用した Windows での ASP.NET Core のホスト
• Azure App Service に ASP.NET Core アプリを展開する
• Nginx 搭載の Linux で ASP.NET Core をホストする
• Apache 搭載の Linux で ASP.NET Core をホストする
• ASP.NET Core での HTTP.sys Web サーバーの実装