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

Перегрузка сети (англ. network congestion) в контексте компьютерных сетей и теории массового обслуживания — снижение качества обслуживания при превышении нагрузки в сетевом узле или на канале связи сверх их пропускной способности. Обычными следствиями перегрузки являются задержка в очереди, потеря пакетов или невозможность установления новых соединений. В результате перегрузки даже небольшое увеличение поступающей нагрузки приводит лишь к незначительному росту или даже снижению пропускной способности сети[1].

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

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

Пропускная способность сети

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

Коллапс из-за перегрузки

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

Возможность коллапса из-за перегрузки была отмечена уже в 1984 году. Впервые такое состояние наблюдалось в Интернете в октябре 1986 года[3], когда пропускная способность NSFNET фазы I упала в 1000 раз — с 32 кбит/с до 40 бит/с[4], и нормализовалась только после внедрения механизмов управления перегрузкой Вана Джейкобсона (англ. Van Jacobson) и Салли Флойд (англ. Sally Floyd) в 1987—1988 годах[5]. Промежуточные маршрутизаторы сбрасывали большое количество пакетов, рассчитывая на повторную передачу с конечных узлов, однако ранние реализации TCP неэффективно справлялись с повторной отправкой, в результате чего в сеть дополнительно поступал избыточный трафик.

Управление перегрузкой

Управление перегрузкой (англ. congestion control) регулирует пропуск трафика в телекоммуникационную сеть, предотвращая коллапс при превышении допустимой нагрузки[6]. Обычно это достигается снижением темпа передачи пакетов. Управление перегрузкой предотвращает чрезмерную нагрузку именно на сеть, а управление потоком — на приёмник.

Теория управления перегрузкой

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

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

при условии

Двойственная задача Лагранжа раскладывается так, чтобы каждый поток мог определить свою скорость, основываясь лишь на цене — суммарной нагрузке на сети, определяемой множителями Лагранжа ; итоговая цена для потока — .

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

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

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

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

Смягчение перегрузки

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

  • Планировщик сети и активное управление очередью — сортировка и избирательное удаление пакетов при перегрузке.
  • Явное уведомление о перегрузке (ECN) — расширение протоколов IP и TCP, добавляющее механизм управления потоком.
  • Управление перегрузкой TCP — разные реализации борьбы с перегрузкой.

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

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

Некоторые протоколы конца-конца учитывают перегрузку: примером служит TCP. Первые решения по TCP для контроля перегрузки описаны ещё в 1984 году[7], однако повсеместную эффективность обеспечила версия Вана Джейкобсона для UNIX BSD в 1988 году.

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

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

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

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

Алгоритм управления перегрузкой TCP лежит в основе борьбы с перегрузкой в Интернете[8][9][10][11][12]. Проблемы возникают при одновременных потоках, когда сброс «по хвосту» в условиях избыточных буферов вызывает задержку потерь, приводя к глобальной синхронизации TCP.

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

Активное управление очередью (AQM) — перестановка или удаление пакетов в исходящем буфере сетевого интерфейса под управлением планировщика.

Случайное раннее обнаружение перегрузки (RED)

Одним из решений является случайное раннее обнаружение (RED) на выходной очереди[13][14]. На оборудовании с несколькими выходными очередями используется взвешенное RED.

RED даёт косвенные сигналы TCP, удаляя часть пакетов — например, при переполнении очереди выше определённого порога (50 %), выполняя удаление по линейному либо кубическому закону[15].

RRED (Robust RED)

Устойчивое случайное раннее обнаружение (англ. robust random early detection, RRED) предназначено для увеличения пропускной способности TCP при LDoS-атаках. Эксперименты показывают уязвимость RED-подобных алгоритмов в таких условиях из-за периодического роста и падения очередей[16].

Flow-based WRED

Некоторые сетевые устройства позволяют измерять каждый поток и сигнализировать о превышении лимита, что даёт возможность раздельного распределения полосы пропускания по определённым критериям[17].

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

Ещё один подход — использование ECN (англ. Explicit Congestion Notification)[18]. ECN применяется, если оба хоста согласовали его поддержку. При этом бит протокола служит явным сигналом перегрузки, что предпочтительнее неявного, реализуемого через потерю пакетов в RED/WRED, но требует поддержки на обоих концах[19][13].

При получении ECN-отмеченного пакета и наличии угрозы перегрузки маршрутизатор устанавливает ECN-флаг, уведомляя отправителя, который, соответственно, уменьшает скорость передачи (например, снижая размер окна TCP).

Протокол L4S является модификацией ECN и допускает совместное управление перегрузкой между отправителем и сетевыми устройствами[20].

Управление TCP-окном

Снижение перегрузки достигается и ограничением размера окна передачи. При запросе больших файлов/страниц приложение обычно выставляет окно в 32-64 КБайт. Сервер при этом передаёт максимально возможные данные по окну. Если множество клиентов одновременно загружают большие файлы, это приводит к перегрузке на вышестоящем провайдере. Сокращая объём окна, можно снизить объём трафика и нагрузку[21][22].

Обратное явное уведомление о перегрузке (BECN)

Обратное ECN (англ. Backward ECN, BECN) — механизм, использующий ICMP source quench для передачи сигналов о перегрузке на уровне IP без согласования между конечными узлами[23].

Побочные эффекты борьбы с коллапсом перегрузки

Радиоканалы

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

Краткоживущие соединения

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

Контроль допуска

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

Примечания

  1. H. Al-Bahadili. Simulation in computer network design and modeling: Use and analysis. IGI Global, Hershey, PA, 2012. С. 282. Simulation in computer network design and modeling: Use and analysis (англ.). IGI Global (2012). Дата обращения: 31 января 2025.
  2. den Hartog, F., Raschella, A., Bouhafs, F., Kempker, P., Boltjes, B., & Seyedebrahimi, M. A Pathway to solving the Wi-Fi Tragedy of the Commons in apartment blocks. In: 2017 27th International Telecommunication Networks and Applications Conference (ITNAC), 2017, pp. 1-6. A Pathway to solving the Wi-Fi Tragedy of the Commons in apartment blocks (англ.). ITNAC 2017. IEEE (ноябрь 2017). Дата обращения: 31 января 2025.
  3. Fall, K.R. TCP/IP Illustrated, Volume 1: The Protocols : [англ.] / Fall, K.R., Stevens, W.R.. — 2. — Pearson Education, 2011. — P. 739. — ISBN 9780132808187.
  4. Congestion Avoidance and Control (англ.) (ноябрь 1988). Дата обращения: 31 января 2025.
  5. Sally Floyd, Who Helped Things Run Smoothly Online, Dies at 69 (англ.), New York Times (4 сентября 2019). Дата обращения: 31 января 2025.
  6. Nanda, Priyadarsi (1 ноября 2000). “A Control Theory Approach for Congestion Control in Intranetwork”. IFAC Proceedings Volumes [англ.]. 33 (30): 91—94. DOI:10.1016/S1474-6670(17)36735-6. ISSN 1474-6670. Дата обращения 2025-01-31.
  7. Vinton G. Cerf; Robert E. Kahn (май 1974). “A Protocol for Packet Network Intercommunication” (PDF). IEEE Transactions on Communications [англ.]. 22 (5): 637—648. DOI:10.1109/tcom.1974.1092259. Архивировано из оригинала (PDF) 4 марта 2016. Дата обращения 2025-01-31. Проверьте дату в |date= (справка на английском)
  8. Van Jacobson, Michael J. Karels. Congestion Avoidance and Control. Proceedings of the Sigcomm '88 Symposium, vol.18(4): pp.314-329, Stanford, CA, август 1988. Congestion Avoidance and Control. Stanford SIGCOMM 1988. Дата обращения: 31 января 2025.
  9. RFC 2001 — TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
  10. RFC 2581 — TCP Congestion Control
  11. RFC 3390 — TCP Increasing TCP’s Initial Window
  12. TCP Congestion Avoidance Explained via a Sequence Diagram (англ.). Дата обращения: 26 ноября 2010. Архивировано 22 ноября 2010 года.
  13. 1 2 Sally Floyd: RED (Random Early Detection) Queue ManagementRED (Random Early Detection) Queue Management (англ.). Дата обращения: 31 января 2025.
  14. Sally Floyd, Van Jacobson. Random Early Detection Gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, vol.1(4): pp.397-413, 1993.
  15. An Analytical RED Function Design Guaranteeing Stable System Behavior (англ.). Дата обращения: 31 января 2025.
  16. Zhang, Changwang; Yin, Jianping; Cai, Zhiping; Chen, Weifeng (2010). “RRED: Robust RED Algorithm to Counter Low-rate Denial-of-Service Attacks” (PDF). IEEE Communications Letters [англ.]. IEEE. 14 (5): 489—491. DOI:10.1109/LCOMM.2010.05.091407. S2CID 1121461. Дата обращения 2025-01-31.
  17. Congestion Avoidance Overview (англ.). Cisco Systems. Дата обращения: 31 января 2025.
  18. RFC 3168 — The Addition of Explicit Congestion Notification (ECN) to IP
  19. Comparative study of RED, ECN and TCP Rate Control (1999)
  20. L4S (англ.). Nokia Bell Labs (14 июня 2023). Дата обращения: 31 января 2025.
  21. Generalized Window Advertising for TCP CongestionControl (англ.). Дата обращения: 13 ноября 2020.
  22. Pop, O. Advertised Window-Based TCP Flow Control in Routers // Telecommunication Network Intelligence : [англ.] / O. Pop, I. Moldován, Cs. Simon … [et al.]. — 2000. — P. 197–218. — ISBN 978-1-4757-6693-6. — doi:10.1007/978-0-387-35522-1_12.
  23. A proposal for Backward ECN for the Internet Protocol

Литература

  • John Evans. Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice : [англ.] / John Evans, Clarence Filsfils. — Morgan Kaufmann, 2007. — ISBN 978-0-12-370549-5.
  • Sally Floyd. Congestion Control Principles (англ.). IETF (сентябрь 2000). Дата обращения: 31 января 2025.
  • John Nagle. Congestion Control in IP/TCP (англ.). IETF (6 января 1984). Дата обращения: 31 января 2025.
  • Congestion Avoidance and Control (англ.) (ноябрь 1988). Дата обращения: 31 января 2025.

Ссылки