Как стать автором
Обновить

Комментарии 6

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

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

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

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

Подсказка
ip route | while read p; do ip route change $p initcwnd 10 initrwnd 10; done

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

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

Зарегистрируйтесь на Хабре , чтобы оставить комментарий