Der Interviewer fragte: Wie viele HTTP-Anfragen kann eine TCP-Verbindung senden?

藏色散人
Freigeben: 2023-04-11 10:36:02
nach vorne
3797 Leute haben es durchsucht

Es gab einmal so eine klassische Interviewfrage: Was passiert im Prozess von der Eingabe der URL im Browser bis zur Anzeige der Seite?

Ich glaube, dass die meisten Studenten, die sich vorbereitet haben, darauf antworten können, aber wenn Sie weiterhin fragen: Wenn der empfangene HTML-Code Dutzende von Bild-Tags enthält, auf welche Weise, in welcher Reihenfolge, wie viele Verbindungen hergestellt werden und welches Protokoll verwendet wird verwendet? Was ist mit den heruntergeladenen?

Der Interviewer fragte: Wie viele HTTP-Anfragen kann eine TCP-Verbindung senden?

Um dieses Problem zu verstehen, müssen wir zunächst die folgenden fünf Fragen lösen:

1 Trennen moderne Browser die Verbindung, nachdem eine HTTP-Anfrage abgeschlossen ist, nachdem eine TCP-Verbindung mit dem Server hergestellt wurde? Unter welchen Umständen wird die Verbindung getrennt?

2. Wie vielen HTTP-Anfragen kann eine TCP-Verbindung entsprechen?

3. Können HTTP-Anfragen zusammen in einer TCP-Verbindung gesendet werden (z. B. werden drei Anfragen zusammen gesendet und drei Antworten zusammen empfangen)?

4. Warum erfordert das Aktualisieren der Seite manchmal keinen erneuten Aufbau der SSL-Verbindung?

5. Ist die Anzahl der vom selben Host hergestellten TCP-Verbindungen im Browser begrenzt?

Erste Frage

Werden moderne Browser die Verbindung trennen, nachdem eine HTTP-Anfrage abgeschlossen ist, nachdem eine TCP-Verbindung mit dem Server hergestellt wurde? Unter welchen Umständen wird die Verbindung getrennt?

In HTTP/1.0 trennt ein Server die TCP-Verbindung, nachdem er eine HTTP-Antwort gesendet hat. Allerdings wird bei jeder Anfrage die TCP-Verbindung neu aufgebaut und getrennt, was zu kostspielig ist. Obwohl es im Standard nicht festgelegt ist, unterstützen einige Server den Keep-Alive-Header Connection:. Das bedeutet, dass Sie nach Abschluss dieser HTTP-Anfrage die von der HTTP-Anfrage verwendete TCP-Verbindung nicht trennen dürfen. Dies hat den Vorteil, dass die Verbindung wiederverwendet werden kann und beim späteren Senden von HTTP-Anfragen kein erneuter Aufbau der TCP-Verbindung erforderlich ist. Wenn die Verbindung aufrechterhalten wird, kann auch der Overhead von SSL vermieden werden Meine zwei Besuche auf www.github in kurzer Zeit. Statistik:

Der Interviewer fragte: Wie viele HTTP-Anfragen kann eine TCP-Verbindung senden?

Beim ersten Besuch sind die anfängliche Verbindung und der SSL-Overhead verschwunden Es wird die gleiche TCP-Verbindung verwendet.

Persistente Verbindung: Da TCP beibehalten wird, hat HTTP/1.1 den Connection-Header in den Standard geschrieben und ermöglicht standardmäßig persistente Verbindungen Die TCP-Verbindung zwischen dem Browser und dem Server wird für einen bestimmten Zeitraum aufrechterhalten, nicht für einen Zeitraum. Sie wird getrennt, wenn die Anfrage abgeschlossen ist. Der Interviewer fragte: Wie viele HTTP-Anfragen kann eine TCP-Verbindung senden?

Die Antwort auf die erste Frage lautet also: Standardmäßig wird eine TCP-Verbindung hergestellt und nicht getrennt. Nur die Deklaration von Connection: close im Anforderungsheader schließt die Verbindung, nachdem die Anforderung abgeschlossen ist.

Zweite Frage

Wie vielen HTTP-Anfragen kann eine TCP-Verbindung entsprechen?

Nachdem Sie die erste Frage verstanden haben, gibt es auf diese Frage bereits eine Antwort. Wenn die Verbindung aufrechterhalten wird, kann eine TCP-Verbindung mehrere HTTP-Anfragen senden.

Die dritte Frage

Können HTTP-Anfragen zusammen in einer TCP-Verbindung gesendet werden (z. B. werden drei Anfragen zusammen gesendet und drei Antworten zusammen empfangen)?

HTTP/1.1 Es gibt ein Problem. Eine einzelne TCP-Verbindung kann nur eine Anfrage gleichzeitig verarbeiten. Das bedeutet: Der Lebenszyklus von zwei Anfragen kann sich nicht vom Anfang bis zum Ende überschneiden TCP-Verbindung darf sich nicht überschneiden.

Obwohl die HTTP/1.1-Spezifikation Pipelining vorsieht, um dieses Problem zu lösen, ist diese Funktion in Browsern standardmäßig deaktiviert.

Werfen wir zunächst einen Blick darauf, was Pipelining vorschreibt:

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received. 一个支持持久连接的客户端可以在一个连接中发送多个请求(不需要等待任意请求的响应)。收到请求的服务器必须按照请求收到的顺序发送响应。
Nach dem Login kopieren

Warum der Standard so festgelegt ist, können wir grob über einen Grund spekulieren: Da es sich bei HTTP/1.1 um ein Textprotokoll handelt, kann dies bei den zurückgegebenen Inhalten nicht der Fall sein Es muss unterschieden werden, welche Anfrage gesendet wird, daher muss die Reihenfolge konsistent sein. Wenn Sie beispielsweise zwei Anfragen an den Server senden, GET/query?q=A und GET/query?q=B, und der Server zwei Ergebnisse zurückgibt, kann der Browser nicht ermitteln, welcher Anfrage die Antwort entspricht die Antwortergebnisse.

Pipelining Diese Idee sieht gut aus, aber in der Praxis gibt es viele Probleme:

Einige Proxyserver können HTTP-Pipelining nicht richtig verarbeiten.

  • Die korrekte Pipeline-Implementierung ist komplex.

  • Head-of-Line-Blockierung: Gehen Sie nach dem Aufbau einer TCP-Verbindung davon aus, dass der Client während dieser Verbindung kontinuierlich mehrere Anfragen an den Server sendet. Gemäß dem Standard sollte der Server Ergebnisse in der Reihenfolge zurückgeben, in der die Anfragen eingehen. Unter der Annahme, dass der Server viel Zeit mit der Verarbeitung der ersten Anfrage verbringt, müssen alle nachfolgenden Anfragen warten, bis die erste Anfrage abgeschlossen ist, bevor sie antworten .

  • Moderne Browser aktivieren also standardmäßig kein HTTP-Pipelining.

    HTTP2 bietet jedoch die Multiplexing-Funktion, mit der mehrere HTTP-Anfragen gleichzeitig in einer TCP-Verbindung ausgeführt werden können. Wie genau Multiplexing umgesetzt wird, ist eine andere Frage. Wir können einen Blick auf die Auswirkung der Verwendung von HTTP2 werfen.

    Der Interviewer fragte: Wie viele HTTP-Anfragen kann eine TCP-Verbindung senden?

    Grün ist die Wartezeit vom Einleiten der Anfrage bis zur Rückgabeanforderung und Blau ist die Downloadzeit der Antwort. Sie können sehen, dass sie alle in derselben Verbindung parallel abgeschlossen werden

    Diese Frage hat also auch eine Antwort: In HTTP/1.1 gibt es eine Pipelining-Technologie, die das Senden mehrerer Anfragen gleichzeitig abschließen kann. Da der Browser jedoch standardmäßig deaktiviert ist, kann dies als nicht machbar angesehen werden. Aufgrund der Multiplexing-Funktion in HTTP2 können mehrere HTTP-Anfragen parallel auf derselben TCP-Verbindung verarbeitet werden.

    Wie verbessert der Browser im Zeitalter von HTTP/1.1 die Effizienz beim Laden von Seiten? Es gibt zwei Hauptpunkte:

    • Behalten Sie die TCP-Verbindung bei, die mit dem Server hergestellt wurde, und verarbeiten Sie mehrere Anforderungen nacheinander über dieselbe Verbindung.

    • Stellen Sie mehrere TCP-Verbindungen mit dem Server her.

    Die vierte Frage

    Warum erfordert das Aktualisieren der Seite manchmal nicht die Wiederherstellung der SSL-Verbindung?

    Die Antwort finden Sie bereits in der Diskussion der ersten Frage. TCP-Verbindungen werden manchmal für einen bestimmten Zeitraum vom Browser und Server aufrechterhalten. TCP muss nicht neu eingerichtet werden und SSL verwendet natürlich das vorherige.

    Die fünfte Frage

    Hat der Browser eine Begrenzung für die Anzahl der TCP-Verbindungen, die vom selben Host hergestellt werden?

    Angenommen, wir befinden uns noch in der HTTP/1.1-Ära. Damals gab es noch kein Multiplexing. Was sollte der Browser tun, wenn er eine Webseite mit Dutzenden von Bildern erhält? Sie können definitiv nicht einfach eine TCP-Verbindung öffnen, um nacheinander herunterzuladen, da der Benutzer sonst auf jeden Fall warten muss, bis für jedes Bild eine TCP-Verbindung geöffnet wird, um HTTP-Anfragen zu senden, kann der Computer oder Server diese möglicherweise nicht verarbeiten . Wenn 1.000 Bilder vorhanden sind, können keine 1.000 TCP-Verbindungen geöffnet werden, selbst wenn Ihr Computer NAT zustimmt.

    Die Antwort lautet also: Ja. Chrome ermöglicht bis zu sechs TCP-Verbindungen zum selben Host. Es gibt einige Unterschiede zwischen verschiedenen Browsern.

    developers.google.com/web/tools/ch...

    Also zurück zur ursprünglichen Frage: Wenn der empfangene HTML-Code Dutzende von Bild-Tags enthält, auf welche Weise und in welcher Reihenfolge sind diese Bilder? Welche Verbindungen wurden hergestellt und mit welchen Protokollen wurden sie heruntergeladen?

    Wenn es sich bei den Bildern ausschließlich um HTTPS-Verbindungen und unter demselben Domänennamen handelt, bespricht der Browser nach dem SSL-Handshake mit dem Server, ob HTTP2 verwendet werden kann, und verwendet in diesem Fall die Multiplexing-Funktion, um Multiplexing für diese Verbindung durchzuführen. Es ist jedoch nicht unbedingt so, dass alle in diesem Domänennamen aufgeführten Ressourcen über eine TCP-Verbindung abgerufen werden, es ist jedoch sicher, dass wahrscheinlich Multiplexing verwendet wird.

    Was ist, wenn Sie feststellen, dass Sie HTTP2 nicht verwenden können? Oder HTTPS kann nicht verwendet werden (in Wirklichkeit ist HTTP2 auf HTTPS implementiert, sodass nur HTTP/1.1 verwendet werden kann). Der Browser stellt mehrere TCP-Verbindungen auf einem HOST her. Die maximale Anzahl der Verbindungen hängt von den Browsereinstellungen ab. Diese Verbindungen werden vom Browser verwendet, um neue Anfragen zu senden. Dann müssen andere Anfragen warten.                                                                                               PHP

Das obige ist der detaillierte Inhalt vonDer Interviewer fragte: Wie viele HTTP-Anfragen kann eine TCP-Verbindung senden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Verwandte Etiketten:
Quelle:learnku.com
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage