Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей, напомню, что эти записи основаны на программе Cisco ICND1 и помогут вам подготовиться к экзаменам CCENT/CCNA. Эта запись является логическим продолжением предыдущей и мы все ближе подбираемся к моделям передачи данных, которых на самом деле очень много, но мы рассмотрим только две: эталонную модель сетевого взаимодействия или просто OSI 7 и модель стека протоколов TCP/IP. Данная запись поможет нам разобраться с вопросом: как и на основе каких критериев разрабатываются уровни любой модели передачи данных.

А когда мы с этим разберемся, мы более детально поговорим о том, что такое протокол, служба и примитив, при помощи чего два узла взаимодействуют на одном уровне модели передачи данных, а также каким образом уровни модели передачи данных взаимодействуют друг с другом. Данная запись сейчас может оказаться не совсем понятной (особенно раздел про службы с установлением и без установления соединения), так как в ней не будет реальных примеров, поэтому рекомендую к ней вернуться после того, как мы разберемся с протоколами транспортного уровня (TCP и UDP), тогда все встанет на свои места.

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

1.13.1 Введение

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

Всё это нам поможет при обсуждении двух самых популярных моделей передачи данных: эталонная модель сетевого взаимодействия и модель стека протоколов TCP/IP.

1.13.2 Как разрабатываются уровни модели передачи данных

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

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

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

На верхних же уровнях модели передачи данных механизм обеспечения целостности данных может не только обнаруживать ошибки, но и проверять правильность последовательности получения данных и их целостность. Но есть еще и третье понимание надежности передачи данных – это поиск рабочего и максимально эффективного пути (как в плане коммерческой, так и в плане технической стоимости) из пункта А в пункт Б, этот механизм реализуется на сетевом уровне при помощи протоколов динамической маршрутизации, таких как OSPF, RIP (уже устарел и практически нигде не используется), EIGRP, BGP, IS-IS.

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

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

1.13.3 Службы на основе соединений и службы без установления соединений

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

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

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

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

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

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

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

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

Кстати говоря, на транспортном уровне, передаваемые данные по протоколу UDP, называются дейтаграммами или датаграммами, а в протоколе TCP передаваемые фрагменты данных называются сегментами. Еще стоит отметить, что устройства, отвечающие за передачу данных по сети, делятся на два больших типа в зависимости от того, как они передают данные:

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

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

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

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

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

Если говорить про надежные службы, то есть те службы, для передачи данных которым требуется установление соединения, то тут можно выделить два вида:

  1. Службы, которые работают с последовательностью сообщений, такие службы разбивают данные на фрагменты или сообщения, у которых есть четкие границы. Если служба настроена так, что сообщения представляют собой фрагменты размером 3 Кбайт, то принимающей стороне может прийти два сообщения размером 3 Кбайт, но никак не одно сообщение, размер которого 6 Кбайт.
  2. Второй вид службы работает с данными как с потоком байт, в этом случае данные не делятся на сообщения. В этом случае получатель, имея на входя последовательность 1028 байт, никогда не сможет понять: одно ли это сообщение длиной 1028 байт или это четыре сообщения по 256 байт.

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

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

Большая часть компьютерных сетей на канальном и сетевом уровнях модели передачи данных использует протоколы, не требующие установления соединения, на сетевом уровне это протокол IP, а на канальном — Ethernet, а вот на транспортном уровне уже идет разделение в зависимости от типа трафика, который передается по сети: если важна точность и надежность (в случае передачи текстовых данных и файлов), то используется протокол TCP, если же более критичным является скорость передачи данных и отсутствие задержек, то используется протокол UDP, ранее мы уже об этом говорили, когда разбирались с видами сетевого взаимодействия.

1.13.4 Примитивы служб или системные вызовы

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

Если вы знакомы с понятием системного вызова, то понять, что такое примитив, вам будет проще, ведь системный вызов по своей сути и есть примитив. Давайте представим себе схему, в которой взаимодействую два устройства (мы уже собирали подобную схему в Cisco Packet Tracer, когда смотрели на пример взаимодействия двух ПК, но тогда мы не давали машинам роли, для нас они были равнозначными): клиент и сервер, общаются клиент и сервер при помощи службы с установлением соединения. Давайте представим: какие примитивы в такой схеме может выполнять клиент, а какие сервер?

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

Также мы упоминали, что сервер, если он не занят запросами клиента, ждет и слушает: а вдруг прилетит запрос, который нужно обработать, для такого действия есть свой примитив, который называется LISTEN. А когда сервер получает от клиента запрос на соединение, он должен подтвердить клиенту, что готов с ним это соединение установить, для этого у него есть примитив ACCEPT: когда сервер получает от клиента запрос на соединение, он посылает клиенту специальный ответ, в котором сообщает, что готов установить соединение, с этого момента можно начинать передавать полезные данные.

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

Взаимодействие между клиентом и сервером, а также системные вызовы (примитивы), которые они выполняют показано на Рисунке 1.13.1.

Рисунок 1.13.1 Клиент и сервер обмениваются сообщениями, выполняя системные вызовы (примитивы)

Рисунок 1.13.1 Клиент и сервер обмениваются сообщениями, выполняя системные вызовы (примитивы)

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

1.13.5 Как работают службы и протоколы

Службы и протоколы на самом деле различные понятия, хотя дальше мы познакомимся с моделями OSI 7 и TCP/IP и узнаем, что первая модель проводит четкую границу между двумя этими понятиями, у второй модели четких границ нет, в настоящий момент большинство компьютерных сетей работает на протоколах модели TCP/IP. Служба или сервис – это набор простейших операций, при помощи которых более низкий уровень предоставляет услуги более высокому уровню. Протокол – это набор правил, которые описывает формат и назначение каждого сообщения, которыми обмениваются устройства на одном уровне модели передачи данных.

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

Рисунок 1.13.2 Модель, демонстрирующая разницу между службами и протоколами

Рисунок 1.13.2 Модель, демонстрирующая разницу между службами и протоколами

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

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

1.13.6 Выводы

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

Следующие две публикации будут уже касаться непосредственно моделей передачи данных: сначала мы поговорим о эталонной модели OSI 7, а затем разберемся с моделью стека протоколов TCP/IP, которая на данный момент описывает взаимодействие в большинстве компьютерных сетей.

Возможно, эти записи вам покажутся интересными


Выберете удобный для себя способ, чтобы оставить комментарий

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Loading Disqus Comments ...