Общая идея алгоритма 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. Но каждый раз, когда кто-то предлагает изменить проверенный механизм, образуется два противоборствующих лагеря: «Пользователи хотят новых возможностей» и «Если ничего не сломано, не надо ничего чинить».
6.7. Вопросы производительности
Вопросы производительности играют критически важную роль в компьютерных сетях. Когда сотни или тысячи компьютеров соединены вместе, их взаимодействие становится очень сложным и может привести к непредсказуемым последствиям, например к низкой производительности, причины которой довольно трудно определить. В следующих разделах мы обсудим многие вопросы, связанные с производительностью сетей, определим круг существующих проблем и обсудим методы их решения.