Einführung und vertieftes Verständnis des HTTP-Protokolls

Fasst mein Verständnis einiger Inhalte im Zusammenhang mit dem HTTP-Protokoll zusammen, auf die ich in tatsächlichen Arbeitsszenarien gestoßen bin.

Anfrage & Antwort

Anfrageformat

GET /api/index.json HTTP/1.1

Zum Beispiel: Accept: */*; User-Agent: Mozilla/4.0;……

[] Zum Beispiel: id=1×tamp=xxxxxx

Antwortformat

Zum Beispiel: HTTP/1.1 200 OK

Zum Beispiel: Content-Type: application/json;......

[

Statuscode

Es werden fast 60 HTTP-Statuscodes aufgezeichnet, die hauptsächlich generiert werden Unter ungewöhnlichen Umständen werden wir mehr oder weniger in täglichen Anwendungen darauf stoßen, was uns hilft, Probleme zu verstehen und zu entdecken.

206 – Wird beim Herunterladen mit Haltepunkten verwendet. Der Client hat einen Teil des Inhalts angefordert und der Server hat diesen Teil des Inhalts erfolgreich zurückgegeben.

301 – Permanenter Sprung, die ursprüngliche Adresse existiert nicht mehr und die URL verweist auf eine andere Adresse. Dies hängt vor allem mit Suchmaschinen zusammen und beeinflusst das Abrufverhalten von Crawlern.

302 – Temporärer Sprung, der Server gibt eine neue URL an den Client zurück und der Client kann weiterhin auf diese URL zugreifen, um Inhalte abzurufen.

304 – Die Ressource hat sich nicht geändert. Der Client kann lokal zwischengespeicherte Inhalte verwenden, was beim Zugriff auf statische Inhalte üblich ist.

413 – Die Anforderungsentität ist zu groß. Eine häufige Situation besteht darin, eine große Datei hochzuladen, diese überschreitet jedoch das Serverlimit (z. B. Nginx). Oder der Anforderungsheader oder Anforderungstext überschreitet die Einstellungen des Back-End-Servers (z. B. Tomcat) (z. B. sind zu viele Cookies unter dem aktuellen Domänennamen vorhanden, wodurch das Anforderungsheader-Limit überschritten wird)

416 - im Zusammenhang mit der Wiederaufnahme des Haltepunkts, Clientanforderung Der Bereich überschreitet die Dateigröße auf dem Server.

500 – Interner Serverfehler, normale Ergebnisse können nicht zurückgegeben werden. Die häufigste Anwendung löst beispielsweise eine Nullzeigerausnahme aus, die nicht behandelt wird.

502 – Gateway-Fehler. Eine häufige Situation besteht darin, dass der Reverse-Proxy-Backend-Server (z. B. Resin oder Tomcat) nicht gestartet ist.

503 – Dienst nicht verfügbar. Beispielsweise ist die Serverauslastung zu hoch oder der Server hat die Bereitstellung eingestellt.

504 – Gateway-Timeout. Beispielsweise überschreitet die Anforderungsdauer das Antwortzeitlimit des Servers.

Header

HTTP-Header sind in zwei Kategorien unterteilt: Request-Header und Response-Header. Im Folgenden sind einige Header aufgeführt, die wir häufig verwenden.

1. Cache-Kontrolle

In Internet-Website-Anwendungen gibt es fast überall Caches. In http-basierten Diensten können wir auch einige Inhalte steuern, die dies nicht tun Häufige Änderungen werden auf der Clientseite zwischengespeichert, sodass der zwischengespeicherte Inhalt bei mehreren Besuchen wiederverwendet werden kann, was den Zugriff beschleunigt und die Benutzererfahrung verbessert. Das http-Protokoll legt einige http-Header für die Cache-Steuerung fest:

Cache-Control(HTTP/1.1)/Pragma(HTTP/1.0): Gibt an, ob der Client zwischenspeichert und wie lange die Cache-Zeit beträgt. Der Standardwert ist privat, was bedeutet, dass der Inhalt im privaten Bereich des Benutzers zwischengespeichert wird. Beispiel: Cache-Control: max-age=86400, Must-Revalidate, dies teilt dem Client mit, dass die angeforderte Ressource einen Tag lang zwischengespeichert wird (Max-Age-Einheit ist Sekunden, relative Zeit) und nach Ablauf erneut überprüft werden muss.

Läuft ab: Geben Sie an, wie lange der Client (wenn keine erzwungene Aktualisierung erforderlich ist) den lokalen Cache direkt lesen kann, ohne eine Anfrage an den Server zu senden.

Hinweis:

Priorität: Cache-Kontrolle > Läuft ab; Detaillierte Parameterbeschreibung: http://condor.depaul.edu/dmumaugh/readings/handouts/ SE435 /HTTP/node24.html

Das unterschiedliche Verhalten verschiedener Browser (Aktualisieren, Zurück, Eingabe in die Adressleiste usw.) kann Unterschiede in der Implementierung haben

Last-Modified/If- Modified -Since: Last-Modified ist der letzte geänderte Zeitstempel der Ressource, der vom Server an den Client zurückgegeben wird. Auf diese Weise bringt der Client den Parameter If-Modified-Since mit, um zu überprüfen, ob die Ressource bei der nächsten Anforderung aktualisiert wurde (z. B. erzwungene Aktualisierung). Nein. Bei einer Aktualisierung gibt der Server den Statuscode 304 zurück und der Client greift direkt auf die lokal zwischengespeicherten Ressourcen zu. Zu diesem Zeitpunkt gibt es nur einen Anforderungs-Overhead und keinen Netzwerkübertragungs-Overhead. Hinweis: Der Zeitstempel muss Greenwich Mean Time (GMT) sein, zum Beispiel: Last-Modified:Sat, 19 Oct 2013 09:20:15 GMT

ETag/If-None-Match: ETag basiert auf der Datei Attribute Die durch einen bestimmten Algorithmus generierte Ressourcenkennung wird auch verwendet, um zu bestimmen, ob die vom Client angeforderte Ressource aktualisiert wurde. Wenn der Server einen ETag-Wert an den Client zurückgibt, bringt er bei der nächsten Anforderung des Clients den Parameter If-None-Match mit, um zu überprüfen, ob die Ressource aktualisiert wird. Wenn sie nicht aktualisiert wird, wird ein 304-Statuscode zurückgegeben . (Der Effekt ist im Grunde derselbe wie bei Last-Modified)

Hinweis:

ETag muss berechnet werden, was für Server mit knappen Rechenressourcen einen Verbrauch darstellt, sodass einige Websites ETag nicht verwenden direkt;

Wenn sich der Server hinter einem Load Balancer befindet, können Anfragen für dieselbe Ressource auf verschiedene Backend-Maschinen verteilt werden. Da die Berechnung von ETag von Dateiattributen abhängt, können Dateien mit demselben Inhalt auf verschiedenen Maschinen unterschiedliche ETags generieren Die ETag-Überprüfung für Dateien, deren ursprünglicher Inhalt sich nicht geändert hat, konnte nicht bestanden werden. Hier gibt es zwei Lösungen: Eine besteht darin, dass die Etag-Berechnung nicht vom lokalen Computer abhängt, z. B. die direkte Berechnung des MD5-Werts des Dateiinhalts. Die andere besteht darin, beim Laden dieselbe URL-Anfrage an denselben Back-End-Computer zu verteilen Balancer.

In unserem tatsächlichen Geschäftsszenario hat HTTP-Caching großartige Verwendungsmöglichkeiten:

Nutzen Sie die Ressourcen des Clients vollständig aus, z. B. einige statische Dateien, auf die der Client häufig zugreifen muss B. LOGO, Werbebilder etc., können lokal auf dem Client zwischengespeichert werden. Dies kann Netzwerkanfragen reduzieren, die Client-Anzeige beschleunigen und den Druck auf Serveranfragen verringern.

Wenn einige unserer statischen Inhalte, wie Nachrichten, Blogs usw., von Suchmaschinen-Crawlern gecrawlt werden, können wir durch die Steuerung der Cache-Parameter die Crawling-Frequenz des Crawlers reduzieren und unnötige Ressourcenverschwendung reduzieren.

Wenn unsere statischen Ressourcen CDN verwenden, kann durch die Einrichtung des HTTP-Cache eine Datei auf dem CDN-Knoten gespeichert werden, wodurch die Anzahl der CDN-Zurück-zu-Ursprünge, die Netzwerkverzögerung und der Druck auf den Ursprungsserver reduziert werden.

　2. Haltepunktanforderung

Accept-Ranges: Wenn der Server den Haltepunkt-Download unterstützt, gibt er diesen Antwortheader an den Client zurück. Wenn der Client dies weiß, kann er eine Haltepunktanforderung senden. .

Content-Length: Die Länge der Antwortinformationen, die dem Client mitteilen, wie viele Daten von der aktuellen Anfrage zurückgegeben werden. Hierbei ist zu beachten, dass beim Senden einer Anfrage mit der Head-Methode keine spezifischen Daten zurückgegeben werden, sondern dass Content-Length die Größe der vollständigen Daten zurückgibt.

Range/Content-Range: Der Client übermittelt bei der Anfrage einen Header namens Range und teilt dem Server mit, welchen Teil der Daten er anfordern möchte. Beispiel: „Bereich: Bytes=0-1023“ bedeutet, dass die Bytes 0 bis 1023 angefordert werden. Anschließend gibt der Server den Inhalt dieser 1024 Bytes an den Client zurück und Content-Range wird in den Antwortheader aufgenommen. Das heißt: Inhaltsbereich: Bytes 0-1023/4096, diese 4096 ist die Gesamtdateigröße. Die nächste Anfrage des Clients kann ab dem 1024. Byte beginnen, Bereich: Bytes=1024-xxxx

　3. Codierung

Accept-Encoding/Content-Encoding: Ersteres wird von der vom Client empfangenen Nachricht unterstützt Codierungstyp. Der Standardwert ist „Identität“. Zu den optionalen Werten gehören „gzip“, „komprimieren“ usw. Letzteres ist der Inhaltskodierungstyp der serverseitigen Antwortinformationen, und häufig wird Komprimierung verwendet. Die Vorteile der Komprimierung liegen auf der Hand. Im Vergleich zum CPU-Verbrauch, der durch die serverseitige Komprimierung verursacht wird, ist die Reduzierung der Netzwerkübertragung offensichtlich praktischer. Gängige Formen: Inhaltskodierung: gzip, deflate, compress Normalerweise können wir Antwortergebnisse wie HTML, JS, CSS, XML und JSON komprimieren und übertragen.

Transfer-Encoding: Antwort-Header Der Transfer-Codierungstyp der Antwortnachricht gibt die Form der Netzwerkübertragung an. Im Allgemeinen hat es die folgende Form: Transfer-Encoding: chunked. Wenn der Server dynamische Inhalte generiert und die spezifische Länge der Antwortinformationen nicht kennt, kann er diese über diesen festgelegten Block übertragen und so viele Daten zurückgeben, wie er verarbeitet. Es besteht also keine Notwendigkeit, mit der Rückgabe zu warten, bis die Daten bereit sind auf einmal. In Kombination mit der oben genannten Inhaltskodierung, wie z. B. gzip, kann es in Blöcken komprimiert und übertragen werden. Bitte beachten Sie außerdem, dass wir bei Verwendung dieser Codierung zur Übertragung die Inhaltslänge nicht sehen können, da der Inhalt nicht vollständig generiert wurde.

　4. Andere

X-Forward-For: Anforderungsheader Wird verwendet, um die tatsächliche IP des Benutzers zu identifizieren, insbesondere beim Zugriff auf den Server über einen Proxy (vorwärts oder rückwärts) oder wenn der Server vorhanden ist unter Last Gleichen Sie die Situation hinter dem Gerät aus. Format: X-forward-For: Client, Proxy1, Proxy2, ... Ganz links ist die IP, die dem Client am nächsten liegt.

User-Agent: Anforderungsheader, der vom Server verwendet wird, um die grundlegenden Informationen des Clients zu identifizieren. Im Allgemeinen ist dies nützlich, wenn Suchcrawler identifiziert werden. In einigen Szenarien kann dies auch zur Erstellung einiger Clientstatistiken verwendet werden.

Referer: Wenn der Client auf den Server zugreift, gibt dieser Referer die Quelle der Anfrage an, z. B. von welcher Website aus sie verlinkt wird. Darüber hinaus besteht eine weitere wichtige Verwendung darin, illegale Anforderungsquellen in Szenarien zu filtern, die Anti-Hotlinking von Ressourcen erfordern (dieser Referrer kann jedoch vom Client gefälscht werden).

Standort: Antwortheader Dieser Standortheader wird in den Antwortheader des 301/302-Statuscodes eingefügt, um den Client anzuweisen, die neue Adresse für den Zugriff auf die erforderlichen Ressourcen zu verwenden.

Verbindung: Anforderungs-/Antwort-Header. Standardmäßig behalten Client und Server die Verbindung bei, d. h. Verbindung: Keep-Alive. Wenn eine der Parteien die Verbindung nicht aufrechterhalten möchte, können Sie dies tun put this Der Wert ist auf close eingestellt. Standardmäßig halten der Client und der Server eine lange Verbindung aufrecht, sodass der Client diese Verbindung zum Senden mehrerer HTTP-Anfragen verwenden kann, wodurch der durch häufige Verbindungsaufbau verursachte Verbrauch reduziert wird. Für diesen Parameter sind möglicherweise weitere Einstellungen auf der Serverseite erforderlich, z. B. die Keep-Alive-Zeit der Verbindung und einige Netzwerkparametereinstellungen des Serverkernels (für TCP).

Sitzung und Cookie

HTTP-Anfragen sind zustandslose Anfragen, aber in unseren Internetanwendungen ist es oft notwendig, Benutzerstatusinformationen zu identifizieren, um einige interaktive Vorgänge abzuschließen. Beispielsweise muss die Benutzerauthentifizierung den Anmeldestatus des Benutzers aufzeichnen, und Warenkorbanwendungen müssen sich den Benutzer merken Auswahlen. Produkte, Werbeanwendungen müssen das historische Surfverhalten der Benutzer usw. aufzeichnen. Dabei kommen Session- und Cookies zum Einsatz.

Sitzung: Bezieht sich auf den Interaktionsstatus zwischen dem Client und dem Server während des HTTP-Anfrage-Antwort-Prozesses. Diese Informationen werden auf der Serverseite gespeichert, z. B. im Speicher, in der Datenbank usw. Jede Sitzung verfügt über eine eindeutige Kennung, die vom Server generiert wird. Diese Kennung muss auch auf dem Client gespeichert werden, damit der Client diese Kennung bei der nächsten Anfrage mitbringen kann, um dem Server die Ermittlung des Client-Status zu erleichtern.

Client-Unterstützung für Sitzungen:

Speichern Sie die Sitzungs-ID über Cookies und senden Sie sie bei Anfrage an den Server.

Kommunizieren Sie mit dem Server, indem Sie die Sitzungs-ID in den URL-Parametern tragen.

Kommunizieren Sie mit dem Server, indem Sie die Sitzungs-ID in das ausgeblendete Feld des Formulars tragen.

Problem bei der Sitzungsfreigabe:

In verteilten Anwendungen wird unser http-Server normalerweise hinter einem Reverse-Proxy oder einem Lastausgleichsgerät platziert, wodurch ein Problem bei der Sitzungsfreigabe auftritt. Das heißt, mehrere Anfragen desselben Benutzers können auf mehrere verschiedene Maschinen verteilt werden. Wenn wir die Sitzung im lokalen Speicher der Maschine speichern, können wir die Sitzung des Benutzers nicht auf mehrere Maschinen verteilen. Im Allgemeinen können wir dieses Problem auf zwei Arten lösen:

Speichern Sie die Sitzung im verteilten Speicher (z. B. im Zwischenspeicher) oder im zentralen Speicher (z. B. in der Datenbank).

Verteilen Sie die Anforderungen desselben Benutzers an denselben Computer auf dem Reverse-Proxy oder dem Lastausgleichsgerät (das Problem der Neuverteilung von Anforderungen nach dem Ausfall des Computers muss hier behandelt werden).

Cookie: Behalten Sie zustandsbehaftete Informationen auf dem Client bei. Jeder Cookie-Inhalt gehört zu einer bestimmten Domäne (Domäne) und einem bestimmten Pfad (Pfad). Aus Sicherheitsgründen können Cookies in verschiedenen Domänen oder Pfaden nicht geteilt werden.

Sitzungscookie: Es ist keine Ablaufzeit angegeben, es wird im Speicher gespeichert und läuft ab, nachdem der Browser geschlossen wird.

Persistentes Cookie: Gibt die Ablaufzeit an und wird lokal im Browser gespeichert.

Einzelheiten finden Sie unter: http://en.wikipedia.org/wiki/HTTP_cookie

Es ist zu beachten, dass Cookies einige Sicherheitsprobleme haben.

Hier habe ich nur mein Verständnis einiger Inhalte im Zusammenhang mit dem http-Protokoll zusammengefasst, auf die ich bei der Arbeit gestoßen bin. Es gibt noch viele Dinge, die im http-Protokoll untersucht werden müssen, und wir müssen auch weiterhin erforschen Verstehen Sie das http-Protokoll. Es wird unseren Entwicklungsanwendungen großen Komfort bieten.

Abschließend empfehle ich zwei sehr wichtige HTTP-Debugging-Tools: Fiddler (Windows) und Charles (Mac) verfügen über eine HTTP-Proxy-Funktion. Sie können HTTP-Anwendungen verwenden, die nicht browserbasiert sind (z. B. mobile Apps). diese beiden Ein Tool zur Überwachung von HTTP-Anfragen.

Das obige ist der detaillierte Inhalt vonEinführung und vertieftes Verständnis des HTTP-Protokolls. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!