HTTP

HTTP (HyperText Transfer Protocol) ist das Standardübertragungsprotokoll im WWW. Es baut in der Regel auf TCP auf. Jede HTTP-Interaktion zwischen Client und Server besteht aus einer Anfrage des Clients und einer Antwort des Servers.

Struktur der Anfragen (requests) und Antworten (responses)

Die wichtigsten Requestparameter

User-Agent: Hier kann der Client mitteilen, welcher Browser die Anfrage sendet und in welchem Betriebssystem dieser läuft. Diese Information ist für Website-Betreiber wichtig, da sie so statistische Erkenntnisse darüber gewinnen, welche Browser/Betriebsssteme ihre User wie häufig verwenden und ihre Seite speziell für diese optimieren können.
Host: Das ist die Domain des Servers. Zusammen mit dem "Datei"namen bildet sie die Adresse der Seite. Der Server benötigt dieses Feld, da oft ein Server für mehrere Domains zuständig ist.
Accept-Language: Damit teilt der Browser dem Server mit, welche Sprache der User vorzugsweise spricht. Hat der Server mehrere Sprachversionen derselben Seite, so kann er mit dieser Information die für den User am besten passende auswählen oder ihn ggf. auch auf einen anderen Server umleiten.
Accept-Encoding: Der Client teilt dem Server mit, ob dieser die Antwort komprimieren darf und welche Algorithmen der ggf. einsetzen darf.
Connection: Früher wurde nach jedem HTTP-Resonse die darunterliegende TCP-Verbindung geschlossen. Das ging zulasten der Performance, da das Öffnen einer TCP-Verbindung jedesmal Zeit kostet. Geht der Client davon aus, dass nach dem aktuellen Request noch weitere folgen (z.B. um Bilder einer Website nachzuladen), so setzt er Connection: Keep-Alive und signalisiert so dem Server, dass er die TCP-Verbindung aus Performancegründen offenhalten möchte.
Cookie: Der Client kann dem Server sogenannte Cookies (das sind Schlüssel-Wert-Paare) übermitteln, die der Server bei einem vorhergehenden Request beim Client hinterlegt hat. Näheres dazu siehe unten.

Die wichtigsten Responseparameter

Date: Datum und Uhrzeit der Antwort
Server: Hier kann der Server angeben, welches Server-Programm zum Einsatz kommt und auf welchem Betriebssystem es läuft.
Cache-Control: Siehe unten
Content-Length: Das ist die Länge der nach dem Response-Header folgenden Daten in Byte. Der Client kann sie nutzen, um z.B. bei größeren Downloads einen Fortschrittsbalken anzuzeigen.
Content-Type: Per HTTP werden nicht nur Webseiten übertragen, sondern auch Bilder, pdf-Dateien, Sound, Videos usw. Mit diesem Parameter teilt der Server dem Client mit, welche Art von Daten er sendet. Die Abkürzungen der Datentypen (MIME-Types) finden Sie hier.
Set-Cookie: Der Server bittet den Client, ein Cookie zu setzen und mit jedem nachfolgenden Request mitzusenden. Mit dem expires-Attribut kann er die Lebensdauer des Cookies einschränken. Mehr zu Cookie siehe unten.

Aufgabe 1: Developer Tools nutzen

Jeder Browser hat sogenannte Devloper Tools integriert, die es Website-Entwicklern ermöglichen, das Document Object Model einer Website zu analysieren und Einblick in die Kommunikation des Browsers zu nehmen.

Öffnen Sie Ihren Browser und gehen Sie auf eine beliebige Webseite.
Drücken Sie die F12-Taste. Es öffnet sich ein zweites Fenster mit den Developer-Tools des Browsers.
Öffnen Sie dort den Reiter "Netzwerk".
Drücken Sie die F5-Taste, damit der Browser die Webseite erneut lädt. Sie sehen im Netzwerk-Reiter eine Auflistung aller HTTP-Requests, die zum Laden der Webseite nötig waren.

a) Wozu sind all die Requests nötig? Sie haben doch nur eine einzige Webseite geladen!
b) Klicken Sie auf einen Request. Der Browser zeigt Ihnen auf der rechten Seite die Details des Requests und des Response an. Wo sind die Request/Response-Parameter zu sehen? Interpretieren Sie sie mithilfe der obigen Beschreibung! Welche zusätzlichen Parameter finden Sie?

Cookies

Zustandslose (stateless) vs. zustandsbehaftete (stateful) Protokolle
Bei zustandsbehafteten (stateful) Protokollen verwalten die Kommunikationspartner während der Kommunikation einen Zustand, bei zustandslosen (stateless) Protokollen nicht.

Beispiele:

IP ist zustandslos: Jedes IP-Paket wird unabhängig von allen anderen Paketen versandt und auch empfangen. Vor dem Empfang eines IP-Pakets weiß die IP-Schicht des Empfängerrs nicht, dass es kommen wird und nach dem Empfang weiß sie nicht, ob noch weitere kommen werden.
TCP ist zustandsbehaftet: Die TCP-Schicht hat die Aufgabe, sicherzustellen, dass alle Pakete, die den Empfänger nicht erreichen, nochmals versandt werden. Dazu müssen Sender und Empfänger speichern, welcher Teil der Daten bereits versandt/empfangen wurde.
HTTP ist zustandslos: Der Client sendet einen HTTP-Request, der Server antwortet mit einer HTTP-Response. Danach "vergisst" der Server den Client wieder.

Problem:
HTTP ist zustandslos, viele Webseiten sind es aber nicht. Stellen Sie sich vor, sie kaufen in einem Online-Shop ein. Auf der Startseite geben Sie Ihren Benutzernamen und Ihr Passwort ein, dann klicken Sie auf "OK". Der Browser sendet die Daten jetzt per HTTP-Request an den Server, der liefert prüft ihre Zugangsdaten mithilfe Ihres Kundendatensatzes in seiner Datenbank und liefert eine Begrüßungsseite zurück ("Hallo Silvia, …"). Da HTTP zustandslos ist, bleibt die Verbindung danach nicht erhalten. Beim nächsten Request an den Server (Sie klicken vielleicht auf ein Item, um es in den Einkaufskorb zu legen…) weiß dieser nicht mehr, dass der Request von Ihnen stammt.

Kurze Frage dazwischen: Der Client könnte doch bei jedem Request den Benutzernamen mitschicken, dann wüsste der Server immer, dass Sie es sind … ?

Das HTTP-Protokoll sah anfangs keine Möglichkeit vor, mithilfe der der Server feststellen kann, dass der zweite Request (Item in den Einkaufskorb legen) vom selben User stammt wie der erste (Login).

Lösung: Cookies
Die Cookie Specification (RFC 2109) sieht vor, dass der Webserver im HTTP Response-Header mithilfe des Parameters Set-Cookie beliebige Schlüssel-Wert-Paare (key value pairs) mitliefern kann. Der Browser speichert diese und zeigt sie jedesmal dann, wenn ein Request an dieselbe Domain versandt wird, dem Server wieder vor. In der Praxis sieht das so aus:

Praktisches Beispiel: Session-Cookies

Cookies zu Marketing- und Werbezwecken (third party cookies)

Das Geschäftsmodell von Firmen wie Google und Facebook beseht darin, Werbung zu vermarkten (online marketing). Dabei können sie für Werbebanner und Links in Suchergebnislisten umso mehr Gebühren verlangen, je besser die Nutzer, die die Werbung zu sehen bekommen, zum beworbenen Produkt/Service passen.

Aufgabe 2: Werbung für ein Klassik-Konzert
Eine Eventagentur organisiert ein Konzert der Münchner Philharmoniker im Stadttheater Ingolstadt. Gespielt wird die 9. Symphonie von Beethoven. Um das Konzert publik zu machen soll auch Onlinewerbung geschaltet werden. Die Agentur beauftragt beispielsweise Facebook mit dem Schalten von Werbeeinblendungen in Timelines und Google mit dem Einblenden des Links zu Ihrer Homepage in Suchergebnislisten. Je Werbeeinblendung/Klick auf eine Suchergebnis muss die Agentur einen bestimmten Betrag (i.d.R. mehrere Cent bis hin zu einstelligen Euro-Beträgen) je Klick auf eine Werbung bzw. auf ein Suchergebnis zahlen. Damit dieses Geld nicht umsonst investiert ist (was nutzt es der Agentur, wenn ein Nutzer in Indonesien ihre Werbung zu sehen bekommt) kann sie bei Beauftragung der Werbung einschränken, dass diese nur für bestimmte Nutzergruppen angezeigt wird:

Wohnort im Umkreis von 150 km um Ingolstadt
Alter: 40 - 70 Jahre
Bruttoeinkommen: > 50 000 €/Jahr
Interesse an klassischer Musik

Versuchen Sie durch Recherche/Überlegung folgende Fragen zu beantworten:

a) Beim Klick auf die Werbung fürs Konzert soll der Browser die Homepage der Konzertagentur öffnen. Wie erfahren Google/Facebook von diesem Klick, so dass sie ihn abrechnen können?
b) Wie können Firmen wie Facebook/Google sicherstellen, dass die Werbeeinblendungen/Links in Suchergebnissen nur (oder zumindest überwiegend) bei der oben beschriebenen Nutzergruppe erscheinen?

Öffnet ein User eine Webseite (z.B. shoes-for-cats.com), auf der sich ein Like-Button von Facebook, eine von Google geschaltete Werbeanzeige o.ä. befindet, so sendet der Browser einen Request an Facebook/Google/…, um die Grafik zu laden. Dieser Request könnte beispielsweise so aussehen:

GET /likebutton.png HTTP/1.1
Host: www.facebook.com
User-Agent: Mozilla/4.0 (Windows NT)
Referer: shoes-for-cats.com/lightblue/cotton.html
Origin: shoes-for-cats.com
Cookie: user=Kodfk4988724lkj

Durch die Request-Header Referer (mit Pfad) und Origin (ohne Pfad) erfährt Facebook, auf welcher Seite der Like-Button steht. Wird eine Werbegrafik angefordert, so bekommt der Ad-Seller i.d.R. auch noch eine id als Parameter mitgeliefert die er vorher vertraglich mit dem Betreiber von www.shoes-for-cats.com vereinbart hat. Auch aus dieser kann er zweifelsfrei die Seite ermitteln, auf der der Nutzer gerade surft. Der Request-Header für die Werbung sieht dann etwa so aus:

GET /ad.png?id=23Jlk34jia HTTP/1.1
Host: www.googleads.com
Cookie: user=Kodfk4988724lkj
...

Sie werden sich wundern, wieso der Browser den Requests ein Cookie beifügt. Genaugenommen tut er dies nur, wenn der User

in letzter Zeit schon mal auf einer Seite gesurft hat, auf der Werbung von Google/Facebook zu sehen war oder
ein Google-Konto/Facebook-Konto besitzt und das Cookie beim Besuch von GMail, Facebook, dem Google-Kalender, … gesetzt wurde.

Beim Ausliefern der oben angeforderten Bilder jedenfalls versäumen es Google/Facebook nicht, ein Cookie zu setzen:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Content-Length: 1745
Content-Type: image/x-png
Set-Cookie: user=Kodfk4988724lkj; Expires=2025-01-20 00:00 GMT

Mithilfe solcher Cookies ist es großen Werbenetzwerken (es gibt nicht nur Google und Facebook…) möglich, das Surfverhalten von Nutzer/innen über viele Seiten und lange Zeiträume hinweg nachzuverfolgen. Sie werden daher als tracking cookies bezeichnet. Da der Host, der das Cookie setzt (z.B. googleads.com, facebook.com, …) von dem Host abweicht, der die aktuell besuchte Seite ausgeliefert hat (shoes-for-cats.com), heißen diese Cookie aus technischer Sicht third party cookies.

Aufgabe 3: Cookies aus Datenschutzsicht

Lesen Sie diesen Artikel des Mozilla Developer Network und beantworten Sie damit folgende Fragen:

a) Welche Arten von Cookies sind aus Datenschutzgründen bedenklich? Warum?
b) Was können Sie als Nutzer/in tun, um sich zu schützen?
c) Wie agieren die aktuellen Browserhersteller (Mozilla/Apple/Google/Microsoft) ins Sachen third party cookies? Welche Interessen verfolgen sie jeweils?

Caching

Liefert ein Server eine Ressource (z.B. eine HTML-Datei, eine Grafikdatei, …) aus, so kann der Client sie auf seiner SSD zwischenspeichern. Falls der User dieselbe Webseite erneut besucht und der Browser die Ressource erneut braucht, kann er dann einfach die zwischengespeicherte Version von der SSD verwenden. Diesen Vorgang nennt man caching. Das beschleunigt nicht nur den Ladevorgang der Webseite (das Laden von der SSD geht viel schneller als das Holen vom Server), sondern ist auch umweltschonend, da jeder HTTP-Request/Response Energie verbraucht.

Aber was, wenn der Client ein Bild "affe.jpg" in seinem Cache hat, das älter ist als die aktuelle Version auf dem Webserver?
Zu diesem Zweck kann der Webserver dem Client beim Ausliefern von Ressourcen im Response-Header signalisieren, wie lange er sie höchstens cachen darf. So bedeutet der Response-Header

Cache-Control: max-age=604800

dass die entsprechende Ressource maximal 604800 Sekunden im Cache zwischengespeichert werden sollte.

Weiterentwicklungen

HTTP/2

Die neue Protokollversion HTTP/2 findet Stand 2024 langsam immer mehr Verwendung in Browsern und Webservern. Sie bietet folgende Performanceverbesserungen gegenüber HTTP/1.1:

Auch Header können komprimiert werden.
Fordert der Client eine Webseite an (z.B. http://www.csg-in.de/index.php) und weiß der Server, dass die Seite bestimmte Ressourcen (Bilder, …) benötigt, so kann er sie dem Client mit dem Response gleich mitschicken ohne dass dieser sie erst extra anfordern muss.