Информатика в техническом университете / Информатика в техническом университете. Телекоммуникации и сети

Рис. 5.48. Формат заголовка пакета TCP

Несмотря на то что для пользователя передача данных с использованием протокола TCP выглядит как потоковая, на самом же деле обмен между парт­ нерами осуществляется посредством пакетов данных, которые мы будем на­ зывать «ТСР-пакетами».

Формат заголовка пакета TCP и назначение полей. На рис. 5.48 при­ веден формат заголовка ТСР-пакета. Порт источника и порт приемника пред­ ставляют собой 16-битовые поля, содержащие номера портов, соответствен­ но, источника и адресата ТСР-пакета. Номер в последовательности (sequence number) - 32-битовое поле, содержимое которого определяет (косвенно) поло­ жение данных ТСР-пакета внутри исходящего потока данных, существующего

врамках текущего логического соединения.

Вмомент установления логического соединения каждый из двух партнеров генерирует свой начальный «номер в последовательности», основное требова­ ние к которому - не повторяться в промежутке времени, в течение которого ТСР-пакет может находиться в сети (по сути, это время жизни 1Р-сегмента). Партнеры обмениваются этими начальными номерами и подтверждают их получение. Во время отправления ТСР-пакетов с данными поле «номер в пос­ ледовательности» содержит сумму начального номера и количества байт ра­ нее переданных данных.

Номер подтверждения (acknowledgement number) - 32-битовое поле, содер­ жимое которого определяет (косвенно) количество принятых данньпс из входя­ щего потока к ТСР-модулю, формирующему ТСР-пакет.

Смещение данных - 4-битовое поле, содержащее длину заголовка ТСР-па­ кета в 32-битовьпс словах и используемое для определения начала расположе­ ния данных в ТСР-пакете.

Флаг URG - бит, единичное значение которого означает, что ТСР-пакет со­ держит важные (urgent) данные. Подробно информащ1Я содержится в поле дан­ ных ТСР-пакета, определенного как «Важные данные».

400

5.6. Протоколы IIуровня стека TCP/IP

Флаг АСК - бит, единичное значение которого означает, что ТСР-пакет со­ держит в поле «номер подтверждения» верные данные.

Флаг PSH - бит, единичное значение которого означает, что данные, содер­ жащиеся в ТСР-пакете, должны быть немедленно переданы прикладной про­ грамме, для которой они адресованы. Подтверждение для ТСР-пакета, содер- « жащего единичное значение во флаге PSH, означает, что и все предьщущие ТСР-пакеты достигли адресата.

Флаг RST - бит, устанавливается в единицу в ТСР-пакете, отправляемом в ответ на получение неверного ТСР-пакета. Также может означать запрос на переустановление логического соединения.

Флаг SYN - бит, единичное значение которого означает, что ТСР-пакет представляет собой запрос на установление логического соединения. Получе­ ние пакета с установленным флагом SYN должно бьггь подтверждено прини­ мающей стороной.

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

Размер окна - 16-битовое поле, содержащее количество байт информации, которое может принять в свои внутренние буфера ТСР-модуль, отправляющий партнеру данный ТСР-пакет. Данное поле используется принимающим поток данных ТСР-модулем для управления интенсивностью этого потока, так, уста­ новив нулевым значение этого поля, можно полностью остановить передачу данных, которая будет возобновлена только, когда размер окна примет доста­ точно большое значение. Максимальный размер окна зависит от реализации, в некоторых реализациях максимальный размер устанавливается системным ад­ министратором (типичное значение максимального размера окна - 4096 байт). Определение оптимального размера окна - одна из наиболее сложных задач реализации протокола TCP.

Контрольная сумма - 16-битовое поле, содержащее контрольную сумму, подсчитанную для ТСР-заголовка, данных пакета и ряда полей IP-заголовка.

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

Дополнительные данные заголовка ~ последовательность полей произволь­ ной длины, описывающих необязательные данные заголовка. Протокол TCP определяет только три типа дополнительных: данных заголовка:

•конец списка полей дополнительных данных;

•пусто (No Operation);

•максимальный размер пакета.

401

5. Сетевые протоколы

Дополнительные данные последнего типа посылаются в ТСР-заголовке в момент установления логического соединения для выражения готовности ТСРмодулем принимать пакеты длиннее 536 байт. В UNIX-реализациях длина па­ кета обычно определяется максимальной длиной 1Р-сегмента для сети.

Номера портов играют роль адресов транспортного уровня, идентифшщруя на конкретных узлах сети, по сути дела, потребителей транспортных услуг, пре­ доставляемых как протоколом TCP, так и протоколом UDP. При этом протоко­ лы TCP и UDP имеют свои собственные адресные пространства: например, порт номер 513 для TCP не идентичен порту номер 513 для UDP.

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

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

1.Используемый транспортный протокол (TCP или UDP);

2.IP-адрес сервера;

3.Номер порта сервера;

4.IP-адрес клиента;

5.Номер порта клиента.

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

Как должны назначаться номера протокольных портов? Эта проблема важ­ на, так как два компьютера должны договариваться о номерах портов, прежде чем они смогут взаимодействовать. Например, когда компьютер А хочет по­ лучить файл от компьютера В, он должен знать, какой порт в компьютере В использует программа передачи файла. Существуют два фундаментальных под­ хода к назначению портов.

Первый подход использует централизованное управление назначением. Все договариваются позволить центральному органу назначать номера всем необ­ ходимым портам и затем опубликовать список назначений.Тогда все програм­ мы создаются в соответствии с этим списком. Этот подход иногда называют «универсальным назначением». Такие назначения портов становятся широко известными назначениями, а номера портов фиксированы и носят название <осо-

402

5.6. Протоколы IIуровня стека TCP/IP

шо известных номеров портов» (well-known port numbers). Централизованное присвоение сервисам номеров портов выполняется организацией Internet Assigned Numbers Authority.

Второй подход использует динамическое назначение. При этом подходе но­ мера портов неизвестны всем. Вместо этого само сетевое обеспечение назна­ чает порт, когда программа в этом нуждается. Чтобы узнать о текущем на­ значении портов на другом компьютере, нужно послать запрос, в котором задан примерно такой вопрос: «как мне вызвать службу передачи файлов?». Компьютер-получатель ответит, какой порт необходимо использовать.

Разработчики TCP/IP приняли смешанный подход, при котором группа портов назначается априорно, но большинство из них можно свободно исполь­ зовать для любых целей прикладными программами в локальной сети. Цент­ рализованно назначаемые номера портов начинаются с маленьких значений и затем увеличиваются, а порты с большими значениями используются для ди­ намического назначения.

На рис. 5.49 приведены примеры номеров портов для некоторых служб.

В протоколе TCP использован принцип «скользящего окна», который обес­

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

ТСР-заголовка - оно задает смещение первого байта важньпс данных в теле ТСР-пакета.

403

Рис. 5.50. Установление логического соединения

Протокол TCP предусматривает передачу важных (urgent) данных в рам­ ках общего потока данных («in-band»). Существуют протоколы (например ISO), поддерживающие режим передачи важных (expedited) данных вне общего по­ тока данных («out-band»), что в общем случае быстрее.

Этапы ТСР-взаимодействия. Взаимодействие партнеров с использова­ нием протокола TCP строится в три этапа:

•установление логического соединения;

•обмен данными;

•закрьггие соединения.

Рис. 5.50-5.52 иллюстрируют последовательность обмена ТСР-пакетами двумя ТСР-модулями: А и В. ТСР-пакеты представлены тремя полями ТСРзаголовка («Номер в последовательности», «Номер подтверждения», «Флаги») и числом, характеризующим длину данных из которых тело ТСР-пакета (заме­ тим, что реально поля «Длина данных» в ТСР-заголовке нет). Стрелками пока­ заны направления пересылки пакетов.

Рис. 5.50 демонстрирует этап установления соединения, реализуемый как «трехшаговое рукопожатие» (three-way handshake). На первом шаге ТСР-мо­ дуль А, играя роль клиента, посылает ТСР-модулю В пакет с установленным флагом SYN и начальным значением номера в последовательности, равным 1000. ТСР-модуль В, будучи готов со своей стороны установить соединение, отвечает ТСР-пакетом, подтверждающим правильный прием запроса (поле «Номер подтверждения» на 1 больше начального номера в последовательнос­ ти для ТСР-модуля А и среди флагов есть установленный в 1 флаг АСК) и информирующим о готовности установить соединение (установлен флаг SYN и установлено значение 3000 начального номера последовательности). На тре­ тьем шаге ТСР-модуль А подтверждает правильность приема ТСР-пакета от В.

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

404

Рис. 5.52 иллюстрирует закрытие соединения по инициативе ТСР-модуля А, посылающего партнеру ТСР-пакет с установленным флагом FIN. Прием зап­ роса на закрытие соединения ТСР-модуль В подтверждает пакетом, содержа­ щем в своем заголовке поле «Номер подтверждения», значение которого (1052) на 1 больше значения принятого «Номера в последовательности» (1051). Пос­ ле этого посылка каких-либо данных ТСР-модулем А невозможна, однако модуль В имеет данные для передачи, которые он отправляет ТСР-модулю А и получает подтверждение на их прием. Затем ТСР-модуль В формирует пакет с флагом FIN, после подтверждения его»приема соединение считается закрыгым.

При подтверждении ТСР-пакетов, содержащих единичные флаги SYN или РШ, значение поля «Номер подтверждения» на 1 больше значения соответ­ ствующего поля «Номер в последовательности», несмотря на то, что никакие данные в подтверждаемых ТСР-пакетах не передаются.

Примечание. Приведенный пример не рассматривает ситуащ1и, связанные с «поте­ рей» ТСР-пакетов в сети, и их обработку, связанную с повторной передачей данных.

Рис. 5.52. Закрытие соединения

405

5. Сетевые протоколы

Таймеры и их назначение. Таймер повторной передачи. Данный тай­ мер устанавливается значением КТО (Retransmission Time Out - интервал до повторной передачи) в момент посылки ТСР-пакета адресату. Если таймер будет сброшен в ноль до моменгга получения подтверждения пакета, то этот пакет должен быть послан вновь.

Ясно, что величина RTO не может быть фиксированной, так как ТСР-паке- ты до разных адресатов следуют по различным маршрутам через сети, ско­ рость передачи данных в которых может различаться более чем в тысячи раз. Для вычисления «оптимального» значения RTO в каждом логическом соеди­ нении используется специальная процедура, специфицированная в RFC-793. Со­ гласно этой процедуре, для каждого ТСР-пакета измеряется величина RTT (Round Trip Time - интервал времени от момента посьшки ТСР-пакета до мо­ мента получения подтверждения на него). По измеренным RTT определяют величину SRTT (Smoothed RTT - сглаженный RTT):

Здесь A:- сглаживающий коэффициент (например, 0,9).

Формула (5.1) учитывает фильтрацию нетипичньгс (пиковьпс) значений из­ меренной величины RTT.

«Оптимальное» значение RTO вьршсляют по формуле:

где: и - ограничение сверху на значение RTO (например, 30 с); L - ограничение снизу на значение RTO (например, I с);р- коэффициент «запаса» (например, 2).

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

Таймер возобновления передачи, В ходе взаимодействия двух ТСР-моду- лей (А и В) вполне возможна следующая ситуация:

•ТСР-модуль В уведомляет ТСР-модуль А о невозможности приема от него данньпс, определяя размер окна равным 0;

•ТСР-модуль А, имея данные для передачи, переходит в состояние ожида­ ния от ТСР-модуля В пакета с ненулевым размером окна;

•ТСР-модуль В, у которого освободилось некоторое пространство в буфе­ рах, посылает модулю А ТСР-пакет с ненулевым размером окна;

•адресованный модулю А пакет «потерян» по какой-либо причине и оба ТСР-модуля переходят в состояние бесконечного ожидания.

Для выхода из такого тупикового состояния и служит таймер возобновления передачи (persistence timer -- «настойчивый» таймер). Он устанавливается в момент получения ГСР-пакета с нулевым значением поля «Размер окна» в его

406

5.6. Протоколы IIуровня стека TCP/IP

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

Таймер закрытия связи. Протокол TCP предусматривает следующий про­ стой прием предотвращения появления в сети ТСР-пакетов, не имеющих адре­ сатов: после закрытия логического соединения между партнерами номера пор­ тов, использовавшихся в этом соединении, остаются еще некоторый интервал времени действительными, что дает возможность долго блуждавшим по сети ТСР-пакетам добраться до места назначения (где они будут просто проигно­ рированы). Значение этого интервала равно удвоенному времени жизни IP-па­ кета (обычно, 2 X15 = 30 с).

Таймеры поддержки соединения. Для проверки наличия логического со­ единения между ТСР-модулями используют следующий механизм. Каждый ТСР-модуль, участвующий в логическом соединении, через фиксированный промежуток времени (keep-alive timer), равный обычно 45 с, периодически от­ правляет партнеру пустые (не содержащие данньпс) ТСР-пакеты и ждет их подтверждения. Каждое полученное подтверждение говорит о сохранении со­ единения. Если же в течении определенного интервала времени (idle timer), рав­ ного обычно 360 с, не будет получено ни одного подтверждения, то логическое соединение считается оборванным.

Очевидно, что данный механизм имеет смысл включать в работу только тогда, когда партнеры по ТСР-взаимодействию приостановили по какой-либо причине обмен данных на достаточно длительный срок (более 45 с).

Протокол UDP

Протокол дейтаграмм пользователя UDP (User Datagram Protocol) являет­ ся протоколом транспортного уровня и базируется на возможностях, предос­ тавляемых межсетевым протоколом IP. Основная задача TCP - обеспечение «быстрой» передачи данных в сети. Его транспортный адрес в заголовке IPсегмента равен 17. Описание протокола UDP дано в рекомендащш RFC-768.

Назначение и основные хара1стеристики протокола. Протокол транс­ портного уровня UDP играет роль интерфейса для прикладных программ к сред­ ствам протокола межсетевого уровня IP. Данные, отправляемые прикладным процессом через модуль UDP, достигают места назначения как единое целое.

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

407

5. Сетевые протоколы

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

Основные характеристики протокола:

•реализует взаимодействие без установления логического (виртуального) соединения;

•организует дейтаграммную передачу данных;

•использует 16-битовые номера портов для идентификащш партнеров по взаимодействию на транспортном уровне;

•не гарантирует надежной передачи данных (возможна как потеря UDPпакетов, так и их дублирование);

•не имеет средств уведомления источника UDP-пакета о доставке пакета адресату;

•не обеспечивает правильный порядок доставки UDP-пакетов от источни­ ка к приемнику;

•может гарантировать целостность даьшых в UDP-пакете за счет исполь­ зования контрольной суммы;

•очень прост (особенно, по сравнению с протоколом TCP).

Формат UDP-дейтаграммы и назначение полей. Формат заголовка для дейтаграмм пользователя приведён на рис. 5.53. Если задействован порт от­ правителя, то он указывает порт процесса, посьшающего дейтаграмму. Мож­ но принять, что это тот порт, на который при отсутствии какой-либо иной ин­ формации следует адресовать ответную дейтаграмму. Если данное поле не задействовано, то в него следует записать нули. Порт получателя имеет смысл только в конгексте конкретного Intemet-адреса получателя.

Длина - длина в октетах данной UDP-дейтаграммы, включающая как за­ головок, так и данные (это означает, что минимальное значение поля длины равно восьми).

Контрольная сумма - 16-битное дополнение до единицы суммы дополне­ ний полей UDP-заголовка, поля данных, нескольких полей из заголовка в прото­ коле IP (IP-адрес отправителя, IP-адрес получателя, поле протокола) и поля

408

5.6. Протоколы IIуровня стека TCP/IP

места назначения, так как UDP-заголовок определяет только номер протоколь­ ного порта. Таким образом, чтобы проверить место назначения, UDP на компьютере-источнике вычисляет контрольную сумму, которая учитьюает IPадрес назначения, а так же саму UDP-дейтаграмму. При получении дейтаг­ раммы в месте назначения программы UDP проверяют контрольную сумму, используя IP-адрес назначения, полученный из заголовка 1Р-дейтаграммы, которая содержала UDP-сообщение. Если контрольные суммы одинаковы, дейтаграмма действительно достигла нужного хост-компьютера и нужного порта в нем.

Если контрольная сумма равна нулю, то это означает, что отправитель дей­ таграммы ее не подсчитывал, и, следовательно, ее нужно игнорировать. Если два модуля UDP взаимодействуют только через одну сеть Ethernet, то от кон­ трольного суммирования можно отказаться, так как средства Ethernet обеспе­ чивают достаточную степень надежности обнаружения ошибок передачи. Это снижает накладные расходы, связанные с работой UDP. Однако рекомендует­ ся всегда вьшолнять контрольное суммирование, так как возможно в какой-то момент изменения в таблице маршрутов приведут к тому, что дейтаграммы будут посьшаться через менее надежную среду.

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

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

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

Концептуально все процессы мультиплексирования и демультиплексирования между UDP и прикладными программами осуществляются с помощью меха­ низма портов. На практике каждая прикладная программа должна договориться с операционой системой о получении протокольного порта и связанного с ним номера перед посьшкой UDP-дейтаграммы. Когда порт выделен, прикладная программа посьшает любую дейтаграмму через порт, номер которого указан в поле «Порт отправителя» UDP-заголовка. В ходе обработки входных данных

409