Модели TCP

    Совсем недавно несколько раз за короткий промежуток времени в разговорах с коллегами натыкался на принципиальное непонимание того простого факта, что тюнинг параметров TCP — это не все, что можно сделать для оптимальной утилизации каналов. Что-что? Какие-такие другие модели TCP? Нафига? Все и так можно подогнать, поигравшись Maximum Window Size, таймингами и прочим. Это конечно все здорово и бывает крайне необходимо, но не все поддается тюнингу через proc или реестр. А именно и например? Сравнить это можно с ситуацией, как если бы мы имели некую формулу и добивались результатов «кручением» в ней неких переменных и коэффициентов. Но можно ли поменять саму формулу?


    Да. Именно поэтому и для этого разработаны и разрабатываются разные модели поведения протокола TCP.

    Модель TCP Vegas, управляя размером окна, ориентируется в том числе на RTT, делая при этом выводы о приближении канала к перегрузке при увеличении RTT.

    Модель TCP Westwood при расчете cwin и ssthresh оценивает поток данных (RE — Rate Estimation) и полосу пропускания (BE — Bandwidth Estimation). На базе этих оценок появляется возможность более тонко управлять окном. Эффективен в случае высоких значений bandwith*rtt.

    Модель TCP Hybla — разработана для широких каналов с высоким RTT. Максимальной утилизации канала удается достичь благодаря аналитической оценке динамики окна перегрузки.

    Модель CUBIC TCP так же заточена для длинных широкополосных сетей (LFN). Использует кубичную функцию роста окна, в которой в частности задействовано время, прошедшее с момента последнего события перегрузки.

    Модель TCP Illinois гибко подбирает коэффициенты увеличения и уменьшения окна во время фазы увеличения окна для предотвращения перегрузки.

    Модель TCP Veno — смесь TCP NewReno и TCP Vegas, пытается выделять потери, не связанные с перегрузкой, что бы не включать борьбу с перегрузкой там, где это не нужно (актуально для WLAN).

    Подробнее и с формулами: book.itep.ru/4/44/tcp.htm

    И это далеко не полный перечень моделей. На данный момент ядро linux поддерживает более десятка алгоритмов. Есть чем поиграться кроме параметров ядра.

    ЗЫ. К слову, Microsoft имеет свой алгоритм Compound TCP, нашедший воплощение в TCP/IP стеке Vista/7/2008. Кому доводится иметь дело с полисерами видел, что по сравнению с XP/2003 (даже подкрученными) утилизация канала намного лучше в случае Tcp Next Generation.
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 12
    • +2
      На данный момент ядро linux поддерживает более десятка алгоритмов. Есть чем поиграться кроме параметров ядра.
      Был бы счастлив, если бы подсказали как конкретно с ними работать: включать, выключать и т.д.
      • +2
        Это легко можно нагуглить, а учитывая, что это возможности ядра, то логично (и правильно) предположить, что можно настроить через /proc или sysctl.
      • +14
        sysctl -w net.ipv4.tcp_congestion_control=westwood

        Просто всегда приятно иметь в одном месте (статье) именно то, о чём она повествует в полном объеме.
        • 0
          Ну для полноты можно упомянуть, что конкретные реализации могут быть включены/выключены при сборке ядра и соответственно может статься, что конкретный алгоритм отсутствует и включить его указанным способом нельзя.
          • +2
            А посмотреть список доступных алгоритмов можно так:
            ls /lib/modules/ВЕРСИЯ_ВАШЕГО_ЯДРА/kernel/net/ipv4/tcp_*.ko
            На месте звёздочки как раз получается имя алгоритма для использования в команде sysctl
          • +10
            Стоит отметить, что это Congestion Control Algorithm-ы (CCA), а не модели TCP.
            • 0
              Да, так точнее. В другом месте у меня — «модели поведения». Это немного извиняет. Базис-то у TCP в смысле установки соединения, отслеживания номеров последовательностей и т.д. более-менее устаканившийся. А о чем еще можно сказать в смысле поведения — только о том, как с перегрузками/заторами бороться. Тут большой простор.
            • +3
              «побольше бы таких статей на хабре» (с)

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

                А окно на отправку с окном получателя никак не связано? Когда отправитель увеличивает cwnd верхней планкой для него будет окно, объявленное получателем — то самое receive window. И даже если не начнутся потери из-за перегрузки, cwnd не превысит rwnd. Таким образом утилизация канала нормальная rwnd может быть ограничена и очень серьезно.
                • 0
                  Таким образом уменьшению эффективности может служить высокий RTT канала, низкая планка для роста cwnd — то бишь объявленное получателем rwnd и неэффективное поведение при потерях (как от перегрузок, т.е. достижения объективного потолка так и случайных). Заметка — об устранении/уменьшении последней причины (в смысле не самих потерь, а реакции на них протокола).
                • 0
                  Самый годный tcp_yeah как раз и забыли.
                  • 0
                    Спасибо за статью и особенно за ссылку «подробнее с формулами».

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