Новый протокол ТСР

Семенов Ю.А. (semenov@itep.ru ) ИТЭФ

Современная версия протокола ТСР (RFC-793, -1323) имеет ряд недостатков (см. http: book.itep.ru/4/44/tcp 443.htm, а также RFC-2525 или [1]):

1. Практически не защищена от атак (подбор ISN, человек по середине , посылка ложного флага FIN или RST, переполнение буфера SYN-запросами и т.д.)

2. Не обеспечивает оптимального использования виртуального соединения в условиях перегрузки (управление CWND)

3. Имеет неэффективность процедуры установления соединения (три операции обмена) и разрыва связи (4 операции обмена)

4. Логика работы протокола плохо адаптируется к изменениям ситуации в сети

5. Протокол плохо приспособлен для работы со скоростными каналами (10Гбит/с и больше, в частности из-за ограничений размера окна или поля идентификатора пакета, а также из-за линейного роста CWND на участке исключения перегрузки)

Попытки адаптировать действующую версию протокола имели существенный, но ограниченный успех (модели Tahoe, Reno (см. также RFC--2581, -2582), Vegas, Т/ТСР (см. RFC-1644), SACK (см. RFC-2018, -2883, -3517) и другие (см., например, RFC-2309, -3042, -3168, -3465)). Одной из наиболее удачных разработок в этой области можно считать [3].

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

Сначала рассмотрим, что мешает ТСР работать в сверхскоростных

каналах. Здесь наиважнейшими параметрами являются window > RTTB/MSS и поле идентификатора пакета, где В - полоса пропускания канала, измеряемая в битах в сек, максимальный размер сегмента MSS (здесь и далее задан в битах), а RTT - сумма времен доставки сегмента от отправителя до получателя и отклика от получателя до отправителя (в сек). По умолчанию величина MSS равна1460*8 = 11680бит. О проблеме работы протокола ТСР в режиме больших произведений RTT на В (см. [2]).

Высокопроизводительные каналы (>1 Гбит/с) уже сегодня могут исчерпать разнообразие идентификационных кодов пакетов за один сеанс связи. Появление же двух пакетов с равными идентификаторами может породить неразрешимые трудности. Для передачи мегабайтного файла по гигабитному каналу требуется около 40 мсек (при этом предполагается, что задержка в канале составляет 32 мсек (RTT=64 мсек)). Собственно передача этой информации занимает 8 мсек. Из этих цифр видно, что традиционные протоколы, размеры окон и пр. могут свести на нет преимущества скоростного,

дорогостоящего канала. Понятно также, что необходимо расширить поле размера окна с 16 до 32 бит (это делается сегодня с привлечением опции ТСР). Чтобы не изменять формат TCP-сегментов, можно сделать код размера окна в программе 32-разрядным, сохранив соответствующее поле в сегменте неизменным (см. RFC-2414, -2415 и -3390). Размер окна в этом случае задается как бы в формате с плавающей запятой и составляет 65535*2n, где п может лежать в интервале 0-14.

Увеличение размера окна в свою очередь приводит к проблемам, при перегрузке. Каноническое поведение протокола TCP в случае потери пакета (это может быть сегмент данных или отклик) заключается в повторной пересылке всех посланных пакетов, начиная с потерянного. Если считать, что о потере пакета отправитель узнает в среднем спустя RTT/2, то для рассмотренного выше примера за это время будет передано более мегабайта данных, которые и должны быть посланы повторно. Для 10Гигабитного канала этот объем увеличится до 10-20Мбайт. А отправитель должен резервировать соответствующий объем памяти для хранения этой информации.

Время RTT складывается из задержки распространения электромагнитных волн по каналу и из времени пребывания пакетов в очередях и их обработки в сетевых устройствах. Вторая составляющая преобладает (если это не спутниковый канал). Время распространения волны по кабелю длиной 5000 км составляет около 25 мсек, задержка в современном маршрутизаторе варьируется от 1 до 20 мсек. Число же маршрутизаторов на пути такой длины равно 10-15. Дополнительной вклад в задержку внесут переключатели локальной сети, а также системы отправителя и получателя. Таким образом, приведенное выше значение RTT является типичным, и, следовательно, нужно искать пути выхода из тупика, сопряженного с повторной передачей больших массивов данных. Учитывая, что часто реализуется несколько ТСР-сессий одновременно, положение только усугубляется. Кроме того, в традиционном ТСР при скорости канала 1 Гбит/c и больше из-за линейного роста CWND в режиме исключения перегрузки оптимальное значения окна за время сессии вообще не может быть достигнуто (см. [3]).

Можно рассматривать варианты, где исключается или сводится к минимуму вероятность потери пакета (тогда ничего повторно передавать не нужно). См., например, http: book.itep.ru/4/44/tcp.htm. В некоторых моделях реализации ТСР предусмотрен режим исключения перегрузки , что подразумевает исключение потери пакетов. Но, к сожалению, полностью исключить потери пакетов невозможно, хотя бы из-за конечной вероятности их повреждения при транспортировке.

Можно задуматься о снижении величины RTT. Время пребывания пакета в очереди и длительность его обработки в маршрутизаторе пока сократить нельзя. Можно ли сократить число маршрутизаторов в виртуальном соединении точка-точка?

Если следовать требованиям современного протокола ТСР, то нельзя, так как конечные точки заданы сессией (отправитель-получатель), а промежуточные узлы - топологией Интернет и протоколом маршрутизации.

Далее рассматривается принципиально новый вариант протокола ТСР, который будем называть NTCP. Все сетевые объекты, поддерживающие протокол NTCP, должны анализировать TCP-заголовки не только адресованных им пакетов, но и всех транзитных, и записывать в поле данных откликов информацию о текущем состоянии их буферов. Для

широкомасштабной реализации протокола NTCP необходима адаптация сетевых маршрутизаторов (в настоящее время они обрабатывают только IP-заголовки) и крайне желательна переделка переключателей уровня L2. Анализ состояния очередей на уровне L2 позволит решать задачи приоритетного обслуживания, что в настоящее время для Ethernet невозможно, и позволит использовать некоторые из предлагаемых алгоритмов и в случае протокола UDP.

В запросе SYN при установлении соединения должен присутствовать код опции нового протокола NTCP (код поля опции вид может равняться, например, 20) и, если поддерживающий NTCP объект получает такой сегмент, он должен послать соответствующий отклик отправителю.

Если исключить виртуальное соединение точка-точка и сделать так, чтобы виртуальный путь состоял из цепочки сегментов, то RTT можно сократить в разы, а для протяженных маршрутов на порядок. Традиционный виртуальный ТСР-маршрут превращается в цепочку каналов, соединяющих маршрутизаторы. Примеры таких каналов можно видеть на рис 3 между узлами А и 1, а также между 3 и 4. Для них все останется практически также, как и в традиционном ТСР. Для каналов 1-2, 2-3, 4-5 и т.д. RTT становится равным времени транспортировки и обработки пакета для одного шага, что может составлять 1-5 мсек (или даже меньше). 16-битного поля window заголовка при RTT>5мсек хватит до скоростей передачи данных ~20Гбит/с. Можно предполагать, что для 100Гигабитного оборудования будут характерны меньшие значения времени обработки очередей пакетов, что позволит во многих случаях еще более сократить RTT и исключить использование ТСР-опции ширины окна. При потере пакета проблема улаживается локально в данном сегменте пути, объем повторно пересылаемых данных будет минимальным (один сегмент). В случае минимизации RTT потребуется большая точность измерения этого времени (~10 мксек). Сокращение среднего значения RTT пропорционально снизит требования, предъявляемые к объему буферов во всех сетевых устройствах по пути от отправителя к получателю.

В отличие от обычного протокола ТСР (рис.1 верх) в такой схеме взаимодействует не конечный отправитель с конечным получателем, а только отправитель с ближайшим маршрутизатором (поддерживающим протокол NTCP), соседние маршрутизаторы между собой и конечный маршрутизатор с получателем (см. рис. 1, низ; случай, когда все маршрутизаторы поддерживают NTCP). Понятно, что в этом варианте маршрутизаторы должны научиться работать на уровне L4 (сейчас они работают только на уровне L3), различать сессии, установленные между одними и теми же конечными агентами (анализировать номера портов или идентификаторы сокетов).

Рис. 1.

Рис. 1.а

Обработка сегментов уровня L4 (TCP) осуществляется не только маршрутизаторами, но и переключателями уровня L2 (рис. 1 верх).

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

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

Следует заметить, что современная технология позволяет создать переключатели уровня L2 не только способные сообщать о состоянии очередей в своих буферах, но и реализовывать приоритетное обслуживание (DiffServ), учитывающее код DSCP в заголовке IP-дейтограммы. Разработка таких переключателей даст возможность обеспечивать требуемый уровень обслуживания для локальных сетей, что принципиально поменяет характер работы многих приложений.

Структура рекорда в поле данных отклика может иметь формат, показанный на рис. 2. Число рекордов в отклике зависит от числа шагов между отправителем и получателем.

0 16 31

Рис. 2.

В поле идентификатор может размещаться IP-адрес сетевого объекта, а в случае прибора L2 - номер по порядку или встроенный идентификатор устройства. Поля свободное место содержат число сегментов, для которых имеется место в буфере. Необходимость отдельной записи данных о состоянии входного и выходного буферов диктуется возможностью разной загрузки этих буферов из-за различия потоков в противоположных направлениях. При числе шагов равном 20 в поле данных отклика потребуется 240 байт. Можно рассмотреть вариант, где каждому из полей (кроме идентификатора) выделяется по одному байту. Проблема может существенно осложниться, если маршруты в направлении туда и обратно отличаются (хотя такая ситуация не является типичной и обычно свидетельствует об ошибках сетевого администратора). Нужную информацию можно получить лишь при передаче кадра данных от отправителя к адресату. Сделать алгоритм универсальным можно путем расширением поля опций заголовка (или выделением специального поля в заголовке), куда производить запись состояния буферов сетевых агентов по маршруту отправитель-адресат. Эти данные затем переносятся получателем в рекорды состояния буферов отклика. Разумеется, асимметричных маршрутов следует всячески избегать.

Приняв и подтвердив получение сегмента, маршрутизатор берет на себя ответственность за последующую доставку сегмента очередному маршрутизатору, и так далее вплоть до конечного адресата (см. рис. 1 а). Может возникнуть вопрос, а если в этой цепочке возникнет ситуация, когда сегмент не может быть доставлен. Что произойдет? Будут ли переполнены буферы промежуточных маршрутизаторов? Но главное, как об этом узнает исходный отправитель? Поскольку виртуальное соединение строится из цепочки каналов, IP-адрес исходного отправителя известен всем участникам, и после нескольких попыток (максимальное число их должно быть оговорено) исходный отправитель может быть уведомлен о том, что адресат недоступен с помощью ICMP-сообщения. Если отправитель продолжает передачу, это ICMP-сообщение через некоторое время дублируется. Не переданные сегменты уничтожаются. Процедура эта дублируется прекращением подтверждения сегментов соседу отправителю. Вариант ICMP менее желателен, так как его легко фальсифицировать. Одновременно с этим по цепочке маршрутизаторов от заблокированного устройства в направлении отправителя будет распространяться волна неподтверждений и прерываний передачи. Можно предусмотреть специальный отклик, уведомляющий отправителя о блокировке маршрута.

Алгоритм усложняется лишь в случае проблем в канале, при нормальной ситуации задержка (RTT) в цепочке отправитель-получатель минимальна. Если пакет оказался поврежден, по истечении таймаута, он будет послан повторно. RTO=RTTm +4D, как и в обычном ТСР, только RTT в несколько раз меньше (см. также RFC-2988).

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

В начале процесса установления соединения отправитель (А) посылает дейтограмму по IP-адресу конечного получателя (Б). Ближайший к отправителю узел, который поддерживает протокол NTCP, перехватывает посланный пакет, заносит его в буфер, и немедленно посылает исходному отправителю подтверждение получения. Это подтверждение перехватывается ближайшим NTCP-маршрутизатором, уведомляя его о том, что посланный им сегмент благополучно доставлен, и снабжая его данными о состоянии буферов соседа. Этот процесс будет продолжаться до тех пор, пока дейтограмма не будет получена конечным адресатом, а исходный отправитель не получит отклик с полной информацией о состоянии буферов маршрута. В результате будет сформирована цепочка каналов с номерами i=1,...,n, каждый из которых содержит от одного до К шагов (см. рис. 3). Первый шаг на рисунке соответствует каналу A-1, содержащему К шагов.

Выигрыш в эффективности использования полосы каналов тем больше, чем больше узлов вдоль пути поддерживают NTCP (в идеале К=1). Если таких узлов вообще нет - выигрыша не будет.

Рис. 3.

Для каждого из каналов (А-1), (1-2), (2-3), (3-4), (4-5), ... и ([n-1] - n) на маршруте от А до Б реализуется традиционный протокол ТСР. Если буфер в одном из промежуточных узлов оказывается близок к переполнению, он будет посылать отклики, которые уведомляют соседа-отправителя о сложившейся ситуации (это справедливо для сегментов (1-2), (2-3),. (4-5), ... и ([n-1] - n)). Отправитель перестанет посылать очередные пакеты. В свою очередь его сосед выше по течению (в направлении к А) может оказаться в режиме близком к переполнению и уведомит об этом своего предшественника. Для сегментов (А-1) и (3-4) модель работы идентична традиционному протоколу ТСР. В области узлов А и Б могут присутствовать переключатели уровня L2, не поддерживающие протокол NTCP.

Но в данной схеме, так же как и во всех моделях ТСР нет механизма подавления потери пакетов из-за их искажения. Если вероятность такого искажения существенна, нужно рассмотреть возможность оптимального определения MTU (см. например, RFC-2923). Если все участники передачи поддерживают NTCP, при искажении пакета, повторно будет передан только искаженный пакет.

Следует иметь в виду, что потеря пакета может быть связана не только с реальной потерей кадра (из-за переполнения буфера или искажения пакета), но и с потерей подтверждения получения, вызванного теми же

причинами. Отправитель может знать, что буфер получателя пуст, но не получив своевременно подтверждения на посланный ранее сегмент, будет вынужден запустить процедуру медленного старта. Реально это может быть объяснено переполнением, например буфера в одном из промежуточных сетевых устройств, не поддерживающих NTCP. Если К=1, потеря пакета в такой ситуации может не сопровождаться процедурой медленного старта, так как очевидно, что переполнения буфера у получателя не произошло, а потеря носит случайный характер и достаточно ограничиться повторной передачей сегмента (значение CWND сохраняется неизменным). При К>1 такая стратегия недопустима и следует использовать одну из стандартных моделей реализации протокола ТСР. При этом необходим механизм контроля наличия буферизующих сетевых устройств между двумя узлами, поддерживающими NTCP. Иными словами нужен механизм определения, равно ли k единице.

Можно конечно предложить NTCP-отправителю посылать IP-дейтограммы с заданным значением TTL (например, 30). Тогда, если очередной узел, поддерживающий NTCP, получит пакет с TTL=29, то К=2. Каждый сетевой прибор, поддерживающий NTCP, должен присваивать перед отправкой полю TTL указанное значение.

Беда в том, что по дороге могут быть включены устройства уровня L2, не посылающие никаких откликов (что, собственно, характерно в настоящее время для всех приборов L2) и не изменяющие значение TTL. Тогда придется использовать традиционные механизмы управления перегрузкой с помощью одной из модификаций медленного старта и моделей предотвращения перегрузки. Для сервис-провайдеров, которые знают структуру своих каналов (отсутствие приборов L2), можно использовать контроль по TTL. Мониторирование TTL может быть полезно и с точки зрения безопасности (выявление ложных маршрутизаторов).

Заполнение буфера получателя происходит за счет разности между входным потоком сегментов Iin и темпом обработки сегментов Iout (отправки последующим узлам).

Темп заполнения буфера определяется производной db/dt. Если уровень заполнения достигает Bmax, следующий пришедший сегмент будет потерян. Значение Bmax в общем случае определяется неравенством Bmax >

BRTT/MSS. Сетевое устройство должно отслеживать уровень заполнения своего буфера. И, если после получения очередного сегмента оказывается, что

b(t) + db/dtRTT + 8 > Bmax,

то всем отправителям, которые используют данное устройства для передачи данных, должен быть послан отклик с window=0 (сигнал прекращения передачи). 8 - конфигурационный параметр. Выполнение данного условия делает переполнение буфера практически маловероятным. Если после получения window=0 клиент все равно посылает сегмент ( агрессивное поведение), такой сегмент отбрасывается и в буфер не попадает, даже если там имеется свободное место. Window 0 посылается клиентам, например, при выполнении условия b(t) < (Втах -28). Алгоритм управления значением CWND отправителей по возможности не должен допускать такого развития событий. При получении отклика, в котором содержится уведомление, что b(t) > (Втах -28) значение CWND должно быть уменьшено на 1 (при двух таких

уведомлениях подряд - на 4 и т.д.). Стратегия может варьироваться. Так как и отправитель, и получатель могут владеть полной информацией, можно даже ввести наказание для отправителей, нарушающих принятые правила (отбрасывание пакетов в течение заданного времени или установка window=0).

В традиционной версии TCP для установления оптимального значения CWND предусмотрен режим медленного старта. Это делается через механизм управления CWND. Для оптимального использования канала должно

выполняться очевидное условие window > RTT-B/MSS (window - значение ширины скользящего окна). В любой момент времени window = min(window,CWND), то есть почти всегда меньше оптимального значения. А при медленном старте CWND варьируется от 1 до максимально возможного значения, которое может быть существенно меньше window. Связано это с тем, что ни отправитель, ни получатель обычно не владеет информацией о заполнении буферов и поиск допустимой величины window осуществляется на ощупь.

В случае К=1 или в ситуации, когда все сетевые приборы вдоль пути следования выдают данные о степени заполнения своих буферов, ситуация меняется радикально.

Если буферы свободны (b=0, что нормально в начале передачи), и

RTT-B/MSS < Bmax, то сразу реализуется значение CWND=window=

RTT-B/MSS и, тем самым, исключается этап медленного старта. Значение RTT предполагается определенным на фазе установления соединения, тогда же получается первая информация о заполнении буферов по пути следования сегмента.

Алгоритмы вычисления среднего значения RTT и величины RTO остаются теми же, что и в традиционном протоколе ТСР.

Литература

1. Ю.А.Семенов Протоколы Интернет. Энциклопедия , Горячая линия -Телеком, М, 2001.

2. T. V. Lakshman, Upamanyu Madhow, The performance of TCP/IP for networks with high bandwidth-delay products and random loss ,

Infocom 97, апрель, 1997, IEEE/ACM Trans. Networking, V5, N3, p.336-350, June 1997. (http: www.ece.ucsb.edu/Faculty/Madhow/publications.html)

3. W. Xu, A.G. Qureshi and K.W. Sarkies, Novel TCP congestion control scheme and its performance evaluation , IEE Proc. Commun., Vol. 149, No. 4, August 2002 217