Канальный уровень. Канальный уровень в локальных сетях

Организация канального уровня

Важнейшими задачами, решаемыми канальным уровнем модели сетевого взаимодействия (иногда этот уровень называют уровнем передачи данных ), являются задачи предоставления определенных сервисов сетево­му уровню. Основным сервисом является передача данных от сетевого уровня пе­редающей вычислительной машины сетевому уровню принимающей машины. На передающей ма­шине работает процесс, который передает биты с сетевого уровня на канальный уровень для передачи их по назначению. Работа канального уров­ня заключается в передаче этих битов на принимающую маши­ну так, чтобы они могли быть переданы сетевому уровню принимающей машины. Физически данные передаются по реальным каналам передачи, как схематично пока­зано на рис. 8.1.а. Однако посредством протоколов канального уровня виртуальный путь передачи данных связывает канальные уровни пе­редающей и принимающей вычислительной машины (рис. 8.1.б ).

Рис. 8.1. Пути передачи данных: а – виртуальный; б – фактический

Протоколы канального уровня описывают, каким образом логические биты или символы, передаваемые физическим уровнем, объединяются в более крупные единицы – кадры . Обобщенная структура кадра показана на рис. 8.2. В общем случае, каждый кадр содер­жит заголовок, поле данных и трейлер (или так называемый «концевик» ). Управление кадрами – одна их главнейших функций работы канального уровня.

Рис. 8.2. Обобщенная структура кадра протокола канального уровня

Канальный уровень может предоставлять различные сервисы и их на­бор может быть разным для разных систем. Обычно рассматриваются следующие возможные вари­анты:

1) сервис без подтверждений приема кадров и без установления соединения;

2) сервис с подтверждениями приема кадров и без установления соединения;

3) сервис с подтверждениями приема кадров и с установлением соединения.

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

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

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

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

Обычно канальный уровень разбивает поток битов на отдельные кадры и считает для каждого кадра так называемую контрольную сумму. Когда кадр прибывает в пункт назначения, его контрольная сумма подсчитывается снова. Если она отличается от содержащейся в кадре, то канальный уровень «понимает», что при переда­че кадра произошла ошибка, и принимает соответствующие меры (например, игнорирует испор­ченный кадр и посылает передающей машине сообщение об ошибке). Разбиение потока битов на отдельные кадры представляет собой не очень простую задачу. Один из способов раз­биения на кадры заключается во вставке временных интервалов между кадрами, подобно тому, как вставляются пробелы между словами в тексте. Однако сети редко предоставляют гарантии сохранения временных интервалов при передаче данных, поэтому возможно, что эти интервалы при передаче исчезнут или, на­оборот, будут добавлены новые интервалы. Поэтому для повышения надежности передачи данных предложены более совершенные методы. Среди них наиболее популярны такие методы маркировки границ кадров (формирования кадров ), как:

1) подсчет количества символов;

2) применение сигнальных байтов с символьным заполнением;

3) использование стартовых и стоповых битов с битовым заполнением;

4) использование запрещенных сигналов физического уровня.

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

Второй метод формирования кадров решает проблему восстановления син­хронизации после сбоя при помощи маркировки начала и конца каждого кадра специальными байтами. В последнее время большинство протоколов перешло на использова­ние в обоих случаях одного и того же байта, называемого флаговым . Таким образом, если приемник теряет синхронизацию, ему необходимо просто найти флаговый байт, с помощью которого он распозна­ет конец текущего кадра. Два соседних флаговых байта говорят о том, что кон­чился один кадр и начался другой. Однако этот метод иногда приводит к серьезным проблемам при передачи бинарных данных, таких как объектные коды программ или числа с плавающей запятой. В передаваемых данных вполне может встретиться последовательность, исполь­зуемая в качестве флагового байта. Возникновение такой ситуации, скорее всего, собьет синхронизацию. Одним из способов решения проблемы является добав­ление специального escape-символа (знака переключения кода – ESC ) непосред­ственно перед байтом, случайно совпавшим с флаговым байтом внутри кадра. Канальный уровень получателя вначале убирает эти escape-символы, затем переда­ет кадр на сетевой уровень. Этот метод называется символьным заполнением. Таким образом, настоящий флаг можно отличить от «случайно совпавшего» по наличию или отсутствию перед ним символа ESC. Если же и символ ESC случайно окажется среди прочих данных, то перед этим фиктивным escape-символом также вставляется настоящий. Тогда любой одиночный ESC будет частью escape-после­довательности, а двойной будет указывать на то, что служебный байт случайно оказался в потоке данных. После очищения от вставных символов байтовая последовательности в точности совпадает с исходной. Главный недостаток этого метода заключается в том, что он тесно связан с 8-битными символами. Между тем не во всех кодировках один символ соответ­ствует 8 битам. Например, кодировка UNICODE использует 16-битное кодирование.

Следующий метод позволяет использовать кадры и наборы символов, состоящие из любого количества битов. При этом каждый кадр начинается и завершается специальной последовательностью битов 01111110. Битовое заполнение аналогично символьному, при котором в кадр перед случайно встретившимся среди данных флагом вставляется escape-символ. Битовое заполнение, как и сим­вольное, является абсолютно прозрачным для сетевого уровня обеих машин. Если флаговая последовательность битов (01111110) встречается в данных пользователя, она передается в виде 011111010, но в памяти принимающего ком­пьютера сохраняется опять в исходном виде: 01111110. Благодаря битовому заполнению границы между двумя кадрами могут быть безошибочно распознаны с помощью флаговой последовательности. Таким образом, если приемная сторона потеряет границы кадров, ей нужно всего лишь оты­скать в полученном потоке битов флаговый байт, поскольку он встречается толь­ко на границах кадров и не может присутствовать в данных пользователя.

Наконец, последний из рассматриваемых методов формирования кадров приемлем только в сетях, в которых физический носитель обладает некоторой избыточностью. Например, некоторые локальные сети кодируют один бит данных двумя физическими бита­ми. Так в «манчестерском» коде бит 1 кодируется парой высокого и низкого уровней сигналов (от­рицательный перепад), а бит 0 – наоборот, парой низкого и высокого уровней (положительный перепад). В такой схеме каждый передаваемый бит данных со­держит в середине переход, благодаря чему упрощается распознавание границ битов. Комбинации уровней сигналов (низкий–низкий и высокий–высокий) не используются для передачи данных, но используются в качестве ограничителей кадров в некоторых протоколах.

Отметим, что многие современные протоколы пе­редачи данных для повышения надежности применяют комбинированные методы формирования кадра.

Канальный уровень должен выполнять ряд специфических функций, к которым относятся обработка ошибок передачи данных и управление потоком данных , исключающее «затопление» медленных прием­ников быстрыми передатчиками.

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

Еще один важный аспект разработки канального уровня (а также более вы­соких уровней) связан с вопросом о том, что делать с отправителем, который по­стоянно желает передавать кадры быстрее, чем получатель способен их получать. Такая ситуация может возникнуть, если у передающей стороны оказывается бо­лее мощная (или менее загруженная) машина, чем у принимающей. При этом отпра­витель будет продолжает посылать кадры на высокой скорости до тех пор, пока получа­тель не окажется, как говорят, «затоплен» ими. Даже при идеально работающей линии связи в определенный момент времени получатель просто не сможет продолжать обработ­ку прибывающих кадров и начнет их терять. Для предотвраще­ния подобной ситуации чаще всего применяются два подхода. При первом, называющемся управлением потоком с обратной связью , получатель отсылает отправителю информацию, разрешающую последнему продолжить передачу или, по крайней мере, сообщающую о том, как идут дела у получателя. При втором подходе – управ­лении потоком с ограничением – в протокол встраивается механизм, ограничи­вающий скорость, с которой передатчики могут передавать данные, а обратная связь с получателем отсутствует. Известны различные схемы управления потоком с обратной связью, но большин­ство из них используют один и тот же принцип. Протокол содержит четко оп­ределенные правила, определяющие, когда отправитель может посылать следую­щий кадр. Эти правила часто запрещают пересылку кадра до тех пор, пока получатель не даст разрешения (явно либо неявно).

P.S. Возможно, со временем список дополнится.

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

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

1) Прикладной уровень. Тут работает само сетевое приложение. То есть веб-браузер, который запускается, например с компьютера.

2) Транспортный уровень. У приложения или службы должен быть порт, который он слушает и по которому с ним можно связаться.

3) Сетевой уровень. Здесь присутствует IP-адрес. Его еще называют логическим адресом устройства в сети. При помощи него можно связаться с компьютером, на котором запущен этот самый браузер, а значит, и достучаться до самого приложения. Имея данный адрес, он является участником сети и может связываться с другими участниками

4) Канальный уровень. Это сама сетевая карточка или антенна. То есть передатчик и приемник. У него есть физический адрес для идентификации этой сетевой карты. Кабели, коннекторы тоже относятся сюда. Это среда, которая свяжет компьютер с другими участниками.

Начнем с самого нижнего уровня. Это канальный и физический уровень, если рассматривать с точки зрения модели OSI и уровень доступа, если смотреть с высоты стека протоколов TCP/IP. Пользуемся мы TCP/IP, поэтому я буду говорить с ее точки зрения. Уровень доступа, как вы поняли, объединяет в себе физический и канальный уровень.

Физический уровень. Или как его любят называть «электрический уровень». Задает параметры сигнала, а также какой вид и форму имеет сигнал. Если, например, используется Ethernet (который передает данные при помощи провода), то какая модуляция, напряжение, ток. Если это Wi-Fi, то какие использовать радиоволны, частоту, амплитуду. К этому уровню можно отнести сетевые карты, Wi-Fi антенны, коннекторы. На этом уровне вводится такое понятие, как биты. Это единица измерения передаваемой информации.

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

Термин «физические адреса» ввели не просто так. Каждая сетевая карта или антенна имеет вшитый адрес, который ей присваивает производитель. В предыдущей статье я упоминал термин «протоколы». Только там это были протоколы верхнего уровня, а если точнее, то прикладного. На канальном уровне работают свои протоколы и количество их не маленькое. Самые популярные - это Ethernet (используется в локальных сетях), PPP и HDLC (они используются в глобальных сетях). Это конечно далеко не все, но Cisco в своей сертификации CCNA рассматривает только их.

Тяжело все это понять в виде сплошного сухого текста, поэтому объясню на картинке.

Забудьте сейчас про IP-адреса, модель OSI и стек протоколов TCP/IP. У вас есть 4 компьютера и коммутатор. На коммутатор внимания не обращайте, так как это обычная коробка для соединения компьютеров. У каждого компьютера есть свой MAC-адрес, который идентифицирует его в сети. Он должен быть обязательно уникальный. Хоть я и представил их 3-х значными, это далеко не так. Сейчас эта картинка только для логического понимания, а как это работает в реальной жизни, напишу чуть ниже.

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

Эти 4 компьютера образуют простенькую локальную сеть и одну канальную среду. Отсюда и название уровня. Но для корректной работы узлов в сетях TCP/IP, недостаточно адресации на канальном уровне. Важна еще адресация на сетевом уровне, которая всем известна, как IP-адресация.

Теперь вспоминаем про IP-адреса. И присвоим их нашим компьютерам.

Теперь важная вещь. Компьютер понимает, что он не знает MAC-адрес компьютера, доступность которого надо проверить. Для того, чтобы узнать MAC-адрес по IP-адресу, придумали протокол ARP. Я о нем напишу подробно позже. Сейчас я хочу, чтобы вы поняли зависимости MAC-адреса и IP-адреса. Итак, он на всю сеть начинает кричать: «Кто такой 1.1.1.4». Этот крик услышат все участники сети и, если найдется тот узел, который имеет данный IP-адрес, он отзовется. У меня такой компьютер присутствует и в ответ на этот крик, он ответит: «1.1.1.4 - это я. Мой MAC - 444». Мой компьютер получит это сообщение и сможет продолжить то, что я ему сказал.

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

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

Модернизирую сеть и покажу вам ее немного иначе.

Посмотрите внимательно на адреса всех устройств. Можно заметить, что у новых узлов и старых отличается 3-ий октет. Давайте разберемся с этим. Я также сижу за компом с MAC:111 и IP:1.1.1.1. Хочу отправить информацию одному из новых узлов. Давайте пусть это будет верхний правый компьютер с MAC:555 и IP:1.1.2.1. Накладываю маску и смотрю.

Мой комп знает, что адрес шлюза 1.1.1.254. Он крикнет на всю сеть: «1.1.1.254 отзовись». Это сообщение получат все участники канальной среды, но ответит только тот, кто сидит за этим адресом. То есть маршрутизатор. Он отправит ответ, и только после этого мой комп отошлет данные до адреса 1.1.2.254. Причем обратите внимание. На канальном уровне данные будут отправлены на MAC:777, а на сетевом, на IP:1.1.2.1. Это значит, что MAC-адрес передается только в своей канальной среде, а сетевой адрес не меняется на всем своем пути. Когда маршрутизатор получит инфу, он поймет, что на канальном уровне она предназначалась ему, но когда увидит IP-адрес, то поймет, что он промежуточное звено и передать надо в другую канальную среду. Его второй порт смотрит в нужную подсеть. Значит, ему все пришло верно. Но он не знает MAC-адрес адресата. Он начинает так же кричать на всю сеть: «Кто такой 1.1.2.1?». И комп с MAC-адресом 555 отвечает ему. Думаю, что логика работы понятна.

На протяжении двух предыдущих статей и текущей, много раз упоминался термин «MAC-адрес» . Давайте разберем, что это такое.

Как я уже говорил, это уникальный идентификатор сетевого устройства. Он уникален и не должен нигде повторяться. Состоит он из 48 бит, из которых первые 24 бита - это уникальный идентификатор организации, который присваивается комитетом IEEE(Институт инженеров электротехники и электроники). А вторые 24 бита назначаются производителем оборудования. Выглядит это так.

1) 00-50-56-C0-00-08
2) 00:50:56:C0:00:08
3) 0050.56С0.0008

Как видите, один и тот же адрес можно записать разными способами. Еще обычно его не разделяют, а записывают слитно. Главное знать, что MAC-адрес всегда состоит из 48 бит и состоит из 12 букв и/или цифр. Посмотреть его можно разными способами. Например, в ОС Windows, открыв командную строку, ввести ipconfig /all. Многие производители еще записывают его на коробке или на обратной стороне корпуса устройства.

Раз мы разобрали адрес на канальном уровне, пришло время разобрать протокол, работающий на данном уровне. Самый популярный на сегодняшний момент протокол, используемый в локальных сетях - это Ethernet . IEEE описала его стандартом 802.3. Так что, все версии, которые начинаются с 802.3, относятся именно к нему. Например, 802.3z - это GigabitEthernet через волоконно-оптический кабель; 1 Гбит/с, а 802.3af - это электропитание через Ethernet (PoE - Power over Ethernet).

Кстати, я не сказал об организации IEEE (англ. Institute of Electrical and Electronics Engineers) . Эта организация разрабатывает стандарты ко всему, что относится к радиоэлектронике и электротехнике. На их сайте можно найти много документации по существующим технологиям. Вот, что они выдают по запросу «Ethernet»

2) MAC-адрес получателя. Поле, куда записывается адрес получателя.

3) MAC-адрес отправителя. Соответственно сюда записывается адрес отправителя.

4) Тип (длина). Раньше в этом поле указывалось, какому вышестоящему протоколу передается данный кадр, но в дальнейшем от этого отказались и ввели поле «Длина». Оно указывает длину поля данных, которое варьируется от 46-1500 байт.

5) Поле SNAP/LLC + данные. Как раз SNAP/LLC указывает какому вышестоящему протоколу передать кадр. Это может быть IP, IPX и другие протоколы сетевого уровня. Также в этом поле содержатся данные, полученные с высших уровней.

6) FCS (от англ. Frame Check Sequence - контрольная сумма кадра). Поле в котором подсчитана чек-сумма. По ней получатель понимает, побился кадр или нет.

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

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

IP (от англ. Internet Protocol). Протокол семейства TCP/IP, который был разработан в 80-х годах. Как я говорил ранее, используется для объединения отдельных компьютерных сетей между собой. Также важной его особенностью является адресация, которую называют

IP-адрес . На текущий момент существуют 2 версии протокола: IPv4 и IPv6. Пару слов о них:

1) IPv4. Использует 32-битные адреса, которые записываются в формате четырёх десятичных чисел (от 0 до 255), разделённых точками. Например, адрес 192.168.0.4. Каждое число разделенное точками называют октетом. Это самая популярная версия на сегодняшний день.

2) IPv6. Использует 128-битные адреса, которые записываются в формате восьми четырехзначных шестнадцатеричных чисел (от 0 до F). Например, адрес 2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d. Каждое число разделенное точками называют хекстетом. На заре всеобщей компьютеризации появилась проблема. Стали заканчиваться IP-адреса и нужен был новый протокол, который смог бы обеспечить больше адресов. Так и появился в 1996 году протокол IPv6. Но благодаря технологии NAT, которая будет рассмотрена позже, была частична решена проблема нехватки адресов, и, в связи с этим, внедрение IPv6 затянулось по сегодняшний день.

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

Итак, протокол IP работает с блоком информации, который принято называть IP-пакет. Рассмотрим его структуру.

2) IHL (от англ. Internet Header Length - размер заголовка). Так как многие из показанных на картинке полей не фиксированы, то это поле считает размер заголовка.

3) Тип обслуживания. Обслуживает размер очередей QoS (Quality of Service - качество обслуживания). Делает он это при помощи байта, который указывает на определенный набор критериев (требование ко времени задержки, пропускной способности, надежности и т.д.)

4) Длина пакета. Размер пакета. Если IHL отвечает только за размер полей в заголовке (заголовком являются все поля на картинке, кроме поля данных), то длина пакета отвечает за весь пакет в целом, включая пользовательские данные.

5) Время жизни (TTL- Time To Live). Поле, используемое для предотвращения циклического пути пакета. При прохождении через маршрутизатор, значение уменьшается на единицу, и когда достигает нуля, пакет отбрасывается.

6) Протокол. Для какого вышестоящего протокола предназначается данный пакет (TCP, UDP).

7) Контрольная сумма заголовка. Здесь считается целостность полей заголовка. Не данных! Данные проверяются соответствующим полем на канальном уровне.

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

9) Смещение. Указывает, какому месту принадлежит фрагмент в оригинальном IP. Это значение всегда кратно восьми байтам.

10) Данные. Здесь как раз содержатся данные, полученные с вышестоящих уровней. Чуть выше я показал, что в Ethernet-кадре тоже есть поле данных. И в его поле данных будет включен данный IP-пакет. Важно помнить, что максимальный размер Ethernet-кадра равен 1500 байт, а вот размер IP пакета может быть 20 Кбайт. Соответственно весь пакет не вместится в поле данных Ethernet-кадра. Поэтому пакет делят и отправляют частями. И вот для этого используются 3 поля ниже.

11) Идентификатор. Это 4-х байтовое число, которое показывает, что все части разделенного пакета одно единое целое.

12) Флаги. Указывает, что это не единый, а фрагментированный пакет.

13) Смещение фрагмента. Сдвиг относительно первого фрагмента. То есть это нумерация, которая поможет собрать IP-пакет воедино.

14) IP-адрес отправителя и IP-адрес получателя. Соответственно эти 2 поля указывают от кого и для кого пакет.

Вот так выглядит IP-пакет. Конечно, для новичков значения многих полей покажутся не совсем понятными, но в дальнейшем это уложится в голове. Например: поле «Время жизни (TTL)». Его работа станет ясна, когда поймете, как работает маршрутизация. Могу дать совет, который я сам применяю. Если видите непонятный термин, выпишите его отдельно и, при наличии свободного времени, попробуйте разобрать. Если никак не лезет в голову, то отложите и вернитесь к его изучению чуть позже. Главное не забрасывать и в конечном итоге все таки добить.

Остался последний уровень из стека TCP/IP. Это транспортный уровень . Пару слов о нем. Он предназначен для доставки данных определенному приложению, которое он определяет по номеру порта. В зависимости от протокола, он выполняет разные задачи. Например, фрагментация файлов, контроль доставки, мультиплексирование потоками данных и управление ими. 2 самых известных протокола транспортного уровня - это UDP и TCP. Поговорим о каждом из них подробнее, и начну с UDP, в силу его простоты. Ну и по традиции показываю, из чего он состоит.

2) Порт назначения. Здесь указывается порт, который будет являться адресатом. Например, если клиент запрашивает страницу сайта, то порт назначения, по умолчанию, будет 80-ый (протокол HTTP).

3) Длина UDP. Длина заголовка UDP. Размер варьируется от 8 до 65535 байт.

4) Контрольная сумма UDP. Проверка целостности. Если нарушена, то просто отбрасывает без запроса о повторной отправки.

5) Данные. Здесь упакованы данные с верхнего уровня. Например, когда веб-сервер отвечает на запрос клиента и отправляет веб-страницу, то она будет лежать в этом поле.

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

Переходим к более сложному протоколу. Встречаем протокол TCP. Смотрим, из чего состоит, и пробегаем по каждому полю.

2) Порядковый номер. Номер, который используется для того, чтобы на другой стороне было понятно какой этот сегмент по счету.

3) Номер подтверждения. Это поле используется, когда ожидается доставка или подтверждается доставка. Для этого используется параметр ACK.

4) Длина заголовка. Используется для того, чтобы понять какой размер у TCP-заголовка (это все поля представленные на картинке выше, кроме поля данных), а какой у данных.

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

6) Флаги. В это поле устанавливаются специальные биты для установления или разрыва сессии.

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

8) Контрольная сумма TCP. Проверка целостности TCP-сегмента.

9) Указатель важности. Это смещение последнего октета важных данных относительно SEQ для пакетов с установленным флагом URG. В жизни применяется, когда необходимо осуществить контроль потока или состояния протокола верхнего уровня со стороны передающего агента (например, если принимающий агент может косвенно сигнализировать передающему, что не справляется с потоком данных).

10) Опции. Используется для каких нибудь расширенных или дополнительных параметров. Например, для параметра timestamp, который является своеобразной меткой, показывающей время произошедшего события.

11) Данные. Практически тоже самое, что и в протоколе UDP. Здесь инкапсулированы данные с вышестоящего уровня.

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

Я открываю CPT и соберу схему, аналогичную одному из рисунков выше.

Открываю компьютер PC1 и пропишу сетевые настройки.

1) IP-адрес - 192.168.1.1

Эту маску мы рассматривали выше. Напомню, что адрес сети у других хостов в той же локальной сети, должен быть 192.168.1, а адрес хоста может быть от 1 до 254.

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

Чтобы не было много однотипных картинок, я не буду приводить скриншоты остальных 3-х компьютеров, а только приведу их настройки.

PC2:
1) IP-адрес - 192.168.1.2
.
3) Основной шлюз - 192.168.1.254.

PC3:
1) IP-адрес - 192.168.1.3
2) Маска подсети - 255.255.255.0.
3) Основной шлюз - 192.168.1.254.

PC4:
1) IP-адрес - 192.168.1.4
2) Маска подсети - 255.255.255.0.
3) Основной шлюз - 192.168.1.254.

На данной настройке пока остановимся и посмотрим, как работает наша локальная сеть. Перевожу CPT в режим симуляции. Допустим, я сижу за компьютером PC1, и требуется проверить доступность PC4 командой ping. Открываю командную строку на PC1.

Но тут ping сталкивается с проблемой. Он не знает MAC-адрес получателя. То есть, адрес канального уровня. Для этого он использует протокол ARP, который сможет опросить участников сети и узнать MAC-адрес. Мы про него вскользь говорили в предыдущей статье. Давайте поговорим о нем подробнее. Не буду изменять традиции. Картинку в студию!

1) Тип протокола канального уровня (Hardware type). Думаю понятно из названия, что тут указывается тип канального уровня. Мы пока рассматривали только Ethernet. Его обозначение в этом поле - 0x0001.

2) Тип протокола сетевого уровня (Protocol type). Тут, аналогично, указывается тип сетевого уровня. Код IPv4 - 0x0800.

3) Длина физического адреса в байтах (Hardware length). Если это MAC-адрес, то размер будет 6 байт (или 48 бит).

4) Длина логического адреса в байтах (Protocol length). Если это IPv4-адрес, то размер будет 4 байта (или 32 бита).

5) Код операции (Operation). Код операции отправителя. Если это запрос, то код 0001. В случае ответа - 0002.

6) Физический адрес отправителя (Sender hardware address). MAC-адрес отправителя.

7) Логический адрес отправителя (Sender protocol address). IP-адрес отправителя.

8) Физический адрес получателя (Target hardware address). MAC-адрес получателя. Если это запрос, то, как правило, адрес неизвестен и это поле остается пустым.

9) Логический адрес получателя (Target protocol address). IP-адрес получателя.

Теперь, когда мы знаем, из чего он состоит, можно посмотреть на его работу в CPT. Кликаю по второму конверту и наблюдаю следующую картину.

1) Преамбула - здесь битовая последовательность, которая говорит о начале кадра.

2) Далее идет MAC-адрес источника и получателя. В адресе источника записан MAC-адрес компьютера, который является инициатором, а в адресе получателя записан широковещательный адрес FF-FF-FF-FF-FF-FF (то есть для всех узлов в канальной среде).

3) Тип - здесь указан вышестоящий протокол. Код 0x806 означает, что выше стоит ARP. Я, если честно, не могу точно сказать, на каком уровне он работает. В разных источниках указано по-разному. Кто то говорит, что на 2-ом уровне OSI, а кто-то говорит, что на 3-ем. Я считаю, что он между ними работает. Так как тут есть адреса, присущие каждому из уровней.

Про данные и чек-сумму много говорить не буду. Данные здесь никак не указаны, а чек-сумма нулевая.

Поднимаемся чуть повыше и здесь протокол ARP .

1) Hardware Type - код канального уровня. CPT убрала лишние нули и вставила 0x1 (тоже, что и 0x0001). Это Ethernet.
2) Protocol Type - код сетевого уровня. 0x800 - это IPv4.
3) HLEN - длина физического адреса. 0x6 означает 6 байт. Все верно (MAC-адрес занимает 6 байт).
4) PLEN - длина сетевого адреса. 0x4 означает 4 байта (IP-адрес занимает 4 байта).
5) OPCODE - код операции. 0x1 означает, что это запрос.
6) Source Mac - здесь MAC-адрес отправителя. Можно сравнить его с адресом в поле протокола Ethernet и убедиться в правильности.
7) Source IP - IP-адрес отправителя.
8) Target MAC - так как это запрос и канальный адрес не известен, то он пустой. CPT показала его нулями, что равносильно.
9) Target IP - IP-адрес получателя. Как раз тот адрес, который пингуем.

1) В поле источника протокола Ethernet теперь записан MAC-адрес PC4, а в поле назначения MAC-адрес инициатора, то есть PC1.
2) В поле OPCODE теперь значение 0x2, то есть ответ.
3) Поменялись поля логических и физических адресов в протоколе ARP. Source MAC и Destination MAC аналогичны тем, что в протоколе Ethernet. В поле Source IP - адрес 192.168.1.4 (PC4), а в поле Destination IP - адрес 192.168.1.1 (PC1).

Как только эта информация достигнет PC1, он сразу формирует ICMP-сообщение, то есть ping.

1) В Ethernet протоколе ничего нового, а именно MAC-адрес отправителя - PC1, MAC-адрес получателя - PC4, а в поле Type - 0x800 (протокол IPv4)
2) В IP протоколе, в поле Версия - 4, что означает протокол IPv4. IP-адрес отправителя - PC1, а IP-адрес получателя - PC4.
3) В ICMP протоколе, в поле Type - код 0x8 (эхо-запрос).

Посылает он эхо-запрос, а я смотрю, чем ответит PC4.

Судя по логике, как только этот ответ достигнет PC1, в консоли PC1 должна появиться запись. Давайте проверим.

По умолчанию пинг отправляет 4 запроса. Следовательно, PC1 сформирует еще 3 аналогичных ICMP. Показывать путь каждого пакета я не буду, а приведу финальный вывод консоли на PC1.

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

Открываю я компьютер с именем PC5 и пропишу сетевые настройки.

Привожу настройки PC6:

1) IP-адрес - 192.168.2.2
2) Маска подсети - 255.255.255.0
3) Основной шлюз - 192.168.2.254

Хосты во 2-ой канальной среде настроены и прекрасно работают. Для того, чтобы они смогли общаться с хостами из 1-ой канальной, нужно настроить маршрутизатор, который соединяет эти среды. Маршрутизатор настраивается через CLI (то есть в консольном виде) и проще будет приводить сюда не скриншоты, а команды.

1) Router>enable - переход в привилегированный режим
2) Router#configure terminal - переход в режим глобальной конфигурации
3) Router(config)#interface fastEthernet 0/0 - переходим к настройке порта 0/0, который смотрит на первую канальную среду
4) Router(config-if)#ip address 192.168.1.254 255.255.255.0 - вешаем на этот порт IP-адрес. Так как этот порт будет являться основным шлюзом для 1-ой канальной среды, то указываем ему тот IP, который прописали хостам
5) Router(config-if)#no shutdown - включаем этот интерфейс. По умолчанию все порты на цисковских маршрутизаторах выключены
6) Router(config-if)#exit - выходим из режима настройки fastEthernet 0/0
7) Router(config)#interface fastEthernet 0/1 - переходим к настройке порта 0/1, который смотрит на вторую канальную среду
8) Router(config-if)#ip address 192.168.2.254 255.255.255.0 - вешаем сюда адрес, который будет являться основным шлюзом для хостов во 2-ой канальной среде
9) Router(config-if)#no shutdown - аналогично включаем его
10) Router(config-if)#end - пишем команду, которая отбросит в привилегированный режим
11) Router#copy running-config startup-config - сохраняем настройки в памяти маршрутизатора

На этом этапе настройка маршрутизатора окончена. Немного забегу вперед и покажу полезную команду «show ip route». Она показывает все известные маршрутизатору сети и маршрут до них.

Исходя из этой таблицы, можно удостовериться, что он знает и про 1-ую канальную среду, и про 2-ую. Отлично. Осталось дело за малым - это проверить доступность PC5 из PC1. Пробую. Переключаю CPT в режим симуляции. Открываю командную строку и пингую 192.168.2.1.

Сначала посмотрим на ICMP.

Что же будет происходить дальше. PC1 видит, что проверяется доступность хоста, находящегося в другой канальной среде (путем наложения маски на свой IP-адрес и IP-адрес получателя). И кроме IP-адреса он не знает о получателе ничего. Соответственно в таком виде отправлять пакет ICMP нельзя. Зато он знает, что у него есть основной шлюз, который, скорее всего, знает что-то про канальную среду, в которой находится PC5. Но возникает еще одна сложность. Он знает IP-адрес шлюза (который я ему прописал в сетевых настройках), но не знает его MAC-адреса. Тут ему приходит на помощь протокол ARP, который опросит всех участников канальной среды и найдет его MAC-адрес. Посмотрим, как заполнены поля.

И чуть повыше (протокол ARP):

1) SOURCE MAC - тот же PC1, а DESTINATION MAC пустой (его должен заполнить тот, для кого этот запрос предназначен).
2) SOURCE IP - адрес PC1, а вот DESTINATION IP - адрес основного шлюза.

1) Source MAC - сюда он вставляет свой MAC-адрес (а именно MAC-адрес fastEthernet0/0).
2) Destination MAC - сюда записывает MAC-адрес PC1 (то есть того, кто запросил).
ARP:
1) Source MAC и Destination MAC аналогично записям в протоколе Ethernet.
2) Source IP - свой IP-адрес.
3) Target IP - IP-адрес PC1.

1) SRC MAC: здесь указан MAC-адрес PC1.
2) DEST MAC: MAC-адрес маршрутизатора.
3) SRC IP: IP-адрес PC1.
4) DST IP: IP-адрес PC5.

Что это значит. Адреса на сетевом уровне (то есть IP-адреса) не меняются, чтобы знать от кого и кому предназначается информация. А адреса на канальном уровне (MAC-адреса) могут спокойно меняться, переходя из одной канальной среды в другую. Это очень важно понять и запомнить!

Смотрим, что происходит. Пакет доходит до маршрутизатора и сразу перечеркивается. А все из-за того, что он не знает MAC-адрес PC5. Теперь он формирует ARP-запрос и пытается его узнать. Привожу скриншот этого запроса.

Как только этот ответ дойдет до маршрутизатора, он будет знать канальный адрес PC5. Но вот что произошло. Пока тянулась канитель с ARP у маршрутизатора и PC5, у PC1 истекает время ожидания ответа отправленного ICMP. Показываю картинку.

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

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

Начну, как всегда, с простого. И это протокол UDP. Как я уже говорил выше, он используется для того, чтобы передать данные определенному протоколу вышестоящего уровня. Делает он это при помощи портов. Один из протоколов, работающих с UDP - это TFTP(Trivial File Transfer Protocol). Протокол этот мы рассматривали в предыдущей статье. Поэтому трудностей возникнуть не должно. Для демонстрации потребуется добавить в сеть сервер с включенной службой TFTP.

Настройки сервера следующие:

1) IP-адрес - 192.168.1.5
2) Маска подсети - 255.255.255.0
3) Основной шлюз - 192.168.1.254

Служба TFTP включена по умолчанию, но лучше проверить. Далее переключаю CPT в режим симуляции и попробую сохранить конфигурацию маршрутизатора на TFTP-сервер:

1) Router>enable - переход в привилегированный режим.
2) Router#copy startup-config tftp: - пишу команду copy (то есть скопировать), далее startup-config (что именно скопировать) и tftp: (куда скопировать).
3) Address or name of remote host ? 192.168.1.5 - выходит сообщение с запросом адреса или имени сервера, где я пишу его адрес.
4) Destination filename ? - следом он спрашивает, под каким именем его сохранить на сервере и предлагает стандартное имя. Меня это устраивает, и я жму ENTER.

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

Ethernet:
1) Source MAC - адрес маршрутизатора.
2) Destination MAC - адрес сервера.
3) Type - 0x800 (означает, что выше работает протокол IP).

IP:
1) Protocol - 0x11 (означает, что выше работает протокол UDP).
2) Source IP - адрес маршрутизатора.
3) Destination IP - адрес сервера.

UDP:
1) Source Port - динамически созданный порт (1025).
2) Destination Port - порт, который слушает TFTP-сервер (зарезервированный 69 порт).

TFTP:
Здесь находятся сами данные.

Так и работает протокол UDP. Он не устанавливает сессии, не требует подтверждения доставки, а если что-то потеряется, он не запрашивает повторно. Его работа - это указать номер порта и отправить. Что там будет происходить дальше, его не интересует. Но возникают случаи, когда это не устраивает и все эти параметры критически важны. Тогда на помощь приходит протокол TCP. Рассмотрим его на примере использования веб-сервера и веб-клиента. Веб-сервером у нас будет тот же TFTP-сервер. Включаем службу HTTP и запросим страницу с компьютера PC1. Не забываем переключить CPT в режим симуляции!

Перед тем как продолжить, я расскажу про установление TCP-сессии. Постараюсь изложить этот процесс максимально просто. Этот процесс называют «трехстороннее рукопожатие» или «handshake». В чем суть. Клиент отправляет TCP-сегмент с флагом «SYN». Получив сегмент, сервер принимает решение. Если он согласен установить соединение, то он отправляет ответный сегмент с флагом «SYN+ACK». Если не согласен, то отправляет сегмент с флагом «RST». Далее клиент смотрим на ответный сегмент. Если там стоит флаг «SYN+ACK», то он в ответ отправляет сегмент с флагом «ACK» и устанавливается соединение. Если же там стоит флаг «RST», то он прекращает попытки соединения. После того, как потребуется разорвать установившееся соединение, клиент формирует и отправляет TCP-сегмент с флагом «FIN+ACK». Сервер на этот сегмент отвечает аналогичным флагом «FIN+ACK». И наконец, клиент отправляет последний TCP-сегмент с флагом «ACK». Сейчас вы увидите, как это работает на практике.

Переключаю внимание на сеть и вижу, как PC1 формирует TCP-сегмент.

А вот в TCP уже поинтереснее.

1) Source Port - 1025 (это динамически сгенерированный порт веб-клиента).
2) Destination Port - 80 (это зарезервированный порт протокола HTTP).
3) Flag - SYN (запрос на установление сессии)

Смотрим, чем ответит веб-сервер.

Как только клиент получает этот сегмент, он сразу формирует 2 сообщения. Один из них TCP-сегмент, представленный ниже, который отправляется с флагом «ACK».

А второй - HTTP, где указана версия протокола, какая страница и адрес сервера.

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

Ну что же, статья подходит к концу. Хочу выразить благодарность пользователю под ником remzalp за предоставленную картинку и остальным пользователям, которые оставляют полезные комментарии к статьям. Очень приятно видеть, как люди интересуются, задают вопросы, ведут объективные и конструктивные споры. Хочется, чтобы русскоязычное IT-сообщество все больше развивалось и материалов для изучения в свободном доступе становилось все больше. Спасибо за прочтение и до встречи на следующей.

(двухузловой).

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

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

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

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

Стандарты и протоколы передачи данных

• Econet,
• Ethernet Automatic Protection Switching (EAPS),
• IEEE 802.2 (provides LLC functions to IEEE 802 MAC layers),
• Link Access Procedures, D channel (LAPD),
• LocalTalk,
• Multiprotocol Label Switching (MPLS),
• Serial Line Internet Protocol (SLIP) (obsolete),

В программировании доступ к этому уровеню предоставляет драйвер сетевой платы. В операционных системах имеется программный интерфейс взаимодействия канального и сетевого уровней между собой, это не новый уровень, а просто реализация модели для конкретной ОС. Примеры таких интерфейсов: ODI, NDIS . [значимость факта? ]

Wikimedia Foundation . 2010 .

Смотреть что такое "Канальный уровень" в других словарях:

канальный уровень - Второй уровень эталонной модели ISO/OSI, обеспечивающий базовые коммуникационные сервисы. Канальный уровень CAN определяет кадры данных, удаленного запроса, ошибки и перегрузки. … …

канальный уровень стека связи (сети и системы связи) - Уровень канала передачи данных. [ГОСТ Р 54325 2011 (IEC/TS 61850 2:2003)] EN data link layer layer 2 of the OSI reference model for Open Systems Interconnection, responsible for the transmission of data over a physical medium. After establishment … Справочник технического переводчика

канальный уровень сетевого протокола - — Тематики электросвязь, основные понятия EN link layer of network protocol function … Справочник технического переводчика

уровень канала передачи данных - канальный уровень уровень звена данных — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом Синонимы канальный уровеньуровень звена данных EN data link layer… … Справочник технического переводчика

уровень звена данных - Ндп. канальный уровень Уровень взаимосвязи открытых систем, обеспечивающий услуги по обмену данными между логическими объектами сетевого уровня, протокол управления звеном данных, формирование и передачу кадров данных [ГОСТ 24402 88] Недопустимые … Справочник технического переводчика

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

Сетевая модель OSI (базовая эталонная модель взаимодействия открытых систем, англ. Open Systems Interconnection Basic Reference Model) абстрактная сетевая модель для коммуникаций и разработки сетевых протоколов. Представляет уровневый подход к… … Википедия

Уровень звена данных - 26. Уровень звена данных Ндп. Канальный уровень Data link layer Уровень взаимосвязи открытых систем, обеспечивающий услуги по обмену данными между логическими объектами сетевого уровня, протокол управления звеном данных, формирование и передачу… … Словарь-справочник терминов нормативно-технической документации

- (англ. Session layer) 5 й уровень сетевой модели OSI, отвечает за поддержание сеанса связи, позволяя приложениям взаимодействовать между собой длительное время. Уровень управляет созданием/завершением сеанса, обменом информацией,… … Википедия

5. Протоколы канального уровня

Функции КУ:

• Формирование кадра
• Контроль ошибок и повышение достоверности
• Обеспечение кодонезависимой передачи
• Восстановление исходной последовательности блоков на приемной стороне
• Управление потоком данных на уровне звена
• Устранение последствий потерь или дублирования кадров

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

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

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

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

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

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

  асинхронный/синхронный;

  символьно-ориентированный/бит-ориентированный;

  с предварительным установлением соединения/дейтаграммный;

  с обнаружением искаженных данных/без обнаружения;

  с обнаружением потерянных данных/без обнаружения;

  с восстановлением искаженных и потерянных данных/без восстановления;

  с поддержкой динамической компрессии данных/без поддержки.

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

  5.1. Асинхронные протоколы

  
  

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

  В асинхронных протоколах применяются стандартные наборы символов, чаще всего ASCII или EBCDIC. Так как первые 32 или 27 кодов в этих наборах являются специальными кодами, которые не отображаются на дисплее или принтере, то они использовались асинхронными протоколами для управления режимом обмена данными. В самих пользовательских данных, которые представляли собой буквы, цифры, а также такие знаки, как @, %, $ и т. п., специальные символы никогда не встречались, так что проблемы их отделения от пользовательских данных не существовало.

  Постепенно асинхронные протоколы усложнялись и стали наряду с отдельными символами использовать целые блоки данных, то есть кадры. Например, протокол XModem.

  5.2. Синхронные символьно-ориентированные и бит-ориентированные протоколы

  
  

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

  Рис. 5.1. Кадры синхронных протоколов

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

  Большинство протоколов допускает использование в кадре поля данных переменной длины. Иногда и заголовок может иметь переменную длину. Обычно протоколы определяют максимальное значение, которое может иметь длина поля данных. Эта величина называется максимальной единицей передачи данных (Maximum Transfer Unit, MTU) . В некоторых протоколах задается также минимальное значение, которое может иметь длина поля данных. Например, протокол Ethernet требует, чтобы поле данных содержало по крайней мере 46 байт данных (если приложение хочет отправить меньшее количество байт, то оно обязано дополнить их до 46 байт любыми значениями). Другие протоколы разрешают использовать поле данных нулевой длины, например FDDI.

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

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

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

  Синхронизация достигается за счет того, что передатчик добавляет два или более управляющих символа, называемых символами SYN, перед каждым блоком символов. В коде ASCII символ SYN имеет двоичное значение 0010110, это несимметричное относительно начала символа значение позволяет легко разграничивать отдельные символы SYN при их последовательном приеме. Символы SYN выполняют две функции: во-первых, они обеспечивают приемнику побитную синхронизацию, во-вторых, как только битовая синхронизация достигается, они позволяют приемнику начать распознавание границ символов SYN. После того как приемник начал отделять один символ от другого, можно задавать границы начала кадра с помощью другого специального символа. Обычно в символьных протоколах для этих целей используется символ STX (Start of TeXt, ASCII 0000010). Другой символ отмечает окончание кадра - ЕТХ (End of TeXt, ASCII 0000011).

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

  Наиболее популярным протоколом такого типа был протокол BSC компании IBM. Он работал в двух режимах - непрозрачном, в котором некоторые специальные символы внутри кадра запрещались, и прозрачном, в котором разрешалась передачи внутри кадра любых символов, в том числе и ЕТХ. Прозрачность достигалась за счет того, что перед управляющими символами STX и ЕТХ всегда вставлялся символ DLE (Data Link Escape). Такая процедура называется стаффингом символов (stuff - всякая всячина, заполнитель). А если в поле данных кадра встречалась последовательность DLE ЕТХ, то передатчик удваивал символ DLE, то есть порождал последовательность DLE DLE ЕТХ. Приемник, встретив подряд два символа DLE DLE, всегда удалял первый, но оставшийся DLE уже не рассматривал как начало управляющей последовательности, то есть оставшиеся символы DLE ЕТХ считал просто пользовательскими данными.

  Бит-ориентированные протоколы

  Потребность в паре символов в начале и конце каждого кадра вместе с дополнительными символами DLE означает, что символьно-ориентированная передача не эффективна для передачи двоичных данных, так как приходится в поле данных кадра добавлять достаточно много избыточных данных. Кроме того, формат управляющих символов для разных кодировок различен, например, в коде ASCII символ SYN равен 0010110, а в коде EBCDIC - 00110010. Так что этот метод допустим только с определенным типом кодировки, даже если кадр содержит чисто двоичные данные.

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

  На рис. 5.2 показаны 3 различные схемы бит-ориентированной передачи. Они отличаются способом обозначения начала и конца каждого кадра.

  

  Рис. 5.2. Способы выделения начало и конца кадра при синхронной передаче

  Первая схема, показанная на рис. 5.2, а, похожа на схему с символами STX и ЕТХ в символьно-ориентированных протоколах. Начало и конец каждого кадра отмечается одной и той же 8-битовой последовательностью - 01111110, называемой флагом. Термин «бит-ориентированный» используется потому, что принимаемый поток бит сканируется приемником на побитовой основе для обнаружения стартового флага, а затем во время приема для обнаружения стопового флага. Поэтому длина кадра в этом случае не обязательно должна быть кратна 8 бит.

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

  Для достижения прозрачности данных в этой схеме необходимо, чтобы флаг не присутствовал в поле данных кадра. Это достигается с помощью приема, известного как вставка 0 бита, - бит-стаффинга . Схема вставки бита работает только во время передачи поля данных кадра. Если эта схема обнаруживает, что подряд передано пять 1, то она автоматически вставляет дополнительный 0 (даже если после этих пяти 1 шел 0). Поэтому последовательность 01111110 никогда не появится в поле данных кадра. Аналогичная схема работает в приемнике и выполняет обратную функцию. Когда после пяти 1 обнаруживается 0, он автоматически удаляется из поля данных кадра. Бит-стаффинг гораздо более экономичен, чем байт-стаффинг, так как вместо лишнего байта вставляется один бит, следовательно, скорость передачи пользовательских данных в этом случае замедляется в меньшей степени.

  Во второй схеме (рис. 5.2, б) для обозначения начала кадра имеется только стартовый флаг, а для определения конца кадра используется поле длины кадра, которое при фиксированных размерах заголовка и концевика чаще всего имеет смысл длины поля данных кадра. Эта схема наиболее применима в локальных сетях. В этих сетях для обозначения факта незанятости среды в исходном состоянии по среде вообще не передается никаких символов. Чтобы все остальные станции вошли в битовую синхронизацию, посылающая станция предваряет содержимое кадра последовательностью бит, известной как преамбула, которая состоит из чередования единиц и нулей 101010... Войдя в битовую синхронизацию, приемник исследует входной поток на побитовой основе, пока не обнаружит байт начала кадра 10101011, который выполняет роль символа STX. За этим байтом следует заголовок кадра, в котором в определенном месте находится поле длины поля данных. Таким образом, в этой схеме приемник просто отсчитывает заданное количество байт, чтобы определить окончание кадра.

  Третья схема (рис. 5.2, в) использует для обозначения начала и конца кадра флаги, которые включают запрещенные для данного кода сигналы (code violations, V). Например, при манчестерском кодировании вместо обязательного изменения полярности сигнала в середине тактового интервала уровень сигнала остается неизменным и низким (запрещенный сигнал J) или неизменным и высоким (запрещенный сигнал К). Начало кадра отмечается последовательностью JKOJKOOO, а конец - последовательностью JK1JK100. Этот способ очень экономичен, так как не требует ни бит-стаффинга, ни поля длины, но его недостаток заключается в зависимости от принятого метода физического кодирования. При использовании избыточных кодов роль сигналов J и К играют запрещенные символы, например, в коде 4В/5В этими символами являются коды 11000 и 10001.

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

  Протоколы с гибким форматом кадра

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

  Однако существует ряд протоколов, в которых кадры имеют гибкую структуру. Например, к таким протоколам относятся очень популярный прикладной протокол управления сетями SNMP, а также протокол канального уровня РРР, используемый для соединений типа «точка-точка». Кадры таких протоколов состоят из неопределенного количества полей, каждое из которых может иметь переменную длину. Начало такого кадра отмечается некоторым стандартным образом, например с помощью флага, а затем протокол последовательно просматривает поля кадра и определяет их количество и размеры. Каждое поле обычно описывается двумя дополнительными полями фиксированного размера. Например, если в кадре встречается поле, содержащее некоторую символьную строку, то в кадр вставляются три поля:

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

  5.3. Передача с установлением соединения и без установления соединения

  
  

  При передаче кадров данных на канальном уровне используются как дейтаграммные процедуры, работающие без установления соединения (connectionless) , так и процедуры с предварительным установлением логического соединения (connection-oriented) .

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

  

  Рис. 5.3. Протоколы без установления соединения (а) и с установлением соединения (б)

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

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

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

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

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

  Логическое соединение обеспечивает передачу данных как в одном направлении - от инициатора соединения, так и в обоих направлениях.

  Процедура установления соединения может использоваться для достижения различных целей.

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

  Для согласования изменяемых параметров протокола: MTU, различных тайм-аутов и т. п.

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

  В некоторых технологиях процедуру установления логического соединения используют при динамической настройке коммутаторов сети для маршрутизации всех последующих кадров, которые будут проходить через сеть в рамках данного логического соединения. Так работают сети технологий Х.25, frame relay и АТМ.

  Как видно из приведенного списка, при установлении соединения могут преследоваться разные цели, в некоторых случаях - несколько одновременно.

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

  5.4. Обнаружение и коррекция ошибок

  
  

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

  Большая часть протоколов канального уровня выполняет только первую задачу - обнаружение ошибок, считая, что корректировать ошибки, то есть повторно передавать данные, содержавшие искаженную информацию, должны протоколы верхних уровней. Так работают такие популярные протоколы локальных сетей, как Ethernet, Token Ring, FDDI и другие. Однако существуют протоколы канального уровня, например LLC2 или LAP-B, которые самостоятельно решают задачу восстановления искаженных или потерянных кадров.

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

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

  5.5. Методы обнаружения ошибок

  
  

  Все методы обнаружения ошибок основаны на передаче в составе кадра данных служебной избыточной информации, по которой можно судить с некоторой степенью вероятности о достоверности принятых данных. Эту служебную информацию принято называть контрольной суммой или (последовательностью контроля кадра - Frame Check Sequence, FCS ).

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

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

  Контроль по паритету представляет собой наиболее простой метод контроля данных. В то же время это наименее мощный алгоритм контроля, так как с его помощью можно обнаружить только одиночные ошибки в проверяемых данных. Метод заключается в суммировании по модулю 2 всех бит контролируемой информации. Например, для данных 100101011 результатом контрольного суммирования будет значение 1. Результат суммирования также представляет собой один бит данных, который пересылается вместе с контролируемой информацией. При искажении при пересылке любого одного бита исходных данных (или контрольного разряда) результат суммирования будет отличаться от принятого контрольного разряда, что говорит об ошибке. Однако двойная ошибка, например 110101010, будет неверно принята за корректные данные. Поэтому контроль по паритету применяется к небольшим порциям данных, как правило, к каждому байту, что дает коэффициент избыточности для этого метода 1/8. Метод редко применяется в вычислительных сетях из-за его большой избыточности и невысоких диагностических способностей.

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

  Циклический избыточный контроль (Cyclic Redundancy Check, CRC) является в настоящее время наиболее популярным методом контроля в вычислительных сетях (и не только в сетях, например, этот метод широко применяется при записи данных на диски и дискеты).

  Метод основан на рассмотрении исходных данных в виде одного многоразрядного двоичного числа. Например, кадр стандарта Ethernet, состоящий из 1024 байт, будет рассматриваться как одно число, состоящее из 8192 бит. В качестве контрольной информации рассматривается остаток от деления этого числа на известный делитель R. Обычно в качестве делителя выбирается семнадцатиразрядное или тридцати трехразрядное число, чтобы остаток от деления имел длину 16 разрядов (2 байт) или 32 разряда (4 байт).

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

  Этот метод обладает более высокой вычислительной сложностью, но его диагностические возможности гораздо выше, чем у методов контроля по паритету. Метод CRC обнаруживает все одиночные ошибки, двойные ошибки и ошибки в нечетном числе бит. Метод обладает также невысокой степенью избыточности. Например, для кадра Ethernet размером в 1024 байт контрольная информация длиной в 4 байт составляет только 0,4 %.

  5.6. Методы восстановления искаженных и потерянных кадров

  
  

  Краткое изложение...
  

  Используются протоколы повторной передачи кадров.
  Цель: надежная доставка кадров по ненадежному каналу.
  Реализован механизм автоматического запроса повторной передачи (ARQ -Automatic Repeat Quest).
  В качестве характеристики протоколов выступают - корректность и эффективность .
  Кадры, не принятые корректно, посылаются повторно.
  Отправитель информируется об ошибках передачи с помощью таймера и подтверждений.
  Протоколы повторной передачи корректны, если они позволяют получателю принять точно одну правильную копию каждого кадра.
  Эффективность протокола повторной передачи равна средней скорости успешной доставки кадров (R эф),
  деленной на скорость передачи в канале.

  Протокол с остановкой и ожиданием (SWP - Stop-and-Wait Protocol). Данный протокол реализует алгоритм РОС-ОЖ.
  

  

  

  Алгоритм работы протокола SWP Эффективность протокола SWP равна
  
  где t - время передачи кадра;
  p - вероятность того, что подтверждение поступает правильно.

  Протокол повторной передачи с возвращением на N кадров назад. (GBN - Go Back N).
  

  

  
  Протокол повторной передачи с выборочным (селективным) повторением. (SRP - Selective Repeat Protocol).
  

  

  Подробное изложение...
  

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

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

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

  Существуют два подхода к организации процесса обмена квитанциями: с простоями и с организацией «окна».

  Метод с простоями (Idle Source) требует, чтобы источник, пославший кадр, ожидал получения квитанции (положительной или отрицательной) от приемника и только после этого посылал следующий кадр (или повторял искаженный).

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

  

  Рис. 5.4. Методы восстановления искаженных и потерянных кадров

  Второй метод называется методом «скользящего окна» (sliding window) . В этом методе для повышения коэффициента использования линии источнику разрешается передать некоторое количество кадров в непрерывном режиме, то есть в максимально возможном для источника темпе, без получения на эти кадры положительных ответных квитанций. (Далее, где это не искажает существо рассматриваемого вопроса, положительные квитанции для краткости будут называться просто «квитанциями».) Количество кадров, которые разрешается передавать таким образом, называется размером окна. Рисунок 5.4, б иллюстрирует данный метод для окна размером в W кадров.

  В начальный момент, когда еще не послано ни одного кадра, окно определяет диапазон кадров с номерами от 1 до W включительно. Источник начинает передавать кадры и получать в ответ квитанции. Для простоты предположим, что квитанции поступают в той же последовательности, что и кадры, которым они соответствуют. В момент t 1 при получении первой квитанции К 1 окно сдвигается на одну позицию, определяя новый диапазон от 2 до (W+1).

  Процессы отправки кадров и получения квитанций идут достаточно независимо друг от друга. Рассмотрим произвольный момент времени t n , когда источник получил квитанцию на кадр с номером n. Окно сдвинулось вправо и определило диапазон разрешенных к передаче кадров от (n+1) до (W+n). Все множество кадров, выходящих из источника, можно разделить на перечисленные ниже группы (рис. 5.4, б).

  Кадры с номерами от 1 до n уже были отправлены и квитанции на них получены, то есть они находятся за пределами окна слева.

  Кадры, начиная с номера (п+1) и кончая номером (W+n) , находятся в пределах окна и потому могут быть отправлены не дожидаясь прихода какой-либо квитанции. Этот диапазон может быть разделен еще на два поддиапазона:

  • кадры с номерами от (n+1) до m, которые уже отправлены, но квитанции на них еще не получены;

    кадры с номерами от m до (W+n), которые пока не отправлены, хотя запрета на это нет.

  Все кадры с номерами, большими или равными (W+n) , находятся за пределами окна справа и поэтому пока не могут быть отправлены.

  Перемещение окна вдоль последовательности номеров кадров показано на рис. 5.4, в. Здесь t 0 - исходный момент, t 1 и t n - моменты прихода квитанций на первый и n-й кадр соответственно. Каждый раз, когда приходит квитанция, окно сдвигается, но его размер при этом не меняется и остается равным W. Заметим, что хотя в данном примере размер окна в процессе передачи остается постоянным, в реальных протоколах (например, TCP) можно встретить варианты данного алгоритма с изменяющимся размером окна.

  Итак , при отправке кадра с номером n источнику разрешается передать еще W-1 кадров до получения квитанции на кадр n, так что в сеть последним уйдет кадр с номером (W+n). Если же за это время квитанция на кадр n так и не пришла, то процесс передачи приостанавливается, и по истечении некоторого тайм-аута кадр n (или квитанция на него) считается утерянным, и он передается снова.

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

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

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

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

  Метод скользящего окна реализован во многих протоколах: LLC2, LAP-B, X.25, TCP, Novell NCP Burst Mode.

  Метод с простоями является частным случаем метода скользящего окна, когда размер окна равен единице.

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

  Выбор тайм-аута зависит не от надежности сети, а от задержек передачи кадров сетью.

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

  5.7. Компрессия данных

  
  

  Компрессия (сжатие) данных применяется для сокращения времени их передачи. Так как на компрессию данных передающая сторона тратит дополнительное время, к которому нужно еще прибавить аналогичные затраты времени на декомпрессию этих данных принимающей стороной, то выгоды от сокращения времени на передачу сжатых данных обычно бывают заметны только для низкоскоростных каналов. Этот порог скорости для современной аппаратуры составляет около 64 Кбит/с. Многие программные и аппаратные средства сети способны выполнять динамическую компрессию данных в отличие от статической, когда данные предварительно компрессируются (например, с помощью популярных архиваторов типа WinZip), а уже затем отсылаются в сеть.

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

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

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

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

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

  При статистическом кодировании коды выбираются таким образом, чтобы при анализе последовательности бит можно было бы однозначно определить соответствие определенной порции бит тому или иному символу или же запрещенной комбинации бит. Если данная последовательность бит представляет собой запрещенную комбинацию, то необходимо к ней добавить еще один бит и повторить анализ. Например, если при неравномерном кодировании для наиболее часто встречающегося символа «Р» выбран код 1, состоящий из одного бита, то значение 0 однобитного кода будет запрещенным. Иначе мы сможем закодировать только два символа. Для другого часто встречающегося символа «О» можно использовать код 01, а код 00 оставить как запрещенный. Тогда для символа «А» можно выбрать код 001, для символа «П» - код 0001 и т. п.

  Вообще, неравномерное кодирование наиболее эффективно, когда неравномерность распределения частот передаваемых символов достаточна велика, как при передаче длинных текстовых строк. Напротив, при передаче двоичных данных, например кодов программ, оно малоэффективно, так как 8-битовые коды при этом распределены почти равномерно.

  Одним из наиболее распространенных алгоритмов, на основе которых строятся неравномерные коды, является алгоритм Хафмана, позволяющий строить коды автоматически, на основании известных частот символов. Существуют адаптивные модификации метода Хафмана, которые позволяют строить дерево кодов «на ходу», по мере поступления данных от источника.

  Многие модели коммуникационного оборудования, такие как модемы, мосты, коммутаторы и маршрутизаторы, поддерживают протоколы динамической компрессии, позволяющие сократить объем передаваемой информации в 4, а иногда и в 8 раз. В таких случаях говорят, что протокол обеспечивает коэффициент сжатия 1:4 или 1:8. Существуют стандартные протоколы компрессии, например V.42bis, a также большое количество нестандартных, фирменных протоколов. Реальный коэффициент компрессии зависит от типа передаваемых данных, так, графические и текстовые данные обычно сжимаются хорошо, а коды программ - хуже.

  5.8. Протоколы передачи файлов

  
  

  Протокол передачи файлов представляет собой набор правил передачи файлов. В его задачи входит:

  1. исправление возникающих при передаче ошибок,
  2. передача и прием определенных кодов, служащих для орнизации связи (handshaking),
  3. выполнение некоторых функций передачи файлов и прекращения передачи.
     
     
     
     
     
     

     Среди протоколов передачи файлов между ПК одним из первых появился XModem. Разработанный еще в 1977 году Вардом Христенсеном, он широко использовался в справочных службах, вводился в недорогие связные программы для ПК и фактически стал стандартом для связи между ПК с использовнием модемов.

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

     передатчик								приемник (задание тайм-аута на интервал в 10 с)
     								"nak"
     "soh" 01 FE -данные- "xx"				=====>
     								"ack"
     "soh" 02 FD -данные- "xx"				=====>				(помеха в линии связи)
     								"nak"
     "soh" 02 FD -данные- "xx"				=====>
     								"ack"
     "soh" 03 FC -данные- "xx" (знак ack искажен)				=====>
     								"ack"
     "soh" 03 FC -данные- "xx"				=====>
     								"ack"
     "eot"				=====>
     								любой знак кроме "ack"
     "eot"				=====>
     								"ack"
     Передача завершена

     
     

     Передающий ПК начинает передачу файла только после приема от принимающего ПК знака "nak". Принимающий ПК передает этот знак до тех пор, пока не начинается передача файла. Если передано девять знаков "nak", а передача файла не началась, то процесс возобновляется вручную.

     После приема знака "nak" передающий ПК посылает знак начала блока "soh" (start of header), два номера блока (сам номер и его двоичное дополнение по "единицам"), блок данных из 128 байт и контрольную сумму "xx" (блоки нумеруются по модулю 256). Контрольная сумма (1 байт) представляет собой остаток от деления на 255 суммы значений кодов знаков, входящих в блок данных.

     В свою очередь принимающий ПК тоже вычисляет контрольную сумму и сравнивает ее с принятой. Если сравниваемые значения различны или если прошло 10 с и не завершен прием блока, принимающий ПК посылает передатчику знак "nak", означающий запрос на повторную передачу последнего блока. В случае принятия правильного блока приемник передает "ack", а если следующий блок не поступил в течение 10 с, то передача знака "ack" повторяется до тех пор, пока блок не будет правильно принят. После девяти неудачных попыток передачи блока связь прерывается.

     Для исключения повторной передачи одного и того же блока из-за потери подтверждающего сообщения в протоколе используется двукратная передача номера. Принимающий ПК контролирует неповторяемость принятого блока, и если блок ошибочно передан повторно, то он сбрасывается. После успешной передачи всех данных передающий ПК посылает знак завершения "eot" (end of transmission), сообщающий об окончании передачи файла.

     Перерыв в передаче блока свыше 1 с считается разрывом связи.

     Преимуществами данного протокола по сравнению с другими являются:

  4. его доступность для разработчиков программных средств;
  5. простота реализации на языках высокого уровня;
  6. малый объем приемного буфера (256 байт);
  7. возможность передачи не только символьных (коды ASCII), но и исполняеиых файлов (с расширением.COM и.EXE). Последнее возможно вследствии того, что конец файла определяется подсчетом переданных байтов и вместо знака файлового маркера (Ctrl-Z) используется специальный сигнал завершения. Эффективность обнаружения ошибок данным протоколом составляет 99,6% - выше, чем при обычной асинхронной проверке четности (95%).

     К основным недостаткам этого протокола можно отнести:

  8. низкое быстродействие;
  9. большая вероятность необнаруженных ошибок;
  10. необходимость задания имени файла при приеме;
  11. относительно большой объем передаваемой служебной информации.

      Последующие модифакации протокола XModem были направлены на устранение этих и некоторых других его недостанков.

      
      

      В протоколе XModem-CRC передается два проверочных знака, образующих проверочную комбинацию CRC-16, вместо одного знака арифметической контрольной суммы, используемого в исходном протоколе XModem-CRC и в большинстве коммерческих приложений. Проверка CRC-16 гарантирует обнаружение всех одиночных и двойных ошибок, всех нечетных ошибок, всех пакетов ошибок длиной до 16 знаков; 99,9969% 17-битовых пакетов ошибок и 99,9984% более длинных пакетов ошибок.

      В начале соединения вместо знаков "nak", как в протоколе XModem, приемник передает знаки "c". Если передатчик не поддерживает протокол XModem-CRC, он игнорирует эти знаки. Не получив ответа на передачу трех знаков "c", приемник переходит на работу по протоколу XModem и передает знаки "nak".

      
      

      Данный протокол представляет собой модификацию XModem-CRC с блоками длиной 1024 байт. При такой длине блоков значительно снижается влияние задержек в системах с разделением времени, модемах и сетях с коммутацией пакетов. Кроме того, по сравнению с обычным протоколом XModem уменьшается относительная доля заголовка в общем объеме передаваемой информации.

      Для сообщения приемнику об увеличении длины передаваемого блока вместо знака "soh" (01) в его начале ставится знак "stx" (02). Номер блока, передаваемый во втором и третьем байтах, увеличивается на единицу независимо от его длины.

      Передатчик не должен изменять длину блока между 128 и 1024 байт, если не был принят знак "ack" для текущего блока. Игнорирование этого ограничения может привести к необнаружению ошибок.

      При использовании блоков по 1024 байт возможно увеличение длины передаваемого файла до значения, кратного 1024.

      Блоки длиной 1024 байт могут применяться при групповой или одиночной передаче файлов. Для сохранения целостности данных, передаваемых по телефонному каналу, с этим вариантом следует использовать проверку CRC-16.

      
      

      Протокол YModem - это протокол XModem-CRC, в котором реализована групповая передача файлов. Его появление было вызвано необходимостью устранения недостатков протокола XModem.

      Все программы, реализующие протокол YModem, должны выполнять следующие функции:

  12. передачу имени и пути файла в блоке 0 в виде строки знаков кода ASCII, завершающейся знаком "нуль";
  13. их использование на приемном конце файла в качестве имени и пути принятого файла, если иная реализация не оговорена специально;
  14. применение проверки CRC-16 при приеме знаков "c", в противном случае - использование 8-битовой контрольной суммы;
  15. прием любой комбинации из 128- и 1024-байтовых блоков внутри каждого принимаего файла; возможность переключения длины блоков в конце файла (файлов) и/или в случае частых повторных передач;
  16. исключение изменения длины неподтвержденного блока на передающем конце канала;
  17. передачу в конце каждого файла знака "eot" до десяти раз, пока не будет принят знак "ack" (часть спецификации протокола XModem);
  18. обозначение конца сеанса связи нулевым (пустым) именем пути.

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

      Выполнение этих минимальных требований не гарантирует надежной передачи файлов при помехах.

      Расширения протокола XModem и протокол YModem устраняют некоторые недостатки протокола XModem, сохраняя в основном его простоту.

      Как и в случае передачи одного файла, приемник инициирует групповую передачу путем посылки знака "c" (для режма CRC-16).

      Передатчик открывает файл и передает номер 0 блока и последующую информацию.

      Для групповой передачи требуются только имена файлов.

      Для обеспечения совместимости "вверх" все неиспользуемые байты блока 0 должны иметь значение 0.

      Имя файла (возможно с указанием пути) передается как строка кодов ASСII, завершаемая знаком "нуль". Этот формат имени файла используется в функциях, ориентированных на операционную систему MS-DOS, или в функциях fopen библиотеке языка Си. В имя файла не включаются пробелы. Обычно передается только само имя (без префекса справочника). Название привода источника (например, A:, B: и т.д.) не передается. Если в имя файла включен каталог, его название должно ограничиваться знаком "/".

      Обозначение длины файла каждого последующего поля произвольно. Длина файла представлена в блоке как десятичная строка, обозначающая количество байтов в файле. В нее не должны входить знаки CPMEOF (^Z) или другие знаки (garbage characters), используемые для заполнения последнего блока.

      Если передаваемый файл увеличивается во время передачи, параметр "длина файла" должен представлять свое максимально ожидаемое значение или не передаваться вовсе.

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

      Протокол YModem допускает возможность введения других полей заголовка без нарушения совместимости со своими прежними программами. Оставшаяся часть блока устанавливается в 0. Это существенно для сохранения совместимости "вверх".

      Если блок имени файла принят с ошибкой по коду, необходимо запросить повторную передачу. Прием блока с именем файла, успешно открытого для записи, подтверждается знаком "ack". Если файл не может быть открыт для записи, приемник прерывает передачу с помощью знака "can".

      Затем приемник инициирует передачу содержимого файлов в соответствии с протоколом XModem-CRC.

      После того как содержимое файла передано, приемник запрашивает имя следующего файла.

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

      По умолчанию приемник запрашивает CRC-16.

      Протокол YModem поддерживается большинством связных программ общего пользования.

      
      

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

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

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

      При обнаружение ошибки в случае использования протокола YModem-g приемник прерывает передачу, посылая последовательность, состоящую из многих знаков "can".

      Расширение YModem-g протокола YModem позволяет значительно увеличить скорость передачи в каналах с защитой от ошибок (при использовании модемов со встроенным протоколом защиты от ошибок). Это достигается за счет отказа от переспроса принятых с ошибками блоков: при обнаружении ошибки передача файла просто прерывается. Для повышения быстродействия в последующих модификациях протокола XModem (например, в протоколе ZModem) был применен так называемый "оконный" алгоритм, при котором последующие блоки передаются подряд, без ожидания подтверждения правильного приема блока.

      Этот протокол, введенный в большинство связных программ, получил сейчас самое широкое применение. Представляя собой фактически развитие протоколов XModem и YModem, протокол ZModem устраняет их недостатки и, будучи совместимым с ними, имеет ряд преимуществ:

  19. высокое быстродействие благодаря использованию "оконного" алгоритма;
  20. динамическая адаптация к качеству канала связи посредством изменения в широких пределах размера блока;
  21. защита управляющей информации, доступа к передаче и защита от имитации управляющих сигналов;
  22. возможность возобновления прерванной передачи файла с того места, на котором произошло прерывание;
  23. повышенная достоверность передачи благодаря использованию 32-разрядной проверочной комбинации;
  24. возможность оптимального применения как в канале с высокой вероятностью ошибок, так и в каналах, работающих практически без ошибок (в которых уже реализован протокол, исправляющий ошибки).

      Протокол ZModem разрабатывался для следующих областей применения:

  25. работа в сетях с большим временем задержки (по сравнению с временем передачи знака) и малой вероятностью ошибок;
  26. передача с помощью модемов с временным разделением и буферизацией, характеризующихся значительными задержками и быстрым снижением пропускной способности при росте обмена по обратному каналу;
  27. обеспечение прямой связи между двумя модемами при высокой вероятности ошибок в канале.

      Протокол ZModem может быть использован либо самостоятельно, либо в сочетании с защитой от ошибок канального уровня, реализованной протоколами X.25, V.42, MNP, Fastlink и др. В случае сочетания с протоколами канального уровня протокол ZModem обеспечивает обнаружение и исправление ошибок в интерфейсах между средой, в которой исправляется ошибка, и остальной частью канала связи.

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

      Протокол позволяет программно инициировать передачу файлов либо передавать команды и/или модификаторы другим программам. Имена файлов вводятся только один раз. При групповых передачах допускается общее задание файлов (например, "*.txt"). Общее требование: сведение к минимуму количества команд, вводимых с клавиатуры.

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

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

      Передача файлов осуществляется без начального таймаута независимо от того, какая из программ запущена первой, в отличие от протокола XModem, требующего задержки в 10 с.

      С самого начала сеанса по протоколу ZModem вся передаваемая информация защищается циклическим кодом с проверочной комбинацией CRC из 16 или 32 битов. Кроме того, в протоколе реализован механизм защиты информации против сообщений типа "троянский конь", имитирующих разрешенные команды или передачу файлов.

      Хотя протокол ZModem имеет широкий набор возможностей, он не предназначен для замены протоколов канального уровня - таких, как, например, протокол X.25.

      Протокол адаптируется к задержкам сети и систем с временным разделением путем непрерывной передачи данных, продолжающейся до тех пор, пока приемник не прервет передатчик запросом на повторную передачу искаженных данных. Фактически протокол ZModem использует отдельный файл как "окно". Такое упрощение управления буфером исключает переполнение "окна", которому подвержены протоколы MEGAlink, Super Kermit и др.

      ZModem разработан в качестве протокола передачи файлов общего назначения компанией Telenet (США). Его описание и исходная программа Unix rz / sz общедоступны. Лицензирование, торговые марки и ограничение копирования на применение этого протокола и исходной программы Unix rz /sz не распространяются.

      Протокол Kermit, реализованный практически во всех связных программах, предназначен в основном для передачи файлов между ЭВМ разных типов, включая большие и мини ЭВМ. Он оптимизирован для работы как при сильных помехах, так и при больших задержках сигнала. В отличие от протоколов XModem и YModem в нем используются пакеты переменной длины с максимальным значением 94 байт. Аналогично протоколу YModem протокол Kermit обеспечивает групповую передачу файлов.

      Наряду со стандартным протоколом Kermit в ряде связных программ реализован более эффективный протокол Super Kermit, предусматривающий для уменьшения задержек при передаче переменное "окно" передачи, в котором может содержаться от 1 до 32 пакетов. На приемном конце канала осуществляется обнаружение ошибок, но повторная передача не запрашивается до тех пор, пока не будут переданы все пакеты "окна". Кроме того, в протоколе реализован простой метод сжатия данных, также позволяющий сократить время передачи. Если на противоположном конце канала поддерживается протокол Kermit, то происходит автоматическое переключение на работу с ним.

      
      

      5.9. Протоколы сжатия данных

      
      

      Протокол V.42bis.

      Этот протокол обеспечивает коэффициент сжатия 4:1, протокол V.42bis основан на алгоритме Лемпела-Зива-Уэлча (LZW-алгоритм).

      Рассмотрим работу кодера LZW на примере трёхсимвольного алгоритма (а, б, в), а - код 1, б - код 2, в - код 3.

      Символ	wK	w	Выход	Строка, добавляемая в словарь
      	аб		код "а"=1	аб - код4
      	ба		код "б"=2	ба - код5
      	аб	аб
      	абв		код "аб"=4	абв - код6
      	вб		код "в"=3	вб - код7
      	ба	ба
      	баб		код "ба"=5	баб - код8
      	ба	ба
      	баб	баб
      	баба		код " баб " =8	баба - код9
      	аа		код "а"=1	аа - код10
      	аа	аа
      	ааа		код "аа"=10	ааа - код11
      	аа	аа
      	ааа	ааа
      	аааа		код "ааа"=11	аааа - код12

      Протокол V.44.

      Коэффициент сжатия 6:1. Эффективен при работе с гипертекстом. В основе протокола лежит модификация алгоритма Лемпела-Зива.

      Выводы

      Основной задачей протоколов канального уровня является доставка кадра узлу назначения в сети определенной технологии и достаточно простой топологии.

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

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

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

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

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

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

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

      Для повышения полезной скорости передачи данных в сетях применяется динамическая компрессия данных на основе различных алгоритмов. Коэффициент сжатия зависит от типа данных и применяемого алгоритма и может колебаться в пределах от 1:2 до 1:8.

Канальный уровень (data link layer) обеспечивает прозрачность соединения для сетевого уровня. Для этого он предлагает ему следующие услуги:

Установление логического соединения между взаимодействующими узлами;

Согласование в рамках соединения скоростей передатчика и приемника информации;

Обеспечение надежной передачи, обнаружение и коррекция ошибок.

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

В сетях, построенных на основе разделяемой среды, физический уровень выполняет еще одну функцию - проверяет доступность разделяемой среды. Эту функцию иногда выделяют в отдельный подуровень управления доступом к среде (Medium Access Control, MAC).

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

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

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

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

Если разделяемая среда освободилась (когда она не используется, то такая проверка, конечно, пропускается), кадр передается средствами физического уровня в сеть, проходит по каналу связи и поступает в виде последовательности битов в распоряжение физического уровня узла назначения. Этот уровень в свою очередь передает полученные биты «наверх» канальному уровню своего узла.

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

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