Кратко о поведении TCP при потерях и задержках

TCP — протокол управления перегрузкой. При обнаружении потерянного сегмента $таймаутилимножественныедублирующиеACK$ большинство реализаций $Reno,NewReno$ сокращают congestion window $cwnd$ примерно вдвое и переходят в фазу восстановления/медленного роста. Это приводит к «пилообразной» отправке: cwnd растёт $slow‑start/конг.избегание$, затем при потере резко падает.Задержка $RTT$ влияет на скорость нарастания cwnd и частоту подтверждений; большая RTT замедляет восстановление и уменьшает среднюю пропускную способность.При ненулевой вероятности случайных потерь $невызванныхперегрузкой$ TCP всё равно воспринимает их как сигнал перегрузки и снижает скорость, что сильно бьёт по пропускной способности.

Модель сети
Параметры:

RTT = 100 ms = 0.1 sканал = 10 Mbpsвероятность потери пакета p = 1% = 0.01файл = 100 MB $явозьму100\cdot 10^6байт=800\cdot 10^6бит;еслисчитатьMiB—получитсячутьбольше,см.ниже$MSS ≈ 1460 байт $стандартноезначение$

Оценка средней пропускной способности TCP при потерях
Для быстрого приближения часто используют упрощённую формулу $Mathisetal.$:
Throughput ≈ 1.22 · MSS / $RTT\cdot sqrt(p)$

Подставляем:

MSS = 1460 байт = 11 680 битsqrt$p$ = sqrt$0.01$ = 0.1
Throughput ≈ 1.22 · 11 680 / $0.1\cdot 0.1$ ≈ 1.22 · 1 168 000 ≈ 1 425 000 бит/с ≈ 1.43 Mbps

Время передачи 100 MB:

Биты файла ≈ 800 000 000 битВремя ≈ 800e6 / 1.425e6 ≈ 562 s ≈ 9.4 минуты

Если считать 100 MiB = 104 857 600 байт → 838 860 800 бит → время ≈ 589 s ≈ 9.8 минуты.

Контраст: при отсутствии потерь максимальная скорость 10 Mbps даёт время 800e6 / 10e6 = 80 s $1.3минуты$. То есть 1% потерь увеличивает время в ~7× $поэтоймодели$.

Почему такие потери так сильно бьют?
Факторы, лимитирующие пропускную способность

Потери пакетов $p$. В квадратном корне в формуле — даже 1% даёт сильное падение пропускной способности.Механизм управления перегрузкой TCP $политикаснижениеcwndприпотере$. Loss‑based алгоритмы принудительно уменьшают скорость.RTT $0.1s$ тормозит восстановление cwnd: при большом RTT возвращение к «полной» скорости занимает больше времени.Тайм‑аута RTO и повторные передачи: при потере, если нет быстрых повторов $SACK/dupACK$, срабатывает RTO — большой простой.Ограничивающие настройки стеков: отключённый window scaling, маленькие буферы $rmem/wmem$, отсутствие SACK снижают эффективность.Overhead протоколов $TCP/IPзаголовки$, small MSS/MTU — влияют не так много, но есть.Тип контроля $RenovsCUBICvsBBR$. Loss‑based CC справляются хуже на сетях с высокой случайной потерей.

Практические оптимизации
A. На уровне TCP/OS $стекTCP$

Включить TCP SACK $SelectiveACK$ и timestamps — уменьшит RTO и позволит точечные восстановление.Включить масштабирование окна $windowscaling$ и увеличить rmem/wmem $buffersizes$ до величин, ≥ BDP $см.ниже$.Увеличить initial congestion window $RFC6928—до10MSS$ для ускорения чуть меньших загрузок.Использовать более подходящий алгоритм управления перегрузкой:
CUBIC обычно лучше Reno на больших каналах/RTT.BBR $Google$ — модельно ориентированный: он пытается работать на фактической пропускной способности и менее чувствителен к потерям, часто даёт гораздо лучшую степень использования канала при случайных потерях.Для мобильных/беспроводных сетей варианты вроде TCP Westwood могут быть лучше.Использовать Jumbo frames / увеличенный MTU, если сеть позволяет $меньшезаголовков\to меньшепакетов\to меньшешансовпотерь$.Настроить RTO/параметры таймеров аккуратно, включить TCP fast retransmit/fast recovery.На уровне оборудования — исправить причину потерь: ошибка канала, битовые ошибки, перегруженные очереди — устранять на уровне link/physical.

B. На уровне приложения/архитектуры

Распараллеливание загрузки: несколько TCP‑потоков $несколькосоединений$ для одного файла часто увеличивают суммарную скорость, потому что каждое соединение имеет своё cwnd и теряет меньше суммарного времени $ноэто«хак»,можетдавитьнасеть$.Протоколы поверх UDP/QUIC: QUIC $TLS+TCP‑like,носсобственнымуправлением$ и приложения на UDP с FEC/ARQ могут быть эффективнее при случайных потерях $контрольнауровнеприложения,болееагрессивные/адаптивныевосстановления$.Использовать FEC/ерейзур‑кодирование $ForwardErrorCorrection$ для скрытия небольших потерь без реконструкции.Разбивать/шардировать файл на куски и параллельно загружать $параллелизмнауровнеHTTPrangerequests$.Кеширование/CDN — сократить путь и вероятность потерь/высоких RTT.Компрессия и дельта‑передача $еслиприменимо$ — уменьшает объём передаваемых данных.При долгих загрузках — поддержка resume, проверка целостности, адаптивный размер сегментов.

Примерные численные эффекты оптимизаций

Включение SACK/вменяемых буферов обычно не изменит выраженно формулу Mathis, но снизит количество RTO и потерянных периодов, реально улучшая throughput.Переключение на BBR или агрессивный конгест‑алгоритм может подтянуть throughput ближе к 10 Mbps, если потеря не является следствием фактического переполнения очередей $т.е.еслипотери—случайные/нафизическомуровне$. Результат зависит от характера потерь.Использование 4 параллельных TCP‑соединений $приблизительно$ может дать ≈4× throughput одной сессии $видеале$, т. е. около 5.7 Mbps по нашей оценке → время ≈ 800e6/5.7e6 ≈ 140 s $2.3мин$. Это распространённый практический трюк, но ведёт к «нечестному» использованию канала.

Дополнительно: Bandwidth‑Delay Product $BDP$

BDP = link_capacity · RTT = 10 Mbps · 0.1 s = 1 Mbit = 125 KB ≈ 86 MSS.Для полного использования канала cwnd и receive window должны быть ≥ BDP. Но при потерах cwnd редко стабильно держится на таком уровне.

Вывод / рекомендации

При RTT=100 ms и случайной потере 1% типичный TCP‑flow $loss‑based$ даст порядка 1.4 Mbps, что на 100 MB значит ~9–10 минут передачи $вместо1.3минприотсутствиипотерь$.Первое, что надо — найти и по возможности устранить первопричину потерь $linkquality,ошибки,очереди$.На уровне стека: включить SACK/timestamps/window scaling, увеличить буферы, рассмотреть смену алгоритма на CUBIC/BBR.На уровне приложения: использовать параллельные загрузки или QUIC/UDP‑решения, FEC, CDN/шардинг/декомпозицию файла.Если нужна практическая настройка вашего сервера/клиента — скажите ОС/стек $Linux,Windows,конкретноеприложение$ — могу предложить конкретные параметры и команды.

Если хотите, могу:

Построить более точную оценку по модели Padhye $учитываетRTOидругиеэффекты$ и выдать интервал ожиданий;Подготовить конкретные команды для Linux $sysctlпараметры$ и конфигурацию для использования BBR/увеличения буферов.