Enable jumbo frames windows

В этой статье мы рассмотрим методику активации пакетов увеличенной длины, Jumbo Frames, на виртуальной машине с Windows, запущенной в Hyper-V на базе Windows Server 2012 R2. Но для начала немного вкратце напомним что такое Jumbo Frames и зачем они нужны.

Jumbo Frames – это особые, сверхдлинные кадры Ethernet, размер которых превышает стандартный размер MTU (Maximum Transmission Unit) для Ethernet в 1518 байт. Размер Jumbo-кадров обычно варьируется в диапазоне от 1518 до 16000 байт. Как правило, размер Jumbo Frame-а не превышает 9000 байт, это ограничение накладывается 32 битной CRC в сетях Ethernet, теряющей свою эффективность при объеме передаваемых данных больше 12000 байт.

Зачем же нужны такие увеличенные пакеты?

Благодаря использованию пакетов увеличенной длины можно существенно повысить КПД сети, т.к. при сохранении размера Ethernet заголовка, количество полезной информации, содержащейся в пакете увеличивается (почти в 6 раз). Кроме того за счет уменьшения количества пакетов, заголовки которых нужно разбирать, снижается нагрузка на CPU сервера. Пакеты Jumbo Frames рекомендуется использовать в высокопроизводительных сетях с интенсивной пересылкой больших объемов данных

Настройка Jumbo Frames в Hyper-V Windows Server 2012 / R2

По умолчанию jumbo frames в Windows — системах отключен. Чтобы активировать передачу больших пакетов Jumbo Frames для гостевой ОС, запущенной в виртуальной машине на базе Hyper –V 2012 нужно:

1. Включить Jumbo Frames на физических сетевых картах (NIC) гипервизора (хостовой ОС), подключенных к сети LAN
2. Включить поддержку Jumbo Frames на сетевом оборудовании LAN
3. Включить Jumbo Frames на виртуальном коммутаторе Hyper-V
4. Активировать Jumbo Frames в гостевой ОС

Jumbo Frames на физических сетевых картах сервера

Для каждой из сетевых карточек (NIC), используемых для подключений сервера (хостовой ОС) к сети LAN необходимо в свойствах сетевых адаптеров перейти в режим настройки драйвера (кнопка Configure). Затем на вкладке Advanced найти параметр с названием Jumbo Frames (в зависимости от производителя NIC, он также может называться Packet Size, Jumbo Packets или что-то похоже) и установить его значение в 9014.

Примечание. Если это поле отсутствует, убедитесь, что ваша сетевая карточка поддерживает этот режим, и обновите драйвера до актуальной версии.

Картинка с сайта: winitpro.ru

Поддержка Jumbo Frames на сетевом оборудовании

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

Включаем поддержку Jumbo Frames на виртуальном коммутаторе Hyper-V

В том случае, если на хостовой ОС (гипервизор) установлена Windows Server 2012, чтобы активировать Jumbo Frames для виртуального коммутатора Hyper-V нужно

1. Открыть редактор реестра и развернуть ветку HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}
2. Внутри данной ветки содержатся несколько «подкустов». Нужно пробежаться по ним и найти ветку, в которой значение параметра «driverdesc» равно «Hyper-V Virtual Ethernet Adapter», а «Characteristics»= 0x00000029 (41)
3. В найденной ветке задать параметру *JumboPacket значение 9014
   

   Картинка с сайта: winitpro.ru

4. Перезагрузите сервер для вступления изменений в силу

Активация Jumbo Frames в гостевой ОС (Windows Server 2012)

На уровне гостевой ОС (в нашем примере это Windows Server 2012) включается аналогично гипервизору: в расширенных настройках драйвера укажите, что Jumbo Packet=9014 Bytes.

Картинка с сайта: winitpro.ru

Тестируем работу Jumbo Frames в Windows

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

Протестировать работу Jumbo Frames можно с помощью простой команды ping, позволяющей определить что пакет большого размера может быть передан без дефрагментации:
ping -f –l 8972 second_jumbo_frame_server

где, флаг f — запрещает фрагментацию пакета, флаг –l задает размер пакета (8972 — на нашем стенде это максимальный размер пакета, передающийся без дефрагментации), second_jumbo_frame_server – имя/ip_адрес второго сервера с включенным Jumbo Frames.

Если ping отработал успешно – поздравляю, вы только что настроили Jumbo Frames для виртуальной машины на Hyper-V!

Настройка Jumbo Frames из Powershell

Указанные выше операции можно выполнить и с помощью всемогущего Powershell:

Следующая команда позволяет узнать включен ли Jumbo Frames для сетевого адаптера с именем Ethernet:
Get-NetAdapterAdvancedProperty –Name Ethernet –DisplayName “Jumbo Packet”

Если команда возвращает Disables (RegistryValue 1514), этоозначает, что Jumbo Frames в настоящий момент не включен, и используется стандартный размер MTU – 1514 байт.

Задаем увеличенный размер пакета для данного интерфейса:
Get-NetAdapterAdvancedProperty -Name Ethernet -DisplayName "Jumbo Packet" | Set-NetAdapterAdvancedProperty -RegistryValue "9014"

Картинка с сайта: winitpro.ru

Под Jumbo Frame обычно обозначают кадр сети Ethernet, в котором, можно передать данные, размером более 1500 байт (MTU). Обычно jumbo-фреймы могут передавать до 9000 байтов данных. По умолчанию, в операционной системе Windows, jumbo-фреймы отключены на уровне драйвера сетевой карты. 
Чтобы включить поддержку jumbo-фреймов в Windows необходимо сделать следующее:
1. Открыть свойства сетевого подключения и нажать Properties (свойства)
2. в открывшемся окне нажать кнопку Configure (сконфигурировать) под названием сетевой карты
3. в окне Advanced перейти в пункт Jumbo Frame и в выпадающем списке справа выбрать желаемый ( или максимальный) размер Jumbo фрейма.4. После включения Jumbo Frame (выбора значения MTU в 9000), значение MTU выставляется в свойствах сетевого адаптера.

Картинка с сайта: userman.ru

 Внимание: включение Jumbo Frame в свойствах драйвера сетевого адаптера приводит к краткосрочной потере сетевой связности

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

Картинка с сайта: bisv.ru

Способы изменения размера MTU в Windows 11 и Windows 10

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

1. Используйте команду «ping»:

• Откройте командную строку, нажав Win + R, введите «cmd» и нажмите Enter.
• В командной строке введите следующую команду и нажмите Enter:

  php
ping <адрес_сайта> -f -l <размер_пакета>


  Здесь <адрес_сайта> — это адрес сайта, например, google.com, а <размер_пакета> — это размер пакета данных для проверки MTU. Начните с небольших значений, например, 1472.

• Если вы получите ответ «Превышено время ожидания запроса» (Request Timed Out), уменьшите размер пакета на 10 и повторите попытку. Если получите ответ «Фрагментация потеряна» (Packet needs to be fragmented but DF set), увеличьте размер пакета на 10 и повторите попытку.
• Когда вы найдете максимальный размер пакета без потери данных, добавьте 28 байт (20 байт для заголовка IP и 8 байт для заголовка ICMP), чтобы получить текущий размер MTU.

2. Используйте утилиту «netsh»:

• Откройте командную строку от имени администратора, нажав Win + X и выбрав «Командная строка (администратор)».
• Введите следующую команду и нажмите Enter:

  kotlin
netsh interface ipv4 show subinterfaces


• В выводе найдите ваше сетевое подключение и найдите столбец «MTU». Это и будет текущий размер MTU.

После того как вы определите текущий размер MTU, вы будете готовы приступить к его изменению с помощью соответствующих инструкций, которые мы рассмотрим в следующем разделе.

Включение Jumbo frame

Jumbo frame — это функция сетевых адаптеров, которая позволяет увеличить размер передаваемых пакетов данных за счет увеличения MTU. Включение этой функции может улучшить производительность сети, особенно при передаче больших объемов данных, таких как видео-стриминг или передача файлов. В этом разделе мы рассмотрим, как включить поддержку Jumbo frame в Windows.

1. Проверьте совместимость сетевого оборудования:

• Прежде чем включать Jumbo frame, убедитесь, что ваше сетевое оборудование, включая сетевой адаптер и маршрутизатор, поддерживает эту функцию. Проверьте спецификации вашего оборудования на официальном сайте производителя.

2. Откройте центр управления сетями и общим доступом:

• Нажмите Win + R, введите «ncpa.cpl» и нажмите Enter, чтобы открыть центр управления сетями и общим доступом.

3. Найдите ваше сетевое подключение:

• В открывшемся окне выберите ваше активное сетевое подключение и щелкните правой кнопкой мыши.

4. Откройте свойства сетевого подключения:

• В контекстном меню выберите «Свойства».

5. Измените настройки сетевого адаптера:

• В списке доступных для установки компонентов найдите «Клиент для Microsoft Networks» и «Файл и принтеры Microsoft». Убедитесь, что они установлены и включены.

Картинка с сайта: bisv.ru

6. Включите поддержку Jumbo frame:

• Найдите в списке доступных для установки компонентов «Jumbo frame» и установите его.

7. Примените изменения и перезагрузите компьютер:

• Нажмите «OK», чтобы сохранить изменения, и перезагрузите компьютер, чтобы они вступили в силу.

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

Изменение MTU в командной строке

Изменение MTU (Maximum Transmission Unit — Максимальный размер передаваемого пакета) в операционной системе Windows можно выполнить с помощью командной строки. Этот метод предоставляет пользователю больше гибкости и контроля над настройками сети. В этом разделе мы рассмотрим, как изменить MTU с использованием командной строки в Windows.

1. Откройте командную строку от имени администратора:

• Нажмите Win + X и выберите «Командная строка (администратор)» из контекстного меню.

2. Введите команду для просмотра списка сетевых интерфейсов:

• В командной строке введите следующую команду и нажмите Enter:

  kotlin
netsh interface ipv4 show interfaces


3. Определите ID сетевого интерфейса, который вы хотите настроить:

• В списке интерфейсов найдите тот, который вы хотите настроить, и запомните его ID.

4. Измените MTU с помощью команды netsh:

• В командной строке введите следующую команду, заменив <InterfaceName> на имя вашего сетевого интерфейса и <MTU> на желаемый размер MTU, и нажмите Enter:

  vbnet
netsh interface ipv4 set subinterface "<InterfaceName>" mtu=<MTU> store=persistent


• Например:

  vbnet
netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent


  

  Картинка с сайта: bisv.ru

5. Перезагрузите сетевой адаптер:

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

  vbnet
netsh interface set interface <InterfaceName> admin=disable
netsh interface set interface <InterfaceName> admin=enable


  Здесь <InterfaceName> — это имя вашего сетевого интерфейса.

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

Дополнительная информация

Оптимальный размер MTU (Maximum Transmission Unit — Максимальный размер передаваемого пакета) может значительно влиять на производительность вашего интернет-подключения. В этом разделе мы рассмотрим, как определить оптимальное значение MTU для вашего текущего Интернет-подключения.

1. Используйте утилиту Ping с фрагментацией пакетов:

• Откройте командную строку, нажав Win + R, введите «cmd» и нажмите Enter.
• В командной строке введите следующую команду, заменив <адрес_сайта> на адрес сайта, и нажмите Enter:

  php
ping <адрес_сайта> -f -l <размер_пакета>


• Начните с небольших значений размера пакета, например, 1472. Если получите ответ «Превышено время ожидания запроса» (Request Timed Out), уменьшите размер пакета на 10 и повторите попытку. Если получите ответ «Фрагментация потеряна» (Packet needs to be fragmented but DF set), увеличьте размер пакета на 10 и повторите попытку.
• Когда вы найдете максимальный размер пакета без потери данных, добавьте 28 байт (20 байт для заголовка IP и 8 байт для заголовка ICMP), чтобы получить оптимальное значение MTU.

2. Используйте онлайн-утилиты для проверки MTU:

• Существуют онлайн-утилиты, которые могут помочь вам определить оптимальное значение MTU для вашего интернет-подключения. Они могут выполнить серию тестов и автоматически определить оптимальный размер MTU.

3. Консультируйтесь с вашим провайдером интернет-услуг:

• Ваш провайдер интернет-услуг также может предоставить вам рекомендации относительно оптимального значения MTU для вашего подключения. Обратитесь к ним для получения более точной информации.

Определение оптимального значения MTU для вашего интернет-подключения позволит вам оптимизировать производительность сети и минимизировать потерю данных при передаче.

Привет.

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

Диспозиция

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

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

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

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

Работаем с RSS
Работаем с CTCP
Работаем с NetDMA
Работаем с DCA
Работаем с ECN
Работаем с TCP Timestamps
Работаем с WSH
Работаем с MPP

• Работаем с управлением RWND (autotuninglevel)
• Работаем с Checksum offload IPv4/IPv6/UDP/TCP
• Работаем с Flow Control
• Работаем с Jumbo Frame
• Работаем с AIFS (Adaptive Inter-frame Spacing)
• Работаем с Header Data Split
• Работаем с Dead Gateway Detection

Работаем с управлением 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ГБ.

Как настраивается 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) достаточно простая и древняя. Но это никак не отменяет её эффективность.

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

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

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

Как включить 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 мбит, то данная настройка не будет иметь смысла.

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

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

Есть ли у данной технологии минусы? Есть. Первый – в случае потери кадра из-за обнаружения сбоя в 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 у кадра, добавляете кадр в буфер, а после – идёт специфичная для протокола обработка (выясняется протокол сетевого уровня, выясняется содержимое заголовка и предпринимаются соответствующие действия). Всё логично.

Но вот есть одна проблема. Смотрите. Если Вы приняли, допустим, сегмент 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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\

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

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

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

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

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