Какое поле присутствует в заголовке ethernet фрейма

Обновлено: 25.01.2025

Это продолжение цикла статей об основах Ethernet. Мы уже рассмотрели тему о физической среде передачи данных Ethernet (медь), познакомились со стандартами T568A и T568B.
Сегодня постараемся разобраться в Ethernet кадре.

В сетевых технологиях, различают такие понятия как фрейм (frame) и пакет packet. Новички сетевых технологий, часто делают ошибки в использовании этих терминов и считают что эти термины являются синонимами, но это не так.

Давайте определимся, что же называют фреймами, а что называют пакетами.

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

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

Используя знания, полученные в предыдущих статьях, мы знаем, что hub это устройство первого уровня (то есть устройство не знает ни о какой информации, оно не знает о Layer 2 заголовках, и тем более уж о Layer 3).
Но, в то же время, Switch обычно это Layer 2 устройство (то есть оно понимает заголовок Layer 2 Header) и исходя из этого может делать некоторые действия (например брать MAC адрес получателя, искать к какому порту этот MAC-адрес привязан и отправлять фрейм только туда и никуда больше). Так же существуют и Layer 3 коммутаторы.

Итак, спецификация Ethernet.

Давайте поговорим о ней. Какие они были, какие они сейчас.

Первым основателем Ethernet спецификации стала такая компания как DIX , на самом деле это группа компаний: Digital Equipment Corp, Intel , Xerox.
В начале 1980х годов, IEEE стандартизировала технологию Ethernet. Эта технология разделялась на две части:

802.3 Media Access Control (MAC)
802.2 Logical Link Control (LLC)

Существует несколько версий Ethernet фрейма, давайте рассмотрим их.

Теперь разберем поля поподробнее.

Как же может устройство определить, какой тип ethernet кадра принимается?

Ведь существует DIX формат (Ethernet II), 802.3 и 802_3 с SNAP ?

Все очень просто. Давайте рассмотрим алгоритм определения.

Устройство получает фрейм. Смотрит на поле Lenght/Type (помним, оно занимает 2 байта). Если значение больше чем 1518 байт (размер всего фрейма с заголовками), то это уже не Ethernet II , а 802.3 или 802.3 SNAP, потому как только в Ethernet II указывается размер в указанном поле.
Допустим Lenght/Type у нас больше 1518 (0x5FE).
Здесь нам нужно определить, какой фрейм 802.3 или 802.3 SNAP. Это делается на основе заголовка LLC (802.2), таких как DSAP,SSAP и SNAP. Заметим, что SNAP это расширение заголовков DSAP и SSAP (Сервисов стало настолько много, что в 1 байте не удавалось закодировать тот или иной сервис и пришлось создавать еще одну реализацию, которая называется 802.3 SNAP).
SSAP и DSAP обычно принимают одно и тоже значение. Поле Control принимает обычно значение 0x03, что означает, что нет необходимости устанавливать соединение на канальном уровне (Layer 2).

И все же, как определить какой формат Ethernet передается, 802.3 или 802.3 SNAP?

Если передается кадр с SNAP, то значение первого и второго байта данных (по сути это наши SSAP и DSAP) равны 0xAA, а третьего (по сути нашего Control) равняется 0x03.

Вот такой алгоритм работает при том, как определить какой формат кадра передается на приемник.

На канальном уровне, адресация проходит по MAC адресам (помните, когда рассматривали ethernet кадр, первые поля были Destination Address и Source Address, которые занимали 6 байт). Эти адреса имеют 48 битный формат и записываются в 16-ом виде.

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

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

Статья получилась довольно объёмная, рассмотренные темы — форматы 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 адрес отправителя. Всегда юникаст.

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). Цель, таже самая, – идентифицировать вышестоящий протокол, но какова реализация! Теперь, благодаря наличию двух полей в рамках одной сессии пакет мог передаваться между разными протоколами, либо же один и тот же протокол мог по разному называться на двух концах одной сессии. А? Каково? Где ваше Сколково?

Не давая себе передышки, в 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.
Замечание: В современных сетях, где возникновение коллизий исключено, данное ограничение уже не актуально, но требование сохраняется. Это не единственный «аппендикс» оставшийся с тех времен, но о них поговорим в другой статье.

Задержка при передаче – чем больше фрейм, тем дольше длится передача. Для ранних сетей, где Collision домен не ограничивался портом, и все станции должны были ждать завершения передачи, это было серьёзной проблемой.
Чем больше фрейм, тем больше вероятность того что фрейм при передаче будет поврежден, что приведет к необходимости повторной передачи, и все устройства в collision домене будут вынуждены опять ожидать.
Ограничения, накладываемые памятью используемой под интерфейс буферы – на тот момент (1979г) увеличение буферов значительно удорожало стоимость интерфейса.
Ограничение, вносимое полем Length/Type – в стандарте закреплено, что все значения выше 1536 (от 05-DD до 05-FF.) указывают на EtherType, соответственно длина должна быть меньше 05-DC. (У меня правда есть подозрение, что это скорее следствие, чем предпосылка, но вроде инфа от разработчиков стандарта 802.3)

Замечание: Фреймы меньше 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 заголовков.

802.3AC — увеличивает максимальный размер фрейма до 1522 – добавляется Q-tag – несущий информацию о 802.1Q (VLAN tag) и 802.1p (биты под COS)
802.1AD — увеличивает максимальный размер фрейма до 1526, поддержка QinQ
802.1AH (MIM) – Provider Bridge Backbone Mac in Mac + 30 байт к размеру фрейма
MPLS – увеличиваем размер фрейма на стек меток 1518 + n*4, где n – количество меток в стеке.
802.1AE – Mac Security, к стандартным полям добавляются поля Security Tag и Message Authentication Code + 68 байт к размеру фрейма.

Все эти фреймы увеличенного размера группируются под одни именем – 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.

Выгода соотношения Payload к заголовкам. Чем больше это соотношение, тем эффективней мы можем использовать линии связи. Конечно здесь разрыв будет не такой как в сравнении с использованием пакетов в 64 байт и 1518 байт для TCP сессий. Но свои 3-8 процентов, в зависимости от типа трафика выиграть можно.
Значительно меньшее количество заголовков генерирует меньшую нагрузку на Forwading Engine, также и на сервисные Engine. К примеру, frame rate для 10G линка загруженного фреймами по 1500 байт равен 812 744 фреймов в секунду, а тот же линк загруженный Jumbo фреймами в 9000 байт генерирует фрейм рейт всего лишь в 138 587 фрейм в секунду. На рисунке 7 приведены график из отчёта Alteon Networks (ссылка будет внизу статьи) утилизации CPU и гигабитного линка, в зависимости от типа используемого размера фрейма.
Увеличение TCP Throughput при изменении размера MTU — staff.psc.edu/rreddy/networking/mtu.html

Чем больше фрейм, тем дольше он будет передаваться (Рис. 8):
Буферы в памяти сетевых устройств заполняются быстрее, что может вызвать нежелательные последствия. По сути, решаемо на стадии проектирования оборудования, но увеличивает стоимость.
Проприетарная реализация у каждого производителя – все устройства должны поддерживать или одинаковые размеры Jumbo фрейма, или же наборы размеров.
Использование на больших участках сети находящихся под разным административным контролем, по сути, невозможно, из-за отсутствия механизма Jumbo Frame Discovery – промежуточный узел может не поддерживать Jumbo Frame совсем или определенный размер.

В серверных кластерах
При бэкапировании
Network File System (NFS) Protocol
iSCSI SANs
FCoE SANs

Замечание: Верхнее ограничение размера есть и у Jumbo MTU. Оно определяется размером поля FCS (4 байт) и алгоритмом Cyclic Redundancy Check и равняется 11 455 байт. На практике же, Jumbo MTU обычно ограничен размером в 9216 байт, на некоторых платформах в 9000 байт, на более старом железе в 8092 байт (речь о Cisco).

Фух, в принципе всё. Что хотел рассмотреть по теории, рассмотрели. По конфигурации размеров MTU и теории с финтами стоящими за этими тремя буквами, прошу в мою прошлую статью – «Maximum Transmission Unit (MTU). Мифы и рифы».

Поля кадра Преамбула (7 байтов) и Начальный разграничитель кадров (SFD) (1 байт) в Ethernet используются для синхронизации между передающим и принимающим устройствами. Эти первые восемь байтов фрейма используются, чтобы привлечь внимание узлов получения. По существу первые несколько байтов говорят получателям подготовиться принимать новый кадр.

Поле MAC-адрес Назначения

Поле MAC Адрес Назначения (6 байтов) является идентификатором для предполагаемого получателя. Как Вы можете вспомнить, этот адрес используется Уровнем 2, чтобы помочь устройствам в определении, адресуется ли им данный фрейм. Адрес во фрейме сравнивается с MAC-адресом устройства. Если адреса совпадают, устройство принимает фрейм.

Поле MAC-адрес Источника

Поле MAC Адрес Назначения (6 байтов) идентифицирует отправляющий NIC или интерфейс фрейма. Коммутаторы также используют этот адрес, чтобы добавить его к своим таблицам сопоставления. Роль коммутаторов будет обсуждаться позже в этой рубрике.

Поле Длина/Тип

Эти два применения поля были официально объединены в 1997 в стандарте IEEE 802.3x, потому что оба применения были распространены. Поле Тип Ethernet II включается в текущее определение фрейма 802.3. Когда узел принимает кадр, он должен исследовать поле Длина, чтобы определить, какой протокол более высокого уровня в нем присутствует. Если значение двух октетов больше или равно, чем шестнадцатеричное число 0x0600 или десятичное число 1536, то содержимое поля Данные декодируется согласно обозначенному типу протокола. Если значение поля меньше или равно, чем шестнадцатеричное число 0x05DC или десятичное число 1500, поле Длина используется для указания использования формата кадра IEEE 802.3. Таким образом различаются кадры Ethernet II и 802.3.

Поля Данные и Набивка

Поля Данные и Набивка (46 - 1500 байтов) содержат инкапсулированные данные от более высокого уровня, который является типичным PDU Уровня 3, обычно, пакетом IPv4. Все фреймы должны быть по крайней мере 64 байта длиной. Если инкапсулируется пакет меньшего размера, используется Набивка, чтобы увеличить размер кадра до этого минимального размера.

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

Было бы не плохо разобраться как именно Ethernet работает на физическом уровне, но в этой статье я сфокусируюсь на фреймах Ethernet канального уровня (“Ethernet frames”). Этот уровень описывает каким образом два компьютера взаимодействуют посредством Ethernet соединения.

Структура Ethernet фрейма

Фундаментальная часть второго уровня Ethernet - это фреймы. Структура фрейма достаточно простая и является основой для построения более сложных протоколов поверх Ethernet.

В первых двух полях указывается MAC адрес получателя и MAC адрес отправителя. MAC адрес - это уникальный идентификатор сетевого интерфейса для работы на канальном уровне. Размер MAC адреса 48 бит (6 байт).

Следующее поле это 16 битное целочисленное поле, которое называется “Тип Ethernet”(EtherType). Оно определяет протокол более высокого уровня, который должен использоваться для работы с данными(полезной нагрузкой), инкапсулированными в фрейме. Как пример, это могут быть протоколы ARP, IPv4 и IPv6.

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

Последний элемент Ethernet фрейма - специальное поле, проверочная последовательность(“FCS”). По сути это CRC32 проверочная сумма использующая IEEE многочлен. С ее помощью можно определять повреждены ли данные фрейма. Как только фрейм полностью сформирован, проверочная сумма рассчитывается и записывается в последние 4 байта фрейма. Как правило, это делается автоматически операционной системой или сетевым интерфейсом. Но иногда бывает необходимым посчитать FCS в самой программе.

Создание Ethernet фрейма с помощью Go

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

В этом примере мы сделаем фрейм у которого в качестве полезной нагрузки будет простая фраза “hello world”. Также, у этого фрейма будет кастомный EtherType. Фрейм будет рассылаться на все машины того же сегмента на канальном уровне, для этого будем использовать адрес: FF:FF:FF:FF:FF:FF

Как я уже писал, операционная система или сетевой интерфейс сами выполнят расчет FCS. В некоторых случаях можно воспользоваться методом ethernet.Frame.MarshalFCS , выполнить расчет FCS в “ручном режиме” и добавить эти данные к фрейму.

Введение в VLAN теги

Если вы работали с компьютерными сетями в прошлом, то вы вероятно знакомы с концепцией VLAN: виртуальные LAN сегменты. VLANs (IEEE 802.1Q) позволяет разбивать один сегмент сети на множество различных сегментов. Для это хитро используется поле EtherType в фрейме.

Когда добавляется VLAN тег, то первые 16 бит поля EtherType становится идентификатором протокола(Tag Protocol Identifier). Если точнее, то что бы указать, что VLAN тег присутствует, используется резервное значение для поля EtherType, например 0x8100 .

Значения этих то 16 бит, следующие за идентификатором протокола в поле EtherType используются для задания специальных параметров:

Приоритет (3 бита) - один из классов IEEE P8021.p, используется на сервисном уровне.
DEI(Drop Eligible Indicator) (1 бит) - определяет можно ли исключить пакет если в сети есть проблемы.
VLAN ID (VID) (12 бит) - указывает на VLAN к которому относится этот фрейм. Каждый VID создает новый сетевой сегмент.

После VLAN тега указывается EtherType, который уже идентифицирует данные в полезной нагрузке пакета.

В некоторых случаях, может быть использовано несколько VLAN тегов(IEEE 802.1ad, также известный как “Q-in-Q”). К примеру, это может быть полезно, когда провайдер инкапсулирует трафик пользователя в одном VLAN, в то время как пользователь также может инкапсулировать свой трафик в множестве различных VLANов

Добавление тегов в фрейм с помощью Go

Как правило, сетевой интерфейс сам заботится о добавлении VLAN тегов в Ethernet фрейм. Но иногда бывает необходимым добавить VLAN тег из самого приложения. Давайте посмотрим, как это можно сделать на примере нашего приложения.

В моем пример не используются поля Priority и DEI в VLAN тегах. Если в этих полях нет необходимости, можно просто оставить их пустыми.

Отправка и получение Ethernet фреймов по сети

Большинство сетевых приложений работают поверх TCP или UDP. Но Ethernet фреймы используются на более низком уровне, и для работы с ним нужно соответствующее API и права.

Под API, как правило, имеются ввиду “сырые сокеты” (“raw sockets” или “packet sockets”). Эти низкоуровневые сокеты позволяют отправлять и получать Ethernet фреймы напрямую, но необходимы повышенные привилегии.

На другой машине мы можем использовать похожую программу для приема Ethernet фреймов с нашим кастомным EtherType.

И это, собственно, все. Если у вас есть несколько машин с Linux, то вы можете попробовать запустить все примеры у себя. Исходный код можно найти на github.

Низкоуровневые сетевые примитивы, такие как сокеты и Ethernet фреймы, очень мощные инструменты. Используя их, можно полностью контролировать весь трафик который отправляет и получает ваше приложение.

Если вы находите подобные программы захватывающими, так же как и я, то вам пригодятся мои пакеты ethernet и raw. В своих будущих постах я покажу как можно реализовать различные протоколы поверх Ethernet фреймов.

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

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