Чем идентифицируется логическое tcp соединение

2.5.2 Протокол tcp

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

Заголовок TCP-сегмента содержит значительно больше полей, нежели заголовок UDP (рис. 2.12), что указывает на широту возможности первого протокола [27].

Порт источника

Порт приемника

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

Подтвержденный номер

Длина заголовка

Кодовые биты

Контрольная сумма

Указатель срочности

максимум 24 бита

Заполнитель

Рис. 2.12 – Структура TCP-заголовка

Поле Порт источника (Source Port) занимает 2 байта и идентифицирует процесс-от­правитель.

Поле Порт приемника (Destination Port) занимает 2 байта и идентифицирует про­цесс-получатель.

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

Поле Подтвержденный номер (Acknowledgement Number) занимает 4 байта и со­держит максимальный номер байта в полученном сегменте, увеличенный на единицу. Именно это значение используется в качестве квитанции, то есть удостоверения, что сегмент получен. Если ус­тановлен контрольный бит АСК, то поле содержит следующий номер оче­реди, который отправитель данного сегмента желает получить в обратном на­правлении.

Поле Длина заголовка (Hlen) занимает 4 бита и представляет собой длину заголов­ка TCP-сегмента, измеренную в 32-х-битовых словах. Длина заголовка не фик­сирована и может изменяться в зависимости от значений, устанавливаемых в поле параметров.

Поле Резерв (Reserved) занимает 6 бит.

Поле Кодовые биты (Code Bits) содержит служебную информацию о типе данного сегмента. Положительное значение сигнализируется установкой этих битов в единицу:

1) URG (срочность) – указывает на необходимость проверки значения поля Urgent Pointer (указатель срочности);

2) АСК (подтверждение) – указывает на необходимость проверки значения поля Acknowdgment Number (подтвержденный номер);

3) PSH (проталкивание) – игнорирует буферизацию и передает данные непосредственно прикладному уровню. Эта возможность применяется для приложений, выполняющихся однократно или с ограниченным временным ресурсом;

4) RST (сброс) – завершает соединение. Применяется для полного закрытия соединения, а также для отказа в соединении по любой причине;

5) SYN (синхронизация) – используется для синхронизации счетчиков передан­ных данных при установлении соединения и обозначает, что отправитель извещает противоположную сторону TCP-соединения о значении в своем поле Sequence Number (порядковый номер);

6) FIN (окончание) – обозначает, что хост завершил соединение, то есть достижение передающей стороной последнего байта в по­токе передаваемых данных.

Поле Окно (Window) определяет размер TCP-буфера приема в байтах. Размер окна, приравненный к нулю, означает, что отправитель должен приостановить передачу – TCP-буфер получателя заполнен.

Поле Контрольная сумма (Сhecksum) занимает 2 байта.

Поле Указатель срочности (Urgent pointer) занимает 2 байта. Данное поле значимо только в том случае, если установить флаг URG, и получатель должен просмотреть это поле, чтобы узнать, откуда начинать считывать данные пакета.

Поле Параметры (Options) имеет переменную длину и может вообще отсутствовать. Максимальная величина поля составляет 3 байта; оно используется для ре­шения вспомогательных задач, например для выбора максимального размера сегмента. Поле параметров может располагаться в конце заголовка TCP, а его длина кратна 8 битам.

Поле Заполнитель (padding) может иметь переменную длину. Это фиктивное поле, используемое для доведения размера заголовка до целого числа 32-х-битовых слов.

Основным отличием протокола TCP от UDP является то, что на протокол TCP возложена дополнительная задача – обеспечить надежную доставку сообщений, используя в качестве основы протокол IP.

TCP-протокол решает задачу обеспечения надежного обмена данными путем установления между компьютерами логических соединений, благодаря которым TCP следит, чтобы передаваемые сегменты не были потеряны, не были продуб­лированы и пришли к получателю в том порядке, в котором были отправлены.

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

1) максимальный размер сегмента, который она готова принимать;

2) максимальный объем данных (возможно несколько сегментов), которые она разрешает другой стороне передавать в свою сторону, даже если та еще не по­лучила квитанцию на предыдущую порцию данных;

3) начальный порядковый номер байта, с которого она начинает отсчет потока данных в рамках этого соединения.

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

Таким образом, из всего вышеизложенного о двух протоколах транспортно­го уровня стека TCP/IP следует, что на один из них – TCP – возложена сложная и очень важная задача обеспечения надежной передачи данных через ненадежную сеть.

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

Протокол UDP может быть использован и в том случае, когда хорошее качество линий связи обеспе­чивает достаточный уровень надежности и без применения дополнительных приемов (например, установление логического соединения и квитирования пере­даваемых пакетов (подтверждение получения)). Заметим, что, поскольку протокол TCP основан на ло­гических соединениях, он не годится для широ­ковещательной и групповой рассылки, в отличие от протокола UDP.

Протокол надежной доставки сообщений TCP

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

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

Рис.4.5. Логическое соединение между взаимодействующими процессами

И пока программы протокола TCP продолжают функционировать корректно, а составная сеть не распалась на несвязные части, ошибки в передаче данных на уровне протокола IP не будут влиять на правильное получение данных [1,6].

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

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

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

Назначение номеров портов прикладным процессам осуществляется одним из двух способов:

• • централизованно, если эти процессы представляют известные всем службы. Примеры: номер порта 21 — служба удаленного доступа к файлам ftp, 23 — служба удаленного управления telnet;
• • локально — для не столь известных служб.

Протокол TCP ведет для каждого порта два потока пакетов: входной и выходной (рис.4.6) [1, 6]. Процедура обслуживания протоколом TCP запросов, поступающих (сверху) от нескольких разных прикладных служб, называется мультиплексированием. Обратная процедура распределения протоколом TCP поступающих (снизу) от сетевого уровня пакетов между набором высокоуровневых служб (по номерам портов) называется демультиплексированием.

Входная очередь сегментов

Выходная очередь сегментов

Рис.4.6. Организация TCP (потоки, порты, очереди сегментов)

Сегменты и потоки. Единицей данных протокола TCP является сегмент. А информация, поступающая к протоколу TCP в рамках логического соединения от протоколов более высокого уровня, рассматривается как неструктурированный поток байтов. Поступающие данные буферизуются средствами TCP. Для передачи (вниз) на сетевой уровень из буфера «вырезается» непрерывная часть данных — сегмент. Но протокол TCP подтверждает получение байтов потока [1].

Не все сегменты, посланные через TCP-соединение, будут одинакового размера, но оба участника соединения должны договориться о максимальном размере сегмента, который они будут использовать. Причем, этот размер должен быть таким, чтобы при упаковке сегмента в

IP-пакет он помещался туда целиком — не превышал максимального размера поля данных IP-пакета, исключая излишнюю фрагментацию.

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

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

В рамках TCP-соединения осуществляется обязательное подтверждение правильности приема всех переданных сообщений и при необходимости выполняется единичная повторная передача. ТСР-соединение позволяет вести дуплексную передачу данных.

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

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

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

На рис.4.7 показан поток байтов передачи, из которого модуль TCP «нарезает» последовательность сегментов.

Направление движения окна

Сегменты отправлены, квитанции получены, номер последнего байта -N

Сегменты отправлены, но квитанции пока не получены

Сегменты, которые еще могут быть отправлены

Сегменты,которые пока нельзя отправлять

Направление движения данных

Рис.4.7. Поток байтов передачи и 4 группы сегментов TCP

Сегменты там делятся на 4 известные группы, окно сдвигается вправо, данные — влево. Если размер окна равен W байтов, а последняя квитанция содержала номер байта — N, то передавать следующие сегменты можно до тех пор, пока в очередной сегмент не попадет байт с номером (W 4- N), выходящий за рамки окна [1].

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

Чем идентифицируется логическое tcp соединение

TCP основан на связи «точка-точка» между двумя узлами сети. TCP получает данные от программ и обрабатывает их как поток байтов. Байты группируются в сегменты, которым TCP присваивает последовательные номера, необходимые для правильной сборки сегментов на узле-приемнике.
Чтобы два узла TCP могли обмениваться данными, им нужно сначала установить сеанс связи друг с другом. Сеанс TCP инициализируется с помощью процесса, называемого трехэтапным установлением связи. В этом процессе синхронизируются номера последовательности и передается управляющая информация, необходимая для установления виртуального соединения между узлами.
TCP-сегменты инкапсулируются и передаются в IP-датаграммах, как показано на следующем рисунке.
Заголовок TCP-сегмента содержит значительно больше полей, чем заголовок UDP, что отражает более развитые возможности первого протокола. Рис. 1. Формат заголовка сегмента TCP.

• флаг URG (Urgent Pointer – указатель точности) устанавливается в 1 в случае использования поля указатель на срочные данные;
• флаг ACK (Acknowledgment – подтверждение) устанавливается в 1 в случае, если поле номер подтверждения содержит данные. В противном случае это поле игнорируется;
• флаг PSH (Push – выталкивание) означает, что принимающий стек TCP должен немедленно информировать приложение о поступивших данных, а не ждать пока буфер заполнится;
• флаг RST (Reset – сброс) используется для отмены соединения: из-за ошибки приложения, отказа от неверного сегмента, попытки создать соединение при отсутствии затребованного сервиса;
• флаг SYN (Synchronize – синхронизация) устанавливается при инициировании соединения и синхронизации порядкового номера;
• флаг FIN (Finished – завершение) используется для разрыва соединения. Он указывает, что отправитель закончил передачу данных.

Рис. 2. Структура пакета TCP при вычислении контрольной суммы.

Рис. 3. Структура псевдозаголовка пакета TCP.

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

• соединение 1 – ;
• соединение 2 – ;
• соединение 3 – .

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

В качестве квитанции получатель сегмента отсылает ответное сообщение (сегмент), в которое помещает число (номер подтверждения), на единицу превышающее максимальный номер байта в полученном сегменте. Для сегментов, изображенных на рис. 6, квитанцией о получении (номером подтверждения) служат номера последнего байта каждого сегмента +1. Так для первого отправленного сегмента это будет число 34060, для второго – 36520 и т.д. Номер подтверждения часто интерпретируют как номер следующего ожидаемого байта данных. Квитанция (подтверждение) в протоколе TCP посылается только в случае правильного приема данных, отрицательные квитанции не посылаются. Таким образом, отсутствие квитанции означает либо потерю сегмента, либо прием искаженного сегмента, либо потерю квитанции.
В протоколе TCP в одном и том же сегменте могут быть помещены и данные, которые посылает приложение другой стороне, и квитанция, которой модуль TCP подтверждает получение данных.
Протокол TCP является дуплексным, то есть в рамках одного соединения регламентируется процедура обмена данными в обе стороны. Каждая сторона одновременно выступает и как отправитель, и как получатель. У каждой стороны есть пара буферов: один – для хранения принятых сегментов, другой – для сегментов, которые только еще предстоит отправить. Кроме того, имеется буфер для хранения копий сегментов, которые были отправлены, но квитанции о получении которых еще не поступили.
И при установлении соединения, и в ходе передачи обе стороны, выступая в роли получателя, посылают друг другу так называемые окна приема. Каждая из сторон, получив окно приема, «понимает», сколько байтов ей разрешается отправить с момента получения последней квитанции. Другими словами, посылая окна приема, обе стороны пытаются регулировать поток байтов в свою сторону, сообщая своему «визави», какое количество байтов (начиная с номера байта, о котором уже была выслана квитанция) они готовы в настоящий момент принять.
На рис. 7 показан поток байтов, поступающих с верхнего уровня в выходной буфер протокола TCP. Из протокола байтов модуль TCP «нарезает» последовательность сегментов и готовит их для отправки другому сокету. В этом потоке можно указать несколько логических границ. Первая граница отделяет сегменты, которые уже были отправлены и на которые уже пришли квитанции. По другую сторону этой границы располагается окно размером W байт. Часть байтов, входящих в окно, составляют сегменты, которые уже были отправлены, но квитанции на них пока не получены. Оставшаяся часть окна – это сегменты, которые пока не отправлены, но могут быть отправлены, так как входят в пределы окна. И наконец, последняя граница указывает на начало последовательности сегментов, ни один из которых не может быть отправлен до тех пор, пока не придет очередная квитанция и окно не будет сдвинуто вправо.
Если размер окна равен W, а последняя по времени квитанция содержала значение N, то отправитель может посылать новые сегменты до тех пор, пока в очередной сегмент не попадет байт с номером N+W. Этот сегмент выходит за рамки окна, и передачу в таком случае необходимо приостановить до прихода следующей квитанции.

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

Формат UDP-пакета
Протокол UDP, являясь дейтаграммным протоколом, реализует сервис по возможности, то есть не гарантирует доставку своих сообщений, а, следовательно, никоим образом не компенсирует ненадежность дейтаграммного протокола IP.
Единица данных протокола UDP называется UDP-пакетом или пользовательской дейтаграммой (user datagram). Каждая дейтаграмма переносит отдельное пользовательское сообщение. Это приводит к естественному ограничению: длина дейтаграммы UDP не может превышать длины поля данных протокола IP, которое, в свою очередь, ограничено размером кадра технологии нижнего уровня. Поэтому если UDP-буфер переполняется, то данные приложения отбрасываются. Заголовок UDP-пакета, состоящий из четырех 2-байтовых полей, содержит поля порт источника, порт получателя, длина UDP и контрольная сумма.

Рис. 8. Формат заголовка пакета UDP.

Рис. 10. Структура псевдозаголовка пакета UDP

Логические соединения — основа надежности TCP

При установлении логического соединения модули TCP договариваются между собой о параметрах процедуры обмёна данными.

? максимальный размер сегмента, который она готова принимать;

? максимальный объем данных (возможно несколько сегментов), которые она разрешает другой стороне передавать в свою сторону, даже если та еще не получила квитанцию на предыдущую порцию данных (размер окна);

? начальный порядковый номер байта, с которого она начинает отсчет потока данных в рамках данного соединения.

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

Логическое ТСР-соединейие однозначно идентифицируется парой ¢ok℮tqo. .

Каждый сокет одновременно может участвовать в нескольких соединениях. Так, если (IP1, nl), (IP2, ∏2), (IPЗ, пЗ) — сокеты трех разных приложений, где IP1,

IP2, IPЗ — их IP-адреса, a nl, п2, пЗ — номера их TCP-портов, то возможно образование следующих соединений:

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

На рис. 19.7 показан вариант хостинга с двумя веб-серверами — сервером www1. model.ru, имеющим IP-aдpec IP1, и сервером www2.tour.ru с адресом IP2. К каждому из них может обращаться множество клиентов, причем клиенты могут одновременно работать как с сервером WWW1, так и с сервером WWW2. Работа каждого клиента требует сохранения прочитанных страниц, параметров и настроек сеанса связи, то есть образования отдельного логического соединения. Такое соединение создается протоколом TCP для каждой пары клиент-сервер.

На рисунке показаны два браузера, имеющие соответственно сокеты (IPk, nk) и (IPm, nm). Пользователь браузера к обращается одновременно к серверам WWW1 и WWW2. Наличие отдельных соединений для работы с каждым из этих серверов гарантирует разделение информационных потоков — у пользователя нико- ”та не возникает вопроса, каким сервером ему была послана та или иная страница. Одновременно с пользователем браузера к с сервером WWW2 работает пользователь браузера ш. Ив этом случае отдельные логические соединения,

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

Таким образом, протокол TCP осуществляет демультиплексирование на основе соединений.