Протокол TCP осуществляет доставку дейтограмм, называемых сегментами, в виде байтовых потоков с установлением соединения. Протокол TCP применяется в тех случаях, когда требуется гарантированная доставка сообщений. Он использует контрольные суммы пакетов для проверки их целостности и освобождает прикладные процессы от необходимости таймаутов и повторных передач для обеспечения надежности. Для отслеживания подтверждения доставки в TCP реализуется алгоритм "скользящего" окна TCP. В настоящее время предложено и опробовано несколько разновидностей протокола TCP. В этой статье я рассмотрю некоторых из них, а так же модификацию протокола gjl названием ARTCP, в которой полностью переработан механизм алгоритм управления потоком.
TCP Tahoe
Алгоритм TCP Tahoe [1,2] является наиболее старым и широко распространенным. Этот алгоритм был сформулирован Джакобсоном в 1988 году, некоторые коррекции были внесены в него позднее.
Если буфер переполнен, какое-то число сегментов будет потеряно. При этом может быть запущено несколько сценариев. Основной вариант - медленный старт, запускается в рамках классического алгоритма ТСР Tahoe при потере сегмента и сопряженным с ним таймаутом (RTO) у отправителя, так как отправитель не получит сигнала подтверждения ACK для потерянного сегмента. Медленный старт предполагает установку окна перегрузки (CWND) равным 1 (имеется в виду 1 MSS – Maximum Segment Size – максимальный сегмент сети ), а порога медленного старта (ssthresh) равным половине значения CWND, при котором произошел таймаут. Сокращение CWND до единицы происходит потому, что отправитель не имеет никакой информации о состоянии сети. Далее после каждого подтверждения CWNDi+1 = CWNDi+1 (имеется в виду прибавляется еще один CWNDi, ,т.е. CWNDi+1 удваивается). Эта формула работает до тех пор, пока CWND не станет равным ssthresh. После этого рост CWND становится линейным согласно (1):
(1)
где ssth(t) [пакетов] - значение порога, при котором TCP переходит из фазы медленного старта в фазу исключения перегрузки.
Смысл этого алгоритма заключается в удержании значения CWND в области максимально возможных значений. По существу эта оптимизация осуществляется с помощью потери пакетов. Если потери пакетов не происходит, значение CWND достигает значения window по умолчанию, задаваемого при конфигурации ТСР-драйвера. На рис. 1 показана эволюция CWND при потере пакетов.
Рис. 1.
Значение таймаута вычисляется по формуле:
где б - средне-квадратичное отклонение среднего значения RTT.
Потерянный пакет и все, посланные после него, пакеты (вне зависимости оттого, подтверждено их получение или нет) пересылаются повторно. При большой вероятности потери это существенно понижает пропускную способность и увеличивает и без того высокую загрузку канала.
Может возникнуть вопрос, почему при потере пакета CWND делается равным 1, а не CWND-1 или CWND/2? Ведь эффективность канала максимальна при наибольшем, возможном значении CWND. Если произошла потеря пакета из-за переполнения буфера, оптимальное значение CWND может быть выбрано лишь при исчерпывающем знании прогноза состояния виртуального канала. Постольку такая информация обычно недоступна, система переходит в режим освобождения буфера (CWND=1). Ведь если потеря была связана с началом сессии обмена с конкурирующим клиентом, операция CWND= CWND-1 проблему не решит. А потеря пакета вызовет таймаут и канал будет блокирован минимум на 1 секунду, что вызовет резкое падение скорости передачи.
Использование стартового значения CWND>1 может увеличить эффективность виртуального ТСР-канала. Стартовое значение CWND = 2*MSS представляется вполне разумным. Понятно, что в критических ситуациях CWND=1 должно быть непременно разрешено.
TCP Reno
В TCP Reno [3], появившимся в 1990г, при нормальной ситуации размер окна меняется циклически. Размер окна увеличивается до тех пор, пока не произойдет потеря сегмента. TCP Reno имеет две фазы изменения размера окна: фаза медленного старта и фаза избегания перегрузки. При получении отправителем подтверждения доставки в момент времени t + tA [сек], текущее значение размера окна перегрузки cwnd(t) преобразуется в cwnd(t + tA) согласно (1).
Когда в результате таймаута детектируется потеря пакета значения cwnd(t) и ssth(t) обновляются следующим образом:
cwnd(t)=1; ssth(t)=(cwnd(t))/2;
С другой стороны, когда TCP детектирует потерю пакета согласно алгоритму быстрой повторной передачи, cwnd(t) и ssth(t) обновляются иначе:
ssth(t) = (cwnd(t))/2; cwnd(t)= ssth(t);
TCP Reno после этого переходит в фазу быстрого восстановления. В этой фазе размер окна увеличивается на один пакет, когда получается дублированное подтверждение. С другой стороны, cwnd(t) делается равным ssth(t), когда приходит не дублированный отклик для пакета, посланного повторно. В случае таймаута ssth(t)= (cwnd(t))/2; cwnd=1 (как в алгоритме TCP Tahoe).
В настоящее время наиболее популярной является модель NewReno [4], которая появилась в апреле 2004 года, и использующая алгоритм Fast Retransmit & Fast Recovery (быстрая повторная пересылка и быстрое восстановление). В случае, когда доступна опция выборочного подтверждения (Selective Acknowledgement - SACK) [5], отправитель знает, какие пакеты следует переслать повторно на фазе быстрого восстановления (Fast Recovery). В отсутствии опции SACK нет достаточной информации относительно пакетов, которые нужно послать повторно. При получении трех дублированных подтверждений (Duplicate Acknowledgement - DUPACK) отправитель считает пакет потерянным и посылает его повторно. После этого отправитель может получить дополнительные дублированные подтверждения, так как получатель осуществляет подтверждение пакетов, которые находятся в пути, когда отправитель перешел в режим Fast Retransmit. В случае потери нескольких пакетов из одного окна отправитель получает новые данные, когда приходит подтверждение для повторно посланных пакетов. Если потерян один пакет и не было смены порядка пакетов, тогда подтверждение этого пакета будет означать успешную доставку всех предыдущих пакетов до перехода в режим Fast Retransmit. Однако, если потеряно несколько пакетов, тогда подтверждение повторно посланного пакета подтверждает доставку некоторых но не всех пакетов, посланных до перехода в режим быстрой повторной пересылки (Fast Retransmit). Такие подтверждения называются частичными.
Разработчики назвали алгоритм быстрого восстановления NewReno, так как он значительно отличается от базового алгоритма Reno. Предложенный алгоритм дает определенные преимущества по сравнению с каноническим Reno при самых разных сценариях.
TCP Vegas
TCP Vegas [6], который появился появился в 1994г, контролирует размер окна путем мониторинга отправителем RTT для пакетов, посланных ранее. Если обнаруживается увеличение RTT, система узнает, что сеть приближается к перегрузке и сокращает ширину окна. Если RTT уменьшается, отправитель определит, что сеть преодолела перегрузку, и увеличит размер окна. Следовательно, размер окна в идеальной ситуации будет стремиться к требуемому значению. В частности на фазе исключения перегрузки, размер окна будет равен
где rtt[сек] зарегистрированное RTT, base_rtt[сек] наименьшее встретившееся в данном цикле RTT, а a и b - некоторые константы. Эта модификация ТСР требует высокого разрешения таймера отправителя.
ARTCP
ARTCP (Adaptive Rate TCP) [7,8] отличается от стандартного TCP тем, что сегменты отправляются в сеть не в виде всплеска в пределах окна, а разделенные временными промежутками, длительность которых определяется текущим значением скорости. Скорость потока регулируется не размером переменного окна, а значением скорости, изменением которой осуществляется адаптация алгоритма в соответствии с условиями. Механизм скользящего окна в ARTCP применяется только для предотвращения переполнения буферов получателя. На размер окна в ARTCP не наложено никаких ограничений ни в одном из режимов работы. Окно ограничено лишь наличием буферного пространства у получателя, поэтому для получателя рекомендуется устанавливать окно на максимальный размер.
В случае, когда получатель ограничен в буферном пространстве, ARTCP будет вести себя как обычный протокол TCP, ограниченный окном. Таким образом, протокол ARTCP сочетает в себе метод скользящего окна для регулирования управления потоком из конца в конец и метод контроля скорости для подстройки под ПС промежуточных узлов соединения.
Вторым важнейшим отличием ARTCP является то, что в качестве сигнала о состоянии перегрузки или наличия дополнительных ресурсов в сети используются темпоральные характеристики потока – измерение скважности потока у получателя и изменения времени RTT. Потеря пакета никак не отражается на работе ARTCP кроме осуществления ретрансляции потерянного пакета механизмом коррекции ошибок. Как и в TCP, о потери пакета сообщают два возможных события: срабатывание ТПП или последовательное получение двух подтверждений одних и тех же данных.
Таким образом, по сравнению со своим предшественником, ARTCP обладает следующими преимуществами:
· ARTCP не требуется доводить сеть до состояния перегрузки, чтобы определить доступную долю ПС, поэтому исключены потери пакетов связанные с этим процессом.
· ARTCP существенно снижает требования к межсетевым устройствам. Во-первых, для нормального функционирования данного протокола требуется меньший объем буферного пространства, чем для TCP, поскольку режим передачи является сглаженным. Во-вторых, ARTCP не требует и не зависит от наличия каких либо механизмов диспетчеризации или управления очередями, таких как RED или WFQ.
· ARTCP не интерпретирует потерю пакета как признак перегрузки сети, используя вместо этого темпоральные характеристики потока. Поэтому ARTCP должен особенно эффективно работать в системах беспроводной связи, т.е. там, где использование TCP неэффективно.
В отличие от TCP новый протокол не полагается целиком на поток подтверждений в обратном направлении для синхронизации процесса передачи. В связи с этим возможна реализация ARTCP с меньшей частотой подтверждений, которая не ограничивала бы скорость в асимметричных системах.
Эвристика в основе алгоритма ARTCP.
Анализ работ в области транспортных протоколов и, в частности, механизма PP позволил заключить, что недостатки протокола TCP весьма существенны и являются следствием самого алгоритма, лежащего в основе протокола TCP. Поэтому модификация TCP без замены его основных алгоритмов не может привести к существенному улучшению характеристик протокола.
Поэтому нами было решено создать новый алгоритм транспортного протокола, остающийся, однако, полностью совместимым с архитектурой TCP/IP.
Для того, чтобы устранить недостатки, свойственные TCP, необходимо было найти способ получения информации о состоянии сети, отличный от применения в этих целях потерь сегментов. Лучше всего на роль индикатора состояния сети подходят временные характеристики потока: время RTT и межсегментные интервалы. С использованием межсегментных интервалов можно также определить долю ПС канала. Для этого требуется запоминать межсегментные интервалы потока у отправителя и измерять их у получателя. Сравнение значений интервалов характеризует состояние сети, а минимальное значение измеряемых интервалов у получателя позволяет определить доступную долю ПС.
Таким образом, получается следующая схема: установка скорости потока отправителем посредством тщательной диспетчеризации сегментов, измерение скорости прибытия потока у получателя и передача этой информации отправителю вместе с остальной контрольной информацией. Разность старого и нового значений скорости отправки потока ARTCP на каждом шаге задается случайной переменной, однако, при наличии сигнала о перегрузке сети вероятность снижения скорости превышает вероятность ее увеличения на каждом новом шаге.
Заключение
В данной статье были рассмотрены несколько разновидностей протокола TCP. Можно сделать вывод, что модификации могут улучшить характеристики базового протокола. Однако, можно утверждать, что недостатки протокола TCP весьма существенны и являются следствием самого алгоритма, лежащего в основе протокола TCP. Поэтому модификация TCP без замены его основных алгоритмов не может привести к существенному улучшению характеристик протокола. В протоколе ARTCP полностью переработан механизм алгоритм управления потоком, поэтому он избавлен от многих недостатков стандартного TCP.
Список источников:
2. V. Jacobson, "Congestion Avoidance and Control," Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
3. RFC 2001 - TCP Slow Start, Congestion Avoidance, Fast Retransmit. W. Stevens. January 1997.
4. RFC 3782 The NewReno Modification to TCP's Fast Recovery Algorithm. Floyd, S., Henderson, T., and A. Gurtov. April 2004.
5. RFC 2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP. S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. July 2000.
6. L. S. Brakmo, S. W. O’Malley, L. L. Peterson, “TCP Vegas: New techniques for congestion detection and avoidance”, Proc. ACM Sigcomm, August 1994.
7. Алексеев И.В., Соколов В.А. Протокол TCP с адаптацией скорости. // Моделирование и анализ информационных систем. Т.6, №1. - 1999.- С. 4-12
