Курс лекций "Сетевым технологиям"

Транзакция между браузером и Web-сервером начинается с того, что клиент отправляет серверу URL запрашиваемой Web-страницы ( см. рис 3а.). Сервер отвечает сообщением ACK и начинает передачу запрашиваемой Web-страницы.

Запрос URL

ACK

Запрашиваемые данные

Рис.3а. Браузер передает сообщение с URL; сервер посылает сообщение ASK, подтверждающее прием и начинает передачу запрашиваемой Web-страницы

Последовательный и подтвержденный номер

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

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

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

Рис. 4. Нумерация байтов в ТСР-сегменте

Когда отправитель посылает TCP-сегмент, он в качестве идентификатора сегмента помещает в поле последовательного номера номер первого байта данного сегмента. Так, на рис. 5 идентификаторами сегментов являются номера 32600, 34060, 35520 и т. д. На основании этих номеров TCP-получатель не только от­личает данный сегмент от других, но и позиционирует полученный фрагмент относительно общего потока байтов. Кроме того, он может сделать вывод, что полученный сегмент является дубликатом или что между двумя полученными сегментами пропущены данные и т. д.

                                           38440                36980                     35520                  34060            32600

Направление передачи сегментов

Рис. 5. Порядковый номер и номер квитанции

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

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

Окно приема

Протокол TCP является дуплексным, то есть в рамках одного соединения регламентируется процедура обмена данными в обе стороны. Каждая сторона одновременно выступает и как отправитель, и как получатель. У каждой стороны есть пара буферов: один — для хранения принятых сегментов, другой — для сегментов, которые только еще предстоит отправить. Кроме того, имеется буфер для хранения копий сегментов, которые были отправлены, но квитанции о получении которых еще не поступили (рис. 6).

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

      (IP1,n1)                                                                                        (IP2,n2)

                                                      TCP - соединение

     Буфер отправления                                                            Буфер приема

         Буфер копий

          Буфер приема                                                          Буфер отправления

                                                                                             Окно

                                                                                                   Буфер копий

Рис. 6. Система буферов ТСР-соединения

На рис. 7 показан поток байтов, поступающий с верхнего уровня в выходной буфер протокола TCP. Из потока байтов модуль TCP «нарезает» последовательность сегментов и готовит их для отправки другому сокету. Для определенности на рисунке принято направление перемещения данных справа налево. В этом потоке можно указать несколько логических границ. Первая граница отделяет сегменты, которые уже были отправлены и на которые уже пришли квитанции. По другую сторону этой границы располагается окно размером W байт. Часть байтов, входящих в окно, составляют сегменты, которые также уже отправлены, но квитанции на них пока не получены. Оставшаяся часть окна — это сегменты, которые пока не отправлены, но могут быть отправлены, так как входят в пределы окна. И наконец, последняя граница указывает на начало последовательности сегментов, ни один из которых не может быть отправлен до тех пор, пока не придет очередная квитанция и окно не будет сдвинуто вправо.

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

Рис.7. Особенности реализации алгоритма скользящего окна в протоколе TCP

Накопительный принцип квитирования

Получатель может послать квитанцию, подтверждающую получение сразу нескольких сегментов, если они образуют непрерывный поток байтов. Например (рис. 8, а), если в буфер, плотно без пропусков заполненный потоком байтов до 2354 включительно, поочередно поступили сегменты (2355-3816), (3817-5275) и (5276-8400), где цифры в скобках означают номера первых и последних байтов каждого сегмента, то получателю достаточно отправить только одну квитан­цию на все три сегмента, указав в ней в качестве номера квитанции значение 8401. Таким образом, процесс квитирования является накопительным, или механизмом отложенного подтверждения..

Однако сегменты могут прийти к получателю не в том порядке, в котором были посланы, то есть в приемном буфере может образоваться «прогалина» (рис. 8, б). Пусть, к примеру, после указанных выше трех сегментов вместо следующего по порядку сегмента (8401-10566) пришел сегмент (10567-12430). Очевидно, что послать в качестве номера квитанции значение 12431 нельзя, потому что это бы означало, что получены все байты вплоть до 12430. Поскольку в потоке байтов образовался разрыв, получатель может только еще раз повторить квитанцию 8401, говоря тем самым, что все еще ожидает поступления потока байтов, начиная с 8401. Это называется положительным подтверждением с повторной передачей. Из этого примера видно, что, в отличие от многих других протоколов, протокол TCP подтверждает получение не отдельных блоков данных, а непрерывной последовательности байтов.

Время ожидания квитанции

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

Рис. 8. Накопительный принцип квитирования: а — плотное заполнение буфера, в момент t4 передается квитанция, б — неплотное заполнение буфера,

в момент t5 снова передается квитанция 8401

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

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

Управление окном приема

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

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

С другой стороны, указание окна малого размера может ограничить передачу дан­ных скоростью, которая определяется временем путешествия по сети каждого посылаемого сегмента. Чтобы избежать применения малых окон, в некоторых реализациях TCP предлагается получателю данных откладывать реальное изменение размеров окна до тех пор, пока свободное место не составит 20-40 % от максимально возможного объема памяти для этого соединения. Но и отправите­лю не стоит спешить с посылкой данных, пока окно принимающей стороны не станет достаточно большим. Учитывая эти соображения, разработчики протокола TCP предложили схему, согласно которой при установлении соединения заявляется большое окно, но впоследствии его размер существенно уменьшает­ся. Существуют и другие прямо противоположные алгоритмы настройки окна, когда вначале выбирается минимальное окно, а затем, если сеть справляется с предложенной нагрузкой, его размер резко увеличивается.

Управлять размером окна приема может не только та сторона, которая посылает это окно, чтобы регулировать поток данных в свою сторону, но и вторая сторона — потенциальный отправитель данных. Если вторая сторона фиксирует ненадежную работу линии связи (регулярно запаздывают квитанции, часто требуется повторная передача), то она может по собственной инициативе уменьшить окно. В таких случаях действует правило: в качестве действующего размера окна вы­бирается минимальное из двух значений — значения, диктуемого приемной сто­роной, и значения, определяемого «на месте» отправителем.

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