Client-Server-Kommunikation

Die Programmierkarriere beginnt meist mit Fehlersuche. Und das nicht zu knapp. Witzigerweise entstehen die teuren Fehler, also die, nach denen der geübte Tastenschubser tagelang ergebnislos forscht, wohl nicht aus Unachtsamkeit, sondern aus Unwissenheit. Fatalerweise entpuppt sich oft der Mangel an Grundkenntnissen als Fallstrick. Zentrale Bedeutung hat in dem Zusammenhang ein gesundes Verständnis der Vorgänge in der Client-Server-Kommunikation, insbesondere wenn man mit Webseitenprogrammierung beschäftigt ist.

Der Server ist dabei der zentrale Rechner, der sich dem Client anbiedert wie Tante Lottis Katze dem Fressnapf. Der Client steht bei Dir und mir zu Hause und läßt sich mit Hingabe von uns von einem Server zum nächsten jagen. Aber wie genau funktioniert die Interaktion zwischen Client und Server, wenn Du im Browser www.irgendwas.de eingibst?

Das Prinzip ist immer dasselbe: Der Browser - mache mögen den Internet Explorer, andere Firefox - des Clients pustet die URL-Eingabe, auch Request genannt, an den Server (1), der macht irgendetwas damit und trötet das Ergebnis zurück (6). So jedenfalls funktioniert jedenfalls HTTP (und HTTPS), was sich in dem HTTP://www.irgendwas.de ausdrückt, daß der Browser selbstständig unserer URL hinzufügt. Der Server schickt nichts von sich aus an den Client, wäre ja auch noch schöner. Auf dem Server passiert unterwegs jede Menge und deswegen schauen wir uns das mal genauer an:

Der Browser des Clients schickt einen URL-Request an den Server. Der Klick auf einen Link oder der Aufruf in der Browser-Adresszeile mündet in einem Get-URL-Request, das Abschicken eines Formulares in einem Post-URL-Request. Auf dem Server empfängt den URL-Request ein sogenannter Webserver (z.B.IIS, Apache oder Tomcat). Der Webserver entscheidet, wie der Request beantwortet werden soll. Statische HTML-Seiten-Anfragen, also z.B. von der statischen HTML-Datei www.irgendwas.de/irgendeinedatei.htm, beantwortet der Webserver selbst.
Aber Webserver lassen sich auch so konfigurieren, daß URL-Requests für Dateien mit bestimmten Endungen (z.B. .php oder .asp) als Webapplikation abgearbeitet werden sollen. Eine php-Datei wird dann beispielsweise von einem PHP-Prozessor durchgenudelt, wenn man das interpretieren und ausführen mal so nennen darf.

Dabei kann sie auf das Dateisystem des Servers und/oder ein Datenbanksystem auf denselben oder einen anderen Server zugreifen. Entscheidend ist, das die Komponenten Webserver, Webapplikation, Datenbank und Dateispeicher miteinander zusammen arbeiten und auf einem oder mehreren Servern laufen können. Typische Konfigurationen für Internetserver, wie Sie auch von Massenhostern angeboten werden:

Betriebssystem	Webserver	Webapplikation basiert auf	Datenbank	Urheber
Unix/Linux	Apache	+ PHP	+ MYSQL	jeweils Opensource
Unix/Linux	Apache	+ Java (Tomcat)	+ Oracle-Datenbank	Opensource+Oracle
Windows	IIS	+ ASP	+ SQL-Server	jeweils Microsoft

Das Dateisystem liefert als Antwort eine Datei, die Datenbank Datensätze - jeweils wenn die Rechte des Webserverbenutzers ausreichen (Lese- und/oder Schreibrechte).
Der von der Webapplikation auf die Standard-Ausgabe geschriebene Datenstrom (in PHP per echo oder print) wird an den Webserver weitergereicht.
Der Webserver sendet die Daten der Webapplikation oder des Dateisystems an den Client, wobei sich daran der Browser bedient und die ankommenden Daten darstellt. Die mitgesendete Portnummer und Sessioninformation identifizieren den richtigen Browser, und zwar den, der unter Punkt (1) den URL-Request gestellt hat. Wenn der ankommende Datenstrom HTML, Javascript oder CSS enthält, werden deren "Befehle" interpretiert und manipulieren so die Art und Weise, wie der Inalt dargestellt wird.

Wir haben nun gesehen, wie die Daten fließen, damit eine Webseite angezeigt wird. Und was ist mit den ganzen Abkürzungen? - HTML, CSS, PHP, u.s.w. Die kommen aus der Webprogrammierung. Viel Spaß beim Weiterlesen.

Haben Sie Fragen zu Client-Server-Kommunikation? Klicken Sie hier für Hilfe.