nicht angemeldet
Moin!
Nu wird's theoretisch. Und es bezieht sich auf Pings, Latenzen und Onlinespiele.
Was mir vertraut ist: Die MTU. Der Wert regelt die Größe der Pakete. Weil jedes Paket ja nun Headerdaten und Checksumme enthält sendet man lieber ein Paket als zwei, und spart ein paar Byte. Man versucht also ein möglichst großes Paket zu generieren, das nicht vom Router fragmentiert wird (man aalso wieder 2 Pakete hat).
Die MTU wird, wenn keine gehirntot konfigurierte Firewall die dabei beteiligten ICMP-Pakete ausfiltert, durchaus dynamisch pro Übertragungsstrecke ausgehandelt, indem durchleitende Router die Info, dass sie ein Paket fragmentieren mussten oder müssten, zurückschicken mit der maximal erlaubten Paketgröße (nennt sich Path MTU Discovery). Insbesondere in lokalen Netzen, die via DSL ins Netz gehen, kann das aber auch falsch konfiguriert sein: 1500 Bytes gehen als Nutzdaten in ein Ethernet-Paket (Gigabit-Ethernet erlaubt auch Jumbo-Frames, um die nutzbare Datenrate zu erhöhen), aber DSL selbst nutzt für das PPPoE-Protokoll auch Ethernet-Frames, muss dorthinein aber noch eigene Adressinformationen packen, so dass 8 Byte weniger für die Nutzdaten zur Verfügung stehen. Normalerweise sollte ein vernünftiger DSL-Router per DHCP die MTU-Info "1492 Byte" an die Clients rausgeben, aber der Client muss sich ja nicht dran halten, sondern kann auch selbst auf die Nase fallen. Oder gar nicht auf DHCP konfiguriert sein.
Gut. Soweit zur Theorie. Womit ich mich nun nicht auskenne: die TCP ACK Frequenz. Diese regelt, soweit ich das verstanden habe, Die Wartezeit, bis ein Paket als vollständig deklariert wird. Um Geschwindigkeitsverbesserungen zu erreichen, soll dieser Wert nun möglichst gering (1) eingestellt werden. Es werden also, so verstehe ich das, in schnellerer Reihenfolge Pakete versendet - zur Not fast leere - hauptsache weg.
Die TCP ACK Frequenz regelt, wie schnell auf eintreffende TCP-Pakete mit einem ACK-Paket reagiert wird. Ein ACK-Paket enthält außer den notwendigen Flags (eben ACK) und den IP-Adressen keine Daten, ist also sehr klein: 64 Byte.
Jetzt ist's eine Frage der Implementierung des Datentransfers zwischen Server und Client: Wartet der Server bei jedem Paket auf ein ACK, ist es ungünstig, wenn der Client erst nach einer Wartezeit von vielleicht 200 Millisekunden pauschal alle bis dahin eingetroffenen Datenpakete quittiert.
Anders herum: Es ist im Regelbetrieb deutlich performanter, wenn die Anzahl an kleinen ACK-Paketen möglichst gering bleibt, der Server also einfach auf Vorrat TCP-Pakete schickt, und der Client mehrere Pakete mit nur einem einzigen ACK bestätigt.
Hier nun meine Frage: Einerseits versuche ich also möglichst große Pakete zu verschicken und auf der anderen Seite möglichst viele, auch winzige, um den Ping zu verbessern? Das klingt doch erstmal paradox. Dann kann ich auch die MTU einfach runtersetzen und schicke dann dauernd winzige Pakete.
Du vergleichst hier Äpfel und Birnen. Große Pakete willst du haben, um effizient Datenmassen zu bewegen. Wenn der Server aber bei jedem Paket erst das ACK abwartet, bevor das nächste Paket gesendet wird, dann willst du tatsächlich unverzüglich jedes Paket mit ACK beantworten. Wenn der Server dies aber nicht tut (das ist der Regelfall), dann sparst du dir einen nennenswerten Teil deiner Upstream-Bandbreite, indem die Datenmenge für ACK verringert wird, wenn nicht jedes Paket einzeln quittiert wird.
Denn parallel zu dem Datenstrom der ACK-Pakete, die du nicht kleiner oder größer kriegst, wandern ja von deiner Seite her auch Daten zum Server - und die wollen in möglichst großen Paketen reisen.
- Sven Rautenberg