Hilfe zum Verständnis von serverseitigem Scripting

Soweit ich weiß, gibt es heutzutage grundsätzlich drei Optionen für serverseitiges Scripting:

1. Unter Verwendung von Skriptsprachen, die direkt vom Webserver interpretiert / ausgeführt werden können (z. B. PHP und ASP), wobei die Skripte im laufenden Betrieb interpretiert / ausgeführt werden (dh wenn HTTP-Anforderungen eingehen), wird die Ausgabe dann in HTML-Seiten eingebettet an den Kunden zurückgeschickt.

2. Mit einer beliebigen Sprache (z. B. C, C ++, PERL, Python) kann das Betriebssystem des Servers ausgeführt werden (entweder mit einem Interpreter oder mit der bereits kompilierten ausführbaren Datei) und anschließend mit CGI zwischen dem Webserver und dem Betriebssystem kommunizieren . Die Ausgabe der Skripte erfolgt über CGI in Form vollständiger HTML-Seiten an den Server und wird dann an den Client zurückgesendet.

3. Verwenden von Java auf einem Server, der Servlets / JSPs verarbeiten kann. Dies entspricht weitgehend der obigen Idee wie Option 1, außer dass Java anstelle von PHP / ASP verwendet wird.

Fragen :

1. Ist mein Verständnis bisher auf dem richtigen Weg oder habe ich etwas falsch gemacht?

2. Sind ASP und PHP die einzigen Sprachen, die direkt von einem Webserver interpretiert und ausgeführt werden können?

3. Wo fällt Ruby in die obige Klassifizierung? Kann es von Servern wie PHP interpretiert / ausgeführt werden? Oder kommuniziert es über CGI?

4. Wird serverseitiges Scripting über CGI veraltet oder gar nicht?

Ihr Verständnis ist richtig, wenn Sie aus der Vergangenheit sind. Sie beschreiben ziemlich genau, wie es in den neunziger Jahren aussah.

Ja, viele Sprachen können direkt von einem Webserver-Plugin ausgeführt werden. Mod_php für Apache ist für PHP immer noch die beliebteste Methode, um es zu hosten. Websites mit hohem Datenverkehr verwenden jedoch einen moderneren Ansatz und verwenden den Webserver nur als Proxy für FastCGI (im Falle von PHP ist es PHP-FPM ).

Die Ausgabe wird in HTML-Seiten eingebettet und dann an den Client zurückgesendet.

Ich denke, Sie beziehen sich auf den sogenannten Spaghetti-Code der frühen 90er Jahre, aber der moderne Ansatz besteht darin, eines von vielen MVC-Frameworks zu verwenden. Im Falle von PHP würde dies beispielsweise Zend Framework bedeuten (es gibt zahlreiche Alternativen).

Was ASP betrifft, so beziehen Sie sich wahrscheinlich auf den sogenannten "klassischen ASP", der veraltet ist. Derzeit ist es ASP.NET, das jede der .NET-Sprachen verwenden kann (C # ist die beliebteste), und natürlich das .NET-Framework.

C und C ++ werden normalerweise nicht für Webanwendungen verwendet. In diesem Fall werden solche Dienste entweder als eigenständige Server, als Modul für den Webserver oder als FastCGI implementiert .

Perl kann mit mod_perl direkt vom Web-Serve-Modul ausgeführt werden . Es gibt auch PSGI , das im Grunde ein Klon von Pythons WSGI ist .

Python ist eine sehr beliebte Sprache für Web-Apps. Es kann direkt vom Apache-Webserver über mod_python ausgeführt werden, dies ist jedoch veraltet und wird nicht empfohlen. Derzeit erfolgt der Weg zu Python entweder über das WSGI -Servermodul. In Python implementierter WSGI- Server (z. B. CherryPy, WebPy) oder unter Verwendung eines eigenständigen Python-Webstacks (das Webmodul von Tornado und Twisted sind gute Beispiele). Und natürlich würden Sie höchstwahrscheinlich wieder ein WSGI- kompatibles MVC-Framework verwenden. Django ist das beliebteste (wieder mehrere Alternativen verfügbar).

Ruby, wieder eine sehr beliebte Sprache für Web-Apps. Am bekanntesten für das Webframework Ruby on Rails, das wiederum MVC ist. Sie können Ruby direkt vom Servermodul über mod_ruby oder über FastCGI ausführen .

Servlets / JSP werden auf eigenständigen J2EE-Anwendungsservern wie JBoss oder Tomcat ausgeführt. Es wird häufiger verwendet, um dem Geschäftssystem eine Weboberfläche hinzuzufügen, als eigenständige Webanwendungen zu erstellen.

Klassisches CGI (dh Laichprozess bei jeder Anfrage) ist vor vielen Jahren veraltet. Es wurde durch FastCGI (bei dem der Prozess lange läuft und nicht bei jeder Anforderung erzeugt wird), Servermodule, Schnittstellen wie WSGI und Klone sowie eigenständige Lösungen ersetzt.

Auch das Paradigma der Anforderungsverarbeitung hat sich weiterentwickelt, mit CGI wurde es pro Anforderung verarbeitet. Dann war Prozesspool (oder Thread-Pool), wobei jeder Prozess (Thread) jeweils eine Anforderung behandelte. Der modernste Ansatz besteht jedoch darin, dass Webserver und eigenständige Frameworks ereignisgesteuerte Programmierung verwenden.

Lassen Sie mich dies vorwegnehmen, indem Sie sagen, dass dies eine äußerst allgemeine und vereinfachte Ansicht dessen ist, was passiert.

Webserver-Software (wie Apache oder IIS) interpretiert keinen Code. es weiß nicht wie. Alles, was es zu tun weiß, ist, eine Anfrage entgegenzunehmen, sie an einer Stelle im Dateisystem nachzuschlagen und das angeforderte Element dann an den Browser zurückzusenden. Das ist alles, was es tut - auf einer sehr einfachen Ebene. Aus diesem Grund erhalten Sie bei der Installation von Apache und dem Hinzufügen einer PHP-Datei zu DocumentRootnicht das ausgeführte PHP-Ergebnis. nur die Datei zurück.

Der erste Schritt, um den Server dazu zu bringen, etwas anderes als Served-Dateien auszuführen, besteht darin, Code hinzuzufügen, der ihn anweist, etwas anderes zu tun, wenn eine bestimmte Datei angefordert wird. Andernfalls wird lediglich versucht, die Datei gemäß ihrem Standard-MIME-Typ (normalerweise Text / Nur-Text) bereitzustellen. Aus diesem Grund wird bei einem falsch konfigurierten Server und bei der Anforderung index.phpder Quellcode für die Datei anstelle des beabsichtigten Ergebnisses angezeigt.

Damit ein Webserver PHP "versteht", müssen Sie ihm mitteilen, was zu tun ist, wenn eine Anforderung für eine Datei mit der .phpErweiterung mod_phpeingeht . Hier kommt sie an. Dieses Modul verlagert die Anforderung an einen PHP-Interpreter (wie es geht) kann das konfiguriert werden), der dann die Datei liest, den Code ausführt, die Ergebnisse kompiliert; und sendet die Ergebnisse zurück an den Server, der wiederum die Ergebnisse an den Client liefert. Anschließend konfigurieren Sie den Webserver so, dass alle Dateien mit .php am Ende von mod_php verarbeitet werden.

Dieser grundlegende Workflow wird auch in anderen Sprachen angewendet. Der einzige Unterschied besteht darin, wohin der Server die Anforderung "auslagert".

Der Fall für PHP ist oben erläutert, gibt es in ähnlicher Weise mod_python, und fastcgi, wsgiund andere etablierte Protokolle auf Offloading - Anfragen , dass ein Web - Server ist nicht zu handhaben gestaltet.

Die meisten gängigen Implementierungen haben einen lang laufenden Prozess, der auf eine Anforderung an einem bestimmten Port (oder Socket) wartet. Der Webserver wird dann als Proxy konfiguriert , sodass alle Anforderungen, die einem bestimmten Muster entsprechen, an diesen lang laufenden Prozess übergeben und die Ergebnisse zurückgelesen werden.

So funktionieren Ruby on Rails (Rack) und Python-Skripte (mit WSGI).

Dies ist auch der Grund, warum einfache Proxy-ähnliche Webserver wie Nginx sehr beliebt sind. Sie erledigen nur die grundlegenden Aufgaben eines herkömmlichen Webservers - stellen die "statischen" Dateien bereit und können Anforderungen sehr gut an andere Proxyserver auslagern, um Dinge wie PHP, Python, ASP usw. zu erledigen. al.

Am Ende haben Sie also den Webserver, der sich um die statischen Dateien kümmert, alles, was nicht verarbeitet werden muss.

Sie haben einen anderen Prozess, der mit Ihrem Code umgehen kann (z. B. einen Prozess, auf dem der PHP-Interpreter ausgeführt wird, oder einen uWSGI-Server). Dies sitzt und wartet auf Anfragen vom Webserver.

Schließlich haben Sie Systeme wie Upstart und Supervisor, die diese Prozesse für Sie verwalten.

Hoffe das klärt die Sache.

Es gibt eine vierte Option, die am ernsthaftesten verwendet wird. Websites wie Banken oder andere Finanzdienstleistungen: Der n-Tier-Ansatz ähnelt CGI, außer dass der CGI-Prozess auf einem anderen Server ausgeführt wird. Der Webserver-Code ist sehr dünn (gerade genug, um Daten in HTML umzuformatieren) und ruft ' cgi 'Dienste über Netzwerkprotokolle wie RPC oder SOAP.

Es ist immer noch der gleiche grundlegende Ansatz, der einen Webserver als Gateway zwischen der vom Client-Browser gestellten http-Anforderung und einer 'Code-Engine' verwendet, die die Geschäftslogik hostet. Beachten Sie, dass in diesem Fall der Webserver die Anforderung an eine Skript-Engine in einer Sprache (z. B. PHP oder XSLT) weiterleitet, die wiederum einen anderen Dienst aufruft, der Rohdaten bereitstellt. Das Web-Skript wird ausschließlich zum Formatieren dieser Daten in HTML verwendet Seite, die an den Browser geliefert wird.