что такое фрейм в сети
Фрейм (телекоммуникации)
Фрейм (англ. frame — скелет, остов, телосложение) — в русскоязычной литературе, термин, обозначающий конечный фрагмент данных, подлежащий передаче в системе связи. Другими словами, это — пакет информации, который применяется в сетевой технологии. Как правило, фрейм имеет заранее определенный, четкий, документированный формат. У каждого фрейма есть минимальный и максимальный размер, формат заголовка и применяемые механизмы коррекции ошибок. И хотя в каждой сетевой технологии может применяться свой формат фрейма, все они в принципе схожи между собой, отличаясь лишь в деталях. Так, в большинстве сетевых технологий фрейм состоит из двух частей: заголовка фрейма и области данных, следующей за ним. В заголовке обычно располагается адрес назначения, адрес источника, информация о типе фрейма, необходимая для правильной его интерпретации, и другие служебные данные. Размер заголовка чаще всего неизменен во фреймах конкретного типа сети, область же данных может иметь переменный размер, определяемый объемом передаваемых данных.
В русскоязычной литературе помимо слова «фрейм», как правило, используется синоним «кадр», особенно применительно к сетевым протоколам
Смотреть что такое «Фрейм (телекоммуникации)» в других словарях:
Фрейм (значения) — Фрейм (англ. frame кадр, рамка) в самом общем случае данное слово обозначает структуру, содержащую некоторую информацию. Фрейм (инженерия знаний) в системном анализе, искусственном интеллекте, инженерии знаний: структура,… … Википедия
Фрейм — (англ. frame кадр, рамка) в самом общем случае данное слово обозначает структуру, содержащую некоторую информацию. Фрейм (инженерия знаний) в системном анализе, искусственном интеллекте, инженерии знаний: структура,… … Википедия
Кадр (телекоммуникации) — У этого термина существуют и другие значения, см. Кадр (значения). Кадр (жарг. фрейм, от англ. frame кадр) фрагмент данных сетевого протокола канального уровня модели OSI, передаваемый по линии связи. Кадры подразделяются на:… … Википедия
Кадр (значения) — Кадр: В Викисловаре есть статья «кадр» Кадр элемент кино или видеоряда, отдельное изображение или отрезок киноплёнки. Кадр (телекоммуникации) фрагмент данных сетевого протокола канального уровня модели OSI, передаваемый по линии связи … Википедия
СОДЕРЖАНИЕ
Состав
Пакет данных на проводе и кадр в качестве полезной нагрузки состоят из двоичных данных. Ethernet передает данные со старшим октетом (байтом) первым; однако в каждом октете младший бит передается первым.
| Слой | Преамбула | Разделитель начального кадра | MAC-адрес назначения | Источник MAC | Тег 802.1Q (необязательно) | Ethertype ( Ethernet II ) или длина ( IEEE 802.3 ) | Полезная нагрузка | Последовательность проверки кадра (32-битная CRC ) | Межпакетный разрыв |
|---|---|---|---|---|---|---|---|---|---|
| 7 октетов | 1 октет | 6 октетов | 6 октетов | (4 октета) | 2 октета | 46-1500 октетов | 4 октета | 12 октетов | |
| Фрейм Ethernet уровня 2 | ← 64–1522 октета → | ||||||||
| Пакет Ethernet уровня 1 и IPG | ← 72–1530 октетов → | ← 12 октетов → | |||||||
Необязательный тег 802.1Q занимает дополнительное место в кадре. Размеры полей для этой опции указаны в скобках в таблице выше. IEEE 802.1ad (Q-in-Q) позволяет использовать несколько тегов в каждом кадре. Этот вариант здесь не проиллюстрирован.
Разделитель преамбулы и начального кадра
Пакет Ethernet начинается с семиоктетной преамбулы и однооктетного ограничителя начального кадра (SFD).
Заголовок
Поле EtherType имеет длину два октета и может использоваться для двух разных целей. Значения 1500 и ниже означают, что он используется для указания размера полезной нагрузки в октетах, а значения 1536 и выше указывают, что он используется как EtherType, чтобы указать, какой протокол инкапсулирован в полезной нагрузке кадра. При использовании в качестве EtherType длина кадра определяется местоположением межпакетного промежутка и действительной контрольной последовательностью кадра (FCS).
Полезная нагрузка
Последовательность проверки кадра
Согласно стандарту, это вычисление выполняется с использованием алгоритма CRC32 BZIP2 со сдвигом влево (poly = 0x4C11DB7, начальный CRC = 0xFFFFFFFF, CRC дополняется после, значение проверки = 0x38FB2284). Стандарт гласит, что данные передаются первым младшим значащим битом (бит 0), тогда как FCS передается первым старшим значащим битом (бит 31). Альтернативой является вычисление CRC с использованием CRC32 со сдвигом вправо (poly = 0xEDB88320, начальный CRC = 0xFFFFFFFF, CRC дополняется пост-дополнением, значение проверки = 0x2144DF1C), что приведет к CRC, который является инверсией битов FCS, и передать сначала данные и младший бит CRC, что приводит к идентичным передачам.
Стандарт гласит, что получатель должен вычислять новую FCS по мере получения данных, а затем сравнивать полученную FCS с FCS, вычисленным получателем. Альтернативой является вычисление CRC как для полученных данных, так и для FCS, что приведет к фиксированному ненулевому значению «проверки». (Результат не равен нулю, потому что CRC дополняется во время генерации CRC). Поскольку данные принимаются в первую очередь младшим значащим битом, и чтобы избежать необходимости буферизовать октеты данных, приемник обычно использует CRC32 со сдвигом вправо. Это делает значение «проверки» (иногда называемое «магической проверкой») 0x2144DF1C.
Однако аппаратная реализация CRC с логическим сдвигом вправо может использовать регистр сдвига с линейной обратной связью со сдвигом влево в качестве основы для вычисления CRC, реверсирования битов и получения значения проверки 0x38FB2284. Поскольку дополнение CRC может выполняться после вычисления и во время передачи, то, что остается в аппаратном регистре, является результатом без дополнения, поэтому остаток для реализации с правым сдвигом будет дополнением к 0x2144DF1C = 0xDEBB20E3, а для сдвига влево реализация, дополнение 0x38FB2284 = 0xC704DD7B.
| Тип кадра | Ethertype или длина | Начало полезной нагрузки два байта |
|---|---|---|
| Ethernet II | ≥ 1536 | Любой |
| Novell raw IEEE 802.3 | ≤ 1500 | 0xFFFF |
| IEEE 802.2 LLC | ≤ 1500 | Другой |
| IEEE 802.2 SNAP | ≤ 1500 | 0xAAAA |
Есть несколько типов кадров Ethernet:
Кроме того, все четыре типа кадров Ethernet могут дополнительно содержать тег IEEE 802.1Q для определения того, к какой VLAN он принадлежит, и его приоритета ( качества обслуживания ). Эта инкапсуляция определена в спецификации IEEE 802.3ac и увеличивает максимальный кадр на 4 октета.
Ethernet II
Чтобы разрешить использование некоторых кадров с использованием кадрирования Ethernet v2 и некоторых с использованием исходной версии кадрирования 802.3 в одном и том же сегменте Ethernet, значения EtherType должны быть больше или равны 1536 (0x0600). Это значение было выбрано, потому что максимальная длина поля полезной нагрузки кадра Ethernet 802.3 составляет 1500 октетов (0x05DC). Таким образом, если значение поля больше или равно 1536, кадр должен быть кадром Ethernet v2, причем это поле является полем типа. Если оно меньше или равно 1500, это должен быть кадр IEEE 802.3, где это поле является полем длины. Исключительные значения от 1500 до 1536 не определены. Это соглашение позволяет программному обеспечению определять, является ли кадр кадром Ethernet II или кадром IEEE 802.3, обеспечивая сосуществование обоих стандартов на одном физическом носителе.
Novell raw IEEE 802.3
«Необработанный» формат кадра 802.3 от Novell был основан на ранней работе IEEE 802.3. Novell использовала это как отправную точку для создания первой реализации собственного сетевого протокола IPX через Ethernet. Они не использовали заголовок LLC, а начали пакет IPX сразу после поля длины. Это не соответствует стандарту IEEE 802.3, но поскольку IPX всегда имеет FF в качестве первых двух октетов (в то время как в IEEE 802.2 LLC этот шаблон теоретически возможен, но крайне маловероятен), на практике это обычно сосуществует на проводе с другими реализациями Ethernet, за заметным исключением некоторых ранних форм DECnet, которые это сбивали с толку.
Novell NetWare по умолчанию использовала этот тип кадра до середины девяностых годов, и поскольку NetWare была тогда очень широко распространена, а IP не использовался, в какой-то момент большая часть мирового трафика Ethernet проходила через «чистый» 802.3, несущий IPX. Начиная с NetWare 4.10, NetWare по умолчанию использует IEEE 802.2 с LLC (тип кадра NetWare Ethernet_802.2) при использовании IPX.
IEEE 802.2 LLC
IEEE 802.2 SNAP
Изучив заголовок 802.2 LLC, можно определить, следует ли за ним заголовок SNAP. Заголовок LLC включает два восьмибитовых адресных поля, которые в терминологии OSI называются точками доступа к услугам (SAP); когда и исходный, и целевой SAP имеют значение 0xAA, за заголовком LLC следует заголовок SNAP. Заголовок SNAP позволяет использовать значения EtherType со всеми протоколами IEEE 802, а также поддерживает пространства идентификаторов частных протоколов.
В IEEE 802.3x-1997 стандарт IEEE Ethernet был изменен, чтобы явно разрешить использование 16-битного поля после MAC-адресов в качестве поля длины или поля типа.
Набор протоколов AppleTalk v2 в сети Ethernet (« EtherTalk ») использует инкапсуляцию IEEE 802.2 LLC + SNAP.
Максимальная пропускная способность
Мы можем рассчитать накладные расходы протокола для Ethernet в процентах (размер пакета, включая IPG).
Мы можем рассчитать эффективность протокола для Ethernet
Эффективность протокола знак равно Размер полезной нагрузки Размер пакета <\ displaystyle <\ text <Эффективность протокола>> = <\ frac <\ text <Размер полезной нагрузки>> <\ text <Размер пакета>>>> 
Максимальная эффективность достигается при максимально допустимом размере полезной нагрузки и составляет:
для немаркированных кадров, поскольку размер пакета составляет максимум 1500 октетов полезной нагрузки + 8 октетов преамбулы + 14 октетов заголовка + 4 октета завершающей части + минимальный межпакетный интервал, соответствующий 12 октетам = 1538 октетов. Максимальный КПД составляет:
когда используется тегирование 802.1Q VLAN.
Пропускная способность может быть вычислена по эффективности
Пропускная способность знак равно Эффективность × Чистая скорость передачи данных <\ displaystyle <\ text ,
где чистая скорость передачи данных физического уровня ( скорость передачи данных по проводам) зависит от стандарта физического уровня Ethernet и может составлять 10 Мбит / с, 100 Мбит / с, 1 Гбит / с или 10 Гбит / с. Следовательно, максимальная пропускная способность для 100BASE-TX Ethernet составляет 97,53 Мбит / с без 802.1Q и 97,28 Мбит / с с 802.1Q.
Использование канала знак равно Время, потраченное на передачу данных Общее время <\ displaystyle <\ text <Использование канала>> = <\ frac <\ text <Время, затраченное на передачу данных>> <\ text <Общее время>>>>
Общее время учитывает время приема-передачи по каналу, время обработки на хостах и время передачи данных и подтверждений. Время, потраченное на передачу данных, включает данные и подтверждения.
Бегущие кадры
Всё, что вы хотели знать о Ethernet фреймах, но боялись спросить, и не зря
Статья получилась довольно объёмная, рассмотренные темы — форматы Ethenet фреймов, границы размеров L3 Payload, эволюция размеров Ethernet заголовков, Jumbo Frame, Baby-Giant, и много чего задето вскользь. Что-то вы уже встречали в обзорной литературе по сетям передачи данных, но со многим, однозначно, не сталкивались, если глубоко не занимались изысканиями.
Начнём с рассмотрения форматов заголовков Ethernet фреймов в очереди их появления на свет.
Форматы Ehternet фреймов.
1) Ethernet II
Рис. 1
Preamble – последовательность бит, по сути, не являющаяся частью ETH заголовка определяющая начало Ethernet фрейма.
DA (Destination Address) – MAC адрес назначения, может быть юникастом, мультикастом, бродкастом.
SA (Source Address) – MAC адрес отправителя. Всегда юникаст.
E-TYPE (EtherType) – Идентифицирует L3 протокол (к примеру 0x0800 – Ipv4, 0x86DD – IPv6, 0x8100- указывает что фрейм тегирован заголовком 802.1q, и т.д. Список всех EtherType — standards.ieee.org/develop/regauth/ethertype/eth.txt )
Payload – L3 пакет размером от 46 до 1500 байт
FCS (Frame Check Sequences) – 4 байтное значение CRC используемое для выявления ошибок передачи. Вычисляется отправляющей стороной, и помещается в поле FCS. Принимающая сторона вычисляет данное значение самостоятельно и сравнивает с полученным.
Данный формат был создан в сотрудничестве 3-х компаний – DEC, Intel и Xerox. В связи с этим, стандарт также носит название DIX Ethernet standard. Данная версия стандарта была опубликована в 1982г (первая версия, Ehernet I – в 1980г. Различия в версиях небольшие, формат в целом остался неизменным). В 1997г. году данный стандарт был добавлен IEEE к стандарту 802.3, и на данный момент, подавляющее большинство пакетов в Ethernet сетях инкапсулированы согласно этого стандарта.
2) Ethernet_802.3/802.2 (802.3 with LLC header)
Рис. 2
Как вы понимаете, комитет IEEE не мог смотреть спокойно, как власть, деньги и женщины буквально ускользают из рук. Поэтому, занятый более насущными проблемами, за стандартизацию технологии Ethernet взялся с некоторым опозданием (в 1980 взялись за дело, в 1983 дали миру драфт, а в 1985 сам стандарт), но большим воодушевлением. Провозгласив инновации и оптимизацию своими главными принципами, комитет выдал следующий формат фрейма, который вы можете наблюдать на Рисунке 2.
Первым делом обращаем внимание на то, что “ненужное” поле E-TYPE преобразовано в поле Length, которое указывало на количество байт следующее за этим полем и до поля FCS. Теперь, понять у кого длинее можно было уже на втором уровне системы OSI. Жить стало лучше. Жить стало веселее.
Но, указатель на тип протокола 3его уровня был нужен, и IEEE дало миру следующую инновацию — два поля по 1 байту — Source Service Access Point(SSAP) и Destination Service Access Point (DSAP). Цель, таже самая, – идентифицировать вышестоящий протокол, но какова реализация! Теперь, благодаря наличию двух полей в рамках одной сессии пакет мог передаваться между разными протоколами, либо же один и тот же протокол мог по разному называться на двух концах одной сессии. А? Каково? Где ваше Сколково?
Замечание: В жизни же это мало пригодилось и SSAP/DSAP значения обычно совпадают. К примеру SAP для IP – 6, для STP — 42 (полный список значений — standards.ieee.org/develop/regauth/llc/public.html)
Не давая себе передышки, в IEEE зарезервировали по 1 биту в SSAP и DSAP. В SSAP под указание command или response пакета, в DSAP под указание группового или индивидуального адреса (см. Рис. 6). В Ethernet сетях эти вещи распространения не получили, но количество бит в полях SAP сократилось до 7, что оставило лишь 128 возможных номера под указание вышестоящего протокола. Запоминаем этот факт, к нему мы ещё вернёмся.
Было уже сложно остановиться в своём стремлении сделать лучший формат фрейма на земле, и в IEEE фрейм формате появляется 1 байтное поле Control. Отвечающее, не много, не мало, за Connection-less или же Connection-oriented соединение!
Выдохнув и осмотрев своё детище, в IEEE решили взять паузу.
Замечание: Рассматриваемые 3 поля — DSAP, SNAP и Control и являются LLC заголовком.
3) «Raw» 802.3
Рис. 3
Данный «недостандарт» явил в мир Novell. Это были лихие 80-ые, все выживали, как могли, и Novell не был исключением. Заполучив ещё в процессе разработки спецификации стандарта 802.3/802.2, и лёгким движением руки выкинув LLC заголовок, в Novell получили вполне себе неплохой фрейм формат (с возможность измерения длины на втором уровне!), но одним существенным недостатком – отсутствием возможности указания вышестоящего протокола. Но, как вы уже могли догадаться, работали там ребята не глупые, и по здравому размышлению выработали решение – «а обратим ка мы свои недостатки в свои же достоинства», и ограничили этот фрейм-формат исключительно IPX протоколом, который сами же и поддерживали. И задумка хорошая, и план был стратегически верный, но, как показала история, не фортануло.
4) 802.3 with SNAP Header.
Время шло. В комитет IEEE приходило осознание того, что номера протоколов и деньги кончаются. Благодарные пользователи засыпали редакцию письмами, где 3-х байтный LLC заголовок ставился в один ряд с такими великими инновациями человечества, как оборудование собаки 5ой ногой, или же с рукавом, который можно использовать для оптимизации женской анатомии. Выжидать дальше было нельзя, настало время заявить о себе миру повторно.
Рис. 4
И в помощь страждущим от нехватки номеров протоколов (их всего могло быть 128 – мы упоминали), IEEE вводит новый стандарт фрейма Ethernet SNAP (Рис. 4). Основное нововведение — добавление 5-ти байтного поля Subnetwork Access Protocol (SNAP), которое в свою очередь состоит из двух частей – 3х байтного поля Organizationally Unique Identifier (OUI) и 2х байтного Protocol ID (PID) — Рис. 5.
Рис. 5
OUI или же vendor code – позволяет идентифицировать пропиетарные протоколы указанием вендора. К примеру, если вы отловите WireShark`ом пакет PVST+, то в поле OUI увидите код 0x00000c, который является идентификатором Cisco Systems (Рис. 6).
Рис. 6
Замечание: Встретить пакет с инкапсуляцией в формат фрейма 802.3 SNAP довольно легко и сейчас – это все протоколы семейства STP, протоколы CDP, VTP, DTP.
Поле PID это, по сути, то же поле EtherType из DIX Ethernet II — 2 байта под указание протокола вышестоящего уровня. Так как ранее, для этого использовались DSAP и SSAP поля LLC заголовка, то для указания того, что тип вышестоящего протокола нужно смотреть в поле SNAP, поля DSAP и SSAP принимают фиксированное значение 0xAA (также видно на Рис. 6)
Замечание: При использовании для переноса IP пакетов формата фрейма LLC/SNAP, IP MTU снижается с 1500 до 1497 и 1492 байт соответственно.
По заголовкам в формате фрейма в принципе всё. Хотел бы обратить внимание на ещё один момент в формате фрейма – размер payload. Откуда взялся этот диапазон — от 46 до 1500 байт?
Размер L3 Payload.
Откуда взялось нижнее ограничение, знает, пожалуй, каждый, кто хотя бы читал первый курикулум CCNA. Данное ограничение является следствием ограничения в размер фрейма в 64 байта (64 байта – 14 байт L2 заголовок — 4 байта FCS = 46 байт ) накладываемого методом CSMA/CD – время требуемое на передачу 64 байт сетевым интерфейсом является необходимым и достаточным для определения коллизии в среде Ethernet.
Замечание: В современных сетях, где возникновение коллизий исключено, данное ограничение уже не актуально, но требование сохраняется. Это не единственный «аппендикс» оставшийся с тех времен, но о них поговорим в другой статье.
Замечание: Фреймы меньше 64 байт называются Runts, фреймы больше 1518 байт называются Giants. Просмотреть кол-во таких фреймов полученных на интерфейсе можно командой show interface gigabitEthernet module/number и show interface gigabitEthernet module/number counters errors. Причём до IOS 12.1(19) в счётчики шли как фреймы с неверным, так и верным CRS (хотя вторые не всегда дропались – зависит от платформы и условий). А вот начиная с 12.1.(19) отображаются в этих счётчиках только те runt и giant фреймы, которые имеют неверный CRS, фреймы меньше 64 байт, но с верным CRS (причина возникновения обычно связана с детегированием 802.1Q или источником фреймов, а не проблемами физического уровня) с этой версии попадают в счётчик Undersize, дропаются они, или же форвардятся дальше, зависит от платформы.
Эволюция размеров Ethernet заголовков.
Все эти фреймы увеличенного размера группируются под одни именем – Baby-Giant frames. Негласное верхнее ограничение по размерам для Baby-Giant – это 1600 байт. Современные сетевые интерфейсы будут форвардить эти фреймы, зачастую, даже без изменения значения HW MTU.
Отдельно обратим внимание на спецификации 802.3AS — увеличивает максимальный размер фрейма до 2000 (но сохраняет размер MTU в 1500 байт!). Увеличение приходится на заголовок и трейлер. Изначально увеличение планировалось на 128 байт – для нативной поддержки стандартом 802.3 вышеперечисленных расширений, но в итоге сошлись на 2х тысячах, видимо, чтобы два раза не собираться (или как говорят в IEEE – this frame size will support encapsulation requirements of the foreseeable future). Стандарт утвержден в 2006 году, но кроме как на презентациях IEEE, я его не встречал. Если у кого есть что добавить здесь (и не только здесь) – добро пожаловать в комменты. В целом тенденция увеличения размера фрейма при сохранении размера PAYLOAD, порождает у меня в голове смутные сомнения в правильности выбранного направления движения.
Замечание: Немного в стороне от перечисленного обосновался FCoE фрейм – размер фрейма до 2500 байт, зачастую, эти фреймы называются mini-jumbo. Для их саппорта необходимо включать поддержку jumbo-frame.
Замечание: Верхнее ограничение размера есть и у Jumbo MTU. Оно определяется размером поля FCS (4 байт) и алгоритмом Cyclic Redundancy Check и равняется 11 455 байт. На практике же, Jumbo MTU обычно ограничен размером в 9216 байт, на некоторых платформах в 9000 байт, на более старом железе в 8092 байт (речь о Cisco).
Фух, в принципе всё. Что хотел рассмотреть по теории, рассмотрели. По конфигурации размеров MTU и теории с финтами стоящими за этими тремя буквами, прошу в мою прошлую статью – «Maximum Transmission Unit (MTU). Мифы и рифы».
IT1210: Сетевое администрирование
Стандарт Ethernet следует считать средством обеспечения соединения между абонентами сети, относящимся к канальному уровню (link-level layer). Поэтому имеет смысл рассматривать передаваемые по сети данные как состоящие из фреймов 1 (frame), или кадров. Фреймы Ethernet имеют переменную длину, однако их размер не может быть меньше 64 октетов 2 и превышать 1518 октетов (с учетом преамбулы фрейма, передаваемых данных и кодов циклической проверки CRC). Как и в любой другой сети с коммутацией пакетов, в каждом фрейме Ethernet предусмотрено специальное поле для адреса получателя. Помимо адреса получателя, фрейм Ethernet содержит также физический адрес отправителя (рис. 2.4).
Рис. 2.4. Формат фрейма (пакета) Ethernet. Перед передачей по сети фрейм дополняется специальной преамбулой (рисунок сделан без соблюдения масштаба полей)
Таким образом, кроме полей адреса отправителя и получателя, в каждый передаваемый по сети Ethernet фрейм добавляется преамбула, поле типа, поле данных и код циклического избыточного контроля (Cyclic Redundancy Check, или CRC). Преамбула состоит из 64-битовой последовательности нулей и единиц и предназначена для облегчения синхронизации принимающей сетевой платы. Поле CRC (его размер 32 бита) служит для обнаружения ошибок при передаче данных на приемном конце. При этом отправитель вычисляет код циклического избыточного контроля как функцию от данных, находящихся во фрейме, и помещает их в передаваемый пакет. Получатель снова вычисляет код CRC и сравнивает его с находящимся во фрейме. Если коды совпадают, принимающая сторона считает, что пакет получен без искажений.
Поле типа состоит из 16-битового целого числа, которое предназначено для идентификации типа данных, передаваемых во фрейме. С точки зрения построения процесса межсетевого взаимодействия поле типа очень важно, поскольку оно позволяет автоматически распознавать фреймы Ethernet. Другими словами, операционная система на основе поля типа полученного фрейма определяет программный модуль протокола, который должен обработать поступивший пакет данных.
Одно из ключевых преимуществ автоматического распознавания фреймов заключается в том, что на одной и той же машине можно использовать несколько различных протоколов, а также передавать по физической сети пакеты данных разных протоколов без их взаимного влияния. Благодаря полю типа на одном и том же компьютере могут свободно сосуществовать приложения, использующие как семейство протоколов TCP/IP, так и любые другие протоколы, например те, что только разрабатываются и находятся на стадии тестирования. Таким образом, операционная система анализирует поле типа каждого полученного фрейма и определяет, как должно обрабатываться его содержимое. Ниже мы увидим, как автоматически опознаваемые фреймы Ethernet используются в семействе протоколов TCP/IP для выделения пакетов разных протоколов.
1. Термин фрейм (кадр) взят из терминологии, использовавшейся для описания процесса передачи данных по последовательному каналу связи. При этом отправитель разделял данные на фрагменты (фреймы) и перед передачей фрейма помещал до и после него специальные коды.
2. Формально для описания размера символа, зависящего от применяемого оборудования, используется термин байт. Однако в телекоммуникации используется другой термин — октет, который, в отличие от байта, не зависит от применяемого оборудования и всегда состоит из 8 бит.