Warum IIS oder Apache Tomcat anstelle von Selbsthosting verwenden?

Ich bin ein .NET-Entwickler. Ich sehe, dass das ASP.NET MVC-Framework jetzt eine Selbsthosting-Funktion bereitstellt. Es macht sehr viel Sinn (für mich). Eine selbst gehostete Anwendung fühlt sich vollständig ohne externe Abhängigkeit an.

Die Frage, die ich im Kopf habe, ist jetzt, warum jemand sich NICHT selbst hosten möchte. Ich meine, gibt es irgendwelche Vorteile, die IIS mir gegenüber Selbsthosting bietet? Ich bin sicher, dass es einige Vorteile gibt, da sich Microsoft sonst nicht die Mühe gemacht hätte, die IIS-Integration mit dem asp.net-Kern zu erstellen.

Ich möchte nicht, dass meine Frage spezifisch für .NET ist. Also werde ich mitmachen - warum mit IIS oder Apache Tomcat anstatt Selbsthosting?

— bilal fazlani
quelle

Auf hoher Ebene verfügen große Webserver über eine Vielzahl von Funktionen, die Sie vollständig neu erstellen müssen und die Sie ansonsten konfigurieren oder einfach ignorieren können , wenn Sie sich selbst hosten. Einfache Dinge wie das Bereitstellen statischer Dateien sowie das Konfigurieren Expiresund ETagHeadern. Und dann kompliziertere Dinge, wie das Trennen des Datenverkehrs durch host, das Fernhalten von Anwendungen vom Speicher des anderen, SSL und das Verwalten von Tausenden von gleichzeitigen Anforderungen ...

— svidgen

Sie können einfach Ihren eigenen HTTP-Dienst mit C ++ - Sockets schreiben.

— Matthew Whited

dotnetfunda.com/interviews/exclusive/show/755/…

— Matthew Whited

Viele .net-Anwendungen nennen sich "selbst gehostet", während sie noch http.sys verwenden, was IMO eher irreführend ist.

— CodesInChaos

Meiner Ansicht nach ist dies lediglich eine historische Folge der Entwicklung der Anwendungsfälle für den TCP / HTTP-Protokoll- und Dienststapel. Im Fall von HTTP befand sich der Dämon oder Dienst beispielsweise über dem Betriebssystem als eine Art zentraler Hub für Webinhalte, an die andere lokale oder entfernte Anwendungen den Verbrauch oder das Angebot von Hypertext / Hypermedia delegierten Inhalt.

— YSharp

IIS bietet eine Reihe allgemeiner Funktionen, die in selbst gehosteten Webdiensten standardmäßig nicht verfügbar sind. Supervisor: Überwacht den Zustand der Webanwendung und beendet die Anwendung, wenn sie ungesund aussieht (mit zu viel Speicher, CPU usw. - konfigurierbar). Ressourcenbeschränkungen wie CPU-Auslastung, Verbindungsbeschränkungen usw. Als bestimmter Benutzer für die geringste Berechtigungssicherheit ausführen. Zertifikate / SSL verwalten. Hosten / verwalten Sie viele Anwendungen über einen Port / eine Schnittstelle. Proxy für Konsolenanwendungen umkehren. Viele andere Dinge, die ich nicht erwähnt habe, wie die Protokollierung von Anfragen.

Ich bin mit Tomcat nicht vertraut, aber ich gehe davon aus, dass es die gleiche Geschichte ist. Sie erhalten zusätzliche Hosting-Funktionen, die Ihnen Self-Hosting standardmäßig nicht bietet und die möglicherweise nur schwer selbst zu implementieren sind.

Oft empfehlen Produkte, die einen selbst gehosteten Webdienst verfügbar machen, diese weiterhin hinter einem Reverse-Proxy oder einem anderen Supervisor in der Produktion zu platzieren. Dies kann sein, um sicherzustellen, dass es Abstürze überlebt oder bei Netzwerkunterbrechungen ordnungsgemäß funktioniert. Ich denke zum Beispiel an NGINX für Docker-Dienste. Im .NET-Bereich wird Kestrel meines Erachtens standardmäßig über IIS (oder möglicherweise NGINX unter Linux / Mac) umgekehrt .

Traditionell wurden ASP.NET-Apps nur unter Windows auf dem Internet Information Server (IIS) gehostet. Die empfohlene Methode zum Ausführen von ASP.NET Core-Anwendungen unter Windows ist weiterhin IIS, jedoch als Reverse-Proxy-Server. Das ASP.NET-Kernmodul in IIS verwaltet und leitet Anforderungen an den Kestrel-HTTP-Server weiter, der außerhalb des Prozesses gehostet wird.

— Kasey Speakman
quelle