Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Мир TCP/IP. Протоколы UDP и TCP

С.Д. Рябко, Н.В. Царев

В предыдущей статье1 мы достаточно подробно обсудили протоколы сетевого (internet) уровня. Теперь, переходя к транспортному (transport) уровню, хотелось бы еще раз обратиться к общей структуре протоколов семейства TCP/IP, чтобы уяснить задачи, решаемые протоколами разных уровней.

Еще раз об уровнях управления...

Стандартизация в сообществе Internet2 базируется на документах RFC (Requests For Comments). Все заслуживающие внимания материалы делаются общедоступными (и бес- платными!) через электронную почту, файловые серверы или другими способами внутри Internet в виде RFC.

Основной структурой Internet, ведающей вопросами стандартизации и принимающей стандарты RFC, является IETF (Internet Engineering Task Force) — международная организация, разбитая на большие секции (по направлениям), внутри которых в свою очередь формируются рабочие группы (по задачам). Существующая практика принятия проекта RFC базируется на необходимости нескольких независимых реализаций предлагаемой концепции.

Другой крупный "производитель" коммуникационных протоколов — международная организация по стандартизации (ISO), которая на межгосударственном уровне согласует и затем принимает международные стандарты. Интересно, что с лета 1995 г. ISO, несмотря на то что является межправительственной некоммерческой организацией, финансируемой за счет налогов, начала распространять свои стандарты исключительно за деньги. Подход к утверждению стандартов у ISO отличается от принятого в Internet. Для ISO характерны глубокая теоретическая проработка и очень строгое формальное описание принимаемых документов. В какой-то степени это напоминает конкуренцию промышленных групп и академических учреждений. Академический подход основательно проработан, теоретически обоснован и дает перспективу на многие годы вперед, но ...все (или многие) де-факто используют промышленные стандарты, которые, может быть, не столь хороши, но зато поддерживаются практически всеми. При рассмотрении иерархии протоколов семейства TCP/IP мы сознательно привели пятиуровневую концептуальную модель, специфицированную в стандартах RFC 791 и RFC 1349, а не семиуровневую модель Взаимодействия открытых систем (OSI). Тому есть две причины.

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

Выделение сеансового уровня можно считать оправданным для коммуникационных приложений, предполагающих ярко выраженные процедуры установления сеанса (login), его завершения и повторной синхронизации. Наиболее распространенными приложениями этого класса являются терминальные. Однако для тех приложений, которые обходятся рассылкой коротких дейтаграммных сообщений или работают в режиме промежуточного накопления информации (store and forward), функциональность сеансового уровня выглядит неактуальной.

Вызывает определенные со-мнения и необходимость выделения представительского уровня как отдельного уровня коммуникационного управления. Если функциями этого уровня являются сжатие, конвертирование и кодирование данных, то почему их необходимо выделять как отдельный слой управления сетью? Кроме того, функции сжатия и кодирования "размазаны" и по другим уровням (вспомним, например, модемные протоколы и стандарты, относящиеся к канальному уровню). Если же функции представитель-ского уровня заключаются в определении форматов данных, то это архитектурное решение также выглядит несколько натянутым: распознавать структуры данных — дело приложений, формирующих и обрабатывающих эти данные, но никак не коммуникационных протоколов, обеспечивающих их передачу.

Вторая причина. Мы воздержались от прямой параллели между моделями OSI и TCP/IP также и из-за определенных различий в функциональном наполнении одноименных уровней. Следует, правда, отметить, что эти различия находят выражение скорее в реализациях конкретных стандартов, чем в абстракции архитектурных концепций.

Реализационным "отражением" протоколов TCP/IP в мире ISO является семейство протоколов Х.25, имеющее ряд существенных архитектурных отличий от TCP/IP.

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

Далее, в Х.25 (как в семействе протоколов) более жестко декомпозированы функции различных уровней управления. Смысл уровневой декомпозиции управления вообще достаточно прост: она позволяет раздельно решать задачи управления для каждого из уровней, что существенно облегчает проектирование, разработку и отладку ПО. Однако такой подход имеет и обратную сторону: требование независимости различных уровней заставляет обеспечивать необходимый максимум функциональности на каждом из них, поскольку заранее неясно, будет ли эта функциональность гарантирована сопредельными уровнями. Протоколы Х.25 полностью следуют этой философии. Они дублируют ряд функций, таких, как подсчет контрольных сумм и установка таймеров на ожидание событий, на канальном и сетевом уровнях, что увеличивает накладные расходы и снижает эффективность протоколов в целом. Кроме того, служба сетевого уровня Х.25 предоставляет транспортные услуги повышенного качества, гарантируя доставку информации и сохраняя целостность потока данных.

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

Задача же обеспечения надежности связана с подтверждением доставки (квитированием) информации. Квитирование предполагает наличие таймеров на ожидание подтверждений (квитанций). Таймеры и очереди пакетов, ожидающих квитанций, "съедают" ресурсы системы, и если бы IP решал эту задачу на каждом узле сети, то все семейство протоколов TCP/IP умерло бы во младенчестве и мир познал бы радость общения при помощи такой сети, как Internet, лет на 20—30 позже.

К счастью, все сложилось иначе, и разноуровневые протоколы семейства TCP/IP решают существенно различные задачи: уровни hardware и network interface обеспечивают доставку информации между узлами IP-сети; сетевой уровень (протокол IP) принимает дейтаграммы из одних каналов связи и "перекладывает" их в другие (или отдает транспортному протоколу); транспортный уровень решает задачи надежности доставки, сохранения порядка (целостности) потока данных и передачи информации получателям.

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

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

Проблема определения получателя

Получателем сообщения коммуникационного протокола является прикладная задача (или просто задача, или приложение, или, как называют задачу в многозадачных ОС, процесс). Предположим, что мы обращаемся к удаленному серверу UNIX с некоторым запросом. Как в этом случае идентифицировать процесс-получатель нашего сообщения? Ведь UNIX — многозадачная ОС, следовательно, на нашем сервере может существовать множество процессов. Более того, состав процессов может меняться динамически: они могут создаваться и уничтожаться, и даже при установке связи с некоторым процессом нельзя быть уверенным в том, что во время работы он не будет прерван или уничтожен (на-пример, вследствие перезагрузки машины).

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

Все задачи можно условно разделить на две большие группы — известные всем (well-known) и прочие. К известным относятся задачи (или сервисы, как их часто называют в сетевых приложениях), получившие повсеместное распространение, такие, как FTP, TELNET и другие. Для них существуют заранее определенные порты, закрепленные в стандартах Internet. Это так называемые well-known numbers. Выделением номеров заранее определенных портов занимается организация IANA (Internet Assigned Numbers Authority).

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

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

Определение получателя (говорят: демультиплексирование потока сообщений) — одна из главных задач транспортных протоколов. В семействе TCP/IP таких протоколов два. Начнем с более простого.

User Datagram Protocol (UDP)

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

Сообщение протокола UDP называют пользовательской дейтаграммой (user datagram). Как обычно, оно состоит из заголовка и блока данных. Заголовок пользовательской дейтаграммы состоит из четырех 16-битовых полей (рис. 1).

Поля UDP SOURCE PORT и UDP DESTINATION PORT определяют протокольные порты процесса-отправителя и процесса-получателя. Поле UDP SOURCE PORT имеет содержательное заполнение только в том случае, если процесс-отправитель должен получить ответное сообщение; в противном случае оно заполняется нулями.

Поле UDP MESSAGE LENGTH указывает полную длину (в октетах) заголовка и блока данных пользовательской дейтаграммы.

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

1. Блок данных сообщения дополняется нулями до целого числа 16-битовых слов.

2. Поле заголовка UDP CHECSUM заполняется нулями.

3. Перед сообщением помещается псевдозаголовок, структура которого показана на рис. 2.

4. Расчет контрольной суммы производится по всей этой совокупности данных, после чего снимаются псевдозаголовок и дополнение нулями, значение контрольной суммы помещается в соответствующее поле заголовка, а дейтаграмма передается протоколу IP.

Для проверки контрольной суммы хост-получатель дейтаграммы UDP производит аналогичные операции.

Расчет контрольной суммы — операция факультативная: заполнение поля UDP CHECKSUM нулями понимается как отказ от расчета контрольной суммы. Для того, чтобы этот отказ отличался от того (редкого, но возможного) случая, когда рассчитанная контрольная сумма равна нулю, в последнем случае все биты поля UDP CHECKSUM устанавливаются в состояние 1.

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

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

Transmission Control Protocol (TCP)

Основные понятия

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

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

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

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

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

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

Соединение: порты, протоколы, оконечные точки

TCP, подобно UDP, использует протокольные порты для доступа к тем или иным прикладным задачам (процессам). Однако, в отличие от UDP, TCP является протоколом с установлением соединения, т. е. для передачи данных от одного приложения к другому необходимо установить соединение. Соединение идентифицируется двумя оконечными точками (end points), каждая из которых определяется парой значений (IP-адрес,протокольный порт).

В какой-то степени хорошей иллюстрацией TCP является телефония: вызывающий абонент знает номер АТС (аналог IP-адреса), т. е. старшую часть телефонного номера, и номер абонента (аналог номера порта) — младшую часть телефонного номера. Для организации разговора достаточно знать только один телефонный номер, вызываемого абонента. Аналогично вызывающая программа не обязана иметь заранее определенный порт, она его просто сообщает вызываемой стороне для "поддержания разговора". Вполне обычны ситуации, когда несколько абонентов могут получить определенную услугу одновременно по одному номеру телефона (так называемые многоканальные телефоны устанавливаются в справочных службах). В мире компьютеров подобное реализуется с помощью специально написанных программ, так называемых демонов, которые "слушают" некоторый порт и при приходе запроса на него организуют процесс-потомок, являющийся копией родительского процесса. После порождения потомка родитель переходит в режим ожидания нового соединения. По окончании соединения потомок завершается. Ясно, что каждое соединение ((IP-адрес1,порт1), (IP-адрес2,порт2)) остается уникальным.

В приведенной выше аналогии с телефонной связью есть еще одно сходство: TCP не заботится о способе (и маршруте!) доставки пакетов, точно так же, как мы не задумываемся о том, как именно наш вызов достиг нужного абонента. Отличие от телефонии заключается в том, что доставляющий пакеты протокол IP не фиксирует маршрут их доставки. Для установившегося соединения каждый IP-пакет, переносящий TCP-пакет, может передаваться своим путем.

Установление соединения

Как говорилось выше, соединение идентифицируется парой оконечных точек. Однако его нельзя отождествлять с этим идентификатором. Соединение — это логическая структура протокола ТСР, которая организуется для передачи данных между двумя оконечными точками.

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

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

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

Обеспечение надежной доставки данных

Протокол ТСР обеспечивает надежную доставку информации в том смысле, что он организует прямое подтверждение корректного приема информации получателем. Однако в организации передачи данных и подтверждении их приема (квитировании) есть много любопытного и поучительного.

Простая схема квитирования

Отправитель шлет получателю некоторую порцию данных. В процессе доставки данные могут быть утеряны или искажены, поэтому получатель, если, конечно, он получил данные, должен произвести проверку их корректности. Делается это путем расчета контрольной суммы. Не вдаваясь в детали, скажем, что для расчета контрольной суммы по своему сообщению (которое у ТСР называется сегментом, segment) протокол ТСР использует механизм подстановки псевдозаголовка, полностью аналогичный соответствующей операции в протоколе UDP. Формат псевдозаголовка ТСР совпадает с показанным на рис. 2 с тем отличием, что в поле PROTOCOL псевдозаголовка устанавливается код, соответствующий ТСР (число 6). Если контрольная сумма сошлась, т. е. данные получены без искажений, то агент протокола ТСР хоста-получателя шлет квитанцию — подтверждение приема; если контрольная сумма не сходится, то никакая квитанция не высылается.

Отправитель должен учитывать, что возможна потеря высланного им пакета, искажение данных или, наконец, потеря сформированной получателем положительной квитанции. Во всех трех случаях отправитель не получит никаких известий о состоянии процесса передачи информации, и ожидание квитанции может быть бесконечным. Для выхода из состояния бесконечного ожидания применяется традиционная для коммуникационных систем техника установки таймера. Она заключается в том, что отправитель, передав в канал порцию данных, "засекает время" передачи и ожидает квитанцию в течение некоторого времени с момента передачи. Период ожидания называют тайм-аутом (timeout). По истечении этого времени отправитель считает, что пакет утерян или искажен, и повторяет передачу. Такая техника называется положительным квитированием с повтором передачи (positive acknowledgement with retransmission).

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

Оптимизация длительности тайм-аута

В такой громадной сети, как Internet, нельзя, как в большинстве малых сетей, заранее принять некоторое среднее значение длительности тайм-аута на ожидание квитанций. Если тайм-аут настроен на среднюю задержку, оптимальную для локальной сети, то почти наверняка он будет слишком коротким для информационного обмена через глобальные сети. Установление же большого времени ожидания ограничит пропускную способность сети, поскольку отправитель будет слишком долго ждать подтверждений.

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

Всякий раз, отправляя сообщение, ТСР производит измерение времени до прихода квитанции, называемого временем двойного прохода (round trip time, RTT). Результаты измерений усредняются с убывающим для более ранних измерений весом.

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

Время двойного прохода измеряется только для сообщений, успешно доставленных с первой же попытки, поскольку квитанции на одну и ту же порцию данных в ТСР неразличимы и невозможно понять, пришла ли данная квитанция на первую или повторную попытку передачи. В случаях, когда квитанция вовремя не доставляется, производится увеличение (обычно удвоение) длительности тайм-аута. Для адаптации алгоритма к сетям с большим разбросом времени двойного прохода производится учет не только среднего значения, но и среднего отклонения RTT.

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

Оконное управление квитированием и передачей данных

Схема квитирования каждого пакета, показанная на рис. 3, приводит к тому, что пропускная способность канала связи используется чрезвычайно неэффективно: передача пакета может занимать, скажем, одну тысячную часть времени, в течение которого транспортный протокол бездействует, ожидая прихода квитанции. Чтобы повысить эффективность использования канала, применяется следующий прием: отправителю разрешается послать некоторое количество, например N, единиц информации (пакетов) до получения квитанции на первый пакет. После получения квитанции на первый пакет разрешается отправить пакет N+1 и т.д. Описанную технику передачи данных называют методом скользящего окна (sliding window), а число пакетов N, передаваемых в сеть до получения квитанции на первый пакет, — размером окна, или просто окном.

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

Этот механизм эффективно используется протоколом ТСР. Точнее, оконное управление в ТСР обеспечивает решение двух совершенно разнородных задач защиты сети от перегрузок.

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

Вторая задача — защита от перегрузки буфера у протокола ТСР, принимающего данные. Протокол-приемник, квитируя некоторую порцию данных, сообщает протоколу-источнику, какую следующую порцию он готов бесконфликтно принять. Тем самым обеспечивается защита приемного устройства от перегрузки даже в тех случаях, когда источник и приемник информации имеют существенно различную производительность, например, когда передачу ведет суперкомпьютер, а прием — устаревшая модель ПК. Этот метод называют декларацией приемного окна (window advertisement). Если протокол-приемник "не справляется" с входящим потоком, то он может декларировать окно нулевого размера, отказываясь тем самым от приема информации.

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

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

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

Реализация передачи данных в ТСР: потоки, сегменты, квитирование

Мы уже говорили, что ТСР принимает от приложения данные в виде неструктурированного потока. Они буферизуются и передаются получателю в виде сообщений, называемых сегментами. Длина сегмента является, строго говоря, величиной переменной, однако в программных реализациях протокола ее часто подстраивают таким образом, чтобы сегмент "укладывался" в одну IP-дейтаграмму, а ее длину согласуют с длиной максимального блока данных (maximum transfer unit, MTU) физической сети. Эти настройки по-зволяют снизить накладные расходы на фрагментацию и таким образом повысить эффективность протокола. ТСР производит оконное управление квитированием, однако реализовано оно не на уровне пакетов, в виде описанной выше упрощенной модели, а, скорее, на уровне байтов.

Скользящее окно определяется над буфером передаваемых данных при помощи трех указателей (рис. 4). Длина окна — это расстояние между указателями А и С. В примере, приведенном на рисунке, данные от начала потока до указателя А (октеты 1 и 2) переданы получателю и квитированы; данные между указателем А и В (октеты 3 – 6) переданы в сеть, но еще не квитированы; данные между указателями В и С еще не переданы, но их передача разрешена до прихода квитанций на октеты 3 – 6; данные, следующие за указателем С, нельзя передавать до прихода этих квитанций.

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

Такая схема квитирования потока называется кумулятивной. Ее достоинства — надежность и простота программной реализации. Недостаток схемы в том, что при восстановлении порядка приема сегментов или при утере некоторого сегмента, в случае возникновения разрыва в принимаемом потоке, относительно высока вероятность ненужной повторной ретрансляции фрагмента данных, следующего за разрывом. Механизм такого повтора показан на рис. 5.

Структура сегмента ТСР

Сегмент ТСР состоит из заголовка и блока данных. Заголовок сегмента ТСР показан на рис. 6.

Поля SOURCE PORT и DESTINATION PORT, как и в протоколе UDP, используются для определения процесса-отправителя и процесса-получателя сообщения.

Поле SEQUENCE NUMBER определяет последовательный номер октета в потоке и служит для контроля порядка следования сегментов и корректного восстановления потока данных получателем.

Поле ACKNOWLEDGEMENT NUMBER в соответствии с обсужденной выше схемой квитирования потока данных содержит номер октета, который получатель намерен принять следующим.

Поле HLEN определяет длину заголовка сегмента ТСР, измеренную в 32-битовых словах. Отметим, что длина заголовка сегмента не фиксирована и может изменяться в зависимости от значений, устанавливаемых в поле OPTIONS.

Поле RESERVED зарезервировано для последующего использования.

Поле CODE BITS содержит определяющие тип сообщения служебные биты, которые поименованы и расположены (слева направо) в следующем порядке:

l URG (urgent) — срочное сообщение;

l ACK (acknowledgement) — квитанция на принятый сегмент данных;

l PSH (push) — требование отправки сообщения без ожидания заполнения буфера;

l RST (reset) — запрос на переустановку соединения;

l SYN (synchronization) — синхронизация счетчиков переданных данных (используется для установления соединения);

l FIN (finish) — передающий протокол указывает, что достиг последнего байта в потоке.

Установка 1 обозначает активное состояние соответствующего служебного бита.

Поле WINDOW заголовка сегмента служит для декларации приемного окна (в байтах).

В поле CHECKSUM помещается контрольная сумма, рассчитанная по сегменту и псевдозаголовку.

Поле URGENT POINTER используется совместно с управляющим битом URG. Число, помещаемое в это поле, указывает на конец срочных данных в потоке. О них говорят, что они передаются вне потока (out of band).

Поле OPTIONS используется для решения вспомогательных задач, например таких, как оптимизация передачи путем выбора максимального размера сегмента (maximum segment size, MSS).

Поле PADDING используется для доведения размера заголовка до целого числа 32-битовых слов.

Протокольная машина TCP

Лучшим способом описания коммуникационного протокола безусловно является не вышеприведенное неформальное изложение, а та или иная форма строгого описания распределенного алгоритма. Одним из наиболее удачных формальных представлений является описание протокола как конечного автомата (иногда, используя дословный перевод с английского, его называют протокольной машиной). Конечный автомат ТСР показан на рис. 7. К сожалению, объем и задачи данной статьи не позволяют подробно истолковать эту модель, поэтому мы сделаем самые краткие пояснения.

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

Изначально протокол ТСР находится в состоянии CLOSED — состоянии пассивного ожидания, когда компьютер включен, реализующее протокол ПО загружено, но информация не принимается и не передается.

Далее от ОС может поступить запрос на установление соединения: на прием (passive open) или на передачу (active open).

Запрос passive open переводит протокол в состояние ожидания приема LISTEN, в котором протокол ожидает установления соединения; а запрос active open — в состояние передачи инициализирующего соединение сообщения SYN_SENT. Установление соединения производится в три этапа; диаграмма взаимодействий для этого процесса показана на рис. 8.

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

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

Однако действия приемной стороны этим не исчерпываются. Поскольку ТСР — полнодуплексный протокол, то приемной стороне необходимо инициализировать поток в обратную сторону. Поэтому в ответном сообщении она также устанавливает управляющий бит синхронизации потока SYN и присваивает счетчику потока в обратном направлении некоторое начальное значение у.

Получив это сообщение, протокол-инициатор соединения должен подтвердить факт получения им квитанции и корректной инициализации направленного к нему потока. Для этого он формирует сегмент, в котором устанавливает бит квитирования ACK и передает номер ожидаемого им следующего байта потока у+1.

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

Процесс завершения соединения, как и установления, трехступенчатый. Диаграмма состояний для него показана на рис. 9.

Инициатор завершения соединения формирует сегмент-запрос, в котором устанавливает в 1 бит FIN и указывает состояние счетчика передаваемого им потока, равного х. Его партнер формирует сообщение, подтверждающее прием х байт потока (ACK, x+1), после чего обращается к своему приложению, информируя его о завершении соединения (в это время он находится в состоянии CLOSED_WAIT). Затем, получив санкцию приложения, повторно квитирует полученный запрос на завершение соединения, но уже установив бит FIN (FIN+ACK, x+1). На это сообщение протокол-инициатор завершения соединения отвечает квитанцией, указывающей состояние счетчика потока в обратном направлении (формирует и отправляет сегмент ACK, y+1). Инициатор завершения соединения проходит при этом через состояния ожидания обеих квитанций FIN_WAIT_1 и FIN_WAIT_2.

Состояние TIME_WAIT есть не что иное, как защита от потери квитанций в процессе завершения соединения. В случае неприхода одной или обеих квитанций на сообщение FIN по истечении определенного времени (обычно оно равно двукратному времени жизни пакета в сети) протокол самостоятельно принимает решение о завершении соединения и переходит в состояние CLOSED.

На этом мы завершаем разговор о базовых протоколах семейства TCP/IP и позже поговорим о приложениях, сетевом управлении и прочих, зачастую не менее интересных, чем протоколы IP и TCP, вещах.


распечатать статью

купить тротуарную плитку в воронеже по умеренным расценкам




  
2 '1996
СОДЕРЖАНИЕ

колонка редактора

• Сладкие сети

локальные сети

• Сценарии входа в сеть

• Высокоскоростные сетевые адаптеры

• Службы NetWare и новые средства разработки приложений

• Cisco и 3Com в одном проекте

• Массивы RAID: емкость и производительность

корпоративные сети

• "Штормящая" сеть

• Суперсерверы широкого пользования

• Catalyst 5000 фирмы Cisco

• Сетевая ловушка, или Платформы управления

• Установка и настройка средств удаленного доступа Windows 95

услуги сетей связи

• Пейджеры

• Беспроводные мосты

приложения клиент-сервер

• Стратегия многопроцессорной обработки

• Доступ к базам данных по низкоскоростным каналам

открытые системы

• Мир TCP/IP. Протоколы UDP и TCP

• Как улучшить Web-страницу?

защита данных

• Руководство по выбору ИБП

• Голосование без обмана

новые продукты

• Семейство BayStack, Цветные струйные принтеры DeskJet 1600C и DeskJet 1600CM, Дисковый массив StorageWorks RAID Array 230 ...



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх