Протоколы TCP и UDP

 

Дуплексные сетевые службы

 

Как уже отмечалось, соединение TCP является дуплексным. Это значит, что данные следуют одновременно в обоих направлениях. Данные, следующие в одном направлении, совершенно не зависят от данных, следующих в противоположном. Поскольку обмен данными TCP является дуплексным, TCP-модулям необходимо подсчитывать получаемые и передаваемые данные раздельно, и номера последовательности для обоих потоков будут разными.

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

Рис. .7. Идентификация данных и их поток с точки зрения TCP-модуля клиента 137

Окончание соединения TCP

 

Соединение TCP заканчивается обменом пакетами, состоящего из двух стадий. Каждая из сторон, как сервер, так и клиент, может предложить другой закончить соединение. Для этого сторона-инициатор обмена высылает пакет с установленным флагом «окончание обмена» (FIN). В силу дуплексной природы протокола TCP оба потока данных независимы, и должны быть завершены по отдельности. Если вам приходилось программировать в UNIX, последнее утверждение предыдущего абзаца может показаться подозрительным. Когда в UNIX закрывается соединение, дальнейший обмен по нему становится невозможен. Соединение TCP работает по-другому. Даже после закрытия соединения (завершения передачи данных) одной из сторон соединения она в состоянии продолжать прием данных от другой стороны соединения.

Мысль принимать данные после закрытия соединения кажется странной на первый взгляд. На самом деле, установленный в пакете флаг FIN является сигналом, означающим, что одна сторона прекратила передачу данных. Приход сообщения-подтверждения от другой стороны означает, что обе стороны договорились прекратить обмен данными в одном направлении. Начиная с этого момента одна из сторон соединения будет молчаливо принимать данные, не делая никаких замечаний по их поводу, а другая молчаливо посылать, не ожидая никаких комментариев. Окончание (закрытие) TCP-соединения — двухступенчатый процесс. Одна сторона выполняет активное закрытие, а другая — пассивное. Закрытие активно, если вызвано по инициативе данной стороны, и, наоборот, пассивно, если вызвано противоположной стороной соединения. Сторона, первой высылающая пакет с установленным флагом «окончание соединения», является активной. Как правило, модуль TCP, принявший пакет с установленным флагом «окончание соединения», инициирует пассивное окончание соединения. Это просто значит, что пассивная сторона также посылает сообщение с установленным флагом окончания. Другими словами, сторона, принявшая сообщение об окончании первой, отвечает: «Хорошо, если тебе нечего больше послать, то и мне тоже нечего послать тебе». После того как обе стороны выслали друг другу сообщения об окончании и получили подтверждения о доставке этих сообщений, соединение TCP считается действительно законченным (закрытым).

 

Что такое закрытие «наполовину»?

 

Вы уже знаете, что в силу дуплексной природы TCP-соединения, в то время как поток данных в одну из сторон закончен, он может сохраняться в обратном направлении. Такое окончание лишь одного потока называется закрытием «наполовину» (half-close). Лишь очень немногие приложения TCP нуждаются или используют закрытие «наполовину». Однако если в ваши планы входит разработка приложений Интернет, эта возможность может когда-нибудь и пригодиться.

 

Что такое заголовок TCP?

 

Из рис. 5.8 видно, что структура TCP-заголовка намного сложнее, нежели у UDP. В следующих абзацах изучается назначение полей, составляющих TCP-заголовок.

Рис. 8. Структура сегмента (сообщения) TCP

Порт источника и порт получателя

16-битные поля источника и  получателя однозначно определяют  посылающие и Принимающие данные  приложения или прикладные протоколы. Номера портов источника и  получателя в совокупности с IP-адресами  сетевых компьютеров (в IP-заголовке) однозначно идентифицируют любое TCP-соединение. Каждая из сторон TCP-соединения  называется сокетом (socket).

Номер последовательности

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

Номер подтверждения

32-битное поле номера подтверждения  обозначает байт данных, который  принимающая сторона рассчитывает получить следующим в потоке данных. Например, если последний принятый байт имел номер 500, модуль TCP установит номер подтверждения равным 501.

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

Как и в заголовке IP, поле длины заголовка TCP состоит из четырех битов, обозначающих длину заголовка, измеренную в 32-битных словах. Как и заголовок IP, заголовок TCP обычно имеет длину в 20 байтов. Область данных начинается сразу после заголовка TCP. Таким образом, модуль TCP определяет место, где начинаются данные и кончается заголовок, просто прибавляя поле «длина заголовка», умноженное на четыре байта (32 бита), к первому байту сегмента данных.

Флаги

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

Флаг URG

Данный флаг сообщает принимающему модулю TCP о том, что. указатель на данные, требующие немедленной обработки, в поле «неотложные данные» установлен, то есть указывает на них. (Модуль TCP должен обработать неотложные данные до того, как обрабатывать что-либо еще.)

Флаг АСК

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

Флаг PSH

Установленный флаг PUSH требует от принимающего модуля TCP вытолкнуть (push), то есть немедленно выслать принятый сегмент данных приложению-получателю. Как правило, модуль TCP буферизует принимаемые данные. То есть он не доставляет каждый сегмент по отдельности, а ждет, пока его буфер наполнится, а затем доставляет все принятые сегменты за один раз. Флаг PSH запрещает размещать сегменты данных в буфере. Telnet, например, устанавливает этот флаг. Нажатия на клавиши пользователем незамедлительно попадают на сервер Telnet, с которым он работает. Такое поведение устраняет возможные задержки в выдаче эха от сервера — большинство пользователей Telnet желают сразу видеть на экране то, что они печатают.

Флаг RST

Данный флаг запрашивает у принимающего модуля TCP сброс соединения. TCP устанавливает флаг RST, если с соединением случилась какая-либо проблема. Большинство приложений просто прекращает работу, приняв этот флаг. Флаг RST может применяться в сложных разработках для контроля повреждений в сети, сбоев в работе оборудования и сетевых программ.

Флаг SYN

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

Флаг FIN

Флаг сообщает принимающему модулю TCP о том, что источник закончил передавать данные. Вы знаете, что этот флаг заканчивает соединение только в том направлении, в каком был послан. Чтобы закончить соединение полностью, принимающий модуль TCP должен также послать сообщение с установленным флагом FIN.

Размер окна

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

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

Как и в случае UDP, 16-битное поле контрольной суммы TCP содержит сумму, вычисленную по области данных. Протокол требует от передатчика, чтобы он включил вычисленную контрольную сумму в поле, а от приемника — чтобы он вычислил ее повторно и сравнил результаты.

Примечание: Контрольные суммы UDP и TCP вычисляются похожим образом. Однако в случае UDP включать контрольную сумму в датаграмму не обязательно. Напротив, протокол TCP обязывает вставлять контрольную сумму в каждый переданный сегмент данных.

Указатель неотложных данных

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

Дуглас Камер во втором издании классического труда «Межсетевое взаимодействие сетей на базе TCP/IP* (Internetworking with TCP/IP, Volume 1, Prentice Hall, 1991) обсуждает поле «неотложные данные» в разделе 12.12, < Данные вне основной полосы пропусканиям (Out of Band Data). С другой стороны, Ричард Стивене в разделе 20.8 своей замечательной книги ^TCP/IP в иллюстрациях^ (TCP/IP Illustrated, Volume 1, Prentice Hall, 1994) пишет следующее:

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

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

^Путаница в связи с неотложными  данными TCP и данными вне основной  полосы пропускания возникает  из-за того, что предпочитаемый большинством интерфейс прикладного программирования (API) сам по себе относит данные ^для неотложной обработким к категории данных <вне основного диапазонам,

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

<Идет продолжительный спор  о том, должен ли указатель  неотложных данных указывать на последний байт этих данных или на байт, следующий за последним. Первоначальный стандарт TCP позволял толковать это двояким образом, однако RFC, посвященный обязательным рекомендациям для сетевых компьютеров, вносит ясность в это дело, утверждая, что указатель все-таки указывает на последний байт данных для немедленной обработки.

Проблема, однако, в том, что большинство реализации сетевых операционных систем (т. н. производные операционной системы Беркли) продолжают использовать неверное представление. Получается, что вполне лояльное по отношению к стандарту TCP сетевое приложение не сможет работать с большинством остальных сетевых компьютеров^.

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

Так же как и у IP, заголовок TCP содержит необязательное поле «опции» (options). В ходе установления соединения модули TCP договариваются о максимальной длине сегмента (MSS) и устанавливают соответствующую опцию. Смысл максимальной длины сегмента тот же, что и у максимальной длины передаваемого блока (MTU) физического уровня сети. Максимальная длина сегмента определяет максимальный размер сегмента, который может быть передан по соединению TCP. TCP оптимизирует пропускную способность сети, увеличивая ее производительность. Опция максимальной длины сегмента позволяет воспользоваться самым большим размером блока данных, который еще можно передать. Опция MSS устанавливается только в тех сообщениях, в которых уже установлен флаг SYN. Однако опция MSS не является предметом обсуждения между обоими модулями. Каждый из модулей TCP просто сообщает другому тот MSS, который он в состоянии принять. Если модуль TCP по каким-либо причинам не передает MSS, его партнер считает, что нужно пользоваться MSS, равным по умолчанию 536 байтам.

 

Что такое инкапсуляция?

 

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

Эта и две предыдущие главы познакомили вас с различными уровнями сети на базе TCP/IP. В этих главах также описываются интерфейсы между сетевыми уровнями и протоколами TCP/IP. Процесс перемещения данных сквозь стек протоколов на самом деле представляет собойих инкапсуляцию. Инкапсуляция данных — это их форматирование таким образом, чтобы они удовлетворяли тому или иному протоколу. По мере прохождения сквозь стек протоколов данные инкапсулируются в тот формат, с которым умеет работать очередной сетевой уровень. На рис. 5.9 процесс прохождения данных сквозь стек протоколов изображен целиком.

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