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

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

U(перед) = (L/R) / (RTT + L/R) = 0,008/30,008 = 0,00027.

Другими словами, передающая сторона активна в течение лишь 0,0027 % общего времени. Кроме того, наши расчеты говорят о том, что передача данных ведется со скоростью 1000 байт за 30,008 мс, что составляет 267 Кбит/с — величину, в тысячи раз меньшую скорости, обеспечиваемой каналом связи. Представьте, каким разочарованием для администратора сети было бы закупить дорогостоящую линию связи и получить столь низкое качество обслуживания! Этот пример наглядно демонстрирует, каким образом сетевые протоколы могут «тормозить» передачу, обеспечиваемую аппаратно. Обратите внимание на то, что мы не учли время, затрачиваемое на обработку данных протоколами более низких уровней передающей и принимающей сторон, а также задержки обработки и ожидания, которые могли иметь место при передаче пакетов. Включение этих факторов в модель показало бы еще большую несостоятельность нашего протокола с точки зрения полезности.

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

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

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

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

3. Протокол скользящего окна

В протоколах, использующих метод возвращения на N шагов назад (Go-Back-N, GBN), передающая сторона может посылать последовательности пакетов, не ожидая квитанций, при этом максимальная длина последовательности ограничена некоторым числом N. На рис. 7.12 представлена схема определения диапазона порядковых номеров. Если base — порядковый номер самого «старого» неподтвержденного пакета, a nextseqnum — наименьший из «свободных» порядковых номеров (то есть номер, который будет присвоен следующему посылаемому пакету), то полный диапазон порядковых номеров можно разделить на четыре части. Номера в диапазоне от 0 до base-1 назначены переданным ранее пакетам, для которых уже получены квитанции. Номера от base до nextseqnum-1 также относятся к переданным пакетам, однако для этих пакетов квитанции еще не получены. Номера от nextseqnum до base+N-1 могут быть назначены пакетам, которые необходимо сформировать и отправить сразу при поступлении новых данных от прикладного уровня. Номера, превышающие значение base+N, нельзя использовать до тех пор, пока не будет получена квитанция для текущего пакета, то есть пакета с порядковым номером base.

Рис. 7.12 Диапазон порядковых номеров с точки зрения передающей стороны

Как показано на рисунке, диапазон порядковых номеров для пакетов, которые могут быть переданы без ожидания квитанций, можно рассматривать в виде «окна» размером N, лежащего внутри множества порядковых номеров. В процессе выполнения протокола это окно «движется» в сторону увеличения порядковых номеров. Такое представление определило терминологию, в соответствии с которой значение N называют размером окна, а протокол GBN — протоколом скользящего окна. Вероятно, у вас возникает вопрос: для чего нужно ограничивать число пакетов, передаваемых без ожидания подтверждения, размером окна ЛГ? В следующем разделе этой главы мы увидим, что одной из причин является необходимость контролировать передаваемый поток данных. Другая причина будет раскрыта в разделе «Контроль перегрузок в ТСР», где мы займемся изучением механизма контроля перегрузки, реализованного в протоколе TCP.

На практике порядковый номер пакета хранится в одном из полей заголовка, имеющем фиксированную длину. Если k — число битов этого поля, то диапазоном порядковых номеров является [0,2k - 1]. Поскольку множество порядковых номеров конечно, все арифметические операции с ними производятся по модулю 2k (другими словами, множество порядковых номеров можно представить в виде кольца, в котором числом, следующим за 2k – 1, является 0). Возвращаясь к протоколу rdt 3.0, отметим, что разрядность его порядковых номеров равна 1, а диапазон — [0,1]. В конце этой главы перечислены несколько проблем, порождаемых ограниченностью множества порядковых номеров. Как мы увидим позже, в протоколе TCP порядковые номера имеют разрядность 32 и предназначены для подсчета байтов (вместо пакетов) в байтовом потоке.

На рис. 7.13 и 7.14 представлены расширенные модели конечных автоматов, описывающие передающую и принимающую стороны GBN-протокола с механизмом квитирования без использования отрицательных квитанций. Мы назвали эти модели расширенными, поскольку они включают в себя переменные величины base и nextseqnum (напоминающие переменные в языках программирования), а также различные операции и другие действия с участием этих переменных. Более того, спецификация расширенной модели конечных автоматов очень напоминает спецификацию языка программирования.

Передающая сторона GBN-протокола должна реагировать на три вида событий.

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

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

Рис. 7.13 Расширенная модель конечных автоматов передающей стороны GBN-протокола

Рис. 7.14 Расширенная модель конечных автоматов принимающей стороны GBN-протокола

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

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

Действия, предпринимаемые принимающей стороной GBN-протокола, также не отличаются сложностью. Если доставка пакета с порядковым номером п произошла корректно и без нарушения очередности (то есть последние данные, переданные верхнему уровню, относятся к пакету с порядковым номером п - 1), то принимающая сторона генерирует подтверждение и передает новые данные верхнему уровню. В противном случае принятый пакет игнорируется, а подтверждение генерируется для последнего корректно обработанного пакета. Поскольку пакеты передаются верхнему уровню по одному, передача пакета k означает, что все пакеты с порядковыми номерами, меньшими k, уже переданы верхнему уровню. Таким образом, применение механизма группового квитирования в GBN-протоколах является весьма естественным.

Наш GBN-протокол игнорирует пакеты, полученные с нарушением порядка следования. Несмотря на то что удаление пакета, не содержащего ошибок (а лишь нарушившего порядок следования данных), кажется нерациональным и неэкономным, существуют причины, обусловливающие это удаление. Мы знаем о том, что приемная сторона должна обеспечивать передачу данных верхнему уровню в правильном порядке. Предположим, что вместо пакета с порядковым номером п приемная сторона получает пакет с номером п + 1. Поскольку мгновенная доставка такого пакета верхнему уровню невозможна, необходимо организовать промежуточное хранение пакета п + 1 до момента, когда будет принят пакет п, а его данные переданы верхнему уровню. В случае потери пакета п в соответствии с GBN-npo-токолом организуется повторная передача как пакета п, так и пакета п + 1.