Hypertext Transfer Protocol

Hypertext Transfer Protocol Information
Funktion Hypertext- Übertragung
Akronym HTTP
Erstellungsdatum 1990
Hafen 80
RFC 1996  : RFC 1945
1997  : RFC 2068
1999  : RFC 2616
2014  : RFC 7230 bis 7237
2015  : RFC 7540

Das ' Hypertext Transfer Protocol (HTTP, wörtlich "Transfer ProtocolHypertext ") ist einClient-Server-Kommunikationsprotokoll, das für das World Wide Web entwickelt wurde . HTTPS(mit S für gesichert , also „sicher“) ist die sichere Variante der Verwendung von Transport Layer Security (TLS) Protokolle.

HTTP ist ein Protokoll der Anwendungsschicht . Es kann auf jeder zuverlässigen Verbindung funktionieren, tatsächlich wird das TCP- Protokoll als Transportschicht verwendet. Ein HTTP-Server verwendet dann standardmäßig Port 80 (443 für HTTPS).

Die bekanntesten HTTP-Clients sind Webbrowser, die es einem Benutzer ermöglichen, auf einen Server zuzugreifen, der die Daten enthält. Es gibt auch Systeme zum automatischen Abrufen von Inhalten von einer Website, wie beispielsweise Website-Staubsauger oder Crawler .

Historisch

HTTP wurde von Tim Berners-Lee mit Webadressen und HTML erfunden , um das World Wide Web zu schaffen . Zu diesem Zeitpunkt war das File Transfer Protocol (FTP) bereits für die Übertragung von Dateien verfügbar, unterstützte jedoch nicht das Konzept des Datenformats, wie es von Multipurpose Internet Mail Extensions (MIME) eingeführt wurde. Die erste Version von HTTP war sehr einfach, enthielt jedoch bereits Unterstützung für MIME-Header, um übertragene Daten zu beschreiben. Diese erste Version ist heute noch teilweise nutzbar, bekannt als HTTP / 0.9.

Im Mai 1996, HTTP / 1.0 ist freigegeben und in RFC  1945 beschrieben . Diese Version unterstützt virtuelle HTTP-Server, Cache-Verwaltung und -Identifikation.

Im Januar 1997, HTTP / 1.1 wird schließlich ein IETF - Standard . Es wird in RFC  2068 der IETF beschrieben, dann in RFC  2616 inJuni 1999. Diese Version fügt Unterstützung für Pipelining (oder Pipelining) und Inhaltstyp-Aushandlung (Datenformat, Sprache) hinzu.

Im März 2012, die Arbeit an HTTP / 2.0 beginnt bei der IETF mit SPDY als Ausgangsmaterial.

Im Februar 2014, wurde die Spezifikation für HTTP 1.1 neu veröffentlicht. Es wurde in mehrere RFCs aufgeteilt und für all seine Ungenauigkeiten korrigiert, RFC  7230 bis RFC  7237.

Implementierung

Methoden

Im HTTP-Protokoll ist eine Methode ein Befehl , der eine Art von Anforderung angibt, das heißt, sie fordert den Server auf, eine Aktion auszuführen. Im Allgemeinen betrifft die Aktion eine Ressource, die durch die URL nach dem Namen der Methode identifiziert wird .

In der nebenstehenden Abbildung wird eine GET-Anfrage gesendet, um die Homepage der Website www.perdu.com abzurufen:

GET / HTTP/1.1 Host: www.perdu.com

Es gibt viele Methoden, die häufigsten sind GET, HEAD und POST:

GET Dies ist die gebräuchlichste Methode zum Anfordern einer Ressource. Ein GET-Request hat keine Auswirkung auf die Ressource, der Request muss wirkungslos wiederholt werden können. HEAD Diese Methode fordert nur Informationen über die Ressource an, ohne nach der Ressource selbst zu fragen. POST Diese Methode wird verwendet, um Daten zur Verarbeitung an eine Ressource zu übertragen (meistens aus einem HTML-Formular). Der bereitgestellte URI ist der URI einer Ressource, für die die gesendeten Daten gelten. Das Ergebnis kann die Erstellung neuer Ressourcen oder die Modifikation bestehender Ressourcen sein. Aufgrund der schlechten Implementierung von HTTP-Methoden (für Ajax ) durch einige Browser (und des HTML- Standards, der nur GET- und POST-Methoden für Formulare unterstützt), wird diese Methode oft als Ersatz für die PUT-Anfrage verwendet, die zum Aktualisieren verwendet werden sollte Ressourcen. OPTIONS Diese Methode wird verwendet, um die Kommunikationsmöglichkeiten einer Ressource oder des Servers im Allgemeinen zu erhalten. CONNECT Diese Methode ermöglicht die Verwendung eines Proxys als Kommunikationstunnel. TRACE Diese Methode fordert den Server auf, die empfangenen Daten zurückzugeben, um die Verbindung zu testen und zu diagnostizieren. PUT Mit dieser Methode können Sie eine Ressource auf dem Server ersetzen oder hinzufügen. Der bereitgestellte URI ist der der betreffenden Ressource. PATCH Diese Methode ermöglicht im Gegensatz zu PUT eine teilweise Änderung einer Ressource. DELETE Mit dieser Methode können Sie eine Ressource vom Server löschen.

Diese letzten 3 Methoden erfordern im Allgemeinen privilegierten Zugriff.

Einige Server erlauben andere Methoden zur Verwaltung ihrer Ressourcen (z. B. WebDAV ).

Vom Client zum Server

Die Verbindung zwischen Client und Server ist nicht immer direkt, es können zwischengeschaltete Maschinen als Relais dienen:

Identifizierung

HTTP ermöglicht die Identifizierung des Besuchers durch die Übermittlung eines Namens und eines Passworts . Es gibt 2 Identifikationsmodi: Basic und Digest ( RFC  2617). Der erste Modus überträgt das Passwort unverschlüsselt und sollte daher nur mit dem HTTPS-Protokoll verwendet werden. Der zweite Modus ermöglicht eine Identifizierung ohne Übertragung des Passworts in Klarschrift. Die Identifizierung wird jedoch häufig von einer höheren Anwendungsschicht als HTTP durchgeführt.

HTTP-Serverliste

Versionen

HTTP 0.9

Zu Beginn des World Wide Web war geplant, das HTTP-Protokoll um Funktionen zur Aushandlung von Inhalten zu erweitern, insbesondere in Anlehnung an MIME . Bis dahin war das HTTP 0.9-Protokoll äußerst unkompliziert.

  1. HTTP-Client- Verbindung
  2. Senden einer Methodenanfrage GET
  3. HTTP - Server - Antwort
  4. der Server schließt die Verbindung, um das Ende der Antwort zu signalisieren.

Anfrage:

GET /page.html

Die Methode GETist die einzig mögliche. Der Server erkennt, dass es sich um eine HTTP 0.9-Anfrage handelt, da die Version nicht hinter dem URI angegeben ist.

Antworten :

<html> <head> <title>Exemple</title> </head> <body> <p>Ceci est une page d'exemple.</p> </body> </html>

Um auf eine HTTP 0.9-Anfrage zu antworten, sendet der Server den Inhalt der Antwort direkt ohne Metadaten. Es sollte sich bei HTTP-Anforderungen höherer Versionen niemals so verhalten.

Sie müssen nicht nach Versionen unter 0.9 des HTTP-Protokolls suchen: Sie existieren nicht, da HTTP 0.9 ursprünglich keine Versionsnummer hatte. Es musste eine zugewiesen werden, als HTTP 1.0 ankam.

HTTP 1.0

Das in RFC  1945 beschriebene HTTP 1.0-Protokoll sieht die Verwendung von in RFC  822 spezifizierten Headern vor. Die Verbindungsverwaltung bleibt identisch zu HTTP 0.9: Der Client baut die Verbindung auf, sendet eine Anfrage, der Server antwortet und schließt die Verbindung sofort.

Eine HTTP-Anfrage hat das folgende Format:

Ligne de commande (Commande, URL, Version de protocole) En-tête de requête [Ligne vide] Corps de requête

HTTP-Antworten haben das folgende Format:

Ligne de statut (Version, Code-réponse, Texte-réponse) En-tête de réponse [Ligne vide] Corps de réponse

Anfrage:

GET /page.html HTTP/1.0 Host: example.com Referer: http://example.com/ User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Die HTTP-Protokollversion wird nach dem URI angegeben. Die Anfrage muss mit einem doppelten Zeilenumbruch ( CRLFCRLF ) abgeschlossen werden. HTTP 1.0 unterstützt auch die Methoden HEAD und POST. Wir können die Verwendung von MIME- inspirierten Headern sehen , um Metadaten zu übertragen:

Host Wird verwendet, um die von der Anfrage betroffene Website anzugeben , was für einen Server erforderlich ist, der mehrere Websites unter der gleichen IP-Adresse hostet ( namensbasierter virtueller Host ). Dies ist der einzige wirklich wichtige Header. Referer Gibt den URI des Dokuments an, das einen Link zur angeforderten Ressource gegeben hat. Dieser Header ermöglicht es Webmastern zu sehen, woher die Besucher kommen. User-Agent Zeigt die zum Verbinden verwendete Software an. Normalerweise ist dies ein Webbrowser oder ein Webcrawler .

Antworten :

HTTP/1.0 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Server: Apache/0.8.4 Content-Type: text/html Content-Length: 59 Expires: Sat, 01 Jan 2000 00:59:59 GMT Last-modified: Fri, 09 Aug 1996 14:21:40 GMT <TITLE>Exemple</TITLE> <P>Ceci est une page d'exemple.</P>

Die erste Zeile enthält den HTTP-Statuscode (hier 200).

Date Zeitpunkt, zu dem die Nachricht generiert wird. Server Gibt an, welches HTTP- Servermodell auf die Anfrage antwortet. Content-Type Gibt den MIME- Typ der Ressource an. Content-Length Gibt die Größe der Ressource in Byte an. Expires Gibt an, wann die Ressource als veraltet betrachtet werden sollte; ermöglicht Web - Browser , wie lange zu bestimmen , cachen die Ressource . Last-Modified Gibt das letzte Änderungsdatum der angeforderten Ressource an. HTTP 1.1

Das HTTP 1.1-Protokoll wird durch RFC  2616 beschrieben, wodurch RFC  2068 obsolet wird. Der Unterschied zu HTTP 1.0 ist eine bessere Cache-Verwaltung. Der Host- Header wird in Anfragen obligatorisch.

Die Hauptanliegen der ersten beiden Versionen des HTTP-Protokolls sind zum einen die große Anzahl von Verbindungen beim Laden einer komplexen Seite (mit vielen Bildern oder Animationen) und zum anderen die Öffnungszeit einer "Verbindung zwischen Client". und Server (das Herstellen einer TCP-Verbindung dauert die dreifache Latenz zwischen Client und Server). Experimente mit persistenten Verbindungen wurden jedoch mit HTTP 1.0 durchgeführt (insbesondere durch die Verwendung des Connection: Keep-Alive- Headers ), dies wurde jedoch erst mit HTTP 1.1 endgültig entwickelt.

HTTP 1.1 verwendet standardmäßig persistente Verbindungen, d. h. die Verbindung wird nach einer Anfrage nicht sofort geschlossen, sondern bleibt für eine neue Anfrage verfügbar. Diese Funktion wird oft als Keep-Alive bezeichnet . Es ist einem HTTP-Client auch erlaubt, mehrere Anfragen über dieselbe Verbindung zu senden, ohne auf Antworten zu warten. Diese Funktion wird als Pipelining bezeichnet . Die Persistenz der Verbindungen ermöglicht es, das Laden von Seiten mit mehreren Ressourcen zu beschleunigen und gleichzeitig die Belastung des Netzwerks zu reduzieren.

Die Verwaltung der Persistenz einer Verbindung erfolgt über den Connection- Header .

HTTP 1.1 unterstützt die Inhaltsaushandlung. Ein HTTP 1.1-Client kann die Anforderung einer Ressource von Headern begleiten, die angeben, welche Sprachen und Datenformate bevorzugt werden. Dies sind Header, deren Namen mit Accept- beginnen .

Zusätzliche Header, die von HTTP 1.1 unterstützt werden, sind:

Connection Dieser Header kann vom Client oder Server gesendet werden und enthält eine Liste mit Namen, die die Optionen für die aktuelle Verbindung angeben. Wenn eine Option Parameter hat, werden diese durch den Header mit dem gleichen Namen wie die Option angegeben ( Keep-Alive zum Beispiel, um die maximale Anzahl von Anfragen pro Verbindung anzugeben). Der Name close ist reserviert, um anzugeben, dass die Verbindung nach der Verarbeitung der aktuellen Anfrage geschlossen werden soll. Accept Dieser Header listet die vom Client akzeptierten MIME-Inhaltstypen auf. Das Sternzeichen * kann verwendet werden, um alle Typen / Untertypen anzugeben. Accept-Charset Gibt die akzeptierten Zeichencodierungen an. Accept-Language Gibt die akzeptierten Sprachen an.

Die Präferenzreihenfolge jeder Option (Typ, Kodierung oder Sprache) wird durch den optionalen Parameter q angegeben , der einen Dezimalwert zwischen 0 ( nicht akzeptabel ) und 1 ( akzeptierbar ) einschließlich (maximal 3 Dezimalstellen nach dem Komma) enthält, gleich 1 containing standardmäßig.

Die Unterstützung für persistente Verbindungen muss auch in Fällen funktionieren, in denen die Größe der Ressource nicht im Voraus bekannt ist (Ressource dynamisch vom Server generiert, Fluss außerhalb des Servers usw.).

Dazu ermöglicht die Übertragungscodierung namens chunked, dass die Ressource in aufeinanderfolgenden Teilen übertragen wird, denen jeweils eine Textzeile vorangestellt ist, die ihre Größe in hexadezimaler Form angibt. Die Übertragung endet dann mit einem Chunk der Größe Null, an den die endgültigen Header gesendet werden können.

Die zusätzlichen Header im Zusammenhang mit dieser Übertragungscodierung sind:

Transfer-Encoding Gibt die Übertragungscodierung an. Der einzige von der RFC  2616- Spezifikation definierte Wert ist chunked . Trailer Listet alle Header auf, die nach dem letzten übertragenen Song erscheinen. TE Wird vom Client gesendet, um die unterstützten Inhaltskodierungen ( Content-Encoding , nicht zu verwechseln mit Transfer-Encoding , da chunked von Clients und Servern, die den HTTP / 1.1-Standard implementieren) zwingend unterstützt wird, zu spezifizieren und gibt an, ob der Client dies unterstützt. - Trailer Kopf durch Hinzufügen von Trailern zur Liste. HTTP 1.1 bis

RFC  2616 enthielt viele Ungenauigkeiten. Die HTTP-Arbeitsgruppe brauchte einige Jahre, um die Spezifikation zu klären, ohne die Semantik zu ändern, wie in der Betriebscharta der Gruppe für diese Arbeit empfohlen. ImJuni 2014, wurden 8 neue Dokumente veröffentlicht, die RFC  2616 obsolet machen :

HTTP / 2

Eine neue Version von HTTP, HTTP/2, wurde innerhalb der Arbeitsgruppe Hypertext Transfer Protocol Bis (httpbis) der Internet Engineering Task Force entwickelt und als RFC-Standard weiter genehmigt.18. Februar 2015. Die Entwicklung von HTTP / 2 begann nach der Erstellung des von Google vorgeschlagenen SPDY- Protokolls , um die Ladezeit von Webseiten zu verkürzen. Die httpbis-Arbeitsgruppe verzichtete zunächst darauf, eine neue Version von HTTP vorzuschlagen und konzentrierte ihre Tätigkeit auf die Klärung der Spezifikationen von HTTP 1.1. In Anbetracht der Einführung von SPDY und seiner schnellen Verbreitung im Web, mit insbesondere Implementierungen in zwei der wichtigsten Webbrowser , Google Chrome und Mozilla Firefox , äußerte Mark Nottingham, „Vorsitzender“ von httpbis, dass es an der Zeit sei, HTTP / 2 und schlug vor, die httpbis-Charta in diese Richtung zu ändern und damit die Entwicklung des neuen Protokolls einzuleiten.

SPDY war eine natürliche Option, um als Grundlage für HTTP / 2 zu dienen. Zwei weitere konkurrierende Vorschläge wurden daraufhin an die IETF geschickt: das Protokoll „HTTP Speed ​​+ Mobility“ von Microsoft und ein Vorschlag zur Aktualisierung von HTTP („Network-Friendly HTTP Upgrade“). ImJuli 2012, httpbis hat einen Aufruf zur Interessenbekundung („Aufruf zur Interessenbekundung“) veröffentlicht, um die Meinungen von Web-Playern zu den Vorschlägen einzuholen. Unter den erhaltenen Antworten ist die von Facebook, das seine Präferenz für SPDY angab. ImNovember 2012veröffentlichte die IETF den ersten Entwurf von HTTP/2, der eine direkte Kopie von SPDY ist.

Nach mehr als 2 Jahren Diskussion wird der RFC genehmigt in Februar 2015 von der IETF-Lenkungsgruppe und wird veröffentlicht in Mai 2015.

Das Modul zur Unterstützung des HTTP/2-Protokolls ist seit Version 2.4.17 des Apache-Webservers und seit Version 1.9.5 von Nginx verfügbar.

HTTP / 3

Eine neue Version von HTTP, HTTP / 3, ist die dritte und nächste Hauptversion des Hypertext-Übertragungsprotokolls, das zum Austausch von Informationen im World Wide Web verwendet wird. Diese basiert auf dem QUIC-Protokoll, das 2012 von Google entwickelt wurde.

Die HTTP-Semantik ist von Version zu Version konsistent. Dies liegt daran, dass in der Regel für alle Versionen die gleichen Abfragemethoden, Statuscodes und Nachrichtenfelder gelten.

Während HTTP / 1 und HTTP / 2 beide TCP als Transportprotokoll verwenden, verwendet HTTP / 3 QUIC, ein für das Web besser geeignetes Transportschichtprotokoll. Der Wechsel zu QUIC zielt darauf ab, ein großes Problem von HTTP/2 namens "Head-of-line-Blocking" dank einer Kapselung der Pakete in UDP zu lösen. Tatsächlich besteht bei HTTP / 2 auf TCP-Basis eine Verbindung aus mehreren Streams. Diese Verbindung wird als Multiplex bezeichnet. Wenn bei einem Stream jedoch ein Paketverlust auftritt, wird die gesamte Verbindung verlangsamt. Mit HTTP / 3 basierend auf dem QUIC-Protokoll haben wir dieses Problem nicht mehr, da alle Flüsse unabhängig voneinander in UDP gekapselt sind, einem Transportprotokoll, das keine Verbindung erfordert.

Hinweise und Referenzen

  1. (en) Antrag auf Kommentare n o  1945 .
  2. (en) Antrag auf Kommentare n o  2068 .
  3. (en) Antrag auf Kommentare n o  2616 .
  4. (en) Antrag auf Kommentare n o  7230 .
  5. (en) Bitte um Stellungnahme n o  7237 .
  6. (in) Antrag auf Kommentare n o  2617 .
  7. (in) Antrag auf Kommentare n o  822 .
  8. (in) Antrag auf Kommentare n o  7231 .
  9. (in) Antrag auf Kommentare n o  7232 .
  10. (in) Antrag auf Kommentare n o  7233 .
  11. (in) Antrag auf Kommentare n o  7234 .
  12. (in) Antrag auf Kommentare n o  7235 .
  13. (in) Antrag auf Kommentare n o  7236 .
  14. (in) „  Hypertext Transfer Protocol Bis (httpbis)  “ auf datatracker.ietf.org (Zugriff am 14. November 2013 )
  15. (in) "  HTTP / 2 Approved  " auf www.ietf.org (abgerufen am 19. Februar 2015 )
  16. (in) "  SPDY: Ein experimentelles Protokoll für ein schnelleres Web  " (Zugriff am 14. November 2013 )
  17. "  SPDY-Protokoll (Internetentwurf)  " ,Februar 2012
  18. (in) Mark Nottingham, „  Rechartering HTTPbis  “ auf listen.w3.org ,24. Januar 2012(Zugriff am 14. November 2013 )
  19. (in) "  HTTP Speed ​​+ Mobility (Internetentwurf)  " ,15. Juni 2012
  20. (in) "  Vorschlag für ein netzwerkfreundliches HTTP-Upgrade  " ,29. März 2012
  21. (in) "  Aufruf zur Interessenbekundung  " auf ietf.org ,3. Juli 2012
  22. (in) "  HTTP2 Interessensbekundung  " ,15. Juli 2012
  23. (de) Dio Synodinos, "  HTTP 2.0 Erster Entwurf veröffentlicht  " auf InfoQ ,30. November 2012
  24. "  Apache-Modul mod_http2  " , unter https://httpd.apache.org/
  25. (en-US) "  HTTP / 2 wird in Open Source NGINX 1.9.5 unterstützt  " , auf NGINX ,22. September 2015(Zugriff am 3. Juli 2019 )

Siehe auch

Zum Thema passende Artikel

Externe Links