Тонкая Настройка TCP

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

Как-то раз мой друг Боб пришел ко мне с вопросом. Он написал программу на Java, которая копировала 100 МБ файлы с его компьютера под управлением Windows XP в его офисе на Linux-сервер в региональный офис компании. В обоих офисах используются 100Мбит сети Ethernet, соединенные через 155Mbps VPN канал. Однако он был очень неприятно удивлен тем, что измеренная скорость передачи была ниже 4Мбит, и попросил меня объяснить причину такого поведения.

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

Как Работает TCP

Самый распространенный сетевой протокол, используемый в Интернет это Transmission Control Protocol, или TCP . TCP использует «окно перегрузки» — число пакетов, которое должен послать или принять стек, прежде чем перейти в режим ожидания сигнала подтверждения. Чем больше размер этого окна, тем выше пропускная способность. Алгоритмы «медленного запуска» и «предотвращения перегрузки» определяют размер окна перегрузки. Максимальный размер окна перегрузки зависит от размера буфера, который ядро отводит для каждого сокета. Для каждого сокета существует значение буфера, установленное по умолчанию, которое программы могут изменять, используя системный вызов библиотек перед открытием сокета. Для некоторых операционных систем существует определенный максимум размера буфера на уровне ядра. Вы можете установить собственное значение буфера как для отправляющего, так и для принимающего конца сокета.

Чтобы достичь максимальной скорости, важно использовать оптимальный размер буфера для TCP сокета для используемого подключения. Если буферы слишком маленькие, окно перегрузки TCP некогда не откроется полностью, таким образом отправитель не сможет работать по полной. Если буферы слишком большие, отправитель попросту завалит получателя, что приведет к тому, что получатель просто будет резать пакеты и окно перегрузки выключится. Наиболее вероятна такая ситуация когда отправляющий хост по производительности лучше, чем получающий. Слишком большое окно на отправляющей стороне это не проблема, пока существует некоторый избыток памяти.

Рассчитываем Размер Буфера TCP

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

Пропускная способность = размер буфера / задержка

В обычной сети задержка между двумя офисами составит около 40ms, а в Windows XP размер буфера по умолчанию равен 17,520 байт. Значит, максимальная пропускная способность будет равна:

Размер буфера по умолчанию для Mac OS X установлен в 64K, таким образом, при использовании Mac OS X у Боба получилось бы лучше, однако были бы достигнуты далеко не 100Mbps, которые по идее должны быть.

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

Большинство экспертов по сетям соглашаются, что оптимальный размер буфера для определенной сети равен удвоенному произведению задержки и полосы пропускания:

Программа ping даст вам округленное время (round trip time — RTT) для сетевого соединения, что в два раза больше задержки. Формула принимает следующий вид:

Для сети Боба ping вернул RTT в 80ms. Это значит, что размер буфера TCP должен быть:

Боб знал скорость VPN канала компании, но часто вы не знаете о пропускной способности сетевого маршрута. Определить пропускную способность сети иногда очень сложно. На сегодняшний день самой большой пропускной способностью является 1Gbps (в США, Европе и Японии), получается, что узкое место это местные сети на обоих концах. В моей практике я встречал в основном офисы, где компьютеры объединены 100Mbps сетью Ethernet. Тогда имеем следующую картину: 100Mbps=12MBps, что, согласитесь, совсем неплохо.

Перенастройка размера буфера никак не повлияет на производительность в сетях, где регламентированная скорость составляет 10Mbps или ниже; например, с хостами, соединенными через DSL, кабельный модем, ISDN, или линию T1. Существует программа pathrate, которая выполняет хорошую работу: оценивает пропускную способность. Но она не позволяет проводить глубокий анализ полученных временных рядов. Например, не ставилась задача получать различные функции распределения, а так же недостаточен набор параметров, которые можно варьировать при проведении измерений. Программа работает только на платформе Linux и требует возможности логина на оба компьютера.

Устанавливаем размер буфера TCP

Итак, имеем две настройки, которые нужно оптимизировать: размер буфера TCP по умолчанию и максимальный размер буфера. С правами пользователя можно изменить размер буфера по умолчанию, но для изменения его максимального размера требуются права администратора. Заметьте, что большинство сегодняшних Unix-Like систем по умолчанию имеют значение максимального размера буфера TCP всего лишь 256K. В Windows нет максимального размера буфера по умолчанию, но администратор может его установить. Очень важно изменить размеры буферов у посылающей и принимающей машин. Изменение только отправляющего буфера не даст ничего, т.к. TCP согласовывает размер буфера с меньшим из двух. Это означает, что не обязательно устанавливать оптимальный размер буфера на отправляющей и принимающей машинах. Обычно делают следующее: устанавливают размер буфера на серверной стороне довольно большим (например 1,024K) и затем позволяют клиенту определить и установить «оптимальное» значение для данного сетевого маршрута. Чтобы установить размер буфера TCP, используйте метода setSendBufferSize и setReceiveBufferSize в Java, или вызов setsockopt в С. Ниже представлен пример установки размеров буфера ТСР в пределах приложения на Java:

Хорошей идеей будет вызвать getSendBufferSize (или getReceiveBufferSize) после установки размера буфера. Таким образом, мы удостоверимся, что наша ОС поддерживает буферы таких размеров. Вызов setsockopt не вернет ошибку, если вы используете значение, большее чем максимальный размер буфера, но попросту будет использовать максимальный размер вместо значения, которое установили вы. Linux загадочным образом удваивает значение, которое вы передаете для размера буфера, так что когда вы делаете getSendBufferSize / getReceiveBufferSize и видите в два раза больше, чем указали, не волнуйтесь — для Linux это «нормально».

А вот и пример на С:

Фрагмент кода на С, проверяющий текущий размер буфера:

Устанавливаем Максимальный Размер буфера TCP

Для большинства соединений невозможно увеличить предопределенный системой максимальный размер ТСР буфера. Например, возьмем соединение в 100Mbps между Калифорнией и Великобританией, время задержки RTT которого 150 мсек. Оптимальный размер буфера для такого соединения будет равен 1,9 МБ, что в 30 раз больше чем размер буфера по умолчанию и в 7,5 раз больше, чем максимальный размер буфера ТСР в Linux.

Чтобы поменять параметры ТСР в Linux, добавьте следующие строки в файл / etc/sysctl.conf , и затем запустите sysctl -p. Теперь наши настройки будут применяться во время загрузки.

Устанавливайте максимальные размеры буферов таким образом, чтобы полностью использовать ресурсы соединения. В Windows не требуется вносить каких-либо изменений, как например максимальный размер буфера ТСР по умолчанию (GlobalMaxTcpWindowSize) не определяется. На моем сайте TCP Tuning Guide web site можно найти информацию о том, как установить максимальный размер буфера в других операционных системах.

От Теории к Практике

Наверняка сейчас у вас возник вопрос «А как же я могу осуществить все эти возможности в реальных условиях? Доверить ли пользователям установку размера буфера? Стоит ли подсчитать оптимальный размер буфера для пользователя? Или может вообще стоит установить больший буфер и больше не вспоминать об этом?»

Обычно, я предлагаю следующее для большинства приложений, ориентированных на высокоскоростную (более 40Mbps), с большой задержкой (RTT > 10ms) сеть. Ваш клиент должен запустить ping, чтобы определить RTT и затем просто принять пропускную способность, равную 100Mbps. Ping трафик блокируется некоторыми сайтами. В этом случае можно воспользоваться утилитой synack, которая использует ТСР вместо ICMP для определения RTT. Если ваши пользователи разбираются в сетях, то можно предоставить им самим самостоятельно выбирать размер TCP буфера. Не правильно тупо устанавливать большие размеры буферов для всех сетевых маршрутов, особенно если приложение могут запустить через медленные линии, такие как DSL или модемы.

Linux на Помощь

Начиная с версии 2.4, в Linux добавлена возможность автоподстройки ТСР буфера отправителя . Это означает, что отправителю больше не нужно задумываться о вызове setsockopt(). Однако все еще следует выполнять setsockopt() на стороне получателя, и вам придется подкорректировать максимальный размер буфера при автоподстройке, что по умолчанию составляет лишь 128 кБ. Начиная с Linux 2.6.7, была добавлена функция автоподстройки для серверной стороны, таким образом вам не нужно больше думать о получателе. Свершилось! К несчастью, максимальный размер буфера ТСР все еще маленький — но хотя бы теперь это проблема системного администрирования, а не программиста.

Мои начальные результаты довольно-таки внушительные. После увеличения максимальных буферов ТСР, при соединении в 1Gbps через США (RTT = 67ms), производительность с 10Mbps при использовании Linux 2.4 поднялась до 700Mbps при использовании Linux 2.6.12, ускорение в 70 раз! На соединении из Калифорнии в Великобританию (RTT = 150 мсек), скорость с 4Mbps на Linux 2.4 выросла до 560Mbps — ускорение в 140 раз. Этого удалось достичь всего лишь увеличением максимального размера буфера ТСР.

В Linux 2.6 кроме того включены некоторые улучшения ТСР, что означает, что скорость можно увеличить еще в несколько раз. Особенно то, что в Linux 2.6 теперь используется алгоритм контроля перегрузки BIC (BIC — bus interface controller, контроллер магистрального интерфейса), который задумывался для увеличения производительности ТСР при использовании высокоскоростных линий и большими задержками. Ручная подстройка Linux 2.4 при использовании тех же соединений дает пропускную способность в 300Mbps через США и 70Mbps до Великобритании. Надеюсь, в скором времени все эти прелести появятся в Windows.

Наладка Сети

Если все попытки повысить пропускную способность закончились неудачей, то, скорее всего причина в самой сети. Итак, сначала попробуйте netstat -s, чтобы посмотреть количество повторных передач. Если их много, то это говорит о том, что сеть перегружена, построена на плохом «железе» или вовсе с нарушением топологии. Также повторные передачи происходят в случае, когда отправляющая машина намного быстрее принимающей. Также обратите внимание на число ошибок, возвращаемых netstat- большое число ошибок также говорит о проблеме в самой сети. Мне самому с трудом верится, но очень часто причина неполадок LAN с сетями 100BT заключается в том, что хост настроен на работу в полном дуплексе, а свитч Ethernet работает в режиме полудуплекса, или наоборот. Новое оборудование автоматически согласует дуплексы, тогда как со старым могут возникнуть проблемы, результатом будет работающая, но ужасно медленная сеть. Лучше всего работать в режиме полного дуплекса, но некоторое старое оборудование 100ВТ поддерживает только полудуплекс. Смотрите TCP Tuning Guide, чтобы узнать, как проверить настройки дуплекса для вашего компьютера.

Internet2’s Network Diagnostic Tool (NDT) — отличная утилита, предназначенная для определения проблем с перегрузкой и дуплексом. NDT это Java аплет, который можно запустить с одного из NDT серверов.

Обратите Внимание на Программу scp

Для копирования файлов через Интернет обычно пользуются программой scp. К сожалению, тонкая настройка ТСР не поможет пропускной способности >scp, потому что в scp используетсяOpenSSL, в котором используются статически определенные потоки буферов. Эти буферы действуют на пропускную способность сети как узкое место, особенно в сетях с длинной задержкой и высокими скоростями. Питсбургская страница Сверхвысокопроизводительного Центра High Performance SSH/SCP объясняет это более подробно и, кроме того, там имеется патч для OpenSSL, устраняющий эту проблему.

Тонкая настройка сетевого стека на Windows-хостах (часть вторая)

Продолжение статьи о тонкой настройке сетевого стека Windows-систем

Это – вторая часть статьи. Поэтому всё, что относится к первой, относится и к этой. В этой, правда, будет больше настроек сетевых адаптеров, но не суть. Не буду повторяться, разве что в плане диспозиции.

Диспозиция

Я предполагаю, что Вы, товарищ читатель, знаете на приемлемом уровне протокол TCP, да и вообще протоколы сетевого и транспортного уровней. Ну и канального тоже. Чем лучше знаете – тем больше КПД будет от прочтения данной статьи.

Речь будет идти про настройку для ядра NT 6.1 (Windows 7 и Windows Server 2008 R2). Всякие исторические ссылки будут, но сами настройки и команды будут применимы к указанным ОС, если явно не указано иное.

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

Содержание (то, что зачёркнуто, было в первой части статьи)

Работаем с управлением RWND (autotuninglevel)

Данный параметр тесно связан с описаным ранее параметром WSH – Window Scale Heuristic. Говоря проще, включение WSH – это автоматическая установка данного параметра, а если хотите поставить его вручную – выключайте WSH.

Параметр определяет логику управление размером окна приёма – rwnd – для TCP-соединений. Если Вы вспомните, то размер этого окна указывается в поле заголовка TCP, которое называется window size и имеет размер 16 бит, что ограничивает окно 2^16 байтами (65536). Этого может быть мало для текущих высокоскоростных соединений (в сценариях вида “с одного сервера по IPv6 TCPv6-сессии и десятигигабитной сети копируем виртуалку” – совсем тоскливо), поэтому придуман RFC 1323, где описывается обходной способ. Почему мало? Потому что настройка этого окна по умолчанию такова:

• Для сетей со скоростью менее 1 мегабита – 8 КБ (если точнее, 6 раз по стандартному MSS – 1460 байт)
• Для сетей со скоростью 100 Мбит и менее, но более 1 Мбит – 17 КБ (12 раз по стандартному MSS – 1460 байт)
• Для сетей со скоростью выше 100 Мбит – 64 КБ (максимальное значение без поддержки RFC 1323)

Примечание: Речь о номинальной скорости, т.е. по информации с интерфейса в момент его инициализации, а не о фактической, которая может быть и ощутимо ниже.

Способ обхода, предлагаемый в RFC 1323, прост и красив. Два хоста, ставящих TCP-сессию, согласовывают друг с другом параметр, который является количеством бит, на которые будет сдвинуто значение поля windows size. То есть, если они согласуют этот параметр равный 2, то оба из них будут читать это поле сдвинутым “влево” на 2 бита, что даст увеличение параметра в 2^2=4 раза. И, допустим, значение этого поля в 64К превратится в 256К. Если согласуют 5 – то поле будет сдвинуто “влево” на 5 бит, и 64К превратится в 2МБ. Максимальный поддерживаемый Windows порог этого значения (scaling) – 14, что даёт максимальный размер окна в 1ГБ.

Примечание: Как понятно, всё это не будет работать без включения поддержки RFC 1323 (см. предыдущую статью).

Как настраивается RWND в Windows

Существующие варианты настройки этого параметра таковы:

• netsh int tcp set global autotuninglevel=disabled – фиксируем значение по умолчанию (для гигабитного линка это будет 64K), множитель – нуль. Это поможет, если промежуточные узлы (например, старое сетевое оборудование) не понимает, что значение окна TCP – это не поле window size, а оно, модифицированное с учётом множителя scaling.
• netsh int tcp set global autotuninglevel=normal – оставляем автонастройку, значение множителя – не более 8.
• netsh int tcp set global autotuninglevel=highlyrestricted – оставляем автонастройку, значение множителя – не более 2.
• netsh int tcp set global autotuninglevel=restricted – оставляем автонастройку, значение множителя – не более 4.
• netsh int tcp set global autotuninglevel=experimental – оставляем автонастройку, значение множителя – до 14.

Ещё раз – если Вы включите WSH, он сам будет подбирать “максимальный” множитель, на котором достигается оптимальное качество соединения. Подумайте перед тем, как править этот параметр вручную.

Работаем с Checksum offload IPv4/IPv6/UDP/TCP

Данная пачка технологий крайне проста. Эти настройки снимают с CPU задачи проверки целостности полученых данных, которые (задачи, а не данные) являются крайне затратными. То есть, если Вы получили UDP-датаграмму, Вам, по сути, надо проверить CRC у ethernet-кадра, у IP-пакета, и у UDP-датаграммы. Всё это будет сопровождаться последовательным чтением данных из оперативной памяти. Если скорость интерфейса большая и трафика много – ну, Вы понимаете, что эти, казалось бы, простейшие операции, просто будут занимать ощутимое время у достаточно ценного CPU, плюс гонять данные по шине. Поэтому разгрузки чексумм – самые простые и эффективно влияющие на производительность технологии. Чуть подробнее про каждую из них:

IPv4 checksum offload

Сетевой адаптер самостоятельно считает контрольную сумму у принятого IPv4 пакета, и, в случае, если она не сходится, дропит пакет.

Бывает продвинутая версия этой технологии, когда адаптер умеет сам проставлять чексумму отправляемого пакета. Тогда ОС должна знать про поддержку этой технологии, и ставить в поле контрольной суммы нуль, показывая этим, чтобы адаптер выставлял параметр сам. В случае chimney, это делается автоматически. В других – зависит от сетевого адаптера и драйвера.

IPv6 checksum offload

Учитывая, что в заголовке IPv6 нет поля checksum, под данной технологией обычно имеется в виду “считать чексумму у субпротоколов IPv6, например, у ICMPv6”. У IPv4 это тоже подразумевается, если что, только у IPv4 субпротоколов, подпадающих под это, два – ICMP и IGMP.

UDPv4/v6 checksum offload

Реализуется раздельно для приёма и передачи (Tx и Rx), соответственно, считает чексуммы для UDP-датаграмм.

TCPv4/v6 checksum offload

Реализуется раздельно для приёма и передачи (Tx и Rx), соответственно, считает чексуммы для TCP-сегментов. Есть тонкость – в TCPv6 чексумма считается по иной логике, нежели в UDP.

Общие сведения для всех технологий этого семейства

Помните, что все они, по сути, делятся на 2 части – обработка на адаптере принимаемых данных (легко и не требует взаимодействия с ОС) и обработка адаптером отправляемых данных (труднее и требует уведомления ОС – чтобы ОС сама не считала то, что будет посчитано после). Внимательно изучайте документацию к сетевым адаптерам, возможности их драйверов и возможности ОС.

Ещё есть заблуждение, гласящее примерно следующее “в виртуалках всё это не нужно, ведь это все равно работает на виртуальных сетевухах, значит, считается на CPU!”. Это не так – у хороших сетевых адаптеров с поддержкой VMq этот функционал реализуется раздельно для каждого виртуального комплекта буферов отправки и приёма, и в случае, если виртуальная система “заказывает” этот функционал через драйвер, то он включается на уровне сетевого адаптера.

Как включить IP,UDP,TCP checksum offload в Windows

Включается в свойствах сетевого адаптера. Операционная система с данными технологиями взаимодействует через минипорт, читая настройки и учитывая их в случае формирования пакетов/датаграмм/сегментов для отправки. Так как по уму это всё реализовано в NDIS 6.1, то надо хотя бы Windows Server 2008.

Работаем с Flow Control

Вы наверняка видели в настройках сетевых адаптеров данный параметр. Он есть практически на всех, поскольку технология данная (официально называемая 802.3x) достаточно простая и древняя. Но это никак не отменяет её эффективность.

Примечание: Сразу – это – управление потоком ethernet-кадров (которые L2). У TCP есть свой flow control, это другое.

Суть технологии проста – существует множество ситуаций, когда приём кадра L2 нежелателен (заполнен буфер приёма, перегружена шина данных, загружен порт получателя). В этом случае без управления потоком кадр придётся просто отбросить (обычный tail-drop). Это повлечёт за собой последующее обнаружение потери пакета, который был в кадре, и долгие выяснения на уровне протоколов более высоких уровней (того же TCP), что и как произошло. Иными словами, потеря 1.5КБ кадра превратится в каскад проблем, согласований и выяснений, на которые будет затрачено много времени и куда как больше трафика, чем если бы потери удалось избежать.

А избежать её просто – надо отправить сигнальный кадр с названием PAUSE – попросить партнёра “притормозить на чуток”. Соответственно, надо, чтобы устройство умело и обрабатывать такие кадры, и отправлять их. Кадр устроен просто – это 802.3 с вложением с кодом 0x0001, отправляемое на мультикастовый адрес 01-80-C2-00-00-01 , внутри которого – предлагаемое время паузы.

Примечание: Работает это всё только поверх full-дуплекса, потому что дуплекс подразумевает, что с той стороны – другой хост или коммутатор, а в случае 802.3 без дуплекса непонятен получатель кадра и механизм не работает.

Примечание 2: Заметьте, какой интересный адрес. Это хоть и мультикаст (видно по биту в заголовке), но т.н. local switch multicast. То есть нормальный простой свич (без всяких IGMP и CGMP), по идее, отдаёт мультикастовые кадры флудом во все порты, но этот адрес будет исключением – это специальный мультикаст “от абонента до ближайшего свича и не дальше”.

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

Кстати, была в своё время попытка сделать более сложный и мудрый стандарт, который бы учитывал кучу факторов – характеристику среды, параметры портов коммутатора и абонента, и прочее-прочее-прочее. Называли 802.3ar. К 2008 году стало понятно, что это банально никому не нужно и комитет разогнали.

Как включить Flow control в Windows

Включается в свойствах сетевого адаптера. Операционная система с данной технологией не взаимодействует. Не забудьте про full duplex.

Работаем с Jumbo Frame

Исторически размер данных кадра протокола Ethernet – это 1.5КБ, что в сумме со стандартным заголовком составляет 1518 байт, а в случае транкинга 802.1Q – 1522 байт. Соответственно, этот размер оставался, а скорости росли – 10 Мбит, 100 Мбит, 1 Гбит. Скорость в 100 раз выросла – а размер кадра остался. Непорядок. Ведь это обозначает, что процессор в 100 раз чаще “дёргают” по поводу получения нового кадра, что объём служебных данных также остался прежним. Совсем непорядок.

Идея jumbo frame достаточно проста – увеличить максимальный размер кадра. Это повлечёт огромное количество плюсов:

• Улучшится соотношение служебных и “боевых” данных – ведь вместо, допустим, 4х IP-пакетов можно отправить один.
• Уменьшится число переключений контекста – можно будет реже инициировать функцию “пришёл новый кадр”.
• Можно соответствующим образом увеличить размеры PDU верхних уровней – пакета IP, датаграммы UDP, сегмента TCP – и получить соответствующие преимущества.

Данная технология реализуема только на интерфейсах со скоростями 1 гбит и выше. Если Вы включите jumbo frames на уровне сетевого адаптера, а после согласуете скорость в 100 мбит, то данная настройка не будет иметь смысла.

Во избежание каши: PDU – это название элемента данных на разных уровня модели OSI. На первом это будет бит, на втором – кадр или ячейка (в ряде ситуаций и пакет), на третьем – пакет или датаграмма, на четвёртом – датаграмма или сегмент. MTU – это максимальное количество байт полезной нагрузки (поэтому про MTU первого уровня говорить не принято – примерно как про Западный и Восточный полюсы Земли). MSS – это максимальный размер одного “кусочка” tcp-сессии – сегмента.

Для увеличения максимального размера кадра есть достаточно технологических возможностей – например, длина кадра хранится в поле размером в 2 байта, поэтому менять формат кадра 802.3 не нужно – место есть. Ограничением является логика подсчёта CRC, которая становится не очень эффективна при размерах >12К, но это тоже решаемо.

Фундаментально неверное мнение – что jumbo frame – это “разрешение на обработку кадров специальной длины”. Вызвано тем, что в настройках сетевых адаптеров обычно выбирается размер jumbo-кадра из фиксированных – 4088, 9014, 16K. По сути, включение jumbo просто снимает верхнее ограничение на приём кадров, у которых в поле “размер” число больше 1500. Если jumbo frame не поддерживаются, такие кадры просто отбрасываются. А данные стандартные числа в настройках сетевого адаптера – это ограничение на формируемый для отправки кадр. Нужно оно, потому что не все коммутаторы поддерживают произвольную длину (ведь эта поддержка требует пропорционально увеличить кадровые буферы). В реальности подавляющее большинство коммутаторов поддерживает размер кадра в 9К, выставлять значение 4088 нет особого смысла.

Самый простой способ – выставить у адаптера данный параметр в 9014 байт. Это является тем, что сейчас “по умолчанию” называется jumbo frame и шире всего поддерживается.

Внимательный читатель уже заметил, что когда речь идёт о 1.5К данных, кадр получается 1518 байт, а когда про 9К – 9014. Как же так получается? Да очень просто – по причине раздолбайства укоренилась чуть разная логика подсчёта. Когда считают обычный кадр, то его делят на 3 части – header(14 байт)-data(до 1500 байт)-trailer(который CRC – 4 байта), а когда jumbo – то считают математическую сумму длины заголовка (который тоже 14 байт) и данных (которые до 9000 байт), а CRC не учитывают. Отсюда и бардак.

Есть ли у данной технологии минусы? Есть. Первый – в случае потери кадра из-за обнаружения сбоя в CRC Вы потеряете в 6 раз больше данных. Второй – появляется больше сценариев, когда будет фрагментация сегментов TCP-сессий. Вообще, в реальности эта технология очень эффективна в сценарии “большие потоки не-realtime данных в локальной сети”, учитывайте это. Копирование файла с файл-сервера – это целевой сценарий, разговор по скайпу – нет. Замечу также, что протокол IPv6 более предпочтителен в комбинации с Jumbo frame.

Как включить Jumbo frame в Windows

Включается в свойствах сетевого адаптера (естественно, только гигабитного). Операционная система с данной технологией не взаимодействует, автоматически запрашивая у сетевой подсистемы MTU канального уровня.

Работаем с AIFS (Adaptive Inter-frame Spacing)

Данная технология предназначена для оптимизации работы на half-duplex сетях со скоростями 10/100 мегабит, и, в общем-то, сейчас не особо нужна. Суть её проста – в реальной жизни, при последовательной передаче нескольких ethernet-кадров одним хостом, между ними есть паузы – чтобы и другие хосты могли “влезть” и передать свои данные, и чтобы работал механизм обнаружения коллизий (который CSMA/CD). Иначе, если бы кадры передавались “вплотную”, хост, копирующий по медленной сети большой поток данных, монополизировал бы всю сеть для себя. В случае же full-duplex данная мера уже не сильно интересна, потому что ситуации “из N хостов одновременно может передавать только один” нет. Помните, что включая данную технологию, Вы позволяете адаптеру уменьшать межкадровое расстояние ниже минимума, что приведёт к чуть более эффективному использованию канала, но в случае коллизии Вы получите проблему – “погибнет” не только один кадр, но и соседний (а то и несколько).

Данные паузы называются или interframe gap, или interframe spacing. Минимальное штатное значение этого параметра – 96 бит. AIFS уменьшает это значение до:

• 47 бит в случае канала 10/100 МБит.
• 64 бит в случае канала 1 ГБит.
• 40 бит в случае канала 10 ГБит.

Как понятно, чисто технически уменьшать это значение до чисел менее 32 бит (размер jam) совсем неправильно, поэтому можно считать 32 бита технологическим минимумом IFS.

Процесс, который состоит в приёме потока кадров с одним IFS и отправкой с другим IFS, иногда называется IFG Shrinking.

В общем, говоря проще – негативные эффекты этой технологии есть, но они будут только на 10/100 Мбит сетях в режиме half-duplex, т.к. связаны с более сложным сценарием обработки коллизий. В остальном у технологии есть плюс, Вы получите небольшой выигрыш в части эффективности загрузки канала в сценарии “плотный поток от одного хоста”.

Да, не забудьте, что коммутатор должен “понимать” ситуацию, когда кадры идут плотным (и более плотным, чем обычно) потоком.

Как включить Adaptive Inter-frame Spacing в Windows

Включается в свойствах сетевого адаптера. Операционная система с данной технологией не взаимодействует.

Работаем с Header Data Split

Фича достаточно интересна и анонсирована только в NDIS 6.1. Суть такова – допустим, что у Вас нет Chimney Offload и Вы обрабатываете заголовки программно. К Вам приходят кадры протокола Ethernet, а в них, как обычно – различные вложения протоколов верхних уровней – IP,UDP,TCP,ICMP и так далее. Вы проверяете CRC у кадра, добавляете кадр в буфер, а после – идёт специфичная для протокола обработка (выясняется протокол сетевого уровня, выясняется содержимое заголовка и предпринимаются соответствующие действия). Всё логично.

Технология не работает для ARP и для всех IPSec-вложений (50 и 51, которые ESP и AH). Для ARP понятно почему – сплиттить особо нечего, ARP-вложение копеечно по размеру, смысла нет особо. Да и ARP-трафик не представляет с точки зрения доли в общем трафике никакого интереса. IPSec же “расщеплять” можно и даже нужно, но до границы ESP/AH вложения – т.е. в случае IPSec NAT-T, “завёрнутого” в UDP ->4500, расщепление всё ж сработает, NDIS 6.1 это умеет. Но лучше уточняйте в документации к конкретному сетевому адаптеру.

Но вот есть одна проблема. Смотрите. Если Вы приняли, допустим, сегмент TCP-сессии, обладающий 10К данных, то, по сути, последовательность действий будет такая (вкратце):

1. Сетевая карта: Обработать заголовок 802.3; раз там 0x0800 (код протокола IPv4), то скопировать весь пакет и отдать наверх на обработку. Ведь в данные нам лезть незачем – не наша задача, отдадим выше.
2. Минипорт: Прочитать заголовок IP, понять, что он нормальный, найти код вложения (раз TCP – то 6) и скопировать дальше. Данные-то не нам не нужны – это не наша задача, отдадим выше.
3. NDIS: Ага, это кусок TCP-сессии номер X – сейчас изучим его и посмотрим, как и что там сделано

Заметили проблему? Она проста. Каждый слой читает свой заголовок, который исчисляется в байтах, а тащит ради этого путём копирования весь пакет.

Технология Header-Data Split адресно решает этот вопрос – заголовки пакетов и данные хранятся отдельно. Т.е. когда при приёме кадра в нём обнаруживается “расщепимое в принципе” содержимое, то оно разделяется на части – в нашем примере заголовки IP+TCP будут в одном буфере, а данные – в другом. Это сэкономит трафик копирования, притом очень ощутимо – как минимум на порядки (сравните размеры заголовков IP, который максимум 60 байт, и размер среднего пакета). Технология крайне полезна.

Как включить Header-Data Split в Windows

Включится оно само, как только сетевой драйвер отдаст минипорту флаг о поддержке данной технологии. Можно выключить вручную, отдав NDIS_HD_SPLIT_COMBINE_ALL_HEADERS через WMI на данный сетевой адаптер – тогда минипорт будет “соединять” головы и жо не-головы пакетов перед отправкой их на NDIS. Это может помочь в ситуациях, когда адаптер некорректно “расщепляет” сетевой трафик, что будет хорошо заметно (например, ничего не будет работать, потому что TCP-заголовки не будут обрабатываться корректно). В общем и целом – включайте на уровне сетевого адаптера, и начиная с Windows Server 2008 SP2 всё дальнейшее будет уже не Вашей заботой.

Работаем с Dead Gateway Detection

Данный механизм – один из самых смутных. Я лично слышал вариантов 5 его работы, все из которых были неправильными. Давайте разберёмся.

Первое – для функционирования этого механизма надо иметь хотя бы 2 шлюза по умолчанию. Не маршрутов, вручную добавленых в таблицу маршрутизации через route add например, а два и более шлюза.

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

Как же будет работать этот механизм? Логика достаточно проста. Стартовые условия – механизм включен и параметр TcpMaxDataRetransmissions настроен по-умолчанию, то есть равен 5. Допустим, что у нас на данный момент есть 10 tcp-подключений.

1. На каждое подключение создаётся т.н. RCE – route cache entry – строчка в кэше маршрутов, которая говорит что-то вида такого “все соединения с IP-адреса X на IP-адрес Y ходят через шлюз Z, пересчитывать постоянно это не нужно, потому что полностью обрабатывать таблицу маршрутизации ради 1го пакета – уныло и долго. Ну, этакий Microsoft’овский свичинг L3 типа CEF. 🙂
2. Соединение N1 отправляет очередной сегмент TCP-сессии. В ответ – тишина. Помер.
3. Соединение N1 отправляет тот же сегмент TCP-сессии, уже имея запись, что 1 раз это не получилось. В ответ – опять тишина. Нет ACK’а. И этот сегмент стал героем.
4. Соединение N1 нервничает и отправляет тот же сегмент TCP-сессии. ACK’а нет. Соединение понимает, что так жить нельзя и делает простой вывод – произошло уже 3 сбоя отправки, что больше, чем половина значения TcpMaxDataRetransmissions , которое у нас 5. Соединение объявляет шлюз нерабочим и заказывает смену шлюза.
5. ОС выбирает следующий по приоритету шлюз, обрабатывает маршрут и генерит новую RCE-запись.
6. Счётчик ошибок сбрасывается на нуль, и всё заново – злополучный сегмент соединения N1 опять пробуют отправить.

Когда такое происходит для более чем 25% соединений (у нас их 10, значит, когда такое случится с 3 из них), то IP-стек меняет шлюз по-умолчанию. Уже не для конкретного TCP-соединения, а просто – для всей системы. Счётчик количества “сбойных” соединений сбрасывается на нуль и всё готово к продолжению.

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

Как настроить Dead Gateway Detection в Windows

Для настройки данного параметра нужно управлять тремя значениями в реестре, находящимися в ключе:

Все они имеют тип 32bit DWORD и следующую логику настройки:

• TcpMaxDataRetransmissions – Количество повторных передач TCP-сегментов. От этого числа берётся критерий “Более половины”.
• TcpMaxConnectRetransmissions – То же самое, но для повторных попыток подключения, а не передачи сегментов данных.
• EnableDeadGWDetect – Включён ли вообще алгоритм обнаружения “мёртвого” шлюза. Единица – включён, нуль – отключен.

Вместо заключения

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

Если как-нибудь дойдут руки – будет новая часть статьи.