Implementierungsprinzip und Prozessanalyse der TCP-Leistungsoptimierung

Drei-Wege-Handshake-Phase

Anzahl der Wiederholungsversuche für Client-SYN-Pakete

sysctl -w net.ipv4.tcp_syn_retries=6

Verwandte Einführung

Der erste Wiederholungsversuch erfolgt nach 1 Sekunde, gefolgt von insgesamt 6 Wiederholungsversuchen nach 2, 4, 8, 16 und 32 Sekunden in verdoppelter Reihenfolge. Der letzte Wiederholungsversuch wartet 64 Sekunden. Wenn immer noch kein ACK zurückgegeben wird, wird der Drei-Wege-Handshake beendet. Daher beträgt die Gesamtzeit 1+2+4+8+16+32+64=127 Sekunden, also mehr als 2 Minuten.

Größe des Server-Semi-Connection-Pools

sysctl -w net.ipv4.tcp_max_syn_backlog=16384

Ob der Syncookie-Mechanismus aktiviert werden soll, nachdem der Server-Semi-Connection-Pool voll ist

sysctl -w net.ipv4.tcp_syncookies=1

Verwandte Einführung

Wenn die SYN-Warteschlange für die halbe Verbindung voll ist, wird die Verbindung standardmäßig beendet. Dies ist nicht der Fall. Durch Einschalten der Syncookies-Funktion kann die Verbindung erfolgreich hergestellt werden, ohne die SYN-Warteschlange zu verwenden.

Syncookies funktionieren folgendermaßen: Der Server berechnet einen Wert basierend auf dem aktuellen Status und fügt ihn in die von ihm gesendete SYN+ACK-Nachricht ein. Wenn der Client die ACK-Nachricht zurücksendet, wird der Wert zur Überprüfung herausgenommen. Wenn er zulässig ist, gilt die Verbindung als erfolgreich hergestellt, wie in der folgenden Abbildung dargestellt.

• 0 bedeutet, diese Funktion auszuschalten;
• 2 bedeutet, die Funktion bedingungslos zu aktivieren;
• 1 bedeutet, dass es nur aktiviert wird, wenn die SYN-Halbverbindungswarteschlange voll ist.

Hinweis: Da Syncookie nur zur Abwehr von SYN-Flood-Angriffen verwendet wird (Angreifer erstellen in böswilliger Absicht eine große Anzahl von SYN-Nachrichten und senden sie an den Server, wodurch die SYN-Halbverbindungswarteschlange überläuft und keine normalen Clientverbindungen mehr hergestellt werden können), können viele TCP-Funktionen für auf diese Weise hergestellte Verbindungen nicht verwendet werden. Daher sollten Sie tcp_syncookies auf 1 setzen und nur aktivieren, wenn die Warteschlange voll ist.

Anzahl der Wiederholungsversuche für das SYN+ACK-Paket des Servers

net.ipv4.tcp_synack_retries=5

Verwandte Einführung

Die Standardanzahl der Wiederholungsversuche von tcp_synack_retries beträgt 5 Mal, was dem erneuten Senden von SYN durch den Client ähnelt. ​​Die Wiederholungsversuche dauern 1, 2, 4, 8 und 16 Sekunden. Nach dem letzten Wiederholungsversuch wird 32 Sekunden gewartet. Wenn immer noch kein ACK empfangen wird, wird die Verbindung geschlossen, sodass insgesamt 63 Sekunden gewartet werden müssen.

Die Größe der vollständigen Verbindungswarteschlange des Servers

Hängt von min(backlog, /proc/sys/net/core/somaxconn) ab. Ab Linux-Kernel-Version 2.2 kann der Backlog-Parameter der Listen-Funktion die Größe der Akzeptanzwarteschlange festlegen.

Darüber hinaus wird der Backlog-Parameter auch durch die Obergrenze der Warteschlangenlänge auf Linux-Systemebene begrenzt. Natürlich kann dieser obere Grenzwert auch durch den Parameter somaxconn geändert werden. somaxconn ist ein Kernelparameter und der Standardwert ist 128.

sysctl -w net.core.somaxconn=32768

Vier Wellenphasen

Als nächstes nennen wir die Partei, die die Verbindung zuerst schließt, die aktive Partei, und die Partei, die die Verbindung später schließt, die passive Partei.

Der Prozess der vier Wellen:

Tatsächlich beinhalten die vier Wellen nur zwei Arten von Nachrichten: FIN und ACK. FIN steht für Finish, also das Beenden der Verbindung. Wer eine FIN-Nachricht sendet, bedeutet damit, dass er keine Daten mehr senden wird und schließt den Übertragungskanal in diese Richtung. ACK steht für „Acknowledge“ (Bestätigen) und wird verwendet, um die andere Partei darüber zu benachrichtigen, dass Ihr Sendekanal geschlossen wurde. Wenn der aktive Teilnehmer die Verbindung schließt, sendet er eine FIN-Nachricht und der Verbindungsstatus des aktiven Teilnehmers ändert sich von ESTABLISHED zu FIN_WAIT1. Wenn die passive Partei die FIN-Nachricht empfängt, antwortet der Kernel automatisch mit einer ACK-Nachricht und der Verbindungsstatus ändert sich von ESTABLISHED zu CLOSE_WAIT. Wie der Name schon sagt, wartet er darauf, dass der Prozess die Close-Funktion aufruft, um die Verbindung zu schließen. Wenn die aktive Partei diese ACK-Nachricht empfängt, ändert sich der Verbindungsstatus von FIN_WAIT1 zu FIN_WAIT2 und der Sendekanal der aktiven Partei wird geschlossen. Schauen wir uns nun an, wie der Sendekanal der passiven Partei geschlossen wird. Wenn die passive Partei in den Zustand CLOSE_WAIT wechselt, gibt die Lesefunktion des Prozesses 0 zurück, sodass der Entwickler gezielt die Schließfunktion aufruft, wodurch der Kernel zum Senden einer FIN-Nachricht veranlasst wird. Zu diesem Zeitpunkt wird der Zustand der passiven Parteiverbindung zu LAST_ACK. Wenn die aktive Partei diese FIN-Nachricht empfängt, antwortet der Kernel automatisch mit ACK und der Verbindungsstatus ändert sich von FIN_WAIT2 zu TIME_WAIT. Unter dem Linux-System wird die Verbindung im Status TIME_WAIT nach etwa 1 Minute vollständig geschlossen. Wenn die passive Partei die ACK-Nachricht empfängt, wird die Verbindung geschlossen.

Aktive Seitenoptimierung

Warten auf ACK- und FIN-Paket-Neuübertragungszeiten

Nachdem die aktive Partei eine FIN-Nachricht gesendet hat, befindet sich die Verbindung im Zustand FIN_WAIT1, der normalerweise innerhalb von zehn Millisekunden in FIN_WAIT2 geändert werden sollte. Nur wenn die von der anderen Partei zurückgegebene ACK längere Zeit nicht empfangen wird, kann der Status FIN_WAIT1 mit dem Befehl netstat beobachtet werden. An diesem Punkt sendet der Kernel die FIN-Nachricht regelmäßig erneut, wobei die Anzahl der erneuten Übertragungen durch den Parameter tcp_orphan_retries gesteuert wird (beachten Sie, dass „orphan“ zwar „verwaist“ bedeutet, dieser Parameter jedoch nicht nur für verwaiste Verbindungen gültig ist, sondern tatsächlich für alle Verbindungen im Status FIN_WAIT1). Der Standardwert ist 0, insbesondere 8 Mal:

net.ipv4.tcp_orphan_retries = 0

Die Anzahl der verwaisten Verbindungen

net.ipv4.tcp_max_orphans = 16384

Verwandte Einführung

tcp_max_orphans definiert die maximale Anzahl verwaister Verbindungen. Wenn der Prozess die Close-Funktion aufruft, um die Verbindung zu schließen, befindet sich die Verbindung im Status FIN_WAIT1. Diese Verbindung hat nichts mit dem Prozess zu tun und wird zu einer verwaisten Verbindung. Um zu verhindern, dass zu viele verwaiste Verbindungen dazu führen, dass Systemressourcen über einen längeren Zeitraum belegt sind, stellt das Linux-System den Parameter tcp_max_orphans bereit. Wenn die Anzahl der verwaisten Verbindungen größer ist, durchlaufen die neu hinzugefügten verwaisten Verbindungen nicht mehr vier Wellen, sondern senden direkt eine RST-Reset-Nachricht, um sie zwangsweise zu schließen.

Definition einer verwaisten Verbindung: Eine Verbindung, die von einem Prozess geschlossen wird, der „close“ aufruft, wird als verwaiste Verbindung bezeichnet. Darüber hinaus kann die Shutdown-Funktion auch eine Verbindung schließen. Beide senden eine FIN-Nachricht an die andere Partei (der Shutdown-Parameter muss in SHUT_WR oder SHUT_RDWR übergeben werden, um FIN zu senden). Der Unterschied besteht darin, dass der Prozess nach dem Close-Aufruf die von der anderen Partei im halbgeschlossenen Zustand gesendeten Daten nicht empfangen kann, selbst wenn sie die aktive Partei erreichen. Wenn Sie den Befehl netstat -p verwenden, werden Sie feststellen, dass der der Verbindung entsprechende Prozessname leer ist (er hat nichts mit dem Prozess zu tun!). Auch wenn die Verbindung nach dem Aufruf der Shutdown-Funktion in den Zustand FIN_WAIT1 oder FIN_WAIT2 wechselt, handelt es sich nicht um eine verwaiste Verbindung und der Prozess kann weiterhin Daten empfangen.

Wartezeit für FIN

net.ipv4.tcp_fin_timeout = 60

Verwandte Einführung

Wenn die Verbindung ACK empfängt und in den Status FIN_WAIT2 wechselt, bedeutet dies, dass der Sendekanal der aktiven Partei geschlossen wurde. Als nächstes wartet sie, bis die andere Partei eine FIN-Nachricht sendet und den Sendekanal der anderen Partei schließt. Wenn die Verbindung zu diesem Zeitpunkt mithilfe der Shutdown-Funktion geschlossen wird, kann die Verbindung im Status FIN_WAIT2 verbleiben. Aber bei verwaisten Verbindungen, die durch die Funktion „Close“ geschlossen werden, kann dieser Zustand nicht zu lange andauern, und „tcp_fin_timeout“ steuert, wie lange die Verbindung in diesem Zustand bleibt.

TIME_WAIT-bezogene Parameter

Verwandte Einführung

TIME_WAIT ist der letzte Status der vier Wellen der aktiven Partei. Beim Empfang der FIN-Nachricht von der passiven Partei antwortet die aktive Partei mit ACK und bestätigt damit, dass der Sendekanal der anderen Partei geschlossen wurde. Die Verbindung wechselt dann in den Status TIME_WAIT und wird nach einer Wartezeit von 60 Sekunden geschlossen.

Maximale Anzahl von Verbindungen im Status TIME_WAIT

Wenn die Anzahl der TIME_WAIT-Verbindungen diesen Parameter überschreitet, durchläuft die neu geschlossene Verbindung nicht mehr TIME_WAIT und wird direkt geschlossen.

net.ipv4.tcp_max_tw_buckets = 5000

Ob Ports im TIME_WAIT-Status wiederverwendet werden sollen

Um Ports im Status TIME_WAIT wiederzuverwenden, wenn der Server aktiv Verbindungen zu Upstream-Servern initiiert, können Sie den Parameter tcp_tw_reuse auf 1 setzen. Dadurch können neue Verbindungen als Clients Ports im Status TIME_WAIT unter sicheren Bedingungen verwenden.

net.ipv4.tcp_tw_reuse = 1

Damit tcp_tw_reuse wirksam wird, muss der Parameter timestamps natürlich auf 1 gesetzt sein, was die Voraussetzung für eine sichere Wiederverwendung erfüllt (die andere Partei muss auch tcp_timestamps aktivieren):

net.ipv4.tcp_timestamps = 1

Ältere Linux-Versionen bieten auch den Parameter tcp_tw_recycle, der nicht erfordert, dass der Zustand TIME_WAIT 60 Sekunden lang besteht, was leicht zu Datenverwirrung führen kann. Es wird nicht empfohlen, ihn auf 1 zu setzen.

net.ipv4.tcp_tw_recycle = 0

Daher wurde dieser Parameter nach der Linux-Version 4.12 direkt gelöscht.

Andere Konfiguration

Der Portbereich, der vom System geöffnet werden darf

sysctl -w net.ipv4.ip_local_port_range=1024 65000

Die maximale Anzahl von Datei-Handles, die das System global zuordnen darf

sysctl -w fs.file-max=2097152

sysctl -w fs.nr_open=2097152

echo 2097152 > /proc/sys/fs/nr_open

Die Anzahl der für die aktuelle Sitzung oder den aktuellen Prozess zulässigen offenen Dateihandles

ulimit -n 1048576

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.