Материал: IP Телефония_Гольдштейн_1-4 части

процессами, которые предоставляют свой сервис через общеизве& стный номер своего порта (например, HTTP, SMTP и т. д.). При актив& ном режиме участия рабочая станция сама инициирует открытие TCP&канала. Соединение будет также установлено, если два процес& са активно откроют канал навстречу друг другу. Такая гибкость в ус& тановлении соединения особенно важна в распределенных сетях, ко& гда компьютеры работают асинхронно.

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

Именно трех тактов квитирующих сообщений всегда бывает дос& таточно, чтобы синхронизировать потоки данных. Соединение счи& тается установленным, когда последовательности передаваемых пакетов в обоих направлениях синхронизируются, т.е. когда и кли& ент, и сервер «знают», пакет с каким номером поступит с противопо& ложной стороны соединения.

Соединение закрывается, когда порты оборудования обменива& ются пакетами, содержащими флаги FIN. При этом все ресурсы сис& темы должны быть освобождены.

4.7.3 Механизмы обеспечения достоверности

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

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

При передаче информации каждому байту данных присваивается порядковый номер, поэтому, в какой бы последовательности эти бай& ты ни достигали точки назначения, они всегда будут собраны в изна& чальной последовательности. Порядковый номер первого байта дан& ных в передаваемом сегменте называется порядковым номером сег& мента. Нумерация проводится «с головы состава», т. е. от заголовка пакета. TCP&пакет содержит также «подтверждающий номер» (ac& knowledgment number), который представляет собой номер следую& щего ожидаемого пакета. Иными словами, подтверждающий номер означает: «до сих пор я все получил». Механизм с использованием «подтверждающего номера» исключает дублирование пакетов при повторной отправке не доставленных данных.

Кроме определения порядка следования информационных паке& тов, «порядковый номер» играет важную роль в механизме синхро& низации соединения и в контроле потерянных пакетов при разрывах соединения.

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

Так, при установлении нового соединения генерируется 32&бито& вое число ISN (Initial Sequence Number). Генератор может использо& вать 32 младших разряда машинного таймера, который меняется каждые 4 микросекунды (полный цикл – 4,55 часа). Это число и слу& жит отсчетом нумератора пакетов. Кроме того, каждая дейтаграмма

всети имеет ограниченное время жизни MSL – Maximum Life Time, которое значительно меньше периода генератора. Таким образом,

всети гарантируется невозможность появления пакетов с одинако& выми номерами.

Поврежденные пакеты отсеиваются механизмом проверки кон& трольной суммы, которая помещается в каждом передаваемом па& кете.

4.7.4 Механизм управления потоком данных

Протокол TCP предоставляет получателю пакетов возможность регулировать передаваемый к нему отправителем поток данных. Этот механизм основан на том, что при передаче флага подтверждения получения пакета (АСК) в ТСР&сегменте передается указатель объе& ма данных (так называемое «окно» TCP&соединения), которые могут

быть переданы отправителем, не дожидаясь от получателя разреше& ния отправить следующую порцию данных. Иными словами, указы& вается размер свободного места в буферном накопителе, куда за& писываются только что принятые данные, ожидающие дальнейшей обработки и передачи соответствующим процессам. Этот механизм позволяет избежать «пробок» при обмене данными между система& ми, обладающими разной производительностью.

«Окно» задается количеством байтов, отсчитываемых от послед& него подтвержденного байта (acknowledgment number). Нулевой раз& мер окна означает, что отправитель должен приостановить передачу до тех пор, пока он не будет уведомлен о готовности получателя к приему данных. Необходимо заметить, что в этом случае отправи& тель передает однобайтовые пакеты.

Безусловно, большой размер окна позволяет передавать данные быстрее, поскольку отправителю пакета не нужно ждать от получа& теля сигнал о его готовности к приему. Однако в случае сбоя переда& чи, соответственно, возрастет объем данных, которые нужно отпра& вить заново. При небольшом же размере окна потерянные сегменты данных можно восстановить с минимальными затратами.

Механизм управления потоком данных позволяет протоколу TCP оптимизировать скорость достоверного обмена данными между про& цессами в сети Интернет.

4.7.5 Состав и назначение полей заголовка

Пакеты протокола ТСР переносятся в поле «Данные» IP&дейта& граммы. Заголовок пакета TCP следует за заголовком дейтаграммы. Структура заголовка пакета TCP представлена на рис. 4.5.

Рис. 4.5 Заголовок пакета TCP

Порт отправителя (Source Port, 16 битов).

Порт получателя (Destination Port,16 битов).

Порядковый номер (Sequence Number, 32 бита). Если в пакете от& сутствует флаг SYN, то это – номер первого октета данных в этом пакете. Если флаг SYN в пакете присутствует, то номер данного паке& та становится номером начала последовательности (ISN), и номером первого октета данных становится номер ISN+1.

Номер при подтверждении (Acknowledgment Number, 32 бита) – если пакет содержит установленный флаг АСК, то это поле содержит номер следующего ожидаемого получателем октета данных. При ус& тановленном соединении пакет подтверждения отправляется всегда.

Поле величины смещения данных (Data Offset,4 бита) указывает количество 32&битовых слов заголовка TCP&пакета.

Резерв (Reserved, 6 битов) – зарезервированное поле.

Флаги управления (слева направо):

URG – флаг срочности,

АСК – флаг пакета, содержащего подтверждение получения,

PSH – флаг форсированной отправки,

RST – сброс соединения,

SYN – синхронизация порядковых номеров,

FIN – флаг окончания передачи со стороны отправителя.

Окно (Window, 16 битов) – поле содержит количество байтов дан& ных, которое отправитель данного сегмента может принять, считая от байта с номером, указанным в поле Номер при подтверждении.

Поле контрольной суммы (Checksum, 16 битов).

Поле указателя срочности данных (Urgent Pointer, 16 битов). Это поле содержит номер пакета, начиная с которого следуют пакеты повышенной срочности. Указатель принимается во внимание только в сегментах с установленным флагом URG.

Опции (Options) – поле дополнительных параметров, может быть переменной длины.

Заполнение (Padding) – поле, заполняемое нулями для выравни& вания заголовка до размера, кратного 32&битам.

Более подробное описание протокола TCP можно найти в RFC&793, RFC&1180.

4.8 Протокол UDP

Протокол передачи пользовательских дейтаграмм – User Datagram Protocol (UDP) значительно проще рассмотренного в предыдущем па& раграфе протокола TCP и предназначается для обмена дейтаграм& мами между процессами компьютеров, расположенных в объединен& ной системе компьютерных сетей.

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

ную доставку данных, т.е. не требует подтверждения их получения; кроме того, данный протокол не требует установления соединения между источником и приемником информации, т. е. между модуля& ми UDP.

К заголовку IP&пакета протокол UDP добавляет служебную инфор& мацию в виде заголовка UDP&пакета (рис. 4.6).

Порт отправителя (Source Port) – поле указывает порт рабочей станции, передавшей дейтаграмму. На этот порт следует адресо& вать ответную дейтаграмму. Если данное поле не используется, оно заполняется нулями.

Порт получателя (Destination Port) – поле идентифицирует порт ра& бочей станции, на которую будет доставлен пакет.

Длина (Length) – это поле информирует о длине UDP&пакета в ок& тетах, включая как заголовок, так и данные. Минимальное значение длины равно восьми.

Контрольная сумма (Checksum) – поле проверки правильности пе& редачи данных заголовка пакета, псевдозаголовка и поля полезной нагрузки пакета. Если данное поле не используется, оно заполняет& ся нулями.

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

Более подробную информацию о протоколе UDP можно найти

вRFC&768.

4.9Требования к современным IP1сетям

Вглаве 3 были рассмотрены принципы кодирования речевой ин& формации, используемые для передачи ее по сетям с маршрутиза&