Кадры ethernet размер поля данных которых может достигать 9000 байт

Обновлено: 25.01.2025

Несмотря на наличие стандарта, кадры Ethernet отличаются друг от друга своим форматом. Как и на производстве, кадры в сети Ethernet решают все. Они служат вместилищем для всех высокоуровневых пакетов, поэтому

Несмотря на наличие стандарта, кадры Ethernet отличаются друг от друга своим форматом.

Как и на производстве, кадры в сети Ethernet решают все. Они служат вместилищем для всех высокоуровневых пакетов, поэтому, чтобы понять друг друга, отправитель и получатель должны использовать один и тот же тип кадров Ethernet. К счастью (или к сожалению), кадры могут быть всего четырех разных форматов, и к тому же не сильно отличающихся друг от друга. Более того, базовых форматов кадров существует всего два (в английской терминологии их называют "raw formats") - Ethernet_II и Ethernet_802.3, причем они отличаются назначением всего одного поля.

Современные компьютерные сети гетерогенны по своей природе, а сетевые протоколы третьего уровня используют зачастую разные типы кадров Ethernet. Так, в старых версиях NetWare 3.х компании Novell базовым форматом по умолчанию является Ethernet_802.3, а не 802.2 или SNAP, как это предусмотрено стандартами IEEE, причем, кроме нее, этот формат больше никто не применяет. С выходом NetWare 4.х протоколы IPX/SPX используют по умолчанию стандартные кадры Ethernet_802.2, а с планируемым переводом IntranetWare на протоколы TCP/IP эта сетевая ОС будет, возможно, работать по умолчанию с кадрами Ethernet_SNAP, так как именно этот формат применяется в новейших реализациях TCP/IP. Вообще говоря, пакеты протоколов IPX/SPX могут передаваться с помощью кадров любых типов, поэтому - а также потому, что тип Ethernet_802.3 используется исключительно Novell, - в этом уроке мы будем рассматривать кадры Ethernet преимущественно с точки зрения сетей NetWare.

ETHERNET II

Несмотря на то что мы привычно называем стандарт 802.3 именем Ethernet, это не совсем правильно, так как последнее название является торговой маркой Xerox, Intel и Digital, чья технология послужила прототипом этого столь популярного стандарта. Формат Ethernet_II соответствует оригинальному формату кадров Ethernet и имеет следующий вид.

Как и всякий кадр, Ethernet_II начинается с семибайтной преамбулы, состоящей из чередующихся единиц и нулей, и однобайтного начального ограничителя кадра, в котором два младших бита равны 112, а не 102, как остальные биты в преамбуле и ограничителе. Однако, если быть более точным, в Ethernet_II преамбула не разделяется на собственно преамбулу и начальный ограничитель кадра - и это является одним из отличий Ethernet от IEEE 802.3, хотя весьма несущественным, можно сказать, схоластическим, тем более что очень часто преамбула вообще рассматривается как часть физического механизма синхронизации передающей и принимающей стороны, а не как часть кадра (поэтому на рисунках мы не будет обозначать преамбулу и начальный ограничитель).

Собственно заголовок кадра состоит из шестибайтного поля адреса получателя (Destination Address), шестибайтного поля адреса отправителя (Source Address) и двухбайтного поля типа протокола (Frame Type) (см. Рисунок 1). При передаче каждого байта адреса младшие биты (крайние справа) передаются первыми. В адресе получателя первый передаваемый бит (бит 0 байта 0) указывает тип адреса - обычный или групповой. Таким образом, нечетный первый байт адреса получателя означает, что кадр предназначен группе станций. Разновидностью многоадресной передачи является широковещательная передача. В этом случае все биты адреса получателя задаются равными 1.

Рисунок 1.
Базовые пакеты Ethernet II и IEEE 802.3 имеют одинаковую структуру. Их различие - в назначении 13-го и 14-го байтов: поля типа протокола и длины кадра соответственно. Совместное использование разных форматов кадров в одном сегменте Ethernet возможно благодаря тому, что тип протокола характеризуется числом, большим 0x05FE.

Однако поле адреса отправителя должно содержать адрес конкретной станции-отправителя.

В случае обычных адресов первые три байта служат для идентификации производителя сетевой платы, а последние три байта составляют уникальный номер конкретной платы. Так, первые три байта адреса популярных сетевых плат производства 3Com выражаются следующим числом - 02608С в шестнадцатеричной системе счисления (далее для обозначения чисел в шестнадцатеричной системе счисления мы будем использовать обозначение 0x, т. е. идентификатор 3Com будет иметь вид 0x02608C). Адрес получателя называется также физическим или MAC-адресом.

Вообще говоря, адрес получателя идентифицирует непосредственного, а не конечного получателя, например маршрутизатор в сети Ethernet. Конечный получатель идентифицируется с помощью высокоуровневых протоколов. В случае TCP/IP - это IP-адрес станции и TCP- или UDP-порт процесса на данной станции.

Поле типа протокола идентифицирует высокоуровневый протокол, такой как IP, AppleTalk и т. д., контейнером для пакета которого служит кадр. Ниже мы приводим значения поля типа протокола для некоторых распространенных сетевых протоколов:

Internet Protocol (IP) - 0x0800; Address Resolution Protocol (ARP) - 0x0806; AppleTalk - 0x809B; Xerox Network System (XNS) - 0x0600; NetWare IPX/SPX - 0x8137.

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

В отличие от служебных полей, поле данных имеет переменную длину, причем оно не может быть короче 46 байт и длиннее 1500 байт. Таким образом, общая длина кадра без учета преамбулы и начального ограничителя кадра находится в диапазоне от 64 до 1518 байт. В случае, когда реальный объем передаваемых данных меньше 46 байт (например, для эмуляции терминала часто передается всего один символ, вводимый с клавиатуры), поле данных дополняется до минимального размера заполнителем. Байт заполнения может вставляться, даже если объем передаваемых данных более 46 байт. По предложению Novell, в случае нечетного количества байт драйвер сетевой платы добавляет еще один. Это сделано потому, что некоторые старые маршрутизаторы не понимают кадры нечетной длины.

Последнее поле в кадре - это четырехбайтное поле контрольной последовательности кадра (Frame Check Sequence, FCS). Значение этого поля вычисляется на основе содержимого заголовка и данных (вместе с заполнителем, но без учета преамбулы и ограничителя) с помощью 32-разрядного циклического избыточного кода (Cyclic Redundancy Code, CRC-32) по следующей формуле (в двоичной системе счисления):

контрольная последовательность = MOD(данные/полином)

После приема кадра принимающая станция заново вычисляет контрольную последовательность и сравнивает полученный результат с содержимым поля FCS. В случае несовпадения пакет считается испорченным и игнорируется.

БАЗОВЫЙ ФОРМАТ КАДРА 802.3

Определяемый спецификацией 802.3 формат кадра практически идентичен своему предшественнику за исключением того, что поле типа протокола имеет смысл длины кадра. На первый взгляд это неизбежно должно привести к путанице, когда кадры Ethernet_II и Ethernet_802.3 передаются между станциями в одном сегменте. Однако на практике эти кадры не представляет труда отличить друг от друга. Как мы уже говорили, длина поля данных не превышает 1500 байт, поэтому, в соответствии с принятыми соглашениями, тип высокоуровневого протокола задается большим, чем 0х05FE (1518 в шестнадцатеричной системе счисления - полная длина кадра), благо двухбайтное поле может принимать 65 536 разных значений. Таким образом, если значение поля между адресом отправителя и данными меньше или равно 1518, то это кадр 802.3, в противном случае - это кадр Ethernet_II.

Другое небольшое отличие между Ethernet и 802.3 состоит в классификации групповых адресов. В отличие от Ethernet, спецификация 802.3 подразделяет групповые адреса на имеющие глобальное и локальное значение. Однако это разделение редко используется на практике. (О третьем незначительном отличии - в преамбуле - мы говорили выше.)

В соответствии с эталонной моделью OSI, каждый протокольный блок данных содержит (инкапсулирует) пакеты вышележащих протоколов своего стека. Протокол 802.3 описывает метод доступа к среде передачи - нижний подуровень канального уровня, и для него вышележащим протоколом является протокол логического

управления каналом (Logical Link Control, LLC) - верхний подуровень канального уровня. Таким образом, согласно требованиям стандарта, поле данных должно содержать заголовок LLC. В ранних версиях NetWare компания Novell проигнорировала этот заголовок и стала помещать пакеты IPX/SPX непосредственно за полем длины кадра, и поле данных начиналось так же, как и обычный заголовок IPX, с двух байтов, состоящих из единиц (число 0xFFFF). Иными словами, Novell использовала кадры просто в качестве контейнера.

В принципе применение базового формата кадра 802.3 без служебной информации верхнего подуровня канального уровня позволяет Novell несколько сократить накладные расходы в расчете на кадр. Однако выигрыш невелик, а в гетерогенной среде применение нестандартного формата ведет к проигрышу, так как маршрутизатор или сетевая плата вынуждены проверять дополнительные поля для определения типа пакета. Это послужило одним из побудительных мотивов, почему начиная с версии 4.0 Novell перешла по умолчанию на стандартный формат Ethernet_802.2. Другой причиной было то, что использование базовых кадров Ethernet_802.3 делало невозможным применение таких опций защиты, как подпись пакетов, из-за того, что поле контрольной суммы пакета было фиксированным и равным 0хFFFF, чтобы кадр Ethernet_802.3 можно было отличить от других типов кадров.

ДВА СТАНДАРТНЫХ ФОРМАТА

Спецификации IEEE предусматривают всего два стандартных формата - 802.2 и 802.2 SNAP, причем второй является естественным расширением первого. Как уже говорилось, стандартный кадр должен содержать в поле данных служебную информацию логического управления каналом, а именно однобайтное поле точки доступа к сервису для получателя (Destination Service Access Point, DSAP), однобайтное поле точки доступа к сервису для отправителя (Source Service Access Point, SSAP) и однобайтное управляющее поле (см. Рисунок 2). Назначением номеров точек доступа к сервису (Service Access Point, SAP) занимается IEEE, и он выделил следующие номера:

Рисунок 2.
Формат IEEE 802.2 SNAP представляет собой расширение стандартного формата IEEE 802.2. Кадры обоих типов содержат заголовок 802.2 LLC в начале поля данных.

Поля DSAP и SSAP служат для определения вышележащего протокола и, как правило, содержат одно и то же значение. Управляющее поле обычно задается равным 0x03 (в соответствии с протоколом LLC это означает, что соединение на канальном уровне не устанавливается).

Протокол доступа к подсети (Sub-Network Access Protocol, SNAP) был разработан с целью увеличения числа поддерживаемых протоколов, так как однобайтные поля SAP позволяют поддерживать не более 256 протоколов. Формат Ethernet_SNAP предусматривает дополнительное пятибайтное поле для идентификации протокола (Protocol Identification, PI) внутри поля данных, причем значения двух последних байтов этого поля совпадают со значениями поля протокола в Ethernet_II в случае, если кадры содержат пакеты одного и того же высокоуровневого протокола, например они равны 0x8137 для NetWare.

АЛГОРИТМ ОПРЕДЕЛЕНИЯ ФОРМАТА КАДРА

Отличить один формат кадра Ethernet от другого не представляет большого труда, и сделать это можно с помощью следующего простого алгоритма (см. Рисунок 3). Сначала драйвер должен проверить значение поля типа протокола/длины кадра (13-й и 14-й байты в заголовке). Если записанное там значение превышает 0x05FE (максимально возможная длина кадра), то это кадр Ethernet_II.

Рисунок 3.
Для определения типа кадра Ethernet сначала необходимо проверить значение поля после адреса отправителя, а затем первых двух байтов поля данных.

Если нет, следует продолжить проверку. Если первые два байта равны 0xFFFF, то это формат Ethernet_802.3 для NetWare 3.х. В противном случае это стандартный формат кадра 802.2, и нам остается только выяснить, какой из двух - обычный (Ethernet_802.2) или расширенный (Ether-net_SNAP). В случае Ethernet_SNAP значение первого, впрочем, как и второго, байта в поле данных равняется 0xAA. (Значение третьего байта равняется 0x03, но это проверять излишне.)

ЗА КАДРОМ

Разные протоколы используют разные форматы кадров (см. Таблицу 1). Однако число последних не так уж велико, и их несложно отличить один от другого. К тому же протокол TCP/IP выдвигается на доминирующую позицию не только в глобальных, но и в локальных сетях, поэтому даже Novell решила отказаться от своего протокола IPX/SPX в пользу TCP/IP в следующей версии NetWare. Это означает, что в большинстве случаев администратору сети не придется беспокоиться о том, какой формат кадров Ethernet используется. Однако, как показывает опыт, унаследованные технологии живут довольно долго, так что знание форматов кадров может представлять не только теоретический, но и практический интерес.

Стандарт на технологию Ethernet, описанный в документе 802.3, дает описание единственного формата кадра МАС-уровня. Так как в кадр МАС-уровня должен вкладываться кадр уровня LLC, описанный в документе 802.2, то по стандартам IEEE в сети Ethernet может использоваться только единственный вариант кадра канального уровня, образованный комбинацией заголовков МАС и LLC подуровней. Тем не менее, на практике в сетях Ethernet на канальном уровне используются заголовки 4-х типов. Это связано с длительной историей развития технологии Ethernet до принятия стандартов IEEE 802, когда подуровень LLC не выделялся из общего протокола и, соответственно, заголовок LLC не применялся. Затем, после принятия стандартов IEEE и появления двух несовместимых форматов кадров канального уровня, была сделана попытка приведения этих форматов к некоторому общему знаменателю, что привело еще к одному варианту кадра.

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

Кадр 802.3/LLC (или кадр Novell 802.2)
Кадр Raw 802.3 (или кадр Novell 802.3)
Кадр Ethernet DIX (или кадр Ethernet II)
Кадр Ethernet SNAP

Заголовок кадра 802.3/LLC является результатом объединения полей заголовков кадров, определенных в стандартах 802.3 и 802.2.

Поле преамбулы состоит из семи байтов синхронизирующих данных. Каждый байт содержит одну и ту же последовательность битов - 10101010. При манчестерском кодировании эта комбинация представляется в физической среде периодическим волновым сигналом. Преамбула используется для того, чтобы дать время и возможность схемам приемопередатчиков (transceiver) прийти в устойчивый синхронизм с принимаемыми тактовыми сигналами.
Начальный ограничитель кадра состоит из одного байта с набором битов 10101011. Появление этой комбинации является указанием на предстоящий прием кадра.
Адрес получателя - может быть длиной 2 или 6 байтов (MAC-адрес получателя). Первый бит адреса получателя - это признак того, является адрес индивидуальным или групповым: если 0, то адрес указывает на определенную станцию, если 1, то это групповой адрес нескольких (возможно всех) станций сети. При широковещательной адресации все биты поля адреса устанавливаются в 1. Общепринятым является использование 6-байтовых адресов.
Адрес отправителя - 2-х или 6-ти байтовое поле, содержащее адрес станции отправителя. Первый бит - всегда имеет значение 0.
Двухбайтовое поле длины определяет длину поля данных в кадре.
Поле данных может содержать от 0 до 1500 байт. Но если длина поля меньше 46 байт, то используется следующее поле - поле заполнения, чтобы дополнить кадр до минимально допустимой длины.
Поле заполнения состоит из такого количества байтов заполнителей, которое обеспечивает определенную минимальную длину поля данных (46 байт). Это обеспечивает корректную работу механизма обнаружения коллизий. Если длина поля данных достаточна, то поле заполнения в кадре не появляется.
Поле контрольной суммы - 4 байта, содержащие значение, которое вычисляется по определенному алгоритму (полиному CRC-32). После получения кадра рабочая станция выполняет собственное вычисление контрольной суммы для этого кадра, сравнивает полученное значение со значением поля контрольной суммы и, таким образом, определяет, не искажен ли полученный кадр.

Кадр 802.3 является кадром MAС-подуровня, в соответствии со стандартом 802.2 в его поле данных вкладывается кадр подуровня LLC с удаленными флагами начала и конца кадра. Формат кадра LLC был описан выше.

Результирующий кадр 802.3/LLC изображен в левой части рисунка 4. Так как кадр LLC имеет заголовок длиной 3 байта, то максимальный размер поля данных уменьшается до 1497 байт.

Рис.4. Форматы кадров Ethernet

Справа на этом рисунке приведен кадр, который называют кадром Raw 802.3 (то есть "грубый" вариант 802.3) или же кадром Novell 802.3. Из рисунка видно, что это кадр MAC-подуровня стандарта 802.3, но без вложенного кадра подуровня LLC. Компания Novell долгое время не использовала служебные поля кадра LLC в своей операционной системе NetWare из-за отсутствия необходимости идентифицировать тип информации, вложенной в поле данных - там всегда находился пакет протокола IPX, долгое время бывшего единственным протоколом сетевого уровня в ОС NetWare.

Теперь, когда необходимость идентификации протокола верхнего уровня появилась, компания Novell стала использовать возможность инкапсуляции в кадр MAC-подуровня кадра LLC, то есть использовать стандартные кадры 802.3/LLC. Такой кадр компания обозначает теперь в своих операционных системах как кадр 802.2, хотя он является комбинацией заголовков 802.3 и 802.2.

Кадр стандарта Ethernet DIX, называемый также кадром Ethernet II, похож на кадр Raw 802.3 тем, что он также не использует заголовки подуровня LLC, но отличается тем, что на месте поля длины в нем определено поле типа протокола (поле Type). Это поле предназначено для тех же целей, что и поля DSAP и SSAP кадра LLC - для указания типа протокола верхнего уровня, вложившего свой пакет в поле данных этого кадра. Для кодирования типа протокола используются значения, превышающие значение максимальной длины поля данных, равное 1500, поэтому кадры Ethernet II и 802.3 легко различимы.

Еще одним популярным форматом кадра является кадр Ethernet SNAP (SNAP - SubNetwork Access Protocol, протокол доступа к подсетям). Кадр Ethernet SNAP определен в стандарте 802.2H и представляет собой расширение кадра 802.3 путем введения дополнительного поля идентификатора организации, которое может использоваться для ограничения доступа к сети компьютеров других организаций.

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

В компьютерной сети , большие кадры являются Ethernet кадры с более чем 1500 байт полезной нагрузки, предел , установленный в IEEE 802.3 стандарта. Обычно jumbo-кадры могут содержать до 9000 байтов полезной нагрузки, но существуют все меньшие и большие вариации, и с этим термином следует проявлять некоторую осторожность. Многие Gigabit Ethernet коммутаторы и Gigabit Ethernet контроллеров сетевого интерфейса и некоторые Fast Ethernet коммутаторы и карты Fast Ethernet сетевого интерфейса может поддерживать большие кадры.

СОДЕРЖАНИЕ

Зарождение

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

Первоначальную известность Jumbo-фреймы приобрели в 1998 году, когда Alteon WebSystems представила их в своих адаптерах ACEnic Gigabit Ethernet . Многие другие производители также приняли этот размер; однако кадры большого размера не являются частью официального стандарта IEEE 802.3 Ethernet.

Принятие

Jumbo-кадры могут снизить накладные расходы и циклы ЦП, а также положительно повлиять на сквозную производительность TCP. Наличие кадров большого размера может отрицательно сказаться на задержке в сети, особенно на каналах с низкой пропускной способностью. Размер кадра, используемый при сквозном соединении, обычно ограничивается наименьшим размером кадра в промежуточных звеньях. 802.5 Token Ring может поддерживать кадры с размером MTU 4464 байта , FDDI может транспортировать 4352 байта, ATM - 9180 байтов, а 802.11 может передавать 7935 байтов MTU. Стандарт IEEE 802.3 Ethernet первоначально предусматривал поддержку 1500-байтовых кадров MTU, общий размер кадра 1518 байтов (1522 байта с дополнительным тегом IEEE 802.1Q VLAN / QoS ). Обновление IEEE 802.3as включает в себя несколько общих заголовков, трейлеров и инкапсуляций, создавая концепцию конверта, в который может быть включено до 482 байтов заголовка и трейлера, а самый большой кадр Ethernet, поддерживаемый IEEE 802.3, стал 2000 байтов.

Использование 9000 байтов в качестве предпочтительного размера полезной нагрузки для jumbo-кадров явилось результатом обсуждений в Объединенной инженерной группе Internet2 и в сетях федерального правительства США. Их рекомендация была принята всеми другими национальными исследовательскими и образовательными сетями. Чтобы соответствовать этому обязательному критерию закупки, производители, в свою очередь, приняли 9000 байт в качестве обычного размера MTU с размером кадра jumbo не менее 9018/9022 байта (без / с полем IEEE 802.1Q). Большая часть оборудования Ethernet может поддерживать кадры большого размера до 9216 байт.

IEEE 802.1AB -2009 и IEEE 802.3bc -2009 добавили обнаружение LLDP в стандартный Ethernet для максимальной длины кадра ( подтип TLV 4). Это позволяет определять длину кадра на порту по двухоктетному полю. В соответствии с IEEE 802.3-2015 допустимые значения: 1518 (только базовые кадры), 1522 (кадры с тегами 802.1Q) и 2000 (кадры с несколькими тегами, огибающие).

Обнаружение ошибок

Простые аддитивные контрольные суммы, содержащиеся в протоколах UDP и TCP , оказались неэффективными при обнаружении битовых ошибок, специфичных для шины, потому что при простом суммировании эти ошибки имеют тенденцию к самоподавлению. Перед принятием RFC 3309 тестирование с моделированием внедрения ошибок по сравнению с реальными данными показало, что до 2% этих ошибок не обнаруживаются.

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

Один из подходов IETF для принятия jumbo-кадров позволяет избежать снижения целостности данных служебного блока данных за счет выполнения дополнительной CRC на следующем уровне сетевого протокола выше Ethernet. Протокол передачи управления потоком (SCTP) (RFC 4960) и iSCSI (RFC 7143) используют полином CRC Кастаньоли . Полином Кастаньоли 0x1EDC6F41 достигает расстояния Хэмминга HD = 6 сверх одного Ethernet MTU (до длины слова данных 16 360 бит) и HD = от 4 до 114 663 бит, что более чем в 9 раз превышает длину MTU Ethernet. Это дает два дополнительных бита способности обнаружения ошибок в словах данных размером MTU по сравнению со стандартным полиномом CRC Ethernet, не жертвуя при этом возможностью HD = 4 для слов данных размером до 72 кбит и выше. Поддержка полинома CRC Кастаньоли в транспорте общего назначения, предназначенном для обработки фрагментов данных, и в транспорте TCP, предназначенном для передачи данных SCSI, оба обеспечивают повышенную частоту обнаружения ошибок, несмотря на использование больших кадров, в которых увеличение MTU Ethernet в противном случае привело бы к привело к значительному сокращению обнаружения ошибок.

Конфигурация

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

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

Эффективность полосы пропускания

Jumbo-кадры могут повысить эффективность обработки Ethernet и сети на узлах за счет уменьшения накладных расходов протокола , как показано в следующем примере с TCP через IPv4 . Обработки накладных хозяев потенциально может снизить отношением размеров полезной нагрузки (примерно в шесть раз улучшение в этом примере). Насколько это важно, зависит от того, как пакеты обрабатываются на хосте. Хосты, использующие механизм разгрузки TCP , получат меньше преимуществ, чем хосты, обрабатывающие кадры с помощью своего ЦП.

Эффективность полосы пропускания на уровне кадра

Тип кадра	MTU	Накладные расходы уровня 1		Накладные расходы уровня 2		Накладные расходы уровня 3	Накладные расходы уровня 4	Размер полезной нагрузки	Всего передано	Эффективность
Стандарт	1500	преамбула 8 байт	IPG 12 байт	заголовок кадра 14 байт	FCS 4 байта	Заголовок IPv4 20 байт	Заголовок TCP 20 байт	1460 байт	1538 байт	94,93%
Джамбо	9000	преамбула 8 байт	IPG 12 байт	заголовок кадра 14 байт	FCS 4 байта	Заголовок IPv4 20 байт	Заголовок TCP 20 байт	8960 байт	9038 байт	99,14%
Другие размеры кадров для справки
IEEE 802.11	7935	Преамбула и заголовок PLCP 24 байта	IPG варьируется	заголовок кадра и безопасность ovhd 52 байта	FCS 4 байта	Заголовок IPv4 20 байт	Заголовок TCP 20 байт	7895 байт	8015 байт + размер IPG	<98,5%
IEEE 802.11 с подключением к Ethernet	1500	Преамбула и заголовок PLCP 24 байта	IPG варьируется	заголовок кадра и безопасность ovhd 52 байта	FCS 4 байта	Заголовок IPv4 20 байт	Заголовок TCP 20 байт	1460 байт	1580 байт + размер IPG	<92,4%

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

Детские гигантские рамки

Детские гигантские или детские jumbo- кадры - это кадры Ethernet, которые лишь немного больше, чем разрешено стандартами IEEE Ethernet. Например, для IP / MPLS через Ethernet требуются фреймы-гиганты для предоставления услуг Ethernet со стандартной полезной нагрузкой 1500 байт. Для большинства реализаций потребуется инкапсуляция пользовательских кадров, не являющихся jumbo, в формат кадра MPLS, который, в свою очередь, может быть инкапсулирован в соответствующий формат кадра Ethernet со значениями EtherType 0x8847 и 0x8848. Повышенная нагрузка на дополнительные заголовки MPLS и Ethernet означает, что в сетях Carrier Ethernet требуется поддержка кадров размером до 1600 байт .

Супер большие кадры

Super Jumbo- кадры (SJF) - это кадры, размер полезной нагрузки которых превышает 9000 байт. Поскольку это был относительно сложный и довольно длительный процесс увеличения MTU пути высокопроизводительных национальных исследовательских и образовательных сетей с 1500 байтов до 9000 байтов или около того, рассматривается последующее увеличение, возможно, до 64000 байтов. Основным фактором, связанным с увеличением максимального размера сегмента (MSS), является увеличение размера доступного буфера памяти в каждом промежуточном механизме сохранения на пути.

Альтернативный подход

Большая разгрузка отправки и большая разгрузка приема-разгрузки по кадрам, благодаря чему загрузка ЦП в значительной степени не зависит от размера кадра. Это еще один способ устранить накладные расходы на пакеты, для уменьшения которых были разработаны большие кадры. Jumbo-кадры по-прежнему полезны с точки зрения полосы пропускания, поскольку они уменьшают объем полосы пропускания, используемый для служебных данных, не связанных с данными.

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

У них также есть некоторые серьезные ограничения и недостатки, потому что они нарушают стандарт Ethernet. Если вы планируете внедрять Jumbo Frames, важно сначала выполнить домашнее задание.

Фреймы Ethernet

Прежде чем вы сможете понять Jumbo Frames, вы должны иметь представление о том, что такое Ethernet Frames. Таким образом, кадры Ethernet буквально выделяют данные, передаваемые в пакетах Ethernet. Все Ethernet-фреймы имеют одинаковые основные части.

Эта структура имеет решающее значение для сотрудничества между устройствами. Оно должно быть распознаваемым для любого устройства Ethernet для передачи и понимания данных. Каждый кадр Ethernet начинается с преамбулы. Сетевые устройства используют преамбулу, чтобы дифференцировать кадр, чтобы синхронизировать передачу кадра.

В конце преамбулы находится разделитель начального кадра (SFD). SFD предназначен для отделения преамбулы от фактической структуры кадра Ethernet.

Сразу после SFD идет MAC-адрес назначения, за которым непосредственно следует MAC-адрес источника. Конечно, это важно для обеспечения того, чтобы пакет попал туда, куда ему нужно, и чтобы ответ мог быть отправлен. Следующая часть присутствует только в конфигурации VLAN. Он содержит информацию о VLAN.

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

Его размер может изменяться, но максимальный размер сети определяет максимальный размер передаваемого блока (MTU). Стандарт Ethernet устанавливает MTU на 1500 байтов.

Наконец, концом кадра Ethernet является последовательность проверки кадра (FCS). Это циклическая проверка избыточности (CRC), которая позволяет получателю кадра проверять отсутствующие или поврежденные данные.

Что делает их Джамбо?

Итак, почему Jumbo Frames Jumbo? Они несут гораздо большую полезную нагрузку, чем обычные кадры Ethernet. Вместо обычных 1500 байт, Jumbo Frames может загружать до 9000 байт. Эти значительно большие кадры могут нести в шесть раз больше данных, чем стандартные кадры. Теоретически, вы можете уменьшить количество пакетов, передаваемых в вашей сети, до одной шестой стандартной скорости при идеальных условиях.

Зачем идти Джамбо?

Вы уже увидели причины использования Jumbo Frames в своей сети. Теперь пришло время погрузиться глубже и разобраться в основных причинах выбора Jumbo Frames.

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

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

Таким образом, меньшее количество полезных нагрузок создает меньшую нагрузку на сетевое оборудование, чем множество мелких полезных нагрузок.

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

В чем подвох?

Jumbo Frames не идеальны. Есть несколько очень явных недостатков при их реализации в вашей сети.

Прежде всего, вам нужно оборудование, которое поддерживает Jumbo Frames. Теперь, это обычно не проблема в корпоративных средах, но это все еще вопрос. Все ваше сетевое оборудование должно поддерживать Jumbo Frames.

Обычно это означает, что скорость должна быть не менее гигабитной. Вы также должны явно настроить его для работы с Jumbo Frames. Если какой-то фрагмент в цепочке не поддерживает Jumbo Frames, он фрагментирует кадры.

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

Вам нужны не только маршрутизаторы и коммутаторы. Сетевые интерфейсные карты (NIC) всех ваших клиентских компьютеров также должны поддерживать Jumbo Frames. Если они этого не сделают, они все равно будут работать, но соединение с этим клиентом будет замедляться, так как оно разбивает кадры на более мелкие стандартные.

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

Как использовать их

Как и в большинстве ситуаций с сетью, очень сложно предоставить конкретику. Здесь все сводится к совместимости. Если все ваше оборудование поддерживает Jumbo Frames, их настройка не должна быть проблемой. MTU является ключом к использованию Jumbo Frames.

Процесс настройки вашей сети сводится к изменению настройки MTU на каждом устройстве до 9000 байт вместо 1500 байт по умолчанию. Сначала проверьте каждый маршрутизатор, коммутатор и любое другое сетевое устройство в вашей сети. Убедитесь, что он поддерживает Jumbo Frames. Если они все делают, измените настройку MTU на каждом.

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

В Windows 10 вы можете включить Jumbo Frames через настройки вашей сетевой карты. В диспетчере устройств вы можете выбрать свой сетевой адаптер. Ищите настройки Jumbo Frames. Если его там нет, ваша карта не поддерживает его. Когда вы выбираете Jumbo Frames, установите размер 9k.

Под Linux есть несколько способов включить Jumbo Frames. Предполагая, что вы используете Linux на рабочем столе, вы можете увеличить размер MTU через Network Manager. Выберите правильное соединение, и вы можете ввести пользовательское значение MTU.

Если вы работаете с сервером, у вас есть некоторые другие параметры интерфейса командной строки, в том числе написание пользовательского модуля Systemd, настройка его с помощью ifconfig при запуске или установка значения в resolv.conf.

Если у вас есть телефоны или другие устройства, которые не поддерживают Jumbo Frames, кадры Ethernet, поступающие с этих устройств, останутся стандартными 1500 байтами. Устройство сломает любые Jumbo Frames, которые приходят к нему.

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

Читайте также: