Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Tools & Tips
Code

HTTP: Das Protokoll, das jeder Webentwickler kennen muss - Teil 2

by
Difficulty:IntermediateLength:LongLanguages:

German (Deutsch) translation by Władysław Łucyszyn (you can also view the original English article)

In meinem vorherigen Artikel haben wir einige Grundlagen von HTTP behandelt, wie das URL-Schema, Statuscodes und Request / Response-Header.  Als Grundlage werden wir uns die feineren Aspekte von HTTP ansehen, wie zum Beispiel Verbindungsbehandlung, Authentifizierung und HTTP-Caching.  Diese Themen sind ziemlich umfangreich, aber wir werden die wichtigsten Punkte behandeln. 

HTTP-Verbindungen

Bevor sie miteinander kommunizieren können, muss eine Verbindung zwischen dem Client und dem Server hergestellt werden, und HTTP verwendet das zuverlässige TCP-Transportprotokoll, um diese Verbindung herzustellen.  Standardmäßig verwendet der Web-Datenverkehr den TCP-Port 80.  Ein TCP-Datenstrom wird in IP-Pakete aufgeteilt und stellt sicher, dass diese Pakete immer fehlerfrei in der richtigen Reihenfolge ankommen.  HTTP ist ein Protokoll der Anwendungsschicht über TCP, also über IP. 

HTTPS ist eine sichere Version von HTTP und fügt eine zusätzliche Schicht zwischen HTTP und TCP mit der Bezeichnung TLS oder SSL (Transport Layer Security bzw.  Secure Sockets Layer) ein. HTTPS kommuniziert standardmäßig über Port 443, und wir werden später in diesem Artikel auf HTTPS schauen. 

HTTP and HTTPS layers

Eine HTTP-Verbindung wird durch und identifiziert. Auf einem Client wird eine HTTP-Anwendung durch ein Tupel identifiziert.  Das Herstellen einer Verbindung zwischen zwei Endpunkten ist ein mehrstufiger Prozess und umfasst Folgendes: 

Connection Delays
  • IP-Adresse vom Hostnamen über DNS auflösen
  • Stellen Sie eine Verbindung mit dem Server her 
  • eine Anfrage senden 
  • warte auf eine Antwort 
  • Verbindung schließen 

Der Server ist dafür verantwortlich, immer mit den richtigen Headern und Antworten zu antworten.

In HTTP / 1.0 wurden alle Verbindungen nach einer einzelnen Transaktion geschlossen. Wenn also ein Client drei separate Images vom selben Server anfordern wollte, wurden drei separate Verbindungen zum Remote-Host hergestellt.  Wie Sie dem obigen Diagramm entnehmen können, führt dies zu vielen Netzwerkverzögerungen, die zu einer suboptimalen Benutzererfahrung führen. 

Um Verbindungsaufbauverzögerungen zu reduzieren, führte HTTP / 1.1 persistente Verbindungen ein, langlebige Verbindungen, die offen bleiben, bis der Client sie schließt.  Permanente Verbindungen sind Standard in HTTP / 1.1. Um eine einzelne Transaktionsverbindung herzustellen, muss der Client den Header der Anforderung Connection: close festlegen.  Dies weist den Server an, die Verbindung nach dem Senden der Antwort zu schließen.

Zusätzlich zu persistenten Verbindungen verwenden Browser / Clients auch eine Technik, die als parallele Verbindungen bezeichnet wird, um Netzwerkverzögerungen zu minimieren.  Das uralte Konzept der parallelen Verbindungen beinhaltet die Schaffung eines Pools von Verbindungen (in der Regel auf sechs Verbindungen begrenzt).  Wenn es sechs Assets gibt, die der Client von einer Website herunterladen muss, führt der Client sechs parallele Verbindungen zum Herunterladen dieser Assets aus, was zu einem schnelleren Turnaround führt.  Dies ist eine enorme Verbesserung gegenüber seriellen Verbindungen, bei denen der Client nur ein Asset herunterlädt, nachdem der Download für ein vorheriges Asset abgeschlossen wurde. 

Parallele Verbindungen in Verbindung mit dauerhaften Verbindungen sind die Antwort von heute auf die Minimierung von Netzwerkverzögerungen und die Schaffung eines reibungslosen Benutzererlebnisses auf dem Client.  Weitere Informationen zu HTTP-Verbindungen finden Sie im Abschnitt Verbindungen der HTTP-Spezifikation. 

Server-seitige Verbindungsbehandlung 

Der Server wartet hauptsächlich auf eingehende Verbindungen und verarbeitet sie, wenn er eine Anforderung empfängt.  Die Operationen umfassen:

  • Einrichten eines Sockets, um an Port 80 (oder einem anderen Port) zu hören
  • Empfangen der Anfrage und Parsen der Nachricht 
  • die Antwort verarbeiten 
  • Antwortheader festlegen 
  • Senden der Antwort an den Client 
  • Schließen Sie die Verbindung, wenn eine Connection: close-Anfrage-Header gefunden wurde 

Natürlich ist dies keine erschöpfende Liste von Operationen.  Die meisten Anwendungen / Websites müssen wissen, wer eine Anfrage stellt, um individuellere Antworten zu erstellen.  Dies ist der Bereich der Identifikation und Authentifizierung


Identifikation und Authentifizierung 

HTTP ist ein Protokoll der Anwendungsschicht über TCP, also über IP. 

Es ist fast obligatorisch zu wissen, wer sich mit einem Server verbindet, um die Nutzung einer App oder einer Website und die allgemeinen Interaktionsmuster der Benutzer zu verfolgen.  Die Voraussetzung für die Identifizierung besteht darin, die Antwort so anzupassen, dass eine personalisierte Erfahrung möglich ist. Natürlich muss der Server wissen, wer ein Benutzer ist, um diese Funktionalität bereitzustellen.

Es gibt ein paar verschiedene Möglichkeiten, wie ein Server diese Informationen sammeln kann, und die meisten Websites verwenden eine Mischung dieser Ansätze: 

  • Header anfordern: Von, Referer, User-Agent - Wir haben diese Header in Teil 1 gesehen.
  • Client-IP - Die IP-Adresse des Clients 
  • Fat URLs - speichert den Status des aktuellen Benutzers, indem die URL geändert und bei jedem Klick auf eine andere URL umgeleitet wird. jeder Klick akkumuliert im Wesentlichen den Zustand. 
  • Cookies - der beliebteste und unaufdringlichste Ansatz.

Cookies ermöglichen es dem Server, beliebige Informationen für ausgehende Antworten über den Set-Cookie-Antwort-Header anzuhängen.  Ein Cookie wird mit einem oder mehreren Name = Wert-Paaren gesetzt, die durch ein Semikolon (;) getrennt sind, wie im Set-Cookie: session-id = 12345ABC; Benutzername = Nettuts

Ein Server kann die Cookies auch auf eine bestimmte Domäne und einen bestimmten Pfad beschränken und sie mit einem expires-Wert persistent machen.  Für jede Anfrage an einen Server werden vom Browser automatisch Cookies gesendet, und der Browser stellt sicher, dass nur die domain- und pfadspezifischen Cookies in der Anfrage gesendet werden.  Der Anforderungsheader Cookie: name=value [; name2=value2] wird verwendet, um diese Cookies an den Server zu senden. 

Die beste Möglichkeit, einen Benutzer zu identifizieren, besteht darin, dass er sich anmelden und anmelden muss. 

Die Implementierung dieser Funktion erfordert jedoch sowohl vom Entwickler als auch vom Benutzer einen gewissen Aufwand. Authentifizierung spielt hier eine große Rolle und ist wahrscheinlich die einzige Möglichkeit, den Benutzer zu identifizieren und zu verifizieren. 

Authentifizierung

HTTP unterstützt eine rudimentäre Form der Authentifizierung namens Basic Authentication sowie die sicherere Digest Authentication

Bei der Standardauthentifizierung verweigert der Server anfänglich die Anfrage des Clients mit einem WWW-Authenticate-Antwortheader und einem 401 Unauthorized Statuscode.  Wenn dieser Header angezeigt wird, zeigt der Browser einen Anmeldedialog an, der nach einem Benutzernamen und einem Passwort fragt.  Diese Information wird in einem Basis-64-codierten Format in dem Header der Authentifizierungsanforderung gesendet. Der Server kann nun die Anfrage validieren und den Zugriff erlauben, wenn die Anmeldedaten gültig sind.  Einige Server senden möglicherweise auch einen Authentication-Info-Header, der zusätzliche Authentifizierungsdetails enthält. 

Authentication Challenge/Response

Eine logische Folge der Standard-Authentifizierung ist die Proxy-Authentifizierung.  Anstelle eines Webservers wird die Authentifizierungsanforderung von einem Zwischenproxy angefordert.  Der Proxy sendet einen Proxy-Authenticate-Header mit einem 407 Nicht autorisierten Statuscode.  Im Gegenzug soll der Client die Credentials über den Header der Proxy-Authorization-Anfrage senden. 

Die Digestauthentifizierung ähnelt Basic und verwendet die gleiche Handshake-Technik mit den WWW-Authenticate- und Authorization-Headern, aber Digest verwendet eine sicherere Hashfunktion zum Verschlüsseln des Benutzernamens und des Kennworts (üblicherweise mit MD5- oder KD-Digestfunktionen).  Obwohl die Digestauthentifizierung sicherer als Basic sein soll, verwenden Websites aufgrund ihrer Einfachheit normalerweise die Standardauthentifizierung.  Um die Sicherheitsbedenken zu mindern, wird Basic Auth in Verbindung mit SSL verwendet. 

Sicheres HTTP

HTTPS AddressBar

Das HTTPS-Protokoll bietet eine sichere Verbindung im Internet.  Der einfachste Weg, um zu wissen, ob Sie HTTPS verwenden, ist die Adressleiste des Browsers zu überprüfen.  Die sichere Komponente von HTTPs beinhaltet das Einfügen einer Schicht von Verschlüsselung / Entschlüsselung zwischen HTTP und TCP.  Dies ist der Secure Sockets Layer (SSL) oder die verbesserte Transport Layer Security (TLS). 

SSL verwendet eine leistungsfähige Form der Verschlüsselung mit RSA und Kryptographie mit öffentlichem Schlüssel.  Da sichere Transaktionen im Internet so wichtig sind, wird seit einiger Zeit eine allgegenwärtige, auf Standards basierende Public-Key-Infrastruktur (PKI) betrieben. 

Bestehende Clients / Server müssen die Art und Weise, wie sie mit Nachrichten umgehen, nicht ändern, da die meiste harte Arbeit in der SSL-Schicht stattfindet.  So können Sie Ihre Webanwendung mit der Standardauthentifizierung entwickeln und automatisch die Vorteile von SSL nutzen, indem Sie zum https: // - Protokoll wechseln.  Damit die Webanwendung jedoch über HTTPS funktioniert, muss ein funktionierendes digitales Zertifikat auf dem Server bereitgestellt werden. 

Zertifikate

Genau wie Sie ID-Karten benötigen, um Ihre Identität zu zeigen, benötigt ein Webserver ein digitales Zertifikat, um sich zu identifizieren.  Zertifikate (oder "Zertifikate") werden von einer Zertifizierungsstelle ausgestellt und bürgen für Ihre Identität im Internet.  Die CAs sind die Wächter der PKI.  Die gebräuchlichste Form von Zertifikaten ist der X.509 v3-Standard, der Informationen enthält, z.

  • der Zertifikataussteller 
  • der für das Zertifikat verwendete Algorithmus 
  • der Name oder die Organisation des Subjekts, für das dieses Zertifikat erstellt wurde 
  • die öffentlichen Schlüsselinformationen für das Subjekt 
  • Signatur der Zertifizierungsstelle unter Verwendung des angegebenen Signaturalgorithmus

Wenn ein Client eine Anforderung über HTTPS stellt, versucht er zunächst, ein Zertifikat auf dem Server zu finden.  Wenn das Zertifikat gefunden wird, versucht es, es gegen seine bekannte Liste von CAs zu verifizieren.  Wenn es sich nicht um eine der aufgelisteten Zertifizierungsstellen handelt, wird möglicherweise ein Dialogfeld angezeigt, in dem der Benutzer über das Zertifikat der Website informiert wird. 

Sobald das Zertifikat verifiziert ist, ist der SSL-Handshake abgeschlossen und eine sichere Übertragung ist in Kraft.


HTTP-Caching 

Es besteht Einigkeit darüber, dass die gleiche Arbeit zweimal verschwendet wird.  Dies ist der Leitgedanke rund um das Konzept des HTTP-Caching, einer grundlegenden Säule der HTTP-Netzwerkinfrastruktur.  Da die meisten Vorgänge über ein Netzwerk abgewickelt werden, spart ein Cache Zeit, Kosten und Bandbreite und bietet eine verbesserte Web-Erfahrung. 

Caches werden an mehreren Stellen in der Netzwerkinfrastruktur vom Browser zum Ursprungsserver verwendet. Abhängig davon, wo es sich befindet, kann ein Cache wie folgt kategorisiert werden: 

  • Privat: In einem Browser werden Benutzernamen, Passwörter, URLs, Browserverlauf und Webinhalte zwischengespeichert.  Sie sind im Allgemeinen klein und für einen Benutzer spezifisch. 
  • Öffentlich: Wird als Caching-Proxy zwischen dem Server und dem Client bereitgestellt.  Diese sind viel größer, da sie mehreren Benutzern dienen.  Eine gängige Praxis besteht darin, mehrere Caching-Proxys zwischen dem Client und dem Ursprungsserver zu behalten.  Dies hilft, häufig aufgerufene Inhalte zu bedienen, während gleichzeitig eine Reise zum Server für selten benötigte Inhalte ermöglicht wird.
Cache Topology

Cache-Verarbeitung 

Unabhängig davon, wo sich ein Cache befindet, ist der Prozess der Cache-Pflege ziemlich ähnlich: 

  • Anforderungsnachricht empfangen 
  • Parsen Sie die URL und die Header.
  • Suche eine lokale Kopie; Ansonsten, holen und lokal speichern 
  • Führen Sie eine Aktualitätsprüfung durch, um das Alter des Inhalts im Cache zu ermitteln. 
  • Ersuchen Sie, den Inhalt nur bei Bedarf zu aktualisieren. 
  • Erstellen Sie die Antwort aus dem zwischengespeicherten Hauptteil und den aktualisierten Headern. 
  • Senden Sie die Antwort zurück an den Client. 

Optional protokollieren Sie die Transaktion. Natürlich ist der Server dafür verantwortlich, immer mit den richtigen Headern und Antworten zu antworten.  Wenn sich ein Dokument nicht geändert hat, sollte der Server mit 304 Not Geändert antworten.  Wenn die zwischengespeicherte Kopie abgelaufen ist, sollte sie eine neue Antwort mit aktualisierten Antwortheadern generieren und mit 200 OK zurückgeben.  Wenn die Ressource gelöscht wird, sollte sie mit 404 Not Found zurückkehren.  Mit diesen Antworten können Sie den Cache optimieren und sicherstellen, dass veralteter Inhalt nicht zu lange aufbewahrt wird. Cache Control Header

Cache Control Header 

Parallele Verbindungen in Verbindung mit dauerhaften Verbindungen sind die Antwort von heute auf die Minimierung von Netzwerkverzögerungen. 

Nachdem wir nun einen Eindruck davon bekommen haben, wie ein Cache funktioniert, ist es an der Zeit, die Anforderungs- und Antwortheader zu betrachten, die die Caching-Infrastruktur aktivieren.  Den Inhalt frisch und aktuell zu halten, ist eine der Hauptaufgaben des Caches.  Um die zwischengespeicherte Kopie konsistent mit dem Server zu halten, bietet HTTP einige einfache Mechanismen, nämlich den Ablauf von Dokumenten und die Revalidierung von Servern

Ablauf des Dokuments 

HTTP ermöglicht einem Ursprungsserver das Anhängen eines Ablaufdatums an jedes Dokument unter Verwendung der Cache-Control- und Expires-Response-Header.  Dies hilft dem Client und anderen Cache-Servern zu wissen, wie lange ein Dokument gültig und frisch ist.  Der Cache kann die Kopie bereitstellen, solange das Alter des Dokuments innerhalb des Ablaufdatums liegt.  Sobald ein Dokument abläuft, muss der Cache beim Server nach einer neueren Kopie suchen und seine lokale Kopie entsprechend aktualisieren.

Expires ist ein älterer HTTP / 1.0-Antwortheader, der den Wert als absolutes Datum angibt.  Dies ist nur nützlich, wenn die Serveruhren mit dem Client synchronisiert sind, was eine schreckliche Annahme ist.  Dieser Header ist im Vergleich zum neueren Header Cache-Control: max-age = , der in HTTP / 1.1 eingeführt wurde, weniger nützlich.  Hier ist max-age ein relatives Alter, das in Sekunden ab dem Zeitpunkt angegeben wird, zu dem die Antwort erstellt wurde.  Wenn also ein Dokument nach einem Tag ablaufen sollte, sollte der Verfalls-Header Cache-Control sein: max-age = 86400

Server-Revalidierung

Sobald ein zwischengespeichertes Dokument abläuft, muss der Cache erneut mit dem Server validiert werden, um zu überprüfen, ob das Dokument geändert wurde.  Dies wird Server-Revalidierung genannt und dient als Abfragemechanismus für die Stagnation eines Dokuments.  Nur weil eine zwischengespeicherte Kopie abgelaufen ist, bedeutet das nicht, dass der Server tatsächlich neueren Inhalt hat.  Revalidierung ist nur ein Mittel, um sicherzustellen, dass der Cache frisch bleibt.  Aufgrund der Ablaufzeit (wie in einer vorherigen Serverantwort angegeben) muss der Cache nicht für jede einzelne Anforderung beim Server nachfragen, wodurch Bandbreite, Zeit und Netzwerkverkehr eingespart werden.

Die Kombination aus Dokumentenablauf und Serververlängerung ist ein sehr effektiver Mechanismus und ermöglicht verteilten Systemen das Verwalten von Kopien mit einem Ablaufdatum. 

Wenn bekannt ist, dass sich der Inhalt häufig ändert, kann die Ablaufzeit verkürzt werden, sodass die Systeme häufiger neu synchronisiert werden können. 

Der Revalidierungsschritt kann mit zwei Arten von Anforderungsheadern durchgeführt werden: If-Modified-Since und If-None-Match.  Der erste ist für eine datumsbasierte Validierung, während der zweite Entity-Tags (ETags) verwendet, ein Hash des Inhalts.  Diese Header verwenden Datums- oder ETag-Werte, die von einer vorherigen Serverantwort erhalten wurden.  Im Fall von "If-Modified-Since" wird der Last-Modified-Antwortheader verwendet. Für If-None-Match ist dies der ETag-Antwortheader. 

Steuern der Cachability 

Der Gültigkeitszeitraum für ein Dokument sollte vom Server definiert werden, der das Dokument erzeugt.  Wenn es sich um eine Zeitungswebseite handelt, sollte die Startseite nach einem Tag (oder manchmal sogar jede Stunde!) Auslaufen.  HTTP stellt die Cache-Control- und Expires-Response-Header zum Festlegen der Ablaufzeit für Dokumente bereit.  Wie bereits erwähnt, basiert Expires auf absoluten Daten und ist keine zuverlässige Lösung zur Cache-Kontrolle.

Der  Cache-Control-Header ist viel nützlicher und hat einige verschiedene  Werte, um einzuschränken, wie Clients die Antwort zwischenspeichern sollten: 

  • Cache-Control: Kein Cache: Der Client darf das Dokument speichern; Es muss jedoch bei jeder Anforderung erneut mit dem Server validiert werden.  Es gibt einen HTTP / 1.0-Kompatibilitätsheader namens Pragma: no-cache, der genauso funktioniert. 
  • Cache-Control: no-store: Dies ist eine stärkere Anweisung an den Client, das Dokument überhaupt nicht zu speichern. 
  • Cache-Control: Muss-Revalidieren: Dies weist den Client an, seine Frischekalkulation zu umgehen und immer wieder mit dem Server zu validieren.  Es ist nicht erlaubt, die zwischengespeicherte Antwort zu liefern, falls der Server nicht verfügbar ist. 
  • Cache-Control: max-age: Dies legt eine relative Ablaufzeit (in Sekunden) ab dem Zeitpunkt fest, zu dem die Antwort generiert wird. 

Wenn der Server keine Cache-Control-Header sendet, kann der Client außerdem seinen eigenen heuristischen Ablaufalgorithmus verwenden, um Frische zu bestimmen. 

Frische vom Kunden einschränken

Die Cachability ist nicht nur auf den Server beschränkt.  Es kann auch vom Client aus angegeben werden.  Dadurch kann der Client Beschränkungen auferlegen, was er zu akzeptieren bereit ist.  Dies ist über den gleichen Cache-Control-Header möglich, allerdings mit ein paar unterschiedlichen Werten: 

  • Cache-Control: min-fresh = : Das Dokument muss für mindestens Sekunden frisch sein. 
  • Cache-Control: max-stale oder Cache-Control: max-stale = : Das Dokument kann nicht aus dem Cache bereitgestellt werden, wenn es länger alsSekunden alt ist. 
  • Cache-Control: max-age = : Der Cache kann ein Dokument, das länger als Sekunden zwischengespeichert wurde, nicht zurückgeben. 
  • Cache-Control: No-Cache oder Pragma: No-Cache: Der Client akzeptiert keine zwischengespeicherte Ressource, wenn er nicht erneut validiert wurde. 

HTTP-Caching ist eigentlich ein sehr interessantes Thema, und es gibt einige sehr ausgefeilte Algorithmen, um zwischengespeicherten Inhalt zu verwalten.  Weitere Informationen zu diesem Thema finden Sie im Abschnitt Caching der HTTP-Spezifikation. 


Zusammenfassung 

Unsere Tour von HTTP begann mit der Erstellung von URL-Schemata, Statuscodes und Request / Response-Headern.  Aufbauend auf diesen Konzepten haben wir uns einige der feineren Bereiche von HTTP angeschaut, z. B. die Handhabung von Verbindungen, die Identifizierung und Authentifizierung sowie das Caching.  Ich bin zuversichtlich, dass diese Tour Ihnen einen guten Geschmack für die Breite von HTTP und genügend Hinweise gegeben hat, um dieses Protokoll weiter zu erforschen. 

Verweise

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.