knowledgr.de

Hypertext-Übertragungsprotokoll

Neues Wissen!

Das Hypertext-Übertragungsprotokoll (HTTP) ist ein Anwendungsprotokoll für den verteilten, das zusammenarbeitende, die Hypermediainformationssysteme. HTTP ist das Fundament der Datenkommunikation für das World Wide Web. Hypertext ist ein mehrgeradliniger Satz von Gegenständen, ein Netz durch das Verwenden logischer Verbindungen (die so genannten Hypertext-Links) zwischen den Knoten (z.B Text oder Wörter) bauend. HTTP ist das Protokoll, um Hypertext auszutauschen oder zu übertragen.

Die Standardentwicklung von HTTP wurde von Internet Engineering Task Force (IETF) und dem Konsortium des World Wide Web (W3C) koordiniert, in der Veröffentlichung einer Reihe von Bitten um Anmerkungen (RFCs), am meisten namentlich RFC 2616 (Juni 1999) kulminierend, der HTTP/1.1, die Version von HTTP in der üblichen Anwendung definiert.

Technische Übersicht

HTTP fungiert als ein Protokoll der Bitte-Antwort im Client/Server-Rechenmodell. In HTTP handelt ein WWW-Browser zum Beispiel als ein Kunde, während eine Anwendung, die auf einem Computer läuft, der eine Website veranstaltet, als ein Server fungiert. Der Kunde legt eine HTTP-Bitte-Nachricht an den Server vor. Der Server, der Inhalt versorgt, oder Mittel wie HTML-Dateien zur Verfügung stellt, oder andere Funktionen im Auftrag des Kunden durchführt, eine Antwortmeldung dem Kunden zurückgibt. Eine Antwort enthält Vollziehungszustandsinformation über die Bitte und kann jeden Inhalt enthalten, der vom Kunden in seinem Nachrichtenkörper gebeten ist.

Ein WWW-Browser (oder Kunde) wird häufig einen Benutzeragenten (UA) genannt. Andere Benutzeragenten können die Indexieren-Software einschließen, die von Suchversorgern verwendet ist, die als Webkettenfahrzeuge oder Schwankungen des WWW-Browsers wie Stimmenbrowser bekannt sind, die eine interaktive Stimmenbenutzerschnittstelle präsentieren.

HTTP wird entworfen, um Zwischennetzelementen zu erlauben, Kommunikationen zwischen Kunden und Servern zu verbessern oder zu ermöglichen. Websites des hohen Verkehrs ziehen häufig aus Webservern des geheimen Lagers einen Nutzen, die Inhalt im Auftrag des ursprünglichen, so genannten Ursprung-Servers liefern, um Ansprechzeit zu verbessern. HTTP Proxyserver an Netzgrenzen erleichtern Kommunikation, wenn Kunden ohne allgemein routable Adresse in privaten Netzen gelegen werden, indem sie die Bitten und Antworten zwischen Kunden und Servern weitergeben.

HTTP ist ein innerhalb des Fachwerks des Internetprotokoll-Gefolges entworfenes Anwendungsschicht-Protokoll. Die Protokoll-Definitionen wagen ein zuverlässiges Transportschicht-Protokoll für die Gastgeber-zu-Gastgeber-Datenübertragung. Transmission Control Protocol (TCP) ist das dominierende Protokoll im Gebrauch für diesen Zweck. Jedoch hat HTTP Anwendung sogar mit unzuverlässigen Protokollen wie User Datagram Protocol (UDP) in Methoden wie Simple Service Discovery Protocol (SSDP) gefunden.

HTTP Mittel werden identifiziert und im Netz durch Gleichförmige Quellenbezeichner (URIs) — oder, mehr spezifisch, Internetadressen (URL-ADRESSEN) — das Verwenden oder URI Schemas gelegen. URIs und die Hypertext-Preiserhöhungssprache (HTML), bilden Sie ein System von verketteten Mitteln, genannt Hypertext-Dokumente im Internet, das zur Errichtung des World Wide Web 1990 durch den englischen Computerwissenschaftler und Neuerer Tim Berners-Lee geführt hat.

Die ursprüngliche Version von HTTP (HTTP/1.0) wurde in HTTP/1.1 revidiert. HTTP/1.0 verwendet eine getrennte Verbindung zu demselben Server für jede Transaktion der Bitte-Antwort, während HTTP/1.1 eine Verbindung mehrmals wiederverwenden kann, um, zum Beispiel, Images für eine gerade gelieferte Seite herunterzuladen. Folglich erfahren HTTP/1.1 Kommunikationen weniger Latenz, weil die Errichtung von TCP Verbindungen beträchtlich oben präsentiert.

Geschichte

Der Begriff HyperText wurde von Ted Nelson ins Leben gerufen, der der Reihe nach von Vannevar Bush begeistert wurde, hat "memex" mikrofilmgestützt. Tim Berners-Lee hat zuerst das "WorldWideWeb"-Projekt — jetzt bekannt als das World Wide Web vorgeschlagen. Berners-Lee und seiner Mannschaft wird die Erfindung des ursprünglichen HTTP zusammen mit dem HTML und der verbundenen Technologie für einen Webserver und einen textbasierten WWW-Browser zugeschrieben.

Die erste Version des Protokolls hatte nur eine Methode, KOMMEN SIE nämlich, der um eine Seite von einem Server bitten würde. Die Antwort vom Server war immer eine HTML-Seite.

Die erste dokumentierte Version von HTTP war HTTP V0.9 (1991). Dave Raggett hat die HTTP Arbeitsgruppe (HTTP WG) 1995 geführt und hat das Protokoll mit verlängerten Operationen, erweiterter Verhandlung, reicherer Meta-Information ausbreiten wollen, die mit einem Sicherheitsprotokoll gebunden ist, das effizienter durch das Hinzufügen von zusätzlichen Methoden und Kopfball-Feldern geworden ist. RFC 1945 offiziell eingeführter und anerkannter HTTP V1.0 1996.

Der HTTP WG hat geplant, neue Standards im Dezember 1995 zu veröffentlichen, und die Unterstützung für vornormalen HTTP/1.1, der auf dem dann Entwickeln RFC 2068 gestützt ist (hat gerufen HTTP-NG) wurde von den Hauptbrowser-Entwicklern Anfang 1996 schnell angenommen. Vor dem März 1996 wurde vornormaler HTTP/1.1 in der Arena, Netscape 2.0, Netscape Navigator-Gold 2.01, Mosaik-2.7, Luchs 2.5, und in Internet Explorer 2.0 unterstützt. Die Endbenutzer-Adoption der neuen Browser war schnell. Im März 1996 hat eine Webbewirtungsgesellschaft berichtet, dass mehr als 40 % von Browsern im Gebrauch im Internet HTTP 1.1 entgegenkommende waren. Dass dieselbe Webbewirtungsgesellschaft berichtet hat, dass vor dem Juni 1996 65 % aller Browser, die auf ihre Server zugreifen, entgegenkommend HTTP/1.1 waren. Der HTTP/1.1 Standard, wurde wie definiert, RFC 2068 im Januar 1997 offiziell veröffentlicht. Verbesserungen und Aktualisierungen zum HTTP/1.1 Standard wurden unter RFC 2616 im Juni 1999 veröffentlicht.

HTTP Sitzung

Eine HTTP Sitzung ist eine Folge von Netztransaktionen der Bitte-Antwort. Ein HTTP Kunde beginnt eine Bitte, indem er eine Verbindung von Transmission Control Protocol (TCP) zu einem besonderen Hafen auf einem Server herstellt (normalerweise Hafen 80; sieh Liste von TCP und UDP Hafen-Zahlen). Ein HTTP Server, der auf diesem Hafen hört, wartet auf eine Bitte-Nachricht eines Kunden. Nach dem Empfang der Bitte sendet der Server eine Status-Linie, wie "HTTP/1.1 200, OK", und eine Nachricht seines eigenen zurück. Der Körper dieser Nachricht ist normalerweise die gebetene Quelle, obwohl eine Fehlermeldung oder andere Information auch zurückgegeben werden können.

Bitte-Methoden

HTTP definiert neun Methoden (manchmal gekennzeichnet als "Verben") das Anzeigen der gewünschten auf der identifizierten Quelle durchzuführenden Handlung. Was diese Quelle vertritt, ob vorher existierende Daten oder Daten, der dynamisch erzeugt wird, von der Durchführung des Servers abhängen. Häufig entspricht die Quelle einer Datei oder der Produktion eines rechtskräftigen Wohnens auf dem Server.

: Bittet um die Antwort, die zu derjenigen identisch ist, die einer BEKOMMEN Bitte, aber ohne den Ansprechkörper entsprechen würde. Das ist nützlich, um Meta-Information wiederzubekommen, die in Ansprechkopfbällen geschrieben ist, ohne den kompletten Inhalt transportieren zu müssen.

: Bittet um eine Darstellung der angegebenen Quelle. Das Bitte-Verwenden KOMMT sollte nur Daten wiederbekommen und sollte keine andere Wirkung haben. (Das trifft auch auf einige andere HTTP Methoden zu.) Hat der W3C Leitungsgrundsätze auf dieser Unterscheidung veröffentlicht, sagend, "Webanwendungsdesign sollte durch die obengenannten Grundsätze, sondern auch durch die relevanten Beschränkungen informiert werden." Sieh sichere Methoden unten.

: Legt Daten vor, die (z.B, von einer HTML-Form) zur identifizierten Quelle zu bearbeiten sind. Die Daten werden in den Körper der Bitte eingeschlossen. Das kann auf die Entwicklung einer neuen Quelle oder die Aktualisierungen von vorhandenen Mitteln oder beiden hinauslaufen.

: Lädt eine Darstellung der angegebenen Quelle.

: Löscht die angegebene Quelle.

: Echos unterstützen die erhaltene Bitte, so dass ein Kunde sehen kann, was (wenn irgendwelcher) Änderungen oder Hinzufügungen durch Zwischenserver gemacht worden sind.

: Gibt die HTTP Methoden zurück, die der Server für die angegebene URL-ADRESSE unterstützt. Das kann verwendet werden, um die Funktionalität eines Webservers durch die Anforderung '*' statt einer spezifischen Quelle zu überprüfen.

: Wandelt die Bitte-Verbindung zu einem durchsichtigen TCP/IP Tunnel um, um gewöhnlich SSL-encrypted Kommunikation (HTTPS) durch einen unencrypted HTTP Vertretung zu erleichtern.

: Wird verwendet, um teilweise Modifizierungen auf eine Quelle anzuwenden.

HTTP Server sind erforderlich, mindestens das BEKOMMEN und die HAUPT-Methoden und, wann immer möglich, auch die OPTIONS-Methode durchzuführen.

Sichere Methoden

Einige Methoden (zum Beispiel, KOPF, KOMMEN OPTIONEN und SPUR), werden als sicher definiert, was bedeutet, dass sie nur für die Informationsgewinnung beabsichtigt sind und den Staat des Servers nicht ändern sollten. Mit anderen Worten sollten sie nicht Nebenwirkungen, außer relativ harmlosen Effekten wie Protokollierung, das Verstecken, die Portion von Schlagzeile-Anzeigen oder das Erhöhen eines Webschalters haben. Das willkürliche Bilden KOMMT Bitten ohne Rücksicht auf den Zusammenhang des Staates der Anwendung sollten deshalb sicher betrachtet werden.

Im Vergleich LÖSCHEN Methoden wie POSTEN, GESTELLT und sind für Handlungen beabsichtigt, die Nebenwirkungen entweder auf dem Server oder auf Außennebenwirkungen wie Geldgeschäfte oder Übertragung der E-Mail verursachen können. Solche Methoden werden deshalb durch das Anpassen von Webrobotern oder Webkettenfahrzeugen nicht gewöhnlich verwendet; einige, die sich nicht anpassen, neigen dazu, Bitten ohne Rücksicht auf den Zusammenhang oder die Folgen zu machen.

Trotz der vorgeschriebenen Sicherheit dessen BEKOMMEN Bitten, in der Praxis wird ihr Berühren durch den Server in jedem Fall nicht technisch beschränkt. Deshalb kann unbesonnene oder absichtliche Programmierung nichttriviale Änderungen auf dem Server verursachen. Das wird entmutigt, weil es Probleme für das Webverstecken verursachen kann, suchen Sie Motoren und andere automatisierte Agenten, die unbeabsichtigte Änderungen auf dem Server vornehmen können.

Methoden von Idempotent und Webanwendungen

Methoden GESTELLT und LÖSCHEN werden definiert, um idempotent zu sein, bedeutend, dass vielfache identische Bitten dieselbe Wirkung wie eine einzelne Bitte haben sollten (Bemerken Sie, dass sich idempotence auf den Staat des Systems bezieht, nachdem die Bitte so vollendet hat, während die Handlung, die der Server (z.B das Löschen einer Aufzeichnung) oder die Antwort nimmt, es codiert, kann Umsatz auf nachfolgenden Bitten verschieden sein, der Systemstaat wird dasselbe jedes Mal sein.) KOMMEN Methoden, GEHEN, OPTIONEN und SPUR, so sicher vorgeschrieben, sollten auch idempotent sein, wie HTTP ein staatenloses Protokoll ist.

Im Gegensatz ist die POST-Methode nicht notwendigerweise idempotent, und deshalb das Senden einer identischen POST-Bitte kann weiter mehrmals Staat betreffen oder weitere Nebenwirkungen (wie Geldgeschäfte) verursachen. In einigen Fällen kann das wünschenswert sein, aber in anderen Fällen konnte das wegen eines Unfalls, solcher als sein, wenn ein Benutzer nicht begreift, dass ihre Handlung auf das Senden einer anderen Bitte hinauslaufen wird, oder sie entsprechendes Feed-Back nicht erhalten haben, dass ihre erste Bitte erfolgreich war. Während WWW-Browser wachsame Dialog-Kästen zeigen können, um Benutzer in einigen Fällen zu warnen, wo Umladung einer Seite eine POST-Bitte wiedervorlegen kann, ist es allgemein bis zur Webanwendung, um Fälle zu behandeln, wo eine POST-Bitte mehr nicht vorgelegt werden sollte als einmal.

Bemerken Sie, dass, ob eine Methode idempotent ist, durch das Protokoll oder den Webserver nicht beachtet wird. Es ist vollkommen möglich, eine Webanwendung zu schreiben, in der (zum Beispiel) ein Datenbankeinsatz oder andere non-idempotent Handlung durch ein BEKOMMEN oder andere Bitte ausgelöst werden. Das Ignorieren dieser Empfehlung kann jedoch auf unerwünschte Folgen hinauslaufen, wenn ein Benutzeragent annimmt, dass das Wiederholen derselben Bitte sicher ist, wenn es nicht ist.

Sicherheit

Das Einführen von Methoden wie SPUR, SPUR und FEHLERSUCHPROGRAMM wird potenziell unsicher von einigen Sicherheitsfachleuten betrachtet, weil sie von Angreifern verwendet werden können, um Information oder Umleitungssicherheitssteuerungen während Angriffe zu sammeln. Sicherheitssoftwarewerkzeuge wie Haltbarer Nessus und Microsoft URLScan berichten über die Anwesenheit dieser Methoden als seiend Sicherheitsprobleme.

Statuskennzeichen

In HTTP/1.0 und seitdem wird die erste Linie der HTTP Antwort die Status-Linie genannt und schließt ein numerisches Statuskennzeichen (solcher als "404") und ein Textgrund Ausdruck (solcher als "Nicht Gefunden") ein. Auf die Weise behandelt der Benutzeragent die Antwort hängt in erster Linie vom Code und sekundär auf den Ansprechkopfbällen ab. Kundenspezifische Statuskennzeichen können seitdem verwendet werden, wenn der Benutzeragent auf einen Code stößt, erkennt er nicht an, er kann die erste Ziffer des Codes verwenden, um die allgemeine Klasse der Antwort zu bestimmen.

Außerdem drückt der Standardgrund aus sind nur Empfehlungen und kann durch "lokale Entsprechungen" am Webentwickler-Taktgefühl ersetzt werden. Wenn das Statuskennzeichen ein Problem angezeigt hat, könnte der Benutzeragent den Grund Ausdruck dem Benutzer zeigen, um weitere Auskunft über die Natur des Problems zu geben. Der Standard erlaubt auch dem Benutzeragenten zu versuchen, den Grund Ausdruck zu interpretieren, obwohl das unklug sein könnte, da der Standard ausführlich angibt, dass Statuskennzeichen maschinenlesbar sind und schließen, dass Ausdrücke menschlich-lesbar sind.

Beharrliche Verbindungen

In HTTP/0.9 und 1.0 wird die Verbindung nach einem einzelnen Paar der Bitte/Antwort geschlossen. In HTTP/1.1 "bewahren Mechanismus" wurde eingeführt, wo eine Verbindung für mehr als eine Bitte wiederverwendet werden konnte.

Solche beharrlichen Verbindungen reduzieren Bitte-Latenz wahrnehmbar, weil der Kunde die TCP Verbindung nicht neu auszuhandeln braucht, nachdem die erste Bitte gesandt worden ist. Eine andere positive Nebenwirkung besteht darin, dass im Allgemeinen die Verbindung schneller mit der Zeit wegen des langsamen Anfang-Mechanismus von TCP wird.

Die Version 1.1 des Protokolls hat Bandbreite-Optimierungsverbesserungen zu HTTP/1.0 gebildet. Zum Beispiel hat HTTP/1.1 Chunked-Übertragungsverschlüsselung eingeführt, um Inhalt auf beharrlichen Verbindungen zu erlauben, verströmt, anstatt gepuffert zu werden. HTTP pipelining reduziert weiter Verzögerungszeit, Kunden erlaubend, vielfache Bitten zu senden, bevor eine vorherige Antwort zur ersten erhalten worden ist. Eine andere Verbesserung zum Protokoll war Byte-Portion, die ist, wenn ein Server gerade den Teil einer von einem Kunden ausführlich gebetenen Quelle übersendet.

HTTP Sitzungsstaat

HTTP ist ein staatenloses Protokoll. Ein staatenloses Protokoll verlangt nicht, dass der Server Information oder Status über jeden Benutzer für die Dauer von vielfachen Bitten behält. Zum Beispiel, wenn ein Webserver erforderlich ist, den Inhalt einer Webseite für einen Benutzer kundengerecht anzufertigen, kann die Webanwendung den Fortschritt des Benutzers von der Seite bis Seite verfolgen müssen. Eine allgemeine Lösung ist der Gebrauch von HTTP Plätzchen. Andere Methoden schließen Server-Seitensitzungen, verborgene Variablen ein (wenn die aktuelle Seite eine Form enthält), und das URL-ADRESSE-NEUSCHREIBEN mit URI-verschlüsselten Rahmen, z.B.

Sicherer HTTP

Es gibt drei Methoden, eine sichere HTTP Verbindung herzustellen: HTTP Sicheres, Sicheres Hypertext-Übertragungsprotokoll und der HTTP/1.1-Steigungskopfball. Die Browser-Unterstützung für die letzten zwei ist jedoch fast, nicht existierend, so ist Sicherer HTTP die dominierende Methode, eine sichere HTTP Verbindung herzustellen.

Bitte-Nachricht

Die Bitte-Nachricht besteht aus dem folgenden:

Eine Bitte-Linie, zum Beispiel, der um eine vom Server genannte Quelle bittet.
Kopfbälle, wie
Eine leere Linie.
Ein fakultativer Nachrichtenkörper.

Die Bitte-Linie und Kopfbälle müssen alle damit enden

Wie man

akzeptiert, erhält eine Bitte-Linie, die nur den Pfadnamen durch Server enthält, Vereinbarkeit mit HTTP Kunden vor der HTTP/1.0 Spezifizierung RFC 1945 aufrecht.

Antwortmeldung

Die Antwortmeldung besteht aus dem folgenden:

Eine Status-Linie (zum Beispiel, der anzeigt, dass die Bitte des Kunden erfolgreich gewesen ist)

Kopfbälle, wie

Eine leere Linie
Ein fakultativer Nachrichtenkörper

Die Status-Linie und Kopfbälle müssen alle mit CR+LF (eine Wagen-Rückkehr enden, die von einem Linienfutter gefolgt ist). Die leere Linie muss aus nur CR+LF und keinem anderen whitespace bestehen.

Beispiel-Sitzung

Unten ist ein Beispielgespräch zwischen einem HTTP Kunden und einem HTTP Server, der auf www.example.com, Hafen 80 läuft.

Kundenbitte

KOMMEN SIE /index.html

HTTP/1.1␍␊

Gastgeber:

www.example.com␍␊ ␍␊ </pre>

Einer Kundenbitte (in diesem Fall aus der Bitte-Linie und dem nur einem Kopfball bestehend), wird von einer leeren Linie gefolgt, so dass die Bitte mit einem doppelten newline, jedem in der Form einer von einem Linienfutter gefolgten Wagen-Rückkehr endet. Der "Gastgeber"-Kopfball unterscheidet zwischen dem verschiedenen DNS-Namenteilen einer einzelnen IP-Adresse, namenbasierte virtuelle Bewirtung erlaubend. Während fakultativ, in HTTP/1.0 ist es in HTTP/1.1 obligatorisch.

Server-Antwort

HTTP/1.1 200, OK

Datum: Montag, der 23. Mai 2005 22:38:34 Uhr GMT

Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)

Letzt modifiziert: Wed, 08 2003-23:11:55 Uhr GMT von Jan

Etag: "3f80f-1b6-3e1cb03b"

Akzeptieren-Reihen: niemand

Zufriedene Länge: 438

Verbindung: naher

Zufriedener Typ: Text/HTML; charset=UTF-8

</pre>

Der ETag (Entitätsanhängsel) Kopfball wird verwendet, um zu bestimmen, ob eine versteckte Version der gebetenen Quelle zur jetzigen Version der Quelle auf dem Server identisch ist. Zufriedener Typ gibt das Internetsektorformat der durch die HTTP Nachricht beförderten Daten an, während Zufriedene Länge seine Länge in Bytes anzeigt. Der HTTP/1.1 webserver veröffentlicht seine Fähigkeit, auf Bitten um bestimmte Byte-Reihen des Dokumentes durch das Setzen der Kopfball-Akzeptieren-Reihen zu antworten: Bytes. Das ist nützlich, wenn der Kunde nur bestimmte Teile einer Quelle haben muss, die durch den Server gesandt ist, der Byte-Portion genannt wird. Wenn Verbindung: Nahe wird in einem Kopfball gesandt, es bedeutet, dass der Webserver die TCP Verbindung sofort nach der Übertragung dieser Antwort schließen wird.

Die meisten Kopfball-Linien sind fakultativ. Wenn Zufriedene Länge fehlt, wird die Länge auf andere Weisen bestimmt. Übertragungsverschlüsselung von Chunked verwendet eine Klotz-Größe 0, um das Ende des Inhalts zu kennzeichnen. Die Identitätsverschlüsselung ohne Zufriedene Länge liest Inhalt, bis die Steckdose geschlossen wird.

Eine Inhalt-Verschlüsselung wie gzip kann verwendet werden, um die übersandten Daten zusammenzupressen.

Siehe auch

HTTP Ersatz oder Erhöhungen

Vertretungsstaatsübertragung (REST)
SPDY - Eine HTTP Erhöhung, die von Google vorgeschlagen ist
Waka (Protokoll) - Ein HTTP Ersatz, der von Roy Fielding vorgeschlagen ist
HTTP-MPLEX - Eine umgekehrt vereinbare Erhöhung zu HTTP, um Seite und Web zu verbessern, wendet Wiederauffindungszeit mit überfüllten Netzen ein, die von Robert Mattson vorgeschlagen sind
HTTP 2.0 - zurzeit auf durch das Hypertext-Übertragungsprotokoll des IETF Arbeitsgruppe von Bis (httpbis) gearbeitet werden.