 |
Дополнительные данные заголовка
|
|
|
|
последовательность полей произвольной длины, описывающих необязательные данные заголовка. Протокол TCP определяет только три типа дополнительных данных заголовка:
· конец списка полей дополнительных данных;
· пусто (No Operation);
· максимальный размер пакета.
Дополнительные данные последнего типа посылаются в TCP-заголовке в момент установления логического соединения для выражения готовности TCP-модулем принимать пакеты длиннее 536 байтов. В UNIX-реализациях длина пакета обычно определяется максимальной длиной IP-сегмента для сети.
4.2. Номер порта
Номера портов играют роль адресов транспортного уровня, идентифицируя на конкретных узлах сети, по сути дела, потребителей транспортных услуг, предоставляемых как протоколом TCP, так и протоколом UDP. При этом протоколы TCP и UDP имеют свои собственные адресные пространства: например, порт номер 513 для TCP не идентичен порту номер 513 для UDP.
Примечание. Своя собственная адресация на транспортном уровне стека протоколов сетевого взаимодействия необходима для обеспечения возмоэ!сности функционирования на узле сети одновременно многих сетевых приложений. Наличие в TCP-заголовке номера порта позволяет TCP-модулю, получающему последовательности TCP-пакетов, формировать раздельные потоки данных к прикладным программам.
Взаимодействие прикладных программ, использующих транспортные услуги протокола TCP (или UDP), строится согласно модели "клиент-сервер", которая подразумевает, что одна программа (сервер) всегда пассивно ожидает обращения к ней другой программы (клиента). Связь программы-клиента и сервера идентифицируется пятеркой:
1. используемый транспортный протокол (TCP или UDP);
|
|
|
2. IP-адрес сервера;
3. номер порта сервера;
4. IP-адрес клиента;
5. номер порта клиента.
Для того, чтобы клиент мог обращаться к необходимому ему серверу, он должен знать номер порта, по которому сервер ожидает обращения к нему ("слушает сеть"). Для прикладных программ, получивших наибольшее распространение в сетях на основе TCP/IP, номера портов фиксированы и носят название "хорошо известных номеров портов" (well-known port numbers). В UNIX-системах такие номера портов содержатся в файле /etc/services. Ниже приводятся примеры хорошо известных номеров портов для некоторых серверов (служб).
Служба Номер порта Протокол
| ftp-data | TCP | |
| ftp | TCP | |
| telnet | TCP | |
| smtp | TCP | |
| time | TCP | |
| time | UDP | |
| finger | TCP | |
| portmap | TCP | |
| portmap | UDP | |
| exec | TCP | |
| login | TCP | |
| shell | TCP | |
| who | UDP | |
| talk | UDP | |
| route | UDP | |
| Xserver | TCP |
Примечание. Обратите внимание, что некоторые серверы (такие, например, как для службы portmap с номером порта 111) могут работать как по протоколу TCP, так и по протоколу UDP.
Программы-клиенты, являющиеся активной стороной во взаимодействии "клиент-сервер", могут использовать, как правило, произвольные номера портов, назначаемые динамически непосредственно перед обращением к серверу (как любые свободные на данном узле).
Примечание. Любая прикладная программа (будь то клиент или сервер) может открывать для взаимодействия любое количество портов для использования любых транспортных протоколов.
Средства разработки сетевых приложений на базе транспортных протоколов TCP и UDP описаны в "Сетевое программирование".
4.3 Принцип "скользящего окна"
Протоколы транспортного уровня, обеспечивающие надежную передачу данных, предполагают обязательное подтверждение принимающей стороной правильности полученных данных.
В "простых" протоколах сторона, отправляющая данные, отсылает пакет с данными принимающей стороне и переходит в состояние ожидания подтверждения получения правильных данных. Только после приема подтверждения становится возможной следующая посылка. Очевидно, что такой подход использует пропускную способность сети неэффективно.
|
|
|
В протоколе TCP используется более совершенный принцип "скользящего окна" (sliding window), который заключается в том, что каждая сторона может отправлять партнеру максимум столько байт, сколько партнер указал в поле "размер окна" заголовка TCP-пакета, подтверждающего получение предыдущих данных.
Принцип "скользящего окна" обеспечивает "опережающую" посылку данных с "отложенным" их подтверждением. Следует отметить недостаток этого механизма: если в течение некоторого времени не будет получено "отсроченное" подтверждение ранее отправленного пакета, то отправляющий TCP-модуль будет вынужден повторить посылку всех TCP-пакетов, начиная с неподтвержденного.
Размер окна, как правило, определяется объемом свободного места в буферах принимающего TCP-модуля.
4.4 Важные данные
Протокол TCP предусматривает возможность информирования принимающей стороны взаимодействия отправляющей стороной о наличии в TCP-пакете важных данных (urgent data), требующих особого внимания согласно логике прикладной задачи.
Примечание. Отличие важных данных от данных основного потока заключается в том, что принимающая сторона должна, как правило, обработать их прежде ранее полученных, но еще не обработанных данных потока.
Для индикации наличия в TCP-пакете важных данных используется флаг URG TCP-заголовка, местоположение важных данных в теле TCP-пакета определяется полем "Указатель" TCP-заголовка - оно задает смещение (в стиле языка программирования С) первого байта важных данных в теле TCP-пакета. Рис. 4.3 иллюстрирует расположение важных данных в теле TCP-пакета.
| URG = 1 | Указатель | Данные потока | Важные данные |
TCP-заголовок Тело TCP-пакета
Примечание. Протокол TCP предусматривает передачу важ}1ых (urgent) данных в рамках общего потока данных ("in-band"). Существуют протоколы (например, ISO), поддерживающие режим передачи важных (expedited) данных вне общего потока данных ("out-band"), что в общем случае быстрее.
|
|
|
4.5. Этапы TCP-взаимодействия
Взаимодействие партнеров с использованием протокола TCP строится в три этапа:
· установление логического соединения;
· обмен данными;
· закрытие соединения.
Ниже с помощью трех рисунков дается описание каждого из этапов. Рисунки иллюстрируют последовательность обмена TCP-пакетами двумя TCP-модулями: А и В. TCP-пакеты представлены тремя полями TCP-заголовка ("Номер в последовательности", "Номер подтверждения", "Флаги") и числом, характеризующим длину данных, составляющих тело TCP-пакета (заметим, что реально поля длины данных в TCP-заголовке нет). Стрелками показаны направления пересылки пакетов.
Рис. 4.4
Рис. 4.4 иллюстрирует этап установления соединения, реализуемый как "трехшаговое рукопожатие" (three-way handshake). На первом шаге TCP-модуль А, играя роль клиента, посылает TCP-модулю В пакет с установленным флагом SYN и начальным значением номера в последовательности равным 1000. TCP-модуль В, будучи готов со своей стороны установить соединение, отвечает TCP-пакетом, подтверждающим правильный прием запроса (поле "Номер подтверждения" на 1 больше начального номера в последовательности для TCP-модуля А и среди флагов есть установленный в 1 флаг АСК) и информирующим о готовности установить соединение (взведен флаг SYN и установлен в 5000 начальный номер в последовательности). На третьем шаге TCP-модуль А подтверждает правильность приема TCP-пакета от В.
Примечание. Некоторые протоколы транспортного уровня (но не TCP) допускают обмен данными уже на этапе установления логического соединения.
Рис. 4.5 иллюстрирует этап двустороннего обмена данными между TCP-модулями А и В.
TCP-модуль, принимающий адресованные ему данные, всегда подтверждает их прием, вычисляя значение поля "Номер подтверждения" в заголовке ответного TCP-пакета как сумму пришедшего "Номера в последовательности" и длины правильно принятых данных. Отметим, что посылка данных к партнеру и подтверждение принятых от него данных реализуются в рамках одного TCP-пакета.
|
|
|
|
|
TCP А последовательности подтверждения данных
Рис. 4.6 иллюстрирует закрытие соединения по инициативе TCP-модуля А, посылающего партнеру TCP-пакет с установленным флагом FIN. Прием запроса на закрытие соединения TCP-модуль В подтверждает пакетом, содержащем в своем заголовке поле "Номер подтверждения", значение которого (1052) на 1 больше значения принятого "Номера в последовательности" (1051). После этого посылка каких-либо данных TCP-модулем А становится невозможной, однако модуль В имеет данные для передачи, которые он отправляет TCP-модулю А и получает подтверждение на их прием. Затем TCP-модуль В формирует пакет с флагом FIN, после подтверждения его приема соединение считается закрытым.
Примечание. Обратите внимание на то обстоятельство, что при подтверждении TCP-пакетов, содержащих единичные флаги SYN или FIN, значение поля "Номер подтверждения" на 1 больше значения соответствующего поля "Номер в последовательности", несмотря на то, что никакие данные в подтверждаемых TCP-пакетах не передаются.
Примечание. Рассмотренный пример не включает в себя ситуации, связанные с "потерей" TCP-пакетов в сети, и их обработку, связанную с повторной передачей данных.
4.6. Таймеры
Содержание
4.6.1 Таймер повторной передачи
4.6.2 Таймер возобновления передачи
4.6.3 Таймер закрытия связи
4.6.4 Таймеры поддержки соединения
4.6.1. Таймер повторной передачи
Данный таймер взводится значением RTO (Retransmission TimeOut - интервал до повторной передачи) в момент посылки TCP-пакета адресату. Если тайм ер ^кажется сброшенным в ноль до момента получения подтверждения пакета, то этот пакет должен быть послан_вновь.
Ясно, что величина RTO не может быть фиксированной, т.к. TCP-пакеты до разных адресатов следуют по различным маршрутам через сети, скорость передачи данных в которых может различаться более чем в тысячи раз. Для вычисления "оптимального" значения RTO в каждом логическом соединении используется специальная процедура, специфицированная в RFC 793.
Согласно этой процедуре, для каждого TCP-пакета измеряется величина RTT (Round Trip Time - интервал времени от момента посылки TCP-пакета до момента получения подтверждения на него). На основе измеренных RTT вычисляется величина SRTT (Smoothed RTT - сглаженный RTT) по следующей формуле:
SRTT = k*SRTT + (1 - k)*RTT,
где k - сглаживающий коэффициент (например, 0.9).
Примечание. Приведенная формула обеспечивает фильтрацию нетипичных (пиковых) значений измеренной величины RTT.
"Оптимальное" значение RTO вычисляется по формуле:
|
|
|
RTO = min(U, max(L, p*SRTT)),
где:
U - ограничение сверху на значение RTO (например, 30 секунд);
L - ограничение снизу на значение RTO (например, 1 секунда);
р - коэффициент "запаса" (например, 2).
Если после повторной посылки TCP-пакета, опять не будет получено его подтверждение за интервал времени RTO, то попытки послать TCP-пакеты будут повторены (до 12 раз), но каждый раз с экспоненциально возрастающим значением RTO. Только после неудачи всей серии повторных посылок связь между партнерами будет считаться аварийно закрытой.
4.6.2. Таймер возобновления передачи
В ходе взаимодействия двух TCP-модулей (А и В) вполне возможна следующая ситуация:
· TCP-модуль В уведомляет TCP-модуль А о невозможности приема от него данных, определяя размер окна равным 0;
· TCP-модуль А, имея данные для передачи, переходит в состояние ожидания от TCP-модуля В пакета с ненулевым размером окна;
· TCP-модуль В, у которого освободилось некоторое пространство в буферах, посылает модулю А TCP-пакет с ненулевым размером окна;
· адресованный модулю А пакет "теряется" по какой-либо причине и оба TCP-модуля переходят в состояние бесконечного ожидания.
Средством выхода из такого тупикового состояния и служит таймер возобновления передачи (persistence timer - "настойчивый" таймер). Он взводится в момент получения TCP-пакета с нулевым значением поля "Размер окна" в его заголовке (типичное начальное значение для этого таймера - 5 секунд). Если до момента обнуления таймера не будет получено разрешение на возобновление передачи данных, то ожидающий разрешения TCP-модуль отправляет партнеру пакет, содержащий всего лишь 1 байт данных. По реакции партнера, возвращающего пакет с нулевым/ненулевым значением размера окна, TCP-модуль продолжает ожидание или возобновляет посылку данных.
4.6.3. Таймер закрытия связи
Протокол TCP предусматривает следующий простой прием предотвращения появления в сети TCP-пакетов, не имеющих адресатов: после закрытия логического соединения между партнерами номера портов, использовавшихся в этом соединении, остаются еще некоторый интервал времени действительными, что дает возможность долго блуждавшим по сети TCP-пакетам добраться до места назначения (где они будут просто проигнорированы). Величина этого интервала равна удвоенному времени жизни IP-сегмента (обычно, 2* 15=30 секунд).
Примечание. Пользователи ОС UNIX могут почувствовать эффект от использования этого приема, попытавшись перезапустить некоторую прикладную программу, использующую TCP, сразу же после ее завершения.
4.6.4. Таймеры поддержки соединения
Ниже описывается механизм, используемый для проверки ненарушенности логического соединения между TCP-модулями.
Каждый TCP-модуль, участвующий в логическом соединении, через фиксированный промежуток времени (keep-alive timer), равный обычно 45 секундам, периодически отправляет партнеру пустые (не содержащие данных) TCP-пакеты и ждет их подтверждения. Каждое полученное подтверждение говорит о ненарушенности соединения. Если же в течении определенного интервала времени (idle timer), равного обычно 360 секудам, не будет получено ни одного подтверждения, то логическое соединение считается оборванным.
Примечание. Очевидно, что данный механизм имеет смысл включать в работу только тогда, когда партнеры по TCP-взаимодействию приостановили по какой-либо причине обмен данных на достаточно длительный срок (более 45 секунд).
Примечание. Стандартная спецификация протокола TCP не включает в себя описанный механизм, однако он реализован во всех UNIX-системах.
4.7. Алгоритмы повышения эффективности
Содержание
4.7.1 Задержка подтверждения
4.7.2 Исключение малых окон
4.7.3 Исключение коротких TCP-пакетов
4.7.4 Алгоритм медленного старта
Ниже описываются некоторые алгоритмы, используемые для повышения эффективности взаимодействия по протоколу TCP в UNIX-реализациях и не являющиеся частью спецификации TCP.
4.7.1 Задержка подтверждения
Задержка отсылки подтверждения принятого пакета используется для сокращения числа TCP-пакетов, которыми обмениваются партнеры по взаимодействию. Поясним эффект от такой задержки следующим примером.
Пусть клиентская часть некоторого приложения (например, службы telnet) направляет серверной части некоторые данные (в случае telnet - строку символов, представляющих команду ОС UNIX, которая должна быть выполнена на удаленном узле сети). Серверная часть, получив данные и обработав их, должна вернуть клиенту результат (в случае с telnet -это стандартный вывод исполненной команды).
В ситуации без задержки TCP-модуль на стороне сервера, приняв пакет с данными и разместив их в своем буфере, сразу же отвечает подтверждающим пакетом, содержащим в своем заголовке и некоторый (уменьшенный) размер окна для приема последующих данных. Спустя некоторое (обычно, очень короткое) время данные из буфера передаются серверной части прикладной программы. Освобождение места в буфере заставляет TCP-модуль отправлять партнеру на стороне клиента TCP-пакет с новым (увеличившимся) размером окна. Тем временем прикладная программа, обработав полученные данные (часто за небольшое время), передает результат TCP-модулю для отсылки его клиенту, для чего модуль формирует еще один пакет. Итого: одна транзакция потребовала от TCP-модуля на стороне сервера посылки трех TCP-пакетов.
Введение же задержки при отсылке подтверждающего TCP-пакета позволяет в ряде случаев уменьшить количество пакетов с трех до одного, содержащего сразу подтверждение, новый размер окна и результирующие данные. Экспериментальные исследования показали, что во многих случаях "оптимальным" значением задержки является 0,2 секунды.
Для того, чтобы введение задержки сказывалось минимальным образом на приложения, предъявляющие жесткие требования к пропускной способности сети, задержка устанавливается нулевой при условии, что размер окна изменяется более чем на 35% или (в абсолютном исчислении) на удвоенный максимальный размер TCP-пакета.
4.7.2 Исключение малых окон
Возможны ситуации, когда прикладная программа, использующая TCP-сервис, "выбирает" из буфера обслуживающего ее TCP-модуля пришедшие для нее данные малыми порциями. Это приводит к генерации TCP-модулем большого количества TCP-пакетов, содержащих в своих заголовках малую величину размера окна, что в свою очередь приводит к генерации на передающей данные стороне многих TCP-пакетов с "короткими" данными. Как результат - "засорение" сети короткими пакетами и снижение ее пропускной способности.
Во избежание деградации сети вследствие описанного явления используется следующий прием: TCP-пакет, информирующий посылающую данные сторону об увеличении размера окна, формируется только при выполнении одного из двух условий:
1. свободное место в буфере принимающего данные TCP-модуля увеличилось по крайней мере на четверть размера этого буфера;
2. свободное место увеличилось по крайней мере на максимальный размер TCP-пакета.
Кроме того TCP-модуль, отправляющий данные, должен делать это большими порциями.
4.7.3 Исключение коротких TCP-пакетов
"Засорение" сети короткими TCP-пакетами возможно и в ситуации, когда прикладная программа, отправляющая данные партнеру по взаимодействию, делает это короткими порциями (типичный пример - любая программа, использующая графическую систему X Window System).
Для борьбы с этим используется следующий прием:
· самая первая порция данных отправляется TCP-модулем сразу же при поступлении "коротким11 TCP-пакетом;
· все последующие накапливаются в буфере TCP-модуля, пока их общий объем не составит максимального размера TCP-пакета или не будет получено подтверждение предыдущей посылки.
Однако этот подход может сказаться на быстродействии некоторых приложений, чтобы избежать этого прикладной программе предоставляются средства для принудительного "выталкивания" буферизованных данных в необходимых случаях. Кроме того, существует возможность отключения описанного механизма.
4.7.4 Алгоритм медленного старта
Опыт эксплуатации сетей на основе TCP/IP показал, что с повышением загрузки сети (особенно, сети со шлюзом) ее пропускная способность падает (хотя, казалось бы, она должна оставаться постоянной). Исследования показали, что падение обусловлено появлением в сети большого числа TCP-пакетов, повторно посылаемых к активно используемому узлу сети (обычно это шлюз в другие сети). Дело в том, что приемный буфер TCP-модуля на шлюзе очень быстро заполняется, и TCP-модуль вынужден сбрасывать поступающие к нему пакеты.
Для предупреждения подобной ситуации необходимо согласование темпа передачи TCP-пакетов с возможностями их приема на узле-адресате. Задачу согласования решает алгоритм медленного старта, постепенно повышающий темп передачи данных от медленного до "оптимального", при котором нет повторных передач TCP-пакетов. Алгоритм использует так называемое "окно перегруженности" (congestion window), используемое на передающей стороне для определения максимального объема передаваемых данных вместо размера, получаемого от принимающей стороны в поле окна подтверждающего пакета.
Размер "окна перегруженности" определяется на передающей стороне путем постепенного его увеличения до момента появления повторных передач (ясно, что размер этого окна никогда не превышает размера окна на принимающей стороне). Однажды определенный размер "окна перегруженности" остается неизменным, пока вновь не появятся повторные передачи, однако периодически делаются осторожные попытки и увеличить этот размер.
Эксперименты показали, что данный алгоритм позволяет уменьшить количество повторно передаваемых TCP-пакетов на 50% и повысить пропускную способность сети на 30%.
5. Протокол дэйтаграмм пользователя UDP
Протокол дэйтаграмм пользователя UDP (User Datagram Protocol) является протоколом транспортного уровня и базируется на возможностях, предоставляемых межсетевым протоколом IP. Основная задача TCP - обеспечение "быстрой" передачи данных в сети. Его транспортный адрес в заголовке IP-сегмента равен 17. Описание протокола UDP дано в RFC 768.
Его основные характеристики перечислены ниже:
· реализует взаимодействие в режиме без установлением логического (виртуального) соединения;
· организует поблочный (дэйтаграммный, пакетный) тип передачи данных;
· для идентификации партнеров по взаимодействию на транспортном уровне использует 16-битовые "номера портов";
· не гарантирует надежной передачи данных (возможна как потеря UDP-пакетов, так и их дублирование);
· не имеет средств уведомления источника UDP-пакета о правильности/ошибочности в
его приеме адресатом;
· не обеспечивает правильный порядок доставки UDP-пакетов от источника к приемнику;
· может гарантировать целостность данных в UDP-пакете за счет использования контрольной суммы;
· очень прост (особенно, по сравнению с протоколом TCP).
Следует отметить, что, по сути дела, протокол транспортного уровня UDP играет роль интерфейса для прикладных программ к средствам протокола межсетевого уровня IP.
На рис. 5.1 приведен формат заголовка UDP-пакета.
|
|
|
