Hypertext Transfer Protocol

Hypertext Transfer Protocol
HTTP logo.svg
Internationaler Standard
  • RFC 1945 Http/1.0 (1996)
  • RFC 2068 Http/1.1 (1997)
  • RFC 2616 Http/1.1 (1999)
  • RFC 7230 HTTP/1.1: Nachrichtensyntax und Routing (2014)
  • RFC 7231 HTTP/1.1: Semantik und Inhalt (2014)
  • RFC 7232 HTTP/1.1: Bedingte Anfragen (2014)
  • RFC 7233 HTTP/1.1: Bereichsanfragen (2014)
  • RFC 7234 HTTP/1.1: Caching (2014)
  • RFC 7235 HTTP/1.1: Authentifizierung (2014)
  • RFC 7540 Http/2 (2015)
  • RFC 7541 HTTP/2: HPACK -Header -Komprimierung (2015)
  • RFC 8164 HTTP/2: Opportunistische Sicherheit für http/2 (2017)
  • RFC 8336 HTTP/2: Der Ursprung HTTP/2 -Rahmen (2018)
  • RFC 8441 HTTP/2: Bootstrapping WebSockets mit http/2 (2018)
  • RFC 8740 HTTP/2: Verwenden Sie TLS 1.3 mit HTTP/2 (2020)
  • RFC 9114 Http/3
Entwickelt von anfänglich Cern; Ietf, W3c
Eingeführt 1991; Vor 31 Jahren
Webseite https://httpwg.org/specs/

Das Hypertext Transfer Protocol (Http) ist ein Anwendungsschicht Protokoll in der Internet -Protokollsuite Modell für verteilte, kollaborative, Hypermedia Informationssysteme.[1] HTTP ist die Grundlage für die Datenkommunikation für die Weltweites Netz, wo Hypertext Dokumente enthalten Hyperlinks zu anderen Ressourcen, auf die der Benutzer leicht zugreifen kann, beispielsweise nach a Maus Klicken Sie auf oder durch Tippen auf den Bildschirm in einem Webbrowser.

Die Entwicklung von HTTP wurde von initiiert von Tim Berners-Lee bei Cern 1989 und zusammengefasst in einem einfachen Dokument, das das Verhalten eines Clients und eines Servers unter Verwendung der ersten HTTP -Protokollversion, die 0.9 genannt wurde, beschreibt.[2]

Http/3 ist die neueste Version des Protokolls, die 2022 veröffentlicht wurde; Bereits von 25% der Websites vor der Standardisierung verwendet. HTTP/3 hat eine geringere Latenz für reale Webseiten, sofern auf dem Server aktiv häufig nur aktiviert).[3] Dies liegt zum Teil daran, dass der TCP (von TCP/IP) nicht mehr wie in den älteren Maßstäben verwendet wird.

Diese erste Version des HTTP -Protokolls entwickelte sich bald zu einer ausgearbeiteten Version, bei der der erste Entwurf für eine weitaus zukünftige Version 1.0 war.[4]

Entwicklung eines frühen HTTP Anfragen nach Kommentaren (RFCS) begann einige Jahre später und es war eine koordinierte Anstrengung der Internettechnik-Arbeitsgruppe (Ietf) und die World Wide Web Konsortium (W3C), mit Arbeiten später zum IETF.

HTTP/1 wurde 1996 abgeschlossen und vollständig dokumentiert (als Version 1.0).[5] Es entwickelte sich 1997 (als Version 1.1) und dann wurden seine Spezifikationen 1999 und 2014 aktualisiert.[6]

Seine sichere Variante benannt Https wird von mehr als 79% der Websites verwendet.[7]

Http/2 ist ein effizientere Ausdruck der HTTP -Semantik "on the Wire" und wurde 2015 veröffentlicht. verwendet von mehr als 46% der Websites,[8] jetzt unterstützt von fast allen Webbrowsern (96% der Benutzer)[9] und große Webserver über Transportschichtsicherheit (TLS) mit einem Anwendungsschichtprotokollverhandlung (ALPN) Erweiterung[10] wo TLS 1.2 oder neuer ist erforderlich.[11][12]

Http/3 ist der Nachfolger von HTTP/2, das 2022 veröffentlicht wurde;[13] verwendet von 25% der Websites,[14] Es wird jetzt von vielen Webbrowsern (73% der Benutzer) unterstützt.[15] HTTP/3 verwendet Quic Anstatt von TCP Für das zugrunde liegende Transportprotokoll. Wie HTTP/2 veraltet es frühere Hauptversionen des Protokolls nicht. Die Unterstützung für HTTP/3 wurde hinzugefügt Wolkenflare und Google Chrome Erste,[16][17] und ist auch aktiviert in Feuerfuchs.[18]

Technische Übersicht

URL Beginnend mit dem HTTP -Schema und dem Www Domainnamenbezeichnung

Http Funktionen wie a Request -Reaktion Protokoll in der Client -Server -Modell. EIN Webbrowserkann zum Beispiel das sein Klient während a Prozess, genannt Webserverauf einem Computer laufen Hosting ein oder mehr Websites vielleicht der Server. Der Client gibt einen HTTP ein Anfrage Nachricht an den Server. Der Server, der bietet Ressourcen wie zum Beispiel Html Dateien und andere Inhalte oder andere Funktionen im Namen des Clients ergeben eine Rückgabe a Antwort Nachricht an den Client. Die Antwort enthält Abschlussstatusinformationen zur Anfrage und kann auch angeforderte Inhalte in seiner Nachrichtenbehörde enthalten.

Ein Webbrowser ist ein Beispiel für a User-Agent (Ua). Andere Arten von Benutzeragenten enthalten die Indizierungssoftware, die von Suchanbietern verwendet wird (Webcrawler), Sprachbrowser, Mobile Apps, und andere Software Das greift auf Webinhalte auf, konsumiert oder zeigt.

Http Es wurde entwickelt, um Zwischennetzelemente zu ermöglichen, um die Kommunikation zwischen Kunden und Servern zu verbessern oder zu ermöglichen. Hochverkehrswebsites profitieren häufig von Webcache Server, die Inhalte im Namen von liefern Upstream -Server Reaktionszeit zu verbessern. Webbrowser Cache hat zuvor auf Webressourcen zugegriffen und sie nach Möglichkeit wiederverwenden, um den Netzwerkverkehr zu reduzieren. Http Proxy -Server bei privates Netzwerk Grenzen können die Kommunikation für Kunden ohne weltweit routbare Adresse ermöglichen, indem Nachrichten mit externen Servern weitergeleitet werden.

Um mittelschwere HTTP -Knoten (Proxy -Server, Web -Caches usw.) zu ermöglichen, um ihre Funktionen zu erfüllen, einige der HTTP -Header (gefunden in HTTP -Anforderungen/Antworten) werden verwaltet Hop-für-Hop Während andere HTTP -Header verwaltet werden Ende zu Ende (Nur vom Quellclient und vom Zielwebserver verwaltet).

Http ist ein Anwendungsschicht Protokoll, das im Rahmen des Rahmens entworfen wurde Internet -Protokollsuite. Seine Definition setzt eine zugrunde liegende und zuverlässige voraus Transportschicht Protokoll,[19] daher Transmissionskontrollprotokoll (TCP) wird üblicherweise verwendet. HTTP kann jedoch so angepasst werden, dass unzuverlässige Protokolle wie die verwendet werden User Datagram Protocol (UDP) zum Beispiel in Httpu und Einfaches Service Discovery Protocol (SSDP).

HTTP -Ressourcen werden identifiziert und im Netzwerk befinden Uniforme Ressourcenlokatoren (URLs), verwenden die Einheitliche Ressourcenidentifikatoren (URI) Schemata http und https. Wie definiert in RFC 3986, URIs sind codiert als Hyperlinks in Html Dokumente, um miteinander verbunden zu bilden Hypertext Unterlagen.

Im Http/1.0 ein separates Verbindung Auf demselben Server wird für jede Ressourcenanforderung durchgeführt.[20]

Im Http/1.1 Stattdessen kann eine TCP -Verbindung wiederverwendet werden, um mehrere Ressourcenanforderungen zu erstellen (d. H. Von HTML -Seiten, Frames, Bildern, Skripte, Stylesheets, etc.).[21][22]

Http/1.1 Kommunikation erlebt daher weniger Latenz Da die Einrichtung von TCP -Verbindungen einen erheblichen Overhead darstellt, insbesondere unter hohen Verkehrsbedingungen.[23]

Http/2 ist eine Überarbeitung früherer HTTP/1.1, um dasselbe Client -Server -Modell und dieselben Protokollmethoden aufrechtzuerhalten, jedoch mit diesen Unterschieden in der Reihenfolge:

  • Verwendung einer komprimierten binären Darstellung von Metadaten (HTTP -Headers) anstelle eines Textes, damit die Header viel weniger Platz benötigen;
  • zu verwenden, um ein einzelnes TCP/ zu verwenden/IP (normalerweise verschlüsselt) Verbindung pro Zugriffsserverdomäne anstelle von 2 bis 8 TCP/IP -Verbindungen;
  • Um einen oder mehrere bidirektionale Streams pro TCP/IP -Verbindung zu verwenden, in der HTTP -Anforderungen und Antworten in kleinen Paketen abgebaut und übertragen werden, um das Problem des HOLB fast zu lösen (Zeilenblockierkopf). [Anmerkung 1]
  • Um eine Push -Funktion hinzuzufügen, damit die Serveranwendung Daten an Clients senden kann, wann immer neue Daten verfügbar sind (ohne Clients dazu zu zwingen, regelmäßig neue Daten an Server anzufordern Umfragen Methoden).[24]

Http/2 Die Kommunikation erlebt daher viel weniger Latenz und in den meisten Fällen noch mehr Geschwindigkeit als HTTP/1.1 -Kommunikation.

Http/3 ist eine Überarbeitung früherer HTTP/2, um zu verwenden Quic + UDP -Transportprotokolle anstelle von TCP/IP -Verbindungen auch, um die Durchschnittsgeschwindigkeit der Kommunikation geringfügig zu verbessern und das gelegentliche (sehr seltene) Problem der TCP/IP -Verbindung zu vermeiden Stauung Dies kann den Datenfluss aller Streams vorübergehend blockieren oder verlangsamen (eine andere Form von "Zeilenblockierkopf").

Geschichte

Tim Berners-Lee

Der Begriff Hypertext wurde von geprägt von Ted Nelson im Jahr 1965 in der Xanadu -Projekt, was wiederum von inspiriert wurde von Vannevar Bush's 1930er Vision des mikrofilmbasierten Informationsabrufs und -managements "Memex"System beschrieben in seinem Aufsatz von 1945"As We May Think". Tim Berners-Lee und sein Team bei Cern wird der Erfindung des ursprünglichen HTTP zusammen mit HTML und der zugehörigen Technologie für a zugeschrieben Webserver und ein Kunde Benutzeroberfläche genannt Webbrowser. Berners-Lee entworfen HTTP, um bei der Übernahme seiner anderen Idee zu helfen: das "weltweitwideweb" -Projekt, das erstmals 1989 vorgeschlagen wurde, das heute als The bekannt ist Weltweites Netz.

Der erste Webserver ging 1990 live.[25][26] Das verwendete Protokoll hatte nur eine Methode, nämlich GET, die eine Seite von einem Server anfordern würde.[27] Die Antwort vom Server war immer eine HTML -Seite.[2]

Zusammenfassung der HTTP -Meilensteinversionen

Ausführung Jahr eingeführt Aktueller Status
HTTP/0,9 1991 Obsolet
Http/1.0 1996 Obsolet
Http/1.1 1997 Standard
Http/2 2015 Standard
Http/3 2022 Standard
HTTP/0,9
1991 wurde die erste dokumentierte offizielle Version von HTTP als einfaches Dokument geschrieben, weniger als 700 Wörter lang, und diese Version wurde als HTTP/0,9 bezeichnet. HTTP/0.9 unterstützt nur Methode, sodass Clients nur HTML -Dokumente vom Server abrufen, jedoch keine anderen Dateiformate oder Informationen zum Hochladen von Informationen unterstützen.[2]
HTTP/1.0-Draft
Seit 1992 wurde ein neues Dokument geschrieben, um die Entwicklung des grundlegenden Protokolls für seine nächste Vollversion anzugeben. Es unterstützte sowohl die einfache Anforderungsmethode der 0,9 -Version als auch die vollständige GET -Anforderung, die die Client HTTP -Version enthielt. Dies war der erste der vielen inoffiziellen HTTP/1.0 -Entwürfe, die den endgültigen Arbeiten zu HTTP/1.0 vorausgingen.[4]
W3C HTTP -Arbeitsgruppe
Nachdem sie entschieden hatten, dass neue Funktionen des HTTP -Protokolls erforderlich waren und dass sie als offiziell vollständig dokumentiert werden mussten RFCsAnfang 1995 die HTTP -Arbeitsgruppe (HTTP WG, angeführt von Dave Raggett) wurde mit dem Ziel konstituiert, das Protokoll mit erweiterten Operationen, erweiterten Verhandlungen, reichhaltigerer Metakellinformationen zu standardisieren und zu erweitern, die mit einem Sicherheitsprotokoll verbunden sind, das durch Hinzufügen zusätzlicher Methoden und Hinzufügen zusätzlicher Methoden und effizienter wurde Headerfelder.[28][29]
Das HTTP WG plante, innerhalb 1995 neue Versionen des Protokolls als HTTP/1.0 und HTTP/1.1 zu überarbeiten und zu veröffentlichen. Aufgrund der vielen Überarbeitungen dauerte diese Zeitleiste jedoch viel mehr als ein Jahr.[30]
Das HTTP-WG plante auch, eine weitaus zukünftige Version von HTTP namens HTTP-NG (HTTP Next Generation) anzugeben, die alle verbleibenden Probleme früherer Versionen, im Zusammenhang mit Performances, Reaktionen mit geringer Latenz usw. gelöst hätte. Diese Arbeit begann jedoch nur mit einer Ein paar Jahre später und es wurde nie fertiggestellt.
Http/1.0
Im Mai 1996, RFC 1945 wurde als endgültige HTTP/1,0-Überarbeitung der in den vergangenen 4 Jahren als Vorstandard HTTP/1.0-Enttäuschung verwendet, die bereits von vielen Webbrowsern und Webservern verwendet wurde.
Anfang 1996 begannen Entwickler, inoffizielle Erweiterungen des HTTP/1.0-Protokolls (d. H. Keep-Alive-Verbindungen usw.) in ihre Produkte einzubeziehen, indem sie Entwürfe der bevorstehenden HTTP/1.1-Spezifikationen verwenden.[31]
Http/1.1
Seit Anfang 1996 haben große Webbrowser und Webserverentwickler auch neue Funktionen implementieren, die von Pre-Standard HTTP/1.1-Entwurfspezifikationen angegeben wurden. Die Übernahme der neuen Versionen von Browsern und Servern war schnell. Im März 1996 berichtete ein Web -Hosting -Unternehmen, dass über 40% der im Internet verwendeten Browser den neuen HTTP/1.1 -Header "Host" zur Aktivierung verwendeten Virtuelles Hosting. Das gleiche Web-Hosting-Unternehmen berichtete, dass bis Juni 1996 65% aller Browser, die auf ihre Server zugreifen, vor dem Standard-HTTP/1,1-konform waren.[32]
Im Januar 1997, RFC 2068 wurde offiziell als HTTP/1.1 -Spezifikationen freigelassen.
Im Juni 1999, RFC 2616 wurde veröffentlicht, um alle Verbesserungen und Updates basierend auf früheren (veralteten) HTTP/1.1 -Spezifikationen zu enthalten.
W3C HTTP-NG Arbeitsgruppe
Wiederaufentwicklung des alten Planens der früheren HTTP -Arbeitsgruppe von 1995, 1997 A. HTTP-NG Arbeitsgruppe wurde gegründet, um ein neues HTTP-Protokoll mit dem Namen HTTP-NG (HTTP New Generation) zu entwickeln. Einige Vorschläge / Entwürfe wurden für das neue Protokoll erstellt Multiplexing von HTTP -Transaktionen in einer einzelnen TCP/IP -Verbindung, 1999 stoppte die Gruppe ihre Aktivität an die technischen Probleme an IETF.[33]
IETF HTTP -Arbeitsgruppe wurde neu gestartet
Im Jahr 2007 das IETF HTTP -Arbeitsgruppe (HTTP WG Bis oder HTTPBIS) wurde zunächst neu gestartet, um frühere HTTP/1.1 -Spezifikationen zu überarbeiten und zu klären, und zweitens, um zukünftige HTTP/2 -Spezifikationen (HTTPBIS) zu schreiben und zu verfeinern.[34]

[35]

HTTP/1.1 endgültiges Update
Im Juni 2014 veröffentlichte die HTTP-Arbeitsgruppe eine aktualisierte sechsteilige HTTP/1.1-Spezifikation, die veraltet ist RFC 2616:
  • RFC 7230, HTTP/1.1: Nachrichtensyntax und Routing
  • RFC 7231, HTTP/1.1: Semantik und Inhalt
  • RFC 7232, HTTP/1.1: Bedingte Anfragen
  • RFC 7233, HTTP/1.1: Bereichsanfragen
  • RFC 7234, HTTP/1.1: Caching
  • RFC 7235, HTTP/1.1: Authentifizierung
SPDY: Ein inoffizielles HTTP -Protokoll, das von Google entwickelt wurde
In 2009, Google, ein privates Unternehmen, kündigte an, ein neues HTTP -Binärprotokoll namens entwickelt und getestet habe und getestet habe und getestet habe und getestet hatte Spdy. Das implizite Ziel war es, den Webverkehr erheblich zu beschleunigen (insbesondere zwischen zukünftigen Webbrowsern und seinen Servern).
SPDY war in vielen Tests in der Tat viel schneller als HTTP/1,1 und wurde schnell übernommen von von Chrom und dann von anderen großen Webbrowsern.[36]
Einige der Ideen zum Multiplexing-HTTP-Streams über eine einzelne TCP/IP-Verbindung wurden aus verschiedenen Quellen entnommen, einschließlich der Arbeit der W3C-HTTP-NG-Arbeitsgruppe.
Http/2
Im Januar bis März 2012 kündigte die HTTP Working Group (HTTPBIS) an, sich auf ein neues HTTP/2 -Protokoll zu konzentrieren (während die Überarbeitung von HTTP/1.1 -Spezifikationen beendet wurde), die möglicherweise für SPDY in Betrachtliche Ideen und Arbeiten erledigt werden.[37][38]
Nach ein paar Monaten darüber, was zu tun ist, um eine neue Version von HTTP zu entwickeln, wurde beschlossen, sie von SPDY abzuleiten.[39]
Im Mai 2015, Http/2 wurde veröffentlicht als RFC 7540 und schnell von allen Webbrowsern übernommen, die SPDY und langsamer von Webservern unterstützen.
HTTP/0,9 Abwertung
Im RFC 7230 Anhang-A, HTTP/0,9 wurde für Server veraltet, die die HTTP/1.1-Version (und höher) unterstützten:[40]

Da HTTP/0.9 keine Headerfelder in einer Anfrage unterstützt, gibt es keinen Mechanismus, um namenbasierte virtuelle Hosts zu unterstützen (Auswahl der Ressourcen durch Inspektion des Feldes des Host-Headers). Jeder Server, der Namensbasierte virtuelle Hosts implementiert, sollte die Unterstützung für HTTP/0.9 deaktivieren. Die meisten Anfragen, die anscheinend HTTP/0,9 sind, sind in der Tat schlecht konstruierte HTTP/1.x-Anforderungen, die durch einen Client verursacht werden, der das Anforderungs-Target nicht ordnungsgemäß codiert.

Seit 2016 haben viele Produktmanager und Entwickler von Benutzeragenten (Browsern usw.) und Webservern begonnen, die Unterstützung für das HTTP/0,9 -Protokoll allmählich abzubauen und abzulehnen, hauptsächlich aus den folgenden Gründen:[41]
  • Es ist so einfach, dass ein RFC -Dokument nie geschrieben wurde (es gibt nur das Originaldokument).[2]
  • Es gibt keine HTTP -Headers und es fehlen viele andere Funktionen, die heutzutage aus minimalen Sicherheitsgründen benötigt werden.
  • Es ist seit 1999 nicht weit verbreitet. 200000 (wegen HTTP/1.0 und HTTP/1.1) und wird üblicherweise nur von einer sehr alten Netzwerkhardware verwendet, d. H. Router, etc.

[Anmerkung 2]

Http/3
Im Jahr 2020, Http/3 Erste Entwürfe wurden veröffentlicht, und große Webbrowser und Webserver begannen, es zu übernehmen.
Am 6. Juni 2022 standardisierte IETF HTTP/3 als RFC 9114.[42]
Gesamtaktualisierungen und Refactoring
Im Juni 2022 wurde eine Charge von RFCs veröffentlicht, die viele der vorherigen Dokumente abzeichnete und einige kleinere Änderungen und ein Refactoring der Beschreibung der HTTP -Semantik in ein separates Dokument einführte.

HTTP -Datenaustausch

Http ist a staatenlos Protokoll auf Anwendungsebene und eine zuverlässige Netzwerktransportverbindung zum Austausch von Daten zwischen Client und Server.[43] In HTTP -Implementierungen, TCP/IP Verbindungen werden unter Verwendung von bekannter Verwendung verwendet Häfen (Typisch Port 80 Wenn die Verbindung unverschlüsselt ist oder Port 443, wenn die Verbindung verschlüsselt ist, siehe auch Liste der TCP- und UDP -Portnummern).[44][45] In HTTP/2 werden eine TCP/IP -Verbindung plus mehrere Protokollkanäle verwendet. In HTTP/3 das Anwendungstransportprotokoll Quic über UDP wird verwendet.

Anforderungs- und Antwortnachrichten über Verbindungen

Daten werden durch eine Folge von ausgetauscht Anfrage -Wirkungsmeldungen die von a ausgetauscht werden Sitzungsschicht Transportverbindung.[43] Ein HTTP -Client versucht zunächst, eine Verbindung zu einem Server herzustellen, der eine Verbindung herstellt (real oder virtuell). Ein HTTP -Server, der diesen Port zuhört, akzeptiert die Verbindung und wartet dann auf die Anforderungsnachricht eines Clients. Der Client sendet seine Anfrage an den Server. Nach Empfang der Anforderung sendet der Server eine HTTP -Antwortnachricht zurück (Header plus eine Körperschaft, wenn dies erforderlich ist). Der Körper dieser Nachricht ist in der Regel die angeforderte Ressource, obwohl auch eine Fehlermeldung oder andere Informationen zurückgegeben werden können. Der Client oder Server kann jederzeit (aus vielen Gründen) die Verbindung schließen. Das Schließen einer Verbindung wird normalerweise im Voraus mithilfe einer oder mehrerer HTTP -Header in der letzten Anforderung/Antwortnachricht an Server oder Client verwendet.[21]

Anhaltende Verbindungen

Hauptartikel: HTTP Persistente Verbindung

Im HTTP/0,9Die TCP/IP -Verbindung ist immer geschlossen, nachdem die Serverantwort gesendet wurde, sodass sie nie hartnäckig ist.

Im Http/1.0Wie in RFC 1945 angegeben, sollte die TCP/IP -Verbindung immer vom Server geschlossen werden, nachdem eine Antwort gesendet wurde. [Notiz 3]

Im Http/1.1 Ein Keep-Alive-Mechanismus wurde offiziell eingeführt, damit eine Verbindung für mehr als eine Anfrage/Antwort wiederverwendet werden konnte. Solche anhaltenden Verbindungen reduzieren die Anfrage Latenz wahrnehmbar, weil der Kunde das nicht neu verhandeln muss TCP 3-Wege-Handshake-Verbindung Nach der ersten Anfrage wurde gesendet. Ein weiterer positiver Nebeneffekt ist, dass die Verbindung im Allgemeinen mit der Zeit aufgrund von TCP schneller wird langsamer Start-Mechanismus.

Http/1.1 Auch hinzugefügt HTTP -Pipelining Um die Verzögerungszeit bei der Verwendung anhaltender Verbindungen weiter zu verkürzen, indem Kunden mehrere Anfragen senden, bevor sie auf jede Antwort warten. Diese Optimierung wurde nie als wirklich sicher angesehen, weil einige Webserver und viele Proxy -Server, speziell transparente Proxy -Server, die im Internet platziert sind / Intranets Zwischen Clients und Servern handelte es nicht ordnungsgemäß mit Pipelined -Anfragen (sie haben nur die erste Anfrage gestellt, die die anderen verwaltete, die Verbindung geschlossen, da sie nach der ersten Anfrage mehr Daten sahen oder einige Proxys sogar die Antworten außerhalb der Reihenfolge usw. zurückgegeben haben). Außerdem nur Kopf und einige Get -Anfragen (d. H. Auf realen Dateianfragen beschränkt und so mit URLs ohne Abfragezeichenfolge als Befehl usw.) könnte in a pipeliniert werden sicher und idempotent Modus. Nach vielen Jahren des Kampfes mit den Problemen, die durch das Aktivieren von Pipelining eingeführt wurden, wurde diese Funktion zuerst deaktiviert und dann aufgrund der angekündigten Übernahme von HTTP/2 auch aus den meisten Browsern entfernt.

Http/2 erweiterte die Verwendung anhaltender Verbindungen durch Multiplexe viele gleichzeitige Anforderungen/Antworten über eine einzelne TCP/IP -Verbindung.

Http/3 Verwendet keine TCP/IP -Verbindungen, sondern Quic + UDP (siehe auch: technische Übersicht).

Optimierungen des Inhaltsabrufs

HTTP/0,9
Eine angeforderte Ressource wurde immer vollständig gesendet.
Http/1.0
HTTP/1.0 Hinzufügen von Headern zum Verwalten von Ressourcen, die vom Kunden zwischengespeichert wurden, um bedingte GET -Anfragen zu ermöglichen. In der Praxis muss ein Server den gesamten Inhalt der angeforderten Ressource nur dann zurückgeben, wenn die letzte geänderte Zeit durch den Client nicht bekannt ist oder wenn er sich seit der letzten vollständigen Antwort auf GET -Anforderung geändert hat. Einer dieser Header, "Inhaltskodierung", wurde hinzugefügt, um festzustellen, ob der zurückgegebene Inhalt einer Ressource komprimiert.
Wenn die Gesamtlänge des Inhalts einer Ressource im Voraus nicht bekannt war (d. H. Da sie dynamisch generiert wurde, usw.), dann der Header "Inhaltslänge: Nummer" war nicht in HTTP -Headern vorhanden und der Client ging davon aus, dass der Inhalt, wenn der Server die Verbindung schloss, vollständig gesendet worden war. Dieser Mechanismus konnte nicht zwischen einer erfolgreich abgeschlossenen Ressourcenübertragung und einem unterbrochenen (aufgrund eines Server- / Netzwerkfehlers oder etwas anderem) unterscheiden.
Http/1.1
HTTP/1.1 eingeführt:
  • Neue Header, um das bedingte Abruf von zwischengespeicherten Ressourcen besser zu verwalten.
  • Chunked Transfer -Codierung Damit Inhalte in Stücken gestreamt werden können, um ihn zuverlässig zu senden, auch wenn der Server seine Länge nicht im Voraus kennt (d. H. Da er dynamisch generiert ist usw.).
  • Byte -Reichweite, wo ein Client nur eine oder mehrere Teile (Bytesbereiche) einer Ressource (d. H. Der erste Teil, ein Teil in der Mitte oder am Ende des gesamten Inhalts usw.) anfordern kann, und der Server sendet normalerweise nur die angeforderten Teile). Dies ist nützlich, um einen unterbrochenen Download wieder aufzunehmen (wenn eine Datei wirklich groß ist), wenn nur ein Teil eines Inhalts angezeigt oder dynamisch dem bereits sichtbaren Teil von einem Browser hinzugefügt werden muss (d. H. Nur die ersten oder die folgenden n -Kommentare von eine Webseite), um Zeit, Bandbreite und Systemressourcen usw.
Http/2, http/3
Sowohl HTTP/2 als auch HTTP/3 haben die oben genannten Merkmale von HTTP/1.1 beibehalten.

HTTP -Authentifizierung

HTTP bietet mehrere Authentifizierungsschemata wie z. Grundlegende Zugriffsauthentifizierung und Zugriffsauthentifizierung verdau Dies funktioniert über einen Herausforderungsmechanismus, bei dem der Server vor dem Servieren des angeforderten Inhalts eine Herausforderung identifiziert und stellt.

HTTP bietet einen allgemeinen Framework für die Zugriffskontrolle und -authentifizierung über einen erweiterbaren Satz von Challenge -Response -Authentifizierungsschemata, die von einem Server verwendet werden können, um eine Client -Anforderung herauszufordern, und von einem Client zur Bereitstellung von Authentifizierungsinformationen.[46]

Der obige Mechanismus gehört zum HTTP -Protokoll und wird von der Client- und Server -HTTP Eine Webanwendungssitzung.

Authentifizierungsbereich

Die HTTP-Authentifizierungsspezifikation liefert auch ein willkürliches, implementierungsspezifisches Konstrukt für weitere Teilen von Ressourcen, die einer bestimmten Wurzel gemeinsam sind Uri. Die Realm -Wertzeichenfolge wird, falls vorhanden, mit dem kanonischen Wurzel -URI kombiniert, um die Schutzraumkomponente der Herausforderung zu bilden. Dies ermöglicht es dem Server, separate Authentifizierungsbereiche unter einem Root -URI zu definieren.[46]

HTTP -Anwendungssitzung

Http ist a Staatelo Protokoll. Für die Dauer mehrerer Anforderungen muss der Webserver nicht für jeden Benutzer Informationen oder Status über jeden Benutzer beibehalten.

Etwas Web Applikationen müssen Benutzersitzungen verwalten, also implementieren sie Zustände oder Server -Seitensitzungenzum Beispiel verwenden HTTP -Kekse[47] oder versteckt Variablen innerhalb Webformen.

Um eine Anwendungsbenutzersitzung zu starten, eine interaktive Authentifizierung Über Webanwendung Anmeldung muss durchgeführt werden. So stoppen eine Benutzersitzung a Ausloggen Der Betrieb muss vom Benutzer angefordert werden. Diese Art von Operationen verwendet nicht HTTP -Authentifizierung Eine benutzerdefinierte Authentifizierung von Webanwendungen.[46]

HTTP/1.1 Meldungen anfordern

Anforderungsnachrichten werden von einem Client an einen Zielserver gesendet.[Anmerkung 4]

Syntax anfordern

Ein Kunde sendet Meldungen anfordern auf den Server, der aus:[48]

  • a Anfragezeile, bestehend aus der Fall-sensitiven Anforderungsmethode, a Platz, die angeforderte URL, ein weiterer Raum, die Protokollversion, a Kutschenrückkehr, und ein Zeilenvorschub, z.B.:
Get /images/logo.png http/1.1
  • Null oder mehr Anfrage Header Fields (Mindestens 1 oder mehr Header bei HTTP/1.1), die jeweils aus dem von Fall unempfindlichen Feldnamen bestehen, einem Dickdarm, optionaler Führung Whitespace, der Feldwert, eine optionale nachfolgende Whitespace und endet mit einer Kutschenrendite und einem Linienfutter, z. B.:
Host: www.example.com Akzeptierensprung: en
  • eine leere Linie, bestehend aus einer Kutschenrendite und einem Linienfutter;
  • ein optionales Nachrichtentext.

Im HTTP/1.1 -Protokoll alle Headerfelder außer außer Host: Hostname sind optional.

Eine Anforderungszeile, die nur den Pfadnamen enthält RFC 1945.[49]

Anfordern von Methoden

Eine HTTP/1.1 -Anforderung, die mit Telnet gestellt wurde. Das Anfrage Botschaft, Antwort Header -Abschnitt und Reaktionskörper werden hervorgehoben.

HTTP definiert Methoden (manchmal bezeichnet als als Verben, aber nirgendwo in der Spezifikation erwähnt es Verb) um die gewünschte Maßnahme anzuzeigen, die auf der identifizierten Ressource ausgeführt werden soll. Was diese Ressource darstellt, ob bereits vorhandene Daten oder Daten, die dynamisch generiert werden, hängt von der Implementierung des Servers ab. Oft entspricht die Ressource einer Datei oder der Ausgabe einer auf dem Server wohnhaften ausführbaren Datei. Die HTTP/1.0 -Spezifikation[50] Definiert die Methoden GET-, Kopf- und Post -Methoden sowie die HTTP/1.1 -Spezifikation[51] Fünf neue Methoden hinzugefügt: setzen, löschen, verbinden, Optionen und Verfolgung. Jeder Client kann eine beliebige Methode verwenden und der Server kann so konfiguriert werden, dass jede Kombination von Methoden unterstützt wird. Wenn eine Methode einem Zwischenprodukt unbekannt ist, wird sie als unsicher behandelt und nicht idempotent Methode. Die Anzahl der Methoden, die definiert werden können, gibt keine Grenze, wodurch zukünftige Methoden angegeben werden können, ohne die vorhandene Infrastruktur zu brechen. Zum Beispiel, Webdav definierte sieben neue Methoden und RFC 5789 angegeben Patch Methode.

Methodennamen sind fallempfindlich.[52][53] Dies steht im Gegensatz zu HTTP-Header-Feldnamen, die von Fall unempfindlich sind.[54]

ERHALTEN
Die GET -Methode fordert, dass die Zielressourcen eine Darstellung ihres Zustands übertragen. Anfragen erhalten sollten nur Daten abrufen und sollte keinen anderen Effekt haben. (Dies gilt auch für einige andere HTTP -Methoden.)[1] Um Ressourcen ohne Änderungen abzurufen, wird Get vor der Post bevorzugt, so wie sie sein können angesprochen durch ein URL. Dies ermöglicht Lesezeichen und Teilen und macht die Antworten erhalten zwischengespeichert, was Bandbreite retten kann. Das W3c hat Leitlinienprinzipien zu dieser Auszeichnung veröffentlicht und sagte: "Internetanwendung Das Design sollte durch die oben genannten Prinzipien, aber auch durch die relevanten Einschränkungen informiert werden. "[55] Sehen sichere Methoden unter.
KOPF
Die Kopfmethode fordert, dass die Zielressourcen eine Darstellung ihres Zustands wie für eine GET -Anforderung übertragen, jedoch ohne die in der Antwortkörper eingeschlossenen Darstellungsdaten. Dies ist nützlich, um die Repräsentationsmetadaten im Antwortheader abzurufen, ohne die gesamte Darstellung übertragen zu müssen. Verwendungsmöglichkeiten enthalten die Überprüfung, ob eine Seite über die verfügbar ist Statuscode und schnell die Größe von a finden Datei (Inhaltslänge).
POST
Das Post -Methode erfragt, dass der Zielressourcenprozess die in der Anfrage entsprechende Darstellung gemäß der Semantik der Zielressource eingeschlossen ist. Zum Beispiel wird es verwendet, um eine Nachricht an eine zu veröffentlichen Internet Forum, abonnieren a Mailinglisteoder ein Abschluss eines Online Einkaufen Transaktion.[56]
STELLEN
Die Put -Methode fordert, dass die Zielressource ihren Status mit dem Status erstellt oder aktualisiert, der durch die in der Anforderung eingeschlossene Darstellung definiert ist. Eine Unterscheidung vom Post ist, dass der Client den Zielort auf dem Server angibt.[57]
LÖSCHEN
Die Löschmethode fordert, dass die Zielressource ihren Status löscht.
VERBINDEN
Die Verbindungsmethode fordert, dass der Vermittler a einrichtet TCP/IP -Tunnel auf den vom Anforderungsziel identifizierten Originserver. Es wird oft verwendet, um Verbindungen durch einen oder mehrere zu sichern HTTP -Proxies mit Tls.[58][59][60] Sehen HTTP -Verbindungsmethode.
OPTIONEN
Die Optionsmethode fordert, dass die Zielressourcen die von ihm unterstützten HTTP -Methoden übertragen. Dies kann verwendet werden, um die Funktionalität eines Webservers zu überprüfen, indem Sie '*' anstelle einer bestimmten Ressource anfordern.
VERFOLGEN
Die Trace -Methode fordert, dass die Zielressourcen die empfangene Anforderung in der Antwortbehörde übertragen. Auf diese Weise kann ein Kunde sehen, welche (falls vorhanden) Änderungen oder Ergänzungen von Vermittlern vorgenommen wurden.
Patch
Das Patch -Methode Anfragen, dass die Zielressource ihren Status gemäß der in der in der Anfrage eingeschlossenen Darstellung festgelegten teilweise Aktualisierung ändert. Dies kann die Bandbreite speichern, indem ein Teil einer Datei oder eines Dokuments aktualisiert wird, ohne sie vollständig übertragen zu müssen.[61]

Alle allgemeinen Webserver sind erforderlich, um mindestens die GET- und Kopfmethoden zu implementieren, und alle anderen Methoden werden nach der Spezifikation als optional angesehen.[62]

Eigenschaften von Anforderungsmethoden
Anforderungsmethode RFC Anfrage hat Nutzlastkörper Antwort hat Nutzlastkörper Sicher Idempotent Zwischengespeichert
ERHALTEN RFC 7231 Optional Ja Ja Ja Ja
KOPF RFC 7231 Optional Nein Ja Ja Ja
POST RFC 7231 Ja Ja Nein Nein Ja
STELLEN RFC 7231 Ja Ja Nein Ja Nein
LÖSCHEN RFC 7231 Optional Ja Nein Ja Nein
VERBINDEN RFC 7231 Optional Ja Nein Nein Nein
OPTIONEN RFC 7231 Optional Ja Ja Ja Nein
VERFOLGEN RFC 7231 Nein Ja Ja Ja Nein
Patch RFC 5789 Ja Ja Nein Nein Nein

Sichere Methoden

Eine Anforderungsmethode ist sicher Wenn eine Anforderung mit dieser Methode keinen beabsichtigten Einfluss auf den Server hat. Die Methoden erhalten, Kopf, Optionen und Trace sind als sicher definiert. Mit anderen Worten, sichere Methoden sollen sein schreibgeschützt. Sie schließen nicht aus Nebenwirkungen Allerdings, z. B. Anfragen von Informationen an a Logdatei oder aufladen ein WerbekontoDa sie nicht vom Kunden angefordert werden, per Definition.

Im Gegensatz dazu sind die Methoden post, setzen, löschen, verbinden und Patch nicht sicher. Sie können den Status des Servers ändern oder andere Effekte haben, z. B. das Senden eines Email. Solche Methoden werden daher normalerweise nicht durch Anpassung verwendet Webroboter oder Webcrawler; Einige, die sich nicht anpassen, neigen dazu, Anfragen zu stellen, ohne dass Kontext oder Konsequenzen berücksichtigt werden.

Trotz der vorgeschriebenen Sicherheit von Get -Anfragen ist in der Praxis in keiner Weise technisch eingeschränkt. Nachlässige oder absichtlich unregelmäßige Programmierung können GET-Anforderungen ermöglichen, nicht triviale Änderungen auf dem Server zu verursachen. Dies wird aufgrund der Probleme entmutigt, die auftreten können, wenn Web -Caching, Suchmaschinenund andere automatisierte Agenten nehmen unbeabsichtigte Änderungen am Server vor. Beispielsweise kann eine Website eine Löschung einer Ressource über eine URL wie z. https://example.com/article/1234/delete, was, wenn es willkürlich eingeholt, sogar mit GET mit GET gelegt wird, einfach den Artikel löschen würde.[63] Für eine ordnungsgemäß codierte Website würde eine Methode für diese Aktion eine Löschung oder eine Postmethode erfordern, die nicht malicucious Bots nicht ausführen würden.

Ein Beispiel dafür in der Praxis war während der kurzlebigen Google Web Accelerator Beta, die vorgeholkte willkürliche URLs auf der Seite ein Benutzer anzog, wodurch Datensätze automatisch geändert oder gelöscht werden. en masse. Die Beta wurde erst Wochen nach ihrer ersten Veröffentlichung nach weit verbreiteter Kritik suspendiert.[64][63]

Idempotente Methoden

Siehe auch: Idempotence § Informatik Bedeutung

Eine Anforderungsmethode ist idempotent Wenn mehrere identische Anforderungen mit dieser Methode den gleichen Effekt haben wie eine einzige solche Anforderung. Die Methoden setzen und löschen und sichere Methoden werden als idempotent definiert. Sichere Methoden sind trivial idempotent, da sie überhaupt keinen Einfluss auf den Server haben sollen. Die Put- und Löschenmethoden sind inzwischen idempotent, da aufeinanderfolgende identische Anfragen ignoriert werden. Eine Website könnte beispielsweise einen Put -Endpunkt einrichten, um die aufgezeichnete E -Mail -Adresse eines Benutzers zu ändern. Wenn dieser Endpunkt korrekt konfiguriert ist, werden alle Anfragen, nach denen die E -Mail -Adresse eines Benutzers in dieselbe E -Mail -Adresse geändert wird, die bereits aufgezeichnet wurde - e.g. Doppelte Anfragen nach einer erfolgreichen Anfrage - haben keine Wirkung. In ähnlicher Weise hat eine Anfrage, einen bestimmten Benutzer zu löschen, keinen Einfluss, wenn dieser Benutzer bereits gelöscht wurde.

Im Gegensatz dazu sind die Methoden nach Post, Connect und Patch nicht unbedingt idempotent, und daher kann das Senden einer identischen Postanforderung mehrmals den Status des Servers weiter ändern oder weitere Effekte haben, z. B. das Senden mehrerer E -Mails. In einigen Fällen ist dies der gewünschte Effekt, aber in anderen Fällen kann es versehentlich auftreten. Ein Benutzer kann beispielsweise versehentlich mehrere Beitragsanforderungen senden, indem er erneut auf eine Schaltfläche klickt, wenn er nicht klares Feedback erhielt, dass der erste Klick verarbeitet wurde. Während Internetbrowser kann zeigen Warndialogfelder Um Benutzer in einigen Fällen zu warnen, in denen das Neuladen einer Seite eine Postanforderung neu aufladet, ist es in der Regel bei der Webanwendung, Fälle zu verarbeiten, in denen eine Postanforderung nicht mehr als einmal übermittelt werden sollte.

Beachten Sie, dass, ob eine Methode idempotent ist oder nicht, nicht vom Protokoll oder des Webservers erzwungen wird. Es ist durchaus möglich, eine Webanwendung zu schreiben, in der (z. B.) eine Datenbankeinfügung oder eine andere nicht idempotente Aktion durch eine GET oder eine andere Anforderung ausgelöst wird. Dies gegen Empfehlungen kann jedoch zu unerwünschten Konsequenzen führen, wenn a User-Agent Angenommen, das Wiederholen der gleichen Anfrage ist sicher, wenn dies nicht der Fall ist.

Zwischengespeicherbare Methoden

Siehe auch: Webcache

Eine Anforderungsmethode ist zwischengespeichert Wenn Antworten auf Anfragen mit dieser Methode für die zukünftige Wiederverwendung gespeichert werden. Die Methoden erhalten, Kopf und Post sind als zwischengespeichert.

Im Gegensatz dazu sind die Methoden, löschen, verbinden, Optionen, Spuren und Patch nicht zwischengespeichert.

Anfrage Header Fields

Siehe auch: Liste der HTTP -Header -Felder § Felder anfordern

Anforderungsheaderfelder ermöglichen es dem Client, zusätzliche Informationen über die Anforderungszeile hinauszugeben und als Anforderungsmodifikatoren zu wirken (ähnlich wie die Parameter eines Prozedur). Sie geben Informationen über den Kunden, über die Zielressource oder über die erwartete Behandlung der Anfrage.

HTTP/1.1 Antwortmeldungen

Eine Antwortmeldung wird von einem Server an einen Client als Antwort auf seine frühere Anforderungsnachricht gesendet.[Anmerkung 4]

Antwortsyntax

Ein Server sendet Antwortmeldungen an den Kunden, der aus:[48] 

Http/1.1 200 ok
  • Null oder mehr Antwortkopffelder, jeweils bestehend aus dem von Fall unempfindlichen Feldnamen, einem Dickdarm, optionaler Führung Whitespace, der Feldwert, eine optionale nachfolgende Whitespace und endet mit einer Kutschenrendite und einem Linienfutter, z. B.:
Inhaltstyp: Text/HTML
  • eine leere Linie, bestehend aus einer Kutschenrendite und einem Linienfutter;
  • ein optionales Nachrichtentext.

Antwortstatuscodes

Siehe auch: Liste der HTTP -Statuscodes

In HTTP/1.0 und seitdem wird die erste Zeile der HTTP -Antwort als die genannt Statuszeile und beinhaltet einen numerischen Statuscode (wie zum Beispiel "404") und ein Textual Grund Phrase (wie "nicht gefunden"). Der Antwortstatuscode ist ein dreistelliger Ganzzahlcode, der das Ergebnis des Versuchs des Servers darstellt, die entsprechende Anforderung des Clients zu verstehen und zu erfüllen. Die Art und Weise, wie der Client die Antwort behandelt, hängt hauptsächlich vom Statuscode und sekundär von den anderen Antwort -Headerfeldern ab. Kunden verstehen möglicherweise nicht alle registrierten Statuscodes, müssen jedoch ihre Klasse (angegeben durch die erste Ziffer des Statuscode) verstehen und einen nicht erkannten Statuscode als gleichwertig mit dem X00 -Statuscode dieser Klasse entsprechen.

Der Standard Grund Phrasen sind nur Empfehlungen und können durch "lokale Äquivalente" ersetzt werden Web-EntwicklerDiskretion. Wenn der Statuscode ein Problem angegeben hat, kann der Benutzeragent die angezeigt Grund Phrase dem Benutzer, um weitere Informationen über die Art des Problems zu erhalten. Mit dem Standard können der Benutzeragent auch versuchen, die zu interpretieren Grund Phrase, obwohl dies unklug sein mag, da der Standard ausdrücklich angibt, dass Statuscodes maschinenlesbar sind und Grund Phrasen sind menschlich lesbar.

Die erste Ziffer des Statuscode definiert seine Klasse:

1xx (Information)
Die Anfrage wurde fortgesetzt und fortgesetzt.
2xx (erfolgreich)
Die Anfrage wurde erfolgreich empfangen, verstanden und akzeptiert.
3xx (Umleitung)
Es müssen weitere Maßnahmen ergriffen werden, um die Anfrage abzuschließen.
4xx (Client -Fehler)
Die Anfrage enthält schlechte Syntax oder kann nicht erfüllt werden.
5xx (Serverfehler)
Der Server konnte eine scheinbar gültige Anfrage nicht erfüllen.

Antwortkopffelder

Siehe auch: Liste der HTTP -Headerfelder § Antwortfelder

Mit den Feldern der Antwortheader können der Server zusätzliche Informationen über die Statuszeile hinausgeben und als Antwortmodifikatoren fungieren. Sie geben Informationen über den Server oder über den weiteren Zugriff auf die Zielressource oder die zugehörigen Ressourcen.

Jedes Antwort -Headerfeld hat eine definierte Bedeutung, die durch die Semantik der Anforderungsmethode oder des Antwortstatuscodes weiter verfeinert werden kann.

HTTP / 1.1 Beispiel für die Anforderung / Antworttransaktion

Im Folgenden finden Sie eine Beispiel -HTTP -Transaktion zwischen einem HTTP/1.1 -Client und einem HTTP/1.1 -Server auf www.example.com, Port 80.[Anmerkung 5][Anmerkung 6]

Kundenanfrage 

ERHALTEN / Http/1.1 Gastgeber: www.example.com User-Agent: Mozilla/5.0 Annehmen: text/html, application/xhtml+xml, application/xml; q = 0,9, Bild/avif, Bild/webp,*/*; q = 0,8 Sprache akzeptieren: en-gb, en; q = 0,5 Akzeptieren: gzip, Deflate, Br Verbindung: bleib am Leben

Eine Kundenanforderung (bestehend aus in diesem Fall der Anforderungszeile und einigen Header, die nur auf die reduziert werden können "Host: Hostname" Header) folgt eine leere Linie, so dass die Anforderung mit einem doppelten Ende der Zeile endet, jeweils in Form von a Kutschenrückkehr gefolgt von einem Zeilenvorschub. Das "Host: Hostname" Der Kopfwert unterscheidet zwischen verschiedenen DNS Namen, die eine Single teilen IP Adresse, zuzulassen, namentlichbasiert Virtuelles Hosting. Während in HTTP/1.0 optional ist, ist es in HTTP/1.1 obligatorisch. (Ein "/" (Schrägstrich) holt normalerweise a /Idex.html Datei, wenn es eine gibt.)

Serverantwort 

Http/1.1 200 OK Datum: Mo, 23. Mai 2005 22:38:34 GMT Inhaltstyp: Text/HTML; charset = utf-8 Inhaltslänge: 155 Zuletzt bearbeitet: Mi, 08. Januar 2003 23:11:55 GMT Server: Apache/1.3.3.7 (UNIX) (Rothut/Linux) ETAG: "3F80F-1B6-3E1CB03B" Akzeptieren: Bytes Verbindung: nah dran <html>  <Kopf>  <Titel>Eine BeispielseiteTitel>  Kopf>  <Karosserie>  <p>Hallo Welt, dies ist ein sehr einfaches HTML -Dokument.p>  Karosserie> html>

Das ETAG (Entity -Tag) Header -Feld wird verwendet, um festzustellen, ob eine zwischengespeicherte Version der angeforderten Ressource mit der aktuellen Version der Ressource auf dem Server identisch ist. "Inhaltstyp" Gibt die an Internet -Medientyp der Daten, die durch die HTTP -Nachricht übermittelt wurden, während "Inhaltslänge" zeigt seine Länge in Bytes an. Das http/1.1 Webserver Veröffentlichen Sie die Fähigkeit, auf Anfragen für bestimmte Byte -Bereiche des Dokuments zu antworten, indem Sie das Feld festlegen "Akzeptieren: Bytes". Dies ist nützlich, wenn der Kunde nur bestimmte Teile haben muss[65] einer vom Server gesendeten Ressource, die aufgerufen wird Byte -Serving. Wann "Verbindung: Schließen" wird gesendet, das bedeutet, dass die Webserver wird das schließen TCP Verbindung unmittelbar nach dem Ende der Übertragung dieser Antwort.[21]

Die meisten Kopfzeilen sind optional, einige sind jedoch obligatorisch. Beim Kopfball "Inhaltslänge: Nummer" fehlt in einer Antwort mit einer Entitätskörper "Transfer-Coding: Chunked" ist anwesend. Chunked Transfer -Codierung verwendet eine Stücke von 0, um das Ende des Inhalts zu markieren. Einige alte Implementierungen von HTTP/1.0 ließen den Header aus "Inhaltslänge" Wenn die Länge der Körperentität zu Beginn der Antwort nicht bekannt war und so die Datenübertragung in den Client fortgesetzt wurde, bis der Server den Socket schloss.

A "Inhaltskodierung: Gzip" Kann verwendet werden, um den Kunden darüber zu informieren, dass der Teil der übertragenen Daten durch den GZIP -Algorithmus komprimiert wird.

Verschlüsselte Verbindungen

Die beliebteste Art, eine verschlüsselte HTTP -Verbindung herzustellen, ist Https.[66] Es gibt auch zwei weitere Methoden zur Erstellung einer verschlüsselten HTTP -Verbindung: Sichern Sie das Hypertext -Transferprotokollund verwenden die HTTP/1.1 Upgrade -Header Um ein Upgrade auf TLS anzugeben. Die Browser-Unterstützung für diese beiden ist jedoch nahezu nicht vorhanden.[67][68][69]

Ähnliche Protokolle

  • Das Gopher -Protokoll ist ein Inhaltsableitungsprotokoll, das in den frühen neunziger Jahren von HTTP vertrieben wurde.
  • Das Spdy Protokoll ist eine Alternative zu HTTP, die bei entwickelt wurde Google, ersetzt durch Http/2.
  • Das Gemini -Protokoll ist ein von Gopher inspiriertes Protokoll, das Datenschutzmerkmale vorschreibt.

Siehe auch

Anmerkungen

  1. ^ In der Praxis werden diese Streams als mehrere TCP/IP Multiplex Gleichzeitige Anfragen/Antworten, wodurch die Anzahl der realen TCP/IP -Verbindungen auf der Server von 2 bis 8 pro Client auf 1 erheblich reduziert wird und viele weitere Clients gleichzeitig bedient werden können.
  2. ^ Im Jahr 2021 wurde die Unterstützung von HTTP/0,9 nicht offiziell vollständig veraltet und ist immer noch in vielen Webservern und Browsern (nur für Serverantworten) vorhanden, auch wenn sie normalerweise deaktiviert sind. Es ist unklar, wie lange es dauern wird, bis HTTP/0,9 stillgelegt wird.
  3. ^ Seit Ende 1996 begannen einige Entwickler der beliebten HTTP/1.0-Browser und -Cerner (insbesondere diejenigen, die auch die Unterstützung für HTTP/1.1 geplant hatten), eine Art Keep-Alive-Mechanismus (unter Verwendung neuer HTTP Header), um die TCP/IP -Verbindung für mehr als ein Anforderungs-/Antwortpaar geöffnet zu halten und so den Austausch mehrerer Anforderungen/Antworten zu beschleunigen.[31]
  4. ^ a b HTTP/2 und HTTP/3 haben eine andere Darstellung für HTTP -Methoden und -Header.
  5. ^ HTTP/1.0 hat die gleichen Nachrichten mit Ausnahme einiger fehlender Header.
  6. ^ HTTP/2 und HTTP/3 verwenden den gleichen Anforderungs-/Antwortmechanismus, jedoch mit unterschiedlichen Darstellungen für HTTP -Header.

Verweise

  1. ^ a b Fielding, Roy T.; Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk; Massinter, Larry; Leach, Paul J.; Berners-Lee, Tim (Juni 1999). Hypertext -Transferprotokoll - HTTP/1.1. Ietf. doi:10.17487/rfc2616. RFC 2616.
  2. ^ a b c d Tim Berner-Lee (1991-01-01). "Das ursprüngliche HTTP wie 1991 definiert". www.w3.org. World Wide Web Konsortium. Abgerufen 2010-07-24.
  3. ^ "Http/3 ist schnell". Metriken anfordern. Abgerufen 2022-07-01.
  4. ^ a b Tim Berner-Lee (1992). "Basic HTTP wie 1992 definiert". www.w3.org. World Wide Web Konsortium. Abgerufen 2021-10-19.
  5. ^ Im RFC 1945. Diese Spezifikation wurde dann durch HTTP/1.1 überwunden.
  6. ^ RFC 2068 (1997) wurde von veraltet von RFC 2616 1999, was ebenfalls durch ersetzt wurde durch RFC 7230 im Jahr 2014.
  7. ^ "Verwendungsstatistik des Standardprotokolls HTTPS für Websites". w3techs.com. Abgerufen 2022-05-05.
  8. ^ "Verwendungsstatistik von HTTP/2 für Websites". w3techs.com. Abgerufen 2022-05-05.
  9. ^ "Kann ich ... Supporttabellen für HTML5, CSS3 usw. verwenden". caniuse.com. Abgerufen 2022-05-05.
  10. ^ "Transport Layer Security (TLS) Anwendungsschichtprotokollverhandlungserweiterung". Ietf. Juli 2014. RFC 7301.
  11. ^ BELSHE, M.; Peon, R.; Thomson, M. "Hypertext Transfer Protocol Version 2, Verwendung von TLS -Funktionen". Abgerufen 2015-02-10.
  12. ^ Benjamin, David. "Verwenden von TLS 1.3 mit HTTP/2". Tools.ietf.org. Abgerufen 2020-06-02. Dies senkt die Barriere für die Bereitstellung von TLS 1.3, eine wichtige Sicherheitsverbesserung gegenüber TLS 1.2.
  13. ^ "Http/3". Abgerufen 2022-06-06.
  14. ^ "Verwendungsstatistik von HTTP/3 für Websites". w3techs.com. Abgerufen 2021-11-02.
  15. ^ "Kann ich ... Supporttabellen für HTML5, CSS3 usw. verwenden". caniuse.com. Abgerufen 2022-05-05.
  16. ^ Cimpanu, Catalin (26. September 2019). "CloudFlare, Google Chrome und Firefox fügen HTTP/3 -Unterstützung hinzu". ZDNET. Abgerufen 27. September 2019.
  17. ^ "HTTP/3: Die Vergangenheit, die Gegenwart und die Zukunft". Der Cloudflare -Blog. 2019-09-26. Abgerufen 2019-10-30.
  18. ^ "Firefox Nightly unterstützt HTTP 3 - General - Cloudflare Community". 2019-11-19. Abgerufen 2020-01-23.
  19. ^ "Gesamtbetrieb". RFC 2616. p. 12. Sek. 1.4. doi:10.17487/rfc2616. RFC 2616.
  20. ^ "Gesamtbetrieb". RFC 1945. S. 6–8. Sek. 1.3. doi:10.17487/rfc1945. RFC 1945.
  21. ^ a b c "Verbindungsmanagement: Verbindung". RFC 7230, HTTP/1.1: Nachrichtensyntax und Routing. S. 51–52. Sek. 6.1. doi:10.17487/rfc7230. RFC 7230.
  22. ^ "Verbindungsmanagement: Persistenz". RFC 7230, HTTP/1.1: Nachrichtensyntax und Routing. S. 52–53. Sek. 6.3. doi:10.17487/rfc7230. RFC 7230.
  23. ^ "Klassische HTTP -Dokumente". W3.org. 1998-05-14. Abgerufen 2010-08-01.
  24. ^ "HTTP/2 -Protokollübersicht". RFC 7540, Hypertext Transfer Protocol Version 2 (HTTP/2). p. 5. Sek. 2. doi:10.17487/rfc7540. RFC 7540.
  25. ^ "Erfindung des Webs, Web History, der das Web erfunden hat, Tim Berners-Lee, Robert Cailliau, Cern, erster Webserver". LivingInternet. Abgerufen 2021-08-11.
  26. ^ Berners-Lee, Tim (1990-10-02). "Daemon.c - TCP/IP -basierter Server für Hypertext". www.w3.org. Abgerufen 2021-08-11.{{}}: CS1 Wartung: URL-Status (Link)
  27. ^ Berners-Lee, Tim. "Hypertext Transfer Protocol". World Wide Web Konsortium. Abgerufen 31. August 2010.
  28. ^ Raggett, Dave. "Dave Raggetts Biografie". World Wide Web Konsortium. Abgerufen 11. Juni 2010.
  29. ^ Raggett, Dave; Berners-Lee, Tim. "Hypertext Transfer Protocol Arbeitsgruppe". World Wide Web Konsortium. Abgerufen 29. September 2010.
  30. ^ Raggett, Dave. "HTTP WG Pläne". World Wide Web Konsortium. Abgerufen 29. September 2010.
  31. ^ a b David Gourley; Brian Totty; Marjorie Sayer; Anshu Aggarwal; Sailu Reddy (2002). HTTP: Der endgültige Handbuch. (Auszug des Kapitels: "Persistente Verbindungen"). O'Reilly Media, Inc. ISBN 9781565925090. Abgerufen 2021-10-18.
  32. ^ "Http/1.1". Webcom.com Glossareintrag. Archiviert von das Original Am 2001-11-21. Abgerufen 2009-05-29.
  33. ^ "HTTP-NG Arbeitsgruppe". www.w3.org. World Wide Web Konsortium. 1997. Abgerufen 2021-10-19.
  34. ^ Webadministrator (2007). "HTTP -Arbeitsgruppe". httpwg.org. Ietf. Abgerufen 2021-10-19.
  35. ^ Webadministrator (2007). "HTTP -Arbeitsgruppe: Charter httpbis". DataTracker.ietf.org. Ietf. Abgerufen 2021-10-19.
  36. ^ "SPDY: Ein experimentelles Protokoll für ein schnelleres Netz". dev.chromium.org. Google. 2009-11-01. Abgerufen 2021-10-19.
  37. ^ "Wiederaufladung httpbis". IETF; Http wg. 2012-01-24. Abgerufen 2021-10-19.
  38. ^ IESG-Sekretär (2012-03-19). "WG Action: Revharter: Hypertext Transfer Protocol Bis (httpbis)". IETF; Http wg. Abgerufen 2021-10-19.
  39. ^ Ilya Grigorik; Surma (2019-09-03). "Hochleistungs -Browser -Netzwerk: Einführung in HTTP/2". Entwickler.google.com. Google Inc. Abgerufen 2021-10-19.
  40. ^ "Anhang-A: HTTP-Version History". RFC 7230, HTTP/1.1: Nachrichtensyntax und Routing. p. 78. Sec. A. doi:10.17487/rfc7230. RFC 7230.
  41. ^ Matt Menke (2016-06-30). "Absicht zu verabfeln und zu entfernen: HTTP/0,9 -Unterstützung". Groups.google.com. Abgerufen 2021-10-15.
  42. ^ "Http/3". Abgerufen 2022-06-06.
  43. ^ a b "Client/Server Messaging". RFC 7230, HTTP/1.1: Nachrichtensyntax und Routing. S. 7–8. Sek. 2.1. doi:10.17487/rfc7230. RFC 7230.
  44. ^ "Einheitliche Ressourcenkennung: HTTP URI -Schema". RFC 7230, HTTP/1.1: Nachrichtensyntax und Routing. S. 17–18. Sek. 2.7.1. doi:10.17487/rfc7230. RFC 7230.
  45. ^ "Einheitliche Ressourcenkennung: HTTPS URI -Schema". RFC 7230, HTTP/1.1: Nachrichtensyntax und Routing. S. 18–19. Sek. 2.7.2. doi:10.17487/rfc7230. RFC 7230.
  46. ^ a b c Fielding, Roy T.; Reschke, Julian F. (Juni 2014). Hypertexttransferprotokoll (HTTP/1.1): Authentifizierung. Ietf. doi:10.17487/rfc7235. RFC 7235.
  47. ^ Lee, Wei-bin; Chen, Hsing-Bai; Chang, Shun-Shyan; Chen, Tzung-Her (2019-01-25). "Sicherer und effizienter Schutz für HTTP-Cookies mit Selbstverifizierung". Internationales Journal of Communication Systems. 32 (2): e3857. doi:10.1002/DAC.3857. S2CID 59524143.
  48. ^ a b "Nachrichtenformat". RFC 7230: HTTP/1.1 Nachrichtensyntax und Routing. p. 19. Sec. 3. doi:10.17487/rfc7230. RFC 7230.
  49. ^ "Apache Woche. Http/1.1". 090502 apacheweek.com
  50. ^ Berners-Lee, Tim; Fielding, Roy T.; Nielsen, Henrik Frystyk. "Methodendefinitionen". Hypertext -Transferprotokoll - HTTP/1.0. Ietf. S. 30–32. Sek. 8. doi:10.17487/rfc1945. RFC 1945.
  51. ^ "Methodendefinitionen". RFC 2616. S. 51–57. Sek. 9. doi:10.17487/rfc2616. RFC 2616.
  52. ^ "Nachrichtenformat: Startlinie, Anforderungszeile". RFC 7230, Hypertext Transfer Protocol (HTTP/1.1): Nachrichtensyntax und Routing. S. 21-22. Sek. 3.1.1. doi:10.17487/rfc7230. RFC 7230.
  53. ^ "Anforderungsmethoden: Übersicht". RFC 7231, Hypertext -Transferprotokoll (HTTP/1.1): Semantik und Inhalt. S. 21-22. Sek. 4.1. doi:10.17487/rfc7231. RFC 7231.
  54. ^ "Nachrichtenformat: Headerfelder". RFC 7230, Hypertext Transfer Protocol (HTTP/1.1): Nachrichtensyntax und Routing. S. 21-22. Sek. 3.2. doi:10.17487/rfc7230. RFC 7230.
  55. ^ Jacobs, Ian (2004). "URIS, Adressierbarkeit und die Verwendung von HTTP -Get and Post". Fundtechnik -Architekturgruppe. W3c. Abgerufen 26. September 2010.
  56. ^ "POST". RFC 2616. p. 54. Sek. 9.5. doi:10.17487/rfc2616. RFC 2616.
  57. ^ "STELLEN". RFC 2616. p. 55. Sek. 9.6. doi:10.17487/rfc2616. RFC 2616.
  58. ^ "VERBINDEN". Hypertext -Transferprotokoll - HTTP/1.1. Ietf. Juni 1999. p. 57. Sec. 9.9. doi:10.17487/rfc2616. RFC 2616.
  59. ^ Khare, Rohit; Lawrence, Scott (Mai 2000). Upgrade auf TLS innerhalb von HTTP/1.1. Ietf. doi:10.17487/rfc2817. RFC 2817.
  60. ^ "Schwachstellennote VU#150227: HTTP -Proxy -Standardkonfigurationen erlauben beliebige TCP -Verbindungen". US-Cert. 2002-05-17. Abgerufen 2007-05-10.
  61. ^ Dusseault, Lisa; Snell, James M. (März 2010). Patch -Methode für HTTP. Ietf. doi:10.17487/rfc5789. RFC 5789.
  62. ^ "Methode". RFC 2616. p. 36. Sek. 5.1.1. doi:10.17487/rfc2616. RFC 2616.
  63. ^ a b EDIGER, Brad (2007-12-21). Advanced Rails: Bauen von Web-Apps in der Industriestärke in der Aufzeichnungszeit. O'Reilly Media, Inc. p. 188. ISBN 978-0596519728. Ein häufiger Fehler besteht darin, GET für eine Aktion zu verwenden, die eine Ressource aktualisiert. [...] Dieses Problem kam 2005 in das öffentliche Auge von Rails, als das Google Web Accelerator veröffentlicht wurde.
  64. ^ Cantrell, Christian (2005-06-01). "Was haben wir vom Google Web Accelerator gelernt?". Adobe Blogs. Adobe. Archiviert von das Original Am 2017-08-19. Abgerufen 2018-11-19.
  65. ^ Luotonen, Ari; Franks, John (22. Februar 1996). Abruferweiterung von Byte Range auf HTTP. Ietf. I-D Draft-ITF-HTTP-Range-Retrival-00.
  66. ^ Canavan, John (2001). Grundlagen der Networking -Sicherheit. Norwood, MA: Artech House. S. 82–83. ISBN 9781580531764.
  67. ^ Zalewski, Michal. "Browser -Sicherheitshandbuch". Abgerufen 30. April 2015.
  68. ^ "Chrom -Ausgabe 4527: Implementieren Sie RFC 2817: Upgrade auf TLS innerhalb von HTTP/1.1". Abgerufen 30. April 2015.
  69. ^ "Mozilla Bug 276813 - [RFE] Unterstützt RFC 2817 / TLS -Upgrade für HTTP 1.1". Abgerufen 30. April 2015.
  70. ^ Nottingham, Mark (Oktober 2010). Webverbindung. Ietf. doi:10.17487/rfc5988. RFC 5988.
  71. ^ "Hypertext Transfer Protocol Bis (HTTPBIS) - Charter". Ietf. 2012.

Externe Links