Перегрузка сети

Перегрузка сети в теории сетей передачи данных и теории очередей — это снижение качества обслуживания , которое возникает, когда сетевой узел или канал передает больше данных, чем он может обработать. Типичные последствия включают задержку в очереди , потерю пакетов или блокировку новых соединений. Следствием перегрузки является то, что постепенное увеличение предлагаемой нагрузки приводит либо лишь к небольшому увеличению, либо даже к снижению пропускной способности сети . ^{[ 1 ]}

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

Сети используют методы контроля и предотвращения перегрузок, чтобы избежать коллапса. К ним относятся: экспоненциальная отсрочка в таких протоколах, как CSMA/CA в 802.11 и аналогичный CSMA/CD в исходном Ethernet , уменьшение окна в TCP и справедливая организация очередей в таких устройствах, как маршрутизаторы и сетевые коммутаторы . Другие методы решения проблемы перегрузки включают схемы приоритетов, которые передают некоторые пакеты с более высоким приоритетом раньше других, а также явное распределение сетевых ресурсов по конкретным потокам посредством использования контроля доступа .

Емкость сети

Сетевые ресурсы ограничены, включая время обработки маршрутизатора и пропускную способность канала . Конфликт за ресурсы может возникнуть в сетях в нескольких распространенных случаях. Беспроводную локальную сеть легко заполнить одним персональным компьютером. ^{[ 2 ]} Даже в быстрых компьютерных сетях магистраль может быть легко перегружена несколькими серверами и клиентскими компьютерами. Атаки типа «отказ в обслуживании» с помощью ботнетов способны заполнить даже самые крупные каналы магистральной сети Интернет , создавая крупномасштабную перегрузку сети. В телефонных сетях событие массового вызова может привести к перегрузке цифровых телефонных каналов, что иначе можно определить как атаку типа «отказ в обслуживании» .

Застойный коллапс

Застойный коллапс (или коллапс перегрузки) — это состояние, при котором застой препятствует или ограничивает полезное общение. Коллапс перегрузки обычно происходит в узких точках сети, где входящий трафик превышает пропускную способность исходящей сети. Точки соединения между локальной сетью и глобальной сетью являются распространенными узкими местами. Когда сеть находится в таком состоянии, она переходит в стабильное состояние, в котором потребность в трафике высока, но полезная пропускная способность мала, при этом пакетов происходят задержки и потери , а качество обслуживания крайне низкое.

К 1984 году застойный коллапс был идентифицирован как возможная проблема. ^{[ 3 ]} Впервые это было замечено в раннем Интернете в октябре 1986 года. ^{[ 4 ]} когда пропускная способность магистральной сети NSFNET фазы I упала на три порядка с 32 кбит/с до 40 бит/с, ^{[ 5 ]} Это продолжалось до тех пор, пока конечные узлы не начали внедрять Ван Джейкобсона и Салли Флойд в период с 1987 по 1988 год. систему контроля перегрузки ^{[ 6 ]} Когда было отправлено больше пакетов , чем могли обработать промежуточные маршрутизаторы, промежуточные маршрутизаторы отбрасывали многие пакеты, ожидая, что конечные точки сети повторно передадут информацию. Однако ранние реализации TCP имели плохое поведение при повторной передаче. Когда произошла потеря пакета, конечные точки отправили дополнительные пакеты, которые повторяли потерянную информацию, удваивая скорость входящего трафика.

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

Контроль перегрузки модулирует вход трафика в телекоммуникационную сеть, чтобы избежать коллапса перегрузки, возникающего в результате переподписки. ^{[ 7 ]} Обычно это достигается за счет снижения скорости передачи пакетов. В то время как контроль перегрузки не позволяет отправителям перегружать сеть , контроль потока не позволяет отправителю перегружать получателя .

Теория контроля перегрузок

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

Позволять $x_{i}$ быть скоростью потока $i$ , $c_{l}$ быть емкостью ссылки $l$ , и $r_{li}$ быть 1, если поток $i$ использует ссылку $l$ и 0 в противном случае. Позволять $x$ , $c$ и $R$ — соответствующие векторы и матрица. Позволять $U(x)$ быть возрастающей, строго вогнутой функцией , называемой полезностью , которая измеряет, какую выгоду получает пользователь от передачи со скоростью $x$ . Оптимальное распределение ставок тогда удовлетворяет

\max \limits _{x}\sum _{i}U(x_{i})

такой, что

Rx\leq c

Двойник Лагранжа этой проблемы отделяется так, что каждый поток устанавливает свою собственную скорость, основанную только на цене, сообщаемой сетью. Пропускная способность каждого канала накладывает ограничение, которое приводит к множителю Лагранжа : $p_{l}$ . Сумма этих множителей, $y_{i}=\sum _{l}p_{l}r_{li},$ цена, на которую реагирует поток.

Тогда контроль перегрузки становится алгоритмом распределенной оптимизации. Многие современные алгоритмы управления перегрузкой могут быть смоделированы в этой структуре. $p_{l}$ это либо вероятность потери, либо задержка очереди на канале $l$ . Основным недостатком является то, что он назначает одну и ту же цену всем потокам, в то время как управление потоком со скользящим окном вызывает пульсацию , из-за которой разные потоки наблюдают разные потери или задержки на данном канале.

Классификация алгоритмов контроля перегрузок

Среди способов классификации алгоритмов контроля перегрузок можно выделить:

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

смягчение последствий

Были изобретены механизмы для предотвращения перегрузки сети или борьбы с ее сбоем:

Сетевой планировщик – активное управление очередью , которое изменяет порядок или выборочно отбрасывает сетевые пакеты в случае перегрузки.
Явное уведомление о перегрузке — расширение протоколов связи IP и TCP, добавляющее механизм управления потоком.
Контроль перегрузки TCP — различные реализации мер по борьбе с перегрузкой сети.

Правильное поведение конечной точки обычно заключается в повторении пропущенной информации, но постепенном замедлении частоты повторения. Если все конечные точки сделают это, перегрузка исчезнет, и сеть возобновит нормальное поведение. ^{[ нужна ссылка ]} Другие стратегии, такие как медленный запуск , гарантируют, что новые соединения не перегрузят маршрутизатор до того, как начнется обнаружение перегрузки.

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

Некоторые сквозные протоколы разработаны таким образом, чтобы хорошо работать в условиях перегрузки; TCP — хорошо известный пример. Первые реализации TCP для обработки перегрузок были описаны в 1984 году. ^{[ 8 ]} но включение Ван Джейкобсоном решения с открытым исходным кодом в стандартный дистрибутив UNIX Беркли (« BSD ») в 1988 году впервые обеспечило хорошее поведение.

UDP не контролирует перегрузку. Протоколы, построенные на основе UDP, должны самостоятельно справляться с перегрузками. Протоколы, передающие данные с фиксированной скоростью, независимо от перегрузки, могут быть проблематичными. Этим свойством обладают протоколы потоковой передачи в реальном времени, включая многие протоколы передачи голоса по IP . Таким образом, необходимо принять специальные меры, такие как качество обслуживания, чтобы предотвратить потерю пакетов в случае перегрузки.

Практическое предотвращение перегрузки сети

Протоколы, ориентированные на соединение , такие как широко используемый протокол TCP , отслеживают потерю пакетов или задержку в очереди, чтобы регулировать скорость передачи. Различные процессы предотвращения перегрузки сети поддерживают разные компромиссы. ^{[ 9 ]}

Предотвращение перегрузок TCP/IP

Алгоритм предотвращения перегрузки TCP является основной основой управления перегрузкой в Интернете. ^{[ 10 ]}^{[ 11 ]}^{[ 12 ]}^{[ 13 ]}^{[ 14 ]}

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

Активное управление очередью

Активное управление очередями (AQM) — это изменение порядка или удаление сетевых пакетов внутри буфера передачи, который связан с контроллером сетевого интерфейса (NIC). Эту задачу выполняет сетевой планировщик .

Случайное раннее обнаружение

Одним из решений является использование случайного раннего обнаружения (RED) в выходной очереди сетевого оборудования. ^{[ 15 ]}^{[ 16 ]} На сетевых аппаратных портах с более чем одной выходной очередью взвешенное случайное раннее обнаружение можно использовать (WRED).

RED косвенно сигнализирует отправителю и получателю TCP, отбрасывая некоторые пакеты, например, когда средняя длина очереди превышает пороговое значение (например, 50%), и удаляет линейно или кубически больше пакетов. ^{[ 17 ]} до, например, 100% по мере дальнейшего заполнения очереди.

Надежное случайное раннее обнаружение

Надежный алгоритм случайного раннего обнаружения (RRED) был предложен для улучшения пропускной способности TCP против атак типа «отказ в обслуживании» (DoS), особенно низкочастотных атак типа «отказ в обслуживании» (LDoS). Эксперименты подтвердили, что алгоритмы, подобные RED, уязвимы для атак LDoS из-за колеблющегося размера очереди TCP, вызванного атаками. ^{[ 18 ]}

WRED на основе потока

Некоторое сетевое оборудование оснащено портами, которые могут отслеживать и измерять каждый поток и, таким образом, способны сигнализировать о слишком большом потоке полосы пропускания в соответствии с некоторой политикой качества обслуживания. Затем политика может разделить пропускную способность между всеми потоками по некоторым критериям. ^{[ 19 ]}

Явное уведомление о перегрузке

Другой подход — использовать явное уведомление о перегрузке (ECN). ^{[ 20 ]} ECN используется только тогда, когда два хоста сигнализируют о своем желании его использовать. В этом методе бит протокола используется для сигнализации явной перегрузки. Это лучше, чем косвенное уведомление о перегрузке, сигнализируемое потерей пакетов алгоритмами RED/WRED, но требует поддержки со стороны обоих хостов. ^{[ 21 ]}^{[ 15 ]}

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

формирование окна TCP

Избежания заторов можно эффективно достичь за счет сокращения трафика. Когда приложение запрашивает большой файл, изображение или веб-страницу, оно обычно объявляет окно размером от 32 КБ до 64 КБ. В результате сервер отправляет полное окно данных (при условии, что файл больше окна). Когда множество приложений одновременно запрашивают загрузку, эти данные могут создать точку перегрузки у вышестоящего провайдера. Уменьшая количество оконной рекламы, удаленные серверы отправляют меньше данных, тем самым уменьшая перегрузку. ^{[ 22 ]}^{[ 23 ]}

Обратный ECN

Обратный ECN (BECN) — еще один предложенный механизм уведомления о перегрузках. Он использует сообщения подавления источника ICMP в качестве механизма IP-сигнализации для реализации базового механизма ECN для IP-сетей, сохраняя уведомления о перегрузке на уровне IP и не требуя согласования между конечными точками сети. Эффективные уведомления о перегрузке могут быть переданы протоколам транспортного уровня, таким как TCP и UDP, для соответствующих корректировок. ^{[ 24 ]}

Побочные эффекты предотвращения застойного коллапса

Радиосвязь

Протоколы, которые избегают перегрузки, обычно предполагают, что потеря данных вызвана перегрузкой. В проводных сетях ошибки при передаче случаются редко. Wi-Fi , 3G и другие сети с радиоуровнем подвержены потере данных из-за помех и в некоторых случаях могут иметь низкую пропускную способность. на основе радиосвязи, TCP-соединения, работающие на физическом уровне видят потерю данных и склонны ошибочно полагать, что происходит перегрузка.

Кратковременные связи

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

Входной контроль

Контроль доступа — это любая система, которая требует, чтобы устройства получали разрешение перед установкой новых сетевых подключений. Если новое соединение рискует создать перегрузку, в разрешении может быть отказано. Примеры включают возможности передачи без конфликтов (CFTXOP) в стандарте ITU-T G.hn для домашних сетей по устаревшей проводке, протокол резервирования ресурсов для IP-сетей и протокол резервирования потока для Ethernet .

См. также

Управление пропускной способностью – контроль пропускной способности сети связи.
Каскадный сбой – системный риск сбоя
Дроссельная станция - телефонная станция, предназначенная для обработки множества одновременных попыток вызова.
Эрланг (единица измерения) – мера нагрузки в телекоммуникациях
Синдром ученика чародея - ошибка сетевого протокола в исходных версиях TFTP.
Проектирование телетрафика - Применение теории организации трафика к телекоммуникациям.
Перетряска – постоянный обмен между памятью и хранилищем.
Формирование трафика - метод управления полосой пропускания связи.
Надежность (компьютерные сети) – возможность подтверждения протокола.

Ссылки

^ (Аль-Бахадили, 2012, стр. 282) Аль-Бахадили, Х. (2012). Моделирование в проектировании и моделировании компьютерных сетей: Использование и анализ . Херши, Пенсильвания: IGI Global.
^ ден Хартог Ф., Рашельла А., Буафс Ф., Кемпкер П., Болтьес Б. и Сейдебрахими М. (ноябрь 2017 г.). Путь к решению проблемы Wi-Fi в многоквартирных домах . В 2017 году 27-я Международная конференция по телекоммуникационным сетям и приложениям (ITNAC) (стр. 1-6). IEEE.
^ RFC 896
^ Фолл, КР; Стивенс, WR (2011). TCP/IP Illustrated, Том 1: Протоколы (2-е изд.). Пирсон Образование. п. 739. ИСБН 9780132808187 .
^ Ван Джейкобсон; Майкл Дж. Карелс (ноябрь 1988 г.), «Избежание и контроль перегрузок» (PDF) , В октябре 1986 года в Интернете произошел первый из того, что впоследствии стало серией «крахов перегрузки». За этот период пропускная способность данных от LBL до Калифорнийского университета в Беркли (сайты, разделенные 400 ярдами и двумя переходами IMP) упала с 32 Кбит/с до 40 бит/с. Мы были очарованы этим внезапным тысячекратным падением пропускной способности и приступили к расследованию того, почему дела пошли так плохо. В частности, мы задавались вопросом, ведет ли себя неправильно TCP 4.3BSD(Berkeley UNIX) или его можно настроить для лучшей работы в ужасных сетевых условиях. Ответ на оба этих вопроса был «да».
^ Хафнер, Кэти (4 сентября 2019 г.). «Салли Флойд, которая помогла интернету работать гладко, умерла в возрасте 69 лет» . Нью-Йорк Таймс . Проверено 5 сентября 2019 г.
^ Нанда, Приядарши (1 ноября 2000 г.). «Подход теории управления к управлению перегрузкой во внутренней сети» . Тома трудов МФБ . 16-й семинар IFAC по распределенным компьютерным системам управления (DCCS 2000), Сидней, Австралия, 29 ноября – 1 декабря 2000 г. 33 (30): 91–94. дои : 10.1016/S1474-6670(17)36735-6 . ISSN 1474-6670 .
^ Винтон Дж. Серф; Роберт Э. Кан (май 1974 г.). «Протокол пакетной сетевой связи» (PDF) . Транзакции IEEE в области коммуникаций . 22 (5): 637–648. дои : 10.1109/tcom.1974.1092259 . Архивировано из оригинала (PDF) 4 марта 2016 г.
^ Ли, БП; Балан, РК; Джейкоб, Л.; Сей, WKG; Ананда, Ал. (2000), «Туннели TCP: предотвращение коллапса перегрузки», Материалы 25-й ежегодной конференции IEEE по локальным компьютерным сетям. LCN 2000 , стр. 408–417, номер doi : 10.1109/LCN.2000.891077 , ISBN. 0-7695-0912-6 , S2CID 34447400
^ Ван Джейкобсон , Майкл Дж. Карелс . Предотвращение перегрузок и контроль (1988). Труды симпозиума Sigcomm '88 , том 18 (4): стр. 314–329. Стэнфорд, Калифорния. Август 1988 г. В этой статье были описаны многие алгоритмы предотвращения перегрузок, используемые в TCP/IP.
^ RFC 2001 - Алгоритмы медленного запуска TCP, предотвращения перегрузки, быстрой повторной передачи и быстрого восстановления
^ RFC 2581 - Контроль перегрузки TCP
^ RFC 3390 - TCP, увеличивающий начальное окно TCP
^ Предотвращение перегрузки TCP, объясненное с помощью диаграммы последовательности
^ Перейти обратно: ^а ^б Салли Флойд: RED (случайное раннее обнаружение) Управление очередью
^ Салли Флойд, Ван Джейкобсон. Случайные шлюзы раннего обнаружения для предотвращения перегрузок (1993). Транзакции IEEE/ACM в сети , том 1(4): стр. 397–413. Изобретены шлюзы случайного раннего обнаружения (RED).
^ Аналитическая конструкция функции RED, гарантирующая стабильное поведение системы , CiteSeerX 10.1.1.105.5995 , ...Преимущество этой функции заключается не только в предотвращении сильных колебаний, но и в предотвращении недостаточного использования канала при низких нагрузках. Применимость производной функции не зависит от диапазона нагрузки, никакие параметры не подлежат корректировке. По сравнению с исходной функцией линейного падения применимость значительно расширена... Наш пример с реалистичными параметрами системы дает аппроксимирующую функцию кубического размера очереди...
^ Чжан, Чанван; Инь, Цзяньпин; Цай, Чжипин; Чен, Вэйфэн (2010). «RRED: надежный алгоритм RED для противодействия низкочастотным атакам типа «отказ в обслуживании» (PDF) . Коммуникационные письма IEEE . 14 (5). IEEE : 489–491. дои : 10.1109/LCOMM.2010.05.091407 . S2CID 1121461 .
^ «Обзор предотвращения перегрузок» . Сиско Системы . Проверено 7 августа 2020 г.
^ RFC 3168 - Добавление явного уведомления о перегрузке (ECN) в IP
^ Сравнительное исследование RED, ECN и TCP Rate Control (1999)
^ Обобщенная реклама в окне TCP CongestionControl (PDF) , получено 13 ноября 2020 г.
^ Поп, О.; Молдован, И.; Саймон, CS .; Биро, Дж.; Койке, А.; Исии, Х. (2000), «Рекламируемое управление потоками TCP на основе окон в маршрутизаторах», Telecommunication Network Intelligence , стр. 197–218, doi : 10.1007/978-0-387-35522-1_12 , ISBN 978-1-4757-6693-6
^ Предложение по обратному ECN для интернет-протокола.

Джон Эванс; Кларенс Филсфилс (2007). Развертывание QoS IP и MPLS для мультисервисных сетей: теория и практика . Морган Кауфманн. ISBN 978-0-12-370549-5 .
Салли Флойд (сентябрь 2000 г.). Принципы контроля перегрузок . РФК 2914 .
Джон Нэгл (6 января 1984 г.). Контроль перегрузки в IP/TCP . РФК 896 .
Ван Джейкобсон; Майкл Дж. Карелс (ноябрь 1988 г.). «Предотвращение и контроль перегрузок» (PDF) .

Внешние ссылки

Флойд С. и К. Фолл, Продвижение использования сквозного контроля перегрузки в Интернете (транзакции IEEE/ACM в сети, август 1999 г.)
Салли Флойд, Об эволюции сквозного контроля перегрузки в Интернете: своеобразный взгляд (Семинар IMA по явлениям масштабирования в сетях связи, октябрь 1999 г.) ( pdf формат )
Связывающий термин: Очередь. Архивировано 8 марта 2003 г. в Wayback Machine.
Пьер-Франсуа Ке, Шрирам Челлаппан, Аржан Дурреси, Мукундан Шридхаран, Хитай Озбай, Радж Джейн, «Руководство по оптимизации многоуровневой ECN с использованием модели TCP на основе потоков жидкости».
Салли Флойд, Ратул Махаджан, Дэвид Уэтералл: RED-PD: RED с льготным удалением. Архивировано 2 апреля 2003 г. на Wayback Machine.
Универсальный простой симулятор RED для образовательных целей, автор Мехмет Сюзен.
Подходы к контролю перегрузки в пакетных сетях
Документы по контролю перегрузок
Случайная домашняя страница раннего обнаружения
Домашняя страница явного уведомления о перегрузке
Домашняя страница TFRC
Домашняя страница AIMD-FC
Недавние публикации о низкочастотных атаках типа «отказ в обслуживании» (DoS)

[1] (Аль-Бахадили, 2012, стр. 282) Аль-Бахадили, Х. (2012). Моделирование в проектировании и моделировании компьютерных сетей: Использование и анализ . Херши, Пенсильвания: IGI Global.

[2] ден Хартог Ф., Рашельла А., Буафс Ф., Кемпкер П., Болтьес Б. и Сейдебрахими М. (ноябрь 2017 г.). Путь к решению проблемы Wi-Fi в многоквартирных домах . В 2017 году 27-я Международная конференция по телекоммуникационным сетям и приложениям (ITNAC) (стр. 1-6). IEEE.

[3] RFC 896

[4] Фолл, КР; Стивенс, WR (2011). TCP/IP Illustrated, Том 1: Протоколы (2-е изд.). Пирсон Образование. п. 739. ИСБН 9780132808187 .

[5] Ван Джейкобсон; Майкл Дж. Карелс (ноябрь 1988 г.), «Избежание и контроль перегрузок» (PDF) , В октябре 1986 года в Интернете произошел первый из того, что впоследствии стало серией «крахов перегрузки». За этот период пропускная способность данных от LBL до Калифорнийского университета в Беркли (сайты, разделенные 400 ярдами и двумя переходами IMP) упала с 32 Кбит/с до 40 бит/с. Мы были очарованы этим внезапным тысячекратным падением пропускной способности и приступили к расследованию того, почему дела пошли так плохо. В частности, мы задавались вопросом, ведет ли себя неправильно TCP 4.3BSD(Berkeley UNIX) или его можно настроить для лучшей работы в ужасных сетевых условиях. Ответ на оба этих вопроса был «да».

[6] Хафнер, Кэти (4 сентября 2019 г.). «Салли Флойд, которая помогла интернету работать гладко, умерла в возрасте 69 лет» . Нью-Йорк Таймс . Проверено 5 сентября 2019 г.

[7] Нанда, Приядарши (1 ноября 2000 г.). «Подход теории управления к управлению перегрузкой во внутренней сети» . Тома трудов МФБ . 16-й семинар IFAC по распределенным компьютерным системам управления (DCCS 2000), Сидней, Австралия, 29 ноября – 1 декабря 2000 г. 33 (30): 91–94. дои : 10.1016/S1474-6670(17)36735-6 . ISSN 1474-6670 .

[8] Винтон Дж. Серф; Роберт Э. Кан (май 1974 г.). «Протокол пакетной сетевой связи» (PDF) . Транзакции IEEE в области коммуникаций . 22 (5): 637–648. дои : 10.1109/tcom.1974.1092259 . Архивировано из оригинала (PDF) 4 марта 2016 г.

[9] Ли, БП; Балан, РК; Джейкоб, Л.; Сей, WKG; Ананда, Ал. (2000), «Туннели TCP: предотвращение коллапса перегрузки», Материалы 25-й ежегодной конференции IEEE по локальным компьютерным сетям. LCN 2000 , стр. 408–417, номер doi : 10.1109/LCN.2000.891077 , ISBN. 0-7695-0912-6 , S2CID 34447400

[10] Ван Джейкобсон , Майкл Дж. Карелс . Предотвращение перегрузок и контроль (1988). Труды симпозиума Sigcomm '88 , том 18 (4): стр. 314–329. Стэнфорд, Калифорния. Август 1988 г. В этой статье были описаны многие алгоритмы предотвращения перегрузок, используемые в TCP/IP.

[11] RFC 2001 - Алгоритмы медленного запуска TCP, предотвращения перегрузки, быстрой повторной передачи и быстрого восстановления

[12] RFC 2581 - Контроль перегрузки TCP

[13] RFC 3390 - TCP, увеличивающий начальное окно TCP

[14] Предотвращение перегрузки TCP, объясненное с помощью диаграммы последовательности

[FloydRED-15] Перейти обратно: ^а ^б Салли Флойд: RED (случайное раннее обнаружение) Управление очередью

[16] Салли Флойд, Ван Джейкобсон. Случайные шлюзы раннего обнаружения для предотвращения перегрузок (1993). Транзакции IEEE/ACM в сети , том 1(4): стр. 397–413. Изобретены шлюзы случайного раннего обнаружения (RED).

[17] Аналитическая конструкция функции RED, гарантирующая стабильное поведение системы , CiteSeerX 10.1.1.105.5995 , ...Преимущество этой функции заключается не только в предотвращении сильных колебаний, но и в предотвращении недостаточного использования канала при низких нагрузках. Применимость производной функции не зависит от диапазона нагрузки, никакие параметры не подлежат корректировке. По сравнению с исходной функцией линейного падения применимость значительно расширена... Наш пример с реалистичными параметрами системы дает аппроксимирующую функцию кубического размера очереди...

[RRED-18] Чжан, Чанван; Инь, Цзяньпин; Цай, Чжипин; Чен, Вэйфэн (2010). «RRED: надежный алгоритм RED для противодействия низкочастотным атакам типа «отказ в обслуживании» (PDF) . Коммуникационные письма IEEE . 14 (5). IEEE : 489–491. дои : 10.1109/LCOMM.2010.05.091407 . S2CID 1121461 .

[19] «Обзор предотвращения перегрузок» . Сиско Системы . Проверено 7 августа 2020 г.

[20] RFC 3168 - Добавление явного уведомления о перегрузке (ECN) в IP

[21] Сравнительное исследование RED, ECN и TCP Rate Control (1999)

[22] Обобщенная реклама в окне TCP CongestionControl (PDF) , получено 13 ноября 2020 г.

[23] Поп, О.; Молдован, И.; Саймон, CS .; Биро, Дж.; Койке, А.; Исии, Х. (2000), «Рекламируемое управление потоками TCP на основе окон в маршрутизаторах», Telecommunication Network Intelligence , стр. 197–218, doi : 10.1007/978-0-387-35522-1_12 , ISBN 978-1-4757-6693-6

[24] Предложение по обратному ECN для интернет-протокола.

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]

[ 15 ]

[ 16 ]

[ 17 ]

[ 18 ]

[ 19 ]

[ 20 ]

[ 21 ]

[ 22 ]

[ 23 ]

[ 24 ]