/
Автор: Семенов Ю.А.
Теги: компьютерные технологии вычислительная техника микропроцессоры эвм телекоммуникации интернет компьютерные сети
ISBN: 5-93517-019-1
Год: 2001
Текст
Сети и сетевые
технологии
Ю. А. Семенов
Протоколы
Interne
Ю.А.Семенав
Протоколы
Энциклопедия
Москва
Горячая линия - Телеком
2001
УДК 681.324
ББК 32.97
Автор: Семенов Ю.А.
СЗО Протоколы Интернет — М.: Горячая линия-Телеком, 2001.
— 1100 с.: ил.
ISBN 5-93517-019-1.
В основу этой работы отчасти легли материалы книг «Протоколы и ресурсы
Интернет» (Радио и связь, М. 1996) и «Сети Интернет. Архитектура и протоко-
лы» (Сиринъ, М. 1998), которые в свою очередь базировались на двух курсах,
прочитанных автором студентам кафедры МФТИ «Телекоммуникационные сети
и системы»- «Каналы и сети передачи данных», «Протоколы Интернет».
Технологии Интернет развиваются настолько стремительно, что даже со
времени выхода последней книги, многое изменилось. Внедряется мультимедиа,
IP-телефония, развилась сетевая торговля, реклама, сфера развлечений, ужесто-
чились требования к безопасности, на подходе интеграция с цифровым телеви-
дением и т.д.
Книга рассчитана на широкий круг читателей, интересующихся сетевыми
технологиями. Но, полагаю, может быть полезна в качестве пособия для сту-
дентов, сетевых интеграторов и администраторов. Здесь собран большой объем
информационных материалов по каналам передачи данных, протоколам фи-
зического уровня и наложенным, виртуальным сетям, обобщен также опыт
построения, эксплуатации и диагностирования многопротокольной сети ИТЭФ,
содержащей более 450 различных ЭВМ. Книга представляет собой справочник
для специалистов, которые создают новые сетевые программные продукты и
технологии.
ББК 32.97
ISBN 5-93517-019-1
© Семенов Ю.А., 2001
Тираж 5 000 экз. Заказ № 3430.
Отпечатано с готовых диапозитивов в Тульской типографии.
300600, г. Тула, пр. Ленина, 109.
о
7. Введение
Интернет является сетью виртуальных сетей. В 1991 году у нас
(тогда еще в СССР) о нем знали несколько десятков человек, кото-
рые только что освоили электронную почту (через RELCOM) и по-
пробовали, что такое FidoNet. Первое сообщение по электронной
почте было послано президентом США Биллом Клинтоном 2 мар-
та 1993 года. Первая новелла Стивена Кинга была опубликована
по каналам Интернет 19 сентября 1993 года (до появления печат-
ной копии), к тому же году относится начало синхронной передачи
радиопрограмм по сетям Интернет. В конце 1993 года заработала
первая очередь оптоволоконной опорной сети Москвы, полностью
профинансированная Джорджем Соросом. В 1994 году НАТО орга-
низовало первую конференцию по Интернет в России (в Голицыно
под Москвой). С помощью DFN (Deutsche Forschung Naetze), а за-
тем Дж. Сороса и RELARN круг любителей Интернет расширился
до сотен и тысяч, а после включения программ Минвуза и Мини-
стерства науки счет пошел на десятки тысяч. Это произошло преж-
де всего потому, что созрели условия — в различных учреждениях
(сначала научных, а затем коммерческих и государственных) и у
частных лиц оказались сотни тысяч персональных ЭВМ. К этому
же времени (1992-93 годы) в мире стала формироваться сеть депо-
зитариев, доступных через анонимный доступ (FTP), а несколько
позднее и WWW-серверов. На рис. 1.1 показан рост числа ЭВМ,
подключенных к Интёрнет по годам с 1989 по 1998 годы. Видно,
что рост числа узлов сети имеет экспоненциальный характер. Мож-
но смело утверждать, что протоколы Интернет, созданные для осу-
4
Глава 1
ществления связи в случае нанесения десятков ядерных ударов по
США со стороны СССР, явились одним из немногих (возможно
единственным) положительным результатом холодной войны.
Сегодня, когда Интернетом заинтересовались широкие массы
трудящихся, и определенная часть их подключилась к расширению
этой сети, стала актуальной проблема оптимального проектирова-
ния сетей и их подключения к общенациональной и международ-
ной сети Интернет.
Современные сети Интернет объединяют в единое целое многие
десятки (а может быть уже и сотни) тысяч локальных сетей по
всему миру, построенных на базе самых разных физических и логи-
ческих протоколов (Ethernet, Token Ring, ISDN, X.25, Frame Relay, и
т.д.). Эти сети объединяются друг с другом с помощью последова-
тельных каналов (протоколы SLIP, PPP), сетей типа FDDI (часто
используется и в локальных сетях), ATM, SDH (SONET) и многих
других. В самих сетях используются протоколы TCP/IP (Интер-
нет), IPX/SPX (Novell), AppleTalk, NetBIOS и бесконечное множе-
ство других, признанных международными, являющихся фирменны-
ми и т.д. Картина будет неполной, если не отметить многообразие
сетевых программных продуктов (Windows NT, MS Windows-95,
NetWare, MultiNet, LANtastic и пр.). На следующем уровне пред-
ставлены разнообразные внутренние (RIP, IGRP, OSPF) и внешние
(BGP, IS-IS и т.д.) протоколы маршрутизации и маршрутной поли-
тики, конфигурация сети и задание огромного числа параметров,
проблемы диагностики и сетевой безопасности. Немалую трудность
Рис. 1Л. Рост числа ЭВМ, подключенных к Интернет
в период 1989-99 годы
(по вертикальной оси отложено число ЭВМ в миллионах]
Введение
5
может вызвать и выбор прикладных программных средств (NetScape,
MS Explorer и пр.). В последнее время сети внедряются в управле-
ние (CAN), сферу развлечений, торговлю, происходит соединение се-
тей Интернет и кабельного телевидения.
Что явилось причиной стремительного роста сети Интернет? Со-
здатели базовых протоколов (TCP/IP) заложили в них несколько
простых и эффективных принципов: инкапсуляцию пакетов, фраг-
ментацию/дефрагментацию сообщений и динамическую маршру-
тизацию путей доставки. Именно эти идеи позволили объединить
сети, базирующиеся на самых разных операционных системах
(Windows, UNIX, SUNOS и пр.), использующих различное оборудо-
вание (Ethernet, Token Ring, FDDI, ISDN, ATM, SDH и т.д.) и сделать
сеть нечувствительной к локальным отказам аппаратуры. Огром-
ный размер современной сети порождает ряд серьезных проблем.
Любое усовершенствование протоколов должно проводиться так,
чтобы это не приводило к замене оборудования или программ во
всей или даже части сети. Достигается это за счет того, что при
установлении связи стороны автоматически выясняют сначала, ка-
кие протоколы они поддерживают, и связь реализуется на общем
для обеих сторон наиболее современном протоколе (примером мо-
жет служить использование расширения протокола SMTP — MIME).
В кабельном сегменте современной локальной сети можно обнару-
жить пакеты TCP/IP, IPX/SPX (Novell), AppleTalk, DecNet, которые
успешно сосуществуют.
Проектировщикам и создателям сетей приходится учитывать
многие десятки факторов при выборе того или иного типа сети,
сетевого оборудования, операционной системы (UNIX, MS-DOS, IRIS,
Windows-NT, Solaris или что-то еще), программного обеспечения,
внешних каналов связи (выделенный канал, коммутируемая теле-
фонная сеть, цифровая сеть, радио или спутниковый канал) и, в
конце концов, сервис-провайдера. За всем этим стоят как техноло-
гические проблемы, таю и финансовые трудности, тяжелый выбор
между дешевой и хорошей сетью.
Если вас интересуют оригинальные тексты протоколов Интер-
нет, вы можете получить их, например, через анонимное FTP по
адресу DS.INTERNIC.NET (в каталоге RFC) или на нашем сервере.
STORE.IN.RU/RFCS (зеркало). Эти документы можно найти и в
других депозитариях.
Документы RFC делятся на стандарты, проекты стандартов, вре-
менные (экспериментальные) регламентации и предложения. Чем
больше номер RFC, тем более поздней дате этот документ соответ-
ствует. О статусе тех или иных RFC можно узнать из RFC-1500 и -
6
tyaea 1
1780 (см. также файл STD-INDE.TXT из того же депозитария, что и
RFC-INDEX.TXT). Если вы хотите найти какой-то RFC-документ,
начните с просмотра индексного файла (напр. RFC-INDEX.txt). Пер-
вый документ RFC был выпущен в 1969 году более 30 лет тому
назад. Далее темп публикаций варьировался в довольно широких
пределах, в 1997-99 годах наблюдается заметный всплеск активно-
сти, связанный с потребностями мультимедиа (RTP, RSVP, PIM и
т.д.), безопасностью и IPv6. Вариация публикаций документов RFC
по годам представлена на рис 1.2.
Из этого распределения видно, что к 1979 году окончательно
сформировался стек базовых протоколов и начался экстенсивный
рост сети Интернет. По мере выявления недостатков протоколов и
новых потребностей после 1989 года началась активная разработка
новых направлений и приложений в Интернет.
Но все по порядку. Начнем с того, как устроен Интернет. На
рис. 1.3 показана общая схема, которая облегчит дальнейшее об-
суждение данной проблематики (буквами R отмечены маршрутиза-
торы-порты локальных сетей).
Каждая из сетей, составляющих Интернет, может быть реализо-
вана на разных принципах, это может быть Ethernet (наиболее по-
пулярное оборудование), Token Ring (вторая по популярности сеть),
ISDN, Х.25 или FDDI. Все внешние связи локальной сети осуществ-
ляются через порты-маршрутизаторы (R). Если в локальной сети
использованы сети с разными протоколами на физическом уровне,
они объединяются через специальные шлюзы (например, Ethernet-
FastEthernet, Ethernet-FDDI и т.д.). Выбор топологии связей опреде-
Рис. 1.2. Распределение публикаций документов RFC
по годам с 1969 по 1999
Введение
7
ляется многими факторами, не последнюю роль играет надежность.
Использование современных динамических внешних протоколов мар-
шрутизации, например BGP-4, позволяет автоматически переключаться
на один из альтернативных маршрутов, если основной внешний ка-
нал отказал. Поэтому для обеспечения надежности желательно иметь
не менее двух внешних связей. Сеть LAN-6 (см. рис; 1.3) при выходе
из строя канала R2-R6 окажется изолированной, а узел LAN-7 ос-
танется в сети Интернет даже после отказа трех внешних каналов.
Здесь также уместно заметить, что многие соединения реализуется с
привлечением протокола РРР.
Широкому распространению Интернет способствует возможность
интегрировать самые разные сети, при построении которых исполь-
зованы разные аппаратные и программные принципы. Достигается
это за счет того, что для подключения к Интернет не требуется
какого-либо специального оборудования (маршрутизаторы не в счет,
ведь это ЭВМ, где программа маршрутизации реализована аппаратно).
Некоторые протоколы из набора TCP/IP (ARP, SNMP) стали уни-
версальными и используются в сетях, построенных по совершенно
иным принципам.
В некотором смысле Интернет возник эволюционно — в начале
был BITNET, FidoNet, USENET и т.д. Со временем стало ясно, что
конкуренция сетей должна быть заменена их объединением, так как
от этого выигрывают все и пользователи и сервис-провайдеры. Ведь
объединённая сеть имеет большие информационные ресурсы, может
предложить более широкий список услуг и становится по этой при-
чине привлекательной для еще большего числа клиентов.
' LAN-1 J в Интернет
< LAN-2 J X ;
\rR-2~;
в Интернет ' ' _ _
' (' LAN-5 j LAN-4
! R-6 "
LAN-6 R-7 j- ^LAN-T^' в Интернет
x-/
Z в Интернет Ч
Рис. 1.3. Схема построения сети Интернет
8
Глава 1
Технология WWW-серверов сделала Интернет важной средой
для целевой рекламы, приближенной к конечному потребителю.
Стремительный рост числа узлов WWW продемонстрирован на рис.
1.4. Здесь также наблюдается экспоненциальный рост. Сам факт
использования Интернет для обливания грязью кандидатов во вре-
мя предвыборной компании, говорит о том, что эта технология осво-
ена и признана эффективной нашими политиками. Наше общество
с удивительным упорством сначала осваивают все негативное, ос-
тавляя, очевидно, позитивное на десерт.
В перспективе Интернет может стать и всемирной ярмаркой то-
варов и услуг. Ведь клиент может не только увидеть изображение
товара и ознакомиться с условиями поставки, но и в диалоговом
режиме получить ответы на интересующие его вопросы, а затем
одним нажатием на клавишу мышки сделать заказ на понравив-
шийся ему товар или услугу. В принципе для этого не нужен даже
номер кредитной карточки, его заменит зашифрованный соответ-
ствующим образом идентификатор пользователя (сертификат) или
его IP-адрес (если он работает на своей домашней машине). Таким
образом, можно будет заказывать билеты на самолет или в театр,
планировать программу своего телевизора на неделю вперед и т. д.
Современные системы мультимедиа позволяют совместить теле-
визор, видеомагнитофон, факс и видеотелефон, причем это не фанта-
зия на тему далекого будущего — это услуги доступные уже сегод-
ня (при наличии широкополосного канала связи (64-512 Кбит/с)).
Если вы имеете доступ к Интернет, вам уже не нужно платить за
международные телефонные переговоры, вы можете сделать это с
помощью IP-Phone или другого аналогичного продукта, при условии
что ваш партнер также имеет доступ к Интернет (данное требова-
ние в ближайшем будущем перестанет быть обязательным). Йсе
более широкий круг услуг предлагает Интернет и в сфере развлече-
Рис. 1.4. Рост числа узлов WWW в период 1994-99 годы
Введение
9
ний. Здесь имеются игровые серверы, аренда обычных и сетевых
компьютерных игр, различные конкурсы и соревнования.
Теперь рассмотрим, как строятся каналы связи (стрелки на рис.
1.5). В простейшем случае связь можно организовать через городс-
кую коммутируемую телефонную сеть, для этого нужны модемы —
по одному на каждой из сторон канала (рис. 1.5А). Следует заме-
тить, что все рассмотренные на рисунке варианты, могут быть обес-
печены протоколом РРР. Традиционные модемы могут предоста-
вить при хорошем качестве коммутируемой аналоговой телефонной
сети пропускную способность до 56 Кбит/с (кабельные широкопо-
лосные модемы при длине соединения порядка 2 км могут гаранти-
ровать 2 Мбит/с). Привлекательность такого решения заключается
в возможности подключения к любому узлу, имеющему модемный
вход. Наиболее широко указанный метод связи используется для
подключения к узлам Интернет домашних ЭВМ. Недостатком та-
кого решения является низкая надежность канала (особенно в Рос-
сии), малая пропускная способность и необходимость большого чис-
ла входных телефонных каналов и модемов.
Использование выделенной 2- или 4-проводной линии (рис. 1.5Б)
обеспечивает большую надежность и пропускную способность (до 256
кбит/с при длинах канала < 10 км). Но и здесь на каждый вход
требуется отдельный модем, да и скоростные модемы, работающие на
выделенную линию, относительно дороги. Выделенные линии чаще
служат для межсетевого соединения (рис. 1.5В). Функциональным
аналогом выделенных линий являются оптоволоконные, спутнико-
вые и радиорелейные каналы. Этот вариант позволяет строить сети с
пропускной способностью в несколько 1-100 Мбит/с и более.
Рис. 1.5. Схемы каналов, использующих городскую телефонную сеть
10
Глава 1
Привлекательные возможности предлагают цифровые сети ISDN.
Здесь можно использовать групповые телефонные номера, когда пара
модемов обслуживает 10 и более пользователей (ведь они работают,
как правило, не все одновременно). Кроме того, ISDN предлагает
пользователям каналы с пропускной способностью не ниже 64кбит/с,
а при необходимости возможно формирование и более широкопо-
лосных каналов. ISDN позволяет делить один и тот же канал меж-
ду многими пользователями для передачи данных, факсов и теле-
фонных переговоров. ISDN органично стыкуется с внешними кана-
лами Х.25. К недостаткам системы следует отнести ограниченность
ширины окна (число переданных пакетов без получения подтверж-
дения приема), что делает неэффективным использование широко-
полосных и особенно спутниковых каналов. В области межсетевых
связей свою нишу занимает Frame Relay. Этот протокол имеет кон-
троль перегрузок, работающий на аппаратном уровне.
На рис. 1.5 показана схема построения сети с использованием
исключительно соединений типа точка-точка. Это наиболее часто
встречающийся, но не единственный вариант. Дорога «от околицы
до околицы» прокладывается там, где она нужна и теми, кому она
нужна непосредственно, но, согласитесь, построить так магистраль
Москва Санкт-Петербург нельзя. При построении крупных общена-
циональных и интернациональных сетей применяются сверхширо-
кополосные каналы и схемы типа опорной сети (backbone). Узлы
такой сети могут располагаться в каких-то крупных организациях
или быть самостоятельными (принадлежать государственным РТТ).
Такие сети обычно базируются на протоколах SDH (SONET). Ин-
формация в этих сетях передается в виде больших блоков (вирту-
альных контейнеров). Использование опорной сети обычно оправ-
дано при организации интернациональных связей, но бывают и ис-
ключения. Примером такого исключения является Московская
опорная сеть, построенная на основе FDDI (100Мбит/с) и объединя-
ющая более 15 научных организаций (длина первой очереди более
30 км). Московская сеть выполнена по схеме с «прозрачными» IP-
мостами, обычно же более мощные опорные сети маршрутизируемы,
то есть блоки данных адресуются конкретным узлам, где они разби-
раются и сортируются. Контейнер может содержать сообщения, ад-
ресованные разным получателям, что несколько противоречит идео-
логии протоколов TCP/IP. IP-пакеты могут вкладываться в эти
контейнеры и транспортироваться до заданного узла опорной сети.
Классическими примерами опорных сетей является E-BONE (Евро-
пейская опорная сеть) и RBNet (опорная сеть РФ). E-BONE объеди-
няет 27 стран (России в этом списке нет) и более 60 сервис-провай-
Введение
деров, пропускная способность для различных участков лежит в
пределах 2-34Мбит/с. Опорная сеть подобна международной авто-
магистрали, по ней добираются до ближайшего к точке назначения
узла, а далее по «проселочным» каналам до конечного адресата.
Резкое увеличение передаваемых объемов информации в локаль-
ных и региональных сетях привело к исчерпанию имеющихся ре-
сурсов, а реальные прогнозы потребностей указывают на продолже-
ние роста потоков в десятки и сотни раз. Единственной технологи-
ей, которая способна удовлетворить эти потребности, являются
оптоволоконные сети (SONET, SDH, ATM, FDDI, Fiber Channel). Ка-
налы этих сетей уже сегодня способны обеспечить пропускную спо-
собность 155-622 Мбит/с, ведутся разработки и испытания каналов
с пропускной способностью в 2-20 раз больше, например, гигабитно-
го Ethernet. Осваивается техника мультиплексирования частот в
оптоволокне (WDM), что позволяет поднять его широкополосность
в 32 раза и в перспективе довести быстродействие каналов до 80
Гбит/с и более. По мере роста пропускной способности возрастают
проблемы управления, синхронизации и надежности. Практически
все сети строятся сегодня с использованием последовательных ка-
налов. Это связано, прежде всего, со стоимостью кабелей, хотя и
здесь существуют исключения (например, HIPPI). Разные сетевые
услуги предъявляют разные требования к широкополосности кана-
ла. На рис. 1.6 представлены частотные диапазоны для основных'
видов телекоммуникационных услуг. В Интернет практически все.
перечисленные услуги доступны уже сегодня (кроме ТВ высокого
разрешения).
Видеотелефон ТВ-высокого разрешения
/ *-----------------------------:-----*
* WWW-сервис
FTP
« ................ 11 1 —- ►
Факс CAD/CAM
Т^олос HiF^
Делеке телетекст*
Telnet
--------1------1-------1-------1______I_______I_______I_______I
10 100- IK ЮК 100К 1М ЮМ Ю0М 1Гбит/с
Рис. 1.6, Требования к пропускной способности канала
для различных видов сервиса»
12
Гпава 2
Рассмотрев диаграмму, можно сделать определенные прогнозы
на ближайшее будущее сетей. Через несколько лет можно ожидать
слияния функций телевизора и ЭВМ, а это потребует пропускных,
способностей от магистральных каналов на уровне 0,1-10 Гбит/с.
Широкополосность каналов, приходящих в каждый семейный дом
составит 1-10 Мбит/с, что позволит реализовать видео-телефонию,
цифровое телевидение высокого разрешения, доступ к централизо-
ванным информационным службам и многое другое. Уже суще-
ствующие оптоволоконные системы обеспечивают и в 10 раз боль-
шую пропускную способность. Можно предположить и появление
локальных сетей внутри жилища. Такие сети способны взять под
контроль кондиционирование воздуха, безопасность дома в самом
широком смысле этого слова, например, оповещение о нежелатель-
ном вторжении, пожаре или возможном землетрясении (в сейсми-
чески опасных районах), появление вредных примесей в воздухе.
Такая система разбудит хозяина в указанное время, подогреет завт-
рак, напомнит о предстоящих делах на день, запросит и предоставит
хозяину свежий прогноз погоды и справку о состоянии дорог, своев-
ременно сделает заказ на авиабилет и т.д. Все это технологически
возможно уже сегодня, пока относительно дорого, но цены весьма
быстро падают. Примером может служить сеть CAN, разработанная
для сбора данных и управления автомобилем. Стремительное рас-
ширение сети Интернет не имеет аналогов в исторйи, так что любой
самый фантастический прогноз в этой области может сбыться.
Протоколы Интернет (TCP/IP) существуют уже около 30 лет.
Требования к телекоммуникационным каналам и услугам вырос-
ли, и этот набор протоколов не удовлетворяет современным требо-
ваниям. Появляются новые протоколы Delta-t (для управления со-
единением), NetBLT (для передачи больших объемов данных), VMTP
(для транзакций; RFC-1045) и ХТР для повышения эффективнос-
ти передачи данных (замена TCP), блоки протоколов для работы с
мультимедиа (RTP, RSVP, PIM, ST-II и пр.), но, безусловно, наиболее
революционные преобразования вызовет внедрение IPv6.
Подготовлены протоколы для организации электронной торгов-
ли IOTP, SET и т.д.
2. Преобразование, кодировка и
передача информации
Для передачи информации на большие расстояния в настоящее
времяшспользуются исключительно электромагнитные волны (аку-
стические волны пригодны лишь для ограниченных расстояний).
При этом пересылка может осуществляться по медным проводам,
оптоволоконному кабелю или непосредственно, по схеме передат-
чик-приемник. В последнем случае используются антенны. Для того
чтобы антенна была эффективна, ее размеры должны быть сравни-
мы с длиной передаваемой волны. Чем шире динамический диапа-
зон передаваемых частот, тем труднее сделать антенну, пригодную
для решения этой задачи. Именно по этой причине для передачи
используются частоты, начиная с многих сотен килогерц и выше
(длина волн сотни метров и меньше). Передача сигнала непосред-
ственно по лучу лазера ограничена расстояниями 100-3000м и ста-
новится неустойчивой при наличии осадков даже для инфракрас-
ных длин волн. Между тем человек воспринимает акустические
колебания в диапазоне 20-12000 Гц и для целей пересылки звука
(например, телефония) требуется именно этот диапазон частот. Ди-
намический диапазон частот в этом случае равен 600, а для высоко-
качественного воспроизведения звука он в два раза шире. При ре-
шении этой проблемы используется преобразование частот и раз-
личные методы модуляции. Так тот же частотный диапазон, лежащий
в пределах (100 — 100,012) Мгц, соответствует динамическому ди-
апазону 0,012%, что позволяет сделать компактную антенну и уп-
ростить частотное выделение сигнала.
74
Гпава 2
Для преобразования частот используется перемножение сигна-
лов. Пусть мы имеем два синусоидальных сигнала: A^sin^t) и
A2 sin(co2t). Из тригонометрии известно, что:
A1-sin((O1t)-A2-sin(co2t)=l/2A1A2[sin((D1+co2)t + sin(co1—co2)t], [1.1]
Это означает, что в результате перемножения вместо двух частот
11==(01/2л и f2=(D2/27C мы имеем две новые частоты (cd14-cd2)/2tt и
(со1—со2)/2л с амплитудой 1/2-А1-А2. Если входной сигнал имеет
полосу 0 — fM, то после перемножения с сигналом, имеющим часто-
ту fH (несущая частота), получим сигнал с полосой в интервале от
(fH — fM) до (fH + fM). Это преобразование проиллюстрировано на
рис. 2.1. (по вертикальной оси отложена спектральная плотность
сигнала F(jco)). На практике это преобразование выполняется с по-
мощью смесителей или гетеродинов, частота fH называется сигна-
лом гетеродина или несущей.
Получение исходного сигнала из преобразованного достигается
путем обратного преобразования, которое сводится к умножению
полученного сигнала на sin((DHt), где сон = 2 л-Г. При таком обрат-
ном преобразовании мы получим сигнал с исходным частотным
диапазоном. Помимо этого будет получен сигнал с полосой от
(2fH — fM) до (2fH+ fM). Так как fH обычно много больше fM, серьез-
ных проблем это не вызывает — достаточно воспользоваться соот-
ветствующим фильтром. Этому методу обратного преобразования
присущи некоторые недостатки. Если сигнал fH имеет фазовый сдвиг
О по отношению к тому, что имел сигнал, использованный при пря-
мом преобразовании, то амплитуда выходного сигнала будет про-
порциональна cos 0. Понятно, что при вариации фазы амплитуда
будет меняться, а при 0=л/2 станет нулевой. По этой причине долж-
fH-fM fH fH+fM F [Гц]
Рис. 2.7. Частотное преобразование
Преобразование, кодировка и передача информации
15
ны быть предприняты специальные меры для синхронизации этих
сигналов (fH. передатчика и fH приемника).
Соотношение [1.1] используется при реализации амплитуд-
ной, частотной или фазовой модуляции. Так в случае амплитудной
модуляции при временной вариации А1 (=А^х) будет изменяться и
амплитуда выходного сигнала (А2=Ан — амплитуда несущей часто-
ты при этом остается постоянной; 0^=0) при этом может также
варьироваться). Форма сигнала на выходе такого преобразователя
имеет вид: Авых = AH[l+ABx(t)] sin CDHt. Для получения формы ис-
ходного сигнала на принимающей стороне используется схема детек-
тора (например, диодного), на выходе которого получается сигнал,
пропорциональный модулю огибающей функции входного сигнала.
Существуют и другие методы демодуляции амплитудно-модулирован-
ного сигнала. Главным недостатком метода амплитудной модуля-
ции является возможность нелинейных искажений из-за перемоду-
ляции (когда амплитуда модулирующего сигнала слишком велика).
При частотной и фазовой модуляции амплитуда передаваемого
сигнала остается почти постоянной, что исключает нелинейные ис-
кажения, связанные с широким динамическим амплитудным диа-
пазоном. Выходной сигнал для этого вида модуляции имеет вид:
Авых = Ан sin[ci)Ht + 0(t)], где 0(t) зависит от формы преобразуемого
входного сигнала. Часто используется комбинация амплитудной и фа-
зовой модуляции, которая носит название квадратурной модуляции.
Системы передачи данных с амплитудной или частотной моду-
ляцией являются аналоговыми и по этой причине весьма чувстви-
тельны к шумам на входе приемника. Применение цифровых ме-
тодов пересылки информации увеличивает вероятность коррект-
ной доставки. Если для аналоговой передачи требуется отношение
сигнал/шум на уровне 40-60 дБ, то при цифровой передаче доста-
точно 10-12 дБ. Выбор типа модуляции зависит от стоящей зада-
чи и от характеристик канала (полосы пропускания, ослабления
сигнала и т.д.). Частотная модуляция менее чувствительна к амп-
литудным флуктуациям сигнала. Ослабление сигнала может ва-
рьироваться во времени из-за изменений в транспортной среде, это
довольно типична для коммутируемых телефонных сетей. В сетях,
использующих выделенные каналы, это также возможно благода-
ря применению динамических протоколов маршрутизации, когда
длина пути может изменяться в пределах одного сеанса связи. В
любом случае на передающей стороне необходим модулятор, а на
принимающей демодулятор. Так как обмен обычно двунаправлен,
эти устройства объединяются в одном приборе, который называет-
ся модемом.
16
Гпава 2
В модемах применимы несколько видов модуляции:
FSK (Frequency Shift Keying) — ступенчатое переключение часто-
ты синусоидального сигнала от f} к f2 при неизменной амп-
литуде, частоте f ставится в соответствие логический нуль, а
f2 — логическая единица.
BPSK (Binary Phase-Shift Keying) — скачкообразное переключение
фазы синусоидального сигнала на л при неизменной ампли-
туде, при этом фазе 0 ставится в соответствие логический
нуль, ал — логическая единица.
DPSK (Differential Phase Shift Keying) — метод, при котором изме-
няется фаза несущей частоты при постоянной амплитуде и
частоте. Разновидность PSK, при которой кодируется лишь
изменение сигнала.
QAM (Quadrature Amplitude Modulation) — комбинация амплитуд-
ной и фазовой модуляции, позволяет осуществить кодирова-
ние 8 бит на бод.
QPSK (Quadrature Phase-Shift Keying) — квадратурная фазовая мо-
дуляция. Использует 4 фиксированных значения фазы 0, л/2,
л и Зл/2. Требует в два раза более узкую полосу, чем PSK, и
по этой причине весьма популярна. *
ТСМ (Trellis Coded Modulation) — метод предполагает использо-
вание избыточности, каждый бод несет дополнительный бит,
который позволяет более точно восстановить информацион-
ную битовую последовательность. При кодировании сигнала
используется метод QAM. Метод реализован в современных
высокоскоростных модемах и позволяет снизить требования
к отношению сигнал/шум на 4-5 дБ.
В QAM-модуляции используется 8/16 комбинаций амплитуда-
фаза (см. рис. 2.2). Понятно, что такой тип модуляции более уяз-
вим для шумов.
Рис. 2.2. QAM-модуляция с 3 битами на бод [слева]
и 4 битами на бод (справа).
Преобразование, кодировка и передача информации
77
2.1. Передача сигналов по линиям связи
Теорема Шеннона ограничивает предельную пропускную способ-
ность канала I с заданной полосой пропускания F и отношением
сигнал/шум S/N: ' *
I = Flog2(l + S / N)
Z/F~l,44—
N
[2.1]
Для стандартного телефонного канала Е=ЗкГц, S/N=30dB, сле-
довательно, теоретический предел для публичной коммутируемой
телефонной сети равен примерно 30кбит/с. Ослабление для теле-
фонных скрученных пар составляет около 15 дБ/км, дополнитель-
ные ограничения возникают из-за перекрестных наводок. Стандар-
тные проводные линии связи имеют ослабление 6 дБ/км на частоте
800 Гц, или 10 дБ/км на частоте 1600 Гц. На рис. 2.1.1 показана
зависимость ослабления от частоты передаваемого сигнала для мед-
ной линии с сечением 0,5 мм.
От частоты зависит фаза (из расчета на километр) и волновое
сопротивление скрученной пары (см. рис. 2.1.2), по этой причине
искажения формы сигнала при заметной длине линии неизбежны.
Из формулы [2.1] видно, что расширять пропускную способность
канала можно за счет широкополосности и высокого отношения
сигнал-шум. Существует много источников шума, один из главных
тепловые шумы (Т = кТВ, где Т — температура в градусах Кельвина,
Рис. 2.11 Зависимость ослабления сигнала в медной линии
сечением 0,5 мм от частоты
18
Гпава 2
В — полоса пропускания приемника, а к — постоянная Больцмана).
На практике существенно большее влияние оказывают различного
рода наводки. Увеличение пропускной способности сети достигается
путем сокращения длины кабеля (уменьшение расстояния между
узлами сети), заменой типа кабеля, например, на провод с большим
сечением, или применив оптоволоконный кабель. Определенный эф-
фект может быть получен и с помощью усовершенствованной систе-
мы шумоподавления (новый, более эффективный модем).
Сопротивление скрученной пары от коммутатора до терминаль-
ного оборудования может лежать в пределах 800-20000 Ом. Следу-
ет учитывать, что при подаче питания на терминальное оборудова-
ние (телефон) по подводящему кабелю, большое его сопротивление,
помимо прочего, приведет к падению питающего напряжения.
В многожильных кабелях определенные проблемы создают перекре-
стные наводки и шумы. Обычно рассматриваются два случая пере-
крестных наводок:
* Источник сигнала и приемник находятся по одну сторону кабе-
ля (NEXT — Near End crosstalk);
* Приемник и источник находятся на разных концах кабеля (FEXT
— Far End crosstalk).
NEXT-наводки при большом числе пар проводов в кабеле под-
чиняются закону f 1.5 , а их уровень составляет около 55 дБ при
частоте 100 Кгц. FEXT-наводки сильно зависят от схемы коммута-
ции и разводки проводов и обычно менее опасны, чем NEXT. Еще
одним источников наводок является импульсный шум внешних
электромагнитных переходных процессов. Этот вид наводок обычно
характеризуется процентом времени, в течение которого его уровень
I
Импеданс, Ом Фаза
Рис. 2.1.2. Зависимость волнового импеданса скрученной пары и
фазы (сечение 0,5 мм] от частоты
Преобразование, кодировка и передача информации 19
превышает порог чувствительности, и варьируется в зависимости от
обстоятельств в очень широких пределах.
При передаче по линии сигналы модулируются, при этом важно
обеспечить сохранение среднего уровня сигнала (постоянной состав-
ляющей). Определенные искажения сигнала вносит сам кабель.
Заметное влияние на характер искажений оказывает межсимволь-
ная интерференция (ISI — Intersymbol Interference). Эта интерфе-
ренция возникает из-за расплывания импульсов в процессе их пере-
дачи по линии и наезжания их друг на друга. Проблема усложняет-
ся тем, что характеристики передающей линии могут меняться со
временем (коммутаторы и маршрутизаторы). По этой причине очень
важно обеспечить идентичность условий передачи различных час-
тот при наличии таких вариаций. Для решения этой задачи ис-
пользуются линейные эквилайзеры (рис. 2.1.3 и 2.1.4), которые
выполняют эту операцию во всем спектре частот, или после строби-
рования для реального спектра сигнала. Этот метод чувствителен к
шумам в системе. Эквилайзеры с решающей обратной связью (DFE
— Decision Feedback Equalizer) не чувствительны к шумам, они уп-
равляются принятой информацией. Но влияние ошибок при приеме
информации в этом случае может быть усилено.
На практике линейное выравнивание и эквилизация с обратной
связью совмещаются друг с другом и со специальными методами
формирования передаваемых сигналов. Проблема усугубляется тем,
что одна и та же линия используется для передачи данных в обоих
направлениях одновременно.
Эквилизованный
сигнал
Рис. 2.1.3. Линейное выравнивание (эквилизация]
Рис. 2.1.4. Эквилизация с помощью решающей обратной связи
20
Гпава 2
Для улучшения отношения сигнал/шум следует поднимать ам-
плитуду передаваемого по линии сигнала. Выбранное значение оп-
ределяется требованиями перекрестных наводок и возможностями
существующих БИС. В результате компромисса выбрана амплитуда
2.5 В на нагрузке 135 Ом. Любые нелинейные искажения должны
быть менее 36 дБ по отношению к основному сигналу. Учитывая
динамический диапазон сигналов в линиях связи, отношение сиг-
нал шум предполагается равным 20 дБ, что соответствует ограни-
чению 6 дБ на число ошибок 1/106 для гауссова распределения
шума. При аналого-цифровом преобразовании одному биту соот-
ветствует 6 дБ.
Обычно двухпроводная линия (тем более 4-х проводная) ис-
пользуется для одновременного двухстороннего обмена (full duplex).
Эта задача может быть решена схемотехнически мультиплексиро-
ванием по времени (TDD — Time Division Duplex) или частоте (FDD
— Frequency Division Duplex). TDD довольно легко реализовать,
этот метод не требует сложных фильтров и эквилайзеров. Метод
TDD привлекателен при малых длинах кабеля для коммутируемых
телефонных сетей.
Более широко для реализации двухстороннего обмена по одной
паре проводов используется метод эхо-компенсации. Этот метод
предполагает вычитание передаваемого сигнала из принимаемого,
определяя тем самым истинную форму входного сигнала. Если на
приведенном рисунке 2.1.5 Zbx равно волновому сопротивлению
линии, то выходной сигнал передатчика не будет влиять на работу
приемника. Здесь предполагается, что выходное сопротивление пе-
редатчика много меньше Z= 2ЛИНИИ. Учитывая вариации ослабле-
ния сигнала, схема эхо-компенсации должна уметь работать в очень
широком динамическом диапазоне амплитуд, сохраняя удовлетво-
рительную линейность. Это обстоятельство, а также зависимость Z
Рис. 2.1.5. Схема эхо-компенсации
Преобразование, кодировка и передача информации
21
линии от частоты, приводит к заметному усложнению схем эхо-
компенсации (Рис. 2.1.6). Системы эхо-компенсации весьма чув-
ствительны к временному разбросу срабатывания пороговых схем,
так как это приводит к фазовому сдвигу вычитаемых друг из друга
сигналов.
На рис. 2.1.7 показана зависимость скорости пропускания от
сопротивления петли передающей линии для разных схем кодиро-
вания сигнала (пунктирной линией отображен вариант четыреху-
ровневого кодирования). Те, кто работал с выделенными линиями,
усвоили эту зависимость на практике. Если сопротивление линии
более 1,5 кОм вы скоро будете знать дежурных вашей телефонной
станции по имени, узнаете, что такое грозовые вставки и что они
имеют привычку окисляться.
Рис. 2.1.6. Схема эхо-компенсации с адаптивным фильтром
Рис. 2.1.7. Зависимость максимальной скорости передачи данных
от сопротивлении петли передающей линии
22
Гпава 2
Различные методы модуляции приводят к разным уровням пе-
рекрестных наводок, и, как следствие, могут обеспечить разные ско-
рости пропускания сигналов. Так применение линейной эквилиза-
ции при амплитудной модуляции дает улучшение пропускной спо-
собности примерно в 5 раз. Из рисунка 2.1.8 видно, что переход от
линейного выравнивания к эквилизации с обратной связью позво-
ляет добиться улучшения почти в 1,5 раза. Многоуровневый метод
кодирования увеличивает скорость пропускания еще на 30%. Сле-
дует, правда, иметь в виду, что многоуровневый метод кодирования
характеризуется большим уровнем импульсных помех и, следова-
тельно, ошибок.
На рис. 2.1.8 показана зависимость отношения сигнал-шум от
сопротивления петли для разных схем передающего канала. Пунк-
тиром проведены зависимости для случая четырехуровневого коди-
рования. Кривые 1 соответствует случаю амплитудной модуляции с
линейным выравниванием, а кривые 2 — варианту эквилизации с
обратной связью.
Рис. 2.1.8. Минимальное отношение сигнал-шум при скорости
передачи ~150кбит/с
Преобразование, кодировка и передача информации
23
2.2. Представление электрических сигналов
в двоичной форме
Прогресс последних лет в области повышения пропускной спо-
собности каналов в заметной мере связан с развитием технологии
передачи цифровых данных. Здесь нужно решить проблемы синхро-
низации, эффективного кодирования и надежной передачи. Чем шире
импульс, тем большую энергию он несет, тем лучше отношение
сигнал/шум, но тем ниже и предельная скорость передачи. Раньше
каждому двоичному разряду соответствовал импульс или перепад в
кодовой последовательности. Сегодня перепад возникает лишь при
смене последовательности нулей на последовательность единиц или
наоборот. Цифровой метод передачи имеет целый ряд преимуществ
перед аналоговым:
• Высокую надежность. Если шум ниже входного порога, его вли-
яние не ощущается, кроме того, всегда возможна повторная по-
сылка кода.
• Отсутствие зависимости от источника информации (звук, изоб-
ражение или цифровые данные).
• Возможность шифрования, что повышает безопасность передачи.
Независимость от времени. Можно передавать не тогда, когда
информация возникла, а когда готов канал.
На рисунке 2.2.1В представлена уже не последовательность им-
пульсов, а последовательность переходов из одного состояния в дру-
гое. При этом уровень +V соответствует логической <1>,а -V —
логическому <0>. Переключение из состояния <0> в состояние <1>
и наоборот (бод) уже не соответствует передаче одного бита.
Домен кода i---- Домен бита
1 I
♦ [А]
I j : и : ! I : i : : , I ; I i : I ! ' I ' ! ! < -! I . •
. 4 4 I “ r i M- --Hi » < - -i -Г I- — -; ‘ ; : ' :
। I । । । i I ' ‘ । i । 1 ' । ! i i ' 1 i i i •
101 111 010 100110 011
I li i: |: j I h । i ч n H | Двоичное
i ; Il I ; i 1 I ! 1 i И ппспгтяппсимс ГБ1
Реальная форма
сигнала в линии [В]
Рис. 2.2.1 Передача цифровых чодов по передающей линии
24
Гпава 2
На практике число нулей или единиц следующих подряд не
лимитировано. По этой причине на принимающей стороне при этом
рано или поздно возникает проблема синхронизации временных шкал
передатчика и приемника. Для решения этой проблемы существует
два метода передачи данных: синхронный и асинхронный. Асинх-
ронный метод используется для относительно низкоскоростных ка-
налов передачи и автономного оборудования. Синхронный метод
применяется в скоростных каналах и базируется на пересылке син-
хронизующего тактового сигнала по отдельному каналу или путем
совмещения его с передаваемыми данными. При наличии синхрони-
зации приемника и передатчика можно допустить более длинные
последовательности нулей или единиц, что способствует повыше-
нию пропускной способности. На рис. 2.2.2 показана схема канала,
использующая технику импульсно-кодовой модуляции. Импульс-
но-кодовая модуляция (ИКМ) была предложена в 30-ые годы 20-го
века, но реализована лишь в 1962 году.
Шаг квантования в АЦП должен быть много меньше диапазона
вариации входного сигнала. Число уровней квантования п выбира-
ется из соображений минимизации искажений сигнала и повыше-
ния уровня S/N. При разумных предположениях (биполярность
сигнала (+V -V), однородность распределения уровня сигнала в ра-
бочем диапазоне, ошибка квантования не более S/2, где S шаг кван-
тования, и т.д.) [S/N]dB = 10 log10(22n) = 6n (N — шум квантования
при этом равен S2/12). Это означает, что при 2П уровнях квантова-
ния и при условии, что входной сигнал может варьироваться во
всем рабочем диапазоне АЦП, отношение сигнал-шум (S/N), свя-
занное с самим процессом квантования, будет равно 6п (при п=8
это составит 48 дБ). Отсюда следует известное значение относи-
тельного расстояния между уровнями квантования, равное 6 дБ.
Звуковой сигнал может иметь динамический диапазон 40 дБ, что
Аналоговый сигнал ln(t)
Цифровой сигнал
Рис. 2,2.2. Система коммуникаций с использованием
кодово-импульсной модуляции [РСМ]
Преобразование, кодировка и передача информации
25
создает определенные проблемы, которые преодолеваются путем пря-
мого и обратного логарифмического преобразования (см. рис. 2.4.1).
Типичный кадр данных в асинхронном канале начинается со
стартового бита, за которым следует 8 битов данных. Завершается
такой кадр одним или двумя стоп-битами. Стартовый бит имеет
полярность противоположную пассивному состоянию линии и пере-
водит приемник в активное состояние. Пример передачи такого кадра
показан на рис. 2.2.3.
Одним из способов обеспечения надежной синхронизации явля-
ется применение в приемнике частоты, например, в 8 раз больше
частоты следования данных. При этом стробирование данных мо-
жет производиться примерно в середине сигнала бита (см. рис. 2.2.4).
Начальный и стоп-биты на каждый байт данных снижают про-
пускную способность канала и по этой причине используются толь-
ко для низких скоростей обмена. Увеличение же длины блока дан-
ных приводит к ужесточению требований к точности синхрониза-
ции. При использовании синхронного метода передачи необходимы
Бит Л
старта Стоп-биты
Биты данных .▼ .
▼
01010011011
’ Пассивное состояние линии
। ! ; 1 1 Тактовая частота
Рис. 2.2.3. Пример передачи кадра в асинхронном режиме
I
ч 4 тика 8 тиков__ ___8 тиков
Тактовая частота приемника
Импульсы стробирования
Рис. 2.2.4. Схема синхронизации и стробирования с 8-кратной
тактовой частотой приемника
I?-.
26
Гпава 2
специальные меры для выделения кадра в общем потоке данных.
Для решения этой задачи используется специальная сигнатура. Если
такая последовательность встретится внутри кадра, она видоизме-
няется путем ввода в нее двоичных нулей (bit stuffing). Синхрон-
ный приемник нуждается в синхронизирующем сигнале, передавае-
мом передатчиком. Обычно это реализуется путем введения опре-
деленного вида кодирования сигнала, например, биполярного
кодирования. В этом случае используется три уровня сигнала: +V
соответствует логической 1; -V - логическому нулю, а 0 вольт логи-
ческому нулю или единице. Пример такого типа кодирования пока-
зан на рис. 2.2.5. ,
Другой разновидностью такого рода кодирования является ман-
честерский код. В этой схеме логической единице и нулю соответ-
ствует не уровни напряжения, а перепады. Так логической единице
поставлен в соответствие переход с низкого уровня на высокий, а
логическому нулю - с высокого на низкий (схема NRZ - Non-Return-
to-Zero). Пример представления сигнала с использованием манчес-
терского кода показан на рис. 2.2.6.
Манчестерский код достаточно неэффективно использует про-
пускную способность канала. Оба описанные выше кода требуют
удвоения полосы для передачи данных. Этого можно избежать, ис-
пользуя схему цифровой фазировки DPLL -Digital Phase Locked Loop.
Эта схема предполагает применение кодирования NRZI (Non-Return-
Zero-Inverted). Здесь сигнал сначала кодируется с использованием
кода NRZ и только затем последовательность преобразуется в NRZI.
В процессе такого преобразования логический нуль из NRZ вызыва-
I Исходные данные
Биполярное кодирование
I________________________________________
Данные Rx
Рис. г.2.5. Пример биполярного кодирования сигнала
(схема RZ - Retum-to-Zero}
Преобразование, кодировка и передача информации
27
Исходные данные
Тактовые сигналы Тх
Манчестерскйй код
Тактовые сигналы Rx
Данные Rx
Рис. 2.2.6. Кодирование сигнала с использованием
манчестерского кода.
ет определенную модификацию исходного кода, в то время как ло-
гическая единица не приводит ни к каким вариациям. Здесь созда-
ются условия, при которых количество переходов 0/1 и 1/0 в еди-
ницу времени достаточно велико, чтобы обеспечить надежную синх-
ронизацию. Схема NRZI кодирования с использованием DPLL
проиллюстрирована на рис. 2.2.7.
Симметричная скрученная пара проводов с волновым сопротив-
лением 120 Ом обеспечивает пропускную способность 2048 Мбит/с
(система кодирования HDB3, длина проводов ~100м), а 100 Ом —
1544 Мбит/с (амплитуда сигналов 3 в, система кодирования B8ZS).
Номинальное значение перепада обычно составляет 750 мВ.
Наиболее простая схема передача данных путем представления
<0> и <1> с помощью двух уровней напряжения не применяется из-
Исходные данные
NRZ
NRZI
Рис. 2.2.7. NRZI-кодирование
28
Гпава 2
за того, что линия обычно используется для подачи на оконечное
(терминальное) оборудование. Проблема может быть решена, если
<0> характеризуется 0 вольт (приращение над постоянным уров-
нем), а <1> попеременно сигналами положительной и отрицательной
полярности (AMI — Alternate Mark Inversion). Такая схема создает
проблему синхронизации, когда подряд следует большое число ну-
лей. Необходимо, чтобы было достаточное число переходов 0->1 и 1-
>0 в единицу времени. Существует также схема ADI (Alternate Digit
Inversion), где инверсия полярности производится для каждого из
передаваемых двоичных разрядов. Но эта схема менее эффективна.
По этой причине система кодирования AMI была модифициро-
вана в HDB3 (High Density Bipolar 3). Цифра 3 указывает на мак-
симально возможное число последовательных нулей в кодовой пос-
ледовательности. AMI требует, чтобы <1> передавались поперемен-
но сигналами противоположной полярности, так последовательность
11011 должна быть передана как +-0+-. HDB3 заменяет любую
группу из 4 нулей последовательностью из 3 нулей, за которой сле-
дует нарушение последовательности отображения единиц. Таким
образом, последовательность 11000001 будет отображена как +-000-
0+ (возможен инверсный вариант, когда символы + заменяются на
— и наоборот). Дальнейшего улучшения балансировки сигнала мож-
но достичь, если заменить код, содержащий 4 нуля подряд, последо-
вательностью B00V (В — обычный биполярный сигнал, V — нару-
шение последовательности). В США используют схему кодировки
B8ZS (Bipolar with 8 Zeros Substitution), где 8 нулей кодируются
как 00B0VB0V. В 1986 году ANSI принял решение о введение схе-
мы кодирования 2B1Q (2 Binary into 1 Quaternary). При этой схеме
каждая пара бит преобразуется в четверичные элементы +3 +1 -1 -
3. Код синхронизации (SW — Synchronization Word) при этом со-
держит 9 четверичных элементов, повторяющихся каждые 1.5 мс:
+3 +3 -3 -3 -3 +3 -3 +3 +3 (+3 соответствует +2.5 В)
В Германии используется схема кодировки 4ВЗТ (4 двоичных
разряда кодируются в 3 циклических кода).
Двоичная информация передается блоками, обычно называемы-
ми кадрами (или пакетами). В рамках системы 2B1Q для передачи
144 Кбит/с требуется частота модуляции не менее 72 Кбод. На
практике для передачи кадров и выполнения функций управления
необходимо создать дополнительные виртуальные каналы. Это до-
водит требуемую частоту модуляции до 80 Кбод. Сводные данные
по наиболее популярным схемам кодирования приведены в табли-
це 2.2.1.
Преобразование, кодировка и передача информации
29
Таблица 2.2.1.
Название метода Расшифровка Описание
1В2В Один бит исходной последовательности кодируется комбинацией из 2 бит половинной длительности
B3ZS B6ZS B8ZS Bipolar with 3/6/8 Zero Substitution Биполярный код с заменой 000/000000/000Q0000 на последовательности 00V/0VB0VB/000VB0VB (или B0V для B3ZS)
HDB2 (/3) High Density Bipolar code of order 2 (/3) Биполярный код высокой плотности второго (третьего) порядка. Эквивалентен коду с возвратом к нулю (RZ) и с инверсией для логических 1. Последовательность ООО (соответственно 0000) заменяется на 00V или B0V (соответственно 000V или B00V). Число В сигналов между V-сигналами всегда нечетно. В результате возникает трехуровневый код.
CMI Coded Mark Inversion Двухуровневый двоичный код (класса 1В2В) без возвращения к нулю. Используется инверсия полярности для каждой логической 1 (единице ставится в соответствие 11 или 00), а для каждого логического нуля вводится смена полярности в середине интервала.
Кадр содержит 120 пар бит (quats), что соответствует 240 бит,
8 кадров образуют мультикадр. Первый пакет мультикадра выде-
ляется путем посылки Inverted Synchronization Word (ISW). В конце
каждого кадра всегда присутствуют специальные биты, которые слу-
жат для целей управления (бит активации, бит холодного старта,
биты состояния питания, биты управления синхронизацией и т.д.).
Структура кадра выглядит следующим образом:
Биты quats Канал Биты quats Канал
1-18 1-9 ISW (кадр 1) 127-134 64-67 В
SW (кадры 2-8) 135-142 68-71 В
19-26 10-13 В-канал 1 143-144 72 D
27-34 14-17 В-канал 2 145-152 73-76 В
34-36 18 D-канал 153-160 77-80 в
37-44 19-22 В 161-162 81 D
45-52 23-26 В 163-170 82-85 В
53-54 27 D 171-178 86-89 В
55-62 28-31 В 179-180 90 D
63-70 32-35 В 181-188 91-94 В
71-72 36 D 189-196 95-98 В
73-80 37-40 В 197-198 99 D
81-88 41-44 В 199-206 100-103 В
89-90 45 D 204-214 104-107 В
99-106 50-53 В 215-216 108 D
107-108 54 D 217-224 109-112 В
109-116 55-58 В 225-232 113-116 В
117-124 59-62 В 233-234 117 D
125-126 63 D 235-240 118-120 Контроль и управление
30
Гпава 2
Кадры следуют каждые 1.5мс. Здесь нужно следить за тем, что-
бы не было корреляции между сигналами, следующими в противо-
положных направлениях. Для этого используются скрэмблеры.
В традиционной телефонной сети для соединения с требуемым
клиентом используются аппаратные коммутаторы. Если коммута-
тор имеет N входов и N выходов, то одновременно можно реализо-
вать не более N связей. Реально это число всегда меньше и клиент
слышит в трубке «короткие гудки» сигнала «занято». В случае
комбинирования традиционного коммутатора с М-канальными муль-
типлексорами пакетов по времени можно осуществить до M*N свя-
зей одновременно. При этом становится возможным объединить
нескольких клиентов так, что они все одновременно могут говорить
друг с другом. Схема такого переключателя каналов показана на
рис. 2.2.8.
Координатный
коммутатор
24/30 канальные
мультиплексоры
по времени
24/30 канальные
мультиплексоры
по времени
Рис. 2.2.8. Схема переключателя каналов
с мультиплексированием по времени.
Кружочки на пересечениях линий представляют собой ключи,
замыкая которые можно соединить i-й входной канал с j-м выход-
ным. На каждой линии может быть только один замкнутый ключ.
Такая схема коммутации называется TST (Time-Space-Time). Имен-
но она преобладает сегодня при построении сетей ISDN. Магист-
ральные каналы ISDN строятся в соответствии со стандартом Т1.
Преобразование, кодировка и передача информации
31
2.3. Цифровые каналы Т1 и Е1
Системы (каналы) Т1 имеют пропускную способность, соответ-
ствующую 24 аналоговым каналам с полосой 0-3.3 Кгц (американ-
ская версия стандарта). Частота стробирования равна 8 Кгц, что
соответствует передаче 8000 кадров в сек. Посла каждых 6000 фу-
тов коаксиального кабеля ставятся системы регенерации сигналов.
Все 24 канала мультиплексируются на общий коаксиальный ка-
бель, предварительно производится PCM-преобразование сигналов.
24 канала по 8 бит (при 8-битном АЦП) дает 192 бита на кадр.
Один дополнительный (193-ий) бит используется для целей синх-
ронизации (F). Таким образом, частота бит в канале Т1 составляет
193*8000=1,554 Мбит/с (это стандарт США, его европейский аналог
— Е1 имеет 30 каналов и пропускную способность 2048 Кбит/с).
Это соответствует частоте кадров 667/с. Каждый восьмой бит (млад-
ший) байта (временного домена на рис. 2.3.1) используется для
целей управления, что несколько снижает пропускную способность.
В ISDN каналы 1,544 и 2,048 Мбит/с, форматы которых здесь опи-
саны, называются первичными.
8-битовые PCM-блоки генерируются каждые 125мксек (8000/с).
Структура данных при передаче со скоростью 1,544 Мбит/с пред-
ставлена ниже (ISDN 2*B+D):
Структура кадра при скорости 1,544 Мбит/с
Таймдомен 1 В
F| 112|з|4| 5|6|7|8
---- 1 кадр = 193 бита = 125 мксек
Таймдомен2 В
1 |г|зkIs Islzls I I I I I I I I
Таймдомен24 D
1I2 |зк Ыб kla
Структура кадра при скорости 2,048 Мбит/с
«------------------ 1 кадр = 256 бит = 125 мксек ----------►
ТаймдоменО Таймдомен 1 Таймдомен 31
ijalskt d б| da ilglsklslelyls I I I I I I I I I 1 {г|зkIslelzle
Synch
Рис. 2.3.1. Структура кадров для американского [вверху)
и европейского [внизу] стандартов передачи данных
Скорости передачи 1,544 (кодирование B8ZS) и 2,048 Мбит/с
(HDB3) называются первичными скоростями. Кадры структуриро-
32
Гпава 2
ваны так, что временные домены (тайм домен на рис. 2.3.1) для
передачи данных по каналам В1 и В2 чередуются. Каждый 6-ой
кадр используется для сигнальных целей. Количество временных
доменов в кадре определяет число телефонных разговоров, которые
могут осуществляться одновременно. Для американского стандарта
это число равно 24, а для европейского 30 (в последнем случае
учтено то, что часть доменов используется в служебных целях).
Все современные коммутаторы управляются центральным про-
цессором. Такие коммутаторы обычно называются коммутаторами,
управляемыми встроенной памятью (SPC — Stored Program Controlled
exchanges).
Преобразование, кодировка и передача информации
33
2.4. Методы преобразования и
передачи звуковых сигналов
На физическом уровне в ISDN используется кодово-импульсная
модуляция с частотой стробирования 8 Кгц (что превосходит огра-
ничение Найквиста = 2*З.ЗкГц, где З.ЗкГц — полоса пропускания
канала для традиционной телефонной сети). Эмпирически установ-
лено, что для удовлетворительного воспроизведения речи, достаточ-
но 4096 уровней квантования сигнала (12 разрядов АЦП). Такое
разрешение диктуется большим динамическим диапазоном сиг-
налов. По этой причине возникает возможность преобразования
12-битных кодов в 8-битные, что формирует информационный по-
ток в 64 Кбит/с. Для этого используется логарифмическое преобра-
зование. Природа позаботилась о человеке, снабдив его логарифми-
ческой чувствительностью слуха, в противном случае у нас в мозгу
перегорали бы предохранители при близком выстреле или грозо-
вом разряде. Логарифмическое преобразование наталкивается на
определенные трудности при низких значениях входного сигнала,
ведь логарифм для значений меньше 1 имеет отрицательную ве-
личину. Функция же преобразования должна пройти через нуль.
В США две логарифмические кривые смещаются в направлении оси
ординат (вертикальная ось), в результате получается функция вида:
у ~ log(l +цх) (так называемая ц-зависимость [p-law])
В Европе используется функция преобразования вида:
у - Ах в области значений х вблизи нуля и
у - 1 4- log (Ах) при «больших» значениях х (А-зависимость
[A-law], см. рис. 2.4.1)
Для дальнейшего упрощения процесса преобразования реаль-
ные кривые апроксимируются последовательностью отрезков пря-
мых, наклоны которых каждый раз меняется вдвое. На практике
функция табулируется (рекомендация G.711) и отличия ц - и А-
функций пренебрежимо малы. Но следует учитывать, что при реа-
лизации практической связи между Европой и Америкой, например
телефонной, необходим ц/А-конвертор.
Для кодирования используется симметричный код, у которого
первый бит характеризует полярность сигнала.
Дальнейшим усовершенствованием схемы РСМ является адап-
тивный дифференциальный метод кодово-импульсной модуляции
(Рис. 2.4.2). Здесь преобразуется в код не уровень сигнала в мо-
2 Зак. Ns 3430 Семенов
34
Гпава 2
Рис. 2.4.1. Иллюстрация функций'преобразования сигналов
мент времени t., а разница уровней в моменты t. и ti4. Так как
обычно сигнал меняется плавно, что типично для человеческой речи,
можно заметно сократить необходимое число разрядов АЦП. Прин-
ципиальное отличие между РСМ и ADPCM (1984 год) заключает-
ся в использовании адаптивного АЦП и дифференциального коди-
рования, соответственно. Адаптивный АЦП отличается от стандар-
тного PCM-преобразователя тем, что в любой момент времени уровни
квантования расположены однородно (а не логарифмически), при-
чем шаг квантования меняется в зависимости от уровня сигнала.
Применение адаптивного метода базируется на том, что в человечес-
кой речи последовательные уровни сигнала не являются независи-
мыми. Поэтому, преобразуя и передавая лишь разницу между пред-
сказанием и реальным значением, можно заметно снизить загрузку
линии, а также требования к широкополосности канала. Следует
иметь в виду, что метод не лишен серьезных недостатков: уровень
шумов, связанный с квантованием сигнала, выше; при резких изме-
нениях уровня сигнала, превышающих диапазон АЦП, возможны
серьезные искажения.
Рис. 2.4.2. Адаптивный преобразователь голоса в код
Преобразование, кодировка и, передача информации
35
Расширение диапазона преобразования достигается умножени-
ем шага квантования на величину несколько больше (или меньше)
единицы.
При дифференциальном преобразовании на вход кодировщика
подается не сам сигнал, а разница между текущим значением сиг-
нала и предыдущим (рис. 2.4.3).
Блок прогнозирования является адаптивным фильтром, кото-
рый использует предшествующий код для оценки последующего стро-
бирования. На вход кодировщика поступает сигнал, пропорциональ-
ный разнице между входным сигналом и предсказанием. Чем точ-
нее предсказание, тем меньше бит нужно, чтобы с нужной точностью
закодировать эту разницу. Характер человеческой речи позволяет
заметно снизить требования к каналу при использовании адаптив-
ного дифференциального преобразователя.
Для компактных музыкальных дисков (CD) характерна полоса
50Гц — 20 Кгц, обычная оке речь соответствует полосе 50 Гц — 7 Кгц.
Только звуки типа Ф или С имеют заметные составляющие в высо-
кочастотной части звукового спектра. Для высококачественной пере-
дачи речи используется субдиапазонный ADPCM-преобразователь
(Adaptive Differential Pulse Code Modulation). В нем звук сначала
стробируется с частотой 16 Кгц, производится преобразование в циф-
ровой код с разрешением не менее 14 бит, а затем подается на квад-
ратурный зеркальный фильтр (QMF), который разделяет сигнал на
два субдиапазона (50Гц-4кГц и 4кГц-7кГц). Диапазоны этих фильт-
ров перекрываются в области 4кГц. Нижнему диапазону ставится в
соответствие 6 бит (48кбит/с), а верхнему 2 бита (16 Кбит/с). Выхо-
ды этих фильтров мультиплексируются, формируя 64 Кбит/с-поток.
На CD используется 16-битное кодирование с частотой строби-
рования 44,1 Кгц, что создает информационный поток 705 Кбит/с.
Для стерео сигнала этот поток может удвоиться. Практически это
Рис. 2.4.3. ADPCM-преобразователь голоса в код для 32кбит/с
2*
36
Гпава 2
не так — сигналы в стереоканалах сильно коррелированны, и мож-
но кодировать и передавать лишь их разницу, на практике высоко-
частотные сигналы каналов суммируются, для различия каналов
передается код их относительной интенсивности. Исследования по-
казывают, что для акустического восприятия тонкие спектральные
детали важны лишь в окрестности 2 Кгц. Для передачи звуковой
информации с учетом этих факторов был разработан стандарт
Musicam (Masking pattern Universal Sub-band Integrated Coding And
Multiplexing),который согласуется c ISO MPEG (Moving Picture Expert
Group; стандарт ISO 11172). Musicam развивает идеологию деления
звукового диапазона на субдиапазоны, здесь 20кГц делится на 32
равных интервалов. Логарифмическая чувствительность человечес-
кого уха и эффект маскирования позволяет уменьшить число разря-
дов кодирования. Эффект маскирования связан с тем, что в присут-
ствии больших звуковых амплитуд человеческое ухо нечувствитель-
но к малым амплитудам близких частот. Причем чем ближе частота
к частоте маскирующего сигнала, тем сильнее этот эффект (см. рис.
2.4.4). Сплошной линией на рисунке показана нормальная зависи-
мость порога чувствительности уха, а пунктиром — зависимость по-
рога чувствительности в присутствии 500-герцного тона с амплиту-
дой в 110 дБ. у
При разбиении на субдиапазоны можно оценить эффект маски-
рования и передавать только ту часть информации, которая этому
эффекту не подвержена. При этом уровень ошибок квантования
следует держать лишь ниже порога маскирования, что также сни-
Рис. 2.4.4.Изменение порога чувствительности человеческого уха
под влиянием эффекта маскирования.
Преобразование, кодировка и передача информации
37
жает информационный поток. Для стробирования высококачествен-
ных звуковых сигналов используются частоты 32, 44,1 или 48 Кгц.
Стандартом предусмотрено три уровня кодирования звука, отлича-
ющиеся по сложности и качеству. На первом уровне производится
разбивка на 32 диапазона, определение диапазонных коэффициен-
тов и формирование кадров, несущих по 384 результатов стробиро-
вания. Уровень 2 формирует кадры с 1152 результатами стробиро-
вания и дополнительными данными. Уровень 3 допускает динами-
ческое разбиение на субдиапазоны и уплотнение данных с
использованием кодов Хафмана. Любой декодер способен работать
на своем и более низком уровне.
Для улучшения качества передачи низких частот в дополнение
к суб-диапазонным фильтрам, используется быстрое Фурье-преоб-
разование (FFT). Результирующая частота бит при передаче звуко-
вых данных оказывается не постоянной. Практическое измерение
показывает, что частота редко превышает 110 Кбит/с, применение
128кбит/с делает качество воспроизведения неотличимым ют CD.
Ограничение скорости на уровне 64 Кбит/с вносит лишь незначи-
тельные искажения.
Ниже в таблицах представлены данные по скоростям передачи
аудиоданных по традиционным цифровым и отповолоконным ка-
налам (см. также раздел 3.5.6).
Таблица 2.4.1. Скорости передачи данных по цифровым каналам
Линия Быстродействие, Мбит/с Число аудио каналов
DS-0 0,064 1
Т-1 1,544 24
Т-1С 3,152 48
Т-2 6,312 96
Т-3 44,736 672
Таблица 2.4.2. Скорости передачи данных по оптическим каналам
Линия ОС-х Быстродействие, Мбит/с Число аудио каналов STM-x
1 51,84 672 -
3 155,52 2016 1
9 466,56 6048 3
12 622.08 8064 4
24 ” 1244,16 16128 8
48 2488,32 32256 16
96 4976,64 64512 32
192 9953,28 129024 64
38
Гпава 2
Еще одним методом, нацеленным на повышение эффективности
преобразования входного аналогового сигнала в код, является дель-
та-модуляция.
2.4.1. Передача голоса по каналам Интернет
Несколько лет назад появился новый вид услуг в Интернет -
голосовая связь (IP-Phone, VocalTec). Сегодня имеется 30 милли-
онов абонентов, регулярно пользующихся IP-phone и его аналогами,
ожидается до 200 миллионов до конца текущего десятилетия, каче-
ство передачи постепенно приближается к уровню цифровой теле-
фонии.
Среди пользователей есть те, для кого это лишь возможность
общения, как для радиолюбителей; но все больше людей использует
IP-phone для деловых контактов или даже как объект бизнеса.
Существуют два алгоритма сжатия звуковой информации, исполь-
зуемых для IP-телефонных переговоров: GSM (Global System for Mobile
' communications, ftp.cs.tu-berlin.de/pub/local/kbs/tubmik/gsm), кото-
рая обеспечивает коэффициент сжатия 5, и алгоритм DSP-группы
(True Speech) с коэффициентом сжатия данных 18 (работает при
частотах 7.7 Кбит/с). Добавление аппаратных средств сжатия ин-
формации позволяет сократить необходимую полосу до 6.72 Кбит/с.
Преобразование, кодировка и передача информации
39
Таблица 2.4ЛЛ.
Пропускная способность, [бит/с] Частота стробирования, [1/с]
9600 4000
14400 6000
19200 8000
28800 11000
Потеря 2-5% пакетов остается незамеченной, 20% оставляет разго-
вор понятным. В таблице 2.4.4.1 представлена зависимость необ-
ходимой полосы телекоммуникационного канала от частоты стро-
бирования звукового сигнала, которая определяет качество воспро-
изведения.
Для подключения к сети IP-phone необходима мультимедийная
карта, микрофон, динамики (или наушники), 8 Мбайт оперативной
памяти, доступ к Интернет и соответствующее программное обеспе-
чение. Качество передачи звука зависит от загруженности 1Р-кана-
ла. В качестве транспорта используется протокол UDP. Для обеспе-
чения высокого качества звука нужна гарантированная ширина IP-
канала, ведь задержанные сверх меры UDP-дейтограммы теряются
безвозвратно, что и приводит к искажениям. Внедрение протоколов,
гарантирующих определенную ширину канала сделают IP-phone зна-
чительно более привлекательным. Многие компании уже предлага-
ют такое оборудование и программы. Программы и описания этого
вида услуг можно найти по адресам:
ftp://cs.ucl.ac.uk/mice/videoconference
http://www.pulver.com/netwatch
http://www.planeteers.com
http: / /www. ne wparadigm. com
http:/ /www.vocaltec.com
http: / /www. it elco. com
http:/ / www. quart erdeck. com
В последнее время технология передачи звука по каналам Ин-
тернет стала широко использоваться для трансляции новостей и
музыки. При этом обеспечивается вполне удовлетворительное ка-
чество даже при передаче стерео программ. В э?ом случае имеется
возможность применить более эффективное сжатие информации и
протоколы типа RTP и RTCP. Задержка при передаче в этом слу-
чае никакого значения не имеет, а качество доставки гарантирова-
но. Современные системы IP-телефонии снабжены гибкой системой
40
Гпава 2
буферов, позволяющих использовать для передачи паузы, когда один
из партнеров молчит.
В настоящее время имеется практически полный набор техноло-
гий, чтобы создать электронную книгу. Такая книга будет представ-
лять собой систему размером с ноутбук, снабженное устройством
для чтения CD-дисков. Текст книги вместе с иллюстрациями и не-
обходимыми командными последовательностями записывается на
CD. При этом в перспективе можно рассматривать возможность
того, что такое устройство будет читать «книгу» вслух (вывод на
наушники). В настоящее время имеется достаточно большое коли-
чество книг, записанных на CD. Это, прежде всего, энциклопедичес-
кие, словари, альбомы музеев, библия и многие другие. Преимуще-
ство такой формы книги уже сегодня ощутимо - вы можете исполь-
зовать современные поисковые средства, чтобы найти нужный раздел
или какую-то конкретную информацию. По мере развития этой тех-
нологии и интеграции ее с сетями можно будет осуществлять поиск
не только по данной книге, но и по книгам или журналам, ссылки
на которые в данной книге содержатся, что может быть особенно
полезно при первичном знакомстве с какой-то проблемой. Этому
способствует и появление электронных аналогов практически всех
научных журналов и многих гаЭет. Я здесь не говорю о компактно-
сти, а в перспективе, и долговечности такой формы записи информа-
ции. При звуковом воспроизведении читатель сможет выбирать, го-
лосом какого актера или актеров будет читаться данная книга.
Разумеется, для этого не потребуется начитывать данный текст са-
мим актерам. Достаточно иметь запись характерных особенностей
голоса и интонаций конкретного голоса, а процессор сам при гене-
рации звука будет использовать голосовые особенности того или
иного человека. Немного фантазии и можно будет представить, как
ЭВМ будет воспроизводить текст в виде фильма, который она сгене-
рировала по выданному ей тексту (ведь сгенерирован же на ЭВМ
корабль «Титаник» и море, по которому он плывет). Аналогичные
услуги смогут оказываться и через сеть Интернет. Наибольшие труд-
ности вызовет реализация качественного воспроизведения. Програм-
мы способные преобразовывать символьный текст в голос уже су-
ществуют. Проблема распознавания индивидуального голоса давно
решена в охранных системах. Осталось научиться использовать ре-
зультаты такого айализа при воспроизведении.
Активно внедряются многие новые стандарты и протоколы для
обеспечения передачи звука по IP-каналам, проведения видеоконфе-
ренций и управления в реальном масштабе времени. К таким про-
токолам относятся RTP (Real Time Protocol, RFC-1889, -1890), RTCP
Преобразование, кодировка и передача информации
47
(Real-Time Control Protocol), который является дополнением RTP, и
RSVP (Resource ReSerVation Protocol, см. разделы проектов IETF
nic.nordu.net, ftp.isi.edu, munnari.oz.au и ds.internic.net или
ftp.ietf.org/intemet-drafts/draft-ietf-rsvp-spec-16.txt), служащий для
обеспечения своевременной доставки данных при работе в реаль-
ном времени. Протокол RTP способен работать помимо UDP/IP в
сетях CLNP, ATM и IPX. Он обеспечивает детектирование потерь,
идентификацию содержимого, синхронизацию и безопасность (дос-
туп по шифрованному паролю, см. RFC-1423). Проблема синхрони-
зации при передаче звука особенно важна, так как даже для ло-
кальных сетей время доставки пакетов может варьироваться в весьма
широких пределах из-за используемого алгоритма доступа (напри-
мер, CSMA/CD), а это приводит к искажениям при воспроизведе-
нии. Протоколы RTP и RTCP позволяют одновременное голосовое
общение неограниченного числа людей в рамках сети Интернет.
Протокол же RSVP (или его аналог) в случае внедрения гарантиру-
ет качество связи (разумеется, при достаточной широкополосности
канала) за счет повышения приоритета пакетов реального времени.
Следует иметь в виду, что голосовое общение, хотя и весьма привле-
кательно, не является единственной и да5ке главной целью разра-
ботчиков. По мере совершенствования протоколов Интернет сдела-
ет возможным управление в реальном масштабе времени довольно
сложными удаленными объектами.
В таблице 2.4.1.3 представлены характеристики аудио-кодеков,
которые можно использовать в 1Р-телефонии.
При внедрении IP-телефонии желательно, чтобы сетевая инфра-
структура обеспечивала:
• Время задержки в одну сторону менее 100 мсек.
• Вероятность потери пакета менее 5%.
• Оборудование должно соответствовать требованиям H.323v2,
а механизмы безопасности — стандарту Н.235.
Таблица 2.4.1.3. Характеристики аудио-кодеков
Кодек Выходная скорость кодека
G.711 64 Кбит/с
G.723.1 5,3 или 6,4 Кбит/с
G.722 48, 56 или 64 Кбит/с
G.726 16, 24,32, 40 Кбит/с
G.728 16 Кбит/с
G.728/G.729a 8 Кбит/с
42
Гпава 2
• Наличие функции привратника в маршрутизаторе/шлюзе (бло-
кирует установку новых телефонных соединений при отсутствии
необходимых ресурсов).
Одна из возможных реализаций IP-телефонии показана на рис.
2.4.3.1. (MVD -Multiflex Voice/WAN модуль, включаемый в марш-
рутизатор, например, CISCO-3662).
Рис. 2.4.1.1, Пример реализации IP-телефонной системы
Связь может осуществляться как с традиционной старой анало-
говой телефонной сетью, так и с ISDN. Телефонные аппараты могут
подключаться непосредственно к интерфейсу маршрутизатора, к се-
тевой рабочей станции или к специальному сетевому адаптеру. При
построении подобной системы следует непременно реализовать фун-
кцию Н.323 (Gatekeeper — привратник). Это позволит блокировать
бесконтрольное и неэффективное использование ресурсов сети (см.
также раздел 2.9).
Преобразование, кодировка и передача информации
43
2.5. Методы преобразования
и передачи изображения
Передача изображения представляет собой наиболее тяжелую
проблему, так как человеческий глаз с информационной точки зре-
ния несравненно совершеннее уха.
В 1902 году Артур Корн (Германия) запатентовал систему фото-
электрического сканирования изображения, а в 1910 году заработа-
ла первая международная факсимильная связь Берлин-Париж-Лон-
дон. До 60-х годов этого века рынок факсимильной аппаратуры
был ограничен.
В 1968 году CCITT разработала рекомендации по факсимильно-
му оборудованию, которое было способно передавать страницу за 6
минут при разрешении 3.85 линий на мм. Позднее в 1976 году
аналоговая факсимильная техника была улучшена. Это позволило
сократить время передачи страницы до 3 минут. В 1980 году разра-
ботан стандарт для цифровых факс-машин (группа 3), здесь уже
предусматривается сжатие информации, что позволяет сократить
время передачи страницы до 1 мин при скорости передачи 4800
бит/с. Следует иметь в виду, что сжатие информации в сочетании с
ошибками пересылки может приводить к неузнаваемости изображе-
ния локальному или полному. По этой причине число линий ска-
нирования, которые используются при обработке изображения, с це-
лью сжатия может варьироваться (1-4) и определяется в результате
Диалога между отправителем и получателем, а передача каждой
скан-линии завершается довольно длинным кодом, предназначен-
ным для надежного распознавания завершения строки сканирова-
ния, а также коррекции ошибок. Факсимильное оборудование труп-
44
Гпава 2
пы 3 может и не обеспечивать сжатия передаваемых (принимае-
мых) данных. В 1984 году разработаны требования к факс-аппара-
там группы 4. Система базируется на двухмерной системе кодиро-
вания изображения (MMR — Modified Modified Reed).
Факсимильное оборудование поделено на 4 группы. Первая груп-
па практически совпадает с традиционным фототелеграфным обору-
дованием (6 минут на страницу при разрешении 3.85 линий на мил-
лиметр). Динамической вариации кодовой таблицы не предусмотре-
но. При этом для кодирования очередной линии сканирования
используются результаты, полученные для предшествующей линии.
Следует учитывать, что зона сканирования факс-машины больше раз-
мера изображения и всегда имеются пустые строки и поля, что предо-
ставляет дополнительные возможности для сжатия передаваемой
информации. Существует три режима кодирования: вертикальный,
горизонтальный и проходной. Последний режим реализуется, когда
позиция в эталонной строке а2 находится слева от Ы (см. рис. 2.5.1;
вертикальному и горизонтальному режиму соответствует нижняя часть
рисунка). При «вертикальном» режиме кодирования (а2 справа от
Ы и |blal|<= 3) позиция Ы кодируется относительно позиции al.
Относительное положение blal может принимать одно из семи зна-
чений V(0), VR(1), Vr(2), Vr(3), Vl(1), Vl(2) и Vl(3) (cm. табл. 2.5.1):
Индексы R и L указывают на то, что bl находится справа или слева
по отношению к al, а число в скобках обозначает расстояние blal.
Если используется «горизонтальный» режим кодирования (а2 спра-
ва от bl и |blal|>3), длины ЬОЬ1 и Ь1Ь2 отображаются с помощью
кодовой комбинации H+M(b0bl)+M(blb2). Н представляет собой код
001, взятый из двумерной кодовой таблицы. М(Ь0Ь1) и М(Ь1Ь2) яв-
Рис. 2.5.1. Режимы кодирования:
проходной; вертикальный: горизонтальный
Преобразование, кодировка и передача информации 45
Таблица 2.5.1. Кодирование элементов изображения
Режим кодирования Элементы, подлежащие кодированию Обозначение Код
Проход а1а2 P 0001
Горизонтальный Ь0Ь1,Ь1Ь2 H 001+M(b0bl)+M(blb2)
Вертикальный Ы под al blal=O bl справа от al blal=l blal=2 blal=3 bl слева от al blal=l blal=2 blal=3 V(0) Vr(D Vr(2) • Vr(3) VL(1) Vl(2) Vl(3). 1 on 000011 0000011 010 000010 0000010 0000001xxx
ляются кодовыми словами, которые характеризуют длину и цвет суб-
строк ЬОЫ и Ь1Ь2 соответственно.
Факс-оборудование группы 4 может поддерживать так называе-
мый расширенный режим, когда часть рабочего поля кодируется без
использования алгоритмов уплотнения информации (как правило,
это участки, где попытка сжать либо ничего не дает, либо даже
приводит к увеличению объема передаваемых данных). Оборудова-
ние этой группа использует на канальном уровне процедуры HDLC
LAPB. Рекомендуемой полосой пропускания канала, к которому под-
ключается такое оборудование, является 64 Кбит/с. >
Перед началом передачи терминалы должны обменяться своими
идентификаторами (TID — Terminal IDentification). В последнее время
появились факс-аппараты, которые печатают изображение на обыч-
ную бумагу с разрешением 300-400 точек на дюйм. Такая схема
удобна, но имеет некоторые недостатки. Эти аппараты дороги, пе-
чать может начаться не ранее, чем будет передана вся страница;
передающий аппарат может иметь более низкое разрешение, нужно
уметь адаптироваться к любому разрешению, что приводит к тому,
что скорость печати изображения при низком разрешении остается
столь же низкой, как и при высокой.
В 1970 году в Бритиш Телеком были разработаны основные
принципы еще одного вида передачи графической информации —
телетекста, первые опыты по его внедрению относятся к 1979 году.
Стандарт на мозаичное представление символов был принят СЕРТ в
1983 году. Каждому символу ставится в соответствие код длиной в
7-8 бит. На экране такой символ отображается с помощью специ-
ального знакового генератора, использующего таблицу.
46
Гпава 2
Полному экрану видео текста, содержащему 24 строки по 40
символов, соответствует 960 байт, для передачи которых по комму-
тируемой телефонной сети требуется 6,4 секунды. D-канал ISDN
может пропустить эту информацию за 1 секунду, а В-канал быстрее
за 0,1 сек. Телетекст позволяет более эффективно использовать
каналы связи и не налагает чрезмерных требований на устройства
отображения.
Известно, что для корректной передачи цвета требуется 16 мил-
лионов оттенков (8 бит на каждую из трех цветовых компонент).
Таким образом, для описания картинки на экране, содержащей 575
линий по 720 пикселей, требуется 1,240 Мбайта. Для передачи та-
кой информации по В-каналу ISDN, если не используется сжатие,
потребуется около 2,5 минут. Эта цифра помогает понять актуаль-
ность проблемы сжатия графической информации. При передаче
чисто текстовой информации электронная почта имеет по этой при-
чине абсолютное преимущество перед факсом. В перспективе можно
ожидать внедрения сжатия информации при передаче почтовых со-
общений с последующей дешифровкой данных принимающей сторо-
ной. Первым шагом на этом пути является внедрение системы
MIME. Такое усовершенствование электронной почты сделает ее
еще более грозным конкурентом факс-машин. Ведь передача гра-
фических образов уже не является монополией факсимильных сис-
тем, а возможность шифрования почтовых сообщений (например, в
PGP) делает электронную почту более противостоящей перехвату.
Таким образом, чтобы выдержать конкуренцию со стороны элект-
ронной почты разработчикам факс-систем нужно упорно работать.
Стандарты для представления и передачи изображения разраба-
тывает Joint Photographic Expert Group (JPEG). Для сжатия гра-
фической информации в настоящее время используется дискретное
косинусное двухмерное преобразование (DCT — Discrete Cosine
Transform), которое дает субъективно наилучший результат и опи-
сывается уравнением:
F(u,v) = (1/4)С(и)С(р)]Г cos Тcos ^2у *
л-0 у=0 L * h [ . 16
[2.5.1]
где v — горизонтальная координата графического блока, и — верти-
кальная, х — вертикальная координата внутри блока, а. у — гори-
зонтальная координата внутри блока, С(и), С(и) = 1/ ^2 для u>v =
0 и С(и), C(v) = 1 в противном случае. Два члена в квадратных
скобках являются ядрами преобразования, показанными ниже на
рис. 2.5.2, а р(х,у) представляет собой пиксельные данные блока
реального рисунка. Начало координат в обоих случаях в верхнем
1
Преобразование, кодировка и передача информации
47
левом углу. Процесс кодирования сводится к разбиению изображе-
ния на блоки 8*8 пикселей и выполнению процедуры двухмерного
DCT для каждого из этих блоков. Полученные коэффициенты пре-
образования дискретизируются. 64 числа, характеризующие уровень
сигнала, превращаются в 64 коэффициента преобразования (ампли-
туды пространственных частот), которые хорошо поддадутся проце-
дуре сжатия. Дискретизатор округляет коэффициенты, эта процеду-
ра вносит некоторые ошибки, йо обратное преобразование на прини-
мающей стороне за счет усреднения частично устраняет вносимые
искажения. На практике дискретизатор реализует несколько более
сложный алгоритм.
Интуитивно метод DCT базируется на выявлении того, насколь-
ко вышестоящий блок отличается от нижестоящего. Для реально-
го представления (сжатия) коэффициентов преобразования здесь
также используются коды Хафмана.
DCT обеспечивает сжатие на уровне 0.5-1.0 бит/пиксель при
хорошем качестве изображения. Сжатие требует времени, а макси-
мально приемлемым временем задержки при пересылке изображе-
ния является 5 секунд. На рис. 2.5.3 приведена качественная оцен-
ка четкости и соответствия оригиналу изображения в зависимости
от величины сжатия (DCT). Если использовать скорость обмена
64 Кбит/с, то степени сжатия 0,01 бита на пиксель будет соответ-
ствовать время передачи изображения 0,04 секунды, а сжатию 10 —
время передачи 40 сек.
Отображение графического образа может выполняться последо-
вательно (примерно так, как мы читаем текст: слева направо и
"□аиншиишт"
"«Л'ЛММ
[в>о»мми
‘SSRSSSMM
§53388® 888 38
= S 8 й Si & » S9
Рис. 2.5.2. Графическое представление двухмерного
преобразования по формуле [2.5.7J
48
Гпава 2
сверху вниз) или с использованием прогрессивного кодирования
(сначала передается вся картинка с низким разрешением, затем
последовательно четкость изображения доводится до максималь-
ной). Последний метод весьма удобен для систем WWW, где, про-
смотрев изображение низкого разрешения, можно отменить переда-
чу данных улучшающих четкость и тем самым сэкономить время.
Хорошо распознаваемое изображение получается при сжатии по-
рядка 0,1 бита на пиксель.
Проблема сжатия и передачи движущегося изображения еще
сложнее. Алгоритм кодирования такого изображения описан в ре-
комендациях CCITT Н.261 и предполагает, что скорость передачи
при этом лежит в интервале 40кбит/с — 2Мбит/с. Следует иметь в
виду, что зидео телефония и видеоконференции требуют синхронной
передачи звука и изображения (стандарт Н.221, например 46,4 Кбит/с
для видео и 16 Кбит/с для звука). Нормальный формат телевиде-
ния имеет 625 и 525 строк развертки и частоту кадров 25-30 в
секунду. Цветное телевидение использует сигналы R (red), G (green)
и В (blue), причем яркость луча (Y) определяется соотношением:
Y = 0.30R + 0.59G + 0.11В (при отображении белого цвета). Инфор-
мация о цветах определяется формулами: Св = В — Y и CR = R — Y.
Зная величины Y, Св и CR, можно восстановить значения R, G и В.
Сжатие информации в бит/пиксель
Рис. 2.5.3. Качество ОСТ-изображения для различных значений
сжатия информации (картинка имеет разрешение 512*512 пикселей;
заполненные квадратики соответствуют цветному изображению,
а незаполненные — черно-белому)
Преобразование, кодировка и передача информации
49
При сжатии цветного изображения учитывается тот факт, что чело-
веческий глаз извлекает большую часть информации из контуров
предметов, а не из цветных деталей. Например, в рекомендации CCIR
601 предлагается использовать полосу 13.5 Мгц для кодирования
Y и только по 6.75 Мгц для Св и CR Такая схема требует 216
Мбит/с, что в 3375 раза превышает возможности стандартного
64кбит/с В-канала ISDN. Приемлемыми решениями могут быть:
а. снижение числа строк до 288 (формат 625 строк) для отображе-
ния яркости;
Ь. использование максимально возможного сжатия графических
данных;
с. повышение пропускной способности канала. Для разрешение
по горизонтали вполне достаточно 3 Мгц. Рекомендация 601
требует 720 пикселей для яркости и 360 для каждой из состав-
ляющих цветов. В настоящее время используется стандарт CIF
(Common Intermediate Format). Для некоторых приложений ре-
комендовано вдвое более низкое разрешение по каждой из осей
(Quarter CIF). PCM-кодирование CIF с 8 битами на пиксель
требует 352х288х(1+1/4+1/4)х29.97х8 = 36.5 Мбит/с.
Проблема сжатия информации была, есть и всегда будет акту-
альной. При известных современных методах, чем больше эффек-
тивность сжатия — больше задержка (наилучший результат можно
получить, используя сжатие всего фильма, чем кадра или тем более
строки). В каждом конкретном случае выбирается то или иное
компромиссное решение. При работе в реальном масштабе времени,
где в процессе обмена участвует человек задержки более секунды
вызывают раздражение, и приходится ограничиваться сравнительно
скромными коэффициентами сжатия.
При пересылке движущегося изображения производится сравне-
ние текущего кадра с предшествующим. Если кадры идентичны,
никакого информационного обмена не происходит. Если кадры от-
личаются лишь смещением какого-то объекта, выявляются грани-
цы этого объекта, направление и величина вектора его перемеще-
ния. Так как использование индивидуальных векторов перемеще-
ния для каждого пикселя слишком расточительно, используется
общий вектор для блока пикселей 16*16 по яркости и для соответ-
ствующего блока 8*8 по цвету. Точность задания вектора переме-
щения обычно лежит в пределах 1/2 пикселя (стандарт MPEG-2).
Только эта информация и передается по каналу связи. Выявление
Движущихся объектов осуществляется путем вычитания изображе-
ния двух последовательных кадров. Если бы передавалась всегда
только разница кадров, происходило бы накопление ошибок. Кроме
50
Гпава 2
того, как кодер, так и декодер содержат прямой и обратный DCT-
преобразователь. Если комбинация прямого и обратного DCT-npe-
образования не приводит к получению исходного объекта, то такого
рода эффекты могут заметно усилиться. Для исключения этого вре-
мя от времени производится передача непосредственно видеосигна-
ла. Практически преобразователь изображения представляет чудо
современной технологии, которое даст работу еще не одному поко-
лению математиков и инженеров
Нисколько не проще система передачи и мультиплексирования
потока видео данных, который содержит помимо обычной информа-
ции описания формы движущихся объектов, векторы перемещения,
коэффициенты дискретизации и многое другое. Схема передачи гра-
фической информации имеет 4-х уровневую, иерархическую струк-
туру. Передача каждого кадра изображения начинается с 20-битно-
го кода PSC (Picture Start Code, эта сигнатура позволяет выделить
начало кадра изображения в общем потоке), далее следует 5-бито-
вый код TR (Temporal Reference, временная метка, которая позволя-
ет поместить соответствующую часть изображения в правильную
точку экрана). Изображение пересылается частями, имеется 4 уров-
ня: кадр, группа блоков GoB (Group of Blocks), макроблоки (MB) и
просто блоки.
Ядро всей структуры составляет процедура передачи кадра (внут-
ренний слой, существуют еще слои GoB, МВ и блока, см. рис. 2.5.4,
2.5.5, 2.5.6).
Поле PTYPE содержит 6 бит, которые характеризуют формат изоб-
ражения (используется ли формат CIF или QCIF). Однобитное поле
PEI указывает на то, следует ли далее 8-битное поле PSPARE (пред-
назначено на будущее). Если РЕ1=0, начинается цикл передачи GoB.
Группа блоков составляет одну двенадцатую картинки CIF или одну
треть QCIF. GoB описывает Y (яркость), 176 пикселей для каждой из
48 строк и соответствующие 88*24 элементов для Св и CR.
Слой изображения
Рис. 2.5.4. Схема передачи кадра изображения
Преобразование, кодировка и передача информации
51
Рис. 2.5.5. Блок-схема кодирования и передачи изображения
GBSC — (Group of Blocks Start Code) представляет собой 16-
разрядное слово, за которым следует 4 бита номера GoB (GN — GoB
number). GN указывает, какой части изображения соответствует дан-
ный GoB. Поле GQUANT имеет 5 бит и указывает на номер преоб-
разователя (одного из 31 дискретизаторов), который используется
данным GoB. Смысл GEI идентичен PEI. GEI и GSPARE позволяют
сформировать структуру данных, идентичную той, что используется
на уровне кадра.
Формат пересылки МВ сложнее (см. [17]). Каждый GoB делится
на 33 макроблока (МВ), каждый из которых соответствует 16 стро-
кам по 16 пикселей Y (четыре блока 8*8) и Св и CR. Каждый макро-
блок начинается с его адреса MBA (Macroblock Address), имеющего
переменную длину и определяющего положение макроблока в GoB.
Макроблоки не передаются, если данная часть изображения не
изменилась. За MBA следует код переменной длины MTYPE, харак-
теризующий формат макроблока (применен ли метод подвижного
вектора MVD и т.д.) и последующую информацию. СВР (Coded
Block Pattern) представляет собой кодовое слово переменной длины,
которое несет в себе информацию о том, какой из шести блоков
преобразования (8*8) содержит коэффициенты (слой блоков). СВР
нужно не для всех типов макроблоков. Каждый блок завершается
флагом EoB (End of Block).
Сама природа алгоритма кодирования и передачи графических
данных такова, что число бит передаваемых в единицу времени за-
Рис. 2.5.6. Размещение блоков в макроблоках
52
Гпава 2
висит от характера изображения. Чем динамичнее изменяется кар-
тинка, тем больше поток данных. Для выравнивания потока дан-
ных широко используется буферизация. Буферизация в свою оче-
редь порождает дополнительные задержки, которые в случае видео-
конференций или видео-телефонии не должны превышать нескольких
сотен миллисекунд.
Так как при передаче изображения широко используются коды
переменной длины, она крайне уязвима для любых искажений. В
случае ошибки будет испорчена вся информация вплоть до следую-
щего стартового кода GoB. Из-за рекурсивности алгоритма форми-
рования картинки, искажения будут оставаться на экране довольно
долго. Использование векторов перемещения может привести к дрей-
фу искажений по экрану и расширению их области. Для того чтобы
уменьшить последствия искажений, в передаваемый информацион-
ный поток включаются коды коррекции ошибок ВСН (511,493;
Forward Error Correction Code), которые позволяют исправить лю-
бые две ошибки или кластер, содержащий до 6 ошибок в блоке из
511 бит (см. рис. 2.5.7). Алгоритм работает в широком диапазоне
скоростей передачи информации. Для реализации коррекции оши-
бок в поток двоичных данных включается 8 пакетов, каждый из
которых включает в себя 1 кадровый бит, 1 бит индикатор заполне-
ния, 492 бита кодированных данных и 18 бит четности. Поле Fi
(индикатор заполнения) может равняться нулю, тогда последующие
492 бита не являются графической информацией и могут игнориро-
ваться. Алгоритм предназначен для работы в динамическом диа-
пазоне частот 40:1.
Во время переговоров или в ходе видеоконференции может воз-
никнуть необходимость отобразить текст, выделить на экране ка-
кой-то объект, послать факс и т.д. Для решенная таких задач можно
Рис. 2.5.7. Схема передачи данных с коррекцией ошибок
Преобразование, кодировка и передача информации
53
использовать D-канал, но это не оптимально, так как он имеет свои
специфические функции. Поэтому более привлекательным представ-
ляется создание специального протокола, работающего в рамках В-
канала (Н.221). Для этих целей используется младший бит каждо-
го из октетов, что позволяет создать канал с пропускной способнос-
тью 8 Кбит/с. этот сервисный канал использует кадры по 80 бит.
Первые 8 бит служат для целей синхронизации (FAS — Frame
Alignment Signal) и выполняют следующие функции:
• выделение начала кадра (исключение имитации этого в ин-
формационном потоке);
• выделение начала блока кадров (опционно до 16 кадров);
• выполнение функций счетчика в многокадровых блоках (по
модулю 16), может использоваться в многоточечных соединениях;
• нумерация соединений;
• CRC-контроль (опционно);
• “A-бит” для определения кадр/мультикадр/синхронизация при
пересылке в противоположном направлении (А=0 — передача, см.
также структуру кадров ISDN);
При работе с каналами на 384, 1536 и 1920 Кбит/с сервисный
канал использует тайм-слот 1. Следующие 8 бит имеют название
BAS (Bit Allocation Signal) и выполняют следующие функции:
• код, характеризующий возможности канала (узко/широко по-
лосная передача звука, различные видео параметры, тип шифрова-
ния и т.д.);
• коды команд, определяющие значения передаваемых кадров;
• esc-noc ледовател ьности.
Очевидно, что BAS-коды (Н.242) должны быть надежно защи-
щены от ошибок. Для этой цели они пересылаются с использовани-
ем кодов, допускающих коррекцию ошибок. При работе оба прием-
ника непрерывно ищут разделительный код кадров. Когда он обна-
ружен, бит А для выходного канала делается равным нулю. Только
после получения А=0 терминал может быть уверен в том, что уда-
ленный терминал правильно воспринял код BAS. Работа с кодами
В AS описана в документе Н.242. При установлении режима обме-
на терминалы обмениваются командами BAS. Команда действительна
Для последующих двух кадров, следовательно, при частоте кадров
100 Гц, изменения режима могут производиться каждые 20 мс.
Многоточечный вызов может рассматриваться как несколько
связей между терминалами и бриджом MCU (Multipoint Control
Unit) по схеме точка-точка. Простой MTU передает на каждый из
'терминалов смешанный аудио-сигнал от остальных терминалов.
Каждый терминал осуществляет широковещательную передачу для
54
Гпава 2
остальных терминалов, участвующих в обмене. При видео обмене
на терминал выводится только одна картинка. Дополнительную
информацию по данной тематике можно найти в рекомендациях
Н.231, Н242 и Н.243.
Для передачи нормального телевизионного изображения необ-
ходимо 364 Кбит/с (4x64 Кбит/с). Интеграция телевидения с сетя-
ми передачи данных, появление видеотелефона и широкое внедре-
ние видеоконференций становится велением времени. Требования к
каждому из этих видов услуг варьируется значительно в зависимос-
ти от приложения. Например, ставшие обычными телевизионные
мосты требуют высокого качества передачи изображения и звука. А
в некоторых дорогостоящих отраслях науки, где международное со-
трудничество стало неизбежным, важным является передача стати-
ческих изображений (чертежи, схемы, описания алгоритмов, и т.д.) с
высоким (иногда более высоким, чем в телевидении) разрешением.
Здесь важно передать звук с приемлемым качеством (но заметно
хуже, чем на ТВ) и обеспечить синхронное перемещение маркера
мыши по экрану в ходе обсуждения переданного документа. Эконо-
мия только на авиа билетах (не говоря о командировочных и вре-
мени экспертов) способна перекрыть издержки по оплате канала
для видеоконференции. В этом режиме приемлемым может счи-
таться один кадр в 1-4 секунды.
Рисунок известного французского художника Клода Серрэ из
книги «Черный юмор и люди в белом» (см. начало раздела) может
служить иллюстрацией того, к чему может привести использование
протокола TCP при передаче изображения в реальном масштабе
времени. Предположим, что в процессе передачи изображения носа
пакеты были повреждены, тогда спустя некоторое время, определяе-
мое размером окна (TCP), будет проведена повторная их передача.
Тем временем переданные ранее пакеты будут использованы для
построения изображения, а часть картинки, содержавшаяся в паке-
тах, посланных вместо поврежденных, будет отображена совсем не
там, где это следует. Реально из-за повреждения пакетов возможны
в этой версии и более тяжелые искажения изображения. Именно
это является причиной использования UDP для передачи видео и
аудио информации при видео и аудио конференциях (еще лучшего
результата можно достичь, использую протокол RTP). Протокол
UDP не требует подтверждения и повторной передачи при ошибке
доставки. Поврежденные пакеты вызовут искажения изображения
(или звука) лишь локально.
Ситуация меняется в случае посылки изображения или звуково-
го послания по электронной почте. Здесь в случае повторной пере-
Преобразование, кодировка и передача информации
55
дачи пакетов в конечном итоге будет сформирован файл, уже не
содержащий ошибок. Такое решение приемлемо всякий раз, когда
большая задержка появления изображения или звука не играет
никакой роли.
Стандарт MPEG
Стандарт MPEG-2 является усовершенствованием MPEG-1 и
базируется на схеме шифрования с потерями и передачи без потерь.
Кодирование в MPEG-2 идентично используемому в MPEG-1 (I- Р-
и В-кадры; В-кадры не используются). Здесь применено двойное
косинусное преобразование с числом коэффициентов 10*10 (против
8*8 в MPEG-1). MPEG-2 предназначен для широковещательного
телевидения (включая прямое спутниковое — DBS) и для записи на
CD-ROM и поддерживает четыре разных стандартов разрешения:
352*240 (низкое), 720*480 (базовое), 1440*1152 (высокое-1440) и
1920*1080 (высокое). Низкое разрешение служит для обеспечения
совместимости с MPEG-1. Базовое разрешение ориентировано на
работу со стандартом NTSC. Последние два стандарта относятся к
телевидению высокого разрешения (HDTV). Помимо этого MPEG-2
поддерживает 5 профайлов для различных прикладных областей.
Основной профайл ориентирован на общие приложения с базовым
разрешением. Простой профайл сходен с основным профайлом, но
не работает с В-кадрами, чтобы облегчить процедуры кодирования/
декодирования. Остальные профайлы служат для обеспечения мас-
штабируемости и работы с HDTV, они отличаются цветовым разре-
шением и форматами информационных потоков. Скорость переда-
чи данных для каждой комбинации разрешения и профайла раз-
лична и лежит в диапазоне от 3 до 100 Мбит/с. Для обычного ТВ
характерна скорость 3-4 Мбит/с. В таблице 2.5.2 представлены
размеры кадров в битах для MPEG-1 и MPEG-2.
Мультиплексирование аудио- и видеоданных в MPEG-2 показа-
но на рис. 2.5.8. На выходе пакетизатора мы имеем элементарные
потоки пакетов (PES — Packetized Elementary Stream), содержащих
около 30 полей, включая длину, идентификаторы потоков, времен-
ные метки, контрольные суммы и т.д. В MPEG-2 формируется два
Таблица 2.5.2. Размеры кадров MPEG-1 и MPEG-2
Тип кадра
I Р В Средний
MPEG-l (1,15 Мбит/с) 150,000 50,000 20,000 38,000
^j№G-2 (4 Мбит/с) 400,000 200,000 80,000 130,000
56
Гпава 2
комплексных потока, программный поток (PS) длинных пакетов
переменной длины сходный с MPEG-1, содержащий видео и аудио
данные и имеющий общую временную шкалу, и транспортный по-
ток (TS) пакетов постоянной длины (188 байт) без общей времен-
ной шкалы. В последнем случае минимизируется влияние потерь
пакетов в процессе транспортировки. Предусмотрено выделение в
потоке составляющих разной степени важности (например, DCT-
коэффициентов и обычных графических данных).
Выходной
сигнал
MPEG-1
Рис. 2.5.8. Мультиплексирование аудио и видео данных
в MPEG-1 и MPEG-2 [внизу]
Преобразование аналогового сигнала в цифровую последователь-
ность осуществляется в MPEG-2 с помощью кодеков, создавая пер-
вичный поток в 140 Мбит/с, который затем преобразуется для пе-
редачи через стандартные каналы 1,5 и 15 Мбит/с (например, для
прямого широковещательного, спутникового телевидения). В соот-
ветствии со стандартом сжатия данных Н.320 можно обеспечить
передачу видео + аудио по каналу 56 Кбит/с с низким разрешени-
ем и частотой 1 кадр/сек. Смотри раздел «Видеоконференции по
каналам ISDN и Интернет».
Преобразование, кодировка и передача информации
57
Интерактивное телевидение
В последнее время благодаря широкому внедрению цифрового
телевидения и новых стандартов передачи изображения (MPEG-2)
открылись возможности для «телевидения по требованию» (инте-
рактивного телевидения) — системы, где клиент может самостоя-
тельно и индивидуально формировать ТВ-программу. Первые опы-
ты такого рода относятся к 1995 году. Такие системы базируются
на существующих сетях кабельного телевидения. Но развитие оп-
товолоконных технологий позволяют ожидать полной интеграции
кабельного цифрового телевидения и информационных сетей Ин-
тернет. Общая схема такой системы показана на рис. 2.5.9.
Базовый мультимедийный сервер может обслуживать отдель-
ный район города. В пределах квартала размещается промежуточ-
ный центр, где размещается локальный буферный сервер, записыва-
ющий фрагменты программ, заказанные локальными клиентами.
Только новостийные и некоторые спортивные программы передают-
ся в реальном масштабе времени, все фильмы берутся из локальной
фильмотеки или предварительно записываются в накопитель из
центрального мультимедиа-сервера. Транспортной средой здесь мо-
жет стать ATM, SDH или Fibre Channel. Оптическое волокно дохо-
дит до квартального сервера или даже до дома клиента. В этом
случае по имеющимся каналам может передаваться не только про-
грамма телевидения и осуществляться телефонные переговоры, но
выполняться полное информационное обслуживание. Сюда может
включаться, помимо заказа ТВ-программ, подписка на газеты, заказ
билетов на транспорт или в театр, получение прогноза погоды и
данных о состоянии дорог, доступ к базам данных, включая библио-
Рис. 2.5.9. Схема реализации интерактивного телевидения
58
Гпава 2
теки и фонотеки и многое другое. Особый интерес представляет
возможность практически полного вытеснения традиционных га-
зет. Клиент сможет получать только интересующие его статьи из
любых газет (и только их и оплачивать). Если какая-то статья
представляет интерес, и он захочет почитать ее позднее в машине
или на даче, ее можно распечатать на принтере, подключенном к его
телевизору-терминалу. Цены на цветные принтеры в настоящее время
спустились почти до 100 долларов, таким образом, нужная копия
уже сейчас дешевле стоимости газеты. Экономия на бумаге и сред-
ствах доставки очевидны, да и необходимость в типографиях отпа-
дет, ведь даже книги можно будет получить непосредственно дома,
хотя привлекательность данной услуги и не вполне очевидна —
хорошо сброшюрованная и переплетенная книга будет привлека-
тельным объектом еще долго (прогноз относительно будущих книг
смотри в разделе «Заключение»). Массовое внедрение таких техно-
логий будет стимулировать падение цен на соответствующие про-
цессоры и принтеры. Интерактивная схема подключения телевизо-
ра-терминала сделает возможным многие новые виды развлечений,
а также выполнение многих покупок, не выходя из дома. Традици-
онной почте подписала отсроченный приговор почта электронная,
но появление интерактивных широкополосных средств завершит
многовековую историю почты (да и телеграфа). Ей будет оставлена
доставка товаров, билетов и документов. Побочным продуктом про-
гресса в данной области станет общедоступный видеотелефон.
В жилье клиента будет входить оптоволоконный кабель, завер-
шающийся интерфейсной коробкой с разъемами для подключения
телефона, телевизора и ЭВМ. Даже современные ограниченные ско-
рости передачи позволяют решить стоящие проблемы. Во-первых,
люди не смотрят телевизор круглые сутки, это позволяет ночью или
в рабочее время, когда клиент на службе, произвести передачу нуж-
ных фрагментов ТВ-программы на локальный сервер. Во-вторых,
популярность фильмов и программ не однородна, что также снижа-
ет требование на широкополосность. Известно, что наиболее попу-
лярный фильм запрашивается примерно в К раз чаще, чем фильм,
занимающий к-ое место в списке популярности (эмпирический за-
кон Ципфа (Zipf), выведенный из статистики контор по прокату
видеокассет). Это означает, что из предлагаемого списка будут выб-
раны не все фильмы, а наиболее популярные фрагменты программ
можно передавать по схеме MBONE, минимизируя загрузку каналов
(смотри также описание протокола PIM). Способствовать решению
данной проблемы будет и появление CD с емкостью 4 Гбайта. Но
проблем здесь остается немало, так трудно себе представить, что все
Преобразование, кодировка и передача информации 59
клиенты захотят смотреть один и тот же фильм в одно время.
Решение подобной задачи потребует очень большого объема буфер-
ной памяти и ощутимо поднимет требования к широкополосности
канала. «Синхронизовать» клиентов можно будет дифференциаци-
ей оплаты для разных временных интервалов, и группированием
клиентов, заказавших близкие времена начала демонстрации филь-
мов. Но, несмотря на все эти ухищрения, локальные серверы долж-
ны будут иметь сложную иерархическую систему буферной памяти,
базирующейся на разных принципах работы (CD, магнитная лента,
дисковая память и даже RAM).
Практическая реализация фантастической схемы, предложенной
в предыдущем абзаце, уже осуществляется в США и Канаде. Здесь
есть немало проблем, например, нужен дешевый широкополосный
кабельный модем. Предстоит написать огромное число различных
сервисных программ, но все базовые технологии уже существуют.
60
Гпава 2
2.6. Общие методы сжатия информации
Полагаю, что все читатели знакомы с архиваторами файлов, ве-
роятно, многие из вас неоднократно ими пользовались. Целью архи-
вации файлов является экономия места на жестком или гибком
магнитном диске. Кому не приходилось время от времени задумы-
ваться над тем, войдет ли данный файл на дискету? Существует
большое число программ-архиваторов, имеются и специальные сис-
темные программные средства типа Stacker или Doublespace и т.д.,
решающие эту проблему.
Первые теоретические разработки в области сжатия информа-
ции относятся к концу 40-х годов. В конце семидесятых появились
работы Шеннона, Фано и Хафмана. К этому времени относится и
создание алгоритма FGK (Faller, Gallager, Knuth), где используется
идея «сродства», а получатель и отправитель динамически меняют
дерево кодов (смотри, например, http://www.ics.uci.edu/~dan/plus/
DC-Sec4.html).
Пропускная способность каналов связи более дорогостоящий'
ресурс, чем дисковое пространство, по этой причине сжатие данных’
до или во время их передачи еще более актуально. Здесь целью
сжатия информации является экономия пропускной способности и
в конечном итоге ее увеличение. Все известные алгоритмы сжатия^
сводятся к шифрованию входной информации, а принимающая сто-1
рона выполняет дешифровку принятых данных.
Преобразование, кодировка и передача информации 61
Существуют методы, которые предполагают некоторые потери
исходных данных, другие алгоритмы позволяют преобразовать ин-
формацию без потерь. Сжатие с потерями используется при переда-
че звуковой или графической информации, при этом учитывается
несовершенство органов слуха и зрения, которые не замечают неко-
торого ухудшения качества, связанного с этими потерями. Более
детально эти методы рассмотрены в разделе «Преобразование, коди-
ровка и передача информации».
Сжатие информации без потерь осуществляется статистическим
кодированием или на основе предварительно созданного словаря.
Статистические алгоритмы (напр., схема кодирования Хафмана)
присваивают каждому входному символу определенный код. При
этом наиболее часто используемому символу присваивается наибо-
лее короткий код, а наиболее редкому — более длинный. Таблицы
кодирования создаются заранее и имеют ограниченный размер. Этот
алгоритм обеспечивает наибольшее быстродействие и наименьшие
задержки. Для получения высоких коэффициентов сжатия статис-
тический метод требует больших объемов памяти.
Альтернативой статистическому алгоритму является схема сжа-
тия, основанная на динамически изменяемом словаре (напр., алго-
ритмы Лемпеля-Зива). Данный метод предполагает замену потока
символов кодами, записанными в памяти в виде словаря (таблица
перекодировки). Соотношение между символами и кодами меняется
вместе с изменением данных. Таблицы кодирования периодически
меняются, что делает метод более гибким. Размер небольших слова-
рей лежит в пределах 2-32 килобайт, но более высоких коэффици-
ентов сжатия можно достичь при заметно больших словарях до 400
килобайт.
Реализация алгоритма возможна в двух режимах: непрерывном
и пакетном. Первый использует для создания и поддержки словаря
непрерывный поток символов. При этом возможен многопротоколь-
ный режим (например, TCP/IP и DECnet). Словари сжатия и де-
компрессии должны изменяться синхронно, а канал должен быть
достаточно надежен (напр., Х.25 или РРР), что гарантирует отсут-
ствие искажения словаря при повреждении или потере пакета. При
искажении одного из словарей оба ликвидируются и должны быть
созданы вновь.
Пакетный режим сжатия также использует поток символов для
создания и поддержания словаря, но поток здесь ограничен одним
пакетом и по этой причине синхронизация словарей ограничена
границами кадра. Для пакетного режима достаточно иметь словарь
объемом, порядка 4 Кбайт. Непрерывный режим обеспечивает луч-
62
Гпава 2
шие коэффициенты сжатия, но задержка получения информации
(сумма времен сжатия и декомпрессии) при этом больше, чем в
пакетном режиме.
При передаче пакетов иногда применяется сжатие заголовков,
например, алгоритм Ван Якобсона (RFC—1144). Этот алгоритм ис-
пользуется при скоростях передачи менее 64 Кбит/с. При этом
достижимо повышение пропускной способности на 50% для скоро-
сти передачи 4800 бит/с. Сжатие заголовков зависит от типа про-
токола. При передаче больших пакетов на сверх высоких скорос-
тях по региональным сетям используются специальные канальные
алгоритмы, независящие от рабочих протоколов. Канальные мето-
ды сжатия информации не могут использоваться для сетей, базиру-
ющихся на пакетной технологии, SMDS (Switched Multi-megabit
Data Service), ATM, X.25 и Frame Relay. Канальные методы сжатия
дают хорошие результаты при соединении по схеме точка-точка, а
при использовании маршрутизаторов возникают проблемы - ведь
нужно выполнять процедуры сжатия/декомпрессии в каждом мар-
шрутизаторе, что заметно увеличивает суммарное время доставки
информации. Возникает и проблема совместимости маршрутизато-
ров, которая может быть устранена процедурой идентификации при
у становлении виртуального канала.
^ Иногда для сжатия информации используют аппаратные сред-
ства. Такие устройства должны располагаться как со стороны пере-
датчика, так и со стороны приемника. Как правило, они дают хоро-
шие коэффициенты сжатия и приемлемые задержки, но они приме-
нимы лишь при соединениях точка-точка. Такие устройства могут
быть внешними или встроенными, появились и специальные интег-
ральные схемы, решающие задачи сжатия/декомпрессии. На прак-
тике задача может решаться как аппаратно, так и программно, воз-
можны и комбинированные решения.
Если при работе с пакетами заголовки оставлять неизмененны-
ми, а сжимать только информационные поля, ограничение на ис-
пользование стандартных маршрутизаторов может быть снято. Па-
кеты будут доставляться конечному адресату, и только там будет
выполняться процедура декомпрессии. Такая схема сжатия данных
приемлема для сетей X.25, SMDS, Frame Relay и ATM. Маршрутиза-
торы корпорации CISCO поддерживают практически все режимы
сжатия/декомпрессии информации, перечисленные выше.
Сжатие информации является актуальной задачей, как при ее
хранении, так и при пересылке. Сначала рассмотрим вариант алго-
ритма Зива-Лемпеля.
Преобразование, кодировка и передача информации
63
2.6.1. Алгоритм Зива-Лемпеля
Блочный алгоритм сжатия информации без потерь
Большинство алгоритмов сжатия базируется на последователь-
ной схеме сжатия Лемпеля-Зива (Lempel-Ziv, 1977). Этот алгоритм
используется, в частности, стандартной процедурой UNIX Compress.
Методики со статистическим моделированием могут обеспечить луч-
шее сжатие, но они заметно медленнее. Но существует алгоритм,
который совмещает в себе лучшие из черт названных выше. Этот
алгоритм не предусматривает последовательной обработки вход-
ных данных, а обрабатывает текст по-блочно. Здесь используется
обратимое преобразование блока данных к виду, который позволяет
эффективно сжать данные с помощью простых алгоритмов. Преоб-
разование имеет целью сгруппировать символы так, чтобы вероят-
ность появления последовательностей идентичных символов значи-
тельно возросла. Такой текст может быть легко сжат посредством
локально-адаптивных алгоритмов в сочетании с кодировкой Хаф-
мана и арифметической кодировкой.
Последовательность S, содержащая N символов ({S(0),.„ S(N—
1)}), подвергается N циклическим сдвигам (вращениям), лексиког-
рафической сортировке, а последний символ при каждом вращении
извлекается. Из этих символов формируется строка L, где i-ый сим-
вол является последним символом i-ro вращения. Кроме строки L
создается индекс I исходной строки S в упорядоченном списке вра-
щений. Существует эффективный алгоритм восстановления исход-
ной последовательности символов S на основе строки L и индекса
I. Процедура сортировки объединяет результаты вращений с иден-
тичными начальными символами. Предполагается, что символы в S
соответствуют алфавиту, содержащему К символов.
Для пояснения работы алгоритма возьмем последовательность
S= «abraca» (N=6), алфавит X = {‘а’/Ь’/с’/г’}.
1. Формируем матрицу из N*N элементов, чьи строки представ-
ляют собой результаты циклического сдвига (вращений) исходной
последовательности S, отсортированных лексикографически. По край-
ней мере, одна из строк М содержит исходную последовательность
S. Пусть I является индексом строки S. В приведенном примере
индекс 1=1, а матрица М имеет вид:
Номер строки
О aabrac
1 abraca
2 acaabr
3 bracaa
4 caabra
5 racaab
64
Гпава 2
2. Пусть строка L представляет собой последнюю колонку мат-
рицы М с символами L[O],...,L[N—1] (соответствуют M[O,N—
1],...,M[N—1,N—1]). Формируем строку последних символов вра-
щений. Окончательный результат характеризуется (L,I). В данном
примере L=’caraab’, I =1.
Процедура декомпрессии использует L и I. Целью этой процеду-
ры является получение исходной последовательности из N симво-
лов (S).
1. Сначала вычисляем первую колонку матрицы М (F). Это
делается путем сортировки символов строки L. Каждая колонка
исходной матрицы М представляет собой перестановку исходной
последовательности S. Таким образом, первая колонка F и L явля-
ются перестановками S. Так как строки в М упорядочены, разме-
щение символов в F также упорядочено. F=’aaabcr’.
2. Рассматриваем ряды матрицы М, которые начинаются с за-
данного символа ch. Строки матрицы М упорядочены лексикогра-
фически, поэтому строки, начинающиеся с ch упорядочены анало-
гичным образом. Определим матрицу М’, которая получается из
строк матрицы М путем циклического сдвига на один символ впра-
во. Для каждого i=0,..., N—1 и каждого j=O,...,N—1, *
M’[i,j] = m[i,(j—1) mod N]
В рассмотренном примере М и М’ имеют вид:
Строка М М’
0 aabrac caabra
1 abraca aabrac
2 acaabr racaab
3 Ьгасаа abraca
4 caabra acaabr
5 racaab bracaa
Подобно М каждая строка М’ является вращением S, и для
каждой строки М существует соответствующая строка М’. М’ по-
лучена из М так, что строки М’ упорядочены лексикографически,
начиная со второго символа. Таким образом, если мы рассмотрим
только те строки М’, которые начинаются с заданного символа ch,
они должны следовать упорядоченным образом с учетом второго
символа. Следовательно, для любого заданного символа ch, строки
М, которые начинаются с ch, появляются в том же порядке что и в
М’, начинающиеся с ch. В нашем примере это видно на примере^
строк, начинающихся с ‘а’. Строки^aabrac’, 4 abraca’ и ‘acaabr’ име-
ют номера 0, 1 и 2 в М и 1, 3, 4 в М’. i
Преобразование, кодировка и передача информации
65
Используя F и L, первые колонки М и М’ мы вычислим
вектор Т, который указывает на соответствие между строками двух
матриц, с учетом того, что для каждого j = 0,...,N—1 строки j М’
соответствуют строкам T[j] М.
Если L[j] является к-ым появлением ch в L, тогда T[j]=l, где
F[i] является к-ым появлением ch в F. Заметьте, что Т представля-
ет соответствие один в один между элементами F и элементами L, а
F[T[j]] = L[j]. В нашем примере Т равно: (4 0 5 1 2 3).
3. Теперь для каждого i = 0,..., N—1 символы L[i] и F[i]
являются соответственно последними и первыми символами строки
i матрицы М. Так как каждая строка является вращением S, сим-
вол L[i] является циклическим предшественником символа F[i] в
S. Из Т мы имеем F[T[j]] = L[j]. Подставляя i =T[j], мы получаем
символ L[T(j)], который циклически предшествует символу L[j] в S.
Индекс I указывает на строку М, где записана строка S. Таким
образом, последний символ S равен ЦТ]. Мы используем вектор Т
для получения предшественников каждого символа: для каждого
i = 0,...,N—1 S[N—1—i] = L[Tj[I]], где T°[x] =x, a Ti+l[x] = Т[Г[х].
Эта процедура позволяет восстановить первоначальную последова-
тельность символов S (‘abraca’).
Последовательность Т*[1] для i =0,...,N—1 не обязательно яв-
ляется перестановкой чисел 0,...,N—1. Если исходная последова-
тельность S является формой Zp для некоторой подстановки Z и
для некоторого р>1, тогда последовательность Т[1] для i = 0,...,N—
1 будет также формой Z’p для некоторой субпоследовательности Z’.
Таким образом, если S = 'cancan’, Z = ‘сап’ и р=2, последователь-
ность Т[1] для i = 0,...,N—1 будет [2,4,0,2,4,0].
Описанный выше алгоритм упорядочивает вращения исход-
ной последовательности символов S и формирует строку L, состоя-
щую из последних символов вращений. Для того чтобы понять,
почему такое упорядочение приводит к более эффективному сжа-
тию, рассмотрим воздействие на отдельную букву в обычном слове
английского текста.
Возьмем в качестве примера букву «t» в слове ‘the’ и предполо-
жим, что исходная последовательность содержит много таких слов.
Когда список вращений упорядочен, все вращения, начинающиеся с
Ье’> будут взаимно упорядочены. Один отрезок строки L будет со-
держать непропорционально большое число Ч’, перемешанных с дру-
гими символами, которые могут предшествовать ‘he’, такими как
пРобел, ‘s’, ‘Т’ и ‘S’.
Аналогичные аргументы могут быть использованы для всех
символов всех слов, таким образом, любая область строки L будет
3 Зак. Na 3430 Семенов • •
66
Гпава 2
содержать большое число некоторых символов. В результате веро-
ятность того, что символ *ch’ встретится в данной точке L, весьма
велика, если ch встречается вблизи этой точки L, и мала в противо-
положном случае. Это свойство способствует эффективной работе
локально адаптивных алгоритмов сжатия, где кодируется относи-
тельное положение идентичных символов. В случае применения к
строке L, такой кодировщик будет выдавать малые числа, которые
могут способствовать эффективной работе последующего кодирова-
ния, например, посредством алгоритма Хафмана.
Ссылки
1. J. Ziv and A. Lempel. A universal algorithm for sequential data
compression. IEEE Transactions on Information Theory. Vol. IT-
23, N.3, May 1977, pp. 337-343.
2. J. Ziv and A. Lempel. Compression of individual sequences via
variable rate coding. IEEE Transactions on Information Theory.
Vol. IT-24. N.5, September 1978, pp. 530-535.
3. M. Burrows and D.J. Wheeler. A block-sorting Lossless Data
Compression Algorithm. Digital Systems Research Center. SRC
report 124. May 10, 1994. |
4. J.L. Bently, D.D. Sleator, R.E. Tarjan, and V.K.Wei. A locally |
adaptive data compression algorithm. Communications of the ACM, I
Vol. 29, No. 4, April 1986, pp. 320-330 |
5. http://www.ics.uci.edu/~dan/pubs/DataCompression.html (Saleem
Bhatti)
6. http://www.speednet/~spenser/ted/DataCompression.html ;
7. http://www.iicm.edu/jucs_l_8/differencial_ziv_lempel_text/html/ f
paper.html
2.6.2. Метод Шеннона-Фано j
Данный метод выделяется своей простотой. Берутся исходные |
сообщения m(i) и их вероятности появления P(m(i)). Этот список |
делится на две группы с примерно равной интегральной вероятное- |
тью. Каждому сообщению из группы 1 присваивается 0 в качестве
первой цифры кода. Сообщениям из второй группы ставятся в со- |
ответствие коды, начинающиеся с 1. Каждая из этих групп делится |
на две аналогичным образом и добавляется еще одна цифра кода. |
Процесс продолжается до тех пор, пока не будут получены группы, |
содержащие лишь одно сообщение. Каждому сообщению в резуль- |
тате будет присвоен код х с длиной -lg(P(x)). Это справедливо, если j
возможно деление на подгруппы с совершенно равной суммарной |
вероятностью. Если же это невозможно, некоторые коды будут иметь
Преобразование, кодировка и передача информации
67
длину -lg(P(x))+l. Алгоритм Шеннона-Фано не гарантирует опти-
мального кодирования. Смотри http://www.ics.uci.edu/~dan/pubs/
DC-Sec3.html. Этим не ограничивается перечень алгоритмов сжа-
тия информации. Актуальность проблемы стимулирует изобрета-
тельность разработчиков.
2.6.3. Статический алгоритм Хафмана
Статический алгоритм Хафмана можно считать классическим
(см. также Р. Галлагер. Теория информации и надежная связь.
«Советское радио», Москва, 1974.) Определение статический в дан-
ном случае относится к используемым словарям. Смотри также
www.ics.ics.uci.edu/~dan/pubs/DataCompression.html (Debra А.
Lelewer и Daniel S. Hirschberg).
Пусть сообщения m(l),...,m(N) имеют вероятности Р(т(1)),...
P(m(N)) и пусть для определенности они упорядочены так, что Р(т(1))
> Р(т(2)) > ... > P(m(N)). Пусть Хр..., xN - совокупность двоичных
кодов и пусть 1р 12,..., 1N - длины этих кодов. Задачей алгоритма
является установление соответствия между m(i) и х.. Можно пока-
зать, что для любого ансамбля сообщений с полным числом более 2
существует двоичный код, в котором два наименее вероятных кода
xN и xN1 имеют одну и ту же длину и отличаются лишь последним
символом: xN имеет последний бит 1, a xN1 - 0. Редуцированный
ансамбль будет иметь свои два наименее вероятные сообщения сгруп-
пированными вместе. После этого можно получить новый редуци-
рованный ансамбль и так далее. Процедура может быть продолже-
на до тех пор, пока в очередном ансамбле не останется только два
сообщения. Процедура реализации алгоритма сводится к следую-
щему (см. рис. 2.6.3.1). Сначала группируются два наименее веро-
ятные сообщения, предпоследнему сообщению ставится в соответ-
ствие код с младшим битом, равным нулю, а последнему - код с
единичным младшим битом (на рисунке ш(4) и т(5)). Вероятнос-
ти этих двух сообщений складываются, после чего ищутся два наи-
Код Сообщение P(m(i))
00 т(1) . 0.3 1 _|0__..Q^5
01 т(2) 0.25 1 1 ° 1.0
10 т(3) 0.25 ' „ L0 .
110 т(4) 0.1 1 1 0 45
111 т(5) О.Г '1 0.2 1 °'45
S = 1.0
Рис. 2.6.3.1 Пример реализации алгоритма Хафмана
68
Гпава 2
менее вероятные сообщения во вновь полученном ансамбле (т(3) и
т'(4); Р(т'(4)) = Р(т(4)) + Р(т(5))).
На следующем шаге наименее вероятными сообщениями ока-
жутся т(1) и т(2). Кодовые слова на полученном дереве считыва-
ются справа налево. Алгоритм выдает оптимальный код (мини-
мальная избыточность).
При использовании кодирования по схеме Хафмана надо вместе
с закодированным текстом передать соответствующий алфавит. При
передаче больших фрагментов избыточность, сопряженная с этим
не может быть значительной.
Возможно применение стандартных алфавитов (кодовых таб-
лиц) для пересылки английского, русского, французского и т.д. тек-
стов, программных текстов на C++, Паскале и т.д. Кодирование при
этом не будет оптимальным, но исключается статистическая обра-
ботка пересылаемых фрагментов и отпадает необходимость пере-
сылки кодовых таблиц.
Преобразование, кодировка и передача информации
69
2.7. Обнаружение ошибок
Каналы передачи данных ненадежны, да и само оборудование
обработки информации работает со сбоями. По этой причине важ-
ную роль приобретают механизмы детектирования ошибок. Ведь
если ошибка обнаружена, можно осуществить повторную передачу
данных и решить проблему. Если исходный код по своей длине
равен полученному коду, обнаружить ошибку передачи не представ-
ляется возможным.
Простейшим способом обнаружения ошибок является контроль
по четности. Обычно контролируется передача блока данных (М
бит). Этому блоку ставится в соответствие кодовое слово длиной N
бит, причем N>M. Избыточность кода характеризуется величиной
1—М/N. Вероятность обнаружения ошибки определяется отноше-
нием М/N (чем меньше это отношение, тем выше вероятность об-
наружения ошибки, но и выше избыточность).
При передаче информации она кодируется таким образом, чтобы
с одной стороны характеризовать ее минимальным числом симво-
лов, а с другой - минимизировать вероятность ошибки при декоди-
ровании получателем. Для выбора типа кодирования важную роль
играет так называемое расстояние Хэмминга.
Пусть А и Б две двоичные кодовые последовательности равной
длины. Расстояние Хэмминга между двумя этими кодовыми последо-
вательностями равно числу символов, которыми они отличаются. На-
пример, расстояние Хэмминга между кодами 00111 и 10101 равно 2.
Можно показать, что для детектирования ошибок в п битах,
схема кодирования требует применения кодовых слов с расстояни-
ем Хэмминга не менее п+1. Можно также показать, что для ис-
правления ошибок в п битах необходима схема кодирования с рас-
стоянием Хэмминга между кодами не менее 2п+1. Таким образом,
конструируя код, мы пытаемся обеспечить расстояние Хэмминга
между возможными кодовыми последовательностями больше, чем
оно может возникнуть из-за ошибок.
Широко распространены коды с одиночным битом четности. В
ЭТИХ кодах к каждым М бит добавляется 1 бит, значение которого
определяется четностью (или нечетностью) суммы этих М бит. Так,
капример, для двухбитовых кодов 00, 01, 10, 11 кодами с контролем
четности будут 000, 011, 101 и 110. Если в процессе передачи один
бит будет передан неверно, четность кода из М+1 бита изменится.
70
Гпава 2
Предположим, что частота ошибок (BER) равна р=10“4. В этом
случае вероятность передачи 8 бит с ошибкой составит 1—(1—р)8 =
=7,9х10“4. Добавление бита четности позволяет детектировать лю-
бую ошибку в одном из переданных битах. Здесь вероятность ошибки
в одном из 9 бит равна 9р(1—р)8. Вероятность же реализации необ-
наруженной ошибки составит 1—(1—р)9 — 9р(1—р)8 = 3,6х10~7.
Таким образом, добавление бита четности уменьшает вероятность
необнаруженной ошибки почти в 1000 раз. Использование одного
бита четности типично для асинхронного метода передачи. В синх-
ронных каналах чаще используется вычисление и передача битов
четности, как для строк, так и для столбцов передаваемого массива
данных. Такая схема позволяет не только регистрировать, но и
исправлять ошибки в одном из битов переданного блока.
Контроль по четности достаточно эффективен для выявления оди-
ночных и множественных ошибок в условиях, когда они являются
независимыми. При возникновении ошибок в кластерах бит метод
контроля четности неэффективен и тогда предпочтительнее метод
вычисления циклических сумм (CRC). В этом методе передаваемый
кадр делится на специально подобранный образующий полином. До-
полнение остатка от деления и является контрольной суммой.
В Ethernet Вычисление CRC производится аппаратно (см. также
Ethernet). На рис. 2.7.1. показан пример реализации аппаратного
расчета CRC для образующего полинома В(Х)= 1 4- X2 4- X3 4-Х5 4-
X7. В этой схеме вхддной код приходит слева.
Рис. 2.7.1. Схема реализации расчета CRC
Эффективность CRC для обнаружения ошибок на многие поряд-
ки выше простого контроля четности. В настоящее время стандар-
тизовано несколько типов образующих полиномов.
CRC-12 CRC-16 CRC-CCITT X12 + X11 + X3 + X2 + X1 + 1 х16 4- х15 4- х2 4- 1 х16 4- х12 4- х5 4- 1
Преобразование, кодировка и передача информации
71
2.8. Коррекция ошибок
Исправлять ошибки труднее, чем их детектировать йли предот-
вращать. Процедура коррекции ошибок предполагает два совме-
щенные процесса: обнаружение ошибки и определение места (иден-
тификация сообщения и позиции в сообщении). После решения
этих двух задач, исправление тривиально - надо инвертировать зна-
чение ошибочного бита. В наземных каналах связи, где вероятность
ошибки невелика, обычно используется метод детектирования оши-
бок и повторной пересылки фрагмента, содержащего дефект. Для
спутниковых каналов с типичными для них большими задержками
системы коррекции ошибок становятся привлекательными. Здесь
используют коды Хэмминга или коды свертки.
Код Хэмминга представляет собой блочный код, который позво-
ляет выявить и исправить ошибочно переданный бит в пределах
переданного блока. Обычно код Хэмминга характеризуется двумя
целыми числами, например, (11,7) используемый при передаче 7-бит-
ных ASCII-кодов. Такая запись говорит, что при передаче 7-битного
кода используется 4 контрольных бита (7+4=11). При этом предпо-
лагается, что имела место ошибка в одном бите и, что ошибка в двух
или более битах существенно менее вероятна. С учетом этого ис-
правление ошибки осуществляется с определенной вероятностью.
Например, пусть возможны следующие правильные коды (все они,
кроме первого и последнего, отстоят друг от друга на расстояние 4):
00000000
11110000
00001111
11111111
При получении кода 00000111 не трудно предположить, что
правильное значение полученного кода равно 00001111. Другие коды
отстоят от полученного на большее расстояние Хэмминга.
Рассмотрим пример передачи кода буквы s = 0x073 = 1110011 с
использованием кода Хэмминга (11,7).
Позиция бита: 11109 8 7 6 5 4 3 21
Значение бита: 1 11*001*1**
Символами * помечены четыре позиции, где должны размещать-
ся контрольные биты. Эти позиции определяются целой степенью 2
72
Гпава 2
(1, 2, 4, 8 и т.д.). Контрольная сумма формируется путем выполне-
ния операции XOR (исключающее ИЛИ) над кодами позиций нену-
левых битов. В данном случае это 11, 10, 9, 5 и 3. Вычислим
контрольную сумму:
11 = 1011
10= 1010
09 = 1001
05 = 0101
03 = ООН
S = 1110
Таким образом, приемник получит код:
Позиция бита: 11 10 98 7 6 5 4 3 21
Значение бита: 1 11100 11110
Просуммируем снова коды позиций ненулевых битов и полу-
чим нуль.
11 = 1011
10= 1010
09 = 1001
08 = 1000
05 = 0101
04 = 0100
1 03 = ООН
02 = 0010
Z = 0000
Ну а теперь рассмотрим два случая ошибок в одном из битов
посылки, например, в бите 7 (1 вместо 0) и в бите 5 (0 вместо 1).
Просуммируем коды позиций ненулевых бит еще раз.
11 = 1011
10= 1010
09 = 1001
08 = 1000
07 = 0111
05 = 0101
04 = 0100
03 = ООН
02 = 0010
Z = 0111
11 = 1011
10 = . 1010
Преобразование, кодировка и передача информации
73
09 = 1001
08 = 1000
04 = 0100
03 = ООН
02 = 0010
Z = 0101
В обоих случаях контрольная сумма равна позиции бита, пере-
данного с ошибкой. Теперь для исправления ошибки достаточно ин-
вертировать бит, номер которого указан в контрольной сумме. По-
нятно, что если ошибка произойдет при передаче более чем одного
бита, код Хэмминга при данной избыточности окажется бесполезен.
В общем случае код имеет N=M+C бит и предполагается, что не
более чем один бит в коде может иметь ошибку. Тогда возможно
N+1 состояние кода (правильное состояние и N ошибочных). Пусть
М=4, a N=7, тогда слово-сообщение будет иметь вид: М4, М3, М2, СЗ,
Ml, С2, С1. Теперь попытаемся вычислить значения Cl, С2, СЗ. Для
этого используются уравнения, где все операции представляют со-
бой сложение по модулю 2:
Cl = Ml + М2 + М4
С2 = Ml + М3 + М4
СЗ = М2 + М3 + М4
Для определения того, доставлено ли сообщение без ошибок, вы-
числяем следующие выражения (сложение по модулю 2):
СИ = Cl + М4 4- М2 + Ml
С12 = С2 + М4 + М3 + Ml
С13 = СЗ + М4 + М3 + М2
Результат вычисления интерпретируется следующим образом.
СИ С12 С13 Значение
1 2 4 Позиция бит
0 0 0 Ошибок нет
0 0 1 Бит СЗ не верен
0 1 0 Бит С2 не верен
0 1 1 Бит М3 не верен
1 0 0 Бит С1 не верен
1 0 1 Бит М2 не верен
1 1 0 Бит Ml не верен
1 1 1 Бит М4 не верен
Описанная схема легко переносится на любое число N и М.
74
Гпава 2
Число возможных кодовых комбинаций М помехоустойчивого
кода делится на N классов, где N - число разрешенных кодов. Разде-
ление на классы осуществляется так, чтобы в каждый класс вошел
один разрешенный код и ближайшие к нему (по расстоянию Хэм-
минга) запрещенные коды. В процессе приема данных определяется,
к какому классу принадлежит пришедший код. Если код принят с
ошибкой, он заменяется ближайшим разрешенным кодом. При этом
предполагается, что кратность ошибки не более qm.
Можно доказать, что для исправления ошибок с кратностью не
более qm кодовое расстояние должно превышать m (как правило, оно
выбирается равным D = 2qm+l). В теории кодирования существуют
следующие оценки максимального числа N п-разрядных кодов с рас-
стоянием D.
D=1 N=2n
D=2 N=2nl
D=3 N< 2n /(1+n)
d
D=2q4-1 N < 2" (1 + ]£ C') 1 (для кода Хэмминга это неравен-
ство превращается в равенство)
В случае кода Хэмминга первые к разрядов используются в ка-
честве информационных, причем
k= n - log(n+l),
откуда следует (логарифм по основанию 2), что к может принимать
значения 0,4, 4, 11, 26, 57 и т.д., это и определяет соответствующие
коды Хэмминга (3,1); (7,4); (15,11); (31,26); (63,57) и т.д.
Циклические коды
Обобщением кодов Хэмминга являются циклические коды ВСН
(Bose-Chadhuri-Hocquenghem). Это коды с широким выбором дли-
ны и возможностей исправления ошибок. Циклические коды ха-
рактеризуются полиномом g(x) степени п—k, g(x) = 1 + g^ + g2x2
+ ... + xn k g(x) называется порождающим многочленом цикличес-
кого кода. Число циклических n-разрядных кодов равно числу де-
лителей многочлена хп + 1
При кодировании слова все кодовые слова кратны g(x). g(x)
определяется на основе сомножителей полинома хп4-1 как:
хп 4-1 = g(x)h(x)
Например, если п=7 (х74-1), его сомножители (1 4- х 4- х3)(1 + х 4-
4- х2 + х4), a g(x) = 1 + х~+ х3.
Преобразование, кодировка и передача информации
75
Чтобы представить сообщение h(x) в виде циклического кода, в
котором можно указать постоянные места проверочных и информа-
ционных символов, нужно разделить многочлен xn-kh(x) на g(x) и
прибавить остаток от деления к многочлену xn~kh(x). См. Л.Ф. Ку-
ликовский и В.В. Мотов, «Теоретические основы информацион-
ных процессов». Москва «Высшая школа» 1987. Привлекательность
циклических кодов заключается в простоте аппаратной реализации
с использованием сдвиговых регистров.
Пусть общее число бит в блоке равно N, из них полезную инфор-
мацию несут в себе К бит, тогда в случае ошибки, имеется возмож-
ность исправить m бит. Таблица 2.8.1 содержит зависимость m от
N и К для кодов ВСН.
Увеличивая разность N—М, можно не только нарастить число
исправляемых бит т, но открыть возможность обнаружить множе-
ственные ошибки. В таблице 2.8.2 приведен процент обнаруживае-
мых множественных ошибок в зависимости от М и N—М.
Другой блочный метод предполагает «продольное и поперечное»
контрольное суммирование предаваемого блока. Блок при этом пред-
ставляется в виде N строк и М столбцов. Вычисляется биты четности
для всех строк и всех столбцов, в результате получается два кода,
соответственно длиной N и М бит. На принимающей стороне биты
четности для строк и столбцов вычисляются повторно и сравниваются
с присланными. При выявлении отличия в бите 1 кода битов четности
строк и бите j - кода столбцов, позиция неверного бита оказывается
Таблица 2.8.1
Общее число бит N Число полезных бит М Число исправляемых бит m
31 26 I
21 2
16 3
63 57 I
51 2
45 3
127 420 I
из t 2
106 3
Таблица 2.8.2
Число полезных бит М Число избыточных бит (N-M)
6 7 8
32 - 48% 74% 89%
40 36% 68% 84%
48 23% 625 81%
76
Гпава 2
определенной (i,j). Понятно, что если выявится два и более неверных
битов в контрольных кодах строк и столбцов, задача коррекции стано-
вится неразрешимой. Уязвим этот метод и для двойных ошибок, ког-
да сбой был, а контрольные коды остались корректными.
Применение кодов свертки позволяют уменьшить вероятность
ошибок при обмене, даже если число ошибок при передаче блока
данных больше 1.
Линейные блочные коды
Блочный код определяется, как набор возможных кодов, который
получается из последовательности бит, составляющих сообщение.
Например, если мы имеем К бит, то имеется 2К возможных сообщений
и такое же число кодов, которые могут быть получены из этих сооб-
щений. Набор этих кодов представляет собой блочный код. Линей-
ные коды получаются в результате перемножения сообщения М на
порождающую матрицу G[IA]. Каждой порождающей матрице ста-
вится в соответствие матрица проверки четности (п—k)*n. Эта мат-
рица позволяет исправлять ошибки в полученных сообщениях путем
вычисления синдрома. Матрица проверки четности находится из мат-
рицы идентичности I и транспонированной матрицы A. G[IA] => Н[АТ1].
I А Ат
100,110
101100
Если G[M]= 010 011
то Н[АТ1] = НООЮ
001101
011001
Синдром полученного сообщения равен
S = [полученное сообщение] [матрица проверки четности].
Если синдром содержит нули, ошибок нет, в противном случае
сообщение доставлено с ошибкой. Если сообщение М соответствует
М=2к, а к =3 высота матрицы, то можно записать восемь кодов:
Кодовые векторы для этих сообщений приведены во второй ко-
лонке. На основе этой информации генерируется таблица 2.8.3, ко-
Сообщения Кодовые вектора Вычисленные как
Ml =000 VI = 000000 MIG
М2 = 001 V2 = 001101 M2G
М3 =010 4 V3 = 010011 M3G
М4= 100 V4 = 100110 M4G
М5 = 011 V5 = 011110 M5G
Мб = 101 V6= 101011 M6G
М7= НО V7= 110101 M7*G
М8 = 111 V8 = 111000 . M8'G
Преобразование, кодировка и передача информации
77
Таблица 2.8.3. Стандартный массив для кодов (6,3)
Гобоооо 001101 010011 100110 011110 101011 110101 111000
000001 001100 010010 100111 011111 101010 110100 111001
000010 001111 010001 100100 011100 101001 110111 111010
7000100 001001 010111 100010 011010 101111 110001 111100
001000 000101 011011 101110 010110 100011 111101’ 110000
010000 011101 000011 110110 001110 111011 100101 , 101000
100000 101101 110011 000110 111110 001011 010101 011000
2001001 1 000100 011010 101111 010111 100010 111100 011001
торая называется стандартным массивом. Стандартный массив ис-
пользует кодовые слова и добавляет к ним биты ошибок, чтобы
получить неверные кодовые слова.
Предположим, что верхняя строка таблицы содержит истинные
значения переданных кодов. Из таблицы 2.8.3 видно, что, если ошиб-
ки случаются в позициях, соответствующих битам кодов из левой
колонки, можно определить истинное значение полученного кода.
Для этого достаточно полученный код сложить с кодом в левой
колонке посредством операции XOR.
Синдром равен произведению левой колонки (CL «coset leader»)
стандартного массива на транспонированную матрицу контроля чет-
ности Нт.
Чтобы преобразовать полученный код в правильный, нужно ум-
ножить полученный код на транспонированную матрицу проверки
четности, с тем, чтобы получить синдром. Полученное значение ле-
вой колонки стандартного массива добавляется (XOR!) к получен-
ному коду, чтобы получить его истинное значение. Например, если
мы получили 001100, умножаем этот код наНт:
Синдром ^CL H1 Левая колонка стандартного массива
000 000000
001 000001
010 000010
100 000100
110 001000
101 010000
011 100000
111 001001
этот результат указывает на место ошибки, истинное значение кода
получается в результате операции XOR:
78
Гпава 2
ПО
011
5 = 101 100 0011=001
010
001
001100
000001
—- под горизонтальной чертой записано истинное значение кода.
Смотри также www.cs.ucl.ac.uk/staff/S.Bhatti/D51 -notes/
node33.html (Saleem Bhatti).
Преобразование, кодировка и передача информации
79
2.9. Видеоконференции
по каналам Интернет и ISDN
Расширение международных контактов и реализация проектов с
«удаленными» отечественными партнерами делает актуальной про-
блему экономии командировочных расходов особенно в случае ко-
ротких поездок (1-7 дней). Одним из средств решения проблемы
является использование видеоконференций. Видеоконференции по
каналам Интернет могут быть привлекательны для дистанционно-
го обучения и медицинской диагностики. В отличие от телевизион-
ных программ обучение с использованием Интернет предполагает
диалог между преподавателем и обучаемым, что делает процесс бо-
лее эффективным (эта техника может успешно дополнить WWW-
методику, широко используемую в университетах США и Европы).
Медицинские приложения еще более многообещающи. Видеоконфе-
ренции позволят проконсультироваться в клинике, отстоящей на
тысячи километров, устроить консилиум с участием врачей из раз-
ных городов, оперативно передать томограмму или многоканальную
кардиограмму пациента с целью ее интерпретации и т.д. В более
отдаленной перспективе технология видеоконференций может быть
применена для целей телевидения.
Для проведения видеоконференции необходимо иметь цифровой
канал с пропускной способностью не менее 56-128кбит/с. Если ка-
нал не позволяет, можно ограничиться аудио телеконференцией (см.
раздел IP-phone). Схеме оборудования, необходимого для видеокон-
ференции показано на рис. 2.9.1.
Рис. 2.9.1. Оборудование, необходимое для видеоконференций
80
Гпава 2
Помимо стандартного оборудования рабочей станции (как пра-
вило, под ОС UNIX) требуется интерфейс для подключения видеока-
меры и микрофонов. Этот интерфейс обычно снабжается аппарат-
ной схемой сжатия видео и аудио данных. Многие современные
мультимедиа интерфейсы снабжены входами для видеокамеры. Из
обязательного оборудования на рис. 2.9.1 не показаны наушники и
звуковые колонки. Полезным дополнением может служить скан-
нер, который позволит с высоким разрешением передать изображе-
ния документов или чёртежей, видеомагнитофон, а также видео про-
ектор для отображений принятого изображения на экране или те-
левизор с большим экраном.
Видеоконференции обеспечивают не только «живое» общение
партнеров, но также оперативное обсуждение и редактирование чер-
тежей и документов. При этом разрешающая способность может
превышать в 10-100 раз ту, которая доступна для факсов.
Реализовать видеоконференцию можно разными путями,, из них
два наиболее реальны:
1. Использование оборудования, каналов и программного обеспе-
чения ISDN. Полоса и качество здесь гарантируются, но сто-
имость весьма высока
2. Применение каналов Интернет, соответствующего (обычно об-
щедоступного) программного обеспечения и оборудования об-
щего применения. Вариант относительно дешев, но качество здесь
пока не гарантируется, ведь информационный поток при прове-
дении сеанса конкурирует с потоками от других процессов в
Интернет
При видеоконференциях используется технология CODEC (Coder/
Decoder) для выделенных и телефонных коммутируемых линий (>56
Кбит/с, интерфейс V35), применим и режим коммутации пакетов
(Multicast Backbone, >256 Кбит/с). Перечень стандартов, регламен-
тирующих протоколы видеоконференций можно найти в следую-
щем разделе (2.9.1). Но базовым протоколом для работы в ло-
кальных сетях, где не гарантируется нужный уровень QOS), являет-
ся Н.323 (1996-98 гг.; вторая дата относится к принятию версии
2). Этот стандарт обеспечивает видеоконференции для соединений
точка-точка и для многоточечных топологий в рамках стека прото-
колов TCP/IP, он регламентирует и принципы сжатия видео и аудио
информации. Привлекательность стандарта заключается в том, что
он применим к уже существующей инфраструктуре телекоммуни-
каций с широкими вариациями задержек отклика. Способствует
этому возрастающая пропускная способность локальных (Fast
Ethernet и Gigabit Ethernet) и региональных сетей (SDH, ATM, FDDI>
Преобразование, кодировка и передача информации
81
Fibre Channel и т.д.). Способствуют этому как новейшие протоколы
из семейства IP - RTP и RSVP, так и поддержка Н.323 такими
компаниями как Intel, Microsoft, Cisco и IBM. Н.323 не привязан ни
к одной операционной системе и не предполагает использования
какого-либо специализированного оборудования. На рис. 2.9.2 по-
казана структура системы Н.323 и основных ее компонентов.
Рис. 2.9.2. Структура системы Н.323 и основных ее компонентов
Н.323 определяет четыре главных составляющих коммуника-
ционной системы:
• Терминалы
• Шлюзы
• Блоки многоточечного управления
• Системы управления доступом (Gatekeepers).
Терминалы служат для предоставления пользователям опреде-
ленных услуг и обеспечивают двухсторонний обмен данными в ре-
альном масштабе времени. Все терминалы Н.323 должны также
поддерживать стандарт Н.245, который служит для выбора пара-
метров канала. Структура терминала показана на рис. 2.9.3.
Интерфейс RAS (Registration/Admission/Status) служит для вза-
имодействия с блоком доступа (Gatekeeper) и поддерживает прото-
иолы RTP/RTCP. Опционными частями Н.323 являются видео ко-
Доки, протоколы для проведения информационных конференций
(Т.120) и возможности поддержания многоточечной связи (MCU).
Внешний шлюз также является опционным элементом конферен-
ций Н.323. Шлюз может выполнять функции интерфейса для со-
82
Гпава 2
Рис. 2.9.3. Структура терминала Н.323
гласования с требованиями других форматов, в частности, Н.225 -
Н.221 или других коммуникационных процедур, например, Н.245 -
Н.242. Типичным шлюзом можно считать соединитель Н.323 с
коммутируемой телефонной сетью (GSTN). Блок схема такого шлюза
показан^ на рис. 2.9.4.
Данный шлюз устанавливает аналоговую связь с терминалами
GSTN, с терминалами Н.320 по каналам ISDN и с терминалами
Н.324 по сети GSTN. Терминалы взаимодействуют со шлюзом че-
рез протоколы Н.245 и Q.931. Применяя соответствующую переко-
дировку, можно обеспечить работу шлюза Н.323 с терминалами, под-
держивающими протоколы V.70, Н.322, Н.310 и Н.321. Многие
функции шлюза не стандартизованы, к их числу, например, относит-
ся нумерация подключенных терминалов.
Узел управления доступом (gatekeeper) является центральным
блоком сети Н.323. Через него проходят все запросы обслуживания,
Терминалы Н.323
Рис. 2.9.4. Схема шлюза IP/GSTN
Преобразование, кодировка и передача информации
83
при этом он выполняет функцию виртуального переключателя. Узел
управления доступом осуществляет преобразование имен термина-
лов и шлюзов в их IP и IPX-адреса в соответствии со спецификаци-
ей RAS. Например, если администратор сети установил верхний пре-
дел на число участников-конференции, при достижении этого порога
узел управления доступом может отказать в установлейии соедине-
ния. Совокупность терминалов, шлюзов и блоков MTU, управляе-
мая общим блоком доступа, называется зоной Н.323. Узел управ-
ления доступом может опционно маршрутизовать запросы Н.323.
Разработчики иногда совмещают функции шлюза, MCU и узла уп-
равления доступом, возможно независимое совмещение функций MCU
и узла управления доступом. К числу обязательных функций узла
управления доступом относится.
• Преобразование адресов (например, из стандарта Е.164 в транс-
портный формат).
• Осуществление контроля доступа к локальной сети с исполь-
зованием сообщений Admission Request, Confirm и Reject (возможен
режим разрешения доступа для всех запросов).
• Управление полосой пропускания (поддержка сообщений
Bandwidth Request, Confirm и Reject).
• Управление зоной. Реализация всех вышеперечисленных фун-
кций для MCU, шлюза и терминалов, зарегистрированных в зоне.
Определены некоторые опционные функции узла управления
доступом:
• обработка запросов управления Q.931
• осуществление авторизации терминалов (Q.931), допускаются
ограничения доступа на определенные периоды времени
• управление запросами (контроль занятости терминалов и ис-
пользования полосы пропускания)
Для организации конференций с числом участников три и более
используется блок многоточечного доступа (MCU). MCU включает в
себя многоточечный контроллер (МС) и многоточечный процессор
(MP). МС осуществляет согласование рабочих параметров термина-
лов для обеспечения совместимости при передаче видео и аудио
информации в рамках протокола Н.245. Многоточечный контрол-
лер управляет также ресурсами каналов, при этом поддерживается
как уникастный, так и мультикастный обмен. Все терминалы посы-
лают аудио, видео и данные MCU в режиме соединения точка-точка.
Управляющая канальная информация Н.245 передается непосред-
ственно в МС. МР может выполнять перекодировку в случае ис-
пользования кодеков различного типа. Конференция может быть
°Рганизована в централизованном (все обмены идут через MCU) и
84
Гпава 2
децентрализованном режиме, когда терминалы непосредственно вза-
имодействуют друг с другом. Терминалы используют протокол Н.245,
для того чтобы сообщить МС, сколько видео- и аудио- потоков они
могут обработать одновременно. МР может осуществлять отбор ви-
деосигналов и смешение аудио-каналов при децентрализованной
многоточечной конференции. Допускается и смешенный режим, когда
одновременно реализуется централизованная и децентрализованная
схема обменов.
Новейшая версия Н.323 (v2) за счет аутентификации и шифро-
вания/дешифрования обеспечивает безопасность и конфиденциаль-
ность (перехват в промежуточных узлах становится невозможным).
Более подробно возможности версии 2 изложены в документе http:/
/www.databeam.com/h323/.
Звуковой сигнал передается в оцифрованной и сжатой форме.
Алгоритмы компрессии, поддерживаемые Н.323, соответствуют тре-
бованиям стандартов ITU. Терминалы Н.323 должны быть спо-
собны работать со стандартом компрессии голоса G.711 (56 или
64 Кбит/с). Голосовой кодек должен следовать рекомендациям G.723,
а видео кодек должен соответствовать стандарту Н.261 (поддержка
Н.263 является опционной, этот стандарт обеспечивает более высо-
кое качество изображения). В таблице 2.9.1 приведены форматы
для видео-конференций ITU.
Таблица 2.9.1
Формат картинки для видеоконференции Размер изображения в пикселях Н.261 Н.263
Sub-QCIF 128*96 не специфицировано необходимо
QCIF 176*44 необходимо необходимо
CIF 352*288 опционно опционно
4CIF 702*576 - опционно
16CIF 1408*1152 - опционно
Видеоконференции реализуемы на ЭВМ IBM/PC [1,2], Mackintosh,
SUN, HP, DEC. Пакетная техника обеспечивает удовлетворительное
качество изображения и звукового сопровождения при низкой заг-
рузке канала и малой вероятности ошибок при передаче пакетов.
Достижимое сжатие видеосигнала — 1000:1, звукового 8:1.
Например, система SPARC classic М позволяет передавать по
сети Ethernet до 30 кадров в секунду при разрешении 768x576
точек (PAL). Рассмотренное оборудование может использоваться не
только для «дальней» связи, но для коллективного редактирования
документов и чертежей в пределах одного предприятия, используя
локальную сеть. Это может найти применение при реализации сис-
Преобразование, кодировка и передача информации 85
тем САПР больших предприятий. Для компрессии применяются
методы CellB, JFPEG, MPEG1, Capture (YUV, RGB-8).
Наиболее популярные программные продукты для телеконферен-
ций: vic, vat, nv, wb, sd, ivs. (cm. http://www.anl.gov/linda/video.html.)
Такие программные средства как VAT (Visual Audio Tool,
ftp.ee.lbl.gov), nevot (network voice terminal, gaia.cs.umass.edu:/pub/
hgschulz/nevot), VIC (Video Conference), IVS (INTRA Videoconferenc-
ing System, avahi.inria.fr:/pub/videoconference), NV (Net Video,
beta.xerox.com:/pub/net-research) или wb (whiteboard, ftp.ee.lbl.gov)
базируются на утилитах XI1, они позволяют пользователю осуще-
ствить связь ЭВМ-ЭВМ или сессии с большим числом участников
по каналам Интернет. Поддерживаются следующие схемы коди-
рования и передачи данных: РСМ (64 Кбит/с), DVI, GSM и LPC
(8 Кбит/с). В wb имеется возможность импорта файлов Postscript
(обычно используемых для прозрачен). При этом достигается раз-
решение 640*512, число цветов равно 256, число кадров 2-20, коэф-
фициент сжатия информации -20:1, а требуемая полоса пропуска-
ния канала >128 Кбит/с. Эти параметры не идеальны. Желательно
вдвое большее разрешение, число цветов должно быть равно 16 мил-
лионам, а частота кадров 25-50, но это требует существенно боль-
шей пропускной способности каналов (> 2 Мбит/с). Но прогресс в
области быстродействия каналов связи столь стремителен....
Система mmcc (Multimedia Conference Control program,
ftp.isi.edu:confctrl/mmcc.tar.Z) во многом аналогична описанным
выше, она позволяет клиенту осуществить вызов нужного партне-
ра. Весьма полезной утилитой является SD (Session Directory,
ftp.ee.lbl.gov:sd.tar.Z), которая может запускать приложения, необ-
ходимые для проведения видео конференций.
Пакет CUSeeMe (gated.Cornell.edu:/pub/video/Mac.CU-
SeeMe0.60bl) предназначен для персонального общения через Ин-
тернет, он работает на IBM/PC и МАС, требует 4 Мбайт оперативной
памяти. Один кадр передается за 6-7 секунд при полосе 28,8 Кбит/с,
разрешение составляет 320*240 пикселей. Такое качество соответ-
ствует скорее видео телефону. На экране предусмотрена область
прокрутки, где можно напечатать какой-либо текст. Этим список
Доступных программных продуктов не исчерпывается. Приведен-
ные здесь краткие описания даны лишь в качестве примеров.
Подчеркну, что качество работы сети более критично для переда-
чи звука, чем изображения, ведь потеря нескольких кадров подчас
с°всем незаметна. Потеря же пакетов при передаче звука более
заметна, особенно при диалоге. Когда же используется сжатие, лю-
бые повреждения пакетов приводят к потере целых блоков данных.
86
Глава 2
Для экспериментов с передачей звука и изображения группой
IETF (Internet Engineering Task Force) была сформирована структу-
ра мультикастинг-сети MBONE. MBONE (Multicast Backbpne, до 300
Кбит/с) представляет собой виртуальную сеть, построенную из уни-
каст-туннелей, которые функционируют поверх Интернет. MBONE
составляет около 3,5% от всего Интернет. Рабочие станции для
доступа к MBONE должны поддерживать IP-мультикастинг (см. RFC-
1112 «Host Extensions for IP Multicasting»). Следует иметь в виду,
что не все маршрутизаторы поддерживают мультикастинг.
При работе с MBONE отправитель не должен знать, кто является
получателем, а требуемая пропускная способность канала не зави-
сит от того, обслуживается один клиент или 100.
Требуемая полоса канала для видеоконференций определяется
необходимой разрешающей способностью и частотой кадров. Табли-
ца требований к каналу для передачи изображения представлена ниже.
Частота кадров/с Размер экрана (24 цветовых бит)
1280*1024 640*480 320*240 160*120
30 900 Мбит/с 211 Мбит/с 53 Мбит/с 13 Мбит/с
В таблице приведены требования на пропускную способность
канала при использовании различных степеней сжатия передавае-
мых видеоданных для частоты кадров 30/с и 24 бит на пиксель для
отображения цвета.
Степень сжатия данных Размел экрана
1280*1024 640*480 320*240 160*120
100:1 9 Мбит/с 2.11 Мбит/с 0.53 Мбит/с 0.13 Мбит/с
50:1 18 4,22 1,06 0,26
25:1 36 8,44 2,12 0.52
12:1 75 17,58 4,4 1,08
6:1 150 35,17 8,8 2,16
Требования при передаче звука определяются необходимым ка-
чеством, так для получения полосы 6 Кгц нужно 64 Кбит/с, а для
уровня, сопоставимого с CD, — 1,4 Мбит/с. Применение сжатия
информации позволяет снизить эти требования в 4-8 раз. Общепри-
нятыми стандартами для сжатия изображения при видеоконферен-
циях являются JPEG, MPEG, Н.261. Обычно они реализуются про-
граммно, но есть и аппаратные реализации.
Если сегодня базовым транспортным протоколом для мульти-
медиа является UDP, то в самое ближайшее время его потеснит
Преобразование, кодировка и передача информации
87
RTR и дополнят RSVP и ST-II, что заметно повысит качество и
надежность (см. также раздел IP-phone).
Набор стеков протоколов, которые могут использоваться для
реализации видео конференций в рамках стандартов ITU (транспор-
тный протокол Н.320):
1.GSTN - Н.324 - Н.320 - [Т.120; Н.243; Н.281],
2.ISDN - Н.221 - Н.320 - [Т.120; Н.243; Н.281]
3.ISDN - PPP - IP - Н.323 - Н.320 - [Т.120; Н.243; Н.281
4.LC - PPP - IP - Н.323 - Н.320 - [Т.120; Н.243; Н.281]
5. ATM ’ AAL5 - IP - Н.323 - Н.320 - [Т.120; Н.243; Н.281]
6. ATM - AAL1 - Н.221 - Н.320 - [Т.120; Н.243; Н.281]
2.9.1. Используемые стандарты
Для видеоконференций стандартизованы следующие скорости
обмена:
112 Кбит/с (64 видео, 48 аудио);
128 Кбит/с (64 видео, 64 — аудио);
128 Кбит/с (96 видео, 32 -аудио);
128 Кбит/с (112 — видео, 16 -аудио);
84 Кбит/с (320 — видео, 64 аудио).
G.711 CCITT рекомендация для импульсно-кодовой модуляции
(РСМ) голоса с использованием m-закона кодирования при 8 Кгц
(8000 стробирований в сек)
G.721 CCITT рекомендация для адаптивной дифференциальной
импульсно-кодовой модуляции (ADPCM) для кодирования звука с
полосой 32 Кгц.
G.722 CCITT рекомендация для ADPCM при 64 Кбит/с (7 Кгц)
G.723 CCITT рекомендация для ADPCM при 24 Кбит/с
G.728 (CLEP) CCITT рекомендация для ADPCM при 16 Кбит/с
(3.1 Кгц)
Н.221 CCITT рекомендация для структуры кадров аудио-видео
каналов при скоростях 64 — 1920 Кбит/с.
Н.261 или Р*64- CCITT рекомендация для кодирования/декоди-
рования аудио-видео процедур при скоростях р х 64 Кбит/с, где р=1-
30, что эквивалентно 64 Кбит/с — 2 Мбит/с. Рекомендации первона-
чально были разработаны для узкополосного ISDN. Достижимы ко-
эффициенты сжатия от 4:1 до 160:1. Регламентированы форматы:
CIF 352x288 15 кадров/сек.
Quarter CIF (QCIF) 176x144
CIF 704x576
QCIF 352x288
Super CIF 704x576.
со
Таблица 2.9ЛЛ
Н.320 Н.321 Н.322 Н.323 V1/V2 Н.324
Дата принятия 1990 1995 1995 1996/1998 1996
Сеть Узкополосная переключаемая цифровая ISDN Широкополос- ная ISDN ATM LAT Сети с гаранти- рованной поло- сой пропускания Сети без гаранти- рованной полосы пропускания (Ethernet) PSTN или POTS, аналоговые телефонные системы
Видео Н.261 Н.263 Н.261 Н.263 Н.261 Н.263 Н.261 Н.263 Н.261 Н.263
Аудио G.711 G.722 G.728 G.711 G.722 G.728 G.711 G.722 G.728 G.711 G.722 G.728 G.723 G.729 G.723
Мультиплексирование Н.221 Н.221 Н.221 Н.225 Н.223
Управление Н.230 Н.242 Н.242 Н.230 Н.242 Н.245 Н.245
Многоточечный режим Н.231 Н.243 Н.231 Н.243 Н.231 Н.243 Н.323
Данные Т.120 Т.120 Т.120 Т.120 Т.120
Общий интерфейс 1.400 AAL 1.363 AJM 1.361 PHY 1.400 1.400 & TCP/IP TCP/IP V.34 модем
Гпава 2
Преобразование, кодировка и передача информации
89
Н.320 CCITT рекомендации для узкополосных видео-телефон-
ных систем и терминального оборудования со скоростями не более
1920 Кбит/с. Общее описание CODEC.
JPEG — ISO/CCITT рекомендации объединенной группы фото-
экспертов. В рекомендации определен алгоритм сжатия для стаци-
онарных цветных изображений, при котором отбрасываются визу-
ально второстепенные детали изображения, убирается избыточность
в пределах кадра, в результате обеспечивается сжатие1:30 при поте-
ре качества изображения и 1:15 без потери качества.
JPEG для движущегося изображения — стандарт JPEG, адапти-
рованный для отображения движущегося изображения, обеспечива-
ет индивидуальный доступ к кадрам и коэффициент сжатия инфор-
мации 20:1.
MPEG-1 ISO/CCITT рекомендации группы экспертов по движу-
щемуся изображению, определен алгоритм сжатия для движущего-
ся изображения при работе с каналами 1.5 Мбит/с (1.2 Мбит/с
видео + 200 Кбит/с для аудио) с коэффициентами сжатия от 50:1
до 200:1 при размере изображения 352x240x24 бит и частоте кад-
ров 30/сек.
MPEG-2 ISO/CCITT рекомендации группы экспертов по движу-
щемуся изображению, поток данных для видео и аудио лежит в
пределах между 4 и 15 Мбит/с, достигаются коэффициенты сжатия
от 50:1 до 200:1, размер изображения 728x486, качество соответ-
ствует телевидению высокого разрешения стандарта NTSC (National
Television Standards Committee US).
Сводные данные по стандартам для видеоконференций пред-
ставлены в таблице 2.9.1.1. Новым универсальным набором стан-
дартов для реализации видео-телефонии и мультимедийных обме-
нов является Н.323.
Главным источником помех в
каналах связи, во всяком
случае в России, являются
бульдозеры, экскаваторы и
некомпетентные руководители
3. Каналы передачи данных
В региональных сетях связь, как правило, осуществляется по
схеме точка-точка. При этом “точки” соединяются с помощью мед-
ных проводов (коаксиального кабеля, скрученных пар или того, что
у нас так называется), посредством оптоволоконного кабеля или с
использованием радио каналов (наземных или спутниковых); Дру-
гие методы - акустические, с привлечением открытого лазерного
луча и пр. здесь не рассматриваются.
3.1. Кабельные каналы связи
Кабельные каналы для целей телекоммуникаций исторически,
использовались первыми. Да и сегодня по суммарной длине ониН
превосходят даже спутниковые каналы. Основную долю этих кана-,
лов, насчитывающих многие сотни тысяч километров, составляют
телефонные медные кабели. Эти кабели содержат десятки или дажеч
сотни скрученных пар проводов. Полоса пропускания таких кабе-iJ
лей обычно составляет 3-3,5 Кгц при длине 2-10 км. Эта полоса^
диктовалась ранее нуждами аналогового голосового обмена в рам-,
ках коммутируемой телефонной сети. С учетом возрастающих тре-:
бованиям к широкополосности каналов скрученные пары проводов!
пытались заменить коаксиальными кабелями, которые имеют поло-;
су от 100 до 500 МГц (до 1 Гбит/с), и даже полыми волноводами.^
Именно коаксиальные кабели стали в начале транспортной средой^
локальных сетей ЭВМ (10BASE-5 и 10BASE-2; см. рис. 3.1.1). Л
Каналы передачи данных
S1
Рис. 3.1.1.
1 - центральный проводник; 2 - изолятор;
3 - проводник-экран; 4 - внешний изолятор
Коаксиальная система проводников из-за своей симметричности
вызывает минимальное внешнее электромагнитное излучение. Сиг-
нал распространяется по центральной медной жиле, контур тока
замыкается через внешний экранный провод. При заземлении экра-
на в нескольких точках по нему начинают протекать выравниваю-
щие токи (ведь разные «земли» обычно имеют неравные потенциа-
лы). Такие токи могут стать причиной внешних наводок (иной раз
достаточных для выхода из строя интерфейсного оборудования),
именно это обстоятельство является причиной требования заземле-
ния кабеля локальной сети только в одной точке. Наибольшее рас-
пространение получили кабели с волновым сопротивлением 50 ом.
Это связано с тем, что эти кабели из-за относительно толстой цент-
ральной жилы характеризуются минимальным ослаблением сиг-
нала (волновое сопротивление пропорционально логарифму отно-
шения диаметров внешнего и внутреннего проводников). Но по мере
развития технологии, скрученные пары смогли вытеснить из этой
области коаксиальные кабели. Это произошло, когда полоса про-
пускания скрученных пар достигла 200-350 МГц при длине 100м
(неэкранированные и экранированные скрученные пары категории
5 и 6), а цены на единицу длины сравнялись. Скрученные пары
проводников позволяют использовать биполярные приемники, что
Делает систему менее уязвимой (по сравнению с коаксиальными ка-
белями) к внешним наводкам; Но основополагающей причиной
вытеснения коаксиальных кабелей явилась относительная деше-
визна скрученных пар. Скрученные пары бывают одинарными, объе-
диненными в многопарный кабель или оформленными в виде плос-
кого ленточного кабеля. Применение проводов сети переменного
т°ка для локальных сетей и передачи данных допустимо для весь-
ма ограниченных расстояний. В таблице 3.1.1 приведены характе-
ристики каналов, базирующихся на обычном и широкополосном
к°аксиальном кабелях.
92
Гпава 3
Таблица 3.1.1
Стандартный кабель Широкополосный
Максимальная длина канала 2 км 10 - 15 км
Скорость передачи данных I - 50 Мбит/с 100- 140 Мбит/с
Режим передачи полудуплекс дуплекс
Скдйбление влияния электромагнитных и радиочастотных наводок 50 дБ 85 дБ
Число подключений < 50 устройств 1500 каналов с одним или более устройств на канал
Доступ к каналу CSMA/CD FDM/FSK
На рис. 3.1.2 показана зависимость ослабления кабеля (вне-
шний диаметр 0,95 см) от частоты передаваемого сигнала.
Рис. 3.1.2. Зависимость ослабления сигнала в кабеле от его частоты
При диагностировании сетей не всегда под руками может ока-
заться настоящий сетевой тестер типа WaveTek, и часто приходится
довольствоваться обычным авометром. В этом случае может ока-
заться полезной таблица 3.1.2, где приведены удельные сопротив-
ления используемых сетевых кабелей. Произведя измерение сопро-
тивления сегмента, вы можете оценить его длину.
Эти данные взяты из Handbook of LAN Cable Testing. Wavetek
Corporation, California.
Таблица 3.1.2 Сопротивление кабеля по постоянному току
Коаксиал Ом/сегмент Максимальная длина сегмента
10BASE5 5 500 м
10BASE2 Ю 185 м
Каналы передачи данных
S3
Скрученная пара Ом/100 м
24 AWG 18,8
22 AWG 11,8
Данные, приведенные в таблице, могут использоваться для опера-
тивной предварительной оценки качества кабельного сегмента (соот-
ветствует стандарту EIA/TIA 568, 1991 год). Частотные характерис-
тики неэкранированных пар категории 6 представлены в табл. 3.1.3.
Таблица 3.1.3. Параметры неэкранированных пар категории 6
Частота, МГц Затухание, дБ/100м NEXT, дБ ACR, дБ/100м
1 2,3 62 60
10 6,9 47 41
100 23,0 38 23
300 . 46,8 31 4
Смотри www.osp.ru/lan/lan_6_96/source/57.htm
ACR — Attenuation-to-Crosstalk Ratio — отношение ослабления
к относительной величине перекресных наводок.
NEXT — Near End CrossTalk — перекрестные наводки ближне-
го конца кабеля. ,
Кабели, изготовленные из скрученных пар категории 5 (волно-
вое сопротивление 100,15 Ом), с полосой 100 Мгц обеспечивают
пропускную способность при передаче сигналов ATM 155 Мбит/с.
При 4 скрученных парах это позволяет осуществлять передачу до
622 Мбит/с. Кабели категории 6 сертифицируются до частот 300 Мгц,
а экранированные и до 600 Мгц (волновое сопротивление 100 Ом).
В таблице 3.1.4 приведены данные по затуханию и перекрестным
наводкам. Приведены характеристики такого кабеля с 4-мя скру-
ченными экранированными парами (S-FTP).
Таблица 3.1.4
Частота, МГц Затухание, дБ/100м NEXT, дБ ACR, дБ/100м
1 2,1 80 77,9
10 6,0 80 74
100 19,0 70 51
300 33,0 70 37
L 600 50 60 10
Такой кабель пригоден для передачи информации со скоростью
более 1 Гбит/с.
84
Гпава 3
Ниже на рис. 3.1.3 показана зависимость наводок на ближнем
конце кабеля, содержащего скрученные пары, от частоты передава-
емого сигнала.
Рис. 3.1.3. Зависимость наводок NEXT
от частоты передаваемого сигнала.
На рис. 3.1.4 представлена зависимость ослабления сигнала в
неэкранированной скрученной паре (именно такие кабели наиболее
часто используются для локальных сетей) от частоты передаваемо-
Рис. 3.1.4. Зависимость ослабления сигнала от частоты
для неэкранированной скрученной пары
Каналы передачи данных
95
Ослабление сигнала
Отношение сигнал-шум
' Наводки NEXT
го сигнала. Следует иметь в виду, что при частотах в области сотен
мегагерц и выше существенный вклад начинает давать поглощение
в диэлектрике. Таким образом, даже если проводники изготовить
из чистого золота, существенного продвижения по полосе пропуска-
ния достичь не удастся.
Для неэкранированной скрученной пары 5-ой категории зависи-
мость отношения сигнал-шум от длины с учетом ослабления и
наводок NEXT показана на рис. 3.1.5.
DB
о
-ю
-20
-30
-40
-50
-60
-70
0 10 20 30 40 50 60 70 80 90 100
Частота в Мгц
Рис. 3.1.5 Зависимость отношения сигнал/шум от частоты с учетом
ослабления и наводок на ближнем конце кабеля
Характеристики неэкранированных скрученных пар американс-
кого стандарта 24 AWG (приведены характеристики кабелей, ис-
пользуемых при построении локальных сетей) для кабелей различ-
ной категории собраны в таблице 3.1.5.
Подводя итоги можно сказать, что при расстояниях до 100 мет-
ров с успехом могут использоваться скрученные пары и коаксиаль-
ные кабели, обеспечивая полосу пропускания до 150 Мбит/с, при
больших расстояниях или более высоких частотах передачи опто-
волоконный кабель предпочтительнее. Следует заметить, что работа
с кабелями предполагает необходимость доступа к системе канали-
3аИии (иногда это требует специальных лицензий; а там часто раз-
мещаются усилители-повторители). Кабельное хозяйство требует
обслуживания. В этом отношении радиоканалы предпочтительнее,
Ведь случаев коррозии электромагнитных волн не зарегистрировано,
96
Гпава 3
Таблица 3.1.5.
Категория кабеля Сопротивление по постоянному току (Ь=300м) Ослабление [дБ] NEXT [дБ]
111 28,4 17@4МГц 30 @ 10 МГц 40 @ 16 МГц 32 @4 МГц - 26 @ 10 МГц 23 @ 16 МГц
IV 28,4 13 @4 МГц 22 @ 10 МГц 27 @ 16 МГц 31 @20 МГц 47 @ 4 МГц 4.1 @ 10 МГц 38 @ 16 МГц 36 @20 МГц
V 28,4 13 @4 МГц 20 @ 10 МГц 25 @ 16 МГц 28 @ 20 МГц 67 @ 100 МГц 53 @ 4 МГц 47 @ 10 МГц 44 @ 16 МГц 42 @ 20 МГц 32 @ 100 МГц
да и крысы их не грызут. Справедливости ради отмечу, что здесь
серьезную угрозу представляют корыстолюбивые бюрократы, ответ-
ственные за выдачу лицензий, а они пострашнее крыс.
Каналы передачи данных
97
3.2. Оптические каналы связи
Оптоволоконные линии связи работают в частотном диапазоне
Ю13 - 1016Гц, что на 6 порядков больше, чем в случае радиочастотных
каналов (это обеспечивает пропускную способность 50000 Гбит/с).
Но земная атмосфера является плохой средой для распространения
света. По этой причине только разработка кремниевых волокон с
низким коэффициентом поглощения в инфракрасном диапазоне
(< 0,2 дБ/км) сделало возможным широкое распространение опти-
ческих каналов связи. В 1990 году в США суммарная протяжен-
ность оптических волокон составляла около 9000000 км, к 2000
году ожидается утроение этой длины. Укладывается -1000км оп-
товолоконного кабеля в день. В настоящее время каналы обычно
имеют пропускную способность -1 Гбит/с и это связано с ограни-
ченным быстродействием оборудования, преобразующего оптичес-
кий сигнал в электрический и обратно. В ближайшие годы следует
ожидать увеличения быстродействия таких устройств в 100-1000
раз. Учитывая, что
Af = (сАХ)/Х2,
где с — скорость света, f — частота, а X — длина волны.
Для наиболее популярного диапазона X = 1,3ц и АХ = 0,17ц мы
имеем Af = -ЗОТГц.
Оптоволоконное соединение гарантирует минимум шумов и вы-
сокую безопасность (практически почти невозможно сделать отвод).
Пластиковые волокна применимы при длинах соединений не более
100 метров и при ограниченном быстродействии (<50 МГц). Веро-
ятность ошибки при передаче по оптическому волокну составляет
<1010, что во многих случаях делает ненужным контроль целост-
ности сообщений.
При построении сетей используются многожильные кабели (рис.
3-2.1; существуют и другие разновидности кабеля: например, двух-
или четырехжильные, а также плоские). В верхней части рисунка
[А] изображено отдельное оптоволокно, а в нижней [Б] сечение вось-
мижильного оптического кабеля. Свет (длина волны X - 1350 или
1500 нм) вводится в оптоволокно (диаметром А<100ц) с помощью
светоизлучающего диода или полупроводникового лазера. Централь-
ное волокно покрывается слоем (клэдинг, 1А), коэффициент пре-
ломления которого меньше чем у центрального ядра (стрелками
^ак- Na 3430 Семенов
98
Гпава 3
условно показан ход лучей света в волокне). Для обеспечения меха-
нической прочности извне волокно покрывается полимерным сло-
ем (2А). Кабель может содержать много волокон, например 8 (1Б).
В центре кабеля помещается стальной трос (ЗБ), который использу-
ется при прокладке кабеля. С внешней стороны кабель защищает-
ся (от крыс!) стальной оплеткой (2Б) и герметизируется эластич-
ным полимерным покрытием.
Рис. 3.2.1. Сечение оптоволоконного кабеля
Существует несколько типов оптических волокон, обладающих
различными свойствами. Они отличаются друг от друга зависимос-
тью коэффициента преломления от радиуса центрального волокна.
На рис. 3.2.2 показаны три разновидности волокна (А, Б и В).
Буквами А и Б помечен мультимодовый вид волокон. Тип Б имеет
меньшую дисперсию времени распространения и по этой причине
вносит меньшие искажения формы сигнала. Установлено, что, при-
давая световым импульсам определенную форму (обратный гипер-
болический косинус), дисперсионные эффекты можно полностью ис-
ключить. При этом появляется возможность передавать импульсы
на расстояние в тысячи километров без искажения их формы. Та-
кие импульсы называются солетонами. При современных же техно-
логиях необходимо использовать повторители через каждые 30 км
(против 5 км для медных проводов). По сравнению с медными про->•
водами оптоволоконные кабели несравненно легче. Так одна тыся-
ча скрученных пар при длине 1 км весит 8 тонн, а два волокна той
же длины, обладающие большей пропускной способностью, имеют
Каналы передачи данных
99
В Коэффициент
преломления
Рис. 3.2.2. Разновидности оптических волокон, отличающиеся
зависимостью коэффициента преломления от радиуса
вес 100кг. Это обстоятельство открывает возможность укладки оп-
тических кабелей вдоль высоковольтных линий связи, подвешивая
или обвивая их вокруг проводников.
Буквой В помечен одномодовый вид волокна (понятие мода свя-
зано с характером распространения электромагнитных волн). Эта
разновидность волокна воспринимает меньшую долю света на вхо-
де, за то обеспечивает минимальное искажение сигнала и мини-
мальные потери амплитуды. Следует также иметь в виду, что обору-
дование для работы с одномодовым волокном значительно дороже.
Центральная часть одномодового волокна имеет диаметр 3-10 ц, а
Диаметр клэдинга составляет 30-125 ц. Число мод, допускаемых
волокном, в известной мере определяет его информационную ем-
кость. Модовая дисперсия приводит к расплыванию импульсов и
их наезжанию друг на друга. Дисперсия зависит от диаметра цент-
ральной части волокна и длины волны света. Число мод N равно
Для волокна тцпа А:
2n2d2A2
л2
гДе d - диаметр центральной части (ядра), А - численная апертура
й°локна, ал- длина волны. Волокно с диаметром центральной
Насти волокна 50 ц поддерживает 1000 мод. Для волокна типа Б
4*
100
Гпава 3
(рис. 3.2.2) значение N в два раза меньше. Численная апертура А
равна А - - п, , где п1 и п2, соответственно, коэффициенты пре-
ломления ядра и клэдинга. Величина А определяет ширину вход но-,
го конуса волокна 0 (телесный угол захвата входного излучения)^
6= arcsinA.
Очевидно, что чем больше длина волны, тем меньше число мод и:
меньше искажения сигнала. Это, в частности, является причиной
работы в длинноволновом инфракрасном диапазоне. Но даже для ;
одной и той же моды различные длины волн распространяются по
волокну с разной скоростью. Источники излучения инжектируемо-]
го в волокно имеют конечную полосу частот. Так светоизлучающие!
диоды испускают свет с шириной полосы 35 нм, а лазеры 2-3 нм:
(лазеры имеют, кроме того, более узкую диаграмму направленности,;
чем диоды). Характеристики светодиодов и инжекционных лазер- ;
ных диодов приведены в таблице 3.2.1.
Таблица 3.2.1. Характеристики светодиодов
и инжекционных лазерных диодов
Параметры Светодиод (LED) Инжекционные лазерные диоды
Выходная мощность 0,5-11,5 мВт 3- 10 мВт
Время нарастания 1 - 20 нс 1 - 2 нс
Диапазон тока смещения 5-150 мА 100-500 мА
Время нарастания фотодиода ограничивает быстродействие систе-
мы. Не малую роль играет и уровень шумов на входе приемника. При"
этом световой импульс должен нести достаточно энергии (заметно;
больше уровня шума), чтобы обеспечить низкий уровень ошибок/
В таблице 3.2.2 приведены характеристики оптических приемников.
Таблица 3.2.2. Характеристики оптических приемников |
Параметры PIN Лавинный фотодиод Фото- транзистор Фотоприемник Дарлингтона
Чувствительность 0,5 мкА/мкВт 15 мкА/мкВт 35 мкА/мкВт 180 мкА/мкВт^
Время нарастания 1 нс 2 нс 2 мкс 40 мкс _
Напряжение смещения 10В 100 В 10В 10В
Поглощение света в волокне происходит по нескольким причй*
нам. Поглощение в собственно стекле волокна падает с частотой,
то время как потери из-за рассеяния на дефектах стекла (релеевсков^
рассеяние) с увеличением частоты растет. При сгибании волокЯ^
Каналы передачи данных
707
поглощение увеличивается. По этой причине следует избегать малых
радиусов изгиба (кроме всего прочего это может привести и к обрыву).
В результате потери света в волокне обычно лежит в диапазоне
(2-5) дБ/км для длин волн 0,8 - 1,8 ц. Зависимость поглощения
света в волокне от длины волны показана на рис. 3.2.3. Используе-
мые диапазоны отмечены на рисунке зеленым цветом. Все эти диа-
пазоны имеют ширину 25000-30000 ГГц.
Рис. 3.2.3. Зависимость поглощения света в волокне
от длины волны
Из рисунка видно, что минимумы поглощения приходятся на
1300 и -1500 нм, что и используется для целей телекоммуникаций.
При длине волны 1300 нм дисперсия скоростей распространения
различных длин волн минимальна. Дйапазон ~850 нм характери-
зуется высоким поглощением, но он привлекателен тем, что как
лазеры, так и электроника могут быть изготовлены из одного мате-
риала (арсенида галлия). Зависимость дисперсии от длины волны
показана на рис. 3.2.4.
Из рисунка видно, что в области ниже 1300 нм более длинные
в°лны движутся быстрее коротких. Для длин волн >1300нм имеет
Место обратная ситуация - более длинные волны движутся мед-
леннее коротких. Для одномодовых волокон определяющий вклад
в искажения вносится дисперсией скоростей распространения, для
Многомодовых основной вклад вносит модовая дисперсия. Зависи-
102
Гпава 3
мость полосы пропускания волокна от его длины приведена на .
рис. 3.2.5.
Типовые характеристики оптических волокон приведены в таб- >
лице 3.2.3. (См. также Дональд Дж. Стерлинг, Волоконная опти- f
ка. Техническое руководство. Изд. «ЛОРИ», Москва, 1998 а также |
Дж. Гауэр, Оптические системы связи. Москва, «Радио и связь», |
Рис. 3.2.5. Зависимость полосы пропускания волокна от его длины *
Каналы передачи данных
103
Таблица 3.2.3. Типовые характеристики оптических волокон
Тип волокна Диамег р ядра |мкм| Диаметр клэдинга |мкм| А Затухание [дБ/км] Полоса пропускания [МГц/км|
дл и на волны 850 1300 1550
Одномодовое 9,3 8,1 125 125 0,13 0,17 0,4 0,5 0,3 0,25 5000 для 850 нм
СсГ сглаженным индексом 50 62,5 85 125 125 125 0,2 0,275 0,26 2,4 3,0 2,8 0,6 0,7 0,7- 0,5 0,3 0,4 600 для 850 нм; 1500 для 1300 нм
Ступенчатый индекс 200 380 0,27 6,0 6 при 850 нм
Одним из критических мест волоконных систем являются срос-
тки волокон и разъемы. Учитывая диаметр центральной части во-
локна, нетрудно предположить, к каким последствиям приведет
смещение осей стыкуемых волокон даже на несколько микрон (осо-
бенно в одномодовом варианте, где диаметр центрального ядра ме-
нее 10 микрон) или деформация формы сечения волокон.
Соединители для оптических волокон имеют обычно конструк-
цию, показанную на рис. 3.2.6, и изготовляются из керамики. Оп-
тические аттенюаторы для оптимального согласования динамичес-
кого диапазона оптического сигнала и интервала чувствительности
входного устройства представляют собой тонкие металлические
шайбы, которые увеличивают зазор между волокном кабеля и при-
емником.
Рис. 3.2.6. Схема оптического разъема
С использованием оптических волокон можно создавать не толь-
ко кольцевые структуры. Возможно построение фрагмента сети, по
характеру связей эквивалентного кабельному сегменту или хабу.
Схема такого фрагмента сети представлена на рис. 3.2.7 (пассив-
ный хаб-концентратор). Базовым элементом этой субсети является
пРозрачный цилиндр, на один из торцов которого подключаются
выходные волокна всех передатчиков интерфейсов устройств, со-
104
Гпава 3
Рис. 3.2.7. Схема пассивного оптоволоконного хаба
ставляющих субсеть. Сигнал с другого торца через волокна посту-
пает на вход фото приемников интерфейсов. Таким образом, сигнал,
переданный одним из интерфейсов, поступает на вход всех осталь-
ных интерфейсов, подключенных к этой субсети.
Каналы передачи данных.
105
3.3. Построение сетей передачи данных
с использованием радио каналов
Применение электромагнитных волн для телекоммуникаций
имеет уже столетнюю историю. Спектр используемых волн делится
на ряд диапазонов, приведенных в таблице 3.3.1.
Таблица 3.3.1.
Номер Название диапазона Частота Длина волны
I Высокочастотный 3 - 30 МГц 100- Юм
2 VHF 50- 100 Мгц 6 - 3 м
3 УВЧ (UHF) 400-1000 МГц 75-30 см
4 Микроволновый 3 109- 10" Гц 10 см - 3 мм
5 Миллиметровый 10"- 10*Тц 3 мм - 0.3 мм
6 Инфракрасный 1012 - 6 ю14. 0,3 мм - 0,5 ц
Далее следуют диапазоны видимого света, ультрафиолета, рент-
геновских и гамма-лучей. Диапазоны часто, используемые различ-
ными каналами связи показаны на рис. 3.3.1.
Если не используется направленная антенна и на пути нет пре-
пятствий, радиоволны распространяются по всем направлениям
равномерно и сигнал падает пропорционально квадрату расстояния
между передатчиком и приемником (удвоение расстояния приво-
дит к потерям 6дБ). Радио каналы для целей передачи информа-
ции используют частотные диапазоны 902-928 МГц (расстояния до
10 км, пропускная способность до 64кбит/с), 2,4 ГГц и 12 ГГц (до
50 км, до 8 Мбит/с). Они используются там, где не существует ка-
F (Гц)
Рис. 3.3.1. Диапазоны частот
различных телекоммуникационных каналов.
106
Гпава 3
бельных или оптоволоконных каналов или их создание по каким-то
причинам невозможно или слишком дорого. Более низкие частоты
(например, 300 МГц) мало привлекательны из-за ограничений про-
пускной способности, а большие частоты (>30 ГГц) работоспособны
для расстояний не более или порядка 5км из-за поглощения радио-
волн в атмосфере. При использовании диапазонов 4, 5 и 6 следует
иметь в виду, что любые препятствия на пути волн приведут к их
практически полному поглощению. Для этих диапазонов заметное
влияние оказывает и поглощение в атмосфере. Зависимость погло-
щения от длины волны радиоволн показана на рис. 3.3.1а.
Рис. 3.3.1а. Зависимость поглощающей способности
земной атмосферы от длины волны
Из рисунка видно, что заметную роль в поглощении радиоволн
играет вода. По этой причине сильный дождь, град или снег могут
привести к прерыванию связи. Поглощение в атмосфере ограничи-
вает использование частот более 30 ГГц. Атмосферные шумы, свя-
занные в основном с грозовыми разрядами, доминируют при низких
частотах вплоть до 2 МГц. Галактический шум, приходящий из-за
пределов солнечной системы дает существенный вклад вплоть до
200 ГГц. Зависимость поглощения радиоволн в тумане и дожде от
частоты показана на рис. 3.3.2.
Мощность передатчика обычно лежит в диапазоне 50 мВт — 2 Вт.
Модемы, как правило, используют шумоподобный метод передачи
SST (Spread Spectrum Transmission). Для устройств на частоты 2.4
ГГц и выше, как правило, используются направленные антенны И
необходима прямая видимость между приемником и передатчиком*
Такие каналы чаще работают по схеме точка-точка, но возможна
Каналы передачи данных
107
Рис. 3.3.2. Зависимость поглощения радиоволн
в тумане и дожде от частоты
реализация и многоточечного соединения. На аппаратном уровне
здесь могут использоваться радиорелейное оборудование, радиомо-
демы или радио-бриджи. Схема этих устройств имеет много обще-
го. Отличаются они лишь сетевым интерфейсом (см. рис. 3.3.3).
Антенна служит как для приема, так и для передачи. Трансивер
(приемопередатчик) может соединяться с антенной через специаль-
ные усилители. Между трансивером и модемом может включаться
преобразователь частот. Модемы подключаются к локальной сети
через последовательные интерфейсы типа RS-232 или V.35 (RS-249),
для многих из них такие интерфейсы являются встроенными. Оте-
чественное радиорелейное оборудование имеет в качестве выходного
интерфейс типа G.703 и по этой причине нуждается в адаптере.
^ис. 3.3.3. Схема оборудования радиоканала передачи данных
108
Гпава 3
Радио-бриджи имеют встроенный Ethernet-интерфейс. Длина кабеля
от модема до трансивера лежит в пределах 30-70м, а соединительный
кабель между модемом и ЭВМ может иметь длину 100-150м. Трансивер
располагается обычно рядом с антенной.
Схемы соединения радиомодемов и традиционных модемов со-
вершенно идентичны (см. рис. 3.3.4).
Рис. 3.3.4. Схема подключения радио-модемов
Кроме уже указанных примеров перспективным полем приме-
нения радиомодемов могут стать «подвижные ЭВМ». Сюда следует
отнести и ЭВМ бизнесменов, клиентов сотовых телефонных сетей, и
все случаи, когда ЭВМ по характеру своего применения подвижна,
например, медицинская диагностика на выезде, оперативная диагно-
стика сложного электронного оборудования, когда необходима связь
с базовым отделением фирмы, геологические или геофизические ис-
следования и т.д. Радиомодемы позволяют сформировать сеть быс-
трее (если не считать времени на аттестацию оборудования, получе-
ние разрешения на выбранную частоту и лицензии на использова-
ние данного направления канала). В этом случае могут стать
доступными точки, лишенные телефонной связи (что весьма при-
влекательно для условий России). Подключение объектов к цент-
ральному узлу осуществляется по звездообразной схеме. Заметное
влияние на конфигурацию сети оказывает ожидаемое распределе-
ние потоков информации.. Если все объекты, подключенные к узлу,
примерно эквивалентны, а ожидаемые информационные потоки не
велики, можно в центральном узле обойтись простым маршрутиза-
тором, имеющим достаточное число последовательных интерфейсов.
Применение радио-бриджей особенно выигрышно для ортаниза-
ций, имеющих здания, отстоящие друг от друга на несколько кило-
метров. Возможно использование этих средств связи и для подклю-
чения к сервис-провайдеру, когда нужны информационные .потоки
до 2 Мбит/с (например, для проведения видео конференций). Если
расстояния не велики (<5км), можно воспользоваться всенаправ*^
ленной антенной (см. рис. 3.3.5). .
Каналы передачи данных
109
Рис. 3.3.5. Схема подключения объектов через радио-бриджи
с помощью всенаправленной антенны
Все соединяемые объекты (А, Б, В, и Г) должны быть оснащены
радио-бриджами. Такая схема подключения эквивалентна с одной
стороны кабельному сегменту Ethernet, так как в любой момент
времени возможен обмен лишь между двумя объектами; с другой
стороны радио-бриджи А, Б, В и Г логически образуют много порто-
вый бридж (или переключатель), что исключает загрузку локаль-
ных сетей объектов «чужими» пакетами. Модификации таких схем
связи позволяют строить телекоммуникационные системы по схеме
сотовых телефонных сетей.
При построении каналов на основе радиорелейных систем или
радио-бриджей следует учитывать возможность их взаимного влия-
ния (см. рис. 3.3.6). Проектируя такие каналы в городе и исполь-
зуя направленные параболические антенны, нужно учитывать воз-
можные помехи от зданий и профиля местности. Направленная
антенна с площадью А обеспечивает усиление сигнала:
G = 4tiA/A2,
гДе X длина волны несущей.
Угол излучения 0 такой антенны с радиусом R равен 0,61 Л/R.
Отсюда видно, что чем больше радиус,, тем больше усиление и уже
Угол излучения и чувствительность.
Предельные расстояния для радио каналов приводятся постав-
щиками в предположении, что в пределах первой зоны Френеля ка-
Физических помех нет. При звездообразной схеме каналов
на рис. 3.6.) нужно по возможности выполнить требования на
имальное расстояние между принимающими антеннами D (оно
110
Гпава 3 *
Рис. 3.3.6.
должно быть больше определенного значения, зависящего от аперту-
ры антенны и расстояния между передатчиком и приемником).
Это расстояние определяется расходимостью (а) радиолуча и ис-
пользуемой длиной волны. Если это требование не выполнимо, еле- ,
дует в смежных каналах использовать разные длины волн. Диаг-<
рамма излучения направленной антенны показана на рис. 3.3.7|
(стрелкой отмечено основное направление излучения). Эту диаграм-
му следует учитывать при выборе места установки антенны, особен-
но при использовании большой мощности излучения. Иначе один}
из лепестков излучения может прийтись на места постоянного пре-,
бывания людей (например, жилье). Учитывая эти обстоятельства,
проектирование такого рода каналов целесообразно поручить про-
фессионалам.
Стоимость антенного комплекса обычно пропорциональна кубу
диаметра антенны. Стандартная антенна INTELSAT имеет диаметр
30 м и угол излучения 0,01°.
Спутниковые каналы используют диапазоны перечисленные в
таблице 3.3.2.
Рис. 3.3.7. Диаграмма излучения параболической антенны
Каналы передачи данных
-------------
111
Таблица 3.3.2. Частотные диапазоны, используемые
для спутниковых телекоммуникаций
Диапазон Канал снижения (Downlink)|rTii| Канал подъема (Uplink)[TTu] Источники помех
С 3,7-4,2 5,925-6,425 Наземные помехи
Ku 11,7-12,2 14,0-14,5 Дождь
Ка 17,7-21,7 27,5-30,5 Дождь
Из таблицы видно, что передача ведется на более высокой часто-
те, чем прием сигнала со спутника. Обычный спутник обладает 12-
20 транспондерами (приемопередатчиками), каждый из которых имеет
полосу 36-50МГц, что позволяет сформировать поток данных 50
Мбит/с. Такая пропускная способность достаточна для получения
1600 высококачественных телефонных каналов (32кбит/с). Совре-
менные спутники используют узкоапертурную технологию передачи
VSAT (Very Small Aperure Terminals). Такие терминалы используют
антенны диаметром 1 метр и выходную мощность около 1 Вт. При
этом канал к спутнику имеет пропускную способность 19,2 Кбит/с,
а со спутника более 512 Кбит/с. Непосредственно такие терминалы
не могут работать друг с другом, разумеется через телекоммуникаци-
онный спутник. Для решения этой проблемы используются проме-
жуточные наземные антенны с большим усилением, что, правда уве-
личивает задержку.
Для создания постоянных каналов телекоммуникаций служат
геостационарные спутники, висящие над экватором на высоте око-
ло 36000 км.
Теоретически три таких спутника могли бы обеспечить связью
практически всю обитаемую поверхность земли (см. рис. 3.3.8.).
Рис. 3.3.8.
112
Гпава 3
Реально геостационарная орбита переполнена спутниками раз-
личного назначения и национальной принадлежности. Обычно спут-
ники помечаются географической долготой мест, над которым они
висят. На практике геостационарный спутник не стоит на месте, а
выполняет движение по траектории, имеющей вид цифры 8. Угло-
вой размер этой восьмерки должен укладываться в рабочую аперту-
ру антенны, в противном случае антенна должна иметь сервопривод,
обеспечивающий автоматическое слежение за спутником. Из-за энер-
гетических проблем телекоммуникационный спутник не может обес-
печить высокого уровня сигнала. По этой причине наземная антен-
на должна иметь большой диаметр, а приемное оборудование низ-
кий уровень шума. Это особенно важно для северных областей, для
которых угловое положение спутника над горизонтом невысоко (это
особенно существенно для широт более 70°), а сигнал проходит до-
вольно толстый слой атмосферы и заметно ослабляется. Спутнико-
вые каналы могут быть рентабельны для областей, отстоящих друг
от друга более чем на 400-500 км (при условии что других средств
не существует). Правильный выбор спутника (его долготы) может
заметно снизить стоимость канала.
Число позиций для размещения геостационарных спутников ог-
раничено. В последнее время для телекоммуникаций планируется
применение так называемых низколетящих спутников (<1000 км;
период обращения ~1 час). Эти спутники движутся по эллиптичес-
ким орбитам и каждый из них по отдельности не может гаранти-
ровать стационарный канал, но в совокупности эта система обеспе-
чивает весь спектр услуг (каждый из спутников работает в режиме
«запомнить и передать»). Из-за малой высоты полета наземные
станции в этом случае могут иметь небольшие антенны и малую
стоимость. Смотри также S.Bhatti.
Существует несколько способов работы совокупности наземных
терминалов со спутником. При этом может использоваться муль-
типлексирование по частоте (FDM), по времени (TDM), CDMA (Code
Division Multiple Access), ALOHA или метод запросов.
Схема запросов предполагает, что наземные станции образуют?
логическое кольцо, вдоль которого двигается маркер. Наземная стан-
ция может начать передачу на спутник, лишь получив этот маркер*
Простая система ALOHA (разработана группой Нормана Абрам--
сона из Гавайского университета в 70-х годах) позволяет каждой
станции начинать передачу тогда, когда она этого захочет. Такая
схема с неизбежностью приводит к столкновениям. Связано это
отчасти с тем, что передающая сторона узнает о столкновении лишь
спустя -270 мсек. После столкновения станция ожидает некоторой
Каналы ^передачи данных 113
псевдослучайное время и совершает повторную попытку передачи
еще pait Такой алгоритм доступа обеспечивает эффективность ис-
пользования канала на уровне около 18%, что совершенно недопус-
тимо для таких дорогостоящих каналов, как спутниковые. По этой
причине чаще используется доменная версия системы ALOHA, кото-
рая удваивает эффективность. Одна наземная станция (эталонная)
периодически посылает специальный сигнал, который используется
всеми участниками для синхронизации. Если длина временного до-
мена равна DT, тогда домен с номером к начинается в момент вре-
мени kDT по отношению к упомянутому выше сигналу. Так как
часы разных станций работают немного по разному, необходима
периодическая ресинхронизация. Другой проблемой является раз-
брос времени распространения сигнала для разных станций.
Метод мультиплекирования по частоте (FDM) является ста-
рейшим и наиболее часто используемым. Типичный транспондер с
полосой 36 Мбит/с может использован для получения 500 64кбит/с
ИКМ-каналов, каждый из которых работает со своей уникальной
частотой, чтобы исключить интерференцию с другими. Соседние ка-
налы должны отстоять на достаточном расстоянии друг от друга.
Кроме того, должен контролироваться уровень передаваемого сигна-
ла, так как при слишком большой выходной мощности могут воз-
никнуть интерференционные помехо в соседнем канале. Если число
станций невелико и постоянно, частотные каналы могут быть рас-
пределены стационарно. Но при переменном числе терминалов или
при заметной флуктуации загрузки приходится переходить на ди-
намическое распределение ресурсов. Одним из механизмов такого
распределение имеет название SPADE, он использовался в первых
версиях систем связи на базе INTELSAT. Каждый транспондер сис-
темы SPADE содержит 794 симплексных ИКМ-каналов по 64-кбит/с
и один сигнальный канал с полосой 128 кбит/с. ИКМ-каналы ис-
пользуются попарно для обеспечения полнодуплексной связи. При
этом восходящий и нисходящий каналы имеют полосу по 50 Мбит/с.
Сигнальный канал делится на 50 доменов по 1 мсек (128 бит).
Каждый домен принадлежит одной из наземной станции, число кото-
рых не превышает 50. Когда станция готова к передаче, она произ-
вольным образом выбирает неиспользуемый канал и записывает номер
этого канала в очередной свой 128 битный домен. Если один и тот
канал попытаются занять две или более станции происходит
столкновение и они вынуждены будут повторить попытку позднее.
Метод мультиплексирования по времени сходен с FDM и до-
вольно широко применяется на практике. Здесь также необходима
синхронизация для доменов. Это делается как и в доменной систе-
774
j Гпава 3
ме ALOHA с помощью эталонной станции. Присвоение доменов на-
земным станциям может выполняться централизовано или децен-
трализовано. Рассмотрим систему ACTS (Advanced Commuhication
Technology Satellite). Система имеет 4 независимых канала (TDM)
по 110 Мбит/с (два восходящих и два нисходящих). Каждый из
каналов структурированы в виде 1-милисекундных кадров, каждый
из которых имеет по 1728 временных доменов. Каждый из времен-
ных доменов имеет 64-битовое поле данных, что позволяет реализо-
вать голосовой канал с полосой в 64 Кбит/с. Управление времен-
ными доменами с целью минимизации времени на перемещения век-
тора излучения спутника предполагает знание географического
положения наземных станций. Управление временными доменами
осуществляется одной из наземных станций (MCS — Master Control
Station). Работа системы ACTS представляет собой трехшаговый
процесс. Каждый из шагов занимает 1 мсек. На первом шаге спут-
ник получает кадр и запоминает его в 1728-ячеечном буфере. На
втором — бортовая ЭВМ копирует каждую входную запись в вы-
ходной буфер (возможно для другой антенны). И, наконец, выход-
ная запись передается наземной станции.
В исходный момент каждой наземной станции ставится в соот-
ветствие один временной домен. Для получения дополнительного
домена, например для организации еще одного телефонного канала,
станция посылает запрос MCS. Для этих целей выделяется специ-
альный управляющий канал емкостью 13 запросов в сек. Суще-
ствуют и динамические методы распределения ресурсов в TDM (ме-
тоды Кроузера [Crowther], Биндера [Binder] и Робертса [Roberts]).
Метод CDMA (Code Division Multiple Access) не требует синхро-
низации и является полностью децентрализованным. Как и другие
методы, он не лишен недостатков. Во-первых, емкость канала CDMA
в присутствии шума и отсутствии координации между станциями
обычно ниже, чем в случае TDM. Во-вторых, система требует быст-
родействующего и более дорогого оборудования.
175
Каналь) передачи данных
-------1 ------------ --
3.4. Протокол SUP
Протокол SLIP (Serial Line IP, RFC-1055) - это простейший спо-
соб инкапсуляции IP-дейтограмм для последовательных каналов свя-
зи. Этот протокол стал популярным благодаря возможностям под-
ключения домашних персональных машин к сети Интернет через
порт RS-232, который соединен с модемом. IP-дейтограмма в случае
SLIP должна завершаться специальным символом ОхСО, называе-
мым конец. Во многих реализациях дейтограмма и начинается с
этого символа. Если какой-то байт дейтограммы равен символу ко-
нец, то вместо него передается двухбайтовая последовательность OxDB,
OxDC. Октет OxDB выполняет в SLIP функцию ESC-символа. Если
же байт дейтограммы равен OxDB, то вместо него передается после-
довательность OxDB, OxDD. Использование протокола SLIP предпо-
лагает выполнение ряда условий:
1. Каждый партнер обмена должен знать IP-адрес своего адреса-
та, так как не существует метода обмена такого рода информацией.
2. SLIP в отличие от Ethernet не использует контрольных сумм,
поэтому обнаружение и коррекция ошибок целиком ложится на
программное обеспечение верхних уровней.
З. Так как кадр SLIP не имеет поля тип, его нельзя использо-
вать, в отличие от кадров Ethernet, для реализации других протоко-
лов методом инкапсуляции.
Впервые протокол SLIP был применен в 1984 году в 4.2BSD.
Скорость передачи информации при использовании протокола SLIP
не превышает 19.2 кб/с, что обычно достаточно для интерактивного
обмена в рамках протоколов telnet или RLOGIN. Максимальный раз-
мер передаваемого блока (MTU) для SLIP лежит вблизи 256-512 байт,
что обеспечивает разумный компромисс между значением задержки
отклика (~256мс.) и эффективностью использования канала (-98%
для CSLIP). При этом для передачи одного символа (нажатая клави-
ша) используется 20 байт заголовка в IP-дейтограмме и 20 байт ТСР-
заголовка. Если мы учтем издержки формирования SLIP-кадра, на-
кладные расходы превосходят 40 байт. Частично этот недостаток уст-
ранен в новой версии CSLIP (Compressed SLIP, RFC-1144, предложенной
Джекобсоном в 1990 году). В CSLIP заголовок сокращается до 3-5
байт (против 40 в SLIP). Эта версия протокола способна поддерживать
До 16 TCP-соединений на каждом из концов последовательного кана-
ла. Многие современные SLIP-драйверы поддерживают и CSLIP.
116
Гпава 3
3. 4.1. Протоколы RS
Протоколы RS (RS-232, RS-449, RS-423-A, RS-422-A и RS-485)
относятся к семейству рекомендованных протоколов (буква R в на-
звании обозначает recommended). RS-232 обеспечивает дуплексную
связь и скорость передачи 19,2 Кбит/с при длине связи до 15м. На
практике при расстояниях порядка 10 метров можно получить бы-
стродействие канала более 100кбит/с. Здесь обеспечивается связь
точка-точка. Логической 1 соответствует уровень сигнала —(5-15)В,
а логическому нулю +(5-15)В. В отличие от других упомянутых
выше стандартов, которые допускают скорости обмена до 10Мбит/с
(при длине линии 15м), данный протокол из-за низкой скорости
обмена работает без использования симметричных сигналов на скру-
ченной паре канала связи. Более подробную информацию можно
найти, например, в http://ixbt.stack.net/comm/rs_proto.html.
Стандарт RS-449 представляет собой в действительности семей-
ство, состоящее из 3-х стандартов. Механическая, функциональная и
процедурная часть содержится в самом RS-449, а регламентации элек-
трического интерфейса описаны в RS-423-A (подобен RS-232-C) для
схемы с общей землей. Балансная симметричная схема интерфейса
представлена в документе на RS-422-A, для передачи каждого сиг-
нала используется два провода, что позволяет достичь быстродей-
ствия 2Мбит/с при длине соединения до 60м.
Каналы передачи данных
117
3.5. Протокол РРР
Протокол PPP (Point-to-Point Protocol; RFC-2716, -2701, -2688,
-2687, -2686, -2516, -2509, -2508, -2507, -2484, -2472, -2433, -2420, -
2419, -2364, -2363, -2290, -2284, -2153, -2125, -2097, -2043, -1994, -
1993, -1990, -1989, -1979, -1978, -1977, -1976, Л975, -1974, -1973, -
1969, -1968, -1967, -1963, -1962, -1915, -1877, -1841, -1764, -1763, -
1762, -1663, -1662, -1661, -1638, -1619, -1618, -1598, -1570, -1552,
-1378, -1377, -1334, -1332, -1331, и STD-51, смотри также
www.spitbrook.destek.com:81/pptp.txt) предназначен для решения тех
же задач, что и SLIP, но лишен многих его недостатков, он служит
для передачи мультипротокольных дейтограмм от одного узла к дру-
гому. Сам по себе список RFC, приведенный выше, впечатяющ. Он
говорит о том, что данный протокол относится к числу наиболее
важных и широкоиспользуемых. Это и понятно, большинство регио-
нальных сетей строится с использованием соединений точка-точка.
РРР поддерживает, как асинхронный режим с 8 битами данных без
бита четности (согласуется со свойствами последовательного интер-
фейса, имеющегося практически на всех ЭВМ), так и побитовый син-
хронный режим. Протокол содержит в себе три составные части:
— Метод инкапсуляции дейтограмм при передаче по последов-
тел ьным коммуникационным каналам.
— Протокол LCP для установления, конфигурирования и тести-
рования информационных каналов
—Набор протоколов NCP для установки и конфигурирования
различных протоколов сетевого уровня.
Протокол управления каналом (LCP — Link Control Protocol)
является частью РРР. Идеология LCP реализована и в протоколе
TCP. Каждый кадр РРР начинается и завершается флагом 0х7Е.
За стартовым флагом-октетом следует байт адреса, который всегда
равен OxFF. Формат кадра РРР представлен на рисунке 3.5.1. Кадр
РРР может содержать только целое число байт. При инкапсуляции
Других пакетов в РРР используется бит-ориентированный прото-
кол HDLC (High-Level Data Link Control).
Поле адрес всегда содержит байт OxFF (смотри также HDLC).
Это указывает на то, что все станции должны принять этот кадр, и
Исключает необходимость выделения каких-то специальных адре-
сов. Байт управления всегда равен 0x03, что указывает на ненуме-
рованный тип кадра. По умолчанию кадры РРР передаются в ре-
118
Гпава 3
2 I
Рис. 3.5.1. Формат кадра в протоколе РРР
жиме «без установления соединения». Если требуется надежная
доставка, используется версия, описанная в RFC-1663. Двухоктет-
ное поле протокол сходно по функции с полем тип в кадре Ethernet
и определяет то, как следует интерпретировать информационное поле
(см. табл. 3.5.1). Значение 0x0021 этого поля говорит о том, что
последующее информационное поле содержит в себе 1Р-дейтограм-
му. Поле CRC (Cyclic Redundancy Check) представляет собой цик-
лическую контрольную сумму, предназначенную для выявления
ошибок при транспортировке PPP-кадра. Применение флагов-огра-
ничителей кадра (0х7Е) создает те же проблемы, о которых говори- 1
лось при описании SLIP-протокола, — эти байты не могут присут- >
ствовать в информационном поле. В синхронном режиме эта про-
блема решается на аппаратном уровне. При работе в асинхронном
режиме для этого используется специальный esc-символ, равный
0x7D. Когда этот esc-символ встречается в информационном поле,
шестой бит в следующем за ним байте инвертируется. Так байт ?
0х7Е будет преобразован в последовательность 0x7D, 0х5Е, а байт
0x7D — в два байта 0x7D, 0x5D. Все символы с кодами меньше
0x20 также преобразуются в esc-последовательности. Например, 0x07
будет преобразован в 0x7D, 0x27. Это необходимо делать, так как
управляющие символы могут оказать непредсказуемые воздействия
на режим работы драйверов или модемов, используемых в канале.
Протокол РРР в отличие от SLIP допускает мультипротокольность
и динамическое определение IP-адресов партнеров. Несмотря на оп-
ределенные преимущества протокола РРР перед SLIP, последний
распространен достаточно широко.
Значения кодов поля протокола от Оххх до Зххх идентифициру-
ют протоколы сетевого уровня, а значения в интервале 8ххх — Ьххх
говорят о том, что протокол соответствует NCP (Network Control
Protocol). Коды из диапазона 4ххх — 7ххх используются для про-
Каналы передачи данных
Таблица 3.5.1. Стандартизованные DLL-номера протоколов для РРР
(поле протокол]
DLL-код протокола (шестнадца- теричный) Наименование протокола
• обо! Протокол заполнения (padding)
“бббЗ-OOlF Зарезервировано
0021 IP-протокол
0023 Сетевой уровень OSI
0025 Xerox NS IDP
0027 DECnet фаза IV
0029 Appletalk
002В Novell IPX
002D Компрессированный TCP/IP протокол Ван Джекобсона
002F He компрессированный TCP/IP протокол Ван Джекобсона
0031 PDU мостов
0033 Потоковый протокол (ST-II)
0035 Banyan Vines
0039 AppleTalk EDDP
003В AppleTalk SmartBuffered
003D Multi-Link
003F Кадры NETBIOS
0041 Cisco Systems
0043 Ascom Timeplex
0047 Удаленная локальная сеть DCA
0049 Транспортный протокол для последовательных данных (PPP-SDTP)
004В SNA через 802.2
004D SNA
004F Сжатие заголовков IP6
007D Зарезервировано (Управл. Esc) [RFC 16611
00FD 1-ый вариант компрессии
0201 Пакеты отклика 802.Id
0203 IBM BPDU базовой маршрутизации
8021 Управляющий протокол Интернет (IPCP)
8023 Управляющий протокол сетевого уровня OSI
_ 8025 Управляющий протокол Xerox NS IDP
. 8027 Управляющий протокол DECnet фаза VI
_ 8029 Управляющий протокол AppleTalk
___802В Управляющий протокол Novell IPX
___ 8031 Бридж NCP
8033 Потоковый управляющий протокол
8035 Управляющий протокол Banyan Vines
803D Многосвязный управляющий протокол
803F Управляющий протокол кадров NETBIOS
8041 Управляющий протокол CISCO
—Л043 Ascom Timeplex
8045 Управляющий протокол Fujitsu LB LB
L_8047 Управляющий протокол удаленных локальных сетей DCA (RLNCP)
120
Гпава 3
Таблица 3.5.1. Продолжение.
DLL-код протокола (шестнадца- теричный) Наименование протокола
8049 Управляющий протокол передачи последовательных данных (PPP-SDCP)
804В Управляющий протокол для передачи SNA поверх 802.2
804D Управляющий протокол SNA
804F Управляющий протокол сжатия заголовков IP6
80FD Управляющий протокол сжатия
С021 Канальный управляющий протокол
С023 Протокол аутентификации паролей
С025 Сообщение о состоянии канала
С081 Управляющий протокол для работы с контейнерами
токолов с низким уровнем трафика, а коды от сххх до еххх соот-
ветствуют управляющим протоколам (например, LCP).
Протокол РРР при установлении соединения предусматривает
процедуру аутентификации, которая является опционной (смотри
рис. 3.5.2.). После перехода на сетевой уровень вызывается NCP-
протокол, который выполняет необходимую конфигурацию канала.
При обнаружении несущей или по инициативе клиента система
может попытаться установить соединение. В случае успеха осуще-
ствляется переход в фазу аутентификации. Если же и аутентифика-
ция завершается благополучно, система выполняет подключение к
сети (IP, IPX, AppleTalk и т.д.), настройка сетевого уровня произво-
дится в рамках протокола NCP. Во всех остальных случаях выпол-
няется возврат в исходное состояние. Процедура закрытия соедине-
ния осуществляется протоколом LCP.
Исходное j Запуск
состояние |
Установка
; Открытие А
1-——Аутентификация]—
| канала
Неудача
Неудача
Успех/
неуспех
Закрытие I I v
---------1 Завершение —---------
| ; Закрытие
L__________I
I П
j Подключение [
к сети
Рис. 3.5.2. Алгоритм установления соединения РРР
Каналы передачи данных
121
В поле данных PPP-пакета может быть вложен один LCP-пакет,
в этом случае в поле протокол должен быть записан код 0хС021
(Link Control Protocol). LCP-протокол служит для установления
соединения путем обмена конфигурационными пакетами. По завер-
шении этого обмена система переходит в фазу аутентификации
(рис.3.5.2). Формат заголовка LCP-пакета показан на рис. 3.5.3.
О 78 15 16 31
Код Идентификатор Длина
Рис. 3.5.3. Формат заголовка LCP-пакета
Вслед за заголовком следует поле данных. Поле код (1 октет)
идентифицирует модификацию LCP-пакета. Если получен пакет с
неизвестным полем код, посылается пакет-отклик «отклонение
кода». Поле идентификатор (1 октет) служит для нахождения
соответствия между запросами и откликами. Если получен пакет с
неправильным идентификатором, он просто уничтожается. Двухок-
тетное поле длина определяет размер LCP-пакета, включая размер
заголовка. Октеты принятого пакета за пределами, заданными по-
лем длина игнорируются.
В качестве примера можно рассмотреть процедуру подключения
персональной ЭВМ к серверу через модем. После того как модем
маршрутизатора ответит на вызов модема-клиента и установит фи-
зическое соединение, ЭВМ посылает последовательность LCP-паке-
тов, вложенных в поля данных одного или нескольких РРР-кадров.
Это позволяет выбрать необходимые параметры РРР. По заверше-
нии этой процедуры посылается последовательность NCP-пакетов,
которые конфигурируют сетевой уровень. Вероятно, ЭВМ захочет
работать со стеком протоколов TCP/IP, и по этой причине нуждает-
ся в IP-адресе. Если провайдер имеет N IP-адресов в резерве, он
может подключить одновременно N ЭВМ. Присвоение IP-адреса осу-
ществляется также в рамках NCP-протокола. После этого ЭВМ ста-
новится узлом Интернет. Завершение сессии и освобождение IP-
аДреса выполняется также через NCP-протокол. Разрыв соединения
ОсУЩествляет протокол LCP.
Эа полем длина могут следовать поля опций. Опции определя-
ется все сразу на фазе конфигурирования канала. Описание опции
СоДержит однооктетные субполя типа и длины, за которыми следует
Ле Данных. Значения субполя типа представлены в таблице.
122
Гпава 3
Значение кода поля типа Назначение опции
0 Зарезервировано
1 Maximum-Receive-Unit (указывает максимальный размер блока данных, который может быть принят)
3 Authentication-Protocol (протокол аутотентификации)
4 Quality-Protocol (протокол качества)
5 Magic-Number (магическое число, опция служит для выявления каналов с петлями обратной связи)
6 Protocol-Field-Compression
7 Address-and-Control-Field-Compression
Существует три класса LCP-пакетов:
1. Пакеты конфигурации канала, которые используются при фор-
мировании виртуального канала (Configure-Request, Configure-Ack,
Configure-Nak и Configure-Reject)
2. Пакеты закрытия канала (Terminate-Request и Terminate-Ack).
3. Пакеты поддержания, которые служат для управления и от-
ладки (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-
Request).
Аналогом LCP является протокол IPCP (IP Control Protocol).
В поле код протокола в этом случае записывается 8021 (RFC-1332).
Формат пакета IPCP показан на рис. 3.5.4.
Тип Длина Протокол сжагия IP
1 байт 1 байт 2 байта
Данные
Рис. 3.5.4. Формат пакета IPCP. Младшие биты слева.
Поле тип содержит 2, в поле длина заносится число байт в
пакете (>4). В поле протокол сжатия IP заносится код алгоритма
сжатия (0x02d — в случае алгоритма Ван Джекобсона). Поле дан-
ные может содержать нуль или более октетов. Конфигурационный
запрос может потребовать присылки (присвоения) IP-адреса. Для
решения этой задачи предусмотрена опция IPCP-пакета, где поле
тип=3, длина=6, а последующие 4 байта выделены для IP-адреса,
куда отправитель должен его записать. Если туда записаны нули,
это говорит о том, что отправитель запрашивает свой IP-адрес.
Протоколы PPP, LCP (Link Control Protocol), ССР (Compression
Control Protocol; RFC-1962, -1967), и некоторые другие управляю-
щие протоколы содержат 8-битовые поля код. Значения этих кодов
приведены в таблице 3.5.2.
Каналы передачи данных
123
Таблица 3.5.2. Значения поля код LCP-заголовка
Код Тип пакета
1 Запрос конфигурации Configure-Request
2 Подтверждение конфигурации Configure-Ack
3 Не подтверждение конфигурации Configure-Nak
4 Отклонение конфигурации Configure-Reject
5 Запрос завершения Terminate-Request
6 Подтверждение завершения Terminate-Ack
7 Отклонение кода Code-Reject
8* Отклонение протокола Protocol-Reject
9* Запрос отклика Echo-Request
10* Эхо-отклик Echo-Reply
11* Запрос отмены Discard-Request
12* Идентификация
13* Остающееся время
14** Запрос сброса
15** Отклик на запрос сброса
*) Только LCP; **) Только ССР
Для случая запроса Discard-Request между полями длина и дан-
ные помещается 4-байтовое поле Magic-Number (магическое число).
Протокол РРР многолик, он способен поддерживать и многока-
нальные соединения (RFCrl990). Это бывает полезно при работе
через ISDN, Х.25, Frame Relay или при необходимости расширить
пропускную способность за счет подключения нескольких парал-
лельных каналов (МР — MultiLink Protocol). Так как я не сталки-
вался со случаями, когда пропускной способности было вполне дос-
таточно, данную модификацию PPP-протокола следует считать край-
не важной. При этом одной из проблем является распределение
пакетов по каналам и последующее их упорядочение принимающей
стороной. Особую осторожность в этом случае следует соблюдать
при использовании заполнителей. В этом режиме по виртуальному
каналу MultiLink запрещается посылать конфигурационные LCP-
пакеты Configure-Request, -Reject, -Ack, -Nak, Terminate-Request или
“Ack. Принимающая сторона в случае их обнаружения должна их
игнорировать. Применение других LCP-пакетов допускается (напри-
МеР, Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-
Request).
Формат MP-пакета представлен на рис. 3.5.5.
Поля PID — идентификатор протокола. Субполе В (Beginning)
бит фрагмента =1 для первого фрагмента РРР и =0 для всех
124
Гпава 3
последующих фрагментов. Субполе Е (Ending) — бит фрагмента =1
для последнего фрагмента РРР и =0 для всех прочих фрагментов.
Поле номер по порядку имеет длину 24 бита. Существует модифи-
кация пакета с укороченным кодом (12 бит) номера по порядку.
При этом к этому полю отходят 4 нулевые бита после ВЕОО. Выбор
длины этого поля осуществляется протоколом LCP. Значение поля
увеличивается на 1 при посылке очередного фрагмента. Для выше-
расположенных уровней совокупность совместно используемых ка-
налов выглядит, как один виртуальный канал.
При передаче пакетов по каналу Multilink инкапсуляция произ-
водится согласно следующим правилам, которые задаются вручную:
• Никакого асинхронного управления кодированием символов
• Запрет использования магических чисел
• Запрещено мониторирование качества канала
• Сжатие полей адреса, протокола и управления
• Никаких составных кадров
• Запрет заполнения с самоописанием (Self-Describing-Padding)
Для предварительно фрагментированных пакетов запрещено до-
полнение нулями или использование каких-либо иных заполните-
лей. Рассмотрим пример Multilink-соединения, приведенный на рис.
3.5.6. Канал 1 между двумя системами согласуется сетевыми уров-
нями NL1, NL2 и МР. Затем эти две системы согласуют с МР канал
2. Кадры, полученные каналом 1, демультиплексируются на ка-.
нальном уровне согласно сетевому протокольному идентификатору
РРР и могут быть посланы NL1, NL2 или МР. Канал 2 примет
кадры со всеми сетевыми протокольными идентификаторами, с ко-
торыми принимает их канал 1. Кадры, полученные МР, позднее Де'
мультиплексируются на сетевом уровне согласно протокольному
Каналы передачи данных
125
Канал 1 Канал 2
Рис. 3.5.6. Пример Multilink-конфигурации
идентификатору РРР и посылаются NL1 или NL2. Любые кадры,
полученные МР для других протоколов сетевого уровня, отбрасыва-
ются с помощью стандартного протокольного механизма (Reject).
Так как межсетевые связи часто используют последовательные
каналы (выделенные линии, радио-модемы и пр.), протокол РРР
распространен достаточно широко. Протокол РРР служит и для
создания межсетевых туннелей (протокол РРТР — Point to Point
Tunneling Protocol). Протокол РРТР использует MTU=1532, номер
порта 5678 и номер версии 0x0100, пакеты данных здесь транспор-
тируются с использованием протокола инкапсуляции GRE V2 (см.
сноску в начале раздела).
126
Глава 3
3.6. Протокол интерфейса G. 703
Интерфейс G.703 (ITU-T Recommendation G.703.Physical/Electrical
Characteristics of Hierarchical Digital Interfaces. 1972 last amended
in 1991) был разработан в 1972 году и базируется на стандартах
G.702, G.704 и 1.430 и обслуживает сети с иерархией PDH и SDH.
Первоначально он разрабатывался для систем с импульсно-кодовой
модуляцией. G.703 может работать на скоростях передачи данных
64 Кбит/с, 1544, 6312, 32064 и 44736 Кбит/с (PDH, американская
версия), 2048, 8448, 34368, 139264 Кбит/с (европейская версия).
Предусматривается работа и при 155,52 Мбит/с. В качестве физи-
ческого канала передачи может использоваться скрученная пара
(Z=100-120 Ом) или коаксиальный кабель (75 Ом), амплитуда им-
пульса 1-ЗВ,
При скорости 64 Кбит/с через интерфейс передается три типа
сигналов: информационный (64 Кбит/с) и два синхронизирующих
тактовых 64 Кбит/с и 8 Кбит/с. Стандарт предусматривает 3 вида
взаимодействия терминального оборудования: однонаправленный
(codirectional; рис. 3.6.1), разнонаправленный (рис. 3.6;2) и с цент-
ральным тактовым генератором (рис. 3.6.3).
Рис. 3.6.1. Однонаправленная передача информации
и тактовых сигналов
Во втором варианте терминалы неравноправны - один из них
управляющий, другой - управляемый. Тактовые сигналы идут в
этом случае только от управляющего терминала.
Рис. 3.6.2. Разнонаправленная передача информации
и тактового сигнала для 64 Кбит/с
Каналы передачи данных
127
Рис. 3.6.3. Интерфейс с центральным тактовым
генератором для 64 Кбит/с
Таблица 3.6.1.
Частота синхронизирующих сигналов может
быть меньше скорости передачи данных в 2, 4 и 8
раз. Тип кода зависит от скорости передачи и
типа аппаратного интерфейса. Характеристики ос-
новных разновидностей интерфейса G.703 приве-
дены в таблице 3.6.1.
Кодировка относится лишь для проводных
каналов.
4. Сети передачи данных.
Метод доступа
В настоящее время существует огромное разнообразие сетей. Но
есть у них и нечто общее. Практически все они базируются на пакет-
ном принципе передачи данных, и в этой связи всем им приходится
решать проблему выделения начала и конца пакетов. Как правило,
для этой цели используются уникальные последовательности бит
или уникальные коды. При этом возникает проблема, если подобные
сигнатуры встретятся в теле пакета. Задача решается с использова-
нием esc-последовательностей или техники бит-стаффинга. При пе-
редаче данных нужно обеспечивать синхронизацию и стабилизацию
уровня регистрации. Практически все сети, так или иначе, решают
проблему мультиплексирования. Как локальные, так и региональ-
ные сети могут отличаться по топологии и методу доступа.
Топология
Среди топологических схем наиболее популярными являются
(см. рис. 4.1):
1. Шина
2. Звезда
3. Кольцо
4. Многокаскадные и многосвязные сети
К первым трем типам топологии относятся 99% всех локаль-
ных сетей. Наиболее популярный тип сети - Ethernet, может стро-
иться по схемам 1 и 2. Вариант 1 наиболее дешев, так как требует
Сети передачи данных. Метод доступа
129
Рис. 4.1. Примеры сетевых топологий
по одному интерфейсу на машину и не нуждается в каком-либо
дополнительном оборудовании. Сети Token Ring и FDDI использу-
ют кольцевую топологию (3 на рис. 4.1), где каждый узел должен
иметь два сетевых интерфейса. Эта топология удобна для оптоволо-
конных каналов, где сигнал может передаваться только в одном
направлении (но при наличии двух колец, как в FDDI, возможна и
двунаправленная передача). Нетрудно видеть, что кольцевая топо-
логия строится из. йоследовательности соединений точка-точка.
Используется и немалое количество других топологий, которые
являются комбинациями уже названных. Примеры таких тополо-
гий представлены на рис. 4.2.
Вариант А на рис. 4.2 представляет собой схему с полным набо-
ром связей (все узлы соединены со всеми), такая схема использует-
ся только в случае, когда необходимо обеспечить высокую надеж-
ность соединений. Эта версия требует для каждого из узлов нали-
чия N-1 интерфейсов при полном числе узлов N. Вариант Б является
примером нерегулярной топологии, а вариант В - иерархический
случай связи (древовидная топология).
Если топологии на рис. 4.1 чаще применимы для локальных
сетей, то топологии на рис. 4.2 более типичны для региональных и
глобальных сетей. Выбор топологии локальной или региональной
сети существенно сказывается на ее стоимости и рабочих характе-
ристиках. При этом важной характеристикой при однородной сети
и
является среднее число шагов между узлами D.
<7=1
dNd
7V-1
где Nd -
число ЭВМ на расстоянии d. п - полное число ЭВМ в сети; d
Расстояние между ЭВМ. Для сети типа А на рис. 4.2 D=l.
Современные вычислительные системы используют и другие то-
кологии: решетки (А), кубы (В), гипердеревья (Б), гиперкубы и т.д.
(см. рис. 4.3). Но так как некоторые вычислительные системы (кла-
$ ^ак* Na 3430 Семенов
130
Гпава 4
Рис. 4.2. Различные сетевые топологические схемы
Рис. 4.3. Некоторые топологии вычислительных систем
стеры) базируются на сетевых технологиях, я привожу и такие при-
меры. В некоторых системах топология может настраиваться на
решаемую задачу.
Метод доступа к сети
Метод доступа определяет метод, который используется при муль-
типлексировании/демультиплексировании данных в процессе пере-
дачи их по сети. Большая часть современных сетей базируется на
алгоритме доступа CSMA/CD (Carrier Sensitive Multi pie Access with
Collision Detection), где все узлы имеют равные возможности доступа
к сетевой среде, а при одновременной попытке фиксируется столк-
новение и сеанс передачи повторяется позднее. Здесь нет возможно-
сти приоритетного доступа и по этой причине такие сети плохо
приспособлены для задач управления в реальном масштабе време-
ни. Некоторое видоизменение алгоритма CSMA/CD (как это сдела-
но в сетях CAN или в IBM DSDB) позволяют преодолеть эти огра-
ничения. Доступ по схеме CSMA/CD (из-за столкновений) предпо-
лагает ограничение на минимальную длину пакета. По существу,
метод доступа CSMA/CD предполагает широковещательную переда-
чу пакетов (не путать с широковещательной адресацией). Все рабо-
Сети передачи данных. Метод доступа
131
чие станции логического сетевого сегмента воспринимают эти паке-
ты хотя бы частично, чтобы прочесть адресную часть. При широко-
вещательной адресации пакеты не только считываются целиком в
буфер, но и производится прерывание процессора для обработки факта
прихода такого пакета. Логика поведения субъектов в сети с досту-
пом CSMA/CD может варьироваться. Здесь существенную роль иг-
рает то, синхронизовано ли время доступа у этих субъектрв. В слу-
чае Ethernet такой синхронизации нет. В общем случае при нали-
чии синхронизации возможны следующие алгоритмы.
А.
1. Если канал свободен, терминал передает пакет с вероятностью 1.
2.Если канал занят, терминал ждет его освобождения, после
чего производится передача.
Б.
1. Если канал свободен, терминал передает пакет.
2. Если канал занят, терминал определяет время следующей по-
пытки передачи. Время этой задержки может задаваться некото-
рым статистическим распределением.
8.
1. Если канал свободен, терминал с вероятностью р передает па-
кет, а с вероятностью 1-р он откладывает передачу на t секунд (на-
пример, на следующий временной домен).
2. При повторении попытки при свободном канале алгоритм не
изменяется.
3. Если канал занят, терминал ждет пока канал не освободится,
после чего действует снова согласно пункту 1.
Алгоритм А на первый взгляд представляется привлекательным,
но в нем заложена возможность столкновений с вероятностью 100%.
Алгоритмы Б и В более устойчивы в отношении этой проблемы.
Следующим по популярности после CSMA/CD является мар-
керный доступ (Token Ring, ArcNet и FDDI), который более гибок и
обеспечивает приоритетную иерархию обслуживания. Массовому его
внедрению препятствует сложность и дороговизна. Хотя региональ-
ные сети имеют самую разнообразную топологию, практически все-
гда они строятся на связях точка-точка.
В таблице 4.1 представлены сводные данные по основным ви-
дам локальных сетей, используемых в настоящее время.
Приведенная таблица не может претендовать на полноту. Так
сюда не вошла сеть IBM DSDB, разработанная в начале 80-х годов.
°лоса пропускания сети составляет 64 Мбит/с. Эта сеть рассчита-
ла на обслуживания процессов реального времени. Сеть имеет топо-
логию шины с приоритетным доступом (длина шины до 500 м).
Таблица 4.1. Параметры различных локальных сетей
Название сети Топология Быстро- действие Мбит/с Доступ Тип кабеля NEXT при макс, частоте [дб] Размер сети (сегмента) Макс, число узлов
10BASE5 шина 10 CSMA/CD RG-8 (50 Ом) 500м 1024
10BASE2 шина 10 CSMA/CD RG-58 (50 Ом) 185 м 90
10BASE-T шина 10 CSMA/CD UTP (III; 100 Ом) 26 100 м -
10BROAD36 шина 10 CSMA/CD RG-59 (75 Ом) 3600 м 1024
100BASE-TX звезда 100 CSMA/CD UTP (V; 100 Ом) 29 200 м -
JOOBASE-FX звезда 100 CSMA/CD оптоволокно 300 м -
100BASE-T4 звезда 100 CSMA/CD UTP (III; 100 Ом) 21 200 м -
1BASE5 (StarLAN) шина/ звезда 1 CSMA/CD UTP (II) 22 400 м 1210
IEEE 802.4 шипа 1/5/10/20 маркер RG-59 (75 Ом)
ARCNET звезда 2,5/20 маркер RG-62/UTP (93 Ом) 600/125м 255
IEEE 802.5 звезда 4/16 маркер STP/UTP (150/120 Ом) 22/32 366 м 260
AppleTalk шина/звезда 0,23 CSMA/CD STP/UTP (100 Ом) 22/32 300/3000 м 32 на сегмент
EtherTalk шина/звезда 10 CSMA/CD STP/UTP, коаксиальный кабель 500/3000 м 254/1023
ISN звезда 8,64 Шина доступа STP, оптоволокно Не огра- ничено 336/1920
PC LAN дерево,звезда 2 CSMA/CD RG-59 (75 Ом), UTP/STP 32/22 2000 72
Hypcrchannel шина 50 CSMA/CD RG-59, оптоволокно 3500 м 256
E-Net шина 10 CSMA/CD RG-58 (50 Ом) 700 м 100
G-Net шина 1 CSMA/CD RG-58, RG-59 2000 м 100
FDDI Двойное кольцо 100 маркер оптоволокно 100км 1000
PX-NET шина/ звезда 1 маркер RG-62 (93 Ом) 7000 м 100
S-NET шина/ звезда 1 Индиви- дуальный STP(100 Ом) 21 700 м 24
WANGNET двойное дерево 10 CSMA/CD RG-59 (75 Ом) 2800 м 65000
132 Глава 4
Сети передачи данных. Метод доступа
133
Коммуникационная шина логически делится на три магистрали:
сигнальная - для реализации приоритетного доступа; лексемная
шина для резервирования в буфере места назначения; и, наконец,
коммуникационная шина для передачи данных. Каждая из ука-
занных магистралей использует идеологию независимых времен-
ных доменов, границы которых синхронизованы для всех трех ма-
гистралей. Схема доступа сходна с описанной для сетей CAN (см.
раздел 4.1.4).
1. Узел, пытающийся получить доступ к одной из магистралей,
выдает свой физический адрес и приоритет сообщения бит за битом.
2. При этом узел мониторирует состояние магистрали, проверяя,
соответствует ли уровень сигнала тому, что он передает.
З.Если имеет место совпадение, передается следующий бит и
осуществляется процедура пункта 2. При несовпадении узел преры-
вает передачу, возвращается к пункту 2 и ждет следующего цикла.
Данная схема доступа исключает столкновения, характерные для
CSMA. Именно это преимущество делает сеть применимой для за-
дач реального времени.
Существует целое семейство методов доступа, исключающих стол-
кновение: это мультиплексирование по времени (TDM) и по частоте
(FDM). Здесь каждому клиенту выделяется определенный времен-
ной домен или частотный диапазон. Когда наступает его временной
интервал и клиент имеет кадр (или бит), предназначенный для от-
правки, он делает это. При этом каждый клиент ждет в среднем N/
2 временных интервалов (предполагается, что работает N клиентов).
При FDM передача не требует ожидания. Но в обоих случаях вре-
менные интервалы или частотные диапазоны используются клиен-
том по мере необходимости и могут заметное время быть не заняты
(простаивать). Такие протоколы доступа часто используются в мо-
бильной связи.
Интересной разновидностью Ethernet является широкополосная
сеть типа Net/One. Она может базироваться на коаксиальном кабе-
ле (суммарная длина до 1500м) или на оптическом волокне (полная
длина до 2500м). Эта сеть по многим характеристикам аналогична
обычному Ethernet (CSMA/CD) за исключением того, что коммуника-
ционное оборудование передает данные на одной частоте, а принимает
— на другой. Для каждого канала выделяется полоса 5 Мбит/с (по-
лоса пропускания 6МГц соответствует телевизионному стандарту).
Предусматривается 5 передающих (59,75-89,75 МГц) и 5 принима-
ющих (252-282 МГц) каналов для каждого из сетевых сегментов.
Частота ошибок (BER) для сети данного типа меньше 10 8.
134
Гпава 4
Другой Ethernet-совместимой сетью является Fibercom Whispemet.
Сеть имеет кольцевую структуру (до 8км), полосу пропускания
10Мбит/с, число узлов до 100 на сегменте при полном числе узлов
в сети - 1024. Число кольцевых сегментов может достигать 101.
Максимальное межузловое расстояние - 2км.
Примером нетрадиционного типа сети может служить Localnet
20 (Sytek). Сеть базируется на одном коаксиальном кабеле и имеет
полную полосу пропускания 400 МГц. Сеть делится на 120 кана-
лов, каждый из которых работает со скоростью 128 Кбит/с. Кана-
лы используют две ЗбМГц-полосы, одна для передачи, другая для
приема. Каждый из коммуникационных каналов занимает ЗООКГц
из 36МГц. Сеть использует алгоритм доступа CSMA/CD, что позво-
ляет подключать к одному каналу большое число сетевых устройств.
Предусматривается совместимость с интерфейсом RS-232. Частота
ошибок в сети не более 108.
Фирма Дженерал Электрик разработала сеть GM (МАР-шина),
совместимую со стандартом IEEE 802.4. Целью разработки было
обеспечение совместимости с производственным оборудованием раз-
личных компаний. Сеть рассчитана на работу со скоростями 1, 5 и
50 Мбит/с.
Традиционные сети и телекоммуникационные каналы образуют
основу сети - ее физический уровень. Реальная топология сети мо-
жет динамически изменяться, хотя это и происходит обычно неза-
метно для участников. При реализации сети используются десятки
протоколов. В любых коммуникационных протоколах важное зна-
чение имеют операции, ориентированные на установление связи
(connection-oriented) и операции, не требующие связи (connectionless
— «бессвязные», ISO 8473). Интернет использует оба типа опера-
ций. При первом типе пользователь и сеть сначала устанавливают
логическую связь и только затем начинают обмен данными. При-
чем между отдельными пересылаемыми блоками данных (пакета-
ми) поддерживается некоторое взаимодействие. «Бессвязные» опе-
рации не предполагают установления какой-либо связи между
пользователем и сетью (например, протокол UDP) до начала обме-
на. Отдельные блоки передаваемых данных в этом случае абсолют-
но независимы и не требуют подтверждения получения. Пакеты
могут быть потеряны, задублированы или доставлены не в порядке
их отправки, причем ци отправитель, ни получатель не будут об
этом оповещены. Именно к этому типу относится базовый прото-
кол Интернет — IP.
Для каждой сети характерен свой интервал размера пакетов.
Среди факторов, влияющих на выбор размеров можно выделить
Сети передачи данных. Метод доступа
135
Аппаратные ограничения, например размер домена при мульти-
плексировании по времени.
Операционная система, например размер буфера 512 байт.
Протокол (например, число бит в поле длины пакета).
Обеспечение совместимости с определенными стандартами.
Желание уменьшить число ошибок при передаче ниже заданно-
го уровня.
Стремление уменьшить время занятости канала при передаче
пакета.
Ниже приведены максимальные размеры пакетов (MTU) для ряда
сетей
Сеть MTU, Байт Быстродействие, Мбит/с
IEEE 802.3 1500 10
IEEE 802.4 8191 10
IEEE 802.5 5000 4
Операции, ориентированные на установление связи (например, про-
токол TCP), предполагают трехстороннее соглашение между двумя
пользователями и провайдером услуг. В процессе обмена они хранят
необходимую информацию друг о друге, с тем, чтобы не перегружать
вспомогательными данными пересылаемые пакеты. В этом режиме
обмена обычно требуется подтверждение получения пакета, а при
обнаружении сбоя предусматривается механизм повторной передачи
поврежденного пакета. «Бессвязная» сеть более надежна, так как
она может отправлять отдельные пакеты по разным маршрутам, об-
ходя поврежденные участки. Такая сеть не зависит от протоколов,
используемых в субсетях. Большинство протоколов Интернет ис-
пользуют именно эту схему обмена. Концептуально TCP/IP-сети пред-
лагают три типа сервиса в порядке нарастания уровня иерархии:
1. «бессвязная» доставка пакетов;
2. надежная транспортировка информации;
3. реализация прикладных задач.
Немногие из читателей участвуют в создании региональных и
тем более глобальных сетей, за-то структура и принципы построе-
ния локальных сетей им безусловно, близки. На рис. 4.4 и 4.5
приведены два варианта «ресурсных» локальных сетей (сети для
коллективного использования ресурсов - памяти, процессоров, прин-
теров, магнитофонов и т.д.). Такие сети строятся так, чтобы пропус-
кная способность участков, где информационные потоки суммиру-
ется, имели адекватную полосу пропускания. Эффективность сети
на рис. 4.4 сильно зависит от структуры и возможностей контрол-
еров внешних устройств, от объема их буферной памяти.
136
Гпава 4
Память)
CPUJ | CPU 1
Концентраторы |
IКонтроллер! I Контроллер |
L___________J I___________ L
! i i 1
^КонтроллерJ Контроллер j
Векторный
процессор
J
Рис. 4.4. Вариант схемы ресурсной локальной сети
Сеть, показанная на рис. 4.5, несравненно более эффективна (прак-
тически исключены столкновения и легче гарантировать определен-
ное время доступа к ресурсу). Здесь также немало зависит от свойств
контроллеров внешних ресурсов (темные квадратики). Но такие сети
обычно более дорого реализовать.
Для сопоставления быстродействия различных видов сетей Стал-
лингс (Stallings, W.: Data and Computer Communications, New York:
Mac-millan Publishing Company, 1985) в 1985 году разработал кри-
терий. Критерий предполагает вычисление битовой длины BL (мак-
симальное число бит в сегменте), которая равна произведению мак-
симальной длины сегмента (L) на полосу пропускания (W), поделен-
ному на скорость распространения сигнала в сегменте (s):
Рис. 4.5.
Сети передачи данных. Метод доступа
137
BL = L*W/s
Для Ethernet BL = [500(м)*10 106(бит/с)]/2 108 (м/с) = 25 бит.
Коэффициент использования сети равен Р = 1 /(14-ос), где
BL
а =-----------
размер пакета ’
Для Ethernet при длине пакета 1500 байта ос = 0,0021, что дает
для эффективности использования сети 0,997. Таким образом, макси-
мальная пропускная способность Ethernet составляет 9,97 Мбит/с
или 1,25 Мбайт/с. Разумеется, в этом подходе не учитываются
издержки, связанные с заголовками пакетов, которые дополнитель-
но снижают эффективность сети. Из данного рассмотрения может
показаться, что чем больше пакет, тем лучше. С точки зрения про-
пускной способности так оно и есть. Но с увеличением длины паке-
та увеличивается время отклика сети. Таким образом, выбор MTU
определяется реальными требованиями пользователей.
Принципы построения сетевых программных
интерфейсов
Существует большое разнообразие сетевых интерфейсов. Их струк-
тура зависит от характера физического уровня сетевой среды; от мето-
да доступа, от используемого набора интегральных схем и т.д.. Здесь
пойдет речь о принципах построения программного интерфейса.
Существует три возможности построения интерфейса: с базиро-
ванием на памяти, с использованием прямого доступа и с примене-
нием запросов обслуживания.
Первый вариант предполагает наличие трех компонентов: буфер
сообщений, область данных для управления передачей и зона памя-
ти для управления приемом данных. Первый из компонентов слу-
жит для формирования исходящих сообщений программного ин-
терфейса. Должны быть приняты меры, чтобы исключить модифи-
кацию содержимого этого буфера до того, как данные будут считаны
ЭВМ или интерфейсом. Проблема решается путем формирования
соответствующих указателей. Управление буфером осуществляется
ЭВМ или совместно ЭВМ и интерфейсом с использованием меха-
низма семафоров.
Остальные методы связаны с использованием традиционных
методов управления памятью с помощью средств операционной сис-
темы. Критической проблемой является обеспечение достаточного
Места в буфере для приходящих сообщений. Ведь в отсутствии па-
мяти приходящее илй записанное ранее сообщение может быть по-
138
Гпава 4
теряно. Недостаток места для исходящих сообщений не является
критическим, так как приводит обычно к задержке передачи, а не к .
потере сообщения.
Второй компонент интерфейса, базирующегося на использова- :
нии памяти, часто реализуется в виде так называемых буферов уп-
равления передачей (ТСВ). Эти буферы содержат такую информа-
цию как положения сообщения в памяти, длина сообщения, адрес ;
места назначения, идентификатор процесса-отправителя, приоритет
сообщения, предельное значение числа попыток передачи, а также
флаг, указывающий на необходимость присылки подтверждения от
получателя. ТСВ (Transmission Control Buffer) создается процес-
сом-отправителем и передается интерфейсу, после завершения запи-
си в буфер сообщений. Параметры ТСВ используются интерфейсом
при организации процесса передачи сообщения.
Третий компонент интерфейса, базирующегося на использова-
нии памяти, называется буфером управления приемом (RCB - ;
Reception Control Buffer). RCB содержит в себе информацию, сход-
ную с той, что записывается в ТСВ, например, идентификатор отпра- :
вителя, длина сообщения, индикатор ошибки, время приема и идеи- j
тификатор процесса места назначения. RCB заполняется интерфей- В
сом при получении сообщения и передается процессору ЭВМ. *
Основополагающим принципом построение всех трех компонент |
является совместное использование памяти и гибкая система ука- J
зателей. Версия программы, рассмотренная в разделе 7 ближе имен- |
но к этой схеме взаимодействия.
Во втором варианте широко используемой схемы доступа к сети
(«прямой доступ») взаимодействие ЭВМ и интерфейса строится по
схеме клиент-сервер. Конкретная реализация программы в этом \
случае в большей степени зависит от структуры регистров физичес- *
кого интерфейса.
В третьем варианте сетевого программного интерфейса исполь-
зуются служебные запросы. Этот тип сетевого доступа удобен для
коммуникационных протоколов высокого уровня, таких как коман- .
ды ввода/вывода CSP-стиля (Communicating Sequential Processes) 4
или процедуры обмена языка Ада. В этом методе накладываются
определенные ограничения на реализацию нижележащих коммуни-
кационных уровней. ?
Программирование для сетей существенным образом является .
программированием для процессов реального времени. Здесь часто
можно столкнуться с тем, что одна и та же программа ведет себя по-
разному в разных ситуациях. Особое внимание нужно уделять на-
писанию многопроцессных сетевых программ, где также как в слу- |
Сети передачи данных. Метод доступа
139
чае работы с соединителями могут возникать ситуации блокировок.
Пример такой ситуации показан на рис. 4.6.
Рис. 4.6.
Когда число процессов больше, заметить запрограммированную
ситуацию блокировки заметно сложнее. По этой причине необходи-
мо предусмотреть меры препятствующие блокировке, если ожидае-
мое сообщение не пришло.
Необычайно важной проблемой при построении сетей является
их устойчивость при возникновении перегрузок. В Интернет для
этого используется специальная опция протокола ICMP, а во Frame
Relay имеются меры для преодоления перегрузок непосредственно
на нижних протокольных уровнях.
Методы работы в условиях перегрузки
Оптимальность управления сетью в условиях перегрузок опреде-
ляет эффективность использования сети. Пока субсеть загружена
незначительно, число принимаемых и обрабатываемых пакетов рав-
но числу пришедших. Однако, когда в субсеть поступает слишком
много пакетов, может возникнуть перегрузка и рабочие характерис-
тики деградируют. При очень больших загрузках пропускная спо-
собность канала или сети может стать нулевой (см. [39]) Такая
ситуация называется коллапсом сети.
Отчасти это может быть связано с недостатком памяти для
входных буферов, по этой причине некоторое увеличение памяти
может помочь. Но следует помнить, что всякое лекарство хорошо в
МеРУ. Еще в 1987 году Нагле (Nagle) обнаружил, что если маршру-
тизатор имеет даже беспредельную память, эффект перегрузки мо-
Жет оказаться еще более тяжелым. Это сопряжено со временем,
к°торые пакеты ожидают обработки. Если время ожидания в очере-
140
Гпава 4
ди превышает длительность таймаута, появятся дубликаты пакетов,
что безусловно понижает эффективность системы. Причиной пере-
грузки может быть медленный процессор или недостаточная про-
пускная способность какого-то участка сети. Простая замена про-
цессора или интерфейса на более быстродействующий не всегда ре-
шает проблему — чаще переносит узкое место в другую часть системы.
Перегрузка, как правило, включает механизмы, усиливающие ее не-
гативное воздействие. Так переполнение буфера приводит к потере
пакетов, которые позднее должны будут переданы повторно (воз-
можно даже несколько раз). Процессор передающей стороны полу-
чает дополнительную паразитную загрузку. Все это указывает на
то, что контроль перегрузки является крайне важным процессом.
Следует делать различие между контролем потока и контролем
перегрузки. Под контролем потока подразумевается балансировка
потока отправителя и возможности приема и обработки получате-
ля. Этот вид контроля предполагает наличие обратной связи между
получателем и отправителем. В этом процессе участвуют, как пра-
вило, только два партнера. Перегрузка же более общее явление, от-
носящееся к сети в целом или к какой-то ее части. Например, 10
ЭВМ хотят передать одновременно какие-то файлы другим 10 ЭВМ.
Конфликта потоков здесь нет, каждая из ЭВМ способна перерабо-
тать поступающие данные, но сеть не может пропустить поток, гене-
рируемый 10 сетевыми интерфейсами одновременно. Часто эти яв-
ления не так просто разделить. Отправитель может получить сооб-
щение ICMP(quench) (в случае TCP/IP) при перегрузке получателя
или при перегрузке какого-то сегмента сети.
Начинать надо с решения проблемы выявления перегрузок. Пе-
регрузкой следует считать ситуацию, когда нагрузка в течение неко-
торого оговоренного времени превышает заданную величину. Пара-
метрами, которые позволяют судить о наличии перегрузки могут
служить:
• процент пакетов, отбрасываемых из-за отсутствия свободного
буферного пространства.
• средняя длина очереди
• процент пакетов, пересылаемых повторно
• среднее время задержки пакета и некоторые другие величины ♦
Перегрузка выявлена, нужно передать необходимую информа-
цию из точки, где она обнаружена, туда, где можно что-то сделать
для исправления ситуации.
Можно послать уведомление о перегрузке отправителю, загружая
дополнительно и без того перегруженный участок сети. Альтерната-;
вой этому может быть применение специального поля в пакете, куда ?
Сети передачи данных. Метод доступа
маршрутизатор может записать соответствующий код при перегруз-
ке, и послать его соседям. Можно также ввести специальный про-
цессор или маршрутизатор, который рассылает периодически запро-
сы о состоянии элементов сети. При получении оповещения о пере-
грузки информационный поток может быть послан в обход.
При использовании обратной связи путем посылки сообщения-
запроса понижения скорости передачи следует тщательно настраи-
вать временные характеристики. В противном случае система либо
попадает в незатухающий осциллятивный режим, либо корректиру-
ющее понижение потока будет осуществляться слишком поздно.
Для корректного выбора режима обратной связи необходимо неко-
торое усреднение.
Преодоление перегрузки может быть осуществлено понижением
нагрузки или добавлением ресурсов приемнику.
Положительный результат может быть достигнут изменением
механизма подтверждения (например, уменьшение размера окна),
вариацией значений таймаутов, вариацией политики повторной пе-
редачи пакетов. В некоторых случаях позитивного результата мож-
но достичь изменением схемы буферизации. Иногда решить про-
блему может маршрутизатор, например, перераспределяющий тра-
фик по нескольким путям.
Одной из причин перегрузки часто являются импульсные загруз-
ки сегмента сети или сетевого устройства. По этой причине любые
меры (напр., pipelining), которые могут выравнивать поток пакетов,
безусловно, улучшат ситуацию (например, traffic shaping в сетях ATM).
В TCP же с его окнами импульсные загрузки предопределены.
Алгоритм leaky bucket («дырявое ведро»)
Для систем без обратной связи решение проблемы выравнива-
ния скорости передачи данных может быть решено с помощью ал-
горитма leaky bucket. Суть этого алгоритма заключается в том, что
на пути потока устанавливается буфер, выходной поток которого
постоянен и согласован с возможностью приемника. Если буфер
переполняется, пакеты теряются. Потеря пакетов вещь мало прият-
ная, но это блокирует процессы, которые могут привести к коллапсу
сегмента или всей сети. Там где потеря пакетов нежелательно, можно
применить более гибкий алгоритм.
Алгоритм («маркерное ведро»)
Алгоритм token bucket предполагает наличие в буферном уст-
ройстве (или программе) некоторого количества маркеров. При по-
ступлении на вход буфера пакетов маркеры используются для их
142
Гпава 4
транспортировки на выход. Дальнейшая передача данных на выход
зависит от генерации новых маркеров. Поступающие извне пакеты
тем временем накапливаются в буфере. Таким образом, полной
гарантии отсутствия потерь мы не имеем и здесь. Но алгоритм
token bucket позволяет передавать на выход «плотные» группы па-
кетов ограниченной численности (по числу маркеров), снижая в не- i
которых случаях вероятность потери. Если буферное устройствоj
«смонтировано» внутри ЭВМ-отправителя, потерь можно избежать;
вовсе, блокируя передачу при заполнении буфера. Как в одном, так!
и в другом алгоритме мерой передаваемой информации может быть ?
не пакет, а n-байт (где п некоторое оговоренное заранее число). |
В системах, где управление трафиком осуществляется с исполь-1
зованием обратной связи, можно достичь большей эффективности. |
Одним из механизмов преодоления перегрузок является управ ле-1
ние разрешением (admission control). Суть метода заключается в!
том, что при регистрации перегрузки не формируется более никаких ;
виртуальных соединений до тех пор пока ситуация не улучшится. -
Альтернативным вариантом может служить решение, где формиро-^
вание нового соединения разрешается, но при этом осуществляетсяi
маршрутизация так, чтобы обойти узлы, в которых выявлена пере-1
грузка (смотри рис. 4.7). I
На рис. 4.7 (верх) показан пример сети с двумя узлами, характе-;
ризующимися перегрузкой (помечены красным цветом). Предполо-t
Рис. 4.7. Выбор маршрута нового виртуального канала
при наличии перегрузки
Сети передачи данных. Метод доступа
143
жим, что необходимо проложить виртуальный канал из узла А в
узел Б. Из графа маршрутов удаляются перегруженные узлы, после
чего осуществляется прокладка пути. В нижней части рисунка по-
казан новый виртуальный канал.
Еще более универсальным решение, пригодным для работы с
установлением соединения и без, является посылка пакетов блоки-
ровки (choke Packets). Маршрутизатор обычно контролирует загру-
женность всех своих внешних каналов L, которая может принимать
значения от 0 до 1. Когда L достигаем некоторого порогового значе-
ния, отправителю посылается пакет блокировки. При вычислении L
следует использовать какую-либо методику усреднения, чтобы избе-
жать слишком частых блокировок.
Когда отправитель получает пакет блокировки, он должен умень-
шить трафик, посылаемый получателю на заданное число процен-
тов. Так как на пути к месту назначения может быть много паке-
тов, это вызовет серию пакетов блокировки. Отправитель должен
игнорировать пакеты блокировки в течение некоторого времени после
получения первого такого пакета. По истечении этого периода от-
правитель прослушивает канал на протяжении аналогичного вре-
мени, ожидая получения новых пакетов блокировки. Если такой
пакет приходит, канал все еще перегружен и отправитель снова
должен понизить темп посылки пакетов. Если на протяжении пе-
риода прослушивания не приходит новых пакетов блокировки, от-
правитель может увеличить поток снова.
ЭВМ может понижать трафик, корректируя свои параметры, на-
пример, ширину окна или темп передачи на выходе устройства типа
«дырявое ведро». Обычно первый блокирующий пакет уменьшает
поток вдвое, следующий на 0,25 и т.д. Увеличение потока также
производится аналогичными шагами. Существует большое число
вариантов алгоритма управления потоком с использованием паке-
тов блокировки. Параметром, который контролируется и определя-
ет условие отправки пакета блокировки, может служить длина оче-
реди или заполненность буфера.
Ситуация перегрузки не всегда управляется однозначно. Напри-
мер, при поступлении на вход пакетов от трех источников возможна
ситуация, когда приемник посылает блокирующие пакеты всем от-
правителям, а откликнется сокращением потока только один. В
Результате этот узел, который «играет по правилам» (как это часто
бывает и в жизни) оказывается в проигрыше. В 1987 году Наглем
был предложен алгоритм fair queuing (честная очередь). В этом
алгоритме маршрутизатор организует независимые очереди для па-
кетов, поступающих от разных источников. Когда выходной канал
144
Гпава 4
маршрутизатора оказывается свободным, он просматривает очереди
циклически и отравляет очередной пакет. В результате при п очере-
дях по завершении такого цикла просмотров-посылок будет посла-
но по одному пакету из каждой очереди. Этот алгоритм использу-
ется в некоторых ATM-переключателях. Следует заметить, что этот
алгоритм дает некоторые преимущества тем узлам, которые посы-
лают более длинные пакеты. Демерс (Demers) и др. в 1990 году
предложил некоторое усовершенствование алгоритма. В данном
варианте организуется циклический просмотр очередей не по-пакет-
но, а побайтно. Система последовательно сканирует очереди и опре-
деляет положение концов пакетов. Первыми отправляются более
короткие пакеты. Для иллюстрации предлагается рассмотреть рис.
4.8. (см. также [39]).
Пакеты на рисунке имеют от трех до девяти октетов. Порядок
пересылки октетов показан в левой части рисунка. В отсутствии
поступления новых пакетов, кадры, записанные в буфер, будут пере-
даны в порядке, представленном в правой части рисунка. Особенно-
стью этого алгоритма является равенство приоритета всех входных
каналов.
При передаче данных на большие расстояния с большими значе-
ниями RTT эффективность использования метода блокирующих
пакетов снижается. Пока блокирующий пакет дойдет через ряд про-
межуточных узлов до отправителя, на вход получателя поступит
большое число пакетов, которые не только усугубят ситуацию пере-
грузки, но и могут вызвать потерю какой-то их доли, что, в свою
очередь, может потребовать повторной пересылки следовавших за
ними кадров. Для повышения эффективности часто применяется
Рис. 4.8. Маршрутизатор с 4-мя входными каналами, в каждом из
которых ждет очереди передачи по одному пакету. В правой части
рисунка представлен порядок посылки этих пакетов.
Сети передачи данных. Метод доступа
145
схема, при которой блокирующие пакеты воздействуют на все мар-
шрутизаторы по пути своего следования. В этом случае снижения
потока можно ожидать уже через время, равное RTT до узла, бли-
жайшего к получателю пакетов. Такая схема требует того, чтобы
все промежуточные узлы имели достаточно емкие буферы, в против-
ном случае возможны потери.
В протоколе TCP используется алгоритм управления трафиком,
называемый «скользящее окно». Здесь размер окна, которое опреде-
ляет число сегментов, посылаемых без получения подтверждения,
варьируется в зависимости от наличия потерь пакетов. При боль-
шой вероятности потери система переходит в режим, когда очеред-
ной пакет не посылается до тех пор, пока не будет подтверждено
получение предшествующего. При серьезных перегрузках, когда по-
тери становятся значительными, нарушается механизм вычисления
значений RTT и таймаутов, что может приводить к трудно предска-
зуемым последствиям. Следует обратить внимание, что в протоколе
UDP какого-либо механизма управления трафиком не предусмот-
рено. По этой причине для мультимедийных задач, следует предус-
матривать другие, например, ICMP-способы подавления перегрузки.
Если другие способы испробованы, а перегрузка не исчезла, мар-
шрутизатор начинает отбрасывать приходящие пакеты, которые уже
не может обработать. Самое простое — это предоставить случаю
выбор отбрасываемых пакетов. Но это не лучшая тактика. В слу-
чае пересылки мультимедийных данных предпочтение следует де-
лать для последних полученных пакетов, а «старые» пакеты выбра-
сывать. При передаче файлов наоборот «старый» пакет имеет при-
оритет, ведь если его отбросить, придется повторно передавать не
только его, но и все последующие пакеты. Некоторые методы пере-
дачи изображения требуют передачи время от времени всего кадра с
последующей пересылкой только фрагментов, где произошли изме-
нения. В таких условиях потеря пакета, составляющего базовый
кадр, менее предпочтительна. Сходные обстоятельства могут возни-
кать и в других приложениях. Можно помечать пакеты, присваивая
им определенные уровни приоритетов, что позволит осознанно при-
нимать решение об отбрасывании того или иного пакета в условиях
перегрузки. В перспективе проблема может быть решена на чисто
коммерческой основе — компонента трафика, помеченная как высо-
ко приоритетная, будет оплачиваться по более высокому тарифу. В
некоторых сетях некоторое количество пакетов объединяется в груп-
ПЬ1, образующие сообщение. Если одна ячейка такого сообщения
выброшена, все сообщение будет повторно переслано (смотри, напри-
МеР, адаптационные уровни сетей ATM).
146
Гпава 4
4.1. Локальные сети (LAN)
В этом разделе речь идет о физической среде локальных сетей.
4 Л Л. Ethernet (IEEE 802.3)
Сеть Ethernet разработана в 1976 году Меткальфом и Боггсом
(фирма Ксерокс). Ethernet совместно со своей скоростной версией
Fast Ethernet занимает в настоящее время абсолютно лидирующую
позицию (а на подходе еще и гигабитный Ethernet). Единственным
недостатком данной сети является отсутствие гарантии времени
доступа к среде (и механизмов, обеспечивающих приоритетное об-
служивание), что делает сеть малоперспективной для решения тех-
нологических проблем реального времени.
4.1.1.1. Архитектура сетей Ethernet
Не трудно видеть, что все перечисленные физические среды ис-
пользуют последовательный формат передачи информации. К этой
разновидности относится и Ethernet (10 Мбит/с ±0,01%). Фирма
Ксерокс осуществила разработку протокола Ethernet в 1973 году, а
в 1979 году объединение компаний Ксерокс, Интел и DEC (DIX)
предоставило документ для стандартизации протокола в IEEE. Пред-
ложение с небольшими изменениями было принято комитетом 802.3
в 1983 году. Кадр Ethernet имеет формат, показанный на рис.
4.1.1.1.1.
Поле преамбула содержит 7 байт ОхАА и служит для стабили-
зации и синхронизации среды (чередующиеся сигналы CD1 и CD0
при завершающем CD0), далее следует поле SFD (Start Frame Delimiter
= ОхАВ), которое предназначено для выявления начала кадра. Поле
EFD (End Frame Delimiter) задает конец кадра. Поле контрольной
суммы (CRC — Cyclic Redundancy Check), также как и преамбула,
SFD и EFD, формируются и контролируются на аппаратном уровне.
В некоторых модификациях протокола поле EFD не используется.
7 1 6 6 2 4 1
Преамбула SFD Адрес получателя Адрес отправителя Протокол или Тип Информация до 1500 байт CRC EFD
Рис. 4.1.1.1.1. Формат кадра сетей Ethernet
(цифры в верхней части рисунка показывают размер поля а байтах]
Сети передачи данных. Метод доступа
147
Пользователю доступны поля, начиная с адреса получателя и кон-
чая полем информация, включительно. После CRC следует межпа-
кетная пауза (IPG — InterPacket Gap - межпакетный интервал)
длиной 9,6 мксек или более. Максимальный размер кадра равен
1518 байт (сюда не включены поля преамбулы, SFD и EFD). Интер-
фейс просматривает все пакеты, следующие по кабельному сегменту,
к которому он подключен, ведь определить, корректен ли принятый
пакет и кому он адресован, можно лишь приняв его целиком. Кор-
ректность пакета по CRC, по длине и кратности целому числу байт
производится после проверки адреса места назначения. Вероятность
ошибки передачи при наличии CRC контроля составляет ~2‘32. При
вычислении CRC используется образующий полином:
G(x) = х32 + х26 + х23 + х22 + х16 4- х12 4- х11 4- х10 4-х84-х74-х5 +
+ х4 + х2 + х + 1.
Алгоритм вычисления CRC сводится к вычислению остатка от
деления кода М(х), характеризующего кадр, на образующий поли-
ном G(x) (Carrier Sense Multi pie Access with Collision detection Access
Method and Physical Layer Specification. Published by IEEE 802.3-
1985. Wiley-Interscience, John & Sons, Inc.). CRC представляет со-
бой дополнение полученного остатка R(x). CRC пересылается, на-
чиная со старших разрядов. Схема взаимодействия различных су-
буровней при реализации протокола IEEE 802.3 показана на рис
4.1.1.1.2. Выше LLC размещаются верхние субуровни, включая
прикладной. Через АШ данные передаются с использованием ман-
честерского кода.
Манчестерский код объединяет в бит-сигнале данные и синхро-
низацию. Каждый бит-символ делится на две части, причем вторая
часть всегда является инверсной по отношению первой. В первой
половине кодируемый сигнал представлен в логически дополнитель-
ном виде, а во второй - в обычном. Таким образом, сигнал логичес-
кого 0 - CD0 характеризуется в первой половине уровнем HI, а во
второй LO. Соответственно сигнал CD1 характеризуется в первой
половине бит-символа уровнем LO, а во второй - HI. Примеры форм
сигналов при манчестерском кодировании представлены на рис.
4.1.1.1.3.
Ниже в таблице 4.1.1.1.1 приведены ограничения, налагаемые
на сеть Ethernet в целом и на отдельные ее фрагменты.
Из таблицы видно, что максимальная задержка в сети Ethernet
складывается из:
148
Гпава 4
Рис. 4.1.1.1.2. Схема взаимодействия субуровней 802.3
(CSMA/CDJ
к 1 бит-Н
I____I____I____I—J_______I____I_____
Закодирована последовательность чередующихся CD0 и CD1
0 110 110
Закодирована произвольная информация
Рис. 4.1.1.1.3 Примеры кодировки с использованием
манчестерского кода
Сети передачи данных. Метод доступа
149
Таблица 4.1. 4. 1.1. Возможности различных схем
реализации Ethernet
Тип кабеля Толстый (10Base5) Тонкий (10Base2) Скрученная пара (lOBaseT)
Максимальная длина сети (м) 2500 900 -
Максимальная длина кабельного сегмента (м) 500 185 100
Максимальное число подключений к сегменту 100 30 1
Минимальное расстояние между точками подключения (м) 2.5 0.5 -
Максимальное удаление узлов 5 сегментов и 4 повто- рителя 5 сегментов и 4 повто- рителя 5 сегментов и 4 повто- рителя
1.4*TR (задержка, вносимая повторителями, при их максималь-
ном числе =4; TR — задержка сигнала в репитере, -20 бит-тактов)
2.4,5 нсек/м*5*500м (задержка пяти кабельных сегментов)
3.4 нсек/м*2*50м (задержка, вносимая двумя кабелями AUI,
первого и последнего сегментов)
4. задержки сетевых интерфейсов и трансиверов (-2*20 бит-тактов)
В сумме это соответствует -220 бит-тактам. Минимальная дли-
на пакета должна быть больше удвоенного значения этой задержки
(выбрано 64 байта = 512 тактов). Если размер пакета меньше 64
байт, добавляются байты-заполнители, чтобы кадр в любом случае
имел соответствующий размер. При приеме контролируется длина
пакета и, если она превышает 1518 байт, пакет считается избыточ-
ным и обрабатываться не будет. Аналогичная судьба ждет кадры
короче 64 байт. Любой пакет должен иметь длину, кратную 8 бит
(целое число байт). Если в поле адресата содержатся все единицы,
адрес считается широковещательным, то есть обращенным ко всем
рабочим станциям локальной сети. Пакет Ethernet может нести от
46 до 1500 байт данных. Формат адреса получателя или отправите-
ля (МАС) показан на рис. 4.1.1.1.4. Для передачи данных на фи-
зическом уровне используется манчестерский код.
1 1 ◄ 22 ► ◄ 24 ►
I/G U/L OUI Адрес (OUA)
47 46 45 0
Рис. 4.1.1.1.4. Формат МАС~адреса
150
Гпава 4
В верхней части рисунка указана длина полей адреса, в нижней i
- нумерация разрядов. Субполе I/G представляет собой флаг инди-
видуального или группового адреса. I/G=O - указывает на то, что
адрес является индивидуальным адресом сетевого объекта. I/G=l 4
характеризует адрес как мультикастинговый, в этом случае даль-
нейшее разбиение адреса на субполя теряет смысл. Субполе U/L
является флагом универсального или местного управления (опре- ,
деляет механизм присвоения адреса сетевому интерфейсу). U/L=l
указывает на локальную адресацию (адрес задан не производителем
и ответственность за уникальность лежит на администраторе LAN). *
U/L=I/G=0 характерно для стандартных уникальных адресов, при-
сваиваемых интерфейсу его изготовителем. Субполе ОШ (Organiza-
tionally Unique Identifier) позволяет определить производителя сете-
вого интерфейса. Каждому производителю присваивается один или ‘
несколько OUI. Размер субполя позволяет идентифицировать около *
4 миллионов различных производителей. За корректность присвое-
ния уникального адреса интерфейса (OUA - Organizationally Unique <
Address) несет ответственность производитель. Двух интерфейсов ;
одного и того же производителя с идентичными номерами не долж- |
но существовать. Размер поля позволяет произвести примерно 16 ?
миллионов интерфейсов. Комбинация OUI и OUA составляют UAA
(Universally Administrated Address = IEEE-адрес).
Если в поле кадра протокол/тип записан код менее 1500, то |
это поле характеризует длину кадра. В противном случае - это код j
протокола, пакет которого инкапсулирован в кадр Ethernet. f
Доступ к каналу Ethernet базируется на алгоритме CSMA/CD
(Carrier Sense Multiple Access with Collision Detection). В Ethernet
любая станция, подключенная к сети, может попытаться начать
передачу пакета (кадра), если кабельный сегмент, к которому она ,
подключена, свободен. Свободен ли сегмент, интерфейс определяет |
по отсутствию «несущей» в течение 9,6 мксек. Так как первый бит
пакета достигает остальных станций сети не одновременно, может '
случиться, что попытку передачи совершат две или более станций, л
тем более что задержки в повторителях и кабелях могут достигать |
достаточно больших величин. Такие совпадения попыток называ-
ются столкновениями. Столкновениё (коллизия) распознается по «
наличию в канале сигнала, уровень которого соответствует работе
двух или более трансиверов одновременно. При обнаружении стол-
кновения станция прерывает передачу. Возобновление попытки мо- ;
жет быть произведено после выдержки (кратной 51,2 мксек, но не|
превосходящей 52 мсек), значения которой является псевдослу-
чайной величиной и вычисляется каждой станцией независимо
Сети передачи данных. Метод доступа
151
(Т= RAND(0,2min(N10)), где N - содержимое счетчика попыток, а чис-
ло 10 — backoff Limit).
После выдержки станция увеличивает на единицу счетчик по-
пыток и начинает очередную передачу. Предельное число попыток
по умолчанию равно 16, если число попыток исчерпано, связь пре-
рывается и выдается соответствующее сообщение. Передаваемый
длинный кадр способствует «синхронизации» начала передачи па-
кетов несколькими станциями. Ведь за время передачи с заметной
вероятностью может возникнуть необходимость передачи у двух и
более станций. В момент, когда они обнаружат завершение пакета,
будут включены таймеры IPG. К счастью информация о заверше-
нии передачи пакета доходит до станций сегмента не одновременно.
Но задержки, с которыми это связано, являются также причиной
того, что факт начала передачи нового пакета одной из станций не
становится известным немедленно. При вовлечении в столкновение
нескольких станций они могут уведомить остальные станции об этом,
послав сигнал «затора» (JAM — не менее 32 бит). Содержимое этих
32 бит не регламентируется. Такая схема делает менее вероятным
повторное столкновение. Источником большого числа столкновений
(помимо информационной перегрузки) может служить запредельная
суммарная длина логического кабельного сегмента, слишком боль-
шое число повторителей, обрыв кабеля, отсутствие терминатора (50-
омного согласователя кабеля) или неисправность одного из интер-
фейсов. Но сами по себе столкновения не являются чем-то негатив-
ным - это механизм, регулирующий доступ к сетевой среде.
Под логическим кабельным сегментом (иногда называемым об-
ластью столкновений) подразумевается один или несколько кабель-
ных сегментов, объединенных повторителями. Анализ столкновений
является одним из средств эффективной диагностики сети. Локаль-
ные столкновения (столкновения на сегменте, к которому непосред-
ственно подключена рабочая станция) порождают укороченные паке-
ты-фрагменты (ведь их передача прерывается) с длиной менее 64 окте-
тов. Большинство трансиверов и репитеров имеют на своих передних
панелях индикаторы столкновений. Блок-схема реализации протоко-
ла CSMA/CD показана на рис. 4.1.1.1.4. Особое внимание я бы хотел
обратить на влияние сигнала JAM. В процессе пересылки столкнув-
шихся пакетов и за время передачи сигнала JAM другие узлы могли
захотеть что-то передать. Если таких узлов больше одного, то это
приведет к синхронизации начала передачи этими узлами и к увеличе-
нию вероятности столкновения. Практически такую «синхронизацию»
может осуществить любой достаточно длинный пакет. Такая синхро-
низация является причиной «коллапса» сети при большой загрузке.
152
Гпава 4
Рис. 4.1.1.7.5. Блок-схема реализации алгоритма доступа
к сетевой среде CSMA/CD
Метод CSMA/CD создает неопределенность времени доступа к
сети, что делает ее неудобной для решения некоторых задач управ-
ления в реальном масштабе времени, где требуется малое время q
реакции системы на внешнее воздействие.
Исторически первой появилась схема подключения к толстому
50-омному коаксиальному кабелю (сегмент 1 на рис. 4.1.1.1.6; Z=50
±2 Ом) через трансивер и многожильный кабель-типа AUI (Attachment
Unit Interface, максимальная длина 50 м). Трансивер подключается
к кабелю методом «наколки», то есть во внешней оплетке и изоля*
Сети передачи данных. Метод доступа
153
ции сверлится с помощью специального инструмента отверстие и
через него осуществляется контакт трансивера с центральной жи-
лой кабеля и экраном. Кабель по возможности не должен содер-
жать сросток, в противном случае его предельная длина должна
быть сокращена. Кабельный сегмент должен быть согласован с обе-
их сторон с помощью терминаторов (50 Ом ±1%). Позднее стала
популярной схема соединений через тонкий коаксиальный кабель и
Т-образные коаксиальные разъемы (волновое сопротивление 50 Ом).
В настоящее время наибольшее применение находит схема со спе-
циальными многовходовыми повторителями-концентраторами (Hub)
и подключением оконечного оборудования через скрученные пары.
Для подключения используется 8-контактный разъем RJ-45. Это-
му способствует удешевление категорированных скрученных пар,
соответствующих повторителей, а также большая надежность и луч-
шая ремонтоспособность таких сетей. Следует иметь в виду, что
предельные длины для коаксиальных кабелей, приведенные в таб-
лице 4.1.1.1.1 относятся к зарубежным типам, в частности в слу-
чае тонкого кабеля — это RG-58. Отечественные разновидности
кабеля, например РК-50-2-11, допускают (при максимальной заг-
рузке) длины примерно в 1,3-1,5 раз меньше. Это связано с мень-
Трансивер i lj Трансивер
Рис. 4 Л Л .1.6. Схема некоторых возможных вариантов
подключения рабочих станций к Ethernet
____Терминатор
'—-]
Терминальный
адаптер
АШкабели
154
Гпава 4
шим сечением центральной жилы и большей вариацией волнового
сопротивления. Если же число ЭВМ подключенных к кабельному
сегменту много меньше предельного, допускается использование и
запредельных длин кабельных сегментов, но это не рекомендуется.
Пропускная способность сети с методом доступа CSMA/CD снижа-
ется по мере роста загрузки из-за увеличения вероятности столкно-
вений. По этой причине даже использование 100-мегагерцного
Ethernet не может гарантировать большей пропускной способности
(по сравнению с обычным, см. рис. 4.1.1.1.8) при условии высоких
загрузок и, как следствие, высоких вероятностей столкновений.
Ethernet-интерфейс перед началом передачи контролирует состоя-
ние кабельного сегмента (наличие несущей), выжидает некоторое
время, если сегмент занят, после чего производит попытку передачи
с контролем возможности столкновения.
Если в поле адресата содержатся все единицы, адрес считается
широковещательным, то есть обращенным ко всем рабочим стан-
циям локальной сети. Схема интерфейса на уровне MAU в упро-
щенном виде имеет вид, показанный на рис. 4.1.1.1.7.
Схема Signal Quality регистрирует коллизии и другие искажения
сигнала и выдает в этом случае флаг SQE (Signal Quality Error). SQE
представляет собой сигнал CS0, посылаемый от MAU к DTE (точнее
РМА к PLS, см. рис. 4.1.1.1.2). Сигнал SQE посылается MAU также
в случае завершения процесса передачи (output_idle). Узел ISOLATE .
служит для блокировки передачи данных в сетевую среду, при этом
DTE передает MAU сигнал CS0. Суммарная емкостная нагрузка, вно-:
симая MAU, не должна превышать 4 пф. Входное сопротивление ;
Выход управления i
Вход управления----
Вход данных —
Выход данных ------------
ISOLATE J
Отключить •
___________I
Сетевая среда
! SIGNAL
| QUALITY
: Качество
I сигнала
Рис. 4.1.1/1.7. Схема интерфейса на уровне MAU
q6Th передачи данных. Метод доступа
155
должно быть более 100 кОм, а ток утечки должен лежать в преде-
лах +2 мкА -25мкА. Выходной драйвер MAU при передаче выдает
в кабель -90 ± 4 мА (эквивалентно -2,05 В на нагрузке 25 Ом).
Предельное ослабление сигнала на длине 500 м не должно превы-
шать 8,5 дБ (на частоте 10 МГц).
При передаче сигнал распространяется в обоих направлениях по
кабелю от точки подключения интерфейса. При использовании тон-
кого кабеля интерфейс должен иметь максимально большое вход-
ное сопротивление и минимально возможную входную емкость, что-
бы вносить минимальные искажения для сигналов, распространяю-
щихся по сегменту. В случае работы со скрученными парами на
«кабельный сегмент» подключается только один интерфейс. Мак-
симальное время прохождения сигнала между узлами сети, принад-
лежащих одному сегменту, называется окном коллизий и является
важной рабочей характеристикой.
Помимо столкновений в сети может быть зарегистрировано по-
явление ложной несущей (FCE - False Carrier Event) - битовая пос-
ледовательность не имеет байта SFD, соответствующего конкретно-
му типу физической среды. Появление ложной несущей обычно свя-
зано с состоянием кабеля или шумами. Если фиксируется появление
двух ложных несущих подряд, повторитель должен отключить порт
(перевести в состояние LINK UNSTABLE) и послать сигнал JAM
во все остальные порты. Сигнал JAM должен продолжаться до
конца потока данных, вызвавшего появление ложной несущей. Если
канал восстановлен, повторитель переводит порт в нормальное со-
стояние. Отключение порта возможно также при возникновении
множественных коллизий (ЕСЕ - Excessive Collision Error) - более
60 коллизий подряд. Цосле блокировки порта он будет восстанов-
лен, если в течении 500 тактов коллизии не обнаружены или при
повторном включении повторителя. Если рассмотреть зависимость
пропускной способности сети L от ее суммарной загрузки L.n, мы для
Ethernet получим кривую, показанную на рис. 4.1.1.1.8.
Вначале эта зависимость линейна и на участке А пропускная
способность удовлетворительна. Но при больших входных загруз-
ках из-за коллизий сначала наступает насыщение, а затем и резкий
спад (Ethernet collapse). Это свойство сетей с CSMA/CD дает опреде-
ленные преимущества сетям с маркерным доступом: Token Ring,
и др.
Помимо уже описанных модификаций сетей Ethernet в после-
^Нее время получили распространение сети для частот 100 Мбит/с,
к°торые базируются на каналах, построенных из скрученных пар
Или оптоволоконных кабелей. Оптические связи используются и в
156
Глава 4
Рис. 4.7.1.1.8. Зависимость пропускной способности Lin сети
со схемой доступа CSMA/CD от суммарной загрузки L
обычном 10-мегагерцном Ethernet (10BASE-FL, стандарт разрабо-
тан в 1980 году, см. рис. 4.1.1.1.9).
Оптоволоконная версия Ethernet привлекательна при объеди-
нении сегментов сети, размещенных в различных зданиях, при этом|
увеличивается надежность сети, так как ослабляется влияние элек-
тромагнитных наводок, исключается влияние разницы потенциалов
земли этих участков сети. Облегчается переход от 10- к 100-мега? i
герцному Ethernet, также можно использовать уже имеющиеся оп->
товолоконные каналы, ведь они будут работать и на 100 Мбит/с|
(возможна реализация сетей со смешанной структурой, где исполь<
FOMAU
RX
10BASE-FL
оптоволоконный
повторитель
ТХ
FOMAU
RX
ТХ
FOMAU
RX
К другому
(jZ оптоволоконному
повторителю
Оптоволоконные
трансиверы
сегменты
длиной до
AUI-кабель
$
Рис. 4.1.7 Л.9. Схема 1О-мегагерцного оптоволоконного Ethernet*
Сети передачи данных. Метод доступа
157
зуется как 100- так и 10-мегагерцное оборудование). На программ-
ном уровне 10- и 100-МГц Ethernet неразличимы. Требования к
параметрам оптоволоконных кабелей не зависят от используемого
протокола (FDDI, Token Ring, Fast Ethernet и т.д.) и определяются
документом EN 50173 (European Norm). Это утверждение не отно-
сится к топологии кабельных связей, которые в общем случае зави-
сят от используемого протокола. При работе с оптоволоконными
системами необходимы специальные тестеры, способные измерять
потери света и отражения методом OTDR (рефлектометрия с ис-
пользованием метода временных доменов). При пассивной звездо-
образной схеме длины оптоволоконных сегментов могут достигать
500 метров, а число подключенных ЭВМ — 33. Для передачи сигна-
лов используются многомодовые волокна (MMF) с диаметром ядра
62,5 микрон и клэдинга 125 микрон. Длина волны излучения рав-
на 850 (или 1350) нанометров при ослаблении сигнала в кабель-
ном сегменте не более 12,5 дБ. Обычный кабель имеет ослабление
4-5 дБ/км. Оптические разъемы должны соответствовать требова-
ния стандарта ISO/IEC BFOC/2,5 и вносить ослабление не более
0,5 — 2,0 дБ. Количество используемых MAU в логическом сег-
менте не должно превышать двух.
На данном рисунке видно, что соединения повторителя с FOMAU
является дуплексным, аналогичные возможности предоставляют
многие современные переключатели. Полно дуплексное подключе-
ние оборудования во многих случаях может обеспечить практичес- .
кое удвоение скорости обмена и, что возможно более важно, исклю- '
чить столкновения пакетов. Схема полно дуплексного соединения
показана на рис. 4.1.1.1.10.
Рис. 4 Л Л Л. 10. Схеме реализации полно дуплексного канала
hernet. (Буква К с цифрой отмечает номера ножек контактов разъема]
158
Глава 4
4.7.1.2 Fast Ethernet
100-мегагерцную сеть Ethernet дешевле создать на базе скручен-
ных пар. Существует несколько версий 100-мегагерцного Ethernet
(100BASE-T4, 100BASE-TX, 100BASE-FX, стандарт 100VG-AnyLAN
— IEEE 802.12).
ТХ и RX передатчики и приемники входных/выходных транси-
веров, соответственно. FOMAU — (Fiber Optic Media Attachment Unit)
оптоволоконный трансивер (см. рис. 4.1.1.1.9).
Сегменты Т4 (100BASE-T4) используют четыре скрученные пары
телефонного качества (экранированные и неэкранированные скру-
ченные пары проводов категории 3, 4 или 5) длиной до 100м. Про-
вода должны быть скручены по всей длине, скрутка может быть
прервана не далее как в 12мм от разъема (это требование справед-
ливо и для сегментов типа ТХ).
Сегменты ТХ (100BASE-TX, стандарт ANSI TP-PMD) состоят из
двух скрученных пар проводов информационного качества (волно-
вое сопротивление 100-150 Ом, экранированные и неэкранирован-
ные скрученные пары проводов категории 5, длина до 100м).
FX-сегменты (100BASE-FX) представляют собой оптоволокон-
ные кабели, отвечающие требованиям стандарта ANSI. Мультимо-
довое волокно 62,5/125ц (см. выше) работает в инфракрасном диа-
пазоне 1350нм. Максимальная длина сегмента составляет 412 мет-
’ ров, ограничение определяется соображениями допустимых задержек.
Предельное ослабление сигнала в волокне не должно превышать 11
дБ, стандартный кабель имеет 1-5 дБ/км. Оптические разъемы дол-
жны отвечать тем же требованиям, что и разъемы, используемые в
FDDI-сетях (MIC — Media Interface Connector), широкое распростра-
нение получили также разъемы типов ST и SC.
Для того, чтобы выявить, к какой модификации относится тот
или иной сегмент, разработан специальный протокол распознава-
ния, позволяющий строить сети, которые содержат оборудование и
кабельные сегменты, отвечающие разным требованиям.
Универсальная схема подключения ЭВМ или любого другого обо-
рудования (например, сетевого принтера) к 100-мегагерцному Ethernet
показана на рис. 4.1.1.2.1.
Физическая среда служит для передачи сигналов Ethernet от
одной ЭВМ к другой. Выше были перечислены три вида физических
сред, используемых 100-мегагерцным Ethernet (Т4, ТХ и FX). Здесь
используется 8-контактный разъем (RJ-45) для скрученных пар
или специальный оптоволоконный соединитель. Блок PHY выпол-
няет ту же функцию, что и трансивер в 10-мегагерцном Ethernet.
Сети передачи данных. Метод доступа 159
Он может представлять собой набор интегральных схем в сетевом
порту или иметь вид небольшой коробочки на МП-кабеле. Интер-
фейс МП является опционным, он может поддерживать работу с 10-
й ЮО-мегагерцным Ethernet. Задачей МП является преобразование
сигналов, поступающих от PHY, в форму, приемлемую для стандарт-
ного набора ИС Ethernet. Соединительный кабель не должен быть
длиннее 0,5 м. PHY и МП могут быть объединены на одной интер-
фейсной плате, вставляемой в ЭВМ.
В сетях 100-мегагерцного Ethernet используются повторители
двух классов (I и II). Задержки сигналов в повторителях класса I
больше (~ 140нс), зато они преобразуют входные сигналы в соответ-
ствии с регламентациями применяемыми при работе с цифровыми
кодами. Такие повторители могут соединять каналы, отвечающие
разным требованиям, например, 100BASE-TX и 100BASE-T4 или
100BASE-FX. Преобразование сигнала может занимать время, со-
ответствующее передаче нескольких бит, поэтому в пределах одного
логического сегмента может быть применен только один повтори-
тель класса I, если кабельные сегменты имеют предельную длину.
Повторители часто имеют встроенные возможности управления с
использованием протокола SNMP.
Повторители класса II имеют небольшие задержки (-90 нс или
даже меньше), но никакого преобразования сигналов здесь не про-
изводится, и по этой причине они могут объединять только одно-
типные сегменты. Логический сегмент может содержать не более
двух повторителя класса II, если кабели имеют предельную длину.
Повторители класса II не могут объединять сегменты разных типов,
например, 100BASE-TX и 100BASE-T4. Согласно требованиям ко-
митета IEEE время задержки сигнала JAM в повторителе Fast
Ethernet (ТХ и FX) не должно,превышать 460 нсек, а для 100BASE-
Т4 - 670 нсек. Для повторителей класса I эта задержка не должна
Рис. 4.1.1.2.1 Блок-схема подключения оборудования
к 100-мегагерцному Ethernet
160
Гпава 4
быть больше 1400 нсек. Значения предельных длин сегментов для
различных конфигураций сети приведены в таблице 4.1.1.2.1.
Таблица 4.7.7.2.7. Максимальные размеры
логического кабельного сегмента
Тин повторителя Скрученные пары, |м] Оптическое волокно, |м|
Один сегмент ЭВМ-ЭВМ 100 412
Один повторитель класса I 200 272
Один повторитель класса II 200 320
Два повторителя класса II 205 228
Типовые задержки для различных устройств Fast Ethernet пред-
ставлены в табл. 4.1.1.2.2.
Таблица 4.1.1.2.2
Сетевое ус тройство Задержка [нсек|
Повторитель класса I 700
Повторитель класса II (порты Т4 и TX/FX) 460
Повторитель класса II (все порты Т4) 340
Сетевая карта Т4 345
Сетевая карта ТХ или FX 250
Вариант построения 100-мегагерцной сети Ethernet показан на;
рис. 4.1.1.2.2.
Рис. 4.7.7.2.2. Возможная схема 100-мегагерцной сети Ethernet*
Сети передачи данных. Метод доступа
767
Из рисунка видно, что максимальная длина логического сегмен-
та не может превышать А+Б+В = 205 метров (см. табл. 4.1.1.2.3.).
Предельно допустимые длины кабелей А и В приведены в табл.
4.1.1.2.3.
Таблица 4.7. Т.2.3. Максимально допустимые длины кабелей для
сети, показанной на рис. 4.7. Т.2.2.
Тип кабеля А (категория) Тип кабеля В (категория) Класс повтори- теля Макс, длина кабеля А |м] Макс, длина кабеля В |м] Макс, диаметр сети [м]
5,4,3 (ТХ, FX) 5,4,3 (ТХ, FX) I или II 100 100 200
5 (ТХ) Оптоволокно I 100 160,8 260,8
3 или 4 (Т4) Оптоволокно I 100 131 231
Оптоволокно Оптоволокно I 136 136 272
5 (ТХ) Оптоволокно II 100 208,8 308,8
3 или 4 (Т4) Оптоволокно II 100 204 304
Оптоволокно Оптоволокно II 160 160 320
[Таблица взята из книги Лаема Куина и Ричарда Рассела Fast Ethernet, BHV, Киев, 1998.]
При работе со скрученными парами (стандарт ТХ) используется
8-контактный разъем RJ-45 со следующим назначением контактов:
Номер контакта Назначение сигнала Номер контакта Назначение сигнала
1 Передача + 5 Не используется
2 Передача - 6 Прием -
3 Прием + 7 Не используется
4 Не используется 8 Не используется
Если используются экранированные пары и 9-контактный разъем
«В»-типа, то назначение контактов следующее:
Контакт 1 Прием +
Контакт 5 Передача +
Контакт 6 Прием -
Контакт 9 Передача -
Для стандарта 100BASE-T4 назначение контактов приведено в
таблице 4.1.1.2.4.
Как видно из таблицы, одна пара предназначена для передачи
(ТХ), одна для приема (RX) и две для двунаправленной передачи
(BI). Знак полярности сигналов обозначен соответственно + и -.
Na 3430 Семенов
162 Глава 4
Таблица 4.1.1.2.4. Разъем MDI [Media Dependant Interface]
кабеля 100BASE-T4
Номер контакта Назначение сигнала Цвет провода
1 TX_D1 + (передача) Белый/оранжевый
2 TX_D1 - Оранжевый/белый
3 RX_D2 + (прием) Белый/зеленый
4 BI_D3 + (двунаправленная) Голубой/белый
5 BI_D3 - Белый/голубой
6 RXD2 - Зеленый/белый
7 BI_D4 + Белый/коричневый
8 BI_D4 - Коричневый/белый
Уровень логической единицы +3,5 В (CS1), нуля - О В (CSO), а -1
соответствует -3,5 В (CS-1). Стандарт 100BASE-T4 предполагает
применение схемы кодирования 8В6Т. Алгоритм 8В6Т преобразует 'j
октет данных в 6-битовый тернарный символ, который называется *
кодовой группой 6Т. Эти кодовые группы передаются параллельно
по трем скрученным парам сетевого кабеля, что позволяет осуще-
ствлять обмен лишь со скоростью 33,ЗЗМбит/с. Скорость же пере-
дачи тернарных символов по каждой из пар проводов равна 6/8 от *
33,33 Мбит/с, что эквивалентно 25 МГц. Шесть тернарных симво-
лов позволяют отобразить 36=729 различных кодов. Это позволяет
отобрать для отображения 256 восьмибитовых кодов те тернарные i
символы, которые обеспечивают не менее 2 перепадов уровня сигна- з
ла. Схема подключения и передачи сигналов в сетях 100BASE-T4
показана на рис 4.1.1.2.3.
Пары 2 и 3 также как и в ТХ предназначены для приема и
передачи данных. Пары 1 и 4 используются в двух направлениях,
преобразуя канал м1ежду узлом и повторителем в полудуплексный.
В процессе передачи узел использует пары 1, 2 и 4, а повторитель - 7
пары 1, 3 и 4. Следует заметить, что схема Т4, в отличие от ТХ,
может работать только в полудуплексном режиме. ;
В сетях Fast Ethernet максимальное значение окна коллизий рав-
но 5,12 мксек и называется временем канала (slot time). Это время в
точности соответствует минимальной длине пакета в 64 байта. Для
более короткого пакета коллизия может быть не зафиксирована.
Окно коллизий представляет собой время от начала передачи перво-
го бита кадра до потери возможности регистрации коллизии с лю- *
бым узлом сегмента, это время равно удвоенной задержке распрост-
ранения сигнала между узлами (RTT). Конфигурация сети Fast >•
Ethernet, для которой значение окна коллизий превышает время ка-
Сети передачи данных. Метод доступа
163
Рис. 4.1.1.2.3. Схема подключения и передачи сигналов в сетях
100BASE-T4 (буквы К с цифрами обозначают номера контактов разъема]
\
нала, не верна. Время канала задает величину минимального размера
кадра и максимальный диаметр сети. Для пояснения этих взаимоза-
висимостей рассмотрим сеть, показанную на рис. 4.1.1.2.4.
Рис. 4.1.1.2.4
Задержка повторителя складывается из задержек физического
Уровня обоих портов и собственно задержки повторителя. Задерж-
ка на физическом уровне сетевого интерфейса считается равной 250
нсек. Рассмотрим задержки сигнала для всех пар узлов (А, В и С)
изображенной на рисунке сети:
6*
164
Гпава 4
А -> В 250+110+700+11+250 = 1321 нсек
А —> С 250+110+700+495+250 = 1805 нсек
В -> С 250+11+700+495+250 = 1706 нсек
Когда А передает кадр, узлы В и С отслеживают наличие несу-
щей. Это продолжается до тех пор, пока А не завершит эту процеду-
ру. Как только узлы В и С фиксируют окончание передачи кадра
узлом А, они запускают свои таймеры IPG. Запускает свой таймер
IPG и узел А, причем его таймер стартует первым. На рис. 4.1.1.2.5
показана временная диаграмма развития событий в сетевом сегмен-
те. Таймер В стартует следующим через 1321 нсек после А. Таймер
узла С стартует спустя 1805 нсек после А.
Узел В начинает передачу сразу после срабатывания его IPG-
таймера, а через 484 наносекунды передачу начнет и узел С, так как
канал с его точки- зрения свободен. Но коллизии еще не происходит,
так как их кадры еще не «столкнулись». Для того чтобы первый
бит от узла В достиг узла С, требуется 1706 наносекунд. Узел С
зарегистрирует столкновение первым, это произойдет в момент
3987нсек. После этого С будет продолжать передачу еще в течение
320 нсек (сигнал JAM). Сигнал JAM гарантирует регистрацию кол-
лизии повторителем. Только спустя 484 нсек коллизию обнаружит
узел В, начнет передачу своего сигнала JAM после чего прекратит
передачу.
Стандарт IEEE предусматривает возможность полнодуплексной
связи при использовании скрученных пар или оптоволокна. Реали-
зуется это путем выделения для каждого из направлений передачи
независимого канала. Такая схема осуществляет связь типа точка-
точка и при определенных условиях позволяет удвоить пропускную
Рис. 4.1.1.2.5 Временная диаграмма, поясняющая возникновение
коллизий (все времена в наносекундах]
Сети передачи данных. Метод доступа
165
способность сети. Здесь нет нужды в стандартном механизме досту-
па к сетевой среде, невозможны здесь и столкновения. Дуплексную
схему могут поддерживать все три модификации 100-мегагерцного
Ethernet (100BASE-TX, 100BASE-T4 и 100BASE-FX). Для оптово-
локонной версии дуплексной связи предельная длина сегмента мо-
жет достигать 2 км (для полудуплексного варианта предельная
длина сегмента может достигать 412 м). Следует иметь в виду, что
для локальных сетей целесообразнее применение мультимодового
оптоволокна (дешевле и больше коэффициент захвата света).
В настоящее время разрабатываются новые еще более скорост-
ные варианты Ethernet IEEE 802.3z (гигабайтный Ethernet утверж-
ден в качестве стандарта в 1998 году; 1000BASE-FX; FTP:/
stdsbbs.ieee.org/pub, смотри также www.gigabit-rethernet.org/
technology/faq.html). Эти сети ориентированы на применения 4-х
скрученных пар категории 5 (до 100м) и оптоволоконных кабелей.
Применяется кодировка 8В/10В. Сетевые интерфейсы используют
шину PCI.
Всякая, даже гигантская сеть была когда-то маленькой. Обычно
сеть начинается с одного сегмента типа 1, 3 или 4 (рис. 4.1.1.2.1).
Когда ресурсы одного сегмента или концентратора (повторители для
скрученных пар) исчерпаны, добавляется повторитель. Так продол-
жается до тех пор, пока ресурсы удлинения сегментов и каналы
концентраторов закончатся и будет достигнуто предельное число
повторителей в сети (4 для 10 МГц-ного Ethernet). Если при пост-
роении сети длина кабельных сегментов и их качество не контроли-
ровалось, возможен и худший сценарий — резкое увеличение числа
столкновений или вообще самопроизвольное отключение от сети
некоторых ЭВМ. Когда это произошло, администратор сети должен
понять, что время дешевого развития сети закончилось — надо ду-
мать о приобретении мостов, сетевых переключателей, маршрутиза-
торов, а возможно и диагностического оборудования. Применение
этих устройств может решить и проблему загрузки некоторых сег-
ментов, ведь в пределах одного логического сегмента потоки, созда-
ваемые каждым сервером или обычной ЭВМ, суммируются. Не ис-
ключено, что именно в этот момент сетевой администратор заметит,
что топология сети неудачна и ее нужно изменить. Чтобы этого не
произошло, рекомендуется с самого начала тщательно документиро-
вать все элементы (кабельные сегменты, интерфейсы, повторители и
пр.). Хорошо, если уже на первом этапе вы хорошо представляете
конечную цель и те возможности, которыми располагаете. Бухгал-
терская сеть и сеть, ориентированная на выход в Интернет, будут
Иметь разные структуры. Прокладывая кабели, рекомендуется учи-
166
Гпава 4
тывать, что положение ЭВМ время от времени меняется, и это не
должно приводить к изменению длины сегмента или к появлению
дополнительных «сросток». Следует также избегать применения в
пределах сегмента кабелей разного типа и разных производителей.
Если сеть уже создана, научитесь измерять информационные потоки
в сегментах и внешние потоки (если ваша сеть соединена с другими
сетями, например с Интернет), это позволит осмысленно намечать
пути дальнейшей эволюции сети. Если возможности позволяют, из-
бегайте использования дешевых сетевых интерфейсов, их параметры
часто не отвечают требованиям стандарта. Сетевая архитектура тре-
бует немалых знаний и это дело лучше поручить профессионалам.
Когда потоки данных в сети достигают уровня, при котором
использование мостов и сетевых переключателей уже недостаточно,
можно подумать о внедрении маршрутизаторов или оптоволокон-
ных сегментов сети FDDI или быстрого (100 Мбит/с) Ethernet. Эти
субсети будут играть роль магистралей, по которым идет основной
поток данных, ответвляясь в нужных местах в субсети, построенные
по традиционной технологии (см. раздел FDDI). Сеть FDDI для
этих целей предпочтительнее, так как она не страдает от столкнове-
ний и у нее не падает пропускная способность при перегрузке. Если
в вашей сети имеются серверы общего пользования, их рекоменду-
ется подключить к быстродействующим сегментам и организовать
несколько узлов доступа к FDDI-кольцу. Остальные потребители
будут соединены с FDDI через эти узлы доступа (мосты/шлюзы).
Аналогичную функцию могут выполнять и сегменты быстрого
Ethernet (особенно хороши для этого схемы дуплексного обмена, см.
выше).
Особую проблему составляют переходы 100 Мбит/с —> 10 Мбит/с
(рис. 4.1.1.2.6). Дело в том, что на МАС-уровне нет механизмов
понижения скорости передачи для согласования возможностей от-
правителя и приемника. Такие возможности существуют только на
IP-уровне (ICMP-congestion и TCP медленный старт). Если функ-
Рис. 4.1.1.2.6 Схема переходов 1O-1OO-1O Мбит/с
Сети передачи данных. Метод доступа
167
цию шлюза исполняет, например, переключатель, то исключить пе-
реполнение его буфера невозможно. Такое переполнение неизбежно
приведет к потере пакетов, повторным передачам и, как следствие, к
потере эффективной пропускной способности канала. Решить про-
блему может применение в качестве шлюза маршрутизатора (здесь
работает механизм «обратного давления»).
Еёли любые 2 или более каналов справа попытаются начать
работу с одним из каналов слева, или наоборот, потери пакетов
неизбежны. Проблема исчезает, когда SW работают на IP-уровне.
4.1.1.3. Интернет в Ethernet
В Интернет не существует иерархии сетей. Локальная сеть на
основе Ethernet, две ЭВМ, связанные через последовательный интер-
фейс, или общенациональная сеть страны — это все сети и по логике
Интернет они все равны. Каждая сеть имеет свое имя и как мини-
мум один IP-адрес. Имя привычнее для людей, адреса — для машин.
Между именами и адресами существует строгое соответствие.
Для того чтобы пояснить взаимодействие различных систем в
сети, рассмотрйм сильно упрощенную схему обработки команды telnet
vxdesy.desy.de, которая предполагает осуществление удаленного до-
ступа к VX-кластеру в ДЕЗИ, Гамбург (вызов через Windows обраба-
тывается практически аналогично). Сначала ЭВМ выделяет коман-
ду telnet и запускает соответствующую программу. Эта программа
рассматривает символьный адрес vxdesy.desy.de в качестве парамет-
ра команды telnet.
Рис. 4.1.1.3.1. Схема обработки сетевого запроса
168
Гпава 4
Сначала определим, что же нужно сделать для решения стоящей
задачи? Чтобы обратиться к нужной ЭВМ, система должна знать ее
IP-адрес, маску субсети и адрес маршрутизатора или ЭВМ, через ко-
торые можно обратиться с запросом на установление канала связи.
Рассмотрим решение проблемы поэтапно. Сначала символьный ад-
рес vxdesy.desy.de пересылается серверу имен (DNS-система может
располагаться как в ЭВМ пользователя, так и в другой машине), где
преобразуется в цифровой IP-адрес, пересылаемый в отклике на DNS-
запрос (предварительно надо узнать его МАС-адрес). Но знания IP-
адреса недостаточно, надо выяснить, где находится объект с этим
адресом. На IP-адрес накладывается сетевая маска (задается при
конфигурации рабочей станции), чтобы определить, не является ли
данный адрес локальным. Если адрес локален, IP-адрес должен быть
преобразован в Ethernet-адрес (МАС), ведь ваша ЭВМ может опери-
ровать только с Ethernet-адресами. Для решения этой задачи посы-
лается широковещательный (обращенный ко всем участникам ло-
кальной сети) ARP-запрос. Если адресат находится в пределах ло-
кальной субсети, то он откликнется, прислав Ethernet-адрес своей
сетевой карты. Если это не так, что имеет место в приведенном
примере, присылается Ethernet-адрес пограничного для данной сети
маршрутизатора. Это происходит лишь в случае, если он поддержи-
вает режим Proxy-ARP. В противном случае рабочая станция дол-
жна воспользоваться IP-адресом маршрутизатора (Gateway), задан-
ным при ее конфигурации, и выявить его МАС-адрес с помокцью
ARP-запроса. Наконец с использованием полученного IP-адреса
программа telnet формирует IP-пакет, который вкладывается в
Ethernet-кадр и посылается маршрутизатору узла (ведь именно его
адрес она получила в ответ на ARP-запрос в данном примере). Пос-
ледний анализирует имеющиеся у него маршрутные таблицы и вы-
бирает, по какому из нескольких возможных путей послать указан-
ный пакет. Если адресат внешний, IP-дейтограмма вкладывается в
РРР- FDDI- или какой-то другой кадр (зависит от протокола внеш-
него канала) и отправляется по каналам Интернет. В реальной
жизни все бывает сложней. Во-первых, присланный символьный
адрес может быть неизвестен локальной DNS-системе (серверу имен)
и она вынуждена посылать запросы вышестоящим DNS-серверам,
во-вторых, пограничный маршрутизатор вашей автономной систе-
мы может быть непосредственно не доступен (ваша ЭВМ находится,
например, в удаленной субсети) и т.д. и т.п. Как система выпутыва-
ется из подобных осложнений, будет описано позднее. Следует иметь
в виду, что, например, в системе UNIX все виды Интернет услуг
обслуживает демон inetd. Конкретный запрос (telnet, FTP, finger,
Сети передачи данных. Метод доступа
169
WWW и т.д.) поступает именно к нему, inetd резервирует номер
порта и запускает соответствующий процесс, после чего переходит в
режим ожидания новых запросов. Такая схема позволяет эффек-
тивно и экономно работать со стандартными номерами портов. Ну
а теперь начнем с фундаментальных положений Интернет.
В Интернет информация и команды передаются в виде пакетов,
содержащих как исходящий адрес, так и адрес места назначения
(IP-адрес имеет 32 двоичных разряда). Каждой ЭВМ в сети постав-
лен в соответствие уникальный адрес, появление двух объектов с
идентичными IP-адресами может дезорганизовать сеть. IP-адреса-
ция поддерживает пять различных классов сетей (практически ис-
пользуется только три) и, соответственно, адресов (версия IPv4).
Класс А предназначен в основном для небольшого числа очень боль-
ших сетей. Здесь для кода сети выделено только 7 бит, это означа-
ет, что таких сетей в мире не может быть больше 127 (27-1). Класс
В выделяет 14 бит для кода сети, а класс С — 22 бита. В классе С
для кода ЭВМ (host) предназначено 8 бит, поэтому число ЭВМ в сети
ограничено. Самые левые биты адреса предназначены для кода клас-
са. IP-адрес характеризует точку подключения машины к сети. По-
этому, если ЭВМ перенесена в другую сеть, ее адрес должен быть
изменен. Старшие биты адреса определяют номер подсети, остальные
биты задают номер узла (номер ЭВМ). В таблице 4.1.1.3.1 приведено
соответствие классов адресов значениям первого октета адреса и ука-
зано количество возможных IP-адресов каждого класса.
Структура IP-адресов изображена на рисунке 4.1.1.3.2:
Для удобства чтения IP-адреса обычно записываются в десятич-
но-точечной нотации, например: 192.148.166.129 (адрес класса С).
Классу А соответствует диапазон адресов 1.0.0.0 - 127.255.255.255.
Классу В соответствует диапазон адресов 128.0.0.0 - 191.255.255.255.
Классу С соответствует диапазон адресов 192.0.0.0 - 223.255.255.255.
Классу D соответствует диапазон адресов 224.0.0.0 - 239.255.255.255.
Классу Е соответствует диапазон адресов 240.0.0.0 - 247.255.255.255.
Таблица. 4.1.1.3.1. Характеристики классов адресов
Класс адреса Диапазон значений первого октета Возможное количество сетей Возможное количество узлов
А 001 .. .. 126 128 16777214
, В_ 128 .. . 191 16382 65534
С 192.. .. 223 2097150 254
__р _ 224.. .. 239 228
L Е 240.. .. 247 227
170
Гпава 4
Класс 0 1 8 16 24 31
А Q NetID Идентификатор ЭВМ
1 0 Идентификатор сети Идентификатор ЭВМ
1 1 0 Идентификатор сети Идентификатор ЭВМ
1 1 1 9 Мульти кастинг-адрес
1 1 1 1 0 Зарезервировано на будущее
Рис. 4.1.1.3.2. Структура IP-адресов (NetID = идентификатор сети]
Ряд адресов является выделенными для специальных целей:
0.0.0.0 — обращение к ЭВМ, на которой производится работа;
255.255.255.255 — обращение ко всем машинам локальной сети.
127.ххх.ххх.ххх — помещение пакета во входной поток данной
ЭВМ (Loopback). Два другие специальные адреса показаны на рис.
4.1.1.3.2.а.
ООО ООО Код адреса ЭВМ
Код адреса сети 11111 11111
Обращение к ЭВМ
данной сети
Широковещательное
обращение к
удаленной сети
Рис. 4.1.1.3.2.а. Специальные IP-адреса
Кроме того, в классах В и С зарезервированы адреса 191.225.0.0
и 223.255.255.0, соответственно. IP-адрес имеет Интернет- и мест-
ную секции, первая характеризует место (организацию, сеть или даже
группу сетей), вторая — конкретную ЭВМ. Местная секция адреса
может быть разделена на части, характеризующие локальную сеть и
конкретную ЭВМ (рис. 4.1.1.3.3).
Такая схема обеспечивает необходимую гибкость, дает возмож-
ность разделить локальную сеть на субсети. При работе с субсетью
необходимо использовать 32-разрядную маску. Разряды маски дол-
Internet-секция адреса Локальная секция адреса
Internet-секция адреса Адрес сети Адрес ЭВМ
Рис. 4.1.1.3.3. Локальная часть IP-адреса
Сети передачи данных. Метод доступа
171
ясны равняться 1, если сеть рассматривает данный бит как часть
адреса сети, и 0, если он характеризует адрес ЭВМ в этой сети. Все
субсети одного адресного блока (А, В или С) должны иметь одну и
ту же маску субсети. Например:
255.255.255.254 (десятично-точечное представление)
11111111 11111111 11111111 11111110 (двоичное представление)
описывает маску субсети, в которой работает автор. Некоторую
информацию о масках в работающей сети можно получить с помо-
щью команды if config (SUN):
/usr/etc/if config -а (курсивом здесь и далее выделяются коман-
ды, введенные с клавиатуры)
1е0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,
MULTlCAST>inet 193.124.224.35 netmask ffffffeO broadcast
193.124.224.32
loO: flags=869<UP,LOOPBACK,NOTRAILERS,RUNNING,
MULTICAST>inet 127.0.0.1 netmask ffffffOO,
где leO и loO — имена интерфейсов, флаг -а предполагает выдачу
данных обо всех интерфейсах.
Во всех схемах IP-адресации адрес со всеми единицами в секции
адрес ЭВМ (host) означает широковещательное обращение ко всем
ЭВМ сети. Следует помнить, что широковещательные запросы силь-
но перегружают сеть, и без особой необходимости их использовать
не следует.
IP-адрес безусловно удобный для использования ЭВМ, почему-то
плохо запоминается людьми, поэтому они разработали символьную
систему имен для узлов Интернет. Эта система (DNS — Domain
Name System) имеет иерархический характер. Имя содержит не-
сколько полей, разделенных символом «.» (точка). В качестве при-
мера можно привести имя домена ITEPnet — cl.itep.ru. Это имя
содержит три поля. Поле ru указывает на принадлежность данного
домена России, поле itep определяет принадлежность узла ITEP
(Institute for Theoretical and Experimental Physics), cl — характери-
зует то, что данное конкретное имя относится к кластеру ЭВМ (имя
субдомена). Никаких ограничений на число полей в имени, кроме
налагаемых здравым смыслом, не существует. Собственно имя до-
мена — это itep.ru. Самое правое поле в имени домена характеризу-
ет принадлежность к определенному типу организации или стране,
аблица стандартизованных имен приведена в приложении “Наци-
°нальные коды”. Преобразование символьного имени в IP-адрес про-
изводится в DNS-сервере узла, который представляет собой базу
Данных с удаленным доступом. Если искомое имя узла в локаль-
°м k^S-сервере отсутствует, он может прислать в качестве ответа
172
Гпава 4
адрес другого DNS-сервера, куда следует обратиться, чтобы опреде-
лить IP-адрес искомого узла. Анализ имени обычно производится
справа налево. Более подробно DNS-система описана в документах
RFC-822, -823, а также ниже в разделе DNS. О правилах получения
IP-адресов и регистрации имен сетей можно прочесть в [8].
При формировании пакетов различного уровня используется прин-
цип инкапсуляции (вложения). Так IP-пакеты вкладываются в
Ethernet-пакеты (кадры). Всякий пакет имеет заголовок и тело, не-
которые из них снабжены контрольной суммой. Схема такого вло-
жения представлена на рисунках 4.1.1.3.4 и 4.1.1.3.5.
Поле тип определяет используемый в дейтограмме протокол, PAD
— пустые биты, дополняющие размер дейтограммы до 48 бит. В
случае протокола IEEE 802.3 полю тип (>150010) соответствует
поле длина (<150010), которое определяет длину кадра.
Пакетный принцип позволяет передавать информацию от раз-
ных источников к различным адресатам по общему телекоммуни-
кационному каналу. Схема вложения пакетов в рамках TCP/IP
показана на рис. 4.1.1.3.4.
Принцип вложения (также как и фрагментации) является фун-
даментальным для любых современных сетей. Этот принцип ис-
пользуется в сетях NetWare, Apple Talk, TCP/IP и т.д.
Отдельные сети в Интернет соединяются друг с другом через
узловые серверы (Gateway, их иногда называют пограничными мар-
шрутизаторами — Boarder Gateway), расстояние между которыми
может измеряться метрами или тысячами километров. В межсете-
вых обменах также используется принцип вложения так пакеты
Ethernet могут вкладываться в пакеты FDDI и т.д..
Прикладные программы также как и все протокольное программ-
ное обеспечение уровня Интернет и выше работают только с IP-
адресами, в то время как уровень сетевого программного обеспече-
ния работает с физическими сетевыми адресами (так Ethernet ис-
пользует 48-битные адреса).
UDP- заголовок Данные UDP- дейтограммы
1Р-заголовок Данные IP- дейтограммы
Заголовок кадра Область данных кадра Ethernet
Уровень UDP/TCP
Уровень IP/ARP
Уровень Ethernet
или другой сети
Рис. 4. 1.1.3.4. Схема вложения пакетов в TCP/IP
(в данном примере в поле тип Ethernet кадра будет записан код 0800)
Сети переда чи данных. Метод доступа 173
Обычно при описании сетей используется терминология 7-уров-
невой модели ISO («стек протоколов»). Так уж получилось, но Ин-
тернет лишь с определенными натяжками можно описать, придер-
живаясь этой схемы. Ethernet-инкапсуляция продемонстрирована
на рис. 4.1.1.3.5 (RFC 894; размеры полей указаны в байтах).
Рис. 4.1.1.3.5. Вложение пакетов Интернет в Ethernet- и
IEEE 802 пакеты
LLC — управление логической связью (Logical Link Control);
DSAP = OxAA (Destination Service Access Point) — поле адреса дос-
тупа к службе получателя; SSAP = OxAA (Source Service Access
Point) — поле адреса доступа к службе отправителя; SNAP — про-
токол доступа к субсетям (SubNetwork Access Protocol). PAD —
поле заполнитель. В общем случае форматы полей DSAP и SSAP
имеют вид, показанный на рис. 4.1.1.3.6 I/G = 0 — индивидуаль-
ный адрес, I/G =1 — групповой адрес; D — бит адреса службы места
назначения, S — бит адреса службы отправителя; C/R =0 — ко-
манда, C/R =1 — подтверждение.
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
I/G D D D D D D D C/R S S S S S S S
DSAP SSAP
Рис. 4.1.1.3.6. Структура адресов DSAP и SSAP
174
Гпава 4
Поле CNTL может иметь длину 1 или 2 байта, а его структура
соответствовать I, S или U-форматам (см. разделы «Эталонная мо-
дель ISO» и «Х.25»). В однобайтовых полях DSAP и SSAP запи-
сывается код типа протокола сетевого уровня. Для протоколов IPX/
SPX это и последующее поле содержат код ОхЕО. Поле CNTL=03
обозначает нечисловой формат для уровня Ethernet 802.2. Эти три
байта часто представляют собой код производителя, как правило,
совпадающий с первыми тремя байтами адреса отправителя. Иног-
да они просто делаются равными нулю. Поле тип (2 байта) харак-
теризует используемую версию Ethernet. Из рисунка 4.1.1.3.5 вид-
но, что первые два поля (адреса получателя и отправителя) и после-
днее поле (CRC) во всех форматах идентичны. При расчете CRC
содержимое кадра рассматривается как двоичный полином. Произ-
водится деление этого кода на специальный образующий полином.
Полученный остаток от деления дополняется по модулю один, ре-
зультирующий код и считается контрольной суммой CRC. В поле
адрес получателя может быть записан код OxFFFFFFFFFFFF, что
указывает на широковещательную адресацию кадра. Адрес отпра-
вителя такой код содержать не может. Третье поле может служить
для выявления типа используемого протокола. Если в этом поле
содержится число более 1500 (десятичное), это указывает на то, что
данный кадр имеет формат Ethernet II, а само поле содержит не
длину кадра а тип данных. Теперь, надеюсь, читателю понятно, по-
чему кадр Ethernet 802.3 не может содержать более 1500 байт.
Кадр Ethernet 802.2 помимо первых трех полей содержит до-
полнительные три однобайтовые поля, следующие вслед за ними
(DSAP, SSAP и CNTL). Кадр Ethernet SNAP является модификаци-
ей кадра Ethernet 802.2. Для этого кадра коды полей DSAP и
SSAP равны ОхАА (признак кадра Ethernet SNAP), код CNTL=03
(нечисловой формат), поле код организации (3 байта, характеризует
организацию сети) равен нулю (для IPX/SPX), а двухбайтовое поле
тип характеризует протокол высокого уровня. Для протоколов IPX/
SPX в этом поле должен быть записан код 0x8138. (для IP —
0x0800, для ARP — 0x0806, для RARP — 0x8035, а для Apple Talk
— 0x809В). Таблица кодов протоколов приведена в приложении
“Базовые протоколы Интернет” (см. также RFC-1700). Поля тип
протокола и по смыслу и по содержанию идентичны для всех разно-
видностей кадра Ethernet (кроме IEEE 802.3).
Транспортный уровень должен воспринимать данные от несколь-
ких пользовательских программ и пересылать их на более низкий
уровень. Многоуровневые протоколы спроектированы так, чтобы слой
п по месту назначения получал ту же самую информацию, нто была
Сети передачи данных. Метод доступа
175
послана слоем п отправителя. Прикладные программы также как
и все протокольное программное обеспечение уровня Интернет и
выше использует только IP-адреса (32 бита), в то время как уровень
сетевого программного обеспечения работает с физическими сетевы-
ми адресами (так Ethernet использует 48-битные адреса).
Когда IP-дейтограмма попадает в ЭВМ, сетевое программное обес-
печение передает ее программе IP-уровня. Если адрес места назначе-
ния совпадает с IP-адресом ЭВМ, дейтограмма принимается и пере-
дается на более высокий уровень для дальнейшей обработки. При
несовпадении адресов дейтограмма уничтожается (переадресация
дейтограмм для ЭВМ запрещена, это функция маршрутизатора).
Хотя можно заставить ЭВМ выполнять задачи маршрутизации, с
точки зрения Интернет-философии это плохая идея.
Различные сети и каналы имеют разные скорости обмена и на-
дежность передачи. Это определяет длину пакета, пересылка кото-
рого с высокой вероятностью будет осуществлена без ошибки. Так
как Интернет объединяет самые разные узлы и сети, использующие
разные длины посылок, при реализации связи между такими объек-
тами размер пакета задается наименее надежным узлом и длина
пакета выбирается минимальной из двух. Поэтому при передаче
длинного пакета через такой участок сети он сегментируется и пе-
редается по частям. Размер фрагмента определяется величиной мак-
симального передаваемого блока (MTU — Maximum Transfer Unit, в
Ethernet MTU=1500 октетам). Величины MTU для других сред при-
ведены в таблице 4.1.1.3.2:
Таблица 4.1.1.3.2. Значения MTU
для различных сетевых стандартов
Сеть MTU (байт)
Hyperchannel (Сеть с топологией типа шина, с CSMA/CD- доступом, числом подключений < 256, максимальной длиной сети около 3,5км (93-омный коаксиальный кабель _RU59 или оптоволокно)) 65535
16 Мбит/с маркерное кольцо (IBM) 17914
ДМбит/с маркерное кольцо (IEEE 802.5) 4464
FDDI 4352
Ethernet II 1500
IEEE 802.3/802.2 1492
X.25 " 576
L£2jj2kjo-Point (при малой задержке) 296
176
Гпава 4
Рассмотрим по фрагментную передачу дейтограммы с длиной в
1300 октетов в предположении, что более 576 октетов за один раз
передать нельзя.
Куда будет направлен Ethernet-кадр, указывает значение для типа .
в заголовке кадра (рис. 4.1.1.3.5). Если IP-пакет попадает в мо-
дуль IP, то содержащиеся в нем данные могут быть переданы либо
модулю TCP (Transmission Control Protocol), либо UDP, что опреде-
ляется полем «протокол» в заголовке IP-пакета.
Исходная дейтограмма
Заголовок 1300 октетов данных
Фрагмент 1 (первые 500 октетов).
Смещение {эавно нулю
Заголовок 500 октетов
Фрагмент 2 (вторые 500 октетов)
Заголовок 500 октетов
Смещение равно 500
Фрагмент 3 (последние 300 октетов)
Заголовок 300 октетов
Смещение равно 1000
Рис. 4.1.1.3.6. Пример фрагментации пакета
Одним из основополагающих понятий в теории маршрутизации |
является автономная система (AS). Автономную систему составля-
ет IP-сеть (или система из нескольких IP-сетей), проводящая еди-
ную политику внешней маршрутизации и имеющая одного или бо-
лее операторов. Все AS имеют уникальные номера. Идеология AS
позволяет решить проблему безудержного роста размера таблиц мар-
шрутизации. Построение узла Интернет неотделимо от формирова-
ния локальной сети, поэтому прежде чем перейти к углубленному
описанию протоколов TCP/IP, введем определения некоторых сете- *
вых устройств, без которых построение локальной сети невозможно.
4.7.7.4. Повторители, мосты, мультиплексоры,
переключатели и маршрутизаторы
На физическом уровне пакет представляет собой цуг импульсов»
распространяющихся по коаксиальному кабелю, скрученной паре*
или оптическому волокну. За счет дисперсии, частичным отраженй*,
ям от точек подключения и поглощению в среде импульсы в пакете^
«расплываются» и искажаются (ухудшается отношение сигнал/шум)»
Сети передачи данных. Метод доступа Л77
это является одной из причин ограничения длин кабельных сегмен-
тов. Для преодоления этих ограничений вводятся сетевые повтори-
тели (repeater). Повторитель воспринимает входные импульсы, уда-
ляет шумовые сигналы и передает вновь сформированные пакеты в
следующий кабельный сегмент или сегменты. Никакого редактиро-
вания или анализа поступающих данных не производится. Задерж-
ка сигнала повторителем не должна превышать 7,5 тактов (750
нсек для обычного Ethernet). Повторители могут иметь коаксиаль-
ные входы/выходы, AUI-разъемы для подключения трансиверов или
других аналогичных устройств, или каналы для работы со скручен-
ными парами.
---------Вход/выход 1
--------- Вход/выход 2
--------- Вход/выход 3
---------Вход/выход-N-1
-----------------Вход/выход N
Рис. 4 Л Л. 4.1 Схема сетевого повторителя
Все входы/выходы повторителя с точки зрения пакетов эквива-
лентны. Если повторитель многовходовый, то пакет пришедший по
любому из входов будет ретранслирован на все остальные входы/
выходы повторителя. Чем больше кабельных сегментов объедине-
но повторителями, тем больше загрузка всех сегментов. При объе-
динении нескольких сегментов с помощью повторителя загрузка
каждого из них становится равной сумме всех загрузок до объеди-
нения. Это справедливо как для коаксиальных кабельных сегмен-
тов, так и для повторителей, работающих со скрученными парами
(хабы — концентраторы). Некоторые повторители контролируют
наличие связи между портом и узлом (Link Status), регистрируют
коллизии и затянувшиеся передачи (Jabber'- узел осуществляет
передачу дольше, чем это предусмотрено протоколом), выполняют
согласование типа соединения (Autonegotiation). В этом случае они
обычно снабжены SNMP-поддержкой.
Для преодоления этого нежелательного явления используются
сетевые мосты или переключатели. Мост соединяет два сегмента
сети, при инициализации он изучает списки адресов устройств, под-
соединенных к каждому из сегментов. В дальнейшем мост записы-
Рис. 4Л. 1.4.2. Схема сетевого моста
вает в свою память эти списки и пропускает из сегмента в сегмент £
лишь транзитные пакеты. Существуют мосты, которые оперируют с X
физическими и с IP-адресами (см. стандарт IEEE 802.ID). г
Мост является активным устройством, которое способно адап-
тироваться к изменениям в окружающей сетевой среде. При этом
пакеты, отправленные из сегмента А и адресованные устройству,
которое подключено к этому же сегменту, никогда не попадут в ;
сегмент Б и наоборот. Через мост проходят лишь пакета, отправ- ;
ленные из сети А в Б или из Б в А.
Функцию моста с определенными скоростными ограничениями
может выполнять и обычная ЭВМ, имеющая два сетевых интерфей-
са и соответствующее программное обеспечение. Мосты при разум-
ном перераспределении серверов и рабочих станций по сетевым
сегментам позволяют выровнять и даже эффективно снизить сред- i
нюю сетевую загрузку. Когда на один из входов моста приходит |
пакет, производится сравнение адреса получателя с содержимым J
внутренней базы данных. Если адрес в базе данных отсутствует, г
мост посылает широковещательный запрос в порт, противополож-
ный тому, откуда получен данный пакет с целью выяснения место- v
положения адресата. Понятно, что появление в субсетях А и Б двух %
объектов с идентичными адресами ни к чему хорошему не приведет.
При поступлении отклика вносится соответствующая запись в базу
данных. Параллельно анализируется и адрес отправителя и, если
этот адрес в базе данных отсутствует, производится его запись в 4
банк адресов соответствующего порта. В базу данных записывается *
также время записи адреса в базу данных. Содержимое базы дан-
ных периодически обновляется. К любой подсети может вести не-
сколько путей, но для нормальной работы мостов и переключателей \
все пути кроме одного должны быть заблокированы. Функциональ-
ная схема работы моста показана на рис. 4.1.1.4.3. Сети, между *
которыми включается мост, не обязательно должны работать со-
гласно идентичным протоколам. Возможны мосты между Ethernet
и Token Ring или между Ethernet и ATM.
Сети передвчи данных. Метод доступа
17 9
Рис. 4.1.1.4.3. Блок-схема работы сетевого моста
Мост, имеющий более двух портов, называется переключателем.
Первый переключатель был разработан фирмой Калпане в 1991
году. Иногда переключатели называются маршрутизаторами, тем
более что некоторые из них поддерживают внутренние протоколы
маршрутизации (например, RIP). Переключатели имеют внутрен-
нюю параллельную магистраль очень высокого быстродействия (от
десятков мегабайт до гигабайт в сек.). Эта магистраль позволяет
переключателю совместить преимущества повторителя (быстродей-
ствие) и моста (разделение информационных потоков) в одном уст-
ройстве. Схемы реализации переключателей варьируются значитель-
но, каких-либо единых стандартов не существует. Алгоритм рабо-
ты с адресами здесь тот же, что и в случае мостов. На рис. 4.1.1.4.4
приведена схема 8-входового переключателя. В переключателе все
Входы идентичны, но внешняя информация, записанная в их па-
мять, делает входы Неэквивалентными. Определенные проблемы воз-
180
Гпава 4
никают, когда к одному из входов переключателя подключен сервер,
с которым работают пользователи подключенные к остальным вхо-
дам. Если все ЭВМ, подключенные к переключателю, одновременно
попытаются обратиться к серверу, переключатель перегрузится и
все каналы будут на некоторое время блокированы (будет послан
сигнал перегрузки - JAM). При данной схеме вероятность таких
событий значительна, так как несколько каналов с пропускной спо-
собностью 10 Мбит/с работают на один общий канал с той же поло-
сой пропускания. Для преодоления проблем этого рода следует рас-
пределять нагрузки между портами переключателя равномерно, а
также подключать серверы через полнодуплексные каналы. Полно-
дуплексные каналы полезны и для соединения переключателей между
собой. Современные переключатели имеют много различных воз-
можностей - SNMP поддержка, автоматическая настройка быстро-
действия и определения типа соединения (дуплексная/полудуплек-
сная). Имеется возможность внешней загрузки программы работа
переключателя. Способы проверки производительности переключа-
телей описаны в документах RFC-1242 и RFC-1944 (тесты Бредне-
ра, см. www.wiley.com/compbooks/FastEthernet и www.tolly.com).
Рис. 4.1.1.4.4. Схема 8-входового сетевого переключателя
Существуют переключатели, работающие в режиме «на пролет»
(cut through). Здесь первые биты пакета поступают на выход /ере-
ключателя, когда последующие еще только приходят на вход. За-
держка в этом случае минимальна, но переключатель пропускает
через себя пакеты, поврежденные в результате столкновений. Аль-
тернативой такому режиму является передача через буферную па-
мять (схема передачи SAF - Store And Forward). Поврежденные
пакеты в этом режиме отбрасываются, но задержка заметно возрас-
тает. Кроме того, буферная память должна иметься на всех входах
Сети передачи данных. Метод доступа
181
Рис. 4Л. 1.4.S. Вариант схемы внутренних связей переключателя.
(или общая многопортовая). При проектировании сетей следует иметь
в виду, что переключатели превосходят маршрутизаторы по соотно-
шению производительность/цена.
При проектировании локальной сети следует учитывать то об-
стоятельство, что узлы с самым напряженным трафиком должны
располагаться как можно ближе к повторителю (мосту или пере-
ключателю). В этом случае среднее число коллизий в единицу вре-
мени будет ниже. По этой причине сервер должен располагаться
как можно ближе к повторителю или другому сетевому устройству
(см. рис. 4.1.1.4.6).
Схема внутренних связей переключателя может отличаться от
приведенной на рис. 4.1.1.4.4 и иметь конфигурацию, показанную
на рис. 4.1.1.4.5. Привлекательность такой схемы заключается в
возможности реализации обмена по двум непересекающимся на-
правлениям одновременно (см. LAN, Журнал сетевых решений, май
1998, том 4, N5, стр 21, Дмитрий Ганжа, “От разделяемых к комму-
тируемым сетям”). При этом эффективная пропускная способность
Рис. 4.1.1.4.6 Схема подключения сервера к переключателю
182
Гпава 4
многопортового переключателя может в несколько раз превосхо- |
дить полосу пропускания сети, например, 10 Мбит/с. |
При использовании в сети большого числа мостов и/или пере-
ключателей может сформироваться топология связей, когда от од-
ного сегмента к другому пакет может попасть более чем одним
путем (см. рис. 4.1.1.4.7). Приведенная на рисунке схема нерабо- j
тоспособна и некоторые связи должны быть ликвидированы. В дан-
ном примере проблема может быть решена удалением мостов BR-2
и BR-3 или разрывом связей, помеченных символом «X».
Проблему ликвидации связей, способных привести к зациклива- ".
нию, решает протокол STP (Spanning Tree Protocol; алгоритм пред- 1
ложен Пёлманом в 1992 году), который автоматически блокирует |
некоторые соединения, а в случае недоступности основного пути от- J
крывает эти заблокированные соединения, обеспечивая высокую на- j
дежность сети. STP является частью протокола мостов IEEE 802.Id. |
При использовании протокола STP каждой связи присваивает-
ся при конфигурации определенный вес (чем меньше, тем выше /
приоритет). Мосты периодически рассылают специальные сообще- |
ния (BPDU — Bridge Protocol Data Unit), которые содержат коды их
уникальных идентификаторов, присвоенные им при изготовлении. ?
Мост или переключатель с наименьшим значением такого кода ।
становится корневым («корень дерева»). Затем выявляется наи-
кратчайшее расстояние от корневого моста/переключателя до лю- ;
бого другого моста в сети. Граф, описывающий дерево наикратчай- |
ших связей, и является «расширяющимся деревом». Такое дерево
включает все узлы сети, но необязательно все мосты/переключате-
ли. Этот алгоритм функционирует постоянно, отслеживая все топо-
логические изменения.
Рис. 4.1.1.4.7. Пример реализации алгоритма
«расширяющееся дереео»
Сети передачи данных. Метод доступа
183
Современные мосты позволяют создавать виртуальные субсети
(VLAN), увеличивающие сетевую безопасность. VLAN позволяет ог-
раничить зону распространения широковещательных пакетов, улуч-
шая эксплуатационные характеристики сети в целом.
Некоторые современные мосты используют так называемую мар-
шрутизацию отправителя (source routing). Такая маршрутизация
предполагает, что отправитель знает, находится ли адресат в преде-
лах локальной сети и может оптимально определить путь достав-
ки. При посылке кадра другой сети отправитель устанавливает стар-
ший бит своего адреса равным единице. Одновременно в заголовке
кадра прописывается весь маршрут. Каждой сети присваивается
12-битовый идентификатор, а каждому мосту ставится в соответ-
ствие 4-битовый код, уникальный в контексте данной сети. Это
означает, что мосты в пределах одной сети должны иметь разные
идентификаторы, но их коды могут совпадать, если они находятся в
разных сетях. Мост рассматривает только кадры с единицей в стар-
шем бите адреса места назначения. Для этих кадров просматрива-
ются коды сети в списке, записанном в заголовке. Если в списке
содержится код, совпадающий с тем, который характеризует сеть, где
находится мост, кадр переадресуется в эту сеть. Реализация алго-
ритма может осуществляться программно или аппаратно. Если путь
до места назначения неизвестен, отправитель генерирует специаль-
ный пакет, посылаемый широковещательно (discovery frame) и дос-
тигающий всех мостов и всех субсетей. Когда приходит отклик от
адресата, мосты записывают его идентификатор, а первичный отпра-
витель фиксируют маршрут до адресата. Данный алгоритм доста-
точно прост, но сопряжен с лавинным размножением «исследова-
тельских» пакетов особенно в случае, когда смежные сети соединя-
ются через несколько мостов/переключателей.
Маршрутизатор отличается от переключателя тем, что поддержи-
вает хотя бы один протокол маршрутизации. Существуют внутрен-
ние и внешние протоколы маршрутизации. Если маршрутизатор осу-
ществляет связь данной автономной системы с другими автономны-
ми системами, его называют пограничным (border). Маршрутизатор
Же> который имеет только один внешний канал связи, в литературе
часто называют gateway (входной порт сети). Любой маршрутизатор
может поддерживать в любой момент только один внутренний и
°Дин внешний протокол маршрутизации, выбор этих протоколов осу-
ществляет администратор сети из имеющегося списка. Маршрутиза-
Т°РЬ1 представляют собой наиболее сложные сетевые устройства. Глав-
Ньтм достоинством маршрутизаторов в локальной сети является ог-
раничение влияния потоков широковещательных сообщений.
184
Гпава 4
В последнее время заметное распространение получил гибрид
маршрутизатора и моста - brouter. Некоторые протоколы (напри-
мер, NetBIOS) не допускают маршрутизации. Когда необходимо ис-
пользовать такие протоколы совместно с TCP/IP, необходим brouter.
Широко используются такие приборы в сетях Token Ring.
Особый класс образуют мультиплексоры/демультиплексоры, ко-
торые используют собственные протоколы и служат для предостав-
ления общего канала большему числу потребителей. Эти устрой-
ства широко используются при построении сетей типа Интранет
(корпоративные сети, где субсети разных филиалов разнесены на
большие расстояния). Такие сети строятся на базе специальных
выделенных каналов, а мультиплексоры позволяют использовать
эти каналы для предоставления комплексных услуг: телефонной :
связи, передачи факсов и цифровой информации, экономя значи-
тельные средства.
Если перед вами стоит задача создания локальной сети с выхо-
дом в Интернет, вам нужно последовательно решить ряд проблем
помимо финансовых. Должны быть сформулированы задачи, ради
которых эта сеть создается, определена топология сети, число сег-
ментов и характер их связей, число ЭВМ-участников, определен сер-
вис-провайдер, или провайдеры, если вам нужно обеспечить более
высокую надежность и живучесть сети. Вам надо оценить требуе-
мую загрузку сегментов сети и внешних каналов связи, выбрать
программную среду. После этого вы можете приступить к составле- z
нию списка необходимого оборудования и программного обеспече-
ния. Если ваша сеть является оконечной и она имеет только один
внешний канал связи, вам не нужен маршрутизатор и вы можете
ограничиться ЭВМ-портом (gateway), которая должна иметь необ-
ходимый интерфейс. Внешним каналом может стать коммутируе-
мая телефонная сеть, выделенная телефонная линия, оптоволокон-
ный кабель или радиорелейный канал. Во всех перечисленных слу-
чаях вам будет необходим соответствующий модем.
4.1.2. Сети FDDI
Одной из наиболее популярных сетей, использующих оптическое |
волокно, (не считая Fast Ethernet) является FDDI. FDDI (Fiber
Distributed Data Interface, ISO 9314-1, RFC-1512, -1390, -1329, - |
1285 — смотри также http://iquest.com/~nmaller/fddi.htm) стай-.t
дарт американского института стандартов (ANSI), принятый без
изменения ISO. Протокол рассчитан на физическую скорость пере-|
дачи информации 100 Мбит/с и предназначен для сетей с суммар-
ной длиной до 100км (40 км для мультимодовых волокон) при
расстоянии между узлами 2 км или более. Частота ошибок в сети
не превышает 10 9. В FDDI используется схема двойного кольце-
Сети передачи данных. Метод доступа
185
вого счетчика (рис. 4.1.2.1; буквами A,B,C,D и Е обозначены стан-
ции-концентраторы). Кольцевая схема единственно возможное реше-
ние для оптическогр_щ1локна (не считая схемы точка-точка). Для
доступа к сети используется специальный маркер (развитиепротоко-
ла IEEE 802.5 — Token Ring). Сети FDDI не имеют себе равных при
построении опорных магистралей (backbone) локальных сетей, позво-
ляя реализовать принципиально новые возможности - удаленную
обработку изображений и интерактивную графику. Обычно устрой-
ства (DAS — Dual Attached Station) подключаются к обоим коль-
цам одновременно. Пакеты по этим кольцам движутся в противо-
положных направлениях. В норме только одно кольцо активно (пер-
вичное), но при возникновении сбоя (отказ в одном из узлов)
активизируется и второе кольцо, что заметно повышает надежность
системы, позволяя обойти неисправный участок (схема соединений
внутри станций-концентраторов на рис. 4.1.2.1 является сильно уп-
рощенной). Предусмотрена возможность подключения станций и толь-
ко к одному кольцу (SAS — Single Attached Station), что заметно
дешевле. К одному кольцу можно подключить до 500 DAS и 1000
SAS. Сервер и клиент имеют разные типы интерфейсов.
Рис. 4.1.2.1. Схема связей в двойном кольце FDDI
Топология связей в FDDI устроена таким образом, что отказ в
любом из узлов из-за выхода из строя оборудования или отключе-
ния питания не приведет к разрыву кольца, поток кадров автомати-
чески пойдет в обход поврежденного участка.
FDDI позволяет работать с кадрами размером 4500 октетов, за
вычетом места, занимаемого преамбулой, остается 4470 октетов для
передачи данных. RFC-1188 резервирует 256 октетов для заголовков,
оставляя для данных 4096 октетов. Маршрутизатор, поддерживаю-
щий протокол FDDI должен быть способен принимать такие длин-
ные пакеты. Посылаться же должны дейтограммы не длиннее 576
октетов, если не ясно, сможет ли адресат принимать длинные кадры.
Услуги информационного канала (Data Link Service) реализу-
ется через протокол IEEE 802.2 Logical Link Control (LLC). В ре-
зультате мы имеем следующий стек протоколов (рис. 4.1.2.2).
Уровень MAC (Media Access Control) определяет доступ к се-
квой среде, включая формат кадров, адресацию, алгоритм вычисле-
186
Гпава 4
Рис. 4.1.2.2. Схема протокольных подуровней для FDDI
ния CRC и механизм исправления ошибок. Уровень PHY (Physical
Layer Protocol) задает процедуру кодирования/декодирования, синх-
ронизацию, формирование кадров и пр. В качестве базовой исполь-
зуется кодировка 4В/5В (преобразование 4-битного кода в. 5-бит-
ный), а в канале — NRZI. Уровень PMD (Physical Layer Medium)
определяет характеристики транспортной среды, включая оптичес-
кие каналы, уровни питания, регламентирует частоту ошибок, зада-
ет требования к оптическим компонентам и разъемам. Блок схема
интерфейса между уровнями МАС и PHY показана на рис. 4.1.2.3.
1Р-дейтограммы, ARP-запросы и отклики, пересылаемые по сети
FDDI, должны инкапсулироваться в пакеты 802.2 LLC и SNAP,
(SubNetwork Access Protocol; см. рис. 4.1.2.4 и 4.1.2.5), а на.физи- л
Рис. 4.1.2.3. Схема физического интерфейса FDDI
Сети передачи данных. Метод доступа
187
MAC Header FDDI MAC
DSAP=K1 SSAP=K1 Управление 802.2 LLC
ID протокола или Org-код =К2 EtherType 802.2 SNAP
Рис. 4.1.2.4. Структура некоторых полей заголовков пакетов
ческом уровне в FDDI МАС. Протокол SNAP должен использо-
ваться с организационными кодами, указывающими, что SNAP-за-
головок содержит код EtherType. 24-битовый организационный код
(Organization Code) в SNAP должен быть равен нулю, а остальные
16 бит должны соответствовать EtherType (см. Assigned Numbers,
RFC-1700; IP =2048, ARP =2054).
Все кадры должны пересылаться в соответствии со стандартом
802.2 LLC тип 1 (формат ненумерованной информации, с полями
DSAP (Destination Service Access Point) и SSAP (Source Service Access
Point) заголовка 802.2, равными предписанным значениям SAP
(Service Access Point) для SNAP.
Полная длина LLC- и SNAP-заголовков составляет 8 октетов.
Десятичное значение К1 равно 170. К2 равно 0. Управляющий
код равен 3 (ненумерованная информация).
Для преобразования 16- или 48-разрядного FDDI-адреса в 32-
разрядный IP-адрес используется протокол ARP. Операционный код
равен 1 для запроса и 2 для отклика. Спецификация FDDI МАС
определяет максимальный размер кадра равным 4500 октетам, вклю-
чая 16-октетную преамбулу. Преамбула состоит из кодов 11111,
стартовый разделитель имеет вид 1100010001, а оконечный разде-
литель — 0110101101 (во всех случаях применена 5-битовая нота-
ция). Контрольная сумма CRC вычисляется для полей, начиная с
поля управление по данные включительно.
Вычитая 8 байт LLC/SNAP заголовка, получаем значения мак-
симального размера пакета (MTU) 4470 (4478) октетов. Для совме-
__16 1 1 6(2) 6 (2) 4(8) 2(4)
I г. I Старт- | | Г Г ’... !
! Реам- ! овый ! Управ- i Адрес ; Адрес ।
। бУла | разде- | Ление I отправителя I назначения • Даннь,е ( CRC
| литель | | J__ j ।__
Конечный разделитель/ Состояние кадра (3-4 байта) —
Рис. 4.1.2.5. Формат пакета протокола FDDI
188
Гпава 4
стимости размер пакетов для IP-дейтограмм и ARP-пакетов согла-
суется с требованиями конкретной сети. FDDI реализует маркерный
доступ, формат пакета-маркера имеет вид, показанный на рис. 4.1.2.6.
В зависимости от размера кольца в нем могут циркулировать не-
сколько маркеров.
16 2 2 1
Преамбула Начальный разделитель Поле управления кадра Оконечный разделитель
Рис. 4.1.2.6. Формат кадра-маркера
802.2 класс I LLC требует поддержки команд ненумерованная
информация (UI), команд и откликов exchange IDentification (XID),
а также TEST. Станции не обязаны уметь передавать команды XID
и TEST, но должны быть способны посылать отклики.
Командные кадры идентифицируются по нулевому младшему биту
SSAP-адреса. Кадры-отклики имеют младший бит SSAP-адреса рав-
ный 1. UI-команды содержат в управляющем поле LLC код 3.
Команды/отклики XID имеют код поля LLC, равный 175 (значе-
ние десятичное) при значении бита Poll/Final=0 или 191 при Poll/
Final=l. Код управления LLC для команд/откликов TEST равен
227, если Poll/Final=0, и 243 при Poll/Final=l.
Отклики и команды UI при Ро11=1 игнорируются. Команды UI,
имеющие отличные от SNAP SAP в DSAP- или SSAP-полях, не
считаются пакетами IP или ARP.
При получении команд XID или TEST должен быть послан соот-
ветствующий отклик. Отклик посылается, когда DSAP равен SNAP
SAP (170), Null SAP (0), или при Global SAP (255). При других
DSAP отклики не посылаются.
При посылке отклика на команды XID или TEST, значение
бита Final отклика должно быть равно значению бита Poll коман-
ды. Кадр отклика XID должен включать в себя информационное
поле 802.2 XID 129.1.0, указывающее на класс услуг 1 (не требую-
щих установления связи).
Кадры отклика TEST должны соответствовать информационно-
му полю кадра команды TEST.
Для начала передачи станция должна получить в свое распоря-
жение маркер. Если станция находится в пассивном состоянии, она
передает маркер следующей станции. Но из-за большой протяжен-
ности колец FDDI время задержки здесь заметно больше, чем >
случае Token Ring. В кольце FDDI может находиться несколько
Сети передачи данных. Метод доступа
189
кадров одновременно. Станция сама удаляет кадры из кольца, по-
сланные ей самой. Все станции должны иметь таймер вращения
маркера (TRT - Token Rotation Time), который измеряет время с
момента, когда станция последний раз принимала этот пакет. Име-
ется переменная TTRT (Target Token Rotation Time). Значение TRT
сравнивается c TTRT и только приоритетные кадры могут быть
переданы при TRT> TTRT. Обычная передача данных контролиру-
ется таймером ТНТ (Token Hold Timer). Когда станция получает
маркер, она заносит TRT в таймер ТНТ, который начинает обратный
отсчет. Станция может посылать кадры до тех пор, пока ТНТ оста-
ется больше TTRT. В действительности ТНТ определяет максималь-
ное число октетов (символов), которое может быть послано станци-
ей в рамках одного кадра (ТНТ задает предельное время, в течение
которого станция может передавать данные).
IEEE специфицирует числа как последовательности бит, где
младший бит передается первым. В протоколах Интернет порядок
бит другой, что может вызывать ошибки. Ниже приведена краткая
таблица (4.1.2.1) соответствия для некоторых из чисел.
Таблица 4.1.2.1
Число IEEE двоичное Интернет двоичное Интернет десятичное
UI 11000000 00000011 3
SAP для SNAP 01010101 10101010 170
Global SAP 11111111 11111111 255
Null SAP 00000000 00000000 0
XID 11110101 10101111 175
XIDPoll/Final 11111101 10111111 191
XID Info 129.1.0
TEST 11000111 11100011 227
TEST Poll/Final 11001111 11110011 243
Оптоволокно особенно привлекательно для сетей, где ЭВМ раз-
мещены в далеко отстоящих друг от друга зданиях и при высоком
Уровне электромагнитных наводок. Оптоволокно является незаме-
нимой средой для широкополосных каналов связей (вспомним тео-
рему Шеннона). Привлекательна такая среда и с точки зрения на-
дежности (бульдозеры, рвущие кабель, не в счет) и безопасности
тсутствие внешних излучений). Расстояние между станциями при
как°ЛЬЗ°ВаНИИ такого ка^еля может достигать 8-9 км (а не 2 км,
б в случае многомодового кабеля с полосой 500МГц/км). Зару-
ые одномодовые кабели группы 1 допускают максимальное рас-
190
Гпава 4
стояние между узлами в 10 км, а группы 2 — 40 км при полосе
пропускания 1 Гбит/с. Подключение к сети FDDI производится обыч-
но через фотооптические трансиверы (ФОТ), которые преобразуют
оптический сигнал в электрический. Источником света является
светоизлучающий диод с длиной волны 1350 или 1500 нм. Толщи-
на передающего оптоволокна равна 50/125 или 62.5/125 микрон
(числитель — диаметр несущего свет волокна; знаменатель — вне-
шний диаметр клэдинга; числа относятся к мультимодовому волок-
ну). При выборе того или иного кабеля следует иметь в виду, что
ослабление более 11 дБ не допустимо, при большем ослаблении чис-
ло ошибок в процессе передачи становится слишком большим.
Именно это ограничение ставит верхний предел на длину при ис-
пользовании многомодового волокна (при длине 2 км ослабление
достигает 10,5 дБ). Выбирая оптические разъемы, нужно помнить,
что хороший разъем не должен вносить ослабление более 2 дБ.
Там где это возможно, предпочтительнее сварка волокон, которая
при качественном исполнении вносит ослабление сигнала не более
0,3 дБ. На случай выхода из строя оборудования или отключения
питания удобно использовать обводящие оптические переключате-
ли (но они вносят ослабление около 2.5-4 дБ). При их использова-
нии предельное расстояние между узлами должно быть сокращено
более чем вдвое. Если видно, что потери достигают критического
уровня, следует выбирать кабель с волокном 62.5/125 микрон. При
прокладке оптического кабеля нельзя допускать слишком малых
радиусов перегибов (возможен обрыв волокна, увеличиваются поте-
ри света). Кабели, относящиеся к разным кольцам FDDI, следует ?
разнести, в этом случае один бульдозер не сможет оборвать сразу k
оба кабеля.
FDDI-кадры используют заголовки, определяемые стандартом
IEEE 802.2 (LLC — Logical Link Control), который не имеет поля
тип, присутствующий в Ethernet-заголовке. FDDI и Ethernet имеют
разный порядок передачи битов, поэтому мосты и маршрутизаторы
между FDDI и Ethernet должны уметь выполнять соответствующие
преобразования. В силу особенностей маршрутизаторов не все про-
токолы могут быть реализованы на стыке FDDI и Ethernet (напри-
мер, DEC LAT работать не будет). Для решения проблемы созданы
гибридные приборы (brouter), которые для одних протоколов рабо-
тают как маршрутизаторы, являясь мостами для других. Эти при-'
боры для одних пакетов прозрачны, другие же пересылаются с ис-
пользованием инкапсуляции. Учитывая то, что FDDI может пере-
сылать до 400000 пакетов в секунду, схемы распознавания адресов
моста должна иметь соответствующее быстродействие.
СеТИ передачи данных. Метод доступа
191
Нетрадиционным для других сетей является концентратор,
используемый в FDDL Он позволяет подключить несколько при-
боров SAS-типа к стандартному FDDI-кольцу, создавая структуры
типа дерева. Но такие структуры несут в себе определенные огра-
ничения на длины сетевых элементов, так при использовании по-
вторителя удаление не должно превышать 1,5 км, а в случае мос-
та 2,5 км (одномодовый вариант). Несмотря на эти ограничения и
то что базовой топологией сетей FDDI является кольцо, звездооб-
разные варианты также имеют право на жизнь, допустимы и ком-
бинации этих топологий. В пределах одного здания подключение
целесообразно делать через концентратор, отдельные же здания объе-
диняются по схеме кольцо. К кольцу FDDI могут также легко под-
ключаться и субсети Token Ring (через мост или маршрутизатор).
Концентраторы бывают двух типов: DAS и SAS. Такие прибо-
ры повышают надежность сети, так как не вынуждают сеть при
отключении отдельного прибора переходить в аварийный режим
обхода. Применение концентраторов снижает и стоимость под-
ключения к FDDI. Концентраторы могут помочь при создании не-
больших групповых субсетей, предназначенных для решения специ-
фических задач (например, CAD, САМ или обработка изображений).
Новым устройством, используемым в FDDI-узлах, являются
межузловые процессоры (Internetwork Nodal Processor — INP), ко-
торые являются развитием идей Front End Processor (FEP). INP,
благодаря модульности, может помочь пользователю адаптировать-
ся к изменениям, постоянно происходящим в сетях, где он рабо-
тает. INP может выполнять функции многопротокольного моста
или маршрутизатора. Управление FDDI-оборудованием произво-
дится с помощью протокола SNMP и базы данных MIB. Предус-
мотрены некоторые дополнительные диагностические средства,
которые выявляют не только аппаратные сбои, но и некоторые
программные ошибки. Применение мостов для объединения FDDI-
сетей позволяет обеспечить высокую степень сетевой безопаснос-
ти и решить многие топологические проблемы, снять ограниче-
ния с предельного числа DAS-подключений (<500). Выбор между
мостом и маршрутизатором определяется тем, что важнее, сто-
имость, гибкость системы или высокая пропускная способность.
На рис. 4.1.2.7 показан пример использования сети FDDI для
Доступа нескольких субсетей к общему серверу без взаимного вли-
яния потоков данных. Сегменты 1 и 2 представляют собой субсе-
ти Ethernet (10 Мбит/с). Учитывая то, что FDDI имеет пропуск-
аю способность 100 Мбит/с, даже при подключении 10 субсетей
взаимовлияние их будет практически отсутствовать. Два кольца
192
Гпава 4
Рис. 4.1.2.7. Схема использования
кольца FDDI для расширения
пропускной способности локальной сети
Рис. 4.1.2.8. Варианты
связей в случае обрывов
волокон
FDDI, показанные на рис. 4.1.2.7, могут быть объединены друг с
другом через мост или маршрутизатор. Сетям FDDI благодаря мар-
керному доступу не знакомы столкновения в том виде, в каком они
существуют в Ethernet и это дает им определенное преимущество
перед сетями равного быстродействия, например перед быстрым
Ethernet (также 100 МГц). Существует версия FDDI приспособлен-
ная для передачи мультимедийной информации. Возможна реали-
зация FDDI на скрученных парах проводов.
При обрывах оптоволокна возможно частичное (при двух обры-
вах) или полное (при одном обрыве) восстановление связности сети.
4.1.3. Параллельный сетевой интерфейс HIPPI
Все рассматриваемые до сих пор системы передачи информации
использовали исключительно последовательный код. На разных
этапах эволюции телекоммуникаций предпочтение отдавалось и
параллельному и последовательному методам обмена данными. В
данный момент параллельный интерфейс сохранился только для
подключения принтеров. Главным преимуществом последователь-
ных схем передачи информации является экономия на кабелях.
Ниже описан еще один стандарт, где применен параллельный ин-
терфейс (начало разработки относится к 1987 году). HIPPI (High
Performance Parallel Interface, смотри ftp.network.com; http://
www.cern.ch/hsi/hippi/spec/introduc.htm; RFC2067,IP over HIPPI,
Сети передачи данных. Метод доступа
193
j.Renwick; RFC-1374, IP and ARP on HIPPI, J.Renwick, ANSI
X3T9.3/90-043, 1990 и X3T9.3/91-005) представляет собой быст-
родействующий параллельный интерфейс, рассчитанный на пропус-
кную способность 800 Мбит/с (но возможны версии со 100, 200 400
й 1600 Мбит/с). Разработка интерфейса выполнена в Лос-Аламосе.
Позднее на базе этого интерфейса была подготовлена идеология
сети.
Длина кода, передаваемого за один такт в HIPPI, составляет 32
разряда (версия HIPPI, рассчитанная на скорость 1600 Мбит/с, име-
ет длину кода 64 бита). Все пересылки являются симплексными.
Существует стандарт SuperHIPPI (HIPPI-6400, 6,4 Гбайт/с), кото-
рый описывает систему передачи данных в 8 раз более быстродей-
ствующую, чем HIPPI. Разработана версия последовательного HIPPI
на скорость обмена 1,2 Гбод для коаксиального и оптоволоконного
кабеля (до 10км; версия HIPPI-FC - Fiber Channel). Максимальное
расстояние между станцией и переключателем составляет 25 м.
Максимальное дистанция между станциями (станция-переключа-
тель-станция) равно 50 м. Предельное число станций зависит от
типа используемых переключателей. Переключатели могут взаимо-
действовать друг с другом (HIPPLSC), обеспечивая информацион-
ный обмен между станциями. Пример топологии сети HIPPI пред-
ставлен на рис. 4.1.3.1.
Рис. 4.1.3.1. Пример топологии сети HIPPI
(П - переключатели, С - станции]
HIPPI предполагает передачу данных по медному кабелю (или
оптическому волокну) только в одном направлении по схеме связи
точка-точка, но два канала HIPPI могут обеспечить и двунаправлен-
ный обмен данными. Передающий кабель может содержать 50/100
окрученных пар или соответствующее число оптических волокон.
Длина пакета данных может варьироваться. Протокол HIPPI рас-
? Зак. № 3430 Семенов
194
Гпава 4
считан на работу в реальном масштабе времени при суммарных
длинах кабелей до десятков километров. Стандартный блок дан-
ных содержит 256 слов (1024 или 2048 байт). Для контроля кор-
ректности передачи предусмотрен контроль по четности для каждо-
го байта на шине, кроме того, для каждого блока данных вычисля-
ется «продольная» контрольная сумма (LLRC - Length/Longitudinal
Redundancy Checkword). На рис. 4.1.3.2 показана схема передачи
данных в рамках протокола HIPPL На каждое соединение может
быть передано любое число пакетов, пакет в свою очередь может
содержать любое число блоков. Время между пакетами не регла-
ментировано и может меняться, оно зависит от потока данных и
протокола верхнего уровня.
1 -поле Соединение
Пакет Пакет Пакет
Пакет
Блок Блок Блок Блок Блок
256 слов + LLRC
Рис. 4.1.3.2. Структура передаваемой информации
(каждое слово содержит 32 или 64 бита)
Каждый пакет содержит в конце субполе контроля четности.
Все сигналы кроме соединения (Interconnect) используют приемни-
ки и передатчики эмиттерно-связанной логики (ECL). Формат I-
поля показан на рис 4.1.3.3.
12 112 1 12 12
L W D PS С Адрес отправителя Адрес получателя
Рис. 4.1.3.3. Формат 1-поля пакета HIPP!
Поле L=1 - локально заданный формат; W=1 указывает на 64-
битное соединение; D=1 отмечает смену положения адресов отпра-
вителя и получателя; PS - биты выбора пути (Path Selection); С -
задержка вызова при занятой линии (camp-on; переключатель не
разрывает соединения при занятом получателе, а ждет его освобож-
Сети передачи данных. Метод доступа
195
дения). 12-битовые адреса отправителя и получателя часто делятся
на 6-битовые секции, определяющие адрес переключателя и номер
порта. HIPPI-IPI (Intelligent Peripheral Interface) представляет со-
бой быстродействующий интерфейс периферийных устройств, выпол-
няющий команды SCSI. Расширение HIPPI-LE (Link Encapsulation)
обеспечивает поддержку IEEE 802.2.
При расстояниях до 25 метров используется кабель, содержа-
щий 50 скрученных пар. Такты часов следуют с периодом 40 нсек.
В сетях HIPPI предусмотрен транзит пакетов формата TCP/IP. Блок-
схема канала HIPPI показана на рис. 4.1.3.4.
Рис. 4.1.3.4. Блок-схема канала HIPPI
Существуют документы, регламентирующие работу системы пере-
дачи информации HIPPI для основных уровней интерфейса, начиная
с физического. Предусмотрена работа HIPPI с протоколами TCP/IP.
4.1.4. Сети IEEE 802.11
Технология беспроводных сетей развивается довольно быстро.
Эти сети удобны для подвижных средств в первую очередь. Наибо-
лее перспективным представляется проект IEEE 802.11, который
Должен играть для радиосетей такую же интегрирующую роль как
802.3 для сетей Ethernet и 802.5 для Token Ring. В протоколе
802.11 используется тот же алгоритм доступа и подавления столк-
н°вений, что и в 802.3, но здесь вместо соединительного кабеля
Исп°льзуются радиоволны (Рис. 4.1.4.1.)
196
Гпава 4
Рис. 4.7.4.7. Схема беспроводной локальной сети
Стандарт 802.11 предполагает работу на частоте 2.4-2.4835 ГГц 1
при использовании 4FSK/2FSK FHSS модуляции, мощность пере- ’’
датчика 10мВт-1Вт. Максимальная пропускная способность сети .
составляет 2 Мбит/с.
В 1992 году страны члены ЕС выделили диапазон частот 1,89-
1,9 ГГц для целей построения сетей, базирующихся на применение
радиосигналов (стандарт DECT - Digital European Cordless
Telecommunications). Этот стандарт был разработан для целей пере-
дачи данных и голоса в системах сотовой связи. В США для этих
же целей используются широкополосные системы с шумоподобным
сигналом (SST - ШПС). Для подобных же целей выделены также
частотные диапазоны 18 и бОГГц (диапазон 2,4 ГГц сильно пере-
гружен и «засорен» шумами). Существуют уже системы базирую-
щиеся на Ethernet и Token Ring.
При относительно малых расстояниях проблем обычно не воз-
никает и работу беспроводной сети действительно можно аппрокси-
мировать алгоритмом CSMA. Но в случае, когда расстояние между
передатчиком и приемником сравнимо с радиусом надежной связи,
отличие от традиционных сетей становится значительным. Ведь
для радиосетей важна интерференция на входе приемника, а не на
выходе передатчика (как в CSMA). Рассмотрим вариант сети, изоб-
раженный на рис. 4.1.4.2. Если передачу осуществляет узел А (ва- '
риант I), узел С находится вне его радиуса действия и может ре- \
шить, что можно начать передачу. Излучение передатчика С может *
вызвать помехи на входе узла В (проблема скрытой станции).
В случае, когда передачу ведет узел В (вариант II), узел С может
решить, что начало передачи сообщения узлу D не возможно, так
как в зоне С детектируется излучение станции В (проблема засве-
ченной станции). Таким образом, в радиосетях, прежде чем начать *
передачу данных надо знать, имеется ли радио активность в зоне
приемника-адресата. В коротковолновых сетях возможна одновре-
Сеги передачи данных. Метод доступа
197
Рис. 4.1.4.2. Схема взаимодействия узлов в беспроводной сети
(МАСА)
менная передача для нескольких адресатов, если они находятся в
разных зонах приема.
Ранние протоколы беспроводных локальных сетей базировались,
на схеме МАСА (Multiple Access with Collision Avoidance),разрабо-
танной Ф. Карном в 1990 году. Эта схема является основой стан-
дарта IEEE 802.11. В этой схеме отправитель запрашивает получа-
теля послать короткий кадр, будучи принят соседями, предотвратит
их передачу на время последующей передачи сообщения адресату.
На рис. 4.1.4.2 узел В посылает кадр RTS (Request То Send) узлу
С. Этот кадр имеет всего 30 октетов и содержит поле длины после-
дующего сообщения. Узел С откликается посылкой кадра CTS (Clear
То Send), куда копируется код длины последующего обмена из кад-
ра RTS. После этого узел В начинает передачу. Окружающие стан-
ции, например D или Е, получив CTS, воздерживаются от начала
передачи на время, достаточное для передачи сообщения оговорен-
ной длины. Станция А находится в зоне действия станции В, но не
станции С и по этой причине не получит кадр CTS. По этой причи-
не станция А может начинать передачу, если хочет и не имеет дру-
гих причин, препятствующих этому. Несмотря на все предосторож-
ности, коллизия может иметь место. Например, станции А и С могут
одновременно послать кадры RTS станции В. Эти кадры будут не-
избежно потеряны, после псевдослучайной выдержки эти станции
могут совершить повторную попытку (как в ETHERNET).
В 1994 году схема МАСА была усовершенствована и получила
название MACAW. Было отмечено, что без подтверждения на ка-
нальном уровне потерянные кадры не будут переданы повторно,
пока транспортный уровень много позднее не обнаружит их отсут-
ствия. В усовершенствованной схеме требуется подтверждение по-
лучения любого информационного кадра, добавлен также механизм
°повещения о перегрузке.
198
Гпава 4
К сожалению беспроводные, особенно мобильные каналы крайне
ненадежны. Потери пакетов в таких каналах весьма вероятны.
Понижение скорости передачи, как правило, не приводит к пониже-
нию вероятности потери. Кроме того, проходы от отправителя к
получателю здесь неоднородны и могут включать в себя сегменты с
различными методами транспортировки данных (проводные и бес-
проводные). В таких структурах бывает полезно разбить канал на
две последовательные связи (indirect TCP). Преимуществом такой
схемы является то, что оба виртуальных канала являются однород-
ными. Таймауты в одном из соединений заставят отправителя за-
медлить темп передачи, в то время как таймауты во втором —
могут ускорить обмен. Да и все остальные параметры связей могут
оптимизироваться независимо. Основной недостаток этого приема
заключается в нарушении базового принципа организации ТСР-со-
единений на основе сокетов, здесь получение подтверждения отпра-
вителем не означает благополучной доставки. В 1995 году была
предложена схема, не нарушающая TCP-семантику. В этой схеме
вводится специальный агент-наблюдатель, который отслеживает
состояние кэшей отправителя и получателя и посылает подтверж-
дения. Этот агент при отсутствии своевременного подтверждения
запускает процедуру повторной посылки сегмента, не информируя
об этом первичного отправителя. Механизмы подавления перегруз-
ки запускаются в этом варианте только при перегрузке проводной
секции канала. При потерях реализуется выборочная пересылка
сегментов.
При работе с UDP также возникают некоторые трудности. Хотя
известно, что UDP не гарантирует доставки, большинство программ,
предполагает, что вероятность потери невелика. Программы исполь-
зуют такие способы преодоления потерь, которые при высокой веро-
ятности потери просто не срабатывают. Многие приложения пред-
полагают наличие достаточного запаса пропускной способности, чего
в случае мобильной связи обычно нет.
4.1.4.1 Мобильные телекоммуникации
В 80-х - 90-х годах весьма активное развитие получила мобиль-
ная телефония. В последнее время услуги мобильной связи стали
применяться и для передачи цифровых данных. Мобильные теле-
коммуникации использует диапазоны в интервале 50 МГц - 1 ГГц.
Мобильные системы работают при малых выходных мощностях
передатчика, что ограничивает размер зоны приема. Вне этой зоны
другие передатчики могут функционировать независимо. Такие зоны
Сети передачи данных. Метод доступа
199
называются сотами (ячейками). По аналогии с пчелиными сотами
их часто изображают шестигранными, хотя реально они могут иметь
самую причудливую форму в зависимости от профиля местности.
Ячейки должны перекрываться, так как показано на рис. 4.1.4.1.1.
Рис. 4.1.4.1.1. Схема расположения ячеек при сотовой связи
Светлыми кружками отмечены реальные границы ячеек, их пе-
рекрытие должно обеспечить перекрытие всей зоны телекоммуника-
ций. Сигнал передатчика падает по мере удаления от центра ячей-
ки, где он должен быть расположен. Там же должен находиться и
приемник. В пределах ячейки предусмотрено несколько каналов
для приема/передачи, разнесенные по частоте. Эти каналы управля-
ются центральным коммутатором ячейки (MSC - Mobile-Service
switching Centre). Пользователь использует канал, до тех пор, пока
находится в пределах ячейки. При переходе в соседнюю ячейку он
получает новый канал (hand-off), что должно быть практически
незаметно для пользователя.
В рамках американского стандарта первого поколения AMPS
(Advanced Mobile Phone Service) формируется 40 МГц канал в интерва-
ле 800-900 МГц. Этот диапазон делится пополам, 20 МГц выделяется
Для передачи и столько же для приема. Данные диапазоны делятся в
свою очередь на 666 двусторонних каналов, каждый по 30 Кгц.
Эти каналы расщепляются на 21 субканал, сгруппированные по 3.
Обычно, как показано на рис. 4.1.4.1.1, гексагональные ячейки груп-
пируются по 7 (центральная и 6 ее соседей). Имея 666 каналов,
можно выделить три набора по 31 каналу для каждой ячейки,
акая схема удобна в случае возникновения необходимости увели-
Чения числа каналов, для этого достаточно уменьшить размер ячей-
200
Гпава 4
ки - число ячеек увеличится и, как следствие, увеличится число
каналов на единицу площади. В хорошо спланированной сети плот-
ность ячеек пропорциональна плотности пользователей.
AMPS базируется на аналоговой модуляции, существует еще
полдюжины аналогичных не стыкуемых друг с другом систем.
В последнее время аналоговая модуляция повсеместно вытесняется
цифровой. В Европе принят единый стандарт для систем мобиль-
ной связи GSM (Groupe Special Mobile, второе поколение мобильных
средств связи). GSM использует диапазоны 900 и 1800 МГц. Это
довольно сложный стандарт, его описание занимает около 5000 стра-
ниц. Идеологически система имеет много общего с ISDN (например,
переадресацию вызовов). GSM имеет 200 полнодуплексных кана-
лов на ячейку, с полосой частот 200 Кгц, что позволяет ей обеспе-
чить пропускную способность 270,833 бит/с на канал. Каждый из
124 частотных каналов делится в GSM между восемью пользовате-
лями (мультиплексирование по времени). Теоретически в каждой
ячейке может существовать 992 канала, на практике многие из них
недоступны из-за интерференции с соседними ячейками.
Система мультиплексирования по времени имеет специфичес-
кую структуру. Отдельные временные домены объединяются в муль-
тифреймы. Упрощенная схема структуры показана на рис. 4.1.4.1.2.
Каждый временной домен (TDM) содержит 148-битовый кадр
данных, начинающийся и завершающийся последовательностью из
Рис. 4.1.4.1.2. Структура кадров в GSM
Сети передачи данных. Метод доступа
201
трех нулей. Кадр имеет два 57-битовых поля данных, каждое из
которых имеет специальный бит, который указывает На то, что ле-
ясит в кадре — голос или данные. Между информационными поля-
ми размещается поле синхронизации (Sync). Хотя информацион-
ный кадр имеет длительность 547 мксек, передатчику позволено
передавать его лишь раз в 4615 мксек, так остальное время зарезер-
вировано для передачи другими станциями. Если исключить на-
кладные накладные расходы каждому соединению выделена полоса
(без учета сжатия данных) 9600 Кбит/с.
Восемь информационных кадров образуют TDM-кадр, а 26 TDM-
кадров объединяются в 128-микросекундный мультифрейм. Как
видно из рисунка 4.1.4.1.2 позиция 12 в мультифрейме занята для
целей управления, а 25-я зарезервирована для будущих примене-
ний. Существует также стандарт на 51-позиционный мультифрейм,
содержащий больше управляющих вставок. Управляющий канал
используется для регистрации, актуализации положения и форми-
рования соединения. Каждая стационарная станция поддерживает
базу данных, где хранится информация обо всех обслуживаемых в
данный момент клиентах. Общий управляющий канал делится на
три субканала. Первый служит для обслуживания вызовов (paging
channel), второй (random access channel) реализует произвольный
доступ в рамках системы ALOHA (устанавливаются параметры вы-
зова). Третий субканал служит для предоставления доступа (access
grant channel).
Алгоритмы обслуживания мобильной связи достаточно нетри-
виальны. Из рисунка 4.1.4.1.1 видно, что области перекрываются
(иначе бы существовали «мертвые» зоны без связи). Существуют
даже субобласти, накрываемые тремя MSC. По это причине проце-
дура должна четко определить, с каким из MSC клиент должен
быть связан, и при каких условиях его следует переключить на
соседний MSC, не прерывая связи. Система должна также компен-
сировать падение сигнала, иногда достаточно резкое, чтобы обеспе-
чить комфортную связь и безошибочную передачу информации. По
этой причине частота ошибок (BER) в таких сетях составляет 10‘3
(против 106 для обычных стационарных цифровых каналов связи).
Следует иметь в виду, что в условиях города сигнал падает пропорци-
онально не квадрату, а четвертой степени расстояния. На распростра-
нение радиоволн в городе влияют ориентация улиц (до 20 дБ), тунне-
Ли (до 30 дБ) и листва деревьев в сельской местности (до 18 дБ).
CSM — система, базирующаяся в основном на коммутации ка-
^алов- Применение модема на переносной ЭВМ позволяет подклю-
чен к сети Интернет. Но здесь не все беспроблемно. Базовые
202
Гпава 4
станции временами теряют связь друг с другом (переключение с
канала на канал), что может приводить к 300 миллисекундным’
потери данных. Как уже говорилось выше, здесь высока вероят-
ность ошибок. Так, нажав клавишу «а», можно получить на экране
букву «я». Да и расценка за минуту работы в Интернет здесь весь-
ма высока. В связи с этим был разработан стандарт на цифровую
систему коммутации пакетов CDPD (Cellular Digital Packet Data).
Система работает поверх AMPS. Система обеспечивает информаци-
онную пропускную способность на уровне 9,6 Кбит/с. CDPD до-
вольно точно следует модели OSI. В CDPD определены три типа
интерфейсов. Е-интерфейс (внешний по отношению CDPD-провай-
деру) соединяют CDPD-область с определенной сетью. 1-интерфейс
(внутренний по отношению CDPD-провайдеру) соединяет CDPD-об-
ласти друг с другом. A-интерфейс (эфирный) используется для связи
базовой станции с мобильной ЭВМ. В функции этого интерфейса
входит сжатие и шифрование данных, а также исправление оши-
бок. 274-битные блоки сжатой и зашифрованной информации вкла- ;
дываются в 378-битовые блоки, предназначенные для коррекции
ошибок согласно алгоритму Рида-Соломона. К каждому такому блоку
добавляется семь 6-битовых флагов.. Результирующие блоки имеют >
420 бит и передаются в виде семи 60-битовых микроблоков. Эти I
микроблоки передаются к базовой станции со скоростью 19,2 Кбит/ '
с. Канал с аналогичным быстродействием создается для пересылки
информации в противоположном направлении. При обмене приме- 1
няется мультиплексирование с делением по времени. При этом вре-
менные домены имеют длительность 3,125 мсек (60 бит).
Когда мобильная ЭВМ хочет что-то передать, прослушивается
канал базовой станции и проверяется флаг, сообщающий, свободен
ли входной канал базовой станции. Если канал занят, ЭВМ вместо
ожидания до очередного временного домена, пропуская псевдослу- ..
чайное число временных доменов, после чего повторяет попытку.
Если повторная попытка неудачна, время ожидания увеличивается
примерно вдвое. Когда, наконец, ЭВМ обнаруживает, что канал сво-
боден, она начинает пересылку своих микроблоков. Предусмотрена J
процедура, препятствующая попытке всех ЭВМ, готовых к передаче,
захватить канал, как только он оказался свободным. Этот алго-
ритм называется DSMA (Digital Sense Multiple Access). Но, несмотря
на применение DSMA, столкновение все же возможно, так как две
или более ЭВМ могут воспользоваться одним и тем же временным
доменом для начала передачи. Для выявления столкновений пре- ?
дусмотрен специальный флаг, который позволяет судить, корректно
ли доставлен предыдущий микроблок. К сожалению, это происхо- *
Сети передачи данных. Метод доступа
203
дит не мгновенно, а лишь после нескольких микроблоков. При об-
наружении ошибки передача прерывается. Следует иметь в виду,
что информационный обмен имеет более низкий приоритет по отно-
шению передачи голосовых данных. Предусмотрена возможность
создания выделенных CDPD-каналов.
GSM использует довольно сложную комбинацию методик ALOHA,
TDM и FDM. CDPD для передачи одиночных кадров не вполне со-
гласуется с алгоритмом CSMA. Впрочем, существует еще один метод
формирования радио каналов — CDMA (Code Division Multiple Access).
Метод CMDA принципиально отличается от описанных выше,
которые использовали для демультиплексирования доступа FDM,
TDM или ALOHA. CMDA позволяет каждой станции осуществлять
передачу во всем частотном диапазоне постоянно. Множественные
передачи реализуются с привлечением теории кодирования. Здесь
предполагается, что сигналы, совпадающие по времени складывают-
ся линейно. В CMDA каждый бит-тайм делится на m коротких
интервалов, называемых чипами. Обычно используется 64 или 128
чипов на бит. Каждой станции присваивается уникальный т-бит-
ный код (chip sequence). Чтобы передать 1 бит станция посылает
свой чип-код. Для простоты далее будем предполагать, что ш=8.
Для того чтобы послать нулевой бит, посылается дополнение чип-
кода по модулю один. Никакие другие кодовые последовательности
не разрешены. Например, пусть станции 1 поставлен в соответствие
чип-код 01010101, тогда при посылке логической 1 она отправляет
код 01010101, а при отправке логического нуля — 10101010. Если
имеется канал с полосой 1 МГц и 100 станций с FDM, то каждая из
них получит по 10 Кгц (10 Кбит/с при 1 бите на Гц). При CDMA
каждая станция использует весь частотный диапазон, так что будет
получена скорость передачи 1 мегачип в секунду. При менее 100
чипов на бит CMDA обеспечивает большую пропускную способность,
чем FDM. Для упрощения введем двуполярную нотацию, где нулю
соответствует -1, а единице +1. Тогда чип-код станции 1 получит
вид -1 +1 -1 +1 -1 4-1 -1 +1. Каждая из станций получает уникаль-
ный чип-код. Чип-коды можно представить в виде ш-компонент-
ных векторов. Чип-коды выбираются так, что все они попарно орто-
гональны (не любой уникальный чип-код пригоден, так, если стан-
ция 1 имеет чип-код 01010101, то станция 2 не может иметь чип-код
Ю101001, но чип-код 10100101 вполне допустим). Математически
Это можно выразить следующим образом:
1 m
H-G=—VHjGi-0
mfr
204
Гпава 4
где Н. и G. компоненты векторов чип-кодов Н и G. Это равенство
указывает, что число разных компонентов равно числу равных. Если
G и Н ортогональны, то и =0. В то же время:
G.G = ±gG,G, = , [1]
Когда сигналы от разных станций совпадают во времени и скла-
дываются, принимающая сторона легко может вычислить наличие
соответствующей компоненты. Если компоненты суммарного сиг-
нала S., то компоненты G. вычисляются с помощью произведения
S.*H. Действительно, если:
S =F+G+H
S •H = (F+ G+H)«H: = F«H + G«H+H*H = 0 + 0 + 1= 1
Здесь первые два слагаемых равны нулю в силу ортогональнос-
ти выбранных чип-кодов. Последнее же слагаемое равно 1 согласно
[1]. Во всех этих рассуждениях предполагалось, что все станции
работают синхронно и начинают передачу чип-кодов одновременно.
Для пояснения метода рассмотрим конкретный пример в выше
предложенной нотации. Присвоим станциям F, G, Н, I ортогональ-
ные чип-коды:
F=01010101 -+ -1 +1 -1 +1 -1 +1 -1 +1
G=10100101 -+ +1 -1 +1 -1 -1 +1 -1 +1
Н=10011001 -+ +1 -1 -1 +1 +1 -1 -1 +1
1=11111111 -+ +1 +1 +1 +1 +1 +1 +1 +1
Теперь рассмотрим четыре варианта наложений:
Только F -+ S^t-l +1 -1 +1 -1 +1 -1 +1]
F+I -+ S2=[0 +2 0 +2 0 +2 0 +2]
F+G+H -+ S3=[+l -1 -1 +1 -1 +1 -3 +3]
F+G+H -+ S4=[-l +1 -3 +3 +1 -1 -1 +1]
Для выявления наличия компоненты G выполним операции
«умножения» согласно описанным выше правилам.
SX*G =[-1 -1 -1 -1 +1 +1 +1 +1]/8=0 (G отсутствует)
S2*G =[0 -2 0 -2 — +2 0 +2]/8=0 (G отсутствует)
S3*G =[+1 +1 -1 -1 +1 +1 +3 +3]/8=1 (G имеется — передана
логическая 1)
S4*G =[-1 -1 -3 -3 -1 -1 +1 +1]/8=-1 (G имеется — передан
логический 0)
Хотя теоретически здесь все прекрасно, наложение слишком боль-
шого числа чип-кодов может создать проблемы и, в конечном итоге»
привести к ошибкам.
СеТи передачи данных. Метод доступа
205
4.1- 5. Двойная шина с распределенной очередью (DQDBJ
Сети с двойной шиной и распределенной очередью (DQDB —
Distributed Queue Dual Bus) используют алгоритм доступа, называе-
мый распределенное переключение пакетов (QPSX - Queued-Packet
Distributed-Switch). Здесь используется две несвязанные однонап-
равленные шины, сформированные из цепочки соединений точка-
точка. Описание работы сети содержится в документе IEEE 802.6.
Пропускная способность сети составляет 150 Мбит/с (планируется
600 Мбит/с). Максимально возможная длина сети составляет 160
км. Максимальное число узлов равно 512. В качестве транспортной
среды можно использовать одно- и мультимодовое оптическое во-
локно (длина волны 1300 нм). Схема кодирования 8В/9В при пред-
ставлении сигнала NRZI. средняя частота ошибок (BER) составля-
ет 109. По сетям DQDB пересылаются также как и по АТМ-кана-
лам ячейки фиксированного размера (L=53 байта). Формат поля
данных совместим с некоторыми типами AAL. Формат пакета по-
казан на рис 4.1.5.1.
511 44 11
Заголовок ST MID Информация LEN CRC
Область,
◄-------------- контролируемая ---------------►
CRC
Рис. 4.1.5.1. Формат ячейки DQDB
(цифры в верхней части рисунка характеризуют длины полей]
Поле ST (Segment Туре) характеризует тип сегмента. Поле MID
(Message IDentifier) представляет собой идентификатор сообщения.
LEN -характеризует длину поля данных, a CRC - это контрольная
сумма ячейки. Когда станция намерена передать ячейку, она долж-
на знать, справа или слева от нее находится место назначения.
Если место назначения справа, отправитель использует шину А, в
противном случае передача производится по шине В. Для ввода
Данных на шину применяется схема проволочного ИЛИ. По этой
причине обесточенная станция не вызовет отказа всего сегмента
сети- Станция образуют очередь для передачи в порядке поступле-
ния заявок (FIFO). Структура заголовка ячейки показана на рис.
•5.2 она весьма схожа с той, что имеет ячейка ATM.
пом °Ле ACF (Access Control Field) служит для управления доступ
Поле VCI (Virtual Cannel Identifier) — виртуальный идентифи-
°Р канала. Далее следуют поля:
206
Гпава 4
8 7 6 5 4 3 2 1 Номера бит
В случае интерфейса сеть-
1 сеть весь этот байт
2 используется для VPI
ACF
VCI
VCI
VCI PT CLP
НЕС
3
4
5
Рис. 4.1.5.2. Формат заголовка DQDB -пакета
PT (Payload Туре) 4 бита типа данных (коды аналогичны ATM);
CLP (Cell Loss Priority) — уровень приоритета при потере паке-
та. Указывает на то, какой приоритет имеет ячейка, и бу-
дет ли она отброшена в случае переполнения канала (как
и в ATM);
НЕС (Header Error Control) поле контроля ошибок (CRC заго-
ловка).
Ячейка DQDB отличается от ячейки ATM тем, что не содержит
поля VPI (идентификатор виртуального пути), а поле VCI имеет на
4 бита больше. Упрощенная схема подключения узлов к сети пока-
зана на рис. 4.1.5.3. Шины А и Б служат для передачи ячеек
противоположных направлениях. Если станция намерена передать
ячейку по шине Б, она должна выполнить резервирование заранее
на шине А, осуществив запись 1 в бит Request соответствующей
ячейки.
Каждый из узлов подключен к обеим шинам. По каждой из
шин всегда циркулирует фиксированное число контейнеров. Содер-
жимое контейнеров может передаваться с одной шины на другую*
В сети DQDB используются следующие типы сегментов:
Рис. 4.1.5.3. Топологии сети DQDB
Сети передачи данных. Метод доступа 207
. одиночный сегмент (не нужно никакой сегментации);
• первый сегмент (первая ячейка сегментированного МАС-кадра);
. промежуточный сегмент фрагментируемого МАС-кадра;
• последний сегмент (последняя ячейка сегментированного МАС-
кадра)
Поле MID остается идентичным для всех DQDB ячеек сегменти-
рованного МАС-кадра. Поле ACF содержит биты BUSY и REQUEST,
которые используются в рамках механизма QPSX. Бит BUSY=1
указывает на то, что ячейка занята. Бит REQUEST=1 устанавлива-
ется узлом, который ждет возможности начать передачу. В каждом
узле имеется счетчик запросов RC (Request Counter), который фик-
сирует число узлов, ожидающих передачи и стоящих в очереди впе-
реди данного узла. Содержимое счетчика увеличивается всякий раз,
когда по шине А проходит контейнер с битом BUSY=1. Счетчик
декрементируется при появлении на шине Б контейнера со свобод-
ным битом REQUEST. Когда станция сама намеривается передать
кадр, содержимое RC переносится в реверсивный счетчик DC, а в
регистр RC заносится нуль. Код в DC уменьшается на единицу при
получении контейнера с битом BUSY=1. DC определяет положение
запроса в очереди (нуль соответствует началу очереди). Если полу-
чен контейнер с REQUEST=0 и DC=O, узел может передать ячейку
по данной шине. Каждый узел может осуществлять передачу и при-
ем по любой из шин А и Б. В сети DQDB предусмотрено 4 уровня
приоритетов и каждый узел поддерживает до 5 очередей с RC и DC
счетчиками для каждой из очередей. Для индикации приоритета в
поле ACF предусмотрено 4 двоичных разряда (Rl, R2, R3 и R4).
Высшему приоритету соответствует R4. Схема сегментирования МАС-
кадра при передаче с помощью DQDB ячеек показана на рис. 4.1.5.4.
Рис. 4.1.5.4. Сегментация МАС-кадра
ч ^ети DQDB могут иметь размер до 160 км при скорости переда-
Данных 44,736 Мбит/с (ТЗ).
208
Гпава 4
4.7.£>. Канальный протокол Fibre Channel
Известно, что производительность микропроцессоров рабочих
станций удваивается каждые 18 месяцев. Каждому миллиону опе-
раций в секунду процессора должна соответствовать пропускная
способность ввода/вывода, равная мегабиту в секунду (закон Amdahl).
По этой причине требования к широкополосности телекоммуника-
ционных каналов уже сегодня лежит в диапазоне от 100 до 1000
Мбит/с. Наиболее популярные скоростные сети Fast Ethernet, FDDI
и ATM соответствуют этим требованиям на пределе. Уже одно это
заставляет обратить внимание на такие протоколы как гигабитный
Ethernet и (стандарт ANSI). Fibre Channel сочетает в себе преимуще-
ства канальных и сетевых технологий. Работы по разработке стан-
дарта FC начаты группой ANSI в 1988 году. К настоящему времени
разработано более 20 регламентирующих документов. В настоящее
время Fibre Channel конкурирует как с Ethernet, так и с SCSI. Смот-
ри www.prz.tu-berlin.de/docs/html/EANTC/INFOSYS/fibrechannel/
detail, http://www.fibrechannel.com/technology/physical.htm и http:/
/www.ancor.com. http://www.iol.unh.edu/training/fc/fc_tutorial.html.
Последний уже сейчас превосходит по быстродействию существую-;
щие сети в 10-100 раз. Он легко стыкуется с протоколами локаль-?
ных и региональных сетей. Fibre Channel имеет уникальную систе-
му физического интерфейса и форматы кадров, которые позволяют?
этому стандарту обеспечить простую стыковку с канальными прото-
колами IPI (Intelligent Peripheral Interface),SCSI,HIPPI,ATM,IP И5
802.2. Это позволяет, например, организовать скоростной канал между?
ЭВМ и дисковой накопительной системой RAID; Быстродействие'
сетей Fibre Channel составляет nt 100Мбайт/с при длинах канала
10 км и более. Предусмотрена работа и на меньших скоростях?
(например, 12,5 Мбайт/с). Предельная скорость передачи составляв
ет 4,25 Гбод. В качестве транспортной среды может использоваться
одномодовое или мультимодовое оптическое волокно. Допускается
применение медного коаксиального кабеля и скрученных пар (при
скоростях до 200 Мбайт/с). Fibre Channel имеет шесть независимых
классов услуг (каждый класс представляет определенную стратегий
обмена информацией), которые облегчают решать широкий диапа-
зон прикладных задач:
Класс 1 Соединение с коммутацией каналов по схеме точка-топ-
ка (end-to-end) между портами типа N_Port Класс удобен для ауД#0
и видео приложений, например, видеоконференций. После установ-
ления соединения используется вся доступная полоса пропускания
канала. При этом гарантируется, что кадры будут получены в тоН
же порядке, в каком они были посланы.
Сеги передачи данных. Метод доступа
209
Класс 2 Обмен без установления соединения с коммутацией па-
кетов, гарантирующий доставку данных. Так как соединение не ус-
танавливается, порт может взаимодействовать одновременно с лю-
бым числом портов типа N_PORT, получая и передавая кадры.
Здесь не может быть гарантии того, что кадры будут доставлены в
том же порядке, в каком были переданы, (за исключением случаев
соединения точка-точка или арбитражное кольцо). В этом классе
допустимы схемы управления потоком буфер-буфер и точка-точка.
Этот класс характерен для локальных сетей, где время доставки
данных не является критическим.
Класс 3 Обмен дейтограммами без установления соединения и
без гарантии доставки. Схема управления потоком буфер-буфер.
Применяется для каналов SCSI.
Класс 4 Обеспечивает выделение определенной доли пропускной
способности канала с заданным значением качества обслуживания
(QOS). Работает только с топологией структура (Fabric), где соеди-
няются два порта типа N_Port. При этом формируется два вирту-
альных соединения, обслуживающих встречные потоки данных.
Пропускная способность этих соединения может быть различной.
Как и в классе 1, здесь гарантируется порядок доставки кадров.
Допускается одновременное соединение более чем с одним портом
типа N_Port. Используется схема управления потоком буфер-бу-
фер. Каждое виртуальное соединение управляется независимо с по-
мощью сигнала-примитива FC_RDY.
Класс 5 Предполагает изохронное обслуживание. Регламентиру-
ющие документы находятся в процессе подготовки.
Класс 6 Предусматривает мультикастинг-обслуживание в рамках
топологии типа структура (Fabric). При этом используется стан-
дартный адрес 0xFFFFF5. N_Port становится членом мультикаст-
группы путем регистрации по адресу 0xFFFFF8.
Fibre Channel использует пакеты переменной длины (до 2148
байт), содержащие до 2112 байт данных. Такая длина пакета за-
метно снижает издержки, связанные с пересылкой заголовков (эф-
фективность 98%). С этой точки зрения в наихудшем положении
оказывается ATM (83% эффективность 48 байт данных при 53
байтном пакете). Только FDDI превосходит Fibre Channel по этому
параметру (99%). В отличие от других локальных сетей, использу-
юЩих 6-октетные адреса, Fibre Channel работает с 3-байтовыми ад-
ресами, распределяемыми динамически в процессе выполнения опе-
рации LOGIN. Адрес OxFFFFFF зарезервирован для широковеща-
тельной адресации. Адреса же в диапазоне OxFFFFFO-OxFFFFFE
Делены для обращения к «структуре» (Fabric)^ мультикастинг-
210
Гпава 4
серверу и серверу псевдонимов (Alias-Server). N_Port передает кад-
ры от своего Source lD (S_ID) к Destination lD (D ID). До выпол-
нения операции Fabric LOGIN S_ID порта не определено. В случае
арбитражного кольца применяются 3-октетные адреса AL_PA, зада-
ваемые при инициализации кольца. Для однозначной идентифика-
ции узлов используются 64-битовые имена-идентификаторы.
Fibre Channel превосходит другие сети и по некоторым экономи-
ческим параметрам (см. табл. 4.1.6.1).
Таблица 4.1.6.1 [www.ancor.com/ctspr97.htm]
Сеть Стоимость за Мбит/сек
FDDI 109,1$ США
Fast Ethernet 12,8$
ATM 23,8$
Fibre Channel 9,5$
Цены вещь непостоянная, но здесь следует учитывать относи-
тельный их характер, да и в случае начала массового производства
цены на Fibre Channel пожалуй, будут падать быстрее, чем для дру-
гих сетей (они этот этап уже прошли).
Формат пакетов в сетях Fibre Channel показан на рис. 4.1.6.1.
Здесь используются 24-битовые адреса, что позволяет адресовать до
16 миллионов объектов.«Сеть может строить соединения по схеме
точка-точка, допускается и кольцевая архитектура с возможностью
арбитража (FC-AL) и другие схемы (например, «ткань соединений»
(Fabric), допускающее большое число независимых обменов одно-
временно). Схема кольцевого соединения показана на рис. 4.1.6.2.
К кольцу может быть подключено до 128 узлов. Протокол Fibre
Channel предусматривает 5 уровней, которые определяют физичес-
кую среду, скорости передачи, схему кодирования, форматы пакетов,
управление потоком и различные виды услуг. На физическом уровне
(FC-PH 1993 год) предусмотрены три подуровня. FC использует опти-
ческие волокна диаметром 62,5, 50мкм и одномодовые. Для обеспече-
ния безопасности предусмотрен опционный контроль подключенности
оптического разъема (OFC). Для этого передатчик время от времени,
посылает короткие световые импульсы приемнику. Если приемник
получает такой импульс, процесс обмена продолжается.
FC-О определяет физические характеристики интерфейса и среды,
включая кабели, разъемы, драйверы (ECL, LED, лазеры), передатчики и
приемники. Вместе с FC-1 этот уровень образует физический слой.
FC-1 определяет метод кодирования/декодирования (8В/10В) и
протокол передачи, где объединяется пересылка данных и синхро-
низирующей информации.
Сети передачи данных. Метод доступа
211
FC-2 определяет правила сигнального протокола, классы услуг,
топологию, методику сегментации, задает формат кадра и описывает
передачу информационных кадров.
FC-3 определяет работу нескольких портов на одном узле и
обеспечивает общие виды сервиса.
FC-4 обеспечивает реализацию набора прикладных команд и
протоколов вышележащего уровня (например, для SCSI, IPI, IEEE
802, SBCCS, HIPPI, IP, ATM и т.д.)
FC-0 и FC-1 образуют физический уровень, соответствующей стан-
дартной модели ISO.
Стандарт FC допускает соединение типа точка-точка, арбитраж-
ное кольцо и структура (верх, середина и низ рисунка 4.1.6.2).
Кольцевая архитектура обеспечивает самое дешевое подключение.
◄ Данные (0-2112 байта) ►
4 байта начала кадра 24 байта заголовка 64 байта опционного заголовка 2048 байта поля данных 4 байта CRC 4 байта конца кадра
Рис. 4.1.G. 1. Формат пакета Fibre Channel
Система арбитража допускает обмен только между двумя узлами
одновременно. Следует учесть, что кольцевая структура не предпо-
лагает применения маркерной схемы доступа. Когда подключенное
к сети устройство готово передать данные, он передает сигнал-при-
митив ARBx, где х — физический адрес устройства в кольце арбит-
ража (ALPA). Если устройство получит свой собственный сигнал-
примитив ARBx, оно получает контроль над кольцом и может на-
чать передачу. Инициатор обмена посылает сигнал-примитив Open
(OPN) и устанавливает связь с адресатом. Время удержания конт-
роля над кольцом не лимитируется. Если контроль над кольцом
одновременно пытаются захватить два устройства, сравниваются
значения х сигналов ARB. Устройство с меньшим AL_PA получает
преимущество, прибор с большим AL_PA блокируется.
Прежде чем использовать кольцо его нужно инициализировать
(процедура LIP), так чтобы каждый порт получил свой физический
аДрес (AL_PA — один октет, что и определяет максимальное число
портов в кольце арбитража). Процедура инициализации начинает-
ся сразу после включения питания посылкой сигнала-примитива
LIP через порт L Port. Затем осуществляется выбор устройства,
к°торое будет управлять процессом выбора AL_PA.
Перед передачей октеты преобразуются в 10-битовые кодовые
п°следовательности, называемые символами передачи (кодировка IBM
212
Гпава 4 >
Рис. 4.1.6.2. Типы топологии FC
• *
8В/10В). Логической единице соответствует больший уровень све-
товой энергии. В Fibre Channel предусмотрено два режима обмена
буфер-буфер и точка-точка (end-to-end). Передача данных осуще- •
ствляется, только когда принимающая сторона готова к этому. Преж- 5
де чем что-либо посылать стороны должны выполнить операцию
login. В ходе выполнения login определяется верхний предел объе- >
ма пересылаемых данных (credit). Значение параметра credit задает
число кадров, которые могут быть приняты. После передачи очеред- ?
ного кадра значение credit уменьшается на единицу. Когда значе-
ние этой переменной достигает нуля, дальнейшая передача блокиру-
ется до тех пор, пока получатель не обработает один или более
кадров и будет готов продолжить прием. Здесь имеет место доволь-
но тесная аналогия с окнами в протоколе TCP. Режим обмена бу-
фер-буфер предполагает установление связи между портами N_Port
и FPort или между двумя N_Port. При установлении соединения
каждая из сторон сообщает партнеру, сколько кадров она готова
принять (значение переменной ВВ_Credit). Режим точка-точка (end-
to-end) реализуется между портами типа N_Port. Предельное число
кадров, которые сторона может принять, задается переменной
EE_Credit. Эта переменная устанавливается равной нулю при ини-
циализации, увеличивается на единицу при передаче кадра и умень-
шается при получении кадра АСК Link Control. Кадр АСК может
указывать на то, что порт получил и обработал один кадр, N кадров
или всю последовательность кадров.
Сети передачи данных. Метод доступа
213
4.2. Наложенные сети
В отличие от локальных наложенные сети не требуют использо-
вания специальных аппаратных средств для подключения. Так, если
ЭВМ подключена к Ethernet (к ArcNet или Token Ring), нужны
только соответствующие программные средства, чтобы она стала
узлом сети Novell (стек протоколов IPX/SPX). Почтовая сеть (про-
токолы SMTP или UUCP) и сеть новостей (Usenet, протокол NNTP)
относятся к наложенным сетям. Интернет (семейство протоколов
TCP/IP) является также примером наложенной сети. Проблемати-
ка Интернет выделена в самостоятельный раздел лишь в силу объе-
ма и разнообразия материалов. Одна и та же ЭВМ может быть
узлом нескольких разных наложенных сетей. Смешанные сети мо-
гут создавать проблемы для администраторов сетей, но для пользо-
вателей они дают лишь дополнительные возможности. В таких се-
тях неизбежно возникает проблема присвоения имен и установки
соответствия между виртуальными и физическими адресами (в Ин-
тернет эта проблема решается с помощью протокола ARP).
4.2.1. NETBIOS
Протокол NetBIOS был создан для работы в локальных сетях.
Система NetBIOS предназначена для персональных ЭВМ типа IBM/
PC в качестве интерфейса, независящего от фирмы-производителя.
NetBIOS использует в качестве транспортных протоколов TCP и
UDP. Описание NetBIOS содержится в документе IBM 6322916
«Technical Reference PC Network» (см. также RFC-1001-2, -1088 и
STD-48).
Пакет NetBIOS (см. также ftp://ietf.org/internet-drafts/draft-
ietf-pppext-netbios-fcp-08.txt) создан для использования группой ЭВМ,
поддерживает как режим сессий (работа через соединение), так и
Режим дейтограмм (без установления соединения). 16-и символь-
ные имена объектов в NetBIOS распределяются динамически.
NetBIOS имеет собственную DNS, которая может взаимодейство-
вать с интернетовской. Имя объекта при работе с NetBIOS не мо-
кнет начинаться с символа *.
Приложения могут через NetBIOS найти нужные им ресурсы,
Установить связь и послать или получить информацию. NetBIOS
использует для службы имен порт — 137, для службы дейтограмм
порт 138, а для сессий — порт 139.
214
Гпава 4
Любая сессия начинается с NetBIOS-запроса, задания IP-адреса и
определения TCP-порта удаленного объекта, далее следует обмен
NetBIOS-сообщениями, после чего сессия закрывается. Сессия осу-
ществляет обмен информацией между двумя NetBIOS-приложения-
ми. Длина сообщения лежит в пределах от 0 до 131071 байт. Допу-
стимо одновременное осуществление нескольких сессий между дву.
мя объектами.
При организации IP-транспорта через NetBIOS 1Р-дейтограм-
ма вкладывается в NetBIOS-пакет. Информационный обмен проис*
ходит в этом случае без установления связи между объектами. Имена
NetBIOS должны содержать в себе IP-адреса. Так часть NetBIOS-
адреса может иметь вид, ip. **.**. **.**, где IP указывает на тип
операции (IP через NetBIOS), а **.**.**.** — IP-адрес. Система
NetBIOS имеет собственную систему команд (Call, Listen, Hang Up,
Send, Receive, Session Status, Reset, Cancel, Adapter Status, Unlink, Remote
Program Load) и примитивов для работы с дейтограммами (Send
Datagram, Send Broadcast Datagram, Receive Datagram, Receive Broadcast
Datagram). Все оконечные узлы NetBIOS делятся на три типа:
• Широковещательные («В») узлы;
• узлы точка-точка («Р»);
• узлы смешанного типа («М»).
IP-адрес может ассоциироваться с одним из указанных ти-
пов. В-узлы устанавливают связь со своим партнером посредством
широковещательных запросов. Р- и М-узлы для этой цели исполь-
зуют NetBIOS сервер имен (NBNS) и сервер распределения дейтаг-
рамм (NBDD).
В настоящее время (1985 г) разработана улучшенная версия*’
протокола NetBIOS — NetBEUI (NetBIOS Extended User Interface).
Этот новый протокол используется операционными системами LAN
Manager, LAN Server, Windows for Workgroups и Windows NT, a no
своей функции занимает нишу протоколов TCP/IP, охватывая связ-
ной, сетевой и транспортный уровни. Здесь стандартизован формат
пакетов NetBIOS, добавлены некоторые новые функции. NetBEUI
базируется на протоколе OSI LLC2, вводит стандарт на формат кад-
ра NetBIOS (NDF) и использует NetBIOS в качестве интерфейса
высокого уровня. Протокол обладает высоким быстродействием #
служит для объединения небольших локальных сетей (20-200 ЭВМ)
друг с другом или с главной ЭВМ. Этот протокол соответствует
связному, сетевому и транспортному уровню модели OSI. В новых
версиях NetBEUI (3.0 и выше) снято ограничение на число одновре-
менных сессий (254). Среди ограничений NetBEUI следует назвать
отсутствие внутренней маршрутизации и серьезные ограничения пр#
__Ч
Сети передачи данных. Метод доступа
215
работе в региональных сетях. По этой причине NetBEUI рекоменду-
ется для локальных сетей (здесь они предпочтительнее других про-
токолов), а для внешних связей использовать, например, TCP/IP.
Для подключения терминальной системы к локальной сети или
к ДРУГОЙ терминальной системе разработан протокол NBFCP
(NetBIOS Frames Control Protocol, код поля протокола = 803F), ко-
торый в свою очередь базируется на протоколе РРР.
формат кадра протокола NBFCP показан на рис. 4.2.3.1.
О 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 31
Тип Длина Класс партнера
Версия партнера (старшая) Версия партнера (младшая)
Имя партнера (peer)
Рис. 4.2.3.1. Формат кадра NBFCP
Поле тип содержит код 2, поле длина определяет размер заголов-
ка, если длина=8, имя партнера отсутствует.. По ле класс партнера
идентифицирует тип системы отправителя (см. таблицу 4.2.3.1).
Таблица возможных значений поля класс партнера приведена ниже.
Поле имя партнера может иметь до 32 октетов.
Таблица 4.2.3.1 Коды класса партнера
Код класса Описание
I Зарезервировано
2 Сервер внешнего порта РРР NetBIOS
3 Зарезервировано
4 Сервер локального доступа РРР NetBIOS
5 Зарезервировано
6 Мост РРР NetBIOS
7 Зарезервировано
8 Терминальная система РРР
216
Гпава 4
4.3. Региональные сети
Региональные сети (WAN — Wide Area Network) с точки зрения
архитектуры и протоколов практически не отличаются от глобаль-
ных. В региональных сетях обычно не используются трансокеанс-
кие кабели, но это отличие не может рассматриваться как принци- •*
пиальное. Региональные сети решают проблему формирования из
LAN (локальных сетей) сетей регионов и целых стран и даже надна-
циональных сетей (например, E-BONE для Европы). Как правило,
эти сети строятся с использованием протоколов SDH, ATM, ISDN,
Frame Relay или X.25. Архитектурно такие сети формируются из
каналов со схемой точка-точка и мощных коммутаторов-мульти-
плексоров. Из таких фрагментов формируются и опорные сети
(BackBone), которые позволяют сократить число шагов от узла к
узлу. В этих сетях в основном используются оптоволоконные транс-
портные системы, а там где это нерентабельно, спутниковые или
радиорелейные каналы.
С появлением корпоративных сетей типа Интранет понятия ;
локальной и региональной сетей стало частично перекрываться.
Для пользователя Интранет все узлы такой, сети являются локаль-
ными, хотя и могут отстоять на сотни или даже тысячи километров
друг от друга. По существу сети Интранет являются наложенными
сетями по отнощению к региональным сетям (WAN). Интернет
также следует отнести к числу наложенных сетей по отношению к
WAN.
4,3.1. Эталонная сетевая модель ISO
Международная организация по стандартизации (ISO) определи-
ла 7-уровневую эталонную сетевую модель для открытых систем »
(OSI), (Интернет использует 4-х уровневое подмножество). Ниже на
рис. 4.3.1.1 показана схема этих уровней, справа записаны коды
документов международного Телекоммуникационного союза (ITU)r 4
регламентирующих протоколы соответствующих уровней.
Разбиение совокупности (стека) сетевых протоколов по уров- д
ням связана с попыткой унификации аппаратного и программного
обеспечения. Предполагается, что каждому из уровней соответству-
ет определенная функциональная программа с жестко заданными -
входным и выходным интерфейсами. Форматы данных на задан-
Сети передачи данных. Метод доступа
217
Прикладной
Презентационный
Уровень сессий
Транспортный
Сетевой
Q.921 (1.441), Q.922
Х.21 (I.430, 1431, I432)
Канальный
Физический
Рис. 4.3.1.1. Семиуровневая эталонная модель ISO
ном уровне модели для отправителя и получателя должны быть
идентичны. Физический уровень локальных сетей определен доку-
ментами, например, Ethernet II, IEEE 802.3 и т.д. Модели ISO наибо-
лее полно соответствуют сети Х.25.
Физический уровень Х.25 определяет стандарт на связь между
ЭВМ и сетевыми коммутаторами (Х.21), а также на процедуры об-
мена пакетами между ЭВМ. Х.21 характеризует некоторые аспекты
построения общественных сетей передачи данных. Следует учиты-
вать, что стандарт Х.25 появился раньше рекомендаций ITU-T и
опыт его применения был учтен при составлении новейших реко-
мендаций. На физическом уровне могут использоваться так&е про-
токолы X.21bis, RS232 или V.35.
Канальный уровень определяет то, как информация передается
от ЭВМ к пакетному коммутатору (HDLC — High Data Link
Communication, бит-ориентированная процедура управления), на этом
Уровне исправляются ошибки, возникающие на физическом уровне.
Сетевой уровень определяет взаимодействие различных частей
субсети, форматы пакетов, процедуры повторной передачи пакетов,
стандартизует схему адресации и маршрутизации.
Транспортный уровень определяет надежность передачи данных
По схеме точка-точка, избавляет уровень сессий от забот по обеспе-
чению надежной и эффективной передачи данных.
Уровень сессий описывает то, как протокольное программное обес-
Печение должно организовать обеспечение выполнения любых при-
кладных программ. Организует двухстороннее взаимодействие сете-
х объектов и необходимую синхронизацию процедур.
218
Гпава 4
Презентационный уровень обеспечивает прикладной уровень
стандартными услугами (сжатие информации, поддержка ASN.1
(Abstract Syntax Notation 1) управляющих протоколов и т.д.).
Прикладной уровень — это все, что может понадобиться пользо-
вателям сетей, например Х.400.
Международным стандартом в процедуре HDLC определены
два вида кадров:
F Адрес Управление FCS F
F Адрес Управление Информация FCS F
Рис. 4.3.1.2 Два вида кадров процедур HDLC
Флаг F = 01111110 задает границы кадра, FCS — контрольная
сумма. Поле информация может иметь переменную длину, кратную
восьми бит. Для HDLC определены три класса кадров: информаци-
онные (I), управляющие (S-Supervisory) и ненумерованные (U —
unnumbered). (Эти форматы соответствуют канальному уровню про-
токола Х.25). Формат поля управление 1-кадра показан на рис.
4.3.1.3.
0 N(S) P/F N(R)
◄ . 7 бит ► 1 * 7 бит
Рис. 4.3.1.3. Формат поля управления 1-кадра
(нумерация по модулю 128)
N(S) и N(R) представляют собой поля номера кадров. N(R) —
номер текущего кадра, a N(S) — номер следующего кадра, который
отправитель текущего кадра ожидает получить. При несоответствии
ожидаемого номера и полученного возникает ошибка. Если исполь-
зуется нумерация кадров по модулю 8, то максимальное число кад-
ров, не получивших подтверждение не может превышать 7, а размер
полей N(S) и N(R) равен трем бит. Это справедливо и для S-кад-
ров. I, S и U-кадры могут иметь обычный (один байт) и расширен-
ный (2 байта) форматы. Младший бит (1) расположен'слева. Поле
P/F — флаг опрос/окончание опроса. Информационный (I) кадр
содержит поле информация (см. рис. 4.3.1.2). Формат S- кадр*
показан на рис. 4.3.1.4.
Сети передачи данных. Метод доступа
219
S 0 0 0 0 P/F N(R)
2 бита 1 р 7 бит ►
Рис. 4.3.1.4. Формат поля управления S-кадра
[расширенный вариант)
Для однобайтовой версии S-кадра за полем S следует непосред-
ственно поле P/F. Поле S определяет тип управляющего кадра (см.
таблицу 4.3.1.1):
Таблица 4.3.1.1. Коды поля S
Код S-поля Назначение
00 RR-кадр (Receiver Ready) готов к приему
01 RNR-кадр (Receiver Not Ready) не готов к приему
10 REJ-кадр (Reject) отказ от приема
и SREJ-кадр (Selected Reject) выборочный отказ от приема
S-кадры служат для передачи сигналов подтверждения, запросов
повторной передачи или прекращения посылки кадров из-за блоки-
ровки приема в местной станции. При получении кадра с неверным
порядковым номером (напр., предшествующий кадр потерян), при-
емник посылает S-кадр REJ, что означает необходимость повторной
посылки предшествующего кадра и всех последующих. Кадр SREJ(n)
указывает на то, что все кадры до п-1, включительно, доставлены без
ошибок, а при доставке кадра п допущена ошибка и он должен
быть послан повторно. В отличии от REJ запрашивается пересыл-
ка только одного кадра. Связь с терминалом является временной,
если бит P/F равен 1. Если адрес места назначения равен 11111111,
то обращение является широковещательным. Формат U-кадра пред-
ставлен на рис. 4.3.1.5.
Рис. 4.3.1.5. Формат поля управления U-кадра
220
Гпава 4
U-кадр используется для формирования канала, изменения ре-
жима работы и управления системой передачи данных. Существует
версия, когда поле «О» размещается не в 8-ой позиции, а в 5-ой. В
нижней части рисунка показана расширенная версия формата. Млад-
шие разряды располагаются слева. Поле М может принимать зна-
чения, приведенные в таблице 3.5.1.2.
Установление соединения начинается с передачи в канал коман-
ды SABM (или SABME). Если удаленной станцией эта команда
принята правильно и имеется возможность установления соедине-
ния, то присылается отклик UA. При этом переменные состояния
на удаленной станции V(S) и V(R) (аналоги полей N(S) и N(R) в
пакетах) устанавливаются в нулевое состояние.
Таблица 4.3.1.2. Коды поля М (U-кадр).
Код поля М Мнемоника Назначение
00000 UI Ненумерованная информация
00001 SNRM Установка нормального режима (Set Normal Regime Mode)
00010 DISC/RD Отсоединение (Disconnect / Request Disconnect)
00100 UP Ненумерованный запрос передачи (Unnumbered Poll)
00110 UA Ненумерованный отклик (Unnumbered Acknowledgment)
00111 TEST Тестирование системы передачи данных
10000 SIM/R1M Установка режима инициализации (Set Initialization Mode 1 Request Initialization Mode)
10001 FRMR Отклонение кадра (Frame Reject)
11000 SARM/DM Установка режима асинхронного отклика (Set Asynchronous acknowledgment Regime Mode 1 Disconnect Mode)
11001 RSET Сброс (возврат в исходное состояние)
ною SARME SARM с расширенной нумерацией
поп SNRME SNRM с расширенной нумерацией _
11100 SAMB Установка асинхронного сбалансированного режима _
11101 XID Идентификация коммутатора (Exchange IDentifier)
11110 SABME SABM с расширенной нумерацией
Сети передачи данных. Метод доступа 22 7
После благополучного получения пакета UA локальной станци-
ей соединение считается установленным и может начинаться обмен
данными. Информацию несут кадры типа I, а также FRMR и UI-
кадры типа U. В кадре ответа FRMR должно присутствовать ин-
формационное поле, содержащее обоснование присылки такого от-
вета. Структура этого поля для обычного и расширенного (внизу)
форматов показана на рис. 4.3.1.6.
20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
А В С D V(R) C/R V(S) 0 U-каДР
36 35 34 33 32 26 25 24 18 17 16 15 ... 1
А В С D V(R) C/R V(S) 0 U-каДР
Рис. 4.3.1.3. Структура информационного поля для FRMR-кадров
Биты А, В, С и D определяют причину, по который кадр не был
доставлен. Если бит равен 1, то это указывает на соответствующую
причины недоставки. Бит А указывает на неверное значение N(R).
Бит В =1 говорит о слишком большой длине информационного
поля. Бит С — указывает на то, что поле управления неопределенно
из-за наличия в кадре недопустимой для данной команды или от-
клика информационного поля, a D=1 означает, что поле управления
принятого кадра не определено или же неприемлемо. V(R) и V(S)
текущие значения переменных приема и передачи, соответственно.
C/R (Command/Response) =1 означает, что ошибочное сообщение
является откликом (=0 — командой). Большинство U-кадров ин-
терпретируются как команды или отклики в зависимости от кон-
текста и того, кто их послал. В некоторых случаях для разделения
откликов и команд используется поле адреса. Одним из наиболее
известных протоколов сетевого уровня, использующих HDLC, явля-
ется Х.25.
222
Гпава 4
4.3.2. Протоколы сетей X. 25
В 1976 году был принят стандарт Х.25, который стал основой
всемирной системы PSPDN (Packet-Switched Public Data Networks),
базирующейся на 7-уровневой модели ISO OSL Стандарт Х.25 был
усовершенствован в 1984. Х.25 — протокол (ISO 8208:1989; RFC-
887, -1381, -1382, -1461, -1598, -1613), который определяет синхрон-
ный интерфейс между терминальным оборудованием (DTE — Data
Terminal Equipment) и оборудованием передачи данных (DCE —
Data Communication Equipment) для терминалов,работающих в па-
кетном режиме. По существу это протокол связи оборудования с
сетью. Главный недостаток протокола Х.25 — большие задержки
отклика (типовое значение 0.6 сек). Терминалом может служить
ЭВМ или любая другая система, удовлетворяющая требованиям
Х.25. Соединение DTE — DTE осуществляется через DCE. В прото-
коле Х.25 DCE и DTE используют статистическое мультиплексиро-
вание с делением по времени. Одновременно могут реализовываться
несколько обменных процессов. Схема взаимодействия DTE и DCE
выглядит как:
DTE — <логический канал> — DCE <виртуальное соединение>
— DCE — «^логический канал> — DTE
Асинхронный старт-стопный терминал подключается к сети ком-
мутации пакетов через пакетный адаптер данных ПАД (PAD —-
Packet Assemble/Disassemble) и отвечает рекомендациям Х.З, Х.28
и Х.29. Один ПАД обеспечивает интерфейс для 8, 16 или 24 асинх-
ронных терминалов. Пакет данных состоит обычно из 128 байтов,
которые передаются по адресу, содержащемуся в пакете. Но длина
пакета может лежать в пределах 64-4096 байтов. Размер пакета
также как и величина окна (число пакетов, передаваемых без под-
тверждения) определяются на фазе установления канала. Прежде
чем пакет будет передан, необходимо установить связь между ис-
ходными ЭВМ/ПАД и адресуемыми ЭВМ/ПАД. Существуют два
вида соединений: коммутируемый виртуальный канал (SVC) и по-
стоянный виртуальный канал (PVC). Предусмотрены две процеду-
ры доступа к каналу:
• Процедура доступа к каналу (LAP — Link Access Procedure), в
основе которой лежат симметричные операции режима асинхронно-
го отклика (ARM — Asynchronous Response Mode) протокола HDLC*
• Балансная процедура доступа к каналу (LAPB — Link Access
Procedure Balanced) на основе асинхронного балансного режима (АВМ
— Asynchronous Balanced Mode) протокола HDLC. Сетевой уровень
реализуется с использованием 14 различных типов пакетов.
Сети передачи данных. Метод доступа
223
Виртуальный канал описывается в общем формате пакета, как
«логический канал». Логический канал имеет идентификатор, состо-
ящий из 12 бит. Этот идентификатор обычно состоит из номера
группы (4 бита) и номера логического канала (8 бит). В группе мо-
жет быть до 256 логических каналов (за исключением группы О,
которая может иметь только 255 логических каналов). Возможное
число групп — 16, поэтому теоретически возможное число виртуаль-
ных каналов для каждого соединения Х.25 равно 4095 (16x256-1).
Постоянный виртуальный канал (PVC — Permanent Virtual
Circuit) является аналогом выделенного канала.
Коммутируемый виртуальный канал (SVC — Switched virtual
Circuit — напоминает традиционный телефонный вызов) реализует
обмен данными. Имеются три типа коммутируемых виртуальных
каналов, работающие в дуплексном режиме, но отличающиеся на-
правлением устанавливаемых соединений: входящий SVC, двунап-
равленный SVC и выходящий SVC. Адресат каждого пакета распоз-
нается с помощью идентификатора логического канала (LCI) или
номера логического канала (LCN).
SVC используются только на время соединения и становятся
доступными для повторного использования после разъединения. Все
типы пакетов, за исключением пакетов запроса повторного пуска,
содержат идентификатор логического канала. Пакет запрос соеди-
нения в SVC является единственным типом пакетов, которые со-
держат адреса в соответствии с рекомендацией Х.121.
Для установки выходящего соединения через SVC ЭВМ выбирает
логический канал с наибольшим номером в группе и посылает пакет
запрос соединения, содержащий выбранный номер группы канала, ад-
рес получателя (в соответствии с рекомендацией Х.121) и в отдельных
случаях свой собственный адрес. При установлении входящего соеди-
нения центр коммутации пакетов (ЦКП) выбирает свободный логи-
ческий канал с наименьшим номером в группе каналов порта адресу-
емой ЭВМ и помещает этот логический номер группы и канала в пакет
входящий запрос соединения. После того как соединение через SVC
установлено, ЭВМ направляют свои пакеты, используя номера своих
логических групп/каналов, а ЦПК в сети осуществляет транспорти-
ровку пакетов и преобразование номеров логических групп/каналов.
Как только установленное по SVC логическое соединение разывается,
номера логических групп/каналов на обоих концах соединения осво-
бождаются и становятся доступными для повторного использования,
оответствие между ЦКП/портом, выделенным для терминального
°борудования, адресами (согласно рекомендациям Х.121) и номерами
логических каналов известно в сети только ЦКП.
224
Гпава 4
Выбор ЭВМ свободного канала с наибольшим номером при
каждом выходящем соединении и выбор в ЦКП свободного канала
с наименьшим номером для каждого входящего позволяют избе-
жать конфликтов. С этой же целью используются две логические
группы: одна только для входящих соединений, а другая только
для выходящих. Перед подключением к сети пользователь должен
определить, сколько PVC и SVC требуется на каждую точку физи-
ческого интерфейса Х.25. Асинхронные терминалы подключаются
к сети коммутации пакетов через встроенные или удаленные пакет-
ные адаптеры данных (ПАД).
Встроенный ПАД обычно располагается вместе с ЦКП в его "
стойке. В этом случае каждый асинхронный терминал, расположен-
ный в удаленном месте, подключается к своему встроенному ПАД
через отдельный канал связи (протокол Х.28). В альтернативном
случае удаленный ПАД (небольшое отдельное устройство) может
быть расположен в удаленном месте и подключается к своему ЦКП
через канал связи (Х.25). С помощью удаленного ПАД к ЦКП
подключается 8-16 асинхронных терминалов.
Встроенный ПАД может быть совместно использован несколь-
кими терминалами, расположенными в различных местах, в то вре-
мя как удаленный ПАД обслуживает терминалы, расположенные
обычно в одном месте. Существует еще один аспект размещения
ПАД, связанный с помехами в каналах связи и использованием
протоколов. Удаленный ПАД подключается к ЦКП на канальном
уровне в соответствии с рекомендацией Х.25. В качестве протокола
канала данных в рекомендации Х.25 реализуется подмножество
HDLC, обеспечивающее автоматическую повторную передачу дан-
ных в случае их искажения при возникновении помех в линии.
Асинхронный терминал использует для диалога с групповым ПАД
процедуры, описанные в рекомендации Х.28, в которых не предус-
мотрена возможность повторной передачи в случае ошибки. Поэто-
му канал между синхронным терминалом и групповым ПАД не
защищен от возникновения ошибок данных в результате линейных
помех. Процедуры ПАД определены в рекомендациях МККТТ (см.
приложение 10.1).
• Рекомендация Х.З: «Пакетный адаптер данных (ПАД) в сети
передачи данных общего пользования».
• Рекомендация Х.28: «Интерфейс между терминальным обо-
рудованием и оборудованием передачи данных (DCE) для стар*^
стопного оконечного оборудования, осуществляющего доступ к па*
кетному адаптеру данных в сетях общего пользования».
Сети передачи данных. Метод доступа
225
. Рекомендация Х.29: «Процедуры обмена управляющей ин-
формацией между терминальным оборудованием пакетного типа и
пакетным адаптером (ПАД)».
Основные функции ПАД соответствуют рекомендациям Х.З:
• сборка символов (полученных от асинхронных терминалов) в
пакеты;
• разборка полей данных в пакетах и вывод данных на асинх-
ронные терминалы;
• управление процедурами установления виртуального соедине-
ния и разъединения, сброса и прерывания;
• обеспечение механизма продвижения пакетов при наличии
соответствующих условий, таких как заполнение пакета, получение
символа (сигнала) на передачу пакета, истечение времени ожида-
ния;
• передача символов, включающих стартстопные сигналы и биты
проверки на четность, по требованию подключенного асинхронного
терминала;
• обнаружение сигнала разрыва соединения от асинхронного тер-
минала;
• редактирование последовательностей команд ПАД.
В постоянном запоминающем устройстве ПАД хранятся па-
раметры. Эти параметры могут быть установлены либо асинхрон-
ным терминалом, подключенным к ПАД, либо любой ЭВМ в сети,
которая удовлетворяет условиям рекомендации Х.29. В рекоменда-
ции Х.29 МККТТ эти параметры названы управляющей информа-
цией. Поэтому необходимо квалифицировать данные, проходящие
между ЭВМ и ПАД, либо как управляющую информацию (сообще-
ния ПАД), либо как собственно данные от асинхронного терминала.
Сеть Х.25 предоставляет пользователю старт-стопного тер-
минала средства, позволяющие выбрать параметры ПАД с заранее
определенными значениями. Пользователь посылает в ПАД коман-
ду выбора профайла, которая включает идентификатор профайла.
Этим определяется один из нескольких стандартных профайлов,
хранящихся в ПАД.
Идентификатор профайла и параметр 11 ПАД (скорость тер-
минала) включаются в «поле данных пользователя» пакетов типа
запРос соединения, посылаемых ПАД. ЭВМ (ПАД) использует это
ПОле, извлекая из него информацию о терминале, пославшем запрос.
Пакетный терминал является интеллектуальным устройством
Ример, ЭВМ, или внешним ПАД’ом), которое обеспечивает синх-
^нный обмен с сетью на скорости 2400, 4800, 9600 бит/с или 48
Ит/с, используя трехуровневый протокол Х.25. Возможная схема
8 Зок- № 3430 Семенов
226
подключения терминальных устройств к сети Х.25 показана на
рис. 4.3.2.1.
Из рисунка 4.3.2.1 видно, что подключение ЭВМ и другого тер.
минального оборудования возможно как к встроенному, так и уда-
ленному ПАД (протокол Х.28), а также непосредственно к ЦКЦ
(протокол Х.25, Х.29). Связи с удаленными объектами осуществля-
ются через соответствующие модемы (на рисунке не показаны).
Для международного соединения необходимо указать код стра-
ны из трех цифр, а также набрать одну цифру 9 перед сетевым
адресом пользователя. Таким образом, всего требуется не более 15
цифровых символов. Для установления коммутируемого соедине- .
ния оператор вначале вручную набирает номер ПАД и ждет под-
тверждения соединения с телефонным узлом общего пользования.
Как только соединение установлено, оператор набирает 12-символь-
ный код «сетевого идентификатора пользователя». ПАД обеспечи-
вает операцию эхо-контроля, которая позволяет оператору термина- *
ла визуально проверять данные, посылаемые в ПАД. Наиболее серь- f
езным недостатком встроенного ПАД является отсутствие ‘г
какого-либо линейного протокола, предусматривающего устранение £
ошибок в данных, посылаемых от ПАД к терминалу. В удаленном
ПАД предусмотрена процедура восстановления ошибочных данных,
однако он подключается к сети как «пакетный терминал».
Сетевой адрес пользователя состоит из 12 десятичных цифр. 1-4
— идентификатор сети передачи данных (3 — страна, 4 — сеть); 5-
12 — национальный номер (5-7 местная область, 8-12 — местный
номер). Международная система адресации для систем передачи
данных общего пользователя описана в рекомендациях Х.121 меж-
дународного комитета по телефонии и телеграфии. Каждое подклю-
Х.25
цкп
Х.25 Х.25
—. Высокоскоростной канал г—
Х.25 I-----
-----► ЦКП
ЦКП
цкп
Х.25
— — Х.25
ЦКП ◄------
Х.25
-1___1-' Х-25 $.. X.
I ПАД (Х.З) I Встроенный Удаленный | ПАД (Х.3)""|
| Х.28
Рис. 4.3.2.1. Возможная топология сети Х.25
Сети передачи данных. Метод доступа
227
чение к сети коммутации пакетов имеет свой национальный номер.’
Протокол Х.25 не определяет технику маршрутизации пакетов по
сети. Для целей управления в сетях Х.25 используется протокол
SNMP и база данных MIB (как и в сетях Интернет). Три базовых
уровня протокола Х.25 и схема потоков информации отображены
на рис. 4.3.2.2.
Для подключения по виртуальному каналу ЭВМ/ПАД посыла-
ется пакет (Call Request), содержащий сетевой адрес пользователя.
После подтверждения соединения и передачи/приема данных вир-
туальное соединение может быть разорвано путем передачи пакета
(Clear Request), инициатором в этом случае выступает удаленная
ЭВМ. При невозможности установить связь Clear Request посылает-
ся сетью. Такой пакет содержит два информационных октета. Пер-
вый содержит код причины, второй является диагностическим ко-
дом. Ниже в таблице 4.3.2.1 приведены коды причин ошибки.
Таблица 4.3.2.1. Коды причины ошибки
Код причины Причина
0x0 Удаленный сброс (Remote Cleared)
0x1 Адресат занят (Number Busy)
0x3 Нелегальный запрос (Invalid Facility Request)
0x5 Перегрузка сети (Network Congestion)
0x9 Нарушен порядок (Out of Order)
0x11 Ошибка при выполнении удаленной процедуры
ОхВ Доступ блокирован (Access Barred)
OxD Не доступно, нет в наличии (Not Obtainable)
0x21 Несовместимость у адресата (ошибка при выполнении удаленной процедуры)
0x23 Ошибка при выполнении местной процедуры
0x29 Сигнал быстрой выборки не воспринят ( Fast Select Not Accepted)
Один физический канал связи Х.25 может поддерживать не-
сколько коммутируемых виртуальных каналов. Постоянный вир-
туальный канал подобен выделенной линии — обмен возможен в
любой момент. Х.25 определяет первые три уровня соединения от-
кРытых систем (см. рис. 4.3.2.2).
1- физический Х.21 (X.21bis)
2. канальный (HDLC — High Data Link Communication — про-
токол высокого уровня управления каналом). Этот уровень и пос-
ледующие реализуются программным образом.
2. сетевой (пакетный)
8*
228
Гпава 4
Х.21 — универсальный интерфейс между оконечным оборудова-
нием (DTE) и аппаратурой передачи данных (DCE) для синхронно-
го режима работы в сетях общего пользования. X.2Ibis - тоже, но
для модемов, удовлетворяющих рекомендациям серии V. Для ка-
нального уровня используется подмножество протокола HDLC (яв-
ляющегося развитием стандарта SDLC IBM), обеспечивающее воз-
можность автоматической повторной передачи в случае возникнове-
ния ошибок в линии.
Рис. 4.3.2.2. Три уровняХ.25
Формат кадра для протокола HDLC показан на рис. 4.3.2.3
(байты передаются, начиная с младшего бита).
Открывающий и закрывающий флаги для бит-ориентированно-
го формата несут в себе код 0х7Е. Когда не передается никакой
информации, по каналу пересылается непрерывный поток флагов
01111110. Посылка более 6 единиц подряд воспринимается как
флаг абортирования связи. Если необходимо передать информации
онную последовательность 01111110, после первых пяти единиц,
вводится дополнительный нуль, приемник восстанавливает истин*,
ную информацию, удаляя эти лишние нули. В случае байт-ориентй-
рованных кадров открывающий и завершающий флаги имеют и®
два байта [ВЕЕ(Символы кодов стандарта ISO 646-1973 (МТК-5>
ГОСТ 13059-74). Здесь и далее используется русская терминология
в соответствии со стандартом ГОСТ 26556-85, STX и DLE, ЕТХ>
Сети передачи данных. Метод доступа
229
Откр. Ад- УПР-
флаг рес |поле
Управление
уровнем
кадра (FLC)
2
Байт Байт
1
Байт
N
2 байта
(FCS)
Контрольная
сумма (CRC)
кадра
Допускается.
4-байтовый
О вариант
Информационное поле
(В управляющем кадре это поле
отсутствует)
Q- бит Идентификатор общего формата (GFI) Групповой номер логического канала
Номер логического канала
Идентификатор типа пакета
Длина адреса источника запроса Длина адреса адресата
Дополнительная
информация,
зависящая от
типа пакета
Рис. 4.3.2.3. Формат кадра Х.25
Закр.
флаг
соответственно, для информационного кадра и DLE, STX и DLE, ЕТХ
для управляющего]. Адрес в пакете Х.25 занимает всего один байт,
что определяет предельное число терминальных устройств, подклю-
чаемых к одному каналу. Кадр на уровне 2 имеет двухбайтовый
заголовок, содержащий байт адреса и байт типа. Для нумерации
кадров на уровне 2 используется 3 бита. При работе со скользя-
щим окном это позволяет иметь до 7 кадров в очереди. При ис-
пользовании спутниковых каналов с большими задержками можно
переходить в режим расширенной нумерации (7 бит), где длина
очереди может достигать 128. Если удаленный партнер не способен
работать в режиме расширенной нумерации, он отклонит запрос со-
единения. При работе в режиме расширенной нумерации возможно
применение 3-байтовых заголовков вместо двухбайтовых.
Значения поля идентификатора общего формата (GFI — General
Format Identifier) приведено в таблице 4.3.2.2. Бит 8 этого поля
(Q) используется в информационных пакетах как индикатор уров-
Ня передаваемых данных. Групповой номер логического канала и
н°мер логического канала присваиваются по соглашению с админи-
стРацией сети во время постановки на обслуживание. Поля группо-
в°й номер логического канала и номер логического канала присут-
ствуют во всех пакетах кроме пакетов регистрации и повторного
Уска» где они принимают нулевое значение.
230
Гпава 4
Таблица 4.3.2.2. Значения кодов идентификатора общего формата (GFI)
Тип пакета Модуль нумерации Номера битов
8 7 6 5
Установка соединения 8 128 0 0 X X 0 1 1 0
Разрыв соединения, управление потоком, повторный пуск, регистрация, диагностика 8 128 0 0 0 0 0 1 1 0
Данные 8 128 X X X X 0 1 1 0
Расширение - 0 0 1 1
х — бит может принимать значения 0 или 1.
Допустимые значения кодов в поле тип пакета приведены в «
таблице 4.3.2.3.
Таблица 4.3.2.3. Значения кодов тип пакета
Тип пакета Октет 3
Биты 87654321
Запрос 00001011
Запрос принят 00001111
Запрос завершения 00010011
Подтверждение завершения 00010111
Данные хххххххО
Прерывание 00100011
Подтверждение прерывания 00100111
Готовность к приему по модулю 8 (RR) х х х 0 0 0 0 1
Готовность к приему по модулю 128 (RR) 00000001
Неготовность к приему по модулю 8 (RNR) х х х 0 0 1 0 1
Неготовность к приему по модулю 128 (RNR) 00000101
Запрос повторной установки 00011011
Подтверждение повторной установки 000 1 1 1 1 1
Запрос повторного пуска 11111011
Подтверждение повторного пуска 11111111
Диагностика 11110001
Запрос регистрации 11110011
Подтверждение регистрации 11110111
х — отмечет разряды, которые могут принимать значения 0 или 1*
СеТИ передачи данных. Метод доступа
231
Четырехбитовые поля длина адреса отправителя и длина адреса
получателя характеризуют длины последующих полей переменной
длины. Длина выражается в полуоктетах. Далее следуют соответ-
ствующие адреса. В каждом полуоктете записывается десятичная
цифра адреса, при необходимости поле адреса дополняется нулями
до целого числа октетов. Для пакетов установления связи кадры
имеют формат, показанный на рис. 4.3.2.4.
8 7 6 5 4 3 2 1
Идентификатор формата Групповой номер логического канала
Номер логического канала (LCN)
Идентификатор типа пакета
Длина адреса вызывающего РТЕ Длина адреса вызываемого РТЕ
DTE адреса получателя и отправителя
0 0 Длина поля опции
Опции
Пользовательские данные. Длина зависит от типа запроса.
Три первых уровня образуют
заголовок пакета, состоящий
из трех байтов
Код 00001011 или 00001111
Длина задается в полуоктетах
Опции - это дополнительные
возможности, например:
расширенная адресация,
нестандартная ширина окна или
размер пакета и т.д.
Рис. 4.3.2.4. Формат кадра запроса на соединение и соединение
установлено
Поле опции содержит целое число октетов, но не более 109, следу-
ющее же поле может содержать до 128 байт. Опция типа Fast Select
позволяет поместить до 64 байтов в информационном поле пользо-
вателя, во многих случаях этого оказывается достаточно и исключа-
ется необходимость переходить в режим пересылки данных.
Если вызываемое DTE не присылает сообщения вызов принят
или запрос завершения (установление связи отвергнуто) за отведен-
ное для этого время, процедура завершается и процесс^, инициали-
зировавшему запрос, присылается соответствующий код ошибки.
При успешной обработке запроса (прислано сообщение соединение
Установлено) система переходит в режим обмена данными. DTE мо-
Жет в любой момент инициировать процедуру разрыва связи, послав
сообщение запрос завершения. DCE сообщает о завершении соедине-
ния путем присылки пакета индикация завершения, на который
*Е должно прислать отклик подтверждение завершения. Формат
пакетов запроса и подтверждения завершения отображен на рис.
•3.2.4. и 4.3.2.5. Байты 1 и 2 на рисунке 4.3.2.5 не показаны,
Так Как они идентичны тому, что представлено на рис. 4.3.2.4.
232
Гпава 4
8 7 6 5 4 3 2 1
Идентификатор типа 00010011
Код причины
Диагностический код
Длина адреса вызывающего DTE Длина адреса вызываемого DTE
DTE адреса получателя и отправителя
0 0 0 0
Длина поля опции
Опции
Пользовательские данные. Длина зависитоттипа запроса.
Рис. 4.3.2.5. Формат пакетов запроса завершения
Коды причины завершения связи приведены в таблице 4.3.2.1.
Однобайтовое поле диагностический код позволяет уточнить причину.
В таблице 4.3.2.4 приведены коды причины повторного пуска. Фор-
мат пакетов подтверждения завершения представлен на рис. 4.3.2.6.
Таблица 4.3.2.4. Коды причин повторного пуска
Код причины Причина повторного пуска
0x1 Ошибка локальной процедуры
0x3 Перегрузка сети
0x7 Сеть работоспособна
8 7 6 5 4 3 2 1
Идентификатор типа 00010111
Длина адреса вызывающего DTE Длина адреса вызываемого DTE
DTE адреса получателя й отправителя
0 0 0 0
Длина поля опции
Опции
Пользовательские данные. Длина зависит от типа запроса.
Рис. 4.3.2.6. Формат пакетов подтверждения завершения
Оети передачи данных. Метод доступа 233
—
Для инициализации обмена информацией (первичного или по-
вторного), а также для прерывания виртуальной связи и возвраще-
ния виртуальных каналов в исходное состояние используются зап-
росы повторного пуска (и подтверждение повторного пуска). DTE
может выдать запрос повторного пуска (к DCE) в любой момент
времени, переводя логический канал в исходное состояние. DCE в
ответ должно послать сообщение подтверждение повторного пуска.
Инициатором повторного пуска может быть и DCE, для этого оно
посылает сообщение индикация повторного пуска. DTE в результа-
те устанавливает логический канал в исходное состояние и посыла-
ет DCE сообщение подтверждение повторного пуска. Форматы па-
кетов, несущих эти сообщения показаны на рис. 4.3.2.6 и 4.3.2.7.
Эти пакеты не имеют полей группового номера логического канала
и LCN (см. рис. 4.3.2.7 и .8). Процедура повторной установки во
многом аналогична повторному пуску и используется всякий раз
при выявлении сбоя, чтобы вернуть виртуальную связь или посто-
янный виртуальный канал в исходное состояние.
8 7 6 5_____4 3_____2 8 7 6 5 4 3 2
Идентификатор 0 0 0 0 формата Идентификатор Групповой номер формата логического канала
00000000 Номер логического канала
Идентификатор типа пакета 11111011 Идентификатор типа пакета 0 0 01 1 0 1 1
Причина Причина
Диагностический код Диагностический код
Рис. 4.3.2.7. Формат пакета запроса повторного пуска (слева) и
повторной установки
Таблица 4.3.2.5. Коды причин повторной установки
Причина повторной установки Код причины
.Установка по инициативе РТЕ 0x0
.Повреждение постоянного виртуального канала 0x1
-Ошибка при исполнении удаленной процедуры 0x3
-Ошибка при выполнении локальной процедуры 0x5
Догрузка сети 0x7
Удаленное DTE работоспособно (постоянный Л^ЕХуальный канал) 0x9
-£Нь£аботоспособна (постоянный виртуальный канал) OxF
Несовместимость партнеров 0x11
234
Гпава
Партнер — получатель этого запроса должен прислать сообщеЛ
ние подтверждение повторной установки (рис. 4.3.2.8). При этом
возможны потери информации (также как и в случае повторного
пуска), так как некоторые пакеты, находящиеся в сети в момент
реализации запроса повторной установки или повторного пуска бу-
дут потеряны.
Инициатором посылки запроса повторной установки может быть
DTE и DCE. Коды причин повторной установки представлены в
таблице 4.3.2.5.
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
Идентификатор формата 0 0 0 0
00000000
Идентификатор типа пакета 11111111
Идентификатор формата Групповой номер логического канала
Номер логического канала
Идентификатор типа пакета 00010111
Рис. 4.3.2.8. Формат пакета подтверждения повторного пуска (слева}
и повторной установки (справа}
Пакеты данных передаются по постоянным виртуальным кана-
лам или через виртуальные соединения после их создания. Пакеты
данных распознаются по нулевому младшему биту (бит с номером 1)
в третьем октете. Остальные биты этого октета используются для
управления. Форматы пакетов данных показаны на рис. 4.3.2.9. *
Информационное поле начинается с четвертого байта (при рас-
ширенной нумерации с пятого) и может иметь длину 16-4096, хотя
в рекомендациях стандарта Х.25 оговорена величина 128 октетов.
Если принимающая сторона не способна принять пакет данной длины, ~
связь должна быть переустановлена, а стороне-инициатору соедине-
ния послано сообщение об ошибке. Каждому пакету данные при-^
сваивается порядковый номер N(S), значение которого при установи
лении соединения равно нулю.
Q-бит определяет тип кадра-пакета, Q=1 — управляющий пакет
для PAD, Q=0 — информационный пакет. Бит D используется для
запроса специального отклика на пакет со стороны удаленного кой*^
ца виртуального канала. Бит М указывает на то, что данный пакет
является частью более крупного пакета, который должен быть вос-
создан позднее.
Индекс S (send) соответствует отправке, а индекс R — приему
(receive). Если используется нумерация пакетов по модулю 8, N(S)
235
передачи данных. Метод доступа
I ri I
8765432 8765432
Идентификатор формата Q D 0 1 Групповой номер логического канала
Номер логического канала
N(R) м N(S) 0
Данные пользователя
Идентификатор формата Q D 1 0 Групповой номер логического канала
Номер логического канала
N(S) 0
N(R) М
Данные пользователя
Рис. 4.3.2.9. Форматы пакетов "данные".
Слева — по модулю 8, справа — по модулю 128
занимает биты 2-4 включительно, при нумерации по модулю 128 для
этого отводятся биты 2-8. Нумерация пакетов позволяет выявить
потерю пакетов или изменение порядка их доставки. N(R) является
номером пакета с принимающей стороны. Бит подтверждения дос-
тавки D (идентификатор формата) служит для указания необходи-
мости сообщения о доставке данных получателем. Если D=l, то DTE
обязано подтвердить доставку. Обязательность процедуры подтверж-
дения определяется уже на фазе установления связи (сообщение зап-
рос на установление связи принят). Если какой-либо узел по пути
пересылки пакета не поддерживает процедуру подтверждения дос-
тавки, он пошлет сообщение запрос завершения (причина — несовме-
стимость у адресата) и связь должна быть сформирована заново с
учетом необходимости подтверждения во всех узлах-участниках.
Размер поля данные в пакете может быть разным для разных узлов,
участвующих в обмене. По этой причине число полученных пакетов
может оказаться больше (или меньше) числа посланных. Для таких
случаев предусмотрен флаг М (дополнительные данные). Возмож-
ность фрагментации и последующей сборки пакетов определяется
Управляющими битами М и D (см. таблицу 4.3.2.6).
Таким образом, при фрагментации исходного сообщения все па-
кеты кроме последнего должны иметь бит М=1. Нумерация пакетов
По Модулю 8 означает, что им последовательно присваиваются но-
МеРа 0,1,2,3,4,5,6,7,0,1,2 и т.д. Аналогично при нумерации по
м°ДУлю 128 — 0,1,2,...127,0,1,2,3 и т.д. Форма нумерации паке-
т°в определяет также размер «окна», то есть число пакетов, которые
^ОГУТ быть переданы, не дожидаюсь подтверждения получения. По
°лчанию размер окна равен 2, другие значения могут быть согла-
сны на фазе установления соединения. Принцип использования
236
Гпава 4
Таблица 4.3.2.6. Управление фрагментацией и сборкой пакетов с
помощью битовМиО
(Бит М Бит D Выполнение объединения с последующим пакетом (реализуется сетью)
0 0 Нет
0 I Нет
I 0 Да
I I Нет
окон при передаче пакетов более подробно описан в разделе «3.6.2
Протокол ТСР».
Для управления процессом передачи данных используются
сообщения «готов к приему» и «не готов к приему». Форматы этих
пакетов показаны на рис. 4.3.2.10 и 4.3.2.11.
Код N(R) на входе DCE должен лежать в пределах между N(R)
последнего принятого пакета и N(S) следующего пакета, который
должен быть послан из DCE к DTE. При невыполнении этого усло-
вия связь будет переустановлена и передача повторена. Пакеты го-
товность к приему используются для сообщения о готовности при-
87654321 8765 432
Идентификатор формата 0 0 0 1 Групповой номер логического канала Идентификатор формата 0 0 0 1 Групповой номер логического канала
Номер логического канала Номер логического канала
N(R) 0 0 0 0 1 N(R) 0 0 10 1
Рис 4.3.2.10. Формат пакетов готовность к приему и неготовность к
приему при нумерации по модулю 8.
87654321 8765 4321
Идентификатор формата 0 0 0 1 Групповой номер логического канала Идентификатор формата 0 0 0 1 Групповой номер логического канала
Номер логического канала Номер логического канала
Идентификатор типа пакета 0 0 0 0 0 0 0 1 Идентификатор типа пакета 0 0 0 0 0 1 0 1
N(R) 0 N(R) 0
Рис 4.3.2.11. Формат пакетов готовность к приему и неготовность к
приему при нумерации по модулю 128.
Сети передачи данных. Метод доступа 237
нять пакеты, с номерами, начиная с номера N(R), приведенного в
пакете. Пакеты неготовность к приему служат для того, чтобы
сообщить о временной неспособности принять данные. При поступ-
лении этого сообщения отправитель должен прервать передачу до
получения сообщения готовность к приему. DTE может передавать
данные удаленному DTE, не следуя правилам управления потоком
данных. Для реализации такой возможности предусмотрена опера-
ция прерывания. Эта операция не влияет на передачу данных и
управление. Формат пакета прерывание и подтверждение прерыва-
ния показан на рис. 4.3.2.12.
87654321 8765 4321
Идентификатор формата Групповой номер логического канала Идентификатор формата Г рул повой номер логического канала
Номер логического канала Номер логического канала
Идентификатор типа пакета 0 0 10 0 0 J 1 Идентификатор типа пакета 0 0 1 0 0 1 1 1
Данные пользователя
Рис. 4.3.2.12. Формат пакетов прерывание и подтверждение
прерывания
Идентификатор формата равен 0x1 для нумерации по модулю 8
и 0x2 при нумерации по модулю 128. Передав сообщение прерыва-
ние, DTE должно ожидать получение пакета подтверждение преры-
вания. Максимальный размер поля данные пользователя в пакете
прерывание не должен превышать 32 байт.
Иногда в сетях для сообщения об ошибке используется пакет
«Диагностика». Этот пакет посылается DCE, адресуется DTE и несет
информацию о неустранимых на уровне пакетов ошибках. Пакет
диагностика посылается лишь один раз сразу после выявления
ошибки. Подтверждения его получения не требуется. Формат паке-
та показан на рис. 4.3.2.13.
Поле код диагностики несет в себе информацию об ошибке, выз-
вавшей посылку этого пакета. Если же пакет диагностика переда-
ется в качестве отклика на пакет с ошибками от DTE, то поле
Уточнение диагностики содержит первые три байта пакета DTE.
Современные сети создаются ради доступа к определенным ус-
лУгам. В протоколе Х.25 предусмотрена процедура, которая позво-
Ляет получить текущие значения параметров услуг (опций) и моди-
238
Гпава <*
8 7 6 5 4 3 2 1
Идентификатор формата 0 0 0 0
00000 00 0
Идентификатор типа пакета 1 1 1 1 0 0 0 1
Код диагностики
Уточнение диагностики
Рис. 4.3.2.13. Формат пакета диагностика
фицировать их. Эта процедура называется регистрацией и не явля-
ется обязательной. Форматы пакетов запроса регистрации и под-
тверждения регистрации показаны на рис. 4.3.2.14 и 4.3.2.15.
Максимальный размер поля регистрация составляет 109 байт. Ини-
циатором регистрации всегда является DTE, которое передает зап-
рос регистрации. В качестве отклика DCE посылает пакет подтвер-
ждение регистрации, в котором содержатся информация о парамет-
рах доступных услуг. Для выявления доступных услуг может быть
послан запрос регистрации, не содержащий списка запрашиваемых
услуг.
Получив список доступных услуг из сообщения подтверждение
регистрации, DTE может поменять параметры некоторых из них.
8 7 6 5 4 3 2 1
Идентификатор формата 0 0 0 0
00000000
Идентификатор типа пакета 11110 0 11
Длина адреса DTE Длина адреса DCE
Адрес DTE
0 0 0 0
0 о Длина поля регистрации
Регистрация
Рис. 4.3.2.14. Формат пакетов запрос регистрации
Сети передачи данных. Метод доступа
239
8 7 6 5 4 3 2 1
Идентификатор формата 0 0 0 0
0 0 0 0 0000
Идентификатор типа пакета 1111 0 111
Причина
Код диагностики
Длина адреса DTE Длина адреса DCE
Адрес DTE
0 0 0 0
0 0 Длина поля регистрации
Регистрация
Рис. 4.3.2.15. Формат пакетов подтверждение регистрации
Если значение какого-либо параметра услуги (опции) не разрешено,
DCE должно сообщить разрешенное значение параметра и макси-
мальное и или минимальное разрешенное значение (в зависимости
от того больше или меньше допустимого оказалось значение запро-
шенного параметра).
Неисправность сети может привести к тому, что та или иная
согласованная ранее услуга станет недоступной. В этом случае DCE
должно инициировать процедуру повторного пуска, чтобы уведо-
мить DTE о случившихся изменениях.
Кроме процедуры регистрации к необязательным процедурам
относятся услуги для замкнутой группы, идентификация пользова-
телей сети, группа поиска, ускоренный обмен, переадресация вызо-
вов, выбор транзитной сети, сообщения о модифицированном адресе,
согласование параметров управления потоком и некоторые другие.
Повторная передача пакетов согласуется на определенное вре-
мя и может использоваться во всех логических каналах DTE-DCE.
DTE запрашивает повторную передачу одного или нескольких паке-
тов данные путем посылки сообщения отказ (reject), которое опре-
деляет логический канал и порядковый номер пакета N(R). Полу-
Чив пакет отказ DTE начинает повторную передачу пакетов. Фор-
Мат пакетов отказ для случаев нумерации по модулю 8 и 128 показан
На РИС. 4.3.2.16.
240
Гпава 4
87654321 8765 4321
Идентификатор формата 0 0 0 1 Групповой номер логического канала Идентификатор формата 00 10 Групповой номер логического канала
Номер логического канала Номер логического канала
N(R) Идентификатор типа пакета 0 10 0 1 Идентификатор типа пакета 0 0 0 0 1 0 0 1
N(R) 0
1
2
3
4
Рис. 4.3.2. "16. Форматы пакетов типа отказ для нумерации
по модулю 8 (слева) и 128
Программное обеспечение принимающей и передающей сто-
рон должно иметь переменные состояния V(R) и V(S), содержащие,
соответственно, номера пакетов, которые предстоит получить и по-
слать (см. описание процедуры HDLC). После посылки очередного
пакета с N(S) значение V(S) увеличивается на 1. Принимающая
сторона сравнивает V(R) с N(S) полученного пакета, при совпадении
укладывает N(S) в поле N(R) пакета-отклика и инкрементируетэ
V(R). Отправитель при получении пакета проверяет равенство пере-
менной V(S) и кода поля N(R) в пакете-отклике. Если при получе-.
нии пакета выясняется, что V(R) не равно N(S), V(R) не инкремен-
тируется, а принимающая сторона отправляет отклик с N(R)=V(R),
Отправитель, получив этот отклик и обнаружив, что V(S) не равно.
N(R), узнает о происшедшем сбое. Номер логического канала (LCN)^
служит для того, чтобы определить соответствие межу DTE и мест-
ным DCE. LCN вместе с полем группового номера логического ка-
нала занимают 12 бит, что позволяет иметь до 4095 логических
каналов (LCN=0 зарезервировано для использования DCE).
4 бита первого байта управляющего пакета содержат в себе код
типа сообщения (таблица 4.3.2.7).
В поле управляющего сообщения PAD может быть включено
любое число параметров, которое допускает максимальный размер
Таблица 4.3.2.7 Коды типов сообщений
Код типа сообщения Команда PAD Отправитель
0001 Команда разъединения ЭВМ
0010 Установление параметров ЭВМ
ООН Индикация разъединения ЭВМ или PAD_
0100 Чтение параметров ЭВМ _
0101 Ошибка PAD
оно Установка и чтение параметров эвм
Сеги передачи данных. Метод доступа
241
Таблица 4.3.2.8. Коды параметров PAD
'"''Код параметра Описание
"1~ Обращение к ПАД с использованием управляющего символа
2 Эхо-контроль
• 1 Выбор сигнала посылки пакета
' т Выбор продолжительности ожидания для таймера
' 5 Управление вспомогательным устройством
6 Подавление управляющих сигналов ПАД
1 7 Выбор действий ПАД при получении сигнала разрыва
’ 8 Прерывание вывода
9 Кодовая последовательность после сигнала ’’возврат каретки”
10 Перенос строки, длина которой ограничена размерами экрана дисплея
11 Скорость работы старт-стопного терминала
12 Управление потоком ПАД
13 Вставка символа "перевод строки" после символа "возврат каретки"
14 Заполнение после сигнала "перевод строки"
15 Редактирование
16 Стирание символа
17 Стирание строки
18 Вывод строки на экран дисплея
19 Редактирование сигналов управления ПАД
20 Маскирование эхо-контроля
21 Обработка символов контроля на четность
22 Ожидание страницы
пакета. Каждый параметр имеет свой код-номер, за которым в па-
кете следует значение параметра (таблица 4.3.2.8).
При работе TCP/IP сети через каналы Х.25 и наоборот следует
учитывать некоторые отличия кодов предпочтения в полях TOS.
Таблица 4.3.2.9 содержит соответствие этих кодов для этих сетей.
Для реализации работы сетей ISDN по существующим каналам
сети Х.25 разработан протокол Х.31. Х.31 организует канал пользо-
ватель-маршрутизатор Х.25 (через посредство ISDN) и регламенти-
рует работу ISDN с пакетами Х.25.
Таблица 4.3.2.9. Соответствие кодов TOS для сетей TCP/IP и Х.25
IP Х.25 IP Х.25
ООО 00 001 01
010 10 ОН - 111 11
242
Гпава 4
Для решения первой задачи используется сообщение SETUP.
Вторая задача решается, когда канал до маршрутизатора сформиро-
ван. На этом этапе привлекается набор протоколов Х.25, возможно
применение протокола Х.75 (ISO 8208), который является расши-
рением Х.25 для межсетевых связей.
4.3.3. Интегрированные цифровые сети ISDN
Название ISDN (Integrated System Digital Network — интегриро-
ванные цифровые сети) было предложено группой XI CCITT в 1971
году (см. П. Боккер, ISDN. Цифровая сеть с интеграцией служб.
Понятия, методы, системы. «Радио и связь», М. 1991). Основное
назначение ISDN — передача 64-кбит/с по 4-килогерцной провод-
ной линии и обеспечение интегрированных телекоммуникационных
услуг (телефон, факс, данные и пр.). Использование для этой цели
телефонных проводов имеет два преимущества: они уже существу-
ют и могут использоваться для подачи питания на терминальное
оборудование. Выбор 64 Кбит/с стандарта определен простыми со-
ображениями. При 4-килогерцной полосе, согласно теореме Найк^
виста-Котельникова, частота стробирований должна быть не ниже
8 Кгц. Минимальное число двоичных разрядов для представления
результатов стробирования голосового сигнала при условии лога-
рифмического преобразования равна 8. Таким образом, в результа-
те перемножения этих чисел и получается значение полосы В-кана-
ла ISDN. Базовая конфигурация каналов имеет вид 2*В + D =
= 2*64 +16 = 144 Кбит/с. Помимо В-каналов и вспомогательного
D-канала ISDN может предложить и другие каналы с большей про-
пускной способностью, канал НО с полосой 384 Кбит/с, НИ - 1536
и Н12 - 1920 Кбит/с (реальные скорости цифрового потока). Для
первичных каналов (1544 и 2048 Кбит/с) полоса D-канала может
составлять 64 Кбит/с.
Ожидается, что к 2000 году в США будет 10000000 пользовате-
лей ISDN. Число же телефонных аппаратов в мире приближается к
миллиарду. Существует около 10 разновидностей протоколов ISDN
(National ISDN-1 (США); AT&T Custom; Euro-ISDN (Net3)) и т.д.
ISDN предполагает, что по телекоммуникационным каналам пе-
редаются цифровые коды, следовательно, аналоговые сигналы в слу-
чае телефона или факса должны быть преобразованы соответствую-
щим образом, прежде чем их можно будет передать. При передаче
цифровых сигналов используется кодово-импульсная модуляция (сМ*
раздел «Преобразование, кодирование и передача информации»), впер-
вые примененная во время второй мировой войны. Широкое внедре-
ние этого метода передачи относится к началу 60-х годов.
Сети передачи данных. Метод доступа 843
—
Чтобы обеспечить пропускную способность 64 Кбит/с по имею-
щимся телефонным проводам, не нарушая теоремы Шеннона, надо
ставить ретрансляторы на расстоянии 2 км друг от друга (ведь
ослабление сигнала в стандартном кабеле составляет около 15дБ/
км). Последние достижения в телекоммуникационных технологиях
существенно ослабили это ограничение. Унификация скоростей пе-
редачи данных в ISDN способствует уменьшению объема оборудова-
ния, так как исключает необходимость межсетевых интерфейсов,
согласующих быстродействие отдельных частей сети. Одной из наи-
более массовых приложений ISDN является цифровая телефония.
Человеческий голос можно удовлетворительно закодировать, исполь-
зуя лишь 6 бит, но вариации уровня входного сигнала приводит к
тому, что нужно не менее 8 бит (с учетом логарифмической характе-
ристики аналого-цифрового преобразователя — АЦП). Значения ко-
дов, полученных в результате последовательных преобразований зву-
ка человеческой речи, сильно коррелированны, а это открывает до-
полнительные возможности для сжатия информации.
Сети ISDN дали толчок развитию сетевой технологии. На очере-
ди интеграция Интернет с кабельным телевидением, а там, глядишь,
появятся квартирные сети, объединяющие телевизор, ЭВМ, бытовую
технику и телефон. Это неудивительно, когда цена хорошего теле-
визора почти сравнялась с ценой персональной ЭВМ, а многие быто-
вые устройства имеют встроенные процессоры. Здесь должно быть
решено несколько проблем. С одной стороны телевизионные кабели
имеют полосу пропускания достаточную для передачи как аналого-
вого (заведомо более 10 каналов), так и цифрового телевидения.
Проблема возникает при совмещении передачи телевизионного сиг-
нала и цифрового (или РСМ) канала Интернет (кабельные модемы
пока достаточно дороги). В США принято решение перехода в тече-
ние года исключительно на цифровую технологию при полном пре-
кращении эфирного вещания. Современные телевизионные системы
обеспечивают порядка 50 каналов одновременно, что накладывает
весьма жесткие требования на кабельную разводку между локаль-
ным распределительным узлом и оконечными пользователями.
Цифровой канал практически всегда является двунаправленным.
По этой причине полоса пропускания в канале конечного пользова-
теля может соответствовать лишь одной ТВ-программе (ведь теле-
ВИз°Р имеет лишь один экран). Для переключения на другую про-
гРамму телевизор посылает в региональный центр соответствую-
щую команду. Распределительные узлы сегодня объединяются с
помощью ATM-каналов (-150 Мбит/с, широкополосный ISDN), что
У^ке сегодня недостаточно. По мере удешевления можно ожидать,
244
Гпава 4
что в ближайшем будущем в квартиры конечных пользователей
будет осуществлен ввод оптоволоконных кабелей, что решит про-
блему радикально (не нужен не только телевизионный, но и теле-
фонный кабель). Попутно это решит проблему и видеотелефона. На
очереди разработка новых стандартов, которые позволят осуществить
такую интеграцию.
Так как первоначально ISDN создавалась для передачи голоса и
изображения (факс), начнем именно с этих приложений. Для фак-
сов сети ISDN особенно привлекательны, так как может обеспечить
высокое разрешение (до 16 линий/мм и лучше) при разумном вре-
мени передачи.
Для иллюстрации взаимодействия различных частей ISDN рас-
смотрим рис. 4.3.3.1.
Точка S
4-8
проводов
Терминал (ТЕ1) р-----►
| Терминал р
______ Точка S
I Терминал р
Точка R
NT2
(РВХ)
Точка Т
4-8
проводов
Точка U
2-4 провода
NT1
_J Передающая
линия
NT - сетевое
оконечное
оборудование
(Аналоговый модем)
ЭВМ
ТА
В городскую
коммутируемую
телефонную
сеть
4.3.3.1 Традиционная схема сети ISDN
Network Termination 1 (NT-1) представляет собой прибор, кото-
рый преобразует 2-проводную ISDN-линию (от телефонной компа-
нии), называемую U-интерфейсом, в 8-проводный S/T-интерфейс. Как
правило, к точке Т может быть подключено только одно оконечное
устройство. NT2 же предназначено для подключения большого чис-
ла разнотипного оборудования (функции NT1 и NT2 могут быть
совмещены в одном приборе). Допускается объединение интерфей-
сов NT2 и ТА; возможна работа нескольких NT1 с одним NT2*
Интерфейс NT2 может обеспечивать внутриофисный трафик, обра-
зуя шину, к которой может подключаться несколько терминалов.
Терминальное оборудование (ТЕ) в режиме точка-точка может быть
подключено к системе кабелем длиной до 1 км, реальным огранй*^
чением служит ослабление в 6 дБ на частоте 96 кГц. В режиме точка-
мультиточка (до 8 терминалов) подсоединение производится пара/*
лельно, но длина шины в этом случае не должна превышать 200 М
Сети передачи данных. Метод доступа
245
NT1 2/4-проводный кабель U-интерфейс Разъем RJ-11
ТА 8-проводный кабель NT1 S/T-интерфейс Разъем RJ-45
ТА 2/4-проводный кабель U-интерфейс Разъем RJ-11
Рис. 4.3.3.2. Кабели и разъемы в каналах ISDN
(по временным ограничениям). Терминалы, чтобы не вносить иска-
жений, должны иметь входное сопротивление не ниже 2500 Ом.
Шина согласуется 100 омным сопротивлением, как со стороны NT1,
так с противоположного удаленного конца (это справедливо для
принимающих и передающих пар проводов). Оборудование, следую-
щее рекомендациям ISDN, может подключаться в точках S и Т.
Схемы кабелей, объединяющих интерфейсы ISDN с оконечным обо-
рудованием, показаны на рис. 4.3.3.2.
Точки S и Т обеспечивают доступ к канальным услугам ISDN.
В точке R (на рис. 4.3.3.2 ТА — терминальный адаптер), в зависи-
мости от типа терминального адаптера, доступны некоторые другие
стандартные CCITT услуги (Х.21 или Х.25, V.35, RS-232 или V.24).
Входы ТЕ1 и ТЕ2 предназначены для удаленных телекоммуника-
ционных услуг. Все виды услуг могут быть разделены на три груп-
пы по форме доступа к 64кбит/с:
1. Услуги, для которых меняется лишь скорость исполнения (на-
пример, файловый обмен или электронная почта).
2. Принципиально новые услуги, которые недоступны при низ-
ких скоростях обмена, например, факсимильная передача со скорос-
тью 3-4 секунды на страницу (против 20-30 сек при низких скорос-
тях); видеотекст (напр., Prestel в Англии, Minitel во Франции или
Bildschirmtext в Германии).
3. Услуги, абсолютно невозможные при скоростях ниже 64кбит/с.
Например, видеотелефон или высококачественная передача звука
(П.722; ADPCM — Adaptive Differential Pulse Code Modulation).
елефония часто использует каналы со скоростью передачи 32кбит/с
*^.721). Полоса звукового сигнала равна 50 Гц — 20 Кгц.
Эталонная конфигурация системы передачи и приема сигналов,
также подачи питания на терминальное оборудование показана
На Рис. 4.3.3.3. Передаваемая по проводам мощность составляет
246
Гпава 4
Рис. 4.3.3.3 Эталонная конфигурация системы передачи и приема
сигналов, а также подачи питания на терминальное оборудование
(*) Относится к полярности кадровых сигналов. (**) относится к поляр- .
ности питающего напряжения. Используется напряжение питания V= 40 V,
которое (если требуется для питания управляющей электроники) преобра-
зуется в 5 В.
1.420 -------► ◄------------- ССГГТ N 7-------------------► «-------- 1.420
Посылка запроса
Связь установлена
Запрос принят
Раздается звонок
Получен ответ
Протокол В-канала
Посылка данных
Данные получены
Данные получены
Посылка данных
Рис. 4.3.3.4 Взаимодействие основных протоколов ISDN
1-0.5 Вт. Дополнительная пара проводов питания является в на- _
стоящее время опционной.
Логика взаимодействия различных частей сети ISDN показана
на рис. 4.3.3.4.
Процессом передачи информации между узлами управляет сиг-
нальная система общего канала (CCS — Common Channel Signaling
system). В ISDN используется 7-я сигнальная система CCITT (рис.
Сети передачи данных. Метод доступа
247
Трансивер
Рис. 4.3.3.5 Терминальный ISDN-интерфейс
4.3.1.1). Ее уровни сходны, но не идентичны OSI. На нижних уров-
нях используется МТР (Message Transfer Part — система передачи
сообщений), задачей которой является надежная пересылка сигналь-
ных пакетов по сети. Пользовательские (прикладные) сообщения
иерархически расположены над МТР, которая имеет три уровня.
Терминальное оборудование подключается к NT через трансфор-
матор (см. рис. 4.3.3.5). На входе трансиверов используются схемы
защиты от переходных процессов в линиях связи.
Нормальная амплитуда сигнала составляет 750 мВ. Формат кадра
первого уровня показан на рис. 3.5.3.6, он содержит 48 бит и имеет
длительность 250 мксек. Физическая скорость обмена составляет
192 Кбит/с (-5,2 мксек на бит). Блок-схема терминального ISDN-
интерфейса показана на рис. 4.3.3.5. Питание интерфейса осуще-
ствляется через 4-проводный выходной кабель. На вход интерфейса
подается импульсно-кодовый модулированный сигнал (ИКМ). Ин-
терфейс обеспечивает доступ к В- и D-каналам. Номинальное сме-
щение в начале кадра в случае обмена терминал-сеть, как показано
на рис. 4.3.3.6, составляет 2 бита. В некоторых случаях оно может
оказаться больше из-за задержек в кабеле. Кадр включает в себя
несколько L-битов, которые служат для балансировки цуга по по-
стоянному току. Для направления NT -> ТЕ (связь сетевого оборудо-
вания с терминальным) первыми битами кадра являются F/L-пары
(см. начало и конец диаграмм; временная ось направлена слева
направо), нарушающие AMI-правила (чередование полярности сиг-
нала при передаче логической единицы). Раз чередование нарушено,
Д° завершения кадра должно присутствовать еще одно такое нару-
шение. Бит Fa реализует это второе нарушение чередования поляр-
н°сти. A-бит используется в процедуре активации для того, чтобы
сообщить терминалу о том, что система синхронизована. Актива-
48 бит за 250 мкс
2-х битовое смещение —j
D - бит D-канала А- бит активации FA - вспомогательный бит кадра
L - бит DC-балансировки В1 - вит в В-канале 1 |\д . многокадровый бит
F - бит кадра В2^бит в В-канале 2 § . резерв на будущее
Е - бит эхо D-канала N=Fa(m3 NT к ТЕ)
Рис. 4.3.3.6 Структура кадра.
248 Гпава 4
Qern передачи данных. Метод доступа
249
ция может проводиться по инициативе терминала или сетевого обо-
рудования, а деактивация может быть выполнена только сетью.
Помимо Bl, В2 (байты выделены стрелками) и D-каналов формиру-
ются также виртуальные Е- и A-каналы. Е-канал служит для пере-
дачи эхо от NT1 к ТЕ в D-канале. Существует 10-битовое смещение
(задержка) между D-битом, посылаемым терминалом, и Е-битрм эхо
(отмечено стрелкой на рис. 4.3.3.6). М-бит используется для выде-
ления мультифреймов (эта услуга недоступна в Европе). М-бит иден-
тифицирует некоторые Ед-биты, которые могут быть изъяты для
того, чтобы сформировать канал управления (например, при прове-
дении видеоконференций). S-бит является резервным. Назначения
различных вспомогательных каналов собраны в таблице А.
Таблица А
А 4-килогерцный аналоговый телефонный канал
В Цифровой ИКМ-канал для голоса и данных с полосой 64 кбит/с
С Цифровой канал с полосой 8 или 16 Кбит/с
D Цифровой канал для внедиапазонного управления с полосой
16 Кбит/с
Е Цифровой канал ISDN для внутреннего управления с полосой
64 Кбит/с
Н Цифровой канал с полосой 384, 1536 или 1920 Кбит/с
Следует обратить внимание на то, что базовый ISDN-канал со-
держит два В-канала по 64 Кбит/с и один D-канал с 16 Кбит/с.
Первичный же ISDN-канал содержит 24 или 30 стандартных
В-каналов и один D-канал с полосой 64 Кбит/с.
На первом уровне протокола разрешаются конфликты доступа
терминалов к D-каналу. Активация и деактивация осуществляется
сигналом <info>. info=0 означает отсутствие сигнала в линии. info=l
передает запрос активации от терминала к NT. info=2 передается
от NT к ТЕ с целью запроса активации или указывает, что NT акти-
вировано вследствие появления info=l.
info=3 и info=4 представляют собой кадры, содержащие опера-
тивную информацию, передаваемую из ТЕ и NT, соответственно. NT
активирует местную передающую систему, которая информирует ком-
мутатор о начале работы пользователя. NT1 в ответ передает тер-
миналу infо=2, которое служит для синхронизации. ТЕ о^гкликают-
5я’ п°сылая info=3, который содержит оперативную информацию.
се терминалы активируются одновременно.
Второй уровень решает проблему надежной передачи сообщений
По схеме точка-точка. К каждому сообщению добавляется 16 конт-
250
Гпава 4
рольных чисел, включающих в себя идентификатор сообщения. Этот'
уровень описывает HDLC-процедуры (High Level Data Link
Communication), которые обычно называются процедурами доступа
для D-канала (LAP — Link Access Procedure). LAP D базировался
первоначально на рекомендациях Х.25 слоя 2, но в настоящее вре-
мя процедуры LAP D функционально обогатились (разрешено мно-
го LAP для одного и того же физического соединения, что позволя-
ет 8-ми терминалам использовать один D-канал). Уровень 2 дол*
жен передать уровню 3 сообщения, лишенные ошибок. На уровне 2
решается проблема повторной передачи пакетов в случае их потери
или доставки с ошибкой. LAP D базируется на LAP В рекоменда.
ций Х.25 для уровня 2. Кадры на уровне 2 представляют собой
последовательности 8-битных элементов. Формат кадра второго уров-
ня показан на рис. 4.3.3.7.
Октет N 1 2 3 4 5 6 7 8 Стартовый флаг Формат управляющего поля ; зависит от типа кадра Присутствует только в информационных кадрах слоя 3
1 0 1111110
2 Адресный октет 1
3 Адресный октет 2
4 Октет управления 1
5 Октет управления 2
6 N-3 Информация уровня 3
N-2 FCS-октет 1 • Контрольная сумма (CRC)
N-1 FCS-октет 1
N 0 1111110 Завершающий флаг
Рис. 4.3.3.7 Структура кадра для слоя 2
Стартовый и завершающие флаги передаются так, что к любым
5 единицам подряд добавляется нуль (чтобы избежать имитации
сигнатуры в других, в том числе информационных полях). Прини-
мающая сторона эти нули убирает. FCS — вычисляется по метода
ке CRC, описанной в разделе 3.3.1. ;
Каждый кадр начинается и завершается одной и той же после-
довательностью (сигнатура начала/конца кадра). Размер управлЯ-
ющего поля зависит от типа кадра (1 или 2 октета). Информацион-
ные элементы присутствуют только в кадрах, содержащих даннЫ®
3-го уровня. Формат двухбайтного поля адреса для уровня 2 пони-
зан на рис. 4.3.3.7. Адрес имеет лишь локальное значение и извеС*
тен только участникам процедуры обмена. Формат байтов ядре0*
показан на рис. 4.3.3.8.
Сети передачи данных. Метод доступа
251
1 2 3 4 5 6 7 8
ЕАО C/R SAPI
ЕА1 TEI
Рис. 4.3.3.8. Адресное поле кадра слоя 2
ЕА бит расширения адресного поля;
C/R бит поля команда/отклик;
SAPI Service Access Point Identifier — идентификатор точки
доступа, служит для описания характера реализуемого сервиса:
TEI Terminal Endpoint Identifier — идентификатор точки под-
ключения терминала.
SAPI=0 — запрос соединения по схеме коммутации каналов;
SAPI=16 — переключение пакетов согласно протокола Х.25;
SAPI=63 административные или управленческие функции (оп-
ционно). Точка доступа к услугам представляет собой виртуаль-
ный интерфейс между слоем 2 и 3 (см. рис. 4.3.3.9).
Рис. 4.3.3.9 Виртуальный интерфейс между слоями 2 и 3
Как видно из рисунка в системе могут использоваться и иден-
тичные коды TEI, если они относятся к разным видам услуг (несов-
падающими должны быть лишь комбинации SAPI-TEI). Для коди-
рования сигналов в ISDN используется метод 2B1Q (2 Binary into 1
Quaternary), что соответствует
Код Уровень
10 +2.5 V
11 +0.833 V
01 -0.833 V
00 -2.5 V
Форматы полей управления для кадров различных модифика-
представлены на рисунках 4.3.3.10, 4.3.3.11 и 4.3.3.12.
252
Гпава 4
1 2 3 4 5 6 7 8
0 N(S)
р N(R)
Октет 4
Октет 5
Рис. 4.3.3.10 Формат поля управления информационных кадров
N(S) — номер кадра, посылаемого отправителем (см. также описание
форматов для протокола Х.25). N(R) — номер кадра, получаемого отправи-
телем; P/F — флаг опроса, если кадр является командой, или флаг оконча-
ния, в случае отклика.
1 2 3 4 5 6 7 8
1 0 s S X X X X
Р N(R)
Рис. 4.3.5.11 Формат поля управления управляющих кадров
S — разряды кода управляющей функции; X — зарезервировано, дол-
жно быть равно нулю.
1 2 3 4 5 6 7 8
1 1 M M P/F М М М
Рис. 4.3.3.12 Формат поля управления ненумерованных кадров
М — бит модификатора функции (см. таблицу 4.3.1.2).
Мультиплексирование на уровне 2 осуществляется за счет ис-
пользования отдельного адреса для каждого LAP (Link Access
Procedure) в системе. Адрес содержит два байта и определяет при-
емник командного кадра и адрес передатчика кадра-отклика. SAPI
используется для идентификации типа услуг. Если наряду с цифрой
вым телефоном используется обмен данными, то эти два терминала
будут подключены к разным типам сервиса и, вообще говоря, К
разным сетям. Для каждого вида услуг фиксируется определенный
код SAPI. TEI (Terminal Endpoint Identifier) обычно имеет опреде-
ленное значение для каждого из терминалов пользователя.
Комбинация SAPI и TEI однозначно описывает LAP (Link Access
Procedure) и определяет адрес второго уровня. Так как в системе яе
может быть двух идентичных TEI, коды TEI распределяются слеДХ*
ющим образом:
Сети передачи данных. Метод доступа
253
0-63 коды TEI, присваиваемые пользователем
64-126 коды TEI, присваиваемые автоматически (сетью);
127 глобальный TEI (для широковещательных целей).
TEI с кодом в диапазоне 0-63 не нуждаются в диалоге с сетью в
процессе установления связи на уровне 2. Но пользователь должен
следить сам, чтобы в системе не было двух TEI с идентичными кода-
ми. Терминалы с TEI в диапазоне 64-126 должны договариваться с
сетью о TEI при установлении связи на уровне 2. Широковещатель-
ный ТЕ1=127 служит для обращения ко всем терминалам, имею-
щим тот же код SAPL Прежде чем предложить услуги уровню 3
уровень 2 должен запустить LAP. Это производится путем обмена
пакетами между драйвером терминала уровня 2 и соответствую-
щим сетевым драйвером. Предварительно должен быть активиро-
ван интерфейс уровня 1. До установления LAP возможен обмен
только ненумерованными кадрами.
Этот процесс включает в себя передачу команды Set Asynchronous
Balanced Mode Extended (SABME), адресат при этом должен от-
кликнуться посылкой ненумерованного отклика (UA — Unnumbered
Acknowledgment). После установления канала уровень 2 может пе-
редавать информацию для уровня 3. Ниже (рис. 4.3.3.13) приведе-
на последовательность обмена кадрами на уровне 2:
Сеть
Терминал
UA
RR
RR I
IFRAME |
Ненумерованное
подтверждение
Приемник готов
Информационный
кадр
Рис. 4.3.3.13 Последовательность обмена кадрами на уровне 2
Получение каждого информационного кадра (IFRAME) должно
быть, в конце концов, подтверждено (прислан пакет RR; см. табли-
цу 4.3.3.1). Число IFRAME, которое может быть послано, не дожи-
даясь подтверждения получения (размер окна), может лежать в пре-
делах 1-127. В случае телефонии это число равно 1. Если ресурс
°КНа исчерпан, партнер вынужден задержать отправку очередного
пакета до подтверждения получения посланного ранее кадра (RR).
я выявления потери кадров используется таймер. Таймер запус-
254
Гпава 4
кается всякий раз при посылке командного кадра и останавливает-
ся при получении подтверждения. Этого таймера достаточно, чтобы
проконтролировать доставку, как команды, так и отклика. Если
произошел таймаут, нельзя определить, какой из этих двух кадров
потерян. Кадр, поврежденный на уровне 1, будет принят с неверной
FCS (Frame Check Sequence) и по истечении времени, заданного тай-
мером, будет произведена посылка командного кадра с битом ро11=1.
Партнер при этом вынужден прислать значение системной перемен-
ной, характеризующей ситуацию. По этой переменной можно су-
дить, был ли получен исходный кадр.
Таким образом, можно идентифицировать факт потери инфор-
мационного кадра (нужна ретрансмиссия) или отклика на него.
После трех ретрансмиссий считается, что канал разорван, и предпри-
нимается попытка его восстановить. FCS получается путем деле-
ния последовательности бит, начиная с адреса и кончая (но не вклю-
чая) FCS, на образующий полином Х16+Х12+Х5+1. Практически это,Л
делается с использованием сдвигового регистра, который в исход-
ном состоянии устанавливается в единичное состояние. В конеч-
ном результате в регистре оказывается код остатка от деления, й
Дополнение по модулю 1 этого остатка и есть FCS. 1
Данные
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |l6
Рис. 4.3.3.14 Схема вычисления контрольной суммы (FCS/CRCJ
Другой возможной ошибкой является получение 1-кадра с невер-
ным номером N(S). Это возможно, когда LAP работает при ширине
окна более 1. Если потерян кадр с номером N(S)=K, принимающая:
сторона не должна посылать подтверждение приема кадра К+1. От-
клик при этом имеет тип REJ (см. таблица 4.3.3.1) с N(R)=K+L
Это укажет передающей стороне, что все кадры до К получены, но
необходимо возобновить передачу, начиная с кадра К. При выявле-
нии ошибки в N(R) связь прерывается, реинициализируются пере-
менные состояния передающей и принимающей сторон, после чего
канал восстанавливается, и обмен возобновляется с самого начала.
Ниже на рис. 4.3.3.15 показана схема алгоритма восстановле-
ния после потери кадра RR.
Сигнал RNR (получатель не готов) используется для запрет»
пересылки пакетов партнеру на уровне 2 и может использоваться
при реализации приоритетных услуг. Другим пакетом, который спе-
Сети передачи данных. Метод доступа
255
Таблица 4.3.3.1. (См. также раздел о протоколе Х.25]
р/р Poll=l для команды, в противном случае конечный бит
для отклика.
jpRAME (Information Frame) Информационный кадр
DISC (Disconnect) Отсоединить
gR (Receiver Ready) Приемник готов
уд (Unnumbered Acknowledge) Ненумерованное подтверждение
RNR (Receiver Not Ready) Приемник не готов
FRMR (Frame Reject) Кадр отвергнут
REJ (Reject) Отказ
DM (Disconnect Mode) Режим отключения
SABME (Set Asynchronous Balanced Mode Extended) Установка
расширенного асинхронного сбалансированного режима
UI (Unnumbered information) Ненумерованная информация.
цифицирован на уровне 2, является кадр Frame Reject (FRMR). Этот
кадр может быть получен объектом второго уровня, но не может
быть послан. При получении этого кадра система сбрасывается в
исходное состояние. После завершения процедуры обмена разрыв
канала производится путем посылки кадров DISC (disconnect) и
отклика UA (Unnumbered Acknowledgment), с этого момента обмен
кадрами 1-типа не возможен. Кадр DM (Disconnect Mode) может
выполнять те же функции, что и UA. Он используется в качестве
отклика на SABME, если слой 2 не может установить связь, или
отклика на DISC, если связь уже разорвана.
Для управления и контроля за выделяемыми идентификаторами
TEI предназначен специальный драйвер, который имеет возможность
выделять и удалять используемые TEI. Все сообщения, связанные с
TEI, передаются с помощью пакетов SAPI (Service access point identifier).
Так как работа с TEI должна выполняться вне зависимости от состо-
^Ис- 4.3.3.15 Восстановление системы после потери кадра RR
256
Глава 4
яния уровня 2, все TEI-сообщения являются ненумерованными (UI)
и не требуют отклика. Надежность достигается путем многократной
пересылки пакётов. Пока терминалу не присвоен TEI (Terminal
endpoint identifier), используется широковещательный метод обмена.
Все терминалы пользователя должны воспринимать любые управля-
ющие кадры. Кадры управления в процессе присвоения TEI термина-
лу рассылаются широковещательно. Схема присвоения TEI и уста-
новления связи показана ниже на рис. 4.3.3.16:
Терминал
Сеть
Рис. 4.3.3.16 Алгоритм выделения TEI и формирования связи
Третий уровень Х.25 служит для доставки управляющих сооб-
щений даже в случае отказа сети, именно здесь выполняется рекон-
фигурация маршрута, если это необходимо. Сигнальный пакет 3-го
уровня имеет формат (рис. 4.3.3.17):
Рис. 4.3.3.17 Формат сигнального пакета уровня 3
Сети передачи данных. Метод доступа 25 7
Эти пакеты следуют от терминала к коммутатору и наоборот.
Первый октет (поле протокольный дискриминатор) дает D-каналу в
будущем возможность поддержки нескольких протоколов. Приве-
денный код соответствует стандартному управляющему запросу
пользователя. Третий октет (поле код запроса — call reference value)
используется для идентификации запроса вне зависимости от типа
коммуникационного канала, где этот запрос может быть реализо-
ван. Четвертый байт характеризует назначение пакета (например,
SETUP — запрос установления канала). Возможные типы сообще-
ний перечислены в таблице 4.3.3.2. Длина сообщения зависит от
еГо типа. Стандарт не регламентирует содержания полей, следую-
щих за полем тип сообщения, и они могут использоваться по ус-
мотрению пользователя для расширения функциональных возмож-
ностей системы.
В приведенной ниже таблице 4.3.3.3 представлены информаци-
онные элементы, которые могут содержаться в сообщениях SETUP
(это самый сложный тип сообщений).
Сигнальная система ISDN позволяет пользователю уже на фазе
формирования канала с помощью запроса SETUP сформулировать
требования к каналу, задав значение ВС (Bearer Capability, см. таб-
лицу 4.3.3.3), а также HLC (High Layer Compatibility) и LLC (Low
Layer Compatibility), характеризуя необходимый вид усл^т. При этом
проверяется совместимость запрашиваемых скоростей и имеющих-
ся в распоряжении возможностей. HLC определяет тип сервиса или
оборудования (телефон, факс группы 3 или 4, видеотекст), a LLC —
быстродействие терминала пользователя, механизм адаптации к
скорости передачи данных, контроль четности, синхронный/асинх-
ронный интерфейс и т.д. ВС может принимать значения (например,
«BC=speech»):
ВС = speech Означает, что используется обычная для этого вида услуг маршрутизация - может быть задействовано не более двух спутников, (G.711);
3.1kHz audio Не должно использоваться эхо-подавление и DCME - (Digital Circuit Multiplication Equipment - оборудование уплотнения), необходим ц/А-адаптер
7 kHz Высококачественная телефония (рекомендации CCITT G.722/G.725), требует 64 Кбит/с; ’
64kbit/s Скоростной информационный обмен
9 ^ак- № 3430 Семенов
258
Гпава ф
Таблица 4.3.3.2 Коды типов сообщений
8 7 6 5 4 3 2 1 Значение сообщение
0 0 0 0 0 0 0 0 Переход к определенным типам сообщений:
0 0 0 - - - - - Сообщения о состоянии:
0 0 0 0 1 ALERTING (оповещение)
0 0 0 1 0 Call proceeding (состояние запроса)
0 0 0 1 1 Progress (прогресс)
0 0 1 0 1 Setup (начальная установка)
О' 0 1 1 1 Connect (соединение)
0 1 1 0 1 Setup acknowledge (подтверждение начальной установки)
0 1 1 1 1 Connect acknowledge (подтверждение соединения)
0 0 1 - - - - - Сообщения фазы запроса информации:
0 0 0 0 0 User information (пользовательские данные)
0 0 0 0 1 Suspend reject (отложенный отказ)
0 0 0 1 0 Resume reject (отказ возобновления)
0 0 1 0 1 Suspend (откладывание выполнения)
0 0 1 1 0 Resume (возобновление)
1 1 0 1 Suspend acknowledge (подтверждение откладывания)
0 1 1 1 0 Resume acknowledge (подтверждение возобновления)
0 1 0 - - - - Сообщения об устранении дефекта:
0 0 1 0 1 Disconnect (отсоединение)
0 0 1 1 0 Restart (повторный старт)
0 1 1 0 1 Release (освобождение)
0 1 1 1 0 Restart Acknowledge (подтверждение повторного старта)
1 1 0 1 0 Release complete (освобождения завершено)
0 1 1 - - - - - Прочие сообщения:
0 0 0 0 0 Segment (сегмент)
0 0 0 1 0 Facility (возможность)
0 1 1 1 0 Notify (обращение внимания)
1 0 1 0 1 Status inquiry (запрос состояния)
1 1 0 0 1 Congestion control (управление перегрузкой) к
1 1 0 1 1 Information (информация)
1 1 1 0 1 Status (состояние)
* Цифрами в верхней части таблицы пронумерованы биты кодов
Сети передачи данных. Метод доступа
259
Таблица 4.3.3.3. Поля SETUP-сообщений
Поле в пакете Длина (октеты) Комментарии
"дискриминатор ^тротокола 1
1Содзапр°са 2-3 =
сообщения 1
"Передача завершена 1 Опционно, включается, если пользователь или сеть указывает, что вся информация включена в это сообщение SETUP
Возможности канала 6-8 Описывает CCITT телекоммуникационные услуги (ВС)
Идентификация канала 2-? Служит для идентификации канала в пределах ISDN-интерфейса, управляемого данными процедурами
Специфические возможности сети 2-? Опционно
Дисплей 2-82 Опционно: 1А5 (ASCII) символы для отображения на терминале
Keypad 2-34 Альтернатива для пересылки кода вызываемого объекта. Keypad может использоваться и для другой информации
Номер отправителя 1-? Опционно
Субадрес отправителя 2-23 Опционно
Номер адресата 2-? В случае направления пользователь-сеть является альтернативой keypad
Субадрес адресата 2-23 Опционно
Выбор транзитной сети 2-? Опционно
Совместимость с .нижним уровнем (LLC) 2-16 Опционно
Совместимость с .верхним уровнем (HLC) 2-4 Опционно
Пользователь- пользователь .— 2-131 Опционно, когда вызывающий пользователь хочет передать информацию вызываемому
9*
260 Гпава 4
Услуги типа speech или 3.1 kHz audio возможны и через обще»
ственную коммутируемую телефонную сеть (PSTN), остальные из
перечисленных требуют 64-килобитного цифрового канала. Схема
формирования запроса, получения доступа к определенному виду
услуг показана ниже на рисунке 4.3.3.18. Помимо названных услуг
существуют и другие, например, видео-телефония, видеоконференции
и пр., список этот постоянно расширяется. При реализации 7кГц-
телефонии должны быть выполнены следующие требования:
• Должно использоваться терминальное оборудование, рассчитан*
ное для работы с 3.1кГц, и обычные сетевые телефонные каналы.
• Время реализации вызова должно быть приемлемо малым.
• Система должна выдавать сообщение в случае, если в резуль-
тате диалога реализуется 3.1кГц вместо 7.
Видео телефония использует один или два В-канала. В Европе
приняты следующие нормы (Normes Europeennes de Telecommuni-
cation-NET):
NET3 ISDN с обычной (базовой) скоростью обмена
NET5 ISDN с первичной скоростью обмена
NET 7 терминальные адаптеры
NET33 цифровая телефония.
Рис. 4.3.3.18 Последовательность сообщений при реализации
стандартного вызова
Сети передачи данных. Метод доступа 261
Вызываемый партнер получает SETUP-сообщение через широко-
вещательное обращение. Все терминалы, соединенные с NT1 могут
анализировать SETUP-сообщение с тем, чтобы определить, соответ-
ствуют ли они вызывающей стороне. Соответствие определяется по
возможностям канала и по совместимости информационных эле-
ментов нижнего уровня. Если терминал соответствует требованиям
запроса, он посылает сети сообщение, Alerting (Оповещение). В то
же время, если необходимо, терминал должен сформировать локаль-
ный сигнал вызова (напр., звонок). После получения всей необходи-
мой информации сеть выдает сообщение CALL PROCEEDING, кото-
рое указывает на то, что начата установка связи с объектом вызова.
Когда терминал обнаружил, что на запрос получен отклик, он пере-
адресует CONNECT-сообщение сети. Сеть регистрирует запрос и
выдает команду терминалу соединиться с соответствующим В-ка-
налом, послав пакет CONNECT ACKnowledge, содержащий код
В-канала. В любой момент времени к В-каналу может иметь доступ
только один терминал. Все остальные терминалы, которые отклик-
нулись на запрос, получат от сети сообщение RELEASE, которое
переводит их в пассивное состояние. Пользователь может отменить
запрос в любое время, послав три сообщения: DISConnet, RELease и
RELease COMPlete (см. рис. 4.3.3.19 и таблица 4.3.3.2).
Терминальное
оборудование -
инициатор
Сеть
Запрошенное
терминальное
оборудование
DISCONNECT
Release
complete
RELEASE
DISCONNECT
Release
complete
RELEASE
Рис. 4.3.3.19 Обмен сообщениями при разрыве связи
Возможна временная пассивация терминала посредством сооб-
щения SUSPEND с последующим возобновлением прерванного ре-
жима с помощью сообщения RESUME. Каждое из этих сообщений
тРебует подтверждения получения (SUSPEND ACKnowledge и
RESUME ACKnowledge, соответственно). При вызове может оказаться
несколько терминалов, отвечающих запрашиваемым требованиям
262
Гпава 4j
(например, телефонных аппаратов). Вызывающая сторона может
выбрать один из них (зная, например, их положение). Существует
два механизма обращения к заданному терминалу. Первый исполь-
зует вспомогательную службу Direct Dialing-In (DDI), которая в слу-
чае реализации обычного доступа к ISDN называется Multiple
Subscriber Number (MSN). В DDI и MSN номер сети используется
для целей маршрутизации в пределах локальной сети пользовате-
ля. Каждому терминалу в сети должен быть присвоен уникальный
MSN-номер. Именно этот номер используется для идентификации
при SETUP-процедуре.
Второй механизм адресации к заданному терминалу базируется
на субадресации (Subaddressing — SUB). В этом варианте дополни-
тельная адресная информация передается от источника запроса к •
адресату. Этот адрес не является частью ISDN-номера, который ис-
пользуется для целей маршрутизации. Этот адрес может быть приме-
нен для обращения к некоторому процессу внутри терминала (не
следует забывать, терминалом может быть ЭВМ) или к приложени-
ям, которые не следуют стандартам OSI. Каждый терминал, подсое-
диненный к пассивной шине, нуждается в присвоении ему субадреса.
Принципиальное различие между DDI/MSN и SUB методами ад-
ресации заключается в том, что для DDI/MSN адрес является час-
тью ISDN номера, в то время как для SUB это не так.
В этом случае каждому терминалу, подключенному к пассивной
шине, должен быть присвоен такой субадрес. Процедура SETUP
должна содержать информацию о субадресе. Для выбора типа услуг
и проверки терминальных возможностей используется обмен сооб-
щениями ALERTING-CONNECT.
Для максимального удовлетворения запросов потребителей ISDN
должна поддерживать самые разные дополнительные виды услуг.
Чтобы решить эти задачи на уровне 3, для интерфейса пользова-
тель-сеть разработаны два протокола — функциональная и стиму-
лирующая сигнальные процедуры. В случае стимулирующей сиг-
нальной процедуры терминал не должен иметь какой-либо инфор- ,
мации о вспомогательных видах услуг. Работа терминала
контролируется сетью с помощью сигнальных сообщений уровня 3. 4
Сеть и терминал работают по схеме клиент-сервер, и от терминала
не требуется особых аналитических способностей. Базовый формат
управляющих сообщений соответствует типу INFORMATION. Су-
ществуют две разновидности этого протокола: один использует уп-
равляющие последовательности символов, заключенные между * и
#; для второго — сеть должна хранить специальный профайл для ,
Сети передачи данных. Метод доступа
263
каждого терминала. Такой профайл может переопределять функ-
цию некоторых клавиш терминала. Нажатие такой клавиши осу-
ществляет вызов определенного вида услуг.
В случае функциональной сигнальной процедуры терминал дол-
жен знать все о вспомогательном виде услуг и хранить всю необхо-
димую информацию о них. Функциональный протокол использует
информационные элементы facility (возможность, см. 'таблицу
4.3.5.4). Для пересылки этих информационных элементов исполь-
зуются сообщения типа REGISTER (см. описание протокола Х.25).
функциональный протокол базируется на протоколе ROSE (Remote
Operations Service Element). Этот протокол служит для поддержки
приложений, где необходим интерактивный контроль сетевых
объектов. Протокол ROSE обеспечивает запуск процесса, поддер-
живает процедуры подтверждения и последующее управление про-
цессом. В таблице 4.3.5.4 приведен перечень дополнительных ус-
луг, предоставляемых ISDN и поддерживаемых функциональным
протоколом.
Таблица 4.3.5.4. Дополнительные услуги сети ISDN
Определение вызывающего номера (более эффективный аналог АОН);
Ограничение (запрет) по вызывающим номерам;
Ожидание вызова;
Прямой набор номера;
Субадресация;
Переносимость терминала;
Телефонные конференции;
Безусловная переадресация вызовов;
Переадресация, если номер занят;
Переадресация вызова при отсутствии ответа;
Групповые номера (по одному и тому же номеру к серверу могут
дозваниваться несколько модемов)
Реально это лишь ядро списка, разные сети могут предоставлять
И многие другие услуги.
При установлении телефонного канала используется сообщение
TUP (Telephony User Part). В ISDN определены также сообщения
ISUP (Integrated Services User Part), которые должны стать основой
всех будущих разработок. Примерами ISUP могут служить следую-
щие сообщения:
264
Гпава 4
IAM (Initial Address Message) используется для инициализации канала, передачи маршрутной информации и параметров запроса.
SAM (Subsequent Address Message) посылается вслед за IAM, когда необходимо передать дополнительную информацию о предстоящей сессии.
INR (Information Request Message) посылается коммутатором для получения информации по текущей сессии.
INF (Information Message) передает информацию, запрошенную INR.
ACM (Address Complete Message) подтверждает получение всей необходимой маршрутной информации.
CPG (Call Progress Message) посылается адресатом вызывающей стороне и информирует о том, что имело место какое-то событие.
ANM (Answer Message) подтверждает получение запроса, используется для начала измерения времени обработки запроса, для контроля информационного потока и доступа пользователей.
FAR (Facility Request Message) посылается одним коммутатором другому для активации его состояния.
FAA (Facility Accepted Message) является позитивным откликом на запрос FAR.
FRJ (Facility Reject Message) отклик на запрос FAR, если он не может быть выполнен.
USR (User-to-User Information Message) используется для обмена информацией между пользователями (помимо сигнальной информации).
CMR (Call Modification Request Message) сообщение, которое может быть послано в любом направлении, для модификации сессии, например, для перехода от передачи данных к передаче голоса.
CMC (Call Modification Completed Message) сообщение-отклик на запрос CMR, подтверждающее его исполнение.
CMRJ (Call Modification Reject Message) сообщение-отклик на запрос \ CMR, оповещающее об отклонении этого запроса.
REL (Release Message) сообщение, посылаемое в любом направлении и оповещающее о том, что система свободна и готова перейти в пассивное состояние при получении сообщения о завершении процедуры release.
RLC (Release Complete Message) - посылается в ответ на REL.
В ISDN используются базовая (В-канал, 64 Кбит/с) и первичная
(1,544/2,048 Мбит/с) скорости передачи информации. Сигнальный;
Сети передачи данных. Метод доступа
265
D-канал формируется на основе 24-го временного домена (timeslot)
в случае 1,544 Мбит/с и 16-го для 2,048 Мбит/с. Характеристики
первичных каналов ISDN приведены в таблице 4.3.3.5.
Таблица 4.3.3.5. Характеристики первичных каналов ISDN
"Быстродействие первичного канала Кодировка Импеданс линии Временной домен D-канала Уровень сигнала
1,544 Мбит/с B8ZS 100 Ом 24 3 в
~~~~2Д48 Мбит/с HDB3 120 Ом 16 3 в
Различие между базовой и первичной скоростями обмена заклю-
чается в следующем.
Для первичной скорости не предусматривается интерфейс много-
точечного обмена в локальной сети пользователя; связь устанавли-
вается между сетью и одним из РАВХ (Public Automatic Branch
Exchange) или другим терминалом.
В случае первичной скорости отсутствуют какие-либо средства
для деактивации связи с целью экономии энергии. Для пользователя
желательно иметь доступ, как к базовым, так и первичным каналам
Для базовой скорости передачи работает сигнальная цифровая
система доступа DASS (Digital Access Signaling System). Формат
кадра при этом имеет вид (DASS2/DPNSS — Digital Private Network
Signaling System):
12 1 до 45 2 1 (Число октетов
Флаг Адрес Управление Сообщение 3-го уровня FCS Флаг
Рис. 4.3.3.20 DASSS/DPIVSS-кадр уровня 2
Этот формат не отличается от общепринятого для уровня 2 ISDN,
за исключением числа байт управления (см. рис. 4.3.3.20 и 4.3.3.7),
что допускается регламентирующими документами. Использование
местной ISDN-АТС открывает дополнительные возможности. По-
мимо высококачественной локальной связи появляются коллектив-
ные (групповые) номера, что снимает ограничение на число пользо-
вателей, подключенных к узлу через обычные аналоговые модемы.
се пользовательские модемы дозваниваются по одному и тому же
номеру, а коммутатор выполняет функцию пакетного мультиплек-
са* Емкость таких АТС легко наращивается, отдельные АТС мо-
гут объединяться друг с другом. Схема взаимодействия такой АТС
xNX) с терминальным пользовательским оборудованием, други-
266
Гпава 4
ми PTNX и основной сетью ISDN показана на рис. 4.3.3.21. Мест- i
нал АТС может предоставлять те же услуги, что и традиционная
сеть ISDN, плюс запрограммированные локально виды сервиса (диа-
лог между пользователями локальной сети, услуга типа «не беспо-
коить» и т.д.).
Рис. 4.3.3.21 Связи местной ISDN-ATC
Взаимодействие между ISDN и PSPDN регулируется стандартом'
CCITT Х.31 (и 1.462). Х.31 позволяет использовать ISDN с суще-
ствующими сетями Х.25. Схема взаимодействия периферийного обо-
рудования, ISDN и PSPDN показана на рисунке 4.3.3.22 (ISDN-
коммутатор может и отсутствовать).
Рис. 4.3.3.22 Схема взаимодействия сетей ISDN и Х.25
ТА — терминальный адаптер; ТЕ — терминальное оборудование; NT —
сетевое терминальное оборудование
Доступ к программам обработки пакетов возможен через В- или
D-каналы. В зависимости от вида приложения доступ через D-ка-
нал имеет определенные преимущества. D-канал в отличие от В-
канала принципиально не может быть заблокирован. Возможна
работа одновременно с 8-ю терминалами, подключенными к пассив-
ной ISDN-шине. Кроме того, работа с D-каналом оставляет В-канал
свободным для задач, которые не решаемы через D из-за его малого
быстродействия (16 Кбит/с). А согласно рекомендациям LAPD бы-
передачи данных. Метод доступа 267
сТродействие D-канала не может быть увеличено, по этой же причи-
не максимальная длина пакетов Х.25 в данной схеме не может
превышать 260 октетов (против 1024 для обычных каналов Х.25).
К недостаткам использования D-канала можно отнести возможное
увеличение задержек из-за низкого быстродействия. Протокол Х.25
был разработан довольно давно для «традиционных» приложений
и его недостаточная гибкость (большие задержки откликов, таймау-
ты и пр.) приводит к тому, что он совершенно не пригоден для
некоторых новых приложений. Это вынудило разработку для ISDN
новых режимов работы с пакетами. И первое, что было сделано —
это четкое разделение управляющих и информационных потоков.
ISDN может рассматриваться как две логически независимые
субсети — сигнальную субсеть и коммутируемую информационную
сеть (в Х.25 информация и управление осуществляется по одним и
тем же каналам). В соответствии с этим разделением терминоло-
гия CCITT различает плоскость управления (C-plane) и пользова-
тельскую информационную плоскость (U-plane, см. рис. 4.3.3.23).
В ISDN существует два режима: frame relaying (передача кадров,
наиболее простой из режимов) и frame switching (коммутация кад-
ров). Отличительной особенностью режима frame relaying является
отсутствие подтверждений получения пакета при обмене данными
между ISDN-терминалами (аналог UDP в TCP/IP сетях). Для обо-
их режимов используется одни и те же сигнальные процедуры (Q.933),
но они отличаются протоколами U-плоскости при пересылке ин-
формации. Здесь используются протоколы передачи данных, бази-
рующиеся на усовершенствованном стандартном сигнальном про-
токоле LAPD слоя 2, известном как LAPF — Link Access Procedures
Терминал
Терминал
Рис. 4.3.3.23 Услуги ISDN в режиме переключения
(Цифрами помечены уровни протоколов, в скобках приведены ссылки
на документы ITU]
268
Гпава 4
for Frame Mode Bearer Services (Q.922). Пользователь может уста-
новить несколько виртуальных соединений и/или постоянных вир-
туальных связей одновременно с несколькими адресатами.
На сигнальном уровне С-плоскости используются стандартные
LAPD-процедуры слоя 2 (Q.921 или 1.441), а для слоя 3 специфика-
ция кадрового режима (Q.933). Но на U-плоскостй сеть поддержи-
вает только небольшую часть связного протокола:
• разделение кадров с использованием HDLC-флагов;
• проверка кадров по длине и контрольной сумме, выбрасыва-
ние кадров с ошибками;
• мультиплексирование и демультиплексирование кадров, отно-
сящихся к разным виртуальным запросам, на основе их адресов
слоя 2. л
В простейшем случае сеть посредством сигнальных процедур на х
фазе setup формирует вход в маршрутную таблицу. На уровне 2 для
каждого виртуального запроса выделяется адрес, который остается
действительным только на время данного вызова. При пересылке
данных сеть просто индексирует маршрутную таблицу, используя
адреса слоя 2 поступающих кадров, и ставит их в очередь на переда-
чу по соответствующему маршруту. На фазе передачи информации
терминалы используют протоколы более высокого уровня по схеме
точка-точка без привлечения сети. Схема протокола коммутации
кадров показана ниже на рис. 4.3.3.24, здесь передача кадров про-
исходит с подтверждением получения (до какой-то степени аналог
протокола TCP). Сеть детектирует потери и случаи дублирования
пакетов.
Здесь на сигнальном уровне все процедуры следуют требовани-
ям связного протокола ISDN в полном объеме, в том числе и при
передаче данных. Это подразумевает необходимость подтверждения
получения каждого информационного кадра, пересылаемого от тер-
минала к терминалу. Сеть контролирует доставку кадров и выяв-
ляет ошибки.
Как и в предыдущем случае, мультиплексирование и демультип-
лексирование выполняется с использованием адресов слоя 2. Адрес
кадра может содержать 2-4 октетов, а информация занимать от 1 до
262 октетов. Последняя величина может быть увеличена в резуль-
тате переговоров между отправителем и получателем при формиро-
вании виртуального канала. Рекомендуется не использовать кадров
с размером поля данных более 1600 октетов во избежание фрагмен-
тации и последующей сборки сообщений.
ITU-T делит все канальные услуги на две категории. 8 типов
услуг уже определены для случая коммутации каналов и три опре-* ,
Сети передачи данных. Метод доступа
269
Т
Терминал
Сеть
Терминал
Рис. 4.3.3.24 Режим переключения кадров
делены для коммутации пакетов. Три из восьми считаются опреде-
ляющими и каждый ISDN-переключатель должен их поддерживать
(ITU-T рекомендация 1.230).
4.3.4, Протокол Frame Relay
Протокол Frame Relay (1.122 ITU-T;
ANSI T1S1.2; RFC-1490, -1315,
-1604; см. также www.frforum.com/
f rame-relay /5000/Approved/FRF. 3 j
FRF.3.1/FRF3.f.0.html) является одним из новых телекоммуника-
ционных протоколов, он обеспечивает большую скорость передачи
данных, но и меньшую надежность доставки информации. Frame
Relay предназначен для межсетевого общения, ориентирован на со-
1
М
единение и использует два протокольных уровня модели OSI. Ос-
тальные уровни должны реализоваться программно. Такая схема
заметно удешевляет интерфейс. Протокол вводит понятие Committed
Information Rates (CIR — оговоренные скорости передачи), обеспе-
чивая каждому приложению гарантированную полосу пропускания.
Если приложение не использует полностью выделенную полосу, другие
приложения могут поделить между собой свободный ресурс. Frame
Relay гарантирует большее быстродействие, чем Х.25. Стандарт
предусматривает 2-х, 3-х и 4-х байтовые форматы заголовков (ANSI
Т1.618 и ITU-T Q.922) и синхронную передачу данных. Примене-
ние инкапсуляции гарантирует транспортировку пакетов других
протоколов через сети Frame Relay. Пакет Frame Relay начинается и
3авеРшаетСЯ разграничительным байтом 0х7Е (что соответствует и
Стандарту Х.25). Максимальный размер кадра 1600 октетов. Фор-
ант пакета показан на рис. 4.3.4.1.
270
Глава 4
f
1 2 3 4 5 6 7 ... N N+1 N+2 N+3
Флаг 0х7Е Заголовок Q.922 Управление UI=0x03 Заполни- тель NLPID FCS Флаг 0х7Е
Поле данных
Рис. 4.3.4.1. Формат пакетов Frame Relay
(цифры сверху — номера байт]
NLPID — идентификатор протокола сетевого уровня (Network
Layer Protocol ID).
FCS — двухбайтовая контрольная сумма кадра (Frame Control
Sum). Заполнитель является опционным и может отсутствовать.
Различные форматы заголовков кадров Frame Relay показаны на
рисунках 4.3.4.2, 4.3.4.3 и 4.3.4.4. В верхней части рисунка при-
ведена нумерация бит.
1 2 3 4 5 6 7 8
ЕА C/R DLCI (старшая часть)
ЕА DE BECN FECN DLCI (Младшая часть)
Рис. 4.3.4.2. 2-байтовый заголовок пакета Frame Relay (адрес!
С/R бит Command/Response (Команда/Отклик).
Е/А бит Extended Address (Расширенный адрес) определяет,
следует ли рассматривать следующий байт в качестве части адреса
(Е/А=0 заголовок продолжается в следующем октете).
DLCI (Data Link Control Interface) адрес управляющего интер-
фейса информационного канала (имеет только локальный смысл).
В двухбайтовой версии DLCI занимает в суммеЮ бит.
FECN бит Forward Explicit Congestion Notification (указание
на возможность реагирования на перегрузку при посылке пакетов).
Сигнализирует отправителю о переполнении буферов на приеме.
BECN бит Backward Explicit Congestion Notification (тоже для
случая приема пакетов).
DE бит Discard Eligibility (пометка пакета при перегрузке
канала). Помеченный пакет может быть отброшен и потребуется
его повторная пересылка.
При возникновении перегрузки DCE-узел отправляет устрой-
ствам-адресатам пакет с FECN=1, а узлам, шлющим ему информа-;
цию, пакет с битом BECN=1. Большое число пакетов с такимиi
битами говорит о перегрузке и отправитель должен снизить частоту >
посылки пакетов или вовсе ее прекратить. t
Qern передачи данных. Метод доступа
271
12 3_4_5_6_7_8
ЕА C/R DLCI (старшая часто)
ЕА DE BECN FECN DLCI
ЕА D/C DLCI (Младшая часть) или DL-CORE управление
Рис. 4.3.4.3. 3-байтовый заголовок пакета Frame Relay
D/C — бит Data/Control (данные/управление) определяет, явля-
ется ли последующее поле младшей частью DLCI или его следует
интерпретировать как управляющую информацию DL-CORE.
1 2 3 4 5 6 7 8
ЕА C/R DLCI (старшая часть)
ЕА DE BECN FECN DLCI
ЕА DLCI (адрес управляющего интерфейса канала)
ЕА D/C DLCI (Младшая часть) или DL-CORE управление
Рис. 4.3.4.4. 4-байтовый заголовок пакета Frame Relay
Первым передается младший бит байта. Для управления сетью
используется протокол SNMP и база данных MIB. Формат кадра
Frame Relay показан на рис. 4.3.4.4.
NLPID — (Network Layer Protocol Identifier) идентификатор про-
токола сетевого уровня. Это поле может содержать коды многих
протоколов, включая IP, CCITT Q.933, ISO 8208, IEEE SNAP, CLNP
(ISO 8473) и т.д. Это поле говорит получателю, какой тип протоко-.
ла инкапсулирован. Коды NLPID стандартизованы документом ISO/
IEC TR 9577. Некоторые допустимые коды этого поля приведены в
таблице 4.3.4.1. Пользовательская информация располагается, на-
чиная с поля управления, и содержит код 0x03 для случая пересыл-
ки без подтверждения (Q.922, UI). Для всех прочих видов обмена
(кадры I- S-типов) подтверждение доставки является обязатель-
ным. Поле заполнитель предназначено для выравнивания границы
полей на 2-байтовый уровень. Длина этого поля может быть рав-
ной нулю или одному байту. Поле адрес описано выше (см. рис.
4*3.4.1, 4.3.4.2, 4.3.4.3). Если за кодом NLPID следует 4 октета
Уровней 2 и 3, это указывает на то, что используется связь, ориенти-
рованная на соединение. Протокол Frame Relay предусматривает
гибкую систему межсетевых соединения на основе мостов-шлюзов и
Маршрутизаторов. Все мосты и маршрутизаторы должны быть спо-
272
Гпава 4
собны воспринимать и правильно интерпретировать как NLPID-
так и SNAP-инкапсуляцию. Для обеспечения правильной интер-
претации идентификатора протокола PID, предусмотрен 3-октетный
уникальный идентификатор OUI (Organizationally Unique Identifier).
В пакетах для мостов и маршрутизатором в поле OUI предшествует
двух-октетному полю PID.
1 2 3 4 5 6 7 8
Байт1
2
4
5
6
7
N-2
N
Стартовый флаг кадра = 0х7Е
Адрес (стандартный размер 2 байта, но допускаются
3 и 4 байтовые адреса)
Поле управления (Q.922, UI или J-кадр)
Опционный заполнитель (0x00)
NLPID
Данные
Контрольная сумма FCS (2 байта)
Флаг завершения кадра = 0x7Е
Рис. 4.3.4.5. Формат маршрутизуемого кадра Frame Relay
Нетрудно видеть, что кадр Frame Relay имеет много общего с
Х.25 и ISDN. Здесь уже на протокольном уровне предусматривает-
ся мультикастинг.
Таблица 4.3.4.1. Коды поля NLPID
(идентификатор протокола сетевого уровня]
Тип кадра Название протокола Код
I-кадр (ISO 8208) N по модулю 8' 0x01
N по модулю 128 0x10
UI-кадр IP ОхСС
CLNP 0x81
Q.933 0x08
SNAP 0x80
Q.922 0х4Е
802.2 0х4С
Протокол, заданный пользователем (уровень 3) 0x70
Оети передачи данных. Метод доступа
273
Код протокола SNAP используется и для протоколов 802.3,
802.4, 802.5, FDDI и 802.6. При вложении IP в кадры Frame Relay
в поле управления записывается код 0x03, а в поле NLPID — ОхСС,
начиная с байта 5, располагается тело IP-дейтограммы, за которой
следует поле FCS. Формат маршрутизируемой IP-дейтограммы по-
казан на рис. 4.3.4.5А.
12 11 2
Флаг 0х7Е Адрес Q.922 Управ 0x03 NLPID ОхСС 1Р-дейтограмма FCS
Рис. 4.3.4.5А. Формат маршрутизируемой 1Р~дейтограммы
Аналогично осуществляется инкапсуляция пакетов протокола
CLNP, только здесь в поле NLPID записывается код 0x81. Для
примера на рис. 4.3.4.6 и 4.3.4.7 показаны пакеты для мостов
802.3 и FDDI (см. «Multiprotocol Encapsulation over Frame Relay»).
Байт1 Адрес Т1.618
3 Поле управления (0x03)
4 Заполнитель (0x00)
5 NLPID=0x80
6 OUI=0x00
7 OUI=0x80
8 OUI=OxC2
9 PID = 0x0001 или 0x0007
11 МАС-адрес места назначения
LAN FCS (если PID=0x0001)
N-1 Контрольная сумма FCS (2 байта)
Рис. 4.3.4.6 Формат мостового кадра Ethernet 802.3
Весьма перспективным сетевым протоколом особенно для пере-
дачи мультимедийных данных является ATM. Его модификация
м°Жет стать транспортным протоколом для цифрового кабельного
телевидения.
274 Глава 4
Байт 1 Адрес Т1.618
3 Поле управления (0x03)
4 Заполнитель (0x00)
5 NLPID=0x80
6 OUI+OxOO
7 OUI=0x80
8 OUI=OxC2
9 PID = 0x0004 или ОхОООА
11 Заполнитель (0x00)
12 Управление кадром
13 , МАС-адрес места назначения &
LAN FCS (если PID=0x0001) 4 байта
у
Контрольная сумма FCS (2 байта)
Рис. 4.3.4.7 Формат мостового кадра FDDI
'•Л
4.3.5. ATM — широкополосный ISDN
В настоящее время начинают широко внедряться каналы с про-
пускной способностью 150,52 и 622,08 Мбит/с. Эти каналы ис- :
пользуются как для соединения локальных сетей, так и непосред- ,
ственно для построения скоростных LAN. 150 Мбит/с может обес-
печить любые современные телекоммуникационные услуги кроме
телевидения высокого разрешения. Предусмотрен стандарт и на ско-
рость передачи 2,48832 Гбит/с. Так как время доставки для мно-
гих видов сетевых услуг реального времени является крайне важ- <
ной характеристикой, ATM находит широкое применение в телефо-
нии, кабельном телевидении и других областях. Следует учитывать,
что цифровой видеосигнал качества VHS требует 100 Мбит/с в от-
сутствии сжатия и 1,5-6 Мбит/с — при использовании сжатия. ;
Файл изображения 1000x1000 пикселей при 24 битах, характери-.
зующих цвет, занимает 3 Мбайта. ATM справится с передачей та-
кого кадра с учетом накладных расходов (заголовок) за ~0,2 сек.
Понятно, что при использовании сжатия можно получить заметно
большее быстродействие.
Это не значит, что доступны лишь указанные скорости, интер*
фейсы позволяют мультиплексировать большое число каналов с са*
мыми разными скоростями обмена. Но мультиплексирование н&
СеТИ передачи данных. Метод доступа
275
таких частотах представляет собой значительную проблему. Опре-
деленные трудности связаны с тем обстоятельством, что в ATM ;
трудно реализовать обмен без установления соединения (аналог UTP / ?
в Интернет)
Протокол ATM (Asynchronous Transfer Mode; см. также А.Н.
Назаров, М.В. Симонов. «АТМ. Технология высокоскоростных се-
тей». ЭКО-Трендз, М. 1998) является широкополосной версией ISDN,
работает на скорости 150,52 Мбит/с с пакетом постоянной длины
и минимальным заголовком. В ATM пакет называется ячейкой
(cell), этот термин введен, чтобы отличить пакеты ATM от пакетов
низкоскоростных каналов. Слово асинхронный в названии означа-
ет, что тактовые генераторы передатчика и приемника не синхрони-
зованы, а сами ячейки передаются и мультиплексируются по запро-
сам. При мультиплексировании используется статистическая тех-
нология. Асинхронная передача не предполагает упорядочивания
ячеек по каналам при пересылке. ATM поддерживает аппаратную
и пакетную коммутацию.
Каждый пакет ATM имеет 53 байта, из них 48 байт несут по-
лезную информацию (что для случая передачи звука, соответствует
6 мс). Для выделения пакета из потока используются такие же, как
в ISDN разделительные байты (0х7Е). Заголовок пакета содержит
лишь 5 байт и предназначен главным образом для того, чтобы
определить принадлежит ли данный пакет определенному вирту-
альному каналу. Отсутствие контроля ошибок и повторной переда-
чи на физическом уровне приводит к эффекту размножения оши-
бок. Если происходит ошибка в поле идентификатора виртуаль-
ного пути или виртуального канала, то коммутатор может отправить
ячейку другому получателю. Таким образом, один получатель не
получит ячейку, а другой получит то, что ему не предназначалось.
Виртуальный канал в ATM формируется также как и в ISDN.
Формально эта процедура не является частью ATM-протокола. Сна-
чала здесь формируется сигнальная схема, для этого посылается
запрос с VPI=0 и VCI=5. Если процедура завершилась успешно, можно
начинать формирование виртуального канала. При создании кана-
ла могут использоваться 6 разновидностей сообщений.
SETUP — запрос формирования канала.
CALL PROCEEDING — обработка вызова.
CONNECT — запрос принят.
CONNECT АСК — подтверждение получения запроса.
RELEASE — сообщение о завершении.
* RELEASE COMPLEATE — подтверждение получения сообще-
НИя RELEASE.
276
Гпава 4
Схема обмена сообщениями при установлении (и разрыве) вирту;
ального соединения показана на рис. 4.3.5.1. Предполагается, что
между ЭВЕМ-инициализатором и ЭВМ-адресатом находится два ATM-
переключателя. Каждый из узлов по пути к месту назначения при
получении запроса SETUP откликается, посылая сообщение CALL
PROCEEDING. Адрес места назначения указывается в сообщении
SETUP. В ATM используется три вида адресов. Первый — имеет 20
байт и имеет структуру OSI-адреса. Первый байт указывает на вид^
адреса (один из трех). Байты 2 и 3 определяют принадлежность
Стране, а байт 4 задает формат последующей части кода адреса, кото-
рая содержит 3 байта кода администрации (authority), 2 байта доме-
на, 2 байта области и 6 байтов собственно адреса. Во втором формате
байты 2 и 3 выделены для международных организаций, а не стран,
Остальная часть адреса имеет тот же формат, что и в варианте 1,
Третий формат является старой формой (CCITT Е.164) — 15 деся-
тичных цифр телефонного номера ISDN. В ATM не специфицирова-
но никакого алгоритма маршрутизации. Для выбора маршрута (от
коммутатора к коммутатору) используется поле VPI. VCI использу-
ется лишь на последнем шаге, когда ячейка посылается от переклю-
чателя к ЭВМ. Такой подход упрощает маршрутизацию отдельных
ячеек, так как при этом анализируется 12- а не 28-битовые коды,
Рис. 4.3.5.1. Обмен сообщениями при установлении и разрыве h
виртуального соединения
Сети передачи данных. Метод доступа 277
В каждом коммутаторе (переключателе) формируются специальные
таблицы, которые решают проблему переадресации ячеек.
Следует обратить внимание на то, что виртуальный канал (circuit) и
виртуальный проход (path) в данном контексте не тождественны. Вирту-
альный проход (маршрут) может содержать несколько виртуальных ка-
налов. Виртуальные каналы всегда являются полностью дуплексными.
• Сети ATM допускают создание маршрутов, с заданным VPI.
Субполя VPI и VCI образуют поле маршрута, которое занимает
24 бита (см. рис. 4.3.5.2).
8 7 6 5 4 3 2 1 Номера бит
В случае интерфейса сеть-
1 сеть весь этот байт
2 используется для VPI
3
GFC VPI
VPI VCI
VCI
VCI РТ RES CLP
НЕС
4
5
Рис. 4.3.5.2. Формат заголовка АТМ-пакета
(сетевой интерфейс пользователя — UNI]
Для интерфейса сеть-сеть (NNI) используется ячейка с несколь-
ко иным форматом заголовка. Там весь первый октет выделен для
VPI, а поле GFC отсутствует.
GFC Generic Flow Control (4 бита, смотри описание пакетов Х.25)
- общее управление потоком.
VPI Virtual Path Identifier (8 бит, служит для целей маршрути-
зации) - идентификатор виртуального пути.
VCI Virtual Call Identifier (16 бит, служит для целей маршрути-
зации) - идентификатор виртуального канала.
PT Payload Туре (2 бита, тип данных; это поле может занимать
и зарезервированное субполе RES.)
RES Зарезервированный бит.
ELP Cell Loss Priority — уровень приоритета при потере пакета
указывает на то, какой приоритет имеет пакет (cell), и будет
_ ли он отброшен в случае перегрузки канала.
G Header Error Control (8 биту поле контроля ошибок).
ет Б 0Тличие от Ethernet в ATM контролируемая сумма покрыва-
. т°лько заголовок. Это связано с тем, что ATM-коммутаторы дол-
Ъ1 принимать решения о переадресации ячейки, приняв коррект-
0 лишь заголовок.
278
Гпава 4
Ряд значений VCI и VPI имеют фиксированные значения, приве.
денные в таблице 4.3.5.1
Таблица 4.3.5.1. Фиксированные значения VCI/VPI
VCI VPI Назначение
0 только 0 Неопределенная ячейка
I все Мета управление
3 все Сетевое управление VP-каналом
4 все VP-управление для соединения между конечными точками
5 все Управление доступом по схеме точка-точка
6 все Ячейка управления ресурсами (для подавления перегрузки)
16 только 0 UNI (SNMP) управление сетью
Некоторые значения поля РТ зафиксированы, их значения пред-
ставлены в таблице 4.3.5.2.
Таблица 4.3.5.2. Заданные значения поля РТ
[Payload Type Identifier]
РТ Назначение ячейки Взаимодействие пользователь-пользователь
ООО Пользовательские данные (перегрузка отсутствует) Нет
001 Пользовательские данные (перегрузка отсутствует) Нет
010 Пользовательские данные (имеет место перегрузка) Да
он Пользовательские данные (имеет место перегрузка) Да
юо Ячейка виртуального канала О AM сегментного потока F5
Ю! Соединение точка-точка О AM сегментного потока F5
по Управление ресурсами
111 Зарезервировано
О AM - эксплуатация и техническое обслуживание. ATM обес-
печивает любые услуги в сети:
• Передача голоса на скоростях 64 Кбит/с. Один ATM-паке1?
соответствует 6 мсек.
• Передача музыки с использованием схемы кодирования Musical^
• Так как для случая изображения передается только перемер
ная часть картинки, ATM идеально подходит для решения такоГ?
рода задач.
Сети передачи данных. Метод доступа
279
. Задачи управления решаются менее экономно, но, тем не ме-
нее достаточно эффективно (предусмотрено несколько приоритетов
для управления потоками данных).
В ATM предусмотрено несколько категорий услуг (таблица
4.3.5.3).
Таблица 4.3.5.3. Типы категорий АТМ-услуг
Описание Пример
' CBR Постоянная скорость передачи Канал Т1
-R1WBR Переменная скорость передачи (реальное время) Видеоконференции
"NRT-VBR Переменная скорость передачи (нереальное время) Мультимедиа по электронной почте
ABR Доступная скорость передачи Просмотр WEB- информации
~ UBR Не специфицированная скорость передачи Пересылка файлов в фоновом режиме
Класс CBR не предусматривает контроля ошибок, управления
трафиком или какой-либо другой обработки. Этот класс пригоден
для работы с мультимедиа реального времени.
Класс VBR содержит в себе два подкласса — обычный и для
реального времени (см. таблицу выше). ATM в процессе доставки
не вносит никакого разброса ячеек по времени. Случаи потери яче-
ек игнорируются.
Класс ABR предназначен для работы в условиях мгновенных
вариаций трафика. Система гарантирует некоторую пропускную спо-
собность, но в течение короткого времени может выдержать и боль-
шую нагрузку. Этот класс предусматривает наличие обратной связи
между приемником и отправителем, которая позволяет понизить
загрузку канала, если это необходимо.
Класс UBR хорошо пригоден для посылки IP-пакетов (нет га-
рантии доставки и в случае перегрузки неизбежны потери).
ATM использует исключительно модель с установлением соеди-
Нения (здесь нет аналогий с UDP-протоколом). Это создает опреде-
ленные трудности для управления трафиком с целью обеспечения
тРебуемого качества обслуживания (QOS). Для решения этой зада-
Чи Используется алгоритм GCRA (Generic Rate Algorithm). Работа
ЭТог° алгоритма проиллюстрирована на рис. 4.3.5.3.
GCRA имеет два параметра. Один из них характеризует мак-
мально допустимую скорость передачи (PCR — Peak Cell Rate;
До ' — минимальное расстояние между ячейками), другой —
Устимую вариацию скорости передачи (CDVT=L). Если клиент
280
Гпава 4
Т
’1
Ячейка 1
__
*1
Рис. 4.3.5.3.
^2 Ячейка 3 ожидается после
Ячейка 2 прибыла
> Т после ячейки 1
^2
। Ячейка 3 ожидается после t2+T
|---------------------------->
Ячейка2 > Ячейка 2 прибыла
-------------/ д0 истечения времени Т
*2
Ячейка 3 ожидается после t^+2T
\ Ячейка 2 прибыла до
>йка2 > -г х
-------/ истечения времени Т + - Т
Ячейка 3 ожидается после t^+T
Иллюстрация работы алгоритма GCRA
не собирается посылать более 100000 ячеек в секунду, то Т=10
мксек. На рис. 4.3.5.3 представлены разные варианты следования
ячеек. Если ячейка приходит раньше, чем Т—t, она считается
подтверждаемой и может быть отброшена. Ячейка может быть со-
хранена, но при этом должен быть установлен бит CLP=1. Приме-
нение бита CLP может быть разным для разных категорий услуг
(смотри таблицу 4.3.5.3.). Данный механизм управления трафи-
ком сходен с алгоритмом «дырявое ведро», описанным в раздеД?
«Сети передачи данных».
Можно вычислить число подтверждаемых ячеек N, которые
гут быть переданы при пиковом потоке ячеек PCR=1/T. Пусть
время ячейки в пути равно 8. Тогда N == 1 + (L/(T-6)). Если поЛУ'
ченное число оказалось нецелым, оно должно быть округлено Д°
ближайшего меньшего целого.
Трудно устранимой проблемой для ATM является предотвращу
ние перегрузки на промежуточных коммутаторах-переключатеЛЯ?*
Коммутаторы могут иметь 100 внешних каналов, а загрузка МОЗ***
достигать 350000 ячеек/сек. Здесь можно рассматривать две заД|*
чи: подавление долговременных перегрузок, когда поток ячеек
восходит имеющиеся возможности их обработки, и кратковре#6*
Сети передачи данных. Метод доступа
281
е пиковые загрузки. Эти проблемы решаются различными спосо-
бами: административный контроль, резервирование ресурсов и уп-
авление перегрузкой, привязанное к уровню трафика.
В низкоскоростных сетях с относительно медленно меняющейся
или постоянной загрузкой администратор вмешивается лишь при
возникновении критической ситуации и предпринимает меры для
понижения скорости передачи. Очень часто такой подход не слиш-
ком эффективен, так как за время доставки управляющих команд
приходят многие тысячи ячеек. Кроме того, многие источники яче-
ек в ATM работают с фиксированной скоростью передачи (напри-
мер, видеоконференция). Требование понизить скорость передачи здесь
достаточно бессмысленно. По этой причине в ATM разумнее предот-
вращать перегрузку. Но для трафика типа CBR, VBR и UBR не
существует никакого динамического управления перегрузкой и ад-
министративное управление является единственной возможностью.
Когда ЭВМ желает установить новый виртуальный канал, она долж-
на охарактеризовать ожидаемый трафик. Сеть анализирует возмож-
ность обработки дополнительного трафика с учетом различных мар-
шрутов. Если реализовать дополнительный трафик нельзя, запрос
аннулируется. В отсутствии административного контроля несколько
широкополосных пользователей могут блокировать работу массы уз-
кополосных клиентов сети, например, читающих свою почту.
Резервирование ресурсов по своей сути близко административ-
ному контролю и выполняется на фазе формирования виртуального
канала. Резервирование производится вдоль всего маршрута (во всех
коммутаторах) в ходе реализации процедуры SETUP. Параметрами
резервирования может быть значение пикового значения полосы
пропускания и/или средняя загрузка.
Для типов сервиса CBR и VBR отправитель даже в случае пере-
грузки не может понизить уровень трафика. В случае UBR потери
не играют никакой роли. Но сервис ABR допускает регулирование
трафика. Более того, такое управление здесь весьма эффективно.
Существует несколько механизмов реализации управления. Так
предлагалось, чтобы отправитель, желающий послать блок данных,
сначала посылал специальную ячейку, резервирующую требуемую
полосу пропускания. После получения подтверждения блок данных
пересылается. Преимуществом данного способа следует считать то,
перегрузки вообще не возникает. Но данное решение не исполь-
тся из-за больших задержек (решение АТМ-форума).
цы* РУГОЙ спос°б сопряжен с посылкой коммутаторами специаль-
Ки ДЧеек отправителю в случае возникновения условий перегруз-
Ри получении такой ячейки отправитель должен понизить
282
скорость передачи вдвое. Предложены различные алгоритмы после,
дующего восстановления скорости передачи. Но и эта схема отверг
нута форумом ATM из-за того, что сигнальные ячейки могут быть
потеряны при перегрузке. Действительно данный алгоритм не все,
гда можно признать разумным. Например, в случае, когда коммута.
тор имеет 10 каналов с трафиком по 50 Мбит/с и один канал с
потоком в 100 кбит/с, глупо требовать понижения трафика в этом
канале из-за перегрузки.
Третье предложение использует тот факт, что граница пакета
помечается битом в последней ячейке. Коммутатор просматривает
входящий поток и ищет конец пакета, после чего выбрасывает все
ячейки, относящиеся к следующему пакету. Этот пакет будет пере,
слан позднее, а отбрасывание М ячеек случайным образом может
вынудить повторение передачи М пакетов, что значительно хуже.
Данный вариант подавления перегрузки был также не принят, так
как выброшенный пакет совсем не обязательно послан источником,
вызвавшим перегрузку. Но этот способ может быть использовав
отдельными производителями коммутаторов.
Обсуждались решения, сходные со «скользящим окном» в про-
токоле TCP. Это решение требует слишком большого числа буфе-
ров в коммутаторах (как минимум по одному для каждого вирту-
ального канала). После длинных дискуссий был принят за основу
совершенно другой метод.
После каждых М информационных ячеек каждый отправитель
посылает специальную RM-ячейку (Resource Management). Эта ячейка
движется по тому же маршруту, что и информационные, но RM-
ячейка обрабатывается всеми коммутаторами вдоль пути. Когда
она достигает места назначения, ее содержимое просматривается я
корректируется, после чего ячейка посылается назад отправителю.
При этом появляются два дополнительных механизма управления
перегрузкой. Во-первых, RM-ячейки могут посылаться не тольК<
первичным отправителем, но и перегруженными коммутаторами В
направлении перегрузившего их отправителя. Во-вторых, перегрУ*
женные коммутаторы могут устанавливать средний PTI-бит в и#*
формационных ячейках, движущихся от первоисточника к адреса*
ту. Но даже выбранный метод подавления перегрузки не идеале#»
так как также уязвйм из-за потерь управляющих ячеек. у
Управление перегрузкой для услуг типа ABR базируется на тоМ»
что каждый отправитель имеет текущую скорость передачи (AG®
— Actual Cell Rate), которая лежит между MCR (Minimum Cell Raw
и PCR (Peak Cell Rate). Когда происходит перегрузка, ACR умей*
шается, но не ниже MCR. При исчезновении перегрузки ACR увел#'
Сети передачи данных. Метод доступа
283
чивается, но не выше PCR. Каждая RM-ячейка содержит значение
заГрузки, которую намеривается реализовать отправитель. Это зна-
чение называется ER (Explicit Rate). По пути к месту назначения
эта величина может быть уменьшена попутными коммутаторами.
Ни один из коммутаторов не может увеличивать ER. Модификация
ER может производиться как по пути туда, так и обратно. При
получении RM-ячейки отправитель может скорректировать значе-
ние ACR, если это необходимо.
С точки зрения построения интерфейса и точек доступа (Т, S и
R) сеть ATM сходна с ISDN (см. рис. 4.3.3Л).
Для физического уровня предусмотрены две скорости обмена
155,52 и 622,08 Мбит/с. Эти скорости соответствуют уровням иерар-
хии SDH STM-1 и 4*STM-1. При номинальной скорости 155.52
Мбит/с пользователю доступна реально скорость обмена 135 Мбит/
с, это связано с издержками на заголовки и управление. Для ATM
используются коаксиальные кабели, скрученные пары (<100м для
обоих вариантов) и оптоволоконные кабели (~2км). Для канала
связи рассматриваются два кода CMI (Coded Mark Inversion) и скрэм-
блеры типа установка-сброс (set-reset). В CMI двоичный 0 передает-
ся как отрицательный импульс половинной длины, за которым сле-
дует положительный импульс той же длительности. Двоичная 1
представляется в виде отрицательного или положительного импульса
полной длины, так чтобы уровень менялся для последовательно
следующих 1 (система AMI, см. раздел 2.1). Это обеспечивает ба-
лансировку передающей линии по постоянному напряжению, но уд-
ваивает частоту переключения практически вдвое. Скрэмблерный
метод не меняет частоту переключения, но его эффективность зави-
сит от передаваемой информации. CMI предпочтительней для 155
Мбит/с. В настоящее время используется две схемы передачи дан-
ных применительно к ATM: базирующийся на потоке пакетов (cell
stream) и на SDH структурах. В первом случае мы имеем непре-
рывный поток 53-октетных пакетов, во втором эти пакеты уложе-
ны в STM-1 кадры. Управляющие сообщения располагаются в за-
головках секции и пути кадра SDHj~AAL (ATM Adaptation Layer)
служит для адаптации различных видов сервиса к требованиям
ATM-уровня. Каждый вид услуг требует своего AAL-протокола. Глав-
н°и целью AAL является обеспечение удобства при создании и ис-
полнении программ прикладного уровня. Для всех AAL определе-
два субуровня:
(Segmentation and Reassemble) делит пакеты высокого
Уровня, передает ATM и наоборот (сборка сообщений из
сегментов).
гв4
Гпава
CS (Convergent Sub-layer) зависит от вида услуг (обработка
случаев потери пакета, компенсация задержек, мониториро-
вание ошибок и т.д.). Этот подуровень может в свою
очередь делиться на две секции: CPCS (Common Part
Convergence Sublayer) - общая часть субуровня конверген-
ции и SSCS (Service-Specific Convergence Sublayer) - слу-
жебно-ориентированный подуровень конвергенции (после-
дний может и отсутствовать).
AAL-протоколы управляются значениями следующих переменных:
• Скорость обмена (постоянная или переменная).
• Режим соединения (с установлением связи или без).
• Синхронизация (требуется или нет синхронизация между от-
правителем и получателем)
В настоящее время определены четыре класса услуг, которые
могут требовать или нет синхронизации между отправителем и по-
лучателем, осуществлять обмен при постоянной или переменной ча-
стоте передачи, с установлением связи или без. Особенности этих
видов услуг для адаптивного уровня систематизированы в таблице
4.3.5.4. Каждая из услуг имеет свой AAL протокол.
Таблица 4.3.5.4. Особенности видов услуг для адаптивного уровня
Класс А (AAL1) Класс В (AAL2) Класс С (AAL3/4 или 5) Класс D (AAL3/4 или 5)
Синхронизация работы отправителя и получателя Необхо- дима Необхо- дима не нужна не нужна
Частота следования битов Постоян- ная Перемен- ная Перемен- ная \ Перемен- ная
Режим соединения С соеди- нением С соеди- нением С соедиг/ нением Без соеди- нения
Уровень адаптации 1-го уровня (AAL1) выполняет для верхн^гР
уровня следующие услуги (передача аудио- и видео- по каналам.
DS-1 и DS-3; постоянная скорость передачи):
• синхронизацию передатчика и приемника;
• передачу данных с фиксированной скоростью;
• индикацию потери и искажения данных, если эти ошибки 06
устраняются на уровне адаптации;
• передачу от отправителя получателю информации о структур®
передаваемых данных. 4
Сети передачи данных. Метод доступа 285
Для решения этих задач AAL первого уровня должен устранять
разброс задержек, выявлять ячейки, доставленные не по адресу, и
потерянные ячейки, сегментацию пакетов и последующее их восста-
новление, выполнять мониторирование ошибок в управляющей ин-
формации протокола AAL-PCI (Protocol Control Information). Ха-
рактер обмена здесь.строго ориентирован на соединение. AAL-1 ис-
пользует субуровни конвергенции и SAR. Субуровень конвергенции
обеспечивает постоянство скорости передачи ячеек. AAL-1 конвер-
генции не имеет какого-то специфического протокольного заголов-
ка. Этот субуровень разбивает входные сообщения на 46- или 47-
байтные блоки и передает их субуровню SAR для пересылки.
Структура протокольной части информационного поля ячейки
SAR-PDU представлена на рис. 4.3.5.4.
CSI позволяет приемнику распознать уровень конвергенции.
Подуровень SAR получает значение SN (порядковый номер) для каж-
дого 47-октетного блока данных от подуровня конвергенции. Поле
SNP (Sequence Number Protection — контрольная сумма) служит
для обнаружения и исправления ошибок в заголовке, в качестве
производящего полинома используется G(x)= х3 + х + 1. Один из
битов SNP — представляет собой бит четности. Если CSI=1, то
после поля SNP следует однобайтовое поле указатель, которое ис-
пользуется для определения положения начала следующего сооб-
щения (значения 0-92; старший бит поля указатель зарезервирован
на будущее).
Для сжатой аудио и видео информации скорость передачи
может варьироваться в широких пределах. Ведь многие схемы пре-
дусматривают периодическую отправку полного видеокадра при пос-
ледующей передаче транспортируются лишь отличия последователь-
ных кадров. Уровень адаптации 2-го типа предоставляет вышесто-
ящему уровню возможность синхронизовать передатчик и приемник,
осуществлять обмен с изменяющейся скоростью, оповещение об ошиб-
ках и потерях ячеек. Структура ячейки AAL 2-го типа показана на
рис. 4.3.5.5 (субуровень SAR). Из-за переменной скорости передачи
заполнение ячеек может быть неполным.
Заголовок ►
CSI SN SNP Протокольный блок данных SAR
1 3 4 40
^ИС‘ 3.5.4. Структура PDU подуровня SAP ATM 1~го типа (AALTJ
286
Гпава 4
CSI (Convergence Sublayer Indicator) - индикатор подуровня
конвергенции
SN (Sequence Number) - номер по порядку
SNP (Sequence Number Protection) - защита номера последова-
тельности
Заголовок-#^----------45 байт----------------► ◄—2 байта—►
SN IT Протокольный блок данных SAR LI CRC
◄--------------------48 байт --------------------:—>
Рис. 4.3.5.5. Структура PDU подуровня SAP ATM 2-го типа (AAL2)
IT (Information Type) - тип данных. Служит для указания
начала, продолжения или окончания сообщения
Ы (Length Indicator) - индикатор длины. Указывает число
октетов в поле данных
CRC Контрольная сумма
Поля SN и IT имеют общую длину 1 байт, поля же LI и CRC
вместе занимают 2 байта. Поле данных (PDU) в такой ячейке имеет
длину 45 байт. Более детальной информации о длинах полей стан-
дарт не оговаривает.
Уровень адаптации 3/4 типов предназначен для передачи дан-
ных как в режиме с установлением соединения, так и без него.
Раньше службам С и D (табл. 4.3.5.4) были выделены разные
уровни адаптации, позднее они были объединены. Определены два
типа обмена: сообщение и поток. В первом случае блок данных
передается в одном интерфейсном блоке (IDU). Сервисные блоки
данных могут иметь переменную длину. В режиме поток сервисный
блок данных передается через интерфейс уровня адаптации в одном
или нескольких IDU. В этом режиме может быть реализована услу-
га «внутренний контейнер». Здесь допускается и прерывание пере-
дачи, частично переданный блок теряется. AAL3/4 допускает орга-
низацию нескольких сессий одновременно (например, несколько УД*
ленных LOGIN). Структура протокольного блока данных подуровня
SAR 3/4 типа представлена на рис. 4.3.5.6. Длина поля данНЫ*
(PDU) составляет 44 байта. Заметим, что AAL3/4 имеет два уровня
издержек — 8 байт добавляется для каждого сообщения и 4 изб*1'
точных байта приходятся на каждую ячейку, это достаточно мяо!?
особенно для коротких сообщений.
ST (Segment Type) - тип сегмента. Начало сообщения - Ю
(BOM - Beginning Of Message), продолжение - 00 (COMf
Сети передачи данных. Метод доступа
287
— 2 октета ► >4—2 октета—►
ST SN MID Протокольный блок данных SAR LI CRC
2 4 10 (Число бит в поле) 6 10
ЧО ОаИТ
рис. 4.3.5.6. Структура PDU подуровня SAP ATM 3/4-го типов
Continuation Of Message), завершение сообщения - 01
(ЕОМ - End Of Message), односегментное сообщение - 11;
gN (Sequence Number) - номер по порядку;
MID (Multiplexing Identifier) - идентификатор мультиплексиро-
вания для протокола 4-го уровня (позволяет мультиплек-
сировать до 1024 пользователей для одного соединения).
Поле служит для определения того, какой из активных
сессий принадлежит данная ячейка.
TJ Длина заполнения поля данных.
Здесь при вычислении CRC используется образующий полином
G(x) = х11 + х9 + х5 4- х4 + х +1. Подуровень конвергенции AAL
содержит общую часть подуровня CPCS (Common Path Convergence
Sublayer) и служебную часть подуровня SSCS (Service Specific
Convergence Sublayer). CPCS обеспечивает негарантированную дос-
тавку кадров любой длины в диапазоне 1-65535 байт. Данные пользо-
вателя передаются непосредственно на суб^ровень AAL. Формат
протокольного блока данных подуровня конвергенции AAL 3/4-
типа показан на рис. 4.3.5.7.
CPI В tag BASize Данные CPCS PAD AL Etag Длина
1 1 За голе 2 )ВОК ► 1 -65535 байт CPCS-PDU - 1 1 Оконе1- секц 2 жая ,ия
Рис. 4.3.5.7. Формат блока данных подуровня конвергенции
AAL 3/4-типа
О Рт
1 (Common Part Indicator) - однооктетный индикатор общей
части, используется при интерпретации последующих полей.
£ (Beginning tag) - однооктетная метка начала, в сочетании с
Etag определяет границы протокольного блока данных (PDU).
1Ze (Buffer Allocation size) - емкость буфера, сообщает получате-
Л1° максимальнь1й размер буфера. Поле занимает 2 байта,
заполнитель, обеспечивает кратность поля данных 4 октетам.
288 Глава 41
AL (Alignment) - выравнивание, заполняется нулями.
Etag (End tag) - метка конца (один октет).
Длина Задает протяженность CPCS-PDU.
CPCS-PDU (Common Part Convergence Sublayer - Protocol Data
Unit) - протокольный блок данных общей части подуровня
конвергенции
Тип 3/4 имеет существенную избыточность (4 байта из 48 на
каждый SAR-PDU). По этой причине был введен 5-ый тип. Этот
уровень обеспечивает канал с переменной скоростью обмена (VBR) в
широковещательном режиме при минимальном контроле ошибок
(или вовсе без него). IP-дейтограммы передаются через сети ATM
через адаптационный уровень 5 (RFC-1577). Уровень AAL5 иногда
называют SEAL (Simple and Efficient Adaptation Layer - простой и
эффективный адаптационный уровень). Формат ячейки SAR-PDU
5-го типа показан на рис. 4.3.5.8.
Заголовок -►
РТ
◄---5 байт—►
Протокольный блок данных SAR
53 байта
Рис. 4.3.5.8. Формат ячейки SAR-PDU 5-го типа [AAL5]
Байтов 112 4
Поле данных (1 - 65535 байт) UU Длина CRC
Рис. 4.3.5.8А. Формат сообщения AAL5 субуровня конвергенции
UU (User to User) - поле необходимо для верхних уровней,
чтобы обеспечить мультиплексирование.
Длина Двухоктетное поле длины поля данных (PDU).
CRC 4-октетная контрольная сумма.
Однобайтовое поле, расположенное между полями UU и дл#Я*
зарезервировано для использования в будущем. Так как здесь ДЛ*
переноса информации используется заголовок, работа AAL не явл*
ется независимой от нижележащего уровня, что является нарУ13^
нием эталонной модели. Инкапсулироваться в поля данных ДА**1
могут блоки длиной до 216-1 октетов (65535). Выполнение оПврШ
Сети передачи данных. Метод доступа 289
ций здесь зависит от того, работает ли система в режиме сообщения
или потока. На подуровне конвергенции для передачи протоколь-
ного блока данных используется 4-х байтовая CRC с образующим
ПОЛИНОМОМ G(x) = X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 + х8 +
х7 + х5 + х4 + х2 + х + 1, что обеспечивает высокую надежность
корректности доставки. Положение адаптационного уровня в рам-
ках эталонной модели показано на рис. 4.3.5.9. Следует, впрочем,
заметить, что не вполне ясно, какой уровень занимает сам протокол
ДТМ (транспортный или сетевой?).
Сервис
AAL Субуровень конвергенции Субуровень сегментации и сборки
\ ATM Физический уровень
Рис. 4.3.5.9. Положение уровней ATM в универсальной модели
Верхние уровни управления для ATM базируются на рекоменда-
циях CCITT 1450/1 (Q930/1). В случае использования ATM для
Интернет значение MTU по умолчанию равно 9180 (RFC-1626), так
как фрагментация IP-дейтограмм крайне нежелательна (AAL). Ра-
бота протоколов TCP/IP поверх ATM описана в документах RFC-
1483, -1577, -1626, -1680, -1695, -1754, -1755, -1821, -1926, -1932
(полужирным шрифтом выделены коды документов, являющиеся
стандартами Интернет). Ниже на рис. 4.3.5.10 показано, как пакеты
ATM размещаются в кадрах STM-1 (виртуальный контейнер VC-4).
10 ^Ис- 4.3.5.10. Размещение ATM пакетов в STM-1 кадре
3430 Семенов
290
Гпава 4
В STM-1 для передачи ячеек выделяется полоса пропускания
9x261x8
1 ”125х10-6 Мбит/с. (9 рядов по 261 байту, передаваемые
каждые 125 мксек)
Форматы адресов согласно спецификации интерфейса «пользо-
ватель-сеть» представлены на рис. 4.3.5.11.
V- IDP—►
йог
AFI DCC DFI АА RSVD RD AREA ESI SEL j
IDI HO-DSP
Рис. 4.3.5.11. Формат DCC ATM с числовым кодом страны.
AFI (Authority and Format Identifier) - идентификатор формата
и привилегий.
DCC (Data Country Code) - код данных страны (стандарт МОС
3166).
DFI (DSP Format Identifier) - идентификатор формата DSP.
DSP (Domain Specific Part) - часть, зависящая от домена.
АА (Administrative Authority) - административное субполе.
RSVD (Reserved) - резерв на будущее.
RD (Routing Domain) - область маршрутизации.
AREA Идентификатор зоны.
ESI (End System Identifier) - идентификатор оконечной систе-
мы.
SEL (Selector) - селектор.
IDI (Initial Domain Identifier) - идентификатор исходной облас-
ти.
НО (Higher Order) - старшая часть.
Формат ICD с указателем международного кода отличается от
формата DCC тем, что в нем поле DCC заменено полем международ-
ного кода ICD (International Code Designator). Формат адреса Е.164
NSAP, где идентификатор исходной области является номером Е.164,
представлен на рис. 4.3.5.12. Структура номера (15 десятичных цифр
в кодировке BCD) места назначения отображена на рис. 4.3.5.13.
Важную роль в управлении сетями ATM играет информация
САМ (Operations and Maintenance). Здесь осуществляется тесное
взаимодействие с потоками управления SDH (F1-F5).
F1 - поток данных ОАМ уровня регенерационной секции SDH-
F2 — поток данных ОАМ цифровой мультиплексорной секции SDH-
F3 — поток данных ОАМ уровня пути обмена SDH.
Сети передачи данных. Метод доступа
291
F4 — поток данных ОАМ виртуального пути ATM.
F5 — поток данных ОАМ виртуального канала ATM.
DSP
IDP-
API
Е.164 RSVD RD AREA ESI SEL
IDI
Рис. 4.3.5.12. Формат адреса Е.164 NSAP
(назначения полей идентично показанному для рис. 4.3.5.11].
Междунаррдный номер
Заполнение Код страны Национальный код места назначения Абонентский номер
Национальный номер
Рис. 4.3.5.13. Структура номеров адресатов
Код страны (СС -Country Code) занимает от одной до трех цифр
(из 15).
Маршрутизация в ATM отличается от аналогичных процессов в
сетях с коммутацией пакетов. Сети ATM в основном ориентирова-
ны на соединение. Ячейки транспортируются по уже выбранному
маршруту через коммутаторы ATM в соответствии со значениями
идентификаторов виртуального пути и виртуального канала. Вы-
числение маршрута осуществляется на специальном сервере. Пото-
ки информации F4 или F5 принимаются и обрабатываются устрой-
ствами, которые формируют виртуальные пути или каналы. Формат
информационного поля ячейки ОАМ показан на рис. 4.3.5.14. Поток
информации ОАМ уровня F4 виртуального пути для идентифика-
ции потока точка-точка использует идентификатор виртуального
канала VCI=4, а для сегментных потоков VCI=3.
4о сайт ►
Тип ОАМ Тип выполняемой функции Поле спец, функций Резерв CRC
4 бита ◄— 4 бита ► ◄ 45 байт —к 6 бит ◄ 10 бит ►
Рис. 4.3.5.14. Формат ячейки CAM F4
^°ТОК ячеек ОАМ F5 уровня виртуального канала каких-либо
ОДальных идентификаторов виртуальных путей не использует.
Ю»
292
Гпава 4 *
В заголовках ячеек потока ОАМ F5 типа точка-точка в поле типа
данных (РТ) записывается код 100, а для сегментных потоков вир-
туальных каналов РТ=101. Значения кодов полей тип ОАМ и
выполняемой функции приведены в таблице 4.3.5.5. Для решения
проблем выявления и локализации отказов в сети ATM использу-
ются ячейки AIS (Alarm Indication Signal - аварийный сигнал),
RDI/FERF (Remote Defect Indication/Far End Reporting Failure -
указатель отказа на удаленном конце), контроля непрерывности
(Continuity check) и проверки с применением обратной связи
(Loopback). Для ячеек AIS и RDI поля тип отказа имеет 8 байт
(по умолчанию во все октеты записывается 0x6А), а для указателя
места отказа выделено 9 байт. Полезная часть поля данных в этих
ячейках равна 45 байтам, из них 28 зарезервировано на будущее.
Таблица 4.3.5.5. Коды полей тип ОАМ и тип выполняемой функции
Код поля тип ОАМ Назначение Код поля тип выполняемой функции Назначение
0001 Обнаружение и определение места отказов (Fault Management) 0000 Указание отказа (AIS)
0001 Указание на удаленный дефект (RDI/FERF)
0100 Проверка непрерывности (Continuity check)
1000 Обратная связь (Loopback)
0010 Контроль рабочих характеристик 0000 Прямой мониторинг (Forward monitoring)
0001 Сообщение о предыстории (Backward reporting)
0010 Мониторирование и предоставление результатов (Monitoring and Reporting)
1000 Активизация и завершение процессов ОАМ 0000 Мониторинг рабочих характеристик (Performance Monitoring)
0001 Проверка непрерывности (Continuity check) _
Контроль рабочих характеристик сети ATM производится беа
нарушения соединений и без снижения качества обслуживания. Для
запуска и остановки процесса измерения служат ячейки тип*
Activation/deactivation. В ячейке ОАМ для этих целей в поле дан*
ных выделено 45 байт. Формат субполей поля данных представлен А
на рис. 4.3.5.15.
Сети nt зредачи дат 6 ных. Мето 2 д доступа 8 4 4 Амт fc. 293
4ZXO опт
Идентифи- катор сообщения Направ- ление действия Корреля- ционная метка Блок РМ Размер А-В Блок РМ Размер В-А Неиспользуемые октеты
Рис. 4.3.5.15. Формат субполей поля данных
ОАМ Activation/deactivation
Субполе неиспользуемые октеты заполняется байтами ОхбА, а
субполя блок РМ — кодами 0000. Значения кодов поля идентифи-
катор сообщения приведены в таблице 4.3.5.6.
В субполе направление действия заносится код 10 при направ-
лении от А к В и 01 при противоположном направлении. В поле
размер записывается код 1000 при длине 1024 ячеек, 0100 — при
512, 0010 — при 256 и 0001 - при 128. Размеры блоков для на-
правлений А->В и В ->А могут быть и неравными. Мониторинг
рабочих параметров может выполняться для А->В, В ->А или для
обоих направлений одновременно.
Формат ячеек ОАМ типа измерение рабочих характеристик
представлен на рис. 4.3.5.16.
<4-----Мониторинг--------->>
Порядковый
номер
мониторинга
Общее число
ячеек
пользователя
BIP-16
Временная
метка
Не исполь'
зуется
I------Сообщение ------->
Результаты Счет
анализа потерянных
ошибок и лишних ячеек
1
1 2 байта
Рис. 4.3.5.16. Формат ячеек ОАМ типа измерение рабочих
характеристик
В субполя BIP-16 (Bit Interleaved Parity) и счет потерянных
ячеек в отсутствии прямого мониторинга по умолчанию заносится
код ОхбА, аналогичный код записывается в субполя число ячеек
пользователя и результаты анализа в отсутствие обратного монито-
ринга. В неиспользуемое поле записываются 1 во все биты, если не
использована временная метка. Поле порядковый номер монито-
ринга (MSN - Monitoring Sequence Number) содержит номер ячейки
AM типа РМ по модулю 256. Поле общее число ячеек пользова-
теля (TUC - Total User Cell) записывается число пользовательских
ЯЧеек, отправленных после последней ячейки ОАМ типа РМ.
О а 5^ин Физический отказ может сгенерировать большое число ячеек
^М. Для блокировки такой возможности введено ограничение на
°Д генерации таких ячеек (< нескольких секунд). Операции
294
Гпава 4
проверки тракта, выполняемые с помощью ячеек ОАМ типа Loopback,
позволяют выявить место возникновения неисправностей. Формат
поля специальных функций ячейки ОАМ типа Loopback отображен
на рис. 4.3.5.17 (см. также рис. 4.3.5.14).
Индикатор шлейфа Корреляционная метка Идентификатор места шлейфа Идентификатор источника Не используется 0 или 1
8 бит 8 бит 12 байт 12 байт 135 бит 1 бит
Рис. 4.3.5.17. Формат ячейки ОАМ типа Loopback
Поле неиспользуемое содержит во всех октетах по умолчанию
код ОхбА. Поле индикатор шлейфа содержит 1 при посылке отпра>
вителем (остальные семь бит равны нулю), единица заменяется ну-
лем в момент приема. При получении ячейки с индикатором шлей-
фа, равным нулю, она уничтожается. Поле корреляционная метка
используется отправителем для идентификации отклика. Поле иден-
тификатор места шлейфа определяет место, откуда ячейка должна
быть послана назад. Если поле содержит все единицы, таким мес-
том является адресат. Поле идентификатор источника служит для
распознавания ячейки и ее уничтожения при возвращении.
Предоставление услуг без установления соединения соответству-
ет уровню выше чем ATM и требует соединения каждого клиента с
соответствующйм сервером, решающим данную задачу. Большин-
ство локальных и региональных сетей ATM реализуют именно та-
кой режим. Для передачи данных без установления соединения ис-
пользуется протокол доступа CLNAP (Connectionless Network Access
Protocol), интерфейс CLAI (Connectionless Access Interface) и сетевой
протокол CLNIP (Connectionless Network Interface Protocol). Размер
поля данных для CLNAP не является постоянным и составляет
9188 октетов, что подразумевает фрагментацию. Эти протоколы ра-
ботают выше подуровня конвергенции. Соответствующая длина для
CLNIP SDU равна 9236 октетам. Формат блока данных CLNIP
показан на рис. 4.3.5.18.
Проблему фрагментации и инкапсуляции этих длинных пакетов
в ATM ячейки берет на себя коммутатор доступа. Схема вложения
и фрагментации для пакетов CLNAP отображена на рис. 4.3.5.19»
Из рисунка видно, что на подуровне SAR происходит деление
пакета на части и укладка полученных сегментов в поля данных
ячеек (по 48 байт).
СеТИ передачи данных. Метод доступа
295
Рис. 4.3.5.18. Формат структуры данных протокола CLNIP
PI (Protocol Identifier) - идентификатор протокола.
PADLE (Padding Length) - длина заполнения.
QOS (Quality of Service) - качество обслуживания
С (CRC indication bit) - индикатор числа бит в контрольной
сумме CRC.
HEL (Header Extension Length) - длина расширения заголовка.
4.3.5.19. Схема вложения и фрагментации для пакетов CLNAP
АН
SAR
(Alignment Header; 4 октета) - поле выравнивания.
(Segmentation and Reassemble) - сегментация и сборка.
296 Глава 4 .
CPCS (Common Part Convergence Sublayer) — общая часть по-
дуровня конвергенции.
Для использования одного и того же виртуального канала мно-
гими протоколами служит LLC-инкапсуляция (Logical Link Control).
LLC-заголовок укладывается в поле данных перед PDU и содержит
в себе информацию, необходимую для того, чтобы корректно обрабо-
тать AAL5 CPCS-PDU. Обычно такой заголовок имеет формат IEEE
802.2, за которым может следовать SNAP-заголовок IEEE 802.1а.
LLC-заголовок, содержащий код OxFE-FE-ОЗ, говорит о том, что да-
лее следует маршрутизируемый PDU длиной 216 — 4 октетов. Одно-
октетный код NLPID идентифицирует сетевой протокол. Значения
кодов NLPID представлены в таблице 4.3.5.7.
Таблица 4.3.5.7. Значения кодов NLPID
Код NLPID Назначение
0x00 Нулевой сетевой уровень (в ATM не используется)
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
ОхСС Интернет (IP не является протоколом ISO)
Формат PDU для маршрутизируемых данных при использова-
нии протоколов, не принадлежащих ISO, представлен на рис. 4.3.5.20
(случай 1Р-дейтограммы).
LLC 0xAA-AA-03 OUI 0x00-00-00 EtherType 0x08-00 IP-PDU
Рис. 4.3.5.20. Формат IP PDU при транспортировке
с использованием AAL5 ATM
Сеги передачи данных. Метод доступа
297
4.3. В. Синхронные каналы SDH/SONET
Мультиплексирование потоков информации при формировании
мощных региональных и межрегиональных каналов имеет два реше-
ния. Одно базируется на синхронном мультиплексировании и носит
название синхронная цифровая иерархия (SDH, см. Н.Н.Слепов, Син-
хронные цифровые сети SDH. ЭКО-ТРЕНДЗ, Москва, 1998), другое
использует простой асинхронный пакетный обмен и носит название
асинхронный режим передачи (ATM, см. предыдущую главу).
Стандарт SDH (Synchronous Digital Hierarchy) разработан в Ев-
ропе, (предназначен для замены иерархии асинхронных линий Е-1/
Е-3) используется в настоящее время многими сетями и представ-
ляет собой модификацию американского стандарта на передачу дан-
ных по оптическим каналам связи SONET (Synchronous Optical
Network). Несмотря на свое название SONET не ограничивается
исключительно оптическими каналами. Спецификация определяет
требования для оптического одно- и мультимодового волокна, а также
для 75-омного коаксиального кабеля CATV 75. Пропускная спо-
собность SONET начинается с 51,84 Мбит/с STS-1 (Synchronous
Transport Signal-1). Более высокие скорости передачи информации
в SONET кратны этому значению. Стандартизованы следующие ско-
рости передачи, которые кратны скорости 64 Кбит/с.
STS-1 51,840 STS-18 933,120
STS-3 155,520 STS-24 1244,160
STS-9 466,560 STS-36 1866,240
STS-12 622,080 STS-48 2488,320
Соответствие каналов SONET и SDH приведено ниже[)ДГ. Simpson
RFC-1619 «РРР over SONET/SDH»] (и тот и другой могут исполь-
зоваться для организации связей по схеме РРР):
SONET
STS-3c
STS-12с
STS-48C
SDH
STM-1
STM-4
STM-16
SONET (стандарт ANSI, предназначенный для замены NADH —
^orth American Digital Hierarchy) использует улучшенную PDH —
(Flesiochronous Digital Hierarchy — plesios — близкий (греч.)) схе-
му мультиплексирования каналов. В плезиохронной (почти синх-
ронной) иерархии используется мультиплексирование с чередовани-
298
Гпава 4 ,
ем бит, а не байт. Мультиплексор формирует из N входных потоков
один выходной (сети, где разные часы сфазированы с разными стан-
дартами, но все они привязаны к одной базовой частоте называются
плезиохронными). Так как скорости разных каналов могут не со-
впадать и нет структур, которые могли бы определить позиции би-
тов для каждого из каналов, используется побитовая синхрониза-
ция. Здесь мультиплексор сам выравнивает скорости входных по-
токов путем введения (или изъятия) соответствующего числа бит.
Информация о введенных и изъятых битах передается по служеб-
ным каналам. Помимо синхронизации на уровне мультиплексора
происходит и формирование кадров и мультикадров. Так для кана-
ла Т2 (6312кбит/с) длина кадра равна 789 бит при частоте кадров
8 кГц. Мультикадр содержит 12 кадров. Помимо европейской и
американской иерархии каналов существует также японская. Каж-
дая из этих иерархий имеет несколько уровней. Сравнение этих
иерархий представлено в таблице 4.3.6.1.
Таблица 4.3.6.1.
Сравнение европейской и американской иерархии каналов
Уровень иерархии Скорости передачи для иерархий
Американская 1544 Кбит/с Европейская 2048 Кбит/с Японская 1544 Кбит/с
0 64 (DS0) 64 64
1 1544 (DS1) 2048 (Е1) 1544 (DS1)
2 6312 (DS2) 8448 (Е2) 6312 (DS2)
3 44736 (DS3) 34368 (ЕЗ) 32064 (DSJ3)
4 274176 (Не входит в рекомендации МСЭ-Т) 139264 (Е4) 97728 (DSJ4)
Но добавление выравнивающих бит в PDH делает затруднитель-
ным идентификацию и вывод потоков 64 Кбит/с или 2 Мбит/с, за-
мешанных в потоке 140 Мбит/с, без полного демультиплексирова-
ния и удаления выравнивающих бит. Если для цифровой телефо-
нии PDH вполне эффективна, то для передачи данных она оказалась ?
недостаточно гибкой. Именно это обстоятельство определило пре-
имущество систем SONET/SDH. Эти виды иерархических систем
позволяют оперировать потоками без необходимости сборки/раз-
борки. Структура кадров позволяет выполнять не только маршру-
тизацию, но и осуществлять управление сетями любой топологии.
Здесь использован чисто синхронный принцип передачи и побайто-
вое, а не побитовое чередование при мультиплексировании. Первич-
ной скоростью SONET выбрана 50,688 Мбит/с (ОС1). Число уров-
Сети передачи данных. Метод доступа
299
ней иерархии значительно расширено (до 48). Кратность уровней
иерархии равна номеру уровня.
CCITT выработал следующие рекомендации на эту тему: G.707,
G.708 и G.709. CCITT разработал рекомендации для высокоскорос-
тных каналов Н:
но 384 Кбит/с=4*64 Кбит/с. 3*Н0=1,544 Мбит/с
Н1 НИ 1536 Кбит/с Н12 1920 Кбит/с
Н4 Н21 Н22 -135 Мбит/с -34 Мбит/с -55 Мбит/с.
На нижних уровнях SDH и SONET в некоторых деталях разли-
чаются. Внедрение стандарта SONET ликвидировало многие недо-
статки каналов Т-1 (ограничения на размер максимальной полез-
ной нагрузки, простота стыковки скоростных каналов связи). SONET
хорошо согласуется с ATM и FDDI, что создает фундаментальный
базис для широкополосных сетей ISDN (В-ISDN). Следует учиты-
вать, что SONET сохраняет совместимость с уже существующими
каналами, убирая лишь некоторые присущие им недостатки. Од-
ним из базовых каналов сегодня является Т-1 (1544 Кбит/с для
США). Он содержит в себе 24 субканалов DS-0 (Digital Signal at
zero level, 64 Кбит/с, США). Мультиплексирование 24 каналов DS-0
по времени формирует канал DS-1 (24 канала*64 Кбит/с)+8 Кбит/с
=1544 Кбит/с, последнее слагаемое связано с заголовками инфор-
мационных блоков). Этой величине соответствует в Европе 2048 Кбит/с
(канал Е-1 = 30*DS0). Два канала Т-1 образуют канал Т-1С, четы-
ре канала Т-1 формируют канал Т-2, а семь Т-2 (28 Т-1) образуют
Т-3. Для оптических систем связи в качестве базового принят ка-
нал ОС-1, равный по пропускной способности Т-3. А кадр STS-1
выбран в качестве основного в системе SONET. Кадр STS-1 имеет 9
строк и 90 столбцов (810 байт). Кадры передаются с частотой 8 кГц,
что дает для канала STS-1 51840 Кбит/с = 8000Гц*810байт*8бит.
Эта цифра характеризует физическую скорость обмена, включающую
в себя передачу служебной информации (заголовков), эффективная
ннформационная пропускная способность равна 50112 Кбит/с. Быс-
тродействие каналов более высокого уровня SONET получается умно-
жением пропускной способности STS-1 (51,84 Мбит/с) на целое чис-
ло. Так пропускная способность ОС-3 будет равна 155,52 Мбит/с, а
ОС-24 — 1244,16 Мбит/с и т.д. Целью создателей SONET было
пРямая стыковка оптических каналов различных сервис-провайде-
300
Гпава 4
ров (вспомним, что непосредственное соединение каналов Т-1 и Е-1
не возможно). SDH допускает сцепление нескольких контейнеров,
(в том числе и разных размеров), если в один контейнер данные не
помещаются. Допускается объединение нескольких контейнеров
равного размера в один большой. Хотя относительный размер заго-
ловка виртуального контейнера невелик (-3,33%), его объем доста-
точен для передачи больший объемов служебной информации (до ,
5,184 Мбит/с).
В SONET предусмотрено четыре варианта соединений: точка-
точка, линейная цепочка (add-drop), простое кольцо и сцепленное
кольцо (interlocking ring). Линейные варианты используются для
ответвлений от основного кольца сети. Наиболее распространенная
топология — самовосстанавливающееся кольцо (см. также FDDI),
Такое кольцо состоит из ряда узлов, которые связаны между собой
двухсторонними линиями связи, образующими кольцо и обеспечи-
вающими передачу сообщений по и против часовой стрелки. Спо- .
собность сетей SONET к самовосстановлению определяется не толь-
ко топологией, но и средствами управления и контроля состояния.
При повреждении трафик перенаправляется в обход, локально это
приводит к возрастанию информационного потока, по этой причине
для самовосстановления сеть должна иметь резерв пропускной спо-
собности (как минимум двойной). Но, проектируя сеть, нужно избе-
гать схем, при которых основной и резервный маршрут проходят
через одну и ту же точку, так как они могут быть, если не повезет, >
повреждены одновременно. Резервные пути могут использоваться
для низкоприоритетных обменов, которые могут быть заблокирова-
ны при самовосстановлении. Сети SONET (и SDH) имеют 4 архи-
тектурных уровня:
• Фотонный (photonic) — нижний уровень иерархии. Этот уро-
вень определяет стандарты на форму и преобразование оптических
сигналов, на электронно-оптические связи.
• Секционный (section) — предназначен для управление переда*
чей STS-кадров (SONET) между терминалами и повторителями. В
его функции входит контроль ошибок.
• Линейный (line) — служит для синхронизации и мультиплек-
сирования, осуществляет связь между отдельными узлами сети и
терминальным оборудованием, например линейными мультиплек-
сорами, выполняет некоторые функции управления сетью.
• Маршрутный (path) — описывает реальные сетевые услуги
(Т-1 или Т-3), предоставляемые пользователю на участке от одного
терминального оборудования до другого.
Сети передачи данных. Метод доступа
301
Существующие PDH-сети мультиплексируют каналы, используя
каскадную схему, показанную на рис. 4.3.6.1.
64 кбит/с 1544/2048 кбит/с 6312/8448 кбит/с 44736/34368 кбит/с 139264
Рис. 4.3.6.1. PDH-мультиплесирование
SDH-иерархия распространяется до 2500 Мбит/с и может быть
расширена вплоть до 13 Гбит/с (ограничение оптического кабеля).
SDH предоставляет существенно улучшенную схему мультиплекси-
рования каналов для быстродействующих интерфейсов с полосой
150 Мбит/с и выше:
• обеспечивается единый стандарт для мультиплексирования и
межсетевого соединения;
• прямой доступ к низкоскоростным каналам без необходимо-
сти полного демультиплексирования сигнала;
• простая схема управления сетью;
• возможность использования новых протоколов, по мере их
появления (напр. ATM)
При передаче по сети SDH информация вкладывается в спе-
циальные структуры, называемые виртуальными контейнерами (VC).
Эти контейнеры состоят из двух частей:
1. Собственно контейнер (С), где лежит передаваемая информация;
2. Заголовок (Path Overhead — РОН), который содержит вспомо-
гательную информацию о канале, управляющую информацию, свя-
занную с маршрутом передачи.
Описано несколько типов виртуальных контейнеров для исполь-
зования в различных каналах.
В схеме мультиплексирования применены следующие обозначения:
С-п Контейнер уровня п (п=1,2,3,4);
VC-n Виртуальный контейнер уровня п (п=1,2,3,4);
TU-n Трибные блоки уровня п (п=1,2,3);
TUG-n Группа трибных блоков п (п=2,3);
AU-n Административные блоки уровня п (п=3,4);
AUG Группа административных блоков (стандарт G.709).
302
Гпава 4
Таблица 4.3.6.2. Виды виртуальных контейнеров
Виртуальный контейнер Поддерживаемые услуги
VC-11 1.544 Мбит/с североамериканские каналы
VC-12 2.048 Мбит/с европейские каналы
VC-2 6.312 Мбит/с каналы (используются редко). VC-2 могут также объединяться для достижения больших скоростей
VC-3 34.368 Мбит/с и 44.736 Мбит/с каналы
VC-4 139.264 Мбит/с каналы и другие высокоскоростные услуги
Контейнеры С-n используются для инкапсуляции сигналов
каналов доступа или трибов, при этом уровни п соответствуют уров-
ням PDH. Контейнер С-1 может нести в себе контейнер С-11, кото-
рый содержит триб Т1=1,54 Мбит/с, и контейнер С-12, несущий
триб Е1=2 Мбит/с. Контейнер С-2 разбивается на контейнер С-21,
содержащий триб Т2=6 Мбит/с и контейнер С-22 с трибом Е2==8М-
бит/с. Контейнер С-3 разбивается на контейнер С-31 (триб Е3=34
Мбит/с) и контейнер С-32 с трибом ТЗ=45Мбит/с. С-4 не имеет
подуровней и несет в себе триб Е4=140 Мбит/с.
Виртуальный контейнер VC-3 делится на два виртуальных кон-
тейнера VC-31 и VC-32, полезная нагрузка VC-3 образуется из одно-
го контейнера С-3 или с помощью мультиплексирования несколь-
ких групп TUG-2.
Виртуальный контейнер VC-4 несет в себе полезную нагрузку в ?
виде контейнера С-4 Hjpi нескольких групп TUG-2 и TUG-3.
Административный блок AU-3 разбивается на подуровни AU-
31 и AU-32, поле данных которых формируется из виртуального
контейнера VC-31 или VC-32 соответственно.
Административный блок AU-4 не имеет подуровней, его поле
данных формируется из виртуального контейнера VC-4 или комби- ?
наций других блоков: 4*VC-31 или 3*VC-32 или 21*TUG-21 илй
16*TUG-22.
На рис. 4.3.6.2 отображена иерархия мультиплексирования по-
токов информации в SDH. На рисунке не показана возможность,,
вложения контейнера VC-11 в TU-12. SDH-сигнал состоит из STM-
1 кадров (Synchronous Transport Module уровень 1; рис. 4.3.6.3).
Этот сигнал обеспечивает интерфейс для обмена со скоростью 155.52
I Мбит/с, что является базовым блоком, из которого строятся интер-
фейсы с более высоким быстродействием. Для более высоких ско-
ростей может быть использовано N STM-1 кадров с перекрытием
байтов (byte interleave, см. рис. 4.3.6.6). Согласно требованиям CCITT
N может принимать значения 1, 4 и 16, предоставляя интерфейс для
Сети передачи данных. Метод доступа
303
Рис. 4.3.6.2 Иерархия мультиплексирования SDH
каналов с'полосой 155.52, 622.08 и 2488 Мбит/с. Каждый STM-1
кадр содержит 2430 байтов, передаваемых каждые 125 мксек. Для
удобства такой кадр можно отобразить в виде блока, содержащего 9
строк по 270 байт.
Первые 9 колонок кадра, исключая строку 4, используются в
качестве заголовка. Регенераторная часть служит для передачи сиг-
Рис. 4.3.6.3 Структура кадра STM-1
304
Гпава 4
нала между линейным оборудованием и несет в себе флаги разгра.
ничения кадров, средства для обнаружения ошибок и управления
телекоммуникационным каналом.
Мультиплексорный заголовок используется мультиплексорами,
обеспечивая детектирование ошибок и информационный канал с
пропускной способностью 576 Кбит/с. AU (Administrative Units) —.
предлагает механизм эффективной транспортировки информации
STM-1. Административный блок перераспределяет информацию внут-
ри виртуального контейнера. Начало виртуального контейнера ин-
дицируется указателем AU, в котором содержится номер байта, с
которого начинается контейнер. Таким образом, начала STM-1 и
VC не обязательно совпадают.
9 колонок
261 колонка
9 строк
9 строк
270
0 мксек
STM-ln
125мксек
STM-ln+1
250мксек
Рис. 4.3.6.4 Вложение виртуального контейнера VC-4 в STM-1
AU-указатель состоит из двух частей: смещение в байтах до
начала следующего контейнера и контрольное поле, которое обычна
заполнено бессмысленной информацией (аналогии с головами пред-
ставителей российской администрации совершенно неуместны). Если
частота следования VC меньше частоты STM-1 кадров, в контрольное
поле может заноситься информация из VC. Иногда для удобства
(чтобы выровнять фазы VC и STM-1) VC задерживается за счет
заполнения «пустой» информацией области за AU-указателем. Су-
ществуют и другие форматы для пересылаемой информации AU-3 и
AU-4. AU-4 транспортирует один VC-4, который занимает весь по-
лезный объем STM-1 кадра. Относительное положение VC-4 в STM-
1 произвольно (см. рис. 4.3.6.4). AU-4-указатель находится в этом
случае в 4-ой строке.
VC-4 (см. рис. 4.3.6.5) позволяет реализовать каналы с быстродей-
ствием 139.264 Кбит/с. Более высокая скорость обмена может быть
достигнута путем соединения нескольких VC-4 вместе. Для болев
низких скоростей (около 50 Мбит/с) предлагается структура AU-3-
Сети передачи данных. Метод доступа
305
Рис. 4.3.6.5. VC-4, плавающий в AU-4
Три VC-3 помещаются в один кадр STM-1, каждый со своим
AU-указателем. Когда три VC-3 мультиплексируются в один STM-1,
их байты чередуются, то есть за байтом первого VC-3 следует байт
второго VC-3, а затем третьего. Чередование байтов (byte interleaving)
используется для минимизации задержек при буферизации. Каж-
дый VC-3 имеет свой AU-указатель, что позволяет им произвольно
размещаться в пределах кадра STM-1.
скоростям
(Tributary Uni
Рис. 4.3.6.6. Три VC-3 в STM-1 кадре
Каждому VC-3 при занесении в STM-1 добавляется 2 колонки
заполнителей, которые размещаются между 29 и 30, а также между
* и 58-ой колонками контейнера VC-3. VC, соответствующие низ-
, сначала вкладываются в структуры, называемые TU
ts — вложенные блоки), и лишь затем в более круп-
306
Гпава 4
ные — VC-3 или VC-4. TU-указатели позволяют VC низкого уровня
размещаться независимо друг от друга и от VC высокого уровня.
VC-4 может нести в себе три VC-3 непосредственно, используя
TU-3 структуры, аналогичные AU-3. Однако транспортировка VC-1
и VC-2 внутри VC-3 несколько сложнее. Необходим дополнитель-
ный шаг для облегчения процесса мультиплексирования VC-1 и VC-
2 в структуры более высокого уровня (см. рис. 4.3.6.7).
VC высокого порядка
STM-1 кадр
Заголовок
регенераторной
секции
AU-указатели
Заголовок
мультиплексорной
секции
TU-указатели
VC низкого порядка
Рис. 4.3.6.7. Транспортировка VC при низких скоростях
с использованием TU-структур
Так как VC-1 и VC-2 оформляются как TU, они вкладываются в
TUG (Tributary Unit Group). TUG-2 имеет 9 рядов и 12 колонок,
куда укладывается 4 VC-11, 3 VC-12 или один VC-2. Каждый TUG-
2 может содержать VC только одного типа. Но TUG-2, содержащие
различные VC, могут быть перемешаны произвольным образом.
Фиксированный размер TUG-2 ликвидирует различия между разме-
рами VC-1 и VC-2, упрощая мультиплексирование виртуальных кон-
тейнеров различных типов и их размещение в контейнерах более
высокого уровня. Данная схема мультиплексирования требует бо-
лее простого и дешевого оборудования для осуществления мульти-
плексирования, чем PDH.
Если в SDH управление осуществляется на скоростях в несколько
килобайт, в ATM оно реализуется на скорости канала, что влечет за
собой определенные издержки.
Для управления SDH/SONET используется протокол SNMP (см.
RFC-1595, «Definitions of Managed Objects for the SONET/SDH
Interface Туре») и база данных MIB.
Архитектура сети, базирующейся на SDH, может иметь кольце-
вую структуру или схему точка-точка.
Сети передачи данных. Метод доступа
307
4.3.7. Модемы
Само название этого прибора происходит от имеющихся в нем
модулятора и демодулятора. Современный модем можно отнести к
числу устройств с наибольшим числом современных технологий на
кубический сантиметр. Разнообразие модемов огромно. Они разли-
чаются по конструкции, по используемым протоколам, по характе-
ру интерфейсов и т.д. Основное назначение модема оптимальное
преобразование цифрового сигнала в аналоговый для передачи его
по каналу связи и, соответственно, обратное преобразование на при-
нимающей стороне. Под «оптимальным преобразованием» понима-
ется такое, которое обеспечивает надежность связи, улучшает отно-
шение сигнал шум и как следствие пропускную способность кана-
ла. Это преобразование необходимо для обеспечения улучшения
отношения сигнал-шум. В качестве канала передачи данных может
быть использована городская телефонная сеть, выделенная линия
или радио-канал. Схема взаимодействия модемов показана на рис.
4.3.7.1.
В качестве последовательного интерфейса может выступать RS-
232, V.35, G.703 и т.д.. Все модемы содержат в себе управляющий
микропроцессор, постоянную память (ROM), куда записано фирмен-
ное программное обеспечение и интерпретатор команд, энергонеза-
висимую память (NVRAM — Non-Volatile RAM), которая хранит
конфигурационные профайлы модема, телефонные номера и т.д., бу-
фер ввода/вывода (128-256 байт), сигнальный процессор (DSP), вклю-
чающий в себя модулятор и демодулятор, интерфейс для связи с
ЭВМ (RS-232) и оперативную память.
Первоначально модемы использовались для связи через тради-
ционные коммутируемые телефонные линии. Так как такие линии
содержат только два провода, а информационный обмен должен про-
исходить в обоих направлениях одновременно, возникает проблема
М1
: Канал
Сигнальный
процессор
ЧУправляющий!^___
процессор J tx
3 t g
( ROM )( NVRAM ) § £
М2 ||
£
^ис. 4.3.7.1. Схема соединения двух модемов {М1 и М2]
через канал
308
Гпава 4
отделения передаваемого сигнала от приходящего из вне (подавле-
ние эхо; см. раздел 2.1). Для выделенных четырехпроводных ли-
ний эта проблема значительно упрощается, здесь прием и передача
осуществляется по разным скрученным парам и эхо возникает
лишь из-за перекрестных наводок (NEXT). Модемы подключаются
к последовательным интерфейсам ЭВМ (COM-порт, RS-232), иногда
для подключения модема используется специальная плата расщц.
рения, которая имеет дополнительные буферы и помогает достичь
большего сжатия информации, существуют модемы, подключаемые
и к параллельному порту ЭВМ. Модемы (микромодемы) могут рабо-
тать не только через общедоступную телефонную сеть, они могут
найти применение при соединении терминалов или ЭВМ в пределах
организации, если расстояние между ними исчисляются сотнями
метров (а иногда и километрами). В этом случае они помогают
повысить надежность связи и исключить влияние разностей потен-
циалов между земляными шинами соединяемого оборудования.
Микромодемы не требуют подключения к сети переменного тока,
так как получают питание через разъем последовательного интер-
фейса (RS-232).
Все протоколы модемов утверждаются международным телеком-
муникационным союзом (ITU), ранее за это был ответственен Кон-
сультативный комитет CCITT. Асинхронные модемы поддерживают
определенный набор команд, который был впервые применен фир-
мой Hayes в модеме Smartmodem 1200. Модемы, придерживающие-
ся этого стандарта, называются Hayes-совместимыми. Совместимость
предполагает идентичность функций первых 28 управляющих реги-
стров модема (всего модем может иметь более сотни регистров);
Почти все внутренние команды начинаются с символов AT (Attention)
и имеют по три символа. По этой причине их иногда называют АТ-
командами. Hayes-совместимость гарантирует, что данный модем
будет работать со стандартными терминальными программами. Ре-
ально набор команд для модемов разных производителей варьиру-
ется в широких пределах. Для синхронных модемов набор команд^
регламентируется стандартом V.25bis. Ниже (таблица 4.3.7.1) при-
водится перечень стандартных модемных протоколов и стандартов.г
Начиная с модемов V.32bis, стала использоваться динамическая
регулировка скорости в ходе телекоммуникационной сессии в ?
висимости от состояния линии связи. Качество линии отслежива-
ется по отношению сигнал/шум или по проценту блоков, передан-
ных с ошибкой за определенный период времени.
Важным свойством модемов является возможность коррекции
ошибок и сжатия информации. Ошибки корректируются путем по-
Сети передачи данных. Метод доступа
309
Таблица 4.3.7.1. Основные протоколы модемов
— Название Тип модуляции Назначение протокола
FSK Дуплексный модем на 300 бит/с для телефонных сетей общего назначения, используется факс- аппаратами и факс-модемами
"V22 DPSK Дуплексной модем для работы при скоростях 600/1200бит/с
"V72bis QAM Дуплексной модем для работы при скоростях 1200/2400бит/с
V?23 FSK Асинхронный модем на частоту 600/1200бит/с (сети Videotex), несовместим с V.21, V.22 и V.22bis
V.24 Стандарт на схемы сочленения DTE и DCE
V/26 Модем для работы на выделенную линию на частотах 2400/1200бит/с
V.27 Модем для работы на частотах 4800бод/с
V.27bis Модем для работы на выделенную линию на частотах 2400/4800бит/с
V.27ter DPSK Модем с набором телефонного номера на частоту 2400/4800бит/с (FAX)
V.29 QAM Модем на частоту 9600бит/с для 4-проводных выделенных линий (FAX)
V.32 QAM, тем Семейство 2-проводных модемов, работающих на частотах до 9600бит/с
V.32bis тем Модем, работающий на выделенную линию для частот 7200, 12000 и 14400бит/с
V.33 тем Модем на частоту 14.4кбит/с для выделенных линий
V.34 Модем на частоту 28.8кбит/с, использован новый протокол установления связи
V.34bis Модем на частоту 32 кбит/с
V.35 Модем, работающий на выделенную линию с частотами до 9600бит/с
_ _V.42bis Стандарт для сжатия данных в модемах (4:1)
вторной пересылки ошибочных блоков (ARQ — Automatic Repeat
reQuest). Ошибки контролируются с использованием CRC (Cyclic
Redundancy Check). Этим целям отвечает стандарт V.42, принятый
еще в 1988 году, он включает в себя протокол LAPM (Link Access
r°cedure for Modems) и один из протоколов MNP (Microcom
Networking Protocol). В V.42 применен алгоритм сжатия информа-
ции Lempel-Ziv. При установлении связи между модемами опреде-
ляется, какой из протоколов коррекции и сжатия они оба поддер-
310
Гпава 4
живают. Если это V.42, то они сначала пытаются работать с ис-
пользованием протокола LAPM. При неудаче (один из модемов це
поддерживает V.42) используется протокол MNP. Перечисленные
ниже алгоритмы коррекции ошибок и сжатия информации работа-
ют только для асинхронных модемов. Для синхронных модемов
известен алгоритм сжатия SDS (Synchronous Data Compression)
фирмы Motorola (коэффициент упаковки ~3.5, что для модемов V.34
может довести скорость обмена до 100кбит/с).
Ниже приведена таблица основных протоколов детектирования
ошибок и сжатия информации, все протоколы MNP совместимы
снизу вверх. При установлении связи между модемами использует-
ся наивысший протокол, поддерживаемый с обеих сторон канала.
Таблица 4.3.7.2. Протоколы MNP
MNP-1 Асинхронная полудуплексная передача данных с побайтовой организацией. Эффективность 70% (2400Кбит/с -> 1680Кбит/с).
MNP-2 Асинхронная дуплексная передача данных с побайтовой организацией. Эффективность 84% (2400кбит/с -> 2000кбит/с)
MNP-3 Синхронная дуплексная передача данных с побитовой организацией. Эффективность 108%.
MNP-4 Адаптивная сборка передаваемых блоков (вариация размера блока) и оптимизация фазы. Эффективность 120%
MNP-5 Помимо новшеств MNP-4 применено сжатие данных. Эффективность 200%. Используется только совместно с MNP-2-4
MNP-6 Снабжен адаптивностью скорости передачи, рассчитан на ^работу до 9.6кбит/с. Имеется возможность автоматического переключения из дуплексного режима в полудуплексный и обратно с учетом ситуации
MNP-7 Усовершенствованный алгоритм сжатия данных. Эффективность до 300%.
MNP-8,9 Еще более мощные алгоритмы сжатия
MNP-10 Протокол, ориентированный на работу в сетях с высоким уровнем шумов (сотовые сети, сельские и междугородние линии), надежность достигается благодаря многократным попыткам установить связь, вариации размера пакета и подстройки скорости передачи
Модем подключается к ЭВМ (см. рис. 4.3.7.2) через последов**
тельный интерфейс RS-232C (существуют версии модемов, способ
ных работать и с параллельным интерфейсом, который обладав
почти в 3 раза большим быстродействием). Ниже в таблице преД*
ставлена разводка для 9- и 25- контактных разъемов (таблий*
Сети передачи данных. Метод доступа
311
Рис. 4.3.7.2 Схема подключения модема
4.3.7.3), используемых для последовательных интерфейсов (синх-
ронные модемы используют только 25-контактный разъем).
Таблица 4.3.7.3. Раздодка стандартных разъемов модема
Сигнал Номер контакта (DB-9) Номер контакта (DB-25) Назначение
DCD 1 8 Несущая обнаружена (Data Carrier Detected)
RxD 2 2 Передача данных от DCE к DTE (Received Data)
TxD 3 3 Передача данных от DTE к DCE (Transmit Data)
DTR 4 20 Данные для передачи готовы (Data Transfer Ready)
GND 5 7 Земляной контакт
DSR 6 6 Готовность DCE к работе (Data Set Ready)
RTS 7 4 Готовность DTE к передаче (Request То Send)
CTS 8 5 Готовность DCE к передаче (Clear То Send)
. RI 9 22 Индикатор звонка (Ring Indicator)
В персональных ЭВМ может быть 2 или 4 последовательных
Сортов (интерфейсов), которые имеют логические имена СОМ1-СОМ4,
соответствуют следующие прерывания и адреса:
СОМ1,3 IRQ4 0x3F8
COM2,4 IRQ3 0x2F8
312
Гпава 4
К телефонной сети модем подключается с помощью 6-х контак-
тного разъема RJ11 (используется 4 контакта).
Модем может находиться в режиме данных (режим по умолча-
нию) и в командном режиме. Последний используется для рекон-
фигурации модема и подготовки его к работе. Реконфигурация и
управление возможны из локальной ЭВМ через последовательный
порт, с передней панели модема, или при установленной связи через
удаленный модем, если такой режим поддерживается. Переключе-
ние в командный режим производится с помощью ESC-последова-
тельности (по умолчанию это три символа «+» с предшествующей и
последующей секундной паузой).
При использовании большого числа модемов они для удобства
обслуживания объединяются в группы (пулы). Модемный пул пред-
ставляет в себя стандартный каркас, где размещается какое-то коли-
чество бескорпусных модемов. На передней панели находится, как пра-
вило, только индикация, выходы в телефонную сеть и разъемы после-
довательного интерфейса подключаются через заднюю панель. Такой
пул содержит в себе обычно управляющий процессор. Так как в насто-
ящее время не существует стандартов на организацию модемных пу-
лов, они ориентированы на использование модемов только определен-
ной фирмы. К пулу может подключаться дисплей, который отобража-
ет текущее состояние всех модемов. Процессор может контролировать
состояние модемов, устанавливать их режим работы, а в некоторых
случаях и выполнять функцию маршрутизатора, управляя встроен-
ным многоканальным, последовательным интерфейсом. В последнем
случае такой пул подключается непосредственно к локальной сети
(например, Ethernet), а не к ЭВМ. Пул позволяет предотвращать «по-
висание» и отключение телефонных линий, что заметно повышает
надежность системы. Некоторые модемы (например, фирмы Penril)
имеют независимые узкополосные (-300 бит/с), дополнительные кана-
лы для дистанционного управления. Такие каналы обладают повы-
шенной устойчивостью, что позволяет сохранять целостность системы
даже при временных отключеньях электропитания.
Передача файлов возможна с использованием терминальной про*
граммы, это особенно полезно для удаленных терминалов, не под-
держивающих протоколы TCP/IP. Терминальные программы ис-
пользуют один из перечисленных выше протоколов, например»
ZMODEM. В качестве терминальной программы можно воспользо-
ваться одной из: Term95 (Norton Commander 5.0), BitCom, TeleVie*’
Telix, Procomm Plus (для DOS и Windows), MTEZ, MTE, ZSTEM-2W
PCTalk, CrossTalk (эта и следующие для Windows), DataLi^’
Hyper Access.
Сети передачи данных. Метод доступа 313
Таблица 4.3.7.4. Протоколы передачи файлов
XMODEM Протокол (1977г, В. Кристенсен для ОС СР/М). Алго-
ритм:
• принимающая ЭВМ посылает символ NAK (ASCII 021)
• передающая ЭВМ посылает блок информации
• принимающая ЭВМ проверяет контрольную сумму и', если
все в порядке, посылает код ASCII 06 (АСК), в противном
случае NAK
• далее следует повтор передачи при ошибке или посылка
следующего блока данных при успехе. Формат блока
данных: номер пакета, 128 байт данных и 2 байта конт-
рольной суммы. В XMODEM на принимающей стороне
приходится вручную указывать имя файла
KERMIT Наиболее распространенный протокол, использующий
блоки переменной длины с максимальным размером 94
байта (программы написаны на Си или ФОРТРАН). Явля-
ется пакетным протоколом, позволяя пересылать за один
раз несколько файлов, для повышения эффективности
пересылки использует предварительную архивацию и
коррекцию ошибок (Колумбийский университет, 1981г.).
MODEM7 Усовершенствованная версия XMODEM для работы по
коммутируемым телефонным каналам (передается имя
файла).
XMODEM/1024 Разновидность XMODEM с размером блока
данных 1024 байта.
XMODEM/CRC Разновидность XMODEM, использующая 16
битовую CRC.
TELINK Передается кроме имени файла, дата, время, можно
передать несколько файлов за одну сессию.
Практически все выше перечисленные протоколы устарели.
YMODEM Протокол использует CRC-16, передает имена файлов,
размер, дату создания и время, в зависимости от условий
передачи размер блока варьируется от 128 до 1024 байт
(Чак Форсберг, 1984-85).
SEALINK Модификация протокола YMODEM.
ZMODEM Протокол использует CRC-32 (или CRC-16), динамичес-
кое изменение размера блока (32-1024 байта), автоматичес-
кий выбор протокола обмена, сжатие файлов при пересылке,
возобновление передачи с прерванного места в случае разры-
ва связи. На сегодня это самый совершенный протокол.
314
Гпава 4
Чтобы обеспечить безопасность и исключить несанкционирован-
ный доступ к сети, можно воспользоваться методом «обратного те-
лефонного вызова», некоторые модемы реализуют его аппаратно.
Метод предполагает, что после установления связи и проверки авто-
ризации связь прерывается, а входной модем сети производит набор
номера клиента, который хранится в памяти, и устанавливает связь
повторно. Такая схема исключает передачу входного пароля друзь-
ям или знакомым, так как это становится бессмысленным — мо-
дем будет пытаться установить связь по номеру вашего домашнего
телефона.
Модемы обычно имеют дисплей, который позволяет контролиро-
вать работу этого прибора. Модемы разных производителей имеют
различные типы дисплеев, ниже приведен список наиболее часто <
встречающихся индикаторов.
MR Модем включен и готов к работе (Modem Ready);
TR «Терминал готов» (Terminal Ready) — включается, когда
модем обнаруживает сигнал TDR (Data Terminal Ready),
передаваемый вашим программным обеспечением;
HS Индикатор включается, когда модем работает на макси-
мальной для него скорости (High Speed).
CD Обнаружен несущий сигнал (Carrier Detected), гаснет лишь :
тогда, когда «партнер положит трубку»;
АА Модем включен в режим авто-ответа (Auto Answer); ;
ОН Модем занял линию — «трубка снята» (Off-Hook);
RD Индикатор мигает (Receive Data), когда ЭВМ принимает
данные из своего модема.
SD Индикатор (Send Data) мигает при передаче данных из
ЭВМ в модем.
RL Индикатор (Reliable Link) указывает на то, что модем
договорился с партнером о типе протокола MNP.
RD Принимаются данные (Receive Data). Индикатор мигает при
передаче данных в ЭВМ. 5
TS Модем находится в режиме самотестирования.
PWR Включено питание модема.
В современных ЭВМ имеется возможность совместить функций
модема и факс-аппарата. Для решения этой задачи используются
так называемые факс-модемы. Эти приборы работают в полуду11'
лексном режиме. Ниже перечислены протоколы, используемые в
этих аппаратах (кроме протоколов передачи данных факс-модем#
поддерживают стандарты Т.4 и Т.ЗО):
Сеги переда чи данных. Метод доступа 315
у.17 9.6 или 14.4 Кбит/с
у. 21 200 бит/с (используется только на этапе
установления связи)
V.27ter 2.4 или 4.8 Кбит/с
у.29 7.2 или 9.6 Кбит/с
V.527ter 2400 или 4800 бит/с
Для обеспечения работы факс-модема пригодны программы: BitFax,
WinFax, QuickLink или любая другая, поставляемая вместе с приоб-
ретенном вами модемом. Следует иметь в виду, что для пересылки
через факс-модем традиционного документа, подготовленного на
типографском бланке, написанного от руки и т.д., вам потребуется
сканнер. В перспективе факс-технология будет вытеснена электрон-
ной почтой, которая эффективнее и, при необходимости, может обес-
печить большую безопасность.
В настоящее время технология модемов продолжает развивать-
ся, появились и активно внедряются кабельные модемы, много уси-
лий тратится на развитие ADSL (см. http://www.adsl.com/
general_tutorial.html (Asymmetric Digital Subscriber Line), SDSL (Single
Line Digital Subscriber Line), HDSL (High data rate Digital Subscriber
Line), VDSL (Very high data rate Digital Subscriber Line) и некоторых
других технологий, связанных с передачей мультимедиа данных.
(См. xDSL. ATG’s Communications & Networking Technology Guide
Series. PairGain, CopperOptics company; http://www.techguide.com/).
Эти технологии предназначены для обеспечения широкополосного
канала между провайдером и конечным пользователем (проблема
последней мили). [Должен заметить, что миля мера иностранная и
российским 1,853 км, если речь идет о телефонных кабелях, не
соответствует. Провода у нас другого качества и наша миля как бы
длиннее, если судить по искажениям сигнала и шумам]. Здесь ис-
пользуются три метода модуляции (2B1Q, САР и DMT). ADSL по-
зволяет приспособить обычные телефонные линии для мультиме-
дийных приложений и для высокоскоростной передачи данных (до
6 Мбит/с). Два ADSL-модема, соединенные скрученной парой прово-
дов образуют три информационных канала: скоростной однонап-
равленный (нисходящий) канал (1,5-6,1 Мбит/с), среднескоростной
Дуплексный канал (16-640 Кбит/с) и POTS-канал (Plain Old Telephone
Service). POTS сохраняет работоспособность даже при отказе ADSL,
каждый из этих каналов может мультиплексироваться, образуя ка-
яалы меньшего быстродействия. ADSL-модемы могут работать и с
iM-сетями, но следует учитывать их принципиальную асиммет-
Ричность - передача в одном направлении и в другом имеет разную
316
Гпава 4
скорость. Для передачи данных в сети Интернет это не удобно. Но
для транспортировки телевизионного сигнала такая схема пред-
ставляется вполне эффективной.
Для провода длиной 5,5 км при диаметре сечения 0,5 мм (стан-
дартные условия для ISDN) пропускная способность составляет 1,5
— 2,0 Мбит/с (верхний край полосы пропускания около 1 МГц).
При организации дуплексного канала весь частотный диапазон де-
лится пополам и одна из частей используется для передачи данных
в одном направлении, другая — в противоположном. Каждый из
частотных диапазонов в свою очередь делится на части и для каж-
дой из них используется техника эхо-подавления. Для POTS-кана-
ла выделяется 4 кГц в низкочастотной части диапазона.
HDLS представляет собой способ передачи потоков Т1 или Е1
по скрученным парам проводов с использованием улучшенной тех-
ники модуляции (для передачи 1,544-2,048 Мбит/с достаточно по-
лосы 80-240 кГц). SDSL представляет собой версию HDSL с одной
скрученной парой. Ниже в таблице 4.3.7.5 приведены сравнитель-
ные данные для различных систем передачи информации.
Верхние значения в третей колонке для ADSL и VDSL соответ-
ствуют нисходящему (асимметричный канал) и дуплексному пото-
кам. HDTV — телевидение высокого разрешения.
DSL представляет собой канал ISDN-BRI (Basic Rate Interface;
2*64 + 16 Кбит/с), совместимый с POTS, ISDN и DDS. На рис.
4.3.7.3 показаны области применимости различных канальных тех-
нологий.
m
к
s
I 2,5
с
о
о.
§0,25
О
с
Опто волокно
HDSI?
Теоретический
предел для медк
ISDN
DDS:
1 2 3 4 5
Расстояние в милях
Рис. 4.3.7.3. Ограничения пропускной способности
для разных типов канала
Сети передачи данных. Метод доступа 317
Таблица 4.3.7.5. Свойства различных систем [модемов!
передачи информации.
г — Название Расшифровка Длина канала при 24 AWG (0,5мм) Быстро- действие Применение
\Л22 ' V.32 V.34 Модемы голосового диапазона 12 км 1200бит/с 28800 бит/с Передача данных
DSL- Digital Subscriber Line 5,4 км 160 Кбит/с Услуги ISDN, передача данных и голоса
"HDSL High data rate Digital Subscriber Line 3,6 км 1,544 Мбит/с 2,048 Мбит/с Т1/Е1 каналы, локальные и региональные сети.
SDSL Single Line Digital Subscriber Line 1,544 Мбит/с 2,048 Мбит/с Т1/Е1 каналы, локальные и региональные сети
ADSL Asymmetric Digital Subscriber Line 3,6/5,4 км 1,5-9 Мбит/с или 16-640 Кбит/с Доступ к Интернет, видео, интерактивное мультимедиа.
VDSL Very high data rate Digital Subscriber Line 13-52 Мбит/с или 1,5-2,3 Мбит/с То же, что и ADSL плюс HDTV
Метод модуляции 2B1Q характеризуется четырьмя уровнями
амплитудной модуляции (4-РАМ; +3, +1, -1 и -3). САР-модуляция
(Carrierless Amplitude and Phase) характеризуется четырьмя уров-
нями амплитуды и четырьмя фиксированными значениями фазы,
нто дает в плоскости амплитуда-фаза 16 независимых состояний.
DTM-модуляция (Discrete Multi-tone) предполагает использование
нескольких смежных, узких частотных диапазонов. На рис. 4.3.7.2
показана схема подключения оборудования ADSL для различных
оконечных терминалов.
В качестве внешней сети на рис. 4.3.7.4 может использоваться
практически любая достаточно быстродействующая среда, например
*М. Выбор того или иного внешнего канала зависит от стоящей
3аДачи. Так файл размером 30 Кбайт (среднего размера электрон-
Ное Со°бщение) будет передан через модем V.34 за .8,3 сек, по кана-
318
Гпава 4
Сервис провайдер
Рис. 4.3.7.4. Схема подключения оборудования ADSL
(IF - ADSL/Ethernet интерфейс)
лу ISDN - за 1,9 сек, по каналу HDSL - за 0,16 сек, а по каналу
VDSL - быстрее 0,04 сек. В большинстве случаев вполне приемле-
мым можно считать уже первые два варианта. Деловой электрон-
ный документ имеет размер порядка 250 Кбайт. Здесь для пересыл-
ки его указанными способами потребуется уже, соответственно: 69,4;
15,6; 1,3 и 0,3 секунды. Более чем минутное время доставки (в
реальности это обычно больше) в некоторых случаях не будет при-
Рис. 4.3.7.5. Схема подключения телевизора и телефона через
модем ADSL
Сети передачи данных. Метод доступа
319
зяано удовлетворительным. Время пересылки рентгенограммы (~5
Мбайт) будет пропорционально больше (23 мин, 5,2 мин, 26 сек и
б 5 сек). Считается, что приемлемым временем отклика на коман-
ду следует считать 3 секунды, а до 80% трафика локальной сети
составляет внешний поток данных. Если же стоит задача организа-
ции видеоконференции (384 Кбит/с), то решение проблемы возмож-
но уже только с использованием каналов xDSL. Учитывая стреми-
тельный рост потребной пропускной способности каналов, не труд-
но предсказать перспективность внедрения технологии xDSL.
Пример использования модема ADSL для подключения телеви-
зора и модема к широкополосному каналу представлен на рис.
4.3.7.5. Управляющий канал на 16 кбит/с может использоваться
для целей интерактивного телевидения (смотри раздел «Методы
преобразования и передачи изображения»).
320
Гпава 4
4.4. Интернет
Виртуальная сеть виртуальных сетей — Интернет является са-
мой большой и самой популярной сетью. Можно смело утверждать,
что эта сеть сохранит это лидерство в ближайшие годы. Привлека-
тельность сети не только в том, что это единая среда общения лю-
дей, находящихся в разных странах и на разных континентах. Ин-
тернет предоставляет все более широкий спектр услуг. Это и инфор-
мационно-поисковые системы, телефония, аудио и видео письма,
доставляемые за считанные секунды в любую точку мира (где име-
ется Интернет), видеоконференции, электронные журналы, службы
новостей, дистанционное обучение, банковские операции и многое,
многое другое. Интернету предстоит мучительная процедура пере-
хода на 128-битовые адреса (IPv6), но по ее завершении можно
ожидать дальнейшего расширения списка услуг. Уже сегодня Ин-
тернет стал средой, предоставляющей возможность целевой рекла-
мы и дистанционной торговли. Уже в начале следующего века сети
станут самым мощным средством массовой информации. Но для
решения всех этих проблем в ^той сфере еще очень много надо
сделать. Современные поисковые системы, несмотря на впечатляю-
щие успехи, требуют существенного улучшения эффективности, много
надо сделать для того, чтобы Интернет пришел в каждую квартиру.
Сегодня Интернет использует многие десятки протоколов. Если
сюда добавить протоколы физического уровня, то их число превы-
сит сотню. На уровне локальных сетей наиболее распространены
различные разновидности Ethernet, а также Token Ring и некото-
рые другие. Особенно велико разнообразие протоколов межсетевого
обмена. Здесь помимо РРР используется FDDI, Х.25, ISDN, ATM,
SDH, Fibre Channel и пр.. На транспортном уровне в Интернет рабо*
тают протоколы UDP (без установления соединения) и TCP (с уста-
новлением соединения). Это два принципиально разных подхода к
передаче данных. В обоих случаях и передатчик и приемник имеют
индивидуальные IP-адреса и порты. Но в случае TCP они ассоции-
руются в соединители (socket) — две пары IP-адрес-порт и прием/
передача в рамках одной сессии происходит по схеме точка-точка*
Для UDP же допускается возможность передачи одновременно Я*
скольким приемникам (мультикастинг) и прием данных от я6*
скольких передатчиков в рамках одной и той же сессии. Проток^
TCP используется для поточной передачи данных, при которой Д00'
тавка гарантируется на протокольном уровне. Это обеспечивает^
обязательным подтверждением получения каждого пакета Tv •
Сеги передачи данных. Метод доступа
321
Напротив, протокол UDP не требует подтверждения получения. В
этом случае, как правило, исключается также и фрагментация паке-
тов, так как пакеты при схеме без установления соединения никак
не связаны между собой. По этим причинам UDP в основном слу-
жит для передачи мультимедийных данных, где важнее своевремен-
ность, а не надежность доставки. Протокол TCP используется там,
где важна надежная, безошибочная доставка информации (файло-
вый обмен, передача почтовых сообщений и WEB-технология).
Схема без установления соединения привлекательна также тем,
что позволяет при передаче данных от исходного источника к боль-
шому числу приемников минимизировать общий трафик. Если бы
для этой цели использовался протокол TCP, то при N приемниках
надо было бы сформировать N виртуальных каналов и транспорти-
ровать N идентичных пакетов (рис. 4.4.1). В случае UDP от пере-
датчика до точки разветвления передается только один пакет, что
уменьшает загрузку данного участка в N раз (рис. 4.4.2). Причем
аналогичная экономия может быть реализована и по пути к очеред-
ной точке разветвления (смотри описание протокола мультикас-
тинг-маршрутизации PIM).
Рис. 4.4.1.
322
Гпава 4
В примере на рисунке 4.4.2 на участке 1 снижение трафика по
сравнению с традиционным методом передачи данных происходив
в 8 раз, на участке 2 — в 4 раза, а на сегментах 3 — в два раза.
Все множество протоколов Интернет можно поделить на две
группы. К первой относятся те, что имеют собственный стандарт на
формат пакетов (IP, UDP, TCP, ARP, RARP, RTP, RIP, OSPF, BGP,
IGRP, ICMP, SNMP, DNS, PIM, IGMP, BOOTP, IPX/SPX, AAL и др.).
Вторую группу образуют протоколы, которые формализуют обмен
на уровне сообщений. Они не имеют своих форматов на пакеты, а
стандартизуют лишь форму сообщений и алгоритм обмена. Вторая
группа использует для передачи своих сообщений протоколы пер-
вой группы. К этой группе относятся SMTP, NTP, POP, IMAP, FTP,
HTTP, RSVP, Telnet, Finger, NNTP, Whois, SET, SSL и т.д. По суще-
ству, вторая группа располагается на прикладном уровне. Первая
группа более консервативна и достаточно хорошо структурирована,
вторая - динамична и постоянно расширяется. Ко второй группе
примыкают некоторые стандартизованные утилиты типа ping,
traceroute, а также поисковые системы. В перспективе на подходе
протоколы для интерфейсов баз данных и мультимедиа. Особня-
ком стоят алгоритмы обеспечения безопасности.
4.4.7. IP-протокол
В Интернет используется много различных типов пакетов, но один
из основных — IP-пакет (RFC-791), именно он вкладывается в кадр
Ethernet и именно в него вкладываются пакеты UDP, TCP. IP-прото-
кол предлагает ненадежную транспортную среду. Ненадежную в том
смысле, что не существует гарантии благополучной доставки 1Р-дей-
тограммы. Алгоритм доставки в рамках данного протокола предельно
прост: при ошибке дейтограмма выбрасывается, а отправителю посы-
лается соответствующее ICMP-сообщение (или не посылается ничего).
Обеспечение же надежности возлагается на более высокий уровень
(UDP или TCP). Формат IP-пакетов показан на рисунке 4.4.1.1.
Поле версия характеризует версию IP-протокола (например, 4 илй
6). Формат пакета определяется программой и, вообще говоря, может
быть разным для разных значений поля версия. Только размер и
положение этого поля незыблемы. Поэтому в случае изменений дли-
ны IP-адреса слишком тяжелых последствий это не вызовет. Понят*’
но также, что значение поля версия во избежание непредсказуемых
последствий должно контролироваться программой. HLen — длина
заголовка, измеряемая в 32-разрядных словах, обычно заголовок
держит 20 октетов (HLen=5, без опций и заполнителя). Поле полнМ
длина определяет полную длину IP-дейтограммы (до 65535 октетовХ
Сети передачи данных. Метод доступа 323
0 4 8 16 19 24 31
Версия HLen Тип сервиса Полная длина
Идентификатор Флаги Указатель фрагмента
Время жизни Протокол Контрольная сумма заголовка
IP-адрес отправителя
IP-адрес получателя
IP-опции (если имеются) Заполнитель
Данные
20
октетов
Рис. 4.4.1.1. Формат дейтограммы Интернет
включая заголовок и данные. Одно-октетное поле тип сервиса (TOS
— Type Of Service) характеризует то, как должна обрабатываться
дейтограмма. Это поле делится на 6 субполей:
0 1 2 3 4 5 6 7
Приоритет D Т R С Не используется
Субполе приоритет предоставляет возможность присвоить код
приоритета каждой дейтограмме. Значения приоритетов приведены
в таблице (в настоящее время это поле не используется).
0 Обычный уровень
1 Приоритетный
2 Немедленный
3 Срочный
4 Экстренный
5 CEITIC/ECP
6 Межсетевое управление
7 Сетевое управление
Биты С, D, Т и R характеризуют пожелание относительно спосо-
ба доставки дейтограммы. Так D=1 требует минимальной задержки,
высокую пропускную способность, R=1 — высокую надеж-
н°сть, а С=1 - низкую стоимость. TOS играет важную роль в марш-
РУтизации пакетов. Интернет не гарантирует запрашиваемый TOS,
Многие маршрутизаторы учитывают эти запросы при выборе мар-
РУта (протоколы OSPF и IGRP). В таблице 4.4.1.1 приведены
ек°мендуемые значения TOS. .
И*
зм
Гпава 4
Табл. 4.4.7.7. Значения TOS для разных протоколов
Процедура Мин. задержка Макс, пропускная способность Макс, надежность Мин. стоимость Код TOS
FTP управление 1 0 0 0 ~оИо~
FTP данные 0 1 0 0 0x08
TFTP 1 0 0 0 0x10
DNS 1 0 0 0 0x10
UDP 0 0 0 0 0x00
TCP 0 0 0 0 0x00
Telnet 1 0 0 0 0x10
ICMP 0 0 0 0 0x00
IGP 0 0 1 0 0x04’
SMTP управление 1 0 0 0 0x10
SMTP данные 0 1 0 0 0x08
SNMP 0 0 1 0 0x04
NNTP 0 0 0 1 0x02
Только один бит из четырех в TOS может принимать значение 1. '
Значения по умолчанию равны нулю. Большинство из рекоменда-
ций самоочевидны. Так при Telnet наибольшую важность имеет
время отклика, а для SNMP (управление сетью) — надежность.
Поля идентификатор, флаги (3 бита) и указатель фрагмента
(fragment offset) управляют процессом фрагментации и последую-
щей «сборки» дейтограммы. Идентификатор представляет собой
уникальный код дейтограммы, позволяющий идентифицировать при-
надлежность фрагментов и исключить ошибки при «сборке» дей- ;
тограмм. Бит 0 поля флаги является резервным, бит 1 служит для
управления фрагментацией пакетов (0 — фрагментация разрешена;
1 — запрещена), бит 2 определяет, является ли данный фрагмент
последним (0 - последний фрагмент; 1 — следует ожидать продол-
жения). Поле время жизни (TTL — Time То Live) задает время
жизни дейтограммы в секундах, т.е. предельно допустимое время
пребывания дейтограммы в системе. При каждой обработке дейтог-
раммы, например в маршрутизаторе, это время уменьшается в соот-
ветствии со временем пребывания в данном устройстве или соглас-
но протоколу обработки. Если TTL=0, дейтограмма из системы уда-
ляется. Во многих реализациях TTL измеряется в числе шагов, в
этом случае каждый маршрутизатор выполняет операцию TTL=TTL-
1. TTL помогает предотвратить зацикливание пакетов. Поле прото-
кол аналогично полю тип в Ethernet-кадре и определяет структуру
поля данные (см. табл. 4.4.1.2).
Сети передачи данных. Метод доступа
325
Поле контрольная сумма заголовка вычисляется с использовани-
ем операций сложения 16-разрядных слов заголовка по модулю 1.
Сама контрольная сумма является дополнением по модулю один
полученного результата сложения. Обратите внимание, здесь осуще-
ствляется контрольное суммирование заголовка, а не всей дейтог-
раммы. Поле опции не обязательно присутствует в каждой дейтог-
рамме. Размер поля опции зависит от того, какие опции примене-
ны. Если используется несколько опций, они записываются подряд
без каких-либо разделителей. Каждая опция содержит один октет
кода опции, за которым может следовать октет длины и серия окте-
тов данных. Если место, занятое опциями, не кратно 4 октетам,
используется заполнитель. Структура октета кода опции отражена
на рис. 4.4.1.2.
Таблица 4.4.1.2. Коды протоколов Интернет
Код протокола Интернет Сокращенное название протокола Описание
0 - Зарезервировано
I ICMP Протокол контрольных сообщений [RFC792]
2 IGMP Групповой протокол управления [RFC1112]
3 GGP Протокол маршрутизатор-маршрутизатор [RFC823]
4 IP IP поверх IP (инкапсуляция/туннели)
5 ST Поток [RFC 1190]
6 TCP Протокол управления передачей [RFC793]
7 UCL UCL
• 8 EGP Протокол внешней маршрутизации [RFC888]
9 IGP Протокол внутренней маршрутизации
10 BBN-MON BBN-RCC мониторирование
н NVP-II Сетевой протокол для голосовой связи [RFC741]
12 PUP PUP
^13 ARGUS ARGUS
— EMCON EMCON
_ 15 XNET Перекрестный сетевой отладчик [IEN158]
_ 16 CHAOS CHAOS
UDP Протокол дейтограмм пользователя [RFC768]
, 18 MUX Мультиплексирование [IEN90]
19 DCN-MEAS DCN измерительные субсистемы
20 HMP Протокол мониторирования ЭВМ (host [RFC869])
326
Гпава 4
Таблица 4.4.1.2. Коды протоколов Интернет (продолжение)
Код протокола Интернет Сокращенное название' протокола Описание
21 PRM Мониторирование при передаче пакетов по радио
22 XNS-IDP XEROX NS IDP
23 TRUNK-1 TRUNK-1
24 TRANK-2 TRUNK-2
25 . LEAF-1 LEAF-1
26 LEAF-2 LEAF-2
' 27 RDP Протокол для надежной передачи данных [RFC908]
28 IRTP Надежный ТР для Интернет [RFC938]
29 IS0-TP4 ISO транспортный класс 4 [RFC905]
30 NETBLT Массовая передача данных [RFC969]
31 MFE-NSP Сетевая служба MFE
32 MERIT-INP Межузловой протокол MERIT
33 SEP Последовательный обмен
34 Протокол подключения через посредника
35 IDRP Междоменный протокол маршрутизации
36 XTP Xpress транспортный протокол
37 DDP Протокол доставки дейтаграмм
38 IDPR-CMTP IDPR передача управляющих сообщений
39 TP++ ТР++ транспортный протокол
40 IL IL-транспортный протокол
41 SIP Простой Интернет-протокол
42 SDRP Протокол маршрутных запросов для отправителя
43 SIP-SR SIP исходный маршрут
44 SIP-FRAG SIP-фрагмент
45 1 IDRP Интер-доменный маршрутный протокол
46 RSVP Протокол резервирования ресурсов канала
47 GRE Общая инкапсуляция маршрутов
49 BNA BNA
50 SIPP-ESP SIPP ES3
52 I-NLSP Интегрированная система безопасности сетевого уровня _
53 SWIPE IP с кодированием _
54 NHRP NBMA протокол определения следующего шага
55-60 Не определены
61 • Любой внутренний протокол ЭВМ
62 CFTP CFTP
Сети передачи данных. Метод доступа
327
Таблица 4.4.1.2. Коды протоколов Интернет [окончание)
Код протокола Интернет Сокращенное название протокола Описание
63 Любая локальная сеть
64 SAT-EXPAK SATNET и ЕХРАК
’ 65 MIT-SUBN Поддержка субсетей MIT
66 RVD Удаленный виртуальный диск MIT
67 IPPC IPPC
68 Любая распределенная файловая система
69 SAT-MON Мониторирование SATNET
70 Протокол VISA
71 IPCV Базовая пакетная утилита
75 PVP Пакетный видео-протокол
76 BRSAT- MON Резервное мониторирование SATNET
78 WB-MON Мониторирование.ЕХРАК
79 WB-EXPAK Широкополосная версия ЕХРАК
80 ISO-IP ISO Интернет протокол
88 IGRP IGRP (CISCO) - внутренний протокол маршрутизации
89 OSPFIGP OSPFIGP - внутренний протокол маршрутизации
92 МТР Транспортный протокол мультикастинга
101-254 Не определены
255 Зарезервировано
1 октет
1 октет
п октетов
Код Длина Данные
0 1 2 3 4 5 6 7 Номера двоичных разрядов
Копия Класс опции Номер опции
Рис. 4.4Л.2. Формат описания опций
Флаг копия равный 1 говорит о том, что опция должна быть
скопирована во все фрагменты дейтограммы. При равенстве этого
Флага 0 опция копируется только в первый фрагмент. Ниже приве-
значения разрядов 2-битового поля класс опции:
328
Гпава 4 s
Значение поля класс опции Описание
0 Дейтограмма пользователя или сетевое управление"
I Зарезервировано для будущего использования "
2 Отладка и измерения (диагностика)
3 Зарезервировано для будущего использования
В таблице, которую вы найдете ниже, приведены значения клас-
сов и номеров опций.
Класс опции Номер опции Длина описания Назначение
0 0 - Конец списка опций. Используется, если опции не укладываются в поле заголовка (смотри также поле ’’заполнитель”)
0 I - Никаких операций (используется для выравнивания октетов в списке опций)
0 2 п Ограничения, связанные с секретностью (для военных приложений)
0 3 * Свободная маршрутизация. Используется для того, чтобы направить дейтограмму по заданному маршруту
0 7 * Запись маршрута. Используется для трассировки
0 8 4 Идентификатор потока. Устарело.
0 9 * Жесткая маршрутизация. Используется, чтобы направить дейтограмму по заданному маршруту
2 4 * Временная метка Интернет
в колонке «длина» — означает — переменная.
Наибольший интерес представляют собой опции временные метки
и маршрутизация. Опция записать маршрут создает дейтограмму,
где зарезервировано место, куда каждый маршрутизатор по дороге
должен записать свой IP-адрес (например, утилита traceroute). Фор-
мат опции записать маршрут в дейтограмме представлен ниже на
рис. 4.4.1.3:
Рис. 4.4.1.3 Формат опций записать маршрут
Сеги передачи данных. Метод доступа 329
Поле код содержит номер опции (7 в данном случае). Поле
длина определяет размер записи для опций, включая первые 3 окте-
та. Указатель отмечает первую свободную позицию в списке IP-
адресов (куда можно произвести запись очередного адреса). Инте-
ресную возможность представляет опция маршрут отправителя,
которая открывает возможность посылать дейтограммы’по задан-
ному отправителем маршруту. Это позволяет исследовать различ-
ные маршруты, в том числе те, которые недоступны через узловые
маршрутизаторы. Существует две формы такой маршрутизации: Сво-
бодная маршрутизация и Жесткая маршрутизация. Форматы для
этих опций показаны ниже:
о 7 16 24 31
Код (137) Длина Указатель I
IP-адрес первого шага (hop)
IP-адрес второго шага
Рис. 4.4.1.3a. Формат опций маршрутизации
Жесткая маршрутизация означает, что адреса определяют точ-
ный маршрут дейтограммы. Проход от одного адреса к другому
может включать только одну сеть. Свободная маршрутизация от-
личается от предшествующей опции возможностью прохода между
двумя адресами списка более чем через одну сеть. Поле длина зада-
ет размер списка адресов, а указатель отмечает адрес очередного
маршрутизатора на пути дейтограммы.
IP-слой имеет маршрутные таблицы, которые просматриваются
каждый раз, когда IP получает дейтограмму для отправки. Когда
дейтограмма приходит от сетевого интерфейса, IP первым делом
проверяет, принадлежит ли IP-адрес места назначения к сйиску ло-
кальных адресов, или является широковещательным адресом. Если
имеет место один из этих вариантов, дейтограмма передается про-
граммному модулю в соответствии с кодом в поле протокола. IP-
процессор может быть сконфигурирован как маршрутизатор, в этом
случае дейтограмма может быть переадресована в другой узел сети.
Маршрутизация на IP-уровне носит пошаговый характер. IP не зна-
ет всего пути, он владеет лишь информацией - какому маршрутиза-
т°Ру послать дейтограмму с конкретным адресом места назначения.
Просмотр маршрутной таблицы происходит в три этапа:
1 • Ищется полное соответствие адресу места назначения. В слу-
Чае успеха, пакет посылается соответствующему маршрутизатору
330
Гпава 4
или непосредственно интерфейсу адресата. Связи точка-точка вы-
являются именно на этом этапе.
2. Ищется соответствие адресу сети места назначения. В случае
успеха система действует также как и в предшествующем пункте.
Одна запись в таблице маршрутизации соответствует всем ЭВМ,
входящим в данную сеть.
3. Осуществляется поиск маршрута по умолчанию и, если он най-
ден, дейтограмма посылается соответствующему маршрутизатору.
Для того чтобы посмотреть, как выглядит простая маршрутная
таблица, воспользуемся командой netstat -гп (ЭВМ SUN. Флаг -г
выводит на экран маршрутную таблицу, а -п отображает IP-адреса
в цифровой форме. С целью экономии места таблица в несколько
раз сокращена).
Routing tables Destination Gateway Flags Refcnt Use Interface
193.124.225.72 193.124.224.60 UGHD 0 61 leO
192.148.166.1 193.124.224.60 UGHD 0 409 leO
193.124.226.81 193.124.224.37 UGHD 0 464 leO
192.160.233.201 193.124.224.33 UGHD 0 222 leO
192.148.166.234 193.124.224.60 UGHD 1 3248 leO
193.124.225.66 193.124.224.60 UGHD 0 774 leO
192.148.166.10 193.124.224.60 UGHD 0 621 leO
192.148.166.250 193.124.224.60 UGHD 0 371 leO
192.148.166.4 193.124.224.60 UGHD 0 119 leO
145.249.16.20 193.124.224.60 UGHD 0 130478 leO
192.102.229.14 193.124.224.33 UGHD 0 13206 leO
default 193.124.224.33 UG 9 5802624 leO
193.124.224.32 193.124.224.35 U 6 1920046 leO
193.124.134.0 193.124.224.50 UGD 1 291672 leO
Колонка Destination — место назначение, default — отмечает
маршрут по умолчанию; Gateway — IP-адреса портов подключения
(маршрутизаторов); Refcnt (Reference count) — число активных ,
пользователей маршрута; Use - число пакетов, посланных по этому
маршруту; Interface — условные имена сетевых интерфейсов. Рас-
шифровка поля Flags приведено ниже:
U Маршрут работает (Up).
G Путь к маршрутизатору (Gateway), если этот флаг отсут-
ствует, адресат доступен непосредственно.
Н Маршрут к ЭВМ (Host), адрес места назначения является
полным адресом этой ЭВМ (адрес сети + адрес ЭВМ). Если
Сети передачи данных. Метод доступа
331
флаг отсутствует, маршрут ведет к сети, а адрес места назна-
чения является адресом сети.
р Маршрут возник в результате переадресации.
Маршрут был модифицирован с помощью переадресации.
Опция временные метки работает также как и опция запись
маршрута. Каждый маршрутизатор на пути дейтограммы делает за-
пись в одном из полей дейтограммы (два слова по 32 разряда; смот-
ри раздел 4.4.15). Формат этой опции отображен на рисунке 4.4.1.4.
0 7 16 ' 24 31
Код (68) Длина Указатель Переполнение Флаги
Первый IP-адрес
Первая временная метка
Рис. 4.4.1.4 Формат опции «временные метки»
Смысл полей длина и указатель идентичен тому, что сказано о
предыдущих опциях. 4-битовое поле переполнение содержит число
маршрутизаторов, которые не смогли записать временные метки из-
за ограничений выделенного места в дейтограмме. Значения поля
флаги задают порядок записи временных меток маршрутизаторами:
Таблица 4.4.1.3. Значения флагов
Значение флага Назначение
0 Записать только временные метки; опустить IP-адреса.
1 Записать перед каждой временной меткой IP-адрес (как в формате на предыдущем рисунке).
3 IP-адреса задаются отправителем; маршрутизатор записывает только временные метки, если очередной IP- адрес совпадает с адресом маршрутизатора
Временные метки должны содержать время в миллисекундах,
отсчитанное от начала суток.
Взаимодействие других протоколов с IP можно представить из
схемы на рис. 4.4.1.5. В основании лежат протоколы, обеспечиваю-
щие обмен информацией на физическом уровне, далее следуют про-
токолы IP, ICMP, ARP, RARP, IGMP и протоколы маршрутизаторов.
ем выше расположен протокол, тем более высокому уровню он
соответствует. Протоколы, имена которых записаны в одной и той
332
Гпава 4
же строке, соответствуют одному и тому же уровню. Но все разло-
жить аккуратно по слоям невозможно — некоторые протоколы
занимают промежуточное положение, что и отражено на схеме, (об-
ласти таких протоколов захватывают два уровня. Здесь протоколы
IP, ICMP и IGMP помещены на один уровень, для чего имеется не
мало причин. Но иногда последние два протокола помещают над IP,
так как их пакеты вкладываются в IP-дейтограммы. Так что деле-
ние протоколов по уровням довольно условно. На самом верху
пирамиды находятся прикладные программы, хотя пользователю
доступны и более низкие уровни (например, ICMP), что также отра-
жено на приведенном рисунке (4.4.1.5).
Прикладные программы
WEB FTP SNMP NTP, RTP, NFS
SMTP HTTP TELNET Xwin DNS ASN.1 TFTP BOOTP
TCP UDP
Протоколы маршрути- заторов IP, ICMP, IGMP
ARP RARP
IEEE 802.3 Ethernet IEEE 802.2, ISDN, ATM, FDDI и т.д.
Рис. 4.4.1.5. Распределение протоколов Интернет по уровням
Интернет — это инструмент общения, средство доступа к инфор-
мации и как всякий инструмент требует практики. Из вашего соб-
ственного опыта вы знаете, что можно прочесть ворох инструкций о
том, как забивать гвозди, но научиться этому можно лишь на прак-
тике. Поэтому рекомендую с самого начала, читая данные тексты,
чаще садитесь за терминал.
4.4.1.1. Новый стандарт адресации IPv6
В конце 1992 года сообщество Интернет для решения проблем
адресного пространства и ряда смежных задач разработало три про-
екта протоколов: “TCP and UDP with Bigger Addresses (TUBA)”;
“Common Architecture for the Internet (CATNIP)” и “Simple Internet
Protocol Plus (SIPP) [смотри “Протоколы и ресурсы Интернет” Се-
менов Ю.А., Радио и связь, М 1995]. После анализа всех этих пред-
ложений был принят новый протокол Ipv6 с IP-адресами в 128 бит
вместо 32 для Ipv4. Внедрение этого нового протокола представля-
Сети передачи данных. Метод доступа
333
ет отдельную серьезную проблему, так как этот процесс не предпо-
лагает замены всего программного обеспечения во всем мире одно-
временно.
Адресное пространство IPv6 будет распределяться IANA (Internet
Assigned Numbers Authority — комиссия по стандартным числам в
Интернет [RFC-1881]). В качестве советников будут выступать IAB
(Internet Architecture Board — совет по архитектуре Интернет) и
IESG (Internet Engineering Steering Group — инженерная группа
управления Интернет). Распределение адресов будет производиться
с учетом максимального облегчения проблем маршрутизации. Каж-
дому из регионов будет выделен равный диапазон адресов, при этом
выстраивается иерархия типа страна-область-район-ассоциация-
пользователь. Такой метод неэкономен (регионы могут иметь не
равные размеры), но за то процедура маршрутизации становится
предельно простой.
IANA будет делегировать права выдачи IP-адресов региональ-
ным сервис провайдерам, а также субрегиональным структурам и
организациям. Отдельные лица и организации могут получить ад-
реса непосредственно от регионального распределителя или сервис
провайдера.
Передача адресного пространства от IANA не является необра-
тимым. Если по мнению IANA распорядитель адресного простран-
ства допустил серьезные ошибки, IANA может аннулировать вы-
полненное ранее выделение.
IANA в этом случае должна сделать все возможное, чтобы не
отзывать адреса, находящиеся в активном использовании, за исклю-
чением случаев, когда это диктуется техническими соображениями.
Оплата за распределение адресов должна использоваться исклю-
чительно на деятельность, непосредственно связанную с выделени-
ем адресов, поддержанием соответствующих баз данных и т.д. Ад-
ресное пространство само по себе не должно стоить ничего.
Следует избегать монополизации и любых злоупотреблений при
распределении IP-v6 адресов. IANA разработает план первичного
распределения IPv6 адресов, включая автоматическое выделение ад-
ресов индивидуальным пользователям.
IPv6 представляет собой новую версию протокола Интернет (RFC-
1883), являющуюся преемницей версии 4 (IPv4; RFC-791). Измене-
ния IPv6 по отношению к IPv4 можно поделить на следующие
гРУппы:
’ Расширение адресации
В IPv6 длина адреса расширена до 128 бит (против 32 в IPv4),
Что позволяет обеспечить больше уровней иерархии адресации, уве-
334
Гпава 4
личить число адресуемых узлов, упростить авто-конфигурацию ад.
ресов. Для расширения возможности мультикастинг-маршрутиза-
ции в адресное поле введено субполе «scope» (область адресов).
Определен новый тип адреса «anycast address» (эникастный), кото-
рый используется для работы с объединением серверов. Эникаст
адресация предназначена для использования с набором взаимодей-
ствующих серверов, чьи адреса не известны клиенту заранее.
• Спецификация формата заголовков
Некоторые поля заголовка IPv4 отбрасываются или делаются
опционными, уменьшая издержки обработки заголовков пакетов с
тем, чтобы уменьшить влияние расширения длины адресов в IPv6.
• Улучшенная поддержка расширений и опций
Изменение кодирования опций IP-заголовков позволяет облег-
чить переадресацию пакетов, ослабляет ограничения на длину оп-
ций, и делает более доступным введение дополнительных опций в
будущем.
• Возможность пометки потоков данных
Введена возможность помечать пакеты, принадлежащие опреде-
ленным транспортным потокам, для которых отправитель запросил
определенную процедуру обработки, например, нестандартный тип TOS
(вид услуг) или обработка данных в реальном масштабе времени.
• Идентификация и защита частных обменов
В IPv6 введена идентификация сетевых объектов или субъектов,
для обеспечения целостности данных и при желании защиты част-
ной информации.
Формат и семантика адресов IPv6 описаны в документе RFC-
1884. Версия ICMP IPv6 рассмотрена в RFC-1885.
7. Терминология
Узел — Оборудование, использующее IPv6.
Маршрутизатор — Узел, который переадресует пакеты IPv6, ко-
торые не адресованы ему непосредственно.
ЭВМ — Любой узел, который не является маршрутизатором.
Верхний уровень — Протокольный уровень, расположенный не-
посредственно поверх текущего. В качестве примеров можно привел
сти транспортные протоколы TCP и UDP, протокол управления ICMP,
маршрутные протоколы типа OSPF.
Канал — Средство коммуникации или среда, через которую узлы
могут взаимодействовать друг с другом на связном уровне, т.е., уро
вень непосредственно под IPv6. Примерами могут служить Ethernet;
РРР; Х.25, Frame Relay, или ATM; а также Интернет «туннели»*-
такие как туннели поверх IPv4 или IPv6. *
Сети передачи данных. Метод доступа 335
Соседи — Узлы, подключенные к общему каналу.
Интерфейс — Средство подключения узла к каналу.
Адрес — Идентификатор 1Ру6-уровня для интерфейса или набо-
ра интерфейсов.
Пакет — Заголовок и поле данных IPv6.
MTU канала — Максимальный размер пакета в канале
MTU пути — Минимальный MTU канала для пути от узла
источника до получателя.
Эникастный адрес — Идентификатор набора интерфейсов (обычно
принадлежащих разным узлам). Пакет, посланный по такому адре-
су, доставляется ближайшему интерфейсу (согласно метрике марш-
рутного протокола) из числа идентифицированных этим адресом.
2. Формат заголовка IPv6
Рис. 4.4.7.7.7. Формат заголовка пакета IPv6
Версия — 4-битовое поле кода номера версии протокола (версия
протокола для IPv6 = 6)
Приор. — 4-битный код приоритета %
Мешка потока — 24-битный код метки потока (для мультимедиа)
Размер поля данных — 16-битовое число без знака. Несет в себе
К0Д длины поля данных в октетах, которое следует сразу после
заголовка пакета. Если код равен нулю, то длина поля данных
записана в поле данных Jumbo, которое в свою очередь хранится в
зоне опций.
Следующий заголовок — 8-битовый разделитель. Идентифициру-
ет тип заголовка, который следует непосредственно за IPv6 заголов-
ком. Использует те же значения, что и протокол IPv4 [RFC-1700],
Предельное число шагов — 8-битовое целое число без знака,
меныпается на 1 в каждом узле, через который проходит пакет.
Ри предельном чйелк шагов, равном нулю, пакет удаляется.
336
Гпава 4
Адрес отправителя — 128-битовый адрес отправителя пакета.
См. RFC-1884.
Адрес получателя — 128-битовый адрес получателя пакета (воз-
можно не конечный получатель, если присутствует маршрутный за-
головок).
3. IP версия 6 архитектуры адресации
Существует три типа адресов:
Unicast: Идентификатор одиночного интерфейса. Пакет, послан-
ный по уникастному адресу, доставляется интерфейсу, указанному в
адресе.
Anycast: Идентификатор набора интерфейсов, принадлежащих
разным узлам. Пакет, посланный по эникастному адресу, доставля-
ется одному из интерфейсов, указанному в адресе (ближайший, в
соответствии с мерой, определенной протоколом маршрутизации).
Multicast: Идентификатор набора интерфейсов (обычно принад-
лежащих разным узлам). Пакет, посланный по мультикастинг-ад-
ресу, доставляется всем интерфейсам, заданным этим адресом.
В IPv6 не существует широковещательных адресов, их функции
переданы мультикастинг-адресам.
В IPv6, все нули и все единицы являются допустимыми кодами
для любых полей, если не оговорено исключение.
4. Модель адресации
IPv6 адреса всех типов ассоциируются с интерфейсами, а не уз-
лами. Так как каждый интерфейс принадлежит только одному узлу,
уникастный адрес интерфейса может идентифицировать узел.
Уникастный адрес соотносится только с одним интерфейсом.
Одному интерфейсу могут соответствовать много адресов различно-
го типа (уникастные, эникастные и мультикстные). Существует два
исключения из этого правила:
1) Одиночный адрес может приписываться нескольким физичес-
ким интерфейсам, если приложение рассматривает эти несколько
интерфейсов как единое целое при представлении его на уровне
Интернет.
2) Маршрутизаторы могут иметь при соединении точка-точка
ненумерованные интерфейсы (например, интерфейсу не присваивает-
ся никакого IPv6 адреса) для того, чтобы исключить необходи-
мость вручную конфигурировать и объявлять (advertise) эти адреса*
Адреса не нужны для соединений точка-точка маршрутизаторов, если
эти интерфейсы не используются в качестве точки отправления или^
назначения при посылке IPv6 дейтограмм.
Сеги передачи данных. Метод доступа 33 7
IPv6 соответствует модели IPv4, где субсеть ассоциируется с
каналом. Одному каналу могут соответствовать несколько субсетей.
4.1. Представление записи адресов
(текстовое представление адресов)
Существует три стандартные формы для представления IPv6 ад-
ресов в виде текстовых строк:
1. Основная форма имеет вид х:х:х:х:х:х:х:х, где “х” шестнад-
цатеричные 16-битовые числа.
Примеры:
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
1080:0:0:0:8:800:200С:417А
Заметьте, что ненужно писать начальные нули в каждом из
конкретных полей, но в каждом поле должна быть, по крайней мере,
одна цифра (за исключением случая, описанного в пункте 2).
2. Из-за метода записи некоторых типов IPv6 адресов, они часто
содержат длинные последовательности нулевых бит. Для того что-
бы сделать запись адресов, содержащих нулевые биты, более удоб-
ной, предусмотрен специальный синтаксис для удаления лишних
нулей. Использование записи «::» указывает на наличие групп из
16 нулевых бит. Комбинация «::» может появляться только при
записи адреса. Последовательность «::» может также использоваться
для удаления из записи начальных или завершающих нулей в ад-
ресе. Например:
1080:0:0:0:8:800:200С:417А уникаст-адрес
FF01:0:0:0:0:0:0:43 мультикаст адрес
0:0:0:0:0:0:0:1 адрес обратной связи
0:0:0:0:0:0:0:0 не специфицированный адрес
может быть представлено в виде:
1080::8:800:200С: 417 А уникаст-адрес
FF01: :43 мультикаст адрес
• • 1 адрес обратной связи
: ’ не специфицированный адрес
3. Альтернативной формой записи, которая более удобна при
Работе с IPv4 и IPv6, является x:x:x:x:x:x:d.d.d.d, где “х” шестнад-
цатеричные 16-битовые коды адреса, a “d” десятичные 8-битовые,
вставляющие младшую часть адреса (стандартное IPv4 представ-
Ление). Например:
ззв
Гпава 4
0:0:0:0:0:0:13.1.68.3
0:0:0:0:0:FFFF:129.144.52.38
или в сжатом виде:
::13.1.68.3
::FFFF:129.144.52.38
4.2. Представление типа адреса
Специфический тип адресов IPv6 идентифицируется лидирую-
щими битами адреса. Поле переменной длины, содержащее эти ли-
дирующие биты, называется префиксом формата (Format Prefix —
FP). Исходное назначение этих префиксов следующее (табл. 4.4.1.1):
Таблица 4.4ЛЛ
Назначение Префикс (двоичный) Часть адресного пространства
Зарезервировано 0000 0000 1/256
Не определено 0000 0001 1/256
Зарезервировано для NSAP 0000 001 1/128
Зарезервировано для IPX 0000 010 1/128
Не определено 0000 011 1/128
Не определено 0000 1 1/32
Не определено 0001 1/16
Не определено 001 1/8
Провайдерские уникаст- адреса 010 1/8
Не определено 011 1/8
Зарезервировано для географических уникаст- адресов 100 1/8
Не определено 101 1/8
Не определено 110 1/8
Не определено 1110 1/16
Не определено 1111 0 1/32
Не определено 1111 10 1/64
Не определено 1111 110 1/128
Не определено 1111 11100 1/512
Локальные канальные адреса 1111 1110 10 1/1024
Локальные адреса (Site) 1111 1110 и 1/1024
Мультикаст-адреса 1111 1111 1/256
Замечание: Не специфицированные адреса, адреса обратной свя-
зи и IPv6 адреса со встроенными IPv4 адресами, определены вне
префиксного пространства “0000 0000”.
Сети передачи данных. Метод доступа 339
Данное распределение адресов поддерживает прямое выделение
адресов провайдера, адресов локального применения и мультикас-
тинг-адресов. Зарезервировано место для адресов NSAP, IPX и гео-
графических адресов. Оставшаяся часть адресного пространства за-
резервирована для будущего использования. Эти адреса могут ис-
пользоваться для расширения имеющихся возможностей (например,
дополнительных адресов провайдеров и т.д.) или новых приложе-
ний (например, отдельные локаторы и идентификаторы).
Уникастные адреса отличаются от мультикастных значением
старшего октета: значение FF (11111111) идентифицирует мульти-
кастинг-адрес; любые другие значения говорят о том, что адрес уни-
кастный. Эникастные (anycast) адреса берутся из уникастного про-
странства, и синтаксически неотличимы от них.
4.3. Уникастные адреса
Уникастные адреса IPv6, сходны с традиционными IPv4 адреса-
ми при бесклассовой междоменной маршрутизации (Class-less
Interdomain Routing — CIDR).
Существует несколько форм присвоения уникастных адресов в
IPv6, включая глобальный уникастный адрес провайдера (global
provider based), географический уникастный адрес, NSAP-адрес, иерар-
хический адрес IPX, адрес локального использования (site-lpcal-use),
адрес канала локального применения (link-local-use) и адрес, совме-
стимый с IPv4 (IPv4-campatible). В будущем могут быть определены
дополнительные типы адресов.
Узлы IPv6 могут иметь существенную или малую информацию о
внутренней структуре IPv6 адресов, в зависимости от выполняемой
узлом роли, (например, ЭВМ или маршрутизатор). Как минимум,
узел может считать, что уникастный адрес (включая его собствен-
ный адрес) не имеет никакой внутренней структуры. То есть пред-
ставляет собой 128 битовый неструктурированный образ.
ЭВМ может дополнительно знать о префиксе субсети для кана-
лов, с которыми она соединена, где различные адреса могут иметь
разные значения п:
N бит
128-N бит
Префикс субсети
Интерфейс ID
Рис. 4.4.1.1.2
340
Гпава 4
ЭВМ могут использовать и другие иерархические границы в уни-
кастном адресе. Хотя простейшие маршрутизаторы могут не знать
о внутренней структуре IPv6 уникастных адресов, маршрутизаторы
должны знать об одной или более иерархических границах для
обеспечения работы протоколов маршрутизации. Известные грани-
цы для разных маршрутизаторов могут отличаться и зависят от
того, какое положение занимает данный прибор в иерархии марш-
рутизации.
4.3.7. Примеры уникастных адресов
Примером уникастного адресного формата, который является
стандартным для локальных сетей и других случаев, где примени-
мы МАС адреса, может служить:
п бит 80-п бит 48 бит
Префикс подписчика ID-субсети Интерфейс ID
Рис. 4.4.1.1.3
Где 48-битовый идентификатор интерфейса представляет собой
IEEE-802 МАС адрес. Использование IEEE 802 МАС адресов в каче-
стве идентификаторов интерфейсов является стандартным для сре-
ды, где узлы имеют такие адреса. В других средах, где IEEE 802
МАС адреса не доступны, в качестве идентификаторов интерфейсов
могут использоваться другие типы адресов связного уровня, такие
как адреса Е.164.
Включение уникального глобального идентификатора интерфейса
типа МАС адреса, делает возможным очень простую форму авто-
конфигурации адресов. Узел может узнать идентификатор субсети,
получая информацию от маршрутизатора в виде сообщений опове-
щения, которые маршрутизатор посылает связанным с ним партне-
рам, и затем сформировать IPv6 адрес для себя, используя IEEE
МАС адрес в качестве идентификатора интерфейса для данной суб-
сети.
Другой формат уникастного адреса относится к случаю, когда
локальная сеть или организация нуждаются в дополнительных уров-
нях иерархии. В этом примере идентификатор субсети делится на
идентификатор области и идентификатор субсети. Формат такого
адреса имеет вид:
Сеги передачи данных. Метод доступа
341
s бит п бит m бит 128-s-n-m бит
Префикс подписчика ID области ID-субсети Интерфейс ID
Рис. 4.4.1.1.4
Допускается использование идентификатора интерфейса ко-
роче 48-разрядного МАС-адреса, с тем, чтобы оставить больше места
для полей, характеризующих уровни иерархии. Это могут быть иден-
тификаторы интерфейсов, сформированные администрацией локаль-
ной сети или организации.
4.4. Не специфицированный адрес
Адрес 0:0:0:0:0:0:0:0 называется не специфицированным адре-
сом. Он не должен присваиваться какому-либо узлу. Этот адрес
указывает на отсутствие адреса. Примером использования такого
адреса может служить поле адреса отправителя любой дейтограммы
IPv6, посланной инициализируемой ЭВМ до того, как она узнала
свой IP-адрес.
Не специфицированный адрес не должен использоваться в каче-
стве указателя места назначения дейтограмм IPv6 или в IPv6 заго-
ловках маршрутизации.
4.5. Адрес обратной связи
Уникастный адрес 0:0:0:0:0:0:0:1 называется адресом обрат-
ной связи. Он может использоваться сетевым объектом для посыл-
ки IPv6 дейтограмм самому себе. Его нельзя использовать в каче-
стве идентификатора интерфейса.
Адрес обратной связи не должен применяться в качестве адреса
отправителя в IPv6 дейтограммах, которые посылаются за пределы
узла.
4.6, IPv6 адреса с вложенными IPv4 адресами
Алгоритмы IPv6 включают в себя механизмы ЭВМ и маршрути-
заторов по организации туннелей для IPv6 пакетов через маршрут-
нУю инфраструктуру IPv4. Узлам IPv6, которые используют этот
МетоД> присваиваются специальные IPv6 уникастные адреса, кото-
рое в младших 32 битах содержат адрес IPv4. Этот тип адреса
взывается «IPv4-compatible IPv6 address» и имеет формат, изобра-
женный на рис. 4.4.1.1.5:
342 Гпава 4
80 бит 16 32 бита
0000 0000 0000 IPv4 адрес
_ Рис. 4.4.1.7.5
Определен и второй тип 1Ру6-адреса, который содержит внутри
IPv4 адрес. Этот адрес используется для представления IPv6 адре-
сов узлам IPv4 (тем, что не поддерживают IPv6). Этот тип адреса
называется «IPv4-mapped IPv6 address» и имеет формат показан-
ный на рис. 4.4.1.1.6:
80 бит 16 32 бита
0000 0000 FFFF IPv4 адрес
Рис. 4.4.1.1.6
4.7. NSAP адреса
Соответствие NSAP адреса IPve-адресам выглядит следующим
образом (рис. 4.4.1.1.7):
7 бит 121 бит
0000001 Не определено
Рис. 4.4.1.1.7
4.8. IPX Адреса
Соответствие IPX и IPv6 адресов показано ниже на рис. 4.4.1.1.8:*
7 бит 121 бит
0000010 Не определено
Рис. 4.4.1.1.8
СеТИ передачи данных. Метод доступа
343
4.9. Провайдерские глобальные уникаст-адреса
Глобальный уникаст-адрес провайдера имеет назначение, опи-
санное в [ALLOC]. Исходное назначение этих уникаст-адресов ана-
логично функции IPv4 адресов в схеме CIDR [см. CIDR]. Глобаль-
ный IPv6 уникаст-адрес провайдера имеет формат, отображенный
ниже на рис. 4.4.1.1.9:
3 п бит m бит о бит 125-s-n-o бит
010 ID регистрации ID-провайдера ID-подписчика Интра подписчик
Рис. 4.4.1.1.9. Гповальный адрес провайдера
Старшая часть адреса предназначена для определения того, кто
определяет часть адреса провайдера, подписчика и т.д.
Идентификатор регистрации определяет регистратора, который
задает провайдерскую часть адреса. Термин «префикс регистрации»
относится к старшей части адреса, включая поле идентификатор
регистрации (ID).
Идентификатор провайдера задает специфического провайдера,
который определяет часть адреса подписчика. Термин «префикс про-
вайдера» относится к старшей части адреса, включая идентифика-
тора провайдера.
Идентификатор подписчика позволяет разделись подписчиков,
подключенных к одному и тому же провайдеру. Термин «префикс
подписчика» относится к старшей части адреса, включая идентифи-
катор подписчика.
Часть адреса интра-подписчик определяется подписчиком и орга-
низована согласно местной топологии Интернет подписчика. Воз-
можно, что несколько подписчиков пожелают использовать область
адреса интра-подписчик для одной и той же субсети и интерфейса.
В этом случае идентификатор субсети определяет специфический
Физический канал, а идентификатор интерфейса — определенный
интерфейс субсети.
4-10. Локальные уникаст-адреса IPv6
Существует два типа уникастных адресов локального использо-
Вания. Имеются локальные адреса сети и канала. Локальный адрес
Канала предназначен для работы с одним каналом, а локальный ад-
сети — с одной локальной сетью (site). Глобальный уникаст-адрес
пРовайдера имеет формат, отображенный ниже на рис. 4.4.1.1.10:
344
Гпава 4
Ю бит
1111111010
118-п бит
ID-интерфейса
Рис. 4.4.7.7.70. Локальный адрес канала
Локальные адреса канала предназначены для обращения через
определенный канал, например, для целей авто-конфигурации, поис-
ка соседей или в случае отсутствия маршрутизатора. Маршрутиза*
торы не должны переадресовывать пакеты с локальными адресами
отправителя. Локальный адрес сети имеет формат, показанный на
рис. 4.4.1.1.11:
10 бит п бит m бит 118-n-m бит
1111111011 • 0 ID субсети ID интерфейса
Рис. 4.4.1.1.11. Локальный адрес сети
Локальные адреса сети могут использоваться для локальных
сетей или организаций, которые (пока еще) не подключены к гло-
бальному Интернет. Им не нужно запрашивать или*«красть» пре-
фикс адреса из глобального адресного пространства Интернет. Вме-
сто этого можно использовать локальный адрес сети IPv6. Когда
организация соединяется с глобальным Интернет, она может сфор-
мировать глобальные адреса путем замещения локального префик-
са сети префиксом подписчика.
4.77. Эникаст-адреса
Эникаст-адрес IPv6 является адресом, который приписан несколь-
ким интерфейсам, обычно принадлежащим разным узлам, при этом,
пакет, посланный по эникастному адресу, будет доставлен ближай-
шему интерфейсу в соответствии с метрикой протокола маршрути-
зации.
Эникастные адреса выделяются из уникастного адресного про*
странства, и используют один из известных уникастных форматов*
Таким образом, эникастные адреса синтаксически неотличимы от
уникастных адресов. Когда уникастный адрес приписан более чвМ
одному интерфейсу, он превращается в эникастный адрес и узЛЫ»
которым он приписан, должны быть сконфигурированы так, чтобь*
распознавать этот адрес.
Сети передачи данных. Метод доступа 34 5
Для любого эникастного адреса существует адресный префикс Р,
который определяет топологическую область, где находятся все соот-
ветствующие ему интерфейсы. В пределах области, заданной Р, каж-
дый член эникастной (anycast) группы должен быть объявлен, как
отдельный вход в маршрутной системе. Вне области Р, эникастный
адрес может быть занесен в маршрутную запись для префикса Р.
Заметим, что в худшем случае префикс Р эникастной группы
(anycast set) может быть нулевым, т.е., члены группы могут не иметь
никакой топологической локальности. В этом случае эникастный
адрес должен объявляться как отдельная маршрутная единица
(separate routing entry) по всему Интернет, что представляет собой
серьезное ограничение, так как число таких «глобальных» эникаст-
ных адресов не может быть большим.
Одним ожидаемым приложением эникастных адресов является
идентификация набора маршрутизаторов, принадлежащих сервис-
провайдеру. Такие адреса в маршрутном заголовке IPv6 могут ис-
пользоваться в качестве промежуточных, чтобы обеспечить достав-
ку пакета через определенного провайдера или последовательность
провайдеров. Другим возможным приложением может стать иден-
тификация набора маршрутизаторов, связанных с определенной суб-
сетью, или набора маршрутизаторов, обеспечивающих доступ в опре-
деленный домен.
Существует ограниченный опыт широкого применения эникаст-
ных Интернет адресов, некоторые возможные осложнения и трудно-
сти рассмотрены в [ANYCST]. Существуют следующие ограничения
при использовании эникастных IPv6 адресов:
• Эникастный адрес не может использоваться в качестве адреса
отправителя в IPv6 пакете.
• Эникастный адрес не может быть приписан ЭВМ, таким обра-
зом, он может принадлежать только маршрутизатору.
4 Л1Л. Необходимые эникаст-адреса
Эникаст-адрес маршрутизатора субсети предопределен и имеет
Формат, отображенный на рис. 4.4.1.1.12:
п бит 128-п бит
Префикс субсети 0000000000000000
₽Ис- 4.4ЛЛЛ2. Формат эникаст-адреса маршрутизатора субсети
346
Гпава 4
Префикс субсети в эникастном адресе является префиксом
который идентифицирует определенный канал. Этот эникастный
адрес является синтаксически идентичным уникастному адресу для
интерфейса канала с идентификатором интерфейса равным нулю.
Пакеты, посланные маршрутизатору субсети с эникастным
адресом, будут доставлены одному маршрутизатору субсети. При этом
все маршрутизаторы субсети должны поддерживать работу с эника-
стными адресами.
Эникастный адрес маршрутизатора субсети предполагается
использовать в приложениях, где необходимо взаимодействовать с
одним из совокупности маршрутизаторов удаленной субсети. На-.
пример, когда мобильный хост хочет взаимодействовать с однимч
мобильным агентом в его «домашней» субсети.
4 Л 2. Мульткаст-адреса
Мультикастинг-адрес IPv6 является идентификатором для груп-
пы узлов. Узел может принадлежать к любому числу мультикас-
тинг групп. Мультикастинг-адреса имеют следующий формат (рис1.
4.4.1.1.13):
8 бит 4 бита 4 бита 112 бит '
11111111 Флаги Scope Идентификатор группы
Рис. 4.4.1.1.13
11111111b начале адреса идентифицирует адрес, как мультика-
тинг-адрес.
Флаги - набор из 4 флагов
0 0 0 Т
Рис. 4.4.1.1.14
Старшие 3 флага зарезервированы и должны быть обнулены.
Т = 0 указывает на то, что адрес является стандартным («well-
known») мультикастным, официально выделенным для глобально-
го использования в Интернет.
Т = 1 указывает, что данный мультикастинг-адрес присвоен вре-
менно («transient»).
Поле scope представляет собой 4-битовый код мультикастинге,
предназначенный для определения предельной области действий
мультикастинг-группы. Допустимые значения:
347
Сети передачи данных. Метод доступа
О зарезервировано
Область действия ограничена локальным узлом
2 Область действия ограничена локальным каналом
3 (не определено)
4 (не определено)
5 Область действия ограничена локальной сетью
6 (не определено)
7 (не определено)
8 Область действия ограничена локальной организацией
9 (не определено)
А (не определено)
В (не определено)
С (не определено)
D (не определено)
Е глобальные пределы (global scope)
F зарезервировано '
Идентификатор группы, в пределах заданной области (scope)
определяет мультикастинг-группу, постоянную или переходную
(transient).
Значение постоянно присвоенного мультикастинг-адреса не за-
висит от значения поля scope. Например, если «NTP servers group»
присвоен постоянный мультикастинг адрес с идентификатором груп-
пы 43 (hex), тогда:
FF01:0:0:0:0:0:0:43
FF02:0:0:0:0:0:0:43
FF05:0:0:0:0:0:0:43
FF0E:0:0:0:0:0:0:43
означает, что все NTP серверы одного и
того же узла рассматриваются как
отправители.
означает, что все NTP серверы работают
с тем же каналом, что и отправитель,
означает, что все NTP серверы принад-
лежат той же сети, что и отправитель,
означает, что все NTP серверы находят-
ся в Интернет.
Непостоянно выделенные мультикаст-адреса имеют значение
только в пределах данной области (scope). Например, группа, опре-
деленная непостоянным локальным мультикаст-адресом
*15:0:0:0:0:0:0:43, не имеет никакого смысла для другой локаль-
«ои сети или непостоянной группы, использующей тот же группо-
в°й идентификатор с другим значением поля scope, или для посто-
ЯНн°й группы с тем же групповым ID.
348
Гпава 4
Мультикастинг адреса не должны использоваться в качестве ад,
реса отправителя в IPv6 дейтограммах или встречаться в любых
заголовках маршрутизации.
4.12.1. Предопределенные мультикаст-адреса
Приведенные ниже мультикаст-адреса являются зарезервирован-
ными (предопределенными):
FF00:0:0:0:0:0:0:0; FF01:0:0:0:0:0:0:0; FF02:0:0:0:0:0:0:0;
FF03:0:0:0:0:0:0:Q; FF04:0:0:0:0:0:0:0; FF05:0:0:0:0:0:0:0;
FF06:0:0:0:0:0:0:0; FF07:0:0:0:0:0:0:0; FF08:0:0:0:0:0:0:0;
FF09:0:0:0:0:0:0:0; FF0A:0:0:0:0:0:0:0; FFOB:0:0:0:0:0:0:0;
FFOC:O:O:O:O:O:O:O; FF0D:0:0:0:0:0:0:0; FFOE:0:0:0:0:0:0:0;
FF0F:0:0:0:0:0:0:0
Перечисленные выше мультикаст-адреса зарезервированы и не'
будут присваиваться каким-либо мультикаст-группам. Адреса для
обращения ко всем узлам:
FF01:0:0:0:0:0:0:l
FF02:0:0:0:0:0:0:l
Приведенные выше адреса идентифицируют группу, включаю;
щую в себя все IPv6 узлы в пределах группы 1 (локальные узлы)
или 2 (локально связанные узлы).
Адреса всех маршрутизаторов: FF01:0:0:0:0:0:0:2 и
FF02:0:0:0:0:0:0:2
Приведенные выше, мультикаст-адреса идентифицируют группу
всех IPv6 маршрутизаторов в пределах области 1 (локальные узлы)
или 2 (локально связанные узлы).
DHCP Server/Relay-Agent: FF02:0:0:0:0:0:0:C
Приведенные выше мультикастинг адреса идентифицируют группу
всех IPv6 DHCP серверов и транзитных агентов в пределах области,
(scope) 2 (локальный канал).
Адрес запрашиваемого узла (SoHdted-Node): FF02:0:0:0:0:1 :ХХХХ:ХХХХ
Приведенный выше мультикаст-адрес вычислен как функция
уникастного и эникастного адресов узла. Мультикаст-адрес заП*
рашиваемого узла (solicited-node) сформирован из младших 32
бит адреса (уникастного или эникастного) добавлением 96 бит-
ного префикса FF02:0:0:0:0:l. В результате получен мультика*5'
Сети передачи данных. Метод доступа 349
инг адрес, охватывающий интервал: от FF02:0:0:0:0:1:0000:0000
до FF02:0:0:0:0:l:FFFF:FFFF.
Например, код мультикаст-адреса запрашиваемого узла (solicited
node), соответствующий IPv6 адресу 4037::01:800:200Е:8С6С, ра-
вен FF02::l:200E:8C6C. IPv6 адреса, которые отличаются только
старшими разрядами, например, из-за множественных старших пре-
фиксов, соответствующих разным провайдерам, будут совпадать с
адресом запрашиваемого узла, что сокращает число мультикаст-
групп, к которым узел должен присоединиться.
4.13. Необходимые адреса узлов
ЭВМ должна распознавать следующие адреса, как обращенные к ней:
Ее локальный адрес канала для каждого из интерфейсов
Выделенные уникаст-адреса
Адрес обратной связи
Мультикастинг-адрес для обращения ко всем узлам
Мультикастинг-адрес запрашиваемого узла (Solicited-Node
Multicast Address) для каждого из приписанных ему уникаст и
эникастных адресов
Мультикаст-адреса всех групп, к которым принадлежит ЭВМ.
Маршрутизатор должен распознавать следующие адреса:
Его локальный адрес канала для каждого из интерфейсов
Выделенные уникаст-адреса
Адрес обратной связи
Эникастные адреса маршрутизатора субсети каналов, для
которых он имеет интерфейсы.
Все другие эникастные адреса, которые использовались при
маршрутизации маршрутизатора.
Мультикастинг-адрес для обращения ко всем узлам
Мультикастинг-адрес для обращения ко всем маршрутизато-
рам
Мультикаст-адрес запрашиваемого узла (Solicited-Node Multicast
Address) для каждого приписанного ему уникаст и эникастного
адресов.
Мультикастные адреса всех прочих групп, принадлежащих
маршрутизатору.
Приложение должно предопределить только следующие адрес-
НЬ1е префиксы:
350
Гпава 4
Не специфицированный адрес
Адрес обратной связи
Мультикаст-префикс (FF)
Локально используемые префиксы (Link-Local и Site-Local)
Предопределенные мультикаст-адреса
Префиксы, совместимые с IPv4
Приложения должны считать все остальные адреса уникастньь
ми, если противоположное не оговорено при конфигурации (напри- w
мер, эникастные адреса).
5. Заголовки расширения IPv6
В IPv6, опционная информация уровня Интернет записывается в
отдельных заголовках, которые могут быть помещены между IPv6
заголовком и заголовком верхнего уровня пакета. Существует не-
большое число таких заголовков, каждый задается определенным
значением кода поля следующий заголовок. В настоящее время
определены заголовки: маршрутизации, фрагментации, аутентифи-
кации, инкапсуляции, опций Нор-Ьу-Нор, места назначения и отсут-
ствия следующего заголовка. Как показано в примерах ниже, IPv6
пакет может нести нуль, один или более заголовков расширения,
каждый задается предыдущим полем следующий заголовок (рис.
4.4.1.1.15):
IPv6 заголовок.
Следующий
заголовок = TCP
TCP- заголовок + даннь'ю
IPv6 заголовок. Следующий заголовок = Routing Заголовок маршрута. Следующий заголовок = TCP TCP-заголовок + данные
IPv6 заголовок Следующий . заголовок = Routing Заголовок маршрута. Следующий заголовок = Fragment Заголовок фрагмента Следующий заголовок = TCP TCP заголовок фрагмента + данные
Рис. 4.4.7.7.7 5. Структура вложения пакетов для IPv6
Заголовки расширения не рассматриваются и не обрабатывают-
ся узлами по пути доставки. Содержимое и семантика каждого за-
головка расширения определяет, следует или нет обрабатывать ел?
дующий заголовок. Следовательно, заголовки расширения должна
обрабатываться строго в порядке их выкладки в пакете. Полу^а*
дети передачи данных. Метод доступа 351
—
тель, например, не должен просматривать пакет, искать определен-
ный тип заголовка расширения и обрабатывать его до обработки
предыдущих заголовков.
Единственное исключение из этого правила касается заголовка
опций Нор-Ьу-Нор, несущего в себе информацию, которая должна
быть рассмотрена и обработана каждым узлом по пути доставки,
включая отправителя и получателя. Заголовок опций Нор-Ьу-Нор,
если он присутствует, должен следовать непосредственно сразу пос-
ле 1Ру6-заголовка. Его присутствие отмечается записью нуля в
поле следующий заголовок заголовка IPv6.
Если в результате обработки заголовка узлу необходимо перей-
ти к следующему заголовку, а код поля следующий заголовок не
распознается, необходимо игнорировать данный пакет и послать со-
ответствующее сообщение ICMP (Parameter Problem message) от-
правителю пакета. Это сообщение должно содержать код ICMP = 2
(«unrecognized Next Header type encountered» — встретился нерас-
познаваемый тип следующего заголовка) и поле-указатель на не
распознанное место в пакете. Аналогичные действия следует пред-
принять, если узел встретил код следующего заголовка равный нулю
в заголовке, отличном от 1Ру6-заголовка.
Каждый заголовок расширения имеет длину кратную 8 окте-
там. Многооктетные поля в заголовке расширения выравниваются
в соответствии с их естественными границами, т.е., поля с шириной
в п октетов помещаются в п октетов, начиная с начала заголовка,
для n = 1, 2, 4 или 8.
IPv6 включает в себя следующие заголовки расширения:
Опции Нор-Ьу-Нор
Маршрутизация (Routing; тип 0)
Фрагмент
Опции места назначения
Проверка прав доступа (Authentication)
Поле безопасных вложений (Encapsulating Security Payload)
Последние два описаны в RFC-1826 и RFC-1827.
Порядок заголовков расширения
Когда используется более одного заголовков расширения в од-
ном пакете, рекомендуется помещать их в следующем порядке:
IPv6 заголовок
Заголовок опций Нор-Ьу-Нор
Заголовок опций места назначения (Destination Options header, (1))
352 Гпава 4"
Заголовок маршрутизации
Заголовок фрагмента
Заголовок Authentication (2)
Заголовок безопасных вложений (Encapsulating Security Payload, (2))
Заголовок опций места назначения (Destination Options header (3))
Заголовок верхнего уровня.
(1) Для опций, которые должны обрабатываться по адресу, ука-
занному в поле адрес получателя IPv6, и во всех узлах, перечислен*
ных в заголовке маршрутизации.
(2) Дополнительные рекомендации относительно порядка зато*
ловков аутентификации и безопасных вложений приведены в RFC-
1827.
(3) Для опций, которые должны обрабатываться при достиже-
нии пакетом конечной точки маршрута.
Каждый заголовок расширения должен встречаться не более одно-
го раза, исключение представляет собой заголовок опций места на-
значения, который должен быть представлен дважды (один раз пе-
ред заголовком маршрутизации и второй раз перед заголовком вер-
хнего уровня).
Если заголовок верхнего уровня представляет собой еще один
IPv6 заголовок (в случае туннелирования или инкапсуляции в IPv6),
за ним может следовать его собственный заголовок расширения.
Узлы IPv6 должны принимать и пытаться обработать заголов-
ки расширения в любом порядке, встречающиеся любое число раз в
пределах одного пакета, за исключением заголовка опций типа Нор-
by-Нор, который может появляться только непосредственно за IPv6
заголовком.
6. Опции
Два из определенных в настоящее время заголовков расшире-
ния — заголовок опций Нор-Ьу-Нор и заголовок опций места на-
значения — несут в себе переменное число TLV-кодированных (type-
length-value) опций следующего формата (Рис. 4.4.1.1.16):
Тип опции Длина опции Данные опции
Рис. 4.4.1.1.16 Формат опций
Сети передачи данных. Метод доступа 353
Tun опции — 8-битовый идентификатор типа опции.
Длина опции — 8-битовое целое число без знака. Длина поля
данных опции в октетах.
Данные опции — Поле переменной длины. Данные зависят от
ffiuna опции.
Последовательность опций в заголовке должна обрабатываться
строго в соответствии с их порядком записи.
Идентификаторы типа опций кодируются так, что их старшие
два бита характеризуют операцию, которая должна быть выполне-
на. Если узел не узнает тип опции:
00 Обойти эту опцию и продолжить обработку заголовка.
01 Выбросить данный пакет.
10 Выбросить данный пакет и вне зависимости от того, яв-
ляется ли адрес назначения мультикастинговым, послать отправи-
телю ICMP-пакет с кодом Parameter Problem (код=2), с указателем
на не узнанный код опции.
11 Выбросить данный пакет и, если адрес места назначения
не мультикастинговый, послать отправителю ICMP-пакет с кодом
Parameter Problem (код=2) и с указателем на не узнанный код опции.
Третий старший бит типа опции определяет, может ли информа-
ция в поле опция поменять место назначения пакета (переадресо-
вать его). Когда в пакете присутствует заголовок идентификации
(Authentication), информация, которая может изменить маршрут, дол-
жна рассматриваться как нулевой октет при определении значения
идентификации. Значения бита имеют следующие значения.
О — Данные опции не меняют маршрута
1 — Информация опции может изменить маршрут.
Отдельные опции могут требовать определенного выравнивания
с тем, чтобы обеспечить выкладку мультиоктетного значения дан-
ных поля опции. Требование выравнивания опции описывается с
помощью выражения xn+у, означающего, что поле тип опции дол-
жно находиться через целое число, кратное х октетам плюс у окте-
тов (отсчет от начала заголовка). Например:
2п — означает любое двухоктетное смещение от начала заголовка.
8п+2 — означает любое 8-октетное смещение от начала заго-
л°вка плюс 2 октета.
Вак. Na 343Q Семенов
354
Гпава 4
Существует две опции заполнения, которые используются, когда
необходимо выровнять последующие опции и вывести границу за-
головка на значение кратное 8 октетам. Эти заполняющие опции
должны распознаваться всеми приложениями IPv6:
Опция Padl (выравнивание не требуется)
Опция Padl используется для введения одного октета заполните-
ля в зону опций заголовка. Если требуется более одного октета, ис-
пользуется опция PadN. Опция PadN (выравнивание не требуется)
1 Opt Data Len Option Data
Рис. 4.4.7.7.77
Опция PadN используется для введения двух и более октетов
заполнителей в поле опций заголовка. Для N октетов заполнителя
поле Opt Data Len содержит значение N-2, а поле данных опции
состоит из N-2 нулевых октетов
В. 7. Опции заголовка Нор-Ьу-Нор (шаг за шагом!
Заголовок опций Нор-Ьу-Нор используется для опционной ин-
формации, которая просматривается каждым узлом по пути дос-
тавки. Заголовок опций Нор-Ьу-Нор идентифицируется кодом поля
следующий заголовок 0 в IPv6 заголовке и имеет формат (рис.
4.4.1.1.18):
Следующий заголовок Hdr Ext Len
Опции *
Рис. 4.4.1.1.78. Формат заголовка опций Нор-Ьу-Нор
Следующий заголовок — 8-битовый селектор. Определяет тип
заголовка, который следует непосредственно за заголовком опций
Нор-Ьу-Нор. Использует те же значения поля протоколов, что и
IPv4 [RFC-1700]
Hdr Ext Len — 8-битовое число без знака. Длина заголовка
поля опций Нор-Ьу-Нор в октетах, исключая первые 8 октетов.
Опции — поле переменной длины. Содержит один или более
TLV-закодированных опций.
Сети передачи данных. Метод доступа
355
В дополнение к Padl и PadN опциям определены следующие
опции hop-by-hop:
Опция Jumbo Payload — (необходимо выравнивание: 4п + 2)
194 Opt Data Len=4
I Длина (“длинного") поля данных
Рис. 4.4.1.1.19.
Опция Jumbo Payload (большое поле данных) используется для
посылки пакетов IPv6 с полем данных, превосходящим 65535 ок-
тетов. Длина Jumbo Payload характеризует длину пакета в октетах,
исключая заголовок IPv6, но включая заголовок опций Нор-Ьу-Нор.
Это поле должно содержать код превосходящий 65535. Если полу-
чен пакет с опцией Jumbo Payload, содержащей код длины меньше
или равный 65535, посылается сообщение ICMP (Parameter Problem,
код 0) с указателем на старший октет поля длины Jumbo Payload.
Поле длины тюля данных заголовка IPv6 должно быть равно
нулю для каждого пакета с опцией Jumbo Pay load. Если получен
пакет с корректным значением опции J umbo Payload и ненулевым
кодом длины поля данных заголовка IPv6, посылается сообщение
ICMP (Parameter Problem код 0) с указателем на поле тип опции.
Опция Jumbo Payload не может использоваться в пакетах, кото-
рые несут в себе заголовок фрагмента. Если заголовок фрагмента
встретится в пакете, содержащем корректную опцию Jumbo Payload,
посылается сообщение ICMP (Parameter Problem, код 0) с указате-
лем на первый октет заголовка фрагмента.
Приложения, которые не поддерживают опцию Jumbo Payload,
не могут иметь интерфейсы для каналов с MTU больше 65575 (40
октетов IPv6 заголовка плюс 65535 октетов данных).
7. Маршрутный заголовок
Заголовок маршрутизации используется отправителем, чтобы
заставить пакет посетить один или более промежуточных узлов на
пУти к месту>назначения. Эта функция схожа с опцией принуди-
тельной маршрутизации в протоколе IPv4. Заголовок маршрутиза-
ции идентифицируется кодом 43 поля следующий заголовок пре-
дыдущего заголовка и имеет формат (Рис. 4.4.1.1.20):
Следующий заголовок 8-битовый селектор. Определяет тип
Заг°ловка, который следует непосредственно за заголовком маршру-
тизации. Использует те же коды протоколов, что и IPv4 [RFC-1700].
12*
356
Следующий заголовок Hdr Ext Len Тип маршрутизации Оставшиеся сегменты
Поле данных, зависящее от типа
Рис. 4.4.1.1.20. Формат заголовка маршрутизации
Hdr Ext Len — 8-битовое целое без знака. Длина заголовка’
маршрутизации выражается в 8-октетных блоках, и не включает в
себя первые 8 октетов.
Тип маршрутизации — 8-битовый идентификатор конкретного
варианта маршрутизации '
Оставшиеся сегменты — 8-битовое число без знака. Число оста-
ющихся сегментов пути, т.е. число промежуточных узлов, которые
должны быть посещены пакетом по пути к месту назначения.
Данные, зависящие от типа — Поле переменной длины, формат
зависит от кода поля шип маршрутизации, а длина определяется
заголовком маршрутизации и кратна 8 октетам.
Если в процессе обработки входного пакета встретится заголо-
вок маршрутизации с не узнанным полем тип маршрутизации, то
поведение узла зависит от содержимого поля число оставшихся
сегментов пути.
Если число оставшихся сегментов пути равно нулю, узел должен
проигнорировать заголовок маршрутизации и продолжить работу
со следующим заголовком, чей тип указан в поле следующий заго-
ловок заголовка маршрутизации.
Если число оставшихся сегментов пути не равно нулю, узел дол-
жен выбросить пакет и послать сообщение ICMP (Parameter Problem,
код 0) с указателем на поле не узнанного типа маршрутизаций.
Заголовок маршрутизации типа 0 имеет следующий формат (рис.
4.4.1.1.20А): "
Следующий заголовок — 8-битовый селектор .v Идентифицирует
тип заголовка, следующего непосредственно за заголовком маршрУ*
тизации. Использует те же коды протоколов, что и IPv4 [RFC-1700]-
Hdr Ext Len — 8-битовое целое без знака. Длина заголовка
маршрутизации в 8-октетных блоках, исключая первые 8 октетов-
Для заголовков маршрутизации типа 0 значение Hdr Ext Len равно
удвоенному числу адресов в заголовке, должно быть четным чис-
лом меньше или равным 46.
Сети передачи данных. Метод доступа 35 7
Следующий заголовок Hdr Ext Len Тип | Оставшиеся маршрутизации =0 | сегменты
Резерв Strict/Loose Bit Map
Адрес [1] 4
Адрес [2]
• ••••••'
Адрес [N]
Рис. 4.4.1.1.20А. Формат заголовка маршрутизации типа О
Tun маршрутизации — 0.
Оставшиеся сегменты — 8-битовое целое без знака. Число ос-
тавшихся сегментов пути, т.е., число узлов, которые следует посетить
на пути к месту назначения. Максимально допустимое число = 23
Резерв — 8-битовое поле резерва. Инициализируется нулем при
передаче и игнорируется при приеме.
Strict/Loose Bit Map — 24-битовый код-маска, биты пронумеро-
ваны, начиная с 0 до 23, слева направо. Для каждого из сегментов
пути указывается, должен ли следующий узел быть соседом: 1 озна-
чает strict (должен быть соседом), 0 означает пропустить (не должен
быть соседом).
Adpec[ 1..п] — Вектор 128-битовых адресов, пронумерованных с
1 до и.
Мультикастинг-адреса не должны встречаться в заголовке мар-
шрутизации типа 0, или в поле места назначения пакета, несущего в
себе этот заголовок.
Если бит 0 поля Strict/Loose Bit Мар имеет значение 1, поле
адреса места назначения заголовка в исходном пакете должно иден-
тифицировать соседа. Если бит 0 имеет значение 0, отправитель
может использовать любой легальный не мультикастинговый адрес
в качестве адреса места назначения.
Биты с номерами более п, где п — число адресов в заголовке
маршрутизации, должны обнуляться отправителем и игнорироваться
получателем.
Заголовок маршрутизации не рассматривается и не анализиру-
ется до тех пор, пока пакет не достигнет места назначения, указан-
ного в поле заголовка. Узел, указанный в поле следующий заголо-
в°к, которому принадлежит модуль заголовка маршрутизации, реа-
лизует следующий алгоритм:
358 Гпава 4 **
If оставшееся число сегментов = 0 {
продолжить обработку следующего заголовка пакета, чей тип
задан полем следующий заголовок заголовка маршрутизации
else, если Hdt Ext Len является нечетным или больше 46 {
послать сообщение ICMP (Parameter Problem, код 0) с указате-
лем на поле Hdr Ext Len, пакет выбросить }
else {
вычислить п, число адресов в заголовке марйтрутизации, для
этого код Hdr Ext Len разделить на 2.
If число оставшихся сегментов пути больше п {
послать сообщение ICMP (Parameter Problem, код 0) с указани-
ем на поле числа оставшихся сегментов пути }
else { уменьшить число оставшихся сегментов пути на 1; ~
Вычислить i, индекс следующего адреса, который следует посе-
тить, для этого вычесть число оставшихся сегментов пути из п.
If а^рес [i] или адрес места назначения IPv6 являются мульти-
кастинговыми,
{ выбросить пакет }
else {
поменять местами адрес места назначения и адрес[1],
if бит i поля Strict/Loose Bit тар имеет значение 1 и новый
адрес места назначения не является адресом узла соседа,
{
послать сообщение ICMP Destination Unreachable — Not a
Neighbor и выбросить пакет
}
^else, если код IPv6 Hop Limit меньше или равен 1, {
послать сообщение ICMP Time Exceeded — Hop Limit Exceeded
in Transit message и выбросить пакет, }
else { уменьшить Hop Limit на 1, повторно направить
пакет модулю IPv6 для отправки новому адресату.
}
}
}
}
В качестве примера работы приведенного выше алгоритма, рас-
смотрим случай, когда узел отправителя S посылает пакет получа-
телю D, используя заголовок маршрутизации, чтобы заставить па-
кет пройти через промежуточные узлы И, 12 и 13. Значения кодов
полей заголовка IPv6 и заголовка маршрутизации для каждого из «
сегментов пути принимают следующие значения.
Сети передачи данных. Метод доступа 35S
При движении пакетов от S к II:
Адрес отправителя = S Hdr Ext Len = 6
Адрес получателя = II Число оставшихся сегментов пути = 3
Адрес[1] = 12
Если бит 0 Bit Мар равен 1,
S и П должны быть соседями.
Это проверяется узл^м S. Адрес[2] = 13
Адрес[3] = D
При движении пакетов от II к 12:
Адрес отправителя = S Hdr Ext Len = 6
Адрес получателя = 12 Число оставшихся сегментов пути = 2
Адрес[1] = II
Если бит 1 Bit Мар равен 1,
II и 12 должны быть соседями.
Это проверяется узлом И Адрес[2] = 13
Адрес[3] = D
При движении пакетов от 12 к 13:
Адрес отправителя = S Hdr Ext Len = 6
Адрес получателя = 13 Число оставшихся сегментов пути = 1
Адрес[1] = 11
Если бит 2 Bit Мар равен 1,
12 и 13 должны быть соседями.
Это проверяется узлом 12 Адрес[2] = 12
Адрес[3] = D
При движении пакетов от 13 к D: '
Адрес отправителя = S Hdr Ext Len = 6
Адрес получателя = D Число оставшихся сегментов пути = О
Адрес[1] = И
Если бит 3 Bit Мар равен 1, 13 и D должны быть соседями.
Это проверяется узлом 13 Адрес[2] = 12
Адрес[3] = 13
360
8. Заголовок фрагмента
Заголовок фрагмента используется отправителем IPv6 для по-
сылки пакетов длиннее, чем MTU пути до места назначения.
Замечание. В отличие от IPv4, фрагментация в IPv6 выполняет-
ся только узлами-отправителями, а не маршрутизаторами вдоль пути
доставки.
Заголовок фрагментации идентифицируется кодом поля следую-
щий заголовок, равным 44. Он имеет следующий формат (рис.
4.4.1.1.21):
Следующий заголовок Резерв Указатель фрагмента Резерв М
Идентификация
Рис. 4.4.7.7.27. Формат заголовка фрагментации
Следующий заголовок — 8-битовый селектор. Идентифицирует
тип исходного заголовка фрагментируемой части исходного пакета.
Использует те же коды протоколов, что и IPv4 [RFC-1700].
Резерв 8-битовое резервное поле. Инициализируется нулем при
передаче и игнорируется при приеме.
Указатель фрагмента — 13-битовое число без знака. Смещение
в 8-октетном блоке, для данных, которые следуют за этим заголов-
ком. Началом отсчета является начало фрагментируемой части ис-
ходного пакета.
Резерв — 2-битовое резервное поле. Инициализируется нулем
при передаче и игнорируется при приеме.
М — флаг 1 = есть еще фрагменты; 0 = последний фрагмент.
Идентификация — 32 бит.
Для того чтобы послать пакет с длиной больше MTU пути до
места назначения, узел-отправитель может разделить пакет на фраг-
менты и послать каждый фрагмент в виде отдельного пакета, сбор-
ка исходного пакета будет проведена получателем.
Для каждого пакета, который должен быть фрагментирован, узел
отправитель генерирует код идентификации. Этот код должен от-
личаться от аналогичных кодов идентификации, используемых для
других фрагментируемых пакетов, которые пересылаются в данный
Сетн передачи данных. Метод доступа
361
момент. Под «данным моментом» подразумевается период времени
жизни пакета, включая время распространения пакета от источни-
ка до получателя и время необходимое для сборки исходного (ори-
гинального) пакета получателем. Однако не предполагается, чтобы
отправитель знал максимальное время жизни пакета. Скорее пред-
полагается, что данное требование будет удовлетворено с помощью
простого 32-разрядного счетчика, инкрементируемого всякий раз,
когда очередной пакет должен быть фрагментирован. Схема реали-
зации генератора кода идентификации оставляется приложению.
Если присутствует заголовок маршрутизации, под адресом получа-
теля подразумевается конечное место назначения.
Под исходным большим, не фрагментированным пакетом под-
разумевается «оригинальный» пакет. Предполагается, что он состо-
ит из двух частей, как показано на рисунке 4.4.1.1.22.
Исходный пакет:
Нефрагментированная часть Фрагментированная часть
Рис. 4.4.1.1.22.
Не фрагментированная часть состоит из IPv6 заголовка плюс
любых заголовков расширения, которые должны быть обработаны
узлами по пути до места назначения. Таким образом, в эту часть
входят все заголовки вплоть до заголовка маршрутизации, если он
присутствует, вплоть до заголовка опций Нор-Ьу-Нор, если таковой
имеется.
Фрагментируемая часть представляет собой остальную часть
пакета, т.е. включает в себя заголовки расширений, которые долж-
ны быть обработаны в узле места назначения, заголовок верхнего
Уровня и данные.
Фрагментируемая часть оригинального пакета делится на фраг-
менты с длиной кратной 8 октетам. Фрагменты пересылаются неза-
висимо с помощью пакетов-фрагментов. Как показано на рис.
4-4.1.1.23.
Исходный пакет:
Нефрагментированная часть Первый фрагмент Второй фрагмент
Последний
фрагмент
362
Гпава 4
Пакеты-фрагменты:
Нефрагментированная 1 Заголовок | Первый
часть фрагмента | фрагмент
Нефрагментированная часть . Заголовок фрагмента Второй фрагмент
о
о
о
Нефрагментированная часть Заголовок фрагмента Последний фрагмент
Рис. 4.4.1.1.23.
Каждый пакет-фрагмент состоит из:
(1) Не фрагментируемой части оригинального пакета, с длиной
поля данных оригинального IPv6 заголовка, измененной так, чтобы
соответствовать длине данного фрагмента пакета (исключая длину
самого 1Ру6-заголовка). Код поля следующий заголовок последнего
заголовка не фрагментируемой части меняется на 44.
(2) Заголовка фрагмента, включающего в себя код поля следую-
щий заголовок, который идентифицирует первый заголовок фраг-
ментируемой части оригинального пакета. Смещение фрагмента
выражается в 8-окФетных блоках и отсчитывается от начала фраг-
ментируемой части оригинального пакета. Смещение первого фраг- 4
мента (самого левого) равно нулю. Код М-флага равен нулю, если
фрагмент является последним (самым правым), в противном слу-
чае флаг равен 1.
(3) Сам фрагмент. л
Длина фрагментов должна выбираться такой, чтобы пакеты-фраг- ;
менты соответствовали значению MTU для маршрута к месту на-
значения (назначений). В узле места назначения из пакетов-фраг- s
ментов восстанавливается оригинальный пакет (см. рис. 4.4.1.22).
В процессе восстановления должны выполняться следующие
правила:
Оригинальный пакет восстанавливается из фрагментов, которые
имеют одни и те же адреса отправителя и получателя, а также код
идентификации.
Не фрагментируемая часть восстанавливаемого пакета состоит
из всех заголовков вплоть до (но, не включая) заголовок фрагмента
Сети передачи данных. Метод доступа
363
первого пакета-фрагмента (пакет со смещением равным нулю). При
этом производятся следующие изменения:
Поле следующий заголовок последнего заголовка не фрагменти-
руемой части берется из поля следующий заголовок заголовка пер-
вого фрагмента.
Длина поля данных восстановленного пакета вычисляется с ис-
пользованиём длины не фрагментируемой части, а также длины и
смещения последнего фрагмента. Например, формула расчета длины
поля данных восстановленного пакета имеет вид:
PL.orig = PL.first — FL.first — 8 + (8 * FO.last) + FL.last
где
PL.orig — поле длины данных восстановленного пакета.
PL.first — поле длины данных первого пакета-фрагмента.
FL.first — длина фрагмента, следующего за заголовком первого
пакета-фрагмента.
FO.last — Поле смещения фрагмента в заголовке последнего
пакета-фрагмента.
FL.last — длина фрагмента, следующего за заголовком фрагмен-
та последнего пакета-фрагмента.
Фрагментируемая часть восстановленного пакета состоит из фраг-
ментов, следующих за заголовками фрагментов^ каждом из паке-
тов-фрагментов. Длина каждого фрагмента вычисляется путем вы-
читания из длины поля данных длины заголовков, размещенных
между IPv6 заголовком и самим фрагментом. Их относительное
положение в фрагментируемой части вычисляется на основе значе-
ния смещения фрагмента. Заголовок фрагмента отсутствует в вос-
становленном пакете. В процессе сборки могут возникнуть следую-
щие ошибки:
Если в пределах 60 секунд после прихода первого фрагмента
получено недостаточно фрагментов для завершения сборки, проце-
дура сборки должна быть прервана и все полученные фрагменты
выкинуты. Если первый фрагмент (т.е., пакет с нулевым смещени-
ем) получен, посылается ICMP сообщение «Time Exceeded — Fragment
Reassemble Time Exceeded».
Если длина фрагмента, полученная из поля длины данных паке-
Та> не является кратным 8 октетам, а М флаг фрагмента равен 1,
Фрагмент должен быть выброшен, и должно быть послано сообще-
ние ICMP (Parameter Problem, код 0) с указателем на поле длины
Данных пакета-фрагмента.
364
Гпава 4
Если длина и смещение фрагмента таковы, что восстановленная
длина поля данных фрагмента превосходит 65,535 октетов, фраг-
мент выбрасывается, посылается сообщение ICMP (Parameter Problem,
код 0) с указателем на поле смещения фрагмента пакета-фрагмента.
Следующие условия не должны реализоваться, но они также
рассматриваются как ошибка, если такое произойдет:
Число и содержимое заголовков, предшествующих заголовку фраг-
мента, отличаются для разных фрагментов одного и того же исход-
ного пакета. Какие бы заголовки ни предшествовали, заголовку
фрагмента, они обрабатываются по прибытии на место назначения
до постановки фрагментов в очередь на восстановление. Только
эти заголовки из пакета с нулевым смещением сохраняются в вос-
становленном пакете.
Значение поля следующий заголовок в заголовках фрагментов
исходного пакета могут отличаться. Для последующей сборки ис-
пользуется только значение из пакета-фрагмента с нулевым смеще-
нием.
9. Заголовок опций места назначения
Заголовок опции места назначения используется для передачи
опционной информации, которая должна анализироваться только *
узлом (узлами) назначения. Заголовок опции места назначения
идентифицируется кодом поля следующий заголовок равным 60
предшествующего заголовка и имеет формат (рис. 4.4.1.1.24):
Следующий заголовок Hdr Ext Len | I
Опции
Рис. 4.4.7.1.24. Формат заголовка опции места назначения
Следующий заголовок — 8-битовый селектор. Идентифицирует
тип заголовка, который непосредственно следует за заголовком оп-
ций места назначения. Использует те же коды протокола, что и
IPv4 [RFC-1700].
Hdr Ext Len — 8-битовое целое без знака. Длина заголовка
опций места назначения в 8-октетных блоках, исключая первые 8
октетов.
Опции — Поле переменной длины, кратная 8 октетам. Содер-
жит одну или более TLV-закодированных опций.
Сети передачи данных. Метод доступа
365
Здесь определены только две опции места назначения Padl и
padN. Обратите внимание, что существует два способа кодировки
опционной информации места назначения для пакетов IPv6: в ка-
честве опции в заголовке опций места назначения, или в виде от-
дельного заголовка расширения. Заголовок фрагмента и заголовок
идентификации являются примерами последнего подхода. Какой
из подходов будет применен, зависит от того, какая операция жела-
тельна в узле места назначения:
• если желательно, чтобы узел назначения уничтожил пакет и,
если адрес места назначения не является мультикастинговым, по-
слал сообщение ICMP Unrecognized Туре, тогда информация может
быть закодирована в отдельном заголовке или в опции места на-
значения с кодом типа опции, равным 11 в старших двух битах.
• если желательна какая-либо иная операция, информация дол-
жна быть закодирована в виде опции места назначения с типом
опции 00, 01 или 10 в старших двух битах.
10. Отсутствие следующего заголовка
Код 59 в поле следующий заголовок или любой другой заголо-
вок расширения указывает, что за этим заголовком ничего не сле-
дует. Если поле длина данных заголовка указывает на присутствие
октетов после конца заголовка, содержащего код 59 в поле следую-
щий заголовок, эти октеты должны быть проигнорированы и пере-
даны без изменений при переадресации пакета.
11. О размере пакетов
Протокол IPv6 требует, чтобы каждый канал в Интернет имел
MTU = 576 октетов или более. Для каждого канала, который не
способен обеспечить длину пакетов в 576 октетов должна быть
обеспечена фрагментация/дефрагментация на уровне ниже IPv6.
Для каждого канала, с которым связан узел непосредственно, он
должен быть способен принимать пакеты с размером MTU данного
канала. В каналах, которые можно конфигурировать, например,
^РР [RFC-1661], должно быть установлено MTU не менее 576 окте-
т°в; рекомендуется устанавливать максимально возможное MTU,
Чт°бы позволить инкапсуляцию (туннелирование) без привлечения
Фрагментации.
Настоятельно рекомендуется, чтобы узлы IPv6 использовали меха-
НИзм определения MTU пути [RFC-1191] для использования преиму-
щества большого значения MTU. Однако, в минимальной конфигура-
пРотокол IPv6 (например, в boot ROM) может ограничивать себя в
Ределах 576 октетов и не использовать процедуру Path MTU Discovery.
366
Гпава 4
Для того чтобы послать пакет длиннее, чем MTU канала, узел
может использовать заголовок фрагментации IPv6. Однако исполь-
зование такой фрагментации заблокировано в приложениях, где ис-
пользуется настройка по измеренному значению MTU пути.
Узел должен быть способен принимать фрагментированные па-
кеты, которые после сборки имеют размер 1500 октетов, включая
IPv6 заголовок. Однако узел не должен посылать фрагменты, кото-
рые после сборки образуют пакеты длиннее 1500 октетов, если он не
уверен, что получатель способен их воспринять и дефрагментиро-
вать.
В ответ на IPv6 пакет, посланный IPv4 адресату (т.е., пакет,
который подвергается преобразованию из IPv6 в IPv4), узел отпра-
витель IPv6 может получить ICMP сообщение Packet Too Big, пре-
дупреждающее о том, что MTU следующего узла меньше 576. В
этом случае узел IPv6 не должен уменьшать размер пакетов до 576
октетов, он должен включить в эти пакеты заголовок фрагментации,
так чтобы маршрутизатор, выполняющий трансляцию IPv6-IPv4, мог
получить приемлемый код идентификации, чтобы использовать по-
лученные IPv4 фрагменты. Заметьте, что это означает сокращение
длины поля данных до 528 октетов (576 минус 40 для IPv6-3aro-
ловка и 8 для заголовка фрагментации), и меньше, если имеются
другие заголовки расширения.
Анализ MTU пути должно проводиться даже в случае, когда
узел «думает», чтд адресат находится на том же канале что и сам
узел. *
В отличие от IPv4, в IPv6 не нужно устанавливать флаг «Don’t
Fragment» (не фрагментировать) в заголовках пакетов, для того
чтобы выполнить операцию определения величины MTU канала,
так как это является атрибутом любого IPv6 пакета по умолча-
нию. Части процедур из RFC-1191, которые включают в себя ис-
пользование таблиц MTU, не применимы к IPv6, так как ,версия
сообщения IPv6 «Datagram Too Big» всегда указывает на точное
значение MTU, которое следует использовать.
12. Метки потоков
24-битовое поле метки потока в заголовке IPv6 может исполь-
зоваться отправителем для выделения пакетов, для которых требу*
ется специальная обработка в маршрутизаторе, такая например как
нестандартное QOS или «real-time» сервис. Этот аспект IPv6 явлЯ*
ется пока экспериментальным и может быть изменен позднее.
ЭВМ или маршрутизаторов, которые не поддерживают функцию по*
Сети передачи данных. Метод доступа
367
метки потоков, это поле должно быть обнулено при формировании
пакета, сохраняться без изменения при переадресации и игнориро-
ваться при получении.
Поток это последовательность пакетов, посылаемых отправите-
лем определенному адресату, при этом предполагается, что все па-
кеты данного потока должны быть подвергнуты определенной обра-
ботке. Характер этой специальной обработки может быть передан
маршрутизатору посредством протокола управления или внутри
самих пакетов, например в опции hop-by-hop.
Допускается несколько потоков между отправителем и получа-
телем, а также обмен, не ассоциированный ни с одним из потоков.
Поток однозначно описывается комбинацией адреса отправителя и
ненулевой меткой потока. Пакеты, не принадлежащие ни одному из
потоков, имеют метку равную нулю.
Метка потока присваивается потоку узлом отправителя. Новые
метки потоков должны выбираться псевдослучайным образом из
диапазона чисел 1 — FFFFFF. Целью псевдослучайного выбора
метки является возможность использования любого набора бит поля
метки потока в качестве хэш ключа маршрутизаторами для конт-
роля состояния, соответствующего потоку.
Все пакеты, принадлежащие одному потоку, должны быть посла-
ны одним отправителем, иметь один и тот же адрес места назначения,
приоритет и метку потока. Если какой-либо из этих пакетов вклю-
чает в себя заголовок опций Нор-Ьу-Нор, тогда вс^они должны начи-
наться с одного и того же содержания заголовка опций Нор-Ьу-Нор
(исключая поле следующий заголовок заголовка опций Нор-Ьу-Нор).
Если любой из этих пакетов включает заголовок маршрутизации,
тогда все они должны иметь идентичные заголовки расширения, вклю-
чая заголовок маршрутизации, но исключая поле следующий заголо-
вок заголовка маршрутизации. Маршрутизаторы и узлы-адресаты
могут проверять эти требования (хотя это и необязательно). Если
обнаружено нарушение, должно быть послано ICMP сообщение от-
правителю (Problem message, код 0) с указателем на старший октет
поля мешка потока (т.е., смещение 1 в IPv6 пакете).
Маршрутизаторы могут варьировать способ обработки потоков
Данных, даже когда отсутствует какая-либо информация о потоке
Со стороны протокола управления, опции hop-by-hop или другого
источника. Например, при получении пакетов от какого-то источ-
ника с неизвестной ненулевой меткой, маршрутизатор может обра-
батывать их IPvjS-заголовок и любой необходимый заголовок рас-
ширения так, как если бы метка равнялась нулю. Такая обработка
м°Жет включать выявление интерфейса следующего шага и другие
368
Гпава 4
действия, такие как актуализация опции hop-by-hop, перемещение
указателя и адресов в заголовке маршрутизации и т.д.. Маршрути-
затор может запомнить результаты такой обработки, занеся их в
кэш (адрес отправителя и метка образуют ключ кэша). Последую-
щие пакеты с тем же адресом отправителя и меткой потока могут
обрабатываться с использованием информации из кэша без деталь-
ного просмотра всех полей, которые, согласно уже описанному, дол-
жны быть идентичными.
Режим обработки пакетов с использованием кэш должен быть
аннулирован не позднее 6 секунд после своей установки вне зависи-
мости от того, продолжают ли поступать пакеты данного потока.
Если приходит другой пакет от того же отправителя с той же мет- J
кой после того как кэш режим отменен, он подвергается обычной ж
обработке (как если бы имел нулевую метку), такая ситуация мо-
жет быть причиной повторного формирования кэш режима.
Время жизни режима обработки потока задается явно в процес- i
се конфигурации, например, через протокол управления или опцию Ф
hop-by-hop, и может превышать 6 секунд.
Отправитель не должен использовать старую метку для нового I
потока в пределах времени жизни любого потока. Так как режим
обработки потока на 6 секунд может быть установлен для любого ;;
потока, минимальный интервал между последним пакетом одного
потока и первым пакетом нового, использующего ту же метку, дол- *
жен быть равным 6 секундам. Метки потока, которые используют-
ся для потоков, существующих более продолжительное время не &
должны использоваться соответственно дольше.
Когда узел останавливает или перезапускает процесс (напри- ч
мер, в случае сбоя), он должен позаботиться о том, чтобы метка ;
потока была уникальной и не совпадала с другой еще действую- -
щей меткой. Это может быть сделано путем записи используемых ;
меток в стабильную память, так чтобы ею можно было воспользо-
ваться даже после серьезного сбоя в системе. Если известно мини-
мальное время перезагрузки системы, это время можно использо-
вать для задания времени жизни меток потоков.
Не требуется, чтобы все или даже большинство пакетов принад-
лежали потокам с ненулевыми метками. Например, было бы неум- l
но сконструировать маршрутизатор так, чтобы он работал только с >
пакетами, принадлежащими к тому или иному потоку, или создать :
схему сжатия заголовков, которая работает только с помеченными ?
потоками.
Сети передали данных. Метод доступа 369
13. Приоритет
4-битовое поле приоритета в IPv6 заголовке позволяет отправи-
телю идентифицировать относительный приоритет доставки паке-
тов. Значения приоритетов делятся на два диапазона. Коды от 0 до
7 используются для задания приоритета трафика, для которого от-
правитель осуществляет контроль перегрузки (например, снижает
поток TCP в ответ на сигнал перегрузки). Значения с 8 до 15
используются для определения приоритета трафика, для которого
не производится снижения потока в ответ на сигнал перегрузки,
например, в случае пакетов «реального времени», посылаемых с по-
стоянной частотой.
Для трафика, управляемого сигналами перегрузки, рекомендуют-
ся следующие значения приоритета для конкретных категорий при-
ложений (см. таблицу 4.4.1.1.2).
Таблица 4.4.1.1.2. Значения кодов приоритета
Код приоритета Назначение
0 Не характеризованный трафик
1 Заполняющий трафик (например, сетевые новости)
2 Не существенный информационный трафик (например, электронная почта)
3 Резерв
4 Существенный трафик (напр., FTP, HTTP, NFS)
5 Резерв
6 Интерактивный трафик (напр. telnet, X)
7 Управляющий трафик Интернет (напр., маршрутные протоколы, SNMP)
Предполагается, что чем больше код, тем выше приоритет дан-
ных, тем быстрее они должны быть доставлены. Так для передачи
мультимедийной информации, где управление скоростью передачи
не возможно, уровень приоритета должен лежать в пределах 8-15.
Практически, уровни приоритета выше или равные 8 зарезервирова-
«Ы для передачи данных в реальном масштабе времени.
Для трафика, не контролируемого на перегрузки, нижнее значе-
Ние приоритета (8) должно использоваться для тех пакетов, кото-
рые отправитель разрешает выбросить в случае перегрузки (напри-
МеР’ видео трафик высокого качества), а высшее значение (15) следу-
ет использовать для пакетов, которые отправитель не хотел бы
п°терять (напр., аудио трафик с низкой надежностью). Не суще-
Ствует связи между относительными приоритетами обменов в при-
сутствии и без контроля перегрузки.
370
Гпава 4
14. О протоколе верхнего уровня
14.1 Контрольные суммы верхнего уровня
Любой транспортный или другой протокол верхнего уровня, ко.
торый включает адреса IP-заголовка в свою контрольную сумму,
должен быть модифицирован, чтобы работать с 128-битовыми IPvfi
адресами вместо 32-битовых IPv4. В частности, ниже показаны
псевдо-заголовки для TCP и UDP в IPv6 (рис. 4.4.1.1.25):
Если пакет содержит заголовок маршрутизации, в качестве адре-
са места назначения в псевдо-заголовке используется оконечный
адрес. В исходном узле этот адрес будет последним элементом
заголовка маршрутизации, для узла получателя будет находиться в
поле адрес места назначения заголовка IPv6.
• Код поля следующий заголовок в псевдо-заголовке идентифи-
цирует протокол верхнего уровня (например, 6 для TCP или 17 для
UDP). Он будет отличаться от кода поля следующий заголовок в
IPv6 заголовке, если имеются заголовки расширения между заго-
ловком IPv6 и заголовком протокола верхнего уровня.
• В качестве кода длины поля данных в псевдо-заголовке ис-
пользуется длина пакета протокола верхнего уровня, включая заго-
ловок верхнего уровня. Он будет меньше длины поля данных в
заголовке, если имеются заголовки расширения между IPv6 заго-!(
ловком и заголовком верхнего уровня.
• В отличие от IPv4, при формировании UDP пакетов в IPv6
узле, контрольная сумма не является опционной. Поэтому при
формировании UDP пакета IPv6 узел должен вычислить контрольную
сумму UDP-пакета и псевдо-заголовка и, если вычисление дает в
качестве результата нуль, он должен быть заменен на FFFF
помещения в UDP заголовок. IPv6 получатели должны выбрасы-
вать UDP пакеты, содержащие нулевую контрольную сумму и
сировать при этом состояние ошибки.
Сеги передачи данных. Метод доступа 377
IPv6 версия ICMP [RFC-1885] включает псевдо-заголовок в вы-
числение контрольной суммы. Причина изменения связана с по-
пыткой защитить ICMP от некорректной доставки или искажений
важных полей в IPv6 заголовке, который в отличие от IPv4 не
защищен контрольным суммированием на Интернет-уровне. Поле
следующий заголовок в псевдо-заголовке для ICMP содержит код
58 который идентифицирует IPv6 версию ICMP.
74. Максимальное время жизни пакета
В отличие от IPv4, узлы IPv6 не требуют установки максималь-
ного времени жизни пакетов. По этой причине поле IPv4 «Time to
Live» (TTL) переименовано в «Нор Limit» (предельное число шагов)
для IPv6. На практике очень немногие IPv4 приложения, использу-
ют ограничения по TTL, так что фактически это не принципиальное
изменение.
75. Максимальный размер поля данных для протоколов
высокого уровня
При вычислении максимального размера поля данных, доступно-
го для данных верхнего уровня, протокол верхнего уровня должен
принимать во внимание большой размер заголовка IPv6 относитель-
но IPv4. Например, в IPv4, MSS опция TCP вычисляется как макси-
мальный размер пакета (значение по умолчанию или величина полу-
ченная из MTU) минус 40 октетов (20 октетов для минимальной
длины IPv4 заголовка и 20 октетов для минимальйой длины TCP
заголовка). При использовании TCP поверх IPv6, JMSS должно быть
вычислено как максимальная длина пакета минус 60 октетов, так
как минимальная длина заголовка IPv6 (т.е., IPv6 заголовок без
заголовков расширения) на 20 октетов больше, чем для IPv4.
/
• 1Б. Приложение А. Рекомендации по формированию опций
Это приложение дает некоторые советы, кдк выкладывать поля,
при формировании новых оп^ций, предназначенных для использова-
ния в заголовке опций Нор-Ьу-Нор или в заголовке опций места
Наз качения. Эти рекомендации базируются на следующих предпо-
ложениях:
Желательно, чтобы любые многооктетные поля в пределах
п°ля опций были выровнены на их естественные границы, т.е., поля
с Длиной в п октетов следует помещать со смещением по отноше-
Нию к началу заголовка (Нор-Ьу-Нор или Destination Options), крат-
HbIM п октетам, для n = 1, 2, 4 или 8.
372 Глава 4
• Другим желательным требованием является минимальное
место, занимаемое Нор-Ьу-Нор или опциями места назначения, дли*
на заголовка должна быть кратной 8 октетам.
• Можно предположить, что когда присутствует какой-то заго-
ловок, содержащий опции, он несет в себе небольшое число опций,
обычно одну.
Эти предположения определяют следующий подход к выкладке
полей опций: порядок опций от коротких к длинным без внутреннего
заполнения. Требования выравнивания границ для всей опции опре-
деляется требованием выравнивания наиболее длинного поля (до 8
октетов). Этот подход иллюстрируется на следующих примерах:
Пример 1
Если опция X требует двух полей данных, одно длиной 8 окте-
тов, а другое длиной 4 октета, ее формат будет иметь вид (рис.
4.4.1.1.26):
Требование выравнивания соответствует 8п+2 октетам, для тогд
чтобы гарантировать начало 8-октетного поля со смещением, крат-г
ным 8, от начала последнего заголовка. Полный заголовок (Нор-
Ьу-Нор или Destination Options), содержащий одну из этих опций
будет иметь формат (рис. 4.4.1.1.27):
Следующий заголовок Hdr Ext Len=1 Тип опции=Х Opt Data Len=12
4-октетное поле
8-октетное поле
Рис. 4.4.1.7.27
Пример 2
Если опция Y требует трех полей данных, одно длиной 4 октета*
одно — 2 октета и одно длиной 1 октет, она будет уложена следУ10'
щим образом (рис. 4.4.1.1.28):
Сети
передачи данных. Метод доступа
373
Тип опции=У
Opt Data Len=7 1 -октетное поле 2-октетное поле
4-октетное поле
Рис. 4.4 Л Л.28
Требование выравнивания выглядит как 4п+3, и призвано га-
рантировать, что 4-октетное поле начнется со смещением кратным
4 по отношению к началу завершающего заголовка. Полный заго-
ловок (Нор-Ьу-Нор или Destination Options), содержащий одну из
указанных опций будет иметь вид (рис. 4.4.1.1.29):
Следующий заголовок Hdr Ext Len=1 Опция Padl =0 Тип опции=У
Opt Data Len=7 Т-октетное поле 2-октетное поле
4-октетное поле
PadN Option=1 Opt Data Len=2 0 0
Рис. 4.4.1.1.29
Пример 3
Заголовок с опциями Нор-Ьу-Нор или Destination Option, содер-
жащий обе опции X и Y из примеров 1 и 2, будет иметь один из
приведенных ниже форматов, в зависимости от того, какая из опций
встречается первой (рис. 4.4.1.1.30, 4.4.1.1.31):
Следующий заголовок Hdr Ext Len=3 Тип опции=Х Opt Data Len=12
4-октетное поле
8-октетное поле
Опция PadN =1 Opt Data Len=2 0 0
Opt Data Len=7 1 -октетное поле 2-октетное поле
4-октетное поле
Опция PadN =1 Opt Data Len=2 0 0
Рис. 4.4.1.1.30
374 Глава 4 •
Следующий заголовок Hdr Ext Len=3 Опция Pad1 =0 Тип опции=У
Opt Data Len=7 1 -октетное поле 2-октетное поле
4-октетное поле
Опция PadN =1 Opt Data Len=4 0 0
0 0 Тип опции=Х Opt Data Len=12
4-октетное поле
8-октетное поле
Рис. 4.4.4.4.34
4 7. Соображения безопасности i
Заголовок аутентификации [RFC-1826] и безопасная IP инкап-
суляция [RFC-1827] будут использоваться в IPv6, в соответствии с
безопасной архитектурой протоколов Интернет [RFC-1825].
48. Расширение DIMS для поддержки IP версии Б
[DNS Extensions to support IP version 6. S. Thomson. RFC-1886]
Существующая поддержка записи адресов Интернет в DNS
(Domain Name System) [1,2] не может быть легко расширена для
поддержки 1Ру6-адресов [3], так как приложение предполагает, что
адресный запрос вернет только 32-битовый 1Ру4-адрес.
Для того чтобы запоминать 1Ру6-адреса, определены следующие
расширения:
• Определен новый тип ресурсной записи, для того чтобы уста-
новить соответствие между именами доменов и адресами IPv6.
• Определен новый домен, предназначенный для обработки зап-
росов по новым адресам.
• Существующие запросы, которые выполняют выявление IPv4-
адресов, переопределены для определения как IPv4, так и 1Ру6-адресов.
Изменения выполнены так, чтобы быть совместимыми с имею-
щимся программным обеспечением. Поддержка 1Ру4-адресов сохра-
няется. Переходное состояние сосуществования IPv4 и 1Ру6-адре-
сов обсуждается в [4].
48.4. Определение новой ресурсной записи и домена
Определен новый тип ресурсной записи для хранения 1Ру6-адре-
са ЭВМ. Если ЭВМ имеет более одного 1Ру6-адреса, тогда использу-
ется более одной такой ресурсной записи.
Сети передачи данных. Метод доступа
375
Тип ресурсной записи АААА является специфическим для класса
Интернет и служит для записи одного 1Ру6-адреса. Код типа равен
28 (десятичное).
128-битовый 1Ру6-адрес заносится в информационную часть ре-
сурсной записи АААА, придерживаясь порядка байт, используемого
в сети (старший байт первый).
Запрос АААА для конкретного имени домена в классе Интернет
возвращает в качестве отклика все ресурсные записи, соответствую-
щие ресурсной секции АААА. Запрос типа АААА не выполняет
никакой дополнительной обработки этой секции.
Текстовое представление информационной секции ресурсной за-
писи АААА, используемое в файле базы данных имеет формат, опи-
санный в [3], а также в текущем разделе.
Определен специальный домен, который предназначен для уста-
новления соответствия между именами и 1Ру6-адресами. Домен имеет
имя IP6.INT.
1Ру6-адрес представляется в виде имени в домене IP6.INT. Это
имя выглядит как последовательность символов, разделенных точка-
ми, завершающаяся суффиксом .IP6.INT. Последовательность сим-
волов записывается в обратном порядке, т.е. младший по порядку
символ записывается первым и т.д... Каждый из символов представ-
ляет собой шестнадцатеричную цифру. Например, запрос, соответству-
ющий адресу 4321:0:1:2:3:4:567:89аЬ будет выглядеть как
Ь.а.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4. IP6.INT.
18.2. Модификации существующих типов запроса
Все существующие типы запросов, которые выполняют дополни-
тельную обработку секции А, т.е. типы запросов, относящиеся к
серверу имен (NS), почтовому серверу (MX) и почтовому ящику (МВ),
для осуществления обработки как секции типа А, так и типа АААА
должны быть переопределены. Эти новые определения означают,
что сервер имен, обрабатывая один из указанных запросов, должен
добавить в соответствующую секцию запроса какие-то подходящие
адреса IPv4 и какие-то адреса IPv6 доступные локально.
19. Протокол управляющих сообщений (ICMPvBJ для
спецификации Ipv6
(A. Conta. Internet Control Message Protocol [ICMPvB] for the
InternetProtocol Version В [IPv6] Specification. RFC-2463)
IPv6 использует протокол управляющих сообщений (ICMP) так,
как это определено для IPv4 [RFC-792], ни с некоторым количе-
376
Гпава 4
ством изменений. Протокол подключения к группам (IGMP), спе-
цифицированный для IPv4 [RFC-1112] был также пересмотрен и
включен в протокол ICMP для IPv6. Результирующий протокол
называется ICMPv6, и имеет код следующего заголовка 58.
79.7. ICMPvB [ICMP для IPv6)
ICMPv6 используется узлами IPv6 для сообщений об ошибках
при обработке пакетов, и для выполнения других функций уровня
Интернет, таких как диагностика (ICMPv6 «ping») и сообщение об
участии в мультикастинг группах. Протокол ICMPv6 является ин-
тегрированной частью IPv6 и должен быть реализован каждым уз-
лом, поддерживающим IPv6.
19.2. Общий формат сообщений
Сообщения ICMPv6 образуют два класса: сообщения об ошиб-
ках и информационные сообщения. Сообщения об ошибках иден-
тифицируются по нулю в старшем бите поля тип. Таким образом,
сообщения об ошибках могут иметь код поля тип от 0 до 127;
информационные сообщения имеют коды поля тип от 128 до 255.
В данном документе определены форматы для следующих сообще-
ний ICMPv6:
Сообщения об ошибках ICMPv6:
1 Destination Unreachable (место назначения недоступно)
2 Packet Too Big (пакет слишком велик)
3 Time Exceeded (время превышено)
4 Parameter Problem (проблема с параметрами)
Информационные сообщения ICMPv6:
128 Echo Request (Запрос эхо)
129 Echo Reply (Эхо-отклик)
130 Group Membership Query (запрос участия в группе)
131 Group Membership Report (отчет об участии в группе)
132 Group Membership Reduction (сокращение числа участни-
ков в группе)
Каждое сообщение ICMPv6 начинается с заголовка IPv6, за ко-
торым следует нуль или более заголовков расширения IPv6. Заго-
ловок ICMPv6 идентифицируется кодом следующего заголовка 58
в предыдущем заголовке. (Заметим: этот код отличается от значе-
ния, принятого для ICMP IPv4.)
Сети передачи данных. Метод доступа
377
Сообщения ICMPv6 имеют следующий общий формат (рис.
4.4.1.1.32):
0 8 16 24 31
Тип Код Контрольная сумма
... Тело сообщения ....
Рис. 4.4.1.1.32. Общий формат сообщений ICMPvG
Поле тип указывает на тип сообщения. Его значение определя-
ет формат последующих данных.
Поле код зависит от типа сообщения. Оно используется для
создания дополнительного уровня структуризации сообщения. Поле
контрольная сумма используется для обнаружения повреждений
сообщения ICMPv6 и заголовка IPv6.
Узел-отправитель сообщения ICMPv6 должен задать 1Ру6-адре-
са отправителя и получателя до вычисления контрольной суммы.
Если узел имеет более одного уникастного адреса, то он должен
выбрать адрес отправителя следующим образом:
(а) Если сообщение является откликом на сообщение, получен-
ное по одному из уникаст-адресов, адресом отправителя должен стать
именно этот адрес.
(Ь) Если сообщение является откликом на мультикаст- или
эникаст- сообщение группе, в которую входит данный узел, адресом
отправителя должен стать уникастный адрес интерфейса, откуда
пришло сообщение-первопричина отклика.
(с) Если сообщение является откликом на сообщение, послан-
ное по адресу, который не принадлежит данному узлу, в качестве
адреса отправителя следует выбрать уникаст адрес, принадлежащий
Узлу и обещающий наибольшую диагностическую полезность. На-
пример, если сообщение является откликом на операцию переадре-
сации пакета, которая не может быть завершена успешно, в каче-
стве адреса отправителя должен быть взят уникаст-адрес интерфей-
са, переадресация на который не удалась.
(d) В противном случае, должна быть просмотрена таблица мар-
шрутизации узла и выяснено, какой интерфейс должен быть ис-
пользован для достижения места назначения сообщения. Уникаст-
аДрес этого интерфейса и должен быть выбран в качестве адреса
отправителя.
Контрольная сумма является 16-битным дополнением по моду-
Л1° 1 суммы всего сообщения ICMPv6, начиная с поля тип, допол-
378
Гпава 4
ненного полями псевдозаголовка IPv6. Код поля следующий заголо-
вок для псевдозаголовка выбирается равным 58. (Заметим: вклю-
чение псевдозаголовка в контрольную сумму ICMPv6 является из-
менением по отношению к протоколу IPv4; обоснование причин
этого см. в [IPv6]). Перед вычислением контрольной суммы поле
контрольная сумма обнуляется.
Приложения должны следовать следующим правилам при об-
работке сообщений ICMPv6 (из [RFC-1122]):
(а) Если получено сообщение о неизвестной ошибке ICMPv6, оно
должно быть передано верхнему уровню.
(Ь) Если получено информационное сообщение ICMPv6 неизвес-
тного типа, оно должно быть выброшено.
(с) Каждое ICMPv6 сообщение об ошибке (тип < 128) включает
в себя целиком или частично IPv6 пакет, вызвавший ошибку, при
условии, что длина сообщения об ошибке не превысит 576 октетов.
(d) В тех случаях, когда протокол Интернет-уровня нуждается в
передаче сообщения об ошибке ICMPv6 вышерасположенному уров-
ню, тип протокола верхнего уровня извлекается из исходного паке-
та (содержащегося в теле сообщения об ошибке ICMPv6) и исполь-
зуется для выбора соответствующего протокола верхнего уровня
при последующей обработке сообщения об ошибке.
Если исходный пакет имеет необычно большое число заголов-
ков расширения, возможно, что тип протокола верхнего уровня мо-
жет отсутствовать в сообщении ICMPv6, из-за укорочения исходно-
го пакета до уровня 576 октетов. В этом случае сообщение об
ошибке отбрасывается после обработки уровня IPv6.
(е) Сообщение об ошибке ICMPv6 не должно посылаться в каче-
стве результата получения:
(е.1) сообщения об ошибке ICMPv6, или
(е.2) пакета, направленного по IPv6 мультикаст-адресу (суще-
ствует два исключения из этого правила: (1) сообщения Packet Too
Big (пакет слишком велик) - чтобы позволить скорректировать
MTU прохода, и (2) сообщения Parameter Problem (проблема с пара-
метрами), код 2, оповещающий о нераспознанной опции), или
(е.З) мультикастинг-пакета канального уровня, (исключений
пункта е.2 применимы и здесь), или
(е.4) широковещательного пакета канального уровня, (исключе- ...
ния пункта е.2 применимы и здесь), или
(е.5) пакета, чей адрес отправителя не однозначно определяем
какой-то узел, например, не специфицированный адрес IPv6, мульту
каст-адрес IPv6 или эникаст-адрес. г:
Сети передачи данных. Метод доступа
379
(f) Наконец, узел IPv6 должен ограничить частоту посылки со-
общений об ошибке, если адресат на них не реагирует. Это ограни-
чит загрузку канала.
Существует много способов ограничения частоты посылки сооб-
щений, например:
(f.l) Таймерный метод. Передача сообщений производится не
чаще, чем раз за указанное число Т миллисекунд.
(f. 2) Метод полосы пропускания. Сообщения об ошибке должны
занимать не более определенной доли F полосы пропускания канала.
Ограничивающие параметры (например, Т или F в вышеприве-
денных примерах) должны задаваться узлом со значениями по умол-
чанию (напр., Т = 1 сек, и F = 2%, а не 100%!).
19.3. Сообщения об ошибках ICMPvB
Формат сообщения об ошибке показан на рис. 4.4.1.1.33.
0_____________8_______________16____________24____________31
Тип Код | Контрольная сумма
Не используется
Пакет, вызвавший ошибку, или его часть, но так, чтобы
размер 1ру6-пакета был не более 576 октетов
Рис. 4.4.1.1.33. Формат сообщения о недостижимости адресата
Поля IPv6:
Адрес места назначения копируется из поля адрес отправителя
пакета, вызвавшего ошибку.
Поля ICMPv6:
Тип = 1
Код = 0 - нет маршрута до места назначения
1 - связь с адресатом административно запрещена
2 - не сосед
3 - адрес не достижим
4 - порт не достижим
Не используется. Это поле не используется при всех значениях
поля код. Оно должно обнуляться отправителем и игнорироваться
Получателем.
Сообщение адресат не достижим (Destination Unreachable) дол-
Нсн° генерироваться маршрутизатором, или уровнем IPv6 узла-от-
правителя, в случае, когда пакет не может быть доставлен адресату
но по причине перегрузки. (Сообщение ICMPv6 не должно посы-
Латься при потере пакета из-за перегрузки).
380
Гпава 4
Если причиной потери пакета является недостаток места в мар-
шрутной таблице узла, поле код должно принять значение 0 (Заме- •
тим, что такая ошибка может произойти только при отсутствии
маршрута по умолчанию).
Если причиной потери пакета является административный зап-
рет, например, Firewall, поле код принимает значение 1.
Если причиной потери пакета является то, что следующий узел
в маршрутной таблице не является соседом данного узла, то поле
код принимает значение 2.
Если имеет место какая-то другая причина недоставки пакета, в
поле код заносится значение 3.
Узел места назначения может посылать сообщение “адресат не
достижим” с кодом 4, когда транспортный протокол пакета (напр.,
UDP) не имеет получателя, а другого метода, уведомить об этом
отправителя нет.
Узел, получивший сообщение ICMPv6 “адресат не достижим”
должен уведомить об этом протокол вышележащего уровня. Фор-
мат сообщения «пакет слишком велик» показан на рис. 4.4.1.1.34.
0 8 16 24 31
Тип Код Контрольная сумма
MTU
Пакет, вызвавший ошибку, или его часть, но так, чтобы размер Ipv6-
пакета был не более 576 октетов
Рис. 4.4.1.1.34. Сообщение Packet Too Big (пакет слишком велик!
Поля IPv6:
Адрес места назначения копируется из поля адрес отправителя
пакета, вызвавшего ошибку.
Поля ICMPv6:
Тип 2
Код О
MTU MTU следующего шага.
Сообщение Packet Too Big (пакет слишком велик) должно по-
сылаться маршрутизатором в ответ на получение пакета, который
не может быть переадресован, из-за того, что он длиннее, чем MTU
выходного канала. Информация в этом сообщении используется в
качестве части процесса определения MTU прохода [RFC-1191].
Пришедшее сообщение Packet Too Big должно быть передай0
протоколу верхнего уровня.
Сети передачи данных. Метод доступа
381
Формат сообщения о превышении времени аналогичен формату
сообщения о недостижимости адресата (рис. 4.4.1.1.33).
Поля ICMPv6:
Tun 3
Код 0 - при передаче превышен лимит числа шагов
1 - превышено время восстановления сообщения из
фрагментов.
Не используется. Это поле не используется при всех значениях
поля код. Оно должно обнуляться отправителем и игнорироваться
получателем.
Если маршрутизатор получает пакет с предельным значением
числа шагов равным нулю (Hop Limit = 0), или маршрутизатор
после декрементации получил нулевое значение поля Hop Limit, он
должен выбросить такой пакет и послать отправителю пакета сооб-
щение ICMPv6 о превышении времени (Time Exceeded) со значени-
ем поля код равным 0. Это указывает на зацикливание маршрута
или на слишком малое значение поля Hop Limit.
Посылая сообщение ICMPv6 о превышении времени (Time
Exceeded) со значением поля код равным нулю, маршрутизатор
должен рассматривать входной интерфейс, в соответствии с прави-
лом выбора адреса отправителя (d).
Пришедшее сообщение Time Exceeded должно быть передано про-
токолу верхнего уровня. Формат сообщения о конфликте парамет-
ров показан на рис. 4.4.1.1.35.
0 8 16 24 31
Тип Код Контрольная сумма
Указатель
Пакет, вызвавший ошибку, или его часть, но так, чтобы размер Ipv6-
пакета был не более 576 октетов
Рис. 4.4 Л Л. 35. Сообщение о конфликте параметров
Поля ICMPv6:
Tun 4
Код 0 - встретилась ошибка в поле заголовка
1 - встретился неопознанный код поля следующий заголовок
2 - встретилась неопознанная опция IPv6
Указатель. Идентифицирует смещение в октетах для пакета,
вызвавшего ошибку.
382
Гпава 4
Указатель отмечает позицию в пакете, если размер пакета ICMPv6
не позволяет поместить его в отклик полностью, а ошибочное пдле
в сообщение не поместилось.
Если узел IPv6, обрабатывающий пакет, обнаруживает какую-то
проблему с одним из полей заголовка или расширения, такую, что
дальнейшая обработка невозможна, он должен выбросить пакет и
послать сообщение ICMPv6 Parameter Problem (проблема с парамет-
рами) отправителю пакета с указанием типа и позиции ошибки.
Поле указатель идентифицирует октет заголовка исходного па-
кета, где обнаружена ошибка. Например, сообщение ICMPv6 с по-
лем тип ~ 4, полем код = 1 и полем указатель = 40 указывает на
то, что заголовок расширения IPv6, размещенный за заголовком
IPv6 исходного пакета содержит нераспознанный код следующего
заголовка.
79.4. Информационные сообщения ICMPvG
Тип Код Контрольная сумма
Идентификатор Номер по порядку
Информация
Рис. 4.4.1.1.36. Сообщение запрос эхо
Поля IPv6:
Адрес места назначения - любой легальный IPv6-адрес
Поля ICMPv6:
Tun 128
Код О
Идентификатор. Идентификатор, который помогает связать друг
с другом запрос эхо и эхо-отклик. Может равняться нулю.
Поле номер по порядку имеет целью связать друг с другом зап-
рос эхо и эхо-отклик. Может равняться нулю.
Информация. Нуль или более октетов произвольных данных.
Каждый узел должен реализовать функцию эхо-отклика ICMPv6.
При получении запроса эхо узлу следует также предоставить пользо-
вательский интерфейс для посылки запросов эхо и получения эхо-
откликов для целей диагностики. Формат сообщения эхо-отклик
идентичен формату запроса эхо (рис. 4.4.1.1.36).
Поля IPv6:,
Сети передачи данных. Метод доступа
383
Адрес места назначения копируется из поля адрес отправителя
пакета запрос эхо.
Поля ICMPv6:
Тип 129
Код О
Поле идентификатор берется из исходного запроса эхо (Echo
Request).
Поле номер по порядку берется из исходного запроса эхо.
Информация. Данные из исходного запроса эхо.
Адрес отправителя эхо-отклика, посылаемого в ответ на уникас-
тный запрос эхо должен быть тем же самым, что и адрес места
назначения в запросе эхо.
Эхо-отклик должен быть послан в ответ на запрос эхо, послан-
ный по мультикастному адресу. Адрес отправителя в отклике дол-
жен быть уникастным адресом, принадлежащим интерфейсу, через
который был получен мультикастный запрос эхо.
Информация, полученная в 1СМРу6-сообщении запроса эхо, дол-
жна быть полостью возвращена без модификации в ICMPv6 эхо
отклике, если эхо-отклик не превысит MTU обратного прохода, в
противном случае пакет укорачивается.
Сообщение о членстве в группе имеет следующий формат (рис.
4.4.1.1.37.):
Рис. 4.4.1.1.37. Сообщения участия в группе
Поля Pv6:
Адрес места назначения.
В сообщении-запросе о членстве в группе запрашивается муль-
тикаст-адрес группы.
В отчете о членстве в группе или в сообщении о сокращении
членства в группе сообщается мультикаст-адрес группы.
Поле предельное число шагов = 1 (Hop Limit)
Поля ICMPv6:
384
Гпава 4
Тип 130 - Запрос членства в группе
131 - Отчет о членстве в группе
132 - Сокращение членства в группе
Код 0
Поле максимальное время отклика в сообщениях-запросах —
это максимальное время в миллисекундах, на которое может задер-
жаться сообщение-отчет. В сообщениях-отчетах и сообщениях о со-
кращении числа членов в группе в это поле отправитель записывает
нуль, а получатель его игнорирует.
В поле не используется отправитель записывает нуль, получа-
тель же его игнорирует.
Поле мультикаст-адрес содержит адрес мультикаст-группы,* со-
общение о которой послано. В сообщениях-запросах поле муль-
тикаст-адреса может равняться нулю, что означает запрос ко всем
группам.
Сообщения ICMPv6 о членстве в группе используются для пере-
дачи информации о членстве в мультикаст-группе от узлов к их
ближайшим маршрутизаторам. Подробности их использования мож-
но найти в [RFC-1112].
20. Литература
[1] Mockape tris, Р., «Domain Names — Concepts and Facilities», STD13,
RFC 1034, USC/Information Sciences Institute, November 1987.
[2] Mockapetris, P., «Domain Names — Implementation and Specification»,
STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
[3] "Hinden, R., and S. Deering, Editors, «IP Version 6 Addressing
Architecture», RFC 1884, Ipsilon Networks, Xerox PARC, December 1995.
[4] Gilligan, R., and E. Nordmark, «Transition Mechanisms for IPv6 Hosts
and Routers», Work in Progress.
[ALLOC] Rekhter, Y., and T. Li, «An Architecture for IPv6 Unicast Address
Allocation», RFC 1887, cisco Systems, December 1995
[ANYCST] Partridge, C., Mendez, T., and W. Milliken, «Host Anycasting
Service», RFC 1546, BBN, November 1993.
[OlDR] Fuller, V., Li, T., Varadhan, K., and J. Yu, «Supemetting: an Address
Assignment and Aggregation Strategy», RFC 1338, BARRNet, cisco, Merit,
OARnet, June 1992.
[IPV6] Deering, S., and R. Hinden, Editors, «Internet Protocol, Version 6
(IPv6) Specification», RFC 1883, Xerox PARC, Ipsilon Networks, December 1995»
[IPv6-ADDR] Hinden, R., and S. Deering, Editors, «IP Version 6 Addressing
Architecture», RFC 1884, Ipsilon Networks,""Xerox PARC, December 1995.
[IPv6-DISC] Narten, T., Nordmark, E., and W. Simpson, «Neighbor Discovery
for IP Version 6 (IPv6)», Work in Progress
[MULT] Deering, S., «Host Extensions for IP multicasting», STD 5,
1112, Stanford University, August 1989
Сети передачи данных. Метод доступа
385
[NSAP] Carpenter, В., Editor, «Mechanisms for OSIN SAPs, CLNP and TP
over IPv6», Work in Progress.
[RFC-791] Postel, J., «Internet Protocol», STD 5, RFC 791, USC/Information
Sciences Institute, September 1981.
[RFC-792] Postel, J., «Internet Control Message Protocol», STD 5, RFC 792,
USC/Information Sciences Institute, September 1981
[RFC-1112] Deering, S., «Host Extensions for IP Multicasting», STD 5, RFC
1112, Stanford University, August 1989.
[RFC-1122] Braden, R., «Requirements for Internet Hosts -Communication
Layers», STD 3, RFC 1122, USC/Information Sciences Institute, October 1989
[RFC-1191] Mogul, J., and S. Deering, «Path MTU Discovery», RFC1191,
DECWRL, Stanford University, November 1990.
[RFC-1661] Simpson, W., Editor, «The Point-to-Point Protocol (PPP)», STD
51, RFC 1661, Daydreamer, July 1994.
[RFC-1700] Reynolds, J., and J. Postel, «Assigned Numbers», STD 2, RFC
1700, USC/Information Sciences Institute, October 1994.
[RFC-1825] Atkinson, R., «Security Architecture for the Internet Protocol»,
RFC 1825, Naval Research Laboratory, August 1995.
[RFC-1826] Atkinson, R., «IP Authentication Header», RFC 1826, Naval
Research Laboratory, August 1995.
[RFC-1827] Atkinson, R., «IP Encapsulating Security Protocol (ESP)», RFC
1827, Naval Research Laboratory, August 1995
[RFC-1885] Conta, A., and S. Deering, «Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», RFC 1885,
Digital Equipment Corporation,Xerox PARC,December 1995.
[RFC-1884] Hinden, R., and S. Deering, Editors, «IP Version 6 Addressing
Architecture», RFC 1884, Ipsilon Networks, Xerox PARC, December 1995
[RFC-1933] Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan
& E. Nordmark. April 1996
[RFC-1970] Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E.
Nordmark & W. Simpson. August 1996.
[RFC-1971] IPv6 Stateless Address Autoconfiguration. S. Thomson & T.
Narten. August 1996.
[RFC-1972] A Method for the Transmission of IPv6 Packets over Ethernet
Networks. M. Crawford. August 1996.
[RFC-2019] Transmission of IPv6 Packets Over FDDI. M. Crawford. October 1996.
[RFC-2030] Simple Network Time Protocol (SNTP) Version 4 for IPv4,
IPv6 and OSI. D. Mills. October 1996.
[RFC-2080] RIPng for IPv6. G. Malkin, R. Minnear. January 1997.
[RFC-2133] Basic Socket Interface Extensions for IPv6. R. Gilligan, S.
Thomson, J. Bound, W. Stevens. April 1997.
3 Ns 3430 Семенов
386
Гпава 4
4.4.1. S. IP-туннели и прокси-серверы
Особенность IP-протокола (опция принудительной маршрутиза-
ции) позволяет переадресовывать IP-дейтограммы определенным уз-
лам сети. На первый взгляд эта возможность может показаться со-
вершенно бесполезной, ведь существуют механизмы динамической
маршрутизации, которые несравненно эффективнее и надежней обес-
печивают обмен данными. Но тем не менее существуют приложения,
где принудительная маршрутизация на IP-уровне представляет воз-
можности недоступные для традиционных решений. Это прежде все-
го сети, работающие с использованием протоколов IPX/SPX (Novell),
где традиционная маршрутизация не предусмотрена. Для подключе-
ний удаленных серверов, находящихся вне локальной сети, здесь ис-
пользуется технология так называемых IP-туннелей. При реализа-
ции этой технологии IPX-пакеты инкапсулируются в 1Р-дейтограм-
мы и доставляются в соответствие с протоколами TCP/IP. Процедура
инкапсуляции осуществляется специальным драйвером (IPTUNNEL;
использует протокол IPXODI), который работает так, как если бы он
был драйвером аппаратного сетевого интерфейса. При этом необхо-
димо модифицировать конфигурационный файл NET.CFG (См. на-
пример, www2.ncsu.edu/cc-consult/UsingLWP/tunnel.html).
Техника IP-туннелей может оказаться иногда полезной и при
администрировании маршрутизации, так как метрика внешних про-
токолов маршрутизации может не учитывать пропускную способ-
ность каналов и некоторые другие факторы, например, QOS. В этом
случае IP-дейтограммы вкладываются в IP-дейтограммы отправите-
лем (начало туннеля) и извлекаются оттуда в конце туннеля. Ко-
нец туннеля не обязательно совпадает с местом назначения паке-
тов. Такая простая схема туннелирования может порождать неко-
торые проблемы (см. рис. 4.4.1.2.1).
Рис. 4.4.1.2.1 Схема туннелирования пакетов.
Сети передачи данных. Метод доступа
387
Из рисунка видно, что простой туннель может породить асим-
метричный маршрут, при котором путь туда и обратно не совпада-
ют. Чтобы такого не произошло, применяется техника «маскарада»
(masquerading). Для этого «маршрутизатор конца туннеля» дол-
жен извлечь вложенный пакет (как это он делает и на рис. 4.4.1.2.1)
и вложить его в пакет с адресом места назначения IP3, указав при
этом в качестве отправителя себя (IP3/IP2[IP3/IP1]). Тогда ко-
нечный адресат IP3 будет посылать отклики по адресу IP2, а не IP1.
А уже маршрутизатор конца туннеля будет пересылать их первоис-
точнику запроса IP1.
Квадратными скобками отмечено вложение пакетов. В числите-
ле приводится адрес места назначения, в знаменателе адрес отправи-
теля. Адрес вне скобок - адрес места назначения.
В последнее время техника туннелей нашла применение при
построении так называемых прокси-серверов (кэш-серверов), попу-
лярность которых связана с возможностью заметно сократить вне-
шний (часто зарубежный) трафик за счет запоминания в дисковом
буфере файлов, наиболее часто запрашиваемых клиентами. Заметно
упрощает решение данной задачи многие современные маршрутиза-
торы, которые могут отфильтровывать запросы по определенным
портам и переадресовывать их прокси-серверу (см. рис. 4.4.1.2.2).
Рис. 4.4.1.2.2. Схема транспортировки запросов при использовании
прокси-сервера
Схема с «невидимым» прокси-сервером работает следующим
образом. Сначала запрос поступает в маршрутизатор, там он анали-
зируется и, если выясняется что это HTTP или FTP-запросы, пере-
адресуется прокси-серверу. Если запрашиваемый файл находится в
буфере сервера, заказ клиента удовлетворяется локально. В против-
ном случае запрос снова посылается маршрутизатору. Запросы про-
кси-сервера маршрутизатор переправляет во внешнюю сеть. В слу-
чае использования персональной ЭВМ в качестве прокси-сервера
Мо*но ее снабдить двумя сетевыми интерфейсами для приема и
посылки запросов, что сделает работу более эффективной. Если мар-
шрутизатор не поддерживает описанный режим, то при конфигура-
388
Гпава 4
ции сетевого программного обеспечения клиента можно явно про-
писать адрес прокси-сервера и все соответствующие запросы пойдут
непосредственно туда.
Туннели широко используются и при передаче мультимедийных
данных.
4.4.2. Протокол 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. Общеизвестные номера портов
определяются стандартами Internet (см. табл. 4.4.2.1). ।
Сети передачи данных. Метод доступа ,
389
ТаблицаЪ.4.2.1 Номера UDP-портов
Десятич. номер порта Обозначение порта Описание
в Интернет в UNIX
0 - - Зарезервировано
I TCPMUX - TCP Мультиплексор
2 compressnet - Программа управления
3 compressnet - Процесс сжатия
5 RJE - Вход в удаленную задачу
7 ECHO echo Эхо
9 DISCARD discard Сброс
П USERS systat Активные пользователи
13 DAYTIME daytime Время дня
15 - netstat Кто работает или NETSTAT
19 CHARGEN chargen Генератор символов
20 FTP-DATA ftp-data FTP (данные)
21 FTP ftp Протокол пересылки файлов (управление)
23 TELNET telnet Подключение терминала
24 - - Любая частная почтовая система
25 SMTP smtp Протокол передачи почтовых сообщений
31 msg-auth Распознавание сообщения (аутентификация)
35 - - Любой частный принт-сервер
37 TIME time Время
39 rip - Протокол поиска ресурсов
41 graphics Графика
42 NAMESERVER name Сервер имен
43 NICNAME whois Кто это? (Whois-сервис)
45 mpm * Блок обработки входных сообщений
46 mpm-snd - Блок обработки выходных сообщений
48 auditd - Демон цифрового аудита
49 login - Протокол входа в ЭВМ
50 re-mail-ck - Протокол удаленного контроля почтовым обменом
53 DOMAIN nameserver Сервер имен доменов (DNS)
57 - - Любой частный терминальный доступ
59 - - Любой частный файл-сервер
64 co via - Коммуникационный интегратор (CI)
390
Гпава 4
Таблица 4.4.2.1 Номера UDP-портов [продолжение]
Десяти ч. номер порта Обозначение порта Описание
в Интернет в UNIX
66 sql*net - Oracle SQL*NET
67 BOOTPS bootps Протокол загрузки сервера
68 ВООТРС bootpc Протокол загрузки клиента
69 TFTP tftp Упрощенная пересылка файлов
70 GOPHER Gopher (поисковая система)
71 - netrjs-1 Сервис удаленных услуг
77 * ... rJe Любой частный RJE-сервис
79 FINGER finger Finger
80 WWW-HTTP World Wide Web HTTP
81 hosts2-ns - Сервер имен 2
87 - - Любая частная терминальная связь
88 kerberos kerberos
• 92 npp - Протокол сетевой печати
93 dcp - Протокол управления приборами
95 SUPDUP supdup SUPDUP протокол
97 swift-rvf - SWIFT-протокол удаленных виртуальных файлов
101 HOSTNAME hostnames Сервер имен ЭВМ для сетевого информационного центра
102 ISO-TSAP iso-tsap ISO-TSAP
103 gPPitnp Сети точка-точка
104 acr-nema ACR-NEMA Digital Imag. & Comm. 300
108 snagas SNA-сервер доступа
109 POP2 - Почтовый протокол POP2
ПО POP3 - Почтовый протокол POP3
111 SUNRPC sunrpc SUN Microsystem RPC
113 AUTH auth Служба распознавания
114 audionews Аудио-новости
115 SFTP Простой протокол передачи файлов
117 UUCP-PATH uucp-path Служба паролей UUCP
118 sqlserv SQL-сервер
119 NNTP nntp Протокол передачи новостей
123 NTP ntr Сетевой протокол синхронизации
129 pwdgen Протокол генерации паролей _
130-132 CISCO _
Сети передачи данных. Метод доступа
391
Таблица 4.4.2.1 Номера UDP-портов (окончание]
Десятич. номер порта Обозначение порта Описание
в Интернет в UNIX
133 statsrv Сервер статистики
134 ingres-net ingres-net-сервис
135 loc-srv Поисковый сервис
’ 137 NETBIOS-SSN - Служба имен NETBIOS
138 netbios-dgm Служба дейтограмм NETBIOS
139 netbios-ssn Служба сессий NETBIOS
' 147 ISO-ip ISO-ip
150 sql-net SQL Net
152 В FTP Протокол фоновой пересылки файлов
156 sqlsrv SQL-сервер
158 pcmail-srv PC почтовый сервер
161 - snmp Сетевой монитор SNMP
162 - snmp-trap SNMP-ловушки
170 print-srv PostScript сетевой сервер печати
179 BGP Динамический протокол внешней маршрутизации
191 PROSPERO Служба каталогов PROSPERO
194 IRC Протокол Интернет для удаленных переговоров
201-206 Протоколы сетей Apple Talk
213 IPX IPX
348 csi-sgwp Протокол управления Cabletron
396 netware-ip Novell-NetWare через IP
398 kryptolan Kryptolan
414 INFOSEEK InfoSeek (информационный поиск)
418 hyper-g •Hyper-G
444 snpp Простой протокол работы со страницами
512 - biff (exec) UNIX comsat (удаленное исполнение)
__513 - who UNIX rwho daemon
_ 514 - syslog Дневник системы
515 printer Работа с буфером печати (spooler)
EZ525 - timed Драйвер времени
Более полный перечень в RFC-1700; Если какой-то номер порта в перечне
0тсУтствует, это не означает, что он не зарезервирован и его можно использовать,
пР°сто я сэкономил место.
392
Гпава 4
Данные, отправляемые прикладным процессом через модуль UDP,
достигают места назначения как единое целое. Например, если про-
цесс-отправитель производит 5 записей в порт, то процесс-получа-
тель должен будет сделать 5 чтений. Размер каждого записанного
сообщения будет совпадать с размером каждого прочитанного. Про-
токол UDP сохраняет границы сообщений, определяемые приклад-
ным процессом. Он никогда не объединяет несколько сообщений в
одно и не делит одно сообщение на части. Формат UDP-сообщений
представлен ниже на рис. 4.4.2.1:
о 16
UDP-порт отправителя UDP-порт получателя
Длина UDP-сообщения UDP-контрольная сумма
Данные
Рис. 4.4.2.1 Формат UDP-дейтограмм
Длина сообщения равна числу байт в UDP-дейтограмме, включая
заголовок. Поле UDP контрольная сумма содержит код, полученный,
в результате контрольного суммирования UDP-заголовка и поля дан-
ные. Не трудно видеть, что этот протокол использует заголовок ми-
нимального размера (8 байт). Таблица номеров UDP-портов приведе-
на ниже (4.4.2.1). Номера портов от 0 до 255 стандартизованы и
использовать их в прикладных задачах не рекомендуется. Но и в
интервале 255-1023 многие номера портов заняты, поэтому прежде
чем использовать какой-то порт в своей программе, следует загля-
нуть в RFC-1700. Во второй колонке содержится стандартное имя,
принятое в Internet, а в третей — записаны имена, принятые в UNIX.
Зарегистрировано ряд портов для стандартного применения и в
диапазоне 1024-65535. Например:
Номер порта 1397 Обозначение audio-activmail
1398 video-activmail
5002 rfe
6000-6063 xll
7008 afs3-update
Назначение
Активная звуковая почта
Активная видео-почта
Радио-Ethernet
Система X Windows
Сервер-сервер актуализация
Модуль IP передает поступающий IP-пакет модулю UDP, если в
заголовке этого пакета указан код протокола UDP. Когда модуль
UDP получает дейтограмму от модуля IP, он проверяет контрольную
сумму, содержащуюся в ее заголовке. Если контрольная сумма рав-
Сети передачи данных. Метод доступа
393
на нулю, это означает, что отправитель ее не подсчитал. ICMP, IGMP,
UDP и TCP протоколы имеют один и тот же алгоритм вычисления
контрольной суммы (RFC-1071). Но вычисление контрольной сум-
мы для UDP имеет некоторые особенности. Во-первых, длина UDP-
дейтограммы может содержать нечетное число байт, в этом случае к
ней добавляется нулевой байт, который служит лишь для унифика-
ции алгоритма и никуда не пересылается. Во-вторых, при расчете
контрольной суммы для UDP и TCP добавляются 12-байтные псев-
до-заголовки, содержащие IP-адреса отправителя и получателя, код
протокола и длину дейтограммы (см. рис. 4.4.2.2). Как и в случае
IP-дейтограммы, если вычисленная контрольная сумма равна нулю,
в соответствующее поле будет записан код 65535.
0 8 16 31
IP-адрес отправителя
IP-адрес получателя
0 Протокол (17) Длина UDP-дейтограммы
UDP-заголовок
Данные
8 октетов
12
октетов
Рис. 4.4.2.2. Псевдозаголовок, используемый при
расчете контрольной суммы
Если контрольная сумма правильная (или равна 0), то проверя-
ется порт назначения, указанный в заголовке дейтограммы. Если
прикладной процесс подключен к этому порту, то прикладное сооб-
щение, содержащиеся в дейтограмме, становится в очередь к при-
кладному процессу для прочтения. В остальных случаях дейтог-
рамма отбрасывается. Если дейтограммы поступают быстрее, чем
их успевает обрабатывать прикладной процесс, то при переполне-
нии очереди сообщений поступающие дейтограммы отбрасываются
модулем UDP. Следует учитывать, что во многих посылках конт-
рольное суммирование не охватывает адреса отправителя и места
назначения. При некоторых схемах маршрутизации это приводит к
зацикливанию пакетов в случае повреждения его адресной части
(адресат не признает его «своим»).
Так как максимальная длина IP-дейтограммы равна 65535 бай-
там, максимальная протяженность информационного поля UDP-дей-
тограммы составляет 65507 байт. На практике большинство сис-
тем работает с UDP-дейтограммами с длиной 8192 байта или ме-
Нее- Детальное описание форматов, полей пакетов й пр. читатель
м°жет найти в RFC-768.
394
4.4.3. Протокол TCP
Протокол TCP (Transmission Control Protocol, RFC-793, -1323) в
отличии от UDP осуществляет доставку дейтограмм, называемых
сегментами, в виде байтовых потоков с установлением соединения.
Протокол TCP применяется в тех случаях, когда требуется гаран-
тированная доставка сообщений. Он использует контрольные сум-
мы пакетов для проверки их целостности и освобождает приклад-
ные процессы от необходимости таймаутов и повторных передач
для обеспечения надежности. Для отслеживания подтверждения
доставки в TCP реализуется алгоритм «скользящего» окна. Наи-
более типичными прикладными процессами, использующими TCP, е
являются FTP (File Transfer Protocol — протокол передачи файлов) -
и TELNET. Кроме того, TCP используют системы SMTP, НТТР,.Х- ?
Windows, RCP (Remote Сору), а также «г»-команды. Внутренняя ?
структура модуля TCP гораздо сложнее структуры UDP. Подобно
UDP прикладные процессы взаимодействуют с модулем TCP через
порты (см. таблицу 4.4Ч2.1 в предыдущей главе). Под байтовыми
потоками здесь подразумевается то, что один примитив, например,
READ или WRITE (см. [25]) может вызвать посылку адресату пос-
ледовательности сегментов, которые образуют некоторый блок дан-
ных (сообщение).
Примером прикладного процесса, использующего ветвь TCP, мо-
жет служить FTP, при этом будет работать стек протоколов FTP/
TCP/IP/ETHERNET. Хотя протоколы UDP и TCP могли бы для
сходных задач использовать разные номера портов, обычно этого не
происходит. Модули TCP и UDP выполняют функции мультиплек-
соров/демультиплексоров между прикладными процессами и IP-мо-
дулем. При поступлении пакета в модуль IP он будет передан в
TCP- или UDP-модуль согласно коду, записанному в поле протоко-
ла данного IP-пакета. Формат сегмента (пакета) TCP представлен
ниже на рис. 4.4.3.1.
Если IP-протокол работает с адресами, то TCP, также как и UDP,
с портами. Именно с номеров портов отправителя и получателя
начинается заголовок TCP-сегмента. Поле код позиции в сообще-
нии определяет порядковый номер первого октета в поле данных
пользователя. При значении флага SYN=1 в этом поле лежит код
ISN (смотри ниже описание процедуры установления связи). Поле
HLen - определяет длину заголовка сегмента, которая измеряется в
32-разрядных словах. Далее следует поле резерв, предназначенное
для будущего использования, в настоящее время должно обнулять-
ся. Поле размер окна сообщает, сколько октетов готов принять
Сети передачи данных. Метод доступа
395
получатель (флаг АСК=1). Окно имеет принципиальное значение,
^^^р^ляет число сегментов, которые могут быть посланы без
прпучеция подтвррждения. Значение ширины окна может варьиро-
ваться во время сессии (смотри описание процедуры «медленного
старта»). Значение этого поля равное нулю также допустимо и ука-
зывает, что байты вплоть до указанного в поле номер октета, ко-
торый должен прийти следующим, получены, но адресат временно
не может принимать данные. Разрешение на посылку новой инфор-
мации может быть дано с помощью посылки сегмента с тем же
значением поля номер октета, который должен прийти следую-
щим, но ненулевым значением поля ширины окна. Поле конт-
рольная сумма предназначено для обеспечения целостности сообще-
ния. Контрольное суммирование производится по модулю 1. Перед
контрольным суммированием к TCP-сегменту добавляется псаиттп-
заголовок, как и в случае протокола UDP, который включает в себя
адреса отправителя и получателя, код протокола и длину сегмента,
исключая псевдозаголовок. Поле указатель важной информации
представляет собой указатель последнего байта, содержащий ин-
формацию, которая требует немедленного реагирования. Поле имеет
смысл лишь при флаге URG=1, отмечающем сегмент с первым бай-
том «важной информации». Значение разрядов в 6-битовом коде
(флаги) описано в таблице 4.4.3.1. Если флаг АСК=О, значение
поля номер октета, который должен прийти следующим, игнори-
руется. Флаг URG=1 в случае нажатия пользователем клавиш DEL
или CTRL-C.
Таблица 4.4.3. ? Значения бит поля флаги
Обозначение битов (слева на право) поля флаги , Значение бита, если он равен 1
URG Флаг важной информации, поле Указатель важной информации имеет смысл, если URG=1.
АСК Номер октета, который должен был прийти следующим, правилен.
PSH Этот сегмент требует выполнения операции push. Получатель должен передать эти данные прикладной программе как можно быстрее.
, RST Прерывание связи.
SYN Флаг для синхронизации номеров сегментов, используется при установлении связи.
LZZZhff Отправитель закончил посылку байтов.
396
Глава 4
0 4 10 16 24
Порт отправителя Порт получателя
Код позиции в сообщении
Номер октета, который должен прийти следующим
HLen Резерв Флаги Размер окна
Контрольная сумма Указатель важной информации
Опции, если таковые имеются Заполнитель
Данные
Рис. 4.4.3.1 Формат ТСР-сегмента
Поле опции зарезервировано на будущее и в заголовке может
отсутствовать, его размер переменен и дополняется до кратного 32-
бит с помощью поля заполнитель. Формат поля опции представлен
на рис. 4.4.3.2. В настоящее время определены опции:
1. Конец списка опций.
2. Никаких операций. Используется для заполнения поля оп-
ции до числа октетов, кратного 4.
3. Максимальный размер сегмента (MSS).
В поле вид записывается код опции, поле len содержит число
октетов в описании опции, включая поля вид и len. Определены
также опции со значением вид=4,5,6,7. В предложении Т/ТСР
(RFC-1644) описаны опции 11, 12 и 13.
Поле данные в TCP-сегменте может и отсутствовать, характер и
формат передаваемой информации задается исключительно приклад-
ной программой, максимальный размер этого поля составляет в от-
сутствии опций 65495 байт. TCP является протоколом, который
ориентируется на согласованную работу ЭВМ и программного обес-
| Вид=2 1_еп=4 MSS | Формат опции MSS
И октет 1 октет 2 октета I
Вид=3 Len=3 Счетчик Формат опции масштаб окна Формат опции временной метки
1 октет 1 октет 1 октет
Вид=8 Len=10 Значение временной метки Отклик
1 октет 1 октет 4 октета 4 октета
Рис. 4.4.3.2. Формат опций для ТСР-сегментов
Сети передачи данных. Метод доступа 397
печения партнеров, участвующих в обмене информацией. Установ-
ление связи клиент-сервер осуществляется в три этапа:
1. Клиент посылает SYN-сегмент с указанием номера порта сер-
вера, который предлагается использовать для организации канала
связи (active open).
2. Сервер откликается, посылая свой SYN-сегмент, содержащий
идентификатор (ISN — Initial Sequence Number). Начальное значе-
ние ISN не равно нулю. Процедура называется passive open.
3. Клиент отправляет подтверждение получения SYN-сегмента
от сервера с идентификатором равным ISN(cepBepa)+l.
Стандартная процедура установления связи представлена на ри-
сунке 4.4.3.3 (под словом «стандартная» подразумевается отсут-
ствие каких-либо отклонений от штатного режима, например, одно-
временного открывание соединения со стороны сервера и клиента).
Если же соединение одновременно инициируется клиентом и серве-
ром, в конечном итоге будет создан только один виртуальный канал.
Сервер Клиент
SVN-RECEIVED
ESTABLISHED
Рис. 4.4.3.3. Алгоритм установления связи.
В рамках представлены состояния клиента и сервера; пункти-
ром отмечены изменения состояния после посылки сообщения (см.
также рис. 4.4.3.4)
Префикс S на рисунке указывает на сервер, а С - на клиента.
Параметры в скобках обозначают относительные значения ISN. После
установления соединения ISN(S) = S_SEQ_1, a ISN(C) = C_SEQ_1.
Каждое соединение должно иметь свой неповторимый код ISN.
Для реализации режима соединения прикладная программа на од-
398
Гпава 4
ном конце канала устанавливается в режим пассивного доступа
(«passive open»), а операционная система на другом конце ставится
в режим активного доступа («active open»). Протокол TCP предпо-
лагает реализацию 11 состояний (ESTABLISHED, CLOSED, LISTEN,
SYNJSENT, SYNRECEIVED и т.д.; см. также RFC-793), переход
между которыми строго регламентирован. Машина состояний для
протокола TCP может быть описана диаграммой, представленной
на рис. 4.4.3.4. Здесь состояние CLOSED является начальной и
конечной точкой последовательности переходов. Каждое соедине-
ние стартует из состояния CLOSED. Из диаграммы машины состоя-
ний видно, что многим из состояний не поставлен в соответствие
какой-либо таймер. Это означает, что машина состояний TCP мо-
жет оставаться в любом из состояний сколь угодно долго. Исклю-
чение составляет Keep-alive таймер, но его работа является опцион-
ной, а время по умолчанию составляет 2 часа. Это означает, что
машина состояния может оставаться 2 часа без движения. В случае,
когда две ЭВМ (С и S) попытаются установить связь друг с другом
одновременно, реализуется режим simultaneous connection (RFC-793).
Обе ЭВМ посылают друг другу сигналы SYN. При поучении этого
сигнала партнеры посылают отклики SYN+ACK. Обе ЭВМ должны
обнаружить, что SYN и SYN+ACK относятся к одному и тому же
соединению. Когда С и S обнаружат, что SYN+ACK соответствует
посланному ранее SYN, они выключат таймер установления соеди-
нения и перейдут непосредственно в состояние SYN_RECVD.
В состоянии ESTABLISHED пакет будет принят сервером, если
его ISN лежит в пределах S ACK, SACK+SWIND (S WIND -
ширина окна для сервера; см. рис. 4.4.3.5). Аналогичный диапазон
ISN для клиента выглядит как: С_АСК, C_ACK+C_WIND (C_WIND
- ширина окна для клиента). C_WIND и S_WIND могут быть не
равны. Пакеты, для которых эти условия не выполняются, будут
отброшены.
Рассмотрим пример установления соединения для случая FTP-
запроса (См. также http://www.cis.ohio-state.edu/~dolske/gradwork/
cis694q). Пусть клиент С запускает процесс установления FTP-co-
единения с сервером S. Обычный порядок установления соединения
показан ниже (см. рис. 4.4.3.3):
С S:SYN(ISNC)
S C:SYN(lSNs), ACK(ISNc)
С —» S: ACK(ISNs) (Связь установлена)
С —> S: данные
и/или
S —» С: данные
Сети передачи данных. Метод доступа
399
ISN - идентификатор пакета, посылаемого клиентом (С) или
сервером (S). Клиент, послав SYN серверу S, переходит в состоя-
ние SYN_SENT. При этом запускается таймер установления со-
единения.
Сервер, получив SYN, откликается посылкой другого SYN. Ког-
да С получает SYN от S (но не получает АСК, например, из-за его
потери или злого умысла), он предполагает, что имеет место случай
одновременного открытия соединения. В результате он посылает S
SYN_ACK, отключает таймер установления соединения и перехо-
дит в состояние SYNRECEIVED. Сервер получает SYN ACK от С,
но не посылает отклика. Тогда С ожидает получения SYN_ACK в
состоянии SYNRECEIVED. Так как время пребывания в этом со-
стоянии не контролируется таймером, С может остаться в состоя-
нии SYN_RECEIVED вечно.
Хотя TCP-соединение является полнодуплексным, при рассмот-
рении процесса разрыва связи проще его рассматривать как два
полудуплексных канала, каждый из которых каналов ликвидирует-
ся независимо. Сначала инициатор разрыва посылает сегмент с фла-
гом FIN, сообщая этим партнеру, что не намерен более что-либо
передавать. Когда получение этого сегмента будет подтверждено
(АСК), данное направление передачи считается ликвидированным.
При этом передача информации в противоположном направлении
может беспрепятственно продолжаться. Когда партнер закончит
посылку данных, он также пошлет сегмент с флагом FIN. По полу-
чении отклика АСК виртуальный канал считается окончательно
ликвидированным. Таким образом, для установление связи требу-
ется обмен тремя сегментами, а для разрыва — четырьмя. Но прото-
кол допускает совмещение первого АСК и второго FIN в одном
сегменте, сокращая полное число закрывающих сегментов с четырех
до трех.
Машина состояний для протокола TCP не предусматривает из-
менения состояний при посылке или получений обычных пакетов,
содержащих данные.
Когда оператор, работая в диалоговом режиме, нажимает коман-
дную клавишу, сегмент, в который помещается эта управляющая
последовательность, помечается флагом PSH (PUSH). Это говорит
приемнику, что информация из этого сегмента должна быть переда-
на прикладному процессу как можно скорее, не дожидаясь прихода
еЩе какой-либо информации. Сходную функцию выполняет флаг
URG. URG позволяет выделить целый массив данных, так как ак-
тивизирует указатель последнего байта важной информации. Будет
Ли какая-либо реакция на эту «важную» информацию определяет
400
Гпава 4
Начало
| CLOSED I*
Passive open
ничего не пересылается
' X passive openX^oz
( SYN RCVD )
________Recv: SYN
-J* send: SYN, ACK
s,mu^aneous °P€
LISTEN )
appl: close
или таймаут
close
Appl:
send: FIN
active open
{ SYN SENT )
( FIN WAIT 1
J1 ESTABLISHED J-X-dP •
Data transfer state
5 ........
simultaneous closd
^9
appl: * close
send:' FIN
Recv:
send:
ACK
<ничего>
CLOSING
\ recv: ! ACK
\ send? <ничего>
( LAST ACK 1
passive close,
recv: J ACK
send; <ничего>
'Ч
( FIN WAIT 2)re^: TIME WAIT U
<------------=—'send: ACKk-----=-------'
2MSL таймаут ;
active close
—► обозначает нормальный переход для клиента
- - ► обозначает нормальный переход для сервера
appl: обозначает изменение состояния, когда приложение
выдает команду
recv: обозначает изменение состояния, когда получен сегмент
send: обозначает то, что посылается при этом переходе
Рис. 4.4.3.4. Машина состояний для протокола TCP
(W.R. Stivens, TCP/IP Illustrated. V1. Addison-Wesley Publishing Company. 1993.)
I
прикладная программа получателя. URG-режим используется для 4
прерываний при работе с FTP, Telnet или Rlogin. Если до заверше- |
ния обработки «важной» информации придет еще один сегмент с
флагом URG, значение старого указателя конца «важного» сообще- ,
ния будет утеряно. Это обстоятельство должно учитываться при- 1
Сети передачи данных. Метод доступа
401
хладными процессами. Так Telnet в командных последовательнос-
тях всегда помещает префиксный байт с кодом 255.
В режиме удаленного терминала (Telnet) при нажатии любой кла-
виши формируется и посылается 41-октетный сегмент (здесь не учи-
тываются издержки Ethernet), который содержит всего один байт по-
лезной информации. Эффективность работы может быть улучшена с
помощью алгоритма Нагля (Nagle, 1984; RFC-896). Нагль предло-
жил при однобайтовом обмене посылать первый байт, а последую-
щие буферизовать до прихвда подтверждения получения посланного.
После этого посылаются все буферизованные октеты, а запись в бу-
фер вводимых кодов возобновляется. Если оператор вводит символы
быстро, а сеть работает медленно, этот алгоритм позволяет заметно
понизить загрузку канала. Встречаются, впрочем, случаи, когда алго-
ритм Нагля желательно отключить, например, при работе в Интер-
нет в режиме Х-терминала, где сигналы перемещения мышки долж-
ны пересылаться немедленно, чтобы не ввести в заблуждение пользо-
вателя относительно истинного положения маркера.
Существует еще одна проблема при пересылке данных по кана-
лам TCP, которая называется синдром узкого окна (silly window
syndrome; Clark, 1982). Такого рода проблема возникает в том слу-
чае, когда данные поступают отправителю крупными блоками, а ин-
терактивное приложение адресата считывает информацию побайт-
но. Предположим, что в исходный момент времени буфер адресата
полон и передающая сторона знает об этом (window=0). Интерак-
тивное приложение считывает очередной октет из TCP-потока, при
этом TCP-агент адресата посылает уведомление отправителю, раз-
решающее ему послать один байт. Этот байт будет послан и снова
заполнит до краев буфер получателя, что вызовет отправку АСК со
значением window=0. Этот процесс может продолжаться сколь угодно
долго, понижая коэффициент использования канала ниже паровоз-
ного уровня.
Кларк предложил не посылать уведомление о ненулевом значе-1
нии ширины окна при считывании одного байта, а лишь после осво- |\
б°ждения достаточно большого пространства в буфере. Например, | \
когда адресат готов принять MSS байтов или когда буфер наполо- Г \
вину пуст. ~ | \
Предполагается, что получатель пакета практически всегда по- . '
оылает отправителю пакет-отклик. Отправитель может послать оче- и *
Родной пакет, не дожидаясь получения подтверждения дд* щуущте /1 с
СТ^юЩего- Таким образом, может быть послано к пакетов, прежде®
нем будет получен отклик на первый пакет (протокол «скользяще- ц
го окна»), В протоколе TCP «скользящее окно» используется для
402
Гпава 4
регулировки трафика и препятствия переполнения буферов. Идея
скользящего окна отображена на рис. 4.4.3.5. Здесь предполагает-
ся, что ширина окна равна 7 (К==7; это число может меняться в
очень широких пределах).
|l 2 3 4 5 6 7~] 8 9 10 11 12....
|Окно, объявленное получателем | а)
" 3 4 5 6 7 8 | 9 10 11 12....
1 2
Посланы и
подтверждены
| 3 4 ~5
Посланы,
но не
подтверждены
гН Можно
|31 посылать
б)
10 11 12....
Эти пакеты
посылаться пока
не могут
Рис. 4.4.3.5. Схема использования скользящего окна
После прихода отклика на пакет <1> окно смещается вправо на
одну позицию. Теперь отправитель может послать и пакет <8>.
Если порядок прихода откликов нарушается, сдвиг окна может за-
держаться. Размер окна в сегментах определяется соотношением:
window > RTT*B/MS S,
где В - полоса пропускания канала в бит/с, a MSS - максималь-
ный размер сегмента в битах, a window — в сегментах.
Для протокола TCP механизм скользящего окна может рабо-
тать на уровне октетов или сегментов. В первом случае нужно
учитывать каждый раз размер поля данных переданного и подтвер-
жденного сегмента. В TCP-протоколе используется три указателя
(стрелки на рис. 4.4.3у$б):
Первый указатель определяет положение левого края окна, от-
деляя посланный сегмент, получивший подтверждение, от посланно-
го сегмента, получение которого не подтверждено. Второй указатель
отмечает правый край окна и указывает на сегмент, который может
быть послан до получения очередного подтверждения. Третий ука-
затель помечает границу внутри скользящего окна между уже по-
сланными сегментами и теми, которые еще предстоит послать. По-
лучатель организует аналогичные окна для обеспечения контроля
потока данных. Если указатель 3 совпадет с указателем 2, отправи-
тель должен прервать дальнейшую посылку пакетов до получения
хотя бы одного подтверждения. Обычно получатель посылает одно
подтверждение (АСК) на два полученных сегмента.
Сети передачи данных. Метод доступа
403
Регулирование трафика в TCP подразумевает существование двух ?
независимых процессов: контрольдоставки, управляемый получате-
лем с помощью параметра window, и контроль перегрузки, управляе-
мый отправителем с помощью окна перегрузки cwnd (congestion
window) и ssthreth (slow start threshold). Первый процесс отслежива-
ет заполнение входного буфера получателя, второй —^регистрирует ’
перегрузку канала, а также связанные с этим потери и понижает
уровень трафика. В исходный момент времени при установлений?со-
единения cwnd делается равным одному MSS, a ssthreth=65535 бай-
там. Программа, управляющая пересылкой, никогда не пошлет^боль-
ше байт, чем это задано cwnd и объявленным получателем значени-
ем window. Когда получение очередного блока данных подтверждено,
значение cwnd увеличивается. Характер этого увеличения зависит от I
того, осуществляется медленный старт или реализуется процедура L
подавления^перегрузки. Если cwnd меньше или равно,ssthreth, вы- i
полняется медленный старт, в противном случае осуществляется по-
давление перегрузки. В последнем случае cwnd.+1 = cwnd^ + MSS/8+
+(MSS*MSS)/cwnd. Если возникает состояние перегрузки канала зна-
чение cwnd снова делается равным одному MSS.
В качестве модуля приращения cwnd используется число MSS.
При получении подтверждения (АСК) окно перегрузки увеличива-
ется на один сегмент («медленный старт», cwnd.+1 = cwnd. + разме-
рсегмента, последнее слагаемое нужно, если размер окна задан в
октетах, в противном случае вместо него следует использовать 1) и
теперь отправитель может послать, не дожидаясь АСК, уже два сег-*7
мента и т.д.. Ширина окна, в конце концов, может стать настолько
большой, цто вероятность ошибки доставки в пределах окна станем *'
заметной. Тогда будет запущена процедура «медленного старта»
или другой алгоритм ^который определит новое, уменьшенное знач^Х\
ние окна cwnd. Окно^п^едедаки позволяет управлять информацион-
ным потоком cojcTopoHbi отправителя, блокируя возможные пере-
грузки и потери данных^промежуточных узлах сети (о других мето-
дах подавления перегрузки канала смотри раздел «Сети передачи
Данных»). Если переполнения не происходит^ cwnd становится боль- '
ше окна, объявленного получателем, и именно последнее будет огра-\^
ничивать поток данных в канале. Размер окна, объявленный получа-
телем, ограничивается произведением полосы пропускания канала
(бит/с) на RTT (время распространения пакета туда и обратно). Мак-
симально др^стимый размер окна в TCP равен 65535 байт (задает-
ся размером поля). Конечной целью регулирования трафика являет-
ся установление соответствия между темпом передачи и возможное-
тями приема. , ,
404
Гпава 4
Причиной перегрузки может быть не только ограниченность раз-
мера буфера, но и недостаточная пропускная способность какого-тп
* участка канала. Каждое из окон cwnd й window задает число бай-
тов, которое может послать отправитель. Реальное число байтов,
которое разрешено послать, равно минимальному из этих двух зна-
.. чений. При инициализации соединения окно перегрузки имеет ши-
рину равную максимальному сегменту, который может быть исполь-
;зован в данном канале. Отправитель посылает такой сегмент. Если
будет прислано подтверждение до истечения времени таймаута, раз-
мер окна перегрузки удваивается и посылается два сегмента макси-
мальной длины. При получении подтверждения доставки каждого
из сегментов окно перегрузки увеличивается на один сегмент мак-
симальной длины. Когда ширина окна перегрузки становится рав-
ной В сегментов и все В посланных сегментов получают подтвержде-
ние, окно перегрузки возрастает на число байт, содержащихся в этих
сегментах. Таким образом, ширина окна перегрузки последовательно
удваивается,_пока доставка всех сегментов подтверждается. Рост
i ширины окна перегрузки при этом имеет экспоненциальный харак-
тер. Это продолжается до тех пор, пока не наступит таймаут или
окно перегрузки не сравняется с окном получателя. Именно эта про-
цедура и называется медленным стартом (Джекобсон, 1988).
Как было сказайо выше, помимо окон перегрузки и получателя
в TCP.используется третий параметр — порог (иногда он называет-
ся порогом медленного старта ssthresh). При установлении соеди-
нений ssthresh=64 Кбайт/В случаё возникЕовёййХ5^имаута)значе- *
ssthresh делается равным cwnd/2, а само значение cwnd при-
Сравнивается MSS (см. рис. 4.4.3.6). Далее запускается процедура
j х t медленного старта, чтобы выяснить возможности канала. При этом
\ ,Л1 - г экспоненциальный рост cwnd осуществляется вплоть до значения
i ssthresh. Когда этот уровень cwnd достигнут, дальнейший рост про-
исходит линейно с приращением на каждом шагу равным MSS
(рис. 4.4.3.6).
, Здесь предполагается, что MSS=1 Кбайт. Началу диаграммы со-
f ! ответствует установка значения ssthresh=16 Кбайт. Данная схема
позволяет более точно выбрать значение cwnd. После таймаута, ко-
торый на рисунке произошел при передаче с номером 12, значение
порога понижается до 12 Кбайт (=cwnd/2). Ширина окна cwnd
снова начинает расти от передачи к передаче, начиная с одного сег-
мента, вплоть до нового значения порога ssthresh. Отратегия с экс-
поненциа^ным ил инейным участками изменения ширины бкя*
переполнения позволяет несколько приблизить среднее его значё*
ние к оптимальному. Для локальных сетей? где значение RTT неве-
Сети передачи данных. Метод доступа
405
Рис. 4.4.3.6. Эволюция ширины окна cwnd при медленном старте
лико, а вероятность потери пакета мала, оптимизация задания cwnd
не так существенна, как в случае протяженных внешних (например,
спутниковых) каналов. Ситуация может поменяться, если в локаль-
ной сети имеется участок, где вероятность потерь пакетов велика.
Таким участком может быть МАС-бридж (или переключатель), один
из каналов которого подключен к сегменту Fast Ethernet, а другой к
обычному Ethernet на 10 Мбит/с. Если такой мост не снабжен сис-
темой подавления перегрузки (до сих пор такие приборы не имели
подобных систем), то каждый из пакетов будет потерян в среднем 9
раз, прежде чем будет передан (здесь предполагается, что передача
идет из сегмента FE). При этом cwnd будет практически все время
равно MSS, что крайне неэффективно при передаче по каналам Ин-
тернет. Такие потери вызовут также определенные ошибки при вы-
числении среднего значения и дисперсии RTT, а^как следствиями
величин таймаутов. Применение в таких местах маршрутизаторов
или других приборов, способных реагировать на перегрузку посред-
ством 1СМР(4), решает эту проблему.
Для взаимного согласования операций в рамках ТСР-протокола
используется четыре таймера: 1 ’ '
1 • Таймер повторных передач (retransmission; RTO) контролиру-
ет время прихода подтверждений (АСК). Таймер запускается в мо-
Мент посылки сегмента. При получении отклика АСК до истечения
времени таймера, он сбрасывается. Если же время таймера истекает
Д° прихода АСК, сегмент посылается адресату повторно, а таймер
перезапускается.
406
Гпава 4
2. Таймер запросов (persist timer), контролирующий размер окна
даже в случае, когда приемное окно закрыто. При window=0 полу-
чатель при изменении ситуации посылает сегмент с ненулевым зна-
чением ширины окна, что позволит отправителю возобновить срою
работу. Но если этот пакет будет потерян, возникнет тупик, тогда
каждая из сторон ждет сигнала от партнера. Именно в этой ситуа-
ции и используется таймер запросов. По истечении времени этого
таймера отправитель пошлет сегмент адресату. Отклик на этот сег-
мент будет содержать новое значение ширины окна. Таймер запус-
кается каждый раз, когда получен сегмент с window=0.
3. Таймер контроля работоспособности (keepalive), который ре-
гистрирует факты выхода из строя или перезагрузки ЭВМ-партне-
ров. Время по умолчанию равно 2 часам. Keepalive-таймер не явля-
ется частью TCP-спецификации. Таймер полезен для выявления
состояний сервера half-open при условии, что клиент отключился
(например, пользователь выключил свою персональную ЭВМ, не вы-
полнив LOGOUT). По истечении времени таймера клиенту посыла-
ется сегмент проверки состояния. Если в течение 75 секунд будет
получен отклик, сервер повторяет запрос 10 раз с периодом 75 сек,
после чего соединение разрывается. При получении любого сегмен-
та от клиента, таймер сбрасывается и запускается вновь. ?
4. 2М8Ь-таймер (Maximum Segment Lifetime) контролирует вре-
мя пребывания канала в состоянии TIME_WAIT. Выдержка тайме-
ра по умолчанию равно 2 мин (FIN__WAIT-TaftMep). См. рис. 4.4.3.4.
и RFC-793. Таймер запускается при выполнении процедуры active
' close s момент посылки последнего АСК.
Важным пмраметромгопределтющтлпрабитаёТТар^метръг^райме-
ров, является RTT (время путешествия пакета до адресата и обрат-
но). TCP-агент самостоятельно измеряет RTT. Такие измерения
производятся периодически и по их результатам корректируется
среднее значение RTT:
RTTm = a*RTTm + (l-a)*RTT.,
где RTT. — результат очередного измерения, RTTm — величина, по-
лученная в результате усреднения предыдущих измерений, а — ко- ,
эффициент сглаживания, обычно равный 0.9. RFC-793 рекомендует
устанавливать время таймаута для ретрансмиссии (повторной пере- -
дачи), значение RTO — Retransmission TimeOut равно RTO=RTTm*b,
где b равно 2. От корректного выбора этих параметров зависит
эффективная работа каналов. Так занижение времени ретрансмис-
сии приводит к неоправданным повторным посылкам сегментов, :
Сети передачи данных. Метод доступа ‘407
перегружая каналы связичДля более точного выбора RTO необхо-
димо знать дисперсию RTT. Несколько более корректную оценку
RTO можно получить на следующих соотношений:
RTT = RTT + g(RTT.-RTT )
m m i m7
D = D + d(|RTT. — RTT J — D)
RTO = RTT + 4D,
где D — среднее отклонение RTT от равновесного значения, а коэф-
фициенты g = 0,125, d = 0,25. Чем больше g, тем быстрее растет
RTO по отношению к RTT. <^то хорошо работаёТ^Дд тех пор, пока не
произойдет таймаут и ретрансмиссия. В этом случае, получив АСК,
трудно решить, какому сегменту соответствует это подтверждение,
первому или второму. На эту проблему впервые обратил внимание
Фил Карн. Решением проблемы является приостановка коррекции
RTTm при таймауте и ретрансмиссиях.
Значение RTO зависит от пропускной способности канала и от
специфических задержек, например в случае спутниковых каналов.
В основном RTO лежит в секундном диапазоне (5-15 сек). Наибо-
лее вероятная причина потери пакетов — это перегрузка канала на и
участках между отправителем и приемником. Указанием на то, что V
пакет потерян, может служить таймаут или получение дубликата
сегмента АСК. Если произошел таймаут, система переходит в ре- '
жим «медленного старта». При инициализации канала переменная
ssthresh обычно равна 65535. Дублирование АСК индицирует по-
терю пакета до наступления таймаута. В этом случае сначала ме-
няется алгоритм приращения величины окна перегрузки cwnd (за-
медляется темп его роста). После прихода очередного АСК новое
значение cwnd вычисляется по формуле:
cwndi+1 = cwnd. + (MSS*MSS)/cwnd. + MSS/8
Если же в этот момент величина окна перегрузки меньше или
равна некоторому порогу (ssthresh — slow start threshold, обычно
измеряется в байтах), осуществляется «медленный старт». Следует
помнить, что TCP требует гюсылки немедленного подтверждения
(дублированного АСК) при обнаружении прихода сегментов с нару-
Шением порядка следования. Причиной нарушения порядка следо-
вания может быть флуктуация задержки в сети или потеря пакета.
три или более задублированных АСК, это является
указанием на потерю пакета и, не дожидаясь тайма-
а» осуществляется его повторная передача. Перехода в режим мед-
ли получено
Убедительным
408
Гпава 4
ленного старта в этом случае не производится, но понижаются зна-
чения cwnd и ssthresh (почти вдвое).
Когда TCP-канал закрывается и за время сессии переслано бо-
лее 16 полых окон, а адресат достижим не через маршрут по умол-
чанию, то в таблицу маршрутизации заносится следующая инфор-
мация: усредненное значение RTT, значение дисперсии RTT и ssthresh.
Если в ходе TCP-сессии получено сообщение 1СМР(4) (переполне-
ние канала — quench), требующее снижения потока данных, то cwdn
делается равным одному сегменту, а величина порога медленного
старта ssthresh не изменяется. На ICMP-сообщения о недостижимос-
ти сети или ЭВМ программы TCP-уровня не реагируют вообще.
Нулевой размер окна блокирует посылку информации и этим
система время от времени пользуется. Что произойдет, если получа-
тель послал сегмент, объявляющий окно ненулевым, а подтвержде-
ние получения этого сегмента не прошло? TCP-протокол не предус-
матривает посылки АСК на само подтверждение. Адресат ждет в
этом случае данных, так как он уже объявил о существовании не-
нулевого окна с помощью соответствующего АСК, а отправитель
ждет этого недошедшего АСК, чтобы начать передачу данных. Для
разрешения этой тупиковой ситуации используется таймер запро-
сов, который периодически посылает зондирующие сегменты полу-
чателю. Цель этого зондирования — выяснение существования окна
ненулевой ширины. Таймер запросов запускается при получении
информации об обнулении ширины окна приемником. Если за оп-
ределенное время не поступает сегмента, сообщающего об измене-
нии размера окна, таймер начинает посылать зондирующие сегмен-
ты. Таймер запросов использует базовую временную шкалу с перио-
дом в 500 мсек, а период посылки зондирующих сегментов лежит в
диапазоне 5-60 сек. Такой сегмент содержит только один байт дан-
ных. Таймер запросов не прерывает своей работы до тех пор, пока
не будет подтверждено открытие окна или пока прикладная задача
не завершит свою работу, выключив канал связи.
Будучи однажды создан, канал TCP может существовать «веч-
но». Если клиент и сервер пассивны, они не заметят того, например,
что какой-то бульдозер оборвал кабель или спутник связи покоит-
ся на дне океана. Чтобы это обнаружить, либо клиент либо сервер
должны попытаться послать какую-то информацию. Чтобы инфор-
мировать систему об этих и подобных им жизненных неурядицах,
предусмотрен таймер контроля работоспособности (keepalive). Мно-
гим читателям, возможно, приходилось легкомысленно выключать
питание своего персонального компьютера, не позаботившись о кор-
ректном logout из процедуры telnet или FTP. Если бы не суОДе*
Сети передачи данных. Метод доступа
409
ствовало этого таймера, включив ЭВМ, вы бы обнаружили, что «нахо-
дитесь» в заморском депозитарии, где были вчера. Но таймер конт-
роля работоспособности может и прервать сессию, если какой-то про-
межуточный маршрутизатор произвел перезагрузку или был вынуж-
ден поменять маршрут. Принцип работы таймера работоспособности
предельно прост. Если канал пассивен, например, 2 часа, сервер посы-
лает клиенту сегмент-зонд. При этом ЭВМ-клиент может быть в
одном из четырех состояний.
• Работоспособен и достижим для сервера. Отклик от клиента
сбросит таймер работоспособности в ноль (начало отсчета очеред-
ных двух часов).
' Вышел из строя, выключен или перезагружается. Сервер по-
сылает 10 запросов с интервалом 75 сек. Если отклика нет, канал
закрывается и со стороны сервера. ,
• Перезагрузился. Сервер получит отклик типа RESET и канал
будет закрыт.
• Работоспособен, но не достижим для сервера. Случай тожде-
ственен, описанному во втором по порядку пункте.
Временная постоянная таймера keepalive является системной
переменной единой для всех пользователей ЭВМ или даже локаль-
ной сети.
Расширение пропускной способности и надежности телекомму-
никационных каналов делает актуальной совершенствование про- |
токолов. Так как TCP является основным транспортным протоко- ii
лом, попытки усовершенствовать его предпринимаются, начиная с i
1992 года/ВЕС-1323, Якобсон, Браден и Борман). Целью этих усо- *
вершенствований служит повышение эффективности и пропускной
способности канала, а также обеспечение безопасности. При этом
рассматриваются следующие возможности:
• увеличение MTU (максимальный передаваемый блок данных);
• расширение окна за пределы 65535 байт;
• исключение «трех-сегментного» процесса установления связи
и «четырехсегментного» ее прерывания (Т/ТСР, RFC-1644);
• совершенствование механизма измерения RTT.
• оптимизация отслеживания CWND.
Оптимальный выбор MTU позволяет минимизировать или ис-
ключить фрагментацию (и последующую сборку) сегментов. Верх-
няя граница на MTU налагается значением MSS (максимальный
Размер сегмента). Разумно находить и запоминать оптимальные
значения MTU для каждого конкретного маршрута. Так как в со-
вРеменных системах используются динамические протоколы марш-
410
Гпава 4
рутизации, поиск оптимального MTU рекомендуется повторять каж-
дые 10 мин (RFC-1191).
Как уже отмечалось, размер TCP-окна определяется произведе-
нием полосы канала (в бит/с) на RTT в сек. Для Ethernet с полосой
10 Мбит/с и RTT=3 мсек это произведение равно 3750 байт, а для
канала ИТЭФ-ДЕЗИ с пропускной способностью 1,5 Мбит/с и
RTT=710 мсек (спутник) — 88750 байт, а это отнюдь не предел
современной телекоммуникационной технологии. Но уже эти при-
меры говорят о том, что максимально возможный размер окна дол-
жен быть увеличен в раз 10-100 уже сегодня. Протокол же разре-
шает 65535 байт. Появление столь мощных каналов порождает и
другие проблемы — потеря пакетов в них обходится слишком до-
рого, так как «медленный старт» и другие связанные с этим издер-
жки сильно снижают пропускную способность. В последнее время
алгоритм медленного старта заменяется более эффективными алго-
ритмами.
Простое увеличение ширины окна до тех пор, пока не произой-
дет сбой, плохая стратегия при использовании традиционного мед-
ленного старта, так как заметную часть времени ширина окна будет
неоптимальной - то слишком большой, то слишком малой. Опти-
мальная стратегия должна включать в себя прогнозирование опти-
мальной ширины окна. В новых версиях модулей TCP реализуются
именно такие алгоритмы. В 1994 году Бракмо предложил вариант
стратегии изменения параметров передачи, который на 40-70% по-
вышает пропускную способность ТСР-канала.
Существуют и другие, могущие показаться забавными пробле-
мы. Каждый сегмент в TCP-протоколе снабжается 32-битным иден-
тификатором. Время жизни IP-пакета (TTL) определяется по мак-
симуму 255 шагами или 255 секундами в зависимости оттого, что
раньше наступит. Трудно предсказуемая ситуация может произой-
ти, когда канал ликвидирован, затем создан снова (для той же ком-
бинации IP-адресов и портов), а какой-то пакет из предшествующей
сессии, погуляв по Интернет, придет уже во время следующей. Есть
ли гарантия, что он будет верно идентифицирован? Одной из мер»
упомянутых ранее, можно считать использование ограничения по
максимальному времени жизни сегмента (MSL) или TTL, хотя сни-
жение значения TTL не всегда возможно — ведь IP-пакетами пользу-
ется не только TCP-протокол и нужна очень гибкая система зада-
ния его величины. Во многих приложениях MSL=30 сек (рекомен-
дуемое значение 2 мин слишком велико). Технический прогресс
ставит и некоторые новые проблемы. Высокопроизводительные ка-
налы (1 Гбит/с) уже сегодня могут исчерпать разнообразие идентИ*
Сети передачи данных. Метод доступа
411
фикационных кодов пакетов за один сеанс связи. Появление же
двух пакетов с равными идентификаторами может породить нераз-
решимые трудности. Для передачи мегабайтного файла по гигабит-
ному каналу требуется около 40 мсек (при этом предполагается, что
задержка в канале составляет 32 мсек (RTT=64 мсек)). Собственно
передача этой информации занимает 8 мсек. Из этих цифр видно,
что традиционные протоколы, размеры окон и пр. могут свести на
нет преимущества скоростного (дорогостоящего) канала. Пропуск-
ная способность такого канала определяется уже не его полосой, а
задержкой. Понятно также, что необходимо расширить поле разме-
ра окна с 16 до 32 бит. Чтобы не изменять формат ТСР-сегментов,
можно сделать код размера окна в программе 32-разрядным, сохра-
нив соответствующее поле в сегменте неизменным. Размер окна в
этом случае задается как бы в формате с плавающей запятой. При
установлении канала определяется масштабный коэффициент п (по-
рядок) лежащий в интервале 0-14. Передача этого коэффициента
(один байт) осуществляется сегментом SYN в поле опций. В резуль-
тате размер окна оказывается равным 65535*2П. Если один из парт-
неров послал ненулевой масштабный коэффициент, но не получил
такого коэффициента от своего партнера по каналу, то п считается
равным нулю. Эта схема позволит сосуществовать старым и но-
вым системам. Выбор п возлагается на TCP-модуль системы.
Для того чтобы точнее отслеживать вариации RTT, предлагает-
ся помещать временные метки в каждый посылаемый сегмент. Так
как в TCP используется одно подтверждение АСК на несколько
сегментов, правильнее будет сказать, что RTT измеряется при по-
сылке каждого АСК. Способность и готовность партнеров работать
в таком режиме временных меток определяется на фазе установле-
ния канала. Более точное вычисление RTT позволяет не только
корректно выбрать временные постоянные для таймеров, правильно
вычислить задержку TIME WAIT (TIME_WAIT=8*RTO), но и от-
фильтровать «старые» сегменты. Идеология временных меток ис-
пользуется и в алгоритме PAWS (Protection Against Wrapped Sequence
Numbers) для защиты против перепутывания номеров сегментов.
Предлагаемое усовершенствование TCP — Т/ТСР модифицирует
алгоритмы выполнения операций. Т/ТСР вводит новую 32-битную
системную переменную — число соединений (СС). СС позволяет со-
кратить число пересылаемых сегментов при установлении канала, а
также отфильтровывать «старые» сегменты, не принадлежащие дан-
ной сессии (установленной связи). Время отклика клиента в рамках
Указанных алгоритмов сокращается до суммы RTT и времени обра-
°тки запроса процессором. Данные пришедшие до SYN-сегмента
412
Гпава 4
должны буферизоваться для последующей обработки, а не отбрасы-
ваться.
Ethernet (10 Мбит/с) в идеальных условиях позволяет осуще-
ствить обмен в рамках протокола TCP (например, при FTP-сессии)
со скоростью 1,18 Мбайт/с.
Как уже отмечалось, максимальная длина сегмента (MSS —
Maximum Segment Size) в TCP-обменах величина переменная. Дли-
на сегмента определяет длину кадра, в который он вложен. Для
локальных Ethernet-сетей MSS=1460 октетов. Чем длиннее кадр,
тем выше пропускная способность сети (меньше накладные расхо-
ды на заголовок кадра). С другой стороны, при передаче дейтограмм
по внешним каналам, где размер пакета не столь велик, большое
значение MSS приведет к фрагментации пакетов, которая замедлит
обмен, поэтому администратор сети должен взвешивать последствия,
задавая значения размера сегментов. Если MSS явно не задан, уста-
навливается значение по умолчанию (536 байт), что соответствует
576-байтной IP-дейтаграмме. Для нелокальных адресов — это, как
правило, разумный выбор.
Ликвидация связи требует посылки четырех сегментов. ТСР-
протокол допускает возможность, когда один из концов канала объяв-
ляет о прекращении посылки данных (посылает FIN-сегмент), про-
должая их получать (режим частичного закрытия — half-close).
Посылка сегмента FIN означает выполнение операции active close.
Получатель FIN-сегмента должен послать подтверждение его полу-
чения. Когда противоположный конец, получивший FIN, закончит
пересылку данных, он пошлет свой FIN-сегмент. Прием подтверж-
дения на получение этого сегмента означает закрытие данного ка-
нала связи. Возможно прерывание связи и с помощью посылки
RST-сегмента. В этом случае вез буферы и очереди очищаются не-
медленно и часть информации будет потеряна.
4.4.4. Протокол передачи команд и сообщений об ошибка*
[ICMP)
Базовым протоколом Интернет является IP. Он не контролиру-
ет корректность обмена, эта функция возлагается на ICMP-прото-
кол. Задача ICMP-протокола диагностировать и сообщать о сбоях И
ошибках, а не гарантировать правильность работы.
Протокол передачи команд и сообщений об ошибках (ICMP
Internet Control Message Protocol, RFC-792, — 1256) выполняет мно-
гие и не только диагностические функции, хотя у рядового пользу
вателя именно этот протокол вызывает раздражение, сообщая °0
Сеги передачи данных. Метод доступа 413
его ошибках или сбоях в сети. Именно этот протокол используется
программным обеспечением ЭВМ при взаимодействии друг с другом
в рамках идеологии TCP/IP. Осуществление повторной передачи
пакета, если предшествующая попытка была неудачной, лёжит на
TCP или прикладной программе. При пересылке пакетов промежу-
точные узлы не информируются о возникших проблемах, поэтому
ошибка в маршрутной таблице будет восприниматься как неисп-
равность в узле адресата и достоверно диагностироваться не будет.
ICMP-протокол сообщает об ошибках в IP-дейтограммах, но не дает
информации об ошибках в самих ICMP-сообщениях. ICMP исполь-
зует IP, а IP-протокол должен использовать ICMP. В случае IP-
фрагментации сообщение об ошибке будет выдано только один раз
на дейтограмму, даже если ошибки были в нескольких фрагментах.
Подводя итоги, можно сказать, что ICMP-протокол осуществляет:
• передачу отклика на пакет или эхо на отклик;
• контроль времени жизни дейтограмм в системе;
• реализует переадресацию пакета;
• выдает сообщения о недостижимости адресата или о некор-
ректности параметров;
• формирует и пересылает временные метки;
• выдает запросы и отклики для адресных масок и другой ин-
формации.
ICMP-сообщения об ошибках никогда не выдаются в ответ на:
• ICMP-сообщение об^ошибке.
• При мультикастинх/йли широковещательной адресации.
• Для фрагмента дейтограммы (кроме первого).
• Для дейтограмм, чей адрес отправителя является нулевым
или мультикастинговым.
Эти правила призваны блокировать потоки дейтограмм, посылаемым
в отклик на мультикастинг или широковещательные ICMP-сообщения.
ICMP-сообщения имеют свой формат, а схема их вложения ана-
логична UDP или TCP и представлена на рис. 4.4.4.1.
<4— 20 байт —► ICMP-заголовок ICMP данные
Заголовок дейтограммы Область данных дейтограммы (IP)
Заголовок кадра Область данных кадра
рис. 4.4.4.1. Схема вложения ICMP-пакетов в Ethernet-кадр
414
Гпава 4
Все ICMP пакеты начинаются с 8-битного поля типа ICMP и
его кода (15 значений). Код уточняет функцию ICMP-сообщения.
Таблица этих кодов приведена ниже (символом * помечены сооб-
щения об ошибках, остальные - являются запросами):
Процедура «отключение источника» (quench, поле тип 1СМР=4)
позволяет управлять потоками данных в каналах Интернет. Не справ-
ляясь с обработкой дейтограмм, ЭВМ-адресат может послать запрос
«отключить источник» отправителю, который может сократить темп
или вовсе прервать посылку пакетов. Специальной команды, отменяю-
щей прежние запреты, не существует. Если сообщения об отключении
прекращаются, источник может возобновить посылку пакетов или уве-
личить частоту их отправки. Ниже (на рис. 4.4.4.2) представлен фор-
мат эхо-запроса (ping) и отклика для протокола ICMP.
О 8 16 31
Тип (8 или 0) Код(О) Контрольная сумма
Идентификатор Номер по порядку
Данные
Рис. 4.4.4.2. Формат эхо-запроса и отклика ICMP
Поля идентификатор и номер по порядку служат для того,
чтобы отправитель мог связать в пары запросы и отклики. Поле
тип определяет, является ли этот пакет запросом (8) или откли-
ком (0). Поле контрольная сумма представляет собой 16-разряд-
ное дополнение по модулю 1 контрольной суммы всего 1СМР-сооб-
щения, начиная с поля тип. Поле данные служит для записи ин-
формации, возвращаемой отправителю. При выполнении процедуры
Ping эхо-запрос с временной меткой в поле данные посылается ад-
ресату. Если адресат активен, он принимает IP-пакет, меняет адрес
отправителя и получателя местами и посылает его обратно. ЭВМ-
отправитель, восприняв этот отклик, может сравнить временную метку, 4
записанную в пакет, с текущим показанием внутренних часов и <
определить время распространения пакета (RTT— Round Trip Time). „
Размер поля данные не регламентирован и определяется предель- <
ним размером IP-пакета.
ICMP-запрос I ICMP-отклик
-------------------► |------------------►
◄-------------------RTT------------------► '
Сети передачи данных. Метод доступа
415
Таблица 4.4.4.1. Типы и коды ICMP-сообщений.
ICMP-сообщение Описание сообщения
Тип Код
' 0 Эхо-ответ (ping-отклик)
3 1 Адресат недостижим
0 * Сеть недостижима
1 * ЭВМ не достижима
2 * Протокол не доступен
3 * Порт не доступен
4 * Необходима фрагментация сообщения
5 * Исходный маршрут вышел из строя
6 * Сеть места назначения не известна
7 * ЭВМ места назначения не известна
8 * Исходная ЭВМ изолирована
9 * Связь с сетью места назначения административно запрещена
10 * Связь с ЭВМ места назначения административно запрещена
11 * Сеть не доступна для данного вида сервиса
12 * ЭВМ не доступна для данного вида сервиса
13 * Связь административно запрещена с помощью фильтра.
.14 * Нарушение старшинства ЭВМ
15 * Дискриминация по старшинству
4 0 * Отключение источника при переполнении очереди
5 Переадресовать (изменить маршрут)
0 Переадресовать дейтограмму в сеть (устарело)
1 Переадресовать дейтограмму на ЭВМ
2 Переадресовать дейтограмму для типа сервиса (TOS) и сети
3 Переадресовать дейтограмму для типа сервиса и ЭВМ
8 0 Эхо запроса (Ping-запрос).
9 0 Объявление маршрутизатора
10 0 Запрос маршрутизатора
11 Для дейтограммы время жизни истекло (TTL=0):
0 *при передаче
1 * при сборке (случай фрагментации).
12 * Проблема с параметрами дейтограммы
0 * Ошибка в IP-заголовке
Г 1 * Отсутствует необходимая опция
__13 Запрос временной метки '
—Н__ Временная метка-отклик
__15 Запрос информации (устарел)
Информационный отклик (устарел)
Запрос адресной маски
LZnr_ Отклик на запрос адресной маски
416
Гпава 4
Время распространения ICMP-запроса, вообще говоря, не равц0
времени распространения отклика. Это связано не только с возмож-
ными изменениями в канале. В общем случае маршруты их движе-
ния могут быть различными.
Когда маршрутизатор не может доставить дейтаграмму по месту
назначения, он посылает отправителю сообщение «адресат не дости-
жим» (destination unreachable). Формат такого сообщения показав
ниже (на рис. 4.4.4.3).
О 8 16 31
Тип (3) Код Контрольная сумма
Не используется, заполняется нулями MTU на следующем этапе
Internet-заголовок (включая опции) + первые 64 бита дейтограммы
Рис. 4.4.4.3. Формат ICMP-сообщения «адресат не достижим»
Поле код содержит целое число, проясняющее положение дел.
Перечень кодов таких сообщений помещена в таблице 4.4.4.1. Поле
MTU на следующем этапе характеризует максимальную длину па*
кетов на очередном шаге пересылки.
Так как в сообщении содержится Интернет-заголовок и первые
64-бита дейтограммы, легко понять, какой адрес оказался недости-
жим. Этот тип ICMP-сообщения посылается и в случае, когда дей-
таграмма имеет флаг DF=1 («не фрагментировать»), а фрагментаций
необходима. В поле код в этом случае будет записано число 4.
Если буфер приема сообщения переполнен, ЭВМ посылает сооб-
щение типа 4 для каждого из не-записанных в буфер сообщений.
Так как собственные часы различных ЭВМ имеют свое представ-
ление о времени, протокол ICMP, среди прочего, служит для синхро-
низации работы различных узлов, если это требуется (запросы вре-
менных меток). Протокол синхронизации NTP (Network Tin#
Protocol) описан в RFC-1119.
Когда дейтограммы поступают слишком часто и принимают#1
сторона не справляется с этим потоком, отправителю может быть
послано сообщение с требованием резко сократить информаций#*
ный поток (quench-запрос), снижение потока должно продолжаться
до тех пор, пока не прекратятся quench-запросы. Такое сообщен^
имеет формат:
417
Рис. 4.4.4.4. Формат ICMP-запроса снижения загрузки
В Internet таблицы маршрутизации остаются без изменений дос-
таточно долгое время, но иногда таблицы все же меняются. Если
маршрутизатор обнаружит, что ЭВМ использует неоптимальный
маршрут, он может послать ей ICMP-запрос переадресации. Формат
такого сообщения отображен на рисунке 4.4.4.5.
О 8 16 31
Тип (5) Код(О) Контрольная сумма
Internet-адрес маршрутизатора
Internet-заголовок + первые 64 бита дейтограммы
Рис. 4.4.4.S. Формат ICMP-запроса переадресации
Поле Internet-adpec маршрутизатора содержит адрес маршрути-
затора, который ЭВМ должна использовать, чтобы посланная дей-
тограмма достигла места назначения, указанного в ее заголовке. В
поле Internet-заголовок кроме самого заголовка лежит 64 первых
бита дейтограммы, вызвавшей это сообщение. Поле код специфици-
рует то, как нужно интерпретировать адрес места назначения (см.
табл. 4.4.4.1).
Команды переадресации маршрутизатор посылает только ЭВМ и
никогда другим маршрутизаторам. Рассмотрим конкретный при-
МеР. Пусть некоторая ЭВМ на основе своей маршрутной таблицы
посылает пакет маршрутизатору Ml. Он, просмотрев свою маршрут-
пую таблицу, находит, что пакет следует переслать маршрутизатору
Причем выясняется, что пакет из Ml в М2 следует послать
Перез тот же интерфейс, через который он попал в Ml. Это означает,
Чт° ^2 доступен и непосредственно для ЭВМ-отправителя. В такой
Ситуации посылает ICMP-запрос переадресации ЭВМ-отправите-
3430 Семенов
418
Гпава 4
лю указанного пакета с тем, чтобы она внесла соответствующие
коррективы в свою маршрутную таблицу.
Маршрутная таблица может загружаться из файла, формиро-
ваться менеджером сети, но может создаваться и в результате зап-
росов и объявлений, посылаемых маршрутизаторами. После загруз-
ки системы маршрутизатор посылает широковещательный запрос.
Один или более маршрутизаторов посылают в ответ сообщения об
имеющейся маршрутной информации. Кроме того, маршрутизаторы
периодически (раз в 450-600 сек.) широковещательно объявляют о
своих маршрутах, что позволяет другим маршрутизаторам скор-
ректировать свои маршрутные таблицы. В RFC-1256 описаны фор-
маты ICMP-сообщений такого рода (см. рис. 4.4.4.6).
0 8 16 31
Тип (9) Код(О) Контрольная сумма
Число адресов Длина адреса (2) Время жизни
Адрес маршрутизатора [1]
Уровень приоритета [1]
Адрес маршрутизатора [2]
Уровень приоритета [2]
Рис. 4.4.4.6. Формат ICMP-сообщений об имеющихся маршрутах
Поле число адресов характеризует количество адресных записей
в сообщении. Поле длина адреса содержит число 32-битных слов,
необходимых для описания адреса маршрутизатора. Поле время
жизни предназначено для записи продолжительности жизни объяв-
ленных маршрутов (адресов) в секундах. По умолчанию время жиз-
ни равно 30 мин. Поля уровень приоритета представляют собой
меру приоритетности маршрута по отношению к другим маршру-
там данной подсети. Чем больше этот код тем выше приоритет-
Маршрут по умолчанию имеет уровень приоритета 0. Формат зап-
роса маршрутной информации (8 октетов, рис. 4.4.4.7).
Так как следующий прогон (hop) дейтограммы определяется на
основании локальной маршрутной таблицы, ошибки в последней
могут привести к зацикливанию пакетов. Для подавления таких
циркуляций используется контроль по времени жизни пакета (TTL)-
Сеги передачи данных. Метод доступа
41Э
О 8
31
Тип (10) Код(О) Контрольная сумма
Не используется, заполняется нулями
Рис. 4.4.4.7 Формат запроса маршрутной информации
При ликвидации пакета по истечении TTL маршрутизатор посыла-
ет отправителю сообщение «время истекло», которое имеет формат
(рис. 4.4.4.8):
0 8 16 31
Тип (11) Код(0 или 1) Контрольная сумма
Не используется, заполняется нулями
Internet-заголовок + первые 64 бита дейтограммы
Рис. 4.4.4.8. Формат сообщения «время (TTL) истекло»
Значение поля код определяет природу тайм-аута (см. табл.
4.4.4.1).
Когда маршрутизатор или ЭВМ выявили какую-либо ошибку, не
из числа описанных выше (например, нелегальный заголовок дей-
тограммы), посылается сообщение «конфликт параметров». Это мо-
жет произойти при неверных параметрах опций. При этом посыла-
ется сообщение вида (рис. 4.4.4.9):
0 8 16 31
Тип (12) Код(0 или 1) Контрольная сумма
Указатель Не используется, заполняется нулями
Internet-заголовок + первые 64 бита дейтограммы
Рис. 4.4.4.9. Формат сообщения типа «конфликт параметров»
Поле указатель отмечает октет дейтограммы, который создал про-
блему. Код=1 используется для сообщения о том, что отсутствует тре-
буемая опция (например, опция безопасности при конфиденциальных
°бменах), поле указатель при значении поля код=1 не используется.
420
Гпава 4
В процессе трассировки маршрутов возникает проблема синхро-
низации работы часов в различных ЭВМ. К счастью синхронизация
внутренних часов ЭВМ требуется не так часто (например, при вы-
полнении синхронных измерений), негативную роль здесь могут иг-
рать задержки в каналах связи. Для запроса временной метки дру-
гой ЭВМ используется сообщение запрос временной метки, которое
вызывает отклик с форматом (рис. 4.4.4.10):
08 16 31
Тип (13 или 14) Код(О) Контрольная сумма
Идентификатор Номер по порядку
Исходная временная метка
Временная метка на входе
Временная метка на выходе
1Рис. 4.4.4.10. Формат ICMP-запроса временной метки
Поле mun=13 указывает на то, что это запрос, а тип=14 — на то,
что это отклик. Поле идентификатор и номер по порядку исполь-
зуются отправителем для связи запроса и отклика. Поле исходная
временная метка заполняется отправителем непосредственно пе-
ред отправкой пакета. Поле временная метка на входе заполняет-
ся маршрутизатором при получении этого пакета, а Временная метка
на выходе, — непосредственно перед его отправкой. Именно этот
формат используется в процедурах Ping. Эти процедуры позволяют
не только диагностировать, но и оптимизировать маршруты.
Сети передачи данных. Метод доступа
421
О 8 16 31
Тип (17 или 18) Код(О) Контрольная сумма
Идентификатор Номер по порядку
Адресная маска
Рис. 4.4.4.11. Формат запроса (отклика] маски субсети
Поле тип здесь специфицирует модификацию сообщения, тип=17
— это запрос, а тип=18 — отклик. Поля идентификатор и номер
по порядку, как обычно, обеспечивают взаимную привязку запроса и
отклика, а поле адресная маска содержит 32-разрядную маску суб-
сети.
422
Гпава 4
4.4.5. Протокол ARP
Любое устройство, подключенное к локальной сети (Ethernet, FDDI
и т.д.), имеет уникальный физический сетевой адрес, заданный ап-
паратным образом. 6-байтовый Ethernet-адрес выбирает изготови-
тель сетевого интерфейсного оборудования из выделенного для него
по лицензии адресного пространства. Если у машины меняется се-
тевой адаптер, то меняется и ее Ethernet-адрес.
4-байтовый IP-адрес задает менеджер сети с учетом положения
машины в сети Интернет. Если машина перемещается в другую
часть сети Интернет, то ее IP-адрес должен быть изменен. Преобра-
зование IP-адресов в сетевые выполняется с помощью ARP-табли-
цы. Каждая машина сети имеет отдельную ARP-таблицу для каж-
дого своего сетевого адаптера. Не трудно видеть, что существует
проблема отображения физического адреса (6 байт для Ethernet) в
пространство сетевых IP-адресов (4 байта) и наоборот.
Протокол ARP (Address Resolution Protocol, RFC-826) решает
именно эту проблему — преобразует IP- в Ethernet-адреса.
Рассмотрим процедуру преобразования адресов при отправле-
нии сообщения. Пусть прикладная программа одной ЭВМ отправ-
ляет сообщение другой. Прикладной программе IP-адрес места на-
значения обычно известен. Для определения Eternet-адреса просмат-
ривается ARP-таблица. Если для требуемого IP-адреса в ней
присутствует Ethernet-адрес, то формируется и посылается соответ-
ствующий пакет. Если же с помощью ARP-таблицы не удается пре-
образовать адрес, то выполняется следующее:
1. Всем машинам в сети посылается пакет с ARP-запросом (с
широковещательным Ethernet-адресом места назначения).
2. Исходящий IP-пакет ставится в очередь.
Каждая машина, принявшая ARP-запрос, в своем ARP-модуле
сравнивает собственный IP-адрес с IP-адресом в запросе. Если IP-
адрес совпал, то прямо по Ethernet-адресу отправителя запроса по-
сылается ответ, содержащий как IP-адрес ответившей машины, так
и ее Ethernet-адрес. После получения ответа на свой ARP-запрос
машина имеет требуемую информацию о соответствии IP и Ethernet-
адресов, формирует соответствующий элемент ARP-таблицы и от-
правляет IP-пакет, ранее поставленный в очередь. Если же в сети
нет машины с искомым IP-адресом, то ARP-ответа не будет и не
будет записи в ARP-таблицу. Протокол IP будет уничтожать IP-
пакеты, предназначенные для отправки по этому адресу.
Протоколы верхнего уровня не могут отличить случай поврежде-
ния в среде Ethernet от случая отсутствия машины с искомым IP-
Сети передачи данных. Метод доступа
423
адресом. Во многих реализациях в случае, если IP-адрес не принадле-
жит локальной сети, внешний порт сети (Gateway) или маршрутизатор
откликается, выдавая свой физический адрес (режим прокси-ARP).
Функционально, ARP делится на две части. Одна — определяет
физический адрес при посылке пакета, другая отвечает на запросы
других машин. ARP-таблицы имеют динамический характер, каждая
запись в ней «живет» определенное время после чего удаляется. Ме-
неджер сети может осуществить запись в ARP-таблицу, которая там
будет храниться «вечно». ARP-пакеты вкладываются непосредствен-
но в Ethernet-кадры. Формат ARP-пакета показан на рис. 4.4.5.1.
О 8
16 24 31
Тип оборудования Тип протокола
HA-Len PA-Len Код операции
Аппаратный адрес отправителя (октеты 0....3)
Адрес отправителя (октеты 4,5) IP- адрес отправителя (октеты 0,1)
IP- адрес отправителя (октеты 2,3) Аппаратный адрес адресата (0,1)
Аппаратный адрес адресата (октеты 2-5)
IP-адрес адресата (октеты 0-3)
Рис. 4.4.5Л. Формат пакета ARP
HA-Len — длина аппаратного адреса; PA-Len - длина прото-
кольного адреса (длина в байтах, например, для IP-адреса PA-Len=4).
Tun оборудования — это тип интерфейса, для которого отправитель
ищет адрес; код содержит 1 для Ethernet. Ниже представлена таб-
лица 4.4.5.1 кодов оборудования.
Таблица 4.4.5.1. Коды оборудования
Код типа оборудования Описание
1 Ethernet (10 Мбит/с)
2 Экспериментальный Ethernet (3 Мбит/с)
3 Радиолюбительская связь через Х.25
. 4 Proteon ProNET маркерная кольцевая сеть (Token Ring)
5 Chaos
6 Сети IEEE 802
7 ARCNET
424
Гпава 4
Таблица 4.4.5.2. Коды типов протокола (для IP это 0800Н).
Код типа протокола Описание
Десятичное значение Hex
512 0200 XEROX PUP
513 0201 PUP трансляция адреса
1536 0600 XEROX NS IDP
2048 0800 DOD Internet протокол (IP)
2049 0801 X.75 Internet
2050 0802 NBS Internet
2051 0803 ECMA Internet
2052 0804 Chaosnet
2053 0805 Х.25 уровень 3
2054 0806 Протокол трансляции адреса (ARP)
2055 0807 XNS совместимость
2560 0А00 Xerox IEEE-802.3 PUP
4096 1000 Bercley Trailer
21000 5208 BBN Simnet
24577 6001 DEC MOP Dump/Load
24578 6002 DEC MOP удаленный терминал
24579 6003 DEC DECnet фаза IV
24580 6004 DEC LAT
24582 6005 DEC
24583 6006 DEC
32773 8005 HP Probe
32784 8010 Excelan
32821 8035 Реверсивный протокол ARP (RARP)
32824 8038 DEC LANbridge
32923 8098 Appletalk
33100 814С SNMP
Поле код операции определяет, является ли данный пакет ARP-
запросом (код = 1), ARP-откликом (2), RARP-запросом (3), или
RARP-откликом (4). Это поле необходимо, как поле тип кадра в
Ethernet пакетах, они идентичны для ARP-запроса и отклика.
ARP-таблицы строятся согласно документу RFC-1213 и для каж-
дого IP-адреса содержит четыре кода:
ifindex физический порт (интерфейс), соответствующий
данному адресу;
Физический (ап- МАС-адрес, например Ethernet-адрес;
паратный) адрес
IP-адрес IP-адрес, соответствующий физическому адресу;
тип адресного это поле может принимать 4 значения: 1 — вари-
соответствия ант не стандартный и не подходит ни к одному из
описанных ниже типов; 2 — данная запись уже
Сети передачи данных. Метод доступа
425
не соответствует действительности; 3 — постоян-
ная привязка; 4 — динамическая привязка;
В SUN и некоторых других ЭВМ имеется программа агр, которая
позволяет отобразить ARP-таблицу на экране. С флагом -а коман-
да отображает всю таблицу, флаг -d позволяет стереть запись, a -s
__ служит для внесения записей в таблицу (последние два флага
доступны для операторов с системными привилегиями). Команда
ARP без флагов с адресом или именем ЭВМ выдаст соответствую-
щую строку таблицы:
агр 192.148.166.129
Name: semenov.itep.ru
Address: 192.148.166.129 (IP-адрес моей персональной ЭВМ)
Aliases: yas
А команда
агр пЪ
выдаст запись
nb (193.124.224.60) at 0:80:ad:2:24:b7
(запись для NetBlazer ИТЭФ)
ARP запросы могут решать и другие задачи. Так при загрузке
сетевого обеспечения ЭВМ такой запрос может выяснить, а не при-
своен ли идентичный IP-адрес какому-то еще объекту в сети. При
смене физического интерфейса такой запрос может инициировать
смену записи в ARP-таблице.
4.4.5.1. Протокол прокси-ARP
Еще одна разновидность протокола ARP служит для того, что-
бы один и тот же сетевой префикс адреса можно было использовать
для двух сетей. Этот протокол называется смешанным протоколом
ARP (proxy). Предположим, мы имеем сеть из четырех ЭВМ (1-4;
рис. 4.4.5.1.1), которую бы мы хотели соединить с другой сетью из
четырех ЭВМ (5-8), причем так, чтобы машины взаимодействовали
ДРУГ с другом так, будто они принадлежат одной сети. Решить эту
проблему можно, соединив эти сети через маршрутизатор М, работа-
ющий в соответствии со смешанным протоколом ARP (функцио-
нально это IP-мост). Маршрутизатор знает, какая из машин при-
надлежит какой физической сети. Он перехватывает широковеща-
тельные ARP-запросы из сети 1, относящиеся к сети 2, и наоборот.
Во всех случаях в качестве физического адреса маршрутизатор воз-
вращает свой адрес. В дальнейшем, получая дейтограммы, он марш-
рутизирует их на физические адреса по их IP-адресам.
426
Гпава 4
Рис. 4.4.5.1.1. Использование протокола proxy АРР
Не трудно видеть, что в смешанном протоколе ARP нескольким
IP-адресам ставится в соответствие один и тот же физический ад-
рес. Поэтому системы, где предусмотрен контроль за соответствием
физических и IP-адресов, не могут работать со смешанным протоко-
лом ARP. Главным преимуществом этого протокола является то,
что он позволяет путем добавления одного маршрутизатора (Gateway)
подключить к Интернет еще одну сеть, не изменяя таблиц маршру-
тизации в других узлах. Этот протокол удобен для сети, где есть
ЭВМ, не способная работать с субсетями. Протокол используется
при построении сетей Интранет.
4.4.5.2. Определение Internet-адреса при загрузке
системы (протокол RARPJ
Обычно IP-адреса хранятся на диске, откуда они считываются
при загрузке системы. Проблема возникает тогда, когда необходимо
инициализировать рабочую станцию, не имеющую диска. Бездиско-
вые системы часто используют операции типа TFTP для переноса
из сервера в память образа операционной системы, а это нельзя
сделать, не зная IP-адресов сервера и ЭВМ-клиента. Записывать эти
адреса в ПЗУ не представляется целесообразным, так как их значе-
ния зависят от точки подключения ЭВМ и могут меняться. Для
решения данной проблемы был разработан протокол обратной транс-
ляции адресов (RARP - Reverse Address Resolution Protocol, RFC-
0903, смотри также ниже описание протокола ВООТР). Форматы
сообщений RARP сходны с ARP (см. рис. 4.4.5.2.1), хотя сами
протоколы принципиально различны. Протокол RARP предполага-
ет наличие специального сервера, обслуживающего RARP-запросы и
Сети передачи данных. Метод доступа
427
О 8 16 24 31
Тип оборудования Тип протокола
НА-Len PA-Len Код операции
Аппаратный адрес отправителя (п октетов)
Протокольный адрес отправителя (т октетов)
Аппаратный адрес получателя (п октетов)
Протокольный адрес получателя (т октетов)
IP-адрес адресата (октеты 0-3)
Рис. 4.4.5.2.1. Формат RARP-сообщения
хранящего базу данных о соответствии аппаратных адресов прото-
кольным. Этот протокол работает с любой транспортной средой, в
случае же кадра Ethernet в поле шип будет записан код 803516
(смотри таблицу 4.4.5.2).
Здесь обозначения те же, что и в описании ARP-формата. Значе-
ние п определяется числом, записанным в поле НА-Len, a m — чис-
лом из поля РА-Len. Для Internet PA-Len=4 и тип про токола=20 48,
а для Ethernet равно HA-Len=6 и тип оборудования^!. В RARP
используется два кода операции. Код операции^ используется для
RARP-запросов, а код операции^ — для RARP-откликов. В первом
случае поля протокольный адрес отправителя и протокольный ад-
рес адресата не определены. Обычно локальная сеть имеет несколь-
ко RARP-серверов, что позволяет загрузиться бездисковым машинам,
даже если какой-то из серверов выключен или не исправен.
4.4.6. Мультимедиа в Интернет.
Протокол для работы с группами (IGMPJ
Передача мультимедийных данных по сетям Интернет является
°Дним из наиболее важных направлений. Этот вид информации
Предается обычно в режиме без установления соединения (прото-
кол UDP-RTP). Наиболее типичной схемой в этом случае является
наличие одного передатчика и большого числа приемников. Эта
схема реализуется с использованием мультикастинг-адресации.
*Ультикастинг-адресация может осуществляться на IP- и МАС-
Уровнях. В Ethernet для этих целей зарезервирован блок адресов в
Диапазоне от 01:00:5Е:00:00:00 до 01:00:5E:7F:FF:FF. Первый байт
428
Гпава 4
адреса, равный 01, указывает на то, что адрес является мультикаст-
ным. Данная схема резервирования адресного пространства позво-
ляет использовать 23 бита Ethernet-адреса для идентификации груп-
пы рассылки при IP-мультикастинге (см. рис. 4.4.6.1.).
Рис. 4.4.6.1. Соотношение мультикастинговых МАС- и IP-адресов
Область из 5 бит в IP-адресе, отмеченная *****, не используется
при формировании Ethernet-адреса. Так как соотношение IP и МАС-
адресов не является однозначным, драйверы должны обеспечивать
обработку адресов с тем, чтобы интерфейсы получали только те кад-
ры, которые действительно им предназначены. Для того чтобы ин-
формировать маршрутизатор о наличии участников мультикастинг-
обмена в субсети, связанной с тем или иным интерфейсом, исполь-
зуется протокол IGMP.
Протокол IGMP (Internet Group Management Protocol, RFC-1112)
используется для видеоконференций, передачи звуковых сообщений,
а также группового исполнения команд различными ЭВМ. Этот про
токол использует групповую адресацию (мультикастинг).
Групповая форма адресации нужна тогда, когда какое-то сооб-
щение или последовательность сообщений необходимо послать не-
скольким (но не всем) адресатам одновременно. При этой форме
адресации ЭВМ имеет возможность выбрать, хочет ли она участво-
вать в этой процедуре. Когда группа ЭВМ хочет взаимодействовать
друг с другом, используется один групповой (мультикастинг) адрес.
Групповая адресация может рассматриваться как обобщение обыч-'
ной системы адресов, а традиционный IP-адрес — частный случай
группового обращения при числе ЭВМ, равном 1. j
При групповой адресации один и тот же пакет может быть Д<#*
тавлен заданной группе ЭВМ. Членство в этой группе может дин*
мично меняться со временем. Любая ЭВМ может войти в группу
выйти из группы в любое время по своей инициативе. В то же вреМ^^
ЭВМ может быть членом большого числа таких групп. ЭВМ мояФт
Сеги передачи данных. Метод доступа
429
0 12 3 4
31
Идентификатор группы
Рис. 4.4.6.2. Формат группового адреса
посылать пакеты членам группы, не являясь им сама, ведь обмен
происходит без установления соединения. Каждая группа имеет свой
адрес класса D (рис. 4.4.6.2, см. также рис. 4.4.6.1).
Адрес 224.0.0.1 предназначен для обращения ко всем группам
(все узлы и серверы, вовлеченные в данный момент в мультикастинг-
обмен, например, участвующие в видеоконференции). ЭВМ может уча-
ствовать в мультикастинг-процессе на одном из следующих уровней:
Таблица 4.4.6.1. Коды мультикастинг-процессов
Уровень мультикастинг- процесса Описание
0 ЭВМ не может ни посылать, ни принимать данные
1 ЭВМ может только посылать пакеты в процессе 1Р-мултикастинга
2 ЭВМ в режиме мультикастинга может передавать и принимать пакеты
Ряд мультикастинг-адресов зарезервировано строго для опреде-
ленных целей.
Для того чтобы участвовать в коллективных обменах в локаль-
ной сети ЭВМ должна быть снабжена программой, которая поддер-
живает этот режим. При этом сервер локальной сети (gateway)
информируется о намерении использовать мультикастинг. Сервер
передает эту информацию другим внешним серверам IP-сети. Сле-
дует иметь в виду, что мультикастинг также как и широковеща-
тельный режим, заметно загружает сеть. IGMP для передачи своих
сообщений использует 1Р-дейтограммы (IGMP-пакеты инкапсули-
руются в них). Для подключения к группе сначала посылается IGMP-
сообщение «всем ЭВМ» о включении в группу, при этом локальный
мУльтикаст-сервер подготавливает маршрут. Локальный мультикаст-
сеРвер время от времени проверяет ЭВМ и определяет, не покинули
они группу (ЭВМ не подтверждает свое членство в группе). Все
Ip eHbI МежДУ ЭВМ и мультикаст-сервером производятся в режиме
мУльтикастинга, те есть, любое сообщение адресуется всем ЭВМ
пы. ЭВМ, не принадлежащая группе, IGMP-сообщений не полу-
430
Гпава 4
Таблица 4.4.6.2. Зарезервированные мультикастинг-адреса
Мультикастинг адрес Описание
224.0.0.0 Зарезервировано ".
224.0.0.1 Все системы данной субсети
224.0.0.2 Все маршрутизаторы данной субсети '
224.0.0.4 Все DVMRP-маршрутизаторы
224.0.0.5-224.0.0.6 OSPFIGP (MOSPF) ~~
224.0.0.9 Маршрутизаторы RIP2
224.0.0.10 IGRP маршрутизаторы
224.0.1.0 VMTP-группа менеджеров *
224.0.1.1 NTP-Network Time Protocol - сетевая службы времени
224.0.1.6 NSS - сервер имен
224.0.1.7 AUDIONEWS - Audio News Multicast (аудио служба новостей)
224.0.1.9 МТР (Multicast Transport Protocol) - транспортный протокол мультикастинга
224.0.1.10 IETF-1-LOW-AUDIO
224.0.1.11 IETF-1-AUDIO
224.0.1.12 IETF-1-VIDEO
224.1.0.0- 224.1.255.255 ST мультикастинг-группы
224.2.0.0- 224.2.255.255 Вызовы при мультимедиа- конференциях
232.0.0.0- 232.255.255.255 VMTP переходные группы *
чает, что сокращает загрузку сети. Формат сообщений в протоколе
IGMP имеет вид, показанный ниже на рис. 4.4.6.3.
Поле версия определяет используемую версию протокола, поле
тпип=1 говорит о том, что это запрос, отправленный мультикастинг-:
маршрутизатором, тип=2 указывает, что этот отклик послан ЭВМ..
ЭВМ использует групповой адрес, чтобы сообщить о своем подклЮ-
чении к группе. Контрольная сумма вычисляется по тому же алго-
ритму, что и для ICMP. IGMP-сообщения используются мультикам
0 4 8 16 31
Версия Тип 1 Не используется Контрольная сумма
Групповой адрес класса D (нуль при запросе)
Рис. 4.4.6.3. Формат IGMP-сообщений
Сети передачи данных. Метод доступа
437
тинГ'Маршрутизаторамн для того, чтобы отслеживать членство в
группе каждой из сетей, подключенных к нему. В группе может
участвовать несколько активных процессов в одной и той же ЭВМ,
но при этом посылается только один запрос для регистрации. Ког-
да какой-то процесс покидает группу, ЭВМ не шлет сообщения об
этом, даже в случае, когда это последний из процессов- членов груп-
пы на данной ЭВМ. Просто при очередном запросе ЭВМ не подтвер-
дит членство в группе. Мультикастинг-маршрутизатор регулярно
посылает запросы с требованием подтвердить участие в группе. ЭВМ
посылает отклик- подтверждение для каждой из групп, если у нее
есть хотя бы один процесс — член группы. На основе этих запро-
сов-откликов мультикастинг-маршрутизатор составляет и поддер-
живает таблицу интерфейсов, которые имеют одну или более ЭВМ,
входящих в мультикастинг-группы.
Протокол IGMP используется при организации мультикастинг-
туннелей для передачи звуковой и видеоинформации. Для решения
проблем мультимедиа в сетях Интернет используется идея MBONE.
По умолчанию мультикаст-дейтограммы имеют значение поля
TTL=1, что ограничивает их распространение одной субсетью. Прило-
жения могут увеличивать значение TTL. Первая дейтограмма, тем не
менее, всегда имеет TTL=1. Если получение этой дейтограммы не под-
тверждается сервером, посылается вторая — с TTL=2 и т.д. Таким
образом попутно измеряется и число шагов между клиентом и серве-
ром. Для случая, когда число шагов не более 1, зарезервирован блок
адресов 224.0.0.0 — 224.0.0.255. Маршрутизатор не обрабатывает
пакеты с такими адресами вне зависимости от кода поля TTL.
При использовании мультикастинга МАС-переключатели пе-
реадресуют пакеты через все имеющиеся интерфейсы, что заметно
ухудшает эффективность сети. Чтобы решить эту проблему компа-
ния CISCO разработала протокол CGMP (Cisco Group Management
Protocol), который позволяет взаимодействовать маршрутизаторам
и переключателям, что позволяет передавать мультикаст-пакеты
только на те интерфейсы, где имеются активные члены группы.
Л. Б. 1. Мультикастинг и MBONE
MBONE — это виртуальная сеть, базирующаяся на мультикас-
^инг-протоколах, которые были одобрены IETF летом 1992 года. В
Легли РазРа^отки, выполненные в компании Ксерокс. Дан-
Сеть РеЖим Работы поддерживается не всеми маршрутизаторами.
с представляет собой систему Ethernet-сетей, объединенных друг
лями °М соединениями точка-точка, которые называются «тунне-
Конечными точками таких туннелей обычно являются ма-
432
Гпава 4
шины класса рабочих станций, снабженные соответствующим про-
граммным обеспечением. Впервые мультикастинг-туннель был реа-
лизован в Стэндфордском университете в 1988 году.
IP-мультикастинг-пакеты инкапсулируются при передаче через
туннели так, что они выглядят как обычные 1Р-уникаст-пакеты.
Мультикастинг-маршрутизатор при посылке пакета через тун-
нель подготавливает IP-пакет с заголовком, который содержит адрес
маршрутизатора-партнера на другом конце туннеля, при этом поле
IP-протокола содержит код 4 (IP). Маршрутизатор-приемник из-
влекает вложенный мультикастинг-пакет и направляет далее, если
это требуется.
MBONE требует пропускной способности магистральных кана-
лов не ниже 500Кбит/с.
Каждый туннель имеет определенный порог для переменной вре-
мени жизни пакета (time-to-live — TTL). Согласно договоренности
(IETF) широкополосная видеоинформация передается с малыми на-
чальными значениями TTL. Малые значения TTL не позволяет ви-
део-пакетам загружать слишком большие участки сети. Мульти-
кастинг-дейтограмма с TTL=0 может быть доступна только процес-
су, существующему в ЭВМ, породившей эту дейтограмму. По
умолчанию мультикастинг-дейтограммы имеют TTL=1, такая дей-
тограмма не может покинуть пределов субсети, и только дейтограм-
мы с TTL>1 могут переадресовываться маршрутизаторами. Следует
помнить, что маршрутизатор не откликнется ICMP-сообщением «вре-
мя истекло», когда TTL достигнет нуля, так как вообще дейтограм-
мы с мультикастинг-адресами не вызывают ICMP-откликов. Увели-
чивая TTL, прикладной процесс может расширять «зону взаимодей-
ствия». Сначала дейтограмма может посылаться с TTL—1, если
отклика не получено, с TTL=2 и так далее. Эта схема позволяет
найти ближайший сервер (с точки зрения числа шагов до него).
Для приложений, которые ограничивают свою активность в преде-
лах одного шага, предусмотрен специальный интервал адресов
224.0.0.0 — 224.0.0.255. Мультикастинг-маршрутизатор не дол-
жен переадресовывать дейтограммы с такими адресами вне зависи-
мости от значения TTL. Адрес 224.0.0.1 является адресом группы
«все ЭВМ» и относится ко всем ЭВМ и маршрутизаторам, способ-
ным работать в режиме мультикастинга. Каждая ЭВМ автомати-
чески включается в эту группу при инициализации интерфейса. О
членстве в этой группе ЭВМ не сообщает.
Конфигурация системы в режиме мультикастинга производится
автоматически. Для того чтобы изменить конфигурацию системы»
или добавить еще один туннель используются специальные конфи*
Сети передачи данных. Метод доступа
433
гурационные команды, которые записываются в /etc/mrouted.conf.
Существует два типа таких команд:
phyint <local-addr> [disable] [metric <m>] [threshold <t>]
tunnel <local-addr> <remote-addr> [metric <m>] [threshold <t>]
Первая команда может отменить мультикастинг-маршрутиза-
цию для конкретного физического интерфейса, идентифицируемого
по его IP-адресу (<local-addr>), или заменить значение метрики или
порога. Эта команда должна выдаваться до команды tunnel. После-
дняя команда может служить для установления туннеля между
местным IP-адресом (<local-addr>) и удаленным IP-адресом
(<remote-addr>). Значения метрики и порога по умолчанию равны 1.
Специфика мультикастйнг-туннелей требует принципиально но-
вых решений задачи маршрутизации, первой попыткой разрешить
эту проблему был протокол DVMRP. Следует иметь в виду, что
DVMRP может решить лишь часть задачи, хотя бы потому, что это
внутренний протокол. Главной особенностью мультикастинг-марш-
рутизации является то, что нужно проложить маршруты от источ-
ника к совокупности адресатов, от которых пришли запросы учас-
тия в процессе. Режим мультикастинга поддерживается не всеми
маршрутизаторами Интернет. Возможны конфликты при решении
задачи маршрутизации, когда транзитный маршрутизатор не имеет
«своих» участников группы (а должен выделить заметный ресурс
каналов для удовлетворения внешних запросов).
4.4.6.2. Транспортный протокол для использования в
реальном масштабе времени RTP
В Интернет, также как и в некоторых других сетях, возможна
потеря пакетов изменение их порядка в процессе транспортировки,
а также вариация времени доставки в достаточно широких преде-
лах. Мультимедийные приложения накладывают достаточно жест-
кие требования на транспортную среду. Для согласования таких
требований с возможностями Интернет был разработан протокол
RTP. Протокол RTP (См. RFC-2205, -2209, -2210, -1990, -1889;
«RTP: A Transport Protocol for Real-Time Applications» H. Schulzrinne,
S. Casner, R. Frederick, V. Jacobson) базируется на идеях, предло-
женных Кларком и Тенненхаузом [1], и предназначен для доставки
Данных в реальном масштабе времени (например, аудио- или ви-
део). При этом определяется тип поля данных, производится ну-
мерация посылок, присвоение временных меток и мониторирование
434
Гпава 4
доставки. Приложения обычно используют RTP поверх протокола
UDP для того, чтобы использовать его возможности мультиплекси-
рования и контрольного суммирования. Но RTP может использо-
ваться и поверх любой другой сетевой транспортной среды. RTP
поддерживает одновременную доставку по многим адресам, если
мультикастинг поддерживается нижележащим сетевым уровнем.
Следует иметь в виду, что сам по себе RTP не обеспечивает
своевременной доставки и не предоставляет каких-либо гарантий
уровня сервиса (QOS). Этот протокол не может гарантировать так-
же корректного порядка доставки данных. Правильный порядок
выкладки информации может быть обеспечен принимающей сторо-
ной с помощью порядковых номеров пакетов. Такая возможность
крайне важна практически всегда, но особое внимание этому уделя-
ется при восстановлении передаваемого изображения.
На практике протокол RTP не отделим от протокола RTCP
(RTP control protocol). Последний служит для мониторинга QOS и
для передачи информации об участниках обмена в ходе сессии. RTP
гибкий протокол, который может доставить приложению нужную
информацию, его функциональные модули не образуют отдельный
слой, а чаще встраиваются в прикладную программу. Протокол RTP
не является жестко регламентирующим.
При организации аудио-конференции каждый участник дол-
жен иметь адрес и два порта, один для звуковых данных, другой для
управляющих RTCP-пакетов. Эти параметры должны быть извест-
ны всем участникам конференции. При необходимости соблюдения
конфиденциальности информация и пакеты управления могут быть
зашифрованы. При аудио конференциях каждый из участников пе-
ресылает небольшие закодированные звуковые фрагменты длитель-
ностью порядка 20 мсек. Каждый из таких фрагментов помещается
в поле данных RTP-пакета, который в свою очередь вкладывается в
UDP-дейтограмму.
Заголовок пакета RTP определяет, какой вид кодирования зву-
ка применен (PCM, ADPCM или LPC), что позволяет отправителю
при необходимости сменить метод кодирования, если к конферен-
ции подключился новый потребитель с определенными ограничени-
ями или сеть требует снижения скорости передачи.
При передаче звука весьма важным становится взаимное поло-
жение закодированных фрагментов во времени. Для решения зада-
чи корректного воспроизведения заголовки пакетов RTP содержат
временную информацию и порядковые номера. Порядковые номера
позволяют не только восстановить правильный порядок фрагмен-
тов, но и определить число потерянных пакетов-фрагментов.
Сети передачи данных. Метод доступа
435
Так как участники конференции могут появляться и исчезать
по своему усмотрению, полезно знать, кто из них присутствует в
сети в данный момент, и как до них доходят передаваемые данные.
Для этой цели периодически каждый из участников транслирует
через порт RTCP мультикастинг-сообщение, содержащее имя участ-
ника и диагностические данные. Узел-участник конференции шлет
пакет BYE (RTCP), если он покидает сессию.
Если в ходе конференции передается не только звук но и
изображение, они передаются как два независимых потока с исполь-
зованием двух пар UDP-портов. RTCP-пакеты посылаются незави-
симо для каждой из этих двух сессий.
На уровне RTP не существует какой-либо взаимосвязи между
аудио- и видео сессиями. Только RTCP-пакеты несут в себе одни и
те же канонические имена участников.
В некоторых случаях можно столкнуться с ситуацией, когда
один из участников конференции подключен к сети через узкопо-
лосный канал. Было бы не слишком хорошо требовать от всех
участников перехода на кодировку, соответствующую этой малой
полосе. Для того чтобы этого избежать, можно установить преобра-
зователь, называемый смесителем, в непосредственной близости от
узкополосной области.
Смеситель преобразует поток аудио-пакетов в последователь-
ность пакетов, которая соответствует возможностям узкополосного
канала. Эти пакеты могут быть уникастными (адресованными од-
ному получателю) или мультикастными. Заголовок RTP включает
в себя средства, которые позволяют мультиплексорам идентифици-
ровать источники, внесшие вклад. Так что получатель может пра-
вильно идентифицировать источник звукового сигнала.
Некоторые участники конференции, использующие широкопо-
лосные каналы, не доступны для IP-мультикастинга (например, на-
ходятся за Firewall). Для таких узлов смесители не нужны, здесь
используется другой RTP-уровень передачи, называемый трансля-
цией. Устанавливается два транслятора по одному с каждой из
сторон Firewall. Внешний транслятор передает мультикастинг-па-
кеты по безопасному каналу внутреннему транслятору. Внутренний
же транслятор рассылает их подписчикам локальной сети обыч-
ным образом.
Смесители и трансляторы могут выполнять и другие функции,
например, преобразование IP/UDP пакетов в ST-П при видео конфе-
ренциях.
436
Гпава 4
Определения
Поле данных RTP: Информация, пересылаемая в пакете RTP,
например фрагменты звука или сжатые видео данные.
Пакет RTP: Информационный пакет, содержащий фиксирован-
ный заголовок. Один пакет транспортного нижнего уровня, напри-
мер UDP, обычно содержит один RTP-пакет, но это требование не
является обязательным. Поле источников информации может быть
пустым.
Пакет RTCP: Управляющий пакет, содержащий фиксирован-
ный заголовок сходный с RTP, за которым следуют структурные
элементы, зависящие от типа RTCP-пакета. Обычно несколько RTCP-
пакетов посылаются как составной RTCP-пакет, вложенный в дей-
тограмму нижележащего уровня.
Транспортный адрес: Комбинация сетевого адреса и порта, ко-
торая идентифицирует конечную точку канала (например, IP-адрес
и UDP-порт). Пакеты следуют от транспортного адреса отправите-
ля к транспортному адресу получателя.
Сессия RTP: Период с момента установления группы участни-
ков RTP-обмена до ее исчезновения. Для каждого из участников
сессия определяется конкретной парой транспортных адресов (сете-
вой адрес и номера портов для RTP и RTCP). Транспортный адрес
места назначения может быть общим для всех участников сессии.
Допускается реализация нескольких сессий для каждого из участ-
ников одновременно.
Источник синхронизации (SSRC): Источник потока RTP-паке-
тов, определяется 32-битным числовым SSRC-идентификатором,
который записывается в заголовок RTP-пакета и не зависит от
сетевого адреса. Все пакеты от источника синхронизации образуют
часть с идентичной временной привязкой и нумерацией. Эти данные
используются принимающей стороной при воспроизведении. Источ-
никами синхронизации могут служить источники первичного сиг-
нала (микрофоны или видеокамеры), а также RTP-смесители. SSRC-
идентификатор представляет собой случайное число, которое явля-
ется уникальным для данной RTP-сессии. Участник сессии не должен
использовать один и тот же SSRC-идентификатор для всех RTP-
сессий мультимедийного набора. Если участник формирует несколько
потоков в рамках одной RTP-сессии (например, от нескольких ви-
деокамер), каждый из них должен быть снабжен уникальным SSRC-
идентификатором.
< Информационный источник CSRC (Contributing source): Ис-
точник потока RTP-пакетов, который вносит вклад в общий поток,
формируемый RTP-смесителем. Смеситель вставляет список SSRC-
Сети передачи данных. Метод доступа
437
идентификаторов, которые идентифицируют парциальные источни-
ки, в заголовок RTP-пакетов. Этот список называется CSRC-спис-
ком. Примером приложения может быть аудио-конференция, где
смеситель отмечает всех говорящих, чей голос порождает исходя-
щие пакеты. Это позволяет принимающей стороне идентифициро-
вать говорящего, хотя все пакеты имеют один и тот же SSRC-иден-
тификатор.
Оконечная система: Приложение, которое генерирует или вос-
принимает данные, посылаемые в виде RTP-пакетов. Оконечная си-
стема может выступать в качестве одного или нескольких источни-
ков синхронизации для конкретной сессии.
Смеситель: Промежуточная система, которая получает RTP-na-
кеты от одного или нескольких источников, при необходимости ме-
няет их формат, объединяет и пересылает их адресатам. Так как
временная привязка входных пакетов может отличаться, смеситель
осуществляет их синхронизацию и генерирует свой собственный
поток RTP-пакетов. Таким образом все посылаемые пакеты имеют
в качестве источника синхронизации смеситель.
Транслятор: Промежуточная система, которая переадресует RTP-
пакеты, не изменяя их идентификаторы источника синхронизации.
Такие устройства используются для преобразования системы коди-
рования, перехода от мультикастинг- к традиционной уникаст-ад-
ресации или при работе с Firewall.
Монитор: Приложение, которое получает RTCP-пакеты, послан-
ные участниками RTP-сессии, в частности диагностические сообще-
ния, производит оценку состояния связи, копит долгосрочную ста-
тистику обмена.
Все целочисленные поля передаются в соответствии с сетевым
порядком, т.е. старший байт следует первым (big-endian). Порядок
передачи описан подробно в работе [3]. Если не оговорено обратно-
го все цифровые константы являются десятичными. Все поля заго-
ловка выравниваются по их естественным границам, т.е. 16-бито-
вые поля имеют четное смещение, а 32-битные имеют адрес, крат-
ный 4. Октеты-заполнители содержат нули.
Абсолютное время представляется с помощью временных меток
в соответствии с форматом NTP (Network Time Protocol), который
характеризует время в секундах от начала суток (UTC) 1 января
1900 [4]. Полное разрешение временной метки NTP определяется
^-битовым числом с фиксированной запятой без знака. Целочис-
ленная часть задается первыми 32 битами, а дробная часть после-
дними. В некоторых полях, где допустимо более компактное пред-
ставление, используются только средние 32 бита (16 бит целочис-
438
Гпава 4
0 2 3 4 7 8 16 31
V=2 Р X СС М РТ Номер по порядку
Временная метка
Идентификатор источника синхронизации (SSRC)
Идентификаторы участников (CSRC от 1 до 15)
Рис. 4.4.6.2.1. Заголовок пакета РТР
ленная часть и 16 бит дробная). Заголовок RTP-пакета имеет сле-
дующий формат (см. рис. 4.4.6.2.1).
Первые 12 октетов присутствуют во всех RTP-пакетах, в то время
как список CSRC-идентификаторов присутствует только, когда пакет
формируется смесителем. Поля имеют следующие назначения:
V (Версия): 2 бита
Это поле идентифицирует версию протокола RTP. В настоящее
время в это поле записывается код 2. Значение 1 использовалось в
опытной версии RTP, а код О-в аудио приложении «vat».
Р (Заполнитель): 1 бит >
Если Р=1, пакет содержит один или более дополнительных ок-
тетов-заполнителей в конце поля данных (заполнители не являют-
ся частью поля данных). Последний октет заполнителя содержит
число октетов, которые должны игнорироваться. Заполнитель ну-
я<ен при использовании некоторых алгоритмов шифрования при
фиксированном размере блоков или при укладке нескольких RTP-
пакетов в один UDP.
X (Расширение): 1 бит
Если бит Х=1, далее следует фиксированный заголовок, за кото-
рым размещается одно расширение заголовка.
СС (CSRC Count - число CSRC): 4 бита
Число CSRC содержит код количества CSRC-идентификаторов,
которые записаны в пакете.
М (маркер): 1 бит
Интерпретация маркера определяется профайлом. Предполага-
ется разрешить выделять в потоке пакетов существенные события,
такие как границы кадра. Профайл может определить дополни-
тельные маркерные биты или специфицировать отсутствие маркер-
ных битов путем изменения числа битов в поле РТ.
РТ (Тип данных): 7 бит
Это поле идентифицирует формат поля данных RTP-пакета и
определяет интерпретацию его приложением. Могут быть определе-
Сети передачи данных. Метод доступа
439
ны дополнительные коды типа данных. Исходный набор кодов по
умолчанию для аудио и видео задан в профайле Internet-Draft draft-
ietf-avt-profile, и может быть расширен в следующих редакциях стан-
дарта Assigned Numbers (RFC-1700) [5].
Номер по порядку: 16 бит
Номер по порядку инкрементируется на 1 при посылке очередно-
го RTP-пакета данных, этот код может использоваться получателем
для регистрации потерь пакетов и для восстановления истинного
порядка присланных фрагментов. Начальное значение кода являет-
ся случайным. Алгоритм генерации таких кодов рассмотрен в [6].
Временная метка: 32 бита
Временная метка соответствует времени стробирования для пер-
вого октета в информационном RTP-пакете. Время стробирования
должно быть получено от часов, показания которых увеличиваются
монотонно и линейно, чтобы обеспечить синхронизацию и вычисле-
ние временного разброса. Разрешающая способность часов должна
быть достаточной для обеспечения приемлемой точности синхрони-
зации (одного тика на видео кадр обычно не достаточно). Частота
часов зависит от формата данных и задается статически в профайле,
в спецификации поля данных, или динамически средствами, выхо-
дящими за пределы спецификации протокола RTP. Если RTP-паке-
ты генерируются периодически, используется временная привязка,
определенная задающим генератором стробирования, а не показа-
ниями системных часов.
Начальное значение временной метки является случайным. Не-
сколько последовательных RTP-пакетов могут иметь идентичные
временные метки, если логически они генерируются одновременно
(например, относятся к и тому же видео кадру).
SSRC: 32 бита
Поле SSRC идентифицирует источник синхронизации. Этот иден-
тификатор выбирается случайным образом, так чтобы в пределах
одной RTP-сессии не было двух идентичных SSRC-кодов. Все при-
ложения должны быть способны выявлять случаи равенства SSRC-
кодов. Если отправитель изменяет свой транспортный адрес, он дол-
жен также сменить и SSRC-идентификатор.
CSRC-список: от 0 до 15 элементов, по 32 бита каждый
CSRC-список идентифицирует источники информации, которые
внесли свой вклад в поле данных пакета. Число идентификаторов
задается полем СС. Если число источников больше 15, только 15
из них могут быть идентифицированы.
Для эффективной реализации протокола число точек мульти-
плексирования должно быть минимизировано. В RTP, мультиплек-
440
Гпава 4
сирование осуществляется по транспортным адресам мест назначе-
ния, которые определены RTP-сессией. Использование пакетов с раз-
личным типом поля данных но с идентичным SSRC создает опре-
деленные проблемы:
1. Если один из типов данных будет изменен в ходе сессии, нет
универсальных средств для определения, какое из старых значений
следует заменить на новое.
2. SSRC определено для идентификации одного пространства
номеров и временных меток. Совместное использование нескольких
типов данных в общем потоке может потребовать разных средств
синхронизации и разной нумерации, чтобы определять, какой из
типов пакетов потерян.
3. RTCP-сообщения отправителя и получателя могут описать
только одно пространство номеров и временных меток для каждого
SSRC и не имеют поля типа данных.
4. RTP-смеситель не сможет объединять перекрывающиеся по-
токи при условии их несовместимости.
5. Работа со многими средами в пределах одной RTP-сессии
предполагает: использование различных сетевых путей или разного
размещения сетевых ресурсов; прием только одного субнабора, на-
пример аудио, когда видео недоступно из-за недостатка широкопо-
лосности.
Использование различных SSRC для каждого вида среды, при
посылке их в пределах одной RTP-сессии позволяет преодолеть пер-
вые три проблемы.
Хотя существующие RTP-заголовки позволяют решать широ-
кий круг проблем, предусмотрена возможность их модификации с
помощью профайлов. При этом сохраняется возможность контро-
ля и мониторирования с использованием стандартных средств.
• Бит маркера и поле типа данных содержат информацию, зада-
ваемую профайлом, но они размещаются в стандартном заголовке,
так как нужны многим приложениям. Октет, где размещаются эти
поля, может быть переопределен профайлом.
* Дополнительная информация, которая необходима для конк-
ретного формата поля данных, такая как тип видео-кодирования,
должна транспортироваться в поле данных пакета. Это может быть
заголовок, присутствующий в начале поля данных.
• Если конкретное приложение нуждается в дополнительных
возможностях, которые не зависят от содержимого поля данных,
профайл данного приложения должен определить дополнительные
фиксированные поля, следующие непосредственно после поля SSRC
Сети передачи данных. Метод доступа
441
существующего заголовка пакета. Эти приложения смогут полу-
чить доступ к этим дополнительным полям, при этом сохраняются
все стандартные средства контроля и мониторинга, так как они
базируются на первых 12 октетах заголовка.
В протоколе RTP предусмотрен механизм расширений заголов-
ка, который позволяет модифицировать заголовок и эксперименти-
ровать с новыми форматами поля данных. Этот механизм устроен
так, что расширения заголовка могут игнорироваться приложения-
ми, которые не нуждаются в расширениях.
Расширения заголовка предназначены для ограниченного исполь-
зования. И многие приложения лучше реализовать, используя про-
файл. Формат реализации расширений показан на рис. 4.4.6.2.2.
0 16 31
Определено по профайлу Длина
Расширение заголовка .........
Рис. 4.4.6.2.2. Формат расширения заголовка
Если бит X в RTP-заголовке равен 1, то к заголовку добавлено
расширение переменной длины, за которым может следовать список
CSRC. Расширение заголовка содержит 16-битовое поле длины, опреде-
ляющее число 32-битных слов в расширении, исключая 4-октета за-
головка расширения (т.о. значения поля длина, равное нулю вполне
допустимо). Информационный заголовок RTP может иметь только
одно расширение. Для того чтобы обеспечить работу различных при-
ложений с различными расширениями заголовка или чтобы обеспе-
чить работу с более чем одним типом расширений, первые 16 бит
расширения заголовка остаются свободными для выбора идентифи-
каторов или параметров. Формат этих 16 бит определяется специфи-
кацией профайла, с которым работает приложение.
Кроме оконечных систем RTP поддерживает трансляторы и сме-
сители, которые рассматриваются как промежуточные системы на
Уровне RTP.
RTP транслятор/смеситель соединяет две или более области на
транспортном уровне. Обычно каждая область определяется сетью
11 транспортным протоколом (например, IP/UDP), мультикаст-адре-
с°м или парой уникаст-адресов, а также портом назначения транс-
п°Ртного уровня. Одна система может служить транслятором или
смесителем для нескольких RTP сессий.
442
Гпава 4
Для того чтобы исключить зацикливание при использовании
транслятора или смесителя следует придерживаться следующих
правил:
• Каждая из областей, соединенных транслятором или смесите-
лем, участвующих в одной RTP-сессии должна отличаться от всех
других, по крайней мере, одним параметром (протоколом, адресом,
портом) или должна быть изолирована от других на сетевом уровне;
• Следствием первого правила является то, что области не долж-
ны быть соединены более чем одним смесителем или транслятором.
Аналогично все оконечные системы RTP, которые взаимодей-
ствуют через один или более трансляторов или смесителей, принад-
лежат одной и той же SSRC-области, т.е., SSRC-идентификаторы
должны быть уникальными для задействованных оконечных сис-
тем. Существует большое разнообразие трансляторов и смесителей,
спроектированных для решения различных задач и приложений.
Некоторые служат для шифрования/дешифрования несущих дей-
тограмм. Различие между смесителями и трансляторами заключа-
ется в том, что последние пропускают через себя потоки данных, при
необходимости их преобразуя, а смесители объединяют несколько
потоков в один.
Транслятор. Переадресует RTP-пакеты, не изменяя их SSRC-
идентификаторы. Это позволяет получателям идентифицировать
отдельные источники, даже если пакеты от всех источников прохо-
дят через один общий транслятор и имеют сетевой адрес транслято-
ра. Некоторые типы трансляторов передают данные без изменений,
другие кодируют данные и соответственно изменяют коды типа дан-
ных и временные метки. Приемник не может заметить присутствия
транслятора.
Смеситель. Принимает потоки RTP-данных от одного или не-
скольких источников, может изменять формат данных, определен-
ным образом объединяет потоки и затем формирует из них один
общий поток. Так как объединяемые потоки не синхронизованы,
смеситель производит синхронизацию потоков и формирует свою
собственную временную шкалу для исходящего потока. Смеситель
является источником синхронизации. Таким образом, все пакеты
данных, переадресованные смесителем, будут помечены SSRC-идей*
тификатором смесителя. Для того чтобы сохранить информацию
об источниках исходных данных, смеситель должен внести свой
SSRC-идентификаторы в список CSRC-идентификаторов, который
следует за фиксированным RTP-заголовком пакета. Смеситель, ко* .
торый вносит в общий поток свою составляющую, должен вклЮ*
Сети передачи данных. Метод доступа 443
чить свой собственный SSRC-идентификатор в CSRC-список для
данного пакета.
Для некоторых приложений смеситель может не идентифициро-
вать источники в CSRC-списке. Однако это создает опасность того,
что петли, включающие эти источники, не смогут быть выявлены.
Преимуществом смесителя перед транслятором для аудио- при-
ложений является то, что выходная полоса не превосходит полосы
одного источника, даже когда в сессии на входе смесителя присут-
ствуют несколько участников. Недостатком является то, что полу-
чатели с выходной стороны не имеют никаких средств контроля
того, какой из источников передает данные даже в случае наличия
дистанционного управления смесителем.
Рис. 4.4.6.2.3 Пример РТР сети с оконечными системами,
смесителями и трансляторами
Некоторый набор смесителей и трансляторов представлен на рис.
4.4.6.2.3. Здесь показано их влияние на SSRC и CSRC-идентифи-
каторы. Оконечные системы обозначены символами ES. Транслято-
ры обозначены буквами TRS и смесители обозначены как MUX.
Запись «Ml: 13(1,17)» обозначает пакет отправленный смесителем
MUX1, который идентифицируется случайным значением SSRC 13
и Двумя CSRC-идентификаторами 1 и 17, скопированными с SSRC-
иДентификаторов пакетов оконечных систем ESI и ES2.
Последовательное включение смесителей
В RTP-сессии могут быть задействованы несколько смесителей
И трансляторов, как это показано на рис. 4.4.6.2.3. Если два смеси-
Теля включены последовательно, так как MUX2 и MUX3, пакеты
п°лученные смесителем могут быть уже объединены и включать
444
Гпава 4
CSRC-список со многими идентификаторами. Смеситель (MUX3)
должен формировать CSRC-список для исходящих пакетов, исполь-
зуя CSRC-идентификаторы уже смешанных входных пакетов (вы-
ход MUX2) и SSRC-идентификаторы несмешанных входных паке-
тов, поступивших от ES9 (Е:36). Это отмечено на рисунке для вы-
ходных пакетов смесителя MUX3 как М3:99(9,11,36). Если число
идентификаторов в списке CSRC превышает 15, остальные не могут
быть туда включены.
SSRC-идентификаторы в RTP-заголовках и в различных полях
RTCP-пакетов являются случайными 32-битовыми числами, кото-
рые должны быть уникальными в рамках RTP-сессии. Очень важно,
чтобы одни и те же числа не были использованы несколькими уча-
стниками сессии.
Недостаточно использовать в качестве идентификатора локаль-
ный сетевой адрес (такой как IPv4), так как может быть не уни-
кальным. Так как RTP трансляторы и смесители допускают работу
с сетями, использующими различные адресные пространства, это до-
пускает их случайное совпадение с большей вероятностью, чем в
случае использования случайных чисел. Не приемлемо также полу-
чать идентификаторы SSRC путем простого обращения к функции
random() без тщательной инициализации.
Так как идентификаторы выбраны случайным образом, суще-
ствует малая, но конечная вероятность того, что два или более ис-
точников выберут одно и то же число. Столкновение более вероят-
но, если все источники стартуют одновременно. Если N число источ-
ников, a L длина идентификатора (в нашем случае, 32 бита),
вероятность того, что два источника независимо выберут одно и то
же значение (для больших N [8]) составляет 1 — ехр(—N2/2(L+U)*
Для N=1000, вероятность примерно равна 104.
Типовое значение вероятности столкновения много меньше худ-
шего случая, рассмотренного выше. Рассмотрим случай, когда новый
источник подключается к RTP-сессии, в которой все остальные ис-
точники уже имеют уникальные идентификаторы. Если N равно чис-
лу источников, a L длина идентификатора, вероятность столкновения
равна N/2L. Для N=1000, вероятность составит около 2*10 7.
Вероятность столкновения уменьшается еще больше в случае,
когда новый источник получает пакеты других участников до того,
как передаст свой первый пакет. Если новый источник отслеживает
идентификаторы других участников, он легко может устранить ве-
роятность конфликта.
Сети передачи данных. Метод доступа
445
Преодоление столкновений и детектирование петель
Хотя вероятность столкновения идентификаторов SSRC доволь-
но мала, все RTP реализации должны быть готовы обнаруживать
столкновения и предпринимать адекватные меры для их преодоле-
ния. Если источник обнаруживает в какой-либо момент, что другой
источник использует тот же идентификатор SSRC, он посылает па-
кет RTCP BYE для старого идентификатора и выбирает новый.
Если получатель обнаруживает, что два других источника имеют
равные идентификаторы (столкновение), он может воспринимать
пакеты от одного и игнорировать от другого до тех пор, пока это не
будет зарегистрировано отправителями или CNAME.
Так как идентификаторы уникальны, они могут использоваться
для детектирования петель, которые могут создаваться смесителем
или транслятором. Петля приводит к дублированию данных и уп-
равляющей информации:
• Транслятор может некорректно переадресовать пакет некото-
рой мультикастинг-группе, откуда этот пакет получен. Это может
быть сделано непосредственно или через цепочку трансляторов. В
этом случае один и тот же пакет появится несколько раз, приходя
от разных сетевых источников.
• Два транслятора некорректно поставленные в параллель, т.е.,
с одними и теми же мультикастными группами на обеих сторонах
будут направлять пакеты от одной мультикастной группы к дру-
гой. Однонаправленные трансляторы могут создать две копии; дву-
направленные трансляторы могут образовать петлю.
• Смеситель может замкнуть петлю путем посылки пакета по
адресу, откуда он был получен. Это может быть выполнено непос-
редственно, через смеситель или через транслятор.
Источник может обнаружить, что его собственный пакет дви-
жется по кругу, или что пакеты других источников осуществляют
циклическое движение.
Оба вида петель и столкновения приводят к тому, что пакеты
приходят с тем же самым SSRC-идентификатором, но с разными
транспортными адресами, которые могут принадлежать оконечной
или какой-то промежуточной системе. Следовательно, если источ-
ник меняет свой транспортный адрес, он должен также выбрать
новый SSRC-идентификатор с тем, чтобы ситуация не была интер-
претирована, как зацикливание. Петли или столкновения, происхо-
дящие на дальней стороне транслятора или смесителя, не могут
Ыть детектированы с использованием транспортного адреса источ-
ника, если все копии пакетов идут через транслятор или смеситель.
Днако столкновения могут быть детектированы, когда фрагменты
44В ‘ Гпава 4 I
двух RTCP SDES пакетов содержат равные SSRC-идентификаторы,
но разные коды CNAME (см. описание протокола RTCP).
Для того чтобы детектировать и устранять конфликты, реализа-
ции RTP должны содержать алгоритм, аналогичный описанному
ниже. Он игнорирует пакеты от нового источника, которые входят в
противоречие с работающим источником. Алгоритм разрешает кон-
фликты с SSRC-идентификаторами участников путем выбора ново-
го идентификатора и посылки RTCP BYE для старого. Однако ког-
да столкновение вызвано зацикливанием собственных пакетов уча-
стников сессии, алгоритм выбирает новый идентификатор только
раз и после этого игнорирует пакеты от транспортного адреса, выз-*
вавшего зацикливание. Это требуется для того, чтобы избежать по-
тока пакетов BYE.
Этот алгоритм зависит от равенства транспортных адресов для
RTP и RTCP пакетов источника. Алгоритм требует модификации
приложений, которые не отвечают этому ограничению.
Этот алгоритм требует наличия таблицы транспортных адресов
источников, упорядоченных по их идентификаторам. В таблицу за-
носятся адреса, откуда данный идентификатор был впервые полу-
чен. Каждый SSRC или CSRC идентификатор, полученный с инфор-
мационным или управляющим пакетом ищется в этой таблице,
для того чтобы корректно обработать полученные данные. Для уп-
равляющих пакетов каждый элемент с его собственным SSRC, на-
пример, фрагмент SDES, требует отдельного просмотра. SSRC в сооб-
щениях-отчетах составляют исключение. Если SSRC или CSRC не
найдены, создается новая запись в таблице. Эти записи в таблице
удаляются, когда приходит пакет RTCP BYE с соответствующим
кодом SSRC, или когда достаточно долго не приходит вообще ника-
ких пакетов.
Для того чтобы отслеживать зацикливание собственных паке- ,
тов участников, необходимо также завести отдельный список транс-
портных адресов источников, которые считаются конфликтными.
Заметим, что это должен быть короткий список, обычно пустой.
Каждый элемент этого списка хранит адрес источника и время, ког-
да был получен последний конфликтный пакет. Элемент может быть
удален из списка, когда за время 10 периодов посылки RTCP сооб-
щений-отчетов не прибыло ни одного конфликтного пакета.
Когда из-за столкновения выбран новый SSRC-идентификатор,
кандидат-идентификатор должен быть сверен с содержимым табли-
цы идентификаторов. Если такой код там уже имеется, должен
быть выбран другой кандидат и процедура сверки повторена. д
Сети передачи данных. Метод доступа
447
Зацикливание информационных мультикастинг-пакетов может
вызвать сильную перегрузку сети. Все смесители и трансляторы
должны реализовывать алгоритм детектирования зацикливания с
тем, чтобы немедленно прервать этот опасный процесс. Это должно
уменьшить лишний трафик. Однако, в крайних случаях, где смеси-
тель или транслятор не прерывают зацикливание, может быть необ-
ходимо для оконечных систем прервать передачу.
Когда необходимо шифрование RTP или RTCP, все октеты бу-
дут инкапсулированы в одну дейтограмму нижележащего уровня и
зашифрованы как единое целое. Для RTCP в начало последова-
тельности перед шифрованием добавляется 32-битное случайное
число, чтобы предотвратить возможные атаки. В случае RTP ника-
ких префиксов не требуется, так как порядковый номер и времен-
ная метка и без того являются случайными числами.
Алгоритмом шифрования по умолчанию является DES (Data
Encryption Standard), работающий в режиме СВС (Cipher Block
Chaining), как это описано в RFC 1423 [9], за исключением того, что
используется заполнение кратное 8 октетам. Инициализационный
вектор равен нулю, так как для RTP-заголовка используются слу-
чайные числа. Более подробно о векторах инициализации можно
прочесть в [10]. Приложения, которые используют шифрование дол-
жны поддерживать алгоритм DES в режиме СВС. Этот метод выб-
ран потому, что он показал на практике свою эффективность при
работе с аудио и видео приложениями в Интернет. Возможно при-
менение и других криптографических средств.
В качестве альтернативы шифрованию на уровне RTP, можно
определить для шифрованных полей в профайлах дополнительные
типы поля данных. Этот метод позволяет шифровать только дан-
ные, в то время как заголовки остаются незашифрованными.
Демультиплексирование RTP-данных осуществляется на ниже-
лежащий протокольный уровень. Для UDP и сходных с ним прото-
колов, RTP использует четные номера портов, а соответствующие
RTCP-потоки используют нечетные номера портов. Если приложе-
нию предлагается нечетный номер RTP-порта, этот номер должен
быть заменен на ближайший четный меньше исходного.
Информационные RTP-пакеты не имеют поля длины или ка-
ких-либо других средств ограничения размеров пакета, по этой при-
Чине RTP полагается на нижележащий протокол при задании раз-
МеР& поля данных. Максимальная длина RTP-пакетов ограничена
Размером используемых транспортных пакетов (например, UDP).
448 Глава 4 f
Если RTP-пакеты переносятся посредством протокола, кото-
рый поддерживает поточный метод передачи, должен быть опреде-
лен механизм вложения. Механизм вложения должен быть дета-
лизован и в случае, когда транспортный протокол использует в поле
данных заполнители.
Механизм вложения может быть определен в профайле даже в
случае, когда для транспортировки RTP используется не поточный
протокол, это позволяет укладывать несколько RTP-пакетов в одну
дейтограмму транспортного протокола (например, UDP). Передача
нескольких RTP-пакетов в одном транспортном уменьшает издер-
жки, связанные с заголовком и может упростить синхронизацию
различных потоков.
Константы, определяющие тип данных (РТ) RTP-пакета, зада-
ются профайлом а не самим протоколом. Однако, значение октета
RTP-заголовка, который содержит бит(ы) маркера не должно ни
при каких обстоятельствах равняться 200 и 201 (десятичные), для
того чтобы отличить RTP-пакеты от RTCP-пакетов типа SR и RR.
Использование протокола RTP в различных приложениях мо-
жет предъявлять различные требования. Адаптация протокола к
этим требованиям осуществляется путем выбора определенных
параметров, использования различных расширений (см. рис.
4.4.6.2.2) или путем вариации формата на основе профайлов. Ти-
повое приложение использует только один профайл. Спецификация
формата поля данных определяет то, например, как, закодирован-
ный видеосигнал (Н.261) должен переноситься RTP-пакетами.
В рамках RTP-стандарта определены следующие элементы поля ,
данных (этот список не следует рассматривать, как окончательный):
Заголовок поля данных RTP. Октет RTP заголовка, содержащий
маркер тип поля данных, может быть переопределен с помощью про-
файла (например, можно изменить число маркерных битов).
Типы поля данных. Профайл обычно определяет набор форма-
тов поля данных (напр., типов кодирования исходных данных) и
соответствие между этими форматами и кодами типа поля данных.
Для каждого описанного типа поля данных должна быть определе-
на частота временных меток. ?
Не предполагается, что для каждого приложения требуется свой *
профайл. В пределах одного класса приложений целесообразно ис-
пользовать расширения одного и того же профайла. Простое рас-
ширение, такое как введение дополнительного типа поля данных
или нового типа RTCP-пакета, может быть выполнено путем регис-
трации их через комитет по стандартным числам Интернет и пуб-
ликации их описаний в приложении к профайлу. ;
Сети передачи данных. Метод доступа
449
Алгоритмы работы отправителя и получателя RTP-пакетов опи-
саны в RFC-1889 на примере кодов, написанных на языке СИ. Пред-
ставлена там и протокольная структура данных.
Получатель RTP-пакета должен проверить корректность заго-
ловка. Здесь следует учитывать, что пакет может быть зашифрован.
Если пакет не пройдет данную проверку (например, неверно дешиф-
рован, ошибка в адресе или обнаружен неизвестный тип поля дан-
ных), должно быть выработано соответствующее сообщение. Огра-
ниченная проверка допустима только для нового источника:
• В поле версии RTP должен быть записан код 2.
• Тип поля данных должен быть из числа известных, в частно-
сти он не должен быть равным SR или RR.
• Если бит Р=1, тогда последний октет пакета должен содер-
жать правильное число октетов, в частности оно должно быть мень-
ше полной длины пакета минус размер заголовка.
• Бит X должен быть равен нулю, если профайл не указывает
на использование механизма расширения. В противном случае длина
поля расширения должна быть меньше полной длины пакета минус
длина стандартного заголовка вместе с заполнителем.
• Длина пакета должна согласовываться с СС и типом поля
данных (если длина поля данных известна).
Последние три проверки достаточно сложны и не всегда воз-
можны. Если SSRC-идентификатор в пакете соответствует одному
из полученных ранее, тогда пакет вероятно корректен и следует
проверить то, что его порядковый номер лежит в нужном диапазо-
не. Если SSRC-идентификатор ранее не встречался, тогда данный
пакет может рассматриваться некорректным до тех пор, пока не
будет получено несколько таких последовательно пронумерованных
пакетов.
Когда новый источник дает о себе знать впервые (т.е. его
SSRC-идентификатор отсутствует в таблице), ^и для описания его
состояния выделено место в памяти, s->probation должно быть сде-
лано равным числу последовательных пакетов, которые должны
быть зарегистрированы до того, как источник будет объявлен ле-
гальным (параметр MINSEQUENTIAL ), а переменной s->max_seq
присваивается значение seq-1. s->probation помечает источник как
еЩе нелегальный, так что описание его состояния может быть выб-
рошено после короткой выдержки.
После того как источник признан легальным, номер по порядку
Читается корректным, если он не больше чем на MAX DROPOUT
До s->max seq и не больше чем на MAX MISORDER после.
*^QK’ 3430 Семенов
450 Гпава 4
В противном случае возвращается нуль, что означает неудачу
проверки, а плохой последовательный номер запоминается. Если
номер очередного полученного пакета имеет следующий номер ц0
порядку, то он рассматривается как начало новой последовательно-
сти (возможно источник рестартовал). Так как при этом теряется
много циклов, статистика потерь пакетов сбрасывается.
В зависимости от приложения и используемого кодирования для :
проверки можно использовать дополнительную информацию о струк-
туре поля данных. Например, для типов данных, где используются
временные метки, можно с некоторой точностью предсказывать оче-'
редное значение метки на основании знания предыдущей и разно- Т
сти номеров пакетов.
Для того чтобы посчитать частоту потерь пакетов, нужно знать,
ожидаемое и реально полученное число пакетов для каждого из
источников. Число полученных пакетов получается простым их-
подсчетом с учетом возможного дублирования и запаздывания. ?
Ожидаемое число пакетов может быть подсчитано получателем как л
разность между наибольшим порядковым номером пакета ( s-
>max__seq ) и номером первого пакета в последовательности ( s-
>base_seq ). При этом нужно учитывать то, что номера имеют 16 '
бит, и по этой причине могут переполниться (число переполнений
хранится в переменной s->cycles).
extendedjmax = s->cycles 4- s->max_seq;
expected == extended_max — s->base_seq +1;
Число потерянных пакетов определяется как разность между
ожидаемым и реально полученным числом пакетов:
lost = expected — s->received;
Доля потерянных пакетов за отчетный период (с момента по*
сылки предыдущего SR или RR пакета) вычисляется из разности
ожидаемого и реально полученного числа пакетов за отчетный пе-
риод, где expected_prior и received—prior представляют собой значе-
ния, записанные в момент подготовки предыдущего отчета:
expected_interval = expected — s->expected_prior;
s->expected_prior = expected;
received_interval = s->received — s->received_prior;
s->received_prior = s->received;
lost-interval = expec ted__interval — received-interval;
if (expected—interval == 0 || lost_interval <== 0) fraction = 0;
else fraction = (lost_interval « 8) / expected_interval;
Сети передачи данных. Метод доступа 451
результирующее значение доли равно 8-битовому числу с фик-
сированной запятой, расположенной слева.
Библиография
D. D. Clark и D. L. Tennenhouse, «Architectural considerations for a
new generation of protocols,» in SIGCOMM Symposium on Commu-
nications Architectures и Protocols , (Philadelphia, Pennsylvania), pp.
200—208, IEEE, Sept. 1990. Computer Communications Review, Vol.
20(4), Sept. 1990,.
j2] D. E. Comer, Internetworking with TCP/IP , vol. 1. Englewood Cliffs,
New Jersey: Prentice Hall, 1991.
[3] Postel, J., «Internet Protocol», STD 5, RFC 791, USC/Information
Sciences Institute, September 1981.
[4] Mills, D., «Network Time Protocol Version 3», RFC 1305, UDEL,
March 1992.
[5] Reynolds, J., и J. Postel, «Assigned Numbers», STD 2, RFC 1700, USC/
Information Sciences Institute, October 1994.
[6] Eastlake, D., Crocker, S., и J. Schiller, «Randomness Recommendations
for Security», RFC 1750, DEC, Cybercash, MIT, December 1994.
[7] J.-C. Bolot, T. Turletti, и I. Wakeman, «Scalable feedback control for
multicast video distribution in the internet,» in SIGCOMM Sympo-
sium on Communications Architectures и Protocols, (London, En-
gland), pp. 58—67, ACM, Aug. 1994.
[8] Balenson, D., «Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, и Identifiers», RFC 1423, TIS, IABIRTF
PSRG, IETF PEM WG, February 1993.
[9] V. L. Voydock и S. T. Kent, «Security mechanisms in high-level
network protocols,» ACM Computing Surveys , vol. 15, pp. 135—171,
June 1983.
[10] Rivest, R., «The MD5 Message-Digest Algorithm», RFC 1321, MIT
Laboratory for Computer Science и RSA Data Security, Inc., April
1992.
[11] S. Stubblebine, «Security services for multimedia conferencing,» in
16th National Computer Security Conference , (Baltimore, Maryland),
pp. 391—395, Sept. 1993.
[12] S. Floyd и V. Jacobson, «The synchronization of periodic routing
messages,» IEEE/ACM Transactions on Networking , vol. 2, pp. 122-
136, April 1994.
15*
452
Гпава 4
4.4.6.3. Управляющий протокол реального времени RTCP
Управляющий протокол RTCP (RTP control protocol; см. RFC-
1889 «RTP: A Transport Protocol for Real-Time Applications» H.
Schulzrinne, S. Casner, R. Frederick, V. Jacobson) базируется на пери-
одической передаче управляющих пакетов всем участникам сессии,
используя тот же механизм рассылки, что и для пакетов данных.
Этот протокол не имеет самостоятельного значения и используется
лишь совместно с RTP. Нижележащий протокол должен обеспечи-
вать мультиплексирование пакетов данных и управления, исполь-
зуя разные номера портов. RTCP выполняет четыре функции: *’
1. Главной задачей данного протокола является обеспечение об- "
ратной связи для контроля качества при рассылке данных. Обрат- j
ная связь может быть непосредственно полезна при адаптивном >
кодировании [1,2], но эксперименты с IP мультикастингом показа-j
ли, что для получателей крайне важно диагностировать ошибки
при рассылке пакетов. Посылка сообщений-отчетов о приеме дан- <
ных всем участникам позволяет тому, кто обнаружил какие-то про- $
блемы, понять, являются ли эти трудности локальными или гло- £
бальными. При механизме рассылки типа IP-мультикастинга, сер- '
вис провайдер, который непосредственно не вовлечен в сессию, получив ?
обратную связь, может независимо мониторировать ситуацию в сети.
2. RTCP имеет постоянный идентификатор транспортного уров-
ня для RTP источника, который называется каноническим именем t
или CNAME. Так как SSRC-идентификатор может быть изменен,
если будет зафиксировано столкновение или источник будет вынуж-
ден рестартовать, получатели нуждаются в CNAME, для того чтобы
отслеживать каждого из участников. Получателям также нужно <•
CNAME, чтобы установить соответствие между многими потоками ,
данных от одного участника при реализации нескольких сессий од-
новременно, например, чтобы синхронизовать аудио- и видеоканалы.
3. Первые две функции требуют, чтобы все участники посылали
RTCP-пакеты, следовательно, скорость передачи должна контроли-
роваться для того, чтобы RTP мог работать с большим числом
участников. При посылке каждым участником своих управляю*
щих пакетов всем остальным любой партнер может независимо
определить полное число участников сессии. Это число использует-
ся при вычислении частоты посылки пакетов.
4. Четвертая опционная функция служит для передачи мияи-г-
мальной управляющей информации, например идентификаторов уча* ?
стников, для графического интерфейса пользователя. Это полезно
для «слабо управляемых» сессий, когда участники входят и выхо* <
Сети передачи данных. Метод доступа
453
дЯт без должного контроля и без согласования параметров. RTCP
выполняет функции удобного канала для контакта со всеми участ-
никами, но он необязательно поддерживает все коммуникационные
требования приложения.
Функции 1-3 являются обязательными, когда RTP использует-
ся в среде с IP мультикастингом, и рекомендательными для всех
остальных сред. Разработчикам приложений RTP рекомендуется
избегать механизмов, которые могут работать только в уникастном
режиме.
Формат пакетов RTCP
Стандарт определяет несколько типов RTCP пакетов, которые
предназначены для переноса управляющей информации:
SR: Отчет отправителя. Для статистики приема и передачи
участников, которые являются активными отправителями.
RR: Отчет получателя. Служит для получения статистики от
участников, которые не являются активными отправителями
SDES: Элементы описания источника, включая CNAME
BYE: Отмечает прекращение участия в группе
АРР: Специфические функции приложения
Каждый RTCP-пакет начинается с фиксированной части, сход-
ной с той, которая используется RTP-пакетами, за ней следуют струк-
турные элементы, которые могут иметь переменную длину в зависи-
мости от типа пакета, но кратную 32 бит. Требования выравнива-
ния и поле длины в фиксированной части заголовка введены для
того, чтобы сделать RTCP-пакеты объединяемыми. Несколько RTCP-
пакетов могут быть соединены друг с другом без введения каких-
либо сепараторов. Такой составной RTCP-пакет, посылается в рам-
ках транспортного протокола низкого уровня, например, UDP. Не
существует специального счетчика индивидуальных RTCP пакетов
в составном, так как протокол низкого уровня задаст общую длину
и определит конец составного пакета.
Каждый индивидуальный RTCP пакет в составном пакете мо-
жет обрабатываться независимо без каких-либо требований к по-
рядку или комбинации пакетов. Однако для того чтобы выполнить
Функции протокола накладываются следующие ограничения:
Статистика приема (в SR или RR) должна посылаться так
часто, как это позволяют ограничения пропускной способности, так
Ч?2 Каждый периодически посылаемый составной пакет включает в
Себя пакет отчета.
454
Гпава 4
• Новые получатели должны приобрести CNAME для источни-
ка как можно быстрее, каждый составной RTCP-пакет должен вклю-
чать в себя SDES CNAME.
• Число типов пакетов, которые могут впервые появиться в со-
ставном пакете, должно быть ограничено.
Таким образом, все RTCP-пакеты должны посылаться в состав-
ных пакетах (не менее 2) и иметь следующий рекомендованный
формат:
Префикс шифрования. Если составной пакет должен быть за-
шифрован, он снабжается 32-битным случайным числом-префиксом,
которое копируется для каждого передаваемого составного пакета.
SR или RR. Первый RTCP-пакет в составном пакете должен
быть всегда сообщением-отчетом. Это справедливо, даже если не
было послано или получено никаких данных, в этом случае посы-
лается пустой пакет RR. Это справедливо, даже если другим RTCP-
пакётом в составной дейтограмме является BYE.
Дополнительные RR. Если число источников, для которых при-
водится статистика приема, превышает 31, в первый пакет помеща-
ется информация по части источников, остальная часть размещает-
ся в следующих RR-пакетах.
SDES-пакет, содержащий CNAME, должен быть включен в каж-
дый составной RTCP-пакет. Другие элементы описания источника
могут быть опционно добавлены, если этого требует характер при-
ложения и позволяет пропускная способность используемого ка-
нала.
BYE или АРР. Другие типы RTCP-пакетов, включая те, которые
еще предстоит определить, могут следовать далее в произвольном
порядке. Пакет BYE, если он присутствует, должен быть последним
и содержать SSRC/CSRC2. Пакеты одного и того же типа могут
повторяться.
Для трансляторов и смесителей рекомендуется объединять RTCP-
пакеты от нескольких источников. Пример составного RTCP-паке-
та, который может быть сформирован смесителем, представлен на
рис. 4.4.6.З.1. Если полная длина составного пакета превысит мак-
симальный размер пересылаемого блока данных для сети (MTU), он
может быть фрагментирован и переслан в нескольких составных
пакетах нижележащего транспортного протокола. Заметьте, что каж-
дый составной пакет должен начинаться с SR или RR-пакета.
Приложение может игнорировать RTCP пакеты неизвестного
ему типа. Дополнительные типы RTCP-пакетов могут быть зареги-
стрированы IANA (Internet Assigned Numbers Authority).
Сетн передачи данных. Метод доступа
455
---Если пакет зашифрован, вводится случайное 32-битовое число
<4---------RTCP-пакет --------------- RTCP-пакет----RTCP-пакет
SR #Доклад #узел #узел SDES #CNAME PHONE #CNAME LOC #BYE##why
SR Отправителя # 1 # 2 # # # #»
SR # # # # # # , ##
SR # # # # # # ##
Поле данных UDP-пакета (составной пакет)
Рис. 4.4.6.3.1. Пример составного пакета RTCP(#: SSRC/CSRC]
Протокол RTP построен так, чтобы позволять приложению из-
менять число участников от единиц до тысяч. Например, при аудио
конференциях информационный поток всегда ограничен (сколько
бы не было участников, все они одновременно говорить не могут, так
как не смогут ничего понять). Однако трафик управления таким
свойством не обладает. Если отчеты о приеме от каждого участни-
ка поступают с постоянной частотой, трафик управления будет рас-
ти пропорционально числу участников. Следовательно, нужно при-
нимать меры по его ограничению.
Для каждой сессии предполагается, что предельно допустимый
информационный трафик сессии делится между участниками. Эта
полоса пропускания может быть зарезервирована. Полоса не зави-
сит от метода кодирования, но на выбор метода кодирования может
оказать влияние имеющаяся в распоряжении полоса пропускания
используемого канала. Определенные ограничения на полосу сессии
может накладывать конкретное приложение. Вычисления полосы
пропускания, необходимой для управления, требует учета издержек
транспортных протоколов (например, UDP и IP).
Трафик управления должен быть ограничен малой долей пол-
ной полосы пропускания сессии: настолько малой, чтобы не нанес-
ти ущерба основной функции транспортного протокола - переносу
информации. Предлагается, чтобы доля трафика сессии, выделенная
на RTCP была фиксирована на уровне не более 5%. Параметры,
определяющие трафик, должны быть идентичными для всех участни-
нов так, чтобы они могли корректно вычислить период рассылки
отчетов. Эти параметры фиксируются в соответствующем профайле.
Алгоритм вычисления периода рассылки составных RTCP-na-
Кетов включает в себя следующие моменты:
456
Гпава 4
• Отправители коллективно выделяют, по крайней мере, 1/4
управляющего трафика, так чтобы в сессиях с большим числом
получателей и малым числом отправителей новые участники быст-
ро получали CNAME узлов отправителей.
• Вычисленный интервал между RTCP-пакетами должен быть
больше 5 сек, с тем, чтобы избежать превышения допустимого зна-
чения трафика при флуктуациях информационного потока, когда
число участников мало.
• Интервалы между RTCP-пакетами варьируются случайным
образом в пределах [0.5-1.5] от вычисленного значения с тем, что-
бы избежать непреднамеренной синхронизации работы участников
[3]. Первый RTCP-пакет, посланный после подключения к сессии,
также задерживается случайным образом со средним значением,
равным половине вычисленного интервала.
• Для того чтобы адаптироваться к количеству пересылаемой
контрольной информации, вычисляется среднее значение размера
составного пакета для отправляемых и получаемых дейтограмм.
Этот алгоритм может использоваться для сессий, в которых всем
участникам позволено посылать данные. В этом случае полоса про-
пускания сессии зависит от произведения трафика индивидуально-
го отправителя на число участников сессии, а полоса пропускания
RTCP должна быть равна 5% от этого значения.
Вычисление периода рассылки RTCP-пакетов зависит от оценки
числа узлов, участвующих в сессии. Новые узлы добавляются к
этому числу, когда они услышаны и соответствующие записи зане-
сены в таблицы SSRC или CSRC-идентификаторов. Новые записи
не рассматриваются, как действующие, до тех пор, пока не будет
получено несколько пакетов с новым SSRC. Записи могут быть
стерты из таблицы, когда приходит пакет RTCP BYE с соответству-
ющим идентификатором SSRC.
Участник может пометить другой узел как пассивный, или уда-
лить его из списка, если от него не получено RTP или RTCP-паке-
тов в течение нескольких периодов RTCP-отчетов (пороговое число
периодов предлагается сделать равным 5). Это обеспечивает опре-
деленную устойчивость против случайной потери пакетов. Все узлы
должны вычислить период RTCP-отчетов, чтобы корректно оценить
время тайм-аута.
Если зарегистрированный узел помечен как пассивный, он будет
оставаться в списках достаточно долго и учитываться при вычисле-
нии распределения полосы пропускания для RTCP. Значение тайм-
аута предлагается сделать равным 30 минутам. Заметим, что это
Сети передачи данных. Метод доступа
457
значение почти в 5 раз больше, чем наибольшая величина периода
рассылки RTCP-отчетов, который составляет 2-5 мин.
Данная спецификация определяет несколько элементов описа-
ния источника (SDES). Сюда входит CNAME (каноническое имя),
NAME (персональное имя) и EMAIL (электронный адрес). Специфи-
кация предлагает также средства для определения типа RTCP-na-
кетов, специфического для конкретного приложения. Приложения
должно проявлять определенную осторожность при выделении по-
лосы для любой дополнительной информации, так как это неизбеж-
но вызовет замедление скорости предоставления отчетов и задер-
жит присылку. Рекомендуется, чтобы дополнительная информация
индивидуального участника не занимала более 20% полосы, выде-
ленной для RTCP. Более того, даже не предполагается, что все эле-
менты SDES будут включаться каждым приложением. Например,
приложение может посылать только CNAME, NAME и EMAIL и не
посылать более никакой дополнительной информации. NAME мо-
жет быть присвоен более высокий приоритет чем EMAIL, так как
NAME будет отображаться пользовательским интерфейсом прило-
жения постоянно, в то время как EMAIL может отображаться толь-
ко при запросе. При каждой RTCP рассылке, должны посылаться
RR- и SDES-пакеты. Последний содержит элемент CNAME. Для
небольших сессий, работающих с минимальными периодами рас-
сылки, это будет делаться в среднем каждые 5 секунд. Каждая
третья рассылка (15 секунд) может содержать один дополнитель-
ный элемент в пакете SDES. Семь из восьми раз это будет элемент
NAME, и каждый восьмой раз (2 минуты) это будет элемент EMAIL.
Когда несколько приложений работают одновременно, например,
в случае мультимедиа конференции, допускается, чтобы дополни-
тельная информация пересылалась только в рамках одной RTP-
сессии. Остальные сессии будут использовать только элемент CNAME.
RTP-получатели обеспечивают обратную связь контроля каче-
ства, используя RTCP пакеты отчетов, которые могут принимать ту
или иную форму в зависимости от того, является ли получатель
одновременно и отправителем. Единственным различием между
формами отчета отправителя (SR) и получателя (RR), помимо кода
типа пакета, является то, что отчет отправителя содержит 20-бай-
товую секцию информации об отправителе. SR посылается, если
Узел отправил какие-либо информационные пакеты за время подот-
четного периода (с момента отправки предыдущего отчета), в про-
тивном случае отправляется пакет RR.
Как SR, так и RR-формы включают в себя нуль или более бло-
ков отчетов о приеме, один для каждого источника синхронизации,
458 Глава 4 f
от которого получатель принял информационные RTP-пакеты с мо-
мента последнего отчета. Отчеты не направляются для источников,
перечисленных в списке CSRC. Каждый блок отчета о приеме со-
держит статистику данных, полученных от конкретного источника.
Так как в SR или RR-пакет можно поместить максимум 31 блок
отчетов, дополнительные RR-пакеты укладываются после исходно-
го SR или RR-пакета.
Пакет отчета отправителя состоит из трех секций (см. рис. '
4.4.6.3.2), за которыми может следовать четвертая, которая опреде-
ляется, если необходимо, профайл9м. Первая секция - заголовок,
имеет 8 октетов. Эта секция содержит следующие поля:
Версия (V): 2 бита
Идентифицирует версию протокола RTP, которая совпадает с
версией RTCP-пакетов. Для данной спецификации V=2.
Заполнитель (Р): 1 бит
Если бит заполнителя Р=1, то этот пакет RTCP содержит неко-
торые октеты заполнителя после управляющей информации. Пос-
ледний октет заполнителя содержит число октетов заполнителя.
Заполнитель может быть нужен при некоторых алгоритмах шифро-
вания, использующих фиксированные блоки. В составных RTCP-
пакетах, заполнитель может быть нужен только последнему пакету, .
так как составной пакет шифруется как целое.
Число отчетов о приеме (RC): 5 бит
Число блоков отчетов о приеме, содержащихся в этом пакете.
Допустимо значение нуль.
Тип пакета(РТ): 8 бит
Содержит константу 200 для пакетов RTCP SR.
Длина*. 16 бит
Длина RTCP-пакета в 32-битных словах минус один, включая
заголовок и заполнитель.
SSRC: 32 бит
Идентификатор источника синхронизации для отправителя SR-
пакета.
Вторая секция информации из 20 октетов присутствует в каж-
дом пакете отправителя. Поля этой секции имеют следующие зна-
чения:
Временная метка NTP: 64 бита
Указывает абсолютное время, когда данный отчет был послан,
оно может быть использовано в комбинации с временными метками,
присланными в отчетах о приеме другими получателями, для изме-
рения RTT до этих получателей.
^еги передачи данных. Метод доступа
459
0 1 2 3 8 16 31
V=2 Р RC PT=SR=2Q0 Длина Заголовок
SSRC отправителя
Временная метка NTP (старшая часть)
Временная метка NTP (младшая часть)
Временная метка RTP
Число пакетов отправителя
Число октетов отправителя
SSRC.1 (SSRC первого источника) Блок
Доля потерянных Суммарное число потерянных пакетов отчета 1
Наибольший номер из числа полученных пакетов
Разброс времен прибытия
Последний SR (LSR)
Задержка с момента последнего SR (DLSR)
SSRC.2 (SSRC второго источника) Блок
отчета 1
Расширения, определяемые профайлом
Рис. 4.4.6.3.2. Формат RTCP пакета сообщения отправителя
Временная метка RTP: 32 бита
Соответствует тому же времени, что и временная метка NTP, но
измеряется в тех же единицах и с тем же произвольным смещени-
ем, что и временные метки информационных пакетов RTP. Это со-
ответствие может использоваться для внутри- и межсредовой синх-
ронизации для источников, чьи временные метки NTP синхронизо-
ваны, и может быть использовано получателями, независящими от
сРеды для оценки номинальной задающей частоты RTP. Заметьте,
что в большинстве случаев эти временные метки не будут равны
временным меткам RTP в любых последовательных информацион-
ных пакетах.
460
Гпава 4 s
Число пакетов отправителя'. 32 бита
Полное число информационных RTP-пакетов, переданных от-
правителем от начала передачи до момента генерации SR-пакета.
Число сбрасывается в нуль, если отправитель изменяет свой SSRC-
идентификатор.
Число октетов отправителя'. 32 бита
Полное число октетов поля данных (исключая заголовки и за-
полнители), переданных в информационных RTP-пакетах отправи-
телем, начиная с начала передачи до момента генерации SR-пакета.
Это число сбрасывается в нуль, когда отправитель меняет свой SSRC-
идентификатор. Это поле может быть использовано для оценки сред-
него потока данных.
Третья секция состоит из нуля или более блоков отчета о при-
еме в зависимости от числа источников, пакеты от которых приня-
ты с момента последнего отчета. Каждый блок отчета о приеме
несет в себе статистику получения RTP-пакетов, поступающих от
одного из источников синхронизации. Получатель не сохраняет ста- ,*
тистику, когда источник изменяет свой SSRC-идентификатор.
SSRC_n (идентификатор источника): 32 бита
SSRC-идентификатор источника, к которому относится инфор- $
мация, содержащаяся в блоке отчета о получении.
Доля потерянных (пакетов): 8 бит
Часть информационных RTP-пакетов от источника SSRC_n по- $
терянная с момента посылки предыдущего SR или RR-пакетов, пред-
ставленная в виде числа с фиксированной запятой, помещенной сле-
ва. Это эквивалентно целому, полученному после умножения данно-
го числа на 256. Эта доля получается в результате деления числа :
потерянных пакетов на ожидаемое число пакетов. Если потери из-
за дубликатов оказались отрицательны, доля потерянных пакетов
объявляется равной нулю. Заметим, что от источника, все пакеты
которого были потеряны при транспортировке, отчета о приеме по-
слано не будет.
Суммарное число потерянных пакетов: 24 бита
Полное число информационных RTP-пакетов от источника..
SSRC_n, которые были потеряны с момента начала передачи. Это
число определяется как разность между ожидаемым и полученным
числами пакетов, где число полученных включает в себя и дублика-
ты. Таким образом, пакеты, пришедшие с опозданием, не считаются |
потерянными, а число потерянных пакетов может оказаться отри-
цательным, если получены дубликаты пакетов. Число ожидаемых
пакетов определяется как разность между номером последнего по-
лученного пакета и номером первого пакета.
Сети передачи данных. Метод доступа
461
Наибольший номер из числа полученных пакетов: 32 бита
Младшие 16 бит содержит наибольший порядковый номер полу-
ченного от источника SSRCn информационного RTP-пакета. Стар-
шие 16 бит несут в себе число циклов нумерации (переполнения
счетчика номеров пакетов). Заметим, что различные получатели в
рамках одной и той же сессии генерируют разные коды циклов нуме-
рации (расширений), если они начали свою работу в разное время.
Разброс времени доставки: 32 бита
Оценка статистической вариации периода прихода RTP-пакетов,
измеряемого с помощью временных меток и характеризуемого це-
лым числом. Разброс периода прихода пакетов J определяется как
усредненное отклонение разности D расстояния между пакетами со
стороны получателя по отношению к той же величине для стороны
отправителя. Эта величина характеризует относительный разброс
времени транспортировки пактов.
Если S. равно временной метке i-ro пакета RTP, a R - время
прибытия в единицах временной метки пакета i, тогда для двух
пакетов i и j D может быть выражено как
D.. =(R.-Ri)-(Sj-S.)=(Rj-Sj)-(R.-S.)
Разброс времени доставки вычисляется непрерывно для каждого
пребывающего от SSRC_n пакета i, используя разность D для дан-
ного пакета и предыдущего пакета i-1 согласно формуле
J=J+(|DM.|-J)/16
Вычисление разброса времени доставки позволяет мониторам,
независимым от профайла, осуществлять интерпретацию отчетов,
приходящих от различных приложений. Это алгоритм является
оптимальным первым приближением и масштабный параметр 1/
16 обеспечивает приемлемое уменьшение влияние шума и разумную
скорость сходимости [4].
Последняя временная метка (LSR) (Last SR): 32 бита
Средние 32 бита из 64 во временной метке NTP, полученной как
часть последнего отчета RTCP-отправителя (SR) об источнике
SSRC_n. Если SR пока не получено, в поле заносится нуль.
Задержка с момента последнего SR (DLSR — Delay of Last
SR): 32 бита <
Задержка, выраженная в единицах 1/65536 секунды, между мо-
ментом получения последнего SR-пакета от источника SSRCn и
вРеменем посылки блока отчета о приеме. Если от SSRC_n пока не
п°лучено ни одного пакета SR, в nojie^DLSR заносится нуль.
Пусть SSRCr обозначает получателя, отправляющего отчет о
пРиеме. Источник SSRC_n может вычислить циклическую задерж-
ку МаршруТа RTT для SSRC_r путем записи времени А, когда этот
462
Гпава 4
блок отчета о приеме был получен. Он вычисляет полное время RTT
А-LSR, используя поле последней временной метки SR (LSR), и за-
тем путем вычитания получает (А — LSR — DLSR). Это может
быть использовано в качестве меры расстояния до кластера получа-
телей, хотя некоторые связи имеют весьма асимметричный характер
задержек. Формат пакета отчета о приеме показан на рис. 4.4.6.3.3.
0 1 2 3 8 16 31
V=2 | Р RC PT=RR=2011 Длина Заголовок
SSRC отправителя
SSRCJ (SSRC первого источника)
Доля потерянных Суммарное число потерянных пакетов Сообщение
-отчет
Наибольший*номер из числа полученных пакетов 1
Разброс времен прибытия
Последний SR (LSR)
Задержка с момента последнего SR (DLSR)
SSRC_2 (SSRC второго источника) Сообщение
- отчет
2
Расширения, определяемые профайлом
Рис. 4.4.6.3.3. Формат пакета отчета о приеме [RR]
Формат пакета отчета о приеме (RR) аналогичен формату SR паке- '
та за исключением того, что поле типа содержит код 201 и опущены
первые пять слов информации об отправителе (это NTP/RTP времен-
ные метки, а также число пакетов и октетов отправителя). Остальные
поля -имеют то же самое значение, как и для пакета SR.
Когда нет информации об отправке или приеме, в начало состав- :
ного RTCP-пакета вставляется пустой RR-пакет (RC = 0).
Профайл должен определять специфические для приложения
расширения в отчетах получателей и отправителей, если имеется
дополнительная информация о получателе или отправителе, кото-:
рая должна регулярно сообщаться. Этот метод предпочтительнее,
чем описание нового типа RTCP-пакета, так как не требует допол-
нительных издержек.
Сети передачи данных. Метод доступа
463
Если необходима дополнительная информация, она должна
быть включена в первую очередь в расширение для отчета отпра-
вителя, но не будет присутствовать в отчетах о приеме. Если
должна быть подключена информация о получателях, эти данные
могут структуризоваться в виде массива блоков в дополнение к
существующему массиву блоков-отчетов; т.е., число блоков будет
задано полем RC.
Ожидается, что качество обратной связи важно не только для
отправителя и получателей, но и для независимых мониторов. От-
правитель может модифицировать свою передачу на основе обрат-
ной связи, получатели могут определить, являются ли проблемы
локальными, региональными или глобальными. Менеджер сети мо-
жет использовать независимые мониторы, которые получают толь-
ко RTCP-пакеты, а не соответствующие информационные RTP-па-
кеты, для оценки эксплуатационных параметров своей сети для муль-
тикастного обмена.
На основе информации отправителя независимый монитор мо-
жет вычислить усредненное значение потока, не получая этих дан-
ных. Если можно предположить независимость вероятности потери
пакета от его размера, тогда число полученных пакетов, умноженное
на средний размер поля данных, может дать оценку для пропускной
способности получателя.
Для RTCP допустимо расщепление составных пакетов на паке-
ты нижележащего уровня, один зашифрованный и один открытый.
Например, информация SDES может быть зашифрована, в то время
как отчеты о приеме будут посылаться открыто для обеспечения
мониторинга. В примере, представленном на рис. 4.4.6/3.4 инфор-
мация SDES должна быть присоединена к RR-пакету, не содержа-
щему отчета. Таким образом, соблюдается правило о том, что все
составные пакеты начинаются с SR или RR пакетов.
UDP UDP
Зашифровано
Не зашифровано
Рис. 4.4.6.3.4. Зашифрованный и незашифрованный
RTCP-пакеты (#SSRCJ
464
Гпава 4
0 1 2 3 8 16 31
V=2 Р SC PT=SDES=202 Длина Заголовок Блок 1 Блок 2
SSRC/CSRC_1
Элементы SDES
SSRC/CSRC_2
Элементы SDES
Рис. 4.4.6.3.5. Формат пакета SDES
SDES: RTCP-пакет описания источника (рис. 4.4.6.3.4).
Пакет SDES состоит из заголовка и нескольких фрагментов,
каждый из которых содержит элементы описания источника, соот-
ветствующего данному фрагменту (число фрагментов может быть
равно нулю).
Поля версия (V), заполнитель (Р), длина имеют то же назначе-
ния что и в случае SR-пакетов.
Тип пакета (РТ): 8 бит
Содержит константу 202, которая идентифицирует данный па-
кет как RTCP SDES.
Число источников (SC): 5 бит
Число фрагментов SSRC/CSRC, содержащихся в данном SDES-
пакете. Значение нуль допустимо, но бесполезно.
Каждый фрагмент состоит из идентификатора SSRC/CSRC, за
которым следует список элементов описания источника SSRC/CSRC
(число элементов может равняться нулю). Каждый фрагмент начи-
нается на 32-битовой границе. Каждый элемент состоит из 8-бито-
вого поля типа, 8-битового поля числа октетов, характеризующего
длину текста, исключая эти 2 октета заголовка, и собственно тек-
ста. Заметьте, что текст не может содержать более 255 октетов, но
это вполне согласуется с требованиями ограничений на полосу, вы-
деляемую для RTCP-пакетов.
Текст кодируется согласно требованиям UTF-2, описанным в
стандарте 10646 [5,6], Annex F ISO. Эта кодировка известна также
под названием UTF-8 или UTF-FSS. Она описана в документе «File
System Safe UCS Transformation Format (FSS_UTF)», «X/Open
Preliminary Specification», документ номер P316 и «Unicode Technical
Report #4». US-ASCII являются модификациями данного кодиро-
вания и требуют определенных доработок. Присутствие многоок-
Сети передачи данных. Метод доступа
465
тетного кодирования задается путем установления старшего бита
октета символа равным 1.
Описания элементов плотно прилегают друг к другу, т.е., их опи-
сания не выравниваются на 32-битовые границы путем индивиду-
ального заполнения. Текст не завершается нулем, так как мульти-
октетное кодирование может включать в себя нули. Список элемен-
тов в каждом фрагменте завершается одним или несколькими
нулевыми октетами, первый из которых интерпретируется как тип
элемента нуль, завершающий список, а последующие служат для за-
полнения до 32-битовой границы. Фрагменты, содержащие только
нулевые элементы (4 нулевых октета), допускаются, но бесполезны.
Оконечные системы посылают один пакет SDES, содержащий их
собственный идентификатор источника (то же, что и SSRC в фикси-
рованных RTP-заголовках). Смеситель посылает один пакет SDES,
содержащий фрагмент для каждого источника, от которого поступа-
ет SDES-информация, или несколько SDES-пакетов описанного выше
формата в случае, когда число таких источников больше 31.
Из числа SDES-элементов только CNAME является обязатель-
ным. Некоторые элементы, описанные ниже, могут оказаться полез-
ными только для определенных профайлов, но типы элементов вы-
деляются из общего кодового пространства, с тем, чтобы обеспечить
совместную работу различных приложений. Дополнительные эле-
менты могут быть определены в профайле путем регистрации их
кодов IANA.
CNAME: Канонический идентификатор конечной системы (рис.
4.4.6.3.6).
0 7 8 16 31
CNAME=1 Длина Имя пользователя и домена ...
Рис. 4.4.6.3.6 Формат CNAME
Идентификатор CNAME имеет следующие свойства:
• Так как характеризуемый случайным числом идентификатор
SSRC может измениться, если обнаруживается конфликт, или если
программа перезапускается, элемент CNAME должен обеспечить связь
между идентификатором SSRC и источником, которая должна оста-
ваться неизменной.
• Подобно идентификатору SSRC, идентификатор CNAME дол-
жен быть уникальным для каждого из участников RTP-сессии.
• Чтобы обеспечить связь между мультимедийными средствами,
Используемыми одним и тем же участником в наборе взаимосвя-
466
Гпава 4
занных RTP-сессий, CNAME должно быть зафиксировано для дан-
ного участника.
• Для того чтобы обеспечить независимый мониторинг, CNAME
должно быть удобным средством идентификации источника как
для программы, так и для человека.
Следовательно, CNAME должно по возможности получаться алго-
ритмически, а не вводиться вручную. Чтобы удовлетворить этому
требованию следует использовать описанный ниже формат, если дру.
гой синтаксис или семантика не задана. Элемент CNAME должен
иметь формат «user@host», или «host», если имя пользователя не
доступно, как это бывает в однопользовательских системах. Для обо-
их форматов, «host» является либо полным именем домена ЭВМ, от-
куда поступают данные, форматированные согласно требованиям до-
кументов RFC-1034 [7], RFC-1035 [8] и раздела 2.1 RFC-1123 [9];
или стандартным ASCII-представлением цифрового, сетевого адреса
интерфейса ЭВМ, используемого для RTP-обмена. Например, стандарт-
ное ASCII-представление IP-адреса (версия 4) имеет «точечно-цифро-
вой» вид. Стандартное полное имя домена более удобно для человека
и исключает необходимость посылать в дополнение элемент NAME, но
в некоторых обстоятельствах его может быть трудно или невозможно
получить. Примерами могут служить «dwarf@sleepy.beauty.com» или
«dwarf@192.166.148.9» для мультипользовательских систем. В си-
стемах, где нельзя получить имя пользователя, можно применить
«sleepy.beauty.com» или «192.166.148.9».
Имя пользователя должно иметь форму, которая может быть
использована в запросах «finger» или «talk», т.е., это скорее имя,
вводимое при аутентификации, чем истинное имя пользователя.
Имя ЭВМ не обязательно идентично электронному почтовому адре-
су участника.
Этот синтаксис не обеспечит уникальность имени в тех случаях,
когда приложение позволяет пользователю сформировать несколь-
ко источников на своей ЭВМ. Такое приложение должно полагать-
ся на SSRC для дополнительной идентификации источника, или на
профайл, для которого приложение должно будет специфицировать
синтаксис идентификаторов CNAME.
Если каждое приложение создает свои CNAME независимо, в
результате можно получить дублирующие имена. Если необходимо
осуществить связь между сессиями, работающими в разных средах»
должны быть использованы специальные средства, которые с одной
стороны обеспечат уникальность имен, а с другой припишут идеН;
тичные имена источникам, размещенным в одной ЭВМ, но работаю-
щих с разными средами.
Сети передачи данных. Метод доступа
467
разработчики приложений должны учитывать возможность того,
что использование сетевого адреса, например, для Net-10 (описано в
документе RFC 1597 [10]) может привести к появлению имен дуб-
ликатов. Дубликаты имен могут возникать, когда ЭВМ с частными
адресами, не имеющие выхода в Интернет, переадресуют свои RTP-
пакеты в Интернет через транслятор RTP-уровня. (См. также RFC-
162 7 [11]-) Для того чтобы разрешать такие конфликты приложе-
ние должно иметь средства для выработки и присвоения уникаль-
ных имен CNAME.
NAME: Имя пользователя (рис. 4.4.6.3.7).
078 16 31
NAME=2 Длина Общее имя источника
Рис. 4.4.6.3.7. Формат элемента NAME
Это настоящее имя, используемое для описания источника, напр.,
«Ivan Durak, Russia.com». Оно может быть сформировано пользова-
телем в произвольной форме. Для приложений типа конференций
эта форма имени может быть наиболее желательной при отображе-
нии в списках участников и, следовательно, может посылаться бо-
лее часто, чем любые другие элементы помимо CNAME. Такой при-
оритет может быть установлен профайлом. Значение NAME предпо-
лагается неизменным, по крайней мере в пределах сессии. В то же
время не требуется, чтобы оно было уникальным для группы участ-
ников сессии.
EMAIL: Адрес электронной почты (рис. 4.4.6.3.8).
078 16 31
EMAIL=3 Длина Email адрес источника
Рис. 4.4.6.3.8. Формат элемента EMAIL
Адрес электронной почты должен иметь формат, согласующийся с
требованиями документа RFC-822 [12], например, «Yuri.Semenov@itep.ru».
Значение элемента EMAIL предполагается неизменным в пределах
сессии.
PHONE: Телефонный номер (рис. 4.4.6.3.9).
468
Гпава 4
0 7 8 16 31
PHONE=4 Длина Номер телефона источника ....
Рис. 4.4.6.3.9. Формат элемента PHONE
Телефонный номер должен иметь формат с символом плюс, за-
мещающим международный код. Например, , «4-7 095 129 9442»
для номера в России.
LOC: Географический адрес пользователя (рис. 4.4.6.3.10).
0 7 8 16 31
LOC=5 Длина Географическое положение узла
Рис. 4.4.6.3.10. Формат элемента LOC
Различная детализация этого элемента сильно зависит от прило-
жения. Для использования во время конференций строки типа «Zuzino,
Moscow» может быть достаточно, в то время как для активной систе-
мы поиска сотрудников приемлемой может стать строка «Room 322,
ITEP BL 180». Значение LOC предполагается неизменным на время
сессии. Исключение могут составлять мобильные ЭВМ.
TOOL: Имя приложения или программного средства (рис.
4.4.6.3.11).
078 16 31
TOOL=6 Длина имя/версия источника приложения ...
Рис. 4.4.6.3.11. Формат элемента TOOL
^Строка, сообщающая имя и, возможно, версию приложения, фор-
мирующего поток, напр., «VC 2.1». Эта информация может быть
полезной для отладочных целей и сходна с SMTP-заголовкамй.
Предполагается, что значение TOOL остается постоянным в течение
сессии.
NOTE: Уведомление/статус (рис. 4.4.6.3.12).
0 7 8 16 31
NOTE=7 Длина Описание источника ...
Рис. 4.4.6.3.12. Формат элемента NOTE
Сети передачи данных. Метод доступа 469
Для этого элемента предлагается следующая семантика (она
может быть определена профайлом). Элемент NOTE предназначен
для сообщений, характеризующих текущее состояние источника,
например, «on the phone, can’t talk». Или, во время семинара этот
элемент может быть использован для передачи темы обсуждения.
Он может служить только для передачи необычной информации и
не должен включаться в систематическую рассылку, так как замед-
лит скорость передачи отчетов. В частности, он не должен вклю-
чаться в конфигурационный файл пользователя.
Так как может быть важно, отобразить элемент NOTE (в случае,
когда он активен), скорость, с которой передаются другие элементы
(кроме CNAME), такие как NAME, может быть уменьшена с тем,
чтобы передать элемент NOTE. Когда сообщение становится не акту-
альным, элемент NOTE передается еще несколько раз с той же часто-
той, но с длиной строки, равной нулю. Однако, получатели должны
рассматривать элемент NOTE, потерявшим актуальность, если они
не получают его, например, на протяжении 20-30 RTCP-интервалов.
PRIV: Элемент частного расширения SDES (рис. 4.4.6.3.13).
о 7 8
16
24
PRIV=8 Длина | Длина префикса | Строка префикса... I
Строка значения ...
Рис. 4.4.3.3.73. Формат элемента расширения PRIV
Этот элемент используется, для того чтобы определить экспери-
ментальные или специфические для приложения расширения SDES.
Элемент содержит префикс, включающий в себя субполя длины и
строки префикса, за которыми следует строка значения, занимаю-
щая остальное пространство элемента, и несущая необходимую ин-
формацию. Поле длины префикса занимает 8 бит. Строка префикса
представляет собой имя, определенное человеком, который сформи-
ровал элемент PRIV. Это имя должно быть уникальным и никакой
Другой элемент PRIV не может иметь такое же. Разработчик прило-
жения может выбрать имя приложения плюс, если необходимо, до-
полнение.
Заметьте, что префикс занимает некоторое место, из числа 255
октетов элемента, по этой причине желательно, чтобы он был короче.
Префиксы SDES PRIV не нужно регистрировать в IANA. Если
некоторая форма элемента PRIV окажется достаточно универсаль-
ной, она должна быть приписана некоторому регулярному типу эле-
470
Гпава 4
мента SDES, зарегистрированному IANA, так что необходимость в
префиксе отпадет. Это упростит использование и увеличит эффек-
тивность передачи.
BYE: Пакет завершения сессии RTCP (рис. 4.4.6.3.14).
0 1 2 3 8 16 31
V=2 Р SC PT=BYE=203 Длина
SSRC/CSRC
Длина Причина ухода
Рис. 4.4.6.3.14. Формат пакета BYE
Заголовок
Опционно
Пакет BYE указывает на то, что один или более источников
покинули сессию.
Поля версия (V), заполнитель (Р), и длина имеет то же назна-
чения что и в случае SR-пакетов.
Тип пакета (РТ): 8 бит
Содержит код 203, который указывает на то, что это RTCP па-
кет BYE.
Число источников (SC): 5 бит
Число фрагментов SSRC/CSRC, содержащихся в данном BYE-
пакете. Значение нуль допустимо, но бесполезно.
Если пакет BYE получен смесителем, он переадресует этот пакет
б идентификаторами SSRC/CSRC без изменений. Если сам смеси-
тель отключается, он должен послать пакет BYE, перечислив все
источники, вносившие вклад в поток, с которым он работал, а также
свой идентификатор SSRC. Опционно пакет BYE может содержать
8-битовое число октетов, за которым следует текст соответствую-
щей длины, объясняющий причину отключения, например «camera
malfunction» или «RTP loop detected». Строка имеет то же кодиро-
вание, что описано для SDES. Если строка заполняет пакет до оче-
редной 32-битовой границы, то в конце ее не будет нуля. В против-
ном случае, пакет BYE дополняется нулевыми октетами.
АРР: RTCP-пакет, определенный приложением (рис. 4.4.6.3.15).
Пакет АРР предназначен для экспериментального использова-
ния при разработке новых приложений или новых функций. Здесь
не требуется регистрация типа пакета. АРР-пакеты с не узнанными
именами должны игнорироваться. После тестирования, когда преДг
полагается широкое использование, рекомендуется новый АРР-па*
кет переопределить без субтипа и поля имени, после чего его следуй
Сети передачи данных. Метод доступа
471
0 1 2 3 8 16 31
V=2 Р Субтип РТ=АРР=204 Длина
SSRC/CSRC
Имя (ASCII)
Информация, зависящая от приложения
Рис. 4.4.6.3.15. Формат пакета, задаваемого приложением
зарегистрировать в IANA (Internet Assigned Numbers Authority), как
новый тип RTCP-пакета.
Поля версия (V), заполнитель (Р),и длина имеют то же назна-
чения что и в случае SR-пакетов.
Поле су б тип*. 5 бит
Может использоваться в качестве субтипа, допуская описание
набора АРР-пакетов с уникальным именем, или для любых данных,
специфических для конкретного приложения.
Поле тип пакета (РТ): 8 бит
Содержит код 204, который указывает на то, что это RTCP па-
кет АРР.
Поле имя: 4 октета
Имя, выбираемое разработчиком, который определил набор АРР-
пакетов. Это имя должно быть уникальным и не совпадать ни с
одним другим именем другого АРР-пакета данного приложения.
Разработчик приложения может использовать для данной цели имя
приложения. При этом новые типы пакетов приложения будут от-
личаться друг от друга кодом субтипа. Имя интерпретируется как
последовательность четырех ASCII-символов, где строчные и про-
писные буквы не являются тождественными.
Поле информация, зависящая от приложения имеет переменную
Длину. Информация, зависящая от приложения используется в АРР-
пакетах опционно. Она интерпретируется приложением, а не самим
RTP. Размер поля должен быть кратным 32 бит.
Обработка RTCP в трансляторах
Кроме переадресации информационных пакетов (иногда с неко-
торой модификацией) трансляторы и мультиплексоры должны так-
обрабатывать RTCP-пакеты. Во многих случаях они разделяют
На составные части комбинированные RTCP-пакеты, полученные от
оконечных систем, собирают SDES-информацию и модифицируют
или RR-пакеты. Пересылка этой информации может иницииро-
Ваться приходом пакета или RTCP-таймером транслятора или сме-
С11теля.
472
Гпава 4
Транслятор, который не модифицирует информационные пакеты,
например такой, который осуществляет связь между мультикастны-
ми и уникастными адресами, может просто переадресовывать RTCP-
пакеты. Транслятор, который каким-то образом модифицирует поле
данных, должен выполнить соответствующие преобразования в SR
и RR-информации, так чтобы она отражала качество приема. Такие
трансляторы не должны просто переадресовывать RTCP-пакеты.
Вообще транслятор не должен объединять SR и RR-пакеты от раз-
личных источников, так как это ухудшит точность измерения за-
держки распространения, использующего поля LSR и DLSR.
Информация отправителя SR*. Транслятор не генерирует своей
собственной информации отправителя, а переадресует SR-пакеты,
полученные из одной области и адресованные в другие области.
SSRC остается неизменным, но, если необходима трансляция, инфор-
мация отправителя должна быть модифицирована. Если трансля-
тор изменяет кодировку данных, он должен изменить поле число
октетов отправителя. Если он объединяет несколько информаци-
онных пакетов в один, то нужно изменить поле число пакетов от-
правителя. Если он изменяет частоту временных меток, нужно мо-
дифицировать поле «временная метка RTP в SR-пакете.
Блоки отчетов о приеме SR/RR*. Транслятор переадресует отче-
ты о приеме, полученные из одной области сети в другие. Заметим,
что эти сообщения движутся в направлении противоположном дан-
ным. SSRC при этом остается неизменным. Если транслятор объе-
диняет несколько информационных пакетов в один выходной па-
кет, и, следовательно, изменяет номер по порядку, он должен позабо-
титься о модификации полей потерянных пакетов и наибольший
номер из числа полученных пакетов.
Транслятор не нуждается в своем собственном SSRC-идентифи-
каторе, но может и завести такой идентификатор, для того чтобы
посылать отчеты о том, что получено. Такие отчеты будут посы-
латься во все области сети, подключенные к транслятору.
SDES. Трансляторы осуществляют переадресацию без измене-
ния SDES-информации, полученной из сетевых областей, участвую-
щих в сессии. Но они могут, например, решить отфильтровывать
некоторую информацию, если этого требуют ограничения пропуск-
ной способности. Транслятор, который генерирует свои собственные
RR-пакеты, должен посылать SDES CNAME-информацию о самом
себе в область сети, куда он шлет эти RR-пакеты.
BYE. Трансляторы переадресуют пакеты BYE без изменений.
Трансляторы, имеющие свой собственный SSRC должны генёриро-
Сети передачи данных. Метод доступа
473
вать пакеты BYE с этим SSRC-идентйфикатором, если они намере-
ваются прекратить свою работу по переадресации.
АРР. Трансляторы переадресовывают АРР-пакеты без каких-
либо изменений.
Обработка RTCP в смесителях 1
Так как смеситель генерирует свой собственный информацион-
ный поток, он не пропускает через себя SR или RR-пакеты и вы-
нужден формировать новые пакеты для обоих направлений.
Информация отправителя SR. Смеситель не пропускает через
себя данные об отправителе от источников, которые он объединяет,
так как характеристики потока при смешении кардинально меня-
ются. Как источник синхронизации смеситель генерирует свои соб-
ственные SR-пакеты с информацией отправителя и посылает их в-
том же направлении, что и смешанный поток.
Блоки отчетов о приеме SR/RR. Смеситель генерирует свои
собственные отчеты о приеме для каждой из сетевых областей и
посылает их туда. Он не посылает эти отчеты о приеме другим
областям и не переадресует отчеты из одной области в другую.
SDES. Смесители обычно переадресуют без изменений SDES-
информацию, которую они получают из сетевых областей зоны об-
служивания, но могут отфильтровывать любую SDES-информацию
помимо CNAME в случае ограничения полосы пропускания. CNAME
должны доставляться, чтобы обеспечить работу по обслуживанию
столкновений идентификаторов SSRC. (Идентификатор в списке
CSRC, сгенерированный смесителем может вызвать столкновение с
SSRC-идентификатором, сформированным оконечной системой.)
Смеситель должен послать SDES CNAME информацию о самом себе
той сетевой области, куда он посылает SR или RR пакеты.
Так как смесители не переадресуют SR или RR пакеты, они
обычно извлекают SDES-пакеты из составных RTCP-пакетов. Для
того чтобы минимизировать издержки, фрагменты из SDES-пакетов
могут быть уложены в один SDES-пакет, который вкладывается в
SR или RR пакет, посылаемый смесителем.
Смеситель, который не вводит идентификаторы CSRC, может так-
же воздерживаться от пересылки SDES CNAME. В этом случае
пространства идентификаторов SSRC для обоих сетевых областей
оказываются независимыми.
BYE. Смесители должны переадресовывать пакеты BYE. Они дол-
жны генерировать пакеты BYE со своим собственным идентифика-
тором SSRC, если они намериваются прервать пересылку пакетов.
АРР. Обработка АРР-пакетов смесителями зависит от вида при-
ложения.
474
Гпава 4
Таблица 4.4.6.3.1. Типы пакетов RTCP
Сокращенное название Имя Значение
SR sender report - сообщение отправителя 200
RR receiver report - сообщение получателя 201
SDES source description - описание источника 202
BYE goodbye - завершение 203
АРР application-defined - определен приложением 204
Значения типов RTCP-пакетов (табл. 4.4.6.3.1) были выбраны
в диапазоне 200-204 для улучшенного контроля корректности заго-
ловков RTCP пакетов. Когда поле типа пакета RTCP сравнивается с
соответствующим октетом RTP-заголовка, этот диапазон соответ-
ствует маркерному биту 1 (который обычно отсутствует в информа-
ционных пакетах) и старшему биту стандартного поля типа данных
равному 1 (так как статические типы поля данных обычно лежат в
младшей половине).
Другие константы определены IANA. Экспериментаторам пред-
лагается зарегистрировать числа, которые им нужны, а затем анну-
лировать регистрацию, если необходимость в них отпадет.
Таблица 4.4.6.3.2. Типы SDES
Сокращенное название Имя Значение
END Конец списка SDES 0
CNAME Каноническое имя 1
NAME Имя пользователя 2
EMAIL Электронный адрес пользователя 3
PHONE Телефонный номер пользователя 4
ос Географическое положение пользователя 5 _
TOOL Имя приложения или программного средства 6
NOTE Замечания об отправителе (Notice about the source) 7
PRIV Частные расширения 8 _
Типы пакетов RTCP. При необходимости могут быть определе-
ны и зарегистрированы IANA новые, специфические для определен-
ных классов приложений типы пакетов RTCP.
Период отчетов RTCP. Профайл должен специфицировать, ка-
кие значения констант будут использоваться для вычисления пери-
ода посылки RTCP отчетов. Это доля полосы пропускания, выДе'
ленная для RTCP, минимальный период посылки отчетов.
Сети передачи данных. Метод доступа 475
Использование SDES: Профайл может специфицировать отно-
сительные приоритеты элементов RTCP SDES, которые будут пере-
даваться или будут полностью исключены; альтернативный син-
таксис или семантику для элемента CNAME; формат элемента LOC;
семантику и использование элемента NOTE; или новые типы SDES,
которые следует зарегистрировать IANA.
Проверка корректности заголовка RTCP
Пакеты RTCP подвергаются следующим проверкам.
• RTP поле версии должно быть равно 2.
• Поле типа данных первого RTCP пакета в составном пакете
должно быть SR или RR.
• Бит заполнителя (Р) должен быть равен нулю для первого
пакета составного RTCP пакета, так как заполнитель может при-
сутствовать только в последнем.
• Длина полей индивидуальных RTCP-пакетов должна в сумме
равняться полной длине составного пакета.
В RFC-1889 представлен текст программы, которая выполняет
все перечисленные проверки, представлены там и фрагменты про-
грамм генерации и разборки пакетов SDES, а также вычисления
периода рассылки RTCP-пакетов.
Библиография
[1] I. Busse, В. Deffner, and Н. Schulzrinne, «Dynamic QoS control of
multimedia applications based on RTP,» Computer Communications ,
Jan. 1996.
[2] S. Floyd and V. Jacobson, «The synchronization of periodic routing
messages,» in SIGCOMM Symposium on Communications Architec-
tures and Protocols (D. P. Sidhu, ed.), (San Francisco, California), pp.
33—44, ACM, Sept. 1993. also in [24].
[3] J. A. Cadzow, Foundations of digital signal processing and data
analysis New York, New York: Macmillan, 1987.
W] International Standards Organization, «ISO/IEC DIS 10646-1:1993
information technology — universal multiple-octet coded character
set (UCS) — part I: Architecture and basic multilingual plane,» 1993.
№] The Unicode Consortium, The Unicode Standard New York, New York:
Addison-Wesley, 1991.
№] Mockapetris, P., «Domain Names — Concepts and Facilities», STD13,
RFC 1034, USC/Information Sciences Institute, November 1987.
I(J Mockapetris, P., «Domain Names — Implementation and Specification»,
STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
1 ] Braden, R., «Requirements for Internet Hosts — Application and Sup-
port», STD 3, RFC 1123, Internet Engineering Task.Force, October 1989.
476
Гпава 4
[9] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, «Address
Allocation for Private Internets», RFC 1597, T.J. Watson Research
Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994.
[10] Lear, E., Fair, E., Crocker, D., and T. Kessler, «Network 10 Considered
Harmful (Some Practices Shouldn’t be Codified)», RFC1627, Silicon
Graphics, Inc., Apple Computer, Inc., Silicon Graphics, Inc., July 1994.
[11] Crocker, D., «Standard for the Format of ARPA Internet Text
Messages», STD 11, RFC 822, UDEL, August 1982.
[12] W. Feller, An Introduction to Probability Theory and its Applica-
tions, Volume 1 , vol. 1. New York, New York: John Wiley and Sons,
third ed., 1968.
4.4.6.4. Протокол мультикастинг-маршрутизации (DVMRP)
DVMRP — (Distance Vector Multicast Routing Protocol; RFC-1075)
мультикастинг-протокол, где в качестве метрики применен вектор
расстояния (см. также описание RIP, RFC-1058). DVMRP исполь-
зует идеологию документа RFC-1054, а также алгоритм TRPB
(Truncated Reverse Path Broadcasting). При получении первого па-
кета маршрутизатор не имеет информации о группе. Он посылает,
полученный пакет через все интерфейсы, кроме того, через который
этот пакет получен. Если пакет пришел не через интерфейс, кото-
рый используется маршрутизатором для посылки пакетов отправи-
телю мультикаст-информации, полученный пакет выбрасывается.
При получении пакета маршрутизатором, в зоне ответственности
которого нет членов группы, он посылает сообщение об исключении
(prun-команда). Эти сообщения используются для отсечения от де-
рева маршрутов веток, не содержащих членов группы. По истечении
определенного времени «отрезанные» ветки дерева маршрутов «от-
растают» вновь и снова могут быть отсечены (протокол TRPB). В
настоящее время этот протокол рассматривается в качестве экспе-
риментального и его широкое применение не рекомендуется. DVMRP
относится к внутренним протоколам маршрутизации, пригодным
для использования в пределах автономной системы.
Протокол DVMRP используется для построения дерева мульти-
кастинг-маршрутов. Предполагается, что в дальнейшем принцип
«вектора расстояния» может быть заменен алгоритмом «состояния
канала» (MOSPF аналог OSPF; RFC-1584). Целью протокола DVMRP
является описание обратного пути к источнику мультикастинг-дей-
тограмм. Протоколы состояния канала предполагают широковеща-
тельную рассылку информации о членстве в группе. При получений
мультикаст-пакета маршрутизатор определяет дерево кратчайших
маршрутов.
Сети передачи данных. Метод доступа
477
DVMRP-дейтограмма состоит из небольшого заголовка фикси-
рованного размера и длинного списка записей. Заголовок DVMRP-
сообщений имеет формат IGMP (рис. 4.4.6.4.1):
0 4 8 16 31
Версия Тип Субтип Контрольная сумма
Рис. 4.4.6.4.Л Формат заголовка DVMRP-сообщений
Поле версия равно 1. Поле тип содержит всегда код 3. А поле
субтип может принимать значения:
1 = Отклик; сообщение о маршрутах до некоторого (-ых) мес-
т(а) назначения.
2 = Запрос; поиск маршрутов до определенного места назначе-
ния.
3 = Сообщение о выходе из членов группы.
4 = Отмена заявки о выходе из группы.
Контрольная сумма вычисляется также как и в других 1Р-прото-
колах. Отдельные записи в указанном списке выполняют роль ко-
манд и их размер должен быть кратен 16 бит (их границы соответ-
ствующим образом выравниваются). Максимальная длина DVMRP-
сообщения, включая заголовок, не может превышать 512 байт.
В настоящее время IETF установлены следующие значения TTL
и порогов при передаче видео- и аудио-информации по мультикас-
тинг-каналам. Колонка TTL содержит значение времени жизни IP-
пакета при его отправке для каждого из указанных приложений. В
колонке порог записано значение TTL, при котором пакет будет
пропущен дальше.
Таблица 4.4.6.4.1. Значения TTL для различных приложений
Вид мультикастинг-туннеля TTL Порог
JETF канал 1 GSM-аудио (~ 18кбит/с) 255 224
JETF канал 2 GSM-аудио 223 192
JETF канал 1 видео 127 96
JETF канал 2 видео 95 64
.Местное аудио 63 32
.Местное видео 31 1
Мультикастинг-дейтограмма с исходным TTL=64 доступна для
Достаточно обширной области, а мультикастинг-дейтограмма с ис-
ходным TTL=128 доступна для целого континента, дейтограмма же
478
Гпава 4
с исходным TTL=255 дойдет до любой точки сети Интернет. Поня-
тия «узкий регион» и «обширная область» достаточно неопреде-
ленные и будут уточняться позднее.
Маршрутные сообщения, посылаемые конкретному физическому ин-
терфейсу, также как и запросы подтверждения членства в мультикас-
тинг-группе должны иметь TTL=1. Цикл обмена маршрутной информа-
цией между мультикастинг- маршрутизаторами (FULLUPDATERATE)
равен 60 сек. Подтверждение членства в группе должно посылаться
каждые 120 сек (QUERY RATE). Если подтверждение не получено
в течение 2*QUERY_RATE+20 секунд, то членство в данной группе
аннулируется. Соседний мультикастинг-маршрутизатор считается
работающим при отсутствии подтверждений (UPDATE-сообщений)
в течение 4*FULL_UPDATE_RATE.
Описанные выше протоколы DVMRP и MOSPF имеют общий
недостаток — широко используют широковещательные режимы
рассылки пакетов и требуют каналов с высокой пропускной способ-
ностью. Они удобны для компактных групп (например, все члены
группа находятся в пределах одной автономной системы). Следует
заметить, что MOSPF может работать только в сетях, где активен
протокол OSPF. Для обслуживания более широких групп предло-
жен протокол PIM.
4.4. Б. 5. Протокольно-независимый мультикастинг (PIM)
Протокол PIM (Protocol Independent Multicast) призван решить
проблемы маршрутизации для произвольного числа и расположе-
ния членов группы и для произвольного числа отправителей ин-
формации. В настоящее время протокол не является стандартом.
Главным преимуществом данного протокола является эффек-
тивная поддержка работы «рассеянных» мультикастинг-групш Та-
кие группы могут включать не только членов из разных автоном-
ных систем, но и находящихся на разных континентах.
PIM базируется на традиционных маршрутных протоколах, кон-
кретно не связан ни с каким из них, им используются сформиро-
ванные этими протоколами маршрутные таблицы. Существует два
режима работы протокола — DM (для компактных групп) и SM
(Protocol Independent Multicast-Sparse Mode (PIM-SM)). Protocol
Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering,
M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, RFC-2117, June
1997) (для рассеянных групп). В режиме DM протокол PIM строит
дерево маршрутов аналогично DVMRP.
В режиме SM маршрутизаторы, имеющие членов мультикастинг-
группы, посылают сообщения о присоединении к дереву рассылки в
Сети передачи данных. Метод доступа
479
узлы, которые называются точками встречи (RP — Rendezvous
Point). Отправители используют RP для объявления о своем суще-
ствовании, а получатели, чтобы узнать о новых отправителях. В
качестве RP может использоваться любой маршрутизатор, поддер-
живающий протокол PIM.
Когда какой-то клиент хочет подключиться к некоторой группе,
ближайший к нему маршрутизатор посылает специальное сообщение
о включении в группу (PIM-joint) узлу, объявленному для данной
группы точкой встречи (RP). Число RP в сети может быть произ-
вольным. Узел RP пересылает сообщение о включении узлу-отпра-
вителю (или отправителям). Если маршрутизатор не-имеет информа-
ции о RP, включается схема, работающая для компактных групп.
При обработке сообщения о включении в группу промежуточные мар-
шрутизаторы формируют часть дерева мулЬтикастинг-маршрутов меж-
ду RP и получателем. При отправке мультикастинг-пакета соответ-
ствующий маршрутизатор посылает узлу RP регистрационное сооб-
щение (PIM-register), куда вкладывается информационный пакет. Если
используется несколько RP, отправитель должен посылать пакеты
всем RP. Получатель же должен быть подключен лишь к одному из
RP. В случае, когда сообщение о включении достигнет отправителя
раньше чем RP, подключение осуществляется, минуя RP. Если необ-
ходимо оптимизировать дерево доставки пакетов, маршрутизаторы-
получатели должны послать сообщение о включении самому отпра-
вителю. После этого дерево соединений видоизменяется. Некоторы-
ми узлами, если требуется, посылается сообщение об отключении.
Ниже приведен пример взаимодействия узлов при формировании де-
рева маршрутов в режиме SM-PIM (рис. 4.4.6.5:1).
Рис. 4.4.6.5.1. Иллюстрация реализации протокола мультикастинг
маршрутизации PIM
480
Гпава 4
Следует заметить, что большинство протоколов для маршрути-
зации мультимедийной информации формируют маршрут не от от-
правителя к получателю, а в обратном направлении. Это имеет под
собой веские причины. Дерево рассылки должно быть построено
так, чтобы поток отправителя как можно дольше не разветвлялся.
Желательно, чтобы разветвления происходили как можно ближе к
получателю. Это соображение проиллюстрировано на рис. 4.4.6.5.2.
На рисунке условно, в виде сетки маршрутизаторов показан фраг-
мент сети Интернет. Прямоугольником отмечен передатчик, а в ниж-
ней части кружочками приемники - члены группы. Маршруту от
передатчика к приемникам можно проложить индивидуально (вы-
делены жирным пунктиром), а можно и «коллективно». От пере-
датчика до маршрутизатора следует один поток для всех приемни-
ков. Такое решение приводит к минимизации сетевой загрузки, ведь
всем приемникам посылаются одни и те же пакеты. Чем позже их
пути разойдутся, тем лучше. Именно этот алгоритм и реализует
протокол PIM. Точки разветвления потоков на рис. 4.4.6.5.2 отме-
чены крестами (RP).
Получатель посылает PIM-joint пакет в RP, устанавливая канал
от RP до получателя. Из рисунка видно, что исходный маршрут D-
С-В-А длиннее оптимального D-B-A. Последний может быть реали-
зован после посылки PIM-joint команды от А к D.
При решении транспортных задач в мультимедиа чаще исполь-
зуется протокол UDP (малая избыточность и отсутствие подтверж-
дений).
Рис. 4.4.6.5.2.
Сети передачи данных. Метод доступа
481
Ниже приводится более подробное, хотя и неполное описание
протокола PIM.
Используемые сокращения и термины
Assert Сообщения Assert используются для принятия решения,
какой из параллельных маршрутизаторов, подключенных к
локальной сети с множественным доступом, должен быть
ответственным за ретрансляцию пакетов в LAN.
Bootstrap Сообщения, посылаемые от узла к узлу в пределах доме-
на. Все маршрутизаторы воспринимают эти сообщения для
получения RP-информации. За рассылку сообщений Bootstrap
в пределах домена ответственен маршрутизатор BSR.
BSR Bootstrap router - маршрутизатор, ответственный за рас-
сылку сообщений Bootstrap
C-RP Candidate RP - кандидат в маршрутизаторы RP
DR Designated Router - специально выделенный маршрутиза-
тор для рассылки мультикастинг данных.
(*,G) Wild card мультикастная запись для группы G
Graft Сообщение, используемое в режиме PIM для компактных групп.
Hello Соседние маршрутизаторы шлют друг другу сообщения
Hello. Маршрутизатор с наибольшим IP-адресом выбирает-
ся в качестве DR.
IGMP Internet Group Management Protocol - протокол управления
группами
iif Input interface - входной интерфейс
Join Подключение к дереву маршрутов
MBR Пограничный мультикастинг маршрутизатор
oif Output interface - выходной интерфейс
PMBR PIM Multicast Border Router — мультикастный погранич-
ный маршрутизатор PIM..
Prune Отключение от дерева маршрутов
Register Когда источник отправляет данные группе в первый
раз, его DR посылает уникастные сообщения Register, в
которые вкладывает информационные пакеты.
RP Rendezvous Point - маршрутизатор разветвления маршрута
для потока данных
(*,*,RP) Специальный тип маршрутных записей для поддержки
совместной работы DVMRP и PIM. Запись (*,*,RP) пред-
ставляет собой объединение всех групп, которые работают
через данную RP.
RPF Reverse Path Forwarding - переадресация по пути возврата
RPT RP-tree - дерево точек встречи
16 Зак. Ns 3430 Семенов
482
Гпава 4
(S,G) Маршрутная запись, характеризующее состояние системы
группа-отправитель (source-group)
SPT Shortest Pass Tree - дерево кратчайших маршрутов
SP Shortest Pass - кратчайший путь (обозначение фрагмента
дерева маршрутов)
WC Wild Card — универсальная подстановка.
Целью протокола PIM является построение дерева маршрутов
для рассылки мультикастных сообщений.
Маршрутизатор получает сообщения Join/Prune от соседних мар-
шрутизаторов, которые обслуживают группы пользователей. Он пере-
адресует информационные пакеты, адресованные группе G, только че-
рез те интерфейсы, через которые ранее было получено сообщение Join.
Специальный маршрутизатор DR (Designated Router) рассылает
периодически сообщения Join/Prune в точки встречи (RP) для каж-
дой группы, в которой имеются активные участники. Для описания
дерева маршрута используются маршрутные записи, содержащие адрес
отправителя, групповой адрес, номер входного интерфейса, через ко-
торый принимаются пакеты, список интерфейсов, через которые осу-
ществляется рассылка, таймеры, флаги и пр. Выходные интерфейсы
указывают на соседние маршрутизаторы, через которые пролегает
путь к RP. В центре этого маршрутного дерева, включающего в себя
всех членов группы, находится RP. Когда источник информации
посылает что-то группе в первый раз, его DR отправляет унщсастное
сообщение Register маршрутизатору RP.
Для того чтобы присоединиться к мультикатинг-группе G, ЭВМ
передает IGMP-сообщение (или ICMP в случае Ipv6). При этом
предполагается, что ЭВМ будет выполнять функции получателя (R).
Когда DR получает уведомление о членстве новой группы, он
просматривает соответствующие RP. DR формирует запись мульти-
кастинг-маршрута для группы (*,G) [Wild card мультикастная за-
пись для группы G, определяющая ее состояние]. Адрес RP включа-
ется в специальное поле маршрутной записи, содержащейся в пери-
одически рассылаемых сообщениях Join/Prune (см. рис. 4.4.6.5.9).
При этом в список выходных интерфейсов включается тот, к кото-
рому подключен новый член группы, а в качестве входного интер-
фейса указывается тот, через который посылаются уникастные па-
кеты к RP.
Когда не остается ни одного непосредственно подключенного
члена группы, протокол IGMP уведомляет об этом DR. Если DR не
имеет ни локальных, ни удаленных получателей, запись (*,G) лик-
видируется.
Сети передачи данных. Метод доступа
483
Запись (*,G), инициирует формирование маршрутизатором DR
сообщения Join/Prune с RP-адресом в его join-списке и установлен-
ными битами WC и RPT. Равенство WC =1 говорит о том, что
согласно этой записи будут пересылаться пакеты любого отправи-
теля. Список удаления (prune)'остается пустым. Когда бит RPT=1,
это указывает на то, что подключение осуществлено через общее
RP-дерево и, следовательно, сообщение Join/Prune будет идти по
этому RP-дереву. Когда бит WC= 1, это означает, что адрес принад-
лежит RP, а получатели предполагают получать пакеты от всех
отправителей.
Каждый маршрутизатор, расположенный по пути к отправите-
лю, создает и отслеживает изменения маршрутной записи для (*,G),
когда он получает сообщения Join/Prune с RPT=WC=1. Интерфейс,
через который получено сообщение Join/Prune, добавляется к спис-
ку выходных интерфейсов (oif) для (*,G). На основе этой записи
каждый маршрутизатор по пути между получателем и RP посыла-
ет сообщение Join/Prune, в которое RP включен в список join. Поле
данных этого пакета содержит мультикаст-адрес=С, Join=RP, WC-
бит, RPT-бит, Prune=NULL.
Когда ЭВМ начинает посылать мультикастинг-пакеты группе,
сначала DR должен доставить их в RP для последующей раздачи
по дереву. DR отправителя в начале инкапсулирует каждый инфор-
мационный пакет в сообщение Register (см. рис. 4.4.6.5.7) и от-
правляет его по уникастному адресу RP данной группы. RP извле-
кает каждое сообщение Register и переадресует вложенные инфор-
мационные пакеты вдоль RP-дерева.
Если поток данных позволяет использовать дерево кратчайшего
пути до отправителя (SPT — Shortest Pass Tree), RP может сформи-
ровать новую маршрутную запись для дерева мультикаст-маршрута,
специфичного для данного отправителя (SP-дерево).
DR отправителя прекратит инкапсуляцию информации в паке-
ты Registers, когда он получит сообщение Register-Stop от RP. RP
отравляет сообщения Register-Stop в качестве отклика на сообще-
ние Register, если RP не имеет более активных членов группы.
Новый приемник может подключиться к существующему RP-
Дереву, для которого установлено состояние обрезания (например,
из-за того, что другие получатели переключились на SP-деревья). В
этом случае состояние обрезания аннулируется с тем, чтобы обеспе-
чить доставку данных новому получателю.
В стабильном состоянии каждый маршрутизатор периодически
р°сЫлает сообщения Join/Prune для каждой маршрутной записи
Сообщения Join/Prune посылаются соседу, указанному в соот-
16»
484 Глава 4Ф
ветствующей записи. Такие сообщения позволяют отследить изме-
нения состояния системы и топологию членства в группе.
Для того чтобы получить информацию о RP, все маршрутизато-
ры в пределах PIM-домена собирают сообщения Bootstrap. Сообще-
ния Bootstrap пересылаются от узла к узлу в пределах домена. За
организацию рассылки этих сообщений несет ответственность спе-
циальный маршрутизатор BSR (bootstrap router). Сообщения
Bootstrap используются для выполнения динамического выбора BSR,
когда это необходимо, а также для получения информации об RP.
Домен в этом контексте представляет собой набор смежных марш-
рутизаторов, поддерживающих PIM, и сконфигурированных для со-
вместной работы в рамках границ, определенных пограничными мар-
шрутизаторами PMBR (PIM Multicast Border Router), соединяющи-
ми PIM-домен с остальным Интернет.
Маршрутизаторы используют набор доступных RP (называемый
{RP-Set}), для того чтобы осуществить связь отдельных групп с соот-
ветствующими RP. Некоторое число маршрутизаторов в домене кон-
фигурируется как кандидаты для выполнения функций BSR. Для
назначения BSR в домене существуют простые правила выбора. Часть
маршрутизаторов в домене конфигурируются также как кандидаты
для работы в качестве RP (С-RP); как правило, это те же маршрути-
заторы, что и кандидаты в BSR. Кандидат в RP периодически посы-
лает BSR домена уникастное сообщение Candidate-RP-Advertisement
(C-RP-Advs). C-RP-Advs включает в себя адрес С-RP, а также опци-
онный групповой адрес и поле длины маски. BSR включает набор
этих кандидатов в RP (набор RP), вместе с соответствующим группо-
вым префиксом периодически рассылаемых сообщений.
Маршрутизаторы получают и запоминают содержимое сообще-
ний Bootstrap. Когда DR получает указание о членстве в группе от
IGMP, DR использует хэш-функцию для установления соответствия
между групповым адресом и одним из С-RP, чей префикс включает
в себя данную группу. Для конкретной группы G, хэш-функция
использует только те С-RP, чьи групповые префиксы покрывают G.
Когда соответствие установлено, DR посылает сообщение Join/Prune
(или уникастный пакет Register) соответствующему RP.
Сообщения Bootstrap информирует о работоспособности точек
встречи (RP), обслуживающих сессию. Если RP включен в сообще-
ние, он считается рабочим, в то время как отсутствие RP в сообще-
нии, приводит к удалению его из списка, с которым работает алго-
ритм. Каждый маршрутизатор продолжает использовать содержи-
мое, полученное в последнем сообщении Bootstrap, пока не буДеТ
получено новое сообщение Bootstrap.
Сети передачи данных. Метод доступа
485
Если зона PIM-домена теряет доступ к старому BSR, производит-
ся выбор нового BSR, который разошлет RP-набор, содержащий RP,
доступные в пределах данной зоны. Любая область в любой задан-
ный момент времени обслуживается только одним BSR, который и
осуществляет посылку сообщений Bootstrap.
Для того чтобы обеспечить совместимость с сетями, работающи-
ми в режиме DM, с протоколами типа DVMRP, все пакеты, генериру-
емые в области PIM-SM, должны быть переправлены мультикаст-
ным пограничным маршрутизаторам области PMBR (Multicast
Border Router) и переадресованы в сеть DVMRP. Маршрутизатор
PMBR размещается на границе домена PIM-SM и взаимодействует
с другими типами мультикаст-маршрутизаторов, например, теми, ко-
торые поддерживают протокол DVMRP. Таким образом, PMBR дол-
жен поддерживать оба протокола. Для поддержки совместной рабо-
ты все маршрутизаторы должны поддерживать специальный тип
маршрутных записей, обозначаемых (*,*,RP).
Информационные пакеты, соответствуют записи (*,*,RP), если
нет никаких других записей, например, (S,G) или (*,G), а групповой
адрес места назначения пакета согласуется с RP, указанным в запи-
си (*,*,RP). В этом смысле запись (*,*,RP) представляет собой
объединение всех групп, которые работают через данную точку встречи
RP. PMBR инициализируют состояние (*,*,RP) для каждой RP в
каждом доменном наборе RP. Состояние (*,*,RP) заставляет PMBR
посылать сообщения (*,*,RP) Join/Prune каждой активной точке
встречи в домене. В результате деревья рассылки строятся так, что
передают все пакеты, возникающие в пределах PIM-домена (и рет-
ранслируются в точки встречи) в направлении пограничных марш-
рутизаторов PMBR.
PMBR осуществляют также доставку внешних пакетов маршру-,
тизаторам в пределах PIM-домена. Для решения этой задачи эти
маршрутизаторы инкапсулируют внешние пакеты, полученные че-
рез интерфейсы DVMRP, в сообщения Register, после чего уникаст-
ным образом переадресуют их в точку встречи RP Р1М-домена.
Сообщение Register имеет бит, указывающий на то, что пакет сфор-
мирован пограничным маршрутизатором.
Информационные пакеты обрабатываются также как и при дру-
гих мультикаст-схемах. Маршрутизатор сначала проверяет адреса
отправителя и группы. Затем определяется адрес RP, если непос-
редственная передача невозможна. Если пути доставки не суще-
ствует, пакет выбрасывается. При наличии пути выясняется интер-
фейс, через который должна производиться передача, и пакет пере-
ЭДресуется.
486
Гпава 4
Информационные пакеты никогда не вызывают обрезания вет-
вей маршрутного дерева. Однако информационные пакеты могут
запустить процессы, которые в конечном итоге приведут к такому
результату.
Когда имеется несколько маршрутизаторов, соединенных с се-
тью, имеющей много каналов доступа, один из них должен быть
выбран в качестве ретранслятора (DR; обычно это маршрутизатор с
наибольшим IP-адресом). Это справедливо для любой точки сети в
любое время. Процедуре выбора предшествует обмен сообщениями
Hello.
При наличии параллельных проходов к источнику или RP для
выбора маршрута применяются сообщения Assert. Используя сооб-
щения Assert, адресованные “224.0.0.13” (группа ALL-PIM-
ROUTERS) в локальной сети, вышестоящий маршрутизатор может
узнать, где осуществляется переадресация сообщений. Нижестоя-
щие маршрутизаторы, получая сообщения Assert, узнают, какой
маршрутизатор выбран в качестве ретранслятора, и куда следует
посылать сообщение Join. Обычно это тот же нижележащий марш-
рутизатор-сосед (Reverse Path Forwarding), но иногда это может быть
и не так, например, когда в локальной сети используется несколько
протоколов уникаст маршрутизации. RPF-сосед для конкретного
отправителя или RP является следующим маршрутизатором, кото-
рому переправляются пакеты по пути к отправителю или RP. По
этой причине он может рассматриваться как хорошая промежуточ-
ная инстанция для пересылки пакетов отправителем.
Когда приходит пакет в выходной интерфейс, маршрутизатор
посылает сообщение Assert в локальную сеть с множественным до-
ступом, указывая, какую метрику он использует для достижения
отправителя информационных пакетов. Маршрутизатор с наимень-
шим значением метрики и станет базовым ретранслятором. Все
прочие вышестоящие маршрутизаторы вычеркнут этот интерфейс
из своего списка выходных интерфейсов. Нижестоящие маршрути-
заторы также производят сравнение, если ретранслятором не явля-
ется RPF-сосед.
С понятием метрики связано и значение предпочтения метрики.
Оно введено, чтобы решать проблемы в случае, когда вышестоящие
маршрутизаторы использует другие уникастные протоколы марш-
рутизации. Численно меньшее значение предпочтения соответству-
ет более высокому приоритету. Значение предпочтения рассматри-
вается в качестве старшей части метрики при сравнении, которое
осуществляется при обработке сообщений Assert. Предпочтение мо-
жет быть присвоено уникастному протоколу маршрутизации и дол-
СеТИ передачи данных. Метод доступа
487
ясно быть взаимосогласованным для всех маршрутизаторов локаль-
ной сети с множественным доступом.
Сообщения Assert нужны для маршрутных записей (*,G), так
как для деревьев RP и SP некоторых групп в сетях с множествен-
ным доступом могут возникать зоны перекрытия. Когда Assert
посылается для записи (*,G), RPT-бит устанавливается равным 1.
Первый бит поля предпочтения всегда устанавливается равным 1,
для того чтобы отметить, что проход соответствует RP-дереву. RPT-
бит всегда обнуляется для предпочтения, которое относится к запи-
сям SP-деревьев. Это приводит к тому, что проход через SP-дерево
выглядит всегда предпочтительнее, чем проход через RP-дерево. Когда
деревья SP и RP перекрываются для какой-то LAN, этот механизм
устраняет дублирование для данной сети.
DR может уступить процесс (*,G) Assert другому маршрутизато-
ру LAN, если существует несколько проходов к RP через LAN. В
этом случае DR не является более «ближайшим» маршрутизато-
ром для местных получателей и он удаляет LAN из своего (*,G)
списка выходных интерфейсов. Маршрутизатор-победитель стано-
вится «ближайшим» и ответственным за рассылку сообщений (*,G)
Join для RP.
Подавление Join/Prune может использоваться в локальных се-
тях с множественным доступом, для того чтобы сократить число
дублирующих сообщений управления. Для нормальной работы про-
токола этого не требуется. Если получено сообщение Join/Prune,
которое соответствует существующим маршрутным записям (S,G),
(*,G) или (*,*,RP) для данного входного интерфейса, а поле Holdtime
сообщения Join/Prune больше, чем Join/Prune-Holdtime получате-
ля, может быть запущен таймер Join/Prune-Suppression маршрут-
ной записи получателя с тем, чтобы заблокировать последующие
сообщения Join/Prune. После завершения работы таймера получа-
тель отправляет сообщение Join/Prune, и возобновляет периодичес-
кую посылку Join/Prune, для данной записи. Таймер Join/Prune-
Suppression должен перезапускаться каждый раз, когда приходит
сообщение Join/Prune с большим значением Holdtime.
Когда уникастная маршрутизация претерпевает изменения, RPF
производит проверку активных маршрутных записей (S,G), (*,G) и
(*,*,RP) и вносит необходимые поправки. Входной интерфейс мо-
жет быть добавлен в список выходных интерфейсов с помощью
последующих сообщений Join/Prune, поступающих от нижестоя-
щих узлов. Сообщения Join/Prune, полученные текущим входным
Интерфейсом, игнорируются, а сообщения, полученные новыми или
существующими выходными интерфейсами, обрабатываются. Осталь-
488
Гпава 4
ные выходные интерфейсы останутся в прежнем состоянии до тех
пор, пока не будут отключены нижележащими маршрутизаторами
или по таймауту из-за отсутствия соответствующих сообщений Join/
Prune. Если маршрутизатор имеет запись (S,G) с установленным
битом SPT, а обновленная запись iif(S,G) не отличается от iif(*,G)
или iif(*,*,RP), тогда маршрутизатор переводит бит SPT в нулевое
состояние.
Соседи-маршрутизаторы, поддерживающие протокол PIM, перио-
дически обмениваются сообщениями Hello (см. рис. 4.4.6.5.6). Со-
общения Hello могут также рассылаться мультикастным образом с
использованием адреса 224.0.0.13 (группа ALL-PIM-ROUTERS).
Пакет содержит значение Holdtime (время сохранения информации).
Когда маршрутизатор получает сообщение Hello, он запоминает
IP-адрес соседа, устанавливает таймер отправки на время, соответ-
ствующее Holdtime, заключенное в Hello, и определяет выделенный
маршрутизатор (DR) для данного интерфейса. В качестве DR выби-
рается объект с наибольшим IP.
Когда маршрутизатор, который является активным DR, получа-
ет Hello от нового соседа (например, от IP-адреса, которого нет в
таблице DR), DR уникастным образом передает RP-информацию
новому соседу.
PIM-соседй, от которых в течение определенного времени не по-
ступало сообщений Hello, считаются отключившимися. Если DR
отключился, выбирается новый DR из числа соседей с наибольшим
IP-адресом.
Сообщения Join/Prune служат* для того чтобы подключить или
удалить ветвь мультикастинг-дерева рассылки. Сообщение содер-
жит как join-, так и prune-списки, любой из них может иметь нуле-
вую длину. Эти сообщения содержат все подключенные и отсоеди-
ненные источники данных, достижимые через данный узел адресат
сообщения. Период отправки сообщений Join/Prune определяется
значением [Join/Prune-Period].
Маршрутизатор периодически посылает сообщения Join/Prune
каждому конкретному RPF-соседу, соответствующему каждой мар-
шрутной записи (S,G), (*,G) и (*,*,RP). Сообщения Join/Prune пол
сылаются только тогда, когда RPF-сосед является Р1М-соседом.
Кроме периодически рассылаемых сообщений некоторые из Join/
Prune пакетов могут генерироваться как следствие следующих со-
бытий:
а. Создана новая маршрутная запись или
Ь. Список выходных интерфейсов изменился из нулевого в нену-
левое состояние или наоборот.
Сети передачи данных. Метод доступа
489
Может так случиться, что размер сообщения Join/Prune превы-
сит MTU сети. В этом случае сообщение может быть фрагментиро-
вано, информация, относящаяся к различным группам, будет посла-
на в разных пакетах. Однако если сообщение Join/Prune должно
быть фрагментировано, полный prune-список, соответствующий группе
G, должен быть включен в одно сообщение Join/Prune согласно RP-
дереву Join для G. Если такая семантическая фрагментация невоз-
можна, при транспортировке пакетов от соседа к соседу должна
использоваться 1Р-фрагментация.
Для любой новой записи (S,G), (*,G) или (*,*,RP), сформирован-
ной входящим сообщение Join/Prune, бит SPT сбрасывается.
Если запись имеет таймер Join/Prune-Suppression и полученное
сообщение Join/Prune не указывает на маршрутизатор в качестве
места назначения, тогда принимающий маршрутизатор просматри-
вает join- и prune-списки, с тем чтобы выяснить, нет ли там адресов
полностью соответствующих существующим состояниям (S,G), (*,G)
или (*,*,RP), для которых принимающий маршрутизатор осуществ-
ляет рассылку сообщений Join/Prune. Элемент join- или prune-
списка полностью соответствует маршрутной записи, только тогда,
когда их IP-адреса и RPT-флаги равны. Если приходящее сообще-
ние Join/Prune полностью соответствует существующим записям
(S,G), (*,G) или (*,*,RP), а сообщение Join/Prune приходит на вход-
ной интерфейс для данной записи, маршрутизатор сравнивает Holdtime
сообщения со своим собственным значением Join/Prune-Holdtime.
Если его значение Join/Prune-Holdtime меньше, запускается таймер
Join/Prune-Suppression. Если Join/Prune-Holdtime равно Holdtime
сообщения, коллизия разрешается в пользу отправителя сообщения
Join/Prune, который имеет больший IP-адрес. Когда время Join/
Prune таймера истекает, маршрутизатор отправляет сообщение Join/
Prune для соответствующей маршрутной записи.
Когда отправитель начинает отправку данных группе, его паке-
ты инкапсулируются в сообщения Register и посылаются в RP.
Если скорость передачи гарантируется каналом, RP устанавливает
соответствующее состояние для отправителя и начинает посылать
сообщения (S,G) Join/Prune отправителю с S в join-списке.
Когда DR получает сообщение Register-Stop, он перезапускает
таймер Register-Suppression в соответствующей записи (S,G) на
Register-Suppression-Timeout секунд. Если имеются данные, кото-
рые должны быть зарегистрированы, DR может послать RP сообще-
ние Register нулевой длины, за Probe-Time секунд до истечения вре-
мени таймера Register- Suppression.
490
Гпава 4
Сообщения Assert используются для принятия решения, какой
из параллельных маршрутизаторов, подключенных к локальной сети
с множественным доступом, должен быть ответственным за ретран-
сляцию пакетов в LAN.
Все управляющие сообщения PIM имеют номер протокола 103.
Сообщения PIM являются либо уникастными (например, Registers
и Register-Stop), либо мультикастными для группы “ALL-PIM-
ROUTERS” “224.0.0.13” (например, Join/Prune, Asserts, и т.д.). Фор-
мат заголовка пакета протокола PIM показан на рис. 4.4.6.5.3.
0 4 8 16 31
PIM Ver Тип Длина адреса Контрольная сумма
Рис. 4.4.6.5.3. Формат заголовка сообщения PIM
Поле PIM Ver - версия протокола (в настоящее время == 2).
Поле шип характеризует PIM-сообщение. Возможные значения поля
тип представлены в таблице 4.4.6.5.1.
Таблица 4.4.6.5.1. Коды типа сообщений
Код поля тип Тип сообщения PIM
0 Hello
1 Register
2 Register-Stop
3 Join/Prune
4 Bootstrap
5 Assert
6 Graft (используется только в PIM-DM)
7 Graft-Ack (используется только в PIM-DM)
8 Candidate-RP-Advertisement
Поле длина адреса характеризует длину кода адреса в байтах.
Поле контрольная сумма вычисляется методом суммирования все-
го PIM-сообщения по модулю 1, это поле имеет длину 16 бит. Фор-
мат закодированного группового адреса показан на рис. 4.4.6.5.4.
0 4 8 16 31
Резерв Длина маски Групповой мультикаст адрес....
...Групповой мультикаст адрес....
Рис. 4.4.6.5.4. Формат закодированного группового адреса
Сети передачи данных. Метод доступа 491
Поле длина маски имеет 8 бит. Значение поля определяет число
последовательных бит, выровненных по левому краю, которые зада-
ют адрес. Маска равна или меньше длины адреса * 8 (то есть 32
бита для IPv4 и 128 для IPv6). Поле групповой мулъпгикастп- адрес
содержит адрес группы и имеет число байт, равное указанному в
поле длина адреса. Формат кодированного адреса отправителя по-
казан на рис. 4.4.6.5.5.
0 4 8 16 31
Резерв S W R Длина маски Адрес отправителя ....
Адрес отправителя .’...
Рис. 4.4.6.5.5. Форматкодированного адреса отправителя
Поле бит S (бит рассеянности) содержит 1 для PIM-SM. Этот
бит используется для обеспечения совместимости с PIM v.l.
Поле W (бит WC). Бит WC =1, если подключение (join) или
удаление (prune) используются для маршрутной записи (*,G) или
(*,*,RP). Если WC=0, join или prune используются для маршрутной
записи (S,G), где S - адрес отправителя. Сообщения Join и Prune,
посылаемые в RP, должны иметь этот бит равным 1.
Поле R (бит RPT). Бит RPT=1, если информация о (S,G) посла-
на в RP. Если RPT=0, информация должна быть послана S, где S -
адрес отправителя.
Поле длина маски имеет 8 бит. Значение этого поля охаракте-
ризовано выше в комментарии к рисунку 4.4.6.5.4.
Поле адрес отправителя имеет длину, определяемую полем за-
головка длина адреса. Для IPv4, она равна 4 октетам. Формат сооб-
щения Hello показан на рис. 4.4.6.5.6.
0 4 8 16 31
PIM Ver Тип Длина адр. Контрольная сумма
Option Туре Option Length
OptionValue
OptionType OptionLength
OptionValue
Рис. 4.4.6.5.6. Формат сообщения Hello
492
Гпава 4
Первые два байта представляют собой заголовок Р1М-сообщения.
Поле OptionType определяет тип опции, значение которой задано в
поле OptionValue. Поле OptionLength задает длину поля OptionValue
в байтах. Поле OptionValue имеет переменную длину и содержит зна-
чение опции. Поле опция может содержать следующие значения:
OptionType == 1; OptionLength = 2; OptionValue = Holdtime, где
Holdtime равно времени в секундах, в течение которого получатель
должен сохранять доступность к соседу. Если Holdtime установлено
равным “Oxffff”, получатель этого сообщения никогда не прервет
соединение с соседом по таймауту. Это может использоваться для
каналов ISDN, для того чтобы избежать поддержания канала пу- *
тем периодической посылки сообщений Hello. Более того, если
Holdtime= 0, информация объявляется устаревшей немедленно. Ди-
апазон значений OptionType 2-16 зарезервирован на будущее. Со-
общение Register посылается DR или PMBR в RP, когда необходимо ,
передать мультикаст-пакет по RP-дереву. IP-адрес отправителя при Ч
этом равен адресу DR, а адрес места назначения - адресу RP. Фор-
мат сообщения Register показан на рис. 4.4.6.5.7. Постоянная часть
заголовка здесь идентична, показанной на рис. 4.4.6.5.3.
0 4 . 8 16 31
PIM Ver Тип Длина адр. Контрольная сумма
В N Зарезервировано
Информационный мультикаст-пакет
Рис. 4.4.6.5.7. Формат сообщения Register
Поле В - (бит Border) пограничный бит. В=1, если маршрутиза-
тор непосредственно соединен с отправителем. Поле N - бит нулево-
го регистра. N устанавливается DR равным 1 при тестировании RP '
до истечения времени регистрации (Register-Suppression Timer). Поле
информационный мультикаст-пакет представляет собой оригиналь-
ное сообщение, посланное отправителем.
Сообщение Register-Stop является уникастным, направляемым
от RP к отправителю сообщения Register. IP-адрес отправителя яв-
ляется адресом, к которому направлялось сообщение регистрации.
IP-адрес места назначения равен адресу отправителя сообщения
Register. Формат сообщения Register-Stop показан на рис. 4.4.6.5.8.
Сети передачи данных. Метод доступа 493
О 4 8 16 31
PIM Ver Тип Длина адреса Контрольная сумма
Закодированный групповой адрес
Уникастный адрес отправителя
Рис. 4.4.6.5.8. Формат сообщения Register-Stop
Поле закодированный групповой адрес имеет тот же смысл, что
и на рис. 4.4.6.5.4. Для сообщений Register-Stop поле длины мас-
ки содержит длину адреса * 8 (32 для IPv4), если сообщение посла-
но для одной группы.
Поле уникастный адрес отправителя представляет собой IP-ад-
рес ЭВМ отправителя из мультикастного информационного пакета.
Длина этого поля в байтах задано полем длина адреса. Значение
(0.0.0.0) может быть использовано для обозначения любого адреса.
Сообщение Join/Prune посылается маршрутизаторами в направ-
лении вышестоящих отправителей и RP. Сообщения Join служит
для построения совместно используемых маршрутных деревьев (RP-
деревьев) или деревьев отправителей (SPT). Сообщения Prune посы-
лаются для отключения ветвей отправителей, когда участники поки-
дают группу, а также для отправителей, которые не используют об-
щее дерево. Формат сообщения Join/Prune показан на рис. 4.4.6.5.9.
Поле адрес вышестоящего соседа представляет собой IP-адрес
RPF или вышестоящего соседа. Поле Holdtime характеризует время
в секундах, в течение которого получатель должен поддерживать
активное состояние Join/Prune. Если Holdtime сделано равным
“Oxffff”, получатель сообщения отключает таймаут для данного
выходного интерфейса. Если Holdtime сделано равным “0”, таймаут
происходит немедленно. Поле число групп равно количеству муль-
тикаст-групп, содержащихся в сообщении.
Поле закодированный мультикастный групповой адрес имеет
формат, показанный на рис. 4.4.6.5.4. Произвольная группа (wildcard)
(*,\RP) характеризуется адресом 224.0.0.0 и “4” в поле длина мас-
ки. Подключение (*,*,RP) имеет биты WC и RPT равные 1.
Поле число подключенных отправителей равно количеству ад-
ресов подключенных отправителей для данной группы. Поля адрес
п°дключенного отправителя — 1 ... п представляют собой список
^правителей, которым посылающий маршрутизатор переправляет
мУльтикастные дейтограммы при получении их через интерфейс, на
к°торый пришло данное сообщение. Формат полей кодированного
^Реса отправителя следует описанию на рис. 4.4.6.5.5.
494 Гпава 4 i
0 4 8 16 31
PIM Ver Тип Длина адреса Контрольная сумма
Уникастный адрес вышестоящего соседа
Резерв Номера групп HoldTime
Закодированный мультикастный групповой адрес-1
Число подключенных отправителей Число отключенных отправителей
Закодированный адрес подключенного отправителя - 1
Закодированный адрес подключенного отправителя - п
Закодированный адрес отключенного отправителя - 1
Закодированный адрес отключенного отправителя - п
Число подключенных отправителей Число отключенных отправителей
Закодированный адрес подключенного отправителя - 1
Закодированный адрес подключенного отправителя - п
Закодированный адрес отключенного отправителя - 1
Закодированный адрес отключенного отправителя - п
Рис. 4.4.6.5.9. Формат сообщения Join/Prune
Сообщения Bootstrap пересылаются мультикастным способом
группе UALL-PIM-ROUTERS”, через все интерфейсы, имеющие PIM-
соседей (за исключением того, через который получено сообщение).
Сообщения Bootstrap генерируются в BSR и посылаются с TTL®!*
Формат сообщения Bootstrap показан на рис. 4.4.6.5.10.
Сообщение Bootstrap делится на семантические фрагменты, если
исходное сообщение превосходит предельный размер пакета. Фор'
мат этих фрагментов представлен ниже (см. также рис. 4.4.6.5.Ю)*
Поле метка фрагмента является случайным числом и слу-
жит для идентификации фрагментов принадлежащих одному и тоМУ
Сети передачи данных. Метод доступа
495
О 4 8 16 24 31
PIMVer Тип Длина адреса Контрольная сумма
Метка фрагмента Длина хэш маски BSR-приоритет
Уникастный BSR-адрес
Закодированный групповой адрес-1
Число RP-1 Frag RP-Cnt-1 Зарезервировано
Уникастный RP-адрес-1
RP1-Holdtime Уникаст-
RP-адрес -2 RP2-Holdtime
Уникастный RP-адрес- m
RPm-Holdtime Закодированный-
Групповой адрес - 2
Закодированный групповой адрес-п
Число RP-m Frag RP-Cnt-m Зарезервировано
Уникастный RP-адрес-1
RP1-Holdtime Уникаст-
RP-адрес -2 RP2-Holdtime
Уникастный RP-адрес- m
RPm-Holdtime
Рис. 4.4.6.5.10. Формат сообщения Bootstrap
Же сообщению. Фрагменты одного и того же сообщения имеют иден-
тичные метки фрагмента. Поле длина хэш-маски - это длина мас-
ки хэш функции в битах. Для IPv4 рекомендуется значение 30, а
Для IPv6 — 126. Поле BSR-npuopumem содержит значение BSR-
пРиоритета для включенного BSR. Это поле рассматривается как
старший байт при сравнении BSR-адресов. Поле уникастный BSR-
адрес является IP-адресом маршрутизатора (bootstrap) домена. Раз-
МеР этого поля в байтах специфицирован в поле длина адреса. Поля
496
Гпава 4
закодированный групповой адрес -1...П является групповым пре-
фиксом (адрес и маска), с которым ассоциируются кандидаты RP.
Поля число RP -1...п равны числу адресов кандидатов RP, включен-
ных в сообщение Bootstrap для соответствующего группового пре-
фикса. Маршрутизатор не замещает старый RP-набор для данного
группового префикса до тех пор, пока не получит новое число RP-
адресов для этого префикса. Адреса могут содержаться в несколь-
ких фрагментах. Если получена только часть RP-набора для данно-
го префикса, маршрутизатор эту часть выбрасывает, не изменяя RP-
набора. Поля Frag RP-Cnt-l.,.m представляет собой число адресов
кандидатов RP, включенных в этот фрагмент сообщения Bootstrap,
для соответствующего группового префикса. Поле Frag RP-Cnt
облегчает разбор RP-набора для данного группового префикса, ког-
да он размещается в более чем одном фрагменте. Поля уникаст-
ные RP-адреса -1...т представляют собой адреса кандидатов RP,
для соответствующего группового префикса. Длина поля в байтах
специфицировано полем длина адреса. Поля RPl...m-Holdtime ха-
рактеризуют значения Hold time для соответствующих RP. Это поле
копируется из поля “Holdtime” RP, записанного в BSR.
Сообщение Assert посылается, когда мультикастный пакет по-
лучен выходным интерфейсом, соответствующим (S,G) или (*,G).
Формат такого сообщения представлен на рис. 4.4.6.5.11.
0 4 8 16 31
PIM Ver Тип Длина адреса Контрольная сумма
Закодированный групповой адрес
Уникастный адрес отправителя
R Предпочтение
Метрика
Рис. 4.4.6.5.11. Формат сообщения Assert
Поле закодированный групповой адрес характеризует групповой
адрес места назначения пакетов, который явился причиной посылки
сообщения Assert. Поле уникастный адрес отправителя содержит
IP-адрес отправителя из дейтограммы, вызвавшей посылку мульти*
кастного пакета Assert. Длина поля в байтах определена полем
длины адреса. Поле R представляет собой RPT-бит. Если IP муль-
тикастинг-дейтограмма, вызвавшая посылку пакета Assert направ-
ляется вниз по RP-дереву, тогда RPT-бит равен 1. Если маршрут^
Сети передачи данных. Метод доступа 49 7
зация осуществляется вдоль SPT, бит равен 0. Поле предпочтение
несет в себе значения кода предпочтения, присвоенного уникастно-
Му протоколу маршрутизации, который организует проход до ЭВМ.
Поле метрика содержит значение метрики для таблицы маршрути-
зации. Единицы измерения должны соответствовать требованиям
маршРУтного протокола.
Сообщения кандидата RP посылаются периодически С-RP и
уникастно адресуются к BSR. Формат таких сообщений показан на
рис. 4.4.6.5.12.
0 4 8 16 31
PIM Ver Тип Длина адреса Контрольная сумма
# префиксов А Резерв Holdtime
Уникастный RP-адрес
Закодированный групповой адрес -1
Закодированный групповой адрес - п
Рис. 4.4.6.5.12. Формат сообщения кандидата RP (C-RPJ
Поле # префиксов (Prefix-Cnt) содержит количество кодирован-
ных групповых адресов, включенных в сообщение. Они указывают
групповые префиксы, для которых производится С-RP оповещение.
Значение поля Prefix-Cnt = “0” предполагает использование пре-
фикса 224.0.0.0 с длиной маски 4, что означает — все мультикаст-
ные группы. Если С-RP не снабжен информацией о групповом пре-
фиксе, С-RP заносит в поле значение по умолчанию равное “0”.
Поле А характеризует бит указания. Этот бит указывает, что BSR
не должен переписывать информацию о групповых префиксах, при-
веденную в С-RP оповещении. В большинстве случаев С-RP уста-
навливает этот бит, равным 0. Поле Holdtime содержит значение
времени, в течение которого оповещение корректно. Это поле позво-
ляет определить время, когда оповещение устареет. Поле уникаст-
Ный RP-adpec представляет собой адрес интерфейса, который объяв-
ляется кандидатом в RP. Длина этого поля в байтах определена
полем длина адреса. Поле закодированный групповой адрес -1..п
является групповым префиксом, для которого производится уве-
домление кандидатом в RP.
498
Глава 4
Литература
1 Deering, S., D.Estrin, D.Farinacci, V. Jacobson, C.Liu, L.Wei, P.Sharma,
and A.Helmy. Protocol independent multicast (pim) : Motivation and
architecture. Work in Progress.
2 Deering, S., D.Estrin, D.Farinacci, V.Jacobson, C.Liu, and L.Wei. The
pim architecture for wide-area multicast routing. ACM Transactions
on Networks, April 1996.
3 Estrin, D., D.Farinacci, V.Jacobson, C.Liu, L.Wei, P.Sharma, and
A.Helmy. Protocol independent multicast-dense mode (pim-dm):
Protocol specification. Work in Progress.
4 Deering,S. Host extensions for ip multicasting,Aug 1989. RFC1112.
5 Fenner, W. Internet group management protocol, version 2. Work in
Progress.
6 Atkinson, R. Security architecture for the internet protocol, August
1995. RFC-1825.
7 Ballardie, A.J., P.F. Francis, and J.Crowcroft. Core based trees. In
Proceedings of the ACM SIGCOMM, San Francisco, 1993.
4.4. 6. 6. Протокол резервирования ресурсов RSVP
(Resource ReSerVation Protocol]
Протокол RSVP (L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S.
Jamin «Resource ReSerVation Protocol», RFC-2205) используется ЭВМ
для того, чтобы запросить для приложения определенный уровень
качества сетевых услуг QoS (Quality of Service, например, определен-
ный уровень полосы пропускания). RSVP используется также марш-
рутизаторами для доставки QOS-запросов всем узлам вдоль пути
информационного потока, а также для установки и поддержания не-
обходимого уровня услуг. RSVP-запросы обеспечивают резервирова-
ние определенных сетевых ресурсов, которые нужны, чтобы обеспе-
чить конкретный уровень QOS вдоль всего маршрута транспортиров-
ки данных. Учитывая стремительное внедрение мультимедийных
приложений в Интернет, в частности IP-телефонии, нетрудно предпо-
ложить, что этот протокол найдет самое широкое применение.
RSVP запрашивает ресурсы только для одного из направлений
трафика и только по указанию получателя. RSVP работает поверх
IPv4 или IPv6. Протокол относится к числу управляющих, а^не
транспортных.
RSVP предназначен для работы с существующими и будущими
маршрутными протоколами, управляющими как обычными, так и
мультикастными потоками. В последнем случае ЭВМ сначала по-
сылает IGMP-запрос, для того чтобы подключиться к мультикас-
тинг-группе, а затем уже RSVP-сообщение для резервирования ре-
сурсов по маршруту доставки.
Сети передачи данных. Метод доступа
499
Механизм обеспечения QOS включает в себя классификацию
пакетов, административный контроль и диспетчеризацию. Класси-
фикатор пакетов определяет QoS класс (а иногда и маршрут движе-
ния) для каждого пакета. В процессе реализации резервирования
RSVP-запрос проходит два местных управляющих модуля: «конт-
роль доступа» и «управление политикой». Контроль доступа опре-
деляет, имеет ли узел достаточно ресурсов для удовлетворения по-
ступившей заявки. Управление политикой определяет, имеет ли
пользователь административное разрешение сделать данное резер-
вирование. Если обе проверки завершились успешно, параметры пе-
редаются классификатору пакетов и интерфейсу канального уровня
(диспетчеру пакетов). Если же какой-либо из тестов не прошел,
программа RSVP присылает прикладному процессу сообщение об
ошибке.
Структура и содержимое параметров QoS документировано в
спецификации RFC 2210. Так как число участников группы, а так-
же топология связей меняется со временем, структура RSVP пред-
полагает адаптацию ЭВМ и маршрутизаторов к этим изменениям.
Для этой цели RSVP периодически посылает сообщения для под-
держания необходимого состояния вдоль всего маршрута обмена.
При отсутствии этих сообщений происходит тайм-аут и резервиро-
вание аннулируется. Обобщая, можно сказать, что RSVP имеет сле-
дующие атрибуты:
• RSVP выполняет резервирование для уникастных и мульти-
кастных приложений, динамически адаптируясь к изменениям член-
ства в группе вдоль маршрута.
• RSVP является симплексным протоколом, т.е., он выполняет
резервирование для однонаправленного потока данных.
• RSVP ориентирован на получателя, т.е., получатель данных
инициирует и поддерживает резервирование ресурсов для потока.
• RSVP поддерживает динамическое членство в группе и авто-
матически адаптируется к изменениям маршрутов.
• RSVP не является маршрутным протоколом, но зависит от
существующих и будущих маршрутных протоколов.
• RSVP транспортирует и поддерживает параметры управления
трафиком и политикой, которые остаются непрозрачными для RSVP.
• RSVP обеспечивает несколько моделей резервирования или
стилей, для того чтобы удовлетворить требованиям различных при-
ложений.
• RSVP обеспечивает прозрачность операций для маршрутиза-
торов, которые его не поддерживают.
• RSVP может работать с IPv4 и IPv6.
500
Гпава 4
Подобно приложениям маршрутизации и протоколам управ-
ления, программы RSVP исполняется в фоновом режиме. Схема
работы процесса RSVP показана на рис. 4.4.6.6.1.
Рис. 4.4.6.6.7. RSVP в ЭВМ и маршрутизаторе
1. Потоки данных
RSVP определяет сессию как поток данных с определенным
местом назначения и заданным транспортным протоколом. Каж-
дая сессия является совершенно независимой.
Сессия RSVP описывается тремя параметрами: DestAddress,
ProtocolId/£, DstPort^. DestAddress - IP-адрес места назначения ин-
формационных пакетов (уникаст или мультикаст). Protocolld - иден-
тификатор IP протокола. Опционный параметр DstPort - обобщен-
ный порт места назначения, т.е., еще одна точка демультиплексиро-
вания на транспортном или прикладном уровне. DstPort может
быть определено полем порта места назначения UDP/TCP.
Заметим, что, строго говоря, не обязательно включать в описание
сессии DstPort, когда DestAddress является мультикастным, так как
различные сессии могут всегда иметь различные мультикаст-адреса.
Однако, DstPort необходим для того, чтобы разрешить более одной
уникаст-сессии для одной и той же ЭВМ-получателя.
Для уникастной передачи может быть один получатель, но мно-
го отправителей; RSVP может выполнить резервирование для пере- •
дачи много_точек -> одна_точка.
2. Модель резервирования
Простой запрос резервирования RSVP состоит из «flowspec» (спе-
цификация потока) и «filter spec» (спецификация фильтра); эта
Сети передачи данных. Метод доступа 501
комбинация называется «описателем потока». Спецификация
flowspec определяет желательное значение QoS. Спецификация филь-
тра в сочетании со спецификацией сессии определяют тип набора
пакетов. Спецификация flowspec используется для задания пара-
метров диспетчеров в узлах, через которые транспортируется поток,
а спецификация фильтра - для определения параметров классифи-
катора пакетов. Информационные пакеты, адресованные конкрет-
ной сессии, но не удовлетворяющие какой-либо спецификации филь-
тра обрабатываются без гарантий обеспечения оговоренного QOS.
Спецификация flowspec в запросе резервирования включает в
себя значение класса услуг и два набора параметров:
1. «Rspec», который определяет желательное значение QoS, и
2. «Tspec», который описывает информационный поток.
Форматы и содержимое Tspecs и Rspecs определяются общими
моделями обслуживания [RFC 2210] и обычно недоступны для RSVP.
Конкретный формат спецификации фильтра зависит от того, ис-
пользуется IPv4 или IPv6. Например, спецификация фильтра может
использоваться для выделения некоторых составных частей инфор-
мационного потока, осуществляя отбор с учетом полей пакетов при-
кладного уровня. В интересах упрощения в описываемом стандарте
RSVP спецификация фильтра имеет довольно ограниченную фор-
му: IP-адрес отправителя и, опционно, номер порта SrcPort (UDP/
TCP).
Так как номера портов UDP/TCP используются для классифи-
кации пакетов, каждый маршрутизатор должен уметь анализиро-
вать эти поля. Это вызывает потенциально три проблемы.
1. Необходимо избегать IP-фрагментации потока данных, для
которого желательно резервирование ресурсов. Документ [RFC 2210]
специфицирует процедуру вычисления минимального MTU для при-
ложений, использующих средства RSVP.
2. IPv6 вводит переменное число Internet заголовков переменной
Длины перед транспортным заголовком, увеличивая трудность и сто-
имость классификации пакетов. Эффективная классификация ин-
формационных пакетов IPv6 может быть достигнута путем исполь-
зования поля метки потока заголовка IPv6.
3. IP-уровень безопасности как для IPv4, так и IPv6 может шиф-
ровать весь транспортный заголовок, скрывая номера портов проме-
жуточных маршрутизаторов.
Сообщения RSVP, несущие запросы резервирования, исходят со
Ст°роны получателя и направляются отправителю информации. В
КаЖдом промежуточном узле запрос резервирования запускает две
пРоцедурЬ1:
502
Гпава 4
А. Резервирование канала
Процесс RSVP проходит стадии проверки допуска и политики.
Если какой-либо тест не прошел, резервирование отвергается и по-
сылается сообщение об ошибке. Если все тесты прошли успешно
узел устанавливает классификатор пакетов, для того чтобы отби-
рать пакеты, указанные в спецификации фильтра. Далее устанавли-
вается контакт с соответствующим канальным уровнем для полу-
чения желательного QoS, заданного в flowspec.
Для простой выделенной линии, желаемый QoS будет получен с
помощью диспетчера пакетов в драйвере канального уровня. Если
технология канального уровня поддерживает свои средства управ-
ления QoS, тогда RSVP должен согласовать с канальным уровнем
получение требуемого QoS.
Б. Переадресация запроса назад
Запрос резервирования посылается от получателя отправителю
(или отправителям) данных. Запрос резервирования, который пере-
адресуется узлом дальше может отличаться от того, который он
получил по двум причинам. Механизм управления трафиком мо-
дифицирует flowspec от узла к узлу. Что более важно, запросы ре-
зервирования, поступающие от получателей мультикастинг-дерева
должны объединяться по мере продвижения процесса резервирова-
ния в направлении отправителя данных.
Когда получатель данных отправляет запрос резервирования, он
может запросить также присылку сообщения, подтверждающего ре-
зервирование. Процесс резервирования распространяется от получа-
телей к отправителям, от узла к узлу. В каждом узле требования
резервирования объединяются и сопоставляются с имеющимися воз-
можностями. Это продолжается до тех пор, пока запрос не достиг-
нет отправителя или пока не возникнет конфликт перегрузки. В
результате получатель данных, направивший запрос резервирова-
ния, получит сообщение об успехе или ошибке.
Базовая модель резервирования RSVP является однопроходной**
получатель посылает запрос резервирования вдоль мультикастинг-
дерева отправителю данных и каждый узел по пути воспринимает
или отвергает этот запрос. RSVP поддерживает улучшенную версий
однопроходного варианта алгоритма, известного под названием OPWA
(One Pass With Advertising) [OPWA95]. С помощью OPWA управля-
ющие пакеты RSVP, посланные вдоль маршрута для сбора данных*
которые могут быть использованы для предсказания значения О0?
маршрута в целом. Результаты доставляются протоколом RSVP >
ЭВМ получателя. Эти данные могут позднее служить для динамичес-
кой адаптации соответствующих запросов резервирования.
Сети передачи данных. Метод доступа
503
3. Стили резервирования
Запрос резервирования включает в себя набор опций, которые в
совокупности называются стилем. Одна опция резервирования оп-
ределяет способ резервирования различными отправителями в пре-
делах одной сессии.
Другая опция резервирования контролирует выбор отправите-
лей. В одних случаях каждому отправителю ставится в соответ-
ствие определенная спецификация фильтра, в других - таких спе-
цификаций не требуется вовсе. В настоящее время определены сле-
дующие стили:
• Стиль WF (Wildcard-Filter)
Стиль WF использует опции: «разделенного» резервирования и
произвольного выбора отправителя («wildcard»). Таким образом,
резервация со стилем WF создает резервирование, которое делится
между потоками всех отправителей. Это резервирование может рас-
сматриваться как общая «труба», чей размер равен наибольшему из
ресурсных запросов от получателей, и не зависит от числа отправи-
телей. Стиль резервирования WF передается в направлений отпра-
вителей и автоматически распространяется на новых отправителей
при их появлении.
Символически можно представить запрос резервирования стиля
WF как:
WF( * {Q}),
где звездочка представляет произвольную подстановку при выборе
отправителя, a Q - спецификация flowspec
• Стиль FF (Fixed-Filter)
Стиль FF использует опции: «четкое» (distinct) резервирование
и «явный» (explicit) выбор отправителя. Таким образом, простой
запрос со стилем FF создает точно заданное резервирование для
информационных пакетов от определенного отправителя, без совме-
стного использования ресурса с другими отправителями в пределах
°Дной и той же сессии. Символически простой запрос резервирова-
ния FF можно представить как:
FF(S{Q}),
гДе S - выбранный отправитель, a Q - соответствующая специфика-
ция flowspec; эта пара параметров образуют дескриптор потока. RSVP
позволяет применение нескольких простых стилей резервирования FF
Одновременно, при этом формируется список дескрипторов потоков:
504
Гпава 4
FF(S1{Q1}, S2{Q2}, ...)
Полное резервирование в канале для данной сессии характеризуй
ется суммой QI, Q2, ... для всех отправителей, куда посланы запросы.
* Стиль SE (Shared Explicit)
Стиль SE использует опции: «разделенное» (shared) резервирова-
ние и «явный» (explicit) выбор отправителя. Таким образом, стиль
резервирования SE формирует одно резервирование, которое совместно
используется несколькими отправителями. В отличие от стиля WF, SE
позволяет получателю непосредственно специфицировать набор отпра-
вителей. Запрос резервирования SE, содержащий flowspec Q и список
отправителей SI, S2,..., можно представить в символьной форме как:
SE((S1,S2,...){Q} )
Разделенное резервирование, выполненное с применением сти-
лей WF и SE, пригодно для мультикастных приложений, где не-
сколько источников данных редко осуществляют передачу одновре-
менно. Пакетная передача голоса может служить примером разде-
ленного резервирования, так как лишь ограниченное число людей
говорят одновременно. Каждый получатель может направить зап-
рос резервирования WF или SE на удвоенную полосу пропускания,
необходимую одному отправителю, позволяя тем самым говорить
обоим партнерам одновременно. С другой стороны стиль FF, кото-
рый осуществляет четкое резервирование для потоков отдельных
отправителей, подходит для передачи видеосигналов.
Правила RSVP не позволяют объединять разделенные резерви-
рования с четкими резервированиями, так как эти модели абсолют-
но несовместимы. Не допускается также объединение явного и про-
извольного (wildcard) выбора отправителей, так как это может выз-
вать предоставление не заказанных услуг получателю, который указал
тип услуг явно. Таким образом, стили WF, SE и FF не совместимы*
Можно моделировать эффект WF резервирования, используя стиль
SE. Когда приложение запрашивает WF, процесс RSVP получателя
может использовать местный статус для выполнения эквивалент*
ного резервирования SE, которое в явном виде перечисляет всех
отправителей. Однако резервирование SE вынуждает классификатор
пакетов в каждом узле в явном виде выбрать каждого отправителя
из списка, в то время как WF позволяет классификатору пакетов
осуществить произвольный выбор отправителя и порта с помоЩЫ®
«wild card». Когда список отправителей велик, стиль резервиров*
ния WF обеспечивает значительно меньшие издержки, чем SE.
Сети передачи данных. Метод доступа 505
4. Примеры стилей
На рис. 4.4.6.6.2. показан пример маршрутизатора с двумя вход-
ными интерфейсами 1А и 1Б, через которые проходят входные потоки,
и двумя выходными интерфейсами 1в и 1г, через которые осуществ-
ляется переадресация входных потоков. Пусть существует три от-
правителя SI (S2 и S3), подключенные к интерфейсам 1А и 1Б, соот-
ветственно. Имеется три получателя R1 (R2 и R3), которые марш-
рутизированы через выходные интерфейсы 1в и 1г, соответственно.
Будем также предполагать, что интерфейс 1г подключен к широко-
вещательной сети, a R2 и R3 достижимы через разные маршрутиза-
торы, не показанные на рисунке.
Здесь нужно специфицировать мультикастные маршруты в пре-
делах узла, отображенного на рис. 4.4.6.6.2. Предположим снача-
ла, что информационные пакеты от каждого из отправителей S.,
показанных на рисунке, маршрутизованы на оба выходных интер-
фейса. При этих предположениях на рисунках 4.4.6.6.3, 4.4.6.6.4
и 4.4.6.6.5 проиллюстрированы стили резервирования WF, FF и SE,
соответственно.
Рис. 4.4.6.6.2. Конфигурация маршрутизатора
Для простоты эти примеры показывают flowspec как одномер-
ное кратное повторение некоторого базового качества ресурса В.
Колонка «Резервирует» показывает запросы резервирования RSVP,
полученные через выходные интерфейсы 1в и 1г, а колонка «Получа-
ет» показывает результирующее состояние резервирования для каж-
дого интерфейса. Колонка «Посылает» показывает запросы резер-
вирования, посланные предшествующим узлам (1А и 1Б). В колонке
«Резервирует» каждая рамка представляет один зарезервированный
виртуальный канал с соответствующим дескриптором потока. Ниж-
няя часть рис. 4.4.6.6.2 показывает еще одно предположение о
МаРШрутизации: информационные пакеты от S2 и S3 не переадре-
сУЮтся интерфейсу 1в, напр., из-за того, что сеть обеспечивает более
506
Гпава 4
короткий путь для пакетов отправителя к R1. Рис. 4.4.6.6.3 пока,
зывает пример резервирования WF именно при этом предположе-
нии (стрелками отмечены допустимые маршруты). Так как нет пут®
от 1Б к 1в, резервирование, переадресуемое интерфейсом 1Б, рассмат-
ривает требования только для интерфейса 1г.
Рис. 4.4.6.6.3, демонстрируя стиль WF, показывает две ситуд.
ции, в которых требуется объединение.
1. Каждый из двух узлов, следующих за интерфейсом 1г, посыла-
ют независимые запросы резервирования RSVP, эти два запроса дол-
жны быть объединены в одну спецификацию flowspec (ЗВ), которая
используется для выполнения резервирования в интерфейсе 1г.
2. Резервирования для интерфейсов 1в и 1г должны быть объеди-
нены, для того чтобы осуществить переадресацию запросов резерви-
рования далее и получить спецификацию flowspec (4В - большее из
ЗВ и 4В).
Посылает
WF(*{4B}) ------ 1а
1в
Резервирует
*{4В}
Получает
1в *—WF(*{4B})
WF(*{4B}) ----- 1б
1г
* {ЗВ}
1г ◄— WF(* 13В})
◄— WF(* {2В})
Рис. 4.4.6.6.3. Пример резервирования WF (Wildcard-Filter)
На рис. 4.4.6.6.4 проиллюстрирован стиль резервирования FF
(Fixed-Filter). Для каждого выходного интерфейса, имеется отдель-
ное резервирование для каждого запрошенного источника, но это
резервирование будет общим для всех получателей, которые посла-
ли запрос. Дескрипторы для получателей S2 и S3, полученные через
выходные интерфейсы 1в и 1г, вкладываются в пакеты запросов, на-
правляемых предыдущему узлу (1Б). С другой стороны, три различ-
ных дескриптора потоков, специфицирующих отправителя S1, об'ЬС*
диняются в один запрос FF(S1{4B}), который посылается предыДУ'
щему узлу (1А).
На рис. 4.4.6.6.5 показан пример стиля резервирования Sl>
Когда резервирования стиля SE объединяются, результирующая сне*
цификация фильтра является объединением исходных специфик*
ций, а результирующая спецификация flowspec равна наиболЫП
из flowspec.
Сети передачи данных. Метод доступа
507
Рис. 4.4.6.6.4. Припер резервирования FF (Fixed-Filter)
Посылает
SE(Sl{3B))-<----- 1а
Резервирует
(S1.S2)
{В}
Получает
1в SE ((S1,S2){B))
SE (S2, S3) {ЗВ)) <— 1б
(S1,S2,S3) Ir SE «SI-S3)I3B))
(ЗВ) SE(S2{2B))
Рис. 4.4.6.6.5. Пример резервирования SE (Shared-Explicit)
Приведенные примеры предполагают, что информационные па-
кеты от SI, S2 и S3 маршрутизируются, через оба выходных интер-
фейса.
5. Механизмы протокола RSVP
5.1. Сообщения RSVP
На рис. 4.4.6.6.6 проиллюстрирована модель RSVP узла марш-
рутизатора. Каждый поток данных приходит со стороны предше-
ствующего узла через соответствующий входной интерфейс и выхо-
Входные
Выходные
Узлы
следующ.
Узлы
предшеств.
Рис. 4.4.6.6.6. Маршрутизатор, использующий RSVP
508
Гпава 4
дит из маршрутизатора через один или несколько выходных интер.
фейсов. Один и тот же интерфейс для разных потоков в пределах
одной сессий может выполнять как входную, так и выходную роль.
Несколько предшествующих узлов и/или последующих узлов мо.
гут для коммуникаций использовать один и тот же физически^
интерфейс; например, на рисунке два узла Г и Г’ подключены к
широковещательной сети через интерфейс 1г. Существует два фу^.
даментальных типа сообщений RSVP: Resv и Path. Каждый полу-
чатель посылает свой запрос резервирования в виде сообщений (Resv)
отправителям данных. Эти сообщения должны двигаться в точное*
ти тем же маршрутом с учетом выбора отправителей, что и данные
только в противоположном направлении. Они создают и поддержи-
вают состояние резервирования в каждом узле вдоль маршрута.
Сообщения Resv должны быть, в конце концов, доставлены ЭВМ-
отправителям, таким образом, ЭВМ устанавливают параметры уп-
равления трафиком.
Каждая ЭВМ-отправитель передает RSVP сообщения «Path*
вдоль уникаст/мультикаст маршрутов, сформированных с помощью
маршрутных протоколов. Эти сообщения Path запоминают состоя-
ние пути в каждом узле вдоль маршрута. Это состояние пути вклю-
чает в себя уникастный IP-адрес предыдущего узла, который ис-
пользуется для маршрутизации сообщений Resv. Сообщение Path
содержит помимо этого следующую информацию:
• Шаблон отправителя
Сообщение Path должно нести в себе шаблон отправителя (Sender
Template), который описывает формат пакетов данных, посылаемых
отправителем. Этот шаблон имеет форму спецификации фильтра,
которая может использоваться для отделения пакетов данного от-
правителя от других пакетов в пределах сессии.
Шаблоны отправителя имеют тот же формат, что и специфика*
ции фильтра, которые используются в сообщениях Resv. Следов*
тельно, шаблон отправителя может специфицировать только его IP*
адрес и опционно UDP/TCP порт, с учетом идентификатора прото*
кола, заданного для сессии.
• Спецификация Tspec отправителя
Сообщения Path должны содержать спецификацию отправителя
Tspec, которая определяет характеристики информационного тр*
фика, формируемого отправителем. Спецификация Tspec использу*
ется для предотвращения избыточного резервирования.
• Спецификация Adspec
Сообщение Path может нести в себе пакет оповещения OPW**»
известный, как «Adspec». Пакет Adspec, полученный с сообщен#^
Сеги передачи данных. Метод доступа
509
path, передается системе управления трафиком, которая присылает
скорректированную версию Adspec. Последняя пересылается далее
в виде сообщения Path.
Сообщения Path посылаются с теми же адресами отправителя и
получателя, что и данные, так что они будут корректно маршрути-
зироваться даже через сетевые области, не поддерживающие RSVP.
С другой стороны, сообщения Resv посылаются от узла к узлу; каж-
дый узел, поддерживающий RSVP, переправляет сообщение Resv по
уникастному адресу предшествующего узла RSVP.
6. Объединение Flowspecs
Сообщение Resv, переадресованное предшествующему узлу, несет
в себе спецификацию flowspec, которая является «наибольшей» из
всех flowspec, запрошенных последующими узлами, которым будут
посылаться данные.
Так как flowspecs непрозрачны для RSVP, действительные пра-
вила для сравнения flowspecs должны быть определены и реализо-
ваны вне рамок этого протокола. Реализация RSVP потребует об-
ращения к специальной программе для выполнения объединения
спецификаций flowspec.
Заметим, что спецификации flowspecs представляют собой в об-
щем случае многомерные векторы; они могут содержать как Tspec,
так и Rspec компоненты, каждая из которых может сама быть мно-
гомерной. Например, если один запрос требует высокой пропускной
способности, а другой - жесткого ограничения задержек, один не
может быть «больше» другого. В таком случае, вместо взятия боль-
шего, прикладная программа объединения должна быть способна
сформировать такую спецификацию flowspec, которая по крайне мере
столь же велика, как и каждая из составляющих; математически
это наименьший верхний предел LUB (least upper bound). В некото-
рых случаях спецификация flowspec по крайне мере настолько мала
насколько возможно; это наибольший нижний предел GLB (Greatest
Lower Bound).
Для вычисления эффективного значения flowspec (Re, Те), ин-
сталлируемого в интерфейс, используются следующие шаги [RFC
2210]. Здесь Те - эффективная спецификация Tspec, a Re - эффек-
тивная спецификация Rspec.
1. Определяется эффективная спецификация flowspec для вы-
ходного интерфейса. В зависимости от технологии канального уровня
Может потребоваться объединение спецификаций flowspecs различ-
НЬ1Х последующих узлов. Это означает вычисление эффективной
Спецификации flowspec, как LUB flowspecs. Какие спецификации
510 Глава 4
следует объединять, определяется средой канального уровня, в то
время как процедура объединения определяется используемой моде-
лью обслуживания [RFC 2210]. В результате получается специфи-
кация flowspec, которая непрозрачна для RSVP, но в действительно-
сти состоит из пары (Re, ResvTe), где Re является эффективной
спецификацией Rspec, a Resv_Te - эффективная спецификация Tspec.
2. Производится вычисление спецификации PathTe, зависящей
от приложения и представляющей собой сумму всех Tspecs, которые
были присланы в сообщениях Path, пришедших от различных пред-
шествующих узлов (напр., некоторые или все узлы А, Б, и Б’ на рис.
4.4.6.6.6).
3. (Re, Resv_Te) и Path_Te передаются системе управления тра- .
фиком. Управление трафиком вычислит эффективную .специфика- ,
цию flowspec, как минимум PathTe и ResvTe.
7. Гибкое состояние
RSVP использует подход «soft state» (гибкое состояние) для
управления состоянием резервирования в маршрутизаторах и ЭВМ.
Гибкое состояние RSVP создается и периодически освежается по-,
средством сообщений Path и Resv. Состояние уничтожается, если
не приходит подтверждения в течение заданного времени тайм-аута
очистки. Состояние может быть стерто также посредством сообще-
ния «teardown» (уничтожение). По истечении каждого таймаута
обновления и после любых изменений RSVP сканирует свое состоя- >
ние, для того чтобы подготовить и отправить сообщения обновле-.
ния Path и Resv последующим узлам.
Сообщения Path и Resv практически эквивалентны. Когда мар-
шрут меняется, следующее сообщение Path инициализирует состоя-
ние прохода для нового маршрута, а последующие сообщения Resv
установят для него резервирование. Состояние же на неиспользо-
ванном в данный момент сегменте маршрута будет аннулировано
по таймауту. Следовательно, определение того, является ли сообще-
ние «новым» или «обновляющим» принимается отдельно для каж-
дого узла в зависимости от его текущего состояния.
Протокол RSVP посылает свои сообщения в виде 1Р-дейтог-
рамм без какого-либо улучшения надежности. Периодическая пе-
редача сообщений обновления от ЭВМ и маршрутизаторов позволя-
ет компенсировать случайные потери отдельных RSVP сообщении*
Если таймаут удаления установлен равным К периодам обновле-
ния, тогда RSVP может допускать потерю К-1 RSVP-пакетов под-
ряд без аннулирования состояния. Механизм управления сетевым
трафиком должен быть отконфигурирован так, чтобы предоставить
Сети передачи данных. Метод доступа
511
минимальную полосу пропускания для сообщений RSVP, чтобы пре-
дотвратить их потерю из-за перегрузки канала.
Состояние, поддерживаемое RSVP, является динамическим. Для
изменения набора отправителей Si или изменения любого запроса
QoS, ЭВМ просто начинает посылать измененные сообщения Path и/
или Resv. В результате будет осуществлено соответствующее изме-
нение RSVP-состояния во всех узлах вдоль пути, неиспользуемые
состояния будут аннулированы по таймауту, если не поступит пря-
мых указаний по их ликвидации до этого.
В стабильном состоянии осуществляется обновление статуса узел
за узлом. Когда полученное состояние отличается от хранящегося,
последнее обновляется. О модификации состояния соседи оповеща-
ются с помощью сообщений обновления, которые рассылаются сра-
зу после изменения состояния. Но эта волна изменений может ос-
тановиться в узле, где в результате слияния получается состояние,
которое не отличается от прежнего. Это минимизирует трафик уп-
равления RSVP, что весьма существенно для больших мультикас-
тинг-групп.
Состояние, которое получено через конкретный интерфейс I* ни-
когда не должно переадресовываться этому интерфейсу. Состояние,
которое направляется интерфейсу I* должно вычисляться на основе
состояний, полученных от других интерфейсов, исключая I*. Триви-
альный пример, поясняющий это правило приведен на рис. 4.4.6.6.7,
на котором показан маршрутизатор с одним отправителем и од-
ним получателем на каждом интерфейсе (Rl, S1 и R2, S2). Интер-
фейсы 1А и 1Б выполняют как входные, так и выходные функции.
Оба получателя используют WF-стиль резервирования, в котором
сообщения Resv переадресуются всем предшествующим узлам груп-
пы вдоль маршрута, за исключением узла, от которого это сообще-
ние получено. В результате достигается независимое резервирова-
ние для обоих направлений (на рис. 4.4.6.6.7 «Получает» и «От-
правляет» подразумевает внешнее направление по отношению к
Маршрутизатору).
Интерфейс 1А Интерфейс 1Б
Получает Отправляет Получает Отправляет
WF (* {4В}) WF (* {ЗВ}) WF (* {ЗВ}) WF (* {4В})
Резервирует
* {4В} | * {ЗВ}
Рис. 4.4.6.6.7. Независимые резервирования
512 Глава 4^
Существует еще одно правило, которое управляет процессом пе-
реадресации сообщений Resv: состояние из сообщения Resv, полу-
ченное через выходной интерфейс 1о, следует передавать входному
интерфейсу И только в том случае, когда сообщение Path от li пере-
адресовано к 1о.
S. Аннулирование (Teardown]
Сообщения RSVP «аннулирование» удаляет проход или состоя-
ние резервирования. Хотя прямое уничтожение старого резервиро-
вания не является обязательным, оно настоятельно рекомендуется,
так как ускоряет переходные процессы в сети.
Существует два типа RSVP сообщений аннулирования: PathTear
и ResvTear. Сообщение PathTear направляется всем получателям
и ликвидирует состояние прохода, а также все зависящие от него
состояния резервирования. Сообщение ResvTear уничтожает состо-
яние резервирования и направляется всем отправителям.
Запрос аннулирование (teardown) может посылаться приложением
оконечной системы (получатель или отправитель), или маршрутизато-
ром в результате таймаута или при появлении привилегированной за-
дачи. После инициализации запрос- аннулирование должен переадресо-
вываться от узла к узлу без задержки. Сообщение аннулирование унич-
тожает специфицированное состояние в узле-получателе.
Подобно другим сообщениям RSVP, запросы-аннулирования до-
ставляются без гарантии надежности. Потеря такого запроса не
вызовет катастрофы, так как не используемое состояние будет рано
или поздно ликвидировано по таймауту. Если маршрутизатор не
получил сообщения аннулирования, он ликвидирует соответствую-
щее состояние по таймауту и формирует сообщение аннулирования,
рассылаемое последующим узлам. Предполагая, что вероятность
потери сообщения RSVP мала, наибольшее среднее время ликвида-
ции ненужного состояния не превышает периода обновления.
Необходимо иметь возможность ликвидировать любой субнабор
установленных состояний. Для состояний прохода это может быть
минимально один отправитель. Для состояний резервирования та-
ким объектом является спецификация фильтра. Например, в слу-
чае, показанном на рис. 4.4.6.6.7, получатель R1 может послать
сообщение ResvTear только отправителю S2 (или любому субнаборУ
из списка спецификаций фильтрации), оставляя S1 без изменении-
Сообщение ResvTear специфицирует стиль и фильтры, любая
спецификация flowspec игнорируется. Любая рабочая специфика-
ция flowspec будет убрана, если все ее спецификации фильтров бу-
дут ликвидированы.
СеТи передачи данных. Метод доступа 513
9. Ошибки
Существует два типа RSVP сообщений об ошибках: ResvErr и
pathErr. Сообщения PathErr очень просты, они посылаются отпра-
вителю виновнику ошибки и не изменяют состояния прохода в
узлах, через которые проходят. Существует всего несколько причин
ошибок прохода.
Однако для синтаксически верных запросов резервирования име-
ется много способов быть отвергнутыми. Узел может решить анну-
лировать установленное резервирование из-за более приоритетных
заданий. Так как неудовлетворение запроса может быть вызвано
объединением нескольких запросов, ошибка резервирования долж-
на быть ретранслирована всем получателям группы. Кроме того,
объединение разнородных запросов создает потенциальную трудность,
известную как проблема «резервирования килера», в которой один
запрос может блокировать услуги другого. В действительности су-
ществует две такие проблемы.
1. Первая проблема резервирования килера (KR-I) возникает,
когда уже имеется резервирование Q0. Если другой получатель де-
лает новое QI > Q0, результирующее объединенное резервирование
Q0 и Q1 может быть отвергнуто системой контроля доступа в неко-
тором последующем узле. Это не должно вредить услугам на уров-
не Q0. Решение этой проблемы весьма просто: когда контроль дос-
тупа не пропускает запрос резервирования, существующее состояние
резервирования сохраняется.
2. Вторая проблема (KR-II) противоположна первой. Получа-
тель, выполняющий резервирование Q1, сохраняется даже в случае
не прохождения контроля доступа для Q1 в каком-то узле. Это не
должно мешать другому получателю, установить меньшее резерви-
рование Q0, которое бы прошло, если бы не было объединено с Q1.
Чтобы решить эту проблему сообщения ResvErr устанавливают
дополнительное состояние, называемое, «состояние блокады», в каж-
дом из узлов, через которые проходит это сообщение. Состояние
блокады в узле модифицирует процедуру объединения, так чтобы
игнорировать блокирующие спецификации flowspec (Q1 в вышепри-
веденном примере), позволяя скромным запросам проходить и осу-
ществлять свое резервирование. Состояние резервирования Q1 счи-
тается в данном случае заблокированным.
Запрос резервирования, не прошедший контроль допуска создает
состояние блокады в соответствующем узле, но остается действую-
щим во всех предшествующих узлах. Было предложено, чтобы эти
Резервирования до точки отказа были удалены. Однако, эти резер-
вирования были сохранены по следующим причинам:
П Зак. № 3430 Семенов
514 Глава 4
• Имеется две возможные причины получателю настаивать на
резервировании:
1. Заказываемый ресурс доступен по всей длине пути, или
2. Нужно получить желаемый уровень QoS вдоль оговоренного
пути так далеко, как это возможно. Конечно, во втором случае, а
может быть и в первом, получатель захочет настаивать на резерви-
ровании, осуществленном вплоть до точки блокировки.
• Если бы эти резервирования в предыдущих узлах не были
сохранены, реагирование RSVP на некоторые переходные отказы
станет хуже. Например, предположим, что маршрут переключился
на альтернативный, который сильно перегружен, так что существу-
ющие резервирования не могут быть удовлетворены, и система воз-
вращается к исходному, маршруту. Состояние блокады в каждом
из маршрутизаторов до узкого места не должно быть немедленно
удалено, так как не позволит системе быстро восстановиться.
• Если бы мы не обновляли резервирование в предшествующих
узлах каждые ТЬ секунд, они могли бы быть удалены по таймауту
(ТЬ время таймаута состояния блокады).
10, Подтверждение
Чтобы запросить подтверждение на свое резервирование, получа-
тель Rj включает в сообщение Resv объект запроса подтверждения,
содержащий IP-адрес Rj. В каждой точке объединения только наи-
большая из спецификаций flowspec и соответствующий объект зап-
роса подтверждения посылаются далее. Если запрос резервирования
от Rj равен или меньше уже существующего резервирования, его
Resv не переадресуется последующим узлам, и, если Resv включает
в себя запрос подтверждения, отправителю Rj посылается сообще-
ние ResvConf. Если запрос подтверждения переадресуется, это дела-
ется немедленно и не более одного раза на каждый запрос.
Этот механизм подтверждения имеет следующую последователь-
ность:
• Новый запрос резервирования со спецификацией flowspec боль-
ше чем любая из действующих в данной точке спецификаций сес-
сии обычно вызывает либо сообщение ResvErr, либо ResvConf, от-
правляемое получателю каждым из отправителей данных. В этом
случае, сообщение ResvConf будет подтверждением, относящимся ко
всему пути.
• Получение ResvConf не предоставляет никаких гарантий.
Предположим, что два запроса резервирования от получателей R1 и
R2 пришли в узел, где они были объединены. R2, чье резервирова-
ние было вторым по времени, может получить подтверждение
СеТИ передачи данных. Метод доступа
515
ResvConf от данного узла, в то время как запрос R1 еще не прошел
весь путь и он может еще быть отвергнут каким-то последующим
узлом. Таким образом, R2 может получить ResvConf, когда не име-
ется полномасштабного резервирования вдоль всего пути; более того,
r2 может получить ResvConf, за которым последует сообщение
ResvErr.
11. Управление политикой
Механизм управления политикой определяет, каким пользовате-
лям или приложениям позволено осуществлять резервирование и в
каком объеме. RSVP-запросы QoS позволяют определенным пользо-
вателям получить предпочтительный доступ к сетевым ресурсам.
Для предотвращения злоупотреблений, необходима некоторая обрат-
ная связь. Такого рода обратная связь может быть реализована с
помощью административной политики обеспечения доступа, или пу-
тем введения прямой или виртуальной оплаты резервирования. В
любом случае требуется идентификация пользователя.
Когда запрашивается новое резервирование, каждый узел дол-
жен ответить на два вопроса: «Имеется ли достаточно ресурсов,
чтобы удовлетворить запрос?» и «Позволено ли данному пользова-
телю осуществлять резервирование? » Эти два решения называются
«управлением доступа» и «управлением политикой», соответствен-
но. Различные административные домены в Интернет могут иметь
разные политики резервирования.
На вход управления политикой поступают специфические бло-
ки данных, которые заключены в объектах POLICYDATA протоко-
ла RSVP. Эти блоки данных могут включать в себя параметры
доступа пользователя, его класс, номер аккоунта, пределы квоты и
пр. Подобно flowspecs, эти данные недоступны для RSVP, который
просто передает их, когда требуется, системе управления политикой.
Аналогично, объединение этих данных должно выполняться систе-
мой управления политикой, а не самим протоколом RSVP. Заме-
тим, что точки объединения данных, характеризующих политику,
Должны находиться на границах административных доменов.
Перенос таких данных, поставляемых пользователями, в сооб-
щениях Resv может представлять проблему в случае существенного
Увеличения числа пользователей. Когда мультикастинг-группа со-
держит большое число получателей, может оказаться невозможно
или нежелательно транспортировать данные, описывающие полити-
ку, вдоль всего маршрута. Эти данные должны объединяться как
Можно ближе к получателям, чтобы избежать чрезмерного информа-
ционного потока.
17*
516
Гпава 4
12. Безопасность
При использовании протокола RSVP возникают определенные
проблемы безопасности.
• Целостность сообщений и аутентификация в узлах
Повреждение или фальсификация запросов резервирования мо-
жет привести к получению услуг неавторизованными пользователя-
ми или к отказам в услугах. RSVP осуществляет защиту против
таких атак с помощью механизма аутентификации, действующего в
каждом из узлов и использующего шифрование с применением хэш-
функций. Механизм поддерживается объектами INTEGRITY, кото-
рые могут быть включены в любое сообщение RSVP. Эти объекты
используют технику криптографических дайджестов, которая пред-
полагает, что соседи RSVP совместно владеют секретом шифрова-
ния (см. [ВакегЭб]).
• Аутентификация пользователя
Управление политикой будет зависеть от положительного ре-
зультата аутентификации для каждого из запросов резервирова-
ния. Информация, характеризующая политику, может быть вклю-
чена в сообщение в виде криптографически защищенного сертифи-
ката пользователя.
• Безопасные потоки данных
Первые два пункта касались выполнения операций RSVP. Тре-
тий пункт касается резервирования для безопасных потоков дан-
ных. В частности, использование IPSEC (IP Security) в потоке дан-
ных создает проблему для RSVP: если транспортный и вышележа-
щие заголовки зашифрованы, общие номера порта RSVP не могут
использоваться для определения сессии или отправителя.
Для решения этой проблемы определено расширение RSVP, в
котором идентификатор секретности (IPSEC SPI) играет ту же роль
что и номер порта [RFC 2207].
13. Области, не поддерживающие RSVP
Невозможно развернуть протокол RSVP (или любой новый про-
токол) во всем Интернет одновременно. Более того, RSVP вероят-
но никогда не будет развернут повсеместно. RSVP должен гаран-
тировать корректную работу, когда два RSVP маршрутизатора объе-
динены друг с другом через сетевую область, не поддерживающую
этот протокол. Конечно, промежуточная сетевая область, лишен-
ная поддержки RSVP, не способна осуществлять резервирование
ресурсов. Однако если эта область обладает достаточной емкостью»
она может обеспечить необходимый уровень услуг в реальном мас-
штабе времени.
Сети передачи данных. Метод доступа
517
Протокол RSVP приспособлен для работы через такие, не под-
держивающие его, сетевые области. Как поддерживающие RSVP так
и не поддерживающие RSVP маршрутизаторы переадресуют сооб-
щения Path в соответствие с адресом местагназначения, используя
свои локальные таблицы маршрутизации. Следовательно, на марш-
рутизацию сообщений Path не оказывает влияние наличие проме-
жуточных маршрутизаторов, лишенных RSVP поддержки. Когда
сообщение Path проходит через сетевую область, не поддерживаю-
щую RSVP, оно, направляясь к следующему узлу, поддерживающему
RSVP, несет в себе IP-адрес последнего RSVP-маршрутизатора. Со-
общение Resv тогда переадресуется непосредственно следующему
RSVP-маршрутизатору на пути к отправителю.
Хотя RSVP работает корректно и через сетевые области без
поддержки RSVP, узлы из этой области могут внести искажения в
QoS. При встрече области без поддержки RSVP протокол устанав-
ливает бит-флаг “NonRSVP” и передает его механизму управления
трафиком. Управление трафиком комбинирует этот однобитовый
флаг со своей собственной информацией об источниках и передает
ее вдоль транспортного пути получателям, используя специфика-
цию Adspecs [RFC 2210].
При некоторых топологиях маршрутизаторов с и без поддержки
RSVP возможна доставка сообщений Resv в не тот узел, или не тот
интерфейс. Процесс RSVP должен быть готов обрабатывать такие си-
туации. Если адрес места назначения не соответствует ни одному ло-
кальному интерфейсу, а сообщение не является Path или PathTear,
тогда оно должно передаваться далее без какой-либо обработки в дан-
ном узле. Чтобы обработать случай с неправильным интерфейсом,
используется дескриптор логического интерфейса LIH (Logical Interface
Handle). Информация предыдущего узла, включенная в сообщение Path,
содержит не только IP-адрес предшествующего узла, но также и ЫН,
определяющий логический выходной интерфейс; обе величины запи-
сываются в состояние прохода. Сообщение Resv, пребывающее в адре-
суемый узел* несет в себе IP-адрес и ЫН правильного выходного интер-
фейса, т.е., интерфейса, который должен получить запрошенное резер-
вирование, вне зависимости от того, на какой интерфейс оно попало.
14. Модель ЭВМ
Прежде чем будет сформирована сессия, ей должен быть присво-
ен идентификатор (DestAddress, Protocolld [, DstPort]), который рас-
сылается всем отправителям и получателям. Когда RSVP сессия
сформировалась, в оконечных системах должны произойти следую-
щие события.
518
Гпава 4 :
Н1 Получатель посредством IGMP подключается к мульти-
каст-группе, заданной адресом DestAddress.
Н2 Потенциальный отправитель начинает посылать сообщения
Path по адресу DestAddress.
НЗ Приложение получателя принимает сообщение Path.
Н4 Получатель начинает посылать соответствующие сообще-
ния Resv, задавая дескрипторы нужных потоков.
Н5 Приложение отправителя получает сообщение Resv.
Н6 Отправитель начинает посылать информационные пакеты.
Существует несколько соображений, касающихся синхронизации.
• Н1 и Н2 могут произойти в любом порядке.
• Предположим, что новый отправитель начинает отправку дан-
ных (Н6), но пока нет мультикастинг маршрутов, так как ни один
получатель не подключился к группе (Н1). Тогда данные будут
выбрасываться в некотором узловом маршрутизаторе (какой это
будет узел, зависит от используемого протокола маршрутизации), !
пока не появится хотя бы один получатель.
• Предположим, что новый отправитель начинает рассылку со-
общений Path (Н2) и данных (Н6) одновременно, и имеется некото-
рое число получателей, но сообщения Resv пока не достигли отпра-
вителя (напр., потому что его сообщения Path еще не дошли до
получателей). Тогда исходные данные могут прийти к получателю
без желаемого уровня QoS. Отправитель может немного облегчить
эту проблему, подождав прибытия первого сообщения Resv (Н5).
Однако, получатели, которые достаточно далеко, могут еще не полу-
чить необходимого резервирования.
• Если получатель начинает посылать сообщения Resv (Н4) до
получения какого-либо сообщения Path (НЗ), RSVP пришлет полу-
чателю сообщение об ошибке.
Получатель может просто игнорировать такие сообщения об
ошибке или он может избежать их, ожидая сообщений, прежде чем
посылать сообщения Resv. Программный интерфейс приложения
(API) для RSVP в данной спецификации не определен, так как он
может зависеть от ЭВМ и ОС.
15. Функциональная спецификация RSVP
15.1. Формат сообщений RSVP
Сообщение RSVP состоит из общего заголовка, за которым еле*,
дует тело сообщения, состоящее из переменного числа объектов пере-
менной длины. Для каждого типа сообщения RSVP, существует на-
бор правил допустимого выбора типов объектов. Эти правила специ-
фицированы с использованием стандартных форм Бакуса-Наура (BNF)»
Сети передачи данных. Метод доступа
519
дополняемых опционными субпоследовательностями, которые поме-
щаются в квадратные скобки. Объекты следуют в определенном по-
рядке. Однако, во многих случаях (но не во всех), порядок объектов
не играет роли. Приложение должно создавать сообщения с поряд-
ком объектов, предлагаемом в данном документе. Но оно должно
быть способно воспринимать объекты в любом порядке.
18. Общий заголовок
В общем заголовке имеются следующие поля:
0 4 8 16 31
VERS Флаги Тип Msg Контрольная сумма RSVP
SendTTL Резерв Длина RSVP
Рис. 4.4.6.6.8. Формат общего заголовка
Vers: 4 бита. Номер версии протокола. В данном описании = 1.
Флаги: 4 бита. Коды 0x01-0x08 зарезервированы. Значения
пока не определены.
Тип Msg: 8 бит. Тип сообщения.
1 = Path
2 = Resv
3 = PathErr
4 = ResvErr
5 == PathTear
6 = ResvTear
7 = ResvConf
Контрольная сумма RSVP: 16 бит.
Дополнение по модулю один контрольной суммы сообщения (в
процессе вычисления поле контрольной суммы считается нулевым).
Если в поле записан нуль, это означает, что контрольное суммирова-
ние не проводилось.
Send__TTL: 8 бит. Значение TTL для протокола IP, с которым
было послано сообщение.
Длина RSVP: 16 бит. Полная длина RSVP сообщения в бай-
тах, включая общий заголовок и объекты переменной длины, кото-
рые за ним следуют.
17. Форматы объектов
• Каждый объект состоит из одного или более 32-битных слов с
'байтовым заголовком. Формат объекта показан на рис. 4.4.6.6.9:
520
Гпава 4
0 16 24 31
Длина в байтах Class_NUM С-тип
Содержимое объекта
Рис. 4.4.6.6.9. Формат объекта
Заголовок объекта имеет следующие поля:
Длина в байтах — 16-битовое поле, содержащее полную длину
объекта в байтах. Длина должна быть кратна 4 октетам,
минимальное значение равно 4.
Class-Num — Идентифицирует класс объекта. Каждый класс
объекта имеет свое имя, которое в данном документе запи-
сывается прописными буквами. Приложения RSVP долж-
ны распознавать следующие классы:
NULL — Объект NULL имеет код Class-Num равный нулю, а его
С-тип игнорируется. Его длина должна быть, по крайней
мере, равна 4, но может быть любой кратной 4. Объект
NULL может появиться где угодно в последовательности
объектов. Его содержимое получателем игнорируется.
SESSION — Содержит IP-адрес места назначения (DestAddress),
идентификатор протокола IP, и обобщенный номер порта
назначения, для того чтобы специфицировать сессию других
объектов, которые следуют далее. Этот класс должен при-
сутствовать в любом сообщении RSVP.
RSVP HOP — Несет в себе IP-адрес узла, поддерживающего
протокол RSVP, который послал это сообщение, и дескрип-
тор логического выходного интерфейса (LIH). Этот класс
характеризует предшествующий узел (previous hop).
TIME_VALUES — Содержит значение периода обновления R,
используемого отправителем сообщения, необходим в
каждом сообщении Path и Resv.
STYLE —.Определяет стиль резервирования, а также зависящую
от стиля информацию, которая не включена в объекты
FLOWSPEC или FILTER SPEC, необходим в каждом
сообщении Resv.
FLOWSPEC — Определяет желательный уровень QoS, в сообщени-
ях Resv.
FILTER-SPEC — Определяет субнабор информационных пакетов
сессии, которые должны получить желательный уровень
Сети передачи данных. Метод доступа
521
QoS (специфицированный объектом FLOWSPEC), в сообще-
ниях Resv.
SENDER-TEMPLATE — Содержит IP-адрес отправителя и, может
быть, некоторые дополнительную информацию, идентифици-
рующую отправителя, необходим в сообщениях Path.
SENDER_TSPEC — Определяет характеристики информационного
трафика отправителя, необходим в сообщениях Path.
ADSPEC — Содержит в себе данные OPWA, для сообщений Path.
ERROR_SPEC — Специфицирует ошибку в сообщениях PathErr,
ResvErr, или подтверждение в сообщении ResvConf.
POLICY_DATA — Несет в себе информацию, которая позволит
локальному модулю, определяющему политику, принять
решение, допустимо ли административно соответствующее
резервирование. Может присутствовать в сообщениях Path,
Resv, PathErr или ResvErr.
INTEGRITY — Несет в себе криптографические данные для аутен-
тификации исходного узла и для верификации содержимого
сообщения RSVP. Использование объекта INTEGRITY описа-
но в ссылке [Baker96] в конце данного раздела.
SCOPE — Несет в себе список ЭВМ-отправителей, к которым
должно быть переадресовано данное сообщение. Может
присутствовать в сообщениях Resv, ResvErr или ResvTear.
RESV_CONFIRM — Несет в себе IP-адрес получателя, который
запросил подтверждение. Может присутствовать в сообще-
ниях Resv или ResvConf.
С-Туре — Тип объекта, уникален в пределах класса Class-Num.
Максимальная длина объекта равна 65528 байт. Поля Class-
Num и C-Тип могут использоваться совместно, как 16-битовое чис-
ло, для определения уникального типа для каждого из объектов.
Старшие два бита Class-Num используются для определения того,
какие действия должен предпринять узел, если он не распознает
Class-Num объекта.
18. Сообщения Path
Каждая ЭВМ-отправитель периодически отправляет сообщения
Path для каждого из информационных потоков, берущих здесь свое
начало. Это сообщение содержит объект SENDER TEMPLATE, оп-
ределяющий формат пакетов данных, и объект SENDER—TSPEC,
специфицирующий характеристики трафика потока. Опционно со-
°бщение может содержать объект ADSPEC, несущий в себе инфор-
мацию о потоке (OPWA).
522
Гпава 4
Сообщение Path направляется от отправителя к получателю по
тому же маршруту, по которому движутся информационные паке-
ты. IP-адрес источника в сообщении Path должен характеризовать
адрес отправителя, в то время как адрес места назначения должен
быть равен DestAddress для текущей сессии. Эти адреса гарантиру-
ют, что сообщение будет корректно маршрутизовано даже через об-
ласти сети, не поддерживающие RSVP. Формат сообщения Path имеет
следующий вид:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <POLICY_DATA> ... ]
[ <sender descriptors ]
<sender descriptors ::= <SENDER_TEMPLATE> <SENDER TSPEC>
[ <ADSPEC> ]
Если присутствует объект INTEGRITY, он должен следовать не-
посредственно за стандартным общим заголовком. Не существует
каких-либо иных ограничений порядка передачи, хотя упомянутое
выше требование является рекомендательным. Число объектов
POLIO Y_D АТ А может быть произвольным.
Объект РНОР (т.е., RSVPHOP) каждого сообщения Path содер-
жит адрес предшествующего узла, напр., IP-адрес интерфейса, через
который только что было послано сообщение Path. Он также содер-
жит дескриптор логического интерфейса (LIH).
Каждый узел, поддерживающий RSVP, вдоль пути перехватывает
сообщение Path и обрабатывает его, с тем чтобы сформировать состо-
яние пути для отправителя, заданного объектами SENDER TEMPLATE
и SESSION. Любой из объектов POLICY DATA, SENDER TSPEC и
ADSPEC также записываются в состояние пути. Если случилась
ошибка при обработке сообщения Path, посылается сообщение PathErr
первичному отправителю сообщения Path.
Периодически процесс RSVP в узле просматривает состояние
прохода, чтобы сформировать новые сообщения Path для посылки
их получателям. Каждое сообщение содержит дескриптор, характе-
ризующий одного отправителя, несет в себе IP-адреса отправителя и
его источника.
Процесс RSVP переадресует и размножает (если требуется, на-
пример при мультикастинге) сообщения Path, используя маршрут-
ную информацию, которую он получает от соответствующих процес-
сов маршрутизации. Маршрут зависит от DestAddress сессии и для
Сети передачи данных. Метод доступа 523
некоторых протоколов маршрутизации от адреса источника. Марш-
рутная информация обычно включает в себя список выходных ин-
терфейсов, куда должно направляться сообщение Path. Так как каж-
дый выходной интерфейс имеет свой IP адрес, сообщения Path, по-
сланные разными интерфейсами содержат отличные адреса РНОР.
Кроме того, объекты ADSPEC, содержащие сообщения Path, будут
отличаться для разных выходных интерфейсов.
Состояние пути для данной сессии и отправителя не обязатель-
но должны иметь уникальные РНОР или уникальный входной ин-
терфейс. Существует два случая, соответствующие мультикастной и
уникастной сессиям.
• Мультикастные сессии
Мультикастинговая маршрутизация позволяет иметь стабильное
дерево распределения, в котором сообщения Path от одного и того же
отправителя приходят от более чем одного РНОР, и RSVP должен
быть готов поддерживать все такие состояния пути. RSVP не дол-
жен пересылать сообщения Path, которые прибывают через входной
интерфейс, .отличный от указанного в маршрутной таблице.
• Уникастные сессии
В течение короткого периода времени, следующего после измене-
ния уникастного маршрута, узел может получать сообщения Path
от нескольких РНОР для данной сессии и отправителя. Узел не
может надежно определить, какой из РНОР является правильным,
хотя узел будет получать одновременно только один из РНОР. Од-
ним из вариантов реализации RSVP является игнорирование РНОР
и допущение для РНОР переключаться между имеющимися канди-
датами. Другим вариантом является поддержание состояния пути
для каждого РНОР и посылка сообщения Resv всем таким РНОР.
В любом варианте ситуация является переходной, неиспользуемые
состояния пути все равно будут удалены (явно или по таймауту).
19. Сообщения Resv
Сообщения Resv несут в себе запросы резервирования от узла к
Узлу, от получателей к отправителям в направлении противопо-
ложном движению потока данных. IP-адрес места назначения сооб-
щения Resv является уникастным адресом предшествующего узла,
полученным из состояния прохода. IP-адрес источника является
адресом узла, который посылает сообщение. Сообщение Resv имеет
следующий формат:
<Resv Message> ::= <Common Header > [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
524
Гпава 4
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor>
Если присутствует объект INTEGRITY, он должен непосредственно
следовать за общим заголовком. За объектом STYLE следует спи-
сок дескрипторов потоков. Объекты в списке дескрипторов должны
следовать требованиям, записанным ниже в BNF.
Объект NHOP (напр., RSVP_HOP) содержит IP-адрес интерфей-
са, через который посылаются сообщения Resv, и LIH для логичес-
кого интерфейса, где требуется резервирование.
Появление объекта RESV_CONFIRM сигнализирует о запросе
подтверждения резервирования и несет в себе IP-адрес получателя,
которому должен быть послан ResvConf. Число объектов
POLICY DATA не лимитировано.
Ниже приведены правила, которые специфицируют структуру <
дескриптора потока для каждого из стилей резервирования. |
• Стиль WF: g
<flow descriptor list> <WF flow descriptor>
< WF flow descrip tor > <FLOWSPEC>
• Стиль FF:
<flow descriptor list> <FLOWSPEC> <FILTER_SPEC> |
<flow descriptor list> <FF flow descriptor>
<FF flow descriptor> [ <FLOWSPEC> ] <FILTER_SPEC>
Каждый запрос стиля FF описывается одной парой (FLOWSPEC, >
FILTERJSPEC), несколько таких запросов могут быть уложены в ;
один список дескрипторов потока сообщения Resv. Объект
FLOWSPEC может быть опущен, если он идентичен последнему та-
кому объекту в списке. Первый дескриптор потока стиля FF дол- *
жен содержать FLOWSPEC.
• Стиль SE:
<flow descriptor list> ::== <SEflow descriptor>
<SEflow descriptor> ::=<FLOWSPEC> <filter spec list>
<filter spec list> <FILTER_SPEC>| <filter spec list> <FILTER_SPEC>
Набор отправителей (reservation scope), которым направляется кон- .
кретный запрос резервирования, определяется следующим образом:
• Явный выбор отправителя
Сети передачи данных. Метод доступа
525
Резервирование переадресуется всем отправителям, чьи объекты
SENDER.TEMPLATE, записанные в состоянии прохода соответству-
ют объекту FILTERSPEC.
• Произвольный выбор отправителей (wildcard)
Запрос с произвольным выбором отправителя соответствует всем
отправителям, которые маршрутизированы на данный выходной
интерфейс.
Когда сообщение Resv с произвольным выбором отправителя
переадресуется более чем одному предыдущему узлу, в сообщение
должен быть включен объект SCOPE. В этом случае список IP
адресов для рассылки хранится именно в этом объекте.
Сообщение Resv, которое пересылается узлом, является в общем
случае результатом объединения входящих сообщений Resv. Если
одно из этих объединенных сообщений содержит объект
RESV_CONFIRM и имеет число FLOWSPEC, больше чем FLOWSPEC
всех других запросов резервирования, тогда этот объект
RESVCONFIRM переадресуется в виде исходящего сообщения Resv.
Объект RESV CONFIRM из одного из объединенных запросов (чья
спецификация flowspecs равна, меньше или сравнима с объединенной
спецификацией flowspec и которая не подвергнута блокаде) запустит
генерацию сообщения ResvConf, содержащего RESV CONFIRM.
Объект RESVCONFIRM в запросе, который подвергнут блокаде, не
будет переадресован или возвращен, он будет аннулирован в теку-
щем узле.
80. Сообщения отмены прохода
Получение сообщения PathTear (path teardown) аннулирует со-
стояния прохода. Соответствующее состояние должно согласовы-
ваться с объектами SESSION, SENDER TEMPLATE и РНОР. Кроме
того, сообщение PathTear для мультикастной сессии может соответ-
ствовать только состоянию прохода для входного интерфейса, через
который получено сообщение PathTear. Если соответствия состоя-
нию прохода нет, сообщение должно быть отброшено без дальней-
шей рассылки.
Сообщения PathTear инициализируются непосредственно отпра-
вителем или в результате таймаута состояния прохода в каком-
либо узле и направляются всем отправителям. Уникастное PathTear
Не Должно переадресовываться, если состояние прохода соответству-
ет той же сессии и отправителю, но имеет другой РНОР.
Сообщение PathTear должно маршрутизоваться в точности
также как соответствующие сообщения Path. Следовательно, его
-адрес места назначения должен совпадать с DestAddress, а его
526 Глава 4
IP-адрес источника должен быть адресом отправителя из состояния
прохода.
<PathTear Message> <Common Header> [ <INTEGRITY>
]<SESSION> <RSVP_HOP> f
[ <sender descriptor> ]
<sender descriptor> ::= (seeearlier definition) |
Сообщение PathTear может содержать в своем дескрипторе от-
правителя объект SENDER_TSPEC илц ADSPEC, но они должны
игнорироваться. *
Удаление состояния прохода в результате получения сообщения
PathTear или таймаута должно модифицировать состояние резерви-
рования в данном узле. Эта модификация зависит от стиля резер- t
вирования. Например, предположим, что PathTear удаляет состоя-
ние прохода отправителя S. Если стиль специфицирует явный вы-
бор отправителя (FF или SE), всякое резервирование со спецификацией
фильтрования, соответствующей отправителю S, должно быть уда- -
лено; если стиль предусматривает произвольный выбор отправите- ...
ля (WF), резервирование удаляется, если S является последним от-
правителем, участвующим в сессии. Эти изменения резервирования ;
не должны вызвать немедленную посылку сообщения обновления
Resv, так как сообщение PathTear уже вызвало необходимые изме- £
нения. Они не должны также вызвать отправку сообщения ResvErr,
так как это может вызвать лавину таких сообщений.
21. Сообщения отмены Resv
Получение сообщения ResvTear (reservation teardown) удаляет 5
соответствующие состояния резервирования. При этом проверяется
соответствие объектов SESSION, STYLE и FILTER SPEC, а также
ЫН в объекте RSVP HOP. Если соответствие не обнаружено, сооб-
щение ResvTear игнорируется. Сообщение ResvTear может отме-
нить любой субнабор спецификаций фильтрации в состояниях ре- 5
зервирования стилей FF или SE.
Сообщения ResvTear отправляются получателями или любым
узлом, в котором состояние резервирование аннулируется в резуль- j
тате таймаута, далее они движутся в направлении получателей.
Сообщение ResvTear должно маршрутизироваться аналогично ?
соответствующим сообщениям Resv, а его IP-адрес места назначе-
ния является уникастным адресом предыдущего узла.
<ResvTear Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP> 7
[ <SCOPE> ] <STYLE>
Сети передачи данных. Метод доступа
527
<flow descriptor list>
<flow descriptor list> ::= (seeearlier definition)
I
Объекты FLOWSPEC в списке дескрипторов потоков сообщения
ResvTear будут игнорироваться и могут быть опущены. Сообщение
ResvTear может включать в себя объект SCOPE, но он должен игно-
рироваться.
В зависимости от изменения состояния узла получение сообще-
ния ResvTear может вызвать переадресацию этого сообщения, по-
сылку модифицированного сообщения Resv или не вызвать ника-
кой реакции. Эти три случая могут быть проиллюстрированы для
стиля резервирования FF на рис. 4.4.6.6;4.
• Если получатель R2 посылает сообщение ResvTear для резер-
вирования S3{B}, соответствующее резервирование удаляется из ин-
терфейса (1г) и посылается ResvTear для S3{B} интерфейсу (1Б).
• Если получатель R1 посылает ResvTear для резервирования
S1{4B}, соответствующее резервирование удаляется из интерфейса
(1В) и немедленно посылается модифицированное сообщение Resv
FF( S1 {ЗВ} ) интерфейсу (1А).
• Если получатель R3 посылает сообщение ResvTear для S1{B},
никаких изменений резервирования не происходит и никаких сооб-
щений далее не посылается.
82. Сообщения об ошибке прохода
Сообщения PathErr (path error) несут в себе данные об ошибке в
обрабатываемых сообщениях Path. Они направляются отправите-
лям данных и маршрутизируются от узла к узлу, используя состоя-
ние прохода. При каждом шаге IP-адрес места назначения являет-
ся уникастным адресом предыдущего узла. Сообщения PathErr не
модифицируют состояния узлов, через которые проходят; они пред-
назначаются только приложению отправителя.
<PathErr message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
[ <POLICY_DATA> ...]
[ <sender descriptor> ]
<sender descriptor> (see earlier definition)
Объект ERRORSPEC специфицирует ошибку и включает в себя
№-адрес узла, который обнаружил эту ошибку (Error Node Address).
Для приобщения необходимой информации в сообщение могут быть
включены один или более объектов POLICY DATA.
528
Гпава 4
23. Сообщения об ошибках Resv
Сообщения ResvErr (reservation error) сообщают об ошибках
при обработке сообщений Resv, или о спонтанном нарушении резер-
вирования, напр., в результате административного вмешательства.
Сообщения ResvErr направляются соответствующим получате-
лям, они маршрутизируются от узла к узлу с использованием состо-
яния резервирования. В каждом из узлов в качестве IP-адреса мес-
та назначения используется уникастный адрес следующего узла.
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <POLICY_DATA> ...]
<STYLE> [ <error flow descriptor> ]
Объект ERROR SPEC специфицирует ошибку и включает в себя
IP-адрес узла, который обнаружил ошибку (Error Node Address).
Для приобщения необходимой информации в сообщение могут быть
включены один или более объектов POLICY DATA. Объект
RSVP_HOP содержит адрес предыдущего узла, а объект STYLE ко-
пируется из сообщения Resv.
Следующие правила, зависящие от стиля, определяют структуру
ошибки дескриптора потока.
• Стиль WF:
<error flow descriptor> ::== <WF flow descriptor>
• Стиль FF:
<error flow descriptor> ::= <FF flow descriptor>
Каждый дескриптор потока в сообщении Resv стиля FF должен
обрабатываться независимо и для каждого из них, имеющего ошиб-
ку, должно посылаться отдельное сообщение ResvErr.
• Стиль SE:
<error flow descriptor> ::= <SE flow descriptor>
Сообщение ResvErr стиля SE может представить список субна-
бора спецификаций фильтрации, которые вызвали ошибки, в соот-
ветствующем сообщении Resv.
Заметим, что сообщение ResvErr содержит только один дескрип-
тор потока. Следовательно, сообщение Resv, которое содержит N > 1
дескрипторов потока (стиль FF) может быть причиной N сообщений
ResvErr.
Сети передачи данных. Метод доступа
529
Вообще говоря, сообщение ResvErr следует пересылать всем полу-
чателям, которые могут быть причиной данной ошибки. Конкретнее:
• Узел, который обнаружил ошибку в запросе резервирования
посылает сообщение ResvErr узлу, от которого получен ошибочный
запрос резервирования.
Это сообщение ResvErr должно содержать информацию, необхо-
димую для идентификации ошибки и для маршрутизации сообще-
ния о ней последующим узлам. Такое сообщение, следовательно,
включает в себя объект ERRORSPEC, копию объекта STYLE и со-
ответствующий дескриптор потока, где зафиксирована ошибка. Если
ошибка является результатом отказа при попытке увеличить ре-
зервирование, тогда существующее резервирование должно быть со-
хранено и должен быть установлен бит-флаг InPlace в ERRORJSPEC
сообщения ResvErr.
• Узлы переадресуют сообщение ResvErr последующим узлам,
которые имеют локальное состояние резервирования. Для резерви-
рования с произвольным выбором отправителей имеется дополни-
тельное ограничение на пересылку сообщений ResvErr, связанное с
блокировкой возможных циклических маршрутов. Существует стро-
гое правило рассылки сообщений при ошибке, связанной с разреше-
нием доступа. Сообщение ResvErr, которое посылается, должно не-
сти в себе спецификацию FILTER_SPEC соответствующего состоя-
ния резервирования.
• Когда сообщение ResvErr достигает получателя, приложение
должно принять объект STYLE, список дескрипторов потока и объект
ERROR SPEC (включая его флаги).
24. Сообщения подтверждения
Сообщения ResvConf посылаются в ответ на запрос подтвержде-
ния резервирования. Сообщение ResvConf посылается в результате
появления объекта RESV_CONFIRM в сообщении Resv. Сообщение
ResvConf посылается по уникастному адресу ЭВМ получателя, адрес
берется из объекта RESVCONFIRM.
<ResvConf message> <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
<RESV_CONFIRM>
<STYLE> <flow descriptor list>
<flow descriptor list> (seeearlier definition)
Объект RESV CONFIRM является копией объекта в сообщении
Resv, который вызвал подтверждение. ERRORJSPEC используется
т°лько для переноса IP-адреса исходного узла в поле адрес узла с
530
Гпава‘4
ошибкой (Error Node Address). Равенство кода ошибки и значения
нулю свидетельствует о подтверждении. Список дескрипторов пото-
ков специфицирует конкретное резервирование, которое подтверж-
дается. Это может быть субнабор из списка дескрипторов потоков
Resv, для которого запрошено подтверждение.
25. Использование портов
Сессия RSVP определяется в норме тремя параметрами:
DestAddress, Protocolld, DstPort. Здесь DstPort является полем пор-
та назначения UDP/TCP. DstPort может быть опущен (сделан рав-
ным нулю), если Protocolld специфицирует протокол, который не
имеет поля порта места назначения.
RSVP допускает любое значение для Protocolld. Однако, реали-
зации оконечных систем RSVP могут знать об определенных значе-
ниях для этого поля и в частности значения для UDP и TCP (17 и
6 соответственно). Оконечная система может выдать сигнал ошиб-
ки приложению, которая:
• специфицирует ненулевое значение DstPort для протокола,
который не имеет портов типа UDP/TCP, или
• специфицирует нулевое значение DstPort для протокола, ко-
торый имеет порты, специфицированные для UDP/TCP.
Спецификации фильтра и шаблоны отправителя определяют пару:
SrcAddress, SrcPort, где SrcPort поле UDP/TCP порта. В некоторых
случаях SrcPort может быть опущен (установлен равным нулю).
Существуют следующие правила использования нулевого значения
полей DstPort и/или SrcPort в RSVP.
1. Порты назначения должны быть взаимосогласованными.
Состояния прохода и резервирования для одного и того же
DestAddress и Protocolld должны иметь свои значения DstPort, ко-
торые все равны нулю или все не равны нулю. Нарушение этого
условия в узле является ошибкой «конфликт портов назначения
(Conflicting Dest Ports)».
2. Правило портов назначения.
Если DstPort в описании сессии равен нулю, все поля SrcPort,
используемые для этой сессии, также должны быть равны нулю.
При этом предполагается, что протокол не имеет портов типа UDP/
TCP. Нарушение этого условия в узле вызовет ошибку «Bad Src
Ports».
3. Порты источников должны быть взаимосогласованы.
ЭВМ-отправитель не должна посылать состояния прохода со
значениями SrcPort равными и неравными нулю. Нарушение этого
условия вызовет ошибку «Conflicting Sender Port». Заметим, что
Сети передачи данных. Метод доступа
531
протокол не допускает произвольного назначения номеров портов
(wildcard), т.е., нулевой порт не может соответствовать ненулевому
порту.
26. Посылка сообщений RSVP
Сообщения RSVP посылаются от узла к узлу между RSVP-мар-
шрутизаторами, поддерживающими этот протокол, в виде IP-дейтог-
рамм с кодом протокола 46. IP-дейтограммы предназначены также
для использования между оконечными системами и первыми/пос-
ледними маршрутизаторами.
Сообщения Path, PathTear и ResvConf должны посылаться с
опцией Router Alert IP [RFC 2113] в их IP-заголовках.
По прибытии RSVP-сообщения М, которое меняет статус, узел
должен немедленно послать сообщение о модификации состояния.
Однако это не должно привести к посылке сообщения через интер-
фейс, откуда пришло М (что может случиться, если приложение
запустит процедуру обновления состояний для текущей сессии). Это
правило предотвращает лавину пакетов в сетях с широковещатель-
ной рассылкой.
Каждое RSVP-сообщение должно пересылаться только в одной
IP-дейтограмме. Если оно превосходит MTU, такая дейтаграмма бу-
дет фрагментирована. Восстановление сообщения будет произведе-
но узлом-получателем. Это имеет несколько следствий:
• Одиночное RSVP-сообщение не должно превосходить макси-
мального размера IP-дейтограммы, примерно 64К байт (на практике
значительно меньше!).
• Перегруженные сетевые области, которые не поддерживают
RSVP, могут потерять отдельные фрагменты, а это приведет к потере
всего сообщения.
RSVP использует свой механизм периодического обновления
Для предотвращения влияния случайной потери отдельных паке-
тов. При перегрузке сети, однако, существенные потери RSVP-сооб-
Щений могут вызвать серьезные нарушения при резервировании се-
тевых ресурсов. Для контроля задержек, связанных с обслуживани-
ем очереди, и влияния потерь RSVP пакетов, маршрутизаторы
Должны быть сконфигурированы так, чтобы обеспечивать для дан-
ных целей приоритетное обслуживание. Если RSVP-пакеты идут
через область сети, где вероятность потери значительна, следует уве-
личить значение таймаутов.
Некоторые мультикастные протоколы маршрутизации обеспе-
чивают туннели, которые организуют IP-инкапсуляцию мультикас-
THbix пакетов и их транспортировку через маршрутизаторы, кото-
532
Гпава 4
рые не поддерживают мультикастную маршрутизацию. RSVP мо-
жет работать через такие мультикастные туннели следующим об-
разом:
1. Когда узел N направляет сообщение Path выходному логичес-
кому интерфейсу L, он включает в сообщение дескриптор логическо-
го интерфейса LIH (logical interface handle). Значение ЫН содер-
жится в объекте RSVPHOP.
2. Следующий узел N’ запоминает значение ЫН в своем состо-
янии прохода.
3. Когда N’ посылает сообщение Resv узлу N, он включает в
него значение ЫН из состояния прохода (содержится в объекте
RSVPHOP).
4. Когда сообщение Resv прибывает в N, его значение ЫН выда-
ет информацию, необходимую для осуществления резервирования в
определенном логическом интерфейсе. Заметим, что узел N создает
и интерпретирует ЫН, которое совершенно не доступно для узла N’.
27. Исключение циклов сообщений RSVP
Переадресация сообщений RSVP должна исключать возможность
образования петель. В спокойном состоянии сообщения Path и Resv
направляются каждому узлу только раз за период обновления. Это'
исключает зацикливание пакетов, но имеется еще возможность пе-
тель «автоматического обновления». Такие петли автоматического
обновления сохраняют состояние «вечно», даже если оконечные узлы
прекращают их обновление до тех пор* пока получатели не покинут:
мультикастинг-группу и/или отправители прекратят посылку сооб-
щения Path. С другой стороны сообщения об ошибке и об аннули-
ровании (teardown) посылаются немедленно и могут служить при-*1
чиной возникновения циклов. 1
Рассмотрим каждый тип сообщения.
• Сообщения Path, Эти сообщения направляются точно тем же!
путем, что и информационные IP-пакеты. Следовательно, не должно-
возникать циклов для сообщений типа Path (за исключением цик-1
лов, связанных с переходными процессами установления маршрута). ’
• Сообщения PathTear, Эти сообщения используют ту же мар-?
шрутизацию, что и сообщения Path и, следовательно, не могут обря-
зовывать циклов.
• Сообщения PathErr. Так как сообщения Path не образуют цик-
лов, они формируют состояние прохода, которое описывает обратный11
маршрут для каждого из отправителей, который не может иметь пе- '
тель. Сообщения PathErr всегда направлены определенному отпря^
вителю и, следовательно, не могут образовывать циклов.
Сети передачи данных. Метод доступа 533
----“
. Сообщения Resv. Эти сообщения направлены определенному
отправителю и не могут иметь циклов. Однако, сообщения Resv с
произвольным выбором отправителя (wildcard) (стиль WF) имеет
потенциал для запуска циклов обновления.
• Сообщения ResvTear. Хотя сообщения ResvTear маршрутизи-
руются также как и сообщения Resv. При повторном проходе по
петле состояние будет отсутствовать (аннулировано!), и любое сооб-
щение ResvTear будет отброшено.,
• Сообщения ResvErr. Эти сообщения для стиля резервирова-
ния WF могут вызывать зацикливание по той же причине, что и
для сообщений Resv.
• Сообщения ResvConf. Эти сообщения направляются фиксиро-
ванному уникастному получателю и не могут приводить к циклам.
Если топология не содержит петель, зацикливания сообщений
Resv и ResvErr при произвольном выборе отправителя можно избе-
жать, следуя приведенному выше правилу: состояние, которое полу-
чено через определенный интерфейс, никогда не должно переадресо-
вываться через этот же интерфейс. Однако, когда топология содер-
жит петли, необходимы дополнительные усилия для предотвращения
циклов автоматического обновления для сообщений Resv и ResvErr
с произвольным выбором отправителя. Решением этой проблемы
может быть включение списка адресов получателей в объект SCOPE.
Когда сообщение Resv с стилем WF должно быть переадресова-
но определенному предыдущему узлу, следует определить новый список
адресов для объекта SCOPE на основе аналогичного объекта, полу-
ченного с соответствующими сообщениями Resv. Если новый объект
SCOPE пуст, сообщение не направляется предыдущему узлу. Прави-
ла для вычисления нового объекта SCOPE для сообщения Resv при-
ведены ниже:
1. Образуется объединение наборов IP-адресов отправителей, пе-
речисленных во всех объектах SCOPE состояния резервирования
Данной сессии. Если состояние резервирования от некоторых NHOP
Не содержит объектов SCOPE, должен быть создан заменяющий список
отправителей, который и помещается в указанное объединение. Для
сообщения, которое получено выходным интерфейсом 01, список
Замен представляет собой набор отправителей, которые маршрути-
зированы на этот 01.
2. Любые локальные отправители (т.е., любое приложение от-
правителя в данном узле) удаляются из этого списка.
2. Если объект SCOPE должен быть послан РНОР, следует уда-
ЛйТь Из набора любого отправителя, который не присылает данные
ЧеРез РНОР.
534
Гпава 4
На рис. 4.4.6.6.10 показан пример Resv сообщений (стиль WP),
Адресный список объекта SCOPE показан в квадратных скобках.
Рис. 4.4.6.6.10. Объекты SCOPE при резервировании в стиле WF
Объекты SCOPE не являются необходимыми, если мультикас-
тинг-маршрутизация использует совместные деревья или если стиль
резервирования предполагает явный выбор отправителей. При ис-
пользовании объектов SCOPE в сообщениях ResvErr стиля WF еле*
дует придерживаться следующих правил:
1 .Узел, который обнаружил ошибку, отправляет сообщение
ResvErr, содержащее копию объекта SCOPE, соответствующего со-,
стоянию резервирования или сообщению, которое вызвало ошибку,
2 . Предположим, что узлом получено сообщение ResvErr с про?
извольным указанием отправителей (wildcard), содержащее объект
SCOPE со списком адресов отправителей L. Сообщение ResvErr, пе-
реадресованное интерфейсу 01 должно содержать объект SCOPE, из-
влеченный из L и включающий только те адреса отправителей, ко-
торые маршрутизированы на 01. Если этот объект SCOPE пуст, сообг
щение ResvErr не должно посылаться 01.
28. Состояние блокады
Основным правилом при формировании сообщения обновления
Resv является объединение спецификаций flowspecs резервирова-
ния в узле посредством вычисления их LUB (наименьший верхний
предел). Однако это правило модифицируется при наличии «состоя-
ния блокады», возникшего из-за сообщений ResvErr при решения
проблемы KR-II.
Когда получено сообщение ResvErr, его спецификация flowspec Q*
используется для формирования или обновления элемента местно#
состояния блокады. Каждый элемент состояния блокады состоит из
Сети передачи данных. Метод доступа 535
спецификации flowspec Qb, взятой из спецификации сообщения ResvErr
и соответствующего таймера блокады ТЬ. Когда врезая таймера бло-
кады истекает, соответствующее состояние блокады аннулируется.
Гранулярность состояния блокады зависит от стиля сообщения
ResvErr, которое явилось ее причиной. Каждому конкретному сти-
лю может соответствовать свой элемент состояния блокады (Qb(S),
Tb(S)), где S — отправитель. Для произвольного стиля выбора от-
правителя состояние блокады определяется предыдущим узлом Р.
Элемент состояния блокады со спецификацией flowspec Qb на-
зывается блокадой резервирования со спецификацией flowspec Qi,
если Qb не больше чем Qi. Например, предположим, что LUB (least
upper bound) двух спецификаций flowspecs было вычислено путем
выбора максимальных составляющих их компонент. Тогда Qb бло-
кирует Qi, если для некоторой компоненты j, Qb[j] < Qi[j).
Предположим, что узел получает сообщение ResvErr от предыду-
щего узла Р (или, если стиль выбора является явным от отправи-
теля S) в результате ошибки доступа. Тогда:
1. Для Р (или S) создается элемент состояния блокады, если его
не было.
2. Qb(P) (или Qb(S)) делается равным flowspec Qe из сообщения
ResvErr.
3. Запускается (или перезапускается) соответствующий таймер
блокады ТЬ(Р) (или Tb(S)) на время Kb*R. Здесь КЬ является фик-
сированным множителем, a R равно интервалу времени обновления
состояния резервирования. КЬ можно варьировать.
4. Если имеется локальное состояние резервирования, которое
не заблокировано, немедленно генерируется обновление резервиро-
вания для Р (или S).
5. Сообщение ResvErr переадресуется' последующим узлам. Если
бит 1пР1асе=0, сообщение ResvErr направляется всем последующим
узлам, где имеется состояние резервирования. Если бит 1пР1асе=1,
сообщение ResvErr направляется только следующим узлам, чьи Qi
блокированы спецификацией Qb.
В Результате предлагается модифицированное правило для объе-
динения спецификаций flowspecs при формировании сообщения об-
новления резервирования.
’ Если имеются какие-либо локальные запросы резервирования
Кот°рые не заблокированы, они объединяются путем вычисле-
их LUB. Заблокированные резервирования игнорируются. Это
а Воляет требовать меньшее резервирование, которое имеет шанс
Успех’ после того как большее резервирование не удалось.
536
Гпава 4
Посылает Состояние блокады
{Qb}
(а) <— WF(* {2В}) {4В}
(Ь)4—WF(* {4В}) (ничего)
Резервирует Получает
| ♦ (4В) | WF(* (4В]) •«--- (с)
| * 12В) I WF(* {2В|) <4— (d)
Рис. 4.4.6.6.11. Блокада для стиля WF
• В противоположном случае (все локальные запросы Qi бло-
кированы), они объединяются путем взятия GLB (Greatest Lower
Bound) спецификаций Qi. '
Этот алгоритм объединения обновления применяется отдельно
для каждого потока (каждого отправителя или РНОР), вносящего
вклад в общее резервирование (стили WF или SE).
На рис. 4.4.6.6.11 приведен пример использования состояния
блокады для совместного резервирования (стиль WF). Имеется два
предшествующих узла, помеченных как (а) и (Ь), и два последую-
щих узла, помеченных как (с) и (d). Большее резервирование 4В
пришло сначала от (с), но “застряло” где-то до РНОР (а), а не на
пути через РНОР (Ь). Рисунок показывает оконечное состояние после
меньшего резервирования 2В пришедшего позднее из (d). Это ста-
бильное состояние нарушается каждые Kb*R секунд, когда состоя- ..
ние блокады удаляется по таймауту. Следующее обновление (4В),
посылаемое предыдущему узлу (а), предположительно будет отверг-
нуто, путем посылки сообщения ResvErr, которое восстановит со-
стояние блокады, возвращая ситуацию к тому, что изображено на
рисунке. В то же самое время сообщение ResvErr будет направлено д
следующему узлу (с) и всем получателям, ответственным за резер-
вирование 4В.
29. Локальное восстановление
Когда маршрут изменяется, следующее сообщение обновления 1
Path или Resv установит проход или состояние резервирования (со- р
ответственно) вдоль нового маршрута. Чтобы обеспечить быструю
адаптацию к изменениям маршрута, не вводя чрезмерно коротких
периодов обновления, местный модуль протокола маршрутизации
может сообщить процессу RSVP об изменении маршрута до опреде-
ленных мест назначения. Процесс RSVP должен использовать эту
информацию для запуска обновления в соответствующей области <>
учетом изменения маршрута.
При этом используются следующие'правила:
сети передачи данных. Метод доступа
537
• Когда маршрутизация обнаруживает изменение набора вы-
ходных интерфейсов для места назначения G, RSVP должен обно-
вить состояние прохода, подождать короткий период W и затем
послать сообщение обновление Path всем сессиям G/* (т.е., любой
сессии с местом назначения G, вне зависимости от порта назначе-
ния). Короткая выдержка перед рассылкой сообщения обновления
Path нужна, чтобы позволить завершиться переходным процессам
в маршрутном протоколе. В настоящее время предлагается W = 2
сек; однако, эта величина должна быть задана при конфигурирова-
нии каждого интерфейса.
• Когда приходит сообщение Path с адресом предыдущего узла,
который отличается от записанного в состоянии прохода, RSVP
должен немедленно послать сообщение обновления Resv этому РНОР.
30. Временные параметры
Существует два временных параметра, соответствующие каждо-
му элементу прохода или состоянию резервирования RSVP в узле:
период обновления R между последовательными коррекциями со-
стояния соседнего узла и время жизни локального состояния L.
Каждое сообщение RSVP Resv или Path может содержать объект
TIME VALUES, специфицирующий значение R, которое было исполь-
зовано при генерации данного сообщения обновления. Эта величи-
на R затем используется для определения значения L. Величины R
и L могут варьироваться от узла к узлу.
Более подробно:
1. Флойд и Джакобсон [FJ94] показали, что периодические сооб-
щения, генерируемые независимыми сетевыми узлами, могут взаим-
но синхронизоваться. Это может привести к деградации сетевых
услуг, так как периодические сообщения могут сталкиваться с дру-
гими сетевыми пакетами. Так как RSVP периодически посылает
сообщения обновления, он должен избегать синхронизации сообще-
ний и гарантировать, чтобы любая возникшая синхронизация не
была стабильной. По этой причине таймер обновления должен быть
Рэндомизован в диапазоне [0.5R, 1.5RJ.
2. Чтобы избежать преждевременной потери состояния, L долж-
Но Удовлетворять условию L > (К + 0.5)*1.5*R, где К небольшое
Целое число. Тогда в худшем случае, К-1 последовательных сооб-
щений могут быть потеряны без ликвидации состояния. Чтобы вы-
числить время жизни L для комбинации состояний с различными R
R1, ..., R заменяется на max(Ri). В настоящее время по умолча-
нию К = 3. Однако может быть необходимо установить большее
значение К для узлов с высокой вероятностью потерь. К может
538
Гпава 4
устанавливаться при конфигурации интерфейса вручную или с по-
мощью какой-либо адаптивной процедуры.
3. Каждое сообщение Path или Resv несет в себе объект
TIME_VALUES, содержащий время обновления R, использованное
при генерации обновлений. Узел получателя использует это R для
определения времени жизни L записанного состояния, созданного
или обновленного данным сообщением.
4. Время обновления R выбирается локально для каждого из
узлов. Если узел не использует локального восстановления резер-
вирования, нарушенного в результате изменения маршрута, мень-
шее значение R ускоряет адаптацию к изменениям маршрута, но
увеличивает издержки RSVP. Узел может настраивать эффективное
значение R динамически, чтобы контролировать уровень издержек,
связанных с сообщениями обновления. В настоящее время по умол-
чанию выбирается R = 30 секундам. Однако значение по умолчанию
Rdef должно выбираться индивидуально для каждого интерфейса.
5. Когда R меняется динамически, существует предел того, как
быстро оно может расти. Отношение величин R2/R1 не должно
превосходить 1 + Slew.Мах. В настоящее время, Slew.Мах равно
0.30. При К = 3, один пакет может быть потерян без таймаута1
состояния, в то время как R увеличивается на 30% за период об-
нов ления.
6. Чтобы улучшить надежность, узел может временно после из-4
менения состояния посылать сообщения обновления более часто. 11
7. Значения Rdef, К и Slew.Мах, используемые в приложении,^
должны легко модифицироваться для каждого интерфейса.
31. Политика в области трафика и узлы
с не интегрированными услугами
Некоторые уровни QoS могут требовать определенной политикй'
в управлении трафиком в некоторых или всех перечисленных ниже
случаях:
1. Краевые точки сети.
2. Точки объединения данных от многих отправителей.
3. Точки ветвления, где трафик в различных ветвях может тре-
бовать различных уровней резервирования.
RSVP знает, где такие точки находятся, и должен обеспечивать
этими данными механизм управления трафиком. С другой стороны,
RSVP не интерпретирует информацию в flowspec и, следовательно
не знает, использованы ли рекомендации управления в каждом кон-
кретном случае.
Сети передачи данных. Метод доступа
539
Процесс RSVP передает управлению трафиком специальный флаг
политики для каждой из трех указанных выше ситуаций.
• E_Police_ Flag - управление входом
Этот флаг устанавливается для первого узла RSVP, который реа-
лизует управление трафиком. Например, ЭВМ-отправители должны
поддерживать RSVP, но многие из них не поддерживают управление
трафиком. В этом случае флаг E_Police_Flag в ЭВМ-отправителе
должен быть равен нулю, флаг устанавливается равным 1, когда
достигнута первая ЭВМ, поддерживающая управление трафиком. Это
контролируется флагом E Police в объектах SESSION.
• M_Police_Flag - управление объединением
Этот флаг должен быть установлен для резервирования, исполь-
зующего стили WF или SE, когда объединяются потоки более чем
одного отправителя.
• B_Police_Flag -управление ветвлением
Этот флаг должен быть установлен, когда инсталлированная
flowspec меньше или сравнима с FLOWSPEC какого-либо другого
интерфейса для того же самого FILTER_SPEC и SESSION.
RSVP должен также проверять наличие вдоль пути узлов, не
поддерживающих RSVP, и переправлять эту информацию управле-
нию трафиком. На.основании этого флага и другой сопутствующей
информации система контроля трафиком может обнаружить узлы,
которые не способны обеспечить управление QoS. Эта информация
передается получателям в спецификации Adspecs [RFC 2210].
При обычной IP-переадресации, RSVP может обнаружить узлы
без поддержки RSVP путём сравнения значения IP TTL, с которым
послано сообщение Path, с полученным TTL. Для этой цели TTL
помещается в общий заголовок. Однако, TTL не всегда является
надежным индикатором узлов без поддержки RSVP, и для этих
Целей иногда используются другие средства. Например, если марш-
рутный протокол использует туннели с IP-инкапсуляцией, этот про-
токол должен проинформировать RSVP о наличии узлов, лишен-
ных поддержки RSVP. В отсутствии автоматических механизмов
°существляется ручная конфигурация.
ЭВМ с несколькими сетевыми интерфейсами
При работе с ЭВМ, имеющими несколько сетевых интерфейсов,
требуется выполнение ряда специальных правил. К такого рода
ройствам относятся и маршрутизаторы, которые поддерживают
ильные прикладные программы.
приложение, исполняемое на такой машине, должно явно ука-
ть через какой интерфейс осуществляется передача данного
540 Глава 4^
информационного потока, для того чтобы заменить интерфейс, за- ‘
данный по умолчанию системой.
• Посылка данных
Приложение отправителя использует API вызов для декларации
характеристик его информационного потока для RSVP. Этот вызов
может опционно включать локальный IP-адрес отправителя. Если
он установлен приложением, этот параметр должен быть адресом
интерфейса для отправки информационных пакетов, в противном
случае, используется системный интерфейс по умолчанию.
Процесс RSVP ЭВМ посылает затем приложению сообщения
Path только через специфицированный интерфейс.
33. Выполнение резервирования
Приложение-получатель использует вызов API для запроса ре-
зервирования RSVP. Этот вызов может опционно включать локаль-
ный IP-адрес получателя, т.е., адрес интерфейса для получения ин-
формационных пакетов. В случае мультикаст-сессий это интерфейс,
к которому подключилась группа. Если этот параметр опущен, сис-
тема использует значение по умолчанию.
Процесс RSVP должен посылать сообщения Resv приложению
через специфицированный интерфейс. Однако когда приложение
исполняется в маршрутизаторе, а сессия является мультикастной,
возникает более сложная ситуация. Предположим, что в этом слу-
чае приложение получателя присоединяется к группе через интер-
фейс lapp, который отличается от Isp - ближайшего интерфейса по
пути к отправителю. Теперь имеется два возможных пути для муль-
тикастной маршрутизации при доставке информационных пакетов
приложению. Процесс RSVP должен определить, какой вариант выб-
рать, просмотрев состояние прохода и решив, какой из входных ин-
терфейсов следует использовать для посылки сообщений.
1. Протокол мультикастной маршрутизации может создавать
отдельные ветви дерева доставки к lapp. В этом случае будет иметься
состояние прохода для обоих интерфейсов Isp и lapp. Состояв#®
прохода в lapp должно только соответствовать резервированию ло*
кального приложения. Оно должно быть помечено процессом RSVP
как «Local_only». Если существует состояние прохода «Ьоса1__оп1У*
для lapp, сообщение Resv должно посылаться через lapp. Замети#,
что имеется возможность для блоков состояния прохода Isp и 1аЙ?
иметь один и тот же следующий узел, если в маршрут вклиниваете^,
область, не поддерживающая RSVP.
2. Протокол мультикастной маршрутизации может переадр®^
вать данные в пределах маршрутизатора от Isp к lapp. В это#
СеТи передачи данных. Метод доступа
541
случае 1арр появится в списке выходных интерфейсов состояния
прохода Isp и сообщения Resv должны будут посылаться через Isp.
3. Когда сообщения Path и PathTear переадресованы, состояние
прохода, помеченное как «Local_Only», должно игнорироваться.
34. Будущая совместимость
В будущем для существующих классов могут быть описаны
новые объекты C-Типа, а могут быть определены и новые клас-
сы объектов. Крайне желательно использовать такие объекты в
Интернет в рамках старых приложений, которые их не распознают.
К сожалению, это возможно с заметными ограничениями. Здесь
нужно придерживаться следующих правил (“Ь” означает бит).
1. Неизвестный класс
Существует три возможных способа, чтобы приложение RSVP
могло работать с объектом неизвестного класса. Этот выбор опреде-
ляется двумя старшими битами октета Class-Num.
• Class-Num = Obbbbbbb. Все сообщение должно быть отброше-
но и возвращена ошибка «Unknown Object Class» (неизвестный класс
объекта).
• Class-Num == lObbbbbb. Узел должен игнорировать объект без
дальнейшей пересылки или отправки сообщений об ошибке.
• Class-Num = llbbbbbb. Узел должен игнорировать объект, но
может переадресовать его далее без модификации со всеми сообще-
ниями, вызванными данным запросом.
Ниже приведены более детализированные правила для работы с
нераспознанными классами объектов Class-Num вида llbbbbbb:
> 1. Такие объекты неизвестного класса, включенные в сообщения
PathTear, ResvTear, PathErr или ResvErr, должны немедленно пере-
адресовываться в рамках того же сообщения.
2. Такие объекты неизвестного класса, включенные в сообщения
Path или Resv, должны быть записаны в соответствующие состоя-
ния и посланы в сообщениях обновления, сопряженных с указан-
ным состоянием.
3. Когда формируется обновление Resv путем объединения не-
скольких запросов резервирования, сообщение обновления должно
включать в себя объединение объектов не узнанных классов всех
компонентов запроса. В этом объединении каждый такой объект
Может присутствовать только один раз. %
4. Исходный порядок таких объектов необязательно сохранять.
Днако формируемое сообщение должно подчиняться общим пра-
вилам в отношении упорядочения объектов.
542
Гпава 4
Хотя объекты с неизвестным классом не могут объединяться,
эти правила позволяют передать их вплоть до узла, который смо-
жет их распознать и объединить.
2. Неизвестный С-тип для известного класса
Появление объекта с неизвестным С-типом приведет к выбра-
сыванию всего сообщения и генерации сообщения об ошибке (ResvErr
или PathErr). Сообщение об ошибке будет включать Class-Num и
C-Туре, который был не распознан. Оконечная система, которая от-
правила нераспознанное сообщение может использовать эту инфор-
мацию, чтобы попытаться повторить попытку с объектом другого
С-типа.
Объекты определенных классов (FLOWSPEC, ADSPEC и
POLICY_DATA) не прозрачны для RSVP, который просто передает
их системе управления трафиком или другим модулям. В зависи-
мости от внутренних правил любой из упомянутых модулей может
отвергнуть С-тип и информировать об этом RSVP-процесс. RSVP
должен тогда отвергнуть такое сообщение и проинформировать об
ошибке.
35. Интерфейсы RSVP
RSVP в маршрутизаторе имеет интерфейсы для управления тра-
фиком, а в ЭВМ — интерфейсы для приложений (т.е., API), а также
для управления трафиком (если такой контроль предусмотрен).
35.1. Интерфейс приложения RSVP
Структура реального интерфейса может зависеть от операцион-
ной системы. Некоторые из вызовов предполагают асинхронную
присылку информации.
• Регистрация сессии
Вызов: SESSION( DestAddress , Protocolld, DstPort
[ , SESSION_object ]
[ , Upcall—Proc_addr ]) -> Session-id
Этот вызов инициирует RSVP обработку сессии, заданной
DestAddress, Protocolld и, возможно, номером порта DstPort. В случае
успеха вызов SESSION возвращает локальный идентификатор сессии
Session-id, который может использоваться при последующих вызовах.
Параметр Upcall_Proc_addr определяет адрес вызова процедуры
получения кода ошибки или информации о событии. Параметр.
SESSION-Object включен для организации механизма поддержки:
более общего описания сессии («обобщенный порт назначения»)-!
Обычно SESSION_object опускается. > *
Сетн передачи данных. Метод доступа
543
• Определение отправителя
Вызов: SENDER( Session-id
[ , Source_Address ] [ , Source_Port ]
[, Sender_Template ]
[ , Sender Tspec ] [, Adspec ]
[ , DataTTL ] [ , Policy data ])
Отправитель использует этот вызов, чтобы определить или мо-
дифицировать атрибуты информационного потока. Первое обраще-
ние к SENDER для регистрации сессии как “Session-id” заставит
RSVP начать рассылку сообщений Path для данной сессии; после-
дующие вызовы будут модифицировать информацию о проходе.
Параметры SENDER интерпретируются следующим образом:
• Source-Address. Это адрес интерфейса через который будут
посылаться данные. Если этот параметр пропущен, будет использо-
ваться интерфейс по умолчанию. Этот параметр необходим для ЭВМ
с двумя и более сетевыми интерфейсами.
• Source_Port. Это UDP/TCP порт, через который будут посы-
латься данные.
• Sender Template. Этот параметр включен для поддержки ме-
ханизма более общего описания отправителя («обобщенный порт
источника»). Обычно этот параметр может быть опущен.
• Sender_Tspec. Этот параметр описывает трафик потока; смот-
ри [RFC 2210].
• Adspec. Этот параметр может быть специфицирован для ини-
циализации вычисления свойств QoS вдоль пути; смотри [RFC 2210].
• Data TTL. Это IP TTL параметр, который несут в себе инфор-
мационные пакеты. Он необходим, чтобы гарантировать, что сообще-
ния Path не будут выходить за пределы зоны мультикастинг-сессии.
• Policy-data. Это опционный параметр несет в себе управляю-
щую информацию для отправителя. Эта информация может задавать-
ся системной службой и для приложения может быть недоступной.
RESERVE
Вызов: RESERVE(session-id, [ receiver_address , ]
[ CONF flag, ] [ Policy data, ]
style, style-dependent-parms)
Получатель использует этот вызов, для того чтобы осуществить
Или модифицировать резервирование для сессии “session-id”. Пер-
Вое обращение RESERVE инициирует периодическую передачу сооб-
^ений Resv. Последующие вызовы RESERVE могут служить для
модификации параметров предыдущих обращений.
544
Гпава 4
Опционный параметр “receiver_address” может использоваться
получателем в маршрутизаторе или ЭВМ с несколькими сетевыми
интерфейсами. Это IP-адрес одного из интерфейсов узла. Флаг
CONFflag должен быть установлен, если желательно подтвержде-
ние резервирования. Параметр “Policy_data” специфицирует управ-
ляющие данные получателя, в то время как параметр “style” указы-
вает на стиль резервирования. Остальные параметры зависят от сти-
ля; обычно они соответствуют спецификациям фильтра и flowspecs.
• RELEASE
Вызов: RELEASE(session-id)
Этот вызов удаляет состояние RSVP для сессии, указанной в
параметре session-id. Узел затем шлет соответствующие сообщения
отмены (teardown) и прекращает рассылку сообщений обновления
для session-id.
• Вызовы Error/Event (ошибка/событие)
Общая форма вызова имеет вид:
Обращение: <Upcall_Proc>() -> session-id, Info_type,
informationjparameters
«Upcall_Proc» представляет собой процедуру, чей адрес был дан
при вызове SESSION. Это обращение может произойти асинхронно
в любое время после вызова SESSION до вызова RELEASE и служит
для индикации ошибки или события.
В настоящее время имеется пять типов обращений, отличаю-
щихся параметром Info_type. Выбор информационных параметров
зависит от типа.
1. Info_type = PATH__EVENT
Обращение Path Event приводит к тому, что получение первого
сообщения Path для данной сессии, указывает приложению получа-
теля на наличие, по крайней мере, одного отправителя или на изме-
нение состояние прохода.
Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Inf ootype = PATHJEVENT,
Sender Tspec, Sender_Template
[ , Adspec ] [, Policy_data ]
Это обращение выдает спецификации Sender_Tspec, Sender Template,
Adspec и управляющую информацию из запроса Path. ,
2. Info type = RESV__EVENT -
Обращение Resv Event запускается в результате получения пер-
вого сообщения RESV, или как следствие модификации предшеству-
ющего состояния резервирования для данной сессии.
Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Qe-ти передачи данных. Метод доступа
545
Info_type = RESVEVENT,
Style, Flowspec, Filter_Spec_list
[, Policy_data ]
“Flowspec” - эффективное значение QoS, которое получено. Заме-
тим, что сообщение Resv (стиль FF) может вызвать несколько обра-
щений RESV_EVENT, по одному для каждого дескриптора потока.
3. Info__type = PATH ERROR
Событие Path Error индицирует ошибку в информации отправи-
теля, которая была специфицирована в запросе SENDER.
Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Info_type=PATH_ERROR,
Error_code, Error_value ,
Error_Node, Sender_Template
[, Policy_data_list ]
Параметр Error_code определяет ошибку, a Error_value может
нести в себе некоторую дополнительную (возможно системно-зави-
симую) информацию об ошибке. Параметр Error_Node специфици-
рует IP-адрес узла, который обнаружил ошибку. Параметр
Policy_data_list, если он присутствует, содержит любые объекты
POLICY DATA из неудачного сообщения Path.
4. Info_type = RESV ERR
Событие Resv Error указывает на ошибку в сообщении резерви-
рования, в формирование которого приняло участие данное прйло-
жение.
Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Info_type = RESV_ERROR,
Error_code, Error_value ,
ErrorNode , Error_flags ,
Flowspec, Filter_spec_list
[, Policy_data_list ]
Параметр Error_Node специфицирует IP-адрес узла, который об-
наружил данное событие.
Имеется два флага Errorflags:
- InPlace
Этот флаг может быть равен 1 при ошибке контроля доступа
Для индикации наличия резервирования в узле, где произошла ошиб-
ка. Этот флаг устанавливается при ошибке и транспортируется со-
°бЩениями ResvErr.
“ NotGuilty
Зак. Ns 34зо Семенов
546 Главам
Этот флаг может быть равен 1 для ошибки при контроле досту.
па для индикации того, что запрошенная получателем специфика-
ция flowspec оказалась меньше той, которая вызвала ошибку. Этот
флаг устанавливается API получателя.
Filter_spec_list и Flowspec содержат соответствующие объекты
из ошибки дескриптора потока. List_count специфицирует число
FILTER SPECS в списке Filter spec list. Параметр Policy datajist
содержит любые объекты POLICY DATA из сообщения ResvErr.
5. Info_type = RESV CONFIRM
Событие подтверждение указывает, что получено сообщение
ResvConf.
Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Info_type = RESV_CONFIRM,
Style, List_count,
Flowspec, Filter spec list
[ , Policy data ]
Параметры интерпретируются также как и для отклика Resv;
Error. J
Хотя сообщения RSVP, указывающие на события path или resv
могут приходить периодически, API должно послать соответствую-
щие асинхронные отклики приложению только на первое из них
или при изменении полученной информации. Все события, сопря-
женные с ошибками или подтверждениями должны доводиться до
сведения приложения.
36. Интерфейс управления трафиком RSVP
Трудно представить общий интерфейс для управления трафиком, ?
так как детали установления резервирования сильно зависят от
технологии реализации канального уровня в интерфейсе. .4
Объединение RSVP-резервирований необходимо из-за мультика- ;
стной доставки данных, при которой информационные пакеты раз-
множаются для отправки последующим узлам. В каждой такой
точке размножения, RSVP должен объединять запросы резервирова-
ния от последующих узлов путем выбора «максимума» их специ-
фикаций flowspecs. В данном маршрутизаторе или ЭВМ может при-
сутствовать несколько таких точек объединения/размножения.
1. IP-уровень
Мультикастная IP рассылка выполняет разветвление потока на
IP-уровне. В этом случае RSVP должен объединять резервирования,
соответствующих выходных интерфейсов для последующей отправ- 2
ки запроса резервирования далее.
СеТи передачи данных. Метод доступа 547
2- Сеть
Размножение пакетов может иметь место и после узла, например,
широковещательных сетях, в переключателях канального уровня
или системе маршрутизаторов, не поддерживающих RSVP. В этих
случаях RSVP должен объединять запросы резервирования от ряда
предыдущих узлов, для того чтобы выполнить резервирование для
одного выходного интерфейса
3. Драйвер канального уровня
В технологиях с множественным доступом размножение паке-
тов может осуществляться на уровне канального драйвера или се-
тевого интерфейса.
В общем, эти сложности не влияют на реализацию протокола
RSVP, нужно только четко определить какие запросы резервирова-
ния следует объединить. Может оказаться желательным организо-
вать реализацию RSVP из двух блоков: ядро, которое выполняет
канально-независимую обработку и адаптационный уровень, учиты-
вающий канальную специфику.
* Выполнение резервирования
Вызов: TC_AddFlowspec( Interface, TCFlowspec,
TC Tspec, TC_Adspec, PoliceFlags)
-> RHandle [, Fwd_Flowspec]
Параметр TC_Flowspec определяет желательное значение QoS
для управления доступом. Его значение вычисляется как макси-
мум совокупности спецификаций flowspecs для последующих узлов
(см. ниже описание вызова Compare_Flowspecs). Параметр TC_Tspec
определяет эффективное значение спецификации отправителя Tspec
Path Te. Параметр ТС_Adspec задает спецификацию Adspec. Пара-
метр Police Flags несет в себе три флага E_Police_Flag, MPoliceFlag
и B_Police_Flag.
1 Если данный вызов оказался успешным, он устанавливает но-
вый канал резервирования, соответствующий RHandle; в против-
ном случае, он возвращает код ошибки. Код RHandle используется
вызывающей программой для будущих ссылок на это резервирова-
ние. Если служба управления трафиком модифицирует flowspec,
вызов вернет модифицированный объект FwdFlowspec.
Модификация резервирования
Вызов: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,
TCjTspec, TC_Adspec, Police flags)
[ -> Fwd Flowspec ]
18*
54S
Гпава
Этот вызов используется для модификации существующего ре,
зервирования. TC_Flowspec передается блоку контроля разрешения.
Если разрешения нет, текущая спецификация flowspec остается в
силе. Соответствующие спецификации фильтров, если таковые име>
ются, остаются не затронутыми. Другие параметры определены так.?
же как и в TC_AddFlowspec. Если система модифицирует flowspec,
вызов вернет также модифицированный объект Fwd_Flowspec.
* Уничтожение спецификации Flowspec
Вызов: TC_DelFlowspec( Interface, RHandle )
Этот вызов ликвидирует существующее резервирование, включая
спецификацию flowspec и все сопряженные спецификации фильтров?
* Добавление спецификации фильтра
Вызов: TC_AddFilter( Interface, RHandle,
Session , FilterSpec ) -> FHandle S
Этот вызов добавляет новую спецификацию фильтра для резерв
вирования, заданного RHandle. Запрос посылается после успешногс|
вызова TC_AddFlowspec. Этот вызов возвращает дескриптор фильтр
pa FHandle. |
• Уничтожение спецификации фильтра
Вызов: TC_DelFilter( Interface, FHandle ) i
Этот вызов используется для удаления какого-либо фильтра*;
идентифицируемого FHandle.
• Модификация OPWA ;
Вызов: TC_Advertise( Interface, Adspec,
Non RSVP Hop flag ) -> New Adspec
Этот вызов используется при OPWA и служит для вычисления,
выходной спецификации New_Adspec заданного интерфейса. Бито-j
вый флаг Non_RSVP_Hop_flag должен устанавливаться в случае
когда демон RSVP обнаруживает, что предшествующий узел содер-1
жит один или более маршрутизаторов, не поддерживающих RSVP*#
TC_Advertise вставит эту информацию в New_Adspec для оповеще-
ния обнаружения такого узла. <
* Запрос резервирования
Обращение (отклик): TC_Preempt() -> RHandle, Reason_code
Для того чтобы выдать новый запрос резервирования, модули
контроля разрешения и управления могут уже осуществить выделе-
ние квот для одно или двух существующих резервирований. Это
вызовет отклик TC_Preempt() на каждое такое резервирование, от-
правляя дескриптор резервирования RHandle и субкод причины.
И'
1 £0
Сети передачи данных. Метод доступа 549
37. Интерфейс маршрутизации RSVP
Реализация RSVP нуждается в следующей поддержке со сторо-
ны механизма маршрутизации узла.
• Запрос маршрута
Для пересылки сообщений Path и PathTear процесс RSVP дол-
жен быть способен запрашивать процесс маршрутизации с целью
получения маршрутных данных.
Ucast_Route_Query( [ SrcAddress, ] DestAddress,
Notify_flag ) -> Outlnterface
Mcast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag )
- > [ Incinterface, ] Outlnterface list
В зависимости от протокола маршрутизации запрос может зави-
сеть или нет от SrcAddress, т.е., от IP-адреса ЭВМ-отправителя, ко-
торый является также IP-адресом источника сообщения. Incinterface
характеризует интерфейс, через который ожидается прибытие паке-
та. Некоторые мультикастные протоколы маршрутизации могут не
выдавать этот адрес. Если флаг Notify_flag = True, блок маршрути-
зации отправит сообщение о непреднамеренном изменении маршру-
та, если такое изменение произойдет.
Мультикастный маршрутный запрос может вернуть пустой спи-
сок Outlnterface_list, если за оговоренным маршрутизатором нет ни
одного получателя. Запрос маршрутной информации может вернуть
сообщение “No such route” (такой маршрут отсутствует) возможно,
в результате временной рассогласованности (например, сообщение
Path или PathTear для запрошенного маршрута не дошло). В лю-
бом случае локальное состояние должно быть актуализовано так,
как это требуется в запросе, который не может быть переслан далее.
* Сообщение об изменении маршрута
При маршрутном запросе с флагом Notify_flag = True, процесс
маршрутизации может послать асинхронное сообщение процессу
RSVP, который уведомляет об изменении определенного маршрута.
Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
Outlnterface
Mcast_Route_Change() -> [ SrcAddress, ] DestAddress,
[ Incinterface, ] Outlnterface list
Обнаружение списка интерфейсов
RSVP должен быть способен выяснить, какой реальный и вир-
туальный интерфейсы являются активными, а также их IP-адреса.
Должна быть предусмотрена возможность логической дезакти-
ВаЦии интерфейса для RSVP. Когда интерфейс дезактивирован, со-
550 Гпава 4
общения Path не должны проходить через данный интерфейс, еслц
сообщение RSVP получено, оно должно быть отброшено (возможно,
с соответствующей записью в журнале операций).
38. Пакетные I/O интерфейсы RSVP
Реализация RSVP нуждается в следующей поддержке со сторо-
ны систем ввода/вывода пакетов и со стороны механизма переадре-
сации узла.
Пакеты, полученные для IP-протокола (код 46) но не адресован-
ные узлу, должны быть переправлены программе RSVP для последу-
ющей обработки. Сообщения RSVP переправляемые таким образом
включают сообщения Path, PathTear и ResvConf. Эти типы сообще-
ний несут в себе IP-опцию оповещение маршрутизатора (Router Alert),
которая может быть использована для выделения этих пакетов в
высокоскоростном канале переадресации. В качестве альтернативу,
узел может перехватывать все пакеты с кодом протокола 46.
В маршрутизаторе или ЭВМ с несколькими сетевыми интерфей-
сами идентификация интерфейса (реального и виртуального), через
который получено заданное сообщение, также как IP-адрес источни-
ка и TTL, с которым оно получено, должна быть также доступна;,
для процесса RSVP.
RSVP должен быть способен обеспечить посылку дейтограммы
через специальный выходной интерфейс (реальный или виртуаль-
ный) в обход обычного механизма маршрутизации. Виртуальным
каналом может быть, например, мультикастный туннель.
RSVP должен уметь специфицировать IP-адрес отправителя и TTL,
которые могут использоваться при посылке сообщений Path. RSVP
должен быть способен вызвать посылку сообщения Path, PathTear и
ResvConf с опцией оповещения маршрутизатора (Router Alert).
39. Манипуляции, зависящие от вида услуг
Flowspecs, Tspecs и Adspecs являются объектами, совершенно
недоступными для RSVP; их содержимое определено в документа^
спецификации услуг. Для того чтобы манипулировать этими объек-
тами процесс RSVP должен иметь в своем распоряжении следую-
щие программы, зависящие от типа услуг.
* Сравнение спецификаций потоков
Compare_Flowspecs( Flowspec_l, Flowspec_2 ) -> result_code
Возможный результат операции result_codes указывает: flowspecs
равны, Flowspec l меньше, Flowspec_2 больше, flowspecs совместимы И
можно вычислить LUB, или flowspecs не совместимы. Заметим, что,
сравнивая две спецификации, мы косвенно сопоставляем Tspecs, кото-
Сеги передачи данных. Метод доступа
551
рые оНИ с°ДеРжат’ Хотя процесс RSVP не может сам осуществить
разбор flowspec с целью извлечения Tspec, он может использовать вы-
зов процедуры CompareFlowspecs для косвенного вычисления ResvTe.
• Сравнение LUB Flowspecs
LUB_of_Flowspecs( Flowspec_l, Flowspec_2 ) -> FlowspecLUB
• Вычисление GLB Flowspecs
GLB_of_Flowspecs( Flowspec_l, Flowspec_2 ) -> Flowspec GLB
• Сравнение Tspecs
Compare_Tspecs( Tspec_l, Tspec_2 ) -> result code
Возможным результатом процедуры result_codes может быть:
Tspecs равны или Tspecs не равны.
• Сумма Tspecs
Sum_Tspecs( Tspec_l, Tspec_2 ) -> Tspec__sum
Этот вызов используется для вычисления Path_Te.
40. Определения объектов
С-типы определены для двух семейств адресов Интернет IPv4 и
IPv6. Для работы с другими адресными семействами можно легко
определить новый С-тип. Все неиспользуемые поля должны запол-
няться нулями и игнорироваться при получении. Ниже представле-
ны форматы объектов.
Класс сессии
• Объект IPv4/UDP SESSION. Класс = 1, С-тип = 1 (рис.
4.4.6.6.12)
О 8 16 24 31
Адрес места назначения Ipv4 (DestAddress; 4 байта)
Протокол id Флаги Порт назначения (DstPort)
Рис. 4.4.6.6.12. Формат объекта SESSION IPv4/UDP
• Объект IPv6/UDP SESSION. Класс = 1, C-Тип = 2 (рис.
4.4.6.6.13).
О 8 16 24 31
Адрес места назначения Ipv6 (DestAddress; 16 байта)
Протокол id Флаги Порт назначения (DstPort) •
Рис. 4.4.6.6.13. Формат объекта SESSION IPvS/UDP
552
Гпэвэ
DestAddress
Уникастный или мультикастный IP-адрес места назначения сес-
сии. Это поле не должно быть равно нулю.
Протокол Id
Идентификатор IP-протокола для потока данных. Это поле не
должно быть равно нулю.
Флаги 0x01 = E Police flag
Флаг E Police используется в сообщениях Path для определения
эффективного «края» сети, с целью организации управления трафи-
ком. Если ЭВМ отправитель сама не способна осуществлять управ-
ление трафиком, она установит этот бит в сообщениях Path, кото- ;
рые посылает. Первый узел, где имеется возможность управления
трафиком (если это требуется), RSVP установит этот флаг равным
нулю. ”
DstPort
UDP/TCP порт места назначения сессии. Допустимо значение
нуль, означающее отсутствие порта.
Класс RSVP_HOP
Объект IPv4 RSVP_HOP. Класс = 3, С-тип = 1 (рис. 4.4.6.6.14)>
0____________8_____________16____________24_________31
IPv4 Адрес Следующего/Предыдущего узла
Дескриптор логического интерфейса (LIH)
Рис. 4.4.6.6.14. Формат объекта RSVP_HOP IPv4
Объект IPv6 RSVPHOP: Класс = 3, С-тип = 2. Формат иденти-
чен показанному выше, за исключением того, что поле адреса в
четыре раза длиннее.
Этот объект несет в себе IP-адрес интерфейса, через который пос-
ледний RSVP-узел переслал это сообщение. Дескриптор логическо-
го интерфейса LIH (Logical Interface Handle) используется, для того
чтобы различать логические выходные интерфейсы. Узел, получая .
LIH в сообщении Path, запоминает его величину и возвращает его в
объектах НОР последующих сообщений Resv, посланных узлу, ко-
торый сформировал ЫН. ЫН должен быть тождественно равен нулю».
если не существует дескриптора логического интерфейса.
Класс INTEGRITY. INTEGRITY класс = 4.
Класс TIME_VALUES TIME VALUES класс = 5, С-тип = 1-
Период обновления. Период таймаута обновления R, исполь-
зованного для генерации этого сообщения (в миллисекундах).
Сети передачи данных. Метод доступа 553
Класс ERROR_SPEC. Объект IPv4 ERROR_SPEC класс = 6,
С-тип = 1 (Рис. 4.4.6.6.14).
о _____________8_______________16_________ 24 31
IPv4 адрес узла, где произошла ошибка (4 байта)
Флаги Код ошибки Значение ошибки
Рис. 4.4.6.6.14. Формат объекта ERROR_SPEC IPv4
Объект IPv6 ERRORSPEC класс = 6, С-тип = 2 имеет формат
идентичный показанному выше, за исключением того, что поле ад-
реса в четыре раза длиннее.
Поле адрес узла, где произошла ошибка является IP-адресом
(IPv4 или Ipv6).
Флаги. 0x01 = InPlace
Это значение поля флаги используется только для объектов
ERROR SPEC в сообщении ResvErr. Если флаг = 1, это указывает,
что в узле, где произошла ошибка, установлено резервирование.
0x02 = NotGuilty
Это значение поля флаги используется только для объекта
ERROR SPEC в сообщении ResvErr. Это значение устанавливается
для интерфейса в прикладной программе получателя. Если флаг
имеет такой код, спецификация FLOWSPEC, которая вызвала ошиб-
ку, больше запрошенной получателем.
Код ошибки. Одно-октетное поле кода описания ошибки.
Значение ошибки. Двухоктетное поле, содержащее дополнитель-
ную информацию об ошибке. Его содержимое зависит от типа ошиб-
ки. Значения поля код ошибки и значение ошибки приведены ниже.
Класс SCOPE = 7.
Этот объект содержит список IP-адресов, использованных для
сообщений маршрутизации с произвольным выбором ртправителей
(wildcard) без петель. Адреса должны быть перечислены в возраста-
ющем порядке.
Объект IPv4 SCOPE. Класс = 7, С-тип = 1 (рис. 4.4.6.6.15).
IPv4 адрес источника (4 байта)
IPv4 адрес источника (4 байта)
Рис. 4.4.6.6.15. Формат объекта SCOPE IPv4
554 Глава 4
Объект Ipv6 SCOPE класс = 7, C-Тип = 2. Объект ймеет ту же
структуру, что и предыдущий, только для каждого адреса выделяет-
ся 16 байт.
• Объект STYLE. Класс = 8, С-тип = 1 (рис. 4.4.6.6.16).
Рис. 4.4.6.6.16. Формат объекта STYLE
Поле флаги: 8 бит. (Пока не определены)
Вектор опций: 24 бита. Этот набор битовых полей определяет
опции резервирования. Если в будущем будут добавлены новые
опции, нужно будет ввести соответствующие поля в вектор опций со
стороны младших разрядов. Если узел не распознает идентифика-
тор стиля, он может интерпретировать ту часть вектора опций, ко-,
торая ему известна, игнорируя новые незнакомые ему поля. Биты
вектора опций определены (слева направо) следующим образом:
19 бит: Зарезервировано
2 бита: контроль распределения
00b: Зарезервировано
01b: точное резервирование
10b: распределенное резервирование
11b: Зарезервировано
3 бита: Управление выбором отправителя
000b: Зарезервировано
001b: Произвольный выбор (Wildcard)
010b: Прямой выбор (Explicit)
011b — 111b: Зарезервировано
Младшие биты вектора опций определяются стилем:
WF 10001b 4
FF 01010b
SE 10010b
Класс FLOWSPEC = 9.
• Зарезервировано (устарело) объект flowspec. Класс = 9, С-тип = 1
• Объект Inv-serv Flowspec. Класс = 9, С-тип = 2
Содержимое и правила кодирования этого объекта описанье®
документах, подготовленных рабочей группой int-serv [RFC 2210].
• Объект IPv4 FILTER_SPEC. Класс = 10, С-тип = 1 (рис.
4.4.6.6.17).
0 8 16 24 31 Я
IPv4 адрес источника (SrcAddress; 4 байта)
/////////// , ////////////// Номер порта источника (SrcPort)
Рис. 4.4.6.6.77. Формат объекта FILTER_SPEC IPv4
Сети передачи данных. Метод доступа
555
Объект IPv6 FILTERSPEC. Класс = 10, С-тип = 2. Объект име-
ет ту же структуру, что и предыдущий, только для каждого адреса
выделяется 16 байт.
• Объект IPv6 Flow-label FILTER_SPEC. Класс = 10, С-тип = 3
(рис. 4.4.6.6.18).
Ipv6 адрес источника (SrcAddress; 16 байт)
/////////// Метка потока (24 бита)
Рис. 4.4.6.6.18. Формат объекта FILTER_SPEC IPv6
SrcAddress. Это поле характеризует IP-адрес источника для ЭВМ
отправителя. Его значение не должно быть равно нулю.
SrcPort. UDP/TCP номер порта отправителя, или нуль, указыва-
ющий на отсутствие порта.
Метка потока. 24-битовое поле метки потока, определенной, в
IPv6. Этот код может использоваться классификатором пакетов
для эффективной идентификации кадров, принадлежащих опреде-
ленному потоку данных (отправитель-> место назначения).
я
41. Коды и значения ошибки
Нижеприведенные коды ошибок могут встретиться в объектах
ERRORSPEC, и предназначены для пересылки оконечным систе-
мам. За исключением специально оговоренных случаев эти коды
могут использоваться только в сообщениях ResvErr.
• Код ошибки = 00. Подтверждение.
Это код зарезервирован для использования в объекте ERROR SPEC
сообщения ResvConf. Значение ошибки также будет равно нулю.
Код ошибки = 01. Отказ системы управления допуском.
Запрос резервирования отвергнут системой управления допус-
ком разрешением из-за недостатка ресурсов. Для этого кода ошиб-
ки 16 бит поля значение ошибки имеют формат:
ssur сссс сссс сссс
гДе биты имеют следующие значения:
556
М*.
Гпава 4
ss == 00.Младшие 12 бит содержат глобально-определенный суб.
код (значение приведены ниже).
ss = 10. Младшие 12 бит содержат организационно-специфичес-
кий субкод. Предполагается, что RSVP интерпретирует этот код
как обычное число.
ss = 11. Младшие 12 бит содержат субкод, зависящий от вида
услуг. Предполагается, что RSVP интерпретирует этот код как обычное
число.
Так как механизм управления трафиком может предлагать раз-
личные услуги, кодирование может включать в себя некоторые осо-
бенности используемой услуги.
и — 0. RSVP отвергает сообщение без модификации локально-
го состояния.
и == 1. RSVP может использовать сообщение для модифика-
ции локального состояния и для последующей пересылки. Это оз-
начает, что сообщение является информационным.
г Зарезервированный бит, должен быть равен нулю.
сссс сссс сссс. 12 битовый код.
Следующие глобально-заданные субкоды могут появиться в млад-
ших 12 битах, когда ssur = 0000:
Субкод = 1.
Субкод = 2
Субкод = 3
Предел по задержке не может быть обеспечен.
Запрашиваемая полоса пропускания недоступна.
MTU в flowspec больше чем MTU интерфейса.
• Код ошибки = 02. Конфликт с политикой управления
(Policy Control failure). Сообщение резервирования или path было
отвергнуто по административным причинам, например, не выполнен
ны условия аутентификации, недостаточная квота и т.д.. Этот код
ошибки может появиться в сообщении PathErr или ResvErr. Содер-
жимое поля значение ошибки должно быть определено в будущем.
• Код ошибки = 03. Нет информации о проходе для этого
сообщения Resv. Нет состояния прохода для данной сессии. Сооб* г
щение Resv не может быть переслано.
• Код ошибки = 04. Нет информации отправителя для этого
сообщения Resv. Имеется состояние прохода для этой сессии, но
оно не включает в себя записи отправителя, соответствующей деск-
риптору потока, который содержится в сообщении Resv. Сообщение
Resv не может быть переслано.
Сети передачи данных. Метод доступа
557
. Код ошибки = 05. Конфликт со стилем резервирования.
Стиль резервирования конфликтует со стилем существующего со-
стояния резервирования. Поле значение ошибки содержит младшие
16 бит вектора опций существующего стиля, с которым произошел
конфликт. Сообщение Resv не может быть переслано.
• Код ошибки = 06. Неизвестный стиль резервирования.
Сообщение Resv не может быть переслано.
• Код ошибки = 07. Конфликт портов места назначения.
Появились сессии для одного и того же адреса места назначения с
нулевым и ненулевым значением полей порта назначения. Этот
код ошибки может появиться в сообщении PathErr или ResvErr.
• Код ошибки = 08. Конфликт портов отправителя. Для
одной и той же сессии имеются нулевые и ненулевые порты отпра-
вителя в сообщениях Path. Этот код ошибки может появиться только
в сообщении PathErr.
• Код ошибки = 09, 10, 11 Зарезервировано
• Код ошибки = 12 Привилегированное обслуживание.
Запрос обслуживания, определенный объектом STYLE, и дескриптор
потока были административно перехвачены.
• Код ошибки = 13. Неизвестный класс объекта. Значение
ошибки содержит 16-битовый код, состоящий из (Class-Num, С-тип)
неизвестного объекта. Этот код ошибки должен быть послан толь-
ко в случае, когда RSVP намеревается отвергнуть сообщение, как
это определено старшими битами Class-Num. Этот код ошибки мо-
жет появиться в сообщении PathErr или ResvErr.
• Код ошибки = 14. Неизвестный С-тип объекта. Значение
ошибки содержит 6-битовый код, состоящий из (Class-Num, С-тип)
объекта.
Код ошибки = 15-19. Зарезервировано
Код ошибки = 20. Зарезервировано для API. Поле знаке'
Ние ошибки содержит код ошибки API, которая была обнаружена
Синхронно и о которой необходимо уведомить систему соответ-
СТвУющим откликом.
558 Гпава 4
• Код ошибки = 21. Ошибка управления трафиком. Запрос
управления трафиком не прошел из-за формата или содержимого
параметров запроса. Сообщения Resv или Path, которые инициировав
ли вызов, не могут быть пересланы, повторные вызовы бесполезны.
Для этого кода ошибки 16 бит поля значения ошибки имеют
формат: ssOO сссс сссс сссс
Ниже представлены значения старших бит ss, как это определено
для кода ошибки 01. Следующие глобально-заданные субкоды могут
появляться в младших 12 битах (сссс сссс сссс), когда ss = 00.
• Субкод = 01. Конфликт сервиса. Попытка объединить два
несовместимых запроса обслуживания.
• Субкод = 02. Сервис не поддерживается. Управление тра-
фиком не может обеспечить запрашиваемый сервис или его прием-
лемую замену.
• Субкод = 03. Плохое значение Flowspec. Запрос неверного ’
формата или неприемлемые требования.
• Субкод = 04. Плохое значение Tspec. Запрос неверного
формата или неприемлемых требований.
• Субкод = 05. Плохое значение Adspec. Запрос неверного
формата и ли неприемлемые требования.
• Код ошибки = 22. Ошибка системы управления трафиком.
Модули управления; трафиком обнаружили системную ошибку. Зна-
чение ошибки будет содержать специфический для системы код, пре-
доставляющий дополнительную информацию об ошибке. Предпола-
гается, что RSVP не может интерпретировать его значение. •
• Код ошибки = 23 Системная ошибка RSVP
Поле значения ошибки предоставляет информацию об ошибке с
учетом конкретной реализации приложения. Предполагается, что
RSVP не может интерпретировать его значение. _
Вообще каждое сообщение RSVP переформируется в каждой
узле, а узел, в котором генерируется RSVP сообщение, несет ответ-
ственность за его правильную структуру. Аналогично, каждый У30*
должен контролировать корректность структуры полученного ММ
сообщения. В случае, когда из-за ошибки программы будет генери-
ровано сообщение с некорректным форматом, оконечная система
обязательно будет проинформирована об этом. Ошибка, скорее всерР»
будет зафиксирована локально и передана через механизмы упра®'
ления сетью.
Сети передачи данных. Метод доступа
559
Единственными ошибками формата сообщений, которые доводят-
ся до сведения оконечной системы, являются несоответствия версии.
Ошибки формата сообщения, которые могут быть зафиксирова-
ны локально и сообщены приложению RSVP, относятся к числу
специфических для данной реализации. Наиболее типичными из
них можно считать следующие:
• Неверная длина сообщения: Поле длины RSVP не соответ-
ствует реальной длине сообщения.
• Неизвестная или неподдерживаемая версия RSVP.
• Ошибка в контрольной сумме RSVP
• Ошибка в INTEGRITY
• Нелегальный тип сообщения RSVP
• Нелегальная длина объекта: не кратна 4, или меньше 4 байт.
• Адрес предыдущего/следующего узла в объекте НОР являет-
ся нелегальным.
• Неверный номер порта источника: Порт источника не равен
нулю в спецификации фильтра или шаблоне отправителя для сес-
сии с нулевым портом назначения.
• Отсутствует необходимый класс объекта
• Нелегальный класс объекта для данного типа сообщения.
• Нарушение регламентируемого порядка объектов
• Неверное число дескрипторов потока для данного типа сооб-
щения или стиля
• Неверный дескриптор логического интерфейса
• Неизвестный объект Class-Num.
• Адрес места назначения сообщения ResvConf не согласуется с
адресом получателя в объекте RESV_CONFIRM.
42. UDP-инкапсуляция
Реализации RSVP обычно требуют возможности выполнять лю-
бые сетевые операции ввода/вывода, т.е., посылать и получать IP-
Деитограммы, используя код протокола 46. Однако, некоторые важ-
ные классы вычислительных систем могут не поддерживать такого
Р°да операции. Для использования RSVP, такие ЭВМ должны ин-
напсулировать сообщения RSVP в UDP-дейтограммы.
Базовая схема UDP-инкапсуляции использует два предположения:
1 • Все ЭВМ способны посылать и получать мультикастные паке-
TbI, если требуется поддержка мультикастных адресов назначения.
2 .Маршрутизаторы первого/последнего узлов должны поддер-
живать RSVP.
560
Гпава 4
Пусть Ни является ЭВМ, которая нуждается в UDP-инкапсуля*
ции, a Hr ЭВМ, способная выполнять любые сетевые операции вво.
да/вывода. Схема UDP-инкапсуляции должна допускать RSVP вза-
имодействие ЭВМ типа Hr, Hu и маршрутизаторов (R).
Сообщения Resv, ResvErr, ResvTear и PathErr посылаются
уникастным адресам, полученным из состояний прохода или резер.
вирования узла. Если узел отслеживает, в каком из предыдущих
узлов и в каком интерфейсе нужна UDP-инкапсуляция, эти сообща
ния при необходимости могут быть посланы с применением UDp
инкапсуляции. С другой стороны, сообщения Path и PathTear могут
посылаться адресату с применением как мультикастных, так и уни-
кастных адресов.
В таблицах 4.4.6.6.1 и 4.4.6.6.2 приведены базовые правила
UDP-инкапсуляции сообщений Path и PathTear, для уникастных и
мультикастных DestAddress. Другие типы сообщений, которые ра-
ботают с уникастными адресами, должны следовать правилам из
табл. 4.4.6.6.1. Записи в колонке “RSVP посылает” имеют формат
“mode(destaddr, destport)”.
Полезно определить две разновидности UDP-инкапсуляций, одна
используется для посылки сообщений от Ни, другая от Hr и R. Это
делается, для того чтобы избежать двойной обработки сообщения
Таблица 4.4.6.6.1.
Правила UDP-инкапсуляции для уникастных сообщений Path и Resv
(D - уникастный адрес места назначения: R - маршрутизатор:
Raw - режим произвольных операций сетевого ввода/вывода, где
допускается работа программы вплоть до физического уровня.)
Узел RSVP посылает RSVP получает
Ни UDP(D/Ra,Pu) [1] UDP(D,Pu) и UDP(D,Pu’) [2L
Hr Raw(D) и, если (UDP), тогда UDP(D, Pu’) RAW() и UDP(D, Pu) [2] (игнорировать Pu’) __
R (интерфейс "а") Raw(D) и, если (UDP), тогда UDP(D, Pu’) RAW() и UDP(Ra, Pu) (игнорировать Pu’)
[1] Ни посылает уникастные сообщения Path либо по адресу D, если
D является локальным, либо по адресу Ra маршрутизатора
первого узла. Ra предполагается известным.
[2] Здесь D является адресом локального интерфейса, через котор*1*
приходит сообщение.
[3] Это предполагает, что приложение присоединилось к группе D-
СеТи передачи данных. Метод доступа 561
Таблица 4.4.6.6.2.
Правила UDP-инкапсуляции для мультикастных сообщений Path
Узел RSVP посылает RSVP получает
jhi UDP(G*,Pu) UDP(D,Pu’) [3] и UDP(G*,Pu)
Hr Raw(D,Tr) и, если (UDP), тогда UDP(D, Ри’) RAW() и UDP(G*, Pu) (игнорировать Pu’)
1Цинтерфейс а) Raw(D,Tr) и, если (UDP), тогда UDP(D, Ри’) RAW() и UDP(G*, Pu) (игнорировать Pu’)
получателем. На практике эти два вида инкапсуляций разделяются
по номерам UDP портов Ри и Ри’.
В таблицах используются следующие символы.
• D является портом назначения (DestAddress) конкретной сессии.
• G* является стандартным групповым адресом формата
224.0.0.14, т.е., группа ограничена пределами локальной сети.
• Ри и Ри’ являются стандартными UDP-портами для UDP-
инкапсуляции RSVP, с номерами 1698 и 1699.
• Ra равен IP-адресу интерфейса маршрутизатора “а”.
• Интерфейс маршрутизатора “а” локально доступен для Ни и Hr.
Маршрутизатор может определить, нуждается ли его интерфейс
X в UDP-инкапсуляции, контролируя поступление UDP-инкапсули-
рованных сообщений Path, которые были посланы либо G* (муль-
тикаст D) либо по адресу интерфейса X (уникаст D). Для данной
схемы существует один неудачный режим: если нет ни одной ЭВМ в
сети, которая бы выполняла функцию RSVP отправителя, тогда не
будет сообщений прохода (Path), чтобы запустить UDP-инкапсуля-
цию. В этом случае будет необходимо сконфигурировать UDP-ин-
капсуляцию для интерфейса локального маршрутизатора.
Когда получен UDP-инкапсулированный пакет, в большинстве
систем TTL не доступно для приложения. Процесс RSVP, который
получает UDP-инкапсулированное сообщение Path или PathTear
Должен использовать поле Send_TTL общего RSVP-заголовка для
извлечения значения TTL. В тех случаях, когда это по каким-либо
причинам не приемлемо, значение TTL может быть задано вручную
при конфигурации.
Мы предположили, что первый маршрутизатор, поддерживаю-
щий RSVP, подключен непосредственно к локальной сети. Суще-
ствует несколько подходов в случае, когда это не так.
562
Гпава 4
1. Hu может запускать как уникастные, так и мультикастные
сессии в UDP(Ra,Pu) с TTL==Ta. Здесь Та должно быть достаточным,
чтобы достичь R. Если Та слишком мало, сообщение Path не дойдет
до R. Если Та слишком велико, R и последующие маршрутизаторы
могут переправлять UDP-пакет до тех пор, пока не иссякнет запас
по TTL. Это включит UDP-инкапсуляцию между маршрутизатора-
ми в Интернет, возможно вызвав паразитный UDP трафик. ЭВМ Ни
должна быть непосредственно сконфигурирована с использованием
Ra и Та.
2. Конкретная ЭВМ локальной сети, соединенная с Ни может
считаться «транспортной ЭВМ RSVP». Транспортная ЭВМ будет
прослушивать (G*,Pu) и переправлять любое сообщение Path не-
посредственно R, хотя это и не будет маршрутом передачи данных.
Транспортная ЭВМ должна быть сконфигурирована с использова-
нием Ra и Та.
Библиография
[Baker96] Baker, F., «RSVP Cryptographic Authentication», Work in Progress.
[RFC 1633] Braden, R., Clark, D., and S. Shenker, «Integrated Services in the Internet Architecture: an Overview», RFC 1633, ISI, MIT, and PARC, June 1994.
[FJ94] Floyd, S. and V. Jacobson, «Synchronization of Periodic Rout- ing Messages», IEEE/АСМ Transactions on Networking, Vol. 2, No. 2, April, 1994.
[RFC 2207] Berger, L. and T. O’Malley, «RSVP Extensions forlPSEC Data Flows», RFC 2207, September 1997.
[RFC-2208] «Resource Reservation Protocol (RSVP) - Version 1. Applica- bility Statement».
[RFC-2209] «Resource Reservation Protocol (RSVP) - Version 1.Message Processing Rules»
[RFC 2113] Katz, D., «IP Router Alert ОрЦоп», RFC 2113, cisco Systems, February 1997.
[RFC 2210] Wroclawski, J., «The Use of RSVP with Integrated Services», RFC 2210, September 1997.
[RFC-2211] «Specification of the Controlled-Load Network Element Service»
[RFC-2212] «Specification of Guarantied Quality of Service»
[PolArch96] Herzog, S., «Policy Control for RSVP: Architectural Overview»* Work in Progress.
[OPWA95] Shenker, S. and L. Breslau, «Two Issues in Reservation Estab- lishment», Proc. ACM SIGCOMM ’95, Cambridge, MA, August 1995.
СеТи передачи данных. Метод доступа
563
4,4.7. Загрузочный протокол {ВООТР)
В больших сетях некоторые рабочие станции (например, Х-тер-
миналы) могут не иметь системного диска, а операционная система
и сетевое программное обеспечение могут загружаться через сеть.
Для этого рабочая станция должна иметь стартовую программу, за-
писанную в ПЗУ. Такое постоянное запоминающее устройство часто
производится на фирме, изготовившей эту рабочую станцию,, и по
этой причине не содержат информации ни об адресе сервера, ни даже
о своем IP-адресе. Выше был описан протокол RARP, который спосо-
бен решать подобные задачи для случая, когда сервер находится в
пределах данной локальной сети. Ведь RARP выдает широковеща-
тельный запрос на связном уровне, а он не ретранслируется маршру-
тизаторами. Более мощным средством для загрузки бездисковых
станций является протокол ВООТР (Bootstrap протокол, RFC-951, -
1048, -1532, -1395, -1542, -2132). ВООТР пригоден и для загрузки
бездисковых маршрутизаторов. ВООТР в качестве транспортного ис-
пользует UDP-протокол. ЭВМ-клиент (порт=68), которая хочет вос-
пользоваться ВООТР, посылает широковещательное сообщение (по
адресу = 255.255.255.255). Сервер (портов?) в отличии от случая
RARP не обязательно должен находиться в пределах данной ло-
кальной сети. В поле IP-адрес клиента будет записано 0.0.0.0, так
как клиент пока не знает своего адреса. Получив запрос через порт
67, маршрутизатор помещает свой IP-адрес в поле IP-адрес маршру-
тизатора (см. формат запроса на рис. 4.4.10.1) и пересылает запрос
действительному ВООТР-серверу, увеличив на 1 значение поля Нор#.
По пути к серверу может быть несколько маршрутизаторов (но обыч-
но не больше 3). Сервер не знает физического адреса клиента. Вос-
пользоваться ARP-запросом он не может, так как клиент пока не
знает своего IP-адреса и на ARP-запрос не откликнется. У сервера,
получившего запрос, имеется две возможности.
1. Проанализировать пакет, извлечь из него физический адрес
клиента и скорректировать ARP-таблицу.
2. Послать отклик, используя широковещательный адрес.
Так как программа загрузки находится на прикладном уровне,
и ей запрещено исправлять ARP-таблицы, реально доступен только
второй путь. Использование разных номеров портов для сервера и
клиента делает работу системы более эффективной. Когда отклик
сервера является широковещательным, это позволяет не прерывать
Работу прикладных программ, работающих с номерами портов, от-
личными от 68 (порт ВООТР-клиента). В ВООТР ответственность
За надежность связи лежит на ЭВМ-клиенте. При отсутствии от-
564
Гпава 4,
клика в отведенное время клиент повторяет ВООТН^запрос. На IP-
уровне, где данные не имеют контрольной суммы, целостность сооб-
щения не гарантирована. ВООТР требует, чтобы проверка конт-
рольной суммы обязательно проводилась на UDP-уровне (следует
заметить, что обычно это не является обязательным). Сервер читает
UDP-дейтограммы через порт 67. Для повышения надежности об-
менов, как правило, блокируется фрагментация дейтограмм.
Загрузка рабочих станций часто запускается броском напряже-
ния сетевого питания. При этом несколько ВООТР-процессов стар-
туют одновременно. Для того чтобы снизить вероятность столкно-
вений, величина времени тайм-аута выбирается случайно в интерва-
ле 0-4сек. После каждого повторного запроса это время удваивается. -
Верхнее значение тайм-аута равно бОсек. Для справок время заг-
рузки бездискового Х-терминала при благоприятных условиях мо-_
жет составлять около 20 сек.
ВООТР осуществляет загрузку в два этапа. На первом этапе .
ВООТР лишь снабжает клиента информацией, где лежит нужные
ему данные. Далее ЭВМ-клиент использует протокол TFTP для по-
лучения искомого загружаемого файла. ВООТР-сервер не обязательно:
должен работать на той же машине, где хранятся загружаемые фай-
IP-заголовок UDP-заголовок ВООТР запрос/отклик
20 ◄ 8 300 октетов
ииг-деи IUI pdMMd I Р-дейтогра мма ►
0 8 16 24 31
Операция Н-тип Hlen Нор#
Идентификатор операции
Секунды Не используется
IP-адрес клиента
Ваш IP-адрес
IP-адрес маршрутизатора
Аппаратный адрес клиента (16 октетов) у,
Имя ЭВМ-сервера (64 октета)
Имя BOOT-файла (128 октетов)
Специфическая информация поставщика (64 октета) *
Всего
300
октетов
Рис. 4.4.7.1. Формат сообщений ВООТР
Сети передачи данных. Метод доступа
565
ль1, Н° он должен знать их имена. Формат ВООТР-сообщений пред-
ставлен на рис. 4.4.7.1.
Поле операция^! говорит о том, что данное сообщение запрос, а
значение операция=2 указывает на то, что сообщение является от-
кликом. Поля Н-пгип и Hlen определяют тип используемого обору-
дования и длину аппаратного адреса (для Ethernet Н-тип=1, а
HLen=6). ЭВМ-клиент кладет в поле Нор# (число шагов) нуль.
Если ВООТР-сервер, получив запрос, решит передать его другой ЭВМ,
он увеличит значение этого поля на 1, и так далее. Поле идентифи-
катор операции содержит целое число, которое на бездисковых ма-
шинах позволяет связать в пары запросы и отклики. Поле секунды
хранит время с момента начала процедуры загрузки (BOOT).
ЭВМ-клиент заполняет все последующие поля, если она этой
информацией владеет, в противном случае поля обнуляются. Воз-
можность указания имени ВООТ(загрузочного)-файла позволяет
учесть индивидуальность конфигурации конкретной ЭВМ и поже-
лания относительно загружаемой операционной системы. Поле спе-
цифическая информация поставщика содержит информацию, которая
передается от сервера к ЭВМ-клиенту. Первые 4 октета этого поля
носят название «волшебное печенье» (magic cookie) и определяют
формат остальных субполей. Если в указанном поле имеется инфор-
мация, субполе волшебное печенье имеет значение 99.130.83.99. Вслед
за этим субполем следует последовательность субполей, содержа-
щих один октет тип, опционный октет длина и многооктетное суб-
поле значение. Стандарт предусматривает следующие разновиднос-
ти субполей:
Таблица 4.4.7.1. Разновидности субполей и их коды (BOOTPJ
Тип субноля Код су^иоля Длина субполя в октегак Содержимое субполя
Заполнитель 0 - Нули - используются для заполнения неиспользуемых полей
.Маска субсети 1 4 Маска субсети в локальной сети
время дня 2 4 Время дня по универсальной шкале
Маршрутиздусфы 3 N Список IP-адресов N/4 маршрутизаторов
временные Л1£рве£ы___~ 4 N 1 P-адреса N/4 временных серверов
сервер 5 N IP-адреса N/4 IEN116 серверов
Домеин-ССрвер 6 N IP-адреса N/4 DNS-серверов
J^fccepBep 7 N IP-адреса N/4 log-серверов
566 Гпава 4
Сервер квот 8 N IP-адреса N/4 серверов квот '
Сервер принтера 9 N IP-адреса N/4 серверов печати
Impress 10 N IP-адреса N/4 impress-серверов '
RLP-сервер 11 N IP-адреса N/4 RLP серверов
Имя ЭВМ 12 N N байтов имени ЭВМ-клиента ’
Размер Boot- файла 13 2 2-октетный размер boot-файла
Зарезервировано 128-254 - Зарезервировано для местного применения
Конец 255 - Конец списка "
Определены и другие субполя (RFC-1533), субполе конец (255) по-
мечает конец поля. Хотя маска субсети может быть получена с помо-
щью ICMP-запроса, стандарт требует, чтобы маска присылалась ВООТ-
сервером в ответ на каждый запрос, что исключает лишние ICMP-
сообщения. Маска субсети может быть записана в поле специфическая
информация поставщика, как это видно из рис. 4.4.7.1. Время дня
(тип=2) отсчитывается в секундах от 1-го января 1900 года. В новом
протоколе DHCP (Dynamic Host Configuration Protocol, RFC-1531, про-
токол динамического конфигурирования системы) размер поля специ:
фическая информация поставщика расширен до 312 байт.
4.4.8. Протоколы маршрутизации в сетях Internet
Основная задача сетей — транспортировка информации от ЭВМ-
отправителя к ЭВМ-получателю. В большинстве случаев для этого
нужно совершить несколько пересылок. Проблему выбора пути ре-
шают алгоритмы маршрутизации. Если транспортировка данных осу?
ществляется дейтограммами, для каждой из них эта задача решаете#
независимо. При использовании виртуальных каналов выбор пут#
выполняется на этапе формирования этого канала. В Интернет с егр
IP-дейтограммами реализуется первый вариант^ а в ISDN — второй^
Алгоритм маршрутизации должен обладать вполне определен-
ными свойствами: надежностью, корректностью, стабильностью, про-
стотой и оптимальностью. Последнее свойство не так прозрачно, каИ
это может показаться на первый взгляд, все зависит от того, по како-
му или каким параметрам производится оптимизация. Эта зада^
иногда совсем не проста даже для локальных сетей (смотри, напри-,
мер, рис. 4.4.8.1). Предположим, что поток данных между ЭВМ
D, соединенных через концентратор (К) весьма высок. Это окаяс#?
ощутимое влияние на скорость обмена между ЭВМ А и С. Но этот
факт довольно трудно выявить, находясь в ЭВМ А или С. Внешне э^О
проявится лишь как повышенная задержка и пониженная nponycfo
ная способность участка А-С. $
Сети передачи данных. Метод доступа
567
Рис. 4.4.8.1
Среди параметров оптимизации может быть минимальная за-
держка доставки, максимальная пропускная способность, минималь-
ная цена, максимальная надежность или минимальная вероятность
ошибки.
Алгоритмы маршрутизации бывают адаптивными и неадаптив-
ными. Вторые, осуществляя выбор маршрута, не принимают во вни-
мание существующую в данный момент топологию или загрузку
каналов. Такие алгоритмы называются также статическими. Адап-
тивные же алгоритмы предполагают периодическое измерение ха-
рактеристик каналов и постоянное исследование топологии марш-
рутов. Выбор того или иного маршрута здесь производится на осно-
вании этих измерений.
Практически все методы маршрутизации базируются на следую-
щем утверждении (принцип оптимальности). Если маршрутиза-
тор М находится на оптимальном пути от маршрутизатора I к
маршрутизатору J, тогда оптимальный путь от М к J проходит по
этому пути. Следствием принципа оптимальности является утвер-
ждение, что оптимальные маршруты от всех отправителей к общему
месту назначения образуют дерево, лишенное циклов (см. разделы
«Протокол OSPF»). Такое дерево может быть не единственным.
Главным параметром при маршрутизации пакета в Интернет
является IP-адрес его места назначения. Проблема оптимальной
маршрутизации в современном Интернет, насчитывающем уже бо-
Лее Десяти миллионов узлов, весьма сложна (полная таблица марш-
рутов может содержать 107! записей (здесь ! означает знак фактори-
а не выражение эмоций), что не по плечу не только сегодняш-
ним ЭВМ).
Обычный пользователь не задумывается и не должен задумы-
oif ЬСЯ Над‘ пР°^лемами маршрутизации, но даже ему иногда может
заться полезным понимать, что возможно, а что невозможно в
Интернет.
568
Гпава 4
IP делит все ЭВМ на маршрутизаторы и обычные ЭВМ (Host),
последние, как правило, не рассылают свои маршрутные таблицы.
Предполагается, что маршрутизатор владеет исчерпывающей иц.
формацией о правильных маршрутах (хотя это и не совсем так);
Обычная ЭВМ имеет минимальную маршрутную информацию (на.
пример, адрес маршрутизатора локальной сети и сервера имен).
Автономная система может содержать множество маршрутизато-
ров, но взаимодействие с другими AS она осуществляет только
через маршрутизатор, называемый пограничным (Border Gateway,
именно он дал название протоколу BGP). Пограничный маршру.
тизатор нужен лишь тогда, когда автономная система имеет более
одного внешнего канала, в противном случае его функции выпол-
няет порт внешнего подключения (Gateway). Если адресат дости-
жим более чем одним путем, маршрутизатор должен сделать вы-
бор, этот выбор осуществляется на основании оценки маршрутов-
кандидатов. Обычно каждому сегменту, составляющему маршрут,
присваивается некоторая величина — оценка этого сегмента. Каж-
дый протокол маршрутизации использует свою систему оценки
маршрутов. Оценка сегмента маршрута называется метрикой. Здесь
следует обратить внимание на то, что при выборе маршрута всем
сегментам пути должны быть даны сопоставимые значения мет-
рики. Недопустимо, чтобы одни сегменты оценивались числом шагов,
а другие — по величине задержки в миллисекундах. В пределах
автономной системы это обычно не создает проблем, ведь это зона
ответственности одного администратора. Но в региональных се-
тях, где работает много администраторов, проблема выбора метри-
ки может стать реальной трудностью. Именно по этой причине в
таких сетях часто используется вектор расстояния, исключающий
субъективность оценок метрики.
Помимо классической схемы маршрутизации по адресу места
назначения, часто используется вариант выбора маршрута отправи-
телем (данный вариант получил дальнейшее развитие при введе-
нии стандарта IPv6). В этом случае IP-пакет содержит соответствуй
ющий код опции и список промежуточных адресов узлов, который
он должен посетить по пути к месту назначения. u
Существуют и другие схемы, например, использующие широк#
вещательные методы адресации (flooding), где каждый приходя*
щий пакет посылается по всем имеющимся исходящим каналам»
за исключением того, по которому он получен. С тем чтобы ис~
ключить беспредельное размножение пакетов в заголовок вводит-
ся поле-счетчик числа шагов. В каждом узле содержимое поЯ*
уменьшается на единицу. Когда значение поля становится Раа'
Сети
передачи данных. Метод доступа
569
ным нулю, пакет ликвидируется. Исходное значение счетчика оп-
пеляется размером субсети. Предпринимаются специальные меры
против возможного зацикливания пакетов. Существует усовершен-
ствованная версия широковещательной маршрутизации, называе-
мая селективной широковещательной рассылкой. В этом алго-
ритме рассылка производится не по всем возможным направлени-
ям, а только по тем, которые предположительно ведут в правильную
сторону. Широковещательные методы не относятся к широко при-
менимым. Но они используются там, где нужна предельно возмож-
ная надежность, например в военных приложениях, когда весьма
вероятно повреждение тех или иных каналов. Данные методы мо-
гут использоваться лишь при формировании виртуального канала,
ведь они всегда обеспечивают наикратчайший путь, так как пере-
бираются все возможности. Если путь записывается в пакете, по-
лучатель может выбрать оптимальный проход и уведомить об этом
отправителя.
Большинство алгоритмов учитывают топологию связей, а не их
качество (пропускную способность, загрузку и пр.). Но существуют
подходы к решению проблемы статической маршрутизации, учиты-
вающие как топологию, так и загрузку (flow-based routing). В неко-
торых сетях потоки между узлами относительно стабильны и пред-
сказуемы. В этом случае появляется возможность вычислить опти-
мальную схему маршрутов заранее. Здесь на основе теории массового
обслуживания производится оценка средней задержки доставки для
каждой связи. Топология маршрутов оптимизируется по значению
задержки доставки пакета. Исходными данными при расчете счита-
ется описание топологии связей, матрица трафика для всех узлов
Т. (в пакетах в секунду) и матрица пропускных способностей кана-
лов В.. в битах в секунду. Задержка t для каждой из связей оцени-
вается по формуле
t. = 1/(Р*В.. - Т..),
гДе 1/р — среднее значение ширины пакета в битах, произведение
выражается в пакетах в секунду, a t измеряется в мсек. Сфор-
мировав матрицу t , можно получить граф кратчайших связей.
ак как вычисления производятся не в реальном масштабе време-
Ни, особых трудностей здесь не возникает.
Статические протоколы (примером реализации статических про-
токолов может служить первая версия маршрутизатора NetBlazer)
пРедполагают, что любые изменения в маршрутные таблицы вносит
администратор сети. Рассмотрим для примера сеть, изображенную
Ча Рис. 4.4.8.2.
570
Гпава 4
Рис. 4.4.8.2 Схема для иллюстрации методики составления
маршрутных таблиц.
G1, G2, G3 — Маршрутизаторы
Примитивная таблица маршрутизации для приведенного приме-
ра может иметь вид (для маршрутизатора G2):
Сеть-адресат
193.0.0.0
193.148.0.0
192.0.0.0
192.166.0.0
Маршрут к этой сети
Прямая доставка
Прямая доставка
Через адрес 193.0.0.1
Через адрес 193.148.0.7
Заметно сокращает размер маршрутной таблицы маршруты по
умолчанию. В этой схеме сначала ищется маршрут в таблицах, а
если он не найден, пакет посылается в узел, специально выбранный
для данного случая. Так, когда имеется только один канал за ру«
беж, неудачный поиск в таблице маршрутов по России означает, что
пакет следует послать по этому каналу и пусть там с ним разбирай
ются. Маршруты по умолчанию используются обычно тогда, когд&
маршрутизатор имеет ограниченный объем памяти или по какой-,
то иной причине не имеет полной таблицы маршрутизации. Марп^
рут по умолчанию может помочь реализовать связь даже при ошиФ
ках в маршрутной таблице. Это может не иметь никаких послед
ствий для малых сетей, но для региональных сетей с ограниченной
пропускной способностью такое решение может повлечь серьезнее
последствия. Экономия на памяти для маршрутных таблиц - ДУР^Л
ной стиль, который не доведет до добра. Например, из-за такой*
рода ошибки довольно долго пакеты из Ярославля в Москву шли
через США, я уже не говорю о случае, когда машины, размещенные^
соседних комнатах Президиума РАН, вели обмен через Амстердам
(правда, это было достаточно давно). Алгоритм выбора маршрут*
универсален и не зависит от протокола маршрутизации, которые
используется лишь для формирования маршрутной таблицы. ОН#0
сание алгоритма выбора маршрута представлено ниже: _
Сети передачи данных. Метод доступа
571
Извлечь IP-адрес (ID) места назначения из дейтограммы.
Вычислить IP-адрес сети назначения (IN)
if IN соответствует какому-либо адресу локальной сети,
послать дейтограмму по этому адресу;
else if IN присутствует в маршрутной таблице, то послать
дейтограмму к серверу, указанному в таблице;
else if описан маршрут по умолчанию, то послать дейтограмму
к этому серверу;
else выдать сообщение об ошибке маршрутизации.
Если сеть включает в себя субсети, то для каждой записи в
маршрутной таблице производится побитная операция <И> для ID
и маски субсети. Если результат этой операции совпадет с содержи-
мым адресного поля сети, дейтограмма посылается серверу субсети.
На практике при наличии субсетей в маршрутную таблицу добав-
ляются соответствующие записи с масками и адресами сетей. Ма-
шины одной й той же субсети не могут быть подключены к разным
интерфейсам маршрутизатора. При маршрутизации используется
только сетевая часть IP-адреса.
Одна из базовых идей маршрутизации заключается в том, чтобы
сконцентрировать маршрутную информацию в ограниченном числе
(в идеале в одном) узловых маршрутизаторов-диспетчеров. Эта за-
мечательная идея ведет к заметному увеличению числа шагов при
пересылке пакетов. Оптимизировать решение позволяет backbone
(опорная сеть), к которой подключаются узловые маршрутизаторы.
Любая AS подключается к backbone через узловой маршрутизатор.
«Прозрачные» backbone не работают с адресами класса С (все
объекты такой сети должны иметь один адрес, а для С-класса число
объектов слишком ограничено). «Прозрачные» мосты трудно диаг-
ностировать, так как они не следуют протоколу ICMP (команда
ping не работает, в последнее время такие объекты снабжаются
SNMP-поддержкой). За то они позволяют перераспределять нагруз-
ку через несколько маршрутизаторов, что невозможно для боль-
шинства протоколов.
В примере, приведенном на рис. 4.4.8.3, задача маршрутизации
Достаточно сложна. ЭВМ1,2 и ЭВМ6,1 можно связать многими пу-
тями: ЭВМ1,2 - GW1 - ЭВМ6,1; ЭВМ1,2 - GW2 - ЭВМ6,1; ЭВМ1,2
GWW3 ~ ЭВМ6’1; ЭВМ1’2 " GW4 " ЭВМ6,1; ЭВМ1,2 - GW1 -
^W2-GW3 -ЭВМ6Д ; и т.д. Трафик между двумя географически
изкими узлами должен направляться кратчайшим путем, вне за-
ЭйюгМ0СТИ от напРавления глобальных потоков. Так ЭВМ1,2 и
должны соединяться через GW1. Маршрутизация через опор-
572 ' Глава’4
Рис. 4.4.8.3.
ные сети (backbone) требует индивидуального подхода для каждого
узла. Администраторы опорных сетей должны согласовывать свой
принципы маршрутизации. Ситуация, когда узел не владеет исчер-
пывающей маршрутной информацией, в сочетании с использовани-
ем маршрутов по умолчанию может привести к зацикливанию па-
кетов. Например, если маршрут по умолчанию в GW1 (рис. 4.4.8.4)
указывает на GW2, а в GW2 на GW1, то пакет с несуществующим
адресом будет циркулировать между GW1 и GW2 пока не истечет
TTL (время жизни пакета). По этой причине желательно имет>
полную таблицу маршрутизации, и, если не вынуждают обстоятель-
ства, избегать использования маршрутов по умолчанию. }
Протоколы маршрутизации отличаются друг от друга тем, где
хранится, и как формируется маршрутная информация. Оптималь-
ность маршрута достижима лишь при полной информации обо всех
возможных маршрутах, но такие данные потребуют слишком большо-
го объема памяти. Полная маршрутная информация доступна ДЛЯ
внутренних протоколов при ограниченном объеме сети. Чаще пре-
ходится иметь дело с распределенной схемой представления марЦк
]5утной информации. Маршрутизатор может быть информирован лишь
о состоянии близлежащих каналов и маршрутизаторов. х
П’
Рис. 4.4.8.4.
4
Сети передачи данных. Метод доступа
573
В маршрутизаторе с динамическим протоколом (например, BGP-4)
резидентно загруженная программа-драйвер изменяет таблицы мар-
шрутизации на основе информации, полученной от соседних марш-
рутизаторов. В ЭВМ, работающей под UNIX и выполняющей функ-
ции маршрутизатора, эту задачу часто решает резидентная програм-
ма gated или routed (демоны). Последняя — поддерживаете только
внутренние протоколы маршрутизации.
Применение динамической маршрутизации не изменяет алго-
ритм маршрутизации, осуществляемой на IP-уровне. Программа-
драйвер при поиске маршрутизатора-адресата по-прежнему просмат-
ривает таблицы. Любой маршрутизатор может использовать два
протокола маршрутизации одновременно, один для внешних связей,
другой — для внутренних.
Любая автономная система (AS, система маршрутизаторов, ЭВМ
или сетей, имеющая единую политику маршрутизации) может выб-
рать свой собственный протокол маршрутизации.
Внутренний протокол маршрутизации IGP (Interior Gateway
Protocol) определяет маршруты внутри автономной системы. Наи-
более популярный IGP - RIP (Routing Information Protocol, RFC-
1058), разработан Фордом, Фулкерсоном и Белманом (фирма
XEROX). Существует более новый протокол OSPF (Open Shortest
Pass First, RFC-1131, -1245, -1247, -1253). Для взаимодействия мар-
шрутизаторов, используются внешние протоколы (EGP — Exterior
Gateway Protocols).
Одной из разновидностей EGP является протокол BGP (Border
Gateway Protocol, RFC-1268 [BGP-3], RFC-1467 [BGP-4]).
Протокол IGRP (Interior Gateway Routing Protocol) разработан
компанией CISCO для больших сетей со сложной топологией и сег-
ментами, которые обладают различной полосой пропускания и за-
держкой. Это внутренний протокол маршрутизации имеет некото-
рые черты сходства с OSPF.
IGRP использует несколько типов метрики, по одной на каждый
вид QOS. Метрика характеризуется 32-разрядным числом. В одно-
родных средах этот вид метрики вырождается в число шагов до
Цели. Маршрут с минимальным значением метрики является пред-
почтительным. Актуализация маршрутной информации для этого
протокола производится каждые 90 секунд. Если какой-либо мар-
щРУт не подтверждает своей работоспособности в течение 270 сек,
°н считается недоступным. После семи циклов (630 сек) актуализа-
Такой маршрут удаляется из маршрутных таблиц. IGRP ана-
/ТпИчно OSPF производит расчет метрики для каждого вида сервиса
U°S) отдельно.
4
574
Гпава 4
Протокол IDPR (InterDomain Policy Routing Protocol, RFC-1477,
>1479) представляет собой разновидность BGP-протокола. Прото-
кол IS-IS (Intermediate System to Intermediate System Protocol, RFC-
1195, -1142, -2763, -2966) является еще одним внутренним прото-
колом, который используется для маршрутизации CLNP
(Connectionless Network Protocol, RFC-1575, -1561, -1526, -1768).
IS-IS имеет много общего с OSPF. Смотри также бесклассовый про-
токол маршрутизации CIDR.
К сожалению, многие современные протоколы маршрутизации
не имеют встроенных средств аутентификации (контроля доступа),
что делает их уязвимыми для различных злоупотреблений.
В последнее время все больше людей обзаводятся компактными
переносимыми ЭВМ, которые они берут с собой в деловые поездки, и
хотели бы использовать в привычном режиме для работы в Интер-
нет. Конечно, можно заставить модем дозвониться до вашего мо-
демного пула в офисе, но это не всегда лучшее решение, как по
надежности, так и по цене. Пользователи с точки зрения их под-
вижности могут быть разделены на три группы:
• стационарные, работающие всегда на своем постоянном месте
в локальной сети
• мигрирующие, меняющие время от времени свое рабочее место в
рамках локальной сети или даже переходящие из одной LAN в другую.
• подвижные, перемещающиеся в пространстве и желающие ра-
ботать в процессе перемещения.
Предполагается, что все эти пользователи имеют свою постоян-
ную приписку к какой-то сети и соответствующий постоянный IP-
адрес (см. RFC-2794 ’’Mobile IP Network Access Identifier Extantion
for IPv4. P.Calhon, C.Perlins, March 2000). На рис. 4.4.8.5 показана
схема подключения подвижных пользователей к Интернет. В этой
схеме предполагается наличие в каждой области сети Интернет внеия.
него агента, обеспечивающего доступ к этой зоне подвижных ЭВМ
(на рисунке такой агент помечен надписью «чужая LAN»). Доступ,
может осуществляться через мобильную телефонную сеть. Пре диолам
гается также наличие соответствующего агента в «домашней» LAN»
куда стационарно приписана данная ЭВМ. Домашний агент.отслек
живает все перемещения своих пользователей, в том числе и тех,ктег
подключается к «чужим» LAN.
Когда к локальной сети подключается новый пользователь (нН
посредственно физически или через модем сотовой телефонной сети)#
он должен там зарегистрироваться. Процедура регистрации вклю-
чает в себя следующие операции:
Р*
Сети передачи данных. Метод доступа
575
Рис. 4.4.8.5. Схема подключения к Интернет подвижных объектов
1. Каждый внешний агент периодически широковещательно рас-
сылает пакет-сообщение, содержащее его IP-адрес. «Вновь прибыв-
шая ЭВМ» может подождать такого сообщения или сама послать
широковещательный запрос наличия внешнего агента.
2. Мобильный пользователь регистрируется внешним агентом,
сообщая ему свой IP- и МАС-адрес, а также некоторые параметры
системы безопасности.
3. Внешний агент устанавливает связь с LAN постоянной при-
писки зарегистрированного мобильного пользователя, сообщая не-
обходимую адресную информацию и некоторые параметры аутенти-
фикации.
4. Домашний агент анализирует параметры аутентификации и,
если все в порядке, процедура установления связи будет продолжена.
5. Когда внешний агент получает положительный отклик от
домашнего агента, он сообщает мобильной ЭВМ, что она зарегистри-
рована.
Когда пользователь покидает зону обслуживания данной LAN
или MAN, регистрация должна быть аннулирована, а ЭВМ должна
быть автоматически зарегистрирована в новой зоне. Когда посыла-
ется пакет мобильному пользователю, «домашняя LAN», получив
его, маршрутизирует пакет внешнему агенту, зарегистрировавшему
данного пользователя. Этот агент переправит пакет адресату.
Процедуры переадресации выполняются с привлечением техно-
логии IP-туннелей. Домашний агент предлагает отправителю посы-
лать пакеты непосредственно внешнему агенту области, где зарегис-
трирована подвижная ЭВМ. Существует много вариантов реализа-
ции протокола с разным распределением функций между
маршрутизаторами и ЭВМ. Существуют схемы с временным вы де-
ланием резервного IP-адреса подвижному пользователю. Междуна-
родный стандарт для решения проблемы работы с подвижными
пользователями пока не разработан.
Теперь немного подробнее о наиболее популярных протоколах
Маршрутизации _ RIp> 0SpF) IGRp и BGP.4> начнем с внутреннего
Протокола маршрутизации RIP.
576
Гпава 4 .
4.4.8.7. Внутренний протокол маршрутизации RIP
Этот протокол маршрутизации предназначен для сравнительно
небольших и относительно однородных сетей (алгоритм Белмана-
Форда). Протокол разработан в университете Калифорнии (Беркли),
базируется на разработках фирмы Ксерокс и реализует те же прин-
ципы, что и программа маршрутизации routed, используемая в ОС
UNIX (4BSD). Маршрут здесь характеризуется вектором расстоя-
ния до места назначения. Предполагается, что каждый маршрути-
затор является отправной точкой нескольких маршрутов до сетей, с
которыми он связан. Описания этих маршрутов хранится в специ-
альной таблице, называемой маршрутной. Таблица маршрутизации
RIP содержит по записи на каждую обслуживаемую машину (на
каждый маршрут). Запись должна включать в себя:
IP-адрес места назначения.
Метрика маршрута (от 1 до 15;
число шагов до места назначения).
IP-адрес ближайшего маршрутизатора (Gateway)
по пути к месту назначения.
Таймеры маршрута.
Первым двум полям записи мы обязаны появлению термина
вектор расстояния (место назначение - направление; метрика -
модуль вектора). Периодически (раз в 30 сек) каждый маршрутиза-
тор посылает широковещательно копию своей маршрутной таблй*
цы всем соседям-маршрутизаторам, с которыми связан непосред*
ственно. Маршрутизатор-получатель просматривает таблицу. Если
в таблице присутствует новый путь или сообщение о более корот-
ком маршруте, или произошли изменения длин пути, эти изменения
фиксируются получателем в своей маршрутной таблице. Протокол »
RIP должен быть способен обрабатывать три типа ошибок:
1. Циклические маршруты. Так как в протоколе нет механизм
мов выявления замкнутых маршрутов, необходимо либо слепо вег
рить партнерам, либо принимать меры для блокировки такой воФ
можности.
2. Для подавления нестабильностей RIP должен использовать
малое значение максимально возможного числа шагов (<16).
3. Медленное распространение маршрутной информации по
создает проблемы при динамичном изменении маршрутной ситу#*
ции (система не поспевает за изменениями). Малое предельное эй#*
чение метрики улучшает сходимость, но не устраняет проблему»
Сети передачи данных. Метод доступа 57У
,' Несоответствие маршрутной таблицы реальной ситуации типич-
но не только для RIP, но характерно для всех протоколов, базирую-
щихся на векторе расстояния, где информационные сообщения акту-
ализации несут в себе только пары кодов: адрес места назначение и
расстояние до него. Пояснение проблемы дано на рис. 4.4.1.8.1 ниже.
Рис. 4.4.8.1. Иллюстрация, поясняющее возникновение циклических
маршрутов при использовании вектора расстояния.
На верхней части рисунка показана ситуация, когда маршрути-
заторы указывают маршрут до сети <А> в соответствии со стрелка-
ми. На нижней части связь на участке GW1 <Сеть А> оборвана, а
GW2 по-прежнему продолжает оповещать о ее доступности с чис-
лом шагов, равным 2. При этом GW1, восприняв эту информацию
(если GW2 успел передать свою маршрутную информацию раньше
GW1), может перенаправить пакеты, адресованные сети А, на GW2, а
в своей маршрутной таблице будет характеризовать путь до сети А
метрикой 3. При этом формируется замкнутая петля маршрутов.
Последующая широковещательная передача маршрутных данных
GW1 и GW2 не решит эту проблему быстро. Так после очередного
обмена путь от GW2 до сети А будет характеризоваться метрикой
5. Этот процесс будет продолжаться до тех пор, пока метрика не
станет равной 16, а это займет слишком много циклов обмена мар-
шрутной информацией.
Проблема может быть решена следующим образом. Маршрути-
затор запоминает, через какой интерфейс получена маршрутная ин-
формация, и через этот интерфейс эту информацию уже не передает.
В Рассмотренном выше примере GW2 не станет посылать информа-
цию о.пути к сети А маршрутизатору GW1, от которого он получил
Эти данные. В этом случае в маршрутной таблице GW1 путь до А
исчезнет сразу. Остальные маршрутизаторы узнают о недостижимо-
сти сети А через несколько циклов. Существуют и другие пути
преодоления медленных переходных процессов. Если производится
°повещение о коротком пути, все узлы-получатели воспринимают
данные немедленно. Если же маршрутизатор закрывает какой-
^ак’ ^8 3430 Семенов
578 Глава 4
то путь, его отмена фиксируется остальными лишь по тайм-ауту.
Универсальным методом исключения ошибок при маршрутизации
является использование достаточно большой выдержки, перед тем
как использовать информацию об изменении маршрутов. В этом
случае к моменту изменения маршрута эта информация станет дос,
тупной всем участникам процесса маршрутизации. Но все перечис-
ленные методы и некоторые другие известные алгоритмы, решая
одну проблему, часто вносят другие. Многие из этих методов могут
при определенных условиях вызвать лавину широковещательных
сообщений, что также дезорганизует сеть. Именно малая скорость
установления маршрутов в RIP (и других протоколах, ориентиро-
ванных на вектор расстояния) и является причиной их постепенно-
го вытеснения другими протоколами.
Но даже усовершенствование, изложенное выше, не всегда сраба-
тывает. На рис. 4.4.8.1а приведен пример, когда переходной про-
цесс, несмотря на усовершенствование будет идти долго. При обры-
ве связи В-Г узлы А и Б сообщают узлу В, что они потеряли связь с
узлом Г. Узел В делает вывод, что Г не достижим, о чем и сообщает
узлам А и Б. К сожалению А знает, что Б имеет проход к Г длиной
2, из чего он делает вывод о достижимости Г за три шага. Анало-
гично рассуждает Б о возможности достижимости Г через А. Далее
при последующих рассылках метрика доступности Г, характеризу-
ется все большими значениями, до тех пор пока не станет равной
«бесконечности».
ГА1
; \ z" "X
, ' в ;--------( |- •
Рис. 4.4.8.1а. Пример топологии, где переходной процесс
осуществляется медленно, даже при усовершенствовании алгоритма»,
В RIP сообщения инкапсулируются в UDP-дейтограммы, при этом
передача осуществляется через порт 520. В качестве метрики RI?
использует число шагов до цели. Если между отправителем и прием-
ником расположено три маршрутизатора (gateway), считается, что
между ними 4 шага. Такой вид метрики не учитывает различий §
пропускной способности или загруженности отдельных сегментов сети*
Применение вектора расстояния не может гарантировать оптимаЛ**
ность выбора маршрута, ведь, например, два шага по сегментам сети
Оети передачи данных. Метод доступа 579
.——'—---
Ethernet обеспечат большую пропускную способность, чем один шаг
через последовательный канал на основе интерфейса RS-232.
Маршрут по умолчанию имеет адрес 0.0.0.0 (это верно и для
других протоколов маршрутизации). Каждому маршруту ставится
в соответствие таймер тайм-аута и «сборщика мусора». Тайм-аут-
таймер сбрасывается каждый раз, когда маршрут инициализируется
или корректируется. Если со времени последней коррекции прошло
3 минуты или получено сообщение о том, что вектор расстояния
равен 16, маршрут считается закрытым. Но запись о нем не стира-
ется, пока не истечет время «уборки мусора» (2мин). При появле-
нии эквивалентного маршрута переключения на него не происхо-
дит, таким образом, блокируется возможность осцилляции между
двумя или более равноценными маршрутами. Формат сообщения
протокола RIP имеет вид, показанный на рис. 4.4.8.2. Поле коман-
да определяет выбор согласно следующей таблице:
Таблица 4.4.8.1. Значения кодов поля команда
Команда Значение
1 Запрос на получение частичной или полной маршрутной информации;
2 Отклик, содержащий информацию о расстояниях из маршрутной таблицы отправителя;
3 Включение режима трассировки (устарело);
4 Выключение режима трассировки (устарело);
5-6 Зарезервированы для внутренних целей SUN Microsystem.
Поле версия &ля RIP равно 1 (для RIP-2 двум). Поле набор
протоколов сети i определяет набор протоколов, которые использу-
ются в соответствующей сети (для Интернет это поле имеет значе-
ние 2). Поле расстояние до сети i содержит целое число шагов (от
1 до 15) до данной сети. В одном сообщении может присутствовать
информация о 25 маршрутах. При реализации RIP можно выде-
лить следующие режимы:
Инициализация, определение всех «живых» интерфейсов путем
п°сылки запросов, получение таблиц маршрутизации от других мар-
шрутизаторов. Часто используются широковещательные запросы.
Получен запрос. В зависимости от типа запроса высылается
адресату полная таблица маршрутизации, или проводится индиви-
дуальная обработка.
Получен отклик. Проводится коррекция таблицы маршрутиза-
Ии (Удаление, исправление, добавление).
19-
580
О ___________ 8________________16____________________________31
Команда(1-6) Версия (1) Должно быть равно нулю
Набор протоколов сети (2) Должно быть равно нулю
IP адрес сети 1
Должно быть равно нулю
Должно быть равно нулю
Расстояние до сети 1 (метрика)
Набор протоколов сети (2) Должно быть равно нулю
IP адрес сети 2
Должно быть равно нулю
Должно быть равно нулю
Дистанция до сети 2 (метрика)
••••••
Рис. 4.4.8.2. Формат сообщения RIP.
0 8 16 31
Команда(1-6) Версия (1) Должно быть равно нулю
Набор протоколов сети (2) Должно быть равно нулю
IP адрес сети 1 20
Должно быть равно нулю октетов Г
Должно быть равно нулю "i *
Расстояние до сети 1 (метрика) 1
Набор протоколов сети (2) Должно быть равно нулю ' * X
IP адрес сети 2 ГН ~
Должно быть равно нулю ’’
Должно быть равно нулю
Дистанция до сети 2 (метрика)
••••••
.‘Ф &
Рис. 4.4.8.3 Формат сообщений протокола RIP-2
Сети передачи данных. Метод доступа 581
регулярные коррекции. Каждые 30 секунд вся или часть табли-
цы маршрутизации посылается всем соседним маршрутизаторам.
Могут посылаться и специальные запросы при локальном измене-
нии таблицы. RIP достаточно простой протокол, но, к сожалению
не лишенный недостатков:
a. RIP не работает с адресами субсетей. Если нормальный 16-
бит идентификатор ЭВМ класса В не равен 0, RIP не может опреде-
лить является ли не нулевая часть субсетевым ID, или полным IP-
адресом.
b. RIP требует много времени для восстановления связи после
сбоя в маршрутизаторе (минуты). В процессе установления режима
возможны циклы.
с. Число шагов важный, но не единственный параметр маршру-
та, да и 15 шагов не предел для современных сетей.
Протокол RIP-2 (RFC-1388, 1993 год) является новой версией
RIP, которая в дополнение к широковещательному режиму поддер-
живает мультикастинг; позволяет работать с масками субсетей. На
рис. 4.4.8.3 представлен формат сообщения для протокола RIP-2.
Поле маршрутный демон является идентификатором резидентной
программы-маршрутизатора. Поле метка маршрута используется
для поддержки внешних протоколов маршрутизации, сюда записы-
ваются коды автономных систем. При необходимости управления
доступом можно использовать первые 20 байт с кодом набора про-
токолов сети OxFFFF и меткой маршрута =2. Тогда в остальные 16
байт можно записать пароль.
4.4.8.2. Протокол маршрутизации OSPF
Протокол OSPF (Open Shortest Pass First, RFC-1245-48, RFC-
1583-1587, алгоритмы предложены Дикстрой) является альтерна-
тивой RIP в качестве внутреннего протокола маршрутизации. OSPF
представляет собой протокол состояния маршрута (в качестве мет-
рики используется — коэффициент качества обслуживания). Каж-
Дьщ маршрутизатор обладает полной информацией о состоянии всех
интерфейсов всех маршрутизаторов (переключателей) автономной
системы. Протокол OSPF реализован в демоне маршрутизации gated,
который поддерживает также RIP и внешний протокол маршрути-
3аДии BGP.
м Автономная система может быть разделена на несколько облас-
ти, куда могут входить как отдельные ЭВМ, так и целые сети. В
м случае внутренние маршрутизаторы области могут и не иметь
ч°Рмации о топологии остальной части AS. Сеть обычно имеет
Пленный (designated) маршрутизатор, который является источ-
582
Гпава 4
ником маршрутной информации для остальных маршрутизаторов
AS. Каждый маршрутизатор самостоятельно решает задачу опти-
мизации маршрутов. Если к месту назначения ведут два или более
эквивалентных маршрута, информационный поток будет поделен
между ними поровну. Переходные процессы в OSPF завершаются
быстрее, чем в RIP. В процессе выбора оптимального маршрута
анализируется ориентированный граф сети. Ниже описан алгоритм
Дикстры по выбору оптимального пути. На иллюстративном рис.
4.4.8.2.1 приведена схема узлов (А-J) со значениями метрики для
каждого из отрезков пути. Анализ графа начинается с узла А (Старт).
Пути с наименьшим суммарным значением метрики считаются
наилучшими. Именно они оказываются выбранными в результате
рассмотрения графа («кратчайшие пути»).
Ниже дается формальное описание алгоритма. Сначала вводим
некоторые определения.
Пусть D(v) равно сумме весов связей для данного пути.
Пусть C(i,j) равно весу связи между узлами с номерами i и j.
Далее следует последовательность шагов, реализующих алгоритм.
1. Устанавливаем множество узлов N = {1}.
2. Для каждого узла v не из множества N устанавливаем D(v)=
c(l,v). -
3. Для каждого шага находим узел w не из множества N, для Г
которого D(w) минимально, и добавляем узел w в множество N.
4. Актуализируем D(v) для всех узлов не из множества N
D(v)=min { D(v), D(v)+c(w,v)}.
5. Повторяем шаги 2-4, пока все узлы не окажутся в множестве N.
Рис. 4.4.8.2.7. Иллюстрация работы алгоритма Дикстры
Сети передачи данных. Метод доступа
583
Топология маршрутов для узла А приведена на нижней части
рис. 4.4.8.2.1. В скобках записаны числа, характеризующие метри-
ку отобранного маршрута согласно критерию пункта 3.
Таблица 4.4.8.2.1. Реализация алгоритма
1
Шаг Множество Метрика связи узла А с узламй
N В с D Е F G н I J
0 {А} 3 - 9 - - - - - -
1 {А,В} (3) 4 9 7 - 10 - - -
_ 2 3 {А,В,С) 3 (4) 6 6 10 10 8 - 14
(А,ВС,Р) 3 4 (6) 6 10 10 8 9 14
4 !A,B,C,D,E) 3 4 -6 (6) 10 10 8 9 14
5 {A,B,C,D,E,H) 3 4 6 6 10 10 (8) 9 14
6 {A,B,C,D,E,H,l} 3 4 6 6 10 10 8 (9) 14
7 {A,B,C,D,E,H,I,F} 3 4 6 6 (10) 10 8 9 14
8 {A,B,C,D,E,H,I,F,G} 3 4 6 6 10 (10) 8 9 14
9 (A,B,C,D,E,H,I,F,G.J} 3 4 6 6 10 10 8 9 (14)
Таблица 4.4.8.2.1 может иметь совершенно иное содержимое
для какого-то другого вида сервиса, выбранные пути при этом мо-
гут иметь другую топологию. Качество сервиса (QOS) может харак-
теризоваться следующими параметрами:
• пропускной способностью канала;
• задержкой (время распространения пакета);
• числом дейтограмм, стоящих в очереди для передачи;
• загрузкой канала;
• требованиями безопасности;
• типом трафика;
• числом шагов до цели;
• возможностями промежуточных связей (например, многовари-
антность достижения адресата).
Определяющими являются три характеристики: задержка, про-
пускная способность и надежность. Для транспортных целей OSPF
использует IP непосредственно, т.е. не привлекает протоколы UDP
или TCP. OSPF имеет свой код (89) в протокольном поле 1Р-заго-
л°вка. Код TOS (Type Of Service) в IP-пакетах, содержащих OSPF-
сообщения, равен нулю, значение TOS здесь задается в самих паке-
тах OSPF. Маршрутизация в этом протоколе определяется 1Р-адре-
С°м и типом сервиса. Так как протокол не требует инкапсуляции
Пакетов, сильно облегчается управление сетями с большим количе-
Ством бриджей и сложной топологией (исключается циркуляция
584
Гпава 4 ;
пакетов, сокращается транзитный трафик). Автономная система
может быть поделена на отдельные области, каждая из которых
становится объектом маршрутизации, а внутренняя структура сна-
ружи не видна (узлы на рис. 4.4.8.2.1 могут представлять собой
как отдельные ЭВМ или маршрутизаторы, так и целые сети). Этот
прием позволяет значительно сократить необходимый объем мар.
шрутной базы данных. В OSPF используется термин опорной сети
(backbone) для коммуникаций между выделенными областями. Про-
токол работает лишь в пределах автономной системы. В пределах
выделенной области может работать свой протокол маршрутизации.
Рис. 4.4.8.2.2. Пример выделения областей при OSPF
маршрутизации в автономной системе
(М - маршрутизаторы; С - сети].
На рис 4.4.8.2.2 (см. также рис. 4.4.8.2.1) приведен пример
выделения областей маршрутизации при OSPF-маршрутизации в
пределах автономной системы. На рис. 4.4.8.2.2 маршрутизаторы
М4 и М2 выполняют функция опорной сети для других областей. В
выделенных областях может быть любое число маршрутизаторов.
Более толстыми линиями выделены связи с другими автономными
системами.
При передаче OSPF-пакетов фрагментация не желательна, но не
запрещается. Для передачи статусной информации OSPF использу-
ет широковещательные сообщения HELLO. Для повышения безо-
пасности предусмотрена авторизация процедур. OSPF-протокол тре-
бует резервирования двух мультикастинг-адресов:
224.0.0.5 — предназначен для обращения ко всем маршрутиза-
торам, поддерживающим этот протокол.
Сети передачи данных. Метод доступа 585
224.0.0.6 — служит для обращения к специально выделенному
Mapmpy™3aTOpy-
Любое сообщение OSPF начинается с 24-октетного заголовка:
Версия тип Длина сообщения
IP-адрес маршрутизатора-отправителя
Идентификатор области
Контрольная сумма Тип идентификации
Идентификация (октеты 0-3)
Идентификация (октеты 4-7)
Рис. 4.4.8.2.3 Формат заголовка сообщений для протокола
маршрутизации OSPF
Поле версия определяет версию протокола (= 2). Поле тип иден-
тифицирует функцию сообщения согласно таблице 4.4.8.2.2:
Таблица 4.4.8.2.2. Коды поля тип
Тип Значение
1 Hello (используется для проверки доступности маршрутизатора).
2 Описание базы данных (топология).
3 Запрос состояния канала.
4 Изменение состояния канала.
5 Подтверждение получения сообщения о статусе канала.
Поле длина пакета определяет длину блока в октетах, включая
заголовок. Идентификатор области — 32-битный код, идентифи-
цирующий область, которой данный пакет принадлежит. Все OSPF-
пакеты ассоциируются с той или иной областью. Большинство из
них не преодолевает более одного шага. Пакеты, путешествующие
по виртуальным каналам, помечаются идентификатором опорной
области (backbone) 0.0.0.0. Поле контрольная сумма содержит кон-
трольную сумму IP-пакета, включая поле типа идентификации.
Контрольное суммирование производится по модулю 1. Поле тип
идентификации может принимать значения 0 при отсутствии конт-
роля доступа, и 1 при наличии контроля. В дальнейшем функции
поля будут расширены. Важную функцию в OSPF-сообщениях вы-
полняет одно-октетное поле опции, оно присутствует в сообщениях
TlIna HELLO, объявление состояния канала и описание базы дан-
нЫх. Особую роль в этом поле играют младшие биты Е и Т:
586
Гпава 4
Е Т
Формат поля опции
Бит Е характеризует возможность внешней маршрутизации ц
имеет значение только в сообщениях типа HELLO, в остальных
сообщениях этот бит должен быть обнулен. Если Е=0, то данный
маршрутизатор не будет посылать или принимать маршрутную ин-
формацию от внешних автономных систем. Бит Т определяет сер.
висные возможности маршрутизатора (TOS). Если Т=0, это означа-
ет, что маршрутизатор поддерживает только один вид услуг (TOS=0)
и он не пригоден для маршрутизации с учетом вида услуг. Такие
маршрутизаторы, как правило, не используются для транзитного
трафика.
Протокол OSPF использует сообщение типа Hello для взаимооб-
мена данными между соседними маршрутизаторами. Структура па-,
кетов этого типа показана на рис. 4.4.8.2.4.
0 8 1 I6 31
Заголовок OSPF типа 1 24 октета В заголовке OSPF-пакета поле тип=1 говорит,
Сетевая маска это HELLO- сообщение
Время между HELLO Опции Приоритет
Время отключения маршрутизатора
IP-адрес маршрутизатора
IP-адрес резервного маршрутизатора
IP-адрес соседа 1
IP-адрес соседа 2
••••••
IP-адрес соседа N
Рис. 4.4.8.2.4 Формат сообщения Hello в протоколе OSPF
Поле сетевая маска соответствует маске субсети данного интер*
фейса. Например, если интерфейс принадлежит сети класса В и тре-
тий байт служит для выделения нужной субсети, то сетевая маска^
будет иметь вид OxFFFFFFOO. Л
Сети передачи данных. Метод доступа
587
Поле время между Hello содержит значение времени в секундах,
сообщениями HELLO. Поле опции характеризует возможно-
мея*ду „
сТи которые предоставляет данный маршрутизатор. Поле приори-
тет определяет уровень приоритета маршрутизатора (целое поло-
жительное число), используется при выборе резервного (backup) мар-
шрутизатора. Если приоритет равен нулю, данный маршрутизатор
никогда не будет использован в качестве резервного. Поле время
отключения маршрутизатора определяет временной интервал в
секундах, по истечении которого «молчащий» маршрутизатор счи-
тается вышедшим из строя. IP-адреса маршрутизаторов, записан-
ные в последующих полях, указывают место, куда следует послать
данное сообщение. Поля IP-adpec соседа k образуют список адресов
соседних маршрутизаторов, откуда за последнее время были получе-
ны сообщения Hello.
Маршрутизаторы обмениваются сообщениями из баз данных OSPF,
чтобы инициализировать, а в дальнейшем актуализовать свои базы
данных, характеризующие топологию сети. Обмен происходит в ре-
жиме клиент-сервер. Клиент подтверждает получение каждого со-
общения. Формат пересылки записей из базы данных представлен
на рис. 4.4.8.2.5.
о 8
Заголовок OSPF типа 2 24 октета
Должно быть обнулено Опции 1 М S
Номер сообщения по порядку
Тип канала
Идентификатор канала
Маршрутизатор, рекламирующий канал
Порядковый номер канала
Контрольная сумма Возраст канала
••••••
В заголовке
OSPF-пакета
поле
тип=2 говорит,
что это
описание
маршрутной
базы данных
Отмеченная
часть
повторяется
по числу
описываемых
каналов. Эта
область
является
заголовком
описания
состояния
канала.
Рис. 4.4.8.2.5 Формат OSPF-сообщений о маршрутах
1
з Поля, начиная с тип канала, повторяются для каждого описа-
канала. Так как размер базы данных может быть велик, ёе
СоДержимое может пересылаться по частям. Для реализации этого
588
Гпава 4
используются биты I и М. Бит I устанавливается в 1 в стартовом
сообщении, а бит М принимает единичное состояние для сообще-
ния, которые являются продолжением. Бит S определяет то, кем
послано сообщение (S=l для сервера, S=0 для клиента, этот бит
иногда имеет имя MS). Поле номер сообщения по порядку служит
для контроля пропущенных блоков. Первое сообщение содержит в,
этом поле случайное целое число М, последующие М+1, M+2,...M+L.
Поле тип канала может принимать следующие значения:
Таблица 4.4.8.2.3. Коды типов состояния каналов (LSJ
LS-тип Описание объявления о маршруте
1 Описание каналов маршрутизатора, то есть состояния его интерфейсов.
2 Описание сетевых каналов. Это перечень маршрутизаторов, непосредственно связанных с сетью.
3 или 4 Сводное описание каналов, куда входят маршруты между отдельными областями сети. Эта информация поступает от пограничных маршрутизаторов этих зон. Тип 3 приписан маршрутам, ведущим к сетям, а тип 4 характеризует маршруты, ведущие к пограничным маршрутизаторам автономной системы.
5 Описания внешних связей автономной системы. Такие маршруты начинаются в пограничных маршрутизаторах AS.
Поле идентификатор канала определяет его характер, в зависи-
мости от этого идентификатором может быть IP-адрес маршрутиза-
тора или сети. Маршрутизатор, рекламирующий канал определяет
адрес этого маршрутизатора. Поле порядковый номер канала позво-
ляет маршрутизатору контролировать порядок прихода сообщений
и их потерю. Поле возраст канала определяет время в секундах с
момента установления связи. После обмена сообщениями с соседя-
ми маршрутизатор может выяснить, что часть данных в его базе
устарела. Он может послать своим соседям запрос с целью получе-
ния свежей маршрутной информации о каком-то конкретном кана*
ле связи. Сосед, получивший запрос, высылает необходимую инфор'
мацию. Запрос посылается в соответствии с форматом, показанном
ниже (рис. 4.4.8.2.6):
Три поля этого запроса повторяются согласно числу каналов, иЯ*
формация о которых запрашивается. Если список достаточно ДЛЯ*
нен, может потребоваться несколько запросов. Маршрутизаторы под-
сылают широковещательные (или мультикастинговые) сообщения
об изменении состояния своих непосредственных связей. Такое сооб-
щение содержит список объявлений, имеющих формат (рис. 4.4.8.2*Ф*
Сеги передачи данных. Метод доступа
589
О 8 16 31
Заголовок OSPF типа 3
24 октета
Тип канала
Идентификатор канала
Маршрутизатор, объявляющий о канале
.••••••
Рис. 4.4.8.2.6. Формат OSPF-запроса маршрутной информации
О 8
31
Заголовок OSPF типа 4
24 октета
Число сообщений о состоянии каналов
Сообщение о состоянии канала 1
Сообщение о состоянии канала N
Рис. 4.4.8.2.7 Сообщение об изменении маршрутов
Сообщения об изменениях маршрутов могут быть вызваны сле-
дующими причинами:
1. Возраст маршрута достиг предельного значения (LSRefreshTime).
2. Изменилось состояние интерфейса.
3. Произошли изменения в маршрутизаторе сети.
4. Произошло изменение состояния одного из соседних маршру-
тизаторов.
5. Изменилось состояние одного из внутренних маршрутов (появ-
ление нового, исчезновение старого и т.д.)
6. Изменение состояния межзонного маршрута.
Появление нового маршрутизатора, подключенного к сети.
8* * Вариация виртуального маршрута одним из маршрутизаторов.
• Возникли изменения одного из внешних маршрутов.
Маршрутизатор перестал быть пограничным для данной AS
(например, перезагрузился).
Каждое сообщение о состоянии канала начинается с заголовка
«объявление состояния канала» (LS - Link State). Формат этого
Типа заголовка приведен ниже (20 октетов):
590
Глава
0 8 16 31
Версия , 4 Длина сообщения
IP-адрес маршрутизатора-отправителя
Идентификатор области
Контрольная сумма Тип идентификации
Идентификация (октеты 0-3)
Идентификация (октеты 4-7)
Число сообщений о состоянии каналов
Возраст LS информации Опции Тип LS
Идентификатор состояния канала
Маршрутизатор, источник маршрутной информации
Порядковый номер LS-сообщения
Контрольная сумма LS Длина
OSPF-
заголовок
Первое
описание
состояния
Канала
20 октетов
Рис. 4.4.8.2.8. Формат OSPF-сообщения,
описывающего состояние канала
Поле возраст LS информации (рис. 4.4.84L8) определяет вре-
мя в секундах с момента объявления состояния канала. Поле оп-
ции содержит значения типов сервиса (TOS), поддерживаемые мар-
шрутизатором, рассылающим маршрутную информацию. Поле тип
LS (тип состояния канала) может принимать значения, описанные
выше в табл. 4.4.8.2.3. Следует обратить внимание, что код, содер-
жащийся в этом поле, определяет формат сообщения. Поле длина.
задает размер сообщения в октетах, включая заголовок. В результа-
те получается сообщение с форматом, показанным на рис. 4.4.8.2.9.
Зарезервированный октет должен быть обнулен. Идентификатор
связи определяет тип маршрутизатора, подключенного к каналу.
Действительное значение этого поля зависит от поля тип. В свои»
очередь информация о канале также зависит от поля тип. Число
TOS определяет многообразие метрик, соответствующих видам сер-,
виса, для данного канала. Последовательность описания метрик за^
дается величиной кода TOS. Таблица кодов TOS, принятых в OSPF
протоколе приведена ниже. ,.л
Если бит V=1 (virtual), маршрутизатор является оконечной то^
кой активного виртуального канала. Если бит Е (external) равен 1>
маршрутизатор является пограничным для автономной системы^
Бит В=1 (border) указывает на то, что маршрутизатор является.
Сеги
передачи данных. Метод доступа
591
Таблица 4.4.8.2.4. Коды типа сервиса (TOS)
О8РЬкод_ TOS-коды TOS (RFC 1349)
0000 Обычный сервис
' 2 0001 Минимизация денежной стоимости
"" 4 0010 Максимальная надежность
8 0100 Максимальная пропускная способность *
~ кГ 1000 Минимальная задержка
О 8
31
Заголовок OSPF 24 октета
Возраст LS Опции 1
Идентификатор LS
Маршрутизатор, анонсирующий канал
Номер LS-записи по порядку
Контрольная сумма Длина
0 V Е В 0 Число каналов
Идентификатор канала
’ Описание канала
Тип Число TOS Метрика TOS 0
Код TOS 0 Метрика
••••
Код TOS 0 Метрика
' Идентификатор канала
Описание канала
Тип LS = 1
LS заголовок
20 октетов
Рис. 4.4.8.2.9. Формат описания типа канала с LS=1
ПогРаничным для данной области. Поле тип может принимать
значения, приведенные в таблице 4.4.8.2.5.
Поле идентификатор канала характеризует объект, с которым
СВязывается маршрутизатор. Примеры идентификаторов представ-
Лены в таблице 4.4.8.2.6.
^аРшруТИзатОр, получивши!^ OSPF-пакет, посылает подтвержде-
его приема. Этот вид пакетов имеет тип=5 и структуру, отобра-
Наую на рис. 4.4.8.2.10. Получение нескольких объявлений о
592
Гпава 4
Таблица 4.4.8.2.5. Коды типов связей (см. рис. 4.4.8.2.9J
Код типа связи Описание
1 Связь с другим маршрутизатором по схеме точка-точка
2 Связь с транзитной сетью
3 Связь с оконечной сетью
4 Виртуальная связь (например, опорная сеть или туннель)
Таблица 4.4.8.2.6. Коды идентификаторов канала
Код* идентификатора Описание
1 Идентификатор соседнего маршрутизатора
2 IP-адрес основного маршрутизатора (по умолчанию)
3 IP-адрес сети/субсети
4 Идентификатор соседнего маршрутизатора
состоянии линий может быть подтверждено одним пакетом. Адре-
сом места назначения этого пакета может быть индивидуальный
маршрутизатор, группа маршрутизаторов или все маршрутизаторы
автономной системы.
Заголовок OSPF типа 5
24 октета
Заголовок типа
“объявление состояния канала"
20 октетов
Рис. 4.4.8.2.10 Формат сообщения о получении OSPF-пакета
Рекламирование сетевых связей относится к типу 2. Сообщения
посылаются для каждой транзитной сети в автономной системе.
Транзитной считается сеть, которая имеет более одного маршрути-
затора. Сообщение о сетевых связях должно содержать информа-
цию обо всех маршрутизаторах, подключенных к сети, включая тот,
который рассылает эту информацию. Расстояние от сети до любого
подключенного маршрутизатора равно нулю для всех видов сервиса
(TOS), поэтому поля TOS и метрики в этих сообщениях отсутству-
ют. Формат сообщения о транзитных сетевых связях показан на
рис. 4.4.8.2.11.
Следует помнить, что приведенные ниже сообщения должны быть
снабжены стандартными 24-октетными OSPF-заголовками (на рис.
4.4.8.2.11 отсутствует).
Сети передачи данных. Метод доступа
593
Рис. 4.4.8.2.11 Формат сообщения о сетевых связях (тип LS=2]
Сетевая маска относится к описываемой сети, а поле подклю-
ченный маршрутизатор содержит идентификатор маршрутизатора,
работающего в сети. Информация об адресатах в пределах автоном-
ной системы передается LS-сообщениями типа 3 и 4. Тип 3 работа-
ет для IP-сетей. В этом случае в качестве идентификатора состоя-
ния канала используется IP-адрес сети. Если же адресатом являет-
ся пограничный маршрутизатор данной AS, то используется
LS-сообщение типа 4, а в поле идентификатор состояния канала
записывается OSPF-идентификатор этого маршрутизатора. Во всех
остальных отношениях сообщения 3 и 4 имеют идентичные форма-
ты (рис. 4.4.8.2.12):
16
31
о
8
Возраст LS Опции 2 или 4
Идентификатор состояния канала
Маршрутизатор, анонсирующий канал
Номер LS-запиои по порядку
Контрольная сумма Длина
Сетевая маска
TOS Метрика
LS заголовок
20 октетов
Тип LS = 3
или 4
Рис. 4.4.8.2.12 Формат сообщений об адресатах в пределах
автономной системы
594
Гпава 4
Поля, следующие после заголовка, повторяются в соответствии с
числом описываемых объектов. Рекламирование внешних маршру-
тов относится к пятому типу. Эта информация рассылается погра-
ничными маршрутизаторами. Информация о каждом внешнем ад-
ресате, известном маршрутизатору, посылается независимо. Этот вид
описания используется и для маршрутов по умолчанию, для кото-
рых идентификатор состояния канала устанавливается равным
0.0.0.0 (аналогичное значение принимает при этом и сетевая мас-
ка). Формат такого сообщения представлен на рис. 4.4.8.2.13.
Рис. 4.4.8.2.13 Формат описания внешних маршрутов
v Сетевая маска характеризует место назначения рекламируемого
маршрута. Так для сети класса А маска может иметь вид
OxFFOOOOOO. Последующий набор полей повторяется для каждого
вида TOS. Поля для TOS=0 заполняются всегда, и это описание
является первым. Бит Е характеризует внешнюю метрику. Если
Е=0, то она может непосредственно (без преобразования) сравни-
ваться с метриками других каналов. При Е=1 метрика считается |
больше любой метрики. Поле адрес пересылки указывает на место, S
куда будут пересылаться данные рекламируемым маршрутом. Если »
адрес пересылки равен 0.0.0.0, данные посылаются пограничному Ц
маршрутизатору автономной системы — источнику данного сооб- |
щения. Метка внешнего маршрута — 32-битовое число, присваива- Ц
емое каждому внешнему маршруту. Эта метка самим протоколом у
OSPF не используется и предназначена для информирования других к
Сети передачи данных. Метод доступа
595
автономных систем при работе внешних протоколов маршрутиза-
ции. Маршрутная таблица OSPF содержит в себе:
• IP-адрес места назначения и маску;
• тип места назначения (сеть, граничный маршрутизатор и т.д.);
• тип функции (возможен набор маршрутизаторов для каждой
из функций TOS);
• область (описывает область, связь с которой ведет к цели, воз-
можно несколько записей данного типа, если области действия гра-
ничных маршрутизаторов перекрываются);
• тип пути (характеризует путь как внутренний, межобластной
или внешний, ведущий к AS);
• цена маршрута до цели;
• очередной маршрутизатор, куда следует послать дейтограмму;
• объявляющий маршрутизатор (используется для межобласт-
ных обменов и для связей автономных систем друг с другом).
4.4.8.3. Протокол маршрутизации IGRP
Протокол IGRP разработан фирмой CISCO для своих многопро-
токольных маршрутизаторов в середине 80-х годов. Хотя этот про-
токол и не является стандартным, я счел возможным включить его
описание, так как маршрутизаторы этой фирмы относятся к наибо-
лее массовым. IGRP представляет собой протокол, который позво-
ляет большому числу маршрутизаторов координировать свою рабо-
ту. Основные достоинства протокола:
• стабильность маршрутов даже в очень больших и сложных
сетях;
• быстрый отклик на изменения топологии сети;
• минимальная избыточность. Поэтому IGRP не требует допол-
нительной пропускной способности каналов для своей работы;
• разделение потока данных между несколькими параллельны-
ми маршрутами, примерно равного достоинства;
• учет частоты ошибок и уровня загрузки каналов;
• возможность реализовать различные виды сервиса для одного
и того же набора информации.
Сегодняшняя реализация протокола ориентирована на TCP/IP.
Однако базовая конструкция системы позволяет использовать IGRP
и с другими протоколами. IGRP имеет некоторое сходство со стары-
ми протоколами, например с RIP и Hello. Здесь маршрутизатор об-
менивается маршрутной информацией только с непосредственными
соседями. Поэтому задача маршрутизации решается всей совокуп-
ностью маршрутизаторов, а не каждым отдельно.
596
Глава 4
Для того чтобы исключить осцилляции маршрутов, протокол
IGRP должен игнорировать новую информацию в течение несколь-
ких минут после ее возникновения. OSPF-протокол вынужден ис-
пользовать большую избыточность информации по сравнению с IGRP,
как на уровне базы маршрутных данных, так и в процессе обмена с
внешней средой.
’ IGRP используется в маршрутизаторах, которые имеют связи с
несколькими сетями и выполняют функции переключателей паке-
тов. Когда какой-то объект в одной сети хочет послать пакет в
другую сеть, он должен послать его соответствующему маршрутиза-
тору. Если адресат находится в одной из сетей, непосредственно
связанной с маршрутизатором, он отправляет этот пакет по месту
назначения. Если же адресат находится в более отдаленной сети,
маршрутизатор перешлет пакет другому маршрутизатору, располо-
женному ближе к адресату. Здесь также как и в других протоколах
для хранения маршрутных данных используются специализирован-
ные базы данных.
Протокол IGRP формирует эту базу данных на основе информа-
ции, которую он получит от соседних маршрутизаторов. В простей-
шем случае находится один путь для каждой из сетей. Сегменты
пути характеризуются используемым сетевым интерфейсом, метри-
кой и маршрутизатором, куда следует сначала послать пакет. Мет-
рика — то число, которое говорит о том, насколько хорош данный
маршрут. Это число позволяет сравнить его с другими маршрутами,
ведущими к тому же месту назначения и обеспечивающим тот же
уровень QOS. Предусматривается возможность (как и в OSPF) разде-
лять информационный поток между несколькими доступными экви-
валентными маршрутами. Пользователь может сам разделить поток
данных, если два или более пути оказались почти равными по метри-
ке, при этом большая часть трафика будет послана по пути с лучшей
метрикой. Метрика, используемая в IGRP, учитывает:
• время задержки;
• пропускную способность самого слабого сегмента пути (в би-
тах в сек);
• загруженность канала (относительную);
• надежность канала (определяется долей пакетов, достигших
места назначения неповрежденными).
Время задержки предполагается равным времени, необходимому
для достижения места назначения при нулевой загрузке сети.
Дополнительные задержки, связанные с загрузкой учитываются от-
дельно.
Сети передачи данных. Метод доступа
597
Среди параметров, которые контролируются, но не учитываются
метрикой, находятся число шагов до цели и MTU (maximum transfer
unit — размер пакета пересылаемого без фрагментации). Расчет мет-
рики производится для каждого сегмента пути.
Время от времени каждый маршрутизатор широковещательно
рассылает свою маршрутную информацию всем соседним маршрути-
заторам. Получатель сравнивает эти данные с уже имеющимися и
вносит, если требуется, необходимые коррекции. На основании вновь
полученной информации могут быть приняты решения об изменении
маршрутов. Эта процедура типична для многих маршрутизаторов и
этот алгоритм носит имя Белмана-Форда. (см. также описание про-
токола RIP, RFC-1058). Наилучший путь выбирается с использова-
нием комбинированной метрики, вычисленной по формуле:
[(KI / Ве) + (К2 * Dc)] г [1],
где: KI, К2 == константы;
Ве= пропускная способность канала (в отсутствии загрузки) * (1
— загрузка канала);
Dc = топологическая задержка;
г = относительная надежность (% пакетов, успешно передавае-
мых по данному сегменту пути). Здесь загрузка измеряется как
доля от 1.
Путь, имеющий наименьшую комбинированную метрику, счита-
ется лучшим. В такой схеме появляется возможность, используя
весовые коэффициенты, адаптировать выбор маршрутов к задачам
конечного пользователя.
Одним из преимуществ IGRP является простота реконфигура-
ции. В IGRP маршрут по умолчанию не назначается, а выбирается
из числа кандидатов.
Когда маршрутизатор включается, его маршрутные таблицы ини-
циализируются оператором вручную или с использованием специ-
альных файлов. На рис. 4.4.8.3.1 маршрутизатор S связан через
соответствующие интерфейсы с сетями 2 и 3.
Рис. 4.4.8.3.1
598
Гпава 4
Таким образом, в исходный момент маршрутизатор S знает только
о доступности сетей 2 и 3. За счет обмена информацией, полученной
при инициализации и присланной позднее соседями, маршрутизато-
ры познают окружающий мир. Так S спустя некоторое время полу-
чит информацию от маршрутизатора R о доступности сети 1 и от Т
— о сети 4. В свою очередь S проинформирует Т о доступе к сети 1.
Очень быстро информация о доступности дойдет до всех маршрути-
заторов и разрозненные сети станут единым целым. Для пояснения
выбора маршрута в условиях многовариантности рассмотрим схему
на рис. 4.4.8.3.2.
Рис. 4.4.8.3.2. Пример с альтернативными маршрутами
Пусть каждый из маршрутизаторов уже вычислил комбинцро*
ванную метрику для системы, изображенной на рис. 4.4.8.3.2. Для
места назначения в сети 6 маршрутизатор А вычислит метрику для
двух путей, через маршрутизаторы В и С. В действительности суще-
ствует три маршрута из А в сеть 6: ;
- через GW-В *
- в GW-С и затем в GW-B
- в GW-С и далее через GW-D в сеть 6.
Маршрутизатору А не нужно выбирать между двумя маршрута-
ми через GW-С. Маршрутная таблица в А содержит только одну
запись, соответствующую пути к GW-С. Если маршрутизатор А по-
сылает пакет маршрутизатору С, то именно С решает, использовать:
далее путь через маршрутизаторы GW-В или GW-D.
Для каждого типа канала используется свое стандартное значе^
ние комбинированной задержки. Ниже приведен пример того, как
может выглядеть маршрутная таблица в маршрутизаторе АгДЗД.
сети, изображенной на рис. 4.4.8.3.3. * ’
Сети передачи данных. Метод доступа
599
Номер сети Интерфейс Следующий маршрутизатор Метрика маршрута
Сеть 1 nw 1 Нет Непосредственная связь
Сеть 2 nw 2 Нет Непосредственная связь
Сеть 3 nw 3 Нет Непосредственная связь
Сеть 4 nw 2 GW-C 1270
nw 3 GW-B 1180
Сеть 5 nw 2 GW-C 1270
nw 3 GW-B 2130
Сеть 6 nw 2 GW-C 2040
nw 3 GW-B 1180
Рис. 4.4.8.3.3. Пример маршрутной таблицы
Для того чтобы обеспечить работу с большими и сложными
сетями, в IGRP введены три усовершенствования алгоритма Белма-
на-Форда:
1. Для описания путей вместо простой, введена векторная мет-
рика. Расчет комбинированной метрики проводится с использова-
нием формулы [1]. Применение векторной метрики позволяет адап-
тировать систему с учетом различных видов сервиса.
2. Вместо выбора одного пути с минимальной метрикой, инфор-
мационный поток может быть поделен между несколькими путями
с метрикой, лежащей в заданном интервале. Распределение потоков
определяется соотношением величин комбинированной метрики.
Таким образом, используются маршруты с комбинированной метри-
кой меньше некоторого предельного значения М, а также с метри-
кой меньше V*M, где V — значение вариации М (обычно задается
оператором сети).
3. Существуют определенные проблемы с вариацией. Трудно оп-
ределить стратегию использования вариации V>1 и избежать за-
цикливания пакетов. В современных реализациях V=l.
4. Разработан ряд мер, препятствующих осцилляциям маршру-
тов при изменении топологии сети.
Значение вариации, отличное от единицы, позволяет использо-
вать одновременно два или более путей с разной пропускной способ-
ностью. При дальнейшем увеличении вариации можно разрешить
не только более «медленные» сегменты пути, но и идущие в обрат-
ном направлении, что приведет с неизбежностью к «бесконечному»
Циклическому движению пакетов.
Протокол маршрутизации IGRP предназначен для работы с не-
сколькими типами сервиса (TOS) и несколькими протоколами. Под
BOO
Гпава 4
типами сервиса в TCP/IP подразумевается оптимизация маршрути-
зации по пропускной способности, задержке, надежности и т.д. Для
решения этой задачи можно использовать весовые коэффициента
К1 и К2 (формула [1] данного раздела). При этом для каждого TOS
подготавливается своя маршрутная таблица. Среди мер, обеспечива-
ющих стабильность топологии связей, следует отметить следующее
правило, которое поясняется на приведенном ниже примере.
Сеть 1
Сеть 2 j— Маршрутизатор В
Маршрутизатор А сообщает В о маршруте к сети 1. Когда же В
посылает сообщения об изменении маршрутов в А, он ни при каких
обстоятельствах не должен упоминать сеть 1. Т.е. сообщения об
изменении маршрута, направленные какому-то маршрутизатору, не
должны содержать данных об объектах, непосредственно с ним свя-
занных. Сообщения об изменении маршрутов должны содержать:
- адреса сетей, с которыми маршрутизатор связан непосредственно;
- пропускную способность каждой из сетей;
- топологическую задержку каждой из сетей;
- надежность передачи пакетов для каждой сети;
- загруженность канала для каждой сети;
- MTU для каждой сети.
Следует еще раз обратить ваше внимание, что в IGRP не исполь-
зуется измерение задержек, измеряется только надежность и коэф-
фициент загрузки канала. Надежность определяется на основе со-
общений интерфейсов о числе ошибок.
Существует 4 временные константы, управляющие процессом
распространения маршрутной информации (эти константы опреде-
ляются оператором сети):
- период широковещательных сообщений об изменении марш-
рутов (это время по умолчанию равно tUPD=90 сек);
- время существования — если за это время не поступило ника-
ких сообщений о данном маршруте, он считается нерабочим. Это
время в несколько раз больше периода сообщений об изменениях
(по умолчанию в 3 раза). <
- время удержания — когда какой-то адресат становится недо-
стижим, он переходит в режим выдержки. В этом режиме никакие
новые маршруты, ведущие к нему, не воспринимаются. Длитель-
ность этого режима и называется временем удержания. Обычно это
время равно 3tUPD +10 сек.
Сети передачи данных. Метод доступа
601
- время удаления — если в течение данного времени не посту-
пило сообщений о доступе к данному адресату, производится удале-
ние записи о нем из маршрутной базы данных (по умолчанию это
время равно 7 ^upd^*
IGRP-сообщение вкладывается в IP-пакет, и имеет следующие
поля:
version — Номер версии протокола 4 байта
opcode — Код операции
edition — Код издания
asystem — Номер автономной системы
Ninterior, N system, Nexterior — Числа субсетей в локальной сети,
в автономной системе и вне автономной системы.
checksum — Контрольная сумма IGRP-заголовка и данных
Version — Номер версии в настоящее время равен 1. Пакеты с
другим номером версии игнорируются.
Opcode — Код операции определяет тип сообщения и может
принимать значения:
1 — изменение; 2 — запрос.
Edition — Серийный номер (издание), который увеличивается
при каждом изменении маршрутной таблицы. Это позволяет мар-
шрутизатору игнорировать информацию, которая уже содержится в
его базе данных.
Asystem — Номер автономной системы. Согласно нормам Cisco
маршрутизатор может входить в более чем одну автономную систе-
му. В каждой AS работает свой протокол и они могут иметь совер-
шенно независимые таблицы маршрутизации. Хотя в IGRP допус-
кается «утечка» маршрутной информации из одной автономной си-
стемы в другую, но это определяется' не протоколом, а
администратором.
Ninterior, nsystem, и nexterior определяют числа записей в каж-
дой из трех секций сообщения об изменениях.
Checksum — Контрольная сумма заголовка и маршрутной ин-
формации, для вычисления которой используется тот же алгоритм,
что и в UDP, TCP и ICMP.
IGRP запрос требует от адресата прислать свою маршрутную
таблицу. Сообщение содержит только заголовок. Используются
поля version, opcode и asystem, остальные поля обнуляются. IP-
пакет, содержащий сообщение об изменении маршрутов, имеет 1500
байт (включая IP-заголовок). Для описанной выше схемы это по-
зволяет включить в пакет до 104 записей. Если требуется больше
записей, посылается несколько пакетов. Фрагментация пакетов не
применяется.
602
Глава 4
Ниже приведено описание структуры для маршрута:
Number — 3 октета IP-адреса.
delay — Задержка в десятках микросекунд 3 октета,
bandwidth — Пропускная способность, в Кбит/с 3 октета.
uchar mtu — MTU, в октетах 2 октета.
reliability — Процент успешно переданных пакетов tx/rx 1 октет,
load — Процент занятости канала 1 октет.
hopcount — Число шагов 1 октет.
Субполе описание маршрута Number определяет IP-адрес места
назначения, для экономии места здесь используется только 3 его
байта. Если поле задержки содержит только единицы, место назна-
чения недостижимо.
Пропускная способность измеряется в величинах, обратных бит/
сек, умноженных на 1010. (Т.е., если пропускная способность равна
N Кбит/с, то ее измерением в IGRP будет 10000000/N.). Надеж-
ность измеряется в долях от 255 (т.е. 255 соответствует 100%).
Загрузка измеряется также в долях от 255, а задержка в десятках
миллисекунд.
Ниже приведены значения по умолчанию для величин задержки
и пропускной способности
Вид среды
Спутник
Ethernet
1.544 Мбит/с
64 Кбит/с
56 Кбит/с
10 Кбит/с
1 Кбит/с
Задержка
200,000 (2 сек)
100 (1 мсек)
2000 (20 мсек)
2000
2000
2000
2000
Пропускная способность
20 (500 Мбит/с)
1,000
6,476
156,250
178,571
1,000,000
10,000,000
Комбинированная метрика в действительности вычисляется по
следующей формуле (для версии Cisco 8.0(3)):
Метрика = [К 1* пропуск ная_способность +
4- (К2*пропускная_способность)/(256 — загрузка) г+
+ К3*задержка] * [К5/(надежность + К4)].
Если К5 == 0, член надежности отбрасывается. По умолчанию в
IGRP К1 == КЗ == 1, К2 == К4 == К5 == 0, а загрузка лежит>в
интервале от 1 до 255.
В начале 90-х годов разработана новая версия протокола IGRP
— EIGRP с улучшенным алгоритмом оптимизации маршрутов, ср-
Сети передачи данных. Метод доступа
603
кращенным временем установления и масками субсетей перемен-
ной длины. EIGRP поддерживает многие протоколы сетевого уров-
ня. Рассылка маршрутной информации здесь производится лишь
при изменении маршрутной ситуации. Протокол периодически рас-
сылает соседним маршрутизаторам короткие сообщения hello. По-
лучение отклика-подтверждения означает, что сосед функционален
и можно осуществлять обмен маршрутной информацией. Протокол
EIGRP использует таблицы соседей (адрес и интерфейс), топологи-
ческие таблицы (адрес места назначения и список соседей, объявля-
ющих о доступности этого адреса), состояния и метки маршрутов.
Для каждого протокольного модуля создается своя таблица сосе-
дей. Протоколом используется сообщения типа hello (мультикаст-
ная адресация), подтверждение (acknowledgement} посылается толь-
ко отправителю hello), актуализация (update), запрос (query; всегда
мультикастный) и отклик (reply; посылается отправителю запро-
са). Маршруты здесь делятся на внутренние и внешние — получен-
ные от других протоколов или записанные в статических таблицах.
Маршруты помечаются идентификаторами их начала. Внешние мар-
шруты характеризуются следующей информацией:
• Идентификатор маршрутизатора EIGRP, который осуществ-
ляет рассылку информации о маршруте.
• Номер AS, где расположен адресат маршрута.
• Метка администратора.
• Идентификатор протокола.
• Метрика внешнего маршрута.
• Битовые флаги маршрута по умолчанию.
Протокол EIGRP полностью совместим с IGRP, он обеспечивает
работу в сетях IP, Apple Talk и Novell.
4.4.8.4. Внешний протокол маршрутизации BGP-4
Протокол BGP (RFC-1267, BGP-3; RFC-1268; RFC-1467, BGP-4;
-1265-66, 1655) разработан компаниями IBM и CISCO. Главная
цель BGP — сократить транзитный трафик. Местный трафик либо
начинается, либо завершается в автономной системе (AS); в против-
ном случае - это транзитный трафик. Системы без транзитного
трафика не нуждаются в BGP (им достаточно EGP для общения с
транзитными узлами). Но не всякая ЭВМ, использующая протокол
BGP, является маршрутизатором, даже если она обменивается мар-
шрутной информацией с пограничным маршрутизатором соседней
автономной системы. AS передает информацию только о маршру-
тах, которыми она сама пользуется. BGP-маршрутизаторы обмени-
604
Гпава 4
ваются сообщениями об изменении маршрутов (UPDATE-сообще-
ния, рис. 4.4.8.4.1). Максимальная длина таких сообщений состав-
ляет 4096 октетов, а минимальная 19 октетов. Каждое сообщение
имеет заголовок фиксированного размера. Объем информационных
полей зависит от типа сообщения.
0 8 16 24 31
Маркер 16 октетов
Длина Тип
Рис. 4.4.8.4.7. Формат BGP-сообщений об изменениях маршрутов
Поле маркер содержит 16 октетов и его содержимое может лег-
ко интерпретироваться получателем. Если тип сообщения «OPEN»,
или если код идентификации в сообщении OPEN равен нулю, то
поле маркер должно быть заполнено единицами. Маркер может
использоваться для обнаружения потери синхронизации в работе
BGP-партнеров. Поле длина имеет два октета и определяет общую
длину сообщения в октетах, включая заголовок. Значение этого
поля должно лежать в пределах 19-4096. Поле тип представляет
собой код разновидности сообщения и может принимать следующие
значения:
1 OPEN (открыть)
2 UPDATE (изменить)
3 NOTIFICATION (внимание)
4 KEEPALIVE (еще жив)
После того как связь на транспортном протокольном уровне
установлена, первое сообщение, которое должно быть послано — это
OPEN. При успешном прохождении этого сообщения партнер дол-
жен откликнуться сообщением KEEPALIVE («Еще жив»). После
этого возможны любые сообщения. Кроме заголовка сообщение OPEN
содержит следующие поля (рис. 4.4.8.4.2):
Поле версия описывает код версии используемого протокола, на
сегодня для BGP он равен 4. Двух-октетное поле моя автономная
система определяет код AS отправителя. Поле время сохранения
характеризует время в секундах, которое отправитель предлагает
занести в таймер сохранения. После получения сообщения OPEN
BGP-маршрутизатор должен выбрать значение времени сохранения.
Обычно выбирается меньшее из полученного в сообщении OPEN я
значения, определенного при конфигурации системы (О-Зсек). Вре-
Сети передачи данных. Метод доступа
605
О 8 16 31
Версия
Моя автономная система Время сохранения
BGP идентификатор
Код идентификации
Идентификационные данные
Рис. 4.4.8.4.2 Формат сообщения OPEN
мя сохранения определяет максимальное время в секундах между
сообщениями KEEPALIVE и UPDATE или между двумя UPDATE-
сообщениями. Каждому узлу в рамках BGP приписывается 4-ок-
тетный идентификатор (BGP-identifier, задается при инсталляции
и идентичен для всех интерфейсов локальной сети). Если два узла
установили два канала связи друг с другом, то согласно правилам
должен будет сохранен канал, начинающийся в узле, BGP-иденти-
фикатор которого больше. Предусмотрен механизм разрешения про-
блемы при равных идентификаторах.
Одно-октетный код идентификации позволяет организовать сис-
тему доступа, если он равен нулю, маркер всех сообщений заполня-
ется единицами, а поле идентификационных данных должно иметь
нулевую длину. При неравном нулю коде идентификации должна
быть определена процедура доступа и алгоритм вычисления кодов
поля маркера. Длина поля идентификационных данных определя-
ется по формуле:
Длина сообщения = 29 + длина поля идентификационных данных.
Минимальная длина сообщения OPEN составляет 29 октетов,
включая заголовок.
Сообщения типа UPDATE (изменения) используются для пере-
дачи маршрутной информации между BGP-партнерами. Этот тип
сообщения позволяет сообщить об одном новом маршруте или объя-
вить о закрытии группы маршрутов, причем объявление об откры-
тии нового и закрытии старых маршрутов возможно в пределах
одного сообщения. Сообщение UPDATE всегда содержит стандарт-
нь1й заголовок и может содержать другие поля в соответствии со
схемой:
606
Гпава 4
О 15
Длина списка отмененных маршрутов 2 октета ,
Отмененные маршруты Длина переменная
Полная длина списка атрибутов пути 2 октета
Атрибуты пути Длина переменная
Информация о доступности сетевого уровня Длина переменная
Рис. 4.4.8.4.3 Формат UPDATE-сообщения
Если длина списка отмененных маршрутов равна нулю, ни один
маршрут не отменен, а поле отмененные маршруты в сообщении
отсутствует. Поле отмененные маршруты имеет переменную длину
и содержит список IP-адресных префиксов маршрутов, которые ста-
ли недоступны. Каждая такая запись имеет формат:
Длина (1 октет)
Префикс (длина переменная)
Длина префикса (в битах), равная нулю означает, что префикс
соответствует всем IP-адресам, а сам имеет нулевой размер. Поле
префикс содержит IP-адресные префиксы, за которыми следуют раз-
ряды, дополняющие их до полного числа октетов. Значения этих
двоичных разрядов смысла не имеют.
Нулевое значение полной длины списка атрибутов пути говорит
о том, что информация о доступности сетевого уровня в UPDATE-
сообщении отсутствует. Список атрибутов пути присутствует в лю-
бом UPDATE-сообщении. Этот список имеет переменную длину, а
каждый атрибут содержит три составные части: тип атрибута, дли-
ну атрибута и значение атрибута. Тип атрибута представляет собой
двух-октетное поле со структурой:
0 В 15
Флаги атрибута Код типа атрибута
Старший бит (битО) поля флаги атрибута определяет, является
ли атрибут опционным (бит0=1) или стандартным (well-known,
бит0=0). Бит 1 этого поля определяет, является ли атрибут пере-
ходным (бит1=1) или непереходным (бит1=0). Для обычных атри-
Сети передачи данных. Метод доступа
607
бутов этот бит должен быть равен 1. Третий бит (бит 2) поля
Флагов атрибута определяет, является ли информация в опцион-
ном переходном атрибуте полной (бит2=0) или частичной (бит2=1).
Для обычных и для опционных непереходных атрибутов этот бит
должен быть равен нулю. Бит 3 поля флагов атрибута информиру-
ет о том, имеет ли длина атрибута один (битЗ=0) октет или два
октета’ (битЗ=1). БитЗ может быть равен 1 только в случае, когда
длина атрибута более 255 октетов. Младшие 4 бита октета флагов
атрибута не используются (и должны обнуляться). Если битЗ=О,
то третий октет атрибута пути содержит длину поля данных атри-
бута в октетах. Если же битЗ=1, то третий и четвертый октеты
атрибута пути хранят длину поля данных атрибута. Остальные
октеты поля атрибут пути характеризуют значение атрибута и
интерпретируются согласно флагам атрибута.
Атрибуты пути бывают «стандартные обязательные» (well-known
mandatory), «стандартные на усмотрение оператора», «опционные
переходные» и «опционные непереходные». Стандартные атрибуты
должны распознаваться любыми BGP-приложениями. Опционные
атрибуты могут не распознаваться некоторыми приложениями. Об-
работка нераспознанных атрибутов задается битом 1 поля флагов.
Пути с нераспознанными переходными опционными атрибутами дол-
жны восприниматься, как рабочие. Один и тот же атрибут может
появляться в списке атрибутов пути только один раз.
Предусмотрены следующие разновидности кодов типа атрибута:
ORIGIN (код типа =1) — стандартный обязательный атрибут,
который определяет происхождение путевой информации. Генери-
руется автономной системой, которая является источником марш-
рутной информации. Значение атрибута в этом случае может при-
нимать следующие значения:
Код атрибута Описание
0 IGP - информация достижимости сетевого уровня является внутренней по отношению к исходной автономной системе;
1 EGP - информация достижимости сетевого уровня получена
с помощью внешнего протокола маршрутизации;
2 INCOMPLETE - информация достижимости сетевого уровня получена каким-то иным способом.
AS PATH (код типа =2) также является стандартным обяза-
тельным атрибутом, который составлен из совокупности сегментов
пути. Атрибут определяет автономные системы, через которые дос-
тавлена маршрутная информация. Когда BGP-маршрутизатор пере-
608
Гпава 4
дает описание маршрута, которое он получил от своего BGP-партне-
ра, он модифицирует А8_РАТН-атрибут, соответствующий этому
маршруту, если информация передается за пределы автономной сис-
темы. Каждый сегмент AS_PATH состоит из трех частей <тип сег-
мента пути, длина сегмента пути и оценка сегмента пути>. Тип
сегмента пути представляет в свою очередь одно-октетное поле, ко-
торое может принимать следующие значения:
Код типа сегмента Описаний
1 AS SET: неупорядоченный набор маршрутов в UPDATE сообщении;
2 AS SEQUENCE: упорядоченный набор маршрутов автономной системы в UPDATE-сообщении.
Длина сегмента пути представляет собой одно-октетное поле,
содержащее число AS, записанных в поле оценка сегмента пути.
Последнее поле хранит один или более кодов автономной системы,
по два октета каждый.
NEXT_HOP (код типа == 3) — стандартный обязательный атри-
бут, определяющий IP-адрес пограничного маршрутизатора, который
должен рассматриваться как цель следующего шага на пути к точ-
ке назначения.
MULI-EXIT-DISC (код типа = 4) представляет собой опцион-
ный непереходной атрибут, который занимает 4 октета и является
положительным целым числом. Величина этого атрибута может
использоваться при выборе одного из нескольких путей к соседней
автономной системе.
LOCAL-PREF (код типа = 5) является опционным атрибутом,
занимающим 4 октета. Он используется BGP-маршрутизатором,
чтобы сообщить своим BGP-партнерам в своей собственной авто-
номной системе степень предпочтения объявленного маршрута.
ATOMIC-AGGREGATE (код типа = 6) представляет собой стан-
дартный атрибут, который используется для информирования парт-
неров о выборе маршрута, обеспечивающего доступ к более широко-
му списку адресов.
AGGREGATOR (код типа =7) — опционный переходной атри-
бут с длиной в 6 октетов. Атрибут содержит последний код авто-
номной системы, который определяет агрегатный маршрут (занима-
ет два октета), и IP-адрес BGP-маршрутизатора, который сформиро-
вал этот маршрут (4 октета). Объем информации о достижимости
сетевого уровня равен (в октетах):
Сети передачи данных. Метод доступа 60S
Длина сообщения UPDATE — 23 — полная длина атрибутов
пуТИ___длина списка отмененных маршрутов. Информация о дос-
тижимости кодируется в следующей форме:
Длина (1 октет)
Префикс (переменная длина)
Поле длина определяет длину IP-адресного префикса в битах.
Если длина равна нулю, префикс соответствует всем IP-адресам.
Префикс содержит IP-адресные префиксы и двоичные разряды, до-
полняющие код до целого числа октетов.
Информация о работоспособности соседних маршрутизаторов
получается из KEEPALIVE-сообщений, которые должны посылать-
ся настолько часто, чтобы уложиться во время, отведенное тайме-
ром сохранения (HOLD). Обычно это время не должно превышать
одной трети от времени сохранения, но не должно быть и меньше 1
секунды. Если выбранное значение времени сохранения равно нулю,
периодическая посылка KEEPALIVE-сообщений не обязательна.
NOTIFICATION-сообщения посылаются, когда обнаружена ошиб-
ка. BGP-связь при этом немедленно прерывается. Помимо заголов-
ка NOTIFICATION-сообщение имеет следующие поля:
о 8 16 31
Код ошибки Субкод ошибки
Код ошибки представляет собой одно-октетное поле и указыва-
ет на тип данного сообщения. Возможны следующие коды ошибки:
При отсутствии фатальной ошибки BGP-партнер может в любой
момент прервать связь, послав NOTIFICATION-сообщение с кодом
ошибки прерывание.
Таблица 4.4.8.4.1. Коды ошибок
_ Код ошибки Описание
_ I Ошибка в заголовке сообщения.
___2 Ошибка в сообщении OPEN
Ошибка в сообщении UPDATE
4 Истекло время сохранения
_ 5 Ошибка машины конечных состояний
6 Прерывание
20 N2 3430 Семенов
610
Гпава 4
Таблица 4.4.8.4.2 Субкоды ошибок
Ошибка Субкод Описание
Заголовок 1 Соединение не синхронизовано
2 Неверная длина сообщения
3 Неверный тип сообщения
Сообщения OPEN 1 Неверный код версии
2 Ошибочный код AS-партнера
3 Ошибочный идентификатор BGP
4 Ошибка в коде идентификации
5 Ошибка при идентификации
6 Неприемлемое время сохранения
Сообщения UPDATE 1 Ошибка в списке атрибутов
2 Не узнан стандартный атрибут
3 Отсутствует стандартный атрибут
4 Ошибка в флагах атрибута
5 Ошибка в длине атрибута
6 Неправильный атрибут ORIGIN
7 Циклический маршрут
8 Ошибка в атрибуте NEXT HOP
9 Ошибка в опционном атрибуте
10 Ошибка в сетевом поле
11 Ошибка в AS PATH
Одно-октетное поле субкод ошибки предоставляет дополнитель-
ную информацию об ошибке. Каждый код ошибки может иметь
один или более субкодов. Если поле содержит нуль, это означает,
что никаких субкодов не определено.
Вся маршрутная информация хранится в специальной базе дан-
ных RIB (Routing Information Base). Маршрутная база данных BGP
состоит из трех частей:
1. Adj-RIBs-In: Запоминает маршрутную информацию, которая
получена из UPDATE-сообщений. Это список
маршрутов, из которого можно выбирать. (Policy t
Information Base — PIB).
2. Loc-RIB: Содержит локальную маршрутную информацию, *
которую BGP-маршрутизатор отобрал, руковод-
ствуясь маршрутной политикой, из Adj-RIBs-In.
3. Adj-RIBs-Out: Содержит информацию, которую локальный BGP-
маршрутизатор отобрал для рассылки соседям с
помощью UPDATE-сообщений.
Так как разные BGP-партнеры могут иметь разную политику *
маршрутизации, возможны осцилляции маршрутов. Для исключе*
ния этого необходимо выполнять следующее правило: если исполь-
Сети передачи данных. Метод доступа
S71
зуемый маршрут объявлен не рабочим (в процессе корректировки
получено сообщение с соответствующим атрибутом), до переключе-
ния на новый маршрут необходимо ретранслировать сообщение о
недоступности старого всем соседним узлам.
Протокол BGP позволяет реализовать маршрутную политику,
определяемую администратором AS (см. раздел «Автономные сис-
темы и маршрутная политика»). Политика отражается в конфигу-
рационных файлах BGP. Маршрутная политика это не часть про-
токола, она определяет решения, когда место назначения достижимо
несколькими путями, политика отражает соображения безопаснос-
ти, экономические интересы и пр. Количество'сетей в пределах од-
ной AS не лимитировано. Один маршрутизатор на много сетей по-
зволяет минимизировать таблицу маршрутов.
BGP — использует три таймера:
ConnectRetry — (сбрасывается при инициализации и коррек-
ции; 120 сек),
Holdtime — (запускается при получении команд Update или
KeepAlive; 90сек) и
KeepAlive — (запускается при посылке сообщения KeepAlive;
ЗОсек).
BGP отличается от RIP и OSPF тем, что использует TCP в
качестве транспортного протокола. Две системы, использующие BGP,
связываются друг с другом и пересылают посредством TCP полные
таблицы маршрутизации. В дальнейшем обмен идет только в слу-
чае каких-то изменений. ЭВМ, использующая BGP, не обязательно
является маршрутизатором. Сообщения обрабатываются только
после того, как они полностью получены.
BGP является протоколом, ориентирующимся на вектор рассто-
яния. Вектор описывается списком AS по 16 бит на AS. BGP
регулярно (каждые ЗОсек) посылает соседям TCP-сообщения, под-
тверждающие, что узел жив (это не тоже самое, что «keepalive» фун-
кция в TCP). Если два BGP-маршрутизатора попытаются устано-
вить связь друг с другом одновременно, такие две связи могут быть
Установлены. Такая ситуация называется столкновением, одна из
связей должна быть ликвидирована. При установлении связи мар-
шрутизаторов сначала делается попытка реализовать высший из
протоколов (например, BGP-4), если один из них не поддерживает
ЭтУ версию, номер версии понижается.
Протокол BGP-4 является усовершенствованной версией (по срав-
нению с BGP-3). Эта версия позволяет пересылать информацию о
МаРШруте в рамках одного IP-пакета. Концепция классов сетей и
сУбсети находятся вне рамок этой версии. Для того чтобы приспо-
642
Гпава 4
собиться к этому, изменена семантика и кодирование атрибута
AS_PASS. Введен новый атрибут LOCAL_PREF (степень предпоч-
тительности маршрута для собственной AS), который упрощает про-
цедуру выбора маршрута. Атрибут INTERASMETRICS переиме-
нован в MULTI_EXIT_DISC (4 октета; служит для выбора пути к
одному из соседей). Введены новые атрибуты ATOMIC_AGGREGATE
и AGGREGATOR, которые позволяют группировать маршруты.
Структура данных отражается и на схеме принятия решения, кото-
рая имеет три фазы:
1. Вычисление степени предпочтения для каждого маршрута,
полученного от соседней AS, и передача информации другим узлам
местной AS.
2.Выбор лучшего маршрута из наличного числа для каждой
точки назначения й укладка результата в Loc-RIB.
3. Рассылка информации из Loc_RIB всем соседним AS соглас-
но политике, заложенной в RIB. Группировка маршрутов и редак-
тирование маршрутной информации.
Бесклассовая интердоменная маршрутизация (CIDR — Classless
Interdomain Routing, RFC-1520, -1519, -1518, -1517) - способ избе-
жать того, чтобы каждая С-сеть требовала свою таблицу маршрути-
зации. Основополагающий принцип CIDR заключается в группи-
ровке (агрегатировании) IP-адресов таким образом, чтобы сокра-
тить число входов в таблицах маршрутизации (RFC-1467, RFC-1466).
Протокол совместим с RIP-2, OSPF и BGP-4. Основу протокола
составляет идея бесклассовых адресов, где нет деления между по-
лем сети и полем ЭВМ. Дополнительная информация, например
32-разрядная маска, выделяющая поле адреса сети, передается в
рамках протокола маршрутизации. При этом выдерживается стро-
гая иерархия адресов: провайдер > предприятие > отдел/здание >
сегмент локальной сети. Групповой (агрегатный) адрес воспринима-
ется маршрутизатором как один адрес. Группу может образовывать
только непрерывная последовательность IP-адресов. Такой бесклас-
совый интернетовский адрес часто называется IP-префиксом. Так
адрес 192.1.1.0/24 означает диапазон адресов 192.1.1.0 —
192.1.1.255, а адрес 192.1.128.0/17 описывает диапазон 192.1.128.0
— 192.1.255.255, таким образом, число, следующее после косой
черты, задает число двоичных разрядов префикса. Это представле-
ние используется при описании политики маршрутизации и самих
маршрутов (см. разд. 4.4.8.4 - «Маршрутная политика»). Для при-
веденных примеров это в терминах масок выглядит следующим
образом:
Сети передачи данных. Метод доступа
613
О 8 16 24 31
12345678 12345678 12345678 12345678
11111111 11111111 11111111 00000000
111111 1 1 11111111 10000000 00000000
24
17
24 и 17 длины префикса сети.
Следует помнить, что маски с разрывами здесь недопустимы.
Ниже приведена таблица метрик маршрутизации для различных
протоколов.
Протокол Метрика Диапазон Код ° маршрут недостижим"
RIP Число скачков 0-15 16
Hello Задержка в ms 0-29999 30000
BGP Не определена 0-65534 65535
Колонка «маршрут недостижим» содержит коды метрики, кото-
рые говорят о недоступности маршрута. Обычно предполагается, что
при посылке пакета из точки <А> в точку <В>, маршруты их в
одном и другом направлении совпадают. Но это не всегда так.
Пример, когда маршруты пакетов «туда» и «обратно» не совпадают,
представлен на рис. 4.4.8.4.4. В предложенной схеме имеется две
ЭВМ «Место назначения» и «ЭВМ-отправитель», а также два марш-
рутизатора «GW-2» и «GW-1».
Предполагается, что оператор находится в ЭВМ-отправителе.
Команда traceroute 192.148.166.33 в этом случае выдаст:
Рис. 4.4.8.4.4. Пример разных маршрутов для пути «туда»
и«обратно».
614
Гпава 4
1 GW-1 (192.148.166.35)
2 Место назначение (192.148.166.33)
Команда же traceroute 192.148.165.80 распечатает:
1 GW-1 (192.148.166.35)
2 GW-2 (192.148.166.7)
3 Место назначения (192.148.165.80)
Команда traceroute -g 192.148.165.80 сообщит вам:
1 GW-1 (192.148.166.35) В этом режиме маршрутизатор ; не откликается
3 Место назначения 4 GW-1 5 ЭВМ-отправитель (192.148.165.80) “ (192.148.166.35) | (192.148.166.32) 2
Из приведенных примеров видна также полезность команды
traceroute для понимания того, как движутся пакеты в сети. В неко-^
торых случаях это может йомочь оптимизировать маршрутизацша
и улучшить пропускную способность сети.
Другой полезной командой является netstat, которая позволяет-
получить разнообразную информацию о состоянии сети. Существуй
ет четыре модификации этой команды: *
- а отображает состояния всех соединений; j
- i отображает значения конфигурационных параметров; -X
- г отображает таблицу маршрутов; j
- v отображает статистику обмена локального Ethernet-интерфейса.*
Например, команда netstat -г может выдать:
Routing tables (таблицы маршрутизации)
Destination Gateway Flags Refcnt Use Interface-
Stavropol-GW.ITEP.RU nb UGHD 0 109 leO i
ihep.su itepgw UGHD 0 103 leO 1
mlO.ihep.su itepgw UGHD 0 16 leO 2
194.85.66.50 itepgw UGHD 0 455 leO
Kharkov.ITEP-Kharkov nb UGHD 0 105 leO
Bryansk-GW.ITEP.Ru nb UGHD 1 8113 leO s.
193.124.225.67 nb UGHD 0 0 leO :
ixwin.ihep.su itepgw UGHD 1 6450 leO
ihep.su itepgw UGHD 0 14 leO
192.148.166.21 nb UGHD 0 109 leO
ihep.su itepgw UGHD 0 224 leO .
193.124.225.71 nb UGHD 0 10 leO *
194.85.112.0 ITEP-FDDI- UGD 0 253 leO
BBone.ITEP
default itepgw UG 10 102497 leO
Сети передачи данных. Метод доступа
615
Здесь приведен только фрагмент маршрутной таблицы. Колонка
destination указывает на конечную точку маршрута (default — мар-
пут по умолчанию), колонка gateway - имена маршрутизаторов,
через которые достижим адресат. Флаг «U» (Up) свидетельствует о
том что канал в рабочем состоянии. Флаг «G» указывает на то, что
маршрут проходит через маршрутизатор (gateway). При этом вто-
рая колонка таблицы содержит имя этого маршрутизатора. Если
флаг «О» отсутствует, ЭВМ непосредственно связана с указанной
сетью. Флаг «D» указывает на то, что маршрут был добавлен дина-
мически. Если маршрут связан только с конкретной ЭВМ, а не с
сетью, он помечается флагом «Н» (host), при этом первая колонка
таблицы содержит его IP-адрес. Базовая команда netstat может обес-
печить следующую информацию:
Active Internet connections (активные Интернет связи)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 127.0.0.1.1313 127.0.0.1.sunrpc TIME_WAIT
tcp 0 0 ns.1312 193.124.18.65.smtp SYN_SENT
tcp 0 0 127.0.0.1.1311 127.0.0.1.sunrpc TIME_WA1T
tcp 0 0 ns.1310 ns.domain TIME JW AIT
tcp 0 0 127.0.0.1.1309 127.0.0.1.sunrpc TIME_WAIT
tcp 39 24576 ns.nntp Bryansk- GW.ITEP.1697 ESTABLISHED
tcp 0 0 ns.telnet semenov. 1802 ESTABLISHED
tcp 0 188 ns. 1033 xmart.desy.de.6000 ESTABLISHED
udp 0 0 127.0.0. Ldomain * *
udp 0 0 ns.domain **
Active UNIX domain sockets (активные UNIX-соединители домена)
Address Type Recv-Q Send-Q Vnode Conn
ff64b38c stream 0 0 * ffl3187c 0
ff64b28c dgram 0 0 0 0
ff64698c dgram 0 0 ffl37fa8 0
Refs
0
0
0
Nextref Addr
0 /dev/printer
0
0 /dev/log
4.4.8.5. Бесклассовая междоменная маршрутизация [CIDR]
Вряд ли отцы-создатели Интернет предполагали, что когда-либо,
тем более при их жизни возникнет дефицит IP-адресов. Уже в
1996 году было зарегистрировано более 100000 сетей. Разбивка
Сетей на три класса А, В и С уже не может отвечать современным
требованиям. Сеть класса А с ее 16000000 адресов слишком вели-
616
Гпава 4
ка, а класса С с 254 адресами, как правило, слишком мала. Сети
класса В с 65536 машинами может показаться оптимальными, но
на практике каждая из этих сетей не обеспечивает оптимального
использования адресного пространства и всегда остаются неисполь-
зованные адреса (для классов В и А количество пустующих адресов
оказывается обычно значительным). Адресные блоки заказываются
администраторами, которые полагают, что однажды их организация
или фирма станет великой с тысячами ЭВМ (пока же у них есть
всего несколько машин). Надо сказать, что такие оптимистические
прогнозы сбываются крайне редко. Проблема маршрутизации мо-
жет быть решена путем реализации более глубокой структурной
иерархии, где каждый IP-адрес имеет код страны, региона, города,
сети, но при этом размер адреса должен существенно превышать 32
разряда, так как адреса неизбежно будут использоваться крайне не
эффективно — ведь Китаю и Монако будут выделены равные адрес-
ные зоны. Это может стать возможным при внедрении технологии
IPv6.
Если бы в адресах класса С для кода номера ЭВМ было выделе-
но 10 или 11 бит (1024-2048), ситуация была бы более приемле-
мой. Маршрутизатор рассматривает IP-адресную среду на двух уров-
нях — адрес сети и адрес ЭВМ, при этом практически они работают
только с адресами сетей. Число записей в маршрутной таблице дол-
жно будет быть равным половине миллиона записей (по числу бло-
ков С-адресов).
Проблема может быть решена, если забыть про разбиение всей
совокупности IP-адресов на классы. Такая модель реализуется в
рамках протокола CIDR (Classless InterDomain Routing). В этой
модели каждой сети ставится в соответствие определенное число
смежных блоков по 256 адресов. Далее используется известное гео-
графическое зонное распределение IP-адресов (см. Ethernet в Интер-
нет, а также RFC-1519). Протокол при просмотре маршрутных таб-
лиц предполагает применение специальных масок и индексных ме-
ханизмов.
4.4.S.6. Автономные системы
Базовым элементом технологии Интернет является модуль IP.
Его центральной частью является таблица маршрутов, используе-
мая для принятия решения о направлении IP-пакета по тому или
иному пути. Формат таблицы маршрутов задается используемым
протоколом маршрутизации, а содержание — определяет админист-
ратор сети. Прямая маршрутизация имеет место при обмене паке-
тами между машинами, входящими в одну сеть. Большинство со-
Сети передачи данных. Метод доступа
617
временных протоколов маршрутизации являются динамическими,
то есть такими, где таблицы маршрутизации изменяются по мере
изменения структуры и параметров окружающей сети. Такие про-
токолы заметно повышают надежность сети в целом, так как при
выходе из строя какого-либо узла или канала связи поток пакетов
может быть автоматически направлен в обход по резервному марш-
руту. При этом пользователи сети не должны ожидать момента,
когда администратор сети вернется из отпуска, проснется или вер-
нется из кафетерия и сам внесет необходимые коррективы.
Автономной системой называют такую локальную сеть или си-
стему сетей, которые имеют единую администрацию и общую марш-
рутную политику.
Пользователь, связанный только с одним сервис-провайдером,
должен принадлежать к общей с ним AS. Автономная система дол-
жна обязательно создаваться, когда оператор сети связан с более
чем одной AS с отличной от его маршрутной политикой. Если же
пользователь обращается к услугам двух или более сервис-провай-
деров, придерживающихся различных маршрутных политик, то он
должен создать свою независимую AS. Общим правилом является
использование максимально возможного числа маршрутов. Это по-
вышает надежность и способствует перераспределению нагрузки
между каналами.
Внедрение идеологии автономных систем сделали возможным
существенно облегчить процедуру маршрутизации, сократить требу-
емое число IP-адресов и создать гибкую и эффективную схему опи-
сания маршрутной политики.
4.4.8.7. Маршрутная политика
Содержанием политики маршрутизации являются правила об-
мена маршрутной информацией между автономными системами
(RIPE-181.txt, RFC-1786). Не следует путать «маршрутную поли-
тику» и просто «политику», между ними такое же различие, как
между «милостивым государем» и «государем». Способы их описа-
ния разнятся столь же значительно. При описании обычной поли-
тики одной из главных задач является сокрытие истинных намере-
ний, а одним из средств — многословие. При описании же марш-
рутной политики важна лаконичность и четкость. В Интернет для
решения этой задачи выработан стандарт, краткое изложение кото-
рого на конкретных примерах будет приведено ниже. Объектами
маршрутной политики являются автономные системы (aut-num) и
маршруты (route). Существует два акта маршрутной политики:
оповещение (announce) и восприятие (accept).
618
Гпава 4
Эти акты определяют взаимодействие с ближайшими соседями.
Совокупность информации, выданной всеми маршрутизаторами ре-
гиональной сети, описывает ее граф. Следует иметь в виду, что в
пределах автономной системы (AS) может работать только один
внутренний протокол маршрутизации (IGP), а обмен маршрутной
информацией между автономными системами происходит в соответ-
ствии с внешним протоколом маршрутизации (EGP). Эта идея про-
демонстрирована ца рис. 4.4.8.7.1. ЭВМ (или узлы) A1,B1,C1,D1 и
маршрутизатор G-1 составляют одну автономную систему, а
A2,B2,C2,D2,E2 и маршрутизатор G-2 — вторую.
Рис. 4.4.8.7.1. Схема связи автономных систем
Пусть имеются две автономные системы ASX и ASY, обмениваю-
щиеся маршрутной информацией. ASX знает, как можно достичь
сети Netl, которая может и не принадлежать ASX. Аналогично
ASY знает, как послать пакет для сети Net2.
Netl .... ASX <-» ASY . Net2
Для того чтобы пакеты попали из Netl в Net2 через ASX и ASY,
автономная система ASX должна анонсировать сеть Netl автоном-
ной системе ASY, используя один из внешних протоколов маршру-
тизации (EGP или BGP), a ASY должна воспринять эту информа-
цию и использовать. Предметом маршрутной политики в этом слу-
чае является решение ASX послать маршрутную информацию ASY,
а также решение ASY эту информацию принять и использовать. Не
существует никаких правил, которые бы вынуждали ASX и ASY к
принятию таких решений. Таким образом, протокол маршрутиза-
ции определяет формат маршрутной информации, способ ее пере-
сылки и хранения, но решения о ее посылке той или иной AS, а
также решение об использовании маршрутной информации, посту-
пающей извне остаются в руках администратора AS.
Сети передачи данных. Метод доступа
619
Так как все существующие протоколы маршрутизации исполь-
зуют при работе с пакетами только адрес места назначения, разде-
лить поток пакетов кроме как по этому параметру не возможно.
Если пакеты с одним и тем же адресом места назначения попали в
общий маршрутизатор, AS или канал связи, они обречены далее
двигаться вместе.
Особый случай составляет топология, при которой две AS име-
ют много возможных маршрутов связи с различными политиками
маршрутизации.
Рис. 4.4.8.7.2
Под каналом в данном случае подразумевается любая среда
коммуникации — Ethernet, FDDI и т.д,. Может так случиться, что
AS2 предпочитает использовать канал 2 только для обмена с AS4.
А канал 1 используется для связи с AS3 и в качестве резервного
маршрута (back-up) к AS4 в случае выхода из строя канала 2. Для
описания маршрутной политики используются атрибуты interas-in
и interas-out. Эти атрибуты позволяют описать локальные решения
AS, основанные на ее предпочтениях, так как это делается в прото-
колах BGP-4 или IGRP. Пример такого описания представлен ниже:
aut-num: AS2 — (номер автономной системы, формат:
А8<целое положительное число в интервале 1-65535>)
as-in: from AS3 10 accept AS3 AS4
(описание воспринимаемой маршрутной информации от других
AS-партнеров. Формат описания:
from <aut-num> <cost> accept <выражение маршрутной политики>;
здесь <aut-num> — относится к AS-соседям; <cost> — положи-
тельное целое число, характеризующее относительную ценность мар-
шрутов, чем меньше cost, тем предпочтительнее маршрут; ключе-
вые слова from (от) и accept (воспринимает) могут отсутствовать.)
Маршрутная политика (<выражение маршрутной политики>)
может иметь следующие форматы.
620
Гпава 4
1. Список из одного или нескольких кодов AS, AS-макро или
список маршрутов. Список маршрутов записывается в префиксной
форме, в качестве разделителей используются запятые и фигурные
скобки.
2. Список ключевых слов. В настоящее время определено клю-
чевое слово ANY, которое говорит о том, что речь может идти о
любых соседних AS.
3. Логическое выражение, включающее в себя объекты типа 1
или 2, объединенные операторами AND, OR, NOT, которые в данном
случае, строго говоря, не являются булевыми. Так например, AS1 OR
AS2 означает все маршруты AS1 или AS2. Или AS1 AND HepNet
означает маршрут AS1, принадлежащий объединению HepNet. NOT
AS3 означает любой маршрут кроме маршрутов AS3.
Приоритеты рператоров распределены в следующем порядке:
для оператора () слева направо; для NOT — справа на лево; для
AND и OR — слева направо.
В отсутствии логических операторов элементы списка (AS, AS-
макро, объединения и списки маршрутов) предполагаются объеди-
ненными оператором OR.
as-out: to AS3 announce AS1 AS2
(описание сформированной маршрутной информации,
рассылаемой другим AS-партнерам). Формат описания:
to <aut-num> announce <выражение маршрутной политики>;
ключевые слова to {указатель адресата} и announce
{указатель списка доступных AS} могут и отсутствовать.)
<aut-num> относится к AS-соседям.
interas-in: from AS3 193.0.1.1/32 193.0.1.2/32 (pref= 5)
accept AS3
interas-in: from AS3 193.0.1.1/32 193.0.1.2/32 (pref=15)
accept AS4
interas-in: from AS3 193.0.1.5/32 193.0.1.6/32 (pref =10)
accept AS4
interas-in: описывает локальные предпочтения для соединений с
другими AS. Это описание имеет формат:
from <aut-num> <местный-п(1> <соседний-пс1> <предпочтение>
accept <выражение маршрутной политики> t
Сети передачи данных. Метод доступа
621
Ключевые слова from (от) и accept (воспринимает) могут отсут-
ствовать. <aut-num> — автономная система, описанная в as-in.
<местный-Н(1> — (идентификатор местного маршрутизатора) со-
держит IP-адрес пограничного маршрутизатора, политика которого
описывается. <соседний-п(1> содержит IP-адрес соседнего маршру-
тизатора, от которого воспринимается маршрутная информация, опи-
санная в <выражении маршрутной политики>. IP-адреса имеют
префиксный формат (описание префиксного формата см. выше в
конце раздела 4.4.8.5 [бесклассовая интердоменная маршрутиза-
ция — CIDR]).
Предпочтение описывается, как <pref-type> = <значение>; клю-
чевое слово <pref-type> должно обязательно присутствовать. В на-
стоящее время стандарт поддерживает только один вид <pref-type>
— «pref». <значение> может принимать один из следующих видов:
<стоимость> — положительное число, служащее выражением
относительной ценности исследуемых маршрутов. Чем меньше <сто-
имость> — тем предпочтительнее маршрут. <стоимость> имеет
смысл при сравнении атрибутов interas-in и совершенно не приме-
нима для сравнения с атрибутами as-in.
Любой маршрут, описанный в interas-in и неупомянутый в as-in,
предполагается отвергнутым. Система диагностики выдаст при этом
сигнал ошибки. Атрибуты interas-out сходны с interas-in, также как
as-out и as-in.
Если мы рассмотрим соответствующие атрибуты interas-out для
AS3, то увидим следующее:
aut-num: AS3
as-in: from AS2 10 accept AS1 A2
as-out: to AS2 announce AS3 AS4
interas-out: to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=5)
announce AS3
interas-out: to AS2 193:0.1.2/32 193.0.1.1/32 (metric-out=15)
announce AS4
interas-out: to AS2 193.0.1.6/32 193.0.1.5/32 (metric-out=10)
announce AS4
Оператор interas-out: имеет формат:
to aut-num> <местный-г1с1> <соседний-пс!> [<метрика>]
announce <выражение маршрутной политики>
622
Ключевые слова in и announce могут и отсутствовать. Осталь- |
ные фрагменты оператора идентичны описанным выше. |
<метрика> является необязательным параметром и описывает- I
ся как:
(<те1г1с4уре>=<величина>),
следует заметить, что в данном случае наличие скобок «()» и клю-
чевого слова <metric-type> (тип метрики) обязательно. В настоя-
щее время поддерживается только один тип метрики «metric-out».
Параметр <величина> может иметь следующий вид: f
<num-metric> — метрика для оценки выходных маршрутов, чем |
ниже ее значение, тем предпочтительнее маршрут. Именно эта оценка
маршрута передается соседним маршрутизаторам. IGP — этот тип ?
метрики указывает на то, что она отражает оценку внутренних мар-
шрутов AS. Следует избегать использования <num-metric> и IGP
для одних и тех же точек назначения.
Атрибут as-exclude отмечает список транзитных AS, маршруты <
через которые должны быть исключены из рассмотрения. Формат §
использования: х
exclude <aut-num> to <exclude-route-keyword>, ?
I
ключевые слова exclude и to не являются обязательными. <aut- 1
num> — описывает транзитные AS. В качестве <exclude-route- |
keyword> можно использовать одно из: <
<aut-num>, AS макро, ANY (любой) или community. -
Атрибут default указывает на маршрут по умолчанию. Формат |
атрибута: I
<aut-num> <relative cost> <default-expression>,
где <aut-num> указывает на AS-партнера, путь к которому и пред-
лагается в качестве маршрута по умолчанию. Атрибут <relative cost>
— положительное целое число, характеризующее уровень приорите-
та предлагаемого маршрута. AS-macro является удобным средством
группировать автономные системы. AS-макро могут использовать-
ся в <выражениях маршрутной политики> для атрибутов as-in и
as-out. В качестве примера можно привести:
aut-num: AS786
as-in: from AS1755 100 accept AS-EBONE AND NOT AS1104
as-out: to AS1755 announce AS786
Сети передачи данных. Метод доступа
623
Здесь присутствует as-macro с именем AS-EBONE, описание ко-
торого может выглядеть как:
as-macro: AS-EBONE (имя AS-макро)
descr: ASes routed by EBONE (AS, маршрутизируемые в EBONE)
as-list: AS2121 AS1104 AS2600 AS2122 (список AS) ,
as-list: AS1103 AS1755 AS2043
guardian: guardian@ebone.net (администратор EBONE)
В результате описание маршрутной политики будет выглядеть как:
aut-num: AS786
as-in: from AS1755 100 accept (AS2121 OR AS1104 OR
AS2600 OR AS2122
as-in: from AS1755 100 accept AS1103 OR AS1755 OR
AS2043)AND NOT AS1104
Community — это группа маршрутов, которые не могут быть пред-
ставлены одной AS или группой AS. Это может быть полезно при
описании доступа к супер-ЭВМ, это может быть группа маршрутов,
используемых для специальных целей, возможно объединение в груп-
пу для получения сетевой статистики. Такие группы не обмениваются
маршрутной информацией. Группа Community может использоваться
в качестве объекта маршрутной политики автономных систем. При-
мерами объектов типа community могут служить HEPNET (объедине-
ние сетей для физики высоких энергий), NSFNET (Национальная На-
учная сеть США), опорная московская оптоволоконная сеть.
Существует еще несколько атрибутов, которые помогают получить
вспомогательную информацию. В ближайшем будущем формирова-
ние конфигурационных файлов внутренних и внешних протоколов
маршрутизации будет осуществляться с помощью специального язы-
ка описания маршрутной политики RPSL (Routing Policy Specification
Language; RFC-2622).
4.4.9. Сервер имен (DNS)
Главной ЭВМ любой системы является та, на которой работаете
вы. Но помимо этой машины и маршрутизатора локальной сети не
последнюю роль играет сервер имен (DNS-система, STD0013, RFC-
2845, -2535, -2137, -2052, -2136, -1996, -1918, -1793, -1712-13, -1706,
-1664, -1611-12, -1536-37, -1401, -1383, -1183, -1101, -1034-35). Сервер
624
Гпава 4
имен это программа управления распределенной базой данных, в I
которой хранятся символьные имена сетей и ЭВМ вместе с их IP- f
адресами. Наиболее распространенным программным продуктом, !
решающим данную задачу является BIND (Berkrley Internet Name f
Domain). Иногда для этой цели выделяют специальную машину. 3
Задача DNS — преобразование символьного имени в IP-адрес и
наоборот в условиях, когда число узлов Internet растет экспоненци- \
ально, совсем не проста. Сама иерархическая система имен (DNS) |
настроена на упрощение решения этой проблемы. Схема взаимодей-
ствия программы пользователя с локальным и удаленными DNS- .
серверами показана ниже на рисунке 4.4.9.1.
Рис. 4.4.9.1. Структура взаимодействия с серверами имен
База имен является распределенной, так как нет такой ЭВМ, где
бы хранилась вся эта информация. Как уже отмечалось имя содер-}
жит несколько полей (длиной не более 63 символов), разделенных*
точками. Имя может содержать не более 255 октетов, включая байт ‘
длины. Анализ имени производится справа налево. Самая правая
секция имени характеризует страну (двухсимвольные национальные
коды смотри в приложении), или характер организации (образова- S
тельная, коммерческая, правительственная и т.д.).
Следующие 3-х символьные коды в конце Internet-адреса озна-|
чают функциональную принадлежность узла:
Секции .mil и .gov принадлежат исключительно американским |
сетям (хотя и многие другие трех-символьные секции адреса, на-|
пример .edu, чаще, но не всегда, принадлежат американским универ-|
ситетам и другим учебным организациям). Структура имен обыч-|
но отражает структуру организации, которой принадлежат сети илИ|
ЭВМ, но не архитектуру сети в этой организации. Так имя itep.ru —* j
это имя домена ITEPNET (Институт Теоретической и Эксперимей*|
Сети передачи данных. Метод доступа
625
Таблица 4.4.9.1. Стандартизованные суффиксы имен
Поле адреса Тип сети
.сом Коммерческая организация;
.GOV Государственное учреждение (США);
.ORG Бесприбыльная организация;
.EDU Учебное заведение;
.MIL Военное предприятие или организация (США);
.NET Большая сеть;
.INT Международная организация;
.ARPA Специальный домен, используемый для преобразования IP-адреса в имя
тальной физики, Москва), cl.itep.ru — имя mVAX-кластера в ИТЭФ,
vxitep.itep.ru — имя VAX-кластера, а suncom.itep.ru — имя одной
из ЭВМ в той же сети. По имени, как правило, нельзя определить
является ли оно именем сети, маршрутизатора или конкретной ЭВМ.
Для записи символьных имен используется исключительно латинс-
кий алфавит.
Маленький фрагмент интернетовской иерархии имен показан на
рис. 4.4.9.2. Число уровней реально больше, но обычно не превы-
шает 5.
.NS .VXITEP .ОАК
ns.itep.ru -----------------------vxitep.itep.ru
Рис. 4.4.9.2. Иерархия имен в Интернет-DNS
(I - домен первого уровня; II - второго уровня]
Каждому узлу (прямоугольнику на рисунке) соответствует имя,
которое может содержать до 63 символов. Только самый верхний,
корневой узел не имеет имени. При написании имени узла строчные
и прописные символы эквивалентны. Имя домена, завершающееся
626
Гпава 4
точкой называется абсолютным или полным именем домена (на-
пример, itep.ru.). В некоторых странах создана структура имен сходная
с com/edu/org. Так в Англии можно встретить адреса .ac.uk для
академических учреждений и .co.uk — для коммерческих. Если
имя домена не завершено символом точки, DNS может попытаться
его .дополнить, например имя ns может быть преобразовано в
ns.itep.ru. На приведенной схеме каждому объекту трех верхних
уровней соответствуют серверы имен, которые могут взаимодейство-
вать друг с другом при решении задачи преобразования имени в IP-
адрес. Можно было бы построить схему, при которой в любом сер-
вере имен имелись адреса серверов .COM, .EDU, .RU и т.д. и при
необходимости он мог бы послать туда запрос. Реальная схема сер-
веров не столь идеальна и стройна — существуют серверы nsf.gov,
oakland.edu и т.д., которые непосредственно связаны с базовым сер-
вером имен. Каждый сервер содержит лишь часть дерева имен. Эта
часть называется зоной ответственности сервера. DNS-сервер может
делегировать ответственность за часть зоны другим серверам, созда-
вая субзоны. Когда в зоне появляется новая ЭВМ или субдомен,
администратор зоны записывает ее имя и IP-адреса в базу данных
сервера. Администратор зоны определяет, какой из DNS-серверов
имен является для данной зоны первичным. Число вторичных сер-
веров не лимитировано. Первичный и вторичный серверы должны
быть независимыми и работать на разных ЭВМ, так чтобы отказ
одного из серверов не выводил из строя систему в целом. Отличие
первичного сервера имен от вторичного заключается в том, что пер-
вичный загружает информацию о зоне из файлов на диске, а вторич-
ный получает ее от первичного. Администратор вносит любые изме-
нения в соответствующие файлы первичного сервера, а вторичные
серверы получают эту информацию, периодически (раз в 3 часа) зап-
рашивая первичный сервер. Пересылка информации из первичного
во вторичные серверы имен называется зонным обменом. Как будет
вести себя сервер, если он не имеет запрашиваемой информации? Он
должен взаимодействовать с корневыми серверами. Таких серверов
насчитывается около десяти и их IP-адреса должны содержаться в
конфигурационных файлах.
Список корневых серверов вы можете получить с помощью ано-
нимного FTP по адресам: nic.ddn.mil или ftp.rs.internic.net . Кор-
невые серверы хранят информацию об именах и адресах всех серве-
ров доменов второго уровня. Существует два вида запросов: рекур-
сивные и итеративные. Первый вид предполагает получение
клиентом IP-адреса, а второй — адреса сервера, который может со-
общить адрес. Первый вид медленнее, но дает сразу IP-адрес, второй
Сети передачи данных. Метод доступа
627
эффективнее — в вашем сервере копится информация об адресах
серверов имен. Одним из способов повышения эффективности транс-
ляции имен в адреса является кэширование, то есть хранение в
оперативной памяти имен-адресов, которые использовались после-
днее время особенно часто. Рассмотрение процесса обмена между
ЭВМ-клиентом и сервером имен может прояснить работу системы в
целом. Прежде чем использовать протоколы UDP или TCP при-
кладная программа должна узнать IP-адрес объекта, куда она хочет
послать дейтограмму. Для решения этой проблемы программа по-
сылает запрос в локальный сервер имен. В UNIX-системах имеются
специальные библиотечные процедуры gethostbyname и gethostbyaddr,
которые позволяют определить IP-адрес по имени ЭВМ и наоборот.
В одном запросе может содержаться несколько вопросов. Если сер-
вер не сможет ответить на вопросы, он пришлет отклик, где содер-
жатся адреса других серверов, способных решить эту задачу. Ниже
на рисунке 4.4.9.3 представлен формат таких сообщений (в каче-
стве транспорта используется UDP или TCP, порт 53).
О 16 31
Идентификация Флаги
Число вопросов Число ответов
Число узловых серверов имен Число записей в секции дополнительной информации
Секция вопросов
Секция ответов
Секция серверов имен
Секция дополнительной информации
Рис. 4.4.9.3. Формат DNS-сообщений
Каждое сообщение начинается с заголовка, который содержит
поле идентификация, позволяющее связать в пару запрос и отклик.
Поле флаги определяет характер запрашиваемой процедуры, а так-
Же кодировку отклика. Поля число... определяют число записей
соответствующего типа, содержащихся в сообщении. Так число воп-
росов задает число записей в секции вопросов, где записаны запросы,
требующие ответов. Каждый вопрос состоит из символьного имени
Домена, за которым следует тип запроса и класс запроса. Значения
628
Гпава 4
0 1 5 6 7 8 9 12 15
QR Тип запроса АА ТС RD RA Нули Тип отклика
Рис. 4.4.9.4. Назначение битов поля флаги.
Таблица 4.4.9.2. Коды поля флаги
Код поля флаги Описание
0(QR) Операция: 0 Запрос 1 Отклик
1...4 Тип запроса (opcode): 0 стандартный 1 инверсный 2 запрос состояния сервера
5 (АА) Равен 1 при ответе от сервера, в ведении которого находится домен, упомянутый в запросе.
6 (ТС) Равен 1 при укорочении сообщения. Для UDP это означает, что ответ содержал более 512 октетов, но прислано только первые 512.
7 (RD) Равен 1, если для получения ответа желательна рекурсия.
8 (RA) Равен 1, если рекурсия для запрашиваемого сервера доступна.
9...11 Зарезервировано на будущее. Должны равняться нулю.
12...15 Тип отклика (rcode): 0 нет ошибки 1 ошибка в формате запроса 2 сбой в сервере 3 имени не существует
битов поля флаги в сообщении сервера имен отображены в таблице
4.4.9.2. Разряды пронумерованы слева направо, начиная с нуля
рис. 4.4.9.4;
Ниже описан формат секции вопросов в DNS-сообщении.
Поле символьное имя домена имеет переменную длину, содержит
одно или более субполей, начинающихся с байта длины (0-63). Поле
Символьное имя домена
Тип запроса Класс запроса
Рис. 4.4.9.5. Формат секции вопросов DNS-запроса.
Сети передачи данных. Метод доступа
629
завершается 0. Например, для ns.itep.ru (цифры представляют со-
бой октеты длины):
2 п S 4 i t е Р 2 г и ~ 0
В реальной нотации байты длины субполя могут иметь два стар-
ших бита равные 1, что преобразует интервал значений из 0-63 в
192-255. Такой байт в поле означает, что это не мера длины секции,
а 16-битный указатель, 14 бит которого являются смещением от
начала DNS-сообщения, указывающим на место продолжения сек-
ции. Смещение для первого байта поля идентификации равно нулю.
Эти ухищрения придуманы для сокращения длины сообщений, так
как одно и то же имя домена в отклике может повторяться много
раз. Поле тип запроса характеризует разновидность запроса:
Таблица 4.4.9.3.. Разновидности полей тип запроса и их коды
Тип запроса Код запроса Описание
А 1 IP-адрес
NS 2 Сервер имен.
CNAME 5 Каноническое-имя.
SOA 6 Начало списка серверов. Большое число полей, определяющих часть иерархии имен, которую использует сервер.
МВ 7 Имя домена почтового ящика.
WKS 11 Well-known service - стандартная услуга.
PTR 12 ' Запись указателя.
HINFO 13 Информация об ЭВМ.
MINFO 14 Информация о почтовом ящике или списке почтовых адресов.
мх 15 Запись о почтовом сервере.
TXT 16 Не интерпретируемая строка ASCII символов.
AXFR 252 Запрос зонного обмена
* или ANY 255 Запрос всех записей.
(Пропущенные коды являются устаревшими или экспериментальными).
Последние две строки в таблице 4.4.9.3 относятся только к
вопросам. Поле класс запроса позволяет использовать имена доме-
нов для произвольных объектов (все официальные имена Интернет
относятся к одному классу [IN] — 1). В сообщении DNS-сервера
каждая из секций (дополнительной информации, ответов или уз-
ловых серверов имен) состоит из набора ресурсных записей, которые
630 Гпава 4,
описывают имена доменов и некоторую другую информацию (на-
пример, их адреса). Появление ресурсных полей в DNS базе данных
придают ей новые качества. Каждая запись описывает только одно
имя, формат этих записей отображен на рис. 4.4.9.6.
О 16 31
Имя домена, ресурсы которого описаны в этой записи
Тип Класс
Время жизни (TTL)
Длина записи о ресурсах Информация о
ресурсах
Рис. 4.4.9.6. Формат ресурсных записей в DNS |
Имя домена в этой записи может иметь произвольную длину. |
Поля шип и класс характеризуют тип и класс данных, включенных
в запись (аналогичны используемым в запросах). Поле время жиз- |
ни (TTL) содержит время (в секундах), в течение которого запись о J
ресурсах может храниться в буферной памяти (в кэше). Обычно это J
время соответствует двум дням. Формат информации о ресурсах
зависит от кода в поле тип, так для тип=1 — это 4 байта IP- ?
адреса. Сервер имей может обслуживать и другие запросы, например, •
по IP-адресу определять символьное имя домена или преобразовать
имя домена в адрес почтового сервера. Когда организация присоеди-
няется к Интернет, она прлучает в свое распоряжение не только
определенную DNS-область, но и часть пространства в in-addr.arpa,
соответствующую ее IP-адресам. Домен in-addr.arpa предназначен
для определения имен по их IP-адресам. Такая схема исключает
процесс перебора серверов при подобном преобразовании.
Имена в домене IN-ADDR.ARPA могут иметь до четырех субпо-
лей помимо суффикса IN-ADDR.ARPA. Каждое субполе представ-
ляет собой октет IP-адреса, и содержит последовательность симво-
лов, отображающую коды в диапазоне 0-255. Так имя для IP-адреса
192.148.166.137 (если оно существует) содержится в домене с име-
нем 137.166.148.192.IN-ADDR.ARPA. Запись адреса задом напе-
ред диктуется общими принципами записи имен доменов (корневая
часть имени находится справа). Направив несколько запросов в
домен IN-ADDR.ARPA относительно имен объектов с интересую-
щими вас IP-адресами, можно получить следующий результат:
Сети передачи данных. Метод доступа
631
IP_address Hard-addr
l28.l4l.202.l0l 00.00.0c.02.69.7d
192.148.166.102 00.00.а7.14.41 .с2
192.148.166.237 00.00.0c.02.69.7d
Delay Date Host_name
440 10/10/95 na48-l.cern.ch
5 10/10/95
5 10/10/95 ITEP-
M9.Relcom. ITEP.RU
где в левой колонке записаны IP-адреса, имена которых ищутся, во
второй — записаны аппаратные адреса интерфейсов, через которые
доступны искомые объекты. Поскольку первая и третья строки от-
носятся к внешним по отношению к узлу ITEP объектам, здесь за-
писан адрес интерфейса пограничного маршрутизатора. В третьей ко-
лонке содержится значение RTT в мсек, а в последней — имена объек-
тов. IP-адресу 192.148.166.102 не соответствует никакого имени.
Задержка при выполнении команды telnet между выдачей ко-
манды и появлением на экране IP-адреса связана с доступом и
работой DNS-сервера. Пауза между появлением надписи Trying и
Connected to определяется временем установления TCP-связи меж-
ду клиентом и сервером. База данных имен может содержать и
другую информацию. Типы такой информации представлены в таб-
лице 4.4.9.3. Для извлечения информации из этой распределенной
базы данных можно воспользоваться программой host (SUN или
другая ЭВМ, работающая под UNIX). Рассмотрим несколько приме-
ров (курсивом выделены команды, выданные с терминала).
host -t cname cernvm.cern.ch
cernvm.cern.ch is a nickname for crnvma.cern.ch
Напомним, что CNAME — каноническое имя узла или ЭВМ, иногда
называемое также псевдонимом (alias).
host -t hinfo ns.itep.ru
ns.itep.ru HINFO SparcStation-1 SunOS-4.1.3
HINFO — информация об ЭВМ. Это обычно две последователь-
ности символов, которые характеризуют ЭВМ и ее операционную
систему. Много полезной информации можно узнать о почтовом
сервере узла посредством команды:
host -t mx cl.itep.ru
cl.itep.ru is a nickname for r02vax.itep.ru
r02vax.itep.ru mail is handled by relayl.kiae.su
r02vax.itep.ru mail is handled by relay2.kiae.su
632
Глава 4
rO2vax.itep.ru mail is handled by mx.itep.ru
r02vax.itep.ru mail is handled by x4u2.desy.de
host -v info.cern.ch
Trying domain «itep.ru»
rcode = 3 (Non-existent domain), ancount=0
Trying null domain •
rcode = 0 (Success), ancount=2
info.cern.ch 86400 IN CNAME www6.cern.ch
www6.cern.ch 86400 IN A 128.141.202.119
Trying domain «itep.ru»
rcode = 3 (Non-existent domain), ancount=0
Trying null domain
rcode = 0 (Success), ancount=l
The following answer is not authoritative:
www6.cern.ch 86400 IN A 128.141.202.119
For authoritative answers, see:
CERN. CH 52256 IN NS dxmon.cern.ch
CERN. CH 52256 IN NS ns.eu.net
CERN. CH 52256 IN NS sunic.sunet.se
CERN.CH 52256 IN NS scsnms.switch.ch
Additional information: '
dxmon.cern.ch 79157 IN A 192.65.185.10 i
ns.eu.net 56281 IN A 192.16.202.11 -
sunic.sunet.se 85087 IN A 192.36.125.2
sunic.sunet.se 85087 IN A 192.36.148.18
scsnms.switch.ch 72545 IN A 130.59.1.30
scsnms.switch.ch 72545 IN A 130.59.10.30
Опция -v, используемая совместно с командой host позволяет
получить более полную информацию об узле. Во второй колонке
данной выдачи указано время жизни (TTL) в секундах. Значение
TTL в первых строках соответствует суткам (24x60x60=86400). IN^
в следующей колонке указывает на принадлежность к классу Ин-
тернет. В четвертой колонке проставлены указатели типов запроса
(см. табл. 4.4.9.3). В пятой колонке идут названия серверов имея
и IP-адреса ЭВМ. Далее следуют коды предпочтения. МХ-записЦ
активно используются почтовыми серверами. Обмен МХ-записямИ
производится в следующих случаях:
• Локальная сеть или ЭВМ не имеет непосредственной связи Q
Интернет, но желает участвовать в почтовом обмене (например,
рез UUCP-протокол).
Сети передачи данных. Метод доступа 633
. Адресат не доступен и предпринимается попытка доставить
почтовое сообщение альтернативной ЭВМ.
. Создание виртуальных ЭВМ, куда можно пересылать почту.
MX-записи снабжены 16-битными кодами предпочтения. Если
для адреса имеется несколько MX-записей, они используются в по-
рядке нарастания этого кода. Если вы хотите узнать список дос-
тупных услуг на той или иной ЭВМ, вы можете напечатать команду
(WKS — Well Known Services, сюда не входят услуги прикладного
уровня, например, услуги NEWS-сервера и пр.):
host -tv wks ns.itep.ru
ns.itep.ru WKS 193.124.224.35 udp domain tftp
ns.itep.ru WKS 193.124.224.35 tcp echo ftp telnet smtp time finger
Если вам нужно узнать IP-адреса того или иного узла можно
также воспользоваться командой host:
host vxdesy.desy.de
vxdesy.desy.de has address 131.169.35.78
vxdesy.desy.de has address 131.169.35.79
vxdesy.desy.de has address 131.169.35.76
vxdesy.desy.de has address 131.169.35.77
Большая часть данных относится к типу «А».
Выше уже говорилось, что для транспортировки DNS-запросов
применяются протоколы UDP и TCP. Когда же следует использо-
вать эти протоколы? Обычно используется UDP. Когда в ответ на
запрос программа получает отклик с битом флагов ТС=1 (сообще-
ние укорочено), программа повторяет запрос, но уже с использовани-
ем протокола TCP. Этот протокол применяется также для зонных
обменов между первичным и вторичным DNS-серверами.
Обычно реализация сервера имен (версия BIND - Berkeley Internet
Name Domain) предполагает наличие трех конфигурационных файлов:
named.boot — файл начальной загрузки сервера имен;
named.Iocal — стартовый файл клиента DNS;
named.ca — исходный буфер имен и адресов.
Это текстовые файлы, строки и фрагменты, начинающиеся с точ-
ки с запятой, представляют собой комментарии. В первом из пере-
численных файлов строка, начинающаяся со слова sortlist, указыва-
ет на порядок присылки адресов при условии, что отклик на запрос
^Держит несколько адресов. Строка, начинающаяся со слова
directory, содержит название каталога, где хранятся конфигураци-
°нные файлы (по умолчанию /etc). Строка cache сообщает имя фай-
ла-буфера имен и адресов (по умолчанию named.ca). Далее обычно
следует несколько строк, начинающихся со слова primary. Эти строки
Указывают имена файлов (например, named.hosts или named.Iocal),
634
Гпава 4
где содержится информация о соответствии имен и адресов для оц.
ределенных субдоменов. Вместо имени файла может быть указан
IP-адрес. Укладка данных в файле соответствует требованиям до-
кумента RFC-1033. Для вторичного (secondary) DNS файл
named.boot имеет схожую структуру. Вместо строк со словом primary
в этом файле присутствуют строки secondary. Эти строки содержат
помимо имен субдоменов и файлов IP-адрес первичного DNS. Пос-
ледний выполняет и функцию переадресации запросов вышестоя-
щим серверам. Вторичный DNS-сервер при невозможности выпол-
нить запрос переадресует его первичному серверу, а не вышестояще-
му. Первичный сервер может создавать большой кэш-буфер для
локального обслуживания часто поступающих запросов.
Файл named.local служит для спецификации интерфейса сервера
имен и содержит в себе запись SOA (Start of Authority) и две ресур- j
сных записи. Запись SOA определяет начало зоны. Символ @ в
начале первой строки файла определяет имя зоны. Здесь же указы-
ваются опционные параметры:
• номер версии файла (увеличивается каждый раз при внесеЛ
нии любых изменений, этот параметр отслеживается вторичным
сервером);
• время обновления данных (период запросов, посылаемых вто-;
ричным сервером первичному) в секундах; |
• длительность периода повторных попыток (retry) вторич-
ного сервера в случае неудачи;
• продолжительность пригодности данных (expiration time)
в секундах, по истечении этого времени вторичный сервер считаем
всю базу данных устаревшей.
• значение TTL по умолчанию.
Запись может выглядеть как (RFC-1033):
@ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
45 ;serial
3600 ;refresh
600 ; retry
3600000 ;expire
86400 ) ;minimum
В файле приводится имя первичного сервера имен для данного
субдомена (флаг NS) и имя администратора с указанием адреса его
электронной почты. Последняя Запись в файле содержит указатель
на местную ЭВМ. Первая цифра в строке этой записи содержи^
суффикс IP-адреса этой машины.
Сети передачи данных. Метод доступа
635
файл named.са используется для заполнения кэша при первич-
ной загрузке DNS. Примером, иллюстрирующим возможное содер-
жимое файла можно считать следующее (взято из RFC-1033):
•list of possible root servers
’ 1 IN NS SRI-NIC.ARPA.
NS C.ISI.EDU.
NS BRL-AOS.ARPA.
NS C.ISI.EDU.
;and their addresses
SRI-NIC.ARPA. A 10.0.0.51
A 26.0.0.73
C.ISI.EDU. A 10.0.0.52
BRL-AOS.ARPA. A 192.5.25.82
A 192.5.22.82
A 128.20.1.2
A. ISI.EDU. A 26.3.0.103
Первое поле представляет собой имя домена или субдомена, вто-
рое поле - значение TTL, третье — поле класс (Internet), четвертое ~
тип записи (NS для сервера имен или А для адреса), и последнее
поле характеризует имя ЭВМ или IP-адрес. Если какие-то поля
пусты, это означает, что они тождественны приведенным выше. Точка
в начале первой строки указывает на корневой домен.
Для администраторов, обслуживающих DNS, весьма полезно оз-
накомиться с документом RFC-1536 («Common DNS Implementation
Errors and Suggested Fixes»). Ошибки при конфигурации DNS-серве-
pa могут привести к досадным ошибкам и отказам системы. Обыч-
но, при получении запроса DNS сначала определяется его зона и
просматривается кэш. Если запрос не может быть выполнен, про-
сматривается список вышестоящих DNS-серверов, которые могут со-
держать необходимую информацию, и запрос пересылается одному из
них. Если клиент прислал рекурсивный запрос и сервер поддержива-
ет рекурсию, запрос пересылается соответствующим серверам. Если
Рекурсия не поддерживается, сервер возвращает клиенту список DNS-
еерверов, предоставляя ему решать свои проблемы самостоятельно.
Однако в некоторых случаях DNS-сервер по ошибке может включить
себя в такой список серверов. Если программное обеспечение клиен-
та не проверяет список, запрос может быть послан этому серверу
повторно, что вызовет бесконечный цикл запросов.
Возможна и другая схема возникновения циклов запросов. Пред-
положим, что сервер <1> содержит в своем списке внешних DNS
СеРвер <2>, а последний в свою очередь содержит в своем списке
СеРвер <1>. Такого рода перекрестные ссылки трудно обнаружить
636
Гпава 4
особенно, если в перечне фигурирует большое число серверов. Иног-
да возникает ситуация, когда клиент, получив список DNS-серверов,
не знает, что с ним делать и посылает запрос повторно тому же
серверу. Идентифицировать такого рода ошибки весьма трудно, осо-
бенно когда в это вовлечены внешние серверы, содержимое конфигу-
рационных файлов которых недоступно.
Иногда DNS-сервер в ответ на запрос не присылает сообщений
об ошибке и никаких-либо данных клиенту. Это случается когда
запрашиваемое имя вполне корректно, но записей нужного типа не
найдено. Например, запрошен адрес почтового сервера домена xxx.com.
Домен этот существует, но рекорда типа MX не обнаружено. Даль-
нейшие события зависят от характера программного обеспечения
клиента. Если клиент считает такого рода «отклик» некорректным,
он может послать запрос повторно и т.д. и т.д. По этой причине в
случае, если программное обеспечение это позволяет, рекомендуется
ограничить число повторных запросов клиента. Приведенные при-
меры показывают, насколько актуальна корректная конфигурация
DNS клиента и сервера.
В системах Windows часто используется своя служба имен WINS
(Windows Internet Naming Service). Эта служба совместима с систе-
мой динамического конфигурирования сети DHCP (Dynamic Host
Configuration Protocol, использует динамическое распределение IP-
адресов). В WINS, также как и в DHCP, имеются части, работающие
у клиента и на сервере. WINS автоматически устанавливается и
конфигурируется при установке системы DHCP. Эта система имеет
удобную встроенную диагностику, позволяющую контролировать
процесс обработки запросов к службе имен.
В последнее время развивается технология DDNS динамическо-
го обновления ресурсных записей зоны DNS внешними ЭВМ или
процессами (Dynamic DNS; RFC-2136). Клиенты с возможностями
DDNS могут сами обновлять записи локальных серверов имен. Еще
более интересное решение базируется на интеграции служб DHCP и
DNS. В этом варианте серверы DHCP, поддерживающие DDNS, по-
сылают соответствующему серверу DNS данные для обновления
записей, включая имена NetBIOS клиентов DHCP. Запись обновля-
ется после выделения IP-адреса. При реализации DDNS возникают
проблемы безопасности. Часть этих проблем может быть решено
путем использования цифровых подписей (RFC-2137).
Еще одной проблемой, связанной со службой имен, являются
атаки, которые сопряжены с.имитацией DNS. Для преодоления та-
ких атак разработан метод транзакционных подписей TSIG
(Transaction SIGnarure).
Сети передачи данных. Метод доступа
637
4.4.10. Управляющий протокол SNMP
Интернет — гигантская сеть. Напрашивается вопрос, как она
сохраняет свою целостность и функциональность без единого уп-
равления? Если же учесть разнородность ЭВМ, маршрутизаторов и
программного обеспечения, используемых в сети, само существова-
ние Интернет представится просто чудом. Так как же решаются
проблемы управления в Интернет? Отчасти на этот вопрос уже дан
ответ - сеть сохраняет работоспособность за счет жесткой прото-
кольной регламентации. «Запас прочности» заложен в самих про-
токолах. Функции диагностики возложены, как было сказано выше,
на протокол ICMP. Учитывая важность функции управления, для
этих целей создано два протокола SNMP (Simple Network Management
Protocol, RFC-1157, -1215, -1187, -1905-7 разработан в 1988 году) и
СМОТ (Common Management Information Services and Protocol over
TCP/IP, RFC-1095, в последнее время применение этого протокола
ограничено). Обычно управляющая прикладная программа воздей-
ствует на сеть по цепочке SNMP-UDP-IP-Ethernet. Наиболее важ-
ным объектом управления обычно является внешний порт сети
(Gateway) или маршрутизатор сети. Каждому управляемому объек-
ту присваивается уникальный идентификатор.
Протокол SNMP работает на базе транспортных возможностей
UDP и предназначен для использования сетевыми управляющими
станциями. Он позволяет управляющим станциям собирать ин-
формацию о положении в сети Интернет. Протокол определяет фор-
мат данных, а их обработка и интерпретация остаются на усмотре-
НИе управляющих станций или менеджера сети. SNMP-сообщения
Не имеют фиксированного формата и фиксированных полей. При
своей работе SNMP использует управляющую базу данных (MIB —
Management Information Base, RFC-1213, -1212).
638
Гпава 4
Алгоритмы управления в Интернет обычно описывают в нота-
ции ASN.l (Abstract Syntax Notation). Все объекты в Интернет .
разделены на 10 групп и описаны в MIB: система, интерфейсы, обме-
ны, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу
«система» входит название и версия оборудования, операционной
системы, сетевого программного обеспечения и пр.. В группу «ин-
терфейсы» входит число поддерживаемых интерфейсов, тип интер-
фейса, работающего под IP (Ethernet, LAPB etc.), размер дейтограмм,
скорость обмена, адрес интерфейса. IP-группа включает в себя время <
жизни дейтограмм, информация о фрагментации, маски субсетей и ±
т.д. В TCP-группу входит алгоритм повторной пересылки, макси- ;
Таблица 4.4.10,1 Команды SNMP
Команда SNMP Тип PDU Назначение
get-request 0 Получить значение указанной переменной или информацию о состоянии сетевого элемента;
get_next_reques t I Получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB);
set-request 2 Присвоить переменной соответствующее значение. Используется для описания действия, которое должно быть выполнено;
get response 3 Отклик на get-request, get_next_request и set- request. Содержит также информацию о состоянии (коды ошибок и другие данные);
trap 4 Отклик сетевого объекта на событие или на изменение состояния.
SNMP менеджер Запрос get (протокол UDP)
. . .. V . ф Отклик get Порт 161
| Порт 162 Запрос get-next - •- - - . ь Отклик get Запрос set Отклик get . — .. Trap # --- • — — - — Объект управления Порт 161 Порт 161
Рис. 4.4.10.1 Схема запросов/откликов SNMP
Сети передачи данных. Метод доступа
639
Таблица 4.4.10.2. Коды ошибок
"Статус ошибки Имя ошибки Описание
0 noError Все в порядке;
г tooBig Объект не может уложить отклик в одно сообщение;
2 noSuchName В операции указана неизвестная переменная;
г- bad Value В команде set использована недопустимая величина или неправильный синтаксис;
4 readonly Менеджер попытался изменить константу;
5 genErr Прочие ошибки.
мальное число повторных пересылок и пр.. Ниже приведена табли-
ца (4.4.10.1) команд (PDU — Protocol Data Unit) SNMP:
Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы,
имеет вид (рис. 4.4.10.2):
Поле версия содержит значение, равное номеру версии SNMP
минус один. Поле пароль (community - определяет группу доступа)
содержит последовательность символов, которая является пропус-
ком при взаимодействии менеджера и объекта управления. Обычно
это поле содержит 6-байтовую строку public, что означает общедос-
тупность. Для запросов get, get-next и set значение идентификато-
ра запроса устанавливается менеджером и возвращается объектом
управления в отклике get, что позволяет связывать в пары запросы
и отклики. Поле фирма (enterprise) = sysObjectID объекта. Поле
статус ошибки характеризуется целым числом, присланным объек-
том управления:
Если произошла ошибка, поле индекс ошибки (error index) ха-
рактеризует, к какой из переменных это относится, error index яв-
SNMP-заголовок ----
<4-----Get/set-заголовок------>-
Переменные для get/set
Значе-
ние
Версия
0
Пароль
Community
Тип
PDU
0...3
Иденти-
фикатор
запроса
Статус
ошибки
(0...5)
Индекс
ошибки
Имя
Тип PDU 4 Фирма Адрес объекта Тип Trap 0...7 Спец, код Метка времени Имя Значение
Trap-заголовок
◄—Нужные переменные
Рис. 4.4.10.2 Формат SNMP-сообщений,
вкладываемых в UDP-дейтограммы
640
Гпава 4
ляется указателем переменной и устанавливается объектом управ-
ления не равным нулю для ошибок badValue, readonly и noSuchName.
Для оператора trap (тип PDU=4) формат сообщения меняется. Таб-
лица типов trap представлена ниже (4.4.10.3):
Таблица 4.4.10.3. Коды trap
Тип trap Имя trap Описание
0 coldStart Установка начального состояния объекта.
1 warmStart Восстановление начального состояния объекта.
2 linkDown Интерфейс выключился. Первая переменная в сообщении идентифицирует интерфейс.
3 linkUp Интерфейс включился. Первая переменная в сообщении идентифицирует интерфейс.
4 authenticationFailure От менеджера получено SNMP-сообщение с неверным паролем (community).
5 egpNeighborLoss EGP-партнер отключился. Первая переменная в сообщении определяет IP- адрес партнера.
6 entrpriseSpecific Информация о trap содержится в поле специальный код.
Для значений тип trap 0-4 поле специальный код должно быть
равно нулю. Поле временная метка содержит число сотых долей
секунды (число тиков) с момента инициализации объекта управле-
ния. Так прерывание coldStart выдается объектом через 200 мс
после инициализации.
В последнее время широкое распространение получила идеоло-
гия распределенного протокольного интерфейса DPI (Distributed
Protocol Interface). Для транспортировки SNMP-запросов может
использоваться не только UDP-, но и TCP-протокол. Это дает воз-
можность применять SNMP-протокол не только в локальных се-
тях. Форматы SNMP-DPI-запросов (версия 2.0) описаны в доку-
менте RFC-1592. Пример заголовка SNMP-запроса (изображенные
поля образуют единый массив; см. рис. 4.4.10.3):
Поле Флаг=0х30 является признаком ASN.1-заголовка. Коды
Ln — представляют собой длины полей, начинающиеся с байта, кото-
рый следует за кодом длины, вплоть до конца сообщения-запроса (п
— номер поля длины), если не оговорено другое. Так L1 - длина
пакета-запроса, начиная с Т1 и до конца пакета, a L3 - длина поля
пароля. Субполя Тп — поля типа следующего за ними субполя зап-
Сети передачи данных. Метод доступа
641
Рис. 4.4.10.3. Формат заголовка SNMP-запроса
роса. Так Т1=2 означает, что поле характеризуется целым числом, а
Т2=4 указывает на то, что далее следует пароль (поле community, в
приведенном примере = public). Цифры под рисунками означают ти-
повые значения субполей. Код ОхА — является признаком GET-
запроса, за ним следует поле кода PDU (=0-4, см. табл. 4.4.10.1)
Блок субполей идентификатора запроса служит для тех же целей,
что и другие идентификаторы — для определения пары запрос-от-
клик. Собственно идентификатор запроса может занимать один или
два байта, что определяется значением Ьиз. СО - статус ошибки (СО=0
— ошибки нет); ТМ — тип MIB-переменной (в приведенном примере
= 0x2В); ИО — индекс ошибки. Цифровой код MIB-переменной ото-
бражается последовательностью цифровых субполей, характеризую-
щих переменную, например: переменная 1.3.6.1.2.1.5 (в символь-
ном выражении iso.org.dod.internet.mgmt.mib.icmp) характеризует-
ся последовательностью кодов 0x2В 0x06 0x01 0x02 0x01 0x05
0x00.
SNMP-протокол служит примером системы управления, где для
достижения нужного результата выдается не команда, а осуществ-
ляется обмен информацией, решение же принимается «на месте» в
соответствии с полученными данными.
21 Зак. № 3430 Семенов
642
Гпава 4
4.4.10.1. Управляющая база данных (MIBJ
Вся управляющая информация для контроля ЭВМ и маршрути-
заторами Интернет концентрируется в базе данных MIB (Management
Information Base, RFC-1213 или STD0017). Именно эти данные ис-
пользуются протоколом SNMP. Система SNMP состоит из трех
частей: менеджера SNMP, агента SNMP и базы данных MIB. Агент
SNMP должен находиться резидентно в памяти объекта управле-
ния. SNMP-менеджер может быть частью системы управления се-
тью NMS (Network Management System), что реализуется, например,
в маршрутизаторах компании CISCO (CiscoWorks). '
MIB определяет, например, что IP программное обеспечение дол-
жно хранить число всех октетов, которые приняты любым из сете- J
вых интерфейсов, управляющие программы могут только читать эту
информацию.
Согласно нормативам MIB управляющая информация делится
на восемь категорий (см. также рис. 4.4.10.1.1):
MIB-категория включает в себя информацию о
М1В-категория Описание
system interfaces addr. trans ip icmp tcp udp egp Операционная система ЭВМ или маршрутизатора. Сетевой интерфейс. Преобразование адреса (напр., с помощью ARP). Программная поддержка протоколов Интернет. Программное обеспечение ICMP-протокола. Программное обеспечение ТСР-протокола. Программное обеспечение UDP-протокола. Программное обеспечение EGP-протокола.
Таблица 4.4.10.1.1. Системные переменные MIB
Системная переменная Описание
sysDescr Текстовое описание объекта;
sysObjectID Идентификатор производителя в рамках дерева 1.3.6.1.4.1
sysUpTime Время с момента последней загрузки системы (TimeTicks);
sysContact Имя системного менеджера и способы связи с ним;
sysName Полное имя домена;
sysLocation Физическое местоположение системы;
sysService Величина, которая характеризует услуги, предоставляемые узлом (сумма номеров уровней модели OSI);
Сети передачи данных. Метод доступа
643
Таблица 4.4.10,1.2. Переменные ifTable (интерфейсы)
Переменная описания интерфейсов (ifTable) Тип данных Описание
jfindex • INTEGER Список интерфейсов от 1 до ifNumber.
'ifDescr Displays tring Текстовое описание интерфейса.
Iffy?6 INTEGER Тип интерфейса, например, 6 - Ethernet; 9 - 802.5 маркерное кольцо; 23 - РРР; 28 - SLIP.
ifNumber INTEGER Число сетевых интерфейсов.
ifMtu INTEGER MTU для конкретного интерфейса;
itS peed Gauge Скорость в бит/с.
ifPhysAddress PhysAddress Физический адрес или строка нулевой длины для интерфейсов без физического адреса (напр. последовательный).
ifAdminStatus [1-3] Требуемое состояние интерфейса: 1 - включен; 2 - выключен; 3 - тестируется.
ifOperStatus [1-.3] Текущее состояние интерфейса: 1 - включен; 2 - выключен; 3 - тестируется.
ifLastChange TimeTicks sysUpTime, когда интерфейс оказался в данном состоянии.
iflnOctets Counter Полное число полученных байтов.
iflnUcastPkts Counter Число пакетов, доставленных на верхний системный уровень (unicast).
iflnDiscads Counter Число полученных но отвергнутых пакетов.
iflnErrors Counter Число пакетов, полученных с ошибкой;
ifOutOctets Counter Число отправленных байтов;
ifOutUcastPkts Counter Число unicast- пакетов, полученных с верхнего системного уровня;
ifOutNUcastPkts Counter Число мультикастинг- и широковещательных пакетов, полученных с верхнего системного уровня;
ifOutDiscads Counter Количество отвергнутых пакетов из числа отправленных;
IfOutErrors Counter Число отправленных пакетов, содержащих ошибки;
QjOutQLen Gauge Число пакетов в очереди на отправку;
21»
644
Гпава 4
Таблица 4.4.10.1.3. Переменные ip-группы
Переменная ip-группы Тип данных Описание
ipDefaultTTL INTEGER Значение, которое использует IP в поле TTL.
ipForwarding [1...2] I означает, что система переадресует дейтограммы (2 -нет).
ipInReceives Counter Число полученных дейтограмм.
ipForwDatagrams Counter Число переадресованных дейтограмм.
ipOutNoRoutes Counter Число неудач при маршрутизации.
ipFragOKs Counter Число фрагментированных IP- дейтограмм.
ipRoutingTable Таблица IP маршрутов.
ipInHdrErrors Counter Число IP-дейтограмм, отвергнутых по причине ошибки в заголовке.
ipInAddrErrors Counter Число дейтограмм, отвергнутых из-за неверного адреса места назначения.
ipInUnknownProto s Counter Число локально адресованных дейтограмм с неверным кодом протокола.
ipInDiscards Counter Число дейтограмм, отвергнутых из-за нехватки места в буфере.
ipInDelivers Counter Число доставленных IP- дейтограмм.
ipOutRequests Counter Полное число IP-дейтограмм, поступивших для пересылки без учета переадресованных.
ipOutDiscards Counter Число отправляемых дейтограмм, потерянных из-за нехватки места в буфере.
ipOutNoRoutes Counter Число потерянных IP-дейтограмм из-за отсутствия маршрута их доставки.
ipReasmTimeout Counter Максимальное время в сек., которое IP- фрагмент может ждать сборки.
ipReasmOKs Counter Число IP-дейтограмм, успешно прошедших сборку.
IpReasmFails Counter Число случаев, когда алгоритм сборки не сработал.
IpFragOKs Counter Число дейтограмм, успешно фрагментированных.
IpFragFails Counter Число дейтограмм, которые нуждались в фрагментации, но не могли быть фрагментированы из-за того, что don’t fragment флаг= I. _
IpFragCreates Counter Число фрагментов, созданных в процессе фрагментации. _
IpRoutingDiscards Counter Число маршрутных записей, помеченных для ликвидации, хотя они и корректны.
Сети передачи данных. Метод доступа
645
Таблица 4.4.10.1.3. Переменные ip-группы (Окончание]
Переменная in-ГРУППЫ Тип данных Описание
' Таблица IP-адресов (ipAddrTable), индекс =<ipAdEntAddr>
jgAdEntAddr IpAddress IP-адрес для данного ряда
jjAdEptlflndex INTEGER Число интерфейсов.
JpAdEntNetMask IpAddress Маска субсети для данного IP-адреса;
IpAdEntBcastAddr [0...1] Значение младшего бита широковещательного адреса (обычно I);
TpAdEntReasm MaxSize [0...65535] Размер наибольшей IP-дейтограммы, полученной интерфейсом, которая может быть собрана.
Помимо простых переменных объектами MIB могут быть табли-
цы. Для каждой таблицы имеется один или несколько индексов.
Таблица 4.4.10.1.4. Переменные tcp-группы
Переменные tcp- группы Тип данных Описание
tcpRtoMin INTEGER Минимальное допустимое время повторной передачи TCP- пакетов.
tcpRtoMax INTEGER Максимальное значение тайм-аута в миллисек.
tcpMaxConn INTEGER Максимальное допустимое число ТСР- соединений.
tcpInSegs Counter Полное число полученных ТСР-сегментов.
tcpRtoAlgorithm INTEGER Алгоритм, используемый для вычисления времени тайм-аута: I - ни один из следующих; 2 - постоянное RTO; 3 - стандарт MIL-STD-1778; 4 - алгоритм Ван Джакобсона
tcpActiveOpens Counter Число переходов из состояния CLOSED в SYN_SENT.
tcpPassiveOpens Counter Число переходов из состояния LISTEN в SYN_RCVD.
tcpAttemptFails Counter Число переходов из состояния SYN SENT или SYNRCVD в CLOSED.
tcpEstabResets Counter Число переходов из состояния ESTABLISHED или CLOSE_WAIT в CLOSED.
tcpCurrEstab — Gauge Число соединений, находящихся в состоянии ESTABLISHED или CLOSE.WAIT.
JcpInSegs Counter Полное число полученных сегментов.
646
Гпава 4
Таблица 4.4.10.1.4. Переменные tcp-группы (Окончание]
Переменные tcp- группы Тип данных Описание
tcpOutSegs Counter Полное число посланных сегментов, исключая повторно пересылаемые.
tcpRetransSegs Counter Полное число повторно пересланных сегментов.
tcpInErrs Counter Полное число сегментов, полученных с ошибкой.
tcpOutRsts Counter Полное число посланных сегментов с флагом RST=1.
tcpConnTable. TCP-таблица связей
tcpConnState [1-12] Состояние соединения: 1 - CLOSED; 2 - LISTEN; 3 - SYN.SENT; 4 - SYN_RCVD; 5 - ESTABLISHED, 6 - FIN_WAIT_1; 7 - FIN_WAIT_2; 8 - CLOSE_WAIT; 9 - LAST_ACK; 10 - CLOSING; 11 - TIME_WAIT;, 12 - delete TCB. Только последняя переменная может устанавливаться менеджером, немедленно прерывая связь.
TcpConnLocal Address IpAddress Местный 1Р-адрес. 0.0.0.0 означает, что приемник готов установить связь через любой из интерфейсов.
TcpConnLocal Port [0...65535 ] Местный номер порта.
TcpConnLocal Address IpAddress Удаленный 1Р-адрес.
TcpConnRem Port [0...65535 I Удаленный номер порта.
Каждый протокол (например, IP) имеет свою таблицу преобразо-
вания адресов. Для IP это IpNetToMediaTable. Способ пропечатать
эту таблицу с помощью программы snmpi описан ниже.
MIB II содержит управляемые объекты, принадлежащие к груп-
пе SNMP. SNMP-группа предоставляет информацию о SNMP-объек-
тах, информационных потоках, о статистике ошибок:
Сети передачи данных. Метод доступа
647
Таблица 4.4. ТО. Т.5. Переменные icmp-группы
(тип данных - counter]
"^[^еменная ICMP- группы Описание
icmpInEchos Число полученных ICMP-запросов отклика.
icmpInMsgs Полное число полученных ICMP-сообщений.
icmplhErrors Число ICMP-сообщений, полученных с,ошибками.
icmpInDestUnreach Число ICMP-сообщений о недостижимости адресата.
icmpInTimeExcds Число ICMP-сообщений об истечении времени.
IcmpInParmProbs Число полученных ICMP-сообщений о проблемах с параметрами.
icmpInSrcQuench Число ICMP-сообщений с требованием сократить или прервать посылку пакетов из-за перегрузки.
icmpinRedirects Число ICMP-сообщений о переадресации.
icmpInEchoReps Число полученных ICMP-эхо- откликов.
icmpInTimestamps Число ICMP-запросов временных меток.
icmpInaddrMasks Число ICMP-запросов адресных масок.
icmpOutMsgs Число отправленных ICMP- сообщений.
icmpOutErrors Число не отправленных ICMP- сообщений из-за проблем в ICMP (напр. нехватка буферов).
icmpOutTimesExcds Число посланных ICMP-сообщений об истечении времени.
icmpOutParmProbs Число посланных ICMP-сообщений о проблемах с параметрами.
icmpOu t S rcQuench Число посланных ICMP- сообщений об уменьшении потока пакетов.
icmpOutRedirects Число посланных ICMP-сообщений о переадресации.
icmpOutEchos Число посланных 1СМР-эхо-запросов.
icmpOutEchoReps Число посланных 1СМР-эхо-откликов.
icmpOutTimestamps Число посланных ICMP-запросов временных меток.
icmpOutAddrMasks Число посланных ICMP-запросов адресных масок.
Таблица 4.4. Т0.Т.6. Переменные at-группы
[atTable, преобразование адресов).
Переменные at-группы Тип данных Описание
at I [Index INTEGER Число интерфейсов.
atPhysAddress PhysAddress Физический адрес. Если эта переменная равна строке нулевой длины, физический адрес отсутствует.
JitNetAddress Net work Address 1Р-адрес.
648
Гпава 4
Название объекта Описание
snmpInPkts Число пакетов, полученных от слоя, расположенного ниже SNMP.
snmpOutPkts Число пакетов доставленных от SNMP к нижележащему слою.
snmpInBadVersions Индицирует число PDU, полученных с ошибкой в поле версия.
snmpInB adCommuni tyNames Индицирует число PDU, полученных с нечитаемым или нелегальным именем community.
snmpInASNParsErrs Указывает число PDU, которые не могут быть преобразованы в объекты ASN.1 и наоборот.
snmpInBadTypes Указывает число полученных PDU с не дешифруемым типом.
snmpInTooBigs Указывает число полученных PDU со слишком большим значением поля статус ошибки.
snmpInNoSuchNames Указывает число PDU, полученных с индикацией ошибки в поле NoSuchName.
snmpInBadValues Указывает число PDU, полученных с индикацией ошибки в поле BadValue.
snmpInReadOnlys Указывает число PDU, полученных с индикацией ошибки в поле readonly.
snmpInGenErrs Указывает число PDU, полученных с GenErr- полем.
snmpInT otalReq V ar Указывает число объектов MIB, которые были восстановлены.
snmpInTotalSetVars Указывает число объектов MIB, которые были изменены.
snmpInGetRequests snmpInGetNexts snmpInSetRequests snmpInGetResposes snmpInTraps Указывает число соответствующих PDU, которые были получены.
snmpOutTooBig Указывает число посланных PDU с полем tooBig.
snmpOutNoSuchNames Указывает число посланных PDU с полем nosuchName.
snmpOutBadValues Указывает число посланных PDU с полем badValue.
snmpOutReadOnlys Указывает число посланных PDU с полем readonly.
snmpOu tGenErr s Указывает число посланных PDU с полем genErr.
snmpEnableAuthTraps Говорит о том, разрешены или нет ловушки (traps).
snmpOutGetRequests snmpOutGetNexts snmpOutSetRequests snmpOutGetResposes snmpOutTraps Указывает число соответствующих посланных PDU.
Сети передачи данных. Метод доступа
649
Стандарт на структуру управляющей информации (SMI) требует,
чтобы все MIB-переменные были описаны и имели имена в соответ-
ствии с ASN.l (Abstract Syntax Notation 1, формализованный син-
таксис). ASN.1 является формальным языком, который обладает
двумя основными чертами.
Используемая в документах нотация легко читаема и понимае-
ма, а в компактном кодовом представлении информация может
использоваться коммуникационными протоколами. В SMI не ис-
пользуется полный набор типов объектов, предусмотренный в ASN.1,
разрешены только следующие типы примитивов: INTEGER, OCTET
STRING, OBJECT IDENTIFIER и NULL. Практически в протоколе
SNMP фигурируют следующие виды данных:
INTEGER. Некоторые переменные объявляются целыми
(INTEGER) с указанием начального значения или с заданным до-
пустимым диапазоном значений (в качестве примера можно приве-
сти номера UDP- или ТСР-портов).
OCTET STRING (последовательность байтов). В соответствии с
требованиями BER (Basic Encoding Rules, ASN.l) последователь-
ность октетов должна начинаться с числа байт в этой последова-
тельности (от 0 до N).
OBJECT IDENTIFIER (идентификатор объекта). Имя объекта,
представляющее собой последовательность целых чисел, разделен-
ных точками. Например, 192.148.167.129 или 1.3.6.1.2.1.5.
NULL. Указывает, что соответствующая переменная не имеет
значения.
DisplayString. Строка из 0 или более байт (но не более 255),
которые представляют собой ASCII-символы. Является частным
случаем OCTET STRING.
Phys Address. Последовательность октетов, характеризующая
физический адрес объекта (6 байт для Ethernet). Частный случай
OBJECT IDENTIFIER.
Сетевой адрес. Допускается выбор семейства сетевых протоко-
лов. В рамках ASN.l этот тип описан как CHOICE, он позволяет
выбрать протокол из семейства протоколов. В настоящее время иден-
тифицировано только семейство протоколов Интернет.
IP-адрес. Этот адрес используется для определения 32-разряд-
ного Интернет-адреса. В нотации ASN.l — это OCTET STRING.
Time Ticks (такты часов). Положительное целое число, которое
используется для записи, например, времени последнего изменения
параметров управляемого объекта, или времени последней актуали-
зации базы данных. Время измеряется в сотых долях секунды.
650
Гпава 4
Gauge (масштаб). Положительное целое число в диапазоне 0 —
(232-1), которое может увеличиваться или уменьшаться. Если эта
переменная достигнет величины 232-1, она будет оставаться неиз-
менной до тех пор пока не будет обнулена командой сброс. Приме-
ром такой переменной может служить tcpCurrEsta, которая харак-
теризует число TCP соединений, находящихся в состоянии
ESTABLISHED или CLOSE_WAIT.
Counter (счетчик). Положительное целое число в диапазоне 0 —
(232-1), которое может только увеличиваться, допуская переполнение.
SEQUENCE. Этот объект аналогичен структуре в языке Си.
Например, MIB определяет SEQUENCE с именем UdpEntry, содер-
жащую информацию об активных UDP-узлах. В этой структуре
содержится две записи:
1. UdpLocalAddress типа IpAddress, содержит местные IP-адреса.
2. UdpLocalPort типа INTEGER, содержит номера местных портов.
SEQUENCE OF. Описание вектора, все элементы которого име-
ют один и тот же тип. Элементы могут представлять собой простые
объекты, например, типа целое. В этом случае мы имеем одномер-
ный список. Но элементами вектора могут быть объекты типа
SEQUENCE, тогда этот вектор описывает двумерный массив.
В Интернет MIB каждый объект должен иметь имя (OBJECT
IDENTIFIER), синтаксис и метод кодировки.
Стандарт ASN.l определяет форму представления информации
и имен. Имена переменных MIB соответствуют в свою очередь стан-
дартам ISO и CCITT. Структура имен носит иерархический харак-
тер, отображенный на рис. 4.4.10.1.1.
В приведенной ниже таблице охарактеризованы четыре простые
переменные, идентификаторы которых помещены в нижней части
рис. 4.4.10.1.1. Все эти переменные допускают только чтение.
Имя переменной Тип данных Описание
udpInDatagrams Counter Число UDP-дейтограмм, присланных процессам пользователя.
udpNoPorts Counter Число полученных UDP-дейтограмм, для которых отсутствует прикладной процесс в порте назначения.
udplnErrors Counter Число не доставленных UDP-дейтограмм по причинам, отличающимся от отсутствия процесса со стороны порта назначения (напр., ошибка контрольной суммы).
udpDatagrams Counter Число посланных UDP-дейтограмм.
Сети передачи данных. Метод доступа
651
Рис. 4.4.10.1.1 Структура идентификаторов переменных в MIB
Ниже приведено описание таблицы (udpTable; index =
<udpLocalAddress>,<udpLocalPort>), состоящей из двух простых пе-
ременных (read-only).
Имя переменной Тип данных Описание
udpLocalAddress IpAddress Местный IP-адрес для данного приемника;
udpLocalPort (0 - 65535) Местный номер порта приемника.
Согласно этой иерархии переменные, соответствующие icmp, дол-
жны иметь префикс (идентификатор) 1.3.6.1.2.1.5 или в символь-
ном выражении iso.org.dod.internet.mgmt.mib.icmp. Если вы хоти-
те узнать значение какой-то переменной, следует послать запрос,
содержащий соответствующий префикс и суффикс, последний опре-
деляет имя конкретной переменной. Для простой переменной суф-
фикс имеет вид .0.
652
Гпава 4
Помимо стандартного набора переменных и таблиц в MIB воз-
можно использование индивидуальных расширений этой базы дан-
ных. Это можно продемонстрировать на примере MIB маршрутиза-
торов CISCO (рис. 4.4.10.1.2).
Рис. 4.4.10.1.2. Расширение базы данных MIB
маршрутизаторов CISCO
Префикс 1.3.6.1.4.1. является стандартным, далее следует рас-
ширение, индивидуальное для маршрутизаторов компании CISCO.
Например, группа IP Checkpoint Accounting позволяет контролиро-
вать поток байтов с определенных адресов локальной сети, что бы-
вает важно при работе с коммерческими провайдерами услуг.
Коды-префиксы для различных производителей телекоммуника-
ционного оборудования приведены в таблице 4.4.10.1.7.
Сети передачи данных. Метод доступа 653
Таблица 4.4.10.1.7 Коды-префиксы производителей
Код префикса Название фирмы
0 Зарезервировано
1 Proteon
2 IBM
3 сми
4 Unix
5 ACC
6 TWG
7 CAYMAN.
8 PSI
9 CISCO
10 NSC
11 HP
12 Epilogue
13 U of Tennessee
14 BBN
15 Xylogics, Inc.
.16 Unisys
17 Canstar
18 Wellfleet
19 TRW
20 MIT
Группа локальных переменных ip checkpoint accounting
(1.3.6.1.4.1.9.2.4.7.1) представляет собой таблицу, содержащую в
каждом рекорде по четыре переменных (в скобках указан суффикс
адреса MIB для переменной):
• CkactByts [4] — число переданных байт,
• ckactDst [2] — адрес места назначения,
• ckactPkts [3] — число переданных пакетов
• ckactSrc [1] — адрес отправителя
Маршрутизаторы CISCO поддерживают две базы данных: active
accounting и checkpoint accounting. В первую заносятся текущие
результаты измерения входящего и исходящего трафика. Эти ре-
зультаты копируются в базу данных checkpoint accounting и, если
там уже имеются предыдущие данные, они объединяются. Для очи-
стки базы данных Checkpointed Database выдается команда clear ip
accounting,а для базы Checkpoint - clear ip accounting checkpoint
(для использования этих команд необходимы системные привиле-
гии). Объем памяти, выделяемой для этих баз данных задается
Командой ip accounting-threshold <значение>,по умолчанию макси-
мальное число записей в базе данных равно 512.
654 х Гпава 4 <
Лучшим способом закрепить в памяти все вышесказанное явля- |
ется использование программы snmpi (SNMP initiator) или ее анало-
га. Если в вашем распоряжении имеется ЭВМ, работающая под UNIX,
например SUN, вы можете попутно узнать много полезного о вашей :
локальной сети. Ниже описан синтаксис обращения к snmpi. I
snmpi [-a agent] [-с community] [-f file] [-p portno] [-d] [-v] [-w]
snmpi -7- крайне простая программа, используемая для тестиро- :
вания snmpd. Для того чтобы проверить, работает ли она, выдайте
команду:
snmpi dump {
Следует отметить, что в ответ на эту операцию будет произведе-
на весьма объемная выдача. ;
Опция -а предлагает возможность ввести адрес SNMP-объекта f
— имя ЭВМ, IP-адрес или транспортный адрес. По умолчанию это |
местная ЭВМ. Аналогично опция -р позволяет задать номер UDP- 4
порта. По умолчанию это порт 161. |
Опция -с позволяет задать групповой пароль (community) для J
SNMP-запроса. По умолчанию — это public, т.е. свободный доступ, f
Опция -f позволяет выбрать файл, содержащий откомпилиро- f
ванные описания MIB-модулей. По умолчанию — это objects.defs. j
Опция -w включает режим наблюдения, осуществляя выдачу на %
терминал всех служебных сообщений. Уход из программы по ко- J
манде quit (q).
Если вы работаете на IBM/PC, и ваша машина подключена к ло- .
кальной сети, получите допуск к одной из UNIX-машин в сети (если ?
вы его не имели) и приступайте. Можно начать с обращения типа:
snmpi -a 193.124.224.33 (адрес или символьное имя надо взять ’•
из вашей локальной сети)
Машина откликнется, отобразив на экране snmpi>, это означает,
что программа имеется и вы можете вводить любые команды.
Начать можно со знакомства с системными переменными систе-
мы (в дальнейшем курсивом выделены команды, введенные с кла-
виатуры):
snmpi> get sysDescr.O
snmpi> sysDescr.O=»GS Software (GS3-K), Version 9.1(4) [fcl],
SOFTWARE Copyright (c) 1986-1993 by cisco Systems, Inc. 4
Compiled Thu 25-Mar-93 09:49 by daveu»
Сети передачи данных. Метод доступа
655
snmpi> get sysObjectlD.O
snmpi> sysObjectID.0=1.3.6.1.4.1.9.1.1
snmpi> get sysUpTime.O
snmpi> sysUpTime.0=14 days, 7 hours, 0 minutes, 15.27 seconds
(123481527 timeticks)
snmpi> get sysServices.O
snmpi> sysServices.0=0x6<datalink/subnetwork,internet>
Код 0x06 (sysServices.O) представляет собой сумму кодов уров-
ней модели ISO, поддерживаемых системой. Для справок: 0x01 —
физический уровень; 0x02 - связной уровень; 0x04 — Интернет;
0x08 — связь точка-точка; 0x40 — прикладной уровень.
Если вы хотите получить информацию о состоянии интерфейсов
на одной из ЭВМ, подключенных к вашей локальной сети (команды
вызова snmpi далее не повторяются; в ниже приведенных примерах в
круглых скобках помещены комментарии автора), выдайте команды:
snmpi> next ifTabl (команда next в данном случае соответству-
ет запросу get-next, здесь понятие «следующий» подразумевает по-
рядок переменных в MIB)
snmpi> iflndex.l=l
snmpi> get ifDescr.l
snmpi> ifDescr.l=»EthernetO"
snmpi> get ifType.l
snmpi> if Type. l=ethernet-csmacd(6)
snmpi> get ifMtu.l
snmpi> ifMtu.1=1500
snmpi> get ifSpeed.l f
snmpi> if Speed. 1=10000000 (10M6/c Ethernet)
snmpi> get ifPhysAddress.l
snmpi> ifPhysAddress.l=0x00:00:0c:02:3a:49
(физический адрес интерфейса)
snmpi> next ifDescr.l ifType.l ifMtu.l ifSpeed.l ifPhysAddress.l
snmpi> ifDescr.2=»Seria!0"
ifType.2=propPointToPointSerial(22)
ifMtu.2=1500
if Speed. 2=2048000 (2 Мбит/с радиорелейный последователь-
7 ный канал, спутниковый канал был бы
охарактеризован точно также).
if Phys Address. 2=
65В Гпава 4
В приведенном примере размеры пересылаемых блоков для
Ethernet и радиорелейного последовательного канала идентичны и
равны 1500. Помните, что SLIP-канал характеризуется как
PointToPointSerial, а не SLIP. Скорость обмена по SLIP-каналу не
сообщается.
Теперь просмотрим некоторые UDP-переменные. Например:
snmpi> next udp
snmpi> udpInDatagrams.0=98931
snmpi> next udpInDatagrams.O (обратите внимание на суффикс
простой переменной)
snmpi> udpNoPorts.0=60009
snmpi> next udpLocalAddress.O
snmpi>udpLocalAddress.l93.124.137.14.7=193.124.137.14 t
(Идентификатор этого объекта —
1.3.6.1.2.1.7.5.1.1.193.124.137.14.7.)
snmpi> next udpLocalPort
snmpi> udpLocalPort. 193.124.137.14.7=7
Если у вас возникла необходимость просмотреть таблицу, напри- <
мер, udpTable, это также можно сделать, используя snmpi:
snmpi> next udpTable
snmpi> udpLocalAddress.l93.124.137.14.7=193.124.137.14
snmpi> next udpLocalAddress.193.124.137.14.7 >
snmpi> udpLocalAddress. 193.124.224.33.67=193.124.224.33
snmpi> next udpLocalAddress.193.124.224.33.67
snmpi> udpLocalAddress.193.124.224.33.161=193.124.224.33 '
snmpi> next udpLocalPort.l 93.124.224.33.6 7
snmpi> udpLocalPort. 193.124.224.33.161=161
Ниже показана методика выяснения алгоритма и параметров
задания величины тайм-аута:
snmpi> get tcpRtoAlgortthm.O tcpRtoMin.O tcpRtoMax.O
cpMaxConn.O
snmpi> tcpRtoAlgorithm.0=vanj(4) (vanj — алгоритм Ван
Джакобсона для расчета времени тайм-аута)
tcpRtoMin.0=300 (минимальное значение тайм-аута = 300 мс)
tcpRtoMax.0=60000 (максимальное — 60 сек) *
tcpMaxConn.0=-l (никаких ограничений на число соединений)
В57
передачи данных. Метод доступа
Чтобы получить информацию о состоянии таблицы адресных
еобразований, выдайте команду: snmpi -а 193.124.224.33 dump
а^ (процедуры с использование субкоманды dump требуют опреде-
ленного времени для своего исполнения)
atlflndex.l.1.193.124.224.33= 1
atlflndex.l. 1.193.124.224.35= 1
atlflndex.3.1.192.148.166.203= 3
atlflndex.3.1.192.148.166.205= 3
atlf Index. 5.1.145.249.30.33= 5
atlflndex.5.1.192.148.166.98= 5
atPhysAddress.l.1.193.124.224.33= 0x00:00:0c:02:3a:49
atPhysAddress.l. 1.193.124.224.35= 0x08:00:20:12:lb:bl
atPhysAddress.l.1.193.124.224.40= 0x00:00:cd:f9:0d:e7
atPhysAddress.l. 1.193.124.224.50= 0x00:00:0c:02:fb:c5
atNetAddress.1.1.193.124.224.33= 193.124.224.33
atNetAddress. 1.1.193.124.224.35= 193.124.224.35
atNetAddress. 1.1.193.124.224.40= 193.124.224.40
atNetAddress. 1.1.193.124.224.50= 193.124.224.50
atNetAddress. 1.1.193.124.224.60= 193.124.224.60
Текст выдачи с целью экономии места сокращен.
Обычно элементы таблицы расположены в порядке колонка-
ряд. Если вы дошли до края колонки или всей таблицы ЭВМ вы-
даст вам, в зависимости от реализации программы, имя и значение
следующего элемента или сообщение об ошибке.
Чтобы получить полный текст адресной таблицы в рамках snmpi
достаточно выдать команду:
snmpi> dump ipAddrTable
snmpi> ipAdEntAddr.192.148.166.222= 192.148.166.222
ipAdEntAddr.l92.168.1.1= 192.168.1.1
ipAdEntAddr.192.168.1.2= 192.168.1.2
ipAdEntAddr.193.124.224.33= 193.124.224.33
ipAdEntAddr.193.124.224.190= 193.124.224.190
ipAdEntlf Index. 192.148.166.222= 3
ipAdEntIfIndex.l92.168.1.1= 4
ipAdEntIfIndex.l92.168.1.2= 6
ipAdEntlf Index. 193.124.224.33= 1
ipAdEntlf Index. 193.124.224.190= 5
(Маски субсетей)
ipAdEntNetMask.l92.148.166.222= 255.255.255.224
658
Гпава 4
ipAdEntNetMask.l92.168.1.1= 255.255.255.0
ipAdEntNetMask.l92.168.1.2= 255.255.255.0
ipAdEntNetMask.193.124.224.33=255.255.255.224
ipAdEntNetMask.193.124.224.190= 255.255.255.224
ipAdEntBcastAddr.l92.148.166.222= 1 (Все эти субсети исполь-
зуют для широковещательной адресации одни и те же биты).
ipAdEntBcastAddr.l92.168.1.1= 1
ipAdEntBcastAddr.l92.168.1.2= 1
ipAdEntBcastAddr.193.124.224.33= 1
i pAdEntBcastAddr. 193.124.224.190= 1
ipAdEntReasmMaxSize.l92.148.166.222= 18024 (С точки зре-
ния фрагментации и последующей сборки дейтограмм данные суб-
сети эквивалентны).
ipAdEntReasmMaxSize.l92.168.1.1= 18024
ipAdEntReasmMaxSize,192.168.1.2= 18024
ipAdEntReasmMaxSize,193.124.224.33= 18024 £
ipAdEntReasmMaxSize,193.124.224.190= 18024
Эта пропечатка совместно с приведенной для ifTable позволяет
получить достаточно полную картину о данной конкретной локаль-
ной сети. Чтобы познакомиться с ARP таблицей, можно воспользо-|
ваться командой:
sun> arp -a
itepgw.itep.ru (193.124.224.33) at 0:0:c:2:3a:49
nb.itep.ru (193.124.224.60) at 0:80:ad:2:24:b7.
и дополнить полученные данные с помощью snmpi:
snmpi> dump ipNetToMediaTable
snmpi> ipNetToMedialflndex. 1.193.124.224.33= 1
ipNetToMedialflndex. 1. 193.124.224.35= 1
i pNetToMedialf Index .3.192.148.166.193=
ipNetToMedialflndex.3.192.148.166.196=
ipNetToMedialflndex.3.193.124.226.110=
ipNetToMedialflndex.5.145.249.30.33= 5
i pNetToMedialf Index .5.192.148.166.100=
ipNetToMediaPhysAddress. 1.193.124.224.33=
0x00:00:0c:02:3a:49
i pN etToMediaPhysAddr ess .3.192.148.166.196=
0xaa:00:04:00:0c:04
i pNe tToMediaPhysAddress .3.192.148.166.198=
0xaa:00:04:00:0e:04
i pNetToMediaPhysAddress .3.192.148.166.203= _
0x00:00:01:00:54:62
3
3
3
5
Сети передачи данных. Метод доступа
659
ipNetToMediaPhysAddress.5.145.249.30.33=
0x00:00:0c:02:69:7d
ipNetToMediaPhysAddress.5.192.148.166.100=
0x00:20:af:15:cl:61
i pNe tToMediaPhys Address .5.192.148.166.101=
0x08:00:09:42:0d:e8
ipNetToMediaNetAddress. 1.193.124.224.33= 193.124.224.33
ipNetToMediaNetAddress.l.193.124.224.35= 193.124.224.35
ipNetToMediaNetAddress.3.192.148.166.193=192.148.166.193
ipNetToMediaNetAddress.3.193.124.226.110=193.124.226.110
ipNetToMediaNetAddress. 5.145.249.30.33= 145.249.30.33
ipNetToMediaType. 1.193.124.224.33= other(l)
ipNetToMediaType. 1.193.124.224.35= dynamic(3)
ipNetToMediaType. 1.193.124.224.37= dynamic(3)
ipNetToMediaType.3.192.148.166.195= dynamic(3)
ipNetToMediaType.3.192.148.166.222= other(l)
ipNetToMediaType. 5.193.124.224.190= other(l)
ipNetToMediaType. 5.193..124.225.33= other(l)
ipNetToMediaType. 5.193.124.225.35= dynamic(3)
Синтаксис каждого объекта описывается в рамках ASN.1 и по-
казывает побитовое представление объекта. Кодирование объекта
характеризует то, как тип объекта отображается через его синтак-
сис и передается по телекоммуникационным каналам. Кодирование
производится в соответствии с базовыми правилами кодирования
ASN.1. Все описания объектов базируются на типовых шаблонах и
кодах ASN.1 (см. RFC-1213). Формат шаблона показан ниже:
OBJECT (Объект):
Имя типа объекта с соответствующим ему идентификатором
объекта (OBJECT IDENTIFIER)
Syntax (Синтаксис):
ASN.1 описание синтаксиса типа объекта.
Definition (Определение):
Текстовое описание типа объекта.
Access (доступ):
Опции доступа.
Status (состояние):
Статус типа объекта.
660
Гпава 4
Маршруты также являются объектами MIB. Согласно требова-
ниям к MIB, каждому маршруту в этой базе соответствует запись,
схема которой приведена ниже на рис. 4.4.10.1.3:
Место назначения (ipRouteDest)
Индекс интерфейса (ipRouteIflndex)
Метрика 1 (ipRoute Metric!)
Метрика 5 (ipRoute Metric5)
Следующий шаг (ipRouteNextHop)
Тип маршрута (ipRouteType)
Протокол маршрутизации
(ip Route Pro to)
Возраст маршрута (ip Rout eAge)
Маска маршрута (ipRoute Mask)
Маршрутная информация (ipRouteinfo)
Рис. 4.4.10.1.3 Формат записи маршрутной таблицы в Ml В
Поле место назначения представляет собой IP-адрес конечной
точки маршрута. Поле индекс интерфейса определяет локальный
интерфейс (физический порт), через который можно осуществить
очередной шаг по маршруту. Следующие пять полей (метрика 1-5)
характеризуют оценку маршрута. В простейшем случае, например
для протокола RIP, достаточно было бы одного поля. Но для прото-
кола OSPF необходимо 5 полей (разные TOS). Поле следующий шаг
представляет собой IP-адрес следующего маршрутизатора. Поле тип
маршрута имеет значение 4 для опосредованного достижения места
назначения; 3 — для прямого достижения цели маршрута; 2 — для
нереализуемого маршрута и 1 - для случаев отличных от вышепе-
речисленных.
Поле протокол маршрутизации содержит код протокола. Для
RIP этот код равен 8, для OSPF — 13, для BGP — 14, для IGMP —
4, для прочих протоколов — 1. Поле возраст маршрута описывает
время в секундах, прошедшее с момента последней коррекции марш-
рута. Следующее поле — маска маршрута используется для вы-
Сети передачи данных. Метод доступа
661
полнения логической побитовой операции И над адресом в 1Р-дей-
тограммы перед сравнением результата с кодом, хранящимся в пер-
вом поле записи (место назначения). Последнее поле маршрутная
информация содержит код, зависящий от протокола маршрутиза-
ции и обеспечивающий ссылки на соответствующую информацию в
базе MIB.
Новым расширением MIB является система удаленного мо-
ниторинга сетей (RMON; RFC-1513, -1271). RMON служит для
мониторирования сети в целом, а не отдельных сетевых устройств.
В RMON предусмотрено 9 объектных групп (см. табл. 4.4.10.1.8).
Таблица 4.4.10.1.8. Функциональные группы RMON
Группа Назначение
statistics Таблица, которая отслеживает около 20 статистических параметров сетевого трафика, включая общее число кадров и количество ошибок
history Позволяет задать частоту и интервалы для измерений трафика
alarm Позволяет установить порог и критерии, при которых агенты выдают сигнал тревоги
host Таблица, содержащая все узлы сети, данные по которым приводятся в сетевой статистике
hostTopN Позволяет создать упорядоченные списки, которые базируются на пиковых значениях трафика группы ЭВМ
matrix Две таблицы статистики трафика между парами узлов. Одна таблица базируется на адресах узлов-отправителей, другая - на адресах узлов-получателей
filter Позволяет определить конкретные характеристики кадров в канале. Например, можно выделить ТСР- трафик.
packet capture Работает совместно с группой filter. Позволяет специфицировать объем ресурса памяти, выделяемой для запоминания кадров, которые отвечают критериям filter.
event Позволяет специфицировать набор параметров или условий, которые должен контролировать агент. Когда условия выполняются, информация о событии записывается в специальный журнал
Для того чтобы реализовать функционирование RMON-агента, се-
тевая карта должна быть способна работать в режиме 6 (promiscuous
^ode), когда воспринимаются все пакеты, следующие по кабельному
сетевому сегменту.
'f
662 Глава 4 у
4.4.10.2. НотацияASN.1
Одной из наиболее сложных систем сегодня являются откры-
тые системы связи OSI (Open System Interconnection). OSI представ-
ляет собой достаточно формализованную стандартную архитектуру
управления межкомпьютерными коммуникациями. Для описания J
этой системы была разработана абстрактный синтаксис нотаций
ASN.1 (Abstract Syntax Notation; см. A Layman’s Guide to a Subset ?
of ASN.1, BER, and DER. Burton S. Kaliski Jr., RSA Data Security, ”*
Inc. Redwood City, CA, 1991). ASN.1 является формальным языком,
который обладает двумя основными чертами. $
Используемая в документах нотация легко читаема и понимае-
ма, а в компактном кодовом представлении информация может
использоваться коммуникационными протоколами. Неотъемлемой
частью ASN.1 являются базовые правила кодирования BER (Basic
Encoding Rules), которые позволяют определить большое разнооб-
разие типов данных. BER описывает то, как представить или зако-
дировать любую величину в рамках стандарта ASN.1. Практически f
все величины здесь представляются в виде последовательности 8-
битных октетов. Восьмой бит октета всегда считается самым стар- Л
шим. BER позволяет закодировать величину более чем одним спо-1
собом. Имеется также поднабор правил кодирования DER
(Distinguished Encoding Rules, описаны в документе Х.509), кото-
рые определяют однозначные способы кодирования величин ASN.1. г
Ниже приведены базовые правила обозначений метасинтаксиса 7
ASN.1.
п (полужирный курсив) обозначает переменную
[] указывают на то, что терм является опционным.
{} группируют родственные термы.
| выделяет альтернативные значения,
обозначает повторения.
= описывает терм как субтерм.
ASN.1 имеет четыре разновидности типов: простые типы, не
имеющие компонент, структурные типы, имеющие компоненты, по-
меченные (tagged) типы, которые получаются из других типов, а
также прочие типы, которые включают в себя типы CHOICE и ANY.
Типам и значениям могут присваиваться имена с помощью опера-
тора (::=). Эти имена в дальнейшем могут использоваться для оп-
ределения других типов и величин.
Все типы ASN.1 кроме CHOICE и ANY имеют метки, которые
состоят из класса и неотрицательного кода метки. Типы ASN.1 *
тождественны, если их числовые метки совпадают. Существует че* *
тыре класса меток.
Сети передачи данных. Метод доступа
663
universal Для типов, значения которых является неизмен- ным для всех приложений. Эти типы определены в документе Х.208.
application Для типов со значением, специфическим для приложений, таких как служба каталогов Х.500. Типы двух разных приложений могут иметь одну и ту же метку и разные значения.
private Для типов, которые являются специфическими для данного предприятия.
content-specific Для типов со значением, специфическим для
данного структурного типа.
Ниже приведена таблица 4.4.10.2.1 типов и их меток универ-
сального класса.
Таблица 4.4.10.2.1. Типы и их метки
Тип Комментарий Цифровая метка (шестнадца- теричная)
INTEGER Любое целое число 02
BIT STRING Произвольная строка бит 03
OCTET STRING Произвольная последовательность октетов 04
NULL 0 05
OBJECT IDENTIFIER Последовательность целых компонент, идентифицирующих объект 06
S EQUENCE и SEQUENCE OF Упорядоченный набор объектов Ю
SET и SET OF Неупорядоченный набор объектов И
PrintableString Последовательность печатных символов 13
lA5String Произвольная строка символов IA5 (ASCII) 16
UTCTime Универсальное время (по Гринвичу; GMT) 17
ASN.l типы и значения выражаются в нотации, близкой к ис-
пользуемой в языках программирования. Множественные пробелы
и разрывы строк рассматриваются как один пробел. Комментарии
выделяются парами дефисов или парой дефисов и переводом стро-
пи. Идентификаторы (имена значений и полей) и имена типов со-
стоят из букв, цифр и пробелов. Идентификаторы начинаются со
строчной буквы, а имена типов - с прописной.
664
Гпава 4 <
В SMI (Structure of Management Information) не используется
полный набор типов объектов, предусмотренный в ASN.1, разреше-
ны только следующие типы примитивов: INTEGER, OCTET STRING,
OBJECT IDENTIFIER и NULL.
Стандарт ASN.l определяет форму представления информации
и имен. Для строчных типов может быть введено ограничение на
максимальный размер. В ASN.1 определено четыре структуриро-
ванных типов: £
SEQUENCE упорядоченный набор из одного или более типов.
SEQUENCE OF упорядоченный набор из нуля или более предста- |
вителей данного типа. J
SET неупорядоченный набор из одного или более типов. 7
SET OF неупорядоченный набор из нуля или более пред- ?
ставителей данного типа.
Структурированные типы могут иметь опционные компоненты, ч
в том числе со значениями по умолчанию.
Существуют типы помеченные явно и неявно. Неявно помечен- ?.
ные типы получаются из других типов путем изменения метки. Для ;
неявной пометки используется ключевое слово IMPLICIT. Явно по-
меченные типы получаются из других типов путем добавления внеш-;
ней метки. Помеченный явно тип - это структурированный тип, со-"
стоящий из одного компонента основного типа. Для явной пометки |
используется ключевое слово EXPLICIT. Пометка (тэгирование) весьма^
удобна для различия типов в пределах одного приложения.
Тип CHOICE обозначает объединение одного или более альтерна-
тив. Тип ANY служит для обозначения произвольной величины £
для произвольного типа.
Правила BER определяют один или более способов представить \
любую величину в виде строки октетов. Существует три метода?
кодирования величин (в рамках BER): примитивный с известной- ;
длиной; конструктивный при известной длине и конструктивный
при неизвестной длине. Выбор метода зависит от типа величины и
от того, известна ли длина преобразуемой величины. Для простых
не строчных типов используется примитивный метод кодирования.
В каждом методе BER-кодирование имеет три или четыре части:
Identifier octets
(октеты идентификатора)
Length octets
(октеты длины)
Contents octets
(октеты содержимого)
Определяет класс и числовую метку значения,
а также указывает, является ли метод
примитивным или конструктивным. г4
Для методов кодирования с известной длиной г
определяет число октетов содержимого.
Для примитивных методов с заданной длиной
дает конкретное выражение значения. I
Сеги передачи данных. Метод доступа
665
gnd-of-contents octets
(октеры конца
содержимого)
Для конструктивных методов с
неопределенной длиной указывает на конец
содержимого.
Примитивный метод кодирования с заданной длиной
Этот метод применим для простых типов и типов подученных
из простых типов путем неявной пометки. Здесь необходимо, чтобы
длина величины была известна заранее. Октеты идентификатора
имеют два формата: для числовых меток от 0 до 31, и для числовых
меток более 31. В первом случае биты 7 и 8 определяют класс (см.
таблицу 4.4.10.2.2), бит 6 равен нулю, указывая на то, что метод
кодирования primitive. Остальные биты используются для записи
кода числовой метки. Во втором случае используется два цли более
октетов. В первом октете кодировка аналогична первому варианту
за исключением того, что биты 1-5 содержат единицы.
Таблица 4.4.10.2.2. Коды классов
Класс Бит 8 Бит 7
Универсальный 0 0
Прикладной 0 1
Контекстно-ориентированный 1 0
Частный 1 1
Для октетов длины примитивного метода имеется два формата:
короткий (один октет для длин 0-127) и длинный (2-127 октетов).
Для короткой формы 8-ой бит октета всегда равен нулю. Для длин-
ной формы восьмой бит первого октета всегда равен 1, биты 1-7
содержат код числа дополнительных октетов длины. Старшая циф-
ра записывается первой.
Конструктивный метод с заданной длиной
Этот метод используется для простых строчных и структуриро-
ванных типов, типов, производных от простых строчных типов, и
некоторых других. Здесь октеты идентификатора и октеты дли-
ны имеют формат, идентичный используемому примитивным мето-
лом, за исключением того, что бит 6 первого октета идентификатора
Равен 1.
Конструктивный метод кодирования с незаданной длиной
Метод используется для простых строчных типов, структуриро-
ванных типов и типов, полученных из простых и структурирован-
НЬ1Х типов с помощью неявной пометки. Октеты идентификатора
идентичны предшествующему. Октет длины содержит код 80. Два
Тета конца содержательной части содержат 00 00.
see
Гпава 4
Нотация типов, помеченных неявно, имеет вид:
[[class] number] IMPLICIT Type
class = UNIVERSAL | APPLICATION | PRIVITE
где Type - тип, class - опционное имя класса и number - цифровая
метка (неотрицательное целое число).
Если имя класса отсутствует, тогда метка является контекстно-
ориентированной. Такие метки могут появляться только в струк-
турных компонентах или в типе CHOICE. Например:
PrivateKeylnfo ::= SEQUENCE {
version Version,
privateKeyAlgorithm PrivateKeyAlgorithmldentifier,
privateKey PrivateKey,
attributes [0] IMPLICIT Attributes OPTIONAL}
Здесь исходным (порождающим) типом является Attributes, класс
отсутствует (т.е. контекстно-ориентированный), а числовая метка
равна нулю. Кодирование компоненты attributes величины
PrivateKeylnfo осуществляется следующим образом.
Октеты идентификатора равны 80, если значение порождающей
величины Attributes имеет конструктивное BER-кодирование. Окте-
ты длины и содержимого строго соответствуют октетам порождаю-
щей величины Attributes.
Непосредственная (явная) пометка используется для опцион-
ных компонент SEQUENCE с порождающим типом ANY и для
компонент version типа Certificate (Х.509 и RFC-1114). Нотаций
типов, помеченных явно, имеет формат.
[ [class] number] EXPLICIT Type
class = UNIVERSAL | APPLICATION | PRIVATE
где Type - тип, class - опционное имя класса, a number - числовая
метка в пределах класса (неотрицательное целое число). Пример:
Contentinfo ::= SEQUENCE {
ContebtType ContentType,
Content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL};
Тип Contentinfo имеет опционную компоненту content с явной,.
контекстно-ориентированной меткой. Здесь порождающим типом
Сети передачи данных. Метод доступа
667
является ANY DEFINED BY contentType, класс отсутствует, а число-
вая метка в пределах класса равна 0.
Другим примером может являться тип Certificate [Х.509], име-
ющий компоненту с явной контекстно-ориентированной меткой (клю-
чевое слово EXPLICIT опущено).
Certificate ...
Version [0] Version DEFAULT vl988,
BER-кодирование величин, помеченных явно, является всегда
конструктивным. Октеты содержимого идентичны соответствующим
октетам порождающей величины. Например, BER-кодирование ком-
поненты content величины Contentinfo имеет следующий вид.
Октеты идентификатора равны нулю, Октеты длины представля-
ют длину BER-кодирования порождающей величины ANY DEFINED
BY contentType.
Тип ANY
Тип ANY обозначает произвольную величину произвольного типа,
где произвольный тип возможно определен при регистрации иден-
тификатора объекта или является целочисленным индексом. Нота-
ция типа ANY имеет формат:
ANY [DEINED BY identifier]
где identifier - опционный идентификатор. Форма ANY DEINED
BY identifier может появиться только в компоненте типа SEQUNCE
или SET, для которой identifier определяет какую-то другую компо-
ненту и эта компонента имеет тип INTEGER или OBJECT
IDENTIFIER. В этой форме истинный тип задается величиной этой
Другой компоненты. Например, тип Algorithmidentifier [Х.509] имеет
компоненту типа ANY:
Algorithmidentifier SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameter ANY DEFINED BY algorithm OPTIONAL}
Здесь истинный тип компоненты parameter зависит от величины
компоненты algorithm. Истинный тип будет определен при регист-
рации объекта величины идентификатора для компоненты algorithm.
668
Гпава 4
Битовые строки
Тип BIT STRING обозначает произвольные битовые последова-
тельности произвольной длины (включая ноль). Тип BIT STRING
используется для цифровых сигнатур типа ExtendedCertificate или
Certificate [Х.509]. Нотация BIT STRING имеет формат.
BIT STRING
Например, тип SubjectPublicKeylnfo имеет компоненту типа BIT
STRING:
SubjectPublicKeylnfo ::= SEQUENCE {
Algorithm Algorithmidentifier,
PublicKey BIT STRING }
BER-кодирование величины BIT STRING может быть примитив-
ным или конструктивным. При примитивном кодировании первый
октет содержимого несет в себе длину битовой строки в октетах. В
последующих октетах записывается сама битовая последователь-
ность. Процедура кодирования может включать в себя дополнение
битовой строки до целого числа октетов нулями (если это необхо-
димо). Строка делится на октеты.
При конструктивном кодировании октеты содержимого пред-
ставляют собой соединение последовательности субстрок, только
последняя из которых содержит код длины, выраженный в октетах.
Например, при BER-кодировании значения BIT STRING «0111 1101
1001 1111 11» может быть представлена в одном из следующих
видов, в зависимости от выбора схемы дополнения до целого числа
октетов, от формата октетов длины и от метода кодирования (при-
митивный/конструктивный).
03 04 06 7D 9F СО DER-кодирование
03 04 06 7D 9F Е0 Дополнение кодом «100000»
03 81 04 06 7D 9F СО Длинная форма представления октетов длины
23 09 03 03 00 7D 9F 03 02 06 СО
Конструктивное кодирование
«01111101 1001 1111» +”11”
Первый октет первых трех представлений содержат код типа
(для BIT STRING = 03). Второй октет в первых двух представлени-
ях - код октетов длины (ведь далее следует 4 октета). Третий октет
первой и второй строк содержит число добавленных нулей до числа
Сети передачи данных. Метод доступа
669
бит, кратного восьми. Во втором байте третей строки записана 8,
что указывает на длинную форму представления октетов длины.
Последующая 1 говорит о том, что использован один дополнитель-
ный октет длины. Код длины в четвертом примере записан также
во втором октете (далее следует 9 октетов). В этом варианте бито-
вая строка разбита на две субстроки, первая из которых имеет дли-
ну в два октета. DER-кодирование предполагает всегда примитив-
ный метод представления с дополнением строки нулями до длины,
кратной целому числу октетов.
Тип CHOICE
Этот тип служит для объединения одной или более альтерна-
тив. Нотация типа CHOICE имеет формат.
CHOICE {
[identifier^
Type,,
[identifier J Typen}
где identifierx ..., identifiern являются опционными идентификатора-
ми альтернатив, а типы Туре19 ..., Туреп - альтернативы. Идентифи-
каторы нужны для документирования и не играют какой-либо роли
при кодировании. Типы должны иметь определенные метки. Рас-
смотрим пример типа ExtendedCertificateOrCertificate, который от-
носится к типу CHOICE.
ExtendedCertificateOrCertificate ::= CHOICE {
certificate Certificate, — X.509 certificate
extendedCertificate [0] IMPLICIT ExtendedCertificate }
Здесь идентификаторами для альтернатив являются certificate и
extendedCertificate, а сами альтернативы представлены типами
Certificate и [0] IMPLICIT ExtendedCertificate. BER-кодирование для
типа CHOICE сводится к кодированию альтернатив. При этом окте-
ты идентификатора для рассмотренного примера содержат код 30,
если выбранная альтернатива certificate, и АО - в случае
ExtendedCertificate.
Строки IA5
Тип IA5String представляет любые последовательности 1А5-сим-
волов (международный алфавит 5 - эквивалентно ASCII). Длина
строки может быть любой, включая нуль. Этот тип используется
670
Гпава 4
для адресов электронной почты и неструктурированных имен. Но-
тация типа IA5String имеет простой формат.
IA5String
BER-кодирование величины IA5String может быть примитив-
ным или структурированным. При примитивном кодировании ок-
теты содержимого представляют собой символы IA5 (ASCII-кода).
При конструктивном кодировании октеты содержимого представ-
ляют собой соединение ряда 1А5-субстрок. Рассмотрим примеры
представления значения 1А5-строки «testl@rsa.com».
12 0D 74 65 73 74 31 40 72 73 61 2Е 63 6F 6D DER-кодирование
12 81 0D 74 65 73 74 31 40 72 73 61 2Е 63 6F 6D Длинная форма октетов длины
32 13 Конструктивное
12 05 74 65 73 74,31 кодирование: «testI»
12 0140 +«@» +
12 07 72 73 61 2Е 63 6F 6D «rsa.com»
DER-кодирование является всегда примитивным, октеты содер-
жимого идентичны случаю BER-кодирования.
Целое
Тип INTEGER представляет любые целые числа (положитель-
ные, отрицательные или 0). Тип INTEGER используется для номе-
ров версий, криптографических параметров (показателей, модулей) и '
типов RSAPublicKey, RSAPrivatKey, DHParameter PBEParameter.
Нотация типа INTEGER имеет формат:
INTEGER [{identifier Rvalue J ... identifier Rvalue*) }]
где identifierr ... identifiern являются опционными идентификатора- ,
ми, a valuef... value* опционные целые значения. Например, Version
RFC-1114 относится к целому типу со значением:
Version ::== INTEGER { 1988(0) } j
Идентификатору vl988 поставлено в соответствие значение 0. |
Тип Certificate RFC-1114 использует идентификатор 1988 для при-
своения значения по умолчанию компоненту version: *
Certificate >.
version Version DEFAULT vl988, 1
Сети передачи данных. Метод доступа
G71
BER-кодирование значения INTEGER является всегда прими-
тивным. Октеты содержимого представляют значение целого по мо-
дулю 256 в форме дополнения по модулю 2. Старшая цифра явля-
ется первой. Значение нуль кодируется одним октетом 00. Приме-
ры BER-кодирования (совпадающего в данном случае с
DER-кодированием) представлены в таблице 4.4.10.2.3.
Таблица 4.4.10,2.3, Примеры BER-кодирования
Значение целого BER-код
0 02 01 00
127 02 02 00 7F
128 02 02 00 80
256 02 02 01 00
-128 02 01 80
-129 02 02FF7F
NULL
Тип NULL обозначает нулевую величину и предназначен для
использования в качестве параметра алгоритмов. Нотация для типа
NULL имеет формат:
NULL
Кодирование для типа NULL является всегда примитивным, ок-
теты содержимого пусты. Например, BER-представление значения
NULL может иметь одну из приведенных ниже форм (зависит от
используемого представления октетов длины).
05 00
05 81 00
DER-кодирование типа NULL является также примитивным и
совпадает с первой строкой приведенного выше примера.
Объектные идентификаторы
Тип OBJECT IDENTIFIER служит для обозначения идентифика-
торов, которые представляют собой последовательность целочислен-
ных компонент, которые идентифицируют такие объекты, как алго-
ритм или атрибут имени каталога. Значение OBJECT IDENTIFIER
м°жет содержать любое число неотрицательных компонент. Этот
тип не относится в числу строчных. Значения OBJECT IDENTIFIER
присваиваются при регистрации.
672
Гпава 4
Тип OBJECT IDENTIFIER используется для идентификации со-
держимого Contentinfo, алгоритмов в Х.509 (Algorithmldentifier) и
атрибутов Attribute и Attribute Value Assertion (Х.501). Нотация
OBJECT IDENTIFIER имеет формат.
OBJECT IDENTIFIER
Нотация величины OBJECT IDENTIFIER имеет вид:
{[identifier] componentr. component n }
component. = identifier. | identifier. (value.) | value.
где identifier, identifiert,... identifierл являются идентификаторами, a
value2 ..., valuen - опционные целые числа. Идентификаторы без
целых значений могут встретиться только для объектов, описанных
в Х.208.
Например, нижеприведенные величины объектных идентифика-
торов присвоены RSA DATA Security, Inc.
{ iso(l) member-body(2) 840 113549 }
{ 1 2 840 113549 }
В таблице 4.4.10.2.4 представлены некоторые объектные иден-
тификаторы и их значения.
Таблица 4.4.10.2.4.
Некоторые объектные идентификаторы и их значения
Величина объектного идентификатора Назначение
{12} Члены ISO
{ 1 2 840 } US (ANSI)
{ 1 2840 113549} RSA Data Security, Inc.
{ 1 2840 113549 } RSA Data Security, Inc. PKCS (Public Key Cryptography Standard)
{25} Служба каталогов (X.500) _
{ 258 } Служба каталогов - алгоритмы _
BER-кодирование OBJECT IDENTIFIER является всегда прими-
тивным. Октеты содержимого представляют собой объединение п-1
строки октетов, где п число компонент объектного идентификатора-
Каждая октетная строка несет в себе целое число по модулю 128
(старшая часть первая). 8-ой бит каждого октета, кроме последнего,
Сети передачи данных. Метод доступа
673
равен 1. Пусть valuep valuen целые значения компонентов объек-
тного идентификатора. Тогда п-1 субидентификаторов, из которых
формируется октетная строка, будут иметь следующий вид.
1. Первый субидентификатор равен lvalue t + value 2. (значение
valuet лежит в пределах 0-2 включительно, a value2 в интервале 0-39,
когда valuet равна 0 или 1.
2. i-ый субидентификатор равен value.+1 ; 2<i< п-1. *
Например, субидентификаторы объектного идентификатора RSA
Data Security, Inc. равны 42 = 40х 1 + 2, 840, 113549 и 1. В шест-
надцатеричном представлении BER-код этого объектного иденти-
фикатора имеет вид:
06 07 2А 86 48 86 F7 0D 01
DER-кодирование в данном случае совпадает с BER.
Строки октетов
Тип OCTET STRING служит для представления произвольных
последовательностей октетов. Значение OCTET STRING может иметь
любую длину, включая нуль. OCTET STRING используется для пред-
ставления сообщений, включая зашифрованные, а также для типа
PBEParameter. Нотация типа OCTET STRING имеет формат.
OCTET STRING [SIZE ({size | size,..size,})]
где size, size} u size2 опционные ограничения размера. В форме OCTET
STRING SIZE(size) строка октетов должна иметь size октетов.
В формате OCTET STRING SIZE(st^e/ .. size2) строка должна содер-
жать число октетов между sizej и size2. Например, тип PBEParameter
имеет компоненту типа OCTET STRING:
PBEParameter ::= SEQUENCE {
salt OCTET STRING SIZE (8),
iterationCount INTEGER}
Здесь размер компоненты salt всегда равен 8 октетам. BER-
кодирование типа OCTET STRING может быть примитивным или
конструктивным. При примитивном кодировании октеты содер-
жимого несут в себе октеты строки с первого по последний. При
конструктивном кодировании содержимое октетов представляет
собой последовательное объединение субстрок значения OCTET
STRING. Например, BER-код значения OCTET STRING 01 23 45
67 89 АВ CD EF может иметь один из следующих видов, в зависи-
22 Зак. Na 3430 Семенов
674
Гпава 4
мости от формата октетов длины и вида кодирования (примитив-
ное /конструктивное).
04 08 01 23 45 67 89 АВ CD EF DER-кодирование Длинный формат октетов длины Конструктивное кодирование
04 81 08 01 24 ОС 23 45 67 89 АВ CD EF
04 04 01 23 45 67 «01 23 45 67»+«89 АВ CD EF»
04 04 89 АВ CD EF
Строки печатных символов
Тип PrintableString предназначен для описания произвольных
последовательностей печатных символов из набора:
A, B,...,Z
a,b,...,z
0,1,...,9
(пробел) ‘ ()+, — ./: = ?
Этот тип используется для представления атрибутов имен
(Х.520). Нотация типа PrintableString имеет вид:
PrintableString
BER-кодирование значения PrintableString может быть прими-
тивным или конструктивным. При примитивном кодировании пе-
чатных символов байты содержимого несут в себе строки октетов
печатных ASCII-кодов. При конструктивном кодировании содержи-
мое октетов представляет собой последовательное объединение суб-
строк. Например, BER-код значения PrintableString «Test User 1»
может быть представлено одним из ниже приведенных способов.
13 0В 54 65 73 74 20 55 73 65 72 20 31 DER-кодирование
13 81 0В 54 65 73 74 20 55 73 65 72 20 31 Длинная форма
октетов длины
33 0F Конструктивная
форма,
13 05 54 65 73 74 20 «Test» + «User 1»
13 06 55 73 65 72 20 31
Сети передачи данных. Метод доступа
675
Тип SEQUENCE
Тип SEQUENCE обозначает упорядоченную последовательность
одного или более типов. Нотация типа SEQUENCE имеет вид:
SEQUENCE {
[identifier t] Typet [{OPTIONAL | DEFAULT valuet}],
[identifier J Type* [{OPTIONAL | DEFAULT value*}],
где identifiert,identifier* являются опционными идентификатора-
ми компонентов, Typet , Type* — типы компонентов, a valuej
value* опционные значения компонентов по умолчанию. Квалифика-
тор OPTIONAL указывает на то, что значения компонентов являются
опционными. Квалификатор DEFAULT говорит о том, что величина
компонента является опционной и ей присваивается определенное
значение, если компонент отсутствует. Например, тип Validity [Х.509]
относится к типу SEQUENCE и имеет два компонента'.
Validity SEQUENCE {
start UTCTime,
end UTCTime}
Здесь start и end являются идентификаторами компонент, а ти-
пом компонент служит UTCTime. BER-кодирование значения
SEQUENCE является всегда конструктивным. Октеты содержимого
представляют последовательное объединение BER-кодов значений
компонентов последовательности.
Тип SEQUENCE OF
Тип SEQUENCE OF обозначает упорядоченную последователь-
ность из нуля или более компонентов данного типа, используется
для имен в Х.501. Нотация SEQUENCE OF имеет вид:
SEQUENCE OF Type
Так например, тип RNDSequence состоит из нуля или более ком-
понент типа RelativeDistinguishedName.
RNDSequence ::= SEQUENCE OF RelativeDistinguishedName
BER-кодирование SEQUENCE OF является всегда конструктив-
ным. Октеты содержимого представляют собой объединение BER-
кодов значений элементов последовательности в порядке их распо-
ложения. DER-кодирование имеет тот же формат.
22*
676
Гпава 4
Тип SET
Тип SET представляет собой неупорядоченное объединение из
одного или более типов. Нотация типа SET имеет вид.
SET {
[identifier Д Typet Typet [{OPTIONAL | DEFAULT valued
[identifier J Type* [{OPTIONAL | DEFAULT value*}],
где identifier Jf identifier* являются опционными идентификато-
рами компонентов, Typet , ..., Type* — типы компонентов, a value t
,..., value* опционные значения компонентов по умолчанию. Квали-
фикатор OPTIONAL указывает на то, что значения компонентов
являются опционными. Квалификатор DEFAULT говорит о том, что
величина компонента является опционной и ей присваивается оп-
ределенное значение, если компонент отсутствует.
BER-кодирование для типа SET является всегда конструктив-
ным. Октеты содержимого представляют последовательное объеди-
нение BER-кодов значений компонентов набора.
Тип SET OF
Тип SET OF представляет неупорядоченный набор, состоящий из
нуля или более компонентов заданного типа и предназначенный
для атрибутов PKCS (Public-Key Cryptography Standard) и имен
Х.501. Нотация типа SET OF имеет вид:
SET OF Type
где Type - тип. Так тип RelativeDistinguishedName состоит из нуля
или более компонентов типа AttributeValueAssertion.
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
BER-кодирование типа SET OF является всегда конструктив-
ным. Октеты содержимого представляют собой объединение BER-
кодов величин компонентов в порядке их исходного расположения.
DER-кодирование также является всегда конструктивным, октеты
содержимого представляются, как и в случае BER-кодировки. Но
компоненты лексикографически упорядочиваются.
Тип UTCTime
Тип UTCTime служит для обозначения универсального местно-
го времени с привязкой по Гринвичу (GMT). Значение UTCTime
характеризует местное время с точностью минут или секунд и вре-
Сети передачи данных. Метод доступа
677
менной сдвиг по отношению к GMT. Оно может иметь следующие
формы:
YYMMDDhhmmZ
YYMMDDhhmm+hh“mm“
YYMMDDhhmm-hh“mm“
YYMMDDhhmmssZ
YYMMDDhhmmss+ hh“mm“
YYMMDDhhmmss- hh“mm“
где
YY младшие две цифры года
ММ код месяца (01 - 12)
DD код дня (01 - 31)
hh код часа (00 - 23)
пли код минут (00 - 59)
ss код секунд (00 - 59)
Z означает местное время по Гринвичу, “+” указывает на то,
что местное время отстает от GMT, а указывает на то,
что местное время опережает GMT.
hh“ абсолютное значение смещения по отношению к GMT в часах
mm“ абсолютное смещение по отношению к GMT в минутах.
UTCTime используется для определения типа Validity [Х.509].
Нотация типа UTCTime имеет вид.
UTCTime
BER-кодирование значения UTCTime может быть примитивным
или конструктивным. При примитивном кодировании октеты пред-
ставляют собой символы строки в виде ASCII-кодов. При конструк-
тивном кодировании октеты образуют объединение BER-кодов пос-
ледовательных субстрок. В качестве примера рассмотрим варианты
представления времени 4:45:40 после полудня 6 мая 1991 года
(Pacific Daylight Time) в виде величины UTCTime.
«910506164540-0700»
«910506234540Z»
Это представление эквивалентно следующим BER-кодам:
17 0D 39 31 30 35 30 36 32 33 34 35 34 30 5А
17 11 39 31 30 35 30 36 31 36 34 35 34 30 2D 30 37 30 30
678
Гпава 4
DER-кодирование типа UTCTime всегда является примитивным.
Ниже приводится пример ASN.1 нотации имен типа Х.501.
Name ::= CHOICE { RNDSequence }
RNDSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET OF Attribute Value Assertion
Attribute Value Assertion SEQUENCE {AttributeType,
AttributeValue}
AttributeType OBJECT IDENTIFIER
AttributeValue ::= ANY
Тип Name идентифицирует объект в каталоге Х.500. Name име-
ет тип CHOICE с одной альтернативой RNDSequence. Тип
RNDSequence указывает проход по дереву каталогов Х.500, начиная
с корневой части. RNDSequence имеет тип SEQUENCE OF, состоя-
щий из нуля или более компонентов RelativeDistinguishedName.
Тип RelativeDistinguishedName присваивает уникальное имя объекту
на дереве каталога. RelativeDistinguishedName имеет тип SET OF, со-
стоящий из нуля или более компонентов At tribute Value Assertion. Тип
Attribute Value Assertion присваивает значение атрибуту имени (напри-
мер, определяющее принадлежность к стране). AttributeValueAssertion
имеет тип SEQUENCE, состоящий из двух компонентов AttributeType и
AttributeValue. AttributeType идентифицирует атрибут с помощью объек-
тного идентификатора. AttributeValue присваивает значение атрибуту.
Ниже предлагается пример DER-кодирования типа Name. В качестве
имени использовано RSA Data Security, Inc. NOTARY (отдел Internet
Privacy Enhanced Mail).
(root)
countryName= «US»
organizationName = «RSA Data Security, Inc.»
organizationalUnitName = «NOTARY»
Каждый уровень соответствует одному значению
RelativeDistinguishedName, в выбранном случае они имеют только
одно значение AttributeValueAssertion. Значение AttributeType поме-
щается до знака равенства, a AttributeValue (строка печатных сим-
волов с заданным типом атрибута) — после знака равенства.
Сети передачи данных. Метод доступа
679
Тип атрибута
DER-кодирование трех значений AttributeType согласно прими-
тивному методу с заданной длиной дает следующие строки октетов.
06 03 55 04 06 countryName
06 03 55 04 0A organizationName
06 03 55 04 0В organizationalUnitName
Здесь countryName, organizationName и organizationalUnitName
являются типами атрибутов Х.520, которые имеют следующие оп-
ределения.
AttributeType OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4 }
countryName OBJECT IDENTIFIER ::= { AttributeType 6 }
organizationName OBJECT IDENTIFIER ::= { AttributeType 10 }
organizationalUnitName OBJECT IDENTIFIER ::= {AttributeType 11}
Октеты идентификатора имеют формат с меткой, так как метка
для OBJECT IDENTIFIER равна 6. Биты 8 и 7 равны 0, указывая
на универсальный класс, бит 6 также равен 0, что говорит о прими-
тивном методе кодирования. Октеты длины ориентированы на ко-
роткую форму представления. Октеты содержимого представляют
собой объединения трех-октетных строк, полученных из субиденти-
фикаторов: 85 = 40x2 + 5; 4 и 6, 10 или 11.
Значение атрибута
DER-кодирование трех значений Attribute Value в соответствии с
примитивным методом при заданной длине дает следующие строки:
13 02 55 53 «US»
13 17 52 53 41 20 «RSA
44 61 74 61 20 Data
53 65 63 75 72 69 74 79 2С 20 Security,
49 6Е 63 2Е Inc.»
13 06 4Е 4F 54 41 52 59 “NOTARY”
Метка равна 19 (PrintableString), биты 8 и 7 равны 0, указывая
на универсальный класс, бит 6 также равен 0, отмечая примитив-
ный метод кодирования. Октеты длины имеют «короткий» формат,
а октеты содержимого являются ASCII-представлением значения
атрибута.
680
Гпава 4
Атрибут Value Assertion
DER-кодирование трех значений AttributeValueAssertion в соответ-
ствии с конструктивным методом дает следующие строки октетов.
30 09
06 03 55 04 06
13 02 55 53 countryName == «US»
30 IE
06 03 55 04 0А
13 17 52 53 41 20
44 61 74 61 20
53 65 63 75 72 69 74 79 2С 20
49 6Е 63 2Е organizationName = «RSA Data Security, Inc.»
30 0D
06 03 55 04 0B
13 06 4E 4F 54 41 52 59 organizationalUnitName - «NOTARY»
Октеты идентификатора используют короткий формат (low-octet
form), так как для SET OF метка равна 17. Биты 8 и 7 равны 0
(универсальный класс), а бит 6 равен 1 (конструктивное кодирова-
ние). Октеты длины следуют «короткому» формату, а октеты содер-
жимого представляют собой объединение DER-кодов компонент
attributeType и attributeValue.
RelativeDistinguishedName
DER-кодирование трех значений RelativeDistinguishedName, вы-
полняемое согласно конструктивному методу, дает следующие стро-
ки октетов.
♦
31 ов
30 09 ... 55 53
31 20
30 1Е ... 63 2Е
31 0F
30 0D ... 52 59
Октеты идентификатора используют короткий формат (low-octet
form), так как для SET OF метка равна 17. Биты 8 и 7 равны 0
(универсальный класс), а бит 6 равен 1 (конструктивное кодирова-
ние). Октеты длины следуют «короткому» формату, а октеты содер-
жимого представляют собой объединение DER-кодов компонент
AttributeValueAssertion.
Сети передачи данных. Метод доступа
681
RDNSequence
DER-кодирование значений RDNSequence, выполняемое соглас-
но конструктивному методу при заданной длине, дает следующие
строки октетов.
30 40
31 0В ... 55 53
31 20 ... 63 2Е
31 0F ... 52 59
Октеты идентификатора используют короткий формат (low-octet
form), так как для SEQUENCE OF метка равна 16. Биты 8 и 7
равны 0 (универсальный класс), а бит 6 равен 1 (конструктивное
кодирование). Октеты длины следуют «короткому» формату, а окте-
ты содержимого представляют собой объединение DER-кодов трех
компонент RelativeDistinguishedName в порядке их следования.
Name
DER-кодирование значений Name выполняется аналогично зна-
чениям RDNSequence и выдает следующие результаты. 1
30 40
31 0В
30 09
06 03 55 04 06
13 02 55 53
31 20
30 1Е
06 03 55 04 0А
13 17 52 53 41 20 44 61 74 61 20 53 65 63 75 72 69
74 79 2С 20 49 6Е 63 2Е
31 0F
30 0D
06 03 55 04 0В
13 06 4Е 4F 54 41 52 59
4.4.74. SMTP протокол
Главной целью протокола Simple Mail Transfer Protocol (SMTP,
RFC-821, -822) служит надежная и эффективная доставка элект-
ронных почтовых сообщений. SMTP является довольно независи-
мой субсистемой и требует только надежного канала связи. Средой
Для SMTP может служить отдельная локальная сеть, система сетей
или весь Интернет.
682
Гпава 4
SMTP базируется на следующей модели коммуникаций: в ответ
на запрос пользователя почтовая программа-отправитель устанав-
ливает двухстороннюю связь с программой-приемником (TCP, порт
25). Получателем может быть оконечный или промежуточный ад-
ресат. SMTP-команды генерируются отправителем и посылаются
получателю. На каждую команду должен быть отправлен и полу-
чен отклик.
Когда канал организован, отправитель посылает команду MAIL,
идентифицирую себя. Если получатель готов к приему сообщения,
он посылает положительное подтверждение. Далее отправитель по-
сылает команду RCPT, идентифицируя получателя почтового сооб-
щения. Если получатель может принять сообщение для оконечного
адресата, он выдает снова положительное подтверждение (схема фор-
мирования откликов помещена в приложении 10.14). В противном
случае он отвергает получение сообщения для данного адресата, но
не вообще почтовой посылки. Взаимодействие с почтовым серве-
ром возможно и в диалоговом режиме, например:
tn dxmint.cern.ch 25 (команда telnet с использованием порта 25)
220 dxmint.cern.ch Sendmail ready at Sun, 9 Jul 1995 11:13:57 +0200
(связь установлена, код отклика 220 является положительным)
ehlo dxmint.cern.ch — (поддерживает ли сервер расширение MIME?)
500 Command unrecognized — (не поддерживает)
helo crnvma.cern.ch — (команда выхода на конкретный сервер)
250 dxmint.cern.ch Hello crnvma.cern.ch, pleased to meet you (от-
клик 250 также является положительным)
MAIL From:<> (так как на моей PC нет резидентной почтовой
программы, я не указываю обратного адреса)
250 <>... Sender ok — (команда прошла успешно)
RCPT То: ysemenov@cernvm.cern.ch — (указываем адрес места
назначения)
250<ysemenov@cernvm.cern.ch>... Recipient ok
DATA — (начало ввода текста сообщения)
Nu i-nu... — (текст сообщения)
. — (знак конца сообщения)
quit — (прерывание или завершение процедуры)
221 dxmint.cern.ch closing connection — (сообщение об успеш-
ном завершении процедуры)
Сети передачи данных. Метод доступа
683
Почтовое сообщение отправлено без использования доступа к
локальной почтовой программе (mail на SUN, например). Следует
отметить, что работа через порт 25 в данном случае открывает бога-
тые возможности для хакеров. Вообще умелый программист может
многого достичь, используя номера портов. Здесь есть над чем пора-
ботать людям, ответственным за безопасность сетей. Аналогично,
не имея авторизации, можно выявить клиентов почтового сервера,
используя команду vrfy:
tn ns.itep.ru 25
220 ns.itep.ru 5.67a8/IDA-1.5 Sendmail is ready at Sat, 29 Jul
995 13:53:03
vrfy Bobyshev
250 Andrey Bobyshev <bobyshev>
и т.д.
QUIT
SMTP-отправитель и SMTP-получатель могут вести диалог с не-
сколькими оконечными пользователями (рис. 4.4.14.1). Любое по-
чтовое сообщение завершается специальной последовательностью
символов. Если получатель успешно завершил прием и обработку
почтового сообщения, он посылает положительное подтверждение.
SMTP обеспечивает передачу почтового сообщения непосредствен-
но конечному получателю, когда они соединены непосредственно. В
противном случае пересылка может выполняться через одного или
более промежуточных «почтовых станций».
Для решения поставленной задачи SMTP-сервер должен знать
имя конечного получателя и название почтового ящика места на-
значения. Аргументом команды MAIL является адрес отправителя
(обратный адрес). Аргументом команды RCPT служит адрес конеч-
ного получателя. Обратный адрес используется для посылки сооб-
щения в случае ошибки.
Запрос--------► ◄----------Отклик
Рис. 4.4.14.1
Схема взаимодействия различных частей почтовой системы
684 . Глава 4 t
-----------------------------------------------------------f
Все отклики имеют цифровые коды. Команды, отклики и имена |
ЭВМ не чувствительны к тому, строчные или прописные символы ?
использованы при их написании. Это не всегда справедливо при
написании имен и адресов получателя.
Многие почтовые системы работают только с ASCII-символа-
ми. Если транспортный канал работает с октетами, 7-битные коды
будут дополнены нулевым восьмым битом. Именно здесь корени-
лась проблема пересылки почтовых сообщений на русском языке ''
несколько лет назад (русский алфавит требует 8-битового пред-
ставления).
Как уже было сказано, процедура отправки почтового сообще-
ния начинается с посылки команды MAIL, которая имеет формат:
MAIL <SP> FROM:<reverse-path> <CRLF>,
где <SP> - пробел, <CRLF> - комбинация кодов возврата каретки и ?
перехода на новую строку, a <reverse-path> - обратный путь.
Эта команда сообщает SMTP-получателю, что стартует новая
процедура и следует сбросить в исходное состояние все статусные
таблицы, буферы и т.д. Если команда прошла, получатель реагирует
откликом: 250 ОК.
Аргумент <reverse-path> может содержать не только адрес по-
чтового ящика, <reverse-path> в общем случае явдяется списком J
адресов ЭВМ-серверов, через которые пришло данное сообщение, вклю-
чая, разумеется, и адрес почтового ящика отправителя. Первым в
списке <reverse-path> стоит адрес ЭВМ-отправителя. ;
После прохождения команды MAIL посылается команда RCPT:
RCPT <SP> TO:<forward-path> <CRLF>
Эта команда указывает адрес конечного получателя (<forward- $
path>). При благополучном прохождении команды получатель по-
сылает код-отклик 250 ОК, и запоминает полученный адрес. Если
получатель неизвестен, SMTP-сервер пошлет отклик 550 Failure reply, г
Команда RCPT может повторяться сколько угодно раз, если адресат
не один.
Аргумент <forward-path> может содержать не только адрес по-
чтового ящика, но и маршрутный список ЭВМ по дороге к нему.
Первым в этом списке должно стоять имя ЭВМ, получившей дан- :
ную команду. По завершении этого этапа посылается собственно
сообщение:
DATA <CRLF>
Сети передачи данных. Метод доступа 685
При правильном приеме этого сообщения SMTP-сервер реагиру-
ет посылкой отклика 354 Intermediate reply (промежуточный от-
клик), и рассматривает все последующие строки в качестве почтово-
го текста. При получении кода конца текста отправляется отклик:
250 ОК.
Признаком конца почтового сообщения является точка в са-
мом начале строки, за которой следует <CRLF>. Пользователям
почтовых UNIX-систем это уже известно.
В некоторых случаях адрес места назначения может содержать
ошибку, но получатель знает правильный адрес. Тогда возможны
два варианта отклика:
1. 251 User not local; will forward to <forward-path>
Это означает, что получатель берет на себя ответственность за
доставку сообщения. Это случается, когда адресат, например, мигри-
ровал в другую субсеть в пределах зоны действия данного почтового
сервера.
2. 551 User not local; please try <forward-path>
Получатель знает правильный адрес и предлагает отправителю
переадресовать сообщение по адресу <forward-path>.
SMTP имеет команды для проверки корректности имени адреса-
та (VRFY) и расширения списка адресов (EXPN). Обе команды в
качестве аргументов используют строки символов (в некоторых реа-
лизациях эти две команды по своей функции идентичны). Для ко-
манды VRFY параметром является имя пользователя, а отклик мо-
жет содержать его полное имя и адрес его почтового ящика.
Реакция на команду VRFY зависит от аргумента. Так если сре-
ди клиентов почтового сервера имеется два пользователя с именем
Ivanov, откликом на команду «VRFY Ivanov» будет «553 User
ambiguous». В общем случае команда VRFY Ivanov может полу-
чить в качестве откликов:
250 Vasja Ivanov Ivanov@cl.itep.ru
или:
251 User not local; will forward to Ivanov@cl.itep.ru
или:
550 String does not match anything ( данная строка ничему
не соответствует).
или:
551 User not local; please try Vasja@ns.itep.ru
или:
VRFY Chtozachertovchina
553 User ambiguous (несуществующее имя)
686
Гпава 4
В случае пропечатки списка адресов отклик занимает несколько
строк, например:
EXPN Example-People
250-Juri Semenov Semenov@ns.itep.ru
250-Alexey Sher Sher@suncom.itep.ru
250-Andrey Bobyshev Bobyshev@ns.itep.ru2
50-Igor Gursky Gursky@ns.itep.ru
В некоторых системах аргументом команды EXPN может быть
имя файла, содержащего список почтовых адресов.
Основной задачей почты служит доставка сообщений в почто-
вый ящик адресата. Сходную форму услуги оказывают некоторые
ЭВМ, доставляя сообщения на экран терминала (в рамках SMTP).
Для посылки сообщений на экран терминала адресата предусмотре-
но три команды:
1. SEND <SP> FROM:<reverse-path> <CRLF>
Команда SEND требует, чтобы почтовое сообщение было достав-
лено на терминал. Если терминал адресата не активен в данный
момент, то откликом на команду RCPT будет код 450.
2. SOML <SP> FROM:<reverse-path> <CRLF>
Команда Send Or MaiL (SOML) пересылает сообщение на экран
адресата, если он активен, в противном случае сообщение будет уло-
жено в его почтовый ящик. ,
3. SAML <SP> FROM:<reverse-path> <CRLF>
Команда Send And MaiL (SAML) предполагает доставку сообще-
ние, на экран терминала адресата и занесение в его почтовый ящик.
Для открытия и закрытия коммуникационного канала исполь-
зуются команды:
HELO <SP> <domain> <CRLF>, где <domain> — имя запраши-
вающего домена.
QUIT <CRLF>
Выражение <forward-path> может быть маршрутом, имеющим
вид «@ONE,@TWO:VANJA@THREE», где ONE, TWO и THREE - имена
ЭВМ. Что подчеркивает различие между адресом и маршрутом. Кон-
цептуально элементы из <forward-path> переносятся в <reverse-path>
при пересылке сообщений от одного SMTP-сервера к другому.
Если SMTP-сервер обнаружит, что доставка сообщения по адресу
<forward-path> невозможна, тогда он формирует сообщение о «не дос-
тавленном письме», используя <reverse-path>. Следует также помнить,
что ни прямой ни обратный адреса-маршруты, вообще говоря, могут не
иметь ничего общего с текстом заголовка почтового сообщения.
Сети передачи данных. Метод доступа
687
При определенных условиях и ошибках в задании прямых и
обратных адресов-маршрутов возможно зацикливание сообщений
об этих ошибках. Чтобы заведомо избежать этого можно выдавать
команду MAIL с нулевым обратным маршрутом:
MAIL FROM:<>
Если вы или ваша программа не указали обратного адреса, не
следует думать, что это помешает работе почтовой программы и она
не будет знать, куда посылать отклики. Ваш обратный IP-адрес
указан в каждом пакете, посылаемом адресату!
Некоторые другие команды, используемые в SMTP:
Команда TURN используется для того, чтобы поменять местами
функции программ, взаимодействовавших по телекоммуникацион-
ному каналу. Программа-отправитель становится получателем (после
того как она выдаст команду TURN и получит отклик 250), а про-
грамма-получатель - отправителем. Если программа не хочет или
не может поменять свою функцию, она пошлет отклик 502.
Команда RESET (RSET) прерывает текущую процедуру отправ-
ки почтового сообщения. Все буферы и таблицы очищаются, полу-
чатель должен послать отклик 250 ОК.
Команда HELP вынуждает получателя послать справочную ин-
формацию отправителю команды HELP. Команда может содержать
аргумент (имя команды). Команда не изменяет состояния таблиц
или буферов.
Команда NOOP не Оказывает влияния на какие-либо парамет-
ры или результаты предшествующих команд, она только вынужда-
ет получателя послать отклик 250 ОК. Может использоваться для
проверки работоспособности ТСР-канала.
Допустимо написание команд строчными или прописными сим-
волами, например: MAIL, Mail, mail, Mall или mAIl.
Для того чтобы программа SMTP-сервера была работоспособна,
она должна понимать следующий минимум команд: HELO, MAIL,
RCPT, DATA, RSET, NOOP, QUIT.
Предельная длина имени пользователя или домена равна 64
символам. Максимальная длина <reverse-path> или <forward-path>
составляет 256 символов, включая разделители (пробелы, точки, за-
пятые и пр.). Командная строка не должна быть длиннее 512 сим-
волов. Максимальный размер строки отклика не должен превы-
шать, включая его код и <CRLF>, 512 символов. Максимальная
Длина текстовой строки составляет, включая <CRLF>, 1000 симво-
лов. Предельно допустимое число адресатов равно 100, последнее
полезно помнить, если вы храните этот список в файле.
688
Гпава 4
4.4.14.2. Почтовый протокол POP3
В некоторых небольших узлах Интернет бывает непрактично
поддерживать систему передачи сообщений (MTS — Message
Transport System). Рабочая станция может не иметь достаточных
ресурсов для обеспечения непрерывной работы SMTP-сервера [RFC-
821]. Для «домашних ЭВМ» слишком дорого поддерживать связь с
Интернет круглые сутки.
Но доступ к электронной почте необходим как для таких ма-
лых узлов, так и индивидуальных ЭВМ. Для решения этой пробле-
мы разработан протокол POP3 (Post Office Protocol — Version 3,
STD: 53. M. Rose, RFC-1939). Этот протокол обеспечивает доступ
узла к базовому почтовому серверу.
POP3 не ставит целью предоставление широкого списка мани-
пуляций с почтой, он лишь получает и стирает почтовые сообще-
ния. Более продвинутый и сложный протокол IMAP4 обсуждается
в RFC-2060 (порт 143).
В дальнейшем ЭВМ-клиентом будет называться машина, пользу-
ющаяся услугами POP3, а ЭВМ-сервером - сторона, предлагающая
услуги POP3.
Когда пользователь ЭВМ-клиента хочет послать сообщение, он
устанавливает SMTP связь с почтовым сервером непосредственно и
посылает все, что нужно через него. При этом ЭВМ РОРЗ-сервер не
обязательно является почтовым сервером.
В исходный момент ЭВМ РОРЗ-сервер прослушивает ТСР-порт
110. Если ЭВМ-клиент хочет воспользоваться услугами РОРЗ-сер-
вера, то устанавливает с ним TCP связь. По установлении связи
РОРЗ-сервер посылает клиенту уведомление (например, +ОК POP3
server ready) и сессия переходит в фазу авторизации (см. также
RFC-1734, -1957). После этого может производиться обмен коман-
дами и откликами.
Команды POP3 состоят из ключевых слов (3-4 символа), за ко-
торыми могут следовать аргументы. Каждая команда завершается
парой символов CRLF. Как ключевые слова, так и аргументы могут
содержать только печатаемые ASCII-символы. В качестве раздели-
теля используются символы пробела. Каждый аргумент может со-
держать до 40 символов.
Сигнал отклика в POP3 содержит индикатор состояния и клю-
чевое слово, за которым может следовать дополнительная информа-
ция. Отклик также завершается кодовой последовательностью CRLF.
Длина отклика не превышает 512 символов, включая CRLF. Суще-
ствует два индикатора состояния: положительный — «+ОК» и от-
Сети передачи данных. Метод доступа
689
рицательный «-ERR» (все символы прописные). Отклики на неко-
торые команды могут содержать несколько строк. В этом случае
последняя строка включает в себя код завершения 046 («.»), за
которым следует CRLF. На практике многострочные отклики для
исключения имитации завершаются последовательностью
CRLF.CRLF.
В процессе авторизации клиент должен представить себя серве-
ру, передав имя и пароль (возможен вариант посылки команды АРОР).
Если авторизация успешно завершена, сессия переходит в состояние
транзакции (TRANSACTION). При получении от клиента команды
QUIT сессия переходит в состояние UPDATE, при этом все ресурсы
освобождаются и TCP связь разрывается. На синтаксически
неузнанные и неверные команды, сервер реагирует, посылая отрица-
тельный индикатор состояния.
POP3 сервер может быть снабжен таймером пассивного состоя-
ния (10 мин.), который осуществляет автоматическое прерывание
сессии. Приход любой команды со стороны клиента сбрасывает этот
таймер в нуль.
Сервер нумерует все передаваемые сообщения из своего почто-
вого ящика и определяет их длину. Положительный отклик начи-
нается с +ОК, за ним следует пробел, номер сообщения, еще один
пробел и длина сообщения в октетах. Завершается отклик последо-
вательностью CRLF. Переданные сообщения удаляются из почтово-
го ящика сервера. Все сообщения, передаваемые во время сессии
POP3 должны следовать рекомендациям формата Интернет сооб-
щений [RFC822],
В состоянии транзакции клиент может посылать серверу пос-
ледовательность POP3 команд, на каждую из которых сервер дол-
жен послать отклик. Далее следует краткое описание команд, ис-
пользуемых в состоянии транзакция.
LIST [сообщение]
Аргументы: номер сообщения (опционно), который не может
относиться к сообщению, помеченному как удаленное. Команда мо-
жет быть выдана только в режиме TRANSACTION. При наличии
аргумента сервер выдает положительный отклик, содержащий ин-
формационную строку сообщения. Такая строка называется скэн-
листингом сообщения (scan listing), scan listing состоит из номера
сообщения, за которым следует пробел и число октетов в сообще-
нии. Сообщения, помеченные как удаленные, не пересылаются. При-
мером отрицательного отклика может служить: -ERR no such
Hiessage.
Примеры использования команды LIST:
690
Гпава 4
Клиент выдает команду: LIST
Сервер откликается: 4-ОК 2 messages (320 octets)
Сервер: 1 120
Сервер: 2 200
Сервер: .
Клиент: LIST 2
Сервер: 4-ОК 2 200
К: LIST 3
С: -ERR no such message, only 2 messages in maildrop
Здесь и далее символом К обозначается клиент, а символом С
— сервер.
Команда STAT — аргументов не использует, возможный отклик
4-ОК nn mm, где пп - номер сообщения, а тт - его длина в байтах.
Пример использования:
К: STAT
С: +ОК 2 320
Команда QUIT — аргументов не использует, возможный от-
клик 4-ОК.
Сервер POP3 удаляет все сообщения, помеченные как удаленные
из почтового ящика, посылает соответствующий отклик и разрыва-
ет TCP связь. Пример:
К: QUIT
С: 4-ОК dewey POP3 server signing off.
Команда RETR msg (msg - номер сообщения)
Если РОРЗ-сервер выдал положительный отклик, то за началь-
ным 4-ОК следует сообщение с номером, указанным в аргументе.
Отрицательный отклик имеет вид -ERR no such message.
Пример использования команды:
К: RETR 1
С: 4-ОК 120 octets
С: <РОРЗ сервер пересылает сообщение >
С: .
DELE msg (msg - номер сообщения)
Сервер POP3 помечает сообщение как удаленное. Любая ссылка
на это сообщение в будущем вызовет ошибку. При этом само сооб-
щение не удаляется пока сессия не войдет в режим UPDATE.
£ети передачи данных. Метод доступа
691
Пример использования команды:
К: DELE 1
С: +ОК message 1 deleted
К: DELE 2
С: -ERR message 2 already deleted
NOOP (не использует каких-либо аргументов). При реализации
этой команды сервер не делает ничего, лишь посылает положитель-
ный отклик.
RSET (не использует каких-либо аргументов)
Если какие-либо сообщения помечены как удаленные, сервер POP3
удаляет эту пометку и возвращает положительный отклик. Например:
К: RSET
С: +ОК maildrop has 2 messages (320 octets)
Если сессия завершается не по команде клиента, то перехода в
состояние UPDATE не производится, а сообщения не удаляются из
почтового ящика. Далее следует описание команд, используемых в
состоянии UPDATE.
Ряд команд не входят в перечень обязательных (являются оп-
ционными).
TOP msg п, где msg - номер сообщения, а и - число строк
(используется только в режиме TRANSACTION).
При положительном отклике на команду ТОР сервер посылает
заголовки сообщений и вслед за ними п строк их текста. Если п
больше числа строк в сообщении, посылается все сообщение.
UIDL [msg], где msg ~ номер сообщения является опционным
(Unique-ID Listing).
Если сервер выдаст положительный отклик, будет выдана стро-
ка, содержащая информацию о данном сообщении. Эта строка на-
зывается уникальным идентификатором сообщения («unique-id
listing»). При отсутствии аргумента аналогичная информация вы-
дается для каждого из сообщений в почтовом ящике. Уникальный
идентификатор сообщения состоит из 1-70 символов в диапазоне от
0x21 до 0х7Е. Сообщения в почтовом ящике должны характеризо-
ваться различными идентификаторами. Пример использования ко-
манды:
692
Гпава 4
К: UIDL
С: +0К
С: 1 whqtswOOOWBw418f9t5JxYwZ
С: 2 QhdPYR:00WBwlPh7x7
USER name, где name - характеризует почтовый ящик сервера.
Команда используется на фазе авторизации или после неудачно-
го завершения команд USER или PASS. При авторизации клиент
должен сначала послать команду USER и лишь после получения
положительного отклика команду PASS. Команда может вызвать
следующие отклики:
+ОК name is a valid mailbox — (для данного имени имеется
почтовый ящик)
-ERR never heard of mailbox name — (такой ящик отсутствует)
Примеры использования команды USER:
К: USER frated
С: -ERR sorry, no mailbox for frated here
K: USER mrose
С: +OK mrose is a real hoopy frood (на самом деле mrose имеет
имя hoopy frood)
PASS string (string - пароль для доступа к почтовому серверу)
Команда работает в режиме авторизации сразу после команды
USER. Когда клиент выдает команду PASS, сервер использует аргу-
менты команд USER и PASS для определения доступа клиента к
почтовому ящику. На команду PASS возможны следующие отклики:
+ОК maildrop locked and ready
-ERR invalid password
-ERR unable to lock maildrop
Пример диалога при использовании команды PASS:
К: USER mrose
С: +ОК mrose is a real hoopy frood
K: PASS secret
C: -ERR maildrop already locked
Сети передачи данных. Метод доступа
693
К: USER mrose
С: +ОК mrose is a real hoopy frood
К: PASS secret
С: +OK mrose’s maildrop has 2 messages (320 octets)
APOP name digest, где name - идентификатор почтового ящика,
a digest - дайджест сообщения - MD5 (RFC-1828). Команда ис-
пользуется только на стадии авторизации.
Обычно любая сессия начинается с обмена USER/PASS. Но так
как в некоторых случаях подключения к серверу POP3 может осу-
ществляться достаточно часто, возрастает риск перехвата пароля.
Альтернативным методом авторизации является использование
команды АРОР. Сервер, который поддерживает применение коман-
ды АРОР, добавляет временную метку в свое стартовое уведомление.
Синтаксис временной метки соответствует формату идентификато-
ров сообщений, описанному в [RFC822] и должны быть уникальны-
ми для всех заголовков уведомлений. Так для UNIX-приложений
синтаксис временной метки должен иметь вид:
<process-ID.clock@hostname>
где “process-ID” представляет собой десятичное значение PID про-
цесса, clock - десятичное показание системных часов, a hostname -
полное имя домена, где размещен сервер POP3.
Клиент POP3 фиксирует временную метку и выдает команду
АРОР. Параметр “паше” семантически идентичен параметру “паше”
команды USER. Параметр “digest” вычисляется с использованием
алгоритма MD5 [RFC1321] для строки, состоящей из временной
метки (включая угловые скобки) за которой следует строка пароля,
которая известна только клиенту и серверу. Параметр “digest” со-
держит 16 октетов, которые пересылаются в шестнадцатеричном
формате с использованием строчных ASCII символов. Сервер, полу-
чив команду АРОР, проверяет принятый дайджест и если он коррек-
тен, посылает положительный отклик клиенту. Сессия при этом
переходит в состояние транзакции. В противном случае посылает-
ся отрицательный отклик, а состояние сессии не изменяется. С це-
лью обеспечения безопасности для каждого конкретного пользова-
теля и сервера должен использоваться либо метод доступа USER/
PASS, либо АРОР, но не в коем случае оба метода попеременно.
Сервер перед закрытием канала по команде QUIT должен уда-
лить из почтового ящика все сообщения, которые были перенесены
с помощью команд RETR.
694
Гпава 4
Предполагается, что все сообщения, передаваемые в ходе сессии
POP3, имеют текстовый формат Интернет в соответствии с докумен-
том [RFC822].
4.4.14.3 Протокол Интернет для работы с сообщениями
IMAP 4.1
Протокол IMAP 4.1 (INTERNET MESSAGE ACCESS PROTOCOL
— VERSION 4revl, V.Crispin, RFC-2060, December 1996) базируется
на транспортном протоколе TCP и использует порт 143. Протокол
IMAP представляет собой альтернативу РОР-3. Также как и после-
дний он работает только с сообщениями и не требует каких-либо
пакетов со специальными заголовками.
1. Команды и отклики
Соединение IMAP 4.1 подразумевает установление связи между
клиентом и сервером. Клиент посылает серверу команды, сервер
клиенту данные и уведомления о статусе выполнения запроса. Все
сообщения, как клиента, так и сервера имеют форму строк, которые
завершаются последовательностью CRLF. Получатель (клиент или
сервер) воспринимает такую строку или последовательность окте-
тов известной длины, за которой следует строка.
1.1. Протокольный отправитель клиента и протокольный по-
лучатель сервера
Любая ^процедура начинается с команды клиента. Любая коман-
да клиента начинается с префикса-идентификатора (обычно корот-
кая буквенно-цифровая строка, например А0001, А0002 и т.д.), на-
зываемого меткой (tag). Для каждой команды клиент генерирует
свою метку. Имеется два случая, когда строка, посланная клиентом,
не представляет собой законченную команду. В первом — аргумент
команды снабжается кодом, определяющим число октетов в строке
(см. описание литеральных строк в разделе "Форматы данных").
Во втором - аргументы команды требуют отклика со стороны сер-
вера (см. описание команды AUTHENTICATE). В обоих вариантах
сервер посылает запрос продолжения команды, если он готов. Такой
отклик сервера начинается с символа "+".
Замечание: Если, вместо этого, сервер детектирует ошибку в ко-
манде, посылается отклик завершения BAD с меткой, требующей
игнорирования команды и предотвращения посылки клиентом ка-
ких-либо еще запросов.
Отправитель может послать отклик завершения и в случае некото-
рых других команд (если одновременно исполняется несколько ко-
Сети передачи данных. Метод доступа
695
манд) или если данные не имеют меток. В любом случае, ожидается
запрос продолжения, клиент предпринимает в ответ соответствующие
действия и читает следующий отклик сервера. Во всех вариантах кли-
ент должен завершить передачу команды, прежде чем послать новую.
Протокольный приемник IMAP 4.1 сервера читает строку ко-
манды, пришедшей от клиента, осуществляет ее разбор, выделяет ее
параметры и передает серверу данные. По завершении сервер посы-
лает соответствующий отклик.
1.2. Протокольный отправитель сервера и протокольный по-
лучатель клиента
Данные, передаваемые сервером клиенту, а также статусные от-
клики, которые не указывают на завершение команды, имеют пре-
фикс и называются непомеченными откликами.
Данные сервера могут быть посланы в ответ на команду клиен-
та или отправлены сервером по своей инициативе. Формат данных
не зависит от причины посылки.
Отклик указывает на успешное выполнение операции или на ее
неудачу. Отклик использует ту же метку, что и команда клиента,
запустившая процедуру. Таким образом, если осуществляется более
чем одна команда, метка сервера указывает на команду, вызвавшую
данный отклик. Имеется три вида отклика завершения сервера:
ОК (указывает на успешное выполнение), NO (отмечает неуспех)
или BAD (указывает на протокольную ошибку, например, не узнана
команда или зафиксирована синтаксическая ошибка).
Протокольный приемник клиента IMAP 4.1 читает строку от-
клика от сервера. Он должен предпринять действия, в соответствии
с первым символом метки или ”+”.
Клиент должен быть готов принять любой отклик сервера в
любое время. Это касается и не запрошенных данных, присланных
сервером. Данные сервера должны быть записаны так, чтобы кли-
ент мог их непосредственно использовать, не посылая серверу уточ-
няющих запросов.
Каждое сообщение имеет несколько связанных с ним атрибу-
тов. Эти атрибуты могут быть определены индивидуально или со-
вместно с другими атрибутами.
Доступ к сообщениям в IMAP 4.1 осуществляется с помощью
Уникального идентификатора или порядкового номера сообщения.
1.3. Атрибут сообщения UID
Каждому сообщению ставится в соответствие 32-битовый код,
который при использовании совместно с уникальным идентифика-
696
Гпава 4
тором образует 64-битовую последовательность, гарантирующую
однозначную идентификацию сообщения в почтовом ящике. Сооб-
щения, приходящие позднее имеют больший код UID, чем получен-
ные ранее.
В отличие от порядкового номера сообщения, уникальные иден-
тификаторы не образуют упорядоченной последовательности, но они
работают и за пределами текущей сессии. Это позволяет осуществ-
лять ссылки на сообщение в случае обрыва сессии [IMAP-DISC].
UID ассоциируется с почтовым ящиком и посылается в виде
кода UIDVALIDITY отклика (ОК) на фазе выбора почтового ящика.
Если UID из предыдущей сессии по какой-то причине не может
быть использован, UID должен быть инкрементирован.
Замечание: UID для данного почтового ящика должен всегда
изменяться монотонно. Если порядок записей изменен вне рамок
IMAP, необходимо перегенерировать UID для данного почтового
ящика, так как порядок старых значений UID в этом случае уже не
будет монотонным.
Еще одной причиной не сохранения UID может служить стира-
ние старого и создание нового почтового ящика с тем же именем.
Так как имя почтового ящика не изменилось, клиент может не
знать об этом и пытаться использовать старые UID. Хорошим
значением UID можно считать 32-битное представление даты и вре-
мени создания почтового ящика. Вполне приемлемо и значение 1,
если имеется гарантия, что это значение никогда не будет использо-
вано повторно, даже в случае стирания и создания нового почтового
ящика с тем же именем.
UID сообщения не должно изменяться в пределах сессии, его не
следует изменять и от сессии к сессии. Однако если невозможно
сохранить UID сообщения в последующей сессии, каждая следую-
щая сессия должна иметь новый уникальный код идентификатора,
который больше чем любой UID использованный ранее.
Атрибут порядкового номера сообщения
Этот атрибут определяет порядковый номер сообщения в почто-
вом ящике, начиная с 1. Последующее сообщение всегда имеет зна-
чение этого атрибута на 1 большее, чем у предшествующего.
Допускается изменение порядкового номера сообщения на про-
тяжении сессии. Например, когда сообщение удаляется из почтово-
го ящика, номера всех последующих сообщений изменяются. Ана-
логично, новому сообщению может быть присвоен номер удаленного <
сообщения. (
Номера сообщений могут использоваться при вычислениях, ка- £
сающихся указателей UID. Например, если сообщение 287 в почто-
Сети передачи данных. Метод доступа
697
вом ящике, содержащем 523 сообщения, имеет UID 12345, имеется
286 сообщений, имеющих меньшее значение UID и 236 сообщений с
большими UID.
1.4. Атрибут флагов сообщения
Этот атрибут представляет собой список из нуля или более имено-
ванных лексем, соотнесенный данному сообщению. Флаг устанавлива-
ется путем его добавления к этому списку и обнуляется путем его
удаления. Существует два типа флагов в IMAP 4.1. Флаг может быть
постоянным или действующим только на время данной сессии.
Системным флагом является флаг, чье имя определено в данной
спецификации. Всё системные флаги начинаются с символа ”\”.
Некоторые системные флаги (\Deleted и \Seen) имеют специальную *
семантику, заданную вне рамок данного документа. В настоящее
время определены следующие системные флаги:
\Seen Сообщение прочитано
\Answered На сообщение послан ответ
\Flagged Сообщение "помечено" как срочное, требующее особого
внимания
\Deleted Сообщение помечено как стертое для последующего
удаления посредством EXPUNGE
\Draft Сообщения не является законченным (помечено, как
проект).
\Recent Сообщение только что положено в почтовый ящик.
Эта сессия является первой, где фигурирует данное сообщение;
для последующих сессий это сообщение не будет иметь флага \Recent.
Флаг не может быть изменен клиентом.
Если невозможно определить, является ли эта сессия первой для
данного сообщения, его следует считать относящимся к текущей
сессии. Ключевое слово определяется реализацией сервера. Ключе-
вые слова не начинаются с символа ”\”. Серверы могут позволять
клиенту создавать новые ключевые слова в почтовом ящике. По-
стоянные флаги клиент может устанавливать для данного сообще-
ния или удалять на постоянной основе; таким образом, последую-
щая сессия может воспользоваться новыми значениями флагов.
Замечание*. Системный флаг \Recent имеет статус флага сессии.
Флаг \Recent не может использоваться в качестве аргумента коман-
ды STORE, и по этой причине не может быть изменен вообще.
Внутренняя дата и время сообщения на сервере не совпадает с
Датой и временем, которые указаны в заголовке [RFC-822], Это вре-
698
Гпава 4
мя и дата получения сообщения. В случае доставки сообщения по-
средством протокола [SMTP], это должна быть дата и время достав-
ки конечному адресату. В случае сообщений, доставленных коман- й
дой IMAP 4.1 COPY, это должна быть внутренняя дата и время
отправителя сообщения. В случае доставки сообщения командой ;
APPEND, это должны быть дата и время, заданные в описании ко-
манды APPEND.
Атрибут размера сообщения определяет число октетов в сообще- ;
нии (рассмотрен в документе, [RFC-822]). Атрибут структуры кон-
верта сообщения соответствует требованиям документа [RFC-822].
Атрибут структуры тела сообщения несет в себе информацию о струк-
туре сообщения в соответствии с регламентациям [М1МЕ-1МВ]. Кроме '
доставки текстового сообщения, как это описано в RFC-822, IMAP Т
4.1 позволяет осуществлять передачу части текста. Можно отдель- (
но доставить заголовок и тело сообщения или даже часть тела /
сообщения. ;
2. Состояние и диаграмма исполнения
Сервер IMAP 4.1 находится в одном из четырех состояний. £
Большинство команд допустимо только во вполне определенных |
состояниях. Если клиент пытается реализовать команду в непра- |
вильном состоянии, это рассматривается как протокольная ошиб- |
ка. В этом случае сервер откликнется командой BAD или NO в $
зависимости от реализации конкретной программы. |
В состоянии без аутентификации клиент должен предоставить |
имя и пароль, прежде чем станет доступно большинство команд» ;•
Переход в это состояние производится при установлении соедине- ;
ния, если только для данного соединения не была проведена предва- /
рительная аутентификация.
В состоянии аутентификации клиент идентифицирован и дол- \
жен выбрать почтовый ящик, прежде чем ему станут доступны ко- ;
манды для работы с сообщениями. Переход в это состояние проис-
ходит при установлении соединение с предварительной аутентифи-
нацией, когда выданы все необходимые идентификационные данные
или при ошибочном выборе почтового ящика.
В состояние выбора система попадает, когда успешно осуществ-
лен выбор почтового ящика. В состояние выхода система попадает
при прерывании соединения в результате запроса клиента или вслед-
ствие независимого решения сервера.
(1) Соединение без предварительной аутентификации (отклик ОК).
(2) Соединение с предварительной аутентификацией (отклик
PREAUTH).
Сети передачи данных. Метод доступа 699
Рис. 4.4.14.2.1. Схема состояний для протокола IMAP
(3) Соединение отвергнуто (отклик BYE).
(4) Успешное завершение команды LOGIN или AUTHENTICATE.
(5) Успешное завершение команды SELECT или EXAMINE.
(6) Выполнение команды CLOSE, неудачная реализация команд
SELECT или EXAMINE.
(7) Команда LOGOUT, закрытие сервера, или прерывание соединения.
3. Формат данных
IMAP 4.1 использует текстовые команды и отклики. Данные в
IMAP 4.1 могут иметь одну из следующих форм: атом, число, стро-
ка, список, заключенный в скобки или NIL.
Атом состоит из одного или более неспециализированных сим-
волов.
Число состоит из одной или более цифр и характеризует некото-
рое числовое значение.
Строка может иметь одну из двух форм: литерал или строка в
кавычках. Литеральная форма является основной формой строки.
Строка в кавычках является альтернативной формой, исключаю-
щей избыточность литеральной формы за счет ограничений, налага-
емых на символы, используемые в строке.
Литерал представляет собой нуль или более октетов (включая
CR и LF). Литерал начинается с октета, где хранится число симво-
лов. Этот октет заключается в фигурные скобки, за которыми следу-
ет последовательность CRLF. В случае передачи литералов от сервера
к клиенту за CRLF следуют непосредственно данные. При передаче
литералов от клиента серверу клиент должен подождать прихода
команды продолжения, прежде чем начать пересылку данных.
700
Гпава 4
Строка в кавычках представляет собой последовательность из
нуля или более 7-битовых символов за исключением CR и LF, начи-
нающуюся и завершающуюся двойной кавычкой (< >). Пустая
строка представляется как "" или как литерал {0}, за которым
следует последовательность CRLF.
Замечание: Даже если число октетов равно нулю, клиент, переда-
ющий литерал должен подождать прихода команды продолжения.
3.1. 8-битовые и двоичные строки
8-битовая текстовая и двоичная почта поддерживается посред-
ством шифрования [М1МЕ-1МВ]. Реализации IMAP 4.1 могут пере-
давать 8-битные или многооктетные символы в литералах, но дол-
жны это делать, только когда определен [CHARSET], Если даже
определена кодировка BINARY, незакодированные двоичные строки
не могут быть разрешены. "Двоичная строка" - это любая строка
из NUL символов. Реализации программ должны перекодировать
двоичные данные в текстовую форму, такую как BASE64, прежде
чем их пересылать. Строка с большим числом символов CTL мо-
жет рассматриваться как двоичная.
3.2. Список в скобках
Структуры данных представляются в виде списков, помещенных
в скобки, элементы списка разделяются пробелами. Такой список
может включать в себя другие "списки в скобках". Пустой список
выглядит как () - "список в скобках" с нулевым числом членов.
3.3. NIL
Специальный атом "NIL" представляет собой указание на от-
сутствие каких-то определенных данных типа строка или "список в
скобках". Его следует отличать от пустой строки "" или пустого
"списка в скобках" ().
4. Операционные соображения
4.1. Присвоение имени почтовому ящику
Интерпретация имен почтовых ящиков является-независимой
от конкретной программной реализации. Однако имя почтового
ящика INBOX является специальным именем, зарезервированным
для "первичного почтового ящика данного пользователя на дан-
ном сервере" (значение не зависит от использования строчных или
прописных букв). Почтовые ящики могут образовывать иерархи- ;
ческую структуру. Если желательно экспортировать иерархию имен |
Сетн передачи данных. Метод доступа
701
почтовых ящиков, имена почтовых ящиков должны быть упорядо-
чены по буквам слева направо.
4.2. Соглашение о пространстве имен почтовых ящиков
В соответствии с соглашением первый иерархический элемент
любого имени почтового ящика, который начинается с символа ”#”
указывает на ’’пространство имен” остальной части имени'. Напри-
мер, реализации, которые предлагают доступ к группам новостей
USENET могут использовать пространство имен ’’#news”, для того
чтобы отделить пространство имен групп новостей от имен других
почтовых ящиков. Таким образом, группа новостей comp.mail.misc
будет иметь имя почтового ящика ”#news.comp.mail.misc”, а имя
”comp.mail.misc” может относиться к другому объекту (напр., к по-
чтовому ящику пользователя).
4.3. Международное соглашение об именах почтовых ящиков
Согласно договоренности имена международных почтовых ящи-
ков специфицированы в соответствии модифицированной версией
кодировки UTF-7, описанной в [UTF-7]. Целью этих модификаций
было устранение следующих проблем, связанных с UTF-7:
1. UTF-7 использует символ ”+” для смещения; это вызывает
конфликт с обычным применением ’’+” в именах почтовых ящи-
ков, в частности в именах групп новостей USENET.
2. Кодировка UTF-7 базируется на BASE64, где используется
символ что вступает в конфликт с применением в качестве
популярного иерархического разделителя.
3. UTF-7 запрещает использование что противоречит при-
менению ”\” в качестве популярного разделителя.
4. UTF-7 запрещает использование это вступает в конфликт
с тем, что некоторые серверы рассматривают этот символ, как указа-
тель на базовый каталог (home).
5. UTF-7 допускает разнообразные формы представления одних
и тех же строк, в частности, печатные символы US-ASCII могут
использоваться в закодированной форме.
В модифицированном UTF-7 печатные символы US-ASCII за
исключением представляются в исходном виде, то есть, симво-
лами со значениями октетов 0x20-0x25 и 0х27-0х7е. Символ
(0x26) представляется в виде двух октетной последовательности
Все другие символы (значения октетов 0x00-0xlf, 0x7f-0xff,
и все уникодные 16-битовые октеты) представляются в модифици-
рованной кодировке BASE64, с дополнительными видоизменениями
из [UTF-7]. Модифицированная BASE64 не должна использоваться
702 Гпава 4
для представления любых печатных символов US-ASCII, которые
должны представлять самих себя.
Символ используется для перехода к модифицированной
кодировке BASE64, а для возврата назад к US-ASCII. Все
имена начинаются с US-ASCII, и должны завершаться US-ASCII
(то есть, имя, которое заканчивается 16-битовым уникодом, дол-
жно быть завершено символом ”-’’). Примером может служить
имя почтового ящика, в котором смешаны фрагменты текста на <
английском, японском и китайском языках: ~peter/mail/
&ZeVnLIqe-/&U,BTFw-.
4.4. Размер почтового ящика и актуализации состояния сообщений
В любое время сервер может послать данные, которые клиент не
запрашивал. Иногда, такое поведение системы является необходи-
мым. Например, агенты, внешние по отношению к серверу, могут
положить сообщения в почтовый ящик, изменить флаги сообщения
в почтовом ящике (например, одновременный доступ в почтовый
ящик нескольких агентов), или даже удалить сообщения из почто-
вого ящика. Сервер должен автоматически послать уведомление об
изменении размера почтового ящика, если такое изменение произош- )
ло в процессе выполнения команды. Сервер должен автоматически £
послать уведомление об изменении флагов сообщений, не требуя
соответствующего запроса клиента. Имеются специальные правила «
для оповещения клиента сервером об удалении сообщений, чтобы £
избежать ошибок синхронизации (смотри также описание >
EXPUNGE). Программа клиента должна своевременно фиксировать j
изменения размера почтового ящика. Она не должна полагаться на \
то, что любая команда после начального выбора почтового ящика \
возвращает значение его размера.
4.5. Отклик в случае, когда не исполняется никакой команды ?
Реализациям сервера разрешается посылать непомеченные от-
клики (за исключением EXPUNGE), если в это время не выполня-
ется ни одной команды. Реализации, которые посылают такие от-
клики, должны учитывать соображения управления трафиком. В
частности, они должны либо (1) проверить, что размер данных не
превосходит транспортные возможности, или (2) использовать не- '
блокирующую запись. , 4
4.6. Таймер автоматического отключения (Autologout) .
Если сервер имеет таймер выгрузки в случае длительной пассив- 5
ности, тогда такой таймер должен быть настроен на время, по край- ~
Сети передачи данных. Метод доступа
703
ней мере, 30 минут. Получения любой команды от клиента в течение
этого периода должно быть достаточно для сброса этого таймера.
4.7. Одновременное исполнение нескольких команд
Клиент может послать другую команду, не дожидаясь отклика
на предшествующую, сервер может начать обработку другой коман-
ды до завершения обработки текущей.
Исключение может составлять случаи, когда результат выполне-
ния одной команды зависит от выполнения других команд. Клиен-
ты не должны посылать несколько команд, не дожидаясь результа-
та, если возможна неопределенность из-за их взаимозависимости.
Если сервер детектирует возможную неопределенность, он должен
исполнить их последовательно в порядке их получения от клиента.
Наиболее очевидный пример неопределенности реализуется, на-
пример, когда последовательно выполняются команды FETCH для
флагов сообщения и STORE для тех же самых флагов.
Неочевидные неопределенности возникают с командами, которые
допускают немаркированный отклик EXPUNGE (команды отлич-
ные от FETCH, STORE и SEARCH), так как немаркированный от-
клик EXPUNGE может нарушить корректность порядковых номе-
ров сообщений для последующих команд. Это не представляет про-
блем для команд FETCH, STORE или SEARCH, так как серверам
запрещено посылать отклики EXPUNGE, когда исполняется одна
их этих команд. Следовательно, если клиент посылает любую ко-
манду, отличную от FETCH, STORE или SEARCH, он должен ждать
отклика, прежде чем посылать команду, содержащую номер сообще-
ния. Например, следующая последовательность команд (без ожида-
ния) является некорректной:
FETCH + NOOP + STORE
STORE + COPY + FETCH
COPY + COPY
CHECK + FETCH
Ниже представлены примеры последовательностей команд, не
требующих ожидания завершения предшествующей инструкции:
FETCH + STORE + SEARCH + CHECK
STORE + COPY + EXPUNGE
704
Гпава 4
5. Команды клиента
Ниже описаны команды IMAP 4.1. Команды рассматриваются с
учетом состояния, в котором они допустимы.
5.1. Команды клиента — любое состояние
Следующие команды могут использоваться в любом состоянии:
CAPABILITY, NOOP и LOGOUT.
5.1.1. Команда CAPABILITY
Аргументы: отсутствуют.
Отклики: Необходим немаркированный отклик: CAPABILITY.
Результат: ОК - успешное завершение команды;
BAD - команда неизвестна или неверный аргумент.
Команда CAPABILITY запрашивает перечень возможностей, под-
держиваемых сервером. Сервер должен послать один немаркирован-
ный отклик CAPABILITY с "IMAP 4.1" в списке возможностей,
прежде чем отправлять маркированный отклик ОК. Этот список не
зависит от состояния соединения или пользователя. Следовательно,
нет необходимости направлять команду CAPABILITY более одного
раза на соединение. Название возможности, которая начинается с
"AUTH=" указывает, что сервер поддерживает определенный меха-
низм аутентификации. Все такие имена по определению являются
частью данной спецификации. Например, аутентификационные воз-
можности для экспериментального аутентификатора "noaccess" мо-
гут быть описаны как "AUTH=XNOACCESS", а не "XAUTH=
NOACCESS" или "XAUTH=XNOACCESS".
Другие имена возможностей относятся к расширениям, новым
версиям или коррекциям данной спецификации.
Пример: С: abed CAPABILITY
S: * CAPABILITY IMAP 4.1 AUTH=KERBEROS_V4
S: abed OK CAPABILITY completed
5.1.2. Команда NOOP
Аргументы: отсутствуют.
Отклики: никакого специального отклика на эту команду не
требуется.
Результат: ОК - команда успешно завершена;
BAD - команда неизвестна или неверен аргумент;
Команда NOOP ничего не делает и всегда успешно завершается.
Сети передачи данных. Метод доступа
705
Так как любая команда может прислать немаркированные дан-
ные об изменении состояния, команда NOOP может использоваться,
как периодический запрос нового сообщения или информации об
изменении статуса в периоды пассивности. Команда NOOP может
также использоваться для сброса таймера прерывания сессии серве-
ром из-за отсутствия активности.
Пример: С: а002 NOOP
S: а002 OK NOOP completed
С: а047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed
5.1.3. Команда LOGOUT
Аргументы: отсутствуют.
Отклики: необходим немаркированный отклик BYE.
Результат: ОК - прерывание сессии завершено;
BAD - неизвестная команда или неверный аргумент.
Команда LOGOUT информирует сервер о том, что клиент преры-
вает соединение. Сервер должен послать немаркированный отклик
BYE, прежде чем отсылать маркированный отклик ОК, после чего
завершить разрыв соединения.
Пример: С: А023 LOGOUT
S: * BYE IMAP 4.1 Server logging out
S: A023 OK LOGOUT completed
(Сервер и клиент разорвали соединение)
5.2. Команды клиента в состоянии без аутентификации
В состоянии без аутентификации, команды AUTHENTICATE или
login устанавливают аутентификацию и переводят систему в со-
стояние с аутентификацией. Команда AUTHENTICATE предостав-
ляет общий механизм для целого ряда методов аутентификации,
среди которых команда LOGIN используется для традиционного ввода
имени и пароля в текстовом виде.
Различные реализации сервера могут позволять доступ без аутен-
тификации к некоторым почтовым ящикам. По договоренности в
этом случае команда LOGIN предполагает ввод имени "anonymous”.
23 Зак. Na 3430 Семенов
706
Гпава 4
Ввод пароля всегда обязателен. Требования на пароль определяют-
ся конкретной версией программной реализации.
По завершении аутентификации невозможно непосредственное
возвращение в состояние "без аутентификации". В дополнение к
универсальным командам (CAPABILITY, NOOP и LOGOUT), в со-
стоянии "без аутентификации" возможны команды: AUTHENTICATE
и LOGIN.
5.2.1. Команда AUTHENTICATE
Аргументы: имя механизма аутентификации.
Отклики: может быть запрошена дополнительная информация.
Результат ОК Аутентификация завершена, осуществлен переход
в состояние "аутентификация выполнена";
NO Ошибка аутентификации: неподдерживаемый
механизм аутентификации, параметры аутенти-
фикации отвергнуты;
BAD Неизвестная команда или неверный аргумент,
операция аутентификации прервана.
Команда AUTHENTICATE указывает серверу на механизм аутен-
тификации, как это описано в [IMAP-AUTH]. Если сервер поддер-
живает запрошенный механизм аутентификации, он выполняет об-
мен согласно аутентификационному протоколу и идентифицирует
клиента. Он может также согласовать опционный механизм защи-
ты для последующих протоколов взаимодействия. Если запрошен-
ный механизм аутентификации не поддерживается, сервер должен
отвергнуть команду AUTHENTICATE путем посылки маркирован-
ного отклика NO. х
Протокол аутентификационного обмена состоит из последова-
тельности запросов сервера и соответствующих ответов клиента.
Запрос сервера состоит из отклика-запроса продолжения с симво-
лом ”+", за которым следует строка кодов BASE64. Ответ клиента
состоит из строки, содержащей коды BASE64. Если клиент хочет
аннулировать аутентификационный обмен, он выдает строку, содер-
жащую только Если сервер получает такой ответ, он должен
отклонить команду AUTHENTICATE, послав маркированный от-
клик BAD.
Механизм защиты обеспечивает целостность и конфиденциаль-
ность соединения. Если механизм защиты согласован, то в даль-
нейшем он используется для всех сообщений, проходящих через
данное соединение. Механизм защиты начинает действовать сразу
после ввода последовательности CRLF, которая завершает аутентй- :
Сети передачи данных. Метод доступа
707
фикационный обмен для клиента, и прихода CRLF маркированного
отклика ОК сервера. Раз механизм защиты вступил в силу, поток
октетов команд и откликов заносится в буферы шифрованного тек-
ста. Каждый буфер передается через соединение в виде потока окте-
тов, который начинается с четырех октетов, содержащих длину пос-
ледующих данных. Максимальный размер буфера для текста-шиф-
ра определяется выбранным механизмом защиты.
Аутентификационные механизмы являются опционными. Ме-
ханизмы защиты также опционны; аутентификационный механизм
может реализоваться в отсутствии какого-либо механизма защиты.
Если команда AUTHENTICATE не прошла и получен отклик NO,
клиент может совершить повторную попытку, послав еще одну ко-
манду AUTHENTICATE, или может попытаться выполнить аутен-
тификацию с помощью команды LOGIN. Другими словами, клиент
может затребовать тип аутентификации в порядке понижения уровня
предпочтения, команда LOGIN используется как последний вариант.
Пример: S: * OK KerberosV4 IMAP4revl Server
С: А001 AUTHENTICATE KERBEROSV4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/
IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+oOKPKfHEcAFs9a3CL50ebe/
ydHJUwYFd
WwuQlMWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKilQh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful
5.2.2. Команда LOGIN
Аргументы: имя пользователя, пароль.
Отклики: команда не требует какого-либо специального отклика.
Результат: OK login завершено, система в состоянии с аутентификацией;
NO команда login не прошла: имя пользователя или пароль отвергнуты;
BAD команда неизвестна или неверный аргумент.
Команда LOGIN идентифицирует клиента серверу и передает па-
роль пользователя открытым текстом.
Пример: С: aOOl LOGIN SMITH SESAME
S: aOOl OK LOGIN completed
23*
708
Гпава 4
5. 3. Команды клиента в состоянии
"аутентификация осуществлена"
В состоянии ’’аутентификация осуществлена” разрешены коман-
ды манипуляции почтовыми ящиками, как объектами-атомами.
Команды SELECT и EXAMINE осуществляют выбор почтового ящи-
ка и переход в состояние "выбрано" .
В добавление к стандартным командам (CAPABILITY, NOOP и
LOGOUT), в состоянии "аутентификация осуществлена" допусти-
мы следующие команды: SELECT, EXAMINE, CREATE, DELETE,
RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и
APPEND.
5.3.1. Команда SELECT
Аргументы: имя почтового ящика.
Отклики: необходимы немаркированные отклики:
FLAGS, EXISTS, RECENT; опционны немаркированные
отклики OK: UNSEEN, PERMANENTFLAGS.
Результат: ОК процедура выбора закончена, система находится в состоянии "выбрано";
NO выбор неудачен: нет такого ящика, доступ к почтовому ящику невозможен;
BAD команда неизвестна или неверен аргумент.
Команда SELECT осуществляет выбор почтового ящика, так чтобы
обеспечить доступ к сообщениям, находящимся там. Прежде чем
присылать клиенту ОК, сервер должен послать клиенту следующие
немаркированные данные:
FLAGS — Флаги, определенные для почтового ящика.
<n> EXISTS — Число сообщений в почтовом ящике.
<n> RECENT — Число сообщений с набором флагов \Recent.
OK [UIDVALIDITY <п>] — Уникальный идентификатор
корректности.
Сервер должен также послать ’’невидимый" код отклика внутри
немаркированного сообщения ОК, который представляет собой по-
рядковый номер первого невидимого сообщения в почтовом ящике.
Если клиент не может изменить состояние одного или несколь-
ких флагов, перечисленных в немаркированном отклике FLAGS, сер-
вер должен в немаркированном отклике ОК послать код
PERMANENTFLAGS, перечислив флаги, которые клиент может из-
менить на постоянной основе.
Сети передачи данных. Метод доступа
709
Единовременно для одного соединения может быть выбран только
один почтовый ящик. Одновременный доступ к нескольким почто-
вым ящикам требует установления соответствующего числа соеди-
нений. Команда SELECT автоматически аннулирует выбор почтово-
го ящика при повторной попытке его выбора. Следовательно, если
почтовый ящик был выбран, а команда SELECT не прошла, предше-
ствующий выбор ящика аннулирован. Если клиенту разрешено мо-
дифицировать почтовый ящик, сервер должен снабжать маркиро-
ванный текст отклика ОК префиксом ’’[READ-WRITE]”.
Если клиенту не позволено модифицировать почтовый ящик, но
разрешен доступ для чтения, почтовый ящик выбирается в режиме
’’только для чтения" и сервер должен перед посылкой текста пере-
дать маркированный отклик ОК в ответ на команду SELECT с ко-
дом отклика ’’[READ-ONLY]”. Доступ "только для чтения" тем не
менее, отличается от команды EXAMINE. При нем некоторые по-
чтовые ящики позволяют изменять постоянное состояние некото-
рых флагов пользователя. Сетевые новости из файла .newsrc явля-
ются примером, когда некоторые состояния могут изменяться для
почтовых ящиков типа "только для чтения”.
Пример: С: А142 SELECT INBOX
S: * 172 EXISTS
S: 4 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed
5.3.2. Команда EXAMINE
Аргументы: имя почтового ящика.
Отклики: необходимы немаркированные отклики: FLAGS,
EXISTS, RECENT; опционны немаркированные
отклики OK: UNSEEN, PERMANENTFLAGS.
Результат: ОК осмотр закончен, система в состоянии "выбор сделан";
NO осмотр не прошел, система в состоянии "аутентификация выполнена"; нет такого почтового ящика; доступ к почтовому ящику невозможен;
BAD команда неизвестна или неверен аргумент.
710
Гпава 4
Команда EXAMINE идентична команде SELECT и дает тот ясе
результат, однако, выбранный почтовый ящик идентифицируется
как "только для чтения”. Никакие изменения постоянного состоя-
ния почтового ящика в этом случае не разрешены. Текст маркиро-
ванного отклика ОК на команду EXAMINE должен начинаться с
кода отклика "[READ-ONLY]".
Пример: С: А932 EXAMINE blurdybloop
S: * 17 EXISTS
S: * 2 RECENT
S: * OK [UNSEEN 8] Message 8 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
S: A932 OK [READ-ONLY] EXAMINE completed
5.3.3. Команда CREATE
Аргументы: имя почтового ящика.
Отклики: на эту команду не посылается каких-либо откликов.
Результат ОК команда выполнена;
NO команда не выполнена: почтовый ящик с таким
именем не может быть создан;
BAD команда неизвестна или неверен аргумент.
Команда CREATE создает почтовый ящик с заданным именем.
Отклик ОК присылается в случае, когда новый почтовый ящик с<
указанным именем создан. Попытка создания INBOX или почто-w
вого ящика с именем, существующего почтового ящика, является^
ошибкой. Любая ошибка при попытке создания почтового ящика;
вызовет маркированный отклик NO. <::
Если имя почтового ящика имеет суффикс с символом сепарато-
ра иерархии сервера (в соответствии с тем, что получено при выпол-
нении команды LIST), то это является декларацией клиента о наме-
рении создать почтовый ящик с именем в рамках указанной иерар-
хии. Реализации сервера, которые не требуют этой декларации
должны ее игнорировать.
Если символ-сепаратор иерархии сервера появляется где-либр
еще в имени, сервер должен создать любые имена более высокогР
уровня иерархии, которые необходимы для успешного завершения^
выполнения команды CREATE. Другими словами, попытка созд£*
ния "foo/bar/zap" на сервере, для которого символ являете?
Сети передачи данных. Метод доступа
711
иерархическим сепаратором, должна привести к созданию foo/ и
foo/bar/, если они до этого не существовали.
Если новый почтовый ящик создан с именем стертого почтового
ящика, то его идентификатор должен быть больше, использованно-
го его предшественником, если только новая версия ящика не имеет
другого значения UID.
Пример: С: А003 CREATE owatagusiam/
S: А003 OK CREATE completed
С: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed
Замечание: интерпретация этого примера зависит от того, явля-
ется ли символ иерархическим сепаратором. Если ’’/" иерархи-
ческий сепаратор, создается новый иерархический уровень с именем
. ’’owatagusiam” с новым членом иерархии этого уровня "blurdybloop”.
В противном случае создаются два почтовых ящика на одном и
том же уровне иерархии.
5.3.4. Команда DELETE
Аргументы: имя почтового ящика.
Отклики: команда не требует каких-либо откликов.
Результат ОК команда выполнена; ’
NO ошибка при выполнении команды: не удается
стереть ящик с этим именем;
BAD команда неизвестна или неверен аргумент.
Команда DELETE навечно удаляет почтовый ящик с указанным
именем. При этом присылается маркированный отклик ОК только
в том случае, когда ящик уничтожен. Ошибкой считается попытка
стереть INBOX или ящик с несуществующим именем.
Команда DELETE не должна удалять ящики с более низкой иерар-
хией, чем текущая. Например, если почтовый ящик ”foo” имеет
иерархическую структуру ’’foo.bar” (предполагается, что являет-
ся иерархическим сепаратором), удаление "foo” не должно удалять
foo.bar”. Считается ошибкой попытка удаления имени, которому
соответствуют нижележащие иерархические уровни, имеющие атри-
бут \Noselect.
Разрешено удалять ящики с именами, которым соответствуют
нижележащие иерархические уровни, не имеющие атрибута \Noselect.
® этом случае все сообщения из этого почтового ящика также бу-
ДУТ Удалены, а имя получит атрибут \Noselect.
712 Глава 4
Значение наибольшего используемого уникального идентифика- j
тора удаленных почтовых ящиков должно сохраняться, так чтобы
новые созданные ящики с тем же именем не использовали иденти-
фикаторы своих предшественников, если только новый ящик не
имеет другое значение UID.
Примеры: С: А682 LIST "" Ъ
S: * LIST () blurdybloop
S: * LIST (\Noselect) "/” foo
S: * LIST () foo/bar
S: A682 OK LIST completed
С: A683 DELETE blurdybloop
S: A683 OK DELETE completed
С: A684 DELETE foo
S: A684 NO Name "foo" has inferior hierarchical names
С: A685 DELETE foo/bar
S: A685 OK DELETE Completed
С: A686 LIST *
S: * LIST (\Noselect) foo
S: A686 OK LIST completed
С: A687 DELETE foo
S: A687 OK DELETE Completed
С: A82 LIST "" *
S: * LIST () "." blurdybloop
S: * LIST () foo
S: * LIST () foo.bar
S: A82 OK LIST completed
С: A83 DELETE blurdybloop
S: A83 OK DELETE completedC: A84 DELETE foo
S: A84 OK DELETE Completed
С: A85 LIST "" *
S: * LIST () "." foo.bar
S: A85 OK LIST completed
С: A86 LIST "" %
S: * LIST (\Noselect) foo
S: A86 OK LIST completed
5.3.5. Команда RENAME
Аргументы: имя существующего почтового ящика, имя нового
почтового ящика.
Отклики: эта команда не требует каких-либо специфических
откликов.
Сети передачи данных. Метод доступа
713
результат: ОК переименование успешно осуществилось;
NO переименование не прошло: не удалось пере-
именовать ящик с данным именем, не удалось
присвоить новое имя;
BAD команда неизвестна или неверен аргумент.
Команда RENAME изменяет имя почтового ящика. Маркиро-
ванный отклик ОК присылается лишь в случае, когда почтовый
ящик переименован. Считается ошибкой попытка переименовать
не существующий почтовый ящик или присвоить ящику уже имею-
щееся имя. Любая ошибка при переименовании вызовет маркиро-
ванный отклик NO.
Если ящик содержит в себе иерархическую структуру, имена этой
структуры не должны меняться. Например, переименование ”foo" в
"zap" переименует "foo/bar" (предполагая, что ”/" является иерар-
хическим разделителем) в "zap/bar".
Значение наибольшего использованного уникального идентифи-
катора имени старого почтового ящика должно быть сохранено, так
чтобы новый создаваемый с тем же именем почтовый ящик не
использовал идентификатора своего предшественника, если только
он не имеет другого значения UID.
Переименование INBOX разрешено, но имеет свою специфику.
Оно перемещает все сообщения в почтовый ящик с новым именем,
оставляя INBOX пустым. Если реализация сервера поддерживает
иерархические системы имен INBOX, это никак не сказывается на
переименовании INBOX.
Примеры: С: А682 LIST ”” *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () foo/bar
S: A682 OK LIST completed
С: A683 RENAME blurdybloop sarasoop
S: A683 OK RENAME completed
С: A684 RENAME foo zowie
S: A684 OK RENAME Completed
С: A685 LIST *
S: * LIST () sarasoop
S: * LIST (\Noselect) ”/" zowie
S: * LIST () zowie/bar
S: A685 OK LIST completed
C: Z432 LIST *
714
Гпава 4
S: * LIST () "." INBOX
S: * LIST О INBOX.bar
S: Z432 OK LIST completed
C: Z433 RENAME INBOX old-mail
S: Z433 OK RENAME completed
C: Z434 LIST ”” *
S: * LIST () "." INBOX
S: * LIST () INBOX.bar
S: * LIST () "." old-mail •
S: Z434 OK LIST completed
5.3.6. Команда SUBSCRIBE
Аргументы: имя почтового ящика.
Отклики: эта команда не требует каких-либо специфических
откликов.
Результат: ОК NO процедура подписки завершена; подписка не прошла: подписка для данного имени невозможна;
BAD команда неизвестна или неверен аргумент.
Команда SUBSCRIBE добавляет специфицированное имя почто-
вого ящика к списку "активных" или "подписных" ящиков серве-
ра, как это реализуется командой LSUB. Эта команда присылает
маркированный отклик ОК только в случае успешного осуществле-
ния подписки.
Сервер может проверить аргумент команды SUBSCRIBE, чтобы
проконтролировать его корректность для данного почтового ящи-
ка. Однако он не должен в одностороннем порядке удалять суще-
ствующее имя почтового ящика из подписного листа, даже если
ящика с таким именем более не существует.
Замечание: это требование возникает потому, что некоторые сер-
веры могут удалить почтовый ящик с известным именем (например^
"system-alerts") после того как срок годности его содержимого истек
с тем, чтобы создать его вновь при появлении новых сообщений.
Пример: С: А002 SUBSCRIBE #news.comp.mail.mime
S: A002 OK SUBSCRIBE completed
5.3.7. Команда UNSUBSCRIBE
Аргументы: имя почтового ящика. . ।
Отклики: эта команда не требует каких-либо специфических
. 3
откликов.
Сети передачи данных. Метод доступа
715
Результат: ОК NO ликвидация подписки прошла успешно; ликвидация подписки не прошла: это невозможно для данного имени;
BAD команда неизвестна или неверен аргумент.
Команда UNSUBSCRIBE удаляет специфицированный почтовый
ящик из списка ’’активных’’ или ’’подписных” почтовых ящиков
данного сервера, как это определяется командой LSUB. Эта команда
возвращает маркированный отклик ОК только в случае, если лик-
видация подписки прошла успешно.
Пример: С: А002 UNSUBSCRIBE #news.comp.maiLmime
S: А002 OK UNSUBSCRIBE completed
5.3.8. Команда LIST
Аргументы: имя, имя почтового ящика может содержать символы
Отклики: Результат: подмены (wildcard). немаркированные отклики LIST. ОК команда list выполнена; NO команда не прошла: не возможно выполнение list для данного образца или имени; BAD команда неизвестна или неверен аргумент.
Команда LIST возвращает субнабор имен из полного набора, дос-
тупного клиенту. Присылается нуль или более немаркированных
откликов LIST, содержащих атрибуты имен, иерархические раздели-
тели и имена.
Команда LIST должна возвращать данные быстро без существен-
ных задержек. Например, она не должна тратить время на выявле-
ние того является ли статус (\Marked или \Unmarked), или выпол-
нять другую трудоемкую обработку, ведь, если каждое имя требует
одной секунды, то обработка списка из 1200 имен займет 20 минут.
Аргумент, содержащий пустую строку образца имени (””), указы-
вает, что имя почтового ящика интерпретируется также, как это
Делает команда SELECT. Присланные имена почтовых ящиков дол-
жны соответствовать присланному шаблону имени. Непустой аргу-
мент шаблона является именем почтового ящика или уровнем иерар-
хии и указывает на контекст, в котором интерпретируется имя.
Пустой аргумент имени (’”’) представляет собой специальный зап-
рос, требующий присылки иерархического разделителя и корневого
имени. Значение, возвращаемое в качестве корневого имени, может
быть нулем, если шаблону не соответствует никакая иерархия. Иерар-
716 Глава <
хический разделитель присылается во всех случаях. Это позволяв!
клиенту получить иерархический разделитель даже в случае, когда
нет почтовых ящиков, соответствующих данному имени.
Шаблон и имя почтового ящика интерпретируются по-разному
в зависимости от реализации. В каноническом варианте анализ
происходит слева направо.
Любая часть аргумента шаблона, которая включена в интерпре-
тированную форму, должна предшествовать этой форме. Она долж- ?
на иметь тот же формат, что и аргумент шаблона имени. Это прави-
ло позволяет клиенту определить, соответствует ли присланное имя
почтового ящика контексту шаблона. Без этого правила, клиент
должен был бы знать семантику имен сервера.
Ниже приведены некоторые примеры того, как могут интерпре-J
тироваться образцы и имена почтовых ящиков на серверах базиру-
ющихся на UNIX:
Шаблон
-smith/Mail/
Archive/
#news.
-smith/Mail/
archive/
Имя почтового ящика
foo.*
%
comp.mail.*
/usr/doc/foo
-fred/Mail/*
Интерпретация
-smith/Mail/foo.*
archive/%
# news. comp .mail. * ;
/usr/doc/foo л;
-fred/Mail/* /
Первые три примера демонстрируют интерпретацию в контексте^
аргумента шаблона. Заметьте, что "-smith/Mail" не должно преоб-/
разоваться во что-то подобное ”/u2/users/smith/Mair', иначе для
клиента было бы невозможно определить, соответствовала ли ин«Ц:
терпретация контексту шаблона.
Символ ’’*’’ представляет собой подмену (wildcard), и соответ*-/
ствует нулю или более символов в данной позиции. Символ
подобен "*", но он не соответствует иерархическому разделителю.!.
Если символ ”%” является последним символом имени почтового/
ящика, то в отклике будут присланы и соответствующие уровни/
иерархии. Если эти уровни не являются почтовыми ящиками, кото-^
рые можно выбрать, то их имена снабжаются атрибутом \Noselecfc\
Реализациям сервера таким образом позволено спрятать некото^
рые почтовые ящики, имена которых могли бы быть раскрыты Ф
использованием шаблонов с символами подмены (wildcard). На-
пример, сервер на основе UNIX может ограничить интерпретацию.^
"*" так, что начальный символ "/” будет приводить к несоответ-j
ствию имени шаблону.
Сети передачи данных. Метод доступа 717
—
Специальное имя INBOX включается в выдачу команды LIST,
если INBOX поддерживается данным сервером для данного пользо-
вателя и, если строка ’’INBOX", напечатанная прописными буквами,
соответствует интерпретированному шаблону.
Пример: С: А101 LIST
S: * LIST (\Noselect)
S: А101 OK LIST Completed
С: А102 LIST #news.comp.mail.misc ’”’
S: * LIST (\Noselect) #news.
S: A102 OK LIST Completed
С: A103 LIST /usr/staff/jones
S: * LIST (\Noselect) /
S: Al03 OK LIST Completed
С: A202 LIST -/Mail/ %
S: * LIST (\Noselect) ’’/’’ ~/Mail/foo
S: * LIST () ’’/’’ -/Mail/meetings
S: A202 OK LIST completed
5.3.9. Команда LSUB
Аргументы: имя-шаблон, имя почтового ящика может содержать
символы подмены (wildcards).
Отклики: немаркированный отклик: LSUB
Результат: ОК команда успешно исполнена;
NO команда не прошла: не возможна выдача списка
для предлагаемого шаблона или имени;
BAD команда неизвестна или неверен аргумент.
Команда LSUB возвращает субнабор имен из списка пользовате-
ля, который декларирован как "активный" или "подписной". При
этом отправляется нуль или более немаркированных откликов LSUB.
Аргументы LSUB имеют тот же формат, что и для команды LIST.
Сервер может проверить имена из подписного листа с тем, чтобы
Убедиться, существуют ли они еще. Если имени не существует, оно
Должно быть помечено в отклике LSUB атрибутом \Noselect. Сервер
Не Должен по своему усмотрению удалять имена почтовых ящиков
из подписного листа даже, если такого ящика более не существует.
Пример: С: А002 LSUB "#news.” ’’comp.mail.*’’
S: * LSUB () #news.comp.mail.mime
S: * LSUB () #news.comp.mail.misc
S: A002 OK LSUB completed
5.3.10. Команда STATUS
Аргументы: имя почтового ящика, статусная информация имен.
Отклики: немаркированные отклики STATUS.
Результат: ОК
NO
команда успешно выполнена;
команда не прошла: нет статусной информации
для данного имени;
команда неизвестна или неверен аргумент.
BAD
Команда STATUS запрашивает статусные данные для указан-
ного почтового ящика. Она не изменяет выбор почтового ящика и
не вносит каких-либо изменений в состояние сообщений для запро-
шенного ящика (в частности команда STATUS не должна вызы-
вать потерю флага \Recent).
Команда STATUS предоставляет альтернативу открытию до-
полнительного IMAP 4.1 соединения и реализует команду EXAMINE
для запрашиваемого почтового ящика, не изменяя выбора, выпол-
ненного при первичном соединении.
В отличии от команды LIST, команда STATUS не гарантирует
быстрого отклика. В некоторых реализациях сервер обязан открыть
почтовый ящик в режиме "только чтение", чтобы получить нужные
статусные данные. Кроме того, команда STATUS не допускает сим-
волов подмены в шаблоне имени. В настоящее время определены
следующие статусные данные, которые могут быть запрошены:
MESSAGES RECENT UIDNEXT Число сообщений в почтовом ящике Число сообщений с установленным флагом \Recent Следующее значение, которое будет предписано новому сообщению в почтовом ящике. Гарантиру- ется, что это значение не изменится, если только в ящик не будет положено новое сообщение. UID будет изменен при укладке нового сообщения, даже
если оно после этого стерто.
UIDVALIDITY Уникальный идентификатор почтового ящика
UNSEEN Число сообщений, не имеющих установленного флага \Seen
Пример: С: А042 STATUS blurdybloop (UIDNEXT MESSAGES)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
S: A042 OK STATUS completed
Сети передачи данных. Метод доступа
719
5.3.11. Команда APPEND
Аргументы: имя почтового ящика, опционно - флаг списка со
скобками, опционно - строка даты и времени, литерал
сообщения
Отклики: команда не требует какого-либо специального отклика
Результат: ОК команда успешно исполнена
NO команда не прошла: добавление в почтовый
ящик не удалось, ошибка во флагах или
дате/времени, или в тексте сообщения
BAD команда неизвестна или неверен аргумент
Команда APPEND добавляет литеральный аргумент в качестве
нового сообщения в почтовый ящик. Этот аргумент должен следо-
вать формату сообщений [RFC-822]. Допускается использование в
сообщениях 8-битовых символов. Реализация сервера, которая не
может работать с 8-битовыми данными, должна быть способна пре-
образовывать 8-битовую информацию APPEND в 7-битовую, исполь-
зуя транспортное кодирование [М1МЕ-1МВ]. Если специфицирован
флаг списка со скобками, в результирующих сообщениях должны
быть установлены флаги, в противном случае список флагов будет
установлен по умолчанию пустым.
Если специфицировано date__time, в результирующем сообщении
должна быть установлена внутренняя дата, в противном случае,
внутренняя дата и время результирующего сообщения будут уста-
новлены по умолчанию равными текущим значениям. Если коман-
да append по какой-то причине не прошла, почтовый ящик должен
быть возвращен в состояние, которое он имел до команды APPEND.
Если почтового ящика места назначения не существует, сервер
должен сообщить об ошибке, а не должен автоматически создавать
новый почтовый ящик. Если не ясно, может или нет быть создан
почтовый ящик, сервер должен послать код отклика "[TRYCREATE]"
в качестве префикса текста маркированного отклика NO. Это ука-
зывает клиенту на возможность попытки исполнения команды
CREATE, после чего, в случае успеха, повторить команду APPEND.
Если в настоящее время почтовый ящик выбран, то немедленно
Должны начаться почтовые операции. Сервер должен уведомить
клиента об этом, послав немаркированный отклик EXISTS. Если
сервер не делает этого, клиент после одной или более команд APPEND
может выдать команду NOOP (или при неудаче команду CHECK).
720
Гпава 4
Пример: С: АООЗ APPEND saved-messages (\Seen) {310}
С: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@Blurdybloop.C0M>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK APPEND completed
Замечание: команда APPEND не используется для» доставки сооб-
щений, так как она не содержит в себе механизма передачи служеб-
ной информации [SMTP].
5.4. Команды клиента в состоянии "выбор сделан"
В состоянии ’’выбор сделан”, разрешены команды, которые мани-
пулируют сообщениями в почтовом ящике. Помимо универсаль-
ных команд (CAPABILITY, NOOP и LOGOUT), а также команд ре-
жима аутентификации (SELECT, EXAMINE, CREATE, DELETE,
RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и
APPEND), в данном режиме доступны следующие команды: CHECK,
CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY и UID.
5.4.1. Команда CHECK
Аргументы: отсутствуют.
Отклики: команда не требует какого-либо специального отклика;
Результат: ОК проверка завершена;
BAD команда неизвестна или неверен аргумент
Команда CHECK осуществляет проверку выбранного почтового
ящика. Проверка относится к любым характеристикам, зависящим
от реализации (например, выявление положения почтового ящика в
памяти сервера и на диске). Если сервер не поддерживает таких
возможностей, команда эквивалентна NOOP.
Не существует гарантии, что в результате CHECK будет прислав
немаркированный отклик. Для проверки поступления новой почты
следует использовать команду NOOP, а не CHECK.
Пример: С: FXXZ CHECK
S: FXXZ OK CHECK Completed
Сети передачи данных. Метод доступа
721
5.4.2. Команда CLOSE
Аргументы: отсутствуют
Отклики: команда не требует какого-либо специального отклика;
Результат: ОК команда выполнена, система в состоянии
’’аутентификация выполнена";
NO команда не прошла, никакого ящика не выбрано;
BAD команда неизвестна или неверен аргумент
Команда CLOSE навечно удаляет из выбранного почтового ящи-
ка все сообщения, помеченные флагом \Deleted, и возвращает систе-
му в состояние "аутентификация выполнена". Никакого немарки-
рованного отклика EXPUNGE не посылается.
Никаких сообщений не удаляется и никаких флагов ошибки не
возвращается, если почтовый ящик был выбран командой EXAMINE
или находился в режиме "только для чтения".
Даже если почтовый ящик выбран, команды SELECT, EXAMINE
или LOGOUT могут быть использованы без предварительного ис-
полнения команды CLOSE. Команды SELECT, EXAMINE и LOGOUT
безоговорочно закрывают выбранный в данный момент почтовый
ящик без удаления сообщений. Однако когда удалено много сооб-
щений, последовательность CLOSE-LOGOUT или CLOSE-SELECT зна-
чительно быстрее, чем EXPUNGE-LOGOUT или EXPUNGE-SELECT,
так как здесь не посылается никаких немаркированных откликов
EXPUNGE (которые клиент вероятно проигнорирует).
Пример: С: А341 CLOSE
S: А341 OK CLOSE completed
5.4.3. Команда EXPUNGE
Аргументы: отсутствуют
Отклики: немаркированные отклики EXPUNGE.
Результат: ОК команда успешно завершена;
NO
BAD
команда не прошла: стирание не выполнено
(например, запрещено); ч
команда неизвестна или неверен аргумент
Команда EXPUNGE навечно удаляет из выбранного почтового
ящика все сообщения, которые помечены флагами \Deleted. Прежде
нем выдать клиенту сигнал ОК, посылается немаркированный от-
клик EXPUNGE для каждого из удаляемых сообщений.
722
Гпава 4
Пример: С: А202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed
Замечание: в этом примере, сообщения 3, 4, 7 и 11 имеют уста-
новленный флаг \Deleted. Следует учитывать, что после каждого
удаления сообщения перенумеруются. f
5.4.4. Команда SEARCH й
Аргументы: опционны, [CHARSETJ-спецификация.
Критерии поиска (один или более).
Отклики: необходим немаркированный отклик SEARCH.
Результат: ОК поиск успешно завершен;
NO ошибка: поиск для данного набора символов или
критериев не возможен;
BAD команда неизвестна или неверен аргумент
Команда SEARCH ищет почтовый ящик, который отвечает выб-
ранным критериям отбора. Критерий отбора состоит из одного или
более ключей поиска. Немаркированный отклик SEARCH от серве- |
ра содержит список номеров сообщений, которые соответствуют кри- v
териям отбора.
Когда специфицировано несколько ключей, результатом являет-
ся совокупность всех сообщений, отвечающим заданным критери-
ям (функция AND)'. Например, критерий DELETED FROM ’’SMITH” /
SINCE 1-Feb-1994 относится ко всем стертым сообщениям от Сми- *
та, которые были положены в почтовый ящик после 1-го февраля \
1994. Возможно объединение ключей с помощью скобок и операто-
ров AND, OR или NOT.
Опционная спецификация [CHARSET] состоит из слова
’’CHARSET’’, за которым следует зарегистрированное название сим-
вольного набора. [CHARSET] характеризует строки, которые ис-
пользуются в качестве критерия отбора. Транспортное кодирование
содержимого [MIME-IMB] и строки [MIME-HDRS] в [RFC-822]/
[MIME-IMB] заголовках, должны декодироваться перед сравнением
текста в представлении [CHARSET], отличном от US-ASCII. US- **
ASCII должно поддерживаться всегда, но могут использоваться и
другие символьные наборы [CHARSET], Если сервер не поддержи-
Сети передачи данных. Метод доступа 7^3
вает специфицированный набор символов [CHARSET], он должен
вернуть маркированный отклик NO (но не BAD).
Для всех ключей поиска, которые используют строки, сообщение
соответствует ключу, если строка является частью строки поля в
сообщении. Соответствие не должно зависеть от использования строч-
ных или прописных символов. Стандартными ключами поиска яв-
ляются следующие слова и выражения.
<набор сообщенйй>Сообщения с номерами, соответствующими
специфицированному набору номеров
ALL Все сообщения в почтовом ящике; ключ отбора по умолчанию для последующего применения команд AND.
answered ВСС <строка> Сообщения с установленным флагом \Answered. Сообщения, которые содержат специфицирован- ную строку в поле ВСС заголовка сообщения.
BEFORE <дата> Сообщения, чьи внутренние даты раньше указан- ной
BODY <строка> Сообщения, которые содержат специфицирован-. ную строку в теле сообщения.
СС <строка> Сообщения, которые содержат специфицирован- ную строку в СС поле заголовка.
DELETED DRAFT FLAGGED Сообщения с установленным флагом \Deleted. Сообщения с установленным флагом \Draft. Сообщения с установленным флагом \Flagged.
FROM <строка> Сообщения, которые содержат специфицирован-
ную строку в поле заголовка FROM.
HEADER <имя поля> <строка> Сообщения, которые содержат
заголовок со специфицированным именем поля (в соответствии с [RFC-822]) и специфицирован-
ную строку в данном поле.
KEYWORD <флаг> Сообщения со специфицированным ключе-
larger <п> выми словами. Сообщения с размером [RFC-822] больше чем
NEW специфицированное число октетов. Сообщения, которые имеют установленный флаг \Recent, но не имеют флага \Seen. Это функцио-
нально эквивалентно "(RECENT UNSEEN)”.
NOT <ключ поиска> Сообщения, которые не содержат специфи-
OLD цированного ключевого слова. Сообщения, которые не имеют флага \Recent. (’’NOT RECENT”).
724
Гпава 4
ON <дата> Сообщения, чья внутренняя дата соответствует специфицированному значению даты.
OR <ключ поиска 1> <ключ поиска 2> Сообщения, которые
RECENT соответствуют любому из ключевых слов поиска. Сообщения, которые имеют установленный флаг \Recent.
SEEN Сообщения, которые имеют установленный флаг \Seen.
SENTBEFORE <дата> Сообщения, чье содержимое заголовка,
SENTON <дата> соответствует дате раньше специфицированного значения [RFC-822]. Сообщения, чье содержимое заголовка, соответ- ствует специфицированному значению даты [RFC-822]:
SENTSINCE <дата> Сообщения, чье содержимое заголовка,
SINCE <дата> соответствует [RFC-822] специфицированному значению даты или более позднему времени. Сообщения, чья внутренняя дата соответствует
SMALLER <n> или позже специфицированного значения. Сообщения с размером [RFC-822] меньше чем специфицированное число октетов.
SUBJECT <строка> Сообщения, которое содержит специфици-
рованную строку в поле SUBJECT заголовка.
TEXT <строка> Сообщения, которые содержат специфицирован- ную строку в заголовке или теле сообщения
ТО <строка> Сообщения, которые содержат специфицирован-
ную строку в поле заголовка ТО.
UID <на(5ор сообщений> Сообщения с уникальными иденти-
UNANSWERED UNDELETED UNDRAFT UNFLAGGED фикаторами, соответствующими заданному набо- ру UID. Сообщения, которые не имеют флага \Answered. Сообщения, которые не имеют флага \Deleted. Сообщения, которые не имеют флага \Draft. Сообщения, которые не имеют флага \Flagged.
UNKEYWORD <флаг> Сообщения, которые не содержат заданного
UNSEEN набора ключевых слов. Сообщения, которые не имеют флага \Seen.
Пример: С: А282 SEARCH FLAGGED SINCE l-Feb-1994 NOT
FROM "Smith"
S: * SEARCH 2 84 882
S: A282 OK SEARCH completed
Сети передачи данных. Метод доступа 725
5.4.5. Команда FETCH
Аргументы: набор сообщений,имена информационных сообщений.
Отклики: немаркированные отклики: FETCH
Результат: ОК операция успешно завершена;
NO команда не прошла: не удалось доставить эти
данные;
BAD команда неизвестна или неверен аргумент
Команда FETCH извлекает данные, соответствующие сообще-
нию в почтовом ящике. В качестве доставляемых данных может
выступать отдельный атом или список элементов, помещенных в
скобки. В настоящее время определены следующие типы данных,
которые могут быть доставлены:
ALL Эквивалентно: (FLAGS INTERNALDATE RFC822.SIZE
ENVELOPE)
BODY Нерасширяемая форма BODYSTRUCTURE.4
BODYf <section>]«partial» Текст определенной части тела
сообщения. Спецификация секции представляет собой нуль
или более спецификаторов, разделенных точками. Специфи-
катором части является либо число, либо одно из имен:
HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME и TEXT.
Пустая спецификация относится ко всему сообщению, включая за-
головок.
Каждое сообщение имеет номер, по крайней мере, одной части.
Сообщения не-[М1МЕ-1МВ] и несоставные сообщения [MIME-
IMB] без инкапсуляции имеют только часть 1.
В составных сообщениях частям присваиваются последователь-
ные номера в порядке их появления. Если конкретная часть явля-
ется составным сообщением, то его части должны быть выделены
точкой, за которой следует номер части.
Спецификаторы частей HEADER, HEADER.FIELDS,
HEADER.FIELDS.NOT и TEXT являются базовыми. Перед ними мо-
гут размещаться один или более числовых спецификаторов частей
сообщения, которые указывают на принадлежность типу MESSAGE/
RFC822. Перед спецификатором части MIME должны размещаться
один или более числовых спецификаторов. Спецификаторы частей
HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT относятся к заго-
ловку сообщения [RFC-822] или инкапсулированному сообщению
[MIME-IMT] MESSAGE/RFC822. За HEADER.FIELDS и
HEADER.FIELDS.NOT следует список имен полей (как это опреде-
лено в [RFC-822]). Субнабор, возвращаемый HEADER.FIELDS, со-
726
Гпава 4
держит только те поля заголовка, имена которых соответствуют
одному из имен списка. Аналогично, субнабор, возвращаемый
HEADER.FIELDS.NOT, содержит только поля заголовка с несоот*
ветствующими именами полей. Соответствие является точным, но
нечувствительным к использованию строчных и прописных букв.
Во всех случаях, вставляется разграничивающая пустая строка между
заголовком и телом сообщения.
Спецификатор MIME части относится к заголовку [MIME-IMB]
этой части. Спецификатор текстовой части относится к телу сооб-
щения без заголовка [RFC-822]. Ниже приведен пример составного
сообщения с некоторыми спецификаторами его частей:
HEADER ([RFC-822] заголовок сообщения)
TEXT MULTIPART/MIXED
1 TEXT/PLAIN
2 APPLICATION/OCTET-STREAM
3 MESSAGE/RFC822
3 .HEADER ([RFC-822] заголовок сообщения)
3 .TEXT ([RFC-822] текстовое тело сообщения)
3.1 TEXT/PLAIN
3.2 APPLICATION/OCTET-STREAM
4 MULTIPART/MIXED
4.1 IMAGE/GIF
4.1. MIME ([MIME-IMB] заголовок для IMAGE/GIF)
4.2 MESSAGE/RFC822
4.2. HEADER ([RFC-822] заголовок сообщения)
4.2. TEXT ([RFC-822] текстовое тело сообщения)
4.2.1 TEXT/PLAIN
4.2.2 MULTIPART/ALTERNATIVE
4.2.2.1 TEXT/PLAIN
4.2.2.2 TEXT/RICHTEXT
Имеется возможность доставить субстроку определенного тек-
ста. Это делается путем присоединения к спецификатору части от-
крытой угловой скобки (”<”), положения первого нужного октета,
точки, максимального требуемого числа октетов и закрывающей уг-
ловой скобки. Если начальный октет находится за пределами тек-
ста, возвращается пустая строка.
При любой частичной доставке, при которой производится по-
пытка чтения за пределами текста, фрагмент соответствующим об-
разом обрезается.
Сети передачи данных. Метод доступа 72 7
Замечание: это означает, что запрос BODY[]<0.2048> сообще-
ния длиной 1500 октетов пришлет BODY[]<0> с литералом разме-
ра 1500, а не BODY[]. Все вышеприведенные комментарии относят-
ся к типу данных BODY. Ниже следует продолжение описания ти-
пов данных, используемых командой FETCH.
BODY.PEEK[<section>] «partial» — Альтернативная форма
BODY[<section>], которая не устанавливает флаг \Seen.
BODY STRUCTURE — Структура тела сообщения [М1МЕ-1МВ].
Она вычисляется сервером путем разбора полей заголовка
[MIME-IMB] [RFC-822] и заголовков [М1МЕ-1МВ].
ENVELOPE — Структура заголовка сообщения. Она выявляется
сервером в результате разбора заголовка [RFC-822] на
части, присваивая им значения по умолчания, если это
необходимо.
FAST — Макро эквивалент (FLAGS INTERNALDATE RFC822.SIZE)
FLAGS — Флаги, присвоенные сообщению.
FULL — Макро эквивалент (FLAGS INTERNALDATE
RFC822.SIZE ENVELOPE BODY)
INTERNALDATE — Внутренняя дата сообщения.
RFC822 — Функционально эквивалентно BODY[], отличается по
синтаксису результирующих немаркированных данных
FETCH (возвращаемые данные имеют формат RFC822).
RFC822.HEADER — Функционально эквивалентно
BODY.PEEK[HEADER], отличается по синтаксису результи-
рующих немаркированных данных FETCH (возвращается
RFC822.HEADER).
RFC822.SIZE ~ Размер сообщения [RFC-822].
RFC822.TEXT — Функционально эквивалентно BODY[TEXT],
отличается по синтаксису результирующих немаркирован-
ных данных FETCH (возвращается RFC822.TEXT).
UID — Уникальный идентификатор сообщения.
Пример:
С: А654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
S: * 2 FETCH ....
S: * 3 FETCH ....
S: *4 FETCH ....
S: A654 OK FETCH completed
728
Глава- 4
5.4.6. Команда STORE
Аргументы: набор сообщений, имя элемента сообщения,
значение элемента сообщения.
Отклики: немаркированные отклики: FETCH.
Результат: ОК операция успешно завершена;
NO команда не прошла: данные не могут быть
запомнены;
BAD команда неизвестна или неверен аргумент
Команда STORE заносит данные в почтовый ящик. В норме ко-
манда STORE возвращает обновленную версию данных с немаркиро-
ванным откликом FETCH. ’’.SILENT’’ в имени элемента данных
блокирует немаркированный отклик FETCH, и сервер должен пред-
полагать, что клиент определил обновленное значение сам или ему
обновленное значение не нужно.
Замечание: вне зависимости от того используется или нет суф-
фикс ’’.SILENT”, сервер должен послать немаркированный отклик
FETCH, если изменение флагов сообщения вызваны внешними при-
чинами.
В настоящее время определены следующие элементы данных:
FLAGS <список флагов> — Заменить флаги сообщения, приведен-
ного в аргументе. Новое значение флагов присылается, как
если бы выполнялась команда FETCH для этих флагов.
FLAGS.SILENT <список флагов> — Эквивалентно FLAGS, но без
возвращения нового значения.
+FLAGS <список флагов> — Добавить аргумент к флагам сооб-
щения; Новое значение флагов возвращается, как при
исполнении команды FETCH.
+FLAGS.SILENT ссписок флагов> — Эквивалентно +FLAGS, но
без возвращения нового значения.
-FLAGS <список флагов> — Удаляет аргумент из флагов сообще-
ния. Новое значение флагов возвращается, как при испол-
нении команды FETCH.
-FLAGS.SILENT ссписок флагов> — Эквивалентно -FLAGS, но без
возвращения нового значения.
Пример: С: АООЗ STORE 2:4 +FLAGS (\Deleted)
S: * 2 FETCH FLAGS (\Deleted \Seen)
S: * 3 FETCH FLAGS (\Deleted)
S: 4 FETCH FLAGS (\Deleted \Flagged \Seen)
S: A003 OK STORE completed
Сети передачи данных. Метод доступа
729
5.4.7. Команда COPY
Аргументы: набор сообщений, имя почтового ящика.
Отклики: команда не требует какого-либо специального отклика.
Результат: ОК команда успешно завершена;
NO команда не прошла: не могут быть скопированы
эти сообщения вообще или в данный почтовый
ящик;
BAD команда неизвестна или неверен аргумент.
Команда COPY копирует специфицированное сообщение в конец
указанного почтового ящика. Флаги и внутренняя дата сообщения
должны быть сохранены в копии.
Если указанный почтовый ящик отсутствует, сервер должен при-
слать сообщение об ошибке. Он не должен автоматически создавать
почтовый ящик. Если заведомо не известно, что ящик не может
быть создан, сервер должен послать код отклика "[TRYCREATE]" в
качестве префикса текста маркированного отклика NO. Это предла-
гает клиенту возможность исполнить команду CREATE, после чего
в случае успеха повторно исполнить команду COPY.
Если команда COPY не прошла по какой-то причине, сервер
должен восстановить почтовый ящик в состояние, которое он имел
до выполнения COPY.
Пример: С: А003 COPY 2:4 MEETING
S: А003 OK COPY completed
5.4.8. Команда UID
Аргументы: имя команды,
аргументы команды.
Отклики: немаркированные отклики: FETCH, SEARCH.
Результат: ОК команда UID завершена;
NO команда UID не прошла;
BAD команда неизвестна или неверен аргумент.
Команда UID имеет две формы. В первой форме она использует в
качестве аргумента имена команд COPY, FETCH или STORE (с их
аргументами). Однако числа в наборе аргументов в этом случае
представляют собой уникальные идентификаторы, а не порядковые
номера сообщений.
Во второй форме команда UID использует команду SEARCH с ее
аргументами. Интерпретация аргументов та же, что и в случае
SEARCH; однако, числа, возвращаемые в отклике на команду UID
730
Гпава 4
SEARCH, представляют собой уникальные идентификаторы, а не
порядковые номера сообщений. Например, команда UID SEARCH
1:100 UID 443:557 возвратит уникальный идентификатор, соответ-
ствующий пересечению порядкового номера сообщения 1:100 и UID
443:557.
Допускаются диапазоны номеров сообщений, однако, нет гаран-
тии, что уникальные идентификаторы образуют монотонную после-
довательность без пропусков. Не существующие уникальные иден-
тификаторы в списке сообщений игнорируются без генерации сооб-
щения об ошибке.
Число после в немаркированном отклике FETCH всегда
является порядковым номером сообщения, а не уникальным
идентификатором, даже для отклика на команду UID. Однако реа-
лизации сервера должны безоговорочно включать значение UID в
качестве части любого отклика FETCH, вызванного командой UID,
вне зависимости от того, был ли UID специфицирован в качестве
элемента сообщения для FETCH.
Пример: С: А999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: *• 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 UID FETCH completed
5.5. Команды клиента — экспериментальные и расширения
5.5.1. Команда X<atom>
Аргументы: определяется приложением.
Отклики: определяется приложением.
Результат: ОК команда выполнена;
NO отказ;
BAD команда неизвестна или неверен аргумент.
Любая команда с префиксом X является экспериментальной
командой. Команды, которые не являются частью этой специфика-
ции стандарта, модификации стандарта или одобренного IESG экс-
периментального протокола, должны использовать префикс X.
Любой добавленный немаркированный отклик, посланный экс-
периментальной командой также должен иметь префикс X. Реали-
зации сервера не должны посылать такие немаркированные откли-
ки, если только клиент не запрашивает их посредством какой-либо
экспериментальной команды.
(Лети передачи данных. Метод доступа
737
Пример: С: а441 CAPABILITY
S: * CAPABILITY IMAP4revl AUTH=KERBER0S_V4 XPIG-LATIN
S: a441 OK CAPABILITY completed
С: A442 XPIG-LATIN
S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
S: A442 OK XPIG-LATIN completed-cay
6. Отклики сервера
Существует три вида откликов сервера: отклики состояния, ин-
формация сервера и запрос продолжения команды. Информация, со-
держащаяся в отклике сервера, идентифицируется словом ’’Содер-
жимое:”.
Клиент должен быть готов воспринять любой отклик в любое
время. Отклики состояния могут быть маркированными или нет.
Маркированные отклики состояния указывают на результат завер-
шения команды клиента (ОК, NO или BAD) и имеют метку, соответ-
ствующую команде.
Некоторые отклики состояния и любая информация сервера не
маркируются. Немаркированный отклик выделяется символом
вместо метки. Немаркированные отклики состояния отмечают ре-
акцию сервера, они не указывают на завершение выполнения ко-
манды (например, предупреждение о предстоящем отключении сис-
темы). По историческим причинам немаркированные информаци-
онные отклики сервера называются также ’’незапрашиваемыми
данными”.
Определенные данные от сервера должны записываться клиен-
том при получении. Такие данные несут критическую информацию,
которая влияет на интерпретацию всех последующих команд и от-
кликов (например, создание или уничтожение сообщений).
Прочие данные сервера следует записывать для последующих
ссылок, если клиент не нуждается в записи данных или если запись
данных не имеет очевидного смысла (например, отклик SEARCH,
когда никакой команды SEARCH не исполняется), такая информа-
ция должна игнорироваться.
Немаркированная информация посылается сервером, когда со-
единение IMAP находится в "выбранном" состоянии. В этом состо-
янии при выполнении команды сервер проверяет наличие новых
сообщений в выбранном почтовом ящике. В норме, это часть про-
цедуры выполняется любой командой, следовательно, даже команды
NOOP достаточно для проверки наличия новых сообщений. Если
обнаружены новые сообщения, сервер посылает немаркированные
отклики EXISTS и RECENT, отражающие новые размеры почтово-
732
Гпава 4
го ящика. Реализации сервера, которые предлагают множественный
одновременный доступ к одному и тому же ящику, также должны
посылать соответствующие немаркированные отклики FETCH и
EXPUNGE, если другие агенты изменяют состояние любого флага
сообщения или удаляют сообщение.
Отклики запросов продолжения команды используют символ ”+"
вместо метки. Эти отклики посылаются сервером для индикации
приема незавершенной команды клиента и готовности приема ос-
тальной части команды.
6.1. Отклики сервера - отклики состояния
Статусными откликами являются OK, NO, BAD, PREAUTH и р
BYE. ОК, NO и BAD могут быть маркированными или нет. PREAUTH
и BYE - всегда не маркированы.
Статусные отклики могут включать опционный код отклика.
Код отклика состоит из информации, заключенной в квадратные
скобки, в форме атома. Далее может следовать пробел и аргументы.
Код отклика содержит дополнительную информацию или статус-
ные коды для программы клиента помимо условий OK/NO/BAD.
Эти данные определяются, когда клиент может предпринять дей- \
ствия на основе этой дополнительной информации. В настоящее
время определены следующие коды откликов:
ALERT — Текстовое сообщение, содержащее специальное предуп-
реждение, которое должно быть представлено пользователю ,
в форме, привлекающей внимание.
NEWNAME — За этим откликом следует имя почтового ящика и .
новое имя. Команды SELECT или EXAMINE не пройдут, так
как ящик места назначения более не существует из-за
переименования. Это является указанием для клиента,
попытаться повторить команду с новым именем почтового
ящика.
PARSE — Текстовое сообщение, которое указывает на ошибку при
разборе заголовка [RFC-822] или заголовка [MIME-IMB]
сообщения.
PERMANENTFLAGS — Когда за этим кодом следует в скобках
список флагов, это указывает, какие из известных флагов
могут быть изменены на постоянной основе. Любые флаги,
которые указаны в немаркированном отклике FLAGS, но
отсутствуют в списке PERMANENTFLAGS, могут быть
установлены на постоянной основе. Если клиент пытается
запомнить (STORE) флаг, который отсутствует в списке
PERMANENTFLAGS, сервер либо отвергнет этот запрос с
QeTn передачи данных. Метод доступа
733
помощью отклика NO или запомнит состояние только до
конца текущей сессии. Список PERMANENTFLAGS может
также включать специальный флаг \*, который указывает,
что имеется возможность создать новые ключевые слова
путем записи этих флагов в почтовый ящик.
READ-ONLY — Почтовый ящик выбран в режиме только для чтения
или доступ к нему был сменен с read-write на read-only.
READ-WRITE — Почтовый ящик находится в режиме read-write,
или доступ к нему был сменен с read-only на read-write.
TRYCREATE — Попытка выполнения APPEND или COPY оказа-
лась неуспешной из-за того, что почтовый ящик места
назначения отсутствует. Это указывает клиенту, что опера-
ция может оказаться успешной, если почтовый ящик будет
сначала создан с помощью CREATE
UIDVALIDITY — Когда за этим кодом следует десятичное число, это
указывает на значение уникального идентификатора (UID).
UNSEEN — Когда за этим кодом следует десятичное число, это
указывает на значение номера первого сообщения без флага
\Seen.
Дополнительные коды откликов определенные конкретным кли-
ентом или сервером должны иметь префикс "X ”, если они отклоня-
ются от рекомендаций данного документа. Реализации клиента дол-
жны игнорировать отклики, которые ими не распознаются.
6.1.1. Отклик ОК
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик ОК индицирует информационное сообщение от сервера.
Если оно маркировано, сообщение указывает на успешное заверше-
ние соответствующей команды. Пользователю может быть предло-
жено текстовое сообщение. Немаркированная форма указывает на
чисто информационное сообщение; природа информации может быть
Указана в коде отклика.
Немаркированная форма используется также как один из трех
видов оповещения об установлении начального соединения. Эта
форма указывает, что еще не выполнена аутентификация и необхо-
дима команда LOGIN.
Пример: S: * OK IMAP4revl server ready
С: А001 LOGIN fred blurdybloop
734
Гпава 4
S: * OK [ALERT] System shutdown in 10 minutes
(Через 10 минут ожидается отключение системы)
S: А001 OK LOGIN Completed
6.1.2. Отклик NO
Содержимое: опционный код отклика;
текст, читаемый человеком.
Отклик NO указывает на сообщение от сервера об операционной '
ошибке. В помеченной форме он отмечает неудачное завершение
соответствующей команды. Непомеченная форма служит для инди- 4
кации предупреждения, команда все еще может завершиться успеш-
но. Текстовое сообщение описывает условия.
Пример: С: А222 COPY 1:2 owatagusiam
S: * NO Disk is 98% full, please delete unnecessary data
S: A222 OK COPY completed
С: A223 COPY 3:200 blurdybloop
S: * NO Disk is 98% full, please delete unnecessary data
S: * NO Disk is 99% full, please delete unnecessary data
S: A223 NO COPY failed: disk is full
6.1.3. Отклик BAD
Содержимое: опционный код отклика;
текст, читаемый человеком.
Отклик BAD отмечает сообщение об ошибке со стороны сервера.
В маркированной форме он сообщает об ошибке протокольного уров-
ня в команде клиента; метка указывает на команду, которая вызва-
ла ошибку. Непомеченная форма используется в случае ошибки,
протокольного уровня, для которой нельзя указать команду, выз-
вавшую ошибку; это может также означать внутреннюю ошибку
сервера. Текстовое сообщение описывает условия.
Пример:
С: ...very long command line... (очень длинная командная строка)
S: * BAD Command line too long (команда слишком длинна)
С: ...empty line... (пустая стока)
S: * BAD Empty command line (пустая командная строка)
С: А443 EXPUNGE
S: * BAD Disk crash, attempting salvage to a new disk! (порча *
диска, попытка спастись на новом диске)
Сети передачи данных. Метод доступа 735
S: * OK Salvage successful, no data lost (спасение прошло ус-
пешно, данные не потеряны)
S: А443 OK Expunge completed (удаление завершено)
6.1.4. Отклик PREAUTH
Содержимое: опционный код отклика;
текст, читаемый человеком.
Отклик PREAUTH является всегда непомеченным и представ-
ляет собой одну из трех возможных реакций при установлении со-
единения. Он указывает, что для соединения уже выполнена аутен-
тификация, и команда LOGIN не нужна.
Пример: S: * PREAUTH IMAP4revl server logged in as Smith
6.1.5. Отклик BYE
Содержимое: опционный код отклика;
текст, читаемый человеком.
Отклик BYE является всегда непомеченным, он указывает, что
сервер намеривается разорвать соединение. При этом пользователю
может быть послано текстовое сообщение, проясняющее статус кли-
ента. Отклик BYE посылается при выполнении одного из четырех
условий:
1. Как часть нормальной процедуры logout. Сервер закроет со-
единение после отправки маркированного отклика ОК на команду
LOGOUT.
2. Как уведомление об аварийном прерывании сессии. Сервер
немедленно разрывает соединение.
3. Как уведомление о процедуре автоматического logout по причи-
не отсутствия активности. Сервер немедленно разрывает соединение.
4. Как одно из трех возможных сообщений при установлении
соединения, уведомляя, что сервер не может установить соединение с
данным клиентом. Сервер немедленно разрывает соединение.
Отличие между откликом BYE, который является частью обыч-
ной процедуры LOGOUT (первый вариант), и BYE при отказе (ос-
тальные три варианта), заключается в том, что соединение в после-
днем случае разрывается немедленно.
Пример: S: * BYE Autologout; idle for too long
736 Глава 4
6.2. Отклики сервера — сообщения о состоянии сервера и по*
чтового ящика
Эти отклики всегда не маркированы. Они служат для передача
статусной информации сервера и почтового ящика клиенту. Боль-
шинство этих откликов являются результатом команд, носящих то
же имя.
6.2.1. Отклик CAPABILITY
Содержимое: список возможностей.
Отклик CAPABILITY возникает в результате исполнения одно-
именной команды. Список возможностей, содержащийся в перечне
наименований, разделенных пробелами, характеризует функции, под-
держиваемые сервером. Список возможностей должен включать в
себя атом 'ТМАР 4.1”.
Имя возможности, которое начинается с ”AUTH=" указывает,
что сервер поддерживает данный механизм аутентификации. Дру-
гие наименования возможностей отмечают, что сервер поддерживает
расширение, модификацию или усовершенствования протокола IMAP
4.1. Отклик сервера должен соответствовать данному документу до <
тех пор, пока клиент использует команды, согласованные со спис- ;
ком возможностей.
Имена возможностей должны либо начинаться с ”Х", либо быть •
стандартными, либо соответствовать расширениям IMAP 4.1, модифи-
кациям или усовершенствованиям, зарегистрированным IANA. Сер-
вер не должен предлагать незарегистрированные или нестандартные
имена возможностей, если их имена не начинаются с символа "X".
Реализациям клиента не следует требовать каких-либо имея
возможностей, отличных от ”1МАР 4.1", они должны игнорировать
неизвестные имена возможностей.
Пример: S: * CAPABILITY IMAP4revl AUTH=KERBEROS_V4
XPIG-LATIN
6.2.2. Отклик LIST
Содержимое: атрибуты имени, иерархический разделитель, имя.
Отклик LIST посылается как результат команды LIST. Он воз*
вращает одно имя, которое соответствует спецификации LIST. До*
пускается несколько откликов LIST на одну команду.
Определено четыре атрибута имени:
Сети передачи данных. Метод доступа
737
\Noinferiors — Дочерние уровни иерархии не могут иметь то же
самое имя. Не существует дочерних уровней в настоящее
время, и они не могут быть созданы в будущем.
\Noselect — Не допускается использование данного имени для
выбираемого почтового ящика.
\Marked — Почтовый ящик помечен сервером как "interesting".
Почтовый ящик, вероятно, содержит сообщения, которые
добавлены со времени, когда почтовый ящик последний раз
был выбран.
\Unmarked — Почтовый ящик не содержит каких-либо дополни-
тельных сообщений, со времени, когда почтовый ящик
последний раз был выбран.
Если сервер не может определить, является ли почтовый ящик
’’интересным", или, если имя имеет атрибут \Noselect, сервер не дол-
жен посылать отклики \Marked или \Unmarked. Иерархическим
разделителем является символ, используемый для разграничения
уровней иерархии имен почтового ящика. Клиент может использо-
вать разделитель для формирования дочерних уровней в почтовом
ящике, а также для поиска в иерархической системе имен. Все до-
черние уровни верхнего уровня иерархии должны использовать один
и тот же тип разделителя. Иерархический разделитель NIL означа-
ет, что никакой иерархии нет.
Имя представляет собой однозначную иерархию (слева направо)
и должно быть пригодным для использования в качестве шаблона
командами LIST и LSUB. Если не использован атрибут \Noselect,
имя должно быть пригодно и в качестве аргумента команд, типа
SELECT, которые требуют ввода имени почтового ящика.
Пример: S: * LIST (\Noselect) ~/Mail/foo
6.2.3. Отклик LSUB
Содержимое: атрибуты имени, иерархический разграничитель, имя.
Отклик LSUB является результатом команды LSUB. Он возвра-
щает одно имя, которое соответствует спецификации LSUB. Допус-
кается несколько откликов на одну команду LSUB. Формат данных
идентичен используемому в отклике LIST.
Пример: S: * LSUB () "." #news.comp.mail.misc
Зак. № 3430 Семенов
738 Гпава 4
6.2.4. Отклик STATUS
Содержимое: имя, статусный список, заключенный в скобки.
Отклик STATUS является результатом команды STATUS. Он
возвращает имя почтового ящика, которое соответствует специфи-
кации STATUS, и запрашиваемую статусную информацию почтово-
го ящика.
Пример: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT
44292)
6.2.5. Отклик SEARCH
Содержимое: нуль или более чисел.
Отклик SEARCH является результатом команды SEARCH или
UID SEARCH. Числа относятся к тем сообщениям, которые отвеча- ч
ют критериям поиска. Для SEARCH это порядковые номера сооб-
щений, а для UID SEARCH - их уникальные идентификаторы. Чис-
ла отделяются друг от друга пробелами.
Пример: S: * SEARCH 2 3 6
6.2.6. Отклик FLAGS
Содержимое: список флагов, заключенный в скобки.
Отклик FLAGS является результатом команды SELECT или
EXAMINE. Список флагов, заключенный в скобки определяет фла-
ги (системные флаги), которые могут использоваться для данного
почтового ящика. Допускаются флаги, отличные от системных, это
зависит от реализации сервера. Отклик FLAGS должен записи*
ваться клиентом.
Пример: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
6.3. Отклики сервера - размер почтового ящика
Эти отклики являются немаркированными. Они передают от
сервера клиенту информацию об изменении размера почтового ящи-
ка. Число, которое следует за символом определяет количество
сообщений.
6.3.1. Отклик EXISTS
Содержимое: отсутствует.
Сеги передачи данных. Метод доступа 733
Отклик EXISTS сообщает о числе сообщений в почтовом ящике.
Этот отклик является результатом команды SELECT, EXAMINE или
изменения размера почтового ящика (например, получено новое почто-
вое сообщение). Отклик EXISTS должен регистрироваться клиентом.
Пример: S: * 23 EXISTS
6.3.2. Отклик RECENT
Содержимое: отсутствует.
Отклик RECENT сообщает число сообщений с флагами \Recent.
Этот отклик является результатом команды SELECT, EXAMINE
или изменения размера почтового ящика (например, получено новое
почтовое сообщение).
Замечание: Нельзя гарантировать, чтобы порядковые номера для
последних сообщений образовывали в почтовом ящике непрерыв-
ный ряд и являлись последними полученными п сообщениями (п -
число сообщений, объявленное откликом RECENT). Примерами,
когда складывается такая ситуация могут служить варианты: не-
сколько клиентов, имеют один и тот же открытый почтовый ящик;
или случай, когда сообщения в почтовом ящике переставлены не-
IMAP приложением.
Единственным способом идентифицировать последние сообще-
ния является рассмотрение флагов \Recent, или выполнение коман-
ды SEARCH RECENT. Информация отклика RECENT должна ре-
гистрироваться клиентом.
Пример: S: * 5 RECENT
6.4. Отклики сервера - статусные сообщения
Эти отклики являются немаркированными. Они несут информа-
цию о том, как сообщения доставляются от сервера к клиентам, и
возникают как результат работы одноименных команд. Сразу за
символом следует число, которое является порядковым номе-
ром сообщения.
6.4.1. Отклик EXPUNGE
Содержимое: отсутствует.
Отклик EXPUNGE уведомляет, сообщение с каким порядковым
номером удалено из почтового ящика. Порядковые номера после-
дующих сообщений немедленно уменьшаются на единицу.
24*
740 Гпава 4 4
Как результат этого немедленного уменьшения порядковых но-
меров следует рассматривать то, что порядковые номера сообщений,
появляющиеся при последующих командах EXPUNGE, зависят от
того, в каком порядке удаляются сообщения. Например, если после-
дние 5 сообщений в почтовом ящике с 9 сообщениями стерты, сер-
вер, удаляющий записи ’’снизу-вверх” пошлет 5 немаркированных
откликов EXPUNGE с номером 5, в то время как сервер, стирающий
записи ’’сверху вниз”, пошлет немаркированные отклики с номера-
ми 9, 8, 7, 6 и 5.
Отклик EXPUNGE не должен посылаться, когда не исполняется
никакая команда, или при отклике на команды FETCH, STORE или
SEARCH. Это правило необходимо, чтобы предотвратить потерю
синхронизации нумерации для клиента и сервера.
Информация отклика EXPUNGE должна регистрироваться кли-
ентом.
Пример: S: * 44 EXPUNGE
6.4.2. Отклик FETCH
Содержимое: текст сообщения.
Отклик FETCH возвращает данные о сообщении клиенту. Дан-
ные сформированы в группы из имени элемента и его значения в
скобках. Этот отклик является следствием команды FETCH или
STORE, а также одностороннего решения сервера (например, об из-
менении флагов). В настоящее время существуют следующие ин-~
формационные элементы:
BODY Форма BODYSTRUCTURE без расширения данных.
BODY[<ceкция>]«нaчaльный_oктeт»
Строка, отражающая содержимое специфицированной секции.
Строка должна интерпретироваться клиентом согласно транспорт-
ной кодировке, типу и субтипу тела.
Если специфицирован начальный октет, то это субстрока полно-
го содержимого тела, начинающаяся с заданного октета. Это озна-
чает, что BODY[]<0> может быть укорочено, но BODY[] никогда нс
укорачивается.
Если идентификатор [CHARSET] является частью списка пара;
метров тела секции, допустимы 8-битовые текстовые данные. За-
метьте, что заголовки (спецификаторы частей HEADER, MIME или
часть заголовка секции MESSAGE/RFC822), должны содержать толь-
сети передачи данных. Метод доступа
741
к0 7-битовые символы (применение 8-битовых символов в заголов-
ке запрещено). Заметим также, что пустая строка в конце заголов-
ка всегда включается в текст заголовка.
Нетекстовые данные, такие как двоичные, должны передаваться
закодированными в текстуальной форме, например в формате BASE64.
Чтобы получить исходные двоичные данные, клиент должен деко-
дировать полученную последовательность,
BODYSTRUCTURE — список, заключенный в скобки, который
описывает [MIME-IMB] структуру тела сообщения. Эта структуру
вычисляется сервером при разборе полей заголовка [MIME-IMB],
подставляя при необходимости значений по умолчанию.
Например, простое текстовое сообщение из 48 строк и 2279 ок-
тетов может иметь структуру тела: ("TEXT’’ ’’PLAIN" ("CHARSET"
"US-ASCII") NIL NIL "7BIT" 2279 48)
Если имеется несколько частей, они выделяются вложенными
скобками. Вместо типа тела в качестве первого элемента списка
используется тело с иерархической структурой. Вторым элементом
списка, заключенным в скобки, является составной субтип (mixed,
digest, parallel, alternative, и т.д.).
Например, сообщение из двух частей, включающее в себя текст и
приложение, закодированное в BASE64, может иметь структуру тела:
(("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152
23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
"<960723163407.20117h@cac.washington.edu>" "Compiler diff"
"BASE64" 4554 73) "MIXED"))
Данные расширения следуют за составным субтипом. Эти дан-
ные никогда не присылаются при доставке тела, но могут быть
доставлены с помощью BODYSTRUCTURE. Данные расширения, если
они присутствуют, должны иметь следующий формат:
Список параметров тела, заключенный в скобки.
Список содержит пары атрибут/значение [например, ("foo" "bar"
'baz" "rag"), где "bar" представляет собой значение "foo", a "rag"
является значением "baz"] как это определено в [MIME-IMB].
Размещение тела
Список, заключенный в скобки, состоящий из строки типа раз-
мещения, за которой следует список пар атрибут/значение. Имена
типов размещения и атрибутов будут определены в будущих стан-
дартах.
Язык тела
Строка или список в скобках, определяющие язык, так как это
задано в [LANGUAGE-TAGS].
742 Гпава 4
Любое из последующих расширений данных в этой версии про-
токола не определено. Такие расширения могут состоять из нуля
или более NIL-строк, чисел, или вложенных списков таких данных,
заключенных в скобки. Реализации клиента, которые осуществля-
ют доставку BODYSTRUCTURE, должны быть готовы принять та-
кие расширения данных. Реализации сервера не должны посылать
подобные расширения, до тех пор, пока они не войдут в новую вер-
сию протокола. Базовые поля несоставной части тела размещаются
в следующем порядке:
Тип тела
Строка, описывающая имя типа содержимого, как это определе-
но в [М1МЕ-1МВ].
Суб тип тела
' Строка, описывающая имя субтипа, как это определено в [MIME-
1МВ].
Список параметров тела, заключенный в скобки
Список пар атрибут/значение, заключенный в скобки, [например,
(”foo” ’’bar’’ ”baz” ”rag”), где ’’bar’’ является значением ’’foo’’, а
"rag” - значением "baz”], как это описано в [М1МЕ-1МВ].
Идентификатор тела
Строка, описывающая идентификатор содержимого, как это оп-
ределено в [М1МЕ-1МВ].
Описание тела
Строка, предоставляющая описание содержимого, как это задано
в [М1МЕ-1МВ].
Шифрование тела
Строка, предоставляющая транспортную кодировку, как это за-
дано в [М1МЕ-1МВ].
Размер тела
Число, указывающее размер тела в октетах. Заметьте, что этот
размер характеризует длину тела с учетом транспортного кодирова-
ния. Размер исходного текста может быть иным.
Тип тела MESSAGE и субтип RFC822 сразу после базовых полей
содержат структуру заголовка, структуру тела и размер вложенного
сообщения в строках.
Тип тела TEXT сразу после базовых полей содержит размер тела
в строках. Заметьте, что этот размер отражает размер фрагмента
после выполнения транспортного кодирования.
Данные расширения следуют после базовых полей и полей, пере*
численных выше и зависящих от типа,. Эти расширения никогда не
транспортируются при передаче тела, но могут быть пересланы при
Сети передачи данных. Метод доступа 743
—
доставке BODYSTRUCTURE. Данные расширения, если они присут-
ствуют, должны быть упорядочены.
расширения для несоставной части тела располагаются в следу-
ющем порядке:
MD5 тела
Строка, содержащая значение MD5 тела, как это описано в [MD5].
Размещение тела
Список, заключенный в скобки, с тем же содержимым и функци-
ями, что и размещение тела для составной части тела.
Язык тела
Строка или список, заключенный в скобки, определяющие язык
тела, как это задано в [LANGUAGE-TAGS],
ENVELOPE. Список, заключенный в скобки, который описыва-
ет структуру заголовка (конверта) сообщения. Он вычисляется сер-
вером в результате разбора заголовка [RFC-822], при необходимос-
ти некоторым полям присваиваются значения по умолчанию.
Поля структуры конверта размещаются в следующем порядке:
дата, subject (предмет сообщения), from (от), отправитель, reply-to
(ответ на), to, сс, bcc, in-reply-to (в ответ на), и идентификатор сооб-
щения. Поля дата, subject, in-reply-to и идентификатор сообщения
являются строками. Поля from, отправитель, reply-to, to, сс и Ьсс
являются списками адресных структур, заключенными в скобки.
Адресная структура представляет собой список, который описы-
вает электронный почтовый адрес. Поля адресной структуры разме-
щаются в следующем порядке: персональное имя, [ЭМТР]@-домен
(маршрут отправителя), имя почтового ящика и имя ЭВМ.
Синтаксис группы [RFC-822] определяется специальной формой
адресной структуры, в которой поле имени ЭВМ равно NIL. Если
поле имени почтового ящика также равно NIL, это является кон-
цом группового маркера (двоеточие в синтаксисе RFC 822). Если
поле имени почтового ящика не равно NIL, это обозначает начало
группового маркера, а поле имени почтового ящика содержит имя
группы.
Любое поле в конверте или адресной структуре, которое не ис-
пользуется, характеризуется значением NIL. Заметим, что сервер дол-
жен заполнять по умолчанию поля reply-to и sender из поля from.
FLAGS — Список флагов, установленных для данного
сообщения, заключенный в скобки.
INTERNALDATE — Строка, представляющая внутреннюю дату
сообщения.
RFC822 — Эквивалент BODY[].
RFC822.HEADER — Эквивалент BODY.PEEK[HEADER].
744
Гпава 4
RFC822.SIZE — Число, выражающее размер сообщения [RFC-822].
RFC822.TEXT — Эквивалент BODY[TEXT].
UID — Число, определяющее уникальный идентификатор
сообщения.
Пример: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
6.5. Отклики сервера — запрос продолжения команды
Отклик на запрос продолжения команды вместо метки выделя-
ется символом ”+”. Эта форма отклика указывает на то, что сервер
готов принять продолжение команды от клиента. Остальная часть
этого отклика имеет текстовую форму.
Этот отклик используется командой AUTHORIZATION, для того
чтобы передать данные от сервера клиенту, и запросить дополни-
тельные данные у клиента. Этот отклик применяется также, если
аргументом какой-то команды является литерал.
Клиенту не позволено посылать литеральные октеты, если толь-
ко сервер в явной форме не запросил их. Это позволяет серверу
обрабатывать команды и отвергать ошибки строчка за строчкой.
Остальная часть команды, включая CRLF, завершающие команду,
следует за октетами литерала. Если имеются какие-либо дополни-
тельные аргументы команды, за литеральными октетами следует
пробел, после чего передаются аргументы.
Пример: С: А001 LOGIN {11}
S: + Ready for additional command text (готов к приему
дополнительного командного текста)
С: FRED FOOBAR {7}
S: + Ready for additional command text
C: fat man
S: A001 OK LOGIN completed
С: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP"
(не существует такой команды)
7. Пример соединения IMAP 4.1
Последующее является записью для соединения IMAP 4.1 (дан-
ный пример и нижеприведенное описание синтаксиса практически
без изменения взято из документа RFC-2060).
S: * OK IMAP4revl Service Ready
С: aOOl login mrc secret
S: aOOl OK LOGIN completed
C: a002 select inbox
Сети передачи данных. Метод доступа
745
S; * 18 EXISTS
S; * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 2 RECENT
S: * OK [UNSEEN 17] Message 17 is the first unseen message
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full
S; * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996
02:44:25 -0700"
RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700
(PDT)"
"IMAP4revl WG mtg summary and minutes"
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
((NIL NIL "imap" "cac.washington.edu"))
((NIL NIL "minutes" "CNRI.Reston.VA.US")
("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
"<B27397-0100000@cac.washington.edu>”)
BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL
"7BIT" 3028 92))
S: a003 OK FETCH completed
C: a004 fetch 12 body[header]
S: * 12 FETCH (BODY[HEADER] {350}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: Terry Gray gray@cac.washington.edu
S: Subject: IMAP4revl WG mtg summary and minutes
S: To: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA.US, John Klensin
KLENSIN@INFOODS.MIT.EDU
S: Message-Id: B27397-0100000@cac.washington.edu
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S: )
S: a004 OK FETCH completed
C: a005 store 12 +flags \deleted
S: * 12 FETCH (FLAGS (\Seen \Deleted))
8: a005 OK +FLAGS completed
C: a006 logout
8: * BYE IMAP4revl server terminating connection
S: a006 OK LOGOUT completed
746 Гпава 4
8. Формальный синтаксис
Последующая синтаксическая спецификация использует нота-
цию Бакуса-Наура (BNF -Backus-Naur Form), как это описано в
[RFC-822] с одним исключением, разделителем, используемым в
конструкции "#”, служит одиночный пробел (SPACE), а не одна или
более запятых.
В случае альтернативных или опционных правил, где последую-
щее правило перекрывается с более ранним, преимущество имеет
правило, встретившееся первым. Некоторые, но не все случаи таких
правил представлены ниже. Если не указано обратного, все буквен- ?
ные записи не зависят от использования строчных или прописных
букв. Конкретные программные реализации должны воспринимать *
такие строки при любом написании.
address addr_name SPACE addr_adl SPACE addr_mailbox
SPACE addr_host ”)”
addr_adl ::= nstring
;; Хранит маршрут из route-addr [RFC-822], если не равно нулю
addr_host ::= nstring
;; NIL указывает на синтаксис группы [RFC-822],
;; В противном случае, содержит имя домена [RFC-822] <
addr_mailbox nstring
;; NIL индицирует конец группы [RFC-822]; если не NIL, a addr_host .
;; равен NIL, содержит имя группы ;; [RFC-822],
;; В противном случае, содержит локальную часть [RFC-822]
addr^name :: = nstring
;; Содержит фразу из почтового ящика [RFC-822], если не NIL i •
alpha ”А” / ”В" / "С" / "D" / "Е” / "F” / "G" / "Н" /
’’I" / ”J” / ”К" / "L” / ”М" / "N" / "О" / "Р" / "Q” / "R” /
"S" I ..т.. ! ..-у.. ! ..у.. I ..w.. I ..х.. !
"Y" / "Z" I
"а" / "b" / "с" I ”d” / "e" / "f" / "g” I "h" I
,''i" I "j" I ”k" / "1" I "m" / ”n" / "o" / ”p” /
”q" / "r" / "s" I "t" / "u" / ”v" / ”w” / "x" / ”y” / "z" '
;; Чувствительно к набору строчными или прописными буквами
append "APPEND” SPACE mailbox [SPACE flagjist] [SPACE i
date_time] SPACE literal $
astring atom / string
atom ::= 1*ATOM_CHAR
ATOM_CHAR ::= <any CHAR except atom_specials>
atom_specials ::= ”(” / ”)” / ”{” / SPACE / CTL /
list_wildcards / quoted_specials
Сети передачи данных. Метод доступа
747
authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)
auth_type ::=atom
;; Определено в [IMAP-AUTH]
base64 *(4base64_char) [base64_terminal]
base64_charalpha I digit / ”+" / "/"
base64Jerminal (2base64_char ’’==") / (3base64_char ”==”)
body ”(’’ body_type_lpart / body_type_mpart ”)”
body_extension ::= nstring / number / ”(” 1 #body_extension ”)”
;; Будущее расширение. Реализации клиента должны воспринимать
;; поля body_extension. Реализации сервера не должны генерировать
;; поля body_extension, за исключением случаев, закрепленных в
;; будущих стандартах или зарегистрированных модификациях уже
;; существующих норм.
body_ext_lpart ::= body_fld_md5 [SPACE body_fld_dsp
[SPACE body_f Id Jang
[SPACE l#body_extension]]]
;; не должны присылаться при non-extensible доставке "BODY"
bodyextmpart body_fld_param
[SPACE body J ld_dsp SPACE bodyJldJang
[SPACE l#body_extension]]
;; MUST NO be returned on non-extensible "BODY" fetch
— nstring
:== "(" string SPACE body_fld_param ")" / nil
:= (<"> ("7BIT” / "8BIT" / "BINARY" /
= nstring / "(” l#string ”)”
= number
= nstring
= number
= "(" l#(string SPACE string) ")" / nil
= (body_type basic / bodyJype_msg /
'body fields : := body_fld_param SPACE bodyJldJd SPACE
body fld_desc SPACE bodyJld_enc SPACE bodyJld_octets
body fld_desc
body_fld_dsp
body fld_enc
"BASE64"/
’’QUOTED-PRINTABLE") <">) / string
body fidJd nstring
body fid lang
body_fld_lines
body_fld_md5
bodyJld_ octets
bodyjldjparam
b°dy_type_lpart
body_typejext)
[SPACE body. ext lpart]
body_type_basic : := mediaJjasic SPACE body_fields
субтип MESSAGE не должен следовать "RFC822"
k°dyJypempart : := 1 *body SPACE media_subtype
748
Гпава 4
[SPACE bodyextmpart]
body_type_msg : := media_message SPACE body_fields SPACE
envelope
SPACE body SPACE body_fId_lines
body_type_text ::« media_text SPACE body_f ields SPACE
body_fld_lines
capability ::= "AUTH=" auth_type / atom
;; Новая возможность должна начинаться с "X" или быть зарегист-
;; рирована IANA в качестве стандарта или являться усовершен-
;; ствованием существующего стандарта
capability_data "CAPABILITY” SPACE [l#capability SPACE]
"IMAP4revl"
[SPACE incapability]
;; серверы IMAP 4.1, которые предлагают совместимость c RFC 1730
;; должны включать ’’IMAP4” в список возможностей этой реализации
CHAR <any 7-bit US-ASCII character except NUL, 0x01 —
0x7f>
CHAR8 ::= <any 8-bit octet except NUL, 0x01 — Oxff>
command ::= tag SPACE (command any / command_auth /
command_nonauth / command—select) CRLF
;; Modal based on state
command_any ::== "CAPABILITY” / "LOGOUT” / *’NOOP" /
x_command
;; Справедливо для всех состояний
command_auth ::== append / create / delete / examine / list / Isub
I
rename / select / status / subscribe / unsubscribe
;; Работает только в состояниях Authenticated или Selected
command_nonauth::= login / authenticate
;; Работает только в состоянии Non-Authenticated
commandjselect ::= "CHECK" / "CLOSE" / "EXPUNGE" / copy /
fetch I store / uid I search
;; Работает только в состоянии Selected
continue req ::=» "+" SPACE (resp_text / base64)
copy ::= "COPY" SPACE set SPACE mailbox
CR ::=<ASCIICR, carriage return, 0x0D> 1
create ::= "CREATE" SPACE mailbox
;; Использование INBOX не приводит к ошибке
CRLF CR LF
CTL ::= <any ASCII control character and DEL, 0x00 — Oxlf, 0x7f>
date date_text / <"> date_text <">
date_day :: = 1 *2digit
Сети передачи данных. Метод доступа
749
.. День месяца
date_day_fixed ::= (SPACE digit) / 2digit
.. Версия с фиксированным форматом date_day
date_month ::= ’’Jan” I "Feb” I "Mar" I "Apr” I "May" I "Jun" I
’Jul’’ I "Aug" / "Sep? I "Oct" / "Nov" / "Dec"
datejtext date_day date_month "-" date_year
date__year 4digit
datetime <”> date_day_fixed date_month "-" date_year
SPACE time SPACE zone <’’>
delete ::== "DELETE" SPACE mailbox
;; Использование INBOX не приводит к ошибке
digit ::= "О" / digit_nz
digit.nz ::= "1" I "2" / "3" / "4" / "5" / ”6" / "7" / ’’8" /
"9 ’’
envelope ’’(’’ env_date SPACE env_subject SPACE env_from
SPACE env sender SPACE env_reply_to SPACE envto SPACE envcc
SPACE envbcc SPACE env_in_reply_to
SPACE env_message_id ”)”
env_bcc ::= ’’(’’ l*address ")” / nil
envcc ::= ’’(’’ l*address ”)” / nil
env_date :: = nstring
env_from "(" l*address ”)” / nil
env_in_reply_to
env_message_id
env_reply_to
:= nstring
:= nstring
:= "(” l*address ")" / nil
env_sender ”(" l*address ”)” / nil
env subject nstring
envto "(" l*address ’’)” / nil
examine "EXAMINE" SPACE mailbox
fetch "FETCH” SPACE set SPACE (’’ALL” I ’’FULL" / "FAST” /
fetch_att / "(" l#fetch_att ")’’)
fetch_att "ENVELOPE” I "FLAGS” / ”INTERNALDATE" /
"RFC822" [".HEADER" / ".SIZE" / ’’.TEXT’’] /
"BODY" ["STRUCTURE"] / "UID" / "BODY" [".PEEK"] section ["<"
number "." nz_number ">"]
Bag ::== "\Answered” / "\Flagged" / "\Deleted" I "\Seen" /
\Draft" / flag_keyword I flag_extension
Bag^extension "\" atom
’’ будущее расширение. Реализации клиента должны воспринимать
м флаги flag_extension. Реализации сервера не должны генерировать
» Флаги flag_extension, за исключением случаев, определенных в
750
Гпава 4
;; будущих стандартах или зарегистрированных модификациях
;; данной спецификации.
flag_keyword atom
flag_list ::= "(" #flag ’’)”
greeting SPACE (resp_cond_auth I resp_cond_bye) CRLF
header_fld_name astring
header_list ”(” l#header_fld_name ”)”
LF : <ASCII LF, line feed, OxOA>
list ’’LIST” SPACE mailbox SPACE list_mailbox
list_mailbox ::= 1*(ATOM_CHAR I list_wildcards) / string
list_wildcards ::= ”%’’ /
literal number ”}’’ CRLF *CHAR8
;; Число характеризует количество октетов CHAR8
login ’’LOGIN” SPACE userid SPACE password
Isub ::= ”LSUB” SPACE mailbox SPACE list_mailbox
mailbox ’’INBOX" / astring
;; INBOX не чувствителен к использованию строчных или
;; прописных букв. Все версии написания INBOX (напр., ’’iNbOx”)
;; должны интерпретироваться как INBOX, а не как строку.
mailbox_data ’’FLAGS” SPACE flagjist / ’’LIST” SPACE
mailbox_list /
”LSUB” SPACE mailbox_list / ’’MAILBOX” SPACE text /
’’SEARCH” [SPACE l#nz_number] I "STATUS” SPACE mailbox
SPACE
”(’’ #<status_att number ’’)” I number SPACE "EXISTS” / number
SPACE ’’RECENT”
mailbox—list ::= ”(” #(’’\Marked” / ”\Noinferiors” / ”\Noselect” /
”\Unmarked” / flag_extension) ’’)” SPACE (<”> QUOTEDCHAR <”>
I nil) SPACE mailbox
media_basic ::= (<’’> (’’APPLICATION” / ’’AUDIO” / ’’IMAGE” /
’’MESSAGE” / ’’VIDEO”) <”>) / string) SPACE media_subtype
;; Определено в [MIME-IMT]
media message ::= <”> ’’MESSAGE” <’’> SPACE <”> ’’RFC822”
;; Определено в [MIME-IMT]
media_subtype ::= string 5
;; Определено в [MIME-IMT]
media_text ::= <”> ’’TEXT" <”> SPACE media_subtype >
;; Определено в [MIME-IMT]
message_data nz_number SPACE ("EXPUNGE” / ("FETCH”
£ети передачи Данных. Метод доступа
751
SPACE msg_att))
insg_att ::= "(" 1#("ENVEIX)PE" SPACE envelope /
•FLAGS” SPACE "(" #(flag I "\Recent") ")" / "INTERNALDATE"
SPACE date_time I
RFC822" [".HEADER" / ".TEXT"] SPACE nstring /
"RFC822.SIZE" SPACE number /
"BODY” ["STRUCTURE"] SPACE body / "BODY" section ["<" number
">"] SPACE nstring I
"UID” SPACE uniqueid)")”
nil ::= "NIL"
nstring ::= string / nil
number ::= l*digit
;; 32-битное целое число без знака (0 <= п < 4,294,967,296)
nz_number ::= digit_nz *digit
;; 32-битное не ранное нулю целое число без знака (0 < п <
4,294,967,296)
password ::= astring
quoted <"> *QUOTED_CHAR <">
QUOTED_CHAR ::= <any TEXT_CHAR except quoted_specials> I
"\" quotedjspecials
quoted_specials ::= <"> / "\"
rename ::= "RENAME" SPACE mailbox SPACE mailbox
;; Использование INBOX в качестве места назначения не дает ошибки
response ::= *(continue_req / response_data) response_done
response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
mailbox data / message_data I capability_data) CRLF
response_done ::= response_tagged / response_fatal
response_fatal ::= "*" SPACE resp_cond_bye CRLF
;; Сервер закрывает соединение немедленно
response_tagged : := tag SPACE resp_cond_state CRLF
resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text
;; Условие аутентификаций
resp_cond_bye "BYE" SPACE resp_text
resp cond state ("OK" I "NO" / "BAD") SPACE resp_text
;; Условие состояния
resp text ["[" resp_text_code "]" SPACE] (text/_mime2 I text)
;; текст не должен начинаться с "[" или "="
resp_text_code ::= "ALERT" / "PARSE" /
"PERMANENTFLAGS" SPACE "(” #(flag / "\*") ")" / "READ-
ONLY" / "READ-WRITE" / "TRYCREATE" / "UIDVALIDITY"
SPACE nz_number / "UNSEEN" SPACE nz_number /
atom [SPACE l*<any TEXT_CHAR except ”]">]
752
Гпава 4
search ::= "SEARCH" SPACE ["CHARSET" SPACE astring
SPACE] l#search_key
;; Символьный набор [CHARSET] должен быть зарегистрирован
IANA
search_key "ALL" / "ANSWERED" / "BCC" SPACE astring /
"BEFORE" SPACE date I "BODY" SPACE astring /
"CC" SPACE astring / "DELETED" / "FLAGGED" / "FROM" SPACE .
astring /
"KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /
"ON" SPACE date / "RECENT" / "SEEN" /
"SINCE" SPACE date / "SUBJECT" SPACE astring I
"TEXT" SPACE astring / "TO" SPACE astring /
"UNANSWERED" I "UNDELETED" / "UNFLAGGED" /
"UNKEYWORD" SPACE flag-keyword / "UNSEEN" /
;; Выше этой строки все соответствует [IMAP2]
"DRAFT" I "HEADER" SPACE header_fld_name SPACE astring /
"LARGER" SPACE number I "NOT" SPACE search_key /
"OR" SPACE search key SPACE search key /
"SENTBEFORE" SPACE date / "SENTON" SPACE date /
"SENTSINCE" SPACE date / "SMALLER" SPACE number /
"UID" SPACE set / "UNDRAFT" / set / "(" l#search_key ")"
section ::= "[" [section text / (nz_number *["." nz_number] ["."
(section text / "MIME")])] "]"
section_text "HEADER" / "HEADER.FIELDS" [".NOT"] SPACE
headerjist / "TEXT"
select ::= "SELECT" SPACE mailbox
sequence num ::= nz number I "*"
;; * является наибольшим используемым числом. Для порядковых
;; номеров сообщений оно равно количеству сообщений в почтовом
;; ящике. Для уникальных идентификаторов оно равно уникальному
;; идентификатору последнего сообщения в почтовом ящике,
set sequence_num / (sequence_num ":" sequence_num) / (set
"," set)
;; Идентифицирует набор сообщений. Для порядковых номеров
;; сообщений это последовательность чисел с 1 до числа сообщений в
;; почтовом ящике.
;; Запятая разграничивает индивидуальные номера, двоеточие
;; указывает на диапазон чисел включительно. Пример для
;; почтового ящика с 15 сообщениями: 2,4:7,9,12:* эквивалентно
;; 2,4,5,6,7,9,12,13,14,15.
Сети передачи данных. Метод доступа
753
SPACE : :== <ASCII SP, space, 0x20>
status ::= "STATUS" SPACE mailbox SPACE "(" l#status_att ")"
status_att ::= "MESSAGES" / "RECENT" / "UIDNEXT" /
"UIDVALIDITY" I
"UNSEEN"
store ::= "STORE" SPACE set SPACE store_att_flags
store_att_flags ::= (["+" / "FLAGS" [".SILENT”]) SPACE
(flagjist / #flag)
string quoted / literal
subscribe ::= "SUBSCRIBE" SPACE mailbox
tag l*<any ATOM_CHAR except "+">
text 1*TEXT_CHAR
text_mime2 ::== ”=?" <charset> "?” <encoding> ”?” <encoded-text>
"?="
;; Синтаксис определен в [MIME-HDRS]
TEXT CHAR ::= <any CHAR except CR and LF>
time 2digit 2digit ":" 2digit
;; Часы, минуты, секунды
uid "UID" SPACE (copy / fetch I search / store)
;; Уникальные идентификаторы используются вместо
;; последовательных номеров сообщения,
uniqueid nz_number
;; В возрастающем порядке
unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox
userid astring
x command ::= "X" atom Experimental command arguments>
zone ::= ("+" / "-") 4digit
;; Число из 4 цифр co знаком hhmm, представляющее часы и минуты
;; к западу от Гринвича
;; (Это число отличается от Universal Time). Вычитая временную
;; зону из данного времени,
;; можно получить форму UT. Зона Universal Time равна "+0000".
Библиография
[АСАР] Myers, J. "АСАР — Application Configuration Access Protocol",
Work in Progress.
[CHARSET] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC/Information Sciences Institute, October 1994.
[DISPOSITION] Troost, R., and Domer, S., "Communicating Presentation
Information in Internet Messages: The Content-Disposition Header",
RFC 1806, June 1995.
754
Гпава 4
[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.
Carnegie-Mellon University, December 1994.
[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC
2061, University of Washington, November 1996.
[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected
IMAP4 Clients", Work in Progress.
[IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2
and IMAP2bis”, RFC 1732, University of Washington, December
1994.
[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in IMAP4",
RFC 1733, University of Washington, December 1994.
[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol — Obsolete
Syntax", RFC 2062, University of Washington, November 1996
[IMAP2] Crispin, M., "Interactive Mail Access Protocol — Version 2", RFC
1176, University of Washington, August 1990.
[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.
[MD5] Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC 1864,
October 1995.
[MIME-IMB] Freed,N.,and N. Borenstein,"MIME(Multipurpose Internet
Mail Extensions) Part One: Format of Internet Message Bodies", RFC
2045, November 1996.
[MIME-IMT] Freed,N.,and N. Borenstein,"MIME(Multi purpose Internet Mail
Extensions) Part Two: Media Types", RFC 2046, November 1996.
[MIME-HDRS] Moore,K.,"*MIME(Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", RFC
2047, November 1996.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, University of Delaware, August 1982.
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/
Information Sciences Institute, August 1982.
[UTF-7]Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe Transformation
Format of Unicode", RFC 1642, July 1994.
Сети передачи данных. Метод доступа
755
4.4.15. Сетевой протокол времени (NTP V.3)
Время - самый важный и невосполнимый ресурс любого челове-
ка. Проблема эта занимала людей всегда, и уже более 4 тысяч лет
люди пытаются как-то упорядочить учет расходования этого ресур-
са, создавая различные календарные системы и устройства измере-
ния времени. Календарные системы древнего мира отражали сельс-
кохозяйственные, политические и ритуальные нужды, характерные
для того времени. Астрономические наблюдения для установления
зимнего и летнего солнцестояния производились еще 4000 лет тому
назад. Проблема создания календаря возникала только в обще-
ствах, где государственная стабильность поддерживалась в течение
достаточно долгого времени (Китай, Египет, государство Майя). В
14-ом столетии до рождества христова в Китае была определена
длительность солнечного года — 365.25 дней, а лунный месяц —
29.5 дней. Солнечно-лунный календарь действовал на ближнем
востоке (за исключением Египта) и в Греции, начиная с 3-го тыся-
челетия до нашей эры. Ранние календари использовали либо 13
лунных месяцев по 28 дней или 12 месяцев с чередующейся протя-
женностью 29 и 30 дней.
Древнеегипетский календарь имел 12 30-дневных лунных меся-
цев, но был привязан к сезонному появлению звезды Сириус (Sirius
- Sothis). Для того чтобы примирить этот календарь с солнечным
годом, был изобретен гражданский календарь, в котором добавлено
5 дней, доводящих длительность года до 365 дней. Однако со време-
нем было замечено, что гражданский год примерно на одну четверть
дня короче, чем солнечный год. Выбранная длительность года обес-
печивала прлное совпадение с солнечным годом раз за 1460 лет.
Этот период называется циклом Сотиса (Sothic-цикл). Также как и
Shang Chinese, древние египтяне установили длительность солнеч-
ного года равной 365,25 дней, что с точностью 11 минут совпадает с
результатами современных вычислений. В 432 году до рождества
Христа, около столетия после китайцев греческий астроном Метон
вычислил, что 110 лунных месяцев по 29 дней и 125 лунных меся-
цев по 30 дней соответствуют 6940 солнечным дням, что лишь
немногр превышает 19 лет. 19-летний цикл, названный циклом
Метона, установил длительность лунного месяца равной 29,532 сол-
нечных дней, что с точностью 2 минут совпадает результатами со-
временных измерений.
В древнем Риме использовался лунный календарь. Юлий Це-
зарь пригласил александрийского астронома Сосигенса, который раз-
работал календарь (который по понятным, причинам стал назы-
756
Гпава 4
ваться юлианским), принятый в 46 году до Рождества Христова.
Календарь содержал 365 дней в году с добавлением одного дня
каждые 4 года. Однако первые 36 лет по ошибке дополнительный
день добавлялся каждые три года. В результате набежало лишних
три дня, которые пришлось компенсировать вплоть до 8 года нашей
эры.
Семидневная неделя была введена лишь в четвертом столетии
нашей эры императором Константином I.
Во время романской эры 15-летний цикл переписи использовал-
ся при исчислении налогов. Последовательность имен дней недели
воспроизводится через 28 лет, этот период называется солнечным
циклом. Таким образом, учитывая 28-летний солнечный цикл, 19-
летний цикл Метона и 15-летний переписи, получаем суперцикл
протяженностью 7980-лет, называемый юлианской эрой, которая
начинается в 4713 году до рождества христова.
К 1545 году расхождение между юлианским календарем и сол-
нечным годом достигло 10 дней. В 1582, астрономы Кристофер
Клавиус и Луиджи Лилио предложили новую схему календаря. Папа
Грегорий XIII выпусти указ, где среди прочего указывалось, что в
году содержится 365,2422 дней. Для того чтобы более точно апп-
роксимировать эту новую величину, только столетние годы, которые
делятся без остатка на 400, объявляются високосными, что предпо-
лагает длительность года 365,2425 дней. В настоящее время григо-
рианский календарь принят большинством стран мира.
Для того чтобы мерить расширение вселенной или распад про-
тона необходимо иметь стандартную схему нумерации дней. По ре-'
шению Международного астрономического Союза был принят стан-
дарт на секунду и юлианская система нумерации дней (JDN). Стан-
дартный день содержит 86,400 стандартных секунд, а стандартный"’
год состоит из 365,25 стандартных дней.
В схеме (JDN), предложенной в 1583 французским ученым Джо-
зефом Юлиусом Скалигером, JDN 0.0 соответствует 12 часам (пол-
день) первого дня юлианской эры — 1 января 4713 до нашей эры.
Годы до нашей эры подсчитываются согласно юлианскому календа-
рю, в то время как годы нашей эры нумеруются по григорианскому
календарю. 1 января 1 года после рождества христова в григориан-
ском календаре соответствует 3 января 1 года юлианского кален-
даря [DER90], в JDN 1.721.426,0 день соответствует 12 часам пер-
вого дня нашей эры.
Калиброванный эталон времени, например, атомные часы, довольно
сложное и дорогостоящее устройство, требующее квалифицирован-
ного обслуживания. По этой причине многие пользователи не мо-А
Сети передачи данных. Метод доступа
757
гут позволить себе такие издержки и вынуждены обращаться к
услугам удаленных эталонов. Это может быть первичный эталон,
размещенный где-то в локальной сети, или радио-часы. Условия
доступа к сети уже предполагают наличие определенной дисперсии
для времени доставки калибровочной информации. Если же эталон
размещен далеко в Интернет, значения задержки и дисперсии могут
возрасти многократно. Для обеспечения большей надежности ка-
либровки обычно используют несколько эталонов, а для снижения
влияния временных разбросов привлекают довольно сложные алго-
ритмы усреднения.
Сетевой протокол задания времени NTP (Network Time Protocol;
Network Time Protocol Version 3 Specification, Implementation and
Analysis, David L. Mills, RFC1305.pdf, March 1992) служит для осу-
ществления синхронизации работы различных процессов в серверах
и программах клиента. Он определяет архитектуру, алгоритмы, объек-
ты и протоколы, используемые для указанных целей. NTP был
впервые описан в документе RFC-958 [MIL85c], но с тех пор не-
сколько раз переделан и усовершенствован (RFC-1119 [MIL89]).
Протокол использует для транспортных целей UDP [POS80]. Це-
лью протокола является обеспечение максимально возможной точ-
ности и надежности, несмотря на значительный разброс задержек
при прохождении через большое число промежуточных маршрути-
заторов.
Протокол NTP обеспечивает механизмы синхронизации с точ-
ностью до наносекунд. Протокол предлагает средства для определе-
ния характеристик и оценки ошибок локальных часов и временно-
го сервера, который осуществляет синхронизацию. Предусмотрены
возможности работы с иерархически распределенными первичными
эталонами, такими как синхронизуемые радио-часы.
Точность, достижимая с помощью NTP, сильно зависит от точнос-
ти локальных часов и характерных скрытых задержек. Алгоритм
коррекции временной шкалы включает в себя учет задержек, коррек-
цию частоты часов и ряд механизмов, позволяющих достичь точнос-
ти порядка нескольких миллисекунд, даже после длительных перио-
дов, когда потеряна связь с синхронизирующими источниками.
Существует ряд механизмов в Интернет, которые позволяют пере-
давать и записывать время, когда произошло какое-то событие. Это
протокол Daytime [POS83a], Time Protocol [POS83b], сообщения ICMP
«временная метка» [DAR81b] и опция IP «временная метка» [SU81].
Маршрутный протокол Fuzzball [MIL83b], иногда называемый
Hellospeak, встраивает синхронизацию непосредственно в алгоритм
Маршрутного протокола. Он не является протоколом из стека IP.
758
Гпава 4
Юниксовский (4.3bsd) времязадающий демон [GUS85a] измеря-
ет временные сдвиги различных клиентских процессов и рассылает
им соответствующие поправки.
В этой модели сервер определен с помощью алгоритма выбора
[GUS85b], который исключает ситуации, где сервер не выбран или
выбрано более одного сервера. Процесс выбора требует возможности
рассылки широковещательных сообщений.
Архитектура системы
В модели NTP некоторое число первичных эталонов времени,
синхронизованных по кабелю или с помощью национальных радио
служб времени, подключено к широкодоступным ресурсам, таким
как порты опорной сети. Эти устройства функционируют как пер-
вичные серверы времени. Целью NTP является передача информа-
ции о точном времени от этих серверов к другим серверам через
Интернет и коррекция ошибок, связанных с флуктуациями задер-
жек в сети. Некоторое число локальных ЭВМ или внешних шлюзов
могут выполнять функции вторичных серверов времени, общающихся
с первичными эталонами на основе протокола NTP. Вторичные сер-
веры позволяют минимизировать избыточность протокола, рассы-
лая нужную временную информацию локально. В целях обеспече-
ния надежности выбранные вторичные источники могут быть снаб-
жены менее точными, зато более дешевыми радио-часами,
используемыми в ситуациях, когда откажет первичный эталон или
выйдет из строя ведущий к нему канал.
Под стабильностью подразумевается степень постоянства зада-
ющей частоты часов, а под точностью - соответствие этой частоты
национальным стандартам времени. Если не указано обратного,
под временным сдвигом между часами подразумевается разйица
показаний этих часов. В то время как под сбоем (skew) подразуме-
вается различие их рабочих частот (первая производная). Настоя-
щие часы имеют конечную стабильность частоты (вторая производ-
ная не равна нулю). Нестабильность частоты называется дрейфом,
но в рамках протокола NTP дрейф предполагается равным нулю.
Протокол NTP создан с целью определения трех величин: сме-
щения часов (clock offset), RTT и дисперсии, все они вычисляются
по отношению к выбранным эталонным часам. Смещение часов
определяет поправку, которую необходимо внести в показания мест-
ных часов, чтобы результат совпал показанием эталонных часов.,
Дисперсия характеризует максимальную ошибку локальных часов
по отношению к эталонным.
Сети передачи данных. Метод доступа
759
В протоколе NTP нет средств для нахождения партнера или
управления. Целостность данных обеспечивается с помощью IP и
UDP контрольных сумм. Система может работать в симметричном
режиме, когда сервер и клиент неразличимы, и в режиме клиент-
сервер, где сервер выполняет только то, что требует клиент. Исполь-
зуется только один формат сообщений NTP. В рамках модели необ-
ходимо определить минимально возможную частоту коррекций ча-
сов, обеспечивающую требуемую временную точность.
Реализация модели
Клиент посылает NTP-сообщения одному или нескольким сер-
верам и обрабатывает отклики по мере их получения. Сервер изме-
няет адреса и номера портов, переписывает содержимое некоторых
полей, заново вычисляет контрольную сумму и немедленно посыла-
ет отклик. Информация, заключенная в сообщение NTP, позволяет
клиенту определить показания часов сервера по отношению к ча-
сам клиента и соответствующим образом скорректировать рабочие
параметры местных часов. Кроме того, эта информация содержит
данные, позволяющие оценить точность и надежность часов сервера
и выбрать наилучший эталон времени.
Модель клиент-сервер может быть вполне достаточна для ло-
кальных сетей, где один сервер обслуживает некоторое количество
клиентов. В общем случае NTP требует одновременной работы боль-
шого числа распределенных пар партнеров (клиент-сервер), конфи-
гурация которых изменяется динамически. Нужны достаточно слож-
ные алгоритмы управления такой ассоциацией, для обработки дан-
ных и контроля множества локальных часов.
Процесс передачи, управляемый независимыми таймерами для
каждого из партнеров, осуществляет накопление информации в базе
данных и посылает сообщения NTP. Каждое сообщение содержит
локальную временную метку момента отправки сообщения, ранее
полученные временные метки, а также необходимую вспомогатель-
ную информацию. Частота посылки сообщений определяется требу-
емой точностью локальных часов, а также предельными точностями
часов партнеров.
Когда получено сообщение NTP, вычисляется сдвиг между часа-
ми партнера и локальными часами, результат заносится в базу дан-
ных вместе с другой информацией, необходимой для вычисления
ошибок и выбора партнера.
760
Гпава 4
Конфигурации сети
Субсеть синхронизации представляет собой соединение первич-
ных и вторичных серверов времени, клиентов и каналов передачи
данных. Первичные серверы времени синхронизованы непосредствен-
но от эталонов времени, обычно от радио-часов. Вторичные серверы
могут быть синхронизованы от первичных серверов или других вто-
ричных серверов времени. Система серверов имеет иерархическую
структуру, построенную по схеме клиент-сервер. Понятно, что вто-
ричные серверы обеспечивают более низкую временную точность.
Следуя принципам, принятым в телефонной промышленности
[BEL86], точность каждого сервера определяется номером слоя
(stratum), наивысший уровень (для первичного сервера) имеет номер
1. На современном уровне технологий (радио-часы) точность одно-
кратной сверки имеет порядок одной миллисекунды.
Точность однократной сверки падает по мере роста значения
RTT и его разброса. Для того чтобы избежать сложных расчетов
[BRA80], необходимых для оценки точности в каждом конкретном
случае, полезно предположить, что средняя ошибка измерения про-
порциональна RTT и ее дисперсии. Предполагая, что первичные сер-
веры синхронизованы стандартами времени с известной точностью,
можно получить вполне надежную оценку точности синхронизации
субсети.
Дополнительным фактором является то, что каждый переход
от одного слоя к другому предполагает наличие ненадежного серве-
ра времени, который вносит дополнительные ошибки. Алгоритм
выбора серверов времени использует разновидность алгоритма мар-
шрутизации Беллмана-Форда, при этом формируется дерево мини-
мальных весов, основанием которого являются первичные сервера.
Метрикой расстояния служит номер слоя плюс расстояние синхро-
низации, которое характеризуется суммой дисперсии и половины
абсолютного значения задержки.
Такая конструкция способствует тому, что субсеть автоматичес-
ки реконфигурируется и настраивается на максимально достижи-
мую точность даже при выходе из строя первичных или вторичных
серверов времени. Если даже все первичные серверы выйдут из строя
или станут недоступными, их функции будут выполнять вторичные
серверы, если расстояние до них согласно алгоритму Беллмана-Фор-
да не превышает значения метрики, соответствующего бесконечнос-
ти (разрыву связи). Если все серверы окажутся на больших рассто-
яниях, субсеть продолжит работу при установках последней синх-
ронизации (коррекции внутренних часов). Даже в этом случае
достижима точность порядка миллисекунд в сутки.
Сети передачи данных. Метод доступа
761
Если два сервера находятся согласно алгоритму на равных рас-
стояниях, допускается случайный выбор.
форматы данных
Все арифметические операции в рамках протокола выполняются
в формате с фиксированной запятой. По этой причине все перемен-
* ные в NTP имеют именно этот формат. Биты пронумерованы слева
на право (со старшего бита), начиная с нуля. Жестких требований
на число разрядов после запятой не установлено,. Если не оговорено
обратного, все числа не имеют знака и занимают все отведенное для
них поле (при необходимости в качестве заполнителей старших
разрядов используются нули).
Временные метки NTP представляют собой 64-битные числа
с фиксированной запятой без знака, которое указывает число секунд
с нуля часов 1-го января 1900 года. Целая часть содержит первые
32 разряда, а дробная часть остальные 32 разряда. Этот формат не
совпадает с форматом меток ICMP, где время измеряется в миллисе-
кундах. Точность представления составляет 200 пикосекунд, что
должно удовлетворить самым экзотическим требованиям.
Временная метка формируется путем копирования показания
местных часов. Это производится в момент времени, заданный ка-
ким-то событием, например, приходом сообщения. Для поддержа-
ния наивысшей точности, важно, чтобы это делалось как можно
ближе к оборудованию или программному обеспечению, инициирую-
щего этот процесс. В случае, когда временная метка недоступна,
например, производится перезагрузка машин, поле метки характери-
зуется 64 нулями.
Заметим, что с 1968 года старший бит (бит 0 целой части) равен
единице, а где-то в 2036 году 64-битовое поле переполнится.
Переменные состояния и параметры
Ниже приводится обзор различных переменных и параметров,
используемых протоколом. Они распределены по классам систем-
ных переменных, которые имеют отношение к операционной среде и
механизму реализации местных часов. Сюда входят переменные
партнеров, которые характеризуют состояние протокольных машин
Участников обмена, переменные пакетов, описывающие содержимое
пересылаемых NTP-сообщений, а также параметры, задающие кон-
фигурацию текущей версии программного обеспечения. Имена пере-
менных записываются строчными буквами, а имена параметров —
прописными.
762
Гпава 4
Общие переменные
Следующие переменные являются общими для двух или более
систем, партнеров и классов пакетов. Когда необходимо отличить
общие переменные с идентичными именами, вводится идентифика-
тор переменной.
Адрес партнера (peer.peeraddr, pkt.peeraddr), порт партнера
(peer.peerport, pkt.peerport) — 32-битный IP-адрес и 16-битный но-
мер порта партнера.
Адрес ЭВМ (peer.hostaddr, pkt.hostaddr), порт ЭВМ (peer.hostport,
pkt.hostport) — 32-битный IP-адрес и 16-битный номер порта ЭВМ.
Эти переменные включаются в переменные состояния для поддерж-
ки мультиинтерфейсных систем.
Индикатор приращения (sys.leap, peer.leap, pkt.leap) — это двух-
битный код предупреждения о включении дополнительных секунд
во временную шкалу NTP. Эти биты устанавливаются до 23:59 дня
добавления и сбрасываются после ОФОО следующего дня. В резуль-
тате день, для которого проведена эта процедура, окажется длиннее
или короче на одну секунду. Для вторичных серверов эти биты
устанавливаются протоколом NTP. Биты 0 и 1 (LI) принимают
значения, перечисленные в таблице 4.4.15.1:
Таблица 4.4.15.1 Значения кодов индикатора U
LI Величина Значение
00 0 предупреждения нет
01 1 последняя минута содержит 61 секунду
10 2 последняя минута содержит 59 секунд
11 3 аварийный сигнал (часы не синхронизованы)
Во всех случаях за исключением аварийного сигнала (alarm -
112), протокол NTP никак не изменяет эти биты, а только передает
их программам преобразования времени, которые не являются час-
тью протокола. Аварийная ситуация возникает, когда по какой-
либо причине локальные часы оказываются не синхронизованны-
ми. Это может случиться в ходе инициализации системы или в
случае, когда первичные часы оказываются недоступны в течение
длительного времени.
Режим (peer.mode, pkt.mode) — это целое 3-битовое число,
обозначающее код режима ассоциации, который может принимать
значения, приведенные в таблице 4.4.15.2:
Сети передачи данных. Метод доступа
763
Таблица 4.4.15.2. Значения кодов Режим
Режим Значение
0 зарезервировано
1 симметричный активный
2 симметричный пассивный
3 клиент
4 сервер
5 широковещательный
6 для управляющих сообщений NTP
7 зарезервировано для частного использования
Слой (sys.stratum, peer.stratum, pkt.stratum) — целое число,
указывающее код слоя локальных часов, который может принимать
значения приведенные в таблице 4.4.15.3.
Таблица 4.4.15.3. Значения кодов слой
Слой ‘ Значение
0 Не специфицирован или недоступен
1 Первичный эталон (например, радио часы)
2-15 Вторичный эталон (через NTP или SNTP)
16-255 Зарезервировано на будущее
Для целей сравнения значение нуль кода слоя считается выше,
чем любая другая величина. Заметим, что максимальное значение
целого, закодированное как пакетная переменная, ограничено пара-
метром NTP. MAXSTRATUM.
Период обмена (sys.poll, peer.hostpoll, peer.peerpoll, pkt.poll) —
целая переменная co знаком, указывающая минимальный интервал
между передаваемыми сообщениями, измеренный в секундах и пред-
ставленный как степень 2. Например, значение 6 указывает на ми-
нимальный интервал в 64 секунды.
Точность (sys.precision, peer.precision, pkt.precision) — целая пе-
ременная co знаком, обозначающая точность часов в секундах и
выраженная как ближайшее значение степени числа 2. Значение
Должно быть округлено в большую сторону до ближайшего значе-
ния степени 2, например, сетевой частоте 50-Гц (20 мс) или 60-Гц
(16.67 мс) будет поставлено в соответствие величина -5 (31.25 мс),
в то время как кварцевой частоте 1000-Гц (1 мс) будет поставлено
в соответствие значение -9 (1.95 мс).
Базовая задержка (sys.rootdelay, peer.rootdelay, pkt.rootdelay) —
число с фиксированной запятой со знаком, указывающее на величи-
764
Глава 4
ну полной циклической задержки (RTT) до первичного эталона ча-
стоты, выраженное в секундах.
Базовая дисперсия (sys.rootdispersion, peer.rootdispersion,
pkt.rodtdispersion) — число с фиксированной запятой больше нуля,
указывающее на максимальное значение временной ошибки по от-
ношению к первичному эталону в секундах.
Идентификатор эталонных часов (sys.refid, peer.refid,
pkt.refid). Это 32-битовый код, идентифицирующий конкретные эта-
лонные часы. В случае слоя 0 (не специфицирован) или слоя 1
(первичный эталонный источник), 4-октетная ASCII-строка, выров-
ненная по левому краю и дополненная при необходимости нулями,
например:
Таблица 4.4.15.4. Коды идентификаторов часов
Слой Код Значение
0 DCN Протокол маршрутизации DCN
0 DTS Цифровая служба времени (Digital Time Service)
0 NIST Общий модем NIST
0 TSP Временной протокол TSP
1 ATOM Атомные часы (калиброванные)
1 VLF VLF-радио (OMEGA, и пр.)
1 callsign Общее радио
1 GPS GPS УВЧ позиционирование спутников
1 LORC LORAN-C радионавигация
1 WWVB Радио WWVB НЧ (диапазон 5)
1 GOES Спутник GOES УВЧ (диапазон 9)
1 wwv Радио WWV ВЧ (диапазон 7)
В случае слоя 2 и выше (вторичный эталон) — это 4-октетный
IP-адрес партнера, выбранного для синхронизации.
Эталонная временная метка (sys.reftime, peer.reftime,
pkt.reftime) — локальное время в формате временных меток, соот-
ветствующее моменту последней коррекции показаний часов. Если
локальные часы не были синхронизованы, переменная содержит нуль.
Базовая временная метка (peer.org, pkt.org) — локальное время
в формате временных меток, соответствующее моменту посылки пос-
леднего NTP-сообщения. Если партнер недостижим, переменная при-
нимает нулевое значение.
Временная метка получения (реег.гес, pkt.rec) — локальное
время в формате временных меток, соответствующее моменту при-
хода последнего NTP-сообщения, полученного от партнера. Если
партнер недостижим, переменная принимает нулевое значение.
Сети передачи данных. Метод доступа
765
Временная метка передачи (peer.xmt, pkt.xmt) — локальное
время в формате временных меток, соответствующее моменту от-
правки NTP-сообщения.
Системные переменные
Следующие переменные используются операционной системой
для синхронизации локальных часов.
Переменная локальные часы (sys.clock) содержит показание
локальных часов в формате временных меток. Локальное время
получается от аппаратных часов конкретной ЭВМ и дискретно уве-
личивается с конструктивно заданными приращениями.
Переменная базовые часы (sys.peer) представляет собой селек-
тор, идентифицирующий используемый источник синхронизации.
Обычно это указатель на структуру, содержащую переменные парт-
нера. Значение нуль указывает, что в настоящее время источник
синхронизации отсутствует.
Переменные партнера
Ниже перечислены все переменные партнера, которые использу-
ются для управления и реализации измерительных процедур.
Бит конфигурации (peer.config) — бит, индицирующий, что ас-
социация была сформирована на основе конфигурационной инфор-
мации и не должна быть расформирована, когда партнер становится
недоступен.
Временная метка актуализации (peer.update) — локальное
время в формате временной метки, отмечающее момент, когда было
получено последнее NTP сообщение. Переменная используется для
вычисления дисперсии временного сдвига.
Регистр достижимости (peer.reach) — сдвиговый регистр би-
тов NTP. WINDOW, используемых для определения статуса дости-
жимости партнера. Ввод данных производится со стороны младших
бит (справа). Партнер считается достижимым, если как минимум
один бит этого регистра равен 1.
Таймер партнера (peer.timer) — целочисленный счетчик, ис-
пользуемый для управления интервалом между последовательно
посылаемыми NTP-сообщениями. После установки значения счет-
чика его содержимое уменьшается на 1 (1сек) пока не достигнет
, нуля. При этом вызывается процедура передачи. Заметим, что рабо-
та этого таймера не должна зависеть от локальных часов.
т Пакетные переменные
Номер версии (pkt.version) — целое число индицирующее но-
МеР версии отправителя. N^P сообщения всегда посылаются с те-
766 Глава 4^
кущим значением версии NTP. VERSION и будут восприняты лищ^
при условии совпадения кодов версии. Исключения допускаются'
лишь при смене номера версии.
Переменные фильтра часов
Когда используются фильтры и алгоритмы отбора, дополнитель-'
но привлекаются следующие переменные состояния.
Регистр фильтра (peer.filter) — сдвиговый регистр каскадов"
NTP.SHIFT, где каждый каскад запоминает значения измеренной
задержки, смещения и вычисленной дисперсии, соответствующих*
одному наблюдению. Эти три параметра вводятся со стороны стар-
ших разрядов и сдвигаются в направлении младших разрядов (на-
право). При получении результатов нового наблюдения старые ре-
зультаты теряются. }
Счетчик корректных данных (peer.valid) — целочисленный
счетчик, указывающий на корректные образцы, остающиеся в регис-
тре фильтра. Он используется для определения состояния доступ-
ности и для управления увеличением и уменьшением периода рас-
сылки сообщений.
Смещение (peer.offset) — число с фиксированной запятой со
знаком, индицирующее значение смещение часов партнера по отно-
шению к локальным часам в секундах.
Задержка (peer.delay) — число с фиксированной запятой со
знаком, индицирующее полную циклическую задержку (RTT) часов
партнера по отношению к локальным часам с учетом времени рас-
пространения сообщения и отклика в сети в секундах. Заметим, что
переменная может принимать как положительное, так и отрица-^
тельное значение в зависимости от точности часов и накопившейся
ошибки смещения.
Дисперсия (peer.dispersion) — число с фиксированной запятой,,,
индицирующее максимальную ошибку часов партнера по отноше^.
нию к локальным часам с учетом сетевой задержки в секундах.
Допускаются только значения больше нуля.
Переменные аутентификации
При использовании механизма аутентификации привлекаются^
следующие переменные состояния.
Бит разрешения аутентификации (peer.authenable) — бит,
указывающий, что ассоциация должна работать в режиме аутентйр
фикации. £
Бит аутентификации (peer.authentic) — бит, индицирующий
то, что последнее сообщение, полученное от партнера, было коррект^
но аутентифицировано.
Сети передачи данных. Метод доступа 767
Идентификатор ключа (peer.hostkeyid, peer.peerkeyid, pkt.keyid)
целое число, идентифицирующее криптографический ключ, исполь-
зованный при генерации аутентификационного кода сообщения.
Криптографические ключи (sys.key) — набор 64-битных клю-
чей DES. Каждый ключ создается в соответствии с берклиевскими
UNIX-распределениями, которые состоят из 8 октетов, где 7 млад-
ших бит каждого октета соответствуют битам DES 1-7, а старший
бит соответствует биту четности DES.
Контрольная крипто-сумма (pkt.check) — криптографическая
контрольная сумма, вычисляемая процедурой шифрации.
Параметры
Ниже описаны параметры для всех реализаций, работающих в
сети Интернет. Необходимо договориться относительно значений
этих параметров для того, чтобы исключить ненужную избыточ-
ность и стабилизировать ассоциации партнеров. Приведенные пара-
метры применимы для всех ассоциаций.
Номер версии (NTP. VERSION) — текущий номер версии NTP (3).
Порт NTP (NTP.PORT) — стандартный номер порта (123), при-
своенный протоколу NTP.
Максимальный номер слоя (NTP.MAXSTRATUM) — макси-
мальный номер слоя, который может быть использован при кодиро-
вании пакетной переменной. Этот параметр обычно интерпретиру-
ется как определение значения метрики бесконечность (недостижи-
мость для протокола маршрутизации в субсети).
Максимальный возраст часов (NTP.MAXAGE) — максималь-
ный интервал в секундах, в течение которого эталонные часы будут
рассматриваться корректными после последней сверки.
Максимальный сбой (NTP.MAXSKEW) — максимальная ошиб-
ка смещения, связанная со сбоем локальных часов за время
NTP.MAXAGE, в секундах. Отношение NTP.MAXSKEW к
NTP.MAXAGE интерпретируется как максимальный сбой, вызван-
ный всей совокупностью факторов.
Максимальное расстояние (NTP.MAXDISTANCE) — макси-
мально допустимое расстояние между партнерами при синхрониза-
ции с использованием алгоритма отбора.
Минимальный период рассылки (NTP.MINPOLL) — минималь-
ный период рассылки, допустимый для любого из партнеров в сети
^нтернет. Этот период выражается в секундах и представляет со-
бой степень 2.
Максимальный период рассылки (NTP.MAXPOLL) -максималь-
ный период рассылки, допустимый для любого из партнеров в сети
768
Гпава 4
Интернет. Этот период выражается в секундах и представляет со-
бой степень 2.
Минимум избранных часов (NTP.MINCLOCK) — минималь-
ное число партнеров, необходимое для синхронизации (при исполь-
зовании алгоритма отбора).
Максимум избранных часов (NTP.MAXCLOCK) — максималь-
ное число партнеров, необходимое для организации отбора (при ис-
пользовании алгоритма селекции).
Минимальная дисперсия (NTP.MINDISPERSE) — минималь-
ное значение приращения дисперсии для каждого из слоев в секун-
дах (при использовании алгоритма фильтрации).
Максимальная дисперсия (NTP.MAXDISPERSE) — максималь-
ная дисперсия в секундах с учетом потерянных данных (при ис-
пользовании алгоритма фильтрации).
Размер регистра доступности (NTP.WINDOW) — размер ре*
гистра доступности (peer.reach) в битах.
Размер фильтра (NTP.SHIFT) — размер сдвигового регистра
фильтра часов (peer.filter), измеряется числом каскадов.
Вес фильтра (NTP.FILTER) — вес, используемый при вычисле*
нии дисперсии фильтра (применяется при работе с алгоритмом филь-
трации).
Выбранный вес (NTP.SELECT) — вес, используемый при вычис-
лении выбранной дисперсии (применяется при работе с алгоритмом
селекции).
Режимы работы
За исключением широковещательного режима, NTP-ассоциация
формируется, когда два партнера обмениваются сообщениями и один
или оба из них создает и поддерживает протокольную машину, на-
зываемую ассоциацией. Ассоциация может работать в одном из 5
режимов, заданных переменной peer.mode: симметрично активный,
симметрично пассивный, клиент, сервер и широковещательный:
Симметрично активный (1). ЭВМ, работающая в этом режиме»
периодически посылает сообщения вне зависимости от достижимос-
ти или слоя своего партнера. При работе в этом режиме ЭВМ опо-
вещает о своем намерении синхронизовать и быть синхронизован-
ной партнером.
Симметрично пассивный (2). Этот тип ассоциации первона-
чально создается по прибытии сообщения от партнера, работающего
в симметрично активном режиме. Он сохраняется, пока партнер
достижим и функционирует в слое ниже или равном данной ЭВМ-
В противном случае ассоциация распадается. Однако ассоциация
Сеги передачи данных. Метод доступа . 769
будет существовать до тех пор, пока, по крайней мере, одно сообще-
ние не будет послано в качестве отклика. При работе в этом режи-
ме ЭВМ оповещает о своем намерении синхронизовать и быть син-
хронизованной партнером.
Клиент (3). ЭВМ, работающая в этом режиме, периодически по-
сылает сообщения вне зависимости от достижимости или слоя сво-
его партнера. При работе в этом режиме ЭВМ, обычно это сетевая
рабочая станция, оповещает о своем намерении быть синхронизо-
ванной партнером.
Сервер (4). Этот тип ассоциации первоначально создается по
прибытии запроса клиента и существует только для отклика на
этот запрос. После отклика ассоциация ликвидируется. При работе
в этом режиме ЭВМ, обычно рабочая сетевая станция, оповещает о
намерении синхронизовать партнера.
Широковещательный (5). ЭВМ, работающая в этом режиме, пе-
риодически посылает сообщения вне зависимости от доступности
или слоя партнеров. При работе в этом режиме ЭВМ, обычно сете-
вой сервер времени, который работает в широковещательной среде,
оповещает о намерении синхронизовать всех партнеров.
ЭВМ, работающая в режиме клиента, иногда посылает NTP-сооб-
щение ЭВМ, работающей в режиме сервера, например, сразу после
перезагрузки и периодически после этого. Сервер откликается, ме-
няя адреса и номера портов, занося необходимую информацию и
отправляя сообщение назад клиенту. Серверы не должны хранить
какую-либо статусную информацию в паузах между запросами кли-
ента, в то время как клиенты могут варьировать интервалы между
NTP сообщениями, для того чтобы удовлетворить локальным тре-
бованиям. В этих режимах протокольная машина, описываемая здесь,
может быть существенно упрощена без заметной потери точности
или надежности особенно при работе в быстродействующей локаль-
ной сети.
В симметричных режимах отличие клиента от сервера практи-
чески исчезает. Симметрично пассивный режим предназначен для
использования временными серверами, работающими вблизи базо-
вых узлов (нижний слой) субсети синхронизации и со сравнительно
большим числом партнеров. В этом режиме идентификации парт-
нера не требуется заранее, так как ассоциация с ее переменными
состояния создана, только когда получено NTP-сообщение. Более
того, запомненное состояние может быть использовано позднее, ког-
да партнер станет недостижим или будет работать на более высо-
ком уровне и по этой причине будет непригоден в качестве источни-
ка синхронизации.
25 Зак. № 3430 Семенов
770
Гпава 4
Симметрично активный режим предназначен для использова-
ния серверами времени, работающими вблизи оконечных узлов (наи-
высший слой) синхронизации. Надежный временной сервис обычно
может быть реализован с помощью двух партнеров на ближайшем
нижележащем слое и одном партнере в том же слое. По этой
причине поток сообщений обычно невелик, даже когда связь поте-
ряна, и на каждый запрос приходит отклик об ошибке.
В норме, один партнер работает в активном режиме (симметрич-
ный активный, клиент или широковещательный), как это сконфи-
гурировано в стартовом файле, в то время как другие работают в
пассивном режиме (симметричный пассивный или сервер), часто без
предварительной конфигурации. Однако оба партнера могут быть
сконфигурированы для работы в симметричном режиме. Условие
ошибки возникает, когда оба партнера работают в одном и том же
режиме, но не в симметричном активном. В таких случаях каждый '
партнер будет игнорировать сообщения, поступающие от другого, и
ассоциация, если она существовала, будет ликвидирована из-за не-
достижимости партнера.
Широковещательный режим предназначен для работы в скорос-
тных локальных сетях с большим числом рабочих станций, где не
требуется высокая точность. При типичном сценарии один или бо-
лее временных серверов LAN периодически посылают широковеща-
тельные сообщения рабочим станциям, которые затем определяют
время на основе предварительно заданной задержки распростране-
ния порядка нескольких миллисекунд.
Обработка событий
Существенные события с точки зрения протокола NTP происхо-
дят при истечении времени таймеров партнера (peer.timer), один из
которых ориентирован специально на данного партнера в активной
ассоциации, а также при получении NTP-сообщения от различных
партнеров. Событие может произойти как результат команды опера-
тора или обнаруженной ошибки, такой как отказ первичного эталона.
Обозначения
Алгоритмы фильтрации и селекции NTP используют несколько -
переменных для хранения значений сдвига часов, RTT и дисперсии.
Переменные, относящиеся к партнерам, обычно обозначаются строч-
ными греческими буквами, а для первичного эталона времени ис-
пользуются прописные буквы. Эти алгоритмы базируются на пара-
метре, называемом расстояние синхронизации (1) и вычисляемом с
использованием RTT и дисперсии.
Сети передачи данных. Метод доступа
771
Дисперсия партнера (е) содержит вклады от ошибок измерения
(Г ) и накопления ошибок дрейфа (skew-error).
Каждый раз, когда соответствующие переменные партнеров из-
меняются, значения дисперсии корректируются. Ниже приводятся
основные определения переменных и формулы их вычисления:
0 = peer.offset,
8 = peer.delay,
г = peer.dispersion = p + (p т + eo,
A = e + |8|/2,
где 8 = RTT, 0 — сдвиг часов, (рт — накопление сбоя, (р =
NTP.MAXSKEW/NTP.MAXAGE, t — момент времени передачи ис-
ходной временной метки (на основе t вычисляется 0 и 8), 8 о —
дисперсия фильтра. Переменные, относящиеся к партнеру i, опреде-
ляются следующим образом:
0t = O,
А = peer, rootdelay + 8,
Е = peer, rootdispersion + 8t + (р т (максимальная дисперсия
часов партнера),
Л = Е t + |А |/2,
Окончательно, предполагая, что для синхронизации выбран i-ый
партнер, система переменных определяется следующим образом:
0 = комбинированное окончательное смещение (combined final offset),
А = A,
E = E + 8^ + 0,
A = A,
где 8f дисперсия выбора (select dispersion).
В рамках протокола NTP предусмотрен ряд стандартных проце-
дур. Процедура передачи запускается, когда таймер партнера станет
равным нулю. В режиме клиента с широковещательным сервером
сообщения вообще не посылаются. В режиме сервера сообщения
посылаются только в качестве отклика на полученные запросы.
Процедура получения выполняется по приходу NTP-сообщения.
Она проверяет сообщения, интерпретирует различные режимы и вы-
зывает другие процедуры для фильтрации данных и выбора источ-
ника синхронизации. Если номер версии в пакете не соответствует
текущей версии, сообщение может быть отброшено. Если получено
25*
772
Гпава 4
управляющее сообщение NTP и код режима пакета равен 6 (управ-
ление), вызывается процедура управляющего сообщения. IP-адреса
отправителя и адресата, а также номера портов устанавливаются
соответствующими заданному партнеру. Если соответствия нет, про-
изводится новая инсталляция протокольной машины и формирует-
ся новая ассоциация.
Пакетная процедура проверяет корректность сообщения, вычис- *
ляет задержку/смещение и вызывает другие процедуры для отбора
данных и выбора источника синхронизации. Переданная временная
метка должна отличаться от последней, полученной от того же парт-
нера. Исходная временная метка должна соответствовать после-
дней метке, посланной тому же партнеру. В случае широковеща-
тельного режима (5) RTT=O и полная точность операции передачи
времени будет недостижимой. Однако, полученная точность может
быть вполне приемлемой для многих целей. Процедура вызова кор-
рекции времени использует в качестве параметра peer.hostpoll
(peer.peerpoll может быть изменено). Пакетная процедура реализует
и некоторые другие тесты.
RTT и относительное временное смещение по отношению парт-
нера вычисляется следующим образом. Пусть i четное целое число.
Тогда Т. 3, Т. 2, Т.л и Т. — содержимое переменных pkt.org, pkt.rec,
pkt.xmt и peer.rec, соответственно. Смещение часов J , RTT D и „
дисперсия е ЭВМ по отношению к партнеру равны:
8 = (Т,— Т. 3) - (Т. л - Т. 2),
0 = ((Т. 2 - Т. 3) + (Т. х - Т.))/2,
е = (1 « sys.precision) + ф (Т. — Т. 3),
где, как и прежде, ф = NTP.MAXSKEW/NTP.MAXAGE, а « — обо-
значает сдвиг кода влево. Значение е представляет собой максималь-
ную ошибку или дисперсию, связанную с ошибкой измерения на сторо-
не ЭВМ, а также накопление ошибок из-за дрейфа локальных часов за
время после посылки последнего сообщения. Дисперсия корректирует-
ся процедурой фильтра часов (clock-filter). Очевидно, что достижимые
точности зависят от статистических свойств каналов связи.
Только пакеты с корректными данными могут использоваться
для вычисления смещения (offset), задержки (delay) и дисперсии.
Только пакеты с корректными заголовками могут использоваться
для определения того, может ли партнер быть выбран в качестве
источника синхронизации.
Процедура «часовой фильтр» вызывается для вычисления за-
держки (peer.delay), смещения (peer.offset) и дисперсии
• -А
Сети передачи данных. Метод доступа
773
(peer.dispersion) партнера. Спецификация алгоритма часового филь-
тра не является составной частью протокола NTP.
Процедура коррекции показания часов вызывается процедурой
приема, когда процедура фильтрации определила корректные значе-
ния смещения задержки и дисперсии для данного партнера.
Может так случиться, что локальные часы оказались сброшены.
В этом случае вызывается процедура очистки (clear procedure) для
каждого из партнеров, чтобы возвратить в исходное состояние фильтр
часов, период рассылки и, если необходимо, осуществить выбор ново-
го источника синхронизации.
Процедура расстояния вычисляет базовую (root) задержку А,
базовую дисперсию Е и базовое расстояние синхронизации Л. ЭВМ
не будет синхронизовать выбранного партнера, если расстояние боль-
ше, чем NTP.MAXDISTANCE.
В некоторых конфигурациях системы прецизионный источник
временной информации доступен в виде последовательности синх-
ронизующих импульсов, следующих с периодом в одну секунду. Обыч-
но это является дополнением к базовому источнику времязадаю-
щей информации, такому как радио-часы или даже сам протокол
NTP, для того чтобы обеспечить подсчет секунд, минут, часов и дней.
В этих конфигурациях системные переменные устанавливаются с
учетом источника, от которого поступают такие импульсы. Для
конфигураций, которые поддерживают первичные эталонные источ-
ники, такие как радио-часы или калиброванные атомные часы код
слоя устанавливается равным 1, поскольку именно он является
действительным источником синхронизации.
Спецификация алгоритмов выбора часов и работ локальных ча-
сов не являются составной частью NTP.
Когда ЭВМ связана с первичным эталоном времени, таким как
радио-часы, удобно ввести информацию об этих часах в базу данных,
как если бы это был обычный партнер. Первичные часы часы зап-
рашиваются раз в минуту или около того, полученный же времен-
ной код используется для корректировки показаний местных ча-
сов. Когда обнуляется peer.timer для первичного партнера, процеду-
ра передачи не вызывается, а посылается запрос радио-часам с
использованием ASCII-последовательности, предусмотренной для
этого случая. Когда получен корректный временной код от радио-
пасов, он преобразуется в формат временной метки NTP и корректи-
руются соответствующие переменные партнера. Величина peer.leap
Устанавливается в зависимости от состояния бита оповещения вре-
менного кода, если таковой имеется, или вручную оператором. Зна-
чение для peer.peeraddr, которое становится равно sys.refid, когда
774
Гпава 4
вызывается процедура корректировки показаний часов, делается рав-
ным ASCII-строке, описывающей часы.
Процедура инициализации вызывается при перезагрузке систе-
мы или при повторном запуске демона NTP. Состояние локальных
часов при загрузке предполагается неопределенным; однако, некото-
рые виды оборудования обеспечивают доступ к локальным часам,
как в ходе загрузки, так и сразу после нее. Переменная точности
определяется внутренней архитектурой оборудования локальных
часов. Аутентификационные переменные используются лишь при
реализации механизма аутентификации. Значения этих перемен-
ных определяются процедурами, выходящими за рамки протокола
NTP. Эта процедура является аппаратно-зависимой и служит, среди
прочего, для формирования ассоциации. Адреса и режимы работы
партнеров определяются в процессе чтения при перезагрузке или в
результате обработки команд оператора. В случае привлечения ме-
ханизма аутентификации только аутентифицированный партнер
может стать источником синхронизации.
Процедура receive-instantiation вызывается процедурой приема,
когда обнаруживается новый партнер. Она инициализирует пере-
менные партнера и формирует ассоциацию. Если сообщение получе-
но от партнера, работающего в режиме клиента (3), ЭВМ переводит-
ся в режим сервера (4); в противном случае, она устанавливается в
симметрично пассивный режим (2).
Процедура Primary Clock-Instantiation (инициализация первич-
ных часов) вызывается из процедуры инициализации для того, что-
бы установить переменные состояния для первичных часов. Значе-
ние peer.precision определяется из спецификации радио-часов и ап-
паратного интерфейса. Значение peer.rootdispersion номинально равно
удесятеренной максимальной ошибке радио-часов, например, 10 мсек
для WWVB или радио-часов GOES и 100 мсек для менее точных
радио-часов WWV.
В некоторых конфигурациях, включающих в себя атомные часы
или приемники LORAN-C, первичный эталон может выдавать толь-
ко секундные импульсы и не предоставлять полного временного
кода (числа секунд и пр.). В этих конфигурациях нумерация секунд
может быть получена из других источников, таких как радио-часы
или даже другие NTP-партнеры. В этих конфигурациях переменные
первичных часов должны отражать особенности первичного этало-
на, а не источника нумерации секунд. Однако, если источник нуме-
рации секунд отказал или работает некорректно, актуализация ло-
кальных часов от первичного эталона должна быть заблокирована.
СеГИ передачи данных. Метод доступа
775
Процедура очистки вызывается, когда произошло событие, ко-
торое значительно изменило достижимость или вызвало поломку
локальных часов.
Процедура запросов-коррекций (Poll-Update) вызывается, когда
происходит событие, которое может вызвать изменение периода зап-
росов (рассылки) или таймера партнера. Она проверяет значения
периода запросов ЭВМ (peer.hostpoll) и партнера (peer.peerpoll), а
также устанавливает их в заданных пределах.
Если интервал запросов (рассылок) не изменился, а таймер парт-
нера на нуле, то таймер просто сбрасывается в начальное состояние.
Если интервал запросов изменен, и новое значение таймера больше
текущего значения, никаких дополнительных действий не требуется;
в противном случае величина выдержки таймера партнера должна
быть уменьшена. Когда время выдержки таймера партнера уменьша-
ется, важно исключить какую-либо тенденцию синхронизации обме-
на между партнерами. Благоразумной предосторожностью является
рэндмизация первой передачи после уменьшения выдержки таймера.
Процедура расстояния синхронизации (Synchronization Distance)
вычисляет расстояние синхронизации на основе переменных парт-
неров. Заметим, что, в то время как Д может быть в некоторых
случаях отрицательной, Е и Л всегда положительны.
Конструкция NTP такова, что случайная или намеренная моди-
фикация данных временного сервера не должна привести к серьез-
ным ошибкам синхронизации. Однако успех этого подхода зави-
сит от дополнительных временных серверов и альтернативных се-
тевых маршрутов, а также от предположения, что искажения не
охватывают большинство временных серверов одновременно. В прин-
ципе уязвимость субсети может быть улучшена разумным выбором
временных серверов. Механизм аутентификации также позволяет
повысить надежность синхронизации. Следует, правда, принимать
во внимание, что шифрование/дешифрование данных заметно ухуд-
шает точность синхронизации.
Если требуется более надежная модель, система может базиро-
ваться на списке доступа, в который включаются 32-битовый IP-
адрес, 32-битовая маска и 3-битовый код режима работы. Если ло-
гическое И адреса эталона (pkt.peeraddr) и маски на входе ЭВМ
соответствуют определенному адресу и режиму (pkt.mode), доступ
разрешается, в противном случае отправителю запроса присылается
ICMP-сообщение об ошибке. Список управления доступом служит
фильтром, определяющим, какой из партнеров может сформировать
ассоциацию.
776
Гпава 4
Алгоритмы фильтрации и селекции
Наиболее важным фактором, влияющим на точность и надеж-
ность синхронизации, является набор алгоритмов, используемых для
уменьшения статистических ошибок и искажений при сбоях в раз-
личных компонентах субсети. Описанные здесь алгоритмы не явля-
ются частью стандарта NTP, по этой причине допускается использо-
вание любых других алгоритмов.
Для того чтобы NTP алгоритмы фильтрации и отбора работали
эффективно, полезно иметь меру вариации для каждого из партне-
ров. Принятая мера вариации базируется на разностях первого по-
рядка, которые легко вычислить. Существует две меры, одна назы-
ваемая дисперсией фильтра 8а, и другая дисперсия выбора (select
dispersion) е^. Обе меры вычисляются как взвешенные суммы сме-
щений из списка, сформированного на основе расстояний синхрони-
зации. Если 0. (О < i < п) смещение i-ой записи, тогда разность е i-
ой записи по отношению к j-ой записи определяется как
|0. — 0 |. Дисперсия относительно j-ой записи определяется как
1=0
где w — весовой коэффициент, который служит для учета влияния
расстояния синхронизации на дисперсию. В алгоритмах NTP w вы-
бирается меньше 1/2. w = NTP.FILTER для дисперсии фильтра (filter
dispersion) и w = NTP.SELECT для дисперсии выбора (select dispersion).
Дисперсия 8а и 8^ определены относительно 0-ой записи 80.
Существует процедура часовой-фильтр (clock-filter), которая ис-
пользуется для выбора лучших записей смещения для данных ча-
сов, и процедура выбора часов (clock-selection), которая использует-
ся, чтобы выбрать наилучшие часы среди иерархического набора
часов.
Процедура часовой фильтр исполняется по прибытии сообще-
ния NTP или другого события, в результате которого получены
новые данные. Она использует аргументы (0,8, 8), где 0 — результат
измерения смещения часов, содержащийся в записи, a d и е соответ-
ственно RTT и дисперсия. Процедура определяет значение отфильт-
рованного смещения часов (filtered clock offset — peer.offset), RTT
(peer.delay) и дисперсии (peer.dispersion). Она также корректирует
дисперсию хранящихся записей и текущее показание часов
(peer.update).
СетИ передачи данных. Метод доступа 777
Процедура часового фильтра использует сдвиговый регистр
(peer.filter), который состоит из NTP.SHIFT каскадов, каждый кас-
кад содержит значения 0,8 и 8 ., которые пронумерованы, начиная с
нуля, слева направо. Фильтр инициализируется процедурой очист-
ки при этом заносятся значения [О, О, NTP.MAXDISPERSE] во всех
каскадах. Новые данные записей вдвигаются в фильтр,с левого
конца. Пакетная процедура выдает записи в формате (0,8,8), когда
приходят новые корректирующие данные, в то время как процедура
передачи выдает записи в форме [О, О, NTP.MAXDISPERSE], когда
истекает два периода запроса без поступления свежих данных. Ког-
да одни и те же символы (0, 8, 8) используются для аргументов,
содержимого часового фильтра и переменных партнера, их значения
обычно понятно из контекста. Ниже представлена псевдопрограм-
ма, поясняющая работу данной процедуры.
Дисперсия 8. для всех корректных записей в регистре фильтра
должна корректироваться с тем, чтобы отражать накопление смеще-
ния со времени последней коррекции. Эти записи заносятся также во
временный список, следуя стандартному формату записей [расстоя-
ние, индекс]. Записи в регистре сдвигаются вправо, новые записи вво-
дятся слева, а самая правая запись теряется. Временный список сор-
тируется по значению расстояния. Если в списке не остается записей,
процедура прерывается без корректировки переменных партнера.
Смещение партнера 0О, задержка 80 и дисперсия 80 выбираются
как величины, соответствующие записи с минимальным расстояни-
ем; другими словами, записи, соответствующей первому элементу
временного списка (в данной нотации имеет индекс 0).
Переменные peer.offset и peer.delay представляют смещение шкалы
часов и RTT для локальных часов, измеренные относительно часов
партнера. Обе они усредняются по большому числу измерений в
течение длительного периода времени. Переменная peer.dispersion
характеризует максимальную ошибку из-за неточности измерений,
дрейфа и вариации записей. Все три переменные используются при
выборе часов для синхронизации.
Процедура выбора часов
Процедура выбора часов использует переменные партнера 0, Д, Е
и т, она вызывается, когда эти переменные изменились или изменил-
ся статус доступности. Процедура включает в себя две составные
части: алгоритм пересечения и алгоритм кластеризации. Алгоритм
пересечения подготавливает список кандидатов партнеров, могущих
стать источниками синхронизации и вычисляет доверительный ин-
тервал для каждого из них. Алгоритм кластеризации сортирует
778
Гпава 4
список кандидатов по кодам слоя и расстояния синхронизации.
Системная переменная sys.peer представляет собой указатель на
наиболее вероятного кандидата, если таковой имеется, или на нуле-
вую величину в противном случае.
Алгоритм пересечения
Каждый из партнеров просматривается последовательно и до-
бавляется в конец списка, если он прошел ряд тестов. Для каждого
из m кандидатов в список заносятся 3 записи в форме [указатель,
тип]: [0 — Л, -1], [0, 0] и [0 — Л, 1]. В результате в списке будет 3m
записей, которые будут позднее упорядочены.
Ниже приведенный алгоритм представляет собой адаптирован-
ную версию DTS [DEC89] и сконструирован так, чтобы отбирать
только истинных кандидатов. Алгоритм начинается с инициализа-
ции значения f и занесения нуля в счетчики inc. Затем, начиная с
конца упорядоченного, для каждой записи [указатель, тип] значение
типа вычитается из кода счетчика i, который содержит число пере-
сечений. Если код типа равен нулю, инкрементируется значение с,
которое регистрирует число ложных кандидатов. Если для некото-
рых записей i > m — f, конец записи становится нижней границей
пересечения; в противном случае, f увеличивается на 1 и процедура
повторяется. Без сброса значений f или с, аналогичная процедура
используется для нахождения верхней границы, за исключением
того, что значение кода тип добавляется к счетчику. Если после
того как обе границы определены с < f, процедура продолжается для
найденных m — f кандидатов, в противном случае, f увеличивается
на 1 и вся процедура повторяется.
Работа продолжается далее, только если имеется более т/2 пе-
ресечений. Однако возможно, но не слишком вероятно, что в облас-
ти пересечения окажется менее т/2 кандидатов.
Алгоритм кластеризации
В исходном алгоритме DTS процедура выбора часов прерывается в
данной точке с выбором кандидатов из центра области пересечения.
Однако это ведет к заметной потере точности и стабильности, так как
не учитываются индивидуальные статистические свойства партнеров.
Следовательно, только кандидаты, прошедшие предварительный отбор,
могут участвовать в последующей обработке. Список кандидатов пре-
образуется к форме [расстояние, индекс], где расстояние вычисляется
на основе кода слоя и расстояния синхронизации L партнера. Масш-
табный коэффициент позволяет реализовать механизм весового учета
вкладов от кодов слоя и расстояния. Обычно, код слоя доминирует,
Сети передачи данных. Метод доступа
779
если только один или более кандидатов имеют слишком большие
расстояния. Список упорядочивается согласно величине расстояния.
Последующие шаги служат для того, чтобы отсеять кандидатов
со слишком большими дисперсиями. Практика показывает, что число
кандидатов здесь может быть достаточно велико. Это может приве-
сти к большому числу циклов повторения процедуры отбора, кото-
рые не дадут какого-либо улучшения результатов. Длина списка
кандидатов ограничивается переменной NTP.MAXCLOCK.
Заметим, что представляет собой дисперсию относительно i-ro
партнера из списка кандидатов, которая может быть вычислена ме-
тодом дисперсии фильтра, описанным выше. е. — дисперсия j-oro
партнера из списка, включающая в себя вклады от ошибок измере-
ния, от накопления дрейфа и из-за дисперсии фильтра. Если макси-
мальное значение 8^ больше чем минимальное значение е., а число
кандидатов больше NTP.MINCLOCK, i-ый партнер удаляется из спис-
ка и процедура повторяется. Если текущий источник синхрониза-
ции является одним из членов списка и нет других кандидатов из
более низкого слоя, процедура прерывается, и никакие другие после-
дующие шцги не предпринимаются. В противном случае в качестве
источника синхронизации берется первый кандидат из списка. В
ниже приведенном тексте i, j, k, 1 — индексы партнеров, к — индекс
текущего источника синхронизации (нуль, если такой источник от-
сутствует), 1 — индекс первого кандидата в списке.
Алгоритм сконструирован так, чтобы отдавать предпочтение парт-
нерам из головной части списка, которые размещены в более низ-
ком слое, имеют наименьшее расстояние и могут обеспечить наи-
большую точность и стабильность. С помощью правильного выбора
весового коэффициента v (называемого NTP.SELECT), можно уда-
лить некоторые записи из финальной части списка.
Локальные часы
Для того чтобы иметь точные локальные часы, ЭВМ должна
быть оборудована аппаратными часами, состоящими из задающего
генератора и интерфейса, обеспечивающего необходимые операции
Установки и коррекции. Логические часы конструируются, исполь-
зуя эти компоненты и программы, которые осуществляют подстрой-
ку частоты и абсолютного показания локальных часов. Такая сис-
тема позволяет достичь точности времени до 15 нс и стабильности
частоты на уровне 0.3 мс в день. Предлагаемая модель удобна для
применения как для компенсируемых, так и для некомпенсируемых
кварцевых генераторов, пригодна она и для часов, использующих
Для создания временной шкалы частоту сети переменного тока.
780
Гпава 4
Реализация «пушистый шарик» (Fuzzball)
Локальные часы «пушистый шарик» представляют собой ком-
бинацию аппаратных и программных регистров, а также алгорит-
мов, которые осуществляют функционирование часов — работу уп-
равляемого задающего генератора, синхронизуемого от внешнего
источника. Далее следует описание его компонентов и способа ра-
боты. Заметим, что все числа являются дополнениями до 2, а все
сдвиги являются арифметическими (заполнение знаком при сдвиге
вправо и нулем при сдвиге влево).
48-битовый часовой регистр (Clock) и 32-битовый предваритель-
ный счетчик (Prescaler) образуют управляемый задающий генератор
с периодом 1 мс. Дробная часть кода времени представляет собой
число миллисекунд с начала суток. 32-битовый регистр коррекций
(Clock-Adjust) используется для подстройки фазы часов постепен-
ными шагами, что исключает неоднородности временной шкалы.
Его содержимое обозначается х. 32-битовый регистр компенсации
дрейфа (Skew-Compensation) используется для подстройки частоты
задающего генератора с помощью добавления небольших фазовых
сдвигов (0'01%). Его содержимое обозначается символом у. 16-
битовый счетчик оповещения (Watchdog) и 32-битный регистр со-
гласования (Compliance) используются для определения корректно-
сти и служит также для задания периода рассылки запросов. Со-
держимое регистра согласования обозначается символом z.
32-битовый регистр настройки (PPS-Adjust) служит для подстрой-
ки точности, когда имеется точный источник сигналов с периодом в
одну секунду. 2-битовый регистр флагов управляет добавлением/
вычитанием секунд к показаниям часов, когда это необходимо.
Все регистры кроме предварительного счетчика обычно разме-
щаются в памяти. В типовом интерфейсе часов, таком как DEC
KWV11-C, регистр Prescaler реализован в виде 16-битового буфер-
ного счетчика, управляемого кварцевым генератором с частотой,
кратной 1000 Гц. Переполнение счетчика вызывает прерывание про-
цессора, которое осуществляет приращение содержимого регистра
часов.
Когда наступает момент подстройки, CLOCK.ADJ секунд вычи-
тается из содержимого PPS-счетчика, но это делается лишь при
условии, что там лежит число больше нуля. CLOCK.ADJ добавля- .
ется к коду счетчика Watchdog. Этот код не должен превышать
значения NTP.MAXAGE, поделенного на CLOCK.ADJ. Если счет- »
чик Watchdog достигнет этой величины, часы считаются не синхро-
низованными, а Leap-биты устанавливаются равными 112.
Сети передачи данных. Метод доступа
781
Постепенная настройка фазы
Если локальные часы нескорректированы, они продолжают ра-
ботать со смещением и частотой (при отсутствии дрейфа), установ-
ленными при последней коррекции. Корректирующая информация
имеет формат 48-битного целого числа со знаком. Это число харак-
теризует целое и дробное число миллисекунд (запятая располагает-
ся после 32-го двоичного разряда). Если полученная величина пре-
восходит максимальное значение, заданное CLOCK.МАХ, необходи-
ма постепенная пошаговая коррекция. В норме величина поправки
вычисляется в рамках алгоритма NTP. Однако, если код счетчика
PPS больше нуля, вместо него должен использоваться регистр PPS-
Adjust. Пусть п представляет собой 32-битовый код с битами 0-31
равными разрядам 16-47 корректирующего кода. Если некоторые
младшие биты корректирующего кода не используются, они уста-
навливаются равными биту знака. Такие операции сдвигают поло-
жение запятой влево по отношению биту 16, что уменьшает влия-
ние ошибок округления. Пусть b число начальных нулей в коде
регистра Compliance и пусть с число начальных нулей в коде счетчи-
ка Watchdog. Тогда b установится равным:
b = b — 16 + CLOCK.COMP
b не должно быть меньше нуля (это логарифм постоянной вре-
мени обратной связи). Затем установим с равным:
с = 10 — с
Величина с представляет собой логарифм времени интегрирова-
ния со времени последней коррекции. Затем вычисляются новые
значения кодов для регистров Clock-Ad just и Skew-Compensation.
х = u » b,
у = у + (u » (b + b — c)).
В заключение вычисляем экспоненциальное среднее
z = z + (u « (b + CLOCK.MULT) — z) » CLOCK.WEIGHT,
где сдвиг влево переносит положение запятой с целью достижения
большей точности.
Для каждого периода подстройки определяется корректирую-
щий код из двух составляющих. Первая составляющая (фаза) оп-
ределяется как
х » CLOCK.PHASE,
эта величина затем вычитается из предшествующего значения ре-
гистра Clock-Adjust. Результат становится новым значением кода
Этого регистра. Вторая компонента — (частота) определяется как
У » CLOCK.FREQ.
782 Глава 4 I
Совокупность фазы и частоты представляет собой окончатель-
ный корректирующий код, который затем добавляется к коду реги-
стра (Clock). В заключение, счетчик Watchdog обнуляется.
Величина b вычисленная ранее может использоваться для изме-
нения величины системной переменной, характеризующей период
запросов (коррекций) sys.poll.
sys.poll <- b + NTP.MINPOLL.
При условии, что шум коррекций велик, частота аппаратного
задающего генератора может меняться быстро из-за изменений ус-
ловий окружающей среды. В этом случае период запросов укорачи-
вается. Когда шум незначителен, задающий генератор стабилен и
период запросов растет вплоть до NTP.MAXPOLL секунд.
Ступенчатая подстройка фазы
Когда величина поправки превышает CLOCK.MAX, имеется воз-
можность того, что часы окажутся настолько не синхронизованы, что
наилучшим решением будет немедленная замена содержимого регистра
часов. Однако, в случаях, когда вариация записи весьма высока, разумно ;
не поверить в возможность скачкообразного изменения, если только со
времени последней коррекции не прошло достаточно много времени.
Следовательно, если обнаружено скачкообразное изменение, а счетчик
Watchdog содержит код меньше предварительно установленного значе-
ния CLOCK.MINSTEP, корректирующее сообщение игнорируется.
Если обнаружено ступенчатое изменение, коррекция заносится
непосредственно в регистры Clock, а содержимое регистров Clock-
Adjust и Watchdog обнуляется. Другие же регистры остаются без
изменений. Так как ступенчатое изменение показаний указывает
на некорректность информации в часовых фильтрах (clock filters),
биты добавления делаются равными 112 (не синхронизовано) и вы-
зывается процедура очистки часовых фильтров и переменных состо-
яния для всех партнеров. На практике необходимость корректиро- »
вать показания часов скачкообразно случается крайне редко, когда, .
например, локальные часы или эталон перезагружаются.
Практически значения CLOCK.MAX могут быть превышены вре-
менным сервером лишь в условиях чрезмерной перегрузки канала а
или при сбоях оборудования. Наиболее часто встречаемый случай
— это смена сервера при регистрации слишком большого числа S
ошибок или из-за сильной вариации задержки. Рекомендуется, что-
бы реализации программ включали средства формирования значе-
ний CLOCK.MAX для особых случаев. Величина, на которую можно
превысить CLOCK.MAX, не нарушая требования монотонности, за-
висит от значения приращения регистра часов (Clock register).
Сети передачи данных. Метод доступа
783
Обсуждение реализации
Базовая модель надежности NTP предполагает, что не должно
быть никаких других способов изменения показаний кроме предус-
мотренных самим протоколом NTP. Системы с часами-календарем,
имеющие питание от батареи или аккумулятора, считаются надеж-
ными, но менее точными, чем использующие NTP-синхронизацию.
При последовательных коррекциях, если величина поправки превы-
шает конфигурационный параметр (напр., 1000 секунд), поправка
отбрасывается и посылается сообщение об ошибке. Некоторые реа-
лизации периодически записывают содержимое регистра Skew-
Compensation (компенсация дрейфа) в системный файл или в па-
мять, сохраняемую при отключении питания.
Преобразование из формата NTP в обычный информационный
формат осуществляется прикладными программами. В день нака-
нуне добавления/вычитания секунды из показаний времени значе-
ние sys.leap устанавливается на первичном сервере вручную. Следу-
ет иметь в виду, что большинство радио-часов не имеет автомати-
ческих или ручных средств добавления/вычитания секунд. Но даже
в случае некорректного добавления/вычитания секунды локальные
часы будут вновь синхронизованы не позднее чем через число се-
кунд, заданное CLOCK.MINSTEP.
Формат данных NTP — версия 3
Формат NTP-сообщения, которое следует сразу после UDP-заго-
ловка, показан на рис 4.4.15.1.
Индикатор добавления (LI — Leap Indicator) — двухбитовое
поле предупреждения о предстоящем добавлении/вычитании секунды
к последней минуте текущего дня. Значения этих битов смотри в
таблице 4.4.15.1.
Номер версии (VN) — трехбитовое поле, указывающее на номер
версии протокола NTP, в настоящее время (3).
Режим (Mode) — трехбитовое поле, определяющее режим, значе-
ния кодов режима приведены в таблице 4.4.15.2.
Слой (Stratum) — 8-битовое поле, определяющее код слоя, где
работают локальные часы. Коды слоя представлены в таблице
4.4.15.3. Возможные значения кодов лежат в интервале от нуля до
NTP.INFIN включительно.
Период запросов (Poll Interval) — 8-битовое поле, указываю-
щее на максимальное значение интервала между запросами. Код,
записанный в этом поле, интерпретируется как целое число со зна-
ком и характеризует значение периода в секундах, как ближайшее
к величине степени двух. Коды, которые могут быть записаны в
784
Гпава 4
0 2 5 8 16
LI VN Режим Слой
Интервал запросов Точность
Базовая задержка
Базовая дисперсия
Идентификатор эталонных часов
Эталонная (REFERENCE) временная метка (64 бита)
Исходная (Originate) временная метка (64 бита)
Получаемая (Receive) временная метка (64 бита)
Отправляемая (Transmit) временная метка (64 бита)
Аутентификатор (96 бит) (опционно)
Рис. 4.4.15.1. Формат сообщения NTP.
этом поле, должны лежать в интервале между NTP.MINPOLL и
NTP.MAXPOLL включительно.
Точность (Precision) — 8-битовое поле, обозначающее точность
локальных часов в секундах. Код поля интерпретируется как целая
степень со знаком числа 2.
Базовая задержка (Root Delay) — 32-битовое поле, характери-
зующее RTT до эталонного источника в секундах. Код поля интер-
претируется как число с фиксированной запятой, размещенной меж-
ду битами 15 и 16. Заметим, что величина этого кода может иметь
и отрицательное значение (зависит от точности часов и величины
дрейфа).
Базовая дисперсия (Root Dispersion) — 32-битовое поле, опре-
деляющее максимальную ошибку по отношению к эталонному ис-
точнику в секундах. Код поля интерпретируется как число с фикси-
рованной запятой (между 15 и 16 битами). Допустимы только по-
ложительные значения.
СеТи передачи данных. Метод доступа 785
Идентификатор эталонных часов (Reference Clock Identifier)
__ 32-битовое поле, идентифицирующее конкретные эталонные часы.
В случае кода слоя нуль (не специфицировано) или слоя 1 (первич-
ный эталон), это 4-октетная комбинация выравнивается по левому
краю и дополняется нулями (ASCII). Когда идентификатор в NTP
не специфицирован, предлагаются ASCII- идентификаторы, приве-
денные в таблице 4.4.15.4.
В случае слоя 2 и больше (вторичный эталон) — это 4-октетный
IP-адрес ЭВМ — первичного эталона.
Эталонная временная метка (Reference Timestamp) — поле
локального времени (64-битовый формат временных меток), когда
часы корректировались в последний раз.
Исходная временная метка (Originate Timestamp) определяет
время, когда запрос направлен серверу (стандартный 64-битовый
формат временных меток).
Получаемая временная метка (Receive Timestamp) — время,
когда запрос прибыл к серверу (стандартный 64-битовый формат
временных меток).
Передаваемая временная метка (Transmit Timestamp) — ло-
кальное время, когда послан отклик сервером (стандартный 64-
битовый формат временных меток).
Аутентификатор (Authenticator) (опционен) — 96-битовое поле,
содержащее аутентификационную информацию. Используется лишь
в случае реализации NTP-аутентификации.
Сообщения управления NTP
В сетевой среде должны быть средства управления программами
NTP, такие как установка индикатора добавления секунды (leap-
indicator) со стороны первичного сервера, настройка различных сис-
темных параметров и процедур мониторинга. Такие операции могут
быть реализованы с привлечением протокола SNMP и соответству-
ющего расширения базы данных MIB. Однако в тех случаях, когда
такие средства недоступны, эти функции могут быть реализованы с
помощью специальных управляющих NTP-сообщений.
Управляющие сообщения NTP имеют код 6 в поле режима
первого октета NTP-заголовка. Формат поля данных специфичен
Для каждой из команд или отклика. Однако, в большинстве случаев
Формат конструируется так, чтобы облегчить его непосредственное
чтение. Как правило, он состоит из ASCII-строк. Если используется
аутентификатор, поле данных дополняется нулями до границы, крат-
ной целому числу 32-битных слов.
786
Гпава 4
IP-ЭВМ не должны обрабатывать дейтограммы длиннее 576 окте-
тов; однако, некоторые команды или отклики могут содержать данные,
непомещающиеся в одну дейтограмму. Для решения данной проблемы
все октеты сообщения нумеруются, начиная с нуля. При передаче фраг-
ментов сообщения номер первого октета записывается в поле смеще-
ния (offset), а число октетов в поле длины. Бит (М — more) устанав-
ливается во всех фрагментах за исключением последнего.
Большинство контрольных функций включает посылку коман-
ды и получение отклика. Отправитель выбирает ненулевой поряд-
ковый номер и устанавливает статусное поле и биты R и Е равными
нулю. Получатель интерпретирует код операции и дополнительную
информацию, содержащуюся в поле данных, вносит изменение в поле
статуса и устанавливает бит R=l, а также возвращает три 32-бит-
ного слова заголовка вместе с другой дополнительной информацией
поля данных. В случае неверного формата сообщения или ошибки
в поле данных получатель заносит соответствующий код в поле
статуса, устанавливает биты R и Е равными 1, и опционно записыва-
ет диагностическое сообщение в поле данных.
Некоторые команды осуществляют чтение или запись для сис-
темных переменных и переменных партнеров для ассоциации, иден-
тифицированной в команде. Другие читают или записывают значе-
ния переменных, связанных с радио-часами и другими приборами,
имеющими непосредственное отношение к эталонам времени. Для
определения ассоциации используется ее 16-битовый идентифика-
тор. Для системных переменных используется идентификатор нуль.
Управляющий объект может затребовать текущий список иденти-
фикаторов с тем, чтобы их использовать в дальнейшем. При попыт-
ке употребить уже недействительный идентификатор будет прислан
соответствующий отклик, после чего необходимо запросить список
идентификаторов еще раз.
Некоторые события, такие как изменение статуса доступа к парт-
неру, не сопряжены с какими-либо командами и происходят асинх-
ронно. Программа может запоминать информацию о таких событи-
ях и пересылать ее в откликах. Текущий статус и краткая аннота-
ция чрезвычайных событий пересылаются каждым откликом. Биты
в статусном поле указывают на то, произошло ли какое-либо собы-
тие с момента предыдущего отклика и было ли их больше одного»
Формат сообщений управления NTP
Формат заголовков управляющих NTP-сообщений показан на
рис. 4.4.15.2. Этот заголовок располагается непосредственно вслед
за UDP-заголовком.
Сети передачи данных. Метод доступа
787
0 2 5 8 9 10 11
Режим R Е М Код операции
Номер по порядку
Статус
Идетификатор ассоциации
Смещение
Длина поля данных
Данные 0-468 байт (дополняется нулями до
границы, кратной 4 октетам)
Аутентификатор
(опционно)
Рис. 4.4.15.2. Формат управляющего сообщения NTP
Первые два бита, обозначенные ZZ, должны всегда содержать 0.
Номер версии (VN — Version Number) — трехбитовое поле, ука-
зывающее на номер версии протокола NTP, в настоящее время (3).
Режим (Mode) — трехбитовое поле, определяющее режим, значе-
ние кода режима для управляющих сообщений равно 6.
Бит отклика (R) — равен нулю для команд и 1 для откликов.
Бит ошибки (Е) — равен нулю для нормального отклика и 1 в
случае ошибки.
Бит продолжения (М — More) — равен нулю для последнего
фрагмента и 1 — для всех остальных.
Код операции (Ор) — 5-битовое поле, определяющее код коман-
ды. Значения кодов и их функции представлены в таблице 4.4.15.5.
Таблица 4.4.15.5. Коду операции управляющего сообщения
Код Функция
0 Зарезервировано
I Чтение статуса команда/отклик
2 Чтение переменной команда/отклик
3 Запись переменной команда/отклик
4 Чтение переменных часов команда/отклик
5 Запись переменных часов команда/отклик
6 Установка адреса/порта trap команда/отклик
7 Отклик на trap
8-31 Зарезервировано на будущее
788
Гпава 4
* Порядковый номер (Sequence) — 16-битовое поле, определяю,
^цее номер запроса или отклика, и облегчающее определения их
соответствия.
Статус — 16-битовое поле, содержащее код статуса системы,
партнера или часов.
Идентификатор ассоциации (Association ID) — 16-битовое поле,
несущее в себе идентификатор ассоциации.
Смещение (Offset) -г- 16-битовое поле, определяющее положе-
ние первого октета поля данных в сообщении, передаваемом в не-
скольких дейтограммах (позиция задается в октетах).
Длина (Count) — 16-битовое поле, определяющее длину поля
данных в октетах.
Данные — это поле содержит информацию сообщения, как для
команды, так и для отклика. Максимальное число октетов в поле
данных равно 468.
Аутентификатор (опционен). Поле, содержащие аутентифика-
ционную информацию. Используется лишь в случае реализации NTP-
аутентификации.
Статусные слова
Статусные слова указывают на текущее состояние системы ассо-
циации и часов. Эти слова интерпретируются программами сетевого
мониторинга и имеют 4 разных 16-битовых форматов. Статусные
слова партнеров и системы соответствуют откликам для всех ко-
манд за исключением случая чтения/записи переменных часов и
установки адреса/порта для trap. Идентификатор ассоциации нуль
соответствует системным статусным словам, в то время как нену-
левой идентификатор указывает на какую-то конкретную ассоциа-
цию. Статусное слово, присланное в ответ на команду чтения или
записи переменной часов, указывает на состояние оборудования и
кодирующего программного обеспечения. *
Системные статусные слова
Системное статусное слово может присутствовать в статусном
поле отклика. Системное статусное слово имеет следующий формат.
Индикатор добавления (LI — Leap Indicator) — двухбитовое
поле предупреждения о предстоящем добавлении/вычитании секунды
к последней минуте текущего дня. Значения этих битов смотри в
таблице 4.4.15.1.
Источник часов (Clock Source) — 6-битовое поле, указывающее
на используемый в данный момент источник синхронизации. На*
значение кодов этого поля описано в таблице 4.4.15.6.
Сети передачи данных. Метод доступа
789
02 8 12 15
LI Источник синхронизации Счетчик Код
Состояние системы 0 5 8 12 15
Статус партнера SEL Счетчик Код
Слово состояния партнера 0 8 15
Состояние часов Код
Состояние радио часов 0 8 15
Код ошибки Зарезервировано
Сообщение об ошибке
Рис. 4.4.15.3. Форматы статусных слов
Таблица 4.4.15.6. Коды источников временного эталона
Код Функция
0 Не специфицирован или неизвестен
1 Калиброванные атомные часы (напр., HP 5061)
2 VLF (диапазон 4) или НЧ (диапазон 5) радио (напр., OMEGA, WWVB)
3 ВЧ (диапазон 7) радио (напр., CHU, MSF, WWV/H)
4 УВЧ (диапазон 9) спутник (напр., GOES, GPS)
5 Локальная сеть (напр., DCN, TSP, DTS)
6 UDP/NTP
7 UDP/TIME
8 Eyeball-and-wristwatch
9 Телефонный модем (напр., N1ST)
1.0-63 Зарезервировано на будущее
Системный счетчик событий — четырех битовое целое число,
обозначающее число событий, происшедших с момента последнего
получения статусного слова системы. Счетчик обнуляется, когда
присылается в статусном поле отклика и остается неизменным
после достижения значения 15.
Код системного события — четырехбитовое число, идентифици-
рующее последнее системное событие, новое значение переписывает
предыдущее. Коды событий перечислены в таблице 4.4.15.7.
790
Гnasg 4
Таблица 4.4.15.7. Коды системных событий
Код [ Функция
0 Не специфицировано
1 Рестарт системы '
2 Системный или аппаратный сбой *
3 Новое статусное слово системы (изменение битов добавления^ или синхронизации)
4 Новый источник синхронизации или слой (изменение sys.peeT" или sys.stratum)
5 Сброс системных часов (корректирующая добавка превысила" CLOCK.MAX)
6 Некорректное системное время или дата
7 Событие системных часов (System clock exception) ”
8-15 Зарезервировано на будущее ”
Статусное слово партнера
Статусное слово партнера возвращается в статусном поле от*
клика на команду чтения статуса, а также чтения или записи пере-
менных. Это слово появляется в списке идентификаторов ассоциа-
ции и статусных слов, присылаемых в ответ на команду чтения
статуса с нулевым идентификатором ассоциации. Формат статус-
ного слова партнера содержит следующие поля.
Статус партнера — 5-битный код, характеризующий состояние;
партнера, определяемого процедурой обмена. Значения этого поля
представлены в таблице 4.4.15.8.
Таблица 4.4.15.8. Коды состояния партнера
Значение кода Функция
0 Сконфигурирован (peer.config)
1 Разрешена аутентификация (peer.authenable)
2 Аутентификация успешна (peer.authentic)
3 Партнер доступен (peer.reach)
4 Зарезервировано на будущее
Выбор партнера (SEL) — 3-битный код, говорящий о состоянии
партнера, определенного в результате процедуры выбора часов (рис*
4.4.15.3). Значения кодов представлены в таблице 4.4.15.9.
Таблица 4.4.15.9. Коды выбора партнера
Счетчик событий партнера — 4-битовое число событий (exception)
партнера, которые имели место со времени последнего получения
статусного слова в рамках отклика или сообщения trap. СчетчИ?
сбрасывается при занесении кода в поле статуса отклика, и перест*'
ет изменяться при достижении значения 15.
Сети передачи данных. Метод доступа 791
——-
Код события партнера — 4-битовое целое число, идентифициру-
ющее последнее событие партнера. Новое значение переписывает
предыдуЩее- Значения кодов представлены в таблице 4.4.15.10.
Таблица 4.4.15.10. Коды события партнера
^а^еяие кода Функция
— o' Не специфицировано
i IP-ошибка партнера
— 2 Ошибка аутентификации партнера (бит peer.authentic был равен I, а теперь =0)
3 Партнер не достижим (peer.reach стал равен нулю)
' 4 Партнер достижим (peer.reach стал не равен нулю)
5 Проблема с часами партнера
6-15 Зарезервировано на будущее
Слово состояния часов
Существует два способа подключить эталонные часы к NTP-
серверу, как специальный прибор, поддерживаемый операционной
системой или как партнера, управляемого NTP. Как и в случае
команды чтения статуса идентификатор ассоциации определяет, часы
какого из партнеров имеются в виду. При нулевом идентификаторе
речь идет о системных часах. Протокол поддерживает только одни
системные часы, число часов-партнеров практически не ограничено.
Статусное слово часов системы или партнера записывается в поле
статуса отклика на команды чтения или записи переменных, харак-
теризующих часы. Это слово может рассматриваться как расшире-
ние системного статусного слова или статусного слова партнера.
Формат слова описан ниже (см. также рис. 4.4.15.3).
Состояние часов — 8-битовое число, характеризующее текущее
состояние часов. Допустимые значения этого числа и их смысл пред-
ставлены в таблице 4.4.15.11.
Таблица 4.4.15.11. Коды состояния часов
Код Функция
0 Работа часов в пределах нормы
I Таймаут ответа
2 Плохой формат ответа
3 Сбой оборудования или программы
4 Потеря при передаче
5 Неверный формат или значение даты
6 Неверный формат или значение времени
7-255 Зарезервировано на будущее
7Э4 Гпава <
статус содержит статусное слово системы. В случае trap партнер^
поле идентификатора ассоциации соответствует партнеру, а поле
статус несет в себе его статусное слово. В поле данных опционно
может быть включено любое символьное сообщение (ASCII).
Аутентификация
Требования надежности NTP подобны аналогичным для других
протоколов, работающих с большим числом партнеров и служащих
для маршрутизации, управления и доступа к файлам. Система должна
противостоять случайным ошибкам и злонамеренным действиям.
Механизм управления доступом в NTP отвечает всем базовым
требованиям. Различные проверки препятствуют большинству воз-
можных атак, связанных с подменой временных меток.
Однако имеется возможность того, что хакер нарушит процедуру
синхронизации путем модификации NTP-сообщений. Для подавле-
ния такой возможности нужно привлекать криптографические ме-
ханизмы аутентификации (в частности сертификаты).
Механизм, который работает на прикладном уровне, служит для
того, чтобы исключить неавторизованную модификацию потока со-
общений. Это достигается с помощью контрольных крипто-сумм,
вычисляемых отправителем и проверяемых получателем. Однако
сам протокол NTP не имеет средств для работы с сертификатами й
ключами.
Процедура вычисления контрольной крипто-суммы использует
алгоритм DES (Data Encryption Standard) [NBS77].
Механизм аутентификации NTP
Когда предполагается использовать аутентификацию, инициа-
лизируется ряд переменных, определяющих выбор сертификата, ал-
горитма шифрования и крипто-ключ и, возможно, другие парамет-
ры. Процедуры инициализации и выбора этих переменных не рег-
ламентируются протоколом NTP. Набор переменных партнера и
пакетов может включать в себя следующие компоненты.
Бит разрешения аутентификации (peer.authenable). Этот бит
указывает, что ассоциация работает в режиме аутентификации. Для
сконфигурированных партнеров этот бит определяется на фазе
инициализации. Для не конфигурированных — этот бит делаетсй
равным 1, если приходящее сообщение содержит аутентификатор
противном случае =0.
Бит аутентификации (peer.authentic). Этот бит указывает,
последнее сообщение, полученное от партнера, было корректно ayreri-
тифицировано. /
Сети передачи данных. Метод доступа
795
Идентификатор ключа (peer.hostkeyid, peer.peerkeyid, pkt.keyid). Это
целое число идентифицирует криптографический ключ, используемый
для генерации кода аутентификации сообщения. Системная перемен-
ная peer.hostkeyid используется для активной ассоциации. Переменная
peer.peerkeyid инициализируется, когда ассоциация сформирована.
Криптографические ключи (sys.key). Это набор 64-битовых ключей
DES, где 7 младших бит каждого октета соответствуют битам 1-7
DES, а старший бит соответствует биту четности 8 (сумма нечетна).
Контрольная крипто-сумма (pkt.check). Крипто-сумма вычис-
ляется процедурой шифрования.
’ Поле аутентификатора состоит из двух субполей, одно содержит
переменную pkt.keyid, а другое переменную pkt.check, вычисленную
программой шифрования, вызываемой процедурой передачи прото-
кола NTP, а также программой дешифровки, которая вызывается
процедурой приема NTP. Ее присутствия определяется по общей
длине UDP-дейтограммы. Для целей аутентификации NTP-сообще-
ние дополняется нулями, для того чтобы сделать ее длину кратной
64 битам. Аутентификатор содержит 96 бит, куда входят 32-бито-
вый идентификатор ключа и 64-битовая крипто-сумма. Дополни-
тельная информация (например, о сертификате и алгоритме шифро-
вания), если необходимо, может быть вставлена между NTP-сообще-
нием и идентификатором ключа. Подобно аутентификатору эта
информация не включается в контрольное крипто-суммирование.
Процедуры аутентификации NTP
Когда используется аутентификация для реализации протокола
NTP, привлекается две дополнительные процедуры. Одна из них фор-
мирует крипто-сумму для передаваемых сообщений, а другая дешиф-
рует и проверяет корректность контрольной суммы получаемых сооб-
щений. Процедуры представляют собой варианты программ, исполь-
зуемых для реализации алгоритма DES и описанных в [NBS80]. На
самом деле процедура не связана жестко с алгоритмом DES, а лишь
предполагают работу с 64-битовыми блоками данных.
Временная шкала NTP и ее хронометрия
Ниже рассматривается соответствие временной шкалы NTP и
UTC (Coordinated Universal Time). Синхронизация часов предпола-
гает их согласование по частоте и времени. Для синхронизации
необходимо уметь сравнить их частоты и показания.
Первичная частота и стандарты времени
Первичными стандартами частоты являются осцилляторы с вы-
сокой стабильностью. Такие стандарты используют межуровневые
ПеРеходы в атомах водорода, цезия и рубидия. В таблице 4.4.15.13
приведены характеристики типичных стандартов времени. Л окал ь-
796
Гпава 4
ные же часы обычно используют некомпенсированные кварцевые
генераторы. Такие генераторы не только подвержены дрейфам под
действием изменения параметров окружающей среды, но системати-
чески меняют свои свойства со временем (старение).
Даже если кварцевый генератор имеет температурную компенса-
цию, его частота должна время от времени сравниваться первичным
стандартом для обеспечения высокой точности.
Сеть, в которой все часы фазированы и согласованы по частоте с
единым стандартом, называется изохронной. Сети, где разные часы
фазированы разными задающими генераторами, но все они привяза-
ны к одной базовой частоте называются плезиохронными. В плези-
охронных системах фазы разных осцилляторов могут дрейфовать друг
относительно друга, что может приводить к накоплению ошибок.
Обычно часовые осцилляторы классифицируются по трем пара-
метрам: стабильность, разброс и блуждание. Стабильность определя-
ется систематическими вариациями частоты со временем. Синони-
мом нестабильности является старение и дрейф. Разброс (называе-
мый также временным дрожанием) характеризует кратковременные
случайные вариации частоты с составляющими более 10 Гц, в то
время как блуждание характеризует медленные вариации частоты с
составляющими менее 10 Гц.
Таблица 4.4.15.13.
Точность и стабильность часов для различных слоев
Слой Минимальная точность (за день) Минимальная стабильность (за день)
1 1 X 10“ Не специфицировано
2 1.6 х 10 * 1 х 10lu
3 4.6 х Ю* 3.7 х IO'7
4 3.2 х 10 s Не специфицировано
Конструкция, работа и характеристики осциллятора слоя 1 пред-
полагаются сопоставимыми с национальными стандартами времени
и часто базируются на цезиевом стандарте. Часы слоя 4 соответ- :
ствуют требованиям обычных цифровых каналов и систем РВХ.
Слои 2-3 могут использоваться для работы с мощными синхронны-
ми каналами связи.
Раздача времени и частоты J
Для того чтобы атомное и обычное время могли быть взаимо- (
связаны, национальные администрации обеспечивают работу пер- /
вичных стандартов времени и частоты и совместно координируют:
их функционирование. Большинство морских держав поддержива*/
ют широковещательные радиослужбы времени.
Сети передачи данных. Метод доступа
797
Американский Национальный Институт Стандартов и Технологии
(NIST - National Institute of Standards and Technology) поддерживает
три радиослужбы для рассылки временной информации. Одна из них
использует передачу (ВЧ или CCIR диапазон 7) на частотах 2.5, 5,10,15
и 20 Мгц. Сигнал распространяется, отражаясь от верхних слоев атмос-
феры, что неизбежно приводит к непредсказуемым вариациям задерж-
ки на принимающей стороне. С 60-секундным интервалом передается
временной код, который транслируется на 100 килогерцной субнесущей
со скоростью передачи 1 бит/с. Этот код содержит информацию об UTC
времени и дате, но не включает в себя данных о текущем годе и опове-
щения о добавлении/вычитании секунды для последней минуты данно-
го дня. Существуют и другие сходные службы времени (например, в
Оттаве), гарантирующие точность на уровне 1-10 мсек. 4
Вторая служба времени NIST использует передачу (НЧ или CCIR
диапазон 5) на частоте 60 КГц, она доступна на континентальной
части США и вблизи берегов. Сигнал распространяется в нижней
части атмосферы и по этой причине слабо подвержен вариациям
* времени распространения. Временной код передается с периодом в
60 секунд со скоростью 1 бит/с. Достижимая точность составляет?
50 миллисекунд [BLA74]. Ряд европейских стран предлагают ана-
логичные службы времени (Великобритания — MSF; Германия —
DCF77). Коды времени здесь включают информацию о текущем
годе и предупреждение о добавляемой/вычитаемой секунде. Третья
служба NIST использует передачу на частоте 468 МГц (УВЧ или
CCIR диапазон 9) с геостационарных спутников GOES, три из кото-
рых перекрывают западное полушарие. Временной код перемежает-
ся с сообщениями, адресованными удаленным датчикам и состоит
из 600 4-битовых слов, передаваемых с периодом в 30 секунд. Вре-
менной код содержит информацию об UTC времени-дне-годе, а так-
же предупреждение о добавлении/вычитании секунды в конце дня.
Точность этой службы составляет 0,5 мсек. .
Министерство обороны США разработало глобальную систему
определения координат GPS (Global Positioning System). Эта систе-
ма базируется на 24 спутниках, движущихся по орбитам с перио£
дом 12 часов. Система GPS может обеспечить точность определе-
ния времени на уровне нескольких наносекунд [VAN84].
Американская береговая охрана в течение многих лет использу-
ет службу радионавигации LORAN-C [FRA82]. Эта служба обеспе-
чивает временную точность менее 1 мксек.
Система радионавигации военно-морского флота США и других
стран — OMEGA [VAS78] состоит из 8 передатчиков, работающих
на частотах от 10.2 до 13.1 КГц (УНЧ или CIR диапазон 4) и
798
Гпава 4
перекрывающих весь земной шар 24 часа в сутки. Точность этой
системы составляет около 1 мсек. Система OMEGA обеспечивает
высокую точность для частоты, но не передает временного кода. По
этой причине приемник должен предварительно получить географи-
ческие координаты с точностью до градуса и время UTC с точностью
5 секунд от независимых источников.
Заметим, что не все службы времени передают информацию о
текущем годе и предупреждения о добавлении/вычитании секунды
в конце суток. Протокол NTP позволяет решить эту проблему.
В течение многих лет наиболее важным применением времени
и частоты были всемирная навигация и космическая наука, кото-
рые зависят от наблюдений солнца, луны и звезд. За стандартную
секунду (в 1957 году) принята 1/31,556,925.9747 периода враще-
ния Земли вокруг Солнца (тропический год). Согласно этой шкалы
тропический год длится 365.2421987 дней, а лунный месяц 29.53059
дней. Однако тропический год может быть определен лишь с точно-
стью около 50 мсек.
С древнейших времен человечеству были известны три осцилля-
тора (процесса задающих временную шкалу) — вращение земли
вокруг своей оси, вращение Луны вокруг Земли и вращение Земли
вокруг Солнца. К сожалению, с точки требований современных тех- ,
нологий все эти три осциллятора не обладают достаточной стабиль-
ностью. В 1967 стандартная секунда была переопределена и теперь
равняется 9,192,631,770 периодов перехода в атоме цезия-133.
С 1972 стандарты времени и частоты базируются на международ-
ном атомном времени TAI (International Atomic Time). Точность
таких часов составляет около микросекунды в сутки. Важно то, что
новая шкала абсолютно однородна и не подвержена дрейфам.
Международное бюро мер и стандартов IBWM (International
Bureau of Weights and Measures) использует астрономические на-
блюдения, выполненные морской обсерваторией США и другими об-
серваториями для определения UTC.
Для более точной временной привязки событий после 1972 года
необходимо знать, когда вставлялись или удалялись секунды кор-
рекции (удаление пока никогда не производилось). Как определено
в докладе 517 CCIR, который воспроизведен в [BLA74], дополни-
тельные секунды вставляются после 23:59:59 в последний день :
июня или декабря. Неоднородность во временную шкалу (TAI), по-
мимо добавляемых секунд, вносят также 100 миллисекундные кор-;
рекции UT1, называемые DUT1, которые служат для повышений^
точности при навигации. Момент добавления секунды является на-
чалом новой (однородной) временной шкалы.
Сети передачи данных. Метод доступа
799
Временная шкала NTP базируется на шкале UTC, но необяза-
тельно совпадает с ней. В О часов 1 января 1972 начинается эра
UTC, часы NTP были установлены на 2,272,060,800 стандартных
секунд после 0 часов 1 января 1900.
Ссылки
[АВА89] Abate, et al. AT&T’s new approach to the synchronization of telecommu-
nication networks. IEEE Communications Magazine (April 1989), 35-45.
[ALL74a] Allan, D.W., J.H. Shoaf and D. Halford. Statistics of time and fre-
quency data analysis. In: Blair, B.E. (Ed.). Time and Frequency Theory
and Fundamentals. National Bureau of Standards Monograph 140, U.S.
Department of Commerce, 1974, 151-204.
[ALL74b] Allan, D.W., J.E. Gray and H.E. Machlan. The National Bureau of
Standards atomic time scale: generation, stability, accuracy and acces-
sibility. In: Blair, B.E. (Ed.). Time and Frequency Theory and Funda-
mentals. National Bureau of Standards Monograph 140, U.S. Depart-
ment of Commerce, 1974, 205-231.
[BEL86] Bell Communications Research. Digital Synchronization Network Plan.
Technical Advisory TA-NPL-000436, 1 November 1986.
[BER87] Bertsekas, D., and R. Gallager. Data Networks. Prentice-Hall, Engle-
wood Cliffs, NJ, 1987.
[BLA74] Blair, B.E. Time and frequency dissemination: an overview of princi-
ples and techniques. In: Blair, B.E. (Ed.). Time and Frequency Theory
and Fundamentals. National Bureau of Standards Monograph 140, U.S.
Department of Commerce, 1974, 233-314.
[BRA80] Braun, W.B. Short term frequency effects in networks of coupled oscil-
lators. IEEE Trans. Communications COM-28, 8 (August 1980), 1269-1275
[COL88] Cole, R., and C. Foxcroft. An experiment in clock synchronization. The
Computer Journal 31, 6 (1988), 496-502.
[DAR81a] Defense Advanced Research Projects Agency. Internet Protocol.
DARPA Network Working Group Report RFC-791, USC Information
Sciences Institute, September 1981.
[DAR81b] Defense Advanced Research Projects Agency. Internet Control Mes-
sage Protocol. DARPA Network Working Group Report RFC-792, USC
Information Sciences Institute, September 1981.
[DEC89] Digital Time Service Functional Specification Version T. 1.0.5. Digi-
tal Equipment Corporation, 1989
[DER90] Dershowitz, N., and E.M. Reingold. Calendrical Calculations. Software
Practice and Experience 20, 9 (September 1990), 899-928.
[FRA82] Frank, R.L. History of LORAN-C. Navigation 29, 1 (Spring 1982).
[GUS84] Gusella, R., and S. Zatti. TEMPO — A network time controller for a
distributed Berkeley UNIX system. IEEE Distributed Processing Tech-
nical Committee Newsletter 6, NoSI-2 (June 1984), 7-15. Also in: Proc.
Summer USENIX Conference (June 1984, Salt Lake City).
[GUS85a] Gusella, R., and S. Zatti. The Berkeley UNIX 4.3BSD time synchroni-
zation protocol: protocol specification. Technical Report UCB/CSD
85/250, University of California, Berkeley, June 1985.
800
Гпава 4
[GUS85b] Gusella, R., and S. Zatti. An election algorithm for a distributed
clock synchronization program. Technical Report UCB/CSD 86/275,
University of California, Berkeley, December 1985.
[HAL84] Halpern, J.Y., B. Simons, R. Strong and D. Dolly. Fault-tolerant clock
synchronization. Proc. Third Annual ACM Symposium on Principles
of Distributed Computing (August 1984), 89-102.
[JOR85] Jordan, E.C. (Ed). Reference Data for Engineers, Seventh Edition. H.W.
Sams & Co., New York, 1985.
[KOP87] Kopetz, H., and W. Ochsenreiter. Clock synchronization in distributed
real-time systems. IEEE Trans. Computers C-36, 8 (August 1987), 933-939.
[LAM78] Lamport, L., Time, clocks and the ordering of events in a distributed
system. Comm. ACM 21, 7 (July 1978), 558-565.
[LAM85] Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the
presence of faults. J. ACM 32, 1 (January 1985), 52-78.
[LIN80] Lindsay, W.C., and A.V. Kantak. Network synchronization of random
signals. IEEE Trans. Communications COM-28,8 (August 1980), 1260-1266.
[LUN84] Lundelius, J., and N.A. Lynch. A new fault-tolerant algorithm for
clock synchronization. Proc. Third Annual ACM Symposium on Prin-
ciples of Distributed Computing (August 1984),75-88.
[MAR85] Marzullo, K., and S. Owicki. Maintaining the time in a distributed
system. ACM Operating Systems Review 19, 3 (July 1985), 44-54.
[MIL81a] Mills, D.L. Time Synchronization in DCNET Hosts. DARPA Internet
Project Report IEN-173, COMSAT Laboratories, February 1981.
[MIL81b] Mills, D.L. DCNET Internet Clock Service. DARPA Network Work-
ing Group Report RFC-778, COMSAT Laboratories, April 1981.
[MIL83a] Mills, D.L. Internet Delay Experiments. DARPA Network Working
Group Report RFC-889, M/A-COM Linkabit, December 1983.
[MIL83b] Mills, D.L. DCN local-network protocols. DARPA Network Working
Group Report RFC-891, M/A-COM Linkabit, December 1983.
[MIL85a] Mills, D.L. Algorithms for synchronizing network clocks. DARPA
Network Working Group Report RFC-956, M/A-COM Linkabit, Sep-
tember 1985.
[MIL85b] Mills, D.L. Experiments in network clock synchronization. DARPA
Network Working Group Report RFC-957, M/A-COM Linkabit, Sep-
tember 1985.
[MIL85c] Mills, D.L. Network Time Protocol (NTP). DARPA Network Work-
ing Group Report RFC-958, M/A-COM Linkabit, September 1985.
[MIL88a] Mills, D.L. Network Time Protocol (version 1) — specification and
implementation. DARPA Network Working Group Report RFC-1059,
University of Delaware, July 1988.
[MIL88b] Mills, D.L. The Fuzzball. Proc. ACM SIGCOMM 88 Symposium (Palo
Alto, CA, August 1988), 115-122.
[MIL89] Mills, D.L. Network Time Protocol (version 2) — specification and
implementation. DARPA Network Working Group Report RFC-1119»
University of Delaware, September 1989.
[MIL90] Mills, D.L. Measured performance of the Network Time Protocol in the
Internet system. ACM Computer Communication Review 20, 1 (Janu-
ary 1990), 65-75.
Сети передачи данных. Метод доступа
801
[MIL91a] Mills, D.L. Internet time synchronization: the Network Time Proto-
col. IEEE Trans. Communications 39, 10 (October 1991), 1482-1493.
[MIL91b] Mills, D.L. On the chronology and metrology of computer network
timescales and their application to the Network Time Protocol. ACM
Computer Communications Review 21, 5 (October 1991), 8-17.
[MIT80] Mitra, D. Network synchronization: analysis of a hybrid of master-
slave and mutual synchronization. IEEE Trans. Communications COM-
28, 8 (August 1980), 1245-1259.
[NBS77] Data Encryption Standard. Federal Information Processing Standards
Publication 46. National Bureau of Standards, U.S. Department of
Commerce, 1977.
[NBS79] Time and Frequency Dissemination Services. NBS Special Publica-
tion 432, U.S. Department of Commerce, 1979
[NBS80] DES Modes of Operation. Federal Information Processing Standards
Publication 81. National Bureau of Standards, U.S. Department of
Commerce, December 1980.
[POS80] Postel, J. User Datagram Protocol. DARPA Network Working Group
Report RFC-768, USC Information Sciences Institute, August 1980.
[POS83a] Postel, J. Daytime protocol. DARPA Network Working Group Re-
port RFC-867, USC Information Sciences Institute, May 1983.
[POS83b] Postel, J. Time protocol. DARPA Network Working Group Report
RFC-868, USC Information Sciences Institute, May 1983.
[RIC88] Rickert, N.W. Non Byzantine clock synchronization — a program-
ming experiment. ACM Operating Systems Review 22, 1 (January
1988), 73-78.
[SCH86] Schneider, F.B. A paradigm for reliable clock synchronization. De-
partment of Computer Science Technical Report TR 86-735, Cornell
University, February 1986.
[SMI86] Smith, J. Modern Communications Circuits. McGraw-Hill, New York,
NY, 1986.
[SRI87] Srikanth, T.K., and S. Toueg. Optimal clock synchronization. J. ACM
34, 3 (July 1987), 626-645.
[STE88] Steiner, J.G., C. Neuman, and J.I. Schiller. Kerberos: an authentica-
tion service for open network systems. Proc. Winter USENIX Confer-
ence (February 1988).
[SU81] Su, Z. A specification of the Internet protocol (IP) timestamp option.
DARPA Network Working Group Report RFC-781. SRI Internation-
al, May 1981.
[TRI86] Tripathi,S.K.,and S.H. Chang. ETempo: a clock synchronization algo-
rithm for hierarchical LANs — implementation and measurements.
Systems Research Center Technical Report TR-86-48, University of
Maryland, 1986. >
[VAN84] Van Dierendonck, A.J., and W.C. Melton. Applications of time transfer
using NAVSTAR GPS. In: Global Positioning System, Papers Published
in Navigation, Vol. II, Institute of Navigation, Washington, DC, 1984.
[VAS78] Vass, E.R. OMEGA navigation system: present status and plans 1977-
1980. Navigation 25, 1 (Spring 1978).
26 Зак. № 3430 Семенов
802
Гпава 4
4.4.16. Простой сетевой протокол времени (SNTP]
версия 4 для IPv4, IPv6 и OSI
Протокол SNTP V 4 отличается от предыдущей версии NTP и
SNTP (Simple Network Time Protocol (SNTP) V.4 for IPv4, IPv6 and
OSI, D. Mills, RFC-2030) модификацией интерпретации заголовка с
целью осуществления совместимости адресации с IPv6 [DEE96] и
OSI [COL94].
1. Введение
Протокол сетевого времени (NTP V3), описанный в документе
RFC-1305 [MIL92], широко используется для синхронизации часов
ЭВМ в глобальном Интернет. Он обеспечивает доступ к национальным
системам точного времени. В большинстве мест Интернет протокол
гарантирует точность синхронизации с точностью 1-50 мс, в зависи-
мости от свойств источника синхронизации и сетевых задержек.
RFC-1305 специфицирует машину протокола NTP V3 в терми-
нах событий, состояний, функций перехода и действий. Кроме того,
тамш определены инженерные алгоритмы улучшения точности синх-
ронизации и выбора из списка эталонных источников, некоторые из
которых могут быть неисправны. Эти алгоритмы необходимы для
компенсации влияния вариаций задержки пакетов в сети Интернет.
Однако во многих обстоятельствах приемлемы точности порядка доли
секунды. В таких случаях используется более простые протоколы
времени [POS83]. Эти протоколы обычно используют RPC-обмен, где
клиент запрашивает время дня, а сервер присылает его значение в
секундах после некоторого известного эталонного момента.
NTP создан для использования клиентами и серверами с широ-
ким диапазоном возможностей для широкого интервала сетевых за-
держек и большого временного разброса. Большинство пользователей
NTP синхронизации используют программное обеспечение с полным
набором опций и алгоритмов (смотри http://www.eecis.udel.edu/~ntp).
SNTP V 4 предполагает совместимость с NTP и SNTP V 3 как
для клиентов, так и для серверов. Кроме того, клиенты и серверы
SNTP V.4 могут реализовывать расширения для работы в эникаст
режиме.
Клиенты SNTP должны работать только на самом верхнем
уровне субсети в конфигурациях, где синхронизация NTP или SNTP
клиентов не зависит от других клиентов. Серверы SNTP должны
работать только на первом (базовом) уровне субсети и в конфигура-
циях, где нет других источников синхронизации кроме надежных
радио или модемных служб точного времени.
Сети передачи данных. Метод доступа
803
2. Рабочие режимы и адресация
SNTP V.4 может работать в уникастном (точка-точка), мульти-
кастном (один передатчик - много приемников) или эникаст (не-
сколько передатчиков — один приемник). Уникастный клиент по-
сылает запросы специально выделенному серверу по его уникастно-
му адресу и ожидает отклика, из которого он может определить
время и опционно.RTT, а также сдвижку временной шкалы мест-
ных часов по отношению к шкале сервера. Мультикастный сервер
периодически посылает сообщения по локальному мультикаст-ад-
ресу (IPv4 или IPv6). Мультикастный клиент воспринимает полу-
чаемые данные и не посылает никаких запросов. Эникастный кли-
ент посылает запрос по локальному специально выделенному муль-
тикастному (IPv4 или IPv6) адресу, при этом один или более
эникатных серверов отправляют клиенту отклик. Клиент связыва-
ется с первым из них и в дальнейшем продолжает работу уже в
уникастном режиме адресации.
Мультикастные серверы должны реагировать на уникастные зап-
росы клиентов, а также самостоятельно посылать мультикастные
сообщения. Мультикастные клиенты могут посылать уникастные
запросы, чтобы определить задержку распространения пакетов в сети
между сервером и клиентом с тем, чтобы в дальнейшем продол-
жить работу в мультикастном режиме.
В уникастном режиме адреса клиенту и серверу присваиваются
согласно обычной схеме IPv4, IPv6 или OSI. В Мультикастном ре-
жиме сервер использует локальный широковещательный адрес или
мультикастный групповой адрес. Локальный широковещательный
IP-адрес имеет область действия, ограниченную субсетью, так как
маршрутизаторы не ретранслируют широковещательные 1Р-дейтог-
раммы. С другой стороны IP-адрес мультикастинг-группы имеет об-
ласть действия, распространяющуюся потенциально на весь Интер-
нет. Для IPv4 IANA для целей NTP выделила мультикастный груп-
повой адрес 224.0.1.1, который используется как для мультикаст
серверов, так и для эникаст клиентов.
Мультикастные клиенты прослушивают выделенный локальный
широковещательный адрес или мультикастный групповой адрес. В
случае мультикастного IP-адреса, мультикастный клиент и эникас-
тный сервер должны реализовать протокол IGMP (Internet Group
Management Protocol) [DEE89], для того чтобы местный маршрути-
затор подключился к мультикаст-группе и ретранслировал сообще-
ния, направленные по IPv4 или IPv6 мультикастным групповым
адресам, присвоенным IANA.
26*
804
Гпава 4
Очень важно оптимально выбрать значение поля TTL в IP-заго-
ловке мультикастинг-сообщения, для того чтобы ограничить сете-
вые ресурсы, используемые данным видом сервиса.
Режим эникаст сконструирован для использования с набором
взаимодействующих серверов, чьи адреса не известны клиенту зара-
нее. Эникастный клиент посылает запрос по локальному широкове-
щательному адресу или групповому мультикастинг-адресу. Для этой
цели используется групповой адрес NTP специально выделенный
IANA для этих целей. Один или более эникастных серверов воспри-
нимают этот запрос и отправляют отклик по уникастному адресу
клиента. Клиент устанавливает связь с сервером, от которого полу-
чил отклик раньше. Последующие отклики эникаст-серверов игно-
рируются.
В случае SNTP, существует реальная угроза того, что SNTP муль-
тикаст-клиент может быть введен в заблуждение поведением SNTP
или NTP-серверов (возможно и преднамеренным), так как все они
используют один и тот же групповой мультикаст-адрес, выделенный
для этих целей IANA. Где необходимо, для выбора сервера, извест-
ного клиенту может проводиться отбор по адресу. Опционной явля-
ется схема криптографической аутентификации, описанной в доку-
менте RFC-1305.
3. Формат временных меток NTP
Протокол SNTP использует стандартный формат временных
меток NTP, описанный в документе RFC-1305 h в предыдущих вер-
сиях стандарта. Для согласования со стандартной практикой в
Интернет данные NTP характеризуются целыми числами с фикси-
рованной запятой. Биты нумеруются так, что нулевой (старший)
разряд размещается слева. Если не оговорено обратного, все числа
не имеют знака и занимают все выделенное для них поле.
Так как временная метка NTP представляет собой наиважней-
шую часть протокола, для нее разработан специальный формат. Вре-
менные метки NTP характеризуются 64-битным числом без знака
с фиксированной запятой, которое равно количеству секунд с 0 ча-
сов 1 января 1900. Для целочисленной части выделено 32 бита и
столько же для дробной части (Рис. 4.4.16.1).
Рекомендуется заполнять несущественные младшие двоичные
разряды временной метки случайной битовой строкой, что исключа-
ет систематические ошибки округления и является средством де-
тектирования зацикливания. Одним из методов выполнения этого
условия является генерация случайной 64-битовой последователь-
ности, с последующим ее сдвигом вправо на число бит, равное коли-
Сети передачи данных. Метод доступа
805
честву значащих разрядов временной метки, и добавлением резуль-
тата к исходному значению временной метки.
Максимальное число, которое может быть представлено в данном
формате равно 4,294,967,295 секунд с точностью порядка 200 пико-
секунд, что может удовлетворить самым экзотическим требованиям.
0______4 8______________16_______________________31
Секунды
Доли секунды (свободные разряды заполняются нулями)
Рис. 4.4.16.1. Формат представления временной метки
Заметим что в 1968 (2,147,483,648 секунда) старший бит (бит
0 целочисленной части) стал равным 1 и 64-битовое поле перепол-
нится в 2036 году. Если NTP или SNTP будут испрльзоваться в
2036 г, будут необходимы некоторые внешние по отношению к дан-
ному протоколу меры для определения того относительно 1900 или
2036 года отсчитана приведенная дата (это справедливо и для дру-
гих дат, кратных 136 годам).
Так как формат временных меток NTP использовался в течение
последних 17 лет, остается возможность того, что он будет исполь-
зоваться еще 35 лет. Так как временных меток NTP до 1968 не
существует, можно считать приемлемым, что при бите 0 равном 1,
UTC-время лежит в диапазоне 1968-2036 с началом отсчета 0 час.
0 мин. 0 сек. 1 января 1900 г. Если же бит 0 равен нулю, время
лежит в диапазоне 2036-2104 г., а UTC-время отсчитывается от 6
час. 28 мин. 16 сек. 7 февраля 2036. Заметим, что при этом вычис-
лении 2000 год не считался високосным.
4. Формат сообщений NTP
Протоколы NTP и SNTP используют в качестве транспортного
протокол UDP. При этом работает UDP-порт 123 (NTP), который
проставляется как в поле порта отправителя, так и получателя
UDP-заголовка.
Ниже приводится описание формата сообщений NTP/SNTP V.4,
которые размещаются после UDP-заголовка. Этот формат иденти-
чен описанному в RFC-1305, за исключением содержимого поля
идентификатора эталона (reference identifier). Поля заголовка пред-
ставлены на рис. 4.4.16.2:
Поле LI (Leap Indicator) содержит два бита кода предупрежде-
ния о добавлении/удалении секунды в последней минуте текущего
Дня. Значения кодов поля LI приведены в таблице 4.4.15.1:
806
Гпава 4
0 2 5 8
16 24 31
LI VM Режим Слой Регистрация Точность
Root Delay
Root Dispersion
Идентификатор эталона
Эталонная временная метка (64)
Originate Timestamp (64)
Receive Timestamp (64)
Transmit Timestamp (64)
Ключевой идентификатор (опционно) (32)
Дайджест сообщения (опционно) (128)
Рис. 4.4.16.2. Формат заголовка SNTP-пакета
Поле VN (Version Number - номер версии) имеет длину три бита
и содержит номер версии протокола NTP/SNTP. Это поле содержит
3 для V.3 (только IPv4) и 4 для V.4 (IPv4, IPv6 и OSI).
Поле режим также содержит три бита и указывает на код ре-
жима. Значения кодов режима представлены в таблице 4.4.16.2.
В уникастном и эникастном режиме клиент при запросе уста-
навливает это поле равным 3 (клиент), а сервер в отклике устанав-
ливает его равным 4. В мультикастном режиме сервер записывает
в данное поле код 5 (широковещательный).
Поле слой (Stratum) содержит восемь бит, указывающих на уро-
вень локальных часов. Значения кодов поля слой представлены в
таблице 4.4.16.3.
Поле интервал запросов (Poll Interval — регистрация) содер-
жит 8 бит и указывает на максимальный интервал между последо-
вательными сообщениями. Код (к) характеризует показатель степе-
ни 2. Интервал между запросами равен 2к секунд. Значения, кото-
рые могут появиться в этом поле лежат в диапазоне от 4 (16 сек)
до 14 (16284 сек); однако большинство приложений использует
субдиапазон от 6 (64 сек.) до 10 (1024 сек).
Поле точность имеет 8 бит и характеризует точность локаль-
ных часов, в секундах (показатель степени 2, как и в предыдущем
поле). Значения кодов в этом поле лежат в диапазоне -6 для часто-
ты сети переменного тока до -20 для микросекундных часов.
Сети передачи данных. Метод доступа
807
Поле Root Delay (базовая задержка) представляет собой 32-би-
товое число с фиксированной запятой, характеризующее RTT в се-
кундах до эталона точного времени. Запятая в этом числе распола-
гается между битами 15 и 16. Заметим, что эта переменная может
быть положительной или отрицательной. Диапазон значений кодов
этого поля лежит в диапазоне от минус нескольких миллисекунд до
плюс нескольких сотен миллисекунд.
Поле Root Dispersion (базовая дисперсия) представляет собой
32-битовое число без знака с фиксированной запятой, указывающее
на номинальное значение временной ошибки относительно эталона
в секундах. Разброс значений этого поля лежит в пределах от нуля
до нескольких сот миллисекунд.
Поле идентификатор эталона, представляет собой 32-битовую
строку, которая позволяет однозначно идентифицировать эталон
времени. В случае первичных серверов (слой 0 или 1) NTP V.3 или
V.4, идентификатор представляет собой четырех символьную ASCII-
строку, размещенную в левой части поля. Свободная часть поля за-
полняется нулями. Для вторичных серверов NTP V.3, идентифика-
тор равен 32-битовому адресу (IPv4) эталонного источника. Для вто-
ричных серверов NTP V.4, в качестве идентификатора используются
младшие 32 бита последней временной метки эталонного источника.
Первичные серверы NTP (слой 1) должны заносить в это поле коды,
идентифицирующие внешние эталоны согласно таблице 4.4.16.4. Если
код в таблице отсутствует, допускаются и другие «коды.
Поле эталонная временная метка характеризует время, когда
локальные часы были установлены или поправлены (64-битовый
формат временной метки).
Поле Originate Timestamp (исходная временная метка) соответ-
ствует времени, когда клиент направил запрос серверу (64-битовый
формат временной метки).
Поле Receive Timestamp характеризует время, когда запрос при-
шел на сервер (64-битовый формат временной метки).
Поле Transmit Timestamp соответствует времени, когда сервер
послал отклик клиенту (64-битовый формат временной метки).
Поле аутентификатор (опционно) используется, когда необхо-
дима аутентификация, и содержит в себе ключевой идентификатор
и сообщение.
Поле дайджест хранит код аутентификации сообщения МАС
(Message Authentication Code).
808
Гпава 4
Таблица 4.4.16.1. Коды идентификатора эталона
ID-код Внешний эталонный источник
LOCL В качестве первичного эталона для субсети используются некалиброванные внутренние часы, которые не имеют внешнего источника синхронизации
PPS Атомные часы или другой источник, выдающий импульс каждую секунду и индивидуально калиброванный с использованием национального стандарта времени
ACTS Модемная служба NIST (работает через коммутируемую телефонную сеть)
USNO Модемная служба USNO
РТВ Модемная служба РТВ (Германия)
TDF Радио 164 Кгц (Allouis Франция)
DCF Радио 77.5 Кгц (Mainflingen, Германия)
MSF Радио 60 Кгц (Rugby, Англия)
WWV Радио 2.5, 5, 10, 15, 20 МГц (Ft. Collins, США)
WWVB Радио 60 Кгц (Boulder, US)
WWVH Радио 2.5, 5, 10, 15 МГц (Кауи Гавайи, США)
сни Радио 3330, 7335, 14670 Кгц (Оттава, Канада)
LORC Радионавигационная система LORAN-C
OMEG Радионавигационная система OMEGA
GPS Глобальная служба определения местоположения
GOES Геостационарный спутник контроля за окружающей средой
5. Операции клиента SNTP
Клиент SNTP может работать в мультикастном, уникастном и -
эникаситном режимах. В мультикастном режиме клиент не посылает
никаких запросов и ждет широковещательных сообщений (режим 5)
от специально выделенного мультикастного сервера. В уникастном
режиме клиент посылает запросы (режим 3) специально выделенному
серверу и ожидает от него отклики (режим 4). В эникартном режиме
клиент посылает запросы (режим 3) по специально выделенному мес-
тному широковещательному или мультикастному адресу и ожидает
отклика (режим 4) от одного или более эникастных серверов. Клиент
использует первый полученный отклик и устанавливает с соответству-
ющим сервером связь в уникастном режиме. Последующие отклики
от данного, или других серверов игнорируются. Запросы номинально
посылаются с интервалом от 64 до 1024 секунд, в зависимости от
стабильности частоты клиента и от требуемой точности.
Уникастные или эникастные клиенты используют заголовок со-
общения NTP, посылают запрос серверу и считывают время дня из
Сети передачи данных. Метод доступа
809
поля Transmit Timestamp отклика. Для этой цели все поля заголов-
ка NTP могут быть установлены равными нулю, за исключением
первого октета и (опционно) поля Transmit Timestamp. В первом
октете поле LI устанавливается равным 0 (никаких предупрежде-
ний), а в поле режим заносится код 3 (клиент). Поле VN должно
соответствовать номеру версии сервера NTP/SNTP; однако, серверы
V.4 воспринимают и предыдущие версии. Серверы V.3 (RFC-1305) и
версии 2 (RFC-1119) воспринимают предшествующие версии, вклю-
чая версию 1 (RFC-1059). Версия О (RFC-959) в настоящее время
уже не поддерживается. Клиентам рекомендуется использовать пос-
леднюю версию, которую поддерживает выбранный сервер.
Чтобы вычислить полную циклическую задержку d и смещение
локальных часов по отношению к серверу t, клиент устанавливает
значение поля transmit timestamp в запросе равным времени дня
согласно часам клиента и в соответствии с форматом временных
меток NTP. Сервер копирует этот код в поле originate timestamp
отклика и устанавливает поле receive timestamp и transmit timestamp
в соответствии с показанием своих часов.
Когда будет получен отклик от сервера, клиент определяет зна-
чение переменной Destination Timestamp, как время прибытия по
своим часам. В таблице 4.4.16.2 рассмотрены все 4 типа времен-
ных меток.
Таблица 4.4.16.2. Типы временных меток
Имя временной метки ID Когда генерируется
Originate Timestamp * (исходная метка) Т1 Время отправки запроса клиента
Receive Timestamp (метка получения) Т2 Время получения запроса сервером
Transmit Timestamp (метка посылки) ТЗ Время посылки отклика сервером
Destination Timestamp (метка назначения) Т4 Время получения отклика клиентом
Циклическая (roundtrip) задержка d и смещение локальных ча-
сов t определяются как:
d = (Т4 — Tl) — (Т2 — ТЗ) t = ((Т2 — Т1) + (ТЗ — Т4)) / 2.
В таблице 4.4.16.3 собраны операции клиента в уникаст, эни-
Каст и мультикаст режимах. Рекомендуемые проверки ошибок пред-
ъявлены в колонках таблицы «отклик» и «мультикаст». Сообще-
810
Гпава 4 1
Таблица 4.4.18.3. Операции клиента и значения полей заголовка
Имя поля Уникаст/Эникаст Мульти каст
Запрос Отклик
LI 0 0-2 0-2
VN (номер версии) 1-4 копируется из запроса 1-4
Режим 3 '4 5
Слой 0 1-14 1-14
Запрос 0 Игнорируется Игнорируется
Точность 0 Игнорируется Игнорируется
Root Delay 0 Игнорируется Игнорируется
Root Dispersion 0 Игнорируется Игнорируется
Reference Identifier 0 Игнорируется Игнорируется
Reference Timestamp 0 Игнорируется Игнорируется
Originate Timestamp 0 (смотри текст) Игнорируется
Receive Timestamp 0 (смотри текст) Игнорируется
Transmit Timestamp (смотри текст) не равно нулю не равно нулю
Аутентификатор опционно опционно опционно
ние следует рассматривать как корректное только в случае, если все
поля содержат допустимые коды. Следует ли воспринимать сообще-
ние, если оно содержит неверные значения для Доля (ей), помеченно-
го ремаркой «Игнорируется», зависит от конкретной реализации
программы. l
6. Операции сервера SNTP
Сервер SNTP может работать в уникастном, эникастном или
мультикастном режимах, а также реализовать любую из комбина-
ций этих режимов. В уникаст и эникаст режимах сервер получает
запросы (режим 3), модифицирует определенные поля в заголовке
NTP, и посылает отклик (режим 4), допускается использование того
же буфера сообщения, что и в случае запроса. В режиме эникаст
сервер прослушивает определенный широковещательный или груп-
повой мультикаст-адрес, определяемый IANA, но использует свой
собственный уникастный адрес в поле адреса отправителя отклика.
За исключением выбора адреса в отклике работа сервера в эникаст
и уникаст режима идентична. Мультикастные сообщения обычно
посылаются с интервалом от 64 до 1024 сек, в зависимости от
стабильности часов клиента и требуемой точности.
В эникаст и уникаст режимах поля VN и регистрация (Poll)
запроса копируются без изменений в отклик. Если поле режим
запроса содержит код 3 (клиент), оно делается в отклике равным 4
СетИ передачи данных. Метод доступа
811
(сервер); в противном случае в это поле записывается 2 (симмет-
ричный пассивный), для того чтобы обеспечить соответствие со спе-
цификацией NTP. Это позволяет клиентам, сконфигурированным
для симметричного активного режима (режим 1) успешно работать,
даже если конфигурация не является оптимальной. В мультикаст-
ном режиме в поле VN заносится код 4, в поле режим код 5 (широ-
ковещательный) и в поле регистрация целая часть значение лога-
рифма по основанию 2 от длительности периода посылки запросов.
Заметим, что крайне желательно чтобы серверы, поддерживаю-
щие мультикастинг, поддерживали и уникастный режим. Это необ-
ходимо для измерения RTT клиент/сервер, прежде чем осуществ-
лять регулярный обмен в мультикастном режиме.
В уникастном и эникастном режимах сервер может реагировать,
а может и игнорировать запросы, если не синхронизован надлежа-
щим образом с помощью радио-часов. Но предпочтительным пове-
дением является присылка отклика в любом случае, так как позво-
ляет убедиться в достижимости сервера. В мультикастном режиме
сервер посылает широковещательные сообщения, только если он
синхронизован.
Остальные поля заголовка NTP заполняются следующим обра-
зом. Если сервер синхронизован и функционирует правильно, в поле
LI заносится 0, а в поле слой - 1 (первичный сервер). Если это не
так, в поле слой записывается 0, а в поле Ы — 3. В поле точность
заносится код, характеризующий точность локальных часов. Для
всех практических случаев этот код вычисляется, как отрицатель-
ное число бит справа от запятой в формате временной метки NTP.
Поля Root Delay и Root Dispersion для первичного сервера делаются
равными 0. Поле Root Dispersion опционно может быть сделано
равным значению, соответствующему максимальной ожидаемой
ошибке радио-часов. В поле Reference Identifier заносится иденти-
фикатор первичного эталона времени, как это указано в таблице
4.4.16.1.
Поля временных меток заполняются следующим образом. Если
сервер не синхронизован или только что включился, все временные
метки устанавливаются равными нулю. Если сервер синхронизован,
в поле Reference Timestamp записывается время последней коррек-
ции по радио-часам или модему. В уникастном и эникастном ре-
жимах в поля Receive Timestamp и Transmit Timestamp заносится
время дня, когда было послано сообщение, а в поле Originate
Timestamp записывается неизмененная копия поля Transmit
Timestamp из запроса. В мультикастном режиме в поля Originate
Timestamp и Receive Timestamp заносится 0, а в Transmit Timestamp
812
Гпава 4
время дня, когда послано сообщение. В таблице 4.4.16.4 представ-
лены все перечисленные операции.
Наиболее важным индикатором неисправности сервера являет-
ся поле Ы, в котором код 3 указывает на отсутствие синхрониза-
ции. Когда получено именно это значение, клиент должен проигно-
рировать сообщение сервера вне зависимости от содержимого дру-
гих полей.
Таблица 4.4.16.4
Имя поля Уникаст/Эникаст Мультикаст
Запрос Отклик
U Игнорируется 0 или 3 0 или 3
VN I-4 копия из запроса 4
Режим 3 2 или 4 5
Слой Игнорируется I I
Регистрация Игнорируется копия из запроса log2 периода запросов
Точность Игнорируется -log2 числа значащих бит сервера -log2 числа значащих бит сервера
Root Delay Игнорируется 0 0
Root Dispersion Игнорируется 0 0
Идентификатор эталона Игнорируется Идентификатор эталона Идентифика- тор эталона
r Reference Timestamp Игнорируется Время последней коррекции по радио-часам Время последней коррекции по радио-часам
Originate Timestamp Игнорируется Копируется из поля transmit timestamp 0
Receive Timestamp Игнорируется Время дня 0
Transmit Timestamp (см. текст) Время дня Иремя дня
Аутентификатор Опционно Опционно Опционно
7. Конфигурация и управление
Исходная конфигурация SNTP серверов и клиентов может быть
произведена на основе конфигурационного файла, если такой файл
имеется, или через последовательный порт. Предполагается, что SNTP
серверы и клиенты практически не требуют какого-то конфигуриро-
вания, специфического для данного узла (помимо IP-адреса, маски
субсети или адреса OSI NSAP).
Сети передачи данных. Метод доступа
813
Уникастные клиенты должны быть снабжены именем сервера
или его адресом. Если используется имя сервера, то необходим один
или несколько адресов ближайших DNS-серверов. Мультикастные
серверы и эникастные клиенты должны снабжаться значением TTL,
а также местным широковещательным или групповым мульти-
кастным адресом. Эникастные серверы и мультикастные клиенты
могут конфигурироваться с привлечением списков пар адрес-мас-
ка. Это обеспечивает контроль доступа, так что операции будут
производиться только с известными клиентами или серверами. Эти
серверы и клиенты должны поддерживать протокол IGMP, а также
знать местный широковещательный или групповой мультикаст-
ный адрес.
Существует несколько сценариев, которые помогают обнаружить
и выбрать сервер для SNTP клиента без предварительной конфигу-
рации (IP-адрес и маска субсети предполагается известной). Для IP-
субсети или сегмента LAN, содержащих работающий NTP-сервер
клиент может быть сконфигурирован для мультикастного режима,
используя местный широковещательный адрес. Тот же подход мо-
жет быть применен для других серверов, используя групповой муль-
тикастинг-адрес. В обоих случаях предоставление списка адресов-
масок серверов является желательным.
В другом сценарии, удобном для протяженных сетей с больши-
ми задержками распространения клиенты могут конфигурировать-
ся для эникастного режима, как на начальной фазе, так и в случае,
когда выбранный уникастный источник становится недоступным.
Следуя протоколу, клиент устанавливает связь с первым отклик-
нувшимся сервером и далее продолжает обмен в уникастном режи-
ме. В этом режиме локальные часы могут автоматически корректи-
роваться с учетом задержки распространения.
В еще одном сценарии, удобном для любой сети, где мультикас-
тные услуги недоступны, DNS может быть сконфигурирована с од-
ним CNAME, аналогично time.domain.net, и списком адресных за-
писей для серверов NTP в домене. Используя адрес time.domain.net
И получив список, клиент выбирает сервер и начинает с ним работу
в Уникастном режиме.
8. Ссылки
[COL94] Colella, R., R. Callon, Е. Gardner, Y. Rekhter, «Guidelines for OSI
NSAP allocation in the Internet», RFC 1629, NIST, May 1994.
[LAR81] Postel, J., «Internet Protocol», STD 5, RFC 791, USC Information
Sciences Institute, Septefnber 1981.
[UEE89] Deering, S., «Host extensions for IP multicasting», STD 5, RFC
814
Гпава 4
1112, Stanford University, August 1989.
[DEE96] Deering, S., R. Hinden, «Internet Protocol, Version.6 (IPv6) Specifi-
cation», RFC 1883, Xerox and Ipsilon, January 1996.
[D0B91] Dobbins, K, W. Haggerty, C. Shue, «OSI connectionless transport
services on top of UDP — Version: 1», RFC 1240, Open Software
Foundation, June 1991.
[EAS95] Eastlake, D., 3rd., and C. Kaufman, «Domain Name System Security
Extensions», Work in Progress.
[FUR94] Furniss, P., «Octet sequences for upper-layer OSI to support basic
communications applications», RFC 1698, Consultant, October 1994.
[HIN96] Hinden, R., and S. Deering, «IP Version 6 addressing Architec-
ture», RFC 1884, Ipsilon and Xerox, January 1996. —
[ISO86] International Standards 8602 — Information Processing Systems
— OSI: Connectionless Transport Protocol Specification. Interna-
tional Standards Organization, December 1986.
[MIL92] Mills, D., «Network Time Protocol (V.3) specification, implementation
and analysis», RFC 1305, University of Delaware, March 1992.
[PAR93] Partridge, С., T. Mendez and W. Milliken, «Host anycasting
service», RFC 1546, Bolt Beranek Newman, November 1993.
[POS80] Postel, J., «User Datagram Protocol», STD 6, RFC 768, USC Informa-
tion Sciences Institute, August 1980.
[POS83] Postel, J., «Time Protocol», STD 26, RFC 868, USC Information
Sciences Institute, May 1983.
Сети передачи данных. Метод доступа
815
4.5.1. Процедура зондирования элементов Интернет [PING]
При работе в Интернет время от времени возникают ситуации,
когда нужно определить, работоспособен ли тот или иной канал
или узел, а в случае работы с динамическими протоколами маршру-
тизации выяснить, по какому из каналов вы в данный момент рабо-
таете. Используется эта процедура и для оценки вероятности поте-
ри пакетов в заданных сегментах сети или каналах. Для решения
этих задач удобна программа Ping.
Ping — это процедура, которая базируется на IP-, ICMP- и UDP-
протоколах пересылки дейтограмм и слуясит для трассировки мар-
шрутов и проверки работоспособности каналов и узлов. Для реше-
ния поставленной задачи PING использует отклики протокола ICMP.
Применяется PING и при отладке сетевых продуктов. Трассиров-
ка может выполняться, например, посредством команды ping -q
<Internet_aflpec> (пакет РСТСР). При выполнении этой команды
ЭВМ сообщит вам Internet адреса всех промежуточных узлов, их
имена и время распространения отклика от указанного вами узла.
Следует иметь в виду, что трассировка осуществляется непосред-
ственно с помощью IP-протокола (опция записи адресов промежу-
точных узлов). Ниже приведен пример использования команды
Ping. Если вы просто напечатаете команду ping (пакет РСТСР), то
ЭВМ выдаст на экран справочную таблицу по использованию этой
команды:
Usage:
ping [-options] host
options:
-d [bytes] dump input packet (пропечатка входных пакетов).
-d# [bytes] dump output packet (пропечатка выходных
пакетов).
-e cancel extended (отмена дополнительных
security мер безопасности)
-i seconds IP time to live (установка времени жизни
пакетов IP)
“j dest l...dest n loose source routing (свободная маршрутизация)
“k dest I...dest n strict source routing (принудительная
it маршрутизация).
4 length set length of icmp (установить длину данных
data ‘для ICMP).
816 Гпава 4
-n times ping host times number of times (провести зондирование J ЭВМ заданное число раз).
-0 no-op option (ни каких опций для операций).
-р precedence set IP precedence (установка IP- предпочтения).
-q trace route (трассировка маршрута).
-г record route (запись маршрута).
-s level [authority] basic security (базовый уровень безопасности).
-t ping forever (режим бесконечного ping).
-v type set type of service (установка типа операции).
-w seconds time to wait for answer (установка времени ожидания ответа).
-x [{113 destl..destn}] timestamp option (опция временных меток).
-z quiet mode (набор статистики отключен).
Команда трассировки маршрута ИТЭФ — сервер научно-иссле-
довательской станции США Мак-Мурдо в Антарктиде (запись в
файл route.txt):
ping -q mcmurdo-gw.mcmurdo.gov > route.txt
Содержимое файла route.txt будет иметь вид (сегодня этот мар-
шрут имеет уже иной вид):
hop 1: 193.124.224.190 ??? имя для GW ИТЭФ
hop 2: пока не придумано 193.124.137.13 MSU-Tower.Moscow.RU. Вперед, в космос
hop 3: . Radio-MSU.net 193.124.137.9 NPI-MSU.Moscow.RU. Через спутник
hop 4: Radio-MSU.net "Радуга” 193.124.137.6 DESY.Hamburg.DE.Radio пакеты совершили
hop 5: -MSU.net мягкую посадку в Гамбурге, ДЕЗИ 188.1.133.56 dante.WiN-lP.DFN.DE
hop 6: 193.172.4.12 duesseldorf2.empb.net
hop 7: 193.172.4.8 amsterdam6.empb.net
hop 8: 193.172.12.6 Amsterdaml.dante.net Пересекаем
hop 9: Атлантический океан 194.41.0.42 New-Yorkl.dante.net вступили на землю
hop 10: США 192.103.63.5 en-0.cnss35.New-
York.t3.ans.net
Qern передачи данных. Метод доступа
817
hop 11: 140.222.32.222 mf-0.cnss32.New- York.t3.ans.net
hop 12: 140.222.56.2 t3-1 .cnss56.Washington- DC.t3.ans.net
hop 13: 140.222.145.1 t3-0.enssl45.t3.ans.net
hop 14: 192.203.229.243 SURA2.NSN.NASA.GOV Снова в космос
hop 15: 128.161.166.1 GSFC8.NSN.NASA.GOV но теперь через американский
hop 16: 128.161.232.1 hop 17: 128.161.1.1 GSFC12.NSN.NASAGOV спутник ARC1NEW.NSN.NASA. GOV
hop 18: 192.203.230.2 hop 19: 192.100.12.2 hop 20: 128.161.115.2 ARC1.NSN.NASA.GOV ARC2.NSN.NASA.GOV MCMURDO.NSN.NASA. Оденьте шапку, мы в GOV Антарктиде!
Target 157.132.100.1 reached on hop 21 round-trip time 1370 ms
Фантастика, мы пересекли туда и обратно Европу, два океана и
США с востока на запад, побывали в Антарктиде и все это менее
чем за полторы секунды.
Ping позволяет не только проверить работоспособность канала,
но измерить ряд его характеристик, включая надежность (например,
версия ping для SUN):
PING -s cernvm.cern.ch 100 64 (пакеты по 100 байт посылаются
64 раза)
108 bytes from crnvma.cern.ch (128.141.2.4): icmp_seq=0.
time=606. Ms
......... (результаты пересылки пакетов с номерами 1-61
опущены)
108 bytes from crnvma.cern.ch (128.141.2.4): icmp_seq=62.
time=667. Ms
108 bytes from crnvma.cern.ch (128.141.2.4): icmp_seq==63.
time=628. Ms
— PING Statistics----
64 packets transmitted, 63 packets received, 1% packet loss (процент
потерянных пакетов)
r°und-trip (ms) min/avg/max = 600/626/702
Для получения большей точности следует послать большее число
Пакетов. В последней строке приведены результаты измерения RTT,
гДе представлены минимальное/среднее/максимальное значения.
818 Глава 4
Наибольшее число модификаций имеет BSD-версия ping, если на
вашей ЭВМ нет этой удобной программы, можно воспользоваться
общедоступной версией по адресу:
ftp.uu.net /unix/bsd-sources/sbin/ping (см. также приложения)^
Сходную информацию позволяет получить и программа traceroute
(использует непосредственно 1Р-пакеты):
traceroute -п cernvm.cern.ch
traceroute to crnvma.cern.ch (128.141.2.4) 30 hops max, 40 byte
packets
1 193.124.224.50 3 ms 2 ms 2 ms
2 194.85.112.130 3 ms 3 ms 3 ms
3 194.67.80.5 4 ms 3 ms 3 ms
4 193.124.137.6 534 ms 534 ms 534 ms
5 188.1.56.5 545 ms 545 ms 546 ms
6 193.172.4.12 558 ms (ttl=59!) 549 ms (ttl=59!) 548 ms (ttl==59!)
7 193.172.4.30 580 ms (ttl=58!) 581 ms (ttl=58!) 581 ms (ttl=58!)
8 193.172.24.10 586 ms 585 ms 597 ms
9 192.65.185.1 593 ms 587 ms 598 ms
10 128.141.2.4 628 ms 602 ms 619 ms
При написании программ, использующих протокол ICMP, полез-
но воспользоваться отладочной опцией PING, которая позволяет
получить на экране шестнадцатеричный образ посылаемого и полу-
чаемого пакетов:
ping -d# 300 ns.itep.ru (версия РСТСР, запрос отклика серверу
имен, число байт, подлежащих выдаче,
равно 300)
Dump of outgoing packet
Version = 4 IP header length = 5 Precedence = Routine
Type of Service = Normal
Total length = 284 Protocol == 1 TTL = 64
45 00 01 1C 00 02 00 00 40 01 71 29 CO 94 A6 81 Cl 7C E0 23
IP-заголовок
08 00 8D BD E9 03 00 01 ... ICMP-заголовок
host responding, time = 60 ms
Выдачи ради экономии места сильно сокращены. Тексты паке-
тов начинаются с кодов IP-версии (=4) и длины заголовка (=5),
далее следует байт TOS=0, два байта длины пакета (01 1С) и т.д. в
соответствии с требованиями IP-протокола.
дети передачи данных. Метод доступа
819
ping 300 ns.itep.ru (команда получения текста пакета-отклика
на запрос)
host responding, time = 25 ms
Dump of incoming packet
Version = 4 IP header length = 5 Precedence = Routine
Type of service = Normal
Total length = 284 Protocol = 1 TTL = 254
45 00 01 1C EE 29 00 00 FE 01 C5 00 Cl 7C E0 23 CO 94 A6 81
00 00 93 BD EB 03 00 01 .........
Версия программы PING написана в ИТЭФ (Москва, разработ-
чик Нилов Р.А.). Эта программа, работающая в среде Windows, по-
зволяет зондировать практически любое число узлов с любой пери-
одичностью. При этом задается время таймаута и длина пакета.
На экран (или в файл) выдается статистика испытаний. Такого
рода программы легко можно создать с помощью языка Perl.
4.5.2. Получение информации о пользователях и узлах
сети (Finger)
Finger является простым протоколом (RFC-1288), который слу-
жит для получения информации о пользователях узлов Internet.
Протокол использует ТСР-порт 79. Команда Finger может дать вам
данные о списке пользователей, которые работают в данный момент
на интересующей вас ЭВМ, о конкретном пользователе (дата после-
днего сеанса входа в систему и т.д.), о списке загруженных задач, о
типах терминалов. Данный протокол обеспечивает интерфейс для
удаленной информационной программы пользователя (RUIP - Remote
User Information Program).
Первоначальная версия такой программы была написана Les
Earnest. Окончательная версия протокола была подготовлена Earl
Killian из Мессачусетского Технологического Института и Brian
Harvey (SAIL).
Протокол Finger базируется на TCP. Локальная ЭВМ осуществ-
ляет TCP-соединение с удаленным узлом через указанный порт.
После этого становится доступной программа RUIP и пользователь
может посылать ей свои запросы. Каждый запрос представляет со-
бой строку текста. RUIP, получив запрос, анализирует его и присы-
лает ответ, после чего соединение закрывается.
Любые пересылаемые данные должны иметь формат ASCII, не
иметь контроля по четности и каждая строка должна завершаться
Последовательностью CRLF (ASCII 13, за которым следует ASCII 10).
820
Гпава 4
Программа RUIP должна воспринимать любые запросы Finger.
Такие запросы могут иметь следующий формат:
{Q1} [{W}|{W}{S}{U}]{C}
{Q2} [{W}{S}][{U}]{H}{C}
где {U} ::= имя_пользователя
{Н} ©hostname | @hostname{H}
{W} /W
{S} <SP> | <SP>{S}
{С} <CRLF>
{H}, является рекурсивным, по этой причине не существует ка-
ких-либо ограничений на число лексем типа ©hostname в запросе.
В примере спецификации {Q2}, число лексем ©hostname не может
превышать двух.
Следует иметь в виду, что в случае запросов «finger
user@host<CRLF>». Программа RUIP в действительности получит
«user<CRLF>».
Запрос {Q2} требует переадресации запроса другой программе
RUIP. Программа RUIP может либо осуществить эту процедуру,
либо отказать в переадресации. В случае выполнения запроса она
должна это подтвердить:
Сообщая, что:
ЭВМ <Н1> открывает соединение Finger <Fl-2> с RUIP на ЭВМ
<Н2>.
<Н1> выдает <Н2> RUIP запрос <Ql-2> типа {Q2} (например,
FOO@HOST1@HOST2).
При этом следует извлечь информацию о том, что:
ЭВМ <Н2> является самой правой ЭВМ в запросе <Ql-2> (на-
пример, HOST2)
Запрос <Q2-3> является остатком запроса <Ql-2> после удале-
ния правой части «©hostname» (например, FOO@HOST1)
Таким образом:
<Н2> RUIP должна открыть соединение <F2-3> с <НЗ>,
используя <Q2-3>.
<Н2> RUIP должна прислать любую информацию, посланную от
<F2-3> к <Н1> через <Fl-2>.
<Н2> RUIP должна закрыть <Fl-2> в нормальных обстоятель-
ствах только когда <НЗ> RUIP закрывает <F2-3>.
Сети передачи данных. Метод доступа
821
По большей части вывод RUIP не следует каким-либо жестким
регламентациям, так как он предназначен для чтения людьми, а не
программами. Главное требование - информативность может огра-
ничиваться только соображениями безопасности.
Запрос {С} требует выдачи списка всех работающих пользовате-
лей. RUIP должна либо ответить, либо активно отказаться. Если
она отвечает, тогда она должна выдать, по крайней мере, полные
имена пользователей. Системный администратор может включить в
выдачу и другую полезную информацию, такую как:
• Положение терминала
• Расположение офиса
• Рабочий номер телефона
• Должность
• Время пребывания в пассивном состоянии (число минут с
момента ввода последнего символа или со времени завершения пос-
ледней сессии).
Запрос {U}{C} является требованием присылки информации о
статусе определенного пользователя {U}. Если вы не хотите выда-
вать такую информацию, тогда следует заблокировать работу Finger.
Ответ должен включать в себя полное имя пользователя. Если
пользователь активно работает в сети, то присылаемые данные дол-
жны включать, по крайней мере, тот же объем информации что и
при запросе {С}.
Так как это запрос информации об отдельном пользователе, ад-
министратор может добавить определенную информации об этом
человеке, например:
• Расположение офиса 4
• Рабочий номер телефона
• Номер домашнего телефона
• Статус работы в системе (not logged in, logout time, и т.д.)
• Информационный файл пользователя
Информационный файл пользователя может содержать корот-
кое сообщение, которое оставляет пользователь для передачи по
запросу Finger. (Это иногда называется «plan» файлом). Это легко
реализуется путем поиска программой в корневом каталоге (или в
специально выделенном каталоге) пользователя файла с заданным
именем. Системному администратору должно быть разрешено вклю-
чать и выключать эту опцию.
При запросе Finger существует возможность запуска определен-
ной программы пользователя. Если такая опция предусмотрена, си-
стемному администратору должно быть позволено запрещать эту
процедуру. Данная опция, создавая определенные угрозы, практи-
822
Гпава 4
чески беспредельно расширяет возможности Finger (см. примеры в
конце раздела).
В командной строке допустимо имя пользователя или имя, под
которым он входит в систему. Если имя неопределенно, реакция
системы определяется системным администратором.
Лексема /W в запросе типа {Q1} или {Q2} в лучшем случае
интерпретируется последней RUIP и означает требование выдачи
максимально возможной информации о пользователе, в худшем слу-
чае она игнорируется.
Продающие автоматы должны реагировать на запрос {С} выда-
чей списка всех предметов, предлагаемых для продажи в данный
момент. Продающие автоматы должны откликаться на запросы
{U}{C}, сообщая число различных продуктов или отделений для раз-
мещения продуктов.
Корректная реализация Finger крайне важна. В частности, RUIP
должна-защищать себя от некорректного ввода. Конкретная реали-
зация программы должна проходить столь же тщательную провер-
ку, как Telnet, FTP или SMTP.
Следует учитывать, что Finger раскрывает информацию о пользо-
вателях. Лица, ответственные за сетевую безопасность, должны ре-
шить разрешать или нет работу Finger, и какую информацию о
пользователях следует рассылать.
Сетевой администратор должен иметь возможность разрешать и
запрещать прохождение запросов {Q2}. Если обработка запросов
{Q2} RUIP заблокировано, программа должна отсылать соответству-
ющее сообщение (например, «Finger forwarding service denied»). По
умолчанию обработка запросов {Q2} должна быть запрещена.
Программа RUIP при отправке данных должна отфильтровы-
вать все символы вне диапазона (ASCII 32 — ASCII 126), за исклю-
чением TAB (ASCII 9) и CRLF. Такая мера обезопасит получателя.
Примеры реализации запросов.
Узел: elbereth.rutgers.edu
Командная строка: <CRLF>
Login Name TTY Idle When Office
rinehart Mark J.Rinehart pO 1:11 Mon 12:15 019 Hill x3166
greenfie Stephen J.Greenfiel pl Mon 15:46 542 Hill x3074 .
rapatel Rocky — Rakesh Patel p3 4d Thu 00:58 028 Hill x2287 ;
pleasant Mel Pleasant p4 3d Thu 21:32 019 Hill 908-932- ;
dphillip Dave Phillips p5 021: Sun 18:24 265 Hill x3792 ;
dmk David Katinsky p6 2d Thu 14:11 028 Hill x2492
cherniss Cary Cherniss p7 5 Mon 15:42 127 Psychol x2008
Сети передачи данных. Метод доступа
вез
harnaga Doug Harnaga р8 2:01 Mon 10:15 055 Hill x2351
brisco Thomas P.Brisco pe 2:09 Mon 13:37 h055 x2351
laidlaw Angus Laidlaw qO 1:55 Mon 11:26 E313C 648-5592
cje Chris Jarocha-Ernst ql 8 Mon 13:43 259 Hill x2413
Узел: dimacs.rutgers.edu
Командная строка: pirmann<CRLF>
Login name: pirmann In real life: David Pirmann
Office: 016 Hill, x2443 Home phone: 989-8482
Directory: /dimacs/ul/pirmann Shell: /bin/tcsh
Last login Sat Jun 23 10:47 on ttypO from romulus.rutgers.
No unread mail
Project:
Plan:
Work Schedule, Summer 1990
Rutgers LCSR Operations, 908-932-2443
Monday 5pm — 12am
Tuesday 5pm — 12am
Wednesday 9am — 5pm
Thursday 9am — 5pm
Saturday 9am — 5pm
larf larf hoo hoo
Login name: surak In real life: Ron Surak
Office: 000 OMB Dou, x9256
Directory: /u2/surak Shell: /bin/tcsh
Last login Fri Jul 27 09:55 on ttyq3
No Plan.
Login name: etter In real life: Ron Etter
Directory: /u2/etter Shell: /bin/tcsh
Never logged in.
No Plan.
Узел: dimacs.rutgers.edu
Командная строка:
hedrick@math. ru tgers. edu@pilot. n j in. ne t <CRLF>
lpilot.njin.net]
[nia th. rut gers. edu]
Login name: hedrick In real life: Charles Hedrick
Office: 484 Hill, x3088
Rectory: /math/u2/hedrick Shell: /bin/tcsh
824
Гпава 4
Last login Sun Jun 24 00:08 on ttypl from monster-gw.rutge
No unread mail
No Plan.
Формат применения команды Finger:
finger [ опции ] имя...
По умолчанию finger отображает информацию обо всех активно
работающих пользователях, включая имя-идентификатор, полное имя,
имя терминала и т.д. В качестве имени может использоваться имя-
идентификатор, фамилия или имя пользователя. Ниже приводится
краткий перечень допустимых опций.
- 1 Запрос подробной информации
- s Запрос краткой информации
- q Запрос имени-идентификатора, имени терминала и времени
входа в систему
- i Запрос, аналогичный -q, но выдается и время пребывания
терминала в пассивном состоянии
- w Блокирует печать полного имени для -s
- h Блокирует печать файла .project в режиме -1 '
- р Блокирует печать файла .plan в режиме -1
Список работающих пользователей хранится в файле /etc/utmp,
полный список имен пользователей размещен в файле /etc/passwd,
времена и даты входа в систему записаны в файле /var/adm/lastlog,
имена и расположение терминалов можно найти в файле /etc/ttytab,
для записи информации о планах и проектах используются файлы
-/.plan и -/.project, соответственно.
Ниже приведен пример отклика на команду finger -1 (запрос^
подробной инфор!мации, ЭВМ SUN):
Login name: Ivanov In real life: Andrey Bobyshev
Directory: /ul/SunITEP/bobyshev Shell: /bin/csh
On since Aug 10 10:16:35 on ttypO from x4u2.desy.de
1 minute 37 seconds Idle Time
Mail last read Thu Aug 10 12:06:20 1995
No Plan. (Никаких планов)
Login name: Petrov In real life: Shtirlitz
Directory: /ul/SunITEP/semenov Shell: /bin/csh
On since Aug 10 12:14:19 on ttyp3 from semenov.itep.ru
33 seconds Idle Time
No unread mail *
No Plan.
Сети передачи данных. Метод доступа
825
Login name: Sidorov In real life: UU Ekatirin
Directory: /var/spool/uucppublic Shell:
/usr/local/lib/uucp/uucico
On since Aug 10 12:16:04 on ttyyOl 57 minutes Idle Time
Mail last read Wed Nov 16 18:17:50 1994
No Plan.
В общем случае при обращении к finger может использоваться
символьный Интернет-адрес:
Finger <имя_адресата>@1п!егпе1_адрес.
Возможности команды Finger варьируются в широких пределах
в зависимости от конкретной реализации. Так команда (РСТСР):
finger semenov@vxdesy.desy.de выдаст на экран:
[vxdesy.desy.de]
SEMENOV Semenov, Yuri SEMENOV not logged in (и qto истинная
правда)
Last login Thu 5-Jan-95 2:35PM-CET
[No plan]
Дополнительную информацию о команде finger можно получить:
Описание протокола
Информация по
электронной почте
Через удаленный
доступ
Через WWW
Через finger
ftp nic.merit.edu
Dp.?'sd.hV\ m.cdu
dlangley@netcom.com
telnet rpi.edu :79
http www.dlr.de cgi-
greving/mfinger
http sundae.triumf.ca
fmgerinfo.html
finger help@dir.su.oz.au
documents/rfc/rfc 1288.txt
pub/fingerinfo
в поле subject:”#finger
USER@HOST.DOMAIN"
Цифра после двоеточия — номер порта. Последняя строка гово-
рит о некоторых необычных возможностях Finger. Опция выдачи
СоДержимого файла пользователя и исполнения программы пользо-
вателя расширяет возможности Finger почти беспредельно. Так, выдав
манду finger help@dir.su.oz.au (Австралия), получим:
826
Гпава 4
[extra.ucc.su.OZ. AU]
**** This is an experimental service offered free of charge by ****
**** The University Computing Service, University of Sydney. ****
**** Please mail support@is.su.edu.au if you have any queries. ****
Finger offers these additional services (Finger предлагает некото-
рые дополнительные возможности):
• Access to a database facility (доступ к базе данных)
Usage (использование): finger <key>%<database>@dir.su.edu.au
<key> is usually an «egrep» regular expression and <database> can
be (в качестве <key> обычно используется стандартное «egrep »-
выражение, а вместо <database> можно записать):
Aamet resources available on AARNet (ресурсы AARNet)
Buildings buildings and their codes at Sydney Uni (коды зданий
сиднейского университета)
Archie query anonymous FTP databases (анонимный поиск по
FTP-депозитариям)
Internet resources available on the Internet (ресурсы Internet)
Library library access available via AARNet (доступ к библиотеч-
ным базам данных) '
Newsgroupsfind NetNews newsgroups (поиск новостей)
Phone The Sydney Uni Phone Book (телефонная книга Сиднейс-
кого университета)
Postcodes Australian Postcodes (австралийские почтовые коды)
Shop prices at the UCS shop (цены в университетском магазине)
Usage (использование): ;
Finger help@dir.su.edu.au this help (данный справочный материал)
Finger help% <database>@dir.su.edu.au on a particular database facility
Finger copyright@dir.su.edu.au please read this copyright notice
Finger egrep@dir.su.edu.au a manual on egrep regular expression^
(справочные материалы по допустимым egrep-выражениям)*
Замечание. Задавая ключевые слова, избегайте применения
циальных символов, пробелы относятся к их числу.
Выдав команду:
Finger 2%aarnet@dir.su.edu.au (запрос содержимого второго '
раздела базы данных aarnet);
получим:
Сети передачи данных. Метод доступа 827
[extra.ucc.su.oz.au]
Index for Chapter 2 (список библиотек):
Australian Defense Force Academy Library
The Australian National University Library
Curtin University Of Technology T.L. Robertson Library
Deakin University Library
Griffith University, Division of Information Services
La Trobe University Library
Macquarie University Library
Murdoch University Library
R.M.LT. Library — MATLAS Library Catalogue.
Swinburne Library
The University of Adelaide, Barr Smith Library
The University of Melbourne Baillieu Library
The University of New England Library
The University of New South Wales
The University of Newcastle Libraries
The University of Queensland Libraries
The University of Western Australia, Reid Library
The University of Wollongong Library
University College of Central Queensland Library
University of South Australia Library Systems Dept
Victoria University of Wellington
Таким образом, даже с помощью Finger можно организовать
доступ к базам данных. Finger не сработает для узлов, не имеющих
IP-адресов (например, электронный почтовый адрес). Эта команда
всегда позволит руководителю проекта узнать, например, когда пос-
ледний раз тот или иной участник проекта работал на ЭВМ. :-)
4.5.3. Команда удаленного доступа TELNET
TELNET позволяет пользователю установить TCP-соединение с
сервером и затем передавать коды нажатия клавиш так, как если бы
Работа проводилась на консоли сервера. TELNET (RFC-854, в некото-
рых реализациях tn) служит для выполнения удаленного доступа к
вЫчислительным ресурсам и базам данных (например, к базам ядер-
*Ь1Х данных в Вене, Брукхейвене или STN-International в Карлсруэ).
7* я вх°да в базу данных или ЭВМ обычно нужна аутентификация
°Д имени-идентификатора пользователя и его слова-пропуска). В
°торь1х реализациях допускается использование параметров, ко-
РЫе подключают необходимые эмуляторы терминалов.
828
Гпава 4
TELNET предлагает три услуги:
1. Определяет сетевой виртуальный терминал (NVT — Network
Virtual Terminal), который обеспечивает стандартный интерфейс к
удаленной системе.
2. Включает механизм, который позволяет клиенту и серверу со-
гласовать опции обмена
3. Обеспечивает симметрию соединения, допуская любой программе
(например FTP) выступать в качестве клиента
Протокол TELNET позволяет обслуживающей машине рассмат-
ривать все удаленные терминалы как стандартные «сетевые вирту-
альные терминалы» строчного типа, работающие в кодах ASCII, а
также обеспечивает возможность согласования более сложных функ-
ций (например, локальный или удаленный эхо-контроль, страничный
режим, высота и ширина экрана и т. д.). На прикладном уровне над
TELNET находится либо программа поддержки реального терминала,
либо прикладной процесс в обслуживающей машине, к которому осу-
ществляется доступ с терминала. Формат NTV достаточно прост.
Для данных используются 7-битовые ASCII коды. 8-битовые же ок-
теты зарезервированы для командных последовательностей.
Программа Telnet взаимодействует с другой ЭВМ через протокол
TELNET. Если команда telnet вводится без аргументов ЭВМ перехо-
дит в командный режим, напечатав приглашение telnet>. В этом
режиме она воспринимает и исполняет команды, описанные ниже.
При вводе Telnet с аргументами программа осуществит связь
вашей ЭВМ с удаленным компьютером, имя или адрес которого вы
ввели в качестве одного из аргументов.
После того как telnet-связь установлена, начинаются переговоры
об используемых опциях (см. табл. 4.5.3.1). Каждая из договари-
вающихся сторон может послать другой один из четырех запросов
WILL, DO, WONT и DONT (см табл. 4.5.3.4).
Далее telnet переходит в режим ввода. В этом режиме любой
введенный текст пересылается удаленной ЭВМ. Ввод может произ-
водиться посимвольно или построчно. При посимвольном режиме
каждый введенный символ пересылается немедленно, при построч-
ном режиме отклик на каждое нажатие клавиши производится
локально, а пересылка выполняется лишь при нажатии клавиши
<Enter>. Некоторые опции требуют дополнительных данных, такая
информация может быть получена с помощью субопций (RFC-1091).
При этом клиент посылает трехбайтовую последовательность IAC
WILL 24, где 24 — код-идентификатор терминала. Получатель мо-
жет откликнуться последовательностью IAC DO 24, если все в по-
рядке. Сервер в свою очередь посылает последовательность IAC SB
Сети передачи данных. Метод доступа
829
24 1 IAC SE, запрашивая тип терминала клиента. Здесь код 24
означает, что это субопция для опции типа терминала (см. табл.
4.5.3.1), а следующая 1 является командой «пришлите код вашего
терминала». Клиент в свою очередь может откликнуться, послав
последовательность — IAC SB 24 О I В М Р С IAC SE. Здесь байт О
имеет значение «мой терминал имеет тип». Список кодов термина-
лов содержится в RFC-1700.
Таблица 4.5.3.1. Коды опций в Telnet
Код опции в telnet Описание Номер RFC
0 Двоичный обмен 856
1 Эхо 857
2 Повторное соединение NIC 15391
3 Подавление буферизации ввода 858
4 Диалог о размере сообщения NIC 15393
5 Статус 859
6 Временная метка 860
7 Удаленный доступ и отклик 726
8 Длина выходной строки NIC 20196
9 Размер выходной страницы NIC 20197
10 Режим вывода символов <возврат каретки> 652
11 Вывод горизонтальной табуляции 653
12 Установка положения табуляции при выводе 654
13 Режим вывода команды смены страницы 655
14 Вывод вертикальной табуляции 656
15 Определяет положение вертикальной табуляции 657
16 Режим вывода символа <перевод строки> 658
17 Расширенный набор кодов ASCII 698
18 Прерывание сессии (Logout) 727
19 Байт-макро 735
20 Терминал ввода данных 732
21 SUPDUP 736
22 SUPDUP вывод 747
23 Место отправления 779
24 Тип терминала 930
25 Конец записи 885
_ 26 TACACS- идентификация пользователя 927
_ 27 Пометка вывода 933
_ 28 ' Код положения терминала 946
29 Режим 3270 1041
_ 30 Х.З PAD 1053
L.31J Размер окна 1073
830
Глава 4
Когда связь с удаленной ЭВМ уже осуществлена, переход в ко-
мандный режим может быть выполнен с помощью нажатия “Л]”
(escape).
В этом режиме доступны команды:
open имя_ЭВМ [ порт ] Open открывает связь с ЭВМ, имя
которой указано в обращении. Если номер порта явно не
указан, telnet пытается использовать для связи с сервером
номер порта по умолчанию. Вместо имени ЭВМ-сервера
может использоваться ее 1Р^адрес.
display [ аргумент ... ] Отображает весь, или часть, набора пара-
метров telnet (см. описание команды send).
close Закрывает сессию TELNET и возвращает систему в команд-
ный режим.
quit Закрывает любую сессию TELNET.
mode type Управляет режимом ввода («построчный» или «посим-
вольный»), Удаленной машине посылается запрос на
переход в соответствующий режим. Если она готова (спо-
собна) работать в запрошенном режиме, будет произведено
соответствующее переключение.
status Отображает текущий статус telnet. В перечень информации
входит имя удаленной ЭВМ и действующий режим обмена.
? [ команда ] Выдает справочную информацию о команде,
название которой приведено в качестве аргумента
send arguments Посылает удаленной ЭВМ один или несколько
символьных аргументов. В качестве аргументов могут
использоваться: escape,synch,brk,ip,ao,ayt,ecel,ga и др.
Смотри таблицу 4.5.3.3 и 4.5.3.4.
escape Посылает escape символ (например, “']”).
synch Посылает SYNCH-последовательность. Эта последователь-
ность позволяет аннулировать все, что было до этого напе-
чатано, но еще не считано. Эта последовательность посыла-
ется как срочная (важная) TCP-информация (может не
сработать, если удаленной системой является 4.2 BSD).
Если она не сработала, на терминал будет послан символ «г».
brk Посылает Break-последовательность при нажатии клавиши
Break (Pause). (Исчерпывающую информацию об аргумен-
тах можно найти в описании используемого программного
обеспечения или с помощью команд Help или man)
set argument value Присваивает любому числу переменных
telnet новые значения. Специальное значение «off» выклю-
чает функцию, соответствующую данной переменной
Сети передачи данных. Метод доступа
831
Значения переменных можно узнать с помощью команды display.
Такими переменными могут быть: echo, escape, interrupt, quit,
flushoutput, erase, kill, eof, echo. Последняя переменная (в исходном
состоянии “"Е”) в построчном режиме осуществляет переключение
между локальным эхо на ввод символа (режим по умолчанию) и
подавлением эхо, например при вводе пароля. Переменные процеду-
ры telnet представлены в таблице 4.5.3.2.
Практически стандарт telnet описан во многих RFC документах,
которые определяют различные варианты реализации этой команды.
Список опций команды Telnet приведен в таблице 4.5.3.1 (не все эти
возможности доступны в конкретных программных продуктах).
Таблица 4.5.3.2. Переменные telnet
Название переменной Назначение
echo Определяет, будет ли отображаться на экране то, что вы вводите с клавиатуры. При значении off ввод не отображается, например, при вводе пароля.
escape Задает символ, который используется в качестве escape. Появление этого символа во входном потоке заставляет его и последующие символы интерпретироваться в ЭВМ, где функционирует процесс telnet, как команда
interrupt Специфицирует символ прерывания процесса. Ввод его приводит к остановке процесса пользователя, работающего на удаленной ЭВМ.
quit Специфицирует символ, который используется пользователем на его клавиатуре для выполнения команд Brake или Attention.
flushoutput Определяет символ, который служит для прерывания процедуры вывода на удаленной ЭВМ.
eof Специфицирует символ, который используется для обозначения конца файла на удаленной машине.
В таблице 4.5.3.4 представлены наименования и коды команд
Telnet, которые используются как клиентом, так и сервером в соче-
тании с префиксным байтом Oxff (IAC — «интерпретировать как
команду»). Если нужно послать код данных, равный 255, посылает-
Ся два байта с кодами 255.
Операция прерывание процесса (IP) позволяет прервать, удалить
Или завершить процесс пользователя (например, выйти из бесконеч-
ного цикла).
Процедура прерывание вывода (АО) позволяет процессу пользо-
вателя продолжаться, но вывод на его рабочую станцию прерывает-
832
Гпава 4
Таблица 4.5.3.3. Последовательности символов, используемые
совместно с командой send
Последователь- ность символов Назначение
9 Отображает справочную информацию о команде send
escape Посылает символ escape (без прерывания посылки символов для telnet)
Посылает протокольную последовательность Telnet. Удаленная машина должна прервать процесс, запущенный для вас.
ес Посылает протокольную ЕС-последовательность telnet. Удаленная ЭВМ должна стереть последний напечатанный вами символ
el Посылает протокольную EL-последовательность telnet. Удаленная ЭВМ должна стереть последнюю напечатанную вами строку.
ао Посылает протокольную АО-последовательность telnet. Удаленная ЭВМ должна направить весь вывод на ваш терминал.
brk Посылает протокольную BRK-последовательность telnet. Удаленная ЭВМ должна обеспечить отклик.
ayt Посылает протокольную AYT-последовательность telnet (Are You There). Удаленная ЭВМ должна обеспечить отклик.
ся, при этом очищается буфер от уже записанной, но не отображен-
ной информации.
Запрос «Вы здесь?» (AYT) удобен, когда необходимо выяснить
выполняется ли пользовательская задача или нет.
Операция стереть символ (ЕС) позволяет пользователю удалить
символ из потока данных, применяется для редактирования текста
на экране.
Операция стереть строку (EL) позволяет пользователю при ре-
дактировании удалить целую строку.
Команда «go ahead» (GA, «продолжайте») устанавливает полу-
дуплексный режим передачи данных. Каких-либо воздействий на
удаленную ЭВМ обычно не производит. В таблице 4.5.3.5 приведен
список комбинаций клавиш, нажатие которых вызывает определен-
ный результат.
Блок данных процедуры Telnet содержит три байта и называет-
ся командой. Формат этого блока показан на рис. 4.5.3.1.
Первый байт в соответствии с таблицей содержит 8 единиц, Да‘
лее следует байт команды (табл, 4,5.3.4). Третий октет служит ДЛЯ
размещения кода опции, он может и отсутствовать.
Сети передачи данных. Метод доступа
833
Таблица 4.5.3.4. Коды команд Telnet
Имя субкоманды telnet Код Описание
"EOF 236 Признак конца файла
SUSP 237 Отложить исполнение текущего процесса
"abort 238 Абортировать процесс
EOR 239 Конец записи
NOP 241 Никаких действий
DM (Метка данных) 242 Блок данных процедуры Synch
BRK (Остановка) 243 BRK-символ (Break);
IP (Прерывание процесса) 244 IP-функция
10 (Прерывание вывода) 245 АО-функция
АУТ (Вы здесь?) 246 AYT-функция
ЕС (Стереть символ) 247 ЕС-функция
EL (Стереть строку) 248 EL-функция
GA (Продолжайте) 249 GA-функция
SB 250 Начало субопции
SE 240 Завершение согласования параметров (конец субонции)
Will ("будет") 251 Начало исполнения(опционно)
Won't (не будет) 252 Отказ исполнения или продолжения выполнения(опционно)
Do ("исполнить”) 253 Индицирует запрос, который другая система исполняет (опционно)
Don’t ("Нет”) 254 Требует, чтобы другая система остановила исполнение (опционно)
IAC 255 Интерпретируется как начало командной последовательности
Таблица 4.5.3.5. Управляющие комбинации клавиш
Комбинация клавиш Достигаемый результат
ICtrl+E Echo
Ctrl+] Escape
Ctrl+? Erase (стереть)
Ctrl+O Flushoutput (немедленный вывод)
Ctrl+C Interrupt (прерывание исполнения программы)
Ctrl+U Kill (ликвидировать)
_Ctrl+\ Quit (завершение)
Orl+D eof
Зак. № 3430 Семенов
834
Гпава 4 f
Третий октет(опционно)
Первый октет
Второй октет
И н тер претируется как команда (IAC) Код команды Опция
Рис. 4.5.3.1. Формат блока данных Telnet
Рассмотрим несколько примеров этих команд. Допустим, вы хо-
тите, чтобы обмен данными производился в виде 8-битовых посылок.
Для реализации вашего пожелания достаточно выдать команду:
IAC WILL TRANSMIT-BINARY,
которая в цифровых кодах выглядит как — (255 251 0).
Для прекращения этого (двоичного) режима передачи нужно
выдать команду:
IAC DON’T TRANSMIT-BINARY (255 254 0).
Субкоманды Telnet позволяют управлять откликом при работе
с клавиатурой. Обычно отклик-эхо присылается удаленной ЭВМ,
реже формируется локально. Для включения отклика можно вы-
дать команду: IAC WILL ECHO (255 251 1) (часто это реализовано
по умолчанию). Далее можете поупражняться самостоятельно и
проверить какие команды и их опции доступны в используемом
вами программном продукте.
При работе с Telnet рекомендуется сначала ознакомиться с кон-
кретными возможностями команды с помощью описания (или ПО/
?). Это позволит вам, например, спасать результаты поиска в файле
с указанным вами именем и т.д. Например, для РСТСР такая ко-
манда выдаст на экран:
Telnet with VT220 and 3270 emulation, escape character is alt-FlO or F10
Copyright (c) 1989-1992 by FTP Software, Inc. All rights reserved.
? display this help message a
Ah debugging command help b
о write receive data to output z
file
i read keystrokes from an input t
file
c close connection gracefully !
q/Q quit current/all telnet I
connections
F toggle build-in FTP-server U
on/off
W toggle FTP server write- u
protect mode
sends Telnet AYT request
send Telnet Interrupt Process
send Telnet Abort output
send Telnet Break
escape to command interpret
show local internet address
turn status line on
turn status line off
Сети передачи данных. Метод доступа
835
0-9 switch to connection # s Enable pop-up TSR with hot-key
p Select code page remapping S Toggle screen-saver key-passing
---------------------VT220 emulator commands--------------------------
R
N
E
E
В
D
У
Enter key send CR 1
Enter key send newline r
(CRLF)
send characters as typed w
send line when ENTER is d
typed
<-key sends BS; CTL_<-key
sends DEL
<- key sends DEL; CTL_<-
local echo mode
remote echo mode
turn end-of-line wrap on ,
turn end-of-line wrap off
set emulator mode (VT52|100|220)
key sends BS
------------------- 3270 emulator commands-----------------------
set Yale Null Processing off Y set Yale Null Processing on
[Press SPACE to return to session, or enter another command (? for Help]
Многие telnet-клиенты позволяют также указывать явно номер
порта, через который должна быть установлена связь. По умолча-
нию это порт 23. Обычный пользователь не интересуется, через ка-
кой порт он работает. Но иногда желательно реализовывать telnet
через разные порты системы, обеспечивающие различные услуги, это
бывает полезно и с отладочными целями. Используя команду:
telnet ХХХХХХ.domain <номер порта>
можно осуществить связь через порт с заданным номером с узлом
ХХХХХХ.domain. Многие библиотеки используют метод портов
для обеспечения доступа к своим ресурсам внешних Inernet-пользо-
вателей. Ссылки на RFC-документы по протоколу TELNET смотри-
те в приложении. Помимо telnet существуют и другие стандартные
процедуры, выполняющие схожие задачи.
SUN Microsistems разработала и широко использует программ-
ный модуль RPC (Remote Procedure Call, RFC-1057), он служит для
Удаленного вызова программ почти во всех системах, базирующих-
ся на UNIX. RPC может использоваться как на TCP, так и UDP
транспортных уровнях.
Для удаленного исполнения программ может служить команда
REXECD, которая активно используется на IBM-системах в рамках
ОС AIX и DOS. Уязвимость протокола Telnet для хакеров привела
к тому, что в последнее время эта утилита часто заменяется SSH
(Secure Shell) или другими программами, обеспечивающими безопас-
ный удаленный доступ.
27*
836
Гпава 4
4.5.4. Пересылка файлов [FTP]
FTP (RFC-959) обеспечивает файловый обмен между удаленны-
ми пользователями. Протокол FTP формировался многие годы.
Первые реализации в МТИ относятся к 1971. (RFC 114 и 141).
RFC 172 рассматривает протокол, ориентированный на пользовате-
ля, и предназначенный для передачи файлов между ЭВМ. Позднее в
документах RFC 265 и RFC 281 протокол был усовершенствован.
Заметной переделке протокол подвергся в 1973, и окончательный
вид он обрел в 1985 году. Таким образом, данный протокол являет-
ся одним из старейших. Работа FTP на пользовательском уровне
содержит несколько этапов:
1. Идентификация (ввод имени-идентификатора и пароля).
2. Выбор каталога.
3. Определение режима обмена (поблочный, поточный, ASCII
или двоичный).
4. Выполнение команд обмена (GET, MGET, DIR, MDEL, MPUT
или PUT).
5. Завершение процедуры (QUIT или CLOSE).
FTP довольно необычная процедура, так как поддерживает две
логические связи между ЭВМ (Рис 4.5.4.1). Одна связь служит для
удаленного доступа и использует протокол TELNET. Другая связь
предназначена для обмена данными. Сервер производит операцию
passive open для порта 21 и ждет соединения с клиентом. Клиент
осуществляет операцию active open для порта 21. Канал остается
активным до завершения процедуры FTP. TOS (тип IP-сервиса)
соответствует минимуму задержки, так как этот канал использует-
ся для ручного ввода команд. Канал для передачи данных (TCP)
формируется каждый раз для пересылки файлов. Канал открывает-
ся перед началом пересылки и закрывается по коду end_of_file
(конец файла). IP-тип сервиса (TOS) в этом случае ориентирован на
максимальную пропускную способность.
Конечный пользователь взаимодействует с протокольным ин-
терпретатором, в задачи которого входит управление обменом ин-
формацией между пользователем и файловой системой, как мест-
ной, так и удаленной. Схема взаимодействия различных частей
Internet при работе FTP изображена на рис. 4.5.4.1.
Сначала по запросу клиента формируется канал управления, ко-
торый в дальнейшем используется для передачи команд от клиента
и откликов от сервера. Информационный канал формируется серве-
ром по команде клиента, он не должен существовать постоянно на
Сети передачи данных. Метод доступа
837
протяжении всей FTP-сессии и может формироваться и ликвидиро-
ваться по мере необходимости. Канал управления может быть зак-
рыт только после завершения информационного Ъбмена. Для кана-
ла управления используется протокол telnet. После того как уп-
равляющий канал сформирован, клиент может посылать по нему
команды. Сервер воспринимает, интерпретирует эти команды и пе-
редает отклики.
Рис. 4.5.4 Л Схема работы протокола FTP.
Возможна и другая схема взаимодействия, когда по инициативе
клиента осуществляется файловый обмен между двумя ЭВМ, ни одна
из которых не является машиной клиента (см. рис. 4.5.4.2).
Рис. 4.5.4.2. Организация информационного обмена
между двумя удаленными машинами
На фазе задания режима обмена предоставляются следующие
возможности:
Команда Block сохраняет структуру логических записей файла.
Команда Stream устанавливает режим, при котором не производит-
ся пересылки контрольной информации для блоков. Это наиболее
быстрый режим обмена, он работает по умолчанию.
Команда TYPE может задать режимы обмена IMAGE, ASCII или
EBCDIC. Из них ASCII — используется по умолчанию. Режим
838
Гпава 4
EBCDIC применяется для обменов между ЭВМ, работающими с на-
бором символов EBCDIC. Режим IMAGE предполагает обмен 8-бит-
ными байтами, используется для передачи двоичной (а не тексто-
вой) информации. Более подробный список команд помещен ниже.
Структурно информация может передаваться в виде файлов (струк-
тура по умолчанию), в виде последовательности записей (применимо
для текстовых файлов ASCII или EBCDIC) или постранично (после-
дняя структура не относится к числу рекомендуемых).
Для копирования файла из удаленного сервера используется
команда get, для копирования группы файлов — mget, в последнем
случае применяются символы заменители, например, mget *.txt (или
RFC-18*.txt, при этом скопируются файлы с RFC-1800.txt до RFC-
189©, txt, если таковые существуют в текущем каталоге). Анало-
гом команды get в какой-то степени является команда dir (Is),
только она переносит содержимое каталога, что для некоторых опе-
рационных систем эквивалентно. При использовании модифика-
ции mget проявляйте осторожность — вы можете заблокировать
телекоммуникационный канал длительным копированием. Для за-
писи файла в удаленный сервер применяется команда put. При опе-
рациях обмена обычно используется текущий каталог локальной
ЭВМ. В вашем распоряжении всегда имеется возможность поме-
нять местный каталог с помощью команды led или ее аналога. Лю-
бая команда обмена выполняется в несколько этапов:
1. Формирование канала под управлением клиента, так как имен-
но клиент выдал команду get, dir, put и т.д.
2. Клиент выбирает произвольный номер порта на своей ЭВМ и
осуществляет процедуру passive open для этого порта.
3. Клиент посылает номер порта серверу по каналу управления
(порт 21), используя команду PORT. Можно обойтись и без коман-
ды PORT (используется тот же порт, что и в командном канале), но
это увеличивает задержки и по этой причине не рекомендуется.
4. Сервер получает номер порта по каналу управления и выдает
команду active open в указанный порт ЭВМ-клиента. Сервер для
канала данных всегда использует порт с номером 20.
Рассмотрим пример FTP-сессии. Для этого выдадим команду
(тексты, набираемые с клавиатуры, выделены курсивом):
ftp -d ns.itep.ru (флаг -d означает установку отладочного режима,
при котором выдаются все сообщения и внутренние коман-
ды на экран терминала).
FTP Trying...Open
220- *** Welcome at FTP-Server ftp.ITEP.RU ***
Сети передачи данных. Метод доступа
аза
220-
220 ns.itep.ru FTP server ready.
Userid for logging in on ns.itep.ru (SEMENOV)? semenov
FTP command: USER semenov
FTP response: 331 Password required for semenov.
331 Password required for semenov.
Password for logging in as semenov on ns.itep.ru? XXXXXXXX
PASS XXXXXXXX (ввод пароля не отображается на экране)
FTP response: 230 User semenov logged in.
230 User semenov logged in.
ftp:ns.itep.ru> hel (просьба выдать список доступных на
данном сервере FTP-команд)
Any unambiguous abbreviation for a command may be used.
Available commands are:
! ? acct append ascii binary bye cd debug
delete dir drive exit fed fdir fpwd get help
iget image iput led Idir Imkdir local login ipwd
Is mdelete mget mkdir mput option parent passive put
pwd quit quote rename retrieve rmdir send server show
stat store take tenex tget tput type user verbose
version
ftp:ns.itep.ru> quit
FTP command: QUIT
FTP response: 221 Goodbye.
Уход из FTP производится по команде quit. В приведенном
примере файловый обмен не производился, но и команда HELP тре-
бует переноса информации (также как и dir), так как вам выдается
список команд, доступных на удаленном сервере. Из воспроизведен-
ного списка команд, самая опасная mdelete, так как способна сте-
реть целый каталог. Нетекстовые файлы (архивированные, графи-
ческие и программные) следует пересылать в режиме binary. Для
перевода в этот режим используется одноименная команда. Для
перехода из одного каталога в другой на удаленном сервере служит
команда cd имя_каталога, а для возврата в предшествующий cd .. .
Например, cd /pub/msdos.
Ссылка на объект, доступный через анонимное FTP, обычно за-
писывается в виде:
Название ресурса Имя сервера Имя каталога в сервере.
Например:
Internet-cmc ftp.rpi.edu /pub/communications/internet-cmc.txt
840
Гпава 4
Ниже приведен список базовых команд FTP. Следует разделять
внутренний набор команд FTP, которыми обмениваются клиент и
сервер по командному каналу, и набор команд доступный пользова-
телю. Служебные команды содержат три или четыре заглавные бук-
вы. Эти наборы команд перекрываются лишь частично. Служебные
команды унифицированы (они выделены в приведенном выше при-
мере FTP-сессии жирным шрифтом, в помещенной ниже таблице
эти команды представлены в ее верхней части), пользовательский
же набор команд может варьироваться от реализации к реализа-
ции. Если выдать команду FTP без аргументов, система обычно
откликается приглашением FTP> и вы можете выполнить некото-
рые из приведенных ниже команд (весь набор становится доступ-
ным только после идентификации).
Таблица 4.5.4.1
Субкоманды FTP Описание
ABOR Прерывание исполнения предыдущей FTP- команды и связанного с ней обмена
ACCT<SP> <account- information> Ввод идентификатора пользователя (ID);
ALLO <SP> <десятичное целое> [<SP> R <SP> <десятичное иелое>] Зарезервировать достаточно места (в байтах) для пересылки файла. Для файлов с постраничной структурой после символа R указывается число записей
АРРЕ <SP> <проход> Присовокупить передаваемые данные к файлу, указанному в параметре проход
CDUP Переход в каталог прародитель
CWD <SP> <проход> Изменить рабочий каталог (CD);
DELE <SP> <проход> Стереть файл (del);
HELP Выдать справочную информацию о выполнимых командах
HELP [<SP> <строка>] Выдать описание работы данной команды
LIST [<SP> <проход>] Вывод списка файлов или каталогов (dir);
MKD <SP> <проход> Создать каталог
MODE <SP> <код режима> Режим обмена - поток, блоки или передача данных со сжатием
NLST [<SP> <проход>] Переслать оглавление каталога от сервера к клиенту
NOOP Пустая команда
PASS <SP> <пароль> Слово-пропуск (пароль) пользователя, заполняется пользователем
PASV Перевести сервер в режим прослушивания информационного порта на предмет установления соединения _
Сети передачи данных. Метод доступа
841
Таблица 4.5.4.1 (окончание)
Обкоманды FTP Описание
"PORT <SP> спорт ЭВМ> IP-адрес и номер порта клиента
PWD Выдать имя текущего каталога
QUIT Уход из FTP
"REIN J Завершение сессии и открытие новой
REST <SP> <маркер> Возобновление обмена, начиная с места, указанного маркером
RETR <SP> <проход> Переслать копию файла (get) другому адресату
RMD <SP> <проход> Удалить каталог
RNFR <SP> <проход> Начало процедуры переименования файла (Rename From)
RNTO <SP> <проход> Указание нового имени файла при переименовании (Rename То)
SITE <SP> <строка> Используется сервером для реализации локально специфических команд
SMNT <SP> <проход> Позволяет пользователю смонтировать нужную файловую систему
STAT Выдать текущие значения параметров (STATUS)
STOR <SP> <проход> Сервер должен запомнить полученные данные в виде файла
STOU Аналог команды STOR но записывает файл в текущий каталог и присваивает файлу уникальное имя
STRU <SP> <код структуры> Структура файла = файл, запись или страница
SYST Сервер сообщает тип системы
TYPE <SP> скод типа> Специфицирует тип информации, часто для этой цели используются команды binary и ASCII
USER <SP> < [имя [пропуск]] > Идентифицирует пользователя (запрашивается сервером)
9 тоже что и HELP;
led Изменить локальный каталог (на вашей ЭВМ);
I Выйти временно из FTP и уйти в Shell (UNIX)
2 команда Исполнить команду Shell (UNIX)
close Прервать связь с удаленным сервером, оставаясь в FTP
open [имя_ЭВМ] Установить связь с указанным удаленным сервером
_dir Выдать содержимое удаленного каталога
<SP> пробел; все команды завершаются последовательностью
<CRLF> возврат каретки + перевод строки. В квадратных скобках
записан опционный аргумент. Выполнение любой команды можно
842
Гпава 4
прервать с помощью Ctrl-C. Возможная форма обращения к FTP:
ftp [ -опции ] [ имя ЭВМ ]
Допустимы следующие опции (модификаторы) команды (SUN):
- d включение отладочного режима.
- g блокировка группового исполнения команд.
- i Выключение интерактивного приглашения при множе-
ственной пересылке файлов.
- v Отображает все отклики удаленного сервера и статистику
обмена; этот режим работает обычно по умолчанию.
В рамках процедуры FTP доступны следующие команды (приве-
денный перечень команд является неполным):
! [ команда ] Исполняется команда интерпретатора shell
вашей ЭВМ (UNIX). Если имя команды явно не введено,
система переходит в интерактивный режим shell.
$ имя-макро [ аргументы ] Выполняется макро, имя которого
введено, аргументы используются этим макро.
account [ пароль ] Позволяет ввести пароль, необходимый для
доступа в удаленный сервер.
append имя местного файла [ имя_удаленного_файла ]
Добавить местный файл к файлу на удаленном сервере.
Вуе Завершает FTP-сессию.
case Переключает регистр символов, которыми записаны имена
файлов на удаленной ЭВМ, в процессе выполнения команды
mget. Если case включен (по умолчанию выключен), все
.прописные буквы в именах файлов на удаленной ЭВМ,
меняются при переносе в вашу ЭВМ на строчные.
close Завершает FTP-сессию и возвращает систему в интерактив-
ный командный режим. Все описанные ранее макро стира-
ются.
debug [ debug-value ] Включает/выключает режим отладки.
Значение debug-value определяет отладочный уровень. Если
отладка включена, ftp отображает на экране каждую ко-
манду, посылаемую удаленной ЭВМ. Эта информация поме-
чается символом “—>”.
dir [ удаленный каталог ] [ местный файл ] Выдает на экран
содержимое удаленного каталога. Если в качестве парамет-
ра указано имя местного файла, результат заносится в него.
Если имя удаленного каталога не указано, команда выпол-
няется для текущего каталога.
disconnect Синоним close.
QeTn передачи данных. Метод доступа
843
hash Включает/выключает знак (#). Во включенном состоянии
отмечается пересылка каждого блока, что позволяет визу-
ально контролировать процесс обмена.
macdef macro-name Определяет макро. Последующие строки
запоминаются в качестве текста макро с именем macro-
name. Нулевая строка (двойное нажатие клавиши RETURN)
завершает ввод текста макро. Можно ввести до 16 макро с
суммарным объемом до 4096 символов.
mdelete [ имена_файлов_на удаленной ЭВМ ] Удаляет файлы
на удаленной ЭВМ.
open имя-ЭВМ [ port ] Устанавливает связь с указанным FTP-
сервером (ЭВМ) через специфицированный порт.
prompt Включает/выключает интерактивные запросы со стороны
ЭВМ. Это бывает полезным при выполнении групповых
команд mput, mget или mdelete и позволяет проводить
соответствующие операции над файлами выборочно.
proxy ftp-команда выполняет FTP-команду на вторичной удален-
ной ЭВМ. Эта команда позволяет связать два удаленных
FTP-сервера и осуществить пересылку файлов между ними.
Первой proxy-командой должна быть команда open, необхо-
димая для установления связи со вторичным сервером.
Введите команду proxy ?, чтобы проверить выполнимость
этих команд на данном сервере.
quit синоним bye.
recv удаленный_файл [ местный_файл ] синоним команды get.
remotehelp [ имя команды ] Запрашивает справочную
информацию у удаленного FTP-сервера. Если имя_команды
задано, запрашивается информация о конкретной команде.
runique Включает режим записи файлов в вашу ЭВМ только с
уникальными именами. Если файл с таким именем уже
существует, то новому файлу будет присвоено имя с расши-
рением .1, если и такое имя уже есть, то с расширением .2.
Это может продолжаться вплоть до расширения .99, после
чего будет выдано сообщение об ошибке. Впрочем, такую
ситуацию вообразить крайне трудно, если вы сами не на-
плодили файлов с цифровыми расширениями. Для команды
mget это крайне полезная функция, которая застрахует вас
от стирания ваших файлов из текущего каталога, имеющих
имена, совпадающие с именами на удаленном сервере. По
умолчанию runique не включено.
send local-file [ remote-file ] Синоним команды put.
status Отображает текущее состояние ftp.
844
Гпава 4
В депозитариях можно встретить файлы следующих разновид-
ностей (все виды ниже перечисленных файлов пересылаются в ре-
жиме binary, а не ASCII):
Таблица 4.5.4.2
Тип файла Пример за- писи имени файла Программа обработки файла
Архивированный файл файл.2 compress, uncompress
tar-файл файл.tar tar
Архивированный tar- файл файлЛаг./ tar, compress, uncompress
файл. tar. gz Применен архиватор GZIP
uuencode-файл файл.иие uuencode, uudecode
Архивированный uuencode-файл файл.иие-Z uuencode, uudecode, compress, uncompress
zip-файл файл.zip pkzip, pkunzip
shar-файл файл, shar shar, sh, unshar
сжатый shar-файл файл.зЬаг./ shar, sh, unshar, compress, uncompress
При выполнении FTP система возвращает трехразрядные деся-
тичные коды-отклики, которые позволяют судить о корректности
обмена и диагностировать процедуру. Выдача кода сопровождается
текстом-комментарием. Первая цифра может принимать значения
от 1 до 5. Структура кодов показана в таблице 4.5.4.3:
Таблица 4.5.4.3. Коды диагностики
Значение кода- отклика Описание
lyz Позитивный предварительный отклик, который означа- ет, что операция начата. До завершения процедуры следует ожидать как минимум еще один отклик
2yz Сигнал успешного завершения процедуры, говорящий о том, что можно ввести новую команду
3yz Положительный промежуточный отклик, указывающий на то, что команда воспринята, но для продолжения требуется дополнительная информация
4yz Негативный отклик, свидетельствующий о том, что команда не воспринята, но можно попробовать ее исполнить еще раз
5yz Отклик, говорящий о том, что команда не выполнена и не может быть выполнена вообще
Значение кода «у» в вышеприведенной таблице может прини-
мать значения от 0 до 5. Значения кодов «у» приведены ниже:
Сети передачи данных. Метод доступа
845
'Значение кода- отклика Описание
xOz Указывает на синтаксическую ошибку; синтаксис верен но команда не имеет смысла
xlz Указание на необходимость ввода дополнительной х информации
x2z Отклик, связанный с управлением каналом связи’
x3z Отклик для команд идентификации пользователя и проверки пароля
x4z Функция не определена
x5z Отклик, характеризующий состояние файловой системы
Далее в тексте встречается выражение «анонимное FTP», это
подразумевает следующую процедуру (см. также RFC-1635):
ftp> login: anonymous
ftp> password: [ваш полный E-mail адрес]
ftp> cd <имя_каталога > (смена каталога)
ftp> binary (если текст, например, архивирован, в противном
случае команду выдавать не нужно)
ftp> get <имя_файла> (копирование файла)
ftp> quit (уход из процедуры)
Следует иметь в виду, что некоторые анонимные FTP-серверы
(также как, например, GOPHER-серверы) требуют, чтобы ЭВМ, с ко-
торой осуществляется ввод, имела не только IP-адрес, но и зарегист-
рированное в локальном DNS-сервере имя. Эти FTP-серверы, полу-
чив запрос, пытаются выяснить имя ЭВМ, так как они ведут «жур-
нал посещений», и в случае неуспеха прерывают сессию. Таким
образом, анонимное FTP может считаться таковым лишь условно, в
смысле ненужности быть авторизованным на сервере, чтобы иметь
к нему доступ. Конкретные примеры кодов статуса обмена для FTP
приведены в табл. 4.5.4.4. В настоящее время разработаны версии
FTP для работы с IPv6 (RFC-2428).
4.5.4.1. Протокол TFTP
TFTP (Trivial FTP, RFC-1350, -783, RFC-906), STD 0033 пред-
ставляет собой упрощенную версию FTP. TFTP не имеет системы
безопасности и идентификации, она в отличии от FTP базируется
на протоколе UDP (порт 69), а не TCP. Обычно передача осуществ-
ляется блоками по 512 байт с ожиданием подтверждения приема
каждого пакета (протокол «стой-и-жди»). TFTP используется при
загрузке операционной системы в бездисковые рабочие станции (напр.
^-терминалы, см. ВООТР) или для загрузки конфигурационных фай-
846
Гпава 4
Таблица 4.5.4.4. Коды откликов
Код- отклик Описание
110 Комментарий
120 Функция будет реализована через ппп минут
125 Канал открыт, обмен данными начат
150 Статус файла правилен, подготавливается открытие канала
200 Команда корректна
211 Системный статус или отклик на справочный запрос
212 Состояние каталога
213 Состояние файла
214 Справочное поясняющее сообщение
220 Слишком много подключений к FTP-серверу (можете попробо- вать позднее). В некоторых версиях указывает на успешное завершение промежуточной процедуры
221 Благополучное завершение по команде quit
225 Канал сформирован, но информационный обмен отсутствует
226 Закрытие канала, обмен завершен успешно
230 Пользователь идентифицирован, продолжайте
250 Запрос прошел успешно
331 Имя пользователя корректно, нужен пароль
332 Для входа в систему необходима аутентификация
421 Процедура не возможна, канал закрывается
425 Открытие информационного канала не возможно
426 Канал закрыт, обмен прерван
450 Запрошенная функция не реализована, файл не доступен, напри- мер, занят
451 Локальная ошибка, операция прервана
452 Ошибка при записи файла (не достаточно места)
500 Синтаксическая ошибка, команда не может быть интерпретиро- вана (возможно она слишком длинна)
501 Синтаксическая ошибка (неверный параметр или аргумент)
502 Команда не используется (нелегальный тип MODE)
503 Неудачная последовательность команд _
504 Команда не применима для такого параметра
530 Система не загружена (not logged in)
532 Необходима аутентификация для запоминания файла
550 Запрошенная функция не реализована, файл не доступен, например, не найден __
552 Запрошенная операция прервана, недостаточно выделено памяти
Сети передачи данных. Метод доступа
847
лов в маршрутизатор. Возможно и непосредственное исполнение
команды TFTP (TFTP имя_ЭВМ), хотя эта процедура и не дает
каких-либо серьезных преимуществ перед FTP (кроме скорости об-
мена). При выполнении команды без параметров машина выдает
приглашение TFTP> и вам предоставляется возможность выпол-
нить определенные команды (ЭВМ SUN):
connect ИМЯ—ЭВМ [ порт ]
Задает имя ЭВМ, с которой будет осуществляться обмен, и, если
это необходимо порт. Но реального соединения не производится,
так как это не предусмотрено протоколом.
mode модификация_обмена.
В качестве модификаций обмена данными могут использоваться
аргументы ASCII или binary. По умолчанию используется ASCII.
put имя_файла
put местный_файл удаленный_файл
put имя_файла1 имя_файла2 ... имя_файлаК удаленный—каталог
Копирование файла или группы файлов происходит в указанный
файл или каталог. Здесь предполагается, что имя удаленной ЭВМ
было указано ранее. Если же это не так, возможно одновременное
указание имени удаленной ЭВМ и имя файла-адресата: имя_ЭВМ:
имя файла. Имя_ЭВМ становится именем по умолчанию для пос-
ледующих обменов. Субкоманда get имеет аналогичную форму об-
ращения. Субкоманда trace позволяет отследить путь пакетов, а
команда status сообщит текущее состояние системы. Уход из TFTP
осуществляется по команде exit или quit.
Существует пять форматов пакетов TFTP (см. рис.4.5.4.1.1).
Операции запросов (RRQ и WRQ) требуют присылки пакета-от-
клика (АСК). Сначала устанавливается связь между клиентом и сер-
вером, для этого посылаются запросы read или write. При этом сооб-
щается имя файла и режим доступа (mode). Предусмотрено три режи-
ма доступа, которые определяются значением поля MODE: Net ASCII
(американский стандарт для информационных обменов), побайтный
(режим binary) и почтовый (данные поступают пользователю, а не
заносятся в файл, при этом используется система кодов Net ASCII).
Предусмотрено шесть типов сообщений об ошибках:!) - не определен;
1 - файл не найден;
2 - ошибка доступа;
3 - переполнение диска или превышение выделенной квоты;
4 - нелегальная TFTP-операция;
5 - неизвестный идентификатор обмена.
848
Гпава 4
1 октет
п октетов
Код субкоманды
2 октета
п октетов 1 октет
| READ REQ.(1) Имя команды 0 MODE l_° I
Запрос чтения (RRQ=1) Код субкоманды 2 октета п октетов 1 октет п октетов 1 октет
I READ REQ.(2) Имя файла 0 MODE 0
Запрос записи (WRQ=2) Код субкоманды 2 октета 2 октетов до 512 октетов
Данные (3) Блок # Октеты данных |
Пакет данных (код операции =3)
Код субкоманды
2 октета 2 октетов
АСК (4) Блок #
Отклик АСК (код операции = 4)
Код субкоманды
2 октета 2 октета п октетов 1 октет
| ERROR (5) Код ошибки Сообщение об ошибке " I
Сообщение об ошибке (код операции =5)
Рис. 4.5.4.1.1. Форматы TFTP-сообщений
Если запросы read или write успешно выполнены, сервер исполь-
зует IP-адрес и номер UDP-порта клиента для идентификации пос-
ледующих операций. Таким образом, ни при пересылке данных, ни
при передаче подтверждений (АСК) не нужно указывать явно имя
файла. Блоки данных нумеруются, начиная с 1, подтверждение по-
лучения пакета имеет тот же номер. Получение блока с размером
менее 512 байт означает конец файла. Получение сигнала об ошиб-
ке прерывает обмен. При возникновении тайм-аута производится
повторная передача последнего блока данных или подтверждения.
При задержке отклика, превышающей значение тайм-аута, возмож-
но удвоение всех последующих блоков. Это происходит в некото-
рых реализациях программного обеспечения оттого, что из-за тайм-
аута происходит повторная пересылка блока, а запоздавший от-
клик на блок i вызовет посылку блока i+1. Это будет продолжаться
вплоть до конца пересылки файла. TFTP-протокол используется
также и при реализации электронной почты (посылка файлов по-
чтовой программе для приложений).
Отсутствие авторизации делает доступность TFTP одной из угроз
безопасности. Именно по этой причине во многих инструкциях вЫ
можете найти рекомендацию запретить применение этой утилиты.
Сети передачи данных. Метод доступа
849
4.5.5. World Wide Web (WWW или W3J
Определения и понятия
Прежде чем передать что-то, надо это иметь. Люди общаются,
используя естественные языки, ЭВМ обмениваются нуликами и еди-
ницами. Но даже в привычном для всех нас общении на родном
языке иногда возникают проблемы, и тогда мы переспрашиваем
партнера (это прием используют и коммуникационные системы).
Когда же мы читаем, перед нами возникает последовательность сим-
волов из хорошо известного с детства алфавита. Символы эти могут
существенно варьироваться по форме своего изображения, но мы их
все равно без труда распознаем.
Получаемая нами информация поступает не только от общения с
людьми, книгами или телевизором. Не мало крайне важных для жизни
данных мы получаем о себе и окружающем мире по имеющимся у
нас каналам органов чувств. Мы научились сопоставлять и перепро-
верять эти данные, когда это требуется. Успешное функционирова-
ние этих каналов передачи данных и средств их обработки позволяет
нам прожить относительно долгую жизнь. Любые же сбои могут
повлиять на нашу судьбу самым драматическим образом.
Человечество научилось усовершенствовать данные нам приро-
дой каналы информационного обмена. Сначала это были примитив-
ные сигнальные системы типа костров на вершинах холмов (про-
пускная способность 0,5 бит/час). Появление письменности откры-
ло возможность общения уже умерших людей с живыми, обеспечив
процесс накопления знаний. Довольно большие объемы информа-
ции могли уже передаваться с использованием лошадей и кораблей
на практически неограниченные расстояния. Но скорость такого
обмена была ничтожна, доставка сообщения занимала часы, дни, а
иногда и годы (никакого намека на работу современной почты я
здесь не делаю).
Гигантским шагом вперед стало изобретение электрического
телеграфа, а позднее радио. Сегодня же мы узнаем о землетрясении
в 20000 км от нас максимум через час из очередного телевизионно-
го сборника новостей. Люди объясняются в любви с использовани-
ем электронной почты и делают покупки, не выходя из дома.
На нас обрушилась лавина информации. Мы стали получать
слишком много совершенно ненужной информации. Миллионером
станет человек, который предложит покупателям дешевый телеви-
зор, отфильтровывающий информацию согласно требованиям зри-
теля. Таким образом, мы уже сталкиваемся с новыми информаци-
850
Гпава 4
онными проблемами, хотя нельзя сказать, что мы решили все ста-
рые. Сплошь и рядом мы узнаем слишком поздно о своих болез-
нях, об угрозах стихийных бедствий или об истинных свойства^
того или иного политика.
Эти же проблемы относятся и к Интернет. По электронной по-
чте вы получаете сообщения от совершенно незнакомых людей, ко-
торые утверждают, что очень хотят вашего быстрого обогащения
(хотя их цели диаметрально противоположны), или предлагающих
вам какие-то товары или услуги, хотя вы их об этом не просили.
К Интернет получили доступ десятки миллионов людей. Если в
издательствах редакторы, заботясь о доходах и избегая убытков, бло-
кируют доступ графоманов к широким массам читателей, такого ме-
ханизма в Интернет не существует. Таким образом, программные сред-
ства, фильтрующие поток данных на входе вашего почтового или WEB-
сервера, здесь также актуальны. Ниже даются некоторые определения
понятий, используемых в разделах о протоколе HTTP и WWW.
Рассмотрим некоторые свойства информации, например струк-
турированность и ценность. Структурированность - это свойство,
которое позволяет принимающей стороне выделить информацию в
виде некоторого сигнала, обладающего некоторыми свойствами.
Ценность данных выражается через содержательность, полноту, опе-
ративность и достоверность.
При обработке и передаче данных важную роль играют знаки и
знаковые системы. Знак - это материальный объект, который слу-
жит для обозначения другого объекта и используется для передачи
информации о последнем. Примерами знаков могут служить ноты,
цифры, жесты азбуки глухонемых, знаки регулирования уличного
движения и т.д. Одной из разновидностей знака является символ.
Разновидностью знаковых систем являются языки, самым слож-
ным из которых является естественный человеческий язык. Все
проявления и применения знаков и знаковых систем изучает семи-
отика. Предметом семиотики является связь знаков друг с другом,
с обозначаемыми ими объектами и явлениями, а также с субъектами
их использующими для целей коммуникаций. Семиотика содержит
в себе три раздела: семантика, синтактика и прагматика.
Семантика изучает отношения между знаком и тем, что он
обозначает или замещает. Синтактика знаковых систем изучает
их структуру и правила соединения знаков. Прагматика изучает
законы функционирования знаковой системы, как средства комму-
никации субъектов. С прагматикой связаны такие понятия как
ценность и цель. После этого вступления перейдем к теме данной
главы по существу.
Сети передачи данных. Метод доступа
851
World Wide Web (всемирная сеть, WWW или 3W) представляет
собой информационную систему, базирующуюся на использовании
гипертекста. Разработка этой системы была начата Тимом Бер-
нерс-Ли, которому в 1989 году пришла в голову мысль объединить
гипертекст с Интернет. Идея впервые реализована в ЦЕРН (Жене-
ва). WEB-технология базируется на протоколе HTTP. Доступ к
WWW возможен только в рамках протоколов TCP/IP, но для ис-
пользования 3W необязательно иметь WEB-клиент (browser) на
вашей машине. Весьма удобным программным интерфейсом для
WWW является MS Explorer, NetScape и некоторые другие. Для
подготовки документов в рамках HTML (HyperText Markup Language)
пригоден любой текстовый редактор (например, emacs в UNIX-ма-
шинах, ME в MS-DOS или WINWORD, в последних версиях которо-
го уже допускаются гиперссылки). При подготовке гипертекстов вы
можете использовать язык HTML или взять одно из множества
доступных программных средств, которые позволяют преобразовать
ваш документ в необходимый формат. Пользователю не нужно знать,
где находится тот или иной документ. Часто ссылки на серверы
WWW начинаются с сокращения http:// (HyperText Transfer
Protocol). Гипертекст позволяет, осуществлять ссылки на статьи,
хранящиеся на удаленном сервере. Гипертекст подразумевает не
только текстовые объекты (но и графические или звуковые), поэто-
му термин гиперсреда (Hypermedia) более правилен. WWW может
проводить поиск ключевых слов и в специфических документах-
индексах, в этом случае выдаются указатели на искомые докумен-
ты. WWW может использовать различные форматы документов и
работать с разнообразными структурами информации, обеспечивая
доступ к информационной вселенной. На рис. 4.5.5.1 показан рост
числа WEB-серверов, базирующихся на разных программных про-
дуктах (www.Netcraft.com).
----Apache ....Microsoft - • • Прочие — • — IPIanet
₽ИС. 4.5.5.1. Рост числа WEB-серверов в период 1995-99 годов
852
Гпава 4
На февраль 1999 года число WWW-серверов равнялось 4.301.512.
Что же такое гипертекст?
Прежде всего, следует отметить, что гипертекст - это текст, со-
стоящий из ASCII-символов. Для обеспечения верстки и организа-
ции перекрестных ссылок в гипертексте используются слова-метки.
Основу гипертекста составляют HTML-элементы. Такой элемент
включает в себя имя, атрибуты, текст или гипертекст. HTML-эле-
мент записывается в документ в виде:
<имя_метки> текст </имя_^метки>
<имя_метки> имя_атрибута=аргумент текст </имя_метки>
HTML-документ состоит из одного элемента:
<html>
.... </html>, который состоит из HTML-элементов:
<head> ... </head> и <body> ... </body>,
последние в свою очередь могут содержать различные списки, внут-
ренние и внешние метки и т.д.. Элементы <HTML>, <HEAD> и
<BODY> для совместимости с более старыми текстами сделаны пока
необязательными. В HTML имеется 6 уровней заголовков (<Н1>,
.... <Н6>), из них первый — главный. В версии HTML+ (и более
поздних версиях) предусмотрены операторы позиционирования тек-
ста, например, <Р ALIGN=”CENTER”> или <Р ALIGN==”JUSTIFY”>.
HEAD-элементы могут содержать в себе элемент:
<isindex>
который говорит о том, что данный документ допускает индексный .
поиск (база данных).
Элемент <title> . . . </title> описывает заголовок документа,
этот заголовок характеризует содержимое окна.
<base href=”URL”>
сообщает имя файла, в котором хранится данный документ.
clink rev=”RELATIONSHIP” rel=" RELATIONSHIP”
href="URL">
этот элемент позволяет установить связь между документом, содер-
жащим метку (якорь), и документом, указанным в URL (Uniform
Resource Locator). Атрибут rel устанавливает связь между HTML-
файлом и URL. Атрибут rev (reverse) описывает взаимоотношения
между URL и HTML-файлом.
Элементы body могут содержать элементы:
Текстовые элементы:
Сети передачи данных. Метод доступа 853
<р> индицирует конец параграфа и начало нового.
<рге> . . . </рге>
выделяет текст, который уже был сформатирован ранее (таблицы,
программы, стихи, ...).
<blockquote> . . . </blockquote>
ограничивает часть текста, который должен быть выделен ка-
вычками.
Гиперсвязи или якоря
<а name="anchor_name"> . . . </а>
определяет заданную позицию в документе.
<а href=="#anchor_name"> . . . </а>
описывает ссылку на определенное место текущего документа.
<а href=="URL"> . . . </а>
устанавливает связь с другим файлом или ресурсом.
<а href="URL#anchor_name"> . . . </а>
устанавливает связь с заданным местом в другом документе.
<а href=”URL?search_word+search_word”> . . . </а>
посылает серверу эталонную строку для поиска.
Различные системы поиска могут интерпретировать эту строку по-
разному. Для того чтобы читатель незнакомый с гипертекстом, полу-
чил некоторое представление о том, как он выглядит, приведу пример:
<TITLE> Протоколы и ресурсы Интернет </TITLE>
< Н1> Это уровень первого заголовка </Н1>
< Н2> Уровень второго заголовка </Н2>
< Р> Начало параграфа ....
Вам уже ясно, что подготовка гипертекстов "вручную" изнури-
тельная задача и вспомогательные программные средства не повре-
дят (например, FrontPage), особенно если вы хотите, чтобы ваш текст
выглядел привлекательно. Заметим, что управляющие слова-метки
могут записываться как строчными, так и прописными буквами
(<Н1> = <Ы>), но они могут восприниматься различными про-
граммами просмотра по-разному (могут и игнорироваться вовсе).
HTML поддерживает нумерованные (OL), ненумерованные (UL), и
описательные списки (DL). Пример нумерованного списка:
Записано в гипертексте
<OL>
Отображено на экране
' 854
Гпава 4
<LI> Белоруссия</Ы> <Ы> Россия</Ы> <Ы> Украина</Ы> </OL> 1. Белоруссия 2. Россия 3. Украина
Примером описательного списка может служить:
<DL>
<DT> ИТЭФ
<DD> Институт Теоретической и Экспериментальной Физики,
Москва, Россия.
<DT> ИФВЭ
<DD> Институт Физики Высоких Энергий, Протвино.
</DL>
На экране это будет выглядеть примерно так:
ИТЭФ
Институт Теоретической и Экспериментальной Физики, Москва.
ИФВЭ
Институт Физики Высоких Энергий, Протвино.
<DT> — метка определения, a <DD> — метка данных описа-
ния. Как <DT> так и <DD> могут содержать много параграфов,
разделенных меткой <Р>. Допускается вложение списков друг в
друга, например <FSU.HTML>:
<UL>
<Ы> Белоруссия</Ы>
<Ы> Россия</Ы>
<DL>
<DT> ИТЭФ
<DD> Институт Теоретической и Экспериментальной Физики,
Москва.
<DT> ИФВЭ
<DD> Институт Физики Высоких Энергий, Протвино.
</DL>
<LI> Украина</Ы>
</UL>
qqth передачи данных. Метод доступа
855
Некоторые символы являются служебными для HTML и для их
отображения на экране требуются определенные ухищрения. На-
пример1 :
Символ записывается как
< <
> >
& &
(неразрывный пробел)
Символ ; (точка с запятой) является составной частью описания.
Все предшествующее относилось к описанию представления текстов
на экране. Теперь рассмотрим, как можно обозначить смысловые свя-
зи и ссылки друг на друга различных частей текста. Собственно именно
ради этого и создавалась идеология гипертекстов. Метка, означаю-
щая наличие связи, имеет вид <А> и происходит от слова anchor
(якорь). В общем виде ссылка имеет следующий формат:
<А HREF="URL"> текст </А>
URL (Universal Resource Locator) в простейшем случае может
быть именем файла. Текст обозначает действительный текст в до-
кументе, который может быть подсвечен, выделен другим цветом
или помечен цифрой. Этот текст говорит программе просмотра, что
в URL можно найти связанную с данным документом информацию
или изображение. При использовании программы типа MS Explorer
(или Netscape) для вызова этой информации или изображения на
экран достаточно указать мышкой на текст и нажать кнопку. Если
URL указывает на объект, находящийся не в вашей сети эта проце-
дура может занять некоторое время. Чтобы вас как-то развлечь,
программа показывает вам вращающийся земной шар в верхнем
правом углу экрана. Метка <А> может использоваться и для ссыл-
ки на определенный раздел документа:
<А NAME=" ref name ”> текст </А>,
где ref паше является меткой в вашем документе. Пусть в файле
FSU.HTML определена следующая ссылка-якорь:
<А NAME=’ итэф"> ИТЭФ </А>
т°гда, находясь в пределах этого документа, можно попасть в нуж-
ную точку с помощью:
<А ННЕГ=”#итэф”> У-10 </А> протонный синхротрон.
——-
Смотри приложение “Символьный набор HTML”
856 Глава $
В другом документе может присутствовать встречная ссылка,
например:
У-10 в <А HREF=”fsu.html#HT34)’’> ИТЭФ>/А>
Теперь, при нажатии кнопки мышки на слове ИТЭФ, программа
отобразит fsu.html и отметит позицию со словом ИТЭФ (ссылка
МАМЕ=итэф). Вообще говоря, вы можете ссылаться на метки-якоря
в файлах, находящихся на другой машине (на другом конце земли
:-)), приводя полное имя URL. В общем случае URL указывает тип
и место расположения ресурса:
cepBep://host.domain[:port]/path/o6beKT,
где в качестве сервера может стоять: ftp, telnet, http, gopher, WAIS,
news. Path описывает проход к каталогу, где лежит файл “объект”.
Если программа просмотра способна воспроизводить изображения,
можно ввести ссылки на файлы, содержащие нужные для поясне-
ния текста картинки, например:
<IMG 8РС="имя_файла.О1Е”>
Обратите внимание, что здесь используется графический стан-
дарт GIF (Graphics Interchange Format). Приемлемы также графи-
ческие форматы TIFF, JPEG, RGB и HDF. Читатели, желающие сфор-
мировать титульную страницу (Home Page) своего института, фирг
мы или проекта, должны изучить предмет более углубленно,
обратившись, например по адресу:
http://www.w3. org/TR/REC-html40-971218">www. w3.org/TR/
REC-html40-971218 ;
После этого недолгого экскурса в гипертекст, который является
основой многих поисковых систем, вернемся к проблематике WWW/
Следует заметить, что публично доступные клиент-серверы суще^
ствуют для сред MS-DOS, MVS, UNIX, X-Windows, Macintosh, NeXT/
Это математическое обеспечение доступно через анонимный FTP из
депозитария info.cern.ch секции /pub/www (или www.earn.net gnrt/
www.html). Графические клиент-серверы доступны для Unix, Windows,
Macintosh, X-Windows, NeXT.
WWW-сервер в простом варианте выполняет лишь команды get’
имя_файла, приходящие от клиент-сервера пользователя. Остальи
ная работа выполняется WWW-клиентом. 4
Например, URL для анонимного ftp:
ftp.rpi.edu/pub/communications/internet-cmc.txt
означает:
£ети передачи данных. Метод доступа 857
Вид Имя
доступа ЭВМ Путь
ftp:// -LlLJi’Ls'Jk5 /pub/communications/internet-cmc.txt
Графические интерфейсы требуют большой пропускной сдособ-
ности от информационных каналов (желательно > 64 Кб/с). Имен-
но NetScape и MS Explorer стали наиболее популярными интерфей-
сами поисковых информационных систем и источником наиболь-
ших загрузок в телекоммуникационных каналах. Этот интерфейс
наиболее естественно позволяет работать и с графическими объек-
тами. Публично доступны версии NetScape для Windows, Unix и т.д.
Сегодня трудно найти какую-либо фирму, организацию или
общественную группу, не представленную в Интернет своей Web-
страницей. Эта технология широко используется в сфере рекламы и
даже продажи товаров. Следствием этого стала актуальность про-
блем безопасности для Web-серверов. Большинство этих проблем
происходят от несовершенства программ. Несмотря на общеизвест-
ный совет не использовать программы версии 1.0, ошибки и "дыры"
встречаются и в более поздних версиях (например, в Apache V. 1.1.1
или Netscape Navigator 2.0, MS Internet Explorer 3.0 и т.д.). Хотя
функция Web-сервера принципиально проста: найти запрошенный
URL и послать его заказчику, реально практически все существую-
щие серверы "обросли" конфигурационными опциями, интерфейса-
ми для различных баз данных, снабжены адаптерами для разных
версий HTTP и HTML, скриптами и модулями API, поисковыми
системами. В результате исполняемый модуль WWW-сервера в не-
сколько раз больше, чем для FTP-сервера, что оставляет достаточно
пространства для ошибок и возможностей для реализации хакерс-
ких замыслов.
4.5.5.1. Программное обеспечение WWW
Существует достаточно широкий список программного обеспече-
иия для формирования WEB-сервера. Структура и конфигурация
этих серверов варьируется в широких пределах, но есть у них и
кемало общего. Рассмотрим основные каталоги, которые возника-
ет при установке WEB-сервера.
Каталог конфигурации. Здесь содержатся файлы, которые опре-
деляют рабочие характеристики сервера. Этот каталог жизненно
в^Жен, и необходимо максимально возможно ограничить круг лиц,
к°торым разрешено изменять здесь что-либо.
858
Гпава 4
Инструментальный каталог администратора. Этот каталог со- 1
держит утилиты, которыми пользуется администратор сервера. Здесь |
могут располагаться программы управления доступом, генерации
криптографических ключей и формирования поисковых индексов.
Каталог файла регистрации операций (LOG-файла). Здесь фик-
сируются все процедуры доступа к серверу, а также все происходя-
щие сбои и ошибки.
Каталог CGI. В этом каталоге располагаются CGI-скрипты, ко-
торые используются для формирования документов с динамически
изменяющимся содержимым, для организации доступа к базам дан-
ных и выполнения интерактивных задач. Здесь же могут находить-
ся средства, которые позволяют администратору-программисту до-
бавлять свои собственные функции сервера, расширяя его возмож-
ности.
Каталог документов (корневой каталог документов). Этот ката-
лог составляет основу иерархического дерева каталогов документов
сервера. Каталог может включать субкаталоги типа html, java, icons
и т.д.
Помимо перечисленных может присутствовать каталог security,
где лежат параметры доступа (имена и пароли) авторизованных
клиентов сервера.
Современные WEB-серверы трудно себе представить без CGI-скрип-
тов (Common Gateway Interface). Эти скрипты позволяют существенно
расширить возможности сервера, обеспечить доступ к базам данных,
работать с документами, содержимое которых изменяется динами-
чески, организовать игры в реальном масштабе времени, обрабаты-
вать запросы клиентов, посылать сообщения по электронной почте
и многое другое. CGI-скрипты обеспечивают интерфейс между WEB-
сервером, серверами FTP и базами данных. Привлекательность CGI-
скриптов и легкость их написания, к сожалению, дополняется тем,
что совсем не просто написать их безошибочно.
CGI-скрипты (ISO 9636) представляют собой небольшие про-
граммы, которые являются независимыми от основной программы
сервера. Когда удаленный пользователь запрашивает URL, который
указывает на CGI-скрипт, сервер исполняет скрипт, передавая ин-
формацию о состоянии сессии. CGI-скрипт обрабатывает эти дан-
ные и выдает документ, который, вообще говоря, может быть и не
только HTML-страницей. Среди информации, которую передает сер-
вер CGI-скрипту, обычно присутствует строка запроса, содержащая
данные, которые поступили от удаленного пользователя. Форма стро-
ки запроса произвольна. Она может содержать ключевые слова для
поиска или SQL-предложение для обращения к серверу базы дан-
Сеги передачи данных. Метод доступа
959
ных. Строка запроса может быть передана CGI-скрипту двумя спо-
собами. В первом случае она прикрепляется к URL. Например:
http’ //www.altavista.com/cgi-bin/query?pgi=q&what==wd)&fmt=F.&q==questLon
Все, что следует после знака вопроса, представляет собой строку
запроса. В этой версии строка запроса должна следовать требовани-
ям записи URL, т.е. пробелы должны заменяться символом + (клю-
чевым словом в приведенном запросе является question). CGI-скрипт
извлекает строку запроса с учетом переменной конфигурации
(environment). Альтернативой этому является посылка строки зап-
роса CGI методом HTTP POST. Этот метод обычно используется
при заполнении пользователем форм и отправке их удаленному
серверу. В этом случае WEB-сервер направляет строку запроса не-
посредственно на стандартный вход скрипта. Желательно пользо-
ваться хорошо проверенными скриптами, а при написании новых
следить за тем, чтобы они ни при каких обстоятельствах не допус-
кали исполнения команд на машине сервера и не производили не-
санкционированной модификации файлов.
Пользователи WEB-сервера, которые имеют доступ к докумен-
там и файлам поддержки обычно делятся на четыре категории:
хозяин, автор, разработчик и администратор. Каждая их этих кате-
горий имеет разные права доступа, показанные в таблице 4.5.5.1.
Таблица 4.5.5.1. Возможности различных категорий
пользователей WEB-сервера
Пользователь Тип файла
Конфигура- ционный Инструмен- тальный LOG- файл CGI Документы
Хозяин RW R R RW RW
Разработчик - - - RW RW
Автор - - - R RW
Клиент - - - R R
R - разрешено чтение. W - разрешена запись и уничтожение.
Хозяином в данном случае считается администратор узла, где
размещен WEB-сервер. Автор занимается подготовкой документов
и рисунков. Разработчик имеет сходные функции с автором, но в
его обязанности входит также разработка и модификация CGI-скрип-
тов и модулей сервера. Клиент (посетитель) может запускать скрип-
ты и читать любые документы. Приведенная иерархия возможнос-
тей для пользователей гарантирует устойчивую работу и безопас-
ность WEB-сервера.
860
Гпава 4
4.5.5.1. Протокол передачи гипертекста — 'НТТР/1.1
(Авторизованный перевод RFC 2068, Hypertext Transfer Protocol
- HTTP/1.1, U.C. Irving, смотри также RFC-2069)
Протокол передачи гипертекста HTTP является протоколом при-
кладного уровня для распределенных мультимедийных информацион-
ных систем. Это объектно-ориентированный протокол, пригодный для
решения многих задач, таких как создание серверов имен, распределен-
ных объектно-ориентированных управляющих систем и др.. Структу-
ра HTTP позволяет создавать системы, независящие от передаваемой
информации. HTTP один из самых сложных протоколов, он служит
для создания широкого круга приложений, начиная с WEB-серверов и
поисковых систем, кончая различными системами дистанционного обу-
чения и пр. Протокол HTTP использован при построении глобальной
информационной системы World-Wide Web (начиная с 1990).
Первые версии, такие как НТТР/0.9, представляли собой простые
протоколы для передачи данных через Интернет. Версия НТТР/1.0,
описанная в RFC 1945 [6], улучшила протокол, разрешив использо-
вание сообщений в формате MIME, содержащих метаинформацию о
передаваемых данных, и модификаторы для запросов/откликов. Даль-
нейшее развитие сетей WWW-серверов потребовало новых усовер-
шенствований, которые вряд ли являются последними.
Реальные информационные системы требуют больших возмож-
ностей, чем простой поиск и доставка данных. Для описания ха-
рактера, наименования и места расположения информационных ре-
сурсов введены: универсальный идентификатор ресурса URI (Uniform
Resource Identifier), универсальный указатель ресурса URL и уни-
версальное имя ресурса URN. Формат сообщений сходен с исполь-
зуемыми в электронной почте и описанный в стандарте MIME
(Multi purpose Internet Mail Extensions).
HTTP используется также в качестве базового протокола для
коммуникации пользовательских агентов с прокси-серверами и дру-
гими системами Интернет, в том числе и использующие протоколы
SMTP, NNTP, FTP, Gopher и WAIS. Последнее обстоятельство спо-
собствует интегрированию различных служб Интернет. Ниже опи-
саны базовые понятия и термины протокола HTTP. Взаимодей-
ствие клиента, кэша и исходного сервера показано на рис. 4.5.5.1.1 •
Прокси
Промежуточная программа, которая выполняет функции, как сер'
вера, так и клиента. Такая программа предназначена для обслужи-
вания запросов так, как если бы это делал первичный сервер. Зап-
росы обслуживаются внутри или переадресуются другим серверам-
Qern передачи данных. Метод доступа
861
Туннель
Промежуточная программа, которая работает как ретранслятор
между двумя объектами. Туннель закрывается, когда обе стороны,
соединенные им прерывают сессию. Туннель может быть активиро-
ван с помощью НТТР-запроса.
Время пригодности объекта (expiration time)
Время, по истечении которого исходный сервер требует’, чтобы
объект не посылался более кэшем без перепроверки пригодности.
Эвристическое значение времени жизни (heuristic expiration time)
Время пригодности, присваиваемое объекту в кэше, если это вре-
мя не задано явно.
Возраст
Возраст отклика - время с момента его посылки или проверки
его пригодности исходным сервером.
Время жизни (freshness lifetime)
Продолжительность времени с момента генерации отклика до
истечения его пригодности.
Свежий. Отклик считается свежим, если его возраст не превысил
времени его пригодности.
Устаревший. Отклик считается устаревшим, когда его возраст
превысил время жизни.
Семантическая прозрачность
Кэш по отношению к конкретному отклику функционирует в
"семантически прозрачном’’ режиме, когда его использование не имеет
последствий ни для исходного сервера, ни для запрашивающего кли-
ента. Когда кэш семантически прозрачен, клиент получает в точно-
сти тот же отклик (за исключением транспортных заголовков), ка-
кой он бы получил при непосредственном обращении к исходному
серверу.
Валидатор
Протокольный элемент (например, метка объекта или время Last-
Modified), который используется для выяснения того, является ли
запись в кэше эквивалентной копией объекта.
Метод
Процедура, выполняемая над ресурсом (GET, PUT, HEAD, POST,
DELETE, TRACE и т.д.).
Кэш может находиться в ЭВМ клиента или агента пользовате-
ля» но может размещаться на соседнем континенте. Число прокси
Между клиентом и исходным сервером может варьироваться и ог-
раничивается сверху только здравым смыслом. Структура ресурсов
и объектов показана на рис. 4.5.5.1.2.
862
Гпава 4
Рис. 4.5.5.1.1. Взаимодействие клиента, кэша
и исходного сервера в протоколе HTTP
Протокол HTTP представляет собой протокол запросов-откли-
ков. Клиент посылает запрос серверу в форме, определяющей метод,
URI и версию протокола. В конце запроса следует MIME-подобное
сообщение, содержащее модификаторы, информацию о клиенте и,
возможно, другие данные. Сервер откликается, посылая статусную
строку, которая включает в себя версию протокола, код результата
(успех/неудача) и MIME-подобное сообщение, в котором содержат-
ся данные о сервере и метаинформация.
Большинство HTTP-обменов инициируются пользователем и
состоят из запросов ресурсов, имеющихся на определенном сервере.
В простейшем случае такой запрос может быть реализован путем
соединения пользовательского агента (UA) и базового сервера.
Более сложная ситуация возникает, когда присутствует один или
более посредников в цепочке обслуживания запроса/отклика. Су*
ществует три стандартные формы посредников: прокси, туннель и
внешний порт (gateway). Прокси представляет собой агент переад-
Рис. 4.5.5.1.2. Структура ресурса и объекта
Qern передачи данных. Метод доступа
863
ресации, получающий запрос для URI, переписывающий все сообще-
ние или его часть и отправляющий переделанный запрос серверу,
указанному URL Внешний порт (gateway) представляет собой при-
емник, который работает на уровень выше некоторых других серве-
ров и транслирует, если необходимо, запрос нижележащему протоко-
лу сервера. Туннель действует как соединитель точка-точка и не
производит каких-либо видоизменений сообщений. Туннель исполь-
зуется тогда, когда нужно пройти через какую-то систему (например,
firewall) в условиях, когда эта система не понимает (не.анализиру-
ет) содержимое сообщений.
Запрос--------------------------------->
UA----------А---------В----------С----------О
<--------------------------------отклик
Рис. 4.5.5.1.3. UA - агент пользователя
На рисунке 4.5.5.1.3 показаны три промежуточные ступени (А,
В, и С) между агентом пользователя (UA) и базовым сервером (О).
Запрос или отклик, двигаясь по этой цепочке, должен пройти четыре
различных соединительных сегмента. Это обстоятельство крайне
важно, так как некоторые опции HTTP применимы только для
ближайших соединений. Хотя схема линейна, на практике узлы
могут участвовать в большом числе других взаимодействий. На-
пример, В может получать запросы от большого числа клиентов
помимо А, и переадресовывать запросы к другим серверам кроме С.
Любой участник обмена, который не используется в качестве
туннеля, может воспользоваться кэшем для запоминания запросов.
Буфер может сократить длину цепочки в том случае, если у одного
из участников процесса имеется в буфере отклик для конкретного
запроса, что может, кроме прочего, заметно снизить требования к
пропускной способности канала. Не все запросы могут записывать-
ся в кэш, некоторые из них могут содержать модификаторы работы
с кэшем.
В действительности имеется широкое разнообразие архитектур
и конфигураций буферных запоминающих устройств и прокси, раз-
рабатываемых в настоящее время или уже доступных через World
Wide Web. Эти системы включают иерархии прокси-серверов нацио-
нального масштаба, задачей которых является сокращение трансо-
ганского трафика, системы, которые обслуживают широковещатель-
ные и мультикастинговые обмены, организации, распространяющие
Фрагменты информации с CD-ROM, занесенной в кэши и т. д.. HTTP-
864
Гпава 4
системы, используются в корпоративных сетях Интранет с больши-
ми пропускными способностями и перемежающимися соединения-
ми. Целью НТТР/1.1 является поддержка широкого разнообразия
уже существующих систем и расширение возможностей будущих
приложений в отношении надежности и адаптируемости.
Коммуникации HTTP обычно реализуются через соединения ТСР/
IP. Порт по умолчанию имеет номер 80, но и другие номера портов
вполне допустимы. Это не исключает использования HTTP поверх
любого другого протокола в Интернет, или других сетей. HTTP
предполагает надежное соединение; применим любой протокол, ко-
торый может гарантировать корректную доставку сообщений.
В HTTP/1.0, большинство приложений используют новое соеди-
нение для каждого обмена запрос/отклик. В НТТР/1.1, соединение
может быть использовано для одного или более обменов запрос/
отклик, хотя соединение может быть разорвано по самым разным
причинам.
4.5.5.1.1. Соглашения по нотации и общая грамматика
1.1. Расширенные BNF
Все механизмы, специфицированные в данном разделе, описаны
с использованием обычного текста и расширенных форм Бахуса-
Наура BNF (Backus-Naur Form; см. RFC 822). Пользователи для
понимания данной спецификации должны быть знакомы с этой но-
тацией. Расширение BNF включает в себя следующие конструкции:
name = definition
Имя правила не требует помещения в угловые скобки. Некото- .
рые базовые правила записываются прописными буквами, например,
SP, LWS, НТ, CRLF, DIGIT, ALPHA и пр.
"literal”
Двойные кавычки используются для выделения символьного
текста.
rulel | rule2
Элементы, разделенные вертикальной чертой, ("|") являются аль-
тернативными, например, "yes | по" допускает yes или по (да или нет).
(rulel rule2)
Элементы, помещенные в круглые скобки, рассматриваются как
один элемент. Так, "(elem (foo | bar) elem)" допускают последовав
тельности "elem foo elem" и "elembar elem*’.
Сети передачи данных. Метод доступа
865
*rule
Символ предшествующий элементу, указывает на повторе-
ние. Полная форма "<n>*<m>element” указывает как минимум на
<п> и как максимум <т> повторений элемента. Значения по умол-
чанию равны 0 и бесконечности, так что ’’^(элемент)” позволяет
любое число, включая ноль; "l*element" требует, по меньшей мере,
один; a "l*2element" допускает один или два.
[rule]
В квадратные скобки заключаются опционные элементы; ”[foo
bar]" эквивалентно "*l(foo bar)’’.
N rule
Специальный повтор: ’’<п>(элемент)" эквивалентно "<n>*<n>
(элемент)’’; то есть, точно <n> (element). Таким образом, 2DIGIT
является 2-значным числом, а 3ALPHA представляет собой строку
из трех буквенных символов.
#rule
Конструкция ’’#’’ определена подобно для описания списка
элементов. Полная форма имеет вид ’’<n>#<m>element ’’, отмечая,
по меньшей мере <п> и по большей <т> элементов, отделенных
друг от друга одной или более запятыми (",’’) и опционно строчным
пробелом (LWS - Linear White Space). Это делает обычную форму
списков очень простой. Запись "(*LWS элемент *(*LWS *LWS
элемент))’’ может быть представлена как ’’l#element’’. Всюду, где
используется эта конструкция, допускаются нулевые элементы, но
они не учитываются при подсчете. То есть, допускается запись "(эле-
мент), (элемент) ", но число элементов при этом считается равным
двум. Следовательно, там, где необходим хотя бы один элемент,
должен присутствовать, по крайней мере, один ненулевой элемент.
Значениями по умолчанию являются 0 и бесконечность, таким об-
разом ’’#элемент" позволяет любое число, включая нуль, "1#эле-
мент" требует, по меньшей мере один; а ”1#2элемент’’ допускает
один или два.
; комментарий
Точка с запятой, смещенная вправо от линейки текста, открыва-
ет комментарий, который продолжается до конца строки. Это про-
стой способ включения замечаний в текст спецификаций.
implied *LWS
28 Зак. № 3430 Семенов
866
Гпава 4
Грамматика, описанная в данной спецификации, ориентирована
на слова. Если не оговорено обратное, строчный пробел (LWS) мо-
жет быть заключен между любыми двумя соседними словами (лек-
сема или заключенная в кавычки строка), и между смежными лек-
семами (token) и разделителями (tspecials) без изменения интерпре-
тации поля. По крайней мере один разграничитель (tspecials) должен
присутствовать между любыми двумя лексемами, так как они иначе
будут интерпретироваться как одна.
1.2. Основные правила
Следующие правила используются практически во всей специ-
фикации для описания основных конструкций разбора (парсинга).
ОСТЕТ= <любая 8-битовая последовательность данных>
CHAR = <любой символ US-ASCII (октеты 0 — 127)>
UPALPHA = <любая прописная буква US-ASCII ”A".."Z">
LOALPHA = < любая строчная буква US-ASCII ”a”..”z”>
ALPHA = UPALPHA | LOALPHA (сточная или прописная
буква)
DIGIT = <любая цифра US-ASCII ”0”..”9”>
CTL = <любой управляющий символ US-ASCII (октеты 0 — 31)
и DEL (127)>
CR = <US-ASCII CR, возврат каретки (13)>
LF = <US-ASCII LF, перевод строки (10)>
SP = <US-ASCII SP, пробел (32)>
НТ = <US-ASCII НТ, знак горизонтальной табуляции (9)>
<"> = <US-ASCII двойная кавычка (34)>
НТТР/1.1 определяет последовательность CR LF, как маркер
конца для всех протокольных элементов, за исключением тела эле-
мента. Маркер конца строки в пределах тела объекта определен
соответствующим типом среды.
. CRLF=CR LF
НТТР/1.1 заголовки могут занимать несколько строк, если про-
должение строки начинается с пробела или символа горизонталь-
ной табуляции. Все строчные пробелы имеют ту же семантику, что
и обычный пробел (SP).
LWS = [CRLF] 1*( SP | НТ )
Правило TEXT используется тдлько для содержимого описа-
тельных полей и значений, которые не предполагается передавать
интерпретатору сообщений. Слова *ТЕХТ могут содержать символы
Сети передачи данных. Метод доступа
867
из символьного набора, не совпадающего с ISO 8859-1 [22], только
когда они закодированы согласно правилам RFC 1522 [14].
TEXT = <любой OCTET за исключением CTL, но включая LWS>
В некоторых протокольных элементах используются шестнад-
цатеричные цифровые символы.
HEX = "А" | "В" | "С” | "D" | "Е" | "F" | "а" | ”b" | "с" | "d" | "е" |
"f" | DIGIT
Многие значения полей заголовков НТТР/1.1 состоят из слов,
разделенных LWS или специальными символами. Эти специальные
символы должны представлять собой строки, заключенные в кавыч-
ки, чтобы использоваться в качестве значения параметра.
Token = 1*<любой CHAR за исключением CTLs или tspecials>
Tspecials = "(” | ’’)’’ | ’’<’’ | ’’>’’ | "@”
| V II I "\" I <">
II т I „г I I ,.=„
| "{' I ”}" I SP I нт
Комментарии могут быть включены в некоторые поля HTTP
заголовков, при этом текст комментария заключается в скобки.
Комментарии допустимы только для полей, содержащих ’’comment",
как часть описания поля. В других полях скобки рассматриваются
как элемент содержимого поля.
Комментарий = ’’(’’ *( ctext | комментарий) ’’)’’
ctext = <любой TEXT, исключая ’’(" и ’’)’’>
Строка текста воспринимается как одно слово, если она помеще-
на в двойные кавычки.
quoted-string =(<’’> *(qdtext) <’’> )
qdtext = <любой TEXT, исключая <”»
Символ обратная косая черта ("\”) может использоваться вмес-
то кавычки внутри закавыченного текста или в структурах коммен-
тариев.
quoted-pair = ”\” CHAR
28*
868 Глава 4
4.5.5.1.2. Параметры протокола
2.1. Версия HTTP
HTTP использует схему нумерации "<major>.<minor>" для ото-
бражения версии протокола. Политика присвоения версии протоко-
лу ориентирована на то, чтобы позволить отправителю указать фор-
мат сообщения и его емкость. Номер версии не меняется при добав-
лении компонент сообщения, которые не влияют на характер обмена.
Число <minor> увеличивается, когда в протокол внесены изме-
нения, которые не изменили общий алгоритм разбора сообщений,
но которые изменили семантику сообщений и добавили новые воз-
можности отправителю. Число <major> увеличивается в случае,
когда изменен формат протокольного сообщения.
Версия HTTP-сообщения указывается в поле HTTP-Version в
первой строке сообщения.
HTTP Version = ’’HTTP” ”/” 1*DIGIT 1*DIGIT
Заметьте, что числа major и minor должны рассматриваться как
независимые целые, так что каждое из них может быть увеличено
за пределы одной цифры. Таким образом, НТТР/2.4 является более
низкой версией, чем НТТР/2.13, которая в свою очередь ниже, чем
HTTP/12.3. Начальные нули должны игнорироваться и не пересы-
латься.
Приложения, посылающие запросы или отклики, так как это
определено в спецификации, должны включать HTTP-Version ’’HTTP/
1.1”. Использование этого номера версии указывает, что посылаю-
щее приложение совместимо с этой спецификацией.
Версия HTTP приложения является верхней, совместимость с
которой гарантируется. Приложения прокси-серверов и сетевых пор-
* тов должны проявлять осторожность при переадресации сообщений
с протокольной версией, отличной от поддерживаемой ими. Так как
версия протокола указывает на возможности отправителя, прокси
никогда не должны пересылать сообщения с версией больше, чем
их собственная; если получено сообщение более высокой версии,
прокси/порт должен либо понизить версию запроса, либо послать
отклик об ошибке или переключиться в режим туннеля. Запросы с
версией ниже, чем у прокси/порта могут быть повышены при пере-
адресации, при этом major часть версии сервера и запроса должны
совпадать.
Замечание: Преобразование между версиями может включать
модификацию полей заголовка.
Сети передачи данных. Метод доступа
869
2.2. Универсальные идентификаторы ресурсов (URI)
URI известен под многими именами: WWW адрес, универсаль-
ный идентификатор документа (Universal Document Identifiers), уни-
версальный идентификатор ресурса (Universal Resource Identifiers),
универсальный локатор ресурса URL (Uniform Resource Locators) и,
наконец, универсальное имя ресурса (URN). Что касается HTTP,
универсальный идентификатор ресурса представляет собой форма-
тированную строку символов, которая идентифицирует имя, поло-
жение или какие-то еще характеристики ресурса.
2.2.1. Общий синтаксис
URI в HTTP может быть представлен в абсолютной или относи-
тельной форме по отношению к некоторому известному базовому
URI, в зависимости от контекста его использования. Эти две формы
отличаются тем, что абсолютный URI всегда начинается с имени
схемы, за которым следует двоеточие (например, HTTP: или FTP:).
URI = ( absoluteURI | relativeURI) [ "#” фрагмент ]
AbsoluteURI = схема *( uchar | reserved )
RelativeURI = net_path | abs_path | rel_path
net_path = net loc [ abs_path ]
absjpath = rel_path
rel_path= [ проход ] [ ” params ] [ ”?” query ]
path = fsegment *( ” Г сегмент )
fsegment « l*pchar
segment = *pchar
params = param *( param )
param = *( pchar | ” /" )
scheme = 1*( ALPHA | DIGIT | | | )
net_loc = *( pchar | | ”?” )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
pchar = uchar | | "@” | | "=” |
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national
escape = "% ’’ HEX HEX
reserved= | I I | | | "=” |
extra = | | | "(” | ")" |
safe = I I I
unsafe = CTL | SP | <’’> | "#" | "%" | | ">”
national = <любой OCTET, исключая ALPHA, DIGIT, зарезервиро-
ванный, extra, safe, и unsafe>
870
Гпава 4
Более детальную информацию о синтаксисе и семантике URL
можно найти в RFC 1738 [4] и RFC 1808 [11]. Приведенные выше
BNF включают в себя национальные символы, недопустимые в URL,
так как это специфицировано в RFC 1738, так как серверам HTTP
не запрещено использование любых наборов символов, допустимых
в rel_path частях адресов, HTTP-прокси могут получить запросы
URI, не определенные в рамках RFC 1738.
Протокол HTTP не устанавливает каких-либо ограничений на
длину URL Серверы должны быть способны обрабатывать URI лю-
бых ресурсов, имеющих любую длину. Сервер должен выдать от-
клик 414 (Request-URI Too Long - URI запроса слишком длинен),
если URI длиннее, чем может обработать сервер (см. раздел 9.4.15).
Замечание: Серверы должны избегать использования URI длин-
нее 255 байт, так как некоторые старые клиенты или прокси-при-
ложения не могут корректно работать с такими длинами.
2.2.2. HTTP URL
Схема "HTTP" используется для локализации сетевых ресурсов
с помощью протокола HTTP. Далее определены синтаксис и семан-
тика HTTP URL, зависящие от схемы.
http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
host = <Легальное имя ЭВМ в Интернет или IP-адрес (в точечно-
цифровой форме), как это определено в разделе 2.1 RFC 1123>
port = *DIGIT
Если номер порта не указан, предполагается порт 80. Семантика
устроена так, что идентифицированный ресурс размещается на сер-
вере, который ожидает TCP-соединения через порт данной ЭВМ, а
Request-URI для ресурса находится в abs path. Использование IP
адресов в URL следует избегать всюду, гдё это возможно (см. RFC
1900 [24]). Если abs_path в URL отсутствует, он должен считаться
равным "/", в случае, если он используется в качестве Request-URI
для ресурса (раздел 4.1.2).
2.2.3. Сравнение URI
При сравнении двух URI с целью проверки их идентичности,
клиент должен использовать по октетное сравнение с учетом регис-
тра, в котором напечатаны символы. Допускаются следующие ис-
ключения:
• Номер порта не указан, тогда для данного URI берется значе-
ние по умолчанию;
Сети передачи данных. Метод доступа
871
• Сравнение имен ЭВМ или схем не должно быть чувствитель-
ным к строчным/прописным буквам.
• Пустой abs_path эквивалентен abs_path ’’/’’.
Символы, отличные от типов ’’reserved" и "unsafe” устанавлива-
ются равными их эквивалентам в кодировке ""%" HEX HEX".
Например, следующие три URI являются эквивалентными:
http://abc.com:80/~smith/home.html
http://ABC.com/% 7Esmith/home.html
http: / / АВС. com: / % 7esmi th/ home. h tml
3.3. Форматы даты/времени
3.3.1. Полная дата
HTTP приложения допускают три различных формата для пред-
ставления метки времени и даты:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, актуализировано в
RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, объявлено устарев-
шим в RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C’s asctime() format
Первый формат предпочтительнее, как стандарт Интернет и пред-
ставляет собой форму фиксированной длины, определенную RFC 1123.
Второй формат используется достаточно широко, но базируется на
устаревшем документе RFC 850 [12], формат даты не имеет 4 цифр
года. Клиенты и серверы НТТР/1.1, которые анализируют дату, дол-
жны уметь работать со всеми тремя форматами (для совместимости
с НТТР/1.0), хотя они должны сами генерировать время/дату со-
гласно формату RFC 1123.
Замечание: Получатели значений даты должны быть готовы
принять коды, которые посланы не приложениями HTTP, что случа-
ется, когда данные поступают через прокси/порты или по почте в
SMTP- или NNTP-форматах.
Все марки времени/даты HTTP должны соответствовать време-
ни по Гринвичу (GMT). Это указано в первых двух форматах путем
включения строки "GMT" и должно предполагаться во всех прочих
случаях.
HTTP-date
rfcll23-date
rfc850-date
asctime-date
= rfcll23-date | rfc850-date | asctime-date
= wkday SP datel SP time SP "GMT"
= weekday SP date2 SP time SP "GMT"
= wkday SP date3 SP time SP 4DIGIT
872
Гпава 4
datel = 2DIGIT SP month SP 4DIGIT
; день месяц год (напр., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; день-месяц-год (напр., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; месяц день (напр., Jun 2)
time = 2DIGIT 2DIGIT ":" 2DIGIT
; 00:00:00 — 23:59:59
wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri” | "Sat” | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday" | "Thursday" |
"Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | "Jul" |
"Aug" | "Sep" | "Oct" | "Nov" | "Dec"
Замечание: HTTP требования для формата метки даты/времени
применимы только для использования в рамках реализации самого
протокола. Клиенты и серверы не требуют применения этих форматов
для пользовательских презентаций, протоколирования запросов и т.д.
2.3.2. Интервалы времени в секундах
Некоторые поля заголовка HTTP допускают спецификацию зна-
чения времени в виде целого числа секунд, представленного в деся-
тичной форме и равного времени с момента получения сообщения.
delta-seconds = 1*DIGIT
2.4. Наборы символов
HTTP использует то же определение термина "набор символов",
что дано для MIME.
Термин "набор символов", используемый в данном разделе, от-
носится к методу, который с помощью одной или более таблиц пре-
образует последовательность октетов в последовательность симво-
лов. Заметьте, что не требуется безусловное обратное преобразова-
ние, при этом не все символы могут быть доступны и одному и тому
же символу может соответствовать более чем одна последователь-
ность октетов. Это определение имеет целью допустить различные
виды кодировок символов, от простых однотабличных, таких как
US-ASCII, до сложных — таблично переключаемых методов, исполь-
зуемых, например, в ISO 2022. Однако, определение, связанное с на-
бором символов MIME, должно полностью специфицировать схему
соответствия октетов и символов. Использование внешних профай-
лов для определения схемы шифрования не допустимо.
Сети передачи данных. Метод доступа 873
Наборы символов HTTP идентифицируются лексемами, которые не
чувствительны к использованию строчных или прописных букв. Пол-
ный набор лексем определен регистром наборов символов IANA,[19].
charset = token
Несмотря на то, что HTTP позволяет использовать произволь-
ную лексему в качестве значения charset, любая лексема, значение
которой определено в рамках регистра набора символов IANA, дол-
жна представлять символьный набор, определенный этим регист-
ром. Приложение должно ограничить использование символьных
наборов только теми, которые определены регистром IANA.
2.5. Кодировки содержимого
Значения кодировки содержимого указывают на кодовое преоб-
разование, которое было или может быть выполнено над объектом.
Кодировки содержимого первоначально применены для того, чтобы
иметь возможность архивировать документ или преобразовать его
каким-то другим способом без потери идентичности или информа-
ции. Часто объект запоминается закодированным, передается и только
получателем декодируется.
content-coding = token
Все значения кодировок содержимого не зависят от того, исполь-
зуются строчные или прописные символы. НТТР/1.1 использует
значения кодировок содержимого в полях заголовка Accept-Encoding
(раздел 13.3) и Content-Encoding (раздел 13.12). Хотя значение
описывает кодирование содержимого, более важным является то,
что оно определяет механизм декодирования.
Комитет по стандартным числам Интернет IANA (Internet
Assigned Numbers Authority) выполняет функции регистра для зна-
чений лексем кодирования содержимого, этот регистр хранит следу-
ющие лексемы:
gzip
Формат кодирования, реализуемый программой архивации фай-
лов "gzip” (GNU zip),как описано в RFC 1952 [25]. Этот формат
соответствует кодированию Lempel-Ziv (LZ77) с 32 битным CRC.
compress
Формат кодирования, реализуемый стандартной программой UNIX
для архивации файлов "compress*’. Этот формат соответствует адап-
тивному методу кодирования Lempel-Ziv-Welch (LZW).
874
Гпава 4
Замечание: Использование имен программ для идентификации
форматов кодирования не является желательным и будет в буду-
щем заменено. Их использование здесь является следствием исто-
рической практики. Для совместимости с предшествующими реали-
зациями HTTP,приложения должны считать "x-gzip" и "x-compress"
эквивалентными "gzip" и ’’compress" соответственно.
deflate
Формат "zlib" определен документом RFC 1950 [31] в комбина-
ции с механизмом сжатия "deflate", описанным в RFC 1951 [29].
Новые значения лексем кодирования содержимого должны ре-
гистрироваться. Для обеспечения взаимодействия между клиента-
ми и серверами спецификации алгоритмов кодирования содержимо-
го должны быть общедоступны.
2.6. Транспортное кодирование
Значения транспортного кодирования используются для опреде-
ления кодового преобразования, может быть подвергнут объект для
того, чтобы гарантировать безопасную его транспортировку через
сеть. Этот вид преобразования отличен от кодирования содержимо-
го, так как относится к сообщению, а не исходному объекту.
Transfer-coding = "chunked" | transfer-extension
Transfer-extension = token
Все значения транспортного кодирования не зависят от того,
строчные или прописные буквы здесь использованы HTTP/1.1 за-
писывает значения транспортного кодирования в поле заголовка
Transfer-Encoding (раздел 13.40).
Транспортные кодировки аналогичны используемым значени-
ям Content-Transfer-Encoding MIME, которые были введены для
обеспечения безопасной передачи двоичных данных через 7-битную
транспортную среду. Однако безопасная транспортировка имеет дру-
гие аспекты в рамках 8-битного протокола передачи сообщений. В
HTTP, единственной небезопасной характеристикой тела сообще-
ния является неопределенность его длины (раздел 6.2.2), или жела-
ние зашифровать данные при передаче по общему каналу.
Блочное кодирование фрагментов модифицирует тело сообще-
ния для того, чтобы передать его в виде последовательности паке-
тов, каждый со своим индикатором размера, за которым следует
опционная завершающая запись (footer), содержащая поля заголов-
ка объекта. Это позволяет передать динамически сформированное
Сети передачи данных. Метод доступа
875
содержимое, снабдив его необходимой информацией для получателя,
который, в конце концов, сможет восстановить все сообщение.
Chunked-Body = *chunk (блок данных)
”0" CRLF
footer
CRLF
Chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF
Hex-no-zero
Chunk-size
Chunk-ext
= <НЕХ excluding "0”>
= hex-no-zero *НЕХ
= *( ”chunk-ext-name [ "=” chunk-ext-value ] )
Chunk-ext-name = token
Chunk-ext-val = token | quoted-string
Chunk-data = chunk-size(OCTET)
footer = *entity-header
Кодирование фрагментов завершается пакетом нулевой длины,
за которым следует завершающая запись и пустая строка. Назна-
чение завершающей записи заключается в том, чтобы дать инфор-
мацию о динамически сформированном объекте. Приложения не
должны пересылать поля заголовка в завершающей записи, кроме
тех, которые специально оговорены, например, такие как Content-
MD5 или будущие расширения HTTP для цифровой подписи. При-
мер процесса такого кодирования представлен в разделе 15.4.6.
Все приложения НТТР/1.1 должны быть способны получать и
декодировать приходящие фрагменты (блочное кодирование), и дол-
жны игнорировать расширения транспортного кодирования, кото-
рые они не понимают. Сервер, получающий тело объекта с транс-
портной кодировкой, которую он не понимает, должен отослать от-
клик с кодом 501 (Unimplemented - не применимо), и закрыть
соединение. Сервер не должен использовать транспортное кодиро-
вание при посылке данных клиенту HTTP/1.0.
2.7. Типы среды
HTTP использует типы среды Интернет (Internet Media Types) в
полях заголовка Content-Type (раздел 13.18) и Accept (раздел 13.1)
Для того, чтобы обеспечить широкий и открытый обмен с самыми
разными типа среды.
Media-type = type ”/” subtype *( parameter )
type = token
subtype = token •
876
Гпава 4
Параметры могут следовать за type/subtype в форме пар атри-
бут/значение.
Parameter = attribute "=" value
attribute = token
value = token | quoted-string
Имена типа, субтипа и атрибутов параметра могут набираться,
как строчными, так и прописными буквами. Значения параметров
могут быть и чувствительны к используемому регистру, в зависимо-
сти от семантики и имени параметра. Строчный пробел (LWS) не
должен использоваться ни между типом и субтипом, ни между ат-
рибутом и значением. Агенты пользователя, которые распознают
тип среды, должны обрабатывать параметры для типа MIME так,
как это описано для данного типа/субтипа, и информировать
пользователя о любых возникающих проблемах.
Замечание: некоторые старые приложения HTTP не узнают па-
раметры типа среды. При посылке данных старому НТТР-приложе-
нию, программы должны использовать параметры типа среды, толь-
ко когда они необходимы по описанию типа/субтипа. Значения
типа среды регистрируются IANA (Internet Assigned Number
Authority). Процесс регистрации типа среды описан в RFC 2048
[17]. Использование незарегистрированных типов среды настоятельно
не рекомендуется.
2.7.1. Канонизация и текст по умолчанию
Типы среды Интернет регистрируются каноническим образом.
Вообще, тело объекта, передаваемого с помощью HTTP сообщений,
должно быть представлено соответствующим каноническим спосо-
бом, прежде чем будет послано. Исключение составляет тип "text",
как это описано в следующем параграфе.
В случае канонической формы субтип среды "text" использует
CRLF для завершения строки. HTTP ослабляет это требование и
позволяет передавать текст, используя просто CR или LF, представ-
ляющие разрыв строки. HTTP приложения должны воспринимать
CRLF, "голое" CR и LF как завершение строки для текстовой среды
полученной через HTTP. Кроме того, если текст представлен в сим-
вольном наборе, где нет октетов 13 и 10 для CR и LF соответствен-
но, как это имеет место в случае мультибайтных символьных набо-
ров, HTTP позволяет использовать соответствующие символьные
представления для CR и LF. Эта гибкость в отношении разрыва
строк относится только к текстовой среде в теле объекта; CR или
(jeTn передачи данных. Метод доступа
877
LF не должны подставляться вместо CRLF в любые управляющие
структуры HTTP (такие как поля заголовка).
Если тело объекта закодировано с помощью Content-Encoding,
исходные данные, прежде чем подвергнуться кодированию должны
были иметь форму, указанную выше.
Параметр ’’charset” используется с некоторыми типами среды,
чтобы определить символьный набор (раздел 2.4). Когда параметр
charset не задан отправителем явно, субтип среды "text” определя-
ется так, что используется символьный набор по умолчанию ’’ISO-
8859-1”. Данные с набором символов, отличным от "ISO-8859-1"
или его субнабора, должны помечаться соответствующим значени-
ем charset.
Некоторые программы HTTP/1.0 интерпретируют заголовок
Content-Type без параметра charset, неправильно предполагая, что
получатель должен решить сам, какой это набор. Отправители, же-
лающие заблокировать такое поведение, могут включать пара-
метр charset, даже когда charset равен ISO-8859-1 и должны делать
так, что бы это не запутало получателя.
К сожалению, некоторые старые НТТР/1.0 клиенты не обраба-
тывают корректно параметр charset. HTTP/1.1 получатели должны
учитывать метку charset, присланную отправителем, и те агенты
пользователя, которые умеют работать с разными символьными на-
борами, должны использовать символьный набор из поля content-
type, если они поддерживают этот набор, а не набор, предпочитаемый
получателем.
2.7.2. Составные типы
MIME обеспечивает нескольких составных типов - инкапсуля-
ция одного или более объектов в общее тело сообщения. Все состав-
ные типы имеют общий синтаксис, как это определено в MIME [7], и
должны включать граничный параметр, являющийся частью значе-
ния типа среды. Тело сообщения является само протокольным эле-
ментом и, следовательно, должно использовать только CRLF для
обозначения разрывов строки. В отличие от MIME, завершающая
часть любого составного сообщения должна быть пустой. HTTP
приложения не должны передавать завершающую часть (даже если
исходное составное сообщение содержит такую завершающую часть
(эпилог-подпись)).
В HTTP, составляющие части тела могут содержать поля заго-
ловка, которые существенны для значения этих частей. Рекоменду-
ется, чтобы поле заголовка Content-Location (раздел 13.15 данной
878
Гпава 4
главы) было включено в часть тела каждого вложенного объекта,
который может быть идентифицирован URL.
Вообще, рекомендуется, чтобы агент пользователя HTTP имел
идентичное или схожее поведение с агентом пользователя MIME
при получении составного типа. Если приложение получает неузна-
ваемый составной субтип, оно должно обрабатывать его также как
"multi part/mixed".
Замечание: Тип "multipart/form-data" специально определен для
переноса данных совместимого с методом обработки почтовых зап-
росов, как это описано в RFC 1867 [15].
2.8. Лексемы продукта
Лексемы продукта служат для того, чтобы позволить взаимодей-
ствующим приложениям идентифицировать себя с помощью имени
и версии программного продукта. Большинство полей, использую-
щих лексемы продукта допускают также включение в список субпро-
дуктов, которые образуют существенную часть приложения, их лексе-
мы отделяются пробелом. По договоренности, продукты перечисля-
ются в порядке их важности для идентификации приложения.
Product = token ["/" product-version]
Product-version = token
Примеры:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
Лексемы продукта должны быть короткими и, кроме того, ис-
пользование их для оповещения или передачи маловажной инфор-
мации абсолютно запрещено. Хотя любой символ лексемы может
присутствовать в версии продукта, рекомендуется, чтобы эта лексе-
ма использовалась только для идентификации версии (то есть, пос-
ледовательные версии одного и того же продукта должны отличать-
ся только в части версии продукта).
2.9. Значения качества (Quality values)
HTTP согласование параметров содержимого (раздел 12) исполь-
зует короткие числа с плавающей запятой для указания относи-
тельной важности (веса) различных согласуемых параметров. Вес
нормализуется на истинное число в интервале 0 — 1, где 0 равен
минимальному, а 1‘максимальному значению. Приложения HTTP/
1.1 не должны генерировать более трех чисел после запятой. Реко-
Сети передачи, данных. Метод доступа
879
мендуется, чтобы конфигурация пользователя для этих значений
удовлетворяла тем же ограничениям.
qvalue = ( ”0” [ 0*3DIGIT ] ) | ( ”1” [ О*3(’’О'’) ] )
’’Quality values” (значения качества) является неверным назва-
нием, так как эти значения в большей степени отражают относи-
тельную деградацию желательного качества.
2.10. Языковые метки
Языковая метка идентифицирует естественный язык. Компью-
терные языки в этот перечень не входят. HTTP использует языко-
вые метки в полях Accept-Language и Content-Language.
Синтаксис и регистр языковых меток HTTP тот же, что и опре-
деленный в RFC 1766 [1]. Языковая метка содержит одну или бо-
лее частей: первичная языковая метка и последовательность субме-
ток, которая может и отсутствовать:
language-tag = primary-tag *( sub-tag )
primary-tag = 1*8ALPHA
sub-tag = 1*8ALPHA
Пробел не допустим в метке, применение строчных или пропис-
ных букв не играет никакой роли. Перечень языковых меток конт-
ролируется IANA. Ниже приведены примеры языковых меток:
en, en-US, en-cockney, i-cherokee, x-pig-latin
где любые две буквы первичной метки представляют собой языко-
вую аббревиатуру ISO 639 и две буквы исходной субметки соответ-
ствуют коду страны ISO 3166 (последние три метки не являются
зарегистрированными; все кроме последней могут быть зарегистри-
рованы в будущем).
2.11. Метки объектов
Метки объектов служат для сравнения двух или более объектов
из одного и того же запрошенного ресурса. НТТР/1.1 использует
метки объектов в полях заголовков ETag (раздел 13.20), If-Match
(раздел 13.25), If-None-Match (раздел 13.26) и If-Range (раздел
13.27). Метки объекта состоят из строк, заключенных в кавычки,
перед ней может размещаться индикатор слабости.
entity-tag = [ weak ] opaque-tag
Weak = ”W/”
opaque-tag = quoted-string
880
Гпава 4
Сильная метка объекта (strong entity tag) может принадле-
жать двум объектам ресурса, если они эквивалентны на октетном
уровне.
Слабая метка объекта (weak entity tag) отмечается префиксом
"W/", может относиться к двум объектам ресурса, только если объек-
ты эквивалентны и могут быть взаимозаменяемы. Слабая метка
объекта может использоваться для "слабого” сравнения.
Метка объекта должна быть уникальной для всех версий всех
объектов, сопряженных с конкретным ресурсом. Значение данной
метки объекта может использоваться для объектов, полученных в
результате запросов для различных URI без использования данных
об эквивалентности этих объектов.
2.12. Структурные единицы
HTTP/1.1 позволяет клиенту запросить только часть объекта
(диапазон). НТТР/1.1 использует структурные единицы, определя-
ющие выделение части объекта, в полях заголовка Range (раздел
13.36) и Content-Range (раздел 13.17). Объект может быть разбит
на фрагменты с использованием различных структурных единиц.
range-unit = bytesunit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
Единственной структурной единицей, определенной в НТТР/1.1,
является "bytes". НТТР/1.1 реализации могут игнорировать диа-
пазоны, специфицированные с использованием других структурных
единиц. НТТР/1.1 сконструирован так, чтобы допустить реализа-
ции приложений, которые не зависят от знания диапазонов.
4.5.5.1.3. HTTP сообщение
3.1. Типы сообщений
Сообщения HTTP включают в себя запросы клиента к серверу и
отклики сервера клиенту.
HTTP-message = Request | Response; НТТР/1.1 messages
Сообщения запрос (раздел 5) и отклик (раздел 6) используют
общий формат RFC 822 [9] для передачи объектов (поле данных
сообщения). Оба типа сообщений состоят из стартовой строки, од-
ного или более полей заголовка (также известные как "заголовки"),
пустой строки (то есть, строка, содержащая CRLF), отмечающей ко-
нец полей заголовка, а также опционного тела сообщения.
Сети передачи данных. Метод доступа
881
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
В интересах надежности, рекомендуется серверам игнорировать
любые пустые строки, полученные, когда ожидается Request-Line (стро-
ка запроса). Другими словами, если сервер читает протокольный
поток в начале сообщения и получает сначала CRLF, он должен
игнорировать CRLF.
Замечание: Определенные не корректные реализации НТТР/1.0
клиентов генерируют дополнительные CRLF после запроса POST.
Клиент НТТР/1.1 не должен посылать CRLF до или после запроса.
3.2. Заголовки сообщений
Поля заголовка HTTP, которые включают в себя поля общего
заголовка (раздел 3.5), заголовка запроса (раздел 4.3), заголовка
отклика (раздел 6.2), и заголовка объекта (раздел 6.1), следуют
тому же общему формату, что дан в разделе 3.1 RFC 822 [9]. Каж-
дое поле заголовка состоит из имени, за которым следует двоеточие
(”:’’) и поля значения. Поля имен безразличны в отношении ис-
пользования строчных и прописных букв. Поле значения может
начинаться с любого числа LWS, хотя один SP предпочтительнее.
Поля заголовка могут занимать несколько строк, каждая новая стро-
ка должна открываться, по крайней мере, одним SP или НТ. Реко-
мендуется, чтобы приложения следовали общему формату, если они
создаются конструкциями HTTP, так как могут существовать неко-
торые реализации, которые не могут воспринимать ничего кроме
общих форматов.
Message-header
field-name
field-value
field-content
= field-name [ field-value ] CRLF
= token
= *( field-content | LWS )
= < OCTET’ы образуют значения поля и
состоят из *ТЕХТ или комбинаций лексем,
tspecials и закавыченных строк >
Порядок, в котором приходят поля заголовка с отличающими-
ся именами, не играет значения. Однако хорошей практикой счи-
тается посылка сначала поля общего заголовка, за которым сле-
дует заголовок запроса или отклика, а в заключение — поля заго-
ловка объекта.
882
Гпава 4
Множественные поля заголовка сообщения с идентичными име-
нами могут присутствовать тогда и только тогда, когда значение
поля определяется как список из элементов, разделенных запятыми
[то есть, #(значения)]. Должна быть предусмотрена возможность
объединять множественные поля заголовка в одну пару ”имя_по-
ля: значение_поля”, без изменения семантики сообщения, путем
последовательного добавления пар поле-значение, отделенных друг
от друга запятыми. Порядок, в котором следуют поля заголовка с
идентичными именами, влияет на последующую интерпретацию зна-
чения комбинированного поля, по этой причине прокси-сервер не
должен менять порядок значений этих полей при переадресации
сообщения.
3.3. Тело сообщения
Тело сообщения HTTP (если имеется) используется для перено-
са тела объекта, сопряженного с запросом или откликом. Тело со-
общения отличается от тела объекта, только когда используется
транспортное кодирование, как это указано в поле заголовка
Transfer-Encoding (раздел 13.40).
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
Transfer-Encoding должно использоваться для указания любо-
го транспортного кодирования, реализованного приложением с це-
лью гарантированной неискаженной доставки сообщения. Транс-
портное кодирование лежит в зоне ответственности сообщения, а не
объекта и по этой причине может быть реализовано любым прило-
жением в цепочке запрос/отклик.
Присутствие тела сообщения в запросе отмечается с помощью
включения полей заголовка Content-Length или Transfer-Encoding
в заголовки сообщений-запросов. Тело сообщения может быть вклю-
чено в запрос, только когда метод запроса допускает наличие тела
объекта (раздел 4.1.1).
Для сообщений-откликов включение в них тела сообщения за-
висит от метода запроса и статусного кода отклика (раздел 5.1.1).
Все отклики в случае метода запроса HEAD не должны содержать
тела сообщения, даже если присутствуют поля заголовка объекта,
позволяющие предположить его присутствие. Все отклики 1хх (ин-
формационные), 204 (никакого содержимого) и 304 (не модифици-
ровано) не должны включать тела сообщения. Все другие отклики
включают в себя тело сообщения, хотя оно может иметь и нулевую
длину.
Сети передачи данных. Метод доступа
883
3.4. Длина сообщения
Когда тело включено в сообщение, его длина определяется сле-
дующим образом (в порядке приоритета):
1. Любое сообщение-отклик, которое не должно включать в себя
тело сообщения (такое как отклик 1хх, 204 и 304, а также любые
отклики на запрос HEAD) всегда завершаются пустой строкой пос-
ле полей заголовка, вне зависимости от присутствующих в сообще-
нии полей заголовка объекта.
2. Если присутствует поле заголовка Transfer-Encoding (раздел
13.40) и указано, что использовано блочное (’’chunked") транспорт-
ное кодирование, тогда длина тела определяется выбранной схемой
кодирования (раздел 2.6).
З.Если присутствует поле заголовка Content-Length (раздел
13.14), его значение в байтах и определяет длину тела сообщения.
4. Если сообщение использует тип среды ’’multi part/byteranges’’,
который является самоограничивающим, тогда он и определяет длину.
Этот тип среды не должен использоваться, если отправитель не зна-
ет, может ли получатель разобрать его. Присутствие в запросе заго-
ловка Range с множественными спецификаторами диапазона подра-
зумевает, что клиент может разобрать отклики типа multipart/
byteranges.
5. Определяется сервером при закрытии связи. (Закрытие со-
единения не может использоваться для обозначения конца тела
запроса, так как это не оставит возможности для сервера послать
отклик.)
Для совместимости с приложениями НТТР/1.0, запросы НТТР/1.1,
содержащие тело, должны включать корректное поле заголовка
Content-Length. Если запрос содержит тело сообщения, а поле Content-
Length отсутствует, рекомендуется, чтобы сервер реагировал откли-
ком 400 (плохой запрос), если он не может определить длину сооб-
щения, или 411 (необходима длина), если он настаивает на получе-
нии корректного поля Content-Length.
Все приложения НТТР/1.1, которые получают объект должны
понимать блочное ("chunked") транспортное кодирование (раздел
2.6), таким образом, разрешая использование этого механизма для
сообщений, когда длина сообщения не может быть определена за-
ранее.
Сообщения не должны включать поле заголовка Content-Length
и блочное транспортное кодирование одновременно. Если такое со-
общение получено, поле Content-Length должно игнорироваться.
884
Гпава 4
Когда в сообщении присутствует поле Content-Length и разре-
шено наличие тела сообщения, его значение должно строго соответ-
ствовать числу октетов в теле сообщения. Агенты пользователя
НТТР/1.1 должны оповещать пользователя, если получено сообще-
ние некорректной длины.
3.5. Общие поля заголовка
Существует несколько полей заголовка, которые имеют приме-
нимость, как для запросов, так и откликов, но которые не использу-
ются для передачи объектов. Эти поля заголовков служат только
для сообщений.
general-header = Cache-Control ; Раздел 13.9
| Connection; Раздел 13.10
|Date ; Раздел 13.19
| Pragma ; Раздел 13.32
| Transfer-Encoding ; Раздел 13.40
| Upgrade ; Раздел 13.41
| Via ; Раздел 13.44
Список имен полей общего заголовка может быть расширен толь-
ко при изменении версии протокола. Однако новые или экспери-
ментальные поля заголовка могут использоваться при условии, если
партнеры обмена способны их распознавать, как поля общего заго-
ловка. Не узнанные поля заголовка считаются полями заголовка
объекта (entity).
4.5.5.1.4. Запрос
Сообщение-запрос от клиента к серверу включает в себя, в преде-
лах первой строки сообщения, метод, который должен быть исполь-
зован для ресурса, идентификатор ресурса и код версии используе-
мого протокола.
Request = Request-Line
*( generalheader | requestheader | entityheader )
CRLF
[ messagebody ]
4.1. Строка запроса
Строка запроса начинается с лексемы метода, за которой следует
идентификатор запрашиваемого ресурса (Request-URI) и версия про-
токола, завершается строка последовательностью CRLF. Элементы
разделяются символами SP. Символы CR или LF запрещены кроме
завершающей последовательности CRLF.
Сети передачи данных. Метод доступа
885
Request Line = Method SP Request-URI SP HTTP-Version CRLF
; Раздел 9.2
; Раздел 9.3
; Раздел 9.4
; Раздел 9.5
; Раздел 9.6
; Раздел 9.7
; Раздел 9.8
4.1.1. Метод
Лексема Method указывает на метод, который должен быть при-
менен к ресурсу, обозначенному Request-URI. При записи метода
использование строчных или прописных букв не безразлично.
Method = "OPTIONS" ;
|"GET" ;
I "HEAD" ;
|"POST" ;
j "PUT" ;
|"DELETE" ;
| "TRACE" ;
| extension-method
extension-method = token
Список методов допустимых для ресурса может быть специфи-
цирован полем заголовка Allow (раздел 13.7). Возвращаемый код
отклика всегда оповещает клиента, допустим ли метод для ресурса,
так как набор допустимых методов может меняться динамически.
Серверам рекомендуется возвращать статусный код 405 (Метод не
допустим), если метод известен серверу, но не приемлем для запра-
шиваемого ресурса и 501 (Не применим), если метод не узнан или не
приемлем для сервера. Список методов, известных серверу может
быть представлен в поле заголовка отклика Public (раздел 13.35).
Методы GET и HEAD должны поддерживаться всеми серверами
общего назначения. Все другие методы являются опционными. Од-
нако если применены вышеназванные методы, они должны быть
применены с той же семантикой, что специфицирована в разделе 8
данного раздела.
4.1.2. URI запроса
URI запроса является универсальным идентификатором ресур-
са (раздел 2.2) и идентифицирует ресурс, который запрашивается.
Request-URI = | absoluteURI | abs path
Три опции для Request-URI зависят от природы запроса. Звез-
дочка "*" означает, что запрос приложим не к заданному ресурсу, но
к самому серверу, и допустим только, когда используемый метод не
обязательно приложим к ресурсу. Примером может служить
OPTIONS * НТТР/1.1
886
Гпава 4
Форма абсолютного URI необходима, когда запрос адресован к
прокси-серверу. Прокси-серверу посылается запрос переадресации с
целью получения отклика. Заметьте, что прокси может переадресо-
вать запрос другому прокси или серверу, указанному абсолютным
URL Для того чтобы избежать петель запросов прокси-сервер дол-
жен быть способен распознавать все имена серверов, включая любые
псевдонимы, локальные вариации и численные IP-адреса. Пример
строки запроса представлен ниже:
GET http://www.w3.org/pub/WWW/TheProject.html НТТР/1.1
Для того чтобы разрешить передачу абсолютных URI в запросах
будущих версий HTTP, все серверы НТТР/1.1 должны уметь рабо-
тать с запросами абсолютных форм URI.
Наиболее общей формой Request-URI является та, которая ис-
пользуется для идентификации ресурса на исходном сервере или
внешнем порту сети. В этом случае абсолютный проход к URI
должен быть занесен в abs_path (см. раздел 2.2.1) как Request-URI,
а сетевой адрес URI (net_loc) должен быть занесен в поле заголовка
Host. Например, клйент, желающий извлечь ресурс из выше приве-
денного примера непосредственно с базового сервера, установит ТСР-
соединение через порт 80 с ЭВМ "www.w3.org" и пошлет строки:
GET /pub/WWW/TheProject.html НТТР/1.1
Host: www.w3.org,
за которыми следует остальная часть запроса. Заметьте, что абсо-
лютный проход не может быть пустым; если его нет в исходном
URI, он должен быть задан в виде "/" (корневой каталог сервера).
Если прокси получает запрос без какого-либо прохода в Request-
URI, а метод, специфицирован так, чтобы быть способным поддер-
живать форму запросов"*", тогда последний прокси в цепочке зап-
роса должен переадресовать запрос с в качестве финального
Request-URI. Например, запрос
OPTIONS http://www.ics.uci.edu:8001 НТТР/1.1
будет переадресован прокси как
OPTIONS * НТТР/1.1
Host: www.ics.uci.edu:8001
после подключения к порту 8001 ЭВМ "www.ics.uci.edu".
Request-URI передается в формате, описанном в разделе 3.2Д«
Исходный сервер должен декодировать Request-URI, для того чтобы
правильно интерпретировать запрос. Серверам рекомендуется от-
Сети передачи данных. Метод доступа
887
кликаться на некорректный запрос Request-URI соответствующим
статусным кодом.
В запросах, которые они переадресуют, прокси-серверы не долж-
ны переписывать ”abs_path” часть Request-URI каким-либо спосо-
бом, за исключением случая, описанного выше, когда нулевой abs_path
заменяется на
4.2. Ресурс, идентифицируемый запросом
Исходному серверу НТТР/1.1 рекомендуется заботиться о точ-
ном определении ресурса, идентифицированного Интернет-запросом
путем анализа Request-URI и поля заголовка Host.
Исходный сервер, который не разделяет ресурсы по запрашивае-
мой ЭВМ, может игнорировать значение поля заголовка Host. (См.
раздел 15.5.1 по поводу других требований по поддержке Host в
НТТР/1.1.)
Исходный сервер, который различает ресурсы с использованием
имени ЭВМ, должен использовать следующие правила для опреде-
ления ресурса в запросе НТТР/1.1:
1. Если Request-URI является absoluteURI, ЭВМ определена час-
тью Request-URI. Любое значение поля заголовка Host в запросе
должно игнорироваться.
2. Если Request-URI не является absoluteURI, а запрос содержит
поле заголовка Host, ЭВМ определяется значением поля этого заго-
ловка.
З.Если ЭВМ, так как это определено правилами 1 или 2, не
является ЭВМ сервера, откликом должно быть сообщение об ошиб-
ке с кодом 400 (Плохой запрос — Bad Request).
Получатели НТТР/1.0-запроса, где отсутствует поле заголовка
Host, могут попытаться использовать эвристику (напр., рассмотре-
ние прохода URI на предмет уникальной конкретной ЭВМ) для того,
чтобы определить, какой конкретный ресурс запрошен.
4.3. Поля заголовка запроса
Поля заголовка запроса позволяют клиенту передавать серверу
Дополнительную информацию о запросе и о самом клиенте. Эти
поля действуют как модификаторы запроса, с семантикой, соответ-
ствующей параметрам метода языка программирования.
Request-header
= Accept
| Accept-Charset
I Accept-Encoding
| Accept-Language
| Authorization
; Раздел 13.1
; Раздел 13.2
; Раздел 13.3
; Раздел 13.4
; Раздел 13.8
888
Гпава 4
| From ; Раздел 13.22
| Host ; Раздел 13.23
j If-Modified-Since ; Раздел 13.24
j If-Match ; Раздел 13.25
| If-None-Match ; Раздел 13.26
j If-Range ; Раздел 13.27
| If-Unmodified-Since ; Раздел 13.28
| Max-Forwards ; Раздел 13.31
| Proxy-Authorization ; Раздел 13.34
| Range ; Раздел 13.36
| Referer ; Раздел 13.37
| User-Agent ; Раздел 13.42
Поля имен заголовка запроса могут быть безопасно расширены
в сочетании с изменением версии протокола. Однако новым или
экспериментальным полям может быть придана семантика полей
заголовка запроса, если все участники обмена способны их распоз-
нать. Не узнанные поля заголовка рассматриваются как поля заго-
ловка объекта.
*
4.5. 5.1.5. Отклик
После получения и интерпретации сообщения-запроса, сервер
реагирует, посылая HTTP сообщение-отклик.
Response
= Status-Line
*( general-header
| response-header
| entity-header)
CRLF
[ message-body ]
; Раздел 5.1
; Раздел 3.5
; Раздел 5.2
; Раздел 6.1
; Раздел 6.2
5.1. Статусная строка
Первая строка сообщения-отклика является статусной строкой,
состоящей из кода версии протокола, за которым следует числовой
статусный код и его текстовое представление, все элементы разделя-
ются символами SP (пробел). Никакие CR или LF не допустимы, за
исключением завершающей последовательности CRLF.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
5.1.1. Статусный код и словесный комментарий
Элемент Status-Code представляет собой 3-значный цифровой
результирующий код попытки понять и исполнить запрос. Эти коды
полностью определены в разделе 9. Словесный комментарий (Reason*
Сети передачи данных. Метод доступа
88В
phrase) предназначен для того, чтобы дать краткое описание статус-
ного кода. Статусный код служит для использования автоматами, а
словесный комментарий для пользователей. Клиент не обязан рас-
сматривать или отображать словесный комментарий.
Первая цифра статусного кода определяет класс отклика. Пос-
ледние две цифры’ не имеют четко определенной функции. Суще-
ствует 5 значений первой цифры:
• 1хх Информационный - Цапрос получен, процесс продолжается
• 2хх Успех (Success) - Запрос успешно получен, понят и воспри-
нят
• Зхх Переадресация (Redirection) - Нужны дополнительные
действия для завершения выполнения запроса
• 4хх Ошибка клиента (Client Error) - Запрос содержит синтак-
сическую ошибку или не может быть выполнен
• 5хх Ошибка сервера (Server Error) - Сервер не смог выполнить
корректный запрос
Индивидуальные значения числовых статусных кодов определе-
ны в НТТР/1.1, а набор примеров, соответствующих причинам, пред-
ставлен ниже. Комментарии причин, предлагаемые здесь, являются
лишь рекомендательными - они могут быть заменены местными
аналогами без последствий для протокола.
Status-Code = "100" | "101" ; Continue (продолжить) ; Switching Protocols (переключающие протоколы)
| "200" | ”201" | "202". | "203" | "204" | "205" | "206" | "300" ; ОК ; Created (создано) ; Accepted (принято) ; Non-Authoritative Information ; No Content (содержимого нет) ; Reset Content (сбросить содержимое) ; Partial Content (часть содержимого) ; Multi pie Choices (множественный выбор)
| "301" ; Moved Permanently (перемещенпостоянно)
| "302" ; Moved Temporarily (временно перемещен)
| "303" | "304" | "305" ; See Other (смотри другие) ; Not Modified (не модифицирован) ; Use Proxy (использовать прокси)
890
Гпава 4
|"400" ; Bad Request (плохой запрос)
| "401" ; Unauthorized (неавторизовано)
| "402" ; Payment Required ♦
(необходима оплата)
| "403" ; Forbidden (запрощенр)
| ”404" ; Not Found (не найдено)
| "405" ; Method Not Allowed
(метод н^ допустим)
| "406" ; Not Acceptable (не приемлемо)
| "407" ; Proxy Authentication Required
| "408" ; Request Time-out (таймаут запроса)
| "409" ; Conflict (конфликт)
| "410" ; Gone (утрачен)
| "411" ; Length Required(нeoбxoдимa длина)
| ”412" ; Precondition Failed (предварительные
условия не выполнены)
| "413" ; Request Entity Too Large (объект
запроса слишком велик)
| "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type
(не поддерживаемый тип среды)
| "500" ; Internal Server Error
(внутренняя ошибка)
| "501" ; Not Implemented (не применимо)
| "502" ; Bad Gateway (плохой шлюз)
| "503” ; Service Unavailable
(услуга не доступна)
| "504” ; Gateway Time-out (таймаут шлюза)
| "505" ; HTTP Version not supported
(версия не поддерживается)
| extension-code
Extension-code == 3DIGIT (код из трех цифр)
Reason-Phrase = *<ТЕХТ, excluding CR, LF> (текстовый
комментарий)
Статусные коды HTTP допускают расширение. HTTP приложе-
ния могут не понимать значения всех зарегистрированных статус-
ных кодов, хотя их понимание, очевидно, является желательным.
Однако приложения должны понимать класс любого статусного кода»
который задается его первой цифрой, и воспринимать не узнанный
отклик как хОО. Не узнанный статусный отклик не должен заног
Сети передачи данных. Метод доступа
891
ситься в буфер. Например, если клиентом получен не распознавае-
мый статусный код 431, он может предположить, что произошло
что-то с запросом и рассматривать отклик так, как если бы он
равнялся 400. В таких случаях агентам пользователя рекоменду-
ется предоставлять пользователю объект с откликом, который со-
держит текст, поясняющий причину создавшейся ситуации.
5.2. Поля заголовка отклика
Поля заголовка отклика позволяют серверу передавать допол-
нительную информацию об отклике, который не может быть поме-
щен в статусную строку. Эти поля заголовка дают информацию о
сервере и доступе к ресурсу, идентифицированному Request-URI.
Response-header = Age ; Раздел 13.6
| Location ; Раздел 13.30
| Proxy-Authenticate ; Раздел 13.33
| Public ; Раздел 13.35
| Retry-After ; Раздел 13.38
| Server ; Раздел 13.39
I Vary ; Раздел 13.43
| Warning ; Раздел 13.45
I WWW-Authenticate ; Раздел 13.46
Имена полей заголовка отклика могут быть расширены только
в случае изменения версии протокола. Однако новые или экспери-
ментальные поля могут быть введены с учетом семантики полей
заголовка отклика, если все участники обмена способны распозна-
вать эти поля. Не узнанные поля заголовка рассматриваются, как
поля заголовка объекта.
4.5. 5.1.6. Объект
Сообщения запрос и отклик могут нести в себе объект, если это
не запрещено методом запроса или статусным кодом отклика.
Объект состоит из полей заголовка и тела объекта, хотя некоторые
отклики включают в себя только заголовки объектов. В данном
Разделе, как отправитель, так и получатель соотносятся к клиенту
или серверу, в зависимости от того, кто отправляет и кто получает
объект.
6.1. Поля заголовка объекта
Поля заголовка объекта определяют опционную метаинформа-
Дию о теле объекта или, если тело отсутствует, о ресурсе, идентифи-
цированном в запросе.
892
Гпава 4
Entity-header = Allow ; Раздел 13.7
| Content-Base ; Раздел 13.11
Entity-header | Content- ; Раздел 13.12
Entity-header | Content-Language ; Раздел 13.13
Entity-header | Content-Length ; Раздел 13.14
Entity-header | Content-Location ; Раздел 13.15
Entity-header j Content-MD5 ; Раздел 13.16
Entity-header | Content-Range ; Раздел 13.17
Entity-header | Content-Type ; Раздел 13.18
Entity-header 1 Etag ; Раздел 13.20
Entity-header | Expires ; Раздел 13.21
Entity-header | Last-Modified ; Раздел 13.29
Entity-header | extension-header
extension-header == message-header (заголовок сообщения)
Механизм расширения заголовка позволяет определить допол-
нительные поля заголовка объекта без изменения версии протоко-
ла, но эти поля не могут считаться заведомо распознаваемыми по-
лучателем. Не узнанные поля заголовка рекомендуется получателю
игнорировать и переадресовывать прокси-серверам.
6.2. Тело объекта
Тела объекта (если они имеются), пересылаемые НТТР-запросом
или откликом, имеют формат и кодировку, определенную полями
заголовка объекта.
entity-body = ‘-OCTET
Тело объекта присутствует в сообщении только когда имеется
тело сообщения, как это описано в разделе 3.3. Тело объекта полу-
чается из т^ла сообщения путем декодирования любого транспорт-
ного кода (Transfer-Encoding), который может быть применен для
обеспечения безопасной и корректной доставки.
6.2.1. Тип
Когда тело объекта включено в сообщение, тип данных этого
тела определяется полями заголовка Content-Type и Content-Encoding»
Они определяют два слоя, заданных моделью кодирования:
entity-body :== Content-Encoding(Content-TypefaaHHbie))
Content-Type специфицирует тип среды данных.
Content-Encoding может использоваться для индикации любого
дополнительного кодирования содержимого поля данных, обычно
Сети передачи данных. Метод доступа
893
для целей архивации, которая является особенностью запрашивае-
мого ресурса. По умолчанию никакого кодирования не используется.
Любое НТТР/1.1 сообщение, содержащее тело объекта, должно
включать поле заголовка Content-Type, определяющее тип среды для
данного тела. Только в случае, когда тип среды не задан полем
Content-Type, получатель может попытаться предположить, каким
является тип среды, просмотрев содержимое и/или расширения имен
URL, использованного для идентификации ресурса. Если тип среды
остается неизвестным, получателю следует рассматривать его как
"application/octet-stream” (поток октетов).
6.2.2. Длина
Длина тела объекта равна длине тела сообщения, после того как
произведено транспортное декодирование. Раздел 4.4 определяет то,
как определяется длина тела сообщения.
4.5.5.1.7. Соединения
7.1. Постоянные соединения
7.1.1. Цель
Прежде чем установить постоянную связь должно быть реали-
зовано отдельное TCP соединение с тем, чтобы получить URL. Это
увеличивает нагрузку HTTP серверов и вызывает перегрузку кана-
лов Интернет. Использование изображений и другой связанной с
этим информации часто требует от клиента множественных запро-
сов, направленных определенным серверам за достаточно короткое
время. Анализ этих проблем содержится в [30] и [27], а результаты
макетирования представлены в [26].
Постоянное HTTP соединение имеет много преимуществ:
• При открытии и закрытии TCP соединений можно сэконо-
мить время CPU и память, занимаемую управляющими блоками
протокола TCP.
• HTTP запросы и отклики могут при установлении связи бу-
феризоваться, образуя очередь. Буферизация позволяет клиенту вы-
полнять множественные запросы, не ожидая каждый раз отклика
па запрос, используя одно соединение TCP более эффективно и с
Меньшими потерями времени.
* Перегрузка сети уменьшается за счет сокращения числа паке-
тов, сопряженных с открытием и закрытием TCP соединений, пре-
доставляя достаточно времени для детектирования состояния пере-
грузки.
894
Гпава 4
• HTTP может функционировать более эффективно, так как со-
общения об ошибках могут доставляться без потери TCP связи.
Новым HTTP реализациям следует пользоваться постоянными со-
единениями.
7.1.2. Общие процедуры
Заметным различием между НТТР/1.1 и более ранними верси-
ями HTTP является постоянное соединение, которое в НТТР/1.1
является вариантом, реализуемым по умолчанию. Поэтому, если не
указано обратное, клиент может предполагать, что сервер будет под-
держивать постоянное соединение.
Постоянное соединение обеспечивает механизм, с помощью кото-
рого клиент и сервер могут сигнализировать о закрытии ТСР-соеди-
нения. Эта система сигнализации использует поле заголовка
Connection. Как только поступил сигнал о закрытии канала, кли-
ент не должен посылать какие-либо запросы по этому каналу.
7.1.2.1. Согласование
НТТР/1.1 сервер может предполагать, что НТТР/1.1 клиент
намерен поддерживать постоянное соединение, если только в поле
заголовка Connection не записана лексема ’’close". Если сервер при-
нял решение закрыть связь немедленно после посылки отклика, ему
рекомендуется послать заголовок Connection, с записанной в нем
лексемой связи close.
Клиентам и серверам не следует предполагать, что соединение
будет оставаться постоянным для версий HTTP, меньше 1.1, если
только не получено соответствующее уведомление.
7.1.2.2. Буферизация
Клиенты, которые поддерживают постоянное соединение, могут
буферизовать свои запросы (то есть, посылать несколько запросов
не дожидаясь отклика для каждого из них). Серверы должны по-
сылать свои отклики на эти запросы в том же порядке, в каком
они их получили.
Клиенты, которые предполагают постоянство соединения и бу-
феризацию немедленно после установления соединения должны быть
готовы совершить повторную попытку установить связь, если пер-
вая попытка не удалась. Если клиент совершает повторную попыт-
ку установления связи, он не должен выполнять буферизацию зап-
росов, пока не получит подтверждения об установления постоянно-
го соединения. Клиенты должны также быть готовы послать повторно
0еТи передачи данных. Метод доступа
895
свои запросы, если сервер закрывает соединение прежде, чем при-
шлет соответствующие отклики.
7.1.3. Прокси-серверы
Особенно важно то, чтобы прокси-серверы корректно использо-
вали свойства поля заголовка Connection, как это специфицировано
в 13.2.1. Прокси-сервер должен сигнализировать о постоянном со-
единении отдельно своему клиенту и исходному серверу (origin server)
или другому прокси, с которым связан. Каждое постоянное соедине-
ние устанавливается только для одной транспортной связи. Про-
кси-сервер не должен устанавливать постоянное соединение с HTTP/
1.0 клиентом.
7.1.4. Практические соображения
Серверы обычно имеют некоторое значение таймаута, за предела-
ми которого они уже не поддерживают более неактивное соедине-
ние. Прокси-серверы могут сделать эту величины больше, так как
весьма вероятно, что клиент создаст больше соединений через один
и тот же сервер. Использование постоянных соединений не уста-
навливает никаких требований на величину этого таймаута для
клиента или сервера.
Когда клиент или сервер хочет прервать связь по таймауту, ему
следует послать корректное оповещение о закрытии соединения.
Клиенты и серверы должны постоянно следить, не выдала ли про-
тивоположная сторона сигнал на закрытие канала и соответствен-
но реагировать на него. Если клиент или сервер не зафиксирует
сигнал противоположной стороны, то будут бессмысленно тратить-
ся ресурсы сети.
Клиент, сервер или прокси могут закрыть транспортный канал в
любое время. Например, клиент может послать новый запрос во
время, когда сервер решит закрыть ’’пассивное” соединение. С точки
зрения сервера, состояние которое предлагается закрыть, является
пассивным, но с точки зрения клиента идет обработка запроса.
Это означает, что клиенты, серверы и прокси должны быть спо-
собны восстанавливаться после случаев асинхронного закрытия.
Программа клиента должна заново открыть транспортное соедине-
Ние и повторно передать неисполненный запрос без вмешательства
пользователя (см. раздел 1.2). Однако эта повторная попытка не
Должна повторяться при повторной неудаче.
Серверам следует всегда реагировать, по крайней мере, на один
запрос при соединении, если это возможно. Серверам не следует
896
Гпава 4
закрывать соединение в процессе передачи отклика, если только не
имеет место отказ в сети или выключение клиента.
Клиенты, которые используют постоянные соединения, должны
ограничивать число одновременных связей, которые они поддержи-
вают с конкретным сервером. Однопользовательскому клиенту ре-
комендуется поддерживать не более двух соединений с любым сер-
вером или прокси. Прокси следует использовать до 2*N соединений
с другим сервером или прокси, где N равно числу активных пользо-
вателей. Эти рекомендации призваны улучшить время отклика HTTP
и исключить перегрузки Интернет и других сетей.
7.2. Требования к передаче сообщений
Общие требования:
• НТТР/1.1 серверам следует поддерживать постоянные соеди-
нения и использовать TCP механизмы контроля информационного
потока для преодоления временных перегрузок, а не разрывать со-
единение в расчете на то, что клиент совершит повторную попытку.
Последнее может усугубить сетевую перегрузку.
• Клиент НТТР/1.1 (или позднее), посылая тело сообщения,
должен мониторировать сетевое соединение на наличие сигнала
ошибки. Если клиент обнаружил состояние ошибки, он должен не-
медленно прервать передачу. Если тело передается с использовани-
ем блочной кодировки (’’chunked” encoding, раздел 2.6), возможно
применение фрагмента нулевой длины и пустой завершающей сек-
ции для обозначения преждевременного конца сообщения. Если телу
предшествовал заголовок Content-Length, клиент должен разорвать
соединение.
• Клиент НТТР/1.1 (или позднее) должен быть готов принять
код статуса 100 (Continue — продолжить), за которым следует обыч-
ный отклик.
• Сервер НТТР/1.1 (или позднее), который получает запрос от
клиента НТТР/1.0 (или ранее), не должен передавать отклик 100
(continue — продолжение), ему следует или ждать нормального за-
вершения запроса (таким образом, избегая его прерывания) или.
преждевременно разрывать соединение.
Клиентам следует запомнить номер версии, по крайней мере,,
сервера, с которым проводилась работа последним, если клиент HTTP/
1.1 получил отклик от сервера НТТР/1.1 (или позднее) и обнару-
жил разрыв соединения до получения какого-либо статусного кода,,
клиенту следует повторно попытаться направить запрос без учас-
тия пользователя (см. раздел 9.1.2). Если клиент действительно
повторяет запрос, то клиент:
Сети передачи данных. Метод доступа
897
• Должен сначала послать поля заголовка запроса, а затем;
• ждать, того, что сервер пришлет отклик 100 (Continue), после
чего продолжить работу, или код статуса, сигнализирующего об
ошибке.
Если клиент НТТР/1.1 не получил отклика от сервера HTTP/
1.1 (или более поздней версии), ему следует считать, что сервер под-
держивает версию HTTP/1.0 или более раннюю и не использует
отклик 100 (Continue). Если в этом случае клиент обнаруживает
закрытие соединения до получения какого-либо статусного кода от
сервера, клиенту следует повторить запрос. Если клиент повторил
запрос серверу HTTP/1.0, ему следует использовать следующий ал-
горитм получения надежного отклика:
• Инициировать новое соединение с сервером.
• Передать заголовок запроса.
• Инициализировать переменную R для оценки задержки от-
клика сервера (round-trip time) (напр.,на основе времени установ-
ления соединения), если RTT не доступно, ему присваивается значе-
ние 5 секунд.
• Вычислить Т = R * (2N), где N равно числу предыдущих попы-
ток запроса.
• Ждать в течение Т секунд или до прихода статуса ошибки
(что наступит раньше).
• Если не получен сигнал ошибки, после Т секунд передать тело
запроса.
• Если клиент обнаруживает преждевременное прерывание свя-
зи, повторять шаг 1 до тех пор, пока запрос не будет принят или
будет получен сигнал ошибки, или пока нетерпеливый пользова-
тель не завершит процесс посылки повторных запросов.
Вне зависимости от версии сервера, если получен статус ошибки,
то клиент:
• Не должен продолжать операции и
• должен прервать соединение, если процедура не завершена
посылкой сообщения.
Клиент НТТР/1.1 (или позднее), который обнаруживает разрыв
соединения после получения флага 100 (Continue), но до получения
какого-либо статусного кода, должен повторить запрос и не должен
Ждать отклика 100 (Continue), но может и делать это, если это
Упрощает реализацию программы.
4.5.5.1.8. Метод определений
Набор общих методов для НТТР/1.1 определен ниже. Хотя этот
набор может быть расширен, нельзя предполагать, что дополнитель-
**9 Зак. № 3430 Семенов
898
Гпава 4
ные методы следуют той же семантике для разных клиентов и сер-
веров. Поле заголовка запроса Host (раздел 13.23) должно присут-
ствовать во всех запросах НТТР/1.1.
8.1. Безопасные и подобные методы
8.1.1. Безопасные методы
Программисты должны заботиться о том, чтобы избегать опера-
ций, которые могут иметь неожиданное значение для них самих или
их соседей по сети Интернет.
В частности, установлено соглашение, что методы GET и HEAD
никогда не должны выполнять какие либо функции помимо дос-
тавки информации. Эти методы должны рассматриваться как впол-
не безопасные. Это позволяет агентам пользователя представлять
другие методы, такие как POST, PUT и DELETE, особым способом,
так что пользователь сам будет заботиться о возможности опасных
операций, которые могут быть выполнены в результате реализации
запроса.
Естественно, невозможно гарантировать, что сервер не будет вы-
зывать побочные эффекты, как следствие выполнения запроса GET;
в действительности, некоторые динамические ресурсы предусматри-
вают такую возможность. Важным здесь является то, что пользова-
тель не запрашивал побочные эффекты и, следовательно, не может
нести ответственность за них.
8.1.2. Подобные методы
Методы могут также иметь свойство ’’idempotence”, при котором
(помимо ошибок и таймаутов) побочный эффект от N > 0 идентич-
ных запросов является таким же, как и от одного запроса. Методы
GET, ЦЕАЛ, PUT и DELETE имеют это свойство.
8.2. Опции
Метод OPTIONS представляет собой запрос информации о ком-
муникационных опциях, доступных в цепочке запрос/отклик, иден-
тифицированной Request-URI. Этот метод позволяет клиенту опре-
делить опции и/или требования, связанные с ресурсами, или воз-
можности сервера, не прибегая к операциям по извлечению и
пересылке каких-либо файлов.
Если отклик сервера не сигнализирует об ошибке, отклик не
должен включать никакой информации об объекте, отличной отто-
го, что считается коммуникационными опциями (напр., Allow под-
ходит под эту категорию, a Content-Type нет). Отклики на этот ме-
тод не должны кэшироваться.
Сети передачи данных. Метод доступа
899
Если Request-URI тождественен символу звездочка ("*"), то зап-
рос OPTIONS будет относиться ко всему серверу. Отклик 200 будет
содержать любые поля заголовка, которые указывают на опцион-
ные характеристики используемого сервера (например, Public), включая
любые расширения неопределенные в данной спецификации. Как
описано в разделе 4.1.2, запрос "OPTIONS *" может быть реализо-
ван через прокси путем спецификации сервера места назначения в
Request-URI без указания прохода. Если Request-URI не равен звез-
дочке, запрос OPTIONS относится только к опциям, которые дос-
тупны при обмене с данным ресурсом. Отклик 200 должен вклю-
чать любые поля заголовка, которые характеризуют опционные ха-
рактеристики используемого сервера и применимы к данному ресурсу
(напр., Allow), включая любые расширения, не описанные в данной
спецификации. Если запрос OPTIONS проходит через прокси, то он
должен редактировать отклик и удалять те опции, которые не дос-
тупны при реализации через данный прокси-сервер.
8.3. Метод GET
Метод GET предполагает извлечение любой информации (в фор-
ме объекта), определенной Request-URI. Если Request-URI относит-
ся к процессу, генерирующему данные, то в результате в виде объек-
та будут присланы эти данные, а не исходный текст самого процесса,
если только этот текст не является результатом самого процесса.
Семантика метода меняется на "условный GET", если сообще-
ние-запрос включает в себя поля заголовка If-Modified-Since, If-
Unmodified-Since, If-Match,' If-None-Match или If-Range. Метод ус-
ловного GET запрашивает, пересылку объекта только при выполне-
нии условий, описанных в соответствующих полях заголовка. Метод
условного GET имеет целью уменьшить ненужное использование
сети путем разрешения актуализации кэшированых объектов без
посылки множественных запросов или пересылки данных, которые
уже имеются у клиента. Семантика метода GET меняется на "час-
тичный GET", если сообщение запроса включает в себя поле заго-
ловка Range. Запросы частичного GET, которые предназначены для
пересылки лишь части объекта, описаны в разделе 13.36. Метод
частичного GET ориентирован на уменьшение ненужного сетевого
обмена, допуская пересылку лишь части объекта, которая нужна
клиенту, и не пересылая уже имеющихся частей.
Отклик на запрос GET буферизуется, тогда и только тогда, когда
это согласуется с требованиями буферизации, рассмотренными в раз-
деле 12.
29*
900
Гпава 4
8.4. Метод HEAD
Метод HEAD идентичен GET за исключением того, что сервер не
должен присылать тело сообщения. Метаинформация, содержащая-
ся в заголовках отклика на запрос HEAD должна быть идентичной
информации посланной в отклик на запрос GET. Этот метод может
использоваться для получения метаинформации об объекте, указан-
ном в запросе, без передачи тела самого объекта. Этот метод часто
используется для тестирования гипертекстных связей на коррект-
ность, доступность и актуальность.
Отклик на запрос HEAD может кэшироваться в том смысле, что
информация, содержащаяся в отклике, может использоваться для
актуализации кэшированных ранее объектов данного ресурса, Если
новые значения поля указывают на то, что кэшированный объект
отличается от текущего объекта (как это индицируется изменени-
ем Content-Length, Content-MD5, ETag или Last-Modified), тогда за-
пись в кэше должна рассматриваться как устаревшая.
8.5. Метод POST
Метод POST используется при заявке серверу принять вложен-
ный в запрос объект в качестве нового вторичного ресурса, иденти-
фицированного Request-URI в Request-Line. POST создан для обес-
печения однородной схемы реализации следующих функций:
• Аннотация существующего ресурса.
• Помещение сообщения на электронную доску объявлений, в группу
новостей, почтовый список или какую-то другую группу статей.
• Выдала блока данных, такого как при передаче формы процес-
су ее обработки.
• Расширение базы данных с помощью операции добавления
(append).
Реальная операция, выполняемая методом POST, определяется
сервером и обычно зависит от Request-URI. Присланный объект
является вторичным по отношению к URI в том же смысле, в
каком файдг является вторичным по отношению к каталогу, в ко-
тором он находится, а статья новостей — вторичной по отношению
к группе новостей, куда она помещена, или запись - по отношению
к базе данных.
Операция, выполняемая методом POST, может не иметь послед-
ствий для ресурса, который может быть идентифицирован URI. В
этом случае приемлемым откликом является 200 (ОК) или 204
(No Content - никакого содержимого), в зависимости от того, вклю-
чает ли в себя отклик объект, описывающий ресурс.
Сети передачи данных. Метод доступа
901
Если ресурс был создан на исходном сервере, отклик должен
быть равен 201 (Created — создан) и содержать объект, который
описывает статус запроса и относится к новому ресурсу и заголовку
Location (см. раздел 13.30).
Отклики на этот метод не могут кэшироваться, если только не
содержат поля заголовка Cache-Control или Expires. Однако отклик
303 (см. Other) может быть использован для того, чтобы указать
агенту пользователя извлечь кэшируемый ресурс.
Запросы POST должны подчиняться требованиям, предъявляе-
мым к передаче сообщений, рассмотренным в разделе 7.2.
8.6. Метод PUT
Метод PUT требует, чтобы вложенный объект был запомнен с
использованием Request-URI. Если Request-URI относится к уже
существующему ресурсу, то вложенный объект следует рассматри-
вать как модифицированную версию объекта на исходном сервере.
Если Request-URI не указывает на существующий ресурс и запра-
шивающий агент пдльзователя может определить этот URI как но-
вый ресурс, исходный сервер может создать ресурс с этим URL Если
новый ресурс создан, исходный сервер должен информировать об
этом агента пользователя, послав код отклик 200 (ОК) или 204
(No Content - никакого содержимого) и тем самым, объявляя об
успешно выполненном запросе. Если ресурс не может быть создан
или модифицирован с помощью Request-URI, должен быть послан
соответствующий код отклика, который отражает характер пробле-
мы. Получатель объекта не должен игнорировать любой заголовок
Content-* (например, Content-Range), который он не понял или не
использовал, а должен в таком случае вернуть код отклика 501
(Not Implemented - не использовано).
Если запрос проходит через кэш и Request-URI идентифицирует
один или более кэшированных объектов, эти объекты должны рас-
сматриваться как устаревшие. Отклики этого метода не должны
кэшироваться.
Фундаментальное отличие между запросами POST и PUT отра-
жается в различных назначениях Request-URI. URI в запросе POST
идентифицирует ресурс, который будет работать с вложенным объек-
том. Этот ресурс может быть процессом приемки данных, шлюзом
к другому протоколу или отдельным объектом, который восприни-
мает аннотации. Напротив, URI в запросах PUT идентифицируют
объекты, заключенные в запросе, - агент пользователя знает, какой
URI применить, и сервер не должен пытаться посылать запрос дру-
902
Гпава 4
гому ресурсу. Если сервер хочет, чтобы запрос был направлен друго-
му URI, он должен послать отклик 301 (Moved Permanently). Агент
пользователя может принять свое собственное решение относительно
того, следует ли переадресовывать запрос.
Один и тот же ресурс может быть идентифицирован многими
URL Например, статья может иметь URI для идентификации ’’теку-
щей версии’’, которая отличается от URI, идентифицирующей каж-
дую конкретную версию. НТТР/1.1 не определяет то, как метод
PUT воздействует на состояние исходного сервера. Запросы PUT
должны подчиняться требованиям передачи сообщения, заданным
в разделе 7.2.
8.7. Метод DELETE
Метод DELETE требует, чтобы исходный сервер уничтожил ре-
сурс, идентифицируемый Request-URI. Этот метод на исходном сер-
вере может быть отвергнут вмешательством человека (или каким-
то иным путем). Клиент не может гарантировать, что операция
была выполнена, даже если возвращенный статусный код указыва-
ет, что операция завершилась успешно. Однако сервер не должен
сообщать об успехе, если он не намерен стереть ресурс или перемес-
тить его в недоступное место.
Сообщение об успехе должно иметь код 200 (ОК), если отклик
включает объект, описывающий статус; 202 (Accepted — принято),
если операция еще не произведена или 204 (No Content - Никакого
содержимого), если отклик ОК, но объекта в нем нет.
Если запрос проходит через кэш, a Request-URI идентифицирует
один или более кэшированных объектов, эти объекты следует счи-
тать устаревшими (stale). Отклики на этот метод не кэшируемы.
8.8. Метод TRACE
Метод TRACE используется для того, чтобы запустить удален-
ный цикл сообщения-запроса на прикладном уровне. Конечный
получатель запроса должен отослать полученное сообщение назад
клиенту в виде тела объекта отклика (код = 200 (ОК)). Конечным
получателем является либо исходный сервер, либо первый прокси
или шлюз для получения значения Max-Forwards (0) в запросе (см.
раздел 13.31). Запрос TRACE не должен включать в себя объект.
TRACE позволяет клиенту видеть, что получено на другом конце
цепи запроса, и использовать эти данные для тестирования или
диагностики. Значение поля заголовка Via (раздел 13.44) представ-
ляет особый интерес, так как оно позволяет клиенту отследить це-
почку реализации запроса. Использование поля заголовка Мах-
Сети передачи данных. Метод доступа
903
Forwards позволяет клиенту ограничить длину цепочки выполне-
ния запроса, что весьма полезно для тестирования цепи прокси, пе-
реадресующих сообщения по замкнутому кругу.
В случае успеха отклик должен содержать все сообщение-запрос
с Content-Type == ”message/http”. Отклики этого метода не должны
кэшироваться.
4.5.5.1.9. Определения статусных кодов
Ниже описаны статусные коды, включая то, каким методам они
соответствуют, и какая метаинформация должна присутствовать в
откликах.
9.1. Информационный 1хх
Этот класс статусного кода индицирует информационный от-
клик, состоящий только из статусной строки и опционных заголов-
ков с пустой строкой в конце. Так как НТТР/1.0 це определяет
каких-либо статусных кодов 1хх, серверы не должны посылать от-
клики 1хх клиентам НТТР/1.0 за исключением случаев отладки
экспериментальных протокольных версий.
100 Continue (продолжение)
Получив этот отклик, лиент может продолжать работу. Этот
промежуточный отклик используется для информирования клиен-
та о том, что начальная часть запроса получена и пока не отклоне-
на сервером. Клиенту следует продолжить отправлять оставшуюся
часть запроса, если же запрос уже отправлен, то игнорировать этот
отклик. Сервер должен послать окончательный отклик по заверше-
нии реализации запроса.
101 Switching Protocols (Переключающие протоколы)
Сервер оповещает клиента о том, что он понял и принял к ис-
полнению запрос. С помощью поля заголовка сообщения Upgrade
(раздел 13.41) клиент уведомляется об изменении прикладного про-
токола для данного соединения. Сервер переходит на протокол, оп-
ределенный в поле заголовка отклика Upgrade, немедленно после
получения пустой строки, завершающей отклик 101.
Протокол следует изменять лишь в случае, если это предостав-
ляет существенные преимущества. Например, переключение на но-
вую версию HTTP предоставляет преимущества по отношению к
старой версии, а переключение на синхронный протокол реального
времени может иметь преимущество, когда ресурс использует это
свойство.
904
Гпава 4
9.2. Successful 2хх (Успешная доставка)
Этот класс статусного кода индицирует, что запрос клиента бла-
гополучно получен, понят и принят к исполнению.
,200 ОК
Запрос успешно исполнен. Информация, возвращаемая вместе с
откликом, зависит от метода, использованного запросом, например:
GET в качестве Отклика посылается объект, соответствующий
запрошенному ресурсу;
HEAD в качестве отклика присылаются поля заголовка объекта
(без какого-либо тела), соответствующего запрошенному
ресурсу;
POST присылается объект, описывающий или содержащий
результат операции;
TRACE присылается объект, содержащий сообщение-запрос в виде,
полученном оконечным сервером.
201 Created (Создано)
Запрос исполнен и в результате создан новый ресурс. Вновь со-
зданный ресурс может быть доступен через URI, присланный в объекте
отклика, со значащей частью URL ресурса в поле заголовка Location.
Исходный сервер должен создать ресурс до отправки статусного кода
201. Если операция не может быть выполнена немедленно, сервер
вместо этого должен откликнуться статусным кодом 202 (Accepted).
202 Accepted (Принято)
Запрос^)ыл принят для исполнения, но обработка запроса не завер-
шена. Запрос может обрабатываться или нет, так как он был блокиро-
ван в процессе исполнения. Не существует механизма повторной по-
сылки статусного кода для асинхронных операций вроде этой.
Целью отклика 202 является разрешить серверу принять запрос
для некоторого другого процесса (возможно процесса, запускаемого
раз в день), не требуя того, чтобы соединение агента пользователя с
сервером сохранялось до завершения процесса. Объект, возвращае-
мый этим откликом должен включать в себя текущий статус запро-
са и указатель на статус-монитор или некоторую оценку того, когда
пользователь может ожидать завершения реализации запроса.
203 Non-Authoritative Information (Не надежная информация)
Присылаемая в ответ метаинформация в заголовке объекта не иден-
тифицируется, как полученная от исходного сервера, ее следует скорее
считать косвенной, полученной апосредовано. Например, включение
местной аннотационной информации о ресурсе может иметь послед-
ствия для метаинформации, известной исходному серверу. Использо-
Сети передачи данных. Метод доступа
905
вание данного кода отклика не является обязательным и целесооб-
разно лишь в случае, когда отклик мог бы быть равен 200 (ОК).
204 No Content (Никакого содержимого)
Сервер исполнил запрос, но нет никакой новой информации для
отсылки. Этот отклик первоначально предназначался ддя разреше-
ния ввода, не вызывая изменения активного документа агента пользо-
вателя. Отклик может включать новую метаинформацию в форме
заголовков объектов, которая должна быть передана для документа,
отображаемого агентом пользователя.
Отклик 204 не должен включать тела сообщения и всегда за-
вершается пустой строкой после полей заголовка.
205 Reset Content (Сброс содержимого)
Сервер исполнил запрос и агент пользователя должен вернуть
документ к виду, который он имел в момент посылки запроса. Этот
отклик первоначально предназначался для обеспечения ввода при
выполнении пользователем операции, за которой следует очистка
формы, в которую произведен ввод, так что пользователь может на-
чать другую операцию ввода. Отклик не должен включать в себя
объект.
206 Partial Content (Частичное содержимое)
Сервер исполнил частично запрос GET для заданного ресурса.
Запрос должен включать поле заголовка Range (раздел 13.36), ука-
зывающее на желательный интервал (range). Отклик должен вклю-
чать поле заголовка Content-Range (раздел 13.17), указывающее
диапазон данных, включенных в отклик, или множественные байт-
ные интервалы (multipart/byteranges) Content-Type, включающие
поля Content-Range для каждой из частей. Если множественные
байтные интервалы не используются, поле заголовка Content-Length
в отклике должно соответствовать действительному числу октетов
в теле сообщения. Кэш, который не поддерживает заголовки Range
и Content-Range, не должен кэшировать отклики 206 (Partial).
9.3. Redirection Зхх (Переадресация)
Этот класс статусных кодов указывает, что для выполнения зап-
роса, нужны дальнейшие действия агента пользователя. Необходи-
мые действия могут быть выполнены агентом пользователя без
взаимодействия с пользователем, тогда и только тогда, когда ис-
пользуемый метод соответствует GET или HEAD. Агент пользовате-
ля не должен автоматически переадресовывать запрос более чем 5
раз, так как такая переадресация обычно свидетельствует о зацик-
ливании запроса.
906
Гпава 4
300 Multi pie Choices (Множественный выбор)
Запрошенный ресурс соответствует какому-то представлению из
имеющегося набора представлений, каждое со своим адресом. Имеет-
ся информация (раздел 11), полученная в результате согласования
под управлением агента пользователя, так что пользователь (или
агент пользователя) может выбрать предпочтительное представление
и переадресовать свой запрос по соответствующему адресу.
Если только это не был запрос HEAD, отклик должен включать
объект, содержащий список характеристик ресурсов и их адресов, из
которых пользователь или. агент пользователя может выбрать наи-
более подходящий. Формат объекта специфицируется типом среды,
заданным полем заголовка Content-Type. В зависимости от форма-
та и возможностей агента пользователя, выбор* наиболее подходя-
щего варианта может быть выполнен автоматически. Однако эта
спецификация не определяет какого-либо стандарта для такого ав-
томатического выбора.
Если сервер имеет предпочтительный вариант представления, ему
следует включить соответствующий URL этого представления в поле
Location. Агент пользователя может использовать значение поля
Location для реализации автоматического выбора. Этот отклик мо-
жет кэшироваться, если не указано обратного.
301 Moved Permanently (Перемещен на постоянной основе)
Запрошенному ресурсу был приписан новый постоянный URI и
любая будущая ссылка на этот ресурс должна делаться с использо-
ванием одного из присланных URL Клиенты с возможностью ре-
дактирования связей должны, где возможно, автоматически менять
связи для ссылок Request-URI на одну или более новых ссылок,
присланных сервером. Этот отклик можно кэшировать, если не ука-
зано обратного.
Если новый URI является адресом (location), его URL должен
быть задан в поле Location отклика. Если метод запроса не HEAD,
объект отклика должен содержать короткое гипертекстное замеча-
ние с гиперсвязью, указывающей на новый URI.
Если получен статусный код 301 в ответ на запрос, отличный от
GET или HEAD, агент пользователя не должен автоматически пере-
адресовывать запрос, если только это не может быть подтверждено
пользователем, так как такая переадресация может изменить усло-
вия, при которых направлен запрос.
При автоматической переадресации запроса POST, получив ста-
тусный код 301, некоторые существующие агенты пользователя
НТТР/1.0 ошибочно меняют его на запрос GET.
Сети передачи данных. Метод доступа
907
302 Moved Temporarily (Временно перемещен)
Запрошенный ресурс размещается временно под различными URL
Так как переадресация может быть случайно изменена, клиент дол-
жен продолжать использовать Request-URI для будущих запросов.
Этот отклик допускает кэширование, если имеются соответствую-
щие указания в полях заголовка Cache-Control или Expires.
Если новый URI является адресом (location), его URL должен
задаваться полем Location отклика. Если запрошенный метод не
HEAD, объект отклика должен содержать короткое гипертекстный
комментарий с гиперсвязью, указывающей на новый URL
Если в ответ на запрос, отличный от GET или HEAD, получен
статусный код 302, агент пользователя не должен автоматически
переадресовывать запрос, если он не может быть подтвержден пользо-
вателем, так как это может изменить условия, при которых был
выдан запрос.
Замечание. Когда после получения статусного кода 302 автома-
тически переадресуется запрос POST, некоторые существующие агенты
пользователя НТТР/1.0 ошибочно меняют его на запрос GET.
303 See Other (Смотри другие)
Отклик на запрос может быть найден под разными URL Его
следует извлекать с помощью метода GET. Этот метод первоначаль-
но создан для того, чтобы позволить переадресацию агента пользо-
вателя на выбранный ресурс при запуске скрипта с помощью POST.
Новый URI не является заменой ссылки для первоначально запро-
шенного ресурса. Отклик 303 не кэшируется, но отклик на второй
(переадресованный) запрос может кэшироваться.
Если новый URI является адресом (location), его URL должно быть
задано в поле Location отклика. Если метод запроса не HEAD, объект
отклика должен содержать гипертекстовую ссылку на новый URL
304 Not Modified (Не модифицировано)
Если клиент выполнил условный запрос GET и получил доступ,
а документ не был модифицирован, сервер должен реагировать этим
статусным кодом. Отклик не должен содержать тела сообщения.
Отклик должен включать поля заголовка:
• Дата.
• ETag и/или Content-Location, если заголовок был послан в
рамках отклика 200 на тот же самый запрос.
• Expires, Cache-Control и/или Vary, если значение поля может
отличаться от посланного в каком-либо предыдущем отклике того
же типа.
908
Гпава 4
Если условный GET использовал строгий валидатор кэша (см.
раздел 12.3.3), отклик не должен содержать других заголовков объек-
та. В противном случае (напр., условный GET использовал слабый
валидатор), отклик не должен включать в себя другие заголовки.
Это предотвращает несогласованности между кэшированными тела-
ми объектов и актуализованными заголовками.
Если отклик 304 указывает на то, что объект не кэширован,
тогда кэш должен игнорировать отклик и повторить запрос уже в
безусловном режиме. Если кэш использует полученный отклик 304
для актуализации записи в кэше, то кэш должен выполнить актуа-
лизацию с учетом новых значений полей, присланных в отклике.
Отклик 304 не должен включать в себя тело сообщения и, по этой
причине всегда завершается пустой строкой после полей заголовка.
305 Use Proxy (Используйте прокси)
Запрошенный ресурс должен иметь доступ через прокси-сервер,
указанный в поле Location. Поле Location задает URL прокси-серве-
ра. Предполагается, что получатель повторит запрос через прокси.
9.4. Client Error 4хх (Ошибка клиента)
Класс статус кодов 4хх предназначен для случаев, когда клиент
допустил ошибку. За исключением случая отклика на запрос HEAD,
серверу следует включить объект, содержащий объяснение ошибоч-
ной ситуации, а также указать, является ли ситуация временной
или постоянной. Эти статусные коды применимы к любому методу
запросов. Агенту пользователя следует отобразить все объекты.
Если клиент посылает данные, реализация сервера, использую-
щая протокол TCP, должна позаботиться о том, чтобы клиент полу-
чил пакет, содержащий отклик, до того как сервер закроет данное
соединение. Если клиент продолжает посылку данных серверу пос-
ле закрытия связи, TCP-уровень сервера должен послать клиенту
пакет reset (сброс), который может стереть содержимое входного
буфера клиента до того, как оно будет прочитано и интерпретирова-
но приложением HTTP.
400 Bad Request (Плохой запрос)
Запрос может быть не понят сервером из-за ошибочного синтак-
сиса. Клиенту не следует повторять запрос без модификации.
401 Unauthorized (Не авторизован)
Запрос требует идентификации пользователя. Отклик должен
включать в себя поле заголовка WWW-Authenticate (раздел 13.46),
содержащее требование, применимое к запрошенному ресурсу. Кли-
ент может повторить запрос с соответствующим содержимым поля
• Сети передачи данных. Метод доступа
909
заголовка Authorization (раздел 13.8). Если запрос уже включал"
допуск в поле Authorization, тогда отклик 401 указывает на то, что
данный допуск не работает. Если отклик 401 содержит то же
требование, что и предшествующий, а агент пользователя уже про-
бовал пройти авторизацию, по крайней мере, хотя бы раз, тогда
пользователю следует предоставить объект отклика, так как он
может содержать полезную диагностическую информацию. Иден-
тификация доступа HTTP описана в разделе 10.
402 Payment Required (Необходима оплата)
Этот код зарезервирован для использования в будущем.
403 Forbidden (Запрещено)
Сервер понял запрос, но отказался его исполнить. Авторизация
не поможет и повторять запрос не следует. Если метод запроса не
HEAD, а сервер желает открыто объявить причину неисполнения
запроса, то ему следует описать соображения, по которым запрос
отклонен в объекте. Этот статусный код обычно используется, ког-
да сервер не хочет показывать, почему запрос отклонен, или когда
другой отклик не подходит.
404 Not Found (Не найдено)
Сервер не нашел ничего, отвечающего Request-URI. Не приво-
дится никаких данных о том, являются ли эта ситуация временной
или постоянной.
Если сервер не хочет сделать эту информацию открытой для
клиента, вместо этого может использоваться статусный код 403.
Статусный код 410 (Gone — Утрачен) следует использовать, если
сервер знает за счет некоторого внутреннего механизма конфигура-
ции, что старый ресурс постоянно недоступен и не имеет нового
адреса для размещения.
405 Method Not Allowed (Метод не разрешен)
Метод, специфицированный в Request-Line, не разрешен для ре-
сурса, указанного Request-URI. Отклик должен включать заголовок
Allow, содержащий список разрешенных методов для запрошенного
ресурса.
406 Not Acceptable (Не приемлемо)
Ресурс, идентифицированный запросом, способен генерировать
объекты откликов, которые имеют характеристики, неприемлемые
согласно заголовкам accept, присланным в запросе.
Если это не запрос HEAD, отклик должен включать объект, со-
держащий список доступных характеристик объекта и адреса, где
пользователь или агент пользователя может выбрать нечто наибо-
910
Гпава 4
лее подходящее. Формат объекта специфицируется типом среды,
приведенным в поле заголовка Content-Type. В зависимости от
формата и возможностей агента пользователя, оптимальный вы-
бор может быть сделан автоматически. Однако данная специфика-
ция не определяет какого-либо стандарта для такого автоматичес-
кого выбора.
НТТР/1.1 серверам разрешено присылать отклики, которые не-
приемлемы согласно заголовкам accept, присланным в запросе. В
некоторых случаях, может оказаться предпочтительнее послать от-
клик 406. Агенты пользователя могут просматривать заголовки
приходящих откликов с тем, чтобы определить, являются ли они
приемлемыми. Если отклик не может быть воспринят, агенту пользо-
вателя следует временно прервать прием данных и запросить пользо-
вателя принять решение о дальнейших действиях.
407 Proxy Authentication Required (Необходима аутентифика-
ция прокси)
Этот статусный код подобен 401 (Unauthorized), но указывает,
что клиент должен сначала авторизоваться на прокси-сервере. Про-
кси должен, прислать в ответ поле заголовка Proxy-Authenticate
(раздел 13.33), содержащее требования, реализуемые на прокси для
запрошенного ресурса. Клиент может повторить запрос с подходя-
щим полем заголовка Proxy-Authorization (раздел 13.34). Автори-
зация доступа HTTP описана в разделе 10.
408 Request Timeout (Таймаут запроса)
Клиент не выдал запрос в пределах временного интервала, в
течение которого сервер его ожидал. Клиент может повторить зап-
рос без модификаций в любое время.
• 409 Conflict (Конфликт)
Выполнение запроса не может быть завершено из-за конфликта
с текущим состоянием ресурса. Этот статусный код разрешен в
ситуациях, где предполагается, что пользователь может разрешить
конфликт и повторно послать запрос. Тело отклика должно вклю-
чать достаточно информации, чтобы пользователь мог понять при-
чину конфликта. В идеале, объект отклика должен был бы вклю-
чать достаточно информации для пользователя или агента пользо-
вателя для того, чтобы уладить конфликт, однако это невозможно и
необязательно.
Конфликты наиболее вероятно происходят в результате запроса
PUT. Если задействована версия и объект операции PUT вызывает
изменение ресурса, которые конфликтуют с изменениями, внесении-
Сети передачи данных. Метод доступа
911
ми запросом, выполненным ранее, сервер может использовать от-
клик 409 для того, чтобы указать на невозможность завершить
выполнение запроса. В этом случае объект отклика должен содер-
жать список отличий между двумя версиями формата, определен-
ном откликом Content-Type.
410 Gone (Исчез)
Запрошенный ресурс не является более доступным на сервере и
не известен указатель переадресации. Это условие следует считать
постоянным. Клиенты с возможностями редактирования связей дол-
жны ликвидировать ссылки на Request-URI после подтверждения
пользователем. Если сервер не знает или не имеет возможности опре-
делить, является ли данное условие постоянным или временным, сле-
дует использовать отклик со статусным кодом 404 (Not Found). <
Этот отклик можно кэшировать, если не указано обратного.
Отклик 410 первоначально предназначался для того, чтобы по-
мочь работе задач в WWW-среде путем сообщения получателю о
том, что ресурс заведомо недостижим и владелец сервера хотел бы,
чтобы связи с этим ресурсом были удалены. Такое событие являет-
ся типичным для ограниченного периода времени и для ресурсов,
принадлежащих частным лицам, которые не работают более с дан-
ным сервером. Не обязательно отмечать все постоянно недоступ-
ные ресурсы, как исчезнувшие (Gone) или сохранять такую пометку
произвольное время - это оставлено на усмотрение собственника
сервера.
411 Length Required (Необходима длина)
Сервер отказывается принять запрос без определенного значе-
ния Content-Length. Клиент может повторить запрос, если он доба-
вит корректное значение поля заголовка Content-Length, содержа-
щего длину тела сообщения.
412 Precondition Failed (Предварительные условия не выполнены)
Предварительные условия, заданные в одном или более полях
заголовка запроса, воспринимаются как не выполненные, когда это
проверено сервером. Этот код отклика позволяет клиенту устано-
вить предварительные условия для метаинформации (данные поля
заголовка) текущего ресурса и, таким образом, предотвратить воз-
можность использования запрошенного метода для ресурса, отлич-
ного от указанного.
413 Request Entity Too Large (Объект запроса слишком велик)
Сервер отказывается обрабатывать запрос, потому что объект
запроса больше, чем сервер способен обработать. Сервер может зак-
912
Гпава 4
рыть соединение, чтобы помешать клиенту продолжать посылать
запросы.
Если условие является временным, серверу следует включить
поле заголовка Retry-After, чтобы указать на временность этого ус-
ловия, что означает возможность повторения запроса некоторое вре-
мя спустя.
414 Request-URI Too Long (URI запроса слишком велик)
Сервер отказывается обслужить запрос, потому что Request-URI
длиннее, чем сервер способен интерпретировать. Это редкое обстоя-
тельство может возникнуть только, когда клиент не корректно пре-
образует запрос POST в GET с длинной информацией запроса. При
этом клиент ныряет в ’’черную дыру” переадресаций. Примером мо-
жет служить преадресованный URL префикс, который указывает на
свой суффикс, или случай атаки сервера клиентом, который пытается,
использовать дыры в системе безопасности, имеющиеся у клиентов с
фиксированной емкостью буферов для работы с Request-URI.
415 Unsupported Media Туре (Неподдерживаемый тип среды)
Сервер отказывается обслужить запрос, потому что объект зап-
роса имеет формат, неподдерживаемый запрашиваемым ресурсом
для указанного метода.
9.5. Сервер ошибок 5хх
Статусный код отклика, начинающийся с цифры "5”, указывает
на случаи, когда сервер опасается, что он ошибся или не может реали-
зовать запрос. За исключением случаев, когда обрабатывается запрос
HEAD, серверу следует включить объект, содержащий объяснение со-
здавшейся ситуации и указывающей на то, является ли ситуация
временной или постоянной. Агенту пользователя следует отобразить
пользователю любой объект, включенный в отклик. Эти коды откли-
ков применимы для любых методов запроса.
500 Internal Server Error (Внутренняя ошибка сервера)
Сервер столкнулся с непредвиденными условиями, которые ме-
шают ему исполнить запрос.
501 Not Implemented (Не применимо)
Сервер не поддерживает функцию, которая должна быть реали-
зована в ходе исполнения запроса. Это адекватный отклик, когда
сервер не распознает метод запроса и не способен поддерживать его
для данного ресурса.
Сети передачи данных. Метод доступа
913
502 Bad Gateway (Плохой шлюз)
Сервер при работе в качестве шлюза или прокси получил невер-
ный отклик от вышестоящего сервера, к которому он обратился,
выполняя запрос.
503 Service Unavailable (Услуга не доступна)
Сервер в данный момент не может обработать запрос в связи с вре-
менной перегрузкой или другими сложившимися обстоятельствами.
Существование статусного кода 503 не предполагает, что сервер
должен использовать его, когда оказывается перегруженным. Неко-
торые серверы могут захотеть просто отказаться устанавливать со-
единение.
504 Gateway Timeout (Таймаут шлюза)
Сервер при работе в качестве внешнего шлюза или прокси-серве-
ра не получил своевременно отклик от вышестоящего сервера, к
которому он обратился, пытаясь исполнить запрос.
505 HTTP Version Not Supported (Версия не поддерживается)
Сервер не поддерживает или отказывается поддерживать версию
протокола HTTP, которая была использована в сообщении-запросе.
Сервер индицирует, что он не способен или не хочет завершать обра-
ботку запроса в рамках главной версии клиента, как это описано в
разделе 2.1. Отклику следует содержать объект, описывающий, по-
чему эта версия не поддерживается и какие другие протоколы под-
держиваются сервером.
4.5.5.1.10. Аутентификация доступа
HTTP предлагает простой механизм аутентификации с помо-
щью отклика, который может использоваться сервером, чтобы по-
требовать от клиента послать запрос, содержащий аутентификаци-
онную информацию. Для определения схемы аутентификации он
использует лексему произвольной длины, не зависящую от примене-
ния строчных или прописных символов, за ней следует список пар
атрибут-значение. Элементы списка отделяются друг от друга запя-
тыми. Атрибуты представляют собой параметры, которые необходи-
мы для реализации аутентификации согласно схемы.
Auth-scheme = token
auth-param = token ”=” quoted-string
Сообщение-отклиК 401 (Unauthorized) используется исходным
сервером для посылки требования авторизации агенту пользовате-
ля. Этот отклик должен включать в себя поле заголовка WWW-
914
Гпава 4
Authenticate, содержащее, по крайней мере, одно требование доступа
к запрашиваемому ресурсу.
Challenge = auth-scheme 1*SP realm *( auth-param )
Realm = "realm” ”=" realm-value
realm-value = quoted-string
Атрибут области realm (не зависит от применения строчных или
прописных букв) необходим для всех схем аутентификации, кото-
рые посылают требования. Значение атрибута realm (чувствительно
к применению строчных и прописных букв), в комбинации с кано-
ническим корневым URL (см. раздел 4.1.2) сервера доступа, опре-
деляет пространство защиты. Эти области позволяют разделить за-
щищенные ресурсы на сервере на ряд защищенных зон, каждая со
своей собственной схемой авторизации и/или идентификационной
базой данных. Значением атрибута области является строка, обыч-
но присваиваемая исходным сервером, которая может иметь специ-
фическую семантику для каждой схемы авторизации.
Агент пользователя, который хочет идентифицировать себя на
сервере, после получения отклика 401 или 411 может сделать это,
включив в запрос поле заголовка Authorization. Значение поля
Authorization состоит из записей, содержащих идентификационную
информацию агента пользователя для области (realm) запрошенно-
го ресурса.
credentials = basic-credentials
| auth-scheme #auth-param
Домен, в пределах которого может автоматически использовать-
ся аутентификационная информация, определяется зоной защиты.
Если предыдущий запрос был авторизован, та же идентификацион-
ная информация может быть использована для всех других запро-
сов в пределах зоны защиты и во временных рамках, заданных
схемой аутентификации, параметрами и/или предпочтениями пользо-
вателя. Если не определено обратного схемой авторизации, одна
зона защиты не может быть распространена за пределы ее сервера.
Если сервер не хочет принимать идентификационную информа-
цию, присланную в запросе, он должен прислать отклик 401
(Unauthorized). Отклик должен включать поле заголовка WWW-
Authenticate, содержащее требование (возможно новое), применимое
для запрошенного ресурса, и объект, объясняющий причину отказа.
Протокол HTTP не ограничивает приложения только этим про-
стым механизмом авторизации (требование-отклик). Может быть
применен дополнительный механизм, такой как шифрование на
Сети передачи данных. Метод доступа
915
транспортном уровне или использование инкапсуляции сообщений.
Однако в данной спецификации эти дополнительные механизмы не
определены.
Прокси-серверы должны быть полностью прозрачны по отноше-
нию авторизации агентов пользователя. То есть, они должны пере-
адресовывать в неприкосновенном виде заголовки WWW-Authenticate
и Authorization, согласно правилам описанным в разделе 13.8.
НТТР/1.1 позволяет клиенту передать идентификационную ин-
формацию в прокси и обратно с использованием заголовков Ргоху-
Authenticate и Proxy-Authorization.
10.1. Базовая схема аутентификации
Базовая схема авторизации базируется на модели, в которой агент
пользователя должен идентифицировать себя с помощью имени
пользователя и пароля, необходимого для каждой области (realm).
Значение атрибута realm должно рассматриваться в виде неотобра-
жаемой строки символов, которая может сравниваться с другим
значение realm на этом сервере.
Сервер обслужит запрос только в случае, если убедится в коррек-
тности имени и пароля пользователя для данной зоны защиты
Request-URI. Не существует каких-либо опционных параметров ав-
торизации.
При получении неавторизованного запроса для URI в пределах
зоны защиты (protection space), сервер может реагировать посылкой
требования в виде:
WWW-Authenticate: Basic realm=="WallyWorld"
где "WallyWorld" - строка, присвоенная сервером для идентифика-
ции зоны защиты Request-URI.
Чтобы получить авторизацию клиент посылает свое имя и па-
роль, разделенные символом двоеточие (":"), и закодированные со-
гласно base64.
basic-credentials = "Basic” SP basic-cookie
basic-cookie = <base64 [7] encoding of user-pass, except not
united to 76 char/line>
user-pass = userid password
userid = *<TEXT excluding
password = *TEXT
Идентификационная информация может быть чувствительной к
применению строчных или прописных букв.
916 Глава 4
Если агент пользователя хочет послать имя пользователя ’’Aladdin”
и пароль ’’open sesame”, он использует следующее поле заголовка:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Смотри раздел 14 по поводу соображений безопасности, связан-
ных с базовой авторизацией. Краткое изложение идей авторизации
для HTTP представлено в документе RFC 2069 [32].
4.5.5 Л. 11. Согласование содержимого
Большинство HTTP откликов включают в себя объекты, кото-
рые содержат информацию для интерпретации человеком-пользова-
телем. Естественно, желательно обеспечить пользователя наилуч-
шим объектом, соответствующим запросу. К сожалению, для серве-
ров и кэшей не все пользователи имеют одни и те же предпочтения
и не все агенты пользователя в равной степени способны обрабаты-
вать все типы объектов. По этой причине, HTTP имеет несколько
механизмов обеспечения согласования содержимого - процесс выбо-
ра наилучшего представления для данного отклика, когда доступны
несколько возможностей.
Замечание. Это не называется "согласование формата ” потому,
что альтернативные представления могут принадлежать к одному и
тому же типу среды, но использовать различные возможности этого
типа, например, различные иностранные языки.
Любой отклик, содержащий тело объекта может быть предме-
том согласования, включая отклики об ошибках. Существует два
сорта согласования содержимого, которые возможны в HTTP: со-
гласование под управлением сервера и под управлением агента
пользователя. Эти два вида согласования могут использоваться по
отдельности или в сочетании. Один из методов, называемый про-
зрачным согласованием, реализуется, когда кэш использует инфор-
мацию, полученную от исходного сервера в результате согласования
под управлением агента пользователя. Эта информация использу-
ется для последующих запросов, где осуществляется согласование
под управлением сервера.
11.1. Согласование, управляемое сервером
Если выбор наилучшего представления для отклика выполнен с
использованием некоторого алгоритма на сервере, такая процедур*
называется согласованием под управлением сервера. Выбор бази-
руется на доступных представлениях отклика (размеры, в пределах
которых он может варьироваться, язык, кодировка и т.д.) и на со-
держимом конкретных полей заголовка в сообщении-запросе иля
Сети передачи данных. Метод доступа 917
другой информации, имеющей отношение к запросу (например, сете-
вой адрес клиента).
Согласование, управляемое сервером предпочтительнее, когда
алгоритм выбора из числа доступных представлений трудно опи-
сать агенту пользователя. Согласование под управлением сервера
привлекательно тогда, когда сервер хочет послать свои ’’наилучшие
предложения” клиенту вместе с первым откликом (надеясь избе-
жать задержек RTT последующих запросов, если предложение удов-
летворит пользователя). Для того чтобы улучшить предложения
сервера, агент пользователя может включить в запрос поля заголов-
ка (Accept, Accept-Language, Accept-Encoding, и т.д.), которые описы-
вают его предпочтения для данного запроса. Согласование под уп-
равлением сервера имеет следующие недостатки.
• Для сервера трудно определить, что является “лучшим” для
любого заданного пользователя, так как это потребовало бы полно-
го знания как возможностей агента пользователя, так конкретного
назначения отклика (напр., хочет ли пользователь видеть отклик
на экране или отпечатать на принтере?).
• Заставлять агента пользователя описывать свои возможнос-
ти при каждом запросе крайне неэффективно (ведь лишь неболь-
шой процент запросов имеют несколько вариантов представления)
и потенциально нарушает конфиденциальность пользователя.
• Это усложняет реализацию исходного сервера и алгоритм ге-
нерации откликов на запросы.
• Это может ограничить возможность общедоступного кэша ис-
пользовать один и тот же отклик для запросов многих пользователей.
НТТР/1.1 включает в себя следующие поля заголовка запроса
для активации согласования, управляемого сервером, через описание
возможностей агента пользователя и предпочтений самого пользо-
вателя: Accept (раздел 13.1), Accept- Charset (раздел 13.2), Accept-
Encoding (раздел 13.3), Accept-Language (раздел 13.4) и User-Agent
(раздел 13.42). Однако исходный сервер не ограничен этими рамка-
ми и может варьировать отклик, основываясь на свойствах запроса,
включая информацию помимо полей заголовка запроса или исполь-
зуя расширения полей заголовка нерассмотренные в данной специ-
фикации.
Исходные серверы НТТР/1.1 должны включать соответствую-
щие поля заголовка Vary (раздел 13.43) в любой кэшируемый зап-
рос, базирующийся на согласовании, управляемом сервером. Поле
описывает пределы, в которых может варьироваться отклик
(то есть, пределы, в которых исходный сервер выбирает свои ”наи-
лУчшие предложения” отклика из многообразия представлений).
918
Гпава 4
Общедоступный кэш НТТР/1.1 должен распознавать поле заго-
ловка Vary, когда оно включено в отклик и подчиняется требовани-
ям, описанным в разделе 12.6, где рассматриваются взаимодействия
между кэшированием и согласованием содержимого.
11.2. Согласование, управляемое агентом
При согласовании, управляемом агентом, выбор наилучшего пред-
ставления для отклика выполняется агентом пользователя после
получения стартового отклика от исходного сервера. Выбор базиру-
ется на списке имеющихся представлений отклика, включенном в
поля заголовка (эта спецификация резервирует имя поля Alternates,
как это описано в 15.6.2.1) или тело объекта исходного отклика,
при этом каждое представление идентифицируется своим собствен-
ным URL Выбор из числа представлений может быть выполнен
автоматически (если агент пользователя способен на это) или вруч-
ную пользователем, выбирая вариант из гипертекстного меню.
Согласование, управляемое агентом, имеет преимущество тогда,
когда отклик варьируется в определенных пределах (таких как тип,
язык или кодирование), когда исходный сервер не способен опреде-
лить возможности агента пользователя, проанализировав запрос, и
вообще, когда общедоступные кэши используются для распределе-
ния нагрузки серверов и для снижения сетевого трафика.
Согласование под управлением агента имеет тот недостаток, что
требуется второй запрос для получения наилучшего альтернативно-
го представления. Этот второй запрос эффективен только тогда, ког-
да используется кэширование. Кроме того, эта спецификация не
определяет какого-либо механизма поддержки автоматического вы-
бора, хотя она и не препятствует применению любого такого меха-
низма в рамках расширения НТТР/1.1.
НТТР/1.1 определяет статусные коды 300 (Multiple Choices -
множественный выбор) и 406 (Not Acceptable - Не приемлем) для
активации согласования под управлением агента, когда сервер не
хочет или не может обеспечить свой механизм согласования.
11.3. Прозрачное согласование
Прозрачное согласование представляет собой комбинацию уп-
равления сервера и агента. Когда кэш получает форму списка воз-
можных представлений откликов (как в согласовании под управле-
нием агента) и кэшу полностью поняты пределы вариации, тогда
кэш становится способным выполнить согласование под управле-
нием сервера для исходного сервера при последующих запросах
этого ресурса.
Сети переда чи данных. Метод доступа 919
Прозрачное согласование имеет преимущество распределения
работы согласования, которое в противном случае было бы выпол-
нено исходным сервером. При этом удаляется также задержка, со-
пряженная со вторым запросом при схеме согласования под управ-
лением агента, когда кэш способен правильно прогнозировать от-
клик.
Эта спецификация не определяет какого-либо механизма для
прозрачного согласования, хотя она и не препятствует использова-
нию таких механизмов в будущих версиях НТТР/1.1. Выполнение
прозрачного согласования кэшем НТТР/1.1 должно включать в
отклик поле заголовка Vary (определяя пределы его вариаций), обес-
печивая корректную работу со всеми клиентами НТТР/1.1.
4.5.5.1.12. Кэширование в HTTP
HTTP обычно используется для распределенных информацион-
ных систем, где эксплуатационные характеристики могут быть улуч-
шены за счет применения кэширования откликов. Протокол HTTP/
1.1 включает в себя много элементов, предназначенных для опти-
мизации такого кэширования. Благодаря тому, что эти элементы
завязаны с другими аспектами протокола и из-за их взаимодей-
ствия друг с другом, полезно описать базовую схему кэширования в
HTTP отдельно от детального рассмотрения методов, заголовков,
кодов откликов и т.д.
Кэширование представляется бесполезным, если оно значительно
не улучшит работу. Целью кэширования в НТТР/1.1 является ис-
ключение во многих случаях необходимости посылать запросы, а в
некоторых других случаях — полные отклики. При этом уменьша-
ется число необходимых RTT для многих операций. Для этих целей
используется механизм ’’истечения срока’’ (см. раздел 12.2). Одно-
временно снижаются требования к полосе пропускания сети, для чего
применяется механизм проверки пригодности (см. раздел 12.3).
Требования к рабочим характеристикам, доступности и работе
без соединения заставляют нас несколько снизить семантическую
прозрачность. Протокол НТТР/1.1 позволяет исходным серверам,
кэшам и клиентам снизить прозрачность, когда необходимо. Так
как непрозрачность операций может поставить в тупик недостаточ-
но опытных пользователей, а также привести к определенной несов-
местимости для некоторых серверных приложений (таких как тор-
говля по заказу), протокол рекомендует не убирать прозрачность
Полностью, а лишь несколько ее ослабить.
Следовательно, протокол НТТР/1.1 обеспечивает следующие важ-
нее моменты:
920 Гпава 4
• Протокольные особенности, которые гарантируют полную се-
мантическую прозрачность, когда это требуется всеми участниками
процесса.
• Протокольные особенности, которые позволяют исходному сер-
веру или агенту пользователя запросить и управлять непрозрачны-
ми операциями.
• Протокольные особенности, которые позволяют кэшу присое-
динить предупреждения к откликам, которые не сохраняют запро-
шенный уровень семантической прозрачности.
Базовым принципом является возможность для клиентов де-
тектировать любое ослабление семантической прозрачности.
Разработчики серверов, кэшей или клиентов могут столкнуться
с решениями, которые не обсуждались в данной спецификации. Если
решение может повлиять на семантическую прозрачность, разработ-
чик может ошибаться относительно прозрачной работы, не проведя
детального анализа и не убедившись, что нарушение такой прозрач-
ности дает существенные преимущества.
12.1.1. Корректность кэша
Корректный кэш должен реагировать на запрос откликом но-
вейшей версии, которой он владеет. Разумеется, отклик должен со-
ответствовать запросу (см. разделы 12.2.5, 12.2.6, и 12.12) и отве-
чать одному из следующих условий:
• Он был проверен на эквивалентность с тем, который бы при-
слал исходный сервер при соответствующем запросе (раздел 12.3);
• Он достаточно нов (см. раздел 12.2). В варианте по умолча-
нию это означает, что он отвечает минимальным требованиям кли-
ента, сервера и кэша по новизне (см. раздел 13.9).
• Он включает в себя предупреждение, о нарушении требований
новизны клиента или исходного сервера (см. разделы 12.1.5 и 13.45).
• Это сообщение-отклик 304 (Not Modified), 305 (Proxy Redirect),
или ошибка (4хх или 5хх).
Если кэш не может осуществлять обмен с исходным сервером,
он должен реагировать в соответствии с вышеприведенными прави-
лами, если отклик может быть корректно обслужен, в противном
случае он должен отослать сигнал ошибки или предупреждения,
указывающий, что имел место отказ в системе коммуникаций.
Если кэш получает отклик (полный отклик или код 304 (Not
Modified)), который уже не является свежим, кэш должен переадрет*
совать его запросившему клиенту без добавления нового предул*
реждения, но и не удаляя существующего заголовка Warning. КэШУ
не следует пытаться перепроверить отклик, так как это может при*
&еТИ передачи данных. Метод доступа
921
вести к бесконечному зацикливанию. Агент пользователя, который
получает устаревший отклик без заголовка Warning, может отобра-
зить предупреждение для пользователя.
12.1.2. Предупреждения
Когда кэш присылает опосредованный отклик, который "недоста-
точно свеж” (с точки зрения условия 2 раздела 12.1.1), к нему долж-
но быть присоединено предупреждение об этом с использованием
заголовка Warning. Это предупреждение позволяет клиентам пред-
принять соответствующие действия. Предупреждения могут исполь-
зоваться и для других целей, как кэшами, так и другими системами.
Использование предупреждения, а не статусного кода ошибки, отли-
чает эти отклики от действительных отказов в системе.
Предупреждения всегда допускают кэширование, так как они
никогда не ослабляют прозрачности отклика. Это означает, что пре-
дупреждения могут передаваться НТТР/1.0 кэшам без опасения,
что такие кэши просто передадут их как заголовки объектов откли-
ка. Предупреждениям приписаны номера в интервале от 0 до 99.
Данная спецификация определяет номера кодов и их значения для
каждого из предупреждений, позволяя клиенту или кэшу обеспе-
чить во многих случаях (но не во всех) автоматическую обработку
ситуаций.
Предупреждения несут в себе помимо кода и текст. Текст может
быть написан на любом из естественных языков (предположитель-
но базирующемся на заголовках Accept клиента) и включать в себя
опционное указание того, какой набор символов используется. К
отклику может быть присоединено несколько предупреждений (ис-
ходным сервером или кэшем), включая несколько предупреждений
с идентичным кодом. Например, сервер может выдать одно и то же
предупреждение на английском и мордовском.
Когда к отклику присоединено несколько предупреждений, не
будет практичным и разумным отображать их все на экране для
пользователя. Эта версия HTTP не специфицирует строгих правил
приоритета для принятия решения, какие предупреждения отобра-
жать и в каком порядке, но предлагает некоторые эвристические
соображения. Заголовок Warning и определенные в настоящий мо-
мент предупреждения описаны в разделе 13.45.
12.1.3. Механизмы управления кэшем
Базовым механизмом кэша в НТТР/1.1 (времена таймаутов и
пР°верки) являются неявные директивы кэша. В некоторых случа-
922
Гпава$
ях серверу или клиенту может потребоваться выдать прямую
рективу кэшу. Для этих целей используется заголовок Cache-Control.
Заголовок Cache-Control позволяет клиенту или серверу пер^
дать большое число директив через запросы или отклики. Эти дцч
рективы переписывают указания, которые действуют по умолчанию
при реализации алгоритма работы кэша. Если возникает явный
конфликт между значениями заголовков, то используется наиболее
регламентирующее требование (то есть, то, которое наиболее вероят-
но сохраняет прозрачность семантики).
Однако в некоторых случаях директивы Cache-Control сформу.
лированы так, что явно ослабляют семантическую прозрачность (на-
пример, "max-stale" или "public"). Директивы Cache-Control подроб-
но описаны в разделе 13.9.
12.1.4. Прямые предупреждения агента пользователя
Многие агенты пользователя позволяют переписывать базовый
механизм кэширования. Например, агент пользователя может спе-
цифицировать то, какие кэшированные объекты (даже явно старые)
не проверять на новизну. Или агент пользователя может всегда
добавлять "Cache-Control: max-stale=3600" к каждому запросу.
Если пользователь переписал базовый механизм кэширования,
агент пользователя должен явно указать всякий раз, когда это важ-
но, что отображаемая информация не отвечает требованиям про-
зрачности (в частности, если отображаемый объект известен как
устаревший). Так как протокол обычно разрешает агенту пользова-
теля определять, является ли отклик устаревшим, такая индикация
нужна только тогда, когда это действительно случится. Для такой
индикации не нужно диалоговое окно; это может быть иконка (на-
пример, изображение гнилой рыбы) или какой-то иной визуальный
индикатор.
Если пользователь переписал механизм кэширования таким
образом, что он непомерно понизил эффективность кэша, агент пользо-
вателя должен непрерывно отображать индикацию (например, изоб-
ражение горящих денег), так чтобы пользователь, беспечно расходу-
ющий ресурсы, страдал от заметной задержки откликов на его дей'
ствия.
12.1.5. Исключения для правил и предупреждений
В некоторых случаях оператор кэша может выбрать такую кон-
фигурацию, которая возвращает устаревшие отклики, даже если кли-
енты этого не запрашивали. Это решение не должно приниматься
легко, но может быть необходимо по причинам доступности илИ
эффективности, особенно когда кэш имеет плохую связь с исхбД'
0ети передачи данных. Метод доступа 923
ЙЬ1М сервером. Всякий раз, когда кэш возвращает устаревший от-
клик, он должен пометить его соответствующим образом (исполь-
зуя заголовок Warning). Это позволяет клиентскому программному
обеспечению предупредить пользователя о возможных проблемах.
Такой подход позволяет также агенту пользователя предпри-
нять шаги для получения "свежего” отклика или информации из
первых рук. По этой причине кэшу не следует присылать устарев-
шие отклики, если клиент запрашивает информацию из первых рук,
если только невозможно это сделать по техническим или полити-
ческим причинам.
12.1.6. Работа под управлением клиента
Когда основным источником устаревшей информации является
исходный сервер (и в меньшей мере промежуточные кэши), клиенту
может быть нужно контролировать решение кэша о том, следует ли
присылать кэшированный отклик без его проверки. Клиенты вы-
полняют это, используя несколько директив заголовка Cache-Control.
Запрос клиента может специфицировать максимальный возраст,
который он считает приемлемым для не верифицированного откли-
ка. Клиент может также специфицировать минимальное время, в
течение которого отклик еще считается пригодным для использо-
вания. Обе эти опции увеличивают ограничения, накладываемые на
работу кэша.
Клиент может также специфицировать то, что он будет воспри-
нимать устаревшие отклики с возрастом не более заданного. Это
ослабляет ограничения, налагаемые на работу кэшей и, таким обра-
зом, может привести к нарушению семантической прозрачности, за-
данной исходным сервером, хотя это может быть необходимо для
поддержания автономной работы кэша в условиях плохой коннек-
тивности.
12.2. Модель истечения срока годности
12.2.1. Определение срока годности под управлением сервера
Кэширование в HTTP работает наилучшим образом, когда кэши
могут полностью исключить запросы к исходному серверу. Другими
словами, кэш должен возвращать ’’свежий" отклик без обращения
к серверу.
Предполагается, что серверы припишут в явном виде значения
времени пригодности (expiration time) откликам в предположении,
что объекты вряд ли изменятся семантически значимым образом
до истечения этого времени. Это сохраняет семантическую прозрач-
ность при условии, что время жизни выбрано корректно.
324
Гпава 4
Механизм времени пригодности применим только к откликам,
взятым из кэша, а не к откликам, полученным из первых рук и
переадресованных запрашивающему клиенту.
Если исходный сервер хочет усилить семантическую прозрач-
ность кэша, тогда он может установить время истечения действия в
прошлое, чтобы проверялся каждый запрос. Это означает, что вся-
кий запрос изначально будет считаться устаревшим, и кэш будет
вынужден проверить его, прежде чем использовать для последую-
щих запросов. О более жестких методах вынуждения проверки дей-
ственности отклика смотри раздел 13.9.4.
Если исходный сервер хочет заставить любой НТТР/1.1 кэш,
вне зависимости от его конфигурации проверять каждый запрос, он
может использовать директиву Cache-Control ”must-revalidate" (см.
раздел 13.9). Серверы определяют реальные времена сроков пригод-
ности, используя заголовок Expires, или директиву максимального
возраста заголовка Cache-Control.
Время пригодности не может использоваться для того, чтобы
заставить агента пользователя обновить картинку на дисплее или
перезагрузить ресурс. Его семантика применима исключительно для-
механизма кэширования, а такой механизм нуждается только в
контроле истечения времени пригодности ресурса, когда иницииру-
ется новый запрос.
12.2.2. Эвристический контроль пригодности
Так как исходные сервера не всегда предоставляют значение
времени пригодности в явном виде, HTTP кэши присваивают им
значения эвристически, используя алгоритмы, которые привлекают
для оценки вероятного значения времени пригодности другие заго-
ловки (такие как Last-Modified time). Спецификация НТТР/1.1 не
предлагает каких-либо специальных алгоритмов, но налагает пре-
дельные ограничения на полученный результат. Так как эвристи-
ческие значения времени пригодности могут подвергнуть риску се-
мантическую прозрачность, они должны использоваться с осторож-
ностью. Предпочтительнее, чтобы исходные серверы задавали время
пригодности явно.
12.2.3. Вычисление возраста
Для того чтобы узнать является ли запись в кэш свежей, кэшу
нужно знать превышает ли ее возраст предельное время жизни. То, *
как вычислить время жизни, обсуждается в разделе 12.2.4. Этот
раздел описывает метод вычисления возраста отклика или записи в
кэше.
Сети передачи данных. Метод доступа
925
В этом обсуждении используется термин "сейчас” для обозначе-
ния ’’текущего показания часов на ЭВМ, выполняющей вычисле-
ние”. ЭВМ, которая использует HTTP, и в особенности ЭВМ, работа-
ющие в качестве исходных серверов и кэшей, должны использовать
^ТР [28] или некоторый схожий протокол для синхронизации их
часов с использованием общего точного временного стандарта.
Следует обратить внимание на то, что НТТР/1.1 требует от ис-
ходного сервера посылки в каждом отклике заголовка Date, сооб-
щая время, когда был сгенерирован отклик. Мы используем термин
”date_value” для обозначения значения заголовка Date, в форме, при-
емлемой для арифметических операций.
НТТР/1.1 использует заголовок отклика Age для того, чтобы
облегчить передачу информации о возрасте объектов между кэша-
ми. Значение заголовка Age равно оценке отправителя времени, про-
шедшего с момента генерации отклика исходным сервером. В слу-
чае кэшированного отклика, который был перепроверен исходным
сервером, значение Age базируется на времени перепроверки, а не на
времени жизни оригинального отклика.
По существу значение Age равно сумме времени, в течение кото-
рого отклик был резидентен в каждом из кэшей вдоль пути от
исходного сервера, плюс время распространения данных по сети.
Мы используем термин ”age_value" для значения поля заголов-
ка Age, в удобном для выполнения арифметических операций фор-
мате. Возраст отклика может быть вычислен двумя совершенно
независимыми способами.
• Текущее время минус date_value, если местные часы синхро-
низованы с часами исходного сервера. Если результат отрицателен,
он заменяется на нуль.
• age_value, если все кэши вдоль пути отклика поддерживают
НТТР/1.1.
Таким образом, мы имеем два независимых способа вычисления
возраста отклика при его получении, допускается их комбинирова-
ние, например:
corrected_received_age = max((now — date_value), age_value)
и, поскольку мы имеем синхронизованные часы, или все узлы вдоль
пути поддерживают НТТР/1.1, получается надежный (консерватив-
ный) результат.
Заметьте, что поправка применяется в каждом кэше НТТР/1.1
вДоль пути так, что, если встретится на пути кэш НТТР/1.0, пра-
вильное значение возраста будет получено потому, что его часы по-
Э26 ' Глава 4 f
чти синхронизованы. Нам не нужна сквозная синхронизация (хотя
ее не плохо бы иметь).
Из-за задержек, вносимых сетью, значительное время может прой- 1
ти с момента генерации отклика сервером и получением его следу-
ющим кэшем или клиентом. Если не внести поправки на эту за-
держку, можно получить неправдоподобные значения возраста от-
клика.
Так как запрос, который определяет возвращаемое значение Age, /
должен быть инициирован до генерации этого значения Age, мы
можем сделать поправку на задержки, вносимые сетью путем запи-
си времени, когда послан запрос. Затем, когда получено значение
Age, оно должно интерпретироваться относительно времени посыл-
ки запроса, а не времени когда был получен отклик. Этот алгоритм
выдает результат, который не зависит от величины сетевой задерж-
ки. Таким образом, вычисляется:
corrected-initial_age = corrected_received_age + (now — request_time)
где "request_time” равно времени (согласно местным часам), когда
был послан запрос, вызвавший данный отклик.
Резюме алгоритма вычисления возраста при получении отклика
кэшем:
/*
* age_value | равно значению Age: поле заголовока,
| полученного кэшем с этим откликом.
* date—value | равно значению поля Date заголовка,
| сформированного исходным сервером
* request-time | равно местному времени, когда кэш сделал
| запрос, который явился причиной этого
| кэшированного отклика
*response_time| равно местному времени, когда кэш получил
| отклик
* now | равно текущему (местному) времени
*/
apparent age = max(0, (response_time — date_value));
corrected—received—age = max(apparent_age, age—value);
response_delay = response-time — requesttime;
corrected—initial—age == corrected-received-age + resporise_delay;
resident-time = now — response_time;
currentage = corrected_initial_age + resident—time;
Сети передачи данных. Метод доступа
927
Когда кэш посылает отклик, он должен добавить к correctedinitialage
время, в течение которого отклик оставался резидентно локальным.
Он должен ретранслировать этот полный возраст, используя заголо-
вок Age, следующему кэшу-получателю.
Заметьте, что клиент не может надежно сказать, что отклик
получен из первых рук, но присутствие заголовка Age определенно
указывает на то, что это не так. Кроме того, если значение в откли-
ке соответствует более раннему времени, чем местное время запроса
клиента, отклик, вероятно, получен не из первых рук (в отсутствии
серьезного сбоя часов).
12.2.4. Вычисление времени жизни
Для того чтобы решить, является ли отклик свежим или уста-
ревшим, нам нужно сравнить его время жизни с возрастом. Возраст
вычисляется так, как это описано в разделе 12.2.3. Этот раздел
описывает то, как вычисляется время жизни, и как определяется,
истекло ли время жизни отклика. В обсуждении, приведенном ниже,
величины могут быть представлены в любой форме, удобной для
выполнения арифметических операций.
Мы используем термин ’’expires_value" для обозначения содер-
жимого заголовка Expires. Для обозначения числа секунд, опреде-
ленного директивой максимального возраста заголовка Cache-Control
отклика (см. раздел 13.9), используется термин ”max_age_value".
Директива максимального возраста имеет приоритет перед Expires,
так если max-age присутствует в отклике, вычисление производится
просто:
freshness_lifetime = max_age_value
В противном случае, если в отклике присутствует Expires, то
вычисления осуществляются следующим образом:
freshness_lifetime = expires_value — date_value
Заметьте, ни одно из этих вычислений не зависит от синхрони-
зации и корректной работы местных часов, так как вся исходная
информация получается от исходного сервера.
Если ни Expires, ни Cache-Control:max-age не определяют макси-
мальный возраст отклика, а отклик не содержит других ограниче-
ний на кэширование, кэш может вычислить время жизни, исполь-
зуя эвристику. Если эта величина больше 24 часов, кэш должен
присоединить к отклику Warning 13, если такое предупреждение
еЩе не добавлено.
928
Гпава 4
Кроме того, если отклик имеет время Last-Modified, эвристичес-
кое значение времени жизни должно быть не больше некоторой
доли времени, прошедшего со времени модификации. Типичное зна-
чение этой доли может составлять 10%.
Расчет того, истекло ли время жизни отклика, достаточно прост:
response is__fresh = (freshness_lifetime > current_age)
12.2.5. Устранение неопределенности значений времени жизни
Из-за того, что значения времени жизни часто назначаются оп-
тимистически, может случиться, что два кэша содержат две ’’све-
жих” записи одного и того же ресурса, которые различаются.
Если клиент, выполняя извлечение ресурса, получает отклик не
из первых рук на запрос, который был свежим в своем собственном
кэше, а заголовок Date в его кэше новей, чем Date нового отклика,
тогда клиент может игнорировать этот отклик. Если это так, он
может повторить запрос с директивой "Cache-Control: max-age=0”
(см. раздел 13.9), чтобы усилить контроль со стороны исходного
сервера.
Если кэш имеет два свежих отклика для одного и того же пред-
ставления с различными указателями корректности (validator), он
должен использовать тот, который имеет современный заголовок
Date. Эта ситуация может возникнуть, когда кэш извлекает отклик
из других кэшей, или потому, что клиент запросил перезагрузку или
повторную проверку корректности заведомо свежего объекта.
12.2.6. Неопределенность из-за множественных откликов
Из-за того, что клиент может получать отклики по большому ’
числу различных маршрутов, так что некоторые отклики проходят
через одну последовательность кэшей, а другие, через другую, клиент
может получить их не в той последовательности в какой они были
посланы исходным сервером. Хотелось бы, чтобы клиент использо-
вал наиболее свежие оклики, даже если срок годности старых еще
не истек.
Ни метка объекта, ни значение времени жизни не могут опреде-
лять порядок откликов, так как возможно, что более поздний от-
клик имеет срок годности, который истекает раньше. Однако, специ-
фикация НТТР/1.1 требует передачи заголовка Date в каждом от-
клике, а значения Date должны быть кратны одной секунде.
Когда клиент пытается перепроверить запись в кэше, а отклик,
который он получает, содержит заголовок Date, который оказывает-
Сети передачи данных. Метод доступа
929
ся старше, чем у другой уже существующей записи, тогда клиенту
следует безусловно повторить запрос и включить в него запись:
Cache-Control: max-age=0
Чтобы заставить некоторые промежуточные кэши сверить свои
копии непосредственно с исходным сервером, или
Cache-Control: no-cache
Чтобы заставить любые промежуточные кэши получит новые
копии от исходного сервера.
Если значения Date равны, тогда клиент может использовать
любой отклик (или может, если он особенно осторожен, затребовать
новый отклик). Серверы не должны зависеть от возможности клиен-
тов выполнить четкий выбор между откликами, сгенерированными в
пределах одной и той же секунды, если их сроки пригодности пере-
крываются.
12.3. Модель проверки пригодности
Когда кэш имеет устаревшую запись, которую бы он хотел ис-
пользовать в качестве отклика на запрос клиента, он сначала дол-
жен произвести сверку с базовым сервером (или возможно проме-
жуточным кэшем, содержащим свежий отклик), чтобы убедиться,
что кэшированная запись все еще применима. Это называется про-
веркой пригодности записи кэша ("validating”). Так как мы не хо-
тим пересылки всей записи, если с ней все в порядке, и мы не хотим
тратить лишнее время из-за RTT в случае, если запись более не
пригодна, протокол НТТР/1.1 поддерживает использование услов-
ных методов.
Ключевой особенностью протокола для поддержки условных
методов являются так называемые "валидаторы" кэша. Когда ис-
ходный сервер генерирует полный отклик, он Подключает к нему
некоторые виды валидаторов, которые хранятся вместе с самой за-
писью в кэше. Когда клиент (агент пользователя или проксй-кэш)
выполняет условный запрос ресурса, для которого он имеет запись в
кэше, он добавляет соответствующий валидатор к запросу.
Сервер сверяет полученный валидатор с текущим валидатором
объекта и, если они совпадают, посылается отклик с соответствую-
щим статусным кодом (обычно, 304 (Not Modified)) и без тела
объекта. В противном случае он возвращает полный отклик (вклю-
чая тело объекта). Таким образом, мы избегаем передачи полного
отклика, если валидаторы взаимно согласованы.
30 Зак. № 3430 Семенов
930 Глава 4 £
В НТТР/1.1 условный запрос выглядит точно также как и обыч-
ный запрос того же самого ресурса, за исключением того, что он
несет в себе специальный заголовок (который содержит валидатор),
и неявно меняет метод (обычный GET) на условный.
Протокол предусматривает как положительное, так и отрица-
тельное значения условий проверки пригодности записей кэша. То
есть, можно потребовать, чтобы был реализован этот метод тогда и
только тогда, когда валидатор подходит, или тогда и только тогда,
когда ни один валидатор не подходит.
Отклик, который не имеет валидатора, может кэшироваться и
использоваться до истечения его срока годности, если только это
явно не запрещено директивой Cache-Control. Однако кэш не может
выполнить условную доставку ресурса, если он не имеет валидатора
для запрашиваемого объекта, что означает отсутствие возможности
его актуализации после истечения срока годности.
12.3.1. Даты последней модификации
Значение поля заголовка объекта Last-Modified часто использу-
ется кэшем в качестве валидатора. Иными словами, запись в кэше
рассматривается как пригодная, если объект не был модифицирован
с момента, указанного в Last-Modified.
12.3.2. Валидаторы кэша для меток объектов
Значение поля заголовка объекта ETag (Entity Tag - метка объек-
та), представляет собой ’’непрозрачный’’ валидатор кэша. Это может
гарантировать большую надежность при контроле пригодности в си-
туациях, когда неудобно запоминать модификации дат, где недоста-
точно односекундного разрешения для значения даты HTTP или где
исходный сервер хочет избежать определенных парадоксов, которые
могут возникнуть от использования дат модификации. Метки объек-
та обсуждаются в разделе 2.11. Заголовки, используемые с метками
объектов, рассмотрены в разделах 13.20, 13.25, 13.26 и 13.43.
12.3.3. Слабые и сильные валидаторы
Так как исходные серверы и кэши будут сравнивать два валида-
тора, чтобы решить, представляют ли они один и тот же объект,
обычно подразумевается, что, если объект (тело объекта или любой
заголовок) изменяется каким-либо образом, то и сопряженный ва-
лидатор изменится. Если это так, валидатор называется ’’сильным •
Однако могут встретиться случаи, когда сервер предпочитает из-
менять валидатор только при семантически существенных измене-
Сети передачи данных. Метод доступа
931
ниях. Валидатор, который не изменяется всякий раз при изменении
ресурса, называется "слабым".
Метки объекта обычно являются "сильными валидаторами", но
протокол предлагает механизм установки "слабой" метки объекта.
Можно считать, что сильный валидатор это такой, который изменя-
ется,-если меняется хотя бы один бит в объекте, в то время как
значение слабого изменяется при вариации значения объекта. Аль-
тернативой можно считать точку зрения, при которой сильный ва-
лидатор является частью идентификатора конкретного объекта, в
то время как слабый валидатор является частью идентификатора
набора семантически эквивалентных объектов.
Примером сильного валидатора является целое число, которое
увеличивается на единицу всякий раз, когда в объект вносится ка-
кое-либо изменение.
Время модификации объекта при односекундном разрешении
может быть лишь слабым валидатором, так как имеется возмож-
ность того, что ресурс может быть модифицирован дважды в течение
одной и той же секунды. Поддержка слабых валидаторов является
опционной. Однако слабый валидатор позволяет более эффективно
кэшировать эквивалентные объекты.
Валидатор используется либо, когда клиент генерирует запрос и
включает валидатор в поле заголовка проверки годности, или когда
сервер сравнивает два валидатора. Сильные валидаторы могут ис-
пользоваться в любом контексте. Слабые валидаторы применимы
только в контексте, который не зависит от точной эквивалентности
объектов. Например, как один, так и другой вид валидаторов приме-
ним для условного GET. Однако только сильный валидатор приме-
ним для фрагментированного извлечения ресурсов, так как в про-
тивном случае клиент может прервать работу с внутренне противо-
речивым объектом.
Единственной функцией протокола НТТР/1.1, определенной для
валидаторов, является сравнение. Существует две функции сравне-
ния валидаторов, в зависимости от того, допускает ли контекст ис-
пользование слабых валидаторов или нет:
• Функция сильного сравнения. Для того чтобы считаться рав-
ными оба валидатора должны быть идентичными, и не один из них
не должен быть слабым.
• Функция слабого сравнения. Для того чтобы считаться рав-
ными оба валидатора должны быть идентичными, но либо оба, либо
один из них могут иметь метку "слабый" без какого-либо воздей-
ствия на результат.
932
Гпава 4
Функция слабого сравнения может быть использована для про-
стых GET-запросов. Функция сильного сравнения должна быть ис-
пользована во всех прочих случаях.
Метка объекта является сильной, если она не помечена явно как
слабая. В разделе 2.11 рассматривается синтаксис меток объектов.
Параметр Last-Modified time, при использовании в качестве ва-
лидатора запроса, подразумевается слабым, если не возможно уста-
новить, что он сильный, используя следующие правила.
• Валидатор сравнивается исходным сервером с текущим ра-
бочим валидатором для данного объекта и,
• исходный сервер твердо знает, что соответствующий объект не
изменялся дважды за секунду, к которой привязан настоящий ва-
лидатор.
Или
• валидатор предполагается использовать клиентом в заголов-
ке If-Modified-Since или If-Unmodified-Since, так как клиент имеет
запись в кэше для соответствующего объекта, и
• эта запись в кэш включает в себя значение Date, которое опре-
деляет время, когда исходный сервер послал оригинал запроса, и
• предлагаемый параметр Last-Modified time соответствует мо-
менту времени, по крайней мере, на 60 секунд раньше значения Date,
или
• валидатор сравнивается промежуточным кэшем с валидато-
ром, запомненным в записи для данного объекта, и
• эта запись в кэше включает в себя значение Date, которое опре-
деляет время, когда исходный сервер послал оригинал запроса, и
• предлагаемый параметр Last-Modified time соответствует мо-
менту времени, по крайней мере, на 60 секунд раньше значения Date.
Этот метод базируется на том факте, что, если два различных
отклика были посланы исходным сервером в пределах одной и той
же секунды, но оба имеют одно и то же время Last-Modified, тогда,
по крайней мере, один из этих откликов имеет значение Date равное
его времени Last-Modified. Произвольный 60-секундный лимит пре-
дохраняет против возможности того, что значения Date и Last-Modified
сгенерированы с использованием различных часов или в несколько
разные моменты времени при подготовке отклика. Конкретная реа-
лизация может использовать величину больше 60 секунд, если счи-
тается, что 60 секунд слишком мало.
Кэш или исходный сервер, получающий условный запрос кэша,
отличный от GET-запроса, должен использовать функцию сильного
сравнения, чтобы оценить условие.
Сети передачи данных. Метод доступа
933
Эти правила позволяют кэшам НТТР/1.1 и клиентам безопас-
но произвести фрагментный доступ к ресурсам для значений, кото-
рые получена от серверов HTTP/1.0.
12.3.4 . Правила того, когда использовать метки объекта и
даты последней модификации
Мы принимаем набор правил и рекомендаций для ’исходных
серверов, клиентов и кэшей относительно того, когда должны ис-
пользоваться различные типы валидаторов.
Исходный сервер НТТР/1.1:
• Должен послать валидатор метки объекта, если только воз-
можно его сгенерировать.
• Может послать слабую метку объекта вместо сильной, если
такая возможность предусмотрена, а послать сильную метку объек-
та невозможно.
• Должен послать значение Last-Modified, когда это возможно
сделать, если только риск нарушения семантической прозрачности,
который может явиться следствием использования этой даты в
заголовке, не приведет к серьезным проблемам.
Другими словами предпочтительным поведением для исходного
сервера НТТР/1.1 является посылка сильной метки объекта и зна-
чения Last-Modified.
Для сохранения легальности сильная метка объекта должна
изменяться всякий раз, когда каким-либо образом меняется ассо-
циированное значение объекта. Слабую метку объекта следует ме-
нять всякий раз, когда соответствующий объект изменяется семан-
тически значимым образом. \
Для того, чтобы обеспечить семантически прозрачное кэширова-
ние, исходный сервер должен избегать повторного использования спе-
цифических, сильных меток для двух разных объектов, или повтор-
ного использования специфических, слабых меток для двух семанти-
чески разных объектов. Записи в кэш могут существовать сколь
угодно долгое время вне зависимости от времени годности. Таким
образом, может оказаться неразумным ожидать, что кэш никогда
вновь не попытается перепроверить запись, используя валидатор, ко-
торый он получил в какой-то момент в прошлом.
Клиенты НТТР/1.1 должны следовать ниже приведенным пра-
вилам:
• Если метка объекта была прислана исходным сервером, эта
метка должна быть использована в любом условном запросе кэша
(с If-Match или If-None-Match).
934 Глава 4 |
——-----J
. Если только значение Last-Modified было прислано исход-
дым сервером, оно должно использоваться в нефрагментных, у слов- :
ных запросах кэша (с использованием If-Modified-Since).
• . Если значение Last-Modified было прислано исходным серве-
ром НТТР/1.0, оно может использоваться во фрагментных, услов-
ных запросах кэша (с использованием If-Unmodified-Since:). Аген-
ту пользователя следует обеспечить способ блокировки этого в слу-
чае возникновения трудностей.
• Если и метка объекта и значение Last-Modified были присла-
ны исходным сервером, в условных запросах кэша следует исполь-
зовать оба валидатора. Это позволяет корректно реагировать кэ-
шам, поддерживающим как НТТР/1.0, так и НТТР/1.1.
Кэш НТТР/1.1 при получении запроса должен использовать
наиболее регламентирующий валидатор, когда проверяется, соответ-
ствуют ли друг другу запись в буфере клиента и собственная запись
в кэше. Это единственный выход, когда запрос содержит как метку
объекта, так и валидатор last-modified-date (If-Modified-Since или
If-Unmodified-Since).
Базовым принципом всех этих правил является то, что HTTP/
1.1 серверы и клиенты должны пересылать как можно больше на-
дежной информации в своих запросах и откликах. НТТР/1.1 сис-
темы, принимая эту информацию, используют наиболее консерва-
тивное предположение относительно валидаторов, которые они по-
лучают.
Клиенты НТТР/1.0 и кэши будут игнорировать метки объек-
тов. Вообще, значения времени последней модификации, получен-
ные или используемые этими системами, будут поддерживать про-
зрачное и эффективное кэширование и, по этой причине, исходные
серверы НТТР/1.1 должны присылать значения параметров Last-
Modified. В тех редких случаях, когда системой НТТР/1.0 в каче-
стве валидатора используется значение Last-Modified, могут возник-
нуть серьезные проблемы, и тогда исходные серверы НТТР/1.1 при-
сылать их не должны.
12.3.5 . Условия пригодности
Принцип использования меток объектов базируется на том, что
только автор услуг знает семантику ресурсов достаточно хорошо, что-
бы выбрать подходящий механизм контроля кэширования. Специ-
фикация любой функции сравнения валидаторов более сложна, чем
сравнение байтов. Таким образом, для целей проверки пригодности
записи в кэше никогда не используется сравнение любых других
заголовков кроме Last-Modified, для совместимости с НТТР/1.0.
Сети передачи данных. Метод доступа
935
12.4. Кэшируемость отклика
Если только нет специального ограничения директивой Cache-
Control (раздел 13.9), система кэширования может всегда запоми-
нать отклик (см. раздел 12.8). Она может прислать его без провер-
ки пригодности, если он является свежим, и может послать его пос-
ле успешной проверки пригодности. Если нет ни валидатора кэша,
ни времени пригодности, ассоциированного с этим откликом, мы не
ожидаем, что такой отклик будет кэширован, но некоторые кэши
могут нарушить это правило (например, когда имеется плохая кон-
нективность или она вообще отсутствует). Клиент обычно может
детектировать, что такой отклик был взят из кэша после сравнения
заголовка Date с текущим временем.
Заметьте, что некоторые кэши НТТР/1.0 нарушают эти правила,
даже не прйсылая предупреждения.
Однако в некоторых случаях может быть неприемлемо для кэша
сохранять объект или присылать его в ответ на последующие зап-
росы. Это может быть потому, что автор сервиса полагает необходи-
мой абсолютную семантическую прозрачность по соображениям бе-
зопасности или конфиденциальности. Определенные директивы Cache-
Control предназначены для того, чтобы сервер мог указать, что
некоторые объекты ресурсов или их части не могут кэшироваться
ни при каких обстоятельствах.
Заметьте, что раздел 13.8 в норме препятствует кэшу запоми-
нать и отсылать отклик на предыдущий запрос, если этот запрос
включает в себя заголовок авторизации.
Отклик, полученный со статусным кодом 200, 203, 206, 300, 301
или 410, может быть запомнен кэшем и использован в ответе на
последующие запросы, если директива не препятствует кэширова-
нию. Однако, кэш, который не поддерживает заголовки Range и
Content-Range не должен кэшировать отклики 206 (Partial Content).
Отклик, полученный с любым другим статусным кодом, не дол-
жен отсылаться в ответ на последующие запросы, если только нет
директив Cache-Control или других заголовков, которые напрямую
разрешают это. К таким, например, относятся: заголовок Expires
(раздел 13.21); "max-age”, ”must-revalidate”, ’’proxy-revalidate",
’’public" или "private” директива Cache-Control (раздел 13.9).
12.5. Формирование откликов в кэшах
Целью кэша HTTP является запоминание информации, полу-
ченной в откликах на запросы, для использования в ответ на буду-
щие запросы. Во многих случаях, кэш просто отсылает соответству-
936
Гпава 4
ющие части отклика отправителю запроса. Однако если кэш содер-
жит объект, базирующийся на предшествующем отклике, он может
быть вынужден комбинировать части нового отклика с тем, что
хранится в объекте кэша.
12.5.1. Заголовки End-to-end (точка-точка)
и Hop-by-hop (шаг-за-шагом)
Для целей определения поведения кэшей и некэшурующих про-
кси-серверов, заголовки HTTP делятся на две категории:
• Заголовки End-to-end, которые должны быть пересланы ко-
нечному получателю запроса или отклика. Заголовки End-to-end в
откликах должны запоминаться как часть объекта кэша и пересы-
латься в любом отклике, полученном из записи кэша.
• Заголовки Hop-by-hop, которые имеют смысл только для од-
ноуровневого транспортного соединения не запоминаются кэшем и
не переадресуются прокси-серверами.
Следующие заголовки НТТР/1.1 относятся к категории hop-by-hop:
• Connection
• Keep-Alive
• Public
• Proxy-Authenticate /
• Transfer-Encoding
• Upgrade
Все другие заголовки, определенные НТТР/1.1 относятся к ка-
тегории end-to-end. Заголовки Hop-by-hop, вводимые в будущих вер-
сиях HTTP, должны быть перечислены в заголовке Connection, как
это описано в разделе 13.10.
12.5.2. Немодифицируемые заголовки
Некоторые черты протокола НТТР/1.1, такие как Digest
Authentication, зависят от значения определенных заголовков end-
to-end. Кэш или некэширующий прокси не должны модифициро-
вать заголовок end-to-end, если только определение этого заголовка
не требует или не разрешает этого.
Кэш или некэширующий прокси не должны модифицировать
любое из следующих полей запроса или отклика или добавлять
какие-либо поля, если они еще не существуют:
• Content-Location
• Etag
• Expires
• Last-Modified
Сети передачи данных. Метод доступа
937
Кэш или некэширующий прокси не должны модифицировать
или добавлять следующие поля в любых запросах и в откликах,
которые содержат директиву no-transform Cache-Control:
• Content-Encoding
• Content-Length
• Content-Range
• Content-Type
Кэш или некэширующий прокси могут модифицировать или до-
бавлять эти поля в отклик, который не включает директиву no-
transform. Если же он содержит эту директиву, следует добавить
предупреждение 14 (Transformation applied), если оно еще не занесе-
но в отклик.
Предупреждение. Ненужная модификация заголовков end-to-end
может вызвать отказы в авторизации, если в поздних версиях HTTP
использован более строгий механизм.
12.5.3. Комбинирование заголовков
Когда кэш делает запрос серверу о пригодности ресурса и сервер
выдает отклик 304 (Not Modified), кэш должен подготовить и от-
править отклик клиенту. Кэш использует тело объекта из кэша
при формировании отклика. Заголовки end-to-end записи кэша, ис-
пользуются при создании отклика. Исключение составляют любые
end-to-end заголовки, поступившие в рамках отклика 304, они дол-
жны заместить соответствующие заголовки записи в кэше. Если
только кэш не решил удалить запись, он должен заменить end-to-
end заголовки в записи соответствующими заголовками из полу-
ченного отклика.
Другими словами, набор end-to-end заголовков, полученный вме-
сте откликом переписывает Все соответствующие end-to-end заго-
ловки, из записи кэша. Кэш может добавить к этому набору заго-
ловки предупреждений (см. раздел 13.45).
Если имя поля заголовка приходящего отклика соответствует
более чем одной записи в кэше, все старые заголовки заменяются.
Это правило позволяет исходному серверу использовать отклик
304 (Not Modified) для актуализации любого заголовка, связанного
с предыдущим откликом для того же объекта, хотя это может не
всегда иметь смысл. Это правило не позволяет исходному серверу
использовать отклик 304 (not Modified) для того, чтобы полностью
стереть заголовок, который был прислан предыдущим откликом.
938
Гпава 4
12.5.4. Комбинирование байтовых фрагментов
Отклик может передать только субдиапазон байтов тела объек-
та, либо потому, что запрос включает в себя один или более специ-
фикаций Range, либо из-за преждевременного обрыва соединения.
После нескольких таких передач кэш может получить несколько
фрагментов тела объекта.
Если кэш запомнил не пустой набор субфрагментов объекта, а
входящий отклик передает еще один фрагмент, кэш может комби-
нировать новый субфрагмент с уже имеющимся набором, если для
обоих выполняются следующие условия:
• Оба приходящие отклика и запись в кэше должны иметь ва-
лидатор кэша.
• Оба валидатора кэша должны соответствовать функции силь-
ного сравнения (см. раздел 12.3.3).
Если любое из условий не выполнено, кэш должен использовать
только наиболее поздний частичный отклик и отбросить другую
частичную информацию.
12.6. Кэширование согласованных откликов
Использование согласования содержимого под управлением сер-
вера (раздел 11), что индицируется присутствием поля заголовка
Vary в отклике, изменяет условия и процедуру, при которой кэш
может использовать отклик для последующих запросов.
Сервер должен использовать поле заголовка Vary (раздел 13.43),
чтобы информировать кэш о том, какие пределы для поля заголов-
ка используются при выборе представления кэшируемого отклика.
Кэш может использовать выбранное представление для ответов на
последующие запросы, только когда они имеют те же или эквива-
лентные величины полей заголовка, специфицированных в заголов-
ке отклика Vary. Запросы с различными значениями одного или
нескольких полей заголовка следует переадресовывать исходному
серверу.
Если представлению присвоена метка объекта, переадресуемый
запрос должен быть условным и содержать метки в поле заголовка
If-None-Match всех его кэшированных записей для заданного Request-
URI. Это сообщает серверу набор объектов, которые в настоящее
время хранятся в кэше, так что, если любая из этих записей соот-
ветствует запрашиваемому объекту, сервер может использовать за-
головок ETag в своем отклике 304 (Not Modified), чтобы сообщить
кэшу, какой объект подходит. Если метка объекта нового отклика
соответствует существующей записи, новый отклик должен быть
Сети передачи данных. Метод доступа
939
использован для актуализации полей заголовка существующей за-
писи, а результат должен быть прислан клиенту.
Поле заголовка Vary может также информировать кэш, что
представление было выбрано с использованием критериев неогра-
ниченных заголовками запросов. В этом случае, кэш не должен
использовать отклик в ответ на последующий запрос, если только
кэш не передает исходному серверу условный запрос. Сервер при
этом возвращает отклик 304 (Not Modified), включая метку объек-
та или поле Content-Location, которые указывают, какой объект дол-
жен быть использован.
Если какая-то запись кэша содержит только часть информации
для соответствующего объекта, его метка не должна содержаться в
заголовке If-None-Match, если только запрос не лежит в диапазоне,
который полностью покрывается этим объектом.
Если кэш получает позитивный отклик с полем Content-Location,
соответствующим записи в кэше для того же Request-URI, с меткой
объекта, отличающейся от метки существующего объекта, и датой
современнее даты существующего объекта, данная запись не должна
использоваться в качестве отклика для будущих запросов и долж-
на быть удалена из кэша.
12.7. Кэши коллективного и индивидуального использования
По причинам безопасности и конфиденциальности необходимо
делать различие между кэшами совместного и индивидуального ис-
пользования. Индивидуальные кэши доступны только для одного
пользователя. Доступность в этом случае должна определяться со-
ответствующим механизмом, обеспечивающим безопасность. Все
другие кэши рассматриваются как коллективные. Другие разделы
этой спецификации накладывают определенные ограничения на ра-
боту совместно используемых кэшей, для того, чтобы предотвратить
потерю конфиденциальности или управления доступом.
12.8. Ошибки или поведение кэша при неполном отклике
Кэш, который получает неполный отклик (например, с меньшим
числом байтов, чем специфицировано в заголовке Content-Length)
может его запомнить. Однако кэш должен воспринимать эти дан-
ные как частичный отклик. Частичные отклики могут компоно-
ваться, как это описано в разделе 12.5.4. Результатом может быть
полный или частичный отклик. Кэш не должен возвращать час-
тичный отклик клиенту без явного указания на то, что он частич-
ный, используя статусный код 206 (Partial Content). Кэш не дол-
940
Гпава 4
жен возвращать частичный отклик, используя статусный код 200
(ОК).
Если кэш получает отклик 5хх при попытке перепроверить за-
пись, он может переадресовать этот отклик запрашивающему кли-
енту или действовать так, как если бы сервер не смог ответить на
запрос. В последнем случае он может вернуть отклик, полученный
ранее, если только запись в кэше не содержит директиву Cache-
Control "must-revalidate” (см. раздел 13.9).
12.9. Побочные эффекты методов GET и HEAD
Если исходный сервер напрямую не запрещает кэширование своих
откликов, методы приложения GET и HEAD не должны давать ка-
ких-либо побочных эффектов, которые вызывали бы некорректное
поведение, если эти отклики берутся из кэша. Они все же могут
давать побочные эффекты, но кэш не обязан рассматривать такие
побочные эффекты, принимая решение о кэшировании. Кэши конт-
ролируют лишь прямые указания исходного сервера о запрете кэ-
ширования.
Обратим внимание только на одно исключение из этого прави-
ла: некоторые приложения имеют традиционно используемые GET
и HEAD с запросами URL (содержащими ”?” в части rel_path) для
выполнения операций с ощутимыми побочными эффектами. Кэши
не должны обрабатывать отклики от таких URL, как свежие, если
только сервер не присылает непосредственно значение времени жиз-
ни. Это в частности означает, что отклики от серверов НТТР/1.0
для этих URI не следует брать из кэша.
12.10. Несоответствие после актуализации или стирания
Воздействие определенных методов на исходный сервер может
вызвать то, что одна или более записей, имеющихся в кэше, стано-
вятся неявно непригодными. То есть, хотя они могут оставаться
’’свежими”, они не вполне точно отражают то, что исходный сервер
пришлет в ответ на новый запрос.
В протоколе HTTP не существует способа гарантировать, что все
такие записи в кэше будут помечены как непригодные. Например,
запрос, который вызывает изменение в исходном сервере не обяза-
тельно проходит через прокси, где в кэше хранится такая запись.
Однако несколько правил помогает уменьшить вероятность некор-
ректного поведения системы.
В этом разделе, выражение "пометить объект как непригодный”
означает, что кэш должен либо удалить все записи, относящиеся к
этому объекту из памяти или должен пометить их, как непригодные
Сети передачи данных. Метод доступа
941
(’’invalid”), что будет вызывать обязательную перепроверку пригод-
ности перед отправкой в виде отклика на последующий запрос.
Некоторые методы HTTP могут сделать объект непригодным.
Это либо объекты, на которые осуществляется ссылка через Request-
URI, или через заголовки отклика Location или Content-Location
(если они имеются). Это методы:
• PUT
• DELETE
• POST
12.10. Обязательная пропись (Write-Through Mandatory)
Все методы, которые предположительно могут вызвать модифика-
цию ресурсов исходного сервера должны быть прописаны в исход-
ном сервере. В настоящее время сюда входят все методы кроме GET
и HEAD. Кэш не должен отвечать на такой запрос от клиента, преж-
де чем передаст запрос встроенному серверу, и получит соответствую-
щего отклик от него. Это не препятствует кэшу послать отклик 100
(Continue), прежде чем встроенный сервер ответит.
Альтернатива, известная как "write-back" или "copy-back" кэши-
рование, в НТТР/1.1 не допускается, из-за трудности обеспечения
согласованных актуализаций и проблем, связанных с отказами серве-
ра, кэша или сети до осуществления обратной записи (write-back).
12.12. Замещения в кэше
Если от ресурса получен новый кэшируемый отклик (см. разде-
лы 13.9.2, 12.2.5, 12.2.6 и 12.8), в то время как какой-либо отклик
для того же ресурса уже записан в кэш, кэшу следует использовать
новый отклик для ответа на текущий запрос. Он может ввести его
в память кэша и, если он отвечает всем требованиям, использовать
в качестве отклика для будущих запросов. Если он вводит новый
отклик в память кэша, он должен следовать правилам из раздела
12.5.3.
Новый отклик, который имеет значение заголовка Date старше,
чем кэшированные уже отклики, не должен заноситься в кэш.
12.13. Списки предыстории
Агенты пользователя часто имеют механизмы "исторического"
Управления, такие как кнопки "Back" и списки предыстории, кото-
рые могут использоваться для повторного отображения объекта,
извлеченного ранее в процессе сессии. Механизмы предыстории и
кэширования различны. В частности механизмы предыстории не
Должны пытаться показать семантически прозрачный вид текущего
942
Гпава 4
состояния ресурса. Скорее, механизм предыстории предназначен для
того, чтобы в точности показать, что видел пользователь, когда ре-
сурс был извлечен. По умолчанию время годности не приложимо к
механизмам предыстории. Если объект все еще в памяти, механизм
предыстории должен его отобразить, даже если время жизни объек-
та истекло и он объявлен непригодным, если только пользователь
не сконфигурировал агента так, чтобы обновлять объекты, срок год-
ности которых истек. Это не запрещает механизму предыстории
сообщать пользователю, что рассматриваемый им объект устарел.
Если механизмы предыстории излишне мешают пользователю
просматривать устаревшие ресурсы, то это заставит разработчиков
избегать пользоваться контролем времени жизни объектов. Разра-
ботчикам следует считать важным, чтобы пользователи не получа-
ли сообщений об ошибке или предупреждения, когда они пользуют-
ся навигационным управлением (например, таким как клавиша
BACK).
13. Определения полей заголовка
Этот раздел определяет синтаксис и семантику всех стандарт-
ных полей заголовков НТТР/1.1. Для полей заголовков объекта,
как отправитель, так и получатель могут рассматриваться клиен-
том или сервером в зависимости от того, кто получает объект.
13.1. Поле Accept
Поле заголовка запроса Accept может использоваться для спе-
цификации определенных типов среды, которые приемлемы для дан-
ного ресурса. Заголовки Accept могут использоваться для индика-
ции того, что запрос ограничен в рамках определенного набора ти-
пов, как в случае запросов отображения в текущей строке.
Accept = ”Accept”
#( media-range [ accept-params ])
media-range = ( ”*/*”
I ( type "/" "*”)
| (type "/" subtype )
) *( parameter )
accept-params = ”q” qvalue *( accept-extension )
accept-extension == token [ ”=” ( token | quoted-string ) ]
Символ звездочка используется для того, чтобы объединят
типы среды в группы с ”*/*”, указывающим на все типы, и ’’type/*",
указывающим на все субтипы данного типа. Группа сред может
включать в себя параметры типа среды, которые применимы. За
Сети передачи данных. Метод доступа
943
каждой группой сред может следовать один или более параметров
приема (accept-params), начинающихся с ”q” параметра для указа-
ния фактора относительного качества. Первый ”q” параметр (если
таковой имеется) отделяет параметры группы сред от параметров
приема. Факторы качества позволяют пользователю или агенту
пользователя указать относительную степень предпочтения для дан-
ной группы сред, используя шкалу значений q от 0 до 1 (раздел
2.9). Значение по умолчанию соответствует q=l.
Использование имени параметра ”q” для разделения параметров
типа среды от параметрон расширения Accept связано с историчес-
кой практикой. Это мешает присвоения параметру типа среды име-
ни "q”. Пример Accept: audio/*; q=0.2, audio/basic.
Должно интерпретироваться, как ”Я предпочитаю audio/basic,
но шлите мне любые типы аудио, если это лучшее, что имеется
после 80% понижения качества”. Если поле заголовка Accept от-
сутствует, тогда предполагается, что клиент воспринимает все типы
среды. Если поле заголовка Accept присутствует и, если сервер не
может послать отклик, который является приемлемым, согласно
комбинированному значению поля Accept, тогда сервер должен по-
слать отклик 406 (not acceptable). Более сложный пример.
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
Это будет интерпретироваться следующим образом, "text/html
и text/x-c являются предпочтительными типами сред, но, если их
нет, тогда следует прислать объект text/x-dvi, а, если и он отсутству-
ет, присылать объект типа text/plain”.
Группы сред могут быть заменены другими группами или неко-
торыми специальными типами среды. Если используется более'од-
ного типа среды для данного типа, предпочтение отдается наиболее
специфичному типу. Например,
Accept: text/*, text/html, text/html;level=l, */*
имеет следующие предпочтения:
1) text/html;level=l
2) text/html
3) text/*
4) */*
Фактор качества типа среды, ассоциированный с данным типом
°пределен путем нахождения группы сред с наивысшим предпочте-
нием, который подходит для данного типа. Например,
944
Гпава 4
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=l,
text/html;level=2;q=0.4,
в результате будут установлены следующие величины:
text/html;level=l = 1
text/html =0.7
text/plain =0.3
image/jpeg = 0.5
text/html;level=2 = 0.4
text/html;level=3; =0.7
Агент пользователя может быть создан с набором значений каче-
ства по умолчанию для определенных диапазонов среды. Однако если
только агент пользователя не является закрытой системой, которая не
может взаимодействовать с другими агентами, этот набор по умолча-
нию должен быть конфигурируем пользователем.
13.2. Поле Accept-Charset
Поле заголовка запроса Accept-Charset может быть использовано
для указания того, какой символьный набор приемлем для отклика.
Это поле позволяет клиентам, способным распознавать более обшир-
ные или специальные наборы символов, сигнализировать об этой воз-
можности серверу, который способен представлять документы в рам-
ках этих символьных наборов. Набор символов ISO-8859-1 может
считаться приемлемым для всех агентов пользователя.
Accept-Charset = ’’Accept-Charset”
1#( charset [ ”q” ”=” qvalue ] )
Значения символьных наборов описаны в разделе 2.4. Каждому
символьному набору может быть поставлено в соответствие значе-
ние качества, которое характеризует степень предпочтения пользо-
вателя для данного набора. Значение по умолчанию q=l. Например
Accept-Charset: iso-8859-5, unicode-1-1 ;q=0.8. Если заголовок Accept-
Charset отсутствует, по умолчанию это означает, что приемлем лю-
бой символьный набор. Если заголовок Accept-Charset присутству-
ет, и, если сервер не может послать отклик, который приемлем с
точки зрения заголовка Accept-Charset, тогда он должен послать
сообщение об ошибке со статусным кодом 406 (not acceptable), хотя
допускается посылка и отклика "unacceptable".
Сети передачи данных. Метод доступа
945
13.3. Поле Accept-Encoding
Поле заголовка запроса Accept-Encoding сходно с полем Accept,
но регламентирует кодировку содержимого (раздел 13.12), которая
приемлема в отклике.
Accept-Encoding = ’’Accept-Encoding”
#( content-coding )
Ниже приведен пример его использования.
Accept-Encoding: compress,gzip
Если заголовок Accept-Encoding в запросе отсутствует, сервер
может предполагать, что клиент воспримет любую кодировку ин-
формации. Если заголовок Accept-Encoding присутствует и, если
сервер не может послать отклик, приемлемый согласно этому заго-
ловку, тогда серверу следует послать сообщение об ошибке со ста-
тусным кодом 406 (Not Acceptable). Пустое поле Accept-Encoding
указывает на то, что не приемлемо никакое кодирование.
13.4. Поле Accept-Language
Поле заголовка запроса Accept-Language сходно с полем Accept,
но регламентирует набор естественных языков, которые предпочти-
тельны в отклике на запрос.
Accept-Language == "Accept-Language"
1#( language-range [ ";" "q” "=" qvalue ] )
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | )
Каждому набору языков может быть поставлено в соответствие
значение качества, которое представляет собой оценку предпочте-
ний пользователя для языков, специфицированных в диапазоне. По
умолчанию значение качества "q=l". Например,
Accept-Language: da, en-gb;q=0.8, en;q=0.7
будет означать: "Я предпочитаю датский, но восприму британский
английский и другие типы английского". Набор языков согласует-
ся с языковой меткой, если он в точности равен метке или, если он в
точности равен префиксу метки, такому как первый символ метки,
за которым следует символ "-". Специальный набор "если он
присутствует в поле Accept-Language, согласуется с любой меткой.
Это использование префикса не предполагает, что языковые мет-
ки присвоены языкам таким образом, что, если пользователь пони-
мает язык с определенной меткой, то он поймет все языки, имеющие
метки с одним и тем же префиксом. Правило префикса просто
946
Гпава 4
позволяет использовать префиксные метки для случаев, когда это
справедливо.
Языковый фактор качества, присваиваемый языковой метке с
помощью поля Accept-Language, равен значению качества самого
длинного языкового списка в поле, которое соответствует языковой
метке. Если в поле отсутствует список языков, фактору качества
присваивается значение нуль. Если в запросе отсутствует заголовок
Accept-Language, серверу следует предполагать, что все языки при-
емлемы в равной мере. Если заголовок Accept-Language имеется,
тогда все языки, которым присвоен фактор качества больше нуля,
приемлемы.
Так как степень интеллигентности в высшей степени индивиду-
альна, рекомендуется, чтобы приложения клиента делали выбор язы-
ковых предпочтений доступным для пользователя. Если выбор не
сделан доступным, тогда Йоле заголовка Accept-Language не должно
присутствовать в запросе. .
13.5. Поле Accept-Ranges
Поле заголовка отклика Accept-Ranges позволяет серверу ука-
зать доступность частичных запросов к ресурсу:
Accept-Ranges = °Accept-Ranges” acceptable-ranges
acceptable-ranges = l#range-unit | ’’none”
Исходные серверы, которые воспринимают байт-диапазонные зап-
росы, могут послать
Accept-Ranges: bytes
но делать это необязательно. Клиенты могут выдавать байт-диапа-
зонные запросы, не получив этот заголовок отклика для запраши-
ваемого ресурса. Серверы, которые не могут работать с какими-либо
диапазонными запросами, могут послать
Accept-Ranges: none,
чтобы посоветовать клиенту, не пытаться посылать такие запросы.
13.6. Поле Age
Поле заголовка отклика Age передает оценку отправителем вре-
мени с момента формирования отклика исходным сервером (или
перепроверки его пригодности). Кэшированный отклик является
свежим, если его возраст не превышает его времени жизни. Значе-
ния Age вычисляютс/i согласно рекомендациям представленным
разделе 12.2.3.
Сети передачи данных. Метод доступа
947
Age = "Age” ":" age-value
age-value = delta-seconds
Значения Age являются неотрицательным десятичным целым
числом, характеризующим возраст записи в секундах.
Если кэш получает величину больше, чем наибольшее положи-
тельное число, которое он может себе представить или, если вычис-
ление возраста вызвало переполнение, он должен передать заголо-
вок Age. со значением 2147483648 (231). Кэши НТТР/1.1 должны
посылать заголовки Age в каждом отклике. Кэшам следует ис-
пользовать арифметический тип чисел не менее 31 бита.
13.7. Поле Allow
Поле заголовка объекта Allow перечисляет набор методов, под-
держиваемых ресурсом, идентифицированным Request-URI. Целью
этого поля является точное информирование получателя о рабочих
методах данного ресурса. Поле заголовка Allow обязательно долж-
но быть представлено в отклике 405 (Method Not Allowed).
Allow = "Allow” ":" l#method
Пример использования:
Allow: GET, HEAD, PUT
Это поле не препятствует клиенту испытать другие методы. Од-
нако указания, данные в значение поля заголовка Allow, следует
выполнять. Действительный набор методов определяется исходным
сервером во время каждого запроса.
Поле заголовка Allow может быть прислано запросом PUT, что-
бы рекомендовать методы, которые будут поддерживаться новым
или модифицированным ресурсом. Серверу не обязательно поддер-
живает эти методы, но ему следует включить заголовок Allow в
отклик, чтобы сообщить действительно поддерживаемые методы.
Прокси не должен модифицировать поле заголовка Allow, даже если
он не понимает все специфицированные методы, так как агент пользо-
вателя может иметь другие средства связи с исходным сервером.
Поле заголовка Allow не указывает на то, что методы реализова-
ны на уровне сервера. Серверы могут использовать поле заголовка
отклика.Public (раздел 13.35), чтобы описать, какие методы реали-
зованы на сервере.
13.8. Авторизация
Агент пользователя, который хочет авторизовать себя на серве-
Ре, может сделать это после получения отклика 401, включив поле
948
Гпава 4
заголовка Authorization в запрос. Значение поля Authorization со-
стоит из идентификационной информации агента пользователя для
области (realm) запрошенных ресурсов.
Authorization = "Authorization” credentials
Авторизация доступа HTTP описана в разделе 10. Если запрос
авторизован и область специфицирована, та же самая идентифика-
ционная информация может быть использована для других запро-
сов в пределах данной области.
Когда кэш коллективного пользования (см. раздел 12.7) полу-
чает запрос, содержащий поле Authorization, он не должен присы-
лать соответствующий отклик в качестве ответа на какой-либо
другой запрос, если только не выполняется одно из следующих
условий.
• Если отклик включает в себя директиву Cache-Control "ргоху-
revalidate", кэш может использовать этот отклик при последующих
запросах, но прокси-кэш должен сначала, перепроверить его пригод-
ность с помощью исходного сервера, используя заголовки нового
запроса для того, чтобы исходный сервер мог идентифицировать но-
вый запрос.
• Если отклик содержит в себе директиву Cache-Control "must-
revalidate", кэш может использовать этот отклик при ответах на
последующие запросы, но все кэши должны сначала перепроверить
пригодность откликов с помощью исходного сервера, используя за-
головки нового запроса для того, чтобы сервер мог идентифициро-
вать новый запрос.
• Если отклик содержит директиву Cache-Control ’’public", то
этот отклик может быть отослан в ответ на любой последующий
запрос.
13.9. Поле Cache-Control
Поле общего заголовка Cache-Control используется для специ-
фикации директив, которые должны исполняться всеми механизма-
ми кэширования вдоль цепочки запрос/отклик. Директивы опреде-
ляют поведение, которое, как предполагается, должно предотвратить
нежелательную интерференцию откликов или запросов в кэше. Эти
директивы обычно переписывают алгоритм кэширования, исполь-
зуемый по умолчанию. Директивы кэша являются однонаправлен-
ными, присутствие директивы в запросе не предполагает, что та же
директива будет присутствовать и в отклике.
Сети передачи данных. Метод доступа
949
Заметьте, что кэши НТТР/1.0 могут не реализовывать управле-
ние (Cache-Control), а могут использовать только директиву Pragma:
no-cache (см. раздел 13.32).
Директивы кэша должны пропускаться через приложения про-
кси или внешнего шлюза (gateway), вне зависимости от их значения
для этого приложения, так как директивы могут быть прйменимы
для всех получателей в цепочке запрос/отклик. Не возможно спе-
цифицировать директивы для каких-либо отдельных кэшей.
Cache-Control = "Cache-Control" ”:" l#cache-directive
cache-directive = cache-request-directive
| cache-response-directive
cache-request-directive = "no-cash" [”=" <"l#field-name<"]
| "no-store"
| "max-age" "=" delta-seconds
| "max-stale" [ "==” delta-seconds ]
| "min-fresh" "=" delta-seconds
| "only-if-cached"
| cache-extension
cache-response-directive = "public"
| "private" [ "=" <"> l#field-name <"> ]
| "no-cache" [ ”=” <"> l#field-name <"> ]
| "no-store"
| "no-transform"
| "must-revalidate"
| "max-age" ”=” delta-seconds
| cache-extension;
cache-extension = token [ "=” ( token | quoted-string ) ]
Если директива появляется без какого-либо параметра 1 #field-
name, она воздействует на весь запрос или отклик. Когда такая
директива приходит с параметром l#field-name, она воздействует
только на именованное поле или поля и не имеет никакого дей-
ствия на остальную часть запроса или отклика. Этот механизм
поддерживает расширяемость. Реализации будущих версий прото-
кола HTTP могут использовать эти директивы для полей заголов-
ка, неопределенных в рамках НТТР/1.1.
Директивы управления кэшем могут быть разделены на следу-
ющие категории:
• Ограничения на то,, что можно кэшировать. Они налагаются
только исходным сервером.
950
Гпава 4
• Ограничения на то, что можно записывать в память кэша.
Они определяются исходным сервером или агентом пользователя.
• Модификации базового механизма контроля годности запи-
сей. Они вносятся либо исходным сервером, либо агентом пользо-
вателя.
• Управление процессом перепроверки годности записей и пере-
загрузкой осуществляется только агентом пользователя.
• Управление преобразованием объектов.
• Расширения системы кэширования.
13.9.1. Что допускает кэширование?
По умолчанию отклик допускает кэширование, если требования
метода запроса, поля заголовка запроса и код статуса отклика ука-
зывают на то, что кэширование не запрещено. Раздел 12.4 обобща-
ет эти рекомендации для кэширования. Следующие директивы от-
клика позволяют исходному серверу переписать стандартные требо-
вания по кэшируемости:
public
!
Указывает, что отклик может кэшироваться любым кэшем, даже
если он в норме не кэшируем или кэшируем только в кэшах инди-
видуального пользования. (См. также об авторизации в разделе 13.8.)
private
Указывает, что весь или часть сообщения отклика предназначе-
на для одного пользователя и не должна быть записана кэшем
коллективного пользования. Это позволяет исходному серверу зая-
вить о том, что специфицированные части отклика предназначены
только для одного пользователя, и он не может отсылаться в ответ
на запросы других пользователей. Частный кэш может кэшировать
такие отклики.
Это использование слова частный (private) определяет только
возможность кэширования и не гарантирует конфиденциальности
для содержимого сообщения.
no-cache
Указывает, весь или фрагмент сообщения-отклика не должны
кэшироваться, где бы то ни было. Это позволяет исходному серверу
предотвратить кэширование даже для кэшей, сконфигурированных
для рассылки устаревших откликов.
Большинство кэшей НТТР/1.0 не распознают и не исполняют
эту директиву.
Сети передачи данных. Метод доступа
951
13.9.2. Что может быть записано в память кэша?
Целью директивы no-store (не запоминать) является предотвраще-
ние ненамеренного распространения или записи конфиденциальной
информации (например, на backup ленты). Директива no-store приме-
няется для всего сообщения и может быть послана как в отклике, так
и в запросе. При посылке в запросе кэш не должен запоминать ка-
кую-либо часть этого запроса или присланного в ответ отклика. При
посылке в отклике, кэш не должен запоминать какую-либо часть от-
клика или запроса, его вызвавшего. Эта директива действует как для
индивидуальных кэшей, так и кэшей коллективного пользования. "Не
должно запоминаться" в данном контексте означает, что кэш не дол-
жен заносить отклик в долговременную память и должен сделать все
от него зависящее для того, чтобы удалить эту информацию из времен-
ной памяти после переадресации этих данных.
Даже когда эта директива ассоциирована с откликом, пользова-
тели могут непосредственно запомнить такой отклик вне системы
кэширования (например, с помощью диалога "Save As"). Буферы
предыстории могут запоминать такие отклики как часть своей нор-
мальной работы.
Цель этой директивы обеспечение выполнения определенных
требований пользователей и разработчиков, кто связан с проблема-
ми случайного раскрытия информации за счет непредвиденного дос-
тупа к структуре данных кэша. При использовании этой директивы
можно в некоторых случаях улучшить конфиденциальность, но сле-
дует учитывать, что здесь не существует какого-либо надежного ме-
ханизма обеспечения конфиденциальности. В частности, некоторые
кэши могут не распознавать или не выполнять эту директиву, а
коммуникационные сети могут прослушиваться.
13.9.3. Модификации базового механизма контроля времени жизни
Время пригодности объекта может быть специфицировано ис-
ходным сервером с помощью заголовка Expires (см. раздел 13.21).
Другой возможностью является применение директивы max-age в
°тклике.
Если отклик включает в себя как заголовок Expires, так и ди-
рективу max-age, более высокий приоритет имеет директива тах-
а£е, даже если заголовок Expires накладывает более жесткие огра-
ничения. Это правило позволяет исходному серверу обеспечить для
Данного отклика большее время жизни в случае объектов кэша
НТТР/1.1 (или более поздней версии), чем в НТТР/1.0. Это может
быть полезным, если кэш НТТР/1.0 некорректно вычисляют воз-
952 Гпава 4
раст объекта или его время пригодности, например, из-за не синх-
ронности часов.
Большинство старых кэшей, несовместимых с данной специфи-
кацией, не поддерживают применение директив управления кэшем.
Исходный сервер, желающий применить директиву управления кэ-
шем, которая ограничивает, но не запрещает кэширование в систе-
мах НТТР/1.1, может использовать то, что директива max-age пере-
писывает заголовок Expires.
Другие директивы позволяют агенту пользователя модифициро-
вать механизм контроля времени жизни объектов. Эти директивы
могут быть специфицированы в запросе max-age.
Это запрос указывает, что клиент желает воспринять отклик, чей
возраст не больше заданного времени в секундах. Если только не
включена также директива max-stale, клиент не воспримет устарев-
ший отклик.
Запрос min-fresh указывает на то, что клиент желает воспринять
отклик, чье время жизни не меньше, чем его текущий возраст плюс
заданное время в секундах. То есть, клиент хочет получить отклик,
который будет еще свежим, по крайней мере, заданное число секунд.
Запрос max-stale z/казывает, что клиент желает воспринять от-
клик, время жизни которого истекло. Если max-stale присвоено кон-
кретное значение, тогда клиент хочет получить отклик, время жиз-
ни которого истекло не ранее, чем заданное число секунд тому на-
зад. Если значения max-stale в директиве не указано, тогда клиент
готов воспринять отклики любого возраста.
Если кэш присылает устаревший отклик, из-за наличия в запро-
се директивы max-stale, либо потому, что кэш сконфигурирован та-
ким образом, что переписывает время жизни откликов, кэш должен
присоединить заголовок предупреждения к отклику, используя
Warning 10 (Response is stale — отклик устарел).
13.9.4. Управление перепроверкой пригодности и перезагрузкой
Иногда агент пользователя может потребовать, чтобы кэш пере-
проверил пригодность своих записей с помощью исходного сервера
(а не соседнего кэша по пути к исходному серверу), или перезагру-
зил свой кэш из исходного сервера. Может потребоваться перепро-
верка End-to-end, если и кэш и исходный сервер имеют завышенные
оценки времени жизни кэшированных откликов. Перезагрузка End-
to-end может потребоваться, если запись в кэше оказалась по ка-
кой-то причине поврежденной.
Перепроверка типа end-to-end может быть запрошена в случав»
когда клиент не имеет своей локальной копии, этот вариант мЫ
Сети передачи данных. Метод доступа
953
называем ”не специфицированная перепроверка end-to-end”, или когда
клиент имеет, локальную копию,, такой вариант называется "специ-
фической перепроверкой end-to-end."
Клиент может потребовать три вида действий, используя в зап-
росе директивы управления кэшем:
End-to-end reload
Запрос включает в себя директиву управления кэшем "no-cache"
или, для совместимости с клиентами НТТР/1.0, "Pragma: no-cache".
Сервер не должен использовать кэшированную копию при ответе
на этот запрос.
Specific end-to-end revalidation
Запрос включает в себя директиву управления кэшем "тах-
age=0", которая вынуждает каждый кэш вдоль пути к исходному
серверу сверить свою собственную запись, если она имеется, с запи-
сью следующего кэша или сервера. Исходный запрос включает в
себя требования перепроверки для текущего значения валидатора
клиента.
Unspecified end-to-end revalidation
Запрос включает в себя директиву управления кэшем "тах-
age=0", которая вынуждает каждый кэш вдоль пути к исходному
серверу сверить свою собственную запись, с записью следующего кэша
или сервера. Исходный запрос не включает в себя требований пере-
проверки. Первый кэш по пути (если таковой имеется), который
содержит запись данного ресурса, подключает условия перепроверки
со своим текущим валидатором.
Когда промежуточный кэш оказывается вынужден с помощью
Директивы max-age=O перепроверить свои записи, присланный кли-
ентом валидатор может отличаться от того, что записан в данный
момент в кэше. В этом случае кэш может воспользоваться в своем
запросе любым из валидаторов, не нарушая семантической прозрач-
ности.
Однако выбор валидатора может повлиять на результат. Наи-
лУчшим подходом для промежуточного кэша является использо-
вание в запросе своего собственного валидатора. Если сервер присы-
лает отклик 304 (Not Modified), тогда кэш должен отправить свою
Унсе проверенную копию клиенту со статусным кодом 200 (ОК).
Если сервер присылает отклик с новым объектом и валидатором
КэШа, промежуточный кэш должен сверить, тем не менее, получен-
ий валидатор с тем, что прислал клиент, используя функцию силь-
954
Гпава 4
ного сравнения. Если валидатор клиента равен присланному серве-
ром, тогда промежуточный кэш просто возвращает код 304 (Not
Modified). В противном случае он присылает новый объект со ста-
тусным кодом 200 (ОК).
Если запрос включает в себя директиву no-cache, в нем не долж-
но быть директив min-fresh, max-stale или max-age.
В некоторых случаях, таких как периоды исключительно пло-
хой работы сети, клиент может захотеть, чтобы кэш возвращал только
те отклики, которые в данный момент находятся в памяти, и не
перезагружать или перепроверять записи из исходного сервера. Для
того чтобы сделать это, клиент может включить в запрос директиву
only-if-cached. При получении такой директивы кэшу следует либо
реагировать, используя кэшированную запись, которая соответству-
ет остальным требованиям запроса, либо откликаться статусным
кодом 504 (Gateway Timeout). Однако если группа кэшей работает
как унифицированная система с хорошей внутренней коннективно-
стью, тогда такой запрос может быть переадресован в пределах груп-
пы кэшей.
Так как кэш может быть сконфигурирован тац, чтобы игнори-
ровать времена жизни, заданные сервером, а запрос клиента мо-
жет содержать директиву max-stale (которая производит анало-
гичный эффект), протокол включает в себя механизм, который
позволяет серверу требовать перепроверки записей в кэше для
любого последующего применения. Когда в отклике, полученном
кэшем, содержится директива must-revalidate, этот кэш не дол-
жен использовать эту запись для откликов на последующие зап-
росы без сверки ее на исходном сервере. Таким образом, кэш
должен выполнить перепроверку end-to-end каждый раз, если со-
гласно значениям Expires или max-age, кэшированный отклик
является устаревшим.
Директива must-revalidate необходима для поддержания надеж-
ной работы для определенных функций протокола. При любых об-
стоятельствах НТТР/1.1 кэш должен выполнять директиву must-
revalidate. В частности, если кэш по какой-либо причине не имеет
доступа к исходному серверу, он должен генерировать отклик 504
(Gateway Timeout).
Серверы должны посылать директиву must-revalidate, тогда а
только тогда, когда неудача запроса перепроверки объекта может
вызвать нарушение работы системы, например, не выполнение Фй'
нансовой операции без оповещения об этом. Получатели не долж-
ны осуществлять любые автоматические действия, которые нарУ*
Сети передачи данных. Метод доступа
955
шают эту директиву, и не должны посылать непригодную копию
объекта, если перепроверка не удалась.
Хотя это и не рекомендуется, агенты пользователя, работающие
в условиях очень плохой коннективности, могут нарушать эту ди-
рективу, но, если это происходит, пользователь должен быть предуп-
режден в обязательном порядке, что присланный отклик возможно
является устаревшим. Предупреждение должно посылаться в слу-
чае каждого непроверенного доступа, при этом следует требовать
подтверждения от пользователя.
Директива proxy-revalidate имеет то же значение, что и must-
revalidate, за исключением того, что она не применима для индиви-
дуальных кэшей агентов пользователя. Она может использовать-
ся в отклике на перепроверенный запрос, чтобы разрешить кэшу
пользователя запомнить и позднее прислать отклик без перепро-
верки (так как он был уже перепроверен однажды этим пользова-
телем). В то же время прокси должен требовать перепроверкй вся-
кий раз при обслуживании разных пользователей (для того чтобы
быть уверенным, что каждый пользователь был идентифицирован).
Заметьте, что такие перепроверенные отклики нуждаются также в
директиве управления кэшем public для того, чтобы разрешить их
кэширование.
13.9.5. Директива No-Transform
Разработчики промежуточных кэшей (прокси) выяснили, что
полезно преобразовать тип среды для тел определенных объектов.
Прокси может, например, преобразовать форматы изображения для
того, чтобы сэкономить место в памяти кэша или чтобы уменьшить
информационный поток в тихоходном канале. HTTP должен дати-
ровать такие преобразования, выполняемые без оповещения.
Серьезные операционные проблемы происходят, однако, когда
такие преобразования производятся над телами объектов, предназ-
наченных для определенного сорта приложений. Например, исполь-
зующих медицинские изображения, предназначенные для анализа
научных данных, а также тех, которые применяют авторизацию end-
to-end, или требуют побитной совместимости с оригиналом.
Следовательно, если отклик содержит директиву no-transform,
промежуточный кэш или прокси не должны изменять те заголовки,
которые перечислены в разделе 12.5.2, так как они могут содержать
Директиву no-transform. Это предполагает, что кэш или прокси не
Должны изменять любую часть тела объекта, который имеет такие
заголовки.
956
Гпава- 4
13.9.6. Расширения управления кэшем
Поле заголовка Cache-Control может быть расширено за счет
использования одной или более лексем расширения возможностей
кэша, каждой из которых может быть присвоено определенное зна-
чение. Информационные расширения (те которые не требуют изме-
нений в работе кэша) могут быть добавлены без изменения семан-
тики других директив. Поведенческие расширения спроектированы
для того, чтобы выполнять функции модификаторов существующих
директив управления кэшем. Новые директивы и стандартные ди-
рективы устроены так, что приложения, которые не воспринимают
новую директиву, по умолчанию исполнят стандартную процедуру.
Те же приложения, которые распознают новую директиву, восприни-
мают ее как модификацию’ стандартной процедуры. Таким путем
расширения директив управления кэшем могут быть сделаны без
изменения базового протокола.
Этот механизм расширений зависит от того, выполняет ли кэш
все директивы управления, определенные для базовой версии HTTP.
Предполагается, что кэш реализует определенные расширения и иг-
норирует все директивы, которые не может распознать.
Например, рассмотрим гипотетическую, новую директиву, назван-
ную "community", которая действует как модификатор директивы
"private". Мы определяем эту новую директиву так, что в дополне-
ние к стандартным возможностям, кэши, которые обслуживают груп-
пу (community), могут кэшировать их отклики. Исходный сервер,
желающий позволить группе "UCI" использовать частные отклики
на их общем кэше, может решить эту проблему, включив директиву
управления кэшем: private, community="UCI".
Кэш, получив это поле заголовка, будет действовать корректно,
если даже не понимает расширение "community", так как он видит
и понимает директиву "private" и, таким образом, по умолчанию
обеспечит безопасное функционирование.
Не распознанная директива управления должна игнорировать-
ся. Предполагается, что любая директива, в том числе и не узнан-
ная кэшем НТТР/1.1, имеет по умолчанию стандартную директи-
ву-подмену, которая обеспечивает определенный уровень функцио-
нальности, когда директива-расширение не распознается.
13.10. Соединение
Поле общего заголовка Connection позволяет отправителю спе-
цифицировать опции, которые желательны для конкретного соеди-
нения. Заголовок Connection имеет следующую грамматику:
Сети передачи данных. Метод доступа
957
Connection-header = "Connection” l#(connection-token)
connection-token = token
Прокси-серверы НТТР/1.1 должны выполнить разбор поля за-
головка Connection, прежде чем выполнить переадресацию, и для
каждой лексемы соединения в этом поле убрать любые поля заго-
ловка в сообщении с именами, совпадающими с этими лексемами.
Опции Connection отмечаются присутствием лексем соединения в
поле заголовка Connection, а не какими-либо дополнительными по-
лями заголовка, так как дополнительное поле заголовка может быть
не послано, если нет параметров, ассоциированных с данной опцией
соединения. НТТР/1.1 определяет опцию ’’close” (закрыть) для от-
правителя, чтобы сигнализировать о том, что соединение будет зак-
рыто после завершения передачи отклика. Например, наличие
Connection: close
как в полях запроса, так и в полях отклика указывает на то, что
соединение не следует рассматривать как ’’постоянное" (раздел 7.1)
после завершения передачи данного запроса/отклика. Приложения'
НТТР/1.1, которые не поддерживают постоянные соединения, дол-
жны содержать опцию соединения "close” в каждом сообщении.
13.11. Content-Base
Поле заголовка объекта Content-Base может быть использовано
для спецификации базового URI, которое позволяет работать с от-
носительными URL в пределах объекта.
Content-Base = "Content-Base” absoluteURI
Если поле Content-Base отсутствует, базовый URI объекта опре-
деляется его Content-Location (если это Content-Location URI явля-
ется абсолютным) или URI используется для инициации запроса.
Заметьте, однако, что базовый URI содержимого в пределах тела
объекта может быть переопределен.
13.12. Кодирование содержимого (Content-Encoding)
Поле заголовка объекта используется в качестве модификатора
типа среды. Если это поле присутствует, его значение указывает, что
тело объекта закодировано, и какой механизм декодирования еле-
ДУет применить, чтобы получить массив данных, ориентированный
Натип среды, указанный в поле Content-Type. Поле Content-Encoding
ПеРвоначально предназначалось, для того чтобы архивировать доку-
958
Гпава 4
мент без потери его идентичности с учетом типа среды, на которую
он ориентирован.
Content-Encoding = "Content-Encoding" ":" l#content-coding
Кодировки содержимого определены в разделе 2.5. Пример его
использования приведен ниже
Content-Encoding: gzip
Content-Encoding (кодирование содержимого) является харак-
теристикой объекта, задаваемой Request-URI. Обычно тело объекта
заносится в память в закодированном виде и декодируется перед
отображением или другим аналогичным использованием. Если было
применено множественное кодирование объекта, кодирование содер-
жимого должно быть перечислено в том порядке, в котором оно
было выполнено.
13.13. Язык содержимого (Content-Language)
Поле заголовка объекта Content-Language описывает естествен-
ный язык(и) потенциальных читателей вложенного объекта. За-
метьте, что это может быть совсем не эквивалентно всем языкам,
использованным в теле объекта.
Content-Language = "Content-Language" ":" l#language-tag
Языковые метки определены в разделе 2.10. Первоначальной
целью поля Content-Language является предоставление пользовате-
лю возможности дифференцировать объекты согласно языковым
предпочтениям. Таким образом, если содержимое тела предназначе-
но только для аудитории, говорящей на датском языке, подходя-
щим содержимым поля Content-Language может быть
Content-Language: da
Если поле Content-Language не задано, по умолчанию считается»
что содержимое ориентировано на любую аудиторию. Это может
значить, что отправитель не выделяет какой-либо естественный язык
конкретно, или что отправитель не знает, какой язык предпочесть
(не владеет ни одним из языков).
Список языков может быть предложен для содержимого, кото-
рое предназначено для многоязыковой аудитории. Например, пере-
вод "Treaty of Waitangi," представленный одновременно в ориги-
нальной версии на маори и на английском, может быть вызван с
помощью.
Сети передачи данных. Метод доступа
959
Content-Language: mi, en
Однако только то, что в поле объекта перечислено несколько
языков не означает, что объект предназначен для многоязыковой
аудитории. Примером может быть языковый курс для начинаю-
щих, такой как "A First Lesson in Latin," который предназначен для
англо-говорящей аудитории. В этом случае поле Content-Language
должно включать только ”еп". Поле Content-Language может быть
применено к любому типу среды - оно не ограничено только тексто-
выми документами.
13.14. Длина содержимого
Содержимое поля заголовка объекта Content-Length указывает
длину тела сообщения в октетах (десятичное число), посылаемое
получателю, или в случае метода HEAD, размер тела объекта, кото-
рый мог бы быть послан при запросе GET.
Content-Length = "Content-Length" ":" 1*DIGIT
Например
Content-Length: 3495
Приложениям следует использовать это поле для указания разме-
ра сообщения, которое должно быть послано вне зависимости от типа
среды. Получатель должен иметь возможность надежно определить
положение конца запроса НТТР/Ы, содержащего тело объекта.
Любое значение Content-Length больше или равное нулю допус-
тимо. Раздел 3.4 описывает то, как определить длину тела сообще-
ния, если параметр Content-Length не задан.
Значение этого поля заметно отличается от соответствующего
определения в MIME, где оно является опционным, используемым в
типе содержимого "message/external-body". В HTTP его следует
посылать всякий раз, когда длина сообщения должна быть известна
До начала пересылки.
13.15. Поле Content-Location
Поле заголовка объекта Content-Location может быть использо-
вано для определения положения ресурса для объекта, вложенного
в сообщение. В случае, когда ресурс содержит много объектов, и эти
объекты в действительности имеют разные положения, по которым
Может быть осуществлен доступ, сервер должен предоставить поле
Content-Location для конкретного варианта, который должен быть
960
Гпава 4
прислан. Кроме того, сервер должен предоставить Content-Location
для ресурса, соответствующего объекту отклика.
Content-Location == ’’Content-Location"
(absoluteURI | relativeURI)
Если поле заголовка Content-Base отсутствует, значение Content-
Location определяет также базовый URL для объекта (см. раздел
13.11).
Значение Content-Location не является заменой для исходного
запрашиваемого URI, это лишь объявление положения ресурса, со-
ответствующего данному конкретному объекту в момент запроса.
Будущие запросы могут использовать Content-Location URI, если
нужно идентифицировать источник конкретного объекта.
Кэш не может предполагать, что объект с полем Content-Location,
отличающимся от URI, который использовался для его получения,
может использоваться для откликов на последующие запросы к
этому Content-Location URI. Однако Content-Location может исполь-
зоваться для того, чтобы отличить объекты, полученные из одного
общего, как это описано в разделе 12.6.
Если Content-Location является относительным URI, URI интер-
претируется с учетом значения Content-Base URI, присланного в от-
клике. Если значения Content-Base не предоставлено, относитель-
ный URI интерпретируется по отношению к Request-URI.
13.16. Content-MD5 (дайджест содержимого)
Поле заголовка объекта Content-MD5, как это определено в RFC
1864 [23], является МБ5-дайджестом тела объекта для целей обеспе-
чения проверки end-to-end целостности сообщения MIC (message
integrity check).
MIC привлекательна для регистрации случайных модификаций
тела объекта при транспортировке, но не является гарантией про-
тив преднамеренных действий.
Content MD5 = "Content-MD5" md5-digest
md5digest = <base64 of 128 bit MD5 digest as per RFC 1864>
Поле заголовка Gontent-MD5 может генерироваться исходным
сервером с целью проверки целостности тел объектов. Только ис-
ходные серверы могут генерировать поле заголовка Content-MD5«
Прокси и внешние шлюзы его генерировать не должны, так как это
сделает невозможными проверку целостности end-to-end. Любой
получатель тела объекта, включая внешние шлюзы и прокси, могут
Сети передачи данных. Метод доступа
961
проверять то, что значение дайджеста в этом поле заголовка согла-
суется с полученным телом объекта.
Дайджест MD5 вычисляется на основе содержимого тела сооб-
щения, с учетом любых кодировок содержимого, но исключая лю-
бые транспортные кодировки (Transfer-Encoding), которые могли
быть использованы. Если сообщение получено в закодированном
виде с использованием Transfer-Encoding, это кодирование должно
быть удалено перед проверкой значения Content-MD5 для получен-
ного объекта.
Это означает, что дайджест вычисляется для октетов тела объек-
та в том порядке, в каком они будут пересланы, если не использует-
ся транспортное кодирование.
HTTP расширяет RFC 1864 с тем, чтобы разрешить вычисление
дайджеста для MIME-комбинации типов среды (например,Multi part/
* и message/rfc822), но это никак не влияет на способ вычисления
дайджеста.
Существует несколько следствий этого. Тело объекта для ком-
бинированных типов может содержать много составных частей, каж-
дая со своими собственными MIME и HTTP заголовками (включая
заголовки Content-MD5, Content-Transfer-Encoding и Content-
Encoding). Если часть тела имеет заголовок Content-Transfer-
Encoding или Content-Encoding, предполагается, что содержимое этой
части закодировано, и она включается в дайджест Content-MD5 как
есть. Поле заголовка Transfer-Encoding не применимо для частей
тела объекта.
Так как определение Content-MD5 является в точности тем же
для HTTP и MIME (RFC 1864), существует несколько вариантов, в
которых применение Content-MD5 к телам объектов HTTP отлича-
ется от случая MIME. Один вариант связан с тем, что HTTP, в
отличие от MIME, не использует Content-Transfer-Encoding, а ис-
пользует Transfer-Encoding и Content-Encoding. Другой — вызван
тем, что HTTP чаще, чем MIME, использует двоичный тип содержи-
мого. И, наконец, HTTP позволяет передачу текстовой информации
с любым типом разрыва строк, а не только с каноническим CRLF.
Преобразование всех разрывов строк к виду CRLF не должно де-
латься до вычисления или проверки дайджеста: тип оформления
Разрыва строк при расчете дайджеста должен быть сохранен.
13.17. Отрывок содержимого
Заголовок объекта Content-Range посылается с частью тела объек-
та и служит для определения того, где в теле объекта должен разме-
щаться данный фрагмент. Он также указывает полный размер тела
31 Зак. № 3430 Семенов
962 Гпава 4
объекта. Когда сервер присылает клиенту частичный отклик, он
должен описать как длину фрагмента, так и полный размер тела '
объекта.
Content-Range = ’’Content-Range" content-range-spec
Content-range-spec = byte-content-range-spec
byte-content-range-spec = bytes-unit SP first-byte-pos
last-byte-pos entity-length
entity-length = 1*DIGIT
В отличие от значений спецификаторов байтовых диапазонов
(byte-ranges-specifier), byte-content-range-spec может специфициро-
вать только один интервал и должен содержать абсолютные поло-
жения, как первого, так и последнего байтов.
Некорректной считается спецификация byte-content-range-spec,
чье значение last-byte-pos меньше, чем его значение first-byte-pos,
или значение длины объекта меньше или равно last-byte-pos. Полу-
чатель некорректной спецификации byte-content-range-spec должен
игнорировать ее и любой текст, переданный вместе с ней. Примеры
спецификации byte-content-range-spec, предполагающей, что объект
содержит 1234 байт, приведены ниже:
• The first 500 bytes: bytes 0-499/1234
• The second 500 bytes: bytes 500-999/1234
• All except for the first 500 bytes: bytes 500-1233/1234
• The last 500 bytes: bytes 734-1233/1234
Когда сообщение HTTP включает в себя содержимое одного фраг-
мента (например, отклик на запрос получения одного фрагмента,
или на запрос набора фрагментов, которые перекрываются без зазо-
ров), это содержимое передается с заголовком Content-Range, а заго-
ловок Content-Length несет в себе число действительно переданных
байт. Например,
НТТР/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
Когда сообщение HTTP несет в себе содержимое нескольких
фрагментов (например, отклик на запрос нескольких, не перекрыва-
ющихся фрагментов), они передаются как многофрагментное MIME-
сообщение. Многофрагментный тип данных MIME используемый для
Сети передачи данных. Метод доступа
963
этой цели,определен в этой спецификации как "multipart/byteranges"
(см. 15.2). Клиент, который не может декодировать сообщение MIME
multi part/byteranges,не должен запрашивать несколько байт-фраг-
ментов в одном запросе. Когда клиент запрашивает несколько фраг-
ментов байт в одном запросе, серверу следует присылать их в по-
рядке перечисления.
Если сервер игнорирует спецификацию byte-range-spec, из-за того,
что она некорректна, сервер должен воспринимать запрос так, как
если бы некорректного заголовка Range не существовало вовсе. В
норме это означает посылку отклика с кодом 200, содержащего весь
объект.
13.18. Тип содержимого
Поле заголовка объекта Content-Type указывает тип среды тела
объекта, посланного получателю, или, в случае метода HEAD, тип
среды, который был бы применен при методе GET.
Content-Type = "Content-Type" media-type
Типы среды определены в разделе 2.7. Примером поля может
служить
Content-Type: text/html; charset=ISO-8859-4
Более полное обсуждение методов идентификации типа среды
объекта приведено в разделе 6.2.1.
13.19. Дата
Поле заголовка Date представляет дату и время формирования
сообщения, имеет ту же семантику, что и orig-date в RFC 822. Зна-
чение поля равно HTTP-date, как-то описано в разделе 2.3.1.
Date = "Date" ":" HTTP-date
Пример
Date: Tue, 15 Nov 1994 08:12:31 GMT
Если сообщение получено через непосредственное соединение с
агентом пользователя (в случае запросов) или исходным сервером
(в случае откликов), дата может считаться текущей датой конца
приема. Однако так как дата по определению является важной при
оценке характеристик кэшированных откликов, исходный сервер
Должен включать поле заголовка Date в каждый отклик. Клиентам
следует посылать поле заголовка Date в сообщениях, которые несут
тело объекта, как в случае запросов PUT и POST, но даже здесь это
зр
964
Гпава 4
является опционным. Полученному сообщению, которое не имеет
поля заголовка Date, следует присвоить дату. Это может сделать
один из получателей, если сообщение будет кэшировано им, или
внешним шлюзом.
Теоретически дата должна представлять момент времени сразу
после генерации объекта. На практике поле даты может быть сфор-
мировано в любое время в процессе генерации сообщения.
Формат поля Date представляет собой абсолютную дату и время
так, как это определено для даты HTTP в разделе 2.3. Оно должно
быть послано в формате, описанном в документе RFC1123 [8].
13.20. Поле ETag
Поле заголовка объекта ETag определяет метку объекта. Заго-
ловки с метками объектов описаны в разделах 13.20, 13.25, 13.26 и
13.43. Метка объекта может использоваться для сравнения с дру-
гими объектами того же самого ресурса (см. раздел 12.3.2).
ETag = ”ETag” entity-tag
Примеры:
ETag: "xyzzy"
ETag: W/"xyzzy”
ETag:
13.21. Поле Expires
Поле заголовка объекта Expires содержит дату/время с момента,
когда отклик может считаться устаревшим. Устаревшая запись в
кэше в норме не должна посылаться, если только она не будет
сначала перепроверена с помощью исходного сервера (или с помо-
щью промежуточного кэша, который содержит свежую копию объек-
та). Дальнейшее обсуждение модели контроля пригодности записей
содержится в разделе 12.2. Присутствие поля Expires не предпола-
гает, что исходный ресурс изменит или удалит объект по истечении
указанного времени.
Формат абсолютной даты и времени так описан в разделе 2.3.
Он должен следовать рекомендациям документа RFC1123:
Expires = "Expires" ":" HTTP-date
Примером реализации формата даты может служить
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Если отклик содержит поле Cache-Control с директивой max-age,
то эта директива переписывает значение поля Expires. Клиенты
Сети передачи данных. Метод доступа
965
НТТР/1.1 и кэши должны рассматривать некорректные форматы
даты, в особенности те, что содержат нули, как относящиеся к про-
шлому (то есть, как ’’уже истекшие").
Для того чтобы пометить отклик, как "уже с истекшим сроком",
исходный сервер должен использовать дату Expires, которая равна
значению заголовка Date. (Правила вычисления времени истечения
пригодности записи смотри в разделе 12.2.4.)
Для того, чтобы пометить отклик как "всегда пригодный", ис-
ходный сервер должен использовать дату Expires приблизительно
на один год позже момента посылки отклика. Серверы НТТР/1.1
не должны посылать отклики с датами в поле Expires, которые
устанавливают время жизни более одного года.
Присутствие поля заголовка Expires со значением даты, относя-
щемся к будущему, означает, что они могут быть занесены в кэш,
если только не указано обратного в поле заголовка Cache-Control
(раздел 13.9).
13.22. Поле From
Поле заголовка запроса From (если присутствует) должно содер-
жать интернетовский e-mail адрес пользователя. Адрес должен иметь
формат, описанный в документе RFC 822 (и дополненный в RFC
1123):
From = "From" mailbox
Пример:
From: webmaster@w3.org
Это поле заголовка может быть использовано для целей регист-
рации процедур и как средство идентификации источников некор-
ректных и нежелательных запросов. Не следует использовать его
как ненадежную систему защиты доступа. Это поле предоставляет
информацию о том, кто является ответственным за метод, использо-
ванный в данном запросе. В частности, агенты-роботы должны со-
держать этот заголовок, так чтобы с лицом, ответственным за рабо-
ту робота, можно было связаться, в случае возникновения проблем
на принимающем конце.
Интернетовский e-mail адрес в этом поле может не совпадать с
Интернет-адресом ЭВМ, пославшей запрос. Например, когда запрос
прошел через прокси, следует использовать адрес первичного отпра-
вителя.
Клиенту не следует посылать поле заголовка From без одобре-
ния пользователя, так как это может вызвать конфликт с интереса-
96В
Гпава 4
ми конфиденциальности пользователя или нарушить политику бе-
зопасности сети отправителя. Настоятельно рекомендуется, чтобы
пользователь мог дезактивировать, активировать и модифицировать
значение этого поля в любое время до запроса.
13.23. Поле Host
Поле заголовка запроса Host специфицирует ЭВМ в Интернет и
номер порта запрашиваемого ресурса в виде, полученном из исход-
ного URL, который выдал пользователь или который получен из
указанного ресурса (в общем случае из HTTP URL, как это описано
в разделе 2.2.2). Значение поля Host должно определять положе-
ние в сети исходного сервера или шлюза, заданное исходным URL.
Это позволяет исходному серверу или шлюзу различать внутренние
URL, такие как корневые ”/” URL сервера для ЭВМ, которым по-
ставлен в соответствие один IP адрес.
Host = ’’Host’’ host [ port ] ; Раздел 2.2.2
Имя "ЭВМ” без последующего номера порта предполагает значе-
ние порта по умолчанию для заданного вида сервиса (напр., ”80’’
для HTTP URL). Например, запрос исходного сервера <http://
www.w3.org/pub/WWW/> должен включать в себя:
GET /pub/WWW/HTTP/1.1
Host: www.w3.org
Клиент должен включать поле заголовка Host во все сообще-
ния-запросы НТТР/1.1 в Интернет (т.е., в любое сообщение, соот-
ветствующее запросу URL, который включает в себя Интернетёадрес
ЭВМ, услуги которой запрашиваются). Если поле Host отсутствует,
прокси НТТР/1.1 должен добавить его в сообщение-запроса до того,
как переадресует его дальше в Интернет. Все серверы НТТР/1.1,
которые базируются в Интернет, должны откликаться статусным
кодом 400 на любое сообщение-запрос НТТР/1.1, в котором отсут-
ствует поле Host. О других требованиях относительно поля Host
смотри раздел 4.2 и 15.5.1.
13.24. Поле If-Modified-Since
Поле заголовка запроса If-Modified-Since используется с мето-
дом GET, для того чтобы сделать его условным. Если запрошенный
объект не был модифицирован со времени, указанного в этом поле,
он не будет прислан сервером, вместо этого будет послан отклик 304
(not modified) без какого-либо тела сообщения.
Сети передачи данных. Метод доступа
967
If-Modified-Since = ”If-Modified-Since” HTTP-date
Пример поля:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Метод GET с заголовком If-Modified-Since и без заголовка Range
требует, чтобы идентифицированный объект был передан, только в
случае его модификации после даты, указанной в заголовке If-
Modified-Since. Алгоритм определения этого включает в себя сле-
дующие шаги
а. Если запрос приводит к чему-то отличному от статусного от-
клика 200 (ОК), или если переданная дата If-Modified-Since некор-
ректна, отклик будет в точности тот же, что и для обычного GET.
Дата раньше текущего времени сервера является некорректной.
Ь. Если объект был модифицирован после даты If-Modified-Since,
отклик будет в точности тем же, что и для обычного GET.
с. Если объект не был модифицирован после корректно указан-
ной даты If-Modified-Since, сервер должен прислать отклик 304 (Not
Modified).
Целью этой функции является эффективная актуализация кэ-
шированной информации с минимальными издержками. Заметьте,
что время If-Modified-Since интерпретируются сервером, чьи часы
могут быть не синхронизованы с часами клиента.
Если клиент использует произвольную дату в заголовке If-
Modified-Since вместо даты взятой из заголовка Last-Modified для
текущего запроса, тогда клиенту следует остерегаться того, что эта
дата интерпретируется согласно представлениям сервера о времен-
ной шкале. Клиенту следует учитывать несинхронность часов и
проблемы округления, связанные с различным кодированием вре-
мени клиентом и сервером. Это предполагает возможность быстро-
го изменения условий, когда документ изменяется между моментом
первого запроса и датой If-Modified-Since последующего запроса, а
также возможность трудностей, связанных с относительным сбоем
часов, если дата If-Modified-Since получена по часам клиента (без
поправки на показания часов сервера). Поправки для различных
временных базисов клиента и сервера желательно делать с учетом
времени задержки в сети.
13.25. Поле If-Match
Поле заголовка запроса If-Match используется с методом, для
того чтобы сделать используемый метод условным. Клиент, кото-
рый имеет один или более объектов, полученных ранее из ресурса,
968
Гпава 4
может проверить, является ли один из этих объектов текущим, вклю-
чив список связанных с ним меток в поле заголовка If-Match. Це-
лью этой функции является эффективная актуализация кэширо-
ванной информации с минимальными издержками. Она использует-
ся также в запросах актуализации с целью предотвращения
непреднамеренной модификации не той Версии ресурса, что нужно.
Значение соответствует любому объекту ресурса.
If-Match = "If-Match" | l#entity-tag )
Если какая-то метка объекта совпадает с меткой объекта, кото-
рый прислан в отклике на аналогичный запрос GET (без заголовка
If-Match), или если задана и какой-то текущий объект суще-
ствует для данного ресурса, тогда сервер может реализовать запро-
шенный метод, как если бы поля заголовка If-Match не существова-
ло. Сервер должен использовать функцию сильного сравнения (см.
раздел 2.11) для сопоставления меток объекта в If-Match.
Если ни одна из меток не подходит, или если задана и не
существует никакого текущего объекта, сервер не должен реализо-
вывать запрошенный метод, а вместо этого прислать отклик 412
(Precondition Failed). Это поведение особенно полезно, когда клиент
хочет помешать актуализующему методу, такому как PUT, модифи-
цировать ресурс, который изменился после последнего доступа к
нему клиента.
Если запрос без поля заголовка If-Match выдает в результате
нечто отличное от статуса 2хх, тогда заголовок If-Match должен
игнорироваться.
”If-Match: *” означает, что метод должен быть реализован, если
представление, выбранное исходным сервером (или кэшем, возмож-
но с привлечением механизма Vary, см. раздел 13.43), существует, и
не должен быть реализован, если выбранного представления не су-
ществует.
Запрос, предназначенный для актуализации ресурса (напр., PUT)
может включать в себя поле заголовка If-Match, чтобы сигнализи-
ровать о том, что метод запроса не должен быть применен, если
объект, соответствующий значению If-Match (одиночная метка объек-
та), не является более представлением этого ресурса. Это позволяет
пользователям указывать, что они не хотят, чтобы запрос прошел
успешно, если ресурс был изменен без их уведомления. Примеры:
If-Match: ’’xyzzy”
If-Match: ’’xyzzy”, ”r2d2xxxx”, ”c3piozzzz”
If-Match: *
Сети передачи данных. Метод доступа
969
13.26. Поле If-None-Match
Поле заголовка запроса If-None-Match используется для форми-
рования условных методов. Клиент, который имеет один или более
объектов, полученных ранее из ресурса, может проверить, что ни
один из этих объектов не является текущим, путем включения списка
их ассоциированных меток в поле заголовка If-None-Match. Целью
этой функции является эффективная актуализация кэшированной
информации с минимальной избыточностью. Она также использу-
ется при актуализации запросов с тем, чтобы предотвратить непред-
намеренную модификацию ресурса, о существовании которого не было
известно.
Значение соответствует любому текущему объекту ресурса.
If-None-Match = ”If-None-Match” ( l#entity-tag )
Если какая-либо метка объекта соответствует метке объекта,
который был прислан в отклике на аналогичный запрос GET (без
заголовка If-None-Match) или если задана и существует какой-
то текущий объект данного ресурса, тогда сервер не должен реали-
зовывать запрошенный метод. Вместо этого, если методом запроса
был, GET или HEAD, серверу следует реагировать откликом 304
(Not Modified), включая поля заголовков объекта, ориентированные
на кэш (в частности ETag). Для всех других методов запроса сервер
должен откликаться статусным кодом 412 (Precondition Failed).
По поводу правил того, как определять соответствие двух меток
объектов смотри раздел 12.3.3. С запросами GET и HEAD должна
использоваться только функция слабого сравнения.
Если не подходит ни одна из меток объекта или если задана
и не существует ни одного текущего объекта, сервер может выпол-
нить запрошенный метод так, как если бы поля заголовка If-None-
Match не существовало. Если запрос без поля заголовка If-None-
Match, даст результат отличный от статусного кода 2хх, тогда заго-
ловок If-None-Match должен игнорироваться.
”If-None-Match: *” означает, что метод не должен реализовы-
ваться, если представление, выбранное исходным сервером (или кэ-
шем, возможно использующим механизм Vary), существует, и дол-
жен быть реализован, если представления не существует. Эта функ-
ция может быть полезной для предотвращения конкуренции между
операциями PUT.
970
Гпава 4
Примеры:
If-None-Match: "xyzzy"
If-None-Match: W/’’xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/’’xyzzy", W/"r2d2xxxx", W/’’c3piozzzz"
If-None-Match: *
13.27. Заголовок If-Range
Если клиент имеет частичную копию объекта в своем кэше и
хочет иметь полную свежую копию объекта, он может использовать
заголовок запроса Range с условным GET (используя If-Unmodified-
Since и/или If-Match.) Однако если условие не выполняется, из-за
того что объект был модифицирован, клиенту следует послать вто-
рой запрос, чтобы получить все текущее содержимое тела объекта.
Заголовок If-Range позволяет клиенту заблокировать второй
запрос. По существу это означает, что "если объект не изменился,
следует посылать мне часть, которой у меня нет, в противном слу-
чае пришлите мене всю новую версию объекта".
If-Range = "If-Range" ( entity-tag | HTTP-date )
Если клиент не имеет метки объекта, но имеет дату Last-Modified, '
он может использовать эту дату в заголовке If-Range. Сервер мо-
жет отличить корректную Дату HTTP от любой формы метки объекта,
рассмотрев не более двух символов. Заголовок If-Range следует ис-
пользовать только совместно с заголовком Range, и его следует
игнорировать, если запрос не содержит в себе этого заголовка, или
если сервер не поддерживает операции с фрагментами.
Если метка объекта, представленная в заголовке If-Range, соот-
ветствует текущей метке, тогда сервер должен обеспечить специфи-
цированный фрагмент объекта, используя отклик 206 (Partial
content). Если метка объекта не подходит, сервер должен прислать
полный объект со статусным кодом 200 (ОК).
13.28. Поле If-Unmodified-Since
Поле заголовка запроса If-Unmodified-Since используется для того,
чтобы формировать условные методы. Если запрошенный ресурс не
был модифицирован с момента, указанного в поле, сервер должен
произвести запрошенную операцию, так как если бы заголовок If-
Unmodified-Since отсутствовал.
Сети передачи данных. Метод доступа
971
Если запрошенный объект был модифицирован после указанно-
го времени, сервер не должен выполнять запрошенную операцию и
должен прислать отклик 412 (Precondition Failed).
If-Unmodified-Since = "If-Unmodified-Since" HTTP-date
Примером поля может служить:
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Если запрос в норме (т.е., без заголовка If-Unmodified-Since)
завершился бы чем-то отличным от статусного кода 2хх, заголовок
If-Unmodified-Since следует игнорировать. Если специфицированная
дата некорректна, заголовок также игнорируется.
13.29. Поле Last-Modified
Поле заголовка объекта Last-Modified указывает на дату и вре-
мя, при которых, по мнению исходного сервера, данный объект был
модифицирован.
Last-Modified = "Last-Modified" ":" HTTP-date
Пример его использования
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Точное значение этого заголовка зависит от реализации исход-
ного сервера и природы ресурса. Для файлов, это может быть дата
последней модификации файловой системы. Для объектов с дина-
мическими встроенными частями это может время последней моди-
фикации одной из встроенных компонент. Для шлюзов баз данных
это может быть метка последней модификации рекорда. Для вирту-
альных объектов это может быть время последнего изменения внут-
реннего состояния.
Исходный сервер не должен посылать дату Last-Modified, кото-
рая позже, чем время формирования сообщения сервера. В таких
случаях, когда последняя модификация объекта указывает на неко-
торое время в будущем, сервер должен заменить дату на время фор-
мирования сообщения.
Исходный сервер должен получить значение Last-Modified объек-
та как можно ближе по времени к моменту генерации значения Date
°тклика. Это позволяет получателю выполнить точную оценку вре-
мени модификации объекта, в особенности, если объект был изменен
буквально накануне формирования отклика. Серверы НТТР/1.1 дол-
жны посылать поле Last-Modified всякий раз, когда это возможно.
972
Гпава 4
13.30. Поле Location
Поле заголовка отклика Location используется для переадреса-
ции запроса на сервер, отличный от указанного в Request-URI, или
для идентификации нового ресурса. В случае отклика 201 (Created),
поле Location указывает на новый ресурс, созданный в результате .
запроса. Для откликов Зхх поле Location должно указывать пред- *
почтительные URL сервера для автоматической переадресации на
ресурс. Значение поля включает одинарный абсолютный URL.
Location = ’’Location" absoluteURI
Например
Location: http://www.w3.org/pub/WWW/People.html
Поле заголовка Content-Location (раздел 13.15) отличается от
поля Location в том, что Content-Location идентифицирует исходное
положение объекта, заключенное в запросе. Следовательно, отклик
может содержать поля заголовка как Location, так и Content-Location.
Требования некоторых конкретных методов изложены также в раз-
деле 12.10.
13.31. Поле Max-Forwards
Поле заголовка запроса Max-Forwards может использоваться с
методом TRACE, чтобы ограничить число прокси или шлюзов, кото-
рые могут переадресовывать запрос. Это может быть полезным, ког-
да клиент пытается отследить путь запроса в случае возникновения
различных проблем.
Max-Forwards = "Max-Forwards" 1*DIGIT
Значение Max-Forwards представляет собой целое десятичное число,
которое указывает сколько еще раз запрос можно переадресовать.
Каждый прокси или шлюз получатель запроса TRACE, содержа-
щего поле заголовка Max-Forwards, должен проверить и актуализо-
вать его величину прежде, чем переадресовывать запрос. Если полу-
ченная величина равна нулю, получателю не следует переадресовы-
вать запрос. Вместо этого, ему следует откликнуться как конечному
получателю статусным кодом 200 (ОК), содержащим полученное
сообщение-запрос в качестве тела отклика (как это описано в разде-
ле 8.8). Если полученное значение больше нуля, тогда переадресо-
ванное сообщение должно содержать актуализованное значение поля
Max-Forwards (уменьшенное на единицу).
Сети передачи данных. Метод доступа
973
Поле заголовка Max-Forwards следует игнорировать для всех
других методов определенных в данной спецификации и для всех
расширений методов, для которых это не является частью определе-
ния метода.
13.32. Поле Pragma
Поле общего заголовка Pragma используется для включения спе-
циальных директив (зависящих от конкретной реализации), кото-
рые могут быть применены ко всем получателям вдоль цепочки
запрос/отклик. Все директивы pragma специфицируют опционное
поведение. Однако некоторые системы могут требовать, чтобы пове-
дение соответствовало директивам. v
Pragma = ’’Pragma" l#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ ’’=’’ ( token | quoted-string ) ]
Когда в запросе присутствует директива no-cache, приложение
должно переадресовать запрос исходному серверу, даже если имеется
кэшированная копия того, что запрошено. Директива pragma имеет
ту же семантику, что и директива кэша no-cache (см. раздел 13.9) и
определена здесь для совместимости с НТТР/1.0. Клиентам следу-
ет включать в запрос оба заголовка, когда посылается запрос no-
cache серверу, о котором неизвестно, совместим ли он с НТТР/1.1.
Нельзя специфицировать директиву pragma для какого-то от-
дельного получателя. Однако, любая директива pragma неприемле-
мая для получателя должна им игнорироваться.
Кэши НТТР/1.1 должны воспринимать "Pragma: no-cache", как
если бы клиент послал "Cache-Control: no-cache". Никаких новых
директив Pragma в HTTP определено не будет.
13.33. Поле Proxy-Authenticate
Поле заголовка отклика Proxy-Authenticate должно быть включено
в качестве части отклика 407 (Proxy Authentication Required). Значе-
ние поля состоит из вызова, который указывает на схему аутентифи-
кации, и параметры, применимые в прокси для данного Request-URI.
Proxy-Authenticate = "Proxy-Authenticate" challenge
Процесс авторизованного доступа HTTP описан в разделе 10.
В отличие от WWW-Authenticate, поле заголовка Proxy-Authenticate
применимо только к текущему соединению и не может быть переда-
но другим клиентам. Однако, промежуточному прокси может быть
нужно получить свои собственные авторизационные параметры с
974
Гпава 4
помощью запроса у ниже расположенного клиента, который при
определенных обстоятельствах может проявить себя как прокси,
переад ресующий поле заголовка Proxy-Authenticate.
13.34. Поле Proxy-Authorization
Поле заголовка запроса Proxy-Authorization позволяет клиенту
идентифицировать себя (или его пользователя) прокси, который тре-
бует авторизации. Значение поля Proxy-Authorization состоит из
автризационных параметров, содержащих идентификационную ин-
формацию агента пользователя для прокси и/или области (realm)
запрошенного ресурса.
Proxy-Authorization == "Proxy-Authorization” ":” credentials
Процесс авторизации доступа HTTP описан в разделе 10. В от-
личие от Authorization, поле заголовка Proxy-Authorization приме-
нимо только к следующему внешнему прокси, который требует ав-
торизации с помощью поля Proxy-Authenticate. Когда работает не-
сколько прокси, объединенных в цепочку, поле заголовка
Proxy-Authorization используется первым внешним прокси, кото-
рый.предполагает получение авторизационных параметров. Прокси
может передать эти параметры из запроса клиента следующему прокси,
если существует механизм совместной авторизации при обслужива-
нии данного запроса.
13.35. Поле Public
Поле заголовка отклика Public содержит список методов, под-
держиваемых сервером. Задачей этого поля является информирова-
ние получателя о возможностях сервера в отношении необычных
методов. Перечисленные методы могут быть, а могут и не быть при-
менимыми к Request-URI. Поле заголовка Allow (раздел 13.7) слу-
жит для указания методов, разрешенных для данного URI.
Public = "Public” l#method
Пример использования:
Public: OPTIONS, MGET, MHEAD, GET, HEAD
Это поле заголовка применяется для серверов, непосредственно
соединенных с клиентом, (т.е., ближайших соседей в цепи соедине-
ния). Если отклик проходит через прокси, последний должен либо
удалить поле заголовка Public или заменить его полем, характери-
зующим его собственные возможности.
Сети передачи данных. Метод доступа
975
13.36. Фрагмент
13.36.1. Фрагменты байт
Так как все объекты HTTP в процессе передачи представляют
собой последовательности байт, концепция фрагментов является
существенной для любого объекта HTTP. Однако не все клиенты и
серверы нуждаются в поддержке операций с фрагментами. Специ-
фикации байтовых фрагментов в HTTP относятся к последователь-
ностям байт в теле объекта, которое, вообще говоря, может быть не
тождественно обязательно телу сообщения.
Операция с байтовыми фрагментами может относиться к одному
набору байт или к нескольким таким наборам в пределах одного
объекта.
ranges-specifier = byte-ranges-specifier
byte-ranges-specifier = byt£-sunit ”=” byte-range-set
byte-range-set
byte-range-spec
first-byte-pos
last-byte-pos
= 1#( byte-range-spec | suffix-byte-range-spec )
= first-byte-pos [last-byte-pos]
= 1*DIGIT
= 1*DIGIT
Значение first-byte-pos в спецификации byte-range-spec указыва-
ет на относительное положение первого байта фрагмента. Значение
last-byte-pos определяет относительное положение последнего байта
фрагмента. Относительное положение начального байта равно нулю.
Если присутствует значение last-byte-pos, оно должно быть боль-
ше или равно значению first-byte-pos в спецификации byte-range-
spec, в противном случае спецификация byte-range-spec не коррект-
на. Получатель некорректной спецификации byte-range-spec дол-
жен ее игнорировать.
Если значение last-byte-pos отсутствует, или если значение боль-
ше или равно текущей длине тела объекта, значение last-byte-pos
берется на единицу меньше текущего значения длины тела объекта
в байтах.
При выборе last-byte-pos, клиент может ограничить число копи-
руемых байт, если не известна длина объекта.
suffix-byte-range-spec = suffix-length
suffix-length = 1*DIGIT
Спецификация suffix-byte-range-spec используется для задания
суффикса тела объекта с длиной, заданной значением suffix-length.
Эта форма специфицирует последние N байтов тела объекта. Если
объект короче заданной длины суффикса, то в качестве суффикса
Используется все тело объекта.
jfi:
97В Глава 4 v
Примеры значений byte-ranges-specifier (предполагается, что длина .
тела объекта равна 10000):
• Первые 500 байтов (относительные позиции 0-499, включи-
тельно): bytes=0-499.
• Вторые 500 байтов (относительные позиции 500-999, включи-
тельно): bytes=500-999
• Последние 500 байтов (относительные позиции 9500-9999,
включительно): bytes—500
ИЛИ ’
bytes=9500-
• Первые и последние байты (байты 0 и 9999): bytes=O-O,-l.
• Несколько легальных, но неканонических спецификаций вто-
рых 500 байт (относительные позиции 500-999, включительно):
bytes=500-600,601-999; bytes-500-700,601-999.
13.36.2. Запросы получения фрагментов
Информационные запросы HTTP, использующие условные или
безусловные методы GET могут заказывать один или более субфраг-
ментов объекта, а не целый объект, используя заголовок запроса
Range:
Range = "Range" ranges-specifier
Сервер может игнорировать заголовок Range. Однако исходные
серверы НТТР/1.1 и промежуточные кэши должны поддерживать
по возможности работу с фрагментами, так как Range поддерживает
эффективное восстановление в случае частично неудачных пересы-
лок больших объектов.
Если сервер поддерживает заголовки Range и специфйцирован-
ный фрагмент или фрагменты подходят для данного объекта, то:
• Присутствие заголовка Range в безусловном GET допускает
модификацию того, что прислано. Другими словами отклик может
содержать статусный код 206 (Partial Content) вместо 200 (ОК).
• Присутствие заголовка Range в условном GET (запрос исполь-
зует If-Modified-Since, If-None-Match, If-Unmodified-Since и/или If-
Match) модифицирует то, что прислано в случае успешного заверше-
ния при выполнении условия (TRUE). Это не влияет на отклик 304
(Not Modified), если условие не выполнено (FALSE).
В некоторых случаях более удобно использовать заголовок If-
Range (см. раздел 13.27). Если прокси, который поддерживает фраг-
менты, получает запрос Range, переадресует запрос внешнему серве-
ру и получает в ответ весь объект, ему следует прислать запрашива-
емый фрагмент клиенту. Он должен запомнить весь полученный
Сети передачи данных. Метод доступа
977
отклик в своем кэше, если отклик совместим с политикой записи в
его кэш.
13.37. Поле Referer
Поле заголовка запроса Referer позволяет клиенту специфици-
ровать (для пользы сервера) адрес (URI) ресурса, из которого был
получен Request-URI. Заголовок запроса Referer позволяет серверу
генерировать список обратных связей с ресурсами для регистрации
полезных ссылок, ведения дневника, оптимизации кэширования и
т.д.. Он позволяет также заставить работать устаревшие или дефек-
тные связи. Поле Referer не должно посылаться, если Request-URI
был получен от источника, который не имеет своего собственного
URI, такого, например, как ввод с пользовательского терминала.
Referer = "Referer" ( absoluteURI | relativeURI )
Пример:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
Если значением поля является частичный URI, его следует ин-
терпретировать относительно Request-URI. URI не должен вклю-
чать фрагментов.
Так как указание на первоисточник может быть конфиденци-
альной информацией или может раскрывать другой источник част-
ной информации, настоятельно рекомендуется, чтобы пользователь
имел возможность решать, посылать поле Referer или нет. Напри-
мер, клиент-броузер может иметь кнопку-переключатель для откры-
того или анонимного просмотра, которая управляет активацией/
дезактивацией посылки информации Referer и From.
13.38. Поле Retry-After
Поле заголовка отклика Retry-After может использоваться с ко-
дом статуса 503 (Service Unavailable) с тем, чтобы указать, как еще
долго данная услуга предполагается быть недоступной для запра-
шивающего клиента. Значением, этого поля может быть либо дата
HTTP либо целое число секунд (в десятичном исчислении) после
отправки отклика.
Retry-After = ’’Retry-After” ( HTTP-date | delta-seconds )
Два примера использования поля Retry-After:
Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
978
Гпава 4
В последнем примере задержка равна двум минутам.
13.39. Поле Server
Поле заголовка отклика Server содержит информацию о про-
граммном обеспечении, используемом исходным сервером для об-
работки запросов. Поле может содержать коды многих продуктов
(раздел 2.8) и комментарии, идентифицирующие сервер, и некоторые
важные субпродукты. Коды программных продуктов перечисляют-
ся в порядке важности приложений.
Server = "Server" ":" 1*( product | comment )
Например:
Server: CERN/3.0 libwww/2.17
Если отклик переадресуется через прокси, приложение прокси не
должно модифицировать заголовок отклика сервера. Вместо этого
ему следует включить в отклик поле Via (как это описано в разделе
13.44).
Раскрытие конкретной версии программного обеспечения серве-
ра может облегчить атаки против программных продуктов, для ко-
торых известны уязвимые места. Разработчикам серверов рекомен-
дуется сделать это поле конфигурируемой опцией.
13.40. Поле Transfer-Encoding (Транспортное кодирование)
Поле общего заголовка Transfer-Encoding указывает, какой тип
преобразования (если таковое использовано) применен к телу сооб-
щения, для того чтобы безопасно осуществить передачу между от-
правителем и получателем. Это поле отличается от Content-Encoding
тем, что транспортное кодирование является параметром сообще-
ния, а не объекта.
Transfer-Encoding = "Transfer-Encoding" ":" l#transfer-coding
Транспортное кодирование определено в разделе 2.6. Например:
Transfer-Encoding: chunked
Многие старые приложения HTTP/1.0 не воспринимают заголо-
вок Transfer-Encoding.
13.41. Заголовок Upgrade (Актуализация)
Общий заголовок Upgrade позволяет клиенту специфицировать
то, какие дополнительные коммуникационные протоколы он под-
держивает и хотел бы использовать, если сервер найдет их подходя-
Сети передачи данных. Метод доступа
979
щими. Сервер должен использовать поле заголовка Upgrade в от-
клике 101 (Switching Protocols) для указания того, какие протоко-
лы включены.
Upgrade = ’’Upgrade” l#product
Например:,
Upgrade: НТТР/2.0, SHTTP/1.3, IRC/6.9, RTA/xll
Поле заголовка Upgrade предназначено для обеспечения просто-
го механизма перехода от протокола НТТР/1.1 к некоторым дру-
гим. Это достигается путем разрешения клиенту объявлять о наме-
рении использовать другой протокол, например, более позднюю вер-
сию HTTP с большим старшим кодом версии, даже если текущий
запрос выполнен с использованием НТТР/1.1. Это облегчает пере-
ходы между несовместимыми протоколами за счет разрешения кли-
енту инициировать запрос в более широко поддерживаемом прото-
коле, в то же время, указывая серверу, что он предпочел бы исполь-
зовать протокол ’’получше”, если таковой доступен (где слово
"получше” определяется сервером, возможно согласно природы ме-
тода и/или запрашиваемого ресурса).
Поле заголовка Upgrade воздействует только на переключаю-
щий протокол прикладного уровня транспортного слоя существую-
щего соединения. Upgrade не может быть использовано для требо-
вания изменения протокола, его восприятие и использование серве-
ром является опционным. Совместимость и природа прикладного
уровня коммуникаций после смены протокола зависит исключи-
тельно от нового выбранного протокола, хотя первым действием
после такой замены должен быть отклик на исходный запрос HTTP,
содержащий поле заголовка Upgrade.
Поле Upgrade применимо только к текущему соединению. Сле-
довательно, ключевое слово upgrade должно содержаться в поле за-
головка Connection (раздел 13.10) всякий раз, когда поле Upgrade
присутствует в сообщении НТТР/1.1. Поле заголовка Upgrade не
может использоваться для указания смены протокола в другом
соединении. Для этой цели более приемлемы отклики переадреса-
ции с кодами 301, 302, 303 или 305.
Эта спецификация определяет протокол с именем ’’HTTP” при
работе с семейством протоколов для передачи гипертекста (Hypertext
Transfer Protocol), как это определено в правилах работы с версия-
ми HTTP раздела 2.1 и для будущих усовершенствований этой
спецификации. В качестве имени протокола может использоваться
980
Гпава 4
любая лексема, однако, она будет работать, только если клиент и
сервер ассоциируют это имя с одним и тем же протоколом.
13.42. Поле User-A gent (Агент пользователя)
Поле заголовка отклика User-Agent содержит информацию об
агенте пользователя, инициировавшем запрос. Это нужно для це-
лей сбора статистических данных, отслеживания нарушений прото-
кола и автоматического распознавания агентов пользователя. Аген-
там пользователя рекомендуется включать это поле в запросы.
Поле может содержать несколько кодов продуктов (раздел 2.8), ком-
ментарии, идентифицирующие агента и любые субпродукты, кото-
рые образуют существенную часть агента пользователя. Согласно
договоренности коды программных продуктов перечисляются в по-
рядке их важности для идентифицируемого приложения.
User-Agent = "User-Agent" ":" 1*( product | comment)
Например:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
13.43. Поле Vary
Поле заголовка отклика Vary используется сервером для того,
чтобы сигнализировать о том, что отклик выбран из числа имеющих-
ся представлений с помощью механизма согласования под управле-
нием сервера (раздел 11). Имена полей, перечисленные в заголовках
Vary, являются такими заголовками запроса. Значение поля Vary
указывает на то, что данный набор полей заголовка ограничивает
пределы, в которых могут варьироваться представления, или что пре-
делы вариации не специфицированы (”*”) и, таким образом, могут
модифицироваться в широких пределах для будущих запросов.
Vary = "Vary" ":" ( | l#field-name )
Сервер НТТР/1.1 должен включать соответствующее поле заго-
ловка Vary в любой кэшируемый отклик, который является субъек-
том, управляющим процессом согласования. Такая схема позволя-
ет кэшу правильно интерпретировать будущие запросы к заданному
ресурсу и информирует пользователя о согласовании доступа к ре-
сурсу. Серверу следует включить соответствующее поле заголовка
Vary в некэшируемый отклик, который является субъектом, управ-
ляющим согласованием, так как это может предоставить агенту
пользователя полезную информацию о пределах вариации отклика.
Сети передачи данных. Метод доступа
981
Набор полей заголовка, перечисленных в поле Vary известен как
’’выбирающие" заголовки запроса.
Когда кэш получает последующий запрос, чей Request-URI специ-
фицирует одну или более записей кэша, включая заголовок Vary, кэш
не должен использовать такую запись для формирования отклика на
новый запрос. Он это должен делать, если только все заголовки, пере-
численные в кэшированном заголовке Vary, присутствуют в новом
запросе и все заголовки отбора предшествующих запросов совпадают
с соответствующими заголовками нового запроса.
Селектирующие заголовки от двух запросов считаются соответ-
ствующими, тогда и только тогда, когда селектирующие заголовки
первого запроса могут быть преобразованы в селектирующие заго-
ловки второго запроса с помощью добавления или удаления строч-
ных пробелов LWS (Linear White Space) в местах, где это допускает-
ся правилами BNF (Backus-Naur Form) и/или, комбинируя несколь-
ко полей заголовка согласно требованиям построения заголовков
сообщения из раздела 3.2.
Vary означает, что не специфицированные параметры, воз-
можно отличные от содержащихся в полях заголовка (напр., сете-
вой адрес клиента), играют роль при выборе представления откли-
ка. Последующие запросы данного ресурса могут быть правильно
интерпретированы только исходным сервером, а кэш должен пере-
адресовать запрос (возможно условно), даже когда он имеет свежий
кэшированный отклик для данного ресурса.
Значение поля Vary, состоящее из списка имен полей сигнализи-
рует о том, что представление, выбранное для отклика, базируется
на алгоритме выбора, который рассматривает только значения пере-
численные в поле заголовка запроса. Кэш может предполагать, что
тот же выбор будет сделан для будущих запросов с теми же значе-
ниями имен полей, для периода времени, в течение которого отклик
остается свежим.
13.44. Поле Via
Поле общего заголовка Via должно быть использовано шлюзами
или прокси для указания промежуточных протоколов и получате-
лей на пути от агента пользователя к серверу, которому адресован
запрос, и между исходным, сервером и клиентом в случае отклика.
Это аналогично полю "Received" документа RFC 822 и предназначе-
но для использования при трассировке переадресаций сообщений,
исключения петель запроса и идентификации протокольных воз-
можностей всех отправителей вдоль цепочки запрос/отклик.
982
Глава 4
= token
= token
Via = "Via" 1#( received-protocol received-by [ comment ])
received-protocol = [ protocol-name ] protocol-version
protocol-name
protocol-version
received-by = ( host [ ”:” port ] ) | pseudonym
pseudonym = token
Запись "received-protocol” указывает версию протокола в сооб-
щении, полученном сервером или клиентом вдоль цепочки запрос/
отклик. Версия received-protocol добавляется к значению поля Via,
когда сообщение переадресуется, так что информация о возможнос-
тях протоколов предыдущих приложений остается прозрачной для
всех получателей.
Запись ’’protocol-name" является опционной, тогда и только тог-
да, когда это "HTTP”. Поле "received-by" обычно соответствует ЭВМ
и номеру порта сервера-получателя или клиента, который переадре-
сует сообщение. Однако если настоящее имя ЭВМ считается конфи-
денциальной информацией, оно может быть заменено псевдонимом.
Если номер порта не задан, можно предполагать, что используется
значение по умолчанию для данного протокола (received-protocol).
Значения поля Via представляет каждый прокси или шлюз, ко-
торый переадресовывал сообщение. Каждый получатель должен
присоединить свою информацию так, что конечный результат ока-
зывается упорядоченным согласно последовательности переадресу-
ющих приложений.
Комментарии могут быть использованы в поле заголовка Via
для идентификации программ получателя прокси или шлюза ана-
логично полям User-Agent и Server. Однако все комментарии в
поле Via являются опционными и могут быть удалены любым по-
лучателем перед тем, как переадресовать сообщение.
Например, сообщение-запрос может быть послано от агента
пользователя НТТР/1.0 программе внутреннего прокси с именем
"vanya", которая использует НТТР/1.1 для того, чтобы переадресо-
вать запрос общедоступному прокси с именем zagadka.com, кото-
рый завершает процесс переадресации запроса исходному серверу
store.in.ru. Запрос, полученный store.in.ru будет тогда иметь следу-
ющее поле заголовка Via:
Via: 1.0 vanya, 1.1 zagadka.com (Apache/1.1)
Прокси и шлюзы, используемые как средства сетевой защиты
(firewall) не должны по умолчанию переадресовывать имена ЭВМ и
портов в пределах области firewall. Эта информация может переда-
Сети передачи данных. Метод доступа
983
ваться, если это непосредственно позволено. Если это не разрешено,
запись "received-by" для ЭВМ в зоне действия firewall должна быть
заменена соответствующим псевдонимом.
Для организаций, которые имеют жесткие требования к защите
конфиденциальности и сокрытию внутренней структуры, прокси
может комбинировать субпоследовательность поля заголовка Via с
идентичными значениями ’’received-protocol" в единую запись. На-
пример,
Via: 1.0 vanya, 1.1 manya, 1.1 dunya, 1.0 sonya
Приложениям не следует комбинировать несколько записей, если
они только не находятся под единым административным контро-
лем и имена ЭВМ уже заменены на псевдонимы. Приложения не
должны комбинировать записи, которые имеют различные значения
"received-protocol".
13.46. Поле Warning (Предупреждение)
Поле заголовка отклика Warning используется для переноса
дополнительной информации о состоянии отклика, которая может
отражать статусный код. Эта информация обычно служит для пре-
дупреждения о возможной потере семантической прозрачности из-
за операций кэширования. Заголовки Warning посылаются с от-
кликами, используя:
Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
warn-code = 2DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; имя или псевдоним сервера, добавившего заголовок Warning,
; предназначенный для целей отладки
warn-text = quoted-string
Отклик может нести в себе более одного заголовка Warning.
Запись warn-text производится на естественном языке и с при-
менением символьного набора, приемлемого для принимающего от-
клик лица. Это решение* может базироваться на какой-то имею-
щейся информации, такой как Положение кэша или пользователя,
поля запроса Accept-Language, поля отклика Content-Language и
т-д. Языком по умолчанию является английский, а символьным
набором — ISO-8859-1.
Если используется символьный набор отличный от ISO-8859-1,
он должен быть закодирован в warn-text с использованием метода,
описанного в RFC 1522 [14].
984
Гпава 4
Любой сервер или кэш может добавить заголовки Warning к
отклику. Новые заголовки Warning должны добавляться после
любых существующих заголовков Warning. Кэш не должен унич-
тожать какие-либо заголовки, которые он получил в отклике. Од-
нако если кэш успешно перепроверил запись, ему следует удалить
все заголовки Warning, присоединенные ранее, за исключением спе-
циальных кодов Warning. Он должен добавить к записи новые за-
головки Warning, полученные с откликом перепроверки. Другими
словами заголовками Warning являются те, которые были бы по-
лучены в отклике на запрос в данный момент.
Когда к отклику подключено несколько заголовков Warning,
агенту пользователя следует отображать их столько, сколько воз-
можно, для того чтобы они появились в отклике. Если невозможно
отобразить все предупреждения, агент пользователя должен следо-
вать следующим эвристическим правилам:
• Предупреждения, которые появляются в отклике раньше, име-
ют приоритет перед теми, что появляются позже.
• Предупреждения, с предпочитаемым пользователем символь-
ным набором имеют приоритет перед предупреждениями с другими
наборами, но с идентичными warn-codes и warn-agents.
Системы, которые генерируют несколько заголовков Warning,
должны упорядочить их с учетом ожидаемого поведения агента
пользователя. Далее представлен список определенных в настоя-
щее время кодов предупреждений, каждый из которых сопровожда-
ется рекомендуемым текстом и описанием его значения.
10 Response is stale (отклик устарел)
Это предупреждение должно включаться всякий раз, когда при-
сылаемый отклик является устаревшим. Кэш может добавить это
предупреждение к любому отклику, но не может удалить его до тех
пор, пока не будет установлено, что отклик является свежим.
11 Revalidation failed (перепроверка пригодности неудачна)
Предупреждение должно включаться, если кэш присылает уста-
ревший отклик, потому что попытка перепроверить его пригодность
не удалась, из-за невозможности достичь сервера. Кэш может доба-
вить это предупреждение к любому отклику, но никогда не может
удалить его до тех пор, пока не будет успешно проведена перепро-
верка пригодности отклика.
12 Disconnected operation (работа в отключенном от сети состоянии)
Сети передачи данных. Метод доступа
985
Следует включать, если кэш намерено отключен от остальной
сети на определенный период времени.
13 Heuristic expiration (эвристическое завершение периода при-
годности)
Должно включаться, если кэш эвристически выбрал время жиз-
ни больше f24 часов, а возраст отклика превышает эту величину.
14 Transformation applied (применено преобразование)
Должно добавляться промежуточным кэшем или прокси, если он
использует какое-либо преобразование, изменяющее кодировку содер-
жимого (как это специфицировано в заголовке Content-Encoding) или
тип среды (как это описано в заголовке Content-Type) отклика, если
только этот код предупреждения не присутствует уже в отклике.
99 Разные предупреждения
Текст предупреждения включает в себя любую информацию, кото-
рая может быть представлена человеку-оператору или может быть
занесена в дневник операций. Система, получающая это предупрежде-
ние, не должна предпринимать каких-либо действий автоматически.
13. 46. Поле WWW-Authenticate
Поле заголовка отклика WWW-Authenticate должно включаться
в сообщения откликов со статусным кодом 401 (Unauthorized).
Значение поля содержит, по крайней мере, одно требование, которое
указывает на схему идентификации и параметры, применимые для
Request-URI.
WWW-Authenticate = ” WWW-Authenticate’’ l#challenge
Процесс авторизации доступа HTTP описан в разделе 10. Аген-
ты пользователя должны проявлять особую тщательность при раз-
боре значения поля WWW-Authenticate, если оно, содержит более
одного требования, или если прислан более чем одно поле заголов-
ка WWW-Authenticate, так как содержимое требования может само
содержать список параметров идентификации, элементы которого
Разделены запятыми.
14. Соображения безопасности
Этот раздел предназначен для того, чтобы проинформировать
Разработчиков приложений, поставщиков информации и пользова-
телей об ограничениях безопасности в н!тр/1 .1, как это описано в
Данном документе. Обсуждение не включает определенные решения
986
Гпава 4
данных проблем, но рассматриваются некоторые предложения, кото-
рые могут уменьшить риск.
14.1. Аутентификация клиентов
Базовая схема аутентификации не представляет безопасного ме-
тода идентификации пользователя, не обеспечивает она и каких-
либо средств защиты объектов, которые передаются открытым тек-
стом по используемым физическим сетям. HTTP не мешает вне-
дрению дополнительных схем идентификации, механизмов
шифрования или других мер, улучшающих безопасность системы
(например, SSL или одноразовых паролей). Наиболее серьезным де-
фектом базового механизма идентификации является то, что па-
роль пользователя передается по сети в незашифрованном виде.
Обычным назначением базовой идентификации является созда-
ние информационной (справочной) среды, которая требует от пользо-
вателя его имени и пароля, например, для сбора точной статистики
использования ресурсов сервера. При таком использовании предпо-
лагается, что не существует никакой опасности даже в случае неав-
торизованного доступа к защищенному документу. Это правильно,
если сервер генерирует сам имя и пароль пользователя и не позво-
ляет ему выбрать свой пароль самостоятельно. Опасность возника-
ет, когда наивные пользователи часто используют один и тот же
пароль, чтобы избежать необходимости внедрения многопарольной
системы защиты.
Если сервер позволяет пользователям выбрать их собственный
пароль, тогда возникает опасность несанкционированного доступа к
документам на сервере и доступа ко всем аккаунтам пользовате-
лей, кто выбрал собственные пароли. Если пользователям разре-
шен выбор собственных паролей, это означает, что сервер должен
держать файлы, содержащие пароли (предположительно в зашифро-
ванном виде). Многие из этих паролей могут принадлежать уда-
ленным пользователям. Собственник или администратор такой си-
стемы может помимо своей воли оказаться ответственным за нару-
шения безопасности сохранения информации.
Базовая аутентификация уязвима также для атак поддельных
серверов. Когда пользователь связывается с ЭВМ, содержащей ин-
формацию, защищенную с использованием базовой системой иден-
тификации, может так получиться, что в действительности он со-
единяется с сервером-злоумышленником, целью которого является
получение идентификационных параметров пользователя (напри-
мер, имени и пароля). Этот тип атак не возможен при использова-
нии идентификации с помощью дайджестов [32]. Разработчики сер-
Сети передачи данных. Метод доступа
987
веров должны учитывать возможности такого рода атак со стороны
ложный серверов или CGI-скриптов.
14.2. Предложение выбора схемы аутентификации
Сервер НТТР/1.1 может прислать несколько требований с от-
кликом 401 (Authenticate) и каждое требование может использо-
вать разную схему. Порядок присылки требований соотйетствует
шкале предпочтений сервера. Сервер должен упорядочить требова-
ния так, чтобы наиболее безопасная схема предлагалась первой.
Агент пользователя должен выбрать первую понятную ему схему.
Когда сервер предлагает выбор схемы аутентификации, исполь-
зуя заголовок WWW-Authenticate, безопасность может быть нару-
шена только за счет того, что злонамеренный пользователь может
перехватить набор требований и попытаться идентифицировать себя,
используя саму слабую схему идентификации. Таким образом, упо-
рядочение служит более для защиты идентификационных парамет-
ров пользователя, чем для защиты информации на сервере.
Возможна атака MITM (man-in-the-middle - ’’посредник"), кото-
рая заключается в добавлении слабой схемы идентификации к списку
выбора в надежде на то, что клиент выберет именно ее и раскроет
свой пароль. По этой причине клиент должен всегда использовать
наиболее строгую схему идентификации из предлагаемого списка.
Еще эффективнее может быть MITM-атака, при которой удаля-
ется весь список предлагаемых схем идентификации, и вставляется
вызов, требующий базовой схемы идентификации. По этой причине
агенты пользователя, обеспокоенные таким видом атак, могут за-
помнить самую строгую схему идентификации, которая когда-либо
запрашивалась данным сервером, и выдавать предупреждение, кото-
рое потребует подтверждения пользователя при использовании бо-
лее слабой схемы идентификации. Особенно хитроумный способ ре-
ализации MITM-атаки является предложение услуг "свободного"
кэширования для доверчивых пользователей.
14.3. Злоупотребление служебными (Log) записями сервера
Сервер должен оберегать информацию о запросах пользователя,
о характере его интересов (такая информация доступна в дневнике
операций сервера). Эта информация является, очевидно, конфиден-
циальной по своей природе и работа с ней во многих странах огра-
ничена законом. Люди, использующие протокол HTTP для получе-
ния данных, являются ответственными за то, чтобы эта информа-
ция не распространялась без разрешения лиц, кого эта информация
касается.
988
Гпава 4
14.4. Передача конфиденциальной информации
Подобно любому общему протоколу передачи данных, HTTP не
может регулировать содержимое передаваемых данных, не суще-
ствует методов определения степени конфиденциальности конк-
ретного фрагмента данных в пределах контекста запроса. Следо-
вательно, приложения должны предоставлять как можно больше
контроля провайдеру информации. Четыре поля заголовка пред-
ставляют интерес с этой точки зрения: Server, Via, Referer и From.
Раскрытие версии программного обеспечения сервера может приве-
сти к большей уязвимости машины сервера к атакам на програм-
мы с известными слабостями. Разработчики должны сделать поле
заголовка Server конфигурируемой опцией. Прокси, которые слу-
жат в качестве сетевого firewall, должны предпринимать специаль-
ные предосторожности в отношении передачи информации заго-
ловков, идентифицирующей ЭВМ, за пределы firewall. В частности
они должны удалять или замещать любые поля Via, созданные в
пределах firewall. Хотя поле Referer может быть очень полезным,
его мощь может быть использована во вред, если данные о пользо-
вателе не отделены от другой информации, содержащейся в этом
поле. Даже когда персональная информация удалена, поле Referer
может указывать на URI частных документов, чья публикация
нежелательна. Информация, посланная в поле From, может всту-
пать в конфликт с интересами конфиденциальности пользователя
или с политикой безопасности его домена, и, следовательно, она не
должна пересылаться и модифицироваться без прямого разреше-
ния пользователя. Пользователь должен быть способен устано-
вить содержимое этого поля, в противном случае оно будет уста-
новлено равным значению по умолчанию.
14.5. Атаки, основанные на именах файлов и проходов
Реализации исходных серверов HTTP должна быть тщательной,
чтобы ограничить список присылаемых HTTP-документов теми, ко-
торые определены для этого администратором сервера. Если сервер
HTTP транслирует HTTP URI непосредственно в* запросы к файло-
вой системе, сервер должен следить за тем, чтобы не пересылать
клиентам файлы, для этого не предназначенные. Например, UNIX,
Microsoft Windows и другие операционные системы используют
как компоненту прохода, чтобы указать уровень каталога выше те-
кущего. В такой системе сервер HTTP должен запретить любую
подобную конструкцию в Request-URI, в противном случае может
возникнуть доступ к ресурсу за пределами того, что предполагалось
разрешить. Аналогично, файлы, предназначенные только для внут-
Сети передачи данных. Метод доступа
989
реннего использования сервером (такие как файлы управления до-
ступом, конфигурационные файлы и коды скриптов) должны быть
защищены от несанкционированного доступа, так как они могут
содержать конфиденциальную информацию. Практика показала, что
даже незначительные ошибки в реализации сервера HTTP могут
привести к рискам безопасности.
14.6. Персональная информация
Клиентам HTTP небезразличен доступ к некоторым данным
(например, имя пользователя, IP-адрес, почтовый адрес, пароль, ключ
шифрования и т,д.) и система должна быть очень тщательно скон-
струирована, чтобы предотвратить непреднамеренную утечку инфор-
мации через протокол HTTP. Настоятельно рекомендуется, чтобы
был создан удобный интерфейс для обеспечения пользователя воз-
можностями управления распространением такой информации.
14.7. Аспекты конфиденциальности, связанные с заголовками Accept
Заголовок запроса Accept может раскрыть информацию о пользо-
вателе всем серверам, к которым имеется доступ. В частности, заго-
ловок Accept-Language может раскрыть информацию, которую пользо-
ватель, возможно, рассматривает как конфиденциальную. Так, на-
пример, понимание определенного языка часто строго коррелируется
с принадлежностью к определенной этнической группе. Агентам
пользователя, которые предлагают возможность конфигурирования
содержимого заголовка Accept-Language, настоятельно рекоменду-
ется посылать сообщение пользователю о том, что в результате мо-
жет быть потеряна конфиденциальность определенных данных.
Подходом, который ограничивает потерю конфиденциальности для
агента пользователя, может быть отказ от посылки заголовков Accept-
Language по умолчанию. Предполагается при этом каждый раз кон-
сультироваться с пользователем относительно возможности посыл-
ки этих данных серверу. Пользователь будет принимать решение о
посылке Accept-Language, лишь убедившись на основании содержи-
мого заголовка в том, что такая посылка существенно улучшит
качество обслуживания.
Для многих пользователей, которые размещены не за прокси,
сетевой адрес работающего агента пользователя может также ис-
пользоваться как его идентификатор. В среде, где прокси использу-
ются для повышения уровня конфиденциальности, агенты пользо-
вателя должны быть достаточно консервативны в предоставлении
опционного конфигурирования заголовков доступа конечным пользо-
вателям. В качестве крайней меры обеспечения защиты прокси мо-
990
Гпава 4
гут фильтровать заголовки доступа для передаваемых запросов. Глав-
ной целью агентов пользователя, которые предоставляют высокий
уровень конфигурационных возможностей, должно быть предупреж-
дение пользователя о возможной потери конфиденциальности.
14.8. Фальсификация DNS
Клиенты, интенсивно использующие HTTP-обмен со службой имен
домена (Domain Name Service), обычно предрасположены к атакам,
базирующимся на преднамеренном некорректном соответствии IP
адресов и DNS имен. Клиенты должны быть осторожны относитель-
но предположений, связанных с ассоциаций IP адресов и DNS имен.
• В частности, клиенту HTTP следует полагаться на его сервер
имен для подтверждения соответствия IP адресов и DNS имен, а не
слепо кэшировать результаты предшествующих запросов. Многие
платформы могут кэшировать такие запросы локально и это надо
использовать, конфигурируя их соответствующим образом. Такие
запросы должны кэшироваться, однако, только на период, пока не
истекло время жизни этой информации. Если клиенты HTTP кэ-
шируют результат DNS-запроса для улучшения рабочих характери-
стик, они должны отслеживать пригодность этих данных с учетом
времени жизни, объявляемого DNS-сервером.
Если клиенты HTTP не следуют этому правилу, они могут быть
мистифицированы, когда изменится IP-адрес доступного ранее сер-
вера. Так как смена адресов в сетях будет в ближайшее время
активно развиваться (Ipv6 !), такого рода атаки становятся все бо-
лее вероятными. Данное требование улучшает работу клиентов, в
том числе с серверами, имеющими идентичные имена.
14.9. Заголовки Location и мистификация
Если один сервер поддерживает несколько организаций, которые
не доверяют друг другу, тогда он должен проверять значения заго-
ловков Location и Content-Location в откликах, которые формируют-
ся под управлением этих организаций. Это следует делать, чтобы
быть уверенным, что они не пытаются провести какие-либо опера-
ции над ресурсами, доступ к которым для них ограничен.
15.1. Интерентовский тип среды "message/http"
В дополнение к определению протокола НТТР/1.1, данный до-
кумент является спецификацией для типов среды Интернет "message/
http". Ниже приведенный список является официальным для IANA.
Сети передачи данных. Метод доступа
991
Media Type name: Message (сообщение)
Media subtype name: http
Required parameters: none (параметры не требуются)
Optional parameters: version, msgtype (версия, тип сообщения)
version. Номер версии вложенного сообщения HTTP (напр., "1.1").
Если отсутствует, номер версии может быть определен по
первой строке тела сообщения»
msgtype. Тип сообщения — "запроса" или "отклика". Если отсут-
ствует, тип может быть определен по первой строке тела
сообщения.
Соображения кодирования: разрешено только "7bit", "8bit” или
"binary" (двоичное).
15.2. Тип среды Интернет "multipart/byteranges"
Когда сообщение HTTP содержит несколько фрагментов (ranges)
(например, отклик на запрос нескольких не перекрывающихся фраг-
ментов), они пересылаются как многофрагментное сообщение MIME.
Тип среды multipart для этих целей носит название "’multipart/
byteranges".
Тип среды multi part/byteranges содержит в себе две или более
части, каждая из которых со своими полями Content-Type и Content-
Range. Отдельные части разделяются с использованием погранич-
ного параметра MIME.
Media Type name: multipart
Media subtype name: byteranges
Required parameters: boundary v
Optional parameters:none (опционные параметры отсутствуют)
Соображения кодирования: разрешено только "7bit", "8bit" или
"binary".
Например:
НТТР/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT Content-type:
ultipart/byteranges; boundary=THIS_STRING_SEP AR ATES
—THIS_STRING_SE PAR ATES
Content-type: application/pdf
Content-range: bytes 500-999/8000
...первый фрагмент ...
—THIS__STRING_SEPARATES
Content-type: application/pdf
992
Гпава 4
Content-range: bytes 7000-7999/8000
...второй фрагмент...
—THIS_STRING_SEPARATES—
15.3. Толерантные приложения
Хотя этот раздел специфицирует требования к генерации HTTP/
1.1 сообщений, не все приложения будут корректны. Мы, следова-
тельно, рекомендуем, чтобы рабочие приложения были толерантны
(терпимы) к некоторым отклонениям от требований, при условии,
что эти отклонения можно однозначно интерпретировать. Клиенту
следует быть толерантным при разборе Status-Line, а серверу - при
разборе Request-Line. В частности, им следует воспринимать любое
число символов SP или НТ между полями, хотя требуется только
один пробел (SP). Терминатором строки полей заголовков сообще-
ния является CRLF. Однако рекомендуется, чтобы приложение при
разборе таких заголовков распознавало в качестве терминатора стро-
ки одиночный символ LF и игнорировало предыдущий символ CR.
Символьный набор тела объекта должен быть снабжен меткой. Мет-
ка не нужна только для набора US-ASCII или ISO-8859-1. Правила
разбора и кодирования дат и пр. включают в себя предположение,
что клиенты и кэши НТТР/1.1 должны предполагать, что даты,
следующие документу RFC-850 и относящиеся ко времени 50 лет в
будущем, на самом деле относятся к прошлому (это помогает ре-
шить проблему ”2000-го года’’).
• Приложение НТТР/1.1 может внутри представлять время ис-
течения годности раньше, чем истинное значение, но не должно
устанавливать его позднее истинного значения.
• Все вычисления, относящиеся йо времени пригодности долж-
ны выполняться в шкале GMT (по Гринвичу). Местные временные
зоны не должны оказывать влияния на вычисления и сравнение
возраста и времени пригодности.
Если заголовок HTTP несет в себе некорректное значение даты с
временной зоной отличной от GMT, значение должно быть преобра-
зовано в GMT.
15.4. Различие между объектами HTTP и MIME
НТТР/1.1 использует много конструкций, определенных для элек-
тронной почты Интернет (RFC 822) и MIME (Multipurpose Internet
Mail Extensions), для обеспечения пересылки объектов в различных
представлениях. MIME [7] обслуживает электронную почту, a HTTP
имеет лишь ряд черт, которые отличают его от MIME. Эти отличия
тщательна подобраны, чтобы оптимизировать работу в условиях
Сети передачи данных. Метод доступа
993
двоичных соединений, с тем, чтобы достичь большей свободы в ис-
пользовании новых типов сред.
15.4.1. Преобразование к канонической форме
MIME требует, чтобы почтовый объект Интернет перед посылкой
был преобразован в каноническую форму. Раздел 2.7.1 описывает
формы, допустимые для подтипов типа среды "text” при пересылке с
использованием HTTP. MIME требует, чтобы содержимое типа "text”
представляло разрывы строк в виде последовательности символов
CRLF и запрещает использование CR или LF отдельно. Для обозна-
чения разрыва строки HTTP позволяет использовать CRLF, одиноч-
ный CR и одиночный LF. Всюду где возможно, прокси и шлюзы
между средами HTTP и MIME должны преобразовать все разрывы
строк для текстовых типов среды, как это описано в разделе 2.7.1.
Заметьте однако, что это может вызвать сложности в присутствии
кодирования содержимого, а также вследствие того, что HTTP до-
пускает применение символьных наборов, которые не используют
октеты 13 и 10 для представления CR и LF, так как для этих целей
здесь служат многобайтовые последовательности.
15.4.2. Преобразование форматов даты
Для того чтобы упростить сравнение, НТТР/1.1 использует ог-
раниченный набор форматов даты (раздел 2.3.1). Прокси и шлюзы
должны позаботиться о преобразовании полей заголовков даты в
один из допустимых форматов всякий раз, когда это необходимо
(при получении данных от других протоколов).
15.4.3. Введение кодирования содержимого
MIME не содержит какого-либо эквивалента полю заголовка Content-
Encoding НТТР/1.1. Так как это поле работает как модификатор
типа среды, прокси и шлюзы между HTTP и MIME протоколами долж-
ны или изменить значение поля заголовка Content-Type или декодиро-
вать тело объекта, прежде чем переадресовывать сообщение. Некото-
рые экспериментальные приложения Content-Type для почты Интер-
нет используют параметр типа среды ”;conversions=<content-coding>”
Для выполнения операции, аналогичной Content-Encoding. Однако этот
параметр не является частью MIME.
15.4.4. No Content-Transfer-Encoding
HTTP не использует поле MIME СТЕ (Content-Transfer-Encoding).
Прокси и шлюзы от MIME к HTTP должны удалять любую не
^2 Зак. Na 3430 Семенов
994
Гпава 4
идентичность СТЕ (’’quoted-printable" или "base64") кодирования,
прежде чем доставлять сообщение-отклик клиенту HTTP.
Прокси и шлюзы от HTTP к MIME ответственны за то, чтобы
сообщения имели корректные форматы и кодировки для безопасной
транспортировки, (где безопасная транспортировка определяется ог-
раничениями используемого протокола). Такие прокси и шлюзы
должны помечать информацию согласно Content-Transfer-Encoding,
поступая так, мы улучшаем вероятность безопасной транспорти-
ровки с использованием протокола места назначения.
15.4.5. Поля заголовка в многофрагментных телах
В MIME, большинство полей заголовка в многофрагментных ча-
стях игнорируются, если только имя поля не начинается с "Content-
’’. В НТТР/1.1, многофрагментные части тела могут содержать лю-
бые поля заголовков HTTP, которые имеют смысл для этой части.
15.4.6. Введение транспортного кодирования
НТТР/1.1 вводит поле заголовка Transfer-Encoding (раздел
13.40). Прокси/шлюзы должны удалять любое транспортное коди-
рование перед переадресацией сообщения через протокол MIME.
15.4.7. MIME-версия
HTTP не является протоколом, совместимым с MIME (смотри
15.4). Однако, НТТР/1.1 сообщения могут включать поле общего
заголовка MIME-Version, для того чтобы указать, какая версия про-
токола MIME была использована для конструирования сообщения.
Использование заголовка поля MIME-Version отмечает, что сообще-
ние полностью соответствует протоколу MIME. Прокси/шлюзы не-
сут ответственность за полную совместимость (где возможно), когда
осуществляется передача HTTP сообщений в среду MIME.
MIME-Version = "MIME-Version" ":" 1*DIGIT 1*DIGIT
HTTP/1.1 использует по умолчанию версию MIME "1.0". Одна-
ко, разбор сообщений НТТР/1.1 и семантика определяются данным
документом, а не спецификацией MIME.
15.5. Изменения с целью упрощения многоинтерфейсных
WWW-серверов и экономии IP адресов
Требование того, чтобы клиенты и серверы воспринимали абсо-
лютные URI (раздел 4.1.2) и поддерживали заголовки Host, откли-
кались кодами ошибки при отсутствии заголовка Host (раздел 13.23)
Сети передачи данных. Метод доступа
995
в запросе НТТР/1.1, являются наиболее важными изменениями,
внесенными данной спецификацией.
Более старые НТТР/1.0 клиенты предполагают однозначное со-
ответствие IP адресов и серверов. Изменения, описанные выше, по-
зволяют Интернет поддерживать несколько WWW узлов с помо-
щью одного IP-адреса. Высокая скорость роста WWW-сети, боль-
шое число уже существующих серверов делают крайне важным, чтобы
реализации HTTP (включая усовершенствования существующих
НТТР/1.0 приложений) корректно следовали перечисленным ниже
требованиям:
• Как клиент, так и сервер должны поддерживать заголовки
запроса Host.
• Заголовки Host необходимы в запросах НТТР/1.1.
• Серверы должны откликаться кодом ошибки 400 (Bad Request)*,
если запрос НТТР/1.1 не содержит заголовка Host.
• Серверы должны воспринимать абсолютные URL
15.6. Дополнительные методы запросов
15.6.1. Метод PATCH
Метод PATCH подобен PUT, за исключением того, что объект
содержит список отличий между оригинальной версией ресурса, иден-
тифицированного Request-URI, и желательной версией ресурса пос-
ле операции PATCH. Список отличий записываемся в формате, оп-
ределенном типом среды объекта (например, "application/diff"), и
должен включать достаточную информацию, чтобы позволить серве-
ру выполнить изменения по преобразованию ресурса из исходной
версии в заказанную. Если запрос проходит через кэш и Request-
URI идентифицирует объект в кэше, этот объект должен быть уда-
лен из кэша. Отклики для этого метода не кэшируются.
Реальный метод определения того, как разместится скорректи-
рованный ресурс и что случится с его предшественником, определя-
ется исключительно исходным сервером. Если оригинальная вер-
сия ресурса, который предполагается скорректировать, включает в
себя поле заголовка Content-Version, объект запроса должен вклю-
чать поле заголовка Derived-From, соответствующее значению ори-
гинального поля заголовка Content-Version. Приложениям реко-
мендуется использовать эти поля для работы с версиями с целью
разрешения соответствующих конфликтов. Запросы PATCH долж-
ны подчиняться требованиям к передаче сообщений, установлен-
ным в разделе 7.2. Кэши, которые реализуют PATCH, должны объя-
вить кэшированные отклики недействительными, как это описано в
разделе 12.10 для PUT.
32*
896
Гпава 4
15.6.2. Метод LINK
Метод LINK устанавливает один или более связей между ресур-
сами, идентифицированными Request-URI, и другими существующи-
ми ресурсами. Отличие между LINK и другими методами, допускаю-
щими установление связей между ресурсами, заключается в том, что
метод LINK не допускает посылки в запросе тела сообщения и не
вызывает непосредственно создания новых ресурсов. Если запрос
проходит через кэш и Request-URI идентифицирует кэшированный
объект, этот объект должен быть удален из кэша. Отклики на этот
метод не кэшируются. Кэши, которые реализуют LINK, должны объя-
вить кэшированные отклики непригодными, как это определено в
разделе 12.10 для PUT.
15.6.3. Метод UNLINK
Метод UNLINK удаляет одну или более связей между ресурсами,
идентифицированными Request-URI. Эти связи могут быть установ-
лены с использованием метода LINK или каким-либо другим мето-
дом, поддерживающим заголовок Link. Удаление связи с ресурсом
не подразумевает, что ресурс перестает существовать или становится
недоступным. Если запрос проходит через кэш и Request-URI иден-
тифицирует кэшированный объект, этот объект должен быть уда-
лен из кэша. Отклики на этот метод не кэшируются. Кэши, кото-
рые реализуют UNLINK, должны объявить кэшированные отклики
непригодными, как это определено в разделе 12.10 для PUT.
15.7. Определения дополнительных полей заголовка
15.7.1. Поле Alternates
Поле заголовка отклика Alternates было предложено в качестве
средства исходного сервера для информирования клиента о других
доступных представлениях запрошенного ресурса. При этом выдает-
ся информация об их специфических атрибутах, все это образует бо-
лее надежное основание агенту пользователя для выбора представле-
ния, которое лучше соответствует желаниям пользователя (описано
как согласование под управлением агента пользователя в разделе
11). Поле заголовка Alternates является ортогональным по отноше-
нию к полю заголовка Vary, вместе с тем они могут сосуществовать в
сообщении без последствий для интерпретации отклика или доступ-
ных представлений. Ожидается, что поле Alternates предоставит за-
метное улучшение по сравнению с согласованием под управлением
сервера, предоставляемым полем Vary для ресурсов, которые варьи-
руются в общих пределах подобно типу и языку.
Сети передачи данных. Метод доступа
997
15.7.2. Поле Content-Version
Поле заголовка объекта Content-Version определяет метку вер-
сии, ассоциированную с отображением объекта. Вместе с полем
Derived-From (15.7.3), это позволяет группе людей вести работу в
интерактивном режиме.
Con tent-Version = "Content-Version” quoted-string.
Примеры использования поля Content-Version:
Content-Version: "2.1.2”
Content-Version: "Fred 19950116-12:26:48”
Content-Version: "2.5a4-omega7"
15.7.3. Поле Derived-From
Поле заголовка объекта Derived-From может использоваться для
индикации метки версии ресурса, из которого был извлечен объект до
модификации, выполненной отправителем. Это поле используется для
того, чтобы помочь управлять процессом эволюции ресурса, в частно-
сти, когда изменения выполняются в параллель многими субъектами.
Derived-From = "Derived-From" ":” quoted-string.
Пример использования поля:
Derived-From: "2.1.1".
'Ис-
Поле Derived-From необходимо для запросов PUT и PATCH, если
посланный объект был перед этим извлечен из того же URI и заго-
ловок Content-Version был включен в объект, когда он последний
раз извлекался.
15.7.4. Поле Link
Поле заголовка объекта Link предоставляет средства для описа-
ния взаимоотношений между ресурсами. Объект может включать
много значений поля Link. Связи на уровне метаинформации обыч-
но указывают на отношения типа структуры иерархии и пути про-
хода. Поле Link семантически эквивалентно элементу <LINK> в
HTML [5].
Link = "Link" ":"#("<" URI ">" link-param)
link-param = (("rel” "=" relationship )
| ("rev" "=” relationship)
| ( "title" "=" quoted-string )
I ( "anchor" "=" <"> URI <"> )
| (link-extension ))
link-extension = token ["=" (token | quoted-string )]
998
Гпава 4
relationship == sgml-name
I ( < ”> sgml-name *( SP sgml-name) <”> )
sgml-name = ALPHA *( ALPHA | DIGIT | | "-")
Запись значений отношения не зависит от использования строч-
ных или прописных букв и может быть расширена в рамках син-
таксиса имен sgml. Параметр заголовка может быть использован
для пометки места назначения связи, которая используется при иден-
тификации в рамках меню пользователя. Параметр типа якорь мо-
жет использоваться для индикации источника якоря, отличного от
всего текущего ресурса, например, фрагмент данного ресурса. Приме-
ры использования:
Link: <http://www.cern.ch/TheBook/chapter2>; rel=”Previous”
Link: <mailto:timbl@w3.org>; rev="Made”; title=”Tim Berners-Lee"
Первый пример указывает, что глава 2 предшествует данному
ресурсу с точки зрения логического прохода. Второй отмечает, что
лицо, ответственное за данный ресурс, имеет приведенный адрес элек-
тронной почты.
15.7.5. Поле URI
Поле заголовка URI использовалось в прошлых версиях данной
спецификации как комбинация существующих полей заголовка
Location, Content-Location и Vary. Его первоначальной целью явля-
лось включение списка дополнительных URI для ресурса, включая
имена и положение зеркал. Однако стало ясно, что комбинация
многих разлйчных функций в пределах одного поля мешает эффек-
тивной их реализации. Более того, мы полагаем, что идентифика-
цию имен и положения зеркал лучше осуществлять через поле заго-
ловка Link. Поле заголовка URI было признано менее удобным, чем
эти поля.
URLheader = "URI" ":" 1#( ”<" URI ">" )
15.8. Совместимость с предыдущими версиями
Версия НТТР/1.1 была специально спроектирована так, чтобы
обеспечить совместимость с предыдущими версиями. Следует заме-
тить, что на фазе разработки этой спецификации предполагалось,
что коммерческие НТТР/1.1 серверы будут следовать следующим
правилам:
• распознают формат Request-Line для запросов НТГР/0.9,1.0 и 1.1;
• воспринимают любой корректный запрос в формате НТТР/0.9,
1.0 или 1.1;
Сети передачи данных. Метод доступа
999
• корректно откликаются сообщениями той же версии, что ис-
пользовал клиент.
Мы также ожидаем, что клиенты НТТР/1.1:
• распознают формат откликов Status-Line для HTTP/1.0 и 1.1;
• воспринимают любой корректный отклик в формате НТТР/0.9,
1.0 или 1.1.
Для большинства реализаций НТТР/1.0, каждое соединение ус-
танавливается клиентом до посылки запроса и закрывается серве-
ром после посылки отклика. Некоторые реализации используют
версию Keep-Alive постоянного соединения, описанную в разделе
15.8.1.1.
15.8.1. Совместимость с постоянными соединениями НТТР/1.0
Некоторые клиенты и серверы могут пожелать быть совмести-
мыми с некоторыми предшествующими реализациями НТТР/1.0
постоянных соединений клиента и сервера. Постоянные соединения
в НТТР/1.0 должны согласовываться в явном виде, так как это не
является вариантом по умолчанию. Экспериментальные реализа-
ции постоянных соединений в НТТР/1.0 не лишены ошибок. Про-
блема была в том, что некоторые существующие клиенты 1.0 могут
посылать Keep-Alive прокси-серверу/который не воспринимает поле
Connection, и ошибочно переадресует его ближайшему серверу. Пос-
ледний установит соединение Keep-Alive, что приведет к повисанию
системы, так как прокси будет ждать close для отклика. В результате
клиентам НТТР/1.0 должно быть запрещено использование Keep-
Alive, когда они работают с прокси. Однако взаимодействие с прокси
является наиболее важным использованием постоянных соедине-
ний, по этой причине подобный запрет является не приемлемым.
Следовательно, нам нужен какой-то другой механизм для индика-
ции намерения установить постоянное соединение. Этот механизм
должен быть безопасным даже при взаимодействии со старыми про-
кси, которые игнорируют Connection. Постоянные соединения для
сообщений НТТР/1.1 работают по умолчанию; мы вводим новое
ключевое слово (Connection: close) для декларации непостоянства
соединения. Ниже описана оригинальная форма постоянных соеди-
нений для НТТР/1.0.
Когда HTTP клиент соединяется с исходным сервером, он мо-
жет послать лексему соединения Keep-Alive в дополнение к лексеме
соединения Persist:
Connection: Keep-Alive.
1000
Глава 4
Сервер НТТР/1.0 откликнется лексемой соединения Keep-Alive
и клиент сможет установить постоянное (или Keep-Alive) соедине-
ние с НТТР/1.0. Сервер НТТР/1.1 может также установить посто-
янное соединение с клиентом НТТР/1.0 по получении лексемы со-
единения Keep-Alive. Однако постоянное соединение с клиентом
НТТР/1.0 не может быть использовано для по-фрагментного коди-
рования и, следовательно, должно использовать Content-Length для
пометки конца каждого сообщения. Клиент не должен посылать
лексему соединения Keep-Alive прокси-серверу, так как прокси-сер-
веры НТТР/1.0 не следуют правилам НТТР/1.1 при разборе поля
заголовка Connection.
15.8.1.1. Заголовок Keep-Alive
Когда лексема соединения Keep-Alive передана с рамках запроса
или отклика, поле заголовка Keep-Alive может также присутство-
вать. Поле заголовка Keep-Alive имеет следующую форму:
Keep-Alive-header = ’’Keep-Alive" 0# keepalive-param
keepalive-param = param-name value.
Заголовок Keep-Alive является опционным и используется, если
передается параметр. НТТР/1.1 не определяет каких-либо пара-
метров. Если посылается заголовок Keep-Alive, должна быть пере-
дана соответствующая лексема соединения. Заголовок Keep-Alive
без лексемы соединения должен игнорироваться.
16. Библиография
[1] Alvestrand, Н., «Tags for the identification of languages», RFC
1766, UNINETT, March 1995.
[2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D.,
and B. Alberti. «The Internet Gopher Protocol: (a distributed
document search and retrieval protocol)», RFC 1436, University
of Minnesota, March 1993
[3] Berners-Lee, T., «Universal Resource Identifiers in WWW», A
Unifying Syntax for the Expression of Names and Addresses of
Objects on the Network as used in the World-Wide Web», RFC
1630, CERN, June 1994
[4] Berners-Lee, T., Masinter, L., and M. McCahill, «Uniform
Resource Locators (URL)», RFC 1738, CERN, Xerox PARC,
University of Minnesota, December 1994
[5] Berners-Lee, T., and D. Connolly, «HyperText Markup Language
Specification - 2.0», RFC 1866, MIT/LCS, November 1995
Сети передачи данных. Метод доступа
1001
[6] Berners-Lee, Т., Fielding, R., and Н. Frystyk, «Hypertext
Transfer Protocol — HTTP/1.0.», RFC 1945 MIT/LCS, UC
Irvine, May 1996
[7] Freed,N.,and N. Borenstein,« Multi purpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies», RFC 2045, Innosoft, First Virtual, November 1996.
[8] Braden, R., «Requirements for Internet hosts - application and
support», STD3, RFC 1123, IETF, October 1989
[9] Crocker, D., «Standard for the Format of ARPA Internet Text
Messages», STD 11, RFC 822, UDEL, August 1982
[10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., Sui,
J., and M. Grinbaum. «WAIS Interface Protocol Prototype
Functional Specification», (vl.5), Thinking Machines
Corporation, April 1990
[11] Fielding, R., «Relative Uniform Resource Locators», RFC 1808,
UC Irvine, June 1995
[12] Horton, M., and R. Adams. «Standard for interchange of
USENET messages», RFC 1036, AT&T Bell Laboratories, Center
for Seismic Studies, December 1987
[13] Kantor, B., and P. Lapsley. «Network-News Transfer Protocol.»
A Proposed Standard for the Stream-Based Transmission of
News», RFC 977, UC San Diego, UC Berkeley, February 1986
[14] Moore,K.,«MIME(Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text», RFC
2047, University of Tennessee, November 1996
[15] Nebel, E., and L. Masinter. «Form-based File Upload in HTML»,
RFC 1867, Xerox Corporation, November 1995.
[16] Postel, J., «Simple Mail Transfer Protocol», STD 10, RFC 821,
USC/ISI, August 1982
[17] Postel, J., «Media Type Registration Procedure», RFC 2048, USC/
ISI, November 1996
[18] Postel, J., and J. Reynolds, «File Transfer Protocol (FTP)», STD
9, RFC 959, USC/ISI, October 1985
[19] Reynolds, J., and J. Postel, «Assigned Numbers», STD 2,
RFC1700, USC/ISI, October 1994
[20] Soilins, K., and L. Masinter, «Functional Requirements for
Uniform Resource Names», RFC 1737, MIT/LCS, Xerox
Corporation, December 1994
[21 ] KS-ASCII. Coded Character Set - 7-Bit American Standard Code for
Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986
[22] ISO-8859. International Standard — Information Processing —
8-bit Single-Byte Coded Graphic Character Sets
1002
Гпава 4
Part 1: Latin alphabet No. 1, ISO 8859-1:1987
Part 2: Latin alphabet No. 2, ISO 8859-2, 1987
Part 3: Latin alphabet No. 3, ISO 8859-3, 1988
Part 4: Latin alphabet No. 4, ISO 8859-4, 1988
Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988
Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987
Part 7: Latin/Greek alphabet, ISO 8859-7, 1987
Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988
Part 9: Latin alphabet No. 5, ISO 8859-9, 1990
[23] Meyers, J., and M. Rose «The Content-MD5 Header Field»,
RFC1864, Carnegie Mellon, Dover Beach Consulting, October,
1995
[24] Carpenter, B., and Y. Rekhter, «Renumbering Needs Work»,
RFC 1900, IAB, February 1996.
[25] Deutsch, P., «GZIP file format specification version 4.3.»
RFC1952, Aladdin Enterprises, May 1996
[26] Venkata N. Padmanabhan and Jeffrey C. Mogul. Improving
HTTP Latency. Computer Networks and ISDN Systems, v. 28,
pp. 25-35, Dec. 1995. Slightly revised version of paper in Proc.
2nd International WWW Conf. ’94: Mosaic and the Web, Oct.
1994, which is available at http: / / www.ncsa.uiuc.edu/SPG /
IT94/Proceedings/РРау/ mogul/HTTPLatency.html.
[27] Joe Touch, John Heidemann, and Katia Obraczka, «Analysis of
HTTP Performance», <URL: http://www.isi.edu/lsam/ib/http-
perf/>. USC/Information Sciences Institute, June 1996
[28] Mills, D., «Network Time Protocol, Version 3, Specification,
Implementation and Analysis», RFC 1305, University of
Delaware, March 1992
[29] Deutsch, P., «DEFLATE Compressed Data Format Specification
version 1.3.» RFC 1951, Aladdin Enterprises, May 1996
[30] Spero, S., «Analysis of HTTP Performance Problems»
<URL:http://sunsite.unc.edu/mdma-release/http-prob.html>.
[31] Deutsch, P., and J-L. Gailly, «ZLIB Compressed Data Format
Specification version 3.3», RFC 1950, Aladdin Enterprises, Info-
ZIP, May 1996
[32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A.,
Sink, E., and L. Stewart, «An Extension to HTTP : Digest
Access Authentication», RFC 2069, January 1997
Сети передачи данных. Метод доступа
1003
4.5.6. Протокол пересылки новостей NNTP (USENET)
Современное общество предъявляет весьма жесткие требования
ко времени получения событийной информации. Это могут быть
технические новинки, политические новости, уведомления о событи-
ях (произошедших или грядущих) и т.д. Одной из форм оператив-
ной рассылки и получения информации является электронная по-
чта (в частности система LISTSERV). В таких системах помимо
воли клиента в его почтовом ящике, как правило, скапливается
огромное количество сообщений. Причем в настоящее время здесь
нет пока каких-либо механизмов фильтрации. Несколько иное ре-
шение предлагает протокол NNTP и сеть рассылки новостей USENET
(смотри RFC-0977, Network News Transfer Protocol, В. Kantor,
P.Lapsley. and RFC-1036, Standard for interchange of USENET
messages, M.R. Horton, R. Adams). В USENET системе сообщение
запоминается в базе данных сервера, а не в почтовых ящиках под-
писчиков. Региональный депозитарий снабжается специальным
программным обеспечением, которое позволяет подписчику отби-
рать статьи, представляющие для него интерес. Система имеет ин-
дексацию, облегчающую поиск, и удаление устаревших статей. Про-
токол NNTP определяет то, как должны функционировать программы
клиента и сервера.
Для кластеров ЭВМ, объединенных ETHERNET (или другой бы-
стродействующей локальной сетью) представляется целесообразным
сконцентрировать функции хранения и распределения новостей в
одном узле. При этом клиент может запросить любую статью тог-
да, когда это ему нужно, и он не обязан предоставлять ресурсы для
хранения копий статей. Учитывая то, что даже в небольшой ло-
кальной сети обычно достаточно много клиентов-подписчиков та-
кая схема позволяет сэкономить достаточно большой объем диско-
вого пространства. Следует учитывать, что интегральный поток но-
востей сегодня превышает 300 Мбайт в сутки.
Сервер новостей должен размещаться в локальной сети, так как
именно в этом случае время доступа минимально. Этот сервер дол-
жен заниматься сбором новостей и созданием необходимых индек-
сных файлов. При большом числе ЭВМ такая схема дает значи-
тельную экономию дискового пространства.
NNTP представляет собой протокол для рассылки, подписки,
поиска и доставки новостей на основе надежного протокола поточ-
ного типа (например, TCP) с использованием схемы клиент-сервер.
1004 Глава 4 |
- ----- — - — — ---- «
15
NNTP сконструирован так, что статья, записанная в одном из сер- ;
веров, становится доступной для всех подписчиков-клиентов.
Протокол NNTP предполагает применения стандартных сооб-
щений, формат которых следует рекомендациям RFC 850. NNTP-
сервер обычно работает в фоновом режиме. В больших сетях, где
число клиентов велико, возможно использование нескольких серве-
ров новостей, которые образуют иерархическую систему. При этом
клиент сначала пытается подключиться к ближайшему серверу.
При неуспехе соединение либо абортируется, либо переадресуется
другому серверу.
Единицей хранения на сервере является статья. Статьи состав-
ляют содержательную часть пересылаемых сообщений. В NNTP
предусмотрены команды, которые обеспечивают непосредственный
обмен статьями между взаимодействующими узлами (более эффек-
тивно, чем это позволяет, например, UUCP).
Традиционный метод рассылки новостей предполагает распрост-
ранение статей от узла к узлу, так что каждый сервер пересылает
другому все новости, которые имеет. При этом неизбежно дублиро-
вание, связанное с этим увеличение трафика и повышенный расход
ресурсов ЭВМ. Но такая схема предельно проста и вполне оправда-
на, когда обмен новостями происходит один раз в сутки (дубликаты
статей могут быть отфильтрованы позднее).
При использовании NNTP ЭВМ, обменивающиеся новостями,
пользуются интерактивным механизмом в процессе принятия ре-
шения о том, какие статьи следует передать. При этом ЭВМ кон-
тактирует с одним или несколькими серверами новостей. Процеду-
ра начинается с запроса о формировании новых групп новостей, для
чего выдается команда NEWGROUPS. Далее клиент делает запрос о
наличии новых статей из групп, представляющих интерес (команда
NEWNEWS). В ответ сервер высылает список статей, а клиент мо-
жет запросить их присыДку, если он их не имеет. В заключение
клиент может сообщить серверу, какие новые статьи он получил в
последнее время.
Сервер новостей, специфицированный в NNTP, использует по-
точный обмен (подобный TCP), а также набор команд и откликов,
схожий с SMTP. Этот сервер является единственным интерфейсом
между программами и базами данных, хранящими новости. Он не
выполняет взаимодействия с пользователем или каких-либо опера-
ций презентационного уровня. Эти функции передаются програм-
мам клиента, которые имеют исчерпывающую информацию о среде-
При работе через Интернет в рамках протокола TCP используется
порт 119. На команды, посылаемые клиентом, предусмотрены тек-
Сети передачи данных. Метод доступа
1005
стовые и статусные отклики. Всякая сессия начинается с процеду-
ры установления соединения между клиентом и сервером по ини-
циативе клиента.
Текст может посылаться только после цифрового статусного от-
клика. Текст имеет вид последовательности строк, каждая из кото-
рых завершается парой символов CR-LF. В конце текста всегда
посылается строка, содержащая один символ (.), за которым следу-
ет CR-LF (как и в SMTP).
Если исходный текст содержит точку в начале строки, то она
перед посылкой должна быть задублирована. Таким образом, кли-
ент должен просматривать первые символы каждой полученной стро-
ки и, если это одиночная точка, прерывать дальнейший прием тек-
ста. Предполагается, что текстовый отклик будет отображен на дис-
плее пользователя, в то время как командно-статусный отклик
интерпретируется программой клиента.
Статусный отклик представляет собой реакцию сервера на ко-
манду, полученную от клиента. Строки статусного отклика начина-
ются с 3-значного десятичного кода, достаточного для описания
любого отклика. Некоторые коды являются предшественниками
последующего текстового отклика. Первая цифра говорит об успехе,
ошибке или процессе исполнения команды.
Ixx Информационное сообщение
2 хх Команда ок
Зхх Команда корректна, можно продолжать обмен.
4хх Команда корректна, но не может быть выполнена по
какой-то причине.
5хх Команда неприменима, неверна или произошла серьез-
ная ошибка в программе.
Следующая цифра кода характеризует категорию отклика.
хОх Соединение, установка режима, прочие сообщения
xlx Выбор группы новостей
х2х Выбор статьи
хЗх Функции распределения
х4х Отправка адресату
х8х Нестандартное (частное применение) расширение
х9х Отладочный вывод
Конкретное значение кодов отклика можно найти только в опи-
сании конкретной команды. Ниже приведен список кодов общего
назначения, которые могут быть получены в любое время.
Некоторые статусные отклики могут иметь параметры (числа
Или имена). Число и тип параметров фиксировано для каждого
1006
Гпава 4
конкретного отклика. Параметры отделяются от кода отклика и
друг от друга одиночным пробелом. Все цифровые параметры имеют
десятичное представление и могут начинаться с нулей. Все строко-
вые параметры начинаются после пробела и завершаются пробелом
или символьной парой CR-LF, то есть не могут содержать в себе
пробелов. Любой текст, который не является параметром отклика,
должен отделяться от последнего параметра, если таковой имеется,
пробелом и завершаться пробелом.
Не специфицированные коды-отклики могут использоваться для
специфических новых команд. Такой код должен относиться к ка-
тегории х8х (см. таблицу, приведенную выше). Применение не спе-
цифицированных откликов для стандартных команд запрещено.
Коды категории х9х зарезервированы для отладочных целей.
Так как большинство отладочных откликов можно рассматривать
как информационные сообщения, для отладочных выдач зарезерви-
рован диапазон кодов 190-199. *
Ниже приведен список сообщений общего назначения, которые
может послать NNTP сервер. Эти отклики не привязаны к каким-
то конкретным командам и могут быть присланы в результате
сбоя или каких-то других необычных обстоятельств.
Вообще говоря, коды 1хх могут игнорироваться; коды 200 или
201 посылаются при начальном подключении к NNTP серверу в
зависимости обналичил разрешения пересылки. Код 400 отправля-
ется, хогда NNTRсервер прерывает обслуживание, например по зап-
росу оператора, а коды 5хх указывают на то, что процедура не будет
выполнена, по какой-то необычной причине.
100 Поясняющий текст
190 - 199 Отладочный вывод
200 Сервер готов - отправка разрешена
201 Сервер готов - отправка запрещена
400 Обслуживание прерывается
500 Команда не распознана
501 Синтаксическая ошибка в команде
502 Доступ ограничен или нет разрешения
503 Ошибка в программе - команда не выполнена
Команды записываются в этом документе прописными буквами,
хотя NNTP сервер игнорирует регистр, в котором они напечатаны.
Параметры команд, помещенные в квадратные скобки, являются
опционными. Длина команды не должна превышать 512 байт.
Сети передачи данных. Метод доступа
1007
Команды ARTICLE, BODY, HEAD и STAT
Существует две формы команды ARTICLE (и соответственно ко-
манд BODY, HEAD, и STAT), каждая из которых использует различ-
ные методы спецификации извлекаемой статьи. Когда за командой
ARTICLE следует идентификатор сообщения в угольных скобках
и ”>”), используется первая форма команды; когда же имеется
цифровой параметр или нет параметра совсем, реализуется вторая
форма. Текст статьи присылается в виде текстового отклика.
Команды HEAD и BODY идентичны команде ARTICLE за исклю-
чением того, что они возвращают соответственно только строки
заголовка или основной текст статьи.
Команда STAT похожа на команду ARTICLE за исключением
того, что не присылается никакого текста. Выбирая номер сообще-
ния в пределах группы, команда STAT служит для установки указа-
теля статьи без пересылки какого-либо текста. Возвращаемый от-
клик содержит идентификатор сообщения. Использование команды
STAT для выбора статей по их идентификатору вполне работоспо-
собно, хотя и не слишком эффективно, так как такой отбор не
изменяет текущий указатель статьи.
ARTICLE <message-id>
Команда отображает заголовок, пустую строку и текст заданной
статьи. Идентификатор сообщения (message-id) представляет собой
идентификатор, представленный в заголовке статьи. Предполагает-
ся, что клиент получит идентификатор сообщения из списка, предо-
ставляемого командой NEWNEWS. Команда не изменяет указате-
ля текущей статьи.
ARTICLE [nnn]
Отображает заголовок, пустую строку и текст текущей или спе-
цифицированной статьи. Опционный параметр nnn представляет
собой числовой идентификатор статьи (номер) в текущей группе
новостей. Он должен быть выбран из диапазона, который был вы-
дан при выборе группы. Если этого параметра нет, предполагается
текущая статья. Эта команда устанавливает указатель текущей ста-
тьи, если номер статьи указан корректно.
Откликом на команду будет номер текущей статьи, строка-иденти-
фикатор сообщения и собственно текст статьи. Присылаемая строка
идентификатора сообщения представляет собой последовательность
символов, заключенную в угловые скобки, которая извлечена из заго-
ловка статьи (согласно RFC850). Если идентификаторная строка за-
головка в статье отсутствует, в угловых скобках будет записан нуль.
1008
Гпава 4
Так как поле идентификатора сообщения . для каждой статьи
уникально, оно может использоваться для поиска и удаления ста-
тей-дубликатов.
Отклики:
220 n <а> article retrieved - далее следует заголовок и сама
статья (п = номер статьи,
<а> = message-id)
221 n <а> article retrieved - далее следует заголовок
222 n <а> article retrieved - далее следует текст статьи
223 n <а> article retrieved - текст запрашивается отдельно
412 no newsgroup has been selected - не выбрано никакой
группы
420 no current article has been selected - не выбрана статья
423 по such article number in this group - в этой группе нет статьи
430 no such article found - такая статья не найдена
Команда GROUP ggg
Обязательный параметр ggg представляет собой имя группы
новостей, которая должна быть выбрана. Список доступных групп
новостей может быть получен с помощью команды LIST.
Отклик на успешный выбор группы возвращает номера первой и
последней статьи в группе и оценку общего числа статей в группе.
Оценка может быть и не вполне корректной, она равна или превос-
ходит реальное число статей.
Когда с помощью данной команды группа выбрана, внутренний
указатель статьи устанавливается на первую запись в группе. Если
выбрана несуществующая группа, остается в силе выбор предыду-
щей группы. При наборе имени группы выбранный регистр (строч-
ные или прописные буквы) не играет роли.
Отклики:
211 n f 1 s group selected - группа выбрана.
(п = оценка числа статей в группе;
f = номер первой статьи в группе,
1 « номер последней статьи в группе; s = имя группы.)
411 no such news group - такой группы новостей нет.
Команда HELP
Команда дает краткое описание команд, которые может воспри-
нять сервер. Отклик на команду имеет текстовую форму и заверша-
ется строкой с одиночной точкой в начале.
Отклик: 100 help далее следует текст
Сети передачи данных. Метод доступа
1009
Команда IHAVE <messageid>
Команда IHAVE информирует сервер о том, что клиент владеет
статьей с идентификационным кодом <messageid>. Если сервер хочет
скопировать статью, он пришлет отклик, предлагающий клиенту
прислать ее. Если же сервер по какой-либо причине не хочет, чтобы
ему прислали копию этой статьи (например, он ее уже имеет), он
оповещает клиента об этом в своем отклике.
Если запрошена передача статьи, клиент должен выслать пол-
ный текст статьи, включая заголовок. Сервер в этом случае при-
шлет отклик, уведомляющий об успехе или неудаче этой операции.
Эта процедура отличается от команды POST в том, что после-
дняя предназначена для пересылки цолученных извне статей. Сер-
вер может и не пересылать полученную статью другим серверам, в
этом случае будут переданы коды ошибок 436 или 437.
Причиной отказа в рассылке может стать неверный код группы,
ошибка в заголовке, неприемлемая длина статьи или ограничения
дискового пространства. Обычно эти ограничения связаны с конфи-
гурацией программного обеспечения на сервере.
Отклики:
235 article transferred ok - статья передана.
335 send article to be transferred - пришлите статью.
Завершение последовательностью <CR-LF>.<CR-LF>
435 article not wanted - статью посылать не следует
436 transfer failed - попытайтесь еще раз позднее
437 article rejected - и не пытайтесь
Так как некоторые серверы новостей не могут немедленно при-
нять решение относительно рассылки конкретной статьи, прием
статьи подтверждается (код 235), а позднее она может быть молча
выброшена. Такое решение не идеально, возможно оно будет пере-
смотрено позднее.
Команда LAST
Внутренний указатель на статью устанавливается на предше-
ствующую запись в текущей группе. Если указатель уже установ-
лен на первую статью, отправляется сообщение об ошибке, а указа-
тель остается неизменным.
Отклик содержит текущий номер статьи и ее идентификатор.
Отклики:
223 n a article retrieved - выборочно запрашивает текст
(п = номер статьи, а = уникальный
идентификатор статьи)
412 no newsgroup selected - не выбрана группа
33 Зак. Na 3430 Семенов
1010
Гпава 4
420 no current article has been selected - не выбрана статья
422 по previous article in this group - в группе нет
прыдущей статьи
Команда LIST
Присылает список доступных групп новостей. Каждой группе
новостей соответствует строка следующего формата:
group last first р
где <group> название группы новостей, <last> номер последней из-
вестной статьи в данной группе, <first> номер первой статьи в груп-
пе, и <р> может быть либо “у” либо “п”, указывая на наличие или
отсутствие разрешения на рассылку соответственно.
Поля <first> и <last> являются числовыми. Они могут начи-
наться с нулей. Если код поля <last> превосходит код поля <first>,
в файле данной группы новостей нет ни одной статьи.
Обратите внимание на то, что рассылка может быть запрещена
клиенту, хотя команда LIST указывает на то, что она разрешена для
данной группы новостей. Флаг рассылки существует для каждой
группы новостей, так как некоторые группы подвергаются редакти-
рованию или обобщению и по этой причине не могут рассылаться.
Присылаемая статья сначала по почте пересылается посреднику-
редактору, который может осуществить ее рассылку. Это не зависит
от права рассылки, предоставленного клиенту NNTP-сервером.
Заметьте, что пустой список может быть вполне корректным
откликом и означает, что в данный момент на сервере нет новостей.
Отклик: 215 далее следует список групп новостей
Команда NEWGROUPS date time [GMT] [<distributions>]
Список групп новостей создан с <date и time> и будет представ-
лен в том же формате, что и в случае команды LIST.
Дата посылается в виде 6 цифр в формате ГГММДД, где ГГ
последние две цифры года, ММ - номер месяца (с нулем в начале,
если требуется) и ДД номер дня в месяце. Дополнение для года
берется из предположения о ближайшем тысячелетии, так 86 пред-
полагает 1986, 30 — 2030, 99 — 1999, а 00 - 2000 годы.
Время должно характеризоваться также 6 цифрами в формате
ЧЧММСС, где ЧЧ - часы с начала суток в 24-часовом исчислении,
ММ минуты 00-59, а СС секунды 00-59. Временная зона определя-
ется сервером, в противном случае появляется символьная комби-
нация "GMT", в этом случае и время и дата привязаны к нулевому
меридиану.
Сети передачи данных. Метод доступа
1O11
Опционный параметр ”distributions" представляет собой список
групп рассылки, заключенный в угловые скобки. Если параметр
задан, рассылаемая часть новых групп новостей будет сравниваться
с данным списком, и только при совпадении включается в список.
Если необходимо использовать более одного такого фильтра, то они
разделяются друг от друга запятыми в пределах угловых скобок.
Отклик: 231 далее следует список новых групп
Команда NEWNEWS newsgroups date time [GMT] [<distribution>]
Команда формирует список идентификаторов статей для задан-
ной группы новостей, с датой после указанной. Для каждого иден-
тификатора сообщения в списке выделяется одна строка. Список
завершается строкой с одиночным символом точки, за которым
следует CR-LF. Дата и время задаются в том же формате, что и для
команды NEWGROUPS.
Для расширения зоны поиска в имени группы новостей можно
использовать символ Программа может подставить вместо звез-
дочки любую комбинацию символов. Если вместо имени группы
подставлен символ звездочка, поиск будет проведен по всем груп-
пам новостей.
Если звездочка в имени группы отсутствует, новые статьи будут
искаться только в группе, имя которой приведено в качестве пара-
метра запроса. Имя группы должно быть взято из списка доступ-
ных групп. Допускается спецификация нескольких групп (имена
разделяются запятыми). После последнего имени группы не долж-
но быть запятой.
Для отрицания соответствия может использоваться восклица-
тельный знак. Это можно использовать для селективного исключе-
ния определенных групп новостей с целью сокращения размера спис-
ка. Например, спецификация групп "net.*,mod.*,!mod.map.*" опре-
деляет, что следует просмотреть все статьи в группах пек<что-то>
и mod.<4TO-TO> за исключением mod.map.<4TO-To>. Восклицатель-
ный знак должен использоваться непосредственно перед первым
символом выбранного имени группы новостей.
Опционный параметр "distributions" представляет собой список
групп рассылки, заключенный в треугольные скобки. Если этот па-
раметр задан, производится отбор статей, соответствующих катего-
риям, приведенным в списке distribution.
Заметьте, что пустой список является вполне допустимым от-
кликом и означает отсутствие новых статей.
Отклик: 230 далее следует список идентификаторов новых статей
Зз*
1012
Гпава 4
Команда NEXT
Команда перемещает указатель текущей статьи на следующую
запись в текущей группе новостей. Если в группе нет больше ста-
тей, посылается сообщение об ошибке, а указатель текущей статьи
остается не измененным.
В качестве отклика на команду возвращается номер текущей
статьи и идентификатор сообщения. Никаких текстовых сообще-
ний не посылается.
Отклики:
223 n a article retrieved, где п = номер статьи, а = уникальный
идентификатор статьи
412 no newsgroup selected - группа новостей не выбрана
420 no current article has been selected - не выбрана статья
421 по next article in this group - в этой группе нет больше статей.
Команда POST
Команда служит для посылки новостей клиентом. Если рассыл-
ка разрешена, в качестве отклика присылается код 340, который
указывает, что статью, предназначенную для рассылки, можно при-
сылать. Код отклика 440 указывает, что рассылка запрещена по
причинам, зависящим от инсталляции.
Если рассылка разрешена, статья должна быть представлена в
формате, описанном в RFC850, и должна включать в себя все необ-
ходимые строки заголовка. После передачи заголовка и текста ста-
тьи от клиента к серверу последующий отклик будет свидетель-
ствовать об успехе или неудаче доставки.
Сервер не осуществляет какой-либо фильтрации текста, и он в
неизмененном виде будет рассылаться.
Отклики:
240 article posted ok
340 send article to be posted.
Конец отмечается последовательностью <CR-LF>.<CR-LF>
440 posting not allowed
441 posting failed
Команда QUIT
Сервер подтверждает получение команды QUIT и затем закрыва-
ет канал связи с клиентом. Эта команда предоставляет клиенту
корректную возможность сообщить NNTP-серверу, что все операции
завершены и сессия закончена.
Если клиент просто разорвет связь, сервер должен также прекра-
тить попытки взаимодействовать с клиентом.
Отклик: 205 closing connection — goodbye!
Сети передачи данных. Метод доступа
1013
Команда SLAVE
Команда сообщает серверу, что он связывается не с пользовате-
лем, а с обслуживающим сервером (slave). Эта команда позволяет
разделить случаи соединения сервера с отдельным пользователем и
промежуточными обслуживающими серверами. Это может исполь-
зоваться для предоставления приоритета запросам от таких клиен-
тов, так как они обслуживают многих пользователей. Это может
быть также использовано при возникновении проблем с внутренни-
ми ресурсами сервера, когда он может разорвать связи с некоторыми
клиентами, сохраняя каналы с обслуживающими серверами. В NNTP-
серверах, где приоритетное обслуживание не предусмотрено, команда
должна все равно распознаваться и подтверждаться ее получение
Отклик: 202 slave status noted
Ниже приведены примеры (Примеры заимствованы из RFC-0977,
Network News Transfer Protocol, В. Kantor, P.Lapsley.) диалога меж-
ду клиентом и сервером. Букве С: соответствует клиент, а букве S:
— сервер.
Пример 1 - относительный доступ с помощью команды NEXT
S: прослушивает порт 119 TCP
С: запрашивает соединения к порту 119 TCP
S: 200 wombatvax news server ready — posting ok
(Клиент запрашивает список текущих новостей)
С: LIST
S: 215 далее следует список групп новостей
S: net.wombats 00543 00501 у
S: net. unix-wizards 10125 10011 у
(какая-то еще информация)
S: net.idiots 00100 00001 n
S:
(Клиент выбирает группу новостей.)
С: GROUP net.unix-wizards
S: 211 104 10011 10125 net.unix-wizards group selected
(В файле 104 статьи с 10011 по 10125)
(Клиент выбирает статью для чтения.)
С: STAT 10110
S: 223 10110 <23445@sdcsvax.ARPA> article retrieved —
statistics
article 10110 selected, its message-id is
<23445@sdcs vax. ARP A>)
(Клиент просматривает заголовок)
C: HEAD
1014
Гпава 4
S: 221 10110 <23445@sdcsvax.ARPA> article retrieved -
далее следует заголцвок
S:
(Клиент хочет просмотреть текст статьи.)
С: BODY
S: 222 10110 <23445@sdcsvax.ARPA> article retrieved -
далее следует текст статьи
S:
(Клиент хочет просмотреть следующую статью данной группы)
С: NEXT
S: 223 10113 <21495@nudebch.uucp> article retrieved —
statistics only (статья 10113 является следующей в группе)
(Клиент завершает сессию)
С: QUIT
S: 205 goodbye.
Пример 2 - абсолютный доступ к статье с помощью команды
ARTICLE
S: прослушивает порт 119 TCP
С: запрашивает соединения к порту 119 TCP
S: 201 UCB-VAX netnews server ready - no posting allowed
(рассылка запрещена)
C: GROUP msgs
S: 211 103 402 504 msgs Your new group is msgs
(Здесь 103 статьи с 402 по 504)
С: ARTICLE 401
S: 423 No such article in this newsgroup
C: ARTICLE 402
S: 220 402 <4105@ucbvax.ARPA> Article retrieved
S: Следует заголовок текст и статьи
S:
С: HEAD 403
S: 221 403 <3108@mcvax.UUCP> Article retrieved, header
follows
S: Следует заголовок статьи
S:
C: QUIT
S: 205 UCB-VAX news server closing connection. Goodbye.
Пример 3 - Команда NEWGROUPS
S: прослушивает порт 119 TCP
С: запрашивает соединения к порту 119 TCP
S: 200 Imaginary Institute News Server ready (posting ok)
(Клиент запрашивает группы новостей после 3-го апреля 1985)
Сети передачи данных. Метод доступа
1015
С: NEWGROUPS 850403 020000
S: 231 Далее следуют группы новостей после 03/04/85
02:00:00 follow
S: net. music, gdead
S: net. games, sources
S:
C: GROUP net.music.gdead
S: 211 0 1 1 net.music.gdead Newsgroup selected
. (Нет статей в этой группе новостей, номера первой и последней
статей следует игнорировать)
С: QUIT
S: 205 Imaginary Institute news server ceasing service. Bye!
Пример 4 - рассылка новых статей
S: прослушивает порт 119 TCP
С: запрашивает соединения к порту 119 TCP
S: 200 BANZAIVAX news server ready, рассылка разрешена.
С: POST
S: 340 Continue posting; Period on a line by itself to end
С: Передает статью в формате RFC850
С:
S: 240 Article posted successfully.
C: QUIT
S: 205 BANZAIVAX closing connection. Goodbye.
Сессия завершается, канал закрывается.
4.5.7. Подписные листы LISTSERV
LISTSERV — система обслуживания и управления списками ад-
ресов электронной почты. Она работает в рамках SUN/UNIX, LINUX
и др., в интернациональной сети NJE (EARN/Bitnet) и Интернет.
Она позволяет группам пользователей, объединенных общим инте-
ресом общаться между собой, обеспечивая эффективное использова-
ние ресурсов сети. Система дает возможность пользователю найти
интересующую его группу, присоединиться к ней и активно участво-
вать в ее функционировании. LISTSERV управляет почтовым тра-
фиком, осуществляет поиск архивов и файлов. Спектр тем ничем
не ограничен, число рубрик превышает 3000. Хотя техника WEB-
серверов достигла впечатляющих успехов, технология подписных
листов имеет и сегодня неплохие перспективы. Помимо клубов по
интересам, это прежде всего электронные газеты и журналы.
Доступ к LISTSERV может получить всякий пользователь, кто
Может посылать электронные сообщения по адресам EARN/Bitnet
1016
Гпава 4
(в соответствии со стандартом RFC-822) и имеет пригодный к ис-
пользованию адрес. Отличие от обычной электронной почты заклю-
чается в том, здесь вы можете обратиться не только к тем партне-
рам, адреса которых вы знаете, но и к тем о существовании которых
и не подозреваете. Однажды по работе мне потребовалась информа-
ция по ультрафиолетовой дозиметрии, я послал запрос в один из
серверов и в течение суток получил 6 ответов из США, Канады и
Новой Зеландии (среди них Stephan Straus stephen@unicaat.yorku.ca,
Martin Brown brauwnma@ucs.oust.edu). Неизвестные мне доселе люди
снабдили меня необходимыми данными, указали адреса, где можно
найти дополнительную информацию, прислали списки библиогра-
фии. Обратите внимание, чтобы однозначно определить, кого я имею
в виду, достаточно указать электронный адрес.
Для того, чтобы наладить контакт с LISTSERV нужно послать
запрос по адресу: LISTSERV@host-id, где host-id NJE-адрес ЭВМ
или имя INTERNET-домена (например, VM.TAU.AC.IL). Серверу
LISTSERV можно послать несколько команд в одном сообщении.
Каждая команда должна начинаться с новой строки. Поле subject
при этом игнорируется. Возможно взаимодействие с LISTSERV и в
интерактивном режиме.
Пользователи могут посылать свои запросы по адресу
LISTSERV.NET. Заметьте, что если этот узел еще не определен
для вашей сети, вы можете попробовать работать на
LISTSERV% LISTSERV.BITNET@CUNYVM.CUNY.EDU. Вы можете
также использовать специальный LISTSERV-адрес, чтобы послать е-
mail в любой LISTSERV-список. На конец 1994 года существовало
более 250 узлов в более чем 30 странах мира, где работают серверы
LISTSERV. Вот некоторые из них:
Сервер Место расположения Страна
DEARN GMD, Бонн Германия
EARNCC Офис EARN, Париж Франция
HEARN Католический университет Nijmegen Нидерланды
PUCC Принстонский университет, Нью-Джерси США
SEARN Kungliga Tekniska Hoegskolan, Стокгольм Швеция
Ниже описаны наиболее часто используемые команды.
Команды имеют следующий формат: заглавные буквы указыва-
ют на возможное сокращение, угловые скобки выделяют опционный
параметр, а вертикальная черта отмечает значение этого параметра.
Существует стандартный набор параметров ключевых слов, которые
Сети передачи данных. Метод доступа
1017
могут использоваться совместно с командами в качестве парамет-
ров. Важными ключевыми словами являются:
РУУ=пароль — это ключевое слово служит для описания слова-
пароля. Если вы завели слово-пароль для данного LISTSERV-серве-
ра, вы должны в дальнейшем записывать в командном тексте стро-
ку PW=, чтобы ваши команды были выполнены. Эта функция со-
здана, чтобы блокировать возможность исполнения команд, используя
ваш электронный адрес. Если вы зарегистрировали ваш пароль в
сервере LISTSERV, вы обязаны включать PW= во все команды, где
это требуется по описанию.
Е=формат — это ключевое слово управляет форматом файла
(или внутренней структурой файла), в котором он будет вам по-
слан. Обычно LISTSERV использует формат MAIL. Любой пользо-
ватель может затребовать формат, отличный от описанного по умол-
чанию, посредством Е=командное_ключевое_слово в командах, где
это требуется опционно. Допустимы следующие форматы файлов:
ХХЕ UUe MIME/text MIME/Appl MAIL
Первичной задачей LISTSERV является обслуживание списков
электронных адресов (списки для рассылки). Эти списки использу-
ются, чтобы пересылать сообщения подписчикам. Таким образом,
создаются форумы для обмена идеями и информацией по темам,
интересующим подписчиков. Пользователю достаточно помнить
только один адрес (адрес сервера), чтобы взаимодействовать с боль-
шим числом лиц, имеющим сходные интересы. Обсуждения или
дебаты при этом могут иметь всемирный характер.
В рамках LISTSERV списка могут использоваться следующие ко-
манды, которые служат для поиска нужного списка и адреса соответ-
ствующего сервера, для подписки или ее отмены и т.д.
SUBscribe имя__списка <полное__имя>
Эта команда служит для включения подписчика в список для
рассылки. Вы можете использовать эту команду для изменения имени
(но не электронного адреса), под которым вы уже известны в спис-
ке. имя_списка — это наименование списка, на который вы хотите
подписаться. Например, EARN User Group список, находящийся в
узле IRLEARN, имеет имя EARN-UG. Не следует путать имя списка
с адресом сервера (EARN-UG@IRLEARN). Опционный параметр
полное_имя позволяет вам выдать имя, под которым вы хотите
фигурировать в списке (это может быть псевдоним). При посылке
этой команды в LISTSERV по e-mail полное имя будет взято из
поля Ft'Otn:. При посылке этой команды в сервер, где вы уже подпи-
iois
Гпава 4
саны, это будет воспринято, как требование об изменении полного
имени. Запрос о присоединении к подписному листу может быть
обработан тремя путями: подписка может быть OPEN, CLOSED или
BY-OWNER. Если это OPEN, вы будете автоматически добавлены в
список и получите подтверждение этого. Если это CLOSED, вы буде-
те вычеркнуты из списка рассылки. Если вас там не было, вы полу-
чите уведомление о том, что запрос не выполнен. Если же это BY-
OWNER, ваш запрос будет переадресован собственнику списка, кто и
решит добавлять вас к списку или нет. Адрес, куда будет переправ-
лен ваш запрос, вам будет прислан. Для того, чтобы быть исклю-
ченным из списка посылайте команду:
UNSubscribe имя_списка | * <(NETWIDE>
Наличие круглой скобки только слева не является опечаткой.
Для того, чтобы ликвидировать подписку по всем спискам LISTSERV,
можете использовать «*» вместо имени списка. Если вы хотите,
чтобы ваш запрос был передан всем серверам сети, используйте
команду (NETWIDE. Эта версия команды рекомендуется при смене
вашего электронного адреса или при длительном отпуске. Для по-
лучения списка имеющихся списков в сервере LISTSERV исполь-
зуйте команду List.
List <option> <Е=формат>
Параметр option может принимать следующие значения:
Short
Отображается резюме всех списков, контролируемых LISTSERV,
по одной строке на список. Эта версия реализуется по умолчанию;
Long
(детально) пересылает вам файл (называемый node-name LISTS),
содержащий исчерпывающие описания всех списков, поддерживае-
мых сервером.
Global <эталон>
Выдается полный список всех известных почтовых списков
LISTSERV на текущий момент. Этот файл имеет имя LISTSERV
LISTS и содержит имена, заголовки и e-mail адреса этих списков.
Это очень большой файл, поэтому следует проверить, есть ли у вас
достаточно места на диске, прежде чем использовать опцию Global.
Опционный параметр эталон может использоваться для того, чтобы
выбрать имя списка, заголовок или список адресов.
Сети передачи данных. Метод доступа
1019
Для получения листинга почтовых списков используется ко-
манда REView. Формат команды:
REView имя_списка <(> <option>
Листинг будет вам переслан в виде файла с именем list-name
LIST (или list-name node-name). Почтовый список состоит из двух
частей: управляющая секция и подписная секция. Управляющая
секция содержит параметры списка, которые включают в себя ин-
формацию о том, кто решает вопросы включения в список или его
пересмотра, а также архивации. Подписная секция содержит e-mail
адреса и имена всех членов списка. REView-команда позволяет вам
получить листинг любой или обеих этих секций (по умолчанию —
обеих) для любого из списков. Следует иметь в виду, что по реше-
нию владельца списка командой REView может выдаваться только
список членов этого списка. В этом случае вам не будет позволено
просматривать список e-mail адресов, если вы не член списка. Чле-
ны списка могут ограничить доступ к своему e-mail адресу по ко-
манде REView, если они установили опцию CANCEL. имя_списка —
имя LISTSERV-списка, который вы хотите просмотреть. К важным
опциям команды REView относятся:
Short
Получаемая информация ограничивается управляющей секцией
(только параметры списка).
Countries
Выдается перечень членов списка упорядоченный с учетом на-
циональной принадлежности.
LOCal
Если список имеет пару (соединен с другим списком того же
имени, обслуживаемым другим сервером), вы получите полный лис-
тинг в отклик на команду REView.
Опция LOCal может использоваться для подавления распростра-
нения действия команды REView на другие серверы. В этом случае
вы получите листинг только от сервера, куда вы послали запрос.
При подключении к какому-либо списку, вам будет поставлен в
соответствие перечень параметров по умолчанию. Эти параметры
могут быть вами изменены для любого из списков, где вы являетесь
подписчиком. Команда Query позволяет просмотреть текущие зна-
чения параметров (опций) для любого списка. Формат команды:
1020
Гпава 4
Query имя_списка | *
Параметр имя_списка представляет собой наименование списка,
на который вы подписались. Если вы используете символ «*» вме-
сто имени списка, вы получите информацию о ваших личных пара- -
метрах для всех списков, на которые вы подписаны.
Для изменения параметров вашей подписки используется ко-
манда SET. Она имеет формат:
SET имя списка | * options
После выполнения команды SET сервер пришлет вам подтверж-
дение успешного изменения параметра по электронной почте. Важ-
ными опциями команды SET являются:
Mail | DIGests | INDex | NOMail
Эти опции варьируют способ, которым вы получаете сообщения.
Mail означает, что вы хотите получать сообщения по электронной
почте (значение по умолчанию).
DIGests и INDex доступны только в случае, если они разрешены
собственником списка. DIGests сохраняет все сообщения послан-
ные в список в течении определенного времени. Вместо того, чтобы
получать сообщения одно за другим вы получите их единым клас-
тером в определенный день недели или месяца. Обратите внимание,
DIGests не редактирует почту и вы получите все сообщения. INDex
передаст вам только дату, время, предмет, число строк, имя отправи-
теля и адреса всех сообщений, посланных в список. Текст сообще-
ний передан не будет. Вы можете выбрать и извлечь заинтересовав-
шие вас сообщения. NoMail означает, что вам не будут пересылать-
ся сообщения. Это полезно при длительной командировке или
отпуске./Вернувшись, вы можете послать команду SET с опцией
Mail и возобновить присылку сообщений. Предусмотрена возмож-
ность изменения формата заголовков почтовых сообщений.
SHORThdr | FULLhdr | lETFhdr | DUALhdr
Все почтовые сообщения состоят из секции заголовка и тела
сообщения. Заголовок содержит информацию об отправителе, полу-
чателе, дате и времени отправки. Перечисленные выше опции ко-
манды SET указывают на тип заголовка почтового сообщения, кото-
рый вы хотите иметь. SHORThdr означает, что заголовок сообще-
ния будет содержать только самую существенную информацию
(например, Date:, То:, From:, Subject:, и Replay-to: поля). Этот вари-
ант работает по умолчанию. Вы можете изменить это, используя
Сети передачи данных. Метод доступа
<1021
опцию FULLhdr, которая означает, что все (даже не существенные)
поля заголовка будут присутствовать в почтовом сообщении. Оп-
ция lETFhdr означает, что LISTSERV не изменит заголовок, за ис-
ключением того, что добавит в заголовок Received: (а также Message-
id: и Sender:, если их там не было). Эта опция введена для обеспе-
чения совместимости с SMTP. Наконец DUALhdr очень похожа на
SHORThdr за исключением того, что LISTSERV введет заголовок в
начало тела сообщения. Следовательно, когда сообщение получено
и читается получателем с этой опцией, оно начнется с этой инфор-
мации (например, первые три строки сообщения могут содержать
То:. From:, и Subject). Эта опция удобна для таких почтовых паке-
тов на PC, где эта информация не отображается.
CONCEAL | NOCONCEAL
указывает на то, хотите вы или нет, чтобы ваше имя и почтовый
адрес появлялся в ответ на команду REView, выданную одним из
подписчиков списка. По умолчанию работает NONCONCEAL. Обра-
тите внимание, что полный список подписчиков доступен владельцу
списка и администратору LISTSERV, вне зависимости от установки
этой опции.
Для возобновления вашей подписки необходимо выдать коман-
ду COMFIRM. Формат команды:
CONFIRM имя_списка
Некоторые подписные листы требуют регулярного подтвержде-
ния подписки (обычно раз в год). Система автоматически напоми-
нает пользователям, что они должны подтвердить свою подписку,
т.е. они должны послать команду CONFIRM в течение заданного
числа дней. В противном случае клиент будет вычеркнут из спис-
ка. Эта команда должна быть послана с того же адреса, по которому
было послано напоминание. LISTSERV присылает подтверждение
получения команды CONFIRM.
LISTSERV может работать также и как файл-сервер. Поэтому
сервер может запоминать файлы и обеспечивать к ним доступ по
запросам. Эти файлы запоминаются в рамках иерархической систе-
мы filelists. Как и предполагает его название filelist представляет
собой специальный файл, который содержит список файлов. Каж-
дая запись в filelist описывает файл, который можно затребовать,
Давая информацию о его имени, размере, а также коде доступа (File
Access Code), который описывает, кто имеет доступ к нему. Эти
Файлы сами могут быть списками файлов. Таким образом, эта фай-
ловая система имеет древовидную структуру.
1022
Гпава 4
На LISTSERV существует два вида файлов-списков. Первый тип
содержит файлы, которые помещены туда специально хозяином спис-
ка или его администратором. Это могут быть документы, карты,
диаграммы или даже программы. Файлы-списки второго вида ассо-
циированы со списком адресов LISTSERV. Это списки файлов-спис-
ков, они состоят из серии файлов, каждый из которых хранит (обычно
до месяца) копию сообщения, которое было ранее разослано. При
желании в течение определенного времени эти файлы могут быть
скопированы любым подписчиком.
LISTSERV может компоновать один или более файлов в пакет и
в таком виде рассылать подписчикам. Это могут быть, например,
файлы, необходимые для генерации определенной программы. Па-
кет декларируется в LISTSERV-filelist через файл, который именует-
ся packet-name $PACKEGE. В нем хранятся описания всех файлов,
которые представляют собой пакеты. Любой файл, представляющий
собой пакет, может быть извлечен из хранилища с помощью запро-
са: packet-name PACKAGE. Обратите внимание, что в этом случае
символ $ в имени опущен. Таким образом, одна команда позволяет
извлечь из депозитария сразу несколько файлов, входящих в пакет.
Некоторые команды позволяют пользователю Манипулировать
файлами, которые хранятся в депозитарии LISTSERV. Сюда входят
команды подписки и извлечения файлов. При посылке команд файл-
серверу вы должны адресовать их именно серверу, а не какому-либо
почтовому списку.
Используйте команду INDex для получения списка файлов из
определенного filelist. Формат команды:
INDex <список_файлов> <Е=формат>
Параметр список_файлов рпределяет имя списка, который вас
интересует. Если не указано никакого имени, вам будет прислан
индекс корневого списка файлов (именуемого LISTSERV FILELIST).
Команда GET используется для извлечения какого-то опреде- -
ленного файла или пакета файлов из списка файлов, если вам раз-
решено это делать. Формат команды:
GET имя_файла тип_файла <список_файлов> <Е=формат>
Параметры имя_файла и тип_файла описывают файл или пакет
файлов, который вы хотите получить. Параметр список_файлов оп-
ределяет список файлов или пакетов, где лежит искомый файл. Еслй
этот параметр не указан, LISTSERV будет определять его путем по-
иска в собственном индексе, что задержит выполнение запроса.
Сети передачи данных. Метод доступа
1023
Для подписки на файлы или пакеты из определенного списка
следует использовать команду AFD (Automatic File Distribution).
Формат команды:
AFD options
Каждый раз, когда данный список или конкретный файл актуа-
лизуется (изменяется), вам будет выслана сервером его копия. Чис-
ло файлов или пакетов, на которые вы подписаны, не лимитирова-
но. Вы можете в любой момент просмотреть перечень подписки и
ликвидировать ее частично или полностью. Параметр options ко-
манды AFD может принимать одно из следующих значений:
ADD имя_файла тип_файла <список_файлов> <текст>
<Р=формат> <PW=password>
Опция ADD позволяет вам подписаться на файл или пакет,
имя_файла и тип_файла характеризует при этом имя и тип файла,
на который вы подписались. Если вы хотите, чтобы автоматически
в начало каждого присылаемого файла или пакета добавлялся не-
который текст, используйте параметр текст. Если вы пропускаете
параметр список_файлов, то параметр текст должен быть помещен
в кавычки.
t
DELete filename filetype <filelist> <PW=password>
Эта опция служит для аннулирования подписки, имена могут
содержать символы * (wildcard). Опция List показывает файлы или
пакеты, на которые вы в данный момент подписаны. Формат опции:
List <(FORMAT>
Если вы включите опцию (FORMAT, то будет отображен и фор-
мат, в котором вам будет присылаться файлы или пакеты. Еще
одна команда, которая позволяет осуществить подписку на файлы и
пакеты, носит название FUI (File Update Information). Ее формат:
FUI options
Эта команда аналогична AFD за исключением того, что вы в
Данном случае получаете сообщение об изменении файла или паке-
та, а не его новую копию. Эта команда допускает следующие опции:
ADD имя_файла тип_файла <список__файлов> <РА¥=пароль>
Аналог ADD для команды AFD за исключением параметров фор- •
Мат и текст. Опция DELete является полным аналогом одноимен-
ной опции команды AFD:
1024
Гпава 4
Для получения информации об актуализации файлов или паке-
тов удобна команда Query File. Параметр список__файлов может быть
опущен. Формат команды:
Query File имя_файла тип_файла <список_файлов> <(FLags>
Вы можете задать параметр (Flags, который позволит админист-
рации LISTSERV получить дополнительную техническую информа-
цию о файле, полезную при описании проблем, с которыми вы стол-
кнулись.
Команда PW позволяет вам добавить, изменить или ликвидиро-
вать ваше персональный пароль. Команда имеет следующий формат:
PW options *
Пароль блокирует возможность несанкционированного исполь-
зования вашего электронного адреса. Настоятельно рекомендуется
воспользоваться этой возможностью. Запрос на регистрацию паро-
ля может быть воспринят в любое время, аналогично оно может
быть изменено и аннулировано также, когда вы захотите. Пароль
может включать в себя от одного до 8 алфавитно-цифровых симво-
лов. Среди опций этой команды могут быть:
ADD new-password
Добавляет новый пароль. Если вы зарегистрировали свое па- I
роль, вы обязаны впредь его использовать всюду (вводить команд-
ное ключевое слово PW=), где это требуется опционно.
CHange old-password new-password
Изменяет ваш пароль на новый.
DELete old-password
Удаляет ваш пароль из сервера, если вы уже имели его. После этого
вы уже не обязаны вводить впредь командное ключевое слово PW=.
Функции LISTSERV DATABASE
LISTSERV позволяет пользователям извлекать старые почто-
вые сообщения, которые рассылались по списку какое-то время на-
зад. Каждый почтовый список имеет ассоциированную базу данных
(обычно называемую notebook или база данных list archive), в кото- ।
рую производится запись рассылаемых сообщений. Такая возмож-
-ность зависит от хозяина списка и присутствует не всегда. Базовые
Серверы имеют также базы данных по всем узловым ЭВМ LISTSERV
(база имеет название PEERS). Для того, чтобы определить, какие
Сети передачи данных. Метод доступа
1025
базы данных доступны на данном сервере выдайте команду
DATABASE LIST. Для выполнения поиска в базе данных вы може-
те послать e-mail в LISTSERV с соответствующим запросом в базу
данных. Для получения более детальной информации пошлите ко-
манду Info DATABASE на ближайший сервер.
LISTSERV может выдать пользователю много и другой инфор-
мации: статистика запросов, справочные и конфигурационные фай-
лы и пр. При запросе этой информации следует адресоваться к
серверам, а не к какому-либо списку. К числу команд, помогающих
извлечь вспомогательную информацию, относится HELP. В ответ на
эту команду вы получите по электронной почте описание наиболее
употребимых команд LISTSERV, а также имя сервер-почтмейстера и
его электронный адрес.
Для получения help-файла из LISTSERV можно выдать команду
Info, которая имеет формат:
INFO <тема> <Г=формат>
Опция тема должна характеризовать тематику файла, который
вы получите в ответ. Если вы пошлете запрос в ближайший (или
любой) LISTSERV без указания темы, то получите список возмож-
ных тем запросов.
При работе с подписными листами следует прежде всего думать
о партнерах по списку. Это занятые люди, поэтому для всеобщего
внимания следует выносить лаконичные сообщения, представляю-
щие всеобщий интерес. Частные сообщения лучше посылать толь-
ко тому, или тем, адресатам, которым это важно знать.
4.5.8. Электронная почта (E-MAIL)
Электронная почта — наиболее популярный и быстро развиваю-
щийся вид общения. Раньне использовался протокол электронной
почты UUCP (Unix-to-Unix Copy Protocol, RFC-976), сейчас SMTP
(Simple Mail Transfer Protocol; RFC-821, -822, -1351, -1352). Один из
протоколов (RFC-822) определяет формат почтовых сообщений, второй
(RFC-821) управляет их пересылкой. Имея механизмы промежу-
точного хранения почты (spooling) и механизмы повышения надеж-
ности доставки, протокол SMTP базируется на TCP-протоколе и
допускает использование различных транспортных сред. Он может
доставлять сообщения даже в сети, не поддерживающие протоколы
TCP/IP. Протокол SMTP обеспечивает как транспортировку сооб-
щений одному получателю^ так и размножение нескольких копий
сообщения для передачи по разным адресам. Обычно в любом узле
1026
Гпава 4
Интернет имеется почтовый сервер (MX), который принимает все
сообщения и устанавливает их в очередь. Далее производится рас-
кладка сообщений по почтовым ящикам ЭВМ пользователей. Если
какая-то ЭВМ не включена, сервер попытается доставить почту по-
зднее (например, через 30 мин). После заданного числа неудачных
попыток или по истечении определенного времени (> 4-5 дней) со-
общение может быть утрачено. При этом отправитель должен по-
лучить уведомление об этом. Над SMTP располагается почтовая
служба конкретных вычислительных систем (например, sendmail
(UNIX), POP3 (RFC-1460), IMAP (RFC-2060), pine, ELM (надстрой-
ка над sendmail), Mush, MH и т.д.). Схема пересылки электронных
почтовых сообщений (RFC-821) показана на рис. 4.5.8.1.
Существует множество реализаций электронной почты. Имеют-
ся версии практически для всех ЭВМ, операционных систем и сред.
Адреса электронной почты уникальны и однозначно определяют
адресата, обладая иногда даже некоторой избыточностью. Символь-
ные адреса электронной почты вполне соответствуют IP-нотации.
Электронный почтовый адрес содержит две части, местную и домен-
ную, например, vanja.ivanov@itep.ru (vanya.ivanov — местная). До-
менная часть обычно совпадает с символьным IP-именем домена.
Если между отправителем и приемником имеется непосредствен-
ная связь, адрес имеет вид имя__пользователя@имя__ЭВМ. Когда при-
емник находится на ЭВМ, которая не поддерживает SMTP и переда-
ча происходит через промежуточный почтовый сервер, то адрес мо-
жет иметь вид, например, ivanov% имя_удаленной__ЭВМ@имя__сервера
(благодаря быстрому развитию Интернет в мире и даже в России
такая схема используется сейчас крайне редко). Местная часть ад-
реса определяется пользователем и часто совпадет с его именем
или фамилией. Электронный адрес несравненно компактнее тради-
ционных почтовых адресов, которые мы пишем на конвертах. Да и
сами возможности электронной почты несравненно богаче почты
традиционной. По этой причине можно утверждать, что традицион-
ная почта постепенно будет в ближайшем будущем вытеснена ее
электронным аналогом. Схема взаимодействия различных объек-
тов электронной почты показана на рис. 4.5.8.1
Со временем можно ожидать, что электронные адреса станут
универсальными, но это произойдет не скоро. Для этого нужно что-
бы транспорт и другие службы научились работать с такими адреса-
ми. Электронные (IP) адреса удобнее для ЭВМ, чем традиционные, а
принимая во внимание, что применение вычислительной техники
повсеместно, вывод напрашивается сам собой. То что удобно для
ЭВМ, удобно в конечном итоге для всех.
Сети передачи данных. Метод доступа
1027
Pm. 4.5.8.1. Схема пересылки электронных почтовых сообщений
Любое почтовое сообщение можно разделить на три части: ’’кон-
верт" (RFC-821), заголовки (RFC-822) и собственно текст. Конверт
используется почтовым сервером и содержит две команды (тексты
после двоеточия приведены в качестве примера):
MAIL From: <semenov@cl.itep.ru>
RCPT To: <king_penguin@antarctic.edu>
Существует девять полей заголовка, используемые почтовой про-
граммой пользователя: Received, From, То, Date, Subject, Message-Id, X-
Phone, X-Mailer, Reply-То. Каждое из этих полей содержит имя, за
которым после двоеточия следует его значение. Документ RFC-822
определяет формат и интерпретацию полей заголовка. Заголовки,
начинающиеся с X- являются полями, определяемые пользователем.
При вызове почты (командой mail или mailx) на экране будет
распечатан служебный текст, который зависит от конкретной реа-
лизации mail, но практически непременным атрибутом любой вер-
сии будет являться полное число полученных вами почтовых сооб-
щений (если таковые были). Это могут быть и сообщения, оставлен-
ные вами там после предшествующего чтения почты. Непрочитанные
вами сообщения так или иначе помечаются (например, символом U
на левом поле строки-описания сообщения или N для новых). Да-
лее следует аннотация сообщения, по одной строке на сообщение.
Аннотация обычно содержит номер сообщения (нумерация всегда
начинается с 1), имя и адрес отправителя, дата и время отправки.
После этого следуют (в некоторых реализациях) два числа, разде-
ленных косой чертой (’’/"). Они характеризуют размер сообщения в
строках и полное число символов. В заключение следует, если еще
1028
Гпава 4
есть место, предмет сообщения (Subject:). Ниже приведен пример
текста такого аннотационного сообщения (SUN):
Mail version SMI 4.1-OWV3 Mon Sep 23 07:17:24 PDT 1991
Type ? for help.
"/usr/spool/mail/semenov": 4 messages 4 new
>N 1 mw@isds.Duke.EDU Wed Aug 23 14:15 92/4350
N 2 hochreit@informatik.tu-muenchen.de Wed Aug 23 23:54
71/2767 TR announcement: Long Sho
N 3 Voz@dice.ucl.ac.be Thu Aug 24 07:08 501/21416 ELENA
Classification data
N 4 S.Renals@dcs.shef.ac.uk Thu Aug 24 07:08 58/2837
AbbotDemo: Continuous Spe
&
He ленитесь заполнять поле Subject, иначе при большой почте
ваш адресат может пропустить ваше сообщение. Среди наиболее
значимых для пользователя полей заголовка можно выделить: ад-
рес и имя отправителя (From:), дата отправки (Date:), адрес получа-
теля (То:), адреса и время прохождения промежуточных узлов, спис-
ки лиц (Сс:), кому кроме вас послано это сообщение, предмет сооб-
щения (Subject:), некоторая служебная информация и т.д. Число
строк заголовка зависит от программы, реализующей функцию по-
чты и от параметров, определенных пользователем, например, путем
задания значений системных переменных.
Практически все программные пакеты электронной почты име-
ют возможность переадресовать сообщение другому адресату (Forward),
отправить ответ (Replay) пославшему вам сообщение человеку (в
этом случае в заголовке появится поле Replay-To), стереть сообще-
ние не читая. В случае смены места работы или длительной коман-
дировки можно установить постоянную переадресацию (на ЭВМ SUN
для этого нужно указать адрес нового почтового ящика в файле
.forward), записать сообщение в файл (Save имя файла) или отпеча-
тать его на принтере.
Команда обращение к почтовому серверу обычно имеет вид:
mail местный_адрес@имя_домена,
(все что записано после команды mail, является электронным адре-
сом адресата). Например, если вы посылаете сообщение автору, то
команда приобретает вид: mail semenov@itep.ru.
Использование промежуточного почтового сервера (mail gateway)
несколько усложнит запись электронного адреса (это бывает нужно,
например, когда кто-то вне Internet хочет послать сообщение клиен-
ту Internet):
Сети передачи данных. Метод доступа
1029
semenov% cl. itep. ги@имя_промежуточного_почтового_сервера
При этом предполагается, что промежуточный почтовый сервер
возьмет местную часть адреса, заменит символ "% ’’ на традицион-
ный ”@" и перешлет полученное сообщение по данному адресу.
Встречаются нотации (хотя сегодня их уже смело можно назвать
устаревшими), когда адрес имеет вид:
идентификатор_пользователя% имя_домена
или
идентификатор_пользователя:имя_домена.
Если вы любоцытны и хотите посмотреть, какие служебные ко-
манды выдаются при отправке электронного сообщения, воспользуй-
тесь командой (в качестве адресата (хххххххх) выберите своего дру-
га, коллегу или знакомого, которому вам нужно что-то сообщить):
mail -v xxxxxxxx@cernvm.cern.ch (обращение к почтовой про-
грамме пользователя)
Subject: Test it. (пользовательская программа предлагает
ввести тему почтового сообщения)
Privet...(текст почтового сообщения)
. (команда отправки сообщения)
xxxxxxxx@cernvm.cern.ch... Connecting to dxmint.cern.ch
(TCP)...
220 dxmint.cern.ch Sendmail ready at Thu, 6 Jul 1995 07:43:27 +200
»> HELO itep.ru
250 dxmint.cern.ch Hello itep.ru, pleased to meet you
»> MAIL From:<xxxxxxx@itep.ru>
250 <xxxxxxx@itep.ru>... Sender ok
»> RCPT To:<xxxxxxxx@crnvma.cern.ch>
250 <xxxxxxxx@crnvma.cern.ch>... Recipient ok
»> DATA
354 Enter mail, end with on line by itself
»> .(команда завершения сообщения и его отправки адресату)
250 Ок
»> QUIT
221 dxmint.cern.ch closing connection
xxxxxxxx@crnvma.cern.ch... Sent (сессия завершена)
Именно модификация команды mail -v обеспечивает вывод сооб-
щений, отпечатанных ниже строки ’’Privet...". Для посылки почто-
вого сообщения используется только пять команд: HELO, MAIL, RCPT,
1030
Гпава 4
DATA и QUIT. Строчки, начинающиеся с »>, являются командами,
которые посланы SMTP-клиентом (xxxxxxx@ns.itep.ru). Строки же,
которые начинаются с трехзначной цифры, представляют собой коды-
отклики SMTP-сервера (в данном случае он имеет имя dxmint.cem.ch),
тексты же, следующие после кода-отклика необязательны и могут
отсутствовать. Процедура отправки сообщения начинается с того, что
клиент выполняет операцию active open для ТСР-порта 25. Далее
клиент идентифицирует себя командой HELO, выдавая в качестве
параметра адрес своего домена. Команда MAIL идентифицирует от-
правителя, команда RCPT — получателя. Число команд RCPT всегда
равно числу получателей. Команда DATA служит для передачи сооб-
щения, a QUIT - для завершения этой процедуры и ликвидации ТСР-
канала. Посмотрим как выглядит посланное выше сообщение после
того, как я его переадресовал себе по адресу semenov@itep.ru:
From xxxxxxxx@crnvma.cern.ch Sat Jul 29 12:15:13 1995
Received: from cearn.cern.ch by ns.itep.ru with SMTP id
AA25862
(5.67a8/IDA-1.5 for <SEMENOV@NS.ITEP.RU>); Sat, 29 Jul
1995 12:15:08 +0300
Received: from CERNVM.CERN.CH by CEARN.cern.ch (IBM
VM SMTP V2R2)
with BSMTP id 3114; Sat, 29 Jul 95 10:07:15 SET
Received: from CERNVM.cern.ch (NJE origin@CERNVM) by
CERNVM.CERN.CH (LMail
1.2a/1.8a) with BSMTP id 4132; Sat, 29 Jul 1995 10:11:12
+0200
Resent-Date: Sat, 29 Jul 95 10:10:30 SET
Resent-From: xxxxxxxx@crnvma. cern. ch
Resent-То: SEMENOV@NS.ITEP.RU
Received: from CERNVM (NJE origin SMTPIBM@CERNVM)
by CERNVM.CERN.CH
Lmail VI.2а/1.8a) with BSMTP id 4125; Sat, 29 Jul 1995
10:08:44 +0200
Received: from dxmint.cern.ch by CERNVM.CERN.CH
(IBM VM SMTP V2R2) with TCP;
Sat, 29 Jul 95 10:08:43 SET
Received: by ns.itep.ru id AA25665
(5.67a8/IDA-1.5 for xxxxxxxx@cernvm.cern.ch); Sat, 29
Jul 1995 12:12:26 +0300
Date: Sat, 29 Jul 1995 12:12:26 +0300
From: Yuri Semenov <semenov>
Message-Id: <199507290912AA25665@ns.itep.ru>
Сети передачи данных. Метод доступа
1031
То: xxxxxxxx@crnvma.cern.ch
Subject: Test it.
Status: R
----------------------------Original message---------------
Privet...
Текст, выделенный курсивом, представляет собой то, что пришло в
CERN. "Накладные расходы" даже здесь значительны, ведь собствен-
но текст состоит из одного слова, следующего после надписи "Original
message". Переадресация же увеличивает издержки еще больше.
При описании DNS говорилось о существовании МХ-записей,
которые являются одной из разновидностей ресурсных рекордов.
MX-записи могут использоваться для доставки почтовых сообще-
ний адресатам, не имеющим прямого доступа к Интернет (RFC-
974). Еще одним применением MX-записей является предоставле-
ние альтернативного получателя почтовых сообщений в случае, когда
ЭВМ-получатель вышла из строя. Для выяснение конкретной кон-
фигурации почтовых серверов можно воспользоваться командой host:
host -a -v -t mx cernvm.cem.ch (команда выданная с
терминала, ниже следует отклик на эту команду)
Trying domain "itep.ru"
rcode = 3 (Non-existent domain), ancount=0
Trying null domain
rcode = 0 (Success), ancount=3
The following answer is not authoritative:
cernvm.cem.ch 30450 IN CNAME crnvma.cern.ch
cmvma.cem.ch 86042 IN MX 20 dxmint.cern.ch
crnvma.cern.ch 86042 IN MX 40 relay.EU.net
For authoritative answers, see:
cern.ch 198821 IN NS dxmon.cern.ch
cem.ch 198821 IN NS ns.eu.net
cern.ch 198821 IN NS sunic.sunet.se
cern.ch 198821 IN NS scsnms.switch.ch
Additional information:
dxmint.cern.ch 31455 IN A 128.141.1.113
relay.EU.net 8411 IN A 192.16.202.2
dxmon.cern.ch 371619 IN A 192.65.185.10
ns.eu.net 38326 IN A 192.16.202.11
sunic.sunet.se 331044 IN A 192.36.148.18
sunic.sunet.se 331044 IN A 192.36.125.2
scsnms.switch.ch 28536 IN A 130.59.10.30
scsnms.switch.ch 28536 IN A 130.59.1.30
1032 Глава 4
MX-записи с наименьшим предпочтением (код предпочтения
следует сразу за MX) указывают, что сначала следует попытаться
переслать сообщение ЭВМ dxmint.cern.ch.
Следующий уровень предпочтения соответствует адресу
relay.EU.net. Здесь же вы найдете CNAME-запись (канонические
имена DNS). Кроме списка альтернативных почтовых серверов эта
команда выдает информацию о списке серверов имен (DNS-серве-
ров). В приведенном примере их четыре, они помечены символами
NS и обслуживают домен cern.ch (см. первую колонку). В нижней
части полученной таблицы вы можете найти IP-адреса приведен-
ных MX- и NS-серверов (помечены символом А). Пояснения рас-
шифровки содержимого других колонок можно найти выше, в опи-
сании DNS-системы (раздел 1.13 ).
При подготовке текста сообщения вы можете сначала восполь-
зоваться традиционным редактором. Текст будет тогда размещен в
файле и при отправке вы можете использовать, например, команду
GET и ввести содержимое файла в текст сообщения (с помощью
команды ~г имя_файла в UNIX). Чаще текст сообщения печатается
в реальном масштабе времени, непосредственно перед отправкой.
В этом случае сигналом конца ввода будет Ctrl-D или символ
(точка) в начале очередной строки. Если по какой-либо причине вы
передумали и не хотите отправлять уже набранное сообщение, про-
цедуру можно прервать, нажав Ctrl-C.
При необходимости посылки одного и того же текста несколь-
ким пользователям можно воспользоваться командой:
mail (или mailx) адрес_1 адрес_2 и т.д.
В этом случае сообщение будет послано по всем перечисленным
адресам. Формат этой операции заметно варьируется для разных
ЭВМ и программных пакетов. Вместо адресов могут использоваться
псевдонимы, что несколько облегчает задачу. Для хранения псевдо-
нимов (alias) служит специальный служебный файл. За описанием
работы с псевдонимами вынужден отослать вас к описанию почто-
вого пакета, с которым вы работаете.
На последней строке будет напечатан символ &, который ука-
зывает, что система ждет ввода команды (просмотр почты). Уход из
mail производится по команде q (quit). В ответ на & вы можете
ввести следующие команды (набор команд и их синтаксис может
варьироваться от ЭВМ к ЭВМ и от реализации к реализации, см.
табл. 4.5.8.1). Современные почтовые системы, работающие, напри-
мер под Windows, создают заметно больший комфорт.
При работе в Unix в процессе печатания текста сообщения вы
можете выдать почтовой программе определенные команды. Такие
Сети передачи данных. Метод доступа
1033
Таблица 4.5.8.1. Внутренние команды почтовой программы UNIX
Субкоманда MAIL Описание
Отображает весь набор описаний —команд
~Ь адрес... Добавляет адрес в строку "Blind сору" (слепая копия "Вес:").
-с адрес... Добавляет адрес(а) в строку ’’Сору” или ’’Сс:’’. ’
~d Читает содержимое файла dead.letter
~е Вызывает редактор текста
~f сообщения Считывает сообщения
~h Редактирует все строки заголовка.
~m сообщения Считывает сообщения, сдвигает указатель вправо на одну табуляцию
~р Отображает (печатает) текущее сообщение
Уход из почты (Quit), эквивалентно двойному Ctrl-C
~г файл Считывает содержимое указанного файла в текст сообщения
~s subject Изменяет содержимое строки Subject
~t адрес... Добавляет адрес в строку ”То:".
~N . Вызывает альтернативный редактор (то же, что и ~е).
~w файл Записывает текущее сообщение в файл
~! команда Выполняет команду Shell и возвращается к сообщению
~| команда Пропускает текущее сообщение через фильтр
команды начинаются с символа (тильда). В таблице 4.5.8.1 при-
веден список таких команд, текст набранный курсивом, означает, что
вместо него должны быть впечатаны имена, адреса и т.д. Многоточие
показывает, что может быть введено более одного имени, адреса и пр.
Если вы напечатаете ~f (без указания номера сообщения), в текст
текущего сообщения будет внесено содержимое сообщения, которое
вы читали последним. Стандартной формой использования ~f яв-
ляется, например, ~f 5, где 5 — номер сообщения. ~т делает тоже
самое, но каждая строка сдвигается на один tab вправо.
В UNIX многие команды имеют разные функции, если они напе-
чатаны строчными или прописными буквами, смотри, например, ко-
манды г и R в таблице 4.5.8.2. Не безразлично в UNIX и примене-
ние строчных и прописных символов в именах файлов, что бывает
существенно, в частности, при работе с FTP-сервером.
Важной командой является SET, которая позволяет изменять
системные переменные. Формат использования:
SET переменная=значение
(Например, SET EDITOR=/bin/edMe=/bin/eda).
1034
Гпава 4
Таблица 4.5.В.2. Команды, выполняемые почтовой программой
Команда Описание
Сокращение Полное имя
? - Отображение списка исполняемых команд
! - Выполнение одной команды Shell
+ - Отобразить следующее сообщение
RETURN - Отобразить следующее сообщение
- - Отобразить предшествующее сообщение
число - Отобразить сообщение с номером "число".
d delete Стереть текущее сообщение
dp - Стереть текущее сообщение и отобразить следующее
е edit Вызвать редактор для работы с сообщениями
h headers Отобразить список заголовков сообщений
I list Выдать список имен всех доступных команд
m mail Послать сообщение по указанному адресу или адресам
n - Отобразить следующее сообщение и распечатать его .
P print Отобразить (отпечатать) сообщения
pre preserve Сохранить сообщения в системном почтовом ящике
q quit Завершить работу с почтой
г replay Ответить отправителю и всем прочим получателям
R Replay Ответить только отправителю
s save Сохранить сообщения в указанном файле или в mbox, если имя файла не указано
sh shell Временно уйти из почты и вернуться в shell
t type Тоже что и print
to top Отобразить несколько верхних строчек сообщения
u undelete Восстановить ранее стертые сообщения
V - Редактирование сообщения с помощью экранного редактора
w write Тоже что и s, но без записи заголовка
X exit Выйти из почты без спасения внесенных изменений
z - Отобразить следующий набор заголовков
z- - Отобразить предшествовавший набор заголовков сообщений
Уже сегодня можно переслать поздравительную цветную открыт-
ку вашим знакомым. Возможна по такой схеме пересылка и звуко-
вых писем, лишь бы у вашего адресата была звуковая карта в ЭВМ.
Сети передачи данных. Метод доступа
1035
Ведутся работы и над протоколами видео-писем (NETBLT).
Тот факт, что электронная почта является наиболее популяр-
ным видом сервиса, делает ее объектом непрерывных доработок и
усовершенствований. Так в документах RFC-1425, -1426, -1427 пред-
лагается вариант расширения возможностей SMTP (ESMTP). Эта
модификация сохраняет совместимость со старыми версиями. Кли-
ент, желающий воспользоваться расширенными возможностями, по-
сылает команду EHLO вместо HELO. Если сервер поддерживает
ESMTP, он выдаст код-отклик 250. Этот вид отклика является
многострочным, что позволяет серверу сообщить о видах сервиса,
которые он поддерживает. Например:
250-8BITMIME (rfc-1426)
250-EXPN (rfc-821)
250-SIZE (rfc-1427)
250-HELP (rfc-821)
250-XADR
Ключевое слово 8BITMIME говорит о том, что клиент может доба-
вить ключевое слово BODY к команде MAIL FROM и определить тип
символов, используемых в сообщении (ASCII или 8-битные). Ключе-
вое слово XADR указывает на то, что любые ключевые слова, начина- /
ющиеся с X, относятся к местным модификациям SMTP. Документ
RFC-1522 определяет способ, как можно включить не ASCII-символы
в заголовок почтового сообщения. Например:
=?набор_символов ?кодировка ?закодированный_текст ?=
набор_символов — спецификация набора символов: us-ascii или
iso-8859-Х, где X — одиночная цифра, например iso-8859-l. Поле
кодировка содержит один символ, характеризующий метод кодиров-
ки. В настоящее время описаны два метода:
1. Q — набор печатных символов; символы, коды которых име-
ют неравный нулю 8-ой бит, отображается тремя символами: зна-
ком равенства (=), за которым следует два шестнадцатеричных числа
(например =AD). Так пробел будет иметь кодировку =20.
2. В — 64-символьный набор (Base64, латинские буквы, 10 цифр,
а также символы + и /). Набор кодов Base64 приведен в таблице:
Интересным дополнением к традиционной электронной почте
является ее расширение MIME (Multipurpose Internet Mail Extensions,
RFC-1521). MIME не требует каких-либо переделок в почтовых сер-
верах, это расширение определяет пять новых полей-заголовков (рас-
ширение RFC-822):
1036
Гпава 4
Таблица 4.5.8.3. Коды Base64
Код символа (6 бит) ASCII символ Код символа (6 бит) ASCII символ Код символа (6 бит) ASCII символ Код символа (6 бит) ASCII символ
0 А 10 Q 20 g 30 W
1 В 11 R 21 h 31 X
2 С 12 S 22 i 32 У
3 D 13 т 23 j 33 Z
4 Е 14 и 24 k 34 0
5 F 15 V 25 1 35 1
6 G 16 W 26 m 36 2
7 Н 17 X 27 n 37 3
8 I 18 Y 28 0 38 4
9 J 19 Z 29 P 39 5
А к 1А а 2А q ЗА 6
В L 1В b 2В r ЗВ 7
С м 1С с 2С s зс 8
D N 1D d 2D t 3D 9
Е О 1Е е 2Е u ЗЕ +
F Р 1F f 2F V 3F /
MIME-Version: (версия MIME, сейчас 1.0)
Content-Type: (тип содержимого, см. таблицу на рис. 4.5.8.4)
Content-Transfer-Encoding: (кодирование содержимого)
Content-ID: (идентификатор содержимого)
Content-Description: (описание содержимого)
Поле заголовка Content-Transfer-Encoding используется пять
видов кодировки (третий вид полей в приведенном выше списке):
1.7-бит (NVT ASCII, по умолчанию);
2. Набор печатных символов (полезен, когда только небольшая
часть символов использует 8-ой бит);
3.64-символьный набор (Base64 см. выше в таблице 4.5.8.3);
4. 8-битный набор символов, включающий псевдографику, с ис-
пользованием построчного представления;
5. Двоичная кодировка (8-битное представление без построчного
представления).
Только первые три типа согласуются с требованиями RFC-821.
MIME позволяет снять с электронной почты привычные ограниче-
ния и предоставляет возможность пересылать любую информацию.
Техника приложений (Attachment) позволяет пересылать через элек-
тронную почту любые файлы без какого-либо специального преоб-
разования, выполняемого пользователем. При этом необходимо толь- *
Сети передачи данных. Метод доступа
1037
ко, чтобы и приемник и передатчик поддерживали это расширение
электронной почты. В MIME предусмотрены следующие типы и суб-
типы содержимого почтового сообщения:
Таблица 4.5.8.4. Типы и субтипы почтовых сообщений.
Тип почтового сообщения Субтип почтового сообщения Описание
text plain Неформатированный текст
richtext Текст с простым форматированием, таким как курсйв, жирный, с подчеркиванием и т.д.
enriched Упрощение, прояснение и усовершенствование richtext
multipart mixed Сообщение содержит несколько частей, которые обрабатываются последовательно
parallel Сообщение содержит несколько частей, обрабатываемых параллельно
digest Краткое содержание почтового сообщения
alternative Сообщение содержит несколько частей с идентичным семантическим содержимым
message rfc822 Содержимое является почтовым сообщением в стандарте RFC-822
partial Содержимое является фрагментом почтового сообщения
external-body Содержимое является указателем на действительный текст сообщения
application octet-stream Произвольная двоичная информация
postscript PostScript программа
image jpeg Формат ISO 10918.
gtf Формат обмена CompuServe (Graphic Interchange Format).
audio basic Формат ISO ll 172
Текст электронного сообщения не передает всех оттенков мыс-
лей и эмоций отправителя, что может вызвать неверное восприятие.
Для решения этой проблемы хотя бы частично используются сим-
вольные обозначения эмоций. Таблица таких обозначений приведе-
на ниже. Чтобы легче воспринять и запомнить их, посмотрите на
страницу, где напечатана таблица, справа.
Символ Значение
-) -D -) Улыбка Смех Подмигивание
1038
Гпава 4
: - ( Неудовольствие
:-< Огорчение
8-) Удивление
:-о О, нет!
:-1 Безразличие
: - # Вынужденная улыбка
:-] Ухмылка
:-{) Улыбка с усами
{: -) Улыбка с париком
:-Х Мой рот на замке
=:-) Панк-рокер
=:-( Настоящий панк-рокер никогда не улыбается
% ') Название для этой улыбки читателям предлагает-
ся придумать самостоятельно
В последнее время большинство почтовых серверов реализуется
в среде UNIX, где функцию почтового демона (фонового процесса)
выполняет программа sendmail. Эта программа осуществляет пере-
адресацию сообщений от пользователя пользователю и от сервера
серверу. Программа эта имеет большие возможности, но ее конфигу-
рирование и использование представляет немалые трудности.
4.5.9. SET и другие системы осуществления платежей
Для операций с кредитными карточками используется протокол
SET (Secure Electronic transactions; см. http:// www.visa.com/cgi-
bin/vee/sf/standard.htmlhttp://www.citynet.net/personal/till/
setl.htm), разработанный совместно компаниями Visa, Mastercard,
Netscape (http://www.netscape.com) и Microsoft. В отличие от SSL
протокол SET узко специализирован. На базовом уровне SET про-
изводит следующие операции:
1. Аутентификация. Все участники кредитных операций иден-
тифицируются с помощью электронных подписей. Это касается кли-
ента-покупателя, продавца и банкира, выдавшего кредитную кар-
точку.
2. Конфиденциальность. Все операции производятся в зашиф-
рованном виде.
3. Обеспечение целостности сообщений. Информация не может
быть подвергнута модификации по дороге.
4. Подсоединение. SET позволяет подключить к базовому сооб-
щению дополнительный текст и послать его одному из партнеров.
На более высоком уровне протокол SET поддерживает все воз-
можности, предоставляемые современными кредитными карточками:
Сети передачи данных. Метод доступа
1039
1. Регистрацию держателя карточки
2. Регистрацию продавца
3. Запрос покупки
4. Авторизацию платежа
5. Перевод денег
6. Кредитные операции
7. Возврат денег
8. Отмену кредита
9. Дебитные операции
Окончательная версия протокола SET была выпущена в мае 1997
года. Протокол работает с четырьмя субъектами: владельцем кре-
дитной карточки, банком, эту карточку выпустившим, продавцом
и банком, где размещен счет продавца. Многие современные WEB-
броузеры также поддерживают протокол SET. Что позволяет осуще-
ствлять торговлю товарами и услугами с использованием WWW-
технологии. Напрашивается вопрос, почему для финансовых опера-
ций не использовать протокол SSL? SSL позволяет безопасно
передавать продавцу номер кредитной карточки покупателя, но не
способен реализовать многие другие операции, например, проверить
этот номер на правильность, проконтролировать, позволено ли данно-
му клиенту пользоваться данной карточкой и т.д.. Конечно, не труд-
но создать CGI-скрипты, которые решат некоторые из этих проблем,
но это не может заменить контроля реального времени, необходимого
для некоторых операций. Нельзя утверждать, что в рамках протоко-
ла SSL не возможно решить и эти проблемы, но для этого нужно
создать достаточно большое число специализированных программ,
которые в существующих пакетах пока отсутствуют. Кроме того, нужно
думать и о безопасности на стороне сервера. Продавец, получив номер
кредитной карточки, может занести его в базу данных. А где гаран-
тия (для покупателя), что эта база данных достаточно хорошо защи-
щена? Таким образом, даже передача номера кредитной карточки по-
средством SSL не самая лучшая идея. Тем более такая схема позво-
ляет осуществлять подбор номеров кредитных карт. А заботиться об
удобствах воров не самое полезное занятие.
Номер кредитной карточки имеет определенную структуру (это
не случайное число). Первые четыре цифры - код банка, выпустив-
шего карточку. Последняя цифра представляет собой контрольную
сумму номера. Вычисление этой контрольной суммы производится
по следующему алгоритму.
Каждая цифра номера умножается на ее «вес». Веса меняются
1,2,1,2. Для карт с четным числом цифр, последовательность весов
1040
Гпава 4
начинается с 2, в противном случае с 1. Если взвешенное число
больше 9, вычитаем из него 9. Далее вычисляется сумма по модулю
10. Результат всегда должен получаться равным нулю (с учетом
кода контрольной суммы). Схема взаимодействия субъектов в про-
токоле SET показана на рис. 4.5.9.1. Протокол SET помогает реа-
лизовать следующие процедуры.
выдача
кредитной
карточки
юдтверждение
платежа
Заказ
Покупатель
Заполненная
форма-заказ
Платеж
Сумма и
код покупки
Г номер
।кредитной
| карточки
номер ।
“кредитной I
карточки I
продавец
Уведомление
о
платеже
Рис. 4.5.9.7. Схема взаимодействия субъектов протокола SET
1. Покупатель инициализирует покупку. При этом покупатель
просматривает WEB-сайт продавца, принимает решение о покупке,
заполняет бланк заказа. Все это делается до вступления в дело
протокола SET. SET начинает свою работу, когда покупатель нажи-
мает клавишу оплаты. При этом сервер посылает ЭВМ-покупателя
сообщение, которое и запускает соответствующую программу. Про-
цедура эта может быть реализована с помощью CGI-скрипта или
JAVA-аплета.
2. Программа клиента посылает заказ и информацию об оплате.
Для этого формируется два сообщения, одно содержит данные о
полной стоимости покупки и номере заказа, второе - номер кредит-
ной карточки покупателя и банковскую информацию. Сообщение о
заказе шифруется с использованием симметричного метода (напри-
мер, DES) и вкладывается в цифровой конверт, где используется
общедоступный ключ продавца. Сообщение об оплате шифруется с
привлечением банковского общедоступного ключа. Таким образом
Сети передачи данных. Метод доступа
1041
продавец не получает доступа к номеру кредитной карточки поку-
пателя. Программа генерирует хэш-дайджест обоих сообщений с
использованием секретного ключа покупателя. Это позволяет про-
давцу и банкиру проконтролировать целостность сообщения, но пре-
пятствует прочтению части, ему не предназначенной.
3. Продавец выделяет часть, адресованную банкиру, и направля-
ет ее по месту назначения. Программа SET WEB-сервера продавца
генерирует запрос авторизации серверу банка, где находится счет
продавца. При формировании запроса авторизации используется
электронная подпись продавца, базирующаяся на его секретном
ключе, что позволяет однозначно его идентифицировать. Этот зап-
рос шифруется с помощью ключа сессии и вкладывается в цифровой
конверт, где используется общедоступный ключ банка.
4. Банк проверяет действительность кредитной карточки, дешиф-
рует запрос авторизации продавца и идентифицирует продавца. После
этого осуществляется проверка авторизации покупателя. При этом
посылается запрос авторизации, снабженный электронной подпи-
сью, банку, выпустившему кредитную карточку.
5. Банк, выпустивший карточку, выполняет авторизацию и под-
писывает чек, если кредитная карточка покупателя в порядке. От-
клик, снабженный соответствующей подписью, посылается банку
продавца.
6. Банк продавца авторизует данную операцию, и посылает под-
тверждение, подписанное электронным образом, WEB-серверу про-
давца.
7. WEB-сервер продавца завершает операцию, выдавая клиенту
подтверждение на экран, и заносит результат операции в соответ-
ствующую базу данных.
8. Продавец осуществляет подтверждение выполнения операции
своему банку, Деньги покупателя переводятся на счет продавца.
9. Банк, выпустивщий карточку, посылает счет покупателю и
SET уведомляет покупателя об изменениях на его счету (раз в ме-
сяц).
Итак, видно, что каждый шаг реализации протокола SET сопро-
вождается аутентификацией. Это препятствует какому-то внешне-
му субъекту стать посредником и видоизменять сообщения.
В выше приведенном описании предполагалось, что все субъек-
ты процедуры уже владеют соответствующими ключами. На прак-
тике до начала такого обмена все участники должны зарегистриро-
ваться и обменяться общедоступными ключами. Общедоступный
Ключ сопровождается электронной подписью отправителя (документ
X.509v3). SET может работать в режиме, когда участники не имеют
34 Зак. № 3430 Семенов
1042
Гпава 4
сертификатов и не прошли аутентификацию. Такой режим сопос-
тавим с использованием SSL для пересылки номера карточки про-
давцу и не может рассматриваться как удовлетворительный. Для
реализации протокола SET в конкретных приложениях можно ис-
пользовать утилиту Wallet (http://www.microsoft.com/commerce/
wallet/) фирмы Microsoft (Microsoft Commerce Server). Следует учи-
тывать, что так как система SET является достаточно сложной и
дорогостоящей, а продавец должен платить за каждую операцию с
кредитной карточкой, то через систему SET проходят платежи, превы-
шающие 10$.
Для осуществления более мелких платежей используются другие
схемы (например, First Virtual, CyberCoin, DigiCash (http://
www.digicash.nl) или Millicent — http://www.millicent.digital.com/).
Схема First Virtual (http://www.fv.com) предназначена для прода-
жи дешевых программных продуктов или услуг. Она предполагает
регистрацию клиента, при которой он сообщает номер своей кредит-
ной карточки и получает регистрационный номер (PIN). При по-
купке клиент вводит свой индивидуальный номер и, если он верен,
немедленно получает доступ к нужному ему продукту. Позднее First
Virtual связывается с клиентом по электронной почте, уведомляет о
цене покупки, предоставляя ему одобрить или нет снятие соответ-
ствующей суммы с его кредитной карточки. Эта система зиждется
на полном доверии и честности обеих сторон.
Система CyberCash (http://www.cybercash.com) базируется на
схеме, сходной с SET. Здесь также используется специальное про-
граммное обеспечение со стороны клиента и продавца. Клиент при
регистрации получает бесплатно программу CyberCash Wallet и за-
полняет идентификационную и платежную информацию. Эта ин-
формация в зашифрованном виде будет храниться на ЭВМ клиен-
та. Эти данные посылаются при нажатии клиентом клавиши «оп-
латить». Система предоставляет ряд дополнительных услуг клиенту,
например просмотр баланса последних операций.
5. Заключение
Автор признателен читателю, который прочел эти тексты до кон-
ца. Надеюсь, что это было не самое скучное и бесполезное занятие.
Я являюсь свидетелем и участником развития Интернет в России с
самого его начала и это внушает самые оптимистические надежды.
В стране, где главным жизненным увлечением заметной части на-
селения является воровство (во всяком случае, той ее части, кото-
рая имеет возможность и определенные способности), появление до-
рогостоящей общенациональной сети при полном отсутствии под-
держки со стороны правительства (по крайней мере, на начальном
этапе) можно считать чудом двадцатого века. Причины этого явле-
ния еще предстоит понять и объяснить.
Существующая система Internet неидеальна, в ней не мало недо-
статков больших и малых. Наиболее серьезные трудности связаны
с проблемой маршрутизации, не существует механизма выравнива-
ния загрузки каналов в рамках внешних протоколов, механизмы
управления не всегда удобны и безопасны, диагностика не совер-
шенна. Система адресации Internet архаична и уже готов новый
стандарт (расширение разрядности адресов до 128), многие сервис-
ные услуги неудобны. Так, например, не производится предупрежде-
ния об отключении связи при пассивности пользователя, telnet не
имеет возможностей непосредственного копирования удаленных
файлов, поисковые системы не всегда позволяют найти то, что нуж-
но, если эта информация имеется и т.д. и пр. Но именно это должно
привлечь новых молодых людей (возможно и из России), которые
усовершенствуют систему. Ничто не идеально в этом мире, ведь
совершенство означает прекращение развития и, следовательно, не-
избежную гибель. Internet жив, возможно его идеи поменяют жизнь
людей не меньше, чем это сделало радио или телевидение. Ведь
именно Интернету мы обязаны появлением электронных журналов,
всемирных дискуссионных клубов по интересам, глобальных баз
Данных, IP-телефонии, видеоконференций и прочих удивительных
З4*
1044
Заключение
вещей, именно электронная почта помогла распространять правди-
вую информацию в незабвенные августовские дни 1991 года. Та-
ким образом, телекоммуникационные сети могут стать гарантом
демократии, можно блокировать телевидение и прессу, но чтобы ос-
тановить электронную почту, нужно выключить телефонную сеть
по всей стране.
Попробую сделать некоторые конкретные прогнозы в этой обла-
сти на будущее. Меня на это подталкивает стоящая у меня дома на
полке книга «Космическая эра. Прогнозы на 2001 год» (Москва,
«Мир», 1970), которая является переводом книги «Space Age in Fiscal
Year 2001», 1966. В этой книге дан прогноз развития науки и
технологии до 2001-го года. Прогнозы этой книги в области космо-
са оказались чересчур оптимистичными (обитаемые станции на Луне,
полеты человека к Марсу, коммерция в космосе и т.д.). Удивитель-
но, что во время написания этой книги люди уже разрабатывали и
испытывали технологии, которые легли в основу Интернет. Приво-
жу цитату из этой книги:
«Устройства графической и буквенно-цифровой индикации бу-
дут использоваться не только как средство взаимодействия челове-
ка с машиной, но, по-видимому, с помощью таких быстродействую-
щих устройств можно будет также осуществлять и связь между
людьми» (это ведь написано 1965 году, когда практически не было
графических дисплеев, а локальные сети только проектировались).
За 35 лет сделан совершенно точный прогноз относительно циф-
ровых телекоммуникаций. Полагаю, прогресс в этой области даже
превзошел то, что себе представляли авторы этой книги. Я не реша-
юсь сделать столь далекие предсказания.
1. К 2002 году появятся первые гибриды ЭВМ и телевизора, а к
2005 эти приборы станут массовыми.
2. В 2010 году в России во многих городах будут созданы обще-
городские сети кабельного цифрового телевидения с доступом к
Интернет из любого дома, будут заложены основы общенациональ-
ной сети. Традиционная подписка на газеты и журналы будет заме-
нена подпиской на отдельные статьи по вашему выбору (зачем оп-
лачивать то, что вам не интересно, печатать и перевозить никому
ненужную бумагу, да и сохранение лесов неплохой аргумент для
этого) с возможностью чтения на экране телевизора и распечаткой
при необходимости на принтере.
3. К 2010 году будут созданы электронные книги — переносные
устройства для чтения текстов, записанных на CD, с возможностью
звукового, а со временем и полномасштабного мультимедийного вос-
произведения. Вудет возможен и сетевой доступ к библиотекам.
Заключение
1045
4. К 2010 телефонные магнитные карты будут снабжены инди-
видуальными характеристиками голоса клиента, которые будут пе-
редаваться принимающей стороне при вызове. Процессор в теле-
фонном аппарате будет преобразовывать голос в символьную после-
довательность (в текст). Это позволит передавать по каналу только
текст, индивидуальность голосу будет придаваться на принимаю-
щей стороне при синтезе, что сократит на порядок требования к
полосе канала.
5. К 2020 году будет создана всемирная информационная сеть,
базирующаяся на широкополосных оптоволоконных каналах (те-
левидение, новости в аудио и видео форматах, полный информаци-
онный сервис). Россия здесь задержится на 5-10 лет из-за нынеш-
него провала в сфере образования.
Время покажет, был ли я пессимистом или оптимистом. В том,
что все это будет, я уверен, могу ошибаться только в сроках. Пред-
посылками для этого должны стать снижение цен на отоволокон-
ные кабели, принтеры и терминальное оборудование, разработки де-
шевых специализированных интегральных схем, часть из которых
уже имеется, другие разрабатываются сегодня; аппаратные устрой-
ства сжатия информации и много другое. Создание широкой инфор-
мационной сети с доступом в каждый дом породит немало новых
проблем. Это, прежде всего обеспечение защиты частной информа-
ции, предотвращение вторжения в личную жизнь. Огромную работу
здесь предстоит выполнить программистам. Здесь и разработка бо-
лее эффективных алгоритмов сжатия данных, шифрования/дешиф-
рования информации, новых протоколов передачи, удобных пользо-
вательских интерфейсов, более совершенных распределенных баз
данных и поисковых систем. Буду счастлив, если среди людей, кто
внесет свой вклад в это общее дело, окажутся и читатели этой кни-
ги. В XXI веке сети предоставят много новых рабочих мест для
граждан планеты Земля. Желаю гражданам всемирного государ-
ства Интернет новых успехов и приятных приключений.
6. Литература
1. Ю. В. Прохоров, Ю. А. Розанов. Теория вероятностей.
Основные понятия, предельные теоремы, случайные про-
цессы. Наука, Глав. Ред. Физмат литературы, М. 1967, серия
« Справочная математйческая библиотека».
2. Guide to Network Resource Tools. EARN Association, Sept.
15, 1993, V2.0. (ISBN 2- 910286-03-7).
3. Douglas E. Comer, Internetworking with TCP/IP, Prentice
Hall, Englewood Cliffs, N.J. 07632, 1988
4. Uyless Black, TCP/IP and Related Protocols, McGraw-Hill, Inc,
New York. 1992
5. Feinler, E., et al, DDN Protocol Handbook, DDN Network Infor-
mation Center, SRI International, Ravenswood Avenue, Menlow
Park, California, USA, 1985
6. Spider Systems, Ltd., «Packets and Protocols», Stanwell Street,
Edinburgh, UK. EH6 5NG, 1990.
7. Tony Bates, et al, «Representation of IP Routing Polices in a
Routing Registry» (RIPE-181.txt, October 1994)
8. A. N. Bobyshev, S. I. Burov, M. Ernst, A. I. Kravtsov, A. O.
Saphonov, Yu. A. Semenov «ITEPNET to Internet communi-
cation», ITEP HI-92.
9. Robert J. T. Morris «Neural Network Control of Communi-
cations Systems» IEEE Transactions on Neural Networks, Vol. 5,
No. 4, July 1944.
10. Paul J. Fortier, Handbook of LAN Technology. 2-nd Edition,
McGraw-Hill, 1992
11. W.Richard Stevens «TCP/IP Illustrated», Addison-Wesley
Publishing Company, 1994^
12. Matthew Flint Arnett, Mike Coulombe, et al. Inside TCP/IP,
Second Edition, New Riders Publishing, 1995
13. Лаура Ф. Чаппелл и Дэн Е. Хейкс. Анализатор локальных
сетей NetWare (Руководство Novell), Москва, Изд. «ЛОРИ»,
1995.
Литература
1047
14. А. В. Фролов и Г. В. Фролов, Локальные сети персональ-
ных компьютеров. Использование протоколов IPX, SPX,
NETBIOS, Москва, «Диалог-МИФИ», 1993
15. К. Джамса, К. Коуп, Программирование для INTERNET в
среде Windows, Санкт-Петербург, «ПИТЕР», 1996.
16. ISDN How to get a high-speed connection to the Internet,
Charles Summers, Bryant Dunetz, «John Wiley @ Sons, Inc.»
17. ISDN Explained, Worldwide Network and Applications
Technology, 2 edition, John M. Griffiths, John Wiley & sons.
18. ISDN. Цифровая сеть с интеграцией служб. Понятия,
методы, системы. П. Боккер, Москва, Радио и связь, 1991.
19. С. Вильховченко, Модем 96. Выбор, настройка и использо-
вание. Москва, ABF, 1995.
20. Справочник «Протоколы информационно-вычислительных
сетей». Под ред. И. А. Мизина и А. П. Кулешова, Радио и
связь, Москва 1990.
21. Craig Hunt, TCP/IP Network Administration, O’Reilly Associ-
ates, Inc., Sebastopol, USA, 1992
22. А. В. Фролов и Г.В. Фролов, Модемы и факс-модемы.
Программирование для MS-DOS и Windows. Москва,
«Диалог-МИФИ», 1995.
23. Семенов Ю. А. «Протоколы и ресурсы INTERNET» «Радио
и связь», Москва, 1996
24. Семенов Ю. А. «Сети Интернет. Архитектура и протоко-
лы», СИРИНЪ, 1998.
25. А. Н. Назаров, М.В. Симонов, «ATM-технология высокоско-
ростных сетей» ЭКО-ТРЕНДЗ, Москва 1998.
26. Н. Н. Слепов, «Синхронные цифровые сети SDH» ЭКО-
ТРЕНДЗ, Москва 1998.
27. «Интернет. Всемирная компьютерная сеть. Практическое
пособие и путеводитель». Москва 1995, изд. «Синтез».
28. «World Wide Web. Всемирная Информационная паутина в
сети Интернет». Практическое'руководство. МГУ, 1995.
29. Эд Крол «Все об INTERNET» BNV, Киев 1995.
30. Пол Гилстер «Навигатор INTERNET. Путеводитель для
человека с компьютером и модемом», Москва 1995.
31. С. Клименко, В. Уразметов «Internet. Среда обитания
информационного общества». РФФИ, Информационные
системы в науке.
32. Лаем Куин, Ричард Рассел, Fast Ethernet, bhv, Киев, 1998.
1048
Литература
33. Тимоти Паркер, Освой самостоятельно TCP/IP. Бином,
Москва 1997.
34. Дональд Дж. Стерлинг, Волоконная оптика. Техническое
руководство. Изд. «ЛОРИ», Москва, 1998
35. Дж. Гауэр, Оптические системы связи. Москва, «Радио и
связь», 1989.
36. Стивен Спейнаур и Валери Куэрсиа. Справочник WEB-
мастера, BHV, Киев, 1997.
37. Lincoln D. Stein, Web Security: a step-by-step reference
guide, Addison-Wesley, 1997
ПРИЛОЖЕНИЯ
7.1. Рекомендации CCITT, ANSI, ЕСМА
по телекоммуникациям
Коды названий документов ITU, CCITT, ANSI и ЕСМА по теле-
коммуникационной тематике начинаются с латинской прописной
буквы, за которой следует точка и номер документа. Ниже приведен
список кодировок документов и перечень наиболее важных реко-
мендаций.
Е Операции, нумерация и маршрутизация.
G Телекоммуникационные системы передачи.
Н Линии передачи для нетелефонных сигналов.
I Общие материалы по ISDN.
Q Сигнальные системы.
Т Терминальное оборудование и протоколы телекоммуника-
ционных услуг.
V Передача данных по коммутируемым телефонным сетям.
X Сети передачи данных.
Код рекомендации Содержание
ANSI T1.102 Цифровая иерархия — электрические интерфейсы;
ANSI Tl.111-116 Сигнальная система N7;
ANSI T1.403 Конструкция интерфейса DS1
ANSI T1.408 Спецификация связи пользователя с первым уровнем первичного канала;
ANSI T1.602 Интерфейс базового канала, процедура доступа к первичному каналу, D-канал (LAP1); связной протокол BRI/PRI;
ANSI T1.603 Минимальный набор услуг для интерфейса первичного канала ISDN;
ANSI T1.604 Минимальный набор услуг базового канального интерфейса ISDN;
ANSI T1.605 Спецификация интерфейса базового канала для связи пользователя с сетью; спецификация интерфейса BRA S/T;
ANSI T1.606 Описание услуг Frame Relay;
1050
Приложения
ANSI Т1.607
ANSI T 1.608
ANSI T1.609
ANSI T1.610
ANSI T1.617
ANSI T1.618
CCIR 601-1
ECMA-104
ECMA-105
ECMA-106
ECMA-123
ECMA-133
ECMA-134
ECMA-135
ECMA-141
ECMA-142
Основные управляющие процедуры для BRI и PRI;
Пакетные режимы канала. Управляющие
процедуры BRI и PRI;
Цифровая система подписки N1 ISDN для меж-
сетевых связей в рамках сигнальной системы N7;
Базовые процедуры для управления вспомога-
тельными услугами ISDN;
Сигнальные спецификации для канальных
услуг Frame Relay;
Базовые аспекты протокола Frame Relay;
Параметры кодировки студийного цифрового
телевидения;
Физический уровень интерфейса для доступа к
первичному каналу в частных телекоммуника-
ционных сетях;
Протокол уровня канала данных для D-канала
интерфейса в эталонной точке между терми-
нальным оборудованием и частной телекомму-
никационной сетью;
Протокол третьего уровня для управления
переадресацией вызовов через интерфейс D-
канала в эталонной точке S между терминаль-
ным оборудованием и частной телекоммуника-
ционной сетью
Обмен параметрами в частных ISDN-сетях на
базе стандарта ЕСМА-102;
Эталонная конфигурация для вызовов через
коммутатор частной телекоммуникационной
сети;
Метод спецификации базовых и дополнитель-
ных видов сервиса в частных телекоммуникаци-
онных сетях.
Алгоритмы связи коммутаторов частных теле-
коммуникационных сетей;
Протокол уровня канала данных для эталонной
точки Q сигнального канала между коммутато-
рами частных телекоммуникационных сетей;
Влияние спецификации, функциональной моде-
ли и потоков данных на управление базовыми
услугами в частных телекоммуникационных
сетях;
Приложения
1051
ЕСМА-143 Протокол третьего уровня для управления переадресацией вызовов между коммутаторами частных телекоммуникационных сетей;
ЕСМА148 Идентификация дополнительных услуг в част- ных телекоммуникационных сетях; специфика- ция, функциональные модели и информацион- ные потоки;
ЕСМА-155 Адресация в частных телекоммуникационных сетях;
ЕСМА-156 Основные процедуры для управления дополни- тельными услугами, используя протокол keypad в эталонной точке S.
ЕСМА-157 Протокол управления по D-каналу в эталонной точке S интерфейсами между терминальным оборудованием и частной телекоммуникацион- ной сетью для поддержки идентификации дополнительных услуг.
F.60 F.69 F.160 Стандарт телексной связи Стандарт для телексных адресов Стандарт на международную общественную факсную связь
F.200 F.201 Стандарт телетекстной связи Стандарт для служб межсетевого обмена для телетекста и телекса
F.300 F.401 Набор рекомендаций для систем видеотекста Стандарт на имена и адреса при передаче сооб- щений
F.410 F.420 F.421 Стандарт службы передачи сообщений Стандарт для частного обмена сообщениями Стандарт для коммуникаций между системами Х.400 при обмене частными и телексными сообщениями
F.500 G.702 G.703 Стандарт международной службы каталогов Иерархия цифровых скоростей обмена Физические и электрические характеристики цифровых интерфейсов.
G.707 Иерархия частот синхронной передачи двоичной цифровой информации
G.708 Синхронный интерфейс сетевого узла для циф- ровой передачи данных в широком диапазоне частот следования.
G.709 Структура синхронного мультиплексирования.
105 2
Приложения
G.711 Импульсно-кодовая модуляция (PCM) голосо- вых частот.
G.721 Адаптивная дифференциальная кодово-импульс- ная модуляция (ADPCM) для- частоты 32 Кбит/с.
G.722 Аудио кодирование в частотном диапазоне 7 кГц для скоростей передачи 64 Кбит/с.
G.725 Системные аспекты использования 7 килогерцно- го аудио кодека на скоростях передачи 64 Кбит/с.
G.728 CCITT рекомендация для ADPCM при16 Кбит/с (3.1 кГц)
H.221 Структура кадра канала на 64 Кбит/с для аудио и видео приложений.
H.231 Многоточечный контроль для скоростей 64- 2048 Кбит/с
H.242 H.243 Коммуникационные процедуры, 64-2048 Кбит/с. Многоточечные коммуникационные процедуры, 64-2048 Кбит/с.
H.261 Видео кодек для аудио-видео сервиса при р*64 Кбит/с (р=1-30).
H.320 CCITT рекомендации для узкополосных видео- телефонных систем и терминального оборудова- ния со скоростями не более 1920 Кбит/с. Общее описание CODEC.
1.110 Введение и общая структура серии документов «I» для интегрированных цифровых сетей ISDN
I.Ill Взаимоотношения с другими рекомендациями, относящимися к ISDN
1.112 1.113 1.120 1.121 1.122 Словарь терминов ISDN Словарь терминов для широкополосной ISDN Интегрированные цифровые сети ISDN Широкополосные аспекты ISDN Рамки для предоставления услуг в канале, работающем в пакетном режиме
1.130 Метод описания телекоммуникационных услуг, поддерживаемых ISDN и сетевые возможности ISDN
1.140 Методика атрибутов для описания телекомму- никационных услуг ISDN и сетевых возможнос- тей ISDN
1.141 1.150 1.200 Атрибуты сети ISDN Характеристики ATM В-ISDN Указатель по серии рекомендаций 1.200
Приложения
1053
1.210 Принципы предоставления телекоммуникацион- ных услуг ISDN и методы их описания
1.211 1.220 Аспекты услуг B-ISDN Общее динамическое описание базовых телеком- муникационных услуг
1.221 1.327 1.230 Общие характеристики услуг Функциональная архитектура сетей B-ISDN. Определение категорий услуг, предоставляемых каналом
Коммутация каналов
1.231 Категории схемных услуг, предоставляемых каналом
1.231.1 1.231.2 64 Кбит/с (структура по 8кбит/с) 64 Кбит/с (структура по 8кбит/с) с возможнос- тью передачи'звуковой информации
1.231.3 64 Кбит/с (структура по 8кбит/с) для аудио- передачи с полосой 3.1 кГц
1.231.4 64 Кбит/с (структура по 8кбит/с) поперемен- ный разговор
1.231.5 1.231.6 1.231.7 1.231.8 2* 64 Кбит/с (структура по 8кбит/с) 384 Кбит/с (структура по 8кбит/с) 1536 Кбит/с (структура по 8кбит/с) 1090 Кбит/с (структура по 8кбит/с)
Коммутация пакетов
1.232 Категории пакетных услуг, предоставляемых каналом
1.232.1 Виртуальный вызов и постоянная виртуальная схема
1.232.2 1.232.3 1.233.1 Бессвязная схема Пользовательская сигнальная система Услуги передачи кадров (FMBS) в ISDN —
1.233.2 передача кадров Услуги передачи кадров (FMBS) в ISDN —
1.240 1.241 1.250 1.251 коммутация кадров Определение удаленных услуг Удаленные услуги, поддерживаемые ISDN Определение дополнительных услуг Идентификационные коды вспомогательных
1-252 1-253 х-253.1 услуг Запрос вспомогательных услуг Завершение выполнения вспомогательных услуг Ожидание запроса вспомогательных услуг
1054
Приложения
1.254 Вспомогательные услуги для нескольких клиентов
1.255.4 Приоритетное обслуживание
1.257 Передача дополнительной информации
1.310 Принципы работы сети ISDN
1.311 Общие аспекты сети B-ISDN
I.312(Q.12O1) Принципы архитектуры интеллектуальных сетей
1.320 Эталонная модель протоколов ISDN
1.321 Эталонная модель протоколов В-ISDN и ее применение
1.324 Архитектура сети ISDN
1.325 Типы эталонных конфигураций соединений в ISDN
1.326 Относительные требования к ресурсам сети
1.327 Функциональная архитектура сети B-ISDN
1.328 (Q.1202) Интеллектуальная сеть — архитектура плоско- сти услуг
1.329 (Q.1203) Интеллектуальная сеть — архитектура гло- бальных функций
1.330 Принципы нумерации и адресации в ISDN
1.331 (Е.164) Схема нумерации в ISDN
1.332 Принципы нумерации для межсетевых соедине- ний ISDN и сетей с различными схемами нуме- рации
1.333 Выбор терминала в ISDN
1.334 Принципы связи чисел/субадресов ISDN и сетевых адресов эталонной модели OSI
1.335 Принципы маршрутизации ISDN
1.351 (G.821/2) Рекомендации других серий, связанные с рабо- той сети, для эталонной точки Т ISDN
1.352 Объективные характеристики сети, связанные с задержками соединений в ISDN
1.361 Спецификация слоя ATM B-ISDN
1.362 Функциональное описание адаптационного уровня для B-ISDN (AAL).
1.363 Спецификация уровня адаптации (AAL) ATM B-ISDN
1.370 Управление перегрузкой для каналов фрейм- релей ISDN
1.410 Общие аспекты и принципы, связанные с реко- мендациями для пользовательского интерфейса ISDN
Приложения
1055
1.411 Сетевой интерфейс пользователя ISDN — эта- лонная конфигурация
1.412 1.413 1.420 1.421 1.430 1.431 1.432 1.440 (Q.920) Интерфейс пользователя сети ISDN — структура интерфейса возможности доступа Интерфейс пользовательской сети B-ISDN Базовый сетевой интерфейс пользователя' Сетевой интерфейс пользователя первичного быстродействия Базовый сетевой йнтерфейс пользователя — спецификация слоя 1 Сетевой интерфейс пользователя первичного быстродействия — спецификация уровня 1 Сетевой интерфейс пользователя B-ISDN — спецификация физического уровня Связной информационный уровень сетевого
1.441 (Q.921) интерфейса пользователя ISDN общие аспекты Сетевой интерфейс пользователя ISDN — специ-
1.450 (Q.930) фикация связного информационного уровня Сетевой интерфейс пользователя ISDN — уро-
1.451 (Q.931) вень 3, общие аспекты Спецификация уровня 3 для сетевого интерфей-
1.452 (Q.932) са пользователя ISDN для управления базовыми запросами Общие процедуры для управления дополнитель-
1.460 1.461 (Х.ЗО) ными услугами ISDN Мультиплексирование, адаптация к скорости передачи и поддержка существующих интерфейсов Поддержка терминального оборудования (DTE)
1.462 (Х.31) базирующегося на Х.21, Х.21бис и Х.20бис интегрированными цифровыми сетями (ISDN) Базовые процедуры для управления дополни-
1.463 (V.110) тельными услугами ISDN Поддержка ISDN терминального оборудования в
1.464 1.465 (V.120) пакетном режиме Мультиплексирование, адаптация к скорости передачи и поддержка существующих интерфей- сов для передачи на скоростях 64 Кбит/с Поддержка ISDN терминального оборудования с
1.470 интерфейсами типа V при статистическом мультиплексировании Взаимодействие терминальных функций и ISDN
1056 Приложения
1.500 Общая структура рекомендаций для взаимодей- ствия ISDN
1.510 Определения и общие принципы взаимодей- ствия в ISDN
1.511 Интерфейс уровня 1 для системы ISDN-ISDN
1.515 Обмен параметрами при взаимодействии систем ISDN
1.520 Общие принципы организации для межсетевых взаимодействий в ISDN
1.530 Взаимодействие сетей ISDN и публичных ком- мутируемых телефонных сетей
1.540 (Х.321) Общие приспособления для взаимодействия между сетями ISDN и коммутируемыми публич- ными телефонными сетями (CSPDN)
1.550 (Х.325) Общие приспособления для взаимодействия между сетями ISDN и публичными сетями с пакетным переключением (PSPDN) для целей передачи информации
1.560 (U.202) Требования, предъявляемые к системе ISDN, для обеспечения телексных услуг
1.601 Общие принципы работы системы доступа для клиента ISDN и инсталляция клиента
1.602 Использование принципов ISDN при инсталля- ции клиентов
1.603 Использование принципов работы ISDN для обеспечения доступа
1.604 Использование принципов работы ISDN для обеспечения доступа на первичных скоростях обмена
1.605 Применение принципов статического мульти- плексирования при реализации базового досту- па к ISDN
1.610 ОАМ-принципы доступа в B-ISDN
ISO 2110 Передача данных 25-контактный соединитель интерфейса DTE-DCE и распределение его кон- тактов.
ISO 2593 Распределение контактов разъема для высоко- скоростного терминального оборудования.
ISO 3166 Коды стран (DCC — Data Country Code).
ISO 4902 Передача данных. 37- и 9-контактные разъемь? интерфейса DTE-DCE и распределение контактов.
Приложения
1057
ISO 4903 Передача данных. 15-контактный разъем интер- фейса DTE-DCE и распределение контактов.
ISO 8473 Протокол доступа к сети без непосредственной связи (CLNAP ConnectionLess Network Access Protocol)
ISO 8877 Интерфейсный разъем и назначение контактов для эталонных точек доступа ISDN S и Т.
ISO 9282-2 ISO 11172-3 Метод сжатия стационарного изображения Кодировка движущегося изображения и сопро- вождающего звука для цифровых систем запи- си при скоростях передачи 1,5 Мбит/с — Часть 3. Звук.
Q.500 Q.512 Введение и область применения ISDN Интерфейс коммутатора для доступа клиентов ISDN
Q.513 Интерфейс коммутатора для операций, админис- трирования и обслуживания
Q.521 Q.522 Функции интерфейса Цифровой коммутатор. Связи, управление, вспомогательные функции
Q.541 Q.542 Q.543 Q.544 Q.551 Общая конструкция Конструкция, операции и обслуживание Рабочие характеристики систем ISDN Измерения на коммутаторе ISDN Передающие характеристики цифровых комму- таторов
Q.552 Передающие характеристики 2-х проводных аналоговых интерфейсов
Q.553 Передающие характеристики 4-х проводных аналоговых интерфейсов
Q.554 Передающие характеристики цифровых интер- фейсов
Q.700-795 Q.920 Спецификация сигнальной системы N7. Интерфейс пользователя в сети ISDN, общие аспекты связного уровня.
Q.921 Интерфейс пользователя в сети ISDN, специфи- кация связного уровня.
Q.922 Спецификация ISDN связного уровня для па- кетной передачи данных.
Q.930 Интерфейс пользователя в сети ISDN, слой 3, общие принципы.
1058
Приложения
Q.931 Интерфейс пользователя в сети ISDN, специфи- кация слоя 3, базовые процедуры управления.
Q.932 Базовые операции управления дополнительны- ми процедурами в ISDN.
Q.933 Цифровая сигнальная подписная система N1 (DSS1), сигнальные модификации для режима передачи кадров
Т.4 Стандарт на факсимильное оборудование груп- пы 3 для передачи документации.
Т.6 Схемы кодирования изображения и кодирова- ние функций управления для факсимильного оборудования группы 3.
Т.81. Т.411-418 Т.431-433 Кодирование фотографического изображения. Открытая архитектура документации (ODA) Манипуляция документами и протокол переда- чи DTAM.
Т.503 Профайл ВТО для передачи факсимильных документов группы 4.
Т.521 Коммуникационный профайл ВТО для пересыл- ки документов большого объема, базирующейся на методике сессий.
Т.563 Терминальные характеристики факсимильного оборудования группы 4.
V.24 Перечень определений цепей связи DTE и DCE (для DTE, работающих с модемами). Этой специ- фикации соответствуют RS-232-C, RS-449-A.
V.28 Электрические характеристики несимметричных цепей интерфейса, работающего с биполярными токовыми сигналами.-
х.з Спецификация ПАД для общественных сетей (Х.25)
Х.20 DTE-DCE интерфейс старт-стопной передачи данных по сетям общего пользования
Х.21 DTE-DCE интерфейс для синхронной передачи данных по сетям общего пользования. Опреде- ляет физические характеристики и процедуры управления.
Х.21бис Использовайие DTE, рассчитанного на сопряже- ние с синхронными модемами, удовлетворяющи- ми рекомендациям серии V в сетях обмена данными общего пользования
Приложения
1059
Х.22 Мультиплексный интерфейс DTE-DCE для классов обслуживания абонентов 3-6;
Х.24 Перечень определений цепей интерфейса DTE- DCE. Определяет функции цепей передачи данных, управления и синхронизации.
Х.25 Протокол пакетного уровня для интерфейса DTE-DCE и терминалов, подключенных к обще- ственным сетям.
Х.26 Электрические характеристики несимметричных двухполюсных цепей, предназначенных для общего использования в устройствах передачи данных (V.10).
Х.27 Электрические характеристики симметричных цепей, предназначенных для устройств передачи информации с сетях общего пользования (V.11).
Х.28 Интерфейс DTE-DCE для старт-стопного режима работы терминального оборудования, работающе- го в общественных сетях с использованием ПАД.
Х.29 Процедуры обмена управляющей информацией и данными между ПАД и DTE или другим ПАД (пакетный ассемблер-дизассемблер).
Х.31 Поддержка терминального оборудования, рабо- тающего в пакетном режиме (ISDN).
Х.32 Интерфейс DTE-DCE для терминалов, работающих в пакетном режиме и связанных с коммутируе- мой телефонной сетью общего пользования.
Х.75 Терминальные управляющие процедуры и системы передачи данных для международных межсетевых обменов.
Х.121 Схема нумерации для общественных информа- ционных сетей
Х.150 Испытательные шлейфы DTE и DCE для сетей обмена данными общего пользования.
Х.200 Эталонная модель соединения открытых систем для приложений.
Х.208 Х.209 CCITT-версия OSI ASN.1 Версия OSI ASN.1 базовых правил кодирования (BER)
Х.210 Рекомендации по сервису в открытых системах на связном уровне.
Х.211 Физическое определение услуг в OSI для CCITT- приложений
1060
Приложения
Х.212 Определения услуг информационных каналов в OSI для CCITT-приложений
Х.213 Определения сетевых услуг для связей между
Х.214 открытыми системами. Определение транспортных услуг связи откры- тых систем для приложений CCITT.
Х.215 Определение сессий для связанных открытых систем.
Х.216 Описание процедур презентации для связанных открытых систем.
Х.217 Описание процедуры управления для связанных открытых систем.
Х.218 CCITT-эквивалент ISO 9066-1: Надежная пересылка текстов
Х.219 Удаленные операции: модель, нотация и описа- ние услуг.
Х.223 Использование Х.25 для обеспечения сетевой связи в режиме OSI
Х.224 Спецификация транспортного протокола связи открытых систем для приложений CCITT.
Х.225 Спецификация протокола сессий для связанных открытых систем.
Х.226 Протокол презентаций для связанных откры- тых систем.
Х.227 Спецификация протокола управления для связанных открытых систем.
Х.228 Надежная передача данных, спецификация протокола.
Х.229 Х.237 Удаленные операции: спецификация протокола. Определения передачи, одновременности и служб восстановления для связанных открытых систем.
Х.247 Спецификация передачи, одновременности и служб восстановления для связанных откры- тых систем.
Х.400 Система обработки сообщений: системная модель, элементы сервиса.
Х.401 Система обработки сообщений: базовые элемен- ты сервиса и опционные пользовательские возможности.
Х.402 Стандарт для пересылки сообщений
Приложения
1061
Х.403 CCITT-система работы с сообщениями: Провер- ка сохранности
Х.407 Х.408 Абстрактные описания услуг Система обработки сообщений: правила преоб- разования кодированной информации.
Х.409 Система обработки сообщений: синтаксис и нотация презентационных пересылок.
Х.410 Система обработки сообщений: удаленные операции и надежный сервер пересылок.
Х.411 Система обработки сообщений: уровень переда- чи сообщений.
Х.413 Запоминание сообщений: абстрактные опреде- ления услуг
Х.419 Х.420 Спецификации протоколов Система обработки сообщений: уровень обмена сообщениями между пользователями сети.
Х.430 Система обработки сообщений: протокол досту- па для терминалов телетекста.
Х.500 Стандарт на каталоги, базирующийся на OSI (RFC 1279, 1275, 1274)
Х.509 Х.511 Х.519 Х.520 Х.521 Z.100-104 CCITT-каталоги: Система идентификации Абстрактные описания услуг Спецификации протоколов Некоторые типы атрибутов Для определенных классов объектов SDL (Specification and Description Language) язык описания и спецификаций
10G2
Приложения
7.2. Коды протоколов в Ethernet II
Таблица 7.2.1. Коды протоколов в Ethernet II (см. RFC-1700)
Десятичный код Hex Описание
0-05DC Поле длины IEEE 802.3
512 0200 XEROX PUP (PARC Universal Packet)
513 0201 Трансляция адреса для пакетов PUP
1536 0600 XEROX NS IDP
2048 0800 Internet протокол (IPv4)
2049 0801 X.75 Internet
2050 0802 NBS Internet
2051 0803 ECMA Internet
2052 0804 Chaosnet
2053 0805 X.25 уровень 3
2054 0806 Протокол трансляции адреса (ARP)
2055 0807 XNS совместимость
2560 0А00 Xerox IEEE-802.3 PUP
4096 1000 Berkley Trailer
21000 5208 BBN Simnet
24577 6001 DEC MOP Dump/Load
24578 6002 DEC MOP удаленный терминал
24579 6003 DEC DECnet фаза IV
24580 6004 DEC LAT (Local Area Transport)
24582 6005 Диагностический протокол DEC
24583 6006 Протокол пользователя DEC
24586 6010-6014 Корпорация 3Com
28720 7030 Proteon
32773 8005 HP Probe
32776 8008 AT&T
32784- 8010 Excelan
32787 8013 Диагностика SGI
32788 8014 Сетевые игры SGI
32793 8019 Apollo Computers
32821 8035 Реверсивный протокол ARP (RARP)
32824 8038 DEC LANbridge
32829 8O3D Ethernet шифрование DEC _
Приложения
1063
Таблица 7.2.1. (Оклнчание)
Десятичный код Hex Описание
32831 803F Сетевой монитор трафика DEC
32872 8068 General Dynamics
32873 8069 AT&T
32923 809В AppleTalk
33011 80F3 AppleTalk AARP
33072 8130 Heyes Microcomputers
33079 8137-8138 NetWare IPX/SPX
33100 814С SNMP
818D . Motorola Computer
81А5-81АЕ RAD Network Devices
36865 9001 3Com(Bridge) XNS Sys Mgmt (Системное управление XNS)
36866 9002 3Com(Bridge) TCP-1P System
1064
Приложения
7.3. Стандартные мультикастинг-адреса
Интернет
Адрес Зона действия Нормативный документ
224.0.0.0 Базовый адрес мультикастинга (зарезервировано) RFC-1112
224.0.0.1 Все системы этой субсети RFC-IH2
224.0.0.2 Все маршрутизаторы этой субсети
224.0.0.3 Не стандартизовано
224.0.0.4 DVMRP маршрутизаторы RFC-1075
224.0.0.5 Все маршрутизаторы OSPFIGP RFC-1583
224.0.0.6 Заданные маршрутизаторы OSPFIGP RFC-1583
224.0.0.7 Маршрутизаторы ST RFC-1190
224.0.0.8 ЭВМ ST RFC-1190
224.0.0.9 Маршрутизаторы RIP2
224.0.0. Ю Маршрутизаторы IGRP
224.0.0. Н Mobile-Agents
224.0.0.12- 224.0.0.255 Не стандартизовано
224.0.1.0 Группа менеджеров VMTP RFC-1045
224.0. l.l Протокол сетевого времени RFC-1119
224.0.1.2 SGI-Dogfight
224.0.1.3 Rwhod
224.0.1.4 VNP
224.0.1.5 Artificial Horizons - Aviator
224.0.1.6 Сервер имен (NSS)
224.0.1.7 AUDIONEWS - мультикастинг аудио- новостей
224.0.1.8 SUN NIS + Информационная служба
224.0.1.9 Мультикастинг транспортный протокол (МТР)
224.0.1.Ю IETF-1-LOW-AUDIO
224.0.1. II IETF-1-AUDIO
224.0.1.12 IETF-1-VIDEO
224.0.1.13 1ETF-2-LOW-AUD1O
224.0.1.14 IETF-2-AUDIO
224.0. l.l 5 IETF-2-VIDEO
Приложения
1065
Адрес Зона действия Нормативный документ
224.0. l.l 6 MUSIC-SERVICE
224.0.1.17 Телеметрия SEANET
224.0. l.l 8 SEANET-IMAGE
224.0.1.19 MLOADD
224.0.1.20 Любой частный эксперимент
224.0.1.21 DVMRP на MOSPF
224.0.1.22 SVRLOC
224.0.1.23 XINGTV
224.0.1.24 microsoft-ds
224.0.1.25 nbc-pro
224.0.1.26 nbc-pfn
224.0.1.27- 224.0.1.255 He стандартизовано
224.0.2.1 "rwho" Group (BSD) (неофициально)
224.0.2.2 SUN RPC PMAPPROC-CALLIT
224.0.3.000- 224.0.3.255 RFE Generic Service
224.0.4.000- 224.0.4.255 RFE Individual Conferences
224.0.5.000- 224.0.5.127 Группы CDPD
224.0.5.128- 224.0.5.255 He стандартизовано
224.0.6.000- 224.0.6.127 Проект Cornell ISIS
224.0.6.128- 224.0.6.255 He стандартизовано
224.1.0.0- 224.1.255.255 ST Multicast Groups RFC-1190
224.2.0.0- 224.2.255.255 Multimedia Conference Calls
224.252.0.0- 224.255.255.255 DIS transient groups
232.0.0.0- _232.255.255.255 VMTP transient groups RFC-1045
1066
Приложения
7.4. Национальные коды доменов
в Интернет
Обычно завершающий код Internet-имени определяет государ-
ственную принадлежность узла, сервера или ЭВМ (информация взя-
та на сервере RIPE Network Coordination Center (X.500 в ISO 3166)).
Данные упорядочены согласно англоязычным названиям стран.
Страна Английское название Двухбук- венный код Трехбук- венный код Числовой код
Афганистан AFGHANISTAN AF AFG 004
Албания ALBANIA AL ALB 008
Алжир ALGERIA DZ DZA 012
Американское Самоа AMERICAN SAMOA AS ASM 016
Андорра ANDORRA AD AND 020
Ангола ANGOLA AO AGO 024
ANGUILLA Al AIA 660
Антарктика ANTARCTICA AQ ATA 010
Антигуа и Барбуда ANTIGUA AND BARBUDA AG ATG 028
Аргентина ARGENTINA AR ARG 032
Армения ARMENIA AM ARM 051
Аруба ARUBA AW ABW 533
Австралия AUSTRALIA AU AUS 036
Австрия AUSTRIA AT AUT 040
Азербайджан AZERBAIJAN AZ AZE 031
Багамские острова BAHAMAS BS BHS 044
Бахрейн BAHRAIN BH BHR 048
Бангладеш BANGLADESH BD BGD 050
Барбадос BARBADOS BB BRB 052
Беларусь BELARUS BY BLR H2
Бельгия BELGIUM BE BEL 056
Белиз BELIZE BZ BLZ 084
Бенин BENIN BJ BEN 204
Бермудские острова BERMUDA BM BMU 060
Приложения
1067
Страна Английское название Двухбук- венный код Трехбук- венный код Числовой код
Бутан BHUTAN ВТ BTN 064
Боливия BOLIVIA ВО . BOL 068
Босния и Герцеговина BOSNIA AND HERZEGOWINA BA BIH 070
Ботсвана BOTSWANA BW BWA 072
BOUVET ISLAND BV BVT 074
Бразилия BRAZIL BR BRA 076
Британская территория в Индийском океане BRITISH INDIAN OCEAN TERRITORY IO IOT 086
Бруней BRUNEI DARUSSALAM BN BRN 096
Болгария BULGARIA BG BGR 100
Буркина Фасо BURKINA FASO BF BFA 854
Бурунди BURUNDI BI BDI 108
Камбоджа CAMBODIA KH KHM П6
Камерун CAMEROON CM CMR 120
Канада CANADA CA CAN 124
CAPE VERDE CV CPV 132
Каймановы острова CAYMAN ISLANDS KY CYM , 136
Центрально Африканская Республика CENTRAL AFRICAN REPUBLIC CF CAF 140
Чад CHAD TD TCD 148
Чили CHILE CL CHL 152
Китай CHINA CN CHN 156
Остров Рождества CHRISTMAS ISLAND ex CXR 162
Кокосовые острова COCOS (KEELING) ISLANDS cc CCK 166
Колумбия COLOMBIA co COL 170
Каморы COMOROS KM COM 174
Конго CONGO CG COG 178
Острова Кука COOK ISLANDS CK COK 184
Коста-Рика COSTA RICA CR CRI 188
Кот де Вуар COTE D'IVOIRE CI CIV 384
Хорватия CROATIA HR HRV 191
JKy6a CUBA CU CUB 192
J<nnp CYPRUS CY CYP 196
1068
Приложения
Страна Английское название Двухбук- венный код Трехбук- венный код Числовой код
Чешская республика CZECH REPUBLIC cz CZE 203
Дания DENMARK DK DNK 208
Джибути DJIBOUTI DJ DJI 262
Доминика DOMINICA DM DMA 212
Доминиканская республика DOMINICAN REPUBLIC DO DOM 214
Восточный Тимор EAST TIMOR TP TMP 626
Эквадор ECUADOR EC ECU 218
Египет EGYPT EG EGY 818
Сальвадор EL SALVADOR SV SLV 222
Экваториальная Гвинея EQUATORIAL GUINEA GQ GNQ 226
Эритрея ERITREA ER ERI 232
Эстония ESTONIA EE EST 233
Эфиопия ETHIOPIA ET ETH 231
Фолклендские острова FALKLAND ISLANDS FK FLK 238
Острова Фаро FAROE ISLANDS FO FRO 234
Фиджи FIJI FJ FJI 242
Финляндия FINLAND FI FIN 246
Франция FRANCE FR FRA 250
Франция, метрополия FRANCE, METROPOLITA N FX FXX 249
Французская Гвинея FRENCH GUIANA GF GUF 254
Французская Полинезия FRENCH POLYNESIA PF PYF 258
Французские Южные территории FRENCH SOUTHERN TERRITORIES TF ATF 260
Габон GABON GA GAB 266
Гамбия GAMBIA GM GMB 270
Грузия GEORGIA GE GEO 268 __
Германия GERMANY DE DEU 276 __
Гана GHANA GH GHA 288
Г ибралтар GIBRALTAR G1 GIB 292 „
Греция GREECE GR GRC 300 _
Гренландия GREENLAND GL GRL 304 _
Гренада GRENADA GD GRD 308~LJ
Приложения
1069
Страна Английское название Двухбук- венный код Трехбук- венный код Числовой код
Гваделупа GUADELOUPE GP GLP 312
Гуам GUAM GU GUM 316
Гватемала GUATEMALA GT GTM 320
Гвинея GUINEA GN GIN . 324
Гвинея-Биссау GUINEA- BISSAU GW GNB 624
Гайана GUYANA GY GUY 328
Гаити HAITI HT HTI 332
HEARD AND MC DONALD ISLANDS HM HMD 334
Гондурас HONDURAS HN HND 340
Гонконг HONG KONG HK HKG 344
Венгрия HUNGARY HU HUN 348
Исландия ICELAND IS ISL 352
Индия INDIA IN IND 356
Индонезия INDONESIA ID IDN 360
Иран IRAN IR IRN 364
Ирак IRAQ IQ IRQ 368
Ирландия IRELAND IE IRL 372
Израиль ISRAEL IL ISR 376
Италия ITALY IT ITA 380
Ямайка JAMAICA JM JAM 388
Япония JAPAN JP JPN 392
Иордания JORDAN Г jo JOR 400
Казахстан KAZAKHSTAN r KZ KAZ 398
Кения KENYA KE KEN 404
Кирибати KIRIBATI KI KIR 296
КНДР KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF KP PRK 408
Корея KOREA KR KOR 410
Кувейт KUWAIT KW KWT 414
Киргизстан KYRGYZSTAN KG KGZ 417
Лаос LAO PEOPLE'S DEMOCRATIC REPUBLIC LA LAO 418
Латвия LATVIA LV LVA 428
Леван LEBANON LB LBN 422
Лесото LESOTHO LS LSO 426
Либерия Liberia LR LBR 430
Ливия LIBYAN ARAB JAMAHIRIYA LY LBY 434
Л070
Приложения
Страна Английское название Двухбук- венный код Трехбук- венный код Числовой код
Лихтенштейн LIECHTENSTEIN LI LIE 438
Литва LITHUANIA LT LTU 440
Люксембург LUXEMBOURG - LU LUX 442
Макао MACAU MO MAC 446
Македония MACEDONIA, MK MKD 807
Мадагаскар MADAGASCAR MG MDG 450
Малави MALAWI MW MWI 454
Малайзия MALAYSIA MY MYS 458
Мальдивские острова MALDIVES MV MDV 462
Мали MALI ML MLI 466
Мальта MALTA MT MLT 470
Маршалловы острова MARSHALL ISLANDS MH MHL 584
Мартиника MARTINIQUE MQ MTQ 474
Мавритания MAURITANIA MR MRT 478
Маврикий MAURITIUS MU MUS 480
MAYOTTE YT MYT 175
Мексика MEXICO MX MEX 484
Микронезия MICRONESIA FM FSM 583
Молдова MOLDOVA MD MDA 498
Монако MONACO MC MCO 492
Монголия MONGOLIA MN MNG 496
MONTSERRAT MS MSR 500
Марокко MOROCCO MA MAR 504
Мозамбик MOZAMBIQUE MZ MOZ 508
MYANMAR MM MMR 104
Намибия NAMIBIA NA NAM 516
Остров Науру NAURU NR NRU 520
Непал NEPAL NP NPL 524
Нидерланды NETHERLANDS NL NLD 528
Нидерландские Антиллы NETHERLANDS ANTILLES AN ANT 530
Новая Каледония NEW CALEDONIA NC NCL 540
Новая Зеландия NEW ZEALAND NZ NZL 554
Никарагуа NICARAGUA NI NIC 558
Нигер NIGER NE NER 562
Нигерия NIGERIA NG NGA 566
NIUE NU NIU 570
Остров Норфолк NORFOLK ISLAND NF NFK 574
Приложения
1071
Страна Английское название Двухбук- венный код Трехбук- венный код Числовой код
Северные Марианские острова NORTHERN MARIANA ISLANDS MP MNP 580
Норвегия NORWAY NO NOR , 578
Оман OMAN ом OMN 512
Пакистан PAKISTAN PK PAK 586
Ос 1 ров Палау PALAU P\V PLW 585
Панама PANAMA PA PAN 591
Папуа Новая Гвинея PAPUA NEW GUINEA PG PNG 598
Парагвай PARAGUAY PY PRY 600
Перу PERU PE PER 604
Филиппины PHILIPPINES PH PHL 608
Остров Питкэрн PITCAIRN PN PCN 612
Польша POLAND PL POL 616
Португалия PORTUGAL PT PRT 620
Пуэрто-Рико PUERTO RICO PR PRI 630
Катар QATAR QA QAT 634
Реюньон REUNION RE REU 638
Румыния ROMANIA RO ROM 642
Россия RUSSIAN FEDERATION RU RUS 643
Руанда RWANDA RW RWA 646 _
Сант Китс и Невис SAINT KITTS AND NEVIS KN KNA 659
Сент-Люсия SAINT LUCIA LC LCA __662
Сент-Винсент и Гренадины SAINT VINCENT AND THE GRENADINES VC VCT 670
Самоа SAMOA WS wsm _ ;
Сан-Марино SAN MARINO ,SM SMR _ 674
Сан Томе и Принсипи SAO TOME AND PRINCIPE ST STP 678
Саудовская Аравия SAUDI ARABIA SA SAU I 682
Сенегал SENEGAL_ ! SN SIN 686 __
Сейшельские острова SEYCHELLES S( 1 SY( 690 ~
Сиерра-Леоне SIERRA I E( )NI SI ‘ SLI 694
Сингапур SINGAPORE SG . ‘ SGP 7O2__
Словакия SLOVAKIA SK SVK ' 703 ~
Словения Jlovenix SI S\ N ‘ 705
1072
Приложения
Страна Английское название Двухбук- венный код Трехбук- венный код Числовой код
Соломоновы острова SOLOMON ISLANDS SB SLB 090
Сомали SOMALIA . SO SOM 706
Южная Африка SOUTH AFRICA ZA ZAF 710
Южная Георгия и Южные Сэндвичевы острова SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS GS SGS 239
Испания SPAIN ES ESP 724
Шри-Ланка SRI LANKA LK LKA 144
Св. Елена ST. HELENA SH SHN 654
Сен-Пьер и Микелон ST. PIERRE AND MIQUELON PM SPM 666
Судан SUDAN SD SDN 736
Суринам SURINAME SR SUR 740
Острова Свалбард и Ян-Майена SVALBARD AND JAN MAYEN ISLANDS SJ SJM 744
Свазиленд SWAZILAND SZ swz 748
Швеция SWEDEN SE SWE 752
Швейцария SWITZERLAND CH CHE 756
Сирия SYRIAN ARAB REPUBLIC SY SYR 760
Тайвань TAIWAN, PROVINCE OF CHINA TW TWN 158
Таджикистан TAJIKISTAN TJ TJK 762
Танзания TANZANIA 1 TZ TZA ] 834
Таиланд THAILAND TH THA 764
Того TOGO TG TGO 768
Острова Токелау TOKELAU TK TKL 772
Тонга TONGA TO TON 776
Тринидад и Тобаго TRINIDAD AND TOBAGO TT TTO 780
Тунис TUNISIA TN TUN 788
Турция TURKEY TR TUR 792
Туркменистан TURKMENISTAN TM TKM 795
TURKS AND CAICOS ISLANDS TC TCA 796
Приложения
1073
Страна Английское название Двухбук- венный код Трехбук- венный код Числовой код
Тувалу TUVALU TV TUV 798
Уганда UGANDA UG UGA 800
Украина UKRAINE UA UKR 804
Объединенные арабские Эмираты UNITED ARAB EMIRATES AE ARE 784
Велико- британия UNITED KINGDOM GB GBR 826
Соединенные Штаты UNITED STATES US USA 840
UNITED STATES MINOR OUTLYING ISLANDS UM UMI 581
Уругвай URUGUAY UY URY 858
Узбекистан UZBEKISTAN UZ UZB 860
Вануату VANUATU vu VUT 548
Ватикан VATICAN CITY STATE(HOLY SEE) • VA VAT 336
Венесуэла VENEZUELA VE VEN 862
Вьетнам VIET NAM VN VNM 704
Виргинские острова (ВБ) VIRGIN ISLANDS (BRITISH) VG VGB 092
Виргинские острова (США) VIRGIN ISLANDS (U.S.) VI VIR 850
Острова Эллис и Футуна WALLIS AND FUTUNA ISLANDS WF WLF 876
Западная Сахара WESTERN SAHARA EH ESH 732
Йемен YEMEN YE YEM 887
Югославия YUGOSLAVIA YU YUG 891
Заир ZAIRE ZR ZAR 180
Замбия ZAMBIA ZM ZMB 894
Зимбабве ZIMBABWE zw ZWE 716
35 Зак. № 3430 Семенов
1074
Приложения
7.5. Список кодов и откликов на почтовые
команды и сообщения
211 Сообщение о состоянии системы или справочный отклик
(help).
214 Help message — сообщение для сведения. [Информация о
том, как использовать приемник или значение конкретной
нестандартной команды; этот отклик полезен только для
пользователей-людей].
220 <domain> Service ready — сервер готов к обслуживанию.
221 <domain> Service closing transmission channel — сервер
закрывает канал;
250 Requested mail action okay, completed — процедура успешно
завершена;
251 User not local; will forward to <forward-path> — адресат не
местный, сообщение ему будет переадресовано.
354 Start mail input; end with <CRLF>.<CRLF> — начало ввода
сообщения, завершение симв'ольной последовательностью
<CRLF>.<CRLF>.
421 <domain> Service not available, closing transmission channel
— услуга не доступна, процедура прерывается. [Это может
быть ответом на любую команду, если сервер знает, что он
должен прервать обслуживание]
450 Requested mail action not taken: mailbox unavailable —
запрошенная процедура не выполнена [Напр., из-за отсут-
ствия доступа к почтовому ящику].
451 Requested action aborted: error in processing - выполнение
процедуры прервано из-за ошибки.
452 Requested action not taken: insufficient system storage —
операция не выполнена из-за недостатка системной памяти.
500 Syntax error, синтаксическая ошибка. [Среди прочего, это
может указывать на то, что командная строка имеет слиш-
ком большую длину].
Приложения
1075
501 Syntax error in parameters or arguments - синтаксическая ошибка в параметрах или аргументах.
502 503 Command not implemented — нелегальная команда. Bad sequence of commands — неудачная последовательность команд.
504 Command parameter not implemented — ошибка в парамет- рах команды.
550 Requested action not taken: mailbox unavailable — Запро- шенная операция не выполнена [Напр., почтовый ящик не найден или доступ к нему невозможен].
551 User not local; please try <forward-path> — адресат не местный, рекомендуется переадресовать сообщение по адресу <f orward-path>.
552 Requested mail action aborted: exceeded storage allocation — операция прервана из-за превышения лимитов памяти (слиш- ком много адресатов или слишком длинное сообщение).
553 Requested action not taken: mailbox name not allowed — операция не выполнена [Например, ошибка в записи адреса почтового ящика].
554 Transaction failed — процедура не выполнена.
1076
Приложения
7.6. Принципы формирования кода
отклика в системе SMTP
Любой код отклика содержит три цифры. Первая цифра говорит *
о том, является ли отклик положительным, отрицательным или
промежуточным. Отправитель, проанализировав первую цифру, мо-
жет решить, продолжать выполнение задачи, повторить последнюю
операцию или отказаться от своей затеи. Для уточнения типа ошибки
отправитель может проанализировать вторую цифру, последняя цифра
уточняет диагноз.
lyz Промежуточный позитивный отклик. Команда воспринята.
Отправитель должен послать следующую команду
2yz Позитивное подтверждение завершения операции. Можно
посылать следующий запрос.
3yz Позитивный промежуточный отклик, сходный с lyz, ис-
пользуется в случае групповых команд.
4yz Временный регативный отклик. Команда не исполнена, но
характер ошибки временный и выполнение процедуры
может быть позже повторено.
5yz Окончательный негативный отклик. Команда не восприня-
та, запрошенная операция не выполнена и не будет выпол-
нена.
Вторая цифра кода может иметь следующие значения:
xOz Синтаксис — эти отклики относятся к синтаксическим
ошибкам или к командам синтаксически корректным но
примененным неправильно.
xlz Информация — относится к командам, которые запрашива-
ют информацию, например, статусную или справочную.
x2z Соединения относится к телекоммуникационному каналу.
x3z Пока не определен.
x4z Пока не определен.
x5z Почтовая система эти отклики индицируют статус получа-
теля или отправителя почты.
Третья цифра уточняет смысл второй.
Приложения
1077
7.7. Базовые протоколы Internet
Протокол Описание RFC
ARP Address Resolution Protocol 826
В FTP Background File Transfer Protocol 1068
BGP Border Gateway Protocol (внешний протокол маршрутизации) 1105,1265-68, 1397, 1654-56
ВООТР Bootstrap Protocol (протокол загрузки) 951,1048,1084
CIDR Classless Inter-Domain Routing protocol 1519,1520
CLNP ConnectionLess Network Protocol (ISO-8474) 1526,1561,1575
CLOCK DCNET Time Server Protocol 778
смот Common Management Information Service and Protocol over TCP/IP 1095
DHCP Dynamic Host Configuration Protocol (динамический протокол конфигури- рования ЭВМ) 2131
DNS Domain Name Service (система распознавания имен доменов) 1713, 1712, 1612, 1611, 1383
DOMAIN Domain Name System (DNS) 1034, 1035, 1032, 974
DVMRP Distance Vector Multicast Routing Protocol 1075
ECHO Эхо протокол 862
EGP Exterior Gateway Protocol 904,911, 1092, 1093
FINGER Finger-протокол 1288,724
FTP File Transfer Protocol (протокол пересылки файлов) 959
HEMP High level Entity Management Protocol 1022
HEMS High level Entity Management System 1021
HMP Host Monitoring Protocol 869
GGP Gateway to Gateway Protocol 823
ICMP Internet Control Message Protocol 792,1256
IDRP Inter-Domain Routing Protocol 1477,1479
IGMP Internet Group Multicast Protocol 1112
IGP Interior Gateway Protocol 1074,1371
IMAP Internet Massage Access Protocol 2359, 2342, 2221. 2195,2193.2182, 2180,2177, 2060
1078
Приложения
Протокол Описание RFC
IP Internet протокол 791
IP субсети 950
IP широковещательные дейтограммы f 919
то же для субсетей 922
IP-ARC Internet протокол для Arcnet 1051
IP-E Internet протокол для Ethernet 895
IP-FDDI Передача IP через FDDI 1103
IP-SLIP Передача IP по последовательным линиям 1055
IPM Internet-протокол для сообщений 759
IRC Internet Relay Chat 1459
1S-IS OSI-междоменный протокол маршрутизации 1195,1142
MAIL Формат сообщений электронной почты 822, 821, 1351, 1352
MIB-II Management Information Base-II 1213
MIME Multipurpose Internet Mail Extensions 2652, 2634, 2633, 2632, 2557, 2480, 2426, 2425, 2424, 2423. 2422, 2387, 2302, 2231,2116,2159, 2156,2110, 2049, 2047, 2046, 2045, 2017, 2015, 1848, 1847, 1767, 1652, 1521, 1522, 1496
NETBIOS NetBIOS Service Protocols 1001, 1002
NETRJE Network Remote Job Entry Program 740,725
NETRJS Network Remote Job Service 477, 436
NFS Network File System (файловая система) 1094
NNTP Network News Transfer Protocol 977 1
NTP Network Time Protocol 1708, 1165, 1119, 1128- 29
NUMBERS Assigned Numbers 1700
OSPF Open Shortest Pass First Protocol (маршрутный протокол «кратчайший путь лучше») 2740, 2370, 2328, 1850, 1793, 1745, 1583-87, 1370, 1253, 1245-48, 1131
PCMAIL Pcmail Transport Protocol 1056
POP Post Office Protocol 2595, 2449, 1734, 1460, 1081, 1082, 937
RAP Router-Access Protocol 1476
Приложения
1079
Протокол Описание RFC
РРР Point-to-Point Protocol 2716, 2701,2688, 2687, 2686, 2516, 2509, 2508, 2507,2484,2472,2433, 2420, 2419, 2364, 2363, 2290, 2284, 2153, 2125, 2097, 2043, 1994, 1993, 1990, 1989, 1979, 1978, 1977, 1976, 1975, 1974, 1973, 1969, 1968, 1967, 1963, 1962, 1915, 1877, 1841, 1764, 1763, 1762, 1663, 1662, 1661, 1638, 1619, 1618, 1598, 1570, 1552, 1378, 1377, 1334, 1332,
RADIUS Remote Authentication Dial In User Service 2620,2619,2618,2139, 2138
RARP Reverse Address Resolution Protocol 903
RDP Reliable Data Protocol 908
RIP Routing Information Protocol (внутренний протокол маршрутизации) 1582, 1581, 1389, 1387, 1388, 1058
RLP Resource Location Protocol 887
RPC Remote Procedure Call Protocol 1057, 1050
SFTP Simple File Transfer Protocol 913
SLIP Serial Line IP (Интернет по послед, линии) 1055
SMI Structure of Management Information 1155
SMTP Simple Mail Transfer Protocol SMTP 2645, 2554, 2487, 2197, 2034, 1985,1891, 1870, 1869, 1652, 1090, 821
SNMP Simple Network Management Protocol SNMP 2575, 2574, 2573, 2572, 2571,2013,2012,2011, 1908, 1907, 1906, 1905, 1442, 1420, 1419, 1418, 1382,1157
SNTP Simple Network Time Protocol 2030
TCP Transmission Control Protocol 2881,2385,2147,2018, 1323, 1213, 1195, 1155, 1144, 1146, 793
1080
Приложения
Протокол Описание RFC
TELNET Протокол удаленного доступа 854, 856-861, 885, 927, 933, 946, 1041, 1043, 1053, 1073, 1079, 1093, 1096, 1097, 1143, 1184, 1205, 1372, 1411, 1412, 1416, 1571, 1572, 2066
TFTP Trivial File Transfer Protocol 2349, 2348, 2347, 1782, 1350
UDP User Datagram Protocol 2147, 768
USERS Протокол активных пользователей 866
UUCP Электронная почта под UNIX 976
VFIP Voice File Interchange Protocol 978
VMTP Versatile Message Transfer Protocol 1045
XDR External Data Representation 1014
X-Windows Системный протокол X-Windows "1198, 1013
Приложения
1081
7.8. Символьный набор HTML
Символьный набор документов HTML, заданный «SGML Declaration
for HTML». Этот набор базируется на документе [ISO-8859-1].
Кодовое представление . Символ Описание
� -  Не используется
	 Символ горизонтальной табуляции

 Перевод строки
Возврат каретки
 -  Не используется
  Пробел
! ! Восклицательный знак
" и Кавычки
# Знак числа ()
$ $ Знак доллара
% % Знак процента
& & Ampersand
' • Апостроф
( ( Левая скобка
) ) Правая скобка
* * Звездочка
+ + Знак плюс (
, запятая
- - Дефис
. Точка(полная остановка)
/ / Косая черта (slash)
0 - 9 0-9 Цифры 0-9
: Двоеточие
; Точка с запятой
< < Знак меньше чем
= = Знак равенства
> > Знак больше чем
? ? Знак вопроса
@ @ Символ @
A - Z A-Z Буквы A-Z
1082
Приложения
Кодовое представление Символ Описание
[ [ Левая квадратная скобка
\ \ Обратная косая черта (backslash)
] ] Правая квадратная скобка
^ Л Знак вставки (Л caret)
_ Горизонтальная черта (underscore)
` Ударение
a - z a-z Буквы a-z
{ { Левая фигурная скобка
| | Вертикальная черта
} } Правая фигурная скобка
~ Тильда (~)
 - Ÿ Не используется
  Неразрывный пробел
¡ i Инвертированный восклицательный знак
¢ Знак центов
£ • £ Знак фунтов стерлингов
¤ п Обобщенный знак валюты
¥ ¥ Знак иены
¦ ! Разорванный знак вертикальной черты
§ § Знак раздела (Section sign)
¨ J <. Умляут (горизонтальное двоеточие над буквой)
© Знак авторского права (Copyright)
ª а Feminine ordinal
« « Левая угловая кавычка (guillemotleft)
¬ ~1 Знак отрицания (Not sign)
­ - Мягкий дефис (Soft hyphen)
® ®' Зарегистрированная торговая марка
¯ - Macron accent
° о Знак градуса (Degree sign)
± ± Знак плюс или минус (± )
² 2 Верхний индекс 2 (Superscript two)
³ 3 Верхний индекс 3 (Superscript three)
´ Знак ударения (Acute accent)
µ д Знак долготы над гласным (горизонтальная Аерта - Micro sign)
¶ I Знак параграфа
· Центральная точка
¸ Орфографический знак седиль (Cedilla)
¹ 1 Верхний индекс 1 (Superscript one)
º о Masculine ordinal
» » Правая угловая кавычка (guillemotright)
¼ Ул Дробь %
Приложения
1083
Кодовое представление Символ Описание
½ '/2 Дробь У2
¾ 3/д Дробь 3Л
¿ Л Инвертированный знак вопроса
À А Прописное A, grave accent
Á А Прописное A, acute accent
 А Прописное A, circumflex accent
à А Прописное A, tilde
Ä А Прописное A, dieresis or umlaut mark
Å А Прописное A, ring
Æ Я, Прописное AE dipthong (ligature)
Ç 9 Прописное C, cedilla
È Е Прописное E, grave accent
É Ё Прописное E, acute accent
Ê Ё Прописное E, circumflex accent
Ë Ё Прописное E, dieresis or umlaut mark
Ì I Прописное I, grave accent
Í I Прописное I, acute accent
Î I Прописное L circumflex accent
Ï I Прописное I, dieresis or umlaut mark
Ð D Прописное Eth, исландское
Ñ N Прописное N, tilde
Ò 0 Прописное О, grave accent
Ó 0 Прописное 0, acute accent
Ô О Прописное О, circumflex accent
Õ О Прописное О, tilde
Ö О Прописное О, dieresis or umlaut mark
× X Знак умножения
Ø 0 Прописное 0, slash
Ù: и Прописное U, grave accent
Ú С Прописное U, acute accent
Û и Прописное U, circumflex accent
Ü и Прописное U, dieresis or umlaut mark
Ý Y Прописное Y, acute accent
Þ 1> Прописное THORN, Icelandic
&W223; В Строчное sharp B, German (sz ligature)
à а Строчное a, grave accent
á а Строчное a, acute accent'
â а Строчное a, circumflex accent
ã а Строчное a, tilde
ä а Строчное a, dieresis or umlaut mark
å § Строчное a, ring
æ ж Строчный дифтонг ae (ligature)
ç £_ Строчное c, cedilla
1084
Приложения
Кодовое представление Символ Описание
è e Строчное e, grave accent
é e Строчное e, acute accent '
ê e Строчное e, circumflex accent
ë: ё Строчное e, dieresis or umlaut mark
ì: i Строчное i, grave accent
í i Строчное i, acute accent
î i Строчное i, circumflex accent
ï i Строчное i, dieresis or umlaut mark
ð Строчное eth, Icelandic
ñ n Строчное n, tilde
ò 0 Строчное о, grave accent
ó 0 Строчное о, acute accent
ô 0 Строчное о, circumflex accent
õ 6 Строчное о, tilde
,ö 6 Строчное о, dieresis or umlaut mark
÷ 4- Строчное ion sign
ø: 0 Строчное о, slash
ù u Строчное u, grave accent
ú й Строчное u, acute accent
û li Строчное u, circumflex accent
ü u Строчное u, dieresis or umlaut mark
ý . У Строчное у. acuie accent
þ l> Строчное thorn, исландское
ÿ: У Строчное у с умляутом (dieresis or umlaut mark)
<!— Набор символьных объектов. Типичное обращение:
<!ENTITY % HTMLlatl PUBLIC «-//W3C//ENTITIES Latin 1//
EN//HTML»>
% HTMLlatl ;—>
Описание Название символа Уникод Название набора
<!ENT1TY nbsp CDATA ” ” > Неразрывный пробел U+OOAO ISOnum
c’ENTITY iexcl CDATA ”¡> Инвертированный ! U+00A1 ISOnum
<!ENTITY cent CDATA ”¢” > Знак цента U+00A2 ISOnum
c!ENT!TY pound CDATA ”£" > Знак фунта U+00A3 ISOnum
<!ENTITY cunen CDATA "&#I64;" > Знак валюты U+00A4 ISOnum
c’ENTITY yen CD \TA Знак иены U+00A5 ISOnum
c’ENTITY brvbar CDATA ”¦” > Разорванная вертикаль- ная черта U+00A6 ISOnum
cIENTITY sect CDATA ”§:" > Знак секции U+00A7 ISOnum
cIENTITY uml CDATA ”¨” > Диэреза = двоеточие над гласной U+00A8 ISOdia
cIENTITY copy CDATA "&# 169;” > Знак авторского права U+00A9 ISOnum
Приложения
1085
Описание Название символа Уникод Название набора
<!ENTITY ordf CDATA "ª” > Указатель женского на- чала U+00AA ISOnum
<!ENTITY laquo CDATA ”«" > Левая двойная угловая кавычка U+00AB ISOnum
<!ENTFTY not CDATA «&# 172;» > Знак отрицания U+00AC ISOnum
clENTITY shy CDATA «&# 173;» > Мягкий дефис U+00AD ISOnum
clENTITY reg CDATA «&#! 74;»> Знак зарегистрированной торговой марки U+00AE ISOnum
<!ENTITY macr CDATA «&#! 75;» > Знак долготы над глас- ным = черта над U+00AF ISOdia
clENTITY deg CDATA «&#! 76;» > Знак градуса и+оово ISOnum
clENTITY plusmn CDATA «±»> Знак плюс-минус U+00B1 ISOnum
clENTITY sup2 CDATA «&# 178;» > 2 в верхнем индексе = знак квадрата U+00B2 ISOnum
clENTITY\sup3 CDATA «&# 179;» > 3 в верхнем индексе = знак куба U+00B3 ISOnum
clENTITY acute CDATA «&#! 80;» > Резкое ударение U+00B4 ISOdia
clENTITY micro CDATA «µ» > Знак микро U+00B5 ISOnum
clENTITY a CDATA «&# 182;» > Знак параграфа U+00B6 ISOnum
clENTTTY middot CDATA «·» > Центральная точка U+00B7 ISOnum
clENTITY cedi! CDATA «&#! 84;» > Седиль U+00B8 ISOdia
clENTITY sup 1 CDATA «&# 185;» > 1 в верхнем индексе U+00B9 ISOnum
<!ENTIT Y ordm CDATA «&# 186;» > Индикатор мужского на- чала U+00BA ISOnum
clENTITY raquo CDATA «&# 187;» > Правая двойная угловая кавычка и+оовв ISOnum
clENTITY frac!4 CDATA «&# 188;» > Символ 1/4 и+оовс ISOnum
clENTITY frac 12 CDATA «&# 189;» > Символ 1/2 U+00BD ISOnum
<!ENTITY frac34 CDATA «¾» > Символ 3/4 U+00BE ISOnum
<!ENTITY iquest CDATA «¿» > Перевернутый знак во- проса U+00BF ISOnum
clENlTTY Agrave CDATA «&# 192;» > Латинская прописная буква А с глухим ударением и+оосо ISOlatl
clENTITY Aacute CDATA «&#! 93;» > Латинская прописная бу- ква А с ударением U+00C1 ISOlatl
clENTTTY Aciic CDATA «&# 194;» > Латинская прописная буква А центральным ударением U+00C2 ISOlatl
clENTITY Atilde CDATA «&# 195;» > Латинская прописная буква А с тильдой и+оосз ISOlatl
clENTITY Auml CDATA «&# 196;» > Латинская прописная бу- ква А с умляутом, (ди- эрезой) U+00C4 ISOlatl
clENTITY Aring CDATA «&# 197;» > Латинская прописная буква А с кружочком сверху U+00C5 ISOlatl
clENTITY Aelig CDATA «&# 198;» > Латинская прописная бу- ква АЕ U+00C6 ISOlatl
clENTITY Ccedil CDATA «&# 199;» > Латинская прописная буква С С ССДИЛЬЮ U+00C7 ISOlatl
1086
Приложения
Описание Название символа Уникод Название набора
<!ENTITY Egrave CDATA «È» > Латинская прописная буква Е с глухим ударением U+00C8 ISOlatl
<!ENTITY Eacute CDATA «l;» > Латинская прописная буква Е с ударением U+00C9 ISOlatl
<!ENTTTY Ecirc CDATA «Ê» Латинская прописная бу- ква Е с циркумфлексом U+00CA ISOlatl
<!ENTITY Euml CDATA «Ë» > Латинская прописная буква Е с диэрезой и+оосв ISOlatl
<!ENTITY Igrave CDATA «Ì» > Латинская прописная бу- ква I с глухим ударением и+оосс ISOlatl
<!ENT1TY lacute CDATA «Í» > Латинская прописная буква 1с ударением U+00CD ISOlatl
<!ENTITY Icirc CDATA «Î» > Латинская прописная бу- ква I с циркумфлексом сверху U+00CE ISOlatl
<!ENTTTY luml CDATA «O7;» > Латинская прописная буква I с диэрезой (умляутом) U+00CF ISOlatl
<!ENTITY ETH CDATA «Ð» > Латинская прописная бу- ква ЕТН U+00D0 ISOlatl
<!ENTITY Ntilde CDATA «Ñ» > Латинская прописная буква N с тильдой U+00D1 ISOlatl
<!ENTITY Ograve CDATA «l0;» > Латинская прописная бу- ква О с тупым ударением U+00D2 ISOlatl
<!ENTITY Oacute CDATA «Ó» > Латинская прописная бу- ква О с ударением U+00D3 ISOlatl
<!ENTTTY Ocirc CDATA «Ô» > Латинская прописная буква О с кружочком сверху U+00D4 ISOlatl
<!ENTITY Otilde CDATA «Õ» > Латинская прописная буква О с тильдой U+00D5 ISOlatl
<!ENTITY Ouml CDATA «Ö» > Латинская прописная буква О с диэрезой (умляутом) U+00D6 ISOlatl
<!ENTTTY times CDATA «×» > Знак умножения U+00D7 ISOnum
<!ENTITY Oslash CDATA «Ø» > Латинская прописная буква О с косой чертой U+00D8 ISOlatl
<!ENTITY Ugrave CDATA «Ù» > Латинская прописная буква U с глухим ударением U+00D9 ISOlatl
<!ENTITY Uacute CDATA «Ú» > Латинская прописная буква U с ударением U+00DA ISOlatl
<!ENTITY Udrc CDATA «Û» > Латинская прописная бу- ква U с циркумфлексом сверху U+00DB ISOlatl
<!ENTITY Uuml CDATA «Ü» > Латинская прописная буква U с тремой (умляутом) U+00DC ISOlatl
<!ENTITY Yacute CDATA «l;» > Латинская прописная буква Y с ударением U+00DD ISOlatl
<!ENTlTY THORN CDATA «Þ>> > Латинская прописная бу- ква THORN U+00DE ISOlatl
c’ENTITY szlig CDATA «ß» > Латинская строчная буква sharp s = ess-zed U+00DF ISOlatl
Приложения
1087
Описание Название символа Уникод Название набора
<!ENTITY agrave CDATA «à» > Латинская строчная оук- ва а с глухим ударением U+00E0 ISOlat 1
<’ENTITY aacute CDATA «á» > Латинская строчная бук- ва а с ударением U+00E1 ISOlat 1
<!ENTITY acirc CDATA ”â"> Латинская строчная бук- ва а с кружочком сверху U+00E2 ISOlat I
cIENTITY atilde CDATA "ã"> Латинская строчная бук- ва а с тильдой U+00E3 ISOlat 1
<!ENTITYauml CDATA ”ä"> Латинская строчная бук- ва а с тремой (умляутом) U+00E4 ISOiatT-
<!ENTITY aring CDATA "å”> Латинская строчная бук- ва а с кружочком сверху U+00E5 ISOlat 1
<!ENTTTY aclig CDATA ”æ"> Латинская строчная буква ае = латинская строчная лигатура ае U+00E6 ISOlat I
<!ENTITY ccedil CDATA "ç ;"> Латинская строчная бук- ва с с седилью U+00E7 ISOlat 1
<!ENTTTY egrave CDATA ”è”> Латинская строчная бук- ва е с глухим ударением U+00E8 ISOlat 1
<!ENTITY eacute CDATA "é”> Латинская строчная бук- ва е с ударением U+00E9 ISOlat 1
cIENTITY ecirc CDATA "ê"> Латинская строчная бук- ва е с циркумфлексом сверху U+00EA ISOlat Г"
<!ENTITY cum! CDATA ”ë"> Латинская строчная бук- ва е с тремой (умляутов)* U+00EB ISOlat Г~
cIENTITY igrave CDATA "ì"> Латинская строчная бук- ва i с глухим ударением U+00EC ISOlat I'"
cIENTITY iacute CDATA "í”> Латинская строчная бук- ва i с ударением U+00ED ISOlat e
<!ENTITY icirc CDATA "î"> Латинская строчная бук- ва i с циркумфлексом сверху U+00EE ISOlat Г"
<!ENTITY iuml CDATA "ï"> Латинская строчная бук- ва i с тремой (умляутом) U+OOEF ISOlat e
<!ENTTTY eth CDATA ”ð Латинская строчная бук- ва eth U+00F0 ISOlate
<!ENTITY ntilde CDATA "l;”> Латинская строчная бук- ва п с тильдой U+00F1 ISOlatl'
<!ENTITY ograve CDATA "ò”> Латинская строчная бук- ва о с глухим ударением U+00F2 ISOlate
cIENTITY oacute CDATA ”ó"> Латинская строчная бук- ва о с ударением U+00F3 ISOlatl^
cIENTITY ocirc CDATA ”ô"> Латинская строчная бук- ва о с циркумфлексом сверху U+00F4 ISOlatl '
cIENTITY otilde CDATA ”õ"> Латинская строчная бук- ва о с тильдой U+00F5 ISOlatl^
1088
Приложения
Описание Название символа Уникод Название набора
<!ENTTTY ouml CDATA ”ö”> Латинская строчная бук- ва о с тремой (умляутом) U+00F6 ISOlatl
<!ENTTTY divide CDATA "÷"> Знак деления U+00F7 ISOnum
<!ENTTTY oslash CDATA ”ø”> Латинская строчная буква о с косой чертой U+OOF8 ISOlatl
<!ENTITY ugrave CDATA ”ù”> Латинская строчная бук- ва и с глухим ударением U+00F9 ISOlatl
<!ENTITY uacute CDATA ”ú’’> Латинская строчная бук- ва и с ударением U+00FA ISOlatl
<!ENTITY ucirc CDATA ”û ;”> Латинская строчная бук- ва и с циркумфлексом сверху U+00FB ISOlatl
<!ENTITY uuml CDATA ”ü”> Латинская строчная бук- ва и с тремой (умляутом) U+00FC ISOlatl
<!ENTTTY yacute CDATA ”ý”> Латинская строчная бук- ва у с ударением U+00FD ISOlatl
<!ENTITY thorn CDATA "þ”> Латинская строчная бук- ва thorn U+00FE ISOlatl
<!ENTITY yum! CDATA ”ÿ”> Латинская строчная бук- ва у с тремой (умляутом) U+00FF ISOlatl
Эталонные символьные объекты для символов,
математических символов и греческих букв
Эталонные символьные объекты в этом разделе производят сим-
волы, которые могут быть представлены глифами из широко извес-
тного шрифта Adobe Symbol, включая греческие буквы, различные
скобки, а также секцией математических операторов (+ . — и т.д.).
Чтобы поддержать эти объекты агенты пользователя могут под-
держивать целиком ISO10646 или использовать другие средства.
Отображение глифов для этих символов может быть реализовано
через отображение соответствующих символов ISO10646 или други-
ми способами, такими как установление внутреннего соответствия
кодов символов и порядковых номеров символов в заданном шриф-
товом наборе.
Использование греческих символов. Этот символьный набор со-
держит все буквы, используемые в современном греческом алфави-
те. Однако, он не включает в себя греческую пунктуацию, символы
со знаками ударения или безпробельные акценты (tonos, dialytika),
необходимые для их формирования, Здесь нет архаичных букв, уни-
кальных коптских букв или комбинированных букв политоничес-
кого греческого языка. Определенные здесь объекты предназначены
не для представления современного греческого текста, а для приме-
нения в технических математических текстах.
Приложения
1089
Список символов
<!— Математические, греческие и другие символы HTML —>
<!— Character entity set. Typical invocation:
clENTITY % HTMLsymbol PUBLIC
»-//W3C//ENTITIES Symbols//EN//HTML»>
% HTMLsymbol; —>
<!— Ниже приводится набор соответствующих объектов ISO, если
не введены новые имена. Новые имена (напр., не из списка ISO
8879) не противоречат другим существующим именам объектов
ISO 8879. Коды символов ISO 10646 даны для каждого символа в
шестнадцатеричной нотации. Значения CDATA приведены в деся-
тичном виде ISO 10646 и относятся к символьному набору доку-
i мента. Имена соответствуют Unicode 2.0. —>
Греческие символы (ISOgrk3)
Определение Название символа Уникод
<!ЕЬПТГУ Alpha CDATA ”Α”> Греческая прописная альфа (А) U+0391
clENTITY Beta CDATA ”Β”> Греческая прописная бета (В) U+0392
clENTITY Gamma CDATA "Γ"> Греческая прописная гамма (Г) U+0393
clENTITY Delta CDATA "Δ"> Греческая прописная дельта (А) U+0394
clENTITY Epsilon CDATA Греческая прописная эпсилон (Е) U+0395
clENTITY Zeta CDATA ”Ζ’’> Греческая прописная зета (Z) U+0396
clENTITY Eta CDATA ”Η”> Греческая прописная эта (Н) U+0397
clENTITY Theta CDATA ”Θ”> Греческая прописная тэта (0) U+0398
clENTITY Iota CDATA ”Ι"> Греческая прописная йота (I) U+0399
clENTITY Kappa CDATA "Κ"> Греческая прописная каппа (К) U+039A
clENTITY Lambda CDATA "Λ"> Греческая прописная лямбда (Л) U+039B
clENTITY Mu CDATA "Μ"> Греческая прописная мю (М) U+039C
clENTITY Nu CDATA "Ν"> Греческая прописная ню (N) U+039D
clENTITY Xi CDATA ”Ξ’’> Греческая прописная кси (Н) U+039E
clENTITY Omicron CDATA ”Ο"> Греческая прописная омикрон (О) U+039F
<!ENT1TY И CDATA "Π"> Греческая прописная пи (П) U+03A0
clENTITY Rho CDATA ”Ρ”> Греческая прописная ро (Р) U+03A1
clENTITY Sigma CDATA ”Σ ;">*) Греческая прописная сигма (S) U+03A3
clENTITY Tau CDATA ”Τ”> Греческая прописная тау (Т) U+03A4
clENTITY Upsilon CDATA ”Υ”> Греческая прописная ипсилон (Y) U+03A5
clENTITY Phi CDATA ”Φ”> Греческая прописная фи (Ф) U+03A6
clENTITY Chi CDATA "Χ"> Греческая прописная хи (X) U+03A7
clENTITY Psi CDATA "Ψ"> Греческая прописная пси fP) U+03A8
clENTITY Omega CDATA ”Ω’’> Греческая прописная омега (Q) U+03A9
clENTITY alpha CDATA "α"> Греческая строчная альфа (а) U+03B1
clENTITY beta CDATA "β"> Греческая строчная бега (р) U+03B2
clENTITY gamma CDATA ”γ”> Греческая строчная гамма (у) U+O3B3
clENTITY delta CDATA ”δ”> Греческая строчная дельта (5) U+03B4
clENTITY epsilon CDATA ”ε"> Греческая строчная эпислон (е) U+03B5
1090
Приложения
Греческие символы (ISOgrk3)
Определение Название символа Уникод
cIENTITY zeta CDATA ”ζ"> Греческая строчная зета © U+03B6
cIENTITY eta CDATA ”η ;”> Греческая строчная эта (Г|) U+03B7
c’ENTTTY theta CDATA "θ"> Греческая строчная тега (0) U+03B8
cIENTITY iota CDATA ”ι”> Греческая строчная йота (t) U+03B9
cIENTITY kappa CDATA ”κ"> Греческая строчная каппа (к) U+03BA
cIENTITY lambda CDATA ”λ”> Греческая строчная лямбда (Л) U+03BB
cIENTITY mu CDATA ”μ” Греческая строчная мю (ц) и+озве
clENTFTY nu CDATA ”ν”> Греческая строчная ню (v) U+03BD
c’ENTIFY xi CDATA ”ξ"> Греческая строчная кси © U+03BE
cIENTITY omicron CDATA ”ο”> Греческий строчный омикрон (о) U+03BF
c’ENTITY pi CDATA "π"> Греческая строчная пи (л) U+03C0
cIENTITY rho CDATA ”`l ;”> Греческая строчная ро (р) U+03C1
cIENTITY sigmaf CDATA ”ς”> Греческая строчная финальная сигма U+03C2
c’ENTITY sigma CDATA "σ"> Греческая строчная сигма (ст) U+O3C3
cIENTITY tau CDATA ”τ”> Греческая строчная тау U+03C4
cIENTITY upsilon CDATA "υ"> Греческий строчный ипсилон (о) U+03C5
cIENTITY phi CDATA ”φ’’> Греческая строчная фи (ср) U+O3C6
<!ENTITY chi CDATA "χ"> Греческая строчная хи (%) U+03C7
cIENTITY psi CDATA "ψ”> Греческая строчная пси (V) U+03C8
cIENTITY omega CDATA ”ω”> Греческая строчная омега (со) U+03C9
cIENTITY thetasym CDATA "ϑ”> Греческий тета символ U+03D1
cIENTITY upsih CDATA ”ϒ"> Греческий ипсилон с крючком U+03D2
cIENTITY piv CDATA ”ϖ”> Греческий символ пи U+03D6
*) Не существует Sigmaf, и нет также символа U+03A2
Общая пунктуация
Определение Название символа Уникод Название набора
cIENTITY ensp CDATA "l94;”> en пробел U+2002 ISOpub
cIENTITY emsp CDATA "l95;"> em пробел U+2003 ISOpub
cIENTITY thinsp CDATA ”̴l;”> Узкий пробел U+2009 ISOpub
cIENTITY zwnj CDATA "‌"> Разрываемый соедини- тель нулевой ширины U+200C NEW RFC 2070
cIENTITY zwj CDATA "‍"> Соединитель нуле- вой ширины U+200D NEW RFC 2070
cIENTITY Irm CDATA "‎”> Знак слева направо U+200E NEW RFC 2070
c’ENTITY rim CDATA "‏”> Знак справа налево U+200F NEW RFC 2070
cIENTITY ndash CDATA "– ;"> еп дефис U+2013 ISOpub
cIENTITY mdash CDATA '’Rl2;"> em дефис U+2014 ISOpub
cIENTITY Isquo CDATA "Rl6;"> Левая кавычка U+2018 ISOnum
cIENTITY rsquo CDATA "Rl7;”> Правая кавычка U+2019 ISOnum
c’ENTITY sbquo CDATA "Rl8;”> Single low-9 quotation mark (одиночная кавычка) U+201A NEW
Приложения
10Э1
Общая пунктуация
Определение Название символа Уникод Название набора
cIENTITY Idquo CDATA ”“”> Левая двойная кавычка U+201C ISOnum
cIENTITY rdquo CDATA ”̶l:”> Правая двойная ка- вычка U+201D ISOnum
c’ENTITY bdquo CDATA "„’’> Двойная кавычка U+201E NEW
cIENTITY dagger CDATA "†" Кинжал t U+2020 ISOpub
cIENTITY Dagger CDATA "‡"> Двойной кинжал J U+2021 ISOpub
c’ENTITY bull CDATA ”•”> Маленький черный кружочек (bullet) • **) U+2022 ISOpub
cIENTITY hellip CDATA ”…”> Многоточие = трех- точечный пунктир ... U+2026 ISOpub
cIENTITY permit CDATA ”‰” Знак промиль %о U+2030 ISOtech
c’ENTITY prime CDATA ”′”> Прайм = минуты = Фрт. . . U+2032 ISOtech
c’ENTITY Prime CDATA ”″"> Дубль прайм = се- кунды = дюймы U+2033 ISOtech
<!ENTITY Isaquo CDATA "‹"> Одиночная, угловая левая кавычка U+2039 Предло- жено ISO
cIENTITY rsaquo CDATA ”›”> Одиночная, угловая правая кавычка U+203A Предло- жено ISO
cIENTITY oline CDATA ”‾”> Верхняя черта U+203E NEW
c’ENTITY frasl CDATA ”⁄”> Косая черта дроби U+2044 NEW
c’ENTITY euro CDATA ”€"> Зйак евро € U+20AC NEW
**) bullet не тождественен оператору bullet, U+2219
Буквоподобные символы
Определение Название символа Уникод Название набора
c’ENTITY weierp CDATA ”℘”> Прописная письменная Р U+2H8 ISOamso
c’ENTITY image CDATA ”ℑ”> Прописная жирная буква I = мнимая часть U+2HI ISOamso
c’ENTITY real CDATA ”ℜ"> Прописная жирная буква R = символ действительной части U+2HC ISOamso
c’ENTITY trade CDATA ”™"> Символ торговой марки U+2122 ISOnum
cIENTITY alefsym CDATA ”͒l;”> Символ alef ***) U+2135 NEW
***) Символ alef не тождественен букве иврита alef, U+05D0 хотя тот же
самый глиф может быть использован для отображения обоих символов
1092
Приложения
Стрелки
Определение Название символа Уникод Название набора
clENTITY larr CDATA "←"> Стрелка влево 1)4-2190 ISOnum
clENTITY uarr CDATA "↑"> Стрелка вверх 1)4-2191 ISOnum
clENTITY rarr CDATA "→"> Стрелка вправо U+2192 ISOnum
<!ENT1TY darr CDATA ”↓”> Стрелка вниз U+2193 ISOnum
clENTITY harr CDATA "↔"> Двухсторонняя горизонтальная стрелка 1)4-2194 ISOamsa
clENTITY crarr CDATA "↵"> Стрелка вниз с поворотом налево ~ возврат каретки U+21B5 NEW
clENTITY lArr CDATA "⇐"> Двойная стрелка влево +) U+21D0 ISOtech
clENTITY uArr CDATA "⇑"> Двойная стрелка вверх 1)4-21 D1 ISOamsa
clENTITY rArr CDATA "⇒"> Двойная стрелка вправо ++) U+21D2 ISOtech
<!ENT1TY dArr CDATA ”⇓’'> Двойная стрелка вниз U+21D3 ISOamsa
clENTITY hArr CDATA "⇔"> Двойная двухсторонняя стрелка U+21D4 ISOamsa
*) Уникод не утверждает, что 1Агг тождественно “implied by”, но не имеет
какого-либо другого символа для этих целей. Так ? 1Агг может использо-
ваться так, как это рекомендует ISOtech
"+) Уникод не утверждает, что это “implies” символ, но не имеет другого
символа для этих целей, таким образом, ? гАгг может использоваться так,
как это рекомендует ISOtech \
Математические операторы
Определение Название символа Уникод Название набора
clENTITY forall CDATA ,,∀,’> Для всех U4-2200 ISOtech
clENTITY part CDATA "∂”> Частный дифференциал 3 1)4-2202 ISOtech
clENTITY exist CDATA "∃”> Существует U+2203 ISOtech
clENTITY empty CDATA "∅"> Пустой набор = диа- метр U4-2205 ISOamso
clENTITY nabla CDATA "∇"> Набла = обратная раз- ница U4-2207 ISOtech
clENTITY isin CDATA ”∈”> Элемент чего-то U4-2208 ISOtech
clENTITY notin CDATA ”∉’’> Не элемент чего-то U4-2209 ISOtech
clENTITY ni CDATA "∋"> Содержит, как член U+220B ISOtech
clENTITY prod CDATA "∏"> . n-кратное произведе- ние= знак произведе- ния П#) U+220F ISOamsb
clENTITY sum CDATA "∑"> n-кратная сумма Х##) U4-2211 ISOamsb
clENTITY minus CDATA "−''> Знак минус - 1)4-2212 ISOtech
clENTITY lowast CDATA "∗">1 Оператор звездочка 1)4-2217 ISOtech
clENTITY radic CDATA "√"> Квадратный корень = знак радикала л/ U4-221A ISOtech
clENTITY prop CDATA "∝"> пропорционально 1)4-221D ISOtech
clENTITY infin CDATA "∞,’> Бесконечность ) 1)4-221Е ISOtech
clENTITY ang CDATA "∠"> Угол (Z) 1)4-2220 ISOamso
Приложения
1093
Математические операторы
Определение Название символа Уникод Название набора
<!ENTITY and CDATA "∧"> Логическое И =призма U+2227 ISOtech
c’ENTITY or CDATA ”∨”> Логическое ИЛИ U+2228 ISOtech
<!ENTITY cap CDATA "∩"> Пересечение п U+2229’ ISOtech
<!ENTlTY cup CDATA "∪”> Объединение и U+222A ISOtech
<!ENTITY int CDATA "∫"> Инте! рал J. U+222B ISOtech
'ENTITY there4 CDATA ”∴”> Следовательно => U+2234 ISOtech
<!ENTITY sim CDATA ,,∼,'> Оператор тильда = из- меняется с = подобно тому ) U+223C ISOtech
c’ENTITY cong CDATA ”≅:”> I {риблизительно равно - U+2245 ISOtech
cIENTITY asymp CDATA ”≈”> Почт равно- aci[митоти- ческое приближение к = U+2248 ISOamsr
c’ENTITY ne CDATA ”X()0:”> Не равно) U+2260 ISOtech
cIENTITY equiv CDATA ”Ͱl :”> Идентично - тождест- венно равно (=) U+2261 ISOtech
<!ENTITY le CDATA "≤:’'> Меньше или равно (< ) U+2264 ISOtech
cIENTITY ge CDATA "X()5;"> Больше или равно > U+2265 ISOtech
cIENTITY sub CDATA ”⊂:,’> Входит в U+2282 ISOtech
cIENTITY sup CDATA ,,⊃,’> Включает в себя LJ+2283 ISOtech
cIENTITY nsub CDATA ”⊄:”> Не является субнабо- ром чего-то CJ+2284 ISOamsn
cIENTITY sube CDATA ’’⊆”> Входит в или тождест- венен U+2286 ISOtech
cIENTITY stipe CDAT/\ ,,<S39;”> Включает в себя или тождественен U+2287 ISOtech
cIENTITY oplus CDATA ,,⊕:”> I !люс в кружочке = direct sum (Ф ) U+2295 ISOamsb
cIENTITY otiines CDATA ”<^#8855;”> Векюрнос произведе- ние = знак умножения в кружочке ) U+2297 ISOamsb
c’ENTITY perp CDATA ”⊥”> Ортогонально = пер- пендикулярно (1 ) U+22A5 ISOtech
cIENTITY sdot CDATA ”Y()l:”> Оператор ючка U+22C5 ISOamsb
#) prod не тождественен символу U+ОЗАО “греческая прописная буква pi”
хотя один и тот же глиф может быть использован для отображения обоих
~fi) sum не тождественен символу U+03A3 “греческая прописная буква сиг-
ма” хотя один и тот же глиф может быть использован для отображения
обоих
tilde оператор не тождественен символу U+007E, хотя один и тот же
глиф может быть использован для отображения обоих
###*) Оператор dot не тождественен символу U+00B7 центральная точка
1094
Приложения
Различные технические символы
Определение Название символа Уникод Название набора
<!ENTITY Iceil CDATA ”⌈”> left ceiling = apl upstile U+2308 ISOamsc
<!ENTITY rceil CDATA ”⌉”> right ceiling ( ) U+2309 ISOamsc
<!ENTITY Ifloor CDATA ”⌊”> left floor = apl downstile U+230A ISOamsc
<!ENTITY rfloor CDATA "⌋ ;"> right floor U+230B ISOamsc
<’ENTITY lang CDATA "〈"> левая угловая скобка U+2329 ISOtech
<!ENTITY rang CDATA ”〉”> ' правая угловая скобка= закрывающая скобка U+232A ISOtech
Геометрические формы
Определение Название символа Уникод Название набора
<!ENTITY loz CDATA ”◊’’> ‘ ромб (0) U+25CA I SOpub
Различные символы
Определение Название символа Уникод Название набора
<!ENTITY spades CDATA ”♠”> черные пики ) U+2660 ISOpub
<!ENTITY clubs CDATA ”♣”> черные крести=лист кислицы (* ) U+2663 ISOpub
<!ENTITY hearts CDATA ”♥"> черные черви(V ) U+2665 ISOpub
<!ENTITY diams CDATA "♦"> черные бубни (♦ ) U+2666 ISOpub
Эталонные символьные объекты для символов разметки текста и
интернационализации
Эталонные символьные объекты в этой секции предназначены для сим-
волов разметки текста (markup) (они те же, что и в HTML 2.0 и‘3.2), для
обозначения пробелов и дефисов. Остальные символы в этой секции ис-
пользуются для интернационализации.
Добавлены некоторые символы из СР-1252, которые не встречаются в
наборах HTMLlatl или HTMLsymbol. Все они из диапазона 128 - 159 сим-
вольного набора ср-1252. Эти объекты позволяют обозначать символы неза-
висимо от платформы.
Для поддержки этих объектов агенты пользователя могут поддержи-
вать полный набор ISO10646 или использовать другие средства. Отображе-
ние глифов этих символов может быть реализовано, если возможно отобра-
жение символов ISO10646 или другими средствами.
Список символов
<!— Набор символьных объектов:
<!ENTITY % HTMLspecial PUBLIC «-//W3C//ENTITIES Special//
EN//HTML»
% HTMLspecial; —>
<!— Используется набор объектов ISO, если не введены новые имена.
Новые имена (напр., не из списка ISO 8879) не будут конфликтовать с лю-
быми существующими именами объектов ISO 8879. Коды символов ISO
10646 приводятся для всех символов в шестнадцатеричном виде. Значе-
ния CDATA представляют собой десятичные коды ISO 10646. Имена соот-
ветствуют именам Unicode 2.0. —>
Приложения
1095
Специальные символы HTML. Контроли СО и базовый латинский
Определение Название символа Уникод Название набора
clENTITY quot CDATA ”"”> Кавычка = APL quote U+0022 ISOnum
clENTITY amp CDATA ”&”> Знак & U+0026 ISOnum
clENTITY It CDATA "<"> Знак меньше чем U+003C ISOnum
clENTITY gt CDATA ”>"> Знак больше чем U+003E ISOnum
Латинские буквы, расширение A
Определение Название символа Уникод Название набора
clENTITY OElig CDATA ”Œ”> ) Латинская прописная лигатура ОЕ U+0I52 ISOlat2
clENTITY oelig CDATA ”œ"> Латинская строчная лигатура ое U+0153 ISOlat2
clENTITY Scaron CDATA "Š"> Латинская прописная буква S с короной U+0160 ISOlat2
<!ENTITY scaron CDATA "š”> Латинская строчная буква s с короной U+0161 ISOlat2
clENTITY Yuml CDATA ”Ÿ”> Латинская прописная буква Y с тремой (умляутом) U+0178 ISOlat2
Латинские буквы, расширение В
Определение Название символа Уникод Название набора
clENTITY fnof CDATA "ƒ" -> Латинская строчная буква f с крючком = флорин U+0192 ISOtech
Модис >икаторы букв
Определение Название символа Уникод Название набора
clENTITY circ CDATA "l0;"> Модификатор буквы - облегченное ударение U+02C6 ISOpub
clENTITY tilde CDATA ”˜'‘> Малая тильда U+02DC ISOdia
1096
Приложения
7.9. Имена временных зон
Временная зона Сокращение
Универсальное время (Universal Time, тоже, что и GMT) UT
Время по Гринвичу (Greenwich Mean Time) GMT
Восточное стандартное время (Eastern Standard Time) EST
Центральное стандартное время (Central Standard Time) CST '
Центральное дневное время (Central Daylight Time) CDT
Mountain Standard Time MST
Mountain Daylight Time MDT
Pacific Standard Time PST
Pacific Daylight Time PDT
Содержание
1. Введение...................................................3
2. Преобразование, кодировка и передача информации...........13
2.1. Передача сигналов по линиям связи....................17
2.2. Представление электрических сигналов в двоичной форме.23
2.3. Цифровые каналы Т1 иЕ1 ..............................31
2.4. Методы преобразования и передачи звуковых сигналов....33
2.4.1. Передача голоса по каналам Интернет..............38
2.5. Методы преобразования и передачи изображения.........43
Стандарт MPEG...........................................55
Интерактивное телевидение............*..................57
2.6. Общие методы сжатия информации .........................60
2.6.1. Алгоритм Зива-Лемпеля. Блочный алгоритм сжатия
информации без потерь................................. 63
2.6.2. Метод Шеннона-Фано .............................66
2.6.3. Статический алгоритм Хафмана.....................67
2.7. Обнаружение ошибок...................................69
2.8. Коррекция ошибок. Линейные блочные коды..............76
2.9. Видеоконференции по каналам Интернет и ISDN..........79
2.9.1. Используемые стандарты...........................87
3. Каналы передачи данных....................................90
3.1. Кабельные каналы связи...............................90
3.2. Оптические каналы связи..............................97
3.3. Построение сетей передачи данных с использованием радио
каналов................................................. 105
3.4. Протокол SLIP...................................... 115
3.4.1. Протоколы RS................................... 116
3.5. Протокол РРР ...................................... 117
3.6. Протокол интерфейса G.703 ......................... 126
4. Сети передачи данных. Метод доступа......................128
Топология............................................... 128
Метод доступа к сети.................................... 130
Принципы построения сетевых программных интерфейсов........ 137
Методы работы в условиях перегрузки .................... 139
Алгоритм leaky bucket («дырявое ведро»)................. 141
Алгоритм («маркерное ведро»)........................... 141
4.1. Локальные сети (LAN)............................... 146
4.1.1. Ethernet (IEEE 802.3).......................... 146
4.1.2. Сети FDDI...................................... 184
4.1.3. Параллельный сетевой интерфейс HIPPI........... 192
4.1.4. Сети IEEE 802.11............................... 195
4.1.5. Двойная шина с распределенной очередью (DQDB)... 205
4.1.6. Канальный протокол Fibre Channel............... 208
4.2. Наложенные сети.................................... 213
4.2.1. NETBIOS........................................ 213
4.3. Региональные сети.................................. 216
4.3.1. Эталонная сетевая модель ISO .................. 216
4.3.2. Протоколы сетей Х.25 ........................ 222
4.3.3. Интегрированные цифровые сети ISDN..............242
4.3.4. Протокол Frame Relay........................... 269
4.3.5. ATM — широкополосный ISDN...................... 274
4.3.6. Синхронные каналы SDH/SONET.................... 297
4.3.7. Модемы ........................................ 307
4.4. Интернет........................................... 320
4.4.1. IP-протокол ................................... 322
4.4.2. Протокол UDP .................................. 388
4.4.3. Протокол TCP................................... 394
4.4.4. Протокол передачи команд и сообщений об ошибках
(ICMP) ................................................412
4.4.5. Протокол ARP....................................422
4.4.6. Мультимедиа в Интернет......................... 427
4.4.7. Загрузочный протокол (ВООТР)................. 563
4.4.8. Протоколы маршрутизации в сетях Internet....... 566
4.4.9. Сервер имен (DNS)...............................623
4.4.10. Управляющий протокол SNMP .................. 637
4.4.14. SMTP протокол .................................681
4.4.15. Сетевой протокол времени (NTP V.3)............ 755
4.4.16. Простой сетевой протокол времени (SNTP) версия 4
для IPv4, IPv6 и OSI...................................802
4.5. Процедуры Интернет....................................
4.5.1. Процедура зондирования элементов Интернет (PING).... 815
4.5.2. Получение информации о пользователях и узлах сети
(Finger)..............................................819
4.5.3. Команда удаленного доступа TELNET ..............827
4.5.4. Пересылка файлов (FTP)..........................836
4.5.5. World Wide Web (WWW или W3).....................849
4.5.6. Протокол пересылки новостей NNTP (USENET) .....1003
4.5.7. Подписные листы LISTSERV.......................1015
4.5.8. Электронная почта (E-MAIL).....................1025
4.5.9. SET и другие системы осуществления платежей . 1038
5. Заключение..............................................1043
6. Литература..............................................1046
ПРИЛОЖЕНИЯ..............................................1049
7.1. Рекомендации CCITT, ANSI, ЕСМА по телекоммуникациям .... 1049
7.2. Коды протоколов в Ethernet II ..................1062
7.3. Стандартные мультикастинг-адреса Интернет.......1064
7.4. Национальные коды доменов в Интернет............1066
7.5. Список кодов и откликов на почтовые команды и сообщения ... 1074
7.6. Принципы формирования кода отклика в системе SMTP.1076
7.7. Базовые протоколы Internet......................1077
7.8. Символьный набор HTML...........................1081
7.9. Имена временных зон...............................1096
Имеются в продаже
Назаров А.Н., Разживин И.А., Симонов М.В. ATM: Технические решения
создания сетей/Под ред. А.Н. Назарова.
На основе системно-технического анализа предлагается обзор современных
подходов и достижений в области синтеза широкополосных цифровых сетей инте-
грального обслуживания, основанных на технологии ATM. Рассмотрены вопросы
структурного построения, управления и сигнализации в ATM сетях. Проанализированы
возможности и тактико-технические характеристики ATM оборудования различных
производителей и выработаны рекомендации по развертыванию ATM сетей.
В толковом словаре достаточно полно изложены термины и понятия, используемые
в тематике ATM. Приведены инженерные решения по реализации ATM сетей и их
взаимодействию с сетями, использующими различные протоколы.
Для широкого круга специалистов, занимающихся научными исследованиями,
разработкой технических средств и проектированием в области ATM сетей. Книга
будет полезна студентам и аспирантам вузов связи.
Хендесон Л., Дженкинс Т. FrameRelay. Межсетевое взаимодействие:
Пер. с англ.
С помощью этой книги читатель сможет определить, подходит ли технология
FrameRelay для его компании, какой именно вариант наиболее оптимален с точки
зрения развития предприятия и самой сети. В книге можно найти советы как решить
проблемы существующей сети и не отстать от растущих потребностей бизнеса,
найти наиболее экономичные и эффективные решения для глобальной сети
и принять стратегические решения относительно будущей реализации.
Приведены примеры поддерживаемых форматов данных, наиболее
благоприятного сетевого окружения, типичных трудностей, возникающих при
установке и эксплуатации сетей FrameRelay. Указаны сильные и слабые стороны
по сравнению с другими сетями, а так же преимущества, извлекаемые
как пользователями, так и инженерами, эксплуатирующими сети.
Книга предназначена для профессионалов в области информационных
технологий, ответственных за принятие решений по организации сети
и занимающихся их эксплуатацией
Эрглис К.Э. Интерфесы открытых систем. Учебный курс.
В книге описаны интерфейсы открытых информационных, вычислительных
и измерительно-управляющих систем: интерфейсы с последовательной передачей
битов, приборный интерфейс GPIB, системы КАМАК, VME, Mulibas, Фастбас,
Futurebs+, МСИ, PCI, SCI (РСИ), HiRelPCI, интерфейсы суперкомпьютеров. Описаны
современные сетевые технологии: Этернет, Интернет, ATM, SerialPlus,
МуппеЬРассмотрены логические протоколы, физические сигналы, конструктивы
модулей и крейтов, разъемы и кабели, а так же вопросы защиты интерфейсов от
электромагнитых помех и наводок. Прослежено развитие систем от первых стандартов
до современного состояния.
Учебное пособие подготовлено по оригинальным стандартам на интерфейсы
и материалам лекционного курса, читаемого автором в Снежинском физико-
техническом институте для студентов специальностей «Вычислительные машины,
комплексы, системы, сети», «Информационно-измерительная техника и технологии».
Книга может быть полезна для студентов других специальностей, а так же
инженерам НИИ и КБ.
Баричев С. Г., Гончаров В. В., Серов Р.Е. Основы современной
криптографии. Учебный курс.
В систематизированном виде рассмотрены вопросы создания симметричных
и асимметричных криптографических систем защиты информации. Описаны
алгоритмы электронных цифровых подписей, системы управления криптографическими
ключами, имитозащита информации.
Для специалистов в области защиты информации, может быть полезна
студентам ВУЗов.
Зегжда Д.П., Ивашко А.М. Основы безопасности информационных
систем. Учебное пособие.
В книге изложены результаты исследований обобщающие отечественный
и зарубежный опыт в области разработки нормативных, теоретических и практических
положений технологии построения специальных защищенных информационных
систем. Описываются основные положения базовых стандартов безопасности
информационных технологий, исследуются нарушения информационной безопасности,
рассматриваются формальные модели безопасности и принципы их использования
в системах обработки информации, анализируются существующие архитектуры за-
щищенных систем.
Для специалистов в области информационной безопасности, студентам вузов,
обучающихся по специальностям «Компьютерная безопасность» и «Комплексное
обеспечение информационной безопасности автоматизированных систем»
Маслов В.В. Основы программирования на языке Перл.
В книге приводятся основные сведения по языку программирования Перл,
получившего широкое распространение в связи с развитием компьютерной сети
Интернет. Описываются синтаксис языка, типы переменных, выражения, операторы,
функции и подпрограммы. Рассматриваются сложные структуры данных, модули
и классы. Даются сведения об отладке программ и диагностических сообщениях.
Для программистов, системных администраторов и пользователей компьютеров.
Маслов В.В. Основы программирования на языке Java.
В компактной форме приведены основные сведения по языку Java. Автор
постарался на простых примерах показать все препятствия, которые приходится
преодолевать в процессе изучения языка.
В данную книгу включены примеры программ для стандартной (JDK 1.1)
и второй (JDK 1.2) версий Java, все они проверены автором на практике.
Для пользователей персональных компьютеров интересющихся программи-
рованием на языке Java.
Халсалл Ф. Передача данных, сети компьютеров и взаимосвязь
открытых систем: Пер.с англ.
Книга посвящена сетям передачи данных: фундаментальным положениям
передачи данных; режимам работы, протоколам и стандартам на интерфейсы,
связанным с различными типами сетей передачи; международным стандартам на
протоколы для обеспечения взаимодействия открытых систем в различных средах.
Для инженерно-технических работников в области связи, информатики и вычис-
лительной техники. Может быть полезна студентам соответствующих специальностей.
Ганеев Р.М. Проектирование интерфейса пользователя средствами
Win32 API.
Книга посвящена методическим основам проектирования пользовательского
интерфейса средствами Win32 API. Основное внимание уделено динамическому
проектированию и управлению базовыми элементами информационных систем -
окнами, органами управления, меню и диалоговыми панелями. Книга написана
доступным языком, насыщена примерами программной реализации, все разделы
сопровождаются вопросами контроля полученных знаний и вариантами упражнений.
Она поможет читателю овладеть методикой проектирования эффективных приложений
для Windows.
Для тех, кто знает основы языка Си и хочет проектировать компактные
быстродействующие приложения.
Румянцев П.В. Азбука программирования в Win32 API. - 3-е изд.,
дополн.
Изложены вопросы создания программных приложений для Window’95
и Windows NT. Описаны основные типы переменных, макросов, функций. Материал
книги иллюстрируется многочисленными примерами. Настоящее издание (второе
вышло в 2000 г.) дополнено описанием тех возможностей Windows, которые не были
упомянуты в предыдущих изданиях.
Для программистов.
Румянцев П.В. Работа с файлами в Win 32 API
Изложены вопросы создания программных приложений для Windows.
Рассмотрены основы работы с файлами в Win 32 API, структура исполняемого файла,
его заголовки и разделы, экспорт и импорт функций, таблицы объектов, процессы
и связанные с ними потоки.
В значительной степени материал книги развивает и дополняет другую книгу
автора "Азбука программирования в Win 32 API", выдержавшую три издания.
Для программистов.
Старков В.В. Азбука персонального компьютера. Архитектура,
устройство и конфигурирование.
Книга написана в первую очередь для тех, кто только начинает свое
знакомство с персональным компьютером (ПК) и посвящена вопросам аппаратного
устройства компьютера.Рассматриваются основные структурные элементы ПК
и организация их совместной работы: материнская плата, процессор, память,
дисковые накопители, видеосистема и структура размещения данных, созданная
операционной системой. Описана история развития отечественной вычислительной
техники и дается краткий обзор нынешнего состояния дел в данной области.
Для начинающих пользователей и специалистов, а также для преподавателей
и студентов вузов, изучающих ПК.
Англо-русский словарь: Мультимедиа-системы. Телекоммуникационные
компьютерные сети. Безопасность компьютерных систем и сетей.
/А.А.Мячев, Е.С.Алексеев, В.Н.Веселов и др.
В книге, состоящей из трех отдельных словарей, содержится более 5000
основных терминов и понятий с толкованиями, относящихся к наиболее
перспективным информационным технологиям: техническим и программным средствам
и мультимедиа-системам, телекоммуникационнм компьютерным сетям, безопасности
компьютерных системи сетей.
Для ширококо круга специалистов, пользователей компьютеров
и компьютерных систем, переводчиков и редакторов, а также аспирантов и студентов.
Горбунов-Посадов М. М. Расширяемые программы.
Внесение изменений - один из ключевых моментов в жизни любой
программы. Программа становится расширяемой, если удалось спрогнозировать
направления ее будущего развития, облегчить и обезопасить выполнение
изменений в этих направлениях. Достичь расширяемости помогут представленные
в книге программные конструкции, поддерживающие возможность безболезненного
развития, т.е. добавления новых модулей без какого-либо редактирования ранее
написанных и отлаженных исходных текстов.
Для опытных программистов.
Роберт Лоренс Бейбер Программное обеспечение без ошибок.
Приемы и секреты создания правильных программ.
Приводятся различные способы проверки правильности программного
обеспечения. Все содержашиеся выкладки основываются на строгом математическом
аппарате. Однако автор, профессор Университета им. Гете, Германия, акцентирует
внимание на практических аспектах решения данной проблемы, избавляя создателей
программного обеспечения от долгих и скурпулезных доказательств, благодаря
которым нужный результат может быть достигнут относительно простыми средствами.
Для программистов.
Семенов Ю.А. Протоколы и ресурсы Internret.
Описывается работа сети Inertnet и рассматриваются вопросы эффективного
пользования услугами Internet, а также создания новых сетевых программных продуктов.
Книга состоит из трех частей: протоколы набора TCP/IP, базовые инструкции и процедуры
Internet, ресурсы и средства поиска информации. Приложения содержат списки
серверов и депозитариев (в странах СНГ и за рубежом), а также справочные таблицы.
Для широкого круга читателей.
Фридман А.Л. Основы объектно-ориентированного программирования
на языке Си++. Изд. 2-е перераб. и доп.
В 'систематизированном виде излагаются основы объектно-
ориентированного программирования, даются основные понятия и описываются
возможности языка Си++. При этом основное внимание уделяется объяснению того,
как теми или иными возможностями пользоваться. В конце книги помещен краткий
справочник по языку Си++, в котором перечисляются все основные конструкции
языка.
Для программистов начинающих изучать объектно-ориентированное програм-
мирование и язык Си++.
Вегнер В.А., Крутиков А.Ю., Серегин В.В., Сидоров В.А., Спесивцев А.В.
Аппаратура персональных компьютеров и ее программирование. IBM
РС/ХТ/АТ и PS/2
В своей книге группа программистов 2В ProGroup обобщает свой опыт работы
с персональными компьютерами. Описываются принципы работы и программирования
аппаратуры персональных компьютеров IBM РС/ХТ/АТ и PS/2. Описаны такие
устройства как таймер, часы, программируемый контроллер прерываний,
клавиатура, контроллер прямого доступа в память, контроллер гибких дисков,
последовательный и параллельный порты. Материал сопровождается большим
количеством примеров программ на языке ассемблера
Для системных программистов, разработчиков аппаратуры, а также
студентов и аспирантов технических вузов.
Иванов В.П., Батраков А.С. Трехмерная компьютерная графика.
Рассмотрены основные принципы формирования трехмерных
изображенийна компьютереи практическоеприменение трехмерной компьютерной
графики: распознавание образов, моделирование трехмерных сцен, архитерктурное
проектирование, анимация и т.д. Приведены сведения о программной поддержке
геометрического моделирования и компьютерного синтеза изображений, примеры
программ. Оригинальность и практическая значимость предложенных подходов
подтверждена независимой конкурсной экспертизой компании Hewlett Packard.
Для программистов, специалистов в области компьютерной графики, может
быть полезна студентам вузов.
Финогенов К.Г. Самоучитель по системным функциям MS-DOS. 3-е изд.
Книга представляет собой учебное пособие по использованию
программных средств операционной системы MS-DOS (включая версии 6.x)
в прикладных программах. Последовательно рассматриваются функции DOS и BIOS,
используемые для управления терминалом, обслуживания дисков, каталогов и файлов,
организации резидентных программ и иерархаических программных комплексов,
обработки прерываний. Каждый раздел книги включает описание системных
концепций и процедур, а также большое количество примеров и задач.
Для программистов, может быть полезна студентам вузов.
Приобрести эти книги можно через почтовое агентство DESSY
107113, г. Москва, а/я 10,
а также через интернет-магазины
www.dessv.ru
www.mistral.ru
www.top-kniqa.ru
С авторскими предложениями просим обращаться по e-mail:
radios@cityline.ru
TAREX-VSP
Цифровые АТС:
* серии GDK до 162 портов
- STAREX VSPi до 360 портов
- STAREX IMS до 14000 портов
Гибридные АТС:
- серии GHX до 46 портов
Аппаратура HDSL
“ГОРЯЧАЯ ЛИНИЯ - ТЕЛЕКОВ
официальный дистрибьюто
LG Information & Communications, Lt<
Москва, ул.Казакова, д.8А, стр.
Тел./факс: 261-0556, 261-9636,928-135
E-mail: hotline@editrans.i
LG Information & Communications, Ltd.