Asp.Net Core中的反向代理和進程內HTTP服務器

Question

我正在閱讀asp.net core app Kestrel web服務器，特別是in-process http server和reverse proxy 。

作為季節性的Web開發人員，我無法理解背后的想法：

• in-process http server實現在核心應用程序中的相關性？
• 反向代理方法對任何典型web server的重要性？
• 除了轉發http request之外，問題的類型是否在asp.net核心世界中解決了反向代理問題？
• 如果asp.net核心應用程序要部署在容器中， reverse proxy和Kestrel如何關聯/通信（ 1:n或1:1 ）？

Answer 1

根據官方文件 ：

ASP.NET Core旨在在其自己的進程中運行，以便它可以跨平台一致地運行。 IIS，Nginx和Apache決定了他們自己的啟動過程和環境; 要直接使用它們，ASP.NET Core必須適應每個人的需求。 使用諸如Kestrel之類的Web服務器實現為ASP.NET Core提供了對啟動過程和環境的控制。 因此，您只需將這些Web服務器設置為代理對Kestrel的請求，而不是嘗試將ASP.NET Core調整為IIS，Nginx或Apache。 無論您在何處部署，這種安排都允許您的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核心應用程序容器的反向代理。