Share
In meinem vorherigen Artikel haben wir einige Grundlagen von HTTP behandelt, beispielsweise das URL-Schema, Statuscodes und Request / Response-Header. Auf dieser Grundlage werden wir uns mit den feineren Aspekten von HTTP beschäftigen, wie Verbindungsverarbeitung, Authentifizierung und HTTP-Caching. Diese Themen sind ziemlich umfangreich, aber wir werden die wichtigsten Punkte behandeln.
Zwischen Client und Server muss eine Verbindung hergestellt werden, bevor sie miteinander kommunizieren können, und HTTP verwendet das zuverlässige TCP-Transportprotokoll, um diese Verbindung herzustellen. Standardmäßig verwendet der Webdatenverkehr den TCP-Port 80. Ein TCP-Datenstrom wird in IP-Pakete aufgeteilt und stellt sicher, dass diese Pakete immer in der richtigen Reihenfolge ohne Fehler ankommen. HTTP ist ein Protokoll auf Anwendungsebene über TCP (über IP).
HTTPS ist eine sichere Version von HTTP, die eine zusätzliche Schicht zwischen HTTP und TCP einfügt, die als TLS oder SSL (Transport Layer Security bzw. Secure Sockets Layer) bezeichnet wird. HTTPS kommuniziert standardmäßig über Port 443, und wir werden uns HTTPS später in diesem Artikel ansehen.
Eine HTTP-Verbindung wird durch gekennzeichnet
Der Server ist dafür verantwortlich, immer mit den richtigen Kopfzeilen 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, stellte er drei separate Verbindungen zum Remote-Host her. Wie Sie dem obigen Diagramm entnehmen können, kann dies zu erheblichen Netzwerkverzögerungen führen, was zu einer suboptimalen Benutzererfahrung führt.
Um Verzögerungen beim Verbindungsaufbau zu reduzieren, wurde HTTP / 1.1 eingeführt dauerhafte Verbindungen, langlebige Verbindungen, die geöffnet bleiben, bis der Client sie schließt. Persistente Verbindungen sind standardmäßig in HTTP / 1.1. Für das Herstellen einer einzelnen Transaktionsverbindung muss der Client das festlegen Verbindung: schließen Anforderungsheader Dadurch wird der Server angewiesen, die Verbindung nach dem Senden der Antwort zu schließen.
Browser / Clients verwenden neben persistenten Verbindungen auch eine Technik namens Parallelverbindungen, Netzwerkverzögerungen zu minimieren. Das jahrhundertealte Konzept der parallelen Verbindungen beinhaltet das Erstellen eines Pools von Verbindungen (im Allgemeinen auf sechs Verbindungen begrenzt). Wenn der Client sechs Assets von einer Website herunterladen muss, stellt er sechs parallele Verbindungen her, um diese Assets herunterzuladen. Dies führt zu einer schnelleren Bearbeitung. Dies ist eine enorme Verbesserung gegenüber seriellen Verbindungen, bei denen der Client ein Asset nur nach Abschluss des Downloads für ein vorheriges Asset herunterlädt.
Parallele Verbindungen in Kombination mit dauerhaften Verbindungen sind heutzutage die Antwort auf die Minimierung von Netzwerkverzögerungen und die Schaffung eines reibungslosen Betriebs auf dem Client. Eine ausführliche Behandlung von HTTP-Verbindungen finden Sie im Abschnitt Verbindungen der HTTP-Spezifikation.
Der Server wartet meistens auf eingehende Verbindungen und verarbeitet sie, wenn er eine Anfrage erhält. Die Operationen beinhalten:
Accentsconagua
Verbindung: schließen Anforderungsheader wurde gefundenNatürlich ist dies keine erschöpfende Liste von Vorgängen. Die meisten Anwendungen / Websites müssen wissen, wer eine Anfrage stellt, um individuellere Antworten zu erstellen. Dies ist das Reich von Identifizierung und Authentifizierung.
HTTP ist ein Protokoll auf Anwendungsebene über TCP (über IP).
Es ist fast zwingend erforderlich zu wissen, wer eine Verbindung zu einem Server herstellt, um die Nutzung einer App oder Website und die allgemeinen Interaktionsmuster der Benutzer zu verfolgen. Die Voraussetzung der Identifikation ist, die Antwort maßzuschneidern, um eine personalisierte Erfahrung zu bieten. Natürlich muss der Server wissen, wer ein Benutzer ist, um diese Funktionalität bereitzustellen.
Es gibt verschiedene Möglichkeiten, wie ein Server diese Informationen sammeln kann, und die meisten Websites verwenden eine Kombination dieser Ansätze:
Von, Referer, User-Agent - Wir haben diese Header in Teil 1 gesehen.Cookies ermöglichen es dem Server, beliebige Informationen für ausgehende Antworten über das Internet anzufügen Set-Cookie Antwortheader Ein Cookie wird mit einem oder mehreren gesetzt name = wert durch Semikolon getrennte Paare (;), wie in Set-Cookie: Sitzungs-ID = 12345ABC; username = nettuts.
Ein Server kann die Cookies auch auf ein bestimmtes beschränken Domain und Pfad, und es kann sie zu einem persistenten machen läuft ab Wert. Cookies werden vom Browser automatisch für jede an einen Server gesendete Anforderung gesendet, und der Browser stellt sicher, dass nur die Domain- und Pfad-In der Anfrage werden bestimmte Cookies gesendet. Der Anforderungsheader Cookie: Name = Wert [; 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 zur Anmeldung und Anmeldung anmelden muss. Die Implementierung dieser Funktion erfordert jedoch einige Anstrengungen des Entwicklers sowie des Benutzers.
Techniken wie OAuth vereinfachen diese Art von Funktion, sie erfordern jedoch die Zustimmung des Benutzers, um ordnungsgemäß zu funktionieren. Authentifizierung spielt hier eine große Rolle, und es ist wahrscheinlich die einzige Möglichkeit, den Benutzer zu identifizieren und zu überprüfen.
HTTP unterstützt eine rudimentäre Form der Authentifizierung Basisauthentifizierung, sowie die sicherere Digest-Authentifizierung.
Bei der Standardauthentifizierung verweigert der Server die Anforderung des Clients zunächst mit einem WWW-Authentifizierung Antwortheader und a 401 nicht Autorisiert Statuscode. Wenn dieser Header angezeigt wird, zeigt der Browser ein Anmeldedialogfeld an, in dem Sie zur Eingabe eines Benutzernamens und eines Kennworts aufgefordert werden. Diese Informationen werden in einem Base-64-codierten Format im gesendet Authentifizierung Anforderungsheader Der Server kann jetzt die Anforderung überprüfen und den Zugriff zulassen, wenn die Anmeldeinformationen gültig sind. Einige Server senden möglicherweise auch eine Authentifizierungs-Info Header mit zusätzlichen Authentifizierungsdetails.
Eine Folge von Basic-Authentication ist Proxy-Authentifizierung. Anstelle eines Webservers wird die Authentifizierungsaufforderung von einem Zwischenproxy angefordert. Der Proxy sendet eine Proxy-Authentifizierung Header mit einem 407 Nicht autorisiert Statuscode. Im Gegenzug soll der Client die Zugangsdaten über die Proxy-Autorisierung Anforderungsheader.
Die Digest-Authentifizierung ähnelt der von Basic und verwendet dieselbe Handshake-Technik wie das WWW-Authentifizierung und Genehmigung Header, aber Digest verwendet eine sicherere Hash-Funktion, um den Benutzernamen und das Kennwort zu verschlüsseln (üblicherweise mit MD5- oder KD-Digest-Funktionen). Obwohl die Digest-Authentifizierung sicherer als Basic sein soll, verwenden Websites aufgrund ihrer Einfachheit normalerweise die Standardauthentifizierung. Zur Verringerung der Sicherheitsbedenken wird Basic Auth in Verbindung mit SSL verwendet.
Das HTTPS-Protokoll bietet eine sichere Verbindung im Web. Der einfachste Weg, um festzustellen, ob Sie HTTPS verwenden, ist das Überprüfen der Adressleiste des Browsers. Die sichere Komponente von HTTPs beinhaltet das Einfügen einer Verschlüsselungs- / Entschlüsselungsschicht zwischen HTTP und TCP. Dies ist SSL (Secure Sockets Layer) oder das verbesserte Transport Layer Security (TLS)..
SSL verwendet eine leistungsfähige Form der Verschlüsselung unter Verwendung von RSA und der Verschlüsselung mit öffentlichen Schlüsseln. Da sichere Transaktionen im Web so wichtig sind, werden seit einiger Zeit allgegenwärtige, auf Standards basierende Public-Key-Infrastruktur (PKI) angestrebt.
Bestehende Clients / Server müssen die Art und Weise, wie Nachrichten behandelt werden, nicht ändern, da der größte Teil der harten Arbeit in der SSL-Schicht stattfindet. So können Sie Ihre Webanwendung mithilfe der Standardauthentifizierung entwickeln und die Vorteile von SSL automatisch nutzen, indem Sie zu https: // Protokoll. Damit die Webanwendung jedoch über HTTPS funktioniert, müssen Sie ein funktionsfähiges digitales Zertifikat auf dem Server bereitstellen.
So wie Sie einen Ausweis 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 (Certificate Authority, CA) ausgestellt und belegen Ihre Identität im Web. Die CAs sind die Wächter der PKI. Die gebräuchlichste Form von Zertifikaten ist der X.509 v3-Standard, der folgende Informationen enthält:
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 anhand seiner bekannten Liste von Zertifizierungsstellen zu überprüfen. Wenn es sich nicht um eine der aufgelisteten Zertifizierungsstellen handelt, wird dem Benutzer möglicherweise ein Dialogfeld mit einer Warnung zum Zertifikat der Website angezeigt.
Nach der Überprüfung des Zertifikats ist der SSL-Handshake abgeschlossen und die sichere Übertragung ist wirksam.
Es ist allgemein anerkannt, dass dieselbe Arbeit zweimal zu verschwenden ist. Dies ist der Leitsatz für das Konzept des HTTP-Caching, einer grundlegenden Säule der HTTP-Netzwerkinfrastruktur. Da die meisten Vorgänge über ein Netzwerk erfolgen, spart ein Cache Zeit, Kosten und Bandbreite und sorgt für ein verbessertes Web-Erlebnis.
Caches werden an mehreren Stellen in der Netzwerkinfrastruktur verwendet, vom Browser bis zum Ursprungsserver. Je nach Standort kann ein Cache in folgende Kategorien unterteilt werden:
Unabhängig davon, wo sich ein Cache befindet, ist die Pflege eines Caches ziemlich ähnlich:
Natürlich ist der Server dafür verantwortlich, immer mit den richtigen Kopfzeilen und Antworten zu antworten. Wenn sich ein Dokument nicht geändert hat, sollte der Server mit einem antworten 304 Nicht modifiziert. Wenn die zwischengespeicherte Kopie abgelaufen ist, sollte eine neue Antwort mit aktualisierten Antwortheatern generiert und mit a zurückgegeben werden 200 OK. Wenn die Ressource gelöscht wird, sollte sie mit zurückkommen 404 Nicht gefunden. Diese Antworten helfen, den Cache zu optimieren und sicherzustellen, dass veraltete Inhalte nicht zu lange aufbewahrt werden.
Parallele Verbindungen in Kombination mit dauerhaften Verbindungen sind heutzutage die Antwort auf die Minimierung von Netzwerkverzögerungen.
Da wir jetzt ein Gefühl dafür haben, wie ein Cache funktioniert, ist es an der Zeit, die Request- und Response-Header zu betrachten, die die Caching-Infrastruktur ermöglichen. Die Aktualität und Aktualität der Inhalte ist eine der Hauptaufgaben des Cache. Um die zwischengespeicherte Kopie mit dem Server konsistent zu halten, bietet HTTP einige einfache Mechanismen, nämlich Ablauf des Dokuments und Server-Überprüfung.
HTTP ermöglicht es einem Ursprungsserver, eine Verbindung herzustellen Haltbarkeitsdatum zu jedem Dokument mit der Cache-Steuerung und Läuft ab Antwort Überschriften Dadurch können der Client und andere Cache-Server wissen, wie lange ein Dokument gültig und aktuell ist. Der Cache kann die Kopie so lange bereitstellen wie die Alter des Dokuments liegt innerhalb des Ablaufdatums. Wenn ein Dokument abläuft, muss der Cache beim Server nach einer neueren Kopie suchen und seine lokale Kopie entsprechend aktualisieren.
Läuft ab 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 synchron sind. Dies ist eine schreckliche Annahme. Dieser Header ist weniger nützlich als der neuere Cache-Kontrolle: max-age = Header eingeführt in HTTP / 1.1. Hier, Maximalalter ist ein relatives Alter in Sekunden, ab dem Zeitpunkt, an dem die Antwort erstellt wurde. Wenn also ein Dokument nach einem Tag abläuft, sollte der Ablauf-Header lauten Cache-Kontrolle: maximales Alter = 86400.
Wenn ein zwischengespeichertes Dokument abläuft, muss der Cache beim Server erneut überprüft werden, um zu prüfen, ob sich das Dokument geändert hat. Das nennt man Servervalidierung und dient als Abfragemechanismus für die Faulheit eines Dokuments. Nur weil eine zwischengespeicherte Kopie abgelaufen ist, bedeutet dies nicht, dass der Server tatsächlich neueren Inhalt hat. Eine erneute Validierung ist nur ein Mittel, um sicherzustellen, dass der Cache aktuell bleibt. Aufgrund der Ablaufzeit (wie in einer früheren Serverantwort angegeben) muss sich der Cache nicht für jede einzelne Anforderung beim Server abfragen, wodurch Bandbreite und Zeit gespart und der Netzwerkverkehr reduziert wird.
Die Kombination aus Dokumentablauf und Server-Revalidierung ist ein sehr effektiver Mechanismus, der es verteilten Systemen ermöglicht, Kopien mit einem Ablaufdatum zu verwalten.
Wenn bekannt ist, dass sich der Inhalt häufig ändert, kann die Ablaufzeit reduziert werden, sodass die Systeme häufiger erneut synchronisiert werden.
Der Revalidierungsschritt kann mit zwei Arten von Anforderungsheadern ausgeführt werden: Wenn-modifiziert-seit und Wenn-keine-Übereinstimmung. Ersteres dient zur datumsbasierten Validierung, während letzteres Entity-Tags (ETags) verwendet, einen Hash des Inhalts. Diese Header verwenden Datums- oder ETag-Werte, die aus einer vorherigen Serverantwort abgerufen wurden. Im Falle von Wenn-modifiziert-seit, das Zuletzt bearbeitet Antwortheader wird verwendet; zum Wenn-keine-Übereinstimmung, es ist der ETag Antwortheader.
Der Gültigkeitszeitraum für ein Dokument sollte vom Server festgelegt werden, der das Dokument generiert. Wenn es sich um eine Zeitungswebsite handelt, sollte die Homepage nach einem Tag (oder manchmal sogar stündlich!) Ablaufen. HTTP liefert die Cache-Steuerung und Läuft ab Antwortheader, um den Ablauf für Dokumente festzulegen. Wie bereits erwähnt, Läuft ab basiert auf absoluten Daten und ist keine zuverlässige Lösung für die Cache-Steuerung.
Das Cache-Steuerung header ist viel nützlicher und hat einige verschiedene Werte, um festzulegen, wie Clients die Antwort zwischenspeichern sollen:
Nebenbei gesagt, wenn der Server keine sendet Cache-Steuerung In den Headern kann der Client seinen eigenen heuristischen Ablaufalgorithmus verwenden, um die Frische zu bestimmen.
Die Zwischenspeicherung ist nicht nur auf den Server beschränkt. Es kann auch vom Client aus angegeben werden. Auf diese Weise kann der Client Einschränkungen auferlegen, was er akzeptieren möchte. Dies ist über dasselbe möglich Cache-Steuerung Header, jedoch mit einigen anderen Werten:
HTTP-Caching ist eigentlich ein sehr interessantes Thema, und es gibt einige sehr ausgeklügelte Algorithmen zur Verwaltung von zwischengespeicherten Inhalten. Weitere Informationen zu diesem Thema finden Sie im Abschnitt Caching der HTTP-Spezifikation.
Unsere HTTP-Tour begann mit der Gründung von URL-Schemata, Statuscodes und Request / Response-Headern. Aufbauend auf diesen Konzepten untersuchten wir einige der feineren Bereiche von HTTP, wie etwa die Verbindungsverarbeitung, Identifizierung, Authentifizierung und Zwischenspeicherung. Ich hoffe, dass diese Tour Ihnen einen guten Eindruck von der Breite von HTTP gegeben hat und genügend Hinweise, um dieses Protokoll näher kennenzulernen.
