Модели TCP

[@nadz]

На данный момент ядро linux поддерживает более десятка алгоритмов. Есть чем поиграться кроме параметров ядра.
Был бы счастлив, если бы подсказали как конкретно с ними работать: включать, выключать и т.д.

[@bosha]

Это легко можно нагуглить, а учитывая, что это возможности ядра, то логично (и правильно) предположить, что можно настроить через /proc или sysctl.

[@nadz]

sysctl -w net.ipv4.tcp_congestion_control=westwood

Просто всегда приятно иметь в одном месте (статье) именно то, о чём она повествует в полном объеме.

[@casperrr]

Ну для полноты можно упомянуть, что конкретные реализации могут быть включены/выключены при сборке ядра и соответственно может статься, что конкретный алгоритм отсутствует и включить его указанным способом нельзя.

[@Envek]

А посмотреть список доступных алгоритмов можно так:
ls /lib/modules/ВЕРСИЯ_ВАШЕГО_ЯДРА/kernel/net/ipv4/tcp_*.ko
На месте звёздочки как раз получается имя алгоритма для использования в команде sysctl

[@Orgasm]

Стоит отметить, что это Congestion Control Algorithm-ы (CCA), а не модели TCP.

[@casperrr]

Да, так точнее. В другом месте у меня — «модели поведения». Это немного извиняет. Базис-то у TCP в смысле установки соединения, отслеживания номеров последовательностей и т.д. более-менее устаканившийся. А о чем еще можно сказать в смысле поведения — только о том, как с перегрузками/заторами бороться. Тут большой простор.

[@motl]

«побольше бы таких статей на хабре» (с)

Когда говорят «размер окна TCP», подразумевают TCP receive window, который регулируется получателем. Его же максимальное значение конфигурируется как maximum window size.
Выше перечислены congestion avoidance алгоритмы, задача которых определить размер другого окна — congestion window, который регулируется отправителем и получателю неизвестен.

[@casperrr]

Это не статья, а так — заметка.

А окно на отправку с окном получателя никак не связано? Когда отправитель увеличивает cwnd верхней планкой для него будет окно, объявленное получателем — то самое receive window. И даже если не начнутся потери из-за перегрузки, cwnd не превысит rwnd. Таким образом утилизация канала нормальная rwnd может быть ограничена и очень серьезно.

[@casperrr]

Таким образом уменьшению эффективности может служить высокий RTT канала, низкая планка для роста cwnd — то бишь объявленное получателем rwnd и неэффективное поведение при потерях (как от перегрузок, т.е. достижения объективного потолка так и случайных). Заметка — об устранении/уменьшении последней причины (в смысле не самих потерь, а реакции на них протокола).

[@tgz]

Самый годный tcp_yeah как раз и забыли.

[@PTPtupit]

Спасибо за статью и особенно за ссылку «подробнее с формулами».