LEDBAT

LEDBAT (Low Extra Delay Background Transport, с англ. — «Фоновый транспорт с низкой дополнительной задержкой») — это способ быстрой передачи данных в Интернете без засорения сети^[1]. LEDBAT был изобретен Станиславом Шалуновым^{[англ.][2][3]} и используется Apple для обновлений программного обеспечения и BitTorrent в большинстве своих передач^[4], а также при распространении программного обеспечения Microsoft SCCM^[5]. По оценкам, LEDBAT будет переносить 13—20 % интернет-трафика^[6].

LEDBAT — это алгоритм управления перегрузкой, основанный на задержке, который использует всю доступную полосу пропускания при ограничении увеличения задержки^[7]. Он делает это путем измерения односторонней задержки и использования изменений в измерениях, чтобы ограничить перегрузку, которую вызывает сам поток LEDBAT в сети.

Контроль перегруженности LEDBAT преследует следующие цели^[2]:

1. Использовать всю доступную пропускную способность и поддерживать низкую задержку в очереди, когда другой трафик отсутствует;
2. Ограничить задержку в очереди, добавляемую к задержке остального трафика;
3. Быстро уступить стандартному TCP, который имеет ту же самую узкую ссылку.

Две основные реализации — это uTP от BitTorrent и как часть TCP от Apple. BitTorrent использует uTP для большей части трафика и делает код доступным по лицензии с открытым исходным кодом^[8]. Apple использует LEDBAT для обновлений программного обеспечения, так что большие загрузки программного обеспечения для Mac OS X компьютеров и устройств IOS не мешают нормальной деятельности пользователей. Кроме этого Apple делает доступным исходный код^[9].

Обе вышеперечисленные реализации направлены на ограничение задержки организации очереди до 100 мс. Это максимум времени задержки, разрешенный стандартизированным протоколом. Если один из них использует более низкое значение, то он будет голодать, когда используется другой^[2][9].

В Windows 10 в Anniversary Update появилась поддержка LEDBAT через опцию недокументированного сокета в качестве экспериментального модуля контроля перегрузки Windows TCP и Windows Server 2019^[10][11][12].

Предположения:

1. Часы отправителя и получателя не синхронизированы.
2. Отправитель отправляет с фиксированной скоростью.

Отправитель отправляет 5 пакетов данных каждые 10 тактов: ${\displaystyle 10,20,30,40,50}$. Единицы не важны. Получатель получает данные не только от этого конкретного отправителя, но и из других источников. Для 5 отправленных пакетов получатель получает их со следующими отсчетами тактов: ${\displaystyle 112,135,176,250,326}$. Первые различия (задержка в одну сторону) между полученным и отправленным счетчиком тактов: ${\displaystyle 102,115,146,210,276}$. Вторые различия (изменение в одну сторону задержки): ${\displaystyle 13(115-102),31,64,66}$. Из положительного увеличения задержки в одном направлении получатель сделает вывод о том, что перегрузка увеличивается, и соответственно скорректирует скорость передачи.

• TCP перегрузка контроля^[англ.]