Powolny start systemu Linux: zmiana trasy IP nie ma wpływu na początkowe okno

Zmieniłem okno początkowe tcp na moim komputerze na 10, jak pokazano poniżej

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

I zmienione, tcp_slow_start_after_idlejak pokazano poniżej

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

potwierdzenie pokazu trasy ip znajduje się poniżej

[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

Teraz, gdy robię tcpdump na stronie, nie widzę zmiany w początkowym oknie z WIN / MSS pozostałymi 4 jako domyślnymi. 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

Zawinięcie, które zrobiłem na stronie, wymagało około 30 KB danych.

[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

Co może być nie tak w moim podejściu?

Jądro

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

Jako aktualizację, oto „wyniki, gdy próbuję google.com

[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

Jak widać, WIN / MSS wynosi 14600/1460 = 10 w tym przypadku

Próbowałem uderzyć moją stronę z samego serwera przez curl i oto wynik:

[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

W tym przypadku WIN / MSS wynosi 32792/16396 = 2

Myślę, że nie rozumiesz, jak działa TCP.

Każdy wysłany pakiet zawsze będzie reklamował okno odbiornika (inaczej RWIN) i opcjonalny współczynnik skalowania, patrz RFC 1323

Nadawca nie może wysłać więcej niż ilość danych określonych w RWIN bez potwierdzenia. W zależności od okna przeciążenia nadawca może zdecydować o uzupełnieniu RWIN lub nie.

Istnieją więc dwa bity informacji, które są publiczne w pakietach TCP. RWIN na serwerze i RWIN na kliencie. Obie te liczby określają, jaki maksymalny rozmiar okna przeciążenia może znajdować się na obu końcach.

RWIN na serwerze jest interesujący, gdy próbujemy zoptymalizować wydajność dla powiedzmy przesyłania plików.

RWIN na kliencie jest interesujący, gdy próbujemy określić prędkość pobierania.

Żadna z tych liczb nie upublicznia okna zatoru na drugim końcu .

SO jeśli mam RWIN 64k, okno przeciążenia na serwerze może być DOWOLNĄ liczbą niższą niż 64k.

Jedynym sposobem ustalenia rzeczywistego okna przeciążenia jest zliczanie pakietów.

Jeśli wiem:

1. Mój czas podróży w obie strony (RTT) wynosi ~ 200 ms.
2. Właśnie poprosiłem o zasób 100k.
3. Mam RWIN 64k.

Jeśli otrzymam z serwera 2 pakiety o długości 1452 bajtów w ciągu ~ 200 ms, prawdopodobnie okno przeciążenia na serwerze jest mniejsze niż 4356, bo gdyby były większe, wysłano by 3 pakiety. Gdyby IW był ustawiony na 10, zobaczyłbym serię 10 pakietów wokół znaku 200ms.

Jeśli zmienisz IW i chcesz potwierdzić, że zmiana zadziałała, musisz policzyć pakiety, aby uzyskać oszacowanie rozmiaru okna przeciążenia na serwerze.

Pamiętaj, że prawdopodobnie chcesz spojrzeć na rozmowę bezpośrednio po SYN, SYN-ACK, ACK, aby upewnić się, że nie patrzysz na środek rozmowy (gdzie okno przeciążenia mogło już wzrosnąć).

Rozmiar okna będzie mniejszy: rozmiar okna inicjującego serwer lub RWIN klienta. Ponieważ 5840 jest domyślnym RWIN dla Linuksa 2.6, wydaje się, że twój klient jest tutaj czynnikiem ograniczającym.

Spróbuj z okna systemu Windows. Windows XP ma RWIN 64k, nowsza wersja 8k.

Źródło: http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/ (Interesująca część znajduje się pod filmem)

Edycja: rozszerzenie odpowiedzi, aby było jaśniejsze:

• W trakcie uzgadniania TCP klient wysyła pakiet SYN do serwera, wysyłając maksymalny dozwolony rozmiar okna. (Jak pokazuje wynik tcpdump, są to 5840 bajtów)
• Serwer odpowiada teraz SYN ACK i rozmiarem okna, na które chciałby się zgodzić. Ten rozmiar okna może być mniejszy niż zaproponowany przez klienta, a nie większy. Bez względu na to, jak jest skonfigurowany serwer, nigdy nie może mieć większego rozmiaru okna niż 5840 bajtów z tym klientem.
• Klient zwraca ACK i chętnie wymienia dane później.

Edycja2: Dodane do pytania tcpdump pokazują, że serwer otwiera połączenia z Google i sam DZIAŁA JAKO KLIENT.