Опубликован: 28.09.2007 | Доступ: свободный | Студентов: 5986 / 903 | Оценка: 4.20 / 4.10 | Длительность: 47:32:00
ISBN: 978-5-94774-707-2
Лекция 2:

Транспортные протоколы Интернет

2.2.1.2. TCP Vegas

TCP-Vegas [9, 1994г] контролирует размер окна путем мониторирования отправителем RTT для пакетов, посланных ранее. Если обнаруживается увеличение RTT, система узнает, что сеть приближается к перегрузке, и сокращает ширину окна. Если RTT уменьшается, отправитель определит, что сеть преодолела перегрузку, и увеличит размер окна. Следовательно, размер окна в идеальной ситуации будет стремиться к требуемому значению. В частности, на фазе исключения перегрузки размер окна будет равен

cwnd(t+t_A)=
\begin{cases}
 cwnd(t)+1,\text{ }\text{ } f \text{ }\text{ }  diff<\frac{\alpha}{base \_rtt}\\
cwnd(t.) \text{ }\text{ } \frac{\alpha}{base \_rtt}\le diff \le \frac{\beta}{base \_rtt};
\text{ }\text{ }diff=\frac{cwnd(t)}{base \_rtt}-\frac{cwnd(t)}{rtt}\\
 cwnd(t)-1,\text{ }\text{ } \frac{\beta}{base \_rtt}<diff text{ }
\end{cases} ( 2)

где rtt [сек] - зарегистрированное RTT, base_rtt [сек] - наименьшее встретившееся в данном цикле RTT, а \alpha и \beta - некоторые константы (смотри также [2.3]). Эта модификация ТСР требует высокого разрешения таймера отправителя.

2.2.1.3. TCP-Tahoe

Алгоритм TCP-Tahoe является наиболее старым и широко распространенным [2.16]. Этот алгоритм был сформулирован Джакобсоном в 1988 году, некоторые коррекции были внесены в него позднее.

Если буфер переполнен, какое-то число сегментов будет потеряно. При этом может быть запущено несколько сценариев. Основной вариант - медленный старт, он запускается в рамках классического алгоритма ТСР-Tahoe при потере сегмента и сопряженном с ним таймаутом ( RTO ) у отправителя, так как отправитель не получит сигнала подтверждения ACK для потерянного сегмента. Медленный старт предполагает установку окна перегрузки ( CWND ) равным 1, а порога медленного старта ( ssthresh ) - равным половине значения CWND, при котором произошел таймаут. Сокращение CWND до единицы происходит потому, что отправитель не имеет никакой информации о состоянии сети. Далее после каждого подтверждения CWNDi+1 = CWNDi+1. Эта формула работает до тех пор, пока CWND не станет равным ssthresh. После этого рост CWND становится линейным (смотри формулу 1). Смысл этого алгоритма заключается в удержании значения CWND в области максимально возможных значений. По существу, эта оптимизация осуществляется с помощью потери пакетов. Если потери пакетов не происходит, значение CWND достигает значения window по умолчанию, задаваемого при конфигурации ТСР-драйвера. На рис. 2.10 показана эволюция CWND при потере пакетов.


Рис. 2.10.

Значение таймаута вычисляется по формуле:

RTO=\overline{RTT}+4\sigma_{\overline{RTT}}

где \sigma - среднеквадратичное отклонение среднего значения RTT.

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

Может возникнуть вопрос, почему при потере пакета CWND делается равным 1, а не CWND-1 или CWND/2? Ведь эффективность канала максимальна при наибольшем, возможном значении CWND. Если произошла потеря пакета из-за переполнения буфера, оптимальное значение CWND может быть выбрано лишь при исчерпывающем знании прогноза состояния виртуального канала. Постольку такая информация обычно недоступна, система переходит в режим освобождения буфера ( CWND=1 ). Ведь если потеря была связана с началом сессии обмена с конкурирующим клиентом, операция CWND=CWND-1 проблему не решит. А потеря пакета вызовет таймаут, и канал будет блокирован минимум на 1 секунду, из-за чего произойдет резкое падение скорости передачи.

Использование стартового значения CWND>1 может увеличить эффективность виртуального ТСРканала. Стартовое значение CWND = 2*MSS представляется вполне разумным. Понятно, что в критических ситуациях CWND=1 должно быть непременно разрешено. На рис. 2.11 показана эволюция CWND (результат моделирования [2.3]) при двух последовательных медленных стартах (один из них может быть вызван случайной потерей сегмента). Отсюда видно, что случайные потери сильно понижают пропускную способность канала.

2.2.1.4. TCP Westwood

Среди множества предлагаемых моделей реализации ТСР можно выделить еще одну - TCPW (TCP Westwood). Эта модель позволяет достичь большей эффективности использования канала. В такой модификации протокола используется новый алгоритм управления окном перегрузки, основанный на оценке потока данных (RE - Rate Estimation) и текущего значения полосы пропускания. На основе этих оценок производится вычисление cwin и ssthresh. Для больших произведений полосы на RTT этот алгоритм может дать лучший результат, чем NewReno.

if(получено 3 DUPACK)
	ssthresh = (BE*RTTmin)/seg_size;
if(cwin > ssthresh)     /* исключение перегрузки */ 
		cwin=ssthresh;
endif
endif
Эволюция cwnd при двух медленных стартах (T. V. Lakshman, Upamanyu Madhow, "The performance of TCP/IP for networks with high bandwidth-delay products and random loss", IEEE/ ACM Trans. Networking, V5, N3, p.336-350, June 1997)

Рис. 2.11. Эволюция cwnd при двух медленных стартах (T. V. Lakshman, Upamanyu Madhow, "The performance of TCP/IP for networks with high bandwidth-delay products and random loss", IEEE/ ACM Trans. Networking, V5, N3, p.336-350, June 1997)

где seg_size идентифицирует длину ТСРсегмента, а DUPACK - задублированное подтверждение, BE - (bandwidth estimation) оценка полосы. Заметим, что после получения n DUPACK следует повторная пересылка потерянных сегментов, как это делается в стандартном режиме быстрой повторной пересылки ТСР Reno. Окно растет после установления его ширины равной ssthresh согласно правилам алгоритма быстрой повторной пересылки ( cwin=cwin+1 при получении каждого ACK и делается равным ssthresh при получении ACK для новых данных). Следовательно, когда получено n DUPACK, мы достигли предела пропускной способности сети. window = BE \times RTT_{min}.

Переход к фазе исключения перегрузки связан с плавным поиском доступного значения полосы пропускания канала. Значение RTTmin равно наименьшему значению, измеренному протоколом ТСР. Заметим, что после установления ssthresh значение ширины окна перегрузки делается равным порогу медленного старта, только если cwin > ssthresh. В протоколе TCPW для оценки BE используются ACK. Для этого регистрируется частота ACK и измеряется объем данных, доставленных в единицу времени. b_k=d_k/\Delta t_k; \Delta t_k = t_kt_{k-1}, где tk - время прихода k -го ACK отправителю, dk - длина подтвержденного сегмента.

В случае, когда потеря пакета индицируется истечением времени таймаута, значения cwin и sstresh устанавливаются согласно:

if(произошел таймаут RTO)
	cwin=1;
	ssthresh=(BE*RTTmin/seg_size;
	if(ssthresh<2) 
	ssthresh=2;
endif
endif

В случае использования комбинированного алгоритма CRB (Combined RE/BE), где применен более сложный алгоритм оценки загрузки и доступной полосы пропускания, присвоение значений cwin и ssthresh производится согласно следующим соотношениям (вариант потери с индикацией посредством присылки 3 DUPACK ):

if(получено 3 DUPACK)
if(cwin/((RE*RTTmin)/seg_size)>0)   /* сеть перегружена */
ssthresh = (RE*RTTmin)/seg_size;
else                                                 /* перегрузки нет */
ssthresh = (BE*RTTmin)/seg_size;
Endif
if(cwin> ssthresh)              /* исключение перегрузки */
cwin = ssthresh;
endif;
endif

В случае, когда потеря пакета индицируется по таймауту, значения cwin и ssthresh вычисляются следующим образом:

if(произошел таймаут RTO)
	cwin=1;
	ssthresh=(BE*RTTmin/seg_size;
	if(ssthresh<2) 
	ssthresh=2;
endif;
endif

Заметим также, что объекты, вовлеченные в соединения, оказываются в определенной мере синхронизованными. Это связано с тем, что, когда буфер полон, все приходящие пакеты отбрасываются. В предположении о постоянной готовности отправителя к передаче и о том, что временной разброс ячеек не превосходит время пересылки пакета во входном канале, все соединения будут передавать ячейки в течение времени транспортировки пакетов, вовлеченных в столкновение. Следовательно, все соединения теряют пакеты и сокращают вдвое ширину окна в пределах RTT.

Помимо таймаута, в протоколе TCP предусмотрена еще одна возможность уведомления отправителя о потере сегмента. Получатель, контролируя номера приходящих сегментов и обнаружив потерю, может начать посылать двойные ACK для пакетов, следующих за потерянным сегментом. Приход таких дублированных ACK позволяет разрешить проблему до истечения времени таймаута RTO (смотри описание алгоритма TCP-reno). Понятно, что для последнего сегмента в сообщении этот метод не работает и остается только таймаут. Получение двойного ACK не является надежным сигналом потери пакета. Двойные ACK возникают и при смене маршрута обмена. По этой причине сигналом потери считается получение трех ACK пакетов подряд (сигнал быстрой повторной посылки сегмента - fast retransmit). В этом режиме при потере одиночного пакета (Fast Recovery) CWND устанавливается на три сегмента больше, чем значение ssthresh. После получения сигнала ACK значение CWND становится равным ssthresh с дальнейшим линейным увеличением. Здесь приход очередного ACK увеличивает CWND на (MSS*MSS)/CWND. Область линейного увеличения CWND часто называется режимом исключения перегрузки (congestion avoidance) или AIMD (Additive Increase, Multiple Decrease).

На пути сегмента может повстречаться перегруженный переключатель (L2), который поддерживает алгоритм "обратного давления". Такой сетевой прибор при переполнении его буферов пошлет отправителю уведомление о перегрузке в виде пакета ICMP(4). В ответ на такой сигнал отправитель должен понизить скорость передачи пакетов в два раза. Следует иметь в виду, что подобное событие слабо коррелированно с процессами ТСРобмена и зависит от условий, складывающихся в независимых соседних каналах. Характер реакции на ICMP(4) определяется конкретными особенностями ТСР-драйвера отправителя (не говоря о том, что причиной переполнения может быть UDP-дейтаграмма).

Вспомним, что, помимо управления перегрузкой со стороны отправителя, в ТСР предусмотрен механизм управления со стороны получателя. Получатель в отклике АСК посылает значение параметра window, определяющее число сегментов, которое готов принять получатель. Механизм управления скользящим окном особенно важен при работе в сетях с большой величиной RTT (например, в случае спутниковых каналов). При этом размер буфера при заданной полосе пропускания канала B и времени задержке t должен равняться B \tau /T, где \tau - время обслуживания пакета, а T = t +  \tau Канал можно рассматривать как трубу, которая при работе всегда должна быть заполнена. Емкость этой трубы определяется величиной cwnd. Максимально возможная емкость такой трубы Vt в стационарном режиме равна V_t = T/ \tau  + B = t/ \tau + B +1. При этом буфер будет полностью заполнен и Т/ \tau пакетов находится в пути. В алгоритме TCP-Tahoe после потери сегмента ssthresh = Vt/2. Понятно, что когда cwnd становится равным Vt, происходит переполнение буфера и потеря пакета. Задача управления перегрузкой виртуального канала является классической проблемой теории массового обслуживания. Аналитическое рассмотрение проблемы и результаты моделирования можно найти в [2.3].

Одна из существенных трудностей оптимизации виртуального соединения ТСР связана с тем, что между участниками обмена может находиться неизвестное число сетевых устройств, загрузка которых может варьироваться произвольным образом, а управление находится в компетенции внешних сетевых администраторов.

Поиски решения оптимизации ТСР-каналов можно вести по двум направлениям: модифицировать сам ТСР-протокол, адаптируя его для новых условий и требований, - или изменять сетевую среду, делая ее более дружественной по отношению к ТСР. Любое изменение ТСР-протокола должно обеспечить обратную совместимость, чтобы миллионы "старых" программ могли попрежнему работать в этой среде. А это, в свою очередь, предполагает некоторый диалог при установлении виртуального соединения, который бы позволял выяснить, какими версиями ТСР обладают будущие партнеры. Причем сессии с модернизированным ТСР должны уживаться со старыми на всех уровнях. Совокупность этих соображений удерживала до сих пор Интернет-общественность от радикальных модификаций протокола ТСР.

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

Другой возможностью является привлечение вместо ТСР протокола T/TCP (TCP for Transactions), который улучшает эксплуатационные характеристики виртуального канала в случае коротких транзакций.

T/TCP помещает данные запроса и флаг завершения FIN в начальный SYN-сегмент. Это может интерпретироваться как попытка открыть сессию, передать данные и закрыть сессию со стороны отправителя. Если сервер воспринимает такой формат, он откликнется одним пакетом, содержащим SYN-отклик, ACK на полученные данные и закрывающим сессию флагом FIN. Для окончательного завершения сессии клиент должен послать серверу сегмент с флагами ACK и FIN. К сожалению, внедрение T/TCP предполагает модификацию программного обеспечения как сервера, так и клиента. По этой причине протокол T/TCP не получает широкого распространения. Кроме того, он достаточно уязвим с точки зрения безопасности.

Бесспорные преимущества при потере нескольких сегментов за один период RTT предлагает алгоритм выборочного подтверждения SACK (Selective Acknowledgement). Понятно, что следует избегать повторной пересылки благополучно доставленных пакетов (как это делается, например, в протоколе XTP).

Дополнительные проблемы возникают при реализации ТСР через спутниковые каналы, где RTT превышает 250 мсек, да и BER оставляет желать лучшего. При таких значениях RTT время преодоления ситуации перегрузки может занимать много циклов RTT и достигать десятка секунд. Короткие ТСР-сессии для таких каналов крайне неэффективны (не успеет система поднять значение CWND до приемлемого размера, а уже все данные переданы). Частично это может компенсироваться за счет реализации большого числа ТСРсессий параллельно.

Хотя ТСР использует соединение "точка--точка", можно попытаться улучшить рабочие характеристики канала, оптимизируя алгоритм управления очередями. Одним из возможных подходов является алгоритм RED (Random Early Detection). RED позволяет маршрутизатору отбрасывать пакеты, даже когда в очереди еще имеется место.

Следует помнить, что установка пакета в очередь или его отбрасывание согласно правилам RED/WRED (или FQ) осуществляется на уровне IP-протокола (ведь именно он содержит поле заголовка DSCP или метку потока).

Алгоритм RED использует взвешенное значение длины очереди в качестве фактора, определяющего вероятность отбрасывания пакета. По мере роста средней длины очереди растет вероятность отбрасывания пакетов. Если средняя длина очереди меньше определенного порога, вероятность отбрасывания пакета равна нулю (см. рис. 2.12). Небольшие кластеры пакетов могут успешно пройти через фильтр RED. Более крупные кластеры могут понести потери. Это приводит к тому, что ТСР-сессии с большими открытыми окнами имеют большую вероятность отбрасывания пакетов.

Наталья Шульга
Наталья Шульга

Курс "информационная безопасность" .

Можно ли на него записаться на ПЕРЕПОДГОТОВКУ по данному курсу? Выдается ли диплом в бумажном варианте и высылается ли он по почте?

Мария Архипова
Мария Архипова