Если один из входящих пакетов содержит ECN, TCP-получатель узнает об этом и с помощью флага ECE (ECN-эхо) сообщает отправителю о перегрузке. Отправитель подтверждает получение этого сигнала с помощью флага CWR (Окно перегрузки уменьшено).

На такие сигналы отправитель реагирует так же, как и на потерю пакетов. Но теперь результат выглядит лучше: перегрузка обнаружена, хотя ни один пакет не пострадал. ECN описаны в RFC 3168. Так как им требуется поддержка как хостов, так и маршрутизаторов, в интернете они не слишком распространены.

Больше информации обо всех методах контроля перегрузки в TCP вы найдете в RFC 5681.

6.5.11. CUBIC TCP

Чтобы справиться с растущим значением произведения пропускной способности на задержку, была разработана версия протокола TCP под названием CUBIC TCP (Ха и др.; Ha et al., 2008). Как уже упоминалось, сетям с большой величиной этого параметра необходимо множество RTT, чтобы обеспечить максимальную пропускную способность для сквозного пути. Суть CUBIC TCP сводится к тому, что окно перегрузки растет в зависимости от времени с момента прибытия последнего дубликата подтверждения (а не просто на основании поступления подтверждений).

Корректировка окна перегрузки в зависимости от времени также производится несколько иным образом. В отличие от описанного ранее стандартного контроля перегрузки по правилу AIMD, окно растет как кубическая функция; при этом после начального роста оно выходит на «плато», после которого следует период еще более быстрого увеличения. Рост окна перегрузки при использовании протокола CUBIC TCP показан на илл. 6.49. Одно из главных отличий CUBIC от других версий TCP — окно меняется как функция времени, прошедшего после последней перегрузки. Сначала оно быстро увеличивается, затем выходит на «плато» с размером, достигнутым отправителем перед последней перегрузкой, после чего снова растет для обеспечения максимально возможной скорости, пока не возникнет новая перегрузка.

Илл. 6.49. Процесс изменения окна перегрузки с течением времени при использовании CUBIC TCP

Протокол CUBIC TCP по умолчанию реализован в ядре Linux версий 2.6.19 и выше, а также в современных версиях Windows.

34 Долгое время шахтеры использовали канареек в качестве средства обнаружения опасного для жизни рудничного газа. — Примеч. ред.

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).