В 1972-ом году в глубинах Xerox впервые появляется идея стандарта передачи данных по проводам. В 1975-ом ксерокс стандартизует Ethernet.
Чуть позже один из разработчиков стандарта покидает компанию, а ближе к 80-му несколько лидеров рынка оформляют полу совместный стандарт DIX (от DEC + Intel + Xerox).
Первые версии стандарта DIX работали на скорости мегабит, чуть позже появились трёх мегабитные версии и чуть позже появляется та самая известная и по сей день - десяти мегабитная редакция Ethernet.
Формат и стандарт и протокол в первоначальной редакции проживает не долго, уже к 82-му году выходит обновлённая версия редакции Ethernet II DIX. Это не вторая версия протокола, как можно подумать из названия, это вторая версия редакции, о которой члены DIX смогли договорится.
Параллельно с этим Novell разрабатывает и стандартизирует свой формат кадра - RAW. Происходит это в 1982-м году. Свеже-созданный (1980-тый) комитет IEEE пытаясь оправдать своё создание, так же пытается навязать свой формат кадра 802.3 в 1983-м году (второй месяц 3-го года = 802.3).
Тут стоит сделать оговорку. Я всё ещё пишу про Ethernet. Это такая штука, в которой от силы три поля с заголовками и данные. Три. Поля. С заголовками. И вот за эти три поля шла настоящая война стандартов.
В итоге мы имеем пять различных форматов кадра:
* Классический Ethernet - в природе в настоящее время не встречается
* Ethernet II - он же Arpa, в нём есть поле EtherType - определяющее тип вложения
* Ethernet 802.3 - от Novell, он же RAW. В нём поле другое - Length - длинна вложения. Заточенный он только под IPX.
* Ethernet 802.2 - он же LLC. Имеет поле Length и LLC - позволяя внутри кадра держать несколько независимых потоков данных
* Ethernet SNAP - к тому что выше добавляется поле SNAP - позволяя ещё боле гибко разруливать потоки данных внутри кадра. Часто встречается в сложных сетях, в которых есть ether channel или прочие кастомные протоколы.
Как работает оборудование, которое с содержимым такого многообразия кадров будет работать?
Железо читает два байта, находящиеся сразу после мак адресов (напомню формат: преамбула - дст.мак - сорс. мак - то самое волшебное поле - содержимое - crc) и делает вывод о версии кадра. Если там больше 0x0600 (dec:1536) - то внутри точно не длинна, а тип. И дальше, если мы имеем железку от Novell - то ждём внутри IPX, если нет, то определяем есть ли внутри что-то про LLC и SNAP.
Что делать если к нам всё же пришёл кадр без указания длинны?
Если железка получает кадр, начинает его обрабатывать и вдруг понимает, что это тот самый кадр, в котором нет поля длинны, то ожидается:
* Для стандарта 10Base-T в конце будет специальный точно различимый импульс электричества - TP_IDL - который ознаменует завершение «этой» передачи. Если такого импульса не было, а буфер памяти, в который мы помещали текущий кадр, закончился - то передача обрывается. Происходит Drop или Error - в зависимости от реакции передающей стороны. Как только мы получили такой импульс - мы отступаем на четыре байта назад и высчитываем и сверяем CRC кадра.
* Для стандарта 100Base-T ситуация другая, так как там появляется кодирование данных: на четыре бита данных мы генерируем пять бит передачи (4B/5B). Мы ожидаем сигнала ESD (End of Stream Delimiter) представляющий из себя две служебные группы T=01101 и R=00111. И дальше как и выше - поймали ESD отступили назад, посчитали и сверили CRS
* Для гигабитных скоростей отличие от 100-мегабит только в группах бит (так как используется другой тип кодирования, например 8B/10B). Но тоже самое ожидание ESD и проверка CRC.
То что выше, так же справедливо и для Jumbo frames. Если вам «приспичило» выпустить кадр особо крупного размера, вы делаете передачу кадра пока он не закончится и в конце генерируете ESD. Именно из-за этой особенности определения длинны кадра вам предварительно необходимо включить поддержку Jumbo с обеих сторон.
Помимо прочего, сетевой адаптер всегда проверяет, что пришедшее количество бит нацело делится на восемь. Если нет - дропаем кадр. Framing error.
И это ещё не всё.
Есть специальное значение поля EtherType обозначающее, что кадр контрольный = 0x8808. Такой кадр появился в стандарте 802.3x и означает паузу в передаче Pause Frame. Но поддерживают его не все =)
Поддержка таких кадров включается через те самые опции Flow Control, которые есть почти на каждой сетевой карте, но что они делают и как работают - знают не многие.
И ещё кое что.
ECTP - ethernet configuration testing protocol. Его EtherType = 0х9000. Разработан он в Xerox. Однако сам ECTP никем не поддерживается и не используется. лол. *протокол к слову годный, эдакий пинг поверх физики.
Но, так как у протокола получился очень крутой код типа (типа код) - «девятитысячный», его отжали ребята из Cisco и с тем же типом гоняют свои кадры Loop Frames (и похожие - BFD, KeepALive и прч). Код прежний, логика и содержимое разное. Предназначены для диагностики физической среды.
Таким образом, никому не известная ныне (кроме как названием копировальных аппаратов) компания Xerox на долгие годы вперёд обозначила вектор развития технологий передачи данных и создала основу для будущего Интернета и большинства локальных сетей на планете.
Stay connected and ESD.
