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

Таблица 8.1. Основные правила генерации квитанций принимающей стороны ТСР (RFC 1122, RFC 2581)

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

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

событие: получена квитанция со значением поля подтверждения у

if (у > SendBase) {

Sendbase=y

if (есть хотя бы 1 неподтвержденный сегмент)

запустить таймер

}

else /* дублирующее подтверждение для уже квитированного сегмента */

увеличить на 1 число дублирующих подтверждений сегмента у

if (число дублирующих АСК для у == 3) {

/* ускоренная повторная передача */

повторно передать сегмент с порядковым номером у

}

break;

Возвращение на N шагов назад или выборочное повторение

Напоследок мы зададимся вопросом, к каким протоколам относится TCP: к GBN-или к SR-протоколам? Как мы знаем, в TCP используется общее квитирование, и для неискаженных сегментов, полученных с нарушением порядка следования, не формируются отдельные квитанции. Таким образом, передающей стороне TCP необходимо хранить лишь наименьший порядковый номер отправленного неподтвержденного байта SendBase и порядковый номер следующего передаваемого байта NextSeqNum. Это создает видимость сходства TCP с GBN-протокола-ми; тем не менее между ними существуют важные различия. Первое различие заключается в том, что в реализациях TCP, как правило, предусмотрена буферизация пакетов, полученных с нарушением порядка следования. Далее, представим себе, что происходит, когда передающая сторона посылает последовательность сегментов 1, 2, N и все сегменты успешно принимаются приемной стороной в правильном порядке. Пусть квитанция для одного из сегментов с номером n < Утеряется, но оставшиеся N - 1 квитанций достигают передающей стороны до истечения интервала ожидания. В этом случае GBN-протокол осуществил бы повторную передачу не только пакета п, но и всех последующих пакетов (п + 1, я + 2,N). TCP, напротив, в худшем случае передает единственный сегмент п; более того, если квитанция для сегмента n + 1 принимается передающей стороной до истечения интервала ожидания, повторная передача сегмента п вообще не производится.

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

5.  Контроль потока

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

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

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

□ LastByteRead — номер последнего байта потока данных, считанного из буфера прикладным процессом хоста В;

□ LastByteRcvd — номер последнего байта потока данных, полученного от передающей стороны и помещенного в буфер.

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

LastByteRcvd – LastByteRead <= RcvBuffer.

Значение окна приема RcvWindow равно объему свободного места в буфере:

RcvWindow = RcvBuffer – [LastByteRcvd - LastByteRead].

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

Рис. 8.9 Окно приема (RcvWindow) и приемный буфер (RcvBuffer)

Каким образом соединение использует переменную RcvWindow для реализации службы контроля потока? Хост В «говорит» хосту А о том, сколько свободного места имеется в его приемном буфере, помещая значение переменной RcvWindow в поле окна приема каждого сегмента, отправляемого хосту А. Начальное значение RcvWindow равно RcvBuffer. Для того чтобы этот механизм работал, необходимо поддерживать на хосте В несколько переменных, характеризующих данное ТСР-соединение.

Хост А поддерживает две переменные, LastByteSent и LastByteAcked, хранящие номера последнего отправленного и последнего квитированного байтов соответственно. Разность LastByteSent – LastByteAcked представляет размер неподтвержденных данных, переданных от хоста А хосту В. Поддерживая значение этой разности меньшим, чем RcvWindow, хост А может гарантировать, что приемный буфер хоста В не переполнится. Таким образом, на протяжении жизни соединения хост А должен соблюдать неравенство:

LastByteSent – LastByteAcked <= RcvWindow

Приведенной схеме присуща небольшая проблема. Предположим, что приемный буфер хоста В оказался заполненным, то есть значение RcvWindow стало равно 0. Возможно, что в этот момент хост В не имеет данных для передачи хосту А. Обратите внимание на то, что считывание приложением данных из буфера, приводящее к изменению значения RcvWindow, не влечет за собой генерацию пакета с новым значением RcvWindow. Напротив, TCP отсылает RcvWindow хосту А только вместе с данными или квитанциями. Таким образом, хост А своевременно не получит сведений об освободившемся пространстве буфера и не сможет осуществлять дальнейшую передачу данных. Чтобы решить эту проблему, спецификация TCP предусматривает периодическую генерацию хостом А сегментов, содержащих один байт данных, если окно приема хоста В имеет нулевое значение. Эти сегменты квитируются принимающей стороной, и при освобождении места в буфере ненулевое значение RcvWindow отправляется вместе с одной из квитанций.

Функционирование окна приема протокола TCP наглядно проиллюстрировано с помощью Java-апплета, находящегося на нашем сайте http://www. /kurose-ross.

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

Управление сегментами

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

Рис. 8.10 Обмен сегментами при тройном рукопожатии в протоколе ТСР

1. Клиентская сторона TCP отсылает серверной стороне специальный сегмент, не содержащий данных. Флаг SYN, находящийся в заголовке этого сегмента (см. рис. 3.26), установлен в 1, поэтому данный сегмент часто называют SYN-сегментом. Клиентская сторона устанавливает начальный порядковый номер (client_isn) и помещает его в поле порядкового номера SYN-сегмента. SYN-сегмент заключается в IP-дейтаграмму и отправляется серверу.