Компьютерные сети

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

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

Сокет одновременно может участвовать в нескольких соединениях. Так, на рис. 17.8 по-
одному приложению — APPL1, APPL2 и APPL3, сокеты которых — соответственно (IP1, nl), (IP2, n2), (IP3, пЗ), а номера TCP-портов приложений — nl, п2, пЗ.
Рис. 17.8. Один сокет может участвовать в нескольких соединениях

На рисунке показаны два логических соединения, которое установило приложение 2 с приложением 1 и приложением 3. Логические соединения идентифицируются как {(IP2, n2), (IP1, nl)} и {(IP2, n2), (IP3, пЗ)} соответственно. Мы видим, что в обоих соединениях участвует один и тот же сокет — (IP2, п2).

А теперь^эассмотрим на примере, как протокол TCP выполняет демультиплексирование. Пусть некий поставщик услуг оказывает услугу по веб-хостингу, то есть на его компьютере клиенты могут разворачивать свои веб-серверы. Веб-сервер основан на протоколе прикладного уровня HTTP, который передает свои сообщения в TCP-сегментах. Модуль TCP ожидает запросы от веб-клиентов (браузеров), «прослушивая» хорошо известный порт 80.

На рис. 17.9 показан вариант хостинга с двумя веб-серверами — сервером www1 .model.ru, имеющим IP-адрес IP1, и сервером www2.tour.ru с адресом IP2. К каждому из них может обращаться множество клиентов, причем клиенты могут одновременно работать как с сервером www1, так и с сервером www2. Для каждой пары клиент-сервер протоколом TCP создается отдельное логическое соединение.
На рисунке показаны два браузера, имеющие соответственно сокеты (IP*, я*) и (IP
m
, n
m

). Пользователь браузера k обращается одновременно к серверам WWW 1 и WWW2. Наличие отдельных соединений для работы с каждым из этих серверов обеспечивает не только надежную доставку, но и разделение информационных потоков — у пользователя никогда не возникает вопроса, каким сервером ему была послана та или иная страница. Одновременно с пользователем браузера k с сервером WWW2 работает пользователь браузера т. И в этом случае отдельные логические соединения, в рамках которых идет работа обоих пользователей, позволяют изолировать их информационные потоки. На рисунке показаны

буферы, количество которых определяется не числом веб-серверов и не числом клиентов, а числом логических соединений. Сообщения в эти буферы направляются в зависимости от значений сокетов как отправителя, так и получателя. Отсюда можно сделать вполне конкретный вывод.
www2.tour.ru - IP2
r?
^(wWVV2^
Соединение браузер к-сервер www2
www1.model.ru - IP1
БуферыСоединениебраузер m-сервер www2
Соединение браузер k-сервер www1
т.\). (1Р1,80)1
1 " \ ЯЛ
TCP
[ ' /“Л'
,Р
?
1
Oft»
n
m)
N/’
-
'Браузеры

Рис. 17.9. Демультиплексирование протокола TCP на основе соединений
|ровтчие инфррмеди^ поступающей на прйютадйой и^^сшо ито же,на осноедедентифии^^и^х
Повторная передача и скользящее окно

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

Итак, существует два метода организации процесса обмена квитанциями: метод простоя источника и метод скользящего окна.

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

Повторная передача кадра 2
Отправленные Простой \ Простой Простойкадры на Ожидание Простой \ Ожидание Ожиданиестороне квитанции Истечение тайм-аута \ квитанции квитанции
отправителя
пи----И
Полученныеквитанции,
\ \ „
&
АСКПолученные
7
\\ Потеря \\ / \\ / ^ квитанции |2|/ |3|/
кадры на стороне приемникаВремя доставки кадра от отправ к получателю
1мтеляРис
!. 17,
-“....... ►ВремяВремя доставки квитанции от получателя к отправителю кадра.10. Метод простоя источника

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

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

В начальный момент, когда еще не послано ни одного кадра, окно определяет диапазон номеров кадров от 1 до 5 включительно. Источник начинает передавать кадры и через какое-то время получать в ответ квитанции. Для простоты предположим, что квитанции поступают в той же последовательности (но не обязательно в том же темпе), что и кадры, которым они соответствуют. В момент получения отправителем квитанции 1 окно сдвигается на одну позицию вверх, определяя новый диапазон разрешенных к отправке кадров (от 2 до 6).

Процессы отправки пакетов и получения квитанций идут достаточно независимо друг от друга. В нашем примере отправитель продолжает передавать кадры, но некоторое время не получает на них квитанции. После передачи кадра 6 окно исчерпывается, и источник приостанавливает передачу.
Отправле! кадры на стороне отправителя
Диапазон номеров кадров, разрешенных к отправке
Полученные кадры на стороне приемникаРис. 17.11. Метод скользящего окна

После получения квитанции 2 (на кадр 2) окно сдвигается вверх на единицу, определяя диапазон разрешенных к передаче кадров от 3 до 7. Аналогичное «скольжение» окна вверх происходит после получения каждой квитанции: окно сдвигается вверх на 1, но его размер при этом не меняется и остается равным 5. После прихода квитанции 8 окно оказывается в диапазоне от 9 до 13 и остается таковым достаточно долго, так как по каким-то причинам источник перестает получать подтверждения о доставке кадров. Отправив последний разрешенный кадр 13, передатчик снова прекращает передачу с тем, чтобы возобновить ее после прихода квитанции 9.

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

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

Алгоритм скользящего окна в протоколе TCP имеет некоторые существенные особенности. В частности, в рассмотренном обобщенном алгоритме скользящего окна единицей передаваемых данных является кадр, и размер окна также определяется в кадрах, в то время как в протоколе TCP дело обстоит совсем по-другому.
Хотя ем^и^пвр^даваемых данныхлррток^ Овсмвнт (аналог кадра в данном
KOWTeK&^f £КДО
данных, передаваемого^

В ходе переговорного процесса модули TCP обоих участвующих в обмене сторон договариваются между собой о параметрах процедуры обмена данными. Одни из них остаются постоянными в течение всего сеанса связи, другие в зависимости, например, от интенсивности трафика и/или размеров буферов адаптивно изменяются. Одним из таких параметров является начальный номер байта, с которого будет вестись отсчет в течение всего функционирования данного соединения. У каждой стороны свой начальный номер. Нумерация байтов в пределах сегмента осуществляется, начиная от заголовка (рис. 17.12).

ТСР-сегмент
Байт Байтс конечным с начальнымномером номеромРис. 17.12. Нумерация байтов в ТСР-сегменте

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

38440 38980 36520 34060 32600
1460 1460 £1460
870
Направление передачи сегментов
Рис. 17.13. Порядковый номер и номер квитанции

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

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

Поскольку протокол TCP является дуплексным, каждая сторона одновременно выступает и как отправитель, и как получатель. У каждой стороны есть пара буферов: один — для хранения принятых сегментов, другой — для сегментов, которые только еще предстоит отправить. Кроме того, имеется буфер для хранения копий сегментов, которые были отправлены, но квитанции о получении которых еще не поступили (рис. 17.14).
(1Р1,п1)
ТСР-соединение
*
(IP2, п2)
Буфер отправления
Буфер приема
Буфер приема
I

Буфер отправления
Окно
Буфер копий
Рис. 17.14. Система буферов ТСР-соединения

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

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

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

□ И наконец, последняя граница указывает на начало последовательности сегментов, ни один из которых не может быть отправлен до тех пор, пока не придет очередная квитанция и окно не будет сдвинуто вправо.
Направление движения окна
^ Размер окна
—
w
Байт N + W
Приложение
Потокбайт
Байт N
,/
Окно
1
V
Г.......г~"1 Г^1
11 I I 1 1 HI 1 1
TCP
Сегменты
1I1Сегменты !
1 1 вСегменты, j
Сегменты,
отправлены,
отправлены, j
которые
которые еще
квитанции
!
квитанции пока
!
разрешено
не разрешено
получены

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

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

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

Передача квитанции на получение байта 8401 2354 2355 3816 3817 5275 5276 8400 /_
t1 t2 t3 t4
J
--►Время t
a
Передача квитанции
на получение байта 8401
2354 2355 3816 3817 5275 5276 8400
10567 12430/
Г__| , |7—
J—-—С-*
t1 t2 t3 t4 t5q Время tРис. 17.16. Накопительный принцип квитирования: а — плотное заполнение буфера (в момент t4 передается квитанция на байт 8401), б — неплотное заполнение буфера (в момент t5 снова передается квитанция на байт 8401)

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

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

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

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

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

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

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

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