{"id":942,"date":"2018-03-02T12:29:33","date_gmt":"2018-03-02T12:29:33","guid":{"rendered":"http:\/\/enginsight.com\/?p=942"},"modified":"2023-10-26T14:05:17","modified_gmt":"2023-10-26T12:05:17","slug":"http-ein-blick-hinter-die-kulissen-des-internets","status":"publish","type":"post","link":"https:\/\/enginsight.com\/de\/blog\/http-ein-blick-hinter-die-kulissen-des-internets\/","title":{"rendered":"HTTP: Ein Blick hinter die Kulissen des Internets"},"content":{"rendered":"

Wenn man genauer darüber nachdenkt, grenzt es eigentlich schon fast an Magie. Man gibt eine Zeichenkette in die Adresszeile seines Browsers ein, drückt einmal kurz auf Enter und schon sieht man den Wetterbericht für das Wochenende oder die neuesten Fußballergebnisse. Aber haben Sie schon einmal darüber nachgedacht, was alles im Hintergrund abläuft, bis Sie zu Ihrem Leidwesen feststellen müssen, dass der TSV Grünkraut schon wieder verloren hat? HTTP spielt dabei eine zentrale Rolle.<\/em><\/p>\n\n\n\n

Das HTTP Protokoll<\/h2>\n\n\n\n

Als normaler Benutzer nimmt man es kaum wahr, stünde es nicht am Anfang so vieler URLs, dabei beruht die Kommunikation im gesamten World Wide Web auf dem HTTP Protokoll. In diesem Artikel wollen wir uns daher den sogenannten HTTP Request-Response-Zyklus <\/strong>genauer ansehen, also alles was von der Eingabe der URL bis zum Anzeigen der Webseite im Browser, im Hintergrund abläuft.<\/p>\n\n\n\n

HTTP Nachrichten: Request & Response<\/h3>\n\n\n\n

HTTP<\/strong> steht für „Hypertext Transfer Protocol“. Mittlerweile wird es hauptsächlich dazu verwendet Webseiten aus dem WWW in einen Webbrowser zu laden. Die „Kommunikationseinheiten“ in HTTP werden als Nachrichten bezeichnet. Prinzipiell gibt es zwei unterschiedliche Arten von HTTP Nachrichten. Die Anfrage<\/em> (bzw. Request<\/em>)<\/strong> geht vom Benutzer (in diesem Zusammenhang oft Client<\/em> <\/strong>genannt) an den Server. Die Antwort<\/em> (bzw. Response<\/em>)<\/strong> geht als Reaktion darauf vom Server <\/strong>zum Benutzer. Sehen wir uns dazu ein Beispiel an.<\/p>\n\n\n\n

Ein Benutzer (nennen wir ihn Herbert) möchte eine Webseite aufrufen, z.B. den Steine & Unkraut Onlineshop. Herbert möchte sich die neu hinzugekommenen Produkte ansehen und zwar aus der Kategorie „Steine“. Er tippt daher folgende URL in seinen Browser ein: http:\/\/www.SteineundUnkraut.org \/Neu\/Steine.html<\/code>Der Browser sendet daraufhin eine HTTP Anfrage an den Server, auf dem die Webseite des Onlineshops liegt. Dieser verarbeitet die Anfrage und sendet eine HTTP Antwort. Aber wie sieht so eine HTTP Nachricht konkret aus?<\/p>\n\n\n\n

HTTP Nachrichten: Aufbau<\/h3>\n\n\n\n

Eine typische HTTP Nachricht besteht aus 3 Teilen, der Start-Line<\/em>, dem Nachrichtenkopf (bzw. Header<\/em>) und dem Nachrichtenrumpf (bzw. Body<\/em>). Die Informationen, die in diesen drei Teilen stehen, sind abhängig davon ob die HTTP Nachricht eine HTTP Anfrage oder eine HTTP Antwort ist.<\/p>\n\n\n\n

HTTP Anfrage<\/h3>\n\n\n\n

Die Start-Line<\/strong> in einer HTTP Anfrage enthält zunächst die Methode<\/em>, ein Kommando, das dem Server sagt, was er eigentlich tun soll. Zwei sehr bekannte Beispiele für HTTP Methoden sind zum einen GET<\/em> (sagt dem Server, dass er Daten an den Benutzer senden soll) und POST<\/em> (sagt dem Server, dass er Daten in der Datenbank speichern soll). In unserem Beispiel wäre die Methode also GET<\/em>, da Herberts Browser vom Server Daten (die Webseite) anfordert.<\/p>\n\n\n\n

Als nächstes in der Start-Line steht die URI<\/em>, nicht zu verwechseln mit der URL<\/em>. URIs werden zur Identifizierung benutzt und URLs zur Lokalisierung. Aber Vorsicht, Lokalisierung bedeutet gleichzeitig auch Identifizierung. Zum Beispiel kann man einen Menschen ja auch anhand seines Wohnorts identifizieren. Es sind also alle URLs gleichzeitig URIs. Es gibt allerdings URIs, die keine URLs sind. Z.B. ist SteineundUnkraut.org<\/code> eine URI und http:\/\/www.SteineundUnkraut.org<\/code> eine URL, da die Webseite nicht nur identifiziert wird, sondern HTTP uns auch zeigt, wo die Ressource (die Webseite) ist.<\/p>\n\n\n\n

Zum Schluss der Start-Line teilt der Browser noch mit, welche HTTP Version<\/em> er benutzt. Die Start-Line aus unserem Beispiel könnte also so aussehen: GET \/Neu\/Steine.html HTTP 1.0<\/code><\/p>\n\n\n\n

Die Anfrage Header<\/strong> sind im Prinzip Paare, bestehend aus einem Namen (Groß- und Kleinschreibung müssen beachtet werden), gefolgt von einem Doppelpunkt und einem Wert. Header spezifizieren bestimmte Regeln und Informationen, z.B. den Host. Das ist die Adresse des Servers, an den wir die Anfrage schicken. In den Headern kann man aber z.B. auch spezifizieren, welche Sprache der Client als Antwort akzeptiert (Accept-Language<\/em>). Die Request Header in unserem Beispiel könnten also so aussehen:
Host: www.SteineundUnkraut.org<\/code>
Accept-Language: de<\/code><\/p>\n\n\n\n

Einen HTTP Anfrage Body<\/strong> brauchen wir an dieser Stelle, in unserem Beispiel nicht.<\/p>\n\n\n\n

HTTP Antwort<\/h3>\n\n\n\n

In der Start-Line<\/strong> der HTTP Antwort gibt es keine Methode oder URI. Hier haben wir nur die HTTP Version<\/em> und einen Status Code<\/em>. Dieser Status Code sagt dem Benutzer, ob die Anfrage erfolgreich war oder fehlgeschlagen ist. Status Code 200<\/em> gibt „OK“<\/em>zurück und bedeutet, dass die Anfrage erfolgreich bearbeitet wurde und das Ergebnis in der Antwort übertragen wird. Der Code dagegen, den wohl jeder Internetbenutzer kennt: 404<\/em> gibt „not found“<\/em> zurück und bedeutet, dass die angeforderte Ressource nicht gefunden wurde. Es gibt aber noch viele andere.<\/p>\n\n\n\n

Status Code 418<\/em> gibt z.B. zurück „I’m a teapot“<\/em> und zeigt an, dass der Server sich weigert Kaffee zu kochen, da er eine Teekanne ist. Diese Fehlermeldung ist Teil des „Hyper Text Coffee Pot Control Protocol“ und war als Erweiterung für HTTP gedacht – aber nur als Aprilscherz. Dennoch wurde der Fehler von humorvollen Entwicklern auch in bekannte Software-Projekte implementiert (z.B. Googles Programmiersprache Go).<\/p>\n\n\n\n

Die Antwort Header<\/strong> haben das gleiche Format wie die Anfrage Header. Allerdings kann man damit andere Informationen und Regeln spezifizieren. Zum Beispiel den Zeitpunkt des Absendens (Date<\/em>) oder Informationen über den verwendeten Webserver. Die Response Header in unserem Beispiel könnten also z.B. so aussehen:
Date: Tue, 27 Feb 2018 08:12:31 GMT<\/code>
Server: Apache\/1.3.27 (Unix) (Red-Hat\/Linux)<\/code><\/p>\n\n\n\n

Der Antwort Body<\/strong> enthält dann die gewünschten Daten, also die Webseite.<\/p>\n\n\n\n

Je nach Methode, HTTP Version, etc. muss<\/em> man andere oder aber auch gar keine Header senden. Man kann<\/em> aber aus den offiziellen, im HTTP-Standard definierten Headern so viele auswählen und senden, wie man für nötig erachtet. In der Regel gibt es übrigens nicht nur eine HTTP Anfrage und HTTP Antwort, sondern mehrere. Zum Beispiel für ein Bild, das sich auf der Webseite befindet, gibt es nochmal einen extra Austausch.<\/p>\n\n\n\n

IT-Sicherheit durch HTTP Header<\/h3>\n\n\n\n

HTTP Header spielen auch aus sicherheitstechnischen Aspekten eine große Rolle. Sie sind z.B. ein einfaches Mittel die Besucher einer Webseite aktiv zu schützen. <\/p>\n\n\n\n

Wie genau das funktioniert und welche HTTP-Header Sie unbedingt setzen sollten, erfahren Sie in einem unserer nächsten Blogposts: Datensicherheit: Benötige ich HTTPS?<\/strong><\/a><\/p>\n\n\n\n

Sofern Sie jetzt gleich schon prüfen möchten, ob diese wichtigen Header bei Ihnen gesetzt sind, registrieren Sie sich bei Enginsight und testen Sie unsere Plattform 14 Tage lang kostenlos.<\/p>\n","protected":false},"excerpt":{"rendered":"

Wenn man genauer darüber nachdenkt, grenzt es eigentlich schon fast an Magie. Man gibt eine Zeichenkette in die Adresszeile seines Browsers ein, drückt einmal kurz auf Enter und schon sieht man den Wetterbericht für das Wochenende oder die neuesten Fußballergebnisse. Aber haben Sie schon einmal darüber nachgedacht, was alles im Hintergrund abläuft, bis Sie zu […]<\/p>\n","protected":false},"author":8,"featured_media":943,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"content-type":"","_eb_attr":"","footnotes":""},"categories":[10],"tags":[],"class_list":["post-942","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-endpoint-netzwerksicherheit"],"_links":{"self":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/942","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/comments?post=942"}],"version-history":[{"count":0,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/942\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/media\/943"}],"wp:attachment":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/media?parent=942"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/categories?post=942"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/tags?post=942"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}