Совсем недавно несколько раз за короткий промежуток времени в разговорах с коллегами натыкался на принципиальное непонимание того простого факта, что тюнинг параметров 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.
Да. Именно поэтому и для этого разработаны и разрабатываются разные модели поведения протокола 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.
