какой механизм tcp позволяет предотвратить перегрузку сети

TCP Congestion Control или Почему скорость прыгает

Бывало ли у вас такое, что ставите файл на закачку, и скорость медленно, но верно возрастает, затем, в какой-то момент, резко снижается, затем опять возрастает? Закачка файла в один поток не обеспечивает полную скорость канала? Запускаете торрент-клиент, и пинг в игре сильно прыгает? Используете 3G-модем (или другую линию с относительно большой потерей пакетов) и не можете это терпеть?
Наверняка вы винили во всем ваш роутер, либо обвиняли своего провайдера в кривой настройке шейпера? Это влияет, но виноваты не они.
Итак, встречайте:

TCP Congestion Control, или TCP Congestion Avoidance Algorithm.

Что это такое?

Вкратце ­— алгоритмы, которые пытается сделать все возможное, чтобы обеспечить наиболее быструю скорость передачи данных между двумя узлами, передающими данные через TCP. Они управляют размером TCP-окна и могут ориентироваться на RTT (Round Trip Time — время от отправки запроса до получения ответа), потерю пакетов, время ожидания отправки пакета из очереди и т.д. Каждый алгоритм по разному ведет себя в той или иной ситуации и нет какого-то универсального.

Долгое время, в ходу были алгоритмы Reno, разработанный в 1990 году, и BIC. Первый применялся во всех ОС Windows до XP, а второй — в Linux до 2.6.18. Затем, в Windows Vista появился новый алгоритм Compound TCP, а в Linux сменили BIC на Cubic.

Какие есть алгоритмы?

Тест 3G

К сожалению, CUBIC, который используется по умолчанию во всех дистрибутивах, совершенно не подходит, например, для 3G-соединений. Ниже представлен график сравнения 4 алгоритмов congestion avoidance для HSDPA сетей за конец 2012 года из TCP Congestion Control over HSDPA: an Experimental Evaluation:

Как видите, CUBIC в отстающих. Он значительно повысил RTT на полной утилизации 3G канала, в то время как Westwood+ и NewReno более-менее справляются с этой проблемой.
Давайте взглянем на количество ретрансмиссий:

Как видно из графика, у CUBIC относительно большое количество ретрансмиссий

В то же время, он лидирует в скорости передачи данных за единицу времени.

Что это значит? Это значит, что с использованием Westwood+ или NewReno вы сможете комфортней серфить интернет, пока у вас скачивается большой файл.

Тест WiMAX и WiFi каналов

Тест взят из Comparative Performance Evaluation of TCP Variants in WiMAX (and WLANs) Network Configurations — еще одного интересного сравнения алгоритмов для беспроводных сетей.

В тесте №1 используется соединение компьютер-wimax.роутер-wimax.клиент с пропускной способностью между компьютером и роутером в 100 мбит/с и RTT в 45 мс и соотношением DL:UL 1:1 между wimax роутером и клиентом.
Зависимость эффективной передачи данных от потери пакетов:

Чуть изменим тест. В тесте №2 используется схема компьютер-роутер1-роутер2-wimax.роутер-wimax.клиент, где RTT 10 мс. между компьютером и первым роутером, далее используется 10 мбит/с канал с 25 мс. RTT, между вторым и wimax роутером канал опять 100 мбит/с c RTT в 10 мс.

Как видно из графиков, лидерство держит Westwood.
Картина для WiFi схожа с WiMAX:

Тест высокоскоростного канала

Этот тест взят из технического отчета алгоритма YeAH-TCP за 2006 год. Теоретически, YeAH является самым продвинутым алгоритмом и нацелен работать как можно лучше на высокоскоростных линиях, на линиях с высокой задержкой или высокими потерями пакетов.
Тесты делались с импользованием канала пропускной способностью в 500 mbit/s

В эффективной передаче данных в зависимости от RTT лидирует YeAH

Зависимость эффективной передачи данных и потери пакетов, опять YeAH занимает первое место

К сожалению, с YeAH на ядре 3.7 какие-то проблемы, через некоторое время он весит систему software interrupt’ами. Такого поведения не наблюдается на 3.6.

Как поменять?

Вместо заключения

На каналах вроде домашнего вайфая, рекомендую использовать Westwood или H-TCP. Для проводных каналов хорошим выбором может быть YeAH (если у вас не наблюдается с ним проблем), H-TCP или Illinois.

Источник

Внутренние механизмы ТСР, влияющие на скорость загрузки: часть 1

Ускорение каких-либо процессов невозможно без детального представления их внутреннего устройства. Ускорение интернета невозможно без понимания (и соответствующей настройки) основополагающих протоколов — IP и TCP. Давайте разбираться с особенностями протоколов, влияющих на скорость интернета.

IP (Internet Protocol) обеспечивает маршрутизацию между хостами и адресацию. TCP (Transmission Control Protocol) обеспечивает абстракцию, в которой сеть надежно работает по ненадежному по своей сути каналу.

Протоколы TCP/IP были предложены Винтом Серфом и Бобом Каном в статье «Протокол связи для сети на основе пакетов», опубликованной в 1974 году. Исходное предложение, зарегистрированное как RFC 675, было несколько раз отредактировано и в 1981 году 4-я версия спецификации TCP/IP была опубликована как два разных RFC:

TCP обеспечивает нужную абстракцию сетевых соединений, чтобы приложениям не пришлось решать различные связанные с этим задачи, такие как: повторная передача потерянных данных, доставка данных в определенном порядке, целостность данных и тому подобное. Когда вы работаете с потоком TCP, вы знаете, что отправленные байты будут идентичны полученным, и что они придут в одинаковом порядке. Можно сказать, что TCP больше «заточен» на корректность доставки данных, а не на скорость. Этот факт создает ряд проблем, когда дело доходит до оптимизации производительности сайтов.

Стандарт НТТР не требует использования именно TCP как транспортного протокола. Если мы захотим, мы можем передавать НТТР через датаграммный сокет (UDP – User Datagram Protocol) или через любой другой. Но на практике весь НТТР трафик передается через TCP, благодаря удобству последнего.

Поэтому необходимо понимать некоторые внутренние механизмы TCP, чтобы оптимизировать сайты. Скорее всего, вы не будете работать с сокетами TCP напрямую в своем приложении, но некоторые ваши решения в части проектирования приложения будут диктовать производительность TCP, через который будет работать ваше приложение.

Тройное рукопожатие

Все TCP-соединения начинаются с тройного рукопожатия (рис. 1). До того как клиент и сервер могут обменяться любыми данными приложения, они должны «договориться» о начальном числе последовательности пакетов, а также о ряде других переменных, связанных с этим соединением. Числа последовательностей выбираются случайно на обоих сторонах ради безопасности.

Клиент выбирает случайное число Х и отправляет SYN-пакет, который может также содержать дополнительные флаги TCP и значения опций.

SYN ACK

Сервер выбирает свое собственное случайное число Y, прибавляет 1 к значению Х, добавляет свои флаги и опции и отправляет ответ.

Клиент прибавляет 1 к значениям Х и Y и завершает хэндшейк, отправляя АСК-пакет.

Рис. 1. Тройное рукопожатие.

После того как хэндшейк совершен, может быть начат обмен данными. Клиент может отправить пакет данных сразу после АСК-пакета, сервер должен дождаться АСК-пакета, чтобы начать отправлять данные. Этот процесс происходит при каждом TCP-соединении и представляет серьезную сложность плане производительности сайтов. Ведь каждое новое соединение означает некоторую сетевую задержку.

Например, если клиент в Нью-Йорке, сервер – в Лондоне, и мы создаем новое TCP-соединение, это займет 56 миллисекунд. 28 миллисекунд, чтобы пакет прошел в одном направлении и столько же, чтобы вернуться в Нью-Йорк. Ширина канала не играет здесь никакой роли. Создание TCP-соединений оказывается «дорогим удовольствием», поэтому повторное использование соединений является важной возможностью оптимизации любых приложений, работающих по TCP.

TCP Fast Open (TFO)

Загрузка страницы может означать скачивание сотен ее составляющих с разных хостов. Это может потребовать создания браузером десятков новых TCP-соединений, каждое из которых будет давать задержку из-за хэндшейка. Стоит ли говорить, что это может ухудшить скорость загрузки такой страницы, особенно для мобильных пользователей.

TCP Fast Open (TFO) – это механизм, который позволяет снизить задержку за счет того, что позволяет отправку данных внутри SYN-пакета. Однако и у него есть свои ограничения: в частности, на максимальный размер данных внутри SYN-пакета. Кроме того, только некоторые типы HTTP-запросов могут использовать TFO, и это работает только для повторных соединений, поскольку использует cookie-файл.

Использование TFO требует явной поддержки этого механизма на клиенте, сервере и в приложении. Это работает на сервере с ядром Linux версии 3.7 и выше и с совместимым клиентом (Linux, iOS9 и выше, OSX 10.11 и выше), а также потребуется включить соответствующие флаги сокетов внутри приложения.

Специалисты компании Google определили, что TFO может снизить сетевую задержку при HTTP-запросах на 15%, ускорить загрузку страниц на 10% в среднем и в отдельных случаях – до 40%.

Контроль за перегрузкой

В начале 1984 года Джон Нейгл описал состояние сети, названное им как «коллапс перегрузки», которое может сформироваться в любой сети, где ширина каналов между узлами неодинакова.

Когда круговая задержка (время прохождения пакетов «туда-обратно») превосходит максимальный интервал повторной передачи, хосты начинают отправлять копии одних и тех же датаграмм в сеть. Это приведет к тому, что буферы будут забиты и пакеты будут теряться. В итоге хосты будут слать пакеты по нескольку раз, и спустя несколько попыток пакеты будут достигать цели. Это называется «коллапсом перегрузки».

Нейгл показал, что коллапс перегрузки не представлял в то время проблемы для ARPANETN, поскольку у узлов была одинаковая ширина каналов, а у бэкбона (высокоскоростной магистрали) была избыточная пропускная способность. Однако это уже давно не так в современном интернете. Еще в 1986 году, когда число узлов в сети превысило 5000, произошла серия коллапсов перегрузки. В некоторых случаях это привело к тому, что скорость работы сети падала в 1000 раз, что означало фактическую неработоспособность.

Чтобы справиться с этой проблемой, в TCP были применены несколько механизмов: контроль потока, контроль перегрузки, предотвращение перегрузки. Они определяли скорость, с которой данные могут передаваться в обоих направлениях.

Контроль потока

Контроль потока предотвращает отправку слишком большого количества данных получателю, которые он не сможет обработать. Чтобы этого не происходило, каждая сторона TCP-соединения сообщает размер доступного места в буфере для поступающих данных. Этот параметр — «окно приема» (receive window – rwnd).

Когда устанавливается соединение, обе стороны задают свои значения rwn на основании своих системных значений по умолчанию. Открытие типичной страницы в интернете будет означать отправку большого количества данных от сервера клиенту, таким образом, окно приема клиента будет главным ограничителем. Однако, если клиент отправляет много данных на сервер, например, загружая туда видео, тогда ограничивающим фактором будет окно приема сервера.

Если по каким-то причинам одна сторона не может справиться с поступающим потоком данных, она должна сообщить уменьшенное значение своего окна приема. Если окно приема достигает значения 0, это служит сигналом отправителю, что не нужно более отправлять данные, пока буфер получателя не будет очищен на уровне приложения. Эта последовательность повторяется постоянно в каждом TCP-соединении: каждый АСК-пакет несет в себе свежее значение rwnd для обеих сторон, позволяя им динамически корректировать скорость потока данных в соответствии с возможностями получателя и отправителя.

Рис. 2. Передача значения окна приема.

Масштабирование окна (RFC 1323)

Исходная спецификация TCP ограничивала 16-ю битами размер передаваемого значения окна приема. Это серьезно ограничило его сверху, поскольку окно приема не могло быть более 2^16 или 65 535 байт. Оказалось, что это зачастую недостаточно для оптимальной производительности, особенно в сетях с большим «произведением ширины канала на задержку» (BDP – bandwidth-delay product).

Чтобы справиться с этой проблемой в RFC 1323 была введена опция масштабирования TCP-окна, которая позволяла увеличить размер окна приема с 65 535 байт до 1 гигабайта. Параметр масштабирования окна передается при тройном рукопожатии и представляет количество бит для сдвига влево 16-битного размера окна приема в следующих АСК-пакетах.

Сегодня масштабирование окна приема включено по умолчанию на всех основных платформах. Однако промежуточные узлы, роутеры и сетевые экраны могут переписать или даже удалить этот параметр. Если ваше соединение не может полностью использовать весь канал, нужно начать с проверки значений окон приема. На платформе Linux опцию масштабирования окна можно проверить и установить так:

В следующей части мы разберемся, что такое TCP Slow Start, как оптимизировать скорость передачи данных и увеличить начальное окно, а также соберем все рекомендации по оптимизации TCP/IP стека воедино.

Источник

Как получить и измерить высокоскоростное соединение по TCP

1) Ограничения TCP

Скорость передачи данных зависит от сетевых и системных характеристик.

img1 Процесс передачи данных по сети

a) Буферы
Оригинальная конфигурация TCP ограничивает скорость передачи буфером (опция Window Size — «размер окна») и является полем размером в 2^16 байт (до 64 КБайт). Максимальная пропускная способность в данном случае:

Пример: У вас 100 мегабитное соединение к Интернету и до сервера задержка 100 мс.
Стандартным стеком TCP, максимальная скорость передачи данных не превысит 10 Мбит/сек
( 524288 бит / 0.1 сек = 5.24 Мбит/сек не смотря на то что у вас 100 мегабитный линк).

b) Bandwidth-delay product (BDP)
Производительность TCP в принципе не столько зависит от скорости канала, сколько от так называемом «bandwidth*delay product» или BDP (результат пропускная способность*задержка), который представляет собой число байт необходимых отправителю и получателю для максимального заполнения TCP соединения.
Проблемы производительности возникают в случаях так называемых «длинных и широких труб» (LFN «long fat network»), так как BDP в таком случае превышает размер окна TCP, тем самым ограничивая скорость передачи.

img2 Влияние задержки на максимальную пропускную способность TCP

Примером могут служить мобильный интернет или быстрый оптический линк.
Пример расчетов BDP:
a) широкополосный мобильный интернет: 10 Mb/s, 100 ms RTT
B×D = 10^7 b/s × 10^-1 s = 10^6 b, or 1 Mb / 125 kB
b) высокоскоростная наземной сеть: 1 Gb/s, 10 ms RTT
B×D = 10^9 b/s × 10^-2 s = 10^7 b, or 10 Mb / 1.25 MB

Рассчитать BDP можно тут.
”Размер окна” TCP должен превышать BDP для достижение максимальной нагрузки канала.

c) Protocol Overhead
По некоторым оценкам около 95% компьютеров мира подключены через технологию Ethernet.
Ethernet MTU (полезная нагрузка кадра Ethernet) = макс. 1500 bytes.
Если принять во внимание все заголовки Ethernet, IP, TCP, картина будет выглядеть так:

img3 Передача одного Ethernet кадра

Цифры указывают размер (в байтах) заголовка для определенного протокола.
IFG (Interframe gap) — обязательное межкадровое пространство.
Заголовки: preamble, frame delimiter, Ethernet header/FCS – 26 bytes, IFG – 12 bytes, IP header – 20 bytes, TCP header – 20 bytes.

Если исключить VLAN tagging, TCP timestamp и другие опциональные возможности, максимальная полезная нагрузка (Payload) TCP в сетях Ethernet будет:
Max TCP Payload= (MTU–TCP–IP) / (MTU+Ethernet+IFG) = (1500–40) / (1500+26+12) = 94.9 %

d) Задержка и потеря пакетов
Так как речь идет о надежной передачи информации, потеря пакетов в сети вынуждает TCP передавать повторно сегменты и влияет непосредственно на понижение скорости.
Зависимость скорости TCP в соотношении к потери пакетов, определяется формулой Mathis-а:

где: MSS (Maximum segment size) – максимальный размер сегмента TCP (MSS = MTU – packet headers=1460 bytes),
MTU — максимальный размер передаваемого блока нижнего уровня OSI (Ethernet MTU = 1500 bytes),
RTT — время двусторонней задержки (от одного конца к другому и назад, от англ. Round Trip Time)
Ploss — Loss probability (вероятность потерь).
Можно обратить внимание что формула не действительна с Ploss = 0. Это нормально, так как в реальном мире всегда есть потери пакетов.

img4 Влияние задержки и потеря пакетов на максимальную пропускную способность TCP

Большинство провайдеров не будет гарантировать потери менее 0.01% (1 пакет из 10`000).
Проверить статистику по протоколам можно командой “netstat –s”.

2) Оптимизация TCP

a) усовершенствования протокола
В связи с этим были разработаны расширения протокола, описанные в стандарте TCP Extensions for High Performance (RFC1323), которые призваны решить ограничения.
Среди них:
— TCP Window Scale Option: возможность увеличение Размера Окна до 2^30 (1 ГБайт),
— TCP selective acknowledgment (SACK) options: принимающая сторона указывает какие именно пакеты в потоке подтверждены (положительно или отрицательно) (RFC2018),
— TCP timestamps: улучшение замеров RTT (Round Trip Time Measurement — RTTM), предотвращение накладки порядковых чисел ACK (Prevention Against Wrapped Sequence numbers — PAWS),
— Path MTU discovery: определение максимального MTU на всем пути,
— Explicit Congestion Notification (ECN): указывает на перегрузку пути без сбрасывание пакетов (RFC3168).

Проверить текущие настройки TCP/IP компьютера можно здесь.

b) aдаптация oперационных систем
Несмотря на то что документ RFC1323 был опубликован в далеком 1992 году, в ОС-ы внедряли изменения не сразу.

OS Windows
Поддержка RFC1323 появилась начиная с Windows 2000 (XP, Server 2003) и для активации опции необходимо покрутить в реестре.
Системы Windows Server 2008, Vista, 7 включают новую реализацию стека протоколов TCP/IP, известную как стек протоколов TCP/IP нового поколения («Next Generation TCP/IP Stack»). Он спроектирован для того, чтобы обеспечивать сетевые технологии Windows на несколько лет вперед. Среди нововведений:
— aвтонастройка окна получения (Receive Window Auto-Tuning),
— compound TCP: решает проблему низкой производительности в сетях с высокой пропускной способностью с помощью нового алгоритма, вместо алгоритмов, использовавшихся на других платформах,
— усовершенствования для сред с высоким уровнем потерь и еще много чего.
Многие опции включены по умолчанию. Конфигурация через командную строку.

С подробными процедурами настройки для различных ОС (Windows XP, FreeBSD, Linux, Solaris, Mac OS X), можно ознакомится на сайте суперкомпьютерного центра Питтсбурга.

Примечание: Хотя через маршрутизаторы в основном проходит весь трафик (между разными сетями), отношение к оптимизации TCP имеют только косвенное (в некоторых случаях), так как работают на более нижнем уровне сетевой модели OSI и выполняют функцию определение оптимальных маршрутов и лишь доставку пакетов до назначения.

3) Измерения производительности стека TCP/IP

В сети существуют множество методов измерения скорости подключения к Интернету.
Здесь будет рассмотрен случай с использованием утилиты nuttcp («New TTCP»), так как она имеет несколько приятных преимуществ:
— простой и эффективный метод измерения пропускной способности канала через TCP или UDP,
— кроссплатформенная одно-файловая программа (CLI),
— возможность проверки эффективности локального стека TCP/IP (loopback),
— стабильная работа сервера (корректное завершения TCP сессий), без подвисаний и падений
(как в случае с iperf),
— работа клиента из NAT-а.

Немного истории: В 1980 году, Mike Muuss (автор ping-а) создал ttcp («Test TCP») — один из первых инструментов тестирования пропускной способности TCP. Многие изменения с тех пор были созданы в различных реализациях и с новыми возможностями. Nuttcp является одной из них. Последняя бета — апрель 2010.

Тестирования работает по схеме клиент-сервер.
Измеряется payload — полезная нагрузка (без заголовков).
Подключение по порту 5000. Передача данных — 5001 (и выше если указать многопоточный тест).

Пример:
Сервер FreeBSD, клиент Windows XP SP3, FastEthernet (100Mbps).
server-ip# nuttcp –S

опции клиента:
-w128 — TCP receive window size = 128 KB
-r — receiving (прием, для клиента)
-F — устраняет возможные проблемы с соединением если вы в NAT-е
-i5 — показывать результат каждые 5 секунд
-T15 — длительность тестирования (15 секунд).

TX% и RX% являются загрузкой процессора на передатчике и приемнике.

Примеры результатов:
— Intel Core 2 Duo (2 core) @ 1.6 GHz/ 1 GB RAM / Windows XP = 1300/1400 Mbps
— AMD Athlon X2 Dual-Core 4600 @ 2.4 GHz/ 2 GB RAM / Windows 7 = 2000/2100 Mbps
— Intel XEON X5650 (24 cores) @ 2.67GHz/ 8 GB RAM / FreeBSD = 16600/18000 Mbps

168.2676 MB / 15.00 sec = 94.1020 Mbps 3 %TX 10 %RX

1371.1741 MB / 15.00 sec = 766.6703 Mbps 26 %TX 39 %RX 3153 host-retrans 0.29 msRTT

167.2500 MB / 15.12 sec = 92.7664 Mbps 17 %TX 6 %RX

1305.3853 MB / 15.06 sec = 727.0077 Mbps 20 %TX 48 %RX 24478 host-retrans 0.29 msRTT

4) Вместо заключения

200 км/мс),
— дополнительные задержки могут возникнуть в момент перегрузки сети или устройства (сервер, рутер, пк),
— автоматическое понижение скорости при обнаружении потерь пакетов (стандартный механизм TCP предотвращения перегрузок),
— отсутствие других негативных эффектов (минимальное количество ошибок битов на физическом уровне (Bit Error Rate

Источник

СОДЕРЖАНИЕ

Операция

Окно перегрузки

Медленный старт

Хотя эта стратегия называется медленным запуском, ее рост окна перегрузки является довольно агрессивным, более агрессивным, чем фаза предотвращения перегрузки. До того, как в TCP был введен медленный старт, начальная фаза предотвращения перегрузки была еще быстрее.

По достижении ssthresh TCP переходит с алгоритма медленного старта на алгоритм линейного роста (предотвращение перегрузки). В этот момент окно увеличивается на 1 сегмент для каждого времени задержки приема-передачи (RTT).

Аддитивное увеличение / мультипликативное уменьшение

Это алгоритм, описанный в RFC 5681 для состояния «предотвращения перегрузки».

Быстрая ретрансляция

Когда отправитель получает три повторяющихся подтверждения, можно с достаточной степенью уверенности в том, что сегмент, несущий данные, следующие за последним упорядоченным байтом, указанным в подтверждении, был потерян. Отправитель с быстрой повторной передачей затем немедленно повторно передаст этот пакет, не дожидаясь его тайм-аута. По получении повторно переданного сегмента получатель может подтвердить последний байт полученных данных по порядку. В приведенном выше примере это подтвердит конец полезной нагрузки пятого пакета. Нет необходимости подтверждать промежуточные пакеты, поскольку TCP по умолчанию использует кумулятивные подтверждения.

Алгоритмы

Соглашение об именах для алгоритмов управления перегрузкой (CCA) могло появиться в статье 1996 года Кевина Фолла и Салли Флойд.

Ниже приводится одна из возможных классификаций по следующим свойствам:

Некоторые известные механизмы предотвращения перегрузки классифицируются по этой схеме следующим образом:

ПТС Тахо и Рино

Алгоритмы TCP Tahoe и Reno были ретроспективно названы в честь версий или разновидностей операционной системы 4.3BSD, в которой каждая из них впервые появилась (которые сами были названы в честь озера Тахо и близлежащего города Рино, штат Невада ). Алгоритм Tahoe впервые появился в 4.3BSD-Tahoe (который был создан для поддержки миникомпьютера CCI Power 6/32 «Tahoe» ), а позже стал доступным для лицензиатов, не имеющих лицензии AT&T, как часть 4.3BSD Networking Release 1; это обеспечило его широкое распространение и внедрение. Улучшения были внесены в 4.3BSD-Reno и впоследствии опубликованы как Networking Release 2 и более поздняя версия 4.4BSD-Lite.

Хотя оба считают тайм-аут повторной передачи (RTO) и дублирующиеся ACK как события потери пакетов, поведение Tahoe и Reno различается в первую очередь тем, как они реагируют на дублирующиеся ACK:

Как в Tahoe, так и в Reno, если время ожидания ACK истекло (время ожидания RTO), используется медленный запуск, и оба алгоритма сокращают окно перегрузки до 1 MSS.

TCP Vegas

TCP Vegas не получил широкого распространения за пределами лаборатории Петерсона, но был выбран в качестве метода контроля перегрузки по умолчанию для прошивки DD-WRT v24 SP2.

TCP Нью-Рино

TCP New Reno, определенный в RFC 6582 (который устарел предыдущие определения в RFC 3782 и RFC 2582 ), улучшает повторную передачу во время фазы быстрого восстановления TCP Reno. Во время быстрого восстановления, чтобы окно передачи оставалось полным, для каждого возвращаемого дублирующего ACK отправляется новый неотправленный пакет с конца окна перегрузки. Для каждого ACK, который частично продвигается в пространстве последовательности, отправитель предполагает, что ACK указывает на новую дыру, и отправляется следующий пакет после ACKed порядкового номера.

Проблема возникает с New Reno, когда нет потери пакетов, но вместо этого пакеты переупорядочиваются более чем с 3 порядковыми номерами пакетов. В этом случае New Reno по ошибке входит в быстрое восстановление. Когда переупорядоченный пакет доставляется, происходит прогрессирование порядкового номера ACK, и с этого момента до конца быстрого восстановления, весь прогресс порядкового номера создает дублирующую и ненужную повторную передачу, которая немедленно подтверждается.

New Reno работает так же хорошо, как SACK при низкой частоте ошибок пакетов и существенно превосходит Reno при высокой частоте ошибок.

TCP Hybla

TCP Hybla направлена ​​на устранение штрафов за TCP-соединения, которые включают наземные или спутниковые радиоканалы с высокой задержкой. Усовершенствования Hybla основаны на аналитической оценке динамики окна перегрузки.

TCP BIC

TCP CUBIC

Agile-SD TCP

TCP Westwood +

Составной TCP

Пропорциональное снижение скорости TCP

TCP BBR

Сохейл Аббаслоо и др. (авторы C2TCP) показывают, что BBRv1 плохо работает в динамических средах, таких как сотовые сети. Они также показали, что у BBR есть проблема несправедливости. Например, когда поток CUBIC (который является реализацией TCP по умолчанию в Linux, Android и MacOS) сосуществует с потоком BBR в сети, поток BBR может доминировать над потоком CUBIC и получать от него всю полосу пропускания канала (см. Рисунок 16 дюймов).

C2TCP

Исследователи из Нью-Йоркского университета показали, что C2TCP превосходит по показателям задержки и ее вариации различные современные схемы TCP. Например, они показали, что по сравнению с BBR, CUBIC и Westwood в среднем, C2TCP снижает среднюю задержку пакетов примерно на 250%, 900% и 700% соответственно в различных средах сотовой сети.

Эластичный TCP

Elastic-TCP был предложен в феврале 2019 года для увеличения использования полосы пропускания в сетях с высоким BDP для поддержки облачных вычислений. Это CCA на базе Linux, разработанная для ядра Linux. Это алгоритм на стороне приемника, который использует подход, основанный на потерях и задержках, с использованием нового механизма, называемого взвешивающей функцией с оконной корреляцией (WWF). Он имеет высокий уровень эластичности, позволяющий работать с различными сетевыми характеристиками без необходимости ручной настройки. Он был оценен путем сравнения его производительности с Compound TCP (CCA по умолчанию в MS Windows), CUBIC (по умолчанию для Linux) и TCP-BBR (по умолчанию в Linux 4.9, используемом Google) с использованием симулятора NS-2 и испытательного стенда. Elastic-TCP значительно улучшает общую производительность с точки зрения средней пропускной способности, коэффициента потерь и задержки.

NATCP

Другие алгоритмы предотвращения перегрузки TCP

Когда произведение пропускной способности и задержки на поток увеличивается, независимо от схемы организации очереди, TCP становится неэффективным и склонным к нестабильности. Это становится все более важным, поскольку Интернет развивается и включает оптические каналы с очень высокой пропускной способностью.

TCP Interactive (iTCP) позволяет приложениям подписываться на события TCP и соответствующим образом реагировать, обеспечивая различные функциональные расширения TCP извне уровня TCP. Большинство схем перегрузки TCP работают внутренне. iTCP дополнительно позволяет расширенным приложениям напрямую участвовать в управлении перегрузкой, например, управлять скоростью генерации источника.

Классификация по осведомленности о сети

CCA классифицируются в зависимости от осведомленности о сети, то есть степени, в которой эти алгоритмы осведомлены о состоянии сети, и состоят из трех основных категорий: черный ящик, серый ящик и зеленый ящик.

Алгоритмы черного ящика предлагают слепые методы контроля перегрузки. Они оперируют только двоичной обратной связью, полученной при перегрузке, и не предполагают никаких сведений о состоянии сетей, которыми они управляют.

Алгоритмы серого ящика используют экземпляры времени для получения измерений и оценок полосы пропускания, конкуренции потоков и других сведений о сетевых условиях.

Алгоритмы зеленого ящика предлагают бимодальные методы контроля перегрузки, которые измеряют справедливую долю общей полосы пропускания, которая должна быть выделена для каждого потока в любой момент во время работы системы.

Черный ящик

Серая коробка

Зеленая коробка

Следующие алгоритмы требуют добавления настраиваемых полей в структуру пакета TCP:

Источник