Get to know MDN better
Dieser Inhalt wurde automatisch aus dem Englischen übersetzt, und kann Fehler enthalten. Erfahre mehr über dieses Experiment.
HTTP (HyperText Transfer Protocol) ist das zugrundeliegende Protokoll des World Wide Web. Entwickelt von Tim Berners-Lee und seinem Team zwischen 1989-1991, hat HTTP viele Veränderungen durchlaufen, die seine Einfachheit bewahrt und dennoch seine Flexibilität geformt haben. Lesen Sie weiter, um zu erfahren, wie HTTP sich von einem Protokoll, das zum Austausch von Dateien in einer semi-vertrauten Laborumgebung entwickelt wurde, zu einem modernen Internet-Labyrinth entwickelt hat, das hochauflösende Bilder und Videos in 3D transportiert.
1989, während seiner Arbeit am CERN, schrieb Tim Berners-Lee einen Vorschlag, ein Hypertext-System über das Internet zu bauen. Ursprünglich Mesh genannt, wurde es während seiner Implementierung 1990 in World Wide Web umbenannt. Es wurde über die bestehenden TCP- und IP-Protokolle aufgebaut und bestand aus vier Grundbausteinen:
Diese vier Grundbausteine waren Ende 1990 abgeschlossen, und die ersten Server liefen bereits Anfang 1991 außerhalb von CERN. Am 6. August 1991 veröffentlichte Tim Berners-Lee einen Beitrag in der öffentlichen Newsgroup alt.hypertext. Dies wird heute als offizieller Start des World Wide Web als öffentliches Projekt angesehen.
Das in diesen frühen Phasen genutzte HTTP-Protokoll war sehr einfach. Es wurde später HTTP/0.9 genannt und wird manchmal als das Ein-Zeilen-Protokoll bezeichnet.
Die Anfangsversion von HTTP hatte keine Versionsnummer; sie wurde später 0.9 genannt, um sie von späteren Versionen zu unterscheiden. HTTP/0.9 war extrem einfach: Anfragen bestanden aus einer einzigen Zeile und begannen mit der einzigen möglichen Methode GET, gefolgt von dem Pfad zur Ressource. Die vollständige URL wurde nicht einbezogen, da das Protokoll, der Server und der Port nicht notwendig waren, sobald die Verbindung zum Server hergestellt war.
Auch die Antwort war äußerst einfach: Sie bestand nur aus der Datei selbst.
Im Gegensatz zu späteren Entwicklungen gab es keine HTTP-Header. Dies bedeutete, dass nur HTML-Dateien übertragen werden konnten. Es gab keine Status- oder Fehlercodes. Bei einem Problem wurde eine spezifische HTML-Datei generiert, die eine Beschreibung des Problems zur menschlichen Betrachtung enthielt.
HTTP/0.9 war sehr limitiert, aber Browser und Server machten es schnell vielseitiger:
Zu diesem Zeitpunkt sahen eine typische Anfrage und Antwort so aus:
Es folgte eine zweite Verbindung und eine Anfrage, um das Bild zu holen (mit der entsprechenden Antwort):
Zwischen 1991-1995 wurden diese mit einem "Versuch-und-sehen"-Ansatz eingeführt. Ein Server und ein Browser fügten eine Funktion hinzu und sahen, ob sie an Fahrt gewann. Interoperabilitätsprobleme waren häufig. Um diese Probleme zu lösen, wurde im November 1996 ein informelles Dokument veröffentlicht, das die gängigen Praktiken beschrieb. Dies war als RFC 1945 bekannt und definierte HTTP/1.0.
In der Zwischenzeit war eine ordnungsgemäße Standardisierung im Gange. Dies geschah parallel zu den vielfältigen Implementierungen von HTTP/1.0. Die erste standardisierte Version von HTTP, HTTP/1.1, wurde Anfang 1997 veröffentlicht, nur wenige Monate nach HTTP/1.0.
HTTP/1.1 klärte Unklarheiten und führte zahlreiche Verbesserungen ein:
Das folgende Beispiel veranschaulicht eine typische Abfolge von HTTP/1.1-Anfragen, die über eine einzelne persistente TCP-Verbindung gesendet werden, und zeigt, wie Clients Verbindungen wiederverwenden können, um Ressourcen effizienter zu laden. Die erste Anfrage ruft eine Webseite ab, und der Server antwortet mit einem HTML-Dokument. Der Client sendet dann weitere Anfragen nacheinander, sobald er CSS- und JavaScript-Ressourcen im HTML-Dokument antrifft:
Das Einrichten einer TCP-Verbindung ist ein teurer Teil des Client-Server-Austauschs, und TCP Slow Start bedeutet, dass längerlebige Verbindungen schneller sind als neu erstellte. HTTP/1.1 ermöglicht die Wiederverwendung einer TCP-Verbindung für mehrere Anfragen und Antworten, sodass Sie vermeiden, für jede Anfrage eine neue Verbindung erstellen zu müssen. Allerdings mussten Clients immer noch warten, bis jede Ressource heruntergeladen war, bevor sie die nächste anfragen konnten (Head-of-line Blocking). Um dies zu umgehen, erlauben die meisten Browser bis zu sechs TCP-Verbindungen pro Website (oder Origin). Mit sechs parallelen Verbindungen können Browser mehrere Ressourcen gleichzeitig abrufen, was beim HTTP/1.1-Modell erhebliche Leistungsverbesserungen hinzugefügt hat.
HTTP/1.1 wurde erstmals im Januar 1997 als RFC 2068 veröffentlicht.
Die Erweiterbarkeit von HTTP machte es einfach, neue Header und Methoden zu erstellen. Obwohl das HTTP/1.1-Protokoll über zwei Revisionen verfeinert wurde, RFC 2616 veröffentlicht im Juni 1999 und RFC 7230-RFC 7235 veröffentlicht im Juni 2014, vor der Veröffentlichung von HTTP/2, war es mehr als 15 Jahre lang extrem stabil. HTTP/1.1 wurde 2022 erneut mit RFC 9110 aktualisiert. Nicht nur HTTP/1.1 wurde aktualisiert, sondern das gesamte HTTP wurde überarbeitet und ist jetzt in folgende Dokumente aufgeteilt: Semantik (RFC 9110), Caching (RFC 9111), anwendbar auf alle HTTP-Versionen, und HTTP/1.1 (RFC 9112), HTTP/2 (RFC 9113) und HTTP/3 (RFC 9114). Zudem hat die Spezifikation schließlich den Status eines Internet-Standards (STD 97) erreicht, während sie zuvor immer ein vorgeschlagener/Entwurfsstandard war.
Die größte Änderung an HTTP wurde Ende 1994 vorgenommen. Anstatt HTTP über einen einfachen TCP/IP-Stack zu senden, schuf das Computer-Dienstleistungsunternehmen Netscape Communications eine zusätzliche verschlüsselte Übertragungsebene darüber: SSL. SSL 1.0 wurde nie der Öffentlichkeit zugänglich gemacht, aber SSL 2.0 und sein Nachfolger SSL 3.0 ermöglichten die Erstellung von E-Commerce-Websites. Dazu verschlüsselten und garantierten sie die Authentizität der zwischen Server und Client ausgetauschten Nachrichten. SSL wurde schließlich standardisiert und zu TLS.
Im selben Zeitraum wurde deutlich, dass eine verschlüsselte Transportschicht notwendig war. Das Web war nicht mehr ein hauptsächlich akademisches Netzwerk, sondern wurde zu einem Dschungel, in dem Werbetreibende, Einzelpersonen und Kriminelle um so viele private Daten wie möglich konkurrierten. Da die über HTTP gebauten Anwendungen leistungsfähiger wurden und Zugriff auf private Informationen wie Adressbücher, E-Mail-Adressen und den Standort der Nutzer benötigten, wurde TLS auch außerhalb des E-Commerce-Szenarios notwendig.
Tim Berners-Lee hatte HTTP ursprünglich nicht als Nur-Lese-Medium vorgesehen. Er wollte ein Web schaffen, in dem Menschen Dokumente aus der Ferne hinzufügen und verschieben könnten – eine Art verteiltes Dateisystem. Um 1996 wurde HTTP erweitert, um das Authoring zu ermöglichen, und ein Standard namens WebDAV wurde geschaffen. Es entwickelte sich zu spezifischen Anwendungen wie CardDAV zur Verwaltung von Adressbucheinträgen und CalDAV zur Kalenderverwaltung. Aber alle diese *DAV-Erweiterungen hatten einen Nachteil: Sie waren nur nutzbar, wenn sie von den Servern implementiert wurden.
Im Jahr 2000 wurde ein neues Muster zur Nutzung von HTTP entwickelt: Representational State Transfer (oder REST). Die API basierte nicht auf neuen HTTP-Methoden, sondern auf dem Zugriff auf spezifische URIs mit grundlegenden HTTP/1.1-Methoden. Dies ermöglichte es jeder Webanwendung, eine API zum Abrufen und Ändern ihrer Daten bereitzustellen, ohne die Browser oder Server aktualisieren zu müssen. Alle notwendigen Informationen waren in den Dateien eingebettet, die die Websites über standardmäßige HTTP/1.1 bereitstellten. Der Nachteil des REST-Modells war, dass jede Website ihre eigene nicht-standardisierte RESTful API definierte und die volle Kontrolle darüber hatte. Dies unterschied sich von den *DAV-Erweiterungen, bei denen Clients und Server interoperabel waren. RESTful APIs wurden in den 2010er Jahren sehr verbreitet.
Seit 2005 sind mehr APIs für Webseiten verfügbar geworden. Mehrere dieser APIs schaffen Erweiterungen des HTTP-Protokolls für spezifische Zwecke:
HTTP ist unabhängig vom Web-Sicherheitsmodell, bekannt als die Same-Origin-Policy. Tatsächlich wurde das aktuelle Web-Sicherheitsmodell nach der Erstellung von HTTP entwickelt! Im Laufe der Jahre erwies es sich als nützlich, einige Beschränkungen dieser Richtlinie unter bestimmten Bedingungen zu lockern. Der Server übertrug die Information, wie viel und wann solche Beschränkungen gelockert werden sollten, an den Client mithilfe eines neuen Satzes von HTTP-Headern. Diese wurden in Spezifikationen wie dem Cross-Origin Resource Sharing (CORS) und der Content Security Policy (CSP) definiert.
Zusätzlich zu diesen großen Erweiterungen wurden viele andere Header hinzugefügt, manchmal nur experimentell. Bemerkenswerte Header sind der Do Not Track (DNT) Header zur Kontrolle der Privatsphäre, X-Frame-Options, und Upgrade-Insecure-Requests, aber es existieren viele weitere.
Über die Jahre wurden Webseiten immer komplexer. Einige von ihnen waren sogar Anwendungen für sich. Mehr visuelle Medien wurden angezeigt und das Volumen und die Größe der Scripte, die Interaktivität hinzufügten, stiegen ebenfalls. Viel mehr Daten wurden über deutlich mehr HTTP-Anfragen übertragen, was mehr Komplexität und Overhead für HTTP/1.1-Verbindungen schuf. Um dem Rechnung zu tragen, implementierte Google in den frühen 2010er Jahren ein experimentelles Protokoll namens SPDY. Auf diesen alternativen Weg des Datenaustauschs zwischen Client und Server konzentrierten sich Entwickler, die an Browsern und Servern arbeiteten. SPDY definierte eine Erhöhung der Reaktionsfähigkeit und löste das Problem der doppelten Datenübertragung und diente als Grundlage für das HTTP/2-Protokoll.
Das HTTP/2-Protokoll unterscheidet sich in einigen Punkten von HTTP/1.1:
Offiziell standardisiert im Mai 2015, erreichte die Nutzung von HTTP/2 im Januar 2022 mit 46,9 % aller Websites ihren Höhepunkt (siehe diese Statistiken). Hochfrequentierte Websites zeigten die schnellste Verbreitung, um den Datenübertragungs-Overhead und die damit verbundenen Budgets zu sparen.
Diese schnelle Übernahme war wahrscheinlich darauf zurückzuführen, dass HTTP/2 keine Änderungen an Websites und Anwendungen erforderte. Um es zu verwenden, war nur ein aktueller Server, der mit einem aktuellen Browser kommunizierte, notwendig. Nur eine begrenzte Gruppe musste die Einführung auslösen und da ältere Versionen von Browsern und Servern erneuert wurden, erhöhte sich die Nutzung auf natürliche Weise, ohne signifikante Arbeit für Webentwickler.
Die Erweiterbarkeit von HTTP wird weiterhin genutzt, um neue Funktionen hinzuzufügen. Insbesondere können wir neue Erweiterungen des HTTP-Protokolls erwähnen, die 2016 aufgetaucht sind:
Die nächste Hauptversion von HTTP, HTTP/3, hat die gleichen Semantiken wie frühere Versionen von HTTP, verwendet aber QUIC anstelle von TCP für den Transport. Bis Oktober 2022 nutzten 26 % aller Websites HTTP/3.
QUIC ist darauf ausgelegt, eine viel niedrigere Latenz für HTTP-Verbindungen bereitzustellen. Wie HTTP/2 ist es ein multiplexed Protokoll, aber HTTP/2 läuft über eine einzelne TCP-Verbindung, sodass Paketverlust-Erkennung und -Übertragung auf der TCP-Schicht alle Streams blockieren kann. QUIC betreibt mehrere Streams über UDP und implementiert Paketverlust-Erkennung und -Übertragung unabhängig für jeden Stream, sodass, wenn ein Fehler auftritt, nur der Stream mit Daten in diesem Paket blockiert wird.
Definiert in RFC 9114, wird HTTP/3 von den meisten großen Browsern unterstützt, einschließlich Chromium (und seine Varianten wie Chrome und Edge) und Firefox.
Der Bauplan für ein besseres Internet.
Besuche die gemeinnützige Muttergesellschaft der Mozilla Corporation, die Mozilla Foundation.
Teile dieses Inhalts sind ©1998–2026 von einzelnen mozilla.org-Mitwirkenden. Inhalte sind verfügbar unter einer Creative-Commons-Lizenz.