Вопросы к государственному экзамену по программе
«Разработчик профессионально-ориентированных компьютерных
технологий» ВМК
2009 год
1. Профили окружения открытых систем (OSE-профили)
Назначение OSE-профилей
Часть определений, включенных в ISO/IEC TR 10000-3, уже рассматривалась нами в
разделе 1. В частности, к ним относятся определения понятий OSE (Open Systems
Environment - окружения или среды открытых систем) и OSE-профиля (OSE-profile), а
также определения основных свойств открытости систем ИТ.
Напомним, что под OSE понимается исчерпывающий набор интерфейсов, сервисов,
форматов и других аспектов, позволяющий достичь целей интероперабельности и/или
переносимости приложений на основе применения базовых стандартов и профилей ИТ.
По существу под открытой системой и понимается система ИТ, реализующая
некоторое OSE, т.е. окружение, удовлетворяющее стандартам или открытым
спецификациям.
Для полной или частичной спецификации такого рода открытых окружений
применяется аппарат OSE-профилей, с помощью которого определяется
функциональность, потребляемая или предоставляемая системами ИТ на их интерфейсах.
Средством представления профилей в виде формальных документов, разработанных по
строго регламентированным требованиям, являются ISP (International Standardized Profile международный стандартизованный профиль). Каждый ISP может описывать один или
несколько профилей.
Введем еще ряд определений, связанных с концепцией открытых систем [1].

16) Прикладное программное обеспечение (Aplication Software - Прикладное программное
обеспечение). Специфическое для некоторого приложения программное обеспечение, состоящее из
программ, данных и документации.

17) Прикладная платформа (Aplication Platform). Набор программно-аппаратных ресурсов,
обеспечивающих сервис, необходимый для выполнения прикладного программного обеспечения.

18) API (Application Program Interface - Интерфейс прикладной программы). Интерфейс между
прикладным программным обеспечением и прикладной платформой, через который обеспечивается
сервис для прикладного программного обеспечения со стороны прикладной платформы.

19) CSI (Communication Services Interface - Интерфейс коммуникационных сервисов). Граница, через
которую обеспечивается доступ к сервисам, реализующим взаимодействие между внутренними
сущностями программного обеспечения и внешними объектами по отношению к прикладной
платформе.
1

20) HCI (Human/Computer Interface - Человеко-машинный интерфейс). Граница, через которую
имеет место физическое взаимодействие между человеком и прикладной платформой.

21) ISI (Information Services Interface - Интерфейс информационного сервиса). Граница, через
которую обеспечивается сервис внешнего, долговременного хранилища (external, persistent storage)
данных.
В рассматриваемом документе состав свойств открытости систем существенно
расширяется до следующего набора целей (свойств) открытых систем:
 Переносимость прикладного программного обеспечения и повторная применимость
(переиспользуемость) программного обеспечения на уровне исходного кода (Application Software
Portability and Software Reuse at the Source Code Level)
Именно переносимость между различными платформами исходного текста
программного обеспечения считается одной из основных практически достижимых задач,
решение которой позволяет организациям защитить себя от необходимости
дополнительного инвестирования в существующее программное обеспечение для его
перепроектирования при переходе на новые прикладные платформы.
Если под переносимостью приложений понимается перенос всего соответствующего
данному приложению программного обеспечения на другие платформы, то под
переиспользумостью программного обеспечения, как правило, понимается перенос или
портирование в новые приложения некоторой части работающих программ, что также
имеет большое практическое значение и непосредственно относится к целям открытости
систем.
Другие формы переносимости и переиспользуемости ПО, например, переносимость на
уровне объектного кода, считается вторичной по значимости задачей, прежде всего из-за
сложности ее решения.
 Переносимость данных (Data Portability)
Не менее важной целью открытых систем является переносимость на новые
прикладные платформы данных, хранящихся во внешней памяти существующих систем
ИТ, что обеспечивается разработкой OSE на основе стандартов и ISPs, строго
регламентирующих форматы и способы представления данных.
 Интероперабельность прикладного программного обеспечения (Application Software
Interoperability)
Под интероперабельностью понимается возможность обмена данными между
сущностями программного обеспечения, в том числе между сущностями, реализуемыми
на разнородных прикладных платформах, а также возможность совместного
использования ими обмениваемых данных. Данное свойство на нижнем уровне
обеспечивается построением стандартизованных коммуникационных интерфейсов (т.е.
CSI-интерфейсов) систем на основе стандартов сетевых протоколов, в частности, OSIпрофилей. Реализация его в полном объеме приводит к необходимости решения проблемы
семантической интероперабельности, т.е. понимания разнородными платформами
семантики данных, которыми они обмениваются друг с другом.
 Интероперабельность управления и безопасности (Management and Security Interoperability)
Для целей интеграции и совместного использования разнородных платформ в рамках
распределенных систем ИТ, необходима унификация и концептуальная целостность
2
средств административного управления и управления информационной безопасностью
систем ИТ независимо от реализационных окружений. Поэтому для обеспечения
бесшовной интеграции систем их средства административного управления и средства
защиты должны строиться в соответствии с международными стандартами.
 Переносимость пользователей (User Portability)
Под переносимостью пользователей понимается отсутствие необходимости в их
повторном обучении при переносе прикладного программного обеспечения на другие
платформы, что также является одной из важных целей концепции открытых систем.
 Адаптация к изменениям стандартов (Accommodation of Standards)
OSE-профили являются эффективным средством продвижения существующих
стандартов в практику. В то же время OSE-профили являются объектами, способными
эволюционировать с учетом изменения стандартов, технологий и пользовательских
требований, прежде всего потому, что они конструируются посредством ссылок на
базовые стандарты. Таким образом, на основе понятия OSE-профиля поддерживается
такое свойство открытых систем, как адаптируемость к изменению стандартов.
 Адаптация к новым технологиям информационных систем (Accommodation of New Information
System Technology)
OSE-профили, являясь исходным материалом при построении открытых систем, не
связаны непосредственно с нижележащими технологиями. Однако развитие таких
технологий влечет развитие системы стандартов. Гибкость аппарата OSE-профилей
позволяет учитывать тенденции перехода к новым стандартам и, соответственно, к новым
технологиям.
 Масштабируемость прикладных платформ (Application Platform Scalability)
Масштабируемость относится к важнейшим свойствам открытости систем ИТ.
Применительно к прикладной платформе оно означает возможность разных типов
реализаций некоторого OSE-профиля, отличающихся техническими и ресурсными
характеристиками (например, суперкомпьютеры и рабочие станции), поддерживать одну и
ту же функциональность, т.е. поддерживать один и тот же набор сервисов.
 Масштабируемость распределенных систем (Distributed System Scalability)
Это свойство заключается в том, что OSE-профили и соответствующие им реализации
должны использовать стандартные механизмы взаимосвязи компонент распределенных
систем, независящие от типов и характеристик компонент, а также от структуры
распределенных систем ИТ.
 Прозрачность реализаций (Implementation Transparency)
Данное свойство поддерживается благодаря систематическому использованию через
аппарат OSE-профилей стандартизованных спецификаций (стандартов и ISPs), одним из
принципов разработки которых является принцип независимости от конкретных
реализаций. Таким образом, все особенности реализации OSE-профилей скрываются за
интерфейсами открытых систем, что и обеспечивает свойство прозрачности реализаций
для конечных пользователей систем ИТ.
 Поддержка пользовательских требований (Support Clear Statement of User Requirements)
Важным свойством открытых систем является точная спецификация пользовательских
требований, определенных в виде наборов сервисов предоставляемых открытыми
3
системами на их интерфейсах. Это свойство адекватно поддерживается применением
аппарата OSE-профилей.
Концепция OSE-профилей
Общие принципы
Как следует из определения OSE-профиля, данная конструкция представляет собой
некоторый набор базовых стандартов и/или ISPs вместе с указанием выбираемой для
области применения профиля функциональности (опций, классов сервиса, тестовых
наборов, значений параметров), которая специфицирует полное или частичное поведение
спроектированных на основе данного профиля систем ИТ, наблюдаемое на их
интерфейсах. При этом под интерфейсами понимаются границы систем, на которых
может прослеживаться их функционирование со стороны внешнего наблюдателя
(пользователя, приложения, тестовой системы, администратора и пр.).
Наиболее важным результатом рассматриваемого документа является введение
классификации интерфейсов систем ИТ. Данная классификация совпадает с
классификацией, приведенной в эталонной модели RM OSE POSIX (ISO/IEC TR 14252,
Guide to the POSIX Open System Environment), но она представлена в более обобщенном,
независящем от конкретных архитектурных решений контексте и согласована с
классификацией эталонных точек (reference points) объектных распределенных систем
(ITU-T Rec. X.902 | ISO/IEC 10746-2, Information Technology - Open Distributed Processing Reference Model: Foundations).
Классификация интерфейсов открытых систем вводит следующие четыре основных
типа интерфейсов OSE, определения которых были рассмотрены выше:

API (Application Program Interface - Интерфейс прикладной программы);

CSI (Communication Services Interface - Интерфейс коммуникационных услуг);

HCI (Human/Computer Interface - Человеко-машинный интерфейс);

ISI (Information Services Interface - Интерфейс информационных услуг).
В принципе могут быть определены и другие типы интерфейсов, например, интерфейс
управляемых объектов.
Под API понимается интерфейс между прикладным программным обеспечением и
поставщиком необходимого для функционирования этого программного обеспечения
сервиса, т.е. прикладной платформой.
CSI трактуется как интерфейс, который обеспечивает сервис для реализации
взаимодействия с внешними системами ИТ. Реализация такого взаимодействия
осуществляется с помощью протоколов (процедур обмена), стандартизация которых
вместе со стандартизацией форматов обмениваемых с помощью этих протоколов данных
является основой обеспечения интероперабельности систем.
4
Понятие HCI ассоциируется с интерфейсом, через который осуществляется физическое
взаимодействие пользователя и системы ИТ. Примерами такого интерфейса служат
клавиатуры для ввода информации и оконные системы взаимодействия с пользователем.
ISI рассматривается как граница взаимодействия с внешней памятью долговременного
хранения данных, для переносимости и интероперабельности которых необходима
стандартизация форматов и синтаксиса представления данных.
Таким образом, определяемая профилем OSE функциональность в общем случае может
рассматриваться как композиция функций или сервисов, реализуемых на интерфейсах
определенных выше классов. Функциональность профиля специфицируется в терминах
вызовов функций, протоколов взаимодействия, форматов данных. Естественным
требованием к профилю является согласованность используемых им спецификаций,
относящихся к интерфейсам различным классов.
Следует отметить, что при разработке профилей OSE ссылки на стандарты и ISPs,
определяющие способы и форматы представления данных, так называемые F-профили (Fprofiles), могут относиться к любым типам интерфейсов, в зависимости от назначения
этих стандартных спецификаций.
Описанная выше классификация интерфейсов открытых систем является основой для
построения таксономии профилей. Она также полезна при использовании
систематического подхода к проектированию профилей OSE.
Иллюстрацией к введенным выше понятиям и их взаимосвязи может служить модель
OSE систем ИТ, предложенная на рис. 4.1.
Рис.4.1. Модель OSE для систем ИТ
В частности, в данной модели показано, что открытые системы могут иметь более
одного экземпляра интерфейсов каждого класса. Например, конкретная система может
включать одновременно CSI-интерфейс, соответствующий стеку протоколов TCP/IP, а
также CSI-интерфейс, соответствующий стеку OSI. Также данная модель отражает тот
факт, что интерфейсы разных классов могут взаимодействовать друг с другом. Примером
такого взаимодействия может служить включение в API-интерфейс средств (библиотек), с
помощью которых прикладная программа может взаимодействовать с элементами
5
интерфейсов других классов. Такая зависимость интерфейсов показана на модели с
помощью функциональной нотации (API(HCI), API(ISI), API(CSI)).
Завершая рассмотрение аппарата OSE-профилей, отметим важность этого понятия для
концепции тестирования конформности открытых систем стандартам и профилям.
OSE-профиль, представляющий собой набор стандартизованных спецификаций,
описывающих поведение системы на ее интерфейсах, является исходной конструкцией
для осуществления процесса установления конформности систем этим спецификациям.
При этом в случае OSE-профилей данный процесс существенно усложняется из-за
необходимости проверки соответствия тестируемого продукта сразу нескольким
спецификациям, определяющим требования к поведению системы на интерфейсах
различных классов с учетом взаимосвязанности происходящих на этих интерфейсах
событий.
Принципы разработки OSE-профилей
Рассмотрим пример применения OSE-профиля и на основе этого примера
продемонстрируем методику разработки OSE-профилей.
Для примера выберем класс распределенных офисных систем, содержащих в качестве
своих компонент (подсистем) системы трех типов: A, B, C. Их назначение следующее:

Система типа A представляет собой систему-клиента базы данных с некоторым прикладным
программным обеспечением (например, ориентированным на поддержку бухгалтерской
деятельности).

Система типа В - сервер баз данных, обслуживающий запросы клиентов к базе данных.

Система типа С - терминальный сервер, выполняющий семантику функций человеко-машинного
интерфейса на клиентских машинах.
Зададимся целью разработать офисную систему рассмотренного класса, обладающую
свойством переносимости прикладного программного обеспечения клиентской части и,
возможно, интероперабельности.
Методологической основой создания такой системы является разработка
соответствующего OSE-профиля, специфицирующего поведение системы типа А на всех
ее интерфейсах. При этом специфицируемое профилем окружение должно определяться
некоторым набором стандартизованных спецификаций (стандартов и ISPs), чтобы
обеспечить разработку приложений клиентской системы А на основе принципов
открытости, в частности, переносимости программного обеспечения. Присвоим данному
профилю рабочее наименование DOT (Distributed Office Technology).
Для разработки профиля DOT будем применять некоторый систематический подход,
который можно представить в виде последовательности шагов. Основными шагами
данного подхода являются:

1. Идентификация области применения систем ИТ, соответствующих данному профилю, а также
определения конечных целей и общих ограничений задачи проектирования профиля.
6
В нашем случае область применения разрабатываемого профиля ограничена
конкретным классом информационных систем и конкретной функциональной
компонентой таких систем (прикладным программным обеспечением клиентских
систем). Также определены цели проектирования - переносимость и
интероперабельность клиентского программного обеспечения.


2. Разработка сценария (типовой ситуации применения системы ИТ, соответствующей
разрабатываемому профилю). Такой сценарий, как правило, представляет собой графическое
представление информационной модели систем данного класса, включающей:
o
Основные функциональные элементы (системы/подсистемы) описываемой реализации;
o
Взаимосвязи между элементами (физические каналы, логические взаимодействия или
протоколы);
o
Распределение функций ИТ по элементам модели.
3. Определение функциональности профиля в виде набора ссылок на актуальные стандарты и ISPs и
формирование, таким образом, раздела нормативных ссылок.
Дадим краткую мотивацию принятым решениям.
Описанный выше профиль определяет OSE для прикладных программ клиентских
систем распределенных офисных технологий со следующими возможностями:

В качестве средств API, обязательными для разработки прикладных программ
систем типа А, принимаются стандарты языков С и SQL. Язык С++ вводится как
дополнительная возможность для программирования приложений. Доступ к
удаленным базам данных должен осуществляться посредством интерфейса и
протокола ODBC, являющегося стандартом де-факто. Доступность базовых
возможностей операционной системы и встроенных в нее языковых средств
(оболочки) реализуется на основе спецификаций POSIX (IEEE Std 1003.1, IEEE Std
1003.2).

Для реализации интерфейса сетевого взаимодействия (CSI) предполагается
использовать стек протоколов TCP/IP. В качестве базовой сетевой архитектуры
канального уровня принимается структура локальных сетей, например, с методом
доступа IEEE Std 802.3 (сети типа Ethernet).

Для реализации HCI в профиле DOT выбираются две оконные системы:
OSF/MOTIF и X Window.

ISI в профиле DOT не специфицируется. Здесь считается, что соответствующих
возможностей, предоставляемых базовой операционной системой должно быть
достаточно для переносимости информации с внешних носителей.
 4. Анализ спецификаций на совместимость. На этом шаге производится тщательный
анализ непротиворечивости спецификаций, входящих в состав профиля. В результате
этого шага могут быть определены дополнительные требования конформности
реализаций профилю, исключающие случаи потенциального конфликта между
спецификациями.
7
 5. Определение концептуальной части профиля - введение новых понятий в раздел
Definitions, дополняющих систему понятий цитируемых базовых спецификаций, а также
введение используемых в профиле сокращений (раздел Abbreviations).
 6. Анализ требуемой функциональности для каждого цитируемого базового стандарта
или ISPs, обоснование и выбор классов сервиса, тестовых поднаборов, опций, диапазонов
значений параметров.
 7. Разработка требований конформности, учитывающих специфику применения
профиля для каждой спецификации, упомянутой в разделе нормативных ссылок (раздел
Conformance).
 8. Разработка списка требований конформности, например, в табличной форме, как это
будет рассмотрено далее.
 9. Разработка информативных приложений.
Принципы таксономии профилей OSE
Таксономия - это классификационная схема профилей ИТ, предназначенная для
недвусмысленной ссылки на профили и группы профилей. Она позволяет формировать
уникальные идентификаторы профилей, отражающие также взаимосвязь профилей и
групп профилей между собой.
Классификация основывается на разбиении профилей по областям, соответствующим
содержанию определенных или предполагаемых эталонных моделей.
Следует отметить, что представленная структура классификации является
динамической по своей природе и легко адаптируется к эволюции системы стандартов и
технологий.
Для построения классификационной схемы применяется метод структурированных
идентификаторов.
Структурированный идентификатор имеет следующие компоненты:

Корневую мнемонику или корень (root mnemonic) - короткую символьную строку, обозначающую
область использования OSE-профиля. Например, EDI (для Electronic Data Interchange) или MED (для
медицинских приложений).

Числовую строку, следующую за корнем и используемую для разбиения области использования
OSE-профилей на подразделы.

Характеристику специфицируемых интерфейсов (суффикс), состоящую от одной до четырех
указанных ниже букв, следующих в алфавитном порядке:
C - для CSI (в профилях, принятых до 1995г., обычно опускается)
I - для ISI
H - для HCI
P - для API
(Рассматривалось использование буквы F для F-профилей).
8
В таксономии возможно указание профилей, цитируемых в конкретном OSE-профиле,
при этом для идентификации OSE-профиля используется функциональная форма записи:
MEDkkk-CHP (FTmmm-CP, WINiii-H)
Тестирование конформности продуктов на соответствие OSE-профилям
Общие принципы аппарата конформности, определенные для профилей в ISO/IEC TR
10000-1, распространяются и на OSE-профили.
Особенность решения задачи тестирования конформности для OSE-профилей исходит
из их композиционной сложности и возможности включения в свой состав спецификаций,
относящихся к различным классам интерфейсов.
Однако единой для всех видов интерфейсов методологии тестирования конформности в
настоящее время еще не существует, что, как правило, делает необходимым применение
для тестирования конформности OSE-продуктов некоторого комплексного подхода,
интегрирующего методологии тестирования, разработанные для отдельных видов
интерфейсов.
В частности, наиболее проработанными в методологическом плане подходами к
тестированию конформности конкретных видов интерфейсов являются:

методология OSI для тестирования реализаций сетевых протоколов и сервисов, т.е. CSIинтерфейсов, - ITU-T Rec. X.290 | ISO/IEC 9646-1;

методология POSIX для тестирования реализаций прикладных интерфейсов, т.е. API-интерфейсов, ISO/IEC 13210.
Для отдельных применений могут быть полезны подходы, разработанные для
технологии ODA (Open Document Architecture) и для графических стандартов,
определенные в ISO/IEC TR 10183-1 и в ISO/IEC 10641, соответственно.
2. Передача данных в локальных сетях. Управление средой передачи.
Обзор протоколов передачи данных: Ethernet, Token Ring, FDDI, WiFi.
1. ПЕРЕДАЧА ДАННЫХ В ЛОКАЛЬНОЙ СЕТИ
1.1. Датаграммы
1.2. Сеансы связи
1.3. Сетевой адрес
В локальной сети данные передаются от одной рабочей станции к другой блоками,
которые называют пакетами данных. Каждый пакет состоит из заголовка и собственно
блока данных. Станция, которая желает передать пакет данных другой станции, указывает
в заголовке адрес назначения и свой
9
собственный, аналогично тому, как это делаете вы, отправляя обычное письмо. На
конверте, в который вложено письмо, вы указываете адрес получателя и обратный (свой
собственный) адрес.
Продолжая аналогию с письмами, вспомним, что на почте существует такая услуга, как
отправка письма или телеграммы с уведомлением о вручении. Когда адресат получит
ваше письмо, вам отправляется уведомление о вручении. В этом случае вы можете
убедиться, что письмо дошло до адресата и не потерялось по дороге.
В локальной сети программы также имеют возможность отправлять "обычные письма", а
также "письма с уведомлением о вручении". И, разумеется, в локальной сети имеется своя
система адресов.
1.1. Датаграммы
Передача пакетов данных между рабочими станциями без подтверждения - это тип связи
между рабочими станциями на уровне датаграмм (datagram). Уровень датаграмм
соответствует сетевому уровню (Network Layer) семиуровневой модели OSI, описанной
нами в предыдущем томе.
Что значит "передача без подтверждения"? Это означает, что не гарантируется доставка
пакета от передающей станции к принимающей. В результате, например, перегрузки сети
или по каким-либо другим причинам принимающая сторона может так и не дождаться
предназначенного ей пакета данных. Причем, что характерно для уровня датаграмм,
передающая сторона так и не узнает, получила ли принимающая сторона пакет или не
получила.
Более того, на уровне датаграмм не гарантируется также, что принимающая сторона
получит пакеты в той последовательности, в какой они посылаются передающей
станцией!
Казалось бы, зачем нужна такая передача данных, которая не гарантирует доставки?
Однако программы, обменивающиеся данными, могут сами организовать проверку.
Например, принимающая программа может сама посылать подтверждение передающей
программе о том, что получен пакет данных.
Протокол передачи данных IPX - межсетевой протокол передачи пакетов (Internetwork
Packet Exchange) - используется в сетевом программном обеспечении Novell и является
реализацией уровня датаграмм. Протокол NETBIOS, разработанный фирмой IBM, также
может работать на уровне датаграмм.
Большинство задач в сети можно решить на уровне датаграмм, поэтому мы уделим много
внимания протоколам IPX и NETBIOS.
Одно из преимуществ уровня датаграмм - возможность посылки пакетов данных
одновременно всем станциям в сети. Если же для программ необходима гарантированная
доставка данных, можно использовать протокол более высокого уровня - уровня сеанса
связи.
10
1.2. Сеансы связи
На уровне сеансов связи (Session Layer) две рабочие станции перед началом обмена
данными устанавливают между собой канал связи - обмениваются пакетами специального
вида. После этого начинается обмен данными.
На уровне сеансов связи при необходимости выполняются повторные передачи пакетов
данных, которые по каким-либо причинам "не дошли" до адресата. Кроме того,
гарантируется, что принимающая станция получит пакеты данных именно в том порядке,
в котором они были переданы.
При использовании уровня сеансов связи невозможно организовать
"широковещательную" передачу пакетов одновременно всем станциям - для передачи
данных необходимо организовать канал связи между одной и другой станцией.
Следовательно, в процессе передачи данных могут участвовать одновременно только две
станции.
Как и следовало ожидать, в сетевом программном обеспечении Novell уровень сеансов
связи реализован как надстройка над уровнем датаграмм. На базе протокола IPX
реализован протокол SPX - протокол последовательной передачи пакетов (Sequenced
Packet Exchange Protocol).
Протокол NETBIOS реализует наряду с уровнем датаграмм уровень сеансов связи.
В сети Novell NetWare есть эмулятор протокола NETBIOS. Этот эмулятор использует
протокол IPX для реализации как уровня датаграмм, так и уровня сеансов связи.
1.3. Сетевой адрес
Подобно почтовому адресу, сетевой адрес состоит из нескольких компонентов. Это номер
сети, адрес станции в сети и идентификатор программы на рабочей станции - сокет (рис.
1).
Рис. 1. Сетевой адрес
Номер сети (network number) - это номер сегмента сети (кабельного хозяйства),
определяемого системным администратором при установке Novell NetWare. Не путайте
этот номер с внутренним номером сети файл-сервера. Напомним, что если в одном
11
сегменте сети имеется два файл-сервера NetWare, то они оба имеют одинаковый номер
сети, но разные внутренние номера сети. Если в общей сети есть мосты, каждая отдельная
сеть, подключенная через мост, должна иметь свой, уникальный номер сети.
Адрес станции (node address) - это число, которое является уникальным для каждой
рабочей станции. При использовании адаптеров Ethernet уникальность обеспечивается
изготовителем сетевого адаптера (адрес станции записан в микросхеме постоянного
запоминающего устройства, которая находится внутри самого адаптера). Для адаптеров
ArcNet адрес станции необходимо устанавливать при помощи перемычек или
переключателей на плате сетевого адаптера. Устанавливая в сети адаптеры ArcNet,
позаботьтесь о том, чтобы все они имели в сети разные адреса. Как установить сетевой
адрес адаптера ArcNet, вы сможете узнать из документации, поставляющейся вместе с
адаптером.
Специальный адрес FFFFFFFFFFFFh используется для посылки пакета данных всем
станциям данной сети одновременно. Пакет с таким адресом напоминает открытое письмо
с опубликованием в печати.
Идентификатор программы на рабочей станции - сокет (socket) - число, которое
используется для адресации конкретной программы, работающей на станции. В среде
мультизадачных операционных систем, к которым можно отнести OS/2 и Microsoft
Windows в расширенном режиме, на каждой рабочей станции в сети одновременно могут
быть запущены несколько программ.
Для того, чтобы послать данные конкретной программе, используется идентификация
программ при помощи сокетов. Каждая программа, желающая принимать или передавать
данные по сети, должна получить свой, уникальный для данной рабочей станции,
идентификатор - сокет.
1.2. Среда и методы передачи данных в сетях ЭВМ
1.2.2. Линии связи и каналы передачи данных
Для построения компьютерных сетей применяются линии связи, использующие
различную физическую среду. В качестве физической среды в коммуникациях
используются: металлы (в основном медь), сверхпрозрачное стекло (кварц) или пластик и
эфир. Физическая среда передачи данных может представлять собой кабель "витая пара",
коаксиальные кабель, волоконно-оптический кабель и окружающее пространство.
Линии связи или линии передачи данных - это промежуточная аппаратура и физическая
среда, по которой передаются информационные сигналы (данные).
В одной линии связи можно образовать несколько каналов связи (виртуальных или
логических каналов), например путем частотного или временного разделения каналов.
Канал связи - это средство односторонней передачи данных. Если линия связи
монопольно используется каналом связи, то в этом случае линию связи называют каналом
связи.
12
Канал передачи данных - это средства двухстороннего обмена данными, которые
включают в себя линии связи и аппаратуру передачи (приема) данных. Каналы передачи
данных связывают между собой источники информации и приемники информации.
В зависимости от физической среды передачи данных каналы связи можно разделить на:
 проводные линии связи без изолирующих и экранирующих оплеток;
 кабельные, где для передачи сигналов используются такие линии связи как кабели "витая пара",
коаксиальные кабели или оптоволоконные кабели;
 беспроводные (радиоканалы наземной и спутниковой связи), использующие для передачи сигналов
электромагнитные волны, которые распространяются по эфиру.
Проводные линии связи
Проводные (воздушные) линии связи используются для передачи телефонных и телеграфных сигналом, а
также для передачи компьютерных данных. Эти линии связи применяются в качестве магистральных линий
связи.
По проводным линиям связи могут быть организованы аналоговые и цифровые каналы передачи данных.
Скорость передачи по проводным линиям "простой старой телефонной линии" (POST - Primitive Old
Telephone System) является очень низкой. Кроме того, к недостаткам этих линий относятся
помехозащищенность и возможность простого несанкционированного подключения к сети.
Кабельные каналы связи
Кабельные линии связи имеют довольно сложную структуру. Кабель состоит из проводников, заключенных
в несколько слоев изоляции. В компьютерных сетях используются три типа кабелей.
Витая пара (twisted pair) — кабель связи, который представляет собой витую пару медных проводов (или
несколько пар проводов), заключенных в экранированную оболочку. Пары проводов скручиваются между
собой с целью уменьшения наводок. Витая пара является достаточно помехоустойчивой. Существует два
типа этого кабеля: неэкранированная витая пара UTP и экранированная витая пара STP.
Характерным для этого кабеля является простота монтажа. Данный кабель является самым дешевым и
распространенным видом связи, который нашел широкое применение в самых распространенных локальных
сетях с архитектурой Ethernet, построенных по топологии типа “звезда”. Кабель подключается к сетевым
устройствам при помощи соединителя RJ45.
Кабель используется для передачи данных на скорости 10 Мбит/с и 100 Мбит/с. Витая пара обычно
используется для связи на расстояние не более нескольких сот метров. К недостаткам кабеля "витая пара"
можно отнести возможность простого несанкционированного подключения к сети.
Коаксиальный кабель (coaxial cable) - это кабель с центральным медным проводом, который окружен
слоем изолирующего материала для того, чтобы отделить центральный проводник от внешнего проводящего
экрана (медной оплетки или слой алюминиевой фольги). Внешний проводящий экран кабеля покрывается
изоляцией.
Существует два типа коаксиального кабеля: тонкий коаксиальный кабель диаметром 5 мм и толстый
коаксиальный кабель диаметром 10 мм. У толстого коаксиального кабеля затухание меньше, чем у тонкого.
Стоимость коаксиального кабеля выше стоимости витой пары и выполнение монтажа сети сложнее, чем
витой парой.
Коаксиальный кабель применяется, например, в локальных сетях с архитектурой Ethernet, построенных по
топологии типа “общая шина”. Коаксиальный кабель более помехозащищенный, чем витая пара и снижает
собственное излучение. Пропускная способность – 50-100 Мбит/с. Допустимая длина линии связи –
13
несколько километров. Несанкционированное подключение к коаксиальному кабелю сложнее, чем к витой
паре.
Кабельные оптоволоконные каналы связи. Оптоволоконный кабель (fiber optic) – это оптическое волокно
на кремниевой или пластмассовой основе, заключенное в материал с низким коэффициентом преломления
света, который закрыт внешней оболочкой.
Оптическое волокно передает сигналы только в одном направлении, поэтому кабель
состоит из двух волокон. На передающем конце оптоволоконного кабеля требуется
преобразование электрического сигнала в световой, а на приемном конце обратное
преобразование.
Основное преимущество этого типа кабеля – чрезвычайно высокий уровень
помехозащищенности и отсутствие излучения. Несанкционированное подключение очень
сложно. Скорость передачи данных 3Гбит/c. Основные недостатки оптоволоконного
кабеля – это сложность его монтажа, небольшая механическая прочность и
чувствительность к ионизирующим излучениям.
Беспроводные (радиоканалы наземной и спутниковой связи) каналы
связи
Радиоканалы наземной (радиорелейной и сотовой) и спутниковой связи образуются с помощью передатчика
и приемника радиоволн и относятся к технологии беспроводной передачи данных.
Радиорелейные каналы связи.
Радиорелейные каналы связи состоят из последовательности станций, являющихся ретрансляторами. Связь
осуществляется в пределах прямой видимости, дальности между соседними станциями - до 50 км.
Цифровые радиорелейные линии связи (ЦРРС) применяются в качестве региональных и местных систем
связи и передачи данных, а также для связи между базовыми станциями сотовой связи.
Спутниковые каналы связи.
В спутниковых системах используются антенны СВЧ-диапазона частот для приема радиосигналов от
наземных станций и ретрансляции этих сигналов обратно на наземные станции. В спутниковых сетях
используются три основных типа спутников, которые находятся на геостационарных орбитах, средних или
низких орбитах. Спутники запускаются, как правило, группами. Разнесенные друг от друга они могут
обеспечить охват почти всей поверхности Земли. Работа спутникового канала передачи данных
представлена на рисунке
14
Целесообразнее использовать спутниковую связь для организации канала связи между станциями,
расположенными на очень больших расстояниях, и возможности обслуживания абонентов в самых
труднодоступных точках. Пропускная способность высокая – несколько десятков Мбит/c.
Сотовые каналы связи.
Радиоканалы сотовой связи строятся по тем же принципам, что и сотовые телефонные сети. Сотовая связь это беспроводная телекоммуникационная система, состоящая из сети наземных базовых приемопередающих станций и сотового коммутатора (или центра коммутации мобильной связи).
Базовые станции подключаются к центру коммутации, который обеспечивает связь, как между базовыми
станциями, так и с другими телефонными сетями и с глобальной сетью Интернет. По выполняемым
функциям центр коммутации аналогичен обычной АТС проводной связи.
LMDS (Local Multipoint Distribution System) - это стандарт сотовых сетей беспроводной передачи
информации для фиксированных абонентов. Система строится по сотовому принципу, одна базовая станция
позволяет охватить район радиусом несколько километров (до 10 км) и подключить несколько тысяч
абонентов. Сами БС объединяются друг с другом высокоскоростными наземными каналами связи либо
радиоканалами. Скорость передачи данных до 45 Мбит/c.
Радиоканалы WiMAX (Worldwide Interoperability for Microwave Access) аналогичны Wi-Fi. WiMAX, в
отличие от традиционных технологий радиодоступа, работает и на отраженном сигнале, вне прямой
видимости базовой станции. Эксперты считают, что мобильные сети WiMAX открывают гораздо более
интересные перспективы для пользователей, чем фиксированный WiMAX, предназначенный для
корпоративных заказчиков. Информацию можно передавать на расстояния до 50 км со скоростью до 70
Мбит/с.
Радиоканалы MMDS (Multichannel Multipoint Distribution System). Эти системы способна обслуживать
территорию в радиусе 50—60 км, при этом прямая видимость передатчика оператора является не
обязательной. Средняя гарантированная скорость передачи данных составляет 500 Кбит/с — 1 Мбит/с, но
можно обеспечить до 56 Мбит/с на один канал.
Радиоканалы для локальных сетей. Стандартом беспроводной связи для локальных сетей является
технология Wi-Fi. Wi-Fi обеспечивает подключение в двух режимах: точка-точка (для подключения двух
ПК) и инфраструктурное соединение (для подключения несколько ПК к одной точке доступа). Скорость
обмена данными до 11 Mбит/с при подключении точка-точка и до 54 Мбит/с при инфраструктурном
соединении.
Радиоканалы Bluetooht - это технология передачи данных на короткие расстояния (не более 10 м) и может
быть использована для создания домашних сетей. Скорость передачи данных не превышает 1 Мбит/с.
Протокол Ethernet
Протокол Ethernet позволяет передавать данные со скоростью 10 Мбит/с и использовать следующие типы кабелей: толстый коаксиальный кабель (стандарт 10Base-5), тонкий коаксиал (стандарт 10Base-2), неэкранированную витую пару (стандарт 10Base-T),
оптоволоконный кабель (стандарт 10Base-F).
Данные в протоколах канального уровня передаются в виде группы бит, организованных в кадр данных. Исторически существует 4 различных формата кадров Ethernet:
- кадр Ethernet DIX (Ethernet II) – один из первых форматов, стандарт фирм Digital, Intel
и Xerox.
- кадр 802.3/LLC - международный стандарт.
- кадр Raw 802.3 (Novell 802.3) – стандарт фирмы Novell.
- кадр Ethernet SNAP – второй доработанный вариант международного стандарта.
Обычно сетевые карты автоматически распознают и поддерживают все четыре
формата кадров. Для простоты изложения ограничимся рассмотрением самого простого
15
по формату кадра Ethernet II, который имеет поля, указанные на рис.2.2.
Преамбула
(для синхронизации) и
признак
начала кадра
Адрес
назначе
ния
пакета
Адрес
источник
а пакета
Тип пакета
(указывает какому
протоколу более
высокого уровня
принадлежит пакет)
Данные
(передаваемая
информаци
я)
Контрольная
сумма
Рис.2.2. Формат кадра Ethernet.
Однако, помимо структуры кадра данных, в протоколе необходимо оговорить и
порядок передачи этого кадра по сети. Основным принципом работы Ethernet является
использование общей среды передачи данных разделяемой по времени, когда кадры
данных передаются всеми компьютерами по общему кабелю. Особенно наглядно это
проявляется при топологии "общая шина", хотя принцип сохраняется и при любой другой
топологии. Впервые метод доступа к разделяемой общей среде был опробован во второй
половине 60-х годов, в радиосети Aloha Гавайского университета, где общей средой
передачи данных являлся радиоэфир. В 1975 году этот принцип был реализован и для
коаксиального кабеля, в первой экспериментальной сети Ethernet Network фирмы Xerox.
В настоящее время сети Ethernet используется метод доступа CSMA/CD (Carrier
Sense Multiply Access with Collision Detection) - коллективный доступ с проверкой несущей и обнаружением коллизий. Порядок передачи данных и коррекция ошибок происходит следующим образом: каждый кадр данных переданный в сеть получают все компьютеры, но только один из них распознает свой адрес и обрабатывает кадр. В каждый
отдельный момент времени только один компьютер может передавать данные в сеть.
Компьютер, который хочет передать кадр данных, прослушивает сеть и, если там
отсутствует несущая частота (сигнал с частотой 5-10 Мгц), то он решает, что сеть
свободна и начинает передавать кадр данных. Однако, может случится, что другой
компьютер, не обнаружив несущей, тоже начнет передачу данных одновременно с
первым. В таком случае, возникает столкновение (коллизия). Если один из передающих
компьютеров обнаружил коллизию (передаваемый и наблюдаемый в кабеле сигнал отли16
чаются), то он прекращает передачу кадра и усиливает ситуацию коллизии, посылкой в
сеть специальных помех – последовательности из 32-бит (jam-последовательность), для
того, чтобы и второй компьютер надежно обнаружил коллизию. После этого компьютеры
ждут (каждый – случайное время) и повторяют передачу. Поскольку время – случайное (у
каждого свое), то вероятность повторного столкновения невелика. Однако если столкновение произойдет снова (возможно с другими компьютерами), то следующий раз диапазон,
в котором выбирается случайное время задержки, увеличится в 2 раза (после 10-й попытки увеличение не происходит, а после 16-й попытки кадр отбрасывается). В любом случае,
время задержки, при возникновении коллизии невелико (максимум 52,4 миллисекунды) и
незаметно для пользователя, однако при большой загрузке сети (начиная с 40 - 50%),
слишком большая доля времени тратится на устранение коллизий и полезная пропускная
способность падает. Более рациональным способом получения доступа к общей
разделяемой среде является протокол Token Ring._
Протокол Token Ring (High Speed Token Ring)
Использование протокола Token Ring позволяет карте работать на скоростях 4 и 16
Мбит/с, а протокола High Speed Token Ring – на скоростях 100 и 155 Мбит/с. Компания
IBM является основным разработчиком протокола Token Ring, производя около 60 %
сетевых адаптеров этой технологии.
Сеть Token Ring представляет собой кольцо: каждый компьютер соединен кабелем
только с предыдущим и последующим компьютером в кольце. Физически это реализуется
при помощи специальных концентраторов (см. рис.2.4) [1], которые обеспечивают целостность кольца даже при выключении или отказе одного из компьютеров, за счет обхода
17
порта выключенного компьютера.
Рис. 2.4. Cтруктура сети Token Ring
Принцип доступа к разделяемой среде – доступ с передачей маркера (token).
Компьютер может начать передавать данные в сеть, только если получит от предыдущего
компьютера в кольце "маркер" – специальный короткий пакет, свидетельствующий о том,
что сеть свободна. Если компьютеру нечего передавать в сеть, то он передает маркер следующему компьютеру в кольце. Если компьютеру есть что передавать, то он уничтожает
маркер и передает свой пакет в сеть. Пакет по битам ретранслируется по кольцу от компьютера к компьютеру, адресат получает пакет, устанавливает в пакете биты, подтверждающие, что пакет достиг адресата и передает пакет дальше по кольцу. Наконец, пакет
возвращается к отправителю, который уничтожает его и передает в сеть новый маркер.
Компьютер может и не передавать в сеть новый маркер, а продолжить передавать кадры
данных до тех пор, пока не истечет время удержания маркера (token holding time). После
истечения времени удержания маркера компьютер обязан прекратить передачу собственных данных (текущий кадр разрешается завершить) и передать маркер далее по кольцу.
Обычно время удержания маркера по умолчанию равно 10 мс.
18
В процессе работы сети, из-за сбоев, возможна потеря маркера. За наличие в сети
маркера, причем единственной его копии, отвечает один из компьютеров - активный
монитор. Если активный монитор не получает маркер в течение длительного времени
(например 2,6 с), то он порождает новый маркер. Активный монитор выбирается во время
инициализации кольца, как станция с максимальным значением МАС-адреса сетевой карты. Если активный монитор выходит из строя, процедура инициализации кольца повторяется и выбирается новый активный монитор. Чтобы сеть могла обнаружить отказ активного монитора, последний в работоспособном состоянии каждые 3 секунды генерирует специальный кадр своего присутствия. Если этот кадр не появляется в сети более 7 секунд, то
остальные станции сети начинают процедуру выборов нового активного монитора.
Описанный выше алгоритм доступа используется в сетях со скоростью 4 Мбит/с. В
сетях со скорость 16 Мбит/с алгоритмы доступа более сложные: используется алгоритм
доступа к кольцу, называемый алгоритмом раннего освобождения маркера (Early Token
Release). Компьютер передает маркер доступа следующей станции сразу же после окончания передачи последнего бита кадра, не дожидаясь возвращения по кольцу этого кадра с
битом подтверждения приема. В этом случае пропускная способность кольца используется более эффективно, так как по кольцу одновременно продвигаются кадры нескольких
компьютеров. Тем не менее, свои кадры в каждый момент времени может генерировать
только один компьютер — тот, который в данный момент владеет маркером доступа.
Остальные компьютеры в это время только повторяют чужие кадры, так что принцип
разделения кольца во времени сохраняется, ускоряется только процедура передачи
владения кольцом.
Передаваемым кадрам, протокол верхнего уровня (например прикладного) может
также назначить различные приоритеты: от 0 (низший) до 7 (высший). Маркер также всегда имеет некоторый уровень текущего приоритета и уровень резервного приоритета. При
инициализации кольца основной и резервный приоритеты устанавливаются в ноль.
Компьютер имеет право захватить переданный ему маркер только в том случае, если
приоритет кадра, который он хочет передать, выше (или равен) текущему приоритету
маркера. В противном случае компьютер обязан передать маркер следующему по кольцу
компьютеру. Однако, даже если компьютер не захватил маркер, он может записать в поле
резервного приоритета значение приоритета своего кадра (при условии, что предыдущие
компьютеры не записали в это поле более высокий приоритет). При следующем обороте
маркера резервный приоритет станет текущим и компьютер получит возможность
захватить маркер.
Хотя механизм приоритетов в технологии Token Ring имеется, но он начинает
работать только в том случае, когда приложение или прикладной протокол решают его
использовать. Иначе все станции будут иметь равные права доступа к кольцу, что в основном и происходит на практике, так как большая часть приложений этим механизмом не
пользуется.
Развитием протокола Token Ring стал протокол High-Speed Token Ring, который
поддерживает скорости в 100 и 155 Мбит/с, сохраняя основные особенности технологии
Token Ring 16 Мбит/с.
2.1.6. Протокол FDDI
Протокол FDDI (Fiber Distributed Data Interface) используется в оптоволоконных
сетях и работает на скорости 100 Мбит/с. Исторически, когда скорости других протоколов
ограничивались 10-16 Мбит/с, FDDI использовался на магистральных оптоволоконных
сетях передачи данных.
Технология FDDI во многом основывается на технологии Token Ring, развивая и
19
совершенствуя ее основные идеи. Сеть FDDI строится на основе двух оптоволоконных
колец, которые образуют основной и резервный пути передачи данных между узлами
сети. Наличие двух колец необходимо для повышения отказоустойчивости сети FDDI, и
компьютеры, которые хотят воспользоваться этой повышенной надежностью могут (хотя
это и не требуется) быть подключены к обоим кольцам.
В нормальном режиме работы сети данные проходят через все узлы и все участки
кабеля только первичного (Primary) кольца. Этот режим назван режимом Thru - «сквозным» или «транзитным». Вторичное кольцо (Secondary) в этом режиме не используется. В
случае какого-либо отказа, когда часть первичного кольца не может передавать данные
(например, обрыв кабеля или отказ компьютера), первичное кольцо объединяется со вторичным (см. рис.2.5), вновь образуя единое кольцо. Этот режим работы сети называется
Wrap, то есть «свертывание» или «сворачивание» колец. Операция свертывания производится средствами концентраторов и/или сетевых карт FDDI. Для упрощения этой процедуры, данные по первичному кольцу всегда передаются в одном направлении, а по
вторичному — в обратном (см. рис.2.5). Поэтому при образовании общего кольца из двух
колец, направление передачи данных по кольцам остается верным. Сеть FDDI может полностью восстанавливать свою работоспособность в случае единичных отказов ее элементов. При множественных отказах сеть распадается на несколько не связанных сетей.
Рис.2.5. Восстановление работоспособности сети FDDI при обрыве кольца.
Метод доступа к разделяемой среде в сети FDDI аналогичен методу доступа в сети
Token Ring. Отличия заключаются в том, что время удержания маркера в сети FDDI не
является постоянной величиной, как в сети Token Ring, а зависит от загрузки кольца —
при небольшой загрузке оно увеличивается, а при больших перегрузках может уменьшаться до нуля. В сети FDDI нет выделенного активного монитора — все компьютеры и
концентраторы равноправны, и при обнаружении отклонений от нормы любой из них
может начать процесс повторной инициализации сети, а затем и ее реконфигурации. В
остальном пересылка кадров между станциями кольца полностью соответствует технологии Token Ring со скоростью 16 Мбит/с (применяется алгоритм раннего освобождения
маркера).
На физическом уровне технология "сворачивания" колец реализуется специальными концентраторами. В стандарте FDDI допускаются два вида подсоединения компьютера
к сети. Одновременное подключение к первичному и вторичному кольцам называется
двойным подключением (Dual Attachment, DA). Компьютеры, подключенные таким обра20
зом, называются DAS (Dual Attachment Station), а концентраторы - DAC (Dual Attachment
Concentrator). Подключение только к первичному кольцу называется одиночным подключением— Single Attachment, SA. Компьютеры, подключенные таким образом, называются
SAS (Single Attachment Station), а концентраторы - SAC (Single Attachment Concentrator).
Чтобы устройства легче было правильно присоединять к сети, их разъемы маркируются.
Разъемы типа А и В должны быть у устройств с двойным подключением, разъем М
(Master) имеется у концентратора для одиночного подключения станции, у которой ответный разъем должен иметь тип S (Slave). В случае однократного обрыва кабеля между устройствами с двойным подключением сеть FDDI сможет продолжить нормальную работу
за счет автоматической реконфигурации внутренних путей передачи кадров между портами концентратора. При обрыве кабеля, идущего к компьютеру с одиночным подключением, он становится отрезанным от сети, а кольцо продолжает работать. Эта ситуация
изображена на рисунках 2.6-2.7.
21
Рис.2.6. Исходное подключение компьютеров к сети FDDI (до обрыва).
Рис.2.7. Реконфигурация сети FDDI в случае обрыва.
22
3. Эталонная модель взаимосвязи открытых систем (OSI RM).
Стандартизация функций информационного обмена между вычислительными системами
имеет решающее значение для создания компьютерных сетей, интеграции
предоставляемых ими ресурсов и услуг.
Стандартизация функции взаимосвязи компьютерных сетей на международном уровне
осуществляется с середины 70-х годов 20-го века. В настоящее время сформирована
обширная система стандартов, в состав которой входят следующие виды документов.
1) Эталонная модель OSI RM (X.200).
2) Стандарты методологии и средств тестирования конформности (X.290).
3) Стандарты протоколов и сервисов сетевых технологий.
4) Стандарты абстрактных методов тестирования сетевых протоколов.
5) Международные стандартизованные профили сетевых технологий.
6) Стандарты общесистемных функций (управления, безопасности, качества сервисов).
7) Вспомогательные документы (руководства, словари понятий, технические отчеты) и др.
Следует отметить, что стандарты сетевых технологий, разработанные в соответствии с
эталонной моделью OSI, не ограничиваются стеком сетевых протоколов модели OSI. К
ним можно отнести обширное множество стандартов технологий локальных сетей,
цифровых сетей с интегральным сервисом ISDN, системы сигнализации N7 (SS7), сетевых
технологий X.25, ATM и Frame Relay, радиосетей стандарта GSM и пр.
Стандартизация взаимосвязи систем охватывает три уровня описания средств
информационного обмена.
На первом уровне, который можно назвать концептуальным, специфицируется
эталонная модель взаимосвязи открытых систем OSI RM (Open Systems Interconnection
Reference Model), в рамках которой определяются основные понятия и общая структура
взаимосвязи, описываются принципы построения системы базовых стандартов. Таким
образом, эталонная модель формирует методологические основы построения и язык
описания стандартов взаимосвязи открытых систем.
На втором уровне определяются спецификации сервиса (услуг), предоставляемого
отдельными компонентами архитектуры OSI RM, т.е. на данном уровне стандартизуются
спецификации функциональных возможностей отдельных компонент модели.
Наиболее детальным уровнем описания взаимосвязи открытых систем является
спецификация протоколов информационного обмена между функциональными
23
элементами эталонной модели, определяющими правила и форматы взаимодействия
элементов.
Изучение системы стандартов сетевых технологий, разработанных на основе эталонной
модели OSI RM, начнем с самой эталонной модели.
Модель OSI RM разработана международной организации по стандартизации ISO. Ее
описание приведено в документах, имеющих индекс ISO 7498, а также в рекомендации
X.200 организации ITU-T (ранее, до 1994г., называвшейся CCITT). Оба документа
являются эквивалентными с технической точки зрения и имеют статус формального
международного стандарта.
OSI RM предназначена для определения общей основы процесса стандартизации в
области взаимосвязи систем, обеспечивающей целостность и взаимную согласованность
стандартов. Разработанные на этой основе стандарты позволяют реализовывать
унифицированные средства обмена данными между системами в соответствии с
согласованными на международном уровне требованиями, определенными в модели OSI
RM. Системы, взаимодействующие посредством такого рода стандартных процедур
обмена данными, называются "открытыми системами", а реализуемая ими взаимосвязь "взаимосвязью открытых систем".
Формирование стандарта OSI RM осуществлялось на протяжении почти десятилетия.
Текст первой редакции ISO 7498 публиковался и принимался в качестве международного
стандарта по частям с 1984 по 1989 гг. В 1994 г. стандарт пересматривался и претерпел
некоторую редакцию и технические исправления. Представленная в документах ISO 7498
и X.200 модель взаимосвязи открытых систем определяет базовые понятия, структуру,
семантику, механизмы исполнения телекоммуникационной функции (т.е. функции
взаимосвязи удаленных систем посредством обмена данными), нотации для спецификации
сервисов сетевых протоколов.
Стандарт ISO 7498 имеет следующую структуру:
1). Базовая эталонная модель (Basic Reference Model - ISO 7498 - 1994(E)/ITU-T
Recommendation X.200 (1994)).
2) Дополнение 1: Передача в режиме без соединения (Addendum 1: Connectionless-mode
transition. ISO 7498(E)/Add.1:1987 - включено в основной текст ITU-T Recommendation
X.200 (1994)).
3). Часть 2: Архитектура безопасности (Part 2: Security Architecture. ISO 74982:1989(E)/ITU-T Recommendation X.800 (1991)).
4). Часть 3: Наименование и адресация (Part 3: Naming and Addressing. ISO 7498-3(E)/ITUT Recommendation X.650 (1996)).
5). Часть 4: Основы управления (Part 4: Management framework. ISO 7498-4(E)/ITU-T
Recommendation X.700 (1992)).
6). Технические исправления (Technical Corrigendum 1: ISO 7498:1984/Cor.:1988).
24
Указанные выше документы составляют описание основной понятийной и
архитектурной части модели OSI RM. Еще одна группа чрезвычайно важных документов,
неразрывно связанная с описанием модели OSI RM, может рассматриваться в качестве
непосредственного дополнения модели OSI RM. Они содержат описание архитектурных
принципов построения сетевых приложений и описание нотаций для спецификации
сервисов и сетевых протоколов. В состав этих документов входят:
1) Структура прикладного уровня (Application Layer Structure. ISO/IEC 9545/ITU-T
Recommendation X.207 (1993)).
2) Спецификация первой синтаксической нотации ASN.1 (Specification of Abstract Syntax
Notation One (ASN.1). ISO/IEC 8824:1990/ITU-T Recommendation X.208 (1993)).
3) Спецификации базовых правил кодирования для ASN.1 (Specification of Basic Encoding
Rules for Abstract Syntax Notation One (ASN.1). ISO/IEC 8825:1990/ ITU-T Recommendation
X.209 (1993)).
4) Соглашения об определении сервисов OSI (Conventions For The Definition of OSI
Services. ISO/IEC 10731/ ITU-T Recommendation X.210 (1993)).
Кроме этого, важное общеметодологическое значение имеют документы серии X.290
(ISO/IEC 9646). В них определена методологическая основа тестирования конформности
реализаций сетевых протоколов стандартам, разработанным в соответствии с моделью
OSI RM. В частности, определены: основные понятия конформности, типовая структура
процесса установления конформности, принципы разработки абстрактных методов
тестирования, средства спецификации тестовых ситуаций, структура комплектов тестов,
назначение и функции лабораторий тестирования и пр.
Основные элементы эталонной модели
В документах стандарта ISO 7498, описывающих эталонную модель OSI RM, вводится
более 200 понятий. Наиболее значимые для понимания и применения данной модели
понятия будут нами вводиться последовательно по мере необходимости при изучении тех
или иных свойств модели OSI RM. Первоначально рассмотрим определения основных
элементов эталонной модели.
Реальная система (real system): компьютерная система вместе с соответствующим
программным обеспечением, периферийным оборудованием, терминалами, операторами,
средствами передачи данных и т.д., которая способна обрабатывать и/или передавать
данные.
Реальная открытая система (open real system): это реальная система,
удовлетворяющая требованиям стандартов ISO при ее взаимодействии с другими
реальными системами.
В окружении ISO стандартизуется только внешний аспект поведения реальных
открытых систем. Поэтому любая реальная система, внешнее поведение которой
соответствует требованиям модели OSI RM и требованиям разработанных на ее основе
стандартов OSI, считается открытой реальной системой. К реальным открытым системам
25
могут относиться оконечные пользовательские компьютерные системы,
коммуникационные устройства подсети связи, сетевые терминалы.
Открытая система (open system): представление с помощью понятийных и
описательных средств эталонной модели OSI RM тех аспектов реальной открытой
системы, которые относятся к окружению (области) OSI.
По существу открытая система представляет собой некоторую абстрактную модель
реальной открытой системы, описывающую внешнее поведение данной системы при ее
взаимосвязи с другими реальными открытыми системами и удовлетворяющую
требованиям стандартов ISO.
Прикладной процесс (application-process): некоторый элемент в реальной открытой
системе, выполняющий обработку информации для конкретного приложения и
представляющий собой потенциальный источник и/или потребитель передаваемой в сети
информации.
Примерами прикладных процессов служат: прикладная программа, использующая
удаленную базу данных; работающий за банковским терминалом пользователь или
оператор; программа управления процессами распределенной робототехнической
системы.
Окружение (среда) взаимосвязи открытых систем или OSI-окружение (Open System
Interconnection Environment - OSIE): абстрактное представление набора понятий,
элементов, функций, сервисов, протоколов и пр., определенных средствами OSI RM, а
также созданные на этой основе стандарты, при реализации которых обеспечивается связь
открытых систем.
Таким образом, OSIE ограничивается миром взаимосвязи систем, т.е. охватывает
исключительно аспекты, связанные с обменом информацией между системами и
возможностью их объединения в сети (интерсети) для решения общих или
распределенных задач.
Окружение локальной системы или LSE (Local System Environment - LSE): абстрактное
представление части реальной системы, которая не относится к OSI.
Активация (экземпляр, вызов) прикладного процесса (application-process-invocation):
конкретное использование (полностью или частично) функциональных возможностей
данного прикладного процесса для поддержки конкретного случая процесса обработки
информации.
Прикладной процесс является основным элементом реальной открытой системы,
реализующим конкретную прикладную функцию.
Работа, выполняемая прикладным процессом, осуществляется одной или несколькими
его активациями. В конкретный момент времени прикладной процесс может быть
представлен некоторым набором активаций, включая пустой набор. При этом,
взаимодействие между прикладными процессами осуществляется посредством
взаимосвязи, устанавливаемой между их активациями. Активация процесса отвечает за
координацию взаимодействия с другими активациями. Собственно семантика
26
координации взаимодействия активаций прикладных процессов выходит за рамки
эталонной модели.
Тип прикладного процесса (application-process-type): описание класса прикладных
процессов в виде набора функциональных возможностей по обработке информации.
Прикладная сущность (application-entity - AE): совокупность функций прикладного
процесса, непосредственно связанных с обеспечением его взаимодействия с другими
прикладными процессами.
Примером такой сущности может служить некоторый протокольный автомат,
реализующий процедуры обмена данными с подобным ему автоматом в другой системе в
соответствии с некоторым протоколом взаимодействия.
Ассоциация (association): связь между сущностями, позволяющая им осуществлять
обмен информацией.
Физическая среда OSI (physical media for OSI): среда распространения физического
сигнала, переносящего информацию.
Примерами физических сред переноса информации в виде сигнала являются
коаксиальный кабель, витая пара, оптоволокно, радиоканал и т.п.
Определенные выше основные элементы эталонной модели OSI RM и их взаимосвязь
иллюстрируется на рис.8.1. Следует заметить, что большое число определений и
сокращений, вводимых в стандартах информационных технологий вообще и в OSI RM, в
частности, а также способы построения понятий посредством композиции ключевых слов,
существенно затрудняют перевод терминов и применение переведенных терминов.
Поэтому для обеспечения большей точности изложения и соответствия
рассматриваемого материала исходным документам, на иллюстрациях и рисунках будут в
основном использоваться оригинальные термины.
Рис.8.1. Основные элементы эталонной модели OSI RM
27
Другая иллюстрация взаимосвязи определенных выше понятий приведена на рис. 8.2,
на котором показана реальная открытая система (Open Real System), охватывающая
пользователей (users), программы (programs), локальные ресурсы (файловую систему,
базы данных и пр.), собственную открытую систему (Open System), прикладной процесс
(Application Process).
Прикладной процесс состоит из двух частей: прикладной сущности (Application Entity)
и прикладного агента (Application Agent).
Назначением прикладной сущности является реализация процедур (протоколов) обмена
прикладными блоками данных (APDUs - Application Protocol Data Units) с удаленными
прикладными сущностями такого же типа.
Собственно обмен прикладными блоками данных осуществляется не непосредственно,
а с помощью услуг набора протоколов, обеспечивающих транспортировку сегментов
данных между открытыми системами в OSIE (в окружении OSI). Распределенная система
сущностей, обеспечивающая надежную транспортировку данных между системами и
предоставляющая соответствующий сервис, показана на рисунке в виде поставщика
транспортного сервиса (Transport Service Provider).
Прикладной агент - некоторая вспомогательная сущность (не стандартизуемая в модели
OSI RM), обеспечивающая связь элементов открытой системы с локальными ресурсами и
сущностями реальной открытой системы.
Сокращение LSE (Local System Environment) используется для обозначения части
открытой реальной системы, не принадлежащей OSIE.
Рис.8.2. Взаимосвязь элементов эталонной модели OSI RM
28
Многоуровневая архитектура OSI RM и принципы ее
функционирования
Проблема взаимосвязи открытых систем чрезвычайно сложна. Она охватывает весь
спектр механизмов взаимосвязи распределенных сущностей, включая как обмены
данными на физическом уровне, так и обмены информацией между прикладными
процессами. Для того, чтобы справиться с этой сложностью в основу построения
функциональной архитектуры OSI RM положен принцип иерархической декомпозиции.
Т.е. все функции взаимосвязи разбиты на отдельные уровни, таким образом, чтобы
сгруппировать в рамках одного уровня логически тесно связанные функции и
минимизировать, тем самым, межуровневые взаимодействия. При этом также достигается
взаимная независимость реализаций уровней друг от друга при сохранении неизменности
межуровневых интерфейсов.
Принцип разбиения на уровни (layers) функциональной среды открытых систем в
модели OSI RM иллюстрируется на рис.8.3.
Рис. 8.3. Разбиение на уровни функциональной среды открытых систем
Для описания поуровневой архитектуры функциональной среды OSI RM вводятся
следующие определения:
(N)-подсистема ((N)-subsystem): элемент иерархической структуры открытой системы,
выполняющий функции взаимосвязи, соответствующие уровню (N), и
взаимодействующий с элементами данной системы, относящимися к непосредственно
29
более высокому или более низкому уровням (каждая открытая система имеет одну и
только одну (N)-подсистему).
Заметим, что (N)-подсистема может состоять из одной или нескольких сущностей.
(N)-уровень ((N)-layer): подмножество архитектуры OSI RM, образованное всеми (N)подсистемами, т.е. подсистемами одного и того же (N)-уровня (допускается
подразделение уровня на подуровни).
(N)-сущность ((N)-entity): некоторый активный элемент внутри некоторой (N)подсистемы, обладающий некоторым набором функциональных возможностей,
определенных для (N)-уровня и соответствующих конкретному типу (N)-сущностей.
Тип (N)-сущности ((N)-entity-type): описание класса (N)-сущностей, определяющее их
функциональные возможности в рамках (N)-уровня.
Одноранговые (N)-сущности (peer-(N)-entities): сущности, взаимодействующие в
границах одного и того же (N)-уровня.
(N)-сервис ((N)-service): функциональные возможности (N)-уровня и нижележащих
уровней, которые могут быть предоставлены (N+1)-сущности на границе между (N)уровнем и (N+1)-уровнем.
(N)-средство ((N)-facility): некоторая часть (N)-сервиса.
(N)-функция ((N)-function): часть активности (N)-сущности (возможные действия (N)сущности, в том числе по реализации некоторого (N)-сервиса).
(N)-точка доступа к сервису ((N)-service-access-point или (N)-SAP): точка, в которой (N)сущность предоставляет (N)-сервис (N+1)-сущности.
По существу (N)-SAP - это порты, через которые сущности (N)- и (N+1)-уровней
обмениваются управляющей информацией и данными на границе между ними.
(N)-протокол ((N)-protocol): набор правил поведения (N)-сущностей и форматов
обмениваемых данных, определяющих взаимосвязь (N)-сущностей при выполнении ими
(N)-функций.
Активация (экземпляр, вызов) (N)-сущности ((N)-entity-invocation): конкретное
использование части или всех функциональных возможностей данной (N)-сущности.
(N)-соединение ((N)-connection): связь, устанавливаемая (N)-уровнем между двумя или
более (N+1)-сущностями для передачи данных между ними.
Поставщик (N)-сервиса или (N)-поставщик сервиса ((N)-service provider): одна или
несколько (N)-сущностей, которые обеспечивают реализацию некоторого (N)-сервиса для
(N+1)-сущности.
Как видно из введенных выше определений в модели OSI RM существенным является
различие между понятиями типа сущности и активации сущности. Под типом понимается
описание класса сущностей, т.е. описание функциональности сущностей данного класса, а
30
под активацией сущности понимается случай конкретного использования этой
функциональности в конкретный момент времени в конкретном контексте.
Заметим, что реальная связь и обмен данными происходят между активациями
(экземплярами, вызовами) сущностей, а не между их типами. Однако с целью упрощения
изложения при описании функционирования рассматриваемой модели мы иногда можем
говорить о взаимосвязи просто сущностей, понимая под этим взаимодействия,
происходящие между их некоторыми активациями.
На рис.8.4. иллюстрируется взаимосвязь введенных выше понятий.
Рис.8.4. Взаимосвязь основных понятий для описания принципа поуровнего представления OSIE
Таким образом, разработанный в рамках эталонной модели механизм поуровневой
декомпозиции взаимосвязи систем позволяет представить любую функцию взаимосвязи в
виде декомпозиции унифицированных горизонтальных и вертикальных взаимодействий
(N)-сущностей в функциональной среде OSIE.
Правила горизонтальных взаимодействий (N)-сущностей на (N)-уровне называются (N)протоколом. Для взаимосвязи между (N)-сущностями может быть определено несколько
(N)-протоколов. Каждый (N)-протокол определяет синтаксис и семантику взаимодействия
(N)-сущностей. Реализуется такое взаимодействие посредством обмена так называемыми
(N)-протокольными блоками данных между (N)-сущностями, для чего может
потребоваться (N-1)-соединение. Описание (N)-протокола определяет форматы блоков
данных, обмениваемых между (N)-сущностями, включая назначение и свойства
31
отдельных полей блоков данных, а также определяет временное и логическое
упорядочивание обмениваемых по протоколу данных.
Протокольное взаимодействие сущностей, принадлежащих любому уровню, за
исключением самого нижнего, является логическим или виртуальным, так как каждый акт
взаимосвязи между такими (N)-сущностями реализуется посредством обращения к
некоторому сервису, предоставляемому нижележащим (N-1)-уровнем.
Вертикальные взаимодействия (N+1)- и (N)-сущностей в среде OSIE, осуществляемые
на границах (N)-подсистем, реализуют отображение (N+1)-протокольных блоков данных,
передаваемых по (N+1)-протоколу, в (N)-протокольные блоки данных некоторого (N)протокола. Такое отображение, как будет показано ниже, реализуется с помощью
механизма (N)-сервисных блоков данных, проходящих без изменения через границу (N)уровня как в системе, являющейся источником блока данных, так и в системе-получателе.
Это позволяет использовать функциональные возможности (N)-уровня, т.е. (N)-сервис,
для реализации функций (N+1)-уровня.
Модель OSI RM строится таким образом, что для самого высокого уровня в архитектуре
OSI RM не существует обслуживаемых им сущностей еще более высокого уровня, т.е.
предоставление услуг прикладным процессам осуществляется в рамках наивысшего
уровня модели OSI RM, а не на его границе, как это определено для всех других уровней.
Другой особенностью модели OSI RM является то, что для самого нижнего уровня не
существует обслуживающих его (N-1)-сущностей, так как подразумевается, что между
(N)-сущностями самого нижнего уровня существует непосредственная связь через
физическую среду OSI.
Рассмотрим общую схему функционирования описанной выше поуровневой
архитектуры функциональной среды взаимосвязи открытых систем модели OSI RM.
В процессе выполнения активации (N+1)-сущности она может через одну или
несколько (N)-SAP запросить некоторый (N)-сервис, как, например, установление (N)соединения с другой (N+1)-сущностью для обмена с ней данными. В этом случае
связанная с (N)-SAP (N)-сущность должна предпринять попытку с помощью некоторой
(N)-функции реализовать запрашиваемый (N)-сервис. Если данный (N)-сервис может быть
реализован только совокупностью (N)-сущностью, то для обеспечения их совместной
работы в свою очередь потребуется использование некоторого (N-1)-сервиса (как
отмечалось выше, это верно для всех (N)-уровней, за исключением низшего уровня).
В итоге (N)-сущности, принадлежащие высшему уровню архитектурной иерархии
модели OSI RM, непосредственно (т.е. в границах высшего уровня, а не на его внешней
границе) предоставляют прикладным процессам (точнее, их активациям) полный набор
функциональных возможностей, обеспечиваемый всеми уровнями модели OSI RM.
Обмен данными между (N+1)-сущностями может осуществляться двумя способами:
1) посредством передачи (односторонней, попеременной, двусторонней) блоков данных
через границу с (N)-уровнем (через некоторую точку (N)-SAP) по (N)-соединению или
2) посредством передачи для сущности, являющейся объектом назначения, через
некоторую точку (N)-SAP независимого функционально самодостаточного блока данных
32
или датаграммы (datagram), который должен быть доставлен адресату без установления
(N)-соединения.
Как отмечалось, правила обмена данными (порядок, форматы, синхронизация) между
(N)-сущностями регламентируются (N)-протоколом. При этом взаимодействие между (N)подсистемами может осуществляться по нескольким (N)-протоколам.
В случае отсутствия (N)-протокола для непосредственного взаимодействия между (N)сущностями, возможно использование (N)-сущности (посредника), с которой у исходных
сущностей имеется непосредственная связь с помощью соответствующих (N)-протоколов
и которая может выполнять функцию ретрансляции одних правил обмена в другие.
Заметим, что не все открытые системы являются источниками и потребителями
передаваемой информации (например, промежуточные узлы подсетей связи). Такие
отрытые системы называются ретрансляторами (relay-системами). В этом случае они
могут не включать некоторые верхние уровни архитектуры модели OSI RM.
Также отметим, что в модели OSI RM проводится четкое разделение между такими
фундаментальными понятиями как сервис (service), интерфейс (interface) и протокол
(protocol). Сервис определяет функциональность соответствующего уровня модели.
Интерфейс определяет способ взаимодействия сущностей, принадлежащих двум смежным
уровням одной открытой системы. Протокол отражает логику и форматы взаимодействия
одноранговых (одноуровневых) сущностей при реализации ими (N)-сервиса. В модели
OSI RM предполагается стандартизация спецификаций только сервисов и протоколов.
Интерфейсы рассматриваются как сущности потенциально зависимые от методов
реализации.
Состав и назначение уровней архитектуры модели OSI RM
В результате систематического проектирования архитектуры для среды взаимосвязи
открытых систем была определена семиуровневая модель архитектуры OSI RM,
включающая следующие уровни:

Прикладной (Application - A) - уровень 7;

Представительный (Presentation - P) - уровень 6;

Сеансовый (Session - S) - уровень 5;

Транспортный (Transport - T) - уровень 4;

Сетевой (Network - N) - уровень 3;

Канальный или звена данных (Data Link - DL) - уровень 2;

Физический (Physical - Ph) - уровень 1.
С учетом этого архитектура модели OSI для оконечных открытых систем принимает
вид, показанный на рис.8.5.
33
Рис.8.5. Семиуровневая архитектура взаимосвязи открытых систем OSI RM
Таким образом, самым верхним уровнем является прикладной уровень, который
состоит из прикладных сущностей, а нижележащие уровни представляют услуги этим
прикладным сущностям, посредством которых и осуществляется взаимодействие между
прикладными сущностями.
Как уже отмечалось выше, не все открытые системы являются оконечными, т.е.
источниками и потребителями передаваемой информации (например, промежуточные
узлы подсетей связи или ретрансляторы (relay systems)). Такие системы могут не
использовать верхние уровни архитектуры модели OSI RM. В частности, для открытых
систем-ретрансляторов сетевого уровня, называемых также маршрутизаторами,
архитектура модели OSI RM будет иметь вид, показанный на рис. 8.6.
Рис.8.6. Архитектура взаимосвязи открытых систем OSI RM в случае использования сетевых
маршрутизаторов
Рассмотрим назначение уровней эталонной модели.
Прикладной уровень (Application Layer - A)
34
Данный уровень отвечает за доступ прикладных процессов к среде OSIE для
обеспечения их взаимодействия при решении совместных задач. В частности, в его задачу
входит установление прикладной ассоциации (связи) между взаимодействующими
прикладными процессами и согласование прикладного контекста, определяющего единые
для взаимодействующих объектов условия взаимосвязи (функциональность, режимы и
параметры работы, способы представления информации). Также он предоставляет
прикладным процессам высокоуровневые сетевые сервисы общего назначения такие, как,
например, электронная почта, передача файлов, функции сетевого справочника.
Представительный уровень (Presentation - P)
Назначением представительного уровня является обеспечение независимости
прикладных взаимодействующих сущностей (A-entities) от использования конкретного
синтаксиса (кодирования) передаваемой информации.
Таким образом, на этом уровне решается проблема представления данных, подлежащих
передаче между прикладными сущностями, а именно представление структур данных,
которыми прикладные сущности обмениваются.
Представительный уровень имеет дело с синтаксисом, т.е. с представлением данных, а
не с их семантикой, известной только прикладным сущностям. Представление данных с
помощью общего синтаксиса освобождает прикладные сущности от необходимости
заботиться о проблеме унифицированного представления информации. Таким образом,
обеспечивается независимость прикладных сущностей от синтаксиса представления
прикладных данных, благодаря чему прикладные сущности могут использовать любой
локальный синтаксис, а представительный уровень выполняет необходимые
преобразования между этими синтаксисами и общим синтаксисом.
Функции представительного уровня включают: запрос на установление сеансового
соединения и его разъединение (в случае режима обмена с соединением), передачу
данных, согласование и пересогласование выбора синтаксиса, преобразование
синтаксисов, кодирование структур данных в битовые представления и декодирование из
битовых представлений в структуры данных в заданном синтаксисе, специальные
преобразования (например, сжатие и шифрация передаваемых данных).
Поясним некоторые функции, связанные с синтаксическим представлением данных и
манипулированием синтаксисом представления.
Имеются три возможных синтаксиса данных:

синтаксис, используемый прикладной сущностью-отправителем,

синтаксис, используемый прикладной сущностью-получателем и

синтаксис, используемый между представительными сущностями (синтаксис передачи).
Два из них или даже все три синтаксиса могут быть идентичными. Представительный
уровень содержит функции, необходимые для выполнения преобразования между
синтаксисом передачи и каждым из остальных двух локальных синтаксисов по мере
необходимости.
35
Для ISOE не вводится единого заранее установленного синтаксиса передачи. Синтаксис
передачи, который будет использоваться для конкретного представительного соединения,
может определяться динамически в процессе согласования между сущностямикорреспондентами представительного уровня. Таким образом, сущность
представительного уровня (или просто представительная сущность - P-entity) должна
знать синтаксис своего пользователя и оговоренный синтаксис передачи, идентификатор
которого используется в протоколах представительного уровня.
Согласование синтаксиса осуществляется посредством диалога между
представительными сущностями. В процессе согласования определяется, какие
преобразования необходимо выполнить (если такая необходимость имеется) и где они
должны выполняться в процессе сеанса.
В заключение еще раз отметим, что представительный уровень несет ответственность за
согласование синтаксисов представления данных, которыми обмениваются прикладные
сущности, а также за некоторые другие функции преобразования передаваемых данных.
Собственно сервис передачи данных по представительному соединению не добавляет
ничего нового по сравнению с возможностями сеансового соединения. Поэтому можно
считать, что этот сервис просто отображается на соответствующий сервис сеансового
уровня.
Сеансовый уровень (Session - S)
Назначение данного уровня состоит в обеспечении сервиса, необходимого
взаимодействующим представительным сущностям (P-entities) для организации,
структуризации и синхронизации их диалога и управления обменом данными. Его также
называют сервисом управляемой надежной сквозной (т.е. осуществляемой между
оконечными открытыми системами) передачи данных.
Сеансовый уровень предоставляет услуги по установлению сеансового соединения
между двумя представительными сущностями и поддержания упорядоченного
взаимодействия при обмене данными между ними по этому соединению. Для
осуществления передачи данных между представительными сущностями сеансовое
соединение отображается на транспортное соединение. Сеансовое соединение существует
до тех пор, пока не будет расторгнуто представительными или сеансовыми сущностями.
Оно расширяет функциональные возможности услуг транспортного уровня для режима
обмена с соединением. Для режима бес соединения услуги сеансового уровня
непосредственно отображаются на соответствующий сервис транспортного уровня.
Функции сеансового уровня сводятся к установлению и расторжению сеансового
соединения; обмену нормальными и срочными данными; управлению взаимодействием;
синхронизации сеанса; восстановлению сеанса.
Транспортный уровень (Transport - T)
Транспортный сервис обеспечивает прозрачную передачу данных между сеансовыми
сущностями (S-entities) оконечных систем, осуществляет оптимизацию использования
сетевых ресурсов, а также обеспечивает надежную передачу данных. Реализует сквозную
межконцевую передачу данных, где концами являются оконечные (т.е. не являющиеся
ретрасляторами подсети связи) открытые систем, содержащие взаимодействующие
36
транспортные сущности-корреспонденты, поэтому транспортные протоколы
используются только между оконечными открытыми системами.
Поскольку сетевой уровень обеспечивает сетевые соединения между любыми двумя
транспортным сущностями, включая случай использования подсетей, соединенных
последовательно, транспортный уровень освобождается от необходимости заниматься
маршрутизацией и ретрансляцией.
Транспортные функции, используемые для обеспечения запрашиваемого качества
сервиса, зависят от предоставляемого сетевого сервиса. Основными функциями данного
уровня являются: отображение транспортного адреса на сетевой адрес;
мультиплексирование и расщепление транспортных соединений на сетевые соединения;
установление и расторжение транспортных соединений; управление потоком на
отдельных соединениях; обнаружение ошибок и контроль качества обслуживания;
исправление ошибок; сегментирование, блокирование и сцепление блоков данных;
передача срочных транспортных блоков данных.
Сетевой уровень (Network - N)
Данный уровень обеспечивает установление, поддержание и разъединение сетевых
соединений между транспортными сущностями (Т-entities) и обмен данными (пакетами)
между ними. Важнейшей его задачей является прокладка оптимальных маршрутов для
передачи пакетов данных через топологию подсетей связи. Основными функциями
данного уровня являются: маршрутизация и ретрансляция, организация сетевых
соединений, мультиплексирование N-соединений на D-соединения, сегментирование и
блокирование пакетов, обнаружение и исправление ошибок, организация
последовательности (упорядоченности передачи пакетов), управление потоком, передача
нормальных и срочных данных, возврат в исходное состояние.
Канальный уровень (Data Link - DL или D)
Канальный сервис обеспечивает надежную передачу массивов (кадров) данных между
сетевыми сущностями (N-entities) открытых системам, которые непосредственно связаны
некоторой физической средой передачи данных. На этом уровне выполняются следующие
функции: установление и расторжение D-соединений, расщепление D-соединений на
несколько соединений физического уровня, управление последовательностью кадров,
управление потоком, управление соединениями физического уровня.
Физический уровень (Physical - Ph)
Данный уровень обеспечивает механические, электрические, функциональные и
процедурные средства активации, поддержания и деактивации физических соединений
для передачи потоков бит между канальными сущностями (D-entities).
Подводя итог рассмотрению функциональности уровней архитектуры эталонной
модели OSI RM, отметим, что нижние три уровня OSI RM предназначены для
предоставления услуги, связанных с передачей данных в сети. Четвертый, транспортный
уровень соответствует сквозной передаче данных между оконечными открытыми
системами. Верхние три уровня предназначены для организации взаимодействия
распределенных прикладных процессов обработки информации.
37
В заключение отметим, что модель OSI RM разработана в духе объектноориентированного подхода. В частности, возможна интерпретация OSI RM, в которой
роль классов отводится уровням эталонной модели, а роль методов классов выполняют их
сервисы, определяющие функциональность данных уровней.
Заключение
Как и в предыдущих главах сформулируем ключевые положения рассмотренного в
главе материала, что может оказаться полезным для систематизации и самоконтроля
знаний.
В данной главе была проделана следующая работа:
1). Отмечена необходимость стандартизации функций информационного обмена между
вычислительными системами для построения компьютерных сетей, обширность
сформировавшейся в этой области системы стандартов. Определены уровни
стандартизации средств информационного обмена между системами, включающие:
концептуальный уровень - уровень спецификации эталонной модель взаимосвязи
открытых систем OSI RM, уровень спецификации сервиса (сетевых услуг), а также
уровень описания протоколов информационного обмена между функциональными
элементами эталонной модели.
2). Определено назначение эталонной модели OSI RM в системе стандартов сетевых
технологий. Определен набор документов, составляющих описание основной понятийной
и архитектурной части модели OSI RM, а также определен ряд других стандартов,
непосредственно дополняющих описание эталонной модели.
3). Рассмотрены определения основных элементов эталонной модели таких, как: реальная
система, реальная открытая система, открытая система, прикладной процесс, окружение
взаимосвязи открытых систем или OSI-окружение, активация прикладного процесса, тип
прикладного процесса, прикладная сущность, ассоциация, физическая среда OSI.
Показана взаимосвязь этих понятий.
4). Рассмотрены принципы построения и функционирования многоуровневой архитектуры
OSI RM. Определена система понятий (N)-концепции, предназначенной для описания
элементов и функционирования многоуровневой архитектуры OSI RM и включающей
следующие понятия: (N)-подсистема, (N)-уровень, тип (N)-сущности, одноранговые (N)сущности, (N)-сервис, (N)-средство, (N)-функция, (N)-точка доступа к сервису, (N)протокол, (N)-соединение, поставщик (N)-сервиса. Показана взаимосвязь этих понятий.
5). Рассмотрены состав и назначение уровней архитектуры модели OSI RM, включающей
следующие уровни протоколов: прикладной, представительный, сеансовый,
транспортный, сетевой, канальный, физический. Рассмотрено назначение и функции этих
уровней.
38
4. Устройства сопряжения локальных сетей: концентраторы, мосты,
коммутаторы.
Разрешение
неоднозначности
маршрутов
при
коммутации. Понятие виртуальной локальной сети (VLAN).
3. Сетевое оборудование
3.1. Повторитель (концентратор, hub)
В начале 80-х годов сети Ethernet организовывались на базе шинной
топологии с
использованием сегментов на основе коаксиального кабеля. С увеличением
длины кабеля,
39
соединяющего компьютеры, усиливается затухание сигнала в кабеле,
поэтому максимальная длина кабеля соединяющего компьютеры в сети не может превышать 500
метров для
толстого жесткого коаксиального кабеля и 185 метров для тонкого кабеля
Ethernet. Таким
образом, максимально возможная общая длина всех кабелей сети – 500
метров. Для преодоления 500-метрового барьера используют повторители (repeater).
Повторитель просто
по битам копирует (пересылает) все пакеты Ethernet из одного сегмента сети
во все другие, подключенные к нему (см. рис.3.1).
Рис.3.1. Двухпортовый повторитель (схема).
Повторитель работает на физическом уровне модели OSI. Основной задачей
повторителя является восстановление электрических сигналов для передачи их в
другие сегменты. За счет усиления и восстановления формы электрических сигналов
повторителем, становится возможным расширение сетей, построенных на основе
коаксиального кабеля и
увеличение общего числа пользователей сети.
Повторители бывают 2-х и многопортовыми. Двухпортовые повторители (см.
рис.
3.1) используются в сетях с шинной топологией, построенных на
коаксиальном кабеле.
Многопортовые повторители используются в сетях с топологией типа
"звезда" (кабель
"витая пара"). И 2-х и многопортовые повторители, получив пакет на один из
своих
портов, просто передает его во все остальные порты.
Многопортовые повторители, в сетях построенных на кабеле "витая пара",
часто
называют концентраторами или хабами (Hub). Хабы нужны даже не столько
для усиления
сигнала, как для соединения в сеть более чем двух компьютеров, т.к. кабель
"витая пара"
позволяет напрямую соединить только два компьютера. Если же необходимо
соединить
40
три компьютера, то каждый из них напрямую подключается к хабу, который
и ретранслирует сигнал, полученный от одного компьютера на все остальные порты, к
которым
подключены другие компьютеры (см. рис. 3.2 и 3.3).
Рис. 3.2 Многопортовый повторитель (Hub) – схема
подключения компьютеров по
топологии "звезда".
Рис.3.3. Концентратор (hub) – внешний вид (схема).
Различия в моделях концентраторов при выполнении основной функции
(побитное
дублирование сигнала на все порты) невелики и, в основном, зависит от типа
кабеля
(витая пара, оптоволоконный и т.п.). Однако различные модели
концентраторы могут
реализовывать и дополнительные функции, некоторые из которых
рассмотрены ниже.
Отключение портов
Концентраторы способны отключать некорректно работающие порты,
изолируя
тем самым остальную часть сети от возникших в узле проблем. Эту функцию
называют
автосегментацией (autopartitioning). Отключение происходит при отсутствии
ответа на
41
последовательность импульсов link test (проверка связи), посылаемых во все
порты каждые 16 мс. В этом случае неисправный порт переводится в состояние
"отключен", но
импульсы link test будут продолжать посылаться в порт с тем, чтобы при
восстановлении
устройства работа с ним была продолжена автоматически. Отключение порта
может
произойти и по другим причинам:
• Ошибки на уровне кадра. Если интенсивность прохождения через порт
кадров, имеющих ошибки, превышает заданный порог, то порт отключается, а затем, при
отсутствии
ошибок в течение заданного времени, включается снова. Такими ошибками
могут быть:
неверная контрольная сумм, неверная длина кадра (больше 1518 байт или
меньше 64
байт), неоформленный заголовок кадра.
• Множественные коллизии. Если концентратор фиксирует, что источником
коллизии
был один и тот же порт 60 раз подряд, то порт отключается. Через некоторое
время порт
снова будет включен.
• Затянувшаяся передача (jabber). Если время прохождения одного кадра
через порт
превышает время передачи кадра максимальной длины в 3 раза, то порт
отключается.
Поддержка резервных связей
Так как использование резервных связей в концентраторах определено
только в
стандарте FDDI, то для остальных стандартов разработчики концентраторов
поддерживают эту функцию с помощью своих частных решений. Например, в
концентраторах
Ethernet/Fast Ethernet резервные связи всегда должны соединять
отключенные порты,
чтобы не нарушать логику работы сети. При конфигурировании
концентратора администратор должен определить, какие порты являются основными, а какие по
отношению к ним
42
— резервными. Если по какой-либо причине порт отключается (срабатывает
механизм
автосегментации), концентратор делает активным его резервный порт. В
некоторых моделях концентраторов разрешается использовать механизм назначения
резервных портов
только для оптоволоконных портов, считая, что нужно резервировать только
наиболее
важные связи, которые обычно выполняются на оптическом кабеле.
Защита от несанкционированного доступа
Общая разделяемая среда предоставляет очень удобную возможность для
несанкционированного прослушивания сети и получения доступа к передаваемым
данным. Для
этого достаточно подключить компьютер с программным анализатором
протоколов
(сниффером - sniffer) к свободному разъему концентратора, записать на диск
все проходящие по сети кадры, а затем выделить из них нужную информацию.
Разработчики концентраторов предоставляют различные способы защиты
данных в
разделяемых средах. Наиболее простой способ защиты заключается в том,
что администратор вручную связывает с каждым портом концентратора некоторый MACадрес. Этот
МАС-адрес является адресом сетевой карты компьютера, которому
разрешено подключаться к данному порту. Например, на рис.3.4. [1] первому порту
концентратора назначен
МАС-адрес 01:23 (условная запись). Компьютер с МАС-адресом сетевой
карты 01:23
нормально работает с сетью через данный порт. Если злоумышленник
отсоединяет этот
компьютер и присоединяет вместо него свой, концентратор заметит, что при
старте
нового компьютера в сеть начали поступать кадры с адресом источника
07:89. Так как
этот адрес является недопустимым для первого порта, то эти кадры
фильтруются, порт
отключается, а факт нарушения прав доступа может быть зафиксирован.
43
Рис.
3.4.
Защита от несанкционированного подключения к портам концентратора.
Другим способом защиты данных является случайное искажение данных в
кадрах,
передаваемых портам с адресом, отличным от адреса назначения пакета. При
этом методе
каждому порту концентратора также ставится в соответствие некоторый
MAC-адрес
сетевой карты. Кадр, поступивший на концентратор, дублируется на все
порты, как этого
и требует стандарт. При этом заголовки сдублированных кадров остаются
неизменными, а
в поле данных кадров помещаются нули. Полезные данные сохраняются
только в поле
данных кадра, направленного на порт, к которому подключен компьютерадресат. Этот
метод сохраняет логику случайного доступа к среде, так как все компьютеры
видят, что
сеть занята кадром, предназначенным одному из них (заголовок кадра не
заполняется
нулями), но только станция, которой послан этот кадр, может понять
содержание поля
данных кадра (см. рис.3.5) [1].
44
Рис.3.5. Искажение поля
данных в кадрах, не предназначенных для приема станциями
Для реализации описанных выше методов защиты концентратор нужно
предварительно сконфигурировать. Для этого концентратор должен иметь блок
управления.
Концентраторы,
имеющие
блок
управления,
обычно
называют
интеллектуальными (smarthub).
Блок управления представляет собой компактный вычислительный блок со
встроенным программным обеспечением. Для взаимодействия администратора с
блоком управления концентратор имеет консольный порт (чаще всего RS-232), к которому
подключается терминал или персональный компьютер с программой эмуляции
терминала. При присоединении терминала блок управления выдает на экран некоторое меню, с
помощью
которого администратор выбирает нужное действие и конфигурирует
концентратор.
Многосегментные концентраторы
Многосегментные концентраторы обычно имеют большое количество портов
(например, 72 или 240). Очевидно, что разделять среду передачи данных между
таким количеством компьютеров нерационально. Поэтому в таких концентраторах
имеется несколь45
ко несвязанных внутренних шин передачи данных, которые предназначены
для создания
нескольких разделяемых сред. Например, концентратор, изображенный на
рис.3.6, имеет
три внутренние шины Ethernet. Первые два компьютера связаны с шиной
Ethernet 3, а
третий и четвертый компьютеры — с шиной Ethernet 1. Первые два
компьютера образуют
один разделяемый сегмент, а третий и четвертый — другой разделяемый
сегмент.
Рис.3.6.
Многосегментный концентратор.
Между собой компьютеры, подключенные к разным сегментам, общаться
через
концентратор не могут, так как шины внутри концентратора никак не
связаны. Для объединения сегментов необходимо использовать дополнительные сетевые
устройства (мосты,
коммутаторы, маршрутизаторы – см. дальше в лекциях).Многосегментные
концентраторы
нужны для создания разделяемых сегментов, состав которых может легко
изменяться.
Большинство многосегментных концентраторов, например System 5000
компании Nortel
Networks или PortSwitch Hub компании 3Com, позволяют выполнять
операцию соединения порта с одной из внутренних шин чисто программным способом,
например с помощью локального конфигурирования через консольный порт. В результате
администратор
46
сети может присоединять компьютеры пользователей к любым портам
концентратора, а
затем с помощью программы конфигурирования концентратора управлять
составом каждого сегмента. Если завтра сегмент Ethernet1 станет перегруженным, то его
компьютеры
можно распределить между оставшимися сегментами концентратора.
Возможность многосегментного концентратора программно изменять связи портов с
внутренними шинами
называется конфигурационной коммутацией (configuration switching).
Управление концентратором по протоколу SNMP
Как видно из описания дополнительных функций, многие из них требуют
конфигурирования концентратора. Это конфигурирование может производиться
локально, путем
подключения персонального компьютера или терминала к концентратору
через интерфейс
RS-232C, однако при большом количестве концентраторов в сети это
становится неудобным.
Поэтому
большинство
концентраторов,
поддерживающих
интеллектуальные дополнительные функции, могут управляться централизованно по сети с помощью
протокола
управления сетью SNMP (Simple Network Management Protocol) из стека
TCP/IP.
В блок управления концентратором встраивается так называемый SNMPагент,
который имеет свой MAC- и IP-адрес. SNMP-агент собирает информацию о
состоянии
концентратора и хранит ее в базе данных управляющей информации —
Management Information
Base (MIB) – блока управления, которая позволяет одному из компьютеров
сети,
выполняющему роль центральной станции управления, запрашивать у
SNMP-агента
значения стандартных переменных базы MIB. В переменных хранятся не
только данные о
состоянии концентратора, но и управляющая информация, воздействующая
на него.
47
Например, в MIB есть переменная, управляющая состоянием порта
("включить" –
"выключить").
Конструктивное исполнение концентраторов
По
конструктивным
особенностям
выделяют
следующие
типы
концентраторов:
- концентраторы с фиксированным количеством портов
- модульные концентраторы
- стековые концентраторы
- модульно-стековые концентраторы
Концентратор с фиксированным количеством портов — это наиболее
простое
конструктивное исполнение, когда устройство представляет собой отдельный
корпус со
всеми необходимыми элементами (портами, органами индикации и
управления, блоком
питания), и эти элементы заменять нельзя. Обычно общее количество портов
изменяется
от 4-8 до 24. Один порт может быть специально выделен для подключения
концентратора
к другому концентратору или иметь кнопочный переключатель,
позволяющий подключать к этому порту как обычный компьютер (маркировка MDI-X), так и
другой концентратор (маркировка MDI). Концентратор также может иметь разъем AUI для
соединения
(при помощи трансивера) с толстым коаксиальным кабелем, концентратором
оптоволоконных сетей или другим концентратором "витая пара".
Модульный концентратор выполняется в виде отдельных модулей с
фиксированным количеством портов, устанавливаемых на общее шасси. Шасси имеет
внутреннюю шину для объединения отдельных модулей в единый повторитель.
Часто такие
концентраторы являются многосегментными, тогда в пределах одного
модульного
концентратора работает несколько несвязанных между собой повторителей.
Агент
протокола SNMP обычно выполняется в виде отдельного модуля, при
установке которого
48
концентратор превращается в интеллектуальное устройство. Модульные
снабжаются
системой терморегулирования, избыточными источниками питания,
позволяют осуществлять замену модулей без отключения питания и дают возможность быстро и
гибко
реагировать на изменения конфигурации сети. Недостатком модульных
концентраторов
на основе шасси является высокая начальная стоимость такого устройства,
т.к. даже если
установлено всего 1-2 модуля, концентратор поставляется вместе со всеми
общими
устройствами (избыточные источники питания и т. п). Поэтому для сетей
средних
размеров большую популярность завоевали стековые концентраторы.
Стековый концентратор, как и концентратор с фиксированным числом
портов,
выполнен в виде отдельного корпуса с фиксированным количеством портов.
Однако
стековыми эти концентраторы называются не потому, что они
устанавливаются один на
другой, в общую стойку. Стековые концентраторы имеют специальные
порты и кабели
для объединения нескольких корпусов в единый повторитель, который имеет
общий блок
повторения и, с точки зрения правила 4-х хабов, считается одним
повторителем. Число
объединяемых в стек корпусов может быть достаточно большим (обычно до
8, но бывает
и больше). Выгодной чертой стековых концентраторов является их более
низкая
стоимость, так как сначала предприятие может купить одно устройство без
избыточного
шасси, а потом нарастить стек еще несколькими аналогичными
устройствами.
Модульно-стековые концентраторы представляют собой модульные
концентраторы, объединенные специальными кабелями в стек. Как правило, корпуса
таких концентраторов рассчитаны на небольшое количество модулей (1-3). Эти
концентраторы сочетают
49
достоинства концентраторов обоих типов.
3.2. Мост (bridge)
Повторители, за счет усиления и восстановления формы электрических
сигналов,
позволяют увеличить протяженность сети, однако и здесь есть ограничения:
из-за задержки приема-передачи сигнала в повторителе, между любыми двумя
компьютерами в сети
Ethernet не может быть более 4-х повторителей, а в сети Fast Ethernet – не
более одного
повторителя 1-го класса и не более двух повторителей 2-го класса (подробнее
см. далее в
лекциях). Поэтому для создания более протяженных сетей необходимо
пользоваться
дополнительными сетевыми устройствами – мостами (bridge).
Мосты позволяют преодолеть ограничение "не более четырех повторителей
между
любыми двумя компьютерами" за счет того, что работают не на физическом,
а на канальном уровне модели OSI. Т.е. мост ретранслирует кадр не по битам, а
полностью принимает кадр в свой буфер, заново получает доступ к разделяемой среде и
ретранслирует
кадр в сеть. Помимо увеличения протяженности сети, мост также позволяет
разбить ее на
сегменты с независимыми разделяемыми средами, увеличив общую
пропускную способность сети. Поясним на примере: пусть имеется три повторителя (хаба), к
каждому из
которых, при помощи кабеля "витая пара", подключено по четыре
компьютера (см.
рис.3.7).
50
Рис.3.7. Пояснение алгоритма работы моста
Повторители соединены между собой при помощи моста. Допустим
компьютер K1
передает в сеть кадр сообщения для компьютера K4. Кадр сообщения по
кабелю попадет
на повторитель1, который сдублирует его на все свои порты, т.е. кадр
сообщения получат компьютеры K2, K3, K4 (что и требовалось) и мост. Мост, получив кадр
сообщения от
повторителя, анализирует "адрес получателя", имеющийся в кадре,
определяет что
компьютер K4 относится к сегменту 1 и поэтому кадр сообщения не надо
дублировать для
повторителей 2 и 3 (если бы кадр сообщения относился к компьютеру K5, то
мост передал
бы этот кадр только повторителю 2, ничего не передавая на порт, к которому
подключен
повторитель 3).
Рассмотрим какие выгоды дает такая схема. В момент когда компьютер К1
передает кадр сообщения, ни один из компьютеров K2-K4 не может ничего
передавать в сеть –
сеть "занята". Однако в тот же момент времени компьютеры К5-К12 могут
передавать
51
сообщения друг другу – для них сеть "свободна", т.к. мост не передал кадр
сообщения от
компьютера К1 в их сегменты сети. Таким образом, если файл копируется с
компьютера
K1 на K4 со скоростью 10 Мбит/с, с компьютера К5 на К8 со скоростью 10
Мбит/с, с
компьютера К9 на К11 со скоростью 10 Мбит/с, то суммарная пропускная
способность
сети составляет 30 Мбит/с. Если бы вместо моста в вершине этой схемы
стоял простой
повторитель, то кадр сообщения от компьютера K1 "занял" бы всю сеть, и ни
один из
компьютеров К2-К12 не смог бы в это время передавать в сеть что-либо (без
возникновения коллизии), а пропускная способность сети упала бы до 10 Мбит/с.
Существует два основных алгоритма работы моста: алгоритм прозрачного
моста и
алгоритм моста с маршрутизацией от источника. Алгоритм прозрачного
моста используется в сетях Ethernet, а алгоритм моста с маршрутизацией от источника
может использоваться в сетях Token Ring и FDDI, хотя в этих сетях могут использоваться и
обычные
прозрачные мосты.
Алгоритм работы прозрачного моста.
Мост при таком алгоритме не заметен (прозрачен) для сетевых карт. Сетевая
карта
посылает кадр данных сетевой карте другого компьютера так, как если бы
моста в сети и
не было. Порты моста подключены к соединяемым сегментам сети и не
имеют своих
MAC-адресов, захватывая все проходящие по сети пакеты. Первоначально
мост не знает к
какому порту подключены какие компьютеры (см. рис.3.8). Поэтому, если
компьютер 1
направит кадр компьютеру 2, то мост, захватив этот пакет на порту 1,
сдублирует его на
все остальные порты, т.е. в данном случае на порт 2 (хотя по логике работы
моста этого
делать и не надо, но мост пока не знает к какому сегменту относится
компьютер 2).
52
Одновременно с этим, мост сделает в своей внутренней таблице адресов
запись, что
компьютер 1 относится к сегменту 1 (т.к. кадр от него был захвачен с порта
1), и кадры
для компьютера 1 надо дублировать только на порт 1. Если все четыре
компьютера достаточно активны в сети, то таблица адресов моста заполнится, и он будет
дублировать кадры
только на те порты, на которые это действительно необходимо. Таким
образом, трафик
между компьютерами 1 и 2 будет отделен от трафика между компьютерами 3
и 4, т.е.
кадры от компьютера 1 к компьютеру 2 не будут дублироваться на порт 2.
Рис.3.8. Алгоритм работы прозрачного моста
Каждая автоматически созданная запись о принадлежности компьютера к
сегменту
1 или 2 имеет срок жизни. Если до истечения срока жизни запись не
подтверждалась
кадрами, проходящими по сети, то она помечается как недействительная.
Если, в любой
момент времени, компьютер 1 будет перемещен в сегмент 2 и пакеты от него
станут
поступать на порт 2, то соответствующая запись в таблице будет изменена.
Помимо
динамически создаваемых записей, могут существовать и статические
записи, созданные
53
администратором вручную, при конфигурировании моста, и не имеющие
срока жизни.
При помощи статических записей можно жестко описать принадлежность
компьютера к
тому или иному сегменту, или указать, что пакеты к компьютеру 1 должны
всегда дублироваться на все порты (flood - затопление), а пакеты к компьютеру 2 никогда
не должны
дублироваться ни на какие порты (discard - отбросить).
Алгоритм работы моста с маршрутизацией от источника (SR-мосты).
Этот алгоритм используется в сетях Token Ring и FDDI. Компьютеротправитель
помещает в кадр всю адресную информацию о промежуточных мостах и
кольцах, которые
кадр должен пройти на пути к компьютеру-адресату. Первоначально
компьютер-отправитель не имеет никакой информации о пути к компьютеру адресату. Кадр
просто передается в кольцо, в надежде, что адресат находится в одном кольце с
отправителем. Если компьютер-адресат в кольце отсутствует не так, то кадр сделает оборот по
кольцу и вернется
без установленного признака "кадр получен" (бит "адрес распознан" и бит
"кадр скопирован"). В таком случае компьютер-отправитель пошлет одномаршрутный
широковещательный кадр-исследователь (SRBF, Single Route Brodcast Frame). Этот кадр
распространяется по сети: мосты дублируют кадр на все свои порты, за исключением
заблокированных администратором (для избежания петлевых маршрутов и зацикливания
кадра). В
конце-концов кадр-иследователь будет получен компьютером-адресатом,
который немедленно отправит многомаршрутный широковещательный кадр-исследователь
(ARBF, All
Route Brodcast Frame). Этот кадр распространяется по сети, дублируясь
мостами на все
порты без исключения (для предотвращения зацикливания, кадр-ARBF уже
однажды
54
сдублированный мостом на один из своих портов, заново на этот порт не
дублируется). В
конце-концов, до компьютера-отправителя дойдет множество кадров- ARBF,
прошедших
через все возможные маршруты от компьютера-адресата до компьютераисследователя.
Полученная информация попадет компьютеру-отправителю и в маршрутные
таблицы
моста, соединяющего кольцо компьютера-отправителя с остальной сетью.
Впоследствии
все компьютеры этого кольца могут воспользоваться информацией моста при
отправке
своих кадров.
Ограничения топологии сетей, построенных на прозрачных мостах.
Основным ограничением при использовании мостов является отсутствие
петлевых
маршрутов. Поясним на примере. Пусть имеется сеть, изображенная на
рис.3.9.
Рис.3.9. Ошибки в работе мостов, возникающие при наличии петлеобразных
маршрутов
Пусть новый компьютер с адресом 10 впервые начинает работу в данной
сети.
55
Обычно начало работы любой операционной системы сопровождается
рассылкой широковещательных кадров, в которых компьютер заявляет о своем существовании
и одновременно ищет серверы сети. На этапе 1 компьютер посылает первый кадр с
широковещательным адресом назначения и адресом источника 10 в свой сегмент. Кадр
попадает как в
мост 1, так и в мост 2. В обоих мостах новый адрес источника 10 заносится в
адресную
таблицу с пометкой о его принадлежности сегменту 1, то есть создается
новая запись
вида: МАС-адрес 10 – порт 1. Так как кадр, рассылаемый компьютером,
имеет широковещательный адрес назначения, то каждый мост должен передать кадр на
сегмент 2. Эта
передача происходит поочередно, в соответствии с методом случайного
доступа CSMA/
CD технологии Ethernet. Пусть первым доступ к сегменту 2 получил мост 1
(этап 2). При
ретрансляции мостом 1 кадра в сегмент 2 мост 2 принимает его в свой буфер
и обрабатывает. Он видит, что адрес 10 уже есть в его адресной таблице, но
пришедший кадр
является более свежим, и он утверждает, что адрес 10 принадлежит сегменту
2, а не 1.
Поэтому мост 2 корректирует содержимое базы и делает запись о том, что
адрес 10
принадлежит сегменту 2. Аналогично поступает мост 1, когда мост 2 получит
доступ к
разделяемой среде и передает свою копию широковещательного кадра на
сегмент 2.
Результатом описанной ситуации является следующее:
- Размножение кадра, то есть появление нескольких его копий (в данном
случае —
двух, но если бы сегменты были соединены тремя мостами — то трех и т. д.).
- Бесконечная циркуляция обеих копий кадра по петле в противоположных
направлениях, а значит, засорение сети ненужным трафиком.
- Постоянная перестройка мостами своих адресных таблиц, так как кадр с
адресом
56
источника 10 будет появляться то на одном порту, то на другом.
Чтобы исключить все эти нежелательные эффекты, мосты нужно применять
так,
чтобы между логическими сегментами не было петель, то есть строить с
помощью мостов
только древовидные структуры, гарантирующие наличие только одного пути
между
любыми двумя сегментами. В простых сетях сравнительно легко
гарантировать
существование одного и только одного пути между двумя сегментами. Но
когда
количество соединений возрастает и сеть становится сложной, то
вероятность
непреднамеренного образования петли оказывается высокой. Кроме того,
желательно для
повышения надежности иметь между мостами резервные связи, которые не
участвуют
при нормальной работе основных связей в передаче информационных
пакетов станций,
но при отказе какой-либо основной связи образуют новую связную рабочую
конфигурацию без петель. Поэтому в сложных сетях между логическими
сегментами
прокладывают избыточные связи, которые образуют петли, но для
исключения активных
петель блокируют некоторые порты мостов. Наиболее просто эта задача
решается
вручную, но существуют и алгоритмы, которые позволяют решать ее
автоматически.
Наиболее известным является стандартный алгоритм покрывающего дерева
(Spanning
Tree Algorithm, STA). Кроме того, имеются фирменные алгоритмы,
решающие ту же
задачу, но с некоторыми улучшениями для конкретных моделей мостов и
коммутаторов.
Удаленные мосты
Удаленный мост – это мост, который через один или несколько портов
подключен
к глобальной сети (Internet, X.25, FrameRelay, ATM). Удаленные мосты (а
также удаленные маршрутизаторы) используются для соединения локальных сетей через
глобальные
57
сети. Если в локальных сетях мосты постепенно вытесняются
коммутаторами, то удаленные мосты и сегодня продолжают пользоваться популярностью. Удаленные
мосты не надо
конфигурировать (адресная таблица строится автоматически), а при
объединении с сетью
предприятия сетей филиалов, где нет квалифицированного обслуживающего
персонала,
это свойство оказывается очень полезным.
Как и в локальных сетях, важной характеристикой удаленных мостов
(удаленных
маршрутизаторов) является скорость обработки кадров, которые часто
ограничиваются
не внутренними возможностями устройства, а скоростью передачи данных
по линии
(например, аналоговой телефонной линии). Для преодоления ограничений на
скорость
линии, а также для уменьшения части локального трафика, передаваемого по
глобальной
линии, в удаленных мостах и маршрутизаторах используются специальные
приемы,
отсутствующие в локальных устройствах. Эти приемы не входят в стандарты
протоколов,
но они реализованы практически во всех устройствах, обслуживающих
низкоскоростные
каналы, особенно каналы со скоростями в диапазоне от 9600 бит/с до 64
Кбит/с. К таким
приемам относятся технологии сжатия пакетов, спуфинга и сегментации
пакетов.
Сжатие пакетов (компрессия). Некоторые производители, используя
собственные
алгоритмы, обеспечивают коэффициент сжатия до 8:1. Стандартные
алгоритмы сжатия,
применяемые в модемах, обеспечивают коэффициент сжатия до 4:1. После
сжатия данных для передачи требуется существенно меньшая скорость канала.
Спуфинг (spoofing). Эта технология позволяет значительно повысить
пропускную
способность линий, объединяющих локальные сети, работающие по
протоколам с боль58
шим количеством широковещательных пакетов. Широковещательные пакеты
характерны
для большинства сетевых операционных систем, за исключением ОС Unix,
которая изначально строилась для медленных глобальных линий связи. Главной идеей
спуфинга
является имитация передачи пакета по глобальной сети. Рассмотрим технику
спуфинга на
примере передачи между удаленными сетями пакетов SAP (Service
Advertising Protocol)
сервера ОС NetWare. Эти пакеты каждый сервер генерирует каждую минуту,
чтобы все
клиенты сети могли составить правильное представление об имеющихся в
сети разделяемых ресурсах — файловых службах, службах печати и т. п. SAP-пакеты
распространяются
в IPX-пакетах с широковещательным сетевым адресом. Удаленные мосты
должны передавать широковещательные пакеты на все свои порты (маршрутизаторы не
должны передавать широковещательные пакеты из сети в сеть, но для SAP-пакетов сделано
исключение
— маршрутизатор, поддерживающий IPX, распространяет его на все порты,
кроме того,
на который этот пакет поступил). Таким образом, по выделенной линии
может проходить
достаточно большое количество SAP-пакетов. Если эти пакеты посылаются
каким-либо
сервером, но не доходят до клиентов, то клиенты не могут воспользоваться
службами
этого сервера. Если маршрутизаторы или мосты, объединяющие сети,
поддерживают
технику спуфинга, то они передают по выделенному каналу не каждый SAPпакет, а
например, только каждый пятый. Интенсивность служебного трафика в
глобальном канале при этом уменьшается. Но для того, чтобы клиенты не теряли из списка
ресурсов
удаленной сети серверы, мост (маршрутизатор) имитирует приход этих
пакетов по
59
глобальному каналу, посылая SAP-пакеты от своего имени каждую минуту,
как это и
положено по протоколу. При этом мост (маршрутизатор) посылает несколько
раз копию
реального SAP-пакета, получаемого раз в 5 минут по выделенному каналу.
Сегментация пакетов — позволяет разделять большие передаваемые пакеты
и передавать их сразу через две телефонные линии. Хотя это и не делает
телефонные каналы
более эффективными, но все же увеличивает скорость обмена данными почти
вдвое.
3.3. Коммутатор (switch)
В последнее время наблюдается вытеснение мостов коммутаторы.
Коммутаторы,
как и мосты работают на канальном уровне и позволяют разделить общую
разделяемую
среду на несколько независимых сегментов передачи данных. Алгоритм
работы коммутаторов аналогичен алгоритму работы прозрачного моста. Основным отличием,
обеспечившим вытеснение мостов коммутаторами – это гораздо более высокая
скорость работы
коммутаторов. Мост должен полностью получить кадр данных перед тем, как
ретранслировать его на соответствующий порт. Коммутатор начинает ретрансляцию
кадра, не дожидаясь его полного получения (достаточно получить несколько первых байт
кадра, содержащих адрес назначения). Кроме того, коммутатор позволяет организовать
сразу несколько параллельных соединений между различными парами портов, что
повышает пропускную способность сети в несколько раз. Однако коммутатор не может
организовать
одновременное соединение несколько портов – к одному порту (см. рис.3.10).
Рис.3.10. Параллельные соединения между портами коммутатора
Технология коммутаторов Ethernet была предложена фирмой Kalpana в 1990
году в
ответ на растущие потребности в повышении пропускной способности сетей.
Структурная
60
схема коммутатора EtherSwitch,
представлена ниже (см.
предложенного
фирмой
Kalpana,
рис.3.11).
Рис.3.11. Структурная схема коммутатора
Каждый из 8 портов коммутатора обслуживается собственным процессором
пакетов Ethernet — ЕРР (Ethernet Packet Processor). Кроме того, коммутатор имеет
системный
модуль, который координирует работу всех процессоров ЕРР. Системный
модуль ведет
общую адресную таблицу коммутатора (какие компьютеры подключены к
каким портам)
и обеспечивает управление коммутатором по протоколу SNMP. Для передачи
кадров между портами используется коммутационная матрица, подобная тем, которые
работают в
телефонных коммутаторах или мультипроцессорных компьютерах. При
поступлении
кадра в какой-либо порт, процессор ЕРР буферизует несколько первых байт
кадра, чтобы
прочитать адрес назначения. После получения адреса назначения процессор
сразу же принимает решение о передаче пакета, не дожидаясь прихода остальных байт
кадра. Для
61
этого он просматривает свой собственный кэш адресной таблицы, а если не
находит там
нужного адреса, обращается к системному модулю, который работает в
многозадачном
режиме, параллельно обслуживая запросы всех процессоров ЕРР. Системный
модуль
производит просмотр общей адресной таблицы и возвращает процессору
найденную
строку (адрес компьютера – номер порта), которая запоминается
процессором EPP в своем
кэше для последующего использования. После определения того, к какому
порту подключен сегмент компьютера – адресата, процессор EPP обращается к
коммутационной
матрице и пытается установить соединение с нужным портом. Если порт
занят, то кадр
полностью буферизуется процессором EPP входного порта, после чего
процессор ожидает
освобождения выходного порта. После освобождения, данные передаются на
выходной
порт, который получает доступ к своему сегменту сети по методу CSMA/CD
и передает
кадр данных в свой сегмент.
Типы коммутаторов
По конструктивному исполнению выделяют следующие типы коммутаторов:
- коммутаторы с фиксированным количеством портов
- модульные коммутаторы на основе шасси
- стековые коммутаторы
- модульно-стековые коммутаторы
Различия между этими типами коммутаторов аналогичны различиям между
соответствующими типами концентраторов (см. выше).
По способу коммутации портов в коммутаторе выделяют следующие типы
коммутаторов:
- коммутаторы на основе коммутационной матрицы
- коммутаторы с общей шиной
- коммутаторы с разделяемой памятью
- комбинированные коммутаторы
Коммутаторы на основе коммутационной матрицы обеспечивают основной и
самый
быстрый способ взаимодействия процессоров портов. Однако реализация
матрицы воз62
можна только для определенного числа портов, причем сложность схемы
возрастает
пропорционально квадрату количества портов коммутатора. Чисто условно
коммутационную
матрицу
можно
представить
рисунком
3.12.
Рис.3.12. Условная схема коммутационной матрицы.
Рассмотрим один из вариантов физической реализации коммутационной
матрицы
для 8 портов (см. рис.3.13). Входные блоки процессоров EPP добавляют к
байтам исходного кадра информацию о том на какой из портов его необходимо передать в
виде специального ярлыка — тэга (tag). Для данного примера тэг представляет собой
число их 3-х
бит, соответствующее номеру выходного порта. Матрица состоит из трех
уровней двоичных переключателей, которые соединяют свой вход с одним из двух выходов
в зависимости от значения бита тэга. Переключатели первого уровня управляются
первым битом
63
тэга,
второго
—
вторым,
а
третьего
—
третьим.
Рис.3.13. Реализация коммутационной матрицы 8x8 с помощью двоичных
переключателей.
Основные достоинства таких матриц — высокая скорость коммутации
портов и
регулярная структура, которую удобно реализовывать в интегральных
микросхемах.
Недостатком является сложность наращивания числа портов и отсутствие
буферизации
данных внутри коммутационной матрицы (если порт занят, то данные
должны накапливаться во входном блоке порта, принявшего кадр).
В коммутаторах с общей шиной процессоры портов связаны
высокоскоростной
64
шиной передачи данных, используемой в режиме разделения времени (см.
рис.3.14).
Рис.3.14. Архитектура коммутатора с общей шиной.
Каждый кадр передаваться по шине небольшими частями, по несколько байт
(например, ячейками по 48 байт), чтобы обеспечить псевдопараллельную
передачу кадров
между несколькими портами. Входной блок процессора помещает в ячейку,
переносимую
по шине, тэг, в котором указывает номер порта назначения. Каждый
выходной блок процессора порта содержит фильтр тэгов, который выбирает тэги,
предназначенные данному
порту. Достоинством коммутаторов с общей шиной является простота
наращивания количества коммутируемых портов.
Коммутаторы с разделяемой памятью обеспечивают коммутацию портов при
65
помощи
общей
разделяемой
памяти
(см.
рис.3.15).
Рис.3.15. Архитектура коммутатора с общей разделяемой памятью.
Входные блоки процессоров портов соединяются с переключаемым входом
разделяемой памяти, а выходные блоки этих же процессоров соединяются с
переключаемым
выходом этой памяти. Переключением входа и выхода разделяемой памяти
управляет
менеджер очередей выходных портов. В разделяемой памяти менеджер
организует несколько очередей данных, по одной для каждого выходного порта. Входные
блоки процессоров передают менеджеру портов запросы на запись данных в очередь того
порта,
который соответствует адресу назначения кадра. Менеджер по очереди
подключает вход
памяти к одному из входных блоков процессоров и тот переписывает часть
данных кадра
в очередь определенного выходного порта. По мере заполнения очередей
менеджер
производит также поочередное подключение выхода разделяемой памяти к
выходным
блокам процессоров портов, и данные из очереди переписываются в
выходной буфер
процессора. Достоинством коммутаторов с разделяемой памятью является
гибкость и
экономичность распределения общей памяти между отдельными портами,
что снижает
66
требования к размеру буферной памяти процессора каждого порта.
Комбинированные коммутаторы сочетают в себе достоинства различных
типов
архитектур. Пример такого коммутатора, сочетающего в себе скорость
матричных коммутаторов и легкость наращивания числа портов коммутаторов с общей шиной,
приведен на
рис.3.16.
Рис.3.16. Комбинированный коммутатор.
Коммутатор состоит из модулей с фиксированным количеством портов (212),
выполненных в виде коммутационной матрицы. Модули соединены между
собой при
помощи общей шины. Если порты, между которыми нужно передать кадр
данных, принадлежат одному модулю, то передача кадра осуществляется при помощи
коммутационной матрицы. Если же порты принадлежат разным модулям, то процессоры
общаются по
общей шине.
Полнодуплексный и полудуплексный режим работы коммутатора,
управление
потоком кадров.
Обычно к коммутатору подключаются концентраторы, т.е. на отдельный
порт
подключается целый сегмент. Однако к порту могут подключаться и
отдельные компьютеры (микросегментация). В таком случае, коммутатор и сетевая карта
компьютера могут
работать в полнодуплексном режиме, т.е. одновременно передавать данные
во встречных
направлениях, увеличивая пропускную способность сети в два раза.
Полнодуплексный
67
режим возможен только если обе стороны - и сетевая карта и коммутатор поддерживают
этот режим. В полнодуплексном режиме не существует коллизий. Наложение
двух кадров
в кабеле считается нормальным явлением. Для выделения принимаемого
сигнала, каждая
из сторон вычитает из результирующего сигнала свой собственный сигнал.
При полудуплексном режиме работы, передача данных осуществляется
только
одной стороной, получающей доступ к разделяемой среде по алгоритму
CSMA/CD.
Полудуплексный режим фактически был подробно рассмотрен ранее.
При любом режиме работы коммутатора (полудуплексном или
полнодуплексном)
возникает проблема управления потоков кадров. Часто возникает ситуация,
когда к одному из портов коммутатора подключен файл-сервер, к которому обращаются
все остальные
рабочие станции (см. рис.3.17).
Рис.3.17. Отношение многие порты – к одному.
Если порт 3 работает на скорости 10 Мбит/с, а кадры с остальных четырех
компьютеров поступают также со скоростью 10 Мбит/с, то не переданные кадры
будут накапливаться в буфере порта 3 и, рано или поздно, этот буфер переполнится.
Частичным решением данной проблемы было бы выделение для файл сервера порта 3, со
скоростью 100
Мбит/с. Однако это не решает проблему, а лишь откладывает ее: со временем
пользователи захотят более высоких скоростей работы сети, и коммутатор будет
заменен на новый,
68
у которого все порты будут работать на скорости 100 Мбит/c. Более
продуманным решением, реализованном в большинстве коммутаторов, является управление
потоком кадров,
генерируемых компьютерами. В полнодуплексном режиме используются
специальные
служебные сигналы "Приостановить передачу" и "Возобновить передачу".
Получив
сигнал "Приостановить передачу" сетевая карта должна прекратить передачу
кадров,
вплоть до последующего сигнала "Возобновить передачу" (к сожалению в
текущем
стандарте 802.3x не предусмотрено частичное уменьшение интенсивности
передачи
кадров, возможен только полный запрет). В полудуплексном режиме
используется "метод
обратного давления" (backpressure) и "агрессивное поведение порта
коммутатора". Оба
метода позволяют реализовать достаточно тонкие механизмы управления
потоком кадров,
частично снижая их интенсивность, но не уменьшая ее до нуля.
Метод обратного давления (backpressure) состоит в создании искусственных
коллизий в сегменте, который чересчур интенсивно посылает кадры в
коммутатор. Для
этого коммутатор обычно использует jam-последовательность (сигналыпомехи создающие и усиливающие коллизию), отправляемую на выход порта, к которому
подключен
сегмент (или компьютер), чтобы приостановить его активность.
Метод агрессивного поведения порта коммутатора основан на захвате среды
либо после окончания передачи очередного пакета, либо после коллизии. В
первом случае
коммутатор оканчивает передачу очередного кадра и, вместо
технологической паузы в 9,6
мкс, делает паузу в 9,1 мкс и начинает передачу нового кадра. Компьютер не
сможет
захватить среду, так как он выдержал стандартную паузу в 9,6 мкс и
обнаружил после
этого, что среда уже занята. Во втором случае кадры коммутатора и
компьютера сталки69
ваются и фиксируется коллизия. Компьютер делает паузу после коллизии в
51,2 мкс, как
это положено по стандарту, а коммутатор — 50 мкс. И в этом случае
компьютеру не
удается передать свой кадр. Коммутатор может пользоваться этим
механизмом адаптивно,
увеличивая степень своей агрессивности по мере необходимости.
Дополнительные возможности коммутаторов
Так как коммутатор представляет собой сложное вычислительное
устройство, имеющее несколько процессорных модулей, то естественно нагрузить его
помимо выполнения основной функции передачи кадров с порта на порт и некоторыми
дополнительными
функциями. Ниже описываются наиболее распространенные дополнительные
функции
коммутаторов.
1) Поддержка алгоритма Spanning Tree.
Как уже отмечалось, для нормальной работы коммутатора (моста) требуется
отсутствие петлевых маршрутов в сети. Петлевые маршруты могут создаваться
администратором специально, для образования резервных связей, или же возникать
случайным образом, что вполне возможно, если сеть имеет сложную топологию связи и
плохо структурирована или документирована. Алгоритм покрывающего дерева — Spanning
Tree Algorithm
(STA) позволяет коммутаторам автоматически, при помощи обмена
служебными пакетами, определять древовидную (без петель) конфигурацию связей в сети. В
случае отказе
какого-либо кабеля, порта или коммутатора, отказ обнаруживается
автоматически, за счет
постоянного тестирования связности сети служебными пакетами. После
обнаружения
потери связности протокол строит новое покрывающее дерево, если это
возможно, и сеть
автоматически восстанавливает работоспособность.
2) Трансляция протоколов канального уровня.
70
Коммутаторы позволяют преобразовывать кадры Ethernet в кадры FDDI,
кадры Fast
Ethernet в кадры Token Ring и т.п. Таким образом, если к одному порту
коммутатора подсоединен сегмент FDDI, а к другому – сегмент Ethernet, то коммутатор
позволит объединить эти две различные технологии канального уровня в единую сеть.
3) Фильтрация трафика.
Многие коммутаторы позволяют администраторам задавать дополнительные
условия фильтрации кадров. Пользовательские фильтры предназначены для
ограничения
доступа определенных групп пользователей к определенным службам сети.
Наиболее
простыми являются пользовательские фильтры на основе МАС-адресов
компьютеров.
Самым простым вариантом является указание коммутатору отбрасывать
кадры с определенным MAC-адресом. При этом пользователю, работающему на
компьютере с данным
МАС-адресом, полностью запрещается доступ к ресурсам другого сегмента
сети. Часто
администратору требуется задать более тонкие условия фильтрации,
например, запретить
некоторому пользователю печатать свои документы на определенном сервере
печати
NetWare чужого сегмента, а остальные ресурсы этого сегмента сделать
доступными. Для
реализации такого фильтра нужно запретить передачу кадров с
определенным МАСадресом, в которых вложены пакеты IPX, в поле "номер сокета" которых
будет указано
значение, соответствующее службе печати NetWare. Коммутаторы не
анализируют
протоколы верхних уровней, поэтому администратору придется вручную, в
шестнадцатеричной (двоичной) форме, задать такой фильтр и указать смещение и
размер фильтра,
относительно начала поля данных кадра канального уровня.
4) Приоритетная обработка кадров.
71
Использование коммутаторов позволяет реализовать приоритетную
обработку
кадров. Коммутатор обычно ведет для каждого входного и выходного порта
не одну, а
несколько очередей, причем каждая очередь имеет свой приоритет
обработки. При этом
коммутатор может быть сконфигурирован, например, так, чтобы передавать
один низкоприоритетный пакет на каждые 10 высокоприоритетных пакетов. Основным
вопросом при
приоритетной обработке кадров является вопрос назначения кадру
приоритета. Так как не
все протоколы канального уровня поддерживают поле приоритета кадра
(например, у
кадров Ethernet оно отсутствует), то коммутатор должен использовать какойлибо дополнительный принцип для назначения приоритета кадру. Наиболее
распространенный способ — приписывание приоритета портам коммутатора: кадр получает
соответствующий
приоритет в зависимости от того, через какой порт он поступил в
коммутатор. Способ
несложный, но недостаточно гибкий — если к порту коммутатора подключен
не
отдельный компьютер, а сегмент, то все узлы сегмента получают одинаковый
приоритет.
Более гибким способом является использование стандарта IEEE 802.1р: в
кадре Ethernet,
перед полем данных, предусматривается дополнительный заголовок,
состоящий из двух
байт, 3 бита из которых используются для указания приоритета кадра. При
передаче
кадра, компьютер, при помощи специального протокола, может запросить у
коммутатора
один из восьми уровней приоритета кадра. Установленный коммутатором
приоритет,
помещается в заголовок кадра и действует для всех коммутаторов в сети. При
передаче
кадра сетевой карте, не поддерживающей стандарт 802.1р, дополнительный
заголовок,
указывающий на приоритет кадра, должен быть удален.
72
5) Виртуальные локальные сети (Virtual LAN, VLAN).
Коммутаторы позволяют реализовывать технологии виртуальных локальных
сетей.
Несмотря на схожесть терминов, не следует путать виртуальные частные
сети (VPN –
Virtual Private Network) и виртуальные локальные сети (Virtual LAN, VLAN).
Виртуальные
частные сети позволяют на сетевом уровне безопасно объединить через
глобальные сети
(например, Internet) или линии телефонной связи несколько локальных сетей,
в единую
виртуальную ЛВС. Виртуальные локальные сети позволяют на канальном
уровне выделить внутри одной, физически существующей ЛВС, несколько
изолированных друг от
друга виртуальных ЛВС. Виртуальной сетью называется группа узлов сети,
кадры
которых, в том числе и широковещательные, на канальном уровне полностью
изолированы от других узлов сети (см. рис.3.18). Несмотря на то, что все
узлы сети могут,
например, быть подключены к одному и тому же коммутатору, передача
кадров на
канальном уровне между ними невозможна. Передача кадров между разными
виртуальными сетями возможно только на сетевом уровне, при помощи
маршрутизатора.
В то же время, внутри виртуальной сети кадры передаются коммутатором
стандартным
образом, на канальном уровне и только на тот порт, который необходимо.
Виртуальные
сети могут пересекаться, если один или несколько компьютеров входят в
состав более чем
одной виртуальной сети (см. рис.3.19) [1]. В таком случае, виртуальные
локальные сети
могут взаимодействовать между собой через эти общие компьютеры,
которые могут
73
являться,
например,
файловыми
74
или
почтовыми
серверами.
Рис.3.18.
сеть
Виртуальная
локальная
Рис.3.19 Пересечение виртуальных локальных сетей.
Технология виртуальных сетей создает гибкую основу для построения
крупной
сети, соединенной маршрутизаторами, так как коммутаторы позволяют
создавать полностью изолированные сегменты программным путем, что очень удобно в
крупных сетях.
До появления технологии VLAN, для создания отдельной сети
использовались либо
физически изолированные сегменты коаксиального кабеля, либо несвязанные
между
собой сегменты, построенные на повторителях и мостах. Затем эти сети
связывались
75
маршрутизаторами
в
единую
составную
сеть
(см.
рис.3.20).
Рис.3.20. Сеть, состоящая из физически независимых подсетей.
Любое изменение структуры такой сети означало физические изменения в
подключении того или иного оборудования к портам концентраторов, коммутаторов
и маршрутизаторов, изменения в прокладке кабеля и т.д. В больших сетях это
требовало значительных объемов работ, что повышало вероятность ошибок. При создании
виртуальных сетей
программным способом, порты коммутатора при помощи графической
программы легко
группируются в отдельные виртуальные сети. Другим, более гибким
способом, является
группировка в виртуальные сети не портов коммутатора, а MAC-адресов
отдельных
компьютеров.
Характеристики, влияющие на производительность коммутаторов
При выборе коммутатора следует в первую очередь обращать внимание на
характеристики, обеспечивающие его производительность, т.к. именно это свойство
послужило
причиной вытеснения мостов коммутаторами. Ниже приведены некоторые
характеристики:
1) Скорость фильтрации/продвижения кадров (кадров в секунду), пропускная
способность (мегабит в секунду), задержка передачи кадра.
76
Коммутатор является неблокирующим, если он может передавать кадры
через свои
порты с той же скоростью, с какой они на них поступают. Необходимо
учитывать для
кадров какого протокола и какой длины указана пропускная способность.
Максимальная
пропускная способность всегда достигается на кадрах максимальной длины,
так как при
этом доля накладных расходов на служебную информацию кадра гораздо
ниже, чем для
кадров минимальной длины, а время обработки кадра (в расчете на один байт
полезной
информации), существенно меньше. Поэтому коммутатор может быть
блокирующим для
кадров минимальной длины, но при этом иметь очень хорошие показатели
пропускной
способности. Коммутатор – это многопортовое устройство, поэтому для него
все приведенные выше характеристики (кроме задержки передачи кадра) можно давать
в общей
сумме, или в расчете на один порт. Обычно производители коммутаторов
указывают
общую максимальную пропускную способность устройства.
2) Тип коммутации — "на лету" или с полной буферизацией.
При коммутации на лету передача кадра начинается сразу после приема
первых
нескольких байт заголовка. При коммутации с полной буферизацией кадр
должен быть
полностью принят в буферную память до начала передачи. Разницу между
этими
характеристиками коммутаторов иллюстрирует таблица 3.1.:
Таблица 3.1.
Возможности коммутаторов при коммутации "на лету" и с полной
буферизацией.
Функция Налету С буферизацией
Защита от плохих кадров Нет Да
Трансляция протоколов
разнородных сетей (Ethernet
Token Ring, FDDI, ATM)
Нет Да
Задержка передачи пакетов Низкая (5-40 мкс) при низкой
77
нагрузке, средняя при высокой
нагрузке
Средняя при
любой нагрузке
Поддержка резервных связей Нет Да
Функция анализа трафика Нет Да
Так как каждый способ имеет свои достоинства и недостатки, в тех моделях
коммутаторов, которым не нужно транслировать протоколы, иногда применяется
механизм
адаптивной смены режима работы коммутатора. Основной режим такого
коммутатора —
коммутация "на лету", но коммутатор постоянно контролирует трафик и при
превышении
интенсивности появления плохих кадров некоторого порога переходит на
режим полной
буферизации. Затем коммутатор может вернуться к коммутации "на лету".
3) Размер адресной таблицы.
Максимальная емкость адресной таблицы определяет предельное количество
МАС-адресов, с которыми может одновременно оперировать коммутатор.
Так как коммутаторы чаще всего используют для выполнения операций каждого порта
выделенный процессорный блок со своей памятью для хранения экземпляра адресной
таблицы, то размер
адресной таблицы для коммутаторов обычно приводится в расчете на один
порт. Каждый
порт хранит только те наборы адресов, с которыми он работал в последнее
время. Недостаточная емкость адресной таблицы может служить причиной замедления
работы коммутатора и засорения сети избыточным трафиком. Если адресная таблица
процессора порта
полностью заполнена, а он встречает новый адрес источника в поступившем
пакете, процессор должен вытеснить из таблицы какой-либо старый адрес и поместить
на его место
новый. Эта операция сама по себе отнимет у процессора часть времени, но
главные потери
производительности будут наблюдаться при поступлении кадра с адресом
назначения,
78
который пришлось удалить из адресной таблицы. Так как адрес назначения
кадра неизвестен, то коммутатор должен передать этот кадр на все остальные порты. Эта
операция
будет создавать лишнюю работу для многих процессоров портов, кроме того,
копии этого
кадра будут попадать и на те сегменты сети, где они совсем не обязательны.
Некоторые
производители коммутаторов решают эту проблему за счет того, что один из
портов коммутатора конфигурируется как магистральный порт, на который по
умолчанию передаются все кадры с неизвестным адресом. Передача кадра на магистральный порт
производится в расчете на то, что этот порт подключен к вышестоящему коммутатору,
который имеет
большую емкость адресной таблицы и знает, куда нужно передать любой
кадр.
4) Объем буфера кадров.
Внутренняя буферная память коммутатора нужна для временного хранения
кадров
данных в тех случаях, когда их невозможно немедленно передать на
выходной порт.
Буфер предназначен для сглаживания кратковременных пульсаций нагрузки
на сеть.
Каждый процессорный модуль порта обычно имеет свою буферную память.
Чем больше
объем этой памяти, тем менее вероятны потери кадров при перегрузках.
Обычно коммутаторы, предназначенные для работы в ответственных частях сети, имеют
буферную
память в несколько десятков или сотен килобайт на порт. Хорошо, когда эту
буферную
память можно перераспределять между несколькими портами, так как
одновременные
перегрузки по нескольким портам маловероятны. Дополнительным
средством защиты
может служить общий для всех портов буфер в модуле управления
коммутатором. Такой
буфер обычно имеет объем в несколько мегабайт.
79
5) Производительность процессоров портов, производительность внутренней
шины
коммутатора.
Необходимо следить, чтобы производительность общей шины (при
архитектуре с
общей шиной) или производительность процессоров портов не стала "узким
местом" в
коммутаторе.
5. Эталонная модель окружений открытых систем (POSIX 1003.0).
Система стандартов окружений открытых систем POSIX OSE и эталонная POSIX RM OSE.
Ин-ция из курса "Анализ ИТ" проф. Сухомлин В.А.
Назначение и состав системы стандартов POSIX
Методология и система стандартов POSIX OSE (POSIX - Portable Operating System
Interface for Computer Environments, OSE - Open System Environment) разработаны
организацией IEEE .
Цель подхода POSIX состоит в том, чтобы обеспечить возможность решения проблемы
переносимости прикладных программ между различными компьютерными платформами
на основе стандартизации прикладных программных интерфейсов (API) операционных
систем (ОС).
Целью разработки системы стандартов POSIX OSE:

Переносимости приложений на уровни исходных текстов (Application Portability at the Source Code
Level).

Системной интероперабельности (System Interoperability), т.е. поддержки взаимосвязанности между
системами.

Переносимости пользователей (User Portability), т.е. обеспечения возможности для пользователей
работать на различных платформах без переобучения.

Адаптируемости к новым стандартам (Accommodation of Standards).

Адаптируемости к новым информационным технологиям (Accommodation of new System
Technology) на основе универсальности классификационной структуры сервисов и независимости
модели от механизмов реализации.

Масштабируемости прикладных платформ (Application Platform Scalability).

Масштабируемости распределенных систем (Distributed System Scalability), отражающей
возможность функционирования прикладного программного обеспечения независимо от развития
топологии и ресурсов распределенных систем.
80

Прозрачности реализаций (Implementation Transparency), т.е. скрытия от пользователей за
интерфейсами систем особенностей их реализации.

Системности и точности спецификаций функциональных требований пользователей (User Functional
Requirements), что обеспечивает полноту и ясность определения потребностей пользователей, в том
числе, в определении состава применяемых стандартов
Главные задачи:

Интеграцию информационных систем из компонент различных изготовителей.

Эффективность реализаций и разработок, благодаря точности спецификаций и соответствию
стандартным решениям, отражающим передовой научно-технический уровень.

Эффективность переноса прикладного программного обеспечения, благодаря использованию
стандартизованных интерфейсов и прозрачности механизмов реализации сервисов систем.
Структура и состав системы стандартов POSIX.
В приведенной ниже таблице, указаны основные стандарты POSIX OSE вместе с
индексами соответствующих им проектов (индексы стандартов получаются из индексов
проектов посредством удаления первой буквы).
Project
Standard/Profile
P1003.0
Guide to the POSIX OSE (руководство по окружениям
открытых систем POSIX)
P1003.1,.1a
System Interfaces (системные интерфейсы)
P1003.1b,.1d
Realtime (реальное время)
P1003.1c
Threads (механизм нитей)
P1003.1e
Security API (API безопасности)
P1003.1f
Transparent File Access (прозрачный доступ к файлам)
P1003.1g
Protocol-Independent Network Specification (протоколонезависимые сетевые спецификации)
P1003.2, .2b
Shell and Utilities (оболочка и утилиты)
P1003.2c
Security Utilities (утилиты безопасности)
P1003.22
Guide to POSIX OSE Security Framework (руководство по
основам безопасности окружений открытых систем POSIX)
и т.д.
и т.д.
Эталонная модель POSIX OSE RM
Методологической основой для таксономии и разработки стандартов POSIX служит
эталонная модель OSE RM (Open System Environment Reference Model), определяющая
концептуальный базис и систематический подход к классификации интерфейсов и
81
сервисов открытых систем.
Модель определяет три типа сущностей, а именно:

прикладного программного обеспечения (Application Software Entities),

прикладной платформы (Application Platform Entities),

внешнего окружения (External Environment Entities),
а также два типа интерфейсов между ними - API и EEI.
Типы OSE POSIX профилей:
- профили, основанные на одном стандарте ("Single-standard profile") - определяют
функциональное подмножество или параметризацию одного многофункционального
стандарта;
-профили платформ ("Platform profile") - как правило, представляют собой комбинации
стандартов, определяющие некоторое операционное окружение для приложений;
- профили прикладных окружений ("Application Environment Profile" - AEP) - профили,
полностью определяющие некоторое окружение открытой системы;
- профили, определяющие политику организаций ("Organization specific profiles") профили организаций, названные нами стратегическими профилями.
Основные понятия:
Внешнее окружение (external environment - EE) - набор внешних для прикладной
платформы сущностей, взаимодействие с которыми осуществляется через некоторые
сервисы.
Интерфейс внешнего окружения (external environment interface - EEI) - интерфейс
между прикладной платформой и внешним окружением, через который осуществляется
взаимодействие с внешними по отношению к прикладной платформе сущностями
посредством использования сервисов этого интерфейса.
В модели OSE RM информационная система рассматривается как черный ящик,
взаимодействие с которым стандартизовано и осуществляется только через ее
интерфейсы, где под интерфейсами понимаются границы, разделяющие между собой
некоторые функциональные сущности.
Принципы построения OSE RM. Этот процесс выполняется с помощью следующих
шагов.

Стандарты интерфейсов открытых систем разбиваются на две основные категории в соответствии с
двумя типами интерфейсов:
82
o
стандарты прикладных программных интерфейсов (Application Program Interface (API)
Standards);
o
стандарты внешнего окружения (External Environment Interface (EEI) Standards).
Следование стандартам обеих групп позволяет решить главную задачу для
потребителей информационных технологий, а именно, обеспечить возможность
построения информационных систем из компонентов, поставляемых различными
изготовителями, и, как следствие, обеспечить независимость от поставщиков ИТ в целом.

Указанные выше две группы сервисов и стандартов, разбиваются на четыре основных категории, а
именно:
o
системные или программные сервисы (System Services)
o
коммуникационные сервисы (Communication Services)
o
информационные сервисы (Information Services)
o
сервисы человеко-машинного взаимодействия (Human/Computer Services).

Для каждой из выше упомянутой категории сервисов определяется их функциональное разбиение
на области (подкатегории).

Для каждой подкатегории сервисов конкретизируется исходная эталонная модель, т.е.
разрабатывается некоторая версия эталонной модели, отражающая особенности использования
соответствующей подкатегории сервисов.

На основе соответствующей эталонной модели для каждой подкатегории сервисов разрабатывается
ее функциональность в виде определения групп сервисов, которые в свою очередь структурируются
до элементарных сервисов.

Для каждой группы сервисов определяются соответствующие ей ссылки на существующие или
разрабатываемые стандарты.

Для каждой категории сервисов определяются, так называемые, межкатегориальные сервисы (CrossCategory Services), элементы которых могут входить в любую группу сервисов. К ним относятся
сервисы интернационализации (Internationalization Services), системной безопасности (System
Security Services), административного управления (Systems Management Services).
Эталонная модель POSIX OSE - интерфейсы.
83
Между сущностями общей модели существует два типа интерфейсов: API и EEI.
API определяет следующие типы сервисов:

системные сервисы (System Services);

коммуникационные сервисы (Communication Services);

информационные сервисы (Information Services);

сервисы взаимодействия человека с компьютером (Human/Computer Interaction Services).
EEI определяет следующие типы сервисов и, соответственно, интерфейсов:

коммуникационные сервисы (Communication Services);

информационные сервисы (Information Services);

сервисы взаимодействия человека с компьютером (Human/Computer Interaction Services).
Модель реализации распределенных приложений.
В распределенном окружении различные прикладные платформы могут
взаимодействовать с помощью сервисов (коммуникационных механизмов) интерфейса
внешнего окружения.
Cервисы системного ядра
Под такими сервисами обычно понимаются сервисы,
предоставляемые прикладным программам операционной
системой или другими программами системного уровня, такими,
как, например, драйверы устройств.
Для разработки функциональности различных категорий сервисов применяется метод
систематической классификации или структуризации сервисов API - первоначально
определяются категории сервисов, затем они детализируются на группы сервисов или
составные сервисы, те, в свою очередь, на элементарные сервисы, которые, в конце
концов, отображаются на конкретные функции API.
Именно этот прием применяется и для разработки номенклатуры сервисов ядра.
84
Первоначально определяется состав групп сервисов ядра. Он включает в себя следующие
группы сервисов:

Process and Thread Mgmt Services (сервисы управления процессами и нитями)

Environment Services (сервисы окружения)

Node Internal Comm and Sync Services (сервисы связи и синхронизации для внутренних узлов)

Generalized I/O Services (общие сервисы ввода/вывода)

File Storage Services (сервисы файлохранилища)

Event, Error, Exception Mgmt Services (сервисы управления событиями, управления обработкой
ошибок и исключениями)

Time and Timer Services (сервисы управления временем и таймерами)

Memory Management Services (сервисы управления памятью)

Logical Naming Services (сервисы логического наименования)
85
6. Cтек протоколов TCP/IP в сравнении со стеком OSI. Основные
протоколы стека TCP/IP: IP, ICMP, UDP, TCP, их назначение и
особенности.
1. Соотношение между OSI/ISO и TCP/IP
В 1984 г. международная стандартизирующая организация ISO предложила модель
взаимодействия открытых систем OSI (Open System Interconnection), являющуюся
удобным средством описания стеков протоколов.
На рис. 1.1 представлено соотношение четырехуровневой архитектуры протоколов TCP/IP
и семиуровневой архитектуры OSI.
Модель OSI/ISO
+-------------------+
| Прикладной
|
+-------------------+
| Представительский |
+-------------------+
| Сеансовый
|
+-------------------+
| Транспортный
|
+-------------------+
| Сетевой
|
+-------------------+
| Канальный
|
+-------------------+
| Физический
|
+-------------------+
TCP/IP
- - - +-----------------------------+
|
|
- - - |
Прикладной
|
|
(Application)
|
- - - |
|
|
|
- - - +-----------------------------+
| Транспортный (Transmission) |
- - - +-----------------------------+
| Межсетевой (Internetwork)
|
- - - +-----------------------------+
|
Сетевой
|
- - - |
(Network)
|
|
|
- - - +-----------------------------+
Рис. 1.1
86
Объединение канального и физического уровней модели OSI в единый сетевой уровень
TCP/IP было обусловлено требованием независимости от используемой среды передачи
данных. Дело в том, что функции протоколов канального и физического уровней
реализуются в настоящее время , как правило, едиными техническими средствами
(сетевыми контроллерами).
Согласно терминологии TCP/IP элементы сетевого уровня называются подсетями
(subnetworks). Идеология TCP/IP допускает, чтобы в качестве "подсетей" выступали
реальные сети с их собственными стеками протоколов, узлами, шлюзами и т.п.
Внимание. Далее в данном учебном пособии для обозначения уровней стека протоколов
используется терминология TCP/IP, а не OSI/ISO (если это не оговорено особо).
Внимание. В данном учебном пособии термин "шлюз" используется как обобщающий для
понятий "маршрутизатор" (router), "мост" (bridge) и, собственно, "шлюз" (gateway).
2. Архитектура протоколов TCP/IP
На рис. 2.1 представлена архитектура основных протоколов TCP/IP, используемых на трех
нижних уровнях стека.
Транспортный
уровень
+-------+
| TCP |
+-------+
Межсетевой
уровень
+------+
| IP |
+------+
Сетевой
уровень
+----------+
| Ethernet |
+----------+
+-------+
| UDP |
+-------+
+--------+
| ICMP |
+--------+
+------+
| X.25 |
+------+
+------------+
| Token Ring |
+------------+
. . .
Рис. 2.1
Краеугольным камнем всей архитектуры является межсетевой протокол IP (Internet
Protocol). С его помощью реализуется адресация узлов сети и доставка данных.
Межсетевой протокол управляющих сообщений ICMP (Internet Control Message
Protocol) предназначен для передачи диагностической информации и сообщений об
ошибках в работе сети.
Примечание. Протокол ICMP отнесен к межсетевому уровню условно, т.к., с одной
стороны, он пользуется возможностями протокола IP для транспортировки
собственных данных, но, с другой стороны, сам для транспортировки данных
пользователя не применяется.
Двумя основными протоколами транспортного уровня являются надежный протокол
управления передачей данных TCP (Transmission Control Protocol) и быстрый протокол
дэйтаграмм пользователя UDP (User Datagram Protocol). TCP реализует сетевое
взаимодействие в режиме с установлением логического (виртуального) соединения, а UDP
- без оного.
87
Функции каждого протокола реализуются компонентой программного обеспечения
(обычно входящей в состав операционной системы), которую будем называть модулем.
Взаимодействие модулей соседних уровней осуществляется через стандартизированный
интерфейс, имеющий, как правило, процедурный характер.
Внимание. На каждом уровне стека протоколов TCP/IP обмен данными ведется блоками
данных конечной длины. К сожалению, отсутствует устоявшаяся терминология в
обозначении этих блоков. В данном учебном пособии названия блоков данных зависят от
уровня стека протоколов, как это показано ниже.
Уровень
| Название
-----------------+----------Транспортный
| Пакет
Межсетевой
| Сегмент
Сетевой
| Кадр
3. Межсетевой протокол IP
Содержание
3.1. Заголовок IP-сегмента
3.2. IP-адрес
3.3. Фрагментация IP-сегментов
3.4. Дополнительные данные IP-заголовка
Межсетевой протокол IP специфицирован в RFC 791. Его основные характеристики
перечислены ниже:

реализует обмен информации пакетами, которые будем называть IP-сегментами (максимальный
размер IP-сегмента - 65535 байт);

является протоколом взаимодействия без установления логического соединения;

для адресации узлов сети используется адрес длиной 4 байта;

обеспечивает в случае необходимости фрагментацию IP-сегментов;

IP-сегменты имеют конечное время жизни в сети;

не гарантирует надежность доставки IP-сегментов адресату;

не имеет средств управления интенсивностью передачи IP-сегментов посылающей стороной (flow
control);

не гарантирует правильную последовательность IP-сегментов на принимающей стороне.
3.1. Заголовок IP-сегмента
На рис. 3.1 приведен формат заголовка IP-сегмента.
0
3
7
15
18
23
31
+------+-------+---------------+-----+---------+---------------+
|Версия| Длина |
Тип
|
Длина
|
88
|
|заг-ка | обслуживания |
сегмента
|
+------+-------+---------------+-+-+-+---------+---------------+
|
Идентификатор
| |D|M|
Смещение
|
|
| |F|F|
фрагмента
|
+--------------+---------------+-+-+-+-------------------------+
|
Время
| Транспорт
|
Контрольная сумма
|
|
жизни
|
|
заголовка
|
+--------------+---------------+-------------------------------+
|
Адрес
|
|
источника
|
+--------------------------------------------------------------+
|
Адрес
|
|
приемника
|
+----------------------------------------------+---------------+
|
Дополнительные
|
Данные
|
|
данные заголовка
| выравнивания |
+----------------------------------------------+---------------+
Рис. 3.1
Версия
4-хбитовое поле, содержащее номер версии протокола IP (номер текущей версии
равен 4);
Длина заголовка
4-хбитовое поле, содержащее длину заголовка IP-сегмента в 32-битных словах.
Минимальная (и типичная) длина заголовка - пять слов.
Тип обслуживания
байт, содержащий набор критериев, определяющих тип обслуживания IPсегментов. Детальное описание отдельных битов дано ниже:
o
биты 0...2 - приоритет (precedence - предпочтение) данного IP-сегмента;
o
бит 3 - требование ко времени задержки (delay) передачи IP-сегмента (0 - нормальная, 1 низкая задержка);
o
бит 4 - требование к пропускной способности (throughput) маршрута, по которому должен
отправляться IP-сегмент (0 - низкая, 1 - высокая пропускная способность);
o
бит 5 - требование к надежности (reliability) передачи IP-сегмента (0 -нормальная, 1 высокая надежность);
o
биты 6...7 - зарезервированы.
На практике в большинстве реализаций протокола IP данное поле почти всегда
равно 0, в UNIX-реализациях это поле не используется вовсе.
Длина сегмента
двухбайтовое поле, содержащее длину (в байтах) всего IP-сегмента, включая длину
заголовка. Максимальная длина IP-сегмента (включая заголовок) - 65535 байт.
Спецификация IP протокола устанавливает, что что любой узел сети должен быть
способен обрабатывать IP-сегменты длиной, по крайней мере, не менее 576 байт
89
(что соответствует 512 байтам данных при возможной длине заголовка до 64 байт).
На практике же узлы сети могут обрабатывать IP-сегменты много длинее, чем 576
байт (как правило, допустимая длина IP-сегмента связана с максимальной длиной
кадра нижележащего сетевого уровня).
Идентификатор
двухбайтовое поле, содержащее уникальный идентификатор IP-сегмента,
присваиваемый ему посылающим узлом. Это поле используется для распознавания
фрагментов одного IP-сегмента (в ситуациях, когда в ходе перемещения по
глобальной сети единый IP-сегмент был разбит на несколько фрагментов по
причине его недопустимо большой длины).
DF, MF
биты, используемые при обработке фрагментированных IP-сегментов.
Если бит DF (Don't Fragment) установлен в 1, то это означает, что IP-сегмент не
может быть разбит на фрагменты ни при каких условиях (даже, если он не может
быть передан без этого далее к адресату и должен быть уничтожен).
Бит MF (More Fragments) указывает, является (MF=0) или нет (MF=1) данный IP"подсегмент" последним в цепочке IP-"подсегментов", в которую был
преобразован (фрагментирован) исходный IP-сегмент.
Алгоритм фрагментации описан ниже в разделе "Фрагментация IP-сегментов".
Смещение фрагмента
13-битное поле, используемое только в IP-сегменте, являющемся фрагментом (IPфрагментом) другого (исходного) IP-сегмента. Это поле содержит смещение
данных, содержащихся в IP-фрагменте, по отношению к началу данных исходного
IP-сегмента. Смещение измеряется в восьмибайтных единицах, поэтому 13 битов
достаточно для представления смещения в IP-сегменте максимальной возможной
длины (8 * 2^13 - 1 = 65535).
Время жизни
однобайтовое поле, заполняемое создающим IP-сегмент узлом сети количеством
единиц времени жизни IP-сегмента в сети. RFC 791 специфицирует в качестве этих
единиц секунды и требует, чтобы каждый транзитный узел сети, через который
проходит IP-сегмент, уменьшал содержимое этого поля по крайней мере на 1 (даже
при условии, что обработка сегмента на самом деле заняла меньше одной секунды).
Таким образом, на практике, время жизни (TTL - Time To Live) - это максимальное
количество узлов, которое может пройти до своего уничтожения IP-сегмент.
Каждый IP-модуль на любом узле сети обязан уничтожать IP-сегменты, для
которых поле "время жизни" стало равным нулю. Этим предотвращается появление
в сети IP-сегментов, "блуждающих" по ней бесконечное время. При этом узлуисточнику уничтоженного IP-сегмента посылается ICMP-сегмент, извещающий об
этом событии.
90
В UNIX-реализациях, как правило, это поле заполняется источником IP-сегмента
числом из диапазона 15...30.
Транспорт
поле размером в байт, содержащее идентификатор протокола более высокого
(обычно, транспортного) уровня, для которого предназначены данные IP-сегмента.
Ниже приведены идентификаторы для ряда протоколов.
--------+-------------+-----------------------------------------Иденти- : Сокращенное :
Имя протокола
фикатор : название
:
--------+-------------+-----------------------------------------1
ICMP
Межсетевой протокол управляющих сообщений
2
IGMP
Межсетевой протокол группового управления
3
GGP
Протокол "шлюз-шлюз"
6
TCP
Протокол управления передачей
8
EGP
Протокол "внешних" шлюзов
17
UDP
Протокол дейтаграмм пользователя
27
RDP
Протокол надежных данных
28
IRTP
Протокол межсетевой надежной передачи
29
ISO TP4
Транспортный протокол ISO 4 класса
80
ISO IP
Межсетевой протокол ISO
89
OSPF
Протокол "кратчайший путь первым"
-------+--------------+------------------------------------------
Контрольная сумма заголовка
двухбайтовое поле, содержащее контрольную сумму заголовка IP-сегмента
(обращаем внимание, что для данных IP-сегмента контрольная сумма не
подсчитывается; контролировать данные - задача протоколов транспортного
уровня).
Поскольку заголовок IP-сегмента содержит поле "время жизни", изменяющее свое
значение в каждом узле, через который следует IP-сегмент, то для вычисления
контрольной суммы должен использоваться эффективный (а, следовательно,
простой алгоритм). Во всех протоколах, входящих в архитектуру TCP/IP,
используется так называемая Internet-контрольная сумма, которая представляет
собой дополнение 16-битной суммы всех 16-битных слов контролируемой
информации.
Адрес источника и адрес приемника
четырехбайтовые IP-адреса узлов сети. Подробно структура IP-адреса описана
ниже в "IP-адрес".
Дополнительные данные заголовка
последовательность полей произвольной длины, описывающих необязательные
данные заголовка. Такие данные используются для специальных целей (управление
сетью, секретность и т.п.) и кратко описаны ниже в "Дополнительные данные IPзаголовка".
Данные выравнивания
91
не имеющие смысла данные, включаемые в заголовок только для выравнивания его
длины до границы четырехбайтового слова.
3.2. IP-адрес
IP-адрес представляет собой четырехбайтовое число, старшие (крайние левые) биты
которого определяют класс IP-адреса. Для классов A, B и C четыре байта адреса делятся
между идентификатором (номером) сети и идентификатором (номером) узла в сети как
это показано на рис. 3.2.
|
0
7|
15
23
31
+-+---------+-------------+-------------+-------------+
|0|
|
:
:
| Класс A
+-+---------+-------------+-------------+-------------+
|
+-------------+
15|
+-+-+-------+-------------+-------------+-------------+
|1|0|
:
|
:
| Класс B
+-+-+-------+-------------+-------------+-------------+
|
+-------------+
23|
+-+-+-+-----+-------------+-------------+-------------+
|1|1|0|
:
:
|
| Класс C
+-+-+-+-----+-------------+-------------+-------------+
|
Идентификатор сети
| Идентификатор узла
Рис. 3.2
Сети классов A, B и C абсолютно равноправны и отличаются лишь допустимым
количеством узлов в них. Идентификаторы узлов, состоящие из одних нулевых или
единичных битов имеют специальный смысл:

IP-адрес с нулевым идентификатором узла используется для обозначения сети в целом;

IP-адрес с идентификатор узла в виде единичных битов является широковещательным (broadcast)
адресом.
IP-адреса принято записывать в так называемой "точечной нотации" - в виде
последовательности разделенных точками четырех десятичных (или шестнадцатиричных
с префиксом 0x) чисел, представляющих значения отдельных байтов.
Каждый узел в сети имеет, по крайней мере, один уникальный IP-адрес.
Кроме классов A, B и C существуют еще два класса IP-адресов - D и E (см. рис. 3.3).
+-+-+-+-+------+------------+------------+------------+
|1|1|1|0|
Идентификатор группы узлов
|
+-+-+-+-+------+------------+------------+------------+
Класс D
+-+-+-+-+------+------------+------------+------------+
|1|1|1|1|
:
:
:
|
+-+-+-+-+------+------------+------------+------------+
Класс E
92
Рис. 3.3
Класс D используется для организации многопунктового (multicast) режима посылки
сообщений: IP-сегмент, посылаемый по по IP-адресу класса D, доставляется всем узлам
сети, имеющим указанный идентификатор группы узлов. Описание данного режима дано
в RFC 1112.
Примечание. Не все современные реализации протоколов TCP/IP поддерживают
многопунктовое вещание.
Для обеспечения гибкости при создании и администрировании сетей различного размера в
1985 г. было введено понятие "подсеть" (RFC 950), позволяющее использовать один и тот
же IP-адрес классов A,B или C для разных подсетей.
Такая возможность обеспечивается специальной битовой маской (netmask),
ассоциированной с IP-адресом и определяющей распределение битов IP-адреса между
идентификатором подсети и идентификатором узла.
Пусть, например, IP-адрес класса C 194.85.36.0 планируется использовать для
организации четырех подсетей. Это потребует выделения двух битов из части IP-адреса,
относящейся к идентификатору узла. Такое "перепланирование" структуры IP-адреса
реализуется сетевой маской 255.255.255.192, где десятичное 192 - это двоичное 11000000.
Эта сетевая маска формирует IP-адрес не из двух, а из трех комронент:

идентификатор сети (24 бита);

идентификатор подсети (2 бита);

идентификатор узла (6 бит).
Каждая из четырех образованных подсетей может иметь до 62 узлов с идентификаторами
от 1 до 62, идентификатор узла с номером 63 является широковещательным
идентификатором для подсети.
Примечание. Для идентификатора подсети можно выделять только старшие (самые
левые) биты из части IP-адреса, отводимой под идентификатор узла.
Примечание. Возможность разбиения сетей на подсети обусловливается, в первую
очередь, средствами маршрутизации IP-сегментов, а не средствами IP-модулей,
формирующих и обрабатывающих IP-сегменты.
Примечание. Некоторые современные реализации протоколов маршрутизации для
TCP/IP позволяют выделять "подподсети" в подсетях.
3.3. Фрагментация IP-сегментов
Для того, чтобы существовала возможность передачи IP-сегментов через сети различного
типа, межсетевой протокол обеспечивает адаптацию их размера к требованиям каждой
сети. Это дает возможность, например, IP-сегментам, порожденным в сети на базе
Ethernet (максимальный размер кадра - 1526 байт), беспрепятственно перемещаться до
93
адресата по сети на базе X.25 (максимальный размер кадра - 128 байт). Изменение размера
IP-сегмента в процессе перемещения по сети может быть связано и с соображениями
эффективности передачи.
Изменение размера IP-сегмента реализуется механизмом, называемым фрагментацией. IPмодуль на любом узле сети должен иметь возможность:
1.
разбивать полученный им IP-сегмент на IP-фрагменты необходимого размера перед их передачей
через конкретную сеть;
2.
восстанавливать исходный IP-сегмент из получаемых им IP-фрагментов.
Каждый IP-фрагмент представляет собой полноценный IP-сегмент со своим собственным
IP-заголовком. Однако заголовки всех IP-фрагментов содержат одинаковый
идентификатор, совпадающий с идентификатором исходного IP-сегмента. Это позволяет
распознавать все IP-фрагменты, относящиеся к одному исходному IP-сегменту.
IP-фрагменты в своих заголовках содержат поле "Смещение фрагмента", описывающее
смещение данных IP-фрагмента в данных исходного IP-сегмента. Это поле позволяет
корректно восстановить данные исходного IP-сегмента в принимающем IP-фрагменты
узле даже в ситуации, когда IP-фрагменты приходят в порядке, от порядка их посылки
(такое вполне возможно, т.к. IP-фрагменты могут следовать от источника к адресату по
разным маршрутам).
Рассмотрим процесс фрагментации более подробно на следующем примере. IP-модуль на
некотором узле получил IP-сегмент с идентификатором 9876 и данными длиной 300 байт
(при этом бит запрета фрагментации DF установлен в 0). Этот IP-сегмент должен быть
передан дальше к адресату через сеть, максимальный размер кадра которой равен 128
байтам.
Рис. 3.4 схематично представляет разбиение исходного IP-сегмента на 3 IP-фрагмента.
Исходный IP-сегмент
+-----------+--------------------------------------+
| Заголовок |
Данные (300 байт)
|
+-----------+--------------------------------------+
:
:
:
:
:
:
:
:
IP-фрагмент 1
:
:
:
:
+-----------+-------------+
:
:
| Заголовок | 104 байта |
:
:
+-----------+-------------+
:
:
IP-фрагмент 2
:
:
:
+-----------+-------------+
:
| Заголовок | 104 байта |
:
+-----------+-------------+
:
IP-фрагмент 3
:
:
+-----------+----------+
| Заголовок | 92 байта |
+-----------+----------+
Рис. 3.4
IP-фрагмент 1 содержит в своем заголовке следующую информацию:
94
1.
идентификатор - 9876;
2.
длина заголовка - 5 (четырехбайтных слов);
3.
длина сегмента - 124 (байт);
4.
бит MF - 1;
5.
смещение фрагмента - 0 (восьмибайтных единиц).
IP-фрагмент 2 содержит в своем заголовке следующую информацию:
1.
идентификатор - 9876;
2.
длина заголовка - 5 (четырехбайтных слов);
3.
длина сегмента - 124 (байт);
4.
бит MF - 1;
5.
смещение фрагмента - 13 (восьмибайтных единиц).
IP-фрагмент 3 содержит в своем заголовке следующую информацию:
1.
идентификатор - 9876;
2.
длина заголовка - 5 (четырехбайтных слов);
3.
длина сегмента - 112 (байт);
4.
бит MF - 0;
5.
смещение фрагмента - 26 (восьмибайтных единиц).
Заметим, что т.к. смещение фрагмента измеряется в восьмибайтных единицах, то длина
данных в каждом IP-фрагменте (кроме последнего в цепочке) обязательно должна быть
кратна 8. Вот почему в нашем примере это 104 байта (13 восьмибайтных единиц), а не
108, как допускает максимальная длина кадра в 128 байт (128 - 20 = 108, где 20 - длина
заголовка).
IP-модуль на принимающем IP-фрагменты узле в ситуации, когда он должен
транслировать IP-сегмент далее по сети, имеет три варианта действий с фрагментами:
1.
переслать IP-фрагменты далее неизменными;
2.
разбить (если в этом есть необходимость) полученные IP-фрагменты на более короткие IPфрагменты;
3.
восстановить исходный IP-сегмент из фрагментов.
В работе с IP-фрагментами на принимающей стороне используется специальный таймер,
который с приходом первого фрагмента IP-сегмента устанавливается в исходное
состояние (для UNIX-реализаций это, обычно, 30 сек) и начинает обратный счет. До
момента обнуления таймера должны прийти все IP-фрагменты, относящиеся к этому
сегменту. Если этого не произойдет, то все частично полученные данные IP-сегмента
сбрасываются, а сам IP-сегмент считается утерянным.
95
3.4. Дополнительные данные IP-заголовка
Ниже кратко описываются дополнительные данные, которые могут включаться в IPзаголовок в случае необходимости.
Предписываемый маршрут
список IP-адресов узлов сети, через которые должен следовать до адресата IPсегмент. Предписываемый маршрут может быть "строгим" или "мягким". В первом
случае IP-сегмент должен следовать строго только по указанным в списке узлам
сети, во втором - допустимо прохождение через любые промежуточные узлы, не
указанные в списке.
Пройденный маршрут
список IP-адресов узлов сети, которые посетил IP-сегмент по пути к адресату.
Каждый транзитный узел, через который следует IP-сегмент, помещает в этот
список свой IP-адрес.
Временные метки (time stamp)
список моментов времени прохождения IP-сегмента через узлы сети,
составляющие маршрут.
Секретность
указание на обработку IP-сегмента в соответствии с требованиями безопасности
(RFC 1038). Эта возможность имеется только в нескольких (военных) реализациях
TCP/IP.
Флаг окончания
указание на завершение дополнительных данных IP-заголовка.
Каждый элемент дополнительных данных представляет собой

либо однобайтовый идентификатор дополнительных данных (например, "флаг окончания");

либо комбинацию однобайтового идентификатора, поля длины и данных (например,
"предписываемый маршрут").
Для дополнительных данных, пополняемых в ходе продвижения IP-сегмента по сети
(например, "пройденный маршрут"), источник IP-сегмента должен зарезервировать место
необходимого объема в IP-заголовке. Такой подход обеспечивает упрощение (а,
следовательно, и ускорение) обработки IP-сегмента в узлах маршрута.
RFC 1063 (1988 г.) предлагает механизм определения оптимального размера IP-сегмента,
при посылке его к определенному адресату. Этот механизм использует дополнительные
данные IP-заголовка, называемые probe MTU (probe Maximum Transfer Unit - тестовый
максимальный блок передачи). Каждый узел в маршруте IP-сегмента, содержащего такие
дополнительные данные, сравнивает MTU следующей по маршруту сети с MTU,
содержащемся в заголовке, и заменяет в нем старое значение на новое, если новое
96
оказывается меньше. Конечный адресат IP-сегмента возвращает определенное таким
образом значение источнику IP-сегмента. Использование в дальнейших посылках
найденного размера IP-сегментов, позволяет избежать их фрагментации. Этот механизм
широкого распространения еще не получил.
Примечание. Понятие MTU подробно рассматривается в "Протоколы сетевого уровня"
.
4. Протокол управления передачей TCP
Содержание
4.1. Заголовок TCP-пакета
4.2. Номер порта
4.3. Принцип "скользящего окна"
4.4. Важные данные
4.5. Этапы TCP-взаимодействия
4.6. Таймеры
4.7. Алгоритмы повышения эффективности
Протокол управления передачей TCP (Transmission Control Protocol) является протоколом
транспортного уровня и базируется на возможностях, предоставляемых межсетевым
протоколом IP. Основная задача TCP - обеспечение надежной передачи данных в сети. Его
транспортный адрес в заголовке IP-сегмента равен 6. Описание протокола TCP дано в RFC
793.
Его основные характеристики перечислены ниже:

реализует взаимодействие в режиме с установлением логического (виртуального) соединения;

обеспечивает двунаправленную дуплексную связь;

организует потоковый (с точки зрения пользователя) тип передачи данных;

дает возможность пересылки части данных, как "экстренных";

для идентификации партнеров по взаимодействию на транспортном уровне использует 16-битовые
"номера портов";

реализует принцип "скользящего окна" (sliding window) для повышения скорости передачи;

поддерживает ряд механизмов для обеспечения надежной передачи данных.
Несмотря на то, что для пользователя передача данных с использованием протокола TCP
выглядит как потоковая, на самом же деле обмен между партнерами осуществляется
посредством пакетов данных, которые мы будем называть "TCP-пакетами".
97
4.1. Заголовок TCP-пакета
На рис. 4.1 приведен формат заголовка TCP-пакета.
0
3
9
15
23
31
+------+-----------+-----------+---------------+---------------+
|
Порт
|
Порт
|
|
источника
|
приемника
|
+------------------------------+-------------------------------+
|
Номер
|
|
в последовательности
|
+--------------------------------------------------------------+
|
Номер
|
|
подтверждения
|
+------+-----------+-+-+-+-+-+-+-------------------------------+
|Смеще-| Зарезер- |U|A|P|R|S|F|
Размер
|
| ние | вировано |R|C|S|S|Y|I|
окна
|
|данных|
|G|K|H|T|N|N|
|
+------+-----------+-+-+-+-+-+-+-------------------------------+
|
Контрольная
|
Указатель
|
|
сумма
|
|
+------------------------------+---------------+---------------+
|
Дополнительные
|
Данные
|
|
данные заголовка
| выравнивания |
+----------------------------------------------+---------------+
Рис. 4.1
Порт источника и порт приемника
16-битовые поля, содержащие номера портов, соответственно, источника и
адресата TCP-пакета. Подробное описание понятия "номер порта" дано в "Номер
порта".
Номер в последовательности (sequence number)
32-битовое поле, содержимое которого определяет (косвенно) положение данных
TCP-пакета внутри исходящего потока данных, существующего в рамках текущего
логического соединения.
В момент установления логического соединения каждый из двух партнеров
генерирует свой начальный "номер в последовательности", основное требование к
которому - не повторяться в промежутке времени, в течение которого TCP-пакет
может находиться в сети (по сути, это время жизни IP-сегмента). Партнеры
обмениваются этими начальными номерами и подтверждают их получение. Во
время отправления TCP-пакетов с данными поле "номер в последовательности"
содержит сумму начального номера и количества байт ранее переданных данных.
Номер подтверждения (acknowledgement number)
32-битовое поле, содержимое которого определяет (косвенно) количество
принятых данных из входящего потока к TCP-модулю, формирующему TCP-пакет.
Смещение данных
98
четырехбитовое поле, содержащее длину заголовка TCP-пакета в 32-битовых
словах и используемое для определения начала расположения данных в TCPпакете.
Флаг URG
бит, установленное в 1 значение которого означает, что TCP-пакет содержит
важные (urgent) данные. Подробно о данных этого типа сказано в "Важные
данные".
Флаг ACK
бит, установленное в 1 значение которого означает, что TCP-пакет содержит в поле
"номер подтверждения" верные данные.
Флаг PSH
бит, установленное в 1 значение которого означает, что данные содержащиеся в
TCP-пакете должны быть немедленно переданы прикладной программе, для
которой они адресованы. Подтверждение для TCP-пакета, содержащего единичное
значение во флаге PSH, означает, что и все предыдущие TCP-пакеты достигли
адресата.
Флаг RST
бит, установливаемый в 1 в TCP-пакете, отправляемом в ответ на получение
неверного TCP-пакета. Также может означать запрос на переустановление
логического соединения.
Флаг SYN
бит, установленное в 1 значение которого означает, что TCP-пакет представляет
собой запрос на установление логического соединения. Получение пакета с
установленым флагом SYN должно быть подтверждено принимающей стороной.
Флаг FIN
бит, установленное в 1 значение которого означает, что TCP-пакет представляет
собой запрос на закрытие логического соединения и является признаком конца
потока данных, передаваемых в этом направлении. Получение пакета с
установленым флагом FIN должно быть подтверждено принимающей стороной.
Размер окна
16-битовое поле, содержащее количество байт информации, которое может
принять в свои внутренние буфера TCP-модуль, отправляющий партнеру данный
TCP-пакет. Данное поле используется принимающим поток данных TCP-модулем
для управления интенсивностью этого потока: так, установив значение поля в 0,
можно полностью остановить передачу данных, которая будет возобновлена
только, когда размер окна примет достаточно большое значение. Максимальный
размер окна зависит от реализации, в некоторых реализациях максимальный
99
размер может устанавливаться системным администратором (типичное значение
максимального размера окна - 4096 байт). Определение оптимального размера окна
- одна из наиболее сложных задач реализации протокола TCP (см. "Исключение
малых окон").
Контрольная сумма
16-битовое поле, содержащее Internet-контрольную сумму, подсчитанную для TCPзаголовка, данных пакета и псевдозаголовка. Псевдозаголовок включает в себя ряд
полей IP-заголовка и имеет показанную на рис. 4.2 структуру.
0
7
15
31
+-----------+-----------+-----------------------+
|
IP-адрес источника
|
+-----------+-----------+-----------------------+
|
IP-адрес приемника
|
+-----------+-----------+-----------------------+
|
Нули
| Транспорт |
Длина IP-сегмента
|
+-----------+-----------+-----------------------+
Рис. 4.2
Указатель
16-битовое поле, содержащее указатель (в виде смещения) на первый байт в теле
TCP-пакета, начинающий последовательность важных (urgent) данных. Данные
этого типа и механизм их обработки описаны в "Важные данные".
Дополнительные данные заголовка
последовательность полей произвольной длины, описывающих необязательные
данные заголовка. Протокол TCP определяет только три типа дополнительных
данных заголовка:
o
конец списка полей дополнительных данных;
o
пусто (No Operation);
o
максимальный размер пакета.
Дополнительные данные последнего типа посылаются в TCP-заголовке в момент
установления логического соединения для выражения готовности TCP-модулем
принимать пакеты длиннее 536 байтов. В UNIX-реализациях длина пакета обычно
определяется максимальной длиной IP-сегмента для сети.
4.2. Номер порта
Номера портов играют роль адресов транспортного уровня, идентифицируя на
конкретных узлах сети, по сути дела, потребителей транспортных услуг, предоставляемых
как протоколом TCP, так и протоколом UDP. При этом протоколы TCP и UDP имеют свои
собственные адресные пространства: например, порт номер 513 для TCP не идентичен
порту номер 513 для UDP.
100
Примечание. Своя собственная адресация на транспортном уровне стека протоколов
сетевого взаимодействия необходима для обеспечения возможности функционирования
на узле сети одновременно многих сетевых приложений. Наличие в TCP-заголовке номера
порта позволяет TCP-модулю, получающему последовательности TCP-пакетов,
формировать раздельные потоки данных к прикладным программам.
Взаимодействие прикладных программ, использующих транспортные услуги протокола
TCP (или UDP), строится согласно модели "клиент-сервер", которая подразумевает, что
одна программа (сервер) всегда пассивно ожидает обращения к ней другой программы
(клиента). Связь программы-клиента и сервера идентифицируется пятеркой:
1.
используемый транспортный протокол (TCP или UDP);
2.
IP-адрес сервера;
3.
номер порта сервера;
4.
IP-адрес клиента;
5.
номер порта клиента.
Для того, чтобы клиент мог обращаться к необходимому ему серверу, он должен знать
номер порта, по которому сервер ожидает обращения к нему ("слушает сеть"). Для
прикладных программ, получивших наибольшее распространение в сетях на основе
TCP/IP, номера портов фиксированы и носят название "хорошо известных номеров
портов" (well-known port numbers). В UNIX-системах такие номера портов содержатся в
файле /etc/services. Ниже приводятся примеры хорошо известных номеров портов для
некоторых серверов (служб).
Служба
Номер порта
Протокол
--------------------------------ftp-data
20
TCP
ftp
21
TCP
telnet
23
TCP
smtp
25
TCP
time
37
TCP
time
37
UDP
finger
79
TCP
portmap
111
TCP
portmap
111
UDP
exec
512
TCP
login
513
TCP
shell
514
TCP
who
513
UDP
talk
517
UDP
route
520
UDP
Xserver
6000
TCP
Примечание. Обратите внимание, что некоторые серверы (такие, например, как для
службы portmap с номером порта 111) могут работать как по протоколу TCP, так и по
протоколу UDP.
Программы-клиенты, являющиеся активной стороной во взаимодействии "клиент-сервер",
могут использовать, как правило, произвольные номера портов, назначаемые динамически
непосредственно перед обращением к серверу (как любые свободные на данном узле).
101
Примечание. Любая прикладная программа (будь то клиент или сервер) может
открывать для взаимодействия любое количество портов для использования любых
транспортных протоколов.
Средства разработки сетевых приложений на базе транспортных протоколов TCP и UDP
описаны в "Сетевое программирование".
4.3. Принцип "скользящего окна"
Протоколы транспортного уровня, обеспечивающие надежную передачу данных,
предполагают обязательное подтверждение принимающей стороной правильности
полученных данных.
В "простых" протоколах сторона, отправляющая данные, отсылает пакет с данными
принимающей стороне и переходит в состояние ожидания подтверждения получения
правильных данных. Только после приема подтверждения становится возможной
следующая посылка. Очевидно, что такой подход использует пропускную способность
сети неэффективно.
В протоколе TCP используется более совершенный принцип "скользящего окна" (sliding
window), который заключается в том, что каждая сторона может отправлять партнеру
максимум столько байт, сколько партнер указал в поле "размер окна" заголовка TCPпакета, подтверждающего получение предыдущих данных.
Принцип "скользящего окна" обеспечивает "опережающую" посылку данных с
"отложенным" их подтверждением. Следует отметить недостаток этого механизма: если в
течение некоторого времени не будет получено "отсроченное" подтверждение ранее
отправленного пакета, то отправляющий TCP-модуль будет вынужден повторить посылку
всех TCP-пакетов, начиная с неподтвержденного.
Размер окна, как правило, определяется объемом свободного места в буферах
принимающего TCP-модуля.
4.4. Важные данные
Протокол TCP предусматривает возможность информирования принимающей стороны
взаимодействия отправляющей стороной о наличии в TCP-пакете важных данных (urgent
data), требующих особого внимания согласно логике прикладной задачи.
Примечание. Отличие важных данных от данных основного потока заключается в том,
что принимающая сторона должна, как правило, обработать их прежде ранее
полученных, но еще не обработанных данных потока.
Для индикации наличия в TCP-пакете важных данных используется флаг URG TCPзаголовка, местоположение важных данных в теле TCP-пакета определяется полем
"Указатель" TCP-заголовка - оно задает смещение (в стиле языка программирования C)
первого байта важных данных в теле TCP-пакета. Рис. 4.3 иллюстрирует расположение
важных данных в теле TCP-пакета.
+---------------------------+
102
|
|
|
v
+-------+-----|-----++-------------------+-------------------+
| URG=1 | Указатель ||
Данные потока
|
Важные данные
|
+-------+-----------++-------------------+-------------------+
TCP-заголовок
Тело TCP-пакета
Рис. 4.3.
Примечание. Протокол TCP предусматривает передачу важных (urgent) данных в
рамках общего потока данных ("in-band"). Существуют протоколы (например, ISO),
поддерживающие режим передачи важных (expedited) данных вне общего потока данных
("out-band"), что в общем случае быстрее.
4.5. Этапы TCP-взаимодействия
Взаимодействие партнеров с использованием протокола TCP строится в три этапа:

установление логического соединения;

обмен данными;

закрытие соединения.
Ниже с помощью трех рисунков дается описание каждого из этапов. Рисунки
иллюстрируют последовательность обмена TCP-пакетами двумя TCP-модулями: A и B.
TCP-пакеты представлены тремя полями TCP-заголовка ("Номер в последовательности",
"Номер подтверждения", "Флаги") и числом, характеризующим длину данных,
составляющих тело TCP-пакета (заметим, что реально поля длины данных в TCPзаголовке нет). Стрелками показаны направления пересылки пакетов.
TCP A
--->
--->
Номер в
Номер
Флаги
Длина
последовательности подтверждения
данных TCP B
+------------------+-------------+---------+------+
|
1000
|
| SYN
|
0 |
+------------------+-------------+---------+------+
+------------------+-------------+---------+------+
|
5000
|
1001
| SYN,ACK |
0 | <--+------------------+-------------+---------+------+
+------------------+-------------+---------+------+
|
1001
|
5001
| ACK
|
0 |
+------------------+-------------+---------+------+
Рис. 4.4
Рис. 4.4 иллюстрирует этап установления соединения, реализуемый как "трехшаговое
рукопожатие" (three-way handshake). На первом шаге TCP-модуль A, играя роль клиента,
посылает TCP-модулю B пакет с установленным флагом SYN и начальным значением
номера в последовательности равным 1000. TCP-модуль B, будучи готов со своей стороны
установить соединение, отвечает TCP-пакетом, подтверждающим правильный прием
запроса (поле "Номер подтверждения" на 1 больше начального номера в
последовательности для TCP-модуля A и среди флагов есть установленный в 1 флаг ACK)
и информирующим о готовности установить соединение (взведен флаг SYN и установлен
в 5000 начальный номер в последовательности). На третьем шаге TCP-модуль A
подтверждает правильность приема TCP-пакета от B.
103
Примечание. Некоторые протоколы транспортного уровня (но не TCP) допускают
обмен данными уже на этапе установления логического соединения.
TCP A
--->
--->
Номер в
Номер
Флаги
Длина
последовательности подтверждения
данных TCP B
+------------------+-------------+---------+------+
|
1001
|
5001
| ACK
| 50 |
+------------------+-------------+---------+------+
+------------------+-------------+---------+------+
|
5001
|
1051
| ACK
| 80 | <--+------------------+-------------+---------+------+
+------------------+-------------+---------+------+
|
1051
|
5081
| ACK
|
0 |
+------------------+-------------+---------+------+
Рис. 4.5
Рис. 4.5 иллюстрирует этап двустороннего обмена данными между TCP-модулями A и B.
TCP-модуль, принимающий адресованные ему данные, всегда подтверждает их прием,
вычисляя значение поля "Номер подтверждения" в заголовке ответного TCP-пакета как
сумму пришедшего "Номера в последовательности" и длины правильно принятых данных.
Отметим, что посылка данных к партнеру и подтверждение принятых от него данных
реализуются в рамках одного TCP-пакета.
TCP A
--->
--->
--->
Номер в
Номер
Флаги
Длина
последовательности подтверждения
данных TCP B
+------------------+-------------+---------+------+
|
1051
|
5081
| ACK,FIN |
0 |
+------------------+-------------+---------+------+
+------------------+-------------+---------+------+
|
5081
|
1052
| ACK
|
0 | <--+------------------+-------------+---------+------+
+------------------+-------------+---------+------+
|
5081
|
1052
| ACK
| 40 | <--+------------------+-------------+---------+------+
+------------------+-------------+---------+------+
|
1052
|
5121
| ACK
|
0 |
+------------------+-------------+---------+------+
+------------------+-------------+---------+------+
|
5121
|
1052
| ACK,FIN |
0 | <--+------------------+-------------+---------+------+
+------------------+-------------+---------+------+
|
1052
|
5122
| ACK
|
0 |
+------------------+-------------+---------+------+
Рис. 4.6
Рис. 4.6 иллюстрирует закрытие соединения по инициативе TCP-модуля A, посылающего
партнеру TCP-пакет с установленным флагом FIN. Прием запроса на закрытие соединения
TCP-модуль B подтверждает пакетом, содержащем в своем заголовке поле "Номер
подтверждения", значение которого (1052) на 1 больше значения принятого "Номера в
последовательности" (1051). После этого посылка каких-либо данных TCP-модулем A
становится невозможной, однако модуль B имеет данные для передачи, которые он
отправляет TCP-модулю A и получает подтверждение на их прием. Затем TCP-модуль B
формирует пакет с флагом FIN, после подтверждения его приема соединение считается
закрытым.
104
Примечание. Обратите внимание на то обстоятельство, что при подтверждении TCPпакетов, содержащих единичные флаги SYN или FIN, значение поля "Номер
подтверждения" на 1 больше значения соответствующего поля "Номер в
последовательности", несмотря на то, что никакие данные в подтверждаемых TCPпакетах не передаются.
Примечание. Рассмотренный пример не включает в себя ситуации, связанные с
"потерей" TCP-пакетов в сети, и их обработку, связанную с повторной передачей
данных.
4.6. Таймеры
Содержание
4.6.1. Таймер повторной передачи
4.6.2. Таймер возобновления передачи
4.6.3. Таймер закрытия связи
4.6.4. Таймеры поддержки соединения
4.6.1. Таймер повторной передачи
Данный таймер взводится значением RTO (Retransmission TimeOut - интервал до
повторной передачи) в момент посылки TCP-пакета адресату. Если таймер окажется
сброшенным в ноль до момента получения подтверждения пакета, то этот пакет должен
быть послан вновь.
Ясно, что величина RTO не может быть фиксированной, т.к. TCP-пакеты до разных
адресатов следуют по различным маршрутам через сети, скорость передачи данных в
которых может различаться более чем в тысячи раз. Для вычисления "оптимального"
значения RTO в каждом логическом соединении используется специальная процедура,
специфицированная в RFC 793.
Согласно этой процедуре, для каждого TCP-пакета измеряется величина RTT (Round
Trip Time - интервал времени от момента посылки TCP-пакета до момента получения
подтверждения на него). На основе измеренных RTT вычисляется величина SRTT
(Smoothed RTT - сглаженный RTT) по следующей формуле:
SRTT = k*SRTT + (1 - k)*RTT,
где k - сглаживающий коэффициент (например, 0.9).
Примечание. Приведенная формула обеспечивает фильтрацию нетипичных (пиковых)
значений измеренной величины RTT.
"Оптимальное" значение RTO вычисляется по формуле:
RTO = min(U, max(L, p*SRTT)),
где:
105
U - ограничение сверху на значение RTO (например, 30 секунд);
L - ограничение снизу на значение RTO (например, 1 секунда);
p - коэффициент "запаса" (например, 2).
Если после повторной посылки TCP-пакета, опять не будет получено его подтверждение
за интервал времени RTO, то попытки послать TCP-пакеты будут повторены (до 12 раз),
но каждый раз с экспоненциально возрастающим значением RTO. Только после неудачи
всей серии повторных посылок связь между партнерами будет считаться аварийно
закрытой.
4.6.2. Таймер возобновления передачи
В ходе взаимодействия двух TCP-модулей (A и B) вполне возможна следующая ситуация:

TCP-модуль B уведомляет TCP-модуль A о невозможности приема от него данных, определяя
размер окна равным 0;

TCP-модуль A, имея данные для передачи, переходит в состояние ожидания от TCP-модуля B
пакета с ненулевым размером окна;

TCP-модуль B, у которого освободилось некоторое пространство в буферах, посылает модулю A
TCP-пакет с ненулевым размером окна;

адресованный модулю A пакет "теряется" по какой-либо причине и оба TCP-модуля переходят в
состояние бесконечного ожидания.
Средством выхода из такого тупикового состояния и служит таймер возобновления
передачи (persistence timer - "настойчивый" таймер). Он взводится в момент получения
TCP-пакета с нулевым значением поля "Размер окна" в его заголовке (типичное начальное
значение для этого таймера - 5 секунд). Если до момента обнуления таймера не будет
получено разрешение на возобновление передачи данных, то ожидающий разрешения
TCP-модуль отправляет партнеру пакет, содержащий всего лишь 1 байт данных. По
реакции партнера, возвращающего пакет с нулевым/ненулевым значением размера окна,
TCP-модуль продолжает ожидание или возобновляет посылку данных.
4.6.3. Таймер закрытия связи
Протокол TCP предусматривает следующий простой прием предотвращения появления в
сети TCP-пакетов, не имеющих адресатов: после закрытия логического соединения между
партнерами номера портов, использовавшихся в этом соединении, остаются еще
некоторый интервал времени действительными, что дает возможность долго блуждавшим
по сети TCP-пакетам добраться до места назначения (где они будут просто
проигнорированы). Величина этого интервала равна удвоенному времени жизни IPсегмента (обычно, 2*15=30 секунд).
Примечание. Пользователи ОС UNIX могут почувствовать эффект от использования
этого приема, попытавшись перезапустить некоторую прикладную программу,
использующую TCP, сразу же после ее завершения.
106
4.6.4. Таймеры поддержки соединения
Ниже описывается механизм, используемый для проверки ненарушенности логического
соединения между TCP-модулями.
Каждый TCP-модуль, участвующий в логическом соединении, через фиксированный
промежуток времени (keep-alive timer), равный обычно 45 секундам, периодически
отправляет партнеру пустые (не содержащие данных) TCP-пакеты и ждет их
подтверждения. Каждое полученное подтверждение говорит о ненарушенности
соединения. Если же в течении определенного интервала времени (idle timer), равного
обычно 360 секудам, не будет получено ни одного подтверждения, то логическое
соединение считается оборванным.
Примечание. Очевидно, что данный механизм имеет смысл включать в работу только
тогда, когда партнеры по TCP-взаимодействию приостановили по какой-либо причине
обмен данных на достаточно длительный срок (более 45 секунд).
Примечание. Стандартная спецификация протокола TCP не включает в себя описанный
механизм, однако он реализован во всех UNIX-системах.
4.7. Алгоритмы повышения эффективности
Содержание
4.7.1. Задержка подтверждения
4.7.2. Исключение малых окон
4.7.3. Исключение коротких TCP-пакетов
4.7.4. Алгоритм медленного старта
Ниже описываются некоторые алгоритмы, используемые для повышения эффективности
взаимодействия по протоколу TCP в UNIX-реализациях и не являющиеся частью
спецификации TCP.
4.7.1. Задержка подтверждения
Задержка отсылки подтверждения принятого пакета используется для сокращения числа
TCP-пакетов, которыми обмениваются партнеры по взаимодействию. Поясним эффект от
такой задержки следующим примером.
Пусть клиентская часть некоторого приложения (например, службы telnet) направляет
серверной части некоторые данные (в случае telnet - строку символов, представляющих
команду OC UNIX, которая должна быть выполнена на удаленном узле сети). Серверная
часть, получив данные и обработав их, должна вернуть клиенту результат (в случае с telnet
- это стандартный вывод исполненной команды).
В ситуации без задержки TCP-модуль на стороне сервера, приняв пакет с данными и
разместив их в своем буфере, сразу же отвечает подтверждающим пакетом, содержащим в
107
своем заголовке и некоторый (уменьшенный) размер окна для приема последующих
данных. Спустя некоторое (обычно, очень короткое) время данные из буфера передаются
серверной части прикладной программы. Освобождение места в буфере заставляет TCPмодуль отправлять партнеру на стороне клиента TCP-пакет с новым (увеличившимся)
размером окна. Тем временем прикладная программа, обработав полученные данные
(часто за небольшое время), передает результат TCP-модулю для отсылки его клиенту, для
чего модуль формирует еще один пакет. Итого: одна транзакция потребовала от TCPмодуля на стороне сервера посылки трех TCP-пакетов.
Введение же задержки при отсылке подтверждающего TCP-пакета позволяет в ряде
случаев уменьшить количество пакетов с трех до одного, содержащего сразу
подтверждение, новый размер окна и результирующие данные. Экспериментальные
исследования показали, что во многих случаях "оптимальным" значением задержки
является 0.2 секунды.
Для того, чтобы введение задержки сказывалось минимальным образом на приложения,
предъявляющие жесткие требования к пропускной способности сети, задержка
устанавливается нулевой при условии, что размер окна изменяется более чем на 35% или
(в абсолютном исчислении) на удвоенный максимальный размер TCP-пакета.
4.7.2. Исключение малых окон
Возможны ситуации, когда прикладная программа, использующая TCP-сервис,
"выбирает" из буфера обслуживающего ее TCP-модуля пришедшие для нее данные
малыми порциями. Это приводит к генерации TCP-модулем большого количества TCPпакетов, содержащих в своих заголовках малую величину размера окна, что в свою
очередь приводит к генерации на передающей данные стороне многих TCP-пакетов с
"короткими" данными. Как результат - "засорение" сети короткими пакетами и снижение
ее пропускной способности.
Во избежание деградации сети вследствие описанного явления используется следующий
прием: TCP-пакет, информирующий посылающую данные сторону об увеличении размера
окна, формируется только при выполнении одного из двух условий:
1.
свободное место в буфере принимающего данные TCP-модуля увеличилось по крайней мере на
четверть размера этого буфера;
2.
свободное место увеличилось по крайней мере на максимальный размер TCP-пакета.
Кроме того TCP-модуль, отправляющий данные, должен делать это большими порциями.
4.7.3. Исключение коротких TCP-пакетов
"Засорение" сети короткими TCP-пакетами возможно и в ситуации, когда прикладная
программа, отправляющая данные партнеру по взаимодействию, делает это короткими
порциями (типичный пример - любая программа, использующая графическую систему X
Window System).
Для борьбы с этим используется следующий прием:
108

самая первая порция данных отправляется TCP-модулем сразу же при поступлении "коротким"
TCP-пакетом;

все последующие накапливаются в буфере TCP-модуля, пока их общий объем не составит
максимального размера TCP-пакета или не будет получено подтверждение предеыдущей посылки.
Однако этот подход может сказаться на быстродействии некоторых приложений, чтобы
избежать этого прикладной программе предоставляются средства для принудительного
"выталкивания" буферизованных данных в необходимых случаях. Кроме того, существует
возможность отключения описанного механизма.
4.7.4. Алгоритм медленного старта
Опыт эксплуатации сетей на основе TCP/IP показал, что с повышением загрузки сети
(особенно, сети со шлюзом) ее пропускная способность падает (хотя, казалось бы, она
должна оставаться постоянной). Исследования показали, что падение обусловлено
появлением в сети большого числа TCP-пакетов, повторно посылаемых к активно
используемому узлу сети (обычно это шлюз в другие сети). Дело в том, что приемный
буфер TCP-модуля на шлюзе очень быстро заполняется, и TCP-модуль вынужден
сбрасывать поступающие к нему пакеты.
Для предупреждения подобной ситуации необходимо согласование темпа передачи TCPпакетов с возможностями их приема на узле-адресате. Задачу согласования решает
алгоритм медленного старта, постепенно повышающий темп передачи данных от
медленного до "оптимального", при котором нет повторных передач TCP-пакетов.
Алгоритм использует так называемое "окно перегруженности" (congestion window),
используемое на передающей стороне для определения максимального объема
передаваемых данных вместо размера, получаемого от принимающей стороны в поле окна
подтверждающего пакета.
Размер "окна перегруженности" определяется на передающей стороне путем постепенного
его увеличения до момента появления повторных передач (ясно, что размер этого окна
никогда не превышает размера окна на принимающей стороне). Однажды определенный
размер "окна перегруженности" остается неизменным, пока вновь не появятся повторные
передачи, однако периодически делаются осторожные попытки и увеличить этот размер.
Эксперименты показали, что данный алгоритм позволяет уменьшить количество повторно
передаваемых TCP-пакетов на 50% и повысить пропускную способность сети на 30%.
5. Протокол дэйтаграмм пользователя UDP
Протокол дэйтаграмм пользователя UDP (User Datagram Protocol) является протоколом
транспортного уровня и базируется на возможностях, предоставляемых межсетевым
протоколом IP. Основная задача TCP - обеспечение "быстрой" передачи данных в сети.
Его транспортный адрес в заголовке IP-сегмента равен 17. Описание протокола UDP дано
в RFC 768.
Его основные характеристики перечислены ниже:

реализует взаимодействие в режиме без установлением логического (виртуального) соединения;
109

организует поблочный (дэйтаграммный, пакетный) тип передачи данных;

для идентификации партнеров по взаимодействию на транспортном уровне использует 16-битовые
"номера портов";

не гарантирует надежной передачи данных (возможна как потеря UDP-пакетов, так и их
дублирование);

не имеет средств уведомления источника UDP-пакета о правильности/ошибочности в его приеме
адресатом;

не обеспечивает правильный порядок доставки UDP-пакетов от источника к приемнику;

может гарантировать целостность данных в UDP-пакете за счет использования контрольной суммы;

очень прост (особенно, по сравнению с протоколом TCP).
Следует отметить, что, по сути дела, протокол транспортного уровня UDP играет роль
интерфейса для прикладных программ к средствам протокола межсетевого уровня IP.
На рис. 5.1 приведен формат заголовка UDP-пакета.
0
15
31
+------------------------------+-------------------------------+
|
Порт источника
|
Порт приемника
|
+------------------------------+-------------------------------+
|
Длина
|
Контрольная сумма
|
+------------------------------+-------------------------------+
Рис. 5.1
Порт источника и порт приемника
16-битовые поля, содержащие номера портов, соответственно, источника и
адресата UDP-пакета. Понятие "номер порта" обсуждается в "Протокол управления
передачей TCP".
Длина
16-битовое поле, содержащее длину (в байтах) всего UDP-пакета, включая
заголовок и данные.
Контрольная сумма
16-битовое поле, содержащее Internet-контрольную сумму, подсчитанную для
UDP-заголовка, данных пакета и псевдозаголовка. Псевдозаголовок (такой же, как
для подсчета контрольной суммы в TCP-заголовке) включает в себя ряд полей IPзаголовка и имеет показанную на рис. 5.2 структуру.
0
7
15
31
+-----------+-----------+-----------------------+
|
IP-адрес источника
|
+-----------+-----------+-----------------------+
|
IP-адрес приемника
|
+-----------+-----------+-----------------------+
|
Нули
| Транспорт |
Длина IP-сегмента
|
+-----------+-----------+-----------------------+
110
Рис. 5.2
Если поле "Контрольная сумма" UDP-заголовка содержит нулевое значение, это означает,
что источник UDP-пакета контрольную сумму не подсчитывал, и приемник выполнять ее
проверку не должен. Некоторые реализации протокола UDP (например, в SunOS - клоне
ОС UNIX от Sun Microsystems) контрольную сумму не подсчитывают в принципе,
полагаясь на возможности контроля целостности данных, реализованные в протоколах
сетевого уровня (например, в Ethernet).
6. Межсетевой протокол управляющих сообщений ICMP
Межсетевой протокол управляющих сообщений ICMP (Internet Control Message Protocol),
специфицированный в RFC 792, играет роль транспортного протокола для управляющей и
диагностической информации, которой обмениваются между собой IP-, TCP- или UDPмодули скрытно от приложений. Протокол ICMP поддерживается в обязательном порядке
ка ждым IP-модулем. Его транспортный адрес в IP-заголовке равен 1.
6.1. Заголовок ICMP-пакета
Поскольку протокол ICMP используется для транспортировки весьма различной
информации, то фиксируется лишь общая структура заголовка ICMP-пакета, имеющего
формат, показанный на рис. 6.1.
0
7
15
31
+-----------+-----------+-----------------------+
|
Тип
|
Код
|
Контрольная сумма
|
+-----------+-----------+-----------------------+
|
Разное
|
+-----------------------------------------------+
:
Тело пакета:
:
: IP-заголовок и следующие за ним 8 байт данных :
:
или
:
:
тестовые данные
:
+-----------------------------------------------+
Рис. 6.1
Тип
однобайтовое поле, содержащее идентификатор типа ICMP-пакета. Возможные
значения этого поля приведены в таблице.
-----------+-------------------------------Поле "Тип" | Назначение
-----------+-------------------------------0
Ответ на запрос эха
3
Адресат недоступен
4
Подавление источника
5
Перенаправление
8
Запрос эха
11
Исчерпано время жизни
12
Ошибка в параметре
13
Запрос временной метки
14
Ответ на запрос временной метки
111
-----------+--------------------------------
Код
однобайтовое поле, значение которого конкретизирует назначение ICMP-пакета
определенного типа.
Контрольная сумма
16-битовое поле, содержащее Internet-контрольную сумму, подсчитанную для всего
ICMP-пакета целиком.
Разное
четырезбайтовое поле, предназначенное для хранения разнообразной информации,
специфичной для ICMP-пакетов определенного типа (например, номера в TCPпоследовательности, IP-адреса и т.п.).
Тело пакета
Здесь содержится заголовок IP-сегмента, явившегося порождения данного ICMPпакета, и первые 8 байт данных тела этого IP-сегмента. Если ICMP-пакет есть
результат проявления аномалии в TCP- или UDP-взаимодействии, то эти 8 байт
будут представлять собой первые восемь байтов, соответственно, TCP- или UDPзаголовка, что дает возможность определить, в частности, номера портов (а,
следовательно, и использующие их прикладные программы).
Для ICMP-пакетов некоторых типов это может содержать не начало IP-сегмента, а
тестовые данные.
Источниками и обработчиками ICMP-пакетов могуть быть как IP-модули, так и TCP- и
UDP-модули (но никогда прикладные программы).
Проблемы в доставке и обработке ICMP-пакетов никогда не приводят к порождению
новых ICMP-пакетов, уведомляющих об этих проблемах. Сделано это с целью избежать
возможных бесконечных циклов генерации ICMP-пакетов в сети.
6.2. Типы ICMP-пакетов
Здесь рассматриваются 6 типов ICMP-пакетов, реализованных во всех клонах и версиях
ОС UNIX.
6.2.1. Адресат недоступен
ICMP-пакет этого типа генерируется в следующих случаях:
1.
сеть, узел сети, протокол или порт являются недоступными;
2.
в ходе продвижения по сети IP-сегмента потребовалась его фрагментация, однако в заголовке
сегмента установлен флаг DF, запрещающий делать это;
3.
предписываемый маршрут, указанный в поле дополнительных данных IP-сегмента, оказался
недействительным (несуществующим или неактивным).
112
6.2.2. Подавление источника
В ситуациях, когда некоторый узел (как правило, шлюз) не имеет достаточно места в
своих буферах для размещения интенсивно поступающих к нему данных, он может
послать узлам-источникам ICMP-пакет данного типа (source quench). Узел-источник в
ответ на такое уведомление обязан уменьшить темп передачи данных.
В ранних UNIX-реализациях протоколов TCP/IP ICMP-пакеты этого типа игнорировались.
В TCP-реализациях, поддерживающих алгоритм медленного старта, в ответ на это
сообщение уменьшается размер "окна перегруженности". UDP-модули игнорируют это
сообщение, информируя при этом обслуживаемую прикладную программу о требовании
приемника уменьшить интенсивность и/или размер дэйтаграмм.
6.2.3. Перенаправление
ICMP-пакет этого типа посылается источнику данных, когда узел-шлюз обнаруживает,
что источник может направлять свои данные непосредственно к следующему шлюзу
маршрута. Такой ICMP-пакет содержит в себе IP-адрес этого шлюза. Этот IP-адрес
должен быть включен в таблицу маршрутизации на узле-источнике данных.
6.2.4. Эхо
Для реализации эха IP-модуль на узле A отправляет узлу B ICMP-пакет типа "запрос эха",
содержащий в своем теле вместо IP-заголовка тестовые данные произвольной длины. Узел
B, получив такой запрос, возвращает узлу A ICMP-пакет типа "ответ на запрос эха",
содержащий те же данные, что и в запросе. Эхо-посылки используются для проверки
достижимости удаленных узлов сети и измерения времени прохождения данных.
6.2.5. Исчерпано время жизни
ICMP-пакет данного типа посылается источнику IP-сегмента, который должен быть
сброшен по одной из двух причин:
1) исчерпано время жизни IP-сегмента;
2) исчерпано допустимое время на сборку фрагментированного IP-сегмента.
6.2.6. Неверный параметр
С помощью ICMP-пакета данного типа источник IP-сегмента информируется о том, что
данный сегмент сброшен вследствие наличия ошибки в каком-либо из полей его
заголовка.
113
7. Концепция Глобальной информационной инфраструктуры (GII).
Началом систематической разработки концепции GII, поддержанной соответствующими
организационными мероприятиями, можно считать следующие события [1, 2, 3]:
1) совещание (meeting) JTC1 в июне 1995г. в г. Киста (Швеция), на котором была
образована оперативная рабочая группа по проблематике GII (Ad Hoc Group on GII) с
целевой задачей обеспечить планирование, организацию и проведение совместно с
организацией ITU-T, объединенного семинара ISO/IEC/ITU по стратегии стандартизации
технологий GII;
2) совещание по стандартизации телекоммуникационных технологий, состоявшееся в
Женеве в сентябре 1995г., на котором было принято решение о создании в рамках SG13
(исследовательского подразделения ITU-T, занимающегося общими сетевыми аспектами)
специальной группы по GII, получившей название JRG (Joint Rapporteur Group),
ориентированной на задачи стандартизации в области GII;
3) проведение совместного семинара ISO/IEC/ITU по стратегическим вопросам
интеграции и разработки стандартов для GII (январь 1996г.), в котором приняло участие
более 300 экспертов, работавших по следующим основным направлениям:
анализ критериев, обеспечивающих эффективность процесса стандартизации
технологий GII;
подготовка информации по проблемам GII с целью ознакомления широких кругов
общественности с возможностями технологий GII, преимуществами и перспективами их
использования;
реинжиниринг процесса стандартизации с целью повышения его эффективности,
сокращения сроков разработки стандартов.
114
Еще одним важным стартовым событием в области GII явилось совместное совещание
обеих рабочих групп JTC1 SWG-GII и ITU-T JRG, проведенное в июне 1996г. На этом
совещании JRG представила обширный доклад по GII, охватывающий следующие
вопросы:
принципы построения и архитектура GII, включая структурные и функциональные
модели GII;
определение терминологии GII;
методологию разработки сценариев и примеры ее применения;
вопросы стандартизации GII.
SWG в свою очередь представила программу работ по GII, включающую шесть
проектов, охватывающие как организационно-методические аспекты, так и основы
стандартизации GII. В частности, важное место среди указанных выше проектов
отводилось разработке, так называемого, проспекта или атласа стандартов GII (GII
Standard Roadmap). Таким образом, процесс стандартизации GII, охватывающий
несколько десятков высокоприоритетных проектов, с самого начала осуществлялся на
систематической плановой основе.
В настоящее время разработаны основные системные стандарты этой концепции.
Процесс стандартизации технологий GII продолжается достаточно динамично.
Международные стандарты GII представляются в виде Рекомендаций ITU серии Y.
Определена следующая структура стандартов серии Y:
Y.100 -Y.199 General
Y.200 -Y.299 Services, applications and middleware
Y.300 -Y.399 Networks aspects
Y.400 -Y.499 Interfaces and protocols
Y.500 -Y.599 Numbering, addressing and naming
Y.600 -Y.699 Operation, administration and maintenance
Y.700 -Y.799 Security
К важнейшим системным стандартам относятся следующие рекомендации:Y.100:1998
General overview of the Global Information Infrastructure standards development.
- Y.110:1998 Global Information Infrastructure principles and framework architecture.
- Y.120:1998 Global Information Infrastructure scenario methodology.
Именно основные положения этих стандартов и будут рассмотрены в данной главе.
Общая стратегия практического воплощения GII в жизнь предполагает эволюционный
путь развития, т.е. построение GII на основе уже существующих систем и технологий
115
посредством их последовательной модернизации и интеграции на базе новых принципов и
стандартов. В частности, потенциальными сервисами GII могут служить услуги
современной телефонии, услуги передачи данных и приложений сети Интернет.
Рассмотрим основные принципы концепции GII, а также другие, связанные с этим
вопросы.
Определение GII
Имеется ряд определений для GII. Одним из них может служить следующее [1, 2].
Под Глобальной информационной инфраструктурой или GII следует понимать
глобальную интегрированную среду телекоммуникационных и информационных сервисов
(услуг), характеризующуюся:
• «непрерывной» в пространстве и во времени физической доступностью сервисов GII,
т.е. возможностью доступа к GII в любой момент времени и в любой точке
географического пространства;
• технической простотой доступа к GII, реализуемого посредством использования
специализированных информационных устройств (приборов, терминалов) ввода/вывода
нового поколения (information appliances - IA);
• всеобщей доступностью сервисов GII, прежде всего по стоимости услуг, что позволяет
потенциально каждому человеку за приемлемую плату иметь необходимый доступ к
информационным и телекоммуникационным сервисам GII;
• гарантированностью обеспечения требуемого качества обслуживания и защиты
информации при использовании услуг GII;
• обширным ассортиментом выбора предоставляемых прикладных услуг,
охватывающих все имеющиеся виды информации: аудио, видео, графическую,
динамическую графику, данные, документы гипермультимедиа;
• функционированием на основе достижения широкого международного согласия по
общим принципам управления доступом к ресурсам GII, основанного на бесшовном
соединении взаимосвязанных, интероперабельных коммуникационных сетей,
компьютерного оборудования, информационных баз и информационных терминалов.
Еще одним взглядом на Глобальную информационную инфраструктуру является
представление ее в виде композиции (перекрестка) ряда базовых технологий,
интегрирование которых в рамках концепции GII обещает качественные изменения
условий деятельности и жизни человека. Пакет базовых технологий GII включает
следующие виды индустрий:
• компьютерную;
• телекоммуникационную;
• бытовых электронных приборов (consumer electronics);
116
• информационных приложений или сервисов, называемых также индустрией
содержаний или приложений (content or application industry).
При этом важной особенностью комбинаций базовых технологий, удовлетворяющих
требованиям концепции GII, является их согласованность, целостность и законченность, в
том смысле, что данные комбинации технологий определяют законченные сценарии
предоставления сервиса конечному пользователю.
Базовые модели GII
GII представляет собой чрезвычайно сложную комплексную технологию. Специалисты,
занимающиеся этой проблемой, пришли к выводу, что для спецификации технологий GII,
не представляется возможным обойтись некоторой единой эталонной моделью. Поэтому
для целей спецификаций свойств, услуг, принципов функционирования, организационной
структуры и других аспектов GII, используется некоторый набор базовых моделей, с
помощью которых объект исследования рассматривается с разных точек зрения.
Рассмотрим некоторые модельные представления GII.
Одной из таких моделей является модель доступа пользователей к прикладным и
коммуникационным сервисам GII. Данная модель иллюстрируется на рис. 16.1, где в
качестве основного системообразующего элемента GII показана сетевая инфраструктура
GII, образующаяся как бесшовное объединение в единую всеобъемлющую
телекоммуникационную среду разнообразных современных сетевых технологий. Сетевые
технологии, являющиеся компонентами сетевой инфраструктуры GII, показаны на модели
в виде эллипсов, внутри которых указаны типы сетей. Например, сетевыми компонентами
GII могут быть системы узкополосного и широкополосного ISDN (N-ISDN, B-ISDN), сети
передачи данных пакетной коммутации (PSDN), сети кабельного телевидения (CATV),
современные локальные сетевые технологии (LAN) и пр.
Рис. 16.1. Модель доступа пользователей к прикладным и коммуникационным сервисам GII
117
Сетевая инфраструктура GII представляет собой пространственную среду,
реализующую следующие основные функции:
• интеграцию разнообразных информационных, коммуникационных, проблемноориентированных сервисов и ресурсов, включая такие прикладные сервисы как, например:
электронная почта, видеоконференции и т.п.;
• обеспечение гарантированного персонального доступа к сервисам и ресурсам GII
независимо от времени и места нахождения потребителя с помощью применения
пользовательских информационных приборов, в качестве которых могут использоваться
различные терминалы, устройства ввода/вывода данных, коммуникационные приборы,
оборудование по обработке информации, а также их комбинации;
• все организационно-технологические аспекты, необходимые для поддержки
функционирования GII.
Для более детального описания GII применяется подход функциональной
декомпозиции (в противовес физическому представлению), посредством которого
определяется функциональная структура GII (Functional structure of the GII). Обобщенное
представление функциональной структуры изображено на рис. 16.2, на котором показаны
три функциональных уровня технологий GII, а именно, уровни:
• сетевой инфраструктуры (Network infrastructure) - самого нижнего уровня модели;
• программного обеспечения среднего уровня (Middleware);
• приложений (Applications).
118
Рис.16.2. Обобщенное представление функциональной структуры GII
Сетевая инфраструктура предоставляет надежный сервис для транспортировки
различных видов информации, включая: данные, текст, факсимильные сообщения, аудиои видеоинформацию, документы гипермультимедиа, графические образы, различные
информационные контейнеры. Она строится из разнообразных типов сетей, посредством
которых реализуется доступ пользователей к ресурсам GII. Сети, интегрированные в
инфраструктуру GII, могут иметь свою собственную более детальную структуризацию.
Сетевая инфраструктура GII охватывает также сети конечных потребителей, так
называемые, пользовательские домашние сети (customer premises networks).
Средний уровень включает функции, реализующие универсальные сервисы,
используемые многими приложениями. К числу характерных функций Middleware
относятся: средства обеспечения защиты информации, служба справочника, служба имен,
сервисы управления данными, учет стоимости обслуживания (биллинг) и т.п.
Уровень приложений охватывает широкий спектр сетевых и информационных
проблемно-ориентированных услуг (сервисов), предоставление которых конечному
пользователю и составляет основное назначение GII. Наиболее известными прикладными
сервисами являются: электронная почта, телефонный сервис, видеоконференции,
телемаркетинг, телемедицина, интерактивная передача речи и видеоданных, оперативный
поиск распределенных документов гипермультимедиа.
Следующий шаг раскрытия функциональной структуры GII состоял в разработке
описания групп однородных функций. Для этого использовались модели, называемые
моделями функционального группирования (Functional groupings). Примером одной из
119
таких моделей являлась следующая структура, включающая четыре группы функций
следующего назначения:
1) Сетевой уровень (Network Level) - самый нижний:
• включает сети коммутации, транспортные сети, пользовательские сети;
• обеспечивает сервис транспортировки информации между оконечными системами;
• обеспечивает поддержку сетевого управления.
2) Уровень организации работы сетевой инфраструктуры (Networking Level):
• моделирует логические сети, включая соответствующие средства административного
управления работой сетей, средства управления соединениями и сервисами;
• включает средства комплексирования и организации совместной работы разнотипных
сетевых технологий;
• обеспечивает различные функции для управления работой нижележащего сетевого
уровня.
3) Уровень сервиса (Service Level):
• реализует функции обработки, хранения и распределения информации;
• предоставляет функции вызова приложений и управления ими;
• осуществляет поддержку мультимедиа технологий;
• предоставляет развитые телекоммуникационные сервисы как для бизнес-приложений,
так и для конечных пользователей.
4) Уровень приложений (Application Level):
содержит полный спектр прикладных услуг, предоставляемых GII.
Следующий уровень детализации описания свойств GII соответствует так называемым
функциональным моделям (Functional models). Их примером может служить модель,
приведенная на рис. 16.3. Данная модель определяет состав функциональноориентированных систем (элементов GII), входящих в сетевую инфраструктуру, и
стековую архитектуру функциональных модулей, реализуемых этими системами.
Типами элементов данной функциональной модели GII являются:
• оконечное оборудование пользователей (End User Equipment - EUE), как, например,
информационные приборы (Information Applainces - IA);
• сети доступа к ядру сетевой инфраструктуры GII (Access Network);
• сети ядра инфраструктуры GII (Core Network);
• пользовательские (домашние) сети (Customer Premises Network);
120
• серверы приложений (Application Server);
• серверы брокерских услуг (Brokerage Server) и пр.
Стековые структуры функциональных модулей зависят от типа систем, на которых они
реализуются. Так, например, для оконечной системы такой стек состоит из следующих
пяти уровней модулей:
• транспортного (transport), обеспечивающего базовый сервис транспортировки данных;
• управления транспортом (transport control), реализующего расширенные функции
сетевого управления, например, управление виртуальными сетями;
• навигации (navigation), обеспечивающего функциональность, связанную с поиском и
перемещением информации в сети по запросам пользователей;
• форматирования информации, предназначенного для реконфигурации данных при
использовании многих форматов представления данных, а также обеспечения вывода
информации в терминах культурных элементов конечного пользователя;
• собственно приложений (Application).
Для сетевых элементов инфраструктуры GII стек включает только два модуля самых
нижних уровней.
Рис.16.3. Модель функциональной архитектуры протоколов GII
121
Первоначально при разработке стандартов технологий GII основное внимание
уделялось их функциональным и архитектурным свойствам. В последствии была осознана
важность нацеленности концепции GII на коммерческие применения, что обеспечило бы
поддержку соответствующих проектов со стороны бизнеса. Поэтому в концептуальных
стандартах Y.100 и Y.110 важная роль отводится так называемой корпоративной модели
сервисов GII, предназначенной для описания основанных на GII бизнес-приложений и
идентификации наиболее коммерчески значимых интерфейсов. Данная модель
рассматривается ниже.
В конце данного раздела отметим некоторые принципиальные моменты,
сформулированные специальной группой по развитию концептуальной структуры и
архитектуры GII в виде следующих рекомендаций:
- предпочтительное использование в качестве программных сред разработки
приложений GII наиболее распределенных протоколов таких, как:
• CORBA и CORBA IDL,
• WWW, Java, Java Beans и IIOP,
• ActiveX и DCOM,
а также использование эталонных моделей IN (интеллектуальной телефонии) и OSI как
единственных методологических основ для построения GII;
- предпочтительное использование при развитии сетевой инфраструктуры наиболее
распространенных и перспективных услуг IP и ATM, при этом, что важно, с поддержкой
предоставления дифференцированного качества услуг (QoS);
- введение в услуги GII характеристик, свойств и требований, соответствующих бизнесприложениям, что обеспечит более адекватное отражение множества взаимоотношений,
возникающих в сфере коммерции в плане ее взаимодействия с GII;
- учет при рассмотрении GII, наряду с функциональными, сервисных аспектов,
включающих контроль за качеством обслуживания (QoS) и управление ресурсами;
- широкое использование интеллектуальных информационных приборов (терминалов) с
гибкими функциональными возможностями, адаптируемых к изменяющимся среднему
уровню (middleware) и приложениям (application) (т. е. имеющих возможность загружать
соответствующие им ПО);
- полная стандартизация спецификаций базовых телекоммуникационных стандартов,
программных интерфейсов и их основных функциональных возможностей;
- первоочередность анализа потребностей бизнеса, коммерческая обоснованность
решений по развитию GII, выбор необходимых функций и протоколов с учетом их
коммерческого применения и управляемости.
Корпоративная модель GII (enterprise model)
122
Целью корпоративной модели является идентификация интерфейсов, имеющих
наибольшее коммерческое значение. Одним из центральных понятий при построении
данной модели служит понятие роли.
Роли исполняются участниками взаимодействия и обладают определенным временем
жизни. Роли обладают интерфейсами. Они принимают от поставщиков сервис или услугу
("товар"), изменяют ее (или добавляют дополнительными свойствами) и передают далее
свои пользователям, образуя, таким образом, некую цепочку, достигающую конечного
потребителя (рис. 16.4).
Одна такая цепь может представлять собой некоторую отрасль промышленности.
Рис. 16.4. Цепочка добавочной стоимости
Модель включает в себя следующие определения:
• роль - некоторая коммерческая активность, включаемая в цепь передачи услуги
(товара);
• цепь передачи услуги (продукта) - "дерево" ролей, объединяемых для предоставления
конечной услуги;
• структурная роль - роль в основной промышленной цепи, т. е. имеющая некоторый
производимый продукт (услугу) и связанная с экономической или деловой активностью в
области информационных услуг и приложений;
• инфраструктурная роль - представляет элемент цепи, главным образом связанный с
повторным использованием компонентов;
• участник - организация или индивидуум, выполняющий одну или несколько ролей,
может быть коммерческой, правительственной или неправительственной организацией;
• отношения между ролями - возникает при соединении двух ролей в цепи с целью
передачи услуги (товара);
• горизонтальные отношения - отношения между двумя соседними ролями,
находящимися в одной цепи (структурное отношение);
123
• вертикальные отношения - отношения между двумя ролями, находящимися в разных
цепях;
• сегмент - часть роли.
При данном различии между ролями и участниками понятно, что модель может
относиться только к понятиям роли.
Структурные роли относятся к чистому производству продукта (услуги) и формируют
цепь от начальных данных до конечной услуги (рис. 16.5).
Структурные роли информационной индустрии включают в себя следующие:
• источник информации, преобразующий "сырую" информацию в вид, удобный для
использования;
• роль создания и производства информации, получающая на ее основе доставляемую
информацию;
• предоставление информации, преобразующее последнюю в применимую
информацию;
• роль создания и производства информационных услуг и приложений, создающая из
применимой информации информационную услугу;
• роль предоставления информационных услуг, либо распространяющая
информационную услугу, либо разделяющая ее на контейнеры, воспринимаемые
пользователем;
• роль конечного пользователя.
Рис. 16.5. Пример структурной роли
В отношениях между ролями одна из них представляет собой поставщика, другая потребителя некоторого ресурса (например, информации), что требует присутствия также:
• управляющей роли (manager role), администрирующей отношение между
структурными ролями,
• посреднической роли (broker role), принимающей участие во взаимодействии и
выбирающей промежуточного поставщика и потребителя.
124
Отношение между данными ролями показано на рис. 16.6.
Рис. 16.6. Типы и взаимосвязь ролей
Инфраструктурные роли относятся к деятельности, помогающей структурным ролям
обмениваться необходимой им информацией, хотя и не должны ничего знать о характере
этого обмена, и, таким образом, предоставляют последним инфраструктурные услуги,
товары, приложения (рис. 16.7). Структурные роли не являются частью GII.
Рис. 16.7. Инфраструктурные и структурные роли
Можно определить некоторые инфраструктурные роли, присутствующие в GII:
• обеспечение базовых и расширенных телекоммуникационных услуг и приложений
(например, телефонная услуга);
125
• обеспечение базовых и расширенных коммерческих коммуникационных услуг и
приложений (например, компьютерная телефония);
• обеспечение радиовещательных и телевизионных услуг и приложений
(широковещательные услуги);
• обеспечение услуг и приложений распределенной обработки и хранения информации.
Динамика и эволюция ролей
Естественно, что окружение постоянно изменяется, в связи, с чем можно определить
динамику инфраструктурных ролей:
• микрофункциональная динамика - изменение в рамках событий индивидуальных
транзакций;
• потенциальная функциональная динамика - при возможности обнаружения тенденций
имеющих место событий;
• макрофункциональная динамика - изменение поведения при сохранении набора услуг
и архитектуры;
• эволюционная динамика - последовательности функциональных периодов,
сопровождающихся сильными изменениями.
Эволюция инфраструктурных ролей, побуждаемая процессами конвергенции
имеющихся технологий, включает следующие пути модификации определенных выше
четырех типов ролей:
• автономная эволюция,
• конвергенция двух текущих ролей,
• конвергенция трех текущих ролей,
• конвергенция всех четырех текущих ролей.
Такой конвергенции может сопутствовать возникновение новой координирующей и
обеспечивающей роли (рис. 16.8).
Эволюция привела к появлению новой инфраструктурной роли - обеспечение
коммуникаций и сетевого взаимодействия информационных услуг и приложений.
Важность использования корпоративной модели состоит еще и в том, что понятие
качества услуги (QoS) проявляется как таковое на уровне прав и обязательств
поставщиков и пользователей услуги, в то время как с чисто технической точки зрения
QoS не является значимым аспектом взаимодействия.
126
Рис. 16.8. Пример конвергенции ролей
Структурная модель GII (structural model)
Целью структурной модели является идентификация услуг и предоставляемых
приложений, предлагаемых ролями (рис. 6). Как видно из рисунка, для предоставления
услуги роль должна объединить ресурсы в применимый набор. Ресурс может
предоставляться другой ролью, то есть быть приложением или услугой другой роли.
Рис. 16.9. Структурная модель GII (structural model)
Семантика структурной модели поддержана следующими определениями:
• услуга - традиционно понимаемая как взаимодействие между компонентами системы,
характеризуется транзакциями между ролями, и в общем случае роль клиента
запрашивает роль сервера о необходимой информации;
• приложение - воспринимается подобно услуге, с тем отличием, что приложение может
быть использовано повторно;
• домен (область, область ответственности, сфера, отрасль) - набор сегментов во
владении участника;
• платформа обеспечения услуги - основа предоставления услуги, состоящая из набора
сегментов, для этого необходимых, и может включать несколько доменов;
• контракт - основа соглашений между двумя участниками, исполняющими разные
роли, определяющая порядок взаимодействия между ними;
127
• интерфейс услуги - средства использования услуги участником взаимодействия,
включающие аспекты межролевых отношений, информационные, вычислительные,
раелизационные;
• сервисная компонента - компонента интерфейса услуги;
• сегмент - сущность, общая для корпоративного, структурного и функционального
моделирования.
Структура услуг и приложений
Пользователь может использовать чистую услугу или работать с приложением. В этом
случае приложение использует услугу GII, но в то же время и приложение может быть
реализовано в GII или использовать компоненты приложений, реализованные в GII.
Со своей стороны GII объединяет необходимые сетевые ресурсы, ресурсы обработки и
хранения, ресурсы среднего уровня (middleware). Услуги и приложения строятся из так
называемых "строительных блоков", то есть компонентов, ассоциированных с ресурсами.
Предоставление инфраструктурных услуг зависит от уровня сложности разработанных
инфраструктурных ролей. До недавнего времени эти роли были довольно просты и
пользователи покупали компоненты приложений, но с развитием GII эти характеристики
будут доступны уже в качестве услуги более сложной системы коммуникаций и
организации работы инфраструктуры информационной роли GII. Таким образом,
проявляется тенденция переходом компонент приложений на средний уровень
(middleware).
Число возможных услуг велико, поэтому вводится некоторая классификация сервисных
компонентов.
Определяются следующие классы сервисов:
Инфраструктурные сервисные компоненты
Эти компоненты образуют полный набор сервисных компонент GII. Они могут
реализовывать как возможности высокого уровня (как, например, безопасность), так и
других распределенных ресурсов, то есть middleware и baseware. Роли GII представляют
использование компонентов пользователям GII, например, структурным ролям.
Компоненты инфраструктурной услуги можно разделить на следующие категории:
• А1 - информационные коммуникации и их организация (CNI): данные компоненты
могут напрямую предоставлять коммуникационные услуги, однако в большинстве своем
связаны с компонентами среднего уровня, включая:
- компоненты услуг человеко-машинного интерфейса,
- компоненты услуг регистрации,
- компоненты услуг аутентификации,
- компоненты услуг безопасности,
128
- компоненты услуг директории,
- компоненты услуг биллинга и т.д.
• А2 - предоставление общей коммуникационной услуги (GCSP): компоненты данной
категории переносят данные, видео и голос посредством PSTN, ISDN, X.25, Frame Relay,
CBDS, мобильных сетей, частных сетей, CATV, широковещательного телевидения,
спутниковых сетей, однако развитие сетей ATM предоставит более полный набор
сервисных компонент.
• А3 - обработка и хранение информации (IPS): основными компонентами данной
категории являются:
- подсоединение, вызов, управление компонентов приложения,
- сохранение и извлечение информации.
Доступ к компонентам обычно осуществляется через API.
• А4 - поддержка создания услуги/приложения (ASCS): данные компоненты позволяют
пользователям компилировать и строить приложения и услуги и специфичны для
прикладных платформ.
Сервисные компоненты среднего уровня (middleware)
Компоненты в общем случае используют только ресурсы middleware и не требуют
других распределенных ресурсов. В этот класс сервисов включаются компоненты
базового уровня, расширенные необходимой функциональностью, что позволяет
организовать работу инфраструктуры.
Кроме того, компоненты сервиса middleware можно дополнить следующими
категориями:
• М1 - услуги взаимодействия GII (IS): компоненты, направленные на организацию
работы инфраструктуры и поддержку распределенных приложений, а также на
необходимые преобразования форматов сообщений и данных. Эта категория может быть
отражена подходом OMG к использованию языка определения интерфейсов CORBA
(CORBA IDL).
• М2 - услуги кооперирования GII (CS): компоненты предоставляют средства
совмещения базовых коммуникационных услуг с возможностями хранения и обработки.
• М3 - услуги ввода в действие и предоставления характеристик (EFPS): компоненты,
поддерживающие категорию А1 компонентов инфраструктурной услуги.
Сервисные компоненты базового уровня (baseware)
Компоненты делятся на компоненты базовой сетевого сервиса и компоненты услуг
распределенной обработки и хранения. Сервис, требующий соединения одной сети через
различные домены является сервисом базового уровня, в то время как сервис, требующий
соединения различных сетей является сервисом среднего уровня.
129
Компоненты услуги baseware можно разделяются на следующие категории:
• В1 - сервисы распространения (DS), ответственные за:
- передачу компонентов среднего уровня или приложений между отдельными
платформами, соединенными телекоммуникационной услугой,
- удаленную загрузку и выполнение компонентов среднего уровня или приложений,
- удаленный вызов услуг удаленных компонентов среднего уровня или приложений.
• В2 - сервисы интерфейса HCI (HCIS), выполняющие:
- отображение графических образов или видео потока на экране,
- проигрывание звукового потока,
- передача событий от клавиатуры или мыши,
- передача графических образов или видео потока от камеры или другого источника,
- передача звукового потока от микрофона аудиоисточника.
• В3 - сервисы фактической транспортировки, обработки и хранения (ATPSS),
осуществляющие:
- исполнение потоков задач в рамках выполнения процесса,
- сохранение данных в устройстве памяти (например, RAM, HD),
- передачу данных между интерфейсами,
- передача сообщений поддержки В1, В2 и В4.
• В4 - сервисы поддержки функций управления и менеджмента (CMFSS), ответственные
за:
- базовое управление выполнением потоков задач в информационном устройстве,
- базовые возможности сохранения и извлечения файлов,
- базовые компоненты соединения, вызова, управления сеансом связи,
- базовые компоненты менеджмента, относящиеся к базовым компонентам
транспортировки, обработки и хранения.
Рассмотренная выше корпоративная модель GII предоставляет развитый
концептуальный базис и соответствующий язык для описания ролевых свойств активных
элементов и их взаимосвязей при проектировании бизнес-процессов, поддержанных
сервисами GII.
Функции и логические интерфейсы GII. Функциональная модель
130
Для независимого от реализации описания GII необходимо описание функций и
логических интерфейсов между ними. Вводятся следующие типы функций:
• прикладные функции - логические сущности приложений (объекты приложения);
• функции среднего уровня - логические сущности среднего уровня (объекты среднего
уровня);
o функции управления услугой (SCF) - функции среднего уровня, позволяющие
"строить" услуги из сервисных компонент и ресурсов;
o функции менеджмента (MF) - функции среднего уровня, администрирующие все
другие функции;
• функции базового уровня (BF) - логические сущности, предоставляющие функциям
приложений и среднего уровня возможности работы, взаимодействия и организации
интерфейса с пользователем;
o сетевые функции (NF) - логические сущности, поддерживающие коммуникации и
включающие транспортные (TF) и управляющие (CF) функции;
o функции распределения (DF) - обеспечивающие безопасную передачу компонентов
приложений и среднего уровня, их загрузку и вызов;
o функции обработки и хранения (P&SF) - логические сущности, выполняющие
компоненты приложений и среднего уровня и сохраняющие информацию;
o функции человеко-машинного интерфейса (HCIF).
Существуют также типы логических интерфейсов:
• прикладной протокол - логический интерфейс между функциями приложений;
• прикладной программный интерфейс - логический интерфейс между функциями
приложений и функциями среднего уровня,
• протокол среднего уровня - логический интерфейс между функциями среднего уровня,
• базовый программный интерфейс (BPI) - логический интерфейс между функциями
среднего уровня и функциями базового уровня,
• протокол базового уровня - логический интерфейс между функциями базового уровня,
• человеко-машинный интерфейс - логический интерфейс между пользователем
(человеком) и функциями базового уровня (хотя могут включать и интерфейс с
функциями среднего уровня и приложений),
• телекоммуникационная эталонная точка - логический интерфейс между функциями
базового уровня и сетевыми функциями, или между сетевыми функциями.
Функции и логические интерфейсы GII иллюстрируются на функциональной модели
GII, представленной на рис. 16.10.
131
Рис. 16.10. Функциональная модель GII. Функции и интерфейсы GII
Сетевые функции и домены сетевых операторов
Основные функции, требуемые для создания телекоммуникационной сети, как
минимум должны включать транспортные функции, функции управления и менеджмента.
В дополнение к этому развитие интеллектуальных сетей ставит необходимость в
присутствии некоторых других функций - функций предоставления расширенных услуг.
Эти функции могут долее быть разбиты на сегменты.
Для выполнения услуг базового уровня требуется реализация функций baseware,
включая:
- функции поддержки загрузки и выполнения компонентов,
- функции поддержки локального вызова методов и компонентов,
- функции поддержки удаленного вызова методов и компонентов,
- функции поддержки человеко-машинного интерфейса.
Модель реализации GII (implementational model)
Формальная стандартизация сама по себе заканчивается функциональной моделью, чего
обычно хватает для того, чтобы гарантировать интероперабельность между оператором и
производителями оборудования или программного обеспечения. Однако в некоторых
случаях становится полезным определять типовые модели реализации, описывающие
примеры отображения функций функциональной модели на базовые технологии и
оборудование.
Данная модель опирается на следующие определения:
• оборудование - реализация одной или более функций в одном физическом элементе;
оборудование имеет как минимум одну функцию, реализованную аппаратно;
• программный модуль - реализация одной или более функций программным способом;
132
• информационное устройство - определенный тип оборудования, предназначенный для
использования в GII и имеющий доступ к программным модулям, обеспечивающим
функциональность структурных ролей GII;
• интерфейс реализации - интерфейс между компонентами реализации, то есть между
оборудованием двух типов или между оборудованием и программным модулем;
• физический интерфейс - интерфейс реализации между оборудованием двух типов,
требующий физической среды для передачи информации;
• прикладной программный интерфейс - внутренний для оборудования интерфейс
реализации между оборудованием и программным модулем;
• система - набор оборудования и программных модулей, работающих как единая
сущность;
• сегмент - одна или несколько систем, выполняющих функции, определенные в
сегменте функциональной модели.
Реализация системы подразумевает объединения сегментов инфраструктурной модели,
которые включают следующие типы:
• информационные устройства, дающие пользователю доступ к GII, например, STB,
сетевой компьютер, миникомпьютеры и мейнфреймы, файловые и видеосерверы,
телефоны, факсимильные аппараты, TV;
• программные модули Middleware, работающие на информационных устройствах;
• прикладные программные модули;
• сегменты телекоммуникационной сети, соединяющие информационные устройства,
например, сегменты доступа, базовые сегменты, сегменты предоставления расширенных
услуг, сегменты менеджмента.
Между информационными устройствами и сегментами телекоммуникационной сети
присутствуют физические интерфейсы, как видно из рис. 16.11.
Рис. 16.11. Подключение информационных приборов в сетевым сегментам GII
Язык спецификации сценариев GII
GII представляет собой объединение многих типов технологий, в частности,
коммуникационных, хранения и обработки информации. Поэтому при анализе и
проектировании конкретных сервисов приходится рассматривать композиции
взаимосвязанных функций, систем и технологий.
133
Понятие сценария вводится как, прежде всего, графическое представление
конфигураций функциональных и сетевых элементов GII, а также их взаимосвязей.
Фактически язык сценариев, применяемый для описания технологий GII и их
взаимосвязей, представляет собой некоторый схемотехнический язык.
По существу аппарат сценариев, как и аппарат профилей, предназначен для
функциональной стандартизации технологий GII, но обладает большей гибкостью,
особенно при условии, когда создание базовых стандартов GII еще не завершено.
Следует подчеркнуть, что сценарии рассматриваются как элементы стандартизации, и
одна из задач организаций, отвечающих за стандартизацию GII, состоит в том, чтобы
разработать и сопровождать банк стандартных сценариев, описывающих типовые
решения по комплексированию технологий GII.
При этом язык сценариев рассматривается так же как методологическое средство,
которое будет способствовать систематизации, классификации и стандартизации
аспектов, связанных с GII.
Язык сценариев является графическим языком описания конфигураций технологий GII
и содержит следующие основные графические элементы:
1. сетевые элементы, обычно изображаемые в форме эллипса, внутри которого
помещается тип изображаемого объекта;
2. функциональные модули (например, информационные устройства, узлы коммутации,
маршрутизаторы), изображаемые прямоугольниками, внутри которых помещается
название реализуемой функции или тип приложения;
3. интерфейсы, изображаемые закрашенным кружком, разделенным чертой - границей
взаимодействия элементов, при этом над изображением интерфейса помещается текстовая
строка с типом интерфейса, а под кружком интерфейса может следовать квалификатор, с
помощью которого специфицируются протоколы, реализующие данный интерфейс;
4. связи между взаимодействующими элементами, изображаемые сплошными линиями,
в разрыв которых помещаются изображения соответствующих интерфейсов;
5. логические связи или ассоциации, изображаемые пунктирными линиями, на которые
также могут накладываться графические символы интерфейсов;
6. квалификаторы (Qualifiers) - описатели наборов протоколов.
Первоначально рассмотрим состав базовых типов сетевых элементов языка. Основными
из них являются:
a) core network (сеть ядра инфраструктуры GII);
b) access network (сеть доступа к ядру сетевой инфраструктуры GII);
c) backbone switching network (коммутирующий бэкбон сетевой инфраструктуры GII);
d) local switching network (коммутирующая локальная сеть);
134
e) local distribution network (сеть локального распространения);
f) final distribution or drop network (конечная сеть пути доступа);
g) customer premises network (пользовательская домашняя сеть).
Состав указанных выше элементов GII отражает подход к структурированию сетевой
инфраструктуры GII, при котором вводится некоторая типовая структура сетевого
доступа. В общем случае при взаимодействии через GII оконечных систем, например,
двух устройств IA-a и IA-b, путь сетевого доступа будет включать следующие сетевые
элементы:
IA-a <--> premises network <--> access network <--> core network <--> access network <->
premises network <--> IA-b.
В свою очередь каждый из сетевых элементов также может структурироваться. Так,
например, структура сети доступа к сетевому ядру GII (access network) в общем случае
состоит из следующих сетевых элементов:
local switching network (локальная коммутирующая сеть)
local distribution (локальная дистрибутивная сеть)
final drop (конечная сеть).
К стандартным типам функциональных модулей относятся:
1) Information Appliance (IA) - информационное устройство или прибор - общий термин
для терминальных устройств (устройств ввода/вывода), используемых приложениями.
Примерами таких устройств могут служить органайзеры-коммуникаторы, компьютеры,
телефонные аппараты, телевизионные приемники и т.п.;
2) Adaptation Unit (A) - модуль или функция, осуществляющая сопряжение конкретного
информационного устройства со стандартным интерфейсом пользовательской сети (OnPremise Interface - OPI);
3) Network Interface Unit (NIU) - модуль сетевого интерфейса;
4) Network Terminating Unit (NT) - оконечный сетевой модуль.
Модель взаимосвязи введенных выше сетевых структур GII и функциональных
элементов иллюстрируется на рис. 16.4.
135
Рис. 16.4. Модель взаимосвязи сетевых структур и функциональных элементов GII
В языке сценариев используется следующий набор основных типов интерфейсов:
1) Network-to-Network Interface Type A (NNI-A) - интерфейс между бэкбоном (backbone)
глобальной сети и локальной сетью.
2) Network-to-Network Interface Type B (NNI-B) - интерфейс между двумя
равноправными бэкбонами (backbone) глобальных сетей.
3) Access-Network Interface (ANI) - интерфейс доступа к сети, представляет интерфейс
между локальной коммутирующей сетью и дистрибутивной сетью в рамках сети доступа.
4) Drop-Distribution Interface (DDI) - интерфейс между сетью локального
распространения и конечной сетью, к которой подключается пользовательская сеть.
5) Premise-Attachment Interface (PAI) - интерфейс между внешней сетью и внутренней
сетью пользователя или оборудованием пользователя.
6) Adaptation Interface (AI) - интерфейс между адаптером и информационным
устройством.
7) On-Premise Interface (OPI) - интерфейс между пользовательской домашней сетью и
информационным устройством.
Пример сетевой конфигурации, описанной с помощью языка сценариев, показан на рис.
16.5, где иллюстрируется схема предоставления услуг передачи аудио/видео/цифровых
данных конечному пользователю, которые обеспечиваются локальной
телекоммуникационной компанией (Telco) с использованием цифровых каналов
технологий B-ISDN (интерфейс В) и N-ISDN (интерфейс Н), а также с использованием
местной кабельной телевизионной сети.
136
Рис.16.5. Пример сценария GII
Различаются общие или родовые элементы сценариев, соответствующие общим типам
объектов, и их экземпляры, конкретизирующие типы элементов вплоть до указания
ссылок на конкретные стандарты, которым эти элементы должны удовлетворять. Этот
принцип распространяется на другие типы объектов, включая интерфейсы,
функциональные блоки, а также сами сценарии.
Построенные перечисленными выше средствами сценарии позволяют в наглядной
форме отражать сложные конфигурации элементов, интерфейсов и сервисов. В то же
время сценарии, в которых конкретизируются типы компонентов указанием ссылок на
стандарты соответствующих им технологий, представляют собой способ
комплексирования наборов технологий и сервисов, а также их точной спецификации.
Сценарии могут также использоваться в качестве базовых документов в организационных
процессах при разработке стандартов и собственно технологий GII.
Проспект стандартов и стандартизация GII
Важное место среди организующих документов по GII сыграл проспект или атлас
технологий GII, называемый ”GII Roadmap” или ”GII Standards Roadmap” [3] и
рассматриваемый в качестве руководства по разработке и развитию стандартов GII. В
этом стратегическом документе определены:
- принципиальные свойства технологий GII,
- состав основных сервисов и приложений,
- организационная инфраструктура стандартизации технологий GII.
137
Рассмотрим основные положения данного документа.
Во-первых, в Roadmap определены состав основополагающих свойств (attributes),
которым должны удовлетворять элементы GII (сервисы, приложения, сетевые
технологии). Данные свойства должны рассматриваться в качестве базовых требований
при разработке стандартов GII. В их число входят следующие свойства:
1) приемлемость по стоимости услуг (affordability), предоставляемых GII;
2) доступность (availability) - мера возможности использования сервисов или ресурсов
GII;
3) поддержка национальных и местных особенностей (диалектов) в элементах культуры
(cultural elements), имея ввиду использование национальных алфавитов и
соответствующих им шрифтов, локальных правил представления адресов и различных
кодов (дат, телефонных номеров, валюты, наименований стран и пр.);
4) интероперабельность (interoperability) - способность систем или приложений
обмениваться информацией и совместно ее использовать;
5) управляемость (manageability) - возможность для организаций и пользователей
контролировать распространение и использование их ресурсов;
6) минимальность требований (minimalism), необходимых для функционирования
ресурсов;
7) мобильность (mobility) - возможность доступа к ресурсам независимо от
местоположения пользователя, а также способность инфраструктуры GII
идентифицировать и определять местоположение источника запросов;
8) непрерывность обслуживания в пространстве и во времени (nomadicity);
9) производительность (performance), включая такие характеристики, как, например,
время ответа, пропускная способность, скорость обработки транзакций, скорость
регенерации изображений и пр.;
10) переносимость (portability) - легкость переноса программного обеспечения и данных
с одной системы на другую;
11) качественность (quality) - -обеспечение уровня качества, который ожидает получить
получатель сервиса;
12) надежность (reliability) - вероятность того, что продукт или система будут
выполнять должным образом свои функции за определенный период времени;
13) масштабируемость (scalability) - свойство продуктов, сервисов, систем эффективно
выполнять свои функции при широком диапазоне параметров, определяющих
технические и ресурсные характеристики нижележащей платформы и/или
поддерживающей среды (примерами таких характеристик могут служить: число
процессоров, число узлов сети, максимальное число обслуживаемых пользователей,
количество обрабатываемых транзакций);
138
14) безопасность (security) - защита ресурсов (аппаратных, программных,
информационных) от случайных или преднамеренных действий, вызывающих
несанкционированный доступ к ресурсам и нарушение конфиденциальности их
использования, модификацию и разрушение ресурсов, а также раскрытие информации;
15) легкость использования (usability) продуктов, сервисов, приложений GII.
Ядром рассматриваемого документа служит базовая модель классификации стандартов
GII, показанная на рис. 16.6. Данная модель является трехуровневой и трехмерной.
Она включает следующие уровни функций:
1) Области приложений (Application Areas) - верхний уровень.
2) Сервисы GII (GII Services).
3) Средства реализации сервисов (Service Implementation Tools).
Первый уровень функций включает разнообразные прикладные сервисы такие, как,
например: развлечения и видео по требованию, электронная коммерция, различные виды
коммуникационных сервисов, интерактивная передача речи и видео, оперативный поиск
распределенных документов гипермультимедиа (WWW и базы данных графических
образов), интерактивный видеосервис (видеоконференции, телемедицина, дистанционное
образование, телемаркетинг, телеголосования), кооперативная работа на дому,
виртуальные корпорации и т.д.
139
Рис. 16.6. Базовая модель классификации стандартов GII
Для более полной классификации функциональных элементов GII и их связывания с
элементами организационной инфраструктуры средний слой данной модели развивается
по следующим трем направлениям (размерностям):
1) Общие классы сервисов (Generalized Service Categories), используемые для
поддержки приложений и объединяющие некоторые наборы фундаментальных
строительных блоков в функционально специализированные сервисы или службы.
140
2) Фундаментальные строительные блоки (Fundamental Building Blocks - FBB), которые
представляют собой унифицированные средства, позволяющие ускорить разработку
приложений и сервисов, а также повысить их надежность.
3) Организации-разработчики стандартов (Standard Development Organizations - SDO),
т.е. организации или их структурные подразделения, ответственные за разработку
стандартов средств, фундаментальных сервисов, производных сервисов и приложений.
В модели выделены фундаментальные строительные блоки, охватывающие следующие
методы и механизмы:
1) Методы доступа (Access Methods) - для обеспечения управляемого доступа к
ресурсам.
2) Адресации (Addressing) - для применения стандартных механизмов идентификации
местоположения объектов, приложений, каналов и маршрутов навигации данных.
3) Компрессии (Compression) - для оптимизации транспортировки данных.
4) Информирования потребителя услуг об их текущей стоимости и реализации
процедуры оплаты за предоставляемые услуги (Cost Quotation).
5) Навигации данных (Data Navigation) - для обеспечения перемещения информации
через инфраструктуру GII.
6) Идентификации (Identification) - для различения экземпляров объектов, соединений,
пересылаемых блоков данных и оптимизации работы с ними.
7) Интернационализации (Internationalization) - для настройки приложений на
генерацию текстов на требуемых языках.
8) Интероперабельности (Interoperability) - для обеспечения возможности обмена
информацией между функциональными компонентами GII, а также взаимного
использования обмениваемой информации.
9) Управления временем передачи (Latency Control).
10) Непрерывного обслуживания мобильных потребителей информации
(Nomadicity/Mobility) - для сохранения доступа к сервисам независимо от того что
пользователь может перемещаться в пространстве и во времени.
11) Приоритетного управления (Priority Management) запросами к сервисам.
12) Обеспечения приватности и прав собственности (Privacy/Ownership) - для гарантии
конфиденциальности передаваемых через GII данных, а также их защиты от
несанкционированного чтения, изменения и копирования.
Другую размерность для второго уровня модели определяют общие классы сервисов,
включающие следующие элементы:
1) Сервисы обмена данными (Data Interchange Services) для передачи текстовой
информации.
141
2) Сервисы обмена графическими данными (Graphic Services), включая движущиеся
образы.
3) Сервисы обмена и генерации аудиоинформации (Audio Services).
4) Сервисы представления данных (Data Presentation Services) с использованием
различных форматов и механизмов преобразования одних форм представления в другие.
5) Сервисы управления данными (Data Management Services) для управления хранением
и восстановлением данных, используемых средствами GII.
6) Сервисы расчета стоимости используемых услуг (Cost Billing Services).
7) Сервисы сетевого управления (Network Control Services) - для управления передачей
данных через одну или более сетей.
Уровень средств реализации сервисов разбивается вертикально на три общих класса
сервисов, а именно:
• коммуникационные сервисы (Communication Services),
• сервисы стандартизованных структур данных для передачи информации (Standardized
Data Structures for Transport of Information),
• стандартизованные механизмы пользовательского взаимодействия (Standardized User
Interaction Mechanisms).
Каждый из указанных выше классов сервиса, в свою очередь, разбиваются на
следующие подкатегории:
1) Коммуникационные сервисы (Communication Services):
• Общие широковещательные в режиме без соединения сервисы передачи (General
Connectionless Broadcast) - для передачи независимых блоков данных (дейтаграмм) всем
получателям некоторого региона.
• Управляемые мультивещательные сервисы передачи в режиме без соединения
(Controlled Connectionless Multicast) - для передачи независимых блоков данных
(дейтаграмм) предопределенному множеству получателей.
• Сервис одновещательной передачи без соединения (Connectionless Unicast) - для
передачи независимых блоков данных (дейтаграмм) единственному получателю.
• Широковещательная передача в режиме с соединением (Connection Oriented Broadcast)
- для передачи данных произвольному множеству получателей по устанавливаемым и
освобождаемым после обмена соединениям.
• Мультивещательная передача в режиме с соединением (Connection Oriented Multicast) для передачи данных заранее определенному множеству получателей по устанавливаемым
и освобождаемым после обмена соединениям.
142
• Сервис одновещательной передачи в режиме с соединением (Connection Oriented
Unicast) - для передачи единственному получателю по устанавливаемым и
освобождаемым после обмена соединениям.
• Сервис сетевого управления (Network Management Services) - для управления
передачей данных через одну или множество сетей.
2) Сервис стандартизованных структур данных для передачи информации
(Standardized Data Structures for Transport of Information):
• Сервис, ориентированный на обмен данными на магнитных лентах (Tape-based
Services).
• Сервис, ориентированный на обмен данными на магнитных дисках (Magnetic Diskbased Services).
• Сервис, ориентированный на обмен данными на оптических дисках (Optical Disk-based
Services).
• Сервис, ориентированный на обмен данными в печатном виде (Paper-based Services), а
также другие методы обмена данными.
3) Стандартизованные механизмы и сервисы пользовательского взаимодействия
(Standardized User Interaction Mechanisms), использующие:
• числовую клавиатуру для ввода данных (Services using Numeric-only Pads);
• алфавитно-цифровую клавиатуру (Services using Alphanumeric Keyboards);
• настраиваемые наборы функционально-ориентированных клавиш (Services using
Customized Keysets);
• ввод данных с помощью электронного пера (Pen-based Services);
• ввод данных с помощью тактильных устройств (Touch-based Services);
• голосовой ввод/вывод данных (Voice-based Services).
Стандартизация общезначимых прикладных и телекоммуникационных сервисов наряду
с достижением международного согласия по общим принципам управления доступом к
ресурсам Глобальной информационной инфраструктуры являются необходимым
условием рентабельности инвестиций в реализацию этой концепции.
Таким образом, в основе реализации концепции GII лежит всеобъемлющая комплексная
стандартизация ИТ. Стандартизацией технологий и сервисов GII занимается большое
число специализированных международных организаций стандартизации ИТ.
Комплексный подход к данной проблематике осуществляется Советом по Стандартизации
в области Информационных и Коммуникационных Технологий (ICTSB - Information and
Communications Technologies Standards Board), объединяющим усилия многих
международных, индустриальных и отраслевые организаций. ICTSB принимает активное
участие в осуществлении ряда проектов концепции GII, включая: проект по развитию
Европейской Информационной Инфраструктуры (EII) в рамках Европейского
143
Сообщества, стандартизацию сервисов телематики для дорожных транспортных
приложений; разработку стандартов электронной коммерции, в частности электронных
форматов представления данных для обмена (EDI) и сервисов обмена (EDIFACT);
разработку языковых и культурных национальных элементов, проект гармонизации
телекоммуникационных и IP-услуг на существующих сетях TIPHON; разработку
мультимедийной домашней платформы для DVB и др.
В процессе стандартизации GII активную роль играют следующие международные
организации: CEN, CENELEC, ETSI, CEN/ISSS, IEEE, ISOC, IETF, IRTF, OMG, ECMA,
W3C, ATM Forum, ECBS, EACEM, TeleManagement forum, Open Group, WFMC, Gigabit
Ethernet Alliance, DVB, EBU UER, ERTICO, ITU, ISO/IEC, HLSG, EWOS, NMF, T1, TINAC, IETF, DAB и др.
Как уже отмечалось, важным результатом процесса стандартизации технологий GII
явилось принятие международных стандартов, формирующих концептуальную и
архитектурную основу разработки системы стандартов для концепции GII, а именно,
стандартов ITU серии Y.100.
Заключение
Представленный выше анализ основ концепции Глобальной информационной
инфраструктуры (GII) позволяет сделать следующие выводы:
1) Разработка концепции и технологий Глобальной информационной инфраструктуры
относится к числу наиболее крупномасштабных проектов, реализуемых мировым
сообществом и призванным качественно изменить условия жизни и деятельности
человека.
2) Разработка концепции и технологий Глобальной информационной инфраструктуры
осуществляется на принципах концепции открытых систем. В частности, основные
свойства открытых систем, а именно: интероперабельность, переносимость,
масштабируемость, являются важнейшими свойствами технологий GII.
3) Разработка концепции и технологий Глобальной информационной инфраструктуры
открывает новый этап в развитии стандартизации информационных технологий,
характеризующийся разработкой стандартов для комплексов технологий разных видов
индустрий, интегрируемых в сценарии предоставления высокоуровневых услуг их
конечному потребителю.
144
8. Понятия маршрутизации, статической и динамической маршрутизации,
протокола маршрутизации, автономной системы.
Основы маршрутизации
Библиографическая справка
В общедоступном значении слова маршрутизация означает передвижение информации от
источника к пункту назначения через объединенную сеть. При этом, как правило, на пути
встречается по крайней мере один узел. Маршрутизация часто противопоставляется
объединению сетей с помощью моста, которое, в популярном понимании этого способа,
выполняет точно такие же функции. Основное различие между ними заключается в том,
что объединение с помощью моста имеет место на Уровне 2 эталонной модели ISO, в то
время как маршрутизация встречается на Уровне 3. Этой разницей объясняется то, что
маршрутизация и объединение по мостовой схеме используют различную информацию в
процессе ее перемещения от источника к месту назначения. Результатом этого является
то, что маршрутизация и объединение с помощью моста выполняют свои задачи разными
способами; фактически, имеется несколько различных видов маршрутизации и
объединения с помощью мостов. Дополнительная информация об объединении сетей с
помощью мостов приведена ниже, в пункте "Основы объединения сетей с помощью
мостов".
Тема маршрутизации освещалась в научной литературе о компьютерах более 2-х
десятилетий, однако с коммерческой точки зрения маршрутизация приобрела
популярность только в 1970 гг. В течение этого периода сети были довольно простыми,
гомогенными окружениями. Крупномасштабное объединение сетей стало популярно
только в последнее время.
145
Компоненты маршрутизации
Маршрутизация включает в себя два основных компонента: определение оптимальных
трактов маршрутизации и транспортировка информационых групп (обычно называемых
пакетами) через объединенную сеть. В настоящей работе последний из этих двух
компонентов называется коммутацией. Коммутация относительно проста. С другой
стороны, определение маршрута может быть очень сложным процессом.
Определение маршрута
Определение маршрута может базироваться на различных показателях (величинах,
результирующих из алгоритмических вычислений по отдельной переменной - например,
длина маршрута) или комбинациях показателей. Программные реализации алгоритмов
маршрутизации высчитывают показатели маршрута для определения оптимальных
маршрутов к пункту назначения.
Для облегчения процесса определения маршрута, алгоритмы маршрутизации
инициализируют и поддерживают таблицы маршрутизации, в которых содержится
маршрутная информация. Маршрутная информация изменяется в зависимости от
используемого алгоритма маршрутизации.
Алгоритмы маршрутизации заполняют маршрутные таблицы неким множеством
информации. Ассоциации "Пункт назначения/следующая пересылка" сообщают роутеру,
что определенный пункт назначения может быть оптимально достигнут путем отправки
пакета в определенный роутер, представляющий "следующую пересылку" на пути к
конечному пункту назначения. При приеме поступающего пакета роутер проверяет адрес
пункта назначения и пытается ассоциировать этот адрес со следующей пересылкой. На
рис. 1.4 приведен пример маршрутной таблицы "место назначения/следующая
пересылка".
Рис. 1.4. Destination/Next Hop Routing Table
В маршрутных таблицах может содержаться также и другая информация. "Показатели"
обеспечивают информацию о желательности какого-либо канала или тракта. Роутеры
146
сравнивают показатели, чтобы определить оптимальные маршруты. Показатели
отличаются друг oт друга в зависимости от использованной схемы алгоритма
маршрутизации. Далее в этой главе будет представлен и описан ряд общих показателей.
Роутеры сообщаются друг с другом (и поддерживают свои маршрутные таблицы) путем
передачи различных сообщений. Одним из видов таких сообщений является сообщение об
"обновлении маршрутизации". Обновления маршрутизации обычно включают всю
маршрутную таблицу или ее часть. Анализируя информацию об обновлении
маршрутизации, поступающую ото всех роутеров, любой из них может построить
детальную картину топологии сети. Другим примером сообщений, которыми
обмениваются роутеры, является "объявление о состоянии канала". объявление о
состоянии канала информирует другие роутеры о состоянии каналов отправителя.
Канальная информация также может быть использована для построения полной картины
топологии сети. После того, как топология сети становится понятной, роутеры могут
определить оптимальные маршруты к пунктам назначения.
Коммутация
Алгоритмы коммутации сравнительно просты и в основном одинаковы для большинства
протоколов маршрутизации. В большинстве случаев главная вычислительная машина
определяет необходимость отправки пакета в другую главную вычислительную машину.
Получив определенным способом адрес роутера, главная вычислительная машинаисточник отправляет пакет, адресованный специально в физический адрес роутера
(уровень МАС), однако с адресом протокола (сетевой уровень) главной вычислительной
машины пункта назначения.
После проверки адреса протокола пункта назначения пакета роутер определяет, знает он
или нет, как передать этот пакет к следующему роутеру. Во втором случае (когда роутер
не знает, как переслать пакет) пакет, как правило, игнорируется. В первом случае роутер
отсылает пакет к следующему роутеру путем замены физического адреса пункта
назначения на физический адрес следующего роутера и последующей передачи пакета.
Следующая пересылка может быть или не быть главной вычислительной машиной
окончательного пункта назначения. Если нет,то следующей пересылкой, как правило,
является другой роутер, который выполняет такой же процесс принятия решения о
коммутации. По мере того, как пакет продвигается через объединенную сеть, его
физический адрес меняется, однако адрес протокола остается неизменным. Этот процесс
иллюстрируется на рис. 1.5.
147
Рис. 1.5. Switching Process
В изложенном выше описании рассмотрена коммутация между источником и системой
конечного пункта назначения. Международная Организация по Стандартизации (ISO)
разработала иерархическую терминологию, которая может быть полезной при описании
этого процесса. Если пользоваться этой терминологией, то устройства сети, не
обладающие способностью пересылать пакеты между подсетями, называются конечными
системами (ЕS), в то время как устройства сети, имеющие такую способность, называются
промежуточными системами (IS). Промежуточные системы далее подразделяются на
системы, которые могут сообщаться в пределах "доменов маршрутизации"
("внутридоменные" IS), и системы, которые могут сообщаться как в пределах домена
маршрутизации, так и с другими доменами маршрутизации ("междоменные IS"). Обычно
считается, что "домен маршрутизации" - это часть объединенной сети, находящейся под
общим административным управлением и регулируемой определенным набором
административных руководящих принципов. Домены маршрутизации называются также
148
"автономными системами" (AS). Для определенных протоколов домены маршрутизации
могут быть дополнительно подразделены на "участки маршрутизации", однако для
коммутации как внутри участков, так и между ними также используются внутридоменные
протоколы маршрутизации.
Алгоритмы маршрутизации
Алгоритмы маршрутизации можно дифференцировать, основываясь на нескольких
ключевых характеристиках. Во-первых, на работу результирующего протокола
маршрутизации влияют конкретные задачи, которые решает разработчик алгоритма. Вовторых, существуют различные типы алгоритмов маршрутизации, и каждый из них поразному влияет на сеть и ресурсы маршрутизации. И наконец, алгоритмы маршрутизации
используют разнообразные показатели, которые влияют на расчет оптимальных
маршрутов. В следующих разделах анализируются эти атрибуты алгоритмов
маршрутизации.
Цели разработки алгоритмов маршрутизации
При разработке алгоритмов маршрутизации часто преследуют одну или несколько из
перечисленных ниже целей:
1.
Оптимальность
2.
Простота и низкие непроизводительные затраты
3.
Живучесть и стабильность
4.
Быстрая сходимость
5.
Гибкость
Оптимальность
Оптимальность, вероятно, является самой общей целью разработки. Она характеризует
способность алгоритма маршрутизации выбирать "наилучший" маршрут. Наилучший
маршрут зависит от показателей и от "веса" этих показателей, используемых при
проведении расчета. Например, алгоритм маршрутизации мог бы использовать несколько
пересылок с определенной задержкой, но при расчете "вес" задержки может быть им
оценен как очень значительный. Естественно, что протоколы маршрутизации должны
строгo определять свои алгоритмы расчета показателей.
Простота и низкие непроизводительные затраты
Алгоритмы маршрутизации разрабатываются как можно более простыми. Другими
словами, алгоритм маршрутизации должен эффективно обеспечивать свои
функциональные возможности, с минимальными затратами программного обеспечения и
коэффициентом использования. Особенно важна эффективность в том случае, когда
программа, реализующая алгоритм маршрутизации, должна работать в компьютере с
ограниченными физическими ресурсами.
149
Живучесть и стабильность
Алгоритмы маршрутизации должны обладать живучестью. Другими словами, они должны
четко функционировать в случае неординарных или непредвиденных обстоятельств, таких
как отказы аппаратуры, условия высокой нагрузки и некорректные реализации. Т.к.
роутеры расположены в узловых точках сети, их отказ может вызвать значительные
проблемы. Часто наилучшими алгоритмами маршрутизации оказываются те, которые
выдержали испытание временем и доказали свою надежность в различных условиях
работы сети.
Быстрая сходимость
Алгоритмы маршрутизации должны быстро сходиться. Сходимость - это процесс
соглашения между всеми роутерами по оптимальным маршрутам. Когда какое-нибудь
событие в сети приводит к тому, что маршруты или отвергаются, или становятся
доступными, роутеры рассылают сообщения об обновлении маршрутизации. Сообщения
об обновлении маршрутизации пронизывают сети, стимулируя пересчет оптимальных
маршрутов и, в конечном итоге, вынуждая все роутеры придти к соглашению по этим
маршрутам. Алгоритмы маршрутизации, которые сходятся медленно, могут привести к
образованию петель маршрутизации или выходам из строя сети.
На Рис. 1.6 изображена петля маршрутизации. В данном случае, в момент времени t1 к
роутеру 1 прибывает пакет. Роутер 1 уже был обновлен и поэтому он знает, что
оптимальный маршрут к пункту назначения требует, чтобы следующей остановкой был
роутер 2. Поэтому роутер 1 пересылает пакет в роутер 2. Роутер 2 еще не был обновлен,
поэтому он полагает, что следующей оптимальной пересылкой должен быть роутер 1.
Поэтому роутер 2 пересылает пакет обратно в роутер 1. Пакет будет продолжать скакать
взад и вперед между двумя роутерами до тех пор, пока роутер 2 не получит корректировку
маршрутизации, или пока число коммутаций данного пакета не превысит допустимого
максимального числа.
Рис. 1.6. Slow Convergence and Routing Loops
Гибкость
Алгоритмы маршрутизации должны быть также гибкими. Другими словами, алгоритмы
маршрутизации должны быстро и точно адаптироваться к разнообразным
обстоятельствам в сети. Например, предположим, что сегмент сети отвергнут. Многие
150
алгоритмы маршрутизации, после того как они узнают об этой проблеме, быстро
выбирают следующий наилучший путь для всех маршрутов, которые обычно используют
этот сегмент. Алгоритмы маршрутизации могут быть запрограммированы таким образом,
чтобы они могли адаптироваться к изменениям полосы пропускания сети, размеров
очереди к роутеру, величины задержки сети и других переменных.
Типы алгоритмов
Алгоритмы маршрутизации могут быть классифицированы по типам. Например,
алгоритмы могут быть:
1.
Статическими или динамическими
2.
Одномаршрутными или многомаршрутными
3.
Одноуровневыми или иерархическими
4.
С интеллектом в главной вычислительной машине или в роутере
5.
Внутридоменными и междоменными
6.
Алгоритмами состояния канала или вектора расстояний
Статические или динамические алгоритмы
Статические алгоритмы маршрутизации вообще вряд ли являются алгоритмами.
Распределение статических таблиц маршрутизации устанавливается администратором
сети до начала маршрутизации. Оно не меняется, если только администратор сети не
изменит его. Алгоритмы, использующие статические маршруты, просты для разработки и
хорошо работают в окружениях, где трафик сети относительно предсказуем, а схема сети
относительно проста.
Т.к. статические системы маршрутизации не могут реагировать на изменения в сети, они,
как правило, считаются непригодными для современных крупных, постоянно
изменяющихся сетей. Большинство доминирующих алгоритмов маршрутизации 1990гг. динамические.
Динамические алгоритмы маршрутизации подстраиваются к изменяющимся
обстоятельствам сети в масштабе реального времени. Они выполняют это путем анализа
поступающих сообщений об обновлении маршрутизации. Если в сообщении указывается,
что имело место изменение сети, программы маршрутизации пересчитывают маршруты и
рассылают новые сообщения о корректировке маршрутизации. Такие сообщения
пронизывают сеть, стимулируя роутеры заново прогонять свои алгоритмы и
соответствующим образом изменять таблицы маршрутизации. Динамические алгоритмы
маршрутизации могут дополнять статические маршруты там, где это уместно. Например,
можно разработать "роутер последнего обращения" (т.е. роутер, в который отсылаются
все неотправленные по определенному маршруту пакеты). Такой роутер выполняет роль
хранилища неотправленных пакетов, гарантируя, что все сообщения будут хотя бы
определенным образом обработаны.
Одномаршрутные или многомаршрутные алгоритмы
151
Некоторые сложные протоколы маршрутизации обеспечивают множество маршрутов к
одному и тому же пункту назначения. Такие многомаршрутные алгоритмы делают
возможной мультиплексную передачу трафика по многочисленным линиям;
одномаршрутные алгоритмы не могут делать этого. Преимущества многомаршрутных
алгоритмов очевидны - они могут обеспечить значительно большую пропускную
способность и надежность.
Одноуровневые или иерархические алгоритмы
Некоторые алгоритмы маршрутизации оперируют в плоском пространстве, в то время как
другие используют иерархии маршрутизации. В одноуровневой системе маршрутизации
все роутеры равны по отношению друг к другу. В иерархической системе маршрутизации
некоторые роутеры формируют то, что составляет основу (backbone - базу)
маршрутизации. Пакеты из небазовых роутеров перемещаются к базовыи роутерам и
пропускаются через них до тех пор, пока не достигнут общей области пункта назначения.
Начиная с этого момента, они перемещаются от последнего базового роутера через один
или несколько небазовых роутеров до конечного пункта назначения.
Системы маршрутизации часто устанавливают логические группы узлов, называемых
доменами, или автономными системами (AS), или областями. В иерархических системах
одни роутеры какого-либо домена могут сообщаться с роутерами других доменов, в то
время как другие роутеры этого домена могут поддерживать связь с роутерами только в
пределах своего домена. В очень крупных сетях могут существовать дополнительные
иерархические уровни. Роутеры наивысшего иерархического уровня образуют базу
маршрутизации.
Основным преимуществом иерархической маршрутизации является то, что она имитирует
организацию большинства компаний и следовательно, очень хорошо поддерживает их
схемы трафика. Большая часть сетевой связи имеет место в пределах групп небольших
компаний (доменов). Внутридоменным роутерам необходимо знать только о других
роутерах в пределах своего домена, поэтому их алгоритмы маршрутизации могут быть
упрощенными. Соответственно может быть уменьшен и трафик обновления
маршрутизации, зависящий от используемого алгоритма маршрутизации.
Алгоритмы с интеллектом в главной вычислительной машине или в роутере
Некоторые алгоритмы маршрутизации предполагают, что конечный узел источника
определяет весь маршрут. Обычно это называют маршрутизацией от источника. В
системах маршрутизации от источника роутеры действуют просто как устройства
хранения и пересылки пакета, без всяких раздумий отсылая его к следующей остановке.
Другие алгоритмы предполагают, что главные вычислительные машины ничего не знают
о маршрутах. При использовании этих алгоритмов роутеры определяют маршрут через
объединенную сеть, базируясь на своих собственных расчетах. В первой системе,
рассмотренной выше, интеллект маршрутизации находится в главной вычислительной
машине. В системе, рассмотренной во втором случае, интеллектом маршрутизации
наделены роутеры.
152
Компромисс между маршрутизацией с интеллектом в главной вычислительной машине и
маршрутизацией с интеллектом в роутере достигается путем сопоставления
оптимальности маршрута с непроизводительными затратами трафика. Системы с
интеллектом в главной вычислительной машине чаще выбирают наилучшие маршруты,
т.к. они, как правило, находят все возможные маршруты к пункту назначения, прежде чем
пакет будет действительно отослан. Затем они выбирают наилучший маршрут,
основываясь на определении оптимальности данной конкретной системы. Однако акт
определения всех маршрутов часто требует значительного трафика поиска и большого
объема времени.
Внутридоменные или междоменные алгоритмы
Некоторые алгоритмы маршрутизации действуют только в пределах доменов; другие - как
в пределах доменов, так и между ними. Природа этих двух типов алгоритмов различная.
Поэтому понятно, что оптимальный алгоритм внутридоменной маршрутизации не
обязательно будет оптимальным алгоритмом междоменной маршрутизации.
Алгоритмы состояния канала или вектора расстояния
Алгоритмы состояния канала (известные также как алгоритмы "первоочередности
наикратчайшего маршрута") направляют потоки маршрутной информации во все узлы
объединенной сети. Однако каждый роутер посылает только ту часть маршрутной
таблицы, которая описывает состояние его собственных каналов. Алгоритмы вектора
расстояния ( известные также как алгоритмы Бэлмана-Форда) требуют от каждогo роутера
посылки всей или части своей маршрутной таблицы, но только своим соседям. Алгоритмы
состояния каналов фактически направляют небольшие корректировки по всем
направлениям, в то время как алгоритмы вектора расстояний отсылают более крупные
корректировки только в соседние роутеры.
Отличаясь более быстрой сходимостью, алгоритмы состояния каналов несколько меньше
склонны к образованию петель маршрутизации, чем алгоритмы вектора расстояния. С
другой стороны, алгоритмы состояния канала характеризуются более сложными
расчетами в сравнении с алгоритмами вектора расстояний, требуя большей процессорной
мощности и памяти, чем алгоритмы вектора расстояний. Вследствие этого, реализация и
поддержка алгоритмов состояния канала может быть более дорогостоящей. Несмотря на
их различия, оба типа алгоритмов хорошо функционируют при самых различных
обстоятельствах.
Показатели алгоритмов (метрики)
Маршрутные таблицы содержат информацию, которую используют программы
коммутации для выбора наилучшего маршрута. Чем характеризуется построение
маршрутных таблиц? Какова особенность природы информации, которую они содержат?
В данном разделе, посвященном показателям алгоритмов, сделана попытка ответить на
вопрос о том, каким образом алгоритм определяет предпочтительность одного маршрута
по сравнению с другими.
В алгоритмах маршрутизации используется много различных показателей. Сложные
алгоритмы маршрутизации при выборе маршрута могут базироваться на множестве
153
показателей, комбинируя их таким образом, что в результате получается один отдельный
(гибридный) показатель. Ниже перечислены показатели, которые используются в
алгоритмах маршрутизации:
1.
Длина маршрута
2.
Надежность
3.
Задержка
4.
Ширина полосы пропускания
5.
Нагрузка
6.
Стоимость связи
Длина маршрута
Длина маршрута является наиболее общим показателем маршрутизации. Некоторые
протоколы маршрутизации позволяют администраторам сети назначать произвольные
цены на каждый канал сети. В этом случае длиной тракта является сумма расходов,
связанных с каждым каналом, который был траверсирован. Другие протоколы
маршрутизации определяют "количество пересылок", т.е. показатель, характеризующий
число проходов, которые пакет должен совершить на пути от источника до пункта
назначения через изделия объединения сетей (такие как роутеры).
Надежность
Надежность, в контексте алгоритмов маршрутизации, относится к надежности каждого
канала сети (обычно описываемой в терминах соотношения бит/ошибка). Некоторые
каналы сети могут отказывать чаще, чем другие. Отказы одних каналов сети могут быть
устранены легче или быстрее, чем отказы других каналов. При назначении оценок
надежности могут быть приняты в расчет любые факторы надежности. Оценки
надежности обычно назначаются каналам сети администраторами сети. Как правило, это
произвольные цифровые величины.
Задержка
Под задержкой маршрутизации обычно понимают отрезок времени, необходимый для
передвижения пакета от источника до пункта назначения через объединенную сеть.
Задержка зависит от многих факторов, включая полосу пропускания промежуточных
каналов сети, очереди в порт каждого роутера на пути передвижения пакета,
перегруженность сети на всех промежуточных каналах сети и физическое расстояние, на
которое необходимо переместить пакет. Т.к. здесь имеет место конгломерация нескольких
важных переменных, задержка является наиболее общим и полезным показателем.
Полоса пропускания
Полоса пропускания относится к имеющейся мощности трафика какого-либо канала. При
прочих равных показателях, канал Ethernet 10 Mbps предпочтителен любой арендованной
линии с полосой пропускания 64 Кбайт/сек. Хотя полоса пропускания является оценкой
154
максимально достижимой пропускной способности канала, маршруты, проходящие через
каналы с большей полосой пропускания, не обязательно будут лучше маршрутов,
проходящих через менее быстродействующие каналы. Например, если более
быстродействующий канал почти все время занят, то фактическое время, необходимое для
отправки пакета в пункт назначения, для этого быстродействующего канала может
оказаться больше.
Нагрузка
Нагрузка относится к степени занятости какого-либо источника сети (такого, как роутер).
Нагрузка может быть вычислена разнообразными способами, в том числе по
коэффициенту использования главного процессора и числу пакетов, обработанных в
секунду. Постоянный контроль этих параметров может привести к интенсивному
расходованию ресурсов.
Стоимость связи
Другим важным показателем является стоимость связи. Некоторые компании интересует
не столько эффективность, сколько операционные расходы. Даже если задержка в их
линии может быть большой, они отправят пакеты через свои собственные линии, а не
через линии общего пользования, т.к. им придется платить за использованное время.
Сопоставление терминов "Routed Protocol" и "Routing Protocol"
Как правило, термины "routed protocol" и "routing protocol" постоянно путают. Routed
protocol - это протокол, отправленный по определенному маршруту через объединенную
сеть. Примерами таких протоколов являются Internet Protocol (IP), DECnet и Apple Talk.
"Routing protocol" - это протокол, который реализует алгоритм маршрутизации. Если
изложить это просто, они отправляют протоколы по определенному маршруту через
объединенную сеть. Примерами таких протоколов могут быть Interior Gateway Routing
Protocol (IGRP), Open Shortest Path First (OSPF), Intermediate System to Intermediate System
(IS-IS) и Routing Information Protocol (RIP).
В начале 90-х годов было принято решение ввести понятие автономной системы (AS).
Автономная система – это совокупность локальных сетей, имеющая одного
администратора и единую маршрутную политику. Введение AS позволило несколько
сократить размер маршрутных таблиц, так как маршруты можно было прокладывать уже
не между локальными сетями, а между более крупными образованьями – автономными
системами. Само название таких систем подчеркивает их независимость, и только
добровольное сотрудничество помогает всем участникам решать общие проблемы.
Автономная система (AS) в Интернете — это система IP-сетей и маршрутизаторов,
управляемых одним или несколькими операторами, имеющими единую политику
маршрутизации с Интернетом. См. RFC 1930 для дополнительной информации по
данному определению.
Поначалу определение требовало единого оператора, обычно Интернет-провайдера или
очень большую организацию с независимыми соединениями с несколькими сетями,
который бы придерживался единой и ясно определенной политики маршрутизации. См.
RFC 1771, оригинальное определение (сейчас устаревшее) Border Gateway Protocol.
155
Новое определение из RFC 1930 вошло в употребление, так как несколько организаций
могло подключиться к Интернет-провайдеру через BGP, используя приватные номера AS,
а провайдер, в свою очередь, подключал все эти организации к Интернету. Хотя
существуют несколько автономных систем, поддерживаемых данным Интернетпровайдером, в Интернете видно только политику маршрутизации данного провайдера.
Именно этот Интернет-провайдер и должен иметь зарегистрированный публичный номер
AS.
Уникальный номер AS (или ASN) присваивается каждой AS для использования в BGP
маршрутизации. Номера AS в BGP очень важны, так как именно ASN однозначно
идентифицирует каждую сеть в Интернете.
Автономные системы можно сгруппировать в 3 категории, в зависимости от их
соединений и режима работы.
Многоинтерфейсная (multihomed) AS — это AS, которая имеет соединения с более чем
одним Интернет-провайдером. Это позволяет данной AS оставаться подключенной к
Интернету в случае выхода из строя соединения с одним из Интернет-провайдеров. Кроме
того, этот тип AS не разрешает транзитный трафик от одного Интернет-провайдера к
другому.
Ограниченная (stub) AS — это AS, имеющая единственное подключение к одной внешней
автономной системе. Это расценивается как бесполезное использование номера AS, так
как сеть размещается полностью под одним Интернет-провайдером и, следовательно, не
нуждается в уникальной идентификации.
Транзитная (transit) AS — это AS, которая пропускает через себя транзитный трафик
сетей, подключенных к ней. Таким образом, сеть A может использовать транзитную AS
для связи с сетью B.
156
9. Соглашение и спецификация
(Рекомендация X210).
сервиса
сетевых
протоколов
Соглашение о спецификации протокольных сервисов
10.1.1 Основные понятия метода и нотации спецификации
протокольных сервисов
Выше, отмечалось, что стандартизация взаимосвязи открытых систем включает три
уровня описания средств информационного обмена, а именно: концептуальный уровень,
содержание которого определяется моделью OSI RM, уровень спецификаций
функциональных возможностей (или сервисов) элементов архитектуры OSI RM и уровень
спецификаций протоколов информационного обмена между функциональными
элементами эталонной модели.
Модель и способ описания сетевых сервисов играют ключевую роль в области
стандартизации телекоммуникационных технологий. Более того, данная модель
используется для построения модели адресации и идентификации в OSI RM. Поэтому
модель и язык описания (соглашение о спецификации) сервисов можно считать составной
частью модели OSI RM, хотя формально они определены в отдельном стандарте (ISO 8509
или X.210).
Модель сетевых сервисов, рассмотренная в данных документах, несмотря на свою
простоту, носит фундаментальный для теории сетевых протоколов характер. Рассмотрим
модель и соглашение о спецификации сервисов подробнее.
157
Первоначально введем ряд основополагающих определений.
(N)-сервис ((N)-service): функциональные возможности, которые могут быть
предоставлены на границе между (N+1)- и (N)- уровнями.
Пользователь (N)-сервиса ((N)-service-user): абстрактное представление всего
множества тех логических объектов в некоторой (N+1)-подсистеме, которые используют
некоторый (N)-сервис через некоторую (N)-точку доступа.
Поставщик (N)-сервиса ((N)-service-provider): абстрактный автомат, который
моделирует поведение совокупности логических объектов, обеспечивающих (N)-сервис, с
точки зрения пользователя.
(N)- сервисный примитив или примитив ((N)-service-primitive; primitive): абстрактное, не
зависимое от реализации неделимое взаимодействие между пользователем (N)-сервиса и
поставщиком (N)-сервиса, происходящее на границе между ними.
В случае, когда смысл понятия распространяется на все семь уровней эталонной
модели, оно префексируется словом OSI, например, ((OSI)-service, (OSI)-service-user,
(OSI)-service-provider, (OSI)-service-primitive). Однако, чтобы не усложнять
рассматриваемую модель с терминологической точки зрения, мы такую нотацию в
последствии использовать не будем.
В теории протоколов и в документации по сетевым протоколам сервисные примитивы,
с помощью которых описываются межуровневые взаимодействия в модели OSI RM,
называются также абстрактными сервисными примитивами или ASPs (Abstract Service
Primitives).
Далее вводятся определения двух общих примитивов: запросить (submit) и доставить
(deliver), а также двух общих типов пользователей сервиса, характеризующихся их
ролевой функцией: инициатор запроса (requestor) и получатель (acceptor).
запросить (submit): сервисный примитив, инициируемый пользователем сервиса
(направляемый от пользователя к поставщику сервиса).
доставить (deliver): сервисный примитив, инициируемый поставщиком сервиса
(направляемый от поставщика сервиса к пользователю).
инициатор запроса (requestor): пользователь, который выдает (поставщику сервиса
нижележащего уровня) примитив запросить, и в результате чего может получить от
поставщика один или несколько примитивов доставить.
получатель (acceptor): пользователь, который получает (от поставщика сервиса
нижележащего уровня) примитив доставить, в результате чего может выдать поставщику
в качестве ответа один или несколько примитивов запросить.
Введенные выше классификация примитивов не очень удобна для использования из-за
своей общности. Поэтому при определении стандартов сервисов сетевых протоколов
применяется более практичная классификация примитивов, вообще говоря, выводимая из
определений общих примитивов и классов пользователей.
158
(N)- сервисный примитив запроса ((N)-service-request-primitive): примитив, выдаваемый
пользователем (N)-сервиса, т.е. инициатором запроса, (поставщику, например, для вызова
некоторой процедуры; примитив request по существу эквивалентен requestor. submit).
(N)- сервисный примитив индикации ((N)-service-indication-primitive): примитив,
выдаваемый поставщиком (N)-сервиса (например, для вызова некоторой процедуры или
для информирования о том, что процедура была вызвана пользователем сервиса на
удаленной точке доступа к сервису; примитив indication по существу эквивалентен
acceptor. deliver).
(N)- сервисный примитив ответа ((N)-service-response-primitive): примитив,
выдаваемый пользователем (N)-сервиса (пользователем-получателем) поставщику в
конкретной точке доступа к сервису для завершения некоторой процедуры,
предварительно вызванной посредством выдачи поставщиком примитива индикации в
этой точке доступа к сервису (примитив response по существу эквивалентен acceptor.
submit).
(N)- сервисный примитив подтверждения ((N)-service-confirm-primitive): примитив,
выдаваемый поставщиком (N)-сервиса в конкретной точке доступа к сервису для
завершения некоторой процедуры, предварительно вызванной посредством выдачи
примитива запроса в этой же точке доступа (примитив confirm по существу эквивалентен
requestor. deliver).
Заметим, что примитивы подтверждение и ответ, могут быть положительными или
отрицательными в зависимости от обстоятельств.
Обязательное (N)-средство (mandatory (N)-facility): часть (N)-сервиса, которая должна
быть обеспечена в (N)-точке доступа к сервису любой реализацией (N)-поставщика.
Факультативное (N)- средство поставщика ((N)-provider-optional-facility): часть (N)сервиса, которая используется только в случае согласия пользователей сервиса.
Подтверждаемый сервис (confirmed-service): сервис, который подразумевает явное
подтверждение поставщиком сервиса того, что им выполнена процедура,
соответствующая семантике сервиса. При этом необязательна связь подтверждения с
ответом пользователя сервиса.
Неподтверждаемый сервис (unconfirmed-service): сервис, который не включает в свои
действия явного подтверждения о выполнении некоторой процедуры.
Сервис, инициируемый поставщиком (provider-initiated-service): сервис, который
генерируется пользователю поставщиком сервиса без запроса пользователя (например,
уведомление об ошибке поставщика).
OSI-local view: разделяемое (shared) поведение пользователя и поставщика сервиса при
их взаимодействии на границе сервиса, по существу некоторый абстрактный интерфейс
взаимодействия пользователя и поставщика.
159
10.1.2. Модель сервиса уровней
Под сервисом уровня понимаются функциональные возможности соответствующего
поставщика сервиса, которые он может предложить пользователям на своей границе (в
точках доступа к сервису) для реализации взаимосвязи между пользователями. Поэтому
определение сервиса должно описывать именно то, что можно наблюдать на этой границе
при взаимодействии поставщика и пользователя, т.е. их поведение, представленное в виде
последовательности событий, происходящей на разделяющей их границе. Таким образом,
сервис уровня определяется в терминах абстрактной модели, содержащей следующие
элементы: (N)-пользователей сервиса, (N)-поставщика сервиса, границу взаимодействия
((N)-SAP) и наблюдаемые на границе элементарные акты взаимодействия (события,
связанные с передачей через границу сервисных примитивов).
Общая модель OSI-сервиса, использующая примитивы submit и deliver, представлена на
рис. 10.1.
Рис. 10.1. Общая модель OSI-сервиса
На рис. 10.2. показана модель предоставления (N)-сервиса со стороны поставщика (N)сервиса двум равнозначным или одноранговым (N)-пользователям (peer (N)-users), т.е.
(N+1)-сущностям-корреспондентам, взаимодействующим друг с другом с помощью
некоторого (N+1)-протокола. Данная модель легко расширяется и для описания случаев,
соответствующих множественным или широковещательным видам взаимодействия
сущностей.
Рис. 10.2. Модель предоставления (N)-сервиса
События, определяющие акты взаимодействия пользователей сервиса с поставщиком
сервиса, осуществляются посредством выдачи или приема сервисных примитивов через
соответствующие точки доступа к сервису.
Взаимосвязь между понятиями: сервис, сервисный примитив, одноранговые сущности и
протокол взаимодействия между ними, показана на рис. 10.3.
160
a - сервис
b - сервисные примитивы
c - протокол
d - одноранговые сущности (протокольные автоматы)
Рис. 10.3. Взаимосвязь понятий в модели предоставления сервиса
В рамках разработанной модели для определения сервиса, предоставляемого
поставщиком, требуется решить следующие задачи:

определить классификацию типов примитивов и сервисов;

разработать некоторый способ систематического наименования примитивов для каждого
конкретного сервиса;

разработать некоторый способ задания допустимых логических и временных связей между
примитивами сервисов;

разработать соглашения о спецификации параметров примитивов, а именно, их типов, диапазонов
значений, форматов представления.
Последняя задача, как правило, решается посредством использования
специализированного языка ASN.1. В других случаях параметры примитивов могут
описываться средствами языков спецификаций или языков программирования, задаваться
в табличной форме или описываться на естественном языке. Использование языка ASN.1
для определения семантики примитивов будет рассмотрен далее. Первые три из
указанных выше аспектов определения сервисов рассмотрим подробнее немедленно.
10.1.3. Состав и основные свойства сервисных примитивов
Первоначально рассмотрим состав типов и основные свойства сервисных примитивов.
Итак, в рассматриваемом стандарте определены четыре типа сервисных примитивов:
a) примитив запрос (request);
b) примитив индикация (indication);
c) примитив ответ (response) - ответ может быть положительным или отрицательным;
d) примитив подтверждение (confirm) - подтверждение может быть положительным
или отрицательным.
161
Основными свойствами примитивов являются:

атомарность - каждый сервисный примитив представляет собой логически самостоятельное
неделимое взаимодействие, происходящее на границе уровня в некоторой точке доступа к сервису,
которое не может быть прервано другим взаимодействием;

направленность - сервисный примитив имеет направление либо от пользователя сервиса к
поставщику сервиса, либо от поставщика сервиса к пользователю сервиса;

перенос семантики - с сервисным примитивом могут быть связаны один или несколько параметров
и каждый из этих параметров имеет определенный диапазон значений. Значения параметров,
относящиеся к сервисному примитиву, передаются в направлении следования сервисного
примитива через среду взаимосвязи открытых систем.
Как уже отмечалось, в данной модели процесс реализации (N)-сервиса,
предоставляемого (N)-пользователю поставщиком (N)-сервиса, описывается в виде
последовательности связанных с семантикой выполнения данного сервиса событий,
которые можно наблюдать на верхней границе поставщика (N)-сервиса. При этом события
представляют собой атомарные взаимодействия между (N)-пользователями и
поставщиком (N)-сервиса, осуществляемые посредством обмена (N)-примитивами в (N)точках доступа к сервису, т.е. в (N)-SAP. Такой подход позволяет абстрагироваться при
описании сервиса от механизмов его реализации, в частности, от элементов сетевых
протоколов, описывающих процедуры реализации сервисов.
Для описания сервисных примитивов используется функциональная форма записи,
имеющая следующий синтаксис:
ServiceType(param 1 , ..., param n),
где параметры могут представлять как элементы управляющей информации, так и
данные пользователя.
Как видно из определений различаются следующие основные типы сервисов:

подтверждаемый сервис (confirmed service), в котором используются все четыре типа примитивов:
запрос (request), индикация (indication), ответ (respond), подтверждение (confirm);

неподтверждаемый сервис (unconfirmed service), в котором используются два типа примитивов:
запрос (request) и индикация (indication);

сервис, инициируемый поставщиком, в котором используется примитивы типа индикация
(indication).
Таким образом, процесс реализации (N)-сервиса может рассматриваться в виде
упорядоченного во времени набора атомарных событий, происходящих на границе (N)уровня (а именно в точках (N)-SAP) и связанных с передачей и приемом примитивов
запрос, индикация, ответ, подтверждение.
10.1.4. Наименование сервисных примитивов
Рассмотрим систему наименования сервисных примитивов. При формировании имени
сервисного примитива в его состав вводится имя соответствующего типа примитива.
Более точно имя каждого сервисного примитива содержит следующие три элемента:
162
a) обозначение уровня;
b) имя сервиса;
c) имя типа примитива.
При составлении имен примитивов конкретных уровней модели OSI RM символ уровня
и имя сервиса отделяются друг от друга дефисом; а имя сервиса и имя типа примитива
отделяются пробелом.
Примерами имен примитивов для (N)-сервиса, осуществляющего установление (N)соединения (CONNECTION) с подтверждением, являются следующие конструкции:

(N)-CONNECTION request

(N)-CONNECTION indication

(N)-CONNECTION response

(N)-CONNECTION confirm
В частности, если бы рассмотренный выше сервис установления (N)-соединения
относился к классу неподтверждаемых сервисов, то для его реализации использовались
бы только два примитива с именами:

(N)-CONNECTION request

(N)-CONNECTION indication
Таким образом, процесс реализации (N)-сервиса может наблюдаться на границе (N)уровня (а именно в точках (N)-SAP) как последовательность атомарных событий,
связанных с передачей и приемом соответствующих данному сервису примитивов.
В заключение рассмотрим принятые соглашения по наименованию сервисных
примитивов в семиуровневой модели. В качестве обозначения уровня в имени примитива
используются следующие символы:

A - Прикладной (Application) - уровень 7;

P - Представительный (Presentation) - уровень 6;

S - Сеансовый (Session) - уровень 5;

T - Транспортный (Transport) - уровень 4;

N - Сетевой (Network) - уровень 3;

D - Канальный или звена данных (Data Link) - уровень 2;

Ph - Физический (Physical) - уровень 1.
Примерами имен примитивов сервисов для конкретных уровней моделиOSI являются:

P-CONNECT request - запрос представительного соединения, т.е. P-соединения;

T-DATA indication - индикация о доставке транспортного сегмента данных;
163

N-DISCONNECT confirm - подтверждение разрыва сетевого соединения.
10.1.5. Соглашения о временных диаграммах
Для описания логических и временных связей между примитивами сервиса
используется метод диаграмм специального вида, которые будем называть TSдиаграммами (time-sequence diagrams). С помощью временных диаграмм можно
отобразить:
a) последовательность событий на границе (N+1)-пользователь/(N)-поставщик в
некоторой открытой системе;
b) последовательность событий между (N+1)-пользователями.
На рис. 10.4 показаны способы построения таких диаграмм.
Каждая диаграмма разделена двумя вертикальными линиями на три области.
Центральная область представляет поставщика сервиса, а две области, расположенные
слева и справа от центральной, соответствуют пользователям сервиса. Вертикальные
линии представляют точки доступа к сервису. Они же являются и временными осями.
Последовательности событий, происходящих в каждой точке доступа к сервису,
размещаются на вертикальных линиях. Причем события, которые располагается на линии
ниже другого, происходит в более поздний момент времени. Стрелки в пользовательской
области диаграммы сервиса, указывают направление передачи примитива (а именно, от
пользователя к поставщику сервиса или, наоборот, от поставщика сервиса к
пользователю).
Наличие детерминированных логических связей между двумя взаимодействующими
точками доступа к сервису (точками вертикальных линий) обозначаются пунктирной
линией между этими точками. Например, на рис. 3.а за примитивом request, поступившим
в момент времени t1 в точку доступа к сервису, представленной вертикальной линией на
диаграмме слева, должен последовать примитив indication, выдаваемый поставщиком
сервиса в момент времени t2 в точке доступа к сервису, к которой подключен удаленный
пользователь сервиса. При отсутствии логических связей между примитивами пунктирная
линия в центральной области диаграммы между моментами проявления событий,
соответствующих приему/передаче примитивов, будет отсутствовать. В этом случае для
большей выразительности может использоваться знак тильда (~).
Рис. 10.3.b и 10.3.c иллюстрирует два способа реализации отрицательных
подтверждений, генерируемых отвечающим пользователем. На рис. 10.3.b на протяжении
всего цикла обслуживания запроса пользователя используется одно и то же имя (в данном
случае - x), а на рис. 10.3.c отвечающий пользователь сервиса посылает встречный запрос
с другим именем (в данном случае - y), показывая тем, самым, что предыдущий запрос на
обслуживание данным пользователем отклоняется.
164
Рис. 10.4 Временные диаграммы
На рис.10.4 показан тип диаграмм, в которых протекание времени отображается с
помощью наклона вниз линий связи в области, представляющей поставщика сервиса.
Также используются диаграммы, в которых факт прохождения времени изображается с
помощью наклона линий направления передачи примитивов в области пользователей.
10.1.6. Соглашения, связанные с описанием параметров
Широко применяемый способ описания параметров примитивов основан на
использовании так называемых таблиц параметров (parameter tables), в которых для
обозначения свойств параметров используются следующие обозначения:

M параметр является обязательным (mandatory)

C параметр является условным (conditional)

(=) значение параметра семантически идентично значению соответствующего параметра
примитива, логически связанного с текущим примитивом и непосредственно предшествующего его
в последовательности событий сервиса

U использование параметра по усмотрению пользователя сервиса (OSI-service-user option).

P использование параметра по усмотрению поставщика сервиса (OSI-service-provider option).

пробел (blank) параметр не представлен в примитиве, описывающим конкретное взаимодействие
поставщика и пользователя.
Модель и спецификация протокольного автомата
165
Описанная выше модель сервиса обеспечивает методическую основу для разработки
теории сетевых протоколов. В ней предполагается наличие двух уровней спецификации
сетевых протоколов, а именно:
a) спецификации сервиса протокола или его абстрактного интерфейса,
b) описания процедур, выполняемых поставщиком сервиса для реализации сервиса или
его частей, т.е. описание собственно протоколов взаимодействия сущностей,
реализующих функции поставщика.
Далее к важным результатам построения модели сервиса следует отнести разработку
номенклатуры примитивов и соответствующей системы атомарных событий, адекватной
для однозначного описания взаимодействий пользователя и поставщика сервиса на
разделяющей их границе.
Ввиду того, что процесс взаимодействия поставщика сервиса и его пользователя носит
дискретно-событийный характер, моделирование поведения поставщика может
осуществляться посредством использования понятий абстрактных автоматов. В этом
случае упомянутая выше номенклатура событий становится основой для формирования
входных и выходных алфавитов абстрактных устройств, моделирующих работу
поставщика сервиса.
Другим важным достоинством модели сервиса является то, что в ней заложен подход к
определению семантики переносимых сервисными примитивами данных через описание
типов и значений параметров. В частности, именно, через механизм параметров
осуществляется реализация отображения (N+1)-протокольных блоков данных в (N)сервисные блоки данных, рассмотренного в предыдущей главе (рис. 9.3).
Используя отмеченные выше решения, рассмотрим некоторые элементы теории сетевых
протоколов, к центральным задачам которой относятся:

разработка средств и методов формальной спецификации сетевых протоколов и сервисов;

разработка метод верификации и анализа функционирования реализаций сетевых протоколов;

разработка средств и методов автоматизации тестирования реализаций сетевых протоколов;

автоматизация программирования реализаций сетевых протоколов и пр.
Начнем знакомство с этой теории с рассмотрения вопросов формальной спецификации
протоколов и сервисов.
10.2.1 Машина с конечным числом состояний как модель
протокольной сущности
Для описания сетевых протоколов широко используются различные модели машин с
конечным числом состояний. В простых случаях, когда при описании поведения
протокольных сущностей абстрагируются от параметров примитивов, состояния памяти и
содержания протокольных блоков памяти, машины состояний называются конечными
автоматами.
166
Дадим наиболее общее определение машины с конечным числом состояний,
применяемой при моделировании поведения протокольных сущностей.
Машина с конечным числом состояний (Finite-State Machine - FSM), описывающая
поведение протокольной сущности, представляет собой следующую пятерку: M = (I, O, S,
D, L), где I - входной алфавит, включает сервисные примитивы request/response (Abstract
Service Primitives - ASPs), исходящие от пользователя, и набор блоков PDU, исходящих
от протокольного автомата того же уровня (peer-entity), партнера по взаимодействию. O выходной алфавит, включает сервисные примитивы indication/confirmation (ASPs),
направляемые пользователю, и набор блоков PDU, направляемых партнеру по
взаимодействию (peer-entity). S - набор состояний, где s из S - начальное состояние, F непустое подмножество состояний, интерпретируемых как конечные состояния. D: I*S ->
S - функция перехода в новое состояние. L: I*S -> O - функция вывода.
Для представления функций переходов и вывода FSM используются, как правило,

таблицы состояний или

диаграммы состояний.
Эти способы представления функций FSM рассмотрим на примере протокола ABP.
10.2.2 Спецификация протокола ABP
Для примера спецификации сетевых протоколов рассмотрим простой протокол
канального уровня, использующий схему нумерации пакетов по модулю два (Altering Bit
Protocol - ABP). Данный протокол предназначен для обеспечения надежной
однонаправленной передачи сообщений от пользователя-источника к пользователюполучателю, причем передача данных может осуществляться через ненадежную среду
передачи.
Пользователями протокола являются сущности сетевого уровня, которые обмениваются
данными, называемыми сообщениями. Протокол ABP реализует передачу сообщений
сетевого уровня посредством передачи пакетов данных на канальном уровне. При этом
предполагается, что среда передачи данных, может задерживать или искажать пакеты, но
не может их терять, переупорядочивать, дублировать.
Для повышения надежности передачи ABP использует дополнительный атрибут - номер
пакета, передаваемый вместе с управляющей информацией пакета. Значение этого
атрибута вычисляется сложением по модулю два значения номера последнего правильно
переданного пакета с единицей, что позволяет контролировать какой пакет - четный или
нечетный, находится в фазе передачи. В более сложных протоколах диапазон номеров
передаваемых пакетов может быть расширен, например, до восьми бит и более. Такой
диапазон называется окном передачи.
Получив сообщение от пользователя (протокольный блок данных сетевого уровня),
сущность-передатчик (SENDER) протокола ABP формирует пакет, содержащий номер
пакета (бит, чередующий значение нуля и единицы для последовательно передаваемых
пакетов) и данные пользователя (сообщение).
167
Сформированный таким образом пакет передается в среду, а его копия сохраняется
передатчиком. После чего передатчик ожидает поступление ответного пакета,
содержащего бит подтверждения, значение которого должно быть равно значению номера
последнего переданного пакета.
Если пакет подтверждения принимается с искажением (ошибка передачи или значение
бита в подтверждении не совпадает со значением номера последнего переданного пакета),
то передатчик повторяет передачу запомненной копии пакета.
Сущность-приемник (RECEIVER), приняв пакет, прежде всего, проверяет, не искажен
ли пакет средой. Если пакет искажен или значение номера пакета равно значению номера
предыдущего пакета, то приемник уничтожает принятый пакет, в противном случае он
выделяет из пакета сообщение и передает его пользователю-получателю. В любом случае
приемник формирует пакет-подтверждение, содержащего значение номера последнего
правильно принятого пакета.
Архитектура протокола ABP представлена на рис. 10.5, где используются следующие
обозначения:
n - PhSAP, u - LDSAP - точки доступа к сервису в подсистемах SENDER и RECEIVER.
Имена точек n и u далее будут использоваться как префиксы примитивов.
Рис. 10.5. Архитектура протокола ABP
Используя данное выше определение машины с конечным числом состояний, построим
спецификацию поведения протокольной сущности SENDER на основе этого понятия.
Определим входной и выходной алфавиты для конечного автомата, описывающего
поведение сущности SENDER.
Состав абстрактных сервисных примитивов ASPs для сущности SENDER следующий:
168

Send_request (или для краткости Send_req), инициируется пользователем сущности SENDER в точке
u.

Send_confirm (или для краткости Send_conf), инициируется сущностью SENDER в точке u.
Блоками данных PDU, пересылаемых от сущности SENDER к сущности RECEIVER,
являются:

DT0 - четный пакет данных, будем считать, что инициируется сущностью SENDER в точке n, т.к.
между пакетами и примитивами физического уровня может быть установлено взаимнооднозначное
соответствие.

DT1- нечетный пакет данных, инициируется сущностью SENDER в точке n с учетом таких же
замечаний, как и для блока DT0.
К блокам данных PDU, пересылаемым от сущности RECEIVER к сущности SENDER,
относятся:

ACK0 - подтверждение о принятии четного пакета

ACK1 - подтверждение о принятии нечетного пакета.
Таким образом, для сущности SENDER протокола ABP имеем:
I(SENDER)={u.Send_req, n.ACK0, n.ACK1}
O(SENDER)={u.Send_conf, n.DT0, n.DT1}.
Начальное состояние сущности SENDER - Ready.
Когда сущность SENDER находится в состоянии Ready, она может принять на вход
только одно событие u.Send_req. В этом случае значениями функций L и D будут:
L(u.Send_req,Ready) = n.DT0
D(u.Send_req,Ready) = WFACK0.
Эти значения интерпретируются следующим образом: сущность SENDER продуцирует
на выходе в точке n четный блок данных DT0 (событие n.DT0) и переходит в состояние
WFACK0 - состояние ожидания поступления в точку n блока данных ACK0
(подтверждения правильного приема сущностью RECEIVER блока данных DT0).
Кроме присваивания нового значения переменной, определяющей текущее состояние
протокольного автомата, функция D может выполнять дополнительные семантические
действия, связанные с реализацией протокольных функций, например, установку таймера
для контроля ситуации, когда время ожидания события n.ACK0 будет исчерпано.
Находясь в состоянии WFACK0, сущность SENDER протокола ABP может получить
два входных события n.ACK0 и n.ACK1, свидетельствующих о поступлении
подтверждений ACK0 и ACK1 соответственно. В принципе, чтобы сделать наш протокол
более защищенным от ошибок передачи на физическом уровне, было бы целесообразно
ввести в протокол аппарат таймеров. Тогда к возможным входным событиям для
169
состояния WFACK0 добавилось бы событие, связанное с приходом сигнала от таймера,
извещающего об исчерпании времени ожидания подтверждения передачи. Для упрощения
рассматриваемой модели протокола ABP такой аппарат вводиться нами не будет, хотя к
обсуждению этого вопроса мы еще вернемся.
При получении события n.ACK0 сущность SENDER перейдет в состояние Ready1,
продуцируя при этом в точке u для своего пользователя сервисный примитив
подтверждения Send_conf (событие u.Send_conf). В новом состоянии сущность SENDER
будет готова к обслуживанию очередного запроса на передачу сообщения от пользователя
посредством передачи нечетного блока данных (DT1).
При получении события n.ACK1 сущность SENDER останется в состоянии WFACK0 и
повторит передачу своему партнеру блока DT0. При этом семантическое действие,
обрабатывающее данную ситуацию может включать подсчет числа повторов передачи
блока данных и вызывать действия по обработке ситуации, связанной с исчерпанием
максимального числа повторов передачи.
Таким образом, функции L и D для состояния WFACK0 будут иметь следующие
возможные значения:
L(n.ACK0, WFACK0) = u.Send_conf
D(n.ACK0, WFACK0) = Ready1
L(n.ACK1, WFACK0) = n.DT0
D(n.ACK1, WFACK0) = WFACK0.
В состоянии Ready1 функции L и D определяются следующим образом:
L(u.Send_req,Ready1) = n.DT1
D(u.Send_req,Ready1) = WFACK1.
В состоянии WFACK1 сущность SENDER ожидает подтверждения передачи пакета
DT1 (событие n.ACK1), после поступления которого осуществит переход в состояние
Ready0 и выдаст в точке u для своего пользователя сервисный примитив подтверждения
Send_conf (событие u.Send_conf).
При получении события n.ACK0 (отрицательное подтверждение) сущность SENDER
останется в состоянии WFACK1 и повторит передачу блока DT1.
Таким образом, в состоянии WFACK0 функции L и D определяются следующим
образом:
L(n.ACK1, WFACK1) = u.Send_conf
D(n.ACK1, WFACK1) = Ready
L(n.ACK0, WFACK1) = n.DT1
D(n.ACK0, WFACK1) = WFACK1
170
На рис.10.6 иллюстрируется способ спецификации поведения протокольной сущности
SENDER, использующий диаграмму состояний соответствующего абстрактного автомата.
На рис. 10.7 функционирование сущности SENDER представлено в табличной форме,
при этом пустые клетки таблицы соответствуют неопределенным в протоколе ситуациям.
Они могут использоваться также для дополнительного контроля ошибочных ситуаций,
которые могли бы возникнуть в системе протокольный автомат-среда.
Еще раз анализирую семантику протокола ABP, легко увидеть, что даже для описания
такого простого протокола, каким является ABP, чисто автоматная модель описания его
динамики функционирования представляется ограниченной, хотя такая модель и
позволяет описать основные логические аспекты функционирования протокола. Поэтому
на практике используются различного рода расширения описательных возможностей
конечных автоматов. Такие расширения предпринимаются в следующих направлениях:
введения глобальной памяти или глобальных переменных, называемых также
переменными истории, замену функции D на процедурную семантику с возможность
анализа условий и выбора альтернативных решений, использования аппарата таймаутов,
структуризации состояний автомата, расширения функций автомата внешней схемой
управления (управляющими предикатами) и пр. Все эти расширения повышают удобство
спецификации сетевых протоколов, делая эти спецификации более компактными и
адекватными семантике протоколов.
Рис. 10.6. Диаграмма состояний для протокола ABP
Input\State
Ready
WFACK0
u.Send_req
WFACK0 n.DT0
Ready2
WFACK1
WFACK1 n.DT1
n.ACK0
Ready2 u.Send_conf
WFACK1 n.DT1
n.ACK1
WFACK0 n.DT0
Ready u.Send_conf
Рис. 10.7. Таблица состояний для протокола ABP
171
Теперь по аналогии построим спецификацию возможного поведения протокольной
сущности RECEIVER, расширив несколько модель машины с конечным числом состояний
в следующих аспектах.
Во-первых, в нашу модель мы введем следующие глобальные переменные истории:
RECEIVER_STATE, BUFFER, и H_PN.
Первая из них будет определять текущее состояние рассматриваемой сущности.
Вторая - будет служить входным буфером и хранить содержимое полученного от
физического уровня пакета (DT0 или DT1).
Третья предназначена для хранения номера текущего принятого и обрабатываемого
сущностью RECEIVER пакета.
Допустим, также, что начальное значение переменных истории H_PN и
RECEIVER_STATE будет установлено в 0 и Ready, соответственно.
Во-вторых, мы расширим функцию D, заменив определение следующего состояния
сущности по автоматной конфигурации (в частности, заданной таблично или в виде
диаграммы состояний) возможностью определения значения переменной истории
RECEIVER_STATE выполнением некоторой процедуры, использующей условные
операторы и оператор присваивания.
В-третьих, такое же расширение, какое мы допустили для функции D, мы допустим и
для функции L.
В-четвертых, введем в язык описания семантики протоколов следующие встроенные
функции:
? - функция ввода входного события (из точки u или из точки n в зависимости от префикса
события или контекста)
! - функция вывода выходного события (в точку u или в точку n в зависимости от
префикса события или контекста)
NUM() - функция определения номера последнего принятого пакета, хранящегося в
переменной BUFFER.
Остальное все будет аналогично тому, что мы делали для сущности SENDER.
Состав абстрактных сервисных примитивов ASPs для сущности RECEIVER
следующий:

Rec_indication (или для краткости Rec_ind), инициируется сущностью RECEIVER в точке u.

Rec_respond (или для краткости Rec_res), инициируется пользователем сущности RECEIVER в
точке u.
Блоки данных PDU, пересылаемые между сущностями SENDER и RECEIVER, такие
же, как рассматривались выше, к ним относятся пакеты: DT0, DT1, ACK0, ACK1.
Таким образом, для сущности RECEIVER протокола ABP имеем:
172
I(RECEIVER)={u.Rec_res, n.DT0, n.DT1}
O(RECEIVER)={u.Rec_ind, n.ACK0, n.ACK1}.
Когда сущность RECEIVER находится в состоянии Ready, она может принять в
начальный момент только одно событие n.DT0. Использую введенные выше расширения,
параметризуем это состояния таким образом, чтобы его можно было бы использовать и
для получения не только начального пакета, но и других пакетов, следующих в
последовательности, т.е. придадим этому событию свойство универсального средства
приема пакетов как DT0, так и DT1. В этом случае потребуется еще одно состояние, в
котором сущность RECEIVER будет ожидать поступления события с ответом
пользователя (u.Rec_res), и по прибытии этого события будет выдавать в среду пакет,
подтверждающий прием последнего переданного пакета.
В этом случае функции примут следующий вид L и D:
a) в случае состояния Ready и поступления событий n.DT0 или n.DT1
D_and_L_Ready()=
{
?BUFFER; //чтение нового пакета в переменную BUFFER
if H_PN= NUM() //пришел пакет с ожидаемым номером
then {!u.Rec_ind, //доставка пакета пользователю через событие u.Rec_ind
RECEIVER_STATE=RWR //перевод автомата в состояние RWR}
else
if H_PN=0 //выдача в точку n некорректного подтверждения
then !ACK1
else !ACK0
}
b) в случае состояния RWR и поступления u.Rec_res
D_and_L_RWR()=
{
? u.Rec_res; //ожидание и ввод события u.Rec_res
RECEIVER_STATE=Ready //перевод автомата в состояние приема пакетов}
if H_PN=0 //выдача в точку n подтверждения
then !ACK0
173
else !ACK1
}
Полученное описание представляет собой набор семантических подпрограмм
(D_and_L_Ready() и D_and_L_RWR()), вызываемых при возникновении в некотором
состоянии автомата некоторого события.
Общая логика работы такого автомата может быть задана таблицей состояние/входное
событие, возможная форма которой приведена на рис.10.8.
Событие\ Состояние
Ready
n.DT0 или n.DT1
D_and_L_Ready()
RWR
u.Rec_res
D_and_L_RWR()
Рис. 10.8. Таблица состояний для протокола ABP
Отметим, что для спецификации сетевых протоколов используется не только теория
конечных автоматов. В этой области достаточно широкое применение получили методы,
связанные с использованием сетей Петри и темпоральных логик.
Применение формальных способов спецификации протоколов создает основу для
разработки теоретически обоснованных решений при решении задач анализа,
верификации и оптимизации протоколов; синтеза, автоматизации программирования и
тестирования их реализаций.
10.Уязвимости web серверов. Технологии и методы защиты web серверов.
Введение
В самом общем виде web можно разделить на два основных компонента: web-серверы —
они являются приложениями, которые формируют информацию, доступную по протоколу
НТТР, и web-браузеры (клиенты) — они используются для доступа и показа информации,
хранящейся на web-серверах. В основном будем рассматривать проблемы безопасности,
касающиеся web-серверов.
К сожалению, web-серверы часто являются целями атак. Вследствие этого важно
гарантировать безопасность web-серверов, а также сетевой инфраструктуры, которая их
174
поддерживает. Угрозы безопасности, специфичные для web-серверов в общем случае
можно разделить на следующие категории:

Враждебно настроенные пользователи интернета могут использовать ошибки ПО в
web-серверах лежащей в основе ОС или в программах, создающих динамические
web-страницы, для получения неавторизованного доступа к web-серверу.
1.
Результатом этого может быть получение доступа к файлам или каталогам, которые не
предназначены для открытого доступа, либо выполнение привилегированных команд и/или
установка ПО на web-сервер.
2.
Информация на web-сервере может быть преднамеренно изменена с враждебными целями.
Наиболее общим примером такой угрозы является подмена содержимого web-сайта.

Denial of service (DoS) атаки могут быть направлены на web-сервер что приведет к отказу в доступе
законным пользователям.

Чувствительная информация, передаваемая в открытом виде между web-сервером и браузером,
может быть перехвачена.

Пользователи могут получить неавторизованный доступ к ресурсам, расположенным где-то еще в
локальной сети организации, используя успешную атаку на web-сервер.

Возможно осуществление атаки на другие сети и серверы, причем будет использован
скомпрометированный web-сервер, скрыта настоящая идентификация и, иногда, ответственность за
последствия возложена на администратора web-сервера, с которого выполняется атака.

Сервер может быть использован в качестве незаконной точки распространения ПО,
инструментальных средств атаки, при этом на администратора сервера может быть возложена
ответственность за последствия атаки.
Рассмотрим проблемы, связанные с безопасностью при инсталлировании,
конфигурировании и сопровождении web-серверов. Перечислим кратко основные
вопросы:

Безопасное инсталлирование и конфигурирование лежащей в основе ОС.

Безопасное инсталлирование и конфигурирование ПО web-сервера.

Развертывание соответствующих сетевых механизмов защиты:
o
Firewall’ы;
o
Intrusion detection systems (IDS);
o
DNS.

Поддержка безопасной конфигурации, со своевременным применением соответствующих patches и
upgrades, тестированием безопасности, просмотром логов и выполнение backup’ов как данных, так и
ОС.

Обеспечение защиты информации, исходя из ее семантики.
Здесь нужно придерживаться следующих принципов.
Следует реализовать соответствующую практику управления безопасностью и
контроль за функционированием системы.
175
Соответствующая практика управления является критичной для функционирования и
поддержки безопасного web-сервера. Необходимо определить требования к
развертыванию, документированию и реализации политик, стандартов, процедур и
руководств, которые гарантируют конфиденциальность, целостность и доступность
информационных ресурсов.
Для гарантирования безопасности web-сервера и поддержки сетевой инфраструктуры
должны быть рассмотрены и реализованы следующие основные моменты:

Политика безопасности информационной системы организации.

Принципы управления и контроля конфигурации и ее изменений.

Анализ риска и определенные подходы к управлению риском.

Стандартные конфигурации ПО, которые удовлетворяют политике безопасности информационной
системы.

Необходимый объем знаний и тренинги, обеспечивающие требуемый объем знаний.

Способы восстановления после внезапных сбоев.

Соответствующая сертификация и аккредитация.
Следует гарантировать, что ОС, на которой выполняется web-сервер, развернута,
сконфигурирована и управляется в соответствии с требованиями безопасности.
Первым шагом в обеспечении безопасности web-сервера является безопасность лежащей в
основе ОС. Большинство доступных web-серверов выполняются на ОС общего
назначения. Многих проблем безопасности можно избежать, если ОС, лежащая в основе
web-сервера, сконфигурирована соответствующим образом. Конфигурации по умолчанию
для аппаратуры и ПО обычно устанавливаются производителями, при этом, как правило,
делается упор на использование возможностей, функциональностей исходного ПО, а
также на простоту использования возможностей, связанных с безопасностью. Также
следует понимать, что производители не знают требований безопасности каждой
организации, поэтому web-администратор должен сконфигурировать новые серверы в
соответствии с требованиями безопасности и переконфигурировать их каждый раз при
изменении этих требований. Обеспечение безопасности ОС как минимум должна
включать следующие шаги:

выполнение patch’ей и upgrade’ов ОС;

удаление или запрещение ненужных сервисов и приложений;

конфигурирование управления ресурсами;

тестирование безопасности ОС.
Следует гарантировать, что ПО web-сервера развернуто, сконфигурировано и управляется
в соответствии с требованиями безопасности, определенными в организации.
Во многих аспектах инсталляция и конфигурирование безопасности ПО web-сервера
аналогично процессу инсталляции и конфигурирования ОС. Главным принципом, как и
176
раньше, является инсталляция минимального числа требуемых сервисов web-сервера и
удаление всех известных уязвимостей с помощью patche’ей и upgrade’ов. Если
инсталляционная программа устанавливает какие-то ненужные приложения, сервисы или
скрипты, они должны быть удалены немедленно после завершения процесса установки.
Обеспечение безопасности web-сервера как минимум должно включать следующие шаги:

выполнение patch’ей и upgrade’ов ПО web-сервера– удаление или запрещение ненужных сервисов,
приложений и примеров содержимого;

конфигурирование аутентификации пользователей web-сервера;

конфигурирование управления ресурсами web-сервера;

тестирование безопасности приложения web-сервера и конкретного содержимого web-сервера.
Следует предпринять шаги для гарантирования того, что на web-сайте публикуется
только корректное содержимое.
Должна существовать четкая политика в определении того, какой тип информации
является открытым, к какой информации следует ограничить доступ и какая информация
не должна публиковаться в публично доступном репозитории.
Следует гарантировать защиту web-содержимого от неавторизованного доступа или
модификации.
Должна существовать определенная политика, гарантирующая невозможность
модификации без выполнения авторизации. Требуется обеспечить гарантию целостности,
даже если информация не является конфиденциальной. Необходимо защищать
содержимое web посредством выполнения соответствующего управления ресурсами webсервера. Некоторые примеры управления ресурсами включают:

инсталлирование только необходимых сервисов;

инсталлирование web-содержимого на выделенном жестком диске или в выделенном разделе;

возможность выполнять запись (uploads) только в директории, которые не являются читаемыми из
web-сервера, а доступны по некоторому другому протоколу (например, ftp);

определение единственной директории для всех скриптов или программ, которые выполняются для
создания web-содержимого и являются внешними по отношению к web-серверу;

запрещение использования жестких или символических ссылок в файловой системе ОС, на которой
выполняется web-сервер;

создание матрицы доступа к web-содержимому, которая определяет, какие папки и файлы внутри
директории web-сервера имеют ограничения по доступу;

запрет просмотра директории в файловой системе;

использование аутентификации пользователей с помощью цифровых подписей и других
криптографических механизмов;

использование систем обнаружения проникновений, основанных на хосте и /или проверки
целостности файлов, для обнаружения проникновения и проверки целостности web-содержимого.
177
Следует использовать активное содержимое только после тщательного взвешивания
получаемых при этом преимуществ в сравнении с увеличением рисков.
Вначале большинство web-сайтов представляли собой статическую информацию,
расположенную на сервере, обычно в форме текстовых документов, имеющих
соответствующую разметку (HTML). В дальнейшем вводились различные интерактивные
элементы. К сожалению, эти интерактивные элементы вносят новые уязвимости, так как
они предполагают пересылку определенного рода информации как от web-сервера к
клиенту для выполнения на стороне клиента, так и от клиента к web-серверу для
обработки информации на стороне сервера. Различные технологии создания активного
содержимого имеют различные уязвимости, которые должны быть оценены в сравнении с
получаемыми преимуществами.
Следует использовать аутентификацию, основанную на криптографических
технологиях, для обеспечения соответствующей защиты чувствительных данных.
Публичные web-серверы обычно поддерживают широкий спектр технологий
идентификации и аутентификации пользователей и определения различных привилегий
для доступа к информации. Некоторые из этих технологий основаны на
криптографических функциях, которые могут обеспечивать тот или иной тип
зашифрованного канала между клиентом web-браузера и web-сервером. Web-серверы
могут быть сконфигурированы для использования различных криптографических
алгоритмов, обеспечивающих различные уровни безопасности.
Без наличия аутентификации пользователей нет возможности обеспечить разграничение
доступа к чувствительной информации. Без наличия сильных механизмов аутентификации
вся информация, которая расположена в web-пространстве сервера, может стать
доступной любому. Кроме того, без процесса аутентификации сервера пользователи не
имеют возможности определить, что сервер является требуемым, а не поддельным,
созданным враждебно настроенным участником для перехвата конфиденциальной
информации о пользователе.
Следует обеспечивать безопасность сетевой инфраструктуры для защиты web-серверов.
Сетевая инфраструктура, в которой функционирует web-сервер, играет важную роль в
обеспечении безопасности web-сервера. Во многом сетевая инфраструктура является
первой линией обороны web-сервера. Однако только тщательное проектирование сети не
является достаточным для защиты web-сервера. Частота и варианты web-атак,
совершаемых сегодня, говорят о том, что безопасность web-серверов может быть
обеспечена только с использованием различных и расположенных на разных уровнях
механизмов обороны (так называемая "оборона вглубь").
Следует гарантировать постоянное функционирование системы обеспечения
безопасности.
Поддержание безопасного функционирования web-сервера требует постоянных усилий и
наличия достаточного количества ресурсов. Поддержание безопасности web-сервера
обычно включает следующие шаги:

своевременное применение patch’ей и upgrade’ов;
178

конфигурирование, защита и анализ лог файлов;

частое выполнение back up’а критической информации;

поддержка защищенных копий web-содержимого;

определение процедур восстановления при компрометации и следование им при обнаружении
проникновения;

периодическое тестирование безопасности.
Рассмотрим общие принципы, которые применимы ко всем системам.
Причины уязвимости web-сервера
Основные проблемы, связанные с безопасностью функционирования публично
доступного web-сайта, возникают по следующим причинам:

Неправильная конфигурация или другое некорректное действие над web-сервером, которое может
привести к раскрытию или изменению информации.

Уязвимости ПО web-сервера, которые могут допускать, например, чтобы атакующий
компрометировал безопасность сервера или других хостов в сети.

Неадекватные механизмы защиты web-сервера, предусмотренные в его окружении.

ПО на стороне сервера (скрипты, JSP, ASP и т.п.), которое содержит ошибки, позволяющие
атакующим компрометировать безопасность web-сервера.
Планирование развертывания web-сервера
При планировании развертывания web-сервера следует рассмотреть следующие пункты:


Определить цели web-сервера;
o
Какие категории информации будут храниться в web-сервере.
o
Какие категории информации будут обрабатываться или передаваться через web-сервер.
o
Каковы требования безопасности для данной информации.
o
Существует ли информация, которая получена с другого сервера или хранится на другом
сервере (например, backend база данных, почтовый сервер, прокси-сервер).
o
Какие еще сервисы предоставляет web-сервер (должен ли web-сервер выполняться на
выделенном хосте).
o
Каковы требования безопасности для этих дополнительных сервисов.
Определить сетевые сервисы, которые будет предоставлять web-сервер, и
используемые при этом протоколы:
o
НТТР, НТТРS, SOAP и т.п. – протоколы взаимодействия с клиентами.
o
ODBC, JDBC, LDAP, LDAPS, NFS и т.п. – протоколы взаимодействия с backend-системами.
179

Определить все необходимое ПО, которое требуется для поддержки функционирования webсервера;

Определить категории пользователей web-сервера и всех backend-систем;

Определить способы аутентификации пользователей и web-сервера и способы защиты
аутентификационных данных;

Определить, как будет предоставляться соответствующий доступ к информационным ресурсам.
Безопасность лежащей в основе ОС
Первым шагом в обеспечении безопасности web-сервера является безопасность лежащей в
его основе ОС. Большинство общедоступных web-серверов функционируют на ОС общего
назначения. Многих проблем безопасности можно избежать, если ОС соответствующим
образом сконфигурирована. Конфигурации по умолчанию аппаратуры и ПО обычно
поставляются производителями с упором на возможности безопасного функционирования
и возможности легкого расширения. Так как производители не знают потребности
безопасности каждой организации, каждый web-администратор должен сконфигурировать
новые серверы в соответствии с требованиями безопасности своей организации.
Данная технология в различных ОС может сильно отличаться. Также могут существовать
некоторые автоматизированные инструментальные средства для настройки ОС с точки
зрения безопасности.
Выбор приложения web-сервера может определяться выбором ОС. Однако по
возможности web-администраторы должны выбрать ОС, которая обеспечивает
следующее:

возможность ограничить деятельность административного уровня или уровня root только
авторизованными пользователями;

возможность управлять доступом к данным на сервере;

возможность запретить сетевые сервисы, не являющиеся необходимыми, которые встроены в ПО
ОС или сервера;

возможность управления доступом к различным формам выполнимых программ, таких как CGIскрипты и plug-ins, на стороне сервера;

возможность записывать в лог соответствующую деятельность сервера для определения
проникновения и попыток проникновения.
Безопасное инсталлирование и конфигурирование ОС
Применение Patch и Upgrade ОС
После того как ОС инсталлирована, следует применить все patches и upgrades для
удаления известных уязвимостей. Все ОС, реализованные сегодня, имеют известные
уязвимости, которые должны быть удалены перед использованием ОС в качестве хоста
web-сервера. Для адекватного определения и корректирования этих уязвимостей webадминистратор должен:
180

идентифицировать уязвимости и применить patches;

смягчить уязвимости, для которых пока patches еще не доступны, не протестированы или не
установлены;

проводить регулярное инсталлирование fixes (часто называемых patches, hotfixes, service packs или
updates).
Удаление или запрещение ненужных сервисов и приложений
Идеально, чтобы web-сервер был выделенным и использовался только для этой цели.
Многие ОС сконфигурированы по умолчанию для предоставления более широкого круга
сервисов и приложений, чем требуется web-серверу; следовательно, web-администратор
должен сконфигурировать ОС, удалив или запретив сервисы, не являющиеся
необходимыми. Приведем некоторые примеры сервисов, которые обычно должны быть
запрещены:

NetBIOS, если не требуется.

NFS, если не требуется.

FTP.

Berkley "r" сервисы (например, rlogin, rsh, rcp).

Тelnet.

NIS.

SMTP.

Компиляторы.

Инструментальные средства разработки ПО, за исключением того случая, когда HTML страницы
создаются каким-либо интерпретатором, например, Perl. В этом случае должен быть оставлен
только используемый интерпретатор.
Удаление ненужных сервисов и приложений является предпочтительным, чем просто
запрещение с помощью конфигурационных установок, потому что атакующий может
попытаться изменить установки и активизировать запрещенные сервисы, что нельзя
сделать при полном удалении.
Удаление или запрещение ненужных сервисов усиливает безопасность web-сервера по
следующим причинам:

ненужные сервисы не могут быть скомпрометированы и использованы для атаки на хост или для
повреждения сервисов web-сервера. Каждый имеющийся в наличии сервис увеличивает риск
компрометации хоста, потому что каждый сервис потенциально открывает вход для доступа
атакующего;

обычно различные сервисы могут администрировать разные люди. Следует изолировать сервисы
таким образом, чтобы каждый хост имел одного администратора при минимально возможных
конфликтах между администраторами. Наличие одного администратора, отвечающего за хост,
приводит к лучшему распределению обязанностей;
181

хост может быть лучше сконфигурирован для удовлетворения требований конкретного сервиса.
Различные сервисы могут требовать наличия различной аппаратуры и конфигураций ПО, которые
приводят к возникновению уязвимостей или ограничениям сервиса;

при уменьшении числа сервисов уменьшается и количество логов и записей лога, благодаря чему
обнаружение некорректного поведения становится легче.
При конфигурировании ОС следует применять принцип "запретить все, за исключением
того, что явно разрешено" — это означает запретить и по возможности удалить все
сервисы и приложения и затем выборочно разрешить те, которые требуются web-серверу.
Также нужно по возможности установить минимальную конфигурацию ОС, которая
требуется для приложения web-сервера. Если система инсталляции ОС предоставляет
опцию "минимальная инсталляция", то нужно выбрать ее, потому что это минимизирует
усилия, требуемые для удаления ненужных сервисов. Многие скрипты или программы
типа uninstall не выполняют полного удаления всех компонент сервиса; следовательно,
всегда лучше по возможности избегать инсталлирования ненужных сервисов.
Необходимые web-серверу сервисы зависят от функций, которые должен обеспечивать
сервер. Эти сервисы могут включать протоколы баз данных для доступа к базе данных,
протоколы передачи файлов и сервисы удаленного администрирования. Каждый из этих
сервисов, даже если он необходим, увеличивает риск для сервера. Когда риски
перекрывают преимущества, следует рассмотреть необходимость наличия каждого
сервиса.
Конфигурирование аутентификации пользователя в ОС
Авторизованных пользователей, которые могут конфигурировать систему и запускать
различные сервисы, обычно очень мало. Однако пользователей, которые могут иметь
доступ к публичному web-серверу, может быть как неограниченное количество, так и
некоторое ограниченное подмножество Интернет-сообщества. Для обеспечения политики
безопасности web-администратор должен сконфигурировать систему для аутентификации
пользователей, которым разрешен вход, требуя предоставления доказательства своей
идентификации. Даже если web-сервер разрешает неаутентифицированный доступ к
большинству сервисов, администрирование и другие типы специализированного доступа
должны быть ограничены определенными персонами или ролями.
Конфигурирование компьютера для аутентификации обычно включает конфигурирование
ОС, firmware и приложений на сервере, таких как ПО, которое реализует сетевой сервис. В
специальных случаях для сайтов с высоким риском или хранящих важные данные можно
также применять аппаратуру для аутентификации, например, токены или устройства с
одноразовыми паролями. Использование аутентификационных механизмов, в которых
аутентификационная информация является переиспользуемой (например, пароли) и
передается в явном виде по сети, не рекомендуется, потому что информация может быть
перехвачена и задействована атакующим для подделки под аутентифицированного
пользователя.
Для гарантии того, что соответствующая аутентификация пользователя выполняется,
необходимо выполнить следующие шаги.
182

Удалить или запретить неиспользуемые аккаунты и группы, созданные по умолчанию.
Конфигурация ОС по умолчанию часто включает аккаунт guest (как с паролем, так и без), аккаунты
уровня администратора или root, связанные с локальными и сетевыми сервисами. Имена и пароли
этих аккаунтов хорошо известны. Удаление или запрещение ненужных аккаунтов предотвращает их
использование для проникновения, включая аккаунты guest, на компьютерах, содержащих
чувствительную информацию. Если существует требование оставить аккаунт или группу guest,
следует ограничить их доступ и изменить пароль в соответствии с политикой для паролей в
организации. Для аккаунтов по умолчанию, которые необходимо оставить, следует изменить имена
(где возможно, особенно для аккаунтов уровня администратора или root) и пароли в соответствии с
политикой для паролей. Следует помнить, что имена аккаунтов и пароли по умолчанию хорошо
известны злоумышленникам.

Запретить неинтерактивные аккаунты. Запретить аккаунты (и связанные с ними пароли),
которые должны существовать, но не требуют интерактивного входа. Для Unix-систем запретить
входной shell или предоставить входной shell с функциональностью NULL (/bin/false).

Создать группы пользователей. Привязать пользователей к соответствующим группам и
назначать права группам. Данный подход предпочтительнее, чем назначать права индивидуальным
пользователям.

Создать аккаунты пользователей. Определить, кто авторизован использовать каждый компьютер
и его сервисы. Создать только необходимые аккаунты. Не допускать использования разделяемых
аккаунтов.

Проверить политику для паролей в организации. Установить пароли аккаунтов
соответствующим образом. Данная политика должна рассматривать следующее:

o
длина – минимальная длина паролей;
o
сложность – требуемые символы. Требуемые пароли содержат буквы как верхнего, так и
нижнего регистров и, по крайней мере, один неалфавитный символ;
o
срок использования – как долго можно не изменять пароль. Требовать от пользователей
периодически изменять пароли. Пароль уровня администратора или root должен изменяться
каждые 30–120 дней. Пароль пользователя также должен периодически изменяться. Этот
период определяется длиной и сложностью пароля в сочетании с чувствительностью
защищаемой им информации;
o
переиспользуемость – может ли пароль переиспользоваться. Некоторые пользователи
пытаются обойти требование устаревания пароля, изменяя пароль на тот, который они уже
использовали до этого. Нужно по возможности гарантировать, что пользователь не может
изменить пароль простым добавлением "предполагаемых" символов к своему исходному
паролю. Например, исходный пароль был "mysecret", а измененный – "mysecret1" или
"1mysecret";
o
авторство – кому разрешено изменять или переустанавливать пароли и какого типа
доказательство требуется перед началом любых изменений.
Сконфигурировать компьютеры для запрещения входа после небольшого
числа неудачных попыток. Следует помнить, что может быть относительно легко
для неавторизованного пользователя получить доступ к компьютеру, используя
автоматические программные средства, которые перебирают все пароли. Чтобы ОС
не предоставляла такую возможность, ее следует сконфигурировать таким образом,
когда она будет запрещать вход после трех неудачных попыток. Обычно аккаунт
блокируется на определенное время (например, 30 минут) или до тех пор, пока
пользователь с соответствующими полномочиями не активирует его.
183
Это пример ситуации, когда от web-администратора требуется принятие решения о
балансе между безопасностью и удобством. Реализация данной возможности
может помочь предотвратить некоторые типы атак, но может также позволить
злоумышленнику выполнить неудачные попытки входа для недопущения доступа
пользователя, т.е. выполнить DoS-атаку для конкретного пользователя.
Неудачные попытки сетевого входа не должны запрещать вход с консоли
пользователя и тем более администратора. Заметим также, что все неудачные
попытки по сети или с консоли должны регистрироваться. Также, если удаленное
администрирование не предусмотрено, следует запретить возможность входа по
сети аккаунтам уровня администратора или root.

Инсталлировать и сконфигурировать другие механизмы безопасности для усиления
аутентификации. Если информация на web-сервере требует этого – рассмотреть использование
других аутентификационных механизмов, таких как токены, сертификаты клиента и сервера или
системы одноразовых паролей. Хотя они могут быть более дорогими и трудными в реализации, это,
возможно, оправдается в некоторых случаях. Когда используются подобные механизмы
аутентификации и устройства, политика организации должна быть пересмотрена и в ней отражен
наилучший способ их применения.

Создавать и распространять отчеты об использовании аккаунтов пользователей. Для того чтобы
гарантировать, что все неиспользуемые аккаунты удаляются своевременно, важно установить в
организации систему, которая создает отчеты о пользовательских аккаунтах, включающие
информацию, необходимую для определения того, должен ли аккаунт оставаться активным. Эти
отчеты должны распространяться соответствующим пользователям и управляющему персоналу для
определения индивидуумов, которым более не требуется иметь аккаунт.
Как отмечалось ранее, нарушитель, используя сетевые сниферы, может легко перехватить
переиспользуемые пароли, передаваемые по сети в явном виде. Вместо этого следует
использовать менее уязвимые технологии аутентификации и шифрования, такие как SSH
и SSL/TLS.
Управление ресурсами на уровне ОС
Многие ОС имеют возможность указать конкретные привилегии доступа для файлов,
директорий, устройств и других коммуникационных ресурсов. Тщательно продумывая
управление доступом, web-администратор может уменьшить преднамеренные и
непреднамеренные бреши в безопасности. Например, запрет доступа по чтению к файлам
и директориям помогает обеспечить конфиденциальность информации, тогда как запрет
доступа по записи помогает обеспечить целостность информации. Разрешая выполнение
большинства инструментальных средств системного уровня только системным
администратором, можно предотвратить внесение пользователями изменений в
конфигурацию, которые понижают безопасность системы. Такое ограничение может
также уменьшить возможность атакующего использовать эти инструментальные средства
для атаки как на данную систему, так и на другие системы в сети. Так как управление
ресурсами ОС тесно связано с управлением ресурсами web-сервера, данная проблема
будет рассмотрена далее в деталях.
184
Альтернативные платформы для web-сервера
Часто web-серверы выполняются на ОС общего назначения. В то же время существуют
примеры, когда используется одна из альтернатив, обсуждаемых ниже. Хотя данные
средства являются относительно новыми для web-серверов, они основаны на надежных
технологиях и, возможно, скоро найдут широкое применение для использования в
качестве окружения web-сервера.
Trusted ОС
Trusted ОС (TOS являются модифицированными с учетом требований безопасности или
специально усиленные ОС, которые включают дополнительные механизмы безопасности,
отсутствующие в ОС общего назначения. Они уже изначально создавались с
использованием мандатного управления доступом. TOS обеспечивают безопасную
политику управления, четко определенное множество привилегий доступа, расширяемые
возможности создания логов и аудита. Большинство TOS подвергались независимой
проверке для гарантии того, что они соответствуют множеству требований, указанных в
их документации.
TOS обычно используются в приложениях, где безопасность очень важна. TOS могут
безопасно управлять всеми аспектами своего окружения, включая сетевые ресурсы,
пользователей, процессы, память и т.п. Более конкретно, TOS имеют возможность
ограничить доступ к системным ресурсам таким способом, в который нельзя вмешаться
или скомпрометировать.
Использование TOS обычно приводит к созданию очень безопасного web-сервера, однако
существуют определенные трудности при их использовании. Основной недостаток
состоит в том, что администрирование TOS требует хорошего знания каждой защищенной
подсистемы. Тем не менее, даже при таких ограничениях, организации, которые имеют
большие требования к безопасности, должны рассмотреть возможность использования
TOS для поддержки web-серверов.
Должны быть рассмотрены следующие вопросы при определении того, какую платформу
использовать для web:

какая ОС лежит в основе и насколько проанализирована ее безопасность;

имеет ли организация опыт администрирования TOS– какова дополнительная цена покупки и
поддержки TOS по сравнению с ее преимуществами;

совместима ли TOS с существующими в организации web-приложениями и скриптами.
Использование Appliances для web-сервера
Относительно недавние разработки в области web-серверов привели к появлению так
называемых web Appliances. Web Appliances является комбинацией ПО и аппаратуры,
которая разработана, чтобы быть "plug-and-play" web-сервером. Эти Appliances
используют упрощенную ОС, которая оптимизирована для поддержки web-сервера.
Упрощенная ОС обеспечивает безопасность, минимизируя возможности, сервисы и
опции, которые не являются необходимыми для web-приложений. ПО web-сервера в таких
185
системах часто заранее инсталлировано и заранее сконфигурировано с точки зрения
безопасности.
Такие системы часто имеют преимущества, относящиеся к наличию дополнительной
безопасности. Выполнение часто улучшается, так как система (ОС, ПО web-сервера и
аппаратура) разработана и собрана специально для выполнения web-сервера. Цена на них
зачастую ниже, так как аппаратура и ПО не требуют специальной настройки для webсервера. Такие системы могут быть отличным решением для малых и средних
организаций, которые не могут себе позволить иметь web-администратора на полную
ставку.
Самым большим недостатком таких систем является то, что они не подходят для больших
сложных и многоуровневых web-сайтов. Они могут также не подойти организациям,
которым требуется более одного сервера, если только организация не захочет покупать
web Appliances от одного производителя, так как такая простота делает трудным
конфигурирование вместе web Appliances от разных производителей. Web Appliances
доступны от основных производителей аппаратуры и от различных специализированных
производителей web Appliances.
Некоторые вопросы, которые следует рассматривать при принятии решения о покупки
web Appliances:

какая ОС лежит в основе и как она протестирована с точки зрения безопасности;

как web Appliance само протестировано с точки зрения безопасности. (Заметим, что
конфигурационные опции web Appliances являются ограниченными, таким образом, web Appliance
обычно бывает безопасным только при инсталляции по умолчанию);

какова разнородность инфраструктуры web-сервера организации. (Различные торговые марки web
Appliances, как правило, не очень хорошо работают вместе);

имеется ли возможность какого-либо расширения web Appliances. (Организация, которая
предполагает быстрый рост, может не захотеть ограничивать себя web Appliance).
Специально усиленные (pre-hardened) ОС и web-серверы
Сегодня распространяется всё возрастающее число специально усиленных ОС и пакетов
web-сервера. Эти пакеты включают ОС и ПО web-сервера, которые модифицированы и
заранее сконфигурированы для обеспечения большой безопасности. Некоторые из этих
пакетов содержат и аппаратную платформу, другие являются ПО, которое состоит только
из ОС и ПО web-сервера. Эти дистрибутивы обычно основаны на специально усиленной
и/или модифицированной ОС общего назначения (например, Linux, Unix и, реже,
Windows), которая специально разработана для поддержки безопасного web-сервера.
Приложение web-сервера также часто основано на усиленном и/или модифицированном
обычном ПО web-сервера например, Apache или IIS). Эти пакеты зачастую включают
большее число опций безопасности и разработаны для более легкого конфигурирования с
помощью заранее cкомпилированных скриптов и GUIs. Хотя все пакеты различны, они
обычно обеспечивают какие-либо из следующих возможностей:

безопасная начальная конфигурация обеспечена по умолчанию;
186

наличие усиленной ОС и/или TOS– наличие усиленного ПО web-сервера;

расширяемые возможности аудита;

наличие разного рода оберток (wrappers) для приложений;

наличие возможностей сетевых wrappers и/или host-based firewall;

host-based IDS;

упрощенное администрирование безопасности (например, меню, GUIs).
Эти типы систем должны быть рассмотрены организацией, которая понимает важность
угроз и/или имеет важные данные на web-сайтах (например, правительственные
организации, банки и т.п.). Такие пакеты доступны от некоторых основных
производителей аппаратуры и ПО, а также от некоторых специализированных
производителей.
Некоторые вопросы, которые следует рассмотреть при приобретении усиленного web
Appliance.

Какая ОС лежит в основе и как она протестирована относительно безопасности.

Как само ПО web-сервер протестировано относительно безопасности.

Насколько трудно его администрировать.

Совместимо ли усиленное ПО web-сервер с существующими в организации web-приложениями и
скриптами.
Тестирование безопасности операционной системы
Периодическое тестирование безопасности ОС является важным способом
идентифицировать уязвимости и гарантировать, что существующие меры обеспечения
безопасности эффективны. Наиболее популярными методами тестирования ОС являются
сканирование уязвимостей и тестирование проникновения. Обычно используют
автоматизированные сканеры уязвимостей для сканирования уязвимостей приложения,
сети или ОС на хосте или группе хостов в сети. Тестирование проникновения является
процессом тестирования, разработанным для проверки возможности компрометации сети,
при этом используются инструментальные средства и методики атакующего. Это
итеративный процесс тестирования, который идентифицирует наиболее слабые области
сети и использует их для получения доступа к оставшейся сети. Результатом обычно
является компрометация безопасности всей сети. Сканирование уязвимостей должно
проводиться периодически, по крайней мере, раз в неделю или в месяц. Тестирование
проникновения должно быть минимум ежегодным. Так как обе эти технологии
тестирования применяются также для тестирования приложений web-сервера, далее они
будут обсуждаться более детально.
Список действий для обеспечения безопасности ОС, на которой
выполняется web-сервер
Составление плана конфигурации и развертывания web-сервера.
187

Определить функции web-сервера.

Определить категории информации, которая будет храниться, обрабатываться и передаваться webсервером.

Определить требования безопасности для данной информации.

Определить способы опубликования информации на web-сервере.

Определить необходимость иметь выделенный хост для web-сервера.

Определить пользователей и категории пользователей web-сервера и определить привилегии
каждой категории пользователей.

Определить методы аутентификации пользователей на web-сервере.
Выбор подходящей ОС для web-сервера.

Максимальная защищенность от уязвимостей.

Возможность ограничить деятельность уровня администратора или root только
аутентифицированными и авторизованными пользователями.

Возможность запретить доступ к информации на сервере всем, кроме явно указанных
пользователей.

Возможность сделать недоступными ненужные сетевые сервисы, которые могли быть встроены в
ОС или ПО сервера.

Возможность управления доступом к различным программам, связанным с web-сервером, таким как
CGI-скрипты и plug-ins сервера в случае web-сервера.
Применение patch’ей и upgrade’ов ОС.

Определить и инсталлировать все необходимые patches и upgrades для ОС.

Определить и инсталлировать все необходимые patches и upgrades для приложений и сервисов,
включенных в ОС.
Удаление или запрещение ненужных сервисов и приложений.
Конфигурирование аутентификации пользователей в ОС.

Удалить или запретить ненужные аккаунты и группы, существующие по умолчанию.

Запретить неинтерактивные аккаунты.

Создать группы пользователей для данного экземпляра ОС.

Создать аккаунты пользователей для данного экземпляра ОС.

Проверить политику пароля в организации и установить соответствующие пароли аккаунтов (длина,
сложность).

Сконфигурировать ОС для запрещения входа после небольшого числа неудачных попыток.

Инсталлировать и сконфигурировать другие механизмы безопасности для усиления
аутентификации.
188
Тестирование безопасности ОС.

Протестировать ОС после начальной инсталляции для определения уязвимостей.

Проводить частое тестирование ОС для определения новых уязвимостей.
Безопасное инсталлирование и конфигурирование web-сервера
После того как ОС инсталлирована и сделана безопасной, следует инсталлировать
выбранное ПО web-сервера. Перед началом данного процесса следует прочитать
документацию производителя и понять, какие опции доступны при инсталляции. Также
следует посетить web-сайт производителя или web-сайт базы данных уязвимостей, такой
как ICAT метабаза (http://icat.nist.gov), для определения всех известных уязвимостей и
соответствующих patches, которые должны быть инсталлированы или сконфигурированы
как часть процесса установки. Только после завершения этих предварительных шагов
следует начать инсталляцию. Будем обсуждать только общие процедуры инсталляции и
конфигурирования.
Безопасное инсталлирование web-сервера
Во многих аспектах безопасное инсталлирование и конфигурирование приложения webсервера аналогично инсталляции и конфигурированию ОС. Основной принцип состоит в
том, чтобы инсталлировать минимальное количество требуемых сервисов web-сервера и
исключить все известные уязвимости с помощью patches или upgrades. Если программа
инсталляции устанавливает какие-то ненужные приложения, сервисы или скрипты, они
должны быть немедленно удалены после завершения процесса. При инсталляции webсервера должны быть выполнены следующие шаги:
1.
Инсталлировать ПО сервера на выделенный хост.
2.
Инсталлировать минимально требуемые сервисы Интернета.
3.
Применить все patches или upgrades для корректировки известных уязвимостей.
4.
Создать выделенный физический диск или логический раздел (отдельный от ОС и приложения
сервера) для содержимого web.
5.
Удалить или запретить все web-сервисы, инсталлированные приложением web-сервера, но не
требуемые (например, gopher, FTP и удаленное администрирование).
6.
Из корневой директории приложения web-сервера удалить все файлы, которые не являются частью
web-сайта.
7.
Удалить всю документацию, а также примеры скриптов и выполняемого кода.
8.
Выполнить разного рода образцы безопасности или "hardening" скрипты, усиливающие
безопасность web-сервера.
9.
Переконфигурировать баннер НТТР-сервиса (и других сервисов, если они используются), чтобы он
не сообщал о типе и версии web-сервера и ОС. Это может быть выполнено в IIS использованием
свободного Microsoft IIS Lockdown Tool и в Apache посредством "ServerTokens" директивы.
189
Конфигурирование управления доступом
Большинство ОС для web-серверов предоставляют возможность указать конкретные
привилегии доступа для файлов, устройств и других вычислительных ресурсов на данном
хосте. Следует понимать, что любая информация, к которой может быть осуществлен
доступ из каталогов, принадлежащих web-серверу потенциально может стать доступной
всем пользователям, имеющим доступ к публичному web-сайту. Обычно ПО web-сервера
обеспечивает дополнительное управление доступом к файлам, устройствам и ресурсам. В
случае, если разрешения доступа к ресурсам могут быть установлены как на уровне ОС,
так и на уровне приложения web-сервера, важно, чтобы они были идентичны друг другу, в
противном случае возможна ситуация, когда пользователям предоставлен либо очень
большой, либо очень маленький доступ. Web-администраторы должны рассмотреть, какое
конфигурирование доступа к хранимой в публичном web-сервере информации является
наилучшим со следующих точек зрения:

ограничение доступа ПО web-сервера к подмножеству вычислительных ресурсов средствами
управления доступом ОС;

ограничение доступа пользователей посредством дополнительного управления доступом,
обеспечиваемым web-сервером, когда требуются более детальные уровни управления доступом.
Соответствующая установка управления доступом может помочь предотвратить
раскрытие чувствительной информации, которая не предназначена для публичного
распространения. Дополнительно управление доступом может быть использовано для
ограничения использования ресурсов в случае DoS-атаки на публичный web-сайт.
Обычно файлами, доступ к которым должен контролироваться, являются следующие:

ПО и конфигурационные файлы приложения.

Файлы, непосредственно использующиеся механизмами безопасности:
o
файлы хэшей паролей и другие файлы, используемые при аутентификации;
o
файлы, которые содержат авторизационную информацию, используемую при управлении
доступом;
o
криптографический материал ключа, используемый в сервисах конфиденциальности,
целостности и невозможности отказа.

Логи сервера и файлы системного аудита.

Системное ПО и его конфигурационные файлы.
Разграничение доступа для ПО web-сервера
Первый шаг в конфигурировании управления доступа состоит в гарантировании того, что
web-сервер выполняется только от имени пользователя и группы, которые специально
созданы для этого и имеют очень ограниченные права доступа. Таким образом, должны
быть введены специальные идентификаторы пользователя и группы, используемые
исключительно ПО web-сервера. Новый пользователь и новая группа должны быть
уникальными и независимыми от всех остальных пользователей и групп. Это необходимо
для реализации управления доступом, описанного далее. Хотя сервер может начинать
190
выполняться как root (Unix) или system/administrator (Windows NT/2000/XP) для привязки
к ТСР-порту 80 и/или 443 (используемому для предоставления НТТР и НТТРS-сервисов
соответственно), не следует допускать, чтобы сервер продолжал выполняться на данном
уровне доступа.
Дополнительно следует использовать возможности ОС для ограничения доступа к
файлам, доступным процессам web-сервера. Эти процессы должны иметь доступ только
по чтению к тем файлам, которые необходимы для выполнения сервиса, и не должны
иметь доступа к остальным файлам, таким как файлы лога сервера. Следует использовать
управление доступом на уровне ОС для обеспечения следующего:

процессы web-сервера должны быть сконфигурированы для выполнения от имени пользователя с
очень ограниченным множеством привилегий (т.е. не выполняться как root, администратор или
эквивалентные пользователи);

к файлам содержимого web-сайтов процессы web-сервера должны иметь доступ по чтению, но не по
записи;

процессы web-сервера не должны иметь возможность записи в директории, в которых хранится
публичное содержимое web-сайтов;

только процессы, авторизованные как администратор web-сервера, могут писать в файлы webсодержимого;

приложение web-сервера может писать в файлы логов web-сервера, но лог-файлы не могут читаться
приложением web-сервера. Только процессы уровня root/system/administrator могут читать логфайлы web-сервера;

временные файлы, создаваемые приложением web-сервера, например, те, которые возникают при
формировании динамических web-страниц, должны быть расположены в специальной и
соответствующим образом защищенной поддиректории;

доступ к любым временным файлам, созданным приложением web-сервера, ограничен процессами,
которые создали эти файлы.
Также необходимо гарантировать, что приложение web-сервера не может хранить файлы
вне специального подкаталога, выделенного для публичного web-содержимого. Это может
быть задано посредством конфигурации в ПО сервера или может контролироваться ОС.
Следует гарантировать, что к директориям и файлам вне специального поддерева
директорий не может быть обращений, даже если пользователи знают имена этих файлов.
Для уменьшения воздействия основных типов DoS-атак нужно сконфигурировать webсервер с ограниченным количеством ресурсов ОС, которые он может использовать. Чаще
всего необходимо совершить следующие действия:

инсталлировать содержимое web на отдельном жестком диске или логическом разделе от ОС и webприложения;

если допустимы загрузки (uploads) на web-сервер, установить ограничение на объем дискового
пространства, которое выделяется для этой цели;

если допустимы загрузки (uploads) на web-сервер, эти файлы не должны быть сразу же читаемы
web-сервером и, тем самым, видимы пользователям по протоколу НТТР. Они должны быть читаемы
web-сервером только после некоторого автоматизированного или ручного процесса просмотра. Это
191
предотвращает от использования web-сервера для передачи пиратского ПО, инструментальных
средств атак, порнографии и т.п.;

гарантировать, что лог-файлы хранятся в соответствующем месте, в котором они не смогут
исчерпать ресурсы файловой системы.
Эти действия в некоторой степени защитят от атак, которые попытаются заполнить
файловую систему информацией, что может вызвать крах системы. Они могут также
защитить против атак, которые пытаются заполнить RAM память ненужными процессами
для замедления или краха системы, тем самым ограничив доступность сервиса.
Информация в логах, созданных ОС, может помочь распознать такие атаки.
Дополнительно часто бывает необходимо сконфигурировать таймауты и другие способы
управления для дальнейшего уменьшения влияния основных DoS-атак. Один из типов
DoS-атаки состоит в том, чтобы одновременно устанавливать сетевые соединения сверх
максимально допустимого, чтобы никакой новый законный пользователь не мог получить
доступ. Когда таймауты установлены на сетевые соединения (время, после которого
неактивное соединение сбрасывается) в минимально допустимое ограничение,
существующие соединения будут завершаться по таймауту так быстро, как только
возможно, создавая возможность устанавливать новые соединения законным
пользователям. Данная мера только смягчает DoS-атаку, но не уничтожает ее.
Если максимальное число открытых соединений (или соединений, которые являются
полуоткрытыми, – это означает, что первая часть ТСР-рукопожатия завершилась
успешно) установить в наименьшее число, атакующий может легко израсходовать
доступные соединения ложными запросами (часто называемыми SYN flood). Установка в
максимум данного числа может смягчить эффект такой атаки, но ценой расходования
дополнительных ресурсов. Заметим, что это является проблемой только тех web-серверов,
которые не защищены firewall’ом, останавливающим SYN flood атаки. Большинство
современных firewall’ов защищают web-сервер от SYN flood атаки, прерывая ее прежде,
чем она достигнет web-сервера.
Управление доступом к директории содержимого web-сервера
Не следует использовать ссылки, aliases или shortcuts из дерева директории содержимого
web на директории или файлы, расположенные где-то еще на хосте или сетевой файловой
системе. Лучше всего запретить возможность ПО web-сервера следовать по ссылкам и
aliases. Как указывалось раньше, лог-файлы и конфигурационные файлы web-сервера
должны размещаться вне дерева директории, которое определено для публичного
содержимого web.
Для ограничения доступа к дереву директории содержимого web требуется выполнить
следующие шаги:

выделить отдельный жесткий диск или логический раздел для web-содержимого и использовать
поддиректории на данном жестком диске или логическом разделе исключительно для файлов
содержимого web-сервера, включая графику, но исключая скрипты и другие программы;

определить отдельную директорию исключительно для всех внешних по отношению к ПО webсервера скриптов или программ, выполняющихся как часть содержимого web (например, CGI, ASP,
PHP);
192

запретить выполнение скриптов, которые не находятся под исключительным контролем
административных аккаунтов. Данное действие выполняется созданием доступа и управлением им к
отдельной директории, предназначенной для хранения авторизованных скриптов;

запретить использование жестких и символических ссылок;

определить матрицу доступа к содержимому web. Определить, какие папки и файлы внутри
содержимого web-сервера имеют ограничения и какие являются доступными (и кому).
Большинство производителей ПО web-сервера предоставляют директивы или команды,
которые позволяют web-администратору ограничить доступ пользователя к файлам
содержимого web-сервера. Например, ПО web-сервера Apache предоставляет директиву
Limit, которая позволяет web-администратору указать, какие возможности доступа (такие
как New, Delete, Connect, Head и Get) связаны с каждым файлом web-содержимого.
Директива Require в Apache позволяет web-администратору ограничивать доступ к
содержимому аутентифицированными пользователями или группами.
Многие директивы или команды могут быть перекрыты на уровне директории. Но при
этом следует помнить, что удобство, состоящее в возможности делать локальные
исключения из глобальной политики, может привести к появлению дыры в безопасности,
появившейся в отдельной поддиректории, которая контролируется другим пользователем.
Web-администратор должен запретить для поддиректорий возможность перекрывать
директивы безопасности верхнего уровня, если это не является абсолютно необходимым.
В большинстве случаев подобные директивы web-сервера должны быть запрещены. НТТР
определяет, что URL, заканчивающийся символом слеша, должен трактоваться как запрос
на перечисление файлов в указанной директории. Web-сервер должен запрещать отвечать
на такие запросы, даже если возможно публичное чтение всех файлов директории. Такие
запросы часто указывают на попытку разместить информацию способами, отличными от
тех, которые допускает web-администратор. Пользователи могут пытаться это делать,
если у них возникают трудности в навигации по сайту или если ссылки в web-страницах
обрываются. Нарушитель может пытаться это сделать, чтобы разместить информацию,
скрытую интерфейсом сайта. Web-администраторы должны исследовать запросы данного
типа, найденные в лог-файлах web-сервера.
Управление влиянием web Bots
Web bots (что тоже самое, что и агенты или spiders) есть прикладное ПО, используемое
для сбора, анализа и индексирования web-содержимого. Web bots используются многими
организациями в разных целях. Некоторые примеры:

Scooter, Slurp и Googlebot анализируют, индексируют и записывают web-сайты для поисковых
систем, таких как AltaVista и Google;

ArchitextSpider собирает статистику Интернета;

Hyperlink validators используются для автоматической проверки корректности гиперссылок на
другие сайты;

EmailSiphon и Cherry Picker являются bots, специально разработанными для поиска на web-сайтах email адресов для добавления в e-mail списки ("спам"). Это пример bot, который имеет негативное
воздействие на web-сайты или их пользователей.
193
Bots имеют негативные последствия, потому что:

web-серверы часто содержат директории, которые не должны индексироваться;

организации могут не хотеть, чтобы часть их сайта появлялась в поисковых системах;

web-серверы часто содержат временные страницы, которые не должны индексироваться;

bots часто содержат ошибки или не всегда имеют хорошие намерения и могут нанести вред частыми
запросами, создавая DoS-атаку для законных пользователей.
В принципе, существует способ для web-администратора повлиять на поведение
большинства bots на своем web-сайте. Была создана серия соглашений, называемая Robots
Exclusion Standard (REP). Хотя REP не является официальным стандартом Интернета, он
поддерживается большинством хорошо написанных и имеющих благие цели bots, включая
те, которые используются в большинстве поисковых систем.
Web-администраторы, которые хотят ограничить деятельность bots на своих webсерверах, должны создать тестовый файл, называемый robots.txt. Файл должен всегда
иметь данное имя и располагаться в корневой директории web-сервера. Кроме того,
допускается только один такой файл на весь web-сайт. Заметим, что файл robots.txt
является стандартом, который на добровольной основе должен поддерживаться
программистами bots. Не существует обязательного требования использовать его. Таким
образом, вредоносные bots, такие как EmailSiphon и Cherry Picker, игнорируют данный
файл.
Robots.txt является простым тестовым файлом, который содержит определенные
ключевые слова и спецификации файла. Каждая строка файла либо является пустой, либо
состоит из единственного ключевого слова и относящейся к нему информации. Ключевые
слова используются для того, чтобы сказать роботам, какую часть web-сайта следует
исключить из их анализа.
Допустимы следующие ключевые слова:

User-agent – имя робота или spider. Web-администратор может указать более одного имени агента,
при этом действие будет применяться к каждому указанному bot. Запись нечувствительна к
регистру (слово "googlebot" – то же самое, что и "GoogleBot", "GOOGLEBOT"). "*" указывает, что
это запись по умолчанию, которая используется, если никакого соответствия не найдено. Например,
если указать "GoogleBot", то "*" будет применяться к любому другому роботу, за исключением
GoogleBot.

Disallow – говорит bots, какие разделы web-сайта следует исключить. Например, /images
информирует bots, что не следует открывать или индексировать любые файлы в директории images
и любых ее поддиректориях. Таким образом, директория /images/special также не будет
индексироваться указанными в user-agent bots.
Заметим, что /do будет соответствовать любой директории, начинающейся с "/do"
(например, /do, /document, /docs и т.п.), в то время как /do/ соответствует только
директории, называемой "/do/".
Web-администратор может также указать конкретные файлы. Например, он может указать
/mydata/help.html для предотвращения доступа только к одному файлу.
194
Значение "/" указывает, что ничего на web-сайте не разрешено для доступа указанных в
user-agent bots.
Должна существовать по крайней мере одна запись на каждый user-agent.
Существует много способов использовать файл robots.txt. Несколько простых примеров:












запретить всем (учитывающим это) bots доступ в указанные директории:
User-agent: *
Disallow: /images/
Disallow: /banners/
Disallow: /Forms/
Disallow: /Dictionary/
запретить всем (учитывающим это) bots доступ ко всему web-сайту:
User-agent: *
Disallow: /
запретить конкретному bot анализировать конкретную web-страницу:
User-agent: GoogleBot
Disallow: tempindex.html
Заметим, что файл robots.txt доступен всем. Следовательно, web-администратор не должен
указывать имена чувствительных файлов или папок. Если они должны быть исключены,
то лучше использовать защищенные паролем страницы, которые не могут быть доступны
bots. Защита паролем является более надежным способом для исключения не
придерживающихся правил bots. Более подробная информация будет приведена при
описании методов аутентификации.
Использование программ проверки целостности файлов
Программа проверки целостности файла является приложением, которое вычисляет и
хранит криптографическую контрольную сумму каждого защищаемого файла и
поддерживает базу данных контрольных сумм файлов. Это позволяет системному
администратору легко распознать изменения, в частности, неавторизованные, сделанные в
критичных файлах. Контрольные суммы должны перевычисляться регулярно для
сравнения текущего значения с хранимым значением, что позволит определить любые
модификации файла. Возможность проверки целостности файлов часто включается в
системы обнаружения проникновений для хоста, но такая проверка может быть доступна
и в виде отдельной программы.
Хотя программа проверки целостности и является полезным инструментальным
средством, которое не требует большого участия человека, для гарантии эффективности
она должна использоваться продуманно.
1.
При создании первого варианта базы данных файлом проверки целостности требуется гарантия, что
система находится в безопасном состоянии. В противном случае могут быть созданы
195
криптографические хэши скомпрометированной системы, и тем самым создастся ложное чувство
безопасности у тестирующего.
2.
База данные контрольных сумм должна храниться off-line, чтобы атакующий не мог
скомпрометировать систему и модифицировать базу данных с целью спрятать следы атаки.
3.
Программа проверки целостности файлов может также создавать ложные позитивные
предупреждения. Каждое изменение файла и каждый системный patch изменяет файл и,
следовательно, требуется изменить базу данных контрольных сумм. Таким образом, держать базу
данных актуальной может быть непросто.
Однако, даже если программа проверки целостности выполняется только один раз (при
первой инсталляции системы), она может быть полезна для определения того, какие
файлы были модифицированы в случае предполагаемой компрометации. Наконец,
атакующий может так модифицировать файл, что использование 32-битной циклической
контрольной суммы (Cyclic Redundancy Check – CRC) не определит модификацию.
Следовательно, рекомендуются более сильные алгоритмы подсчета контрольных сумм
для гарантирования целостности данных.
Программы проверки целостности должны выполняться ночью для проверки некоторой
файловой системы, которая могла быть скомпрометирована. Если программа проверки
целостности определит неавторизованные модификации системных файлов, должна быть
рассмотрена возможность инцидента, связанного с безопасностью, и осуществлены
соответствующие процедуры, согласно установленной политики безопасности.
Список действий для безопасного инсталлирования и конфигурирования
web-сервера
Безопасное инсталлирование web-сервера.

Инсталлировать ПО сервера на выделенный хост.

Инсталлировать минимально требуемые сервисы Интернета.

Применить все patches и upgrades для устранения известных уязвимостей.

Создать выделенный физический диск или логический раздел (отдельно от ОС и приложения
сервера) для web-содержимого.

Удалить или запретить все сервисы, инсталлированные приложением web-сервера, но в данном
случае не требуемые (например, gopher, FTP и удаленное администрирование).

Удалить все примеры страниц, скриптов и выполняемого кода.

Удалить с сервера всю документацию производителя.

Протестировать сервер, применив различные образцы безопасности или скрипты взлома.

Переконфигурировать баннер НТТР-сервиса (и баннеры других сервисов, если требуется), чтобы он
не сообщал о типе и версии web-сервера и ОС.
Конфигурирование управления доступом web-сервера со стороны ОС.

Сконфигурировать доступ к файлам со стороны ОС так, чтобы процессы web-сервера могли только
читать файлы web-содержимого, но не могли записывать в них.
196

Сконфигурировать доступ к файлам со стороны ОС так, чтобы процессы web-сервера не могли
записывать в директории, в которых расположено содержимое web.

Сконфигурировать доступ к файлам со стороны ОС так, чтобы только процессы, авторизованные
для администрирования web-сервера, могли записывать в файлы содержимого web.

– Сконфигурировать доступ к файлам со стороны ОС так, чтобы web-приложение могло писать в
лог-файлы web-сервера, но лог-файлы не могли быть читаемы приложением web-сервера.

Сконфигурировать доступ к файлам со стороны ОС так, чтобы временные файлы, создаваемые
приложением web-сервера, были расположены только в указанной и соответствующим образом
защищенной поддиректории.

Сконфигурировать доступ к файлам со стороны ОС так, чтобы доступ к любым временным файлам,
созданным приложением web-сервера, был ограничен только процессами, которые создали эти
файлы.

Инсталлировать web-содержимое на отдельном жестком диске или логическом разделе, отличном
от ОС и web-приложения.

Сконфигурировать доступ к файлам со стороны ОС так, что если допустима загрузка на web-сервер,
то должно существовать ограничение на пространство жесткого диска или логического раздела,
которое выделено для этих целей.

Сконфигурировать доступ к файлам со стороны ОС так, чтобы лог-файлы имели соответствующий
максимальный размер.
Конфигурирование безопасной директории web-содержимого.

Выделить отдельный жесткий диск или логический раздел для web-содержимого и установить
соответствующие поддиректории исключительно для файлов содержимого web-сервера, включая
графику, но исключая скрипты и другие программы.

Определить отдельную директорию исключительно для всех внешних по отношению к ПО webсервера скриптов или программ, выполняющихся как часть содержимого web-серверанапример,
CGI, ASP и т.п.).

Запретить выполнение скриптов, которые не находятся под управлением административных
аккаунтов. Данное действие выполняется созданием доступа и управлением им к отдельной
директории, которая предназначена для авторизованных скриптов.

Создать группы и пользователей для web-сервера.

Запретить использование жестких и символических ссылок (аналог shortcuts в Windows).

Определить полную матрицу доступа к web-содержимому. Определить, какие папки и файлы
внутри документов web-сервера имеют ограничения и какие являются доступными (и кому).

Проверить политику паролей в организации и установить соответствующие критерии паролей
(длина, сложность).

Использовать при необходимости файл robots.txt.
Использование программ проверки целостности.

Инсталлировать проверку целостности для защиты конфигурационных файлов web-сервера.

Пересчитывать контрольные суммы при изменении содержимого файлов.
197

Хранить контрольные суммы в защищенном от записи носителе.

Регулярно сравнивать контрольные суммы критичных файлов с эталонными значениями.
11.Логика высказываний. Логические связки, высказывательные формы,
полные системы связок. Логические эквивалентности. Дизъюнктивная
нормальная форма. Булевы функции. Таблицы истинности.
Булевы функции от n переменных
Булевы функции1)названы в честь английского математика ХIХ века Дж. Буля, который
впервые применил алгебраические методы для решения логических задач. Они образуют
самый простой нетривиальный класс дискретных функций - их аргументы и значения
могут принимать всего два значения (если мощность множества значений функции равна
1, то это тривиальная функция - константа !). С другой стороны, этот класс достаточно
богат и его функции имеют много интересных свойств. Булевы функции находят
применение в логике, электротехнике, многих разделах информатики.
Обозначим через B двухэлементное множество {0,1}. Тогда
это множество всех двоичных последовательностей (наборов, векторов) длины n. Булевой функцией от n
переменных (аргументов) называется любая функция f(x1, xn): Bn B . Каждый из ее аргументов xi, 1 i n ,
может принимать одно из двух значений 0 или 1 и значением функции на любом наборе из Bn также может
быть 0 или 1. Обозначим через
подсчитать их число.
множество всех булевых функций от n переменных. Нетрудно
Теорема 3.1.
198
Доказательство.Действительно, по теореме 1.1 число функций из k-элементного
множества A в m-элементное множество B равно mk . В нашем случае B={0, 1}, а A = Bn .
Тогда m=2 и k= |Bn| = 2n . Отсюда следует утверждение теоремы.
Имеется несколько различных способов представления и интерпретации булевых
функций. В этом разделе мы рассмотрим геометрическое и табличное представления, а
также представление с помощью логических формул. В лекции 4 будет показано, как
булевы функции можно представлять с помощью формул специального вида дизъюнктивных и конъюнктивных нормальных форм и многочленов Жегалкина. Кроме
того, в лекциях 1 и 2 (курс "Введение в схемы, автоматы и алгоритмы") будет рассмотрено
еще два способа представления булевых функций: логические схемы и упорядоченные
бинарные диаграммы решений.
Геометрическое представление
Bn можно рассматривать как единичный n-мерный куб. Каждый набор из нулей и единиц
длины n задает вершину этого куба. На рис. 3.1 представлены единичные кубы Bn при
n=3,4.
Рис. 3.1.
При этом существует естественное взимнооднозначное соответствие между
подмножествами вершин n-мерных единичных кубов и булевыми функциями от n
переменных: подмножеству A Bn соответствует его характеристическая функция
Например, верхней грани куба B3 (ее вершины выделены на рисунке) соответствует
функция f: f(0,0,1)=f(0,1,1)=f(1,0,1)=f(1,1,1) =1 и f(0,0,0)=f(0,1,0)=f(1,0,0)=f(1,1,0) =0.
Очевидно, что указанное соответствие действительно взаимнооднозначное: каждая
199
булевая функция f от n переменных задает подмножество Af={(x1, …, xn)|f(x1, …, xn)=1}
вершин Bn . Например, функция, тождественно равная 0, задает пустое множество Bn , а
функция, тождественно равная 1, задает множество всех вершин Bn .
Табличное представление
Булевы функции от небольшого числа аргументов удобно представлять с помощью
таблиц. Таблица для функции f(x1, …, xn) имеет n+1 столбец. В первых n столбцах
указываются значения аргументов x1, …, xn , а в (n+1)-ом столбце значение функции на
этих аргументах - f(x1, …, xn) .
Таблица 3.1. Табличное представление функции f(x1, …, xn)
x1
.
.
.
xn-1
f(x1, …, xn)
xn
0
.
.
.
0
0
f(0, …, 0,0)
0
.
.
.
0
1
f(0, …, 0,1)
0
.
.
.
1
0
f(0, …, 1,0)
.
.
.
.
.
.
…
1
.
.
.
1
1
f(1, …, 1,1)
Наборы аргументов в строках обычно располагаются в лексикографическом порядке:
( 1, …,
n)
< (β1, …, βn)
существует такое i [1,n], что при j < i
j
= βj , а
i
< βi .
Если эти наборы рассматривать как записи чисел в двоичной системе счисления, то 1-ая
строка представляет число 0, 2-ая - 1, 3-я - 2, … , а последняя - 2n-1 .
При больших n табличное представление становится громоздким, например, для функции
от 10 переменных потребуется таблица с 1024 строками. Но для малых n оно достаточно
наглядно.
Булевы функции от 1-ой и 2-х переменных
Представим вначале в табличном виде все булевы функции от 1-ой переменной. Как мы
знаем, их всего четыре.
Таблица 3.2. Булевы функции от 1-ой переменной
x1
f1
f2
f3
f4
0
0
1
0
1
1
0
1
1
0
В этой таблице представлены следующие функции:
1.
f1(x1)= 0 - константа 0;
2.
f2(x1)= 1 - константа 1;
3.
f3(x1)= x1 - тождественная функция;
4.
f4(x1)= ¬ x1 - отрицание x1 (используется также обозначение x 1 , а в языках программирования эта
функция часто обозначается как NOTx1 ).
В следующей таблице представлены все 16 функций от 2-х переменных.
200
Таблица 3.3. Булевы функции от 2-х переменных
x1 x2 f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 f11 f12 f13 f14 f15 f16
0 0 0 1 0 1 0 1 0 0 1 0 1 1 1 0 0 1
0 1 0 1 0 1 1 0 0 1 1 1 0 1 0 1 0 0
1 0 0 1 1 0 0 1 0 1 0 1 0 1 0 0 1 1
1 1 0 1 1 0 1 0 1 1 1 0 1 0 0 0 0 1
Многие из этих функций часто используются в качестве "элементарных" и имеют
собственные обозначения.
1.
f1(x1,x2)= 0 - константа 0;
2.
f2(x1,x2)= 1 - константа 1;
3.
f3(x1,x2)= x1 - функция, равная 1-му аргументу ;
4.
f4(x1,x2)= ¬ x1 - отрицание x1 ;
5.
f5(x1,x2)= x2 - функция, равная 2-му аргументу ;
6.
f6(x1,x2)= ¬ x2 - отрицание x2 ;
7.
f7(x1,x2)= (x1 x2) - конъюнкция, читается " x1 и x2 " (используются также обозначения (x1 & x2) ,
(x1x2) , min(x1,x2) и (x1 AND x2) );
8.
f8(x1,x2)= (x1 x2) - дизъюнкция, читается " x1 или x2 " (используются также обозначения (x1 x2) , (x1
+ x2) , max(x1,x2) и (x1 OR x2) );
9.
f9(x1,x2)= (x1
x2) - импликация, читается "x_1 влечет x_2" или "из x1 следует x2 " (используются
также обозначения ( x1
x2 ), и ( IF x1 THEN x2 ));
10. f10(x1,x2)= (x1 + x2) - сложение по модулю 2, читается " x1 плюс x2 " (используется также обозначение
(x1 x2) );
11. f11(x1,x2)= (x1 ~ x2) - эквивалентность, читается " x1 эквивалентно (равносильно) x2 " (используется
также обозначение (x1 x2) );
12. f12(x1,x2)= (x1 | x2) - штрих Шеффера (антиконъюнкция), иногда читается как "не x1 и x2 ";
13. f13(x1,x2)= (x1 x2) - стрелка Пирса (антидизъюнкция), иногда читается как "не x1 или x2 ".
В качестве элементарных функций будем также рассматривать 0-местные функцииконстанты 0 и 1.
Отметим, что функции f1(x1,x2) и f2(x1,x2) фактически не зависят от значений обоих
аргументов, функции f3(x1,x2) и f4(x1,x2) не зависят от значений аргумента x2, а функции
f5(x1,x2) и f6(x1,x2) не зависят от значений аргумента x1.
Определение 3.1. Функция f(x1,…, xi,…, xn) не зависит от аргумента xi, если для любого
набора значений σ1,…,σi-1>, σi+1,…, σn остальных аргументов f имеет место равенство
201
Такой аргумент xi называется фиктивным. Аргументы, не являющиеся фиктивными,
называются существенными.
Функции f1(x1,…, xn) и f2(x1,…,xm) называются равными, если функцию f2 можно получить
из функции f1 путем добавления и удаления фиктивных аргументов.
Например, равными являются одноместная функция f3(x1) и двухместная функция f3(x1,x2)
, так как вторая получается из первой добавлением фиктивного аргумента x2 . Мы не
будем различать равные функции и, как правило, будем использовать для обозначения
равных функций одно и то же имя функции. В частности, это позволяет считать, что во
всяком конечном множестве функций все функции зависят от одного и того же множества
переменных.
Формулы
Как мы видели, геометрическое и табличное представления булевых функций подходят
лишь для функций с небольшим числом аргументов. Формулы позволяют удобно
представлять многие функции от большего числа аргументов и оперировать различными
представлениями одной и той же функции.
Пусть
- некоторое (конечное или бесконечное) множество булевых функций.
Зафиксируем некоторое счетное множество переменных V={X1, X2, …} . Определим по
индукции множество формул над
с переменными из V. Одновременно будем
определять числовую характеристику dep(Φ) формулы Φ, называемую ее глубиной, и
множество ее подформул.
Определение 3.2.
1.
Базис индукции. Каждая переменная Xi V и каждая константа c
является формулой глубины
0, т.е. dep(Xi)= dep(c)=0 . Множество ее подформул состоит из нее самой.
2.
Шаг индукции. Пусть
и A1, … , Am - формулы, и max {dep(Ai) | i = 1,…,
m} = k . Тогда выражение Φ = f(A1,… , Am) является формулой, ее глубина dep(Φ) равна k+1, а
множество подформул Φ включает саму формулу Φ и все подформулы формул A1, …, Am.
Каждой формуле Φ(X1,…, Xn) сопоставим булеву функцию, которую эта формула задает,
используя индукцию по глубине формулы.
Базис индукции. Пусть dep(Φ)=0. Тогда Φ = Xi V или Φ =c
. В первом случае Φ задает
функцию fΦ(Xi)=Xi, во втором - функцию, тождественно равную константе c.
Шаг индукции. Пусть Φ - произвольная формула глубины dep(Φ)= k+1. Тогда Φ(X1,…,
Xn)= fi(A1,…, A_m) , где fi
и A1, …, Am - формулы, для которых max1 i m{dep(Ai)}=k .
Предположим (по индукции), что этим формулам уже сопоставлены функции g1(X1,…,
Xn), … , gm(X1,…, Xn) . Тогда формула Φ задает функцию fΦ(X1,…, Xn) = fi(g1(X1,…, Xn), …
, gm(X1,…, Xn)) .
Далее мы будем рассматривать формулы над множеством элементарных функций
. Все эти функции, кроме констант, называются
логическими связками или логическими операциями. При этом для 2-местных функций из
202
этого списка будем использовать инфиксную запись, в которой имя логической связки
помещается между 1-ым и 2-ым аргументами. Тогда определение формулы над
имеет
следующий вид.
Определение 3.3.

Базис индукции. 0, 1 и каждая переменная Xi V являются формулами глубины 0.

Шаг индукции. Пусть Φ1 и Φ2 - формулы, ˆ { , ,
, +, ~, |, }.
Тогда выражения ¬ Φ1 и (Φ1 ˆ Φ2) являются формулами. При этом dep(¬ Φ1)=1 + dep( Φ1) ,
а dep((Φ1 ˆ Φ2))= 1 + max {dep(Φ1), dep(Φ2)} .
В соответствии с этим определением выражения Φ1(X1,X2) = ¬ (X1 ¬ X2) и Φ2(X1,X2,X3) =
( (X1 ¬ ¬ X2) (X3 ~ (X1 ¬ X2))) являются формулами. Глубина Φ1 равна 3, а глубина Φ2
равна 4. Выражения же ¬ X1 +( ¬ X2 X3) , (X1 ¬ X2) и (X1 + X2 + X3) формулами не
являются (почему?).
Для определения функции, задаваемой формулой, удобно использовать таблицу, строки
которой сответствуют наборам значений переменных, а в столбце под знаком каждой
логической связки стоят значения функции, задаваемой соответствующей подформулой.
Например, для формулы Φ2 функция fΦ2 задается выделенным столбцом следующей
таблицы.
Таблица 3.4. Функция f Φ2
X1 X2 X3 ((X1
¬ ¬ X2)
(X3 ~ (X1
¬ X2)))
0 0 0 0
0 0 1 0
1 0
10
0 1 0
0 0 1 0
0 0 1 0
1 1
00
0 0 1
0 1 0 0
1 1 0 1
0 0
00
1 0 1
0 1 1 0
1 1 0 1
1 1
10
1 0 1
1 0 0 1
1 0 1 0
1 0
11
0 1 0
1 0 1 1
1 0 1 0
0 1
01
0 1 0
1 1 0 1
1 1 0 1
1 0
11
0 0 1
1 1 1 1
1 1 0 1
0 1
01
0 0 1
Булевы функции и логика высказываний
Как мы уже отметили, Дж. Буль ввел булевы функции для решения логических задач. В
логике под высказыванием понимают некоторое повествовательное предложение,
относительно которого можно сказать, истинно оно или ложно. Логика высказываний
занимается выяснением истинности тех или иных высказываний, связью между
истинностью различных высказываний и т.п.
Булевы функции могут служить полезным инструментом при решении многих логических
задач.
Каждую переменную можно рассматривать как некоторое элементарное высказывание,
принимающее одно из двух значений: 1 (истина) или 0 (ложь). Сложным высказываниям
сооответствуют формулы, построенные из элементарных высказываний с помощью
203
логических связок. Вычисляя значения задаваемых ими функций, можно устанавливать
зависимости истинностных значений сложных высказываний от значений входящих в них
элементарных высказываний. Рассмотрим следующий пример.
Пример 3.1.Пусть известно, что в дорожном проишествии участвовали три автомобиля с
водителями A, B и C. Свидетели проишествия дали следующие показания:

1-ый свидетель: если A виновен, то из остальных B и C хоть один не виновен;

2-ой свидетель: если C не виновен, то виновен кто-то один из пары A, B но не оба вместе;

3-ий свидетель: в столкновении виновны не менее двух водителей.
Опишите показания свидетелей в виде булевых формул и постройте таблицу значений их
конъюнкции. Можно ли на основании этих показаний сделать вывод, что C является
виновником проишествия? Можно ли однозначно определить второго виновника?
Для ответа на эти вопросы введем три переменные, соответствующие следующим
высказываниям: X1 : " виновен A ", X2 : " виновен B " и X3 : " виновен C ". Тогда
показания 1-го свидетеля описываются формулой Φ1=(X1 (¬X2 ¬X3)) , показания 2-го
свидетеля - Φ2= (¬ X3 (( X1 X2) ¬(X1 X2))), а 3-го свидетеля - Φ3= ((X1 X2)\vee ((X1
X3) ( X2 X3))) . Показаниям всех трех свидетелей соответствует конъюнкция этих
формул Ψ= (Φ1 (Φ2 Φ3)) . Составим таблицы значений для функций fΦi (i=1,2,3) , а затем
- для fΨ.
Таблица 3.5. Функция fΦ1
X1 X2 X3 (X1
(¬ X2
¬ X3))
0
0
0
0
1
1 0
1 1 0
0
0
1
0
1
1 0
1 0 1
0
1
0
0
1
0 1
1 1 0
0
1
1
0
1
0 1
0 0 1
1
0
0
1
1
1 0
1 1 0
1
0
1
1
1
1 0
1 0 1
1
1
0
1
1
0 1
1 1 0
1
1
0
1
1
0 1
1 1 0
1
1
1
1
0
0 1
0 0 1
Таблица 3.6. Функция f Φ2
X1 X2 X3 (¬ X3
(( X1
X2)
¬ (X1
X2)))
0
0
0
1
0 0
0
0 0
0 1 0
0 0
0
0
1
0
1 1
0
0 0
0 1 0
0 0
0
1
0
1
0 1
0
1 1
1 1 0
0 1
0
1
1
0
1 1
0
1 1
1 1 0
0 1
1
0
0
1
0 1
1
1 0
1 1 1
0 0
\1 0
1
0
1 1
1
1 0
1 1 1
0 0
1
1
0
1
0 0
1
1 1
0 0 1
1 1
1
1
1
0
1 1
1
1 1
0 0 1
1 1
Таблица 3.7. Функция f Φ3
204
X1 X2 X3 ((X1
X2)
((X1
X3)
( X2
X3)))
0 0 0 0
0 0
0 0
0 0
0 0
0 0
0 0 1 0
0 0
0 0
0 1
0 0
0 1
0 1 0 0
0 1
0 0
0 0
0 1
0 0
0 1 1 0
0 1
1 0
0 1
1 1
1 1
1 0 0 1
0 0
0 1
0 0
0 0
0 0
1 0 1 1
0 0
1 1
1 1
1 0
0 1
1 1 0 1
1 1
1 1
0 0
0 1
0 0
1 1 1 1
1 1
1 1
1 1
1 1
1 1
Таблица 3.8. Функция f Ψ
X1 X2 X3 (\Phi1
(\Phi2
\Phi3))
0 0 0 1
0 0
0
0
0 0 1 1
0 1
0
0
0 1 0 1
0 1
0
0
0 1 1 1
1 1
1
1
1 0 0 1
0 1
0
0
1 0 1 1
1 1
1
1
1 1 0 1
0 0
0
1
1 1 1 0
0 1
1
1
Из этой таблицы следует, что fΨ(X1,X2,X3)=1 на двух наборах: (X1=0, X2=1, X3=1) и (X1=1,
X2=0, X3=1) (строки с этими наборами подчеркнуты). Поскольку в обоих случаях X3=1 ,
можно сделать вывод, что С является одним из виновников проишествия. Однозначно
определить второго виновника полученная от свидетелей информация не позволяет, так
как в одном случае им является А, а в другом - В.
Важную роль в логике играют понятия тождественно истинной и выполнимой формулы.
Определение
Булева формула Φ называется тождественно истинной, если она истинна при любых
значениях входящих в нее переменных, т.е. функция fΦ тождественно равна 1.
Булева формула Φ называется выполнимой, если существует такой набор значений
переменных, на котором она истинна, т.е. функция fΦ равна 1 хоть на одном наборе
аргументов.
Как проверить тождественную истинность или выполнимость формулы Φ? На первый
взгляд кажется, что ответ прост - построим по Φ таблицу для функции fΦ , и, если в
столбце значений стоят только единицы, то заключаем, что Φ тождественно истинна, если
там есть хоть одна единица, то Φ выполнима. К сожалению, этот способ пригоден только
для формул с небольшим числом переменных. Уже для нескольких десятков и сотен
переменных он не годится из-за большого размера получающейся таблицы - нетрудно
подсчитать, что число 290 превосходит количество атомов во всей видимой вселенной.
В математической логике построены аксиоматические системы, позволяющие
формализовать человеческие рассуждения о выводимости одних тождественно истинных
формул из других (см., например, [15]). В некоторых случаях они позволяют доказать
205
тождественную истинность достаточно длинных формул, имеющих регулярную
структуру. Но в общем случае и они практически не применимы для произвольных
формул с большим числом переменных.
В теории сложности алгоритмов имеется ряд результатов (они выходят за рамки нашего
курса), которые свидетельствуют о том, что эффективных алгоритмов для проверки
выполнимости или тождественной истинности произвольной булевой формулы не
существует. Вместе с тем для некоторых подклассов формул эти задачи решаются
достаточно эффективно. Один такой подкласс - Хорновские формулы - будет рассмотрен
далее в лекции 6
Эквивалентность булевых формул
Определение 4.1. Булевы формулы Φ и Ψ называются эквивалентными, если
соответствующие им функции fΦ и fΨ равны.
Обозначение: Φ Ψ. Эквивалентные формулы называют также тождественно равными, а
выражения вида Φ Ψ логическими тождествами .
Основные эквивалентности (тождества)
Таким образом, эквивалентные формулы являются различными заданиями одной и той же
булевой функции. Ниже мы приводим ряд пар эквивалентных формул (тождеств),
отражающих существенные свойства логических операций и важные соотношения между
различными операциями. Они часто позволяют находить для булевых функций по одним
задающим их формулам более простые формулы. Большинство из приводимых тождеств
имеют собственные имена. Часто их называют законами логики.
Пусть ˆ - это одна из функций , , +. Для этих трех функций выполнены следующие две
эквивалентности (законы ассоциативности и коммутативности).
1.
Ассоциативность:
(1)
2.
Коммутативность:
(2)
3.
Дистрибутивные законы:
(3)
4.
Двойное отрицание:
(4)
5.
Законы де Моргана (внесение отрицания внутрь скобок):
206
(5)
6.
Законы упрощения:
(6)
Некоторые законы упрощения имеют собственные названия: эквивалентности в первой
строке называются законами идемпотентности,
- это закон противоречия,
- это закон исключенного третьего. Эквивалентности в двух последних
строках иногда называют законами 0 и 1.
Следующие две эквивалентности позволяют выразить импликацию и сложение по модулю
2 через дизъюнкцию, конъюнкцию и отрицание.
(7)
(8)
Проверку правильности этих эквивалентностей оставляем читателям (см. задачу 4.1).
Эквивалентные преобразования формул
Соглашения об упрощенной записи формул.
1.
Законы ассоциативности показывают, что значения формул, составленных из переменных и одних
операций конъюнкции, не зависят от расстановки скобок. Поэтому вместо формул ((X1 X2) X3) и
(X1 (X2 X3)) мы будем для упрощения писать выражение (X1 X2 X3) , которое не является
формулой, но может быть превращено в нее с помощью расстановки скобок. Аналогично, будем
использовать выражения (X1 X2 X3) и (X1 + X2 + X3) для сокращения формул, состоящих из
одних дизъюнкций или одних сложений по модулю 2, соответственно.
2.
Если внешней функцией в формуле является одна из функций , , +,
записи формулы можно опустить.
, то внешние скобки в
Таким образом, с использованием этих соглашений формула
может быть записана как
Из определения эквивалентности формул непосредственно следует Принцип замены
эквивалентных подформул:
пусть формула является подформулой формулы Φ, формула ' эквивалентна и формула
Φ' получена из Φ посредством замены некоторого вхождения на '. Тогда Φ'
эквивалентна Φ, т.е. Φ' Φ.
207
Применяя этот принцип и используя основные тождества, можно находить для заданной
формулы другие эквивалентные ей формулы. Часто это может приводить к
существенному упрощению исходной формулы. Например, если в формуле ((X 0) Y)
заменим на основании тождеств (6) подформулу (X 0) на 0, то получим эквивалентную
формулу (0 Y). По закону коммутативности (2) эта формула эквивалентна формуле (Y
0), которая, в свою очередь, по одному из тождеств группы (6) эквивалентна формуле Y.
Эту цепочку эквивалентных преобразований можно записать также следующим образом:
В этой цепочке вспомогательные номера под знаками эквивалентности указывают, с
помощью какой группы основных тождеств эта эквивалентность получается.
Выведем еще несколько важных логических тождеств, позволяющих проводить
упрощения сложных формул. Их называют законами поглощения.
1.
(П1)
2. Действительно,
3.
4.
(П2)
5.
Действительно,
6.
7.
(П3)
8.
Действительно,
9.
208
Дизъюнктивные и конъюнктивные нормальные формы
Определение ДНФ и КНФ
В этом разделе мы интересуемся представлением произвольной булевой функции
посредством формул специального вида, использующих только операции , и ¬.
Пусть
- это множество пропозициональных переменных. Введем
для каждого i=1,...,n обозначения:
и
. Формула
, в которой
переменные разные, т.е.
(элементарной дизъюнкцией).
при
и все
, называется элементарной конъюнкцией
Определение 4.2. Формула
называется дизъюнктивной нормальной формой (ДНФ),
если она является дизъюнкцией элементарных конъюнкций, т.е. имеет вид
где каждая формула
- это элементарная
конъюнкция. называется совершенной ДНФ, если в каждую из ее конъюнкций
входят все переменных из
Аналогично, формула называется конъюнктивной
нормальной формой (КНФ), если она является конъюнкцией элементарных дизъюнкций,
т.е.
, где каждая формула Dj (j=1,...,r) - это элементарная
дизъюнкция. Она является совершенной КНФ, если в каждую Dj входят все n переменных
из
Совершенные ДНФ и КНФ
Рассмотрим произвольную булеву функцию f(X1,…,Xn) , зависящую от переменных из .
Oбозначим через Nf+ множество наборов значений переменных, на которых f принимает
значение 1, а через Nf- множество наборов, на которых f принимает значение 0, т.е.
и
Определим по этим множествам две формулы:
и
Теорема 4.1.
1.
Если функция f не равна тождественно 0, то формула
функцию f.
209
- это совершенная ДНФ, задающая
2.
Если функция f не равна тождественно 1, то формула
функцию f.
- это совершенная КНФ, задающая
Доказательство получается непосредственным вычислением значения каждой из
указанных формул с учетом того, что для любого σ {0, 1} имеют место равенства: 1σ = σ
и 0σ = ¬σ (см. задачу 4.4).
Следствие 4.1.1. Каждая булева функция может быть задана формулой, содержащей
переменные и функции конъюнкции, дизъюнкции и отрицания.
Приведенные выше формулы для
и
позволяют эффективно строить совершенные
ДНФ и КН по табличному представлению функции f (Каким образом?). Можно ли
получить такие специальные представления по произвольной формуле, задающей f, не
выписывая ее полной таблицы? Приводимая ниже процедура позволяет это сделать,
используя основные эквивалентности формул.
Процедура Приведение к совершенной ДНФ
Вход: формула Φ, включающая функции ¬, , ,
и +.
1.
Используя эквивалентность (7), заменить все вхождения функции в Φ на ¬, и , затем
использовать эквивалентность (8) для замены всех вхождений функции + на ¬, и .
2.
Используя законы де Моргана (5) и снятия двойного отрицания(4), внести все знаки отрицания
внутрь скобок так, чтобы все оставшиеся отрицания находились непосредственно перед
переменными.
3.
Получившаяся после шага (2) формула
o
или
o
.
имеет одну из двух форм:
Поскольку каждая из формул Φ1 , Φ2 имеет меньшую глубину, чем формула Φ', то
предположим по индукции, что для них уже построены эквивалентные ДНФ
и
, соответственно.
Тогда в случае (а) имеем:
Каждый член
этой дизъюнкции представляет собой конъюнкцию
переменных и их отрицаний. Применяя эквивалентности групп (1), (2) и (6), можно
удалить из нее повторения переменных, после чего она превратится в некоторую
элементарную конъюнкцию или константу. Проделав такие преобразования со
всеми парами (i,j), 1 i r, 1 j s, и удалив, если потребуется, константы 0, мы
получим ДНФ, эквивалентную исходной формуле Φ.
210
В случае (б) формула
сама уже является ДНФ.
4.
Используя эквивалентности групп (1), (2) и (6), удалить из получившейся после шага (3) формулы
повторные вхождения одинаковых конъюнкций.
5.
Пусть после шага (4) получилась ДНФ
. Чтобы получить
эквивалентную совершенную ДНФ, построим для каждой Ki (i=1,…, m) , эквивалентную
совершенную ДНФ (см. задачу 4.5),заменим ею Ki , а затем устраним повторения одинаковых
конъюнкций.
Из формулировок эквивалентностей (7) и (8) непосредственно вытекает
Предложение 4.1. На этапе (1) процедуры при последовательном выполнении
преобразований (7), а затем - (8), до тех пор, пока ни одно из них не применимо,
полученная в результате формула не будет содержать функций и +.
Доказательство этого предложения оставляем в виде упражнения (см. задачу 4.7).
Следующее утверждение гарантирует корректность этапа (2).
Предложение 4.2. На этапе (2) процедуры при любом порядке выполнения
преобразований групп (4) и (5) до тех пор, пока ни одно из них не применимо, в
полученной в результате формуле все знаки отрицания будут стоять непосредственно
перед переменными.
Перед доказательством этого утверждения введем некоторые обозначения. Напомним, что
в определениях 3.2 и 3.3 для каждой формулы Φ была определена ее глубина dep(Φ).
Например, формула Φ=¬(X+Y) (¬(X ¬ Z) Y), построенная над системой F={ , , ¬, ,
+}, имеет глубину dep(Φ)=5.
Пусть Φ - это формула над F={ , , ¬}. Определим для каждой ее "отрицательной"
подформулы вида ¬(Ψ) высоту h(¬(Ψ)) как 3dep(Ψ)-1 . И пусть высота всей формулы H(Φ)
равна сумме высот всех ее отрицательных подформул. Например, для приведенной выше
формулы Φ ее высота равна H(Φ)= h(¬(X+Y)) +h(¬(X ¬ Z))+ h(¬ Z) = (31-1) + (32-1) +(301) = 10.
Доказательство предложения 4.2 проведем индукцией по высоте формул.
Базис индукции. Если H(Φ)=0, то либо в Φ нет отрицаний, либо все отрицания находятся
непосредственно перед переменными. Следовательно, Φ удовлетворяет требованию
предложения 4.2.
Шаг индукции. Предположим, что при n k для всех формул высоты n Предложение 4.2
выполнено. Пусть Φ - произвольная формула высоты H(Φ)= k+1. Докажем наше
утверждение для нее. Поскольку H(Φ) 1, то Φ содержит хотя бы одну отрицательную
подформулу ¬(Ψ), у которой h(¬(Ψ)) 1 и, следовательно, dep(Ψ) 1. К такой формуле
обязательно можно применить либо снятие двойного отрицания (4), либо один из законов
де Моргана (5). (Объясните почему.) Пусть ¬(Ψ) - это та подформула Φ, которая на (2)-ом
этапе процедуры первой заменяется на эквивалентную формулу Ψ' в соответствии с одной
211
из указанных эквивалентностей. Пусть Φ' - это формула, получившаяся в результате этой
замены из Φ. Нетрудно проверить (проделайте эту проверку!), что при любом из
преобразований (4), (5) H(Ψ') < H(¬(Ψ)) и, следовательно, H(Φ') < H(Φ). Тогда H(Φ') k и
по предположению индукции применение эквивалентностей (4), (5) в произвольном
порядке приведет в конце концов к формуле, у которой все отрицания будут стоять
непосредственно перед переменными. Тем самым, предложение 4.2 выполнено при n=k+1,
что завершает индукционный шаг и все доказательство.
Рассмотрим применение процедуры приведения к совершенной ДНФ на примере.
Пример 4.1. Пусть формула
.
На (1)-ом этапе процедуры получаем следующую цепочку эквивалентностей:
На (2)-ом этапе вносим отрицание внутрь первой скобки и получаем формулу
Устранив двойное отрицание, получим
Нетрудно видеть, что это уже ДНФ. Удалим на (4)-ом этапе повторное вхождение первой
конънкции и получим ДНФ
Эта ДНФ не является совершенной, так как в каждую из ее трех конъюнкций входят не
все переменные. Построим на этапе (5) для них эквивалентные совершенные ДНФ
(используя решение задачи 4.5).
Подставив эти формулы в Φ1 и устранив повторения конъюнкций, получим совершенную
ДНФ, эквивалентную исходной формуле Φ:
Мы видим, что ДНФ Φ1 , полученная после 4-го этапа, выглядит существенно проще, т.е.
является более короткой, чем совершенная ДНФ Φ2 . Однако совершенные ДНФ и КНФ
обладают важным свойством единственности, которое следует из их конструкции в
теореме 4.1.
Следствие 4.1.2. Для каждой булевой функции от n переменных, не равной тождественно
0, существует единственная с точностью до перестановки конъюнкций и переменных
внутри конъюнкций совершенная ДНФ, задающая эту функцию.
212
Это следствие позволяет предложить следующую процедуру для проверки
эквивалентности формул Φ и Ψ.
1.
Построить для Φ и Ψ эквивалентные совершенные ДНФ Φ' и Ψ' используя процедуру приведения к
совершенной ДНФ.
2.
Упорядочить в соответствии с нумерацией переменных X вхождения переменных в каждую
конъюнкцию, а затем лексикографически упорядочить между собой конъюнкции, входящие в Φ' и
Ψ'. Пусть в результате получатся совершенные ДНФ Φ'' и Ψ''
3.
Если Φ'' = Ψ'', то выдать ответ "Да", иначе - ответ "Нет".
Замечание. Аналогичную процедуру можно построить с использованием совершенных
КНФ.
Сокращенные ДНФ
Сокращенные ДНФ являются еще одним способом однозначного представления булевых
функций, которое во многих случаях может оказаться более простым, чем представление с
помощью совершенных ДНФ.
Напомним, что мы рассматриваем булевы функции над переменными
. С каждой элементарной конъюнкцией
связано множество
наборов переменных, на которых
K принимает значение 1. Нетрудно понять, что это множество содержит 2(n-k) наборов, в
которых каждая из входящих в K переменных
имеет фиксированное
значение σr , а значения остальных (n-k) переменных произвольны.
Определение Пусть f - произвольная булева функция над
K называется допустимой для f, если
. Элементарная конъюнкция
.
Элементарная конъюнкция K называется максимальной для f, если для любой
элементарной конъюнкции L из условия
следует, что
Сокращенной ДНФ для функции f называется дизъюнкция всех максимальных для этой
функции элементарных конъюнкций.
Из этого определения непосредственно следует, что сокращенная ДНФ для функции f
единственна (с точностью до порядка элементарных конъюнкций и порядка переменных в
них) и в точности задает функцию f.
Примером сокращенной ДНФ является формула
примера 4.1.
Сокращенную ДНФ можно получить из произвольной ДНФ D, используя процедуру,
называемую методом Блейка.
1.
Применять, сколько возможно, закон поглощения
213
из
(П3):
слева направо при условии, что конъюнкция (K1 K2) непротиворечива, т.е. не содержит
одновременно некоторую переменную и ее отрицание. (Заметим, что на этом этапе число
элементарных конъюнкций в ДНФ, вообще говоря, увеличивается).
2.
Применять, сколько возможно, правило поглощения
(П1):
.
Затем удалить повторные вхождения конъюнкций.
Теорема 4.2. В результате применения метода Блейка к произвольной ДНФ через
конечное число шагов будет получена эквивалентная ей сокращенная ДНФ.
Доказательство Пусть после (1)-го этапа процедуры ДНФ D функции f преобразовалась в
эквивалентную ДНФ D1 . Покажем, что для всякой допустимой для f элементарной
конъюнкция K в D1 найдется такая конъюнкция K', что
проведем возвратной индукцией по числу переменных в K.
Базис индукции. Пусть K содержит все n переменных из
единственного набора и, поскольку
которой
, то в
. Доказательство
. Тогда
состоит из
сущетсвует конъюнкция K', для
.
Шаг индукции. Пусть для некоторого k < n утверждение верно для всех допустимых для
f конъюнкций, содержащих не менее (k+1)-ой переменной. Докажем, что оно верно и для
допустимых конъюнкций с k переменными.
Пусть допустимая для f элементарная конъюнкция K содержит k переменных и пусть
- переменная, не входящая в K. Тогда обе элементарные конъюнкции
и
являются допустимыми для f и по предположению
индукции для них в Φ1 найдутся такие
и
, что
и
. Если
хотя бы одна из них не содержит X, то ее можно выбрать в качестве K'. В противном
случае, их можно представить в виде
и
и
При этом
. Поскольку все преобразования вида (П3) выполнены, то D1
тогда содержит и конъюнкцию
для которой
Заметим, что если K максимальна для f, то
максимальные конъюнкции входят в D1 .
.
. Таким образом, все
Теперь, чтобы завершить доказательство теоремы, нужно показать, что на этапе (2) из D1
будут удалены все немаксимальные элементарные конъюнкции. (Докажите это индукцией
по числу немаксимальных конъюнкций в D1 .)
Пример 4.2. Применим метод Блейка к совершенной ДНФ функции f(X1,X2,X3) ,
принимающей значение 1 на наборах множества
214
.
Ее совершенная ДНФ
После применения преобразований (П3) на (1)-ом этапе получим
После поглощений (П1) на втором этапе останется сокращенная ДНФ
Заметим, что она не является самой короткой ДНФ для f, т.к.
.
Многочлены Жегалкина
Многочлены Жегалкина являются еще одним интересным подклассом формул,
позволяющим однозначно представлять булевы функции.
Определение 4.4. Многочленами Жегалкина назваются формулы над множеством
функций FJ={ 0, 1, *, +} (здесь * - это другое обозначение конъюнкции).
Таким образом, каждый многочлен Жегалкина (возможно, после раскрытия скобок и
"приведения" подобных членов) представляет сумму (по модулю 2) положительных
(монотонных) элементарных конъюнкций (т.е. элементарных конъюнкций без отрицаний).
Поскольку для + и * справедливы законы ассоциативности, мы будем при записи
многочлена Жегалкина опускать скобки, считая, что * связывает аргументы сильнее, чем
+
Нетрудно проверить, что справедливы следующие эквивалентности:
Из этих эквивалентностей и теоремы 4.1 легко получить первую часть следующего
утверждения.
Теорема 4.3. Для любой булевой функции существует задающий ее многочлен
Жегалкина. Он единственен с точностью до перестановок слагаемых и порядка
переменных в конъюнкциях.
ДоказательствоСуществование такого многочлена следует из того, что для любой ДНФ
или КНФ можно с помощью указанных эквивалентностей найти эквивалентный
многочлен Жегалкина: (J1)-(J3) позволяют заменять все вхождения ¬, и на + и *, а (J4) перемножать получившиеся после такой замены многочлены.
215
Для доказательства единственности представления подсчитаем число различных
многочленов Жегалкина от переменных. Каждая положительная элементарная
конъюнкция имеет вид Xi1 * … * Xik , где 1 i1 < … < ik n . Таких конъюнкций столько же,
сколько подмножеств множества
, т.е. 2n . (Конъюнкция,
соответствующая пустому подмножеству переменных равна 1). Упорядочим их
произвольным образом (например, лексикографически):
Tогда каждый
многочлен Жегалкина единственным образом можно представить как сумму
где каждый из коэффициентов i равен 0 или 1. Следовательно, число многочленов
Жегалкина равно
, т.е. числу всех булевых функций от n переменных. Поэтому каждая
функция задается в точности одним многочленом Жегалкина.
Пример 4.3. Пусть функция f(X1,X2,X3) задается ДНФ
. Найдем полином Жегалкина, который также
задает эту функцию.
Сначала заменяем на *, а затем,применяя эквивалентность (J1), устраняем отрицания и
получаем:
Перемножив по правилам (J4), получим:
Эквивалентность (J3) позволяет устранить :
Снова, используя (J4), перемножим первые две скобки и устраним повторения
переменных в конъюнкциях:
Упростим эту сумму, используя эквивалентности: X + X 0 и X + 0 X. В результате
получим многочлен Жегалкина
эквивалентный исходной ДНФ Φ.
Если функция f(X1, …, Xn) задана таблично, то для построения реализующего ее
многочлена Жегалкина можно применить метод неопределенных коэфициентов.
Сопоставим i-ому набору значений переменных
положительную конъюнкцию
в таблице
переменных, равных 1 в этом наборе. В
216
частности, K1 - пустая конъюнкция, K2 = Xn, K3 = Xn-1, K4 = (Xn * Xn-1). и т.д. Тогда для
получения нужного многочлена Жегалкина достаточно определить все коэффициенты i, i
= 1, …, 2n, в выражении
Подставляя в это равенство значения переменных из набора σi, i = 1, …, 2n, мы получим 2n
линейных уравнений относительно 2n неизвестных коэффициентов i. Решив эту систему,
получим требуемый многочлен Жегалкина. Эта система треугольная и легко решается
"сверху-вниз": каждое i определяется по значениям 1, …, i-1 из уравнения,
соответствующего набору σi.
Пример 4.4. Рассмотрим в качестве примера функцию f(X1, …, Xn), заданную следующей
таблицей.
Таблица 4.1. Функция f(X1, X2, X3)
X1
X2
X3
f(X1, X2, X3)
0
0
0
1
0
0
1
0
0
1
0
0
0
1
1
0
1
0
0
1
1
0
1
0
1
1
0
0
1
1.
1
1
Многочлен Жегалкина для нее (как и для любой функции от 3-х переменных)
представляется в виде
В этом представлении в индексах у коэффициентов перечислены переменные, входящие
в соответствующие конъюнкции.
Последовательно подставляя значения переменных и f из таблицы, получаем:
Следовательно, функция f(X1, X2, X3) представляется многочленом Жегалкина
217
12.Классификация firewall’ов. Пакетные фильтры, stateful inspection
firewall’ы и прокси прикладного уровня.
Firewall’ы защищают компьютеры и сети от попыток несанкционированного доступа с
использованием уязвимых мест, существующих в семействе протоколов ТСР/IP.
Дополнительно они помогают решать проблемы безопасности, связанные с
использованием уязвимых систем и с наличием большого числа компьютеров в локальной
сети. Существует несколько типов firewall’ов, начиная от пакетных фильтров, встроенных
в пограничные роутеры, которые могут обеспечивать управление доступом для IPпакетов, до мощных firewall’ов, которые могут закрывать уязвимости в большом
218
количестве уровней семейства протоколов ТСР/IP, и еще более мощных firewall'ов,
которые могут фильтровать трафик на основании всего содержимого пакета.
Технологические возможности firewall’ов с начала 1990-х годов существенно улучшились.
Сперва были разработаны простые пакетные фильтры, которые постепенно развивались в
более сложные firewall’ы, способные анализировать информацию на нескольких сетевых
уровнях. Сегодня firewall’ы являются стандартным элементом любой архитектуры
безопасности сети.
Современные firewall’ы могут работать совместно с такими инструментальными
средствами, как системы обнаружения проникновений и сканеры содержимого e-mail или
web с целью нахождения вирусов или опасного прикладного кода. Но в отдельности
firewall не обеспечивает полной защиты от всех проблем, порожденных Интернетом. Как
результат, firewall’ы являются только одной частью архитектуры информационной
безопасности. Обычно они рассматриваются как первая линия обороны, однако их лучше
воспринимать как последнюю линию обороны в организации; организация в первую
очередь должна делать безопасными свои внутренние системы. Для внутренних серверов,
персональных компьютеров и других систем должны своевременно выполняться все
обновления как самих систем, так и других систем обеспечения безопасности, например,
антивирусного ПО.
Займемся основными понятиями, связанными с firewall’ами и политикой firewall’а, на
основании которой реализуется обеспечение безопасности сети. Рассмотрим понятия,
относящиеся к выбору, развертыванию и управлению firewall’ом и его функциональному
окружению. Рассмотрим также возможные подходы к созданию различных топологий
сети с использованием firewall’ов.
Данное описание в основном предназначено для технических специалистов, а также для
управляющего персонала, которому могут потребоваться технические знания для
принятия решений.
Сначала сделаем обзор стека протоколов OSI и покажем, на каком уровне функционируют
различные типы firewall’ов, такие как пакетные фильтры, stateful inspection firewall’ы и
прикладные прокси.
Затем опишем различные окружения firewall’а, например, комбинации конкретных
компонентов обеспечивающие то или иное решение. Приведем примеры расположения
firewall’ов и их взаимодействий с другими инструментальными средствами безопасности.
Также опишем прочие функции современных firewall’ов, такие как использование их в
качестве конечных точек VPN, трансляция IP-адресов, фильтрация содержимого web или
e-mail.
Далее рассмотрим принципы, используемые при администрировании firewall’ов и
конфигурировании политики firewall’а. Опишем политику firewall’а, которой он должен
соответствовать в контексте общей политики безопасности, а также сформулируем
минимальную политику, которая может соответствовать многим окружениям. Наконец,
опишем предложения по реализации и поддержке администрирования firewall’а.
219
Классификация firewall’ов
Firewall’ы являются устройствами или системами, которые управляют потоком сетевого
трафика между сетями с различными требованиями к безопасности. В большинстве
современных приложений firewall’ы и их окружения обсуждаются в контексте соединений
в Интернете и, следовательно, использования стека протоколов ТСР/IP. Однако firewall’ы
применяются и в сетевых окружениях, которые не требуют обязательного подключения к
Интернету. Например, многие корпоративные сети предприятия ставят firewall’ы для
ограничения соединений из и во внутренние сети, обрабатывающие информацию разного
уровня чувствительности, такую как бухгалтерская информация или информация о
заказчиках. Ставя firewall’ы для контроля соединений с этими областями, организация
может предотвратить неавторизованный доступ к соответствующим системам и ресурсам
внутри чувствительных областей. Тем самым, использование firewall’а обеспечивает
дополнительный уровень безопасности, который иначе не может быть достигнут.
В настоящее время существует несколько типов firewall’ов. Одним из способов сравнения
их возможностей является перечисление уровней модели OSI, которые данный тип
firewall’а может анализировать. Модель OSI является абстракцией сетевого
взаимодействия между компьютерными системами и сетевыми устройствами. Рассмотрим
только уровни модели OSI, относящиеся к firewall’ам.
Стек протоколов модели OSI определяется следующим образом:
Таблица 1.1. Стек протоколов модели OSI
Уровень 7
Application
Уровень 6
Presentation
Уровень 5
Session
Уровень 4
Transport
Уровень 3
Network
Уровень 2
Data Link
Уровень 1
Physical
Уровень 1 представляет собой реальную аппаратуру физического соединения и среду,
такую как Ethernet. Уровень 2 — уровень, на котором сетевой трафик передается по
локальной сети (LAN). Он также является первым уровнем, обладающим возможностью
адресации, с помощью которой можно идентифицировать отдельную машину. Адреса
назначаются на сетевые интерфейсы и называются МАС (Media Access Control) адресами.
Ethernet-адрес, принадлежащий Ethernet-карте, является примером МАС-адреса уровня 2.
Уровень 3 является уровнем, отвечающим за доставку сетевого трафика по WAN. В
Интернете адреса уровня 3 называются IP-адресами; адреса обычно являются
уникальными, но при определенных обстоятельствах, например, при трансляции сетевых
адресов (NAT) возможны ситуации, когда различные физические системы имеют один и
тот же IP-адрес уровня 3. Уровень 4 идентифицирует конкретное сетевое приложение и
коммуникационную сессию в дополнение к сетевым адресам; система может иметь
большое число сессий уровня 4 с другими ОС. Терминология, связанная с семейством
протоколов ТСР/IP, включает понятие портов, которые могут рассматриваться как
конечные точки сессий: номер порта источника определяет коммуникационную сессию
на исходной системе; номер порта назначения определяет коммуникационную сессию
220
системы назначения. Более высокие уровни (5, 6 и 7) представляют приложения и
системы конечного пользователя.
Стек протоколов TCP/IP соотносится с уровнями модели OSI следующим образом:
Таблица 1.2. Взаимосвязь уровней стека протоколов TCP/IP и OSI
Уровень 7
Application
Почтовые клиенты, web-браузеры
Уровень 4
Transport
ТСР-сессии
Уровень 3
Network
IP-адресация
Уровень 2
Data Link
Ethernet-адресация
Современные firewall’ы функционируют на любом из перечисленных уровней.
Первоначально firewall’ы анализировали меньшее число уровней; теперь более мощные из
них охватывают большее число уровней. С точки зрения функциональности, firewall,
имеющий возможность анализировать большее число уровней, является более
совершенным и эффективным. За счет охвата дополнительного уровня также
увеличивается возможность более тонкой настройки конфигурации firewall’а.
Возможность анализировать более высокие уровни позволяет firewall’у предоставлять
сервисы, которые ориентированы на пользователя, например, аутентификация
пользователя. Firewall, который функционирует на уровнях 2, 3 и 4, не имеет дело с
подобной аутентификацией.
Независимо от архитектуры firewall может иметь дополнительные сервисы. Эти сервисы
включают трансляцию сетевых адресов (NAT), поддержку протокола динамической
конфигурации хоста (DHCP) и функции шифрования, тем самым являясь конечной точкой
VPN-шлюза, и фильтрацию на уровне содержимого приложения.
Многие современные firewall’ы могут функционировать как VPN-шлюзы. Таким образом,
организация может посылать незашифрованный сетевой трафик от системы,
расположенной позади firewall’а, к удаленной системе, расположенной позади
корпоративного VPN-шлюза; firewall зашифрует трафик и перенаправит его на удаленный
VPN-шлюз, который расшифрует его и передаст целевой системе. Большинство наиболее
популярных firewall’ов сегодня совмещают эти функциональности.
Многие firewall’ы также включают различные технологии фильтрации активного
содержимого. Данный механизм отличается от обычной функции firewall’а тем, что
firewall теперь также имеет возможность фильтровать реальные прикладные данные на
уровне 7, которые проходят через него. Например, данный механизм может быть
использован для сканирования на предмет наличия вирусов в файлах, присоединенных к
почтовому сообщению. Он также может применяться для фильтрации наиболее опасных
технологий активного содержимого в web, таких как Java, JavaScript и ActiveX. Или он
может быть использован для фильтрации содержимого или ключевых слов с целью
ограничения доступа к неподходящим сайтам или доменам. Тем не менее компонент
фильтрации, встроенный в firewall, не должен рассматриваться как единственно
возможный механизм фильтрации содержимого; возможно применение аналогичных
фильтров при использовании сжатия, шифрования или других технологий.
221
Установление ТСР-соединения
ТСР является надежным протоколом в сетях, основанных на коммутации пакетов. Так как
и пакетные фильтры, и stateful inspection firewall’ы анализируют параметры ТСРпротокола, рассмотрим подробно этот протокол. Стек протоколов TCP/IP выглядит
следующим образом:
Таблица 1.3. Стек протоколов TCP/IP
Прикладной уровень
ТСР
IP
Коммуникационная сеть
Протокол IP обеспечивает способ адресации источника и получателя. IP также имеет дело
с фрагментацией и реассемблированием пакетов, которые передаются на транспортный
уровень.
Протокол ТСР обеспечивает надежность и упорядоченность для получателя потока
данных, посылаемого по ТСР-соединению.
Надежность обеспечивается с помощью того, что каждый пакет содержит свой
последовательный номер и номер полученного пакета. С каждым октетом данных
связывается последовательный номер. Этот номер указывается для первого октета данных
в передаваемом сегменте. Сегменты также содержат номер подтверждения, который
является последовательным номером следующего ожидаемого октета данных,
передаваемых в обратном направлении. Когда один из концов ТСР-соединения передает
сегмент, содержащий данные, он помещает его копию в очередь повторной передачи и
запускает таймер; когда подтверждение о получении этих данных получено, сегмент
удаляется из очереди. Если подтверждение не получено по истечении таймера, сегмент
передается повторно.
Для идентификации начальной и конечной точек ТСР-соединения вводится понятие
номера порта. Номера портов выбираются независимо для каждого соединения ТСР, при
этом они могут не быть уникальными. Для обеспечения уникальной идентификации
внутри каждого соединения ТСР, выполняется конкатенация IP-адреса и номера порта.
Эта конкатенация определяет сокет.
Соединение полностью определяется парой сокетов на своих концах. Локальный сокет
может участвовать во многих соединениях с различными удаленными сокетами.
Соединение используется для пересылки данных в обоих направлениях.
ТСР может использовать любые номера портов. Тем не менее определены некоторые
базовые принципы назначения номеров портов. Существуют "хорошо известные" номера
портов, которые ТСР связывает только с "соответствующими" процессами.
Каждый конец ТСР-соединения является либо клиентом, либо сервером. Соединение
инициируется клиентом. Сервер ждет установления соединения от клиента. Поэтому ТСРсоединение может быть открыто либо в пассивном режиме — сервером, либо в активном
— клиентом.
222
Запрос пассивного открытия означает, что процесс сервера ждет запросов на входящие
соединения, а не пытается сам инициировать соединение. Часто процесс, запрашивающий
пассивное открытие, будет принимать запросы соединения от любого вызывающего.
Процесс, который хочет предоставлять сервис другим неизвестным процессам, создает
запрос пассивного открытия. При этом будет создаваться соединение с любым процессом,
который запросил соединение с данным локальным сокетом.
Процедура установления соединений использует флаг управления синхронизацией (SYN)
и включает обмен тремя сообщениями.
Соединение инициируется при получении сегмента, содержащего установленный флаг
SYN. При инициализации соединение устанавливается между локальным и удаленным
сокетами. Оно становится "установленным", когда последовательные номера пакетов
синхронизованы в обоих направлениях.
Очистка соединения включает обмен сегментами, содержащими управляющий флаг FIN.
ТСР-сегменты посылаются в виде датаграмм. Заголовок IP содержит несколько полей,
включая адреса хостов источника и получателя. ТСР-заголовок следует за IP-заголовком и
содержит информацию, специфичную для ТСР.
Таблица 1.4. Формат заголовка ТСР
Порт источника
Порт получателя
Sequence Number
Acknowledgement Number
Data Offset Reserved URG ACK PSH RST SYN FIN Window
Checksum
Urgent Pointer
Options Padding
Данные
Порт источника – 16 бит.
Порт получателя – 16 бит.
Sequence Number – 32 бита. Последовательный номер первого октета данных в данном
сегменте. Исключением является случай, когда присутствует флаг SYN. В этом случае
последовательный номер есть начальный последовательный номер (Initial Sequence
Number — ISN), и номер первого октета данных равен ISN+1.
Acknowledgement Number – 32 бита. Если установлен управляющий бит ACK, то данное
поле содержит значение следующего последовательного номера, который ждет
получатель. Это значение посылается всегда, если соединение установлено.
Data Offset – 4 бита. Число 32-битных слов в ТСР-заголовке. Оно определяет положение
начала данных. Длина ТСР-заголовка всегда кратна 32.
Управляющие биты: 6 бит.
223
URG — указывает, что сегмент содержит экстренные данные и поле Urgent Pointer
заголовка определяет их положение в сегменте.
ACK — указывает, что поле номера подтверждения содержит номер последнего
полученного сегмента.
PSH — указывает, что данные из буфера могут быть переданы немедленно.
RST — указывает на необходимость сброса соединения.
SYN — указывает, что выполняется синхронизация последовательных номеров.
FIN — указывает, что от отправителя больше не будут передаваться данные.
Window — 16 бит. Количество октетов данных, начиная с номера, указанного в
подтверждении, которое отправитель данного сегмента может получить. Используется для
управления интенсивностью передаваемого потока данных.
Checksum – 16 бит. Контрольная сумма всех слов в заголовке и данных.
Urgent Pointer – 16 бит. Данное поле содержит положительное смещение экстренных
данных относительно последовательного номера в данном сегменте.
Options – переменной длины. Опции могут быть указаны в конце ТСР-заголовка.
Определены два варианта формата опций:

Один октет для типа опции.

Октет типа опции, октет длины опции и октеты с конкретными данными опции.
Padding – переменной длины. Данное добавление ТСР-заголовка используется для того,
чтобы гарантировать, что ТСР-заголовок кончается, и данные начинаются на 32-битной
границе.
Установление ТСР-соединения происходит с использованием так называемого "тройного
рукопожатия". Соединение инициирует клиент, посылая сообщение с установленным
битом SYN. Сервер отвечает клиенту сообщением с установленными битами SYN и ACK.
Сервер также указывает начальный порядковый номер в поле Sequence Number. Наконец,
клиент посылает серверу сообщение с установленным битом ACK, в поле Sequence
Number указывает свой начальный номер, в поле Acknowledgement Number указывает
полученный от сервера начальный порядковый номер, увеличенный на единицу.
В течение своего жизненного цикла соединение проходит через несколько состояний.
На стороне клиента:
CLOSED
SYN-SENT
ESTABLISHED
FIN-WAIT-1
224
CLOSE-WAIT
CLOSING
LAST-ACK
CLOSED,
На стороне сервера:
CLOSED
LISTEN
SYN-RESEIVED
ESTABLISHED
FIN-WAIT-1
CLOSE-WAIT
CLOSING
FIN-WAIT-2
TIME-WAIT
CLOSED
Рассмотрим смысл каждого состояния.
Состояние CLOSED является фиктивным, потому что оно представляет собой состояние,
для которого не существует структуры данных Transmission Control Block (ТСВ) и,
следовательно, нет соединения.
LISTEN – состояние сервера, которое представляет собой ожидание запроса соединения
от любой удаленной стороны.
SYN-SENT – состояние клиента, которое представляет собой ожидание ответа на запрос
соответствующего соединения после того как послан запрос на соединение.
SYN-RECEIVED – состояние сервера, которое представляет собой ожидание
подтверждения на запрос соединения после того как и клиент, и сервер получили и
послали запрос на соединение.
ESTABLISHED – состояние как клиента, так и сервера, которое представляет собой
открытое соединение: полученные данные могут быть доставлены на прикладной уровень.
Обычное состояние для фазы пересылки данных по соединению.
Инициатором закрытия соединения может быть как клиент, так и сервер.
225
FIN-WAIT-1 – состояние как клиента, так и сервера, при котором сторона,
инициировавшая закрытие (был послан пакет в флагом FIN), ожидает подтверждения на
запрос закрытия соединения.
CLOSE-WAIT – состояние как клиента, так и сервера, при котором было послано
подтверждение ACK на запрос закрытия (FIN). При этом канал становится симплексным:
передача возможна только в одном направлении – от того, кто послал подтверждение
ACK. Происходит ожидание закрытия канала от локального процесса.
FIN-WAIT-2 — состояние как клиента, так и сервера, при котором было получено
подтверждение ACK запроса закрытия соединения от удаленной стороны. При получении
пакета с установленным флагом FIN канал считается окончательно разрушенным.
LAST-ACK – состояние как клиента, так и сервера, представляет собой подтверждение
(пакет с установленным флагом FIN) завершения соединения, ранее посланного
удаленной стороне.
CLOSING – представляет собой ожидание подтверждения запроса завершения соединения
от удаленной стороны.
TIME-WAIT – представляет собой ожидание определенное время, чтобы быть уверенным,
что удаленная сторона получила подтверждение вашего запроса на закрытие соединения.
ТСР-соединение переходит из одного состояния в другое в результате возникновения
событий. Событиями являются вызовы функций OPEN, SEND, RECEIVE, CLOSE,
ABORT и STATUS, входящие сегменты, содержащие флаги SYN, ACK, RST и FIN, а
также таймауты.
Пакетные фильтры
Самый основной, базовый, первоначально разработанный тип firewall’а называется
пакетным фильтром. Пакетные фильтры в основном являются частью устройств роутинга,
которые могут управлять доступом на уровне системных адресов и коммуникационных
сессий. Функциональность управления доступом обеспечивается с помощью множества
директив, называемых ruleset или rules (правила).
Вначале пакетные фильтры функционировали на уровне 3 (Network) модели OSI. Данная
функциональность разработана для обеспечения управления сетевым доступом,
основываясь на нескольких блоках информации, содержащихся в сетевом пакете. В
настоящее время все пакетные фильтры также анализируют и уровень 4 (Transport).
Пакетные фильтры анализируют следующую информацию, содержащуюся в заголовках
пакетов 3-го и 4-го уровней:

Адрес источника пакета, например, адрес уровня 3 системы или устройства, откуда получен
исходный сетевой пакет (IP-адрес, такой как 192.168.1.1).

Адрес назначения пакета, например, адрес уровня 3 пакета, который он пытается достигнуть
(например, 192.168.1.2).
226

Тип коммуникационной сессии, т.е. конкретный сетевой протокол, используемый для
взаимодействия между системами или устройствами источника и назначения (например, ТСР, UDP
или ICMP).

Возможно некоторые характеристики коммуникационных сессий уровня 4, такие как порты
источника и назначения сессий (например, ТСР:80 для порта назначения, обычно принадлежащий
web-серверу, ТСР:1320 для порта источника, принадлежащий персональному компьютеру, который
осуществляет доступ к серверу).

Иногда информация, относящаяся к интерфейсу роутера, на который пришел пакет, и информация
о том, какому интерфейсу роутера она предназначена; это используется для роутеров с тремя и
более сетевыми интерфейсами.

Иногда информация, характеризующая направление, в котором пакет пересекает интерфейс, т.е.
входящий или исходящий пакет для данного интерфейса.

Иногда можно также указать свойства, относящиеся к созданию логов для данного пакета.
Пакетные фильтры обычно размещаются в сетевой инфраструктуре, использующей
ТСР/IP. Однако они могут также быть размещены в любой сетевой инфраструктуре,
которая имеет адресацию уровня 3, например, IPX (Novell NetWare) сети. В современных
сетевых инфраструктурах firewall’ы на уровне 2 могут также использоваться для
обеспечения балансировки нагрузки и/или в приложениях с высокими требованиями к
доступности, в которых два или более firewall’а используются для увеличения пропускной
способности или для выполнения восстановительных операций.
Некоторые пакетные фильтры, встроенные в роутеры, могут также фильтровать сетевой
трафик, основываясь на определенных характеристиках этого трафика, для
предотвращения DoS- и DDoS-атак.
Пакетные фильтры могут быть реализованы в следующих компонентах сетевой
инфраструктуры:

пограничные роутеры;

ОС;

персональные firewall’ы.
Пограничные роутеры
Основным преимуществом пакетных фильтров является их скорость. Так как пакетные
фильтры обычно проверяют данные до уровня 3 модели OSI, они могут функционировать
очень быстро. Также пакетные фильтры имеют возможность блокировать DoS-атаки и
связанные с ними атаки. По этим причинам пакетные фильтры, встроенные в
пограничные роутеры, идеальны для размещения на границе с сетью с меньшей
степенью доверия. Пакетные фильтры, встроенные в пограничные роутеры, могут
блокировать основные атаки, фильтруя нежелательные протоколы, выполняя простейший
контроль доступа на уровне сессий и затем передавая трафик другим firewall’ам для
проверки более высоких уровней стека OSI.
227
Рис. 1.1. Использование пограничного роутера с возможностями пакетного фильтра
На рис. 1.1 показана топология сети, использующая пограничный роутер с возможностями
пакетного фильтра в качестве первой линии обороны. Роутер принимает пакеты от
недоверяемой сети, которые обычно приходят от другого роутера или от Интернет Сервис
Провайдера (ISP). Затем роутер выполняет контроль доступа в соответствии со своей
политикой, например, блокирует SNMP, разрешает НТТР и т.п. Затем он передает пакеты
более мощному firewall’у для дальнейшего управления доступом и фильтрования
операций на более высоких уровнях стека OSI. На рис. 1.1 также показана промежуточная
сеть между пограничным роутером и внутреннем firewall’ом, называемая DMZ-сетью.
Преимущества пакетных фильтров:

Основным преимуществом пакетных фильтров является их скорость.

Пакетный фильтр прозрачен для клиентов и серверов, так как не разрывает ТСР-соединение.
Недостатки пакетных фильтров:

Так как пакетные фильтры не анализируют данные более высоких уровней, они не могут
предотвратить атаки, которые используют уязвимости или функции, специфичные для приложения.
Например, пакетный фильтр не может блокировать конкретные команды приложения; если
пакетный фильтр разрешает данный трафик для приложения, то все функции, доступные данному
приложению, будут разрешены.

Так как firewall’у доступна ограниченная информация, возможности логов в пакетных фильтрах
ограничены. Логи пакетного фильтра обычно содержат ту же информацию, которая использовалась
при принятии решения о возможности доступа (адрес источника, адрес назначения, тип трафика и
т.п.).
228

Большинство пакетных фильтров не поддерживают возможность аутентификации пользователя.
Данная возможность обеспечивается firewall’ами, анализирующими более высокие уровни.

Они обычно уязвимы для атак, которые используют такие проблемы ТСР/IP, как подделка
(spoofing) сетевого адреса. Многие пакетные фильтры не могут определить, что в сетевом пакете
изменена адресная информация уровня 3 OSI. Spoofing-атаки обычно выполняются для обхода
управления доступа, осуществляемого firewall’ом.

При принятии решений о предоставлении доступа используется небольшое количество
информации.

Пакетные фильтры трудно конфигурировать. Можно случайно переконфигурировать пакетный
фильтр для разрешения типов трафика, источников и назначений, которые должны быть запрещены
на основе политики безопасности организации.
Следовательно, пакетные фильтры больше всего подходят для высокоскоростных
окружений, когда создание логов и аутентификация пользователя для сетевых ресурсов не
столь важна.
Так как современная технология firewall’а включает много возможностей и
функциональностей, трудно найти firewall, который имеет возможности только пакетного
фильтра. Примером может являться сетевой роутер, осуществляющий проверку списка
контроля доступа для управления сетевым трафиком. Высокая производительность
пакетных фильтров также способствует тому, что они реализуются в устройствах,
обеспечивающих высокую доступность и особую надежность; некоторые производители
предлагают аппаратные и программные решения как высоко доступные, так и особо
надежные. Также большинство SOHO (Small Office Home Office) устройства firewall’ов и
firewall’ов, встроенных по умолчанию в ОС, являются пакетными фильтрами.
Пример набора правил пакетного фильтра
Предположим, что в организации существует следующая топология (рис. 1.2).
Рис. 1.2. Топология сети с использованием пакетного фильтра
Таблица 1.5. Набор правил пакетного фильтра
Адрес источника
1 Any
Порт
Порт
Адрес назначения
Действие
источника
назначения
Any
192.168.1.0(рабочая >1023
станция)
229
Allow
Описание
Правило разрешает
возвращать ТСРсоединения во
внутреннюю подсеть, т.е.
пользователи внутренней
сети могут выходить в
Интернет
2 192.168.1.1(пакетный Any
фильтр)
Any
Any
Deny
Защищает сам пакетный
фильтр от
непосредственного
соединения с кем-либо
3 Any
Any
192.168.1.1
Any
Deny
Предотвращает
непосредственный доступ
всех пользователей к
пакетному фильтру
4 192.168.1.0
Any
Any
Any
Allow
Внутренние пользователи
могут иметь доступ к
внешним серверам
5 Any
Any
192.168.1.2(SMTPсервер)
SMTP
Allow
Разрешает всем (внешним
и внутренним)
пользователям посылать
e-mail внутренним
пользователям
6 Any
Any
192.168.1.3(НТТРсервер)
НТТР
Allow
Разрешает внешним
пользователям иметь
доступ к WWW-серверу
7 Any
Any
Any
Any
Deny
"Запретить все": правило
– все, что не разрешено,
то запрещено
В таблице приведен пример набора правил пакетного фильтра для вымышленной сети с
IP-адресами 192.168.1.0/255, т.е. локальная сеть имеет адреса в диапазоне от 192.168.1.0 до
192.168.1.254. В большинстве случаев набор правил должен быть детальнее. Обычно
firewall принимает пакет, просматривает его адреса и порты источника и назначения и
определяет используемый прикладной протокол. Далее firewall начинает просматривать
правила сверху вниз. Если найдено правило, которое соответствует анализируемой в
пакете информации, то выполняется указанное в правиле действие:

Accept (в некоторых пакетных фильтрах может быть Allow или Pass): firewall пропускает пакет
через firewall, при этом может происходить создание лога, либо не происходить.

Deny: firewall отбрасывает пакет без его передачи. После того как пакет отброшен, исходной
системе возвращается сообщение об ошибке ("host unreachable"). Событие "Deny" может как
создавать, так и не создавать запись лога, в зависимости от конфигурации набора правил firewall’а.

Discard (в некоторых пакетных фильтрах может быть Unreach, Block или Reject): firewall не только
отбрасывает пакет, но и не возвращает сообщение об ошибке исходной системе. Данное действие
используется для реализации методологии "черной дыры", когда firewall не обнаруживает свое
присутствие для внешней стороны. Как и для других действий, "Discard" может создавать и не
создавать записи в логах.
В приведенной выше таблице первое правило разрешает, чтобы пакеты от внешних
систем возвращались во внутренние системы, тем самым разрешая завершать создание
соединения. Таким образом, здесь предполагается, что если инициализация соединения с
внешней системой была разрешена, то возвращаемые пакеты от внешней системы должны
быть также разрешены для завершения создания ТСР-соединения. Второе правило
запрещает firewall’у пересылать любые пакеты с адресом источника firewall’а; данное
условие предотвращает возможность атакующего подделать адрес firewall’а, заменив свой
230
адрес на адрес firewall’а, чтобы firewall передал пакет внутреннему получателю. Здесь
предполагается, что на данном хосте не установлено никаких других систем, к которым
необходим доступ. В этом случае редактирование правил firewall’а возможно только с
консоли хоста. Это не всегда бывает возможно. Например, может понадобиться доступ к
хосту по протоколу SSH для редактирования правил самого firewall’а. Третье правило
просто блокирует все пакеты от непосредственного доступа к firewall’у.
Четвертое правило разрешает внутренним системам соединяться с внешними системами,
используя любые внешние адреса и любой протокол. Правила 5 и 6 разрешают внешним
пакетам проходить firewall, если они содержат SMTP- или НТТР-данные. Тем самым
можно сделать вывод, что политика информационной безопасности для сети следующая:

Любой тип доступа изнутри наружу разрешен.

Никакой доступ снаружи внутрь не разрешен, за исключением SMTP и НТТР.

SMTP- и НТТР-серверы расположены позади firewall’а.

На сам firewall не разрешен доступ.
Важно заметить, что если последнее правило будет случайно пропущено, весь трафик
извне будет разрешен. Когда набор правил более длинный и более детальный, могут
быть сделаны ошибки, которые приведут к нарушениям безопасности. Набор правил
должен быть очень тщательно проверен перед его применением и регулярно проверяться
не только для гарантии того, что допустимы корректные протоколы, но и также для
минимизации логических ошибок при добавлении новых правил.
Важным свойством пакетных фильтров является то, что фильтрация может
осуществляться как для исходящего, так и для входящего трафика. Организация может
выбрать ограничение типов трафика, передаваемых из внутренней сети, например,
блокирование всего исходящего FTP-трафика. На практике исходящая фильтрация чаще
всего применяется к IP-адресам и приложениям для блокировки возможности соединения
всех пользователей, внутренних и внешних, с некоторыми системами, такими как сам
пакетный фильтр, backup-серверы и другие чувствительные системы.
Stateful Inspection firewall’ы
Stateful Inspection firewall’ы являются пакетными фильтрами, которые анализируют
содержимое 4-го уровня (Transport) модели OSI.
Stateful inspection разрабатывались исходя из необходимости рассматривать основные
особенности протоколов TCP/IP. Когда ТСР создает сессию с удаленной системой, также
открывается порт на исходной системе для получения сетевого трафика от системы
назначения. В соответствии со спецификацией ТСР, данный порт источника клиента будет
некоторым числом, большим, чем 1023 и меньшим, чем 16384. Порт назначения на
удаленном хосте, как правило, имеет фиксированный номер. Например, для SMTP это
будет 25.
Пакетные фильтры должны разрешать входящий сетевой трафик для всех таких портов "с
большими номерами" для транспорта, ориентированного на соединение, так как это будут
231
возвращаемые пакеты от системы назначения. Открытие портов создает риск
несанкционированного проникновения в локальную сеть.
В таблице 1.6 показана первая строчка набора правил пакетного фильтра из приведенной
выше таблицы, которая разрешает любое входящее соединение, если порт назначения
больше 1023. Stateful inspection firewall’ы решают эту проблему созданием таблицы для
исходящих ТСР-соединений, соответствующих каждой сессии. Эта "таблица состояний"
затем используется для проверки допустимости любого входящего трафика. Решение
stateful inspection является более безопасным, потому что отслеживать используемые
порты каждого клиента лучше, чем открывать для внешнего доступа все порты "с
большими номерами".
Таблица 1.6. Правило завершения создания соединения
Адрес
Порт
Адрес
Порт
Действие
Описание
источника
источника
назначения
назначения
Any
Any
192.168.1.0
>1023
Allow
Правило разрешает возвращать ТСРсоединения во внутреннюю подсеть
В сущности, stateful inspection firewall’ы добавляют понимание уровня 4 в архитектуру
пакетного фильтра. Stateful inspection firewall’ы разделяют сильные и слабые стороны
пакетных фильтров, но вследствие реализации таблицы состояний stateful inspection
firewall’ы обычно считаются более безопасными, чем пакетные фильтры. В таблице 1.7
показан пример таблицы состояний firewall’а stateful inspection.
Таблица 1.7. Таблица состояний соединений stateful inspection firewall’а
Адрес источника Порт источника Адрес назначения Порт назначения Состояние соединения
192.168.1.100
1030
210.9.88.29
80
Establish
192.168.1.102
1031
216.32.42.123
80
Establish
192.168.1.101
1033
173.66.32.122
25
Establish
192.168.1.106
1035
177.66.32.122
79
Establish
223.43.21.231
1990
192.168.1.6
80
Establish
219.22.123.32
2112
192.168.1.6
80
Establish
210.99.212.18
3321
192.168.1.6
80
Establish
24.102.32.23
1025
192.168.1.6
80
Establish
223.212.212
1046
192.168.1.6
80
Establish
Преимущества stateful inspection firewall’а:

Разрешает прохождение пакетов только для установленных соединений;

Прозрачен для клиентов и серверов, так как не разрывает ТСР-соединение.
Недостатки stateful inspection firewall’а:

Реально используется только в сетевой инфраструктуре TCP/IP. Хотя, надо отметить, что stateful
inspection firewall можно реализовать в других сетевых протоколах тем же способом, что и пакетные
фильтры.
232
Host-based firewall’ы
Пакетные фильтры реализованы в некоторых ОС, таких как Unix/Linux; в частности, они
могут использоваться только для обеспечения безопасности хоста, на котором они
функционируют. Это может быть полезно при совместном функционировании с
различными серверами; например, внутренний web-сервер может выполняться на системе,
на которой функционирует host-based firewall.
Преимущества host-based firewall’а:

Приложение сервера защищено лучше, чем если бы оно выполнялось на ОС, не имеющей host-based
firewall’а: внутренние серверы должны быть сами по себе защищены, и не следует предполагать,
что они не могут быть атакованы только потому, что они расположены позади основного firewall’а.

Выполнение firewall’а на отдельном хосте не является необходимым условием для обеспечения
безопасности сервера: host-based firewall достаточно хорошо выполняет функции обеспечения
безопасности.

ПО, реализующее host-based firewall, обычно предоставляет возможность управления доступом для
ограничения трафика к серверам и от серверов, выполняющихся на том же хосте, и обычно
существуют определенные возможности создания логов. Хотя host-based firewall’ы менее
предпочтительны в случае большого трафика и в окружениях с высокими требованиями к
безопасности, для внутренних сетей небольших офисов они обеспечивают адекватную безопасность
при меньшей цене.
Недостаток host-based firewall’а:

Каждый такой firewall должен администрироваться самостоятельно, и после определенного
количества серверов с host-based firewall’ами легче и дешевле просто разместить все серверы позади
выделенного firewall’а.
Персональные firewall’ы и персональные устройства firewall’а
Обеспечение безопасности персональных компьютеров дома или в мобильном варианте
сейчас становится столь же важным, как и обеспечение безопасности компьютеров в
офисе; домашние пользователи, подключающиеся по dial-up к провайдеру, могут
обеспечить защиту с помощью небольшого firewall’а, доступного им. Это необходимо,
потому что провайдер может иметь много различных политик безопасности, не всегда
соответствующих нуждам конкретного пользователя. Тем самым персональные firewall’ы
разрабатываются для обеспечения защиты удаленных систем и выполняют во многом те
же самые функции, что и большие firewall’ы.
Эти программные продукты обычно реализованы в одном из двух вариантов. Первый
вариант представляет собой Personal Firewall, который инсталлируется на защищаемую
систему; персональные firewall’ы обычно не предполагают защиту каких-либо других
систем или ресурсов. Более того, персональные firewall’ы обычно не обеспечивают
управление сетевым трафиком, который проходит через компьютер – они только
защищают систему, на которой они инсталлированы.
Второй вариант называется устройством персонального firewall’а, чей подход более похож
на традиционный firewall. В большинстве случаев устройства персонального firewall’а
разрабатываются для защиты небольших сетей, таких как домашние сети. Эти устройства
233
обычно изготавливаются на специализированной аппаратуре и имеют некоторые другие
компоненты сетевой архитектуры в дополнение к самому firewall’у, включая следующие:

WAN-роутер кабельного модема;

LAN-роутер (поддержка динамического роутинга);

сетевой концентратор (hub);

сетевой коммутатор (switch);

DHCP;

агент SNMP;

агенты прикладного прокси.
Размещение этих инфраструктурных компонент в устройстве firewall’а позволяет
использовать единственное аппаратное устройство для эффективного решения нескольких
задач.
Хотя персональные firewall’ы и устройства персональных firewall’ов теряют некоторые
преимущества и возможности масштабируемости традиционных firewall’ов, они могут
быть достаточно эффективны для обеспечения общей безопасности организации.
Персональные firewall’ы и устройства персональных firewall’ов обычно предназначены
для филиалов офисов. Тем не менее некоторые организации используют эти устройства
для создания Интранета, обеспечивая стратегию обороны вглубь. Персональные firewall’ы
и устройства персональных firewall’ов могут также использоваться как конечные точки
VPN.
Удобство управления устройством или приложением является важным фактором при
оценке или выборе персонального firewall’а и устройства персонального firewall’а.
Идеально, когда управление позволяет реализовать определяемую организацией политику
безопасности на всех системах, которые присоединяются к сети и системе. Поэтому
управление персональным firewall’ом или устройством персонального firewall’а должно
быть по возможности централизовано. Это позволяет организации реализовывать
определенную политику и поддерживать согласованное состояние систем, которые
подсоединены удаленно. Наилучший способ обеспечить подобную функциональность
является создание профиля безопасной конфигурации, который сопровождает конечного
пользователя при его входе на любую систему. При таком подходе политика безопасности
всегда будет эффективно реализовываться в момент доступа пользователя к ресурсам.
Что можно сказать об удаленных пользователях, которые подсоединяются к dial-in
серверу организации или к провайдерам? Если политика безопасности провайдера
является менее ограничительной, чем в организации, то риск, что компьютер будет
инфицирован вирусом или будет выполнена другая атака, будет больше. Существует
также проблема, что многие пользователи используют свои персональные компьютеры
как для работы, так и для целей, далеких от служебных.
Одно из возможных решений состоит в использовании отдельных компьютеров в офисе и
вне офиса.
234
Если такое решение недоступно, то персональный firewall должен использоваться все
время и должен быть сконфигурирован с учетом наиболее ограничительных установок,
используемых в организации. Если, например, разделение файлов в Windows запрещено
firewall’ом, то это должно оставаться запрещенным, даже если компьютер используется в
нерабочих целях. Также, если установки web-безопасности отвергают определенные типы
содержимого, данный запрет должен оставаться в силе все время. Такая политика должна
быть реализована для dial-in сервера; он, в свою очередь, должен быть размещен таким
образом, чтобы firewall и прокси фильтровали входящий трафик от dial-in соединений.
Прокси-сервер прикладного уровня
Прокси прикладного уровня являются более мощными firewall’ами, которые
комбинируют управление доступом на низком уровне с функциональностью более
высокого уровня (уровень 7 – Application).
Рис. 1.3. Типичные прокси-агенты
При использовании firewall’а прикладного уровня обычно, как и в случае пакетного
фильтра не требуется дополнительное устройство для выполнения роутинга: firewall
выполняет его сам. Все сетевые пакеты, которые поступают на любой из интерфейсов
firewall’а, находятся под управлением этого прикладного прокси. Прокси-сервер имеет
набор правил управления доступом для определения того, какому трафику может быть
разрешено проходить через firewall.
Аутентификация пользователя может иметь много форм, например такие:

с помощью User ID и пароля;

с помощью аппаратного или программного токена;

по адресу источника;

биометрическая аутентификация.
Прокси-сервер, который анализирует конкретный протокол прикладного уровня,
называется агентом прокси.
Firewall’ы прикладного уровня имеют много преимуществ по сравнению с пакетными
фильтрами и stateful inspection пакетными фильтрами.
Преимущества прокси-сервера прикладного уровня:
235

Прокси имеет возможность запросить аутентификацию пользователя. Часто существует
возможность указывать тип аутентификации, который считается необходимым для данной
инфраструктуры. Прикладные прокси имеют возможность аутентифицировать самих
пользователей, в противоположность пакетным фильтрам и stateful inspection пакетным фильтрам,
обычно проверяющим только адрес сетевого уровня, с которого пришел пользователь. Эти адреса
сетевого уровня могут быть легко подменены без обнаружения подмены пакетным фильтром.

Возможности аутентификации, свойственные архитектуре прикладного уровня, лучше по
сравнению с теми, которые существуют в пакетных фильтрах и stateful inspection пакетных
фильтрах. Благодаря этому прикладные прокси могут быть сделаны менее уязвимыми для атак
подделки адреса.

Firewall’ы прикладного уровня обычно имеют больше возможностей анализировать весь сетевой
пакет, а не только сетевые адреса и порты. Например, они могут определять команды и данные,
специфичные для каждого приложения.

Как правило, прокси прикладного уровня создают более подробные логи.
Более развитая функциональность прикладного прокси имеет также несколько
недостатков по сравнению с пакетными фильтрами и stateful inspection пакетными
фильтрами.
Недостатки прокси-сервера прикладного уровня:

Так как прикладные прокси "знают о пакете все", firewall вынужден тратить много времени для
чтения и интерпретации каждого пакета. По этой причине прикладные прокси обычно не подходят
для приложений, которым необходима высокая пропускная способность, или приложений
реального времени. Чтобы уменьшить загрузку firewall’а, может использоваться выделенный
прокси-сервер для обеспечения безопасности менее чувствительных ко времени сервисов, таких как
e-mail и большинство web-трафика.

Прикладные прокси обрабатывают ограниченное количество сетевых приложений и протоколов и
не могут автоматически поддерживать новые сетевые приложения и протоколы. Для каждого
прикладного протокола, который должен проходить через firewall, необходим свой агент прокси.
Большинство производителей прикладных прокси предоставляют общих агентов прокси для
поддержки неизвестных сетевых приложений или протоколов. Однако эти общие агенты не имеют
большинства преимуществ прикладных прокси: как правило, они просто туннелируют трафик через
firewall.
Выделенные прокси-серверы
Выделенные прокси-серверы отличаются от прикладных прокси в том, что они
анализируют трафик только конкретного прикладного протокола и не обладают
возможностями анализа всего трафика, что все-таки характерно для firewall’а прикладного
уровня. По этой причине они обычно развертываются позади firewall’ов прикладного
уровня. Типичное использование таково: основной firewall получает входящий трафик,
определяет, какому приложению он предназначен, и затем передает обработку
конкретного типа трафика соответствующему выделенному прокси-серверу, например, email прокси серверу. Выделенный прокси-сервер при этом выполняет операции
фильтрации и логирования трафика и затем перенаправляет его во внутренние системы.
Этот сервер может также принимать исходящий трафик непосредственно от внутренних
систем, фильтровать трафик и создавать логи, а затем передавать его firewall’у для
последующей доставки. Обычно выделенные прокси-серверы используются для
236
уменьшения нагрузки на firewall и выполнения более специализированной фильтрации и
создания логов.
Как и в случае прикладных прокси, выделенные прокси позволяют выполнить
аутентификацию пользователей. В случае использования выделенного прокси легче более
точно ограничить исходящий трафик или проверять весь исходящий и входящий трафик,
например, на наличие вирусов. Выделенные прокси-серверы могут также помочь в
отслеживании внутренних атак или враждебного поведения внутренних пользователей.
Фильтрация всего исходящего трафика сильно загружает общий firewall прикладного
уровня и увеличивает стоимость администрирования.
В дополнение к функциям аутентификации и создания логов, выделенные прокси-серверы
используются для сканирования web и e-mail содержимого, включая следующие функции:

фильтрование Java-апплетов или приложений;

фильтрование управлений ActiveX;

фильтрование JavaScript;

блокирование конкретных MIME-типов – например, "application/msword";

сканирование и удаление вирусов;

блокирование команд, специфичных для приложения, например, блокирование НТТР-команды
PUT;

блокирование команд, специфичных для пользователя, включая блокирование некоторых типов
содержимого для конкретных пользователей.
Рис. 1.4. Примеры выделенных прикладных прокси-серверов
237
На рис. 1.4 показан пример топологии сети, которая имеет выделенные прокси-серверы
для НТТР и e-mail, расположенные позади основного firewall’а. В этом случае e-mail
прокси может быть SMTP-шлюзом организации для входящей почты. Основной firewall
будет перенаправлять входящую почту к прокси для сканирования содержимого, после
чего почта может становиться доступной внутренним пользователям на SMTP-сервере,
например, по протоколам РОР3 или IMAP. НТТР-прокси должен обрабатывать исходящие
соединения ко внешним web-серверам и, возможно, фильтровать активное содержимое.
Прокси-сервером может выполняться кэширование часто используемых web-страниц, тем
самым уменьшая трафик к firewall’у.
Гибридные технологии firewall’а
Недавние разработки в области сетевой инфраструктуры и информационной безопасности
привели к стиранию границ между различными типами firewall’ов, которые обсуждались
выше. Как результат, программные продукты firewall’ов соединяют функциональности
нескольких различных типов firewall’ов. Например, многие производители прикладных
прокси реализуют базовую функциональность пакетных фильтров.
Также многие разработчики пакетных фильтров или stateful inspection пакетных фильтров
реализуют базовую функциональность прикладных прокси для ликвидации слабых мест,
связанных с этими типами firewall’ов. В большинстве случаев производители реализуют
прикладные прокси для улучшения создания логов и аутентификации пользователя.
После того как все основные производители будут использовать в своих продуктах в том
или ином виде гибридные технологии, не всегда просто будет решить, какой продукт
наиболее подходит для данного приложения или инфраструктуры предприятия.
Гибридные свойства платформ firewall’ов делают особенно важной фазу оценки firewall’а.
При выборе продукта важнее оценить поддерживаемое количество возможностей, чем
формально смотреть тип firewall’а.
Трансляция сетевых адресов (NAT)
Технология трансляции сетевых адресов (NAT) была разработана для решения двух
важных проблем, возникших в сетевой инженерии и безопасности. Во-первых, NAT
является эффективным средством для скрытия схемы сетевой адресации позади firewall’а.
В сущности, трансляция сетевых адресов позволяет организации развертывать схему
адресации позади firewall’а в соответствии со своим выбором, в то же время поддерживая
возможность соединяться с внешними ресурсами через firewall. Во-вторых, это решает
проблему исчерпания пространства IP-адресов.
NAT выполняется в трех основных формах: статическая трансляция сетевых адресов,
скрытая трансляция сетевых адресов и трансляция портов.
Статическая трансляция сетевых адресов
При статической трансляции сетевых адресов каждая внутренняя система или частная
сеть имеет соответствующий, связанный с ней внешний IP-адрес. Данная технология
используется редко из-за недостатка доступных IP-адресов. При статической трансляции
сетевых адресов возможно предоставление доступа к ресурсам, размещенным позади
238
firewall’а. Другими словами, внешняя система может иметь доступ ко внутреннему webсерверу; при этом адрес отображается с использованием статической трансляции сетевых
адресов. Ниже приведен пример таблицы статической трансляции сетевых адресов,
отображающей внутренние IP-адреса, к которым не выполняется роутинг, во внешние
адреса, к которым выполняется роутинг.
Таблица 1.8. Таблица статической трансляции сетевых адресов
Внутренний IP-адрес Внешний (глобально доступный)IP-адрес
192.168.1.100
207.119.32.81
192.168.1.101
207.119.32.82
192.168.1.102
207.119.32.83
Скрытая трансляция сетевых адресов
При скрытой трансляции все системы позади firewall’а разделяют некоторый внешний IPадрес, к которому выполняется роутинг. Таким образом, при скрытой трансляции сетевых
адресов все хосты позади firewall’а будут выглядеть как один хост. Такой тип трансляции
является достаточно распространенным, но имеет одно существенное слабое место.
Данная технология не позволяет сделать доступными для внешних пользователей те
ресурсы, которые размещены позади firewall’а. Отображение от внешних систем во
внутренние системы невозможно, следовательно, хосты, которые должны быть доступны
внешним системам, не могут применять данное отображение адресов. Другое слабое
место данного подхода состоит в том, что firewall в этом случае должен использовать свой
собственный внешний интерфейсный сетевой адрес в качестве "заменяемого" или
транслируемого адреса для всех систем и ресурсов, которые расположены позади него.
Данное требование приводит к уменьшению гибкости данного механизма.
239
13.Графы, ориентированные и неориентированные. Эйлеров контур,
критерий его существования. Способы описания графов (матрица
инцидентности). Деревья, их свойства, каркасы. Сбалансированные
деревья, их применение. Алгоритм балансировки АВЛ-дерева.
Основные понятия
Мы часто сталкиваемся с задачами, в условиях которых заданы некоторые объекты и
между некоторыми их парами имеются определенные связи. Если объекты изобразить
точками (вершинами), а связи - линиями (ребрами), соединяющими соответствующие
пары точек, то получится рисунок, называемый графом. Историю теории графов принято
исчислять с 1736 г., когда Эйлер исследовал "задачу о кенигсберских мостах": построить в
графе циклический путь, проходящий по одному разу через каждое ребро. В середине 19го века Гамильтон заинтересовался задачей построения циклического пути, проходящего
по одному разу через каждую вершину графа1) К тому же времени относится
использование графов для анализа электрических цепей ( Кирхгоф ) и химических
молекул (Кэли). Развитие современной теории графов относится к 30-м годам 20-го
столетия. Они нашли многочисленные применения в электротехнике, электронике,
биологии, экономике, программировании и в других областях. В этой и двух следующих
лекциях мы рассмотрим основные понятия теории графов и несколько широко
используемых в различных приложениях типовых задач, таких, как представления графов,
отношение достижимости и транзитивное замыкание графа, компоненты сильной
связности ориентированного графа и его базы, деревья и их обходы, минимальные
остовные деревья, поиск в глубину и поиск кратчайших путей. Основное внимание
уделено алгоритмическим процедурам, решающим указанные задачи.
240
Приведем основные определения.
Определение 9.1. Ориентированный граф - это пара (V, E), где V - конечное множество
вершин (узлов, точек) графа, а E - некоторое множество пар вершин, т.е. подмножество
множества V × V или бинарное отношение на V. Элементы E называют ребрами (дугами,
стрелками, связями). Для ребра e= (u,v) E вершина u называется началом e, а вершина v концом e, говорят, что ребро e ведет из u в v.
Неориентированный граф G=(V, E) - это ориентированный граф, у которого для каждого
ребра (u,v) E имеется противоположное ребро (v,u) E, т.е. отношение E симметрично.
Такая пара (u,v), (v,u) называется неориентированным ребром. Для его задания можно
использовать обозначение для множества концов: {u, v}, но чаще используется указание
одной из пар в круглых скобках. Если e= (u,v) E, то вершины u и v называются
смежными в G, а ребро e и эти вершины называются инцидентными. Степенью вершины в
неориентированном графе называется число смежных с ней вершин. Вершина степени 0
называется изолированной.
В ориентированном графе полустепень исхода вершины - это число исходящих из нее
ребер, а полустепень захода - это число входящих в данную вершину ребер.
Заметим, что в ориентированном графе может быть ребро вида (u,u), называемое петлей, а
в неориентированном петель не бывает.
Пример 9.2. На рис.9.1 приведены примеры ориентированного графа G1=(V1, E1) и не
ориентированного графа G2=(V2, E2). Здесь V1={ a,b,c,d}, E1={ (a,b), (a,c), (b,b), (b,d),
(d,a)}, V2={ a,b,c,d}, E2={ (a,b), (a,c), (a,d), (b,d)}. В графе G1 ребро (b,b) является петлей,
полустепень исхода вершины a равна 2, а полустепень захода для нее равна 1. В графе G2
степень вершины a равна 3, вершин b и d - 2, вершины c - 1, а вершины e - 0, т.е. вершина
e является изолированной,
Рис. 9.1. Ориентированный граф G1 и неориентированный граф G2
Во многих приложениях с вершинами и ребрами графов связывается некоторая
дополнительная информация. Обычно она представляется с помощью функций разметки
вершин и ребер.
Определение 9.2. Размеченный граф - это ориентированный или неориентированный граф
G= (V, E), снабженный одной или двумя функциями разметки вида: l: V M и c: E L,
где M и L - множества меток вершин и ребер, соответственно.
241
Упорядоченный граф - это размеченный граф G= (V, E), в котором ребра, выходящие из
каждой вершины v V, упорядочены, т.е. помечены номерами 1, …, kv, где kv полустепень исхода v, т.е. kv =|{ w | (v,w) E}|.
В качестве множества меток ребер L часто выступают числа, задающие "веса", "длины",
"стоимости" ребер. Графы с такой разметкой часто называют взвешенными.
Во многих случаях естественно не различать графы, отличающиеся лишь именами
(порядком) вершин.
Определение 9.3. Изоморфизм графов. Два графа G1= (V1, E1) и G2= (V2, E2) называются
изоморфными, если между их вершинами существует взаимно однозначное соответствие
: V1 V2 такое, что для любой пары вершин u, v из V1 ребро (u,v) E1 ребро ( (u), (v))
E2.
Для изоморфизма размеченных графов требуется также совпадение меток
соответствующих вершин : l1(v) = l2( (v)) и/или ребер: c1((u,v)) = c2(( (u), (v)) ).
Многие приложения графов связаны с изучением путей между их вершинами.
Определение 9.4. Путь в ориентированном или неориентированном графе - это
последовательность ребер вида (v1,v2),(v2,v3), … , (vn-1,vn). Этот путь ведет из начальной
вершины v1 в конечную вершину vn и имеет длину n-1. В этом случае будем говорить, что
vn достижима из v1. Будем считать, что каждая вершина достижима сама из себя путем
длины 0. Путь можно также определять как соответствующую последовательность
вершин: (v1,v2,v3, … , vn-1,vn), где (vi,vi+1) E при i=1,2,…, n-1.
Путь назывется простым, если все ребра и все вершины на нем, кроме, быть может,
первой и последней, различны.
Циклом в ориентированном графе называется путь, в котором начальная вершина
совпадает с конечной и который содержит хотя бы одно ребро. Цикл (v1,v2, … , v_{n1},vn=v1) называется простым, если в нем нет одинаковых вершин, кроме первой и
последней, т.е. если все вершины v2, … , v_{n-1} различны.
В неориентированном графе путь (v1,v2, … , vn-1,vn=v1) называется циклом, если n 4 и все
ребра (vi, vi+1) различны.
Если в графе нет циклов, то он называется ациклическим.
Из последнего определения следует, что длина цикла в неориентированном графе не
меньше 3. Следующее утверждение непосредственно следует из определений.
Лемма 9.1. Если в графе G (ориентированном или неориентированном) имеется путь из u
в v, то в нем имеется и простой путь из u в v.
Неориентированный граф называется связным, если любая пара вершин в нем соединена
путем. При выполнении такого же условия ориентированный граф называется сильно
связным.
242
Представления графов
Из определения графа следует, что каждый граф G=(V,E) можно задать, непосредственно
перечислив его множество вершин V и множество ребер E. Однако такое представление
неудобно для решения многих задач о графах. Например, чтобы проверить наличие ребра
между двумя вершинами, придется, вообще говоря, просмотреть все множество E.
Хорошее представление, по крайней мере, должно позволить легко переходить от
вершины к ее соседу и перечислять всех ее соседей.
В этом параграфе мы рассмотрим три разных способа представления графов, которые
более эффективны при решении типичных для теории графов задач.
Матрица (таблица) смежности
Определение 9.5. Матрицей смежности ориентированного (или неориентированного)
графа G=(V,E) с n вершинами V= { v1, … , vn} называется булева матрица AG размера n × n
с элементами
Это представление позволяет легко проверять наличие ребер между заданными парами
вершин. Для поиска всех соседей, в которые ведут ребра из вершины vi, необходимо
просмотреть соответствующую ей i-ю строку матрицы AG, а чтобы найти вершины, из
которых ребра идут в vi, необходимо просмотреть ее i-ый столбец. Требуемая для AG
память - по порядку n2 битов - не может быть уменьшена для графов, у которых "много"
ребер. Но для разреженных графов с числом ребер существенно меньшим по порядку n2 в
матрице смежности много "ненужных" нулей. Для таких графов более эффективными
могут оказаться другие представления.
Матрица (таблица) инцидентности
Определение 9.6. Матрицей инцидентности ориентированного (или неориентированного)
графа G=(V,E) с n вершинами V= { v1, … , vn} и m ребрами E={e1, …, em} называется
матрица BG размера n × m с элементами
Таким образом, в матрице инцидентности BG любому ребру ej = (vi,vk) соответствует j-ый
столбец, в котором в i-ой строке стоит 1, а в k-ой - -1. Ребра-петли выделяются числом 2.
Для проверки наличия ребра между двумя вершинами vi и vk требуется просмотреть i-ю и
k-ую строки BG, поиск всех соседей вершины требует просмотра соответствующей строки.
Если m >> n, то это требует существенно больше времени, чем при использовании
матрицы смежности. Поэтому при практическом решении задач на графах матрица
инцидентности почти не используется.
243
Списки смежности
Определение 9.7. Пусть G=(V,E) - ориентированный граф, v - вершина из V. Список
смежности Lv для вершины v включает все смежные с ней вершины, т.е.
Представление графа G=(V,E) c n вершинами V= { v1, … , vn} с помощью списков
смежности состоит из списков смежности всех вершин: Lv1, Lv2, … , Lvn.
Размер этого представления сравним с суммой числа вершин и ребер графа. Оно
позволяет легко переходить по ребрам от вершины к ее соседям. В программах списки
смежности представляются списковыми структурами, которые легко реализуются во всех
языках программирования.
Пример 9.1. Рассмотрим следующий граф G=(V,E):
Он показан на рис. 9.2.
Построим для него определенные выше представления.
1.
Матрица смежности.
2.
Матрица инцидентности.
3.
Списки смежности.
244
Граф достижимости
Один из первых вопросов, возникающих при изучении графов, это вопрос о
существовании путей между заданными или всеми парами вершин. Ответом на этот
вопроc - введенное выше отношение достижимости на вершинах графа G=(V,E): вершина
w достижима из вершины v, если v = w или в G есть путь из v в w. Иначе говоря,
отношение достижимости является рефлексивным и транзитивным замыканием
отношения E. Для неориентированных графов это отношение также симметрично и,
следовательно, является отношением эквивалентности на множестве вершин V. В
неориентированном графе классы эквивалентности по отношению достижимости
называются связными компонентами. Для ориентированных графов достижимость,
вообще говоря, не должна быть симметричным отношением. Симметричной является
взаимная достижимость.
Определение 9.8. Вершины v и w ориентированного графа G=(V,E) называются взаимно
достижимыми, если в G есть путь из v в w и путь из w в v.
Ясно, что отношение взаимной достижимости является рефлексивным, симметричным и
транзитивным и, следовательно, эквивалентностью на на множестве вершин графа.
Классы эквивалентности по отношению взаимной достижимости называются
компонентами сильной связности или двусвязными компонентами графа.
Рассмотрим вначале вопрос о построении отношения достижимости. Определим для
каждого графа его граф достижимости ( называемый иногда также графом транзитивного
замыкания), ребра которого соответствуют путям исходного графа.
Определение 9.9. Пусть G=(V,E) - ориентированный граф. Граф достижимости G*=(V,E*)
для G имеет то же множество вершин V и следующее множество ребер E* ={ (u, v) | в
графе G вершина v достижима из вершины u}.
Пример 9.3. Рассмотрим граф G из примера 9.2.
Рис. 9.2. Граф G
Тогда можно проверить, что граф достижимости G* для G выглядит так (новые ребрапетли при каждой из вершин 1-5 не показаны):
Рис. 9.3. Граф G*
245
Каким образом по графу G можно построить граф G*? Один способ заключается в том,
чтобы для каждой вершины графа G определить множество достижимых из нее вершин,
последовательно добавляя в него вершины, достижимые из нее путями длины 0, 1, 2 и т.д.
Мы рассмотрим другой способ, основанный на использовании матрицы смежности AG
графа G и булевых операций. Пусть множество вершин V={v1, … , vn}. Тогда матрица AG это булева матрица размера n × n.
Ниже для сохранения сходства с обычными операциями над матрицами мы будем
использовать "арифметические" обозначения для булевых операций: через + будем
обозначать дизъюнкцию , а через · - конъюнкцию .
Обозначим через En единичную матрицу размера n × n. Положим
. Пусть
Наша процедура построения G* основана на
следующем утверждении.
Лемма 9.2. Пусть
. Тогда
Доказательство проведем индукцией по k.
Базис. При k=0 и k=1 утверждение справедливо по определению
и
.
Индукционный шаг. Пусть лемма справедлива для k. Покажем, что она остается
справедливой и для k+1. По определению
имеем:
Предположим, что в графе G из vi в vj имеется путь длины k+1. Рассмотрим кратчайший
из таких путей. Если его длина k, то по предположению индукции a_{ij}^{(k)}=1. Кроме
того, ajj(1)=1. Поэтому aij(k) ajj(1)=1 и aij(k+1)=1. Если длина кратчайшего пути из из vi в vj
равна k+1, то пусть vr - его предпоследняя вершина. Тогда из vi в vr имеется путь длины k
и по предположению индукции air(k)=1. Так как (vr,vj) E, то a_{rj}^{(1)}=1. Поэтому air(k)
arj(1)=1 и aij(k+1)=1.
Обратно, если aij(k+1)=1, то хотя бы для одного r слагаемое air(k) arj(1) в сумме равно 1. Если
это r=j, то aij(k)=1 и по индуктивному предположению в G имеется путь из vi в vj длины k.
Если же r j, то air(k)=1 и arj(1)=1. Это означает, что в G имеется путь из vi в vr длины k и
ребро (vr,vj) E. Объединив их, получаем путь из vi в vj длины k+1.
Из лемм 9.1 и 9.2 непосредственно получаем
Следствие 1. Пусть G=(V,E) - ориентированный граф с n вершинами, а G* - его граф
достижимости. Тогда A_{G*} =
. Доказательство. Из леммы 5.1 следует, что, если
246
в G имеется путь из u в v u, то в нем имеется и простой путь из u в v длины n-1. А по
лемме 5.2 все такие пути представлены в матрице
.
Таким образом процедура построения матрицы смежности AG* графа достижимости для G
сводится к возведению матрицы в степень n-1. Сделаем несколько замечаний,
позволяющих упростить эту процедуру.
1. Для возведения матрицы
в произвольную степень n достаточно выполнить
возведений в квадрат:
где k - это наименьшее число такое, что 2k n.
2.
Так как на диагонали в матрице
сохраняются в матрице
стоят единицы, то для любых i < j все единицы матрицы
, в частности, и в матрице
3. Если при вычислении элемента aij(2) матрицы
.
по стандартной формуле
обнаруживается такое r, что air = 1 и arj =1, то и вся сумма aij(2) =1. Поэтому
остальные слагаемые можно не рассматривать.
Пример 9.3. Рассмотрим в качестве примера вычисление матрицы графа достижимости
AG* для графа G, представленного на рис.9.2. В этом случае
Так как у G имеется 6 вершин, то
и
. Вычислим эту матрицу:
(последнее равенство нетрудно проверить). Таким образом,
247
Как видим, эта матрица действительно задает граф
, представленный на рис.9.3.
Взаимная достижимость, компоненты сильной связности и базы графа
По аналогии с графом достижимости определим граф сильной достижимости.
Определение 9.10. Пусть G=(V,E) - ориентированный граф. Граф сильной достижимости
G**=(V,E**) для G имеет то же множество вершин V и следующее множество ребер E** ={
(u, v) | в графе G вершины v и u взаимно достижимы}.
По матрице графа достижимости
легко построить матрицу
графа сильной
достижимости. Действительно из определений достижимости и сильной достижимости
непосредственно следует, то для всех пар (i,j), 1 i,j n, значение элемента
1 тогда и только тогда, когда оба элемента AG*(i, j) и AG*(j, i) равны 1, т.е.
По матрице
образом.
равно
можно выделить компоненты сильной связности графа G следующим
1.
Поместим в компоненту K1 вершину v1 и все такие вершины vj, что A_{G_*^*}(1,j) = 1.
2.
Пусть уже построены компоненты K1, …, Ki и vk - это вершина с минимальным номером, еще не
попавшая в компоненты. Тогда поместим в компоненту K_{i+1} вершину vk и все такие вершины vj,
3.
что A_{G_*^*}(k,j) = 1.
Повторяем шаг (2) до тех пор, пока все вершины не будут распределены по компонентам.
В нашем примере для графа G на рис.2 по матрице
графа сильной достижимости
получаем следующую матрицу
Используя описанную выше процедуру, находим, что вершины графа G разбиваются на 4
компоненты сильной связности: K1= {v1, v2, v3}, \ K2 ={ v4}, \ K3 ={ v5}, \ K4 ={ v6}. На
множестве компонент сильной связности также определим отношение достижимости.
248
Определение 9.11. Пусть K и K' - компоненты сильной связности графа G. Компонента K
достижима из компоненты K^\prime, если K= K' или существуют такие две вершины u K
и v K', что u достижима из v. K строго достижима из K^\prime, если K K' и K
достижима из K'. Компонента K называется минимальной, если она не является строго
достижимой ни из какой компоненты.
Так как все вершины в одной компоненте взаимно достижимы, то нетрудно понять, что
отношения достижимости и строгой достижимости на компонентах не зависят от выбора
вершин u K и v K'.
Из определения легко выводится следующая характеристика строгой достижимости.
Лемма 9.3. Отношение строгой достижимости является отношением частичного порядка,
т.е. оно антирефлексивно, антисимметрично и транзитивно.
Это отношение можно представлять в виде ориентированного графа, вершинами которого
являются компоненты, а ребро (K', K) означает, что K строго достижима из K'. На рис. 9.4
показан этот граф компонент для рассматриваемого выше графа G.
Рис. 9.4. Граф отношения достижимости на компонентах G
В данном случае имеется одна минимальная компонента K2.
Во многих приложениях ориентированный граф представляет собой сеть распространения
некоторого ресурса: продукта, товара, информации и т.п. В таких случаях естественно
возникает задача поиска минимального числа таких точек (вершин), из которых этот
ресурс может быть доставлен в любую точку сети.
Определение 9.12. Пусть G=(V,E) - ориентированный граф. Подмножество вершин W V
называется порождающим, если из вершин W можно достичь любую вершину графа.
Подмножество вершин W V называется базой графа, если оно является порождающим,
но никакое его собственное подмножество порождающим не является.
Следующая теорема позволяет эффективно находить все базы графа.
Теорема 9.1. Пусть G=(V,E) - ориентированный граф. Подмножество вершин W V
является базой G тогда и только тогда, когда содержит по одной вершине из каждой
минимальной компоненты сильной связности G и не содержит никаких других вершин.
Доказательство Заметим вначале, что каждая вершина графа достижима из вершины,
принадлежащей некоторой минимальной компоненте. Поэтому множество вершин W,
содержащих по одной вершине из каждой минимальной компоненты, является
порождающим а при удалении из него любой вершины перестает быть таковым, так как
249
вершины из соответствующей минимальной компоненты становятся недостижимы.
Поэтому W является базой.
Обратно, если W является базой, то оно обязано включать хотя бы по одной вершине из
каждой минимальной компоненты, иначе вершины такой минимальной компоненты
окажутся недоступны. Никаких других вершин W содержать не может, так как каждая из
них достижима из уже включенных вершин.
Из этой теоремы вытекает следующая процедура построения одной или перечисления
всех баз графа G.
1.
Найти все компоненты сильной связности G.
2.
Определить порядок на них и выделить минимальные относительно этого порядка компоненты.
3.
Породить одну или все базы графа, выбирая по одной вершине из каждой минимальной
компоненты.
Пример 9.5. Определим все базы ориентированного графа G, показанного на рис.9.5.
Рис. 9.5. Граф G
На первом этапе находим компоненты сильной связности G:
На втором этапе строим граф строгой достижимости на этих компонентах.
Рис. 9.6. Граф отношения достижимости на компонентах G
Определяем минимальные компоненты: K2 = { b }, K4 ={ d,e, f, g} и K7= { r}.
Наконец перечисляем все четыре базы G: B1= { b, d, r}, B2= { b, e, r}, B3= { b, f, r} и B1= {
b, g, r}.
250
Задачи
Задача 9.1. Докажите, что сумма степеней всех вершин произвольного ориентированного
графа четна.
У этой задачи имеется популярная интерпретация: доказать, что общее число
рукопожатий, которыми обменялись люди, пришедшие на вечеринку, всегда четно.
Задача 9.2. Перечислите все неизоморфные неориентированные графы, у которых не
более четырех вершин.
Задача 9.3. Докажите, что неориентированный связный граф остается связным после
удаления некоторого ребра ↔ это ребро принадлежит некоторому циклу.
Задача 9.4. Докажите, что неориентированный связный граф с n вершинами

содержит не менее n-1 ребер,

если содержит больше n-1 ребер, то имеет, по крайней мере, хотя бы один цикл.
Задача 9.5. Докажите, что в любой группе из 6 человек есть трое попарно знакомых или
трое попарно незнакомых.
Задача 9.6. Докажите, что неориентированный граф G=(V,E) связен ↔ для каждого
разбиения V= V1 V2 с непустыми V1 и V2 существует ребро, соединяющее V1 с V2.
Задача 9.7. Докажите, что, если в неориентированном графе имеется ровно две вершины
нечетной степени, то они связаны путем.
Задача 9.8. Пусть G=(V,E) неориентированный граф с |E| < |V|-1. Докажите, что тогда G
несвязный граф.
Задача 9.9. Докажите, что в связном неориентированном графе любые два простых пути
максимальной длины имеют общую вершину.
Задача 9.10. Пусть неориентированный граф без петель G=(V,E) имеет k компонент
связности. Доказать, что тогда
Задача 9.11. Определите, что представляет из себя граф достижимости для

графа с n вершинами и пустым множеством ребер;

графа с n вершинами: V= {v1,… , vn}, ребра которого образуют цикл:
Задача 9.12. Вычислите матрицу графа достижимости
для графа
и постройте соответствующий ей граф достижимости. Найдите все базы графа G.
251
Задача 9.13. Построить для заданного на рис. 9.7 ориентированного графа G1=(V,E) его
матрицу смежности AG1, матрицу инцидентности BG1 и списки смежности. Вычислить
матрицу достижимости AG1* и построить соответствующий граф достижимости G1*.
Рис. 9.7.
Неориентированные и ориентированные деревья
Деревья являются одним из интереснейших классов графов, используемых для
представления различного рода иерахических структур.
Определение 10.1. Неориентированный граф называется деревом, если он связный и в
нем нет циклов.
Определение 10.2. Ориентированный граф G=(V,E) называется (ориентированным)
деревом, если
1.
в нем есть одна вершина r E, в которую не входят ребра; она называется корнем дерева;
2.
в каждую из остальных вершин входит ровно по одному ребру;
3.
все вершины достижимы из корня.
На рис. 10.1 показаны примеры неориентированного дерева G1 и ориентированного дерева
G2. Обратите внимание на то, что дерево G2 получено из G1 с помощью выбора вершины c
в качестве корня и ориентации всех ребер в направлении "от корня".
Рис. 10.1. Неориентированное и ориентированное деревья
Это не случайно. Докажите самостоятельно следующее утверждение о связи между
неориентированными и ориентированными деревьями.
252
Лемма 10.1. Если в любом неориентированном дереве G=(V,E) выбрать произвольную
вершину v V в качестве корня и сориентировать все ребра в направлении "от корня", т.е.
сделать v началом всех инцидентных ей ребер, вершины, смежные с v - началами всех
инцидентных им еще не сориентированных ребер и т.д., то полученый в результате
ориентированный граф G' будет ориентированным деревом.
Неориентированные и ориентированные деревья имеют много эквивалентных
характеристик.
Теорема 10.1.Пусть G=(V,E) - неориентированный граф. Тогда следующие условия
эквивалентны.
1.
G является деревом.
2.
Для любых двух вершин в G имеется единственный соединяющий их путь.
3.
G связен, но при удалении из E любого ребра перестает быть связным.
4.
G связен и |E| = |V| -1.
5.
G ациклический и |E| = |V| -1.
6.
G ациклический, но добавление любого ребра к E порождает цикл.
Доказательство (1) (2): Если бы в G некоторые две вершины соединялись двумя
путями, то, очевидно, в G имеелся бы цикл. Но это противоречит определению дерева в
(1).
(2) (3): Если G связен, но при удалении некоторого ребра (u,v) E не теряет связности, то
между u и v имеется путь, не содержащий это ребро. Но тогда в G имеется не менее двух
путей, соединяющих u и v, что противоречит условию (2).
(3)
(4): Предоставляется читателю (см. задачу 9.4).
(4) (5): Если G содержит цикл и является связным, то при удалении любого ребра из
цикла связность не должна нарушиться, но ребер останется |E|= V -2, а по задаче 9.4(а) в
связном графе должно быть не менее V -1 ребер. Полученное противоречие показывает,
что циклов в G нет и выполнено условие (5).
(5) (6): Предположим, что добавление ребра (u,v) к E не привело к появлению цикла.
Тогда в G вершины u и v находятся в разных компонентах связности. Так как |E|= V -1, то
в одной из этих компонент, пусть это (V1,E1), число ребер и число вершин совпадают:
|E1|=|V1|. Но тогда в ней имеется цикл (см. задачу 9.4 (б) ), что противоречит ацикличности
G.
(6) (1): Если бы G не был связным, то нашлись бы две вершины u и v из разных
компонент связности. Тогда добавление ребра (u,v) к E не привелобы к появлению цикла,
что противоречит (6). Следовательно, G связен и является деревом.
Для ориентированных деревьев часто удобно использовать следующее индуктивное
определение.
253
Определение 10.3. Определим по индукции класс ориентированных графов
,
называемых деревьями. Одновременно для каждого из них определим выделенную
вершину - корень.
1.
Граф T0=(V,E), с единственной вершиной V={ v} и пустым множеством ребер E= является
деревом (входит в
). Вершина v называется корнем этого дерева.
2.
Пусть графы T1=(V1,E1), … , Tk= (Vk, Ek) с корнями r1 V1, …, rk Vk принадлежат
вершина, т.е.
. Тогда классу
, где
, а r0 - новая
принадлежит также следующий граф
,
. Корнем этого дерева является вершина
3.
Других графов в классе
.\\
нет.
Рис. 10.2 иллюстрирует это определение.
Рис. 10.2. Индуктивное определение ориентированных деревьев
Теорема 10.2. Определения ориентированных деревьев 10.2 и 10.3 эквивалентны.
Доказательство Пусть граф G=(V,E) удовлетворяет условиям определения 10.2.
Покажем индукцией по числу вершин |V|, что
.
Если |V|=1, то единственная вершина v V является по свойству (1) корнем дерева, т.е. в
этом графе ребер нет: E = . Тогда
.
Предположим, что всякий граф с n вершинами, удовлетворяющий определению 10.2
входит в . Пусть граф G=(V,E) с (n+1)-й вершиной удовлетворяет условиям
определения 10.2. По условию (1) в нем имеется вершина-корень r0. Пусть из r0 выходит k
ребер и они ведут в вершины r1, … , rk(k 1). Обозначим через Gi,(i=1, …, k) граф,
включающий вершины Vi ={ v V|v \textit{ достижима из }ri } и соединяющие их ребра Ei
E. Легко понять, что Gi удовлетворяет условиям условиям определения 10.2.
Действительно, в ri не входят ребра, т.е. эта вершина - корень Gi . В каждую из остальных
вершин из Vi входит по одному ребру как и в G . Если v Vi, то она достижима из корня ri
по определению графа Gi. Так как |Vi| n, то по индуктивному предположению
.
254
Тогда граф G получен по индуктивному правилу (2) определения 10.3 из деревьев G1, …,
Gk и поэтому принадлежит классу .
⇐ Если некоторый граф G=(V,E) входит в класс
, то выполнение условий (1)-(3)
определения 10.2 для него легко установить индукцией по определению 10.2.
Предоставляем это читателю в качестве упражнения.
С ориентированными деревьями связана богатая терминология, пришедшая из двух
источников: ботаники и области семейных отношений.
Корень - это единственная вершина, в которую не входят ребра, листья - это вершины, из
которых не выходят ребра. Путь из корня в лист называется ветвью дерева. Высота дерева
- это максимальная из длин его ветвей. Глубина вершины - это длина пути из корня в эту
вершину. Для вершины v V, подграф дерева T=(V,E), включающий все достижимые из v
вершины и соединяющие их ребра из E, образует поддерево Tv дерева T с корнем v ( см.
задачу 10.3). Высота вершины v - это высота дерева Tv. Граф, являющийся объединением
нескольких непересекающихся деревьев, называется лесом.
Если из вершины v ведет ребро в вершину w, то v называется отцом w, а w - сыном v (в
последнее время в ангоязычной литературе употребляется асексульная пара терминов:
родитель - ребенок). Из определения дерева непосредственно следует, что у каждой
вершины кроме корня имеется единственный отец. Если из вершины v ведет путь в
вершину w, то v называется предком w, а w - потомком v. Вершины, у которых общий
отец, называются братьями или сестрами.
Выделим еще один класс графов, обобщающий ориентированные деревья ориентированные ациклические. Два вида таких размеченных графов будут использованы
далее для представления булевых функций. У этих графов может быть несколько корней вершин, в которые не входят ребра, и в каждую вершину может входить несколько ребер,
а не одно, как у деревьев.
Деревья и формулы (выражения)
Напомним, что в главе 2 было введено общее понятие формулы над системой функций
(определение 3.2), которое применимо для произвольных функций, а не только
булевых. В главе 4 аналогичные синтаксические объекты для логики предикатов названы
термами (определение 7.1), а в языках программирования такие конструкции часто
называются выражениями.
Итак, пусть формула над множеством функций , множеством констант C и множеством
переменных Var определяется индуктивно по следующим правилам.

Переменная из Var есть формула.

Константа из C есть формула.

Если g1, …, gk - формулы, а f(k) - k-местная функция из F, то f(g1, …, gk) - это формула.
Обозначим множество всех таких формул через
255
.
Рассмотрим класс упорядоченных размеченных деревьев
, листья которых
помечены элементами из (C Var), а внутренние вершины - функциями из F, причем, если
вершина помечена символом k-местной функции из F, то у нее имеется k сыновей.
Рис. 10.3. Индуктивное определение связи между формулами и деревьями
Предложение 10.1. Между множеством формул\
и множеством деревьев
имеется взаимно однозначное соответствие.
Доказательство Это соответствие легко устанавливается индукцией по определениям
формул и деревьев. Оно показано выше на рис. 10.3.
Пример 10.2. Рассмотрим, например, класс обычных арифметических формул над
множеством функций F = { +, -, *, : }, целочисленных констант C = {0, 1, 2,… } и
переменных Var = {x,y,z, … }. Пусть формула Φ = +(*(5, +(x,7)),(:(y,+(x, 7))) (ее обычное
представление Φ = 5*(x+7) + y :(x + 7) )
Тогда в соответствии с предложением 10.1 эта формула представляется деревом TΦ,
изображенном на рис. 10.4.
Рис. 10.4. Дерево TΦ
На этом рисунке не указаны явно номера ребер, выходящих из внутренних вершин дерева,
которые идентифицируют порядок аргументов операций. Предполагается, что для
коммутативных операций +, * это несущественно, а для некоммутативных, таких, как :,
первый аргумент расположен левее второго.
256
Заметим, что у деревьев, представляющих арифметические или логические (булевские)
формулы, внутренние вершины имеют не более 2-х сыновей. Такие деревья образуют
важный подкласс ориентированных деревев, называемых бинарными или двоичными.
Определение 10.4. Ориентированное дерево называется бинарным или двоичным, если у
каждой его внутренней вершины имеется не более двух сыновей, причем ребра, ведущие к
ним помечены двумя разными метками (обычно используются метки из пар: "левый" "правый", 0 - 1, + - - и т.п.)
Бинарное дерево называется полным, если у каждой его внутренней вершины имеется два
сына и все его ветви имеют одинаковую длину.
Ориентированные ациклические графы также используются для представления формул.
Они получаются из соответствующих деревьев при склеивании вершин, представляющих
одинаковые подформулы. Для формулы Φ = 5*(x+7) + y :(x + 7) такой граф GΦ получается
при склеивании вершин v5 и v7 дерева TΦ, представляющих подформулу (x+7).
Рис. 10.5. Ациклический граф GΦ
На рис.10.5 явно указаны номера ребер, выходящих из вершины v3, которые определяют
порядок аргументов приписанной этой вершине операции :. Ясно, что при отсутствии
такого указания и использовании порядка " по умолчанию" - первый аргумент слева - граф
представлял бы другое выражение.
Обходы деревьев
Часто при обработке представленной в дереве информации требуется обойти некоторым
регулярным способом все его вершины. Имеется два естественных стандартных способа
обхода деревьев. Каждый из них позволяет линейно упорядочить вершины дерева и тем
самым представить его "двумерную структуру" в виде линейной последовательности
вершин.
Прямой (префиксный) обход дерева основан на принципе: "сначала родитель, затем дети".
Определим индукцией по построению дерева T в определении 10.3 его прямое
представление ПР(T) следующим образом.
257
1.
Если T0=( {v}, ), то ПР(T0)= v.
2.
Если T получено из деревьев T1, …, Tk и нового корня r0 по пункту (2) определения 10.3 то ПР(T)=
r0\, ПР(T1)… ПР(Tk).
Обратный (суффиксный) обход дерева основан на противоположном принципе: "сначала
дети , затем родитель". Вот его индуктивное определение.
1.
1) Если T0=( {v}, ), то ОБР(T0)= v.
2.
2) Если T получено из деревьев T1, …, Tk и нового корня r0 по пункту (2) определения 10.3, то
ОБР(T)= ОБР(T1)… ОБР(Tk)\, r0.
Для бинарных деревьев, внутренние вершины которых имеют не более 2-х сыновей,
помеченных как "левый" и "правый", можно естественно определить еще один способ
обхода - инфиксный (внутренний) обход, основанный на принципе: "сначала левый сын,
затем родитель, а затем правый сын". Он определяется следующим образом.
1.
Если T0=( {v}, ), то ИНФ(T0)= v.
2.
Если T получено из деревьев T1, T2 и нового корня r0 по пункту (2) определения 10.3, то ИНФ(T)=
ИНФ(T1) r0 ИНФ(T2)
(Если одно из деревьев T1, T2 пусто, то соответствующее ему инфиксное представление
тоже пусто).
Пример 10.2. Построим в соответствии с этими определениями три разных обхода
бинарного дерева TΦ, изображенного на рис. 10.4 (в скобках после вершины указана ее
метка).
Для упорядоченного размеченного дерева T из класса
по любому из
указанных обходов ПР(T), ОБР(T) и, если дерево бинарное, - ИНФ(T) можно однозначно
восстановить само дерево T (см. задачу 10,6).
Замечание. Для вычислительных приложений особенно интересен обратный обход,
иногда называемый обратной польской записью. По нему компилятор легко строит
программу вычисления соответствующего выражения.
258
14.Динамическая маршрутизация в сети Интернет. Обзор протоколов
маршрутизации.
2.9.2. Динамическая маршрутизация
Прежде чем вникать в подробности и особенности динамической маршрутизации обратим
внимание на двухуровневую модель, в рамках которой рассматривается все множество
машин Internet. В рамках этой модели весь Internet рассматривают как множество
автономных систем (autonomous system - AS). Автономная система - это множество
компьютеров, которые образуют довольно плотное сообщество, где существует
множество маршрутов между двумя компьютерами, принадлежащими этому сообществу.
В рамках этого сообщества можно говорить об оптимизации маршрутов с целью
достижения максимальной скорости передачи информации. В противоположность этому
плотному конгломерату, автономные системы связаны между собой не так тесно как
259
компьютеры внутри автономной системы. При этом и выбор маршрута из одной
автономной системы может основываться не на скорости обмена информацией, а
надежности, безотказности и т.п.
Рис. 2.24. Схема взаимодействия автономных систем
Сама идеология автономных систем возникла в тот период, когда ARPANET представляла
иерархическую систему. В то время было ядро системы, к которому подключались
внешние автономные системы. Информация из одной автономной системы в другую
могла попасть только через маршрутизаторы ядра. Такая структура до сих пор
сохраняется в MILNET.
На рисунке 2.24 автономные системы связаны только одной линией связи, что больше
соответствует тому, как российский сектор подключен к Internet. В классических
публикациях по Internet взаимодействие автономных частей чаще обозначают
пересекающимися кругами, подчеркивая тот факт, что маршрутов из одной автономной
системы в другую может быть несколько.
Обсуждение этой модели Internet необходимо только для того, чтобы объяснить наличие
двух типов протоколов динамической маршрутизации: внешних и внутренних.
Внешние протоколы служат для обмена информацией о маршрутах между автономными
системами.
Внутренние протоколы служат для обмена информацией о маршрутах внутри
автономной системы.
В реальной практике построения локальных сетей, корпоративных сетей и их
подключения к провайдерам нужно знать, главным образом, только внутренние
протоколы динамической маршрутизации. Внешние протоколы динамической
маршрутизации необходимы только тогда, когда следует построить закрытую большую
систему, которая с внешним миром будет соединена только небольшим числом
защищенных каналов данных.
260
К внешним протоколам относятся Exterior Gateway Protocol (EGP) и .
EGP предназначен для анонсирования сетей, которые доступны для автономных систем за
пределами данной автономной системы. По данному протоколу шлюз одной AS передает
шлюзу другой AS информацию о сетях из которых состоит его AS. EGP не используется
для оптимизации маршрутов. Считается, что этим должны заниматься протоколы
внутренней маршрутизации.
BGP - это другой протокол внешней маршрутизации, который появился позже EGP. В
своих сообщениях он уже позволяет указать различные веса для маршрутов, и, таким
образом, способствовать выбору наилучшего маршрута. Однако, назначение этих весов не
определяется какими-то независимыми факторами типа времени доступа к ресурсу или
числом шлюзов на пути к ресурсу. Предпочтения устанавливаются администратором и
потому иногда такую маршрутизацию называют политической маршрутизацией,
подразумевая, что она отражает техническую политику администрации данной
автономной системы при доступе из других автономных систем к ее информационным
ресурсам. Протокол BGP используют практически все российские крупные IPпровайдеры, например крупные узлы сети Relcom.
К внутренним протоколам относятся протоколы Routing Information Protocol (RIP),
HELLO, Intermediate System to Intermediate System (ISIS), Shortest Path First (SPF) и Open
Shortest Path First (OSPF).
Протокол RIP (Routing Information Protocol) предназначен для автоматического
обновления таблицы маршрутов. При этом используется информация о состоянии сети,
которая рассылается маршрутизаторами (routers). В соответствии с протоколом RIP любая
машина может быть маршрутизатором. При этом, все маршрутизаторы делятся на
активные и пассивные. Активные маршрутизаторы сообщают о маршрутах, которые они
поддерживают в сети. Пассивные маршрутизаторы читают эти широковещательные
сообщения и исправляют свои таблицы маршрутов, но сами при этом информации в сеть
не предоставляют. Обычно в качестве активных маршрутизаторов выступают шлюзы, а в
качестве пассивных - обычные машины (hosts).
В основу алгоритма маршрутизации по протоколу RIP положена простая идея: чем
больше шлюзов надо пройти пакету, тем больше времени требуется для прохождения
маршрута. При обмене сообщениями маршрутизаторы сообщают в сеть IP-номер сети и
число "прыжков" (hops), которое надо совершить, пользуясь данным маршрутом. Надо
сразу заметить, что такой алгоритм справедлив только для сетей, которые имеют
одинаковую скорость передачи по любому сегменту сети. Часто в реальной жизни
оказывается, что гораздо выгоднее воспользоваться оптоволокном с 3-мя шлюзами, чем
одним медленным коммутируемым телефонным каналом.
Другая идея, которая призвана решить проблемы RIP, - это учет не числа hop'ов, а учет
времени отклика. На этом принципе построен, например, протокол OSPF. Кроме этого
OSPF реализует еще и идею лавинной маршрутизации. В RIP каждый маршрутизатор
обменивается информацией только с соседями. В результате, информации о потере
маршрута в сети, отстоящей на несколько hop'ов от локальной сети, будет получена с
опозданием. Лавинная маршрутизация позволяет решить эту проблему за счет
оповещения всех известных шлюзов об изменениях локального участка сети.
261
К сожалению, многовариантную маршрутизацию поддерживает не очень много систем.
Различные клоны Unix и NT, главным образом ориентированы на протокол RIP.
Достаточно посмотреть на программное обеспечение динамической маршрутизации,
чтобы убедится в этом. Программа routed поддерживает только RIP, программа gated
поддерживает RIP, HELLO, OSPF, EGP и BGP, в Windows NT поддерживается только RIP.
Поэтому мы рассмотрим возможность динамического управления таблицей маршрутов
только по протоколу RIP.
15.Понятие
вычислительной
сложности
алгоритма,
О-нотация.
Эмпирические оценки эффективности алгоритмов на примере
алгоритмов сортировки.
Что же такое сложность алгоритма? На самом деле, понять это интуитивно довольно легко.
Алгоритмическая сложность — это зависимость времени исполнения алгоритма от длины
входных
данных.
То есть, конечно же очевидно, что если нам нужно что-то найти во входных данных или что-то
переставить местами, то чем больше количество информации на входе, тем больше времени
262
понадобится,
чтобы
получить
результат.
"Время" здесь величина довольно абстрактная. Естественно, она (эта величина) должна быть
универсальной, и не зависеть от типа и производительности компьютера или иного устройства, а
также от других частностей. Измеряется она числом элементарных шагов. Сейчас поясню, что это
такое.
Думаю, каждый согласится с тем, что любую (и не только вычислительную) задачу можно решать
миллионом способов, но, как правило, лишь один (реже несколько) из них будут оптимальными.
Вот, например, возьмем задачу, которую можно решить полным перебором (пример не мой):
нахождение фамилии в телефонном справочнике. Можно просматривать страницу за страницей,
пока
мы
наконец
не
наткнемся
на
того,
кого
искали.
Однако же мало кто будет искать именно так. Нас спасает то, что фамилии упорядочены по
алфавиту. Достаточно открыть справочник приблизительно посередине, и сразу станет ясно, в какой
из двух половин надо искать. Таким образом, область поиска сразу сокращается вдвое. Если мы
нужную половину откроем опять посередине, то на втором шаге нам останется лишь четверть
справочника. Применяя такой нехитрый метод, мы двигаемся семимильными шагами.
(Кстати, так будет действовать "безмозглый компьютер", если его запрограммировать должным
образом. Казалось бы, человеку сделать это быстрее, потому что он представляет, в начале алфавита
нужная ему буква, в середине, или в конце, и поэтому он в состоянии открыть справочник сразу
более точно, а не начинать с середины. Но, как оказывается, таким методом отбрасываются как
максимум два-три (если повезет) первых шага, а дальше приходится использовать всё тот же
алгоритм).
Таким образом, задача поиска фамилии в телефонном справочнике (в самом худшем случае)
повторится столько раз, сколько мы можем делить число страниц пополам.
Т.е. если справочник у нас имеет n страниц, то в худшем случае пополам придется делить
2•2•...•2=2m(>=n) раз, где m — такая степень двойки, что 2m — минимальное число такого вида,
превосходящее
n,
или
равное
ему.
Люди, близкие к математике или информатике фыркнут и скажут, что уже давно надо было перейти
к
логарифмам.
Сейчас
и
перейду.
То самое искомое число m как раз и будет логарифмом по основанию 2 от длины входной
информации
n.
Т.е.
log2
n
=
m
Таким образом, чтобы пролистать справочник из тысячи страниц, нам нужно раскрыть его:
log2
1000
≈
10
раз.
(Потому
что
210=1024)
Если, предположим, наш справочник вдвое толще, и составляет более 2000 страниц, то нам
придется
его
открыть
всего
лишь
на
один
раз
больше!
Если страниц у нас будет сто тысяч, понадобится всего лишь около 17 открываний!
Аналогично устроены некоторые численные методы! Самый похожий и один из самых
распространенных (по крайней мере, в учебных целях): деление отрезка пополам.
Этот алгоритм один в один повторяет наши действия со справочником. Представьте себе, что нам
нужно приблизительно найти корень алгебраического уравнения. То есть такое значение х, при
котором f(x)=0, где f(x) и есть наше уравнение (какое-нибудь суперсложное, нерешаемое
аналитически) Нам достаточно найти два значения х1 и х2, для которых f(x) имеет разные знаки.
Предположим, f(x1)>0, а f(x2)<0. Ясно, что между ними лежит по крайней мере одно (хотя может
быть и три и пять, и любое нечетное число) искомое нами значение х0, при котором и достигается
равенство: f(x0)=0. Правильно? Нельзя же из плюса перескочить в минус, не побывав в нуле, при
условии, конечно, что функция, описываемая уравнением, непрерывна на рассматриваемом отрезке!
И вот, это самое х0 мы и будем искать как фамилию в справочнике.
Поделим отрезок пополам и найдем знак нашего уравнения в серединной точке отрезка х3. Если
f(x3)>0 (т.е. знак совпал со знаком f(x1)), то на половине отрезка [x1, x3] перехода через ноль не
произошло. Таким образом, область поиска сократилась вдвое: остался отрезок [x3, x2], который на
следующем шаге тоже поделится пополам. И так далее. Таким образом, за логарифмическое время
можно
найти
корень
уравнения
с
любой
наперед
заданной
точностью.
Есть еще немного отличающийся (или много (или вообще не отличающийся) — пишу по памяти, а
263
она имеет тенденцию привирать) метод пристрелки. Называется он так потому, что имитирует
пристрелку орудия к цели. Мы не знаем корня, и в первый раз стреляем очень приблизительно. Но
как только мы обстреляли корень с двух сторон: f(x)<0 — недолет, f(x)>0 — перелет, то каждый раз
мы вводим в прицел коррективы и стреляем точнее, пока не попадем в сколь угодно малую
окрестность
корня.
Из сказанного видно, что множество абсолютно разных задач можно решать одинаковыми или
очень
похожими
методами.
Таким
образом,
пришли
к
самому
первому
определению.
Множество вычислительных проблем, для которых существуют алгоритмы, схожие по сложности,
называется
классом
сложности.
Приведу
еще
один
пример
из
Википедии.
Предположим,
нам
надо
почистить
ковер.
Время на его чистку пропорционально площади ковра. Если ковер увеличится вдвое, — время
чистки тоже должно возрасти ровно вдвое. Увеличим мы ковер в сто тысяч раз — время чистки
возрастет
ровно
во
столько
же!
В
сто
тысяч
раз.
Тогда как метод половинного деления при увеличении входных данных в сто тысяч раз дает всего
лишь
семнадцатикратное
увеличение
времени
их
обработки.
Таким
образом,
это
задачи
из
разных
классов
сложности.
Любой полный перебор (например, нахождение минимального или максимального элемента
произвольной последовательности чисел, или вычисление их суммы (произведения)), дает нам
сложность ковра)))
Множество вычислительных проблем, для которых существуют алгоритмы, схожие по сложности,
называется
классом
сложности.
Здесь можно заметить, что для одной и той же проблемы могут существовать алгоритмы, различные
по сложности. В таком случае данное определение становится дуальным, что не есть хорошо
(корректнее
говорить
о
сложности
алгоритма,
а
не
задачи).
Вообще говоря, сложность алгоритма принято обозначать как О (читается "О-большое"), это так
называемая
О-нотация.
Наиболее часто встречающиеся классы сложности в зависимости от числа входных данных N
таковы (в порядке нарастания сложности, т.е. увеличения времени работы алгоритма, при
стремлении
N
к
бесконечности):
О(1) - количество шагов алгоритма не зависит от количества входных данных. Обычно это
алгоритмы, использующие определённую часть данных входного потока и игнорирующие все
остальные данные. Например, Чистка 1квадратного метра ковра вне зависимости от его размеров.
О(log N) - логарифмический алгоритм. Главным образом, в эту категорию попадают алгоритмы
поиска
О(N) - алгоритм линейной сложности. Например, просмотр обложки каждой поступающей книги то
есть
для
каждого
входного
объекта
выполняется
только
одно
действие
О(N log N) - специального названия не имеет. Такую сложность имеют алгоритмы быстрой
сортировки,
сортировки
слиянием
и
"кучной"
сортировки.
O(N2) - квадратичные алгоритмы. В основном, все простейшие алгоритмы сортировки
O(Nx)
полиномиальные
алгоритмы
O(XN)
экспоненциальные
алгоритмы
О(N!) - факториальные алгоритмы, в основном, используются в комбинаторике для определения
числа
сочетаний,
перестановок.
Конечно, если посмотреть на вышеприведённые записи, на первый взгляд, О(1) - самый лучший
алгоритм. Но это не всегда так! Всё определяется числом входных данных. Константное время,
требуемое для исполнения алгоритма сложности О(1) может оказаться во много раз больше, чем
даже О(N!) при малом числе входных данных. Хотя, естественно, ничто не сравнится с О(1) при N,
стремящемся
к
бесконечности.
Поэтому при программировании алгоритмов требуется оценить как трудоёмкость решения (более
быстрые алгоритмы, как правило, требуют большей оптимизации кода, иногда менее устойчивы и
уж как пить дать существенно тяжелее для проверки), так и класс задач, т.е. оценить максимальный
объём входных данных - и уже исходить из полученных соотношений. Следует помнить, что
выражение "Цель оправдывает средства" далеко не всегда применимо при реализации алгоритмов
264
нализ алгоритмов. Критерий эффективности.
Структуры данных в С++. У.Топп, У.Форд
Алгоритм, в конечном счете, выполняется в машинной системе со специфическим набором
команд и периферийными устройствами. Для отдельной системы какой-либо алгоритм может
быть разработан для полного использования преимуществ данного компьютера и поэтому
достигает высокой степени эффективности. Критерий, называемый системной эффективностью
(sys-tem efficiency), сравнивает скорость выполнения двух или более алгоритмов, которые
разработаны для выполнения одной и той же задачи. Выполняя эти алгоритмы на одном
компьютере с одними и теми же наборами данных, мы можем определить относительное время,
используя внутренние системные часы. Оценка времени становится мерой системной
эффективности для каждого из алгоритмов.
При работе с некоторыми алгоритмами могут стать проблемой ограничения памяти. Процесс
может потребовать большого временного хранения, ограничивающего размер первоначального
набора данных, или вызвать требующую времени дисковую подкачку. Эффективность
пространства (space efficiency) — это мера относительного количества внутренней памяти,
используемой каким-либо алгоритмом. Она может указать, какого типа компьютер способен
выполнять этот алгоритм и полную системную эффективность алгоритма. Вследствие
увеличения объема памяти в новых системах, анализ пространственной эффективности
становится менее важным.
Третий критерий эффективности рассматривает внутреннюю структуру алгоритма, анализируя
его разработку, включая количество тестов сравнения итераций и операторов присваивания,
используемых алгоритмом. Эти типы измерений являются независимыми от какой-либо отдельной
машинной системы. Критерий измеряет вычислительную сложность алгоритма относительно n,
количества элементов данных в коллекции. Мы называем эти критерии вычислительной
эффективностью (computational efficiency) алгоритма и разрабатываем нотацию Big-О для
построения измерений, являющихся функциями n.
Нотация Big-O. Интуитивно вычислительная эффективность алгоритма измеряется
количеством обрабатываемых им данных для определения ключевых операций алгоритма.
Эти операции могут зависеть от типа коллега данных, количества данных и их начального
упорядочения.
Нахождение минимального элемента в массиве — это простой алгоритм, основная операция
которого включает сравнение элементов данных. Для массива с n элементами алгоритм требует
n — 1 сравнений и мера эффективности пропорциональна n. Другие алгоритмы являются более
сложными. Для обменной сортировки, обработка данных включает серию сравнений в каждом
прохождении. Если А — это массив из n элементов, то обменная сортировка выполняет n — 1
проходов. На рис. показан этот алгоритм.
265
266
Проход 1: Сравнение n - 1 — элементов А[1] . . . А[n — 1] с А[0] и, если необходимо, такой обмен
элементов, чтобы А[0] всегда имел наименьшее значение.
Проход 2: Сравнение n -2 — элементов А[2] . . . А[n — 1] с А[1].
Проход i: Для общего случая, сравнение n-i — элементов А[n] . . . A[n — i] с A[i — 1].
Общее число сравнений в сортировке обмена задается арифметическим рядом f(n) от 1 до n-1:
f(n) = (n — 1) + (n — 2) + . . . + 3 + 2 + 1 = n(n — 1)/2
Количество сравнений зависит от n2.
Для обработки данных общих классов коллекций таких, как последовательные списки и
деревья, мы используем сравнения в качестве меры эффективности алгоритмов.
Алгоритмы зависят также от начального упорядочения данных. Например, нахождение
минимального значения в массиве значительно упрощается, если мы знаем, что эти данные
упорядочены. В возрастающем списке минимальное значение занимает первую позицию. Это
значение находится в конце убывающего списка. В этих случаях вычислительная сложность
включает единственный доступ к данным, который может быть выполнен в постоянную единицу
времени. В примере с сортировкой, если список упорядочен, не требуется никакого обмена. Это
условие наилучшего случая, и оно представляет наиболее эффективное выполнение алгоритма.
Однако, если список отсортирован в обратном порядке, каждое сравнение приводит к обмену. Это
условие наихудшего случая для сортировки. Общий случай предполагает некоторое промежуточное
количество обменов в зависимости от порядка данных в списке. Для алгоритмов поиска и
сортировки в классе коллекций мы используем количество сравнений как доминантное действие и
меру вычислительной эффективности. Наш анализ определяет также начальное упорядочение
данных, в котором можно различать наилучший случай (best case), наихудший случай (worst
case) и средний случай (average case) для алгоритма. Средний случай — это ожидаемая
эффективность алгоритма, если он выполняется много раз со случайным набором значений
данных.
Определяя вычислительную эффективность алгоритма, мы ассоциируем функцию f(n) с
количеством сравнений. В действительности, точная форма функции может быть трудна для
определения, и поэтому мы используем методы аппроксимации для определения хорошей
верхней границы функции.
Мы определяем простую функцию g(n) и константу К так, что K*g(n) превышает f(n) по мере
того, как п значительно возрастает. Для большого значения п поведение f(n) ограничивается
произведением функции g(n) на некоторую константу. Мы используем эту математическую
концепцию, называемую нотацией Big-O, чтобы дать меру вычислительной эффективности.
Определение: Функция f(n) имеет порядок O(g(n)), если имеется константа К и счетчик п 0 ,
такие, что f(n) < K*g(n), для п > п 0 .
Интуитивно это означает, что функция g в конечном счете превышает значение функции f. Мы
говорим, что вычислительная сложность (computational complexity) (или порядок) алгоритма
равна O(g(n)).
Традиционно значение Big-О для алгоритма структур данных выбирается среди небольшого
набора полиномиальных, логарифмических и экспоненциальных функций. Для классических
структур данных эти функции дают наилучшие верхние границы вычислительной сложности
алгоритмов.
267
В примере с обменной сортировкой мы ищем функцию g, которая ограничивает f(n). В таблице
рассматриваются
g(n) = 1/2 п2 и f(n) для разных значений п.
В конечном счете, функция f(n) ограничивается величиной 1/2 g(n), где g(n) = п 2 . В этом
случае возможное условие появляется непосредственно при n 0 = 1 и К = 1 / 2 .
f(n) < 1/2 п 2 для всех п > 1
Мы говорим, что f(n) имеет порядок O(g(n)) — О(п2), поэтому вычислительная сложность
обменной сортировки составляет О(п2). Анализ наилучшего и наихудшего случаев также
приводит к той же мере сложности, так как обменная сортировка всегда требует 1 / 2 п(п — 1)
сравнений. Этот алгоритм сортировки требует порядка О(п2) единиц времени для вычисления
независимо от начального порядка данных.
В нашем исследовании сортировки мы обнаружим, что некоторые алгоритмы имеют
вычислительную сложность (порядок) О(п log2n) для достаточно большого п0.
Количество сравнений < К п log 2 п для п > п 0 .
В таблице сравниваются значения п2 и п log2 n. Заметьте, насколько более эффективным
является алгоритм сортировки О(пlog2n), чем обменная сортировка. Например, в случае со
списком из 10 000 элементов количество сравнений для обменной сортировки ограничивается
величиной 100 000 000, тогда как более эффективный алгоритм имеет количество сравнений,
ограниченное величиной 132 000. Новая сортировка приблизительно в 750 раз более
эффективна.
Таблица
n
(1/2)n2
S(n) = n 2 /2 - n - 2
10
50
45
100
5.000
4.950
1000
500.000
499.500
5000
12.500.000
12.497.500
10000
50.000.000
49/995.000
n
n2
n log2n
5
25
11,6
268
10
100
33,2
100
10000
664,3
1000
1000000
9965,7
10000
100000000
132877,1
При выполнении Big-O-аппроксимации функции f(n) мы используем термин доминирование
для определения вычислительной сложности. Небольшой опыт работы с неравенствами дает
возможность математически проверить эту стратегию. Например, в случае функции
f(n) = п + 2
терм п является доминирующим. Функция g(n) = n используется в следующем неравенстве для
проверки того, что f имеет порядок О(п).
f(n) = п + 2 <= п + п = 2*п для п >= 2
f также имеет порядок О(п 2 ) или О(п 3 ), так как g(n) — п 2 и g(n) = п 3 ограничивают f(n). Мы
выбираем О(п), что представляет наилучшую оценку для этой функции.
Пример
1. f(n) = п 2 + п + 16 Доминирующий терм — п 2 , а f имеет порядок О(п2).
f(n) = п 2 + п + 1 <= п 2 + п 2 + п 2 = 3п 2 для п >= 1
2. f(n) =
O(sqrt(n))
sqrt(n+3)
Доминирующий
терм
—
sqrt(n),
a
/
имеет
порядок
f(n) = sqrt(n+3) <= sqrt(n+n)=sqrt(2n)=sqrt(2)*sqrt(n) для п >= 3
3. f(n) = 2 п + n + 2 Доминирующий терм — 2 n , a f имеет порядок О(2 п ).
f(n) = 2 п + п + 2
<= 2 п + 2 п +2 п = 3*2 п , для п >= 1
Сложность алгоритма. Big-O-оценка дает меру времени выполнения (runtime) алгоритма.
Обычно алгоритм имеет разную вычислительную эффективность для наилучшего и наихудшего
случаев, поэтому мы вычисляем конкретное значение Big-О для каждого случая. В разделе 4.4
излагается метод нахождения времении выполнения для последовательного и бинарного
поиска. Каждый алгоритм имеет порядок для наилучшего и наихудшего случая, которые
различны. Наилучший случай для алгоритма часто не важен, так как эти обстоятельства
являются исключительными и неподходящими для решения о выборе какого-либо алгоритма.
Наихудший случай может быть важен, так как эти обстоятельства будут наиболее негативно
влиять на ваше приложение. Клиент может не допускать наихудшего случая и может
предпочесть, чтобы вы выбрали алгоритм, который имеет более узкий диапазон эффективности. В
общем, довольно трудно математически определить среднюю эффективность какого-либо
алгоритма. Мы будем использовать только очень простые измерения ожидаемых значений и
оставим математические детали для курса по теории сложности.
Общий порядок величин
269
Небольшой набор различных порядков определяет сложность большинства алгоритмов структур
данных. Мы определяем различные порядки и описываем алгоритмы, приводящие в результате к
таким оценкам.
Если алгоритм — порядка 0(1), то этот порядок не зависит от количества элементов данных в
коллекции. Этот алгоритм выполняется за постоянную единицу времени (constant time).
Например, присваивание некоторого значения элементу списка массива имеет порядок 0(1),
при условии, что вы храните индекс, который определяет конец списка. Сохранение этого
элемента включает только простой оператор присваивания.
Алгоритм О(п) является линейным (linear). Сложность этого алгоритма пропорциональна
размеру списка. Например, вставка элемента в конец списка п элементов будет линейной, если
мы не храним ссылку на конец списка. Подразумевая, что мы можем просматривать элемент за
элементом, алгоритм требует, чтобы мы протестировали п элементов перед определением конца
списка. Порядком этого процесса является О(п). Нахождение максимального элемента в массиве
из п элементов — это О(п), потому что должен быть проверен каждый из п элементов.
Ряд алгоритмов имеют порядок, включающий log2n, и называются логарифмическими
(logarithmic). Эта сложность возникает, когда алгоритм неоднократно подразделяет данные на
подсписки, длиной 1/2, 1/4, 1/8, и так далее от оригинального размера списка.
Логарифмические порядки возникают при работе с бинарными деревьями. Бинарный
поискимеет сложность
среднего и наихудшего случаев O(log2n).
Алгоритмы, имеющие порядок О(п2), являются квадратическими (quadratic). Наиболее простые
алгоритмы сортировки такие, как обменная сортировка, имеют порядок О(п2). Квадратические
алгоритмы используются на практике только для относительно небольших значений га. Всякий
раз, когда п удваивается, время выполнения такого алгоритма увеличивается на множитель 4.
Алгоритм показывает кубическое (cubic) время, если его порядок равен О(n3), и такие
алгоритмы очень медленные. Всякий раз, когда п удваивается, время выполнения алгоритма
увеличивается в восемь раз. Алгоритм Уоршела, применимый к графам, — это алгоритм
порядка О(п 3 ).
Алгоритм со сложностью О(2п) имеет экспоненциальную сложность (exponential complexity).
Такие алгоритмы выполняются настолько медленно, что они используются только при малых
значениях п. Этот тип сложности часто ассоциируется с проблемами, требующими
неоднократного поиска дерева решений.
В таблице приводятся линейный, квадратичный, кубический, экспоненциальный и
логарифмический порядки величины для выбранных значений п. Из таблицы очевидно, что
270
следует избегать использования кубических и экспоненциальных алгоритмов, если только
значение п не мало.
Оценка порядка алгоритмов
Таблица
n
lоg2n
n lоg2n
n2
nэ
2n
2
1
2
4
8
4
4
2
8
16
64
16
8
3
24
64
512
256
16
4
64
256
4096
65536
32
5
160
1024
32768
4294967296
128
7
896
16384
2097152
3.4 х 1038
1024
10
10240
1048576
1073741824
1.8 х 10308
65536
16
1048576
4294967296
2.8 х 1014
Избегайте!
271
16.Протокол ТСР: установление и разрыв соединения, управление
передачей данных, надёжная доставка данных.
Протокол TCP
Протокол TCP (transmission control protocol, RFC-793, 1323, 1644[T/TCP], 2018, 2581,
2582[RENO], 2861, 2873, 2883[SACK], 2923[MTU], 2988[RTO], 3293[GSMP], 3448[TFRC],
3465, 3481) в отличие от UDP осуществляет доставку дейтаграмм, называемых
сегментами, в виде байтовых потоков с установлением соединения. Протокол TCP
применяется в тех случаях, когда требуется гарантированная доставка сообщений. Он
использует контрольные суммы пакетов для проверки их целостности и освобождает
прикладные процессы от необходимости таймаутов и повторных передач ради
обеспечения надежности. При отслеживании подтверждения доставки в TCP реализуется
алгоритм "скользящего" окна. Наиболее типичными прикладными процессами,
использующими TCP, являются FTP (file transfer protocol - протокол передачи файлов) и
telnet (или SSH для удаленного доступа). Кроме того, TCP используют системы SMTP,
HTTP, Xwindow, RCP (remote copy), а также "r"-команды. Внутренняя структура модуля
TCP гораздо сложнее структуры UDP. Подобно UDP, прикладные процессы
взаимодействуют с модулем TCP через порты. Под байтовыми потоками здесь
подразумевается то, что один примитив, например, read или write, может вызвать посылку
адресату последовательности сегментов, которые образуют некоторый блок данных
(сообщение). Применение портов открывает возможность осуществлять несколько
соединений между двумя сетевыми объектами (работать с разными процессами).
Примером прикладного процесса, использующего TCP, может служить FTP, при этом
будет работать стек протоколов ftp/tcp/ip/ethernet. Хотя протоколы UDP и TCP могли бы
для сходных задач задействовать разные номера портов, обычно этого не происходит.
Модули TCP и UDP выполняют функции мультиплексоров/демультиплексоров между
прикладными процессами и IP-модулем. При поступлении пакета в модуль IP он будет
передан в TCP или UDP-модуль согласно коду, записанному в поле протокола данного IPпакета. Формат сегмента (пакета) TCP представлен ниже на рис. 2.3. Если вы хотите
глубже разобраться с особенностями работы этого протокола, воспользуйтесь услугами
272
программы tcpdump, которая позволяет отслеживать содержимое отправляемых и
приходящих пакетов в ходе реализации сессии.
Если IP-протокол работает с адресами, то TCP, так же, как и UDP, - с портами. Именно с
номеров портов отправителя и получателя начинается заголовок TCP-сегмента. 32битовое поле код позиции в сообщении определяет порядковый номер первого октета в
поле данных пользователя. В приложениях передатчика и приемника этому полю
соответствуют 32-разрядные счетчики числа байт, которые при переполнении
обнуляются. При значении флага syn=1 в этом поле лежит код ISN (Initial Sequence
Number; смотри ниже описание процедуры установления связи), выбираемый для
конкретного соединения. Первому байту, передаваемому через созданное соединение,
присваивается номер ISN+1. Значение ISN может задаваться случайным образом. Но в
UNIX 4.4BSD при загрузке ОС ISN делается равным 1 (это нарушает требования RFC), а
далее увеличивается на 640000 каждые полсекунды. Аналогичная инкрементация
осуществляется при установлении нового соединения. В RFC рекомендуется увеличивать
счетчик ISN на 1 каждые 4 мкросекунды.
32-битовое поле номер октета, который должен прийти следующим, содержит код,
который на единицу больше номера последнего успешно доставленного (принятого)
байта. Содержимое этого поля интерпретируется получателем сегмента, только если
присутствует флаг ACK. Это поле заполняется в заголовках всех сегментов, передаваемых
после установления соединения, а флаг AСK=1.
В ТСР предусмотрен режим полнодуплексной передачи. При этом данные могут
передаваться в обоих направлениях независимо. В ходе обмена каждая из сторон должна
отслеживать позиционные номера передаваемых и принимаемых байт. Если получен
сегмент с некоторым кодом поля номер октета, который должен прийти следующим, это
означает, что все октеты с номерами, меньшими указанного в данном поле, доставлены
благополучно. Если благополучно доставлены байты с номерами 0-N, а затем получен
сегмент с номерами байтов (N+k) - (N+k+m), такой сегмент будет буферизован, но
подтверждения его получения не последует. Вместо этого посылается отклик, с кодом
номер октета, который должен прийти следующим =(N+1). В случае получения сегмента с
неверной контрольной суммой будет послан отклик, идентичный предыдущему.
Дублированные отклики позволяют детектировать потерю пакета.
Поле HLEN определяет длину заголовка сегмента, которая измеряется в 32-разрядных
словах. Это поле необходимо, так как в заголовке могут содержаться поля опций
переменной длины. Далее следует поле резерв, предназначенное для будущего
использования, в настоящее время должно обнуляться. Поле размер окна сообщает,
сколько октетов готов принять получатель (флаг ACK=1) вслед за байтом, указанным в
поле номер октета, который должен прийти следующим. Окно имеет принципиальное
значение, оно определяет число сегментов, которые могут быть посланы без получения
подтверждения. Значение ширины окна может варьироваться во время сессии. Значение
этого поля, равное нулю, также допустимо и указывает, что байты вплоть до указанного в
поле номер октета, который должен прийти следующим, получены, но адресат временно
не может принимать данные. Разрешение на посылку новой информации может быть дано
с помощью посылки сегмента с тем же значением поля номер октета, который должен
прийти следующим, но ненулевым значением поля ширины окна. Поле контрольная
сумма предназначено для обеспечения целостности сообщения. Контрольное
273
суммирование производится по модулю 1. Перед контрольным суммированием к TCPсегменту добавляется псевдозаголовок (как и в случае протокола UDP), который включает
в себя адреса отправителя и получателя, код протокола и длину сегмента, исключая
псевдозаголовок. Поле указатель важной информации представляет собой указатель
последнего байта, содержащий информацию, которая требует немедленного
реагирования. Поле имеет смысл лишь при флаге URG=1, отмечающем сегмент с первым
байтом "важной информации". Значение разрядов в 6-битовом коде флаги описано в
таблице 2.1. Если флаг ACK=0, значение поля номер октета, который должен прийти
следующим, игнориру ется. Флаг URG=1 устанавливается в случае нажатия
пользователем клавиш Del или Ctrl+С.
Таблица 2.1. Значения битов поля флаги
обозначение битов (слева на
право) поля флаги
значение бита, если он равен 1
URG
Флаг важной информации, поле Указатель важной информации имеет
смысл, если urg=1
ACK
Номер октета, который должен прийти следующим, правилен
PSH
Этот сегмент требует выполнения операции push. Получатель должен
передать эти данные прикладной программе как можно быстрее
RST
Прерывание связи
SYN
Флаг для синхронизации номеров сегментов, используется при
установлении связи
FIN
Отправитель закончил посылку байтов
Рис. 2.3. Формат TCP-сегмента
Поле опции зарезервировано на будущее и в заголовке может отсутствовать, его размер
переменен и дополняется до кратного 32-бит с помощью поля заполнитель. Формат поля
опции представлен на рис. 2.4. В настоящее время определены опции (поле вид):
0 Конец списка опций.
1 Никаких операций. Используется для заполнения поля опции до числа октетов, кратного
4.
2 Максимальный размер сегмента (MSS).
274
В поле вид записывается код опции, поле LEN содержит число октетов в описании опции,
включая поля вид и LEN. Определены также опции со значением вид=4,5,6,7. В
предложении T/TCP (RFC-1644) описаны опции 11, 12 и 13. Поле данные может иметь
переменную длину, верхняя его граница задается значением MSS (Maximum Segment
Size). Значение MSS может быть задано при установлении соединения каждой из сторон
независимо. Для Ethernet MSS=1452 байта.
Поле данные в TCP-сегменте может и отсутствовать, характер и формат передаваемой
информации задается исключительно прикладной программой, теоретически
максимальный размер этого поля составляет в отсутствии опций 65495 байт (на практике,
помимо MSS, нужно помнить, например, о значении MTU для Ethernet, которое немногим
больше 1500 байт). TCP является протоколом, который ориентируется на согласованную
работу ЭВМ и программного обеспечения партнеров, участвующих в обмене
информацией. Установление соединения клиент-сервер осуществляется в три этапа.
Рис. 2.4. Формат опций для TCP-сегментов
1.
Клиент посылает SYNсегмент с указанием номера порта сервера, который предлагается
использовать для организации канала связи (active open).
2.
Сервер откликается, посылая свой SYNсегмент, содержащий идентификатор (ISN - Initial Sequence
Number). Начальное значение ISN не равно нулю. Процедура называется passive open.
3.
Клиент отправляет подтверждение (ACK) получения SYN-сегмента от сервера с идентификатором
равным ISN(сервера)+1.
Стандартная процедура установления связи представлена на рисунке 2.5 (под словом
"стандартная" подразумевается отсутствие каких--либо отклонений от штатного
режима, например, одновременного открывание соединения со стороны сервера и
клиента). Если же соединение одновременно инициируется клиентом и сервером, в
конечном итоге будет создан только один виртуальный канал.
Префикс S на рисунке указывает на сервер, а С - на клиента. Параметры в скобках
обозначают относительные значения ISN. После установления соединения ISN(S) =
s_seq_1, а ISN(C) = c_seq_1.
275
Рис. 2.5. Алгоритм установления связи. В рамках представлены состояния клиента и
сервера; (см. также рис. 2.6)
Каждое соединение должно иметь свой неповторимый код ISN. Для реализации режима
соединения прикладная программа на одном конце канала устанавливается в режим
пассивного доступа ("passive open"), а операционная система на другом конце ставится в
режим активного доступа ("active open"). Протокол TCP предполагает реализацию 11
состояний (established, closed, listen, syn_sent, syn_received и т.д.; см. также RFC-793),
переход между которыми строго регламентирован. Машина состояний для протокола TCP
может быть описана диаграммой, представленной на рис. 2.5. Здесь состояние closed
является начальной и конечной точкой последовательности переходов. Каждое
соединение стартует из состояния closed. Из диаграммы машины состояний видно, что ни
одному из состояний не поставлен в соответствие какой--либо таймер. Это означает, что
машина состояний TCP может оставаться в любом из состояний сколь угодно долго.
Исключение составляет keepalive таймер, но его работа является опционной, а время по
умолчанию составляет 2 часа. Это означает, что машина состояния может оставаться 2
часа без движения. В случае, когда две ЭВМ (C и S) попытаются установить связь друг с
другом одновременно, реализуется режим simultaneous connection (RFC-793). Обе ЭВМ
посылают друг другу сигналы SYN. При получении этого сигнала партнеры посылают
отклики SYN+ACK. Обе ЭВМ должны обнаружить, что SYN и SYN+ACK относятся к
одному и тому же соединению. Когда C и S обнаружат, что SYN+ACK соответствует
посланному ранее SYN, они выключат таймер установления соединения и перейдут
непосредственно в состояние syn_recvd (смотри рис. 2.4).
В состоянии established пакет будет принят сервером, если его ISN лежит в пределах
s_ack, s_ack+s_wind (s_wind - ширина окна для сервера; см. рис. 2.6). Аналогичный
диапазон ISN для клиента выглядит как: c_ack, c_ack+c_wind (c_wind ширина окна для
клиента). c_wind и s_wind могут быть не равны. Пакеты, для которых эти условия не
выполняются, будут отброшены.
Рассмотрим пример установления соединения для случая FTP-запроса. Пусть клиент С
запускает процесс установления FTP-соединения с сервером S. Обычный порядок
установления соединения показан ниже (см. рис. 2.4):
c > s:syn(isnc)
s > c:syn(isns), ack(isnc)
c > s: ack(isns) (Связь установлена)
276
c > s: данные
и/или
s > c: данные
ISN - идентификатор пакета, посылаемого клиентом (С) или сервером (S). Клиент, послав
SYN серверу S, переходит в состояние syn_sent. При этом запускается таймер
установления соединения.
Как при установлении соединения, так и при его разрыве приходится сталкиваться с
проблемой двух армий. Представим себе, что имеются две армии А и Б, причем Б больше
по численности чем А. Армия Б разделена на две части, размещенные по разные стороны
от армии А. Если две части армии Б одновременно нападут на армию А, победа
гарантирована. В то же время нападение на А одной из частей армии Б обрекает ее на
поражение. Но как обеспечить одновременность? Здесь предполагается, что радио еще не
изобретено и передача сообщений осуществляется вестовыми, которые в нашем случае
могут быть перехвачены врагом. Как убедиться, что вестовой дошел? Первое, что
приходит в голову, это послать другого вестового с подтверждением. Но он также с
некоторой вероятностью может быть перехвачен. А отправитель не будет знать, дошел ли
он. Ведь если сообщение перехвачено, отправитель первичного запроса не выдаст
команды на начало, так как не уверен, дошло ли его первое сообщение. Возникает вопрос,
существует ли алгоритм, который бы гарантировал надежность синхронизации решений
путем обмена сообщениями при ненадежной доставке? Повысит ли достоверность
увеличение числа обменов между партнерами? Ответом на этот вопрос будет - нет, не
существует. В этом читатель, порассуждав логически, может убедиться самостоятельно.
Нетрудно видеть, что схожие проблемы возникают в любом протоколе, работающем через
установление соединения. Чаще всего эта проблема решается путем таймаутов и
повторных попыток (это, слава Богу, не война и все обходится без человеческих жертв).
Сервер, получив SYN, откликается посылкой другого SYN. Когда С получает SYN от S
(но не получает ACK, например, из-за его потери или злого умысла), он предполагает, что
имеет место случай одновременного открытия соединения. В результате он посылает
syn_ack, отключает таймер установления соединения и переходит в состояние
syn_received. Сервер получает syn_ack от C, но не посылает отклика. Тогда С ожидает
получения syn_ack в состоянии syn_received. Так как время пребывания в этом состоянии
не контролируется таймером, С может остаться в состоянии syn_received вечно. Из--за
того, что переходы из состояния в состояние не всегда четко определены, протокол TCP
допускает и другие виды атак.
Хотя TCP-соединение является полнодуплексным, при рассмотрении процесса разрыва
связи проще его рассматривать как два полудуплексных канала, каждый из которых
ликвидируется независимо. Сначала инициатор разрыва посылает сегмент с флагом FIN,
сообщая этим партнеру, что не намерен более что--либо передавать (FIN посылается, как
правило, в результате вызова приложением функции close). Когда получение этого
сегмента будет подтверждено (ACK), данное направление передачи считается
ликвидированным (реализуется полузакрытие соединения). При этом передача
информации в противоположном направлении может беспрепятственно продолжаться.
Когда партнер закончит посылку данных, он также пошлет сегмент с флагом FIN. По
получении отклика ACK виртуальный канал считается окончательно ликвидированным.
277
Таким образом, для установления связи требуется обмен тремя сегментами, а для разрыва
- четырьмя. Но протокол допускает совмещение первого ACK и второго FIN в одном
сегменте, сокращая полное число закрывающих сегментов с четырех до трех.
Партнер, пославший флаг FIN первым, производит активное закрытие соединения, а
противоположный партнер (получивший FIN) отвечает на него своим FIN, осуществляя
пассивное закрытие соединения. Инициатором посылки первого FIN может быть любая из
сторон, но чаще это делается клиентом (например, путем ввода команды quit).
Полузакрытие используется, например, при реализации команды rsh (запуск операций в
удаленном узле).
Машина состояний для протокола TCP не предусматривает изменения состояний при
посылке или получении обычных пакетов, содержащих данные.
Состояние ESTABLISHED (рис. 2.6) указывает на то, что система находится в состоянии с
установленным соединением. Четыре состояния в левом углу помещены в границы
затененной зоны и соответствуют активному закрытию. Состояния CLOSE_WAIT и
LAST_ACK относятся к пассивному закрытию. Переход из состояния SYN_RCVD в
LISTEN возможно, если переход в SYN_RCVD осуществлен из состояния LISTEN, а не из
состояния SYN_SENT (одновременное открытие двух соединений, получение RST вместо
финального ACK).
Состояние TIME_WAIT часто называется ожиданием длительностью 2MSL (Maximum
Segment Lifetime). Значение MSL задается конкретной реализацией и определяет
предельную величину пребывания сегмента в сети. В RFC-793 рекомендуется задавать
MSL равным 2 мин. Но нужно помнить, что ТСРсегмент транспортируется в IPдейтаграмме, содержащей поле TTL. Когда модуль выполнил активное закрытие и в ответ
на FIN послал ACK, соединение должно оставаться в состоянии TIME_WAIT в течение
времени, в два раза превышающем MSL. Сокет, используемый данным соединением, не
может быть задействован другим соединением в продолжение указанного времени. Все
сегменты данного соединения, задержавшиеся в пути, во время TIME_WAIT
отбрасываются. Этим гарантируется, что сегменты старого соединения не будут
восприняты новым соединением. Такая процедура препятствует перезапуску серверов в
течение 14 минут, так как в течение данного времени не могут использоваться
стандартные значения номеров портов.
278
Рис. 2.6. Машина состояний для протокола TCP (W.R. Stivens, TCP/IP Illustrated. V1.
Addison-Wesley publishing company. 1993. Имеется обновленная версия книги,
переведенная на русский язык: У.Ричард Стивенс, "Протоколы TCP/IP. Практическое
руководство", BHV, Санкт-Петербург, 2003)
Состояние FIN_WAIT_2 сопряжено со случаем, когда одна сторона послала сегмент
FIN, а другая сторона подтвердила его получение. Если данное соединение не нужно,
можно ждать, когда приложение другой стороны получит код конца файла и пришлет
свой флаг FIN. Только после этого система перейдет из состояния FIN_WAIT_2 в
состояние TIME_WAIT. Теоретически такое ожидание может быть бесконечным.
Другая сторона при этом остается в состоянии CLOSE_WAIT, пока приложение не
вызовет функцию close. Для решения проблемы часто вводят дополнительный таймер.
В ТСР возможна ситуация, когда обе стороны запускают процедуру закрытия
одновременно (посылают FIN), что в протоколе ТСР вполне допустимо. Каждая из
279
сторон при этом переходит из состояния ESTABLISHED в состояние FIN_WAIT_1
(после вызова операции closed). По получении FIN стороны переходят из состояния
FIN_WAIT_1 в состояние CLOSING и посылают ACK. После получения ACK
происходит переход в состояние TIME_WAIT.
Когда оператор, работая в диалоговом режиме, нажимает командную клавишу,
сегмент, в который помещается эта управляющая последовательность, помечается
флагом PSH (push). Это говорит приемнику, что информация из этого сегмента должна
быть передана прикладному процессу как можно скорее, не дожидаясь прихода еще
какой--либо информации. Сходную функцию выполняет флаг URG. URG позволяет
выделить целый массив данных, так как активизирует указатель последнего байта
важной информации. Будет ли реакция на эту "важную" информацию, определяет
прикладная программа получателя. URG-режим используется для прерываний при
работе с FTP, telnet или rlogin. Если до завершения обработки "важной" информации
придет еще один сегмент с флагом URG, значение старого указателя конца "важного"
сообщения будет утеряно. Это обстоятельство должно учитываться прикладными
процессами. Так, telnet в командных последовательностях всегда помещает
префиксный байт с кодом 255.
В режиме удаленного терминала (telnet/ssh) при нажатии любой клавиши формируется
и посылается 41-октетный сегмент (здесь не учитываются издержки Ethernet и
возможность наличия опций в IP и TCP), который содержит всего один байт полезной
информации. В локальной сети здесь проблем не бывает, но в буферах
маршрутизаторов в среде Интернет могут возникнуть заторы. Эффективность работы
может быть улучшена с помощью алгоритма Нагля (Nagle, 1984; RFC-896). Нагль
предложил при однобайтовом обмене посылать первый байт, а последующие
буферизовать до прихода подтверждения получения посланного. После этого
посылаются все буферизованные октеты, а запись в буфер вводимых кодов
возобновляется. Если оператор вводит символы быстро, а сеть работает медленно, этот
алгоритм позволяет заметно снизить загрузку канала. Встречаются, впрочем, случаи,
когда алгоритм Нагля желательно отключить, например, при работе в Интернет в
режиме Х-терминала, где сигналы перемещения мышки должны пересылаться
немедленно, чтобы не ввести в заблу ждение пользователя относительно истинного
положения маркера.
Существует еще одна проблема при пересылке данных по каналам TCP, которая
называется синдром узкого окна (silly window syndrome; Clark, 1982). Такого рода
проблема возникает в том случае, когда данные поступают отправителю крупными
блоками, а интерактивное приложение адресата считывает информацию побайтно.
Предположим, что в исходный момент времени буфер адресата полон и передающая
сторона знает об этом (window=0). Интерактивное приложение считывает очередной
октет из TCP-потока, при этом TCP-агент адресата посылает отправителю
уведомление, разрешающее ему послать один байт. Этот байт будет послан и снова
заполнит до краев буфер получателя, что вызовет отправку ACK со значением
window=0. Процесс может продолжаться сколь угодно долго, понижая коэффициент
использования канала ниже паровозного уровня.
Кларк предложил посылать уведомление о ненулевом значении ширины окна не при
считывании одного байта, а лишь после освобождения достаточно большого
280
пространства в буфере: например, когда адресат готов принять MSS байтов или когда
буфер наполовину пуст.
Предполагается, что получатель пакета практически всегда посылает отправителю
пакет--отклик. Отправитель может послать очередной пакет, не дожидаясь получения
подтверждения для предшествующего. Таким образом, может быть послано k пакетов,
прежде чем будет получен отклик на первый пакет (протокол "скользящего окна").
В протоколе TCP "скользящее окно" служит для эффективного использования
высокопроизводительных каналов с большими значениями RTT.
Идея скользящего окна отображена на рис. 2.7. Здесь предполагается, что ширина окна
равна 7 (k=7; это число может меняться в очень широких пределах, обычно оно равно
нескольким тысячам).
После прихода отклика на пакет <1> окно смещается вправо на одну позицию. Теперь
отправитель может послать и пакет <8>. Если порядок прихода откликов нарушается,
сдвиг окна может задержаться. Размер окна в сегментах определяется соотношением:
window > RTT*B/MSS,
Рис. 2.7. Схема использования скользящего окна
где B - полоса пропускания канала в бит/с, MSS - максимальный размер сегмента в битах,
а размер окна window - в сегментах.
Для протокола TCP механизм скользящего окна может работать на уровне октетов или
сегментов. В первом случае нужно учитывать каждый раз размер поля данных
переданного и подтвержденного сегмента. В TCP протоколе используется три указателя
(стрелки на рис. 2.7):
Первый указатель определяет положение левого края окна, отделяя посланный сегмент,
получивший подтверждение, от посланного сегмента, получение которого не
подтверждено. Второй указатель отмечает правый край окна и указывает на сегмент,
который может быть послан до получения очередного подтверждения. Третий указатель
помечает границу внутри скользящего окна между уже посланными сегментами и теми,
которые еще предстоит послать. Получатель организует аналогичные окна для
обеспечения контроля потока данных. Если указатель 3 совпадет с указателем 2,
отправитель должен прервать дальнейшее отправление пакетов до получения хотя бы
одного подтверждения. Обычно получатель посылает одно подтверждение (ACK) на два
полученных сегмента.
281
Регулирование трафика в TCP подразумевает существование двух независимых
процессов: контроль доставки, управляемый получателем с помощью параметра window, и
контроль перегрузки, управляемый отправителем с помощью окна перегрузки cwnd
(congestion window) и ssthreth (slow start threshold). Первый процесс отслеживает
заполнение входного буфера получателя, второй - регистрирует перегрузку канала, а
также связанные с этим потери и понижает уровень трафика. В исходный момент времени
при установлении соединения cwnd делается равным одному MSS, а ssthreth=65535
байтам. Программа, управляющая пересылкой, никогда не пошлет больше байт, чем это
задано cwnd и объявленным получателем значением window. Когда получение очередного
блока данных подтверждено, значение cwnd увеличивается. Характер этого увеличения
зависит от того, осуществляется ли медленный старт или реализуется режим подавления
перегрузки. Если cwnd меньше или равно ssthreth, выполняется медленный старт,в
противном случае осуществляется режим подавление перегрузки. В последнем варианте
cwndi+1 = cwndi + MSS/8 +(MSS*MSS)/cwnd. Если возникает состояние перегрузки канала
значение cwnd снова делается равным одному MSS.
Окно перегрузки (cwnd) позволяет согласовать полную загрузку виртуального соединения
и текущие возможности канала, минимизируя потери пакетов при перегрузке.
В качестве модуля приращения cwnd используется MSS (а не байт). При получении
подтверждения (ACK) окно перегрузки увеличивается на один сегмент ("медленный
старт", CWNDi+1 = CWNDi + размер_сегмента; последнее слагаемое нужно, если размер
окна задан в октетах, в противном случае вместо него следует использовать 1), и теперь
отправитель может послать, не дожидаясь ACK, уже два сегмента и т.д.. Ширина окна, в
конце концов, может стать настолько большой, что ошибка доставки в пределах окна
станет заметной. Тогда будет запущена процедура "медленного старта" или другой
алгоритм, который определит новое, уменьшенное значение окна. Окно перегрузки
позволяет управлять информационным потоком со стороны отправителя, блокируя
возможные перегрузки и потери данных в промежуточных узлах сети. Если переполнения
не происходит, CWND становится больше окна, объявленного получателем, и именно
последнее будет ограничивать поток данных в канале. Размер окна, объявленный
получателем, ограничивается произведением полосы пропускания канала (бит/с) на RTT
(время распространения пакета туда и обратно). Максимально допустимый размер окна в
TCP равен 65535 байт (задается размером поля заголовка). Конечной целью
регулирования трафика является установление соответствия между темпом передачи и
возможностями приема. Причиной перегрузки может быть не только ограниченность
размера буфера, но и недостаточная пропускная способность какогото участка канала. С
учетом этого обстоятельства каждый отправитель формирует два окна: окно получателя
(window) и окно перегрузки (cwnd). Реальное значение ширины скользящего окна равно
минимальному из этих величин.
При инициализации соединения окно перегрузки имеет ширину, равную одному MSS.
Отправитель посылает сегмент, и если будет прислано подтверждение получения до
истечения времени таймаута, размер окна перегрузки удваивается и посылается два
сегмента. При получении подтверждения доставки каждого из сегментов окно перегрузки
увеличивается на один сегмент максимальной длины. Таким образом, ширина окна
перегрузки последовательно удваивается, пока доставка всех сегментов подтверждается.
282
Рост ширины окна перегрузки при этом имеет экспоненциальный характер. Именно эта
процедура и называется медленным стартом (Джекобсон, 1988).
Как было сказано выше, помимо окон перегрузки и получателя в TCP используется третий
параметр - порог (иногда он называется порогом медленного старта ssthresh). При
установлении соединения ssthresh=64 Kбайт. В случае возникновения таймаута значение
ssthresh делается равным CWND/2, а само значение CWND приравнивается одному MSS
(см. рис. 2.8). Далее запускается процедура медленного старта, чтобы выяснить
возможности канала. При этом экспоненциальный рост cwnd осуществляется вплоть до
значения ssthresh. Когда этот уровень cwnd достигнут, дальнейший рост происходит
линейно с приращением на каждом шагу равным MSS (рис. 2.8).
Рис. 2.8. Эволюция ширины окна при медленном старте
Здесь предполагается, что MSS=1 Кбайт. Началу диаграммы соответствует установка
значения ssthresh=16 Kбайт. Данная схема позволяет более точно выбрать значение cwnd.
Заметим, что в разных реализациях в качестве единицы измерения для cwnd и ssthresh
может использоваться число байт или число сегментов. После таймаута, который на
рисунке произошел при передаче c номером 12, значение порога понижается до 12 Кбайт
(=cwnd/2). Ширина окна cwnd снова начинает расти от передачи к передаче, начиная с
одного сегмента, вплоть до нового значения порога ssthresh=12 Кбайт. Стратегия с
экспоненциальным и линейным участками изменения ширины окна перегрузки позволяет
несколько приблизить среднее его значение к оптимальному. Для локальных сетей, где
значение RTT невелико, а вероятность потери пакета мала, оптимизация задания cwnd не
так существенна, как в случае протяженных внешних (например, спутниковых) каналов.
Ситуация может поменяться, если в локальной сети имеется участок, где вероятность
потери пакетов велика. Таким участком может быть МАСбридж (или переключатель),
один из каналов которого подключен к сегменту Fast Ethernet, а другой к обычному
Ethernet на 10 Мбит/c. Если такой мост не снабжен системой подавления перегрузки (до
сих пор такие приборы не имели подобных систем), то каждый из пакетов будет потерян в
среднем 9 раз, прежде чем будет передан (здесь предполагается, что передача идет из
283
сегмента FE). При этом cwnd будет практически все время равно MSS, что крайне
неэффективно при передаче по каналам Интернет. Такие потери вызовут определенные
ошибки при вычислении среднего значения и дисперсии RTT, а как следствие и величин
таймаутов. Применение в таких местах маршрутизаторов или других приборов,
способных реагировать на перегрузку посредством ICMP(4), решает эту проблему (беда в
том, что многие ТСР агенты не реагируют на ICMP(4)). Алгоритм медленного старта
придуман как раз для преодоления подобных проблем, так как он минимизирует потери,
сопряженные с переполнением буферов.
Для взаимного согласования операций в рамках TCP-протокола используется четыре
таймера.
1. Таймер повторных передач (retransmission; RTO) контролирует время прихода
подтверждений (ACK). Таймер запускается в момент посылки сегмента. При
получении отклика ACK до истечения времени таймера - он сбрасывается. Если же
время таймера истекает до прихода ACK, сегмент посылается адресату повторно, а
таймер перезапускается.
2. Таймер запросов (persist timer), контролирующий размер окна даже в случае, когда
приемное окно закрыто. При window=0 получатель при изменении ситуации
посылает сегмент с ненулевым значением ширины окна, что позволит отправителю
возобновить свою работу. Но если этот пакет будет потерян, возникнет тупик,
тогда каждая из сторон ждет сигнала от партнера. Именно в этой ситуации и
используется таймер запросов. По истечении времени этого таймера отправитель
пошлет сегмент адресату. Отклик на этот сегмент будет содержать новое значение
ширины окна. Таймер запускается каждый раз, когда получен сегмент с window=0.
3. Таймер контроля работоспособности (keepalive), который регистрирует факты
выхода из строя или перезагрузки ЭВМ-партнеров. Время по умолчанию равно 2
часам. Keepalive-таймер не является частью TCP-спецификации. Таймер полезен
для выявления состояний сервера halfopen при условии, что клиент отключился
(например, пользователь выключил свою персональную ЭВМ, не выполнив
LOGOUT). По истечении времени таймера клиенту посылается сегмент проверки
состояния. Если в течение 75 секунд не будет получен отклик, сервер повторяет
запрос 10 раз с периодом 75 сек, после чего соединение разрывается. При
получении любого сегмента от клиента таймер сбрасывается и запускается вновь.
4. 2MSL-таймер (Maximum Segment Lifetime) контролирует время пребывания канала
в состоянии TIME_WAIT. Выдержка таймера по умолчанию равно 2 мин
(FIN_WAITтаймер). См. рис. 2.6. и RFC-793. Таймер запускается при выполнении
процедуры active close в момент посылки последнего ACK.
Важным параметром, определяющим рабочие параметры таймеров, является RTT (время
путешествия пакета до адресата и обратно). TCPагент самостоятельно измеряет RTT.
Такие измерения производятся периодически, и по их результатам корректируется
среднее значение RTT:
RTTm = a*RTTm + (1-a)*RTTi,
284
где RTTi - результат очередного измерения, RTTm - величина, полученная в результате
усреднения предыдущих измерений, а - коэффициент сглаживания, обычно равный 0.9.
RFC-793 рекомендует устанавливать время таймаута для ретрансмиссии RTO
(Retransmission TimeOut) равным RTO=RTTm*b, где b равно 2. От корректного выбора
этих параметров зависит эффективная работа каналов. Так, занижение времени
ретрансмиссии приводит к неоправданным повторным посылкам сегментов, перегружая
каналы связи. Для более точного выбора RTO необходимо знать дисперсию RTT.
Несколько более корректную оценку RTO можно получить из следующих соотношений
(предложено Джекобсоном в 1988 году, он же позднее предложил целочисленный
алгоритм реализации этих вычислений):
RTTm = RTTm + g(RTTi - RTTm)
D = D + d(|RTTi - RTTm | - D)
RTO = RTTm + 4D,
где D - среднее отклонение RTT от равновесного значения, а коэффициенты g = 0,125, d =
0,25. Чем больше g, тем быстрее растет RTO по отношению к RTT. Это хорошо работает
до тех пор, пока не произойдет таймаут и ретрансмиссия. В этом случае, получив ACK,
трудно решить, какому сегменту соответствует это подтверждение, первому или второму.
На эту проблему впервые обратил внимание Фил Карн. Решением проблемы является
приостановка коррекции RTTm при таймауте и ретрансмиссиях. Значение RTO зависит от
пропускной способности канала и от специфических задержек, например, в случае
спутниковых каналов. В основном RTO лежит в секундном диапазоне (515 сек). Наиболее
вероятная причина потери пакетов - это перегрузка канала на участках между
отправителем и приемником. Указанием на то, что пакет потерян, может служить таймаут
или получение дубликата сегмента ACK. Если произошел таймаут, система переходит в
режим "медленного старта" (ширина окна перегрузки делается равной 1 сегменту, а
значение порога медленного старта - ssthresh делается равным половине cwnd, при
котором это произошло). Дублирование ACK индицирует потерю пакета до наступления
таймаута. В этом случае сначала меняется алгоритм приращения величины окна
перегрузки cwnd (замедляется темп его роста). После прихода очередного ACK новое
значение cwnd вычисляется по формуле:
cwndi+1 = cwndi + (размер_сегмента*размер_сегмента)/cwndi + размер_сегмента/8
Если же в этот момент величина окна перегрузки меньше или равна некоторому порогу
(ssthresh - slow start threshold, обычно измеряется в байтах), осуществляется "медленный
старт". Следует помнить, что TCP требует посылки немедленного подтверждения
(дублированного ACK) при обнаружении прихода сегментов с нарушением порядка
следования. Причиной нарушения порядка следования может быть флуктуация задержки
в сети или потеря пакета. Если получено три или более задублированных ACK, что
является убедительным указанием на потерю пакета, не дожидаясь таймаута,
осуществляется повторная передача. Перехода в режим медленного старта в этом случае
не производится, но понижаются значения cwnd и ssthresh (почти вдвое).
Когда TCP-канал закрывается и за время сессии переслано более 16 полых окон, а адресат
достижим не через маршрут по умолчанию, то в таблицу маршрутизации заносится
следующая информация: усредненное значение RTT, значение дисперсии RTT и ssthresh.
285
Если в ходе TCP-сессии получено сообщение ICMP(4) (переполнение канала - quench),
требующее снижения потока данных, то cwdn делается равным одному сегменту, а
величина порога медленного старта ssthresh не изменяется. На ICMP-сообщения о
недостижимости сети или ЭВМ программы TCP-уровня не реагируют.
Нулевой размер окна блокирует посылку информации, и этим система время от времени
пользуется. Если за определенное время не поступает сегмент, сообщающий об изменении
размера окна, таймер начинает посылать зондирующие сегменты. Таймер запросов
использует базовую временную шкалу с периодом в 500 мсек, а период посылки
зондирующих сегментов лежит в диапазоне 560 сек. Такой сегмент содержит только один
байт данных. Таймер запросов не прерывает своей работы до тех пор, пока не будет
подтверждено открытие окна или пока прикладная задача не завершит свою работу,
выключив канал связи.
Будучи однажды создан, канал TCP может существовать "вечно". Если клиент и сервер
пассивны, они не заметят того, например, что какой-то бульдозер оборвал кабель или что
спутник связи покоится на дне океана. Чтобы это обнаружить, либо клиент, либо сервер
должны попытаться послать какуюто информацию. Чтобы информировать систему об
этих и подобных им жизненных неурядицах, предусмотрен таймер контроля
работоспособности (keepalive). Многим читателям, возможно, приходилось
легкомысленно выключать питание своего персонального компьютера, не позаботившись
о корректном logout из процедуры ssh или FTP. Если бы не существовало этого таймера,
то, включив ЭВМ, вы бы обнаружили, что "находитесь" в заморском депозитарии, где
были вчера. Но таймер контроля работоспособности может и прервать сессию, если
какой-то промежуточный маршрутизатор произвел перезагрузку или был вынужден
поменять маршрут. Принцип работы таймера работоспособности предельно прост. Если
канал пассивен, например, 2 часа, сервер посылает клиенту сегмент-зонд. При этом
ЭВМклиент может быть в одном из четырех состояний.

Работоспособен и достижим для сервера. Отклик от клиента сбросит таймер
работоспособности в ноль (начало отсчета очередных двух часов).

Вышел из строя, выключен или перезагружается. Сервер посылает 10 запросов с
интервалом 75 сек. Если отклика нет, канал закрывается и со стороны сервера.

Перезагрузился. Сервер получит отклик типа RESET, и канал будет закрыт.

Работоспособен, но не достижим для сервера. Случай тождественен описанному во
втором по порядку пункте.
Временная постоянная таймера keepalive является системной переменной единой для всех
пользователей ЭВМ или даже локальной сети.
Расширение пропускной способности и надежности телекоммуникационных каналов
делает актуальной совершенствование протоколов. Так как TCP является основным
транспортным протоколом, попытки усовершенствовать его предпринимаются, начиная с
1992 года (RFC-1323, Якобсон, Браден и Борман; см. также ссылки в конце главы). Целью
этих усовершенствований служит повышение эффективности и пропускной способности
канала, а также обеспечение безопасности. При этом рассматриваются следующие
возможности:
286

увеличение MTU (максимальный передаваемый блок данных);

расширение окна за пределы 65535 байт;

исключение "трехсегментного" процесса установления связи и
"четырехсегментного" ее прерывания (T/TCP, RFC-1644);

совершенствование механизма измерения RTT;

оптимизация отслеживания CWND.
Оптимальный выбор MTU позволяет минимизировать или исключить фрагментацию (и
последующую сборку) сегментов. Верхняя граница на MTU налагается значением MSS
(максимальный размер сегмента). Разумно находить и запоминать оптимальные значения
MTU для каждого конкретного маршрута. Так как в современных системах используются
динамические протоколы маршрутизации, поиск оптимального MTU рекомендуется
повторять каждые 10 мин (RFC-1191).
Как уже отмечалось, размер TCP-окна определяется произведением полосы канала (в
бит/с) на RTT в сек. Современный уровень технологий требует увеличения максимально
возможного размера окна в 10100 раз. Протокол же разрешает всего 65535 байт.
Появление мощных каналов порождает и другие проблемы - потеря пакетов в них
обходится слишком дорого, так как "медленный старт" и другие связанные с этим
издержки сильно снижают пропускную способность. В последнее время алгоритм
медленного старта заменяется более эффективными алгоритмами.
Простое увеличение ширины окна до тех пор, пока не произойдет сбой, - плохая стратегия
при использовании традиционного медленного старта, так как заметную часть времени
ширина окна будет неоптимальной - то слишком большой, то слишком малой.
Оптимальная стратегия должна включать в себя прогнозирование оптимальной ширины
окна. В новых версиях модулей TCP реализуются именно такие алгоритмы. В 1994 году
Бракмо предложил вариант стратегии изменения параметров передачи, который на 4070%
повышает пропускную способность TCP-канала.
Существуют и другие, могущие показаться забавными проблемы. Каждый сегмент в TCPпротоколе снабжается 32-битным идентификатором. Время жизни IP-пакета (TTL)
определяется по максимуму 255 шагами или 255 секундами в зависимости от того, что
раньше наступит. Трудно предсказуемая ситуация может произойти, когда канал
ликвидирован, затем создан снова (для той же комбинации IP-адресов и портов), а какойто пакет из предшествующей сессии, погуляв по Интернет, придет уже во время
следующей. Есть ли гарантия, что он будет верно идентифицирован? Одной из мер,
упомянутых ранее, можно считать использование ограничения по максимальному
времени жизни сегмента (MSL) или TTL, хотя снижение значения TTL не всегда
возможно - ведь IP-пакетами пользуется не только TCP-протокол и нужна очень гибкая
система задания его величины. Во многих приложениях MSL=30 сек (рекомендуемое
значение 2 мин слишком велико). Технический прогресс ставит и некоторые новые
проблемы. Высокопроизводительные каналы (
Гбит/с) уже сегодня могут исчерпать
разнообразие идентификационных кодов пакетов за один сеанс связи. Появление же двух
пакетов с равными идентификаторами может породить неразрешимые трудности. Для
передачи мегабайтного файла по гигабитному каналу требуется около 40 мсек (при этом
287
предполагается, что задержка в канале составляет 32 мсек (RTT=64 мсек)). Собственно
передача этой информации занимает 8 мсек. Из этих цифр видно, что традиционные
протоколы, размеры окон и пр. могут свести на нет преимущества скоростного
(дорогостоящего) канала. Пропускная способность такого канала определяется уже не его
полосой, а задержкой. Понятно также, что необходимо расширить поле размера окна с 16
до 32 бит. Чтобы не изменять формат TCPсегментов, можно сделать код размера окна в
программе 32-разрядным, сохранив соответствующее поле в сегменте неизменным.
Размер окна в этом случае задается как бы в формате с плавающей запятой. При
установлении канала определяется масштабный коэффициент n (порядок) лежащий в
интервале 0-14. Передача этого коэффициента (один байт) осуществляется сегментом
SYN в поле опций. В результате размер окна оказывается равным 65535*2n. Если один из
партнеров послал ненулевой масштабный коэффициент, но не получил такого
коэффициента от своего партнера по каналу, то n считается равным нулю. Эта схема
позволит сосуществовать старым и новым системам. Выбор n возлагается на TCP-модуль
системы.
Чтобы точнее отслеживать вариации RTT, предлагается помещать временные метки в
каждый посылаемый сегмент. Так как в TCP используется одно подтверждение ACK на
несколько сегментов, правильнее будет сказать, что RTT измеряется при посылке каждого
ACK. Способность и готовность партнеров работать в таком режиме временных меток
определяется на фазе установления канала. Более точное вычисление RTT позволяет не
только корректно выбрать временные постоянные для таймеров, правильно вычислить
задержку TIME_WAIT (TIME_WAIT=8*RTO), но и отфильтровать "старые" сегменты.
Идеология временных меток применяется и в алгоритме PAWS (Protection Against
Wrapped Sequence Numbers) для защиты против перепутывания номеров сегментов.
Предлагаемое усовершенствование TCP - T/TCP модифицирует алгоритмы выполнения
операций. T/TCP вводит новую 32-битную системную переменную: число соединений
(CC). СС позволяет сократить число пересылаемых сегментов при установлении канала, а
также отфильтровывать "старые" сегменты, не принадлежащие данной сессии
(установленной связи). Время отклика клиента в рамках указанных алгоритмов
сокращается до суммы RTT и времени обработки запроса процессором. Данные
пришедшие до SYN-сегмента должны буферизоваться для последующей обработки, а не
отбрасываться.
Как уже отмечалось, максимальная длина сегмента (MSS - Maximum Segment Size) в TCPобменах величина переменная. Длина сегмента определяет длину кадра, в который он
вложен. Для локальных Ethernet-сетей MSS=1460 октетов. Чем длиннее кадр, тем выше
пропускная способность сети (меньше накладные расходы на заголовок кадра). С другой
стороны, при передаче дейтаграмм по внешним каналам, где MTU не столь велик,
большое значение MSS приведет к фрагментации пакетов, которая замедлит обмен,
поэтому администратор сети должен взвешивать последствия, задавая значения размера
сегментов. Если MSS явно не задан, устанавливается значение по умолчанию (536 байт),
что соответствует 576-байтной IP-дейтаграмме. Для нелокальных адресов это, как
правило, считалось разумным выбором. Следует, впрочем, заметить, что технология идет
вперед и MTU для региональных соединений уже превышает 1500 байт.
288
17.Объектно-ориентированное программирование на языке С#. Атрибуты.
Индексаторы. Делегаты.
Объектно-ориентированное программирование на языке С#
Управляемый код
Язык программирования C# был разработан как язык, использующий технологию .NET.
Поэтому приложение на C# компилируется в промежуточный код, называемый IL-кодом
(Intermediate Language) или MSIL-кодом (Microsoft intermediate language). Такой код перед
выполнением компилируется JIT-компилятором в команды, отвечающие специфике
конкретного процессора.
Выполнение IL-кода управляется механизмом CLR (Common Language Runtime),
непосредственно осуществляющим JIT-компиляцию (Just In Time), наложение политик
безопасности, предоставление отладочных сервисов, автоматическое управление памятью
(реализация механизма "сборки мусора"). IL-код можно компилировать как при установке
приложения, так и при его выполнении (при этом компилироваться будет не весь код, а
289
только реально вызываемые методы). В процессе компиляции кроме IL-кода
формируются также метаданные, описывающие классы. CLR использует метаданные для
поиска и загрузки классов, размещения объектов в памяти, определения входящих в класс
методов и свойств. CLR можно рассматривать как некоторую виртуальную машину,
выполняющую приложения .NET. Среда CLR обеспечивает единообразное поведение всех
приложений вне зависимости от языка реализации кода. CLS-спецификация (Common
Language Specification) определяет требования к CLS-совместимым языкам
программирования, использующим классы .NET Framework как некоторую
унифицированную систему типов.
Кроме создания MSIL-кода, CLS-совместимый компилятор добавляет в выходной EXEфайл метаданные, описывающие используемые типы и методы. Под метаданными
понимаются некоторые данные, которые описывают другие данные. Используя
метаданные, среда CLR определяет требуемые во время выполнения типы и методы.
Библиотеки классов .NET Framework предоставляют большой набор методов отражения,
применяемых средой CLS и другими приложениями для получения информации о типах и
методах, реализуемых приложением. Отражением называется механизм получения
метаданных. АPI отражения среды .NET представляет собой иерархию классов
System.Reflection.
.NET Framework - это та часть платформы .NET, которая предназначена для создания
надежных, масштабируемых и распределенных приложений, использующих технологии
.NET.
.NET Framework состоит из CLR (Common Language Runtime) - среды времени
выполнения кода, и из набора библиотек классов (иногда называемых BCL - Base Class
Library).
Приложения, выполняемые под управлением CLR, называются управляемым кодом.
В Windows выполняемым приложением является EXE-файл, библиотеки реализуются как
DLL-файлы. Технология .NET предоставляет приложения в виде сборок, описывающих
"логические" EXE- или DLL- файлы. Сборка содержит декларацию, которая описывает ее
содержимое. Так, сборка mscorlib.dll содержит все стандартные пространства имен из
пространства имен System для .NET.
Структура приложения на языке С#
Проектом называется совокупность файлов, содержащих информацию об установках,
конфигурации, ресурсах проекта, а также файлов исходного кода и заголовочных файлов.
Интегрированная среда проектирования VisualStudio.NET позволяет для создания
проектов на разных языках программирования использовать различные инструментальные
средства проектирования (например, Microsoft Visual Basic, Microsoft Visual C#).
Любое приложение на языке C#, разрабатываемое в среде проектирования
VisualStudio.NET, реализуется как отдельный проект. Приложение на языке С# может
состоять из нескольких модулей. Каждый модуль C# может содержать код нескольких
классов (при создании приложения в среде Visual Studio.NET каждый класс C#
290
автоматически помещается в отдельный модудь - файл с расщирением cs). Среда Visual
Studio 2005 позволяет создавать частичные классы ( partial class), когда один класс
содержится в нескольких файлах. Соединение всех частей класса выполняется на этапе
компиляции. (Вообще, частичными также могут быть структуры и интерфейсы.)
Для консольного приложения один из классов, реализуемых модулем, должен содержать
метод Main. В языке C# нет аппарата заголовочных файлов, используемого в языке С++,
поэтому код модуля должен содержать как объявление, так и реализацию класса.
По умолчанию весь код класса, представляющего консольное приложение, заключается в
одно пространство имен, одноименное с именем приложения.
Точкой входа в программу на языке C# является метод Main.
Этот метод может записываться как без параметров, так и с одним параметром типа string.
- указателем на массив строк, который содержит значения параметров, введенных при
запуске программы. В отличие от списка параметров, задаваемых при запуске Сприложения, список параметров C#-приложения не содержит в качестве первого
параметра имя самого приложения.
Код метода указывается внутри фигурных скобок:
static void Main(string[] args)
{
}
Ключевое слово static определяет, что метод Main является статическим методом,
вызываемым без создания экземпляра объекта типа класса, в котором этот метод
определен.
Метод, не возвращающий никакого значения, указывается с ключевым словом void.
Однако, метод Main может возвращать значение типа int.
Например:
static int Main(string[] args)
{
// Проверка числа введенных параметров
if (args.Length == 0)
{ Console.WriteLine("Нет параметров"); return 1; }
// Для получения значения параметра как значения типа long
// используется функция
Parse
long num = Int64.Parse(args[0]);
// Тип long языка C# является псевдонимом типа Int64.
// Поэтому предыдущая запись эквивалентна записи
// long num = long.Parse(args[0]);
// Для получения значения параметра как значения
// определенного типа также можно использовать
// метод ToInt64 класса Convert
long num = Convert.ToInt64(s);
}
Компилятор C# допускает наличие метода Main сразу в нескольких классах. Но для
успешной компиляции и выполнения такого приложения следует указать класс, метод
Main которого следует считать точкой входа в приложение. Это можно сделать, установив
291
опции проекта или указав опцию компилятора /main с именем класса, чей метод Main
будет задействован (например: csc class1.cs class2.cs /main:Class2).
Для того чтобы установить опцию проекта, определяющую "стартовый" класс (Startup
Object), следует открыть диалог свойств проекта Property Pages, в секции Common
Properties на странице General выбрать опцию Startup Object и указать для нее имя
"стартового" класса (рис. 1).
Рис. 15.1. Определение имени "стартового класса"Комментарии в программе
на языке C#
Комментарий в языке С# может быть как однострочным, так и многострочным.
Однострочный комментарий может размещаться в начале строки или после некоторого
кода. Он начинается символами // и завершается концом строки.
Многострочный комментарий располагается между парами символов /* и */ .
Комментарий, вставляемый средой проектирования, например // TODO: Add code to start
application here указывает место, в которое должен быть вставлен код, выполняемый при
запуске приложения.
Существует особый тип комментария, который записывается в summary-секции:
/// <summary> - /// </summary>.
Такой комментарий может быть использован для автоматического документирования
приложения.
При автоматическом документировании приложения создается XML-файл,
представляющий собой информацию о приложении как некоторую иерархию секций. Для
того чтобы при компиляции приложения создавался XML-файл документа, следует
установить опции компиляции следующим образом: в окне Solution Explorer выделить
292
секцию с именем проекта и выполнить команду меню View|Property Pages (или Shift+F4), а
затем, выбрав папку Configuration Properties и страницу свойств Build, установить новое
значение свойства XML Documentation File, описывающее имя файла, в котором будет
сохранен XML-документ.
Пространство имен
Пространство имен позволяет именовать группу данных, таких как классы, переменные
и/или методы. В языке C# все библиотеки классов подключаются как пространства имен.
При автоматическом формировании проекта в среде Visual Studio.NET первой строкой
создаваемого приложения вставляется строка using System.
Ключевое слово using подключает библиотеку классов System (каждая библиотека классов
рассматривается как пространство имен).
Создание пространства имен указывается ключевым словом namespace.
Объявляемые пространства имен могут использоваться для структурирования программы.
Например:
namespace NameSN1.NameSN2
{
class A {}
}
namespace NameSN3
{
using NameSN1.NameSN2;
class B: A {}
}
В среде проектирования Visual Studio.NET библиотеки классов NET Framework образуют
иерархическую структуру пространств имен.
Библиотеку классов среды .NET Framework иногда называют NET Frameworkбиблиотекой или просто Framework-библиотекой.
Объявление пространства имен имеет следующее формальное описание:
namespace name[.name1] ...] {
// объявляемые_данные
}
Пространство имен указывается идентификатором, который может содержать операцию . ,
определяющую составное имя пространства имен.
Объявляемыми данными пространства имен могут быть:

другие пространства имен;

классы;

интерфейсы;
293

структуры;

перечисления.
Для того чтобы иметь возможность обращаться к переменным или методам из
пространства имен, можно использовать один из следующих способов:

имя соответствующей переменной или метода должно быть квалифицировано названием
пространства имен (пространство имен указывается перед именем через точку).
Например:
System.Console.WriteLine("Печать строки");

имя библиотеки должно быть установлено как доступное оператором using.
Например:
using System;
Директива using может использоваться для:

подключения пространства имен. Класс не может быть подключен директивой using;

создания псевдонима имени класса. Псевдоним используется в программе для квалификации членов
данного класса.
Объявление псевдонима имеет следующее формальное описание:
using alias=class_name;
Например:
using System.Console = my_SN;
class MyClass {
public static void Main() { my_SN.WriteLine("123");}
}
Директива using позволяет не квалифицировать каждую переменную пространством имен,
а просто подключить требуемое пространство имен.
Пространство имен System
Библиотека классов .NET Framework среды Visual Studio.NET состоит из иерархически
организованного набора пространства имен. В каждом пространстве имен определяется
набор типов (классы, структуры, нумераторы, интерфейсы). Пространство имен System
содержит набор классов для общеиспользуемых значений и ссылочных типов данных,
событий и обработчиков событий, интерфейсов, атрибутов и т.п. Также это пространство
имен содержит классы, позволяющие выполнять преобразование типов, реализовывать
операции ввода/вывода и т.п.
Все встроенные типы данных языка C# реализованы как классы пространства имен.
Пространство имен System включает такие классы, как Console, String, Array, Math,
Boolean, Byte, Char, DateTime, Decimal, Double, Int16, Int32, Voidи т.п.
Псевдонимы типов языка C# и соответствующие им предопределенные типы
пространства имен являются при написании программы взаимозаменяемыми.
294
Для определения типа переменной можно использовать метод GetType или оператор
typeof.
Библиотека классов NET Framework предоставляет для реализации потоков ввода, вывода
и ошибок класс Console, располагаемый в пространстве имен System.
Класс Console имеет следующие свойства, описывающие соответствующие потоки
ввода/вывода:

In - стандартный поток ввода;

Out - стандартный поток вывода;

Error - стандартный поток вывода ошибок.
Класс Console содержит следующие методы, позволяющие осуществлять чтение и запись
символов из потоков ввода/вывода:

Read - чтение символов из потока ввода;

ReadLine - чтение строки символов из потока ввода;

Write - запись строки символов в поток вывода;

WriteLine - запись в поток вывода строки символа, ограниченной символами конца строки.
Работа с различными видами коллекций реализуется такими классами пространства имен
System.Collections , как:

ArrayList - динамически расширяемый массив;

BitArray - структура данных, каждый элемент которой реализуется как битовое значение;

Hashtable - коллекция связанных ключей и значений;

SortedList - массив, состоящий из пар "ключ-значение";

Queue - очередь;

Stack - коллекция объектов, реализуемая как стек.
Создание классов
Объявление класса
В языке С# определение класса не обязательно должно иметь методы конструктор и
деструктор.
Управляемый код на языке С# избавлен от необходимости освобождения памяти,
выделяемой под объекты, так как это реализуется средой NET Framework. Поэтому
основное назначение деструктора в языке C# - это освобождение неуправляемых
ресурсов, таких как окна, файлы, сетевые соединения и т.п.
Язык C# поддерживает три типа конструкторов:
295

конструкто