Новый транспортный протокол BIC-TCP обещает преобразить Internet

Получивший сегодня широкое распространение транспортный протокол TCP/IP разработан в 1980-х годах, когда скорости передачи данных и пропускная способность Internet были намного ниже современных. Теперь же в случае применения его в высокоскоростных сетях проявились такие присущие протоколу недостатки, как плохая масштабируемость и неэффективное использование полосы пропускания. Осознав это, сетевая общественность отреагировала довольно быстро. Были предложены несколько многообещающих новых протоколов, в частности High Speed TCP (HSTCP), Scalable TCP (STCP), FAST, XCP, SABUL. Пока эти проколы не у дел, правда, сейчас неизвестна и судьба BIC-TCP. Но, судя по приему, который оказала ему компьютерная пресса, и результатам испытаний, проведенных в Стэнфордском университете, BIC-TCP уготована более приятная участь, чем пополнить список перспективных, но так и не реализованных проектов. Однако, прежде чем познакомиться с основными принципами работы предложенного протокола, напомним некоторые особенности передачи данных и управления перегрузкой в сетях на базе TCP/IP, необходимые для понимания его сути.

Пакеты, сегменты и сигнал ACK

Основной единицей, передаваемой в IP-сетях, является пакет, содержащий некоторую порцию данных. Протокол же TCP гарантирует, что сегмент данных будет, в конце концов, доставлен из, скажем, точки A в точку B. Однако нет никаких гарантий, что этот пакет прибудет по назначению. Пакеты могут отбрасываться, задерживаться, приходить с нарушением очередности. Хотя порядок их следования восстанавливается на приемном конце, но не существует способа восполнить данные из потерянных пакетов. Для обеспечения доставки всех данных отправитель требует от получателя подтверждения (ACKnowledgement) для переданных пакетов. Время на передачу пакета и подтверждение его приема называется периодом кругового обращения сообщения (Round Trip Time -- RTT).

Как следует из предыдущего абзаца, термины "пакеты" и "сегменты" не являются взаимозаменяемыми. Первые используются на сетевом (IP) уровне стека протоколов. С помощью пакетов информация передается от одного местоположения к другому, тогда как сегменты -- фрагменты данных, которые запрашивают и обрабатывают приложения. Это значит, что в случае необходимости повторной передачи потерянных данных протокол TCP отошлет тот же сегмент, но он будет инкапсулирован в новый IP-пакет.

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

При передаче возникают ситуации, когда необходимо регулировать скорость поступления пакетов для того, чтобы передающий узел не "затопил" приемный чрезмерным количеством данных. Это выполняется посредством управления потоком данных, отдельные методы которого мы вкратце рассмотрим.

Управление потоком данных

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

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

Эту проблему частично решает управление потоком методом раздвижных окон. Продемонстрируем суть этого метода на простом примере. Пусть имеются две станции A и B, и размер буфера станции B составляет K пакетов. Это значит, что станция A может передать K пакетов без ожидания подтверждения. В общем случае станция A хранит список порядковых номеров отправляемых пакетов, а станция B -- список порядковых номеров пакетов, которые она готова принять. Каждый из этих списков называется окном, и основная цель этого абзаца -- введение данного понятия.

Второй ключевой проблемой (к ее краткому рассмотрению мы подходим) является...

...перегрузка в сетях передачи данных

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

С ростом нагрузки на сеть увеличивается длина очередей на различных узлах. В конечном счете, достигается точка максимальной производительности сети, после этого ее пропускная способность резко снижается с увеличением поступающей нагрузки. Это вызывается тем, что размеры буферов на узлах ограничены. Когда они заполняются, узлы не в состоянии принимать пакеты. Вследствие этого отправители вынуждены, кроме новых пакетов, опять передавать отклоненные. Даже пакеты, доставленные успешно, могут передаваться снова, так как время их подтверждения превышает допустимое время ожидания отправителя, определенное в таймере повторной передачи (Round Trip Timeout -- RTO), и тот посылает их снова. Процесс лавинообразно нарастает, и в конце концов пропускная способность сети снижается до нуля.

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

Замедленный старт

Чем больше установленное в TCP окно передачи, тем больше сегментов в состоянии отправить в сеть источник, прежде чем включить таймер ожидания подтверждения. Это может сразу создать проблему перегрузки. Поэтому была предложена процедура, известная под названием замедленного старта. Здесь используется окно перегрузки (congestion window -- cwnd), размер которого измеряется в сегментах и управляется отправителем. При открытии нового соединения объект TCP присваивает cwnd начальное значение 1. Другими словами, TCP имеет право передать лишь один сегмент и затем должен ожидать подтверждения. После каждого подтверждения значение cwnd увеличивается на 1 до некоторой максимальной величины. С приходом подтверждений TCP получает право расширять окно, пока поток данных не станет контролироваться уже не размером cwnd, а поступающими подтверждениями. Важно отметить, что на самом деле значение cwnd растет не линейно, а экспоненциально, так как окно увеличивается на 1 для каждого приходящего подтверждения.

Динамическая установка окна

Экспоненциальный рост cwnd при замедленном старте может оказаться слишком быстрым и привести к перегрузке. Поэтому было предложено вначале использовать замедленный старт, а затем увеличивать размер cwnd линейно. Для этого устанавливается пороговое значение окна перегрузки, равное половине текущего, при котором произошла потеря пакета. На участке до порогового значения выполняется процедура замедленного старта, а после этого увеличение окна происходит линейно. Таким образом, TCP увеличивает cwnd на 1 при получении каждого подтверждения и уменьшает его вдвое при обнаружении потери пакета.

А теперь приведем некоторые цифры, характеризующие "эффективность" работы протокола TCP в высокоскоростных сетях. Так, для полной утилизации канала с пропускной способностью 10 Gbps при передаче пакетов длиной 1500 байт требуется 83 333 RTT. При значении RTT, равном 100 мс, это займет около 1,5 ч. Далее, при передаче нескольких состязающихся за ресурс потоков протокол TCP ведет себя несправедливо для разных по значению RTT: для более коротких RTT окно перегрузки будет расти быстрее. Таким образом, широкое распространение высокоскоростных сетевых технологий поставило задачу разработки протокола, который удовлетворял бы трем критериям: был справедлив к RTT, хорошо масштабировался и дружественно относился к TCP (TCP friendliness). Последнее означает, что он справедливо разделял бы полосу пропускания с TCP-потоками при передаче данных по общему каналу. Именно этими свойствами, по мнению авторов, и обладает предложенный ими протокол.

Основные принципы работы протокола BIC-TCP

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

BIC-TCP функционально состоит из двух частей: увеличения с помощью дихотомического поиска (binary search increase) и аддитивного увеличения (additive increase).

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

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

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

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

Таковы вкратце идеи и принципы, заложенные в BIC-TCP. В заключение отметим особенности протокола, которые могут определить его дальнейшую судьбу.

Разработчики BIC-TCP обращают внимание специалистов на то, что при разворачивании существующих протоколов могут возникнуть серьезные проблемы, связанные с появляющейся при перегрузках неравноправностью для потоков с разным временем RTT. В противоположность этому новый протокол рассматривает обеспечение RTT-справедливости как важный фактор при управлении перегрузкой в высокоскоростных сетях. Испытания, проведенные в Центре линейных ускорителей Стэнфордского университета, свидетельствуют о том, что, кроме RTT-справедливости, BIC-TCP поддерживает дружественность к TCP-трафику, обладает хорошей масштабируемостью и демонстрирует высокую производительность по всем трем упомянутым метрикам. Станет ли он стандартом, покажет будущее.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365