Analysieren Sie häufige Faktoren, die sich auf die HTTP-Leistung auswirken

Der Hauptinhalt dieses Artikels besteht darin, die allgemeinen Faktoren vorzustellen, die sich auf die HTTP-Leistung auswirken. Interessierte Freunde können mehr darüber erfahren.

Die hier besprochene HTTP-Leistung basiert auf dem einfachsten Modell, nämlich der HTTP-Leistung eines einzelnen Servers. Dies ist natürlich auch auf große Lastausgleichscluster anwendbar auch aus mehreren HTTP-Servern zusammengesetzt. Darüber hinaus schließen wir auch aus, dass die Belastung des Clients oder Servers selbst zu hoch ist oder dass die Software, die das HTTP-Protokoll implementiert, unterschiedliche IO-Modelle verwendet. Darüber hinaus ignorieren wir auch Fehler im DNS-Auflösungsprozess und bei der Webanwendungsentwicklung selbst.

Aus Sicht des TCP/IP-Modells ist die untere Schicht von HTTP die TCP-Schicht, daher hängt die Leistung von HTTP weitgehend von der Leistung von TCP ab. Wenn es sich um HTTPS handelt, hängt die Leistung von TLS/ natürlich stark ab. Es muss eine SSL-Schicht hinzugefügt werden, aber es ist sicher, dass die Leistung von HTTPS definitiv schlechter ist als die von HTTP. Der Kommunikationsprozess wird hier nicht besprochen. Kurz gesagt, je mehr Schichten vorhanden sind, desto gravierender ist der Leistungsverlust Sei.

Unter den oben genannten Bedingungen gehören zu den häufigsten Faktoren, die sich auf die HTTP-Leistung auswirken:

• TCP-Verbindungsaufbau, also die Drei-Wege-Handshake-Phase

• TCP Langsamer Start

• TCP verzögerte Bestätigung

• Nagle-Algorithmus

• TIME_WAIT-Ansammlung und Port erschöpft

• Server-Port erschöpft

• Die Anzahl der geöffneten Dateien im Server-HTTP-Prozess hat das Maximum erreicht

TCP-Verbindungsaufbau

Wenn das Netzwerk stabil ist, nimmt der TCP-Verbindungsaufbau normalerweise nicht viel Zeit in Anspruch und der Drei-Wege-Handshake-Prozess wird innerhalb eines angemessenen Zeitaufwands abgeschlossen Da HTTP jedoch zustandslos ist und es sich um eine kurze Verbindung handelt, wird die TCP-Verbindung normalerweise über viele Ressourcen getrennt, was bedeutet, dass es viele HTTP-Sitzungen gibt Bei einer HTTP-Sitzung ist der TCP-Drei-Wege-Handshake zum Herstellen der Verbindung zu zeitaufwändig. Natürlich können Sie vorhandene Verbindungen wiederverwenden, um die Anzahl der TCP-Verbindungsaufbauzeiten zu reduzieren.

TCP-Langsamstart

TCP-Überlastungskontrollmethode¹, in der ersten Übertragungsphase nach dem Aufbau von TCP wird die maximale Übertragungsgeschwindigkeit der Verbindung begrenzt Die Datenübertragung ist erfolgreich. Die Übertragungsgeschwindigkeit wird in Zukunft schrittweise erhöht, was als langsamer TCP-Start bezeichnet wird. Der langsame Start begrenzt die Anzahl der IP-Pakete ², die gleichzeitig übertragen werden können. Warum gibt es also einen langsamen Start? Der Hauptzweck besteht darin, zu verhindern, dass das Netzwerk aufgrund der großen Datenübertragung im Internet lahmgelegt wird. Darüber hinaus ist der Router selbst nicht schnell Wenn die Datenmenge, die in einem bestimmten Zeitraum beim Router ankommt, viel größer ist als die gesendete Menge, verwirft der Router die Datenpakete, wenn der lokale Cache erschöpft ist Ein solches Verhalten wird als Überlastung bezeichnet. Es beeinträchtigt viele Verbindungen und kann in schweren Fällen zu einer großflächigen Lähmung führen. Daher muss jede Partei in der TCP-Kommunikation eine Überlastungskontrolle durchführen, und der langsame Start ist einer der Algorithmen oder Mechanismen der Überlastungskontrolle.
Sie stellen sich eine Situation vor. Wir wissen, dass ein Router im Netzwerk aufgrund einer Überlastung einen großen Paketverlust erleidet. Dann wird der TCP-Neuübertragungsmechanismus gestartet, und der vom Router betroffene Absender muss mehr als nur Sie sein. Dann hat eine große Anzahl von Absender-TCP-Protokollstapeln mit der Neuübertragung begonnen, was dem Senden weiterer Daten im ursprünglich überlasteten Netzwerk entspricht , das ist gleichbedeutend damit, Öl ins Feuer zu gießen.

Aus der obigen Beschreibung kann geschlossen werden, dass selbst in einer normalen Netzwerkumgebung als Absender von HTTP-Nachrichten der Aufbau einer TCP-Verbindung bei jeder Anfrage durch einen langsamen Start beeinträchtigt wird. Eine kurze Verbindung ist eine Sitzung, die beendet wird. Sie können sich vorstellen, dass der Client eine HTTP-Anfrage initiiert und gerade eine Ressource auf der Webseite erhalten hat. Möglicherweise wurde die TCP-Verbindung getrennt Bevor der langsame TCP-Startvorgang abgeschlossen wurde, werden die nachfolgenden Ressourcen weiterhin TCP-Verbindungen herstellen, und jede TCP-Verbindung hat eine langsame Startphase. Wir können uns also vorstellen, die Leistung zu verbessern Aktivieren Sie persistente HTTP-Verbindungen, das später erwähnte Keepalive.

Außerdem wissen wir, dass es in TCP das Konzept eines Fensters gibt. Dieses Fenster existiert sowohl auf dem Sender als auch auf dem Empfänger. Die Rolle des Fensters stellt sicher, dass Sender und Empfänger bei der Verwaltung des Pakets ordnungsgemäß vorgehen Andererseits gibt es mehrere Pakete, die nacheinander gesendet werden können, um den Durchsatz zu verbessern. Ein weiterer Punkt besteht darin, dass die Fenstergröße angepasst werden kann. Der Zweck besteht darin, zu verhindern, dass der Sender Daten schneller sendet, als der Empfänger sie empfangen kann . Obwohl das Fenster das Problem der doppelten Übertragungsgeschwindigkeit löst, passieren andere Netzwerkgeräte das Netzwerk. Woher kennt der Absender die Empfangsfähigkeit des Routers? Es gibt also die oben eingeführte Staukontrolle.

TCP-verzögerte Bestätigung

Zunächst müssen Sie wissen, was eine Bestätigung ist. Das bedeutet, dass der Absender ein TCP-Segment an den Empfänger sendet Bestätigung, um den Empfang anzuzeigen. Wenn der Absender die Bestätigung nicht innerhalb eines bestimmten Zeitraums erhält, muss das TCP-Segment erneut gesendet werden.

Bestätigungsnachrichten sind normalerweise relativ klein, das heißt, ein IP-Paket kann mehrere Bestätigungsnachrichten enthalten. Um zu vermeiden, dass zu viele kleine Nachrichten gesendet werden, wartet der Empfänger beim Zurücksenden der Bestätigungsnachricht darauf, ob es noch andere gibt Wenn ja, fügen Sie die Bestätigungsnachricht und die Daten in einem TCP-Segment zusammen und senden Sie es. Wenn innerhalb eines bestimmten Zeitraums keine anderen Daten gesendet werden müssen, beträgt der Inhalt normalerweise 100-200 Millisekunden. Senden Sie die Bestätigungsnachricht in einem separaten Paket. Tatsächlich besteht der Zweck darin, die Netzwerkbelastung so weit wie möglich zu reduzieren.

Ein häufiges Beispiel ist die Logistik. Wenn es sich um eine 10-Tonnen-Ladung von Stadt A nach Stadt B handelt, möchten Sie auf jeden Fall, dass sie so voll wie möglich ist Mit einem kleinen Paket stehst du sofort auf und fährst in die Stadt B.

TCP ist also nicht darauf ausgelegt, sofort eine ACK-Bestätigung zurückzugeben, wenn ein Datenpaket eintrifft. Es sammelt sich normalerweise für einen bestimmten Zeitraum im Cache an und sendet es zurück Sie können jedoch nicht zu lange warten, da die andere Partei sonst denkt, dass das Paket verloren gegangen ist, und eine erneute Übertragung von der anderen Partei auslöst.

Verschiedene Betriebssysteme haben unterschiedliche Meinungen darüber, ob und wie die verzögerte Bestätigung verwendet werden soll. Wenn Sie sie beispielsweise deaktivieren, müssen Sie sie jeweils sofort bestätigen.

Es ist zu beachten, dass es vom Szenario abhängt, ob es aktiviert ist oder wie viele Millisekunden eingestellt werden müssen. In Online-Gaming-Szenarien muss die Bestätigung beispielsweise so schnell wie möglich erfolgen, und eine verzögerte Bestätigung kann für SSH-Sitzungen verwendet werden.

Für HTTP können wir die verzögerte TCP-Bestätigung deaktivieren oder anpassen.

Nagle-Algorithmus

Dieser Algorithmus ist eigentlich darauf ausgelegt, die Nutzung von IP-Paketen zu verbessern und die Netzwerklast zu reduzieren. Er umfasst immer noch kleine Pakete und Pakete voller Größe (gemäß Ethernet-Standards beträgt die MTU 1500 Bytes pro Nachricht). , und jede Nachricht mit weniger als 1500 wird als nicht vollständige Nachricht betrachtet), aber egal wie klein die kleine Nachricht ist, sie wird nicht weniger als 40 Bytes sein, da der IP-Header und der TCP-Header jeweils 20 Bytes belegen. Wenn Sie eine kleine Nachricht von 50 Bytes senden, bedeutet dies tatsächlich, dass zu wenig gültige Daten vorhanden sind. Ebenso wie die verzögerte Bestätigung stellen kleine Pakete im LAN kein großes Problem dar, sondern wirken sich hauptsächlich auf das WAN aus.

Dieser Algorithmus besteht eigentlich darin, dass der Absender, wenn er in der aktuellen TCP-Verbindung eine Nachricht gesendet, aber keine Bestätigung erhalten hat, diese nicht senden kann, wenn er noch kleine Nachrichten zu senden hat Im Puffer abgelegt, um auf die Bestätigung der zuvor gesendeten Nachricht zu warten. Nach Erhalt der Bestätigung sammelt der Absender die kleinen Nachrichten in der gleichen Richtung im Cache und fügt sie zum Senden zu einer Nachricht zusammen. Tatsächlich bedeutet dies, dass der Sender umso schneller Daten senden kann, je schneller der Empfänger die ACK-Bestätigung zurückgibt.

Lassen Sie uns nun über die Probleme sprechen, die sich aus der Kombination von verzögerter Bestätigung und dem Nagle-Algorithmus ergeben. Tatsächlich ist leicht zu erkennen, dass der Empfänger aufgrund der verzögerten Bestätigung für einen bestimmten Zeitraum ACK-Bestätigungen ansammelt und der Absender die verbleibenden, nicht vollständigen Daten nicht weiter sendet, wenn er währenddessen keine ACK erhält Pakete (Die Daten werden in mehrere IP-Pakete aufgeteilt. Die Anzahl der vom Absender zu sendenden Antwortdatenpakete darf kein ganzzahliges Vielfaches von 1500 sein. Es besteht eine hohe Wahrscheinlichkeit, dass einige Daten am Ende der Daten klein sind. Der Widerspruch besteht darin, dass diese Art von Problem die Übertragungsleistung bei der TCP-Übertragung beeinträchtigt. Dann hängt HTTP von TCP ab, sodass es sich natürlich auf die HTTP-Leistung auswirkt Wir können es im Betriebssystem oder in HTTP deaktivieren. Stellen Sie TCP_NODELAY im Programm ein, um diesen Algorithmus zu deaktivieren. In Nginx können Sie es beispielsweise mit tcp_nodelay on; deaktivieren.

TIME_WAIT-Akkumulation und Port-Erschöpfung³

Dies bezieht sich auf die Partei, die der Client ist, oder auf die Partei, die die TCP-Verbindung aktiv schließt, obwohl der Server dies auch übernehmen kann Initiative Initiieren Sie das Schließen, aber was wir hier besprechen, ist die HTTP-Leistung. Aufgrund der Eigenschaften von HTTP-Verbindungen initiiert der Client normalerweise das aktive Schließen.

Der Client initiiert eine HTTP-Anfrage (hier für eine bestimmte Ressource). Anstatt eine sogenannte Homepage zu öffnen, verfügt eine Homepage über N Ressourcen, daher werden N HTTP-Anfragen initiiert. Nachdem diese Anfrage abgeschlossen ist, wird die TCP-Verbindung getrennt und der TCP-Status der Verbindung auf dem Client angezeigt . Von diesem Zustand bis zum endgültigen Herunterfahren dauert es normalerweise 2MSL⁴. Wir wissen, dass der Client seinen eigenen zufälligen High-Bit-Port verwendet Stellen Sie eine Verbindung zum 80- oder 443-Port des Servers her, um eine HTTP-Kommunikation herzustellen (im Wesentlichen die TCP-Kommunikation), was bedeutet, dass die Anzahl der verfügbaren Ports auf dem Client belegt wird, obwohl der Client die Verbindung trennt Wenn der Client die Verbindung aktiv trennt, wird der TCP-Status während des 2MSL-Zeitraums zwischen TIME_WAIT und dem tatsächlichen CLOSED nicht verwendet (wenn der Client erneut HTTP-Zugriff auf denselben Server initiiert). Einer seiner Zwecke besteht darin, schmutzige Daten auf dem Server zu verhindern Gleicher TCP-Socket. Aus der obigen Schlussfolgerung wissen wir, dass, wenn der HTTP-Zugriff des Clients auf den Server zu intensiv ist, die Geschwindigkeit der Portnutzung höher sein kann als die Geschwindigkeit der Portfreigabe, was letztendlich dazu führt, dass keine Verbindung hergestellt werden kann, da kein Zufall verfügbar ist Hafen.

Wie oben erwähnt, schließt der Client die Verbindung normalerweise aktiv,

TCP/IP Detaillierte Erklärung Band 1 Zweite Ausgabe, P442, im letzten Absatz heißt es, dass bei interaktiven Anwendungen der Client normalerweise einen aktiven Herunterfahrvorgang ausführt und in den TIME_WAIT-Status wechselt und der Server normalerweise einen passiven Herunterfahrvorgang durchführt und es wird nicht direkt in den TIME_WAIT-Status versetzt.

Wenn auf dem Webserver jedoch Keep-Alive aktiviert ist, wird der Server automatisch heruntergefahren, wenn das Zeitlimit erreicht ist. (Ich sage nicht, dass die ausführliche Erklärung von TCP/IP hier falsch ist, aber sie bezieht sich in diesem Abschnitt hauptsächlich auf TCP und führt HTTP nicht ein, und es heißt eher normalerweise als notwendig)

Ich verwende Nginx wurde getestet und keepalive_timeout 65s; wurde in der Konfigurationsdatei eingestellt. Die Standardeinstellung von Nginx ist 0, was bedeutet, dass Keepalive deaktiviert wird, wie unten gezeigt:

Ich verwende Unten greift der Chrom-Browser standardmäßig auf die von Nginx bereitgestellte Homepage zu und überwacht den gesamten Kommunikationsprozess über das Paketerfassungsprogramm, wie unten gezeigt:

Wie oben ersichtlich ist Abbildung: Es werden effektive Daten übertragen. Nach Abschluss erscheint in der Mitte eine mit Keep-Alive markierte Kommunikation und der Server trennt aktiv die Verbindung, wenn innerhalb von 65 Sekunden keine Anfrage erfolgt. In diesem Fall wird auf dem Nginx-Server der Status TIME_WAIT angezeigt.

Der Server-Port ist erschöpft

Manche Leute sagen, dass Nginx auf 80 oder 443 lauscht. Der Client verbindet sich immer mit diesem Port. Wie kann der Server den Port beenden? Genau wie im Bild unten (ignorieren Sie TIME_WAIT im Bild, der Grund dafür wurde oben erwähnt und wird durch die keepalive_timeout-Einstellung von Nginx verursacht)

Eigentlich hängt es von Nginx ab Wenn wir Nginx verwenden, arbeiten wir im Arbeitsmodus normalerweise im Proxy-Modus, was bedeutet, dass sich die tatsächlichen Ressourcen oder Daten in der Back-End-Webanwendung wie Tomcat befinden. Das Merkmal des Proxy-Modus besteht darin, dass der Proxy-Server im Namen des Benutzers zum Backend geht. Zu diesem Zeitpunkt ist Nginx ein Client relativ zum Backend-Server. Zu diesem Zeitpunkt verwendet Nginx einen zufälligen Port zum Initiieren eine Anfrage an das Backend, und das System ist verfügbar. Der zufällige Portbereich ist sicher. Sie können den Befehl sysctl net.ipv4.ip_local_port_range verwenden, um den zufälligen Portbereich auf dem Server anzuzeigen.

Durch die verzögerte Bestätigung, den Nagle-Algorithmus und den Proxy-Modus, die wir zuvor eingeführt haben, fungiert Nginx als Client des Backends und verwendet einen zufälligen Port, um eine Verbindung zum Backend herzustellen, was bedeutet, dass das Risiko einer Porterschöpfung auf dem Server besteht Seite existiert. Es kann zu einer zufälligen Portfreigabegeschwindigkeit kommen, wenn diese langsamer ist als die Geschwindigkeit beim Verbindungsaufbau mit dem Backend. Diese Situation tritt jedoch im Allgemeinen nicht auf. Zumindest habe ich dieses Phänomen im Nginx unseres Unternehmens nicht gefunden. Denn erstens befinden sich statische Ressourcen im CDN; zweitens nutzt der Großteil des Backends REST-Schnittstellen, um Benutzerauthentifizierung oder Datenbankoperationen bereitzustellen. Tatsächlich sind diese Vorgänge grundsätzlich sehr schnell, wenn es im Backend keine Engpässe gibt. Wenn das Backend jedoch tatsächlich einen Engpass aufweist und die Kosten für die Erweiterung oder Änderung der Architektur relativ hoch sind, sollten Sie bei einem hohen Maß an Parallelität den Fluss begrenzen, um zu verhindern, dass das Backend zerstört wird.

Die Anzahl der vom serverseitigen HTTP-Prozess geöffneten Dateien erreicht das Maximum

Wir haben gesagt, dass die HTTP-Kommunikation auf TCP-Verbindungen basiert. Für Unix-ähnliche Systeme , Öffnen eines Sockets Das Wort besteht darin, eine Datei zu öffnen. Wenn 100 Anfragen zum Herstellen einer Verbindung zum Server vorliegen, öffnet der Server nach erfolgreichem Verbindungsaufbau 100 Dateien und gibt die Anzahl der Dateien an, die ein Prozess öffnen kann Das Linux-System ist eingeschränkt ulimit -f. Wenn dieser Wert zu klein ist, wirkt sich dies auch auf die HTTP-Verbindung aus. Bei Nginx oder anderen HTTP-Programmen, die im Proxy-Modus ausgeführt werden, öffnet normalerweise eine Verbindung zwei Sockets und belegt zwei Dateien (außer wenn sie auf den lokalen Cache von Nginx trifft oder Nginx Daten direkt zurückgibt). Daher muss auch die Anzahl der Dateien, die vom Proxy-Server-Prozess geöffnet werden können, größer eingestellt werden.

Dauerhafte Verbindung Keepalive

Zunächst müssen wir wissen, dass Keepalive auf zwei Ebenen eingestellt werden kann und die beiden Ebenen unterschiedliche Bedeutungen haben. Keepalive von TCP ist ein Erkennungsmechanismus, den wir häufig als Hinweis darauf verwenden, dass die andere Partei immer noch online ist. Dies bedeutet, dass die TCP-Verbindung untereinander immer geöffnet bleiben muss -alive in HTTP ist ein Mechanismus zur Wiederverwendung von TCP-Verbindungen, um den häufigen Aufbau von TCP-Verbindungen zu vermeiden. Sie müssen also verstehen, dass TCP Keepalive und HTTP Keep-alive nicht dasselbe sind.

HTTP-Keep-Alive-Mechanismus

Nicht persistente Verbindungen trennen die TCP-Verbindung, nachdem jede HTTP-Transaktion abgeschlossen ist, und die nächste HTTP-Transaktion stellt die TCP-Verbindung wieder her. Dies ist offensichtlich nicht der Fall ein Problem. Dies ist ein effizienter Mechanismus, sodass HTTP in den erweiterten Versionen von HTTP/1.1 und HTTP/1.0 die TCP-Verbindung nach dem Ende der Transaktion offen halten darf, sodass nachfolgende HTTP-Transaktionen die Verbindung wiederverwenden können, bis der Client oder Der Server schließt die Verbindung aktiv. Dauerhafte Verbindungen reduzieren die Anzahl der TCP-Verbindungsaufbauten und minimieren außerdem die durch den langsamen TCP-Start verursachten Verkehrseinschränkungen.

Verwandte Tutorials: HTTP-Video-Tutorial

Sehen Sie sich dieses Bild noch einmal an. Das keepalive_timeout 65s im Bild ist so eingestellt, dass HTTP aktiviert bleibt. Die Alive-Funktion hat das Timeout auf 65 Sekunden eingestellt. Tatsächlich ist keepalive_requests 100; die maximale Anzahl von HTTP-Anfragen, die von derselben TCP-Verbindung initiiert werden können.

Keep-Alive wird in HTTP/1.0 standardmäßig nicht verwendet. Wenn der Client eine HTTP-Anfrage sendet, muss dieser den Header Connection: Keep-alive enthalten, um zu versuchen, Keep-Alive zu aktivieren , wird es nicht verwendet. Alle Anfragen werden in der regulären Form gestellt und Connection: Keep-alive Informationen werden auch in den Antwortheader aufgenommen, wenn der Server dies unterstützt.

Keep-Alive wird standardmäßig in HTTP/1.1 verwendet. Sofern nicht anders angegeben, sind alle Verbindungen dauerhaft. Wenn Sie die Verbindung nach dem Ende einer Transaktion schließen möchten, muss der HTTP-Antwortheader den Connection: CLose-Header enthalten, andernfalls bleibt die Verbindung immer offen. Natürlich kann sie nicht immer geöffnet sein, und auch inaktive Verbindungen müssen geschlossen werden wie bei Nginx oben. Die Einstellung entspricht der Aufrechterhaltung einer Leerlaufverbindung für bis zu 65 Sekunden. Danach trennt der Server die Verbindung aktiv.

TCP-Keepalive

Es gibt keinen einheitlichen Schalter zum Ein- oder Ausschalten der TCP-Keepalive-Funktion unter Linux. Überprüfen Sie die System-Keepalive-Einstellungensysctl -a | grep tcp_keepalive Auf dem System wird Folgendes angezeigt:

net.ipv4.tcp_keepalive_intvl = 75   # 两次探测直接间隔多少秒
net.ipv4.tcp_keepalive_probes = 9   # 探测频率
net.ipv4.tcp_keepalive_time = 7200  # 表示多长时间进行一次探测，单位秒，这里也就是2小时

Gemäß den Standardeinstellungen besteht die allgemeine Bedeutung des oben Gesagten darin, einmal alle 2 Stunden zu erkennen, und nach 75 Sekunden erneut zu erkennen 9 Mal wird die Initiative ergriffen.

So aktivieren Sie Keepalive auf TCP-Ebene. Es gibt eine Anweisung in Nginx, die im Serverabschnitt verwendet wird, um festzulegen, welchen Port Nginx überwacht. Es gibt andere Parameter, die zum Festlegen der Socket-Eigenschaften verwendet werden. Sehen Sie sich die folgenden Einstellungen an: listen

# 表示开启，TCP的keepalive参数使用系统默认的
listen       80 default_server so_keepalive=on;
# 表示显式关闭TCP的keepalive
listen       80 default_server so_keepalive=off;
# 表示开启，设置30分钟探测一次，探测间隔使用系统默认设置，总共探测10次,这里的设
# 置将会覆盖上面系统默认设置
listen       80 default_server so_keepalive=30m::10;

Ob dies so_keepalive auf Nginx festgelegt wird, hängt vom jeweiligen Szenario ab Nginx aktiviert so_keepalive nicht, es hat keine Auswirkungen auf Ihre HTTP-Anfrage, die die Keep-Alive-Funktion verwendet. Wenn zwischen dem Client und Nginx direkt oder zwischen Nginx und dem Backend-Server ein Lastausgleichsgerät vorhanden ist und Antworten und Anforderungen über dieses Lastausgleichsgerät weitergeleitet werden, sollten Sie auf so_keepalive achten. Im direkten Routing-Modus von LVS ist dies beispielsweise nicht betroffen, da die Antwort nicht über

LVS erfolgt. Im NAT-Modus müssen Sie jedoch darauf achten, da LVS auch eine Dauer hat Um die TCP-Sitzung aufrechtzuerhalten, trennt LVS die TCP-Verbindung, bevor der Client die Daten empfängt.

---

1. Die TCP-Überlastungskontrolle verfügt über einige Algorithmen, darunter langsamer TCP-Start, Überlastungsvermeidung und andere Algorithmen ↩

2. Einige davon wird auch IP-Fragmentierung genannt, aber es bedeutet alles dasselbe: Verschiedene Datenverbindungen haben unterschiedliche MTUs. In einigen Szenarien sind es 1492 Bytes Die MTU von FDDI ist eine andere Größe, wenn man die IP-Schicht allein betrachtet. ↩

3. Auf Seite P90 des „HTTP Authoritative Guide“ wird nicht ganz klar dargelegt, ob Diese Situation bezieht sich auf den Client oder den Server, da dies sehr wahrscheinlich missverstanden wird. Dies bedeutet natürlich nicht, dass dem Server nicht die Ports ausgehen, daher habe ich hier zwei Inhalte hinzugefügt↩

4. Die längste Zeit wird 2 Minuten nicht überschreiten↩

Verwandte Tutorials:

HTTP-Video-Tutorial

Das obige ist der detaillierte Inhalt vonAnalysieren Sie häufige Faktoren, die sich auf die HTTP-Leistung auswirken. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!