Ускоренная повторная передача

Одним из недостатков механизма повторной передачи с интервалами ожидания является то, что интервалы ожидания часто оказываются относительно долгими. При потере пакета передающая сторона вынуждена ждать истечения интервала ожидания для того, чтобы осуществить повторную передачу, тем самым увеличивая общую задержку. Здесь на помощь приходит механизм дублирования подтверждений, позволяющий передающей стороне обнаруживать потери пакетов до истечения интервала ожидания. Дублирующее подтверждение — это копия положительной квитанции предыдущего сегмента, отправляемая в ответ на получение следующего сегмента, если порядковый номер последнего превышает ожидаемый. Чтобы понять реакцию передающей стороны на появление дублирующих подтверждений, сначала необходимо выяснить причину, побуждающую к использованию такого механизма. В табл. 3.3 приведены основные правила генерации квитанций принимающей стороной TCP. При получении сегмента, порядковый номер которого превышает ожидаемый, протокол регистрирует наличие недостающего сегмента. Появление недостающих сегментов может быть обусловлено потерей сегментов или нарушением порядка их следования при передаче по сети. Поскольку в TCP не поддерживается отрицательное квитирование, принимающая сторона не может явно указать на необходимость повторной передачи недостающих данных. Вместо этого она повторно отсылает подтверждение для последнего успешно принятого байта (обратите внимание на то, что таблица иллюстрирует ситуацию, когда принимающая сторона не игнорирует сегменты, нарушающие очередность).

33t.png

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

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

событие: получена квитанция со значением поля подтверждения у
if (у > SendBase) {
Sendbase=y
if (есть хотя бы 1 неподтвержденный сегмент)
запустить таймер
}
else /* дублирующее подтверждение для уже квитированного сегмента */
увеличить на 1 число дублирующих подтверждений сегмента у
if (число дублирующих АСК для у == 3) {
/* ускоренная повторная передача */
повторно передать сегмент с порядковым номером у
}
break;

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

Данная статья "Ускоренная повторная передача" размещена на сайте Компьютерные сети и многоуровневая архитектура интернета (conlex.kz) в ознакомительных целях.

Уточнения, корректировки и обсуждения статьи "Ускоренная повторная передача" - под данным текстом, в комментариях.

Ответственность, за все изменения, внесённые в систему по советам данной статьи, Вы берёте на себя.

Копирование статьи "Ускоренная повторная передача", без указания ссылки на сайт первоисточника Компьютерные сети и многоуровневая архитектура интернета (conlex.kz), строго запрещено.

Добавить комментарий

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