Назад | Перейти на главную страницу

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, окно перегрузки на сервере может быть ЛЮБОЙ номер ниже 64к.

Единственный способ определить фактическое окно перегрузки - это подсчитать количество пакетов.

Если бы я знал:

  1. Мое время приема-передачи (RTT) составляет ~ 200 мс.
  2. Я только что запросил ресурс на 100к.
  3. У меня RWIN 64k.

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

Если вы измените свой IW и хотите подтвердить, что изменение сработало, вам нужно посчитать пакеты чтобы получить оценку размера окна перегрузки на сервере.

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

Размер окна будет в зависимости от того, что меньше: размер окна инициализации сервера или RWIN клиента. Поскольку 5840 является RWIN по умолчанию для Linux 2.6, похоже, что ваш клиент является здесь ограничивающим фактором.

Попробуйте из окна Windows. Windows XP имеет RWIN 64k, более новая версия 8k.

Источник: http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/ (Интересная часть под видео)

Изменить: расширение ответа, чтобы было понятнее:

  • В квитировании TCP клиент отправляет на сервер SYN-пакет, отправляя его максимально допустимый размер окна. (Как показывает ваш вывод tcpdump, это 5840 байт)
  • Сервер теперь отвечает SYN ACK и размером окна, с которым он хотел бы согласиться. Этот размер окна может быть только меньше, чем предложил клиент, но не больше. Независимо от того, как настроен сервер, он никогда не может иметь размер окна больше, чем 5840 байт с этим клиентом.
  • Клиент возвращает ACK, и они с удовольствием обмениваются данными с тех пор.

Edit2: tcpdumps, добавленные к вопросу, показывают, что сервер открывает соединения с Google и сам ДЕЙСТВУЕТ КАК КЛИЕНТА.