Asp.Net Core 中的反向代理和程序內 HTTP 伺服器
我正在閱讀有關
KestrelWeb 伺服器的內容，asp.net core app特別是in-process http server和reverse proxy.作為一名季節性 Web 開發人員，我很難理解背後的想法：
in-process http server核心應用程序中的實現的相關性？- 反向代理方法對任何典型的重要性
web server？- 除了轉發之外，反向代理在 asp.net 核心世界中解決的問題類型是
http request什麼？- 如果 asp.net 核心應用程序打算部署在容器中，
reverse proxy如何關聯Kestrel/通信（1:n或）？1:1
根據官方文件：
ASP.NET Core 設計為在其自己的程序中執行，以便它可以跨平台一致地執行。IIS、Nginx 和 Apache 決定了它們自己的啟動過程和環境；要直接使用它們，ASP.NET Core 必須適應每個人的需求。使用諸如 Kestrel 之類的 Web 伺服器實現可以讓 ASP.NET Core 控制啟動過程和環境。因此，與其嘗試使 ASP.NET Core 適應 IIS、Nginx 或 Apache，您只需設置這些 Web 伺服器以代理對 Kestrel 的請求。這種安排允許您的 Program.Main 和 Startup 類在本質上是相同的，無論您在哪裡部署。
除此之外，擁有程序內 http 伺服器使開發人員的工作變得更加容易。他們只需下載框架並安裝它，無論他們使用什麼作業系統（Windows、Linux 或 MacOS）或他們以後想使用什麼 Web 伺服器，它都可以開箱即用。他們只是觸發
dotnet run命令啟動 http 伺服器並在其上託管一個 web 應用程序。當應用程序準備好用於生產時，可以在開發環境中執行它，但開發人員應該記住安全性。Kestrel Web 伺服器是非常新的 Web 伺服器，因此它沒有 IIS、Apache 或 Nginx 在其漫長的生命週期中獲得的所有安全性和其他有用的功能。這是 MS 建議在生產環境中使用反向代理的唯一原因。反向代理的目標不僅僅是將請求轉發到程序內的 http 伺服器，還要負責安全、壓縮和一個好的 web 伺服器可能提供的其他功能。
至於容器部署，它實際上取決於您想要實現的目標。有不同的場景：
- 在同一個容器中執行 ASP.NET Core 應用和反向代理。在這種情況下，ASP.NET 核心應用程序通常配置為在本地埠（例如 5000）上執行，而反向代理綁定到埠 80。通常不建議使用這種方法，因為最佳實踐說“每個容器應該只關註一個問題”
- 在 2 個不同的容器中執行反向代理和 ASP.NET Core 應用程序。在這種情況下，您必須將這些容器相互連結，以便將請求從反向代理轉發到 Web 應用程序。
- 在一個容器上執行反向代理並將其配置為多個 ASP.NET 核心應用程序容器的反向代理。