Einführung
TCP ist ein WAN-orientiertes Kommunikationsprotokoll. Der Zweck besteht darin, eine Kommunikationsmethode zwischen zwei Kommunikationsendpunkten mit den folgenden Merkmalen bei der Kommunikation über mehrere Netzwerke bereitzustellen:
(1) Stream-basiert;
(2) Verbindungsorientiert;
( 3) Zuverlässige Kommunikationsmethode:
(4) Wenn die Netzwerkbedingungen nicht gut sind, versuchen Sie, den Systembandbreitenaufwand aufgrund einer erneuten Übertragung zu verringern.
(5) Die Aufrechterhaltung der Kommunikationsverbindung ist unabhängig vom Zwischennetzwerksegment und auf die beiden Kommunikationsendpunkte ausgerichtet Knoten.
Um diese Eigenschaften des TCP-Protokolls zu erfüllen, hat das TCP-Protokoll die folgenden Bestimmungen getroffen
1. Datenfragmentierung: Benutzerdaten werden am sendenden Ende fragmentiert und am empfangenden Ende neu organisiert. TCP bestimmt die Größe der Fragmente und steuert die Fragmentierung und den Zusammenbau.
2. Ankunftsbestätigung: Wenn das empfangende Ende die fragmentierten Daten empfängt, Senden Sie eine Bestätigung gemäß der Fragmentdatensequenznummer an den Absender.
3. Timeout-Neuübertragung: Der Absender startet beim Senden von Fragmenten einen Timeout-Timer. Wenn die entsprechende Bestätigung nach Ablauf des Timers nicht empfangen wird, wird das Fragment erneut übertragen.
4. Schiebefenster: Die Größe des Empfangspufferbereichs auf jeder Seite der TCP-Verbindung ist festgelegt, und das Empfangsende ermöglicht nur dem anderen Ende das Senden der Daten, die der Empfangsendepuffer akzeptieren kann. TCP bietet eine Flusssteuerung basierend auf dem Schiebefenster, um zu verhindern, dass schnellere Hosts Langsamkeit verursachen Pufferüberlauf des Hosts;
5. Verarbeitung außerhalb der Reihenfolge: TCP-Fragmente, die als IP-Datagramme übertragen werden, sind möglicherweise nicht in der richtigen Reihenfolge, wenn sie eintreffen. TCP ordnet die empfangenen Daten neu an und liefert die empfangenen Daten in der richtigen Reihenfolge an die Anwendung Schicht;
6. Doppelte Verarbeitung: TCP-Fragmente, die als IP-Datagramme übertragen werden, werden dupliziert, und der TCP-Empfänger muss die doppelten Daten verwerfen.
7. Datenüberprüfung: TCP behält die Prüfsumme seines Headers und seiner Daten bei Eine End-to-End-Prüfsumme erkennt Änderungen der Daten während der Übertragung. Wenn in der Prüfsumme des empfangenen Fragments ein Fehler auftritt, verwirft TCP das Fragment, ohne zu bestätigen, dass der Peer durch den Empfang dieses Segments eine Zeitüberschreitung verursacht und es erneut sendet.
Die obigen Konzepte stammen aus der Baidu-Enzyklopädie
Ich bin mit dem Konzept nicht sehr vertraut oder möchte das Konzept nicht mehr lesen. Lassen Sie mich also über etwas Praktisches sprechen.
Das obige Bild beschreibt detailliert den Drei-Wege-Handshake und die Vier-Zeit-Welle von TCP.
Dieses Bild ist nicht schlecht, daher wird es nicht von mir gezeichnet . Die folgende zugehörige Parameteranweisung und Optimierung kann sich auf dieses Bild beziehen. Die Zeichnung ist sehr gut. Ich werde meine Schande nicht zeigen. Es ist definitiv nicht zu faul
Das folgende ist das Optimierungsschema für bestimmte TCP-Parameter
Bitte entsprechend der aktuellen Situation optimieren! ! !
# Gibt den vom Socket überwachten Rückstand an (wenn eine Anforderung (Anforderung) nicht verarbeitet oder hergestellt wurde, geben Sie den Rückstand ein). Obergrenze
# begrenzt die Größe der Überwachungswarteschlange für den Empfang neuer TCP-Verbindungen. Für eine Hochlast-Webdienstumgebung, die häufig neue Verbindungen verarbeitet, ist der Standardwert 128 zu klein. Es wird empfohlen, diesen Wert in den meisten Umgebungen auf 1024 oder mehr zu erhöhen. Der Serverprozess begrenzt die Größe der Überwachungswarteschlange (z. B. sendmail (8) oder Apache) und bietet häufig die Möglichkeit, die Warteschlangengröße in der Konfigurationsdatei festzulegen. Große Abhörwarteschlangen helfen auch dabei, Denial-of-Service-DoS *** zu verhindern.
net.core.somaxconn = 262144# Zeigt an, dass die Wiederverwendung aktiviert ist. Zulassen, dass TIME-WAIT-Sockets für neue TCP-Verbindungen wiederverwendet werden. Der Standardwert ist 0, was bedeutet, dass er geschlossen ist
net.ipv4.tcp_tw_reuse = 1# Gibt an, dass die schnelle Wiederherstellung von TIME-WAIT-Sockets in der TCP-Verbindung aktiviert ist. Der Standardwert ist 0, was bedeutet, dass sie geschlossen ist
net.ipv4.tcp_tw_recycle = 0#keepalive Zeit behalten
net.ipv4.tcp_keepalive_time = 900# Bedeutet, dass dieser Parameter, wenn der Socket durch die lokale Anforderung geschlossen wird, die Zeit bestimmt, in der er im Status FIN-WAIT-2 bleibt (er kann auf 30 geändert werden, im Allgemeinen gibt es nur sehr wenige FIN-WAIT-2-Verbindungen).
net.ipv4.tcp_fin_timeout = 15#Portbereich für externe Verbindungen
net.ipv4.ip_local_port_range = 10000 65500#Reservierte Ports Um eine Belegung zu vermeiden, können verschiedene Ports durch Kommas getrennt werden
net.ipv4.ip_local_reserved_ports = 50010,10050,32275# Gibt die Länge der Warteschlange für Verbindungen (SYN-Nachrichten) an, die keine Client-Bestätigung erhalten haben. Der Standardwert ist 1024. Erhöhen Sie die Warteschlangenlänge auf 819200, um mehr Netzwerkverbindungen aufzunehmen, die auf eine Verbindung warten.
net.ipv4.tcp_max_syn_backlog = 819200Die Statusmenge #TIME_WAIT
# gibt an, dass das System die maximale Anzahl von TIME_WAIT-Sockets gleichzeitig beibehält. Wenn diese Anzahl überschritten wird, wird der TIME_WAIT-Socket sofort gelöscht und die Warninformationen werden gedruckt. Der Standardwert ist 180000 und wurde in 8192000 geändert. Bei Apache, Nginx und anderen Servern können die oben genannten Parameterzeilen die Anzahl der TIME_WAIT-Sockets verringern, bei Squid ist der Effekt jedoch nicht groß. Dieser Parameter kann die maximale Anzahl von TIME_WAIT-Sockets steuern, um zu verhindern, dass der Squid-Server von einer großen Anzahl von TIME_WAIT-Sockets zu Tode gezogen wird
net.ipv4.tcp_max_tw_buckets = 8192000#Dieser Parameter wird verwendet, um die maximale Anzahl von TCP-Sockets festzulegen, die im System zulässig sind und keinem Benutzerdatei-Handle zugeordnet sind. Wenn diese Anzahl überschritten wird, werden TCP-Socket-Zeichen, die nicht mit dem Dateihandle des Benutzers verknüpft sind, sofort zurückgesetzt und eine Warnmeldung ausgegeben. Diese Einschränkung dient lediglich dazu, einfache DoS-Tools zu verhindern. Wenn der Systemspeicher ausreicht, kann der Wert dieses Parameters im Allgemeinen erhöht werden:
net.ipv4.tcp_max_orphans = 3276800#CONNTRACK_MAX Der maximal zulässige Trace-Verbindungseintrag ist die "Task" (Verbindungs-Trace-Eintrag), die Netfilter gleichzeitig im Kernelspeicher verarbeiten kann
net.netfilter.nf_conntrack_max = 250000#tcp_synack_retries Zeigt an oder legt fest, wie oft der Linux-Kernel versucht, die anfänglichen SYN- und ACK-Pakete als Antwort auf die SYN-Anforderung erneut zu senden, bevor er aufgibt. Dies ist der zweite Schritt des sogenannten Drei-Wege-Handshakes. Mit anderen Worten, wie oft das System versucht, eine vom Remote-Ende initiierte TCP-Verbindung herzustellen. Der Wert von tcp_synack_retries muss eine positive Ganzzahl sein und darf 255 nicht überschreiten. Denn jedes Mal, wenn Sie ein Paket erneut senden, dauert es etwa 30 bis 40 Sekunden, bis Sie sich entscheiden, das nächste erneute Senden zu versuchen oder aufzugeben. Der Standardwert von tcp_synack_retries ist 5, dh es dauert ungefähr 180 Sekunden (3 Minuten), bis jede Verbindung das Zeitlimit ermittelt hat.
net.ipv4.tcp_synack_retries = 2#Für eine neue Verbindung, wie viele SYN-Verbindungsanforderungen muss der Kernel senden, bevor er sich entscheidet, aufzugeben. Sollte nicht größer als 255 sein, ist der Standardwert 5, was ungefähr 180 Sekunden entspricht. (Für Netzwerke mit hoher Last und guter physischer Kommunikation ist dieser Wert zu hoch und kann auf 2 geändert werden. Dieser Wert gilt nur für externe Verbindungen und für eingehende Verbindungen. Er wird durch tcp_retries1 bestimmt.)
net.ipv4.tcp_syn_retries = 2
#四种TCP状态的超时时间
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 15
net.netfilter.nf_conntrack_tcp_timeout_established = 86400 #Wenn die Erkennung nicht bestätigt wird, wird die Häufigkeit des erneuten Sendens der Erkennung angegeben. Der Standardwert beträgt 75 Sekunden.
net.ipv4.tcp_keepalive_intvl = 15#Wie viele TCP-Keepalive-Testpakete werden gesendet, bevor festgestellt wird, dass die Verbindung ungültig ist? Der Standardwert ist 9. Nachdem dieser Wert mit tcp_keepalive_intvl multipliziert wurde, wird bestimmt, wie lange keine Antwort erfolgen kann, nachdem eine Verbindung ein Keepalive gesendet hat
net.ipv4.tcp_keepalive_probes = 5#Wie oft versucht dieses Ende, es erneut zu versuchen, bevor die TCP-Verbindung geschlossen wird. Der Standardwert ist 7, was 50 Sekunden bis 16 Minuten entspricht (abhängig von RTO). Wenn Ihr Computer ein überlasteter WEB-Server ist, sollten Sie diesen Wert reduzieren, da solche Sockets viele wichtige Ressourcen verbrauchen. Siehe tcp_max_orphans.
net.ipv4.tcp_orphan_retries = 0#Unterstütztes größeres TCP-Fenster. Wenn das maximale TCP-Fenster 65535 (64 KB) überschreitet, muss dieser Wert auf 1 gesetzt werden
net.ipv4.tcp_window_scaling = 1#Wenn der Drei-Wege-Handshake für TCP zum Herstellen einer Verbindung abgeschlossen ist und die Verbindung in den Status ESTABLISHED versetzt und an die Backlog-Warteschlange der Anwendung übermittelt wird, wird geprüft, ob die Backlog-Warteschlange voll ist. Wenn es voll ist, besteht das übliche Verhalten darin, die Verbindung zum SYN_ACK-Status wiederherzustellen, um die Illusion eines versehentlichen Verlusts des ACK-Pakets am Ende des 3-Wege-Handshakes zu verursachen, sodass der Client die ACK nach dem Wartezeitlimit erneut senden kann, um erneut zu versuchen, in den Status ESTABLISHED zu wechseln Ein Reparatur- / Wiederholungsmechanismus. Wenn tcp_abort_on_overflow aktiviert ist und überprüft wird, ob die Backlog-Warteschlange voll ist, wird ein RST-Paket direkt an den Client gesendet, um die Verbindung zu beenden. Das Client-Programm erhält durch Zurücksetzen einen Peer-Fehler.
net.ipv4.tcp_abort_on_overflow = 1# Verwalten Sie die selektive Antwort von TCP, sodass das empfangende Ende die im Byte-Stream verlorene Sequenznummer an das sendende Ende weiterleiten kann, und reduzieren Sie die Anzahl der
Segmente, die erneut übertragen werden müssen, wenn das Segment verloren geht. Wenn das Segment häufig verloren geht, ist Sack sehr vorteilhaft.
net.ipv4.tcp_sack = 1#Schließen Sie den langsamen Start der TCP-Verbindungsübertragung, dh halten Sie für einen bestimmten Zeitraum an und initialisieren Sie dann das Überlastungsfenster.
net.ipv4.tcp_slow_start_after_idle = 0#Wenn die Rate, mit der jede Netzwerkschnittstelle Datenpakete empfängt, schneller ist als die Rate, mit der der Kernel diese Pakete verarbeitet, kann die maximale Anzahl von Datenpaketen an die Warteschlange gesendet werden
net.core.netdev_max_backlog = 300000
#Der vom Kernel der TCP-Verbindung zugewiesene Speicher ist Page, 1 Page = 4096 Bytes. Sie können ihn mit dem folgenden Befehl anzeigen : #getconf PAGESIZE #Die
erste Zahl gibt an, dass der Kernel die von tcp verwendete Seite nicht unter 1048576 stört.
#Die zweite Zahl bedeutet, dass der Kernel, wenn TCP mehr als 1310720 Seiten verwendet, in den Druckmodus "Speicherdruck" wechselt.
#Die dritte Zahl bedeutet, dass wenn TCP mehr als 1572864 Seiten verwendet (entspricht 1,6 GB Speicher) Bericht: Nicht genügend Socket-Speicher
net.ipv4.tcp_mem = 1048576 1310720 1572864#Die Größe des für jede TCP-Verbindung zugewiesenen Lese- und Schreibpufferspeichers ist Byte. #Die
erste Zahl gibt den für die TCP-Verbindung
zugewiesenen Mindestspeicher an. #Die zweite Zahl gibt den für die TCP-Verbindung zugewiesenen Standardspeicher an.
# 第 第Drei Zahlen geben an, dass der maximale Speicher, der für die TCP-Verbindung
# zugewiesen wurde, im Allgemeinen gemäß dem Standardwert zugewiesen wird. Das folgende Beispiel ist 8 KB zum Lesen und Schreiben, insgesamt
16 KB # 1572864 * 16 KB = 25165824 KB entsprechen 26 GB Speicher
net.ipv4.tcp_rmem = 4096 8192 16384# Standardmäßige TCP-Daten, die die Fenstergröße (Bytes) empfangen.
net.core.rmem_default = 1048576# Maximales TCP-Datenempfangsfenster (Bytes).
net.core.rmem_max = 15728640#Definieren Sie den Speicher, der von jedem Socket für die automatische Abstimmung verwendet wird.
#Der erste Wert ist die Mindestanzahl von Bytes, die dem Sendepuffer des Sockets zugewiesen sind.
#Der zweite Wert ist der Standardwert (dieser Wert überschreibt wmem_default), und der Puffer kann auf diesen Wert anwachsen, wenn die Systemlast nicht hoch ist.
#Der dritte Wert ist die maximale Anzahl von Bytes des Sendepufferbereichs (dieser Wert überschreibt wmem_max).
net.ipv4.tcp_wmem = 256000 768000 4194304# Verschiedene Arten von Sockets Standardgröße für Lese- und Schreibpuffer
net.core.wmem_default = 1048576# Verschiedene Arten von Sockets Standard-Lese- und Schreibpuffer maximal
net.core.wmem_max = 5242880#panic error Startet automatisch neu und wartet, bis das Timeout 20 Sekunden beträgt
kernel.panic = 20# Gibt die Anzahl der Dateihandles an, die auf Systemebene geöffnet werden können. Dies ist eine Einschränkung für das gesamte System, nicht für Benutzer.
fs.file-max = 6553560Viele der oben genannten Parameter sind modifizierungswürdig, nicht unbedingt erforderlich. Sie sollten sie entsprechend den tatsächlichen Anforderungen verwenden
Erwägen
Wie können diese Parameter optimiert werden? Woher weiß ich, wie ich es ändern kann?
Mein Vorschlag ist, nach der grundlegenden Optimierung zu überwachen, den Ressourcenverbrauch
von TCP zu überprüfen und zu ermitteln, wo sich die spezifische Karte befindet. Nachfolgend sind einige ungefähre Methoden zum Abrufen der TCP-Überwachung unter Linux-Systemen aufgeführt, die nur als Referenz dienen
Zeigen Sie die aktuelle Anzahl der Verbindungen an: Der
Code lautet wie folgt:
grep ip_conntrack /proc/slabinfo
ip_conntrack 38358 64324 304 13 1 : tunables 54 27 8 : slabdata 4948 4948 216Rufen Sie den aktuellen numerischen
Code jeder TCP-Handshake-Welle wie folgt ab:
# netstat -an | awk '/^tcp/ {++state[$6]} END {for (key in state) print key,"\t",state[key]}'
TIME_WAIT 1832
CLOSE_WAIT 360
FIN_WAIT2 12
ESTABLISHED 3588
SYN_RECV 148
CLOSING 7
LAST_ACK 19
LISTEN 59Finden Sie das aktuelle Ranking von ip_conntrack heraus: Der
Code lautet wie folgt:
$ cat /proc/net/nf_conntrack | cut -d ' ' -f 10 | cut -d '=' -f 2 | sort | uniq -c | sort -nr | head -n 10um zusammenzufassen
Es ist besser, die Parameter an die tatsächliche Situation anzupassen, es ist die wissenschaftlichste, nicht blind zu erhöhen oder einen einheitlichen Ansatz zu wählen