stringtranslate.com

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

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

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

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

Емкость сети

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

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

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

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

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

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

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

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

Пусть будет скорость потока , будет пропускная способность канала и будет 1, если поток использует канал , и 0 в противном случае. Пусть , и – соответствующие векторы и матрица. Пусть — возрастающая, строго вогнутая функция , называемая полезностью , которая измеряет, какую выгоду получает пользователь от передачи со скоростью . Оптимальное распределение ставок тогда удовлетворяет

такой, что

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

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

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

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

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

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

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

Общие механизмы предотвращения перегрузки маршрутизатора включают справедливую организацию очередей и другие алгоритмы планирования , а также случайное раннее обнаружение (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 .

Смотрите также

Рекомендации

  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. ^ Ли, BP; Балан, РК; Джейкоб, Л.; Сей, WKG; Ананда, Ал. (2000), «Туннели TCP: предотвращение коллапса перегрузки», Материалы 25-й ежегодной конференции IEEE по локальным компьютерным сетям. LCN 2000 , стр. 408–417, номер документа : 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, объясненное с помощью диаграммы последовательности
  15. ^ ab Салли Флойд: RED (Случайное раннее обнаружение) Управление очередью
  16. ^ Салли Флойд, Ван Джейкобсон. Случайные шлюзы раннего обнаружения для предотвращения перегрузок (1993). Транзакции IEEE/ACM в сети , том 1(4): стр. 397–413. Изобретены шлюзы случайного раннего обнаружения (RED).
  17. ^ Аналитическая конструкция функции RED, гарантирующая стабильное поведение системы , CiteSeerX 10.1.1.105.5995 , ... Преимущество этой функции заключается не только в предотвращении сильных колебаний, но и в предотвращении недостаточного использования канала при низких нагрузках. Применимость производной функции не зависит от диапазона нагрузки, никакие параметры не подлежат корректировке. По сравнению с исходной функцией линейного падения применимость значительно расширена... Наш пример с реалистичными параметрами системы дает аппроксимирующую функцию кубического размера очереди... 
  18. ^ Чжан, Чанван; Инь, Цзяньпин; Цай, Чжипин; Чен, Вэйфэн (2010). «RRED: надежный алгоритм RED для противодействия низкочастотным атакам типа «отказ в обслуживании» (PDF) . Коммуникационные письма IEEE . ИИЭЭ . 14 (5): 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 для интернет-протокола.

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