Vorwort
Das HTTP-Protokoll ist eines der wichtigsten Protokolle im Internet, obwohl es einfach erscheint, stößt es in der Praxis oft auf Probleme, und wir sind ihm schon mehrfach begegnet. Es gibt lange Verbindungen und Paketparsing. Du kannst nichts über das HTTP-Protokoll wissen, du musst es gründlich verstehen. Deshalb habe ich diese Serie geschrieben, um die Probleme und Erfahrungen des HTTP-Protokolls zu teilen.
Das HTTP-Protokoll hat einen Header und einen Körper für sowohl die Anfrage- als auch die Antwortpakete, und der Body ist die Ressource, die Sie erhalten möchten, wie zum Beispiel eine HTML-Seite, ein JPEG-Bild, und der Header wird verwendet, um bestimmte Konventionen zu erstellen. Zum Beispiel einigen sich Client und Server auf einige Übertragungsformate, und der Client erhält zuerst den Header, kennt einige Formatinformationen und beginnt dann, den Body zu lesen.
Client: Accept-Encoding:gzip (komprimiere es für mich, ich benutze Traffic, lade es zuerst herunter und entpacke es dann langsam)
Server 1: Inhaltskodierung: null (Kein Inhaltskodierungs-Header.) Ich gebe keine Kompression an, die CPU ist nicht frei, willst du sie?
Server 2: Inhaltskodierung: gzip (Speichert für dich den Datenverkehr, komprimiert ihn) Client: Verbindung: Keep-alive (Großer Bruder, wir haben endlich eine TCP-Verbindung gebaut, wir werden sie beim nächsten Mal verwenden)
Server 1: Verbindung: Keep-alive (nicht einfach, weiterhin nutzen)
Server 2: Verbindung: schließen (Wer es weiterhin mit dir benutzt, unser TCP ist einmal, und wir müssen uns beim nächsten Mal wieder verbinden) Das HTTP-Protokoll hat keine drei Handshakes, und wenn ein Client Ressourcen vom Server anfordert, hat die Serverseite Vorrang. Es gibt auch einige Header, die keinen Verhandlungsprozess haben, aber der Server sagt dem Client direkt, was zu tun ist. Zum Beispiel ist die Content-Length oben das, was der Server dem Client angibt, wie groß der Körper ist. Aber! Der Kellner kann dir vielleicht nicht im Voraus genau sagen, wie groß der Körper ist. Der Server muss zuerst den Header schreiben und dann den Body; wenn du den Body Case im Header schreiben willst, musst du die Body-Größe im Voraus kennen. Wenn der Body dynamisch generiert wird, beendet der Server den Header und beginnt dann, den Header zu schreiben, was viel zusätzlichen Overhead verursacht, sodass es möglicherweise keine Inhaltslänge im Header gibt.
Wie weiß der Kunde also die Größe des Körpers? Der Server informiert es dir auf drei Arten.
1. Der Server kennt bereits die Ressourcengröße und teilt es dir über den Inhaltslängen-Header mit.
Content-Length:1076(body的大小是1076B,你读取1076B就可以完成任务了)
Transfer-Encoding: null
2. Der Server kann die Größe der Ressource nicht im Voraus kennen oder ist nicht bereit, Ressourcen aufzugeben, um die Größe der Ressource im Voraus zu berechnen, weshalb er der HTTP-Antwortnachricht einen Header namens Transfer-Encoding:chunked hinzufügt, was Block Transfer bedeutet. Jeder Block verwendet ein festes Format, wobei die Größe des Blocks vorne, die dahinterliegenden Daten und dann der letzte Block mit Größe 0 ist. So muss der Client beim Parsen darauf achten, einige nutzlose Felder zu entfernen.
Content-Length:null
Transfer-Encoding:chunked (接下来的body我要一块一块的传,每一块开始是这一块的大小,等我传到大小为0的块时,就没了)
3. Der Server kennt die Größe der Ressource nicht und unterstützt den Chunked-Übertragungsmodus nicht, sodass weder der Inhalts-Längen-Header noch der Transfer-Codierungs-Header vorhanden ist. Zu diesem Zeitpunkt muss der vom Server zurückgegebene Header in der Nähe sein.
Content-Length:null
Transfer-Encoding:null
Connection:close(我不知道大小,我也用不了chunked,啥时候我关了tcp连接,就说明传输结束了)
|