Перегрузка сети
Перегрузка сети (англ. 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].
Побочные эффекты борьбы с коллапсом перегрузки
Радиоканалы
Многие алгоритмы борьбы с коллапсом подразумевают, что потери пакетов обусловлены исключительно перегрузкой. Для проводных сетей это справедливо, но в Wi-Fi, 3G и других радиосетях потери могут вызываться помехами, а TCP будет ошибочно трактовать их как перегрузку, приводя к ненужному снижению скорости.
Краткоживущие соединения
Медленный старт неэффективен для коротких соединений. Старые веб-браузеры для каждой загрузки открывали отдельное TCP-соединение, что удерживало соединения в режиме медленного старта, увеличивая задержки. Современные браузеры либо открывают несколько соединений, либо используют постоянные HTTP-соединения.
Контроль допуска
Контроль допуска — это система, при которой устройству необходимо получить разрешение на установление нового соединения. Если новое соединение способно вызвать перегрузку, в допуске может быть отказано. Примеры: режим CFTXOP в стандарте G.hn (домашние сети), протокол резервирования ресурсов (RSVP) для сетей IP, или протокол резервирования потоков (SRP) для Ethernet.
Примечания
- ↑ 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.
- ↑ 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.
- ↑ Fall, K.R. TCP/IP Illustrated, Volume 1: The Protocols : [англ.] / Fall, K.R., Stevens, W.R.. — 2. — Pearson Education, 2011. — P. 739. — ISBN 9780132808187.
- ↑ Congestion Avoidance and Control (англ.) (ноябрь 1988). Дата обращения: 31 января 2025.
- ↑ Sally Floyd, Who Helped Things Run Smoothly Online, Dies at 69 (англ.), New York Times (4 сентября 2019). Дата обращения: 31 января 2025.
- ↑ 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.
- ↑ 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=(справка на английском) - ↑ 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.
- ↑ RFC 2001 — TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
- ↑ RFC 2581 — TCP Congestion Control
- ↑ RFC 3390 — TCP Increasing TCP’s Initial Window
- ↑ TCP Congestion Avoidance Explained via a Sequence Diagram (англ.). Дата обращения: 26 ноября 2010. Архивировано 22 ноября 2010 года.
- ↑ 1 2 Sally Floyd: RED (Random Early Detection) Queue ManagementRED (Random Early Detection) Queue Management (англ.). Дата обращения: 31 января 2025.
- ↑ Sally Floyd, Van Jacobson. Random Early Detection Gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, vol.1(4): pp.397-413, 1993.
- ↑ An Analytical RED Function Design Guaranteeing Stable System Behavior (англ.). Дата обращения: 31 января 2025.
- ↑ 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.
- ↑ Congestion Avoidance Overview (англ.). Cisco Systems. Дата обращения: 31 января 2025.
- ↑ RFC 3168 — The Addition of Explicit Congestion Notification (ECN) to IP
- ↑ Comparative study of RED, ECN and TCP Rate Control (1999)
- ↑ L4S (англ.). Nokia Bell Labs (14 июня 2023). Дата обращения: 31 января 2025.
- ↑ Generalized Window Advertising for TCP CongestionControl (англ.). Дата обращения: 13 ноября 2020.
- ↑ 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.
- ↑ 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.
Ссылки
- Promoting the Use of End-to-End Congestion Control in the Internet (IEEE/ACM Transactions on Networking, август 1999; англ.)
- On the Evolution of End-to-end Congestion Control in the Internet: An Idiosyncratic View (IMA Workshop on Scaling Phenomena in Communication Networks, октябрь 1999; англ.)
- Queuing на Linktionary Queuing (англ.). Linktionary. Дата обращения: 31 января 2025. Архивировано 8 марта 2003 года.
- Guidelines for optimizing Multi-Level ECN, using fluid flow based TCP model
- RED-PD: RED with Preferential Dropping RED-PD (англ.). Дата обращения: 31 января 2025. Архивировано 2 апреля 2003 года.
- Simple RED Simulator by Mehmet Suzen
- Approaches to Congestion Control in Packet Networks
- Papers in Congestion Control
- Random Early Detection Homepage
- Explicit Congestion Notification Homepage
- TFRC Homepage
- AIMD-FC Homepage
- Recent Publications in low-rate denial-of-service (DoS) attacks