А. Робачевский - Операционная система UNIX (1114671), страница 77
Текст из файла (страница 77)
д. Таким образом, протоколы при!ложений, использующие TCP, могут быть значительно упрощены. С дру!гой стороны, это ведет к сложности самого транспортного протокола и,как следствие, к значительным накладным расходам при передаче данных.TCP!канал представляет собой двунаправленный поток данных между со!ответствующими объектами обмена — источником и получателем. Данныемогут передаваться в виде пакетов различной длины, называемых сегмен!тами. Каждый TCP!сегмент предваряется заголовком, за которым следуютwww.books-shop.comПротоколы транспортного уровня405данные, инкапсулирующие протоколы уровня приложения.
Вид заголовкаTCP!сегмента представлен на рис.Рис. 6.11. ФорматПоложение каждого сегмента в потоке фиксируется порядковым номером(Sequence Number), представленным соответствующим полем заголовка иобозначающим номер первого октета сегмента в потоке TCP. Порядковыеномера также используются для подтверждения получения: каждый ТСР!сегмент содержит номер подтверждения (Acknowledgement Number), со!общающий отправителю количество полученных от него последовательныхданных. Номер подтверждения определяется как номер первого непод!твержденного октета в потоке.И порядковый номер, и номер подтверждения занимают по 32 бита в за!головке TCP!сегмента, таким образом, их максимальное значение состав!ляет! 1), за которым следует 0.
При установлении связи стороны до!говариваются о начальных значениях порядковых номеров (InintialSequence Number, ISN) в каждом из направлений. Впоследствии первыйоктет переданных данных будет иметь номер (ISN+1).Управление потокомосуществляется с помощью метода скользя!щего окна (sliding window). Каждый TCP!заголовок содержит также полеWindow, которое указывает на количество данных, которое адресат готовпринять, начиная с октета, указанного в поле Acknowledgement Number.Заголовок TCP!сегмента занимает как минимум 20 октетов.
Помимо рас!смотренных нами порядковых номеров и анонсируемого окна, он содер!жит ряд других важных полей. Заголовок начинается с двух номеров пор!тов, адресующих логические процессы на обоих концах виртуального ка!нала. Далее следуют порядковый номер и номер подтверждения.Поле смещенияуказывает начало данных сегмента. Это поле не!обходимо, поскольку размер TCP!заголовка имеет переменную величину.www.books-shop.comГлава 6.сети всистеме UNIXЗначение этого поля измеряется в 32!битных словах. Таким образом, приминимальном размере заголовка полебудет равно 5.Далее заголовок содержит шесть управляющих флагов Flags, каждый изкоторых занимает отведенный ему бит:Указывает, что сегмент содержит экстренные данные, и полеUrgent pointer заголовка определяет их положение в сегменте.Указывает, что заголовок содержит подтверждение полученных дан%ных В поле Acknowledgement Number.PSHУказывает, чтоданные должны быть переданынемедленно, не ожидая заполнения сегмента максимального раз%мера.Указывает на необходимость уничтожения канала.SYNУказывает, что сегмент представляет собой управляющее сообще%ние, являющееся частью "тройного рукопожатия" для синхронизациипорядковых номеров при создании канала.Указывает, что сторона прекращает передачу данных и желает за%крыть виртуальный канал.Поле контрольной суммы Checksum используется для защиты от ошибок.Контрольная сумма вычисляется на основаниипсевдозаго!ловка, содержащего, в частности IP!адреса источника и получателя, а так!же номер протокола.
Цель включения в контрольную сумму части заго!ловка IP та же, что и для протокола UDP — дополнительно защитить дан!ные от получения не тем адресатом.Поле Urgent Pointer позволяет указать расположение экстренных дан!ных внутри сегмента. Это поле используется при установленном флаге URGи содержит порядковый номер октета, следующего за экстренными дан!ными.В конце заголовка располагается поле Options переменной длины, кото!рое может содержать различные опции, например, максимальный размерсегмента (MSS). Это поле дополняется нулями (Padding) для того, чтобызаголовок всегда заканчивался на границе 32 бит.Состояния TCP[сеансаКак уже говорилось, передача данных с использованием протокола TCPпредусматривает предварительное установление связи, или создание логи!ческого TCP!канала.
Эта предварительная фаза призвана усилить надеж!ность протокола. В процессе этой фазы определяется начало TCP!потоковв обоих направлениях, их характеристики (например, максимальный раз!мер окна), в это же время могут быть обнаружены "полуразрушенные"TCP!каналы прошлых сеансов передачи, некорректно закрытые, напри!www.books-shop.comПротоколы транспортного уровня407мер, ввиду аварийного останова одной из сторон.
Стороны выбирают про!извольные начальные порядковые номера потоков, чтобы уменьшить ве!роятность обработки сегментов, принадлежащих "старым"Начальная фаза сеанса передачи получила название "тройное рукопожа!тие" (three!way handshake), которое достаточно точно отражает процессобмена служебными сегментами между сторонами. Этот процесс является— одна из сторон, называемая клиентом, инициирует на!чало сеанса, посылая другой стороне — серверу сегментКак правилоэтот сегмент является числом служебным, т.
е. не содержит полезных дан!ных, его заголовок определяет номер порта и начальный порядковый но!мер потока клиент!сервер. Если сервер готов принять данные от клиента,он создает логический канал (размещая соответствующие структуры дан!ных) и отправляет клиенту сегмент с установленным начальным порядко!вым номером потока сервер!клиент и флагами SYN и АСК, подтверждаю!щий получение сегмента SYN и выражающего готовность сервера к полу!чению данных.
Наконец, и это третье рукопожатие, клиент отвечает сег!ментом с установленным флагом АСК, подтверждающим получение ответаот сервера и тем самым завершающим фазу создания TCP!канала. Процессустановления связи в TCP!сеансе представлен на рис.После этого обе стороны начинают передачу TCP!сегментов, каждый изкоторых содержит подтверждение полученных данных и новое значениеокна. Начиная с подтвержденного октета, источник может передать, недожидаяськоличество данных, определенных значениемокна.
Если отправитель не получает подтверждения на посланные данныев течение определенного промежутка времени, он полагает, что данныеутеряны, и их передача повторяется, начиная с последнего подтвержден!ного октета. Поскольку надежность передачи гарантируется протоколом,для данных приложения, переданных, но не подтвержденных, протоколхранит копию, которая уничтожается после получения подтверждения иливновь передается при отсутствии такового. Получение дублированныхданных также подтверждается, хотя сами данные уничтожаются, посколькудублирование могло быть вызвано неполучением подтверждения.
Если од!на из сторон получает неупорядоченные данные, они, как правило, сохра!няются до получения недостающих последовательных сегментов. Разуме!ется, получение таких неупорядоченных данных не подтверждается, по!Вусловиях модули TCP хранят последние использованные порядковые номера.Поэтому при создании нового канала (сеанса) модуль выбирает следующееиз ад!ресного пространство порядковых номеров (которое составляетПри скорости2 Мбит/с потребуется 4,5 часа для передачи данных, адресуемых этими номерами (поряд!ковыми и подтверждений). Это время на несколько порядков превышает время жизни ТСР!сегмента в сети,по умолчанию составляет 2 секунды. Это гарантирует, что новыеномера не "догонят" номера старых сегментов.
Даже при скорости 100 Мбит/с полный циклиспользования порядковых номеров составляет чуть больше 5 минут.Сегмент S Y N имеет установленный флаг S Y N в заголовке — отсюда и его название.www.books-shop.com408Глава 6.сети в операционной системе UNIXскольку подтверждение отправляется только на полученный непрерывныйпоследовательный поток октетов.Рис. 6.12. Установ%ление связи, переда%ча данных и заверше%ние TCP%сеансаЗавершение сеанса в TCP происходит в несколько этапов.
Любая из сто!рон может завершить передачу данных, отправив сегмент с установленнымфлагом FIN (рис. 6.12). Получение такого сегмента подтверждается другойстороной и эквивалентно достижению конца файла при его чтении. Одна!ко другая сторона может продолжать передавать данные, также впоследст!вии завершив передачу сегментом FIN. Подтверждение этого сегментаполностью разрушает канал и завершает сеанс.
Для того чтобы гарантиро!вать синхронизацию завершения сеанса, сторона, отправившая подтвер!ждение на последний сегмент FIN, должна поддерживать сеанс достаточнодолго, чтобы иметь возможность вновь подтвердить повторные сегментыFIN данного сеанса в случае, когда подтверждение не было получено дру!гой стороной.www.books-shop.comПротоколы транспортного уровняНа рис.также проиллюстрированы состояния коммуникационных уз!лов TCP!канала.Как видно из рисунка, начальное состояние узла (сервера или клиента) —состояние CLOSED. Готовность сервера к обработке инициирующих запро!сов от клиента определяется переходом его в состояние LISTEN. С этогомомента сервер может принимать и обрабатывать инициирующие сеанс сег!менты SYN.
При отправлении такого сегмента клиент переходит в состояниеSYN!SENT и ожидает ответного запроса от сервера. Сервер при получениисегмента также отправляет сегмент SYN с подтверждением АСК и переходит всостояние SYN!RECEIVED. Подтверждение от клиента завершает"рукопожатие" и сеанс переходит в состояние ESTABLISHED. После завер!шения обмена данными одна из сторон (например, клиент) отправляет сег!мент FIN, переходя при этом в состояниеПриняв этот сегментдругая сторона (например, сервер) отправляет подтверждение АСК и перехо!дит в состояние CLOSE!WAIT, при этом канал становится симплексным —передача данных возможна только в направлении от сервера к клиенту.
Ко!гда клиент получает подтверждение он переходит в состояние FIN!WAIT!2,в котором находится до получения сегмента FIN. После подтверждения по!лучения этого сегмента канал окончательно разрушается.Расшифровка состояний приведена в табл. 6.5.Таблица 6.5. Состояния TCP%сеансаLISTENГотовность узла к получению запроса на соединение от лю%бого удаленного узла.SYN%SENTОжидание ответного запроса на соединение.SYN%RECEIVEDОжидание подтверждения получения ответного запроса насоединение.ESTABLISHEDСостояние канала, при котором возможен дуплексный обменданными между клиентом и сервером.CLOSE%WAITОжидание запроса на окончание связи от локального про%цесса, использующего данный коммуникационный узел.LAST%ACKОжидание подтверждения запроса на окончание связи, от%правленного удаленному узлу.
Предварительно от удаленно%го узла уже был получен запрос на окончание связи и каналстал симплексным.FIN%WAIT%1Ожидание подтверждения запроса на окончание связи, от%правленного удаленному узлу (инициирующий запрос, каналпереходит в симплексный режим).FIN%WAIT%2Ожидание запроса на окончание связи от удаленного узлаCLOSINGОжидание подтверждения от удаленного узла на запросокончания связи.Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRSɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕɈɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭpiracy@books-shop.com4/0Глава 6.в операционной системе UNIXТаблица 6.5 (продолжение)TIME%WAITCLOSEDТаймаут перед окончательным разрушением канала, доста%точный для того, чтобы удаленный узел получил подтвержде%ние своего запроса окончания связи.
Величина тайм%аутасоставляет 2 MSL (Maximum SegmentФиктивное состояние, при котором коммуникационный узел иканал фактически не существуют.Для обеспечения правильной обработки данных для каждого логическогоTCP!канала хранится полная информация о его состоянии, различныхтаймерах и о текущих порядковых номерах переданных и принятых окте!тов. Это необходимо, например, для корректной обработки служебныхсегментов SYN иПередача данныхПосле создания виртуального канала взаимодействующие процессы полу!чают возможность обмениваться данными в дуплексном режиме.Хотя фактически передача данных осуществляется в виде сегментов, еелогический вид представляет собой последовательный поток октетов, каж!дый из которых адресуется порядковым номером. Каждый сегмент хранитв заголовке порядковый номер первого октета данных.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
