Понятие протокола, и связанные с ним понятия

Вид материала

Содержание

Транспортный уровень. Протоколы TCP и UDP.
Open – read/write … close)
TCP-протокола – документ RFC-793
Протокол UDP.
Source Port
Интерфейс пользователя
Интерфейс протокола IP
Протокол ТСР
Options Поля этого заголовка следующие: Source Port
Sequence Number
Acknowledgment Number
Data Offset
Flags или Control Bits
RST: перезагрузка (сброс) данного соединения SYN
Urgent Pointer
LISTEN Ожидание запроса на соединение со стороны чужих портов и программ TCP. (пассивно открытое соединение) SYN-SENT
CLOSING Ожидание подтверждения со стороны чужой программы TCP запроса о закрытии соединения. LAST-ACK
Концепция периода молчания в протоколе TCP

Подобный материал:

1 2 3 4 5 6 7 8 9 ... 20

Транспортный уровень. Протоколы TCP и UDP.

Место протоколов UDP и TCP в иерархии протоколов сети Internet.

Протокол IP обеспечивает доставку пакетов данных между узлами сети. Доставку сообщений между процессами на узлах обеспечивают протоколы транспортного уровня – TCP и UDP. Для адресации процессов оба эти протокола используют 16-битные идентификаторы, называемые номерами портов. Совокупность IP-адреса и номера порта однозначно идентифицирует процесс и называется сокетом (т.е. соединителем). Для ряда основных протоколов прикладного уровня определенны “общеизвестные” номера портов. Для других процессов номера портов могут быть в общем случае произвольные, с единственным ограничением – номер порта должен быть уникальным на данном узле.

Протокол транспортного уровня UDP (User Datagram Protocol) проектировался для создания в объединенной системе компьютерных сетей с коммутацией пакетов режима передачи датаграмм клиента – без установления соединения и без подтверждения доставки. Протокол UDP предполагает, что нижестоящим протоколом является Internet (IP).

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

Оригинальная версия спецификации UDP-протокола – документ RFC-768 размещается на сервере ISI (Information Sciences Institute):

URL = ссылка скрыта

Протокол транспортного уровня TCP (Transmission Control Protocol) – основной протокол этого уровня сети Internet.

Протокол TCP реализует для приложений более высокого уровня работу с сетью как привычный обмен с последовательным файлом (OPEN – READ/WRITE … CLOSE). Перед началом обмена посылается запрос на установление связи, а с противоположной стороны – подтверждение на готовность к сеансу (установление связи). Затем данные передаются последовательно, наконец, после обмена сеанс явно завершается.

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

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

Обеспечивается, при необходимости, доставка экстренных данных.

Таким образом, прикладные программы могут работать с TCP-каналом как с обычным двунаправленным последовательным каналом ввода-вывода.

Зато сам протокол значительно сложнее, и накладные расходы при его использовании значительно больше.

Оригинальная версия спецификации TCP-протокола – документ RFC-793 размещается на сервере ISI (Information Sciences Institute):

URL = ссылка скрыта

Протокол UDP.

UDP-датаграмма состоит из заголовка (4 16-битных поля) и пользовательских данных. Кроме своего заголовка, протокол UDP использует в своей работе также так называемый псевдозаголовок, состоящий из полей протокола (UDP=17), и адресов отправителя и получателя из заголовка пакета IP. Структура заголовка следующая:

Source Port, Destination Port – идентифицируют приложения верхнего уровня, кем отправлена и кому адресована датаграмма. Порт отправителя необязателен. Если задействован порт отправителя, то он указывает порт процесса, посылающего датаграмму. Это тот порт, на который при необходимости следует адресовать ответную датаграмму. Если данное поле не задействовано, то в него следует записать нули. Порт получателя имеет смысл только в контексте конкретного IP адреса получателя.

Length - длина в байтах данной датаграммы, включая как заголовок, так и данные (Это означает, что минимальное значение поля длины равно восьми).

Checksum – Контрольная сумма – 16 битное дополнение до единицы суммы дополнений UDP заголовка, данных и псевдозаголовка. Последний содержит информацию из заголовка в протоколе IP. В случае необходимости, датаграмма дополняется в конце нулевыми байтами, чтобы общее их количество стало четным.

П

севдозаголовок, который, согласно концепции, предшествует UDP заголовку, содержит адрес отправителя, адрес получателя, поле протокола и длины UDP датаграммы. Структура псевдозаголовка предполагается такой:

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

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

Интерфейс пользователя

Интерфейс пользователя должен позволять:

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

Интерфейс протокола IP

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

Примеры применения протокола UDP:

Протокол взаимодействия с сервером доменных имен DNS, порт 53;
Протокол синхронизации Network Time Protocol, порт 123;
Протокол удаленной загрузки BOOTP, порт 67 клиент, 68 сервер;
Протокол удаленного копирования Trivial FTP (TFTP), порт 69;

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

Протокол ТСР

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

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

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

К

аждый сегмент предваряется 20-60-байтным заголовком следующего вида:

Options

Поля этого заголовка следующие:

Source Port (порт отправителя) 16 бит = номер порта отправителя

Destination Port (порт получателя) 16 бит = номер порта получателя

Sequence Number (номер очереди) 32 бита

Номер очереди для первого байта данных в данном сегменте (за исключением тех случаев, когда присутствует флаг синхронизации SYN). Если же флаг SYN присутствует, то номер очереди является инициализационным (ISN), а номер первого байта данных – ISN+1.

Acknowledgment Number (номер подтверждения) 32 бита.

Если установлен контрольный бит ACK, то это поле содержит следующий номер очереди, который отправитель данного сегмента желает получить в обратном направлении. Номера подтверждения посылаются постоянно, как только соединение будет установлено.

Data Offset (смещение данных) 4 бита = Количество 32-битных слов в TCP заголовке. Указывает на начало поля данных. TCP заголовок всегда кончается на 32-битной границе слова, даже если он содержит опции.

Reserved 6 бит = Резервное поле, должно быть заполнено нулями.

Flags или Control Bits (контрольные биты) 6 бит

Биты этого поля слева направо:

URG: поле срочного указателя задействовано

ACK: поле подтверждения задействовано

PSH: функция проталкивания

RST: перезагрузка (сброс) данного соединения

SYN: синхронизация номеров очереди

FIN: нет больше данных для передачи

Window (окно) 16 бит = Количество байтов данных, начиная с байта, чей номер указан в поле подтверждения, получения которых ждет отправитель настоящего сегмента (которые он готов принять).

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

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

Urgent Pointer (срочный указатель) 16 бит.

Это поле сообщает текущее значение срочного указателя. Последний является смещением относительно номера очереди данного сегмента. Срочный указатель сообщает номер очереди для байта, следующего за срочными данными. Это поле интерпретируется только в том случае, когда в сегменте выставлен контрольный бит URG. При этом модуль TCP должен сообщить приложению о переходе в “срочный режим”, а при достижении байта, на который указывает “срочный указатель” – о переходе в “нормальный режим”. Если срочный указатель изменится, когда приложение находится в срочном режиме, оно об этом не узнает. Спецификация TCP не определяет, как обрабатывать срочные данные – это компетенция приложения.

Options (опции) длина переменная.

Опции могут начинаться с любого байта. Они могут иметь два формата:

•однобайтный тип опций;

•байт типа опции, байт длины опции и байты данных рассматриваемой опции.

В байте длины опции учитываются байт типа опции, сам байт длины, а также все байты с данными.

В настоящее время определены следующие опции:

Тип Длина Значение

0 1 – конец списка опций

1 1 – нет операций

2 4 – максимальный размер сегмента 2.4.<16-бит макс размер сегмента>

Протокол TCP использует тип сервиса и, возможно, опцию безопасности протокола IP с тем, чтобы пользователям протокола TCP обеспечить приоритет и безопасность на каждом соединении.

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

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

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

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

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

Соединение задается командой OPEN (открыть), сделанной с локального порта и имеющей аргументом чужой сокет. В ответ на такой запрос программа протокола TCP предоставляет локальное имя (идентификатор) соединения. По этому имени пользователь адресуется к данному соединению при последующих вызовах. Предполагается, что имеется некая структура данных, называемая блоком управления передачей (Transmission Control Block – TCB), предназначенная для сохранения описанной выше информации. Можно было бы реализовать протокол таким образом, чтобы локальное имя (идентификатор) соединения было бы указателем на его TCB.

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

Если на один и тот же местный сокет осуществлено несколько ждущих пассивных запросов на открытие (записанных в блоки TCB), и осуществляется извне активный запрос на открытие, то чужой активный сокет будет связываться с тем блоком TCB, где было указание именно на этот сокет. И только если такого блока TCB не существует, выбор партнера осуществляется среди блоков TCB с неопределенным чужим сокетом.

Процедура установки соединения использует флаг управления синхронизацией (SYN) и трижды обменивается сообщениями. Такой обмен называется трехвариантным подтверждением (тройным рукопожатием).

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

Отмена соединения также включает обмен сегментами, несущими на этот раз управляющий флаг FIN.

Состояния TCP-соединения. Определено 11 состояний, в которых может пербывать TCP соединение. Переходы из состояния в состояние осуществляются в результате запросов прикладного уровня на открытие или разрыв соединения, прихода от противоположной стороны сегментов, несущих управляющие флаги SYN,FIN,RST,ACK, а также по таймауту (TIME-WAITCLOSED). Переход из состояния в состояние при приеме обычных сегментов, несущих пользовательскую информацию, не предусматривается. Такие сегменты корректно принимаются и обрабатываются, только если соединение находится в состоянии ESTABLISHED. Начальным и конечным состоянием любого соединения является состояние CLOSED. Вообще-то состояние соединения определяется состояниями клиента и сервера, но мы рассматриваем их по отдельности^¹⁰. Эти состояния следующие:

LISTEN Ожидание запроса на соединение со стороны чужих портов и программ TCP. (пассивно открытое соединение)

SYN-SENT Ожидание парного запроса на установление соединения. С нашей стороны запрос уже сделан (запрос посылается после активного открытия соединения).

SYN-RECEIVED Ожидание подтверждения после того, как запрос соединения уже принят и отправлен (пассивно открытое соединение получило сегмент с установленным флагом SYN, ответило сегментом с установленными флагами SYN и ACK).

ESTABLISHED Состояние открытого соединения, принимаемые данные можно представить пользователю. Это нормальное состояние соединения в фазе передачи данных.

FIN-WAIT-1 Ожидание запроса от чужой программы TCP, или подтверждения ранее отправленного запроса на закрытие соединения.

FIN-WAIT-2 Ожидание запроса на закрытие соединения со стороны чужой программы TCP.

CLOSE-WAIT Ожидание запроса на закрытие соединения со стороны своего клиента.

CLOSING Ожидание подтверждения со стороны чужой программы TCP запроса о закрытии соединения.

LAST-ACK Ожидание запроса на закрытие соединения, ранее отправленного чужой программе TCP (запрос включал также подтверждение получения чужого запроса на закрытие соединения).

TIME-WAIT Ожидание, когда истечет достаточное количество времени и можно быть уверенным, что чужая программа TCP получила подтверждение своего запроса на закрытие соединения.

CLOSED Состояние полного отсутствия соединения.

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

Клиент (Client, C)	Сеть	Сервер (Server, S)
ПО	TCP		TCP	ПО
	CLOSED		CLOSED	OPEN(passive)
	CLOSED		LISTEN
OPEN(active)	CLOSED		LISTEN
	SYN-SEND		LISTEN
	ESTEBLISED		SYN-RECIVED
	ESTEBLISED		ESTEBLISED
	ESTEBLISED	Двухсторонний обмен данными	ESTEBLISED
CLOSE	ESTEBLISED		ESTEBLISED
	FIN-WAIT-1		ESTEBLISED
	FIN-WAIT-2		CLOSE-WAIT
	FIN-WAIT-2	 передача только от S к C	CLOSE-WAIT
	FIN-WAIT-2		CLOSE-WAIT	CLOSE
	CLOSING		LAST-ACK
	TIME-WAIT		CLOSED
	CLOSED		CLOSED

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

Концепция периода молчания в протоколе TCP

Мы уже затронули временные параметры – таймаут повторной передачи (retransmission; RTO). Поскольку в протоколе TCP не предусмотрено отрицательное подтверждение, единственным признаком необходимости повторной передачи является неполучение положительного до истечения этого таймаута.

Поскольку TCP пользуется транспортными услугами IP понятно, что еще одним параметром, имеющим значение времени будет значение, устанавливаемое в поле TTL IP-пакета (Maximum Segment Lifetime – MSL). Согласно RFC-793 MSL=2 мин, многие авторы считают такое время жизни избыточным, и предлагают ограничить его1 мин, 30 с, или даже меньшим значением.

С ним напрямую связан FIN_WAIT-таймер – таймаут между закрытием соединения и переходом в состояние CLOSED (разрушением TCB), равный 2 MSL.

Еще один таймаут связан с ситуацией, когда получатель заявил нулевое окно, что соответствует запрету передачи. Рекомендация RFC-793 определяет, что в этом случае, когда надобность в запрете миновала, получатель должен уведомить об этом отправителя, послав сегмент с ненулевым значением ширины окна, что позволит отправителю возобновить свою работу. Но этот сегмент может быть утерян, и в этом случае дальнейшая работа окажется заблокированной. Для исключения блокировки используется таймер запросов (persist timer). Таймер запускается каждый раз, когда получен сегмент с window=0. По истечении времени этого таймера отправитель пошлет сегмент с данными (хотя бы один байт) адресату. Отклик на этот сегмент будет содержать новое значение ширины окна.

Наконец, таймер контроля работоспособности (keepalive) регистрирует факты выхода из строя ЭВМ-партнеров, либо утрату связности. Время по умолчанию равно 2 часам. При получении любого сегмента таймер сбрасывается и запускается вновь. По истечении времени таймера партнеру посылается сегмент проверки состояния. Если в течение 75 секунд не будет получен отклик, сервер повторяет запрос 10 раз с периодом 75 сек. Если ответ так и не получен, соединение разрывается. Keepalive-таймер не является частью TCP-спецификации. Этот таймер является средством ликвидации соединения, когда оно по каким-либо причинам не было нормально завершено.

Blog