Введение в сетевые технологии

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

Это максимально размытое понятие. По большому счету, например, телефонная сеть — это тоже сеть. И в какой-то степени нас она тоже будет интересовать. Да, мы не будем вникать в детали того, как работает телефония, но телефонная сеть — это сеть, по которой передаются какие-то данные. У нас там есть устройства, телефонные аппараты. И они обмениваются данными. Да, это голосовые данные. Это тоже сеть. Безусловно, сеть будет компьютерная. Там, где есть компьютеры, они связываются между собой, передают файлы по файлопомойкам. Пользователи 1С запускают электронную почту — это тоже сеть. Есть сети другие. Например, сеть видеонаблюдения. Это тоже сеть. Там видеокамеры, видеорегистраторы. Они между собой тоже данными обмениваются. Может быть, только в одном направлении. Может быть, и в двух. Например, PTZ-камеры, которые управляемые, которые можно джойстиком покрутить на пульте администратора. И он камеры может посмотреть в разные стороны. По проводу в одну сторону бегут видеоданные, а в другую сторону бегут команды управления.

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

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

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

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

В 99% случаев активное оборудование — это то, что вы втыкаете в розетку, и оно дальше как-то работает. Без этого оно не работает. Что в итоге такое сеть? Это какая-то совокупность устройств, которые связаны между собой через каналы связи и активное оборудование. Они между собой передают данные, терминальное оборудование формирует данные. Дальше транзитные узлы эти данные передают. И дальше получатель, другая терминальная железка, эти данные на себя принимает, и путь данных через сеть на этом заканчивается. Сети бывают разные. Уже было сказано, что есть сети телефонные, компьютерные. И задачи у них тоже разные. Мы вряд ли будем ожидать, что через телефонную сеть мы можем передавать, например, видеосигнал. И наоборот. Но задачи, типичные для сетей, мы можем сформулировать.

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

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

Например, чтобы бегали бэкапы. Тоже не самая характерная задача. Бэкап — это такая штука, которая одновременно занимает практически всю доступную полосу пропускания. Сколько ему ни дай, он будет жрать полосу пропускания. И бэкап может быть достаточно большой. Те, кто пробовал, например, бэкап хотя бы какой-нибудь виртуалочки сделать, гигов на 100–200, знают, что бэкап — такая штука, которая длится долго. И пока он длится, он действительно занимает полосу пропускания достаточно серьёзно. Если у вас сеть в это время используется для какой-то другой задачи, например, для передачи голоса, то эти задачи будут между собой конфликтовать. Потому что одному требуется всегда свободная полоса, а другому — чем больше полосы, тем лучше. Если есть вся полоса, которую можно сожрать, он сожрёт всё. Поэтому одновременно бэкап и голос друг с другом не очень дружат. Поэтому бэкап лучше ставить ночью. Можно много чего сделать.

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

которая достаточно давно делала свою сеть, вы вполне можете увидеть, что у вас есть отдельная компьютерная сеть, в которой компьютеры подключаются. Там в интернет люди ходят, 1С запускают. Есть отдельная сеть для того, чтобы связываться с какими-то внутренними серверами. Отдельный интернет и отдельно прямо внутренняя сетка, в которой что-то секретное бегает. Прямо отдельная физическая сеть для телефонов, для аналоговых, например, телефонов. Это отдельные провода, которые к каждому сотруднику приходят. Отдельно приходит доступ к интернету, отдельно приходит доступ к какой-то корпоративной сети, отдельный провод приходит для телефона, и отдельный провод приходит для чего-то ещё — тревожная кнопка или видеонаблюдение. Отдельный провод приходит к видеокамере, которая на стене висит. Это прямо все отдельные провода, они друг на друга не похожи. До видеокамеры идёт коаксиал, для телефона идёт медная лапша. Доступ в интернет и корпоративные сети могут быть витой парой сделаны. Но физически разные сети между собой вообще никак не связаны.

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

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

Когда у нас есть какая-то полезная нагрузка на сеть, мы должны будем её хорошо знать. Для того, чтобы наша сеть работала хорошо, всё, что в нашей сети бегает, мы должны будем понимать. У нас должен быть список того, что вообще в нашей сети может быть, а чего быть не может. С точки зрения того, как каждая конкретная нагрузка на сеть будет влиять на эту самую сеть, мы можем выделить три основных характера взаимодействия. Первое — это междумашинное взаимодействие. У нас стоят два сервера, и один начинает на другой лить данные. Бэкап — это типичный пример междумашинного взаимодействия. Он может быть большой, а может быть маленький. Но мы должны будем исходить из того, что если у нас такое междумашинное взаимодействие есть, оно может быть достаточно интенсивным по полосе. Например, бэкап. Запустили бэкап, и он сразу гигабитный линк уложил в стопроцентную загрузку. Легко. Чем хорошо такое взаимодействие? Компьютер, который пытается лить бэкап на другой компьютер,

да, он выжрет всю полосу, но он вам не будет звонить в середине ночи с криками: «Ты знаешь, у меня что-то как-то медленно качается». Он не умеет звонить. Компьютеры очень плохо умеют жаловаться. Если вы их научили жаловаться, если вы научили писать вам SMS, если у вас что-то работает не так, да, он может вам отправить SMS, сказать: «Что-то работает не так, ты просил меня уведомить тебя, если что-то не так работает — вот я тебя уведомляю». Но до тех пор, пока триггер, который вы ему сами задаёте, не сработал, он пытается работать в тех условиях, которые вы ему даёте. Если у вас сеть начинает работать в два раза хуже, бэкап будет длиться в два раза больше, но он всё равно будет работать. Никто не будет — сервер бэкапа не будет звонить среди ночи с криками, что у него всё плохо работает, срочно починить. Как только у вас в сети появляется человек, ситуация изменяется. Вторая строчка — интерактивное выполнение команд пользователя, там человечек нарисован. Вроде всё то же самое, вроде два компьютера, только у одного компьютера человек сидит.

И это всё меняет, потому что этот человек будет недоволен. Он всегда недоволен. Если работает хорошо — он недоволен. Если работает плохо — он очень недоволен. Разница только в степени недовольства. Но он всегда будет недоволен чем-нибудь. Если у вас сеть начинает хотя бы чуть-чуть хуже работать, он это сразу заметит, и он будет жаловаться. Он вам будет звонить среди ночи: «Ты знаешь, у меня 1С сегодня на одну секунду дольше открывается, срочно почини, так невозможно работать». И в ситуации, когда у вас человек появляется, вы должны будете понимать, что если это одноразовое какое-то явление, у вас сетка начинает работать плохо по какой-то совершенно объективной причине, и дальше вы знаете, как это починить, Вы можете сказать, знаешь, Вася, Петя, сегодня у нас авария, так что потерпи, сегодня действительно одна эска будет открываться на секунду дольше. Сегодня такой особый случай. Но если это системная проблема, то пользователь будет недоволен, он будет писать докладные записки, он будет жаловаться начальству, будет всячески вонять,

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

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

но не настолько, чтобы прямо вызывать дискомфорт. Да, чувствуется, что вы говорите по телефону, да, чувствуется, что собеседник чуть-чуть подтормаживает, но несущественно. В принципе, это вполне нормально. Субъективно 150 миллисекунд — это как бы терпимо. Мы сейчас с вами общаемся, я говорю в микрофон, и вы слышите то, что я говорю. Если бы я слышал то, что вы говорите обратно, между нами, скорее всего, как раз была бы задержка порядка 100–150 миллисекунд, и в принципе это нормально было бы. Мы могли бы с вами общаться без особых проблем. Если бы вдруг эта задержка начала расти и стала бы больше чем 150 миллисекунд, была бы 200, 300, 400, 500 миллисекунд, это было бы прямо уже реально заметно. Если вдруг вы достаточно старый, такой же, как и я, не сказать, что я очень старый, но всё-таки достаточно уже старый. Я помню, как работала аналоговая телефония, междугородняя или международная. Там задержка при передаче голосовых данных

в аналоговой международной телефонии была реально секунды, секунды две даже. Вы поднимали трубку, говорили «Алло», и дальше это ваше «Алло» только через две секунды на той стороне воспроизводилось. И человек, который услышал «Алло», он немедленно вам говорил «Да, привет». Это «Да, привет» в обратную сторону тоже шло, и ещё через две секунды вы это слышали. С момента, когда вы сказали «Алло», до момента, когда вы услышали ответное «Да, привет», прошло четыре секунды. Это реально очень сильно заметно. Это реально вызывает дискомфорт. Поэтому если у вас начинают, например, расти задержки при передаче данных, например, IP-телефонии, пользователи это немедленно будут замечать. Они будут недовольны, они будут жаловаться и говорить, что сегодня телефония работает плохо. Это становится очень-очень заметно. Если у вас начинают, например, расти потери пакетов, то же самое. В телефонии потеря пакетов — это очень и очень неприятная вещь. Давайте я сначала расскажу про другую штуку,

про джиттер, а потом вы поймёте, почему потеря пакетов — это плохо. Потому что это связанные между собой понятия. Есть такая штука, как джиттер. Это дрожание голоса. Смысл заключается в том, что если вы отправляете пакетики в той же самой телефонии, каждый из пакетиков, которые вы отправляете, содержит в себе немножко голоса. У вас аналоговый голос, который вы производите голосовыми связками, оцифровывается кусочками по, например, 50 миллисекунд. Сначала вы произнесли 50 миллисекунд, у вас это запихалось в один пакетик, потом следующие 50 миллисекунд произнесли, это снова в следующий пакетик отправилось. И эти пакетики отправляются раз в 50 миллисекунд, 20 пакетов в секунду. Пакетики мелкие, но отправляются регулярно, ровно раз в 50 миллисекунд. Если пакеты по сети проходят за одинаковое время, вы их отправляете раз в 50 миллисекунд, и они на получателя приходят тоже раз в 50 миллисекунд, то в этом случае получатель принимает эти самые пакетики,

он их декодирует и обратно в голос преобразует. И получается, что они с одной стороны вышли, с другой стороны пришли таким ровненьким потоком, и проблем с этим никаких не возникает. Но что возникает, если вдруг у нас начинаются проблемы с этим самым джиттером, с дрожанием голоса, когда у нас некоторые пакеты проходят быстрее, чем некоторые другие. Представьте себе, что у нас здесь две девушки нарисованы, которые по телефону общаются, левая девушка говорит «мама мыла раму». И у нас каждое из этих слов упаковалось в отдельный пакетик. Я уже говорил, что там вообще 20 пакетов в секунду, но «мама» в один пакет, «мыла» в другой, «раму» в третий. И всё это дело отправляется по сети. Если у нас всё хорошо, то каждый из этих пакетиков прибежит за какое-то время до получателя, за одинаковое время, и получается, что первый, второй, третий пакет мы отправили, и они в таком же порядке пришли. Первый, второй, третий. Причём с той же самой разницей, что была между этими пакетами при отправке.

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

но он где-то в сети пока ещё бежит. И дальше к нему приходит пакет «раму». И что делать получателю? У него это взаимодействие реального времени. Он должен воспроизводить все данные так скоро, как только это возможно. Соответственно, он воспроизведёт «мама», дальше пустое место, потому что пакет «мыла» ещё не пришёл. И дальше пакет «раму». «Раму» уже пришло. У получателя вообще вариантов нет. Он должен воспроизвести слово «раму». Он не может сказать: я сейчас подожду, пока у меня придёт что-то недостающее, потом воспроизведу это, а потом воспроизведу всё остальное. Он совершенно смело выкидывает то, что не пришло в срок. Да, через микросекунду, может быть, придёт недостающий пакет, но всё, уже поезд ушёл, уже вариантов нет, уже надо воспроизводить следующий пакет. Поэтому всё, что не пришло в срок, в случае с телефонией выкидывается на мороз. Поэтому у нас будет «мама», бульк, «раму». Ничего не сделаешь с этим. То, что не пришло, надо выкинуть. Вместо этого обычно заполняется каким-то либо серым шумом,

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

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

того или иного приложения. Если вы знаете, что у вас quality of service на свитчах ваших не настраивается, а сеть в какой-то момент может быть загружена на 100%, голос там запрещено просто пускать. Это должно быть незаконно, потому что он у вас будет булькать, и никто этим голосом по факту пользоваться не будет. Как-то в таком духе. Так, далее. Как вы уже поняли, все сети разные, нет двух одинаковых сетей. В сетях у нас бывает разная нагрузка, в сетях у нас бывает разное железо, в сетях у нас бывает разное количество пользователей, разные приложения запускаются поверх них. Поэтому, если вы хотите построить новую сеть, вы всегда должны будете понимать, что там внутри будет бегать. После того, как вы составите требования, вы напишете список приложений, которые будут работать в сети, и какие хотелки будут у этих приложений для того, чтобы корректно работать в сети, дальше вы уже можете выбирать конкретные технологии

для построения вашей сети. Конкретное железо, конкретные стандарты выбирать, что именно у вас по сети будет передаваться, какие каналы у вас будут по сети, оптика, медь, гигабит, 10 гигабитов — всё это вы уже выбираете после того, как у вас составлены требования к сети. Дальше. Тонкий намек на то, что перед тем, как что-то делать, надо сначала подумать. Хороший вариант: вы проводите планирование, вы составляете документ, в котором пишете, что у нас есть такие-то приложения, они требуют выполнения таких-то условий для того, чтобы работать хорошо. Соответственно, мы выбираем решение А, Б, С для того, чтобы обеспечить нормальное функционирование этих приложений. Плохой вариант — если вы начинаете закупать просто оборудование, либо самое дорогое, либо самое дешевое, потому что в итоге вы либо потратите лишние деньги, либо не решите поставленную задачу,

либо и то, и другое. Поэтому сначала подумаем, потом поделаем. Дальше. Сети, которые можно будет строить, они могут различаться. Как понимаете, сеть какой-нибудь условной компании ЗАО «Ромашка» на 20 человек, которые сидят в одном помещении, в одной комнате, и сеть какого-нибудь оператора-магистрала, условного Ростелекома или Билайна, — они немножко разные. Да, у них есть кое-что общее, и то, и другое — вроде как сеть. Но они немножко различаются между собой. У них есть какое-то едва уловимое различие. Это различие можно характеризовать следующим образом. Они разные по размеру, и у них разные задачи. Если разбивать сети по размеру, то мы можем выделить несколько классов сетей. Такая классификация по размеру на самом деле довольно вменяемая. И самый маленький класс, самые маленькие сети,

будут называться PAN, Personal Area Network. Это сеть, которая нужна для того, чтобы соединить между собой единицы узлов. Например, два узла, два ноутбука в чистом поле встретились, и один другому хочет файлик передать. В этом случае вы как раз организуете PAN-сеть. Вы берете их, патчкордом соединяете, и они у вас работают. Или, может, кто-то был настолько старый, что помнит, что лет 10 назад, или даже не 10, 20 назад, была такая штука, как инфракрасные порты в телефонах. В сотовом телефоне можно было взять и звонок другу скинуть, мелодию звонка. И это делалось через инфракрасный порт. Два друга в этом случае встречались, говорили, сейчас я тебе клёвую мелодию скину. И один другому инфракрасный порт наставлял — передатчик одного на приёмник другого — и скидывал эту самую мелодию. Смысл этого заключается в том, что у вас на очень небольшом расстоянии

очень небольшое количество узлов могут передавать данные друг другу. Но это физически нельзя сделать на большом расстоянии для больше чем 2–3–5 узлов. Сегодня типичный пример PAN-сети — это Bluetooth. У вас есть наушник, который связывается с телефоном. Там внутри тоже данные бегают. Или вы можете взять по Bluetooth с одного сотового телефона на другой фоточку скинуть. Это та самая Personal Area Network, та самая сеть на единицы узлов, когда у вас два узла друг другу скидывают фоточку по Bluetooth. Это та самая PAN-сеть. Вы можете сделать сетку на 3 узла в Bluetooth, на 4, но вы не можете сделать сеть на 100 узлов. Bluetooth физически ограничен 8 узлами, но даже если бы он не был ограничен, вы как себе это представляете, что 100 человек собрались в одном месте и думают, что сейчас один будет скидывать 99 другим людям одну и ту же фотку. Как-то это бредово звучит. Да, потому что Bluetooth изначально создавался в условии, что это сеть на единицы узлов,

на два узла, к примеру, они работают на очень маленьком расстоянии, единицы метров, до десятка метров. И это сети, как правило, то, что называется ad hoc, строящиеся по случаю. Вы в чистом поле встретили друга, скинули ему фоточку, дальше пошли, сеть быстренько организовали на момент передачи данных и быстренько же её разобрали. Bluetooth, инфракрасные порты — всё это сюда идёт, оно очень удобное для того, чтобы как раз это дело проиллюстрировать. В то же время LAN-сети, локальные сети, это уже более крупные сети, они уже следующего класса, Local Area Network, это сети на десятки, а иногда сотни узлов, скорее десятки, чем сотни. Это десятки, иногда сотни, но опять же, скорее десятки метров расстояния. Как раз пример, когда у нас есть одно здание, один офис, и мы в этом офисе хотим организовать сеть для того, чтобы на сервер обращаться, файлики с него тырить. Это как раз Local Area Network и есть. У нас есть много пользователей, но не очень много. У нас есть расстояние,

на которое должно всё это передаваться, оно опять же не очень большое. И классическая LAN-сеть — это Ethernet. Ethernet создавался исходя из того, что он будет LAN-сетью, что он будет работать на небольшом расстоянии для небольшого количества пользователей, но всё-таки это не единицы пользователей, а скорее десятки. И не единицы метров, а опять же скорее десятки метров между ними. Если вам нужно было связывать между собой много пользователей, например, представьте себе университетский кампус. Это несколько общежитий, это лаборатории, это какие-то корпуса факультетов, соответственно, это много зданий, которые находятся на расстоянии километров друг от друга. И вам надо их связать между собой в одну большую университетскую сеть. Для этого изначально предполагалось использование отдельного класса сетевых технологий, прямо отдельных, которые назывались Campus Area Network. Это сети, которые позволяли между собой соединять тысячи, иногда даже десятки тысяч узлов,

но достаточно компактно расположенных, в пределах какой-то ограниченной площади до одного километра. Сегодня этот класс сетей мы практически не видим за счёт того, что Ethernet начал разрастаться и фактически этот класс в себя подмял целиком. Если вы сегодня будете видеть те же самые университетские кампусы или какие-то крупные компании, у которых несколько зданий, стоящих рядом, скорее всего, они будут использовать Ethernet. Просто Ethernet немножко не такой, который был раньше. Изначально Ethernet позволял между собой связывать только небольшое количество узлов на небольшом расстоянии друг от друга. Сегодняшний Ethernet — это уже немножко другой Ethernet. И если вам нужно будет проиллюстрировать какой-то технологией сегодня этот самый класс CAN, то это будет Ethernet с коммутацией, про которую мы будем говорить отдельно. Далее. Отдельный класс сетей — это MAN, Metropolitan Area Network. Это, например, сотовая связь. У нас есть вышка,

которая накрывает город или отдельный микрорайон, и под этой вышкой ходят тысячи, десятки тысяч человек. И все с сотовыми телефонами. И все там что-то делают. Как раз LTE — куча сотовых телефонов бродит под одной вышкой. Все они объединены в одну сотовую сеть. И расстояние, на которых это всё работает, до десятков километров. И пользователей в сети может быть достаточно много, до десятков тысяч. Всё, что больше, — это уже WAN-сети, Wide Area Network. Это сети масштабные. Если у нас есть расстояние, на которое надо передать сигнал, больше чем 10 километров, 20, 30, 50 километров, мы протягиваем провод. Это без вариантов. Там уже никакие радиотехнологии работать особо не будут. Или это будет какая-то спутниковая связь. Она будет работать на большое расстояние, но с небольшим количеством участников. Поэтому, как правило, WAN-технология

исходит из того, что у вас узлов в сети будет немного. Там нельзя сделать такой провод, который будет подключать 100 абонентов, или 1000 абонентов, или миллион абонентов. Вы, как правило, будете прокладывать провод до каждого пользователя отдельно. Поэтому у вас в канале WAN будет, как правило, два абонента. Левый, правый. Расстояние при этом может быть практически любым. Всё, что больше чем 10 километров, — это всё WAN-технологии. И, по большому счёту, сегодня WAN-технологии заползают в сегмент MAN-сетей. И поэтому WAN и MAN сегодня — это практически одно и то же. Так. Эта классификация нужна для того, чтобы вы понимали следующий момент. Сети разные. И они разные не потому, что у них разный формат провода, разные сечения кабеля и всё остальное. А из-за того, что каждая технология создаётся под решение конкретной задачи. Если у нас есть задача организовать между собой передачу данных в одном офисе,

у нас там сидит 10 человек или 20 человек, это LAN-сеть. У нее задачи соответственные. И поэтому мы выбираем технологии построения LAN-сети. Мы выбираем Ethernet для того, чтобы связать между собой небольшое количество пользователей, которые сидят в географически компактной зоне. Если нам нужно передать сигнал на большое расстояние, мы не выбираем LAN-технологию. Мы выбираем WAN-технологию для того, чтобы передать сигнал на большое расстояние. Да, у нас будет в этом случае небольшое количество пользователей. Эти технологии такие, потому что они решают задачи класса, под который они создавались. Ethernet решает задачи LAN-сетей. Условно, LTE решает задачи MAN-сетей. Если вы будете пытаться Ethernet-ом накрыть весь город, у вас, скорее всего, ничего не выйдет. Если вы пытаетесь LTE использовать для того, чтобы в офисе все пользователи могли обращаться к серверу, у вас тоже, скорее всего, ничего не выйдет. Поэтому выбирайте правильно технологии, исходя из тех задач, которые у вас есть.

Магистральные сети провайдеров — это WAN, как правило. Если мы говорим про магистраль, именно, то это всё WAN. Здесь в качестве примера приведена как раз сеть SONET, технология SONET — это Synchronous Optical Network. Как раз такой образцово-показательный механизм построения магистральной сети провайдера. Сегодня в меньшей степени он популярен, опять же, за счет того, что кое-какие другие технологии, не будем показывать пальцем на Ethernet, но некоторые другие технологии в этот сегмент тоже пытаются пролезть. Но всё-таки классический WAN — это как раз магистральные провайдерские сети. Проблема заключается в том, что если вам надо сигнал передать на расстояние, условно, 50 километров, то есть явно больше, чем 10 километров, которые Metropolitan Area Network может себе позволить, то отдельно взятая компания, просто какая-то маленькая, не может себе позволить передать сигнал на такое расстояние.

Она не может закопать в землю 50 километров провода просто так, потому что ей захотелось. Представьте себе, что вы, условно, в Москве, не знаю, представляете географию Москвы или нет, вы в Москве хотите из условного Медведкова передать сигнал в условное Бутово, это север и юг Москвы соответственно. Между ними расстояние условно 40 километров. Но эти 40 километров проходят по плотной городской застройке. Вы не можете физически, если у вас два офиса разнесены на 40 километров, закопать в московский асфальт 40 километров кабеля. Потому что вам придется раскопать Кремль, это наверняка вызовет некоторое неудовольствие ФСО. Это будет адски дорого, и вам просто этого никто не даст сделать, даже если у вас будут деньги. Поэтому вы с вероятностью единица пойдете к провайдеру и скажете: дорогой провайдер, нам нужно передать сигнал оттуда досюда. Пожалуйста, ты уже закопал в московские канализации много километров кабеля. Дай, пожалуйста, нам немножко своего кабеля, своей оптики, для того чтобы мы могли передать сигнал. Провайдеры — это такие специальные ребята,

у которых есть возможности протянуть сигнал на большое расстояние. Они располагают такими фондами, которые позволяют им закопать нужное количество проводов в землю на нужное расстояние. У условного Ростелекома есть достаточно денег для того, чтобы всю планету окутать оптикой. Так что всё, что касается провайдерских сетей, это, как правило, именно WAN-сети. С одной стороны, потому что это то, что им нужно, а с другой стороны, WAN-технологии фактически только провайдерам доступны, больше никто, кроме провайдеров, не может себе позволить реализовать такого рода каналы. Так. Мы с вами говорили про то, что сети разные, и нагрузка в этих сетях тоже разная. Соответственно, мы должны будем составить некий план, в котором написано, что мы хотим от этой жизни, и как мы собираемся этого добиваться. При этом рано или поздно возникнет вопрос:

окей, сделали бумажку, написали в этой бумажке, что у нас будет бегать голос, электронная почта, бэкап и что там ещё другое бывает, одинеска какая-нибудь, и мы подошли к тому, что надо решить, что за железо мы покупаем. И здесь вас ожидает не то чтобы проблема, но вопрос: а что покупать? Например, свитчи бывают гигабитные, 10-гигабитные, 40-гигабитные, 100-мегабитные. Какой свитч выбрать? А даже если мы выбрали, что мы покупаем, например, гигабитные свитчи, они почему-то бывают, например, за 10 тысяч рублей, а бывают за 100 тысяч рублей, а бывают за миллион. Возникает вопрос, за что мы платим. Чем отличается свитч за 10 тысяч рублей от свитча за миллион? И в этот момент мы должны будем отчётливо

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

В случае, например, с современными Ethernet-ами, они все используют топологию точка-точка. А старые версии Ethernet-а, про которые мы будем с вами отдельно и очень много говорить, они все использовали топологию общей шины. И, например, Wi-Fi сегодня тоже использует топологию общей шины, потому что у нас там в общей среде передачи данных передаётся сигнал. И у нас среда передачи данных одна на всех. У нас есть 10 абонентов, например, Wi-Fi сети. Частота, на которую они могут передавать или не передавать данные, она всего одна. Если у нас начинает один участник передавать данные, все остальные сидят и молчат. Они не могут в этот момент занять частоту, она уже занята. В случае, если мы используем топологию с общей шиной, мы должны будем понимать, что если у нас написано на коробочке 100 мегабит, но при этом используется общая шина, то 100 мегабит — это скорость, которая в каждый момент только одним участником может быть задействована. А все остальные не могут в этот момент передавать данные вообще.

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

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

к примеру, бизнес-центре, условно, Москва-Сити, и вы работаете с персональными данными, то вы должны будете заморочиться на безопасность, чтобы никто к вашим данным не получил доступа, потому что вокруг вас находится много людей, и некоторые из них могут быть вполне замотивированы ваши данные украсть, либо модифицировать, или что-то с ними ещё сделать. Про безопасность мы тоже будем говорить отдельно и много. Надёжность и отказоустойчивость — это два разных термина. Они похожи друг на друга, но это про разное. Надёжность — это насколько конкретно выбранная вами технология может сломаться или не может сломаться. А отказоустойчивость — это что будет, если она всё-таки сломается. Я бы хотел прокомментировать безопасность, надёжность и отказоустойчивость на примере сравнения Wi-Fi и Ethernet. Wi-Fi у нас технология беспроводная, Ethernet — это, как правило, проводная технология.

И если мы говорим про безопасность применительно к Ethernet, то в Ethernet для того, чтобы получить доступ к передаваемым данным, надо физически получить доступ к проводу. До тех пор, пока вы не получили доступ к проводу, вы не знаете, что передаётся в этом самом проводе. Да, некоторое время назад были опубликованы инструменты, с помощью которых можно на некотором расстоянии, достаточно небольшом, не повреждая сам провод, с помощью очень чувствительных радиоприёмников подслушать, что передаётся в проводе на небольшой скорости, например, на 100 мегабитах. Но в целом можно говорить, что если у вас физического доступа к проводу нет, и вы не работаете в условном ЦРУ или АНБ, то вы не можете перехватить данные, которые передаются в проводе. Если вы хотите отправить какие-то данные в провод от имени какого-то другого участника, вам опять же необходимо будет иметь доступ к этому физическому проводу. Если у вас физического доступа к проводу нет, вы вашу сеть уже защитили. Не вы, а владелец сети защитил сеть от вас.

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

Определённо противопоказан, я бы сказал. Надёжность — это то, с какой вероятностью оно сломается. Тот же самый Ethernet проводной. Вы его сделали, проложили провод, и дальше с этим проводом ничего не случится. Он в стене лежит, пить-есть не просит, мыши его могут погрызть, но вероятность того достаточно небольшая. Хотя у меня был случай, когда мыши перегрызли Ethernet-овский провод, который лежал в стене. Или, может, там бухгалтер, который, как в анекдоте, покрутился на стуле и соответственно запутал патч-корд вокруг стула и выдернул этот патч-корд. Вероятность того, что с проводом что-то случится, она небольшая, и скорее всего это можно будет легко починить. В то же время, если говорим про Wi-Fi, то Wi-Fi сломаться, передача сигнала может очень легко. Частота публичная. У вас кто-то запустил микроволновку, она работает на этой же частоте. Микроволновка, если вы не знали, работает на частоте 2,5 ГГц.

2,5 ГГц — это не идеальная частота. Это не означает, что ровно 2,5 ГГц и всё. Это значит, что он в районе 2,5 ГГц шумит очень сильно, а вокруг в диапазоне там 100–200 МГц шумит просто сильно. Поэтому, когда на 2,5 она начинает работать, она и на 2,4, и на 2,3 шумит, и дай Боже, где ещё. Поэтому, когда мы говорим про Wi-Fi 2,4 ГГц, который работает, микроволновка в него шумит дай Боже. Всякие игрушечные машинки в 2,4 работают, машинки на радиоуправлении, рации, всякие пульты управления, которые по радио. Всё это работает на одной и той же частоте. Bluetooth тот же самый. Частота публичная, и если вдруг у вас кто-то начинает передавать данные на той же самой частоте, что и вы, то ваши данные соответственно будут страдать. Поэтому Wi-Fi может поломаться, и очень легко. Вероятность того, что Wi-Fi сломается, сильно выше по сравнению с проводом. В то же самое время,

мы говорим, надёжность у провода выше, а у Wi-Fi меньше. А отказоустойчивость, которая звучит похоже очень на надёжность, она наоборот, у Wi-Fi выше, а у провода меньше. Что будет, если провод сломается? Да ничего с ним не будет. Он будет лежать сломанный, вы пока не спаяете его, или не перепроложите заново, или не переобожмёте, он так и будет сломан. Что будет, если у вас в Wi-Fi случится отказ, и там кто-то включил микроволновку, и Wi-Fi у вас соответственно пострадал. Знаете, что произойдёт? Если поставите рядом вторую точку с тем же самым SSID, он немедленно переподключится на другую точку. Поэтому отказоустойчивость Wi-Fi на самом деле как раз выше, чем у провода. Потому что, если вдруг сломалась передача данных на одной частоте, Wi-Fi может упрыгать на другую. Сломался в 5 ГГц — он упрыгал на 2,4. Сломался 2,4 — он упрыгал в пятёрку. Отказоустойчивость у Wi-Fi на самом деле выше, чем у Ethernet. А надёжность ниже.

Масштабируемость — это достаточно очевидно, то, насколько большую сеть можно будет построить с использованием выбранной технологии. Опять же, пример Wi-Fi современного и Ethernet современного очень наглядный, очень показательный. Вы можете построить современную сеть на коммутаторах Ethernet, и это будет сеть весьма большая. Можно построить сеть на тысячи, десятки тысяч портов, и это вполне стабильно будет работать. А Wi-Fi на тысячу или десяток тысяч абонентов построить — реально большая сложность. Это характерный пример. Опять же, недавно в Сочи проходила Олимпиада, и олимпийские объекты — это стадионы, на которых может действительно быть десяток, несколько десятков тысяч пользователей, и все эти пользователи будут смотреть какое-то мероприятие. Что они будут делать правильно? Они будут вести стримы. Поэтому для того, чтобы обеспечить множество пользователей, которые будут одновременно достаточно интенсивно загружать сеть

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

поставленную задачу, мы можем купить либо вот такие свитчи, либо вот такие свитчи, пятые, десятые, но, соответственно, они все стоят разное количество денег. Какой конкретно свитч мы должны будем, например, купить для того, чтобы решить поставленную задачу? Если они все решают поставленную задачу, ответ простой, самый дешевый. Здесь очень часто есть такой когнитивный диссонанс у людей, что они говорят, ну, мы же не хотим самый дешевый, мы хотим тот, который будет дороже, потому что он прикольный, он клевый, модный, молодежный, вот, соответственно, мы не хотим дешевый, потому что дешевый это фу-фу-фу-фу, и здесь очень-очень-очень важно понимать, что вы работаете не с игрушками, вы работаете с инструментами. ставленную задачу, то, соответственно, надо брать самый дешевый из тех, которые решают поставленную задачу. Если вы не хотите брать дешевый потому что, и дальше потому что А, Б, С, значит, вы вот этот вот А, Б, С должны внести в список требований, что самый дешевый свить не удовлетворяет этим требованием, что мы хотим купить более дорогой свить, потому что он такой

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

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

Дальше. Порядка 35% налогов работодатель платит, за то, чтобы платить вам вашу зарплату. То есть вы эти налоги не видите, но работодатель их все равно платит. Это всякая пенсионка, социальное страхование и прочее, прочее, прочее. Для того, чтобы этого работника иметь, надо ему где-то выделить рабочее место. Опять же, аренда, освещение, уборка этого рабочего места и прочая лабуда. В итоге, на круг, когда вы платите этому работнику 50 тысяч рублей чистыми в месяц, не самая большая зарплата по Москве, например, он вам грязный, обходится порядка сотки в месяц. Теперь смотрите, следите за руками. 100 тысяч рублей в месяц, 12 месяцев. Вы в миллион, миллион 200 тысяч ему должны будете платить в год. С учетом всяких больничных, отпускных и прочих, на самом деле, это будет скорее миллион 300, миллион 400. 2 миллиона. За горизонт планирования 5 лет вы заплатите 7,5 миллионов рублей. За то, что у вас будет вот этот администратор,

который за всем этим делом следит. Это намного больше, чем стоит любая железка, которая сможет обслуживать этот администратор. Поэтому фонд оплаты труда в этой самой совокупной стоимости владения, он намного выше, чем стоимость, которую вы оставите в магазине. Вы можете смело покупать вдвое более дорогую железку, если потом вы сможете 5 тысяч рублей сэкономить на зарплате сотрудника. Это будет прямая экономия. То есть, если вы купите свитч не за 50 тысяч рублей, а за 100 тысяч рублей, но при этом сможете миллион сэкономить на зарплате через 5 лет, это напрямую как бы выгода при этом есть. Вы должны будете понимать, что если вдруг вы сами распоряжаетесь этим деньгами, если это ваши деньги, ваш бюджет, то вы, естественно, должны будете сами это все посчитать и принять решение самостоятельно. Если вы защищаете ваш бюджет, доказываете вашу точку зрения кому-то вышестоящему, то вышестоящему человеку абсолютно наплевать, какой свитч вы купите и что такое Ethernet, и чем он отличается от Wi-Fi. Ему важны деньги,

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

либо чистый медный провод, либо если вдруг вы будете пытаться сэкономить, вы можете столкнуться с такой вещью, как медленный алюминий, CCA, Copper Cloud Aluminium Cable. Вот этот вот самый медленный алюминий – это алюминиевый кабель, на который, не снаружи, как сказать, на поверхность которого напылена медь. Естественно, такой кабель сильно дешевле, потому что алюминий дешевле, чем медь. Вот. В чем смысл этого самого медленного кабеля? Он дешевле. Это его основное преимущество. В чем недостаток этого кабеля? Он ломается. Он физически более хрупкий, потому что медный кабель, он достаточно пластичный, его можно гнуть, его можно там узлом вязать. А алюминиевый кабель, он все-таки склонен ломаться. И к тому же он существенно более, существенно хуже работает на больших расстояниях. То есть если мы говорим про Ethernet, например, то классическая длина для Ethernet кабеля – это 100 метров.

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

А при прочих равных, если действительно кабель решает поставленную задачу, зачем платить больше? Еще бывает амедненная сталь, CCS, Copper Clad Steel. Если вам нужно работать на больших расстояниях, не покупайте амедненку. То есть, если вам закупчики, например, пытаются всунуть амедненный кабель под видом медного, бейте их по рукам, говорите, что вы с этим работать не будете. Но, в принципе, да, на небольших расстояниях работать нормально. Чистый алюминий встречается редко. Что еще бывает? Оптика бывает. Мы про оптику будем говорить отдельно, когда поговорим про Ethernet. Но смысл в том, что да, там стекло, самый стеклянный кабель, и он физически сделан из двух разных сортов стекла. Сначала идет внутренняя часть, которая называется сердечник, потом вокруг нее другой сорт стекла с немножко другим показателем преломления. И пучок света, который вы отправляете вот в эту сердцевинку, он целиком и полностью без каких-либо искажений,

без каких-либо затуханий, практически без затуханий, доходит до другого конца проводов. Там такой световод, и вы можете, договорившись между двумя узлами, как именно вы кодируете цифровой сигнал с помощью пучка света, передать сигнал на достаточно большое расстояние. Оптический кабель может использоваться для передачи данных на тысячи километров. Там не без черной магии это происходит, но все-таки, да, это возможно. Поэтому, например, трансатлантические кабели, они все как раз оптические. Что еще бывает? Радио бывает. То есть классический пример Wi-Fi, сотовая связь, спутниковая связь. Ну, там много чего есть, там бардак в этой области. Все остальное – это экзотика. То есть несмотря на то, что оно, в принципе, встречается, мы всерьез это рассматривать не будем. Там тоже самое инфракрасное излучение. Я вам про него уже упомянул сегодня, что если кто-то достаточно старый, он мог видеть эти самые инфракрасные порты на сотовых телефонах. Но сегодня это все-таки уже экзотика очень сильная.

Иногда бывает звуковое излучение, иногда бывает световое излучение. В видимом свете или в слышимом звуке можно передавать данные. Но это, опять же, всё реальная экзотика. Если мы говорим про передачу в, например, медном проводнике, то самое первое, что может прийти в голову, это то, как был устроен самый-самый старый Ethernet. Ethernet, когда его придумали, был устроен как провод с общей шиной. Сегодня Ethernet работает не так. Я специально сейчас вам показываю, как он работал изначально, и мы потом ещё будем вспоминать, как работал Ethernet изначально. Это будет достаточно важная вещь. Сейчас просто в качестве примера. У вас были компьютеры. В каждый компьютер втыкалась сетевая карта. Эта сетевая карта имела разъём, так называемый BNC-разъём, байонетный разъём, на который завинчивается коннектор. И эти коннекторы назывались T-коннекторы. Вот так они выглядели, буквой T. Вы подключали к карточке T-коннектор.

У него был левый разъём и правый разъём. И вы эти T-коннекторы соединяли в одну большую длинную колбасу. Брали куски провода и соединяли их, навинчивая друг на друга. Один левый соединяли с одним правым концом. И получалось: первая соединялась со вторым, вторая с третьим, третья с четвёртым. И на концах обязательно ставились вот такие заглушки — терминаторы. Одна с одного конца, другая с другого конца. И получалась такая неразрывная колбаса на много-много абонентов. Это был физически один большой проводник. Это одна большая электрическая цепь. Это не то, что вы соединяли второго с третьим, третий с четвёртым, и они были попарно соединены. Нет, они все были соединены в одну большую электрическую цепь. Если кто-то занимал среду передачи данных, то есть левый узел начинал передавать данные, он не передавал их только правому, он их передавал вообще всем. Он передавал данные в этот проводник. Он подавал на этот проводник, там два контакта было,

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

Мы про это будем говорить, когда будем говорить про Ethernet. Что можно сделать ещё, если мы говорим про физику? Можно не делать общую среду. Можно взять и сказать, что у нас, например, есть компьютеры, и мы хотим эти компьютеры подключить в одну сеть, но мы не хотим их объединять в одну общую среду. В этом случае мы можем использовать связь в том виде, в котором она, например, в современных Ethernet устроена, то есть это топология точка-точка. Здесь будет три компьютера и одно какое-то центральное устройство, которое соединяет эти узлы между собой. С точки зрения передачи аналогового сигнала, этот рыжий порт, рыжий провод — это отдельный провод, и сигнал, который в нём передаётся, не распространяется дальше. Сигнал, который левый компьютер посылает на центральный узел, доходит до другого конца провода и там останавливается. Дальше этот центральный узел, если захочет, может передать копию этого сигнала куда-то дальше,

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

И сигналы, которые передаются в каждом из этих проводов, не смешиваются друг с другом. Если вдруг здесь компьютер подал плюс 0,7 вольта, а другой компьютер на свой порт подал минус 0,7 вольта, это не вызывает смешение этих вольтов. Центральный узел, который наверху находится, действительно услышит плюс 0,7 вольт на одном порту и минус 0,7 вольт на другом порту. В случае с общей шиной эти сигналы бы смешались, если два узла одновременно начали бы передавать сигналы друг другу. А в случае с точкой-точкой у нас один узел передаёт данные, второй эти данные слушает, и больше ничто не может повлиять на эти данные. Так, здесь у нас встречается некая специальная терминология. Терминология будет следующая. Первое — это терминология американского института по стандартизации, American National Standardization Institute.

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

Вот это как раз и есть симплексное взаимодействие. У нас один-единственный участник, который передаёт сигнал, и он всегда один. Мы хорошо знаем, что это за передатчик, и он фиксированный и стабильный. Полудуплексное взаимодействие — это немножко другое, хотя и очень похожее. У нас тоже есть канал передачи данных, но этот канал передачи данных делится между многими разными участниками, и эти участники могут в разные моменты времени занимать этот канал. Но в каждый конкретный момент времени только один участник может занять канал передачи данных. Если у нас есть полудуплексное взаимодействие, как, например, рации, милицейские рации, или то, что называется walkie-talkie, у нас есть несколько передатчиков. Если вдруг два передатчика начнут передавать данные одновременно на одной частоте, будет коллизия. Поэтому для того, чтобы всё работало хорошо, кто-то один должен будет передавать данные, все остальные должны будут сидеть и слушать его.

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

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

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

Вы не просто сказали «Привет, на такой-то улице произошло преступление». Вы должны будете сказать диспетчеру, кто вы, назвать, например, свой номер и сказать, что произошло. И дальше диспетчер должен вам повторить то, что он услышал, и таким образом вы поймёте, что то, что вы сказали, действительно дошло до получателя, и что в этот момент никто ничего не перебил. И есть договорённость о том, как использовать эфир. Это фактически тот же самый арбитр. Арбитр — не какое-то физическое лицо, а договорённости между всеми участниками, как можно использовать общую среду передачи данных. И третий тип взаимодействия, который различает ANSI, это дуплексное взаимодействие, когда у нас есть канал передачи данных, и он позволяет одновременно принимать и отправлять данные. Современные Ethernet'ы, они, как правило, дуплексные, за счёт того, что они точка-точка. Проиллюстрировать это, опять же, может быть, не телекомовским методом можно, но представьте себе автостраду. Данные, которые передаются в дуплексном канале, передаются одновременно в две стороны,

и туда, и обратно, и от вас, и к вам. На автостраде машины едут и в одну сторону, и в другую, они не сталкиваются при этом. Но при этом автострада — одна часть её идёт в одну сторону, от вас, другая — к вам. Но она как линия выглядит. Вот это как раз точка-точка — канал, в котором есть передача данных в одну сторону и передача данных в другую сторону. Эти данные не сталкиваются до тех пор, пока кто-то не выедет навстречу. Выехать навстречу на автостраде сложно, потому что там барьер. В Международном союзе электросвязи ITU не различают симплексное и полудуплексное взаимодействие, поэтому если вдруг вы будете читать американскую литературу, там различаются симплекс и полудуплекс. А в европейской литературе, как правило, всё, что не предполагает одновременной отправки и приёма данных, всё это называется полудуплексным взаимодействием. Не надо это запоминать, это просто для понимания того, что такое дуплекс

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

По этой причине в современном Ethernet у вас не может быть такого, что сигналы столкнутся или устроят кашу. Они физически этого не могут сделать. В то же время у точки-точки есть одна особенность: вы должны будете отправлять сигнал на одно устройство. Соответственно, вы не можете, если вам нужно отправить сигнал на 2, 3, 10 разных устройств, сделать так, чтобы на каждое устройство вы смотрели отдельным проводом. Поэтому, если у нас на картинке нарисовано три узла — я сейчас сознательно не говорю термин «компьютер», потому что это не совсем компьютер, это узлы какие-то — узел А, Б и С. И нам нужно с узла А на узел С передать некий сигнал. Но с А до С физический провод не идёт. Нам нужно сделать как-то так, чтобы узел А передал сигнал узлу Б и в этом сигнале закодировал какие-то данные, из которых было бы понятно, что эти данные адресованы узлу С. У нас оно должно пройти

— сейчас нарисую — по вот такой трассе. Узел Б должен понять, что он не конечный получатель, он транзитный получатель. И дальше передать данные, которые были им получены. В этой ситуации нам нужно будет каким-то образом узел Б проинструктировать, что дорогой узел Б, это не тебе, это куда-то дальше в сторону узла С. Мы, соответственно, своим передатчиком — TX это стандартное обозначение для слова transmitter — мы своим передатчиком, трансмиттером, отправляем какой-то сигнал, он получается ресивером, получателем, приёмником узла Б. Узел Б получает аналоговый сигнал, декодирует его, смотрит, что там прибежали какие-то полезные данные, понимает, что эти полезные данные не ему, принимает решение, куда их дальше девать, смотрит, что дальше их девать надо в сторону узла С. Почему он это решил, мы сейчас не специфицируем, но он принимает такое решение и дальше отправляет своим передатчиком в сторону узла С

эти данные на узел С. Узел С, соответственно, эти данные ловит и принимает, обрабатывает как-то уже самостоятельно. При этом важно, что сигнал, который передавался от узла А на узел Б, и сигнал, который передавался от узла Б до узла С, это два разных сигнала. Это два разных электрических сигнала. Они могут быть разных стандартов, они могут передаваться с разной скоростью, они могут передаваться в разных физических средах. И фактически это два абсолютно не связанных сигнала между собой. Данные передавались одни и те же, а сигналы при этом разные. Здесь нарисовано, что узел B — это компьютер. Вы можете представить себе, что это не компьютер, а, например, свитч или роутер. Он с одной стороны данные получил, с другой стороны данные выплюнул. Он транзитный узел, и этот узел передаёт данные с одного порта на другой. При этом каждый из каналов — вот этот канал и вот этот канал — это канал точка-точка, который связывает транзитный узел с, в нашем случае, терминальными узлами А и С.

А может быть, они тоже нетерминальные, может быть, они тоже транзитные. Заранее предсказать это сложно. Если бы у нас была общая шина, то у нас несколько узлов подключалось бы к единой среде передачи. И в этом случае, например, в старых Ethernet'ах очень хорошо это заметно, у нас не нужно было бы иметь никакие транзитные узлы. Оно бы просто так всё работало. У нас один общий проводник, одна общая среда передачи данных. В этой среде передачи данных все узлы слышат, что передаётся. Если кто-то начинает передавать сигнал, все остальные слышат этот сигнал целиком. Нельзя отправить в коаксиальном проводе какой-то сигнал, чтобы первый, второй узел из трёх получили этот сигнал, а третий — нет. Вы передаёте один сигнал, все узлы в канале этот сигнал слышат. Соответственно, для того чтобы не устроить коллизию, есть договорённость, что каждый конкретный узел может занимать этот канал,

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

что получит узел Б, что он там своим приёмником намерит? Может быть, плюс 0,7 вольта, может, минус 0,7 вольта, может, ноль, а может, плюс 0,2 — одному богу известно. Что бы он ни принял, это в любом случае некорректный замер будет. Он не будет означать ничего конкретного. Поэтому эта самая коллизия — штука очень неприятная, и с ней принято каким-то образом бороться. Есть два механизма. Можно, если она произойдёт, бороться с её негативными последствиями, или второй вариант — не доводить до того, чтобы коллизия вообще произошла. Например, в Ethernet используется как раз первый вариант: если вдруг коллизия произошла, дальше с её негативными последствиями можно будет бороться. Потому что в Ethernet есть механизм обнаружения коллизий, узел может понять, что коллизия произошла. А в Wi-Fi, например, такого механизма нету. Коллизия произойти может, но про это никто не узнает. Поэтому в Wi-Fi есть дополнительные механизмы, как сделать так, чтобы коллизия вообще не случилась. Или вероятность её возникновения

была бы минимальной. Но про Wi-Fi мы с вами будем говорить, если и будем говорить, то отдельно и очень мало. Помимо общей шины и точка-точка, есть ещё и другие типы физической топологии, кто на кого как смотрит. И здесь можно встретить, например, такую штуку, как NBMA — Non-Broadcast Multiple Access. Это сценарий, при котором кое-кто кое-кого кое-как видит, но не все всех. Если мы возьмём, например, беспроводную сеть. Беспроводная сеть — вроде бы все узлы работают на одной и той же частоте. У нас есть точка доступа. Первая станция, у неё антенка. Вторая станция, у неё антенка. Третья станция, четвёртая станция. У них у всех есть антенки. И, соответственно, вот это первая, это вторая, эта третья,

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

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

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

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

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

не обмениваются данными, то эта штука будет иметь специальное название. Это будет называться точка-многоточка или point to multipoint, когда у нас есть какая-то среда передачи данных, и вот это вот есть узел, который увидят всех, и если вдруг этот узел получает какой-то сигнал из провода, из антенки, что надо будет обратно, этот сигнал будет отправить в этот же канал. Это вот как раз называется point to multipoint. Он удобен тогда, когда у нас неполная связность между узлами, и, соответственно, есть обязательно связанность у любого узла с центральным. В этой ситуации как раз точка-многоточка будет являться упрощением NBM-а топологии non-broadcast multiple access, и она будет обеспечивать нормальную, комфортную организацию среды передачи данных. С точки зрения центрального узла это будет фактически поведение, как будто среда с общей шиной. То есть если кто-то занял эту среду,

он сидит, молчит, ничего не делает. Он дожидается, пока среда освободится. Он слышит любую передачу любого другого участника, поэтому если никто не передает, то эту среду можно занять, и, соответственно, если он начинает занимать эту среду, все остальные узлы услышат, что среда будет занята. А с точки зрения всех остальных это точка-точка, правда, полудуплексная. То есть если кто-то слышит, что передает хотя бы кто-то, он сидит и молчит. Там дополнительно надо будет каким-то образом побороться с коллизиями, то есть сделать так, чтобы если вдруг у нас есть два участника, которые друг друга напрямую не видят, но через этот транзитный узел они в принципе могут передавать друг другу данные, вот если они друг друга не видят, они могут одновременно захотеть передавать друг другу данные. Такое может быть. Они же видят, что среда свободна, потому что сигнал одного не достреливает другого напрямую. Вот они начинают передавать друг другу данные, центральный узел видит кашу. Чтобы такого не было, там нужно будет с коллизиями побороться отдельно. Но вот в целом вот это вот самое point-to-multipoint,

это то, как, например, у нас там на самом деле устроен современный Wi-Fi. У вас то, что я называю центральным узлом, это называется точка доступа. Вот она ровно так и устроена. Что если у вас есть два сотовых телефона, которые лежат на столе, и они подключены к Wi-Fi, который находится в другой комнате, и вы хотите с одного телефона на другой отправить данные, физический сигнал пойдет сначала на точку доступа, а потом вернется на сотовый телефон соседний, который лежит там в 10 сантиметрах от него. Да, трафик будет так ходить через точку доступа. Вот. Так. Если у нас есть какой-то канал передачи данных, то в нем передается некий аналоговый сигнал. То есть либо мы в него, не знаю, фонариком светим, лазером, если это оптический провод, либо если это электрический проводник, мы на него подаем какое-то напряжение разное, постоянно. При этом, естественно, что там нельзя сделать так,

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

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

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

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

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

приемник ввести себя определенным образом. И вот этот самый пример того, как можно заставить приемник делать так или иначе, это вот в протоколе RS-232, который чаще всего известен как COM-порт, у нас там есть такая штука, как стартовые стоповые биты. И вот вы отправляете самые стартовые стоповые биты, вы даете понимание получателю, соответственно, на что похож ваш сигнал. То есть вы начинаете передавать этот самый сигнал, и получатель в течение некоторого времени еще понимает, что, судя по всему, продолжительность этих битиков будет примерно такой же, как вот эти вот самые стартовые стоповые биты. И у вас время он будет угадывать, когда пришла пора включать и выключать приемник на прием очередного определенного бита. То есть у вас в самом сигнале не кодируются указания на то, когда вы включаете и выключаете сигнал в течение приема большей части данных. Но вот в этих самых отдельных битах, стартовых стоповых, у вас как раз

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

у нас начала работать, вот как раз там эта штука и будет нужна. Так. Если мы с вами будем смотреть на какую-нибудь карту сети, которая у нас будет встречаться на курсе, то у нас будет использоваться следующее обозначение. Когда у нас есть какой-то порт на железке, вот, например, свитч нарисован, и, соответственно, у нас есть порты. Вот это вот обозначение названия самого порта, и вот это вот тоже название самого порта, равно как вот это, вот это. Эти самые названия, они будут не случайны. Соответственно, сначала тут какие-то буковки, а потом какие-то цифры, возможно, через дробь. Вот эти буковки и цифры следует рассматривать следующим образом. До первой дроби на цифках будет писаться название модуля. То есть если мы говорим, что у нас есть, например, порт, который называется fastethernet 0. Вот этот фа — это... Дальше мы находим здесь буковку фа. Вот она фа. Fastethernet. Модуль, который называется fastethernet 0.

Или вот здесь вот, например, g01. g0 — это до первого слэша, до первой дроби. Здесь находим ги. Вот оно, гигабит, ethernet, ну, соответственно, 0. Вот эти вот первые буковки, они кодируют тип модуля. А дальше первая циферка до дроби, она указывает на номер этого самого модуля. Там чаще всего, если вы будете работать с небольшими железками, будет стоять нолик. Ну, то есть модуль, который будет на железке сделан, он, как правило, уже прошит на заводе, на материнскую плату припаян. Оторвать его нельзя. Просверлить новые разъемы в корпусе тоже не можете. Вот поэтому там fastethernet 0.1, или гигабит 0.1 — это вот номер модуля 0, потому что он уже штатно стоит на заводе поставленный. Бывают так называемые модульные железки, то есть вы покупаете отдельно шасси, и отдельно в них накупаете модули. То есть у вас будет там, например, 65-й и 68-й свитч, и вы в этот свитч, в своего рода корзину,

можете поставить линейные карты. И у вас, если вы хотите, можете поставить там 2 линейные карты или 4 линейные карты. И на этих линейных картах будут те порты с таким количеством, которые вам будут нужны. Вам сегодня нужно, чтобы на свитче было там 96 портов, вы покупаете 2 линейные карты по 48. Вам завтра нужно еще 48 портов на этом же самом свитче. Окей, не проблема, вы еще одну линейную карту включаете, и у вас получается, соответственно, еще один модуль. Или, допустим, вам сегодня нужно там 96 портов по гигабиту, а завтра нужно еще, к примеру, 80-гигабитных портов или там 8-40-гигабитных портов. Опять же, не проблема. Идете в магазин, покупаете модуль, в предположении, что у вас есть куда его вставить, и вставляете в свитч, у вас появляются новые порты. Так вот, первая цифра — это как раз номер модуля. Вторая цифра после дроби, если цифр всего 2, то это будет указывать на номер порта в модуле. То есть FA 0.1 — это Fast Ethernet 0 модуль, первый порт.

Что означают буковки FA, GI и прочее? У CISC есть обозначение, как вся вот эта классификация работает. И обозначения будут следующие. Если у нас есть порты, которые могут работать только на скорости 10 мегабит, то есть в стандарте 10 BST, это обозначается как Ethernet. То есть просто Ethernet без каких-либо буквок. Вот она, скорость 10 мегабит в секунду. Либо 10 BST, либо 10 BST, 10 BST, 10 BST, AUI. Вот все вот это вот 10-мегабитное, оно просто обычный Ethernet без каких-либо обозначений дополнительных. Если у нас есть порт, который может работать на 100 мегабитах, то есть он либо просто 100 мегабитный, либо 10 на 100, то он обозначается FA, Fast Ethernet. То есть вот Fast Ethernet — это до 100 мегабит в секунду. Он в каждый конкретный момент времени может работать либо на 100 мегабитах, либо может быть на 10 мегабитах. Но теоретически до 100 мегабит он раскачаться может. Поэтому Fast Ethernet. Гигабит, ну вы уже догадываетесь, да, это гигабитный порт.

Он может быть работает на гигабите, может быть на 100 мегабитах гипотетически. Вот, может быть на 10 мегабитах. Но вот как минимум на гигабит его можно раскачать гипотетически. 10-гигабитные порты на Cisco, iOS железках можно встретить не очень часто, но если вдруг вы его встретите, они будут обозначаться буквами TE, 10 гигабит. Не путайтесь. Туннельный интерфейс будет обозначаться TUN. Ну, про туннели мы сейчас отдельно. Смотрите, какая штука. Вы можете сокращать название вот этих самых интерфейсов. То есть если у вас есть интерфейс FA Ethernet 0.1, то да, вот эта вот буковка FA, это обозначает название, начало названия Fast Ethernet, сокращение. То есть вы можете написать FA, можете написать FA, можете даже просто F написать. Система поймет, что вы имеете в виду, потому что на букву F никакие другие типы интерфейсов, никакие другие модули не начинаются. А вот на букву T начинаются другие типы портов. Вот, например, туннельные интерфейсы, они тоже на букву T начинаются.

Поэтому если вы хотите работать с 10-габитным интерфейсом, то вы обязаны писать TE. Вы не можете сократить его до буквки T. Нумерация модулей может быть сплошная, может каждый конкретный тип модуля идти независимо. То есть, например, гигабитные Fast Ethernet порты на большинстве дешевых свечей, они как раз все будут иметь модуль 0. То есть, это, допустим, взять 3750-й свеч, у него там 24 порта 100-мегабитных и 2 порта гигабитных. То есть, у него будет Fast 0.1, Fast 0.2, Fast 0.3, Fast 0.4 и так далее до Fast 0.24 и потом гигабит 0.1, гигабит 0.2. То есть, они как бы все, получается, на двух модулях. Fast Ethernet 0 и гигабит 0. Если брать модульные свитчи, чисто модульные, там нумерация модулей может идти с первого и второго. В первый модуль поставили 100-мегабитные свитчи, у вас Fast Ethernet 1.0, 1.1, 1.2.

Во второй модуль поставили гигабитные свитчи, гигабит 2.0, 2.1, 2.2 и так далее. Иногда можно будет встретить тройную нумерацию, примерно такую. Если мы говорим про свитчи, первая цифра будет обозначать номер свитча в стеке, вторая цифра – номер модуля, и третья цифра – это номер порта на модуле. Если на роутерах, например, serial-линки, они на свитчах не встречаются, они только на роутерах, там первая цифра будет обозначать номер большого модуля, вторая – номер маленького модуля, потому что иногда бывают такие модули, которые можно вставить в другие модули, и третья цифра – уже номер порта на маленьком модуле. Особенно не парьтесь, главное, знайте, что у каждого порта есть название, и это название всегда более-менее одинаковое. И поэтому, когда вы видите, что у вас что-то называется Fast Ethernet 0/2, это явно второй порт на каком-то модуле. Если у вас свитч не модульный, там сразу всё понятно, про что идёт речь.

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

Как по факту путь данных будет идти, вы заранее не знаете. То, как распространяются электрические сигналы, это видно глазами, кто на кого каким проводом смотрит. А вот как дальше оно будет передаваться, это заранее уже неизвестно. Логическая топология как раз и указывает, кто кому как данные передаёт. И здесь для того, чтобы на карте можно было каким-то образом показать, как это всё будет передаваться, нам нужны какие-то новые обозначения. И логическая топология, как правило, будет определяться структурой IP-адресации. Если мы используем протокол IP, IPv4 в частности, то обозначения на картах у нас будут следующие. Если у нас есть некоторое количество адресов, которые принадлежат к одной и той же сети, например вот эта — это у нас одна и та же сеть, то обозначение того, какая именно эта сеть будет использоваться, примерно вот такое. Мы пишем 192.168.10.0/24. Это и есть та самая сеть, которую мы будем использовать.

При этом рядом с каждым узлом у нас будет писаться что-то подобного рода, там .1, .2, .3. Это означает, что мы будем брать начало от этого адреса и маску от этого адреса. А в самый последний октет, в нашем случае, тот, который у самой сети был нулевой, мы будем записывать .1, .2, .3, то есть это адрес 192.168.1.1, 192.168.1.2, 192.168.1.3, а вот здесь это .1, .2, .254. По аналогии тут тоже видно, 198.51.100.1, 198.51.100.2. Оба по 30-й маске. Это просто для того, чтобы вы понимали, как у нас будут использоваться обозначения, если вдруг вы этого никогда не видели. Я думаю, что с этим, скорее всего, так или иначе сталкивались все, а если даже не сталкивались, то здесь всё достаточно понятно. Так, когда у нас несколько узлов хотят вести взаимодействие друг с другом,

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

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

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

с разной аппаратной частью, выполненных разными производителями, всё разное. Но при этом у нас есть какие-то договорённости, как всё это дело работает. И эти договорённости как раз нам позволяют, несмотря на то, что у нас всё разное, аппаратная часть разная, программная часть разная, тем не менее вести одинаковое и согласованное взаимодействие, потому что задачи, которые мы решаем при сетевом взаимодействии, решаются стандартным образом. Сейчас я произнёс очень важное слово «стандарт». Постарался раньше его избегать, но сейчас оно прозвучало. У нас должны быть какие-то стандартные способы решения этих самых задач. Эти самые стандарты на самом деле были не всегда. И если немножко отмотать в историю назад, примерно лет на 50 назад, то компьютеры, которые были 50 лет назад, были устроены совершенно не так, как сегодня. Вообще компьютерная эра началась, как вы помните, достаточно недавно,

49-й год, короче, конец 40-х годов. Это первые компьютеры, которые занимали целые здания, которые нужны были только для того, чтобы рассчитывать ядерные бомбы. И там особых проблем не было с тем, что они как-то между собой не могли взаимодействовать, потому что этих компьютеров было всего на всю планету полторы штуки. И там не было задачи сделать между ними какое-то стандартное взаимодействие. Один компьютер был у американского министерства обороны, второй был, не знаю, у ЦРУ, третий у кого-нибудь ещё. И между ними, в принципе, не стояла задача взаимодействовать. Но потом, когда компьютеры стали более популярными, и между ними стала уже появляться задача обеспечения взаимодействия, возникла проблема, что эти компьютеры делали разные компании, и эти компании совершенно не были заинтересованы в том, чтобы обеспечить какой-то стандарт, который бы их ущемлял в своих правах. Напротив, они были очень сильно заинтересованы в том, чтобы сделать всё максимально не похоже на других,

чтобы ни в коем случае, если вдруг они продали свой компьютер условному американскому министерству обороны, это министерство обороны не закупило бы компьютеры конкурентов, которые были бы в какой-то степени совместимы с компьютерами, которые продавали они. Поэтому, если была компания условный Hewlett-Packard, или условный Intel, или условный Xerox, или условный IBM, они все делали всё максимально не похоже на других. Более того, они специально делали всё максимально не похоже на других, чтобы обеспечить это взаимодействие было физически невозможно. Чтобы если вы купили компьютер от IBM как министерство обороны, дальше вы продолжали пользоваться и покупать компьютеры от IBM, пусть вдвое, втрое дороже, чем это стоило бы у конкурентов, но тем не менее вы просто физически не могли с них спрыгнуть. Это была как игла, на которую один раз сели, и всё, дальше уже не слезешь. И в какой-то момент американское министерство обороны устало от этого и сказало: «Ребят, всё-таки мы тут тратим государственные деньги, налогоплательщики

как-то не очень хорошо смотрят, когда мы покупаем компьютер, который стоит как подводная лодка. Он столько не должен стоить. Мы всё понимаем, что кушать хочется, и даже мы согласны немножко на это отстегнуть, но всё-таки совесть надо иметь». Поэтому они примерно в конце 60-х годов, спустя 20 лет вакханалии, разработали правила, по которым на своих тендерах они должны закупать оборудование, которое удовлетворяет определённым требованиям. Не совершенно любое железо можно было покупать, не совершенно любой софт можно было покупать, а только удовлетворяющее определённым критериям. В принципе, то, что сегодня мы с вами видим, что в Российской Федерации иногда появляются какие-то законы о том, что надо импортозамещение, о том, что надо покупать только

отечественное железо, причём это отечественное железо должно быть каким-то определённым. Очень похожий тренд был тогда, в конце 60-х годов в Америке, когда производителям компьютеров просто завязывали руки и говорили: «Ребята, вы должны делать такие компьютеры, которые устроят нас. Вы не должны делать такие компьютеры, которые устроят вас как поставщика. Здесь клиент мы, и мы платим деньги. Поэтому делайте такое, чтобы было удобно нам». И в 69-м году появилась так называемая уровневая модель TCP/IP, которая указывала, что если решаются какие-то задачи взаимодействия, то они решаются стандартным образом. Не надо было делать такие способы сетевого взаимодействия между компьютерами, которые были бы нестандартными. Я сейчас это говорю, на самом деле это очень простая идея, что если вы что-то делаете, делайте это стандартным способом, чтобы это можно было сочетать с другими компьютерами, которые были бы совместимы с тем же самым стандартом. И открывайте эти самые стандарты, делайте так, чтобы можно было,

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

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

если вы решаете задачу в одной пачке, то вы не должны будете своим стандартом, который вы собираетесь выпускать, потому что на тот момент самих стандартов ещё не было, их только предстояло придумать. Если вы делаете стандарт, то вы должны будете решать задачу в пределах своей пачки, в пределах того, что вам можно делать. И плюс можно немножко залезть в соседнюю пачку. Если вы делаете, условно говоря, оптический линк, вы можете сказать, что да, в этом оптическом линке перекладывание битиков между разными проводами будет происходить определённым образом. Но вы не должны будете говорить, что поверх этого провода может работать только определённые приложения, которые могут обеспечивать только передачу красных символов по экрану. Такое делать уже нельзя, потому что это задачи из разных пачек, из разных областей. И четыре области, четыре пачки задач было выделено. И модель TCP/IP, она же известна как модель DoD по названию ведомства, которое

её придумало, Department of Defense, в 1969 году появилась и стала достаточно интенсивно влиять на отрасль, потому что производители были вынуждены с выкрученными руками делать такие компьютеры, которые были бы стандартными. И это очень сильно действительно продвинуло развитие компьютерной индустрии. На это дело смотрели европейцы, которые говорили, ух, как клёво американцы придумали. Они придумали стандартные компьютеры. До того момента стандартных компьютеров не было, были только вендорские компьютеры, которые, например, придумала компания IBM — два компьютера, которые можно между собой связать проводом. У них было всё абсолютно своё. Сегодня это сложно представить, но у них была своя операционная система, у других компьютеров такой операционной системы не было, поверх которой были свои приложения. Вы не могли взять и поставить приложение от Xerox на компьютер от Intel. Это всё работало поверх проводов, которые были своими, кастомными. Вы не могли взять и чисто физически провод Xerox воткнуть в компьютер IBM.

Он просто не подходил. А когда придумали эти стандарты, это стало возможно. И, как понятно, это всё заметно снизило цены на оборудование. Это всё заметно повысило качество, потому что теперь вендор был заинтересован в том, чтобы делать качественное железо, качественный софт. Потому что если вдруг вам не нравилось, как заказчику, софт или железо, вы могли взять и купить аналогичный софт или железо конкурентов. Раньше этого не было, а теперь это появилось. И в 70-х годах европейцы сказали, ууу, как охрененно придумали. А давайте мы такое же придумаем, только лучше. И стали думать, что же лучше придумать. И долго думали. Они думали почти 9 лет. И додумались до модели, которая стала называться OSI. Open System Interconnection или базовая эталонная модель взаимодействия открытых систем. На самом деле, настолько хорошо придумали, что Советский Союз эту модель тоже скоммуниздил.

Не так много мы у кого-нибудь что-то коммуниздили в части стандартов. Обычно своё придумывали. Но есть ГОСТ, который называется ГОСТ 7498. Он как раз говорит, что если вы делаете взаимодействие компьютеров, то вы должны следовать этой модели OSI. Вы должны делать всё стандартным образом. И задачи, которые вы решаете, вы должны решать так, как это написано в модели OSI. В европейской модели, которая делалась по образу и подобию американской. Иногда это называется модель OSI, Open System Interconnection. Иногда это называется ISOшная модель по названию организации International Organization for Standardization, или по-французски, если мне не изменяет память. И, соответственно, она придумана была в 1988 году. И задача у неё была ровно та же самая, что и у TCP/IP- шной модели — сделать так, чтобы вендоры, которые

продавали железо европейским государственным заказчикам, в первую очередь военка, чтобы они не делали какие-то свои уникальные вещи. Уникальный провод, поверх которого может работать только уникальная операционная система, поверх которой может только уникальный софт работать. Если вы купили провод, вы к нему покупаете компьютеры, софт, операционки — всё-всё-всё. Модель ISO была лучше, чем TCP/IP, потому что в TCP/IP было придумано 4 пачки задач. Это про физику, про передачу данных между разными проводами, про мультиплексирование потоков и всё остальное. 4 пачки. А в ISOшной модели было придумано 7 пачек. И оно в какой-то степени напоминало TCP/IP модель, но было более детализированным. Пачек было больше, соответственно, задач в каждой конкретной пачке было меньше. Поэтому если вы придумывали какой-то стандарт, вы вынуждены

были этот стандарт делать более компактным. Вы не могли говорить, что мы делаем специальный провод, который может соединять два компьютера, но по этому проводу может бегать только Telnet, причём только Telnet наш фирменный. Вы должны были каким-то образом всё-таки делать провод, по которому можно передавать битики. И, соответственно, придумали 7 пачек задач, 7 уровней. Уровень — это именно пачка задач, которые можно решать стандартным образом. С этой моделью связано очень много интересного. Первое заблуждение, которое с этой моделью будет связано, — что к этой модели относятся протоколы передачи данных. Ничего подобного. Эта модель ISO описана в стандарте ISO/IEC 7498-1. Соответственно, если вдруг вы захотите, вы можете скачать документ, он доступен бесплатно на сайте ISO.org, и пункт 1.18.

Самая первая глава, в которой рассказывается, про что это вообще. Пункт 1.18 говорит о том, что протоколы к этой модели не относятся. Поэтому, если вдруг вы видите вопрос, к какому уровню относятся протоколы, дальше там ICMP или IP или Ethernet — пункт 1.18. Протоколы к уровням не относятся. Возникает вопрос, а что это такое уровни и зачем они нужны? Они про сетевые задачи. Если у нас есть задача передать один битик, то это задача сетевого взаимодействия. Одна из многих задач сетевого взаимодействия. Она может быть решена стандартным образом. Соответственно, эта задача относится к пачке номер — дальше там. Каждая конкретная задача относится к одной из семи пачек, к одному из семи уровней. И, соответственно, если мы говорим, что мы делаем какой-то стандарт, который решает сетевые задачи, мы имеем право залезать в максимум два смежных уровня. Мы можем сказать, мы этим стандартом решаем часть задач одного уровня, часть задач другого уровня.

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

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

У нас есть, возможно, например, толстый коаксиальный провод, в котором 10 абонентов сидит. Нам надо как-то сделать так, чтобы мы нолики-единички в этот провод впихнули, и тот, кто действительно является получателем, но не все остальные, прочитал этот сигнал, а все остальные взяли и зажмурились. Как организовать передачу ноликов-единичек в канале так, чтобы нужный получатель смог в этом общем проводе получить сигнал и понять, что это адресовано именно ему. А все остальные, соответственно, поняли, что это не им адресовано, и, например, зажмурились. Всё, что передаётся в пределах канала, за исключением физики, — это вторая пачка, канальный уровень. Здесь можно решить дополнительные задачи, типа контроль доставки, контроль ошибок, описать какое-то форматирование, сказать, что нолики-единички, которые передаются, передаются не просто так, они передаются в виде упорядоченной последовательности. У этой последовательности есть определённый заголовок, есть определённые какие-то служебные данные. Если вы хотите, это можете всё там описать.

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

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

Например, если у вас есть... Чтобы у вас такое могло быть... У вас есть тот же самый TCP. Вот. Он при попытке подключиться, он сначала устанавливает сессию. Там процедура трехэтапного рукопожатия. Мы про нее будем говорить ближе к концу нашего курса. Но, тем не менее, для того, чтобы TCP-шную сессию поднять, нужно определенные манипуляции провести. Вот эти вот манипуляции, вы пока их не проведете, у вас сессия не поднимется, и вы не сможете передавать данные, не сможете сделать так, чтобы ваши данные были отделены от каких-то других данных, которые передаются в соседних сессиях. Вот эта вот процедура — это установление соединений. Это и есть процедура, которая относится к пачке номер пять, к сессионному уровню. Шестая пачка — это преобразование форматов. Все, что связано с тем, что данные можно хранить или передавать в каком-то соглашенном формате, вот это все связано с этим. Пример. Если помните раньше... Опять же, я очень старый, но это хорошо помню.

Вы, может быть, не настолько старые, поэтому не застали этого. Но есть такая штука, как кодировка веб-страниц. То есть там COE8R, COE8U на Украине, Windows 1251, UTF-8, UTF-16. Вот вы можете хранить веб-страничку, которая кодирует там кириллицу, не кириллицу, что-то разное в разных кодировках. Соответственно, у вас может быть такое, что сервер, который вам отдает эту самую веб-страничку, он ее хранит в одном формате и вам ее он передает. А дальше вам нужно ее воспроизвести на компьютере, и вы должны будете эту самую кодировку каким-то образом воспроизвести. То есть вы должны будете понять, в какой кодировке оно пришло. Но вы не можете на экране воспроизвести эту кодировку, поэтому вы должны ее будете преобразовать. Зачем? Ну, такое может быть. И вот, соответственно, вы понимаете, что данные пришли в одной кодировке, их надо преобразовать и показать в другой кодировке. При этом, чтобы смысл сохранился, но при этом физические битики, которые передавались, они при этом бы изменились. То есть вам передали, допустим, byte 62, там буква B, а вы хотите сказать, что вот byte 62 в вашей кодировке, он не буква B, а для того, чтобы показать букву B, вы должны его преобразовать в byte 78. И вот вы преобразуете и, соответственно, показываете на экран букву B в том виде, в котором она изначально и предполагалась.

Это вот преобразование форматов. То есть, да, вот такая вот простая операция. Если вдруг она вам нужна, то она вот в этой пачке будет. В 78 году, когда эта модель придумывалась, это была очень актуальная проблема. Опять же, именно потому, что все вендоры компьютеров, которые были на тот момент, они все делали все в своем кривом формате. Кривом, косом, у кого-то byte был 40 бит, у кого-то byte был 7 бит, у кого-то byte был 4 бита. То есть у всех у них были какие-то странные наркоманские вещи. Для того, чтобы из одной наркоманская вещи в другую наркоманскую вещь преобразовать данные, вот этот вот стандарт, точнее требование стандартизировать все вот это вот преобразование и появилось. Сегодня мы нагло пользуемся тем, что фактически в индустрии есть Unicode. И фактически все, что мы сейчас делаем, все делается в Unicode. И поэтому нет особой потребности в преобразовании между разными кривыми форматами. Но когда-то давным-давно это было очень актуально. На самом деле, 15 лет назад еще было очень актуально.

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

То есть он, получается, решает задачи трех разных уровней. В нормальной ситуации он вот этого делать не должен, и тогда, если он этого не делает, он прекрасно соответствует требованиям модели OSI. Он решает задачи двух смежных уровней, что имеет полное право делать. Если мы заставляем его решать задачи презентационного уровня, он начинает решать задачи трех разных уровней, и, как следствие, он уже не соответствует требованиям модели OSI. Теоретически систему, которая работала бы с таким TCP, европейские государственные органы не могли бы купить, потому что она не соответствует требованиям их стандарта. Это не означает, что она не будет работать. Она может работать. То есть она прекрасно работает, возможно. Но, соответственно, это делается не по стандарту. Тем не менее, да, вот это вот, конечно, в самом TCP встретить можно было, хотя и можно было, но очень редко. В основном для того, чтобы мочь продавать системы в ГАСУХу, все стремились все-таки соответствовать требованиям модели OSI и делали свои стандарты, свои протоколы в соответствии с этой самой моделью.

Еще один момент заключается в следующем. Задачи, которые мы ставим перед конкретным протоколом, они могут быть разные. Например, у нас есть такой протокол динамической маршрутизации, BGP. Вот этот BGP, он работает поверх TCP, он работает для того, чтобы обеспечить сетевую связность, и, соответственно, он работает, ну, он просто работает. И здесь частый вопрос. Вот, например, вот если у нас есть протокол BGP, какие уровни модели OSI будут относиться к его задачам? Во-первых, если у нас он обеспечивает задачу динамической маршрутизации, безусловно, эта задача будет относиться к третьему уровню. Как нам передавать данные между разными проводами, между разными роутерами? Соответственно, это будет задача третьего уровня. То, что он поверх TCP работает, никоим образом для нас неинтересно, потому что то, поверх какого протокола, во что инкапсулируется, никоим образом на задачи сами не влияет.

Но то, что этот BGP сам по себе работает, иногда приводит нас к любопытному казусу, что иногда бывает такое, что мы этот BGP запускаем для того, чтобы у нас, условно говоря, интернет работает. И у нас тогда эта задача сетевого уровня. А иногда мы его запускаем не для того, чтобы у нас интернет работал, а для того, чтобы чисто на него позырить. И вы не поверите, это реально есть такие вещи. То есть, есть такое явление среди сетевых инженеров, которое называется BGP Looking Glass. Я вам сейчас даже покажу. У меня оно есть. Так. Вот, например, это роуд-сервер Looking Glass провайдера Swisscom, швейцарского провайдера. Это настоящий живой роудер. То есть, я могу к нему подключиться. Вы тоже к нему можете подключиться. Вот у него название роуд-сервер, точка IP+, точка нет, обычный Тилнет. Вот. На этом роутере запущен протокол BGP.

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

BGP никакую задачу сетевого уровня здесь не решает. Поэтому, если мы запускаем его для того, чтобы он обеспечивал межсетевое взаимодействие, это задача третьего уровня. Если мы его запускаем чисто для того, чтобы на него посмотреть, это задача седьмого уровня. И поэтому один и тот же протокол, одно и то же все, то есть он с точки зрения того, как он устроен, ничего не меняется. Меняется только наше отношение к нему. Если мы говорим, что это задача для того, чтобы обеспечить межсетевое взаимодействие, задача третьего уровня. Если это задача для того, чтобы на него можно было позарить, задача седьмого уровня. Все вот так просто. Так что конкретный протокол к модели OSI отношения иметь не обязан. Пункт 1.18 стандарта ISO 7498 говорит нам об этом в явном виде. Протоколы к уровням не относятся. Если вам очень сильно хочется, вы можете декомпозировать задачи, которые решают конкретный протокол, конкретный стандарт. Вот возьмете одну конкретную маленькую задачу,

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

Типа того, что эта модель устарела, и сейчас есть новые протоколы, которые не соответствуют этой самой модели. И вот эти самые протоколы соответствуют уровню, там, не знаю, 2,5. Честное слово, есть серьезные люди, которые вот с умным видом заявляют вот такие вот вещи. Абсолютно полностью херня на постном масле. Именно потому, что, а, протоколы к уровням не относятся, и Б, потому что вот эти вот самые шесть пачек, они закрывают вообще все, все, все, что бывает в мире. Ровно за счет того, что есть вот эта вот седьмая пачка, все остальное. То есть если оно в явном виде не попадает в пачку номер один, в пачку номер два, в пачку номер три, в пачку номер четыре, в пачку номер пять, в пачку номер шесть, оно точно попадает в пачку все остальное, в пачку номер семь. Поэтому пачек сетевых задач ровно семь штук. Не больше, не меньше. И каждая конкретная маленькая сетевая задача относится к одной из этих семи пачек. Поэтому уровня 2,5 не существует. Нет такой пачки 2,5. Есть либо пачка номер 2, это пачка канальная, про то, как порядочные последовательности с битиков складываются

и передаются в пределах провода. Либо пачка номер 3, как данные передаются между проводами. Но нет пачки уровня 2,5, которая бы что-то посередине между ними делала. Вот их 7 пачек, и все, больше ничего нет. Вот. Соответственно, если вдруг вы видите какой-то современный протокол, он все равно эти задачи так или иначе решает. И можно сказать, что у нас есть конкретный протокол, который решает вот эти вот самые задачи. И мы можем эти задачи расписать, каждую из отдельных задач расписать по вот этим вот 7 пачкам. Да, физика. Это про передачу сигнала в пределах одного провода. Конечный результат работы физического уровня — это отдельные битики. Канальный уровень. Это про то, как у нас в пределах, опять же, одного провода, после того, как мы договорились о том, как передаются отдельные нолики-единички, сформировать упорядочную последовательность из этих самых ноликов и единичек. Потому что некоторые нолики-единички будут служебными,

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

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

Программистам эти задачи интересны, сетевикам эти задачи неинтересны. Поэтому часто все, что происходит на вот этих вот высших трех уровнях, пятом, шестом и седьмом, называют одним большим таким мега-уровнем. Уровнем 7, уровнем приложения, да, L7. Да, кстати, если вдруг вы видите нумерацию уровней где-нибудь, когда-нибудь, то эта нумерация всегда идет по модели OSI, не по модели Dota. То есть, второй уровень – это значит, что второй уровень модели OSI. Первый уровень – значит, первый уровень модели OSI – это не про модель Dota. Если мы говорим про модель Dota или модель TCPIP, у нее четыре уровня. Они были очень простые. Первый – про передачу данных в одном проводе. Второй уровень – про передачу данных между проводами. Третий – про мультиплексирование потоков. Четвертый – все остальное. То есть, четыре уровня, три из них явно заданные, четвертый – все остальное. Модель ISO – это семь уровней. Шесть уровней явно заданных и седьмой – все остальное. Можно будет с некоторой натяжки сказать, что при создании своей модели

европейцы взяли первый уровень, который называется канальный уровень, и, соответственно, распилили его на две части. Здесь у нас про нолики и единички. Соответственно, здесь у нас про составление упорядоченных последовательностей из этих ноликов и единичек. Примерно здесь соответствие имеется. Тот уровень, который называется сетевым уровнем модели OSI, он называется уровнем интернет в модели Американского Министерства обороны. И здесь есть очень четкая проблема с тем, что в современном мире слово интернет имеет очень определенное значение. Это та самая всемирная сеть, через которую мы сегодня все работаем. Модель DOT появилась в 1969 году. Интернет появился в конце 80-х. А в том виде, в котором мы его знаем, это Тим Бернерс-Ли в 1991 году придумал первый браузер. Сеть интернет называется так по названию уровня межсетевого взаимодействия, по названию уровня интернет в модели DOT.

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

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

Пункт 1.18 нам это дело запрещает, но тем не менее нам плевать, потому что так все привыкли. И поэтому мы говорим, что TCP — это протокол транспортного уровня, а транспортный уровень — это четвертый уровень, пачка номер 4, поэтому мы говорим, что TCP — это протокол четвертого уровня. Это утверждение неверное. TCP не относится к транспортному уровню, потому что TCP решает сразу пачку задач. Но всем насрать, простите мой французский, потому что в индустрии так принято, что TCP — это транспортный протокол. Равным образом у нас есть протокол IP, который тоже решает целую пачку задач. Они тоже могут относиться к разным уровням, но большая часть задач, которые решаются протоколом IP — это задачи межсетевого взаимодействия, перекладывания данных между проводами. И поэтому IP принято называть сетевым протоколом, и поскольку сетевой уровень — это третий уровень, IP называют протоколом третьего уровня. Опять же, это неверное утверждение — протокол к уровням не относится.

Но в какой-то момент кто-то предложил: давайте закроем глаза на то, что, во-первых, это нельзя делать, а во-вторых, это неправда, и сделаем вид, что это правда и что так делать можно. И с тех пор так и повелось, что все называют протокол IP протоколом третьего уровня. И то же самое, например, с уровнем Link Layer. Например, у нас есть протокол Ethernet. У него сразу много чего делается. У него и задачи первого уровня решаются, и задачи второго уровня решаются. Забегая немножко вперед, там немножко третьего уровня тоже решается. Но, опять же, всем насрать, опять же, простите мой французский, поэтому все сказали: давайте мы будем считать, что это протокол второго уровня, потому что можем. Ничего страшного, на пункт 1.18 закроем глаза, ничего страшного, что там и первый, и второй, и третий уровень тоже есть. Мы будем считать, что это протокол второго уровня. И как только это стало допустимо и окно Овертона схлопнулось, эта картинка стала иметь смысл. Но эта картинка — вранье с первого до последнего символа, потому что Ethernet — это не протокол второго уровня, IP — это не протокол третьего уровня, TCP — это не протокол четвертого уровня.

Но как только вы начинаете считать их такими, у вас получается следующее. Есть какой-то кусочек данных, который ваше приложение хочет отправить. Дальше. Приложение отправляет кусочек данных, он оборачивается заголовком транспортного уровня, например TCP. В этот момент мы хитро подмигиваем друг другу, говорим: это же неправда, но ладно, окей, зажмуриваемся. Дальше. Этот кусочек данных — заголовок TCP плюс данные — оборачивается дополнительно заголовком третьего уровня. Здесь мы опять же друг другу подмигиваем, говорим: ребят, мы понимаем, что IP — это не третий уровень. IP — это и третий, и четвертый, и там еще немножко разных других уровней, но ладно. И полученный кусочек данных опять же оборачивается заголовком L2. И тут, поскольку все договорились под L2 считать Ethernet, возникает немножко неприятная ситуация, потому что у Ethernet есть не только заголовок, но и трейлер. И поэтому здесь появляется такой уродливый хвостик FCS.

Но поскольку всем, опять же, все равно, получается вот такая картинка. И дальше полученный кусочек данных разбивается на отдельные битики и отправляется по сети. Отдельно одаренные граждане иногда бывают еще дорисовывают заголовок первого уровня. Здесь появляется такая штука L1. Мне всегда смешно смотреть на это, потому что да, в Ethernet есть действительно кадр, который имеет заголовок, имеет payload, в этом payload может лежать IP, а в IP может лежать TCP, а в TCP может быть даже конечное приложение. Но что такое заголовок физического уровня? Потому что на физическом уровне у нас биты. И когда у нас есть кадр Ethernet, он не оборачивается ничем, чтобы получить отдельный бит. Он разделяется на отдельные части, и все, больше ничего не происходит. Но, честное слово, бывают даже отдельные очень уважаемые учебные заведения, которые выпускают литературу, и там такое появляется. Так вот, эта картинка обозначает, что протоколы бывают вкладываются друг в друга. У нас бывает кусочек данных, который оборачивается одним протоколом,

потом другим, потом третьим, и все это дальше по сети будет бежать. Не обращайте внимания, пожалуйста, на эти символы. Если даже обращаете внимание, не воспринимайте их всерьез. Это не обозначение уровней модели OSI. Это традиционные, принятые в отрасли обозначения конкретных протоколов. Если вы видите L4, не пытайтесь это проассоциировать с транспортным уровнем модели OSI. Читайте это как TCP-хедер. Если вы видите L3-хедер, не пытайтесь проассоциировать это с третьим уровнем модели OSI. Читайте это как IP-хедер. Если вы видите L2-хедер, не пытайтесь проассоциировать это с канальным уровнем модели OSI. Читайте это как Ethernet-хедер. И тогда эта картинка имеет смысл. Почему это нельзя читать напрямую? Потому что вы можете взять и, например, IP вложить в еще один IP-пакет. У вас будет два IP-заголовка подряд. Это допустимо, это разрешено. Соответственно, у вас такое может быть.

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

Если мы говорим про конкретные протоколы, опять же, не воспринимайте всерьез эти обозначения L1, L2, L3. Говорим про конкретные протоколы. Когда мы говорим про L2, допустим, мы имеем в виду Ethernet. Про L3 мы говорим IP. Про L4 — TCP. Про L7 — просто какое-то приложение. Мы говорим про то, что эти протоколы обмениваются какими-то кусками данных. И если мы говорим просто про приложение, то приложение обменивается просто данными. Data. Если мы говорим про протоколы, которые в отрасли традиционно неправильно называют транспортными, то есть TCP и UDP, то они обмениваются датаграммами. Иногда у TCP еще есть термин сегмент. Но сегмент — это чуть другое. У протоколов, которые в отрасли неправильно называются L3, то есть в первую очередь IP, есть термин пакет. Когда IP передает данные с одного узла на другой,

он обменивается именно пакетами. И L2 — это, соответственно, протоколы, которые в отрасли традиционно неправильно называются канальными. Это, например, Ethernet. Эти протоколы обмениваются кадрами. Если мы кадры делим на части, то у нас получаются отдельные биты. Так, эти кусочки данных, которые можно передавать на разных уровнях, у них есть специальное название — PDU — Protocol Data Unit. Это специальный термин, который обозначает кусочек данных, который имеет свое собственное специальное название в зависимости от того, какой конкретно протокол его оперирует. PDU для TCP и UDP будет датаграмма, PDU для L3 будет пакет, PDU для L2 будет кадр. Так, мы молодцы. Мы сегодня прошли много-много всякой теории. Если вдруг вам было интересно, я очень рад. Если вдруг вам было неинтересно, жизнь — боль. Не забывайте страдать.

Тогда давайте встретимся завтра в 6 часов по Москве. А на сегодня все. Спасибо за внимание. Пока-пока.