Главная | Обратная связь | Поможем написать вашу работу!

Доклад 4 (Лекция 4). Протокол TCP

Протокол TCP рассматривается в этом курсе подробно, т.к. является базовым для Интернет.

Протокол TCP (transmission control protocol, RFC-793, -1323) в отличии от udp осуществляет доставку дейтаграмм, называемых сегментами, в виде байтовых потоков с установлением соединения. Протокол TCP применяется в тех случаях, когда требуется гарантированная доставка сообщений. Он использует контрольные суммы пакетов для проверки их целостности и освобождает прикладные процессы от необходимости таймаутов и повторных передач для обеспечения надежности. Для отслеживания подтверждения доставки в TCP реализуется алгоритм "скользящего" окна. Наиболее типичными прикладными процессами, использующими TCP, являются FTP (file transfer protocol - протокол передачи файлов) и telnet. Кроме того, TCP используют системы SMTP, HTTP. Внутренняя структура модуля TCP гораздо сложнее структуры UDP. Подобно UDP прикладные процессы взаимодействуют с модулем TCP через порты. Под байтовыми потоками здесь подразумевается то, что один примитив, например, read или write может вызвать посылку адресату последовательности сегментов, которые образуют некоторый блок данных (сообщение).

Примером прикладного процесса, использующего ветвь TCP, может служить FTP, при этом будет работать стек протоколов ftp/tcp/ip/ethernet. Хотя протоколы UDP и TCP могли бы для сходных задач использовать разные номера портов, обычно этого не происходит. Модули TCP и UDP выполняют функции мультиплексоров/демультиплексоров между прикладными процессами и IP-модулем. При поступлении пакета в модуль IP он будет передан в TCP- или UDP-модуль согласно коду, записанному в поле протокола данного IP-пакета. Если IP-протокол работает с адресами, то TCP, также как и UDP, с портами. Именно с номеров портов отправителя и получателя начинается заголовок TCP-сегмента.

Рис. Формат TCP-сегмента

Поле код позиции в сообщении определяет порядковый номер первого октета в поле данных пользователя. При значении флага syn=1 в этом поле лежит код isn (initial sequence number, начальное значение isn не равно нулю). Поле HLEN - определяет длину заголовка сегмента, которая измеряется в 32-разрядных словах. Далее следует поле резерв, предназначенное для будущего использования, в настоящее время должно обнуляться. Поле размер окна сообщает, сколько октетов готов принять получатель (флаг ACK=1). Окно имеет принципиальное значение, оно определяет число сегментов, которые могут быть посланы без получения подтверждения. Значение ширины окна может варьироваться во время сессии. Значение этого поля равное нулю также допустимо и указывает, что байты вплоть до указанного в поле номер октета, который должен прийти следующим, получены, но адресат временно не может принимать данные. Разрешение на посылку новой информации может быть дано с помощью посылки сегмента с тем же значением поля номер октета, который должен прийти следующим, но ненулевым значением поля ширины окна. Поле контрольная сумма предназначено для обеспечения целостности сообщения. Контрольное суммирование производится по модулю 1. Перед контрольным суммированием к TCP-сегменту добавляется псевдозаголовок, как и в случае протокола udp, который включает в себя адреса отправителя и получателя, код протокола и длину сегмента, исключая псевдозаголовок. Поле указатель важной информации представляет собой указатель последнего байта, содержащий информацию, которая требует немедленного реагирования. Поле имеет смысл лишь при флаге URG=1, отмечающем сегмент с первым байтом "важной информации". Если флаг ACK=0, значение поля номер октета, который должен прийти следующим, игнорируется. Флаг urg=1 в случае нажатия пользователем клавиш Del или Ctrl-c.

Таблица Значения бит поля флаги

Обозначение битов (слева на право) поля флаги	Значение бита, если он равен 1
urg	Флаг важной информации, поле Указатель важной информации имеет смысл, если urg=1.
ack	Номер октета, который должен прийти следующим, правилен.
psh	Этот сегмент требует выполнения операции push. Получатель должен передать эти данные прикладной программе как можно быстрее.
rst	Прерывание связи.
syn	Флаг для синхронизации номеров сегментов, используется при установлении связи.
fin	Отправитель закончил посылку байтов.

Поле опции зарезервировано на будущее и в заголовке может отсутствовать, его размер переменен и дополняется до кратного 32-бит с помощью поля заполнитель.

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

1. Клиент посылает SYN-сегмент с указанием номера порта сервера, который предлагается использовать для организации канала связи (active open).

2. Сервер откликается, посылая свой SYN-сегмент, содержащий идентификатор (ISN - initial sequence number). Начальное значение isn не равно нулю. Процедура называется passive open.

3. Клиент отправляет подтверждение получения syn-сегмента от сервера с идентификатором равным ISN (сервера)+1.

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

Алгоритм установления связи. В рамках представлены состояния клиента и сервера; пунктиром отмечены изменения cостояния после посылки сообщения

Префикс S на рисунке указывает на сервер, а С - на клиента. Параметры в скобках обозначают относительные значения ISN. После установления соединения ISN(S) = s_seq_1, а ISN(C) = c_seq_1.

Каждое соединение должно иметь свой неповторимый код ISN. Для реализации режима соединения прикладная программа на одном конце канала устанавливается в режим пассивного доступа ("passive open"), а операционная система на другом конце ставится в режим активного доступа ("active open"). Протокол TCP предполагает реализацию 11 состояний (established, closed, listen, syn_sent, syn_received и т.д. (см. RFC-793), переход между которыми строго регламентирован. Машина состояний для протокола TCP может быть описана диаграммой. Здесь состояние closed является начальной и конечной точкой последовательности переходов. Каждое соединение стартует из состояния closed. Из диаграммы машины состояний видно, что ни одному из состояний не поставлен в соответствие какой-либо таймер. Это означает, что машина состояний TCP может оставаться в любом из состояний сколь угодно долго. Исключение составляет keep-alive таймер, но его работа является опционной, а время по умолчанию составляет 2 часа. Это означает, что машина состояния может оставаться 2 часа без движения. В случае, когда две ЭВМ (C и S) попытаются установить связь друг с другом одновременно, реализуется режим simultaneous connection (RFC-793). Обе ЭВМ посылают друг другу сигналы SYN. При получении этого сигнала партнеры посылают отклики SYN+ACK. Обе ЭВМ должны обнаружить, что SYN и SYN+ACK относятся к одному и тому же соединению. Когда C и S обнаружат, что SYN+ACK соответствует посланному ранее SYN, они выключат таймер установления соединения и перейдут непосредственно в состояние syn_recvd.

В состоянии established пакет будет принят сервером, если его ISN лежит в пределах s_ack, s_ack+s_wind (s_wind - ширина окна для сервера). Аналогичный диапазон isn для клиента выглядит как: c_ack, c_ack+c_wind (c_wind - ширина окна для клиента). c_wind и s_wind могут быть не равны. Пакеты, для которых эти условия не выполняются, будут отброшены.

Рассмотрим пример установления соединения для случая FTP-запроса. Пусть клиент С запускает процесс установления FTP-соединения с сервером s. Обычный порядок установления соединения:

c -> s:syn(isn_c)
s -> c:syn(isn_s), ack(isn_c)
c -> s: ack(isn_s) (Связь установлена)
c -> s: данные
и/или
s -> c: данные

isn - идентификатор пакета, посылаемого клиентом (С) или сервером (S). Клиент, послав syn серверу S, переходит в состояние syn_sent. При этом запускается таймер установления соединения. Как при установлении соединения так и при его разрыве приходится сталкиваться с проблемой двух армий. Представим себе, что имеется две армии А и Б, причем Б больше по численности чем А. Армия Б разделена на две части, размещенные по разные стороны от армии А. Если две части армии Б одновременно нападут на армию А, победа гарантирована. В то же время нападение на А одной из частей армии Б обрекает ее на поражение. Но как обеспечить одновременность? Здесь предполагается, что радио еще не изобретено и передача сообщений осуществляется вестовыми, которые в нашем случае могут быть перехвачены врагом. Как убедиться, что вестовой дошел? Первое, что приходит в голову, это послать другого вестового с подтверждением. Но он также с некоторой вероятностью может быть перехвачен. А отправитель не будет знать, дошел ли он. Ведь если сообщение перехвачено, отправитель первичного запроса не выдаст команды на начало, так как не уверен, дошло ли его первое сообщение. Возникает вопрос, существует ли алгоритм, который бы гарантировал надежность синхронизации решений путем обмена сообщениями при ненадежной доставке? Повысит ли достоверность увеличение числа обменов между партнерами? Ответом на этот вопрос будет - нет не существует. В этом, порассуждав логически, может убедиться самостоятельно. Не трудно видеть, что схожие проблемы возникают в любом протоколе, работающем через установление соединения. Чаще всего эта проблема решается путем таймаутов и повторных.

Сервер, получив SYN, откликается посылкой другого SYN. Когда С получает SYN от S (но не получает ACK, например, из-за его потери или злого умысла), он предполагает, что имеет место случай одновременного открытия соединения. В результате он посылает s syn_ack, отключает таймер установления соединения и переходит в состояние syn_received. Сервер получает syn_ack от C, но не посылает отклика. Тогда С ожидает получения syn_ack в состоянии syn_received. Так как время пребывания в этом состоянии не контролируется таймером, С может остаться в состоянии syn_received вечно. Из-за того, что переходы из состояния в состояние не всегда четко определены, протокол tcp допускает и другие виды атак.

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

Существует еще одна проблема при пересылке данных по каналам TCP, которая называется синдром узкого окна (silly window syndrome; Clark, 1982). Такого рода проблема возникает в том случае, когда данные поступают отправителю крупными блоками, а интерактивное приложение адресата считывает информацию побайтно. Предположим, что в исходный момент времени буфер адресата полон и передающая сторона знает об этом (window=0). Интерактивное приложение считывает очередной октет из TCP-потока, при этом TCP-агент адресата поcылает уведомление отправителю, разрешающее ему послать один байт. Этот байт будет послан и снова заполнит до краев буфер получателя, что вызовет отправку ACK со значением window=0. Этот процесс может продолжаться сколь угодно долго, понижая коэффициент использования канала ниже паровозного уровня.

Кларк предложил не посылать уведомление о ненулевом значении ширины окна при считывании одного байта, а лишь после освобождения достаточно большого пространства в буфере. Например, когда адресат готов принять MSS байтов или когда буфер наполовину пуст.

Предполагается, что получатель пакета практически всегда посылает отправителю пакет-отклик. Отправитель может послать очередной пакет, не дожидаясь получения подтверждения для предшествующего. Таким образом, может быть послано k пакетов, прежде чем будет получен отклик на первый пакет (протокол "скользящего окна"). В протоколе tcp "скользящее окно" используется для регулировки трафика и препятствия переполнения буферов. Идея скользящего окна отображена на рис. Здесь предполагается, что ширина окна равна 7 (k=7; это число может меняться в очень широких пределах).

После прихода отклика на пакет <1> окно смещается вправо на одну позицию. Теперь отправитель может послать и пакет <8>. Если порядок прихода откликов нарушается, сдвиг окна может задержаться. Размер окна в сегментах определяется соотношением:

window > RTT*B/MSS,

где B - полоса пропускания канала в бит/с, а MSS - максимальный размер сегмента в битах, а window - в сегментах.

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

Пример работы TCP

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

Структура TCP-пакета известна (дополнительно в рис. добавлен псевдозагаловок, который учитывается при контрольном суммировании):

Адрес получателя, порт получателя и адрес отправителя, порт отправителя - это понятно.

Sequence Number(SYN) - номер очереди или последовательный номер, показывает порядковый номер пакета при передаче, именно поэтому принимающая система собирает пакеты именно так, как надо, а не в том порядке, как они пришли.

Acknowledgment Number(ACK) - номер подтверждения, показывает, на пакет с каким SYN отвечает удаленная система, таким образом мы имеем представление, что удаленная система получила наш пакет с данным SYN.

Контрольные биты- 6 бит (на схеме между reversed и window). Значения битов:

URG: поле срочного указателя задействовано
ACK: поле подтверждения задействовано
PSH: функция проталкивания
RST: перезагрузка данного соединения
SYN: синхронизация номеров очереди
FIN: нет больше данных для передачи

DATA - это непосредственно те данные, которые мы хотим передать.

Более подробно о значении остальных полей можно прочитать в в RFC793. Разберем как это работает на практике.

Когда мы хотим установить соединение, мы отправляем удаленной системе пакет следующей структуры:

Client --- SYN (856779) --- Host
Где Client- это мы, a Host - это удаленная система. Мы посылаем пакет лишь с указанием SYN - это значит, что этот пакет первый, мы ни на что не отвечаем (отсутствует ACK). Данный пакет выглядит примерно так:
20 53 52 43 00 00 44 45 53 54 00 00 08 00 45 00 00 2C C3 00 40 00 20 06 10 0C CB 5E FD BA CB 5E F3 47 04 07 00 17 00 0D 12 CB 00 00 00 00 60 02 20 00 D9 70 00 00 02 04 05 B4 2D

Интересный момент в том, откуда берется SYN. SYN образуется от первоначального номера очереди (ISN) - это 32-битный номер от 1 до 4294967295 (2 в 32-ой степени). ISN при перезагрузке системы равен 1, затем каждую секунду он увеличивается на 128000 (строго говоря изменение происходит каждые 4 микросекунды) + при каждом установленном соединении он увеличивается на 64000. Получается, что цикл уникальности ISN, при условии того, что никакие соединения не устанавливались, составляет примерно 4,55 часа. Поскольку ни один пакет так долго по сети не путешествует, мы можем полагать, что SYN будет абсолютно уникальным.

Получив наш пакет, удаленная система отвечает, что получила и готова установить соединение. Данные пакет выглядит так:

Host --- SYN (758684758) и ACK (856780) --- Client

Удаленная система дает понять, что получила наш пакет. Для этого она посылает нам ACK с номером "наш SYN+1". В добавок к этому удаленная система посылает нам свой SYN (мы же тоже будем отвечать). А ответ наш будет такой:

Client --- SYN (856780) и ACK (758684759) --- Host

Это означает следующее: ваш пакет с SYN (758684758) получен, соединение установлено, наш SYN равен 856780.

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

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

Если соединение нам больше не нужно, можно его и закрыть. Этот этап снова будет состоять из нескольких стадий.

Client --- FIN(4894376) и ACK (1896955378) --- Host

Host --- ACK (4894377) --- Client

Host --- FIN (1896955378) и ACK (4894377) --- Client

Client --- ACK (1896955378) --- Host

Здесь, ничего сложного здесь нет. Единственное, что стоит отметить - это флаг FIN, который означает желание завершить соединение.

Подводя небольшие итоги вышеизложенному, отметим в каких же случаях изменяются/не изменяются порядковые номера:

Передача одного FIN Пакета = +1
Передача одного SYN Пакета = +1
Передача одного ACK Пакета = 0
Передача одного SYN/ACK Пакета = +1
Передача одного FIN/ACK Пакета = +1
Изменение за 1 секунду = +128,000
Установление одного соединения = +64,000

Возможно, кто-то спросит: "А что будет, если машина получит пакет с таким ACK, которого не было?" (SYN=ACK-1, а пакет с таким SYN мы не посылали). Получив ответ непонятно на что, мы в свою очередь ответим удаленной системе NACK-пакетом (означает "не знаю о чем ты", никакого соединения не устанавливается).

ПротоколUDP
Протокол UDP (user datagram protocol, RFC-768) является одним из основных протоколов, расположенных непосредственно над IP. Он предоставляет прикладным процессам транспортные услуги, немногим отличающиеся от услуг протокола IP. Протокол UDP обеспечивает доставку дейтограмм, но не требует подтверждения их получения. Протокол UDP не требует соединения с удаленным модулем UDP ("бессвязный" протокол). К заголовку IP-пакета udp добавляет поля порт отправителя и порт получателя, которые обеспечивают мультиплексирование информации между различными прикладными процессами, а также поля длина udp-дейтограммы и контрольная сумма, позволяющие поддерживать целостность данных. Таким образом, если на уровне ip для определения места доставки пакета используется адрес, на уровне UDP - номер порта.

Примерами сетевых приложений, использующих UDP, являются NFS(network file system), TFTP(trivial file transfer protocol, RFC-1350), RPC (remote procedure call, RFC-1057) и SNMP (simple network management protocol, RFC-1157). Малые накладные расходы, связанные с форматом UDP, а также отсутствие необходимости подтверждения получения пакета, делают этот протокол наиболее популярным при реализации приложений мультимедиа, но главное его место работы - локальные сети и мультимедиа.

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

Например, сервер snmp всегда ожидает сообщения, адресованного в порт 161. Если клиент snmp желает получить услугу, он посылает запрос в UDP-порт 161 на машину, где работает сервер. На каждой машине может быть только один агент SNMP, т.к. существует только один порт 161. Данный номер порта является общеизвестным, т.е. фиксированным номером, официально выделенным в сети Internet для услуг SNMP.

Данные, отправляемые прикладным процессом через модуль UDP, достигают места назначения как единое целое. Например, если процесс-отправитель производит 5 записей в порт, то процесс-получатель должен будет сделать 5 чтений. Размер каждого записанного сообщения будет совпадать с размером каждого прочитанного. Протокол UDP сохраняет границы сообщений, определяемые прикладным процессом. Он никогда не объединяет несколько сообщений в одно и не делит одно сообщение на части.

Формат UDP-сообщений представлен ниже:

Длина сообщения равна числу байт в UDP-дейтаграмме, включая заголовок. Поле UDP контрольная сумма содержит код, полученный в результате контрольного суммирования UDP-заголовка и поля данные. Не трудно видеть, что этот протокол использует заголовок минимального размера (8 байт). Номера портов от 0 до 255 стандартизованы и использовать их в прикладных задачах не рекомендуется.

Модуль IP передает поступающий IP-пакет модулю UDP, если в заголовке этого пакета указан код протокола UDP. Когда модуль UDP получает дейтаграмму от модуля IP, он проверяет контрольную сумму, содержащуюся в ее заголовке. Если контрольная сумма равна нулю, это означает, что отправитель ее не подсчитал. ICMP, IGMP, UDP и TCP протоколы имеют один и тот же алгоритм вычисления контрольной суммы (RFC-1071). Но вычисление контрольной суммы для UDP имеет некоторые особенности. Во-первых, длина UDP-дейтограммы может содержать нечетное число байт, в этом случае к ней добавляется нулевой байт, который служит лишь для унификации алгоритма и никуда не пересылается. Во-вторых, при расчете контрольной суммы для UDP и TCP добавляются 12-байтные псевдозаголовки, содержащие IP-адреса отправителя и получателя, код протокола и длину дейтаграммы. Как и в случае IP-дейтаграммы, если вычисленная контрольная сумма равна нулю, в соответствующее поле будет записан код 65535.

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

Так как максимальная длина IP-дейтаграммы равна 65535 байтам, максимальная протяженность информационного поля UDP-дейтаграммы составляет 65507 байт. На практике большинство систем работает с UDP-дейтаграммами с длиной 8192 байта или менее. Детальное описание форматов, полей пакетов можно найти в RFC-768.