Langsamer Linux-Start: Das Ändern der IP-Route hat keine Auswirkungen auf das Anfangsfenster

Ich habe das TCP-Anfangsfenster in meinem Computer wie unten gezeigt auf 10 geändert

[user@site etc]$ sudo ip route change default via 17.255.209.1 dev eth0  proto static initcwnd 10 

Und geändert tcp_slow_start_after_idlewie unten gezeigt

[user@site etc]$ sudo sysctl -a | grep tcp_slow_start_after_idle
net.ipv4.tcp_slow_start_after_idle = 0

Eine Bestätigung der IP-Routenshow ist unten angegeben

[user@site etc]$ ip route show
default via 17.255.209.1 dev eth0  proto static  initcwnd 10
169.254.0.0/16 dev eth0  scope link  metric 1002
17.255.209.0/24 dev eth0  proto kernel  scope link  src 17.255.209.19

Wenn ich jetzt einen tcpdump auf der Website mache, sehe ich anscheinend keine Änderung im Anfangsfenster, wobei WIN / MSS standardmäßig 4 bleibt . 5840/1460 = 4

[user@site etc]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:17:45.048174 IP 21.101.151.198.45873 > 17.255.209.19.http: Flags [S], seq 2008673341, win 5840, options [mss 1460,sackOK,TS val 1724223146 ecr 0,nop,wscale 6], length 0

Der Curl-Treffer, den ich auf der Webseite gemacht habe, forderte ungefähr 30 KB Daten an.

[user@machine ~]$ curl http://www.site.com/js/main.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 88212  100 88212    0     0   179k      0 --:--:-- --:--:-- --:--:--  272k

Was könnte an meinem Ansatz falsch sein?

Kernel

[user~]$ uname -r
3.0.4x86_64-linode21

Als Update sind hier die Ergebnisse, wenn ich google.com versuche

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.google.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:20:28.033236 IP 17.255.209.19.42799 > 74.125.127.106.http: Flags [S], seq 3148947324, win 14600, options [mss 1460,sackOK,TS val 193695310 ecr 0,nop,wscale 4], length 0

Wie Sie sehen können, ist WIN / MSS in diesem Fall 14600/1460 = 10

Ich habe versucht, meine Site vom Server-Computer selbst durch Curl zu erreichen, und hier ist das Ergebnis:

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.site.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:25:14.584338 IP 17.255.209.19.35008 > 17.255.209.19.http: Flags [S], seq 3894567470, win 32792, options [mss 16396,sackOK,TS val 193981861 ecr 0,nop,wscale 4], length 0

WIN / MSS ist in diesem Fall 32792/16396 = 2

Ich denke, Sie verstehen falsch, wie TCP funktioniert.

Jedes gesendete Paket kündigt immer ein Empfängerfenster (auch bekannt als RWIN) und einen optionalen Skalierungsfaktor an, siehe RFC 1323

Der Absender darf nicht mehr als die im RWIN angegebene Datenmenge senden, ohne dass dies bestätigt wird. Abhängig vom Überlastungsfenster kann der Absender entscheiden, ob die RWIN ausgefüllt werden soll oder nicht.

Es gibt also zwei Informationsbits, die in den TCP-Paketen öffentlich sind. Die RWIN auf dem Server und die RWIN auf dem Client. Beide Zahlen bestimmen, wie groß das Überlastungsfenster an beiden Enden maximal sein kann.

Die RWIN auf dem Server ist interessant, wenn wir versuchen, die Leistung beispielsweise für das Hochladen von Dateien zu optimieren.

Die RWIN auf dem Client ist interessant, wenn wir versuchen, die Download-Geschwindigkeit zu bestimmen.

Keine dieser Zahlen macht das Überlastungsfenster am anderen Ende öffentlich .

Wenn ich also eine RWIN von 64 KB habe, kann das Überlastungsfenster auf dem Server eine beliebige Zahl unter 64 KB sein .

Die einzige Möglichkeit, das tatsächliche Überlastungsfenster zu bestimmen, besteht darin, Pakete zu zählen.

Wenn ich weiß:

1. Meine Roundtrip-Zeit (RTT) beträgt ~ 200ms.
2. Ich habe gerade eine Ressource angefordert, die 100.000 ist.
3. Ich habe eine RWIN von 64k.

Wenn ich 2 Pakete vom Server zurück bekomme, die innerhalb von ~ 200 ms 1452 Bytes lang sind, ist das Überlastungsfenster auf dem Server wahrscheinlich kleiner als 4356, denn wenn es größer wäre, würden 3 Pakete gesendet. Wenn IW auf 10 eingestellt wäre, würde ich einen Burst von 10 Paketen um die 200-ms-Marke sehen.

Wenn Sie Ihre IW ändern und bestätigen möchten, dass die Änderung funktioniert hat, müssen Sie die Pakete zählen , um eine Schätzung der Größe des Überlastungsfensters auf dem Server zu erhalten.

Denken Sie daran, dass Sie die Konversation wahrscheinlich direkt nach SYN, SYN-ACK, ACK anzeigen möchten, um sicherzustellen, dass Sie nicht in die Mitte einer Konversation schauen (in der das Überlastungsfenster möglicherweise bereits gewachsen ist).

Die Fenstergröße ist die kleinere: Server-Init-Fenstergröße oder Client-RWIN. Da 5840 das Standard-RWIN für Linux 2.6 ist, scheint Ihr Client hier der begrenzende Faktor zu sein.

Versuchen Sie es aus einer Windows-Box. Windows XP hat eine RWIN von 64k, neuere Version 8k.

Quelle: http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/ (Der interessante Teil befindet sich unter dem Video)

Bearbeiten: Erweitern Sie die Antwort, um sie klarer zu machen:

• Beim TCP-Handshake sendet der Client ein SYN-Paket an den Server und sendet seine maximal zulässige Fenstergröße. (Wie Ihre tcpdump-Ausgabe zeigt, sind dies 5840 Bytes)
• Der Server antwortet nun mit SYN ACK und der Fenstergröße, auf die er sich einigen möchte. Diese Fenstergröße kann nur kleiner sein als vom Kunden vorgeschlagen, nicht größer. Unabhängig davon, wie der Server konfiguriert ist, kann er mit diesem Client niemals größere Fenster als 5840 Byte haben.
• Der Kunde gibt ACK zurück und tauscht gerne Daten aus.

Edit2: Die der Frage hinzugefügten tcpdumps zeigen, wie der Server Verbindungen zu Google öffnet und sich selbst als Kunde verhält.