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

Рассмотрим другую ситуацию. Пусть хост А получил от хоста В два сегмента, в первом из которых содержатся байты с номерами от 0 до 535, а во втором — байты с номерами от 900 до 1000. Это означает, что по какой-либо причине байты с номерами от 536 до 899 не были получены хостом А. В этом случае хост А ожидает появления отсутствующих байтов и в поле номера подтверждения своего сегмента помещает число 536. Поскольку TCP квитирует принятые данные до первого отсутствующего байта, говорят, что он поддерживает общее квитирование.

Последний пример демонстрирует очень важный аспект функционирования протокола TCP. Третий сегмент (содержащий байты 900-1000) принят хостом А раньше, чем второй (содержащий байты 536-899), то есть с нарушением порядка следования данных. Возникает вопрос: как протокол TCP реагирует на нарушение порядка? Оказывается, что спецификация протокола предоставляет программистам, реализующим TCP, полную свободу в разрешении этого вопроса. Тем не менее выделяются два основных подхода: принимающая сторона может либо немедленно проигнорировать сегменты, нарушающие порядок следования данных, либо сохранять принятые сегменты до тех пор, пока недостающие данные не будут получены. Первый подход позволяет упростить программирование, в то время как второй повышает эффективность использования линий связи.

На рис. 8.3 первым порядковым номером является 0, однако на практике стороны протокола TCP выбирают начальный номер случайным образом. Это объясняется необходимостью минимизировать вероятность нахождения в сети сегмента, который сформирован другим (уже закрытым) TCP-соединением между этими же двумя хостами, но который может быть по ошибке отнесен к существующему TCP-соединению. Заметим, что существующее соединение может использовать те же номера портов, что и предыдущее.

Telnet — пример на тему порядковых номеров и номеров подтверждения

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

Предположим, что хост А инициирует Telnet-сеанс с хостом В. Это означает, что А будет играть роль клиента, а В — сервера. Каждый символ, введенный пользователем клиентской стороны, передается удаленному хосту; последний отсылает обратно копии символов, которые отображаются на экране пользователя. Это «обратное эхо» позволяет убедиться в том, что вводимые символы успешно принимаются сервером. Таким образом, введенные символы проходят двойной путь между хостами перед тем, как отобразиться на экране.

Предположим, что пользователь вводит единственный символ «С», и посмотрим, какими TCP-сегментами обмениваются клиент и сервер в этом случае. На рис. 8.4 показано, что начальными порядковыми номерами клиента и сервера являются 42 и 79 соответственно. Как вы помните, порядковый номер ТСР-сегмента определяется как порядковый номер первого байта его поля данных. Таким образом, первый переданный клиентом сегмент будет иметь номер 42, а первый сегмент, переданный сервером, — 79. Далее, вспомним о том, что номер подтверждения — это порядковый номер байта данных, которого ожидает хост. После того как ТСР-со-единение установлено, клиент будет ожидать получения байта с номером 79, а сервер — байта с номером 42.

Рис. 8.4 Порядковые номера и номера подтверждений в простом Telnet-приложении, работающем поверх протокола ТСР

Как видно из рисунка, в рассматриваемом нами случае между хостами передаются три сегмента. Первый сегмент посылается клиентом и содержит в своем поле данных ASCII-код символа «С», а в поле порядкового номера — число 42. Поскольку к моменту отправки сегмента клиентом не получено никаких данных от сервера, поле номера подтверждения будет содержать число 79.

Второй сегмент передается от сервера к клиенту и содержит две информационные составляющие. Во-первых, он квитирует данные, полученные от клиента: число 43 в поле номера подтверждения говорит о том, что байты с номерами до 42 приняты сервером успешно и ожидается байт с номером 43. Во-вторых, сегмент возвращает символ «С» клиенту, поэтому ASCII-код этого символа заносится в поле данных. Порядковый номер сегмента равен 79, поскольку он является первым сегментом, посылаемым клиентом. Обратите внимание на то, что квитанции для данных, передаваемых от клиента к серверу, отправляются вместе с данными, передаваемыми от сервера к клиенту. Подобные квитанции называют вложенными.

Наконец, третий сегмент вновь передается от клиента к серверу. Он необходим лишь для квитирования данных, посланных сервером в предыдущем сегменте (ASCII-кода символа «С»). Поле данных третьего сегмента оказывается пустым (квитанция не является «вложенной» в том смысле, что она не передается вместе с данными). Поскольку байт с номером 79 был успешно принят клиентом, последний ожидает появления байта с номером 80 и записывает число 80 в поле номера подтверждения. Кроме того, сегмент имеет порядковый номер 43. Наличие порядкового номера на первый взгляд кажется лишним (сегмент не несет никаких данных), однако, будучи обязательной частью сегмента, поле порядкового номера всегда должно содержать какое-либо значение.

Время оборота и интервал ожидания

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

Оценка времени оборота

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

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

EstimatedRTT = (1 – а) х EstimatedRTT + ах SampleRTT.

Подобная запись похожа на оператор языка программирования: новое значение EstimatedRTT вычисляется с использованием старого значения и значения SampleRTT. Величину а рекомендуется (RFC 2988) принимать равной 0,125 (то есть 1/8); при этом формула принимает вид

EstimatedRTT = 0,875 х EstimatedRTT + 0,125 х SampleRTT

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

Термин «экспоненциальное» означает, что вес каждого значения SampleRTT экспоненциально убывает с появлением новых значений. В упражнениях, приведенных в конце главы, вам будет предложено извлечь экспоненциальный член из формулы EstimatedRTT.

На рис. 8.5 показаны значения SampleRTT и EstimatedRTT для TCP-соединения между хостами gaia. cs. umass. edu в штате Массачусетс и fantasia. eurecom. fr на юге Франции при а = 0,125. Как видно, график EstimatedRTT значительно сглажен по сравнению с графиком SampleRTT.

Рис. 8.5 Выборочные значения времени оборота и их весовые средние значения

Кроме усредненного значения времени оборота полезно располагать мерой его изменчивости. В RFC 2988 описывается величина DevRTT как приближенное отклонение SampleRTT от EfstimatedRTT:

DevRTT = (1 – B) x DevRTT + B x | SampleRTT – EstimatedRTT |.

Обратите внимание на то, что DevRTT представляет собой экспоненциальное весовое скользящее среднее разности между SampleRTT и EstimatedRTT. Чем меньше разброс значений SampleRTT, тем меньшей является величина DevRTT.

Коэффициент В рекомендуется считать равным 0,25.

Определение и управление величиной интервала ожидания

Как определить величину временного интервала ожидания на основе значений EstimatedRTT и DevRTT? Очевидно, что интервал ожидания должен быть не меньше EstimatedRTT, поскольку в противном случае это приведет к лишним повторным передачам. Вместе с тем интервал ожидания не должен значительно превосходить значение EstimatedRTT: чем больше времени требуется на обнаружение факта потери пакета, тем большие задержки при передаче данных испытывает приложение. Таким образом, для задания интервала ожидания наиболее предпочтительно увеличить значение EstimatedRTT на некоторую переменную величину, зависящую от разброса значений SampleRTT. Именно такой величиной является DevRTT. В протоколе TCP используется следующая формула для вычисления интервала ожидания: