Учебно-методическии комплекс дисциплины «Компьютерные сети» для специальности 6М011100 — «Информатика» (стр. 28 )

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

В этом разделе мы займемся созданием клиентской и серверной сторон протокола надежной передачи данных, постепенно усложняя модель капали передачи. Интерфейс будущего протокола приведен на рис. 7.1, б. Передающая сторона вызывается с расположенного выше уровня методом rdt_send(). Здесь rtd является аббревиатурой от reliable data transfer (надежная передача данных), a _send указывает на передающую сторону протокола (вообще говоря, первым шагом в создании протокола является выбор для него подходящего имени). На принимающей стороне при появлении нового пакета выполняется метод rdt_rcv(), а метод deliver_data() передает данные прикладному уровню. Для обозначения единицы обмена мы далее будем использовать термин «пакет» вместо ставшего привычным термина «сегмент». Мы выходим за пределы Интернета и рассматриваем компьютерные сети в целом, поэтому использование общей терминологии в данном случае более предпочтительно.

Рис. 7.1 Надежная передача данных: а - модель обслуживания; б-реализация модели обслуживания

На этой лекции мы ограничимся лишь однонаправленной, или полудуплексной, передачей данных, то есть передачей от источника к приемнику. Двунаправленная, или дуплексная, передача концептуально не сложнее, однако делает описание весьма утомительным. Несмотря на свое название, однонаправленная передача предусматривает движение пакетов в обоих направлениях, как и показано на рис. 7.1. Мы убедимся в том, что принимающей и передающей сторонам необходимо, кроме данных, обмениваться также различной управляющей информацией. Передача пакетов сторонами протокола друг другу будет производиться с помощью метода udt_send(), где udt означает unreliable data transfer (ненадежная передача данных).

Надежная передача данных по абсолютно надежному каналу

Сначала рассмотрим простейший случай, когда канал, по которому передаются данные, является абсолютно надежным. Протокол rdt 1.0, обеспечивающий передачу по такому каналу, также является тривиальным. На рис. 7.2 приведена схема конечных автоматов, описывающая этот протокол. Фрагмент а соответствует передающей стороне, фрагмент б — принимающей. При описании протокола важным является наличие двух моделей конечных автоматов, соответствующих каждой из его сторон. В данном случае оба автомата имеют единственное состояние. Стрелки на схемах обозначают переходы между состояниями автомата; поскольку автоматы имеют единственное состояние, переход возможен только в то же состояние. Ниже мы разработаем более сложные модели. Событие, вызывающее переход, указывается над горизонтальной чертой возле стрелки, а действие, предпринимаемое при наступлении этого события, — под горизонтальной чертой. Отсутствие события или ответного действия явно обозначается символом «?». Пунктирная стрелка указывает на начальное состояние автомата. В более сложных моделях, имеющих несколько состояний, определение начального состояния является важным.

Передающая сторона протокола принимает данные от верхнего уровня при помощи метода rdt_send(data), методом make_pkt(data) создает пакет с данными и отправляет созданный пакет в канал. На практике событие rdt_send(data) является результатом вызова процедуры rdt_send(data) прикладной программой.

На приемной стороне получение пакета rdt от протокола сетевого уровня происходит при наступлении события rdt_rcv(packet). Далее данные пакета извлекаются при помощи метода extract(packet, data), а метод dеLiver_data(data) передает данные приложению. На практике событие rdt_rcv(packet) является результатом вызова процедуры rdt_rcv() протоколом нижнего уровня.

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

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

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

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

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

Для разрешения проблем искажения битов в ARQ-протоколах используются три дополнительных механизма.

□ Обнаружение ошибок. Как следует из названия, данный механизм позволяет определять наличие искаженных битов в принятых данных. В предыдущем разделе было показано, что протокол UDP использует для этой цели значение контрольной суммы. Подробное рассмотрение методов обнаружения и исправления ошибок приводится в главе 5; сейчас нам необходимо знать лишь о том, что эти методы основаны на передаче специальных дополнительных битов, не входящих в информационную часть пакета. Эти биты будут помещены в поле контрольной суммы протокола rdt 2.0.

□ Обратная связь с передающей стороной. Поскольку приемная и передающая стороны находятся на разных оконечных системах, возможно, разделенных тысячами километров, единственный способ уведомить передающую сторону о результате передачи пакетов заключается в организации обратной связи, исходящей от принимающей стороны. Обратная связь, как и в примере с телефонным сообщением, заключается в посылке положительных (АСК) или отрицательных (NAK) квитанций. Минимальная длина квитанции составляет 1 бит, поскольку двух различных значений (0 и 1) достаточно, чтобы указать исход передачи.

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

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

Автомат передающей стороны имеет два состояния. Состояние а соответствует ожиданию передачи данных от верхнего уровня. При наступлении события rdt_send(data) передающая сторона создает пакет sndpkt, включающий данные и поле контрольной суммы (например, вычисляемой по аналогии с протоколом UDP, как описано в предыдущем разделе), и отсылает его приемной стороне методом udt_send(sndpkt). Состояние б соответствует ожиданию квитанции от приемной стороны. В случае получения квитанции АСК, то есть наступления события rdt_rcv(rcvpkt) && isACK (rcvpkt), передающая сторона переходит в состояние ожидания данных от верхнего уровня. Если квитанция оказывается отрицательной (NAK), происходит повторная передача пакета и ожидание ее результата (квитанции). Важной особенностью передающей стороны является то, что, находясь в состоянии ожидания квитанции, она не может принимать данные от верхнего уровня; прием новой порции данных возможен только после получения положительной квитанции для текущего пакета. Таким образом, безошибочная передача предыдущего пакета является необходимым условием для начала передачи следующего пакета. Протоколы, функционирующие подобным образом, называют протоколами с ожиданием подтверждений.

Принимающая сторона rdt 2.0 по-прежнему описывается единственным состоянием. При получении пакета генерируется квитанция АСК или NAK в зависимости от того, содержит принятый пакет ошибки или нет. Приему пакета, содержащего ошибки, соответствует событие rdt_rcv(rcvpkt) && corrupt(rcvpkt).

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

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

□ Вернемся к примеру с телефонным сообщением и представим себе, как два человека могут решить подобную проблему. Если передающий абонент не расслышал фразу «Да!» или «Повтори это еще раз!», он может обратиться к принимающему абоненту с фразой «Что ты сказал?», являющейся новым типом пакета в протоколе. С другой стороны, как поступить, если и она не будет расслышана? Не понимая, является ли эта фраза новым предложением, принимающий, вероятно, ответит фразой «Что ты сказал?»; в свою очередь, она также может быть не расслышана. Очевидно, что описанный способ решения проблемы является весьма громоздким и ненадежным.