Стандарты Ethernet (Часть 2)

Итак, второй день наших вебинаров про Ethernet. Мы будем говорить про протокол Ethernet, про всякое разное, что с ним будет связано. В первый день мы проговорили про базовые какие-то вводные вещи, которые характерны вообще для любой сети, которые подводят нас к тому, как работает Ethernet. Мы проговорили про физику, про витую пару и про оптику. Некоторые аспекты физики мы еще не разобрали, потому что мы к ним подойдем чуть попозже. Но, соответственно, в основном мы их посмотрели. И теперь пришла пора проговорить про следующие аспекты, про то, как Ethernet будет передавать отдельные биты. То есть мы научились работать с физикой, мы поняли, что нужны там провода определенного сечения 0,24 АВГ, что их нужно либо 4, либо 8 штук, 2 или 4 пары. И давайте посмотрим, что там будет у нас передаваться по этим проводам. Для того, чтобы понимать, как устроен Ethernet и почему он так устроен, надо понять, что было первично.

То есть собрались люди и сказали, а давайте мы сделаем Ethernet. Отчего они отталкивались, что они должны были решить для себя перед тем, как что-то делать. Они, естественно, должны были понять, на какой скорости они будут желать передавать данные, потому что от этого будет много что зависеть. С какими параметрами сигнал будет передаваться. И, соответственно, в зависимости от этого уже дальше вся пляска бы и шла. То есть разработка должна с чего-то начинаться. Должны быть зафиксированы какие-то вводные. Соответственно, при разработке 10-мегабитного Ethernet было сказано, вот мы хотим передавать 10 миллионов бит в секунду. Соответственно, если у вас есть 10 миллионов бит в секунду, каждый отдельный бит, если предположить, что они отправляются не параллельно, а последовательно, независимо друг от друга, то есть передали 1 бит, закончили, начали передавать второй бит, закончили, начали передавать третий бит. Просто берем калькулятор, одну секунду делим на 10 миллионов, на 10 мегабит в секунду, 10 миллионов бит в секунду. И получаем время отправки 1 бита 0,1 микросекунда или 100 наносекунды.

Вот это время, за которое отправляется с интерфейса в среду передачи данных 1 бит, будет называться специальным словом bit time. Почему я сейчас рассказываю подробно про достаточно очевидную вещь, что существует время, за которое отправляется 1 бит? Потому что от этого времени в Ethernet будет очень много чего плясать. Время, в течение которого отправляется 1 бит в среду передачи данных, это отправная точка, от которой плясался Ethernet. То есть, при разработке, если бы вы были на месте авторов стандарта, вы бы сказали, давайте зафиксируем время отправки в 0,1 микросекунда или 100 нс. Мы это возьмем как отправную точку. Таких отправных точек будет несколько. Ну вот, соответственно, это одна из них, важная, ключевая точка, которая у вас будет использоваться. Это далеко не единственная точка, далеко не единственный важный параметр, который при разработке Ethernet был важен. То есть, вы должны будете зафиксировать много разных других вещей. Ну вот, одна из них это время отправки 1 бита.

Второй важный параметр, который вы должны были зафиксировать, это slot time. Вообще, в теории коммуникации, slot time это время, которое необходимо 1 биту для того, чтобы дойти между двумя самыми удаленными участниками, вот одного участника до другого и обратно. Зачем нужен этот самый slot time? Затем, что у вас за это время, если произойдет коллизия, вот когда вы передаете что-то, вы начинаете это что-то передавать. Вот это вот начало того, что вы передаете, добегает до удаленного конца сети. Там, возможно, вот в тот момент, когда оно прибежало в удаленный конец сети, случается коллизия. И коллизия тоже распространяется по сети обратно. Время, в течение которого информация по сети бежит, оно конечное. Оно маленькое, но все равно оно какое-то есть. Скорость передачи данных в металлическом проводнике, она примерно равна скорости света, поделенной на 2 трети. Поделенной на 3 вторых. Ну, то есть 2 трети от скорости света.

Если скорость света примерно взять 300 тысяч километров в секунду, то вот скорость сигнала в металлическом проводнике примерно 200 тысяч километров в секунду. Соответственно, да, 200 тысяч километров в секунду это дофига. Но помножьте это все дело на 0,1 микросекунда, на 100 наносекунд. И вы получите, что время, которое требуется сигналу для того, чтобы пробежать достаточно небольшое расстояние, оно может быть достаточно большим. То есть вот вы за 0,1 микросекунду чего-то отправили. И дальше вот за еще 1,0,1 микросекунду у вас свет пробежит там какое-то расстояние. Это расстояние можно взять достаточно легко посчитать. Опять же, берем калькулятор и считаем. Вот если мне память не изменяет, эта штука получается порядка 50 метров. То есть пока вы 1 бит отправили, 2 бит отправили, первый уже на 50 метров убежал.

Еще 1 бит отправляете, еще там на 50 метров. Слушайте, я где-то, наверное, ошибся. Это не 50 метров. Давайте прям возьмем калькулятор и посчитаем. Нам известна скорость распространения электромагнитной волны в металлическом проводнике. Это 200 тысяч километров в секунду, 200 миллионов метров в секунду. У нас есть, соответственно, количество секунд, которое пробегает этот самый, которое распространяется сигнал. Это у нас будет 0,000. Это будет 0 миллисекунд, 0,01. 100 нс. 20 метров. Простите, я ошибся. Не 50 метров, а 20 метров. То есть вы отправили 1 бит, второй бит вы начинаете отправлять, первый уже убежал на 20 метров. Третий бит начинаете отправлять, первый убежал на 40 метров, второй убежал на 20 метров. Так вот, вы должны будете зафиксировать, что у вас есть некое время,

в течение которого ваши данные могут отправляться. И, соответственно, пока вы это дело отправляете, у вас сигнал убегает на какое-то расстояние. И если вдруг он там встретит коллизию, эта коллизия точно так же с такой же скоростью будет распространяться обратно. Вот это вот время, в течение которого вы минимальное гарантированное время, в течение которого вы отправляете данные, оно называется slot time. Вы это время фиксируете. То есть вы говорите, мы фиксируем время slot time, для того, чтобы минимально за это время гарантированно выполнялась передача данных, что если мы начинаем занимать среду, вот это вот время slot time мы фиксируем. То, что меньше данные передаваться не будут точно. И, соответственно, это самое время сигнал должен потратить на то, чтобы добежать до самого удаленного конца сети и вернуться назад. Соответственно, если у вас есть указание, что один битик за одну миллисекунду пробегает 20 метров, то вы дальше это самое за 0,1 микросекунду, за 100 нс,

пробегая 20 метров, дальше вы с этим временем, с этой скоростью что-то сможете сделать. В Ethernet слот time выставлен в 512 биттаймов. То есть у вас зафиксировано время, в течение которого отправляется один битик. Это 100 нс. И слот time зафиксирован как 512 раз по биттайму. Или 51 микросекунда. Это опять же, так же как и биттайм, который зафиксирован просто как данность. Вот слот time зафиксирован как данность. Вы можете посчитать, исходя из биттайм и слот time, которые в Ethernet зафиксированы как данность, какое максимальное расстояние между двумя участками в Ethernet может быть. Если вы знаете, что за 0,1 микросекунду у вас проходит сигнал 20 метров, вы можете взять и помножить все это дело на 512. То есть 20 метров умножаем на 512, получаем 10 240 метров. Вот это вот самое 10 240 метров, это расстояние, которое проходит 1 битик за 512 микросекунд.

Учитывая, что расстояние между двумя узлами, надо ему будет пройти дважды для того, чтобы поместиться в это самое время slot time, чтобы добежать до удаленного участка и успеть вернуться назад, если коллизия будет, до конца передачи. Вот это вот расстояние в 10 километров мы должны будем поделить пополам. И получается, что если у вас есть сеть Ethernet, ни при каких обстоятельствах между двумя участками в Ethernet не имеет права быть больше 5 километров расстояния. То есть это вообще запрещено физикой. Вы не можете взять и сделать участок Ethernet длиной, допустим, 6 километров одним длинным проводом. Даже если вы придумаете какую-то супер-мега технологию, которая позволит вам достаточно эффективно добивать до удаленного участка и вернуться назад. Обращая внимание, это все разговор идет про 10-мегабит Ethernet. Если вы возьмете 100-мегабит Ethernet, то, соответственно, время bit time точно так же будет уменьшено в 10 раз,

потому что в секунду вы отправляете в 10 раз больше данных, и на каждый отдельный бит уходит в 10 раз меньше времени. И, соответственно, slot time там тоже будет зафиксирован во что-то еще. Ну, соответственно, да. В любом случае у вас будет зафиксировано с помощью двух этих времен, bit time и slot time, одновременно и максимальное расстояние, на которое теоретически физика позволяет передавать данные и обнаруживать при этом коллизию, если она произошла. Вот. Однако же, мы, хотя и получили в цифру в 5 километрах, мы при этом знаем, что на самом деле размер одного сегмента у нас выставлен в 100 метров. Мы при этом знаем, что он выставлен в 100 метров не потому, что он там коллизию не успеет обнаружить, а потому что именно там наводка не успевает пройти. Наводки на сегментах больше 100 метров становятся слишком большими. Однако, на самом деле, вот эта вот самая математика вида, давайте посчитаем скорость распространения сигнала и на основании этой скорости за известное время посчитаем расстояние, которое оно успеет пройти,

оно нам пригодится чуть позже. Поэтому имейте в виду, максимальное теоретическое расстояние между двумя узлами, да, может быть не более 5 километров. В реальности оно существенно меньше по немножко другой причине, которую мы сейчас обязательно разберем. Что будет, если два участника начинают одновременно передавать коллизию? Вот мы когда говорили чуть раньше, что коллизия вообще-то бывает, мы же говорили, что ну просто один начинает передавать, второй начинает передавать, получается каша. Вы имейте, пожалуйста, в виду, что на самом деле, когда коллизия происходит, она происходит так, что вы начинаете передавать, а потом через некоторое время вам возвращается результат, что что-то как-то не то прибежало. То есть вы-то подаете, допустим, плюс 0,7 вольт у себя, а сосед свои плюс 0,7 вольта, которые он будет передавать, он передаст их у себя. И вот это вот расстояние между вами, этот сигнал должен какое-то время проходить. И вы, соответственно, будете передавать данные,

и сигнал до вас будет ходить с задержкой. И кашу вы услышите только после того, как вы что-то передадите. Начинаете передавать что-то, а потом прибегает каша. Поэтому, каким образом Ethernet с коллизиями будет бороться или не бороться вообще, что Ethernet будет делать с коллизиями? Давайте вспомним, что такое коллизия. Коллизия – это один узел начал передавать данные, второй не заметил, что среда занята, тоже начал передавать данные, вместе получилось каша. Может ли произойти каша, если у нас участники все добросовестные, и все одновременно слышат среду, и они сразу слышат, если кто-то начинает передавать данные, и тем самым среду занимает? Если они очень рядышком друг с другом расположены, технически, наверное, можно предусмотреть сценарий, при котором узел А начинает передавать данные, узел Б сразу слышит, что среда занята и не передает данные. В реальности все чуть более сложно. В реальности узел А может начать передавать данные, тем самым занимая среду, но сигнал до узла, допустим, C еще не дошел.

И узел C тоже начинает занимать среду. Вот он видит C, да, свободно, потому что он еще не знает, что в то же самое время кто-то другой в другом конце сети начал свои вольты подавать на проводник. И он тоже начинает занимать среду, он тоже начинает свои вольты подавать на контакты, на интерфейс. И получается, что через некоторое время оба, соответственно, поток этих данных, оба сигнала столкнутся, смешаются, и оба узла поймут, что что-то не то произошло. Как они поймут, что что-то не то произошло? Они всегда, когда они передают какие-то данные, они слушают, что они передают. И если вы начинаете передавать данные, допустим, 0 передаете, подаете условные плюс 0,7 вольта, или минус 0,7 вольта, не важно, на проводник, и вы слушаете одновременно, что у вас там передается. Вот вы подали плюс 0,7 вольта и сразу вольтметром замеряете, и слышите 0,7 вольта, И говорите, да, подали 0,7 вольта и 0,7 вольта услышали. Все в порядке, коллизия по крайней мере не прибежала сейчас.

Может быть она произойдет в будущем от того, что мы эти самые 0,7 вольта подали, просто кто-то нам еще не успел испачкать их. Но вот прямо сейчас 0,7 вольта мы слышим. Дальше вы, возможно, передаете следующий бит. То есть первый бит передали, 20 метров он пробежал, передаете следующий бит. Подали там минус 0,7 вольта. И к вам прибегает, возможно, коллизия от предыдущего бита или от предыдущего бита. Она, коллизия, в чем будет заключаться? В том, что та коллизия, которая произошла, она произошла от того, что какие-то данные наложились на ваши. Да, возможно, они наложились на ваши давным-давно, но к вам прибежала вот прямо сейчас какая-то беда. И вы, соответственно, берете, передаете минус 0,7 вольта, вольтмер сразу тыкаете на контакты и видите там что-то отличное от минус 0,7 вольта. То есть вы-то собираетесь передать минус 0,7 вольта, но каша, которая к вам прибежала от того, что раньше произошла коллизия, и она дает вам что-то отличное от того, что вы передаете. Вот коллизия в Ethernet будет предотвращаться, не сама коллизия будет предотвращаться, а ее последствия будут предотвращаться с помощью метода CSMA-CD.

На самом деле, когда писался протокол 802.3, оригинальный Ethernet 802.3, он описывал в большей степени не столько саму физику, не столько какие-то указания, давайте видом биттайм выставим в 100 мс, слот тайм в 512 раз по биттайм. Он описывал как раз механизм CSMA-CD. Он называется так, потому что это аббревиатура. Carrier Sense with Multiple Access and Collision Detection. Если это дело перевести просто пословно, получается следующее. Carrier Sense. У вас каждый из узлов слушает среду. Он всегда ее слушает. Когда он не передает, он слушает, чего передают другие. А когда, соответственно, он сам передает, он слышит, чего он сам передает и сравнивает это с тем, что он передает. Вот этот вот механизм CSMA-CD, это как раз все узлы всегда слушают среду. И более того, они по среде могут понять, свободна среда или занята. Вот прямо сейчас.

Не означает на самом деле то, что прямо сейчас среда занята, не то, что ее через 50 наносекунд не займет кто-нибудь еще. Но, по крайней мере, попытаться занять ее вы можете. Если среда занята, то это видно. Если среда прямо сейчас не занята, то вы можете попытаться передать в эту среду свои данные. На физическом уровне свободная среда выражается в том, что туда никто ничего не передает и напряжение, соответственно, там будет нулевое. В занятии среды передачи вы будете видеть следующее. Вы будете видеть два уровня. Но, опять же, про 10 BST, если мы говорим, там будет передаваться либо плюс 0,7 вольта, либо минус 0,7 вольта. Вот я когда говорил эти самые 0,7 вольта плюс или минус, это действительно честные 0,7 вольта. Другой вопрос, что на самом деле битики, которые будут передаваться, нолики, единички, они будут немножечко как бы специфическим образом передаваться. Вот как вы думаете, что из плюс 0,7 вольта и минус 0,7 вольта обозначают нолик и единичку в 10 BST?

Хитрость будет заключаться в следующем. Если у вас есть медная пара, на эту медную пару может пройти хитрая наводка и, соответственно, немножечко изменить вам напряжение между этими самыми двумя проводками. То есть можно пройти такое, что уровень заряда на одном проводнике немножко изменится, и тем самым разность потенциалов у вас будет изменена. Поэтому, если у вас будет, соответственно, такая хитрая наводка проходить, она, скорее всего, во времени будет достаточно распределенной. Она вам вряд ли испортит отдельный битик, не затронув все остальные. Она, скорее всего, затронет сразу большую пачку бит. И, соответственно, может случиться такое, что у вас на каком-то отдельном проводе, на одной конкретной жиле заряд будет изменяться, и тем самым вы всегда будете в течение довольно продолжительного времени, по сравнению с биттаймом, вы всегда будете наблюдать смещение того самого напряжения в какую-то сторону. Допустим, у вас будет постоянная ошибка, например, в полвольта, в плюс.

И, соответственно, ваши отправительские 0,7 вольта плюс и 0,7 вольта минус превратятся в минус, сколько получается, 0,2 и плюс 1,2 вольта. Вот такие вот штуки, они могут произойти в Ethernet. И для того, чтобы с ними бороться, то есть, допустим, у вас есть отправитель, который передает один битик. Ну, например, вот он передал плюс 0,7. Мы сейчас не говорим про то, что именно биты кодируются только именно так. Ну, вот если он передал плюс 0,7 вольта, что произошло? Пробежала ошибка, и получатель принял плюс 1,2 вольта. Вот ему эти 1,2 вольта как воспринимать? Как плюс или как минус? Ему их надо декодировать. Не как плюс, а как нолик или как единичку. Ему их надо как-то декодировать и получить из аналогового сигнала цифровой. Вот он взял, вольтметром тыкнул, говорит 1,2. Что с ним делать? Ну, хорошо, можно сказать, что это был, скорее всего, там, допустим, битик единичка. Потом следующий померил, еще раз вольтметром тыкнул,

видит минус 0,2. Чего с ними делать? Ну, раз минус, наверное, значит, вот, скорее всего, это был ноль. Предположим, ошибка прошла больше. Предположим, ошибка прошла, допустим, в 3 вольта. Таким образом, вы намерили плюс 3,7 вольта и плюс 2,3 вольта. Если мы передаем плюс 0,7 вольта на передатчике, то это превращается в 3,7 на приемнике. Вот ткнули и говорим, 3,7 прошло. Задать порог срабатывания? Нет, все хитрее. Такие наводки, они реально бывают, и они довольно частые. Поэтому в Ethernet, в 10 BST, по крайней мере в стандарте, используется так называемый манчестерский код. Он заключается в следующем. У вас есть тайм-слоты, в течение которых вы можете выдавать в среду некий сигнал. Ну, условно говоря, выдавать вот те самые плюс 0,7 вольта или минус 0,7 вольта. Одно из этих напряжений, плюс 0,7 вольта, задается как высокий уровень напряжения.

Другое, минус 0,7 вольта, как низкий уровень напряжения, low. Если вы хотите передать 0, вы передаете за 2 такта сначала низкий уровень напряжения, а потом высокий. Если вы хотите передать 1, вы наоборот передаете сначала высокий, а потом низкий. И, соответственно, да, это алгоритм коррекции ошибок, который позволяет вам за 2 такта передать 1 бит. И если отправитель отправляет, допустим, сначала минус 0,7, потом плюс 0,7, но они превращаются в 2,3 и 3,7 вместе взятые, получатель говорит, я вижу, прибежало что-то, что в 2 тактах я намерил 2,3 и 3,7 вольта. Судя по всему, там прошла ошибка. Там прошла какая-то наводка, которая видоизменила сигнал таким образом, что напряжение превратилось в совершенно другие. Но я вижу, что за 2 такта сначала было маленькое напряжение, а потом большое. Да, они не пришли эталонные минус 0,7 и плюс 0,7. Они пришли модифицированные. Но зато пришло сначала поменьше, а потом побольше.

Это был нолик. А потом в другом каком-то передаваемом бите, точнее, принимаемом бите, опять мы меряем 2 такта. И видим, что сначала было много, а потом мало. Сначала высокий уровень, а потом низкий. И мы говорим, ага, это была по ходу единичка. Потому что, соответственно, у нас было сначала много, а потом мало. Естественно, манчестерский код это очень неэффективный способ отправки данных. Он механизм не столько даже коррекции, сколько предоставления избыточности. Поток завышенных, заниженных бидов подряд. Ну какая разница-то? То есть у вас надо передать, допустим, 3 единицы подряд. И вот вы передаете первую единицу, много-мало. Потом вторую единицу, много-мало. Третью единицу, много-мало. Да, они будут идти завышенные, заниженные подряд. Но вы же можете определить, где закончился один такт, начался другой. И получается, что вы можете все передаваемые вот эти вот такты померить. Разбить их на пары. И в каждой паре сказать, вот эта пара характеризует один какой-то бид.

Если сначала много, потом мало, это было единица. Если сначала мало, потом много, это ноль. Да. Вот. Манчестерский код, да, он неэффективен. Он на самом деле половину передаваемых данных передает просто так. То есть вы в принципе могли бы сказать, если у нас среда хорошая, если у нас нет никаких помех, задержек, помех, наводок и прочего, давайте каждый бид кодировать либо высоким, либо низким уровнем. То есть скажем, низкий уровень это нолик, высокий уровень это единица. Тем самым вы теоретически пропускную способность 10-мегабитного Ethernet можете просто вот самим фактом отказа от этого механизма коррекции ошибок повысить в два раза. У вас по факту передается 20 миллионов тактов в секунду, а вы их делите на пары, и каждая пара у вас характеризует один бит. Но это нужно вот для возникновения, для коррекции возникающих ошибок, если таковые возникнут. Вот. Да.

Если же вы в среду ничего не передаете, то получается следующее. Вы не передаете ни нолик, ни единичку, ни плюс 0,7 вольта, ни минус 0,7 вольта. Вы просто сидите тихо на попе ровно и ничего не делаете. И если все узлы сидят на попе ровно и ничего не делают, то у вас напряжение между проводами нулевое. Ну или по крайней мере оно какое-то стабильное. Такие 20 или всегда 10. 20 миллионов тактов в секунду, 10 миллионов бит в секунду. Потому что каждый бит кодируется двумя тактами. Мы сейчас опять же говорим про стандарт 10 BST. Вы в реальном мире 10 BST не увидите. Потому что это 10 мегабитный Ethernet по витой паре. Он давным-давно уже даже из музеев выкинули, как ненужный мусор. Современные стандарты, начиная с сотки, они будут использовать другие уже способы кодирования. Если вам это реально интересно, идите в Википедию. Там про каждый конкретный стандарт будет написано, какой метод кодирования он будет использовать.

Там существенно меньше будут накладные расходы. То есть обычно при таких стандартах будет использоваться либо механизм 6 на 8, либо 8 на 10, когда у вас на каждые 8 бит полезных данных будет передаваться 10 тактов. Ну и механизм, скажем, этой самой избыточности, которая будет передаваться, он будет более сложный по сравнению с манчестерским кодом. Но манчестерский код просто проще объяснить. А вот все эти механизмы более хитрые, они уже настолько тяжелые, там используется математика, которую просто вы все равно в мире никогда не увидите. Вы не будете с вольтметром тыкать в Ethernet и понимать, чего он там какие битики передает. Главное, что существует такой механизм кодирования. На примере манчестерского кода мы узнали, как он может выглядеть. Да, математику нафиг. Важное замечание. Когда у вас узел ничего не передает, он никакие данные в физическую среду не выдает. Он просто не виден практически.

Если все узлы сидят и ничего не делают, то у вас среда свободна. Любой желающий может взять, тыкнуть вольтметром, померить, увидеть там ноль и сказать, среда свободна, я могу ее занять. И начать в эту среду выгонять какие-то биты. И тогда все увидят, что среда занята. Они увидят там либо плюс 0,7 вольта, либо минус 0,7 вольта, либо какие-то другие вольты, которые будут постоянно меняться. И они скажут, среда занята, пора слушать и понимать, чего там такое передается. То есть метод CSMACD, career sense, будет означать, что у вас всегда все узлы слушают среду и понимают, свободна она или занята. Если нет, то можно среду попытаться занять. Возможно, случится коллизия. Multiple access означает, что у вас к этой среде будет много участников, которые будут иметь доступ. То есть может быть ситуация, при которой два участника по каким-то причинам попытаются занять среду. В норме, если у вас среда уже занята, участники не должны пытаться занимать среду. То есть один первый занял, который увидел, что среда свободна,

а второй увидел, что среда не свободна и не решил передавать данные. Но иногда из-за того, что скорость передачи данных конечная, может случиться ситуация, когда два узла одновременно вскидываются, говорят, одновременно мы сейчас померили вольтметром 0 вольт визем, и одновременно мы пытаемся передавать данные. Случается коллизия. Коллизия не может случиться, когда один уже начал передавать много данных, а, соответственно, второй вот видит, смотрит, передаются данные, вдруг решает встрять. А не передать ли мне чего-нибудь, вот пока тот передает. Ну и как в хорошем парламенте мужики друг друга не перебивают. Один мужик встал, побухтел в микрофон, сел. Другой мужик встал, побухтел, сел. Никто не будет вскакивать и говорить, ты не прав, ты козел, дайте мне сюда микрофон, я ему морду набью. Или там оттаскивать за всякие разные причиндалы от трибуны тоже как-то в серьезном парламенте не принято. Ну и вот все смси сидит такой же. Серьезные мужики собрались, один поговорил, сел.

Второй увидел, что свободно, переговорил, сел. Может сложиться ситуация, когда двое встанут одновременно, и это случится коллизия. Двое серьезных людей, которые встали поговорить одновременно и начали говорить одновременно, они долго говорить не будут. Они должны понять, что случилась какая-то коллизия, сесть, заткнуться и попытаться как-то с этой ситуацией разобраться другими методами. Collision detection означает, что все узлы будут слушать среду, включая оба передающих узла. Коллизию один узел устроить не может, может только два узла устроить. Один, который начал передавать данные, второй, который тоже начал передавать данные одновременно. Они оба начинают передавать данные, они оба слушают то, что они передают. И с некоторой задержкой они услышат, относительно того момента, как они начали передавать, что то, что они передают, отличается от того, что они принимают. Тот сигнал, который отправлялся оригинальным узлом, вот он начал отправлять. Один, ноль, один, ноль, один, ноль. Другой какой-то узел тоже услышал свободную среду, тоже начал передавать один, ноль, один, ноль, один, ноль.

И у них в какой-то момент эти самые данные сталкиваются. Волна, которая приходит от одного участника до другого, накладывается на то, что он в этот момент передает. Важное замечание, да, что произошло это в разные моменты времени, но волна от вредителя дошла до вас с некоторой задержкой. И вы слышите, что вы то, что передаете, нолик там, допустим, меряете вольтметром, а там совсем не то, что вы слышите. Более того, оно может даже отличаться по тактам, потому что два узла, которые одновременно начали занимать среду, они могли это сделать с разницей, допустим, в половину биттайма. И биты одного узла наложились на биты другого узла с смещением вот в полбитика. И получится, что в этой ситуации, соответственно, у вас уровни, которые вы намеряете, те самые вольты, они могут вообще быть ни на что не похожи. Они могут быть одинаковые всегда, потому что там передаете вы ровно в противофазе. И у вас получается всегда, вы передаете плюс 0,7, а сосед передает минус 0,7.

Либо может быть такое, что вы там передаете, начинаете передавать побольше, а там прибежало от соседа поменьше напряжение, но оно вот не весь такт ваш будет передаваться. Это только часть такта. Ну и вот вам немножко уровень понизила. А потом в следующем такте немножко повысило. И получается, что вы просто слышите чего-то другое. Каждый раз, когда узлы слышат что-то другое, они понимают, что случилась коллизия. Таких участников, которые устроили коллизию, будет как минимум два. Оба они примерно одинаково поймут, что коллизия произошла. И оба они должны дать понять всем, включая себе, что коллизия произошла. Третьи узлы, которые сидят в сети, которые не устроили коллизию, они ничего не знают про то, что эта коллизия произошла. Они просто слышат какие-то уровни. И они пытаются понять. Вот пришло 1,3 вольта, 1,2 вольта, 1,3 вольта, 1,2 вольта. Конечно, оно больше похоже на то, что там больше-меньше, но все-таки какая-то билиберда приходит. Вот нужно всем остальным участникам дать понять, что даже если они что-то намерили, это точно не надо воспринимать всерьез.

Поэтому два узла, которые устроили коллизию, которые передавали какие-то данные и услышали данные от второго участника, ну или третьего, четвертого, неважно, которые устроили коллизию, они начинают сразу после обнаружения коллизии делать следующее. Сейчас у меня там картинка, кажется, есть. Да. Они отправляют специальную джемпоследовательность. Джемпоследовательность – это сигнал, который нужен только лишь для одного. Гарантированно испортить передаваемые данные, что бы ни передавалось, как бы ни передавалось. Может быть такой просто, что ваш сигнал, допустим, до самой дальней точки доходит практически, как бы это сказать, практически заглушенный тем участникам, который сделал вам коллизию. И вы должны будете гарантированно сделать так, чтобы все участники точно и гарантированно определили, что коллизия произошла. Вот вы посылаете такую мусорную последовательность, которая нужна только для того, чтобы гарантированно всем испортить контрольную сумму.

И все узлы, которые слышат какие-то данные, на которые сверху дополнительно накладывается эта самая специальная джемпоследовательность, они пытаются потом понять, что они такое получили, видя точно, что это какая-то цепочка бит, у которой вообще ничего не сходится, никакая неконтрольная сумма не сходится, ничего. И они просто ее выбрасывают, говорят, пришла какая-то каша, мы даже не будем пытаться понять, что это прошло. То есть, это нужно именно для вот этого механизма. После того, как джемпоследовательность отправлена к каждому из узлов, оба участника, вызвавшие коллизию, ну или если их вдруг случилось больше, 3-4, неважно, они будут заниматься разруливанием этой самой коллизии. То есть, всех остальных участников, что передача не получилась, они уведомили. Дальше, каждый из них придумывает некое случайное число. Это случайное число будет называться back-off-timer. Здесь на слайде не написано, но, в принципе, вы вполне можете пережить без знания того, как это точно пишется.

Это просто случайное число. Случайное число измеряется порядка bit-таймов. Порядка slow-тайма, простите, порядка slow-тайма. И, соответственно, оно будет зависеть от того, сколько коллизий происходило за последнее время. В скольких коллизиях вы участвовали. Если у вас коллизий до того момента не было, то число будет поменьше. Если коллизий в последнее время было много, то это число будет побольше. Но главное, это число действительно придумано случайным образом. И из двух участников, которые коллизию строили, у одного число будет поменьше, у другого побольше. И back-off-timer, соответственно, у одного будет поменьше, у другого побольше. Тот, который придумал число поменьше, у которого back-off-timer получился поменьше, он заткнулся. Через некоторое время проснулся и видит, что среда, допустим, свободна. И он пытается эту самую среду занять. Тот, у которого, соответственно, back-off-timer был придуман побольше. Он проснулся и увидел, что среда уже занята.

Может быть такое, что оба заткнулись, оба заснули, оба проснулись и видят, что кто-то уже третий занял совершенно линию. Но в этом случае они просто оба сидят и ждут своей очереди. Каждый узел, который будет, соответственно, пытаться ждать своей очереди, он будет выплевывать битики пачками. Эти пачки будут называться кадрами. И, соответственно, да, между двумя кадрами у вас всегда будет некий перерывчик. Если у вас есть узел, который хочет отправить данные, несколько кадров подряд, он будет пытаться это делать следующим образом. Он передает кадр, потом делает маленькую паузу, минимально необходимую по стандарту, и дальше начинает отправлять следующий кадр. Таким образом, у него как-то есть приоритет по сравнению со всеми остальными узлами, которые могли бы занять эту самую среду. Все остальные узлы, которые еще пока не отправляли кадры, но хотят передать, они будут действовать следующим образом. Там схема будет примерно как Wi-Fi. У вас есть узел.

Этот узел хочет отправить какой-то кадр. Этот узел придумывает себе, опять-таки, некое число. И это число, опять же, случайное, приблизительно случайное. Этот узел начинает ждать, чтобы тишина была в течение определенного времени. Ну, допустим, вы там придумали себе число 10. Вот вы говорите, я на 10 микросекунд сейчас жду, чтобы ничего не передавалось в сети, чтобы сеть была свободна. Если у вас кадр пробежал, вы подождали Interframe Space, вы его обязаны подождать. Дальше включаете отсчет времени, что в течение 10 микросекунд никто не занимает среду. И если никто среду не занял, то вы начинаете передавать данные. Таким образом, если вдруг даже кто-то передает прямо сейчас кадр, и двое участников одновременно хотят после этого передать кадр, они точно так же будут придумывать два разных случайных числа. У одного окажется поменьше число, у другого побольше, тот, у которого оказалось поменьше, он начнет передавать данные раньше, чем другой. А другой, соответственно, как только увидел, что он начинает считать до 15, но досчитал до 5, и тут кто-то среду занял,

он вот это вот самое число, которое у него получилось, от таймера осталось, он запоминает и ждет, пока среда снова освободится. И когда в следующий раз среда освободится, он будет продолжать отсчет уже с того места, где он закончил считать. То есть он, допустим, придумал число 15, 14, 13, 12, 10, 8, 7, 6, 5 досчитал, среду заняли, среду освободили, интерфрейм спейс прошел, и он читает дальше 4, 3, 2, 1 и занимает среду, соответственно, дальше. Если вдруг у вас есть какой-то узел, который ждет достаточно долго, то вот у него, соответственно, получается некий приоритет по сравнению со всеми остальными, для того, чтобы отправить данные вперед тех, кто захотел отправить данные позже. Вот такой вот механизм, он в Азернете существует. Технически, возможно, вероятность того, что вот вы уже отсчитали все, что можно, вы попытались отправить все кадры, которые хотели, но вот все у вас вперед кто-то у вас все пробегает и пробегает. Ну, в этом случае, рано или поздно у вас этот таймер дойдет до нуля, и когда вы, соответственно, услышите, что среда в очередной раз свободна, вы просто скажете, а вот теперь я передаю.

Ну, если таких узлов будет много, то, да, может быть коллизия. Но это опять ситуация будет в виду, у нас много узлов, которые хотят передавать много данных, наша сеть передает данные всего лишь со скоростью 10 мегабит в секунду, и до узлов, которые хотят передавать данные данных, которые должны быть переданы узлами, больше, чем этих самых 10 мегабит. То есть у нас сеть перегружена, да, в случае перегрузки сети Ethernet начинает себя вести плохо. Хорошо себя ведет Ethernet именно тогда, когда сеть недонагружена. Вот в случае с 10 мегабитами по общей шине, 10 мегабит по факту эффективно могут передавать только один узел. Вот он сидит и он херачит. Первый, второй, третий, четвертый, пятый, десятый, сотый кадр. Все подряд идут без перерывов. В этом случае у вас, да, на физическом уровне передается реально 10 мегабит в секунду, и все эти 10 мегабит в секунду превращаются, ну, с небольшими потерями в боевые кадры, в боевые данные. В случае, если у вас есть Ethernet, и, соответственно, это общая шина, и у вас много участников, которые пытаются разделить эту среду между собой,

начинается конкурентный доступ к среде, начинаются коллизии, и каждый раз, когда коллизия у вас происходит, что такое коллизия? Это вы начали занимать среду, но вы ее начали занимать зря. Вы потратили время, вы потратили ресурсы, вы не дали передавать в это время полезные данные, а потом разбежались, и кто-то другой, возможно, после вас эту самую среду занял. Поэтому коллизия это плохо. В Wi-Fi тоже коллизия есть, но только в Wi-Fi механизма обнаружения коллизии нет. Поэтому в Wi-Fi, если что, есть такая же штука, как CSMA, дробь, только CA, не Collision Detection, Collision Avoidance. То есть в Wi-Fi есть служебный арбитражный трафик, с помощью которого узлы могут договориться, кто передает данные первым, кто передает данные вторым. Вот в Wi-Fi никаких договоренностей нет, есть просто справедливое разделение, что все стоят, условно говоря, в очереди. Каждый, пусть в эту очередь, встает в приблизительно произвольном месте, но эта очередь рано или поздно все равно разбирается. Вот. Так, да.

Если, соответственно, у вас произошла коллизия, вы попытались передать кадр, и у вас случилась коллизия, вы придумываете себе этот самый back-off-таймер побольше, чем придумывали раньше. То есть чем больше у вас коллизий, тем более неэффективно используется сеть, и тем больше узлы будут ждать перед попыткой отправки. То есть у вас мало того, что коллизии будут съедать сами служебное время работы сети, когда могли бы передавать полезные биты, передаются вот всякая фигня. Плюс к тому, расстояние между кадрами у вас будет больше, потому что как раз требуется каждому узлу, который устроил коллизию, придумывать большее время, чтобы можно было как-то между собой узлам договориться, кто прямо сейчас среду занимает, кто нет. Вот. Поэтому, да, перегруженный Ethernet начинает работать сильно хуже, чем слегка недонагруженный. Имейте это в виду. Также имейте в виду, что если на Ethernet написано 10 Мбит в секунду, это не означает, что вы можете 10 Мбит реально полезных данных, вот 10 разделить на 8 получается там сколько,

1,25 Мбит данных в секунду через него пропихнуть. Будут служебные данные, как минимум будут служебные данные тратиться на пустое ожидание вот между кадрами, на эти самые интрафрейм спейсы. Оно будет, кстати, довольно заметное. Там 96 биттаймов, если меня память не изменяет, это 12 байт. Ну, то есть, так это серьезно. Его можно в некоторых более новых протоколах подкрутить, но имейте в виду, в абсолютно любых протоколах вот этот самый интерфрейм спейс есть. Даже если вы берете там 100 гигабитный Ethernet, у него тоже есть интерфрейм спейс, который нужен для того, чтобы вот участники между собой могли понять, что среда свободна и, если что, вклинится. В современных Ethernet-ах никакого CSMC-CD уже нет, никаких общих шин, ничего. Современные Ethernet-ы, все вот те, которые мы там в промышленных масштабах будем использовать, там 10 гигабит по оптике, гигабит по меди, даже 100 мегабит со свечами, они все point-to-point. Там вот эта вот штука уже просто не нужна.

Но у них все равно есть интерфрейм спейс. И этот интерфрейм спейс появился из-за того, что был когда-то механизм CSMC-CD. Это как раз один из тех примеров, которые вынуждают нас знать, как был устроен Ethernet когда-то давным-давно, для того, чтобы понять, а зачем Ethernet сейчас работает вот так. Вот он ни зачем сейчас так не работает. Это тяжелые рудименты тех времен, когда Ethernet работал по общей шине. Вот. Далее нам потребуются специальные два названия, два термина новых. Первый термин. Домен коллизий. Это область, в которой распространяется физический сигнал. Вот там, где вы передаете плюс вольт, плюс 0,7 вольта. Вот область, в пределах которой этот самый сигнал распространяется, где вы можете намерить эти самые плюс 7 вольт, это будет домен коллизий. Если у вас используется Ethernet с общей шиной и больше ничего, то, соответственно, в этой области вы можете передавать данные в Ethernet, и она будет называться широкопечательным доменом. Почему два разных названия?

Того, что, в общем, по сути своей для старых Ethernet одно и то же. Потому что, если у вас сеть не с общей шиной, если у вас сеть современный Ethernet, который, в общем-то, имеет представление, имеет топологию точка-точка, это будут совершенно разные вещи. Домен коллизий. Это там, где распространяется физический сигнал, а широкопечательный домен – это та область, в пределах которой можно доставить кадр Ethernet. Нам они прямо вот сейчас будут очень-очень нужны оба этих понятия. Да. Тонкий намек на то, что в современном мире с SMA-CD вы нигде не увидите. То есть, вот на картинке нарисовано то, как сейчас устроены Ethernet. У вас есть свитч, коммутатор. Этот коммутатор с помощью физического подключения точка-точка подключен к каждому абоненту. Этих абонентов может быть много. Если у вас есть узел А, который хочет отправлять данные куда-то, он, эти данные, отправляет узлу с помощью протокола, с помощью физической топологии точка-точка, с помощью протокола Ethernet.

Подают какие-то битики в сторону узла, В, в сторону свитча. Эти битики дальше каким-то образом будут декодироваться. То есть, вы понимаете, что вот прибежали битики нолики-единички. Не плюс 0,7 вольт, а не минус 0,7 вольт, а вот именно нолики-единички. Как бы они там ни кодировались. Манчестерский код, не манчестерский код, неважно. Вычленяются нолики-единички вот здесь. И дальше в сторону другого какого-то порта свитч будет отправлять данные, опять-таки, нолики-единички те же самые, которые прибежали. Но электрически закодированы. Они могут быть по-другому. Совершенно не обязательно будет такое, что у вас узел А и узел С используют совершенно одинаковые стандарты Ethernet. Один из них может отправлять данные на скорости 10 мегабит в секунду, а другой на скорости 100 мегабит в секунду. И это принципиально разные физические стандарты. Да, логически нолики-единички одинаковые. Вот, соответственно, если у вас есть коммутатор, он будет гарантировать передачу ноликов и единичек одинаковые.

А то, что там будут вольты одинаковые, время отправки данных одинаковые, это совершенно никто не обещал. Если у вас будет хаб, то да, там все честно. Там вы отправили плюс 0,7 вольта. Все 0,7 вольта разбежались по всей сети. Отправили дальше там минус 0,7 вольта. Да, они по всей сети разбежались. Да, возможно, с наводками. Да, возможно, с какими-то еще особенностями. Но, тем не менее, добежали. Вот в случае, соответственно, со свечами электрический сигнал распространяется только в пределах одного порта. Так, да. Опять-таки, если у нас есть точка-точка, обратите внимание на то, что в случае с современными изернетами, как правило, у вас будет так называемый full-duplex использоваться, полный дуплекс, при котором связь будет реально полнодуплексная или просто дуплексная. То есть данные, которые идут от узла А до свеча, и данные, которые идут от свеча до узла А, они идут физически по разным проводам, по разным цепям или по разным оптическим волокнам.

Они не сталкиваются между собой. Поэтому для вас это будет вполне себе актуально, что если вы хотите сделать дуплексную связь, вы должны будете использовать свечи. И если вы используете свечи, вы можете использовать дуплексную связь. Дуплексную связь с общей шиной сделать не получится физически. Так, далее. Что у нас тут еще будет? Коммутация сигналов и средств. Да. Почему коммутатор называется коммутатором? Потому что он действительно использует коммутацию... Тут не сигналов, коммутацию данных. Строго говоря, правильно было бы сказать. К вам пришел какой-то сигнал, в этот сигнал померили, получили там высокое напряжение, а потом низкое напряжение. Вы говорите, высокое, а потом низкое. Это нолик. Логический нолик, который передавался, вы оцифровали, передали дальше в сторону другого порта, и дальше в сторону другого порта отправляете логический нолик. Этот самый нолик, возможно, будет закодирован уже по-другому. Поэтому, да, здесь у нас используется именно коммутация.

По поводу сравнения домена коллизий и домена широковещательного. Если вы будете брать и добавлять хабы, то эти хабы увеличивают размер домена коллизий. То есть у вас там было два узла соединенных проводов, вы воткнули между ними хаб, воткнули третий узел, у вас домен коллизий был всего лишь в одном проводе, а потом стал в двух или трех проводах. Вот сколько у вас абонентов есть, все это домены коллизий. Происходит это потому, что хаб распространяет электрический сигнал. Вы вот здесь вот подали плюс 0,7 вольта, везде в пределах домены коллизий вы увидели плюс 0,7 вольта. Если вы, соответственно, добавляете где-то коммутатор, коммутатор сокращает распространение сигнала, потому размеры доменов коллизий уменьшаются. Но зато этих доменов коллизий становится больше. Каждый порт коммутатора – это отдельный домен коллизий. Если у вас был прямой провод вот здесь, вот между двумя участниками, это был один большой домен коллизий. Взяли, вставили коммутатор между ними, у вас получилось два домена коллизий. Один вот в этом проводе,

где распространяется электрический сигнал между коммутатором и левым участником. Другой вот здесь, вот отдельный физический провод, который будет, соответственно, нести сигнал между свечом и правым участником. На сертификационных экзаменах цисковских довольно часто в свое время спрашивали понимание того, что такое домен коллизии, что такое широковещательный домен. В современных версиях экзаменов уже не спрашивают. Плохо это или хорошо, в общем-то сказать сложно. С одной стороны, в общем неплохо, потому что в современных эзернетах коллизий уже не бывают. Поэтому говорить о том, что в современном эзернете есть необходимость понимать, что такое домен коллизии, особенно такое понимание не требуется. Главное, чтобы вы примерно понимали, что добавили коммутатор или добавили хаб и у вас получилось возможно воткнуть много новых участников. Поскольку в современном мире все равно хаба вы не используете, везде вы используете свечи и со всеми свечами вы везде используете полный дуплекс, то действительно для вас понятие того, что у вас есть домен коллизий в отдельном проводе, причем на самом деле в каждом проводе два домена коллизий в одну и в другую сторону.

Причем в каждом из этих доменов ровно один передатчик, поэтому на самом деле каждый провод это два разнонаправленных симплексных канала и там коллизии в общем невозможно физически устроить. Ну, наверное, да. В таких условиях знать про то, что домены коллизий существуют не обязательно. Однако для других технологий, которые используются в коммутации, например для Spanning 3, в понимании того, как устроен домен коллизий, почему он так устроен и почему он так называется, кстати говоря, будет очень важно. Для OSPF, как ни странно, тоже нужно будет понимать, что такое домен коллизий, как он устроен. Поэтому вы должны будете хорошо понимать, зачем эти самые домены нужны, оба этих домены, чем они отличаются друг от друга, для того, чтобы эффективно работать с теми технологиями, которые в современных сетях используются. Даже если эта технология не Ethernet. То есть вот такой вот забавный момент. Вы должны знать про исторические эти самые домены коллизий, которые использовались и были нужны прям реально каждому администратору.

Хотя сегодня в Ethernet вам это не нужно. Но понимание того, что такое было и как оно работало, нужно для других технологий. В частности для Spanning 3. Так. Если вы можете отправить сигнал, то вы в этом сигнале можете закодировать какие-то кадры Ethernet и кадр Ethernet может быть доставлен в пределы домена коллизий обязательно. Может быть такое, тем не менее, что у вас есть несколько коммутаторов и между ними тоже можно кадры Ethernet коммутировать. Вот вы отправляете электрический сигнал вот здесь вот в проводе. Здесь у нас в проводе будет отдельный домен коллизий.

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

Вы, соответственно, технически в Ethernet можете такие передавать. Более того, разные протоколы будут подмешивать вот эти самые дополнительные такты. К сигналу. Но каждый из участников в Ethernet знает, какие такты будут подмешиваться. Если вот он сидит на попе ровно, видит, что прибежал просто внеплановый какой-то, допустим, плюс 0,7 вольта. Он говорит, да, я понимаю, это прибежало плюс 0,7 вольта. Это служебный плюс 0,7 вольта. Они не означают половинку единички, не означают половинку нолика. Это вот дополнительный подмешанный сигнал, который нужен для какой-то служебной задачи. Поэтому вот такие вот эти самые подмешанные дополнительные сигналы, они могут на самом деле подмешиваться в виде, допустим, даже ноликов или единичек. Но все равно эти нолики единички будут служебные. И когда вы передаете боевые данные, вот вы передаете там, не знаю, 10 мегабит данных ноликов единичек полезных, которые вам нужны для какого-то приложения. К этим ноликам и единичкам могут быть подмешаны нолики единички служебные. Эти нолики единички в приложении вы нигде не увидите. Более того, вы их снифером нигде не увидите.

Но вот если вы возьмете вольтметр или осциллограф, вот вы там сможете заметить, что передаются какие-то лишние сигналы. И эти сигналы распространяются в пределах домена коллизий. А вот, соответственно, между доменами коллизий коммутатор будет перекладывать только полезные нолики единички. И если стандарт, допустим, слева от коммутатора был один, справа от коммутатора будет другой, то нолики единички могут подмешиваться по-разному. Имейте это, пожалуйста, в виду. Вот эти служебные данные, которые отправляют узлы Ethernet, они не включаются в число тех самых 10 мегабит в секунду или 100 мегабит в секунду. То есть то, что там передаются дополнительные высокие или низкие напряжения в проводе, вы можете не учитывать. Если подсчитываете, например, сколько максимально полезных бит вы можете передать в проводе Ethernet. Но Interframe Space, все остальные части, которые у нас будут входить в кадры Ethernet, вы должны будете обязательно, конечно, учитывать. Размеры коллизий, если вдруг у вас почему-то таковые будут, тоже вы должны будете учитывать.

То есть когда вам говорят, этот Ethernet работает на скорости, допустим, 100 мегабит в секунду, вы должны будете понимать, что у вас кадры будут отправляться вот такого размера, условно 64 байта с учетом всех заголовков. Плюс к этому надо прибавить, допустим, преамбула, плюс к этому надо будет прибавить междукадровое расстояние. Это же все время, в течение которых могло бы теоретически передаваться полезная нагрузка, но она не передается, потому что все узлы сидят на попе ровно и ждут, пока все предыдущие участники поймут, что кадр передаваться закончил. Поэтому вот учитывайте, пожалуйста, этот момент, что на 10 мегабитном интерфейсе данных 10 мегабит полезных, вот 10 миллионов полезных ноликов в единичек вы никогда не сможете передать. На самом деле их будет передаваться меньше. А с физической точки зрения их будет передаваться больше. То есть тактов будет как минимум в два раза больше, если вы используете манчестерский код. И плюс к этому дополнительно еще будут какие-то служебные высокие низкие напряжения передаваться.

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

Вот чтобы такие кадры не терять, коммутатор промежуточные данные складывает в промежуточный буфер. Этот буфер, он конечно достаточно большой, но все-таки он неограниченный. Поэтому теоретически может быть такое, что если у вас есть, допустим, коммутатор, в этот коммутатор вот три абонента, 1 сервер и 2 клиента. И оба клиента начинают на скорости 10 мегабит в секунду или 100 мегабит в секунду, это абсолютно неважно, гнать данные в сторону сервера. Они же физически могут это сделать, а у сервера тоже данные передаются на скорости в 100 мегабит в секунду, и он передает данные и получает данные вот на скорости в 100 мегабит в секунду. Он не может два потока по 100 мегабит в себя вместить. Поэтому как это будет физически вылететь? Вы начинаете передавать один кадр, второй кадр, третий кадр. И второй клиент тоже начинает передавать первый кадр, второй, третий кадр. И эти все кадры попадают во внутренний буфер. Из этого внутреннего буфера, соответственно, они потихоньку в сторону сервера уходят. Можете слово сервера заменить на интернет, например. Ничего от этого не изменится. И получится, что у вас канал до сервера загружен на 100%.

Буфер опустошается со скоростью 100 мегабит в секунду. А пополняется этот самый буфер со скоростью 200 мегабит в секунду. И, соответственно, у вас сальдо не сходится. Что у вас этот буфер начинает заполняться, заполняться, заполняться. И довольно скоро он заполняется целиком и полностью. А клиенты-то об этом ничего не знают. Они вам все еще продолжают посылать кадры. И в такой ситуации, да, коммутатор может кадр такой сбросить. Который приходит. Его надо переложить в сторону выходного абонента. А там уже занято. Там уже буфер переполнен. Но, тем не менее, мы все-таки рассматриваем сценарии относительно простые сейчас. То есть сценарий вида перегруженная сеть, как себя будет вести, мы разберем чуть попозже. И в нормальной ситуации у вас есть какой-то буфер. Этот буфер, предположим, нормального размера, достаточного для наших сценариев. И вы в этот буфер начинаете складывать кадры, которые пока нельзя отправить в сторону получателя. Но рано или поздно среда получателя освободится.

И вы сможете в эту среду впихнуть кадр. И, соответственно, освободить тем самым буфер. Получается, что вы технически можете несколькими разными участниками отправлять данные в пределах одной сети. Если у вас сеть будет построена на коммутаторах. Даже если у вас нигде еще тот самый полный дуплекс не используется. Даже если везде вы используете общую шину. Может быть ситуация, при которой и Вася, и Петя отправляют данные. И Петя, и Вася в тот же самый момент точно такой же кадр начинают отправлять в обратную сторону. Оба получателя, в смысле, оба узла, оба отправителя, и Петя, и Вася, посылают данные в сторону коммутатора. Коммутатор оба этих кадра принимает к себе, складывает во временные буферы. На каждой из них смотрит, куда отправлять. И каждый из этих кадров отправляет обратно, ну не обратно, в сторону того получателя, который оригинальный получатель был. То есть Вася отправил Петя, на самом деле Вася отправил коммутатору, а коммутатор, когда смог, отправил Петя. И наоборот, Петя отправил Вася, но на самом деле отправил коммутатору.

Коммутатор принял этот кадр, когда смог, отправил Вася. Вот получается технически возможность отправлять данные в сторону коммутатора нескольким разным участникам и даже возможно друг другу. Если у вас есть общая шина, при этом на самом деле не может быть ситуации, при котором в одном домене коллизии, в одном и том же проводе данные будут идти и к вам и от вас. То есть данные будут идти в сторону коммутатора и там они будут складываться в буфер и там они, когда среда освободится, из буфера будут заниматься, будут в анимации отправляться в сторону получателя. Но вот соответственно если у вас теоретически общая шина используется, вы должны будете передавать все данные либо в сторону коммутатора, либо от коммутатора к вам, но не одновременно. То есть та самая полудуплексная передача, которая у нас была с общей шиной, вот она здесь классическая и есть. Давайте проговорим про то, как устроен полудуплексный интерфейс, как он именно будет работать и почему он работает именно так.

Если у вас есть полудуплексный режим Ethernet, то есть Ethernet на самом деле используется с общей шиной, хотя это Ethernet по витой паре, у вас узел может испытывать коллизии. И соответственно этот узел, который может испытывать коллизии, он должен определять, что коллизия произошла и с этой коллизией как-то бороться. Включать схему SMA-CD. Каким образом с физической точки зрения это происходит? У вас узел всегда слушает среду, всегда слушает цепь ресивера, RX ресивер. И когда он, соответственно, что-то хочет передавать, он включает цепь трансмиттера TX и он замыкает эти цепи друг на друга. Он сравнивает то, что передается, что вы что-то передаете и вы принимаете. И вот он электрически сравнивает сигналы, которые отправляются на трансмиттере и получаются на ресивере. И, соответственно, если видит разницу, что на трансмиттере одно, на ресивере другое, он понимает, что случилась коллизия и дальше запускает алгоритм back-off-таймер и прочей всякой фигни.

Jam последовательности. Если вы используете сценарий, при котором каждый из узлов подключается прямым проводом к свечу, то есть у вас нету нигде никаких хабов, нигде нету коаксиальных проводов, используется везде строго витая пара и строго прямые подключения к свечам. И свечи между собой тоже соединяются. У вас везде используется протокол физической топологии точка-точка. И на самом деле вы можете воспользоваться следующим механизмом. Вы можете не замыкать цепь трансмиттера на ресивер. И не сравнивать то, что слушается в сети с тем, что вы передаете. Получится, что вы можете принимать данные какие-то одни, а отправлять данные какие-то другие. Если коллизии в этом случае не происходят, то есть не может быть такого, что вы начинаете передавать данные, а потом вам навстречу данные передаются. Они же физически передаются в случае витой пары по двум разным парам.

У вас есть первая и вторая пара трансмиттер, и там третья, шестая ресивер. Вы можете в первую и вторую контакты передавать одно, а на третьем и шестом ловить другое. Можете. То есть можно теоретически сказать, давайте мы не будем проверять на коллизии, давайте мы не будем сравнивать то, что передается на трансмиттере и ловится на ресивере. Если там будут разные данные прибегать, это просто нормальная штатная ситуация. Это мы передаем что-то одно туда и ловим что-то другое обратно. И в этом случае у вас получается дуплексная передача. Обратите внимание, чем дуплексная передача отличается от полудуплексной передачи. То есть чем half-duplex отличается от full-duplexа? Электрически ничем. Кроме того, что когда вы отправляете данные в half-duplex, вы сравниваете эти данные с тем, что прибежало на ресивер. А если вы отправляете данные в дуплексной среде, то есть у вас полный дуплекс включен, вы перестаете сравнивать то, что отправляется, с тем, что принимается. Да, если вдруг вы включаете со своей стороны режим полного дуплекса, то есть вы свой интерфейс переключаете в режим полного дуплекса,

это означает, что вы гарантируете как администратор, что коллизия произойти не может, что нет необходимости использовать схему CSMA-CD и бороться с коллизиями, которые происходят. При этом это ваша ответственность как администратора, чтобы коллизии те самые не происходили. Если вдруг вы возьмете несколько участников, соедините их через хаб и повключаете везде полный дуплекс, коллизии точно так же, как происходили, они будут происходить. Физику никто не отменял, коллизия может произойти в среде, которая по факту является с общей шиной. Но каждый из узлов, ему администратор сказал, работай в полном дуплексе, я тебе своей администраторской волей обещаю, что коллизии быть не может. Поэтому если коллизия происходит, каждый из узлов, который переключается в режим полного дуплекса, он просто перестает эту коллизию ловить и перестает повторно пытаться отправлять какие-то кадры, если вдруг эти кадры не удалось передать с первого раза. Поэтому если у вас используется современный Ethernet, схема CSMA-CD вам не нужна, потому что в современном Ethernet коллизии произойти не могут.

Поэтому вы должны и будете фактически обязаны использовать полную дуплексную передачу. Начиная с 10-гигабитного Ethernet, вы уже не можете даже на самом деле использовать халф-дуплексный режим, полудуплексную передачу. То есть вы не можете сказать, что у нас в 10-гигабитном Ethernet будет коллизия, потому что на уровне самого протокола сказано, отдельно используются пары на отправку данных, отдельно используются пары на прием данных. На этих парах сигнал физически столкнуться не может, никаких хабов для 10-гигабитного Ethernet нету, всегда только свечи, поэтому механизма CSMA-CD нету вообще, поэтому и полудуплексного режима тоже нету вообще. На уровне стандарта 1-гигабита в смысле 1000-BST. Здесь будет следующая ситуация использоваться. Что насчет 1-гигабит Ethernet? Вот самый последний пункт, который здесь на слайде написан. Начиная с 1000-BST только дуплексный режим. Фраза немножко спорная тем, что в стандарте, если почитать 1000-BST,

то есть, как он там называется, 802-3-AB, в 1000-BST технически возможно существование хабов-дуплексного режима. Как следствие, технически возможно существование хабов. Тем не менее, ни один производитель не делал хабов для 1000-BST. Как следствие, ни у одного производителя нету возможности организовать среду с общей шиной для 1000-BST. Просто на рынке таких решений нету. Теоретически они возможны. По факту, но вот не делают, не знаю, холодильник, совмещенный с пылесосом. Вот и в 1000-BST нету хабов, только свечи есть. На рынке просто отсутствует такого рода решение. Для других гигабитов есть. Для других гигабитов бывают хабы. Вот для 1000-BST, ну вот, не делали их. Стандарт предусматривает, если что. Но по факту их не бывает. Вы можете на интерфейсе 1000-BST сказать, что вам хочется использовать полудуплексный режим. Опять же, это физически означает лишь то, что вы будете сравнивать то, что вы получаете на ресивере с тем, что вы отправляете на трансмиттере.

Это все, что делается при включении полудуплексной передачи. Если вы включаете полудуплексный режим, то вы включаете вот эту дополнительную проверку. Если вы говорите, что не нужна дополнительная проверка, используем дуплексную передачу, то вы используете полный дуплекс. И у вас вот эта дополнительная функциональность проверки на коллизии отключается полностью. В современных Ethernet это дополнительная штука про проверку коллизии уже не нужна. Так. Да. Что касается важного замечания про дуплекс. Вы уже, наверное, поняли из того, что я говорил, что дуплекс можно назначать. То есть вы можете переключать ваш интерфейс в режим полнодуплексного или полудуплексного соединения. И на самом деле при полнодуплексном соединении, при фулл дуплексе, у вас просто часть электрического механизма интерфейса отключается. И дополнительная проверка на ошибки, она у вас тоже отключается.

Естественно, что везде в пределах домена коллизий вы должны выставлять одинаковые значения дуплекса. То есть если у вас есть среда с общей шиной, то вы обязаны на всех узлах в пределах этой самой среды с общей шиной, в пределах этого домена коллизий выставить полудуплексное соединение, half-duplex, потому что вам потребуется проверка на ошибки. Естественно также, что если у вас есть point-to-point соединение, в котором два участника, вы должны будете правильно выставить значения. Везде одинаково в пределах домена коллизий. Если хотите, можете выставить half-duplex. Если хотите, можете выставить фулл дуплекс. Это не важно. Главное, чтобы везде было одинаково. Если вы используете современный Ethernet, это означает, что у вас все линии физически будут point-to-point. Поэтому везде в пределах одного провода вы обязаны правильно выставлять дуплекс. Естественно, что если вы выставите на point-to-point проводе half-duplex, то это привлечет просто за собой неэффективное использование сети. Потому что в режиме полного дуплекса у вас 10 мегабит скоростную отправку, 10 мегабит скоростной приема.

Получается 20 мегабит. Если вы замените название стандарта 10 мегабит на 100 гигабит, неважно, смысл не изменится. Если вы включаете полную дуплексную передачу, у вас одновременно и отправка происходит на 10 мегабитах, 100 мегабитах, неважно, и прием на такой же скорости. То есть физически скорость передачи и приема данных в два раза больше, чем скорость только передачи или только приема. скорость только передачи или только приема. Если вы включаете Half-Duplex везде, то вы фиксируете, что в каждый момент времени ровно один участник вместо двух может передавать данные, и как следствие, теористически, количество данных, пересылаемое в единицу времени, оно будет меньше. Не обязательно это будет строго так, то есть вполне возможно, что у вас ровно один участник всегда передает данные, а второй только слушает. Но тем не менее, полудуплексная передача, она типа хуже, чем полнодуплексная, потому что если поддерживается и тот, и другой режим, то у полудуплексной передачи эффективность будет ниже.

Если у вас используется Point-to-Point соединение, вы можете с обеих сторон задать одинаковый режим дуплекса, полудуплекс, и оно будет работать. Вы также можете задать с обеих сторон полный дуплекс, и он тоже будет работать. И это будет правильно. И вы должны будете естественно правильно, как администратор, понять, физический канал у вас имеет топологию Point-to-Point, или физический канал у вас имеет топология общая шина. И в зависимости от этого правильно выставить режим дуплекса, для того, чтобы избавиться от вот этой самой неэффективной работы из-за неизвестной. Что будет, если вы правильно назначаете дуплекс с обеих сторон? Если у вас общая шина, то вы выставляете правильный режим дуплекса. Это может быть только полудуплексный режим, half-duplex. Если вы выставляете с обеих сторон каналов точка-точка, point-to-point, полудуплексную передачу, да, все будет. Теоретически возможна ситуация, когда два узла начнут передавать данные

одновременно. Да, они физически будут передавать данные по разным проводам, то есть канал от вас и канал к вам физически на самом деле на проводе точка-точка разные. Но вы такую ситуацию, когда вы одновременно передаете данные, из-за того, что вы настраиваете полудуплексную передачу, расцениваете как коллизию, и дальше запускаются все те процедуры, которые встречались у нас в случае обнаружения коллизии. То есть вы придумываете случайное число, отправляете джимпоследовательность и все такое вот прочее. Физически коллизия не произошло, но вы подумали, что произошла коллизия, потому что вы увидели данные, которые принимаются вами от другого участника, сравнили их с тем, что отправляете вы и подумали, что это случилась коллизия, потому что данные не совпали. И из-за этого стали работать неэффективно. Отправили джимпоследовательность, сказали, что у нас тут какая-то фигня и из-за того, что сосед, который сейчас в этот момент тоже отправляет данные, то есть, он чем-то устроил вам коллизию, он же отправляет данные, вы ему бежимпоследовательность послали и у него тоже данные испортились и он понял что тоже до произошла коллизия соответственно пора вот

запускать тот самый back of timer и все такое прочее если вы с двух сторон к провода . . полудуплексную передачу настроили до работать будет да будет работать неэффективно до будут коллизии до производительность будет сильно ниже чем она могла быть если вы с двух сторон провода . . настроили полный дуплекс ну вы молодец вы сделали все абсолютно правильно лучше сделать было невозможно коллизии быть не может двусторонняя передача данных в том числе и синхронная то есть вы отправляете соседу что-то сосед в это время что-то другое вам отправляет и вы не переживаете по поводу того что эти данные не одинаковые в случае халв дуплекса вы переживаете и вы запускаете процедуру отработки коллизии в случае . . канала и дуплексной передачи с обеих сторон вы не переживаете это нормальное штатное явление если вы сделаете что-то не так но например вы возьмете и будете использовать среду с общей шиной и дуплексное соединение настроите на этой самой среде физически это может выглядеть как то что вы возьмете хаба и к этому хабу подключаете васю который работает в полном дуплексе

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

случится одновременная отправка и прием данных этим самым абонентом с полным дуплексом вы проблему не заметите то есть если у вас исключительно слабо заполненный канал то есть в этом канале данные пробегают очень редко при таком сценарии работать тот самый абонент с полным дуплексом будет у него проблемы будут только тогда когда он и отправляет данные одновременно и к нему приходят данные то есть тогда когда порождается коллизия когда он начал занимать среду а кто-то еще ему вот эти самые данные в ответ впихнул вперед или когда кто-то передает данные а он не обращая внимание на то что среда занята все равно пытается в эту среду впихнуть данные вот если кто-то другой не занимает среду или делает это исключительно редко и наш проблемный абонент тоже занимает среду не часто проблем не будет то есть каľ hic muscles оптима же спасибоäm föróm ряде apolog sense of the но я вас контролирует это формально обрабатывать и то что к null воском splendid

Если же у вас будет происходить синхронная отправка кадров вашим участникам и каким-то другим участникам, то есть сначала тот другой начал передавать, а потом вы, как узел, которому администратор отключил проверку среды на отправку, на свободность перед отправкой, одновременно отправляете данные, случается коллизия, и в эту коллизию, соответственно, вы потеряете кадр, вы даже не будете пытаться его повторно переотправить. Нормальный узел, у которого произошла коллизия, он что делает? Он говорит, я сейчас придумаю себе случайное число, заткнусь на это случайное число, там микросекунд, а потом попытаюсь отправить кадр заново. То есть кадр висит в буфере, кадр отправляется целиком с самого начала, вот там есть у вас пачка ноликов и единиц, вы начали эту пачку передавать. Если вам удалось передать первый нолик, но не удалось передать затем единичку, вы повторно этот нолик будете передавать вместе со всеми остальными битиками, вместе со всей единичкой, потому что это все часть одного большого кадра.

Если от кадра голова прошла, а хвост не прошел из-за коллизии, вы будете повторно передавать все целиком, начиная с самого начала. Если у вас настроен правильный дуплекс, если вы поняли, что произошла коллизия, что надо повторно передать кадр, что да, может быть отдельные битики и прошли, но целиком сущность не прошла. Вот в случае, если вы настраиваете полный дуплекс, то вы не будете пытаться отрабатывать ситуацию с коллизией, и если вам кто-то передачу испортит, вы этого а не заметите, и б, вы не будете повторно отправлять эти самые данные. Вы будете продолжать шарашить в эту среду свои данные, тем самым усугубляя коллизию на самом деле, и вы будете терять свои отправленные кадры. То есть вы чего-то отправили, это чего-то превратилось в кашу, а вы сидите на попировании, ничего с этим не делаете. Вот если вы видите такого рода явление, то вы где-то ошиблись с настройкой. Если у вас есть... Да, давайте вернемся к предыдущему кадру, предыдущему слайду. Если у вас есть канал, допустим, Point2Point, в котором у вас есть один участник, узел полно-дуплексный, а второй участник half-дуплексный.

То есть вообще-то говоря, в Point2Point мы можем выставить любое значение, которое нам нравится. Хотим такое, хотим сякое. Лучше, когда полный дуплекс. Но если с двух сторон полудуплексный режим есть, то тоже работать будет. Если вы с одной стороны канала Point2Point и с другой стороны канала Point2Point настроите разные значения, получится проблема такого же характера, что у вас есть Вася, который отправляет данные и не заботится о том, что данные столкнутся, потому что он знает, что это канал Point2Point. А Петя, который сидит с настройкой half-дуплекс, он сравнивает то, что он принял и то, что он отправил. Да, физически коллизии в этом случае произойти не может, но он может попытаться взять и чего-нибудь отправить в надежде, что это общая шина, и никто ничего ему-то присылать в этот момент не будет по вполне объективной причине. А ему навстречу в этот момент, или даже через некоторое время после начала передачи, но все еще в течение передачи, придет встречный поток данных. Сосед не заботится о том, что канал надо ждать, пока освободится.

Он-то на вас шарашит все как следует. Поэтому вот у узла с полным дуплексом будет все хорошо. А у узла с half-дуплексом будет проблема, что он будет понимать, что это случилось коллизия, и будет пытаться отправлять кадр повторно. Если у вас, соответственно, используется физическая среда с общей шиной, то в этом случае кадры будут теряться безвозвратно. Если у вас среда с физической топологией point-to-point используется, и с двух сторон дуплекс настроен разный, то в этом случае у вас просто сеть будет работать неэффективно. С одной стороны вы используете full-дуплекс, с другой стороны half-дуплекс, и у вас тот, который full-дуплекс, абонент, он будет просто отправлять данные и принимать данные одновременно. У него все будет в порядке. Тот, который с half-дуплексом, он иногда будет думать, что случилось коллизия, хотя ее не произошло. И он будет говорить, ой, я что-то начал передавать, но давайте-ка вот вам джемпоследовательность. И снова пытается отправлять данные, и снова к нему приходят встречные кадры, и снова он говорит, ой, что-то опять мне не нравится то, как я передаю.

На самом деле он передает нормально, но он не знает, что это среда двунаправленная. И вот он говорит, ой, что-то я пытаюсь, а у меня не получается. Ой, что-то у меня не получается никак, все. Вот я еще раз пробую, и снова какие-то данные на встречу приходят. И каждый раз вот у этого half-дуплексного абонента будут проблемы с тем, чтобы отправить полноценный кадр. Особенно если его полно-дуплексный сосед постоянно на него кадры шарашит навстречу. Вот каждый раз, когда приходит кадр, и когда пытается отправить какой-то кадр half-дуплексный сосед, у half-дуплексного соседа будет мнимая коллизия. И у него будут, соответственно, проблемы с тем, что надо переотправить эти самые кадры. Каждый раз, когда случилась коллизия, в которую включен абонент, каждый раз back-off-таймер придумывается все больше и больше. Если 16 раз подряд у вас случилась коллизия при отправке одного и того же кадра, на интерфейсе возникает ошибка, и интерфейс сбрасывается. Поэтому если у вас сосед А полно-дуплексный, и он посылает много данных соседу Б, который half-дуплексный, и сосед Б попытается отправить хотя бы один кадр, но вот он попытается отправить, и тут коллизия.

Попытается еще раз отправить, и тут снова коллизия. И вот так 16 раз подряд случится. В принципе, не самая редкая ситуация, если у вас навстречу интерфейс загружен сильно. То, соответственно, у вас интерфейс просто падает с ошибкой, потому что 16 раз подряд не получилось отправить кадр. Следовательно, back-off-таймер вырастает до таких значений, что вы вообще ничего не можете отправить. И это просто обрабатывается как константа. 16 раз отправили, все, баста-карапузики, выключаем интерфейс, и говорим, что сеть просто тупо не работает. Поэтому не надо делать так, чтобы у вас с разных сторон одного и того же домена коллизий, или с разных сторон, скажем, point-to-point канала были выставлены разные значения дуплексов. Это будет явная ошибка администратора, если вы так сделаете. Далее. По поводу дуплекса теорию проговорили, даже про настройки проговорили. Давайте поговорим теперь про то, что называется скорость. Замечу, что в любом стандарте Ethernet, который бы вы не взяли, 10 BST, 100 BST, 1000 BST, 1000 BST, даже, не знаю, 10 G BST,

неважно какой стандарт, зафиксируйте стандарт, он вам однозначно определяет время отправки одного бита, однозначно определяет количество бит полезных, которые вы можете отправить в единицу времени. То есть на самом деле то, что называется скорость, оно однозначно определяется тем стандартом, на котором вы будете работать. И бывают интерфейсы, которые поддерживают ровно один стандарт. Ну, допустим, там вот 10 BST, какая-нибудь старая карточка Realtek 8029, возьмите ее в руки, вот она либо этот самый 10 BST поддерживает, либо 10 BST. У нее два разъема, и они оба 10-мегабитные. Вот один на витухе, а другой на коксиале. Есть карточки, на которых написаны буквки типа 10 на 100. И возникает предположение, что вот такой вот хитрый Ethernet, который может работать типа бы быстрее, типа помедленнее. На самом деле нет. На самом деле это интерфейс, у которого в него вставляется физический провод пятой категории с фишкой 8P8C на конце, обжатой по TA568, либо там таблица А, либо Б, после чего этот провод становится регистром Jack45.

И этот регистр Jack45 может использоваться с двумя стандартами 10 BST или 100 BSTX. И внутри интерфейса, который поддерживает оба стандарта, принимается решение, какой из стандартов использовать. Либо 10 BST, либо 100 BSTX. Одновременно оба, естественно, использовать нельзя. Если у вас поверх какого-то провода есть несколько соседей, допустим, вы взяли ноутбука, два ноутбука, соединили их прямым проводом, естественно, везде в пределах этого провода все абоненты должны работать в одном и том же стандарте. Не то что на одной и ту же скорости, а именно на одном и том же стандарте. Если вы возьмёте с одной стороны 10 BST, а с другой стороны 10 BSTX, да, скорость будет одинаковая, как бы номинально, на которой работает интерфейс. Но стандарты разные, они по-разному кодируют сигнал, по-разному используют вообще всё, по-разному работают. Поэтому 1000 BST, с одной стороны 1000 BSTX, с другой стороны не заведутся. Даже если они используют одинаковый провод, Даже если используют они одинаковый интерфейс разъема, они все равно работают принципиально по-разному.

И поэтому интерфейсы, которые даже на одной скорости работают, они разные. А уж те, которые на разных скоростях работают, они просто совсем электрически разные, они друг на друга вообще даже не похожи. У них общего только дырочка, куда вставляется провод. И, соответственно, если вы на интерфейсе видите написано 10 NAS, это означает, что у вас поддерживается два каких-то стандарта. Один с скоростью 10 Мбит, другой со скоростью 100 Мбит. И на самом деле физически есть две разные микросхемы. Одна, которая будет работать с одной скоростью, с одним стандартом. Другая микросхема, которая работает с другим стандартом. Возможно, они конструктивно будут объединены в одном корпусе. Но это надо понимать, что это именно два разных набора кода, два разных набора элементной базы, которые будут обслуживать эти самые стандарты. Бывает такое, что на интерфейсе с витой парой, вот как здесь нарисована какая-то сетевая карточка, тут написано 10 NAS, 100 на 1000. Бывает такое, что поддерживаются три разных скорости, на самом деле три разных стандарта. Как правило, если написано 10 NAS на 1000, это будет 10 BST, 100 BSTX и 1000 BST.

Бывает такое, что 10 NAS на 1000 на 10000, это еще добавляется 10 G BST. Если говорить про оптику, бывают интерфейсы, на которых написано 1, 3, 10 G. Как правило, это оптические интерфейсы, точнее не оптические, это интерфейсы, которые поддерживают в том числе и оптику. Для интерфейсов 1 ГБ и 10 ГБ, как правило, будут использоваться переходники, которые мы смотрели в разделе про оптику. Это SFP для 1 ГБ и SFP Plus для 10 ГБ. То есть, если вы видите на интерфейсе надписи 1, 10G и видите дырочку, в которую визуально можно вставить SFP, знайте, что в нее можно вставить и модуль SFP и модуль SFP Plus. Какой именно модуль вы решите выбрать? Медный, оптический, оптический для многомода, оптический для одномода, оптический с одним глазом, с двумя глазами, с четырьмя глазами, неважно. Вы можете вставить этот самый модуль SFP, а потом в эту SFP вставить уже конкретную среду.

Либо медный провод, витая пара нужной категории, либо нужное количество оптических разъемов и у вас все типа будет работать. Бывает такое, что карточки будут, соответственно, двух или трех-четырех головые. Вот как здесь на картинке нарисована карточка с двумя разъемами Ethernet. Это не означает, что в один из них втыкается 10 Мбит, а другой 100 Мбит. То есть, это было когда-то давным-давно актуально для того самого Realtek 8029, у которого была одна дырка для витой пары и другая дырка для Coxial, BNC-шный разъем. Но это был один и тот же интерфейс Ethernet, который работал на самом деле просто по одному из двух вариантов. Либо по Меде, либо по Coxial. У него была физика, которая завязана на витую пару, физика, которая завязана на Coxial. И дальше битики, которые передавались, они у них обрабатывались одинаково.

Вот, соответственно, в двухголовых современных карточках, четырехголовых, как правило, это серверное оборудование. Такие карточки заметно дороже, чем обычные PCI-ные карточки Ethernet. Будет использоваться более хитрый сценарий. У вас каждый из этих самых интерфейсов, вышестоящий операционной системе, видно как отдельную сетевую карту. Как отдельный интерфейс. Если вы захотите, вы можете увидеть вот этот интерфейс, как, допустим, локальная сеть 1, вот этот интерфейс, как локальная сеть 2, назначить на них разные IP-шники и все такое. То есть они будут выглядеть как отдельные адаптеры с точки зрения операционной системы. Чаще всего, тем не менее, на самом деле в таких сетевых картах два интерфейса делаются не для того, чтобы на них вешать два разных IP-шника. Предполагается, что вы будете каким-то образом агрегировать эти каналы. То есть вы вставляете такую карточку в сервер, прокладываете два параллельных патч-корда до коммутатора. И дальше на коммутаторе и на сервере прописываете настройку, что эти два физических интерфейса Ethernet, они логически объединяются в один.

Мы про агрегацию портов поговорим чуть попозже. Ну, не сегодня даже, наверное, ближе к пятнице. Но, тем не менее, такое бывает. То есть это требует специальной поддержки со стороны операционной системы и требует специальной поддержки со стороны свеча чаще всего. Вот. Да. Про многостандартные интерфейсы. Вот, собственно, они бывают. Это то, что вам нужно знать. Каким образом вы будете работать на каком-то конкретном стандарте? Если у вас есть многостандартный интерфейс. Вот он работает либо на скорости. 10 Мбит, то есть 10 BST, либо на скорости 100 Мбит, там 100 BSTX. Понятное дело, можно здесь перечислить все возможные варианты, на которых он будет работать. Ну, допустим, это будет такой самый простой вариант 10 на 100. Вот он может работать либо в одном стандарте, либо в другом. Как он определяет, как будет работать это все дело? Самый простой сценарий. Пришел админ и сказал. Работай на такой-то скорости, на самом деле на таком-то стандарте. То есть отключаем физику, которая работает на 10 Мбитах, включаем физику, которая работает на 100 Мбитах.

Если у вас с обеих сторон, естественно, провода используются, два разных интерфейса, они обязаны работать в одном и том же стандарте. Если с одной стороны вы будете бит отправлять со скоростью 1 бит за 100 нс, а другой за время 10 нс бит будет отправляться, то пока один ловит 1 бит, второй отправляет уже целый десяток. Вот он ему в панамку напихал этих самых десяток бит, а второй думает, что это такое, блин, ко мне такое приближало. Вообще ни кодирования не совпадает, ничего, и вообще тут походу 10 разных сигналов в одном смешалось. Поэтому вы должны будете работать, естественно, в пределах одной физической среды, у вас все узлы должны работать в одном и том же стандарте. Ну то есть на самом деле на одной и той же скорости. Самый простой способ этого добиться искусственно всех переключить вручную в нужную самую скорость. Однако это процесс, который, естественно, этот процесс может формировать ошибки.

За счет того, что требуется ручная работа, за счет того, что требуется принять решение человеком, ошибки здесь могут возникать. Поэтому в далеком, если мне память не изменяет, в 96 году была такая компания, которая называлась N-Way. И она придумала механизм. Если у нас есть интерфейс десятка и интерфейс сотка, и они конструктивно объединены в одном корпусе, и вы можете переключать их через софт, в каком режиме работать, вы можете специальным хитрым образом заставить вашего соседа понять, что вы хотите работать на сотке. Даже не то, что вы хотите, вы можете работать на сотке. А если поддерживается десятка и сотка, то нет причины не использовать сотку. Нет причины скатываться на более медленный стандарт. Каким образом эта штука будет работать? У вас, мы поговорим сейчас про медную пару, потому что в основном, когда говорят про автоматическое согласование Ethernet, оно идет про медную пару. Оно будет работать следующим образом.

Для начала давайте немножечко откатимся от автосогласования и подумаем про следующую вещь. Представьте себе интерфейс Ethernet. Ну то есть наверняка каждый из вас его видел. Наверняка у кого-то там свечи есть. Представьте себя стоящего рядом с таким свечом. У вас в руке патчкорд. В этот патчкорд воткнут компьютер. Вы втыкаете этот патчкорд в порт свеча и у вас что-то происходит. Что происходит? Подскажите мне, что происходит. Происходит магия. Загорается лампочка. Линк. Возникает вопрос, а как она загорается? То есть что происходит в проводе, что загорается линк? Вариант ответа электричества. Вот нету там электричества. Мы проговорили про то, как Ethernet отправляет какие-либо данные. Пока Ethernet не отправляет боевые кадры, никаких линков там не загорается. Цепь не замыкается. Нет. Линк загорается. Более того, если вы посмотрите, вот как бы зоркий глаз. На четвертый день заметил, что нет одной стены.

Зоркий глаз заметит, что в этом самом, в Ethernet, если вы втыкаете порт в свеч, лампочка загорается не сразу. Ну то есть она загорается почти сразу, но чуть-чуть происходит вот это все с задержкой. Эта самая задержка, она есть почему-то у всех. Это не объяснить тем, что вот какой-то один тормозной производитель делает какие-то тормозные лампочки, которые загораются не сразу. Даже если вы выключаете автосогласование, она все равно загорается не сразу. Дело в том, что в Ethernet есть специальные служебные битики, которые отправляются даже тогда, когда вы не отправляете никаких боевых данных. Если вы сидите и ничего не делаете, и вы хотите просто сообщить, что у вас сеть работает, вы отправляете специальные пиковые напряжения в сеть. Ну вот это то самое большое напряжение, о котором я говорил, плюс 0,7 вольта. Вы отправляете периодически эти самые плюс 0,7 вольта без минуса. То есть вы специально показываете, что это такой вот особенный сигнал, который не надо трактовать как какое-то чего-то лишнее.

Вы передаете только много и соответственно не передаете после этого мало. Если вы отправляете такой сигнал, и если вы слышите, что у вас такой сигнал приходит, вы понимаете, что у вас канал нормально работает. Исторически в Ethernet присутствует только вот этот вот самый механизм, а давайте периодически отправлять много в сеть без какой-либо на то причины. Ну просто чтобы показать, что с вашей стороны все есть. Если вы слышите, что приходят вот такие вот сигналы, то значит с той стороны тоже кто-то есть. Но если вы слышите три раза подряд вот это вот самое много, линк загорается. Если вы три раза подряд перестаете слышать это самое много, линк гаснет. Это такие типа Keeper Life пакеты, только это не пакеты, а просто сигнал повышенного напряжения. И отправляются они по умолчанию раз в 16 миллисекунд. Если вы передаете какие-то боевые кадры, то вот как только вы передаете боевой кадр, естественно, это... С bunch of個人, точнее, вы передаете, вы принимаете какой-то кадр, вы понимаете, что с той стороны кто-то есть, кто передает вам чего-то.

Но если никто ничего не передает, все равно есть вот эти вот пиковые сигналы, которые вы принимаете, которые вы, соответственно, можете поймать. И даже если вы ничего не делаете, вы все равно эти сигналы отправляете. Отправляются эти сигналы раз в 16 миллисекунд. То есть для 10 мегабитного Ethernet это раз в 16 миллисекунд. И это получается в... Когда у нас происходит? Раз в 160 бит тайм. Да, не наврал. Нет, наврал, наврал, много наврал. Сильно наврал. Раз в 160 тысяч бит. То есть раз в 20 килобайт, условно говоря. 16 миллисекунд, не микросекунд. То есть 1 бит тайм это 100 наносекунд 0,1 микросекунды. А время между этими всплесками 16 миллисекунд. То есть они отправляются достаточно редко. Я что-то начал говорить, считать. У меня цифры начали не сходиться. Я начал подозревать, что что-то не так.

Да, они отправляются достаточно редко. То есть раз, условно говоря, в 20 килобайт, вы вот этот самый пик отправляете. И учитывая, что у вас нужно 3 подряд этих самых сигнала получить для того, чтобы цепь считалась нормально работающей, 3 вот этих пика проходят за 48 миллисекунд. На самом деле вам может повезти, и вы можете услышать эти самые пики немножечко за меньшее время. То есть может быть такое, что вы вот только подключились и прям сразу через полмиллисекунды прибежал первый пик, а потом еще один, а потом еще один. И между ними пройдет 16 плюс 16 плюс там еще немножечко, типа 33 миллисекунды. Не меньше 32, но не больше 48. Если вы перестаете слышать эти самые пики, перестаете слышать эти бёрсты, они называются, по-моему, LPI, Link Pulse, что-то там, Identifier. Вот если вы перестаете слышать эти пиковые пульсы,

то вы должны понять, что у вас сеть упала. Три раза подряд не получили внепланово ничего. Ну, не внепланово, а три раза планово не получили, внеплановых кадров тоже не получили. Сеть понимает, что что-то не так, что интерфейс помер. То есть он ничего не получает, даже то, что гарантированно должно быть отправлено. Отсюда, кстати, циферка. Наверняка вы замечали, что есть такие протоколы, которые умеют обнаруживать падение канала и умеют переключаться на типа запасной канал. И у них у всех циферка 50 миллисекунд. Время обнаружения отказа. Вот эта вот циферка, она не совсем честная. То есть 50 миллисекунд на самом деле, это не более чем 48 миллисекунд. Это как раз те самые три подряд пропущенных пульса. Вот вы три подряд пульса пропустили, это как раз 48 миллисекунд, не более. Может быть меньше, может быть больше. Но, соответственно, за 48 миллисекунд вы гарантированно определяете, что три пульса пропустили,

и гарантированно определяете, что пора бы переключиться на запасной канал. Все протоколы типа ERPS, Ethernet Ring Protection Switching, EAPS, Экстримовский, Ethernet Automatic Protection Switching, они вот все переключаются на скорости 50 миллисекунд, то есть за время 50 миллисекунд. Rapid Spanning 3, если он везде использует топологию правильную, прописанную на нем, он тоже переключается типа на скорости, типа 50 миллисекунд время обнаружения отказа и перестроения топологии. Вот эти 50 миллисекунд, у них ноги растут как раз из этих самых трех подряд пропущенных линк пульсов. Ну там, да, их много технологий, которые так или иначе защищают от петель и быстро переключаются в случае, если у вас одна, как называется, одна сторона петли поломалась, вот он переключается в обратную сторону,

в другом направлении. Если вдруг вы не знакомы с этим провайдерским технологиями, типа EAPS, ERPS, Rapid Spanning 3 вас спасет. В Rapid Spanning 3 тоже время переключения 50 миллисекунд, точнее сказано от 50 миллисекунд, а дальше до бесконечности, потому что у Rapid Spanning 3 бывают режимы совместимости с обычным Spanning 3, когда он долго думает, тупит и там полминуты сосет лапу. Вот понятное дело полминуты это много, но меньше чем за 48 миллисекунд вы физически не можете обнаружить отказ канала в Азернете. Вот если вы перестаете принимать пульсы, вы это обнаружите за время от 32 до 48 миллисекунд. И вот спустя вот это время вы можете запустить какие-то механизмы. Все от этого значения отталкиваются. Мы сейчас говорим про физику. Вот если у вас лампочка гаснет на интерфейсе, она гаснет потому, что система на физике понимает, канал упал. А понимает, что канал упал, она пропустив три раза подряд те самые вот эти вот пульсы, которые должны приходить раз в 16 миллисекунд.

Умножаем 16 на 3, получаем 48. То есть вот это та самая магия, которая происходит, когда у вас втыкается порт в... В смысле не порт, втыкается патч-корд в порт коммутатора и с небольшой задержкой загорается лампочка. Она загорается через 48 миллисекунд. Ну, то есть через 32-48. И точно та же самая магия позволяет определить, что интерфейс упал. Потому что если вы возьмете и на абсолютно свободном канале Ethernet начнете мерить напряжение между всеми этими самыми линками, при условии, что у вас отсутствует Power Over Ethernet и всем остальным, у вас там нулевое везде напряжение будет. Нигде вы там 0,7 вольт не увидите. Но периодически они там пробегают. И пробегают они вот как раз в 16 миллисекунд один пик. По-моему, он... Ну да, вот маленький, коротенький. Как будто бы вы отправили какой-то битик.

Да. По поводу алгоритма автосогласования. Я начал говорить, что вот он работает, что он существует, и он позволяет автоматически согласовывать скорость. На самом деле он и дуплекс тоже может согласовать. Он будет использовать как раз эти самые пульсы, которые будут отправляться вне боевых данных. Если у вас включился порт Ethernet, то есть включили вы интерфейс, этот самый интерфейс сразу начинает отправлять пульс. То есть он первый пульс отправляет, как только вот он понимает, что что-то отправилось, он говорит, окей, я начал что-то отправлять. Вы воткнули провод, отправился первый пульс, второй пульс, третий пульс, и сосед понимает, что он у вас поджегся. И сосед к вам тоже. Он периодически отправляет эти пульсы. Вы воткнулись, вы поймали первый, второй, третий, у вас тоже порт поджегся. Вы можете, если захотите, этих самых пульсов отправлять больше, чем планируется. То есть никто вам не мешает отправлять их чаще, чем раз в 16 миллисекунд. Автосогласование будет использовать

так называемый Fast Link Pulse, FLP. Он будет говорить следующее. Давайте вместо одного пульса отправлять много. Например, 17. И 17 раз мы подряд будем отправлять с разницей в достаточно маленький промежуточек. Но и мы между этими самыми 17 будем оставлять еще промежуточек, для того, чтобы туда, если что, можно было вставить еще один битик. То есть выглядит это как один такт передаем пульс, один такт тишина. Один раз передаем пульс, один раз тишина. И так 17 раз подряд. Вот этот самый Fast Link Pulse, он позволяет вам на самом деле при необходимости отправить еще дополнительно 16 бит. Вы 17 раз передали пульс и 16 раз молчали. Вот пока вы молчали, вы тоже могли передавать пульсы. И, соответственно, это 16 бит, которые вы можете отправлять без полезных данных. То есть это не полезная нагрузка, это не те данные, которые вы передаете вместе с каким-то,

не знаю, кадром Ethernet. Это вообще не кадр. Это именно чисто пульсы, которые вы передаете, просто повышенное напряжение. Но вы можете передавать биты таким образом, так, чтобы сосед эти биты мог прочитать и мог из них какую-то полезную информацию изъять. И вот эти вот самые 16 бит, они могут указывать, как вы будете, соответственно, какие режимы вы можете поддерживать. Вы можете там сказать, я поддерживаю 10 мегабит. Или вы можете сказать, я поддерживаю 100 мегабит. На самом деле я поддерживаю 10 BST, 100 BSTX, 100 BST4, 1000 BST. Вот все поддерживаемые варианты, которые у вас там есть, у вас там есть флаги, и вы можете этот флаг поднимать и опускать. И эти флаги формируют 16-битное слово, и в это 16-битное слово вставляете между 17 пульсами в виде отдельных тоже пульсов. И, соответственно, раз в 16 миллисекунд вы шарашите эти самые пульсы, периодически, для того, чтобы дать соседу понять, что вообще происходит. Более того,

там на самом деле будет флаг вида. Я вижу нормально, что сосед работает. То есть, если вы используете 10 мегабит Ethernet, то вы раз в 16 миллисекунд будете получать просто флажочек. Я есть. Я есть. Я есть. Сосед не заботится о том, что он вас видит, или вы его видите. Он просто отправляет информацию, типа, «сеть работает нормально», «сеть работает нормально», «сеть работает нормально». На самом деле, это не означает, что сеть работает нормально. Но если вы прочитали этот флаг, этот пульс, то вы понимаете, «сеть работает нормально действительно». В механизме автосогласования с помощью FastLink Pulse будет указываться флажок. Я вижу соседа, который мне говорит, что сеть работает нормально. То есть это такая поддержка двустороннего взаимодействия, что действительно не только я отправляю какие-то данные, которые сосед может быть видит, а может быть и нет. А сосед точно меня видит и присылает меня обратно, и я точно вижу, что сосед меня видит. И вот в этом случае, если у вас FastLink Pulse работает, вы сможете обнаружить односторонний отказ, если данные от вас до соседа не проходят.

Например, у вас оптика, и в этой оптике отвалился один глазик. Тот, который от вас до соседа данные пересылает. Вот если вдруг у вас будет работать FastLink Pulse, в такой оптике оно обычно не работает, но если бы оно работало, то вы бы могли бы определить, что данные, которые от вас проходят до соседа, они не доходят до него. Он-то свои битки до вас посылал, как посылал, так и посылает. Если он вам просто будет говорить единичка, единичка, единичка, единичка, то вы из этого никакой вывод не сможете сделать. А вот если он вам говорит единичка, и, кстати, я тебя вижу. Единичка, и, кстати, я тебя вижу. Единичка, что-то я никого не вижу. Единичка, что-то я никого не вижу. Единичка, что-то я никого не вижу. Вы понимаете, от него до вас связь есть, а от вас до него связи нет. Вот, соответственно, в FastLink Pulse такая штучка будет встроена. И среди прочего там будет встроено, естественно, то, что вы поддерживаете такие-то режимы скорости, и сосед может понять, какие режимы скорости поддерживаете вы, режимы этого самого, режимы Ethernet, с каким дуплексом вы будете уметь, на каких режимах дуплексов вы умеете работать.

И он у себя сможет тоже принять решение, соответственно, в какой режим переключиться. Он вам посылает данные свои, вы ему посылаете данные свои, но в итоге кто-то из вас должен будет первый принять решение, что работаем на такой-то скорости. Механизм пульсов автосогласований описывается в спецификации, если у меня память не изменяет 10 бастей, я думаю, что именно в спецификациях ЕЕшных это все дело будет описываться. Дело в том, что эти механизмы, они на самом деле общие для всех стандартов. То есть, если у вас есть интерфейс, который работает на 10, на 100, на 1000, и вы в него втыкаете провод, который работает, который с другой стороны втыкается в абонент, который работает на десятки, у них фастлинг пульсы будут одинаковые. То есть, они одинаково должны отправляться раз в 16 миллисекунд, неважно какая скорость интерфейса, главное, что они друг к другу должны отправлять одинаковые эти самые линки, одинаковые линк пульсы.

И в этих линк пульсах, если поддерживается вдруг автосогласование с обеих сторон, кодироваться сигнал должен быть одинаково. Поэтому я думаю, что это все в 802.3. Штука должна быть описана. 802.1 очень вряд ли, а вот 802.3 наверняка. Точно не знаю, надо проверять. Если вдруг вам это интересно, можете поискать. Понятно, что вы на то, как работает автосогласование, повлиять не можете. Поэтому, в принципе, достаточно понимать, что оно есть, и достаточно понимать примерно, как оно работает. То есть, здесь понимания на пальце для обычного инженера будет достаточно. Важно знать, как оно работает детально. Естественно, если вы пишете свой вариант из интернета, но это не самое частое явление. Обычно достаточно просто понимать, в каких сценариях это автосогласование может отказать, в каких сценариях оно будет работать хорошо, и в каких сценариях его лучше не использовать вообще. А для этого достаточно, как мне кажется, понимания на пальцах. Так, отправляется оно в виде вот этих вот самых битиков.

И битики будут следующие. У вас, вы будете говорить, я поддерживаю, допустим, 10 BST Half Duplex. Это один флажок. Я поддерживаю 10 BST Full Duplex. Это другой флажок. Я поддерживаю 100 BST X на Half Duplex. Третий флажок. 100 BST X на Full Duplex. Четвертый флажок. То есть, каждая совокупность скорости и дуплекса, она отправляется как отдельный битик. И, соответственно, в стандарте, по-моему, предусмотрено 10 на 100 на 1000 Half и Full Duplex. И предусмотрен этот самый 100 BST 4. Вот четыре этих стандарта. Они между собой могут автоматически переключаться. Это механизм, который у большинства вендоров встроен. На самом деле, не у всех вендоров он может быть. То есть, может быть такое, что у вас интерфейс поддерживает 10 Мбит, поддерживает 100 Мбит. Ну, то есть, 10 BST или 100 BST X. Но автосогласования в нем нет. Естественно, свежее оборудование такое вряд ли вы встретите.

Но если это оборудование какое-то старое, то вот оно вполне может быть такое, что вы не увидите именно этого режима автосогласования. Кстати, этот режим патентованный. И вот его оригинальный патент был получен на компанию NWA. Так, для описания среды передачи данных тоже есть стандарты. То есть, я не знаю насчет того, что битики в описании среды. Но, безусловно, там, где описывается конкретный стандарт, допустим, 1000 BST, там, оказывается, описывается и процедура передачи одного отдельного бита. Да, еще по поводу автосогласования, того, что оно может не поддерживаться. Есть другие механизмы автосогласования, не вот этот вот NWA-овский. То есть, NWA-овский механизм, тот, который стандартное автосогласование в Ethernet, это механизм, который используется в подавляющем большинстве устройств.

Тем не менее, существуют другие реализации автосогласования. Поэтому, может быть такое, что на коробке с железкой будет написано автосогласование есть, вы ее втукаете в оборудование, а оно вот как-то не работает. Также может быть такое, что вы втыкаете в одно оборудование, автосогласование отрабатывает, в другое оборудование автосогласование не отрабатывает. Вот такое тоже возможно. Не все механизмы автосогласования между собой каким-либо образом совместимы. На моей памяти адпаки, голосовые штуки, старые ADSL-овские, как они назывались, FX-шки. Да. Вот. Они чувствовали себя как-то очень плохо. С Ethernet-ом, с автосогласованием. Да. По поводу того, что согласуются в итоге. Если у вас оба узла, которые находятся в проводе, ну мы сейчас говорим про современные Ethernet-ы.

Если, допустим, у вас есть два узла, находятся они в пределах одного провода, на них на обоих есть автосогласование и оно совместимое друг с другом. Вот у вас два узла подожглись. Как они будут работать? Они попытаются выбрать максимально лучший режим, который у вас есть. Понятно, что в случае канала Point-to-Point дуплекс полный лучше, чем дуплекс половинчатый. То есть Half-duplex хуже, чем Full-duplex, Full-duplex лучше, чем Half-duplex. Если оба узла поддерживают Half-duplex в какой-то конкретной скорости, естественно, он будет поддерживаться обоим участниками, то они выберут именно его. По поводу скорости. Если у вас, соответственно, поддерживается быстрый стандарт обоим участниками и медленный стандарт обоим участниками. Естественно, нет никакой причины выбирать медленный. Всегда будет выбран быстрый. Учитывая, что автосогласование поддерживает 10, 100 и 1000 мегабит в секунду, ну то есть 10, 100 и гигабит, всегда будет по умолчанию стараться согласовываться гигабит, если он поддерживается обоим участникой.

Если кто-то один или оба не поддерживает гигабит, значит будет пытаться согласовываться сотка. Если сотку кто-то из них тоже не поддерживает, то тогда будет десятка. То есть он проседает по скорости, пытается согласовать самый выгодный. Ну то есть как согласовать. Один присылает, я говорю, умею такое, такое, такое. А вы ему говорите, а я только десятку. Давай десятку тогда использовать. То есть вы отправили соседу, я поддерживаю только 10 BST. Сосед говорит, я поддерживаю такой, сякой, пятый, десятый. И вы в итоге сошлись на том, что надо упасть до десятки. Оба. По поводу, соответственно, дуплекса по умолчанию. Если вы поддерживаете оба режима дуплекса, то, естественно, согласуется максимально возможный, максимально выгодный полный дуплекс. Если вдруг один из узлов поддерживает только халф-дуплекс, ну, понятное дело, тогда только халф-дуплексы будут работать. Считается, что гигабит с халф-дуплексом лучше, чем 100 мегабит с фулл-дуплексом.

То есть это, конечно, спорное утверждение, но вот оно считается именно так. На сверхзагруженных каналах, в принципе, там может быть такое, что 100 мегабит с полным дуплексом будет интереснее, чем гигабит с халфом. Может быть такое вполне. Дальше. Если один из узлов не поддерживает автосогласование. В современных сетях все это согласование между узлом и коммутатором. Да, то есть у нас везде автосогласование работает только в пределах доменных коллизий. Только там, где отправляются электрические сигналы. То есть это в пределах одного провода. Поэтому если у вас современная сеть, у вас везде прямые провода от узлов до коммутатора. И у вас согласование идет именно между узлом и коммутатором. Если у вас один из узлов поддерживает автосогласование, а другой нет. Что это означает? Один отправляет фастлинк пульсы, а второй отправляет тупо вот эти вот самые периодические раз в 16 мс палочку. Отправил палочку. Через 16 мс еще палочку.

В этих палочках не зашифрованы никакие данные. Они просто отправляются и все. У 1 гигабит есть халф-дуплекс теоретический. Но практически ни одного производителя, который реализовал бы хабы для 1 гигабита нет для 1000 BST. Поэтому теоретически халф-дуплекс есть. Практически халф-дуплекса для 1000 BST нету, потому что он не нужен. Халф-дуплекс нужен для того, чтобы включать специальный обработчик для коллизий. Коллизий. Коллизия может быть только в среде с общей шиной. В реальном мире у вас везде только коммутаторы с каналами point-to-point до каждого абонента. У вас негде взять среду с общей шиной для 1000 BST. Поэтому да, у вас на оборудовании может быть поддержка 1000 BST халф-дуплекс. Просто потому, что вот этот модуль, который выполняет проверку того, что вы приняли с тем, что вы отправили, он уже есть. Его уже реализовали. Он вообще-то решает задачи для десятки и для сотки, но для тысячника, для гигабита, он как бы есть, его нельзя же выкинуть.

Сказать ему, да работай только с таким и с таким механизмом, а с вот этим не работай. Его уже сделали, поэтому вы можете сказать, что пусть ваш интерфейс работает на 1000 BST халф-дуплекс. Это не означает, что это стоит делать. Учитывая, что у вас везде будут только коммутаторы на гигабите, нет ни одной причины переключать ваш интерфейс гигабитный в режим халф-дуплекс гигабит. Если у вас один из узлов в пределах канала point-to-point поддерживает согласование, а другой не поддерживает, что у вас произойдет? Тот узел, который не поддерживает согласование. Это означает, что он должен выбрать какой-то режим работы. У него есть только один вариант, как выбрать режим работы. Ему нужно будет зафиксировать этот стандарт. Администратор приходит и говорит, работай на сотке. То есть у него нет выбора, я включился и принял решение, как мне работать на основании того, как звезды сошлись. Ему нужно какой-то заранее известный предсказуемый вариант получить.

Автосогласования нет, механизма считать положение звезд нет. Поэтому он должен заранее знать, как он будет работать. Вот он говорит, я буду работать, допустим, на 100 мегабитах. Если узел, который не поддерживает согласование, начинает работать на 100 мегабитах, вы можете попытаться угадать, что он работает на 100 мегабитах. Вы не можете это сделать гарантированно. То есть вы единственный способ, как можете это сделать, вы можете послушать, что приходит на ваш приемник. Если вы поддерживаете автосогласование, потыкались с соседа палочкой, фаст пульсами, он вам ничего не ответил. Что происходит под капотом? Вы говорите, ага, сосед не поддерживает автосогласование. Я, конечно, могу сказать, раз сосед не поддерживает согласование, он, наверное, дурачок и работает на скорости ЗЮ. Но, возможно, он работает на скорости совсем даже не ЗЮ. Возможно, его администратор выставил в какое-то конкретное значение скорость. Поэтому я сейчас попытаюсь угадать, какая скорость используется соседам с помощью механизма автосенсинг.

Этот механизм, это означает, что вы пытаетесь слушать сразу на всех скоростях. Ну, пытаться работать сразу на всех стандартах. Автосенсинг есть не у всех. Автосенсинг есть у большинства вендоров, но не у всех. Вы пытаетесь слушать сразу на всех стандартах, и если вы в каком-то стандарте пытаетесь услышать что-то, что похоже на правду, вы говорите, «О, мне кажется, что сосед передает мне какой-то кадр, я чего-то получил, какие-то битики». И эти битики реально складываются, похоже на то, что в каких-то тактах чего-то такое передалось. Получилось прочитать какой-то кадр на стандарте, допустим, 100BSTX. При этом в стандарте 10BSTX и в стандарте 1000BST в то же самое время не получилось прочитать никаких полезных данных. Поэтому, судя по всему, сосед использует скорость 100BSTX. Мы переключаемся и фиксируем скорость 100BSTX. Дальше мы работаем именно на ней.

Этот самый механизм автосенсинг, он очень ненадежный. Он требует, чтобы вам сосед чего-то отправил. Если сосед просто воткнулся и вам гонит линк пульса, вы никак на это не сможете поэтому угадать, какая скорость у него используется. То есть, да, он периодически посылает вам плюс 0,7 вольта. Это ничего не означает. Если он не посылает никаких боевых данных, вы скорость его угадать не сможете. Но если он вам пытается что-то отправить, вы-то им тоже пульса гоните, он понимает, что интерфейс в аппе. Он вам посылает какой-нибудь кадр, неважно какой. А вы говорите, о, вижу кадр, полученный по ходу на стандарте 100BSTX. Работаем теперь с этого момента в 100BSTX. Таким образом, вот вы можете попытаться угадать стандарт соседа, если у вас есть автосенсинг. Если у вас автосенсинга нет, то вы пытаетесь просесть до максимально тупой скорости, ну то есть до 10BST. Если у вас поддерживается 10 на 100 на 1000, но сенсинга нет, то вы говорите, сосед дурачок, сосед не поддерживает автосогласование.

Это может быть только в одном сценарии, если у соседа интерфейс сделан тогда, когда еще автосогласования не было, когда выбирать не было из чего. Поэтому сосед, видимо, работает на минимальной возможной скорости, на 10BST. Соответственно, по поводу дуплекса. Что здесь будет у вас? Если у вас с обеих сторон согласование есть, то вы выбираете максимально полезный дуплекс, который у вас будет. Если согласование с одной стороны есть, а с другой стороны нет, то вы пытаетесь угадать каким-то образом стандарт соседа. Либо вы говорите, он дурачок, работает на десятке. Либо вы говорите, я подслушал, что он передает, и работает он, допустим, на сотке. Неважно, что получилось в итоге. И вы используете режим дуплекса, так называемый, по умолчанию. Режим дуплекса по умолчанию это для десятки и сотки half duplex и для gigabit full duplex. То есть, если, допустим, вы подслушали, что сосед передает данные на 100 мегабитах, но это не получилось не из-за автонегушиейшен, а из-за автосенсинг, то вы падаете до half.

Вот такая вот штука. При этом, естественно, если вы со своей стороны взяли, запустили автосенсинг, услышали кадр, передающийся на 100 мегабитах, сказали, давайте мы теперь будем работать на сотке. Режим дуплекса по умолчанию для сотки half, поэтому мы будем работать в режиме 100 half. Если у соседа запущен режим 100 full, то, естественно, у вас будут проблемы с тем, что с вашей стороны периодически не будет удаваться отправить кадр в сторону соседа. Сосед вам посылает какой-то кадр, вы в этот момент тоже пытались чего-то отправить. У вас с вашей точки зрения случилась коллизия, вы пытаетесь переотправить кадр через некоторое время. Потом снова вам сосед присылает какой-то кадр, снова он вам портит всю малину, снова вы говорите, что-то как-то не пошло. И вот если там 16 раз подряд все не получится, то у вас интерфейс будет падать. Вы увидите несовпадение дуплексов по количеству ошибок на интерфейсе. Если вы видите, что у вас счетчики ошибок различных по категориям начинают расти,

либо интерфейс просто падает, либо интерфейс не падает, но что-то как-то скорость проседает, либо вы смотрите на количество коллизий и видите, что у вас есть коллизии на интерфейсе, на котором вообще-то коллизий быть не должно. Ну то есть, например, point-to-point канал, витая пара, в ней негде столкнуться разным данным, приходящим от разных участников. Они физически разделены. Одна пара на отправку, одна пара на прием. Или там две пары на отправку, две на прием. И получается, что у вас физически коллизия быть не может, но счетчик коллизии растет. Это означает как раз, что вы где-то используете режим дуплекса, не подходящий для этой канальной среды. Не подходящий, по крайней мере, для соседа. Если вы фиксируете с обеих сторон half-duplex, да, коллизии будут, но оба участника будут правильно с этими коллизиями пытаться обходиться. Это будет не совсем нормальная настройка для этого канала, но тем не менее работать будет. В случае, если у вас только с одной стороны будет зафиксирован half-duplex,

а с другой стороны будет full-duplex, сосед вам постоянно будет портить малину. Поэтому, если у вас с одной стороны автосогласование почему-то выключено, и там, где выключена настроена скорость, неважно какая, и в полный дуплекс, то, соответственно, это будет означать, что с другой стороны постоянно будет проблема. Поэтому не надо так делать. Если у вас оба узла поддерживают автосогласование, включайте автосогласование. Автосогласование – штука хорошая. Никакой, скажем, задержки, это самое автосогласование не вносит дополнительной. Вспоминаем, да, как работает поднятие интерфейса в app. Оно работает следующим образом. Он ловит три подряд пульса, и после получения трех подряд пульсов он включается. Так вот, в первом же пульсе, если сосед поддерживает автосогласование, сосед присылает вам информацию, какие режимы он поддерживает. И вы сразу после первого же получения вот этого самого пульса говорите, окей, мы приняли решение, что сосед поддерживает вот такое, мы поддерживаем вот такое,

мы включаем вот такой вот режим. Поэтому на включение интерфейса вам требуется 48 миллисекунд, ну, 32-48. А на принятие решения по автосогласиям требуется получение всего лишь одного пульса, которое происходит до получения третьего пульса, которое происходит до включения интерфейса в абсолютно любом случае. Поэтому не надо выключать автосогласование, если оно у вас везде поддерживается. Оно хорошее. Есть, правда, один неприятный момент. Если у вас канал, который вы используете, физическая среда, скажем, не канал, физическая среда, она достаточно хороша для того, чтобы работать на скорости, допустим, 100 BSTX. Ну, на скорости в 100 мегабит. Достаточно хороша для стандарта 100 BSTX. Но недостаточно хороша для 1000 BST. Например, это длинный патч-корд, длинный кабель пятой категории. Не 5, а именно 5. Вот там 100 метров. Вот 100 BSTX на нем работает хорошо. 1000 BST на нем начинает работать с проблемами. Автосогласование, оно работает всегда на минимальной скорости.

Оно работает вот на тех самых пульсах, которые работают одинаково во всех трех стандартах. Что 10 BST, что 100 BSTX, 100 1000 BST. Пульсы у всех одинаковые. Они работают как бы так, чтобы понять, их можно было даже медленному дурачку. Так вот, если у вас два гигабитных соседа, которые поддерживают и гигабит, и 100 мегабит, и 10 мегабит, соединяются таким длинным-предлинным кабелем, они эти пульсы посылают, они эти пульсы ловят прекрасно, эти пульсы читаются хорошо, потому что они как бы передаются так же понятно, как и в 10 BST. И два узла говорят, и я поддерживаю гигабит, и сосед поддерживает гигабит. Вот сейчас у нас пройдет три пульса, мы сможем включить интерфейс, и мы будем кадры передавать на скорости 1000 BST. После того, как это все дело происходит, у вас лампочка загорается, интерфейс поднимается в АП, вы принимаете решение 1000 BST, окей. Вы начинаете передавать кадры на скорости в 1000 BST, в 1 гигабит в секунду, и у вас эти кадры не проходят, потому что они передаются с помощью импульсов, которые слишком короткие, слишком маленькие по продолжительности, и их наводками портят так, чтобы невозможно было вычленить оригинальный сигнал.

Поэтому, если у вас автосогласование бы просело до 100 Мбит, все бы работало хорошо. Но автосогласование не умеет проседать, оно всегда выбирает самый быстрый режим работы, который только есть. Если оба узла поддерживают гигабит, да, он согласует гигабит. Не важно, что кабель его не выдерживает, он же не тестирует кабель. Поэтому имейте в виду, что такая вот штучка, она бывает. И если вы используете какой-то кабель не очень хороший, с какими-то повреждениями или не способный работать на нужную вам скорость, автосогласование этого не определит. Качество физической следы оно не отслеживает. Оно лишь говорит, что я узел, поддерживаю такую скорость. И сосед говорит, я узел, поддерживаю такую скорость. Среда вам не сообщает, а я среда не могу вас соединить на скорости такой-то. Она лишь вам сообщает на минимально возможной скорости, что вот сосед прислал тебе вот такие вот биты. Что значит на минимальной возможной скорости? На десятки. Очень условно говоря, продолжительность одного пульса, это продолжительность передачи одного такта на скорости 10 мегабит в секунду.

Вы сначала договариваетесь на 10 мегабитах о том, что вы умеете работать на гигабите, а потом вы переключаетесь на гигабит и уже ни о чем не договариваетесь. Если среда не выдерживает, ну это значит ваша проблема. Приходилось сталкиваться с тем, что самодельный патч-корд визуально очень хороший, на сотке работает нормально, на гигабите не работает. Вот это что значит на гигабите не работает? То и значит, что втыкаешь в два порта двух разных узлов, они говорят, я поддерживаю гигабит, включается гигабит и все. И среда не позволяет передавать данные на одном гигабите. Данные просто не проходят. Вот, да. Пришла пора вспомнить про тот протокол, про который я говорил, что он работает по одной витой паре. 1000 BST1. Я спрашивал, как по-вашему он может быть применен? И, по-моему, пришла пора про него рассказать. Очевидно, он используется в тех сценариях, где не хочется прокладывать много проводов.

То есть, где хочется сэкономить на кабелях, на той самой прокладке. Где нужно минимизировать количество этих самых проводов, занимаемый размер. И все вот такого вот характера явления хочется обеспечить. Понятное дело, в корпоративной среде это не требуется. То есть, если у вас есть компания, вы вполне можете поставить стойку. В эту стойку воткнуть 19 дюймовый свитч. Напихать в этот свитч столько проводов, сколько вам захочется. Да, может быть такое, что этих проводов будет много. Да, может быть свитч будет большой. Но, тем не менее, все равно стойка занимает место. Все равно, как бы, вот те 19 дюймов, которые у нее есть, размеры. Вы никуда от них не уйдете. 1000 BST1 придуман специально для автомобилей. Там, где требуется именно минимизировать размер коннектора, минимизировать размер самого провода, минимизировать размер оборудования, которое будет с этим всем делом работать. Более того, там действительно реально используется всего одна витая пара и там используется полный дуплекс.

Я, честно говоря, не знаю, как они реализовали, как они придумали работу полного дуплекса по одной витой паре. Но, тем не менее, это факт. 1000 BST1 это стандарт, который специально для автомобилей позволяет вам передавать достаточно много данных и в режиме полного дуплекса. Вы ставите маленький свитчик, автомобильный, хитрый. Вы подключаете к этому свитчу, допустим, приборную панель, как в новой Mercedes-E-E сделано. Там приборная панель и мультимедийный компьютер для переднего пассажира. Вот тут большой экран, который на консоли есть. Они конструктивно соединены между собой. И это достаточно большой экран, на 1920 на 720 точек каждый. Да, это достаточно много изображений. Если вам хочется на оба эти экрана выдавать практически Full HD картинку, то вам потребуется много полосы пропускания. Да, 1000 BST1, если вдруг интересно, понятное дело, вы в реальном мире с ним работать не будете до тех пор, пока вы не хотите именно ковыряться именно в автомобилях, писать приложение для автомобилей. Но если вдруг просто любопытно пасовать нос во всяких разных отраслях,

где что-то интересное творится, то вот 1000 BST1 стандарт, который реально работает всего по одной витой паре и позволяет пропускать через себя 1 ГБ. Обратите внимание на то, что ГБ, какой бы он ни был, он может быть по одной витой паре, может быть по 4-м витой паре, может быть по 2-м тоже бывает, может быть по оптике, может быть по меди. То есть неважно какой ГБ, он все равно позволяет через себя пропускать ровно 1 миллиард бит в секунду. Бывают распространенные заблуждения, связанные с тем, что ГБ, в целом выходит дороже, что ГБ лучше по оптике, чем по меди. Нет, ГБ по оптике не лучше, чем ГБ по меди. Он ровно, такие же биты позволяет передавать ровно столько же в единицу времени. Если для вас ключевой параметр это скорость, оптика ничем не лучше, чем меди. И не надо, допустим, думать, ах, как бы мне развести руководство для того, чтобы всех моих пользунов подключить по оптике. Не надо этого делать. Это дороже, чем по меди.

И главное, это бессмысленно. Если у вас пользователей можно подключить по меди, естественно, есть смысл использовать медь, потому что она просто дешевле. С точки зрения битов, которые передаются, и там, и там одинаковые нолики, и одинаковые единички. Они, может быть, формируют разные сигналы, закодированы в разных сигналах, разных импульсах. Но для вас импульсы не являются какой-то самоцелью. Для вас целью является передача данных, передача кадров из Эрнета в виде ноликов и единичек. И вот они действительно могут передаваться в виде ноликов, в виде единичек. Сами нолики и единички одинаковые там и там. Количество ноликов и единичек одинаковые там и там. Поэтому гигабит по меди, гигабит по оптике абсолютно одинаковые гигабиты. Вы должны будете только опираться на физические ограничения, которые у вас есть. В основном по длине. При выборе между гигабитом и оптикой. Вот. Далее. Чего у нас тут еще будет? По поводу самих ноликов и единичек.

Да, на физическом уровне передается аналоговый сигнал, импульсы. Эти импульсы могут быть закодированы по-разному. То есть они могут передаваться в виде пучков света. Или в виде электромагнитной волны в металлическом проводнике. В виде там плюс 0,7 вольта, минус 0,7 вольта. Они могут быть закодированы по-разному. То есть один и тот же бит единичка может быть представлен по-разному в разных стандартах Ethernet. То есть не обязательно, если в десятке используется манчестерский код, то в сотке тоже будет использоваться манчестерский код, и единица будет передаваться как много и мало. Она может быть закодирована совсем по-другому. Может быть такое, что, соответственно, там единица будет передаваться в виде 0,7 вольта, а нолик будет передаваться в виде там минус 0,7 вольта. Но следом за ними пойдет какой-то еще дополнительный такт, в течение которого будет передаваться какое-то служебное третье напряжение, по которому можно будет определить ошибку и восстановить оригинальные данные.

Как бы там ни было, вы, если хотите передать нолики единичке, вы формируете какой-то аналоговый сигнал, передаете его в среду и вычленяете из среды на получателя с помощью замеров значение этого самого сигнала и восстанавливаете оригинальный поток ноликов и единичек. Может быть такое, что отправитель чего-то отправит, а получатель чего-то примет не то, что отправлялось. Ну, в виде там наводки или чего-то еще. Там прошла наводка, и вы передали там плюс 0,7 вольта, а получили 5 вольт. И вот вы говорите, это точно не могло быть ни нолик, ни единичка, вообще ничего. То есть, это просто какие-то данные побились по дороге, там что-то передавалось, а что непонятно. И вы такие нолики единички можете не обрабатывать. То есть, вы не можете их не обрабатывать совсем. Но, понятно дело, что это будет уже ваше предположение, что вот эти вот 5 вольт, которые пришли, они больше похожи на единичку, чем на нолик. И дальше вам нужно будет понять, какие из этих бит побились совсем нечитаемо,

а какие действительно, ну вот вы передали 5 вольт, вы вообще-то говоря передавали 0,7, но вот они пришли в виде 5 вольт. И вы правильно получили эти самые 5 вольт, действительно правильно восстановили из этого оригинальную единицу. Вам потребуется, соответственно, какие-то из этих ноликов и единичек тоже в них нести какую-то дополнительную информацию избыточную. И, соответственно, эти нолики и единички, которые будут передаваться, они будут частично полезные, те, которые вышестоящее приложение заказало передавать. И частично это будут нолики и единички, нужные именно для работы самого Ethernet. То есть это будут уже не просто какие-то пульсы, которые вы отправляете, а именно нолики и единички, но они будут являться заголовком, скажем, служебными данными кадра. К вам приложение сказало, отправь вот это вон ему. Вы написали с помощью ноликов и единичек, чего надо передать. Дальше к этому добавили нолики и единички заголовки Ethernet и отправили. И вот эти нолики и единички, они служебные. Они в оригинальных данных, которые вам надо было передать, отсутствовали. И если вы передадите по сети это все на получателя,

получатель нолики и единички служебные прочитает, отбросит, а полезные нолики и единички уже передаст дальше и выше. Во всех стандартах Ethernet кадр, который будет передаваться, ну, в виде тех самых ноликов и единичек, будет примерно одинакового стандарта. То есть они будут одинакового формата, иногда будут различаться в деталях, но в целом они будут примерно одинаковые. Вот примерно такие вот кадры будут у нас передаваться. Они не в масштабе, то есть здесь я старался поля, которые побольше, сделать побольше, поля, которые поменьше, сделать поменьше, но они не все в масштабе. У нас будут два формата кадра в основном использоваться. Это кадр формата Ethernet 2, помните? Dix, Digital Intel Xerox, придумали в каком-то там лохматом году. Стандарт Ethernet, потом придумали Ethernet 2, и потом все это дело в 83-м году добили в 802.3 комитетом. Вот у Dix и у 802.3 были разные форматы кадров.

Так, вот это самое преамбула у нас будет 1.0.1.0.1.0.1.0.1.0.1.0. В случае, если у нас Ethernet 2 вот так 64 бита, чередование 1.0.1.0, последний бит, естественно, 0, а первый единичка. Если у вас преамбула 802.3, она продолжается 63 бита, 1.0.1.0.1.0.1.0, последний бит единичка, а последний самый бит после этой 63-битовой преамбула будет 1 бит Start of Frame Delivery. Он иногда вот так записывается. SFD или записывается SOF, как у меня на слайде. Расшифровывается как Start of Frame. Означает этот битик следующее, что преамбула закончилась, и пора передавать уже боевые данные. Назначение его, в общем, достаточно такое специфическое, то есть ему можно было бы и не делать. 802.3 комитет решил его сделать на случай, если вдруг два узла

одновременно начинают передавать данные, но, соответственно, они друг у друга устраивают коллизию, но поскольку они используют одинаковое физическое кодирование, и если вдруг у них случится смещение смещение друг относительно друга на ровно 2 бита, 4 такта, то произойдет, соответственно, следующее, что у вас в одном узле начинается передавать единичка нолик, потом второй узел тоже начинает передавать единичку в то время, когда вы передаете свою единичку, и ваши единички, ваши нолики начинают совпадать. Вот для того, чтобы преамбула могла устроить коллизию, вот этот самый битик SFD нужен, если вдруг у вас два узла начинают передавать данные не одновременно, а с небольшим смещением друг относительно друга, которое на каждом из узлов получается смещенное ровно на некоторое количество бит, на 2 бита, на 4 бита.

Они же 1, 0, 1, 0, 1, 0, 1, 0. То есть может быть такое, что вы передаете свой 1, 0, начинаете третью единицу передавать, и к вам доходит первая единица. Вы передаете плюс 0,7 вольта, сосед прикладывает 0,7 вольта. Что это означает, что 0,7 вольт? Значит, что у вас не складывается все это дело, что у вас напряжение между этим самыми штуками будет 0,7 вольта. То есть те же самые 0,7 вольта. И вы говорите, окей. Дальше вы начинаете 0 отправлять, до вас доходит следующий 0 от соседа. Вы опять меряете, опять не минус 0,7. Вот поэтому в оригинальном кадре Ethernet 2, который был, диксовский, такие ситуации обрабатывались плохо. В случае, соответственно, с 802.3, вот этот вот самый битик, он нужен как раз для того, чтобы такие штуки отрабатывать. В Ethernet 2 биты SFD нет. Далее. Следующий момент. У нас начинается передача каких-то более-менее полезных данных. Преамбула она вот такая, типа служебная. Она нужна только для того, чтобы дать понять всем остальным участникам, чуваки, я занимаю среду,

я сейчас начинаю передавать боевые данные. Дальше начинается передача осмысленных данных. И она одинаковая, что в Ethernet 2, что в 802.3. Вы указываете, кто и кому посылает этот кадр. Ну как вот письмо отправляете на почту, относите конверт. И на этом конверте пишите, от кого, кому. То же самое и в кадре Ethernet. Вы отправляете, от кого и кому. Вложение 802, 802.3. Да, обязательно. Я сейчас про них расскажу чуть попозже. В случае, соответственно, с кадром, что Ethernet 2, что 802.3. Вы указываете отправителя, указываете получателя. И давайте вспомним, какой задачей был вдохновлен Ethernet, когда он создавался. Протокол этот создавался для средств общей шины. У вас есть среда с общей шиной. Провод, тянущийся через всю организацию. Соответственно, к этому проводу подключается, допустим, 50 компьютеров. Один из компьютеров

хочет другому отправить кадр. Он указывает, кому он посылает кадр. Указывает получателя. И здесь указывается 6-ти байтовый уникальный адрес получателя. И начинает этот кадр отправлять в сеть в виде ноликов и единичек. На самом деле, в физическую среду в виде сигналов. Ну, там, плюс 0,7 вольт и минус 0,7 вольт. Эти плюсы и минусы 0,7 вольт слышат вообще все 50 участников. Нет возможности от одного узла до другого в среде с общей шиной отправить сигнал, так, чтобы этот сигнал все остальные не услышали. Вы отправляете плюс 0,7 вольт и минус 0,7 вольт. Все узлы в общей шине слышат эти самые 0,7 вольта. Все узлы воспринимают это как нолики-единички. У всех узлов нолики-единички отправляются на обработчик кадра Ethernet. Все узлы видят преамбулу, все узлы видят получателя. И в этот момент происходит магия. Только тот, кто является оригинальным получателем этого кадра, кто является легитимным получателем этого кадра, продолжает его обработку. Все остальные говорят, я получил какой-то кадр,

который мне не адресован. Я получил сигнал. В этом сигнале нолики-единички. В этих ноликах-единичках кадр. И в этом кадре указан получатель. И это не я. Я зажму, и все дальше не буду обрабатывать этот кадр. Здесь, естественно, будет использоваться честность всех участников. Участники, которые получают какие-то кадры, которые им не адресованы, не должны смотреть, что там внутри передается. Вы не можете повлиять на то, что участник какой-то, который ваш кадр кому-то третьему получит, он непременно его читать не будет. На этом основано на самом деле то, что если вам хочется подслушать, что передает какая-то машинка, вот у вас есть непонятный черный ящик, у этого черного ящика Ethernet есть разъем, и вы хотите узнать, что в этом проводе Ethernet передается. Вы должны взять, подключить машину со снефером к каналу между черным ящиком и чем-то там еще,

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

в котором указан какой-то получатель, и этот адрес ваш, вы его читаете, этот кадр дальше. Если вы получаете кадр, а в этом кадре написан получатель, и этот получатель не вы, то вы этот кадр должны проигнорировать. Нет способа заставить вас его проигнорировать, кроме вашей доброй воли. Вот, дальше указывается 6 байт отправителя. Обратите внимание, получатель идет перед отправителем, для того, чтобы принять решение о том, что мне это неинтересно, мне это надо проигнорировать, вы могли как можно раньше. Чем раньше вы примете решение, тем больше системных ресурсов вы оставите свободными. Поэтому получатель идет самым-самым-самым первым местным пунктом, который вы будете анализировать. Прочитали первые 6 байт, поняли, это не мне, выкинули дальше, остальное не анализируйте. Если вдруг вы приняли решение его дальше анализировать, потому что это вам, вы читаете 6 байт мак-адреса источника. Вот. Эта схема и в получателе и в отправителе одинаковая.

Дальше, соответственно, 2 байта хитрого поля, которое называется EtherType в Ethernet 2 или поле длина в 802.3. В разных стандартах, соответственно, это сделано по-разному. Оно размер имеет одинаковый, но реализация его и обработка этого поля будет, соответственно, различаться. В оригинальном Dix-овском Ethernet 2 здесь хранилось чего внутри? Указание типа вложения. И, соответственно, тип вложения вы здесь указывали, допустим, 0800 16-ти ричные, например, Ethernet, и сразу было понятно, что дальше пойдут данные, какой Ethernet, 0800 IP протокол, IPv4, и дальше идут какие-то данные, которые сразу понятны. Эти данные надо передать обработчику IP. После чего идет поле с данными, после чего идет чек-сумма, которая нужна для того, чтобы убедиться, что те 0,7 вольта и минус 0,7 вольта, которые вы получили, действительно соответствовали ноликами-единичкам, ничего не побилось по дороге.

Вот. Недостатком такого кадра, Ethernet 2, будет являться следующее. У вас есть слот-тайм. Помните, мы начали разговор про Ethernet с того, что у вас есть бит-тайм и слот-тайм. Слот-тайм – это время, за которое бит, который вы отправляете, должен пробежать до самого-самого-самого дальнего угла сети и вернуться перед тем, как вы завершите передачу кадра, потому что, соответственно, у вас нужно эту самую передачу кадра завершить для того, чтобы стереть кадр из буфера. Если вы сотрете кадр из буфера, потому что передача будет завершена, и тут к вам прибежит коллизия от того, что там первый бит какой-то столкнулся с боевыми данными, то вы данные эти самые потеряете. Вот. Что здесь будет важно? Важно здесь будет следующее. У вас есть ограничение на минимальный размер кадра. И это самое ограничение на минимальный размер кадра

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

то получится следующая фиговина. Вы отправляете первый битик, второй битик, третий, 510. У вас где-то в самом дальнем углу сети, если сеть очень-очень-очень длинная, случилась коллизия. Она очень длинная, но не настолько длинная, чтобы противоречить максимальному размеру сегмента. И дальше к вам возвращается коллизия. И коллизия вернулась в пределах слот тайма, но уже после того, как кадр закончил передаваться. Вот если у вас такое произошло, то вы уже кадр стерли из буфера, вы не имеете возможности с этой коллизией ничего сделать. Такая штука называется Late Collision. И соответственно, у вас будет ограничение на размер данных снизу, для того, чтобы кадр целиком получился никак не меньше 512 бит, включая преамбула. Вот. В 8022 есть механизм, который, соответственно, позволяет дополнить эту штуку. Если вы не можете передавать меньше, чем 46 байт в кадре Zerney 2, а 46, как понятно, это вот ровно столько,

сколько нужно, чтобы получилось со всеми вот этими заголовками 64 байт или 512 бит. Если вы не можете передавать меньше, чем 46 байт, а хочется, ну, допустим, у вас есть IP-пакет, который вот имеет заголовок, допустим, 20 байт и чего-нибудь еще вложения, ну, какой-нибудь там ICMP. Вот. Ну, в сумме получается, ну, допустим, там 32 байта. Вот вам очень хочется передать IP-пакет размером 32 байта, и вы хотите его вложить в Ethernet 2 кадр. Что делать? 32 сюда нельзя вкладывать, потому что сразу после 32 байт не должна идти чек-сумма. У вас должно быть минимум 46 байт. Поэтому здесь как раз будет использоваться следующая схема. Вы указываете IP-пакет, который у вас здесь есть в виде ноликов, единичек, указываете все 32 байта этого IP-пакета, а остальное добиваете мусором, нулями или чем-то еще, таким образом, чтобы минимальный размер кадра получился все-таки каким-то разумным. Ну, то есть, добиваете до 46 байт

в поле данных нужные вам или ненужные вам содержимые. Получается, что если вы получили кадр из Ethernet, посмотрели, что внутри лежит протокол IP, сказали, вот у нас кадр пришел, по этому кадру видно, что он 64 байта минимальный размер, мы содержимые, все 46 байт, передаем обработчику IP. Вот в этом случае в обработчике IP должен быть механизм, который скажет, мне на вход дали 46 байт, но только 32 байта меня интересует, а все остальные байты это мусор, я их обрабатывать не должен. Если у вас во всех возможных протоколах, которые умеют вкладываться в Ethernet, есть такой механизм, то вот эта вот штука будет работать. Если же у вас в каком-то протоколе, который работает поверх Ethernet, нет возможности отследить, что вот это полезные данные, а вот это мусор прибежало, то есть у вас будет какая-то функция, которую дергает обработчик Ethernet 2, говорит, смотри, я тебе принес кадр в этом кадре,

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

сколько этих самых данных там есть. Вот есть один байт полезных данных и оставшиеся 45 мусора, значит, надо написать вот здесь в поле длина, что это был один байт полезного значения. Только возникает вопрос, окей, вы указали, сколько здесь полезного, а дальше-то надо что-то с этим сделать, то есть вот к вам пришел кадр, вы сказали, пришли 0,7 вольта, эти 0,7 вольта похожи на единичку, окей, собрали пачку единичек, посмотрели, сказали, да, там есть преамбула, да, там есть старт-оффрейм, да, там есть получатель, отправитель, получатель, это мы, длина, один байт полезной нагрузки. Дальше какая-то колбаса идет. Что это за колбаса? Вот как понять из одного байта, что это за колбаса? Непонятно. Надо, чтобы в явном виде было написано, эта колбаса относится к протоколу, там, допустим, IRP, или эта колбаса относится к протоколу IP, или эта колбаса относится к, там, CDP. Вот 802.3 кадры указывают следующее. У вас от поля с данными от 46 байт откусывается

8 байт, которые будут называться заголовками 802.2. И, соответственно, в этих самых заголовках будут два поля, одно будет называться LLC, Local Link Control, а другое SNAP. Сейчас, как он там пишет? У меня на следующем слайде написано, как он называется. В общем, да, сейчас я расскажу тогда про это и расшифрую вам SNAP. Забыл облевиатуру. Так, про преамбулу. Да, мы уже сказали, состоит из чередующихся бит, ноликов, единичек. 802.3 преамбула 63 бита, последний битик, единичка. Иногда Start of Frame Delimiter, вот это SFD, считается 1 байт, и тогда этот 1 байт считается вот 1.0, 1.0, 1.0, 1.0, строго говоря, вот эти 7 последних единичка, ноликов, они относятся к преамбуле еще. И последняя вот эта единичка. Зачем нужна преамбула? Почему она именно такая? И...

И... И... Это самое... Туплю. Да, зачем она нужна? И почему она именно такая? Почему она именно такого размера? Почему она именно такого вида? Единички и нолики? Для начала давайте здесь вспомним следующий момент. Манчестерский код, единички и нолики, которые у нас там есть, они передаются в виде мало и много. Если у вас используется 10 BST, то это хорошо. Если у вас используется какой-то другой стандарт, не 10 BST, а там, допустим, 100 BSTX, в котором нет манчестерского кода, то вы не можете по приходящим к вам данным угадать, что является каждым тактом. В случае с манчестерским кодом все просто. К вам приходит какой-то аналоговый сигнал, и он обязательно в каждом битике, посреди бит, там, где смена тактов идет, обязательно он переходит через ноль. К вам приходит, допустим, либо минус 0.7 и плюс 0.7, и тогда у вас есть переход через ноль,

либо плюс 0.7 и минус 0.7, и опять есть переход через ноль. Вы можете сказать, как только у вас есть переход через ноль, это как раз происходит смена такта в пределах передачи одного бита, и вы можете по этой смене такта автоматом синхронизироваться с отправителем. Помните, у нас есть синхронная и асинхронная передача. Вот синхронная передача требует, чтобы ваш кварц, ваш дергалка тактовой частоты, она была синхронизирована с передатчиком. Если у вас асинхронная передача, у вас в самом сигнале приходит что-то, что показывает вам, включая передатчик и выключая передатчик. Здесь к вам приходят преамбула, и вы говорите, о, преамбула, вижу, подряд идет 64 перехода через ноль. Я могу синхронизироваться по этим переходам через ноль, я могу понять, что вот пришла пора включать передатчик, и пришла пора понимать, что это действительно приходят какие-то полезные нолики-единички, которые надо как-то обрабатывать. Если же у вас используется какой-то другой стандарт физического кодирования, не манчестерский код,

то тогда вам придется слегка подсинхронизироваться каким-то образом под передатчик соседа. И если у вас используется какой-то механизм кодирования, который, соответственно, более сложный, а что значит более сложный? Он меньше накладных расходов обеспечивает, то есть вы передаете какие-то биты практически в чистом виде, а потом идет к ним какая-то дополнительная информация. То вот именно по этой самой преамбуле происходит синхронизация. Вы получаете что-то похожее на единичку, потом что-то похожее на нолик, потом снова что-то похожее на единичку, что-то похожее на нолик. И так 64 или 63 раза подряд. Вот именно она будет нужна для того, чтобы синхронизировать тактовую частоту передатчик с тактовой частотой приемника. Вот. Да, преамбула и стартов фрейм не являются местными данными, передающимися в кадре. Она зачастую не подсчитывается при размере передаваемых данных. Но надо понимать, что она все равно занимает полосу пропускания.

Если у вас написано 10 мегабит на устройстве, преамбула будет порождать нолики-единички, которые вот в эти самые 10 мегабит входить будут. То есть ее все равно придется передавать, и все равно она будет расцениваться как какая-то полезная нагрузка. ФЦС обычно считается как полезная нагрузка. То есть вот преамбула и стартов фрейм, битик, если он есть, она обычно не считается. Если мы говорим, допустим, что у нас размер кадра должен быть 64 байта, то вот преамбула туда обычно не входит. Вот я сейчас опять вернусь к предыдущему слайду. Смотрите, 4 байта чек-суммы, 46 байт полезной нагрузки, всего 50. 2 байта из артайп 52. И отправитель и получатель по 6 байт каждый 12 байт в сумме. 52 плюс 12, 64. То есть вот этого штука до преамбула 64 байта. И преамбула еще дополнительно 8 байт. И еще не забудьте, если вы будете рассчитывать физическую скорость передачи данных,

стартов фрейм деливери. Ой, простите, интерфрейм спейс. Еще 12 байт. То есть если вы хотите передать 1 байтик полезной нагрузки, то вы должны 1 байтик передать вот здесь, добить его 45 байтами мусора, дописать еще дополнительно 18 байт заголовков, приставить 8 байт преамбула и 12 байт интерфрейм спейса. И вот на 1 байт полезной нагрузки вы получите сколько получается? 71 байт самого кадра плюс еще 12, 71, 12, 83. 73 байта мусора. Ну как мусора. Какое-то вот данных, которые вы обязаны передавать, занимая сеть, или ничего не передавать, но опять-таки не занимая сеть, и вы не можете эту самую сеть не занимать, пока вы эти данные не передаете. Вот накладные расходы, да, в том или ином виде на 1 байт кадра из Rnet 2 получится 73 байта, я посчитал, да?

Ну короче, много. Вот. Да, 83, простите. Математику у меня сегодня не очень хорошо. Да, преамбула. Зачем она нужна и почему она 8 байт? Ну или 7 байт плюс вот стартовый. Размер 8 байт будет исходить из правил 4 хабов. То есть вы наверняка помните про правила 4 хабов, если кто-то из вас работал с Rnet, там старше 15 лет. Это правило гласит следующее. Если у вас в сети используются хабы, между любыми двумя участниками в промежутке не может быть больше 4 хабов. Соответственно, между этими 4 хабами будет 3 сегмента, которыми хабы соединяются, и 2 сегмента будут соединять хабы с этими двумя участниками. И все это будет одним доменом коллизий. Иногда это правило записывается как 5, 4, 3, 2, 1. 5 проводов, 4 хаба, 3 провода между хабами,

2 провода между узлами и хабами и 1 домен коллизий. Иногда это правило записывается неправильно. Во всех источниках русскоязычных, которые я в интернете нашел, они указывают это самое правило 5, 4, 3, 2, 1 как то, что у вас не должно быть вообще больше 4 хабов. в сети. И между этими 4 хабами должно быть, соответственно, по-моему, 2, не больше 2 сегментов между ними. Это не совсем правда. То есть 4 хаба, это вот как раз используется указание для того, чтобы у вас не получилось сегменты больше 500 метров. Каждый из проводов не может быть больше 100 метров. Если у вас будет 5 проводов по 100 метров, общая длина сегмента получится 500 метров. И между ними должно быть 4 повторителя. Те самые 4 хаба. Вы технически можете, если захотите, взять и напихать 10 хабов, 20 хабов.

Возьмите метровые патчкорды. Первый патчкорд, воткните в первый хаб. В него вставляете второй патчкорд, второй хаб, третий патчкорд, третий хаб. И вот так вот длинную-длинную колбасу сделаете. Общая длина сегмента получится в... Если 10 хабов, 10 метровых патчкордов... 11 метровых патчкордов, простите. Общая длина сегмента 11 метров. Никаких проблем. Это работать будет. Правило 4 хабов исходит из того, что все сегменты могут быть максимальной длины. И тогда длина сегмента, общая, которая у вас получается, длина доменной коллизии, условно говоря, будет не более 500 метров. Откуда взялась цифра в 500 метров? Она взялась как раз из преамбулы. То есть тут сложно сказать, что было первично, что вторично. Скорее цифра в 500 метров для 4 хабов была вторична по отношению к преамбуле. Если у вас есть какой-то кадр, который вы хотите отправить, вы должны его начать отправлять. Вы занимаете среду преамбулы, начинаете передавать эту самую преамбулу. И вы отправляетесь импульсы в сеть,

и эти импульсы начинают бежать до самого-самого дальнего угла в сети. Если у вас размер доменной коллизий не будет превышать 500 метров, то коллизия, если она и возникнет, она случится не позже, чем через 32 биттайма. Но опять-таки, просто берем, делим одно на другое, получаем, что за один биттайм расстояние проходится 20 метров мы насчитали приблизительно. Соответственно, если вы 32 биттайма, 32 бита передаете, оно пробежит в 32 раза больше, то есть 640 метров. Вот при длине сегмента меньше 500 метров у вас получается, что за то время, пока вы передаете первые 32 бита, у вас сигнал пробежит вот те самые 500 метров. И если вдруг коллизия случится в самом дальнем углу, то коллизия до вас будет бежать еще те самые 32 биттайма. То есть 3,2 микросекунды. И получится, если у вас

соблюдается правило длина сегмента не более 500 метров, то коллизия до вас добежит не только пока вы передаете кадр, но коллизия до вас добежит, пока вы передаете преамбулу. Никакие боевые данные не испортятся. То есть вы начинаете передавать преамбулу, кто-то другой с вами устраивает коллизию, даже если он сидит очень далеко. Эта коллизия до вас добежит до того, как вы начнете передавать боевые данные. И соответственно у вас никакие боевые данные не потеряются. Вы просто попытались занять среду, у вас это не получилось. Заткнулись, снова попытались занять среду, не получилось. Снова заткнулись. Вот эта коллизия, она нужна как раз для того, в смысле преамбула, нужна как раз для того, чтобы быть буфером, чтобы кадры от разных участников сталкивались именно по преамбуле, Чтобы коллизия распространялась именно только в пределах преамбулы, не затрагивая мясные данные. Если вы будете сталкиваться по мясным данным, если у вас будет слишком большая сеть, и вы начинаете передавать мясо, и до вас доходит преамбула, это чужая.

Это будет плохо, потому что вы долго занимаете сеть, и занимаете сеть совершенно зря. Коллизия поздняя, вот та, которая происходит после преамбула, она уже слишком негативно влияет на работу сети. Поэтому есть ограничения на размер сети именно в 500 метров. А соответственно уже именно с 500 метров строится правило 4-х хабов, что если у вас участки слишком длинные, по 100 метров каждый, то вы не можете взять, допустим, 5 хабов, соединить их с 100-метровыми патч-кордами и подключить к ним абонентов тоже с 100-метровыми патч-кордами. Коллизия в этом случае будет слишком поздно приходить, и это будет называться late collision. Вот такая вот штука. Именно поэтому коллизия получается 64 бита, именно поэтому у нас есть правило 500 метров диаметра сети, именно отсюда растет правило 4-х хабов. Теперь вы будете это знать. Если кадр начинается с преамбула, то кадр заканчивается механизмом, который называется frame check sequence.

4 байта. Это такое специальное поле, в которое вставляются 4 байта таких, что если вы начинаете считать чек-сумму CRC32 от всего кадра вместе с полем FCS, то у вас всегда получится вот такой результат. Это так называемый magic number или Ethernet magic number. Магическое число. Вы можете достаточно легко взять и посчитать, какое число в отправляемом кадре надо вложить, чтобы чек-сумма получилась вот именно такая, которая надо. Равным образом вы всегда можете взять и легко посчитать чек-сумму от того, что пришло. И если оно отличается от вот этого самого magic number, то вы можете сразу сказать, оно побилось по дороге. Вычисление CRC32 хорошо тем, что его можно начать вычислять до того, как у вас кадр целиком придет. То есть вам пришло первые 4 байта кадра, там полезло MAC адрес получателя. Вот вы уже можете начинать вычислять CRC32.

У функции CRC32 есть шанс ложного негативного срабатывания. То есть она вам скажет, что чек-сумма сошлась, хотя на самом деле кадр все равно побился по дороге. Этот шанс, тем более, чем больше у вас будет размер кадра. Ну то есть понятное дело, что если у вас анализируемые данные, от которых вы читаете чек-сумму, там просто 4 байта, вопросов нет. У вас на разных наборах обязательно будет разная чек-сумма. И, соответственно, шанс ложного негативного срабатывания будет нулевой. Но если у вас, соответственно, мощность множества анализируемых данных больше, чем мощность результата функции CRC32, то может быть такое, что два набора, от которых вы будете считать CRC32, дадут вам одинаковый выход этой самой функции. Может быть даже такое, что два набора, отличающихся очень мало друг от друга, дадут вам одинаковый результат. Вот на объемах входных, вот этих самых размеров кадров, меньше чем 1500 байт, этот самый шанс маленький.

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

это 10 в минус 14 степени. То есть вероятность того, что у вас один битик потеряется по дороге или изменится по дороге, 10 в минус 14. Очень условно говоря, на объеме в 10 гигабайт, нет, в 10 тысяч гигабайт, простите, посчитал плохо, у вас, соответственно, должен потеряться один битик. Это если у вас Ethernet работает хорошо. В реальности Ethernet может работать не очень хорошо, если вы его используете как-то неправильно. Если вы провода проложили рядом с силовыми кабелями, там микроволновку кто-то включает, что-то еще, и может быть такое, что в реальности у вас ошибки в канале будут проходить чаще. Если ваша сеть точно работает хорошо, вы точно знаете, что микроволновок не включает, везде провода у вас проложены как надо, нигде силовые кабеля там рядом не лежат, сварочный аппарат никто не подключает к ним, вы можете сказать, хрен с ней, с этой самой функцией CRC32. Мне не нужна проверка на ошибки.

Даже если вдруг у нас будет какая-то ошибка, все равно вероятность ее мала. По стандарту 10 в минус 14 степени это дофига мало как. То, что там раз в 10 гигабайт у меня будет битик теряться, ну и хрен бы с ним, пусть теряется. Вышестоящие протоколы это дело отследят наверняка. Поэтому, даже если вдруг потеряется этот самый один битик, скорее всего CRC32 даст мне позитивный результат, что не получилось у меня пропустить этот самый битик. Скорее всего CRC32 посчитает чек-сумму от этого изменившегося кадра и скажет, не сошелся результат. Да, шанс на то, что она скажет, результат все равно сошелся есть, но он все-таки достаточно маленький, исходя из того, что я знаю, как работает моя сеть. Вот CRC32 использует размер кадра до 1500 байт, исходя из того, что в реальности процент ошибок может быть больше. Он может быть не 10 минус 14, а существенно выше. И, соответственно, да, она будет успешно определять проблемы в кадрах,

даже если вдруг у вас есть микроволновки, даже если у вас там есть что-то еще, и эти самые кадры постоянно приходят к вам битые. Вот, да, с полезными данными. Минимальная длина 46 байт, максимальная длина 1500 байт. 46 байт используется именно из-за того, что у нас время передачи кадра должно гарантированно превышать слот тайм. Оно гарантированно превышает именно на размер преамбулы, потому что слот тайм исходит из того, что у нас размер кадра должен быть минимум 512 бит, а размер кадра вместе с преамбулой это 512 бит полезных данных плюс 64 бита преамбулы. Ну и получается, что абсолютно при любых раскладах слот тайм у нас будет превышен. Вот, ограничение сверху, да, минимизирование ложного негативных срабатываний CRC32, когда CRC32 говорит «не, все в порядке, ничего не побилось по дороге», а на самом деле это не так. Если мы говорим про кадр формата 802.3, у него ограничения на размер снизу и сверху вот самих бит кадра Ethernet те же самые.

То есть у нас без учета внутреннего содержимого все равно минимум 64 байта, максимум 1518 байт. Но, соответственно, размер данных, поле с данными, будет за счет дополнительных заголовков LLC и SNAP меньше. Если вы, соответственно, возьмете и посчитаете, вот эти вот два заголовка будут 8 байт, 46 байт поле полезных данных было в Ethernet 2, от 46 байт 8 байт откусили, получили 30 сколько получается? 8 байт минимум должно быть в кадре 802.3. Максимально будет, соответственно, 1492 байта. Опять-таки, никто не отменял максимальное ограничение, которое должно быть в Ethernet. Обратите внимание на то, что свечи, которые у вас будут пропускать через себя кадры, они никоим образом не анализируют поле Ethertype, не анализируют поле Length, не анализируют наличие заголовков LLC и SNAP. Они в основном будут ориентироваться на поле MAC-адреса.

Поэтому вы не можете использовать с глупыми свечами, которые просто берут и замеряют, что пришло что-то похожее на преамбулу плюс что-то похожее на 1500 байт. Такие свечи глупые не могут обработать нормальную ситуацию, когда пришло что-то похожее на преамбулу и 1500, допустим, 4 или 1508 байт. Они на такие кадры могут ругаться. Поэтому именно исходя из того, что ваши кадры 802.3 могут проходить через такие глупые свечи, максимальный размер поля с данными тоже будет сокращен. Максимальный размер кадра 1518 байт минус, соответственно, все заголовки, включая LLC-SNAP, получается 1492 байта под полезные данные. Так, далее, далее, далее. Если вам очень-очень сильно хочется, вы можете повысить размер отправляемых данных. Делается это следующим образом.

Вы искусственно говорите вашему адаптеру, что он может отправлять кадры большего размера, чем 1500 байт с полезной нагрузкой. 1518 байт с учетом заголовков. Даже если это повлечет за собой меньшую эффективность чек-суммы. Для чего это полезно делать? Во-первых, вам иногда будет необходимо впихнуть в один кадр из Орнета что-нибудь большое. Ну, например, вы хотите iSkyZ кадры, iSkyZ пакеты, вложенные в TCP, вложенные в IP, вложенные в Орнет отправлять. И вам хочется, чтобы ваша подсистема, которая будет работать, она бы SkyZ команда отправляла не в нескольких разных кадрах, если это будет одна команда, а вот одна большая команда с одним блоком данных, и все это дело нормально проходило бы по сети. Вот вам хочется взять и все в одном кадре из Орнет, отправить один IP пакет, в нем один TCP сегмент, и в нем одна iSkyZ команда с внутренней вложенной SkyZ командой, которая может быть до 2 килобайт. Вот хочется, иногда зудит где-нибудь.

В этом случае вы можете сказать, окей, отправляем джамбофреймы. Иногда это требование протокола, какой-нибудь FCOE, например, Fiber Channel over Ethernet. То есть там нельзя работать без поддержки джамбофреймов. Она просто не будет работать. Иногда это осмысленное действие, которое позволяет вам более эффективно работать. То есть если у вас заголовок Ethernet кадра плюс дополнительная преамбула, плюс дополнительный интерфрейм спейс, а не фиксированного размера. И сколько бы вы данных не посылали, у вас все равно этот заголовок будет. Вот если вы посылаете там 1500 байт, это заголовок 18 байт. Если вы посылаете 9 килобайт, это заголовок все равно 18 байт. То есть в процентном отношении получается эффективность использования сети выше. Если вы посчитаете, простите, если вы посчитаете эффективность использования сети как бы в пересчете на процент полезных данных от общей производительности сети с обычными кадрами, вы должны будете сказать, что вот у нас есть кадры 1,5 килобайта. Эти кадры передаются вместе с заголовками.

18 байт заголовка плюс 8 байт преамбула 26 байт плюс 12 байт интерфрейм спейс 26 плюс 12. 38 байт. На каждые 1500 байт у вас 38 байт идет мусора. Это в общем заметная достаточно доля. 38 делить на 1500. 2,5% вы тратите на заголовки. Вот даже если вы самые большие кадры будете посылать, они все равно 2,5% будут тратить на заголовки. Если вы будете меньше кадров посылать, то оверхед будет больше. Если же вы используете джамбо фреймы, то заголовок интерфрейм спейс останутся того же самого размера 38 байт. размера полезных данных вы можете сказать, что вот хочу отправлять, например, 9 килобайтный пакет. 9000 байт. Получается в этом случае у вас 4,5 промилле. То есть в 8-9 раз меньше накладные расходы по сравнению с обычными кадрами.

То есть если для вас вот эти вот проценты, 2,5% или 4 промилле играют роль, то вы можете сказать, окей, используем джамбо фреймы. Почему делать так не нужно? То есть в каких случаях джамбо фреймы использовать можно полезно? Понятно. В каких случаях делать этого не нужно? Во-первых, если у вас есть среда Ethernet, в которой не поддерживается джамбо фрейма. Есть свитчи, которые не пропускают через себя 1,5 килобайтные кадры. Есть узлы, которые подключаются к Ethernet широковещательному домену и не поддерживают они эти самые 9 килобайтные кадры. Тогда вы не должны включать эти самые джамбо фреймы. Джамбо фреймы включаются целиком в пределах широковещательного домена. Если у вас есть узлы, которые поддерживают эти самые джамбо фреймы, это не означает, что вы должны повключать эти самые джамбо фреймы. Вы должны вообще во всей сети включить джамбо фреймы для того, чтобы оно работало. Чтобы любой желающий мог отправить любому другому желающему большой кадр и тот бы не сошел с ума.

Имейте, пожалуйста, в виду, что если у вас есть какая-то сеть Ethernet, и в этой сети у вас используется поверх нее протокол IP. И, соответственно, этот самый протокол IP, IP-сеть, которая у вас используется в этом самом широковещательном домене, она соединена с интернетом. То есть вы можете отправить такой кадр, в который будет вложен IP-пакет, который будет предназначен для интернета. В этом случае джамбо фреймы вы включать не имеете права. То есть вы можете это сделать, но это будет вредительство, совершенно откровенное. Почему? Если вы помните, как работает IP, он запрашивает со стороны канального уровня максимальный размер отправляемых данных, которые можно отправить. И, соответственно, он делает IP-пакеты такими, чтобы они влезли гарантированно в эту самую канальную среду. А если у него надо отправить много данных, и оно в канальную среду все не пролезает, он занимается так называемой фрагментацией. Если захочет.

Он может взять и побить пакет на части. Или может сказать, оно не пролезет, ну его нафиг. Вот если он будет заниматься фрагментацией, он скажет, окей, у нас есть кадр, допустим, полтора килобайта, который мы можем отправить, но у нас есть два килобайта данных, которые в один кадр не влезут никак. Мы возьмем, по-режиму на части, полтора килобайта один кусок и полкилобайта другой кусок. И, соответственно, получается, что у вас IP-пакеты будут формироваться в некоторых случаях максимального размера такие, чтобы они влезли в эти самые драмбофреймы. Если у вас, соответственно, интерфейс поддерживает драмбофреймы, заявляет, что он поддерживает, IP говорит, какого размера я могу отправить пакет. Вы ему говорите 9 килобайт. И у вас будут IP-пакеты размером в 9 килобайт, которые, возможно, будут отправляться в интернет. Мы же говорим, что там сеться и нас с интернетом, правильно? Что происходит? Вы отправляете IP-пакет размером 9 килобайт, в кадре 9 килобайт в Ethernet. Такой кадр доходит до маршрутизатора, который смотрит в интернет.

А у провайдера эти самые драмбофреймы никоим образом не работают. То есть провайдер вообще не знает, что такое драмбофреймы. Поэтому на интерфейсе, который у вас смотрят в сторону провайдера, вы не имеете права драмбофреймы включать. Вы обязаны там включать полтора килобайта размер кадра. Вы обязаны драмбофреймы выставлять везде в пределах канальной среды одинаковые. И что произойдет в этом случае? Ваш роутер должен будет взять 9 килобайт на IP-пакет и побить его на куски. Заняться фрагментацией. Фрагментация процесс очень медленный. Она выполняется на центральном процессоре в большинстве случаев. Поэтому если у вас есть вот такая вот штука, что вы взяли и отправили драмбофрейм. И он воткнулся в роутер, который не может дальше его отправить целиком. Должен его заниматься разделением на части отправкой по частям. Этот роутер будет постоянно в полной загрузке. Он будет перегружен и он будет заниматься исключительно тем, что пакеты будут резать на части. Считать чек суммы всех его пакетов. Считать чек суммы всех частей. И все это делать на процессоре, вместо того, чтобы делать это на аппаратном ускорителе маршрутизации типа CEF или FastPass или чего-нибудь еще.

Поэтому не надо так делать. Если у вас есть абонентская сетка, в этой сети сидят абоненты, которые могут выходить в интернет. Понятно, не с помощью протокола Ethernet они в интернет будут ходить. Они будут в Ethernet сидеть. С помощью протокола IP через этот Ethernet они будут отправлять пакеты в сторону интернета. Вы не имеете права там включать драмбофреймы. Да, вы в среду Ethernet будете отправлять IP пакеты, предназначенные для интернета. Соответственно, в этом случае у вас будут проблемы. В каких случаях еще будет плохо использовать драмбофреймы? Если у вас есть маршрутизируемая среда не в интернете даже, а в пределах, допустим, корпоративной сети. И какая-то часть этой сети поддерживает драмбофреймы, какая-то часть не поддерживает драмбофреймы. То же самое будет история. В каком-то месте сети у вас оборудование будет заниматься тем, что будет дробить на части пакеты, а потом возможно собирать их обратно для какого-то анализа или чего-то еще. То есть у вас постоянно будет оборудование заниматься фигней. Ради тех самых экономии 2% нет смысла этим заниматься.

То есть экономия 2% в плане полосы пропускания вылится вам в то, что у вас оборудование будет заниматься тем, что будет тупо считать чек-суммы от кусков пакетов, которые он считать совершенно неинтересной. И будет это делать на центральном процессоре. Не надо так делать. Так что если у вас есть часть сети, которая поддерживает драмбофреймы, часть сети, которая не поддерживает драмбофреймы, и между ними надо отправлять IP пакеты, вот в этих средах Ethernet, которые обеспечивают работу IP, не включая драмбофреймы. Еще проблема будет соответственно с тем, что у нас не должно быть большого количества ошибок в сетях. Bitterer Rate в Ethernet, под который писался стандарт Ethernet, 10 в минус 14 степени. Если вы знаете, что ваш Ethernet работает с помощью витой пары, проложенной между зданиями на расстоянии 120 метров, причем эта витая пара уже наполовину сгнила, и пару раз ее экскаватор переехал, вот он каким-то чудом еще работает, но в нем процент ошибок 1%. В этом случае вы, ну надо понимать, сталкиваетесь с очень большой вероятностью того, что у вас будут ошибки.

Чем больше вероятность того, что у вас будут ошибки, тем больше шанс сложно негативного срабатывания CRC32. Если у вас CRC32 не обнаружат ошибку, то соответственно есть шанс того, что IP на уровне заголовка не обнаружит ошибку, если он будет это делать. И вышестоящий протокол над IP транспортного уровня тоже по каким-то причинам может не обнаружить ошибку. Да если там будет TCP или UDP, там скорее всего проблем не будет. Но если там будет что-то еще, может быть шанс того, что там, соответственно, закрадется ошибка и никто этого дела не обнаружил. Поэтому рекомендация. Не включайте Jumbo Frame до тех пор, пока вы абсолютно не будете точно знать, что без них вам не обойтись. В каких случаях их нужно включать? Если у вас обособленная отдельная выделенная среда для Storage Network. Вот в этом случае Jumbo Frame вам пригодятся. Если у вас есть обособленная выделенная среда для каких-то административных нужд без доступа в интернет. Допустим для бэкапов.

Там тоже постоянно загруженная сеть у вас, потому что бэкапы туда всегда бегают, они огромные. И 2% экономии они там могут вам помочь. Вы точно знаете, что у вас нигде там маршрутизация не выполняется. Если выполняется, то маршрутизатор нормально обрабатывает такие огромные пакеты. Все здесь будет хорошо. Во всех остальных случаях не трогайте Jumbo Frame. Они вам навредят. Имейте, пожалуйста, в виду, что несмотря на популярное заблуждение, что Jumbo Frame можно не включать для того, чтобы разрешить принимать их, зачастую это не так. То есть действительно, Jumbo Frame, если вы на уровне драйвера разрешаете отправлять, это означает, что ваша система теперь имеет право отправлять большие кадры. И она их позволит отправить вообще в среду. Но в большинстве случаев на самом деле эта же настройка одновременно и разрешает принимать кадры Jumbo Frame. То есть бывает такое, что у вас есть среда. С одной стороны вы Jumbo Frame включили, с другой стороны Jumbo Frame не включили. Вот у вас происходит какой-нибудь там, не знаю, FTP-сессия.

Вот вы открываете ее или там файлы через SMB пытаетесь передать. То есть вы набираете там ftp.sosednieuzel.com, нажимаете Enter. FTP-шная сессия команда использует достаточно маленькие пакетики. Она нормально устанавливается, показывает вам список файлов, все прекрасно, все работает. Вы начинаете загружать файл, может даже не очень большой файл, но вот просто пытаетесь это сделать. Естественно, файл становится существенно больше, чем полтора килобайта. Он раздирается на куски того размера, который позволяет канальный уровень. То есть, допустим, 9 килобайт, если вы включили Jumbo Frame, отправляется в сторону соседа. У соседа эти кадры не принимаются. У него настройка Jumbo Frame не стоит, он не отправляет кадры и он их не принимает. Поэтому, если вы, соответственно, говорите, что Jumbo Frame не отправлять, чаще всего вы говорите, что и не принимать. И выглядеть сценарий вида, где-то повключали Jumbo Frame, где-то не повключали Jumbo Frame, будет именно как то, что маленькие пакетики проходят нормально, большие пакетики работают ненормально.

Типичное проявление, типичный симптом. Вы пытаетесь передать файл, нормально устанавливается командная сессия, показывается список файлов, список папок, но не получается передать файл. Что в SMB, что в FTP, оно просто зависает и ничего не происходит. А вы потом пытаетесь обновить папку, видите, что файл то ли создался в 0 байт, то ли что-то еще. Вот действительно, командная сессия говорит, давай создавать файл, давай я сейчас тебе буду передавать боевые данные. Начинаете передавать боевые данные, они не проходят. Вот это вот явление, которое очень характерно для неправильно включенных Jumbo Frame. Если вы включили со своей стороны какие-то Jumbo Frame, то есть вы с одной стороны, допустим, включили 9 килобайт Jumbo Frame, а с другой стороны включили 4,5 килобайта Jumbo Frame, в большинстве случаев вы включением Jumbo Frame вообще включаете прием Jumbo Frame вообще любого размера. Если вы со своей стороны включили Jumbo Frame, а с другой стороны не включили Jumbo Frame, вообще никакие, то, как правило, получение кадра, который будет большего размера, чем должен быть,

то есть больше, чем 1,5 килобайта, оно будет вызывать ошибку, которая называется Giant Frame. Вот так вот. На большинстве оборудования, которые я видел, вот Giant Frame, это как раз что-то пришло, оно похоже по виду на кадр, но его размер превышает максимально разрешенный размер, в нашем случае 1,5 килобайта, допустим. Вот кто-то нам Jumbo отправил, и у нас это вызвало ошибку, мы выставили счетчик Giant Frame в единицу. Ну или там на единицу подняли. Так, с полем EtherType, в общем, все просто, вы указываете там, что внутри лежит, если у вас именно Ethernet 2 формат кадра, то вы указываете там именно тип вложения. Типичное значение, которое можно увидеть, это 0800 для IPv4, 08006 ARP, близкий друг и товарищ, IPv4, IPv6 будет 86DD, 8100, 802.1. Это все 16-ти ричные значения, то есть поле 2-байтовое, 16-ти битовое,

и вот здесь вот значения показаны именно 16-ти ричные. 802.3 комитетный отдел сказал, что не, мы так делать не будем, мы будем указывать, что внутри лежит в LLC snap, а в вот это вот поле 2-байтовое освободившееся мы будем класть, что внутри лежит, сколько внутри этого лежит. И, соответственно, туда указывается длина полезных данных в байтах. Если вы указываете, что, соответственно, там чего-то маленькое лежит, ну, допустим, вы указываете там размер полезного поля с данными 1 байт, вы все равно кадр делает 64 байта, только вы добиваете его мусором и говорите, вот из этого мусора 1 байт полезных данных. Если вы делаете кадр большой, там 1500 байт, то вы туда списываете число 1500. То есть мусора в этом случае не будет и у вас просто получается какой-то большой кадр. Естественно, что оборудование, которое работает в одном формате, оборудование, которое работает в другом формате, это два разных вида оборудования. 802.3 комитетный отдел посмотрел и сказал, блин, Ethernet 2 он, конечно, хороший. Он 8 байт лишней нагрузки не заставляет вкладывать.

Поэтому современный вариант 802.3, актуальной версии его, они поддерживают оба варианта. То есть если у вас в поле length хранится что-то меньше, чем 1500, то это будет 802.3 формат. Если у вас в этом поле хранится что-то больше, чем 0.6.0, вот такой вот, 1536 в десятичном виде, это будет Ethertype. То есть оборудование само решает, в каком формате читать заголовок по вот этим двум байтам. Она видит, пришел какой-то кадр, она этот кадр анализирует, смотрит MAC-адрес получателя, свой, окей. Дальше продолжаем. MAC-адрес источника, окей, какой-то там MAC-адрес источника. Дальше смотрит поле 2 байта, который идет после MAC-адрес источника и говорит, там число, которое больше, чем 1536, поэтому это поле Ethertype. Поэтому я сейчас возьму, посмотрю, что там написано и передам обработчику, который там написан. Лежит там 0800. Передам обработчику IPv4.

Если там число меньше, чем 1500, то, соответственно, это воспринимается как длина. Следовательно, вы ожидаете после этой длины увидеть обязательный LLC-заголовок. SNAP может не быть, LLC будет обязательно. И вы будете обрабатывать полезные данные уже исходя из того, что там внутри написано в этом самом доп.заголовке. Это вот актуальная версия 802.3 стандарта, которая указывает, собственно, как надо себя вести. Как быть в этом случае с Jumbo Frame? Jumbo Frame, они всегда будут в ZRN2, простите. А 802.3 они быть не могут. Если вы, допустим, скажете, что у вас есть Jumbo Frame, который 9-килобайтный, вы не можете это самое число 9000 вписать в поле Length, потому что это будет означать, что актуальные версии 802.3 стандарта будут в этом случае понимать, что это на самом деле EtherType. Хотя вы туда вписали длину. То есть это будет неправильно. Jumbo Frame, да, всегда Ethernet 2.

Более того, на самом деле для них изначально предполагалось использовать отдельный EtherType. То есть отдельное вот это вот число. Я его так на память не помню, но оно было. Эта штука считается устаревшей, поэтому современные Jumbo, которые вы будете отправлять, они будут совершенно нормальные. То есть вы отправляете кадр, в этом кадре там вложен протокол IP, IP-пакет занимает 9 килобайт, и в поле EtherType просто вкладывается 0800. Если вдруг вы видите кадр, у которого значение будет десятичное, вот этого самого поля двухбайтового, в диапазоне от 1501 до 1535, это 16-ти ричные 05DD и 05FF. То есть какой-то промежуточный, больше чем 1500, но меньше чем 1536. Такой кадр считается ошибочным. То есть его просто нельзя обрабатывать, это недопустимо по стандарту. Так, по поводу MAC-адреса. Я думаю, что с MAC-адресом здесь все относительно просто.

У вас в каждом кадре указывается два адреса. MAC-адрес получателя и MAC-адрес отправителя. Первый получатель, второй отправитель. Вы всегда сможете сказать по пришедшему к вам кадру, по первым шести байтам кадра, соответственно, что вот надо это читать или это читать не надо. Да, длина каждого MAC-адреса, что отправителя, что получателя у нас одинаковые, 48 бит. Записывается оно в одном из нескольких форматов. Правильный формат, который прописан 802-2 комитетом ИЕЕшным, это 6 двузначных чисел, разделенных разделителем. Разделителем может быть либо минусик, либо двоеточие. То есть вот это правильный формат записи MAC-адреса. И вот это правильный формат записи MAC-адреса с точки зрения 802-2 комитета ИЕЕ. С точки зрения CISC, инженеры, электротехники, электроники им не указ,

поэтому CISC использует свой отдельный формат записи, который не похож ни на что. Это четырехзначные 16-ти ричные числа, разделенные двумя точками. То есть вот 2 байта, точка 2 байта, точка 2 байта. Всего 6 байт. Бывают отдельные умники, которые придумывают свои собственные форматы, ну как CISC, например. Например, часто бывает такое, что MAC-адрес записывается целиком слитно. То есть имейте в виду, что представление человека понятное. Это, конечно, очень хорошо, но MAC-адрес от этого 48-битным быть не перестает. 48 бит это всего лишь 6 байт. Как вы эти самые 6 байт запишите? Всем пофигу. Вот настолько пофигу, что есть целая пачка разных способов записать, и каждый здесь записывает как угодно. Вот в IP, в IPv4 особенно, способ записать IPv4 адрес всего один. Берем 4 байта, разделяем их точками, записываем в виде детичных чисел. Ведущие 0 обычно не пишутся. Ну там есть способы сокращенной записи, но опять-таки это все не очень стандартные.

То есть стандартный вариант, он вообще-то не регламентирован. Но все считают, что записывается оно вот именно так. В случае с MAC-адресами каждый делает все как умеет. MAC-адрес это 48 бит, и эти 48 бит будут не случайные. Вы можете, если хотите, сделать совершенно от балды 48 бит. Вы имеете право это делать. Единственное требование от MAC-адреса, которое ожидается от сети, в смысле требование, которое предъявляет сеть к MAC-адресу, это быть уникальным. Если вы придумаете, там, не знаю, у вас будет сеть на 1000 узлов, если вы придумаете, первому дадите MAC-адрес 0.0.0.0.0.0.1, второму 0.0.0.2, третьему 0.0.0.3, да, работать будет никаких проблем. Но прописывать все MAC-адреса вручную неудобно. Поэтому обычно у вас MAC-адреса будут строиться по известной схеме. И схема будет называться EUI 48. Extended Unique Identifier, длиной 48 бит. Этот самый EUI 48 состоится из двух частей.

Левая часть будет называться OUI, Organizational Unique Identifier. Организация, которая хочет назначать MAC-адреса, например, производитель сетевой карты. Она идет в EEE. И EEE ей выдает эти самые OUI. Вообще говоря, выдается 22 бита. То есть OUI имеет размер 22 бита. Тем не менее, левые 24 бита, соответственно, надо будет каким-то образом заполнить. 22 бита из них заполняются OUI. И два самых первых передающихся по сети бита, они будут немножко в хитром месте расположены, они назначаются по известному алгоритму. Самый-самый-самый первый битик, самый передающийся по сети, это младший бит первого байта. Он будет иметь специальное название M-бит. Иногда его называют I-Drop-G-бит. Вот так вот. I-Drop-G. Он будет обозначать тип MAC-адреса. То есть, когда вы с помощью механизма EEE48 генерируете MAC,

вы обязаны указать, какой это MAC. Если вы в самый младший бит всовываете нолик, это будет Unicast-овый MAC, который принадлежит одной единственной железке. Он нигде больше не повторяется, он уникален. И он отвечает ровно одному устройству. Вот. Соответственно, если вы выставляете младший битик в нолик, то вы обещаете, что такой адрес будет ровно у одной железки. И этот адрес будет уникальным именно для конкретной вот этой вот железки. Больше никто этим адресом пользоваться не будет. Если вы выставляете первый бит MAC-адреса в единицу, то это означает, что это будет специальный групповой адрес, который может пользоваться более одного устройства. Вы, соответственно, должны будете эти адреса использовать специальным образом. У вас у каждой железки должен быть уникальный адрес. Мы уже говорили. Этот адрес будет как паспорт. У каждого человека есть паспорт, и он всего один. Но в то же время есть и групповые адреса, которые нужны для того, чтобы использовать рассылку сразу на группу устройств.

Мы сейчас про взаимодействие уникастов и мультикастов проговорим, но вот такие вот групповые адреса иногда бывают нужны. И у них будет у групповых адресов как раз особенность. У них первый битик выставляется в единицу. Рядышком с ним почти самый младший бит первого байта будет называться X-бит. И этот самый X-бит будет иногда называться Universal Local. Не совсем очевидное название, означающее следующее. Universal. Это значит, что MAC-адрес, если он будет построен по схеме UE48, он обязан получиться уникальным в пределах всей вселенной, которая строит адреса по UE48. Соответственно, если вы туда ставите 0, вы говорите, этот MAC-адрес построен по честной схеме UE48, как следствие он уникален. Если вы, соответственно, выставляете этот самый битик в единицу, вы говорите, этот MAC-адрес построен как-то иначе, не по схеме UE48. Вы технически можете построить совершенно любой MAC.

То есть вы можете сделать это, но по-хорошему, если вы это будете делать, вы должны будете почти самый младший бит первого байта выставить в единицу. Никто не контролирует это. То есть вообще правильность выставления первых двух бит никто вообще никогда ни в коем случае не проверяет. Исторически предполагалось, что это должно быть, для того, чтобы упростить задачу на оборудовании для каких-то его нужд. Но по факту все на это дело кладут большой болт. Поэтому вы можете через драйвер выставить абсолютно любой MAC-адрес. Хотите DeadBeef, хотите 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1. Никаких проблем не будет. Никто не будет проверять, правильно ли выставили эти самые MAC-адреса. Но вот стандарт он такой. Почему мы этот стандарт вообще изучаем? Дело в том, что в IPv6, например, еще встречается эта же схема EOE, только 64. Он строится по той же самой схеме. То есть там точно так же берется OOE, точно так же берется вендор Assigned ID, точно так же выставляются первые два бита специальным образом.

Они точно такие же будут, MBit и XBit. Только там еще дополнительно добавляется 16 бит мусора. А так, в принципе, все то же самое. Соответственно, из 48 бит первые 24 бита, они задаются именно вот этой схемой. А 24 оставшиеся бита это вендор Assigned ID, которое назначается владельцем OOE. То есть если вы компания, допустим, D-Link, вы пошли в IEE, получили 22 бита, вставили их в нужное место, вставили 2 бита, которые вот здесь указаны, что они должны быть. И оставшиеся 24 бита получили каким-то иным образом. То есть вы обязаны, как производители железки, как производители MAC-адреса, сделать так, чтобы у вас получился уникальный адрес. Левые 24 бита у вас зафиксированы. У вас у всех железок, которые получаются, эти адреса будут иметь одинаковые левую половинку. А вот правую половинку вы ответственны за то, чтобы получилось разное. Кто просил картинку? Вот они, 48 бит. Они пронумерованы с 0.1 по 48.

Соответственно, левая половинка это OOE, правая половинка это вендор Assigned ID. Вот они биты X-бит и L-бит, в смысле M-бит. Они последние как бы в самом первом байте. Вот они, видите, байты разделены на такие пачечки. Вот первая пачечка с 0.1 по 8 биты, вторая пачечка с 9 по 16, третья пачка по 24. Дальше закончилась половинка. Вот эти биты передаются первыми по сети. Здесь справедливо задать вопрос, какого хрена они находятся где-то в серединке, но они передаются первыми. Дело в том, что в Ethernet кадры будут передаваться по-хитрому. Байты, которые вы будете передавать, передаются в нормальном человеческом порядке. Если у вас есть какая-то пачка из некоторого количества байт, вот, допустим, вы хотите передать 6 байт MAC адреса. Вот вы говорите, передаю первый байт, пошел передавать первый байт. Передаю второй байт, пошел передавать второй байт.

Они не путаются между собой и они идут в нормальном человеческом естественном порядке. Но внутри каждого байта биты передаются в обратном порядке. По схеме Little Indian. У вас самый-самый-самый неважный бит передается первый. Потом идет тот, который чуть поважнее. Тот, который потом самый старший, идет самым последним. Это так называемый сетевой порядок, network order. Если что, имейте в виду, что он во многих технологиях встречается. То есть байты передаются в естественном порядке, а биты передаются задом наперед, в пределах одного байта. Поэтому сначала идет самый младший бит первого байта. Вот этот вот самый байт под номером 0.8, он идет самым первым. Потом идет байт под номером 0.8, он идет самым первым. Потом идет бит под номером 0.7, 0.6, 0.5, 0.4 и так далее, 0.1. Потом идет второй байт, начиная с 16 бита. Потом 15, 14, 13 и так далее, до 0.9. Ну и вот задом наперед, каждый из байтов будет передаваться. Получается, что самый первый бит, который по сети передается, он указывает.

Это групповой мак или это индивидуальный мак, unicast, который принадлежит всего одной железке. Изначально предполагалось, что на основании этого можно сразу будет принять какое-то решение. То есть, допустим, нужно вам слушать этот мак или не нужно слушать этот мак. Например, если вы точно знаете, что мак будет unicast, что он принадлежит ровно одной железке, и к вам приходят, допустим, какие-то биты, вот эти первые два бита пришли, шестой бит пришел, и вы, соответственно, можете сразу сказать, а у меня шестой бит не такой в моем unicast в адресе, в шестом бите единичка, а здесь пришел нолик. Вы сразу на основании первых трех бит можете сказать, это вас не интересует. С другой стороны, если это групповой мак, то такой мак-адрес может принадлежать не только вам, и вы должны, безусловно, получить полный список всех бит для того, чтобы понять, вам это адресовано или не адресовано, касается вас такой адрес или не касается. Не забывайте, что сигналы в Ethernet распространяются на всех в пределах физической среды передачи данных.

Возможно, ваши нолики и единички получат не только вы, но еще и ваш сосед. И вы должны будете определить, вам это или не вам, те, кому адресован кадр, не зажмуриваются, те, кому неадресован, зажмуриваются и пропускают его мимо ушей. Соответственно, для того, чтобы понять, зажмуриваются или не зажмуриваются, вам нужно понять, кому это адресовано. И вот изначально предполагалось, что эти два бита как раз будут нужны для того, чтобы быстро оценить, вам это или не вам. В реальности схема оказалась не жизнеспособной, потому что вы будете сравнивать пачки по 32 бита или по 16 бит. Если у вас 16-битный процессор будет или 16-битная микросхема, вы сразу пачками по 2 байта сравниваете. Один раз кладете 2 байта оригинального Unicast в адрес, один раз кладете 2 байта полученного MAC-адреса, который в пакете пришел. Дергаете одну операцию процессора или одну операцию микросхемы и она сравнивает все 16 бит параллельно. Поэтому вот эта схема с двумя битами MX не пригодилась.

Но она в стандарте есть. Последнее, о чем хотелось бы сегодня рассказать, это механизмы рассылки Unicast, Multicast и все остальное. Имейте в виду, что сигналы в Ethernet распространяются на всех. Вы не можете сказать, что если у вас есть общая шина, общий провод, общий коаксиальный провод, и в этом проводе 4 абонента A, B, C и D. Вот абонент A не может отправить сигнал так, чтобы его получил только абонент D. Сигнал абонента A дойдет до всех. И до B, и до C, и до D. Вот вы отправляете какие-то битики. Да, абонент D их получит. Но абонент B и C тоже их получит. И соответственно, если вы отправляете Unicast кадр, абоненты B и C по-хорошему должны сказать, это не мне, и зажмурится. И один единственный абонент D, у которого единственный, он будет обладателем этого самого Unicast адреса, по определению уникального. Вот он не будет зажмуриваться, и он этот кадр обработает и сделает то, что в нем написано. Мультикастовая рассылка.

Соответственно, в Ethernet она есть. Ethernet позволяет отправить такой кадр, который прочитают несколько абонентов, но возможно не все. То есть вы можете написать такой кадр, в котором указать групповой MAC адрес в качестве получателя. Его не будет в качестве Unicast ни на одной машине. То есть вы можете отправить какой-то кадр от абонента A до абонентов C и D, но не до абонента B. Вы все равно отправляете биты физические в среду, и все узлы, включая B, C и D, видят эти биты, видят эти возмущения электромагнитные, видят эти 0,7 вольта. Никуда от этого не деться. Провод всего один, вы в этот провод суете 0,7 вольта, все видят пачку бит, все пытаются воспринять ее как кадр. Дальше B говорит. Этот кадр пришел на мультикастовый адрес, который мне не интересен. Я пока не знаю, почему он мне не интересен, но я знаю точно, что он мне не интересен, и я зажмуриваюсь и не пропускаю этот кадр дальше. Абонент C говорит. Я вижу мультикастовый кадр, который пришел на мультикастовый MAC, например, 0,1, 0,0,0,C, C, C, C, C, C, C.

Я знаю, почему мне этот MAC интересен. Например, на мне запущен софт, который сказал, с этого момента слушаем MAC адрес 0,1, 0,0,0,C, C, C, C, C, C. И узел C говорит. Окей, я эту пачку бит воспринимаю как кадр, кадр воспринимаю как адресованный мне. То, что внутри лежит, передаю на обработчик того, что внутри написано. Абсолютно то же самое делает D. Он говорит. Мой MAC адрес, еженекастовый, 1. Здесь пришел кадр на совершенно другой адрес, но он пришел на мультикастовый адрес. И этот мультикастовый адрес такой, который мне тоже интересен. Да, возможно, другие кто-то его тоже прочитают, но мне он тоже интересен. И я тоже обработчик запускаю, тоже его, соответственно, анализирую. Как принимается решение о том, что какой-то мультикастовый адрес вам интересен или не интересен, это тонкий философский вопрос. Но фактически вы можете это воспринимать как то, что у вас запущен софт, который умеет анализировать кадры, приходящие на определенный MAC,

или у вас не запущен софт, который умеет анализировать кадры, адресованные на такой-то вот MAC. Например, протокол какой-нибудь там CDP. Вот он запускается, у вас есть обработчик CDP. Теперь вы сможете обрабатывать пакеты, адресованные на обработчик CDP. И вы говорите, пакеты CDP будут приходить сразу многим устройствам, они будут приходить на MAC адрес 010000C, и вы говорите, окей, теперь я буду слушать такие кадры. Никто не отправляет кадры из-под такого группового MAC мультикастового, но на групповой MAC они отправляться могут. При этом, если вы отправляете какие-либо кадры, они всегда отправляются из-под юникастового MAC, который всегда есть у железки как минимум один обязательно. Так что мультикастовые кадры, которые вы отправляете, вы отправляете из-под своего юникаста на какую-то мультикастовую группу, на какой-то мультикастовый MAC. И те, кому интересен этот MAC, они обрабатывают такие кадры. Те, кому неинтересен такой MAC, они не обрабатывают такой кадр, хотя, подчеркну, биты они получили.

Но дальше они этим битам дорогу не дают, потому что они говорят, что кадр пришел, да, кадр вижу, MAC адрес неинтересный, зажму его. Частный случай мультикаста – это браткаст. Браткастовые кадры, они в виде сигналов, естественно, приходят на всех, так же, как и в случае с юникастом, с мультикастом, физически 0,7 вольта видят все. Физически нолики, единички восстанавливают все. Но дальше из этих ноликов, единичек складывается кадр. И особый случай многоадресной рассылки на адрес FFFFFFFF, то есть 48 единиц битовых подряд, это MAC адрес, который интересен вообще всем. То есть это не надо запускать специальный софт, для того, чтобы слушать браткастовый адрес FFFFFFFF. Оно само умеет работать. Естественно, это частный случай мультикаста. Поступил вопрос, где я не каст. Ответ очень простой. В Ethernet нет я не каста. Я не каст нужен в IP, например. Вот там он есть. В IPv4 есть кастылик в виде я не каста, в IPv6 есть штатное взаимодействие я не каста.

В Ethernet нет я не каста. Он там не нужен. Вы доставляете сигнал до всех. А дальше, кому надо, зажмурился. Кому не надо, не зажмурился. То есть наоборот, кому не надо, зажмурился. Кому надо, не зажмурился и пропустил дальше этот пакет на обработку. Так что только три типа взаимодействия. Доставляем сигнал вообще всем. Если это интересно вообще всем, это браткаст. Если это интересно некоторым, но не всем, это мультикаст. Если это интересно ровно одному, это юникаст. Все. Больше тут ничего нет. Да, ну, соответственно, вот MAC-адреса, которые у нас есть. Юникастовые адреса. Есть у любого узла как минимум один. Может быть больше, но это редкое явление. Чаще всего он один и есть. Чаще всего он прошит на заводе. Для таких прошитых на заводе адресов есть специальное название BR. Burnt in address. Ну, то есть прожженный на заводе адрес. Если вы захотите, вы можете прописать в вашей железке другой MAC-адрес. Чаще всего это возможно. Обычно в настройках драйвера сетевой карты.

И тогда ваш адрес, который вы пропишете, будет переопределять Burnt in address. Он будет называться Local Administrator. Вот если вы задаете Local Administrator адрес вместо Burnt in address, вы по-хорошему должны бить и к Local выставить в единичку. То есть тот самый, вот помните, второй, почти самый младший бит, вот он должен быть выставлен в единичку. Но никто это проверять не будет. Так что, в принципе, если вам религия не позволяет выставлять какие-то биты по указанию CRUS выше, вы можете на это дело забить. Unicast-овый адрес всегда принадлежит ровно одной железке. Никогда ни про каких условиях. Ethernet не будет работать хорошо, если у вас есть два устройства с одинаковыми Unicast-овыми MAC-ами. И все кадры, которые вы отправляете, они всегда будут идти из-под Unicast-ового MAC-а. Скорее всего, из-под одного и того же, если у вас он всего один. Мультикастовые адреса не принадлежат какой-то конкретной железке, не прописываются в настройках интерфейса. Вы должны запустить какой-то софт для того, чтобы обрабатывать какие-то кадры мультикастовые определенного формата.

И соответственно, вот эти самые кадры, они будут приходить на группу узлов, на которых запущен этот самый софт. Они приходят до вас безусловно. То есть вы не можете сказать, а мне теперь надо, чтобы ко мне приходила копия сигнала. Сигнал до вас дойдет по-любому. Вы можете либо зажмуриться, либо не зажмуриться. Вот в норме, если на вас не запущен софт, вы зажмуритесь. Но если вы запустили софт, и он сказал вам, теперь слушай эту группу, вы перестаете зажмуриваться на такие мультикастовые кадры. В случае, допустим, с IP, там мультикаст по-другому совершенно устроен. Там вы до тех пор, пока вы явно не попросите, присылая мне вот этот мультикастовый трафик, система вам не доставит сигнал, содержащий нужные мультикастовые данные. Поэтому там дополнительные всякие штуки, протоколы IGMP, мультикастовая маршрутизация и прочая всякая фигня. Здесь все просто. Сигнал до вас дойдет по-любому. Вы не можете сказать, не надо мне присылать 0,7 вольта, то самое. Вы 0,7 вольта получите по-любому.

0 к 1 вы из этих 0,7 вольта прочитаете по-любому. А дальше, если вы не просили этот мультикаст, вы просто скажете, ну и все, зажмурился, следующий кадр. Браткаст, частный случай мультикаста, соответственно, который не требует настроек. Макадрес FFFFFF. На сегодня все. Добили мы сегодняшнюю большую тему. Работу с протоколами Ethernet применительно к разным стандартам. Ну и проговорили по тому, что общее у разных стандартов. И следующая большая тема у нас будет коммутация. Продолжение следует... Продолжение следует...