Введение

Расширение протокола Интернет для сигнализации о перегрузке сети Explicit Congestion Notification (ECN) является расширением протокола Интернет и протокола управления передачей данных и определяется в RFC 3168 (2001). ECN позволяет осуществлять уведомление о перегрузке сети от конца до конца без потери пакетов. ECN – это необязательная функция, которая может использоваться между двумя конечными точками с поддержкой ECN, если базовая сетевая инфраструктура также ее поддерживает. Традиционно сети TCP/IP сигнализируют о перегрузке путем сброса пакетов. При успешном согласовании ECN, маршрутизатор с поддержкой ECN может установить флаг в заголовке IP вместо сброса пакета, чтобы сигнализировать о приближающейся перегрузке. Получатель пакета передает информацию о перегрузке отправителю, который снижает скорость передачи, как если бы был зафиксирован потеря пакета. Некоторые устаревшие или неисправные сетевые устройства исторически некорректно обрабатывали или отбрасывали пакеты с установленными битами ECN, вместо того чтобы реагировать на них должным образом или игнорировать их. По данным на 2015 год, доля веб-серверов в общедоступном Интернете, для которых включение ECN приводило к проблемам с сетевыми подключениями, снизилась менее чем до 1%. Пассивная поддержка реализована в Ubuntu Linux начиная с версии 12.04 и в Windows Server начиная с 2012 года. Пассивная поддержка на наиболее популярных веб-сайтах увеличилась с 8,5% в 2012 году до более 70% в мае 2017 года.

Работа ECN с TCP

TCP поддерживает ECN, используя два флага в заголовке TCP. Первый, ECN Echo (ECE), используется для возврата информации о перегрузке (то есть для подачи сигнала отправителю о необходимости снизить скорость передачи). Второй, Congestion Window Reduced (CWR), используется для подтверждения получения информации о перегрузке. Использование ECN в TCP-соединении является необязательным; для использования ECN необходимо согласовать его при установлении соединения, включив соответствующие опции в сегменты SYN и SYN ACK. Когда ECN согласован для TCP-соединения, отправитель указывает, что IP-пакеты, содержащие сегменты TCP этого соединения, передают трафик от ECN-совместимого транспорта, помечая их кодовой точкой ECT. Это позволяет промежуточным маршрутизаторам, поддерживающим ECN, помечать эти IP-пакеты кодовой точкой CE вместо их отбрасывания для сигнализации о надвигающейся перегрузке. При получении IP-пакета с кодовой точкой "Congestion Experienced", TCP-приемник возвращает эту информацию о перегрузке, используя флаг ECE в заголовке TCP. Когда конечная точка получает сегмент TCP с установленным битом ECE, она уменьшает окно перегрузки, как если бы пакет был потерян. Затем она подтверждает получение информации о перегрузке, отправляя сегмент с установленным битом CWR. Узел продолжает передавать сегменты TCP с установленным битом ECE до тех пор, пока не получит сегмент с установленным битом CWR. Для просмотра затронутых пакетов с помощью tcpdump используйте фильтр (tcp[13] & 0xc0 != 0).

Пакеты управления ECN и TCP

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

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

ECN также определен для других протоколов транспортного уровня, осуществляющих контроль перегрузки, в частности DCCP и протокол управления потоком (SCTP). Общий принцип аналогичен TCP, хотя детали кодирования в сети отличаются. Возможно использование ECN с протоколами, работающими поверх UDP. Однако UDP требует, чтобы контроль перегрузки осуществлялся на уровне приложения, и ранние протоколы на основе UDP, такие как DNS, не использовали ECN. Более современные протоколы на основе UDP, такие как QUIC, используют ECN для контроля перегрузки.

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

Поскольку ECN эффективен только в сочетании с политикой активного управления очередями (AQM), преимущества ECN зависят от конкретной используемой реализации AQM. Однако некоторые наблюдения, по-видимому, применимы к различным AQM. Как и ожидалось, ECN снижает количество пакетов, теряемых TCP-соединением, что, избегая повторной передачи, уменьшает задержку и особенно дрожание. Этот эффект наиболее заметен, когда у TCP-соединения имеется только один незавершенный сегмент, позволяя избежать таймаута RTO; это часто встречается в интерактивных соединениях, таких как удалённый вход, и в транзакционных протоколах, таких как HTTP-запросы, фаза обмена данными SMTP или SQL-запросы. Влияние ECN на пропускную способность при передаче больших объёмов данных менее очевидно, поскольку современные реализации TCP достаточно эффективно вовремя повторно отправляют потерянные сегменты, когда окно отправителя велико. Использование ECN может негативно сказываться на производительности в сильно загруженных сетях при использовании алгоритмов AQM, которые никогда не отбрасывают пакеты. Начиная с Windows Server 2012, он включен по умолчанию в версиях Windows Server, поскольку используется протокол управления передачей данных центра обработки данных (DCTCP). В предыдущих версиях Windows и несерверных версиях он отключен по умолчанию. Поддержку ECN можно включить с помощью командной строки, например .

БСД

На FreeBSD ECN для TCP можно настроить с помощью sysctl. По умолчанию он включен только для входящих соединений, запрашивающих его поддержку. Его также можно включить для всех соединений или полностью отключить. NetBSD 4.0 реализует поддержку ECN для TCP; её можно активировать через интерфейс sysctl, установив значение параметра равным 1. Аналогично, sysctl можно использовать и в OpenBSD.

Mac OS X

Mac OS X 10.5 и 10.6 реализуют поддержку ECN для TCP. Она управляется с помощью булевых переменных sysctl `net.inet.tcp.ecn.enable` и `net.inet.tcp.ecn.initiate`. Первая переменная включает ECN для входящих соединений, которые уже имеют установленные флаги ECN; вторая пытается инициировать исходящие соединения с включенной ECN. Обе переменные по умолчанию равны 0, но могут быть установлены в 1 для включения соответствующего поведения. В июне 2015 года Apple Inc. объявила, что в OS X 10.11 ECN будет включена по умолчанию.

iOS

В июне 2015 года Apple Inc. объявила, что iOS 9, следующая версия iOS, будет поддерживать ECN и иметь его включенным по умолчанию, а для iOS 11 – на 100%.

Поддержка ECN в IP с помощью маршрутизаторов

Поскольку маркировка ECN в маршрутизаторах зависит от некоторой формы активного управления очередями, маршрутизаторы должны быть сконфигурированы с подходящей дисциплиной очереди для выполнения маркировки ECN. Маршрутизаторы Cisco IOS выполняют маркировку ECN при настройке дисциплины WRED, начиная с версии 12.2(8)T.

Маршрутизаторы Linux выполняют маркировку ECN при настройке одной из дисциплин очереди RED или GRED с явным параметром ecn, при использовании дисциплины sfb, дисциплины CoDel Fair Queuing (fq_codel) или дисциплины CAKE. Современные реализации BSD, такие как FreeBSD, NetBSD и OpenBSD, поддерживают маркировку ECN в реализации очередей ALTQ для ряда дисциплин очередей, в частности RED и Blue. FreeBSD 11 включила в себя реализации дисциплин очередей CoDel, PIE, FQ_CoDel и FQ_PIE в рамках ipfw/dummynet с возможностью маркировки ECN.

TCP центра обработки данных

Протокол управления передачей данных центра обработки данных (Data Center TCP или DCTCP) использует ECN для улучшения алгоритма управления перегрузкой протокола TCP. Он применяется в сетях центров обработки данных. В то время как стандартный алгоритм управления перегрузкой TCP способен лишь обнаруживать наличие перегрузки, DCTCP, используя ECN, может оценить степень перегрузки. DCTCP изменяет TCP-приемник таким образом, чтобы он всегда передавал точную маркировку ECN входящих пакетов, при этом игнорируя функцию, предназначенную для обеспечения надежности сигнализации. Это делает отправителя DCTCP уязвимым к потере подтверждений (ACK) от приемника, и у него отсутствует механизм для обнаружения или устранения этой проблемы. По состоянию на 2014 год, алгоритмы, обеспечивающие эквивалентную или лучшую обратную связь от приемника более надежным способом, являются активной областью исследований.