Замедленный запуск Linux: изменение ip route не влияет на начальное окно

Я изменил начальное окно 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

Источник

2 ответа

Решение

Я думаю, вы неправильно понимаете, как работает TCP.

Каждый отправленный пакет всегда будет объявлять окно получателя (aka. RWIN) и необязательный коэффициент масштабирования, см. RFC 1323.

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

Итак, есть два бита информации, которые являются общедоступными в пакетах TCP. RWIN на сервере и RWIN на клиенте. Обе эти цифры определяют, какой максимальный размер окна затора может быть на обоих концах.

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

RWIN на клиенте интересен, когда мы пытаемся определить скорость загрузки.

Ни одно из этих чисел не делает окно перегрузки на другом конце общедоступным.

Поэтому, если у меня RWIN 64k, окно перегрузки на сервере может иметь ЛЮБОЙ номер ниже 64k.

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

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

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

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

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

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

Источник

Размер окна будет в зависимости от того, что меньше: размер окна инициализации сервера или 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 и сам ДЕЙСТВУЕТ КАК КЛИЕНТ.

Источник
Другие вопросы по тегам