Вопросы к государственному экзамену по программе

Вопросы к государственному экзамену по программе
«Разработчик профессионально-ориентированных компьютерных
технологий» ВМК
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

конструктор экземпляра объекта ( instance), используемый при создании объекта;

private-конструктор, указываемый в коде для предотвращения автоматического создания
конструктора по умолчанию. Такой тип конструктора используется для классов, имеющих только
статические члены. Экземпляр объекта с private-конструктором не может быть создан.

статический конструктор ( static), вызываемый для инициализации класса до создания первого
объекта или до первого вызова статического метода. Статический конструктор не может иметь
модификаторы доступа и список параметров.
Конструктор экземпляра объекта имеет следующее формальное описание:
[атрибуты] [модификаторы_доступа]
имя_конструктора([список_формальных_параметров])
[:base (список_аргументов) | :this (список_аргументов)]
{ тело_конструктора }
Ключевое слово base определяет явный вызов конструктора базового класса, а ключевое
слово this - вызов конструктора данного класса с указанным списком параметров.
Например:
public class AClass1
{
public AClass1()// Объявление конструктора
{
}
}
Ключевое слово class определяет имя объявляемого класса. Тело объявляемого класса
указывается в фигурных скобках.
Ключевое слово public - это модификатор доступа, указывающий, что объявляемые после
него идентификаторы (имена классов или методов) будут общедоступны (модификатор
доступа позволяет определить область видимости переменных и методов - членов класса).
По умолчанию все переменные и методы - члены класса, заданные без модификатора
доступа, считаются private-переменными (называемыми иногда приватными или
закрытыми). Приватные переменные доступны только внутри экземпляра класса и не
могут быть использованы во внешних функциях модуля.
Модификаторы доступа
В языке C# применяются следующие модификаторы доступа:

public - доступ не ограничен;

protected - доступ ограничен только наследуемыми классами;

internal - доступ ограничен рамками текущего проекта;

private - доступ ограничен рамками данного класса.
Для любого члена класса или объектного типа разрешено указывать только один
модификатор доступа, за исключением комбинации protected internal, регламентирующей
ограничение доступа наследуемыми классами текущего проекта.
296
Например:
class A
{
protected int x = 100;
}
class B : A
{
void M1()
{
A a1 =
B b1 =
// a1.x
b1.x =
}
}
new A(); // Создание объекта типа A
new B(); // Создание объекта типа B
= 200;
- доступ не разрешен
200;
// Правильно реализованный доступ
Отметим, что пространство имен не может иметь модификатора доступа.
Язык C# поддерживает использование вложенных классов.
Типы верхнего уровня, которые не являются вложенными в другие типы, могут иметь
модификатор доступа только internal (по умолчанию) или public.
Если модификатор доступа не указан, то применяется доступ по умолчанию. В следующей
таблице отображены модификаторы доступа для вложенных типов, являющихся членами
других типов.
Член,
определяемый в:
Модификатор
доступа,используемый по
умолчанию
Допустимые модификаторы
доступа,используемые для членов
enum
Public
-
class
private
public protected internal private protected internal
interface
public
-
struct
private
public internal private
Структуры не могут иметь модификатор
доступа protected,так как не могут быть
наследуемы
Например:
using System;
namespace MyNameSpace
{
public class A
{
public static int myPublicInt;
internal static int myInternalInt;
private static int myPrivateInt = 0;
public class Nest1
// "Вложенный" член класса
{
public static int myPublicInt;
internal static int myInternalInt;
297
private static int myPrivateInt = 0;
}
private class Nest2
// "Вложенный" член класса
{
public static int myPublicInt = 0;
internal static int myInternalInt = 0;
private static int myPrivateInt = 0;
}
}
public class MyClass
{
public static int Main()
{
// Доступ к членам класса A:
A.myPublicInt = 1; // Доступ не ограничен
A.myInternalInt = 2; // Только в текущем проекте
// A.myPrivateInt = 3; - ошибка: нет
// доступа вне класса
// Доступ к членам класса Nest1:
A.Nest1.myPublicInt = 1; // Доступ не ограничен
A.Nest1.myInternalInt = 2;
// Только в текущем проекте
// A.Nest1.myPrivateInt = 3; - ошибка: нет
// доступа вне класса Nest1
// Доступ к членам класса Nest2:
// A.Nest2.myPublicInt = 1;
- ошибка: нет
// доступа вне класса A
// A.Nest2.myInternalInt = 2; - ошибка: нет
// доступа вне класса A
// A.Nest2.myPrivateInt = 3; - ошибка: нет
// доступа вне класса Nest2
return 0;
}
}
}
Листинг 15.1. (html, txt)
Создание экземпляра класса
Для использования переменных или методов класса следует создать объект - экземпляр
класса.
В языке C# экземпляр класса всегда создается при помощи оператора new. Если класс
имеет несколько конструкторов, то при создании переменной указывается требуемый
конструктор.
Место выделения памяти под объект зависит от типа создаваемого объекта: объекты
ссылочных типов размещаются в куче, а объекты размерных типов - в стеке.
Объявление переменной объектного типа в языке С# не создает объекта, а только
определяет идентификатор указанного типа. Обратите внимание, что во многих объектноориентированных языках, таких как С++, объявление переменной объектного типа также
становится и созданием экземпляра данного типа.
Например:
298
using System;
namespace MyNS
{
public class A
{ public A()
// Конструктор без параметров
{ Console.WriteLine("A()"); }
public A(int i)
// Конструктор с одним параметром
{ Console.Write("A(i) i= ");
Console.WriteLine(i);
}
}
}
using System;
namespace MyNS
{
class MyClass
{
static void Main(string[] args)
{ A acl1= new A();
// Создание экземпляра класса
A acl2= new A(987);
}
}
}
Явный вызов конструктора
Определение конструктора может содержать явный вызов конструктора того же класса.
Вызываемый конструктор указывается после имени определяемого конструктора со
списком параметров через символ двоеточия. Вызываемый конструктор может быть
определен ключевым словом this - для вызова конструктора из того же самого класса, или
ключевым словом base - для вызова конструктора базового класса. Явно вызываемый
конструктор будет выполнен до выполнения конструктора, в котором он указывается.
Например:
public class A
{ public A():this(222) // Конструктор без параметров
{ }
public A(int i) // Конструктор с одним параметром
{ }
}
Методы члены класса
Среда проектирования Visual Studio .NET дает возможность использовать мастер создания
метода - члена класса (в окне Class View выбрать имя класса и выполнить команду
контекстного меню Add|Add Metod). Список Modifier. диалога. C# Metod Wizard
позволяет указать один из следующих модификаторов параметра метода:

none - определяет передачу параметров по значению. Если внутри метода будет изменено значение
фактического параметра, то вне метода его значение останется прежним;

ref - определяет передачу параметров по ссылке. Изменение параметра внутри метода останется и
после завершения метода. ref-параметр перед использованием обязательно должен быть
инициализирован;
299

out - определяет передачу параметров по результату. При завершении метода конечное значение
формального параметра присваивается указанному при вызове фактическому параметру. При этом в
момент вызова метода фактический параметр может не быть инициализирован.
Например:
public void Metod1(int i, ref int j, out int k)
{
}
При обращении к методу или полю - членам класса используется операция . (точка) доступ к члену класса. Имя поля или метода члена класса квалифицируется именем
экземпляра класса.
Язык C# позволяет использовать методы с переменным числом параметров. Для метода с
переменным числом параметров должны быть выполнены следующие правила:

переменный список параметров выступает как единый параметр и указывается ключевым словом
params;

кроме переменного списка параметров, никаких других параметров после ключевого слова params в
методе указывать нельзя;

в методе может быть указано только одно ключевое слово params, определяющее переменный
список параметров.
Количество параметров в переменном списке параметров определяется свойством Length .
Например:
using System;
public class MyClass1
{
public static void UseParams1(params int[] list)
{
// Отображение списка параметров
for ( int i = 0 ; i < list.Length ; i++ )
Console.WriteLine(list[i]);
}
public static void UseParams2(params object[] list)
{ // В переменном списке параметров могут быть
// объекты различных типов
for ( int i = 0 ; i < list.Length ; i++ )
Console.WriteLine((object)list[i]);
}
public static void UseParams3(int k,params object[] list)
{ // В переменный список параметров
// включаются параметры, начиная
// со второго
for ( int i = 0 ; i < list.Length ; i++ )
Console.WriteLine((object)list[i]);
}
public static void Main()
{
UseParams1(1, 2, 3, 4, 5);
UseParams1(1, 2);
int[] myarray = new int[3] {1,2,3};
UseParams1(myarray);
300
UseParams2(111, 'f', "string");
UseParams3(111, 'f', "string");
}
}
Листинг 15.2. (html, txt)
Индексаторы
Создание индексаторов
Индексатор позволяет работать с классом или структурой таким образом, как если бы это
были массивы. Индексация класса выполняется по индексу, указываемому как параметр.
Иногда классы, используемые как индексаторы, называют классами-индексаторами.
Объявление индексатора может иметь следующее формальное описание:
[атрибуты] [модификаторы] тип this [[атрибуты]
тип_параметра идентификатор_параметра .,...]
{объявление аксессоров}
Индексатор должен иметь как минимум один параметр. Тип и идентификатор параметра
указываются в квадратных скобках после ключевого слова this.
Среда проектирования Visual Studio.NET позволяет использовать мастер создания
индексатора: для этого в окне Class View следует выделить имя класса и выполнить
команду контекстного меню Add|Add Indexer.
Диалог C# Indexer Wizard (рис. 17.1) позволяет определить параметры создаваемого
индексатора.
Рис. 17.1. Диалог C# Indexer Wizard
В поле Indexer Аcess указывается модификатор доступа для индексатора. Это могут быть
следующие модификаторы:

public - доступ не ограничен;
301

protected - доступ ограничен только наследуемыми классами;

internal - доступ ограничен рамками текущего проекта;

private - доступ ограничен рамками данного класса;

protected internal - ограничение доступа наследуемыми классами текущего проекта.
В поле Indexer Type определяется тип массива, используемого для индексатора. В
качестве типа индексатора может быть выбран любой из следующих типов:

bool - логическое значение true или false;

decimal - 128-битовый тип данных (1,0 * 10-28 до 7,9 * 1028);

int - 32-битовое целочисленное значение;

sbyte - знаковое 8-битовое целое (от - 128 до 127);

uint - беззнаковое 32-битовое целочисленное значение (от 0 до 4 294 967 295);

byte;

double - 64-битовый тип данных (±5,0 * 10-324 до ±1,7 * 10308);

long - 64-битовое целочисленное значение;

string;

ulong;

char;

float- 32-битовый тип данных (±1.5 * 10-45 до ±3.4 * 1038);

object;

short;

ushort.
Поле Parameter Name содержит имя параметра.
На панели Indexer Modifiers можно выбрать одну из следующих опций:

None - индексатор не содержит дополнительных модификаторов;

Virtual - реализация индексатора может быть переопределена в наследуемых классах, для
индексатора указывается ключевое слово virtual;

Abstract - индексатор является членом абстрактного класса, для индексатора указывается ключевое
слово abstract.
Ключевое слово this используется как имя индексатора, так как с классом, содержащим
индексатор, можно манипулировать как с массивом.
Например:
302
public int this[int ind1] // Индексатор типа int
// с одним параметром типа int - ind1
{ get
{ return 0;
}
set
{
}
}
Методы-аксессоры
После определения параметра в фигурных скобках указаны два метода-аксессора. getаксессор возвращает значение данных по указанному индексу,а set-аксессор
устанавливает значение данных с указанным индексом. Устанавливаемое значение
задается ключевым словом value.
Индексатор устанавливает и возвращает значения некоторого массива. Такой массив для
аксессора должен быть создан. Типы используемого массива и аксессора должны
совпадать. Например для целочисленного аксессора можно объявить следующий массив:
private int [] imyArray = new int[50];
Теперь, чтобы использовать акссессор, следует:
1.
определить возвращаемое методом-аксессором значение (например: return imyArray[ind1];);
2.
определить устанавливаемое методом-аксессором значение (например: imyArray[ind1]= value;).
В результате класс, содержащий аксессор, будет иметь следующее объявление:
public class AClass1
{
public AClass1() { }
private int [] imyArray = new int[20];
public int this[int ind1]
{
get
{ return imyArray[ind1]; }
set
{ imyArray[ind1]= value; }
}
}
Элементы индексатора
Объект класса, используемого как аксессор, создается обычным образом. Инициализация
элементов аксессора указывается как присвоение значений элементам массива. Доступ к
элементам аксессора записывается как доступ к элементам массива.
Например:
AClass1 ac1= new AClass1();
ac1[0]=5;
ac1[1]=6;
Console.WriteLine("ac1[0]= {0}, ac1[1]= {1}",
ac1[0],ac1[1]);
303
Индексаторы на базе многомерных массивов
Для одного класса может быть создано несколько индексаторов. Индексаторы должны
различаться числом параметров.
Например:
public class AClass1
{
public AClass1() {
}
private int [] imyArray = new int[20];
public int this[int ind1]
{ get { return imyArray[ind1];
}
set { imyArray[ind1]= value; }
}
private int [,] imyArray2 = new int[2,10];
public int this[int ind1, int ind2]
{ get {return imyArray2[ind1,ind2]; }
set {imyArray2[ind1,ind2]= value; }
}
}
Атрибуты
Язык С# позволяет создавать атрибуты для различных элементов языка, таких как типы,
методы, поля и свойства классов. Данные, хранимые в атрибутах, можно запрашивать во
время выполнения приложения. Атрибуты - это механизм, позволяющий создавать
самоописывающиеся приложения.
Использование атрибутов позволяет получать метаданные периода выполнения.Каждый
атрибут - это экземпляр класса, производного от System.Attribute.
Назначаемый типу или члену класса атрибут указывается в квадратных скобках перед
типом или членом класса.
Про атрибут, указанный для класса, иногда говорят, что этот атрибут "прикреплен к
целевому типу".
Класс Attribute пространства имен System предоставляет следующие члены класса:

GetType - получает объект типа Type текущего экземпляра;

ToString - возвращает строку, описывающую данный объект;

IsDefined - определяет, существует ли атрибуты заданного типа, назначенные указываемому члену
класса;

GetCustomAttribute - запрашивает атрибут заданного типа для указанного члена класса.
Для класса Attribute определено свойство TypeId, определяющее уникальный
идентификатор атрибута.
Назначение атрибута
Для того, чтобы назначить атрибут элементу кода, можно:
304

определить новый класс атрибута

использовать существующий класс атрибута из библиотеки NET Framework.
Атрибут указывается в квадратных скобках перед элементом, которому он назначается.
Назначаемый атрибут инициализируется вызовом конструктора с соответствующими
параметрами.
Класс System.ObsoleteAttribute позволяет помечать код и задавать информацию, которая
будет отображаться как Warning во время компиляции приложения. Этот класс
предназначается для возможности указания некоторого кода модуля как
"устаревшего".Для того чтобы использовать существующий класс для назначаемого
методу атрибута, следует:
1.
создать метод, использующий атрибут (например, метод, при каждом вызове которого компилятор
будет формировать сообщение Warning с указанным в атрибуте кодом);
2.
ввести перед определением метода в квадратных скобках имя класса атрибута (например, класса
ObsoleteAttribute).
Например:
[ObsoleteAttribute
("Сообщение, отображаемое
компилятором как Warning")]
public static void M1( ) {return ;
// Компилятор будет выдавать предупреждение при
// каждом вызове данного метода, которому назначен
// соответствующий атрибут. Например:
// c:\c#_project\pr1\class1.cs(23,4): warning
// CS0618: 'pr1.Class1.M1()' is obsolete:
// 'Сообщение, отображаемое компилятором как
//
Warning'
}
Язык С# при назначении атрибута позволяет не указывать суффикс Attribute. Так, вместо
[ObsoleteAttribute("")] можно записать [Obsolete("")].
Класс атрибута должен иметь хотя бы один public-конструктор.
Создание атрибута
Создание атрибута начинается с создания класса, реализующего атрибут. Такой класс
должен быть наследуем от любого класса атрибута. Класс атрибута всегда должен иметь
модификатор доступа public.
Класс атрибута всегда непосредственно или опосредованно наследуется от класса
System.Attribute.
Например:
public class MyAttribute : System.Attribute
{
public MyAttribute()
305
{
}
}
Параметры атрибута
По умолчанию код класса атрибута содержит конструктор без параметров.Для того чтобы
иметь возможность при назначении атрибута сохранять для типа или члена класса
некоторые параметры, эти параметры надо задать как параметры конструктора класса
атрибута. Параметры атрибута могут объявляться как переменные члены класса.
Для доступа к защищенным переменным членам класса в языке C# используются
свойства.
Для создания свойства в среде проектирования VisualStudio.NET можно использовать
мастер построения свойства: для этого в окне Class View следует выделить секцию c
именем класса и выполнить команду контекстного меню Add|Add Property.
В диалоге C# Property Wizard (рис. 17.2) в поле Property Name следует указать имя
создаваемого свойства.
Рис. 17.2. Диалог C# Property Wizard
Тип создаваемого свойства выбирается из списка Property type.
На панели Accessors переключатели get и set определяют, какие методы-аксессоры будут
созданы. Например:
using System;
namespace MyPr1
{
[AttributeUsage(AttributeTargets.All)]
public class MyAttribute : System.Attribute
{
306
private string name; // Используются как
private int kod;
// параметры атрибута
public MyAttribute(string name)
{ // Конструктор
this.name = name;
this.kod = 12345;
}
// Свойство Name
public string Name
{ get { return name; } }
// Свойство Kod
public int Kod
{ get { return kod; }
set {kod=value; } // Назначение
// защищенной переменной члену
// класса значения параметра
}
}
}
// Для назначения некоторому классу данного
// атрибута перед объявлением класса следует
// указать строку типа [My("NameClass", Kod=123)]
Позиционные и именованные параметры атрибута
При назначении классу или члену класса атрибута используется конструктор атрибута со
списком параметров. Параметры могут быть:

позиционными;

именованными.
Позиционные параметры указываются в порядке, который определяется списком
параметров конструктора атрибута. Позиционные параметры всегда должны быть указаны
при назначении атрибута.
Именованные параметры отсутствуют в списке параметров конструктора атрибута.
Значения, задаваемые для именованных параметров, используются для инициализации
полей и свойств создаваемого экземпляра атрибута. Список именованных параметров
указывается через запятую после списка позиционных параметров. Каждый именованный
параметр определяется как Имя_параметра=Значение_параметра.
В предыдущем примере параметр name использовался как позиционный параметр, а kod как именованный (по умолчанию значение переменной kod, доступной через свойство
Kod, устанавливается равным конкретному значению. Если при назначении атрибута явно
не будет задан именованный параметр, то при создании экземпляра атрибута будет
использовано значение по умолчанию).
Параметры атрибута могут указываться константными значениями следующих типов:

bool, byte, char, short, int, long, float, double;

string;

System.Type;
307

enums;

object (аргумент для параметра атрибута типа object должен быть константным значением
вышеуказанных типов);

одноразмерные массивы любых вышеуказанных типов.
Используемость атрибута
Атрибуты могут быть использованы для различных элементов языка. Для того чтобы
специфицировать, каким образом и для каких элементов можно использовать данный
класс атрибута, библиотека NET Framework предоставляет класс
System.AttributeUsageAttribute.
Спецификация используемости атрибута указывается в квадратных скобках перед именем
определением класса.
Например:
[AttributeUsage(AttributeTargets.All,
Inherited = false,
AllowMultiple = true)]
Элементы языка, которым может быть назначен атрибут, указываются значением или
набором значений перечислимого типа AttributeTargets.
Например, для использования данного атрибута только для классов или методов перед
определением класса атрибута следует записать:
[AttributeUsage (AttributeTargets.Class |
AttributeTargets.Method)]
Спецификация используемости атрибута имеет следующее формальное описание:
[AttributeUsage(
доступные_элементы,
AllowMultiple=true_или_false,
Inherited=наследуемость
)]
Доступные элементы определяют те элементы языка, для которых может быть назначен
данный атрибут. По умолчанию используется значение AttributeTargets.All (доступен для
всех элементов).
Если именованный параметр AllowMultiple равен true, то классу или члену класса может
быть назначено несколько атрибутов.
Параметр Inheritedопределяет, наследуется ли данный атрибут производным классом (по
умолчанию - false).
Перечислимый тип AttributeTargets определяет следующее множество значений:

All - все элементы языка;

Assembly - сборки;
308

Class - классы;

Constructor - конструкторы;

Field - поля;

Method - методы;

Property - свойства;

Delegate - делегаты;

Enum - нумераторы;

Event - события;

Interface - интерфейсы;

Module - модули;

Parameter - параметры;

ReturnValue - возвращаемые значения;

Struct - структуры.
Доступ к атрибуту
Значения атрибутов или их существование могут быть запрошены во время выполнения
приложения.
При запросе для класса или для члена класса данных о прикрепленных к нему атрибутах
применяется отражение. Отражением называется функция, используемая во время
выполнения приложения для получения метаданных, в том числе и заданных атрибутами.
Для реализации отражения библиотека NET Framework предоставляет несколько классов,
базовым для которых служит класс отражения System.Reflection.
Основные методы отражения, используемые для запроса атрибутов, предоставляются
классами System.Reflection.MemberInfo и System.Reflection.Assembly. Так, метод
GetCustomAttributes позволяет определить атрибуты, присущие данному объекту.
Например:
class MyClass
{
public static void Main()
{
System.Reflection.MemberInfo info =
typeof(MyClass);
object[] attr = info.GetCustomAttributes(true);
for (int i = 0; i < attr.Length; i ++)
{ System.Console.WriteLine(attr[i]); }
}
}
309
В результате выполнения данного кода в массив будут помещены классы всех
назначенных атрибутов, а также класс System.Reflection.DefaultMemberAttribute. Доступ к
типу объекта может быть реализован посредством класса Type . Метод Object.GetType
возвращает объект типа Type , представляющий тип экземпляра объекта. Объект типа
Type представляет собой ассоциированный с типом объект, используемый для доступа к
метаданным типа.
Используя класс Type, можно создать объект для типа, экземпляр которого еще не был
создан.
Например:
Type t= typeof(MyClass1);
Для создания объекта типа, ассоциированного с типом существующего экземпляра
объекта, следует использовать метод GetType.
Например:
Type t = obj1.GetType(); , где obj1 экземпляр класса MyClass1.
При использовании объекта типа атрибута метод GetCustomAttribute возвращает значения
атрибута, который назначен указанному параметрами объекту: первый параметр метода
определяет ассоциированный объект, а второй - указывает класс атрибута.
Например:
MyAttribute MyAttr =
(MyAttribute) Attribute.GetCustomAttribute(
t,
typeof(MyAttribute));
Следующий пример иллюстрирует доступ к значениям атрибутов.
class Class1
{ static void Main(string[] args)
{
// Создание объекта, ассоциированного с типом AClass1
Type t= typeof(AClass1);
MyAttribute MyAttr =
(MyAttribute) Attribute.GetCustomAttribute(
t,
typeof (MyAttribute));
if(null == MyAttr)
{Console.WriteLine("Атрибут не найден");}
else
{
Console.WriteLine("Атрибут name = {0},
атрибут kod = {1}" ,
MyAttr.Name,
// Возвращает значение
// поля Name атрибута MyAttribute
MyAttr.Kod); }
}
}
[AttributeUsage(AttributeTargets.All)]
public class MyAttribute : System.Attribute
{ private string name;
private int kod;
310
public MyAttribute(string name)
{this.name = name; this.kod = 10; }
public string Name { get { return name;} }
public int Kod { get { return kod; }
set {kod=value;
}
}
}
[My("NameOfClass", Kod=123)]
public class AClass1
{ public AClass1() { }
private int [] iArr = new int[10];
public int this[int ind1] {
get { return iArr[ind1];}
set { iArr[ind1]= value; }
}
}
Листинг 17.1. (html, txt)
Класс Type
Класс System.Type имеет следующее формальное описание:
public abstract class Type : MemberInfo, IReflect.
Две ссылки типа Type на объект будут ссылаться на один и тот же объект только в том
случае, если они представляют одинаковый тип.
Экземпляр типа Type может быть представлен любым из следующих типов:

классы;

размерные типы (Value types);

массивы;

интерфейсы;

указатели;

нумераторы.
Ссылка на объект Type, ассоциируемый с типом, может быть получена одним из
следующих способов:

метод Object.GetType возвращает объект Type, представляющий тип экземпляра объекта;

статический метод GetType возвращает объект Type, который представляет тип, указанный
посредством своего полного имени;

методы Module.GetTypes, Module.GetType, и Module.FindTypes возвращают объект Type, который
представляет типы, определенные в модуле. Метод GetTypes позволяет получить массив объектов
для всех общедоступных и защищенных типов, определенных в модуле;

метод FindInterfaces возвращает отфильтрованный список интерфейсов типов, которые
поддерживаются данным типом;

метод GetElementType возвращает объект Type, который представляет элемент;
311

методы GetInterfaces и GetInterface возвращают объект Type, который представляет интерфейс,
поддерживаемый типом;

метод GetTypeArray возвращает массив объектов Type, которые представляют типы, заданные
посредством набора объектов;

методы GetTypeFromProgIDи GetTypeFromCLSID возвращают объект Type , который указывается
через ProgID или CLSID (методы предоставляются для совместимости с СОМ);

метод GetTypeFromHandle возвращает объект Type , который указывается посредством дескриптора
(метод предоставляется для совместимости);

оператор typeof получает объект Type для указанного типа.
Метаданные - это информация о выполнимом модуле, получаемая во время выполнения
приложения. К такой информации относятся и данные о типе. В случае неправильного
указания имени типа возникает исключение. Поэтому указание типа следует заключать в
блок try-catch .
Например:
try
{
Type tp=Type.GetType(s);
Console.WriteLine("Имя типа : {0}",tp.FullName);
}
catch (System.NullReferenceException)
{Console.WriteLine("Ошибка задания типа");}
Класс Type предоставляет большой набор свойств для запроса информации по типу,
включая следующие:

FullName - возвращает имя типа;

IsClass - определяет, является ли тип классом;

IsAbstract - определяет, является ли тип абстрактным классом;

IsNestedPublic - определяет, является ли тип вложенным и общедоступным;

IsPublic - определяет, является ли данный тип общедоступным;

IsNotPublic - определяет, является ли данный тип защищенным;

IsSealed - определяет, является ли тип конечным (не может быть базовым классом);

IsArray - определяет, представляет ли указанный тип массив;

GUID - возвращает значение типа GUID, ассоциированное с данным типом (такое значение
хранится в реестре Windows).
Например:
Type myType = typeof(MyClass1);
Guid myGuid =(Guid) myType.GUID;
312

IsNestedAssembly - определяет, является ли тип вложенным и видимым только в своей собственной
сборке;

Module - возвращает модуль (DLL) в котором объявлен данный тип;

Namespace - возвращает пространство имен, содержащее данный тип;
Свойство IsByRef позволяет определить, передается ли указанный элемент по типу, а
свойство Assembly определяет сборку.
Например:
Type tp=Type.GetType(s);
Console.WriteLine("\tПередается по ссылке ? : {0}",tp.IsByRef);
Получение информации о методах
Используя метод GetMethods, можно получить информацию о методах. Такая информация
заносится в массив типа MethodInfo.
Например:
public static void Main()
{
Type myType =(typeof(MyClass1));
// Получить методы с доступом public
MethodInfo[] myArrMethodInfo =
myType.GetMethods(BindingFlags.Public
|BindingFlags.Instance
|BindingFlags.DeclaredOnly);
Console.WriteLine("\n Число методов public =:"
+myArrMethodInfo.Length);
Console.WriteLine("Имена методов public : ");
// Отобразить имена всех методов
MyPrintMethodInfo(myArrMethodInfo);
// Получить методы с защищенным доступом
MethodInfo[] myArrMethodInfo1 =
myType.GetMethods(BindingFlags.NonPublic
|BindingFlags.Instance
|BindingFlags.DeclaredOnly);
Console.WriteLine("\n Число защищенных методов:"
+myArrMethodInfo1.Length);
}
public static void MyPrintMethodInfo(MethodInfo[] a)
{
for(int i=0;i<a.Length;i++)
{
MethodInfo myMethodInfo = (MethodInfo)a[i];
Console.WriteLine("\n" + myMethodInfo.Name);
}
}
Листинг 17.2. (html, txt)
313
Объявление делегата
Использование делегата для вызова методов
Делегат объявляет новый ссылочный тип.
Делегат позволяет передавать функцию как параметр.
Объявление делегата имеет следующее формальное описание:
[атрибуты] [модификаторы] delegate тип_результата имя_делегата
([список_формальных параметров]);
Модификаторами делегата могут быть:

new

public

protected

private

internal

unsafe (если в списке параметров используется указатель).
Тип результата должен соответствовать типу результата используемого метода. При
создании делегата требуется, чтобы передаваемый как делегат метод имел ту же
сигнатуру метода, что и в объявлении делегата.
Например:
using System;
delegate void MyDelegate();
// Этот делегат позволяет
// вызывать методы без параметров
// и без возвращаемого значения
Для вызова метода через делегата следует создать экземпляр делегата, передав ему в
качестве параметра метод, имеющий ту же сигнатуру, что и у делегата, а затем выполнить
вызов. Для статического метода в качестве параметра передается имя метода,
квалифицированное именем класса.
Например:
using System;
delegate void MyDelegate();
namespace MyDelegat1
{ class Class1
{[STAThread]
static void Main(string[] args) {
CA var1= new CA();
// Экземпляр делегата для нестатического метода:
MyDelegate F_d =
new MyDelegate(var1.F_Instance);
F_d();
// Экземпляр делегата для статического метода:
314
F_d = new MyDelegate(CA.F_Static);
F_d();
} }
public class CA
{ public CA()
{ }
public void F_Instance()
{ Console.WriteLine("Вызов метода класса с
использованием делегата"); }
public static void F_Static()
{ Console.WriteLine("Вызов статического метода с
использованием делегата"); }
}
Применение делегатов как методов обратного вызова
Метод обратного вызова используется для передачи одному методу в качестве параметра
другого метода, который может быть вызван через переданный "указатель" на метод.
Методы обратного вызова могут применяться в различных целях. Наиболее часто их
используют для реализации асинхронной обработки данных или определения кода,
выполняющего дополнительную обработку данных.
Например:
using System;
namespace MyDelegatе1
{
class Class1
{[STAThread]
static void Main(string[] args) {
CA var1= new CA();
// Создание экземпляра делегата
CA.Metod1Callback myCall =
new CA.Metod1Callback(Class1.Metod2); // Значение
// параметра, передаваемое методу обратного
// вызова Class1.Metod2, определено
// в методе Metod1 как "1".
// Выполнение метода обратного вызова (Metod2),
// переданного в качестве параметра
CA.Metod1(myCall);
}
static void Metod2 (string str2){
Console.WriteLine("Выполняется метод Metod2");
Console.WriteLine(str2);
}
}
}
using System;
namespace MyDelegatе1
{
public class CA
{ public CA() { }
public delegate void Metod1Callback(string str1);
public static void Metod1(Metod1Callback callback)
{
315
Console.WriteLine("Выполняется метод Metod1");
// Параметр callback используется для вызова
// метода обратного вызова и передачи ему
// параметра (строки "1")
callback("1");
}
}
}
Листинг 18.1. (html, txt)
В результате выполнения этого приложения сначала будет вызван метод Metod1, а затем
Metod2.
Применение неуправляемого кода
По умолчанию приложения на C# относятся к управляемому коду. Но при необходимости
управляемый код может взаимодействовать с неуправляемым кодом. К неуправляемому
коду, вызываемому из управляемых C# приложений, можно отнести функции DLLбиблиотек и сервисы COM-компонентов. Приложение управляемого кода на языке C#
также может включать фрагменты небезопасного кода. Небезопасный код тоже относится
к неуправляемому коду, так как выделение и освобождение памяти в нем не
контролируется исполняющей средой .NET.
Небезопасный код
Фрагмент небезопасного кода следует помечать ключевым словом unsafe.
Например:
int i1;
unsafe {int *i2=&i1;}
Ключевым словом unsafe требуется обязательно помечать любой фрагмент кода, который
содержит указатель.
Модификатор unsafe может быть указан для методов, свойств и конструкторов (за
исключением статических конструкторов), а также для блоков кода.
Например:
using System;
class Class1
{
unsafe static void M1 (int* p)
// Небезопасный код: указатель на int
{
*p *= *p;
} // *p - доступ к значению
unsafe public static void Main()
// Небезопасный код: применен оператор
// получения адреса (&)
{ int i = 4;
M1 (&i);
Console.WriteLine (i);
}
}
316
Чтобы использовать небезопасный код, следует установить опцию компилятора /unsafe.
Для этого достаточно выбрать имя проекта в окне Solution Explorer и через контекстное
меню вызвать диалогProperty Pages (рис. 18.1) , а затем на странице Configuration
Properties | Build установить значение опции Allow unsafe code blocks равным True.
Рис. 18.1. Диалог Property Pages
Указатели можно использовать только с размерными типами, массивами и строками. При
задании указателя на массив первый элемент массива должен быть размерного типа.
Выполняющая среда .NET для эффективного управления памятью при удалении одних
объектов "перемещает" другие объекты, чтобы исключить фрагментацию памяти
свободными блоками памяти. Таким образом, выполняющая среда .NET по умолчанию не
гарантирует, что объект, на который получен указатель, всегда будет иметь один и тот же
адрес. Для предотвращения перемещения объекта следует использовать оператор fixed,
который имеет следующее формальное описание:
fixed ( тип* имя_указателя = выражение )
выполняемый_оператор_или_блок
В качестве типа можно указывать любой неуправляемый тип или void. Выражение
является указателем на заданный тип. Фиксация объекта применяется только для
указанного выполняемого оператора или блока. Доступ к фиксированной переменной не
ограничен областью видимости небезопасного кода. Поэтому фиксированная переменная
может указывать на значение, располагаемое в более широкой области видимости, чем
данная область видимости небезопасного кода. При этом компилятор C# не выдает
предупреждений о такой ситуации.
Однако компилятор C# не позволит установить указатель на управляемую переменную
вне оператора fixed.
Например:
class Point
317
{ public int x, y; }
class Class1
{[STAThread]
static void Main(string[] args)
{
unsafe
{
Point pt = new Point();
// pt - это управляемая
// переменная
fixed ( int* p = &pt.x ) { *p = 1 }
// pt.x // указывает на значение
// размерного типа
}
} }
Одним оператором fixed можно фиксировать несколько указателей, но только в том
случае, если они одного типа.
Например:
fixed (byte* pa1 = array1, pa2 = array2) {...}
В том случае, если требуется зафиксировать указатели различных типов, можно
использовать вложенные операторы fixed.
Например:
fixed (int* p1 = &p.x)
fixed (double* p2 = &array1[5]) {
}
Указатели, которые инициализированы оператором fixed, не могут быть изменены. Если
объект, на который устанавливается указатель, размещается в стеке (например,
переменная типа int), то его местоположение фиксировать не требуется.
Разместить блок памяти в стеке можно и явным образом, используя оператор stackalloc,
который имеет следующее формальное описание:
тип * имя_указателя = stackalloc тип [ выражение ];
В качестве типа может быть указан любой неуправляемый тип.
Например:
using System;
class Class1
{public static unsafe void Main()
{
int* a1 = stackalloc int[100];
int* p = a1;
// Указатель на первый
// элемент массива
*p++ = *p++ = 1;
for (int i=2; i<100; ++i, ++p)
*p = p[-1] + p[-2];
for (int i=0; i<10; ++i) Console.WriteLine (a1[i]);
}
}
318
Время жизни указателя, инициализированного с применением stackalloc, ограничено
временем выполнения метода, в котором этот указатель объявлен. Инициализировать
указатели посредством stackalloc можно только для локальных переменных.
DLL-библиотеки
Для того чтобы вызвать метод из DLL-библиотеки, его следует объявить с модификатором
extern и атрибутом DllImport.
Например:
[DllImport("Имя_библиотеки.dll")]
static extern int M1(int i1, string s1);
Класс атрибута DllImportAttribute имеет следующее определение:
namespace System.Runtime.InteropServices
{
[AttributeUsage(AttributeTargets.Method)]
public class DllImportAttribute: System.Attribute
{
public DllImportAttribute(string dllName) {...}
public CallingConvention CallingConvention;
public CharSet CharSet;
// Набор символов
public string EntryPoint;
// Имя метода
public bool ExactSpelling;
// Точное
// соответствие написания имени метода
public bool PreserveSig;
// Определяет, будет ли
// предотвращено изменение сигнатуры метода (по умолчанию
// установлено значение true).
// При изменении сигнатуры возвращаемое значение будет
// иметь тип HRESULT и будет добавлен out-параметр retval
public bool SetLastError;
public string Value { get {...} }
}
}
Атрибут DllImport имеет один позиционный параметр, определяющий имя DLLбиблиотеки, и пять именованных параметров. Параметр EntryPoint позволяет указать имя
метода из DLL-библиотеки. При этом имя метода, помечаемого данным атрибутом, может
отличаться от имени метода в DLL-библиотеке.
Например:
[DllImport("myDll.dll", EntryPoint="M1")]
static extern int New_name_of_M1(int i1, string s1);
Именованный параметр CharSet определяет используемый в DLL-библиотеке набор
символов (ANSI или Unicode). По умолчанию используется значение CharSet.Auto.
Например:
[DllImport("myDll.dll", CharSet CharSet.Ansi)]
static extern int M1(int i1, string s1);
Для каждого типа параметра при вызове метода из DLL-библиотеки выполняющая среда
.NET производит подразумеваемое по умолчанию преобразование типов (например, тип
319
string в тип LPSTR (Win32). Для того чтобы явным образом указать тип, используемый в
методе DLL-библиотеки, следует применить к параметру атрибут MarshalAsAttribute.
Например:
[DllImport("myDll.dll", CharSet CharSet.Unicode)]
static extern int M1(int i1,
[MarshalAs(UnmanagedType.LPWStr)]
string s1);
Атрибут MarshalAsAttribute может быть прикреплен к полю, методу или параметру.
Прикрепление данного атрибута к методу позволяет указать явное преобразование типа
для возвращаемого значения.
18.Адресация в стеке TCP/IP: адресация устройств (ip-адрес), сетей
(понятии маски сети), сервисов (понятие порта). Адресация устройств
при помощи доменных имен. Универсальная система адресации
ресурсов всемирной паутины (понятия URI, URL, URN).
320
IP-адресация версии 4
На сетевом уровне (или IP) мы должны уникально идентифицировать каждое устройство в
Интернете, чтобы обеспечить глобальную связь между всеми устройствами. Эта
адресация напоминает нумерацию в телефонной сети, где каждый абонент имеет
уникальный номер телефона, содержащий международный код (код страны),
междугородний код города и т. д., который идентифицирует его местоположение.
Установление соединения между двумя и более узлами происходит на основе обработки
адресной информации, которая по мере необходимости обрабатывается устройствами 3-го
уровня в маршрутизаторах. К адресу предъявляются следующие требования:

адрес должен быть универсальным;

адрес должен иметь иерархическую структуру, удобную для обработки соответствующими узлами;

адрес должен быть удобен для пользователя.
Идентификатор, используемый на уровне IP набора протокола TCP/IP, чтобы
идентифицировать каждое устройство, подключенное к Интернету, назван адресом
Интернета, или адресом IP. Адрес IP — двоичный адрес на 32 бита, который уникально и
универсально определяет подключение хоста или маршрутизатора к Интернету.
Адреса IP уникальны. Они уникальны в том смысле, что каждый адрес определяет одно и
только одно подключение к Интернету. Два устройства в Интернете никогда не могут
иметь одного того же адреса. Если устройство имеет два подключения к Интернету, через
две сети, оно имеет два адреса IP.
Адреса IP универсальны потому, что система адресации должна быть принята любым
хостом, который хочет быть связанным с Интернетом.
Адресное пространство
Протокол, подобный IP, то есть определяющий адреса, имеет адресное пространство.
Адресное пространство — общее количество адресов, применяемых в соответствии с
протоколом. Если протокол использует N бит, чтобы определить адрес, адресное
пространство – 2N, потому что каждый бит может иметь два различных значения (0 и 1), а
N бит могут иметь 2N значений.
IPv4 использует адреса на 32 бита, то есть адресное пространство – 232 или 4,294,967,296
(больше чем четыре миллиарда). Это означало бы, что, теоретически, если не было бы
никаких ограничений, к Интернету могли бы быть подключены более чем 4 миллиарда
устройств. Мы вскоре увидим, что фактически номеров намного меньше.
Система обозначений
Применяется, чтобы указать адрес IP. Есть три общих системы обозначений: двоичная,
десятичная разделенная точками и шестнадцатеричная система обозначений.
321
Двоичная система обозначений
В двоичной системе обозначений адрес IP отображен как 32 бита. Чтобы сделать адрес
читаемым, обычно вставляются один или более пробелов между каждым октетом (8 бит).
Каждый октет часто упоминается как байт. Поэтому адрес IP называется адресом с 4
октетами, или 4-байтовым адресом. Ниже показан пример адреса IP в двоичной системе
обозначений:
10010001 11011101 01010101 10010100
Десятичная разделенная точками система обозначений
Чтобы сделать адрес IP более компактным и более простым для чтения, адреса Интернета
обычно написаны в десятичной форме с точкой (точечное отделение байтов). Рисунок 2.1
показывает адрес IP в десятичной системе обозначений, разделенной точками. Обратите
внимание на то, что поскольку каждый байт (октет) — только 8 битов, каждый номер в
десятичной разделенной точками системе обозначений находится между 0 и 255. В
некоторых компьютерных системах возможно применение октальной и
шестнадцатеричной систем обозначения.
Рис. 2.1. Десятичная разделенная точками система обозначений (нотация)
Пример 1
Замените следующие IP-адреса в двоичном обозначении на десятичную систему,
обозначенную с разделением точками:

10000001 00001011 00001011 11101111;

11000001 10000011 00011011 11111111;

11100111 11011011 10001011 01101111;

11111001 10011011 11111011 00001111.
Решение
Мы заменяем каждую группу 8 битов ее эквивалентным десятичным номером и
добавляем точки для разделения:

129.11.11.239;

193.131.27.255;

231.219.139.111;
322

249.155.251.15.
Пример 2
Замените следующие IP-адреса десятичного обозначения с применением точек на
двоичное обозначение:

111.56.45.78;

221.34.7.82;

241.8.56.12;

75.45.34.78.
Решение
Мы заменяем каждый десятичный номер его двоичным эквивалентом:

01101111 00111000 00101101 01001110;

11011101 00100010 00000111 01010010;

11110001 00001000 00111000 00001100;

01001011 00101101 00100010 01001110.
Пример 3
Найдите ошибку, если таковые вообще имеются, в следующих IP-адресах:

111.56.045.78;

221.34.7.8.20;

75.45.301.14;

11100010.23.14.67.
Решение

В десятичном обозначении с использованием разделительных точек в начале десятичного числа не
применяется нуль (045).

Мы не можем иметь больше чем четыре байта в IP-адресе.

В пунктирно-десятичном изображении каждый номер меньше или равен 255; 301 — вне этого
диапазона.

Смесь двоичного обозначения и десятичной системы обозначений, разделенной точками, не
позволяется.
Шестнадцатеричная система обозначений
Мы иногда видим адрес IP в шестнадцатеричной системе обозначений. Каждая
шестнадцатеричная цифра эквивалентна четырем битам. Это означает, что адрес на 32
323
бита имеет 8 шестнадцатеричных цифр. Такая система обозначений часто используется в
сетевом программировании.
Пример 4
Замените следующие адреса IP в двоичной системе обозначений на шестнадцатеричную
систему обозначений:

10000001 00001011 00001011 11101111;

11000001 10000011 00011011 11111111.
Решение
Мы заменяем каждую группу в 4 бита ее шестнадцатеричным эквивалентом. Обратите
внимание, что шестнадцатеричная система обозначений обычно не имеет ни одного
добавленного пробела; однако 0X добавляется в начале или в конце приписывается индекс
16, чтобы показать, что номер приведен в шестнадцатеричном обозначении.

OX810BOBEF или 810BOBEF16;

OXC1831BFF или C1831BFF16.
Адресация по классам
В начале внедрения IP-адресации использовали концепцию классов. Эта архитектура
названа адресацией по классам.
В середине 1990-х была введена новая архитектура, названная бесклассовой адресацией,
которая была предназначена, в конечном счете, заменить первоначальную архитектуру.
Однако в большинстве случаев Интернет все еще использует адресацию по классам, и
переход идет медленно. Далее рассматривается сначала адресация по классам, а потом
бесклассовая адресация. "Классовая" концепция необходима, чтобы понять
"бесклассовую" концепцию.
Имеется пять классов адресов, приведенных в табл. 2.1, где жирным шрифтом выделена
старшая часть IP-адреса, указывающая номер сети.
Согласно [31, 32], в версии 4 сетевые IP-адреса имеют двухуровневую иерархию, старшая
часть которых отображает номер сети (netid), а младшая – номер узла (компьютера) в сети
(hostid). Общая длина адреса имеет длину 4 байта и записывается в виде десятичных
чисел, разделенных точками. Первые биты сетевого адреса задают класс адреса, по
которому определяется, какая его часть относится к номеру сети, а какая – к номеру узла.
Если сеть является частью Интернета, то номер сети назначается централизованно по
рекомендации специального органа Интернета – Internet Information Center. Номер узла в
IP-адресе назначается из разрешенного для этого класса диапазона независимо от
физического адреса. Маршрутизатор объединяет несколько сетей, поэтому каждый порт
(интерфейс) маршрутизатора имеет свой IP-адрес.
Таблица 2.1. Классы адресов
Класс
Первые биты
IP-адреса
Наименьший
номер сети
Наибольший
номер сети
324
Максимальное
число сетей
Макс. число узлов в
каждой сети
A
0
0.0.0.0
127.0.0.0
27 – 2
224 – 2
B
10
128.0.0.0
191.255.0.0
214 – 2
216 – 2
C
110
192.0.0.0
223.255.255.0
221 – 2
28 – 2
D
1110
224.0.0.0
239.255.255.255
15 x 224
Групповые адреса
E
11110
240.0.0.0
255.255.255.255
7x2
24
Резерв
Большие сети используют адреса класса А, средние – класса В, маленькие – класса С.
Мы можем видеть из табл. 2.1, что класс A покрывает половину адресного пространства
— это серьезный недостаток проекта. Класс B охватывает 1/4 всего адресного
пространства — и это второй недостаток проекта. Класс C охватывает 1/8 адресного
пространства, и классы D и E покрывают 1/16 адресного пространства каждый.
Если адрес дается в двоичной системе обозначений, первые биты остатка могут указать
нам класс адреса, как показано на Рис. 2.2.
Рис. 2.2. Нахождение класса в двоичной системе обозначений
Пример 5
Как доказать, что мы имеем 2147483648 адресов в классе A?
Решение
В классе A только 1 бит определяет класс. Остающийся 31 бит доступен для адреса.С 31
битом мы можем иметь 231, или 2147483648 адресов.
Пример 6
Найдите класс каждого адреса:

00000001 00001011 00001011 11101111;

11000001 10000011 00011011 11111111;

10100111 11011011 10001011 01101111;

11110011 10011011 11111011 00001111.
Решение
325
См. процедуру на рис. 2.2.

Первый бит — 0. Это — адреса класса A.

Первые 2 бита — 1; третий бит — 0. Это — адрес класса C.

Первый бит — 1; второй бит — 0. Это — адрес класса B

Первые 4 бита — 1111. Это — адрес класса E.
Когда адрес дается в десятичной разделенной точками системе обозначений, чтобы
определить класс адреса, мы должны смотреть только на первый байт (номер). Каждый
класс имеет заданный диапазон номеров.
Это означает, что если первый байт (в десятичном числе) — между 0 и 127, то класс — A.
Если первый байт — между 128 и 191, класс — B. И так далее.
Пример 7
Найдите класс каждого адреса:

227.12.14.87;

193.14.56.22;

14.23.120.8;

252.5.15.111;

134.11.78.56.
Решение

Первый байт — 227 (между 224 и 239); класс — D.

Первый байт — 193 (между 192 и 223); класс — C.

Первый байт — 14 (между 0 и 127); класс — A.

Первый байт — 252 (между 240 и 255); класс — E.

Первый байт — 134 (между 128 и 191); класс — B.
Пример 8
В Примере 5 мы показали, что класс A имеет 231 (2 147 483 648) адресов. Как мы можем
доказать тот же самый факт, используя десятичную разделенную точками систему
обозначений?
Решение
Адреса в классе A расположены в диапазоне от 0.0.0.0 до 127.255.255.255. Мы должны
показать, что разность между этими двумя номерами — 2 147 483 648. Это упражнение
показывает, как определить диапазон адресов между двумя адресами. Мы замечаем, что
мы имеем дело с основой 256 номеров здесь. Каждый байт в системе обозначений имеет
вес. Веса располагаются следующим образом:
326
2563, 2562, 2561, 2560.
Теперь, чтобы найти значение целого числа каждого номера, мы умножаем каждый байт
на его вес.
Последний адрес: 127 x 2563 + 255 x 2562 + 255 x 2561 + 255 x 2560 = 2 147 483 647
Первый адрес = 0
Если мы вычтем первый из последнего и добавим 1 к результату (помните, что мы всегда
добавляем 1, чтобы получить диапазон), мы получаем 2 147 483 648 или 231.
В IPv4 существуют определенные соглашения об использовании адресов:
1.
В каждом классе имеется диапазон адресов для локального использования, которые сетевые
маршрутизаторы не обрабатывают ни при каких условиях, — они применяются для маршрутизации
в локальных сетях. В классе А – это сеть 10.0.0.0, в классе В – диапазоны сетей от 172.16.0.0 до
172.31.0.0, в классе С – диапазон сетей от 192.168.0.0. до 192.168.255.255.
2.
Если в поле номера сети установлены все двоичные "0", то пакет адресован соответствующему узлу
той же сети.
3.
Если в полях номера сети и номера узла установлены все двоичные "1", то пакет адресован всем
узлам той же сети (широковещательная рассылка, limited broadcast).
4.
Если в поле номера узла установлены все двоичные "1", то пакет адресован всем узлам
соответствующей сети.
5.
Основное назначение групповых (Multicast) адресов – распространение информации по схеме
"один-ко-многим" для групповой рассылки в Интернете аудио- и видеоинформации. Хост, который
хочет осуществить рассылку, с помощью протокола группового обслуживания Интернета (Internet
Group Management Protocol – IGMP) сообщает о создании в сети мультивещательной группы с
определенным адресом. Устройства, которые хотят присоединиться к создаваемой группе,
высылают свое подтверждение. Одно и то же устройство может входить в несколько групп, в одну и
ту же группу могут входить устройства различных сетей.
6.
Адреса класса Е зарезервированы для будущих применений.
Сетевой (Netid) и локальный (Hostid) адреса
При адресации по классам адрес IP в классах A, B и C разделен на сетевой (Netid) и
локальный (Hostid) адреса. Длина адреса зависит от класса объекта. Обращаем внимание
на то, что классы D и E не разделены на эти части.
В классе A 1 байт определяет сетевой адрес и 3 байта определяют локальный адрес. В
классе B 2 байта определяют сетевой адрес и 2 байта — локальный. В классе C 3 байта
определяют сетевой адрес и 1 байт — локальный.
Классы и блоки
При адресации по классам каждый класс разделен на фиксированное число блоков, и
каждый блок имеет фиксированный размер. Давайте рассмотрим каждый класс.
327
Класс A
Класс A разделяется на 128 блоков, где каждый блок имеет различный netid. Первый блок
охватывает адреса от 0.0.0.0 до 0.255.255.255 (netid 0), второй блок — адреса от 1.0.0.0 до
1.255.255.255 (netid 1), последний блок — адреса от 127.0.0.0 до 127.255.255.255 (netid
127). Обратите внимание, что для каждого блока адресов первый байт (netid) является тем
же самым, но другие 3 байта (hostid) могут принимать любое значение в данном
диапазоне.
Первый и последние блоки в этом классе сохранены для специальных целей и будут
обсуждаться далее. Кроме того, один блок (netid 10) используется для частных адресов.
Оставшиеся 125 блоков могут быть назначены для организаций. Это означает, что общее
количество организаций, которые могут иметь адреса класса — только 125. Однако
каждый блок в этом классе содержит 16 777 216 адресов, то есть организация должна быть
действительно большой, чтобы использовать все эти адреса.
Адреса класса A были предназначены для больших организаций с большим количеством
хостов или маршрутизаторов, закрепленных за их сетью. Однако число адресов в каждом
блоке, 16 777 216, является, вероятно, большим, чем потребности почти всех организаций.
В этом классе много адресов потрачены впустую.
Класс B
Класс B разделен на 16 384 блока, и каждый блок имеет различный сетевой номер.
Шестнадцать блоков зарезервированы для частных адресов, оставшиеся 16 368 блоков —
для назначения организацией. Первый блок охватывает адрес от 128.0.0.0 до 128.0.255.255
(netid 128.0), последний блок — адреса от 191.255.0.0 до 191.255.255.255 (netid 191.255).
Обратите внимание, что для каждого блока адресов первые 2 байта (netid) являются теми
же самыми, но другие 2 байта (hostid) могут принимать любое значение в данном
диапазоне.
Всего могут быть назначены адреса для 16 368 блоков. Это означает, что общее
количество организаций, которые могут иметь адрес класса B, — 16 368. Так как каждый
блок в этом классе содержит 65 536 адресов, организация должна быть достаточно
большой, чтобы использовать все эти адреса. Таблица 2.1 показывает блоки в классе B.
Первый адрес (128.0) — сетевой адрес; последний адрес — 191.255, зарезервирован для
специальной цели.
Адреса класса B были предназначены для организаций среднего размера, которые могут
иметь десятки тысяч хостов или маршрутизаторов, закрепленных за их сетями. Однако
число адресов в каждом блоке, 65 536, является большим, чем потребности большинства
организаций среднего размера. Много адресов в этом классе также потрачены впустую.
Класс C
Класс C разделен на 2 097 152 блока, каждый блок имеет различный сетевой номер.
Двести пятьдесят шесть блоков используются для частных адресов, остальные 2 096 896
блоков — для назначения организацией. Первый блок охватывает адреса от 192.0.0.0 до
328
192.0.0.255 (netid 192.0.0), последний — адреса от 223.255.255.0 до 223.255.255.255 (netid
223.255.255). Следует обратить внимание, что для каждого блока адресов первые 3 байта
(netid) являются одними и теми же, а остающийся байт (hostid) может принимать любое
значение в данном диапазоне.
Имеются 2 096 блоков, которые могут иметь адреса класса C — 2 096 902. Однако каждый
блок в этом классе содержит 256 адресов. Это означает, что организация должна быть
достаточно маленькой и нуждаться в менее чем 256 адресах. Первый адрес (192.0.0) —
сетевой; последний адрес зарезервирован для специальной цели.
Адреса класса C были предназначены для маленьких организаций с небольшим
количеством хостов или маршрутизаторов, закрепленных за их сетью. Число адресов в
каждом блоке ограничено так, что большинство организаций не хотят иметь блоки в этом
классе.
Класс D
Класса D имеет один блок адресов. Этот класс разработан для рассылки информации по
многим адресам. Каждый адрес в этом классе используется, чтобы определить одну
группу хостов в Интернете. Когда группа назначена в этом классе адресов, тогда каждый
хост — член этой группы будет иметь адрес групповой рассылки в дополнение к его
нормальному (индивидуальному) адресу.
Класс E
Класса E имеет один блок адресов. Он был разработан для использования в качестве
класса резервных адресов. Последний адрес в этом классе, 255.255.255.255, используется
для специального адреса.
Пример 9
Дан сетевой адрес 17.0.0.0, найдите класс, блок и диапазон адресов.
Решение
Класс — A, потому что первый байт — между 0 и 127. Блок имеет сетевой номер 17.
Адреса располагаются от 17.0.0.0 до 17.255.255.255.
Пример 10
Дан сетевой адрес 132.21.0.0, найдите класс, блок и диапазон адресов.
Решение
Класс — B, потому что первый байт — между 128 и 191. Блок имеет сетевой номер
132.21. Адреса располагаются от 132.21.0.0 до 132.21.255.255.
Пример 11
Дан сетевой адрес 220.34.76.0, найдите класс, блок и диапазон адресов.
329
Решение
Класс — C, потому что первый байт — между 192 и 223. Блок имеет сетевой номер
220.34.76. Адреса располагаются от 220.34.76.0 до 220.34.76.255.
Маска
Уже давно наблюдается дефицит IP-адресов, который обусловлен не только ростом числа
пользователей, но и необходимостью выделения IP-адресов на каждый порт
маршрутизатора. Имеется несколько подходов смягчения этой проблемы, в том числе за
счет использования масок.
Традиционно номер сети и узла определяется в зависимости от класса адреса. Однако
наличие только четырех классов адресов часто бывает неудобно. Например,
администратор получил от поставщика услуг номер сети 135.38.0.0 (адрес класса В,
двоичный код сети – 10000111 00100110 00000000 00000000). В такой сети потенциально
можно иметь 65 534 узла, но такое количество узлов администратору не нужно, ему
достаточно иметь 32 000. Проблема решается с помощью масок. Количество "единиц" в
маске показывает число старших разрядов, которые определяют номер сети. Для нашего
случая следует выбрать маску со значением 255.255.192.0 (двоичный код 11111111
11111111 11000000 00000000). В результате наложения маски на сетевой адрес получается
четыре подсети: 135.38.0.0; 135.38.64.0; 135.38.128.0; 135.38.192.0. (табл. 2.2).
Таблица 2.2. Результат наложения маски
Номер сети
Число узлов в подсети
10000111 00100110 00000000 00000000 16382
135.38.00.0
10000111 00100110 01000000 00000000 16382
135.38.64.0
10000111 00100110 10000000 00000000 16382
135.38.128.0
10000111 00100110 11000000 00000000 16382
135.38.192.0
Две полученные подсети с общим количеством узлов 32764 = 2 х 16382 администратор
использует для своих нужд, а остальные может отдать другому администратору.
Для адресации по классам есть три маски. Для класса A маска – из восьми "единиц" и
двадцати четырех "нулей" (255.0.0.0). Для класса B маска – шестнадцать "единиц" и
шестнадцать "нулей" (255.255.0.0). На класс C маска — двадцать четыре "единицы" и
восемь "нулей" (255.255.255.0). "Единицы" сохраняют сетевой адрес (netid); "нули"
устанавливают локальный адрес (hostid) на "0".
Пример 12
Дан адрес 23.56.7.91 и заданный по умолчанию класс маски А; найдите начальный адрес
(сетевой адрес).
Решение
330
Заданная по умолчанию маска — 255.0.0.0, что означает, что только первый байт
сохраняется, а другие 3 байта устанавливаются на "нуль". Сетевой адрес — 23.0.0.0.
Пример 13
Дан адрес 132.6.17.85 и задана по умолчанию маска класса B; найдите начальный адрес
(сетевой адрес).
Решение
Заданная по умолчанию маска — 255.255.0.0, что означает, что первые 2 байта
сохраняются и другие 2 байта устанавливаются на "нуль". Сетевой адрес — 132.6.0.0.
Пример 14
Дан адрес 201.180.56.5 и маска класса C, заданная по умолчанию; найдите начальный
адрес (сетевой адрес).
Решение
Заданная по умолчанию маска — 255.255.255.0, что означает, что первые 3 байта
сохраняются, а последний байт установлен на 0. Сетевой адрес — 201.180.56.0.
Следует обратить внимание, что мы не должны применять по умолчанию маски одного
класса к адресам, принадлежащим другому классу.
Многоадресные устройства
Адрес Интернета определяет подключение узлов к своей сети. Из этого следует, что
любое устройство, подключенное больше чем к одной сети, должно иметь больше чем
один адрес Интернета. Фактически устройство имеет различные адреса для каждой сети, к
которой оно подключено. Компьютер, который подключен к различным сетям, называется
многоадресным компьютером и будет иметь несколько адресов. Каждый из таких адресов
может принадлежать к различному классу. Маршрутизатор должен быть связан больше
чем с одной сетью, иначе он не сможет маршрутизировать. Поэтому маршрутизатор по
определению имеет больше чем один адрес IP (один для каждого интерфейса).
Прямой широковещательный адрес
В классах A, B и C, если сетевой номер (netid) состоит только из единиц, адрес называется
прямым широковещательным адресом. Такой адрес используется маршрутизатором для
того, чтобы передать пакеты для всех хостов в заданной сети. Все хосты примут пакет,
имеющий этот тип адреса пункта назначения. Заметим, что введение такого адреса
уменьшает число номеров локальных адресов в каждом из классов A, B, C.
Возможен случай ограничения широковещательного адреса, когда маршрутизатор
местной сети может блокировать пакеты, имеющие этот тип адреса, ограничивая
широковещательную передачу к местной сети.
331
Этот хост на этой сети
Если адрес IP составлен из всех нулей, это означает, что это хост расположенный на этой
сети. Он используется хостом во время начальной загрузки, когда передающий хост не
знает свой адрес IP. Хост передает пакет IP серверу начальной загрузки, используя этот
адрес как исходный адрес пункта назначения, который может определить собственный
адрес передающего хоста. Его можно использовать только как исходящий адрес. Этот
адрес – всегда адрес класса A независимо от сети, что уменьшает число сетей в классе A
на одну сеть.
Заданный хост на этой сети
Адрес IP с сетевым номером (netid) из всех нулей означает адрес заданного хоста на этой
сети. Он используется хостом, чтобы передать сообщение другому хосту на той же самой
сети. Заметим, что он может использоваться только как входящий адрес пункта
назначения. Это адрес класса A независимо от размера сети.
Адрес кольцевой проверки (Loopback address)
Адрес IP с первым байтом, равным 127, применяется для адреса кольцевой проверки,
который является адресом, используемым для проверки программного обеспечения
компьютера. Когда этот адрес задействуется, пакет никогда не покидает хост; он просто
возвращается хосту и обрабатывается согласно протоколу и установленному на
управляющем компьютере программному обеспечению. Он может использоваться, чтобы
проверить программное обеспечение IP. Например, приложение может передать пакет с
адресом шлейфа как адрес пункта назначения, чтобы проверить, способно ли программное
обеспечение IP получить и обработать пакет. Другой пример: адрес шлейфа может
применяться процессом клиента (функционирующая прикладная программа), чтобы
передать сообщение процессу сервера на том же самом компьютере. Этот адрес может
использоваться только как адрес пункта назначения в пакете IP. Это — адрес класса A.
Его применение уменьшает число сетей в классе на 1.
В таблице 2.3 приведены рассмотренные выше специальные адреса.
Таблица 2.3. Специальные адреса
Специальный адрес
Netid
Hostid
Источник или конечный пункт
Сетевой адрес
Заданный
Все нули
Нет
Прямой широковещательный адрес
Заданный
Все единицы Конечный пункт
Ограниченный широковещательный адрес Все единицы Все единицы Конечный пункт
"Этот хост на этой сети"
Все нули
Все нули
Источник
"Заданный хост на этой сети"
Все нули
Заданный
Конечный пункт
Адрес шлейфа
127
Любой
Конечный пункт
Частные адреса
Некоторое количество блоков в каждом классе предназначено для частного
использования. Эти блоки изображены в таблице 2.4 Эти адреса используются при
подключении к сетям с другими способами адресации.
332
Таблица 2.4. Специальные адреса
Класс
Сетевой адрес
A
10.0.0
Величина блока
1
B
172.16 до 172.31
C
192.168.0 до 192.168.255 256
16
Индивидуальные адреса, групповая рассылка и широковещательные
адреса
Связь в Интернете осуществляется с использованием индивидуальных адресов, или
адресов групповой рассылки, или широковещательных адресов. Если в полях номера сети
и номера узла установлены все двоичные "1", то пакет адресован всем узлам той же сети
(широковещательная рассылка, адрес ограниченной групповой рассылки).
Индивидуальные адреса
Когда пакет передают от индивидуального источника до индивидуального пункта
назначения — это индивидуальная связь. Все системы в Интернете имеют по крайней
мере один уникальный индивидуальный адрес. Индивидуальные адреса принадлежат к
классам A, B или C.
Адреса групповой рассылки
Связь групповой рассылки происходит по принципу "один ко многим". Когда пакет
передают от индивидуального источника до группы пунктов назначения — это связь
групповой рассылки. Адрес групповой рассылки — адрес класса D. Полный адрес
определяет групповой адрес (groupid). Система в Интернете может иметь один или более
адресов класса D групповой рассылки (в дополнение к индивидуальному адресу или
адресам). Если система (обычно хост) имеет семь адресов групповой рассылки, это
означает, что он принадлежит семи различным группам. Адрес класса D может
использоваться только как входящий адрес пункта назначения, а не как исходный адрес.
Групповая передача в Интернете может осуществляться на местном или на глобальном
уровне. На местном уровне хостом локальной сети LAN может быть сформирована
группа, и могут быть назначены адреса групповой рассылки. На глобальном уровне хосты
на различных сетях могут формировать группу, и может быть назначен адрес групповой
рассылки.
Назначенные адреса групповой рассылки. В сети Интернет определены некоторые адреса
групповой рассылки к заданным группам.
Категория. Некоторые адреса групповой рассылки предназначены для некоторого
специального использования. Эти адреса групповой рассылки начинаются с префикса
224.0.0. таблицa 2.5 показывает некоторые из этих адресов.
Таблица 2.5. Специальные адреса
Адрес
224.0.0.0 Зарезервировано
Группа
333
224.0.0.1 Все СИСТЕМЫ на данной ПОДСЕТИ
224.0.0.2 Все МАРШРУТИЗАТОРЫ на данной ПОДСЕТИ
224.0.0.3 Не определено
224.0.0.4 Все маршрутизаторы, работающие по протоколу многоадресной маршрутизации по вектору
расстояния (DVMRP)
224.0.0.5 Все маршрутизаторы, работающие по протоколу первоначального выбора наикратчайшего пути
(OSPF)
224.0.0.6 Заданные маршрутизаторы, работающие по протоколу первоначального выбора наикратчайшего
пути (OSPF)
224.0.0.7 Заданные маршрутизаторы
224.0.0.8 Заданные хосты
224.0.0.9 Маршрутизаторы, работающие по протоколу обмена маршрутной информацией (RIP2)
224.0.0.10 Маршрутизаторы, работающие по протоколу внутренней маршрутизации (IGRP)
224.0.0.11 Доступ к сети мобильной связи (Mobile agents)
Конференц-связь. Некоторые адреса групповой рассылки предназначены для конференцсвязи и организации телеконференций. Эти адреса групповых рассылок начинаются с
префиксов 224.0.1. табл. 2.6 показывает некоторые из этих адресов.
Таблица 2.6. Примеры адресов для конференц-связи
Адрес
224.0.1.7
Группа
Аудионовости
224.0.1.10 Низкоскоростная речь согласно IETF
224.0.1.11 Речь согласно IETF
224.0.1.12 Видео согласно IETF
224.0.1.16 Музыкальные передачи
Широковещательные адреса
Широковещательная связь происходит по принципу "один ко всем". Интернет позволяет
широковещательную передачу только на местном уровне. Мы уже обсудили два
широковещательных адреса, используемые на местном уровне: ограниченный
широковещательный адрес (все единицы) и прямой широковещательный адрес (сетевой
адрес и все единицы в локальном адресе).
Ни одна широковещательная передача не разрешается на глобальном уровне. Это
означает, что система (хост или маршрутизатор) не может передавать сообщение для всех
хостов и маршрутизаторов в Интернете. Можно представить, какой может быть трафик в
результате снятия этого ограничения.
Для сокращения числа записей в маршрутизаторе широко используют бесклассовую
систему междоменной маршрутизации (Classless Inter Domain Routing, CIDR), в которой
маршрутизация осуществляется на основе префиксов. Префиксом обозначают общую
часть старших разрядов адреса, они позволяют сократить число записей в
маршрутизаторе. Так, если две первые указанные подсети подсоединены к одному
маршрутизатору, то смежным маршрутизаторам не обязательно иметь 2 записи о каждой
подсети, а достаточно иметь одну запись префикса 135.38.0.0/17 с маской 255.255.128.0
(11111111 11111111 10000000 00000000), содержащей 17 лидирующих "единиц".
334
Для идентификации объекта протоколы используют IP-адреса, которые уникально
идентифицирует соединения хоста с Интернетом. Однако люди предпочитают имена
адресам. Поэтому нам необходима система, которая сопоставляет имя с адресом или адрес
к имени.
Когда Интернет имел небольшой объем, сопоставление делал хост-файл. Хост-файл имел
только две колонки, включающие в себя имя и адрес. Когда программа или пользователь
хотели сопоставить имя и адрес, хост обращался к хост-файлу и находил отображение.
Однако сегодня невозможно иметь одиночный файл хоста, чтобы устанавливать связь
каждого файла с именем или обратно. Этот хост-файл был бы слишком велик для
накопления каждого хоста. В дополнение к этому, было бы невозможно обновить все
файлы хостов в мире каждый раз, когда идут изменения.
Одно из решений могло бы состоять в том, чтобы хранить полный файл хоста в
единственном компьютере и позволять доступ к этой централизованной информации для
каждого компьютера, который нуждается в отображении. Но это бы создало огромный
трафик на сети Интернет.
Другое решение, используемое сегодня, — это децентрализация. Огромное количество
информации разделено на маленькие части, и каждая часть накапливается в различных
компьютерах. При этом методе хост, который нуждается в отображении, может
контактировать с ближайшим компьютером, содержащим необходимую информацию.
Этот метод используется в доменной системе имен (DNS — Domain Name System). Далее
рассматриваются концепции и идеи этой системы. Затем дается описание самого
протокола DNS.
Пространство имен
Чтобы быть однозначным, имя, назначаемое машиной, должно быть отделено от других
имен. При этом должен быть обеспечен контроль возможного совпадения имен и связь
между именем и адресом IP. Другими словами, имя должно быть уникально, потому что
адреса уникальны. Пространство имен, которое сопоставляет каждый адрес и уникальное
имя, может быть организовано двумя путями: плоско и иерархически.
Плоское пространство имен
В пространстве плоских имен имя назначается каждому адресу. Имя в этом
пространстве есть последовательность символов без структуры, закрепленной какимилибо правилами. Имена могут или не могут иметь общую часть; это не имеет никакого
значения. Главный недостаток плоского пространства имен – это то, что оно не может
быть использовано в больших системах, таких как Интернет, потому что оно хаотично и
не может управляться дистанционно, а это затрудняет проверку неоднозначности и
дублирования.
Иерархическое пространство имен
В иерархическом пространстве имен каждое имя составлено из нескольких частей.
Первая часть может определять природу организации, вторая часть — имя организации,
335
третья часть — департаменты в организации, и так далее. В этом случае полномочия и
управление пространством имен может быть децентрализовано. Центральные полномочия
могут назначаться согласно той части имени, которое определяет природу организации и
имя организации. Полномочия, определяемые остальной частью имени, определяются
самой организацией. Организация может добавить к имени суффикс или префикс,
определяющие ресурсы ее хоста. Управлению организации не нужно беспокоиться, что
префикс, выбранный для хоста, взят другой организацией, потому что даже если часть
адреса одна и та же, полный адрес различается. Например, предположим, два
университета и компания назвали один из их компьютеров kafedra. Первый университет
дает имени центральные полномочия, такие как gut.edu, второй дает имя mtusy.edu, и
компания дает имя loniis.ru. Когда каждая из этих организаций добавляет имя кафедра к
имени, они уже дают в конечном результате три отличающихся имени: kafedra.gut.edu,
kafedra.mtusy.edu и kafedra.loniis.ru.
Имена уникальны, и управление полномочиями проводится не по полному имени, а
только по его части.
Пространство доменных имен
Иерархическое пространство доменных имен назначается. При этом назначении имя
определяется структурой инвертированного дерева с корнем в вершине. Дерево может
иметь 128 уровней: от уровня 0 (корень) до уровня 127. Принимая во внимание, что
корень скрепляет целое дерево вместе, каждый уровень дерева определяет иерархический
уровень.
Метка
Каждый узел дерева имеет метку. Она отображается строчкой из символов с
максимальным числом 63. Метка корня – нулевая строчка (пустая строчка). DNS требует,
чтобы "дети" узла (узлы, которые являются ветками от того же узла) имели различные
метки, которые гарантируют уникальность доменного имени.
Доменное имя
Каждый узел дерева имеет доменное имя. Полное доменное имя — последовательность
меток, отделенных точками (.). Доменные имена всегда читают от узла к корню.
Последняя метка — это метка-корень (нуль). Это означает, что полное доменное имя
всегда оканчивается нулевой отметкой, которую означает последний символ – точка,
потому нулевая строка ничего не обозначает.
Полностью определенное доменное имя
Если метка завершается нулевой строкой, это называется "полностью определенное
доменное имя" (FQDN — Fully Qualified Domain Name). FQDN – имя хоста, которое
содержит полное имя хоста. Оно включает в себя все метки, от наиболее специфичной до
наиболее общей, которые уникально определяют имя хоста. Например, доменное имя
kafedra.gut.edu.
336
Это FQDN компьютера, названного kafedra и установленного в Государственном
университете телекоммуникаций. Заметим, что имя должно заканчиваться нулевым
ярлыком, но поскольку он ничего не обозначает, метка заканчивается точкой (.).
Частично определенное имя домена
Если метка не заканчивается нулевой строкой, это называется "частично определенным
доменными именем" (PQDN — Partially Qualified Domain Name). PQDN начинается от
узла, но не достигает корня. Оно используется, если в компьютере будет отмечено, что
имя принадлежит тому же самому сайту, что и клиент. Здесь компьютер может заменить
отсутствующую часть так называемым суффиксом, который создает FQDN. Например,
если пользователь сайта sut.edu. хочет иметь IP-адрес компьютера "kafedra", он может
определить частичное имя
kafedra
DNS клиента добавляет суффикс sut.edu перед тем, как передать адрес к DNS-серверу.
DNS клиента обычно имеет список суффиксов. Символы могут определяться списком
сервера университета. Нулевой суффикс ничего не определяет. Этот суффикс добавляется,
когда имя пользователя полностью определено в виде FQDN.
Домен
Домен — это фрагмент дерева в пространстве доменных имен. Имя домена – это
доменное имя узла на вершине поддерева.
Распределение имен
Информация, содержащаяся в пространстве доменных имен, может быть накоплена.
Однако иметь только один компьютер, накапливающий такое громадное количество
информации, — это крайне неэффективно и ненадежно. Это неэффективно, потому что
реагирование на запросы со всего мира — тяжелая нагрузка на систему. Это ненадежно,
потому что любая ошибка делает данные недоступными.
Иерархия серверов имен
Решение этих проблем – распределить информацию по компьютерам, называемым DNSсерверы. Один из путей сделать это – разделить полное пространство на много доменов,
базирующихся на первом уровне. Другими словами, считать корень автономным и
создавать и предоставить полномочия, создавать столько доменов (поддеревьев), сколько
имеется узлов. Поскольку домен, создаваемый таким способом, очень большой, DNS
позволяет разделить домен на более мелкие домены (поддомены). Каждый сервер может
обслуживать (уполномочен) любой большой или маленький домен. Другими словами, мы
имеем иерархию серверов в соответствии с иерархией имен.
337
Зона
То, за что сервер несет ответственность или где он имеет полномочия, называется зона.
Если сервер назначен отвечать за домен и домен не разделен на поддомены, "домен" и
"зона" относятся к одним и тем же понятиям. Сервер создает базу данных, называемую
файлом зоны, и сохраняет всю информацию для всех узлов под этим доменом. Однако
если сервер разделяет свои домены на поддомены и делегирует часть своих полномочий
другому серверу, "домен" и "зона" относятся к различным понятиям.
Информация об узлах в поддоменах накапливается в серверах нижнего уровня,
первоначальный сервер проводит некоторую сортировку ссылок на эти серверы низкого
уровня. Конечно, первоначальный сервер имеет зону, но детальная информация
сохраняется серверами нижнего уровня.
Сервер нижнего уровня может разделить часть домена и делегирует ответственность, но
может часть адресов сохранить за собой. В этом случае своя зона образуется из детальной
информации о части домена (группа адресов домена), которая оставлена за ним, и ссылок
на адреса, которые делегированы следующему уровню.
Корневой сервер
Корневой сервер – это сервер, зона которого состоит из полного дерева. Корневой сервер
обычно не накапливает информацию о домене, но делегирует свои полномочия другому
серверу, сохраняя ссылки на полное пространство имен. Серверы распределены по всему
миру.
Первичные и вторичные серверы
DNS определяет два типа серверов: первичные и вторичные. Первичный сервер — это
сервер, накапливающий файл о зоне, на которую он имеет полномочия. Он несет
ответственность за создание, эксплуатацию и изменения зонового файла. Зоновый файл
накапливается на локальном диске.
Вторичный сервер – это сервер, который передает полную информацию о
зоне для других серверов (первичных или вторичных) и накапливает
файл на своем локальном диске. Вторичный сервер не создает и не
изменяет зоновый файл. Если изменение требуется, он должен сделать
это с помощью первичного сервера, который посылает из DNS в
Интернете
DNS – это протокол, который может быть использован в различных платформах. В
Интернете пространство доменных имен (дерево) разделяется на три различных секции:
родовой домен, домен страны и инверсный домен.
338
Родовой домен
Родовой домен определяет регистрацию хоста (generic domain) в соответствии с его
родовой природой. Эти уровни связаны с типами организаций, как это, например,
приведено для США в табл. 3.1 [5].
Каждый узел дерева — домен, который является частью базы пространства доменных
имен.
В таблице первый уровень в секции родового домена позволяет семь возможных
трехсимвольных уровней. Эти уровни соотнесены с типами организаций так, как
перечислено в табл. 3.1 [5].
Таблица 3.1. Метки родового домена
Метка
Описание
com
Коммерческие организации
edu
Образовательные учреждения
gov
Правительственные учреждения
int
Международные организации
mil
Военные группы
net
Центры поддержки сетей
org
Некоммерческие организации
Домены страны
Секция домены страны придерживается того же формата, что и родовые домены, но
использует двухсимвольные сокращения страны (например, ru для России) вместо
трехсимвольной организационной структуры первого уровня. Аббревиатуры второго
уровня могут быть организационными или могут более детально определять
национальную принадлежность. Россия (ru), например, использует аббревиатуры
отдельных городов (например, spb.ru). Адрес gut.spb.ru может быть расшифрован как
Государственный университет телекоммуникаций, Санкт-Петербург, Россия.
Инверсный домен
Инверсный домен использует отражение адреса в имя. Это может понадобиться,
например, когда сервер получил запрос от клиента на выполнение определенной задачи.
Поскольку сервер имеет файл, который содержит список полномочных клиентов, сервер
перечисляет только IP-адреса клиентов (извлекая их из полученного пакета). Чтобы
определить, есть ли клиент в разрешенном списке, сервер может запросить DNS-сервер об
отображении адреса в имя.
Этот тип запроса называется инверсным запросом, или запросом указателя. Для того
чтобы обработать запрос указателя, инверсный домен добавляет к пространству доменных
имен узел первого уровня, называемый arpa (по историческим причинам). Второй уровень
также именует одиночный узел in-addr (для инверсного адреса). Остаток домена
определяет IP-адреса.
339
По договоренности следует читать метки инверсного домена от основания к вершине.
Например, такой IP-адрес, как 132.34.45.121, читается как 121.45.34.132.in-adr.arpa.
Сервер, который обрабатывает инверсный домен, — также иерархический. Это означает,
что часть адреса, содержащая сетевой номер (netid), должна быть более высокого уровня
(в данном примере это 132), чем часть адреса подсети (subnetid), в данном примере 45; а
часть адреса подсети должна быть более высокого уровня, чем адрес хоста (hostid). Такая
конфигурация делает вид домена инверсным, если сравнивать с родовым доменом и
доменом страны.
Распознавание имен
Отображение имени в адрес или адреса в имя называется "распознавание имя-адрес".
Распознаватель (resolver)
Протоколы DNS разработаны как приложение сервер-клиент. Хост, который нуждается в
отображении адреса в имя или имени в адрес, вызывает DNS клиента, который называется
распознавателем. Распознаватель получает доступ к ближайшему серверу DNS с запросом
на отображение. Если сервер имеет информацию, он выполняет запрос распознавателя; в
противном случае он либо отсылает распознаватель к другим серверам, либо сам
запрашивает другие сервера для того, чтобы обеспечить эту информацию.
После того как распознаватель получит это отображение, он анализирует отклик для того,
чтобы посмотреть, является ли это реальным распознаванием или ошибкой. В конечном
итоге результат доставляется процессу, который запросил его.
Отображение имен в адреса
Большинство времени распознаватель выдает имена серверу и запрашивает
соответствующие адреса. В этом случае сервер проверяет родовой домен или домен
страны для того, чтобы найти отображение.
Если имя домена от родовой секции, распознаватель получает доменное имя, такое как
kafedra.gut.edu. Запрос посылается распознавателем к местному DNS-серверу для
распознавания. Если местный сервер не распознает запроса, он либо отсылает
распознаватель к другому серверу, либо запрашивает другой сервер напрямую.
Если имя домена из секции доменов стран, распознаватель получает доменное имя, такое
как kafedra.gut.spb.ru. Процедура та же самая.
Отображение адресов в имена
Клиент может послать IP-адрес на сервер для того, чтобы отобразить доменное имя. Как
уже было упомянуто прежде, это называется PTR-запрос. Для подобного запроса DNS
использует инверсный домен. Однако IP-адрес запроса должен быть реверсирован, и
должны быть прикреплены две метки, in-addr или arpa, чтобы создать доступный домен с
помощью инверсной доменной секции. Например, если распознаватель получил IP-адрес
132.34.45.121, распознаватель вначале инвертирует адрес, а затем добавляет две метки
340
перед посылкой. Посылаемое имя домена — 121.45.34.132.in-addr-arpa. Оно получается с
помощью локальной DNS и распознается.
Рекурсивное распознавание
Клиент (распознаватель) может запросить рекурсивный ответ из сервера имени. Если
сервер может это сделать, он проверяет свою базу данных и отвечает. Если сервер не
уполномочен, он посылает запрос другому серверу (обычно к вышестоящему) и ожидает
отклика. Если вышестоящий сервер уполномочен, он отвечает; в противном случае он
посылает запрос еще одному серверу. Когда запрос окончательно распознан, ответ
перемещается назад, пока окончательно не достигнет запрашиваемого клиента.
Итерационное распознавание
Если клиент не запрашивает рекурсивный ответ, отображение может быть сделано
итерационно. Если сервер имеет разрешенное имя, он посылает ответ. Если нет, он
возвращает клиенту IP-адрес сервера, который, как он предполагает, может ответить на
запрос. Клиент повторяет запрос второму серверу. Если вновь адресованный сервер может
распознать запрос, он отвечает IP-адресом; в противном случае он возвращает IP-адрес
нового сервера клиенту. Теперь клиент должен повторить запрос третьему серверу. Этот
процесс называется итерационным, потому что клиент повторяет один и тот же запрос к
множеству серверов.
Кэширование
Каждый раз как сервер получает запрос имени, которого нет в его домене, ему
необходимо провести поиск в базе данных адресов первичного сервера. Уменьшение
времени поиска увеличило бы эффективность. DNS делает это с помощью механизма,
называемого кэшированием. Когда сервер запрашивает отображение от другого сервера и
получает отклик, он накапливает эту информацию в своей сверхоперативной памяти (кэшпамять), перед тем как послать ее другому клиенту. Если тот же самый или другой клиент
запрашивает отображение, он может проверить свою кэш-память и распознать номер.
Однако чтобы информировать клиента, что отклик пришел от кэш-памяти, а не от
полномочного источника, север маркирует отклик как неполномочный.
Кэширование ускоряет распознавание, но может и создать проблемы. Если сервер
кэширует отображение за долгое время, он может послать клиенту устаревшее
отображение. Чтобы противостоять этому, используются два метода.
При первом из них полномочный сервер всегда добавляет кусок информации для
отображения так называемого "времени жизни" (TTL – time to live). Оно определяет время
в секундах, в течение которого принимающий сервер может кэшировать информацию.
После истечения этого времени отображение недействительно, и любой запрос может
быть опять послан к полномочному серверу.
Второй метод состоит в том, что DNS-запрос, который каждый сервер сохраняет в памяти,
содержит TTL – ограниченное время для каждого отображения. Кэш-память периодически
сканируется, и отображения с истекшим "временем жизни" (TTL) удаляются.
341
мененную версию на вторичный.
DNS-сообщения
DNS имеет два типа сообщения: запрос и отклик. Оба типа имеют один и тот же формат.
Сообщение запроса содержит заголовок, запись запроса, ответную запись, запись
полномочий и дополнительные записи (рис. 3.1).
Рис. 3.1. Сообщение запроса и записи
Заголовок
Оба сообщения, запрос и отклик, имеют один и тот же формат заголовка с несколькими
полями с установленными нулями для сообщений отклика. Заголовок 12 байт и его
формат показан в (табл. 3.2).
Таблица 3.2. Формат заголовка
Идентификатор
Флаг
Номер записи запроса
Номер записи ответа (Все нули в сообщении
отклика)
Номер записи полномочий (Все нули в сообщении
отклика)
Номер записи ответа (Все нули в сообщении
отклика)
Поля заголовков – следующие:

Идентификация. Это 16-битовое поле применяется клиентом для того, чтобы сравнить отклик с
запросом. Клиент использует различный номер идентификации каждый раз, когда он посылает
запрос. Сервер дублирует этот номер в соответствующем отклике.

Флаги. Это 16-битовое поле, содержащее субполя, показано на (рис. 3.2).
342
Рис. 3.2. Поле флагов
Короткое описание субполей каждого флага дано ниже.
1.
QR (query/response) — запрос/ответ. Это однобитовое субполе, которое определяет тип
сообщения. Если оно равно 0, сообщение является запросом. Если оно равно 1, то сообщение —
ответ.
2.
OpCode (код операции). Это 4-битовое субполе, которое определяет тип запроса или ответа (0 —
тип стандартный, 1 — тип инверсный и 2 — сервер запрашивает состояние).
3.
AA (authoritative answer — авторитетный ответ). Это однобитовое поле. Когда оно установлено
(значение 1), это означает, что имя сервера является полномочным севером. Используется только в
ответном сообщении.
4.
TC (truncated — усеченное). Это однобитовое поле. Когда оно установлено (значение 1), это
означает, что ответ был более чем 512 байт и усечен до 512. Применяется, когда DNS пользуется
услугой UDP.
5.
RD (recursiondesired – желательна рекурсия). Это однобитовое субполе. Когда оно установлено
(значение 1), это означает, что клиенту желателен рекурсивный ответ. Он устанавливается в
сообщении запроса и повторяется в ответном сообщении.
6.
RA (recursion available — рекурсия возможна). Однобитовое субполе. Когда оно установлено в
ответе, это означает, что возможен рекурсивный ответ. Устанавливается только в ответном
сообщении.
7.
Reserved (резервные). Это трехбитовое субполе с установленными нулями.
8.
rCode (r-код). Это 4-битовое поле, которое показывает состояние ошибки в ответе. Конечно, только
полномочный сервер может сделать такую оценку. Таблица 3.2. показывает возможные значения
этого поля.
Таблица 3.3. Значения rCode
Значение
9.
Комментарий
0
Нет ошибки
1
Ошибка формат
2
Проблема имени сервера
3
Проблема ссылки на домен
4
Тип запроса не поддерживается
5
Административный запрет
6-15
Резервные
Поле записи запроса. Это 16-битовое поле, содержащее номер запроса в секции сообщения
запроса.
10. Поле записи ответа. Это 16-битовое поле, содержащее номер записи ответа в секции сообщения
отклика. Его значение равно нулю в секции запроса.
11. Поле записи полномочий. Это 16-битовое поле, содержащее номер записи полномочий в секции
полномочий. Его значение равно нулю в секции запроса.
12. Поле дополнительной записи. Это 16-битовое поле, содержащее номер дополнительной записи в
дополнительной секции сообщения отклика. Его значение равно нулю в секции запроса.
343
Имеются следующие типы секций.
Секция запроса
Это секция, содержащая одну или более записей. Она содержит оба сообщения: и запрос,
и ответ. Мы обсудим вопрос записи в следующем разделе.
Секция ответа
Это секция, содержащая одну или более записей. Она представляет только сообщения
ответа. Секция включает ответ от сервера к клиенту (сообщение распознавателя).
Секция полномочий
Это секция, содержащая одно или более сообщений источника. Она представлена только в
ответном сообщении. Секция дает информацию (имя домена) об одном или более
полномочном сервере для запроса.
Секция дополнительной информации
Это секция, содержащая одну или более записей источников. Она представляет только
ответные сообщения. Секция обеспечивает дополнительной информацией, которая может
помочь распознавателю. Например, сервер может дать имя домена полномочного сервера
распознавателю в полномочной секции и включать IP-адрес для того же самого
полномочного сервера в секции дополнительной информации.
Типы записей
Как мы видели в предыдущих разделах, в DNS используются два типа записей. Запись
запроса происходит в секции запроса, сообщения запроса или отклика. Средства записи
применяют в информации ответа, полномочий и дополнительной секции сообщения
ответа.
Запись запроса
Запись запроса используется клиентом, чтобы иметь информацию от сервера. Она
содержит доменное имя. Рисунок 3.3 показывает формат записи запроса. Список,
приведенный ниже, дает описание полей записи запроса.
344
Рис. 3.3. Формат записи запроса

Имя запроса. Это поле переменной величины, содержащее доменное имя рисунок 3.4.
Рис. 3.4. Формат имени запроса

Тип запроса. Это 16-битовое поле, определяющее тип запроса. Табл. 3.4 показывает обычно
используемые типы. Последние два могут быть применены только в запросе.
Таблица 3.4. Типы
Тип Мнемоника

Имя
Описание
1
A
Address
Адрес. 32-битовый Ipv6-адрес. Он используется для доменного
имени адреса IPv6
2
NS
Name server
Оно идентифицирует полномочный сервер зоны
5
CNAME
Canonical name
Каноническое имя. Оно определяет псевдоним для
официального имени хоста
6
SOA
Start of authority
Старт полномочиям. Он отмечает начало зоны. Это обычно
первая запись в файле зоны.
11
WKS
Well-know
services
Хорошо известный сервис. Он определяет сетевой сервис,
который обеспечивается хостом
12
PTR
Pointer
Указатель. Он используется для преобразования адреса в
доменное имя
13
HINFO
Host information
Информация хоста. Он дает определение аппаратуре и
операционной системе, используемой хостом
15
MX
Mail exchange
Обмен сообщениями. Он перенаправляет информацию к
почтовому серверу
28
AAA
Address An IPv6
address
Адрес IPv6
252 AXFR
Запрос на передачу по всей зоне
255 ANY
Запрос на все записи
Класс запроса. Это 16-битовое поле, которое определяет специальный протокол, используемый
DNS. Табл. 3.5 показывает текущие значения. В этой таблице нас интересует только класс 1
(Интернет).
Таблица 3.5. Классы
Класс
Мнемоника
1
IN
2
Зарезервировано
3
Зарезервировано
4
Зарезервировано
Описание
Интернет
345
Запись ресурса
Каждое доменное имя (каждый узел дерева) связан с записью, называемой записью
ресурса. Сервер базы данных содержит записи ресурса. Записи ресурса — это также то,
что возвращается сервером клиенту. Рис. 3.5 показывает формат записи ресурсов.
Рис. 3.5. Формат записи ресурсов

Имя домена. Это поле переменной длины, содержащее имя домена. Оно дублирует имя домена в
записи запроса. Пока DNS запрашивает использование сжатия, везде повторяется имя — указатель
ответвления к соответствующему полю имени домена в записи запроса. См. раздел "Сжатие".

Тип домена. Это поле такое же, как поле типа запроса в секции запроса, исключая два последних
типа, которые не разрешены.

Класс домена. Это поле такое же, как поле класса запроса в секции запроса ( (см. табл. 3.5).

Время жизни. Это 32-битовое поле, определяющее число секунд, при котором ответ действителен.
Приемник может кэшировать ответ на этот период времени. Значение нуль означает, что запись
ресурсов используется только на один переход и не может быть кэширована.

Длина ресурса данных. Это 16-битовое поле, определяющее длину ресурса данных.

Данные ресурса. Это поле переменной длины, содержащее ответ на запрос (в секции ответ), или
имя домена полномочного сервера (в секции полномочий), или дополнительную информацию (в
дополнительной секции). Формат и содержание этого поля зависит от значения типа поля. Оно
может быть одним из нижеследующих:
o
Номер. Это – записанный октет. Например, Ipv4-адрес – это целое число из 4-х октетов, и
IPv6-адрес – это целое число из 16-ти октетов.
o
Имя домена. Имена домена выражаются как последовательность меток. Каждая метка
помечается полем однобайтовой длины, которое определяет число символов в метке.
Каждое имя домена заканчивается нулевой меткой, последний байт каждого имени домена
— поле длины со значением 0. Для того чтобы отличить поле длины и точку ответвления
(как, мы будем это обсуждать позднее), два старших разряда длины поля должны быть
всегда нулевыми (00). Это не будет создавать проблем, потому что длина метки не может
быть больше 63 — максимального значения из 6-ти (111111).
346
o
Точка ответвления. Имя домена может быть заменено точкой ответвления. Точка
ответвления — двухбайтное поле с двумя старшими битами, установленными в положение
1 (11).
o
Строка символов. Строка символов представляется полем длиной в 1 бит
(сопровождаемое число символов, определяемых длиной поля .zk). Строчка символов
может иметь длину до 256 символов (включая поле длины).
Сжатие
Когда имя домена повторяется, DNS требует, чтобы оно заменялось указателем сдвига.
Например, запись ресурса имени домена обычно повторяет имя домена в запросе. Для
того чтобы избежать дублирования, DNS определяет двухбайтовый указатель сдвига,
который указывает на предыдущее вхождение имени в домен или часть его. Формат поля
показан на Рис. 3.6
Рис. 3.6. Формат указателя сдвига
Первые два старших разряда — это две единицы, необходимые для того, чтобы отличить
точку-указатель сдвига от информации "длина поля".) Другие 14 бит представляют число,
которое указывает на соответствующий байт номера сообщения. Этот байт отсчитывается
от начального сообщения с первым байтом, который считается нулевым. Например, если
указатель сдвига указывает на байт 12 (тринадцатый байт) сообщения, значение должно
быть 1100000000001100. Здесь 2 наибольших левых разряда определяют поле как
указатель ответвления, а другие биты определяют десятичное число 12. Мы покажем, как
используются указатели сдвига на следующих примерах.
Краткие итоги

Система доменных имен (DNS – Domain Name System) – это приложение клиент-сервер, которое
определяет каждый хост в Интернете с уникальным именем, дружественным пользователю.

DNS организует пространство имен в иерархическую структуру для децентрализации обязательств,
содержащихся в наименовании.

DNS может быть изображено как инвертированная структура иерархического дерева с одним
узловым корнем на вершине и максимально 128 уровнями.

Каждый узел в дереве имеет доменное имя.

Домен определяется как любое поддерево в пространстве доменных имен.

Информация пространства имен распределяется среди DNS-серверов. Каждый сервер имеет
юрисдикцию в своей зоне.

Зона корневого сервера — это целое DNS-дерево.

Первичный сервер создает, эксплуатирует и корректирует информацию о своей зоне.

Вторичный сервер выдает свою информацию о первичном сервере.
347

Пространство доменных имен разделяется внутри дерева на секции: родовые имена, домены страны
и инверсные домены.

Имеется семь родовых имен, каждое определяет тип организации.

Каждое доменное имя определяет страну.

Инверсный домен находит доменное имя для выдачи IP-адреса. Это называется "распознавание
адрес–имя".

Имя серверов, компьютеров, которые работают с программами DNS-серверов, организованы
иерархически.

DNS-клиент, называемый распознаватель, сопоставляет имени адрес или адресу имя.

В рекурсивном распознавании клиент посылает свой запрос к серверу, который в зависимости от
обстоятельств возвращает ответ.

При интерактивном распознавании клиент может посылать свой запрос ко многим серверам,
прежде чем получить ответ.

Кэширование – это метод, посредством которого ответ на запрос накапливается в памяти
(ограниченное время) для простого доступа будущих запросов.

Полностью квалифицированное доменное имя (FQDN) – это доменное имя, которое содержит
метки, начинающиеся с хоста и проходящие через каждый уровень к корневому узлу.

Частично квалифицированное доменное имя (PQDN) – это имя домена, которое не включает все
уровни между хостом и корневым узлом.

Имеется два типа DNS-сообщений: запросы и ответы.

Имеется два типа записи запроса и записи ресурсов: запросы и ответы.

DNS использует указатель сдвига для дублирования информации доменных имен в сообщениях.

Имеется два типа DNS-сообщений: запросы и ответы.

Динамическая DNS (DDNS) автоматически корректируется DNS-мастер-файлом.

DNS использует обслуживание UDP для сообщений, меньших чем 512, в противном случае
применяется TCP.
World Wide Web (WWW) – это хранилище информации, размещенной во всем мире и
соединенной воедино. WWW – уникальная комбинация гибкости, мобильности
дружественных пользователю свойств, что отличает ее от других служб, обеспечиваемых
с помощью Интернета.
WWW-проект был инициирован CERN (Center European Laboratory for Practice Physics),
чтобы создать систему для обработки распределенных ресурсов, необходимых для
научных исследований.
WWW сегодня — распределенная система клиент-сервер обслуживания, в которой
клиент, использующий браузер1, может иметь доступ к этой службе с применением
сервера. Однако обеспечиваемая служба распределяется по многим местам, называемым
вместе websites.
348
Архитектура
Эта услуга может обеспечиваться во многих местах, которые называются сайтами, как это
показано на рис. 16.1.
Каждый сайт содержит одну или более ссылок на веб-документы. Каждая веб-страница
может содержать линк (связь) с другими страницами на том же самом сайте. Страницы
могут быть вызваны для работы с браузерами. Рассмотрим сценарий, показанный рис.
16.1. Клиенту нужна информация, которая принадлежит сайту A. Он посылает запрос
через браузер, программа которого доставляет веб-документ. Запрос, который включает в
себя адрес веб-сайта и веб-страницы (web-page), называется универсальным
идентификатором ресурса — URL (Uniform Resource Locator), который будет рассмотрен
далее. Сервер находит и посылает документ клиенту. Когда пользователь смотрит
документ, он может найти ссылки на другие документы, включая веб-страницы сайта B.
Ссылка содержит URL для нового сайта. Пользователь может рассмотреть другой
интересующий его документ. Клиент посылает другой запрос к новому сайту и вызывает
другую страницу.
Рис. 16.1. Архитектура WWW
Архитектура браузеров
Различные производители предлагают коммерческие браузеры, которые интерпретируют
и отображают веб-документы, и все они используют одинаковую или родственную
349
архитектуру. Каждый браузер обычно содержит три части: контроллер, клиентский
протокол и интерпретатор. Контроллер получает входную информацию от клавиатуры
или "мыши" и использует клиентскую программу для доступа к документам. После того
как документ доступен, контроллер применяет один из интерпретаторов, чтобы
отобразить документ на экране. Клиентские программы могут использовать один из
методов (протоколов) – такие как HTTP, FTP, TELNET. Интерпретатор может быть HTML
или Java, JavaScript, в зависимости от типа документа ( рис. 16.2.).
Рис. 16.2. Архитектура браузера
Сервер
Веб-страница хранится в веб-сервере. Каждый раз, когда поступает запрос клиента, ему
посылается соответствующий документ. Для повышения эффективности работы обычно
сервер хранит запрашиваемые файлы в кэш-памяти, это ускоряет поиск при запросе.
Сервер более эффективен, если он может выполнять параллельные процессы или является
многопроцессорным. В этом случае он способен отвечать одновременно на несколько
запросов.
Унифицированный локатор ресурса — URL (Uniform Resource Locator)
Клиент, который хочет вызвать веб-страницу, должен располагать ее адресом. Чтобы
обеспечить доступ к документам, разбросанным во всем мире, существует протокол
передачи гипертекста (HTTP – Hypertext Transfer Protocol). Индивидуальный индикатор
ресурса — URL (Uniform Resource Locator) — стандарт для любой заданной информации в
Интернете. URL определяет четыре элемента: протокол, хост, порт и путь ( рис. 16.3.).
Протокол (метод) – программа клиент-сервер, используемая для доставки документа.
Несколько различных протоколов могут доставлять документ; среди них Gopher, FTP,
HTTP, News и TELNET. На сегодня наиболее общий протокол — HTTP.
350
Хост – компьютер, где находится информация, хотя имя компьютера может быть
псевдонимом. Веб-страницы обычно накапливаются в компьютерах, и компьютеры дают
псевдонимы именам, которые обычно начинаются с символов "www". Однако это не
обязательно, поскольку хост может быть с любым именем, данным компьютеру, который
является хостом веб-страницы.
Рис. 16.3. Универсальный идентификатор ресурса — URL
URL иногда может содержать номер порта сервера. Если порт включен, он должен быть
вставлен между хостом и путем и должен быть отделен от хоста двоеточием.
Путь — имя пути к файлу, где находится информация. Заметим, что путь сам может
содержать "слеши" (наклонные черточки), которые в операционной системе UNIX
отделяют директории от поддиректорий и файлов.
URI — это символьная строка, позволяющая идентифицировать какой-либо ресурс:
документ, изображение, файл, службу, ящик электронной почты и т. д. Прежде всего, речь
идёт, конечно, о ресурсах сети Интернет и Всемирной паутины. URI предоставляет
простой и расширяемый способ идентификации ресурсов. Расширяемость URI означает,
что уже существуют несколько схем идентификации внутри URI, и ещё больше будет
создано в будущем. труктура URI очень гибка, синтаксис не сложен. В базовом виде URI
представляется как:
<схема>:<идентификатор-в-зависимости-от-схемы>
В этой записи:
схема
схема обращения к ресурсу, например http, ftp, mailto, urn
идентификатор-в-зависимости-от-схемы
непосредственный идентификатор ресурса, вид которого зависит от выбранной схемы обращения к
ресурсу
Часть идентификатора URI без схемы обращения к ресурсу часто называется «ссылкой
URI» (англ. URI reference). Прецеденты применения ссылок URI имеются в HTML,
XHTML, XML и XSLT. Процесс превращения ссылки URI в абсолютную форму URI
называют «разрешением URI» (англ. URI resolution).
Процесс разработки новых схем описан в документе RFC 2718. Новые схемы должны
регистрироваться в организации IANA (англ. Internet Assigned Numbers Authority),
процедура регистрации зафиксирована в RFC 2717. Оба указанных запроса комментариев
(RFC) сейчас находятся в процессе переработки.
351
[править] Разбор структуры URI
Для так называемого «па́рсинга» URI (англ. parsing), то есть для разложения URI на
составные части и их последующей идентификации удобнее всего использовать систему
регулярных выражений, доступную ныне почти во всех современных языках
программирования. Для разбора URI рекомендуется[1] использовать следующий шаблон:
^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
12
3 4
5
6 7
8 9
Этот шаблон включает в себя 9 обозначенных выше цифрами групп (подробнее о
шаблонах и группах см. Регулярные выражения), которые наиболее полно и точно
разбирают типичную структуру URI, где:

группа 2 — схема,

группа 4 — источник,

группа 5 — путь,

группа 7 — запрос,

группа 9 — фрагмент.
Таким образом, если при помощи данного шаблона разобрать, например, такой типичный
идентификатор URI:
http://www.ics.uci.edu/pub/ietf/uri/#Related
то 9 вышеуказанных групп шаблона дадут следующие результаты соответственно:
1.
http:
2.
http
3.
//www.ics.uci.edu
4.
www.ics.uci.edu
5.
/pub/ietf/uri/
6.
нет результата
7.
нет результата
8.
#Related
9.
Related
Отличие URI от URL
URI не всегда указывает то, как получить ресурс, в отличие от URL, а только
идентифицирует его. Это даёт возможность описывать с помощью RDF (Resource
Description Framework) ресурсы, которые не могут быть получены через Интернет
(например, личность, автомобиль, город и проч.).
RFC 3986 / STD 66 (от 2005 года)
352
URN (англ. Uniform Resource Name) — единообразное название (имя) ресурса. На
английский манер произносится как [эо́рн], по-русски чаще говорят [у-эр-э́н]. URN — это
постоянная последовательность символов, идентифицирующая абстрактный или
физический ресурс. URN является частью концепции URI (англ. Uniform Resource
Identifier) — единообразных идентификаторов ресурса. Имена URN призваны в будущем
заменить локаторы URL (англ. Uniform Resource Locator) — единообразные определители
местонахождения ресурсов. Но имена URN, в отличие от URL, не включают в себя
указания на местонахождение и способ обращения к ресурсу. Стандарт URN специально
разработан так, чтобы он мог включать в себя другие пространства имён. Идея URN
возникла из-за существенных недостатков системы URL. Ресурсы во Всемирной паутине
и Интернете перемещаются, а ссылки в виде URL остаются, указывая на уже
отсутствующие ресурсы. Старые URL также делаются бесполезными при
реструктуризации ресурсов, переименовании, удалении, перемещении в другой домен
DNS. Для решения этой проблемы была разработана интересная и эффективная система
PURL (англ. Persistent Uniform Resource Locator — постоянный URL), ныне уже широко
используемая, а также система DOI (англ. Digital Object Identifier — цифровой
идентификатор объекта). Но это всё же лишь частичные решения проблемы.
Принципиальным же решением должен стать стандарт единообразного именования
ресурсов URN.
URN указывает неизменное имя ресурса без указания его местонахождения и способа
обращения. В результате URN-имена совершенно постоянны, они не зависят от
конкретных серверов и протоколов. Другими словами, URN концептуально обозначает
сам ресурс, а не место, где находится какой-то ресурс (а может, уже не находится), как это
делает URL. Например, допустим, есть человек по имени Михаил Петров, который живёт
в Москве по адресу ул. Земляной вал, 14. Если кто-то спросит его: «Вы кто?». Он,
разумеется, ответит «Я — Михаил Петров». Он ведь не скажет: «Я человек, живущий на
Земляном валу, 14». Так вот URN идентифицирует человека как «Михаил Петров», а URL
лишь сообщает, что кто-то живёт по адресу ул. Земляной вал, 14 (а может там находится и
организация… URL этого не сообщает).
Для нахождения ресурсов по URN-имени нужна «система разрешения URN-имён» (англ.
URN resolution). Тогда человек (или программа), знающий точный URN ресурса, введёт
его в систему разрешения и немедленно получит множество конкретных мест (серверов
или, скажем, интернет-магазинов), где этот ресурс можно найти. В 2002 году была
предложена система DDDS (англ. Dynamic Delegation Discovery System) — система
динамического обнаружения ресурсов, которая разрешает имена URN в URL-ссылки на
конкретные местонахождения ресурсов. При этом и URN, и URL являются частью одной
системы идентификации ресурсов URI.
Структура URN
Единообразные имена ресурсов имеют следующую структуру:
<URN> ::= "urn:" <NID> ":" <NSS>
В этой записи:
<NID>
353
идентификатор пространства имён (англ. Namespace Identifier), представляет собой
синтактическую интерпретацию NSS; не чувствителен к регистру.
<NSS>
строка из определённого пространства имён (англ. Namespace Specific String); если в этой строке
содержатся символы не из набора ASCII, то они должны быть закодированы в Юникоде (UTF-8) и
предварены (каждый из них) знаком процента «%». Подробнее см. URL.
При этом начальная последовательность символов "urn:" не чувствительна к регистру. А
идентификаторы пространства имён «urn» и «URN» запрещены вообще, чтобы не
возникло путаницы с этой начальной строкой "urn:".





RFC 2141 — Синтаксис URN
RFC 1737 — Функциональные требования к URN
RFC 2483 — Системы разрешения URI для URN
RFC 3406 — Определение пространств имён для URN
RFC 3986 / STD 66 — Спецификация URI
19.Объектно-ориентированное программирование на языке С#. Классы.
Механизмы наследования. Объектные типы данных. Указатели.
С#. Классы и структуры. Объектные типы
Объектно-ориентированное программирование на языке С#
Управляемый код
Язык программирования C# был разработан как язык, использующий технологию .NET.
Поэтому приложение на C# компилируется в промежуточный код, называемый IL-кодом
(Intermediate Language) или MSIL-кодом (Microsoft intermediate language). Такой код перед
выполнением компилируется JIT-компилятором в команды, отвечающие специфике
конкретного процессора.
Выполнение IL-кода управляется механизмом CLR (Common Language Runtime),
непосредственно осуществляющим JIT-компиляцию (Just In Time), наложение политик
безопасности, предоставление отладочных сервисов, автоматическое управление памятью
(реализация механизма "сборки мусора"). IL-код можно компилировать как при установке
приложения, так и при его выполнении (при этом компилироваться будет не весь код, а
только реально вызываемые методы). В процессе компиляции кроме IL-кода
формируются также метаданные, описывающие классы. CLR использует метаданные для
поиска и загрузки классов, размещения объектов в памяти, определения входящих в класс
354
методов и свойств. 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#
автоматически помещается в отдельный модудь - файл с расщирением cs). Среда Visual
Studio 2005 позволяет создавать частичные классы ( partial class), когда один класс
355
содержится в нескольких файлах. Соединение всех частей класса выполняется на этапе
компиляции. (Вообще, частичными также могут быть структуры и интерфейсы.)
Для консольного приложения один из классов, реализуемых модулем, должен содержать
метод 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 которого следует считать точкой входа в приложение. Это можно сделать, установив
опции проекта или указав опцию компилятора /main с именем класса, чей метод Main
будет задействован (например: csc class1.cs class2.cs /main:Class2).
356
Для того чтобы установить опцию проекта, определяющую "стартовый" класс (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 выделить
секцию с именем проекта и выполнить команду меню View|Property Pages (или Shift+F4), а
затем, выбрав папку Configuration Properties и страницу свойств Build, установить новое
357
значение свойства 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] ...] {
// объявляемые_данные
}
Пространство имен указывается идентификатором, который может содержать операцию . ,
определяющую составное имя пространства имен.
Объявляемыми данными пространства имен могут быть:

другие пространства имен;

классы;

интерфейсы;

структуры;

перечисления.
358
Для того чтобы иметь возможность обращаться к переменным или методам из
пространства имен, можно использовать один из следующих способов:

имя соответствующей переменной или метода должно быть квалифицировано названием
пространства имен (пространство имен указывается перед именем через точку).
Например:
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# и соответствующие им предопределенные типы
пространства имен являются при написании программы взаимозаменяемыми.
Для определения типа переменной можно использовать метод GetType или оператор
typeof.
359
Библиотека классов 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# поддерживает три типа конструкторов:

конструктор экземпляра объекта ( instance), используемый при создании объекта;
360

private-конструктор, указываемый в коде для предотвращения автоматического создания
конструктора по умолчанию. Такой тип конструктора используется для классов, имеющих только
статические члены. Экземпляр объекта с private-конструктором не может быть создан.

статический конструктор ( static), вызываемый для инициализации класса до создания первого
объекта или до первого вызова статического метода. Статический конструктор не может иметь
модификаторы доступа и список параметров.
Конструктор экземпляра объекта имеет следующее формальное описание:
[атрибуты] [модификаторы_доступа]
имя_конструктора([список_формальных_параметров])
[:base (список_аргументов) | :this (список_аргументов)]
{ тело_конструктора }
Ключевое слово base определяет явный вызов конструктора базового класса, а ключевое
слово this - вызов конструктора данного класса с указанным списком параметров.
Например:
public class AClass1
{
public AClass1()// Объявление конструктора
{
}
}
Ключевое слово class определяет имя объявляемого класса. Тело объявляемого класса
указывается в фигурных скобках.
Ключевое слово public - это модификатор доступа, указывающий, что объявляемые после
него идентификаторы (имена классов или методов) будут общедоступны (модификатор
доступа позволяет определить область видимости переменных и методов - членов класса).
По умолчанию все переменные и методы - члены класса, заданные без модификатора
доступа, считаются private-переменными (называемыми иногда приватными или
закрытыми). Приватные переменные доступны только внутри экземпляра класса и не
могут быть использованы во внешних функциях модуля.
Модификаторы доступа
В языке C# применяются следующие модификаторы доступа:

public - доступ не ограничен;

protected - доступ ограничен только наследуемыми классами;

internal - доступ ограничен рамками текущего проекта;

private - доступ ограничен рамками данного класса.
Для любого члена класса или объектного типа разрешено указывать только один
модификатор доступа, за исключением комбинации protected internal, регламентирующей
ограничение доступа наследуемыми классами текущего проекта.
Например:
361
class A
{
protected int x = 100;
}
class B : A
{
void M1()
{
A a1 =
B b1 =
// a1.x
b1.x =
}
}
new A(); // Создание объекта типа A
new B(); // Создание объекта типа B
= 200;
- доступ не разрешен
200;
// Правильно реализованный доступ
Отметим, что пространство имен не может иметь модификатора доступа.
Язык C# поддерживает использование вложенных классов.
Типы верхнего уровня, которые не являются вложенными в другие типы, могут иметь
модификатор доступа только internal (по умолчанию) или public.
Если модификатор доступа не указан, то применяется доступ по умолчанию. В следующей
таблице отображены модификаторы доступа для вложенных типов, являющихся членами
других типов.
Член,
определяемый в:
Модификатор
доступа,используемый по
умолчанию
Допустимые модификаторы
доступа,используемые для членов
enum
Public
-
class
private
public protected internal private protected internal
interface
public
-
struct
private
public internal private
Структуры не могут иметь модификатор
доступа protected,так как не могут быть
наследуемы
Например:
using System;
namespace MyNameSpace
{
public class A
{
public static int myPublicInt;
internal static int myInternalInt;
private static int myPrivateInt = 0;
public class Nest1
// "Вложенный" член класса
{
public static int myPublicInt;
internal static int myInternalInt;
private static int myPrivateInt = 0;
}
362
private class Nest2
// "Вложенный" член класса
{
public static int myPublicInt = 0;
internal static int myInternalInt = 0;
private static int myPrivateInt = 0;
}
}
public class MyClass
{
public static int Main()
{
// Доступ к членам класса A:
A.myPublicInt = 1; // Доступ не ограничен
A.myInternalInt = 2; // Только в текущем проекте
// A.myPrivateInt = 3; - ошибка: нет
// доступа вне класса
// Доступ к членам класса Nest1:
A.Nest1.myPublicInt = 1; // Доступ не ограничен
A.Nest1.myInternalInt = 2;
// Только в текущем проекте
// A.Nest1.myPrivateInt = 3; - ошибка: нет
// доступа вне класса Nest1
// Доступ к членам класса Nest2:
// A.Nest2.myPublicInt = 1;
- ошибка: нет
// доступа вне класса A
// A.Nest2.myInternalInt = 2; - ошибка: нет
// доступа вне класса A
// A.Nest2.myPrivateInt = 3; - ошибка: нет
// доступа вне класса Nest2
return 0;
}
}
}
Листинг 15.1. (html, txt)
Создание экземпляра класса
Для использования переменных или методов класса следует создать объект - экземпляр
класса.
В языке C# экземпляр класса всегда создается при помощи оператора new. Если класс
имеет несколько конструкторов, то при создании переменной указывается требуемый
конструктор.
Место выделения памяти под объект зависит от типа создаваемого объекта: объекты
ссылочных типов размещаются в куче, а объекты размерных типов - в стеке.
Объявление переменной объектного типа в языке С# не создает объекта, а только
определяет идентификатор указанного типа. Обратите внимание, что во многих объектноориентированных языках, таких как С++, объявление переменной объектного типа также
становится и созданием экземпляра данного типа.
Например:
using System;
363
namespace MyNS
{
public class A
{ public A()
// Конструктор без параметров
{ Console.WriteLine("A()"); }
public A(int i)
// Конструктор с одним параметром
{ Console.Write("A(i) i= ");
Console.WriteLine(i);
}
}
}
using System;
namespace MyNS
{
class MyClass
{
static void Main(string[] args)
{ A acl1= new A();
// Создание экземпляра класса
A acl2= new A(987);
}
}
}
Явный вызов конструктора
Определение конструктора может содержать явный вызов конструктора того же класса.
Вызываемый конструктор указывается после имени определяемого конструктора со
списком параметров через символ двоеточия. Вызываемый конструктор может быть
определен ключевым словом this - для вызова конструктора из того же самого класса, или
ключевым словом base - для вызова конструктора базового класса. Явно вызываемый
конструктор будет выполнен до выполнения конструктора, в котором он указывается.
Например:
public class A
{ public A():this(222) // Конструктор без параметров
{ }
public A(int i) // Конструктор с одним параметром
{ }
}
Методы члены класса
Среда проектирования Visual Studio .NET дает возможность использовать мастер создания
метода - члена класса (в окне Class View выбрать имя класса и выполнить команду
контекстного меню Add|Add Metod). Список Modifier. диалога. C# Metod Wizard
позволяет указать один из следующих модификаторов параметра метода:

none - определяет передачу параметров по значению. Если внутри метода будет изменено значение
фактического параметра, то вне метода его значение останется прежним;

ref - определяет передачу параметров по ссылке. Изменение параметра внутри метода останется и
после завершения метода. ref-параметр перед использованием обязательно должен быть
инициализирован;
364

out - определяет передачу параметров по результату. При завершении метода конечное значение
формального параметра присваивается указанному при вызове фактическому параметру. При этом в
момент вызова метода фактический параметр может не быть инициализирован.
Например:
public void Metod1(int i, ref int j, out int k)
{
}
При обращении к методу или полю - членам класса используется операция . (точка) доступ к члену класса. Имя поля или метода члена класса квалифицируется именем
экземпляра класса.
Язык C# позволяет использовать методы с переменным числом параметров. Для метода с
переменным числом параметров должны быть выполнены следующие правила:

переменный список параметров выступает как единый параметр и указывается ключевым словом
params;

кроме переменного списка параметров, никаких других параметров после ключевого слова params в
методе указывать нельзя;

в методе может быть указано только одно ключевое слово params, определяющее переменный
список параметров.
Количество параметров в переменном списке параметров определяется свойством Length .
Например:
using System;
public class MyClass1
{
public static void UseParams1(params int[] list)
{
// Отображение списка параметров
for ( int i = 0 ; i < list.Length ; i++ )
Console.WriteLine(list[i]);
}
public static void UseParams2(params object[] list)
{ // В переменном списке параметров могут быть
// объекты различных типов
for ( int i = 0 ; i < list.Length ; i++ )
Console.WriteLine((object)list[i]);
}
public static void UseParams3(int k,params object[] list)
{ // В переменный список параметров
// включаются параметры, начиная
// со второго
for ( int i = 0 ; i < list.Length ; i++ )
Console.WriteLine((object)list[i]);
}
public static void Main()
{
UseParams1(1, 2, 3, 4, 5);
UseParams1(1, 2);
int[] myarray = new int[3] {1,2,3};
UseParams1(myarray);
365
UseParams2(111, 'f', "string");
UseParams3(111, 'f', "string");
}
}
Листинг 15.2. (html, txt)
Механизмы наследования
Объявление класса в языке C# создает новый ссылочный тип, определяющий как
описание методов, так и их реализацию.
Объявление интерфейса создает новый ссылочный тип, который специфицирует описание
методов и имена некоторых констант, но не определяет саму реализацию.
Интерфейс может быть объявлен для расширения одного или нескольких интерфейсов.
Наследование позволяет определять новые классы в терминах существующих классов. В
языке C# поддерживается только простое наследование: любой подкласс является
производным только от одного непосредственного суперкласса. При этом любой класс
может наследоваться от нескольких интерфейсов.
Производные классы
В среде VisualStudio.NET новый производный класс можно создать, используя окно
ClassView (выполнив в нем команду контекстного меню Add|Add Class). Рисунок 16.1
иллюстрирует страницы диалога C# Class Wizard, предлагаемого средой VisualStudio.NET
для создания нового класса.
Рис. 16.1. Диалог C# Class Wizard
Имя создаваемого класса указывается в поле Class Name на странице Class Options диалога
C# Class Wizard.
366
В поле Namespace указывается пространство имен, к которому будет принадлежать
создаваемый класс. По умолчанию проект размещается в пространстве имен,
одноименным с именем проекта.
В поле Access выбирается модификатор доступа для создаваемого класса.
Для класса в языке C# возможно использование двух модификаторов доступа:

public - определяет, что нет ограничений на использование класса;

internal - определяет, что класс будет доступен для файлов, входящих в ту же сборку.
Сборка - это физический файл, который состоит из нескольких PE-файлов (portable
executable), генерируемых компилятором среды .NET. В сборку входит декларация
(manifest), содержащая описание сборки для управляющей среды .NET.
Класс может имеет один из следующих модификаторов класса:

abstract - определяет, что класс должен быть использован только как базовый класс других классов.
Такие классы называются абстрактными классами;

sealed - определяет, что класс нельзя использовать в качестве базового класса. Такие классы в языке
C# иногда называются изолированными классами.
Очевидно, что изолированный класс не может быть одновременно и абстрактным
классом.
Объявление класса может иметь следующее формальное описание:
МодификаторДоступа МодификаторКласса class ИмяКласса
: ИмяНаследуемогоКласса
{ТелоКласса
}
Тело класса содержит описание переменных, методов и вложенных классов и заключается
в фигурные скобки. В частном случае тело класса может не содержать ни одного
объявления.
Например:
namespace CA1
{
public abstract class Class2 : CA1.Class1
{
public Class2()
{
// TODO: Add constructor logic here
}
}
}
367
Методы - члены класса
В среде VisualStudio.NET добавить в класс новый метод можно, используя контекстное
меню окна Class View. На рис. 16.2 приведен диалог C# MetodWizard, позволяющий
определить модификаторы метода и список формальных параметров.
Рис. 16.2. Диалог C# MetodWizard
Язык C# поддерживает следующие модификаторы метода члена класса:

static - определяет статический метод, доступный без создания экземпляра класса;

abstract - определяет абстрактный метод, который является членом абстрактного класса;

virtual - метод, реализация которого может быть переопределена в производных классах;

extern - метод, имеющий реализацию вне данного класса (внешний метод);

override- метод, выполняющий переопределение виртуальной функции, наследуемой от базового
класса;

new - метод, скрывающий в производном классе наследуемый метод с тем же именем (если
ключевое слово не указано, то имя скрывается, но при компиляции отображается предупреждение
warning).
Порядок указания модификаторов доступа и модификаторов метода несущественен.
Виртуальные и абстрактные методы всегда должны указываться с модификатором
доступа public.
Виртуальные методы
Виртуальные методы объявляются в базовом классе с ключевым словом virtual, а в
производном классе могут быть переопределены. Метод, который переопределяет
368
виртуальный, указывается ключевым словом override. Прототипы виртуальных методов
как в базовом, так и в производном классе должны быть одинаковы.
Применение виртуальных методов позволяет реализовывать механизм позднего
связывания.
На этапе компиляции строится только таблица виртуальных методов, а конкретный адрес
проставляется уже на этапе выполнения.
При вызове метода - члена класса действуют следующие правила:

для виртуального метода вызывается метод, соответствующий типу объекта, на который имеется
ссылка;

для невиртуального метода вызывается метод, соответствующий типу самой ссылки.
При позднем связывании определение вызываемого метода происходит на этапе
выполнения (а не при компиляции) в зависимости от типа объекта, для которого
вызывается виртуальный метод.
При раннем связывании определение вызываемого метода происходит на этапе
компиляции.
Например:
using System;
namespace MyDerriv1
{
class Class1
{
static void Main(string[] args)
{
// Тип объекта и тип ссылки совпадают
CA var1; var1=new CA();
// Вызывается метод класса CA
Console.WriteLine (var1.F1());
// Вызывается метод класса CA
Console.WriteLine (var1.F2());
// Тип объекта - CB , а тип ссылки - CA
CA var2; var2=new CB();
// Вызывается метод класса CA
Console.WriteLine (var2.F1());
// Вызывается метод класса CB
Console.WriteLine (var2.F2());
}
}
}
// Класс CA
using System;
namespace MyDerriv1
{
public class CA
{ public CA()
{
}
public int F1() { return 1; }
public virtual string F2()
{return "Метод F2 класса CA";}
}
369
}
// Класс CB
using System;
namespace MyDerriv1
{ public class CB : MyDerriv1.CA
{
public CB() {
}
public int F1() {return 2; }
// Переопределение виртуального метода F2
public override string F2()
{ return "Метод F2 класса CB"; }
}
}
Листинг 16.1. (html, txt)
Абстрактные классы
Абстрактным классом называется класс, который содержит один или несколько
абстрактных методов.
Абстрактный класс не может использоваться для создания объектов.
Как правило, абстрактный класс описывает некий интерфейс, который должен быть
реализован всеми его производными классами.
Абстрактный метод языка C# не имеет тела метода и аналогичен чисто виртуальному
методу языка C++.
Например:
public abstract int M1(int a, int b);
Абстрактный класс можно использовать только как базовый для других классов. При
этом если производный класс не содержит реализации абстрактного метода, то он также
является абстрактным классом.
По умолчанию при создании абстрактного класса в среде VisualStudio .NET в
формируемый абстрактный класс автоматически вставляется только один метод конструктор без параметров.
Интерфейсы
Определение интерфейса
В языке C# отсутствует множественное наследование: каждый класс может иметь только
один непосредственный базовый класс. Частичной заменой множественному
наследованию может служить использование интерфейсов.
Интерфейсы могут содержать свойства, методы и индексаторы, но без их реализации.
Один класс языка C# может наследовать несколько интерфейсов.
370
В C# интерфейс определяет новый ссылочный тип, содержащий объявления методов,
которые обязательно должны быть реализованы в классе, наследующем данный
интерфейс.
Можно сказать, что интерфейс определяет некоторую модель поведения, которая должна
быть реализована в любом классе, наследующем данный интерфейс.
Объявление интерфейса может иметь следующее формальное описание:
[атрибуты] [модификаторы]
interface имя_интерфейса
[:список_базовых_интерфейсов]
{тело_интерфейса}[;]
Например:
interface IMyInterface: IBase1, IBase2
{
int M1();
int M2();
}
Если класс, наследующий интерфейс, не является абстрактным, то он обязательно должен
реализовать методы, объявленные в интерфейсе. При наследовании интерфейса
абстрактным классом методы, объявленные в интерфейсе, могут не иметь реализации
только в том случае, если они объявляются с модификатором abstract.
Например:
public abstract class CMyInterface : IMyInterface
{
public CMyInterface()
{
//
}
public abstract int M1();
public abstract int M2();
}
interface IMyInterface
{
int M1();
int M2();
}
Определение типа объекта
Для получения информации о том, является ли тип объекта времени выполнения
совместимым с заданным типом, используется оператор is. Если типы совместимы, то
оператор возвращает значение true.
Оператор as аналогичен оператору is, с той лишь разницей, что выполняет приведение в
случае совместимости типов или устанавливает ссылку на несовместимый объект равной
null.
371
Применение оператора is имеет следующее формальное описание:
выражение is тип
Например:
string str1 = myObjects;
if (str1 is string)
Console.WriteLine ("тип string");
Применение оператора as имеет следующее формальное описание:
выражение as тип
Например:
string str1 = myObjects as string;
if (str1 != null) Console.WriteLine ( "это строка" );
При этом предыдущая форма записи эквивалентна следующей записи:
выражение as тип ? (тип)выражение : (тип)null
Приведение типа объекта к типу интерфейса
При создании объект сразу можно приводить к типу интерфейса, используя оператор as
Например:
Object ivar1 = varb1 as IA;
Если приведение допустимо, то переменная будет содержать ссылку на интерфейс. Если
приведение типа объекта типу интерфейса недопустимо, то в результате приведения типа
переменная примет значение null.
Следующий пример иллюстрирует определение типов объектов и приведение типа
объекта к типу интерфейса.
using System;
namespace MyAClass1
{ class Class1
{[STAThread]
// Класс
// System.STAThreadAttribute,
// определяющий однопотоковую модель
static void Main(string[] args)
{
CB varb1 = new CB();
/* Запрос о совместимости типа объекта с типом наследуемого им интерфейса */
if (varb1 is IA)
/* Если переменная типа CB является переменной типа класса, реализующего
запрашиваемый интерфейс IA, то оператор is вернет значение true. */
{Console.WriteLine ("varb1 - это ссылка на
класс, который реализует интерфейс IA");}
// Создание объекта типа интерфейса IA
IA ivar=(IA)varb1;
if (ivar is IA)
{Console.WriteLine ("ivar - это ссылка на интерфейс IA");}
bool var1=ivar.F1();
Console.WriteLine("Вызов метода F1 интерфейса IA: {0}",var1);
// Приведение объекта к типу интерфейса
Object ivar1 = varb1 as IA;
372
if (ivar1 != null)
Console.WriteLine ( "ivar1 - это ссылка на
интерфейс IA");
}
}
}
using System;
namespace MyAClass1
{
public class CB : MyAClass1.CA,IA
{public CB()
{ }
public bool F1() { return true; }
public int F2(int a) { return a*10; }
}
interface IA { bool F1();}
}
using System;
namespace MyAClass1
{ public abstract class CA
{ public CA() { }
public abstract int F2(int a);
}
}
Листинг 16.2. (html, txt)
Вложенные классы
Язык C# позволяет создавать вложенные классы. Вложенный класс объявляется как член
другого класса.
Права доступа для вложенного класса могут быть или меньшими, или такими же, как у
содержащего его класса. Так, вложенный класс не может быть общедоступным, если
содержащий его класс объявлен как internal.
При доступе к имени вложенного класса из членов внешнего класса квалификация именем
внешнего класса не требуется.
Например:
using System;
namespace MyNClass1
{class Class1
{ static void Main(string[] args)
{Class1.Class2 var1=
new Class1.Class2(); // Эквивалентно
// записи: Class2 var1= new Class2();
//Вызов метода вложенного класса
Console.WriteLine( var1.F1());
}
class Class2
{
private int a=12345;
public int F1() {return this.a;}
}
}
}
373
Указатели можно использовать только с размерными типами, массивами и строками. При
задании указателя на массив первый элемент массива должен быть размерного типа.
Выполняющая среда .NET для эффективного управления памятью при удалении одних
объектов "перемещает" другие объекты, чтобы исключить фрагментацию памяти
свободными блоками памяти. Таким образом, выполняющая среда .NET по умолчанию не
гарантирует, что объект, на который получен указатель, всегда будет иметь один и тот же
адрес. Для предотвращения перемещения объекта следует использовать оператор fixed,
который имеет следующее формальное описание:
fixed ( тип* имя_указателя = выражение )
выполняемый_оператор_или_блок
В качестве типа можно указывать любой неуправляемый тип или void. Выражение
является указателем на заданный тип. Фиксация объекта применяется только для
указанного выполняемого оператора или блока. Доступ к фиксированной переменной не
ограничен областью видимости небезопасного кода. Поэтому фиксированная переменная
может указывать на значение, располагаемое в более широкой области видимости, чем
данная область видимости небезопасного кода. При этом компилятор C# не выдает
предупреждений о такой ситуации.
Однако компилятор C# не позволит установить указатель на управляемую переменную
вне оператора fixed.
Например:
class Point
{ public int x, y; }
class Class1
{[STAThread]
static void Main(string[] args)
{
unsafe
{
Point pt = new Point();
// pt - это управляемая
// переменная
fixed ( int* p = &pt.x ) { *p = 1 }
// pt.x // указывает на значение
// размерного типа
}
} }
Одним оператором fixed можно фиксировать несколько указателей, но только в том
случае, если они одного типа.
Например:
fixed (byte* pa1 = array1, pa2 = array2) {...}
В том случае, если требуется зафиксировать указатели различных типов, можно
использовать вложенные операторы fixed.
Например:
fixed (int* p1 = &p.x)
374
fixed (double* p2 = &array1[5]) {
}
Указатели активно используются в машинных кодах и языке ассемблера (практически, на
указателях построено все низкоуровневое программирование) и естественно, указатели
перешли по наследству в язык С и С++, но оказалось, что работа с указателями легко
приводит к ошибкам с очень тяжелыми последствиями (Эти ошибки очень сложно
обнаружить и они могут вызывать неизбежное завершение приложения, его зависание и
даже зависание и завершение операционной системы).
Поэтому при развитии высокоуровневых языков программирования от указателей
старались отказываться, но полный отказ от указателей часто был невозможен из-за того,
что было необходимо обеспечить возможность работы с программами, созданные на
старой версии языка.
Кстати, основная причина появления языков Jаvа и С# в том, что в языке С++ было
создано слишком много программ с указателями и нельзя было отказаться от указателей и
главное отличие Java и C# от языков C и C++ в почти полном отказе от использовании
указателей и множественного наследования. Кроме того, что использования указателей
служит источником ошибок, использование указателей не позволяет использовать
автоматическую очистку памяти, т.е. когда объект удаляется автоматически, если на
объект не указывает ни одна ссылка.
Суть указателя: указатель это обычная переменная числового целого типа, но она хранит
адрес объекта в памяти и по этому адресу можно работать с объектами. При выделении
памяти на новый объект его адрес записывается в указатель, а когда в объект уже не
нужен, его необходимо удалить, используя указатель на объект. Причем можно не просто
работать с адресом объекта, но прибавить или отнять к адресу число и работать с
объектом по полученному адресу(Например, массив это всего лишь указатель на первый
элемент, а к остальным можно получить доступ прибавляя к адресу первого элемента
смещение элемента) .
Почему возникают проблемы с указателями? Во- первых легко можно ошибиться с
размером массива, или структуры и начать работать памятью за пределами массива, вовторых легко можно ошибиться и выделить память для уже созданного объекта или
попытаться удалить объект, который был уже удален. Это все вызовет запись или очистку
в любую область памяти, что может вызвать любые нарушения в работе программы, хотя,
как правило, вызовет недопустимое обращение к памяти.
Указатели, которые инициализированы оператором fixed, не могут быть изменены. Если
объект, на который устанавливается указатель, размещается в стеке (например,
переменная типа int), то его местоположение фиксировать не требуется.
Разместить блок памяти в стеке можно и явным образом, используя оператор stackalloc,
который имеет следующее формальное описание:
тип * имя_указателя = stackalloc тип [ выражение ];
В качестве типа может быть указан любой неуправляемый тип.
Например:
using System;
375
class Class1
{public static unsafe void Main()
{
int* a1 = stackalloc int[100];
int* p = a1;
// Указатель на первый
// элемент массива
*p++ = *p++ = 1;
for (int i=2; i<100; ++i, ++p)
*p = p[-1] + p[-2];
for (int i=0; i<10; ++i) Console.WriteLine (a1[i]);
}
}
Время жизни указателя, инициализированного с применением stackalloc, ограничено
временем выполнения метода, в котором этот указатель объявлен. Инициализировать
указатели посредством stackalloc можно только для локальных переменных.
376
20.Система доменных имен (DNS): структура пространства имен, понятия
домена, зоны, основные типы ресурсных записей. Поиск в DNS.
Организация работы серверов DNS: первичные и вторичные,
рекурсивные и нерекурсивные.
См. № 18
377
21.Средства языка UML для описания статической структуры модели
системы.
Структурные (structural) модели:

диаграммы классов (class diagrams) - для моделирования статической структуры
классов системы и связей между ними;
Центральное место в методологии ООАП занимает разработка логической модели
системы в виде диаграммы классов. Диаграмма классов отражает, в частности, различные
взаимосвязи между отдельными сущностями предметной области, такими как объекты и
подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной
диаграмме не указывается информация о временных аспектах функционирования
системы. С этой точки зрения диаграмма классов может служить дальнейшим развитием
концептуальной модели проектируемой системы
Диаграмма классов (class diagram) — диаграмма языка UML, на которой представлена
совокупность декларативных или статических элементов модели, таких как классы с
атрибутами и операциями, а также связывающие их отношения.
Диаграмма классов предназначена для представления статической структуры модели
системы в терминологии классов объектно-ориентированного программирования. При
этом диаграмма классов может содержать интерфейсы, пакеты, отношения и даже
отдельные экземпляры классификаторов, такие как объекты и связи. Когда говорят о
данной диаграмме, имеют в виду статическую структурную модель проектируемой
системы, т. е. графическое представление таких структурных взаимосвязей логической
модели системы, которые не зависят от времени.
Класс
Класс (class) — абстрактное описание множества однородных объектов, имеющих
одинаковые атрибуты, операции и отношения с объектами других классов.
Графически класс в нотации языка UML изображается в виде прямоугольника, который
дополнительно может быть разделен горизонтальными линиями на разделы или секции
(рис. 5.1). В этих секциях могут указываться имя класса, атрибуты и операции класса.
Рис. 5.1. Варианты графического изображения класса на диаграмме классов
378
На начальных этапах разработки диаграммы отдельные классы могут обозначаться
простым прямоугольником, в котором должно быть указано имя соответствующего класса
(рис. 5.1, а). По мере проработки отдельных компонентов диаграммы описание классов
дополняется атрибутами (рис. 5.1, б) и операциями (рис. 5.1, в). Четвертая секция (рис. 5.1,
г) не обязательна и служит для размещения дополнительной информации справочного
характера, например, об исключениях или ограничениях класса, сведения о разработчике
или языке реализации. Предполагается, что окончательный вариант диаграммы содержит
наиболее полное описание классов, которые состоят из трех или четырех секций.
Даже если секции атрибутов и операций пусты, в обозначении класса они должны быть
выделены горизонтальной линией, с тем чтобы отличить класс от других элементов языка
UML. Примеры графического изображения конкретных классов приведены на рис. 5.2. В
первом случае для класса Окружность (рис. 5.2, а) указаны только его атрибуты – точка на
координатной плоскости, которая определяет расположение ее центра. Для класса Окно
(рис. 5.2, б) указаны только его операции, при этом секция его атрибутов оставлена
пустой. Для класса Счет (рис. 5.2, в) дополнительно изображена четвертая секция, в
которой указано требование – реализовать резервное копирование объектов этого класса.
Рис. 5.2. Примеры графического изображения конкретных классов
Имя класса
Имя класса должно быть уникальным в пределах пакета, который может содержать одну
или несколько диаграмм классов. Имя указывается в самой верхней секции
прямоугольника, поэтому она часто называется секцией имени класса. В дополнение к
общему правилу именования элементов языка UML, имя класса записывается по центру
секции имени полужирным шрифтом и должно начинаться с заглавной буквы.
Рекомендуется в качестве имен классов использовать существительные, записанные по
практическим соображениям без пробелов. Необходимо помнить, что имена классов
образуют словарь предметной области при ООАП.
В секции имени класса могут также находиться стереотипы или ссылки на стандартные
шаблоны, от которых образован данный класс и, соответственно, от которых он наследует
атрибуты и операции. В этой секции может также приводиться информация о
разработчике данного класса и статус состояния разработки. Здесь также могут
записываться и другие общие свойства этого класса, имеющие отношение к другим
классам диаграммы или стандартным элементам языка UML.
Класс может иметь или не иметь экземпляров или объектов. В зависимости от этого в
языке UML различают конкретные и абстрактные классы.
379
Конкретный класс (concrete class) — класс, на основе которого могут быть
непосредственно созданы экземпляры или объекты.
Рассмотренные выше обозначения относятся к конкретным классам. От них следует
отличать абстрактные классы.
Абстрактный класс (abstract class) — класс, который не имеет экземпляров или объектов.
Для обозначения имени абстрактного класса используется наклонный шрифт (курсив). В
языке UML принято общее соглашение о том, что любой текст, относящийся к
абстрактному элементу, записывается курсивом. Это имеет принципиальное значение,
поскольку является семантическим аспектом описания абстрактных элементов языка
UML.
В некоторых случаях необходимо явно указать, к какому пакету относится тот или иной
класс. Для этой цели используется специальный символ разделитель – двойное двоеточие
- (::). Синтаксис строки имени класса в этом случае будет следующий: <Имя
пакета>::<Имя класса>. Другими словами, перед именем класса должно быть явно указано
имя пакета, к которому его следует отнести. Например, если определен пакет с именем
Банк, то класс Счет в этом банке может быть записан в виде: Банк::Счет.
Атрибуты класса
Атрибут (attribute) — содержательная характеристика класса, описывающая множество
значений, которые могут принимать отдельные объекты этого класса.
Атрибут класса служит для представления отдельного свойства или признака, который
является общим для всех объектов данного класса. Атрибуты класса записываются во
второй сверху секции прямоугольника класса. Эту секцию часто называют секцией
атрибутов.
В языке UML принята определенная стандартизация записи атрибутов класса, которая
подчиняется некоторым синтаксическим правилам. Каждому атрибуту класса
соответствует отдельная строка текста, которая состоит из квантора видимости атрибута,
имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного
значения. Общий формат записи отдельного атрибута класса следующий:
<квантор видимости> <имя атрибута> [кратность] :
<тип атрибута> = <исходное значение> {строка-свойство}.
Видимость (visibility) — качественная характеристика описания элементов класса,
характеризующая потенциальную возможность других объектов модели оказывать
влияние на отдельные аспекты поведения данного класса.
Видимость в языке UML специфицируется с помощью квантора видимости (visibility),
который может принимать одно из 4-х возможных значений и отображаться при помощи
специальных символов.

Символ "+" – обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с
этой областью видимости доступен или виден из любого другого класса пакета, в котором
определена диаграмма.
380

Символ "#" – обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с
этой областью видимости недоступен или невиден для всех классов, за исключением подклассов
данного класса.

Символ "-" – обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой
областью видимости недоступен или невиден для всех классов без исключения.

И, наконец, символ "~" - обозначает атрибут с областью видимости типа пакетный (package).
Атрибут с этой областью видимости недоступен или невиден для всех классов за пределами пакета,
в котором определен класс-владелец данного атрибута.
Квантор видимости может быть опущен. Его отсутствие означает, что видимость атрибута
не указывается. Эта ситуация отличается от принятых по умолчанию соглашений в
традиционных языках программирования, когда отсутствие квантора видимости
трактуется как public или private. Однако вместо условных графических обозначений
можно записывать соответствующее ключевое слово: public, protected, private, package.
Имя атрибута представляет собой строку текста, которая используется в качестве
идентификатора соответствующего атрибута и поэтому должна быть уникальной в
пределах данного класса. Имя атрибута - единственный обязательный элемент
синтаксического обозначения атрибута, должно начинаться со строчной (малой) буквы и
не должно содержать пробелов.
Кратность (multiplicity) — спецификация области значений допустимой мощности,
которой могут обладать соответствующие множества.
Кратность атрибута характеризует общее количество конкретных атрибутов данного типа,
входящих в состав отдельного класса. В общем случае кратность записывается в форме
строки текста из цифр в квадратных скобках после имени соответствующего атрибута,
при этом цифры разделяются двумя точками: [нижняя граница .. верхняя граница], где
нижняя и верхняя границы положительные целые числа. Каждая такая пара служит для
обозначения отдельного замкнутого интервала целых чисел, у которого нижняя (верхняя)
граница равна значению нижняя граница (верхняя). В качестве верхней границы может
использоваться специальный символ "*" (звездочка), который означает произвольное
положительное целое число, т.е. неограниченное сверху значение кратности
соответствующего атрибута.
Интервалов кратности для отдельного атрибута может быть несколько. В этом случае их
совместное использование соответствует теоретико-множественному объединению
соответствующих интервалов. Значения кратности из интервала следуют в монотонно
возрастающем порядке без пропуска отдельных чисел, лежащих между нижней и верхней
границами. При этом придерживаются следующего правила: соответствующие нижние и
верхние границы интервалов включаются в значение кратности.
Если в качестве кратности указывается единственное число, то кратность атрибута
принимается равной данному числу. Если же указывается единственный знак "*", то это
означает, что кратность атрибута может быть произвольным положительным целым
числом или нулем. В языке UML кратность широко используется также для задания ролей
ассоциаций, составных объектов и значений атрибутов. Если кратность атрибута не
указана, то по умолчанию в языке UML принимается ее значение равное [1..1], т. е. в
точности 1.
381
Тип атрибута представляет собой выражение, семантика которого определяется
некоторым типом данных, определенным в пакете Типы данных языка UML или самим
разработчиком. В нотации UML тип атрибута иногда определяется в зависимости от языка
программирования, который предполагается использовать для реализации данной модели.
В простейшем случае тип атрибута указывается строкой текста, имеющей осмысленное
значение в пределах пакета или модели, к которым относится рассматриваемый класс.
Исходное значение служит для задания начального значения соответствующего атрибута
в момент создания отдельного экземпляра класса. Здесь необходимо придерживаться
правила принадлежности значения типу конкретного атрибута. Если исходное значение не
указано, то значение соответствующего атрибута не определено на момент создания
нового экземпляра класса. С другой стороны, конструктор объекта может переопределять
исходное значение в процессе выполнения программы, если в этом возникает
необходимость.
При задании атрибутов могут быть использованы дополнительные синтаксические
конструкции — это подчеркивание строки атрибута, пояснительный текст в фигурных
скобках и косая черта перед именем атрибута. Подчеркивание строки атрибута означает,
что соответствующий атрибут общий для всех объектов данного класса, т.е. его значение
у всех создаваемых объектов одинаковое (аналог ключевого слова static в некоторых
языках программирования).
Пояснительный текст в фигурных скобках может означать две различные конструкции.
Если в этой строке имеется знак равенства, то вся запись Строка-свойство служит для
указания дополнительных свойств атрибута, которые могут характеризовать особенности
изменения значений атрибута в ходе выполнения программы. Фигурные скобки как раз и
обозначают фиксированное значение соответствующего атрибута для класса в целом,
которое должны принимать все вновь создаваемые экземпляры класса без исключения.
Это значение принимается за исходное значение атрибута, которое не может быть
переопределено в последующем. Отсутствие строки-свойства по умолчанию трактуется
так, что значение соответствующего атрибута может быть изменено в программе.
Знак "/" перед именем атрибута указывает на то, что данный атрибут является
производным от некоторого другого атрибута этого же класса.
Производный атрибут (derived element) — атрибут класса, значение которого для
отдельных объектов может быть вычислено посредством значений других атрибутов этого
же объекта.
Операции класса
Операция (operation) - это сервис, предоставляемый каждым экземпляром или объектом
класса по требованию своих клиентов, в качестве которых могут выступать другие
объекты, в том числе и экземпляры данного класса.
Операции класса записываются в третьей сверху секции прямоугольника класса, которую
часто называют секцией операций. Совокупность операций характеризует
функциональный аспект поведения всех объектов данного класса. Запись операций класса
в языке UML также стандартизована и подчиняется определенным синтаксическим
382
правилам. При этом каждой операции класса соответствует отдельная строка, которая
состоит из квантора видимости операции, имени операции, выражения типа
возвращаемого операцией значения и, возможно, строка-свойство данной операции.
Общий формат записи отдельной операции класса следующий:
<квантор видимости> <имя операции>(
список параметров):
<выражение типа возвращаемого значения>
{строка-свойство}
Квантор видимости, как и в случае атрибутов класса, может принимать одно из четырех
возможных значений и, соответственно, отображается при помощи специального символа
либо ключевого слова. Символ "+" обозначает операцию с областью видимости типа
общедоступный (public). Символ "#" обозначает операцию с областью видимости типа
защищенный (protected). Символ "-" используется для обозначения операции с областью
видимости типа закрытый (private). И, наконец, символ "~" используется для обозначения
операции с областью видимости типа пакетный (package).
Квантор видимости для операции может быть опущен. В этом случае его отсутствие
просто означает, что видимость операции не указывается. Вместо условных графических
обозначений также можно записывать соответствующее ключевое слово: public, protected,
private, package.
Имя операции представляет собой строку текста, которая используется в качестве
идентификатора соответствующей операции и поэтому должна быть уникальной в
пределах данного класса. Имя операции - единственный обязательный элемент
синтаксического обозначения операции, должно начинаться со строчной (малой) буквы, и,
как правило, записываться без пробелов.
Список параметров является перечнем разделенных запятой формальных параметров,
каждый из которых, в свою очередь, может быть представлен в следующем виде:
<направление параметра> <имя параметра>:
<выражение типа> =
<значение параметра по умолчанию>.
Параметр (parameter) — спецификация переменной операции, которая может быть
изменена, передана или возвращена.
Параметр может включать имя, тип, направление и значение по умолчанию. Направление
параметра — есть одно из ключевых слов in, out или inout со значением in по умолчанию,
в случае если вид параметра не указывается. Имя параметра есть идентификатор
соответствующего формального параметра, при записи которого следуют правилам
задания имен атрибутов. Выражение типа является спецификацией типа данных для
допустимых значений соответствующего формального параметра. Наконец, значение по
умолчанию в общем случае представляет собой некоторое конкретное значение для этого
формального параметра.
Выражение типа возвращаемого значения также указывает на тип данных значения,
которое возвращается объектом после выполнения соответствующей операции. Две точки
и выражение типа возвращаемого значения могут быть опущены, если операция не
возвращает никакого значения. Для указания нескольких возвращаемых значений данный
383
элемент спецификации операции может быть записан в виде списка отдельных
выражений.
Операция с областью действия на весь класс показывается подчеркиванием имени и
строки выражения типа. В этом случае под областью действия операции понимаются все
объекты этого класса. В этом случае вся строка записи операции подчеркивается.
Строка-свойство служит для указания значений свойств, которые могут быть применены к
данной операции. Строка-свойство может отсутствовать, если свойства не
специфицированы.
Список формальных параметров и тип возвращаемого значения не обязателен. Квантор
видимости атрибутов и операций может быть указан в виде специального значка или
символа, которые используются для графического представления моделей в
инструментальном средстве. Еще раз следует напомнить, что имена операций, так же как
атрибутов и параметров, записываются со строчной (малой) буквы, а их типы параметров
— с заглавной (большой) буквы. При этом обязательной частью строки записи операции
является наличие имени операции и круглых скобок.
Расширение языка UML для построения моделей программного
обеспечения и бизнес-систем
Одним из несомненных достоинств языка UML является наличие механизмов
расширения, которые позволяют ввести в рассмотрение дополнительные графические
обозначения, ориентированные для решения задач из определенной предметной области.
Язык UML содержит два специальных расширения: профиль для процесса разработки
программного обеспечения (The UML Profile for Software Development Processes) и
профиль для бизнес-моделирования (The UML Profile for Business Modeling).
В рамках первого из них предложено три специальных графических примитива, которые
могут быть использованы для уточнения семантики отдельных классов при построении
различных диаграмм:

Управляющий класс (control class) — класс, отвечающий за координацию действий других классов.
На каждой диаграмме классов должен быть хотя бы один управляющий класс, причем количество
посылаемых объектам управляющего класса сообщений мало, по сравнению с числом рассылаемых
ими. Управляющий класс отвечает за координацию действий других классов. У каждой диаграммы
классов должен быть хотя бы один управляющий класс, контролирующий последовательность
выполнения действий этого варианта использования. Как правило, данный класс является активным
и инициирует рассылку множества сообщений другим классам модели. Кроме специального
обозначения управляющий класс может быть изображен в форме прямоугольника класса со
стереотипом <<control>> (рис. 5.3, а).

Класс-сущность (entity class) — пассивный класс, информация о котором должна храниться
постоянно и не уничтожаться с выключением системы. Класс-сущность содержит информацию,
которая должна храниться постоянно и не уничтожается с уничтожением объектов данного класса
или прекращением работы моделируемой системы, связанные с выключением системы или
завершением программы. Как правило, этот класс соответствует отдельной таблице базы данных. В
этом случае его атрибуты являются полями таблицы, а операции – присоединенными или
хранимыми процедурами. Этот класс пассивный и лишь принимает сообщения от других классов
модели. Класс-сущность может быть изображен также стандартным образом в форме
прямоугольника класса со стереотипом <<entity>> (рис. 5.3, б).
384

Граничный класс (boundary class) — класс, который располагается на границе системы с внешней
средой и непосредственно взаимодействует с актерами, но является составной частью системы.
Граничный класс может быть изображен также стандартным образом в форме прямоугольника
класса со стереотипом <<boundary>> (рис. 5.3, в).
Рис. 5.3. Графическое изображение классов для моделирования программного обеспечения
В рамках второго профиля также предложено три специальных графических примитива,
которые могут быть использованы для уточнения семантики отдельных классов при
построении моделей бизнес-систем:

Сотрудник (business worker) — класс, служащий на диаграмме классов для представления любого
сотрудника, который является элементом бизнес-системы и взаимодействует с другими
сотрудниками при реализации бизнес-процесса. Этот класс также может быть изображен в форме
прямоугольника класса со стереотипом <<worker>> или <<internalWorker>> (рис. 5.4, а).

Сотрудник для связи с окружением (caseworker) – класс, служащий для представления в бизнессистеме такого сотрудника, который, являясь элементом бизнес-системы, непосредственно
взаимодействует с актерами (бизнес-актерами) при реализации бизнес-процесса. Этот класс также
может быть изображен в форме прямоугольника класса со стереотипом <<caseWorker>> (рис. 5.4,
б).

Бизнес-сущность (business entity) — специальный случай класса-сущности, который также не
инициирует никаких сообщений. Этот класс служит для сохранения информации о результатах
выполнения бизнес-процесса в моделируемой бизнес-системе или организации. Этот класс также
может быть изображен в форме прямоугольника класса со стереотипом <<business entity>> (рис. 5.4,
в).
Рис. 5.4. Графическое изображение классов для моделирования бизнес-систем
385
Интерфейс
Интерфейс (interface) — именованное множество операций, которые характеризуют
поведение отдельного элемента модели.
Интерфейс в контексте языка UML является специальным случаем класса, у которого
имеются операции, но отсутствуют атрибуты. Для обозначения интерфейса используется
специальный графический символ окружность или стандартный способ – прямоугольник
класса со стереотипом <<interface>> (рис. 5.5).
На диаграмме вариантов использования интерфейс изображается в виде маленького круга,
рядом с которым записывается его имя (рис. 5.5, а). В качестве имени может
использоваться существительное, которое характеризует соответствующую информацию
или сервис, например, "Датчик температуры", "Форма ввода", "Сирена", "Видеокамера"
(рис. 5.5, б). С учетом языка реализации модели имя интерфейса, как и имена других
классов, рекомендуется записывать на английском и начинать с заглавной буквы I,
например, ITemperatureSensor, IsecureInformation (рис. 5.5, в).
Рис. 5.5. Примеры графического изображения интерфейсов на диаграммах классов
Интерфейсы на диаграмме служат для спецификации таких элементов модели, которые
видимы извне, но их внутренняя структура остается скрытой от клиентов. Интерфейсы не
могут содержать ни атрибутов, ни состояний, ни направленных ассоциаций. Они содержат
только операции без указания особенностей их реализации. Формально интерфейс не
только отделяет спецификацию операций системы от их реализации, но и определяет
общие границы проектируемой системы. В последующем интерфейс может быть уточнен
явным указанием тех операций, которые специфицируют отдельный аспект поведения
системы. Графическое изображение интерфейсов в форме окружности могут
использоваться и на других типах канонических диаграмм, например, диаграммах
компонентов и развертывания.

диаграммы компонентов (component diagrams) - для моделирования иерархии
компонентов (подсистем) системы;
386
Диаграмма компонентов и особенности ее построения
Все рассмотренные ранее диаграммы отражали концептуальные и логические аспекты
построения модели системы. Особенность логического представления заключается в том,
что оно оперирует понятиями, которые не имеют материального воплощения. Другими
словами, различные элементы логического представления, такие как классы, ассоциации,
состояния, сообщения, не существуют материально или физически. Они лишь отражают
понимание статической структуры той или иной системы или динамические аспекты ее
поведения.
Для создания конкретной физической системы необходимо реализовать все элементы
логического представления в конкретные материальные сущности. Для описания таких
реальных сущностей предназначен другой аспект модельного представления, а именно –
физическое представление модели. В контексте языка UML это означает совокупность
связанных физических сущностей, включая программное и аппаратное обеспечение, а
также персонал, которые организованы для выполнения специальных задач.
Физическая система (physical system) — реально существующий прототип модели
системы.
С тем чтобы пояснить отличие логического и физического представлений, необходимо в
общих чертах рассмотреть процесс разработки программной системы. Ее исходным
логическим представлением могут служить структурные схемы алгоритмов и процедур,
описания интерфейсов и концептуальные схемы баз данных. Однако для реализации этой
системы необходимо разработать исходный текст программы на языке программирования.
При этом уже в тексте программы предполагается организация программного кода,
определяемая синтаксисом языка программирования и предполагающая разбиение
исходного кода на отдельные модули.
Однако исходные тексты программы еще не являются окончательной реализацией
проекта, хотя и служат фрагментом его физического представления. Программная система
может считаться реализованной в том случае, когда она будет способна выполнять
функции своего целевого предназначения. А это возможно, только если программный код
системы будет реализован в форме исполняемых модулей, библиотек классов и процедур,
стандартных графических интерфейсов, файлов баз данных. Именно эти компоненты
являются базовыми элементами физического представления системы в нотации языка
UML.
Полный проект программной системы представляет собой совокупность моделей
логического и физического представлений, которые должны быть согласованы между
собой. В языке UML для физического представления моделей систем используются так
называемые диаграммы реализации, которые включают в себя две отдельные
канонические диаграммы: диаграмму компонентов и диаграмму развертывания.
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает
особенности физического представления системы. Диаграмма компонентов позволяет
определить архитектуру разрабатываемой системы, установив зависимости между
программными компонентами, в роли которых может выступать исходный, бинарный и
исполняемый код. Во многих средах разработки модуль или компонент соответствует
файлу. Пунктирные стрелки, соединяющие модули, показывают отношения
387
взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных
текстов программ. Основными графическими элементами диаграммы компонентов
являются компоненты, интерфейсы и зависимости между ними.
В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы,
так и программисты. Диаграмма компонентов обеспечивает согласованный переход от
логического представления к конкретной реализации проекта в форме программного кода.
Одни компоненты могут существовать только на этапе компиляции программного кода,
другие – на этапе его исполнения. Диаграмма компонентов отражает общие зависимости
между компонентами, рассматривая последние в качестве отношений между ними.
Компоненты
Для представления физических сущностей в языке UML применяется специальный
термин – компонент.
Компонент (component) — физически существующая часть системы, которая
обеспечивает реализацию классов и отношений, а также функционального поведения
моделируемой программной системы.
Компонент предназначен для представления физической организации ассоциированных с
ним элементов модели. Дополнительно компонент может иметь текстовый стереотип и
помеченные значения, а некоторые компоненты – собственное графическое
представление. Компонентом может быть исполняемый код отдельного модуля,
командные файлы или файлы, содержащие интерпретируемые скрипты.
Компонент служит для общего обозначения элементов физического представления
модели и может реализовывать некоторый набор интерфейсов. Для графического
представления компонента используется специальный символ – прямоугольник со
вставленными слева двумя более мелкими прямоугольниками (рис. 12.1). Внутри
объемлющего прямоугольника записывается имя компонента и, возможно,
дополнительная информация. Этот символ является базовым обозначением компонента в
языке UML.
Рис. 12.1. Графическое изображение компонента
Графическое изображение компонента ведет свое происхождение от обозначения модуля
программы, применявшегося некоторое время для отображения особенностей
инкапсуляции данных и процедур.
Модуль (module) — часть программной системы, требующая памяти для своего хранения
и процессора для исполнения.
388
В этом случае верхний маленький прямоугольник концептуально ассоциировался с
данными, которые реализует этот компонент (иногда он изображается в форме овала).
Нижний маленький прямоугольник ассоциировался с операциями или методами,
реализуемыми компонентом. В простых случаях имена данных и методов записывались
явно в маленьких прямоугольниках, однако в языке UML они не указываются.
Имя компонента подчиняется общим правилам именования элементов модели в языке
UML и может состоять из любого числа букв, цифр и знаков препинания. Отдельный
компонент может быть представлен на уровне типа или экземпляра. И хотя его
графическое изображение в обоих случаях одинаково, правила записи имени компонента
несколько отличаются.
Если компонент представляется на уровне типа, то записывается только имя типа с
заглавной буквы в форме: <Имя типа>. Если же компонент представляется на уровне
экземпляра, то его имя записывается в форме: <имя компонента ‘:' Имя типа>. При этом
вся строка имени подчеркивается. Так, в первом случае (рис. 12.1, а) для компонента
уровня типов указывается имя типа, а во втором (рис. 12.1, б) для компонента уровня
экземпляра – собственное имя компонента и имя типа.
Правила именования объектов в языке UML требуют подчеркивания имени отдельных
экземпляров, но применительно к компонентам подчеркивание их имени часто опускают.
В этом случае запись имени компонента со строчной буквы характеризует компонент
уровня примеров.
В качестве собственных имен компонентов принято использовать имена исполняемых
файлов, динамических библиотек, Web-страниц, текстовых файлов или файлов справки,
файлов баз данных или файлов с исходными текстами программ, файлов скриптов и
другие.
В отдельных случаях к простому имени компонента может быть добавлена информация
об имени объемлющего пакета и о конкретной версии реализации данного компонента.
Необходимо заметить, что в этом случае номер версии записывается как помеченное
значение в фигурных скобках. В других случаях символ компонента может быть разделен
на секции, чтобы явно указать имена реализованных в нем классов или интерфейсов.
Такое обозначение компонента называется расширенным .
Поскольку компонент как элемент модели может иметь различную физическую
реализацию, иногда его изображают в форме специального графического символа,
иллюстрирующего конкретные особенности реализации. Строго говоря, эти
дополнительные обозначения не специфицированы в нотации языка UML. Однако,
удовлетворяя общим механизмам расширения языка UML, они упрощают понимание
диаграммы компонентов, существенно повышая наглядность графического
представления.
Для более наглядного изображения компонентов были предложены и стали
общепринятыми следующие графические стереотипы:

Во-первых, стереотипы для компонентов развертывания, которые обеспечивают непосредственное
выполнение системой своих функций. Такими компонентами могут быть динамически
389
подключаемые библиотеки (рис. 12.2, а), Web-страницы на языке разметки гипертекста (рис. 12.2, б)
и файлы справки (рис. 12.2, в).

Во-вторых, стереотипы для компонентов в форме рабочих продуктов. Как правило – это файлы с
исходными текстами программ (рис. 12.2, г).
Рис. 12.2. Варианты графического изображения компонентов на диаграмме компонентов.
Эти элементы иногда называют артефактами , подчеркивая при этом их законченное
информационное содержание, зависящее от конкретной технологии реализации
соответствующих компонентов. Более того, разработчики могут для этой цели
использовать самостоятельные обозначения, поскольку в языке UML нет строгой нотации
для графического представления артефактов.
Другой способ спецификации различных видов компонентов — указание текстового
стереотипа компонента перед его именем. В языке UML для компонентов определены
следующие стереотипы:

<<file>> (файл) – определяет наиболее общую разновидность компонента, который представляется
в виде произвольного физического файла.

<<executable>> (исполнимый) – определяет разновидность компонента-файла, который является
исполнимым файлом и может выполняться на компьютерной платформе.

<<document>> (документ) – определяет разновидность компонента-файла, который представляется
в форме документа произвольного содержания, не являющегося исполнимым файлом или файлом с
исходным текстом программы.

<<library>> (библиотека) – определяет разновидность компонента-файла, который представляется в
форме динамической или статической библиотеки.

<<source>> (источник) – определяет разновидность компонента-файла, представляющего собой
файл с исходным текстом программы, который после компиляции может быть преобразован в
исполнимый файл.

<<table>> (таблица) – определяет разновидность компонента, который представляется в форме
таблицы базы данных.
Отдельными разработчиками предлагались собственные графические стереотипы для
изображения тех или иных типов компонентов, однако, за небольшим исключением они
не нашли широкого применения. В свою очередь ряд инструментальных CASE-средств
также содержат дополнительный набор графических стереотипов для обозначения
компонентов.
390
Интерфейсы
Следующим графическим элементом диаграммы компонентов являются интерфейсы. В
общем случае интерфейс графически изображается окружностью, которая соединяется с
компонентом отрезком линии без стрелок (рис. 12.3, а). При этом имя интерфейса, которое
рекомендуется начинать с заглавной буквы "I", записывается рядом с окружностью.
Семантически линия означает реализацию интерфейса, а наличие интерфейсов у
компонента означает, что данный компонент реализует соответствующий набор
интерфейсов .
Рис. 12.3. Графическое изображение интерфейсов на диаграмме компонентов.
Кроме того, интерфейс на диаграмме компонентов может быть изображен в виде
прямоугольника класса со стереотипом << interface>> и секцией поддерживаемых
операций (рис. 12.3, б). Как правило, этот вариант обозначения используется для
представления внутренней структуры интерфейса.
При разработке программных систем интерфейсы обеспечивают не только совместимость
различных версий, но и возможность вносить существенные изменения в одни части
программы, не изменяя другие . Характер применения интерфейсов отдельными
компонентами может отличаться.
Различают два способа связи интерфейса и компонента. Если компонент реализует
некоторый интерфейс, то такой интерфейс называют экспортируемым или
поддерживаемым, поскольку этот компонент предоставляет его в качестве сервиса
другим компонентам. Если же компонент использует некоторый интерфейс, который
реализуется другим компонентом, то такой интерфейс для первого компонента называется
импортируемым. Особенность импортируемого интерфейса состоит в том, что на
диаграмме компонентов это отношение изображается с помощью зависимости.
Зависимости между компонентами
В общем случае отношение зависимости также было рассмотрено ранее. Отношение
зависимости служит для представления факта наличия специальной формы связи между
двумя элементами модели, когда изменение одного элемента модели оказывает влияние
или приводит к изменению другого элемента модели. Отношение зависимости на
диаграмме компонентов изображается пунктирной линией со стрелкой, направленной от
клиента или зависимого элемента к источнику или независимому элементу модели.
Зависимости могут отражать связи отдельных файлов программной системы на этапе
компиляции и генерации объектного кода. В других случаях зависимость может указывать
на наличие в независимом компоненте описаний классов, которые используются в
зависимом компоненте для создания соответствующих объектов. Применительно к
391
диаграмме компонентов зависимости могут связывать компоненты и импортируемые этим
компонентом интерфейсы, а также различные виды компонентов между собой.
В этом случае рисуют стрелку от компонента-клиента к импортируемому интерфейсу
(рис. 12.4). Наличие такой стрелки означает, что компонент не реализует
соответствующий интерфейс, а использует его в процессе своего выполнения. При этом на
этой же диаграмме может присутствовать и другой компонент, который реализует этот
интерфейс. Отношение реализации интерфейса обозначается на диаграмме компонентов
обычной линией без стрелки.
Так, например, изображенный ниже фрагмент диаграммы компонентов представляет
информацию о том, что компонент с именем Control зависит от импортируемого
интерфейса IDialog, который, в свою очередь, реализуется компонентом с именем
DataBase . При этом для второго компонентa этот интерфейс является экспортируемым.
Изобразить связь второго компонентa DataBase с этим интерфейсом в форме зависимости
нельзя , поскольку этот компонент реализует указанный интерфейс.
Рис. 12.4.
Другим случаем отношения зависимости на диаграмме компонентов является отношение
программного вызова и компиляции между различными видами компонентов. Для
рассмотренного фрагмента диаграммы компонентов (рис. 12.5) наличие подобной
зависимости означает, что исполнимый компонент Control .exe использует или
импортирует некоторую функциональность компонентa Library .dll, вызывает страницу
гипертекста Home .html и файл помощи Search .hlp, а исходный текст этого исполнимого
компонентa хранится в файле Control .cpp. При этом характер отдельных видов
зависимостей может быть отмечен дополнительно с помощью текстовых стереотипов.
392
Рис. 12.5. Графическое изображение отношения зависимости между компонентами.
На диаграмме компонентов могут быть также представлены отношения зависимости
между компонентами и реализованными в них классами. Эта информация имеет значение
для обеспечения согласования логического и физического представлений модели системы.
Разумеется, изменения в структуре описаний классов могут привести к изменению этой
зависимости. Ниже приводится фрагмент зависимости подобного рода, когда исполнимый
компонент Control .exe зависит от соответствующих классов (рис. 12.6).
Рис. 12.6. Графическое изображение зависимости между компонентом и классами.
В этом случае из диаграммы компонентов не следует, что классы реализованы данным
компонентом. Если требуется подчеркнуть, что некоторый компонент реализует
отдельные классы, то для обозначения компонентa используется расширенный символ
прямоугольника. При этом прямоугольник компонентa делится на две секции
горизонтальной линией. Верхняя секция служит для записи имени компонентa и,
возможно, дополнительной информации, а нижняя секция – для указания реализуемых
данным компонентом классов (рис. 12.7).
393
Рис. 12.7. Графическое изображение компонентa с информацией о реализуемых им классах.
В случае если компонент является экземпляром и реализует три отдельных объекта, он
изображается в форме компонентa уровня экземпляров (рис. 12.8). Объекты, которые
находятся в отдельном компоненте-экземпляре, изображаются вложенными в символ
данного компонента. Подобная вложенность означает, что выполнение компонентa влечет
за собой выполнение операций соответствующих объектов. При этом существование
компонентa в течение времени исполнения программы обеспечивает функциональность
всех вложенных в него объектов. Что касается доступа к этим объектам, то он может быть
дополнительно специфицирован с помощью видимости, подобно видимости пакетов.
Рис. 12.8. Графическое изображение компонента-экземпляра, реализующего отдельные объекты.
Для компонентов с исходным текстом программы видимость может означать возможность
внесения изменений в соответствующие тексты программ с их последующей
перекомпиляцией. Для компонентов с исполняемым кодом программы видимость может
характеризовать возможность запуска на исполнение соответствующего компонентa или
вызова реализованных в нем операций или методов.
Рекомендации по построению диаграммы компонентов
Разработка диаграммы компонентов предполагает использование информации не только о
логическом представлении модели системы, но и об особенностях ее физической
реализации. В первую очередь, необходимо решить, из каких физических частей или
файлов будет состоять программная система. На этом этапе следует обратить внимание на
такую реализацию системы, которая обеспечивала бы возможность повторного
использования кода за счет рациональной декомпозиции компонентов, а также создание
объектов только при их необходимости.
394
Общая производительность программной системы существенно зависит от рационального
использования вычислительных ресурсов. Для этой цели необходимо большую часть
описаний классов, их операций и методов вынести в динамические библиотеки, оставив в
исполняемых компонентах только самые необходимые для инициализации программы
фрагменты программного кода.
После общей структуризации физического представления системы необходимо дополнить
модель интерфейсами и схемами базы данных. При разработке интерфейсов следует
обращать внимание на согласование различных частей программной системы. Включение
в модель схемы базы данных предполагает спецификацию отдельных таблиц и
установление информационных связей между ними.
Завершающий этап построения диаграммы компонентов связан с установлением и
нанесением на диаграмму взаимосвязей между компонентами, а также отношений
реализации. Эти отношения должны иллюстрировать все важнейшие аспекты физической
реализации системы, начиная с особенностей компиляции исходных текстов программ и
заканчивая исполнением отдельных частей программы на этапе ее выполнения. Для этой
цели можно использовать различные графические стереотипы компонентов.
При разработке диаграммы компонентов следует придерживаться общих принципов
создания моделей на языке UML. В частности, в первую очередь необходимо
использовать уже имеющиеся в языке UML и общепринятые графические и текстовые
стереотипы. В большинстве типовых проектов этого набора достаточно для представления
компонентов и зависимостей между ними.
Если же проект содержит физические элементы, описание которых отсутствует в языке
UML, то следует воспользоваться механизмом расширения. В частности, можно
применить дополнительные стереотипы для отдельных нетиповых компонентов или
помеченные значения для уточнения отдельных характеристик компонентов.
Наконец, следует обратить внимание на то, что диаграмма компонентов, как правило,
разрабатывается совместно с диаграммой развертывания, на которой представляется
информация о физическом размещении компонентов программной системы по ее
отдельным узлам. Особенности построения диаграммы развертывания будут рассмотрены
в следующей лекции.

диаграммы размещения (deployment diagrams) - для моделирования физической
архитектуры системы.
Диаграмма размещения отражает физические взаимосвязи между программными и
аппаратными компонентами системы. Она является хорошим средством для того, чтобы
показать размещение объектов и компонентов в распределенной системе.
Диаграмма размещения показывает физическое расположение сети и местонахождение в
ней различных компонентов. Ее основными элементами являются узел (вычислительный
ресурс) и соединение - канал взаимодействия узлов (сеть).
395
Диаграмма размещения используется менеджером проекта, пользователями, архитектором
системы и эксплуатационным персоналом, чтобы понять физическое размещение системы
и расположение ее отдельных подсистем.
UML обладает механизмами расширения, предназначенными для того, чтобы
разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не
меняя при этом его метамодель. Наличие механизмов расширения принципиально
отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и ERM.
Перечисленные языки моделирования можно определить как сильно типизированные (по
аналогии с языками программирования), поскольку они не допускают произвольной
интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в
основном за счет стереотипов), является слабо типизированным языком. К его
механизмам расширения относятся:

стереотипы;

тегированные (именованные) значения;

ограничения.
Стереотип - это новый тип элемента модели, который определяется на основе уже
существующего элемента. Стереотипы расширяют нотацию модели и могут применяться
к любым элементам модели. Стереотипы классов - это механизм, позволяющий разделять
классы на категории. Разработчики ПО могут создавать свои собственные наборы
стереотипов, формируя тем самым специализированные подмножества UML (например,
для описания бизнес-процессов, Web-приложений, баз данных и т.д.). Такие
подмножества (наборы стереотипов) в стандарте языка UML носят название профилей
языка.
Именованное значение - это пара строк "тег = значение", или "имя = содержимое", в
которых хранится дополнительная информация о каком-либо элементе системы,
например, время создания, статус разработки или тестирования, время окончания работы
над ним и т.п.
Ограничение - это семантическое ограничение, имеющее вид текстового выражения на
естественном или формальном языке (OCL - Object Constraint Language), которое
невозможно выразить с помощью нотации UML.
396
22.Алгоритмы симметричной криптографии.
Криптография
Основные понятия
Рассмотрим общую схему симметричной, или традиционной, криптографии.
Рис. 2.1. Общая схема симметричного шифрования
В процессе шифрования используется определенный алгоритм шифрования, на вход
которому подаются исходное незашифрованное сообщение, называемое также plaintext, и
ключ. Выходом алгоритма является зашифрованное сообщение, называемое также
ciphertext. Ключ является значением, не зависящим от шифруемого сообщения. Изменение
ключа должно приводить к изменению зашифрованного сообщения.
Зашифрованное сообщение передается получателю. Получатель преобразует
зашифрованное сообщение в исходное незашифрованное сообщение с помощью
алгоритма дешифрования и того же самого ключа, который использовался при
шифровании, или ключа, легко получаемого из ключа шифрования.
Незашифрованное сообщение будем обозначать P или M, от слов plaintext и message.
Зашифрованное сообщение будем обозначать С, от слова ciphertext.
Безопасность, обеспечиваемая традиционной криптографией, зависит от нескольких
факторов.
397
Во-первых, криптографический алгоритм должен быть достаточно сильным, чтобы
передаваемое зашифрованное сообщение невозможно было расшифровать без ключа,
используя только различные статистические закономерности зашифрованного сообщения
или какие-либо другие способы его анализа.
Во-вторых, безопасность передаваемого сообщения должна зависеть от секретности
ключа, но не от секретности алгоритма. Алгоритм должен быть проанализирован
специалистами, чтобы исключить наличие слабых мест, при наличии которых плохо
скрыта взаимосвязь между незашифрованным и зашифрованным сообщениями. К тому же
при выполнении этого условия производители могут создавать дешевые аппаратные чипы
и свободно распространяемые программы, реализующие данный алгоритм шифрования.
В-третьих, алгоритм должен быть таким, чтобы нельзя было узнать ключ, даже зная
достаточно много пар (зашифрованное сообщение, незашифрованное сообщение),
полученных при шифровании с использованием данного ключа.
Клод Шеннон ввел понятия диффузии и конфузии для описания стойкости алгоритма
шифрования.
Диффузия - это рассеяние статистических особенностей незашифрованного текста в
широком диапазоне статистических особенностей зашифрованного текста. Это
достигается тем, что значение каждого элемента незашифрованного текста влияет на
значения многих элементов зашифрованного текста или, что то же самое, любой элемент
зашифрованного текста зависит от многих элементов незашифрованного текста.
Конфузия - это уничтожение статистической взаимосвязи между зашифрованным текстом
и ключом.
Если Х - это исходное сообщение и K - криптографический ключ, то зашифрованный
передаваемый текст можно записать в виде
Y = EK[X].
Получатель, используя тот же ключ, расшифровывает сообщение
X = DK[Y]
Противник, не имея доступа к K и Х , должен попытаться узнать Х, K или и то, и другое.
Алгоритмы симметричного шифрования различаются способом, которым обрабатывается
исходный текст. Возможно шифрование блоками или шифрование потоком.
Блок текста рассматривается как неотрицательное целое число, либо как несколько
независимых неотрицательных целых чисел. Длина блока всегда выбирается равной
степени двойки. В большинстве блочных алгоритмов симметричного шифрования
используются следующие типы операций:

Табличная подстановка, при которой группа битов отображается в другую группу битов. Это так
называемые S-box.

Перемещение, с помощью которого биты сообщения переупорядочиваются.

Операция сложения по модулю 2, обозначаемая XOR или .
398

Операция сложения по модулю 232 или по модулю 216.

Циклический сдвиг на некоторое число битов.
Эти операции циклически повторяются в алгоритме, образуя так называемые раунды.
Входом каждого раунда является выход предыдущего раунда и ключ, который получен по
определенному алгоритму из ключа шифрования K. Ключ раунда называется подключом.
Каждый алгоритм шифрования может быть представлен следующим образом:
Рис. 2.2. Структура алгоритма симметричного шифрования
Области применения
Стандартный алгоритм шифрования должен быть применим во многих приложениях:

Шифрование данных. Алгоритм должен быть эффективен при шифровании файлов данных или
большого потока данных.

Создание случайных чисел. Алгоритм должен быть эффективен при создании определенного
количества случайных битов.

Хэширование. Алгоритм должен эффективно преобразовываться в одностороннюю хэш-функцию.
Платформы
Стандартный алгоритм шифрования должен быть реализован на различных платформах,
которые, соответственно, предъявляют различные требования.
399

Алгоритм должен эффективно реализовываться на специализированной аппаратуре,
предназначенной для выполнения шифрования/дешифрования.

Большие процессоры. Хотя для наиболее быстрых приложений всегда используется специальная
аппаратура, программные реализации применяются чаще. Алгоритм должен допускать
эффективную программную реализацию на 32-битных процессорах.

Процессоры среднего размера. Алгоритм должен работать на микроконтроллерах и других
процессорах среднего размера.

Малые процессоры. Должна существовать возможность реализации алгоритма на смарт-картах,
пусть даже с учетом жестких ограничений на используемую память.
Дополнительные требования
Алгоритм шифрования должен, по возможности, удовлетворять некоторым
дополнительным требованиям.

Алгоритм должен быть простым для написания кода, чтобы минимизировать вероятность
программных ошибок.

Алгоритм должен иметь плоское пространство ключей и допускать любую случайную строку битов
нужной длины в качестве возможного ключа. Наличие слабых ключей нежелательно.

Алгоритм должен легко модифицироваться для различных уровней безопасности и удовлетворять
как минимальным, так и максимальным требованиям.

Все операции с данными должны осуществляться над блоками, кратными байту или 32-битному
слову.
Сеть Фейштеля
Блочный алгоритм преобразовывает n-битный блок незашифрованного текста в n-битный
блок зашифрованного текста. Число блоков длины n равно 2n. Для того чтобы
преобразование было обратимым, каждый из таких блоков должен преобразовываться в
свой уникальный блок зашифрованного текста. При маленькой длине блока такая
подстановка плохо скрывает статистические особенности незашифрованного текста. Если
блок имеет длину 64 бита, то он уже хорошо скрывает статистические особенности
исходного текста. Но в данном случае преобразование текста не может быть
произвольным в силу того, что ключом будет являться само преобразование, что
исключает эффективную как программную, так и аппаратную реализации.
Наиболее широкое распространение получили сети Фейштеля, так как, с одной стороны,
они удовлетворяют всем требованиям к алгоритмам симметричного шифрования, а с
другой стороны, достаточно просты и компактны.
Сеть Фейштеля имеет следующую структуру. Входной блок делится на несколько равной
длины подблоков, называемых ветвями. В случае, если блок имеет длину 64 бита,
используются две ветви по 32 бита каждая. Каждая ветвь обрабатывается независимо от
другой, после чего осуществляется циклический сдвиг всех ветвей влево. Такое
преобразование выполняется несколько циклов или раундов. В случае двух ветвей каждый
раунд имеет структуру, показанную на рисунке:
400
Рис. 2.3. I-ый раунд сети Фейштеля
Функция F называется образующей. Каждый раунд состоит из вычисления функции F для
одной ветви и побитового выполнения операции XOR результата F с другой ветвью.
После этого ветви меняются местами. Считается, что оптимальное число раундов - от 8 до
32. Важно то, что увеличение количества раундов значительно увеличивает
криптостойкость алгоритма. Возможно, эта особенность и повлияла на столь активное
распространение сети Фейштеля, так как для большей криптостойкости достаточно просто
увеличить количество раундов, не изменяя сам алгоритм. В последнее время количество
раундов не фиксируется, а лишь указываются допустимые пределы.
Сеть Фейштеля является обратимой даже в том случае, если функция F не является
таковой, так как для дешифрования не требуется вычислять F-1. Для дешифрования
используется тот же алгоритм, но на вход подается зашифрованный текст, и ключи
используются в обратном порядке.
В настоящее время все чаще используются различные разновидности сети Фейштеля для
128-битного блока с четырьмя ветвями. Увеличение количества ветвей, а не размерности
каждой ветви связано с тем, что наиболее популярными до сих пор остаются процессоры с
32-разрядными словами, следовательно, оперировать 32-разрядными словами
эффективнее, чем с 64-разрядными.
Основной характеристикой алгоритма, построенного на основе сети Фейштеля, является
функция F. Различные варианты касаются также начального и конечного преобразований.
Подобные преобразования, называемые забеливанием (whitening), осуществляются для
того, чтобы выполнить начальную рандомизацию входного текста.
Криптоанализ
Процесс, при котором предпринимается попытка узнать Х, K или и то, и другое,
называется криптоанализом. Одной из возможных атак на алгоритм шифрования является
лобовая атака, т.е. простой перебор всех возможных ключей. Если множество ключей
достаточно большое, то подобрать ключ нереально. При длине ключа n бит количество
возможных ключей равно 2n. Таким образом, чем длиннее ключ, тем более стойким
считается алгоритм для лобовой атаки.
401
Существуют различные типы атак, основанные на том, что противнику известно
определенное количество пар незашифрованное сообщение - зашифрованное сообщение.
При анализе зашифрованного текста противник часто применяет статистические методы
анализа текста. При этом он может иметь общее представление о типе текста, например,
английский или русский текст, выполнимый файл конкретной ОС, исходный текст на
некотором конкретном языке программирования и т.д. Во многих случаях криптоаналитик
имеет достаточно много информации об исходном тексте. Криптоаналитик может иметь
возможность перехвата одного или нескольких незашифрованных сообщений вместе с их
зашифрованным видом. Или криптоаналитик может знать основной формат или основные
характеристики сообщения. Говорят, что криптографическая схема абсолютно безопасна,
если зашифрованное сообщение не содержит никакой информации об исходном
сообщении. Говорят, что криптографическая схема вычислительно безопасна, если:
1.
Цена расшифровки сообщения больше цены самого сообщения.
2.
Время, необходимое для расшифровки сообщения, больше срока жизни сообщения.
Дифференциальный и линейный криптоанализ
Рассмотрим в общих чертах основной подход, используемый при дифференциальном и
линейном криптоанализе. И в том, и в другом случае предполагается, что известно
достаточно большое количество пар (незашифрованнный текст, зашифрованный текст).
Понятие дифференциального криптоанализа было введено Эли Бихамом (Biham) и Ади
Шамиром (Shamir) в 1990 году. Конечная задача дифференциального криптоанализа используя свойства алгоритма, в основном свойства S-box, определить подключ раунда.
Конкретный способ дифференциального криптоанализа зависит от рассматриваемого
алгоритма шифрования.
Если в основе алгоритма лежит сеть Фейштеля, то можно считать, что блок m состоит из
двух половин - m0 и m1. Дифференциальный криптоанализ рассматривает отличия,
которые происходят в каждой половине при шифровании. (Для алгоритма DES "отличия"
определяются с помощью операции XOR, для других алгоритмов возможен иной способ).
Выбирается пара незашифрованных текстов с фиксированным отличием. Затем
анализируются отличия, получившиеся после шифрования одним раундом алгоритма, и
определяются вероятности различных ключей. Если для многих пар входных значений,
имеющих одно и то же отличие Х, при использовании одного и того же подключа
одинаковыми (Y) оказываются и отличия соответствующих выходных значений, то можно
говорить, что Х влечет Y с определенной вероятностью. Если эта вероятность близка к
единице, то можно считать, что подключ раунда найден с данной вероятностью. Так как
раунды алгоритма независимы, вероятности определения подключа каждого раунда
следует перемножать. Как мы помним, считается, что результат шифрования данной пары
известен. Результаты дифференциального криптоанализа используются как при
разработке конкретных S-box, так и при определении оптимального числа раундов.
Другим способом криптоанализа является линейный криптоанализ, который использует
линейные приближения преобразований, выполняемых алгоритмом шифрования. Данный
метод позволяет найти ключ, имея достаточно большое число пар (незашифрованный
402
текст, зашифрованный текст). Рассмотрим основные принципы, на которых базируется
линейный криптоанализ. Обозначим
P[1], … , P[n] - незашифрованный блок сообщения.
C[1], … , C[n] - зашифрованный блок сообщения.
K[1], … , K[m] - ключ.
A[i, j, …, k] = A[i] A[j] … A[k]
Целью линейного криптоанализа является поиск линейного уравнения вида
P[ 1,
2,
…,
a]
C[β1, β2, …, βb ] = K[γ1, …, γc]
Выполняющееся с вероятностью р 0.5. i, βi и γi - фиксированные позиции в блоках
сообщения и ключе. Чем больше р отклоняется от 0.5, тем более подходящим считается
уравнение.
Это уравнение означает, что если выполнить операцию XOR над некоторыми битами
незашифрованного сообщения и над некоторыми битами зашифрованного сообщения,
получится бит, представляющий собой XOR некоторых битов ключа. Это называется
линейным приближением, которое может быть верным с вероятностью р.
Уравнения составляются следующим образом. Вычисляются значения левой части для
большого числа пар соответствующих фрагментов незашифрованного и зашифрованного
блоков. Если результат оказывается равен нулю более чем в половине случаев, то
полагают, что K[γ1, …, γс] = 0. Если в большинстве случаев получается 1, полагают, что
K[γ1, …, γс] = 1. Таким образом получают систему уравнений, решением которой является
ключ.
Как и в случае дифференциального криптоанализа, результаты линейного криптоанализа
должны учитываться при разработке алгоритмов симметричного шифрования.
Используемые критерии при разработке алгоритмов
Принимая во внимание перечисленные требования, обычно считается, что алгоритм
симметричного шифрования должен:

Манипулировать данными в больших блоках, предпочтительно размером 16 или 32 бита.

Иметь размер блока 64 или 128 бит.

Иметь масштабируемый ключ до 256 бит.

Использовать простые операции, которые эффективны на микропроцессорах, т.е. исключающее
или, сложение, табличные подстановки, умножение по модулю. Не должно использоваться сдвигов
переменной длины, побитных перестановок или условных переходов.

Должна быть возможность реализации алгоритма на 8-битном процессоре с минимальными
требованиями к памяти.

Использовать заранее вычисленные подключи. На системах с большим количеством памяти эти
подключи могут быть заранее вычислены для ускорения работы. В случае невозможности
заблаговременного вычисления подключей должно произойти только замедление выполнения.
403
Всегда должна быть возможность шифрования данных без каких-либо предварительных
вычислений.

Состоять из переменного числа итераций. Для приложений с маленькой длиной ключа
нецелесообразно применять большое число итераций для противостояния дифференциальным и
другим атакам. Следовательно, должна быть возможность уменьшить число итераций без потери
безопасности (не более чем уменьшенный размер ключа).

По возможности не иметь слабых ключей. Если это невозможно, то количество слабых ключей
должно быть минимальным, чтобы уменьшить вероятность случайного выбора одного из них. Тем
не менее, все слабые ключи должны быть заранее известны, чтобы их можно было отбраковать в
процессе создания ключа.

Задействовать подключи, которые являются односторонним хэшем ключа. Это дает возможность
использовать большие парольные фразы в качестве ключа без ущерба для безопасности.

Не иметь линейных структур, которые уменьшают комплексность и не обеспечивают
исчерпывающий поиск.

Использовать простую для понимания разработку. Это дает возможность анализа и уменьшает
закрытость алгоритма.
Большинство блочных алгоритмов основано на использовании сети Фейштеля, все имеют
плоское пространство ключей, с возможным исключением нескольких слабых ключей.
Алгоритм DES
Принципы разработки
Самым распространенным и наиболее известным алгоритмом симметричного
шифрования является DES (Data Encryption Standard). Алгоритм был разработан в 1977
году, в 1980 году был принят NIST (National Institute of Standards and Technology США) в
качестве стандарта (FIPS PUB 46).
DES является классической сетью Фейштеля с двумя ветвями. Данные шифруются 64битными блоками, используя 56-битный ключ. Алгоритм преобразует за несколько
раундов 64-битный вход в 64-битный выход. Длина ключа равна 56 битам. Процесс
шифрования состоит из четырех этапов. На первом из них выполняется начальная
перестановка (IP) 64-битного исходного текста (забеливание), во время которой биты
переупорядочиваются в соответствии со стандартной таблицей. Следующий этап состоит
из 16 раундов одной и той же функции, которая использует операции сдвига и
подстановки. На третьем этапе левая и правая половины выхода последней (16-й)
итерации меняются местами. Наконец, на четвертом этапе выполняется перестановка IP-1
результата, полученного на третьем этапе. Перестановка IP-1 инверсна начальной
перестановке.
404
Рис. 2.4. Общая схема DES
Справа на рисунке показан способ, которым используется 56-битный ключ.
Первоначально ключ подается на вход функции перестановки. Затем для каждого из 16
раундов подключ Ki является комбинацией левого циклического сдвига и перестановки.
Функция перестановки одна и та же для каждого раунда, но подключи Ki для каждого
раунда получаются разные вследствие повторяющегося сдвига битов ключа.
Шифрование
Начальная перестановка
Начальная перестановка и ее инверсия определяются стандартной таблицей. Если М - это
произвольные 64 бита, то X = IP (M) - переставленные 64 бита. Если применить обратную
функцию перестановки Y = IP-1 (X) = IP-1 (IP(M)), то получится первоначальная
последовательность битов.
Последовательность преобразований отдельного раунда
Теперь рассмотрим последовательность преобразований, используемую в каждом раунде.
405
Рис. 2.5. I-ый раунд DES
64-битный входной блок проходит через 16 раундов, при этом на каждой итерации
получается промежуточное 64-битное значение. Левая и правая части каждого
промежуточного значения трактуются как отдельные 32-битные значения, обозначенные
L и R. Каждую итерацию можно описать следующим образом:
Li = Ri-1
Ri = Li-1
F(Ri-1, Ki)
Где обозначает операцию XOR.
Таким образом, выход левой половины Li равен входу правой половины Ri-1. Выход
правой половины Ri является результатом применения операции XOR к Li-1 и функции F,
зависящей от Ri-1 и Ki.
Рассмотрим функцию F более подробно.
Ri, которое подается на вход функции F, имеет длину 32 бита. Вначале Ri расширяется до
48 битов, используя таблицу, которая определяет перестановку плюс расширение на 16
битов. Расширение происходит следующим образом. 32 бита разбиваются на группы по 4
бита и затем расширяются до 6 битов, присоединяя крайние биты из двух соседних групп.
Например, если часть входного сообщения
. . . efgh ijkl mnop . . .
то в результате расширения получается сообщение
406
. . . defghi hijklm lmnopq . . .
После этого для полученного 48-битного значения выполняется операция XOR с 48битным подключом Ki. Затем полученное 48-битное значение подается на вход функции
подстановки, результатом которой является 32-битное значение.
Подстановка состоит из восьми S-boxes , каждый из которых на входе получает 6 бит, а на
выходе создает 4 бита. Эти преобразования определяются специальными таблицами.
Первый и последний биты входного значения S-box определяют номер строки в таблице,
средние 4 бита определяют номер столбца. Пересечение строки и столбца определяет 4битный выход. Например, если входом является 011011, то номер строки равен 01 (строка
1) и номер столбца равен 1101 (столбец 13). Значение в строке 1 и столбце 13 равно 5, т.е.
выходом является 0101.
Далее полученное 32-битное значение обрабатывается с помощью перестановки Р, целью
которой является максимальное переупорядочивание битов, чтобы в следующем раунде
шифрования с большой вероятностью каждый бит обрабатывался другим S-box.
Создание подключей
Ключ для отдельного раунда Ki состоит из 48 битов. Ключи Ki получаются по
следующему алгоритму. Для 56-битного ключа, используемого на входе алгоритма,
вначале выполняется перестановка в соответствии с таблицей Permuted Choice 1 (РС-1).
Полученный 56-битный ключ разделяется на две 28-битные части, обозначаемые как C0 и
D0 соответственно. На каждом раунде Ci и Di независимо циклически сдвигаются влево на
1 или 2 бита, в зависимости от номера раунда. Полученные значения являются входом
следующего раунда. Они также представляют собой вход в Permuted Choice 2 (РС-2),
который создает 48-битное выходное значение, являющееся входом функции F(Ri-1, Ki).
Дешифрование
Процесс дешифрования аналогичен процессу шифрования. На входе алгоритма
используется зашифрованный текст, но ключи Ki используются в обратной
последовательности. K16 используется на первом раунде, K1 используется на последнем
раунде. Пусть выходом i-ого раунда шифрования будет Li||Ri. Тогда соответствующий
вход (16-i)-ого раунда дешифрования будет Ri||Li.
После последнего раунда процесса расшифрования две половины выхода меняются
местами так, чтобы вход заключительной перестановки IP-1 был R16||L16. Выходом этой
стадии является незашифрованный текст.
Проверим корректность процесса дешифрования. Возьмем зашифрованный текст и ключ и
используем их в качестве входа в алгоритм. На первом шаге выполним начальную
перестановку IP и получим 64-битное значение Ld0||Rd0. Известно, что IP и IP-1
взаимнообратны. Следовательно
Ld0||Rd0 = IP (зашифрованный текст)
Зашифрованный текст = IP-1(R16||L16)
Ld0||Rd0 = IP(IP-1(R16||L16)) = R16||L16
407
Таким образом, вход первого раунда процесса дешифрования эквивалентен 32-битному
выходу 16-ого раунда процесса шифрования, у которого левая и правая части записаны в
обратном порядке.
Теперь мы должны показать, что выход первого раунда процесса дешифрования
эквивалентен 32-битному входу 16-ого раунда процесса шифрования. Во-первых,
рассмотрим процесс шифрования. Мы видим,что
L16 = R15
R16 = L15
F(R15, K16)
При дешифровании:
Ld1 = Rd0 = L16 = R15
Rd1 = Ld0
= R16
F(Rd0, K16) =
F(Rd0, K16) =
= (L15
F(R15, K16))
F(R15, K16)
XOR имеет следующие свойства:
(A
B)
D
D = 0
E
0 = E
C = A
(B
C)
Таким образом, мы имеем Ld1 = R15 и Rd1 = L15. Следовательно, выход первого раунда
процесса дешифрования есть L15||R15, который является перестановкой входа 16-го раунда
шифрования. Легко показать, что данное соответствие выполняется все 16 раундов. Мы
можем описать этот процесс в общих терминах. Для i-ого раунда шифрующего алгоритма:
Li = Ri-1
Ri = Li-1
F(Ri-1, Ki)
Эти равенства можно записать по-другому:
Ri-1 = Li
Li-1 = Ri
F(Ri-1, Ki) = Ri
F(Li, Ki)
Таким образом, мы описали входы i-ого раунда как функцию выходов.
Выход последней стадии процесса дешифрования есть R0||L0. Чтобы входом IP-1 стадии
было R0||L0, необходимо поменять местами левую и правую части. Но
IP-1(R0||L0) = IP-1(IP (незашифрованный текст)) = незашифрованный текст
Т.е. получаем незашифрованный текст, что и демонстрирует возможность дешифрования
DES.
Проблемы DES
Так как длина ключа равна 56 битам, существует 256 возможных ключей. На сегодня такая
длина ключа недостаточна, поскольку допускает успешное применение лобовых атак.
Альтернативой DES можно считать тройной DES, IDEA, а также алгоритм Rijndael,
принятый в качестве нового стандарта на алгоритмы симметричного шифрования.
408
Также без ответа пока остается вопрос, возможен ли криптоанализ с использованием
существующих характеристик алгоритма DES. Основой алгоритма являются восемь
таблиц подстановки, или S-boxes, которые применяются в каждой итерации. Существует
опасность, что эти S-boxes конструировались таким образом, что криптоанализ возможен
для взломщика, который знает слабые места S-boxes. В течение многих лет обсуждалось
как стандартное, так и неожиданное поведение S-boxes, но все-таки никому не удалось
обнаружить их фатально слабые места.
Алгоритм тройной DES
В настоящее время основным недостатком DES считается маленькая длина ключа,
поэтому уже давно начали разрабатываться различные альтернативы этому алгоритму
шифрования. Один из подходов состоит в том, чтобы разработать новый алгоритм, и
успешный тому пример - IDEA. Другой подход предполагает повторное применение
шифрования с помощью DES с использованием нескольких ключей.
Недостатки двойного DES
Простейший способ увеличить длину ключа состоит в повторном применении DES с
двумя разными ключами. Используя незашифрованное сообщение P и два ключа K1 и K2,
зашифрованное сообщение С можно получить следующим образом:
C = Ek2 [Ek1 [P]]
Для дешифрования требуется, чтобы два ключа применялись в обратном порядке:
P = Dk1 [Dk2 [C]]
В этом случае длина ключа равна 56 * 2 = 112 бит.
Атака "встреча посередине"
Для приведенного выше алгоритма двойного DES существует так называемая атака
"встреча посередине". Она основана на следующем свойстве алгоритма. Мы имеем
С = Ek2 [Ek1 [P]]
Тогда
X = Ek1 [P] = Dk2 [C].
Атака состоит в следующем. Требуется, чтобы атакующий знал хотя бы одну пару
незашифрованный текст и соответствующий ему зашифрованный текст: (Р, С). В этом
случае, во-первых, шифруется Р для всех возможных 256 значений K1. Этот результат
запоминается в таблице, и затем таблица упорядочивается по значению Х. Следующий
шаг состоит в дешифровании С, с применением всех возможных 256 значений K2. Для
каждого выполненного дешифрования ищется равное ему значение в первой таблице.
Если соответствующее значение найдено, то считается, что эти ключи могут быть
правильными, и они проверяются для следующей известной пары незашифрованный
текст, зашифрованный текст.
Если известна только одна пара значений незашифрованный текст, зашифрованный текст,
то может быть получено достаточно большое число неверных значений ключей. Но если
противник имеет возможность перехватить хотя бы две пары значений (незашифрованный
409
текст - зашифрованный текст), то сложность взлома двойного DES фактически становится
равной сложности взлома обычного DES, т.е. 256.
Тройной DES с двумя ключами
Очевидное противодействие атаке "встреча посередине" состоит в использовании третьей
стадии шифрования с тремя различными ключами. Это поднимает стоимость лобовой
атаки до 2168, которая на сегодняшний день считается выше практических возможностей.
Но при этом длина ключа равна 56 * 3 = 168 бит, что иногда бывает громоздко.
В качестве альтернативы предлагается метод тройного шифрования, использующий
только два ключа. В этом случае выполняется последовательность зашифрованиерасшифрование-зашифрование (EDE).
C = EK1 [DK2 [EK1 [P]]]
Рис. 2.6. Шифрование тройным DES
Рис. 2.7. Дешифрование тройным DES
Не имеет большого значения, что используется на второй стадии: шифрование или
дешифрование. В случае использования дешифрования существует только то
преимущество, что можно тройной DES свести к обычному одиночному DES, используя
K1 = K2:
C = EK1 [DK1 [EK1 [P]]] = EK1 [P]
Тройной DES является достаточно популярной альтернативой DES и используется при
управлении ключами в стандартах ANSI X9.17 и ISO 8732 и в PEM (Privacy Enhanced
Mail).
Известных криптографических атак на тройной DES не существует. Цена подбора ключа в
тройном DES равна 2112.
Алгоритм Blowfish
Blowfish является сетью Фейштеля, у которой количество итераций равно 16. Длина блока
равна 64 битам, ключ может иметь любую длину в пределах 448 бит. Хотя перед началом
любого шифрования выполняется сложная фаза инициализации, само шифрование данных
выполняется достаточно быстро.
Алгоритм предназначен в основном для приложений, в которых ключ меняется нечасто, к
тому же существует фаза начального рукопожатия, во время которой происходит
аутентификация сторон и согласование общих параметров и секретов. Классическим
410
примером подобных приложений является сетевое взаимодействие. При реализации на 32битных микропроцессорах с большим кэшем данных Blowfish значительно быстрее DES.
Алгоритм состоит из двух частей: расширение ключа и шифрование данных. Расширение
ключа преобразует ключ длиной, по крайней мере, 448 бит в несколько массивов
подключей общей длиной 4168 байт.
В основе алгоритма лежит сеть Фейштеля с 16 итерациями. Каждая итерация состоит из
перестановки, зависящей от ключа, и подстановки, зависящей от ключа и данных.
Операциями являются XOR и сложение 32-битных слов.
Blowfish использует большое количество подключей. Эти ключи должны быть вычислены
заранее, до начала любого шифрования или дешифрования данных. Элементы алгоритма:
1.
Р - массив, состоящий из восемнадцати 32-битных подключей:
Р1, Р2, ..., Р18.
2.
3.
4.
5.
6.
Четыре 32-битных S-boxes c 256 входами каждый. Первый индекс означает номер S-box, второй
индекс - номер входа.
S1,0,
S2,0,
S3,0,
S4,0,
S1,1,
S2,1,
S3,1,
S4,1,
…
…
…
…
S1,255;
S2,255;
S3,255;
S4,255;
Метод, используемый для вычисления этих подключей, будет описан ниже.
Шифрование
Входом является 64-битный элемент данных X, который делится на две 32-битные
половины, Xl и Xr.
Xl = Xl XOR Pi
Xr = F (Xl) XOR Xr
Swap Xl and Xr
Функция F
Разделить Xl на четыре 8-битных элемента A, B, C, D.
F (Xl) = ((S1,А + S2,B mod 232) XOR S3,C) + S4,D mod 232
Дешифрование отличается от шифрования тем, что Pi используются в обратном порядке.
Генерация подключей
Подключи вычисляются с использованием самого алгоритма Blowfish.
1.
Инициализировать первый Р-массив и четыре S-boxes фиксированной строкой.
2.
Выполнить операцию XOR P1 с первыми 32 битами ключа, операцию XOR P2 со вторыми 32 битами
ключа и т.д. Повторять цикл до тех пор, пока весь Р-массив не будет побитово сложен со всеми
битами ключа. Для коротких ключей выполняется конкатенация ключа с самим собой.
411
3.
Зашифровать нулевую строку алгоритмом Blowfish, используя подключи, описанные в пунктах (1) и
(2).
4.
Заменить Р1 и Р2 выходом, полученным на шаге (3).
5.
Зашифровать выход шага (3), используя алгоритм Blowfish с модифицированными подключами.
6.
Заменить Р3 и Р4 выходом, полученным на шаге (5).
7.
Продолжить процесс, заменяя все элементы Р-массива, а затем все четыре S-boxes, выходами
соответствующим образом модифицированного алгоритма Blowfish.
Для создания всех подключей требуется 521 итерация.
Алгоритм IDEA
IDEA (International Data Encryption Algorithm) является блочным симметричным
алгоритмом шифрования, разработанным Сюдзя Лай (Xuejia Lai) и Джеймсом Массей
(James Massey) из швейцарского федерального института технологий. Первоначальная
версия была опубликована в 1990 году. Пересмотренная версия алгоритма, усиленная
средствами защиты от дифференциальных криптографических атак, была представлена в
1991 году и подробно описана в 1992 году.
IDEA является одним из нескольких симметричных криптографических алгоритмов,
которыми первоначально предполагалось заменить DES.
Принципы разработки
IDEA является блочным алгоритмом, который использует 128-битовый ключ для
шифрования данных блоками по 64 бита.
Целью разработки IDEA было создание относительно стойкого криптографического
алгоритма с достаточно простой реализацией.
Криптографическая стойкость
Следующие характеристики IDEA характеризуют его криптографическую стойкость:
1.
Длина блока: длина блока должна быть достаточной, чтобы скрыть все статистические
характеристики исходного сообщения. С другой стороны, сложность реализации
криптографической функции возрастает экспоненциально в соответствии с размером блока.
Использование блока размером в 64 бита в 90-е годы означало достаточную силу. Более того,
использование режима шифрования СВС говорит о дальнейшем усилении этого аспекта алгоритма.
2.
Длина ключа: длина ключа должна быть достаточно большой для того, чтобы предотвратить
возможность простого перебора ключа. При длине ключа 128 бит IDEA считается достаточно
безопасным.
3.
Конфузия: зашифрованный текст должен зависеть от ключа сложным и запутанным способом.
4.
Диффузия: каждый бит незашифрованного текста должен влиять на каждый бит зашифрованного
текста. Распространение одного незашифрованного бита на большое количество зашифрованных
битов скрывает статистическую структуру незашифрованного текста. Определить, как
статистические характеристики зашифрованного текста зависят от статистических характеристик
412
незашифрованного текста, должно быть непросто. IDEA с этой точки зрения является очень
эффективным алгоритмом.
В IDEA два последних пункта выполняются с помощью трех операций. Это отличает его
от DES, где все постороено на использовании операции XOR и маленьких нелинейных Sboxes.
Каждая операция выполняется над двумя 16-битными входами и создает один 16-битный
выход. Этими операциями являются:
1.
Побитовое исключающее OR, обозначаемое как .
2.
Сумма целых по модулю 216 (по модулю 65536), при этом входы и выходы трактуются как
беззнаковые 16-битные целые. Эту операцию обозначим как +.
3.
Умножение целых по модулю 216 + 1 (по модулю 65537), при этом входы и выходы трактуются как
беззнаковые 16-битные целые, за исключением того, что блок из одних нулей трактуется как 216.
Эту операцию обозначим как •.
Эти три операции являются несовместимыми в том смысле, что:
1.
Не существует пары из трех операций, удовлетворяющих дистрибутивному закону. Например
a • (b + c) <> (a • b) + (a • c)
2.
Не существует пары из трех операций, удовлетворяющих ассоциативному закону. Например
a + (b
c) <> (a + b)
c
Использование комбинации из этих трех операций обеспечивает комплексную
трансформацию входа, делая криптоанализ более трудным, чем в таком алгоритме как
DES, основанном исключительно на функции XOR.
Шифрование
Рассмотрим общую схему шифрования IDEA. Как и в любом алгоритме шифрования,
здесь существует два входа: незашифрованный блок и ключ. В данном случае
незашифрованный блок имеет длину 64 бита, ключ имеет длину 128 бит.
Алгоритм IDEA состоит из восьми раундов, за которыми следует заключительное
преобразование. Алгоритм разделяет блок на четыре 16-битных подблока. Каждый раунд
получает на входе четыре 16-битных подблока и создает четыре 16-битных выходных
подблока. Заключительное преобразование также получает на входе четыре 16-битных
подблока и создает четыре 16-битных подблока. Каждый раунд использует шесть 16битных ключей, заключительное преобразование использует четыре подключа, т.е. всего в
алгоритме используется 52 подключа.
413
Рис. 3.1. Алгоритм IDEA
Последовательность преобразований отдельного раунда
Рассмотрим последовательность преобразований отдельного раунда.
Одним из основных элементов алгоритма, обеспечивающих диффузию, является
структура, называемая МА (умножение/сложение):
Рис. 3.2. Структура МА (умножение/сложение)
На вход этой структуре подаются два 16-битных значения и два 16-битных подключа, на
выходе создаются два 16-битных значения. Исчерпывающая компьютерная проверка
показывает, что каждый бит выхода этой структуры зависит от каждого бита входов
414
незашифрованного блока и от каждого бита подключей. Данная структура повторяется в
алгоритме восемь раз, обеспечивая высокоэффективную диффузию.
Раунд начинается с преобразования, которое комбинирует четыре входных подблока с
четырьмя подключами, используя операции сложения и умножения. Четыре выходных
блока этого преобразования комбинируются, используя операцию XOR для формирования
двух 16-битных блоков, которые являются входами МА структуры. Кроме того, МА
структура имеет на входе еще два подключа и создает два 16-битных выхода.
Рис. 3.3. I-ый раунд IDEA
В заключении четыре выходных подблока первого преобразования комбинируются с
двумя выходными подблоками МА структуры, используя XOR для создания четырех
выходных подблоков данной итерации. Заметим, что два выхода, которые частично
создаются вторым и третьим входами (Х2 и Х3), меняются местами для создания второго и
415
третьего выходов (W12 и W13). Это увеличивает перемешивание битов и делает алгоритм
более стойким для дифференциального криптоанализа.
Рассмотрим девятый раунд алгоритма, обозначенный как заключительное преобразование.
Это та же структура, что была описана выше. Единственная разница состоит в том, что
второй и третий входы меняются местами. Это сделано для того, чтобы дешифрование
имело ту же структуру, что и шифрование. Заметим, что девятая стадия требует только
четыре входных подключа, в то время как для первых восьми стадий для каждой из них
необходимо шесть входных подключей.
Рис. 3.4. Заключительное преобразование
Создание подключей
Пятьдесят два 16-битных подключа создаются из 128-битного ключа шифрования
следующим образом. Первые восемь подключей, которые обозначим как Z1, Z2, ..., Z8,
получаются непосредственно из ключа, при этом Z1 равен первым 16 битам, Z2 равен
следующим 16 битам и т.д. Затем происходит циклический сдвиг ключа влево на 25 битов,
и создаются следующие восемь подключей. Эта поцедура повторяется до тех пор, пока не
будут созданы все 52 подключа.
Заметим, что каждый первый подключ раунда получен из своего подмножества битов
ключа. Если весь ключ обозначить как Z [1..128], то первыми ключами в восьми раундах
будут:
Z1 = Z [1..16] Z25 = Z [76..91]
Z7 = Z [97..112] Z31 = Z [44..59]
Z13 = Z [90..105] Z37 = Z [37..52]
Z19 = Z [83..98] Z43 = Z [30..45]
Хотя на каждом раунде за исключением первого и восьмого используются только 96
битов подключа, множество битов ключа на каждой итерации не пересекаются, и не
существует отношения простого сдвига между подключами разных раундов. Это
происходит потому, что на каждом раунде используется только шесть подключей, в то
время как при каждой ротации ключа получается восемь подключей.
416
Дешифрование
Процесс дешифрования аналогичен процессу шифрования. Дешифрование состоит в
использовании зашифрованного текста в качестве входа в ту же самую структуру IDEA,
но с другим набором ключей. Дешифрующие ключи U1, . . . , U52 получаются из
шифрующих ключей следующим образом:
1.
Первые четыре подключа i-ого раунда дешифрования получаются из первых четырех подключей
(10-i)-го раунда шифрования, где стадия заключительного преобразования считается 9-м раундом.
Первый и четвертый ключи дешифрования эквивалентны мультипликативной инверсии по модулю
(216 + 1) соответствующих первого и четвертого подключей шифрования. Для раундов со 2 по 8
второй и третий подключи дешифрования эквивалентны аддитивной инверсии по модулю (216)
соответствующих третьего и второго подключей шифрования. Для раундов 1 и 9 второй и третий
подключи дешифрования эквивалентны аддитивной инверсии по модулю (216) соответствующих
второго и третьего подключей шифрования.
2.
Для первых восьми раундов последние два подключа i раунда дешифрования эквивалентны
последним двум подключам (9 - i) раунда шифрования.
Для мультипликативной инверсии используется нотация Zj-1, т.е.:
Zj • Zj-1 =1 mod (216 + 1)
Так как 216 + 1 является простым числом, каждое ненулевое целое Zj 216 имеет
уникальную мультипликативную инверсию по модулю (216 + 1). Для аддитивной инверсии
используется нотация (-Zj), таким образом, мы имеем: -Zj + Zj = 0 mod (216)
Для доказательства того, что алгоритм дешифрования с соответствующими подключами
имеет корректный результат, рассмотрим одновременно процессы шифрования и
дешифрования. Каждый из восьми раундов разбит на две стадии преобразования, первая
из которых называется трансформацией, а вторая шифрованием.
Рис. 3.5. Шифрование IDEA
417
Рис. 3.6. Дешифрование IDEA
Рассмотрим преобразования, выполняемые в прямоугольниках на обоих рисунках. При
шифровании поддерживаются следующие соотношения на выходе трансформации:
Y1 = W81 • Z49 Y3 = W82 + Z51
Y2 = W83 + Z50 Y4 = W84 • Z52
Первая стадия первого раунда процесса дешифрования поддерживает следующие
соотношения:
J11 = Y1 • U1 J13 = Y3 + U3
J12 = Y2 + U2 J14 = Y4 • U4
Подставляя соответствующие значения, получаем:
J11
J12
J13
J14
=
=
=
=
Y1
Y2
Y3
Y4
•
+
+
•
Z49-1
-Z50
-Z51
Z52-1
=
=
=
=
W81
W83
W82
W84
•
+
+
•
Z49
Z50
Z51
Z52
•
=
+
•
Z49-1 = W81
W83 + Z50 + -Z50 = W83
-Z51 = W82
Z52-1 = W84
Таким образом, выход первой стадии процесса дешифрования эквивалентен входу
последней стадии процесса шифрования за исключением чередования второго и третьего
блоков. Теперь рассмотрим следующие отношения:
W81 = I81
MAR(I81
I83, I82
I84)
W82 = I83
MAR(I81
I83, I82
I84)
W83 = I82
MAL(I81
I83, I82
I84)
W84 = I84
MAL(I81
I83, I82
I84)
Где MAR(X, Y) есть правый выход МА структуры с входами Х и Y , и MAL(X, Y) есть
левый выход МА структуры с входами Х и Y. Теперь получаем
V11 = J11
MAR (J11
J13, J12
J14) =
W81
MAR(W81
W82, W83
W84) =
I81
MAR(I81
I83, I82
I84)
MAR[ I81
MAR(I81
MAR(I81
I83, I82
I83, I82
I84)
I84), I82
418
I83
MAL(I81
I83, I82
I84)
MAL(I81
I83, I82
I84) ] =
I81
MAR(I81
MAR(I81
I81
I83, I82
I83, I82
I84
I84)
I84) =
Аналогично мы имеем
V12 = I83
V13 = I82
V14 = I84
Таким образом, выход второй стадии процесса дешифрования эквивалентен входу
предпоследней стадии процесса шифрования за исключением чередования второго и
третьего подблоков. Аналогично можно показать, что
V81
V82
V83
V84
=
=
=
=
I11
I13
I12
I14
Наконец, так как выход трансформации процесса дешифрования эквивалентен первой
стадии процесса шифрования за исключением чередования второго и третьего подблоков,
получается, что выход всего процесса шифрования эквивалентен входу процесса
шифрования.
Алгоритм ГОСТ 28147
Алгоритм ГОСТ 28147 является отечественным стандартом для алгоритмов
симметричного шифрования. ГОСТ 28147 разработан в 1989 году, является блочным
алгоритмом шифрования, длина блока равна 64 битам, длина ключа равна 256 битам,
количество раундов равно 32. Алгоритм представляет собой классическую сеть Фейштеля.
Li = Ri-1
Ri = Li
f (Ri-1, Ki)
Функция F проста. Сначала правая половина и i-ый подключ складываются по модулю 232.
Затем результат разбивается на восемь 4-битовых значений, каждое из которых подается
на вход S-box. ГОСТ 28147 использует восемь различных S-boxes, каждый из которых
имеет 4-битовый вход и 4-битовый выход. Выходы всех S-boxes объединяются в 32битное слово, которое затем циклически сдвигается на 11 битов влево. Наконец, с
помощью XOR результат объединяется с левой половиной, в результате чего получается
новая правая половина.
419
Рис. 3.7. I-ый раунд ГОСТ 28147
Генерация ключей проста. 256-битный ключ разбивается на восемь 32-битных подключей.
Алгоритм имеет 32 раунда, поэтому каждый подключ используется в четырех раундах по
следующей схеме:
Раунд
1 2 3 4 5 6 7 8
Подключ 1 2 3 4 5 6 7 8
Раунд
9 10 11 12 13 14 15 16
Подключ 1 2 3 4 5 6 7 8
Раунд
17 18 19 20 21 22 23 24
Подключ 1 2 3 4 5 6 7 8
25 26 27 28 29 30 31 32
Раунд
Подключ 8 7 6 5 4 3 2 1
Считается, что стойкость алгоритма ГОСТ 28147 во многом определяется структурой Sboxes. Долгое время структура S-boxes в открытой печати не публиковалась. В настоящее
время известны S-boxes, которые используются в приложениях Центрального Банка РФ и
считаются достаточно сильными. Напомню, что входом и выходом S-box являются 4битные числа, поэтому каждый S-box может быть представлен в виде строки чисел от 0 до
15, расположенных в некотором порядке. Тогда порядковый номер числа будет являться
входным значением S-box, а само число - выходным значением S-box.
1-ый S-box 4 10 9 2 13 8 0 14
420
6 11 1 12 7 15 5 3
2-ой S-box 14 11 4 12 6 13 15 10
2 3 8 1 0 7 5 9
3-ий S-box 5 8 1 13 10 3 4 2
14 15 12 7 6 0 9 11
4-ый S-box 7 13 10 1 0 8 9 15
14 4 6 12 11 2 5 3
5-ый S-box 6 12 7 1 5 15 13 8
4 10 9 14 0 3 11 2
6-ой S-box 4 11 10 0 7 2 1 13
3 6 8 5 9 12 15 14
7-ой S-box 13 11 4 1 3 15 5 9
0 10 14 7 6 8 2 12
8-ой S-box 1 15 13 0 5 7 10 4
9 2 3 14 6 11 8 12
Основные различия между DES и ГОСТ 28147 следующие:

DES использует гораздо более сложную процедуру создания подключей, чем ГОСТ 28147. В ГОСТ
эта процедура очень проста.

В DES применяется 56-битный ключ, а в ГОСТ 28147 - 256-битный. При выборе сильных S-boxes
ГОСТ 28147 считается очень стойким.

У S-boxes DES 6-битовые входы и 4-битовые выходы, а у S-boxes ГОСТ 28147 4-битовые входы и
выходы. В обоих алгоритмах используется по восемь S-boxes, но размер S-box ГОСТ 28147
существенно меньше размера S-box DES.

В DES применяются нерегулярные перестановки Р, в ГОСТ 28147 используется 11-битный
циклический сдвиг влево. Перестановка DES увеличивает лавинный эффект. В ГОСТ 28147
изменение одного входного бита влияет на один S-box одного раунда, который затем влияет на два
S-boxes следующего раунда, три S-boxes следующего и т.д. В ГОСТ 28147 требуется 8 раундов
прежде, чем изменение одного входного бита повлияет на каждый бит результата; DES для этого
нужно только 5 раундов.

В DES 16 раундов, в ГОСТ 28147 - 32 раунда, что делает его более стойким к дифференциальному и
линейному криптоанализу.
Режимы выполнения алгоритмов симметричного шифрования
Для любого симметричного блочного алгоритма шифрования определено четыре режима
выполнения.
ECB - Electronic Codebook - каждый блок из 64 битов незашифрованного текста
шифруется независимо от остальных блоков, с применением одного и того же ключа
шифрования. Типичные приложения - безопасная передача одиночных значений
(например, криптографического ключа).
CBC - Cipher Block Chaining - вход криптографического алгоритма является результатом
применения операции XOR к следующему блоку незашифрованного текста и
421
предыдущему блоку зашифрованного текста. Типичные приложения - общая
блокоориентированная передача, аутентификация.
CFB - Cipher Feedback - при каждом вызове алгоритма обрабатывается J битов входного
значения. Предшествующий зашифрованный блок используется в качестве входа в
алгоритм; к J битам выхода алгоритма и следующему незашифрованному блоку из J битов
применяется операция XOR, результатом которой является следующий зашифрованный
блок из J битов. Типичные приложения - потокоориентированная передача,
аутентификация.
OFB - Output Feedback - аналогичен CFB, за исключением того, что на вход алгоритма при
шифровании следующего блока подается результат шифрования предыдущего блока;
только после этого выполняется операция XOR с очередными J битами незашифрованного
текста. Типичные приложения - потокоориентированная передача по зашумленному
каналу (например, спутниковая связь).
Режим ECB
Данный режим является самым простым режимом, при котором незашифрованный текст
обрабатывается последовательно, блок за блоком. Каждый блок шифруется, используя
один и тот же ключ. Если сообщение длиннее, чем длина блока соответствующего
алгоритма, то оно разбивается на блоки соответствующей длины, причем последний блок
дополняется в случае необходимости фиксированными значениями. При использовании
данного режима одинаковые незашифрованные блоки будут преобразованы в одинаковые
зашифрованные блоки.
ECB-режим идеален для небольшого количества данных, например, для шифрования
ключа сессии.
Существенным недостатком ECB является то, что один и тот же блок незашифрованного
текста, появляющийся более одного раза в сообщении, всегда имеет один и тот же
зашифрованный вид. Вследствие этого для больших сообщений ECB режим считается
небезопасным. Если сообщение имеет много одинаковых блоков, то при криптоанализе
данная закономерность будет обнаружена.
Режим CBC
Для преодоления недостатков ECB используют способ, при котором одинаковые
незашифрованные блоки преобразуются в различные зашифрованные. Для этого в
качестве входа алгоритма используется результат применения операции XOR к текущему
незашифрованному блоку и предыдущему зашифрованному блоку.
422
Рис. 3.8. Шифрование в режиме СВС
Рис. 3.9. Дешифрование в режиме СВС
Для получения первого блока зашифрованного сообщения используется
инициализационный вектор (IV), для которого выполняется операция XOR с первым
блоком незашифрованного сообщения. При дешифровании для IV выполняется операция
XOR с выходом дешифрирующего алгоритма для получения первого блока
незашифрованного текста.
IV должен быть известен как отправителю, так и получателю. Для максимальной
безопасности IV должен быть защищен так же, как ключ.
Режим CFB
Блочный алгоритм предназначен для шифрования блоков определенной длины. Однако
можно преобразовать блочный алгоритм в поточный алгоритм шифрования, используя
последние два режима. Поточный алгоритм шифрования устраняет необходимость
разбивать сообщение на целое число блоков достаточно большой длины, следовательно,
он может работать в реальном времени. Таким образом, если передается поток символов,
каждый символ может шифроваться и передаваться сразу, с использованием символьно
ориентированного режима блочного алгоритма шифрования.
Одним из преимуществ такого режима блочного алгоритма шифрования является то, что
зашифрованный текст будет той же длины, что и исходный.
Будем считать, что блок данных, используемый для передачи, состоит из J бит; обычным
значением является J=8. Как и в режиме CBC, здесь используется операция XOR для
предыдущего блока зашифрованного текста и следующего блока незашифрованного
423
текста. Таким образом, любой блок зашифрованного текста является функцией от всего
предыдущего незашифрованного текста.
Рассмотрим шифрование. Входом функции шифрования является регистр сдвига, который
первоначально устанавливается в инициализационный вектор IV. Для левых J битов
выхода алгоритма выполняется операция XOR с первыми J битами незашифрованного
текста Р1 для получения первого блока зашифрованного текста С1. Кроме того,
содержимое регистра сдвигается влево на J битов, и С1 помещается в правые J битов этого
регистра. Этот процесс продолжается до тех пор, пока не будет зашифровано все
сообщение.
При дешифровании используется аналогичная схема, за исключением того, что для блока
получаемого зашифрованного текста выполняется операция XOR с выходом алгоритма
для получения незашифрованного блока.
Рис. 3.10. Шифрование в режиме СFВ
424
Рис. 3.11. Дешифрование в режиме СFВ
Режим OFB
Данный режим подобен режиму CFB. Разница заключается в том, что выход алгоритма в
режиме OFB подается обратно в регистр, тогда как в режиме CFB в регистр подается
результат применения операции XOR к незашифрованному блоку и результату алгоритма.
Основное преимущество режима OFB состоит в том, что если при передаче произошла
ошибка, то она не распространяется на следующие зашифрованные блоки, и тем самым
сохраняется возможность дешифрования последующих блоков. Например, если
появляется ошибочный бит в Сi, то это приведет только к невозможности дешифрования
этого блока и получения Рi. Дальнейшая последовательность блоков будет расшифрована
корректно. При использовании режима CFB Сi подается в качестве входа в регистр и,
следовательно, является причиной последующего искажения потока.
Недостаток OFB в том, что он более уязвим к атакам модификации потока сообщений,
чем CFB.
425
Рис. 3.12. Шифрование в режиме OFB
Рис. 3.13. Дешифрование в режиме OFB
Создание случайных чисел
Случайные числа играют важную роль при использовании криптографии в различных
сетевых приложениях, относящихся к безопасности. Сделаем краткий обзор требований,
предъявляемых к случайным числам в приложениях сетевой безопасности, а затем
рассмотрим несколько способов создания случайных чисел.
426
Требования к случайным числам
Большинство алгоритмов сетевой безопасности, основанных на криптографии,
используют случайные числа. Например:
1.
Схемы взаимной аутентификации. В большинстве сценариев аутентификации и распределения
ключа используются nonсes для предотвращения атак повтора (replay-атак). Применение
действительно случайных чисел в качестве nonces не дает противнику возможности вычислить или
угадать nonce.
2.
Ключ сессии, созданный KDC или кем-либо из участников.
Двумя основными требованиями к последовательности случайных чисел являются
случайность и непредсказуемость.
Случайность
Обычно при создании последовательности псевдослучайных чисел предполагается, что
данная последовательность чисел должна быть случайной в некотором определенном
статистическом смысле. Следующие два критерия используются для доказательства того,
что последовательность чисел является случайной:
1.
Однородное распределение: распределение чисел в последовательности должно быть однородным;
это означает, что частота появления каждого числа должна быть приблизительно одинаковой.
2.
Независимость: ни одно значение в последовательности не должно зависеть от других.
Хотя существуют тесты, показывающие, что последовательность чисел соответствует
некоторому распределению, такому как однородное распределение, теста для
"доказательства" независимости нет. Тем не менее, можно подобрать набор тестов для
доказательства того, что последовательность является зависимой. Общая стратегия
предполагает применение набора таких тестов до тех пор, пока не будет уверенности, что
независимость существует.
Непредсказуемость
В приложениях, таких как взаимная аутентификация и генерация ключа сессии, нет
жесткого требования, чтобы последовательность чисел была статистически случайной, но
члены последовательности должны быть непредсказуемы. При "правильной" случайной
последовательности каждое число статистически не зависит от остальных чисел и,
следовательно, непредсказуемо. Однако правильные случайные числа на практике
используются достаточно редко, чаще последовательность чисел, которая должна быть
случайной, создается некоторым алгоритмом. В данном случае необходимо, чтобы
противник не мог предугадать следующие элементы последовательности, основываясь на
знании предыдущих элементов и используемого алгоритма.
Источники случайных чисел
Источники действительно случайных чисел найти трудно. Физические генераторы шумов,
такие как детекторы событий ионизирующей радиации, газовые разрядные трубки и
имеющий течь конденсатор могут быть такими источниками. Однако эти устройства в
427
приложениях сетевой безопасности применяются ограниченно. Проблемы также
вызывают грубые атаки на такие устройства. Альтернативным решением является
создание набора из большого числа случайных чисел и опубликование его в некоторой
книге. Тем не менее, и такие наборы обеспечивают очень ограниченный источник чисел
по сравнению с тем количеством, которое требуется приложениям сетевой безопасности.
Более того, хотя наборы из этих книг действительно обеспечивает статистическую
случайность, они предсказуемы, так как противник может получить их копию.
Таким образом, шифрующие приложения используют для создания случайных чисел
специальные алгоритмы. Эти алгоритмы детерминированы и, следовательно, создают
последовательность чисел, которая не является статистически случайной. Тем не менее,
если алгоритм хороший, полученная последовательность будет проходить много тестов на
случайность. Такие числа часто называют псевдослучайными числами.
Рассмотрим несколько алгоритмов генерации случайных чисел.
Генераторы псевдослучайных чисел
Первой широко используемой технологией создания случайного числа был алгоритм,
предложенный Лехмером, который известен как метод линейного конгруента. Этот
алгоритм параметризуется четырьмя числами следующим образом:
m Модуль (основание системы)
m>0
a Множитель
0 a<m
c Приращение
0 с<m
Х0 Начальное значение или зерно (seed) 0 Х0 < m
Последовательность случайных чисел {Xn} получается с помощью следующего
итерационного равенства:
Xn+1 = (a Xn + c) mod m
Если m, а и с являются целыми, то создается последовательность целых чисел в диапазоне
0 Xn < m.
Выбор значений для а, с и m является критичным для разработки хорошего генератора
случайных чисел.
Очевидно, что m должно быть очень большим, чтобы была возможность создать много
случайных чисел. Считается, что m должно быть приблизительно равно максимальному
положительному целому числу для данного компьютера. Таким образом, обычно m
близко или равно 231.
Существует три критерия, используемые при выборе генератора случайных чисел:
1.
Функция должна создавать полный период, т.е. все числа между 0 и m до того, как создаваемые
числа начнут повторяться.
2.
Создаваемая последовательность должна появляться случайно. Последовательность не является
случайной, так как она создается детерминированно, но различные статистические тесты, которые
могут применяться, должны показывать, что последовательность случайна.
428
3.
Функция должна эффективно реализовываться на 32-битных процессорах.
Значения а, с и m должны быть выбраны таким образом, чтобы эти три критерия
выполнялись. В соответствии с первым критерием можно показать, что если m является
простым и с = 0, то при определенном значении а период, создаваемый функцией, будет
равен m-1. Для 32-битной арифметики соответствующее простое значение m = 231 - 1.
Таким образом, функция создания псевдослучайных чисел имеет вид:
Xn+1 = (a Xn) mod (231 - 1)
Только небольшое число значений а удовлетворяет всем трем критериям. Одно из таких
значений есть а = 75 = 16807, которое использовалось в семействе компьютеров IBM 360.
Этот генератор широко применяется и прошел более тысячи тестов, больше, чем все
другие генераторы псевдослучайных чисел.
Сила алгоритма линейного конгруента в том, что если сомножитель и модуль (основание)
соответствующим образом подобраны, то результирующая последовательность чисел
будет статистически неотличима от последовательности, являющейся случайной из
набора 1, 2, ..., m-1. Но не может быть случайности в последовательности, полученной с
использованием алгоритма, независимо от выбора начального значения Х0. Если значение
выбрано, то оставшиеся числа в последовательности будут предопределены. Это всегда
учитывается при криптоанализе.
Если противник знает, что используется алгоритм линейного конгруента, и если известны
его параметры (а = 75, с = 0, m = 231 - 1), то, если раскрыто одно число, вся
последовательность чисел становится известна. Даже если противник знает только, что
используется алгоритм линейного конгруента, знания небольшой части
последовательности достаточно для определения параметров алгоритма и всех
последующих чисел. Предположим, что противник может определить значения Х0, Х1, Х2,
Х3. Тогда :
Х1 = (а Х0 + с ) mod m
Х2 = (а Х1 + с ) mod m
Х3 = (а Х2 + с ) mod m
Эти равенства позволяют найти а, с и m.
Таким образом, хотя алгоритм и является хорошим генератором псевдослучайной
последовательности чисел, желательно, чтобы реально используемая последовательность
была непредсказуемой, поскольку в этом случае знание части последовательности не
позволит определить будущие ее элементы. Эта цель может быть достигнута несколькими
способами. Например, использование внутренних системных часов для модификации
потока случайных чисел. Один из способов применения часов состоит в перезапуске
последовательности после N чисел, используя текущее значение часов по модулю m в
качестве нового начального значения. Другой способ состоит в простом добавлении
значения текущего времени к каждому случайному числу по модулю m.
Криптографически созданные случайные числа
В криптографических приложениях целесообразно шифровать получающиеся случайные
числа. Чаще всего используется три способа.
429
Циклическое шифрование
Рис. 3.14. Циклическое шифрование
В данном случае применяется способ создания ключа сессии из мастер-ключа. Счетчик с
периодом N используется в качестве входа в шифрующее устройство. Например, в случае
использования 56-битного ключа DES может применяться счетчик с периодом 256. После
каждого созданного ключа значение счетчика увеличивается на 1. Таким образом,
псевдослучайная последовательность, полученная по данной схеме, имеет полный период:
каждое выходное значение Х0, Х1,...ХN-1 основано на различных значениях счетчика и,
следовательно, Х0 X1 XN-1. Так как мастер-ключ защищен, легко показать, что любой
секретный ключ не зависит от знания одного или более предыдущих секретных ключей.
Для дальнейшего усиления алгоритма вход должен быть выходом полнопериодического
генератора псевдослучайных чисел, а не простой последовательностью.
Режим Output Feedback DES
Режим OFB DES может применяться для генерации ключа, аналогично тому, как он
используется для потокового шифрования. Заметим, что выходом каждой стадии
шифрования является 64-битное значение, из которого только левые j битов подаются
обратно для шифрования. 64-битные выходы составляют последовательность
псевдослучайных чисел с хорошими статистическими свойствами.
Генератор псевдослучайных чисел ANSI X9.17
Один из наиболее сильных генераторов псевдослучайных чисел описан в ANSI X9.17. В
число приложений, использующих эту технологию, входят приложения финансовой
безопасности и PGP.
Алгоритмом шифрования является тройной DES. Генератор ANSI X9.17 состоит из
следующих частей:
430
1.
Вход: генератором управляют два псевдослучайных входа. Один является 64-битным
представлением текущих даты и времени, которые изменяются каждый раз при создании числа.
Другой является 64-битным начальным значением; оно инициализируется некоторым
произвольным значением и изменяется в ходе генерации последовательности псевдослучайных
чисел.
2.
Ключи: генератор использует три модуля тройного DES. Все три используют одну и ту же пару 56битных ключей, которая должна держаться в секрете и применяться только для генерации
псевдослучайного числа.
3.
Выход: выход состоит из 64-битного псевдослучайного числа и 64-битного значения, которое будет
использоваться в качестве начального значения при создании следующего числа.
Рис. 3.15. Генератор псевдослучайных чисел ANSI X9.17
DTi - значение даты и времени на начало i-ой стадии генерации.
Vi - начальное значение для i-ой стадии генерации.
Ri - псевдослучайное число, созданное на i-ой стадии генерации.
K1, K2 - ключи, используемые на каждой стадии.
Тогда:
Ri = EDEK1,K2 [ EDEK1,K2 [ DTi]
Vi ]
Vi+1 = EDEK1,K2 [ EDEK1,K2 [ DTi] Ri]
Схема включает использование 112-битного ключа и трех EDE-шифрований. На вход
подаются два псевдослучайных значения: значение даты и времени и начальное значение
очередной итерации, на выходе создаются начальное значение для следующей итерации и
очередное псевдослучайное значение. Даже если псевдослучайное число Ri будет
скомпрометировано, вычислить Vi+1 из Ri невозможно, и, следовательно, следующее
псевдослучайное значение Ri+1, так как для получения Vi+1 дополнительно выполняются
три операции EDE.
431
Разработка Advanced Encryption Standard (AES)
Обзор процесса разработки AES
Инициатива в разработке AES принадлежит NIST. Основная цель состояла в создании
федерального стандарта (FIPS), который бы описывал алгоритм шифрования,
используемый для защиты информации как в государственном, так и в частном секторе.
Конкуренция среди финалистов была достаточно серьезной, и в результате длительного
процесса оценки NIST выбрал Rijndael в качестве алгоритма AES. Мы кратко рассмотрим
этот процесс и суммируем различные характеристики алгоритмов, которые были описаны
на данном этапе. Следующий раздел представляет собой обзор разработки AES и
обсуждение деталей алгоритмов.
Историческая справка
2 января 1997 года NIST объявил о начале разработки AES, и 12 сентября 1997 года были
представлены официальные требования к алгоритмам. В этих требованиях указывалось,
что целью NIST является разработка неклассифицированного, хорошо
проанализированного алгоритма шифрования, доступного для широкого применения. Как
минимум алгоритм должен быть симметричным и блочным и поддерживать длину блока
128 бит и длину ключа 128, 192 и 256 бит.
20 августа 1998 года NIST анонсировал пятнадцать кандидатов на алгоритм AES на
первой конференции кандидатов AES (AES1), и было предложено прокомментировать их
характеристики. Данные алгоритмы были разработаны промышленными и
академическими кругами двенадцати стран. Вторая конференция кандидатов AES (AES2)
была проведена в марте 1999 года с целью обсуждения результатов анализа
предложенных алгоритмов. В августе 1999 года были представлены выбранные NIST пять
финалистов. Ими стали MARS, RC6™, Rijndael, Serpent и Twofish.
Обзор финалистов
Все пять финалистов являются итерационными блочными алгоритмами шифрования: они
определяют преобразование, которое повторяется определенное число раз над блоком
шифруемых или дешифруемых данных. Шифруемый блок данных называется plaintext;
зашифрованный plaintext называется ciphertext. Для дешифрования в качестве
обрабатываемого блока данных используется ciphertext. Каждый финалист также
определяет метод создания серии ключей из исходного ключа, называемый управлением
ключом. Полученные ключи называются подключами. Функции раунда используют в
качестве входа различные подключи для конкретного блока данных.
У каждого финалиста первая и последняя криптографические операции являются
некоторой формой перемешивания подключей и блока данных. Такие операции,
используемые на начальном шаге первого раунда и заключительном шаге последнего
раунда, называются pre- и post-забеливанием (whitening) и могут быть определены
отдельно.
432
Существуют также некоторые другие технические особенности финалистов. Четыре
финалиста определяют таблицы подстановки, называемые S-box: AxB-битный S-box
заменяет А входных битов на В выходных битов. Три финалиста определяют функции
раунда, являющиеся сетью Фейштеля. В классической сети Фейштеля одна половина
блока данных используется для модификации другой половины блока данных, затем
половины меняются местами. Два финалиста не используют сеть Фейштеля, в каждом
раунде обрабатывают параллельно весь блок данных, применяя подстановки и линейные
преобразования; таким образом, эти два финалиста являются примерами алгоритмов,
использующих линейно-подстановочное преобразование.
Далее рассмотрим каждый из алгоритмов в алфавитном порядке; профили и оценки будут
представлены в следующих разделах.
MARS выполняет последовательность преобразований в следующем порядке: сложение с
ключом в качестве pre-whitening, 8 раундов прямого перемешивания без использования
ключа, 8 раундов прямого преобразования с использованием ключа, 8 раундов обратного
преобразования с использованием ключа, 8 раундов обратного перемешивания без
использования ключа и вычитание ключа в качестве post-whitening. 16 раундов с
использованием ключа называются криптографическим ядром. Раунды без ключа
используют два 8х16- битных S-boxes и операции сложения и XOR. В дополнение к этим
элементам раунды с ключом используют 32-битное умножение ключа, зависимые от
данных циклические сдвиги и добавление ключа. Как раунды перемешивания, так и
раунды ядра являются раундами модифицированной сети Фейштеля, в которых четверть
блока данных используется для изменения остальных трех четвертей блока данных.
MARS предложен корпорацией IBM.
RC6 является параметризуемым семейством алгоритмов шифрования, основанных на сети
Фейштеля; для AES было предложено использовать 20 раундов. Функция раунда в RC6
задействует переменные циклические сдвиги, которые определяются квадратичной
функцией от данных. Каждый раунд также включает умножение по модулю 32, сложение,
XOR и сложение с ключом. Сложение с ключом также используется для pre- и poswhitening. RC6 был предложен лабораторией RSA.
Rijndael представляет собой алгоритм, использующий линейно-подстановочные
преобразования и состоящий из 10, 12 или 14 раундов в зависимости от длины ключа.
Блок данных, обрабатываемый с использованием Rijndael, делится на массивы байтов, и
каждая операция шифрования является байт-ориентированной. Функция раунда Rijndael
состоит из четырех слоев. В первом слое для каждого байта применяется S-box
размерностью 8х8 бит. Второй и третий слои являются линейными перемешиваниями, в
которых строки рассматриваются в качестве сдвигаемых массивов и столбцы
перемешиваются. В четвертом слое выполняется операция XOR байтов подключа и
каждого байта массива. В последнем раунде перемешивание столбцов опущено. Rijndael
предложен Joan Daemen (Proton World International) и Vincent Rijmen (Katholieke
Universiteit Leuven).
Serpent является алгоритмом, использующим линейно-подстановочные преобразования и
состоящим из 32 раундов. Serpent также определяет некриптографические начальную и
заключительную перестановки, которые облегчают альтернативный режим реализации,
называемый bitslice. Функция раунда состоит из трех слоев: операция XOR с ключом, 32-х
433
параллельное применение одного из восьми фиксированных S-boxes и линейное
преобразование. В последнем раунде слой XOR с ключом заменен на линейное
преобразование. Serpent предложен Ross Anderson (University of Cambridge), Eli Biham
(Technion) и LarsKnudsen (University of California San Diego).
Twofish является сетью Фейштеля с 16 раундами. Сеть Фейштеля незначительно
модифицирована с использованием однобитных ротаций. Функция раунда влияет на 32битные слова, используя четыре зависящих от ключа S-boxes, за которыми следуют
фиксированные максимально удаленные отдельные матрицы в GF(28), преобразование
псевдо-Адамара и добавление ключа. Twofish был предложен Bruce Schneier, John Kelsey
и Niels Ferguson (Counterpane Internet Security, Inc.), Doug Whiting (Hi/fn, Inc.), David
Wagner (University of California Berkley) и Chris Hall (Princeton University).
При объявлении финалистов представители NIST предложили обсудить и
прокомментировать алгоритмы. На третьей конференции кандидатов AES (AES3),
состоявшейся в апреле 2000 года, представленные комментарии были рассмотрены.
Период открытого обсуждения был завершен 15 мая 2000 года.
Критерий оценки
В сентябре 1997 года, объявив об алгоритмах кандидатов, специалисты NIST определили
общий критерий, который должен использоваться при сравнении алгоритмов.
Критерий оценки был разделен на три основных категории:
1.
Безопасность.
2.
Стоимость.
3.
Характеристики алгоритма и его реализации.
Безопасность является важнейшим фактором при оценке и сравнении таких возможностей
как стойкость алгоритма к криптоанализу, исследование его математической основы,
случайность выходных значений алгоритма и относительная безопасность по сравнению с
другими кандидатами.
Стоимость является второй важной областью оценки, которая характеризует
лицензионные требования, вычислительную эффективность (скорость) на различных
платформах и требования к памяти. Так как одной из целей NIST была возможность
широкой доступности алгоритма AES без лицензионных ограничений, обсуждались в
основном требования защиты интеллектуальной собственности и потенциальные
конфликты. Рассматривалась также скорость работы алгоритма на различных платформах.
При первом обсуждении основное внимание уделялось скорости, связанной со 128битными ключами. При втором обсуждении рассматривались аппаратные реализации и
скорости, связанные со 192- и 256-битными ключами. Также важно рассматривать
требования памяти и ограничения программной реализации.
Третьей областью оценки являлись характеристики алгоритма и реализации, такие как
гибкость, аппаратное и программное соответствие и простота алгоритма. Гибкость
включает возможность алгоритма:
434

управлять размером ключа и блока сверх того, который минимально должен поддерживаться;

безопасно и эффективно реализовываться в различных типах окружений;

реализовываться в качестве поточного алгоритма шифрования, хэш-функции и обеспечивать
дополнительные криптографические сервисы.
Должна быть возможность реализовать алгоритм как аппаратно, так и программно,
эффективность смешанных (firmware) реализаций также считается преимуществом.
Относительная простота разработки алгоритма также является фактором оценки.
На первом и втором этапах обсуждения стало очевидно, что различные выводы,
полученные при анализе, часто переходят из одного рассмотренного выше критерия в
другой. Таким образом, критерии стоимости и характеристик алгоритма рассматривались
вместе в качестве второго критерия после безопасности.
Результаты второго этапа обсуждения
Считается, что второй этап обсуждения начинается с официального объявления пяти
финалистов AES 20 августа 1999 года и заканчивается официальным завершением
обсуждений 15 мая 2000 года.
NIST выполнил анализ оптимизированных реализаций алгоритмов на ANSI C и Java,
которые были предоставлены после первого этапа обсуждений. При тестировании
реализаций на ANSI C основное внимание уделялось скорости выполнения на
компьютерах, использующих различные комбинации процессоров, операционных систем
и компиляторов. Код Java был протестирован на скорость и используемую память на
различных системах. Дополнительно было выполнено статистическое тестирование.
Процесс выбора
Была проведена серия встреч, чтобы выработать стратегию выбора алгоритма AES. В
результате этих встреч все пришли к выводу, что выбранный алгоритм обеспечивает
достаточную безопасность на обозримое будущее, эффективен на различных платформах
и в различных окружениях, обеспечивает приемлемую гибкость с учетом возможных
требований в будущем.
Методология и результаты выбора
Принципы выбора алгоритма
Команда NIST до выбора алгоритма должна была принять несколько фундаментальных
решений:

Принять количественный или качественный критерий при выборе алгоритма.

Выбрать один или несколько алгоритмов в качестве AES.

Выбрать запасной алгоритм(ы).

Рассмотреть предложения по модификации алгоритмов.
435
Кратко рассмотрим полученные результаты.
Качественный или количественный критерий
На одной из первых встреч по планированию второго этапа обсуждений была рассмотрена
возможность количественного подхода, используя который каждый алгоритм или
комбинация алгоритмов будет получать определенное количество очков, основываясь на
критерии оценки. Как при осуществлении такого подхода определить конкретные
значения и обеспечить сравнение алгоритмов? Количественный подход также
обеспечивает явные веса для каждого выбранного фактора AES. Тем не менее, было
достигнуто соглашение, что степень субъективности в критерии приведет к большому
количеству дискуссий. Было также высказано предположение, что определение
количественной системы счетчиков невозможно без широкого обсуждения того, что такая
система является объективной. Поэтому был сделан вывод, что количественный подход
неприменим, и было решено рассмотреть его после первого этапа обсуждений. То есть
было решено рассмотреть безопасность алгоритма, выполнение, реализацию и остальные
характеристики и принять решение, основываясь на качественной оценке каждого
алгоритма - помня, что обсуждение безопасности является самым главным.
Количество алгоритмов AES
В течение первого и второго этапов обсуждений было высказано несколько аргументов
относительно количества алгоритмов, которые должны быть выбраны для включения в
AES. Дополнительно был сделан вывод относительно "запасного" алгоритма для случая,
если будет выбран единственный AES-алгоритм, и последующие изменения окажутся
невозможными. Это может произойти в случае, например, фактической атаки на алгоритм
или простого обсуждения свойств. Было решено, что это необходимо считать частью
параметров, которые в дальнейшем будут рассматриваться как часть процесса выбора.
Некоторые аргументы, выдвинутые в защиту нескольких алгоритмов (против
единственного алгоритма), включают:

В интересах безопасности; на случай, если один алгоритм AES будет взломан, в продуктах должно
быть реализовано более одного AES-алгоритма. Некоторые считают, что широкое применение
единственного алгоритма является рискованным, если данный алгоритм проявит себя как
небезопасный.

Понятия интеллектуальной собственности могут быть рассмотрены позднее в вопросе отсутствия
лицензионных ограничений для конкретного алгоритма. Альтернативный алгоритм может
предоставлять промежуточный вариант, который не влияет на рассмотренное понятие
интеллектуальной собственности.

Множество алгоритмов AES может охватывать более широкий диапазон характеристик, чем
единственный алгоритм. В частности, можно будет предложить как большую степень безопасности,
так и большую степень эффективности, что не всегда возможно при использовании единственного
алгоритма.
Были также высказаны мнения в пользу единственного алгоритма (и/или против
нескольких алгоритмов). Некоторые из этих аргументов таковы:
436

Использование нескольких AES-алгоритмов уменьшает интероперабельность и увеличивает
стоимость продукта.

Несколько алгоритмов могут представлять собой определенное число "атак на интеллектуальную
собственность", направленных против реализаций.

Описание нескольких алгоритмов может вызвать обсуждение вопросов безопасности любого из
алгоритмов.

Аппаратные реализации могут лучше использовать доступные ресурсы, оптимизируя выполнение
единственного алгоритма, а не нескольких алгоритмов.
Во время второго этапа обсуждались эти и другие проблемы, касающиеся единственного
или нескольких алгоритмов AES. Как выяснилось, существует вероятность, доказываемая
коммерческими продуктами сегодня, что скоро продукты будут реализовывать несколько
алгоритмов, которые определяются нуждами потребителей, требованиями
интероперабельности с наследуемыми или собственными системами и так далее. Тройной
DES, который NIST предлагает сделать в обозримом будущем соответствующим FIPSалгоритмом, доступен во многих коммерческих продуктах, как и другие FIPS и не-FIPS
алгоритмы. Следовательно, считается, что наличие этих нескольких алгоритмов в
конкретном продукте обеспечивает большую степень надежности, как и наличие
нескольких длин ключей в AES. В случае атаки на выбранный алгоритм NIST предлагает
задействовать соответствующие исследованные опции, которые включают использование
других финалистов AES, у которых отсутствуют подобные атаки, либо в случае
необходимости определить полностью новые подходы.
В соответствии с выводами об интеллектуальной собственности отмечалось, что если
будет выбрано несколько алгоритмов AES, то возникнет необходимость реализовывать
все AES-алгоритмы, таким образом создавая дополнительные риски в отношении
интеллектуальной собственности.
На конференции AES3 состоялась дискуссия по поводу количества алгоритмов, которые
должны быть включены в AES. Большинство присутствующих выразили поддержку
выбора единственного алгоритма. Некоторые поддержали и выбор запасного алгоритма,
но не было согласовано, как это должно быть выполнено. Указанное выше мнение было
отражено в письменных комментариях, представленных в NIST многими из
присутствующих на конференции.
Перед тем как принять решение в пользу единственного алгоритма AES, были
рассмотрены все комментарии и аргументы. Остальные соответствующие FIPS алгоритмы
будут обеспечивать определенную степень надежности, единственный же AES-алгоритм
обеспечивает интероперабельность, способствует решению проблем интеллектуальной
собственности.
Запасной алгоритм
Как уже отмечалось, существует взаимосвязь между обсуждениями проблемы нескольких
алгоритмов AES и выбором запасного алгоритма, особенно в случае единственного
алгоритма AES. Backup может иметь несколько форм, от алгоритма, который требуется
реализовывать в продуктах AES ("cold backup"), до определяемого в AES запасного
алгоритма ("hot backup"). Было доказано, что запасной алгоритм во многом эквивалентен
437
второму AES-алгоритму, так как многие пользователи пожелают, чтобы даже "cold
backup" был реализован в продуктах.
Итак, имея

представления о том, что запасной алгоритм должен de facto требоваться в продуктах;

сомнения относительно потенциальной применимости в связи с возможными достижениями
криптоанализа;

заинтересованность NIST в обеспечении интероперабельности;

доступность в коммерческих продуктах других алгоритмов (как FIPS, так и не-FIPS);
было принято решение не выбирать запасной алгоритм.
Как и в случае с другими стандартами на криптографические алгоритмы, NIST продолжит
исследования в области криптоанализа AES-алгоритма, и стандарт будет
пересматриваться каждые пять лет. Если полученные результаты потребуют более
быстрой реакции, NIST будет действовать соответствующим образом и рассмотрит все
возможные альтернативы.
Профили финалистов
MARS
Общая безопасность
MARS не имеет известных атак безопасности.
В отличие от других финалистов, MARS использует в качестве нелинейных компонентов
зависящие от данных ротации и S-boxes. В силу нестандартной, разнородной структуры
раунда (16 раундов перемешивания и 16 раундов ядра) трудно оценить предоставляемый
MARS резерв безопасности. Данного финалиста критикуют за сложность, которая
затрудняет анализ его безопасности.
Программные реализации
Эффективность программных реализаций зависит от того, насколько хорошо комбинация
процессор/язык управляет операциями 32-битного умножения и переменной ротации. Это
может привести к различным вариациям между процессорами и между компиляторами
для данного процессора. По эффективности выполнения MARS принадлежит к среднему
диапазону для шифрования/дешифрования и для установления ключа.
Окружения с ограничениями пространства
MARS недостаточно соответствует окружениям с ограничениями пространства, т.к.
требует большого объема ROM. Причем следует отметить, что требования ROM имеют
тенденцию роста.
Аппаратные реализации
MARS имеет средние потребности. Его эффективность ниже средней. Скорость
реализации MARS зависит от используемой длины ключа.
Шифрование vs. дешифрование
438
Шифрование и дешифрование в MARS имеют аналогичные функции. Таким образом,
скорость MARS при шифровании и дешифровании существенно не изменяется.
Свойства ключа
MARS требует вычисления 10 из 40 подключей за один раз, требуя дополнительных
ресурсов для хранения этих 10 подключей. Это неудобно для окружений с ограниченной
памятью. MARS также требует однократного выполнения управления ключом для
создания всех подключей до первого дешифрования с конкретным ключом. Вычисление
нескольких подключей за один раз требует больше ресурсов памяти, чем при вычислении
подключей на лету.
Другие возможности настройки
MARS поддерживает длину ключа от 128 до 448 бит.
RC6
Общая безопасность
RC6 не имеет известных атак безопасности.
RC6 использует зависящие от данных ротации в качестве нелинейных компонентов. Его
резерв безопасности является адекватным. Аналитики высоко оценивают простоту RC6,
которая может способствовать анализу его безопасности. Предшественником RC6
является RC5, который также стал предметом тщательного анализа.
Программные реализации
Преобладающие операции в RC6 - умножение и переменные ротации. Программное
выполнение зависит от того, насколько хорошо комбинация процессор/язык обрабатывает
эти операции. RC6 является наиболее быстрым из финалистов на 32-битных платформах.
Однако его выполнение замедляется на 64-битных процессорах. Выполнение RC6
улучшается, если он используется в режиме, допускающем interleaving. Время
установления ключа признано средним.
Окружения с ограничениями пространства
RC6 имеет небольшие требования к ROM, что является преимуществом в окружениях с
ограничениями пространства. У RC6 при дешифровании отсутствует возможность
вычисления подключа на лету, что создает повышенные требования к RAM. Это не
вполне соответствует реализации в устройстве с существенными ограничениями на RAM,
если требуется дешифрование.
Аппаратные реализации
RC6 может быть эффективно реализован.
Шифрование vs. дешифрование
Шифрование и дешифрование в RC6 имеют аналогичные функции. Таким образом,
эффективность RC6 при шифровании и дешифровании существенно не отличается.
Свойства ключа
RC6 поддерживает возможность вычисления подключей на лету только для шифрования,
используя порядка 100 байтов для промежуточных значений. Подключи дешифрования
должны быть вычислены заранее.
Другие возможности настройки
439
Размеры блока, ключа и число раундов параметризуемы. RC6 поддерживает размер ключа
намного больше 256 бит.
Rijndael
Общая безопасность
Rijndael не имеет известных атак безопасности.
Rijndael использует S-boxes в качестве нелинейной компоненты. Rijndael демонстрирует
адекватный резерв безопасности, но подвергается критике из-за математической
структуры, которая может привести к атакам. С другой стороны, простая структура
облегчает анализ безопасности.
Программные реализации
Rijndael очень хорошо выполняет шифрование и дешифрование на различных
платформах, включая 8-битные и 64-битные платформы. Однако выполнение замедляется
с увеличением длины ключа, т.к. возрастает число раундов. Rijndael имеет возможность
параллельного выполнения, что позволяет эффективно использовать ресурсы процессора.
Время установления ключа в Rijndael небольшое.
Окружения с ограничениями пространства
В целом, Rijndael хорошо соответствует окружениям с ограничениями пространства, в
которых реализовано либо шифрование, либо дешифрование (но не оба одновременно).
Он имеет очень небольшие требования к RAM и ROM. Недостатком является то, что
требования ROM возрастают, если шифрование и дешифрование реализованы
одновременно, хотя он все равно остается подходящим для такого окружения. Управление
ключом для шифрования и дешифрования различается.
Аппаратные реализации
Rijndael имеет самую высокую производительность среди финалистов для feedback
режимов и является вторым по производительности для не-feedback режимов. Для 192- и
256-битных ключей производительность падает из-за дополнительного числа раундов.
Шифрование vs. дешифрование
В Rijndael функции шифрования и дешифрования различны. При этом скорости
шифрования и дешифрования существенно не отличаются, но установление ключа
выполняется медленнее для дешифрования, чем для шифрования.
Свойства ключа
Rijndael поддерживает для шифрования вычисление подключей на лету. Rijndael требует
однократного выполнения управления ключом для создания всех подключей до первого
дешифрования с конкретным ключом.
Другие возможности настройки
Rijndael полностью поддерживает размеры блока и размеры ключа в 128, 192 и 256 бит в
любой комбинации. В принципе, структуру Rijndael можно приспособить к любым
размерам блока и ключа, кратным 32, а также изменить число раундов.
Serpent
Общая безопасность
440
Serpent не имеет известных атак безопасности.
Serpent использует S-boxes в качестве нелинейных компонент. Serpent демонстрирует
значительный резерв безопасности и имеет простую структуру, которую легко
анализировать.
Программные реализации
Serpent является наиболее медленным из финалистов при программной реализации
шифрования и дешифрования.
Окружения с ограничениями пространства
Serpent хорошо соответствует оружениям с ограничениями пространства, включая низкие
требования к RAM и ROM. Недостатком является то, что требования к ROM возрастают,
если шифрование и дешифрование реализованы одновременно, но и при этом Serpent попрежнему соответствует окружениям с ограничениями пространства.
Аппаратные реализации
Конвейерные реализации Serpent показывают самую высокую среди финалистов
производительность для не-feedback режимов. Serpent занимает второе место по
производительности в feedback режиме для основной архитектуры. Скорость выполнения
Serpent не зависит от длины ключа.
Шифрование vs. дешифрование
Шифрование и дешифрование в Serpent имеют различные функции, которые разделяют
ограниченные ресурсы. Одновременная реализация как шифрования, так и дешифрования
требует пространства приблизительно в два раза больше, чем необходимо отдельно для
шифрования. Это является недостатком, когда в аппаратуре нужно одновременно
реализовать обе функции.
Скорость выполнения Serpent при шифровании и дешифровании отличается
несущественно.
Свойства ключа
Serpent поддерживает для шифрования и дешифрования возможность вычисления
подключей на лету. Для дешифрования необходимо единственное вычисление для
получения первого подключа дешифрования из исходного ключа. Это вычисление
отличается от преобразования, которое используется для остальных подключей.
Другие возможности настройки
Serpent может обрабатывать любую длину ключа более 256 бит. Кроме того, для
улучшения выполнения может использоваться технология bitslice на 32-битных
процессорах.
Twofish
Общая безопасность
Twofish не имеет известных атак безопасности.
Twofish использует S-boxes в качестве нелинейных компонент. Демонстрирует высокий
резерв безопасности, но вызвала критические замечания за свойство разделения ключа и
за сложность, которая затрудняет анализ безопасности.
441
Программные реализации
Twofish показывает смешанные результаты при выполнении шифрования и
дешифрования. Установление ключа происходит медленно. Время выполнения
шифрования/дешифрования или установления ключа уменьшаются для большей длины
ключа, в зависимости от используемой опции ключа.
Окружения с ограничениями пространства
Требования RAM и ROM соответствуют окружениям с ограничениями пространства.
Аппаратные реализации
Производительность и эффективность на основной аппаратуре являются средними.
Возможны компактные реализации.
Шифрование vs. дешифрование
Шифрование и дешифрование в Twofish имеют идентичные функции. Таким образом,
эффективность Twofish при шифровании и дешифровании не отличается. Одновременная
реализация шифрования и дешифрования всего на 10 % увеличивает объем пространства
по сравнению с реализацией одного только шифрования.
Свойства ключа
Twofish поддерживает вычисление подключей на лету как для шифрования, так и для
дешифрования.
Другие возможности настройки
Спецификация Twofish описывает четыре опции для реализации зависимых от ключа Sboxes, позволяя варьировать выполнение. Twofish поддерживает произвольную длину
ключа более 256 бит.
Заключительные оценки финалистов
Как уже не раз отмечалось, безопасность считается самым важным свойством при оценке
финалистов. Так как многие из оставшихся результатов анализа часто охватывают как
стоимость, так и характеристики алгоритма, было принято решение рассматривать эти
факторы вместе в качестве второго после безопасности свойства.
Общая безопасность
На основании выполненного анализа безопасности можно утверждать, что не существует
известных атак безопасности ни на одного из финалистов, и все пять финалистов
проявили необходимый для AES уровень безопасности. В терминах резерва безопасности
MARS, Serpent и Twofish показали самый высокий резерв безопасности, хотя резерв RC6 и
Rijndael также можно назвать адекватным. Ряд критических замечаний вызвала
математическая структура Rijndael и свойство разделения ключа Twofish; однако это не
приводит к атакам.
Программные реализации
RC6 и Rijndael демонстрируют скорость шифрования и дешифрования выше средней для
128-битных ключей, при этом RC6 имеет особенно хорошие показатели на 32-битных
платформах, а Rijndael выполняется более ровно на всех платформах. MARS имеет
442
среднее выполнение шифрования и дешифрования на всех платформах, в зависимости от
того, выполняет ли процессор 32-битные умножения и переменные ротации. Twofish
демонстрирует смешанные результаты среди различных платформ для шифрования и
дешифрования, но в целом имеет средние показатели по сравнению с другими
финалистами. Serpent при шифровании и дешифровании несколько медленнее остальных
финалистов.
Установление ключа Rijndael выполняет быстрее всех. Для MARS, RC6 и Serpent этот
показатель является средним, а Twofish здесь на последнем месте.
MARS, RC6 и Serpent демонстрируют одинаковое выполнение шифрования и
дешифрования для всех трех длин ключа. Выполнение шифрования и дешифрования
Rijndael возрастает с увеличением длины ключа из-за увеличения числа раундов.
Выполнение шифрования/дешифрования или установления ключа Twofish уменьшается
при большей длине ключа в зависимости от используемых опций ключа.
RC6 является лучшим среди финалистов, если использует режим, обеспечивающий
interleaving.
Окружения с ограничениями пространства
Rijndael предъявляет очень низкие требования к RAM и ROM и отлично соответствует
окружениям с ограничениями пространства, если реализовано либо шифрование, либо
дешифрование. Недостаток его в том, что требования к ROM возрастают, если как
шифрование, так и дешифрование реализованы одновременно, хотя и в этом случае
Rijndael остается соответствующим окружению с ограничениями пространства.
Serpent имеет низкие требования к RAM и ROM и очень хорошо соответствует
окружениям с ограничениями пространства, когда реализовано либо шифрование, либо
дешифрование. Как и у Rijndael, у Serpent требования к ROM возрастают, если
шифрование и дешифрование реализованы одновременно, но, тем не менее, алгоритм
остается соответствующим окружениям с ограничениями пространства.
Требования RAM и ROM Twofish соответствуют окружениям с ограничениями
пространства.
RC6 имеет небольшие требования к ROM, что является преимуществом в окружениях с
ограничениями пространства. Однако алгоритм не допускает возможности вычисления
подключей на лету при дешифровании, увеличивая тем самым требования к RAM
относительно других финалистов. Следовательно, RC6 недостаточно хорошо
соответствует реализации в устройствах с существенными ограничениями доступной
RAM, если требуется шифрование.
MARS недостаточно соответствует окружению с ограничениями пространства вследствие
требований к ROM, самых высоких среди финалистов. Кроме того, управление ключом
MARS включает операции сравнения с образцом, которые требуют дополнительных
ресурсов.
Аппаратные реализации
443
Serpent и Rijndael имеют лучшую аппаратную производительность среди финалистов как
для режимов feedback, так и для других. Serpent демонстрирует самую высокую
производительность среди финалистов в не-feedback режимах, и его эффективность
(производительность/пространство) обычно очень высокая. Rijndael показал лучшую
производительность среди финалистов в feedback-режимах. При большей длине ключа
производительность Rijndael падает. Эффективность Rijndael также обычно заслуживает
самой высокой оценки.
RC6 и Twofish обычно проявляют среднюю производительность. Производительность
RC6 возрастает в не-feedback режимах. Производительность Twofish иногда понижается
при больших размерах ключа. MARS имеет средние требования к памяти, его
производительность выше средней, и эффективность также.
Шифрование vs. дешифрование
Twofish, MARS и RC6 нуждаются в небольшом дополнительном пространстве для
одновременной реализации в аппаратуре как шифрования, так и дешифрования в
противоположность реализации одного только шифрования. Функции шифрования и
дешифрования для Twofish почти не отличаются , а для MARS и RC6 являются
аналогичными.
Шифрование и дешифрование Rijndael отличаются больше, чем у Twofish, MARS и RC6,
хотя Rijndael может быть реализован таким способом, чтобы разделять некоторые
аппаратные ресурсы.
Для Serpent функции шифрования и дешифрования отличаются, что позволяет разделять
только очень ограниченные аппаратные ресурсы.
Все финалисты показывают очень небольшие различия в скорости между шифрованием и
дешифрованием для данной длины ключа. Установление ключа Rijndael для
дешифрования выполняется медленнее, чем для шифрования.
Свойства ключа
Twofish поддерживает вычисление подключей на лету как для шифрования, так и для
дешифрования. О Serpent можно сказать то же самое, однако процесс дешифрования
требует одного дополнительного вычисления. Rijndael поддерживает вычисление
подключей на лету для шифрования, но требует вычисления за один раз всего управления
ключом до выполнения первого дешифрования. MARS имеет характеристики,
аналогичные Rijndael, за исключением того, что 10 ключей должны вычисляться и
храниться одновременно. Их размещение требует дополнительных ресурсов при
реализации MARS. RC6 поддерживает вычисление ключей на лету только для
шифрования, создавая при этом промежуточные значения.
Другие возможности настройки
MARS поддерживает длину ключа в диапазоне от 128 до 448 бит.
444
RC6 имеет параметризуемые размеры блока и ключа и параметризуемое число раундов,
включая поддержку размеров ключа более 256 бит.
Rijndael поддерживает дополнительные размеры блока и ключа с приращением в 32 бита,
число раундов также может быть изменено.
Serpent поддерживает любую длину ключа более 256 бит, и bitslice-реализация может
обеспечить его выполнение на многих процессорах.
Twofish поддерживает произвольный размер ключа более 256 бит, и спецификация
алгоритма предлагает дополнительно четыре опции.
Заключение
Каждый из финалистов показал адекватную безопасность, имеет определенные
преимущества, и каждый может использоваться в качестве AES. Но в то же время каждый
из алгоритмов в одной или нескольких областях уступает другим; ни один из финалистов
не является абсолютным лидером.
В качестве предлагаемого AES алгоритма в результате длительного и сложного процесса
оценки специалисты NIST выбрали Rijndael.
Rijndael очень хорошо выполняется как в программной, так и в аппаратной реализации в
широком диапазоне окружений независимо от использования feedback или не-feedback
режимов. Он показал отличное время установления ключа и хорошие свойства ключа.
Rijndael имеет небольшие требования к памяти, что делает его пригодным для окружений
с ограниченными ресурсами. В этом случае он также демонстрирует отличное
выполнение.
23.Средства языка UML для описания поведения моделируемой системы.
445
 Модели поведения (behavioral):

диаграммы вариантов использования (use case diagrams) - для моделирования
функциональных требований к системе (в виде сценариев взаимодействия
пользователей с системой);
Диаграммы вариантов использования показывают взаимодействия между вариантами
использования и действующими лицами, отражая функциональные требования к системе
с точки зрения пользователя. Цель построения диаграмм вариантов использования - это
документирование функциональных требований в самом общем виде, поэтому они
должны быть предельно простыми.
Вариант использования представляет собой последовательность действий (транзакций),
выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом
(действующим лицом). Вариант использования описывает типичное взаимодействие
между пользователем и системой и отражает представление о поведении системы с точки
зрения пользователя. В простейшем случае вариант использования определяется в
процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать, или
целей, которые он преследует по отношению к разрабатываемой системе.
Диаграмма вариантов использования является самым общим представлением
функциональных требований к системе. Для последующего проектирования системы
требуются более конкретные детали, которые описываются в документе, называемом
"сценарием варианта использования" или "потоком событий" (flow of events). Сценарий
подробно документирует процесс взаимодействия действующего лица с системой,
реализуемого в рамках варианта использования [11]. Основной поток событий описывает
нормальный ход событий (при отсутствии ошибок). Альтернативные потоки описывают
отклонения от нормального хода событий (ошибочные ситуации) и их обработку.
Достоинства модели вариантов использования заключаются в том, что она:

определяет пользователей и границы системы;

определяет системный интерфейс;

удобна для общения пользователей с разработчиками;

используется для написания тестов;

является основой для написания пользовательской документации;

хорошо вписывается в любые методы проектирования (как объектноориентированные, так и структурные).

диаграммы взаимодействия (interaction diagrams):
Диаграммы взаимодействия описывают поведение взаимодействующих групп
объектов (в рамках варианта использования или некоторой операции класса). Как
правило, диаграмма взаимодействия охватывает поведение объектов в рамках только
одного потока событий варианта использования. На такой диаграмме отображается
446
ряд объектов и те сообщения, которыми они обмениваются между собой. Существует
два вида диаграмм взаимодействия: диаграммы последовательности и кооперативные
диаграммы.
o
диаграммы последовательности (sequence diagrams) и кооперативные
диаграммы (collaboration diagrams) - для моделирования процесса обмена
сообщениями между объектами;
Диаграммы последовательности отражают временную последовательность событий,
происходящих в рамках варианта использования, а кооперативные диаграммы
концентрируют внимание на связях между объектами. Диаграмма последовательности
(sequence diagram) - диаграмма, на которой показаны взаимодействия объектов,
упорядоченные по времени их проявления.
Особенности взаимодействия элементов моделируемой системы могут быть представлены
на диаграммах кооперации и последовательности. Диаграммы кооперации используются
для спецификации динамики поведения систем, хотя время в явном виде в них
отсутствует. Однако временной аспект поведения может иметь существенное значение
при моделировании синхронных процессов, описывающих взаимодействие объектов.
Именно для этой цели в языке UML используются диаграммы последовательности,
которые и станут предметом изучения в настоящей лекции.
На диаграмме последовательности неявно присутствует ось времени, что позволяет
визуализировать временные отношения между передаваемыми сообщениями. С помощью
диаграммы последовательности можно представить взаимодействие элементов модели как
своеобразный временной график "жизни" всей совокупности объектов, связанных между
собой для реализации варианта использования программной системы, достижения бизнесцели или выполнения какой-либо задачи.
Объекты и их изображение на диаграмме последовательности
На диаграмме последовательности также изображаются объекты, которые
непосредственно участвуют во взаимодействии, при этом никакие статические связи с
другими объектами не визуализируются. Для диаграммы последовательности ключевым
моментом является именно динамика взаимодействия объектов во времени. При этом
диаграмма последовательности имеет как бы два измерения. Одно - слева направо в виде
вертикальных линий, каждая из которых изображает линию жизни отдельного объекта,
участвующего во взаимодействии. Второе измерение диаграммы последовательности вертикальная временная ось, направленная сверху вниз.
Каждый объект графически изображается в форме прямоугольника и располагается в
верхней части своей линии жизни (рис. 8.1). Внутри прямоугольника записываются
собственное имя объекта со строчной буквы и имя класса, разделенные двоеточием. При
этом вся запись подчеркивается, что является признаком объекта, который, как
указывалось ранее, представляет собой экземпляр класса.
Для объектов диаграммы последовательности остаются справедливыми правила
именования, рассмотренные ранее применительно к диаграммам кооперации. Если на
447
диаграмме последовательности отсутствует собственное имя объекта, то при этом должно
быть указано имя класса. Такой объект считается анонимным. Может отсутствовать и
имя класса, но при этом должно быть указано собственное имя объекта. Такой объект
считается сиротой. Роль классов в именах объектов на диаграммах последовательности,
как правило, не указывается.
Крайним слева на диаграмме изображается объект - инициатор моделируемого процесса
взаимодействия (объект a на рис. 8.1). Правее - другой объект, который непосредственно
взаимодействует с первым. Таким образом, порядок расположения объектов на диаграмме
последовательности определяется исключительно соображениями удобства визуализации
их взаимодействия друг с другом.
Рис. 8.1. Графические элементы диаграммы последовательности
Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом
процесс взаимодействия объектов реализуется посредством сообщений, которые
посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных
стрелок с именем сообщения и образуют определенный порядок относительно времени
своей инициализации. Другими словами, сообщения, расположенные на диаграмме
последовательности выше, передаются раньше тех, которые расположены ниже. При этом
масштаб на оси времени не указывается, поскольку диаграмма последовательности
моделирует лишь временную упорядоченность взаимодействий типа "раньше-позже".
Линия жизни объекта (object lifeline) - вертикальная линия на диаграмме
последовательности, которая представляет существование объекта в течение
определенного периода времени.
Линия жизни объекта изображается пунктирной вертикальной линией, ассоциированной с
единственным объектом на диаграмме последовательности. Линия жизни служит для
обозначения периода времени, в течение которого объект существует в системе и,
следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект
существует в системе постоянно, то и его линия жизни должна продолжаться по всей
448
рабочей области диаграммы последовательности от самой верхней ее части до самой
нижней (объект 1 и анонимный объект Класса 2 на рис. 8.1).
Отдельные объекты, закончив выполнение своих операций, могут быть уничтожены ,
чтобы освободить занимаемые ими ресурсы. Для таких объектов линия жизни обрывается
в момент его уничтожения. Для обозначения момента уничтожения объекта в языке UML
применяется специальный символ в форме латинской буквы "X". На рис. 8.2 этот символ
используется для уничтожения анонимного объекта, образованного от Класса 3 . Ниже
этого символа пунктирная линия не изображается, поскольку соответствующего объекта в
системе уже нет, и этот объект должен быть исключен из всех последующих
взаимодействий
Рис. 8.2. Графическое изображение линий жизни и фокусов управления объектов
Вовсе не обязательно создавать все объекты в начальный момент времени. Отдельные
объекты в системе могут создаваться по мере необходимости, существенно экономя
ресурсы системы и повышая ее производительность. В этом случае прямоугольник такого
объекта изображается не в верхней части диаграммы последовательности, а в той, которая
соответствует моменту создания объекта (анонимный объект, образованный от Класса 3
на рис. 8.2). При этом прямоугольник объекта вертикально располагается в том месте
диаграммы, которое по оси времени совпадает с моментом его возникновения в системе.
Объект создается со своей линией жизни а, возможно, и с фокусом управления.
В процессе функционирования объектно-ориентированных систем одни объекты могут
находиться в активном состоянии, непосредственно выполняя определенные действия,
или в состоянии пассивного ожидания сообщений от других объектов. Фокус управления символ, применяемый для того, чтобы явно выделить подобную активность объектов на
диаграммах последовательности.
Фокус управления (focus of control) - специальный символ на диаграмме
последовательности, указывающий период времени, в течение которого объект выполняет
некоторое действие, находясь в активном состоянии.
Фокус управления изображается в форме вытянутого узкого прямоугольника (объект а на
рис. 8.1), верхняя сторона которого обозначает начало получения фокуса управления
449
объекта (начало активности), а ее нижняя сторона - окончание фокуса управления
(окончание активности). Этот прямоугольник располагается ниже обозначения
соответствующего объекта и может заменять его линию жизни (объект a на рис. 8.2), если
на всем ее протяжении он активен.
Периоды активности объекта могут чередоваться с периодами его пассивности или
ожидания. В этом случае у такого объекта фокусы управления изменяют свое
изображение на линию жизни и наоборот (объект сирота ob2 на рис. 8.2). Важно
понимать, что получить фокус управления может только объект, у которого в этот момент
имеется линия жизни. Если же объект был уничтожен, то вновь возникнуть в системе он
уже не может. Вместо него может быть создан лишь экземпляр этого же класса, который,
строго говоря, будет другим объектом.
В отдельных случаях инициатором взаимодействия в системе может быть актер или
внешний пользователь. При этом актер изображается на диаграмме последовательности
самым первым объектом слева со своим фокусом управления (рис. 8.3). Наиболее часто
актер и его фокус управления будут существовать в системе постоянно, отмечая
характерную для пользователя активность в инициировании взаимодействий с системой.
Актер может иметь собственное имя либо оставаться анонимным.
В отдельных случаях объект может посылать сообщения самому себе, инициируя так
называемые рефлексивные сообщения. Для этой цели служит специальное изображение
(сообщение у объекта а на рис. 8.3). Такие сообщения изображаются в форме сообщения,
начало и конец которого соприкасаются с линией жизни или фокусом управления одного
и того же объекта. Подобные ситуации возникают, например, при обработке нажатий на
клавиши клавиатуры при вводе текста в редактируемый документ, при наборе цифр
номера телефона абонента.
Если в результате рефлексивного сообщения создается новый подпроцесс или нить
управления, то говорят о рекурсивном или вложенном фокусе управления. На диаграмме
последовательности рекурсия обозначается небольшим прямоугольником,
присоединенным к правой стороне фокуса управления того объекта, для которого
изображается данное рекурсивное взаимодействие (анонимный объект Класса 2 на рис.
8.3).
Рис. 8.3. Графическое изображение актера, рефлексивного сообщения и рекурсии на диаграмме
последовательности
450
Сообщения на диаграмме последовательности
Сообщения как элементы языка UML, уже рассматривались ранее при изучении
диаграммы кооперации (лекция 7). Стрелки сообщений изображаются аналогично
рассмотренным ранее, но применительно к диаграммам последовательности сообщения
имеют дополнительные семантические особенности. При этом на диаграмме
последовательности все сообщения упорядочены по времени своей передачи в
моделируемой системе, хотя номера у них могут не указываться.
На диаграммах последовательности могут присутствовать три разновидности сообщений,
каждое из которых имеет свое графическое изображение (рис. 8.4).
Рис. 8.4. Графическое изображение различных видов сообщений между объектами на диаграмме
последовательности
Первая разновидность сообщения (рис. 8.4, а) наиболее распространена и используется
для вызова процедур, выполнения операций или обозначения отдельных вложенных
потоков управления. Начало этой стрелки, как правило, соприкасается с фокусом
управления того объекта-клиента, который инициирует это сообщение. Конец стрелки
соприкасается с линией жизни того объекта, который принимает это сообщение и
выполняет в ответ определенные действия. При этом принимающий объект может
получить фокус управления, становясь в этом случае активным. Передающий объект
может потерять фокус управления или остаться активным.
Вторая разновидность сообщения (рис. 8.4, б) используется для обозначения простого
асинхронного сообщения, которое передается в произвольный момент времени. Передача
такого сообщения обычно не сопровождается получением фокуса управления объектомполучателем.
Третья разновидность сообщения (рис. 8.4, в) используется для возврата из вызова
процедуры. Примером может служить простое сообщение о завершении вычислений без
предоставления результата расчетов объекту-клиенту. В процедурных потоках управления
эта стрелка может быть опущена, поскольку ее наличие неявно предполагается в конце
активизации объекта. В то же время считается, что каждый вызов процедуры имеет свою
пару - возврат вызова. Для непроцедурных потоков управления, включая параллельные и
асинхронные сообщения, стрелка возврата должна указываться явным образом.
Обычно сообщения изображаются горизонтальными стрелками, соединяющими линии
жизни или фокусы управления двух объектов на диаграмме последовательности. При этом
неявно предполагается, что время передачи сообщения достаточно мало по сравнению с
процессами выполнения действий объектами. Считается также, что за время передачи
сообщения с соответствующими объектами не может произойти никаких событий.
Другими словами, состояния объектов не изменяются. Если же это предположение не
может быть признано справедливым, то стрелка сообщения изображается под наклоном,
так чтобы конец стрелки располагался ниже ее начала.
Каждое сообщение на диаграмме последовательности ассоциируется с определенной
операцией, которая должна быть выполнена принявшим его объектом. При этом операция
может иметь аргументы или параметры, значения которых влияют на получение
451
различных результатов. Соответствующие параметры операции будет иметь и
вызывающее это действие сообщение. Более того, значения параметров отдельных
сообщений могут содержать условные выражения, образуя ветвление или альтернативные
пути основного потока управления.
Ветвление потока управления
Одна из особенностей диаграммы последовательности - возможность визуализировать
простое ветвление процесса. Для изображения ветвления используются две или более
стрелки, выходящие из одной точки фокуса управления объекта (объект ob1 на рис. 8.5).
При этом рядом с каждой из них должно быть явно указано соответствующее условие
ветви в форме булевского выражения.
Количество ветвей может быть произвольным, однако наличие ветвлений может
существенно усложнить интерпретацию диаграммы последовательности. Предложениеусловие должно быть явно указано для каждой ветви и записывается в форме обычного
текста, псевдокода или выражения языка программирования. Это выражение всегда
должно возвращать некоторое булевское выражение. Запись этих условий должна
исключать одновременную передачу альтернативных сообщений по двум и более ветвям.
В противном случае на диаграмме последовательности может возникнуть конфликт
ветвления.
Рис. 8.5. Графическое изображение бинарного ветвления потока управления на диаграмме
последовательности
С помощью ветвления можно изобразить и более сложную логику взаимодействия
объектов между собой (объект ob1 на рис. 8.6). Если условий более двух, то для каждого
из них необходимо предусмотреть ситуацию единственного выполнения. Описанный
ниже пример относится к моделированию взаимодействия программной системы
обслуживания клиентов в банке. В этом примере диаграммы последовательности объект
ob1 вызывает выполнение действий у одного из трех других объектов.
Условием ветвления может служить сумма снимаемых клиентом средств со своего
текущего счета. Если эта сумма превышает 1500$, то могут потребоваться
дополнительные действия, связанные с созданием и последующим разрушением объекта
Класса 1. Если же сумма превышает 100$, но не превышает 1500$, то вызывается
операция или процедура объекта ob3. И, наконец, если сумма не превышает 100$, то
452
вызывается операция или процедура объекта ob2. При этом объекты ob1, ob2 и ob3
постоянно существуют в системе. Последний объект создается от Класса 1 только в том
случае, если справедливо первое из альтернативных условий. В противном случае он
может быть никогда не создан.
Рис. 8.6. Графическое изображение тернарного ветвления потока управления на диаграмме
последовательности
Объект ob1 имеет постоянный фокус управления, а все остальные объекты - получают
фокус управления только для выполнения ими соответствующих операций.
На диаграммах последовательности при записи сообщений также могут использоваться
стереотипы, рассмотренные ранее при построении диаграммы кооперации (лекция 7). Их
семантика и синтаксис остаются без изменения, как они определены в нотации языка
UML. Ниже представлена диаграмма последовательности для описанного выше случая
ветвления, дополненная стереотипными значениями отдельных сообщений (рис. 8.7).
Очевидно, эта диаграмма последовательности является более выразительной и простой
для своей содержательной интерпретации.
Рис. 8.7. Диаграмма последовательности со стереотипными значениями сообщений
453
Как уже отмечалось ранее, сообщения могут иметь собственное имя, в качестве которого
выступает имя операции, вызов которой инициируют эти сообщения у принимающего
объекта. В этом случае рядом со стрелкой записывается имя операции с круглыми
скобками, в которых могут указываться параметры или аргументы соответствующей
операции. Если параметры отсутствуют, то скобки после имени операции все равно
должны быть изображены.
Рекомендации по построению диаграмм последовательности
Построение диаграммы последовательности целесообразно начинать с выделения из всей
совокупности классов только тех, объекты которых участвуют в моделируемом
взаимодействии. После этого все объекты наносятся на диаграмму, с соблюдением
порядка инициализации сообщений. Здесь необходимо установить, какие объекты будут
существовать постоянно, а какие временно - только на период выполнения ими требуемых
действий.
Когда объекты визуализированы, можно приступать к спецификации сообщений. При
этом необходимо учитывать те операции, которые имеют классы соответствующих
объектов в модели системы. При необходимости уточнения этих операций следует
использовать их стереотипы. Для уничтожения объектов, которые создаются на время
выполнения своих действий, нужно предусмотреть явное сообщение. Наиболее простые
случаи ветвления процесса взаимодействия можно изобразить на одной диаграмме с
использованием соответствующих графических примитивов. В более сложных случаях
для моделирования каждой ветви управления может потребоваться отдельная диаграмма
последовательности. Следует помнить, что каждый альтернативный поток управления
затрудняет понимание построенной модели.
Общим правилом является визуализация особенностей реализации каждого варианта
использования на отдельной диаграмме последовательности. В этой ситуации отдельные
диаграммы должны рассматриваться совместно как одна модель взаимодействия.
Необходимость синхронизации сложных потоков управления, как правило, требуют
введение в модель дополнительных ограничений. При этом общая запись таких
ограничений должна следовать семантике языка объектных ограничений OCL.

диаграммы состояний (statechart diagrams) - для моделирования поведения объектов
системы при переходе из одного состояния в другое;
Диаграммы состояний определяют все возможные состояния, в которых
может находиться конкретный объект, а также процесс смены состояний
объекта в результате наступления некоторых событий. Диаграммы
состояний не надо создавать для каждого класса, они применяются
только в сложных случаях. Если объект класса может существовать в
нескольких состояниях и в каждом из них ведет себя по-разному, для
454
него может потребоваться такая диаграмма. Диаграмма состояний в
контексте конечного автомата
Для систем различной природы и назначения характерно взаимодействие между собой
отдельных образующих их элементов. Для представления динамических особенностей
взаимодействия элементов модели в контексте реализации вариантов использования
предназначены диаграммы кооперации и последовательности. Однако для моделирования
процессов функционирования большинства сложных систем, особенно систем реального
времени, этих представлений недостаточно.
Диаграмма состояний (statechart diagram) - диаграмма, которая представляет конечный
автомат.
Семантика понятия состояния довольно сложна. Дело в том, что характеристика
состояний системы явным образом не зависит от логической структуры, зафиксированной
на диаграмме классов. При рассмотрении состояний системы приходится отвлекаться от
особенностей ее объектной структуры и мыслить категориями, описывающими
динамический контекст поведения моделируемой системы. При построении диаграмм
состояний необходимо использовать специальные понятия, о которых и пойдет речь в
данной лекции.
Ранее отмечалось, что любая прикладная система характеризуется не только структурой
составляющих ее элементов, но и некоторым поведением или функциональностью. Для
общего представления функциональности моделируемой системы предназначены
диаграммы вариантов использования, которые на концептуальном уровне описывают
поведение системы в целом. Для того чтобы представить наиболее общее поведение на
логическом уровне, следует ответить на вопрос: "В процессе какого поведения система
реализует необходимую пользователям функциональность?".
Главное назначение диаграммы состояний - описать возможные последовательности
состояний и переходов, которые в совокупности характеризуют поведение моделируемой
системы в течение всего ее жизненного цикла. Диаграмма состояний представляет
динамическое поведение сущностей, на основе спецификации их реакции на восприятие
некоторых конкретных событий. Системы, которые реагируют на внешние действия от
других систем или от пользователей, иногда называют реактивными. Если такие действия
инициируются в произвольные случайные моменты времени, то говорят об асинхронном
поведении модели.
Диаграммы состояний чаще всего используются для описания поведения отдельных
систем и подсистем. Они также могут быть применены для спецификации
функциональности экземпляров отдельных классов, т. е. для моделирования всех
возможных изменений состояний конкретных объектов. Диаграмма состояний по
существу является графом специального вида, который служит для представления
конечного автомата.
Диаграммы состояний могут быть вложены друг в друга, образуя вложенные диаграммы
для более детального представления состояний отдельных элементов модели. Для
понимания семантики конкретной диаграммы состояний необходимо представлять
455
особенности поведения моделируемой сущности, а также иметь общие сведения из теории
конечных автоматов.
Конечный автомат (state machine) - модель для спецификации поведения объекта в форме
последовательности его состояний, которые описывают реакцию объекта на внешние
события, выполнение объектом действий, а также изменение его отдельных свойств.
В контексте языка UML понятие конечного автомата обладает дополнительной
семантикой. Вершинами графа конечного автомата являются состояния и другие типы
элементов модели, которые изображаются соответствующими графическими символами.
Дуги графа служат для обозначения переходов из состояния в состояние. Конечный
автомат описывает поведение отдельного объекта в форме последовательности состояний,
охватывающих все этапы его жизненного цикла, начиная от создания объекта и
заканчивая его уничтожением. Каждая диаграмма состояний представляет собой
конечный автомат.
Основными понятиями, характеризующими конечный автомат, являются состояние и
переход. Ключевое различие между ними заключается в том, что длительность
нахождения системы в отдельном состоянии существенно превышает время, которое
затрачивается на переход из одного состояния в другое. Предполагается, что в пределе
время перехода из одного состояния в другое равно нулю (если дополнительно ничего не
сказано). Другими словами, переход объекта из состояния в состояние происходит
мгновенно.
В общем случае конечный автомат представляет динамические аспекты моделируемой
системы в виде ориентированного графа, вершины которого соответствуют состояниям, а
дуги - переходам. При этом поведение моделируется как последовательное перемещение
по графу состояний от вершины к вершине по связывающим их дугам с учетом их
ориентации. Для графа состояний системы можно ввести в рассмотрение специальные
свойства.
Среди таких свойств - выделение из всей совокупности состояний двух специальных:
начального и конечного. Ни в графе состояний, ни на диаграмме состояний время
нахождения системы в том или ином состоянии явно не учитывается, однако
предполагается, что последовательность изменения состояний упорядочена во времени.
Другими словами, каждое последующее состояние может наступить позже
предшествующего ему состояния.
Состояние и его графическое изображение
Моделирование поведения объектов и системы в целом основывается на понятии
состояния.
Состояние (state) - условие или ситуация в ходе жизненного цикла объекта, в течение
которого он удовлетворяет логическому условию, выполняет определенную
деятельность или ожидает события.
Состояние может быть задано в виде набора конкретных значений атрибутов объекта
некоторого класса, при этом изменение отдельных значений этих атрибутов будет
отражать изменение состояния моделируемого объекта или системы в целом. Однако не
456
каждый атрибут класса может характеризовать состояние его объектов. Как правило,
имеют значение только те свойства элементов системы, которые отражают динамический
или функциональный аспект ее поведения. В этом случае состояние будет
характеризоваться некоторым инвариантным условием, включающим в себя только
принципиальные для поведения объекта или системы атрибуты классов и их значения.
Такое условие может соответствовать ситуации, когда моделируемый объект находится в
состоянии ожидания возникновения внешнего события. В то же время нахождение
объекта в некотором состоянии может быть связано с выполнением определенных
действий. В последнем случае соответствующая деятельность начинается в момент
перехода моделируемого элемента в рассматриваемое состояние, а после и элемент может
покинуть данное состояние в момент завершения этой деятельности.
Состояние на диаграмме изображается прямоугольником со скругленными вершинами
(рис. 9.1). Этот прямоугольник, в свою очередь, может быть разделен на две секции
горизонтальной линией. Если указана лишь одна секция, то в ней записывается только
имя состояния (рис. 9.1, а). В противном случае в первой из них записывается имя
состояния, а во второй - список некоторых внутренних действий или переходов в данном
состоянии (рис. 9.1, б). При этом под действием в языке UML понимают некоторую
атомарную операцию, выполнение которой приводит к изменению состояния или
возврату некоторого значения (например, "истина" или "ложь").
Рис. 9.1. Графическое изображение состояний на диаграмме состояний
Имя состояния представляет собой строку текста, которая раскрывает содержательный
смысл или семантику данного состояния. Имя должно представлять собой законченное
предложение и всегда записываться с заглавной буквы. Поскольку состояние системы
является частью процесса ее функционирования, рекомендуется в качестве имени
использовать глаголы в настоящем времени или соответствующие причастия. Как
исключение, имя у состояния может отсутствовать, т. е. оно необязательно для некоторых
состояний. В этом случае состояние является анонимным. Если на одной диаграмме
состояний несколько анонимных состояний, то все они должны различаться между собой.
Действие (action) - спецификация выполнимого утверждения, которая образует
абстракцию вычислительной процедуры.
Действие обычно приводит к изменению состояния системы, и может быть реализовано
посредством передачи сообщения объекту, модификацией связи или значения атрибута.
Для ряда состояний может потребоваться дополнительно указать действия, которые
должны быть выполнены моделируемым элементом. Для этой цели служит добавочная
457
секция в обозначении состояния, содержащая перечень внутренних действий или
деятельность, которые производятся в процессе нахождения моделируемого элемента в
данном состоянии. Каждое действие записывается в виде отдельной строки и имеет
следующий формат:
<метка действия '/ ' выражение действия>
Метка действия указывает на обстоятельства или условия, при которых будет
выполняться деятельность, определенная выражением действия. При этом выражение
действия может использовать любые атрибуты и связи, принадлежащие области имен или
контексту моделируемого объекта. Если список выражений действия пустой, то метка
действия с разделителем в виде наклонной черты '/' не указывается. Перечень меток
действий в языке UML фиксирован, причем эти метки не могут быть использованы в
качестве имен событий:
Входное действие (entry action) - действие, которое выполняется в момент перехода в
данное состояние.
Обозначается с помощью ключевого слова - метки действия entry, которое указывает на
то, что следующее за ней выражение действия должно быть выполнено в момент входа в
данное состояние.
Действие выхода (exit action) - действие, производимое при выходе из данного состояния.
Обозначается с помощью ключевого слова - метки действия exit, которое указывает на то,
что следующее за ней выражение действия должно быть выполнено в момент выхода из
данного состояния.
Внутренняя деятельность (do activity) - выполнение объектом операций или
процедур, которые требуют определенного времени.
Обозначается с помощью ключевого слова - метки деятельности do, которое
специфицирует так называемую "ду-деятельность", выполняемую в течение всего
времени, пока объект находится в данном состоянии, или до тех пор, пока не будет
прервано внешним событием. При нормальном завершении внутренней деятельности
генерируется соответствующее событие.
Во всех остальных случаях метка действия идентифицирует событие, которое запускает
соответствующее выражение действия. Эти события называются внутренними
переходами. Семантически они эквивалентны переходам в само это состояние, за
исключением той особенности, что выход из этого состояния или повторный вход в него
не происходит. Это означает, что действия входа и выхода не производятся. При этом
выполнение внутренних действий в состоянии не может быть прервано никакими
внешними событиями, в отличие от внутренней деятельности, выполнение которой
требует определенного времени.
В качестве примера состояния можно рассмотреть аутентификацию клиента для доступа к
ресурсам моделируемой информационной системы (рис. 9.2). Список внутренних
действий в данном состоянии может включать следующие действия. Первое действие входное, которое выполняется при входе в это состояние и связано с получением строки
символов, соответствующих паролю клиента. Далее выполняется деятельность по
458
проверке введенного клиентом пароля. При успешном завершении этой проверки
выполняется действие на выходе, которое отображает меню доступных для клиента
опций.
Рис. 9.2. Пример состояния с непустой секцией внутренних действий
Кроме обычных состояний на диаграмме состояний могут размещаться псевдосостояния.
Псевдосостояние (pseudo-state) - вершина в конечном автомате, которая имеет форму
состояния, но не обладает поведением.
Примерами псевдосостояний, которые определены в языке UML, являются начальное и
конечное состояния.
Начальное состояние (start state) - разновидность псевдосостояния, обозначающее
начало выполнения процесса изменения состояний конечного автомата или
нахождения моделируемого объекта в составном состоянии.
В этом состоянии находится объект по умолчанию в начальный момент времени. Оно
служит для указания на диаграмме состояний графической области, от которой
начинается процесс изменения состояний. Графически начальное состояние в языке UML
обозначается в виде закрашенного кружка (рис. 9.3, а), из которого может только
выходить стрелка-переход.
Рис. 9.3. Графическое изображение начального и конечного состояний на диаграмме состояний
На самом верхнем уровне представления объекта переход из начального состояния может
быть помечен событием создания (инициализации) данного объекта. В противном случае
этот переход никак не помечается. Если этот переход не помечен, то он является первым
переходом на диаграмме состояний в следующее за ним состояние. Каждая диаграмма или
под-диаграмма состояний должна иметь единственное начальное состояние.
Конечное состояние (final state) - разновидность псевдосостояния, обозначающее
прекращение процесса изменения состояний конечного автомата или нахождения
моделируемого объекта в составном состоянии.
В этом состоянии должен находиться моделируемый объект или система по умолчанию
после завершения работы конечного автомата. Оно служит для указания на диаграмме
459
состояний графической области, в которой завершается процесс изменения состояний или
жизненный цикл данного объекта. Графически конечное состояние в языке UML
обозначается в виде закрашенного кружка, помещенного в окружность (рис. 9.3, б), в
которую может только входить стрелка-переход. Каждая диаграмма состояний или
подсостояний может иметь несколько конечных состояний, при этом все они считаются
эквивалентными на одном уровне вложенности состояний.
Переход и событие
Пребывание моделируемого объекта или системы в первом состоянии может
сопровождаться выполнением некоторых внутренних действий или деятельности. При
этом изменение текущего состояния объекта будет возможно либо после завершения этих
действий (деятельности), либо при возникновении некоторых внешних событий. В обоих
случаях говорят, что происходит переход объекта из одного состояния в другое.
Переход (transition) - отношение между двумя состояниями, которое указывает на то, что
объект в первом состоянии должен выполнить определенные действия и перейти во
второе состояние.
Переход осуществляется при наступлении некоторого события: окончания выполнения
деятельности (do activity), получении объектом сообщения или приемом сигнала. На
переходе указывается имя события, а также действия, производимые объектом в ответ на
внешние события при переходе из одного состояния в другое.
Переход может быть направлен в то же состояние, из которого он выходит. В этом случае
его называют переходом в себя. Исходное и целевое состояния перехода в себя совпадают.
Этот переход изображается петлей со стрелкой и отличается от внутреннего перехода.
При переходе в себя объект покидает исходное состояние, а затем снова входит в него.
При этом всякий раз выполняются внутренние действия, специфицированные метками
entry и exit.
Срабатывание <перехода> (fire) - выполнение перехода из одного состояния в другое.
Срабатывание перехода может зависеть не только от наступления события, но и от
выполнения определенного условия, называемого сторожевым. Объект перейдет из
одного состояния в другое в том случае, если произошло указанное событие и сторожевое
условие приняло значение "истина". До срабатывания перехода объект находится в
предыдущем от него состоянии, называемым исходным, или в источнике (не путать с
начальным состоянием - это разные понятия), а после его срабатывания объект находится
в последующем от него состоянии (целевом состоянии).
На диаграмме состояний переход изображается сплошной линией со стрелкой, которая
выходит из исходного состояния и направлена в целевое состояние (например, выход из
строя на рис. 9.1). Каждый переход может быть помечен строкой текста, которая имеет
следующий общий формат:
<имя события>'('<список параметров,
разделенных запятыми>')'
'['<сторожевое условие>']'
<выражение действия>.
460
Событие (event) - спецификация существенных явлений в поведении системы, которые
имеют местоположение во времени и пространстве.
Формально, событие представляет собой спецификацию факта, имеющего место в
пространстве и во времени. Про события говорят, что они "происходят", при этом
отдельные события должны быть упорядочены во времени. После наступления события
нельзя уже вернуться к предыдущим, если такая возможность явно не предусмотрена в
модели.
Семантика понятия события фиксирует внимание на внешних проявлениях качественных
изменений, происходящих при переходе моделируемого объекта из состояния в
состояние. Например, при включении электрического переключателя происходит
событие, в результате которого комната освещается. После успешного ремонта
компьютера также происходит немаловажное событие - восстановление его
работоспособности. Если поднять трубку обычного телефона, то, в случае его
исправности, мы ожидаем услышать тоновый сигнал. Это тоже является событием.
В языке UML события играют роль стимулов, которые инициируют переходы из одних
состояний в другие. В качестве событий можно рассматривать сигналы, вызовы,
окончание фиксированных промежутков времени или моменты окончания выполнения
определенных действий. В зависимости от вида происходящих событий - стимулов в
языке UML различают два типа переходов: триггерные и нетриггерные.
Переход называется триггерным, если его специфицирует событие-триггер,
связанное с внешними условиями по отношению к рассматриваемому состоянию.
В этом случае рядом со стрелкой триггерного перехода обязательно указывается имя
события в форме строки текста, начинающейся со строчной буквы. Наиболее часто в
качестве имен триггерных переходов задают имена операций, вызываемых у тех или иных
объектов системы. После имени такого события следуют круглые скобки для явного
задания параметров соответствующей операции. Если таких параметров нет, то список
параметров со скобками может отсутствовать. Например, переход на рис. 9.4, а, является
триггерным, поскольку с ним связано конкретное событие-триггер, происходящее
асинхронно при срабатывании некоторого датчика.
Переход называется нетриггерным, если он происходит по завершении выполнения
ду-деятельности в данном состоянии.
Нетриггерные переходы часто называют переходами по завершении ду-деятельности. Для
них рядом со стрелкой перехода не указывается никакого имени события, а в исходном
состоянии должна быть описана внутренняя ду-деятельность, по окончании которой
произойдет тот или иной нетриггерный переход.
461
Рис. 9.4. Графическое изображение триггерного (а) и нетриггерного (б) переходов на диаграмме состояний
Сторожевое условие (guard condition) - логическое условие, записанное в прямых
скобках и представляющее собой булевское выражение.
При этом булевское выражение должно принимать одно из двух взаимно исключающих
значений: "истина" или "ложь". Из контекста диаграммы состояний должна явно
следовать семантика этого выражения, а для записи выражения может использоваться
обычный язык, псевдокод или язык программирования.
Дополнение триггерных и нетриггерных переходов сторожевыми условиями позволяет
явно специфицировать семантику их срабатывания. Если сторожевое условие принимает
значение "истина", то соответствующий переход при наступлении события-триггера или
завершении деятельности может сработать, в результате чего объект перейдет в целевое
состояние. Если же сторожевое условие принимает значение "ложь", то переход не может
сработать, даже если произошло событие-триггер или завершилась деятельность в
исходном состоянии. Очевидно, в случае невыполнения сторожевого условия
моделируемый объект или система останется в исходном состоянии. Однако вычисление
истинности сторожевого условия в модели происходит только после возникновения
ассоциированного с ним события-триггера или завершения деятельности, которые
инициируют соответствующий переход.
Поскольку общее количество выходящих переходов из любого состояния в языке UML не
ограничено, хотя и является конечным, не исключена ситуация, когда из одного состояния
могут выходить несколько переходов с идентичным событием-триггером. Каждый такой
переход должен содержать собственное сторожевое условие, при этом никакие два или
более сторожевых условий не должны одновременно принимать значение "истина". В
противном случае на диаграмме состояний возникнет конфликт триггерных переходов,
что делает несостоятельной (ill formed) модель системы в целом.
Аналогичное замечание справедливо и для нетриггерных переходов, когда из одного
состояния выходят несколько переходов по завершении деятельности. Каждый из таких
переходов также должен содержать собственное сторожевое условие, при этом никакие
два или более сторожевых условий не должны одновременно принимать значение
"истина". В противном случае на диаграмме состояний будет иметь место конфликт
нетриггерных переходов, что также делает несостоятельной (ill formed) модель системы в
целом.
462
Рис. 9.5. Триггерные и нетриггерные переходы на диаграмме состояний
Изображенный фрагмент диаграммы состояний (рис. 9.5) моделирует изменение
состояний банкомата при проверке ПИН-кода. Нетриггерные переходы на данной
диаграмме помечены сторожевыми условиями, которые исключают конфликт между
ними. Что касается триггерного перехода, помеченного событием отмена транзакции, то
он происходит независимо от проверки ПИН-кода в том случае, когда клиент решил
отказаться от ввода ПИН-кода.
Выражение действия (action expression) представляет собой вызов операции или
передачу сообщения, имеет атомарный характер и выполняется сразу после
срабатывания соответствующего перехода до начала действий в целевом состоянии.
Выражение действия выполняется в том и только в том случае, когда переход
срабатывает. Атомарность действия означает, что оно не может быть прервано никаким
другим действием до тех пор, пока не закончится его выполнение. Данное действие может
оказывать влияние как на сам объект, так и на его окружение, если это с очевидностью
следует из контекста модели. Данное выражение записывается после знака "/" в строке
текста, присоединенной к соответствующему переходу.
В общем случае, выражение действия может содержать целый список отдельных
действий, разделенных символом ";". Обязательное требование - все действия из списка
должны четко различаться между собой и следовать в порядке их записи. На синтаксис
записи выражений действия не накладывается никаких ограничений. Главное - их запись
должна быть понятна разработчикам модели и программистам. Поэтому чаще всего
выражения записывают на одном из языков программирования, который предполагается
использовать для реализации модели.
В качестве примера выражения действия перехода (рис. 9.6) может служить отображение
сообщения на экране банкомата в том случае, когда запрашиваемая клиентом сумма
превосходит остаток на его счету. В случае если кредит не превышен, то происходит
переход в состояние получения наличных.
Рис. 9.6. Выражение действия перехода на диаграмме состояний
463
Формализм конечных автоматов допускает вложение одних конечных автоматов в другие
для уточнения внутренней структуры отдельных более общих состояний. В этом случае
вложенные конечные автоматы получили название конечных подавтоматов. Подавтоматы
могут использоваться для внутренней спецификации процедур и функций, реализация
которых обусловливает поведение моделируемой системы или объекта.

диаграммы деятельности (activity diagrams) - для моделирования поведения
системы в рамках различных вариантов использования, или потоков управления.
Диаграммы деятельности, в отличие от большинства других средств UML,
заимствуют идеи из нескольких различных методов, в частности, метода
моделирования состояний SDL и сетей Петри. Эти диаграммы особенно полезны в
описании поведения, включающего большое количество параллельных процессов.
Диаграммы деятельности являются также полезными при параллельном
программировании, поскольку можно графически изобразить все ветви и определить,
когда их необходимо синхронизировать.
Диаграммы деятельности можно применять для описания потоков
событий в вариантах использования. С помощью текстового описания
можно достаточно подробно рассказать о потоке событий, но в сложных
и запутанных потоках с множеством альтернативных ветвей будет
трудно понять логику событий. Диаграммы деятельности предоставляют
ту же информацию, что и текстовое описание потока событий, но в
наглядной графической форме. Диаграмма деятельности и особенности
ее построения
При моделировании поведения проектируемой или анализируемой программной системы
возникает необходимость не только представить процесс изменения ее состояний, но и
детализировать особенности алгоритмической и процедурной реализации выполняемых
системой операций. Для этой цели, как правило, используются блок-схемы или
структурные схемы алгоритмов. Каждая такая схема акцентирует внимание на
последовательности выполнения определенных процедур или элементарных операций,
которые в совокупности приводят к получению желаемого результата.
С увеличением сложности системы строгое соблюдение определенной
последовательности выполняемых действий приобретает большое значение. Попытка
заварить кофе холодной водой может испортить порцию напитка. Нарушение
последовательности операций при ремонте двигателя приводит к его поломке или выходу
из строя. Еще более катастрофические последствия могут произойти в случае отклонения
от установленной последовательности действий при взлете или посадке авиалайнера,
запуске ракеты, регламентных работах на АЭС.
Для моделирования процесса выполнения операций в языке UML используются
диаграммы деятельности. Применяемая в них графическая нотация во многом похожа на
нотацию диаграммы состояний, поскольку на диаграммах деятельности также
присутствуют обозначения состояний и переходов. Отличие заключается в семантике
464
состояний, которые используются для представления деятельности и действий, а также в
отсутствии на переходах сигнатуры событий. Каждое состояние на диаграмме
деятельности соответствует выполнению некой операции, а переход в следующее
состояние происходит только после завершения выполнения этой операции. Диаграмма
деятельности представляется в форме графа деятельности, вершинами которого являются
состояния действия или деятельности, а дугами - переходы от одного состояния действия
к другому.
Диаграммы деятельности - частный случай диаграмм состояний. Они позволяют
реализовать в языке UML особенности процедурного и синхронного управления,
обусловленного завершением внутренних действий и деятельности. Основным
направлением использования диаграмм деятельности является визуализация особенностей
реализации операций классов, когда необходимо представить алгоритмы их выполнения.
При этом каждое состояние может являться выполнением операции определенного класса
либо ее части, позволяя использовать диаграммы деятельности для описания реакций на
внутренние события системы.
В контексте языка UML деятельность представляет собой совокупность отдельных
вычислений, выполняемых автоматом. При этом отдельные элементарные вычисления
могут приводить к результату или действию. На диаграмме деятельности отображается
логика или последовательность перехода от одной деятельности к другой, при этом
внимание фиксируется на результате деятельности. Сам же результат может привести к
изменению состояния системы или возвращению некоторого значения. Диаграмма
деятельности предназначена для моделирования поведения систем, хотя время в явном
виде отсутствует на этой диаграмме. Ситуация здесь во многом аналогична диаграмме
состояний, однако имеет ряд особенностей.
Состояния деятельности и действия
Состояние деятельности (activity state) - состояние в графе деятельности, которое
служит для представления процедурной последовательности действий, требующих
определенного времени.
Переход из состояния деятельности происходит после выполнения специфицированной в
нем ду-деятельности, при этом ключевое слово do в имени деятельности не указывается.
Состояние деятельности не может иметь внутренних переходов, поскольку оно является
элементарным. Деятельность, описанная в состоянии деятельности, не может быть
прервана никакими внешними событиями. Обычное использование состояния
деятельности заключается в моделировании подпроцесса выполнения отдельных
алгоритмов или процедур.
Состояние действия (action state) - специальный случай состояния с некоторым входным
действием и, по крайней мере, одним выходящим из состояния переходом.
Переход из состояния действия происходит после завершения входного действия.
Состояние действия не может иметь внутренних переходов, поскольку оно является
элементарным. Обычное использование состояния действия заключается в моделировании
шага выполнения алгоритма или процедуры в рамках одного потока управления.
465
Графически состояния деятельности и действия изображаются одинаковой фигурой,
напоминающей прямоугольник, боковые стороны которого заменены выпуклыми дугами
(рис. 11.1). Внутри этой фигуры записывается имя состояния деятельности (рис. 11.1, а)
или действия (рис. 11.1, б) в форме выражения (expression), которое должно быть
уникальным в пределах одной диаграммы деятельности.
Рис. 11.1. Графическое изображение состояний деятельности и действия
Действие может быть записано на естественном языке, псевдокоде или языке
программирования. Никаких дополнительных или неявных ограничений при записи
действий не накладывается. Рекомендуется в качестве имени простого действия
использовать глагол с пояснительными словами (рис. 11.1, а). Если же действие может
быть представлено в формальном виде, то целесообразно записать его на том языке
программирования, на котором предполагается реализовывать разрабатываемый проект
(рис. 11.1, б).
Иногда возникает необходимость представить на диаграмме деятельности сложное
действие, в свою очередь, состоящее из нескольких более простых. В этом случае можно
использовать специальное обозначение так называемого состояния под-деятельности.
Состояние под-деятельности (subactivity state) - состояние в графе деятельности, которое
служит для представления неатомарной последовательности шагов процесса.
Это состояние является графом деятельности и обозначается специальной пиктограммой в
правом нижнем углу символа состояния действия (рис. 11.2). Данная конструкция может
применяться к любому элементу языка UML, который поддерживает "вложенность" своей
структуры. При этом пиктограмма может быть дополнительно помечена типом вложенной
структуры.
Рис. 11.2. Графическое изображение состояния под-деятельности
Каждая диаграмма деятельности должна иметь единственное начальное и конечное
состояния. Они имеют такие же обозначения, как и на диаграмме состояний. При этом
каждая деятельность начинается в начальном состоянии и заканчивается в конечном
состоянии. Саму диаграмму деятельности принято располагать таким образом, чтобы
466
действия следовали сверху вниз или слева направо. В этом случае начальное состояние
будет изображаться в верхней или левой части диаграммы, а конечное - в ее нижней или
правой части. В интересах удобства визуального представления на диаграмме
деятельности допускается изображать несколько конечных состояний. В этом случае все
их принято считать эквивалентными друг другу.
Переходы на диаграмме деятельности
Переход как элемент диаграммы состояний был рассмотрен в лекции 9. При построении
диаграммы деятельности используются только нетриггерные переходы, т. е. такие,
которые происходят сразу после завершения деятельности или выполнения
соответствующего действия. Такой переход передает управление в последующее
состояние сразу, как только закончится действие или деятельность в предыдущем
состоянии. На диаграмме такой переход изображается сплошной линией со стрелкой.
Если из состояния действия выходит единственный переход, то его можно никак не
помечать. Если же таких переходов несколько, то при моделировании последовательной
деятельности запускается только один из них. В этом случае для каждого из таких
переходов должно быть явно записано собственное сторожевое условие в прямых скобках
(см. лекцию 9). При этом для всех выходящих из некоторого состояния деятельности
переходов должно выполняться требование истинности только одного из них. Подобный
случай встречается тогда, когда последовательно выполняемая деятельность должна
разделиться на альтернативные ветви в зависимости от значения промежуточного
результата. Такая ситуация получила название ветвления, а для ее обозначения
применяется специальный символ решения.
Графически ветвление на диаграмме деятельности обозначается символом решения
(decision), изображаемого в форме небольшого ромба, внутри которого нет никакого
текста (рис. 11.3 вверху). В этот ромб может входить только одна стрелка от того
состояния действия, после выполнения которого поток управления должен быть
продолжен по одной из взаимно исключающих ветвей. Принято входящую стрелку
присоединять к верхней или левой вершине символа решения. Выходящих стрелок может
быть две или более, но для каждой из них явно указывается соответствующее сторожевое
условие в форме булевского выражения.
Для графического объединения альтернативных ветвей на диаграмме деятельности
рекомендуется также использовать аналогичный символ в форме ромба, который в этом
случае называют соединением (merge). Наличие этого символа, внутри которого также не
записывается никакого текста, упрощает визуальный контроль логики выполнения
процедурных действий на диаграмме деятельности (рис. 11.3 внизу). Входящих стрелок у
символа соединения может быть несколько, они исходят от состояний действия,
принадлежащих к одной из взаимно исключающих ветвей. Выходить из ромба соединения
может только одна стрелка, при этом ни входящие, ни выходящая стрелки не должны
содержать сторожевых условий. Исключением является ситуация, когда с целью
сокращения диаграммы объединяют символ решения с символом соединения. Нарушение
этих правил делает диаграмму деятельности несостоятельной (ill formed).
Диаграмма деятельности (рис. 11.3) моделирует ситуацию, возникающую в супермаркетах
при оплате товаров. Как правило, заплатить за покупки можно либо наличными, либо по
467
кредитной карточке. Если покупателем выбран вариант оплаты по кредитной карточке, то
проверяется сумма баланса предъявленной к оплате кредитной карточки. При этом оплата
происходит только в том случае, если общая стоимость приобретаемых товаров не
превышает суммы баланса этой карточки. В противном случае оплаты не происходит, и
товар остается у продавца.
Рис. 11.3. Различные варианты ветвлений на диаграмме деятельности
Один из наиболее значимых недостатков обычных блок-схем или структурных схем
алгоритмов связан с проблемой изображения параллельных ветвей отдельных
вычислений. Поскольку распараллеливание вычислений существенно повышает общее
быстродействие программных систем, необходимы графические примитивы для
представления параллельных процессов. В диаграммах деятельности с этой целью
используется специальный символ для разделения и слияния параллельных вычислений
или потоков управления. Это прямая черточка, аналогичная обозначению параллельных
переходов для диаграмм состояний.
На диаграммах деятельности такая черточка изображается отрезком горизонтальной, реже
- вертикальной, линии, толщина которой несколько шире линий простых переходов
диаграммы деятельности. При этом разделение (fork) имеет один входящий переход и
несколько выходящих (рис. 11.4, а), которые изображаются отрезками вертикальных, реже
- горизонтальных, линий. Слияние (join), наоборот, имеет несколько входящих переходов
и один выходящий (рис. 11.4, б). Параллельные переходы на диаграмме деятельности
можно изображать в удлиненной форме, а входящие и выходящие переходы
вертикальными стрелками.
468
Рис. 11.4. Графическое изображение разделения и слияния параллельных потоков управления на диаграмме
деятельности
Рассмотренных переходов оказывается достаточно для моделирования различных по
сложности ситуаций. Для иллюстрации особенности изображения ветвления и
параллельных деятельностей можно рассмотреть пример регистрации пассажиров в
аэропорту (рис. 11.5). Первоначально выполняется деятельность по проверке билета. В
случае если билет не действителен, он возвращается пассажиру, при этом никаких
дополнительных действий не выполняется.
Рис. 11.5. Диаграмма деятельности для примера регистрации пассажиров в аэропорту
469
Если же билет действителен, то пассажиру выдается посадочный талон. В дополнение к
этому проверяется гражданство и наличие багажа у пассажира. Если есть багаж, то его
проверка может быть выполнена параллельно, по результатам которой пассажиру
выдается талон на багаж. Если пассажир является иностранным гражданином, то
дополнительно проверяется наличие у него визы. Если виза действительна, то проверка
завершается успешно, и пассажир с возвращенным ему билетом может проследовать на
посадку.
Если же виза окажется не действительной, то для этого пассажира посадка на данный рейс
оказывается невозможной. В этом случае ему не выдается посадочный талон и талон на
багаж, в случае его наличия, поскольку происходит прекращение всех выполняемых
сотрудниками аэропорта действий.
Дорожки
Диаграммы деятельности могут быть использованы не только для спецификации
алгоритмов вычислений или потоков управления в программных системах. Не менее
важная область их применения связана с моделированием бизнес-процессов. В этом
контексте деятельность любой компании или фирмы представляет собой не что иное, как
совокупность отдельных действий, работ, операций, направленных на достижение
требуемого результата.
Однако применительно к бизнес-процессам желательно выполнение каждого действия
ассоциировать с конкретным подразделением компании. В этом случае подразделение
будет нести ответственность за реализацию определенных действий, а сам бизнес-процесс
представляется в виде переходов действий из одного подразделения к другому. Для
моделирования этих особенностей в языке UML предложена специальная конструкция,
получившая название дорожки.
Дорожка (swimlane) - графическая область диаграммы деятельности, содержащая
элементы модели, ответственность за выполнение которых принадлежит отдельным
подсистемам.
В данном случае имеется в виду визуальная аналогия с плавательными дорожками в
бассейне, если смотреть на соответствующую диаграмму деятельности сверху. При этом
все состояния на диаграмме деятельности делятся на группы, разграниченные
вертикальными линиями. Две соседних линии и образуют дорожку, а группа состояний
между этими линиями выполняется организационным подразделением (отделом, группой,
отделением, филиалом) или сотрудником компании (рис. 11.6). В последнем случае
принято указывать должность сотрудника, ответственного за выполнение определенных
действий.
Названия подразделений или должностей явно указываются в верхней части дорожки.
Пересекать линию дорожки могут только переходы, которые в этом случае обозначают
выход или вход потока управления в соответствующее подразделение компании. Порядок
следования дорожек не несет какой-либо семантической информации и определяется
соображениями удобства.
470
Рис. 11.6. Вариант диаграммы деятельности с дорожками
В качестве примера можно рассмотреть фрагмент диаграммы деятельности торговой
компании, обслуживающей клиентов в форме заказов. Подразделениями компании
обычно являются отдел приема и оформления заказов, отдел продаж и склад. Этим
подразделениям будут соответствовать три дорожки на диаграмме деятельности, каждая
из которых специфицирует зону ответственности подразделения. В этом случае
диаграмма деятельности заключает в себе не только информацию о последовательности
выполнения рабочих действий, но и о том, какое подразделение торговой компании
должно выполнять то или иное действие (рис. 11.7).
471
Рис. 11.7. Фрагмент диаграммы деятельности для торговой компании
Из указанной диаграммы деятельности видно, что после принятия заказа от клиента
отделом приема и оформления заказов осуществляется распараллеливание деятельности
на два потока (переход-разделение). Первый из них остается в этом же отделе и связан с
получением оплаты от клиента за заказанный товар. Второй инициирует выполнение
действия по регистрации заказа в отделе продаж (модель товара, размеры, цвет, год
выпуска и пр.). Однако выдача товара со склада начинается только после того, как будет
получена от клиента оплата за товар (переход-слияние). Затем выполняется подготовка
товара к отправке и его отправка клиенту в отделе продаж. После завершения этих
деятельностей заказ закрывается в отделе приема и оформления заказов.
Объекты на диаграмме деятельности
Действия на диаграмме деятельности могут производиться над теми или иными
объектами. Эти объекты либо инициируют выполнение действий, либо определяют
результат этих действий. При этом действия специфицируют вызовы, которые передаются
от одного объекта графа деятельности другому. Поскольку в таком ракурсе объекты
играют определенную роль в понимании процесса деятельности, иногда возникает
необходимость явно указать их на диаграмме деятельности.
472
Следует напомнить, что базовым графическим представлением объекта в нотации языка
UML является прямоугольник класса, с тем отличием, что имя объекта подчеркивается.
На диаграммах деятельности после имени может указываться характеристика состояния
объекта в прямых скобках. Такие прямоугольники объектов присоединяются к состояниям
действия отношением зависимости пунктирной линией со стрелкой. Соответствующая
зависимость определяет состояние конкретного объекта после выполнения
предшествующего действия.
На диаграмме деятельности с дорожками расположение объекта может иметь
дополнительный смысл. А именно, если объект расположен на границе двух дорожек, то
это может означать, что переход к следующему состоянию действия в соседней дорожке
ассоциирован с нахождением документа в некотором состоянии. Если же объект
расположен внутри дорожки, то и состояние этого объекта целиком определяется
действиями данной дорожки.
Применительно к диаграммам деятельности объекты, как правило, являются
экземплярами классов сущностей или бизнес - сущностей. Стоит также заметить, что на
диаграмме деятельности один и тот же объект может быть изображен несколько раз, при
этом для исключения несогласованности диаграммы необходимо указывать для них
различные характеристики состояния.
В предыдущем примере с торговой компанией центральным объектом процесса продажи
является заказ или вернее состояние его выполнения. Вначале до обращения клиента заказ
как объект отсутствует и возникает лишь после контакта с клиентом. В результате
фиксируется полученный заказ, после чего он регистрируется в отделе продаж. Затем он
передается на склад, где после получения оплаты за товар оформляется окончательно .
Наконец, после того, как товар отправлен клиенту, эта информация вносится в заказ, и он
считается выполненным. Эта информация может быть представлена графически в виде
модифицированного варианта диаграммы деятельности торговой компании (рис. 11.8).
Достоинством диаграммы деятельности является возможность визуализировать отдельные
аспекты поведения рассматриваемой системы или реализации отдельных операций
классов в виде процедурной последовательности действий. Таким образом, полная модель
системы может содержать одну или несколько диаграмм деятельности, каждая из которых
описывает последовательность реализации либо наиболее важных вариантов
использования (типичный ход событий и все исключения), либо нетривиальных операций
классов.
473
Рис. 11.8. Фрагмент диаграммы деятельности торговой компании с объектом-заказом
В заключение следует заметить, что диаграмма деятельности, так же как и другие виды
канонических диаграмм, не содержат средств выбора оптимальных вариантов
конфигурации собственно диаграмм. При разработке сложных проектов проблема выбора
оптимальных решений применительно к диаграммам деятельности становится весьма
актуальной. Рациональное расходование средств, затраченных на разработку и
эксплуатацию системы, повышение ее производительности и надежности зачастую
определяют конечный результат всего проекта.
474
24.Коды аутентификации сообщений (МАС) и криптографические хэшфункции.
Хэш-функции
Требования к хэш-функциям
Хэш-функцией называется односторонняя функция, предназначенная для получения
дайджеста или "отпечатков пальцев" файла, сообщения или некоторого блока данных.
Хэш-код создается функцией Н:
h = H (M)
Где М является сообщением произвольной длины и h является хэш-кодом фиксированной
длины.
Рассмотрим требования, которым должна соответствовать хэш-функция для того, чтобы
она могла использоваться в качестве аутентификатора сообщения. Рассмотрим очень
простой пример хэш-функции. Затем проанализируем несколько подходов к построению
хэш-функции.
Хэш-функция Н, которая используется для аутентификации сообщений, должна обладать
следующими свойствами:
1.
Хэш-функция Н должна применяться к блоку данных любой длины.
2.
Хэш-функция Н создает выход фиксированной длины.
3.
Н (М) относительно легко (за полиномиальное время) вычисляется для любого значения М.
4.
Для любого данного значения хэш-кода h вычислительно невозможно найти M такое, что Н (M) = h.
5.
Для любого данного х вычислительно невозможно найти y x, что H (y) = H (x).
6.
Вычислительно невозможно найти произвольную пару (х, y) такую, что H (y) = H (x).
Первые три свойства требуют, чтобы хэш-функция создавала хэш-код для любого
сообщения.
Четвертое свойство определяет требование односторонности хэш-функции: легко создать
хэш-код по данному сообщению, но невозможно восстановить сообщение по данному
хэш-коду. Это свойство важно, если аутентификация с использованием хэш-функции
включает секретное значение. Само секретное значение может не посылаться, тем не
менее, если хэш-функция не является односторонней, противник может легко раскрыть
секретное значение следующим образом. При перехвате передачи атакующий получает
сообщение М и хэш-код С = Н (SAB || M). Если атакующий может инвертировать хэшфункцию, то, следовательно, он может получить SAB || M = H-1 (C). Так как атакующий
теперь знает и М и SAB || M, получить SAB совсем просто.
475
Пятое свойство гарантирует, что невозможно найти другое сообщение, чье значение хэшфункции совпадало бы со значением хэш-функции данного сообщения. Это
предотвращает подделку аутентификатора при использовании зашифрованного хэш-кода.
В данном случае противник может читать сообщение и, следовательно, создать его хэшкод. Но так как противник не владеет секретным ключом, он не имеет возможности
изменить сообщение так, чтобы получатель этого не обнаружил . Если данное свойство не
выполняется, атакующий имеет возможность выполнить следующую последовательность
действий: перехватить сообщение и его зашифрованный хэш-код, вычислить хэш-код
сообщения, создать альтернативное сообщение с тем же самым хэш-кодом, заменить
исходное сообщение на поддельное. Поскольку хэш-коды этих сообщений совпадают,
получатель не обнаружит подмены.
Хэш-функция, которая удовлетворяет первым пяти свойствам, называется простой или
слабой хэш-функцией. Если кроме того выполняется шестое свойство, то такая функция
называется сильной хэш-функцией. Шестое свойство защищает против класса атак,
известных как атака "день рождения".
Простые хэш-функции
Все хэш-функции выполняются следующим образом. Входное значение (сообщение, файл
и т.п.) рассматривается как последовательность n-битных блоков. Входное значение
обрабатывается последовательно блок за блоком, и создается m-битное значение хэшкода.
Одним из простейших примеров хэш-функции является побитный XOR каждого блока:
Сi = bi1
bi2
. . .
bik
Где
Сi - i-ый бит хэш-кода, 1 i n.
k - число n-битных блоков входа.
bij - i-ый бит в j-ом блоке.
- операция XOR.
В результате получается хэш-код длины n, известный как продольный избыточный
контроль. Это эффективно при случайных сбоях для проверки целостности данных.
Часто при использовании подобного продольного избыточного контроля для каждого
блока выполняется однобитный циклический сдвиг после вычисления хэш-кода. Это
можно описать следующим образом.

Установить n-битный хэш-код в ноль.

Для каждого n-битного блока данных выполнить следующие операции:
o
сдвинуть циклически текущий хэш-код влево на один бит;
o
выполнить операцию XOR для очередного блока и хэш-кода.
Это даст эффект "случайности" входа и уничтожит любую регулярность, которая
присутствует во входных значениях.
476
Хотя второй вариант считается более предпочтительным для обеспечения целостности
данных и предохранения от случайных сбоев, он не может использоваться для
обнаружения преднамеренных модификаций передаваемых сообщений. Зная сообщение,
атакующий легко может создать новое сообщение, которое имеет тот же самый хэш-код.
Для этого следует подготовить альтернативное сообщение и затем присоединить nбитный блок, который является хэш-кодом нового сообщения, и блок, который является
хэш-кодом старого сообщения.
Хотя простого XOR или ротационного XOR (RXOR) недостаточно, если целостность
обеспечивается только зашифрованным хэш-кодом, а само сообщение не шифруется,
подобная простая функция может использоваться, когда все сообщение и присоединенный
к нему хэш-код шифруются. Но и в этом случае следует помнить о том, что подобная хэшфункция не может проследить за тем, чтобы при передаче последовательность блоков не
изменилась. Это происходит в силу того, что данная хэш-функция определяется
следующим образом: для сообщения, состоящего из последовательности 64-битных
блоков Х1, Х2,..., ХN, определяется хэш-код С как поблочный XOR всех блоков, который
присоединяется в качестве последнего блока:
С = ХN+1 = X1
X2
. . .
XN
Затем все сообщение шифруется, включая хэш-код, в режиме СВС для создания
зашифрованных блоков Y1, Y2, ..., YN+1. По определению СВС имеем:
Х1 = IV
DK [Y1]
Хi = Yi-1
DK [Yi]
ХN+1 = YN
DK [YN+1]
Но XN+1 является хэш-кодом:
ХN+1 = X1
(IV
(YN-1
X2
DK [Y1])
. . .
(Y1
XN =
DK [Y2])
. . .
DK [YN])
Так как сомножители в предыдущем равенстве могут вычисляться в любом порядке,
следовательно, хэш-код не будет изменен, если зашифрованные блоки будут
переставлены.
Первоначальный стандарт, предложенный NIST, использовал простой XOR, который
применялся к 64-битным блокам сообщения, затем все сообщение шифровалось,
используя режим СВС.
"Парадокс дня рождения"
Прежде чем рассматривать более сложные хэш-функции, необходимо проанализировать
одну конкретную атаку на простые хэш-функции.
Так называемый "парадокс дня рождения" состоит в следующем. Предположим,
количество выходных значений хэш-функции Н равно n. Каким должно быть число k,
чтобы для конкретного значения X и значений Y1, …, Yk вероятность того, что хотя бы
для одного Yi выполнялось равенство
H (X) = H (Y)
477
была бы больше 0,5.
Для одного Y вероятность того, что H (X) = H (Y), равна 1/n.
Соответственно, вероятность того, что H(X) H(Y), равна 1 - 1/n.
Если создать k значений, то вероятность того, что ни для одного из них не будет
совпадений, равна произведению вероятностей, соответствующих одному значению, т.е.
(1 - 1/n)k.
Следовательно, вероятность, по крайней мере, одного совпадения равна
1 - (1 - 1/n)k
По формуле бинома Ньютона
(1 - a)k =
1 - ka + (k(k-1)/2!)a2 - ... ≈ 1 - ka
1 - (1 - k/n) = k/n = 0,5
k = n/2
Таким образом, мы выяснили, что для m-битового хэш-кода достаточно выбрать 2m-1
сообщений, чтобы вероятность совпадения хэш-кодов была больше 0,5.
Теперь рассмотрим следующую задачу: обозначим P (n, k) вероятность того, что в
множестве из k элементов, каждый из которых может принимать n значений, есть хотя бы
два с одинаковыми значениями. Чему должно быть равно k, чтобы P (n, k) была бы
больше 0,5?
Число различных способов выбора элементов таким образом, чтобы при этом не было
дублей, равно
n(n-1) … (n-k+1)n!/(n-k)!
Всего возможных способов выбора элементов равно
nk
Вероятность того, что дублей нет, равна
n!/(n-k)!nk
Вероятность того, что есть дубли, соответственно равна
1
P
1
1
1
- n!/(n-k)!nk
(n, k) = 1 - n! / ((n-k)! ×
- (n × (n-1) × … × (n-k-1))
- [ (n-1)/n × (n-2)/n × … ×
- [(1- 1/n) × (1 - 2/n) × …
nk) =
/ nk =
(n-k+1)/n] =
× (1 - (k-1)/n)]
Известно, что
1 - x
e-x
P (n, k) > 1 - [e-1/n × e-2/n × … × e-k/n]
P (n, k) > 1 - e-k(k-1)/n
1/2 = 1 - e-k(k-1)/n
2 = ek(k-1)/n
ln 2 = k (k-1) / 2n
k (k-1) ≈ k2
k = (2n × ln 2)1/2 = 1,17 n1/2 ≈ n1/2
478
Если хэш-код имеет длину m бит, т.е. принимает 2m значений, то
k = √2m = 2m/2
Подобный результат называется "парадоксом дня рождения", потому что в соответствии с
приведенными выше рассуждениями для того, чтобы вероятность совпадения дней
рождения у двух человек была больше 0,5, в группе должно быть всего 23 человека. Этот
результат кажется удивительным, возможно, потому, что для каждого отдельного
человека в группе вероятность того, что с его днем рождения совпадет день рождения
кого-то другого в группе, достаточно мала.
Вернемся к рассмотрению свойств хэш-функций. Предположим, что используется 64битный хэш-код. Можно считать, что это вполне достаточная и, следовательно,
безопасная длина для хэш-кода. Например, если зашифрованный хэш-код С передается с
соответствующим незашифрованным сообщением М, то противнику необходимо будет
найти М' такое, что
Н (М') = Н (М)
для того, чтобы подменить сообщение и обмануть получателя. В среднем противник
должен перебрать 263 сообщений для того, чтобы найти такое, у которого хэш-код равен
перехваченному сообщению.
Тем не менее, возможны различного рода атаки, основанные на "парадоксе дня
рождения". Возможна следующая стратегия:
1.
Противник создает 2m/2 вариантов сообщения, каждое из которых имеет некоторый определенный
смысл. Противник подготавливает такое же количество сообщений, каждое из которых является
поддельным и предназначено для замены настоящего сообщения.
2.
Два набора сообщений сравниваются в поисках пары сообщений, имеющих одинаковый хэш-код.
Вероятность успеха в соответствии с "парадоксом дня рождения" больше, чем 0,5. Если
соответствующая пара не найдена, то создаются дополнительные исходные и поддельные
сообщения до тех пор, пока не будет найдена пара.
3.
Атакующий предлагает отправителю исходный вариант сообщения для подписи. Эта подпись
может быть затем присоединена к поддельному варианту для передачи получателю. Так как оба
варианта имеют один и тот же хэш-код, будет создана одинаковая подпись. Противник будет уверен
в успехе, даже не зная ключа шифрования.
Таким образом, если используется 64-битный хэш-код, то необходимая сложность
вычислений составляет порядка 232.
В заключение отметим, что длина хэш-кода должна быть достаточно большой. Длина,
равная 64 битам, в настоящее время не считается безопасной. Предпочтительнее, чтобы
длина составляла порядка 100 битов.
Использование цепочки зашифрованных блоков
Существуют различные хэш-функции, основанные на создании цепочки зашифрованных
блоков, но без использования секретного ключа. Одна из таких хэш-функций была
предложена Рабином. Сообщение М разбивается на блоки фиксированной длины М1, М2, .
. . , МN и используется алгоритм симметричного шифрования, например DES, для
вычисления хэш-кода G следующим образом:
479
Н0 = начальное значение
Нi = EMi [Hi-1]
G = HN
Это аналогично использованию шифрования в режиме СВС, но в данном случае
секретного ключа нет. Как и в случае любой простой хэш-функции, этот алгоритм
подвержен "атаке дня рождения", и если шифрующим алгоритмом является DES и
создается только 64-битный хэш-код, то система считается достаточно уязвимой.
Могут осуществляться другие атаки типа "дня рождения", которые возможны даже в том
случае, если противник имеет доступ только к одному сообщению и соответствующему
ему зашифрованному хэш-коду и не может получить несколько пар сообщений и
зашифрованных хэш-кодов. Возможен следующий сценарий: предположим, что
противник перехватил сообщение с аутентификатором в виде зашифрованного хэш-кода,
и известно, что незашифрованный хэш-код имеет длину m битов. Далее противник
должен выполнить следующие действия:

Используя описанный выше алгоритм, вычислить незашифрованный хэш-код G.

Создать поддельное сообщение в виде Q1, Q2, . . . , QN-2.

Вычислить Нi = EQi[Hi-1] для 1 i N-2.

Создать 2m/2 случайных блока Х и для каждого такого блока Х вычислить ЕХ[HN-2]. Создать
дополнительно 2m/2 cлучайных блока Y и для каждого блока Y вычислить DY[G], где D дешифрующая функция, соответствующая Е. Основываясь на "парадоксе дня рождения" можно
сказать, что с высокой степенью вероятности эта последовательность будет содержать блоки Х и Y
такие, что ЕХ[HN-2] = DY[Y].

Создать сообщение Q1, Q2, . . . ,QN-2, X, Y. Это сообщение имеет хэш-код G и, следовательно, может
быть использовано вместе с зашифрованным аутентификатором.
Эта форма атаки известна как атака "встреча посередине". В различных исследованиях
предлагаются более тонкие методы для усиления подхода, основанного на цепочке
блоков. Например, Девис и Прайс описали следующий вариант:
Hi = EMi [Hi-1]
Hi-1
Возможен другой вариант:
Hi = EHi-1 [Mi]
Mi
Однако обе эти схемы также имеют уязвимости при различных атаках. В более общем
случае, можно показать, что некоторая форма "атаки дня рождения" имеет успех при
любом хэш-алгоритме, включающем использование цепочки шифрованных блоков без
применения секретного ключа.
Дальнейшие исследования были направлены на поиск других подходов к созданию
функций хэширования.
Хэш-функция MD5
Рассмотрим алгоритм получения дайджеста сообщения MD5 (RFC 1321), разработанный
Роном Ривестом из MIT.
480
Логика выполнения MD5
Алгоритм получает на входе сообщение произвольной длины и создает в качестве выхода
дайджест сообщения длиной 128 бит. Алгоритм состоит из следующих шагов:
Рис. 8.1. Логика выполнения MD5
Шаг 1: добавление недостающих битов
Сообщение дополняется таким образом, чтобы его длина стала равна 448 по модулю 512
(длина 448 mod 512). Это означает, что длина добавленного сообщения на 64 бита
меньше, чем число, кратное 512. Добавление производится всегда, даже если сообщение
имеет нужную длину. Например, если длина сообщения 448 битов, оно дополняется 512
битами до 960 битов. Таким образом, число добавляемых битов находится в диапазоне от
1 до 512.
Добавление состоит из единицы, за которой следует необходимое количество нулей.
Шаг 2: добавление длины
64-битное представление длины исходного (до добавления) сообщения в битах
присоединяется к результату первого шага. Если первоначальная длина больше, чем 264,
то используются только последние 64 бита. Таким образом, поле содержит длину
исходного сообщения по модулю 264.
В результате первых двух шагов создается сообщение, длина которого кратна 512 битам.
Это расширенное сообщение представляется как последовательность 512-битных блоков
Y0, Y1, . . ., YL-1, при этом общая длина расширенного сообщения равна L * 512 битам.
Таким образом, длина полученного расширенного сообщения кратна шестнадцати 32битным словам.
Рис. 8.2. Структура расширенного сообщения
Шаг 3: инициализация MD-буфера
Используется 128-битный буфер для хранения промежуточных и окончательных
результатов хэш-функции. Буфер может быть представлен как четыре 32-битных регистра
(A, B, C, D). Эти регистры инициализируются следующими шестнадцатеричными
числами:
А = 01234567
481
В = 89ABCDEF
C = FEDCBA98
D = 76543210
Шаг 4: обработка последовательности 512-битных (16-словных) блоков
Основой алгоритма является модуль, состоящий из четырех циклических обработок,
обозначенный как HMD5. Четыре цикла имеют похожую структуру, но каждый цикл
использует свою элементарную логическую функцию, обозначаемую fF, fG, fH и fI
соответственно.
Рис. 8.3. Обработка очередного 512-битного блока
Каждый цикл принимает в качестве входа текущий 512-битный блок Yq,
обрабатывающийся в данный момент, и 128-битное значение буфера ABCD, которое
является промежуточным значением дайджеста, и изменяет содержимое этого буфера.
Каждый цикл также использует четвертую часть 64-элементной таблицы T[1 ... 64],
построенной на основе функции sin. i-ый элемент T, обозначаемый T[i], имеет значение,
равное целой части от 232 * abs (sin (i)), i задано в радианах. Так как abs (sin (i)) является
числом между 0 и 1, каждый элемент Т является целым, которое может быть представлено
32 битами. Таблица обеспечивает "случайный" набор 32-битных значений, которые
должны ликвидировать любую регулярность во входных данных.
482
Для получения MDq+1 выход четырех циклов складывается по модулю 232 с MDq.
Сложение выполняется независимо для каждого из четырех слов в буфере.
Шаг 5: выход
После обработки всех L 512-битных блоков выходом L-ой стадии является 128-битный
дайджест сообщения.
Рассмотрим более детально логику каждого из четырех циклов выполнения одного 512битного блока. Каждый цикл состоит из 16 шагов, оперирующих с буфером ABCD.
Каждый шаг можно представить в виде:
Рис. 8.4. Логика выполнения отдельного шага
A ← B + CLSs (A + f (B, C, D) + X [k] + T [i])
где
A, B, C, D - четыре слова буфера; после выполнения каждого отдельного шага происходит циклический
сдвиг влево на одно слово.
f - одна из элементарных функций fF, fG, fH, fI.
483
CLSs - циклический сдвиг влево на s битов 32-битного аргумента.
X [k] - M [q * 16 + k] - k-ое 32-битное слово в q-ом 512 блоке сообщения.
T [i] - i-ое 32-битное слово в матрице Т.
+ - сложение по модулю 232.
На каждом из четырех циклов алгоритма используется одна из четырех элементарных
логических функций. Каждая элементарная функция получает три 32-битных слова на
входе и на выходе создает одно 32-битное слово. Каждая функция является множеством
побитовых логических операций, т.е. n-ый бит выхода является функцией от n-ого бита
трех входов. Элементарные функции следующие:
fF = (B & C)
(not B & D)
fG = (B & D) V (C & not D)
fH = B
C
D
fI = C
(B & not D)
Массив из 32-битных слов X [0..15] содержит значение текущего 512-битного входного
блока, который обрабатывается в настоящий момент. Каждый цикл выполняется 16 раз, а
так как каждый блок входного сообщения обрабатывается в четырех циклах, то каждый
блок входного сообщения обрабатывается по схеме, показанной на Рис. 4, 64 раза. Если
представить входной 512-битный блок в виде шестнадцати 32-битных слов, то каждое
входное 32-битное слово используется четыре раза, по одному разу в каждом цикле, и
каждый элемент таблицы Т, состоящей из 64 32-битных слов, используется только один
раз. После каждого шага цикла происходит циклический сдвиг влево четырех слов A, B, C
и D. На каждом шаге изменяется только одно из четырех слов буфера ABCD.
Следовательно, каждое слово буфера изменяется 16 раз, и затем 17-ый раз в конце для
получения окончательного выхода данного блока.
Можно суммировать алгоритм MD5 следующим образом:
MD0 = IV
MDq+1 = MDq + fI[Yq, fH[Yq, fG[Yq, fF[Yq, MDq]]]]
MD = MDL-1
Где
IV - начальное значение буфера ABCD, определенное на шаге 3.
Yq - q-ый 512-битный блок сообщения.
L - число блоков в сообщении (включая поля дополнения и длины).
MD - окончательное значение дайджеста сообщения.
Алгоритм MD4
Алгоритм MD4 является более ранней разработкой того же автора Рона Ривеста.
Первоначально данный алгоритм был опубликован в октябре 1990 г., незначительно
измененная версия была опубликована в RFC 1320 в апреле 1992 г. Кратко рассмотрим
основные цели MD4:
1.
Безопасность: это обычное требование к хэш-коду, состоящее в том, чтобы было вычислительно
невозможно найти два сообщения, имеющие один и тот же дайджест.
484
2.
Скорость: программная реализация алгоритма должна выполняться достаточно быстро. В
частности, алгоритм должен быть достаточно быстрым на 32-битной архитектуре. Поэтому
алгоритм основан на простом множестве элементарных операций над 32-битными словами.
3.
Простота и компактность: алгоритм должен быть простым в описании и простым в
программировании, без больших программ или подстановочных таблиц. Эти характеристики не
только имеют очевидные программные преимущества, но и желательны с точки зрения
безопасности, потому что для анализа возможных слабых мест лучше иметь простой алгоритм.
4.
Желательна little-endian архитектура: некоторые архитектуры процессоров (такие как линия Intel
80xxx) хранят левые байты слова в позиции младших адресов байта (little-endian). Другие (такие как
SUN Sparcstation) хранят правые байты слова в позиции младших адресов байта (big endian). Это
различие важно, когда сообщение трактуется как последовательность 32-битовых слов, потому что
эти архитектуры имеют инверсное представление байтов в каждом слове. Ривест выбрал
использование схемы little-endian для интерпретации сообщения в качестве последовательности 32битных слов. Этот выбор сделан потому, что big-endian процессоры обычно являются более
быстрыми.
Эти цели преследовались и при разработке MD5. MD5 является более сложным и,
следовательно, более медленным при выполнении, чем MD4. Считается, что добавление
сложности оправдывается возрастанием уровня безопасности. Главные различия между
этими двумя алгоритмами состоят в следующем:
1.
MD4 использует три цикла из 16 шагов каждый, в то время как MD5 использует четыре цикла из 16
шагов каждый.
2.
В MD4 дополнительная константа в первом цикле не применяется. Аналогичная дополнительная
константа используется для каждого из шагов во втором цикле. Другая дополнительная константа
используется для каждого из шагов в третьем цикле. В MD5 различные дополнительные константы,
Т [i], применяются для каждого из 64 шагов.
3.
MD5 использует четыре элементарные логические функции, по одной на каждом цикле, по
сравнению с тремя в MD4, по одной на каждом цикле.
4.
В MD5 на каждом шаге текущий результат складывается с результатом предыдущего шага.
Например, результатом первого шага является измененное слово А. Результат второго шага
хранится в D и образуется добавлением А к циклически сдвинутому влево на определенное число
бит результату элементарной функции. Аналогично, результат третьего шага хранится в С и
образуется добавлением D к циклически сдвинутому влево результату элементарной функции. MD4
это последнее сложение не включает.
Усиление алгоритма в MD5
Алгоритм MD5 имеет следующее свойство: каждый бит хэш-кода является функцией от
каждого бита входа. Комплексное повторение элементарных функций fF, fG, fH и fI
обеспечивает то, что результат хорошо перемешан; то есть маловероятно, чтобы два
сообщения, выбранные случайно, даже если они имеют явно похожие закономерности,
имели одинаковый хэш-код. Считается, что MD5 является наиболее сильной хэшфункцией для 128-битного хэш-кода, то есть трудность нахождения двух сообщений,
имеющих одинаковый дайджест, имеет порядок 264 операций. В то время, как трудность
нахождения сообщения с данным дайджестом имеет порядок 2128 операций.
Два результата, тем не менее, заслуживают внимания. Показано, что используя
дифференциальный криптоанализ, можно за разумное время найти два сообщения,
которые создают один и тот же дайджест при использовании только одного цикла MD5.
485
Подобный результат можно продемонстрировать для каждого из четырех циклов. Однако
обобщить эту атаку на полный алгоритм MD5 из четырех циклов пока не удалось.
Существует способ выбора блока сообщения и двух соответствующих ему
промежуточных значений дайджеста, которые создают одно и то же выходное значение.
Это означает, что выполнение MD5 над единственным блоком из 512 бит приведет к
одинаковому выходу для двух различных входных значений в буфере ABCD. Пока
способа расширения данного подхода для успешной атаки на MD5 не существует.
Хэш-функция SHA-1
Безопасный хэш-алгоритм (Secure Hash Algorithm) был разработан национальным
институтом стандартов и технологии (NIST) и опубликован в качестве федерального
информационного стандарта (FIPS PUB 180) в 1993 году. SHA-1, как и MD5, основан на
алгоритме MD4.
Логика выполнения SHA-1
Алгоритм получает на входе сообщение максимальной длины 264 бит и создает в качестве
выхода дайджест сообщения длиной 160 бит.
Алгоритм состоит из следующих шагов:
Рис. 9.1. Логика выполнения SHA-1
Шаг 1: добавление недостающих битов
Сообщение добавляется таким образом, чтобы его длина была кратна 448 по модулю 512
(длина 448 mod 512). Добавление осуществляется всегда, даже если сообщение уже
имеет нужную длину. Таким образом, число добавляемых битов находится в диапазоне от
1 до 512.
Добавление состоит из единицы, за которой следует необходимое количество нулей.
Шаг 2: добавление длины
К сообщению добавляется блок из 64 битов. Этот блок трактуется как беззнаковое 64битное целое и содержит длину исходного сообщения до добавления.
Результатом первых двух шагов является сообщение, длина которого кратна 512 битам.
Расширенное сообщение может быть представлено как последовательность 512-битных
486
блоков Y0, Y1, . . . , YL-1, так что общая длина расширенного сообщения есть L * 512 бит.
Таким образом, результат кратен шестнадцати 32-битным словам.
Шаг 3: инициализация SHA-1 буфера
Используется 160-битный буфер для хранения промежуточных и окончательных
результатов хэш-функции. Буфер может быть представлен как пять 32-битных регистров
A, B, C, D и E. Эти регистры инициализируются следующими шестнадцатеричными
числами:
A = 67452301
B = EFCDAB89
C = 98BADCFE
D = 10325476
E = C3D2E1F0
Шаг 4: обработка сообщения в 512-битных (16-словных) блоках
Основой алгоритма является модуль, состоящий из 80 циклических обработок,
обозначенный как HSHA. Все 80 циклических обработок имеют одинаковую структуру.
Рис. 9.2. Обработка очередного 512-битного блока
487
Каждый цикл получает на входе текущий 512-битный обрабатываемый блок Yq и 160битное значение буфера ABCDE, и изменяет содержимое этого буфера.
В каждом цикле используется дополнительная константа Кt, которая принимает только
четыре различных значения:
0
t
19
Kt = 5A827999
(целая часть числа [230 × 21/2])
20
t
39
Kt = 6ED9EBA1
(целая часть числа [230 × 31/2])
40
t
59
Kt = 8F1BBCDC
(целая часть числа [230 × 51/2])
60
t
79
Kt = CA62C1D6
(целая часть числа [230 × 101/2])
Для получения SHAq+1 выход 80-го цикла складывается со значением SHAq. Сложение по
модулю 232 выполняется независимо для каждого из пяти слов в буфере с каждым из
соответствующих слов в SHAq.
Шаг 5: выход
После обработки всех 512-битных блоков выходом L-ой стадии является 160-битный
дайджест сообщения.
Рассмотрим более детально логику в каждом из 80 циклов обработки одного 512-битного
блока. Каждый цикл можно представить в виде:
A, B, C, D, E (CLS5 (A) + ft (B, C, D) + E + Wt + Kt), A, CLS30 (B), C, D
Где
A, B, C, D, E - пять слов из буфера.
t - номер цикла, 0 t 79.
ft - элементарная логическая функция.
CLSs - циклический левый сдвиг 32-битного аргумента на s битов.
Wt - 32-битное слово, полученное из текущего входного 512-битного блока.
Kt - дополнительная константа.
+ - сложение по модулю 232.
488
Рис. 9.3. Логика выполнения отдельного цикла
Каждая элементарная функция получает на входе три 32-битных слова и создает на
выходе одно 32-битное слово. Элементарная функция выполняет набор побитных
логических операций, т.е. n-ый бит выхода является функцией от n-ых битов трех входов.
Функции следующие:
Номер цикла
ft (B, C, D)
(0 t 19)
(B C) (¬ B D)
(20 t 39)
B C D
(40 t 59)
(B C) (B D) (C D)
(60 t 79)
B C D
На самом деле используются только три различные функции. Для 0 t 19 функция
является условной: if B then C else D. Для 20 t 39 и 60 t 79 функция создает бит
четности. Для 40 t 59 функция является истинной, если два или три аргумента истинны.
32-битные слова Wt получаются из очередного 512-битного блока сообщения следующим
образом.
489
Рис. 9.4. Получение входных значений каждого цикла из очередного блока
Первые 16 значений Wt берутся непосредственно из 16 слов текущего блока. Оставшиеся
значения определяются следующим образом:
Wt = Wt-16
Wt-14
Wt-8
Wt-3
В первых 16 циклах вход состоит из 32-битного слова данного блока. Для оставшихся 64
циклов вход состоит из XOR нескольких слов из блока сообщения.
Алгоритм SHA-1 можно суммировать следующим образом:
SHA0 = IV
SHAq+1 = Σ32 (SHAq , ABCDEq )
SHA = SHAL-1
Где
IV - начальное значение буфера ABCDE.
ABCDEq - результат обработки q-того блока сообщения.
L - число блоков в сообщении, включая поля добавления и длины.
Σ32 - сумма по модулю 232, выполняемая отдельно для каждого слова буфера.
SHA - значение дайджеста сообщения.
Сравнение SHA-1 и MD5
Оба алгоритма, SHA-1 и MD5, произошли от MD4, поэтому имеют много общего.
Можно суммировать ключевые различия между алгоритмами.
Длина дайджеста
128 бит
SHA−1
160 бит
Размер блока обработки
512 бит
512 бит
Число итераций
64 (4 цикла по 16 итераций в каждом) 80
MD5
Число элементарных логических функций 4
3
Число дополнительных констант
4
64
Сравним оба алгоритма в соответствии с теми целями, которые были определены для
алгоритма MD4:
1.
Безопасность: наиболее очевидное и наиболее важное различие состоит в том, что дайджест SHA-1
на 32 бита длиннее, чем дайджест MD5. Если предположить, что оба алгоритма не содержат какихлибо структурированных данных, которые уязвимы для криптоаналитических атак, то SHA-1
является более стойким алгоритмом. Используя лобовую атаку, труднее создать произвольное
490
сообщение, имеющее данный дайджест, если требуется порядка 2160 операций, как в случае
алгоритма SHA-1, чем порядка 2128 операций, как в случае алгоритма MD5. Используя лобовую
атаку, труднее создать два сообщения, имеющие одинаковый дайджест, если требуется порядка 280
как в случае алгоритма SHA-1, чем порядка 264 операций как в случае алгоритма MD5.
2.
Скорость: так как оба алгоритма выполняют сложение по модулю 232, они рассчитаны на 32битную архитектуру. SHA-1 содержит больше шагов (80 вместо 64) и выполняется на 160-битном
буфере по сравнению со 128-битным буфером MD5. Таким образом, SHA-1 должен выполняться
приблизительно на 25% медленнее, чем MD5 на той же аппаратуре.
3.
Простота и компактность: оба алгоритма просты и в описании, и в реализации, не требуют больших
программ или подстановочных таблиц. Тем не менее, SHA-1 применяет одношаговую структуру по
сравнению с четырьмя структурами, используемыми в MD5. Более того, обработка слов в буфере
одинаковая для всех шагов SHA-1, в то время как в MD5 структура слов специфична для каждого
шага.
4.
Архитектуры little-endian и big-endian: MD5 использует little-endian схему для интерпретации
сообщения как последовательности 32-битных слов, в то время как SHA-1 задействует схему bigendian. Каких-либо преимуществ в этих подходах не существует.
Хэш-функции SHA-2
В 2001 году NIST принял в качестве стандарта три хэш-функции с существенно большей
длиной хэш-кода. Часто эти хэш-функции называют SHA-2 или SHA-256, SHA-384 и
SHA-512 (соответственно, в названии указывается длина создаваемого ими хэш-кода). Эти
алгоритмы отличаются не только длиной создаваемого хэш-кода, но и длиной
обрабатываемого блока, длиной слова и используемыми внутренними функциями.
Сравним характеристики этих хэш-функций.
Алгоритм
SHA-1
Длина сообщения Длина блока Длина слова
Длина дайджеста
(в битах)
(в битах)
(в битах)
сообщения (в битах)
<264
512
32
160
Безопасность (в
битах)
80
SHA-256 <264
512
32
256
128
SHA-384 <2128
SHA-512 <2128
1024
64
384
192
1024
64
512
256
Под безопасностью здесь понимается стойкость к атакам типа "парадокса дня рождения".
В данных алгоритмах размер блока сообщения равен m бит. Для SHA-256 m = 512, для
SHA-384 и SHA-512 m = 1024. Каждый алгоритм оперирует с w-битными словами. Для
SHA-256 w = 32, для SHA-384 и SHA-512 w = 64. В алгоритмах используются обычные
булевские операции над словами, а также сложение по модулю 2w, правый сдвиг на n бит
SHRn (x) , где х - w-битное слово, и циклические (ротационные) правый и левый сдвиги на
n бит ROTRn (x) и ROTLn (x), где х - w-битное слово.
SHA-256 использует шесть логических функций, при этом каждая из них выполняется с
32-битными словами, обозначенными как x, y и z. Результатом каждой функции тоже
является 32-битное слово.
Ch (x, y, z) = (x
y)
Maj (x, y, z) = (x
Σ0{256} (x) = ROTR2 (x)
y)
(¬x
z)
(x
z)
ROTR13 (x)
(y
z)
ROTR22 (x)
491
Σ1{256} (x) = ROTR6 (x)
ROTR11 (x)
ROTR25 (x)
σ0{256} (x) = ROTR7 (x)
ROTR18 (x)
SHR3 (x)
σ1{256} (x) = ROTR17 (x)
ROTR19 (x)
SHR10 (x)
SHA-384 и SHA-512 также используют шесть логических функций, каждая из которых
выполняется над 64-битными словами, обозначенными как x, y и z. Результатом каждой
функции является 64-битное слово.
Ch (x, y, z) = (x
y)
Maj (x, y, z) = (x
y)
(¬x
z)
(x
z)
(y
z)
Σ0{512} (x) = ROTR28 (x)
ROTR34 (x)
ROTR39 (x)
Σ1{512} (x) = ROTR14 (x)
ROTR18 (x)
ROTR41 (x)
σ0{512} (x) = ROTR1 (x)
σ1{512} (x) = ROTR19 (x)
ROTR8 (x)
ROTR61 (x)
SHR7 (x)
SHR6 (x)
Предварительная подготовка сообщения, т.е. добавление определенных битов до целого
числа блоков и последующее разбиение на блоки выполняется аналогично тому, как это
делалось в SHA-1 (конечно, с учетом длины блока каждой хэш-функции). После этого
каждое сообщение можно представить в виде последовательности N блоков M(1), M(2), … ,
M(N).
Рассмотрим SHA-256. В этом случае инициализируются восемь 32-битных переменных,
которые послужат промежуточным значением хэш-кода:
a, b, c, d, e, f, g, h
Основой алгоритма является модуль, состоящий из 64 циклических обработок каждого
блока M(i):
T1 = h + Σ1{256}(e) + Ch(e, f, g) + Kt{256} + Wt
T2 = Σ0{256}(a) + Maj(a, b, c)
h = g
g = f
f = e
e = d + T1
d = c
c = b
b = a
a = T1 + T2
где Ki{256} - шестьдесят четыре 32-битных константы, каждая из которых является
первыми 32-мя битами дробной части кубических корней первых 64 простых чисел.
Wt вычисляются из очередного блока сообщения по следующим правилам:
Wt = Mt(i) , 0
t
15
Wt = σ1{256}(Wt-2) + Wt-7 + σ0{256}(Wt-15) + Wt-16 ,
16
t
63
i-ое промежуточное значение хэш-кода H(t) вычисляется следующим образом:
H0(i)
H1(i)
H2(i)
H3(i)
=
=
=
=
a
b
c
d
+
+
+
+
H0(i-1)
H1(i-1)
H2(i-1)
H3(i-1)
492
H4(i)
H5(i)
H6(i)
H7(i)
=
=
=
=
e
f
g
h
+
+
+
+
H4(i-1)
H5(i-1)
H6(i-1)
H7(i-1)
Теперь рассмотрим SHA-512. В данном случае инициализируются восемь 64-битных
переменных, которые будут являться промежуточным значением хэш-кода:
a, b, c, d, e, f, g, h
Основой алгоритма является модуль, состоящий из 80 циклических обработок каждого
блока M(i):
T1 = h + Σ1{512}(e) + Ch(e, f, g) + Kt{512} + Wt
T2 = Σ0{512}(a) + Maj(a, b, c)
h = g
g = f
f = e
e = d + T1
d = c
c = b
b = a
a = T1 + T2
где Ki{512} - восемьдесят 64-битных констант, каждая из которых является первыми 64-мя
битами дробной части кубических корней первых восьмидесяти простых чисел.
Wt вычисляются из очередного блока сообщения по следующим правилам:
Wt = Mt(i) , 0
t
15
Wt = σ1{512}(Wt-2) + Wt-7 + σ0{512}(Wt-15) + Wt-16 ,
16
t
79
i-ое промежуточное значение хэш-кода H(t) вычисляется следующим образом:
H0(i)
H1(i)
H2(i)
H3(i)
H4(i)
H5(i)
H6(i)
H7(i)
=
=
=
=
=
=
=
=
a
b
c
d
e
f
g
h
+
+
+
+
+
+
+
+
H0(i-1)
H1(i-1)
H2(i-1)
H3(i-1)
H4(i-1)
H5(i-1)
H6(i-1)
H7(i-1)
Рассмотрим SHA-384. Отличия этого алгоритма от SHA-512:
1.
Другой начальный хэш-код H(0).
2.
384-битный дайджест получается из левых 384 битов окончательного хэш-кода H(N):
H0(N) || H1(N) || H2(N) || H3(N) || H4(N) || H5(N).
Хэш-функция ГОСТ 3411
Алгоритм ГОСТ 3411 является отечественным стандартом для хэш-функций. Его
структура довольно сильно отличается от структуры алгоритмов SHA-1,2 или MD5, в
основе которых лежит алгоритм MD4.
Длина хэш-кода, создаваемого алгоритмом ГОСТ 3411, равна 256 битам. Алгоритм
разбивает сообщение на блоки, длина которых также равна 256 битам. Кроме того,
493
параметром алгоритма является стартовый вектор хэширования Н - произвольное
фиксированное значение длиной также 256 бит.
Алгоритм обработки одного блока сообщения
Сообщение обрабатывается блоками по 256 бит справа налево.
Каждый блок сообщения обрабатывается по следующему алгоритму.
1.
Генерация четырех ключей длиной 256 бит каждый.
2.
Шифрование 64-битных значений промежуточного хэш-кода H на ключах Ki(i = 1, 2, 3, 4) с
использованием алгоритма ГОСТ 28147 в режиме простой замены.
3.
Перемешивание результата шифрования.
Для генерации ключей используются следующие данные:

промежуточное значение хэш-кода Н длиной 256 бит;

текущий обрабатываемый блок сообщения М длиной 256 бит;

параметры - три значения С2, С3 и С4 длиной 256 бит следующего вида: С2 и С4 состоят из одних
нулей, а С3 равно
18 08 116 024 116 08 (08 18)2 18 08 (08 18)4 (18 08)4
где степень обозначает количество повторений 0 или 1.
Используются две формулы, определяющие перестановку и сдвиг.
Перестановка Р битов определяется следующим образом: каждое 256-битное значение
рассматривается как последовательность тридцати двух 8-битных значений.
Перестановка Р элементов 256-битной последовательности выполняется по формуле y =
(x), где x - порядковый номер 8-битного значения в исходной последовательности; y порядковый номер 8-битного значения в результирующей последовательности.
(i + 1 + 4(k - 1)) = 8i + k
i = 0 ÷ 3, k = 1 ÷ 8
Сдвиг А определяется по формуле
A (x) = (x1
x2) || x4 || x3 || x2
Где
xi - соответствующие 64 бита 256-битного значения х,
|| обозначает конкатенацию.
Присваиваются следующие начальные значения:
i = 1, U = H, V = M.
W = U
V, K1 = Р (W)
Ключи K2, K3, K4 вычисляются последовательно по следующему алгоритму:
U = A(U)
Сi,
V = A(A(V)),
494
W = U
V,
Ki = Р(W)
Далее выполняется шифрование 64-битных элементов текущего значения хэш-кода Н с
ключами K1, K2, K3 и K4. При этом хэш-код Н рассматривается как последовательность 64битных значений:
H = h4 || h3 || h2 || h1
Выполняется шифрование алгоритмом ГОСТ 28147:
si = EKi [hi]
i = 1, 2, 3, 4
S = s1 || s2 || s3 || s4
Наконец на заключительном этапе обработки очередного блока выполняется
перемешивание полученной последовательности. 256-битное значение рассматривается
как последовательность шестнадцати 16-битных значений. Сдвиг обозначается Ψ и
определяется следующим образом:
η16 || η15 || ... || η1 - исходное значение
η1 η2 η3 η4 η13 η16 || η16 || ... || η2 - результирующее значение
Результирующее значение хэш-кода определяется следующим образом:
Χ(M, H) =
61
(H
(M
12(S)))
где
H - предыдущее значение хэш-кода,
М - текущий обрабатываемый блок,
Ψi - i-ая степень преобразования Ψ.
Логика выполнения ГОСТ 3411
Входными параметрами алгоритма являются:

исходное сообщение М произвольной длины;

стартовый вектор хэширования Н, длина которого равна 256 битам;

контрольная сумма Σ, начальное значение которой равно нулю и длина равна 256 битам;

переменная L, начальное значение которой равно длине сообщения.
Сообщение М делится на блоки длиной 256 бит и обрабатывается справа налево.
Очередной блок i обрабатывается следующим образом:
1.
H = Χ(Mi, H)
2.
Σ=Σ
3.
L рассматривается как неотрицательное целое число, к этому числу прибавляется 256 и вычисляется
остаток от деления получившегося числа на 2256. Результат присваивается L.
' Mi
Где ' обозначает следующую операцию: Σ и Mi рассматриваются как неотрицательные
целые числа длиной 256 бит. Выполняется обычное сложение этих чисел и находится
495
остаток от деления результата сложения на 2256. Этот остаток и является результатом
операции.
Самый левый, т.е. самый последний блок М' обрабатывается следующим образом:
1.
Блок добавляется слева нулями так, чтобы его длина стала равна 256 битам.
2.
Вычисляется Σ = Σ
3.
L рассматривается как неотрицательное целое число, к этому числу прибавляется длина исходного
сообщения М и находится остаток от деления результата сложения на 2256.
4.
Вычисляется Н = Χ(М', Н).
5.
Вычисляется Н = Χ(L, Н).
6.
Вычисляется Н = Χ(Σ, Н).
' Mi.
Значением функции хэширования является Н.
Коды аутентификации сообщений - МАС
Требования к МАС
Напомним, что обеспечение целостности сообщения - это невозможность изменения
сообщения так, чтобы получатель этого не обнаружил. Под аутентификацией понимается
подтверждение того, что информация получена от законного источника, и получателем
является тот, кто нужно. Один из способов обеспечения целостности - это вычисление
МАС (Message Authentication Code). В данном случае под МАС понимается некоторый
аутентификатор, являющийся определенным способом вычисленным блоком данных, с
помощью которого можно проверить целостность сообщения. В некоторой степени
симметричное шифрование всего сообщения может выполнять функцию аутентификации
этого сообщения. Но в таком случае сообщение должно содержать достаточную
избыточность, которая позволяла бы проверить, что сообщение не было изменено.
Избыточность может быть в виде определенным образом отформатированного
сообщения, текста на конкретном языке и т.п. Если сообщение допускает произвольную
последовательность битов (например, зашифрован ключ сессии), то симметричное
шифрование всего сообщения не может обеспечивать его целостность, так как при
дешифровании в любом случае получится последовательность битов, правильность
которой проверить нельзя. Поэтому гораздо чаще используется критографически
созданный небольшой блок данных фиксированного размера, так называемый
аутентификатор или имитовставка, с помощью которого проверяется целостность
сообщения. Этот блок данных может создаваться с помощью секретного ключа, который
разделяют отправитель и получатель. МАС вычисляется в тот момент, когда известно, что
сообщение корректно. После этого МАС присоединяется к сообщению и передается
вместе с ним получателю. Получатель вычисляет МАС, используя тот же самый
секретный ключ, и сравнивает вычисленное значение с полученным. Если эти значения
совпадают, то с большой долей вероятности можно считать, что при пересылке изменения
сообщения не произошло.
MAC = CK (M)
496
Рассмотрим свойства, которыми должна обладать функция МАС. Если длина ключа,
используемого при вычислении МАС, равна k, то при условии сильной функции МАС
противнику потребуется выполнить 2k попыток для перебора всех ключей. Если длина
значения, создаваемого МАС, равна n, то всего существует 2n различных значений МАС.
Предположим, что конфиденциальности сообщения нет, т.е. оппонент имеет доступ к
открытому сообщению и соответствующему ему значению МАС. Определим усилия,
необходимые оппоненту для нахождения ключа МАС. Предположим, что k > n, т.е. длина
ключа больше длины МАС. Тогда, зная М1 и МАС1 = СK (M1), оппонент может вычислить
МАС1 = СKi (M1) для всех возможных ключей Ki. При этом, по крайней мере, для одного
из ключей будет получено совпадение MACi = MAC1. Оппонент вычислит 2k значений
МАС, тогда как при длине МАС n битов существует всего 2n значений МАС. Мы
предположили, что k > n, т.е. 2k > 2n. Таким образом, правильное значение МАС будет
получено для нескольких значений ключей. В среднем совпадение будет иметь место для
2k / 2n = 2(k-n) ключей. Поэтому для вычисления единственного ключа оппоненту требуется
знать несколько пар сообщение и соответствующий ему МАС.
Таким образом, простой перебор всех ключей требует не меньше, а больше усилий, чем
поиск ключа симметричного шифрования той же длины.
Функция вычисления МАС должна обладать следующими свойствами:
1.
Должно быть вычислительно трудно, зная М и СK (M), найти сообщение М′, такое, что СK(M) =
СK(M′).
2.
Значения СK(M) должны быть равномерно распределенными в том смысле, что для любых
сообщений М и M′ вероятность того, что СK(M) = СK(M′), должна быть равна 2-n, где n - длина
значения МАС.
МАС на основе алгоритма симметричного шифрования
Для вычисления МАС может использоваться алгоритм симметричного шифрования
(например, DES) в режиме СВС и нулевой инициализационный вектор. В этом случае
сообщение представляется в виде последовательности блоков, длина которых равна длине
блока алгоритма шифрования. При необходимости последний блок дополняется справа
нулями, чтобы получился блок нужной длины. Вычисление МАС происходит по
следующей схеме:
МАС1 = EK [P1]
МАС2 = EK [P2
. . .
MAC1]
МАСN = EK [PN
MAC = МАСN
MACN-1]
MAC = МАСN МАС на основе хэш-функции
Другим способом обеспечения целостности является использование хэш-функции. Хэшкод присоединяется к сообщению в тот момент, когда известно, что сообщение корректно.
Получатель проверяет целостность сообщения вычислением хэш-кода полученного
сообщения и сравнением его с полученным хэш-кодом, который должен быть передан
497
безопасным способом. Одним из таких безопасных способов может быть шифрование
хэш-кода закрытым ключом отправителя, т.е. создание подписи. Возможно также
шифрование полученного хэш-кода алгоритмом симметричного шифрования, если
отправитель и получатель имеют общий ключ симметричного шифрования.
НМАС
Еще один вариант использования хэш-функции для получения МАС состоит в том, чтобы
определенным образом добавить секретное значение к сообщению, которое подается на
вход хэш-функции. Такой алгоритм носит название НМАС, и он описан в RFC 2104.
При разработке алгоритма НМАС преследовались следующие цели:

возможность использовать без модификаций уже имеющиеся хэш-функции;

возможность легкой замены встроенных хэш-функций на более быстрые или более стойкие;

сохранение скорости работы алгоритма, близкой к скорости работы соответствующей хэшфункции;

возможность применения ключей и простота работы с ними.
В алгоритме НМАС хэш-функция представляет собой "черный ящик". Это, во-первых,
позволяет использовать существующие реализации хэш-функций, а во-вторых,
обеспечивает легкую замену существующей хэш-функции на новую.
Введем следующие обозначения:
Н - встроенная хэш-функция.
b - длина блока используемой хэш-функции.
n - длина хэш-кода.
K - секретный ключ. К этому ключу слева добавляют нули, чтобы получить b-битовый ключ K+.
Вводится два вспомогательных значения:
Ipad - значение '00110110', повторенное b/8 раз.
Opad - значение '01011010', повторенное b/8 раз.
Далее НМАС вычисляется следующим образом:
НМАС = Н ((K+
Opad) || H ((K+
Ipad) || M))
498
25.Базовые классы и типы данных метамодели языка UML.
3.5. Специфика описания метамодели языка UML
Метамодель языка UML описывается на некотором полуформальном языке с
использованием трех видов представлений:

Абстрактного синтаксиса

Правил правильного построения выражений

Семантики
Абстрактный синтаксис представляет собой модель для описания некоторой части языка
UML, предназначенной для построения диаграмм классов на основе описаний систем на
естественном языке. Возможности абстрактного синтаксиса в языке UML довольно
ограничены и имеют отношение только к интерпретации обозначений отдельных
компонентов диаграмм, связей между компонентами и допустимых дополнительных
обозначений. К элементам абстрактного синтаксиса относятся некоторые ключевые слова
и значения отдельных атрибутов базовых понятий уровня метамодели, которые имеют
фиксированное обозначение в виде текста на естественном языке.
Правила правильного построения выражений используются для задания дополнительных
ограничений или свойств, которыми должны обладать те или иные компоненты модели.
Поскольку исходным понятием ООП является понятие класса, его общими свойствами
должны обладать все экземпляры, которые в этом смысле должны быть инвариантны друг
другу. Для задания этих инвариантных свойств классов и отношений необходимо
использовать специальные выражения некоторого формального языка, в рамках UML
получившего название языка объектных ограничений (Object Constraint Language, ОСЬ).
Хотя язык ОСЬ и использует естественный язык для формулировки правил правильного
499
построения выражений, особенности его применения являются темой самостоятельного
обсуждения. Основные особенности языка ОСЬ рассмотрены в приложении.
Семантика языка UML описывается в основном на естественном языке, но может
включать в себя некоторые дополнительные обозначения, вытекающие из связей
определяемых понятий с другими понятиями. Семантика понятий раскрывает их смысл
или содержание. Сложность описания семантики языка UML заключается именно в
метамодельном уровне представлений его основных конструкций. С одной стороны,
понятия языка UML имеют абстрактный характер (ассоциация, композиция, агрегация,
сотрудничество, состояние). С другой стороны, каждое из этих понятий допускает свою
конкретизацию на уровне модели (сотрудник, отдел, должность, стаж).
Сложность описания семантики языка UML вытекает из этой двойственности понятий.
Здесь мы должны придерживаться традиционных правил изложения, поскольку
понимание семантики носит индуктивный характер и требует для своей интерпретации
примеров уровня модели и объекта. Иллюстрация абстрактных понятий на примере
конкретных свойств и отношений, а также их значений позволяет акцентировать внимание
на общих инвариантах этих понятий, что совершенно необходимо для понимания их
семантики.
Примечание
Таким образом, метамодель языка UML может рассматриваться как комбинация
графической нотации (специальных обозначений), некоторого формального языка и
естественного языка. При этом следует иметь в виду, что существует некоторый
теоретический предел, который ограничивает описание метамодели средствами самой
метамодели. Именно в подобных случаях испрльзуется естественный язык, обладающий
наибольшими выразительными возможностями.
Хотя сам термин "естественный язык" далеко не однозначен и порождает целый ряд
дополнительных вопросов, здесь мы ограничимся его трактовкой в форме обычного
текста на русском невозможно, английском языках. Как бы ни хотелось некоторым из
отечественных разработчиков, полностью избежать использования английского при
описании языка UML не удастся. Тем не менее если исключить написание стандартных
элементов и некоторых ключевых слов, то во всех остальных случаях под естественным
языком можно понимать русский без специальных оговорок.
Для придания формального характера моделям UML использование естественного языка
должно строго соответствовать определенным правилам. Например, описание семантики
языка UML может включать в себя фразы типа "Сущность А обладает способностью" или
"Сущность Б есть сущность В". В каждом из этих случаев мы будем понимать смысл фраз,
руководствуясь традиционным пониманием предложений русского языка. Однако этого
может оказаться недостаточно для более формального представления знаний о
рассматриваемых сущностях. Тогда необходимо дополнительно специфицировать
семантику этих простых фраз, для чего рекомендуется использовать следующие правила:

Явно указывать в тексте экземпляр некоторого метакласса. Речь идет о том, что в
естественной речи мы часто опускаем слово "пример" или "экземпляр", говоря
просто "класс". Так, фразу "Атрибут возраст класса сотрудник имеет значение 30
500
лет" следует записать более точно, а именно: "Атрибут возраст экземпляра класса
сотрудник имеет значение 30 лет".

В каждый момент времени используется только то значение слова, которое
приписано имени соответствующей конструкции языка UML. Все дополнительные
особенности семантики должны быть указаны явным образом без каких бы то ни
было неявных предположений.

Термины языка UML могут включать только один из допустимых префиксов, таких
как под-, супер- или мета-. При этом сам термин с префиксом записывается одним
словом.
В дополнение к этому будут использоваться следующие правила выделения текста:

Если используются ссылки на конструкции языка UML, а не на их представления в
метамодели, следует применять обычный текст без какого бы то ни было
выделения.

Имена метаклассов являются элементом нотации языка UML и представляют собой
существительное и, возможно, присоединенное к нему прилагательное. В этом
случае имя метакласса на английском записывается одним словом с выделением
каждой составной части имени заглавной буквой (например, ModelElement,
StructuralFeature).

Имена метаассоциаций и ассоциаций классов записываются аналогичным образом
(например, ElementReference).

Имена других элементов языка UML также записываются одним словом, но
должны начинаться с маленькой буквы (например, ownedElement, allContents).

Имена метаатрибутов, которые принимают булевы значения, всегда начинаются с
префикса "is" (например, isAbstract).

Перечислимые типы должны всегда заканчиваться словом "Kind" (например,
AggregationKind).

При ссылках в тексте на метаклассы, метаассоциаций, метаатрибуты и т. д. должны
всегда использоваться в точности те их имена, которые указаны в модели.

Имена стандартных обозначений (стереотипов) заключаются в кавычки и
начинаются со строчной буквы (например, "type").
Рассмотренные выше правила выделения текста имеют непосредственное отношение к
англоязычным терминам языка ,UML. Поскольку вопросы локализации языка UML до
настоящего времени не нашли своего отражения в работе OMG, отечественным
специалистам придется самостоятельно дополнять эти правила на случай использования в
качестве естественного русского языка. В книге мы будем придерживаться двух
дополнительных рекомендаций:

При описании семантики языка UML все имена его стандартных элементов
(метаклассов, метаассоциаций, метаатрибутов) допускается записывать на русском
501
с дополнительным указанием оригинального имени на английском. При этом, хотя
имена стандартных элементов могут состоять из нескольких слов, согласно
сложившейся отечественной традиции, будем их записывать раздельно (например,
класс ассоциации, элемент модели, пространство имен).

При разработке конкретных моделей систем в форме диаграмм языка UML
целесообразно применять оригинальные англоязычные термины, придерживаясь
описанных выше правил (кроме, возможно, пояснительного текста на русском).
Причина этой рекомендации вполне очевидна - последующая инструментальная
реализация модели может оказаться невозможной, если не следовать
оригинальным правилам выделения текста в языке UML. Это правило не
распространяется на отдельные примеры и фрагменты диаграмм, которые
приводятся в тексте книги с чисто иллюстративными целями и лишь раскрывают
особенности использования стандартных элементов языка UML.
Примечание
Приведенные дополнительные рекомендации не противоречат оригинальным правилам
языка UML, а только уточняют рамки использования естественного языка при построении
моделей и при описании самого языка. Поскольку описание семантики любого
формального языка связано с проблемой его интерпре-~ тации, полностью обойтись без
естественного языка не представляется возможным. Если вопросы использования
оригинальных терминов при построении логических и физических моделей не вызывают
сомнений у большинства программистов, то процесс построения концептуальных моделей
сложных систем формализован в меньшей степени. Именно по этой причине исходные
требования к системе формулируются на естественном для разработчиков языке (в нашем
случае, на русском). В любом случае эти аспекты использования языков при построении
моделей многогранны и могут служить темой отдельной работы.
В рамках языка UML все представления о модели сложной системы фиксируются в виде
специальных графических конструкций, получивших название диаграмм. В терминах
языка UML определены следующие виды диаграмм:

Диаграмма вариантов использования (use case diagram)

Диаграмма классов (class diagram)

Диаграммы поведения (behavior diagrams)

o
Диаграмма состояний (statechart diagram)
o
Диаграмма деятельности (activity diagram)
o
Диаграммы взаимодействия (interaction diagrams)

Диаграмма последовательности (sequence diagram)

Диаграмма кооперации (collaboration diagram)
Диаграммы реализации (implementation diagrams)
502
o
Диаграмма компонентов (component diagram)
o
Диаграмма развертывания (deployment diagram)
Из перечисленных выше диаграмм некоторые служат для обозначения двух и более
других подвидов диаграмм. При этом в качестве самостоятельных представлений в языке
UML используются следующие диаграммы:
1. Диаграмма вариантов использования (см. главу 4).
2. Диаграмма классов (см. главу 5).
3. Диаграмма состояний (см. главу 6).
4. Диаграмма деятельности (см. главу 7).
5. Диаграмма последовательности (см. главу 8).
6. Диаграмма кооперации (см. главу 9). 1. Диаграмма компонентов (см. главу 10). 8.
Диаграмма развертывания (см. главу 11).
Перечень этих диаграмм и их названия являются каноническими в том смысле, что
представляют собой неотъемлемую часть графической нотации языка UML. Более того,
процесс ООАП неразрывно связан с процессом построения этих диаграмм. При этом
совокупность построенных таким образом диаграмм является самодостаточной в том
смысле, что в них содержится вся информация, которая необходима для реализации
проекта сложной системы.
Каждая из этих диаграмм детализирует и конкретизирует различные представления о
модели сложной системы в терминах языка UML. При этом диаграмма вариантов
использования представляет собой наиболее общую концептуальную модель сложной
системы, которая является исходной для построения всех остальных диаграмм. Диаграмма
классов является, по своей сути, логической моделью, отражающей статические аспекты
структурного построения сложной системы.
Диаграммы поведения также являются разновидностями логической модели, которые
отражают динамические аспекты функционирования сложной системы. И, наконец,
диаграммы реализации служат для представления физических компонентов сложной
системы и поэтому относятся к ее физической модели. Таким образом, интегрированная
модель сложной системы в нотации UML (рис. 3.10) представляется в виде совокупности
указанных выше диаграмм (см. рис. 3.9).
503
Рис. 3.10. Интегрированная модель сложной системы в нотации UML
Примечание
В ранней литературе по UML в качестве отдельной диаграммы рассматривалась еще
диаграмма объектов. Однако в версии 1.3 она не включена в перечень канонических
диаграмм, поскольку ее элементы могут присутствовать на диаграммах других типов.
Поэтому описание отдельных элементов диаграммы объектов рассматривается ниже, при
изучении основных канонических типов диаграмм в части II данной книги.
3.6. Особенности изображения диаграмм языка UML
Большинство перечисленных выше диаграмм являются в своей основе графами
специального вида, состоящими из вершин в форме геометрических фигур, которые
связаны между собой ребрами или дугами. Поскольку информация, которую содержит в
себе граф, имеет в основном топологический характер, ни геометрические размеры, ни
расположение элементов диаграмм (за некоторыми исключениями, такими как диаграмма
последовательностей с метрической осью времени) не имеют принципиального значения.
Для диаграмм языка UML существуют три типа визуальных обозначений, которые важны
с точки зрения заключенной в них информации:

Связи, которые представляются различными линиями на плоскости. Связи в языке
UML обобщают понятие дуг и ребер из теории графов, но имеют менее
формальный характер.

Текрт, который содержится внутри границ отдельных геометрических фигур на
плоскости. При этом форма этих фигур (прямоугольник, эллипс) соответствует
некоторым элементам языка UML (класс, вариант использования) и имеет
фиксированную семантику.

Графические символы, изображаемые вблизи от тех или иных визуальных
элементов диаграмм.
504
Примечание
Все диаграммы в языке UML изображаются с использованием фигур на плоскости.
Однако некоторые из фигур (например, кубы) могут представлять собой двумерные
проекции трехмерных геометрических тел, но и в этом случае они рисуются как фигуры
на плоскости. Хотя в ближайшее время предполагают включить в язык UML
пространственные диаграммы, в рассматриваемой версии языка такая возможность
отсутствует.
Таким образом, в языке UML используется четыре основных вида графических
конструкций:

Значки или пиктограммы. Значок представляет собой графическую фигуру
фиксированного размера и формы. Она не может увеличивать свои размеры, чтобы
разместить внутри себя дополнительные символы. Значки могут размещаться как
внутри других графических конструкций, так и вне их. Примерами значков могут
служить окончания связей элементов диаграмм или некоторые другие
дополнительные обозначения (украшения).

Графические символы на плоскости. Такие двумерные символы изображаются с
помощью некоторых геометрических фигур и могут иметь различную высоту и
ширину с целью размещения внутри этих фигур других конструкций языка UML.
Наиболее часто внутри таких символов помещаются строки текста, которые
уточняют семантику или фиксируют отдельные свойства соответствующих
элементов языка UML. Информация, содержащаяся внутри фигур, имеет важное
значение для конкретной модели проектируемой системы, поскольку
регламентирует реализацию соответствующих элементов в программном коде.

Пути, которые представляют собой последовательности из отрезков линий,
соединяющих отдельные графические символы. При этом концевые точки отрезков
линий должны обязательно соприкасаться с геометрическими фигурами,
служащими для обозначения вершин диаграмм, как принято в теории графов (см.
главу 2). С концептуальной точки зрения путям в языке UML придается особое
значение, поскольку они являются простыми топологическими сущностями. С
другой стороны, отдельные части пути или сегменты могут не существовать сами
по себе вне содержащего их пути. Пути всегда соприкасаются с другими
графическими символами на обеих границах соответствующих отрезков линий.
Другими словами, пути не могут обрываться на диаграмме линией, которая не
соприкасается ни с одним графическим символом. Как отмечалось выше, пути
могут иметь в качестве окончания или терминатора специальную графическую
фигуру - значок, который изображается на одном из концов линий, являющихся
сегментами этого пути.

Строки текста. Служат для представления различных видов информации в
некоторой грамматической форме. Предполагается, что каждое использование
строки текста должно соответствовать синтаксису в нотации языка UML,
посредством которого может быть реализован грамматический разбор этой строки.
Последний необходим для получения полной информации о модели. Например,
строки текста в различных секциях обозначения класса могут соответствовать
505
атрибутам этого класса или его операциям. На использование строк накладывается
важное условие - семантика всех допустимых символов должна быть заранее
определена в языке UML или служить предметом его расширения в конкретной
модели.
При графическом изображении диаграмм следует придерживаться следующих основных
рекомендаций:

Каждая диаграмма должна служить законченным представлением
соответствующего фрагмента моделируемой предметной области. Речь идет о том,
что в процессе разработки диаграммы необходимо учесть все сущности, важные с
точки зрения контекста данной модели и диаграммы. Отсутствие тех или иных
элементов на диаграмме служит признаком неполноты модели и может
потребовать ее последующей доработки.

Все сущности на диаграмме модели должны быть одного концептуального уровня.
Здесь имеется в виду согласованность не только имен одинаковых элементов, но и
возможность вложения отдельных диаграмм друг в друга для достижения полноты
представлений. В случае достаточно сложных моделей систем желательно
придерживаться стратегии последовательного уточнения или детализации
отдельных диаграмм.

Вся информация о сущностях должна быть явно представлена на диаграммах. Речь
идет о том, что, хотя в языке UML при отсутствии некоторых символов на
диаграмме могут быть использованы их значения по умолчанию (например, в
случае неявного указания видимости атрибутов и операций классов), необходимо
стремиться к явному указанию свойств всех элементов диаграмм.

Диаграммы не должны содержать противоречивой информации. Противоречивость
модели может служить причиной серьезнейших проблем при ее реализации и
последующем использовании на практике. Например, наличие замкнутых путей
при изображении отношений агрегирования или композиции приводит к ошибкам
в программном коде, который будет реализовывать соответствующие классы.
Наличие элементов с одинаковыми именами и различными атрибутами свойств в
одном пространстве имен также приводит к неоднозначной интерпретации и может
служить источником проблем.
Примечание
Наличие в инструментальных CASE-средствах встроенной поддержки визуализации
различных диаграмм языка UML позволяет в некоторой степени исключить ошибочное
использование тех или иных графических символов, а также контролировать
уникальность имен элементов диаграмм. Однако, поскольку вся ответсвенность за
окончательный контроль непротиворечивости модели лежит на разработчике, необходимо
помнить, что неформальный характер языка UML может служить источником
потенциальных ошибок, которые в полном объеме вряд ли будут выявлены
инструментальными средствами. Именно это обстоятельство требует от всех
разработчиков глубокого знания нотации и семантики всех элементов языка UML.
506

Диаграммы не следует перегружать текстовой информацией. Принято считать, что
визуализация модели является наиболее эффективной, если она содержит минимум
пояснительного текста. Как правило, наличие больших фрагментов развернутого
текста служит признаком недостаточной проработанности модели или ее
неоднородности, когда в рамках одной модели представляется различная по
характеру информация. Поскольку общая декомпозиция модели на отдельные типы
диаграмм способна удовлетворить самые детальные представления разработчиков
о системе, важно уметь правильно отображать те или иные сущности и аспекты
моделирования в соответствующие элементы канонических диаграмм.

Каждая диаграмма должна быть самодостаточной для правильной интерпретации
всех ее элементов и понимания семантики всех используемых графических
символов. Любые пояснительные тексты, которые не являются собственными
элементами диаграммы (например, комментариями), не должны приниматься во
внимание разработчиками. В то же время отдельные достаточно общие фрагменты
диаграмм могут уточняться или детализироваться на других диаграммах этого же
типа, образуя вложенные или подчиненные диаграммы. Таким образом, модель
системы на языке UML представляет собой пакет иерархически вложенных
диаграмм, детализация которых должна быть достаточной для последующей
генерации программного кода, реализующего проект соответствующей системы.

Количество типов диаграмм для конкретной модели приложения не является
строго фиксированным. Речь идет о том, что для простых приложений нет
необходимости строить все без исключения типы диаграмм. Некоторые из них
могут просто отсутствовать в проекте системы, и этот факт не будет считаться
ошибкой разработчика. Например, модель системы может не содержать диаграмму
развертывания для приложения, выполняемого локально на компьютере
пользователя. Важно понимать, что перечень диаграмм зависит от специфики
конкретного проекта системы.
Любая из моделей системы должна содержать только те элементы, которые определены в
нотации языка UML. Имеется в виду требование начинать разработку проекта, используя
только те конструкции, которые уже определены в метамодели UML. Как показывает
практика, этих конструкций вполне достаточно для представления большинства типовых
проектов программных систем. И только в случае отсутствия необходимых базовых
элементов языка UML следует использовать механизмы их расширения для адекватного
представления конкретной модели системы. При этом не допускается какое бы то ни было
переопределение семантики тех элементов, которые отнесены к базовой нотации
метамодели языка UML.
Примечание
Как не вспомнить в этой связи известный афоризм, получивший название "бритва
Оккама". Суть изречения средневекового ученого-схоласта в достаточно вольном
переводе сводится к следующему: "Не плоди рассуждений больше сущности". Другими
словами, нужно стремиться дополнительно не усложнять и без того сложные модели
систем, а по возможности упрощать их за счет унификации обозначений и семантики
базовых элементов.
507
Процесс построения отдельных типов диаграмм имеет свои особенности, которые тесно
связаны с семантикой элементов этих диаграмм. Сам процесс ООАП в контексте языка
UML получил специальное название - рациональный унифицированный процесс (Rational
Unified Process, RUP). Концепция RUP и основные его элементы разработаны А.
Джекобсоном в ходе его работы над языком UML [18].
Примечание
При дословном переводе термина RUP теряется некоторая дополнительная семантическая
окраска, связанная с двусмысленным толкованием английского Rational. Речь идет о
другом варианте перевода - унифицированный процесс от фирмы Rational Software,
сотрудниками которой являются с некоторых пор его разработчики, включая упомянутого
выше А. Джекобсона.
Суть концепции RUP заключается в последовательной декомпозиции или разбиении
процесса ООАП на отдельные этапы, на каждом из которых осуществляется разработка
соответствующих типов канонических диаграмм модели системы. При этом на начальных
этапах RUP строятся логические представления статической модели структуры системы,
затем - логические представления модели поведения, и лишь после этого - физические
представления модели системы. Как нетрудно заметить, в результате RUP должны быть
построены канонические диаграммы на языке UML, при этом последовательность их
разработки в основном совпадает с их последовательной нумерацией. Таким образом,
порядок изложения канонических диаграмм в части II книги не является случайным, а
определяется общими рекомендациями рационального унифицированного процесса.
26.Алгоритмы асимметричной криптографии.
Основные требования к алгоритмам асимметричного шифрования
Создание алгоритмов асимметричного шифрования является величайшим и, возможно,
единственным революционным достижением в истории криптографии.
Алгоритмы шифрования с открытым ключом разрабатывались для того, чтобы решить две
наиболее трудные задачи, возникшие при использовании симметричного шифрования.
Первой задачей является распределение ключа. При симметричном шифровании
требуется, чтобы обе стороны уже имели общий ключ, который каким-то образом должен
быть им заранее передан. Диффи, один из основоположников шифрования с открытым
ключом, заметил, что это требование отрицает всю суть криптографии, а именно
возможность поддерживать всеобщую секретность при коммуникациях.
Второй задачей является необходимость создания таких механизмов, при использовании
которых невозможно было бы подменить кого-либо из участников, т.е. нужна цифровая
подпись. При использовании коммуникаций для решения широкого круга задач, например
в коммерческих и частных целях, электронные сообщения и документы должны иметь
эквивалент подписи, содержащейся в бумажных документах. Необходимо создать метод,
при использовании которого все участники будут убеждены, что электронное сообщение
508
было послано конкретным участником. Это более сильное требование, чем
аутентификация.
Диффи и Хеллман достигли значительных результатов, предложив способ решения обеих
задач, который радикально отличается от всех предыдущих подходов к шифрованию.
Сначала рассмотрим общие черты алгоритмов шифрования с открытым ключом и
требования к этим алгоритмам. Определим требования, которым должен соответствовать
алгоритм, использующий один ключ для шифрования, другой ключ - для дешифрования, и
при этом вычислительно невозможно определить дешифрующий ключ, зная только
алгоритм шифрования и шифрующий ключ.
Кроме того, некоторые алгоритмы, например RSA, имеют следующую характеристику:
каждый из двух ключей может использоваться как для шифрования, так и для
дешифрования.
Сначала рассмотрим алгоритмы, обладающие обеими характеристиками, а затем перейдем
к алгоритмам открытого ключа, которые не обладают вторым свойством.
При описании симметричного шифрования и шифрования с открытым ключом будем
использовать следующую терминологию. Ключ, используемый в симметричном
шифровании, будем называть секретным ключом. Два ключа, используемые при
шифровании с открытым ключом, будем называть открытым ключом и закрытым ключом.
Закрытый ключ держится в секрете, но называть его будем закрытым ключом, а не
секретным, чтобы избежать путаницы с ключом, используемым в симметричном
шифровании. Закрытый ключ будем обозначать KR, открытый ключ - KU.
Будем предполагать, что все участники имеют доступ к открытым ключам друг друга, а
закрытые ключи создаются локально каждым участником и, следовательно,
распределяться не должны.
В любое время участник может изменить свой закрытый ключ и опубликовать
составляющий пару открытый ключ, заменив им старый открытый ключ.
Диффи и Хеллман описывают требования, которым должен удовлетворять алгоритм
шифрования с открытым ключом.
1.
Вычислительно легко создавать пару (открытый ключ KU , закрытый ключ KR).
2.
Вычислительно легко, имея открытый ключ и незашифрованное сообщение М, создать
соответствующее зашифрованное сообщение:
С = ЕKU[М]
3.
Вычислительно легко дешифровать сообщение, используя закрытый ключ:
М = DKR[C] = DKR[EKU[M]]
4.
Вычислительно невозможно, зная открытый ключ KU, определить закрытый ключ KR.
5.
Вычислительно невозможно, зная открытый ключ KU и зашифрованное сообщение С, восстановить
исходное сообщение М.
Можно добавить шестое требование, хотя оно не выполняется для всех алгоритмов
с открытым ключом:
509
6.
Шифрующие и дешифрующие функции могут применяться в любом порядке:
М = ЕKU[DKR[M]]
Это достаточно сильные требования, которые вводят понятие односторонней функции с
люком. Односторонней функцией называется такая функция, у которой каждый аргумент
имеет единственное обратное значение, при этом вычислить саму функцию легко, а
вычислить обратную функцию трудно.
Y = f(X) - легко
X = f-1(Y) - трудно
Обычно "легко" означает, что проблема может быть решена за полиномиальное время от
длины входа. Таким образом, если длина входа имеет n битов, то время вычисления
функции пропорционально na, где а - фиксированная константа. Таким образом, говорят,
что алгоритм принадлежит классу полиномиальных алгоритмов Р. Термин "трудно"
означает более сложное понятие. В общем случае будем считать, что проблему решить
невозможно, если усилия для ее решения больше полиномиального времени от величины
входа. Например, если длина входа n битов, и время вычисления функции
пропорционально 2n, то это считается вычислительно невозможной задачей. К сожалению,
тяжело определить, проявляет ли конкретный алгоритм такую сложность. Более того,
традиционные представления о вычислительной сложности фокусируются на худшем
случае или на среднем случае сложности алгоритма. Это неприемлемо для криптографии,
где требуется невозможность инвертировать функцию для всех или почти всех значений
входов.
Вернемся к определению односторонней функции с люком, которую, подобно
односторонней функции, легко вычислить в одном направлении и трудно вычислить в
обратном направлении до тех пор, пока недоступна некоторая дополнительная
информация. При наличии этой дополнительной информации инверсию можно вычислить
за полиномиальное время. Таким образом, односторонняя функция с люком принадлежит
семейству односторонних функций fk таких, что
Y = fk(X) - легко, если k и Х известны
X = fk-1(Y) - легко, если k и Y известны
Х = fk-1(Y) - трудно, если Y известно, но k неизвестно
Мы видим, что разработка конкретного алгоритма с открытым ключом зависит от
открытия соответствующей односторонней функции с люком.
Криптоанализ алгоритмов с открытым ключом
Как и в случае симметричного шифрования, алгоритм шифрования с открытым ключом
уязвим для лобовой атаки. Контрмера стандартная: использовать большие ключи.
Криптосистема с открытым ключом применяет определенные неинвертируемые
математические функции. Сложность вычислений таких функций не является линейной от
количества битов ключа, а возрастает быстрее, чем ключ. Таким образом, размер ключа
должен быть достаточно большим, чтобы сделать лобовую атаку непрактичной, и
достаточно маленьким для возможности практического шифрования. На практике размер
ключа делают таким, чтобы лобовая атака была непрактичной, но в результате скорость
шифрования оказывается достаточно медленной для использования алгоритма в общих
510
целях. Поэтому шифрование с открытым ключом в настоящее время в основном
ограничивается приложениями управления ключом и подписи, в которых требуется
шифрование небольшого блока данных.
Другая форма атаки состоит в том, чтобы найти способ вычисления закрытого ключа, зная
открытый ключ. Невозможно математически доказать, что данная форма атаки исключена
для конкретного алгоритма открытого ключа. Таким образом, любой алгоритм, включая
широко используемый алгоритм RSA, является подозрительным.
Наконец, существует форма атаки, специфичная для способов использования систем с
открытым ключом. Это атака вероятного сообщения. Предположим, например, что
посылаемое сообщение состоит исключительно из 56-битного ключа сессии для
алгоритма симметричного шифрования. Противник может зашифровать все возможные
ключи, используя открытый ключ, и может дешифровать любое сообщение,
соответствующее передаваемому зашифрованному тексту. Таким образом, независимо от
размера ключа схемы открытого ключа, атака сводится к лобовой атаке на 56-битный
симметричный ключ. Защита от подобной атаки состоит в добавлении определенного
количества случайных битов в простые сообщения.
Основные способы использования алгоритмов с открытым ключом
Основными способами использования алгоритмов с открытым ключом являются
шифрование/дешифрование, создание и проверка подписи и обмен ключа.
Шифрование с открытым ключом состоит из следующих шагов:
Рис. 7.1. Шифрование с открытым ключом
1.
Пользователь В создает пару ключей KUb и KRb, используемых для шифрования и дешифрования
передаваемых сообщений.
2.
Пользователь В делает доступным некоторым надежным способом свой ключ шифрования, т.е.
открытый ключ KUb. Составляющий пару закрытый ключ KRb держится в секрете.
3.
Если А хочет послать сообщение В, он шифрует сообщение, используя открытый ключ В KUb .
4.
Когда В получает сообщение, он дешифрует его, используя свой закрытый ключ KRb. Никто другой
не сможет дешифровать сообщение, так как этот закрытый ключ знает только В.
Если пользователь (конечная система) надежно хранит свой закрытый ключ, никто не
сможет подсмотреть передаваемые сообщения.
511
Создание и проверка подписи состоит из следующих шагов:
Рис. 7.2. Создание и проверка подписи
1.
Пользователь А создает пару ключей KRA и KUA, используемых для создания и проверки подписи
передаваемых сообщений.
2.
Пользователь А делает доступным некоторым надежным способом свой ключ проверки, т.е.
открытый ключ KUA. Составляющий пару закрытый ключ KRA держится в секрете.
3.
Если А хочет послать подписанное сообщение В, он создает подпись EKRa[M] для этого сообщения,
используя свой закрытый ключ KRA.
4.
Когда В получает подписанное сообщение, он проверяет подпись DKUa[M], используя открытый
ключ А KUA. Никто другой не может подписать сообщение, так как этот закрытый ключ знает
только А.
До тех пор, пока пользователь или прикладная система надежно хранит свой закрытый
ключ, их подписи достоверны.
Кроме того, невозможно изменить сообщение, не имея доступа к закрытому ключу А; тем
самым обеспечивается аутентификация и целостность данных.
В этой схеме все сообщение подписывается, причем для подтверждения целостности
сообщения требуется много памяти. Каждое сообщение должно храниться в
незашифрованном виде для использования в практических целях. Кроме того, копия
сообщения также должна храниться в зашифрованном виде, чтобы можно было проверить
в случае необходимости подпись. Более эффективным способом является шифрование
небольшого блока битов, который является функцией от сообщения. Такой блок,
называемый аутентификатором, должен обладать свойством невозможности изменения
сообщения без изменения аутентификатора. Если аутентификатор зашифрован закрытым
ключом отправителя, он является цифровой подписью, с помощью которой можно
проверить исходное сообщение. Далее эта технология будет рассматриваться в деталях.
Важно подчеркнуть, что описанный процесс создания подписи не обеспечивает
конфиденциальность. Это означает, что сообщение, посланное таким способом,
невозможно изменить, но можно подсмотреть. Это очевидно в том случае, если подпись
основана на аутентификаторе, так как само сообщение передается в явном виде. Но даже
если осуществляется шифрование всего сообщения, конфиденциальность не
обеспечивается, так как любой может расшифровать сообщение, используя открытый
ключ отправителя.
512
Обмен ключей: две стороны взаимодействуют для обмена ключом сессии, который в
дальнейшем можно использовать в алгоритме симметричного шифрования.
Некоторые алгоритмы можно задействовать тремя способами, в то время как другие могут
использоваться одним или двумя способами.
Перечислим наиболее популярные алгоритмы с открытым ключом и возможные способы
их применения.
Алгоритм
Шифрование / дешифрование
Цифровая подпись Обмен ключей
RSA
Да; непригоден для больших блоков Да
Да
DSS
Нет
Да
Нет
Нет
Да
Диффи-Хеллман Нет
Алгоритм RSA
Диффи и Хеллман определили новый подход к шифрованию, что вызвало к жизни
разработку алгоритмов шифрования, удовлетворяющих требованиям систем с открытым
ключом. Одним из первых результатов был алгоритм, разработанный в 1977 году Роном
Ривестом, Ади Шамиром и Леном Адлеманом и опубликованный в 1978 году. С тех пор
алгоритм Rivest-Shamir-Adleman (RSA) широко применяется практически во всех
приложениях, использующих криптографию с открытым ключом.
Алгоритм основан на использовании того факта, что задача факторизации является
трудной, т.е. легко перемножить два числа, в то время как не существует
полиномиального алгоритма нахождения простых сомножителей большого числа.
Алгоритм RSA представляет собой блочный алгоритм шифрования, где зашифрованные и
незашифрованные данные являются целыми между 0 и n -1 для некоторого n.
Описание алгоритма
Алгоритм, разработанный Ривестом, Шамиром и Адлеманом, использует выражения с
экспонентами. Данные шифруются блоками, каждый блок рассматривается как число,
меньшее некоторого числа n. Шифрование и дешифрование имеют следующий вид для
некоторого незашифрованного блока М и зашифрованного блока С.
С = Ме (mod n)
M = Cd (mod n) = (Me)d (mod n) = Med (mod n)
Как отправитель, так и получатель должны знать значение n. Отправитель знает значение
е, получатель знает значение d. Таким образом, открытый ключ есть KU = {e, n} и
закрытый ключ есть KR = {d, n}. При этом должны выполняться следующие условия:
1.
Возможность найти значения е, d и n такие, что Med = M mod n для всех М < n .
2.
Относительная легкость вычисления Ме и Сd для всех значений М < n.
3.
Невозможность определить d, зная е и n.
Сначала рассмотрим первое условие. Нам необходимо выполнение равенства:
Med = М (mod n)
513
Рассмотрим некоторые математические понятия, свойства и теоремы, которые позволят
нам определить e, d и n.
1.
Если (а · b) (a · c) mod n, то b c mod n, если а и n взаимнопростые, т.е gcd (a, n) = 1.
2.
Обозначим Zp - все числа, взаимнопростые с p и меньшие p. Если p - простое, то Zp - это все остатки.
Обозначим w-1 такое число, что w · w-1
1 mod p.
Тогда w Zp z: w · z 1 mod p
Доказательство этого следует из того, что т.к. w и p взаимнопростые, то при
умножении всех элементов Zp на w остатками будут все элементы Zp, возможно,
переставленные. Таким образом, хотя бы один остаток будет равен 1.
3.
Определим функцию Эйлера следующим образом: Φ(n) - число положительных чисел, меньших n и
взаимнопростых с n. Если p - простое, то Φ(р) = p-1.
Если p и q - простые, то Φ(p · q) = (p-1) · (q-1).
В этом случае Zp · q ={0, 1, ј, (p · q - 1)}.
Перечислим остатки, которые не являются взаимнопростыми с p · q:
{p, 2 · p, ј, (q-1)
{q, 2 · q, ј, (p-1)
0
· p}
· q}
Таким образом Φ(p · q) = p · q - [(q-1) + (p-1) + 1] = p · q - (p+q) + 1 = (p-1) · (q-1).
4.
Теорема Ферма.
an-1 1 mod n, если n - простое.
Если все элементы Zn умножить на а по модулю n, то в результате получим все
элементы Zn, быть может, в другом порядке. Рассмотрим следующие числа:
{a mod n, 2 · a mod n, ј, (n-1) · a mod n} являются числами {1, 2, ј, (n-1)}, быть
может, в некотором другом порядке. Теперь перемножим по модулю n числа из
этих двух множеств.
[(a mod n) · (2a mod n) · ... · (n-1)a mod n]
mod n
(n-1)! mod n(n-1)! an-1
(n-1)! mod n
n и (n-1)! являются взаимнопростыми, если n - простое, следовательно, an-1 1 mod
n.
5.
Теорема Эйлера.
aΦ(n) 1 mod n для всех взаимнопростых a и n.
Это верно, если n - простое, т.к. в этом случае Φ(n) = n-1. Рассмотрим множество R
= {x1, x2, ј, xΦ(n)}. Теперь умножим по модулю n каждый элемент этого множества
на a. Получим множество S = {a · x1 mod n, a · x2 mod n, ј, a · xΦ(n) mod n}. Это
множество является перестановкой множества R по следующим причинам.
514
Так как а является взаимнопростым с n и xi являются взаимнопростыми с n, то a · xi
также являются взаимнопростыми с n. Таким образом, S - это множество целых,
меньших n и взаимнопростых с n.
В S нет дублей, т.к. если a · xi mod n = a · xj mod n
x i = xj .
Следовательно, перемножив элементы множеств S и R, получим:
Φ(n)
Φ(n)
∏ (a · xi mod n)
i=1
Φ(n)
Φ(n)
∏ xi mod n
i=1
( ∏ a · xi
i=1
∏ xi ) mod n
i=1
Φ(n)
Φ(n)
( aΦ(n)
∏ xi
i=1
·
( aΦ(n)
∏ xi ) mod n
i=1
1) mod n
Теперь рассмотрим сам алгоритм RSA. Пусть p и q - простые.
n = p · q.
Надо доказать, что M < n: MΦ(n) = M(p-1) · (q-1) 1 mod n
Если gcd (M, n) = 1, то соотношение выполняется. Теперь предположим, что gcd (M, n) 1,
т.е. gcd (M, p · q) 1. Пусть gcd (M, p) 1, т.е. M = c · p gcd (M, q) = 1, так как в
противном случае M = c · p и M = l · q, но по условию M < p · q.
Следовательно,
MΦ(q)
1 mod q
(MΦ(q))(p)
MΦ(n)
1 mod q
1 mod q
По определению модуля это означает, что MΦ(n) = 1 + k · q. Умножим обе части равенства
на M = c · p. Получим
MΦ(n)+1 = c · p + k · q · c · p.
MΦ(n)
1 mod n
Или
MΦ(n)+1
M mod n
Таким образом, следует выбрать e и d такие, что е · d 1 mod (n)
Или e d-1 mod Φ(n)
e и d являются взаимнообратными по умножению по модулю Φ(n). Заметим, что в
соответствии с правилами модульной арифметики, это верно только в том случае, если d
(и следовательно, е) являются взаимнопростыми с Φ(n). Таким образом, gcd (Φ(n), d) = 1.
Теперь рассмотрим все элементы алгоритма RSA.
515
p, q - два простых целых числа - открыто, вычисляемо.
n=p·q
- закрыто, вычисляемо.
d, gcd (Φ(n), d) = 1;
- открыто, выбираемо.
1 < d < Φ(n)
- закрыты, выбираемы.
е d-1 mod Φ(n)
Закрытый ключ состоит из {d, n}, открытый ключ состоит из {e, n}. Предположим, что
пользователь А опубликовал свой открытый ключ, и что пользователь В хочет послать
пользователю А сообщение М. Тогда В вычисляет С = Ме (mod n) и передает С. При
получении этого зашифрованного текста пользователь А дешифрует вычислением М = С d
(mod n).
Суммируем алгоритм RSA:
Создание ключей
Выбрать простые р и q
Вычислить n = p · q
Выбрать d
Вычислить е
gcd (Φ(n), d) = 1; 1 < d < Φ(n)
е = d-1 mod Φ(n)
Открытый ключ KU = {e, n}
Закрытый ключ KR = {d, n}
Шифрование
Незашифрованный текст: М < n
Зашифрованный текст: С = М е (mod n)
Дешифрование
Зашифрованный текст: С
Незашифрованный текст: М = Сd (mod n)
Рассмотрим конкретный пример:
Выбрать два простых числа: р = 7, q = 17.
Вычислить n = p · q = 7 · 17 = 119.
Вычислить Φ(n) = (p - 1) · (q - 1) = 96.
Выбрать е так, чтобы е было взаимнопростым с Φ(n) = 96 и меньше, чем Φ(n): е = 5.
Определить d так, чтобы d · e 1 mod 96 и d < 96.
d = 77, так как 77 · 5 = 385 = 4 · 96 + 1.
Результирующие ключи открытый KU = {5, 119} и закрытый KR = {77, 119}.
Например, требуется зашифровать сообщение М = 19.
195 = 66 (mod 119); С = 66.
Для дешифрования вычисляется 6677 (mod 119) = 19.
Вычислительные аспекты
Рассмотрим сложность вычислений в алгоритме RSA при создании ключей и при
шифровании/дешифровании.
Шифрование/дешифрование
516
Как шифрование, так и дешифрование включают возведение целого числа в целую
степень по модулю n. При этом промежуточные значения будут громадными. Для того,
чтобы частично этого избежать, используется следующее свойство модульной
арифметики:
[(a mod n) · (b mod n)] mod n = (a · b) mod n
Другая оптимизация состоит в эффективном использовании показателя степени, так как в
случае RSA показатели степени очень большие. Предположим, что необходимо вычислить
х16. Прямой подход требует 15 умножений. Однако можно добиться того же конечного
результата с помощью только четырех умножений, если использовать квадрат каждого
промежуточного результата: х2, х4, х8, х16.
Создание ключей
Создание ключей включает следующие задачи:
1.
Определить два простых числа р и q.
2.
Выбрать е и вычислить d.
Прежде всего, рассмотрим проблемы, связанные с выбором р и q. Так как значение n = p ·
q будет известно любому потенциальному противнику, для предотвращения раскрытия р и
q эти простые числа должны быть выбраны из достаточно большого множества, т.е. р и q
должны быть большими числами. С другой стороны, метод, используемый для поиска
большого простого числа, должен быть достаточно эффективным.
В настоящее время неизвестны алгоритмы, которые создают произвольно большие
простые числа. Процедура, которая используется для этого, выбирает случайное нечетное
число из требуемого диапазона и проверяет, является ли оно простым. Если число не
является простым, то опять выбирается случайное число до тех пор, пока не будет
найдено простое.
Были разработаны различные тесты для определения того, является ли число простым.
Это тесты вероятностные, то есть тест показывает, что данное число вероятно является
простым. Несмотря на это они могут выполняться таким образом, что сделают
вероятность близкой к 1. Если n "проваливает" тест, то оно не является простым. Если n
"пропускает" тест, то n может как быть, так и не быть простым. Если n пропускает много
таких тестов, то можно с высокой степенью достоверности сказать, что n является
простым. Это достаточно долгая процедура, но она выполняется относительно редко:
только при создании новой пары (KU, KR).
На сложность вычислений также влияет то, какое количество чисел будет отвергнуто
перед тем, как будет найдено простое число. Результат из теории чисел, известный как
теорема простого числа, говорит, что простых чисел, расположенных около n в среднем
одно на каждые ln (n) чисел. Таким образом, в среднем требуется проверить
последовательность из ln (n) целых, прежде чем будет найдено простое число. Так как все
четные числа могут быть отвергнуты без проверки, то требуется выполнить
приблизительно ln (n)/2 проверок. Например, если простое число ищется в диапазоне
величин 2200, то необходимо выполнить около ln (2200) / 2 = 70 проверок.
517
Выбрав простые числа р и q, далее следует выбрать значение е так, чтобы gcd(Φ(n), e) = 1
и вычислить значение d, d = e-1 mod Φ(n). Cуществует единственный алгоритм,
называемый расширенным алгоритмом Евклида, который за фиксированное время
вычисляет наибольший общий делитель двух целых и если этот общий делитель равен
единице, определяет инверсное значение одного по модулю другого. Таким образом,
процедура состоит в генерации серии случайных чисел и проверке каждого относительно
Φ(n) до тех пор, пока не будет найдено число, взаимнопростое с Φ(n). Возникает вопрос,
как много случайных чисел придется проверить до тех пор, пока не найдется нужное
число, которое будет взаимнопростым с Φ(n). Результаты показывают, что вероятность
того, что два случайных числа являются взаимнопростыми, равна 0.6.
Обсуждение криптоанализа
Можно определить четыре возможных подхода для криптоанализа алгоритма RSA:
1.
Лобовая атака: перебрать все возможные закрытые ключи.
2.
Разложить n на два простых сомножителя. Это даст возможность вычислить Φ(n) = (p-1) · (q-1) и d =
e-1 (mod Φ(n)).
3.
Определить Φ(n) непосредственно, без начального определения р и q. Это также даст возможность
определить d = e-1 (mod Φ(n)).
4.
Определить d непосредственно, без начального определения Φ(n).
Защита от лобовой атаки для RSA и ему подобных алгоритмов состоит в использовании
большой длины ключа. Таким образом, чем больше битов в е и d, тем лучше. Однако, так
как вычисления необходимы как при создании ключей, так и при
шифровании/дешифровании, чем больше размер ключа, тем медленнее работает система.
Большинство дискуссий о криптоанализе RSA фокусируется на задаче разложения n на
два простых сомножителя. В настоящее время неизвестны алгоритмы, с помощью
которых можно было бы разложить число на два простых множителя для очень больших
чисел (т.е. несколько сотен десятичных цифр). Лучший из известных алгоритмов дает
результат, пропорциональный:
L (n) = esqrt
(ln n * ln (ln n))
Пока не разработаны лучшие алгоритмы разложения числа на простые множители, можно
считать, что величина n от 100 до 200 цифр в настоящее время является достаточно
безопасной. На современном этапе считается, что число из 100 цифр может быть
разложено на множители за время порядка двух недель. Для дорогих конфигураций (т.е.
порядка $10 млн) число из 150 цифр может быть разложено приблизительно за год.
Разложение числа из 200 цифр находится за пределами вычислительных возможностей.
Например, даже если вычислительный уровень в 1012 операций в секунду достижим, что
выше возможностей современных технологий, то потребуется свыше 10 лет для
разложения на множители числа из 200 цифр с использованием существующих
алгоритмов.
Для известных в настоящее время алгоритмов задача определения (n) по данным е и n, по
крайней мере, сопоставима по времени с задачей разложения числа на множители.
518
Для того чтобы избежать выбора значения n, которое могло бы легко раскладываться на
сомножители, на р и q должно быть наложено много дополнительных ограничений: р и q
должны друг от друга отличаться по длине только несколькими цифрами. Таким образом,
оба значения р и q должны быть от 1075 до 10100.
Оба числа (р - 1) и (q - 1) должны содержать большой простой сомножитель.
gcd (p -1, q - 1) должен быть маленьким.
Алгоритм обмена ключа Диффи-Хеллмана
Первая публикация данного алгоритма открытого ключа появилась в статье Диффи и
Хеллмана, в которой вводились основные понятия криптографии с открытым ключом и в
общих чертах упоминался алгоритм обмена ключа Диффи-Хеллмана.
Цель алгоритма состоит в том, чтобы два участника могли безопасно обменяться ключом,
который в дальнейшем может использоваться в каком-либо алгоритме симметричного
шифрования. Сам алгоритм Диффи-Хеллмана может применяться только для обмена
ключами.
Алгоритм основан на трудности вычислений дискретных логарифмов. Дискретный
логарифм определяется следующим образом. Вводится понятие примитивного корня
простого числа Q как числа, чьи степени создают все целые от 1 до Q - 1. Это означает,
что если А является примитивным корнем простого числа Q, тогда числа
A mod Q, A2 mod Q, . . . , AQ - 1 mod Q
являются различными и состоят из целых от 1 до Q - 1 с некоторыми перестановками. В
этом случае для любого целого Y < Q и примитивного корня A простого числа Q можно
найти единственную экспоненту Х, такую, что
Y = AХ mod Q, где 0
X
(Q - 1)
Экспонента X называется дискретным логарифмом, или индексом Y, по основанию A mod
Q. Это обозначается как
indA,
Q
(Y).
Теперь опишем алгоритм обмена ключей Диффи-Хеллмана.
Общеизвестные элементы
Q
простое число
A
A < Q и A является примитивным корнем
Q
Создание пары ключей пользователем I
Выбор случайного числа Хi (закрытый ключ) Xi < Q
Вычисление числа Yi (открытый ключ)
Yi = AXi mod Q
Создание открытого ключа пользователем J
Выбор случайного числа Хj (закрытый ключ)
Xj < Q
Вычисление случайного числа Yj (открытый ключ) Yj = AXj mod Q
Создание общего секретного ключа пользователем I
519
K = (Yj)Xi mod Q
Создание общего секретного ключа пользователем J
K = (Yi)Xj mod Q
Предполагается, что существуют два известных всем числа: простое число Q и целое A,
которое является примитивным корнем Q. Теперь предположим, что пользователи I и J
хотят обменяться ключом для алгоритма симметричного шифрования. Пользователь I
выбирает случайное число Хi < Q и вычисляет Yi = AXi mod Q. Аналогично пользователь J
независимо выбирает случайное целое число Хj < Q и вычисляет Yj = AXj mod Q. Каждая
сторона держит значение Х в секрете и делает значение Y доступным для другой стороны.
Теперь пользователь I вычисляет ключ как К = (Yj)Xi mod Q, и пользователь J вычисляет
ключ как K = (Yi)Xj mod Q. В результате оба получат одно и то же значение:
K = (Yj)Xi mod Q
= (AXj mod Q)Xi mod Q
= (AXj )Xi mod Q
по правилам модульной арифметики
= AXj Xi mod Q
= (AXj )Xj mod Q
= (AXi mod Q)Xj mod Q
= (Yi)Xj mod Q
Таким образом, две стороны обменялись секретным ключом. Так как Хi и Хj являются
закрытыми, противник может получить только следующие значения: Q, A, Yi и Yj. Для
вычисления ключа атакующий должен взломать дискретный логарифм, т.е. вычислить
Xj = inda, q (Yj)
Безопасность обмена ключа в алгоритме Диффи-Хеллмана вытекает из того факта, что,
хотя относительно легко вычислить экспоненты по модулю простого числа, очень трудно
вычислить дискретные логарифмы. Для больших простых чисел задача считается
неразрешимой.
Следует заметить, что данный алгоритм уязвим для атак типа "man-in-the-middle". Если
противник может осуществить активную атаку, т.е. имеет возможность не только
перехватывать сообщения, но и заменять их другими, он может перехватить открытые
ключи участников Yi и Yj , создать свою пару открытого и закрытого ключа (Xоп, Yоп) и
послать каждому из участников свой открытый ключ. После этого каждый участник
вычислит ключ, который будет общим с противником, а не с другим участником. Если нет
контроля целостности, то участники не смогут обнаружить подобную подмену.
520
27.Применение технологии .NET. Библиотека классов .NET Framework.
SDI и MDI приложения. Серверные ASP – приложения.
Достоинства платформы .NET
1) Вся платформа .NET основана на единой объектно-ориентированной модели. Что это
значит? Дело в том, что все сервисы, интерфейсы и объекты, которые платформа
предоставляет разработчику объединены в единую иерархию классов. Другими словами,
все, что может вам потребоваться при создании приложений под платформу .NET будет
всегда у вас под рукой. Причем, все это сгруппировано очень удобно и интуитивно
понятно.
2) Приложение, написанное на любом .NET-совместимом языке является
межплатформенным (в идеале). Почему в идеале? Дело в том, что приложение,
написанное, скажем, на том же C#, не зависит от платформы, на которой будет
выполняться, но зато зависит от наличия платформы .NET. Но согласитесь, что намного
легче один раз портировать архитектуру .NET под какую либо систему, после чего без
проблем запускать абсолютно любое .NET приложение. В настоящий момент платформа
.NET портирована на большинство популярных системы, в том числе и на мобильные
системы, такие как MS Windows mobile.
3) В состав платформы .NET входит т.н. "сборщик мусора", который освобождает
ресурсы. Таким образом, приложения защищены от утечки памяти и от необходимости
освобождать ресурсы. Это делает программирование более легким и более безопасным.
4) Приложения .NET используют метаданные, что позволяет им не пользоваться
системным реестром Windows.
5) Любое .NET приложение является автономным, в том смысле, что не зависит от других
программ, в частности от ОС. Установка приложения написанного на одном из .NET
языках может быть произведена обычным копированием файлов (исключение составляет
создание ярлыков в меня "Пуск" и др. местах).
6) Приложения .NET используют безопасные типы, что повышает их надежность,
совместимость и межплатформенность.
7) Приложение, написанное на любом .NET языке взаимодействует с единой моделью
обработки ошибок, что значительно упрощает этот нудный процесс.
8) Приложения написанные на разных могут легко взаимодействовать. Например,
серверная часть может быть написана на C#, а клиентская на Visual Basic.
9) .NET приложения могут быть сертифицированы на безопасность. Это является
особенность промежуточного кода, в который преобразуются все .NET приложения.
521
10) Абсолютно все ошибки обрабатываются механизмом исключительных ситуаций. Это
позволяет избежать разногласия, который иногда возникал при программировании под
Win32.
11) Повторное использование кода стало еще удобнее. Это связано с тем, что
промежуточный язык MSIL не зависит от языка программирования. Например, вы можете
написать программу на C#, а патч к ней писать уже, скажем, на J#. Недостатки
платформы .NET
У любого программного продукта есть свои недостатки, есть они и у платформы .NET. Их
нужно тоже знать.
1) Как это часто бывает, за удобство нужно платить скоростью, так и случилось с .NET.
Приложения, написанные под платформу .NET работают медленнее, это факт. В
некоторых случаях скорость может упасть на 15%, что иногда является неприемлемым
(например, при создании 3D приложений, где бьются за каждый FPS). Задержки в
выполнении связаны с промежуточным языком MSIL, ведь для того чтобы его
скомпилировать в выполняемый файл тоже нужно время. Разумеется, что приложение
компилируется не все сразу, а по частям, равномерно при работе программы.
2) Не на любом языке можно создавать .NET приложения. Дело в том, что первоначально
.NET "затачивался" под C/JAVA-подобные языки. Это породило некоторые трудности с
созданием .NET компиляторов для других языков (особенно экзотических и
узкоспециализированных). В результате этого некоторые функции пришлось решать
нетривиальными способами, что отрицательно сказалось на производительности. Но
постепенно данный недостаток сходит на нет, т.к. разработчики компиляторов поняли
важность платформы .NET и стараются сделать для своих языков достойные
инструменты.
3) Необходимо наличие библиотеки FrameWork. Данный недостаток будет полностью
устранен с выходом Windows Vista, т.к. данная библиотека будет встроена в систему по
умолчанию. Сейчас же наличие FrameWork на компьютерах обычных пользователей
являются редкостью. Они попросту не знают, что это такое.
Объектная архитектура распределенных систем. Понятие о технологии
.NET
Итак, под платформой Microsoft.NET следует понимать интегрированную систему
(инфраструктуру) средств разработки, развертывания и выполнения сложных,
распределенных программных систем.
522

Операционные системы корпорации Microsoft - Windows 2000/XP/ME/CE, представляют собой
базовый уровень платформы MS.Net.

.Net Enterprise Servers являются программными продуктами, использование которых позволяет
снизить сложность разработки сложных программных систем (SQL Server).

.Net Building Block Services) представляют собой готовые "строительные блоки" сложных
программных систем, которые могут быть использованы через Интернет как сервисные услуги.
Набор таких сервисов MS.Net планируется последовательно расширять.

Интегрированная среда разработки приложений Visual Studio.NET (VS.Net) - верхний уровень
MS.Net - обеспечивает возможность создания сложного ПО на основе платформы Windows.

MS.NET Framework является ядром платформы MS.Net, обеспечивая возможность построения и
исполнения .Net приложений.
Здесь набор базовых классов обеспечивает, например, работу со строками, ввод-вывод
данных, многопоточность. Набор классов для работы с данными предоставляют
возможность использования SQL-запросов, ADO.Net и обработки XML данных и так
далее.
Общеязыковая среда выполнения (Common Language Runtime, CLR) активизирует
исполняемый код, выполняет для него проверку безопасности, располагает этот код в
памяти и исполняет его, обеспечивает сборку мусора. Для обеспечения возможности
многоязыковой разработки ПО программный код, получаемого после компиляции
программы на одном из алгоритмических языков платформы MS.Net, представляется на
общем промежуточном языке (Common Intermediate Language или CIL). Сборки (файлы на
CIL) перед своим исполнением с помощью JIT-компилятора (Just-In-Time compilers)
перево