0. Die Kurzfassung

Wenn man in einen Browser eine Adresse eingibt, etwas www.herr-rau.de/wordpress/, geschieht Folgendes:

1. Der Browser erstellt eine Verbindung zu dem Teil dieser Adresse, der den Server angibt, zum Beispiel www.herr-rau.de. Die Verbindung wird bei http auf Port 80 angefragt beziehungsweise mit zusätzlicher Verschlüsselung auf Port 443 bei https.
2. Der Browser schickt über diese Verbindung eine HTTP-Anfrage an diese Adresse, die mindestens folgende Zeilen enthält. Nach dem GET steht die angeforderte Ressource auf dem Server:
   GET /wordpress/ HTTP/1.1
Host: www.herr-rau.de
3. Der Browser erhält eine Antwort und stellt sie dar.

Hier stelle ich ein kleines Programmierergebnis für die Schule vor, mit dem man das und Varianten davon ausprobieren kann. Den Code gibt es hier: https://codeberg.org/HerrRau/TCP_in_der_Schule

Als Filmchen:

Dieser Blogeintrag ist entstanden als Skript für die Schule; das erklärt den vielleicht ungewohnten Tonfall. Im Unterricht vermittle ich das anders, das hier ist zum Nachlesen für zuhause.

1. Das Client-Server-Prinzip

Im Internet laufen viele Abläufe so ab, dass ein Client-Programm (das auf einem Rechner läuft, den man auch Client nennt) eine Anfrage an ein Server-Programm (das auf eine Server-Rechner läuft) stellt und daraufhin eine Antwort erhält.

Lernwörter: Client, Server

2. Die Verbindung zwischen Client und Server

Im Internet sind die Rechner ja nicht unmittelbar durch ein Kabel verbunden. Auf einer oberen Ebene, die heißt Anwendungsschicht, kann man einfach davon ausgehen, dass es irgendwie halt eine Verbindung zwischen Client und Server gibt. Die Anwendungsschicht interessiert sich nicht, wie diese Verbindung zustande kommt oder wie die am Ende physisch aussieht, ob Kabel oder WLAN oder über Zwischenrecher oder wie auch immer.

Man kann sich eine Verbindung so vorstellen, dass an den beiden Enden der Verbindung jeweils eine Blechdose ist mit einer langen verbindenden Schnur dazwischen, und in die Blechdose kann man hineinsprechen und das kommt dann am anderen Ende an. Ein Server hält meist einen ganzen Vorrat solcher Blechdosen vorrätig, weil ja oft gleichzeitig mehrere Clients etwas von ihm wollen. Der Client braucht dagegen nur die eine Blechdose.

Im Bild: links ein vielarmiger Server, rechts ein Außerirdischer mit einer Dosenverbindung zu ihm.

(Es gibt auch andere Übermittlungsverfahren, die mehr nach dem Flaschenpost-Prinzip funktionieren als nach dem Dosen-Prinzip; die sind manchmal schneller und einfacher, aber nicht so zuverlässig. Uns geht es heute nur um die Blechdosen-Variante.)

Lernwörter: Verbindung

3. Ports und Sockets

Der Fachausdruck für Blechdose ist Socket. Wenn ein Client ein Socket für die Verbindung zu einem Server einrichten will, braucht er dazu a) die Adresse des Servers, zum Beispiel 85.13.157.184 und zweitens einen Port für die Verbindung. Das ist erst einmal einfach nur eine beliebige Zahl. Unter einer Server-Adresse können nämlich verschiedene Server gleichzeitig laufen: ein Webserver, ein Medienserver, ein E-Mail-Server, und damit die auseinander gehalten werden, gehört der Port zum Socket dazu.

Der Client sagt also: „Bitte ein Socket zu 85.13.157.184 auf Port 80“, und wenn unter dieser Adresse ein Server auf Port 80 auf Verbindungswünsche wartet, dann kommt eine Verbindung zustande. Sonst halt nicht. Das Verfahren für die Blechdosen-Verbindung heißt TCP, Transmission Control Protocol.

Viele der Ports sind standardisiert. Anfragen an einen Webserver laufen über Port 80, bei Verschlüsselung über Port 443. Wenn man abfragt, ob neue E-Mail da ist, werden dazu die Ports 143 oder 220 verwendet, bei Verschlüsselung auch 993 oder 995. Zum Verschicken von E-Mail dienen die Ports 25 oder 487. Wenn ich mich auf einem fremden Rechner einloggen möchte, und das technisch zugelassen ist, findet das meist auf Port 22 statt.

Viele Ports sind also für bestimmte Anwendungen vorgesehen, es gibt aber noch ausreichend freie Ports. Der Client muss halt nur wissen, auf welchem Port bei der Server-Adresse etwas angeboten wird, und der Server muss es auch anbieten.

Lernwörter: Port

Aufgabe: Starte den Client im Modus „Lokal“. Mit dem Knopf „Verbindung herstellen!“ kannst du auf Port 80 eine Verbindung zu beliebigen Adressen im Web herstellen. Etwa: dailyimage.de, httpforever.com, facebook.com. Probiere ein paar davon aus. Allerdings bringt das noch nicht viel, weil du erst in einem nächsten Schritt Anfragen über diese Verbindung schicken musst, damit etwas geschieht.
Beende die Verbindung, wenn du sie nicht mehr brauchst. Die angefragten Webserver werden vermutlich ohnehin nach jeder HTTP-Anfrage die TCP-Verbindung gleich oder nach ein paar Sekunden schließen; das erkennst du an der Zeile „Connection: Closed“ in der Antwort.

(Probiere auch ein oder zwei andere Ports aus; du dürftest keine Verbindung herstellen können, weil auf diesen Ports kein Server erreichbar ist. Mach das aber nicht zu oft, denn das könnte bereits als illegales Hacken ausgelegt werden. Die Rechtslage ist unklar, aber es ist in Deutschland möglicherweise verboten, automatisiert zu überprüfen, welche Ports bei einer Adresse offen, also erreichbar, sind; das heißt Port Scanning.)

3. Der Witze-Server und das Witze-Protokoll

Ich habe einen kleinen Witze-Server programmiert, den ich auf einem Rechner laufen lassen kann. Der Port ist beliebig, sagen wir: 54000. Ein Client kann eine TCP-Verbindung zu dem Server aufmachen, wenn er dessen Adresse weiß. Da der Client auf dem gleichen Rechner läuft wie der Server, kann ich als Adresse 127.0.0.1 oder auch localhost angeben, das sind Pseudo-Adressen für: ist der gleiche Rechner, auf dem du eh bist. Deswegen gibt es auch T-Shirts mit der Aufschrift „There‘s no place like 127.0.0.1“

Sobald die Verbindung steht, kann ich dem Server Nachrichten schicken. Bei meinem Server geht das nur in Form von Text. Bei folgenden Anfragen erhält man als Response lediglich „Anfrage nicht verstanden.

hallo
erzähl mir einen Witz
erzähl mir einen Witz
wie funktioniert denn das?

Das Witz-Protokoll verlangt nämlich, dass die Buchstaben „Witz“ und „Bitte“ (Großschreibung egal) in irgendeiner Form geschickt werden. Fehlt das „Witz“, kriegt man „Was willst du?“, fehlt das „Bitte“, kriegt man „Wie heisst das Zauberwort?“ Bei folgenden Anfragen erhält man als Response demnach einen – zufällig ausgewählten – Witz:

bitte 1 witz
Witz, bitte
bittewitz
Das ist doch ein Witz! Bitte.?

Warum sieht das Witze-Protokoll so aus? Einfach so, weil ich mir das ausgedacht habe.

Lernwörter: Protokoll

Aufgabe: Wenn du kannst, lass auf deinem Rechner den Witzeserver laufen. Lass ebenfalls auf deinem Rechner den Client laufen, weiterhin im Modus „Lokal“. Verbinde den Client mit dem Server; als Adresse kannst du 127.0.0.1oder localhosteingeben; der Port sollte eine höhere Zahl sein, etwa 54000. Schicke dann Anfragen an ihn.

4. Echo-, Chat- und Sprichwortserver

Ich habe auch noch weitere ähnliche Server programmiert, die man gleichzeitig (aber eben jeweils auf einem anderen Port!) laufen lassen kann.

1. Der Echo-Server akzeptiert jeden Input und schickt die Nachricht in umgekehrter Reihenfolge zurück.
2. Der Joke-Server sendet dann einen zufälligen Witz zurück, wenn die Anfrage die Wörter „witz“ und „bitte“ enthält.
3. Der Sprichwort-Server sendet ein zufälliges Sprichwort zurück, wenn du ihm ok sendest.
4. Der Chat-Server sendet alles, was du eingibst, an alle anderen Teilnehmer im Chat.

Aufgabe: Lasse auch diese Server laufen, nacheinander oder gleichzeitig auf verschiedenen Ports

Leider sind im Computerraum die Ports so gesperrt, dass du nur einen Server auf deinem eigenen Rechner erreichen kannst, die auf den anderen Rechnern sind nicht zugänglich.

Vorgeschlagene Standard-Ports:

Server	Port	Protokoll-Elemente
Echo-Server	54000	(beliebig)
Joke-Server	54001	witz (und) bitte
Sprichwort-Server	54002	ok
Chat-Server	54003	(beliebig)

5. Web-Server

Ein Webserver ist ein Programm, das auf Anfragen in einer bestimmten Form damit reagiert, dass das Erwartete in einer bestimmten Form zurückgeschickt wird, meist eine Webseite; es könnte aber auch eine Bilddatei sein.

Dabei müssen sowohl Anfrage als auch Antwort einem bestimmten Protokoll folgen, also eben eine bestimmte Form haben. Die Wörter „Bitte“ und „Witz“ spielen anders als im Witze-Protokoll keine Rolle, aber im Hypertext Transfer Protocol HTTP ist festgelegt, wie man Anfragen korrekt formuliert und welche Art Antworten man in welcher Form zu erwarten kann. Häufig beginnen die Antworten mit den Fehlermeldungen „404 Not Found“ oder „400 Bad Request“. Letzteres kriegt man gerne dann, wenn man die HTTP-Anfragen selber von Hand schreibt, statt sie dem Browser zu überlassen, und dabei in irgendeiner Form gegen das Protokoll verstoßen hat.

Du sollst nach und nach lernen, wie dieses Protokoll HTTP aussieht. Keine Sorge, es sind nur zwei Zeilen.

Lernwörter: Webserver, HTTP

6. Eigene HTTP-Anfragen

Aufgabe: Starte den Client im Modus „Einfach“. Lade nacheinander die Beispiele und verbinde dich erst mit dem Server, bevor du dann die voreingestellte HTTP-Anfrage abschickst.
Wenn du das Prinzip verstanden hast, kannst du auch andere Server als in den Beispielen ausprobieren. Bei der Adresse kannst du einen Namen wie „facebook.com“ aingeben; eine IP-Adresse funktioniert auch, wenn du eine geeignete kennst. (In späteren Beispielen wird das nur noch mit Namen gehen.) Der Port muss bisher immer 80 sein.

Wie es funktioniert

Wenn man eine TCP-Verbindung zu 85.13.157.184 auf Port 80 hergestellt hat, dann kann man über diese Verbindung folgende drei Zeilen schicken (es sind tatsächlich drei Zeilen, denn die Leerzeile am Ende gehört mit zum Protokoll):

GET /index.html HTTP/1.1
Host: www.dailyimage.de

Als Antwort sollte man das hier erhalten:

HTTP/1.1 200 OK
Date: Sat, 20 Jun 2026 16:28:09 GMT
Server: Apache
Upgrade: h2,h2c
Connection: Upgrade
Last-Modified: Sat, 20 Jun 2026 16:24:17 GMT
ETag: "ef-654b1d746e0d5"
Accept-Ranges: bytes
Content-Length: 239
Vary: Accept-Encoding,User-Agent
Content-Type: text/html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title></title>
</head>
<body>

<p>
Welch Wort entfloh dem Gehege deiner Zähne?
</p>

</body>
</html>

Schauen wir uns die Antwort an: Alles ab dem „<!DOCTYPE“ ist die gesendete Webseite. Alles davor ist der Kopf der Antwort. Der Status ist 200 OK, es hat also alles geklappt. Auch die anderen Angaben sind lauter Angaben, die ein Client, also meist ein Browser, sinnvoll verarbeiten und nutzen kann.

Am Ende sollte ich übrigens die Verbindung (das mit den Dosen) wieder schließen, damit der Webserver nicht mit unnötig vielen Dosen jonglieren muss. Es steht dem Webserver aber auch frei, die Verbindung selbsttätig zu schließen, entweder sofort nach der Anfrage oder nach einigen Sekunden Wartezeit. Dem Connection: Upgradein der Antwort oben kann man entnehmen, dass der Server die Verbindung eben nicht geschlossen hat; man könnte also gleich weitere Anfragen nachschicken, ohne erst mit den Dosen hantieren zu müssen.

Was die Anfrage-Zeilen bedeuten

Schauen wir uns die Anfrage noch einmal an, die hat es nämlich in sich:

GET /index.html HTTP/1.1
Host: www.dailyimage.de

Die erste Zeile ist nötig:

• Sie enthält das Schlüsselwort GET gefolgt von einem Schrägstrich und der angeforderten Ressource.
• Die Ressource ist in diesem Fall eine Datei namens index.html, sich auf der obersten Ebene des Hosts befindet. Da könnte man auch nur /schreiben, dann sucht der Webserver standardmäßig nach einer Datei, die so oder so ähnlich heißt.
• Dann folgt die Protokollversion, denn 1.2 oder 1.3 oder gar 1.0 unterscheiden sich in einigen Punkten. 1.1 ist die übliche Version.

Die zweite Zeile ist auch nötig:

• Um welche Web-Adresse geht es überhaupt? Das ist deshalb wichtig, weil sich unter der IP-Adresse, mit der wir uns verbunden haben (das war das mit den Dosen) verschiedene Host-Adressen befinden könnten, die alle verschiedene Dateien namens index.html auf der obersten Ebene liegen haben. Es ist nämlich tatsächlich so, dass sich unter 85.13.157.184 nicht nur dailyimage.de, sondern auch herr-rau.de und taschenbuchschuerfer.de und neuronenzirkus.de und noch eine Reihe anderer Adressen aufrufen lassen. Die habe ich alle auf diesem gemieteten Server laufen, und andere Kunden haben auf dem gleichen Server vermutlich etliche weitere Adressen. Deswegen muss man in der HTTP-Anfrage den korrekten Host angeben.

Weitere Zeilen sind optional, aber üblich. Wikipedia etwa antwortet nur dann mit dem Gewünschten, wenn Information zum User-Agent mitgeschickt wird; Connection: disconnectwürde mitteilen, dass die Verbindung danach gleich wieder geschlossen werden kann.

Tückisch ist außerdem eines: Die HTTP-Anfrage besteht aus mindestens drei Zeilen, davon ist die letzte leer. Aber was eine Zeile ist, darüber streiten sich die Betriebssystem. Für Linux, Unix, MacOS ist alles eine Zeile, was mit einem nicht druckbaren Zeichen NEWLINE, das gerne mal als "\n" repräsentiert wird, endet. Für alte Versionen von MacOS ist alles eine Zeile, was mit dem ähnlich nichtdruckbaren Zeichen CARRIAGE RETURN, auch "\r", endet. Für Windows ist alles eine neue Zeile, was mit der Kombination"\r\n" endet. Für menschliche Augen im Textfenster sieht das alles gleich aus. Für die HTTP-Anfrage muss die Zeile immer mit "\r\n" enden.

Weitere Aufgaben

Aufgabe: Formuliere HTTP-Anfragen an den Server 85.13.157.184 auf Port 80, um folgende Ressourcen zu laden:

• /bild.jpg auf dem Host dailyimage.de
• /gedicht.html auf dem Host dailyimage.de

7. Zwischenfazit

Kein Mensch erstellt von Hand eine HTTP-Request und verarbeitet die HTTP-Response von Hand. Das überlässt man einem Programm, die können das besser. Es muss nicht gleich ein ganzer Browser sein, für die meisten gängigen Programmiersprachen dürfte es Pakete geben, in den das alles von Fachleuten sauber programmiert wurde.

Aber es ist ein besonderes Gefühl, das selber zu machen. Die TCP-Verbindung wird von der Programmbibliothek erstellt, alles andere, also auf der Anwendungsschicht, schreiben wir selber, egal ob Witze-Anfragen oder HTTP-Requests.

(Fortsetzung hier.)