Skip to content

MS_ASPNETCoreWebServer

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

ASP.NET CoreのWebサーバ

概要

ASP.NET Coreの Web サーバ・インフラストラクチャについて説明する。

補足（ASP.NET との構造の違い）: ここが
ASP.NET Coreへの移行 で最も理解が要る箇所である。

【ASP.NET (System.Web)】
   IIS が Web サーバであり、同時にアプリのホストでもある
     IIS ─(w3wp.exe の中で ASP.NET パイプラインを実行)─ アプリ
     → IIS 無しには動かない。Windows 専用

【ASP.NET Core】
   アプリ自身が HTTP サーバを内蔵する（自己ホスト）
     Kestrel（アプリ内）で待ち受ける
     → 単独で動く。IIS / nginx は「前段のリバース プロキシ」
     → クロスプラットフォーム

この転換により、

  • dotnet run だけで Web アプリが動く（開発が軽い）
  • Linux / コンテナで動く
  • IIS は必須ではなくなった（使ってもよい）

という現在の姿になっている。

インプロセス HTTP サーバ

ASP.NET Coreアプリは、
下記のインプロセス HTTP サーバ実装を使用して実行される。

Kestrel

概要

  • クロスプラットフォームの HTTP サーバ。
  • 非同期 I/O ライブラリである libuvに基づく。
  • ASP.NET Coreプロジェクト テンプレートは既定では Kestrel を使用する。

移行メモ（libuv は使われていない／最新化）: 「libuv に基づく」は
ASP.NET Core 2.0 頃までの記述である。

版 トランスポート
〜 2.0 libuv（Node.js 由来の C ライブラリ）
2.1 マネージド ソケットが既定に（libuv は選択可）
3.0 以降 libuv のサポートを削除。マネージド ソケットのみ

現在の Kestrel は
System.Net.Sockets ベースのマネージド実装であり、
ネイティブ依存が無い。
async/await と Span<T> / Pipelines を活用した
実装に置き換わり、性能面でも libuv 版を上回っている。

機能

  • HTTPS
  • Websocket
  • UNIX ドメインソケット

補足（現在サポートされるもの）:

機能 対応
HTTP/1.1 ○
HTTP/2 ○（TLS 上。ASP.NET Core 2.2+）
HTTP/3（QUIC） ○（.NET 7+。MsQuic が必要）
HTTPS / TLS ○（SNI、証明書の動的選択も可）
WebSocket ○
gRPC ○（HTTP/2 が前提）
UNIX ドメイン ソケット ○
Named Pipe ○（.NET 8+、Windows）
Windows 認証 ×（HTTP.sys / IIS が必要）

用例

  • 内部ネットワークにのみ公開される場合、単独で使用。
  • 外部公開する場合、IIS、nginx、Apache などのリバース プロキシと併用。
    （外部公開する場合、Web サーバのセキュリティ機能が必要になる）

移行メモ（「単独で外部公開してはいけない」は過去の話）: 原文の
「外部公開する場合はリバース プロキシと併用」という記述は、
ASP.NET Core 1.x 時代のガイダンスである。

現在は Kestrel を直接インターネットに公開してもサポートされる
（Microsoft のドキュメントも 2.0 以降その旨に改訂されている）。

ただし、リバース プロキシを置く実務上の理由は今も多い。

理由 内容
1 台で複数アプリを公開 ポート 80/443 を共有し、ホスト名やパスで振り分ける
TLS 終端の集約 証明書の管理を 1 箇所に
静的ファイル配信 nginx / CDN の方が速い
負荷分散・ヘルス チェック
WAF・レート制限
Windows 認証 Kestrel 単独では不可

逆に、コンテナ + クラウドのロード バランサーという構成では、
Kestrel 単独で十分なことが多い
（Ingress / Application Gateway が前段を担うため）。

構成

  • 単独
    Startup.Configure メソッド内で、

    • クライアントの最大接続数、要求本文の最大サイズ、要求本文の最小レートなどを設定
    • app.UseKestrel メソッドや、app.Run メソッドにより設定

  • 併用

補足（現在の構成方法／最新化）: UseKestrel を
Configure で呼ぶ形は古い。現在は Program.cs で設定する。

var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel(options =>
{
    options.Limits.MaxConcurrentConnections = 1000;
    options.Limits.MaxRequestBodySize = 30 * 1024 * 1024;   // 30MB
    options.Limits.MinRequestBodyDataRate =
        new MinDataRate(bytesPerSecond: 100, gracePeriod: TimeSpan.FromSeconds(10));

    options.ListenAnyIP(5001, listen => listen.UseHttps());
});

設定ファイル（appsettings.json）からも構成できる
（.NET Core config）。

{
  "Kestrel": {
    "Endpoints": {
      "Https": {
        "Url": "https://*:5001",
        "Certificate": { "Path": "cert.pfx", "Password": "..." }
      }
    },
    "Limits": { "MaxRequestBodySize": 31457280 }
  }
}

**MaxRequestBodySize（既定 30MB）**は
ファイル アップロードで最初に踏む制限である
（IIS 併用時は **IIS 側の maxAllowedContentLength（既定 30MB）**も
別途引き上げる必要がある点に注意）。

HTTP.sys

概要

  • Windows 専用。

  • 下記に基づく。

機能

  • Windows 認証
  • ポート共有
  • SNI を使用する HTTPS
  • 直接ファイル伝送
  • 応答キャッシュ
  • WebSocket (Windows 8 以降)
  • HTTP/2 over TLS (Windows 10 以降)

用例

  • IIS を使用せず、インターネットに直接サーバを公開するシナリオ

  • Kestrel ではサポートされていないシナリオ

    • インターネットに公開する場合。
    • その他、HTTP.sys の機能を使用したい場合。

構成

  • HTTP.sys とASP.NET Coreのコードと直結させる。

  • 設定は、以下によって行う。

    • Windows Server の構成

      • ファイアウォールのポートを開ける。
      • HTTP.sys の構成（レジストリ設定）
      • HTTP.sys に x.509 証明書を設定する。
      • .NET Framework、.NET Coreなどのランタイムをインストール

    • ASP.NET Coreアプリの構成
      Startup.Configure メソッド内で、

      • ・・・などを、
      • app.UseHttpSys メソッドや、app.Use メソッドにより設定

補足（HTTP.sys を選ぶ理由は 1 つに絞られた）: 原文が挙げる用例のうち、
「インターネットに公開する場合」は前述の通り
Kestrel でも可能になったため、現在の選択理由は実質
「Windows 認証（Kerberos / NTLM）を IIS 無しで使いたい」
にほぼ限定される。

Kestrel HTTP.sys
プラットフォーム クロスプラットフォーム Windows 専用
Windows 認証 × ○
ポート共有 × ○（同一ポートを複数プロセスで）
応答キャッシュ × ○（カーネル モード）
IIS との併用 ○（ANCM 経由） ×（併用不可）
性能 高い 中
構成の容易さ 容易 レジストリ・netsh が要る 
builder.WebHost.UseHttpSys(options =>
{
    options.Authentication.Schemes =
        AuthenticationSchemes.NTLM | AuthenticationSchemes.Negotiate;
    options.Authentication.AllowAnonymous = false;
    options.UrlPrefixes.Add("https://+:443");
});

URL 予約と証明書のバインドが別途必要になる。

netsh http add urlacl url=https://+:443/ user=DOMAIN\User
netsh http add sslcert ipport=0.0.0.0:443 certhash=<thumbprint> appid={GUID}

カスタム サーバ

OWIN（Nowin ベースの IServer 実装）に基づいたカスタム サーバを開発可能。

補足: 独自の IServer 実装は現在もサポートされるが、
実務で作ることはほぼ無い。
原文が挙げる Nowin はメンテナンスされていない。
テスト用途であれば TestServer（Microsoft.AspNetCore.TestHost）が
標準で用意されており、これが IServer の代表的な別実装である。

一般的な HTTP サーバ

  • IIS と Kestrel
    リバース プロキシとして IIS または IIS Express を使用
  • nginx と Kestrel
    リバース プロキシとして nginx を使用
  • Apache と Kestrel
    リバース プロキシとして Apache を使用

移行メモ（誤記）: 原文の「バース プロキシ」は
リバース プロキシの脱字、
「nginx と Kestre」は Kestrel の脱字と判断し修正した。

IIS

補足（インプロセス／アウトプロセスの 2 方式）: 原文が説明しているのは
アウトプロセス ホスティングである。
ASP.NET Core 2.2 以降、インプロセスが追加され、
現在はこちらが既定になっている。

【アウトプロセス（〜2.1 の方式）】
   ブラウザ → IIS(w3wp.exe) → ANCM → Kestrel(dotnet.exe) → アプリ
     → プロセスが 2 つ。ループバック HTTP を 1 往復する

【インプロセス（2.2 以降・既定）】
   ブラウザ → IIS(w3wp.exe) ─ ANCM ─ IISHttpServer → アプリ
     → 1 プロセス内で完結。Kestrel は使われない
     → 性能が大幅に向上（数倍のスループット）

<PropertyGroup>
  <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup>

この違いはデバッグ時のプロセス選択に影響する
（ASP.NET Coreのデプロイ で、
原文が「dotnet.exe ではなく w3wp.exe に戻っている」と
記録しているのは、まさにこの変更のためである）。

nginx

コチラを参照。

補足（リバース プロキシ配下で必須の設定）: nginx / Apache /
ロード バランサーの配下に置く場合、
転送ヘッダーの処理を有効にしないと不具合が出る。

【設定しないと起きること】
  ・HttpContext.Connection.RemoteIpAddress が
    プロキシの IP（127.0.0.1 等）になる → ログ・レート制限が無意味に
  ・Request.Scheme が http のまま → 生成される URL が http:// になる
    → OAuth のリダイレクト URI が一致せず認証が失敗する

// Program.cs：認証などより「前」に置く
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});
location / {
    proxy_pass         http://127.0.0.1:5000;
    proxy_http_version 1.1;
    proxy_set_header   Upgrade $http_upgrade;      # WebSocket
    proxy_set_header   Connection keep-alive;
    proxy_set_header   Host $host;
    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Proto $scheme;
}

KnownProxies / KnownNetworks の既定はループバックのみのため、
別ホストのプロキシを経由する場合は明示的に許可する必要がある
（コンテナ環境で特に踏みやすい）。

Apache

・・・

ASP.NET Coreのデプロイ

on IIS

on Linux

参考

Microsoft Learn

.NET 開発基盤部会 Wiki

Tags: 移行, .NET開発, .NET Core, ASP.NET, ASP.NET MVC

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally