Предыдущая часть.

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

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

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

Что же делает пылесос, когда ему надо передать информацию?! (Предлагаю профантазировать о модели пылесоса с подключением к таймкапсулю по вайфаю).

Предположим, что все автоматизировано, как положено в эппл и пылесос автоматически подключается к сети и получает настройки для сетевого подключения. Внутри пылесоса для функционирования передачи данных в облака при такой схеме должен быть предусмотрен какой-то компьютер-контроллер, который содержит программно-аппаратные средства для осуществления контроля параметров работы пылесоса, обработки данных и передаче данных куда нужно. Как минимум нам интересны сетевая карта вайфая (сетевой интерфейс) и операционная система с tcp/ip стеком.

В момент включения пылесос подключится к вайфай сети, запросит и получит настройки сетевого подключения, в числе которых скорее всего:

1. IP адрес

2. Маску сети

3. Шлюз по умолчанию

4. IP адреса ДНС серверов

В L3 схеме сети это будет выглядеть так:

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

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

1. IP адрес - 192.168.0.100

2. Маску сети - 255.255.255.0

3. Шлюз по умолчанию - 192.168.0.1

4. IP адреса ДНС серверов - 192.168.0.1, 8.8.8.8

Итак зачем все это нужно.

IP адрес - идентификатор хоста в IP сети, уникальное в сети 32хбитное число, представляемое для удобства человека чаще всего как набор из 4х 8мибитных десятичных чисел (байтов или октетов). Октет это восьмиразрядное двоичное число, например 11111111. В большинстве случаев сейчас байт тоже восьмиразрядное двоичное число, поэтому в данном контексте они тождественны.

192.168.0.100 - 11000000101010000000000001100100 или 3232235620 (в десятичной системе), или 11000000.10101000.00000000.01100100 с разделением октетов точками.

Тут нужно опять сделать отступление. Представьте, что вам нужно перемножить 2 числа -

LXXVIII * CXI, для многих задача покажется невыполнимой, потому что я привел числа, записанные римскими цифрами, а данная система записи чисел - непозиционная.

В то врtмя как мы привыкли использовать арабские цифры и позиционную систему записи чисел с основанием в 10.

LXXVIII * CXI = 78 * 111 = 78*100+78*10+78*1 = 7800+780+78 = 7000+800+700+80+70+8 =

= 7000+1500+150+8=8658, ну или в столбик. Эти все итерации в примере возможны потому, что каждая цифра может обозначать разные числа, находясь в разных позициях, позиции определяют соответствующие степени основания системы счисления (для нас привычно степени 10ти - 10^0 - единицы, 10^1 - десятки, 10^2 -сотни и т.д.), а цифра в позиции определяет их количество. То есть 111 = 1 единица + 1 десятка + 1 сотня.

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

В двоичной системе основание не 10, а 10, шутка, а нет, не шутка - основание 2 то есть в двоичной записи - 10, цифр соответственно не 10 (0-9), а 2 (0,1), переход в числа в следующую позицию осуществляется при исчерпании цифр в текущей позиции. То есть как в десятичной системе, пока можно увеличивать число изменяя цифру в позиции, количество позиций не изменяется. Например число будет одноразрядным, пока для единиц хватает цифр - 1, 2, 3, 4, 5, 6, 7, 8, 9, а вот цифры закончились, дальше для увеличения числа нужно изменять разряд. 10,11,12..99, опять закончились цифры уже в десятках, опять добавляем разряд, и следующее число - 100.

Еще раз в двоичной системе цифр только 2 (0,1), поэтому натуральный ряд чисел выглядит так - 1, 10, 11, 100, 101, 110, 111 и т. д. Его не трудно перевести на человеческий (десятичный), это соответственно 1, 2, 3, 4, 5, 6, 7.

Еще раз:

1-1

2-10

3-11 (почти 99)

4-100

5-101 (дальше как с 909)

6-110 (а тут как с 990)

7-111 (а это похоже на 999).

Теперь попробуем подвести это к IP адресам, то есть к их частям - октетам. Возьмем последние октеты наших устройств (таймкапсуль-маршрутизатор - 192.168.0.1, пылесос - 192.168.0.100), то есть 1 и 100, и переведем их в двоичную систему с сохранением количества цифр в октете.

1 - 00000001 (1)

100 - 01100100 (1100100)

Чтобы количество цифр сохранялось равным 8ми (это важно), в части чисел нужны лидирующие нули.

Далее нужно понять зачем все это. А все это для маршрутизации.

У каждого компьютера, оборудованного сетевым интерфейсом с настроенным IP есть таблица маршрутизации, которая создается после настройки IP адреса на интерфейсе и некоторых дополнительных параметров.

Посмотрим как выглядит такая таблица у пылесоса, после настройки сети.

После добавления IP адреса 192.168.0.100 и маски сети 255.255.255.0 к интерфейсу в таблицу маршрутизации добавилось 2 записи:

1. - 192.168.0.100 255.255.255.255 - локальный адрес

2. - 192.168.0.0 255.255.255.0 - сеть непосредственно подключена к интерфейсу

После добавления шлюза по умолчанию - 192.168.0.1 в таблицу маршрутизации добавилась 1 запись:

3. - 0.0.0.0 0.0.0.0 - через шлюз 192.168.0.1.

Итого, еще раз, в таблице маршрутизации пылесоса появилось 3 записи:

1. - 192.168.0.100 255.255.255.255 - локальный адрес

2. - 192.168.0.0 255.255.255.0 - сеть непосредственно подключена к интерфейсу

3. - 0.0.0.0 0.0.0.0 - через шлюз 192.168.0.1.

Записи обычно сортируются по возрастанию, так что при просмотре это будет выглядеть так:

0.0.0.0 0.0.0.0 - через шлюз 192.168.0.1.

192.168.0.0 255.255.255.0 - сеть непосредственно подключена к интерфейсу

192.168.0.100 255.255.255.255 - локальный адрес

Вот как это выглядит,например, в windows 7:

$ netstat -nr
===========================================================================
Список интерфейсов
14...6c 71 d9 84 cb 57 ......Atheros AR9485WB-EG Wireless Network Adapter
13...74 d0 2b b0 64 a7 ......Qualcomm Atheros AR8161/8165 PCI-E Gigabit Ethernet Controller (NDIS 6.20)
12...6c 71 d9 84 cb 56 ......Устройства Bluetooth (личной сети)
1...........................Software Loopback Interface 1
17...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP
27...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP #2
16...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP #3
15...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================
IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес  Маска сети  Адрес шлюза  Интерфейс  Метрика
0.0.0.0  0.0.0.0  192.168.0.1  192.168.0.100  20
192.168.0.0  255.255.255.0  On-link  192.168.0.100  276
192.168.0.100  255.255.255.255  On-link  192.168.0.100  276
192.168.0.255  255.255.255.255  On-link  192.168.0.100  276
127.0.0.0  255.0.0.0  On-link  127.0.0.1  306
127.0.0.1  255.255.255.255  On-link  127.0.0.1  306
127.255.255.255  255.255.255.255  On-link  127.0.0.1  306
255.255.255.255  255.255.255.255  On-link  127.0.0.1  306

Здесь кроме тех маршрутов, что я перечислял выше, есть еще несколько, но про них позже.

Теперь надо сказать несколько слов откуда эти маршруты взялись и что с ними можно делать. Представьте, что пылесосу нужно отправить какие-то данные хосту 8.8.8.8, на котором находится публичный ДНС гугла, ну типа "привет, пока, пшел вон, тупая железяка!", так сказать приветствие от IoT компании эппл, сервису компании гугл. Для отправки данного месседжа, его необходимо поместить в IP пакет с соответствующими заголовками, по минимуму как-то так:

1. IP адрес отправителя

2. IP адрес получателя

3. Тип данных

4. TTL и т. д.

Хост готовит пакет, в котором IP адрес отправителя - 192.168.0.100, IP адрес получателя - 8.8.8.8, остальное пока не важно. Далее встает вопрос куда же это отправлять? За ответом хост отправляется выбирать из собственной таблицы маршрутизации маршрут, по которому отправить пакет.

Выбор маршрута происходит просто - из таблицы выбирается маршрут для которого выполняются следующие условия:

1. IP адрес получателя входит в диапазон адресов, описанных сетевым адресом и маской сети

2. Из нескольких подходящих маршрутов выбираются те, у которых маска сети максимальна

3. Из оставшихся выбираются те, у которых метрика минимальна.

Теперь нужно понять, зачем нужны маски и как все это работает.

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

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

Чаще всего эквивалентом истинности чего-либо в вычислениях является двоичная единица, а эквивалентом лжи - ноль.

Теперь к сути операций, сначала Логическое И (умножение или AND):

Истина И Истина = Истина, Ложь И (Истина или Ложь) = Ложь, (если есть хоть немного лжи, то все целиком - ложь) или так:

1 И 1 = 1, 1 И 0 = 0, 0 И 1 = 0, 0 И 0 = 0, или так:

1 * 1 = 1, 1 * 0 = 0, 0 * 1 = 0, 0 * 0 = 0.

То есть если один из операндов - ноль, результат тоже ноль.

Далее Логическое ИЛИ (сложение или OR):

Истина ИЛИ Истина = Истина, Истина ИЛИ Ложь = Истина, Ложь ИЛИ Ложь = Ложь (если есть хоть немного истины, то все целиком - истина) или так:

1 ИЛИ 1 = 1, 1 ИЛИ 0 = 1, 0 ИЛИ 1 = 1, 0 ИЛИ 0 = 0, или так:

1 + 1 = 1 (сумма, конечно, 2, но главное, что она больше нуля, то есть результат суммирования не 0), 1 + 0 = 1, 0 + 1 = 1, 0 + 0 = 0.

То есть если один из операндов - единица, то результат тоже единица.

Логическое НЕ (отрицание или инверсия, или NOT):

НЕ Истина = Ложь, а НЕ Ложь = Истина, или так:

НЕ 1 = 0, а НЕ 0 = 1.

То есть после операции результат будет противоположным операнду.

Теперь вернемся к маскам. Маски представляют собой некий числовой трафарет (похожий на решетку Кардано), который нужен для необходимых в маршрутизации IP пакетов расчетов.

Чаще всего это набор единиц слева направо в 32х-разрядном двоичном числе. Например:

10000000000000000000000000000000 - маска /1 (1 единица) или 128.0.0.0,

11000000000000000000000000000000 - маска /2 (2 единицы) или 192.0.0.0,

11100000000000000000000000000000 - маска /3 (3 единицы) или 224.0.0.0,

11111111.00000000.00000000.00000000 - маска /8 (8 единиц) или 255.0.0.0,

11111111.11111111.00000000.00000000 - маска /16 (16 единиц) или 255.255.0.0,

11111111.11111111.11111111.00000000 - маска /24 (24 единицы) или 255.255.255.0.

Маски (32 бита) накладывается на IP адреса (32 бита), чтобы производить разнообразные расчеты.

В нашем примере с пылесосом маска 255.255.255.0 накладывается на IP адрес интерфейса - 192.168.0.100 для расчетов записей, добавляемых в таблицу маршрутизации:

Повторю еще раз 192.168.0.100 это в двоичной системе -

11000000.10101000.00000000.01100100,

а 255.255.255.0 -

11111111.11111111.11111111.00000000.

Итак на первом этапе стек рассчитывает из комбинации адреса и маски адрес IP сети, непосредственно подключенный к интерфейсу при помощи побитовой операции И:

11000000.10101000.00000000.01100100 И

11111111.11111111.11111111.00000000 =

11000000.10101000.00000000.00000000 или 192.168.0.0.

Расчетный адрес подсети соответственно - 192.168.0.0 с маской 255.255.255.0, нужно отметить, что в знакоместах адреса биты, закрытые единицами маски, не изменились, а в знакоместах закрытых нулями все единицы изменились на нули.

Далее производится операция инвертирования маски - НЕ

11111111.11111111.11111111.00000000 =

00000000.00000000.00000000.11111111

это 0.0.0.255.

Данное число называется wildcard. Это эквивалент количества адресов в данной сети.

Таким образом минимальный адрес в сети, подключенной к вайфай интерфейсу пылесоса -

192.168.0.0, а максимальный (192.168.0.0+0.0.0.255) - 192.168.0.255.

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

Все это нужно, чтобы при настройке интерфейса добавить в таблицу маршрутизации запись, указанную ранее:

192.168.0.0 255.255.255.0 - сеть непосредственно подключена к интерфейсу.

А также чтобы определять принадлежность произвольного адреса назначения в IP пакете определенной сети из таблицы маршрутизации.

Например 8.8.8.8 совершенно точно не входит в 192.168.0.0 255.255.255.0, но в таблице маршрутизации была еще одна запись:

0.0.0.0 0.0.0.0 - через шлюз 192.168.0.1,

Как понимать что такое сеть 0.0.0.0 0.0.0.0.

Давайте посчитаем.

Адрес 0.0.0.0 это:

00000000.00000000.00000000.00000000, маска такая же:

00000000.00000000.00000000.00000000, после операции И, получим

00000000.00000000.00000000.00000000, это 0.0.0.0 - адрес сети (а также и минимальный адрес в данной сети), после инверсии маски:

00000000.00000000.00000000.00000000, получим

11111111.11111111.11111111.11111111, то есть 255.255.255.255 (wildcard, количество адресов в сети), после арифметического сложения адреса сети и wildcard (0.0.0.0+255.255.255.255) получим 255.255.255.255 - максимальный адрес в сети.

После данных операций становится понятно, что сеть 0.0.0.0 0.0.0.0 (короткая запись с маской, указывающей на количество единиц маски, - 0.0.0.0/0) содержит все IPv4 адреса в сети IP. Адреса 8.8.8.8, 192.168.0.1 и 192.168.0.100 являются частью данной сети.

Продолжение следует...

Продолжение IP over Ethernet. Часть 0.2 со ссылками на 0.1 и 0.

Итак поговорим о ethernet коммутаторах.

Сначала кратенько о том как было до них:

Для понимания функционирования любой эзернет сети нужно знать немного, но все-таки кое-что нужно:

1. Адресация. Если не упоминать ранние реализации, а начинать сразу с актуальных (ethernet v2), то у каждого устройства в сети (для удобства дальше все такие устройства буду называть хостами (host) как в tcp/ip независимо от контекста L2 или L3 пока речь будет идти о связанных с tcp/ip технологиях) должен существовать уникальный физический адрес - MAC, уникальность обеспечивается координацией IEEE производителей оборудования. Каждый MAC-адрес это 48 битный идентификатор, для удобства восприятия человеком обычно представленный шестнадцатиричными цифрами, объединенными в блоки:

00:0f:9f:c5:c3:c3 - разделенные двоеточиями на 8-мибитные блоки (байты или октеты) - один из наиболее популярных видов записи;

00-0f-9f-c5-c3-c3 - то же, но с дефисами, так, обычно, в длинках;

c04a.003c.044b - разделенные точками 16-тибитные блоки - принятый вид записи в Cisco IOS;

Первые 3 октета это префикс, соответствующий вендору, а следующие 3 октета - уникальный идентификатор, назначенный производителем.

Кроме идентификаторов хостов есть MAC адреса специального назначения. Во-первых широковещательный адрес или broadcast (ff:ff:ff:ff:ff:ff), MAC адрес, который используется, когда отправляемый эзернет кадр предназначается всем хостам в сети. Во-вторых и далее разные адреса для многоадресного (multicast) трафика, vrrp и прочих.

2. Общие сведения об струтуре кадра эзернет. Минимум, который нужно знать:

Кадр состоит из 3х частей - заголовка, полезных данных и контрольной суммы. Пока нам для последующего разбора надо знать из чего состоит заголовок. На рисунке заголовок представлен 14ю байтами из которых 6 - адрес назначения (destination, dst, d), 6 - адрес источника (source, src, s), 2 - тип кадра. Надо сказать, что на физическом уровне перед заголовком есть еще и преамбула, состоящая из 8ми байт, а после кадра межпакетный пропуск, но для начального понимания коммутации они несущественны. После нехитрого подсчета минимального payload в 46 и checksum в 4 байта получим минимальный кадр размером в 64 байта.

До появления коммутаторов все кадры в эзернет сети приходили всем хостам. То есть в такой сети (для удобства среда просто обозначена как шина):

Кадр отправленный от A к C с адресами в заголовке dst 00:00:00:00:00:03 и src 00:00:00:00:00:01 приходил и к B, B соответственно должен был его отбросить, так как кадр не для него, а C принять и обработать, A во время отправки ничего принимать не мог. Если C ответит A, то кадр также попадет и к A, где будет обработан, и к B, где будет отброшен. Любой кадр с dst ff:ff:ff:ff:ff:ff приходил ко всем и обрабатывался всеми, кроме отправителя, который, как водится, ничего не мог принимать во время отправки.

Сеть на концентраторах (хабах) принципиально ничего не меняла, кадры доставлялись точно также всегда всем.

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

Картина почти идентична предыдущей, но на ней не хватает существенных деталей, которые раньше не были существенными - номеров портов, исправим.

Теперь разберемся, что происходит в такой сети при таком же трафике как в предыдущих примерах.

Кадр отправленный от A к C с адресами в заголовке dst 00:00:00:00:00:03 и src 00:00:00:00:00:01 приходит в 3й порт свича. С этого момента все совсем не так как раньше. Я писал, что свич это специализированный сетевой компьютер. У него есть центральный процессор и память (ЗУ).

Итак шаг за шагом:

1. Приняв кадр на 3м порту с src-mac 00:00:00:00:00:01, свич, используя специализированную часть ЗУ, называемую CAM таблицей, запомнит на некоторое время, что хост A с MAC адресом 00:00:00:00:00:01 подключен где-то за 3м портом. CAM таблица представляет собой специализированное ЗУ, называемое ассоциативной памятью или АЗУ, в котором поиск данных по уникальным ключам происходит очень быстро.

2. Изучив dst-mac 00:00:00:00:00:02 из заголовка и определив, что это не адрес специального назначения, свич начнет поиск записи в CAM таблице, соответствующей ключу в виде этого адреса, если записи там нет (предположим в момент, когда сеть только включилась), то кадр будет отправлен во все порты кроме того, в который пришел этот кадр. То есть дальше кадр уйдет в порты 6 и 8, где будет обработан или отброшен соответствующими хостами.

3. Если C ответит A, то кадр с dst 00:00:00:00:00:01 и src 00:00:00:00:00:03 будет принят 8м портом свича.  Свич добавит в CAM таблицу запись о том, что хост C с MAC адресом 00:00:00:00:00:03 подключен где-то за 8м портом.

4. Изучив dst-mac 00:00:00:00:00:01 из заголовка и определив, что это не адрес специального назначения, свич начнет поиск записи в CAM таблице, соответствующей ключу в виде этого адреса, найдет запись о том, что хост с MAC адресом 00:00:00:00:00:01 подключен где-то за 3м портом. Дальше кадр уйдет только в порт 3, где будет обработан хостом A. В остальные порты кадр скоммутирован не будет.

Далее при каком-то значимом трафике между хостами кадры будут уходить уже адресно только получателям в соответствующие порты, это еще называется unicast.

5. Любой кадр с dst ff:ff:ff:ff:ff:ff будет после соответствующего обновления CAM таблицы по src-mac будет отправлен во все порты, кроме того на котором он был получен. Кадр будет обработан всеми хостами, кроме отправителя.

Для оценки значимости этих простых, в сущности алгоритмов я и написал предыдущие 3 части цикла. Поскольку это и предопределило революцию, описанную ранее.

В конце приведу несколько полезных ссылок в качестве, так сказать, дополнительной литературы.

Сети для самых маленьких. Часть вторая. Коммутация

Про MAC-таблицы в коммутаторах

Всё, что вы хотели знать о Ethernet фреймах, но боялись спросить, и не зря

В Интернет через Ethernet - Nag.ru

Продолжение IP over Ethernet.  Часть 1.

Итак об локальных сетях.

Цифровая передача данных как полезная штука начала широко входить в жизнь простого бюргера в 80х годах XX века. Появились телетексты, минители, а с ISDN и разные пользовательские терминалы, объявления, службы такси, прогнозы погоды и т. д. и т. п. Это не считая RS-232 с модемами. Некоторой части общественности стали доступны локальные сети на работе, а некоторые даже занимались промышленной автоматизацией, используя какие-нибудь MODBUS/RS-485 или CAN.

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

В офисах и на заводах жили arcnet, ethernet и token-ring. Причем где надо было качественно передавать данные - преимущественно аркнет и токенринг, а где надо было дешево и быстро - преимущественно эзернет. Собственно вот это главное.

А дальше будет не менее главное второстепенное.

RS-485, arcnet, ethernet и token-ring - сети с множественным доступом (каждый участник может передавать каждому) на то время использовавшие общую разделяемую физическую среду передачи (за исключением токенринга, где все несколько сложнее/проще). Одной из существенных проблем, которую обязательно нужно решить в такой схеме - необходимость передачи информации в сети от только одного участника в каждый момент времени при молчании всех остальных. Если передавать одновременно будут несколько устройств, в сети произойдет смешение сигналов с последующей потерей данных. Решить эту проблему технически можно разными способами. Один из самых простых вариантов в MODBUS поверх RS-485 - master-slave модель, при таком варианте одно устройство в сети назначается ведущим, а остальные ведомыми, ведущее устройство опрашивает ведомые по очереди, после запроса у ведомых есть определенное время на ответ в течение которого ведущее устройство молчит и ждет, не отправляя новых запросов.

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

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

И тем не меннее вокруг нас один сплошной эзернет, а остальные почили, ну RS-485 нет, но он и не ЛВС, а промышленная сеть, а вот новых arcnet и token-ring нам скорее всего уже не увидеть.

Итак сначала об топологиях ЛВС на то время:

Эзернет - шина, токенринг - кольцевая шина, нет кольцо,нет даже сложно точно сформулировать, скорее точка-точка-кольцо или точка1->точка2->точка3->точка1, кольцевые бусы?, аркнет смешанная шина/звезда, сеть-мечта с практически произвольной топологией. В эзернет и аркнет для создания физической среды передачи применялся коаксиальный кабель, в токенринге неэкранированная витая пара.

Что было хорошего у аркнет - отсутствие коллизий, почти произвольная топология, передача данных в общей среде передачи всем участникам одновременно, у токенринга - отсутствие коллизий, 4 мбит/с против 2.5 мбит/с у аркнет, международный стандарт, у эзернет - 2 и 10 мбит/с, международный стандарт. В отличии от сетей с маркерным доступом, где очевидно были ограничения на размерность сетевого адреса и соответственно на количество устройств в сети, в эзернет довольно быстро появились 48-битные уникальные MAC адреса с механизмом их получения для производителей устройств, что позволяло теоретически запилить сеть с сотнями или тысячами устройств.

Дальше произошло несколько событий, определивших текущее положение вещей.

Сначала у эзернет появилась звездчатая топология с концентраторами/хабами (hub) внутри (как у аркнет), использующая витую пару (как у токенринг). И это произвело революционные изменения в дальнейшем. После появления сетей с хабами оказалось возможным коренным образом изменить все, заменив хаб на новое устройство, которое незамедлительно появилось. Называлось оно коммутатор или switch (свич) и представляло собой специализированный сетевой компьютер, обрабатывающий пакеты данных как пакеты, а не как электрические сигналы. Появление свичей сделало эзернет совершенно отличным от других ЛВС технологий, управление сетью стало более простым, надежность и скорость работы сети значительно увеличились, увеличилась качественно и сетевая безопасность. Доступ к среде передачи стал почти детерминированным как у конкурентов, коллизии практически ушли в прошлое. Цифровая обработка пакетов сразу предоставила громадные возможности для фантазии и творчества разработчикам программного обеспечения для сетевых устройств на десятилетия вперед.

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

Мутация из хабов в коммутаторы стала первой из череды особо значимых революций эзернета, во многом предопределив более 25 лет назад, то что происходит сегодня.

Продолжение следует...

В связи с очень полезным начинанием пикабушницы @virrasha попробую в меру сил продолжить ликбез. Обдумывая с чего же начать, решил не мудрствовать и начать с истории, тем более, что похожие попытки популярно это объяснить довольно редки, известные мне - "В Internet через ethernet" на nag.ru.

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

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

В этом месте нужно сделать первое отступление о коммутации. Все я разбирать не буду, остановлюсь на 2х важных вариантах: 1й - коммутация каналов, 2й - коммутация пакетов.

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

Большинство событий в начале эпохи цифровой передачи данных были подчинены телефонии и парадигме коммутации каналов. Цифровая передача данных в начале при всем своем отличии от механических вариантов коммутации была заточена под то же самое. Первые технологии цифровой передачи данных PDH и SDH это 50е-80е годы XX века, это технологии коммутации каналов с мультиплексированием во времени. Каналы делились на таймслоты по 64 килобита/с и из них создавался результирующий канал определенной пропускной способности T1, E1, E2 и т.д. При, например, звонке от Васи к Пете для передачи голоса резервировалось нужное количество временных интервалов (таймслотов) для передачи голосового траффика в реальном времени. Эти таймслоты при неиспользовании или недогруженности информацией для других целей использовать в сети было уже нельзя.

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

ATM в виде ISDN и DSL был довольно распространен и популярен до 2000х, он подразумевал коммутацию пакетов, возможности передачи поверх SDH/PDH, был все еще тесно связан с телефонией. Для передачи информации использовались цифровые ячейки (пакеты фиксированного размера по 53 байта с заголовком в 6 байт и с полезной нагрузкой в 48 байт) в которые могли инкапсулироваться самые разные данные от текстовых файлов до голосовых звонков в реальном времени, имелись механизмы управления качеством обслуживания, коммутация пакетов позволяла эффективнее использовать пропускную способность канала для передачи чистых цифровых данных в компьютерных сетях чем SDH/PDH. А заложенные изначально в оборудование и технологию развитые возможности для работы с конечными абонентами с корнями из телефонии позволяли операторам строить эффективные сети для продажи услуг цифровой связи.

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

Продолжение следует...

Зачем ставить комут или роутер.

Наткнулся на очередной курьез в робочие будни :)