Asp.NetコアのリバースプロキシとインプロセスHTTPサーバー

Question

私は約Kestrelウェブサーバーをasp.net core appに、具体的にはin-process http serverとreverse proxyで読んでいました。

• コアアプリケーションにおけるin-process http server実装の関連性：

  季節のウェブ開発者なので、私は背後にある考え方を理解する上で問題がありますか？

• 典型的なものよりもリバースプロキシアプローチの重要性web server？
• 転送型以外のasp.netコアの世界でリバースプロキシが解決するのは、http requestですか？
• asp.netコアアプリケーションがコンテナにデプロイされる場合、どのようにreverse proxyとKestrelが関連付けられますか（1:nまたは1:1）？ official documentationによると

Answer 1

：

ASP.NETコアは、それがプラットフォーム間で一貫して振る舞うことができるように、独自のプロセスで実行するように設計されました。 IIS、Nginx、Apacheは独自の起動プロセスと環境を規定しています。それらを直接使用するには、ASP.NET Coreはそれぞれのニーズに適応する必要があります。 KestrelなどのWebサーバー実装を使用すると、起動プロセスと環境に対するASP.NET Coreの制御が可能になります。したがって、ASP.NETコアをIIS、Nginx、またはApacheに適合させるのではなく、それらのWebサーバーをKestrelへのプロキシ要求に設定するだけです。この配置により、Program.MainクラスとStartupクラスは、どこに配置しても基本的に同じクラスになります。

さらに、インプロセスのhttpサーバーを使用すると、開発者にとって非常に簡単になります。彼らはフレームワークをダウンロードしてインストールするだけで、使用しているOS（Windows、Linux、MacOS）や、後で使用するWebサーバに関係なく、自由に動作します。彼らはそれをホストしているWebアプリケーションでhttpサーバを起動するコマンドdotnet runを起動します。

開発環境でアプリケーションを実行できるようになっても、開発者はセキュリティについて覚えておく必要があります。 Kestrel Webサーバーは非常に新しいWebサーバーなので、長寿の中で得られたIIS、Apache、Nginxなどのセキュリティやその他の便利な機能をすべて備えているわけではありません。これは、プロダクション環境でリバースプロキシを使用することを推奨する唯一の理由です。リバースプロキシの目標は、処理中のHTTPサーバーへの転送要求だけでなく、セキュリティ、圧縮、およびその他の優れたWebサーバーが提供する機能を担当します。

コンテナの配備に関しては、実際に達成したいことに依存します。さまざまなシナリオがあります。

• ASP.NETコアアプリケーションとリバースプロキシを同じコンテナで実行します。この場合、ASP.NETコアアプリケーションは通常、ローカルポートで実行するように設定されています。 5000、リバースプロキシはポート80にバインドします。ベストプラクティスでは「各コンテナには1つの懸念がある」と言われているため、このアプローチは一般的に推奨されていません。
• 逆プロキシとASP.NETコアアプリケーションを2つの異なるコンテナで実行します。この場合、リバースプロキシからWebアプリケーションにリクエストを転送するには、これらのコンテナを相互にリンクする必要があります。
• 1つのコンテナでリバースプロキシを実行し、複数のASP.NETコアアプリケーションコンテナのリバースプロキシとして構成します。