sunnybear Apr 21 2017 at 10:52

Внутренние механизмы ТСР, влияющие на скорость загрузки: часть 2

14 min

36K

WEBO Group corporate blog*nix*DevOps*Configuring Linux*Network technologies*

Translation

+14

Comments 6

vesper-bot Apr 21 2017 at 13:36

А что мешает сразу поднять cwnd до ожидаемого значения, если заранее известно, скажем, что интерфейс отдачи гигабитный и может быть полностью занят N соединениями (если у нас, например, веб-сервер)? То есть имеем пропускную способность 1Gb/s, размер пакета 1460, в среднем число соединений, скажем, 1000, и средняя задержка round-trip 100ms — тогда cwnd можно смело выставлять в величину, которая уже сразу будет забивать канал в 1mbps (125 kbytes/s)… кстати, получается 9… интересно. Но если число соединений ожидается малым, например, интерфейс внутри сети, клиентов мало, а запросов много, вариант поднять сразу. Возможным кандидатом кажется SQL-сервер.

ClausMark Apr 28 2017 at 09:25

Возможно, cwnd не выставляется константой по причине того, что сеть существует в реальном мире и RTT может сильно измениться спустя несколько TCP — сессий. Но это моё предположение.

А цикл статей хороший, автор молодец, разбирает полезные вещи. Было бы здорово ознакомиться с другими важными технологиями, работающими под капотом протоколов.

UFO landed and left these words here

akden May 9 2017 at 16:26

«Убедитесь, что параметр cwnd установлен равным 10» —
ФЕЙЛ.
Он не устанавливается в 10. Ни где. Можно только увеличить в 10 раз через sysctl. Переводите не теряя смысла в след раз.

Док-во будут или список действий и кстати причем тут вообще sysctl, это значение не так выставляется.

Подсказка

ip route | while read p; do ip route change $p initcwnd 10 initrwnd 10; done

DjOnline Oct 23 2018 at 14:12

Начальное значение окна перезагрузки можно увидеть командой ss -nli|fgrep cwnd
В современных centos 7.5 cwnd уже изначально 10. Также маштабирование окна net.ipv4.tcp_window_scaling там включено изначально.

pae174 Apr 28 2017 at 09:25

Поэтому лучше отключить SSR на сервере, чтобы улучшить производительность долгоживущих соединений.

Кроме отключения SSR имеет смысл проверить, включён ли tcp hostcache. Этот механизм сохраняет статистику по TCP соединениях с какой-либо удаленной машиной в течении некоторого времени после закрытие последнего открытого соединения с этой машиной. Если до протухания информации в host cache нам снова понадобится работать с этой машиной по TCP то мы не будет повторно заниматься медленным стартом и набором статистики а просто возьмем те RTT, cwnd и bandwidth, которые были определены за время работы предыдущих соединений и были сохранены в кэше.

Выглядит содержимое кэша примерно так:

$ sysctl net.inet.tcp.hostcache.list
net.inet.tcp.hostcache.list:
IP address        MTU  SSTRESH      RTT   RTTVAR BANDWIDTH     CWND SENDPIPE RECVPIPE HITS  UPD  EXP
172.68.10.128       0        0      3ms      4ms         0     5852        0        0 3674   10 3000
172.68.10.8         0        0     12ms     11ms         0    48679        0        0  252    1 3300
162.158.78.212      0        0    139ms     24ms         0    64363        0        0  464    3 3000

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