АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Explicit Congestion Notification

Explicit Congestion Notification (англ. Explicit Congestion Notification, ECN) — расширение для интернет-протокола и протокола управления передачей (TCP), определённое в (2001). ECN позволяет осуществлять сквозное оповещение о перегрузках в сети без необходимости отбрасывания пакетов. Эта функция является опциональной и может применяться только между двумя конечными точками с поддержкой ECN при условии, что и сетевая инфраструктура поддерживает данную технологию.

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

Исторически часть устаревшего или некорректно работающего сетевого оборудования не обрабатывала ECN-биты корректно — такие устройства иногда отбрасывали или искажали пакеты с установленными ECN-битами[1].[2][3] По состоянию на 2015 год, измерения показали, что доля веб-серверов в публичном Интернете, для которых наличие ECN предотвращает установление сетевого соединения, снизилась до менее 1 %.

Пассивная поддержка ECN появилась в Ubuntu Linux начиная с версии 12.04 и в Windows Server с 2012 года[4]. Доля самых популярных веб-сайтов с пассивной поддержкой ECN выросла с 8,5 % в 2012 году до более 70 % в мае 2017 года[4]. В настоящее время для широкого внедрения ECN в Интернете требуется явный запрос ECN от клиентов. В июне 2015 года компания Apple объявила, что будет включать ECN по умолчанию на своих поддерживаемых и будущих продуктах в целях стимулирования его массового внедрения.

Принцип работы

ECN требует специально реализованной поддержки как на интернет-уровне, так и на транспортном уровне по следующим причинам:

  • В стеке TCP/IP маршрутизаторы работают на интернет-уровне, тогда как управление скоростью передачи осуществляется конечными узлами на транспортном уровне.
  • Перегрузка может быть устранена только отправителем, но о её наличии становится известно только после отправки пакета, поэтому требуется механизм эхо-уведомления о перегрузке от получателя к отправителю.

Без ECN эхо-индикация перегрузки реализуется косвенно — по потере пакетов. В случае ECN сигнализация перегрузки осуществляется установкой в IP-пакете значения поля ECN в CE ("Congestion Experienced" — перегрузка), а получатель передаёт это уведомление отправителю, выставляя соответствующие биты в заголовке транспортного протокола. Например, при использовании TCP для передачи сигнала используется бит ECE.

ECN на уровне IP

ECN использует два младших бита поля Differentiated Services (DS) Field в заголовке IPv4 и Traffic Class в заголовке IPv6[5], позволяя кодировать четыре значения:

  • 00 — транспорт без поддержки ECN, Not-ECT
  • 01 — ECN Capable Transport(1), ECT(1)
  • 10 — ECN Capable Transport(0), ECT(0)
  • 11 — Congestion Experienced, CE

Если обе конечные точки поддерживают ECN, они помечают свои пакеты как ECT(0) или ECT(1). Маршрутизаторы трактуют их одинаково. Если пакет проходит через очередь Active Queue Management (AQM), например управляемую алгоритмом RED, испытывающую перегрузку, и поддерживающий ECN маршрутизатор, то он может изменить значение поля на CE вместо отбрасывания пакета. Такая процедура называется «маркировкой» и предназначена для информирования получателя о надвигающейся перегрузке. На принимающем конце верхний (транспортный) протокол обрабатывает сигнал и должен вернуть уведомление отправителю для сокращения скорости передачи.

В архитектуре L4S (RFC 9331) семантика маркировки CE изменена: она является ранним сигналом о начале формирования очереди, а не эквивалентом потери пакета[6]. Кодовая точка ECT(1) была освобождена от устаревшего механизма ECN Nonce (RFC 8311) специально для использования в новых экспериментах, таких как L4S[7].

Так как признак CE эффективно может быть обработан только вышележащим протоколом, поддерживающим корректную реакцию и эхо-механизм, ECN используется лишь в сочетании с такими протоколами (например, TCP), которые реализуют контроль перегрузки и способность передавать сигнал обратным ходом.

ECN и TCP

В TCP поддержка ECN реализована двумя флагами в заголовке TCP. Первый — ECN-Echo (ECE) — используется для передачи назад отправителю сигнала о перегрузке (индикации, необходимой для снижения скорости передачи). Второй — Congestion Window Reduced (CWR) — подтверждает получение эхо-уведомления о перегрузке. Использование ECN на TCP-соединении опционально; обе стороны должны договориться об этом при установлении соединения с помощью соответствующих опций в сегментах SYN и SYN-ACK.

Когда ECN согласован, отправитель помечает IP-пакеты транспортируемые TCP-соединением как ECN-совместимые (ECT). Это позволяет промежуточным маршрутизаторам, поддерживающим ECN, отмечать эти пакеты как CE вместо отбрасывания.

При получении пакета с признаком CE TCP-приёмник посылает отправителю эхо-сигнал о перегрузке посредством установки флага ECE. Получатель сегмента TCP с установленным ECE уменьшает размер окна перегрузки — как при потере пакета. После этого он подтверждает получение уведомления передачей сегмента с флагом CWR.

Узел продолжает посылать сегменты с установленным ECE до получения сегмента с CWR.

В апреле 2026 года был стандартизирован механизм AccECN (RFC 9768)[8], который заменяет бинарный сигнал о перегрузке на количественный, передавая точное число пакетов с меткой CE. Для передачи счётчика AccECN использует комбинацию флагов ECE, CWR и AE (ранее известного как NS)[9]. При этом обеспечивается автоматическая обратная совместимость с узлами, поддерживающими только классический стандарт RFC 3168[9].

Для анализа соответствующих пакетов в tcpdump используют фильтр tcp and ((tcp[12] & 1) != 0 or (tcp[13] & 192) != 0), который учитывает бит NS/AE в дополнение к флагам ECE и CWR[10].

ECN и управляющие пакеты TCP

Поскольку TCP не реализует контроль перегрузки на чистых управляющих пакетах (чистых ACK, SYN, FIN), такие пакеты, как правило, не помечаются как ECN-совместимые.

В 2009 году была предложена идея маркировки пакетов SYN-ACK битами ECN (улучшение известно как ECN+), что показало значительный прирост производительности для короткоживущих TCP-соединений[11].

ECN с другими транспортными протоколами

ECN определён и для других транспортных протоколов, реализующих контроль перегрузки, таких как DCCP, SCTP. Общий принцип аналогичен TCP, хотя детализация кодировки различается.

Возможна работа ECN с протоколами, расположенными выше UDP. Однако контроль перегрузки в UDP должен реализовываться на уровне приложения. Ранние UDP-протоколы (например, DNS) ECN не использовали. Современные UDP-протоколы, такие как QUIC, применяют ECN для контроля перегрузок.

Протокол QUIC имеет стандартизированную базовую поддержку ECN (RFC 9000)[12]. Для передачи медиа в реальном времени (например, WebRTC) механизм обратной связи ECN при использовании RTP поверх UDP определён в RFC 6679[13].

Влияние на производительность

Поскольку эффективность ECN возможна только при использовании схем активного управления очередями (AQM), итоговая польза определяется конкретной реализацией AQM. Тем не менее, отмечаются некоторые универсальные эффекты.

Наиболее ожидаемый результат — снижение количества сброшенных пакетов TCP, что уменьшает потери, задержки и особенно джиттер, так как избегается ретрансляция. Эффект особенно заметен при одном незавершённом сегменте TCP (когда удаётся избежать таймаута RTO), что характерно для интерактивных соединений (например, удалённые входы в систему) и транзакционных протоколов (HTTP-запросы, диалоговая фаза SMTP, SQL-запросы).

Влияние ECN на массовую производительность (bulk throughput) менее однозначно[14], поскольку современные TCP-реализации довольно эффективно пересылают потерянные сегменты при больших окнах передачи.

Известно, что использование ECN может ухудшить производительность в условиях высоких перегрузок при таких AQM-алгоритмах, которые вообще не отбрасывают пакеты[11]. Современные реализации AQM предпочитают отбрасывать пакеты при высоких нагрузках, а не только маркировать их.

Архитектура L4S обеспечивает сверхнизкую задержку при сохранении пропускной способности, сопоставимой с классическим ECN, за счёт плавного и пропорционального снижения скорости передачи[6][15]. Механизмы ECN и L4S критически важны для ИИ-кластеров и сетей RoCEv2, так как они позволяют избежать потерь пакетов и снизить задержки в очередях[16].

Реализации

Современные реализации TCP/IP, как правило, поддерживают ECN, однако часто по умолчанию функция отключена.

Microsoft Windows

Начиная с Windows Server 2008 и Windows Vista, поддержка ECN для TCP присутствует[17]. С версии Windows Server 2012 ECN включён по умолчанию в серверных редакциях благодаря использованию Data Center Transmission Control Protocol (DCTCP)[18]. В предыдущих и несерверных версиях Windows функция по умолчанию отключена.

Включить ECN можно командой {{{1}}}.

BSD

В FreeBSD ECN может быть настроен через параметр net.inet.tcp.ecn.enable sysctl. По умолчанию он активен для входящих соединений с поддержкой ECN; может быть включён для всех соединений или полностью отключён[19].

NetBSD 4.0 реализует ECN для TCP, он включается через sysctl-параметр net.inet.tcp.ecn.enable[20].

Аналогично, в OpenBSD используется параметр sysctl net.inet.tcp.ecn[21].

Linux

Начиная с версии 2.4.20 ядра Linux (ноябрь 2002)[22], поддерживаются различные режимы работы ECN для TCP, настраиваемые через параметр /proc/sys/net/ipv4/tcp_ecn посредством sysctl[23]. В ядре Linux 7.0 (2026 год) было добавлено значение 3, которое включает AccECN по умолчанию для всех новых соединений[24]. Другие значения:

  • 0 — отключённый ECN (инициация и принятие ECN невозможны)
  • 1 — включение ECN как по входящим запросам, так и запрос ECN для исходящих соединений
  • 2 (по умолчанию) — включён на входящих соединениях, но не инициализируется на исходящих

С версии 4.1 ядра Linux (июнь 2015) механизм tcp_ecn_fallback (по умолчанию включён при значении 1) реализует гибкий откат при обнаружении невозможности использовать ECN на исходящих соединениях[25]. В ядре 7.0 механизм отката стал более сложным: он включает автоматическое согласование наилучшего режима ECN при установке соединения и адаптивный откат для L4S-алгоритмов для справедливого сосуществования с классическим трафиком[24][6].

macOS

В Mac OS X 10.5 и 10.6 реализована поддержка ECN для TCP. Управление осуществляется булевыми переменными sysctl net.inet.tcp.ecn_negotiate_in и net.inet.tcp.ecn_initiate_out[26]. Первая активирует ECN на входящих соединениях с флагами ECN, вторая — инициирует исходящие соединения с ECN. Значения по умолчанию — 0, при установке в 1 ECN включается.

В июне 2015 года компания Apple объявила, что в OS X 10.11 ECN будет включён по умолчанию, однако на самом деле такой политики не было. В macOS Sierra ECN включён для половины TCP-сессий[27].

iOS

В июне 2015 года Apple объявила о поддержке ECN в iOS 9, причём ECN был включён по умолчанию. Для соединений по Wi-Fi/Ethernet функция активна на 5 % случайно выбранных TCP-соединений в iOS 9, 50 % в iOS 10[28], а в iOS 11 — на 100 % сессий[29].

Solaris

Ядро Solaris поддерживает три режима ECN для TCP:[30]

  • never — ECN отключён
  • active — ECN включён
  • passive — поддержка ECN рекламируется только по запросу

В Solaris 11.4 режим по умолчанию — active. Изменить можно через {{{1}}}[31].

ECN на уровне IP в маршрутизаторах

Для реализации маркировки ECN в маршрутизаторах необходима поддержка активных дисциплин управления очередями (AQM).

Маршрутизаторы Cisco IOS поддерживают маркировку ECN при использовании дисциплины WRED с момента версии 12.2(8)T.

Маршрутизаторы под Linux поддерживают ECN при использовании дисциплин RED или GRED с параметром ecn, а также дисциплин sfb, fq_codel и CAKE[32].

Современные BSD-системы (FreeBSD, NetBSD, OpenBSD) реализуют поддержку ECN-маркировки в подсистеме ALTQ для различных дисциплин очередей, в том числе RED и Blue. FreeBSD 11 также поддерживает CoDel, PIE, FQ-CoDel, FQ-PIE в рамках ipfw и dummynet с возможностью ECN-маркировки[33].

Механизмы переноса битов ECN поддерживаются при инкапсуляции в туннелях VXLAN и Geneve. Согласно стандарту RFC 6040[34][35], при инкапсуляции поле ECN копируется из внутреннего IP-заголовка во внешний, а при деинкапсуляции метка о перегрузке (CE) переносится обратно во внутренний пакет. Это обеспечивает сквозную прозрачность ECN и позволяет конечным устройствам реагировать на перегрузки в физической сети.

Data Center TCP (DCTCP)

Data Center TCP (DCTCP) использует ECN для повышения эффективности алгоритма управления перегрузкой TCP[36]. DCTCP применяется в дата-центрах. В то время как стандартный алгоритм TCP определяет только сам факт перегрузки, DCTCP с помощью ECN позволяет оценить её степень[37].

DCTCP изменяет TCP-приёмник так, что он всегда возвращает точное значение ECN-маркировки входящих пакетов, что приводит к игнорированию части функционала по обеспечению надёжности сигнализации. Это делает DCTCP-отправитель уязвимым к потере ACK от приёмника, которую он не может контролировать[38]. По состоянию на июль 2014 года разрабатываются новые алгоритмы, способные обеспечить ту же точность e обратному сигналу с большей надёжностью[38].

Идеи DCTCP эволюционировали в более универсальную архитектуру L4S для публичного интернета[39]. Уязвимость DCTCP к потере ACK была решена в стандарте AccECN (RFC 9768) за счёт использования 3-битного поля ACE и новой TCP-опции, обеспечивающих надёжную передачу счётчиков перегрузки[8].

Безопасность

Основные угрозы безопасности, связанные с использованием Explicit Congestion Notification (ECN), включают возможность манипуляции флагами как со стороны конечных узлов, так и со стороны промежуточного сетевого оборудования, а также атаки типа «отказ в обслуживании» (DoS)[40].

Одной из существенных проблем является «отбеливание» ECN (ECN bleaching) — ситуация, при которой промежуточные маршрутизаторы или межсетевые экраны обнуляют биты ECN в IP-заголовке проходящих пакетов. Это превращает ECN-совместимый трафик в обычный, отключая механизм уведомления о перегрузке для данного соединения и вынуждая сеть прибегать к отбрасыванию пакетов[41].

Злоумышленники могут эксплуатировать механизм ECN для проведения DoS-атак, например, отправляя поддельные пакеты с флагом эхо-уведомления о перегрузке. Это заставляет отправителя ошибочно диагностировать перегрузку в сети и необоснованно снижать скорость передачи данных.

Для защиты от сокрытия получателем меток о перегрузке (что давало бы ему несправедливое преимущество в пропускной способности) изначально был разработан механизм ECN Nonce (RFC 3540)[42]. Однако он не получил широкого распространения на практике и в дальнейшем был признан устаревшим, а зарезервированные для него сетевые ресурсы были переназначены для других технологий[43].

Примечания

  1. ↑ Steven Bauer, Robert Beverly, Arthur Berger. Measuring the State of ECN Readiness in Servers, Clients, and Routers. Internet Measurement Conference 2011 (2011). Дата обращения: 28 мая 2026. Архивировано 22 марта 2014 года.
  2. ↑ Alberto Medina, Mark Allman, Sally Floyd. Measuring Interactions Between Transport Protocols and Middleboxes. Internet Measurement Conference 2004. Дата обращения: 28 мая 2026. Архивировано 4 марта 2016 года.
  3. ↑ TBIT, the TCP Behavior Inference Tool: ECN. Icir.org. Дата обращения: 28 мая 2026. Архивировано 11 марта 2013 года.
  4. ↑ 1 2 David Murray, Terry Koziniec, Sebastian Zander, Michael Dixon, Polychronis Koutsakis. An Analysis of Changing Enterprise Network Traffic Characteristics. The 23rd Asia-Pacific Conference on Communications (APCC 2017) (2017). Дата обращения: 28 мая 2026. Архивировано 3 октября 2017 года.
  5. ↑ The Addition of Explicit Congestion Notification (ECN) to IP. IETF Datatracker. Дата обращения: 28 мая 2026.
  6. ↑ 1 2 3 Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture. IETF Datatracker. Дата обращения: 28 мая 2026.
  7. ↑ Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation. RFC Editor. Дата обращения: 28 мая 2026.
  8. ↑ 1 2 The Addition of More Accurate ECN (AccECN) to TCP. IETF Datatracker (апрель 2026). Дата обращения: 28 мая 2026.
  9. ↑ 1 2 RFC 9768: The Addition of More Accurate ECN (AccECN) to TCP. RFC Editor. Дата обращения: 28 мая 2026.
  10. ↑ RFC 3540: Explicit Congestion Notification (ECN) for TCP. RFC Editor. Дата обращения: 28 мая 2026.
  11. ↑ 1 2 Aleksandar Kuzmanovic. The power of explicit congestion notification. В сборнике: Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications. 2005.
  12. ↑ QUIC: A UDP-Based Multiplexed and Secure Transport. IETF Datatracker. Дата обращения: 28 мая 2026.
  13. ↑ Explicit Congestion Notification (ECN) for UDP. IETF Datatracker. Дата обращения: 28 мая 2026.
  14. ↑ Marek Małowidzki, Simulation-based Study of ECN Performance in RED Networks, Proc. SPECTS'03, 2003.
  15. ↑ Low Latency, Low Loss, Scalable Throughput (L4S). Nokia Bell Labs. Дата обращения: 28 мая 2026.
  16. ↑ Cisco Data Center Networking Blueprint for AI/ML Applications. Cisco. Дата обращения: 28 мая 2026.
  17. ↑ New Networking Features in Windows Server 2008 and Windows Vista. Дата обращения: 28 мая 2026. Архивировано 15 января 2010 года.
  18. ↑ Data Center Transmission Control Protocol (DCTCP) (Windows Server 2012). Дата обращения: 28 мая 2026. Архивировано 26 августа 2017 года.
  19. ↑ tcp(4) - Internet Transmission Control Protocol. FreeBSD Kernel Interfaces Manual. Дата обращения: 28 мая 2026.
  20. ↑ Announcing NetBSD 4.0 (19 декабря 2007). Дата обращения: 28 мая 2026. Архивировано 31 октября 2014 года.
  21. ↑ Michael Lucas. Absolute OpenBSD: UNIX for the Practical Paranoid. — No Starch Press, 2013. — ISBN 9781593274764.
  22. ↑ A Map of the Networking Code in Linux Kernel 2.4.20, Technical Report DataTAG-2004-1, FP5/IST DataTAG Project. datatag.web.cern.ch (март 2004). Дата обращения: 28 мая 2026. Архивировано 27 октября 2015 года.
  23. ↑ Documentation/networking/ip-sysctl.txt: /proc/sys/net/ipv4/* Variables. kernel.org. Дата обращения: 28 мая 2026. Архивировано 5 марта 2016 года.
  24. ↑ 1 2 Linux 7.0: AccECN Enabled by Default. LinuxTeck. Дата обращения: 28 мая 2026.
  25. ↑ Linux man pages. man7.org (5 декабря 2015). Дата обращения: 28 мая 2026. Архивировано 16 февраля 2016 года.
  26. ↑ ECN (Explicit Congestion Notification) in TCP/IP. Дата обращения: 28 мая 2026. Архивировано 19 июня 2012 года.
  27. ↑ macOS 10.12 Sierra: The Ars Technica review. Ars Technica (20 сентября 2016). Дата обращения: 28 мая 2026. Архивировано 26 апреля 2018 года.
  28. ↑ Bhooma, Padma TCP ECN — Experience with enabling ECN on the Internet (март 2017). Дата обращения: 28 мая 2026. Архивировано 9 мая 2018 года.
  29. ↑ Inc., Apple Advances in Networking, Part 1 - WWDC 2017 - Videos - Apple Developer. Apple Developer. Дата обращения: 28 мая 2026. Архивировано 31 января 2018 года.
  30. ↑ ipadm(8). Oracle Solaris 11.4 Information Library. Oracle. Дата обращения: 28 мая 2026.
  31. ↑ Administering TCP/IP Networks, IPMP, and IP Tunnels in Oracle® Solaris 11.4, Using the TCP ECN Feature. Oracle Solaris 11.4 Information Library. Oracle. Дата обращения: 28 мая 2026.
  32. ↑ Høiland-Jørgensen, Toke; Täht, Dave & Morton, Jonathan (2018), Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways, arΧiv:1804.07617v2 [cs.NI]. 
  33. ↑ Import Dummynet AQM version 0.2.1 (CoDel, FQ-CoDel, PIE and FQ-PIE) to FreeBSD 11. The FreeBSD Project, FreeBSD r300779. Дата обращения: 28 мая 2026.
  34. ↑ RFC 6040: ECN for IP Tunnels. RFC Editor. Дата обращения: 28 мая 2026.
  35. ↑ RFC 8926: Geneve ECN. IETF Datatracker. Дата обращения: 28 мая 2026.
  36. ↑ Data Center TCP (DCTCP). Дата обращения: 28 мая 2026. Архивировано 31 октября 2014 года.
  37. ↑ Data Center TCP (DCTCP): TCP Congestion Control for Data Centers, RFC 8257, doi:10.17487/RFC8257, <https://datatracker.ietf.org/doc/html/rfc8257>. Проверено 21 августа 2024. 
  38. ↑ 1 2 Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback, 26 августа 2015, RFC 7560, doi:10.17487/RFC7560, <https://datatracker.ietf.org/doc/html/rfc7560>. Проверено 21 августа 2024. 
  39. ↑ TCP Prague: A DCTCP variant for the Internet. SBC Sol. Дата обращения: 28 мая 2026.
  40. ↑ ECN Explained. IORiver. Дата обращения: 28 мая 2026.
  41. ↑ ECN bleaching. arXiv. Дата обращения: 28 мая 2026.
  42. ↑ Explicit Congestion Notification (ECN) for TCP. IETF. Дата обращения: 28 мая 2026.
  43. ↑ Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation. RFC Translater. Дата обращения: 28 мая 2026.

Литература

Категории