Учебник для вузов в. Олифер Н. Олифер Компьютерные Принципы, технологии, протоколы
 Скачать 22.28 Mb.
|
|
562 Глава 17. Базовые протоколы TCP/IP TCP на стороне TCP на стороне TCP на стороне TCP на стороне клиента сервера клиента сервера Запрос соединения Состояние ESTABLISHED Подготовка Закрыть соединения соединение прошла успешно Состояние ESTABLISHED Тайм-аут Закрыть соединение * Соединение закрыто а б Рис. 17.7. Процедура установления и разрыва логического соединения при нормальном течении процесса В ответ клиент посылает сегмент с флагом АСК и переходит в состояние установленного логического соединения (состояние ESTABLISHED). Когда сервер получает флаг АСК, он также переходит в состояние ESTABLISHED. На этом процедура установления соеди нения заканчивается, и стороны могут переходить к обмену данными. Соединение может быть разорвано в любой момент по инициативе любой стороны. Для этого клиент и сервер должны обменяться сегментами FIN и АСК, в последовательности, показанной на рис. 17.7, б (здесь инициатором является клиент). Соединение считается закрытым по прошествии некоторого времени, в течение которого сторона-инициатор убеждается, что ее завершающий сигнал АСК дошел нормально и не вызвал никаких «аварийных» сообщений со стороны сервера. П Р И М Е Ч А Н И Е --------------------------------------------------------------------------------------------------------------- Мы описали здесь процедуры установления и закрытия соединения очень схематично. Реальные протокольные модули работают в соответствии с гораздо более сложными алгоритмами, учитываю щими всевозможные «нештатные» ситуации, такие, например, как задержки и потери сегментов, недостаточность ресурсов или неготовность сервера к установлению соединения. Кроме того, мы проигнорировали тот факт, что еще на этапе установления соединения стороны договариваются о некоторых параметрах своего взаимодействия, например о начальных номерах посылаемых ими байтов. Однако мы скоро вернемся к этим важным деталям работы протокола TCP. Іааимодвй<^уі{иа Сокет одновременно может участвовать в нескольких соединениях. Так, на рис. 17.8 по- v o n o u u т п т і і г т і п і . і л т о п ' ї п огтпороікі'тл TD1 ТОО Т Р Ч Н о ь^омсттли v rtik in L iA T o n o т * т п л я и а й т р 0 ттл Протоколы транспортного уровня TCP и UDP 563 одному приложению — APPL1, APPL2 и APPL3, сокеты которых — соответственно (IP1, пі), (IP2, n2), (IP3, пЗ), а номера TCP-портов приложений — nl, п2, пЗ. На рисунке показаны два логических соединения, которое установило приложение 2 с приложением 1 и приложением 3. Логические соединения идентифицируются как {(IP2, n2), (IP1, nl)} и {(IP2, n2), (IP3, пЗ)} соответственно. Мы видим, что в обоих соединениях участвует один и тот же сокет — (IP2, п2). А теперь^эассмотрим на примере, как протокол TCP выполняет демультиплексирование. Пусть некий поставщик услуг оказывает услугу по веб-хостингу, то есть на его компью тере клиенты могут разворачивать свои веб-серверы. Веб-сервер основан на протоколе прикладного уровня HTTP, который передает свои сообщения в TCP-сегментах. Модуль TCP ожидает запросы от веб-клиентов (браузеров), «прослушивая» хорошо известный порт 80. На рис. 17.9 показан вариант хостинга с двумя веб-серверами — сервером wwwl .model.ru, имеющим IP-адрес IP1, и сервером www2.tour.ru с адресом IP2. К каждому из них может обращаться множество клиентов, причем клиенты могут одновременно работать как с сер вером wwwl, так и с сервером www2. Для каждой пары клиент-сервер протоколом TCP создается отдельное логическое соединение. На рисунке показаны два браузера, имеющие соответственно сокеты (IP*, щ) и (IPm, nm). Пользователь браузера k обращается одновременно к серверам W WW 1 и WWW2. Нали чие отдельных соединений для работы с каждым из этих серверов обеспечивает не только надежную доставку, но и разделение информационных потоков — у пользователя никогда не возникает вопроса, каким сервером ему была послана та или иная страница. Одновре менно с пользователем браузера k с сервером WWW2 работает пользователь браузера т. И в этом случае отдельные логические соединения, в рамках которых идет работа обоих пользователей, позволяют изолировать их информационные потоки. На рисунке показаны 564 Глава 17. Базовые протоколы TCP/IP буферы, количество которых определяется не числом веб-серверов и не числом клиентов, а числом логических соединений. Сообщения в эти буферы направляются в зависимости от значений сокетов как отправителя, так и получателя. Отсюда можно сделать вполне конкретный вывод. www1.model.ru - IP1 Соединение браузер k-сервер wwwl {(IF*,nk), (IP1,80ft www2.tour.ru - IP2 r ^QWWW2^ Соединение браузер к-сервер www2 (IP2, 80)} Ч І Соединение ^браузер m-сервер www2 : . ' І \« 1 й , nm), (ІР2, 80)} Oft» nm) Браузеры Рис. 17.9. Демультиплексирование протокола TCP на основе соединений іровтчие инфррмации, поступающей на прйклащйой |§ § § |§ 0 £ и л и , ‘ сгооідно ито же,на основ^идентифии^^и^х Повторная передача и скользящее окно Один из наиболее естественных приемов, используемых для организации надёжной пере дачи — это квитирование. Отправитель отсылает данные и ждет, пока к нему не придет квитанция, подтверждающая, что его данные благополучно дошли до адресата. В протоколе TCP используется частный случай квитирования — алгоритм скользящего окна. Прежде чем перейти к подробному рассмотрению особенностей реализации этого алгоритма в про токоле TCP, очень полезно обсудить его с общих позиций. Итак, существует два метода организации процесса обмена квитанциями: метод простоя источника и метод скользящего окна. Метод простоя источника требует, чтобы источник, пославший кадр (в данном случае не имеет значения, какое название используется для единицы передаваемых данных), дожидался от приемника квитанции, извещающей о том, что исходный кадр получен и данные в нем корректны, и только после этого посылал следующий кадр (или повторял искаженный). Если же квитанция в течение тайм-аута не пришла, то кадр (или квитанция) считается утерянным и его передача повторяется. На рис. 17.10 показано, что второй кадр Протоколы транспортного уровня TCP и UDP 565 отсылается только после того, как пришла квитанция, подтверждающая доставку первого кадра. Однако затем произошла длительная пауза в отправке следующего третьего кадра. В течение этой паузы источник был вынужден повторить передачу кадра 2, так как кви танция на первую его копию была потеряна. Понятно, что при таком алгоритме работы источника принимающая сторона должна уметь распознавать дублирующиеся кадры и избавляться от них. Повторная передача кадра 2 Простой Ожидание квитанции Отправленные кадры на стороне отправителя Полученные квитанции, АСК Полученные кадры на стороне приемника Время доставки кадра от отправителя к получателю Простой Истечение тайм-аута Простой Простой Ожидание Ожидание квитанции квитанции Время 1 Время доставки квитанции от получателя к отправителю кадра Рис. 17.10. Метод простоя источника Достаточно очевидно, что при использовании данного метода производительность обмена данными ниже потенциально возможной — передатчик мог бы посылать следующий кадр сразу же после отправки предыдущего, но он обязан ждать прихода квитанции. Второй метод называется методом скользящего окна (sliding window). В этом методе для повышения скорости передачи данных источнику разрешается передать некоторое коли чество кадров в непрерывном режиме, то есть в максимально возможном для источника темпе еще до получения на эти кадры квитанций. Количество кадров, которые разрешается передавать таким образом, называется размером окна. Рисунок 17.11 иллюстрирует применение данного метода для окна размером 5 кадров. В начальный момент, когда еще не послано ни одного кадра, окно определяет диапазон номеров кадров от 1 до 5 включительно. Источник начинает передавать кадры и через какое-то время получать в ответ квитанции. Для простоты предположим, что квитанции поступают в той же последовательности (но не обязательно в том же темпе), что и кадры, которым они соответствуют. В момент получения отправителем квитанции 1 окно сдви гается на одну позицию вверх, определяя новый диапазон разрешенных к отправке кадров (от 2 до 6). Процессы отправки пакетов и получения квитанций идут достаточно независимо друг от друга. В нашем примере отправитель продолжает передавать кадры, но некоторое время не получает на них квитанции. После передачи кадра 6 окно исчерпывается, и источник приостанавливает передачу. 566 Глава 17. Базовые протоколы TCP/IP Диапазон номеров кадров, разрешенных к отправке Рис. 17.11. Метод скользящего окна После получения квитанции 2 (на кадр 2) окно сдвигается вверх на единицу, определяя диапазон разрешенных к передаче кадров от 3 до 7. Аналогичное «скольжение» окна вверх происходит после получения каждой квитанции: окно сдвигается вверх на 1, но его размер при этом не меняется и остается равным 5. После прихода квитанции 8 окно оказывается в диапазоне от 9 до 13 и остается таковым достаточно долго, так как по каким-то причи нам источник перестает получать подтверждения о доставке кадров. Отправив последний разрешенный кадр 13, передатчик снова прекращает передачу с тем, чтобы возобновить ее после прихода квитанции 9. При отправке кадра в источнике устанавливается тайм-аут. Если за установленное время квитанция на отправленный кадр не придет, то кадр (или квитанция на него) считается утерянным, и кадр передается снова. Если же поток квитанций поступает регулярно в пределах допуска в 5 кадров, то скорость обмена достигает максимально возможной величины для данного канала и принятого протокола. В общем случае метод скользящего окна более сложен в реализации, чем метод простоя источника, так как передатчик должен хранить в буфере копии всех кадров, на которые пока не получены квитанции. Кроме того, при использовании данного метода требуется отслеживать несколько параметров алгоритма, таких как размер окна, номер кадра, на который получена квитанция, номер кадра, который еще можно передать до получения новой квитанции. Протоколы транспортного уровня TCP и UDP 567 Реализация метода скользящего окна в протоколе TCP Алгоритм скользящего окна в протоколе TCP имеет некоторые существенные особенности. В частности, в рассмотренном обобщенном алгоритме скользящего окна единицей пере даваемых данных является кадр, и размер окна также определяется в кадрах, в то время как в протоколе TCP дело обстоит совсем по-другому. Хотя ем^иі^пвр^даоаемьіх данныхлррто^^ фермент (аналог кадра в данном контакте}, €Ьй?ов^іеатру«с«>рироааиноіго потомка данных, В ходе переговорного процесса модули TCP обоих участвующих в обмене сторон догова риваются между собой о параметрах процедуры обмена данными. Одни из них остаются постоянными в течение всего сеанса связи, другие в зависимости, например, от интенсивно сти трафика и/или размеров буферов адаптивно изменяются. Одним из таких параметров является начальный номер байта, с которого будет вестись отсчет в течение всего функ ционирования данного соединения. У каждой стороны свой начальный номер. Нумерация байтов в пределах сегмента осуществляется, начиная от заголовка (рис. 17.12). ТСР-сегмент Заголовок TCP Байт Байт с конечным с начальным номером номером Рис. 17.12. Нумерация байтов в ТСР-сегменте Когда отправитель посылает ТСР-сегмент, он помещает в поле последовательного номера номер первого байта данного сегмента, который служит идентификатором сегмента. На рис. 17.13 показаны четыре сегмента размером 1460 байт и один — 870 байт. Идентифи каторами этих сегментов являются номера 32600, 34060, 35520 и т. д. На основании этих номеров получатель TCP-сегмента не только отличает данный сегмент от других, но и по зиционирует полученный фрагмент относительно общего потока байтов. Кроме того, он может сделать вывод, например, что полученный сегмент является дубликатом или что между двумя полученными сегментами пропущены данные и т. д. 38440 38980 36520 34060 32600 «1460 1460 1460 ------ ► Направление передачи сегментов Рис. 17.13. Порядковый номер и номер квитанции В качестве квитанции получатель сегмента отсылает ответное сообщение (сегмент), в поле подтвержденного номера которого он помещает число, на единицу превышающее макси 568 Глава 17. Базовые протоколы TCP/IP мальный номер байта в полученном сегменте. Так, для первого отправленного сегмента, изображенного на рис. 17.13, квитанцией о получении (подтвержденным номером) будет число 34060, для второго — 35520 и т. д. Подтвержденный номер часто интерпретируют не только как оповещение о благополучной доставке, но и как номер следующего ожидаемого байта данных. Квитанция в протоколе TCP посылается только в случае правильного приема данных. Таким образом, отсутствие квитанции означает либо потерю сегмента, либо потерю кви танции, либо прием искаженного сегмента. В соответствии с определенным форматом один и тот же TCP-сегмент может нести в себе как пользовательские данные (в поле данных), так и квитанцию (в заголовке), которой подтверждается получение данных от другой стороны. Поскольку протокол TCP является дуплексным, каждая сторона одновременно выступает и как отправитель, и как получатель. У каждой стороны есть пара буферов: один — для хранения принятых сегментов, другой — для сегментов, которые только еще предстоит отправить. Кроме того, имеется буфер для хранения копий сегментов, которые были от правлены, но квитанции о получении которых еще не поступили (рис. 17.14). (IP1.n1) (IP2, п2) Буфер копий 0кно Буфер отправления Буфер приема и— — Окно Буфер копий ІПП Рис. 17.14. Система буферов ТСР-соединения И при установлении соединения, и в ходе передачи обе стороны, выступая в роли полу чателя, посылают друг другу так называемые окна приема. Каждая из сторон, получив окно приема, «узнает», сколько байтов ей разрешается отправить с момента получения последней квитанции. Другими словами, посылая окна приема, обе стороны пытаются регулировать поток байтов в свою сторону, сообщая своему «визави», какое количество байтов (начиная с номера байта, о котором уже была выслана квитанция) они готовы в на стоящий момент принять. На рис. 17.15 показан поток байтов, поступающий от приложения в выходной буфер модуля TCP. Из потока байтов модуль TCP «нарезает» последовательность сегментов Протоколы транспортного уровня TCP и UDP 569 и поочередно отправляет их приложению-получателю. Для определенности на рисунке принято направление перемещения данных справа налево. В этом потоке можно указать несколько логических границ: □ Первая граница отделяет сегменты, которые уже были отправлены и на которые уже пришли квитанции. Последняя квитанция пришла на байт с номером N. □ По другую сторону этой границы располагается окно размером W байт. Часть байтов, входящих в окно, составляют сегменты, которые также уже отправлены, но квитанции на которые пока не получены. □ Оставшаяся часть окна — это сегменты, которые пока не отправлены, но могут быть отправлены, так как входят в пределы окна. □ И наконец, последняя граница указывает на начало последовательности сегментов, ни один из которых не может быть отправлен до тех пор, пока не придет очередная кви танция и окно не будет сдвинуто вправо. Направление движения окна ^ Размер окна — W Байт N + W Приложение Поток байт Байт N , / Окно і V Г'...Т "1 г ^ 1 1 1 1 1 ....1...... I « 1 1 г TCP Сегменты 1 а і Сегменты і і 1 в Сегменты, І Сегменты, отправлены, отправлены, і которые которые еще квитанции ! квитанции пока ! разрешено не разрешено получены не получены отправлять отправлять ^Направление передачи данных из источника к приемнику Рис. 17.15. Особенности реализации алгоритма скользящего окна в протоколе TCP Если размер окна равен W, а последняя по времени квитанция содержала значение N, то отправитель может посылать новые сегменты до тех пор, пока в очередной сегмент не попадет байт с номером N + W. Этот сегмент выходит за рамки окна, и передачу в таком случае необходимо приостановить до прихода следующей квитанции. Получатель может послать квитанцию, подтверждающую получение сразу нескольких сегментов, если они образуют непрерывный поток байтов. Например, (рис. 17.16, я), если в буфер, плотно без пропусков заполненный потшсом байтов до 2354 включительно, поочередно поступили сегменты (2355-3816), (3817-5275) и (5276-8400), где цифры в скобках означают номера первых и последних байтов каждого сегмента, то получателю достаточно отправить только одну квитанцию на все три сегмента, указав в ней в качестве номера квитанции значение 8401. Таким образом, процесс квитирования в TCP является накопительным. Вполне возможны ситуации, когда сегменты приходят к получателю не в том порядке, в котором были посланы, то есть в приемном буфере может образоваться «прогалина» (рис. 17.16, б). Пусть, к примеру, после указанных ранее трех сегментов вместо следую щего по порядку сегмента (8401-10566) пришел сегмент (10567-12430). Очевидно, что |