Was ist der Unterschied zwischen einem Webserver und einem Webframework?


Antwort 1:

Ein "Web-Framework" bietet eine Reihe von APIs, mit denen Sie Ihren eigenen benutzerdefinierten Code so schreiben können, dass er über das Web aufgerufen werden kann. Normalerweise behandelt ein Framework allgemeine Details wie das Parsen von HTTP-Headern, das URL-Routing usw.

Ein Webserver ist eine Software, die auf einem Netzwerkport auf eingehende HTTP-Anforderungen wartet und auf diese reagiert. Die meisten Webserver haben einen Standardmodus, in dem sie die eingehende Anforderung als Pfad im Dateisystem interpretieren und die Datei unter diesem Pfad zurückgeben. Sie können jedoch normalerweise so konfiguriert werden, dass sie stattdessen etwas anderes mit der Anforderung tun (an ein CGI-Skript übergeben). Proxy auf einen anderen Server, führen Sie einen benutzerdefinierten Modulcode aus usw.).

Wenn Sie sich für Apache oder Nginx (im Allgemeinen als Webserver bezeichnet) interessieren, können Sie diese möglicherweise auch als Webframeworks beschreiben, da beide umfangreiche Konfigurationsoptionen und eine C-Modul-API zum Schreiben von benutzerdefiniertem Code bieten. Die meisten Leute werden sie aber nicht so nennen.

Wenn Sie node.js als Framework betrachten (was meiner Meinung nach eine vernünftige Interpretation ist, andere jedoch nicht mit mir übereinstimmen), können Sie es auch als Webserver betrachten, da es eine einigermaßen robuste HTTP-Server-Implementierung enthält begann mit einem einzigen Funktionsaufruf.

Das Problem hierbei ist wirklich, dass sich das Konzept eines "Web-Frameworks" nicht für eine grundsolide Definition eignet.

Ich stelle mir vor, diese Antwort ist eher verwirrend als hilfreich, wofür ich mich entschuldige.


Antwort 2:

Der Webserver ist ein Programm, das http-Anforderungen verarbeiten kann. Egal, ob es die vollständige Spezifikation abdeckt und ob es gut funktioniert. Die Implementierung eines solchen Minimal-Webservers ist nicht so kompliziert. Heutzutage können Sie auf jeder wichtigen Webentwicklungsplattform einen einfachen Webserver starten. Das ist normalerweise in einigen Bereichen gut genug, aber selten funktioniert es unter allen Bedingungen sehr gut.

Manchmal ist die Plattform ein Anwendungsserver, der auch einen Webserver und möglicherweise ein Framework oder zumindest auch Konnektoren enthält (aber viel mehr unterstützen kann) - wie Java EE-Server. Andere Beispiele könnten Ruby + RoR und Webrick sein - das sollte ein anständiger Webserver sein oder node.js, was auch ziemlich beeindruckend ist.

Und diese Lösungen eignen sich sehr gut für kleinere Projekte und sollten auch für die Bereitstellung statischer Dateien ausreichend sein.

Wo ist nun der Unterschied zu den großen Jungs wie Apache, Nginx und anderen?

Die spezialisierten Webserver sind schnell, arbeiten unter hoher Last und verfügen über Module zur Behandlung vieler Probleme wie Überlastung (DOS-Angriffe), Sicherheit und Zugriffskontrolle, Ablaufheader, Komprimierung, SSL, HTTP Version 2, URL-Umschreibung, virtuelle Hosts, Standard Protokollierungsformate, MIME-Typen, Proxy, mehrere Versionen von Inhalten und vieles mehr.

Ich habe einen Framework-Benchmark für den Leistungsvergleich von TechEmpower Web Framework gefunden, der die Leistung für 20 Anforderungen pro Sekunde vergleicht und ein Framework als "jede HTTP-Server-Implementierung definiert, auf der Sie eine Webanwendung erstellen können".

Dieser Webserver-Benchmark-Leistungsvergleich für Webserver testet bis zu 3000 parallele Anforderungen. Beachten Sie auch nur den Speicherverbrauch der spezialisierten Webserver. Dasselbe mit den Framework-Lösungen zu tun, ist nicht ratsam.

Die übliche (nicht nur eine) Konfiguration besteht darin, den statischen Inhalt mit dem spezialisierten Webserver zu verarbeiten und nur dynamische Anforderungen an das Framework zu übergeben.


Antwort 3:

Ich hasse es, wenn Begriffe, die echte, diskrete Bedeutungen haben, zu einem semantischen Glop werden.

Ein Webserver wartet auf Webverbindungen und stellt entweder statischen Inhalt aus Dateien bereit oder leitet Anforderungen an anderen Code weiter. Ursprünglich bedeutete das "Weitergeben" das Ausführen von Programmen (normalerweise Skripten), die vom WS getrennt waren, unter Verwendung eines Protokolls namens CGI (nur eine Standardmethode zum Beschreiben des Aufrufs des Skripts, Übermitteln der Anforderung, von wem es kam usw.). Skriptbibliotheken, Das Parsen von CGI-Anforderungen oder das Generieren von HTML wurde zum ersten Web-Framework. Es wurde üblich, den Overhead dieser externen Skripte zu reduzieren, indem der Skriptinterpreter auf das WS übertragen wurde. Web-Frameworks haben im Laufe der Zeit begonnen, einen Großteil des Anforderungs-Parsing-Aspekts des WS ("Routing") zu übernehmen - genug, so dass einige Frameworks beschlossen, auf das WS vollständig zu verzichten. Der Stil der Webprogrammierung hat sich ebenfalls geändert: Javascript fügt jetzt einen Großteil der WF-Logik in den Browser ein, so dass die Logik, die sich noch im WS befindet, möglicherweise stark reduziert wird (im Gegensatz zum ursprünglichen CGI-Begriff, bei dem der Browser wirklich nur behandelt wird Rendern eines statischen HTML-Blobs, der vom WS bereitgestellt wird.)

Wenn Leute WS sagen, meinen sie normalerweise ein generisches WS wie Apache. Wenn Leute WF sagen, meinen sie normalerweise etwas wie PHP oder ein moderneres JS-basiertes System, das Templating, ORM, Routing usw. umfasst.


Antwort 4:

Ich hasse es, wenn Begriffe, die echte, diskrete Bedeutungen haben, zu einem semantischen Glop werden.

Ein Webserver wartet auf Webverbindungen und stellt entweder statischen Inhalt aus Dateien bereit oder leitet Anforderungen an anderen Code weiter. Ursprünglich bedeutete das "Weitergeben" das Ausführen von Programmen (normalerweise Skripten), die vom WS getrennt waren, unter Verwendung eines Protokolls namens CGI (nur eine Standardmethode zum Beschreiben des Aufrufs des Skripts, Übermitteln der Anforderung, von wem es kam usw.). Skriptbibliotheken, Das Parsen von CGI-Anforderungen oder das Generieren von HTML wurde zum ersten Web-Framework. Es wurde üblich, den Overhead dieser externen Skripte zu reduzieren, indem der Skriptinterpreter auf das WS übertragen wurde. Web-Frameworks haben im Laufe der Zeit begonnen, einen Großteil des Anforderungs-Parsing-Aspekts des WS ("Routing") zu übernehmen - genug, so dass einige Frameworks beschlossen, auf das WS vollständig zu verzichten. Der Stil der Webprogrammierung hat sich ebenfalls geändert: Javascript fügt jetzt einen Großteil der WF-Logik in den Browser ein, so dass die Logik, die sich noch im WS befindet, möglicherweise stark reduziert wird (im Gegensatz zum ursprünglichen CGI-Begriff, bei dem der Browser wirklich nur behandelt wird Rendern eines statischen HTML-Blobs, der vom WS bereitgestellt wird.)

Wenn Leute WS sagen, meinen sie normalerweise ein generisches WS wie Apache. Wenn Leute WF sagen, meinen sie normalerweise etwas wie PHP oder ein moderneres JS-basiertes System, das Templating, ORM, Routing usw. umfasst.