Эвристический метод реализации этой идеи называется быстрым восстановлением (fast recovery). Это временный режим, направленный на поддержание учета скорости прихода подтверждений в тот момент, когда порогом медленного старта становится текущий размер окна или его половина (во время быстрой повторной передачи). Для этого дубликаты подтверждений (включая те три, которые инициировали быструю повторную передачу) подсчитываются до тех пор, пока число пакетов в сети не снизится до нового порогового значения. На это уходит примерно половина RTT. С этого момента на каждый полученный дубликат подтверждения отправитель может передавать в сеть новый пакет. Через один RTT после быстрой повторной передачи получение потерянного пакета подтвердится. В это время поток дубликатов подтверждений прекратится, и алгоритм выйдет из режима быстрого восстановления. Окно перегрузки будет равняться новому порогу медленного старта и начнет увеличиваться линейно.
Этот метод позволяет TCP избегать медленного старта в большинстве ситуаций, за исключением случаев установления нового соединения и возникновения тайм-аутов. Последнее может произойти, если теряется больше одного пакета, а быстрая повторная передача не помогает. Вместо повтора медленного старта окно перегрузки активного соединения перемещается по пилообразным (sawtooth) линиям аддитивного увеличения (на один сегмент за RTT) и мультипликативного уменьшения (в полтора раза за RTT). Это и есть правило AIMD, которое мы с самого начала хотели реализовать.
Такое пилообразное движение показано на илл. 6.47. Данный метод используется в протоколе TCP Reno, названном в честь выпущенного в 1990 году дистрибутива 4.3BSD Reno. По сути, это TCP Tahoe с быстрым восстановлением. После начального медленного старта окно перегрузки растет линейно, пока отправитель не обнаружит потерю пакета, получив нужное количество дубликатов подтверждения. Потерянный пакет передается повторно, и далее алгоритм работает в режиме быстрого восстановления. Этот режим дает возможность продолжать учет скорости прихода подтверждений, пока не придет подтверждение доставки повторно переданного пакета. После этого окно перегрузки принимает значение, равное новому порогу медленного старта, а не единице. Это продолжается неопределенно долго. Почти все время размер окна перегрузки близок к оптимальному значению произведения пропускной способности и времени задержки.
Механизмы выбора размера окна, использующиеся в TCP Reno, составляли основу контроля перегрузки в TCP более двух десятилетий. За это время они претерпели ряд незначительных изменений, например появились новые способы
Илл. 6.47. Быстрое восстановление и пилообразный график TCP Reno
выбора начального окна, были устранены различные примеры неоднозначности. Усовершенствования коснулись и механизмов восстановления после потери двух или более пакетов. Так, версия TCP NewReno использует номера частичных подтверждений, полученных после повторной передачи одного потерянного пакета для восстановления другого (Хо; Hoe, 1996) (см. RFC 3782). С середины 1990-х годов стали появляться варианты описанного выше алгоритма, основанные на других законах управления. К примеру, в системе Linux используется CUBIC TCP (Ха и др.; Ha et al., 2008), а в Windows — Compound TCP (Тань и др.; Tan et al., 2006).
Два более серьезных нововведения касаются реализаций TCP. Во-первых, сложность TCP состоит в том, что по потоку дубликатов подтверждений нужно определить, какие пакеты были потеряны, а какие — нет. Номер накопительного подтверждения не содержит такой информации. Простым решением стало применение выборочных подтверждений SACK, в которых может содержаться до трех диапазонов успешно полученных байтов. Эти сведения позволяют отправителю более точно определять, какие пакеты следует передавать повторно, а также следить за еще не доставленными пакетами.
При установлении соединения отправитель и получатель передают друг другу параметр SACK permitted, сообщая о возможности работы с выборочными подтверждениями. Когда SACK включены, обмен данными происходит, как показано на илл. 6.48. Получатель использует поле Acknowledgement number обычным способом — как накопительное подтверждение последнего по порядку байта, который был принят. Когда пакет 3 приходит вне очереди (так как пакет 2 потерян), получатель отправляет SACK option для полученных данных вместе с накопительным подтверждением (дубликатом) для пакета 1. SACK option содержит диапазоны байтов, которые были получены сверх числа, заданного накопительным подтверждением. Первый из них — пакет, к которому относится дубликат подтверждения. Следующие диапазоны, если они есть, относятся к последующим блокам. Обычно применяется не более трех диапазонов. К моменту прихода пакета 6 были использованы два байтовых диапазона, указывающих на получение пакета 6, а также 3 и 4 (в дополнение к тем, которые пришли до пакета 1). Учитывая все принятые SACK option, отправитель решает, какие пакеты передать заново. В данном случае неплохо было бы повторить пакеты 2 и 5.
Илл. 6.48. Выборочные подтверждения
SACK содержат рекомендательную информацию. Фактическое обнаружение потерь пакетов по дубликатам подтверждений и изменение окна перегрузки происходят так же, как и раньше. Тем не менее SACK упрощают процесс восстановления TCP в ситуациях, когда несколько пакетов теряются примерно в одно и то же время, поскольку TCP-отправитель знает, какие пакеты не дошли до адресата. Сегодня SACK широко распространены. Они описаны в RFC 2883, а контроль управления TCP с использованием SACK — в RFC 3517.
Второе изменение заключается в использовании явных уведомлений о перегрузке ECN в качестве дополнительного сигнала помимо потери пакета. ECN — это механизм IP-уровня, позволяющий сообщать хостам о перегрузке (см. раздел 5.3.2). С их помощью TCP-получатель принимает сигналы перегрузки от IP.
ECN включены для TCP-соединения, если при его установлении отправитель и получатель сообщили друг другу, что они поддерживают такие уведомления, — с помощью битов ECE и CWR. В заголовке каждого пакета с TCP-сегментом указывается, что этот пакет может передавать ECN. При угрозе перегрузки маршрутизаторы с поддержкой ECN помещают соответствующие сигналы в подходящие для этого пакеты, вместо того чтобы удалять эти пакеты, когда перегрузка действительно происходит.
Если один из входящих пакетов содержит 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 взаимодействует с прикладными протоколами интернета. Как мы вскоре убедимся, интернет требует установления множества параллельных соединений для загрузки отдельной веб-страницы. Поскольку многие из этих соединений представляют собой соединения с общим сервером, установление нового соединения для загрузки каж