Компьютерные сети. 6-е изд.

6.6. Транспортные протоколы и контроль перегрузки

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

6.6.1. QUIC

Протокол QUIC (Quick UDP Internet Connections — быстрые интернет-соединения UDP) был изначально предложен в качестве транспортного протокола, призванного улучшить ряд характеристик TCP относительно пропускной способности и величины задержки. Еще до стандартизации он уже использовался более чем в половине соединений между браузером Chrome и сервисами Google. Несмотря на это, он не поддерживается большинством остальных веб-браузеров.

Как и предполагает его название, протокол QUIC работает поверх UDP и служит главным образом для ускорения прикладных протоколов, в частности веб-протоколов, о которых пойдет речь в главе 7. В ней мы подробно поговорим о том, как QUIC взаимодействует с прикладными протоколами интернета. Как мы вскоре убедимся, интернет требует установления множества параллельных соединений для загрузки отдельной веб-страницы. Поскольку многие из этих соединений представляют собой соединения с общим сервером, установление нового соединения для загрузки каждого отдельного веб-объекта может привести к значительным тратам ресурсов. В результате QUIC стремится мультиплексировать такие соединения в единый UDP-поток, гарантируя при этом, что откладывание пересылки одного веб-объекта не заблокирует передачу остальных.

Базируясь на протоколе UDP, QUIC не обеспечивает надежную передачу автоматически. При потере данных одного потока он может продолжить независимую транспортировку данных других потоков, что в итоге повышает производительность каналов с высокой частотой ошибок передачи. В QUIC также применяется ряд других методов оптимизации для повышения производительности. Среди них вложение информации о шифровании прикладного уровня при установлении транспортного соединения и независимое шифрование каждого пакета (чтобы потеря одного из них не препятствовала декодированию последующих пакетов). Кроме того, QUIC может ускорять передачу обслуживания между сетями (например, переключение с мобильного соединения на Wi-Fi). Он использует идентификатор соединения для сохранения состояния, когда конечные точки меняют сеть.

6.6.2. BBR: контроль перегрузки на основе пропускной способности узких мест

Если буферы узких мест слишком велики, алгоритмы контроля перегрузки на основе потерь (включая описанные выше) в итоге заполняют эти буферы, приводя к излишней сетевой буферизации (bufferbloat). Механизм ее возникновения прост: если у сетевых устройств на пути очень крупные буферы, TCP-отправитель с большим окном перегрузки будет передавать данные со скоростью, намного превышающей пропускную способность сети, прежде чем получит сигнал о потере. Буферы в середине сети заполнятся, что отсрочит наступление перегрузки для отправителей, передающих данные слишком быстро (вместо того, чтобы удалить пакеты). Также это увеличивает сетевую задержку для других отправителей, пакеты которых помещаются в очередь данного буфера (Геттис; Gettys, 2011).

Решить проблему излишней сетевой буферизации можно несколькими способами. Один из них заключается в уменьшении буферов. К сожалению, в этом пришлось бы убедить поставщиков и производителей всех сетевых устройств, от беспроводных точек доступа до магистральных маршрутизаторов. Даже если бы это было возможно, в сетях существует слишком много устаревших устройств, и полагаться лишь на этот подход нельзя. Другое решение — использовать альтернативный метод контроля перегрузки, не основанный на потере данных. Именно таким методом является алгоритм BBR (Bottleneck Bandwidth and RTT — пропускная способность узких мест и время в пути туда-обратно).

Задача BBR — оценить пропускную способность узких мест и величину RTT и выбрать подходящую рабочую точку для отправки данных, исходя из этих оценок. Соответственно, BBR непрерывно отслеживает эти параметры. Поскольку TCP уже учитывает RTT, BBR лишь расширяет имеющийся функционал, проверяя, как с течением времени меняется скорость доставки транспортного протокола. Фактически в качестве пропускной способности узких мест принимается максимальная оценка скорости доставки, полученная в течение заданного времени (обычно это 6–10 RTT).

Общая идея алгоритма BBR сводится к следующему. Пока объем данных не превышает произведение пропускной способности на задержку, RTT не увеличивается, поскольку при этом не происходит дополнительной буферизации. Скорость доставки обратно пропорциональна RTT и пропорциональна объему передаваемых пакетов (размеру окна). Когда объем передаваемых пакетов превышает произведение пропускной способности на задержку, величина задержки начинает расти, так как пакеты помещаются в очередь, а скорость доставки перестает увеличиваться. Именно в этот момент требуется алгоритм BBR. На илл. 6.50 показана зависимость RTT и скорости доставки от объема передаваемых данных (еще не подтвержденных). Оптимальной рабочей точкой для BBR является то место, где рост объема трафика ведет к увеличению RTT (но не скорости доставки).

Таким образом, ключевая составляющая алгоритма BBR — это постоянное обновление оценок пропускной способности узких мест и RTT по мере изменения этих параметров. Каждое подтверждение предоставляет актуальную информацию о величине RTT и средней скорости доставки. При этом проверяется, не ограничивается ли скорость доставки приложениями (как часто бывает при использовании запросно-ответных протоколов). Второй составляющей BBR является непосредственно подстройка скорости передачи данных с учетом пропускной способности узких мест. Подстройка скорости (pacing rate) — критически важный параметр контроля перегрузки на основе BBR. В устойчивом состоянии используемая алгоритмом скорость отправки данных просто представляет собой функцию от пропускной способности узких мест и RTT.

Илл. 6.50. Рабочая точка алгоритма BBR

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

Компания Google широко использует алгоритм BBR и во внутренней магистральной сети, и во многих своих приложениях. Однако есть один нерешенный вопрос: насколько хорошо контроль перегрузки на базе BBR может соперничать с традиционным контролем перегрузки на базе TCP. Так, в ходе недавно проведенного эксперимента исследователи обнаружили, что BBR-отправитель потреблял 40 % пропускной способности канала при совместном использовании сетевого пути с 16 другими транспортными соединениями, каждое из которых получило менее 4 % от оставшейся пропускной способности (Уэр и др.; Ware et al., 2019). Можно доказать, что BBR часто потребляет фиксированную долю доступной пропускной способности, независимо от количества конкурирующих TCP-потоков. К сожалению, лучший способ проверить, насколько хорошо новые алгоритмы контроля перегрузки обеспечивают равнодоступность, сводится к тому, чтобы просто применить их и посмотреть, что получится. По-видимому, предстоит значительная работа по обеспечению нормального взаимодействия BBR с TCP-трафиком в интернете.

6.6.3. Будущее протокола TCP

TCP — «рабочая лошадка» интернета — используется многими приложениями; с течением времени разработчики видоизменяют и дополняют этот протокол, стараясь добиться высокой производительности в разнообразных сетях. На сегодняшний день существует много версий, каждая из которых добавляет что-то новое к классическим алгоритмам, описанным здесь; особенно это касается контроля перегрузки и устойчивости к сетевым атакам. По всей вероятности, TCP будет развиваться параллельно с интернетом. Здесь мы рассмотрим два частных вопроса.

Во-первых, TCP не решает проблем транспортной семантики, актуальных для многих приложений. К примеру, некоторые из них хотят, чтобы границы передаваемых ими сообщений или записей сохранялись. Другие приложения нацелены на работу с группами взаимосвязанных сообщений (например, веб-браузер, загружающий несколько объектов с одного сервера). Некоторым приложениям нужны дополнительные возможности управления сетевыми путями. TCP со своим стандартным интерфейсом сокетов не в состоянии выполнить эти требования. В результате каждое приложение вынуждено самостоятельно решать проблемы, которые не по силам TCP. Это привело к созданию новых протоколов со слегка измененным интерфейсом, таких как SCTP и SST. Но каждый раз, когда кто-то предлагает изменить проверенный механизм, образуется два противоборствующих лагеря: «Пользователи хотят новых возможностей» и «Если ничего не сломано, не надо ничего чинить».