CaptureSetup / Offloading
Offloading
Most modern operating systems support some form of network offloading, where some network processing happens on the NIC instead of the CPU. Normally this is a great thing. It can free up resources on the rest of the system and let it handle more connections. If you’re trying to capture traffic it can result in false errors and strange or even missing traffic.
Checksum Offload
On systems that support checksum offloading, IP, TCP, and UDP checksums are calculated on the NIC just before they’re transmitted on the wire. In Wireshark these show up as outgoing packets marked black with red Text and the note [incorrect, should be xxxx (maybe caused by «TCP checksum offload»?)].
Wireshark captures packets before they are sent to the network adapter. It won’t see the correct checksum because it has not been calculated yet. Even worse, most OSes don’t bother initialize this data so you’re probably seeing little chunks of memory that you shouldn’t.
New installations of Wireshark 1.2 and above disable IP, TCP, and UDP checksum validation by default. You can disable checksum validation in each of those dissectors by hand if needed.
If you are experiencing network problems and while trying to figure it out with Wireshark you found these checksum errors, you may have a network card with TCP checksum offload enabled and for some reason the packet is not being fixed by the adapter (NAT, bridge or route redirection is sending the packet to another interface). In this case, you may want to check and disable checksum offload for the adapter, if possible.
Linux
Checksum offloading can be enabled and disabled with the ethtool command.
Or, with some 3Com cards (see 3c59x vortex docs):
Windows
In Windows, go to Control Panel->Network and Internet Connections->Network Connections, right click the connection to change and choose ‘Properties’. Press the ‘Configure. ‘ button, choose the ‘Advanced’ tab to see or modify the «Offload Transmit TCP Checksum» and «Offload Receive TCP Checksum» values.
Segmentation Offload
Some cards can reassemble traffic. This will manifest itself in Wireshark as packets that are larger than expected, such as a 2900-byte packet on a network with a 1500-byte MTU. You can check and change offloading behavior on Linux and Windows using the methods described in the previous section.
This article has a nice explanation on what to do.
TCP Chimney
Chimney offloading lets the NIC handle processing for established TCP connections. On Windows offloaded connections bypass WinPcap, which means that you won’t capture TCP conversations.
See also
Checksums in the Wireshark User’s Guide
KB 912222, The Microsoft Windows Server 2003 Scalable Networking Pack Release
KB 951037, Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008
CaptureSetup/Offloading (последним исправлял пользователь Anders Broman 2013-10-30 12:27:52)
Разгрузка задач контрольной суммы
NDIS поддерживает разгрузку задач контрольной суммы TCP/IP во время выполнения.
Перед разгрузкой вычисления контрольной суммы для пакета TCP, транспорт TCP/IP вычисляет сумму дополнение для TCP псеудохеадер. Транспорт TCP/IP вычисляет сумму дополнения для одного по всем полям в псеудохеадер, включая исходный IP-адрес, IP-адрес назначения, протокол и длину TCP для пакетов TCP. Транспорт TCP/IP вводит сумму дополнения за единицу для псеудохеадер в поле CHECKSUM (контрольная сумма) заголовка TCP.
Сумма дополнения 1 для псеудохеадер, обеспечиваемая транспортом TCP/IP, дает сетевому адаптеру раннее начало для вычисления реальной контрольной суммы TCP для пакета отправки. Чтобы вычислить фактическую контрольную сумму TCP, сетевая карта вычисляет переменную, которая является частью контрольной суммы TCP (для заголовка TCP и полезных данных), добавляет эту контрольную сумму к сумме дополнения до единицы для псеудохеадер, вычисленную транспортом TCP/IP, и вычисляет 16-разрядное дополнение для контрольной суммы. Дополнительные сведения о вычислении таких контрольных сумм см. в документах RFC 793 и RFC 1122.
Транспорт TCP/IP вычисляет сумму дополнения для одного псеудохеадер пакета UDP, выполняя те же действия, что и для пакета TCP, и сохраняет значение в поле CHECKSUM заголовка UDP.
Обратите внимание, что транспортный протокол TCP/IP всегда гарантирует, что поле CHECKSUM в IP-заголовке пакета будет иметь значение 0 перед передачей пакета в базовый драйвер минипорта. Драйвер минипорта должен игнорировать поле CHECKSUM в заголовке IP-адреса. Драйверу минипорта не нужно проверять, что для поля CHECKSUM задано нулевое значение, и не нужно устанавливать это поле в ноль.
После получения структуры NET_BUFFER_LIST в своей функции минипортсенднетбуфферлистс или минипорткосенднетбуфферлистс драйвер минипорта обычно выполняет следующую обработку контрольной суммы:
Драйвер минипорта передает пакет сетевой карте, который вычисляет соответствующие контрольные суммы для пакета. Если у пакета есть и заголовок IP-адреса туннеля, и заголовок транспортного IP-адреса, сетевая карта, поддерживающая разгрузку контрольной суммы IP, выполняет задачи контрольной суммы IP только в заголовке туннеля. Транспорт TCP/IP выполняет задачи контрольной суммы IP-адреса в заголовке транспортного IP-адреса.
Перед указанием структуры NET_BUFFER_LIST для получения пакета, на котором он выполняет задачи контрольной суммы, драйвер минипорта проверяет соответствующие контрольные суммы и устанавливает соответствующие флаги xxxчекксумфаилед или xxxчекксумсукцеедед в структуре NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO.
Отключение разгрузки контрольной суммы адреса, если включена разгрузка большой отправки (LSO), не мешает драйверу минипорта вычислять и вставлять контрольные суммы в пакеты, созданные функцией LSO. Чтобы отключить разгрузку контрольной суммы адреса в этом случае, пользователь должен также отключить LSO.
Hardware Only (HO) features and technologies
Applies to: Windows Server 2022, Windows Server 2019, Azure Stack HCI, versions 21H2 and 20H2
These hardware accelerations improve networking performance in conjunction with the software but are not intimately part of any software feature. Examples of these include Interrupt Moderation, Flow Control, and Receive-side IPv4 Checksum Offload. To learn more, see Host network requirements for Azure Stack HCI.
SH and HO features are available if the installed NIC supports it. The feature descriptions below will cover how to tell if your NIC supports the feature.
Address Checksum Offload
Address checksum offloads are a NIC feature that offloads the calculation of address checksums (IP, TCP, UDP) to the NIC hardware for both send and receive.
On the receive path, the checksum offload calculates the checksums in the IP, TCP, and UDP headers (as appropriate) and indicates to the OS whether the checksums passed, failed, or not checked. If the NIC asserts that the checksums are valid, the OS accepts the packet unchallenged. If the NIC asserts the checksums are invalid or not checked, the IP/TCP/UDP stack internally calculates the checksums again. If the computed checksum fails, the packet gets discarded.
On the send path, the checksum offload calculates and inserts the checksums into the IP, TCP, or UDP header as appropriate.
Disabling checksum offloads on the send path does not disable checksum calculation and insertion for packets sent to the miniport driver using the Large Send Offload (LSO) feature.В To disable all checksum offload calculations, the user must also disable LSO.
Manage Address Checksum Offloads
In the Advanced Properties there are several distinct properties:
IPv4 Checksum Offload
TCP Checksum Offload (IPv4)
TCP Checksum Offload (IPv6)
UDP Checksum Offload (IPv4)
UDP Checksum Offload (IPv6)
By default, these are all always enabled. We recommend always enabling all of these offloads.
The Checksum Offloads can be managed using the Enable-NetAdapterChecksumOffload and Disable-NetAdapterChecksumOffload cmdlets. For example, the following cmdlet enables the TCP (IPv4) and UDP (IPv4) checksum calculations:
Tips on using Address Checksum Offloads
Address Checksum Offloads should ALWAYS be enabled no matter what workload or circumstance. This most basic of all offload technologies always improve your network performance. Checksum offloading is also required for other stateless offloads to work including receive side scaling (RSS), receive segment coalescing (RSC), and large send offload (LSO).
Interrupt Moderation (IM)
IM buffers multiple received packets before interrupting the operating system. When a NIC receives a packet, it starts a timer. When the buffer is full, or the timer expires, whichever comes first, the NIC interrupts the operating system.
Many NICs support more than just on/off for Interrupt Moderation. Most NICs support the concepts of a low, medium, and high rate for IM. The different rates represent shorter or longer timers and appropriate buffer size adjustments to reduce latency (low interrupt moderation) or reduce interrupts (high interrupt moderation).
There is a balance to be struck between reducing interrupts and excessively delaying packet delivery. Generally, packet processing is more efficient with Interrupt Moderation enabled. High performance or low latency applications may need to evaluate the impact of disabling or reducing Interrupt Moderation.
Jumbo frames
Jumbo frames is a NIC and network feature that allows an application to send frames that are much larger than the default 1500 bytes. Typically the limit on jumbo frames is about 9000 bytes but may be smaller.
There were no changes to jumbo frame support in Windows Server 2012 R2.
In Windows Server 2016 there is a new offload: MTU_for_HNV. This new offload works with Jumbo Frame settings to ensure encapsulated traffic doesn’t require segmentation between the host and the adjacent switch. This new feature of the SDN stack has the NIC automatically calculate what MTU to advertise and what MTU to use on the wire. These values for MTU are different if any HNV offload is in use. (In the feature compatibility table, Table 1, MTU_for_HNV would have the same interactions as the HNVv2 offloads have since it is directly related to the HNVv2 offloads.)
Large Send Offload (LSO)
LSO allows an application to pass a large block of data to the NIC, and the NIC breaks the data into packets that fit within the Maximum Transfer Unit (MTU) of the network.
Receive Segment Coalescing (RSC)
Receive Segment Coalescing, also known as Large Receive Offload, is a NIC feature that takes packets that are part of the same stream that arrives between network interrupts and coalesces them into a single packet before delivering them to the operating system. RSC is not available on NICs that are bound to the Hyper-V Virtual Switch. For more information, see Receive Segment Coalescing (RSC).
Только аппаратные функции и технологии
область применения: Windows server 2022, Windows server 2019, Azure Stack хЦи, версии 21H2 и 20H2
Эти аппаратные ускорения улучшают производительность сети в сочетании с программным обеспечением, но не являются частью какой – либо программной функции. к таким примерам относятся контроль прерываний, управление Flow и разгрузка Checksum на стороне приема. Дополнительные сведения см. в разделе требования к сети узла для Azure Stack хЦи.
Функции SH и ПРИНЕС доступны, если установленный сетевой адаптер поддерживает ее. В описании функций ниже рассказывается, как определить, поддерживает ли ваш сетевой адаптер эту функцию.
Разгрузка контрольной суммы адреса
Разгрузка контрольной суммы адресов — это функция сетевого интерфейса, которая позволяет разгрузить вычисление контрольных сумм адресов (IP, TCP, UDP) на СЕТЕВое оборудование для отправки и получения.
На пути получения контрольная сумма разгрузки вычисляет контрольные суммы в заголовках IP, TCP и UDP (соответственно) и указывает операционной системе на то, что контрольные суммы пройдены, не пройдены или не проверены. Если сетевая карта утверждает, что контрольные суммы действительны, операционная система принимает пакет с неправильными вызовами. Если сетевая карта утверждает, что контрольные суммы недействительны или не установлены, стек IP/TCP/UDP внутренне вычисляет контрольные суммы. Если вычисленная контрольная сумма завершается сбоем, пакет удаляется.
На пути отправки контрольная сумма разгрузка вычисляет и вставляет контрольные суммы в заголовок IP, TCP или UDP соответствующим образом.
Отключение разгрузок контрольной суммы для пути отправки не отключает вычисление контрольной суммы и вставку пакетов, отправляемых драйверу минипорта, с помощью функции разгрузки большой отправки (LSO). Чтобы отключить все вычисления для разгрузки контрольной суммы, пользователь должен также отключить LSO.
Управление разгрузкой контрольной суммы адреса
В дополнительных свойствах есть несколько различных свойств:
Разгрузка контрольной суммы IPv4
Разгрузка контрольной суммы TCP (IPv4)
Разгрузка контрольной суммы TCP (IPv6)
Разгрузка контрольной суммы UDP (IPv4)
Разгрузка контрольной суммы UDP (IPv6)
По умолчанию все они включены всегда. Рекомендуется всегда включать все эти разгрузки.
Разгрузкой контрольной суммы можно управлять с помощью командлетов Enable-NetAdapterChecksumOffload и Disable-NetAdapterChecksumOffload. Например, следующий командлет включает вычисления контрольной суммы TCP (IPv4) и UDP (IPv4):
Советы с использованием разгрузок контрольной суммы адреса
Разгрузка контрольной суммы адреса должна всегда включаться независимо от рабочей нагрузки или обстоятельств. Эта основная часть всех технологий разгрузки всегда повышает производительность сети. Разгрузка контрольной суммы также требуется для выполнения других разгрузок без отслеживания состояния, включая масштабирование на стороне приема (RSS), получение сегментов (RSC) и разгрузку большой отправки (LSO).
Контроль прерываний (IM)
Перед прерыванием операционной системы IM отправляет в буфер несколько полученных пакетов. Когда сетевой адаптер получает пакет, он запускает таймер. Когда буфер полон или срок действия таймера истекает, в зависимости от того, какой из них первым, сетевая карта прерывает работу операционной системы.
Многие сетевые адаптеры поддерживают не только включение/отключение для контроля прерываний. Большинство сетевых адаптеров поддерживают основные понятия, связанные с низким, средним и высоким уровнем скорости обмена мгновенными сообщениями. Разные тарифы представляют более короткие и более длинные таймеры и соответствующие изменения размера буфера, позволяющие сократить задержку (с низким уровнем прерывания) или уменьшить количество прерываний (высокий уровень прерывания).
Существует баланс между уменьшением количества прерываний и чрезмерной задержкой доставки пакетов. Как правило, обработка пакетов более эффективна благодаря включению поддержки прерываний. Для приложений с высокой производительностью или низкой задержкой может потребоваться оценить влияние отключения или снижения контроля прерываний.
Кадры крупного размера
Кадры крупных размеров — это сетевой интерфейс и сетевая функция, позволяющая приложению передавать кадры, размер которых значительно превышает 1500 байт по умолчанию. Обычно ограничение на большие кадры составляет около 9000 байт, но может быть меньше.
в Windows Server 2012 R2 не было изменений в поддержке кадров крупного размера.
в Windows Server 2016 имеется новая разгрузка: MTU_for_HNV. Эта новая разгрузка работает с крупными параметрами кадров, чтобы гарантировать, что инкапсулированный трафик не требует сегментации между узлом и соседним коммутатором. В этой новой функции в стеке SDN сетевой адаптер автоматически вычисляет значение MTU для объявления и значение MTU, которое будет использоваться при передаче данных. Эти значения для параметра MTU различаются, если используется разгрузка HNV. (В таблице «совместимость функций» Таблица 1 MTU_for_HNV будет иметь те же взаимодействия, что и разгрузки HNVv2, так как она напрямую связана с разгрузкой HNVv2.)
с разгрузкой большой отправки (LSO);
LSO позволяет приложению передать большой блок данных в сетевую карту, и сетевая карта разбивает данные на пакеты, которые соответствуют максимальной единице передачи (MTU) сети.
Receive Segment Coalescing (RSC)
Объединение сегментов, называемое также «крупной разгрузкой», — это сетевая карта, которая принимает пакеты, входящие в тот же поток, который приходит между сетевыми прерываниями, и объединяет их в один пакет, прежде чем доставлять их в операционную систему. RSC недоступен на сетевых адаптерах, привязанных к виртуальному коммутатору Hyper-V. Дополнительные сведения см. в статье Объединение сегментов приема (RSC).
Тонкая настройка сетевого стека на 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, где описывается обходной способ. Почему мало? Потому что настройка этого окна по умолчанию такова:
Примечание: Речь о номинальной скорости, т.е. по информации с интерфейса в момент его инициализации, а не о фактической, которая может быть и ощутимо ниже.
Способ обхода, предлагаемый в RFC 1323, прост и красив. Два хоста, ставящих TCP-сессию, согласовывают друг с другом параметр, который является количеством бит, на которые будет сдвинуто значение поля windows size. То есть, если они согласуют этот параметр равный 2, то оба из них будут читать это поле сдвинутым “влево” на 2 бита, что даст увеличение параметра в 2^2=4 раза. И, допустим, значение этого поля в 64К превратится в 256К. Если согласуют 5 – то поле будет сдвинуто “влево” на 5 бит, и 64К превратится в 2МБ. Максимальный поддерживаемый Windows порог этого значения (scaling) – 14, что даёт максимальный размер окна в 1ГБ.
Примечание: Как понятно, всё это не будет работать без включения поддержки RFC 1323 (см. предыдущую статью).
Как настраивается RWND в Windows
Существующие варианты настройки этого параметра таковы:
Ещё раз – если Вы включите 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КБ кадра превратится в каскад проблем, согласований и выяснений, на которые будет затрачено много времени и куда как больше трафика, чем если бы потери удалось избежать.
Примечание: Работает это всё только поверх 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 достаточно проста – увеличить максимальный размер кадра. Это повлечёт огромное количество плюсов:
Данная технология реализуема только на интерфейсах со скоростями 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 уменьшает это значение до:
Как понятно, чисто технически уменьшать это значение до чисел менее 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К данных, то, по сути, последовательность действий будет такая (вкратце):
Заметили проблему? Она проста. Каждый слой читает свой заголовок, который исчисляется в байтах, а тащит ради этого путём копирования весь пакет.
Технология 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-подключений.
Когда такое происходит для более чем 25% соединений (у нас их 10, значит, когда такое случится с 3 из них), то IP-стек меняет шлюз по-умолчанию. Уже не для конкретного TCP-соединения, а просто – для всей системы. Счётчик количества “сбойных” соединений сбрасывается на нуль и всё готово к продолжению.
Примечание: Если шлюз последний, и ниже его в списке никого нет, опять берётся первый.
Как настроить Dead Gateway Detection в Windows
Для настройки данного параметра нужно управлять тремя значениями в реестре, находящимися в ключе:
Все они имеют тип 32bit DWORD и следующую логику настройки:
Вместо заключения
Сетевых настроек – много. Знать их необходимо, чтобы не делать лишнюю работу, не ставить лишний софт, который кричит об “уникальных возможностях”, которые, на самом деле, встроены в операционную систему, не разрабатывать дурацкие архитектурные решения, базирующиеся на незнании матчасти архитектором, и в силу множества других причин. В конце концов, это интересно.
Если как-нибудь дойдут руки – будет новая часть статьи.
