Linux Slow Start: Зміна маршруту ip не впливає на початкове вікно

Я змінив початкове вікно tcp на своїй машині на 10, як показано нижче

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

І змінено, tcp_slow_start_after_idleяк показано нижче

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

iP підтвердження показу маршруту наведено нижче

[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

Тепер, коли я роблю tcpdump на веб-сайті, я, здається, не бачу змін у початковому вікні, коли WIN / MSS залишається 4 за замовчуванням. 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

Я потрапив на завивку, щоб веб-сторінка вимагала близько 30 Кб даних.

[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

Що може бути неправильним у моєму підході?

Ядро

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

Як оновлення, ось ось такі результати, коли я пробую 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

Як ви бачите, WIN / MSS становить 14600/1460 = 10 у цьому випадку

Я спробував потрапити на свій сайт із самого серверного апарату через curl, і ось результат:

[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 в цьому випадку становить 32792/16396 = 2

Я думаю, ви нерозумієте, як працює TCP.

Кожен надісланий пакет завжди буде рекламувати вікно приймача (ака. RWIN) та необов'язковий коефіцієнт масштабування, див. RFC 1323

Відправник не може надсилати більше, ніж обсяг даних, зазначений у RWIN, без його отримання. Залежно від вікна перевантаженості, відправник може вирішити заповнити RWIN чи ні.

Отже, є два біти інформації, які є загальнодоступними в пакетах TCP. RWIN на сервері та RWIN на клієнті. Обидві ці цифри диктують, який максимальний розмір вікна перевантаженості може бути на обох кінцях.

RWIN на сервері цікавий, коли ми намагаємось оптимізувати продуктивність для завантаження скажімо файлів.

RWIN для клієнта цікавий, коли ми намагаємося визначити швидкість завантаження.

Жоден із цих номерів не відкриває вікно заторів на іншому кінці .

Так якщо у мене RWIN 64k, вікно перевантаженості на сервері може бути будь-яким числом менше 64k.

Єдиний спосіб визначити, яке фактичне вікно перевантаженості - це підрахунок пакетів.

Якщо я знаю:

1. Мій час в обидва кінці (RTT) становить ~ 200 мс.
2. Я щойно просив ресурс, який становить 100 к.
3. У мене RWIN 64k.

Якщо я поверну з сервера два пакети, довжиною яких 1452 байти, протягом ~ 200 мс, ймовірно, вікно перевантаженості на сервері менше 4356, тому якби було надіслано більше 3 пакети. Якби IW встановив 10, я побачив би пакет із 10 пакетів біля позначки 200 мс.

Якщо ви змінили свій IW і хочете підтвердити, що зміни працювали, вам потрібно порахувати пакети, щоб отримати оцінку щодо розміру вікна перевантаженості на сервері.

Майте на увазі, ви, мабуть, хочете подивитися на розмову безпосередньо після SYN, SYN-ACK, ACK, щоб переконатися, що ви не дивитесь на середину розмови (там, де вікно заторів може вже вирости).

Розмір вікна буде залежно від того, який розмір буде меншим: розмір вікна init сервера або клієнт RWIN. Оскільки 5840 є RWIN за замовчуванням для Linux 2.6, здається, що ваш клієнт є обмежуючим фактором тут.

Спробуйте з вікна. У Windows XP RWIN на 64 кб, новіша версія 8 к.

Джерело: http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/ (Цікава частина нижче відео)

Правка: розширення відповіді, щоб зробити її зрозумілішою:

• Під час рукостискання TCP клієнт відправляє на сервер пакет SYN, надсилаючи його максимально дозволений розмір вікна. (Як показує ваш вихід tcpdump, це 5840 байт)
• Тепер сервер відповідає SYN ACK та розміром вікна, про який хотілося б узгодити. Цей розмір вікна може бути лише меншим, ніж той, що запропонував клієнт, а не більший. Незалежно від налаштування сервера, він ніколи не може мати більший розмір вікна, ніж 5840 байт з цим клієнтом.
• Клієнт повертає ACK, і вони із задоволенням обмінюються даними.

Edit2: додані до запитання tcpdumps показують, що сервер відкриває з'єднання з google, а сам діє як Клієнт.