Последовательный порт

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

Последовательный порт хорош тем, что он просто передаёт битики. Он засовывает битики в провод, и с другой стороны эти битики высовываются. Дальше, как мы эти битики будем составлять в кадры — это уже задача канального уровня. Если говорить про тот последовательный порт, который в рамках нашего курса есть, то это будет классический образцово-показательный механизм первого уровня модели OSI. Он будет как раз говорить о том, как будут передаваться отдельные битики. С точки зрения, например, циски, которая будет поддерживать такой serial link, у неё будет некий разъём. Разъём будет зависеть от конкретного стандарта, который мы будем использовать, потому что последовательный порт бывает разных типов. Он в любом случае будет передавать отдельные нолики-единички, и он будет их передавать последовательно один за другим. Но тем не менее он может это делать на разной скорости, может это делать с использованием разных коннекторов.

И поэтому разъёмы на циске могут быть разные. Здесь приведены примеры четырёх наиболее популярных типов интерфейсов. Это всё serial link, но они немножко различаются между собой. Этот serial link можно было встретить, на самом деле, часто и в обычных компьютерах, если вдруг вы это застали. Это, по сути, свой COM-порт. И там мог передаваться RS-232. У RS-232 есть ограничение по скорости. Он больше, чем до 115200 раскачивается крайне редко. Он, в принципе, может работать на любой скорости. Но в силу того, что сами провода обычно не предназначены для передачи большого количества данных на большое расстояние, на характерных для обычных компьютеров двух-трёх метрах передачи скорость RS-232 могла подниматься до этой цифры. 115200 бит в секунду. Если вдруг вы не застали такие разъёмы, то этот разъём, который здесь конкретно нарисован, называется DB25.

D означает, что форма этой штуки была похожа на букву D, какая-то трапециевидная. Буква D — она вот такая. Соответственно, здесь есть некое сходство между разъёмом DB и буквой D. Трапециевидность заключалась в том, что у этого разъёма было нечётное количество штырьков, и эти штырьки выстраивались в две группы. В верхний ряд получалось 12 штырьков и нижний ряд 13 штырьков. Общее количество штырьков получалось 25, поэтому 25. И если вдруг вы хотели связать между собой две железки таким проводом, вы брали провод, с одной стороны втыкали в циску, с другой стороны втыкали в циску, и у вас получался провод, на котором можно было передавать до 115200 бит в секунду. Если не DB25, то альтернативный вариант был такой разъём.

Это называется просто обычный serial link, соответственно, DB60 разъём. Хорошо видно, что цифра здесь уже не 25, а 60, поэтому штырьков тут намного больше. Визуально этот разъём очень похож на разъём DVI. Если вы на видеокарту современную посмотрите, DVI по размеру, по количеству штырьков примерно совпадает с этим самым DB60. Не путайте, это разные, абсолютно не связанные между собой разъёмы, но они похожи. Человеку, который никогда не видел оригинальный DB60, надо как-то объяснить, на что это было похоже. Это было похоже на DVI. И был разъём, который назывался Smart Serial. Smart Serial. Это по сути своей тот же самый DB60, но он более компактный. И опять же, если его с чем-то сравнить, он немножко был похож на HDMI, если говорить про аналогию в современном мире. Он примерно по размеру был таким же. Как понятно, DVI и HDMI разъёмы, в принципе, по большому счёту похожи по назначению,

но DVI побольше, а HDMI поменьше. Равным образом и Smart Serial тоже был банально поменьше. Поэтому на том модуле, который мог нести на себе только один DB60 разъём, в силу того, что DB60 банально большой, Smart Serial получалось две штуки. На циске примерно такого размера была платка, куда можно было подключать различные модули. И либо на эту платку получалась такая мандула DB60, либо два модуля Smart Serial на неё можно было поставить. И портов Smart Serial на ту же самую площадь, на единицу площади, можно было сделать в два раза больше. Поэтому, начиная где-то с 2000 года, DB60 циско перестаёт делать практически, и все serial link она делает на Smart Serial. Альтернатива этим портам была ещё такая штука. Это называется колодка V.35, стандартная колодка.

Если сравнить её с чем-то, с чем вы могли сталкиваться, не знаю, это не HDMI, не DVI — не знаю, сигаретная пачка. Она большая, такая дура. Если размахнуться, можно было человека убить, как моргенштерном. Да, она действительно большая. Как правило, провода у вас были разные с разных сторон, за исключением DB25, которые с обеих сторон были, как правило, одинаковые. Чаще всего, если мы говорим про обычные назначения serial link, у нас с одной стороны был либо DB60 разъём, либо Smart Serial, а с другой стороны как раз эта большая бандура V.35. V.35 колодка втыкалась в провайдерскую железку, а DB60 или Smart Serial — в, условно говоря, нашу циску, которая Customer Premises Equipment. Это не все стандарты, не все варианты разъёмов, которые можно было встретить. Этих стандартов и разъёмов было намного больше.

Наиболее классические, наиболее часто используемые — вот эти. Если вы захотите, вы можете взять, найти разъём, найти провод, который будет иметь с одной стороны Smart Serial, с другой DB60 или два DB60 с разных сторон. Но есть нюанс. Чаще всего эти самые провода будут не одинаковы с разных сторон. Они будут разные, и разные они будут именно вот в чём. Так же, как в Ethernet, если мы вспомним, как устроен Ethernet, у нас Ethernet на свитче, например, и на обычном компьютере не одинаковый. Даже если мы возьмём обычный наш не RJ45, а 8P8C порт на свитче, этот порт будет на первом и втором контактах иметь приёмник, а на третьем и шестом контактах он будет иметь передатчик, если мы говорим про 10 и 100 мегабит Ethernet. В то же время на компьютере у нас всё наоборот. Первый и второй порт — это передатчик, а третий и шестой порт — это приёмник.

Соответственно, электрически на свитче, и на хабе тоже, и на обычном компьютере Ethernet, хотя визуально похож, он всё-таки разный. Так вот, та же самая история была и с этим самым serial link. Там должен был быть узел, который задаёт частоту, на которой работает serial link. И если в Ethernet у нас этой концепции нет, то в serial link она была. У нас из двух узлов, которые соединяются между собой общим электрическим проводом, один узел должен был быть ведущим, а второй — ведомым. И ведущий узел, как правило, позволял к себе подключаться по V.35, а ведомый узел позволял к себе подключаться, как правило, с помощью разъёмов DB60 или Smart Serial. И ведущий узел, который задаёт тактовку, задаёт частоту, назывался DTE — Data Terminal Equipment. И узел, который принимает эту частоту и соглашается на ней работать,

называется DCE. Data Circuit Terminating Equipment. Если что-то не получается, Google нас спасает. DTE — это Data Terminal Equipment, а DCE — это Data Circuit Terminating Equipment. Circuit в том смысле, что если у нас есть некая провайдерская линия, которая тянется от провайдера до нас, там дальше ставится это самое CSU/DSU, и она позволяет к себе подключиться V.35 колодкой, этой большой, и она будет DCE.

Она будет ведущей частью serial link, и всё это дело будет подключаться к кастомерскому роутеру, который будет, соответственно, ведомым. Он будет DTE. Так вот, канал передачи данных — данные передаются по всему проводу. И DCE означает, что в этом порту терминируется канал, который предоставляет вам провайдер. Поэтому DCE — это Data Circuit Terminating Equipment. А DTE — это Data Terminal Equipment, это линк, который терминирует на себе хитрую физику провайдера. Хитрая физика заканчивается вот здесь, и на этой самой хитрой физике сигнал передаётся таким способом, который кастомеру знать вообще не надо. Далее. DCE задаёт частоту, DTE эту частоту принимает

и работает на этой самой частоте. Если говорить про то, что внутри этого самого serial link можно было передавать, можно было передавать данные на любой скорости. Вы могли взять и передавать данные хоть на 1,5 мегабитах, хоть на 2 мегабитах, хоть на 7 мегабитах, но чаще всего данные передавались на некой стандартной скорости, и стандартные скорости, как правило, были кратны 64 кбит в секунду. Эти 64 кбит в секунду — это была очень характерная цифра, потому что если вы хотели использовать цифровую телефонию, не аналоговую телефонию, где под вас коммутируется электрическая цепь, и не Voice over IP, где данные передаются в виде отдельных IP-пакетиков, а именно цифровую телефонию, когда телефонные аппараты подключаются с использованием именно отдельных битиков друг к другу, и в этих битиках передаются голосовые сообщения, побитово, то 64 кбита требовалось для того,

чтобы передавать голос в несжатом виде. Если мы использовали обычный телефонный вызов, то нам нужно было под него 64 кбита. И эта цифра 64 кбита называлась специальным термином DS0. Это как бы единица измерения скорости, которую использовали телефонисты. Можно было сказать, что нам достаточно одного вызова в канале, и тогда скорость этого канала 64 кбита. Либо нужно будет два вызова одновременно поддерживать, тогда мы скажем, что у нас будет 2 DS0, либо 4 вызова, тогда 4 DS0 и так далее. За счёт того, что мы могли использовать разделение канала по времени, у нас была, например, какая-то железочка, и у неё один телефонный аппарат. Сейчас я попробую нарисовать его. Вот телефонный аппарат. Как мог, так и нарисовал. И другой телефонный аппарат.

Оба телефонных аппарата посылали битовые потоки. 1, 0, 1, 1, 0 и так далее. И здесь тоже 1, 0, 1, 1, 0. Эти два телефонных вызова можно было смешать между собой и дальше выплюнуть в среду передачи данных, которая имеет скорость 2 по DS0. И работает это следующим образом. Выбрали сначала один битик, передали в сеть, потом другой битик от другого абонента и тоже передали его в сеть. Потом снова следующий битик от одного абонента, следующий битик от другого абонента. И вот так поочерёдно вы берёте сначала от одного, потом от другого, потом от одного, потом от другого. Точно так же можно взять и сказать: давайте 4 абонента подключим, и мы берём сначала первый, потом второй, потом третий, потом четвёртый. Снова первый, второй, третий, четвёртый. И мультиплексирование нескольких потоков осуществляется очень просто. Здесь не нужно быть каким-то умным свитчом для того, чтобы коммутировать много разных портов в сторону одного-единственного. Логика, которая позволит нам побитово перебирать много разных интерфейсов

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

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

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

и здесь атомные часы будут работать. И тогда расхождение во времени между двумя участниками никогда не будет слишком большим, и оба участника смогут понять, как именно надо разделить приходящий трафик на отдельные субканалы для того, чтобы они не перепутались между собой. Возникает еще один вопрос. Сколько именно каналов можно соединять между собой, пока это еще имеет смысл, пока нам не нужны эти самые атомные часы, и кто конкретно собирает каналы в пачки. Американцы пошли своим путем, и стандартные способы мультиплексирования каналов у американцев будут иметь название T-carrier. Соответственно, T1 канал — это 24 вызова по DS0. Соответственно, 24 умножить на 64 килобита — это полтора мегабита, 1536 килобит в секунду. Там еще один из этих каналов будет выделяться под синхронизацию. Есть еще канал, который будет называться T3. Это 28 раз по DS1.

Соответственно, скорость такого канала будет 45 мегабит. У европейцев было как-то больше разума. Они говорили, какая-то странная цифра — 24 вызова, 28 композитных вызовов. Что за цифры такие странные? Вы, американцы, говорили европейцы, очень странные люди, вы меряете объемы в галлонах, вы меряете длину в футах, ярдах, и черти пойми в чем, в милях. Расход бензина у вас вообще в милях на галлон. Или галлон на милю. Как-то кривые вы люди. Поэтому давайте использовать степени двойки, сказали европейцы. Мы возьмем эти звонки DS0 и скажем, что если их мультиплексируем между собой, то мы берем 32 вызова и складываем их в одну пачку. Эта пачка будет называться E1. Поэтому на самом деле там 30 вызовов плюс 2 служебных канала под синхронизацию. Соответственно, 30 каналов по 64 килобита дают нам скорость 2048 килобит в секунду.

Если мы хотим связать между собой несколько этих самых двухмегабитных каналов, мы берем 16 штук и объединяем в пачку, которая будет называться E3. И у нас получается эффективная полоса пропускания за минусом расходов на синхронизацию 34 мегабита в секунду. Стандартные европейские скорости немножко другие. В принципе, вы можете сказать, а мы пойдем вообще своим путем. Мы будем не американцами, не европейцами, а нацистами с Марса. И мы возьмем и скажем, давайте соединять по 7 DS0. И у нас будут скорости, M1 — это 7 маленьких вызовов. И M3 — это 5 умножить на 7 DS0. Когда мы берем 5 каналов M1 и складываем в канал M3. Пожалуйста. Никто вам не запрещает такие штуки делать. Просто оборудование, которое будет поддерживать такую схему мультиплексирования, будет довольно тяжело найти.

Начиная с определенных скоростей, больше, чем T3 обычно не мультиплексируют. Не берут, не собирают T3 в пачки T4 или T5. Просто потому, что уже начинает быть необходима та самая синхронизация времени. И если мы говорим про скорости, которые будут превышать порядка 52 мегабита в секунду, всё, что больше, чем 52 мегабита, это, как правило, уже требует атомные часы. И эта скорость 52 мегабита, она довольно характерная. Она будет являться единицей измерения скорости для SDH, для протоколов связи, которые используют как раз синхронизацию времени. Если мы берем эту скорость 52 мегабита и объединяем несколько таких каналов в пачки, то мы получаем, допустим, берем три канала, получаем пачку 155 мегабит в секунду.

Она же будет называться... 52 мегабита — это STM0. Стандартная скорость для синхронных цифровых иерархий. Если мы берем STM1 и соединяем таких каналов 4 в пачку, то мы получаем каналы STM4. Это сколько получается? 640 мегабит в секунду. Если мы берем 16 STM1, соответственно, 155 мегабит умножить на 16. Если мы берем STM64, соответственно, 155 мегабит умножить на 64. Можно взять и представить канал, допустим, STM256. Это 256 каналов по STM1 по 155 мегабит в секунду. Если взять и пересчитать, 155 умножить на 256, это сколько бит в секунду по факту получится. Получится примерно такая цифра, 38 гигабит. Порядка 40 гигабит. Именно поэтому, если посмотреть на современные эзернеты, мы увидим, что есть стандартная скорость эзернета

10 мегабит в секунду, 100 мегабит в секунду, и в промежуточке там еще какой-то закрался 40 мегабит в секунду. Откуда он взялся, этот самый 40? Это как раз стандарт эзернета, который имеет скорость, сравнимую с STM256. Если вам кажется, что эта штука какая-то странная и мало где используемая с STM256, то это, например, кабель, трансатлантический кабель, который в 2014 году был сдан в эксплуатацию между Европой и Америкой, он как раз имел тип связи с STM256. Там использовалось 4 пары волокон, в каждом волокне по 16 длин волны. Уплотнение на основе длин волны, WDM. И, соответственно, каждый вейвленгс имел 38 гигабит пропускную полосу. Несложно посчитать, что если бы все эти самые длины волн, все пары жил были бы задействованы, то производительность такого кабеля была бы сильно большой. Обычно, когда прокладывают кабели,

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