Настройка сетей Microsoft дома и в офисе. Учебный курс

Сергеев Александр

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

Протокол TCP

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

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

В процессе сбора данных, требуемых для работы адаптивного алгоритма, экземпляр протокола TCP фиксирует время отправки каждого сегмента, а также время получения сигналов подтверждения приема данных, находящихся в этих сегментах. Затем определяется разность этих значений, соответствующая времени доставки каждого пакета. Этот алгоритм также называется оценкой полного времени доставки пакета. После выполнения очередной оценки экземпляр протокола TCP пересчитывает среднее время доставки для данного соединения. При этом также оценивается средневзвешенная величина полного времени доставки пакетов (RTT, Round Trip Time).

В процессе отправки пакета экземпляр протокола TCP вычисляет величину задержки в виде функции от предполагаемой величины полного времени доставки.

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

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

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

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

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

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

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