Текст
Б.Д. Виснадул, С.А. Лупин,
С.В. Сидоров, П.Ю. Чумаченко
ОСНОВЫ
КОМПЬЮТЕРНЫХ СЕТЕЙ
Под редакцией Л.Г. Гагариной
Допущено Министерством образования Российской Федерации
в качестве учебного пособия для студентов учреждений
среднего профессионального образования, обучающихся по группе
специальностей 2200 «Информатика и вычислительная техника»
МОСКВА
ИД «ФОРУМ» - ИНФРА-М
2007
УДК 004.6(075.32)
ББК 32.973л723
В53
Рецензенты:
доктор техн, наук, профессор О.И. Лисов-,
кандидат техн, наук, доцент А.А. Петров
Виснадул Б.Д., Лупин С.А., Сидоров С.В., Чумаченко П.Ю.
В53 Основы компьютерных сетей: учеб, пособие / Под ред. Л.Г. Гага-
риной. М.: ИД «ФОРУМ»: ИНФРА-М, 2007. — 272 с.: ил. —
(Профессиональное образование).
ISBN 5-8199-0294-7 (ИД «ФОРУМ»)
ISBN 5-16-002799-8 (ИНФРА-М)
Приведены основные понятия и определения сетевых архитектур, типов,
топологий, методов доступа, сред передачи, аппаратных компонентов ком-
пьютерных сетей. В качестве основополагающих факторов изучения сете-
вого взаимодействия рассмотрены методы пакетной передачи данных, мо-
дель OSI, функции уровней модели OSI, стеки протоколов и особенности
их использования. Изложены также особенности межсетевого взаимодей-
ствия: технологии доступа к глобальным информационным ресурсам, адре-
сация в сетях, способы проверки правильности передачи данных, алгорит-
мы маршрутизации и фильтрации пакетов.
Для студентов средних специальных учебных заведений, обучающихся
по специальностям 2202 «Автоматизированные системы обработки инфор-
мации и управления», 2203 «Программное обеспечение вычислительной
техники и автоматизированных систем»; может быть использовано для са-
мообразования в области информационных технологий.
УДК 004.6(075.32)
ББК 32.973л723
ISBN 5-8199-0294-7 (ИД «ФОРУМ»)
ISBN 5-16-002799-8 (ИНФРА-М)
© Б.Д. Виснадул, 2006
© С.А. Лупин, 2006
© С. В. Сидоров, 2006
© П.Ю. Чумаченко, 2006
© ИД «ФОРУМ», 2006
Введение
Уже сегодня нашу жизнь невозможно представить без Интер-
нета и тех новых возможностей, которые он нам предоставляет.
Доступ к огромному хранилищу информации, причем не только
текстовой, но и мультимедийной, IP-телефония, форумы и чаты,
возможность совместной работы для коллектива, членов которого
разделяют тысячи километров, и еще множество других функций
мы можем получить благодаря сетевым технологиям. Конечно,
можно смотреть телевизор и при этом ничего не знать о телевиде-
нии, как инженерной дисциплине, обеспечивающей нам этот
сервис. Эта книга предназначена для тех, кто не просто является
потребителем благ информационного общества, но относится
к той его наиболее востребованной сегодня части, которая фор-
мирует единое информационное пространство и обеспечивает
комфортное «проживание» в нем остальным гражданам.
Информатизация общества предполагает доступ всех граждан
к тем ресурсам, которые благодаря интеграции становятся обще-
ственным достоянием. Такой доступ, не зависящий от расстоя-
ний до источника информации, возможен только потому, что су-
ществует WWW — всемирная паутина и LAN — локальные сети,
решающие проблему транспорта данных не только через границы
государств, но и через океаны.
Глобальность решаемых задач требует унификации как на ап-
паратном, так и на программном уровне. В настоящей книге под-
робно рассмотрены основные стандарты, обеспечивающие функ-
ционирование локальных и глобальных сетей, принципы работы
устройств коммутации и методы повышения надежности каналов
передачи информации.
Материал пособия прошел апробацию в Московском инсти-
туте электронной техники и используется в учебном процессе
различных факультетов.
Предисловие
В последнее время уже никого не удивляет тот факт, что при
приеме на любую работу преимущества всегда получает тот пре-
тендент, который уверенно владеет средствами вычислительной
техники. Практически во всех крупных и в подавляющем боль-
шинстве средних и мелких компаний весь документооборот реа-
лизуется с использованием современных автоматизированных
систем, использующих персональные компьютеры. Именно этот
факт и заставляет работодателей отдавать предпочтение тем, кто
может назвать себя «уверенным пользователем» офисных прило-
жений. Еще одной особенностью современного этапа развития
средств автоматизации управления, безусловно, является их ори-
ентация на широкое использование сетевых технологий на всех
этапах деятельности предприятия. Именно сети обеспечивают
возможность совместной работы над документами, оператив-
ность принятия управленческих решений, доступ к самой свежей
информации для всех сотрудников компании и ее филиалов. Ко-
нечно, для реализации этих преимуществ сама сеть — коммуни-
кационная среда для приложений — должна функционировать
безупречно, а это возможно только в том случае, если ее проекти-
рованием и обслуживанием занимаются специалисты, разбираю-
щиеся во всех тонкостях сетевых технологий. Можно даже ска-
зать, что сегодня успех работы компании во многом будет зави-
сеть от того, будет ли устойчиво работать ее сеть или нет! Эти
моменты делают сегодня особенно востребованными специали-
стов, владеющих современными сетевыми технологиями и спо-
собных обеспечить работоспособность как аппаратных, так
и программных компонентов сетевой инфраструктуры.
Разобраться в основных вопросах, связанных с функциониро-
ванием современных вычислительных сетей, и помогает данная
книга.
В книге четыре главы — первые три рассматривают теорети-
ческие вопросы, а последняя содержит лабораторный практикум,
закрепляющий пройденный материал. Для лучшего усвоения ма-
Предисловие
5
териала мы рекомендуем читать книгу последовательно, контро-
лируя себя при ответах на вопросы, помешенные после каждой
главы.
В первой главе рассматриваются вопросы, связанные с физи-
ческой реализацией сети: сетевые архитектуры, типы и тополо-
гии, методы доступа к среде передачи, аппаратные компоненты
компьютерных сетей и наиболее популярные сетевые стандарты.
Вторая глава посвящена изучению сетевого взаимодействия:
рассмотрены методы кодирования информации при передаче по
линиям связи, методы пакетной пересылки данных, сетевая мо-
дель OSI и функции ее отдельных уровней, стеки протоколов и
особенности их использования.
В третьей главе изучаются принципы межсетевого взаимодей-
ствия: технологии доступа к глобальным информационным ре-
сурсам, адресация в сетях, способы проверки правильности пере-
дачи данных, алгоритмы маршрутизации и фильтрации пакетов.
Четвертая глава содержит лабораторный практикум из шести
работ, направленный на освоение современных методов работы
с пакетами в сетях. Приведенные примеры программ не только
помогают освоить материал, но могут быть полезны при разра-
ботке пользовательских приложений, поддерживающих обмены
между процессами.
Представленное учебное пособие предназначено, в первую
очередь, студентам учебных заведений среднего профессиональ-
ного образования, обучающимся по специальностям 2201 «Вы-
числительные машины, комплексы, системы и сети», 2202 «Авто-
матизированные системы обработки информации и управления»
(по отраслям), 2203 «Программное обеспечение вычислительной
техники и автоматизированных систем».
Глава 1
ПОСТРОЕНИЕ КОМПЬЮТЕРНЫХ СЕТЕЙ
1.1. Архитектура компьютерных сетей
Компьютерная (вычислительная) сеть или сеть передачи дан-
ных представляет собой некоторую совокупность узлов (компью-
теров, рабочих станций или других устройств), соединенных ком-
муникационными каналами, а также набор оборудования, обес-
печивающего соединение станций и передачу между ними
информации.
Сегодня существует огромное многообразие компьютерных
сетей самых разных назначений, построенных на основе различ-
ных компьютерных и коммуникационных технологий и опреде-
ляемых использованием той или иной сетевой архитектуры.
Сетевая архитектура — это совокупность сетевых аппаратных
и программных решений, методов доступа и протоколов обмена
информацией.
1.1.1. Классификация компьютерных сетей
Многообразие компьютерных сетей можно классифициро-
вать по ряду признаков.
По технологии передачи данных сети делятся на два типа: ве-
щание (или один—ко многим) и соединение точка—точка. В слу-
чае вещания сообщение, отправленное одним компьютером, по-
лучают все компьютеры сети. Соединение точка—точка подразу-
мевает использование индивидуального канала связи для
обменивающихся информацией компьютеров.
По принципу организации обмена данными между абонентами
различают сети, основанные на коммутации:
• каналов;
• сообщений;
• пакетов.
J. 1. Архитектура компьютерных сетей
7
Под коммутацией понимается технология выбора направле-
ния и организации передачи данных в сетях, имеющих несколько
альтернативных маршрутов, по которым может производиться
обмен информацией между двумя узлами.
Передаваемые при этом по сети информационные потоки на-
зываются сетевым трафиком (от англ, traffic — движение).
При коммутации каналов образуется непосредственное со-
единение двух узлов посредством организации последовательно-
сти физических каналов связи.
Сеть с коммутацией каналов — тип коммуникационной сети,
в которой каждой паре абонентов в течение сеанса их информа-
ционного взаимодействия предоставляется физическое соедине-
ние.
При этом на время, в течение которого осуществляется сеанс
связи между двумя абонентами, канал связи становится недоступ-
ным для использования другими абонентами.
Коммутация сообщений подразумевает передачу между або-
нентами информации в виде логически завершенных порций
данных, например телеграмм, писем или отчетов.
При этом сеть с коммутацией сообщений работает аналогич-
но сети с коммутацией каналов, но физические каналы связи за-
нимаются не на период всего сеанса связи, а только на период пе-
редачи сообщения.
Сети с коммутацией сообщений явились прообразом для со-
здания сетей с коммутацией пакетов и в настоящее время практи-
чески не используются.
Коммутация пакетов — технология доставки сообщений, при
которой данные, разбитые на отдельные блоки малых размеров,
называемые пакетами, могут пересылаться из исходного пункта
в пункт назначения по различным маршрутам. Пакеты могут раз-
ными маршрутами достигать своего места назначения, в котором
после прибытия пакетов производится сборка исходных данных.
Сеть с коммутацией пакетов — коммуникационная сеть, со-
стоящая из соединенных друг с другом магистральными каналами
узлов коммутации, в которой данные передаются в виде пакетов,
с промежуточным хранением этих пакетов на узлах коммутации.
В силу малых размеров пересылаемых пакетов физические кана-
лы связи оказываются занятыми в течение минимальных интер-
валов времени, что позволяет практически всегда обеспечить пе-
редачу данных между любыми узлами сети без длительных задер-
8
Глава 1. Построение компьютерных сетей
жек, вызванных необходимостью ожидать, когда же, наконец,
освободится требуемый канал связи.
По территориальной распространенности сети могут быть: ло-
кальные, кампусные, городские, глобальные. Локальная сеть или
локальная вычислительная сеть (Local Area Network — LAN) — это
сеть ЭВМ, включающая в себя компьютеры, расположенные
в пределах одного помещения, здания или небольшой террито-
рии, позволяющая обмениваться данными и совместно использо-
вать различные устройства (принтеры, сканеры и т. п.).
Кампусная сеть — (от англ, campus — университет, территория
университета) сеть, охватывающая территорию университета или
студенческого городка. В России аналогом кампусной сети мож-
но рассматривать домовую сеть, объединяющую несколько сосед-
них домов.
Городская сеть (Metropolitan Area Network — MAN) объединяет
компьютеры на территории городского района или всего города
целиком.
Глобальная сеть (Wide Area Network — WAN) — совокупность
сетей, объединяющих территориально рассредоточенные компь-
ютеры, находящиеся в различных городах и странах.
Кроме того, сети могут различаться по топологии. Топология
сети может быть полносвязная, ячеистая, кольцевая, звезда, дере-
во, общая шина и смешанная.
По скорости передачи данных сети делятся на:
• низкоскоростные (до 10 Мбит/с);
• среднескоростные (до 100 Мбит/с);
• высокоскоростные (свыше 100 Мбит/с).
По типу среды передачи данных сети разделяются на провод-
ные (коаксиальные, на витой парс, оптоволоконные) и беспро-
водные (радиопередача, спутниковые каналы).
По принципу организации иерархии компьютеров сети бывают
одноранговые и с выделенным сервером.
Сервер (от англ, server — служащий, служитель) — это некий
объект, предоставляющий другим объектам, обычно называемым
клиентами, некоторые услуги.
В компьютерных сетях сервером обычно называют компьютер
или программу, которая предоставляет клиентам доступ по сети
к своим службам и ресурсам с целью обмена информацией. Ком-
пьютер или программа, обменивающиеся с сервером информаци-
1.1. Архитектура компьютерных сетей
9
ей и использующие предоставляемые им службы и ресурсы, назы-
ваются клиентом.
В одноранговых сетях все компьютеры имеют одинаковые,
равные права (ранги). В сетях с выделенным сервером различают
две архитектуры использования сервера:
• файл-сервер — данные и программы по треоованию пользо-
вателя пересылаются с сервера ему на компьютер, являю-
щийся клиентом, где могут быть выполнены и обработаны;
• клиент-сервер — выполнение программ и обработка данных
происходят на сервере по запросу пользователя, компью-
тер-клиент которого получает только результаты запроса.
1.1.2. Топологии компьютерных сетей
Топология компьютерной сети — это конфигурация физиче-
ских связей компьютеров или других сетевых устройств друг с
другом.
При увеличении числа связываемых компьютеров или других
сетевых устройств резко возрастает число возможных вариантов
конфигураций связей, т. е. топологий.
Выбор топологии для объединения компьютеров в сеть зави-
сит от различных факторов, например:
• надежности получаемой сети;
• простоты присоединения новых узлов;
• экономических соображений.
Все множество топологий можно условно разделить на пол-
носвязные и неполносвязные.
Полносвязные топологии (рис. l.l) подразумевают наличие
отдельного канала для связи любых двух компьтеров сети. Не-
смотря на кажущуюся простоту, такое решение является очень
громоздким, требует наличия большого количества коммутаци-
онного оборудования и потому является экономически неэффек-
тивным.
Неполносвязные топологии получаются из полносвязных пу-
тем удаления некоторых связей и, следовательно, данные будут
передаваться через промежуточные узлы сети.
Ячеистая топология (рис. 1.2) получается из полносвязной за
счет удаления некоторых возможных связей.
10
Глава 1. Построение компьютерных сетей
Рис. 1.1. П олносвязная
топология для шести узлов
Рис. 1.2. Я чеистая топология
Рис. 1.3. Топология типа
«кольцо»
Кольцевая конфигурация подразумевает соединение компью-
теров в замкнутое кольцо (рис. 1.3). При этом данные передаются
от одного компьютера к другому по кругу до тех пор, пока не най-
дут своего адресата.
Топология звезда образуется, когда каждый компьютер сети
подключается к концентратору по отдельной линии связи
(рис. 1.4). Концентратором может быть как отдельный компью-
тер, так и специальное устройство, способное передавать инфор-
мацию с одного компьютера сети на любой другой или на все
компьютеры сразу.
Дерево — топология, получаемая при объединении несколь-
ких звезд (рис. 1.5). При этом в иерархическом порядке объединя-
ются только концентраторы звезд. Между любыми двумя узлами
в такой сети существует только единственный путь. На сегодняш-
ний момент такая конфигурация построения связи является наи-
более распространенным видом топологии.
J. J. Архитектура компьютерных сетей
11
При использовании топологии общая шина все компьютеры
подключаются к одной линии связи (рис. 1.6), например, это мо-
жет быть высокочастотный кабель или радиочастота. При этом
12
Глава 1. Построение компьютерных сетей
передаваемые в сеть данные становятся доступны всем компьюте-
рам и устройствам, объединенным в сеть.
Смешанная топология характерна для крупных сетей, где мо-
гут быть объединены несколько подсетей, имеющих топологию
разных типов (звезда, кольцо и т. п.).
1.1.3. Среды передачи данных
Среда передачи данных — линии (или каналы) связи, по кото-
рым компьютеры могут обмениваться информацией.
В случае если топология сети не является полносвязной, раз-
личные узлы вынуждены использовать для передачи своих дан-
ных одни и те же линии связи. На рис. 1.7 узлы А и Б используют
общий канал для передачи сообщений узлу В, т. е. среда передачи
данных используется несколькими устройствами или узлами се-
ти. В этом случае среда называется разделяемой.
Подключение компьютера к разделяемой среде осуществляет-
ся с помощью сетевого адаптера.
В зависимости от используемой среды передачи данных ли-
нии связи делятся на:
• проводные;
• кабельные;
• беспроводные.
Проводные линии связи строятся с использованием телефон-
ных или телеграфных проводов. Такая среда обладает низкими
показателями скорости передачи данных и помехозащищенно-
сти, поэтому при построении сети при наличии возможности
предпочитают использовать кабель или радиодиапазон.
Тем не менее на сегодняшний момент существуют быстро
развивающиеся технологии, позволяющие в качестве линий связи
Общий
разделяемый
канал
Рис. 1.7. Использование одного канала связи несколькими узлами
J. I. Архитектура компьютерных сетей
13
использовать электрические провода. Привлекательными такие
технологии делает возможность использования уже проложенных
проводов. По этим проводам осуществляется энергоснабжение
домов, квартир, офисов, предприятий и т. д., а может параллель-
но осуществляться и информационный обмен.
Кабельные линии строятся на основе специальных кабелей,
представляющих собой проводники, заключенные в несколько
слоев изоляции.
Промышленностью выпускается большое число видов кабе-
ля, но для построения компьютерных сетей применяется три ос-
новных типа:
• высокочастотные коаксиальные кабели с медной жилой;
• кабели на основе витых пар медных проводников;
• оптоволоконные (или волоконно-оптические) кабели.
Для кабелей характерны следующие параметры:
• полоса пропускания — частотный диапазон сигналов, про-
пускаемых кабелем;
• задержка распространения сигнала;
• помехозащищенность кабеля — степень защищенности ка-
беля от воздействия помех и наводок, возникающих как во
внешней среде, так и на внутренних проводниках самого ка-
беля;
• затухание — степень потери мощности сигнала на выходе
линии связи по отношению к мощности на входе этой ли-
нии.
• волновое сопротивление (для электрических кабелей) —
полное сопротивление, которое встречает электромагнитная
волна определенной частоты при распространении вдоль
однородной цепи.
Коаксиальный кабель представляет собой центральный мед-
ный проводник, заключенный в металлическую оплетку (экран)
и отделенный от нее диэлектриком. При этом металлическая оп-
летка обычно покрывается внешней изолирующей оболочкой
(рис. 1.8).
Металлическая оплетка в коаксиальном кабеле играет двоя-
кую роль: служит для передачи информации, а также защищает
внутреннюю жилу кабеля от помех, вызываемых посторонними
электромагнитными полями, т. е. экранирует ее.
Наиболее часто коаксиальный кабель применяется в сетях
с топологией типа «общая шина».
14
Глава 1. Построение компьютерных сетей
Рис. 1.8. «Толстый» (а) и «тонкий» (б) коаксиальный кабель:
/ —центральный проводник; 2 — экранирующая оплетка; 3 — изолирующая
оболочка; 4 — диэлектрик
Для построения сетей применяют «толстый» и «тонкий» коак-
сиальный кабель.
«Толстый» коаксиальный кабель (RG-8, RG-11) имеет волно-
вое сопротивление 50 Ом, диаметр центрального медного провода
2,17 мм и внешний диаметр порядка 10 мм.
«Тонкий» коаксиальный кабель (RG-58) имеет такое же, как
у «толстого» коаксиала, волновое сопротивление 50 Ом, диаметр
внутреннего проводника составляет 0,89 мм и внешний диаметр
порядка 5 мм.
Кабель на основе витых пар представляет собой несколько
пар, скрученных попарно медных изолированных проводников,
заключенных в общую диэлектрическую оболочку.
Такой кабель может быть экранированным (Shielded Twisted
Pair — STP) и неэкранированным (Unshielded Twisted Pair —
UTP). В случае экранированного кабеля каждая витая пара поме-
шается в металлическую оплетку. Экранирование витой пары
способствует увеличению помехозащищенности линии связи,
а также улучшению зашиты от «прослушивания».
Кабель на неэкранированной витой паре в настоящее время
являются основной средой передачи данных для неоптических
технологий.
В зависимости от характеристик кабели на витых парах разде-
ляются на пять категорий:
1.1. Архитектура компьютерных сетей
15
Кабели категории 1 (UTP I) применяют там, где требования
к скорости передачи минимальны. Обычно это кабели для пере-
дачи голоса и низкоскоростной передачи данных. До 1983 г. ка-
бель категории 1 был основным кабелем для телефонной развод-
ки в США.
Кабели категории 2 (UTP 2) разработаны фирмой IBM для
применения в собственных кабельных системах. Главное их отли-
чие от кабеля категории 1 — это полоса пропускания 1 МГц.
Кабели категории 3 (UTP 3) имеют полосу пропускания
16 МГц. Использовались как для передачи данных, так и для пе-
редачи голоса, поэтому в настоящее время кабельные системы
многих зданий построены на кабеле третьей категории.
Кабели категории 4 (UTP 4) представляют собой улучшенный
вариант кабеля категории 3 — полоса пропускания 20 МГц, повы-
шенная помехоустойчивость и низкие потери. На практике при-
менялся редко, в основном там, где было необходимо увеличить
длину сегмента сети.
Кабели категории 5 (UTP 5) специально разработаны для под-
держки высокоскоростных технологий. Полоса пропускания ка-
беля категории 5—100 МГц. Кабель категории 5 в настоящее вре-
мя заменил кабель категории 3, и все новые технологии локаль-
ных сетей ориентируются именно на него.
Особое место занимают кабели категорий 6 и 7, которые вы-
пускаются сравнительно недавно и имеют полосу пропускания
200 и 600 МГц соответственно. Кабели категории 7 обязательно
экранируются; категории 6 могут быть как экранированными, так
и нет. Они используются в высокоскоростных сетях на отрезках
большей длины, чем кабели пятой категории. Эти кабели значи-
тельно дороже и по стоимости приближаются к волоконно-опти-
ческим кабелям. Кроме того, они пока не унифицированы и их
характеристики определяются только фирменными стандартами.
Оптоволоконный кабель состоит из одного или нескольких
оптических волокон (световодов), сделанных из кварцевого стек-
ла и заключенных в общую защитную оболочку. При необходи-
мости кабель может содержать элементы, повышающие прочно-
стные характеристики кабеля.
Каждый световод состоит из стеклянной сердцевины (цен-
трального проводника), обладающей высоким показателем пре-
ломления, и стеклянной оболочки, обладающей низким показа-
телем преломления света. За счет этого лучи света распространя-
16
Глава 1. Построение компьютерных сетей
Рис. 1.9. Типы оптоволоконного кабеля:
а — многомодовое волокно со ступенчатым изменением показателя преломления;
б — многомодовое волокно с плавным изменением показателя преломления;
в — одномодовое волокно; / — мода 1; 2 — мода 2; 3 — стеклянная оболочка;
4 — сердцевина
ются по сердцевине, последовательно отражаясь от внутренней
границы стеклянной оболочки.
В зависимости от характера распространения света оптоволо-
конный кабель делится на (рис. 1.9):
• одномодовое волокно;
• многомодовое волокно со ступенчатым изменением показа-
теля преломления;
• многомодовое волокно с плавным изменением показателя
преломления.
Мода луча — это угол отражения луча в сердцевине.
В одномодовых кабелях применяются сердцевины с очень ма-
лым диаметром — 8—9 мкм, что соизмеримо с длиной волны све-
та, поэтому в таком кабеле возможно существование только од-
ной моды.
На рынке распространен одномодовый кабель 9/125 мкм.
В этом обозначении 9 мкм соответствует диаметру сердцевины
оптоволокна, а 125 мкм — диаметру стеклянной оболочки.
Производство стеклянного волокна столь малого диаметра яв-
ляется сложным технологическим процессом, что делает одномо-
довый кабель весьма дорогим. Однако его характеристики, по
1.1. Архитектура компьютерных сетей
17
сравнению с более дешевыми многомодовыми кабелями, сущест-
венно выше, что позволяет использовать его при передаче данных
на большие расстояния.
В многомодовом оптоволокне используются более широкие
сердечники, что делает их дешевле, нежели одномодовый кабель.
Наиболее распространены многомодовые кабели 50/125 мкм
и 62,5/125 мкм. В сердцевине такого диаметра свет может рас-
пространяться по различным путям, отражаясь под разными
углами — существует более одной моды луча.
Множество мод приводит к дисперсии импульса передачи,
интерференции лучей, что в итоге приводит к ухудшению харак-
теристик кабеля. Поэтому многомодовые кабели используются
в основном при передаче данных на небольшие расстояния
(до 2000 м) на скоростях не более 1 Гбит/с.
При передаче по оптоволоконным кабелям в качестве источ-
ника света используются полупроводниковые лазеры или свето-
диоды. Длина волны излучаемого ими света обычно равна 850,
1300 или 1550 нм, что соответствует определенным «окнам про-
зрачности» самого волокна.
Беспроводные линии связи используют для передачи данных
радиоволны либо инфракрасное излучение. Каналы связи строят-
ся с помощью передатчика и приемника соответствующих радио-
волн, а отличаются используемым частотным диапазоном и даль-
ностью, на которую возможна передача.
1.1.4. Методы доступа к среде передачи данных
При построении сетей необходимо определить методы или
правила, согласно которым рабочие станции, подключенные
к сети, смогут получать доступ к разделяемой среде передачи дан-
ных и, соответственно, праву на передачу.
Методы доступа к среде передачи делятся на централизован-
ные и децентрализованные.
В централизованных методах все управление доступом сосре-
доточено в одном узле (центре). Недостатки таких методов: неус-
тойчивость к отказам центра, малая гибкость управления, так как
центр обычно не может оперативно реагировать на все события
в сети. Достоинство централизованных методов — отсутствие
18
Глава 1. Построение компьютерных сетей
конфликтов, так как центр всегда предоставляет право на переда-
чу только одному абоненту, которому не с кем конфликтовать.
В децентрализованных методах центр управления отсутствует.
Управление доступом, в том числе предотвращение, обнаружение
и разрешение конфликтов, осуществляется всеми абонентами се-
ти. Главные достоинства децентрализованных методов: высокая
устойчивость к отказам и большая гибкость. Однако в данном
случае возможны конфликты, которые необходимо разрешать.
Децентрализованные методы делятся на детерминированные
и случайные.
Детерминированные методы определяют четкие правила, по
которым осуществляется порядок предоставления доступа або-
нентам сети. Абоненты имеют определенную систему приорите-
тов, причем приоритеты эти различны для всех абонентов. Кон-
фликты при этом практически полностью исключены.
Случайные методы подразумевают произвольный (случай-
ный) порядок получения доступа к среде передачи. При этом воз-
можность возникновения конфликтов подразумевается, но опре-
делены и способы их разрешения. Случайные методы не гаран-
тируют абоненту время доступа. Но зато они обычно более
устойчивы к отказам сетевого оборудования и более эффективно
используют сеть при малой интенсивности обмена.
Одним из самых распространенных методов доступа к среде
передачи является метод множественного доступа с прослушива-
нием несущей и разрешением коллизий (Carrier Sense Multiply
Access with Collision Detection — CSMA/CD).
Метод заключается в том, что сетевой адаптер прослушивает
среду передачи (Carrier Sense), будь то кабель или радиочастота,
чтобы определить, свободна ли она в данный момент времени.
Если среда передачи свободна, то сетевой адаптер начинает пере-
дачу кадра.
Кадр (или пакет) — это единица информации, пересылаемая
с одного компьютера на другой.
Если в среде передачи обнаруживается сигнал, свидетельст-
вующий об уже ведущейся передаче данных, то сетевой адаптер
откладывает передачу своих кадров на некоторый интервал вре-
мени, по истечении которого попытка получить доступ к среде
передачи и, соответственно, разрешение на передачу данных
предпринимается вновь.
1.1. Архитектура компьютерных сетей
19
После завершения передачи кадра любой узел должен выж-
дать паузу — межкадровый интервал (Inter Packet Gap — IGP), —
равную 9,6 нс.
В случае, когда одновременно два сетевых адаптера прослу-
шивают среду, обнаруживают, что она не занята передачей, и на-
чинают одновременно передавать свои кадры, происходит ошиб-
ка передачи — коллизия.
Поскольку время распространения сигнала в среде переда-
чи величина, отличная от нуля, то коллизия может возникнуть
и в том случае, когда сигнал, переданный с одной рабочей стан-
ции, еще не дошел до другой. Эта станция, прослушав среду, и ре-
шив, что среда передачи не занята, начинает пересылку своих
кадров, что и приводит к сбою.
Каждый сетевой адаптер должен постоянно прослушивать
среду передачи данных, в том числе и во время своей передачи,
это позволяет более быстро обнаружить коллизию в сети и при-
нять меры по ее устранению.
При обнаружении коллизии (Collision Detection) рабочие
станции прерывают передачу данных и переходят в режим ожида-
ния. Продолжительность режима ожидания у каждой станции вы-
бирается случайным образом и может составлять от 0 до 52,4 мс.
После истечения режима ожидания производится попытка завла-
деть средой передачи данных и возобновить прерванную пере-
сылку кадров. Таким образом, метод доступа к среде передачи
данных для технологии Ethernet имеет случайный характер.
Другим методом доступа к среде передачи является маркер-
ный метод доступа. Этот метод применяется в сетях с топологией
«кольцо» и имеет детерминированный характер. Суть этого мето-
да заключается в поочередной передаче права на пересылку кад-
ров от одного компьютера сети к другому. Это право передается
с помощью маркера — кадра специального формата.
Сеть с маркерным доступом контролируется активным мони-
тором — рабочей станцией сети, которая выбирается при инициа-
лизации сети. Одной из функций активного монитора является
генерация маркера, который передается следующей по кругу
станции.
Кроме того, активный монитор осуществляет контроль над
наличием маркера в сети. Если после генерации и посылки мар-
кера, он не возвращается к активному монитору, то по истечении
20
Глава 1. Построение компьютерных сетей
определенного времени генерируется и запускается в кольцо но-
вый маркер.
При получении маркера станция проверяет наличие данных,
которые требуется переслать. Если таковые отсутствуют, то маркер
передается далее по кольцу. Если имеются данные для пересылки,
то станция изымает маркер из кольца и начинает передачу кадров.
Данные в сети с маркерным доступом передаются последова-
тельно от одной рабочей станции к другой в одном направлении.
Все станции в сети, получив кадр, ретранслируют его далее по
кольцу. Если адресатом полученного кадра является данная стан-
ция, то она копирует этот кадр во внутренний буфер и добавляет
в него признак подтверждения приема.
Обойдя круг по кольцу, кадры возвращаются с пометкой о под-
твержденном приеме на породившую их станцию, которая изыма-
ет их из кольца, после этого передает маркер другой машине.
Существует такое понятие как время удержания маркера —
это время, в течение которого машина может передавать свои
данные в сеть. По истечении этого временного интервала должна
быть завершена передача текущего кадра, после этого маркер пе-
редается далее по кольцу.
Все кадры в такой сети имеют различные приоритеты от низ-
шего (0) до высшего (7). Если приоритет кадров для пересылки
соответствует приоритету маркера или выше него, то только
в этом случае станция может захватить переданный ей маркер,
иначе она должна передать его дальше по сети.
Еще один метод доступа к разделяемой среде передачи дан-
ных называется приоритетным доступом по требованию (Demand
Priority).
Суть метода заключается в передаче концентратору функций
арбитра сети, который разрешает порядок доступа к разделяемой
среде.
Концентратор — это многопортовый повторитель.
Повторитель — устройство, дублирующее получаемые сигналы.
То есть информация, поступившая на один из портов концен-
тратора, дублируется на всех остальных его портах.
При работе по методу приоритетного доступа по требованию
концентратор циклически опрашивает свои порты. Если рабочей
станции необходимо передать данные, она передает на порт кон-
центратора специальный сигнал, а также сообщает приоритет —
низкий или высокий — кадра, который собирается передать.
1.2. Аппаратные компоненты локальных компьютерных сетей 21
Если сеть свободна, то концентратор разрешает передачу. По-
лучив от станции кадр, концентратор пересылает его по адресу
назначения. Если сеть занята, то заявка на передачу данных ста-
вится в очередь и далее обрабатывается в соответствии с поряд-
ком поступления заявок от других станций, а также приоритетов
их кадров.
Высокий приоритет соответствует данным, чувствительным
к временным задержкам, например голос, видеоизображение,
кадры приложений, работающих в реальном времени. Обычные
данные, для которых фактор времени менее важен, имеют низкий
приоритет. Кроме того, в методе приоритетного доступа по требо-
ванию учитывается частота получение доступа к среде передачи
рабочими станциями. То есть если станция в течение продолжи-
тельного времени не получала разрешение на передачу, то при-
оритет ее кадров повышается.
1.2. Аппаратные компоненты локальных
компьютерных сетей
Любая компьютерная сеть представляет собой довольно слож-
ный комплекс программных и аппаратных средств, осуществляю-
щих связь компьютеров и других устройств между собой.
В основе аппаратной части локальной сети лежат стандарти-
зованные компьютерные платформы различных классов — от
персональных компьютеров до мэйнфреймов и суперЭВМ. Ис-
пользование тех или иных компьютерных платформ, а также про-
чих аппаратных средств обосновывается набором задач, на реше-
ние которых ориентирована создаваемая сеть.
Кроме того, к аппаратной составляющей компьютерной сети
относятся кабельные системы линий связи и коммуникационное
оборудование, позволяющее объединять отдельные сегменты се-
ти и организовывать информационные потоки.
1.2.1. Структурированная кабельная система
Кабельная система является базой для любой сети. Если ка-
бель низкого качества, неграмотно проложен и подключен, то ни-
какое оборудование не заставит работать сеть надежно и устой-
чиво. Очень часто будут возникать проблемы при расширении
22
Глава 1. Построение компьютерных сетей
кабельной системы, подключении новых сегментов кабеля или
других кабельных подсистем.
Существует ряд стандартов и методик по построению кабель-
ной системы, позволяющий обеспечить надлежащую работу сети
и более легкое ее обслуживание, ремонт и масштабирование. По-
строенная таким образом кабельная система называется структу-
рированной.
Структурированная кабельная система (СКС) — это набор
коммутационных элементов (кабелей, разъемов, соединителей,
специальных шкафов, кронштейнов, кабель-каналов и т. д.), со-
вместное использование которых закреплено определенной мето-
дикой.
Структурированная кабельная система строится из стандарт-
ных элементов, модулей, позволяющих достаточно просто ме-
нять конфигурацию связей и подключений кабеля. За счет этого
систему легко наращивать и масштабировать при увеличении
зоны охвата сети или переходе на новое более совершенное обо-
рудование.
Кроме того, за счет модульности структурированная кабель-
ная система позволяет снизить затраты на ее обслуживание
и ремонт.
Очень часто, говоря о СКС, имеют в виду не только линии
связи, обеспечивающие работу сети. Структурированная кабель-
ная система подразумевает единую среду, единую структуру для
передачи практически любых видов данных — от компьютерных
до телевизионных и видеосигналов, от телефонных разговоров до
сигналов с датчиков систем безопасности здания.
Но за все преимущества СКС приходится расплачиваться. Со-
отношение стоимости построения структурированной кабельной
системы по сравнению с более простым бюджетным вариантом
решения составляет примерно 4:1.
1.2.2. Сетевые адаптеры
Сетевой адаптер (Network Interface Card — NIC) — это пери-
ферийное устройство компьютера. Именно сетевой адаптер непо-
средственно взаимодействует со средой передачи данных, кото-
рая прямо или через коммуникационное оборудование связывает
его с другими компьютерами.
1.2. Аппаратные компоненты локальных компьютерных сетей 23
В зависимости от технологии построения сети, с которой
работает адаптер, они делятся на Ethernet-адаптеры, Token
Ring-адаптеры, FDDI-адаптеры и т. д.
Как правило, сетевые адаптеры выполняются в виде отдель-
ной платы, вставляемой в слоты расширения системной ши-
ны компьютера. Плата сетевого адаптера обычно имеет также
один или несколько внешних разъемов для подключения к ней
кабеля сети.
К основным функциям сетевых адаптеров относятся:
• гальваническая развязка компьютера и кабеля локальной
сети;
• кодирование и декодирование данных;
• опознавание принимаемых кадров (передача на компьютер
только тех пакетов, которые адресованы данной рабочей
станции);
• буферизация передаваемой и принимаемой информации
в буферной памяти адаптера;
• организация доступа к сети в соответствии с принятым ме-
тодом доступа к среде передачи данных.
Для обеспечения взаимодействия компьютера с подключен-
ным к нему сетевым адаптером необходим драйвер, который
обеспечивает управление сетевым адаптером, а также позволяет
производить его настройку и конфигурирование.
Главной задачей сетевых адаптеров является прием и передача
данных. На практике эта функция разделена между самим адапте-
ром и его драйвером. В некоторых моделях адаптеров большая
часть работы с данными передается драйверу адаптера, в этом
случае увеличивается загрузка центрального процессора компью-
тера, на котором этот драйвер работает, но адаптер становится
проще и дешевле. Обычно такие адаптеры устанавливаются на
клиентские машины. На серверы устанавливают более сложные
и дорогие адаптеры, снабженные собственными микропроцессо-
рами, которые самостоятельно выполняют основную работу по
приему и передаче данных.
В ходе развития компьютерных и сетевых технологий было
разработано несколько поколений сетевых адаптеров.
Адаптеры первого поколения были выполнены на дискретных
логических микросхемах. Они имели буферную память только на
один кадр, при этом все кадры передавались из компьютера в сеть
или из сети в компьютер последовательно, что приводило к низ-
24
Глава 1. Построение компьютерных сетей
кой производительности адаптера. Конфигурирование адаптера
происходило вручную, с помощью перемычек. Для каждого типа
адаптеров использовался свой драйвер, причем интерфейс между
драйвером и операционной системой не был стандартизирован.
Сетевые адаптеры второго поколения строились на основе
микросхем с высокой степенью интеграции, что повышало на-
дежность адаптеров. Кроме того, драйверы этих адаптеров были
основаны на стандартных спецификациях.
Сетевые адаптеры второго поколения обладали более высокой
производительностью, которую обеспечивал используемый ими
метод многокадровой буферизации. Суть метода заключалась в
одновременной выгрузке кадра данных из буфера памяти адапте-
ра и загрузке туда следующего кадра.
Адаптеры третьего поколения базируются на специализиро-
ванных интегральных схемах, что повышает производительность
и надежность адаптера при одновременном снижении его стои-
мости.
В сетевых адаптерах третьего поколения осуществляется кон-
вейерная схема обработки кадров, при которой процессы приема
кадра из оперативной памяти компьютера и передачи его в сеть
совмещаются во времени. Таким образом, после приема несколь-
ких первых байт кадра начинается их передача. Такой алгоритм
передачи данных от компьютера в сеть и обратно является весьма
сложным и требует специальной настройки в зависимости от ха-
рактеристик работы компьютера и сети. При этом сетевые адапте-
ры третьего поколения способны сами в автоматическом режиме
без участия оператора произвести такую настройку и выбрать оп-
тимальный режим работы.
Выпускаемые сегодня сетевые адаптеры можно отнести к чет-
вертому поколению. В эти адаптеры обязательно входит специа-
лизированная интегральная схема, выполняющая помимо основ-
ных большое количество дополнительных функций по обработке
и пересылке данных.
1.2.3. Концентраторы
Концентратор или хаб (от англ, hub) — специальное много-
портовое устройство, основная функция которого — повторение,
кадра с одного из портов на другие.
1.2. Аппаратные компоненты локальных компьютерных сетей 25
К портам концентратора с помощью отдельных сегментов ка-
беля подключаются узлы сети: компьютеры, сетевые принтеры и
накопители, другие концентраторы или прочее коммутационное
оборудование.
Конструктивное устройство, алгоритмы работы, функции,
характеристики концентраторов зависят от области их примене-
ния. Поэтому для каждого типа технологии построения сети
производятся свои концентраторы: Ethernet, Token Ring, FDDI,
lOOVG-AnyLAN, предназначенные для работы именно по этой
технологии. Например, для концентраторов, работающих в сетях
Ethernet, функция повторения кадра выполняется для всех
портов, для концентраторов lOOVG-AnyLAN повторение кадра
происходит только в порту, к которому подключен адресат
этого кадра.
Помимо основной функции — повторения, ретрансляции
кадров, концентраторы могут выполнять дополнительные функ-
ции, например отключение неработающих портов или. усиление
передаваемых сигналов.
В сетях Ethernet, построенных на коаксиальном кабеле, для
соединения сегментов сети использовались двухпортовые кон-
центраторы, называемые повторителями. Повторители объединя-
ли в единую среду передачи данных, в общую шину несколько от-
резков кабеля, к которым подключались рабочие станции. По ме-
ре развития сетевых технологий и перехода на другие виды
физической среды передачи, концентраторы сами стали своего
рода общей шиной, к которой с помощью витых пар или оптово-
локна подключались компьютеры.
Существующие различия при выполнении основной функции
концентраторов не очень велики, но их намного превосходит раз-
брос в возможностях реализации концентраторами дополнитель-
ных функций.
В зависимости от области применения концентраторы произ-
водятся:
• с фиксированным количеством портов;
• как модульные устройства на основе шасси;
• со стековой конструкцией.
Концентратор с фиксированным количеством портов, напри-
мер концентратор на 5, 8, 16, 24 порта, представляет собой от-
дельный корпус с расположенными на нем портами, элементами
индикации и управления.
26
Глава 1. Построение компьютерных сетей
Модульный концентратор имеет общее шасси с внутренней
шиной, к которой подключаются модули, имеющее фиксирован-
ное количество портов. Для модульного концентратора могут су-
ществовать различные типы модулей, различающиеся количест-
вом портов и типом поддерживаемой физической среды. Такие
концентраторы обычно используются в крупных корпоративных
сетях.
Стековый концентратор, как и концентратор с фиксирован-
ным числом портов, выполнен в виде отдельного корпуса без воз-
можности замены отдельных его модулей. Однако стековые кон-
центраторы имеют специальные порты и кабели для объединения
нескольких таких корпусов в единый повторитель. Скорость ра-
боты внутренней шины концентратора значительно выше, чем
скорость, с которой он может передавать данные, поэтому при
объединении внутренних шин нескольких стековых концентрато-
ров скорость их взаимодействия между собой оказывается выше,
чем при соединении через порт. Необходимо помнить, что число
сегментов сети всегда ограничено. С точки зрения «правила 4 ха-
бов» объединение стековых концентраторов воспринимается как
один концентратор.
1.2.4. Мосты
При расширении сети, увеличении числа работающих в ней
станций возникает проблема перегрузки каналов связи. При до-
стижении некоторого порогового значения числа подключенных
к сети компьютеров пропускная способность сети начинает стре-
мительно убывать, а продолжительность задержек перед получе-
нием доступа к разделяемой среде — увеличиваться.
Для решения этой проблемы сеть начали разделять на не-
сколько сред передачи данных, объединенных мостами.
Мост (bridge) — специальное устройство, ретранслирующее
получаемые из одного сегмента сети кадры в другой сегмент.
Но в отличие от повторителя или концентратора, мост анализиру-
ет адрес назначения кадра. Кадр повторяется в другой сегмент се-
ти только в том случае, если в этом сегменте находится адресат,
т. е. сеть разбивается на несколько подсетей, которые разделяют
между собой и объемы передаваемой между станциями информа-
ции, снижая загруженность на общем канале связи (рис. 1.Ю).
1.2. Аппаратные компоненты локальных компьютерных сетей 27
Рис. 1.10. Разделение сети на подсети с помощью моста
При этом меняется только логическая структура сети, физическое
расположение узлов и их связей остается прежним.
При построении сети как совокупности подсетей каждая под-
сеть может быть адаптирована к специфическим потребностям
рабочей группы или отдела. Например, в одной подсети может
использоваться технология Ethernet, в другой — Token Ring, при
этом рабочие станции одной подсети могут обмениваться данны-
ми с рабочими станциями другой подсети.
Кроме того, использование логического деления на подсети
повышает безопасность данных, ограничивая доступ к ним от-
дельных пользователей.
В основе работы мостов могут лежать следующие принципы:
• прозрачный мост;
• маршрутизация по источнику.
При работе в сети с прозрачным мостом сетевые адаптеры
не предпринимают каких-либо дополнительных действий для
продвижения кадра через мост. Они «не видят» прозрачных мос-
тов и работают так, словно это обычная сеть. Это осуществляется
за счет того, что мост строит особую адресную таблицу, на осно-
вании которой принимает решение, передавать ли полученный
кадр в другой сегмент или нет.
28
Глава 1. Построение компьютерных сетей
Мост принимает все передаваемые по сети данные и записы-
вает их в свой буфер, из которого данные поступают на обработ-
ку. Обработка кадров при работе моста происходит последова-
тельно по мере их поступления. У полученных кадров анализиру-
ются адрес источника и адрес назначения. Если мосту известно,
в каких сегментах находятся отправитель и адресат кадра, то он
производит передачу кадра в нужный сегмент. При этом если от-
правитель и адресат находятся в одном сегмента, то передача
не происходит, а кадр просто удаляется из буфера.
Если мост не знает адресов, полученных вместе с кадром, то
он ретранслирует кадр во все сегменты, за исключением того,
с которого данный кадр пришел. При этом он записывает незна-
комые адреса в адресную таблицу.
Таким образом, в ходе работы мост самообучается, узнавая
расположение по сегментам подключенных узлов. После само-
обучения мост передает кадры только в сегмент назначения,
уменьшая тем самым общий объем передаваемых по сети данных.
Для соединения колец Token Ring и FDDI иногда применяют
мосты с маршрутизацией по источнику.
Метод «маршрутизация по источнику» основан на том, что
станция-отправитель помещает в пересылаемый в другое коль-
цо-кадр адресную информацию о промежуточных мостах и коль-
цах, которые должен пройти кадр перед тем, как попасть в коль-
цо, к которому подключена станция-адресат.
Для определения маршрутов от одной станции до другой ис-
пользуются специальные кадры-исследователи, генерируемые
станциями отправителя и адресата, и передаваемые по сети в ши-
роковещательном режиме. Полученные таким образом маршру-
ты, практически всегда являющиеся оптимальными, сохраняются
в таблицах маршрутизации рабочих станций.
Для использования мостов с маршрутизацией по источнику не-
обходимо применение более дорогих сетевых адаптеров, которые
принимают участие в определении маршрута станции назначения.
1.2.5. Коммутаторы
Коммутатор (switch [свич], коммутирующий концентратор) —
это многопортовое устройство, которое, так же как и мост, позво-
ляет объединить несколько отдельных сегментов в одну сеть. 1
1.2. Аппаратные компоненты локальных компьютерных сетей 29
Коммутаторы появились в ответ на растущие потребности
в повышении пропускной способности связей высокопроизводи-
тельных серверов с сегментами рабочих станций. В отличие от
мостов, коммутаторы позволяют осуществлять не последователь-
ную, а параллельную обработку кадров, продвигая кадры сразу
между всеми парами своих портов, что существенно увеличивает
их производительность и пропускную способность.
Работа коммутатора может быть основана на использовании:
• коммутационной матрицы;
• общей шины;
• разделяемой памяти;
Коммутационная матрица обеспечивает передачу кадров меж-
ду портами и работает по принципу коммутации каналов.
При получении кадра на какой-либо из портов несколько
первых байтов кадра, содержащих адрес назначения, помещаются
в буфер коммутатора для анализа. Получив адрес назначения,
коммутатор, не дожидаясь получения оставшихся байтов кадра,
решает, передавать ли кадр. Если в этом нет необходимости, то
запись кадра в буфер прекращается и происходит очистка буфера.
Если коммутатор решил передавать кадр, то он просматривает ад-
ресную таблицу, чтобы определить нужный порт-получатель, по-
сле этого обращается к коммутационной матрице для установки
соединения с этим портом. После установки соединения начина-
ется передача кадра.
Если нужный порт занят другим соединением, то полученный
кадр записывается в буфер, где ожидает, пока можно будет уста-
новить требуемое соединение.
В случае коммутаторов с общей шиной порты связывает вы-
сокоскоростная шина, по которой и передаются кадры.
Передача происходит небольшими порциями, чтобы не заби-
вать шину передачами только с одного порта, заставляя осталь-
ные порты находиться в очереди на передачу в течение неопреде-
ленного времени.
Использование для связи портов коммутатора разделяемой
памяти основано на особой организации памяти коммутатора, где
образовано несколько очередей данных для каждого из портов.
При этом память поочередно соединяется с буферами портов для
записи или чтения. Поступающие кадры записываются в буфер
порта, откуда попадают в разделяемую память. Когда память со-
30
Глава 1. Построение компьютерных сетей
единиться с буфером порта назначения, тот считывает данные
и пересылает их в сеть.
1.3. Стандарты построения локальных сетей
В 1980 г. Институт инженеров по электротехнике и радио-
электронике (Institute of Electrical and Electronics Engineers —
IEEE) организовал комитет 802, в состав которого вошли рабочие
и исследовательские группы, занимающиеся стандартизацией ло-
кальных сетей. Результатом их работы стал перечень стандартов,
регламентирующих проектирование локальных сетей:
• IEEE 802.1 — стандарты, относящиеся к управлению сетя-
ми;
• IEEE 802.2 — общий стандарт управления логическим со-
единением (Logical Link Control — LLC) и управления до-
ступом к среде (Media Access Control — MAC);
• IEEE 802.3, 802.4, 802.5 — стандарты, определяющие управ-
ление доступом к среде передачи данных;
• IEEE 802.6 — стандарт для городских сетей.
Позже стандарты IEEE 802.x легли в основу комплекса меж-
дународных стандартов ISO 8802-1 х.
1.3.1. Ethernet
Основой для стандарта IEEE 802.3 послужила спецификация
Ethernet, разработанная Xerox Corporation в кооперации с DEC
и Intel в 1976 г., а точнее, ее несколько видоизмененная модифи-
кация Ethernet II или Ethernet DIX. В настоящее время Ethernet —
это самый распространенный стандарт построения локальных се-
тей.
В зависимости от типа физической среды передачи данных
стандарт IEEE 802.3 имеет различные модификации — l0Base-5,
10Base-2, l0Base-T, l0Base-F (табл. LI). Но для всех модификаций
технология Ethernet обеспечивает скорость передачи данных
в 10 Мбит/с и использует один и тот же метод доступа к разделен-
ной среде передачи данных — метод множественного доступа с про-
слушиванием несущей и разрешением коллизий (CSMA/CD).
Стандарт 10Base-5 использует в качестве среды передачи дан1-
ных «толстый» коаксиальный кабель и позволяет подключать до1
1.3. Стандарты построения локальных сетей
31
Таблица 1.1. Характеристики спецификаций технологии Ethernet
Характеристики Спецификации
10Base-5 10Base-2 IOBase-T 10Base-F
Тип кабеля Толстый коаксиальный кабель RG-8/11 Тонкий коаксиальный кабель RG-58 UTP3, UTP4, UTP5 Одномодовое и многомодовое оптоволокно
Максимальное число узлов в сегменте 100 30 1024 1024
Максимальное число узлов в сети 296 86 1024 1024
Максимальная дли- на сегмента, м 500 185 100 2000
Топология Обшая шина Обшая шина Звезда Звезда
Диаметр сети, м 2500 925 500 2500
100 рабочих станций к одному непрерывному сегменту кабеля
длиной до 500 м. При этом расстояние между соседними подклю-
чениями должно быть кратно 2,5 м.
Для подключения сетевого адаптера к коаксиальному кабелю
используется специальное приемопередающее устройство —
трансивер (transceiver — от англ, transmitter и receiver), подсоеди-
ненный к адаптеру интерфейсным кабелем на основе четырех ви-
тых пар. Длина интерфейсного кабеля не должна превышать 50 м.
Использование повторителей, дублирующих и усиливающих
сигналы, полученные из одного сегмента, в другом сегменте се-
ти позволяет строить сети, состоящие из нескольких сегмен-
тов, но не более чем из пяти. При этом два промежуточных сег-
мента не должны содержать узлов. Это так называемое «правило
5—4—3»: пять сегментов, четыре повторителя, три нагруженных
сегмента (рис. 1.11).
Каждый сегмент кабеля должен иметь на концах специаль-
ные заглушки («терминаторы») с сопротивлением 50 Ом. За-
глушки предотвращают возникновение в кабеле отраженных
сигналов и тем самым препятствуют появлению искажений сиг-
налов в кабеле.
32
Глава 1. Построение компьютерных сетей
Рис. 1.11. Правило 5—4—3:
1 — рабочая станция; 2 — повторитель; 3 — нагруженный сегмент; 4 — ненагру-
женный сегмент
Таким образом, диаметр сети, построенной на стандарте
10Base-5, не может превышать 2,5 км. Кроме того, такая сеть мо-
жет содержать не более 296 рабочих станций.
Средой передачи данных для стандарта 10Base-2 является
«тонкий» коаксиал, позволяющий подключить до 30 компьюте-
ров к одному непрерывному сегменту, длина которого не должна
превышать 185 м. Расстояние между соседними узлами должно
быть кратно 0,5 м.
Подключение компьютера к кабелю происходит с помощью
специального Т-коннектора (соединителя), имеющего три отво-
да, один из которых соединяется с сетевым адаптером, а два дру-
гих подключаются к концам разреза коаксиального кабеля с по-
мощью специальных разъемов.
В сети по-прежнему не может быть более пяти сегментов,
и только три из них могут иметь узлы. Такая сеть позволяет объ-
единить 86 компьютеров и может достигать 925 м в диаметре.
Стандарт 10Base-T является дополнением к стандарту 802.3
(обозначается как 802.3i) и использует в качестве среды передачи
данных кабель на основе неэкранированных витых пар категории
3. Такой кабель применялся внутри зданий в качестве телефон-
ных линий.
Роль общей среды здесь играет концентратор, к портам кото-
рого подключаются отрезки витой пары, соединенные с компью-
1.3. Стандарты построения локальных сетей
33
терами. Концентратор выполняет функцию повторителя, дубли-
руя и усиливая сигнал, полученный с одного порта, на всех ос-
тальных.
При использовании в качестве разделяемой среды кабеля на
основе витых пар «правило 5—4—3» заменяется новым правилом
(«правило 4 хабов», хаб (hub) — синоним термина «концентра-
тор»), согласно которому между двумя любыми станциями сети
не должно быть больше четырех концентраторов.
Длина кабеля на основе витых пар, соединяющего два узла,
например, компьютер и концентратор или концентратор и кон-
центратор, не должна превышать 100 м. В сети не должно быть
более пяти сегментов, т. е. число концентраторов не может пре-
вышать четырех, следовательно, максимальный диаметр такой се-
ти составит 500 м.
При передаче данных по стандарту 10Base-T используется две
витые пары. По одной из них данные поступают с компьютера на
концентратор, по другой — с концентратора на компьютер. Вход-
ное подключение к устройству обозначается Rx, выходное — Тх.
При подключении кабеля на основе витых пар используются
разъемы RJ-45. Присоединение разъемов к кабелю называется
обжимом кабеля. Обжатый кабель с разъемом вставляется в соот-
ветствующее гнездо на рабочей станции или концентраторе.
Стандарт 10Base-F представляет собой реализацию Ethernet
на оптоволоконном кабеле. При этом длина сегмента составляет
2000 м. И хотя количество сегментов в сети может доходить до пя-
ти, максимальная длина сети не может превышать 2500 м.
1.3.2. Token Ring
Стандарт IEEE 803.5 был принят на основе технологии Token
Ring, разработанной компанией IBM в 1984 г. Сети Token Ring
строятся по топологии «кольцо» и используют маркерный метод
доступа к среде передачи данных.
Передача данных в сетях Token Ring может осуществляться на
скоростях в 4 и 16 Мбит/с. В сети Token Ring 16 Мбит/с использу-
ются некоторые усовершенствования маркерного метода доступа
к разделяемой среде. Например, алгоритм раннего освобождения
маркера, при котором станция не дожидается возвращения по
кольцу переданных ею кадров с подтверждением приема, пере-
34
Глава 1. Построение компьютерных сетей
Рис. 1.12. Сеть на основе технологии Token Ring:
логическая топология — «кольцо»; физическая — «звезда»
дает маркер следующей станции сразу по окончании своей пере-
сылки кадров.
Технология Token Ring изначально ориентировалась на ис-
пользование концентраторов, одной из задач которых является
сохранение целостности кольца при выключении одного или не-
скольких компьютеров. Концентраторы могут быть пассивными
и выполнять функцию простого соединителя для портов, так,
чтобы подключаемые станции образовывали кольцо, либо актив-
ными, при этом концентратор выполняет еще и функцию повто-
рителя сигналов. При этом сеть (рис. 1.12) имеет логическую то-
пологию «кольцо», хотя физическое соединение компьютеров
имеет структуру типа «звезда».
Для соединения узлов сети в качестве физической среды пе-
редачи данных могут использоваться кабели на основе экраниро-
ванной витой пары категории 1, неэкранированной витой пары
категории 3 или 6, а также оптоволокно.
В случае использования пассивных концентраторов для экра-
нированной витой пары допускается подключение до 260 рабочих
станций, при этом расстояния между узлами сети не должны пре-
вышать 100 м. При объединении станций посредством неэкрани-
рованной витой пары их максимально допустимое число сокра-
щается до 72, а длина между узлами — до 45 м.
1.3. Стандарты построения локальных сетей
35
Если установленные концентраторы являются активными, то
максимальная длина соединяющего их кабеля не должна превы-
шать 730 м в случае использования экранированной витой пары,
и 365 м — для неэкранированной. Максимальная длина кольца
Token Ring не должна превышать 4000 м.
Соединение компьютеров в кольцо делает сеть более отказо-
устойчивой по сравнению с сетями Ethernet. Например, ошибки
и сбои в работе сети, вызванные потерей маркера, устраняются
автоматически активным монитором. Даже в случае выхода из
строя активного монитора сеть продолжит свое нормальное
функционирование, передав задачи мониторинга сети другой ра-
бочей станции.
1.3.3. FDD!
Еще одна технология, использующая маркерный метод досту-
па к среде передачи данных, описывается в стандарте FDDI, раз-
работанном американским институтом по стандартизации ANSI.
FDDI был разработан в 1988 г. В качестве физической среды
передачи данных здесь используется оптоволоконный кабель.
Спустя некоторое время эта технология была реализована с под-
держкой кабеля на основе неэкранированной витой пары пятой
категории.
Сеть FDDI строится на основе двух оптоволоконных колец:
первичного и вторичного. При нормальной работе сети данные
передаются по первичному кольцу, вторичное кольцо при этом не
используется.
Наличие двух колец (рис. 1.13) существенно повышает отка-
зоустойчивость сети. В случае обрыва сети кольца «сворачивают-
ся», и пересылка информации происходит по вторичному кольцу.
Если образовалось несколько точек разрыва кабеля, то сеть рас-
падается на несколько несвязанных сетей.
Маркерный метод доступа к разделяемой среде FDDI имеет
ряд отличий от метода, аналогичного методу Token Ring.
Деление кадров по восьми уровням приоритета здесь не ис-
пользуется. Вместо этого все данные делятся на синхронные
и асинхронные. Для пересылки синхронных данных время удер-
жания маркера так же, как и в сетях Token Ring, остается строго
фиксированным, но при передаче асинхронных данных, менее
36
Глава 1. Построение компьютерных сетей
Рис. 1.13. Механизм обеспечения высокой отказоустойчивости работы сети:
а — нормальное функционирование сети; б — разрыв кабеля, сворачивание сети
в одно кольцо; в — множественные повреждения кабеля, сеть распадается на не-
сколько независимых колец; / — первичное кольцо; 2— вторичное кольцо; 3—
разрыв кабеля
чувствительных к задержкам, время удержания маркера меняется
в зависимости от степени загруженности кольца. При уменьше-
нии загруженности сети время удержания маркера увеличивается,
при увеличении — может уменьшаться практически до нуля. Кро-
ме того, здесь применяется алгоритм раннего освобождения мар-
кера, характерный для сетей Token Ring, поддерживающих ско-
рость в 16 Мбит/с.
Скорость передачи данных для сетей FDDI составляет
100 Мбит/с. Максимальное количество узлов составляет 500. При
использовании в качестве физической среды передачи данных
многомодового оптоволоконного кабеля расстояние между узлами
сети может составлять до 2 км, при использовании одномодового
кабеля — до 40 км. В случае кабеля на основе витых пар пятой ка-
тегории указанное расстояние может составлять до 100 м. Макси-
мальный диаметр двойного кольца не должен превышать 100 км.
1.3.4. Token Bus
Стандарт IEEE 802.4 описывает свойства сетей, известных под
названием маркерная шина (Token Bus). Такие сети также ис-
пользуют маркерный метод доступа к разделяемой среде. Вместо
передачи маркера от станции к станции по кругу, как это проис-
ходит в сетях Token Ring, что обусловлено топологией построения
сети, в сетях Token Bus маркер передается от «старшей» станции
1.3. Стандарты построения локальных сетей
37
Направление передачи маркера
Рис. 1.14. Передача маркера в сетях Token Bus
к «младшей». Старшинство подключенных к сети станций обыч-
но определяется на основе их адреса. Маркер движется в направ-
лении убывания адресов. Передача маркера происходит до тех
пор, пока он не достигнет младшей станции, после этого он воз-
вращается обратно первой станции (рис. 1.14).
Сеть Token Bus способна обеспечить пропускную способ-
ность до 10 Мбит/с (табл. 1.2).
Таблица 1.2. Характеристики спецификаций, использующих маркерный метод до-
ступа к среде передачи данных
Характеристики Спецификации
Token Ring FDD1 Token Bus
Скорость передачи дан- ных, Мбит/с 4 или 16 100 10
Тип кабеля STP 1, UTP3, UTP6, оптоволокно Оптоволокно, UTP5 Коаксиал
Максимальное число узлов в сети 260 для STP, 72 для UTP 500 255
Максимальная длина сегмента, м 100 2000 для много- мод. оптоволокна, 40 000 для одно- мод. оптоволокна, 100 для UTP 5 610
Топология Звезда/кольцо Двойное кольцо Общая шина, звезда, дерево
Диаметр сети, км 4 100 6
38 Глава 1. Построение компьютерных сетей
С точки зрения структуры сети Token Bus имеют физическую
топологию «общая шина», а логическую — «кольцо».
1.3.5. Fast Ethernet
По мере развития компьютерных технологий и появления но-
вых более мощных машин, скорость 10—14 Мбит/с перестала
быть достаточной для нормальной работы сетей, которые просто
не справлялись с возросшими нагрузками на каналы связи. По-
этому в 1995 г. были утверждены новые стандарты — IEEE 802.Зп
и 802.12, которые позволяли реализовывать взаимодействие ком-
пьютеров через сеть на скорости 100 Мбит/с.
IEEE 802.3u основан на технологии Fast Ethernet, которую раз-
работала группа производителей сетевого оборудования, в ее со-
став входили такие компании, как ЗСот и SynOptics. Этот стандарт
стал дополнением к уже существовавшему стандарту IEEE 802.3.
Разработчики отказались от использования в качестве физи-
ческой среды передачи данных коаксиального кабеля, полностью
перейдя на витую пару и оптоволокно, которые позволяют под-
держивать требуемые скорости соединений, и при этом являются
более удобным и экономичным решением (табл. 1.3).
Как и стандарт IEEE 802.3, описывающий технологию Ин-
тернет, новый стандарт установил спецификации для различных
сред передачи данных.
100Base-TX использует для передачи данных кабель на основе
неэкранированной витой пары пятой категории или экраниро-
ванной витой пары первой категории. Максимальная длина сег-
мента при этом составляет 100 м.
Стандарт 100Base-T4, как и в технологии Ethernet, предпола-
гает использование кабеля на основе неэкранированных витых
пар третьей категории. Но для возможности увеличить скорость
до 100 Мбит/с здесь используются все четыре пары, вместо двух,
как это было раньше. При этом одна витая пара используется для
прослушивания несущей частоты и обнаружения коллизий, а ос-
тавшиеся три пары — для передачи данных. Скорость передачи
данных каждой из пар составляет 33 Мбит/с, что суммарно и дает
скорость в 100 Мбит/с.
Так же как и в технологии 100Base-TX, длина сегмента не
должна превышать 100 м.
1.3. Стандарты построения локальных сетей
39
Таблица 1.3. Характеристики спецификаций технологии Ethernet и lOOVG-AnyLAN
Характеристики Спецификации
I00Base-TX l00Base-T4 lOOBase-FX lOOVG-AnyLAN
Тип кабеля UTP5, STP I UTP3 Многомодовое оптоволокно UTP3, UTP4, UTP5, STP I, оптоволокно
Метод доступа CSMA/CD CSMA/CD CSMA/CD Demand Priority
Максимальное число узлов в сети 1024 I024 1024 1024
Максимальная длина сегмента, м ЮО ЮО 2000 при полнодуплекс- ной передаче, 412 при полудуплексной передаче 225
Топология Звезда Звезда Звезда Звезда
Диаметр сети, м 205 205 — ПОО
100Base-FX имеет много общего со спецификацией 100Base-TX,
по сути, это его реализация для многомодового оптоволоконного
кабеля, который и используется в качестве физической среды пере-
дачи данных. Максимальная длина сегмента для Fast Ethernet, по-
строенного на этой технологии, зависит от режима передачи.
Одновременная передача данных в обоих направлениях назы-
вается полнодуплексной передачей, а соответственный режим
передачи — полнодуплексным. В этом случае длина сегмента не
должна превышать 2 км.
Режим, при котором обмен данными осуществляется путем
чередования приема и передачи, называется полудуплексным.
Длина отрезка кабеля, соединяющего узлы сети, при этом не
должна быть больше 412 м.
1.3.6. 100VG-AnyLAN
Технология lOOVG-AnyLAN использует в качестве метода
доступа к среде передачи данных приоритетный доступ по требо-
ванию.
40
Глава 1. Построение компьютерных сетей
В качестве физической среды передачи данных IEEE 802.12
можно использовать четыре неэкранированные витые пары кате-
горий 3, 4 и 5, две экранированные витые пары категории 1 или
неэкранированные категории 5, два многомодовых оптоволокна.
Максимальное количество подключаемых узлов не должно пре-
вышать 1024. Длина сегмента не должна превышать 225 м при
диаметре сети в 1100 м.
1.3. 7. Gigabit Ethernet
После разработки стандартов, позволяющих передавать дан-
ные на скорости 100 Мбит/с, достаточно скоро снова назрела
необходимость в переходе на новый уровень скоростей. Слож-
ность возникла при строительстве крупных корпоративных се-
тей, где серверы, работающие при 100 Мбит/с, перегружали ма-
гистральные каналы связи. Технология lOOVG-AnyLAN не полу-
чила столь широкого распространения как Fast Ethernet из-за
своей высокой сложности. Поэтому следующим шагом в разви-
тии высокоскоростных сетей стала технология Gigabit Ethernet,
обеспечивающая возможность передачи данных на скорости
1000 Мбит/с (табл. 1.4).
Технологии Gigabit Ethernet соответствует стандарт 802.3z, ко-
торый определяет для нее в качестве физической среды передачи
данных одномодовый и многомодовый оптоволоконный кабель,
Таблица 1.4. Характеристики спецификаций технологии Gigabit Ethernet
Характе- ристики Спецификации
1000Base-LX 1000Base-SX 1000Base-T l000Base-CX
Тип кабеля UTP 5, STP 1 Оптоволокно UTP 5 STP Twinax
Максималь- ная длина сегмента, м 316 — при полудуп- лексной передаче. 550 — при полно- дуплексной передаче по многомодовому волокну. 5000 — при полно- дуплексной передаче по одномодовому волокну 316 — при полуду- плексной передаче по волокну 50/125. 550 — при полно- дуплексной пере- даче по волокну 50/125. 275 — при передаче по волокну 62,5/125 100 25
1.3. Стандарты построения локальных сетей.
41
а также экранированная витая пара с волновым сопротивлением
75 Ом. Чуть позже была разработана реализация Gigabit Ethernet
для кабеля на основе витой пары категории 5 (стандарт IEEE
802.ЗаЬ). Также определены и соответствующие физическим сре-
дам спецификации.
1000Base-LX (L — от long wavelength — длинная волна) преду-
сматривает использование как многомодового, так и одномодово-
го оптоволокна и излучения с длиной волны в диапазоне
1270—1355 нм. Длинноволновой лазер дороже, чем коротковол-
новой, но допускает передачу на более длинные дистанции. Для
полудуплексного режима передачи длина сегмента составляет
316 м, тогда как для полнодуплексного — 550 м для многомодово-
го оптоволокна и 5 км для одномодового.
1000Base-SX (S — от short wavelength — короткая волна) пред-
полагает передачу только по многомодовому оптоволокну и дли-
ну волны в диапазоне 770—860 нм. Длина сегмента в полудуп-
лексном режиме передачи составляет 275 м для волокна диамет-
ром 62,5 нм и 316 м для волокна 50 нм. В дуплексном режиме
соответственно 275 и 550 м.
1000Base-T использует для передачи все четыре витые пары
кабеля категории 5. Так же, как и в технологии 100VG-AnyLAN,
передача происходит параллельно по каждой паре со скоростью
250 Мбит/с. Показатели максимального числа подключаемых уз-
лов, длины сегмента, диаметра сети остаются стандартными для
кабеля на основе витой пары пятой категории.
1000Base-CX в качестве физической среды использует специ-
альную экранированную витую пару с волновым сопротивлением
75 Ом для каждого проводника (Twinax). Передача осуществляет-
ся в полудуплексном режиме, причем данные посылаются по
двум проводникам одновременно. Максимальная длина сегмента
при этом может составлять всего 25 м.
1.3.8. 10 Gigabit Ethernet
Новым скачком в развитии технологий высокоскоростной пе-
редачи данных стал стандарт IEEE 802.3ае — Ю Gigabit Ethernet
(10 GbE), одобренный в июне 2002 г. С его появлением область
использования Ethernet расширилась до масштабов городских
(MAN) и глобальных (WAN) сетей.
42
Глава 1. Построение компьютерных сетей
В стандарте описано несколько спецификаций, определяю-
щих использование в качестве среды передачи данных одно-
и многомодовые оптоволокна, методы кодирования, применяе-
мые длины волн и т. д.
1.3.9. Wireless Ethernet
Часто возникают ситуации, когда прокладка кабельной систе-
мы затруднена или экономически нецелесообразна. Причиной
тому, например, могут быть естественные преграды, образован-
ные особенностями рельефа местности: реки, озера, горы или не-
обходимость создания временной локальной сети, которую при-
дется демонтировать. В таких случаях для организации сети без
прокладки дополнительных линий связи используют беспровод-
ные локальные сети (Wireless LAN — WLAN), позволяющие объ-
единить в единую информационную систему разрозненные ло-
кальные сети и компьютеры для обеспечения доступа всех поль-
зователей этих сетей к единым информационным ресурсам.
Кроме того, необходимость построения беспроводных сетей
диктуется удешевлением, а значит, и ростом популярности мо-
бильных устройств, таких, как портативные ноутбуки, карманные
компьютеры и т. д. С увеличением числа мобильных пользовате-
лей возникает острая необходимость в оперативном осуществле-
нии коммуникаций между ними, в обмене данными, в быстром
получении информации.
В основе технологий беспроводных сетей лежит принцип ра-
диосвязи между узлами сети. В качестве узла сети может выступать
как отдельный компьютер или ноутбук, так и специальное устрой-
ство «точка доступа» (Access Point), обеспечивающее доступ к ка-
бельному сегменту какой-либо сети или другому компьютеру.
В 1990 г. комитет по стандартам IEEE 802 сформировал рабо-
чую группу по стандартам для беспроводных локальных сетей
802.11. В 1997 г. была утверждена первая спецификация для ра-
диооборудования и сетей, работающих на частоте 2,4 ГГц, со ско-
ростями доступа 1 и 2 Мбит/с. Новая технология передачи дан-
ных, многое перенявшая из технологии Ethernet, получила соот-
ветствующее название Radio Ethernet.
Однако к тому времени скорость передачи данных 1—2 Мбит/с
в беспроводной сети уже не удовлетворяла потребности пользова-
1.3. Стандарты построения локальных сетей
43
телей. Чтобы сделать технологию беспроводных сетей популярной,
дешевой и удовлетворяющей современным требованиям, разра-
ботчики были вынуждены создать новый стандарт.
В сентябре 1999 г. утверждается новый стандарт IEEE 802.11b
(или 802.11 High rate), который позволяет обеспечивать скорость
передачи данных в 11 Мбит/с. В стандарте для модуляции сигнала
применяется метод широкополосной модуляции с прямым рас-
ширением спектра (Direct Sequence Spread Spectrum — DSSS).
При этом весь рабочий диапазон делится на 14 каналов, частоты
которых разнесены на 25 МГц для исключения взаимных помех.
Данные передаются по одному из этих каналов без переключения
на другие. Возможно одновременное использование всего трех
каналов. Скорость передачи данных может автоматически ме-
няться в зависимости от уровня помех и расстояния между пере-
датчиком и приемником.
Очень часто беспроводные сети называют сетями Wi-Fi или
просто Wi-Fi. Этот термин происходит от названия независи-
мой международной организации Wireless Fidelity Alliance (Wi-Fi
Alliance). Эта организация была создана в 1999 г. лидерами инду-
стрии беспроводной связи и изначально называлась Wireless
Ethernet Compatibility Alliance (WECA). Задачей организации
является сертификация совместимости с технологией WLAN
продуктов различных производителей. Эта организация объеди-
няет практически всех ведущих производителей — Cisco, Lu-
cent, ЗСот, IBM, Intel, Apple, Compaq, Dell, Fujitsu, Siemens, Sony,
AMD и др.
Еще одной спецификацией WLAN является стандарт IEEE
802.1 1а, основной особенностью которого является метод моду-
ляции сигнала, называемый мультиплексированием с разделени-
ем по ортогональным частотам (Orthogonal Frequency Division
Multiplexing — OFDM). Метод предполагает параллельную пере-
дачу полезного сигнала одновременно по нескольким частотам
диапазона. В результате повышается пропускная способность ка-
нала и качество сигнала.
В отличие от стандарта 802.11, ориентированного на область
частот 2,4 ГГц, спецификациями 802.11а предусмотрена работа
в диапазоне 5 ГГц. В стандарте определены три обязательные ско-
рости передачи данных (6, 12 и 24 Мбит/с) и пять дополнитель-
ных (9, 18, 24, 48 и 54 Мбит/с). Сети, построенные на основе это-
го стандарта, имеют 12 неперекрывающихся каналов.
44
Глава 1. Построение компьютерных сетей
Таблица 1.5. Характеристики спецификаций Radio Ethernet
Характеристики Спецификации
IEEE 802.11b IEEE 802.11g IEEE 802.1 la
Скорость передачи данных, Мбит/с II До 54 До 54
Число каналов 3 3 12
Расстояние передачи дан- ных, м: в закрытых помещениях в открытых помещениях в пределах прямой видимости 30(11 Мбит/с), 91 (1 Мбит/с) 120(11 Мбит/с), 460(1 Мбит/с) 30 (54 Мбит/с), 91 (1 Мбит/с) 120 (54 Мбит/с), 460(1 Мбит/с) 12 (54 Мбит/с), 91 (6 Мбит/с) 30 (54 Мбит/с), 305 (6 Мбит/с)
Схема модуляции DSSS OFDM OFDM
Рабочая частота, ГГц 2,4 (2,4-2,4835) 2,4 (2,4-2,4835) 5(5,15—5,350 и 5,725—5,825)
В 2003 г. был утвержден стандарт IEEE 802.11g, являющийся
развитием спецификации IEEE 802.11b. Стандарт предусматрива-
ет использование диапазона 2,4 ГГц и OFDM-метод модуляции
сигнала. При этом скорость передачи данных увеличена до
54 Мбит/с (табл. 1.5).
При использовании для передачи данных излучения в инфра-
красном диапазоне передаваемый сигнал излучается в потолок,
отразившись от которого может быть получен приемниками. Ра-
диус, на котором работает такая сеть, не превышает 10 м при ско-
рости передачи данных в 1—2 Мбит/с.
Контрольные вопросы
1. Что представляет собой вычислительная сеть?
2. Назовите основные различия клиент-серверной и файл-серверной
архитектур.
3. Какое количество соединений (ребер) необходимо для реализации
полносвязной топологии в сети из семи узлов?
4. Какие основные типы кабелей используются для построения компь-
ютерных сетей?
5. Приведите основные типы оптоволоконных кабелей.
1.3. Стандарты построения локальных сетей
45
6. В чем заключается CSMA/CD-метод доступа к среде передачи?
7. Является ли концентратор элементом структурированной кабель-
ной системы?
8. Назовите основные функции сетевых адаптеров.
9. Какую функцию выполняет порт расширения в стековых концентра-
торах?
10. Должен ли мост иметь адресную таблицу? Почему?
11. Назовите архитектуры, лежащие в основе работы коммутаторов.
12. Какие ограничения устанавливает «правило 5—4—3»?
13. Для чего используются «терминаторы» в сетях на основе коакси-
ального кабеля?
14. Поясните принцип работы концентраторов в технологии Token Ring.
15. Как обеспечивается высокая отказоустойчивость в сетях FDDI?
16. Можно ли использовать UTP кабель 5 категории для реализации
Gigabit Ethernet?
17. Какую роль играет «точка доступа» в сетях WLAN?
18. Поясните метод модуляции OFDM для стандарта IEEE 802.11.
Г лава 2
ОРГАНИЗАЦИЯ СЕТЕВОГО
ВЗАИМОДЕЙСТВИЯ
2.1. Физическая передача данных
2.1.1. Физическое кодирование данных
Обмен информацией по физическим каналам передачи дан-
ных осуществляется с помощью соответствующих среде передачи
сигналов. Например, передача по коаксиальному кабелю или ви-
той паре осуществляется с помощью электрических сигналов,
а передача по оптоволоконному кабелю — с помощью световых.
Однако для того чтобы передать таким образом информацию,
ее предварительно необходимо преобразовать в тот или иной вид
сигналов.
Представление данных одного типа в виде данных другого ти-
па (в данном случае в виде сигналов) называется кодированием
данных.
Существует множество систем кодирования данных для обес-
печения возможности их передачи по сети, однако выбор той или
иной системы кодирования обусловливается рядом факторов, та-
ких, как характеристика физической среды передачи или стои-
мость оборудования, осуществляющего кодирование и декодиро-
вание данных.
Использование различных кодов может существенно сказать-
ся на достоверности и скорости передачи информации. Так, при
использовании различных систем кодирования скорость переда-
чи по одной и той же физической среде передачи может разитель-
но различаться.
Кроме всего, чтобы снизить стоимость сетевого оборудования,
необходимо выбирать такую систему кодирования, которая спо-
собна максимально обеспечить синхронизацию приема данных
(приемнику данных необходимо знать, когда именно необходимо
2.1. Физическая передача данных
47
произвести считывание данных, пришедших по линии связи),
а также снизить частоту возникновения ошибок при передаче.
В беспроводных сетях, на каналах с узкой полосой пропуска-
ния обычно применяется метод кодирования, основанный на мо-
дуляции несущего высокочастотного аналогового сигнала. В за-
висимости от модулируемых характеристик сигнала различаются
следующие основные виды модуляции (рис. 2.1):
• амплитудная;
• фазовая;
• частотная.
При амплитудной модуляции единицы и нули данных коди-
руются за счет разницы уровня амплитуды несущей частоты, т. е.
единицы исходных данных представляются сигналом с одним
уровнем амплитуды, а нули — либо сигналом с меньшим уровнем
амплитуды, либо отсутствием сигнала.
При фазовой модуляции данные кодируются посредством
сигналов, имеющих различную фазу.
Частотная модуляция представляет исходные единицы и нули
в виде синусоид, различающихся по частоте.
На практике очень часто для повышения качества и скорости
передачи применяются смешанные методы модуляции, например
амплитудная модуляция в комбинации с фазовой.
| 0 1 0 1:0
Рис. 2.1. Основные виды модуляции сигнала:
а — амплитудная; б — фазовая; в — частотная
48
Глава 2. Организация сетевого взаимодействия
Рис. 2.2. Цифровое кодирование NRZ
Другим видом кодирования дискретных данных, т. е. данных,
представляющих собой последовательности нулей и единиц, яв-
ляется цифровое кодирование.
Существует весьма большое разнообразие систем цифрового
кодирования, основанных на использовании различных прин-
ципов.
Примером цифрового кодирования может быть код NRZ (Non
Return to Zero — без возврата к нулю) — один из самых простей-
ших кодов, использующий для представления нулей и единиц зна-
чение потенциала сигнала (рис. 2.2). При этом нулю исходных
данных может соответствовать высокий уровень напряжения в ка-
беле, а единице — низкий уровень напряжения (или наоборот).
В течение времени передачи одного бита, называемого бито-
вым интервалом, уровень сигнала в кабеле не изменяется.
К преимуществам кода NRZ относятся:
• простота его реализации;
• минимальная по сравнению с другими кодами пропускная
способность линии.
К недостаткам кода NRZ можно отнести:
плохую самосинхронизацию: в случае если внутренние часы
приемника и передатчика несколько расходятся, то приемник не
может точно определить границы битовых интервалов, особенно
при передаче длинных последовательностей нулей или единиц,
когда потенциал не изменяется в течение довольно длительного
времени;
фиксированную длину сообщений: начало приема происходит
с получением специального стартового бита, а конец передачи —
после принятия заданного числа бит (приемник ведет подсчет).
Другим видом цифрового кода является код RZ (Return to
Zero — с возвратом к нулю). Здесь при кодировании используется
три уровня потенциала в кабеле. Так же, как и в коде NRZ, нулю
кодируемых данных соответствует положительный импульс,
единице — отрицательный (или наоборот). Третий уровень по-
2.1. Физическая передача данных
49
Рис. 2.3. Цифровое кодирование RZ
тенциала (например, нулевой) используется для самосинхрониза-
ции кода.
В середине каждого битового интервала всегда осуществляется
переход сигнала с положительного или отрицательного уровня на
этот «нулевой» уровень (рис. 2.3). Поэтому приемник всегда может
выделить каждый отдельный бит кода, следовательно, синхрониза-
ция не нарушится при любой длине пакета. Соответственно, также
легко осуществляется и определение начала и окончания передачи
пакета — первый битовый интервал без изменения уровня сигнала
означает конец передаваемой последовательности битов пакета.
К недостаткам кода RZ относятся:
• большая (по сравнению с NRZ) полоса пропускания;
• необходимость в усложнении передающей и принимаю-
щей аппаратуры из-за использования трехуровневого ко-
дирования.
Применение кода RZ возможно также в сетях, использующих
в качестве среды передачи данных не только электрические кабе-
ли, но и оптоволоконные. При этом уровням электрического по-
тенциала в передаче данных по оптоволокну соответствует яр-
кость света.
Альтернативой потенциальных кодов являются импульсные
коды, которые для представления данных используют перепады
потенциала различных направлений.
Примером потенциального кода является Манчестерский код,
получивший очень большое распространение в локальных сетях.
Кодирование с использованием Манчестерского кода осуще-
ствляется за счет положительных и отрицательных переходов
уровня потенциала, осуществляемых посередине битового интер-
вала (рис. 2.4). Нулю исходных данных соответствует положи-
тельный переход, а единице — отрицательный.
За счет наличия переходов потенциала Манчестерский код
тоже обладает самосинхронизацией, и хотя он использует всего
два уровня потенциала, для его применения необходима полоса
50
Глава 2. Организация сетевого взаимодействия
Рис. 2.4. Манчестерский код
О
Рис. 2.5. Бифазный код
пропускания, в 2 раза превышающая полосу пропускания для ко-
да NRZ.
Манчестерский код используется как в электрических, так
и в оптоволоконных кабелях, где двум уровням потенциала соот-
ветствует отсутствие или наличие света.
Еще одним примером потенциальных кодов является бифаз-
ный код, имеющий большое сходство с Манчестерским. Бифаз-
ный код предполагает наличие переходов уровней в каждом бито-
вом интервале (рис. 2.5). Кроме того, при передаче единицы фор-
мируется дополнительный переход уровней в середине битового
интервала. Наличие частых переходов делает этот код самосин-
хронизирующимся. При этом он нечувствителен к смене поляр-
ности.
2.1.2. Способы проверки правильности передачи данных
Чтобы обеспечить надежность передачи данных, используется
два основных метода:
• коды с обнаружением ошибок — позволяют выявить нали-
чие ошибки;
• коды с обнаружением и исправлением ошибок — позволяют
выявить место возникновения ошибки.
Оба этих метода основаны на внесении избыточного кода
в передаваемый блок данных таким образом, чтобы при анализе
полученного блока можно было бы получить информацию о воз-
никших ошибках.
2.1. Физическая передача данных
51
Существует множество разнообразных систем кодирования,
позволяющих внести избыточный код в исходную последователь-
ность.
Общим для всех видов кодирования является разбиение исход-
ной последовательности битов на отдельные части, обычно назы-
ваемые символами. После этого происходит замена исходных сим-
волов новыми, имеющими большее число бит, чем в исходных.
Примером избыточного кодирования является код, исполь-
зуемый в технологиях Fast Ethernet и FDDI, который заменяет
символы длиной четыре бита исходной последовательности на
символы, имеющие длину пять бит. Таким образом, в коде 4В/5В
(4 бита / 5 бит) символы, полученные после кодирования, могут
содержать 32 (23) битовые комбинации. Это является избыточным
для кодирования символа длиной в четыре бита, поскольку для
него достаточно, соответственно, 16 (24) битовых комбинаций.
Метод проверки правильности передачи данных, использую-
щий код с обнаружением ошибок, подразумевает проверку с по-
мощью контрольной суммы.
Контрольная сумма — это некоторое значение, рассчитанное
по определенным алгоритмам для входной последовательности
данных.
Суть этого метода заключается в расчете с помощью специ-
ального алгоритма контрольной суммы пакета данных, которая
передается вместе с пакетом, для которого она была рассчитана.
Рабочая станция, получившая пакет, производит повторный рас-
чет контрольной суммы. Если значения полученной вместе с па-
кетом и рассчитанной контрольных сумм не совпадают, то пакет
передан с ошибкой и требуется его повторная пересылка.
Алгоритм расчета контрольной суммы определяется техноло-
гией, используемой для передачи данных.
Одной из простых разновидностей такого алгоритма является
контроль по четности. Суть его работы заключается в следующем:
для обнаружения ошибок, которые могут появляться в группе
символов, образующих слово, фразу, предложение, подсчитыва-
ется число единиц или нулей, содержащихся в рассматриваемой
группе. Полученное число может быть либо четным, либо нечет-
ным, что отражается в специальном бите, так называемом бите
четности, соответствующем данной группе символов. После пе-
редачи данных адресату снова подсчитывается число единиц или
нулей для каждой группы и определяется их четность или нечет-
52
Глава 2. Организация сетевого взаимодействия
ность. Сравнив полученное значение со значением бита четности,
можно с некоторой достоверностью определить, появилась ли
в группе символов ошибка.
Этот метод позволяет выявлять одиночные ошибки, однако
двойную ошибку данный алгоритм не обнаружит.
Существуют модификации алгоритма контроля по четности,
решающие эту проблему, где исходные данные представляются
в виде матрицы, элементы которой являются битами данных. Ко-
эффициент четности рассчитывается для каждой строки и каждо-
го столбца матрицы. При проверке по такому методу большая
часть двойных ошибок будет обнаружена, однако реализация это-
го метода вынуждает пересылать по сети дополнительный код,
содержащий контрольную сумму и имеющий весьма большую
длину. При этом он не несет в себе полезной исходной информа-
ции. То есть код кадра, содержащего контрольную сумму, являет-
ся избыточным по отношению к коду кадра, для которого эта
сумма была рассчитана.
Самым распространенным алгоритмом проверки правильно-
сти передачи данных по сети является проверка с помощью цик-
лического избыточного кода (Cyclical Reduancy Check — CRC).
Основная идея алгоритма CRC состоит в представлении всего
сообщения в виде огромного двоичного числа, делении его на
другое фиксированное двоичное число. При этом в качестве кон-
трольной суммы используется остаток от этого деления. Обычно
делитель выбирается таким образом, чтобы остаток имел длины
в 16 разрядов (CRC-16) или 32 разряда (CRC-32).
Алгоритм CRC обладает очень неплохими показателями: он
обнаруживает практически все ошибки и обладает невысокой
степенью избыточности кода.
2.1.3. Способы обнаружения и устранения ошибок
при передаче данных
Процесс устранения ошибок предполагает решение двух
смежных задач: обнаружение ошибки и определение места ее
возникновения. После решения этих двух задач для исправления
ошибки достаточно инвертировать значение ошибочного бита.
В зависимости от каналов связи и их характеристик проблеме
устранения ошибок придают различное значение. Например, при
2.1. Физическая передача данных
53
использовании спутниковых каналов, для которых типичны
большие задержки, методики коррекции ошибок становятся до-
вольно острой необходимостью.
К таким методикам относится использование избыточных
«кодов обнаружения и исправления ошибок» (Error Detection and
Correction Code — EDCC). Примерами таких кодов может быть
код Хемминга или код Рида-Соломона.
Код Хемминга основан на использовании контрольных би-
тов, которые добавляются для каждого заданного набора бит ис-
ходной последовательности.
Предположим, что исходная последовательность данных име-
ет длину в т бит. Добавление контрольных к бит позволяет полу-
чить битовое слово длиною п = т + к, которое и будет передавать-
ся по сети.
Контрольными битами являются биты, номера которых явля-
ются степенями 2, т. е. это биты с номерами 1,2, 4, 8, 16 и т. д. Все
остальные биты последовательности являются битами исходного
сообщения, которое необходимо передать.
Каждый контрольный бит хранит значения четности группы
битов, включающей и его. При этом один бит может относиться
к разным группам. Таким образом, если представить номер бита
данных, например s, по степеням 2, можно определить номера
контрольных битов, которые отвечают за достоверность значения
этого бита s.
Например, бит под номером 13 будет контролироваться бита-
ми 1, 4 и 8 (13 = 1 + 4 + 8), а бит под номером 21 — битами 1, 4
и 16 (21 = I + 4 + 16).
При получении сообщения производится проверка четности
для контрольных битов. При этом порядковые номера битов с на-
рушением четности суммируются, в результате получается поряд-
ковый номер бита данных, содержащего ошибку.
Таким образом, код Хемминга позволяет обнаруживать и ис-
правлять лишь единичные ошибки, однако существуют модифи-
кации данного кода, способные справиться с ошибками, повре-
дившими более одного разряда исходной последовательности
данных подряд.
В наземных каналах связи, где вероятность возникновения
ошибки невелика, а передача данных происходит достаточно бы-
стро, при обнаружении ошибки обычно производится повторная
пересылка пакета, содержащего дефект.
54
Глава 2. Организация сетевого взаимодействия
2.2. Принципы пакетной передачи данных
При использовании разделяемой среды передачи данных
очень важную для пользователей роль начинает играть время до-
ступа к среде.
В сетях, построенных на основе большей части известных тех-
нологий, в один конкретный момент времени не может происхо-
дить несколько передач одновременно. Передача узлами инфор-
мации в таких сетях происходит поочередно. Очередность обес-
печивается, в зависимости от метода доступа к среде передачи
данных, получением узлом сети права на передачу.
Поэтому, когда рабочей станции необходимо переслать дан-
ные по сети, она пытается получить доступ к разделяемой среде
передачи данных. Время ожидания с момента, когда рабочая
станция готова начать пересылку, и до момента, когда рабочая
станция, наконец, получает доступ к среде передачи и начинает
пересылку данных, называется временем доступа к среде.
Очевидно, что для лучшей и более быстрой работы сети время
доступа должно быть как можно меньше. Однако в случае, напри-
мер, пересылки по сети файла или крупного блока данных время
доступа к среде будет довольно большим, и узлы, не участвующие
в обмене данными, вынуждены будут ждать до завершения пере-
дачи. При этом вероятность возникновения ошибки при передаче
большого блока информации весьма высока. Возникновение та-
кой ошибки приведет к необходимости в повторной передаче все-
го блока информации, что опять же не сокращает время ожида-
ния других узлов сети.
Поэтому для того чтобы иметь возможность уменьшить время
доступа к разделяемой среде передачи данных для любого узла,
вся передаваемая информация разбивается на небольшие блоки,
называемые пакетами или кадрами.
Максимальная длина каждого пакета строго ограничена.
Таким образом, в процессе пакетной передачи данных осуще-
ствляется одновременное взаимодействие сразу между несколь-
кими узлами сети — информация, передаваемая по сети, пред-
ставляет собой очереди пакетов, отправленных разными узлами.
Сети, информационный обмен которых основан на передаче
по линиям связи последовательностей пакетов, называются сетя-
ми с коммутацией пакетов.
2.2. Принципы пакетной передачи данных
55
Разбиение данных на пакеты представляет собой процесс,
в результате которого исходные данные делятся на отдельные
блоки небольшого размера, снабженные специальной служебной
и управляющей информацией, которая должна обеспечить:
• возможность передачи данных, т. е. определить, каким об-
разом и куда передавать пакеты;
• сбор данных в надлежащем порядке на стороне получателя;
• проверку целостности и достоверности данных после их пе-
ресылки.
2.2.7. Методы взаимодействия
«Пакетная» организация обмена данными между абонентами
сети предполагает два основных принципа или метода взаимо-
действия (рис. 2.6):
• дейтаграммный метод, т. е. метод взаимодействия без уста-
новки логического соединения;
• метод взаимодействия с предварительной установкой логи-
ческого соединения.
При передаче пакета дейтаграммным методом логическое со-
единение не устанавливается и не ликвидируется после заверше-
Пакетданных 1
Пакет данных 2
Пакет данных 3
Узел 1
Узел 2
а
Узел 1
Узел 2
Запрос
Подтверждение запроса
Пакет данных
Подтверждение получения
Окончание передачи
б
Рис. 2.6. Методы информационного взаимодействия:
а — дейтаграммный; б — с установкой логического соединения
56
Глава 2. Организация сетевого взаимодействия
ния передачи, т. е. приемник и передатчик предварительно не об-
мениваются никакими служебными пакетами для выяснения го-
товности приемника, а также для подтверждения окончания
передачи. Задача проверки, дошел ли пересылаемый пакет до ад-
ресата или нет, переносится на более высокие уровни.
Другой метод, использующий при взаимодействии логическое
соединение, был разработан позднее, чем дейтаграммный метод,
и имеет более сложную организацию взаимодействия узлов в сети.
При работе по этому методу приемник и передатчик обмени-
ваются служебными пакетами, позволяющими устанавливать, ли-
квидировать и контролировать состояние логического канала
связи. Например, это могут быть запросы на установку соедине-
ния, подтверждения получения пакетов адресатом, запрос на по-
вторную передачу пакета в случае его потери,или искажения,
а также запрос на разрыв соединения.
2.2.2. Обобщенный формат пакета
Структура и размер пакетов, а также формат размещения
в них служебной информации определяются технологией по-
строения сети, в которой они используются, и зависят от исполь-
зуемой среды передачи данных, топологии сети, а также от осо-
бенностей ее аппаратных средств.
Синонимами термина «пакет» являются термины «кадр»,
«дейтаграмма». Выбор при употреблении тех или иных терминов
обычно обусловливается контекстом, с которым эти термины
употребляются.
Например, когда речь идет о физической среде передачи дан-
ных, обычно используется термин «кадр».
В общем случае любой пакет или кадр содержит следующие
поля (рис. 2.7):
• преамбула пакета — представляет собой определенную по-
следовательность битов, которая позволяет сетевым устрой-
ствам обнаружить присутствие сигнала в среде передачи
и произвести синхронизацию приемника, т. е. приготовить-
ся к приему данных;
• стартовый ограничитель — обозначает начало пакета;
• адрес (идентификатор) назначения — адрес узла, которому
адресован данный пакет, позволяющий этому узлу распо-
2.2. Принципы пакетной передачи данных
57
Рис. 2.7. Типичная структура пакета:
I — преамбула; 2 — стартовый ограничитель; 3 — адрес назначения; 4 — адрес
отправител; 5— служебная информации; 6— контрольная сумма; 7— конечный
ограничитель
знать, что пакет адресован ему лично, группе, в которую он
входит, или всем абонентам локальной сети одновременно
(при широковещательной передаче);
• адрес отправителя — адрес узла, сгенерировавшего и по-
славшего данный пакет в сеть;
• служебная информация — обычно содержит характеристики
пакета: тип, размер, формат, маршрут его доставки и т. д.;
• данные — непосредственно информация, которую необхо-
димо передать по сети, в зависимости от технологии органи-
зации сети, а также особенностей передачи данных может
иметь переменную длину;
• контрольная сумма пакета — некоторое значение, рассчи-
танное по определенным алгоритмам на основе данных все-
го пакета; формируется передающим узлом и используется
для выявления ошибок, возникающих при передаче пакета
по сети;
• конечный ограничитель — обозначает окончание пакета.
2.2.3. Формат кадров Ethernet
Передача данных по технологии Ethernet осуществляется с по-
мощью кадров, которые могут иметь один из четырех форматов:
• Raw 802.3 (или кадр Novell 802.3);
• 802.3/LLC (или кадр Novell 802.2);
• Ethernet II (или кадр Ethernet DIX);
• Ethernet SNAP.
Несоответствия отдельных полей в различных форматах кад-
ров иногда являются причиной неправильного функционирова-
ния аппаратуры, рассчитанной на работу только с одним из фор-
матов. Тем не менее практически все сетевое оборудование в на-
58
Глава 2. Организация сетевого взаимодействия
100 нс
Кадр Ethernet
Рис. 2.8. Передача кадров Ethernet:
1 — перамбула; 2 — стартовый ограничитель
6 байт 6 байт
Данные 46-1500 байт
/4
4 байта
Рис. 2.9. Формат кадра Ethernet Raw 802.3:
1 — адрес назначения; 2 — адрес отправителя; 3 — длина; 4— контрольная сумма
стоящее время способно работать со всеми используемыми при
организации сетевого взаимодействия форматами кадров техно-
логии Ethernet.
Передаче кадра Ethernet любого формата предшествует пре-
амбула кадра, а также стартовый ограничитель. Преамбула, по-
зволяющая синхронизировать приемник, представляет собой по-
вторяющуюся последовательность из семи байт 10101010. Старто-
вый ограничитель представляет собой всего один байт 10101011.
Следующий за стартовым ограничителем байт будет первым бай-
том заголовка передаваемого кадра (рис. 2.8).
Друг от друга кадры отделяются межкадровым интервалом —
паузой в 9,6 нс.
Формат кадра Raw 802.3, иногда также называемого кадром
Novell 802.3, описывается в стандарте IEEE 802.3 и представляет
собой совокупность следующих полей (рис. 2.9):
• адрес назначения;
• адрес источника;
• длина — определяет длину поля данных кадра;
• данные — не должно превышать 1500 байт, с другой сторо-
ны, минимальная длина этого поля 46 байт, поэтому, если
длина передаваемых данных оказывается меньше 46 байт,
данное поле дополняется псевдоданными, не несущими ни-
какой определенной информации, до нужной дины;
• контрольная сумма кадра.
2.2. Принципы пакетной передачи данных
59
6 байт 6 байт 2 байта 1 1 1
Данные 46-1497 байт
Рис. 2.10. Формат кадра Ethernet LLC:
/ — адрес назначения; 2 — адрес отправителя; 3 — длина; 4 — заголовок LLC;
5 — контроль; 6 — служба источника; 7— служба назначении; 8 — контрольная
сумма
6 байт 6 байт
2 байта
Данные 46-1500 байт
Рис. 2.11. Формат кадра Ethernet 11:
I — адрес назначения; 2 — адрес отправителя; 3 — тип; 4 — контрольная сумма
Кадр 802.3/LLC учитывает требования двух стандартов:
IEEE 802.3 и IEEE 802.2, где и описан LLC — стандарт управле-
ния логическим соединением. Формат этого кадра отличается от
предыдущего дополнительными полями, называемыми заголов-
ком LLC (рис. 2.10).
Заголовок LLC помещается после поля, содержащего длину
передаваемых данных, и содержит поля, приведенные на рис. 2.10:
• служба назначения (Destination Service Access Point, DSAP);
• служба источника (Source Service Access Point, SSAP);
• контроль.
Поля, определяющие служебные точки входа, позволяют ука-
зать, какие сообщения или данные, принадлежащие какой служ-
бе, пересылаются в данном кадре и, следовательно, какая служба
или процесс должны эти данные получить. В поле контроль про-
исходит передача специальных команд, которые используются
при установке соединения между узлами.
Стандарт Ethernet II или Ethernet DIX явился основой для
создания стандарта IEEE 802.3, неудивительно, что форматы их
кадров имеют одинаковую структуру (рис. 2.11). Однако при этом
кадр Ethernet II вместо поля «длина» содержит двухбайтовое поле
«идентификатор протокола», которое выполняет функции, ана-
логичные функциям полей DSAP и SSAP заголовка LLC, и пере-
60
Глава 2. Организация сетевого взаимодействия
6 байт 6 байт 2 байта 3 байта 3 байта 2 байта Данные 46-1497 байт 4 байта
Рис. 2.12. Формат кадра Ethernet SNAP:
/ — адрес назначения; 2 — адрес отправителя; 3 — длина; 4 — заголовок LLC;
5 — идентификатор организации; 6 — тип; 7— затолок SNAP; 8 —контрольная
сумма
3 4 5 6
10 нс
Кадр Ethernet
1 2 И-*Н
0,96 нс
Рис. 2.13. Передача кадров Fast Ethernet:
/ — преамбула; 2 — стартовый ограничитель
дает сведения о типе службы, процесса или протокола, сгенери-
ровавших данные, пересылаемые в данном кадре.
При этом тип службы или протокола кодируется таким обра-
зом, чтобы значение этого поля превышало 1500 байт, т. е. макси-
мальнодопустимый размер данных, передаваемых в кадре. Таким
образом, кадры Ethernet II и Raw 802.3 легко различить. Напри-
мер, если значение поля меньше 1500, то это поле определяет
длину передаваемых данных, а кадр является кадром Raw 802.3.
Формат кадра Ethernet SNAP (SubNetwork Access Protocol —
протокол доступа к подсетям) описывается в одном из расширений
стандарта 802.2 и представляет собой кадр Ethernet 802.3/LLC, до-
полненный полями «идентификатор организации» и «идентифи-
катор протокола» (рис. 2.12).
Поле «идентификатор организации» (Organizationally Unique
Identifier — OU1), содержит код организации-производителя сете-
вого оборудования, которая определяет свои собственные коды
типов служб или протоколов, помещаемых в поле «идентифика-
тор протокола».
С появлением новой технологии Fast Ethernet, позволяющей
передавать данные на скорости в 100 Мбит/с, форматы кадрц.
не изменились.
2.2. Принципы пакетной передачи данных
61
По сути, технология практически не изменилась, десяти-
кратное увеличение скорости было достигнуто за счет десяти-
кратного уменьшения времени на передачу одного кадра, а так-
же межкадрового интервала (рис. 2.13). Таким образом, в техно-
логии Fast Ethernet битовый интервал стал составлять 10 нс,
а межкадровый — 0,96 нс.
2.2.4. Формат кадров Token Ring
Сети, построенные на основе технологии Token Ring, исполь-
зуют три типа кадров, имеющих различный формат и выполняю-
щих различные задачи:
• кадр маркера;
• кадр данных;
• прерывающая последовательность.
Кадр маркера состоит из трех однобайтовых полей (рис. 2.14):
• начальный ограничитель;
• контроль доступа — состоит из четырех подполей:
— приоритет — содержит значение приоритета кадра (от 0
ДО 7);
— признак маркера — если значение этого поля равно еди-
нице, то кадр является маркером;
— признак монитора — если значение этого поля равно еди-
нице, то данный кадр был послан активным монитором
сети. Таким образом, если данный кадр получает актив-
ный монитор, то это значит, что кадр уже раз обошел
кольцо и по каким-либо причинам не был обработан
станциями;
Рис. 2.14. Формат маркера в сетях Token Ring:
I— стартовый ограничитель; 2— контроль доступа; 3 — приоритет; 4— признак
маркера; 5— признак монитора; 6— резервный приоритет; 7— конечный ограни-
читель
62
Глава 2. Организация сетевого взаимодействия
— резервный приоритет — содержит максимальное значе-
ние приоритета кадров станций, пытающихся получить
доступ к среде передачи;
• конечный ограничитель — последовательность битов,
идентифицирующая окончание кадра; последние два байта
данного поля в технологии Token Ring используются для
передачи “информации о том, является или нет данный
кадр последним в серии передаваемых кадров, а также
о возникновении каких-либо ошибок при пересылке дан-
ного кадра.
Кадр, являющийся транспортом для передаваемых по сети
данных состоит из следующих полей (рис. 2.15):
• стартовый ограничитель;
• контроль доступа;
• контроль кадра;
• адрес получателя;
• адрес отправителя;
• данные;
• контрольная сумма;
• конечный ограничитель;
• статус кадра.
Поля начального и конечного ограничителей, а также контро-
ля доступа идентичны аналогичным полям маркера. Поле «кон-
троль кадра» содержит два подполя:
• тип кадра — характеризует тип передаваемой информации:
данные приложений пользователя или служебные данные
для управления работой сети;
• идентификатор управления — используется только при пе-
редаче сл^окебной управляющей информации и определяет
тип управляющего кадра.
1 байт 1 байт 1 байт 6 байт 6 байт Данные 4472/17 800 байт
Рис. 2.15. Формат кадра данных в сетях Token Ring:
/ — стартовый ограничитель; 2— контроль доступа; 3 — контроль кадра; 4 — адрес
назначения; 5 — адрес отправителя; 6 — контрольная сумма; 7 — статус кадра;
8 — конечный ограничитель
2.2. Принципы пакетной передачи данных
63
Управляющие кадры, т. е. кадры, содержащие служебную
управляющую информацию, делятся на шесть типов и могут вы-
полнять следующие задачи:
• проверку уникальности физического адреса рабочей стан-
ции сети;
• оповещение рабочих станций сети о благополучном функ-
ционировании активного монитора сети;
• оповещение о существовании резервного монитора — лю-
бой станции, не являющейся активным монитором, но го-
товой взять на себя выполнение его функций по управле-
нию сетью;
• обмен информацией между станциями при выборе активно-
го монитора сети;
• передачу специальных тестирующих кадров, помогающих
локализовать возможную неисправность в работе сети;
• «очистку» кольца, т. е. отбрасывание всех ранее переданных
кадров после выбора активного монитора и инициализации
кольца.
Поля «адрес получателя» и «адрес отправителя» содержат со-
ответствующие адреса, имеющие ту же структуру, что и адреса,
используемые в Ethernet.
Поле данных кадра может содержать либо данные пользова-
тельских приложений, либо служебную информацию и команды,
необходимые для управления работой кольца. Максимально до-
пустимая длина этого поля составляет 4472 байта для сети, рабо-
тающей на скорости 4 Мбит/с, и 17 800 байт для сети 16 Мбит/с.
Однобайтовое поле «статус кадра» состоит из двух подполей:
• признак распознавания — сигнализирует о том, что адрес
станции назначения определен и опознан;
• признак копирования — при создании кадра устанавливает-
ся в ноль и меняется на единицу только станцией-получате-
лем в случае удачного приема этого кадра и при отсутствии
ошибок.
Таким образом, поле статуса кадра используется для контроля
и гарантии доставки всей передаваемой информации получателю.
Кадр прерывающей последовательности состоит из двух бай-
тов: начального и конечного ограничителей. Прерывающая по-
следовательность оповещает рабочие станции о том, что текущая
передача кадра или маркера отменяется.
64
Глава 2. Организация сетевого взаимодействия
2.3. Сетевые модели
2.3.1. Понятие сетевой модели
При взаимодействии по сети производится множество опера-
ций, обеспечивающих передачу данных с одной рабочей станции
на другую. При этом передаваемые данные проходят множество
этапов обработки.
Сначала данные разбиваются на отдельные блоки, из которых
формируются кадры данных, снабженные метками, и идентифи-
каторы для того, чтобы потом данные можно было снова «со-
брать» воедино такими, какими они были до разбиения. Получен-
ные кадры кодируются и передаются по сети в виде электриче-
ских или световых сигналов.
На стороне принимающей рабочей станции данные проходят
обработку в обратном порядке: принимаются, декодируются, со-
бираются из блоков, принимая первоначальный вид.
Действия по подготовке информации для передачи, передача,
прием и обработка информации после приема осуществляются
частично программными средствами, частично аппаратными.
Но при передаче сообщений оба участника сетевого обмена
должны принять множество соглашений. Они должны согласо-
вать уровни и форму передаваемых сигналов, способ определения
длины сообщений, определить методы контроля достоверности
получаемой информации и многое другое.
Для упорядочивания и обеспечения возможности стандарти-
зировать все выполняемые при взаимодействии по сети процеду-
ры используют архитектурный подход, согласно которому сете-
вые системы описываются с помощью сетевых моделей.
Сетевая модель устанавливает соглашения о том, как переда-
вать и принимать данные для всех этапов взаимодействия по сети,
начиная от передачи битов, до определения того, как информа-
ция должна быть интерпретирована.
2.3.2. Сетевая модель OS!
По мере развития компьютерных технологий производители
аппаратуры, оборудования и техники, работающие в этой облас-
ти, исходя из своих собственных исследований и разработок,
предлагали продукцию, использующую различные архитектуры
2.3. Сетевые модели
65
и принципы построения вычислительных систем. Со временем
это привело к возникновению проблемы переносимости (мо-
бильности) программ и данных между компьютерами, имеющими
различную архитектуру и различные аппаратные платформы.
Необходимость решения этих проблем привела к созданию
концепции открытых систем.
Открытая система — это некая вычислительная среда, состоя-
щая из аппаратных и программных продуктов и использующая
технологии, разработанные в соответствии с общедоступными
и общепринятыми стандартами.
Одним из первых шагов в этом направлении явилось созда-
ние компьютеров серии IBM 360, обладающих единым набором
команд и способных работать в одной и той же операционной
системе.
Стремление к использованию открытых систем обусловлива-
ется возможностью обеспечить совместимость систем, исполь-
зующих различные аппаратные платформы, что приводит к воз-
можности более универсально использовать программное обеспе-
чение и информацию.
С развитием сетевых технологий возникла необходимость
в создании стандартов взаимосвязи в сетях открытых систем.
В начале 80-х годов международной организацией по стандар-
тизации (ISO) на основе сетевой архитектуры SNA (System Network
Architecture) компании IBM была разработана модель взаимодей-
ствия открытых систем (Open System Interconnection — OSI).
Модель OSI, очень часто называемая эталонной моделью
взаимодействия открытых систем, разбивает все процессы взаи-
модействия и передачи данных по сети на семь уровней
(табл. 2.1). Этой же моделью для каждого уровня определяются
выполняемые ими функции, даются термины и определения ос-
новных понятий.
Формализованные правила, определяющие порядок и формат
сообщений, которыми обмениваются сетевые компоненты, пред-
ставляющие один уровень, но находящиеся в разных узлах сети,
называются протоколами.
Более простое определение: протоколы — это набор правил
я процедур, регулирующих порядок осуществления связи.
Вышестоящие уровни сетевой модели выполняют более слож-
ные, глобальные задачи, для этого используют в своих целях ни-
жестоящие уровни, а также управляют ими. Задача нижестоящего
66
Глава 2. Организация сетевого взаимодействия
Таблица 2.1. Уровни модели OSI/ISO
Номер Название уровня
7 Прикладной
6 Представления (или представительский)
5 Сеансовый
4 Транспортный
3 Сетевой
2 Канальный
1 Физический
уровня — предоставление услуг вышестоящему уровню, обеспечи-
вающих возможность выполнения его задач, причем вышестоя-
щему уровню не важно, каким образом эти услуги реализуются.
Нижестоящие уровни выполняют более простые и конкретные
функции. В идеале каждый уровень взаимодействует только с те-
ми, которые находятся рядом с ним (выше и ниже него). Верхний
уровень соответствует прикладной задаче, работающему в данный
момент приложению, нижний — непосредственной передаче сиг-
налов по каналу связи.
Для взаимодействия между собой протоколы смежных уров-
ней, находящиеся в одном узле сети, используют интерфейсы —
четко определенные правила и стандартизованные форматы со-
общений.
Интерфейс определяет набор услуг, которые нижележащий
уровень предоставляет вышележащему.
При передаче данных по сети связь уровней между собой осу-
ществляется посредством интерфейсов, а пересылка с одного узла
на другой — с помощью протоколов.
Например, сформировав сообщение для передачи по сети,
прикладной уровень передает его на нижний уровень, т. е. на уро-
вень представления. Протокол уровня представления, получив
сообщение, обрабатывает его. При этом к сообщению добавляет-
ся заголовок, содержащий служебную информацию. После этого
сообщение «спускается» на сеансовый уровень, где оно также об-
рабатывается и снабжается еще одним заголовком — на этот раз
сеансового уровня.
2.3. Сетевые модели
67
Сообщение
от прикладной программы
Прикладной
уровень
Уровень
представления
Сеансовый
уровень
Транспортный
уровень
Сетевой
уровень
...01010100110100....
Канальный
уровень
Физический
уровень
Добавлена информация
об адресате сообщения
Добавлена информация
о кодировке
Добавлена коммуникаци-
онная информация
Добавлен заголовок
контрольной суммы
Добавлена информация
о характеристиках пакета
Добавлена служебная инфор-
мация канального уровня
Кодировка и передача в виде
битовой последовательности
Рис. 2.16. Инкапсуляция пересылаемого сообщения при продвижении
его вниз по стеку протоколов
Иногда, помимо заголовка, служебная информация помеша-
ется в конец сообщения. В этом случае говорят, что сообщению
добавлен трейлер («концевик», или «терминатор»).
Продвигаясь на нижние уровни, сообщение постепенно об-
растает заголовками и трейлерами. Эта операция называется ин-
капсуляцией данных верхнего уровня в пакет нижнего уровня
(рис. 2.16). Служебная информация, помещаемая в заголовок,
а иногда и в конец сообщения, предназначается для объекта того
же уровня на удаленном компьютере, при этом ее формат и ин-
терпретация определяются протоколом данного уровня.
Таким образом, данные, приходящие с верхнего уровня, пред-
ставляют собой пакеты с уже инкапсулированными данными еще
более верхнего уровня.
После передачи пакета по сети адресату он начинает продви-
жение по уровням «наверх». При этом на каждом уровне считыва-
ется служебная информация из заголовков и трейлеров пакета,
выполняются соответствующие уровню функции, после этого за-
головок, соответствующий текущему уровню, удаляется, и пакет
передается на следующий вышележащий уровень. То есть проис-
ходит декапсуляция пакета — процесс, обратный инкапсуляции,
в результате которого данные, «очищенные» от служебной ин-
формации, попадают к пользовательским приложениям.
68
Глава 2. Организация сетевого взаимодействия
2.3.3. Задачи и функции по уровням модели OS!
Физический уровень (Physical Layer) определяет физические,
механические и электрические характеристики линий связи,
к которым относятся:
• тип кабелей и разъемов;
• разводка контактов в разъемах;
• схемы бинарного кодирования сигналов.
На этом уровне осуществляется прием и передача данных по
линиям связи. Данные, поступающие с канального уровня, коди-
руются в электрические или световые сигналы, после этого пере-
даются. При приеме полученные с лини связи данные декодиру-
ются и передаются на дальнейшую обработку на канальный уро-
вень. Со стороны компьютера функции физического уровня
в локальных сетях обычно выполняются сетевым адаптером,
а в глобальных — модемом.
Канальный уровень (Data Link Layer) определяет формирова-
ние пакетов соответствующего используемой сети вида. Каналь-
ный уровень обычно разделяют на два подуровня:
• управление логической связью (Logical Link Control —
LLC);
• доступ к среде передачи данных (Media Access Control —
MAC).
Верхний подуровень управления логической связью осущест-
вляет установку и поддержку виртуального канала связи, а также
обеспечивает взаимодействие с сетевым уровнем.
Нижний подуровень доступа к среде передачи данных обеспе-
чивает непосредственный доступ к каналу связи и связан с аппа-
ратурой сети. Помимо контроля над состоянием сети, повторной
передачи кадров при их утере, приема кадров и проверки пра-
вильности передачи, в функции этого уровня входит взаимодей-
ствие с физическим уровнем.
Сетевой уровень (Network Layer) обеспечивает адресацию пе-
ресылаемых пакетов. Также здесь решаются задачи управления
потоками данных в сети и маршрутизации, т. е. выбора маршрута
передачи данных по узлам сети.
Транспортный уровень (Transport Layer) является своего рода
связующим звеном между более высокими уровнями, сильно за-
висящими от приложений, и нижними уровнями, более привя-
занными к линиям связи.
2.4. Стеки протоколов
69
На транспортном уровне происходит разбиение передаваемой
информации на пакеты и сборка принимаемых данных из паке-
тов. Здесь же обеспечивается контроль над передачей данных.
На транспортном уровне реализованы возможности обнаружения
и исправления ошибок передачи данных, вызванными искаже-
ниями, потерями или дублированием пакетов.
Кроме того, на этом уровне происходит согласование сетевых
уровней различных несовместимых сетей.
Сеансовый уровень (Session Layer) обеспечивает координацию
связи между двумя рабочими станциями сети. Уровень организует
сеанс обмена данными, управляет приемом и передачей пакетов,
обеспечивает завершение сеанса. Кроме того, осуществляется
контроль над степенью завершения длинных передач, что позво-
ляет избежать повторной пересылки данных при разрывах связи
и возобновить передачу с прерванного места.
Уровень представления (Presentation Layer) имеет дело с внеш-
ним представлением данных и обеспечивает преемственность пе-
редаваемой информации с одной системы для другой системы.
С его помощью преодолеваются различия, например, между все-
возможными кодировками символов или синтаксиса.
Средства уровня представления позволяют выполнять различ-
ные виды преобразования данных: шифрование, дешифрование,
сжатие.
Прикладной уровень (Application Layer) реализует взаимодейст-
вие прикладных программ пользователя с процессами модели
OSI, обеспечивая им набор определенных сетевых услуг, таких,
как передача файлов, обмен почтовыми сообщениями, управле-
ние сетью и т. д.
2.4. Стеки протоколов
Стек протоколов — это иерархически организованная сово-
купность протоколов, достаточных для реализации взаимодейст-
вия узлов в компьютерной сети.
В отличие от модели, представляющей собой концептуальную
схему взаимодействия систем, стек протоколов представляет на-
бор конкретных спецификаций, позволяющих реализовать сете-
вое взаимодействие.
70
Глава 2. Организация сетевого взаимодействия
Существует достаточно много стеков протоколов, широко
применяемых в сетях. Это стеки, появившиеся на основе между-
народных и национальных стандартов, стеки, предложенные
фирмами-производителями сетевого оборудования, получившие
распространение благодаря распространенности оборудования
этой фирмы.
Примерами популярных стеков протоколов могут служить:
стек IPX/SPX фирмы Novell, стек TCP/IP, используемый в сети
Internet и во многих сетях на основе операционной системы UNIX,
стек DECnet корпорации Digital Equipment и некоторые другие.
Некоторые из них будут более подробно рассмотрены ниже.
Применения в сети различных стеков коммуникационных
протоколов порождает большое разнообразие характеристик
и структур этих сетей. В небольших сетях достаточно использова-
ние одного стека, но в крупных корпоративных сетях, объеди-
няющих различные подсети, как правило, параллельно использу-
ются несколько стеков.
Протоколы могут быть реализованы в виде программных эле-
ментов операционной системы. Например, очень часто протоко-
лы канального уровня выполнены в виде драйвера сетевого адап-
тера, а функции протоколов верхних уровней представляются
серверными или клиентскими компонентами сетевых служб.
В коммуникационном оборудовании реализуются протоколы
нижних уровней, которые в большей степени стандартизованы,
чем протоколы верхних уровней, что является предпосылкой для
успешной совместной работы оборудования от различных произ-
водителей.
Например, на физическом и канальном уровнях практически
во всех стеках используются одни и те же протоколы. Это хорошо
стандартизованные протоколы Ethernet, Token Ring, FDDI и дру-
гие, позволяющие использовать во всех сетях одинаковую аппа-
ратуру.
Протоколы более высоких уровней, начиная с сетевого, в су-
ществующих стандартных стеках отличаются большим разнообра-
зием и зачастую не соответствуют рекомендуемому моделью ISO
разбиению на уровни. Например, функции сеансового и уровня
представления могут быть объединены с прикладным уровнем.
Такое несоответствие объясняется тем, что сетевая модель
ISO появилась как результат обобщения уже существующих и ре-
ально используемых стеков, а не наоборот.
2.4. Стеки протоколов
71
2.4.1. Стек протоколов OSI
Каждому уровню модели OSI соответствует один или не-
сколько протоколов, выполняющих функции обеспечения сете-
вого взаимодействия.
Стек протоколов OSI соответствует модели OSI и включает
протоколы для всех семи уровней (табл. 2.2).
На физическом и канальном уровнях стека OSI используются
стандартные протоколы Ethernet, Token Ring и т. д.
Сетевой уровень реализован с помощью протоколов ES-ES
и IS-IS:
ES-IS (End System to Intermediate System routing exchange pro-
tocol) — протокол маршрутизации оконечных систем, посредст-
вом которого оконечные системы (рабочие станции) оповещают
о себе промежуточные системы (например, концентраторы);
IS-IS (Intermediate System to Intermediate System routing ex-
change protocol) — протокол маршрутизации промежуточных
станций, посредством которого промежуточные системы обмени-
ваются информацией о действующих маршрутах сети.
Эти протоколы используются для «разведки» и построения
полной, последовательной картины топологии сети, чтобы обес-
печить возможность маршрутизации пересылаемых пакетов.
Транспортный, сеансовый и уровень представления реализо-
ваны соответствующими протоколами OSI, которые имеют край-
не малое распространение.
Таблица 2.2. Стек протоколов OSI
Уровень модели OSI Протоколы OSI
7. Прикладной FTAM, VTP, Х.400 и Х.500
6. Представления Протокол представления OSI
5. Сеансовый Сеансовый протокол OSI
4. Транспортный Транспортный протокол OSI
3. Сетевой ES-IS, IS-IS
2. Канальный Ethernet, Token Ring, FDDI, X.25, ISDN, ATM, LAP-D, PPP и др.
I. Физический Спецификации физических сред
72
Глава 2. Организация сетевого взаимодействия
Наибольшую популярность получили протоколы прикладно-
го уровня стека OSI. Это прежде всего протоколы FTAM, VTP,
Х.400 и Х.500.
FTAM (File Transfer Access and Management) — протокол пере-
дачи, обеспечения доступа и управления файлами.
VTP (Virtual Terminal Protocol) — протокол, описывающий ра-
боту виртуального терминала.
Х.400 — представляет собой набор рекомендаций Междуна-
родного консультативного комитета по телеграфии и телефонии
(CCITT — от франц. Comite' Consultatif International Te'lephonique
et Te'legraphique), в которых описываются системы пересылки
электронных сообщений. В роли протокола Х.400 определяет
структуру сообщений электронной почты, так что все сообщения
удовлетворяют стандартному формату.
Х.500 — расширение стандарта Х.400, определяющее формат
адреса сообщения и позволяющее всем системам электронной
почты связываться между собой. Изначально целью рекоменда-
ций Х.500 является выработка стандартов глобальной справочной
службы. Однако процесс доставки сообщения требует знания ад-
реса получателя. При больших размерах сетей возникает пробле-
ма хранения, поиска и получения адресов. Решением этой про-
блемы является справочная служба, помогающая получать адреса
отправителей и получателей и представляющая собой распреде-
ленную базу данных имен и адресов.
Модель OSI сделала популярной идею обшей модели уровней
протоколов, определяющей взаимодействие между сетевыми уст-
ройствами и программным обеспечением.
Тем не менее стек протоколов OSI, разработанный как часть
проекта и направленный обеспечить однородность при построе-
нии сетей, и, следовательно, универсальность взаимодействия,
был воспринят многими как слишком усложненный и мало реали-
зуемый. Дело в том, что разработка и внедрение стека OSI предпо-
лагали отказ от существующих протоколов и переход на новые на
всех уровнях стека. Это сильно затруднило реализацию стека и по-
служило причиной для отказа от него многих компаний, сделав-
ших значительные инвестиции в другие сетевые технологии.
Таким образом, когда были реализованы протоколы для мо-
дели OSI, выявился ряд проблем:
• протоколы основаны на концепциях, имеющих мало смыс-
ла в современных сетях;
2.4. Стеки протоколов
73
• спецификации в некоторых случаях оказались неполными
или противоречивыми;
• по функциональным возможностям протоколы OS1/ISO ус-
тупали другим протоколам;
• наличие большого числа уровней требует большой вычисли-
тельной мощности и, следовательно, приводит к более низ-
кой производительности.
2.4.2. Стек протоколов TCP/IP
Стек TCP/IP, также часто называемый стеком Интернет, в на-
стоящее время является наиболее популярным и быстроразви-
вающимся (табл. 2.3).
Этот стек был разработан по инициативе Министерства обо-
роны США и изначально ориентировался на обеспечение связи
разнородных вычислительных сетей.
Поскольку стек протоколов TCP/IP был разработан до появ-
ления сетевой модели ISO/OSI, то соответствие его уровней уров-
ням модели OSI носит весьма условный характер, хотя он также
имеет многоуровневую структуру.
Стек был реализован для работы в операционной системе
Unix, популярность которой привела к широкому распростране-
нию протоколов TCP/IP, благодаря которым стек и получил свое
название, а также другим протоколам стека.
Таблица 2.3. Стек протоколов TCP/IP
Уровни модели OSI Протоколы TCP/IP Уровни TCP/IP
7 FTP, TFTP, Gopher, telnet, SMTP, SNMP... 1
6
5 TCP, UDP 11
4
3 IP, ICMP, RIP, OSPF III
2 He регламентировано, но поддерживаются все популярные стандарты IV
1
74
Глава 2. Организация сетевого взаимодействия
Самый нижний уровень стека — уровень межсетевых
интерфейсов — соответствует физическому и канальному уров-
ням модели OSI. В стеке TCP/IP этот уровень не регламентиро-
ван, но тем не менее реализована поддержка практически всех
популярных стандартов физического и канального уровня:
Ethernet, Token Ring, FDDI (для локальных сетей) и Х.25, ISDN,
SLIP/PPP (для глобальных сетей).
Уровень межсетевого взаимодействия (уровень III) обеспечи-
вает маршрутизацию и передачу данных по сети, выполняя, та-
ким образом, функции, соответствующие сетевому уровню моде-
ли OSI. На этом уровне используются протоколы IP, ISMP, RIP,
OSPF.
IP (Internet Protocol) — межсетевой протокол, обеспечивает
передачу пакетов в сетях.
RIP (Routing Internet Protocol) и OSPF (Open Shortest Path
First) — протоколы сбора маршрутной информации, обеспечи-
вающие составление и модификацию специальных таблиц мар-
шрутизации, используемых при выборе пути пересылки данных
по сети.
ICMP (Internet Control Message Protocol) — протокол меж-
сетевых управляющих сообщений, предназначенный для орга-
низации обратной связи с отдельными узлами сети при обмене
информацией об ошибках, например, о невозможности доставки
пакета, о превышении времени жизни или продолжительности
сборки пакета из фрагментов, о ненормальных значениях пара-
метров. Кроме того, с помощью этого протокола передаются тес-
тирующие пакеты и пакеты, содержащие служебные информаци-
онные сообщения, например об изменении маршрута пересылки
и типа обслуживания, о состоянии системы и т. п.
Уровень II стека TCP/IP называется основным и обеспечива-
ет функции транспортировки информации по сети. При этом ис-
пользуются два протокола TCP и UDP, реализующих различные
механизмы доставки данных и имеющих различные степени на-
дежности.
TCP (Transmission Control Protocol) — протокол управления
передачей, работающий с установкой логического соединения
между удаленными прикладными процессами, а также исполь-
зующий принцип автоматической повторной передачи пакетов,
содержащих ошибки.
2.4. Стеки протоколов
75
UDP (User Datagram Protocol) — протокол пользовательских
дейтаграмм (синоним термина «пакет»), являющийся упрощен-
ным вариантом TCP и работающий без установки логического
соединения, и, соответственно, не обеспечивающий проверку на
наличие ошибок и подтверждение доставки пакета.
Верхний уровень стека TCP/IP называется прикладным.
К протоколам этого уровня относятся такие широко используе-
мые протоколы, как FTP, telnet, SMTP, SNMP и многие другие.
FTP (File Transfer Protocol) — протокол передачи файлов, ис-
пользующий в качестве транспортного протокол с установлением
соединений — TCP, что повышает надежность передачи файлов.
Протокол, предназначенный для обеспечения передачи и приема
файлов между серверами и клиентами.
TFTP (Trivial File Transfer Protocol) — простейший протокол пе-
редачи файлов. В отличие от FTP этот протокол базируется на рабо-
те с UDP, при этом протокол реализует только передачу файлов.
SNMP (Simple Network Management Protocol) — простой прото-
кол управления сетью, предназначенный для передачи информа-
ции, определяющей форматы сообщений, которыми обмениваются
клиенты и серверы, а также форматы имен и адресов узлов сети.
Telnet — протокол, обеспечивающий передачу потока байтов
между процессами или между процессом и терминалом и обычно
использующийся для эмуляции терминала удаленной станции.
SMTP (Simple Mail Transfer Protocol) — простой протокол пе-
редачи почты, использующийся для обеспечения передачи элек-
тронных почтовых сообщений с применением транспортного
протокола TCP.
Gopher — протокол доступа клиентов к файлам и каталогам
в сети Интернет, предоставляющий только текстовую информа-
цию. Gopher обычно используется для передачи очень больших
документов, не содержащих форматирования или иллюстраций.
2.4.3. Стек протоколов IPX/SPX
Стек протоколов IPX/SPX был разработан компанией Novel
в начале 80-х годов для использования в операционной системе
NetWare.
Изначально стек ориентировался на работу в локальных сетях
небольших размеров и имеющих небольшие вычислительные
76
Глава 2. Организация сетевого взаимодействия
Таблица 2.4. Стек протоколов IPX/SPX
Уровни .модели OSI Протоколы IPX/SPX
7 NCP, SAP
6
5
4 SPX
3 IPX, RIP, NLSP
2 Поддерживаются все популярные стандарты
1
мощности, поэтому протоколы IPX/SPX имеют свои особенности
(табл. 2.4).
На уровне, соответствующем физическому и канальному
уровням модели OSI, стек IPX/SPX поддерживает все популяр-
ные протоколы этих уровней.
Следующий уровень, выполняющий функции сетевого уров-
ня модели OSI, реализован протоколами IPX, RIP и NLSP.
IPX (Internetwork packet exchange) — межсетевой обмен
пакетами — протокол, регламентирующий обмен данными по се-
ти и работающий по дейтаграммному принципу, т. е. без установ-
ки предварительного логического соединения, что обеспечивает
более экономное потребление вычислительных ресурсов.
RIP (Routing Information Protocol) — протокол маршрутной
информации, представляет собой один из старейших протоколов,
реализующих процессы обмена маршрутной информацией, одна-
ко он до сих пор чрезвычайно распространен в вычислительных
сетях.
NLSP (NetWare Link Servies Protocol) — протокол управления
связями NetWare — протокол, разработанный под операционные
системы NetWare, который обеспечивает передачу данных и по-
зволяет выбирать оптимальные маршруты в сети. Этот протокол
является аналогом протокола OSPF стека TCP/IP.
На уровне, соответствующем транспортному, используется
протокол SPX, давший часть названия стека, в котором он ис-
пользуется.
SPX (Sequenced Packet eXchange) — упорядоченный обмен
пакетами — коммуникационный протокол, разработанный для
2.4. Стеки протоколов
77
использования в сетях NetWare. SPX работает с установкой логи-
ческого соединения и обеспечивает гарантированную доставку
и порядок сообщений в потоке пакетов, для посылки которых ис-
пользует протокол IPX.
На верхних уровнях используются протоколы NCP и SAP.
NCP (NetWare Core Protocol) — основной протокол для пере-
дачи информации между сервером NetWare и рабочей станцией.
С помощью функций этого протокола рабочая станция произво-
дит подключение к серверу, имеет возможность просмотреть фай-
ловую систему сервера, копирует удаленные файлы, осуществляет
разделение сетевого принтера между рабочими станциями и т. д.
SAP (Service Advertising Protocol) — протокол объявления о
сервисе, по принципу действия подобен протоколу RIP. Анало-
гично с тем, как различные узлы сети обмениваются маршрутной
информацией с помощью протокола R1P, сетевые устройства по-
лучают возможность обмениваться информацией об имеющихся
сетевых сервисах, используя протокол SAP.
2.4.4. Стек протоколов NetBIOS/SMB
Стек NetBIOS/SMB — совместный проект компаний
Microsoft и IBM, разработанный в 1984 г. (табл. 2.5).
Стек работает со всеми наиболее распространенными прото-
колами нижнего уровня.
На верхних уровнях работают протоколы NetBEUI и SMB.
Протокол NetBIOS (Network Basic Input/Output System) стал
расширением стандартных функций базовой системы вводы/вы-
Таблица 2.5. Стек протоколов NetBIOS/SMB
Уровни модели OS1 Протоколы NetBIOS/SMB
7 SMB
6
5 NetBIOS, NetBEUI
4
3
2 Поддерживаются все популярные стандарты
1
78
Глава 2. Организация сетевого взаимодействия
вода (BIOS — Base Input/Output System), обеспечивающем под-
держку работы в сети. В дальнейшем NetBIOS был заменен про-
токолом NetBEUI. При этом NetBIOS все же был сохранен для
обеспечения совместимости приложений.
NetBEUI (NetBIOS Extended User Interface) — протокол рас-
ширенного пользовательского интерфейса NetBIOS, предостав-
ляющий функции, относящиеся к сеансовому, транспортному
и частично к сетевому уровням модели OSI. NetBIOS поддержи-
вает как дейтаграммный способ обмена данными, так и обмен
с установлением логических соединений. Однако этот протокол
не обеспечивает маршрутизацию пакетов, поэтому его примене-
ние ограничивается только небольшими локальными сетями. Для
решения этой проблемы используется NBF (NetBEUI Frame) —
реализация этого протокола, впервые появившаяся в операцион-
ной системы Microsoft Windows NT. Тем не менее в сложных се-
тях предпочитают использовать более универсальные протоколы
стеков TCP/IP и IPX/SPX.
SMB (Server Message Block) — протокол, выполняющий
функции прикладного уровня и уровня представления модели
OSI, определяет взаимодействие рабочей станции и сервера. SMB
предоставляет основные сетевые сервисы, необходимые прило-
жениям: управление сессиями передачи данных, установку и лик-
видацию логического соединения, доступ для работы с файлами,
сетевую печать, передачу сообщений и т. д.
2.4.5. Другие стеки протоколов
Такие стеки, как AppleTalk компании Apple, SNA фирмы IBM
или стек DECnet корпорации Digital Equipment, получили мень-
шее распространение, так как применяются в основном в опера-
ционных системах и сетевом оборудовании, производимых пере-
численными фирмами, и, соответственно, ориентированных на
использование системных архитектур и аппаратных платформ
этих же фирм.
Любой протокол по тем или иным условиям может соответст-
вовать некоторому уровню модели OSI. Однако, в силу того, что
разработчики не строго придерживаются модели OSI и что мно-
гие протоколы и стеки появились до разработки эталонной моде-
ли, зачастую протоколы могут относиться сразу к нескольким
2.5. Различия и особенности распространенных протоколов 79
уровням, либо наоборот, выполнять только часть функций одного
из уровней. Все это приводит к тому, что для того чтобы обеспе-
чить успешную работу протоколов и реализовать законченный
набор функций, обеспечивающих обмен данными по сети, при-
ходится использовать протоколы из одного стека. Это приводит
к несовместимости со стандартной моделью открытых систем.
2.5. Различия и особенности
распространенных протоколов
Протоколы, используемые для обмена данными в локальных
сетях, делятся по своей функциональности на три типа:
• прикладные;
• транспортные;
• сетевые.
Прикладные протоколы выполняют функции трех верхних
уровней модели OSI — прикладного, уровня представления и се-
ансового. Они обеспечивают взаимодействие приложений и об-
мен данными между ними. К наиболее популярным прикладным
протоколам относятся:
• FTAM (File Transfer Access and Management) — протокол
OSI доступа к файлам;
• Х.400 — протокол OSI для международного обмена элек-
тронной почтой;
• Х.500 — протокол OSI служб файлов и каталогов на не-
скольких системах;
• SMTP (Simple Mail Transfer Protocol) — протокол Интернета
для обмена электронной почтой;
• FTP (File Transfer Protocol) — протокол Интернета для пере-
дачи файлов;
• SNMP (Simple Network Management Protocol) — протокол
для мониторинга сети, контроля за работой сетевых компо-
нентов и управления ими;
• Telnet — протокол Интернета для регистрации на удаленных
серверах и обработки данных на них;
• SMB (Server Message Blocks) — протокол взаимодействия ра-
бочей станции и сервера фирмы Microsoft;
• NCP (NetWare Core Protocol) — протокол передачи данных
между сервером NetWare и рабочей станцией фирмы Novell;
80
Глава 2. Организация сетевого взаимодействия
• Apple Talk и Apple Share — набор сетевых протоколов фир-
мы Apple;
• AFP (AppleTalk Filling Protocol) — протокол удаленного до-
ступа к файлам фирмы Apple;
• DAP (Data Access Protocol) — протокол доступа к файлам се-
тей DECnet.
Транспортные протоколы реализуют функции транспортного
и сеансового уровня модели OSI. Они инициализируют и поддер-
живают сеансы связи между узлами сети и обеспечивают требуе-
мый пользователем уровень надежности передачи данных. Наи-
более популярны из них следующие:
• TCP (Transmission Control Protocol) — протокол Интернета
для гарантированной доставки данных, разбитых на после-
довательность фрагментов;
• SPX (Sequential Packet Exchange) — протокол стека IPX/SPX
для передачи данных, разбитых на последовательность
фрагментов, фирмы Novell;
• NetBIOS (Network Basic Input/Output System) — протокол
устанавливает и контролирует сеансы связи между компью-
терами;
• ATP (AppleTalk Transaction Protocol), NBP (Name Binding
Protocol) — протоколы сеансов связи и транспортировки
данных фирмы Apple.
Сетевые протоколы выполняют функции трех нижних уров-
ней модели OSI — сетевого, канального и физического. Эти про-
токолы управляют адресацией, маршрутизацией, проверкой оши-
бок и повторной передачей кадров, обеспечивая услуги связи,
и определяют правила осуществления связи в отдельных средах
передачи данных, например Ethernet или Token Ring. К наиболее
популярным сетевым протоколам относятся:
• IP (Internet Protocol) — протокол Интернета для передачи
пакетов;
• IPX (Internetwork Packet Exchange) — протокол для передачи
и маршрутизации пакетов фирмы Novell;
• NetBEUI — транспортный протокол, обеспечивающий
услуги транспортировки данных для сеансов и приложений
NetBIOS фирмы Microsoft;
• DDP (Datagram Delivery Protocol) — AppleTalk-протокол
транспортировки данных фирмы Apple.
2.7. Предоставление сетевых услуг
81
Кроме особенностей, обусловленных выполняемыми функ-
циями, различия и особенности протоколов характеризуются их
ориентацией на работу в различных операционных системах
и с различными аппаратными платформами.
2.6. Принципы работы протоколов разных уровней
В ходе обмена данными по сети протоколы разных уровней
тесно взаимодействуют друг с другом. Протоколы более высоких
уровней используют возможности и сервисы протоколов нижних
уровней.
Приложения обмениваются информацией с помощью средств,
предоставляемых прикладными протоколами, которые в свою оче-
редь обеспечивают пересылку данных за счет использования соот-
ветствующих транспортных протоколов.
Транспортные протоколы осуществляют передачу данных,
используя услуги сетевых протоколов, отвечающих за управление
адресацией, маршрутизацию в сложных сетях, обеспечение на-
дежности передачи данных и т. д.
2.7. Предоставление сетевых услуг
Сетевая услуга или сетевой сервис — это процесс обслужива-
ния объектов сети, обычно связанный с распределенной обработ-
кой данных и информационным обменом. Объектами сети могут
быть пользователи, программы, операционные системы, функ-
циональные блоки, вычислительные процессы и т. д.
Примерами сетевых услуг являются следующие распростра-
ненные виды сервисов:
• хранение данных;
• поиск информации;
• почтовые услуги (например, электронная почта);
• передача сообщений и блоков данных между узлами сети;
• организация сеансов взаимодействия между прикладными
процессами.
Сетевой сервис определяет интерфейс между потребителем
и поставщиком сетевых услуг.
Потребителями сетевых услуг могут являться пользователи,
прикладные программы, другие объекты сети. Поставщиком се-
82
Глава 2. Организация сетевого взаимодействия
тевых услуг является сетевая служба — некая сетевая компонента,
совокупность средств, которые позволяют реализовать услугу ли-
бо набор услуг.
К таким средствам относятся:
• средства обеспечения общего доступа и пользования ло-
кальных ресурсов и услуг — серверная часть программного
обеспечения, реализующего сетевую службу;
• средства получения доступа и обеспечения использования
удаленных ресурсов и услуг — клиентская часть программ-
ного обеспечения, реализующего сетевую службу.
При этом серверная часть сетевой службы производит обра-
ботку и выполнение запросов, полученных от клиентской части
службы и касающихся использования или получения доступа
к сетевым ресурсам, с которыми данная сетевая служба связана.
Так, сетевая служба, организующая взаимодействие клиента
с удаленными файловыми системами, будет называться файло-
вой. Почтовая служба предоставляет пользователю доступ к ре-
сурсам и возможностям электронной почты. А сетевая служба пе-
чати позволяет производить печать с использованием удаленного
принтера.
Таким образом, серверная часть может предоставлять сетевые
услуги клиентской части при непосредственной инициативе этой
клиентской части.
Взаимодействия между клиентами и сервером осуществляется
посредством телекоммуникационных средств сетевой службы
и сети передачи данных, выполняющих формирование сообще-
ний запросов и ответов, разбиение этих сообщений при необхо-
димости на отдельные блоки данных, обеспечение адресации,
маршрутизации, надежной доставки этих сообщений и т. д. в со-
ответствии с правилами, которые определяются используемыми
коммуникационными протоколами.
Обычно сетевая служба располагается на прикладном уровне
модели OSI, т. е. выполняет его функции, иногда может занимать
и уровень представления. При этом сетевая служба, используя
средства нижележащих уровней, не зависит от типа используемой
коммуникационной сети.
Таким образом, сетевая служба зачастую является платфор-
мой для тех или иных прикладных процессов.
2.8. Адресация в сетях
83
По степени интеграции сетевой службы в операционную сис-
тему различают следующие виды программной реализации сете-
вой службы:
• высокая степень интеграции — сетевая служба является ча-
стью операционной системы;
• средняя степень интеграции — сетевая служба представляет
собой надстройку над операционной системой;
• низкая степень интеграции — сетевая служба является само-
стоятельным программным продуктом.
2.8. Адресация в сетях
При объединении в сеть трех и более узлов возникает пробле-
ма идентификации конкретного узла, которому предназначены
пересылаемые данные. Другими словами, возникает проблема ад-
ресации узлов компьютерной сети.
На практике адресация производится не для самих узлов сети,
а для их сетевых интерфейсов, т. е. наборов средств и правил, по-
зволяющих осуществлять обмен информацией. Это объясняется
тем, что один узел сети может иметь несколько сетевых интер-
фейсов, например в сети, имеющей физическую топологию коль-
цо, каждому узлу необходимо минимум два сетевых интерфейса,
связывающих его с его соседями.
Существует множество систем адресации и, соответственно,
множество форматов представления адресов. Например, адрес
может иметь вид числовой или символьной последовательности.
Множество всех допустимых адресов в какой-либо системе
адресации называется адресным пространством. Структура адрес-
ного пространства может быть линейной, или как ее еще
называют — плоской, и иерархической.
2.8.1. Адресное пространство с плоской структурой
Примером плоского адреса является МАС-адрес. МАС-адрес
или физический адрес — уникальный идентификатор, однознач-
но определяющий каждый сетевой интерфейс.
Поэтому, чтобы избежать проблем, связанных с дублирова-
нием физических адресов на нескольких компьютерах, и тем
самым с нарушением корректной работы системы адресации,
84
Глава 2. Организация сетевого взаимодействия
МАС-адреса фиксируют в оборудовании сетевых интерфейсов.
При этом этот адрес не повторится нигде в мире, поскольку за
распределением диапазонов физических адресов для сетевого
оборудования следит институт IEEE.
Соответственно, при замене вышедшего из строя сетевого
оборудования, например сетевого адаптера компьютера, физиче-
ский адрес этого компьютера поменяется.
МАС-адрес представляет собой двоичное число длиной
48 бит. Для простоты восприятия и работы с ними МАС-адреса
обычно записываются в виде 12 цифр в шестнадцатеричной сис-
теме счисления, попарно разделенных дефисами, например
00-C0-DF-11-47-9F. При этом первые шесть цифр определяют
производителя сетевого устройства, а оставшиеся шесть цифр
идентифицируют само устройство, выпущенное этим производи-
телем.
МАС-адреса — это адреса подуровня управления доступом
к среде передачи (МАС — Media Access Control), которые лежат
в основе работы протоколов физического уровня.
При взаимодействии по сети, если компьютер получает пакет,
имеющий физический адрес, отличный от адреса компьютера, то
полученный пакет отбрасывается сетевым интерфейсом на ка-
нальном уровне, и остальная часть стека протоколов его не обра-
батывает.
При совпадении адресов пакет принимается и передается на
более высокие уровни, где обрабатывается в соответствии со сво-
им назначением.
Однако существуют специально зарезервированные адре-
са, например широковещательный МАС-адрес, имеющий
вид FF-FF-FF-FF-FF-FF, т. е. состоящий из одних двоичных
единиц.
Широковещательные пакеты обрабатываются несколько ина-
че, нежели обычные, поскольку обычно предназначены для всех
компьютеров. Однако зачастую на такой пакет должен ответить
только один компьютер или ограниченный набор компьютеров,
и пока пакет до конца не обработан, практически невозможно
определить, кому именно он предназначен. Поэтому, если компь-
ютер получает пакет с адресом, состоящим из одних двоичных
единиц, то такой пакет направляется вверх по стеку протоколов
для обработки и выяснения адресата. Поэтому при широковеща-
тельной рассылке данных пакет получают все компьютеры, а от-
2.8. Адресация в сетях
85
вечает только тот из них, для кого предназначено полученное со-
общение. Остальные компьютеры отбрасывают такой пакет после
его обработки и выяснения, что он предназначен не для них.
2.8.2. Адресное пространство с иерархической структурой
Примером иерархических адресов служат сетевые IP-адреса,
которые использует при своей работе протокол IP стека TCP/IP.
Поскольку протокол IP относится к сетевому уровню, то и IP-ад-
реса часто называют сетевыми адресами.
IP-адрес представляет собой двоичное число, имеющее длину
32 бита. Для удобства чтения и записи адреса он обычно пред-
ставляется в виде четырех разделенных точками десятичных чи-
сел, например 193.226.17.137 или 127.0.0.1. При этом каждое из
четырех десятичных чисел соответствует числу, которое можно
записать в двоичной системе счисления, используя восемь бит.
В этом случае максимальным окажется число, состоящее из
восьми двоичных единиц: 11111111, что при пересчете в десятич-
ную систему счисления будет равно 255. Таким образом, каждое
из четырех чисел IP-адреса при десятичном представлении не мо-
жет быть больше 255.
При адресации, имеющей иерархическую структуру, адресное
пространство состоит из вложенных друг в друга подгрупп адре-
сов, последовательно уточняющих конечного адресата. Приме-
ром могут служить почтовые адреса, в которых последовательно
указывается местонахождение адресата, например: город Москва,
проспект Мира, дом 26г, квартира 151.
Такая организация адресного пространства зачастую позволя-
ет экономить время поиска того или иного адресата, а также сред-
ства для хранения всей адресной информации потому, что иерар-
хическая структура позволяет хранить только ту часть адреса,
которая соответствует уровню иерархии, на котором находится
компьютер.
IP-адреса являются иерархическими, так как состоят из двух
частей, первая из которых идентифицирует номер сети, в которой
находится некий узел, а вторая часть — непосредственно сам узел.
Адрес сети может быть выбран администратором произволь-
но, однако если сеть должна работать как составная часть Ин-
тернета, то адрес сети должен быть назначен централизованно
86
Глава 2. Организация сетевого взаимодействия
Таблица 2.6. Классы IP-адресов
Класс Диапазон значений первого байта Максимальное количество сетей Максимальное количество узлов в сети
А 1-126 126 16 777 214
В 128-191 16 382 65 534
С 192-223 2 097 150 254
D 224-239 — 228
Е 240-247 — 227
некоммерческой организацией регистрации глобальных адресов
в Интернете (Internet Corporation for Assigned Names and Num-
bers - ICANN).
Например, провайдеры услуг Интернет для подключения
к сети своих абонентов получают диапазоны адресов у подразде-
лений ICANN.
Номер узла в протоколе IP назначается независимо от локаль-
ного адреса узла. Деление IP-адреса на поле номера сети и номера
узла — гибкое, и граница между этими полями может устанавли-
ваться произвольно. При этом IP-адрес идентифицирует не от-
дельный узел сети, а отдельный сетевой интерфейс; поскольку
любой узел может одновременно входить в несколько сетей, то
в этом случае он должен иметь несколько IP-адресов, по числу се-
тевых связей.
Существует пять классов IP-адресов, различающихся количе-
ством бит, отведенных под идентификацию номера сети и номера
узла (табл. 2.6). Определить, к какому классу относится 1Р-адрес,
можно по значению первого байта адреса. Обычно сеть, имею-
щую адреса какого-либо класса, называют сетью этого же класса,
т. е., например, сеть с IP-адресами класса В можно назвать сетью
класса В.
Адреса класса А предназначены для использования в крупных
сетях масштаба региона или страны, число таких сетей сильно ог-
раничено. Сети класса В имеют средние размеры и обычно ис-
пользуются в университетах и крупных компаниях. Адреса класса
С используются в малых сетях, имеющих небольшое количество
узлов. IP-адреса класса D используют для обращения к группам
2.8. Адресация в сетях
87
компьютеров. Адреса класса Е зарезервированы для будущего ис-
пользования.
Кроме того, существует набор специально зарезервированных
IP-адресов:
• адрес состоит только из двоичных нулей — обозначает тот
же самый узел сети, который сгенерировал пакет, содержа-
щий такой 1Р-адрес;
• адрес типа «Номер сети. Все нули» обозначает данную сеть,
т. е. ту же сеть, в которой находится компьютер, сгенериро-
вавший пакет с этим адресом;
• адрес типа «Все нули. Номер узла» обозначает узел, принад-
лежащий той же сети, что и узел, сгенерировавший пакет;
• адрес состоит только из двоичных единиц — обозначает, что
пакет с таким адресом предназначен всем узлам той же сети,
что и источник пакета (при этом такой пакет не выйдет за
пределы данной сети, поэтому такая рассылка называется
ограниченным широковещанием);
• 127.0.0.1 — пакет с таким адресом не передается в сеть,
а возвращается верхним уровням стека протоколов, как
только что принятый; IP-адреса, первый байт которых име-
ет значение, равное 127, используются для тестирования
программного обеспечения и взаимодействия сетевых про-
цессов в пределах отдельного узла.
Разбиение IP-адресов на классы приводит к достаточно жест-
кой и не всегда рациональной системе адресации.
Использование масок IP-адресов позволяет сделать систему
адресации более гибкой за счет возможности разбивать одну сеть
на несколько подсетей, разделяя адресное пространство на непе-
ресекающиеся друг с другом диапазоны.
Для этого используется маска, которой «маскируется» часть
IP-адреса, используемая для получения номера подсети. Там, где
значение бита маски равно единице, адресация узлов запрещена,
там, где значение равно нулю, — разрешена. Причем «маскиров-
ка» происходит от старшего бита к младшему.
Для сетей, имеющих адреса класса А, маска будет иметь вид:
255.0.0.0. При этом первые 8 бит маски соответствуют номеру се-
ти. Поскольку использование этих битов при адресации естест-
венно невозможно, их значения равны единицам. Для сетей клас-
са В маска будет иметь вид: 255.255.0.0, а для сетей класса С —
255.255.255.0.
88
Глава 2. Организация сетевого взаимодействия
Таблица 2.7. Разбиение сети класса С на подсети
Количество адресов Маска
Десятичное представление Шестнадцатеричное представление Значения последних 8 бит
256 255.255.255.0 FFFFFF00 00000000
128 255.255.255.128 FFFFFF80 10000000
64 255.255.255.192 FFFFFFC0 11000000
32 255.255.255.224 FFFFFFE0 11100000
16 255.255.255.240 FFFFFFF0 11110000
8 255.255.255.248 FFFFFF8 11111000
4 255.255.255.252 FFFFFFC 11111100
При разбиении сети на подсети с помощью маски происходит
установка значений, равных единице, для битов, равных нулю.
Причем такая установка производится слева направо, т. е. от
старшего бита к младшему, поэтому, по сути, происходит деление
адресного пространства сети пополам.
Например (табл. 2.7), если для наглядности записать маску се-
ти класса С в шестнадцатеричном виде, получится FFFFFF00. Ес-
ли значение первого слева бита, равного нулю, установить равным
единице, то получится маска FFFFFF80, которая позволяет выде-
лить сеть на 128 IP-адресов. Следующая подсеть будет определять-
ся маской FFFFFFC0 или в десятичном виде 255.255.255.192.
Такая подсеть имеет всего 64 IP-адреса.
Таким образом, при разбиении сети на подсети нельзя выде-
лить в одну логическую сеть более половины исходной сети.
Для возможности обмениваться информацией по сети каждо-
му сетевому интерфейсу узла необходим свой IP-адрес. Назначе-
ние IP-адресов интерфейсам может производиться как вручную,
так и автоматически.
Ручное назначение адресов обычно производится в процессе
настройки конфигурации работы сетевого интерфейса, при этом
новые назначаемые адреса не должны повторять уже используе-
мые IP-адреса в сети. Естественно, что при больших размерах се-
тей такая настройка начинает вызывать ряд проблем.
2.8. Адресация в сетях
89
Автоматическое назначение IP-адресов упрощает процесс
определения адресов для каждого сетевого интерфейса и освобо-
ждает администратора, занимающегося настройкой сетевого
взаимодействия, от рутинной работы.
Для автоматического назначения IP-адресов используется
вспомогательный протокол динамической конфигурации узлов
DHCP (Dynamic Host Configuration Protocol).
DHCP предназначен для автоматической настройки парамет-
ров стека TCP/IP рабочей станции. В момент загрузки операцион-
ной системы рабочая станция посылает широковещательный за-
прос параметров своей конфигурации, получив который, сервер
DHCP посылает в ответ сведения, содержащие IP-адрес этой рабо-
чей станции, а также прочую информацию, необходимую при на-
стройке сетевого взаимодействия. При этом предполагается, что
клиент DHCP, т. е. рабочая станция, пославшая широковещатель-
ный запрос, и сервер DHCP находятся в одной локальной сети.
Автоматическое назначение адресов может работать, исполь-
зуя различные способы распределения адресов по интерфейсам:
• статический;
• динамический.
При статическом способе сервер DHCP в ответ на запрос ра-
бочей станции посылает ей произвольный IP-адрес, выбранный
из диапазона наличных адресов. Диапазон адресов задается при
настройке сервера DHCP. Выбранный для рабочей станции адрес
дается ей в пользование на неограниченный срок, при этом при
последующих обращениях к серверу станция будет получать этот
же 1Р-адрес.
При динамическом распределении адресов адрес выдается для
использования на ограниченное время, называемое сроком арен-
ды. После истечения срока аренды данный IP-адрес может быть
назначен другой рабочей станции. Поскольку при таком распреде-
лении один и тот же адрес может использоваться несколькими ин-
терфейсами, а также за счет того, что обычно одновременно рабо-
тают далеко не все зарегистрированные в сети рабочие станции,
появляется возможность экономить IP-адреса, выделяя их под
конкретные нужды, а не под простаивающие узлы.
Независимо от используемого метода применение DHCP по-
зволяет избежать конфигурирования стека TCP/IP на каждом от-
дельном узле сети и проводить весьма гибкую, централизованную
политику администрирования сети.
90
Глава 2. Организация сетевого взаимодействия
Чтобы определить физический адрес узла, указанного сете-
вым адресом, используется протокол разрешения адресов ARP
(Address Resolution Protocol). В локальных сетях для определения
нужного адреса ARP использует рассылку широковещательных
запросов. Протокол разрешения адресов формирует запрос, ука-
зывая в нем сетевой адрес, для которого нужно определить соот-
ветствующий физический адрес узла, инкапсулирует этот запрос
в кадр протокола канального уровня, используемого в данной
сети, и производит широковещательную рассылку полученного
кадра.
Узел сети, получивший такой запрос, сравнивает указанный
в запросе сетевой адрес со своим сетевым адресом. В случае, если
адреса совпали, узел формирует ответ, содержащий оба адреса
узла — физический и сетевой — и отправляет его отправителю ис-
ходного ARP-запроса, на который передается ответ.
Пакеты, содержащие ARP-запросы и ARP-ответы, имеют оди-
наковый формат.
Для решения обратной задачи, т. е. определение IP-адреса по
известному физическому адресу, используется протокол обратно-
го разрешения адресов RARP (Reverse Address Resolution Proto-
col). Необходимость использования протокола обратного разре-
шения адресов обычно обусловливается использованием бездис-
ковых рабочих станций, загрузка операционной системы которых
производится с единого сервера.
Применение RARP возможно при наличии в сети специаль-
ного сервера, который отвечает на RARP-запросы, основываясь
на информации, хранящейся в его ARP-таблице и позволяющей
провести соответствие физических адресов сетевым (табл. 2.8).
В ответ на запрос такой сервер отсылает пакет, содержащий
оба адреса запрашивающего узла — сетевой и физический.
Таблица 2.8. Пример ARP-таблицы
IP-адрес Ethemet-адрес
101.0.10.3 08:00:F0:00:2F:Dl
101.0.10.10 08:00:5А: 19:ВА: 15
101.0.10.17 08:00:11:56:А4:76
2.8. Адресация в сетях
91
0 7 15
Tип сети
Тип протокола
Длина физического адреса Длина сетевого адреса
Операция
Физический адрес отправителя
Сетевой адрес отправителя
Искомый физический адрес
Искомый сетевой адрес
Рис. 2.17. Формат пакета ARP
Хотя механизм работы ARP и RARP существенно различает-
ся, они используют для передачи запросов и ответов на них паке-
ты, имеющие одинаковый формат. Формат такого пакета зависит
от длины физических адресов, применяемых в локальной сети,
где производится разрешение адресов. Например, физический
адрес, используемый в сетях Ethernet, имеет длину, равную 6 бай-
там, поэтому пакет разрешения адресов будет иметь вид, приве-
денный на рис. 2.17, где:
• тип сети — содержит код, определяющий тип сети, в кото-
рой используется протокол (для сетей Ethernet это поле име-
ет значение 1);
• тип протокола — содержит код, определяющий протокол,
который собственно и производит разрешение адреса, поль-
зуясь средствами ARP и RARP;
• длина физического адреса — указывает длину соответствую-
щего адреса (для сетей Ethernet — 6 байт);
• длина сетевого адреса (длина IP-адреса — 4 байта);
• операция — содержит код, определяющий тип данного па-
кета;
• физический адрес отправителя;
• сетевой адрес отправителя;
• искомый физический адрес;
• искомый сетевой адрес.
92
Глава 2. Организация сетевого взаимодействия
Поле «операция» может иметь следующие значения:
• 1 — ARP-запрос;
• 2 — ARP-ответ;
• 3 — RARP-запрос;
• 4 — RARP-ответ.
2.8.3. Адреса в виде символьной последовательности
Кроме числовых схем адресации, также применяются схемы
адресации, использующие символьное представление адресов.
Символьные адреса гораздо проще запоминать, этому способст-
вует еще и тот факт, что обычно они несут некую смысловую на-
грузку. Поэтому такие адреса удобны там, где необходимо обеспе-
чить интерфейс человека с сетевой программой.
Однако символьные адреса имеют переменный формат доста-
точно большой максимально возможной длины, поэтому хране-
ние и передача по сети таких адресов вызывают ряд сложностей
и являются не очень экономичными.
В сети Интернет используется IP-адресация, но поскольку
пользователям приложений удобней работать с символьными ад-
ресами, то на прикладных уровнях используется символьная сис-
тема адресации, каждый адрес которой является мнемоническим
обозначением некоего IP-адреса.
Раньше символьная адресация обеспечивалась средствами
операционных систем, хранившими таблицы соответствия фи-
зического адреса узла сети и его символьного адреса. Однако
такие системы изначально разрабатывались для работы в не-
больших локальных сетях. При этом имена узлов имели линей-
ную структуру, т. е. не разделялись на несколько частей. Чтобы
определить физический адрес узла, соответствующий некоторо-
му символьному имени, проводился опрос всех узлов локальной
сети, осуществляемый посредством механизма широковеща-
тельных запросов.
Но в больших сетях или в сетях, объединяющих несколько
подсетей, более эффективно применение иерархической системы
адресации, и, соответственно, адресов, состоящих из нескольких
«вложенных» друг в друга частей.
Примером такой системы адресации может служить доменная
система имен (Domain Name System), применяемая в Интернете,
2.8. Адресация в сетях
93
search
WWW
Домены
третьего <'
уровня
WWW------
Имена............
Рис. 2.18. Система иерархии доменов
хостов
имеющая иерархическую древовидную структуру и допускающая
большую степень вложенности, т. е. большое количество иерар-
хических подуровней.
Доменное имя может состоять из нескольких частей, отделен-
ных друг от друга точками, например news.yandex.ru. Каждая из
таких частей называется доменом.
Под доменом можно подразумевать некую совокупность ком-
пьютеров, имеющих какие-либо схожие свойства.
Доменное имя записывается так, что слева оказывается имя
узла, входящего в домен, имеющий самый низкий уровень в ие-
рархии, а справа — домен, имеющий самый высокий иерархиче-
ский уровень (рис. 2.18). Поэтому крайний справа домен называ-
ется доменом верхнего или первого уровня. Следующий слева до-
мен, отделенный точкой, является дочерним доменом по
отношению к домену первого уровня, т. е. входит в него как его
составная часть. Этот домен называется доменом второго уровня.
Домены, которые являются дочерними для домена второго уров-
ня, называются доменами третьего уровня и т. д.
В адресе news.yandex.ru доменом первого уровня является до-
мен «ги», доменом второго уровня — «yandex», слово «news» явля-
ется именем хоста.
Термин «хост» (от англ, host) используют в качестве синонима
термина «узел сети», обычно говоря о сетях, объединенных на ос-
нове использования стека TCP/IP.
* ' Названия доменов первого уровня назначаются централизо-
ванно, в соответствии с международным стандартом. Имена до-
94
Глава 2. Организация сетевого взаимодействия
Таблица 2.9. Примеры доменов первого уровня
Домены первого уровня
Общие1 Региональные2
Имя Значение Имя Значение
Сот Коммерческие Ru Российская Федерация
Edu Образовательные Ua Украина
Gov Правительственные Us США
Int Международные Jp Япония
Mil Военные De Германия
Info Информационные GB Великобритания
Net Сетевые Au Австралия
Org Некоммерческие Za Южная Африка
1 Предназначены для обозначения типов организаций.
2 Предназначены для обозначения стран и регионов.
менов первого уровня могут обозначать страны или типы органи-
заций и обычно представляют собой двух- или трехбуквенные аб-
бревиатуры (табл. 2.9).
Доменом второго уровня обычно является псевдоним органи-
зации, которой принадлежит корпоративная сеть или хост-ком-
пьютер, для адресации которых используется этот домен.
Домены третьего и последующих уровней являются частью
доменов второго уровня, и на практике обычно представляют не-
кие подсети либо дочерние хосты, которые продаются или бес-
платно передаются в использование другим организациям или
физическим лицам. Очень часто на таких хостах размещаются до-
машние страницы пользователей Интернета.
Установление соответствия доменных имен сетевым адресам
осуществляется централизованно с помощью сервиса DNS.
Сервис DNS — система обеспечения преобразования симво-
лических имен и псевдонимов локальных сетей и узлов в сети
Интернет в IP-адреса и обратно.
Принцип работы сервиса DNS основан на использовании так
называемых DNS-серверов. Каждый домен должен иметь свой
2.9. Работа протоколов стека TCP/IP
95
DNS-сервер, который хранит таблицу соответствий доменных
имен и IP-адресов данного домена, а также доменов, являющихся
для него дочерними. В таблице также присутствует запись, относя-
щаяся к родительскому домену. Таким образом, любой узел может
получить сведения об искомом IP-адресе любого узла сети. Для
этого узел последовательно обращается ко всем DNS-серверам,
находящимся выше по иерархии, пока не дойдет до сервера, рас-
положенного в домене, общем для данного узла, осуществляющего
поиск, и искомого узла. Далее происходит последовательное обра-
щение к серверам, находящимся ниже по доменной иерархии, по-
ка домен, содержащий искомый узел, не будет найден.
2.9. Работа протоколов стека TCP/IP
2.9.1. Межсетевой протокол IP
Межсетевой протокол (Internet Protocol — IP) был создан для
использования в сложных сетях, объединенных из разнородных
подсетей на основе коммутации пересылаемых пакетов.
Данный протокол описывается стандартом RFC 791 (Request
for Comments — запрос на комментарии). Согласно этому стан-
дарту, межсетевой протокол имеет специально ограниченный на-
бор задач, обеспечивающих функции, необходимые для передачи
битового пакета, от отправителя к получателю через объединен-
ную систему компьютерных сетей. Таким образом, данный про-
токол не имеет механизмов для увеличения достоверности пере-
данных данных, управления потоками данных, синхронизации
или прочих служб, обычно применяемых в протоколах передачи
от хоста к хосту.
Синонимом «пакета» согласно стандарту на этот протокол яв-
ляется термин «межсетевая дейтаграмма» (internet datagram).
Функция или цель межсетевого протокола состоит в передаче
дейтаграмм через ряд взаимосвязанных сетей. Это осуществляет-
ся пересылкой дейтаграмм между IP-модулями, располагающи-
мися на хостах, до тех пор, пока дейтаграммы не попадут к своему
адресату. Модулем называется реализация, обычно программная,
протокола или какой-либо процедуры.
< Перенаправление дейтаграмм с одного IP-модуля на другой
через локальные сети осуществляется на основе интерпретации
96 Глава 2. Организация сетевого взаимодействия
Формат дейтаграммы
0 7 15 23 I 31
Версия Длина Тип сервиса Общая длина
Идентификатор дейтаграммы Флаги Смещение фрагмента
Время жизни Протокол Контрольная сумма заголовка
IP-адрес отправителя
IP-адрес получателя
Опции (если есть) Заполнение
Рис. 2.19. Формат пользовательской дейтаграммы
сетевых, т. е. IP-адресов, или, другими словами, на основе ото-
бражения сетевых адресов на адреса локальной сети, т. е. физиче-
ской сети. Выбор пути передачи дейтаграммы называется ее мар-
шрутизацией.
При передаче информации с одного IP-модуля на другой дей-
таграммы (рис. 2,19) могут нуждаться в прохождении через сети,
для которых максимально допустимый размер пакета меньше,
чем размер дейтаграммы. Для решения этой проблемы IP исполь-
зует механизм фрагментации, т. е. разбиение крупного пакета или
дейтаграммы на более мелкие блоки, фрагменты.
Каждая дейтаграмма состоит из заголовка и поля данных.
При фрагментации (рис. 2.20) блоки исходной дейтаграммы
снабжаются заголовками, практически полностью дублирующи-
ми заголовок исходной дейтаграммы и, соответственно, имеющи-
ми точно такой же формат.
Заголовок дейтаграммы содержит следующие поля:
• версия — указывает версию межсетевого протокола, уста-
новленного на хосте, сгенерировавшем дейтаграмму; по су-
ти, определяет формат заголовка дейтаграммы;
• длина — содержит длину заголовка, выраженную в 32-бито-
вых словах; минимальный размер корректно составленного
заголовка равен пяти;
• тип сервиса — определяет тип и качество обслуживания, ко-
торые требуются дейтаграмме при ее передаче;
• общая длина — общая длина дейтаграммы, включающая дли-
ну заголовка и длину поля данных и выраженная в байтах;
2.9. Работа протоколов стека TCP/IP
97
Рис. 2.20. Фрагментация дейтаграммы
• идентификатор дейтаграммы — устанавливается отправите-
лем дейтаграммы для того, чтобы обеспечить возможность
сборки фрагментов какой-либо дейтаграммы;
• флаги — поле, состоящее из трех бит; при этом первый бит
зарезервирован и всегда равен нулю, второй бит в случае ус-
тановки его в единицу запрещает фрагментацию, третий
бит, равный единице, сигнализирует, что данная дейтаграм-
ма является промежуточным фрагментом, после которого
фрагменты ожидаются еще;
• смещение фрагмента — используется для сборки фрагмен-
тов дейтаграммы — данное поле содержит значение смеще-
ния поля данных дейтаграммы от начала поля данных ис-
ходного нефрагментированного пакета;
• время жизни — характеризует максимальный интервал
времени, в течение которого дейтаграмма может нахо-
диться в сети, если значение этого поля равно нулю, то
дейтаграмма должна быть уничтожена; поле применяется
для ограничения времени существования дейтаграмм,
особенно неспособных по тем или иным причинам до-
стигнуть получателя;
• протокол — идентифицирует протокол вышележащего
уровня, которому принадлежит информация, помещенная
98
Глава 2. Организация сетевого взаимодействия
в поле данных дейтаграммы (например, 1 соответствует
ICMP, 17 - UDP);
• контрольная сумма заголовка — рассчитывается и обновля-
ется после каждого изменения, внесенного в заголовок, на-
пример, после уменьшения времени жизни дейтаграммы;
• IP-адрес отправителя;
• IP-адрес получателя;
• опции — поле является необязательным и не имеет фикси-
рованной длины; используется обычно при тестировании
и настройке работы сети;
• выравнивание — состоит из нулей и используется для запол-
нения заголовка дейтаграммы до длины, кратной 32 битам,
поскольку поле «параметры» может иметь произвольную
длину.
Тип сервиса обработки дейтаграммы
Поле «тип сервиса» (рис. 2.21) определяет характеристики об-
служивания дейтаграммы при ее передаче по некой конкретной
сети и основывается как на приоритете любой передаваемой дей-
таграммы, так и на качестве ее передачи, определяемых четырьмя
под полями:
• приоритет — характеризует приоритет дейтаграммы (от 0 —
обычный приоритет до 7 — управление сетью);
• параметр задержки:
О — нормальная;
1 — малая;
• параметр пропускной способности:
О — нормальная;
1 — высокая;
• параметр достоверности передаваемых данных:
О — обычная;
1 — высокая.
0 1 1 2 3 4 5 I 6 I 7
Приоритет Задержка Пропускная способность Достоверность Не используется
Рис. 2.21. Формат поля «тип сервиса»
2.9. Работа протоколов стека TCP/IP
99
Опции дейтаграммы
Поле «опции» (рис. 2.22) позволяет для каждой дейтаграммы
задать некий набор опций, учитываемых при передаче этой дей-
таграммы по сети. Запись опции может включать в себя тип, дли-
ну и данные опции.
0 1 1 2 3 1 4 1 5 1 6 1 7
Признак копирования Класс опции Номер опции
Рис. 2.22. Формат записи о типе опции
Таблица 2.10. Опции межсетевого протокола
Класс Номер Длина Описание
0 0 — Конец списка опций. Используется для обозна- чения окончания записи опций в том случае, ес- ли конец списка опций не совпал с окончанием заголовка дейтаграммы
0 1 — Нет операции. Используется для дополнения длины какой-либо опции в списке опций до кратной 32 битам
° 2 11 Безопасность. Позволяет управлять степенью доступа к той или иной информации различных групп пользователей
0 3 Переменная Маршрутизация по источнику, позволяющая для достижения следующего адреса в заданном ис- точником маршруте использовать любые проме- жуточные маршруты
0 7 Переменная Запись маршрута. Используется для отслежива- ния проходимого дейтаграммой маршрута
0 8 4 Идентификатор маршрута. Используется для поддержки идентификации потока пересылае- мых данных
0 9 Переменная Строгая маршрутизация по источнику. Дейта- грамма должна следовать строго по тому маршру- ту, который был задан ее отправителем
2 4 Переменная Временная метка. Отметка о текущем времени
100
Глава 2. Организация сетевого взаимодействия
0 7 15 23 | 31
Код Длина Указатель
Первый IP-адрес
п-й IP-адрес
Рис. 2.23. Формат опции записи маршрута
Запись о типе опции состоит из трех полей:
• признак копирования — если равен единице, то данная оп-
ция копируется во все фрагменты при фрагментации дейта-
граммы;
• класс опции — содержит значение класса опции:
О — управление;
1,3 — зарезервирован;
2 — тестирование и измерения;
• номер опции — указывает номер, непосредственный иден-
тификатор опции.
В стандарте на межсетевой протокол определены опции, при-
веденные в табл. 2.10:
Например, опция записи маршрута будет иметь следующие
поля (рис. 2.23):
• код — содержит класс и номер опции;
• длина — общая длина опции в дейтаграмме;
• указатель — определяет смещение внутри опции, куда про-
межуточный для дейтаграммы узел должен добавить свой
IP-адрес;
• первый 1Р-адрес;
• ...
• п-й 1Р-адрес.
2.9.2. Протокол межсетевых управляющих сообщений ICMP
Протокол ICMP (Internet Control Message Protocol) исполь-
зуется для обеспечения обратной связи между отправителем
IP-дейтаграмм, их получателем, а также между коммуникацион-
ным оборудованием, передающим эти дейтаграммы по сети.
2.9. Работа протоколов стека TCP/IP
101
Спецификация протокола межсетевых управляющих сооб-
щений и дополнения к ней приводятся в стандартах RFC 792,
RFC 1256 и RFC 950.
Согласно стандарту RFC 792, межсетевой протокол использу-
ется для обеспечения передачи дейтаграмм между различными
хостами, работающими в системе объединенных между собой се-
тей. Такая система называется Catenet.
Catenet — составная сеть, в которой конечные узлы подклю-
чены к сетям с различными характеристиками, а эти сети соеди-
нены между собой специальными устройствами. Устройства,
посредством которых осуществляется соединение сетей, называ-
ются шлюзами (gateway). Примером сети Catenet является гло-
бальная сеть Интернет.
Межсетевой протокол не гарантирует доставку дейтаграмм.
В случаях их потери или порчи отправитель так и не узнает, до-
шла ли переданная им информация до получателя. ICMP позво-
ляет решить эту проблему, осуществляя обмен служебной инфор-
мацией между шлюзом или хостом-получателем и хостом-отпра-
вителем данных.
При этом протокол межсетевых управляющих сообщений для
передачи собственных сообщений использует в качестве транс-
портного средства дейтаграммы межсетевого протокола, подобно
тому, как это делают протоколы более высоких уровней. При
этом ICMP принадлежит тому же уровню модели, что и IP, и даже
более — является своего рода его составной частью.
При этом целью использования управляющих сообщений не
является обеспечение абсолютной надежности передачи инфор-
мации, их задача, как уже говорилось, — обеспечить обратную
связь между хостами и коммуникационным оборудованием сети.
Часто сообщения ICMP отправляются при возникновении
каких-либо проблем, связанных с обработкой дейтаграммы, на-
пример, при обнаружении ошибок передачи дейтаграммы, или в
случае, когда дейтаграмма по каким-либо причинам не может
достичь своего адресата. Поскольку сообщения ICMP передаются
в дейтаграммах межсетевого протокола, то чтобы в случае ошибки
избежать передачи по сети лавинообразного потока сообщений,
управляющие сообщения о дейтаграммах, содержащих управляю-
щие сообщения, не передаются.
Получателем сообщений ICMP является программное обес-
печение модуля IP на хосте назначения. Другими словами, полу-
102
Глава 2. Организация сетевого взаимодействия
Рис. 2.24. Инкапсуляция сообщений ICMP
ченные управляющие сообщения в первую очередь обрабаты-
ваются модулем IP, а точнее, его частью, отвечающей за ICMP.
Если ошибка, в результате которой было отправлено данное
управляющее сообщение, была вызвана работой протокола более
высокого уровня или прикладной программы, то они получат об
этом уведомление. Таким образом, ICMP обеспечивает взаимо-
действие между модулями межсетевого протокола, принадлежа-
щими разным машинам.
При передаче сообщения ICMP инкапсулируются в IP-дейта-
граммы (рис. 2.24), которые, в свою очередь, помещаются в поля
данных кадров канального уровня.
Формат управляющих сообщений ICMP различается в зави-
симости от задач, возложенных на эти сообщения, тем не менее
все сообщения имеют одинаковый заголовок, состоящий из трех
полей:
• тип — указывает тип управляющего сообщения;
• код — указывает код сообщения, относящегося к данному
типу;
• контрольная сумма — рассчитывается для всего ICMP-сооб-
щения целиком.
Сообщения ICMP могут быть следующих типов (табл. 2.11).
В зависимости от типа сообщения формат поля данных
ICMP-пакета изменяется. Однако ICMP-пакеты, содержащие со-
общение об ошибке, всегда включают заголовок и первые 64 бита
дейтаграммы, эту ошибку вызвавшую. Это позволяет не только
узнать о неудавшейся передаче данных, но определить протоколы
и пользовательские приложения, использующие для передачи
своих данных дейтаграмму, вызвавшую ошибку.
2.9. Работа протоколов стека TCP/IP
103
Таблица 2.11. Типы сообщений ICMP
Значение поля «тип» Тип сообщения
0 Ответ на эхо
3 Адресат недостижим
4 Приостановка источника
5 Перенаправление дейтаграммы
8 Запрос эха
9 Объявление маршрутизатора
10 Запрос маршрутизатора
11 Превышено время жизни дейтаграммы
12 Проблема параметра заголовка дейтаграммы
13 Запрос временной отметки
14 Ответ для временной метки
15 Запрос информации
16 Ответ на запрос информации
17 Запрос адресной маски
18 Ответ на запрос адресной маски
Сообщение о недостижимости адресата
Сообщения подобного типа генерируются шлюзом и отправ-
ляются на хост-отправитель в случае, когда посланная этим хос-
том дейтаграмма не может достигнуть пункта своего назначения,
например из-за того, что рабочая станция, являющаяся адреса-
том, в настоящее время выключена или потому, что при отправке
дейтаграммы был указан несуществующий адрес. Другим случаем
появления управляющих сообщений данного типа является по-
пытка передать дейтаграмму, не подлежащую дефрагментации,
через сеть, для прохода через которую дейтаграмма слишком ве-
лика и должна быть разбита на более мелкие части.
104
Глава 2. Организация сетевого взаимодействия
0 7 15 23 3,
Тип Код Контрольная сумма
Нули
Рис. 2.25. Формат ICMP-сообщения о недостижимости адресата
Сообщение о недостижимости адресата состоит из следующих
полей (рис. 2.25):
• заголовок;
• пустое поле — 32 бита, следующие за заголовком, не ис-
пользуются (заполняются нулями);
• данные исходной дейтаграммы — данное поле содержит за-
головок и первые 64 бита исходной дейтаграммы, в резуль-
тате обработки которой было сгенерировано данное
ICMP-сообщение.
Поле «код» заголовка сообщения данного типа содержит код,
определяющий причину возникновения ошибки (табл. 2.12).
Таблица 2.12. Коды причин недостижимости адресата
I Код Описание
0 Невозможно передать дейтаграмму в локальную сеть, где находится адресат
1 Невозможно передать дейтаграмму на хост-компьютер, являющийся адресатом
2 Нельзя воспользоваться указанным протоколом
3 Нельзя передать данные на указанный порт, т. е. конкретному пользовательскому приложению или сетевой службе
4 Для передачи дейтаграммы по сети требуется фрагментация, однако выставлен запрещающий ее флаг
5 Сбой в маршрутизации по источнику
6 Сеть назначения неизвестна
7 Хост-компьютер назначения неизвестен
8 Хост-компьютер источника изолирован (устарел, больше не используется)
2.9. Работа протоколов стека TCP/IP
105
Окончание табл. 2.12
Код Описание
9 Взаимодействие с сетью назначения административно запрещено
10 Взаимодействие с хостом назначения административно запрещено
11 Сеть недостижима из-за класса обслуживания
12 Хост недостижим из-за класса обслуживания
Шлюз может послать сообщения с кодами 0, 1, 4 и 5. Хост-по-
лучатель может послать сообщения только с кодами 2 и 3.
Ошибки, связанные с невозможностью достижения некой се-
ти, часто бывают результатом ошибок маршрутизации, а ошибки,
связанные с недостижимостью конкретных хостов — результатом
ошибок при передаче данных.
Сообщение приостановки источника
Различные хосты, а также различные сети обладают различ-
ными характеристиками, в той или иной мере влияющими на
скорость обработки потоков дейтаграмм. Сообщения данного ти-
па используются получателем дейтаграмм либо шлюзом, обеспе-
чивающим транспортировку этих дейтаграмм между сетями, для
того, чтобы снизить скорость пересылки данных отправителем.
Такие управляющие сообщения посылаются источнику дей-
таграмм в случае, когда шлюз не имеет места в буфере для поста-
новки дейтаграмм, полученных от него, в очередь на обработку
и отправление в очередную сеть, соответствующую маршруту.
Также сообщения приостановки источника посылаются и в слу-
чае, когда получатель попросту не успевает обрабатывать посту-
пающие к нему дейтаграммы. Таким образом, сообщение приос-
тановки источника является запросом для хоста-отправителя на
уменьшение скорости пересылки данных на адрес получателя
дейтаграмм.
Хост, получивший сообщение приостановки источника, т. е.,
собственно, источник дейтаграмм должен начать снижение ско-
рости передачи данных на адрес хоста, отправившего полученное
ICMP-сообщение. Делается это до тех пор, пока с этого хоста
не перестанут приходить повторные сообщения-запросы на при-
106
Глава 2. Организация сетевого взаимодействия
остановку. После этого скорость передачи данных можно посте-
пенно увеличивать, правда, до тех пор, пока сообщения приоста-
новки снова не начнут приходить.
Сообщение приостановки источника имеет точно такой же
формат, как и сообщение о недостижимости адресата.
Сообщение о перенаправлении дейтаграммы
Сообщение о перенаправлении (рис. 2.26) посылается шлю-
зом на хост в том случае, если шлюзу известно о существовании
более выгодного маршрута, нежели тот, что используется хостом
для передачи дейтаграмм.
Для дейтаграмм с опцией маршрутизации по источнику по-
добное ICMP-сообщение никогда послано не будет, даже если
шлюзам известен лучший маршрут, чем тот, по которому дейта-
грамма должна быть передана согласно опции.
0 7 15 23 31
Тип Код Контрольная сумма
Адрес шлюза
Данные исходной дейтаграммы
Рис. 2.26. Формат ICMP-сообщения о перенаправлении дейтаграммы
Формат сообщения о перенаправлении дейтаграммы имеет
следующий вид:
• заголовок;
• адрес шлюза — содержит IP-адрес шлюза, на который сле-
дует перенаправить дейтаграмму, чтобы она достигла своего
назначения по более выгодному пути;
• данные исходной дейтаграммы.
Сообщения запроса и ответа на эхо
У зел, получивший сообщение запроса эха (рис. 2.27), должен
послать в ответ сообщение, называемое ответом на эхо и содержа-
щее копию данных, присланных в запросе. Поэтому данные сооб-
щения обычно используются для тестирования соединения между
двумя узлами сети. Получение ответа на запрос эха, отправлен-
ный на некий узел, свидетельствует о достижимости этого узла,
2.9. Работа протоколов стека TCP/IP
107
0 7 15 23 | 31
Тип Код Контрольная сумма
Идентификатор Последовательный номер
Данные
Рис. 2.27. Формат ICMP-сообщения запроса и ответа на эхо
т. е. о работоспособности основных элементов транспортной сис-
темы, осуществляющей передачу данных от этого узла и обратно.
Сообщения запроса и ответа на эхо имеют одинаковую струк-
туру и состоят из следующих полей:
• заголовок;
• идентификатор;
• последовательный номер;
• данные — данное поле может содержать любые данные,
имеет переменную длину и является необязательным.
Поля «идентификатор» и «последовательный номер» исполь-
зуются для того, чтобы определить соответствующие друг другу
запросы и ответы.
Поле «тип» заголовка сообщения имеет значение, равное 8,
в случае, если это сообщение является запросом эха, и равное О,
если это ответ на него.
Обмен информацией о маршрутах
Маршрутизаторы могут использовать ICMP-сообщения для
обнаружения и определения сетевых адресов друг друга. Для это-
го используются сообщения типа объявление маршрутизатора
и запрос маршрутизатора.
Маршрутизатор в каждую из сетей, к которой он подключен,
периодически (обычно раз в 7—10 мин) осуществляет широкове-
щательную рассылку сообщения «объявление маршрутизатора»
(рис. 2.28), содержащего его IP-адрес. Таким образом, о функцио-
нировании маршрутизатора в сети и его адресе узнают не только
другие маршрутизаторы, но и обычные хосты.
Сообщение «запрос маршрутизатора» рассылается в том слу-
чае, если маршрутизатору, например, после подключения к сети,
необходимо срочно получить сведения о соседних маршрутизато-
рах, не дожидаясь очередной рассылки их объявлений. При этом
108
Глава 2. Организация сетевого взаимодействия
О 7 15
23 31
Тип Код
Контрольная сумма
Число адресов Длина адреса
Время жизни
Адрес маршрутизатора 1
Уровень приоритета маршрутизатора 1
Адрес маршрутизатора N
Уровень приоритета маршрутизатора N
Рис. 2.28. Формат 1СМР-сообшения «объявление маршрутизатора»
после получения такого запроса маршрутизатор должен произ-
вести внеочередную рассылку сообщения «объявление маршрути-
затора».
Сообщение объявления имеет следующие поля:
• заголовок;
• число адресов — количество адресов маршрутизатора, ука-
зываемых в сообщении;
• длина адреса — число 32-битовых слов, необходимых для
записи каждого адреса маршрутизатора;
• время жизни — максимальное время, выраженное в секун-
дах, в течение которого адреса маршрутизатора могут счи-
таться действительными;
• адрес маршрутизатора — IP-адрес (или адреса, если их не-
сколько) интерфейса маршрутизатора, с которого данное
сообщение было отправлено;
• уровень приоритета — предпочтительность каждого из адре-
сов маршрутизатора относительно адресов других маршру-
тизаторов, находящихся в этой же сети.
0 7 15 23 31
Тип Код Контрольная сумма
Нули
Рис. 2.29. Формат ICMP-сообшения «запрос маршрутизатора»
2.9. Работа протоколов стека TCP/IP
109
Сообщение «запрос маршрутизатора» (рис. 2.29) состоит из
заголовка, где поле тип имеет значение, равное 10, и игнорируе-
мого при получении 32-битового слова, заполняемого по требова-
нию стандарта нулями.
Сообщение о превышении времени жизни дейтаграммы
Если время жизни дейтаграммы истекает, то данная дейта-
грамма уничтожается, однако при этом ее отправителю посылает-
ся соответствующее ICMP-сообщение (рис. 2.30), содержащее
следующие поля:
• заголовок;
• пустое поле;
• данные исходной дейтаграммы.
0 7 15 23 | 31
Тип Код Контрольная сумма
Нули
Данные исходной дейтаграммы
Рис. 2.30. Формат ICMP-сообщения о превышении
времени жизни дейтаграммы
Значение поля «код» заголовка сообщения указывает на при-
чину истечения срока жизни дейтаграммы (табл. 2.13).
Сообщение о возникновении проблем с параметрами в заго-
ловке дейтаграммы
Подобные сообщения (рис. 2.31) генерируются, если при
обработке дейтаграммы обнаруживаются проблемы или несоот-
ветствия в параметрах заголовка дейтаграммы, делающие не-
возможной дальнейшую обработку дейтаграммы. В этом случае
Таблица 2.13. Коды причины окончания срока жизни дейтаграммы
Код Описание
0 Время жизни превышено при передаче
1 Превышено контрольное время при сборке фрагментов дейтаграммы (не все фрагменты дейтаграммы были получены вовремя)
по
Глава 2. Организация сетевого взаимодействия
0 7 15 23 | 31
Тип Код Контрольная сумма
Указатель Нули
Данные исходной дейтаграммы
Рис. 2.31. Формат ICMP-сообщения о проблемах с параметрами
обрабатываемая дейтаграмма уничтожается, а ее отправителю
посылается уведомляющее об этом ICMP-сообщение.
Сообщение о проблемах с параметрами имеет следующие
поля:
• заголовок;
• указатель — определяет байт в заголовке дейтаграммы, где
была обнаружена ошибка в параметре;
• пустое поле;
• данные исходной дейтаграммы.
Сообщения обмена временными метками
Сообщения запроса временной метки и ответа на него
(рис. 2.32) используются для синхронизации машинного времени
на различных узлах сети. Для этого один из узлов может послать
другому узлу сообщение, содержащее запрос временной метки
с указанием времени, фиксированным на момент отправки сооб-
щения. Получив подобный запрос, второй узел отсылает полу-
ченное сообщение обратно, поместив в него время, которое он
зафиксировал в момент получения запроса и в момент отправки
ответа.
0 7 15 23 | 31
Тип Код Контрольная сумма
Идентификатор Последовательный номер
Начальная временная метка
Временная метка получения
Временная метка передачи
Рис. 2.32. Формат ICMP-сообщения обмена временными метками
2.9. Работа протоколов стека TCP/IP
111
Сообщения обмена временными метками состоят из следую-
щих полей:
• заголовок;
• идентификатор;
• последовательный номер;
• начальная временная метка — время, зафиксированное от-
правителем непосредственно перед посылкой запроса;
• временная метка получения — время, зафиксированное ад-
ресатом запроса, на момент получения данного сообщения;
• временная метка передачи — время, зафиксированное узлом,
отправляющим ответ на запрос временной метки, непосред-
ственно перед посылкой этого ответа.
Поля «идентификатор» и «последовательный номер» так же,
как и в сообщениях типа запрос и ответ на эхо, используются
для того, чтобы определить соответствующие друг другу запро-
сы и ответы.
На основе данных, полученных из трех меток ответа на запрос,
узел может вычислить примерное время обмена сообщениями,
а на его основе и разницу в своем и чужом машинном времени.
Сообщения обмена информацией
Данный тип сообщений — запросы информации и ответы на
них — позволяет определить номер сети, в которой находится
хост, отправляющий такое ICMP-сообщение. Для этого хост дол-
жен разослать широковещательное сообщение «запрос информа-
ции», при этом IP-адреса отправителя и получателя в заголовке
дейтаграммы, содержащей данное сообщение, должны состоять
из нулей. В ответ должна быть послана дейтаграмма с полностью
определенными IP-адресами.
Сообщения данного типа состоят из заголовка и полей «иден-
тификатор» и «последовательный номер», назначение которых
совпадает с аналогичными полями сообщений запрос—ответ дру-
гих типов.
Обмен информацией об адресной маске
Сообщения запроса маски адреса и ответа на него (рис. 2.33)
используются для определения маски подсети, в которой нахо-
дится интересующий хост-адрес. Сообщение с запросом переда-
112
Глава 2. Организация сетевого взаимодействия
0 7 15 23 | 31
Тип Код Контрольная сумма
Идентификатор Последовательный номер
Маска адреса
Рис. 2.33. Формат ICMP-сообщения обмена информацией об адресной маске
ется на шлюз, если хосту-отправителю запроса известен его адрес,
либо делается широковещательный запрос.
Формат сообщений запроса и ответа одинаков и имеет сле-
дующие поля:
• заголовок;
• идентификатор;
• последовательный номер;
• маска адреса — содержит искомую маску.
Поля «идентификатор» и »последовательный номер» исполь-
зуются для определения соответствующих запросов и ответов.
2.9.3. Протокол пользовательских дейтаграмм UDP
Данный протокол является одним из транспортных протоко-
лов стека TCP/IP и описывается стандартом RFC 768.
Задачей UDP (User Datagram Protocol) является передача дан-
ных прикладных программ с использованием простых механизмов
пересылки (рис. 2.34), которые не гарантируют доставку и защиту
от дублирования. Для выполнения этой задачи UDP использует
Рис. 2.34. Инкапсуляция пользовательских дейтаграмм
2.9. Работа протоколов стека TCP/IP
113
Рис. 2.35. Иерархия протоколов стека TCP/IP
средства передачи данных, предоставляемые нижележащим меж-
сетевым протоколом IP.
Большинство используемых в настоящее время операцион-
ных систем являются многозадачными, т. е. имеют возможность
одновременно выполнять два прикладных процесса и более, ко-
торым могут соответствовать, например, выполняемые пользова-
тельские программы.
В отличие от межсетевого протокола, который должен обес-
печивать передачу данных между хостами сети, протокол пользо-
вательских дейтаграмм должен обеспечивать передачу данных ме-
жду любыми прикладными процессами (рис. 2.35), выполняемы-
ми на этих хостах.
Для однозначной идентификации прикладных процессов, вы-
полняемых операционной системой, используются логические
порты.
Назначение номера порта тому или иному процессу может
носить как централизованный, так и локальный характер. В пер-
вом случае номера портов закрепляются за широко используемы-
ми популярными службами, такими как FTP, HTTP, SMTP,
(табл. 2.14) и т. д. Занимается этим уполномоченная организация
по распределению нумерации в сети Интернет (Internet Assigned
Numbers Authority — IANA), которая также отвечает за приведе-
ние к единым нормам информации о структуре доменных имен
(DNS), является глобальным координатором в распределении
IP-адресов и многих других параметров, используемых в сети Ин-
тернет.
114
Глава 2. Организация сетевого взаимодействия
Таблица 2.14. Некоторые процессы и службы и номера закрепленных за ними логи-
ческих портов
Номер порта Обозначение Описание
21 FTP Протокол пересылки файлов
23 telnet Работа с удаленным терминалом
25 SMTP Протокол передачи почтовых сообщений
50,51 IPSec IP-инкапсуляция шифрованных данных/аутентифи- кационный заголовок
69 TFTP Протокол простой пересылки файлов
80 WWW-HTTP Всемирная паутина (World Wide Web), протокол пе- ресылки гипертекста
109 POP2 Почтовый протокол рор2
110 POP3 Почтовый протокол рорЗ
194 IRC Протокол Интернет для удаленных переговоров
201-206 Протоколы стека компании Apple
213 IPX Протокол IPX
443 HTTPS Защищенный HTTP
520 RIP Протокол обмена маршрутной информацией
Для других служб и процессов выделение портов производит-
ся локально, т. е. независимо на каждой машине, путем назначе-
ния прикладному процессу номера любого незанятого в текущий
момент времени порта из отведенного для этих целей диапазона.
Таким образом, на одном узле может одновременно существо-
вать несколько конечных мест назначения пересылаемых данных.
Для каждого задействованного порта модуль UDP ведет две
очереди обработки пакетов:
• пакеты, поступающие из сети;
• пакеты, которые должны быть переданы в сеть.
Прием сообщений от разнообразных прикладных процессов,
инкапсуляция их в UDP-дейтаграмму и передача их нижележа-
щим уровням для пересылки по сети называется мультиплексиро-
ванием UDP.
Мультиплексирование — это технология разделения средств
передачи данных между группой использующих их объектов.
2.9. Работа протоколов стека TCP/IP
115
Рис. 2.36. Мультиплексирование UDP
Мультиплексирование, осуществляемое протоколом пользова-
тельских дейтаграмм (рис. 2.36), позволяет использовать средства
передачи данных, предоставляемые межсетевым протоколом,
множеству разнообразных прикладных процессов и служб.
Обратный мультиплексированию процесс называется демуль-
типлексированием. Так, протокол пользовательских дейтаграмм
производит демультиплексирование по портам назначения, при-
нимая от межсетевого протокола дейтаграммы, распределяя полу-
ченные в них данные среди различных прикладных процессов
и служб.
Как уже говорилось, UDP использует для передачи своих со-
общений межсетевой протокол, обеспечивающий ненадежную
доставку данных. UDP призван реализовывать простой механизм
пересылки данных между пользовательскими приложениями
и сетевыми службами, поэтому он не имеет своих собственных
механизмов обеспечения контроля передачи данных и не несет
ответственности за благополучную доставку сообщений. Ответст-
венность за это возлагается на прикладные протоколы и процес-
сы, использующие UDP в качестве транспортного средства, кото-
рые и должны иметь и использовать свои собственные средства
обеспечения надежности доставки данных.
Пользовательская дейтаграмма состоит из заголовка (рис. 2.37)
и поля данных. Заголовок имеет достаточно простой формат и со-
держит следующие поля:
• порт отправителя — идентифицирует процесс, посылающий
данную дейтаграмму; в случае если это поле в дейтаграмме
не используется, оно заполняется нулями;
116
Глава 2. Организация сетевого взаимодействия
0 7 | 15 23 | 31
Порт отправителя Порт получателя
Длина Контрольная сумма
Рис. 2.37. Формат заголовка пользовательской дейтаграммы
• порт получателя — идентифицирует процесс, на который
должны быть переданы данные, пересылаемые данной дей-
таграммой;
• длина — указывает длину дейтаграммы в байтах, включая
как ее заголовок, так и поле данных;
• контрольная сумма — рассчитывается по заголовку, полю
данных и псевдозаголовку дейтаграммы; является необяза-
тельной для вычисления, поэтому в сетях с повышенной на-
дежностью передачи данных может не использоваться, что
позволяет уменьшить объем вычислений при использова-
нии данного протокола.
Если поле контрольной суммы заполнено нулями, это значит,
что она не рассчитывалась при посылке дейтаграммы. Если дан-
ное поле заполнено единицами, значит, рассчитанное значение
контрольной суммы равно нулю.
Псевдозаголовок (рис. 2.38), используемый при расчете кон-
трольной суммы дейтаграммы, имеет следующие формат:
• IP-адрес отправителя;
• IP-адрес получателя — значения для заполнения этого
и предыдущего полей берутся из IP-дейтаграммы, в которую
инкапсулируется данная UDP-дейтаграмма;
• нули — поле из восьми бит, заполненное нулями;
• протокол — данное поле аналогично одноименному полю
IP, в данном случае содержит значение, равное 17, — код
UDP;
• длина UDP-дейтаграммы (не включая псевдозаголовок).
Псевдозаголовок является частью механизма, позволяющего
удостовериться, что дейтаграмма была доставлена по своему ис-
тинному месту назначения, и не передается вместе с этой дейта-
граммой.
Проверить, правильно ли была дейтаграмма доставлена, мож-
но с помощью контрольной суммы сообщения, при этом необхо-
димо учитывать полный адрес назначения, т. е. и IP-адрес, и но-
2.9. Работа протоколов стека TCP/IP
117
0 7 15 23 | 31
IP-адрес отправителя
IP-адрес получателя
Нули Протокол Длина UDP-дейтаграммы
Рис. 2.38. Формат псевдозаголовка пользовательской дейтаграммы
мер порта. UDP-заголовок определяет только номер логического
порта получателя.
Поэтому, чтобы убедиться в достоверности места назначения
дейтаграммы, контрольная сумма вычисляется и для псевдозаго-
ловка. При этом псевдозаголовок можно легко повторить на хос-
те-получателе, основываясь на данных заголовка дейтаграммы
межсетевого протокола. Если вычисленная получателем кон-
трольная сумма совпадает с той, что была передана в UDP-дейта-
грамме, значит, сообщение пришло по нужному адресу и на нуж-
ный порт.
2.9.4. Протокол управления передачей TCP
Протокол управления передачей (Transmission Control Proto-
col — TCP) представляет собой высоконадежный протокол, обес-
печивающий взаимодействие между хостами, а точнее, между вы-
полняемыми на них прикладными процессами в коммуникацион-
ных компьютерных сетях, а также в объединенных системах таких
сетей. Спецификация TCP содержится в стандарте RFC 793.
Так же как и протокол пользовательских дейтаграмм, прото-
кол управления передачей является транспортным средством
прикладных процессов, обеспечивающим для них интерфейс со
средствами передачи данных межсетевого протокола. Однако,
в отличие от UDP, не гарантирующего доставку данных, TCP яв-
ляется так называемым надежным протоколом, имеющим средст-
ва обеспечения гарантированной доставки данных.
Взаимодействие модуля TCP с прикладными процессами осу-
ществляется посредством двунаправленных потоков данных на
каждом из используемых процессами логических портов. Дан-
ные, поступающие от прикладного процесса, упаковываются
в сегменты определенной длины для дальнейшей передачи по се-
118
Глава 2. Организация сетевого взаимодействия
0 '1 15 23 31
Порт отправителя Порт получателя
Последовательный номер
Номер подтверждения
Смещение Зарезерви- Контрольные биты
данных Р°ван0 urg ack psh rst syn fin Окно
Контрольная сумма Указатель срочных данных
Опции Выравнивание
Данные
Рис. 2.39. Формат ТСР-сегмента
ти. В общем случае модуль TCP сам принимает решение о том,
как и когда производить разбивку поступающих от приложений
данных на сегменты (рис. 2.39) и осуществлять их пересылку.
Сегменты могут иметь различную длину, однако при обмене
информацией участники сетевого взаимодействия все же должны
договориться об их максимальном размере. При этом максималь-
ный размер сегмента не должен превышать максимального раз-
мера поля данных IP-дейтаграммы, в которой будет осуществ-
ляться его пересылка.
TCP-сегмент включает в себя заголовок и поле данных, имея
следующий формат:
• порт отправителя — содержит номер логического порта,
идентифицирующего процесс, который является источни-
ком информации, пересылаемой в поле данных сегмента;
• порт получателя — содержит номер логического порта,
на который пересылаемая информация должна быть до-
ставлена;
• последовательный номер — порядковый номер байта в по-
токе данных, полученных модулем TCP от вышележащего
уровня или процесса;
• номер подтверждения — данное поле может содержать по-
рядковый номер байта в потоке передаваемых данных, кото-
рый отправитель данного пакета желает получить в ответ;
2.9. Работа протоколов стека TCP/IP
119
• смещение данных — поскольку заголовок ТСР-сегмента
имеет переменную длину, то данное поле указывает начало
поля данных;
• зарезервированное — данное поле является зарезервирован-
ным для будущего использования, должно быть заполнено
нулями;
• контрольные биты:
— w/g (от англ, urgent — срочный) — поле указателя срочных
данных задействовано — если данный бит установлен,
т. е. его значение равно единице, значит, сегмент содер-
жит срочные данные;
— ack (от англ, acknowledgement — уведомление, подтвержде-
ние) — поле «номер подтверждения» задействовано;
— psh (от англ, push — толкать, проталкивать) — функция
«проталкивания» — установленный данный бит сигнали-
зирует, что данные по мере поступления: от прикладного
процесса должны будут передаваться в сеть незамедлитель-
но небольшими сегментами, а не накапливаться и упако-
вываться в более крупные сегменты; при получении сег-
мента с установленным битом «psh» модуль TCP должен
передать данные, пришедшие в сегменте, прикладному
процессу, которому эти данными адресованы, также неза-
медлительно, не дожидаясь пока дойдут другие части пере-
даваемого сообщения;
— rst (от англ, reset — сброс) — сброс логического соедине-
ния либо запрос на переустановку соединения;
— syn (от англ, synchronize — синхронизировать) — синхро-
низация последовательных номеров, используется при ус-
тановке логического соединения;
— fin (от англ, finalize — завершить, закончить) — данных
для передачи больше нет — если бит установлен, то дан-
ный TCP-сегмент является запросом на прекращение ло-
гического соединения;
• окно — номера байтов данных, которые отправитель данно-
го сегмента собирается принять, начиная с того байта, но-
мер которого указан в поле «окно подтверждения»;
• контрольная сумма — для вычисления контрольной суммы
используется псевдозаголовок (рис. 2.40), формат которого
полностью повторяет формат псевдозаголовка UDP;
120
Глава 2. Организация сетевого взаимодействия
0 7 15 23 I 31
IP-адрес отправителя
IP-адрес получателя
Нули Протокол Длина UDP-дейтаграммы
Рис. 2.40. Псевдозаголовок TCP
• указатель срочных данных — это поле обрабатывается, толь-
ко если установлен контрольный бит «urg»; TCP позволяет
информировать получателя о наличии в пересылаемом сег-
менте блока срочных данных, требующих обработки вне
очереди — данное поле определяет местоположение блока
срочных данных в поле данных сегмента;
• опции — данное поле используется при установке логиче-
ского соединения, в частности для определения максималь-
ной длины передаваемых между узлами сегментов; формат
данного поля похож на формат аналогичного поля межсете-
вого протокола;
• выравнивание — поле, заполняемое нулями, чтобы длина
заголовка всегда оказывалась кратной 32 битам;
• данные — непосредственно данные прикладного процесса,
для передачи которых используется этот ТСР-сегмент.
Главной задачей протокола управления передачей, как уже
упоминалось, является обеспечение надежным и безопасным
транспортным средством пары прикладных процессов.
Поэтому, основываясь на малонадежных средствах межсете-
вого протокола для выполнения своей задачи, TCP реализует ряд
механизмов:
• надежную доставку данных;
• управление потоком данных;
• управление логическими соединениями.
Надежная доставка данных
Протокол управления передачей обеспечивает достоверность
передаваемых данных за счет использования контрольной суммы,
позволяющей выявлять ошибки, возникающие в ходе работы сис-
темы передачи данных.
2.9. Работа протоколов стека TCP/IP
121
Заголовок TCP llllllllllllll Данные сегмента llllllllllllll
Последовательный номер Последовательный номер
первого байта сегмента последнего байта сегмента
Рис. 2.41. Нумерация байтов данных в сегменте TCP
Однако гарантированность доставки всего объема передан-
ных данных основывается на использовании другого метода.
Для того чтобы отправитель мог убедиться, что переданная им
информация была успешно доставлена, ее получатель должен
в ответ передать квитанции — особые пакеты, — подтверждаю-
щие успешную доставку этой информации.
При этом для определения того, какая часть информации была
доставлена получателю, а какая нет, ведется нумерация каждого
байта, полученного модулем TCP вместе с потоком данных от вы-
шележащего уровня или процесса (рис. 2.41). При передаче по сети
номер первого байта, содержащегося в поле данных пересылаемо-
го сегмента, помещается в заголовок этого сегмента в поле «после-
довательный номер». Нумерация передаваемых байтов в пределах
сегмента производится по возрастанию, т. е. самый первый байт
имеет наименьший номер, а последний — наибольший.
Квитанция, подтверждающая получение данных, содержит
последовательный номер байта, следующего за последним из
успешно полученных, т. е. за байтом, имеющим максимальный
номер. Другими словами, квитанция указывает байт, который по-
лучатель данных желает получить следующим. Порядковый но-
мер этого байта называется номером подтверждения.
Если квитанция, подтверждающая доставку данных, не полу-
чена в течение некоторого контрольного времени, то передача
этих данных повторяется.
Получение квитанции, содержащей некий номер байта, озна-
чает, что все байты с предыдущими номерами благополучно до-
ставлены адресату, т. е. данный механизм носит накопительный
характер.
Последовательные номера байтов также используются полу-
чателем для восстановления очередности сегментов, если они по-
лучены в неправильном порядке, кроме того, они позволяют бо-
лее корректно отслеживать случаи дублирования сегментов.
122
Глава 2. Организация сетевого взаимодействия
Таким образом, до тех пор, пока модули TCP продолжают ра-
ботать корректно и система взаимодействующих между собой се-
тей не распалась на отдельные части, ошибки непосредственно
передачи данных не повлияют на корректность обмена данными.
Другими словами, протокол управления передачей обеспечивает
защиту от возможных ошибок ненадежных транспортных средств
протоколов нижележащих уровней.
Управление потоком данных
Одна из самых простых реализаций механизма подтвержде-
ния доставки данных заставляет отправителя сегмента дождаться
квитанции, подтверждающей или опровергающей (если сегмент
по каким-либо причинам не был принят) получение этого сег-
мента адресатом, и только после этого производить передачу сле-
дующего либо повтор утерянного сегмента данных. В этом случае
наблюдается неэффективное использование линии связи, так как
отправитель вынужден постоянно прерывать передачу данных,
поскольку должен дожидаться квитанций.
Для повышения производительности при передаче информа-
ции по сети с использованием подобного механизма подтвержде-
ния доставки данных отправителю разрешают переслать, не до-
жидаясь квитанции, не один (см. рис. 2.41), а сразу несколько сег-
ментов. Количество этих сегментов называется размером «окна».
Окно определяет некий диапазон в потоке данных, который
отправитель вправе передать на текущий момент времени до по-
лучения дальнейших инструкций. То есть до тех пор, пока дан-
ные, «лежащие» в пределах окна, не будут полностью переданы,
а квитанции по ним не будут получены, пересылка данных, нахо-
дящихся за границами этого окна, запрещена (рис. 2.42).
В протоколе управления передачей используется более совер-
шенный метод подтверждения доставки данных, называемый ме-
тодом «скользящего окна» (рис. 2.43). Данный метод основан на,
том, что границы окна, определяющего диапазон порядковых но-,
меров байтов, сдвигаются по мере прихода квитанций. Таким об-
разом, если не происходит задержка квитанций, передача можетs
идти непрерывно, практически без остановок.
С другой стороны, каждая из взаимодействующих сторон мо-
жет передавать количество байтов, не превышающее размер окна, ,
указанного в поле «окно» заголовка сегмента, подтверждающего',
2.9. Работа протоколов стека TCP/IP
123
Размер окна
Рис. 2.42. Управление потоком данных:
1— переданные сегменты, квитанции для которых получены; 2— переданные сег-
менты, но квитанции для них пока не получены; 3 — сегменты, которые можно
передавать; 4 — сегменты, которые пока нельзя передавать
Окно
I ............. —И
I | IЮ 161 |18|19| | | | |
Сегмент отправлен адресату | 61
: Окно •
Получена квитанция с номером подтверждения 13 [ 1з|
Рис. 2.43. Метод «скользящего окна»
получение предыдущих данных. При этом размер окна обычно
зависит от объема свободного места в буферах приема модулей
TCP, а также от скорости обработки поступающих данных этим
модулем.
Таким образом, кроме всего прочего, протокол управления
передачей предоставляет удобный механизм управления объемом
потоков данных, пересылаемых друг другу узлами.
Управление логическими соединениями
Подобно протоколу пользовательских дейтаграмм, протокол
управления передачей для обеспечения взаимодействия различ-
ных прикладных процессов использует логические порты.
124
Глава 2. Организация сетевого взаимодействия
TCP 1 Последова- тельный номер Номер под- тверждения Установлен- ные биты Длина поля данных TCP 2
500 syn 0
800 501 syn, ack 0
501 801 ack 0
Рис. 2.44. Процесс установления логического соединения
Каждый прикладной процесс может однозначно идентифи-
цироваться набором таких параметров, как адрес сети, адрес хоста
в сети и номер порта, принадлежащего хосту — совокупность этих
параметров называется сокетом (socket).
Работа TCP основана на установлении между участниками
взаимодействия — прикладными процессами логических соеди-
нений.
Логическое соединение подразумевает обмен участниками
взаимодействия информацией о характеристиках и состоянии по-
токов данных, которые должны быть переданы в результате сете-
вого взаимодействия. Совокупность подобной информации,
включающей сокеты, последовательные номера, размеры окон,
называется соединением.
Каждый прикладной процесс определяется сокетом (1Р-ад-
рес, номер порта). Каждое соединение однозначно идентифици-
руется парой сокетов, обозначающих взаимодействующие про-
цессы. Таким образом, любой сокет может одновременно исполь-
зоваться в нескольких соединениях.
Процесс взаимодействия двух процессов с установкой соеди-
нения подразумевает выполнение следующих этапов:
• установка соединения;
• обмен данными;
• закрытие соединения.
Соединение TCP является полнодуплексным, т. е. данные по
нему могут пересылаться в обоих направлениях. Установление
соединения подразумевает наличие пассивной стороны, ожидаю-
щей, пока кто-то другой инициализирует соединение, и активной
стороны, посылающей запрос на инициализацию соединения.
2.9. Работа протоколов стека TCP/IP
125
TCP 1 Последова- тельный номер Номер под- тверждения Установлен- ные биты Длина поля данных TCP 2
501 801 ack 30
801 531 ack 50 <—
531 851 ack 0
Рис. 2.45. Процесс обмена данными
Процесс установления соединения (рис. 2.44), который ино-
гда называют трехшаговым рукопожатием (three-way handshake),
сводится к обмену сегментами с установленным битом syn и не-
ким начальным значением последовательного номера. В случае
получения подтверждения (последовательный номер, увеличен-
ный на единицу) доставки соответствующих сегментов обеими
сторонами соединение считается открытым.
При обмене данными (рис. 2.45) принимающая сторона все-
гда должна подтвердить получение данных, отослав отправителю
сегмент с установленным битом ack и номером подтверждения,
значение которого определяется прибавлением единицы к сумме
последовательного номера, и длины корректно принятых данных.
Закрытие соединения (рис. 2.46) происходит после обмена
взаимодействующими сторонами сегментами, где установлен бит
fin, означающий отсутствие данных для пересылки. При этом од-
на сторона, например А, может послать сегмент с таким битом,
прекратив передачу данных, в то время как другая сторона еще
имеет данные для передачи. Сторона А, закрывшая соединение,
больше не передает данные, но может тем не менее отсылать дру-
гой стороне квитанции, подтверждающие прием данных.
Вторая сторона — сторона Б, закончив пересылку данных, от-
правляет стороне А сегмент с установленным битом fin. Получив
его, сторона А высылает подтверждение на разрыв соединения.
После этого соединение считается разорванным.
Управление соединением может осложняться различными си-
туациями, например попыткой узлов инициализировать соедине-
ние друг с другом, выслав одновременно два встречных запроса
на установку соединения. В этом случае запрос на соединение
126
Глава 2. Организация сетевого взаимодействия
TCP 1 Последова- тельный номер Номер под- тверждения Установлен- ные биты Длина поля данных TCP 2
531 851 ack, fin 0
851 532 ack 0 <—
851 532 ack 100 <—
532 952 ack 0
952 533 ack, fin 0 <-
533 953 ack 0
Рис. 2.46. Процесс расторжения логического соединения
одной из сторон будет проигнорирован, и порядок действий по
инициализации соединения сведется к описанному выше.
2.9.5. Прикладные протоколы
Прикладные протоколы или протоколы прикладного уровня,
прежде всего, ориентированы на обеспечение интерфейса между
конкретными прикладными задачами и средствами транспорти-
ровки данных по сети, предоставляемых нижележащими уровня-
ми. Прикладные протоколы обеспечивают взаимодействие при-
кладных процессов и определяют форму такого взаимодействия.
Существует большое разнообразие протоколов прикладного
уровня, и их количество продолжает увеличиваться по мере раз-
вития сетевых технологий и появления новых типов приложений,
а значит, и новых типов задач по организации обмена информа-
цией.
Наиболее распространенные протоколы стека TCP/IP под^;
робно рассмотрены ниже.
2.9. Работа протоколов стека TCP/IP
127
Протокол TELNET
Протокол telnet (telecommunications network) — протокол сети
передачи данных телекоммуникационной сети, обеспечивающий
передачу данных между процессами или между процессом и тер-
миналом и обычно использующийся для эмуляции терминала
удаленной станции.
Терминалом называют устройство, состоящее из средств вво-
да-вывода, обычно клавиатуры и монитора, и используемое для
взаимодействия с хост-компьютерами, на которых выполняются
прикладные программы.
Для передачи своих данных в качестве транспорта telnet ис-
пользует протокол управления передачей, в сегменты которого
инкапсулирует свои сообщения.
Telnet достаточно простой и весьма распространенный про-
токол, присутствует практически в каждой реализации стека
TCP/IP. Он обеспечивает возможность удаленного доступа через
сеть к хостам и их вычислительным ресурсам. Telnet позволяет
устанавливать связь между хостами, имеющими различные опе-
рационные системы.
Telnet-клиент обеспечивает интерфейс между пользователем
и telnet-сервером, отправляя на сервер команды, вводимые поль-
зователем с клавиатуры, а результаты их выполнения на сервере
выводя на дисплей пользователя.
Протоколы передачи файлов
FTP (File Transfer Protocol) — протокол передачи файлов —
это протокол, предназначенный для обеспечения обмена файла-
ми между серверами и клиентами. Подобно протоколу telnet, про-
токол передачи файлов также способен обеспечивать взаимодей-
ствие между хостами, использующими различные операционные
системы и различные файловые системы, использует транспорт-
ные средства надежного протокола передачи данных TCP.
Используя специальные команды, пользователь FTP может
просмотреть каталог файлов удаленной рабочей станции, осуще-
ствлять навигацию среди каталогов, а также производить копиро-
вание файлов.
TFTP (Trivial File Transfer Protocol) — простейший протокол
передачи файлов. В отличие от FTP этот протокол использует
пользовательские дейтаграммы UDP и подходит для пересылки
128
Глава 2. Организация сетевого взаимодействия
небольших файлов. Одним из весьма распространенных его при-
менений является обеспечение передачи с сервера файлов, необ-
ходимых для загрузки системы или приложений удаленной рабо-
чей станции.
NFS (Network File System) — сетевая файловая система, пред-
ставляет собой скорее не протокол, а сетевую службу, позволяю-
щую объединить в одно целое файловые системы нескольких уда-
ленных машин. При этом пользовательские приложения, запу-
щенные на рабочей станции, получают возможность работать
с файлами и каталогами сетевой файловой системы так, как будто
эта система является для данной рабочей станции локальной. Для
передачи файлов, а также информации и содержимого каталогов
и логических дисков NFS так же, как и TFTP, использует прото-
кол пользовательских дейтаграмм.
Протокол SMTP
SMTP (Simple Mail Transfer Protocol) — простой протокол пе-
редачи почты, использующийся для передачи текстовых файлов
и почтовых сообщений с использованием средств надежной дос-
тавки транспортного протокола TCP между сетевыми системами.
SMTP-сообщение состоит из заголовка и непосредственно те-
ла почтового сообщения. Заголовок содержит сведения обо всех
промежуточных узлах, через которые данное сообщение прошло,
эти сведения включают в себя сетевой адрес промежуточного узла,
а также временную метку, поставленную на каждом из этих узлов.
При передаче сообщения отправитель выступает в роли кли-
ента почтовой службы, который инициирует соединение с полу-
чателем, являющимся сервером, и посылает запросы на обслужи-
вание.
Простой протокол управления сетью SNMP
SNMP (Simple Network Management Protocol) — простой про-
токол управления сетью, позволяющий производить мониторинг
сетевой активности, а также осуществлять управление рабочими
станциями и коммутационным оборудованием сети. Мониторинг
сети и управление осуществляются с помощью станции управле-
ния сетью, задача которой — контроль работы сетевых устройств,
поддерживающих SNMP-агентов сети.
2.9. Работа протоколов стека TCP/IP
129
Протокол дает возможность передавать между станцией
управления и агентами сети информацию, представляющую со-
бой как простую статистику функционировании того или иного
сетевого агента, так и адресованные этим же агентам управляю-
щие команды.
Работа протоколов стека IPX/SPX
Стек протоколов IPX/SPX имеет ряд особенностей, обуслов-
ливаемых тем, что входящие в него протоколы разрабатывались
для работы в операционной системе Novell NetWare. Данная сис-
тема изначально ориентировалась на функционирование в не-
больших локальных сетях, рабочие станции которых не имели
особо мощных ресурсов.
Протоколы, входящие в разработанный компанией Novell
стек IPX/SPX, отличаются от других протоколов весьма скромны-
ми требованиями к вычислительным ресурсам, но достаточно не-
экономно используют пропускную способность каналов связи,
засоряя их широковещательными пакетами.
Однако компания Novell обычно с выходом каждой после-
дующей версии операционной системы NetWare вносит в свои
протоколы существенные изменения, ориентируя их на работу
в больших составных сетях.
Стек 1PX/SPX имеет структуру, схожую со стеком TCP/IP, со-
ответственно, и принцип его работы напоминает работу TCP/IP.
Протоколы верхнего уровня, взаимодействуя с приложения-
ми пользователя, формируют сообщения, для передачи которых
пользуются услугами транспортного протокола SPX.
Протокол SPX, устанавливая логическое соединение, в свою
очередь использует для пересылки данных протокол IPX,
Прикладные программы могут обращаться непосредственно
к уровню IPX, например, для посылки широковещательных сооб-
щений, но гораздо чаше работают с уровнем SPX, организующим
быструю и надежную доставку пакетов.
Протокол SPX, а также другие протоколы того же уровня спо-
собны поддерживать работу практически со всеми популярными
протоколами нижних уровней. Они осуществляют прием и пере-
дачу данных, сбор информации о состоянии сети и существую-
щих маршрутах.
130
Глава 2. Организация сетевого взаимодействия
Протокол межсетевого обмена пакетами IPX
Протокол IPX (Internetwork Packet eXchange — межсетевой
обмен пакетами), разработанный компанией Novell, в некоторой
степени является аналогом межсетевого протокола стека TCP/IP.
Так же как и межсетевой протокол, протокол межсетевого об-
мена использует дейтаграммный метод передачи данных, т. е.
другими словами, предоставляет протоколам вышележащих уров-
ней средства негарантированной доставки данных без установле-
ния логического соединения.
Протокол IPX хорошо работает в сравнительно небольших
локальных сетях, поскольку для использования в таких сетях
и разрабатывался. Однако использование этого протокола для об-
мена данными в больших составных или глобальных сетях вызы-
вает ряд трудностей и является гораздо менее эффективным, не-
жели использование IP.
Протокол межсетевого обмена пакетами использует систему
адресации с иерархической структурой адресного пространства,
отличную от системы адресации межсетевого протокола.
Сетевой адрес IPX состоит из трех элементов и имеет следую-
щую структуру:
• номер сети;
• номер узла;
• сокет.
Поле «номер сети» в адресах IPX всегда имеет фиксированную
длину, составляющую 4 байта. Поле «номер узла» содержит физи-
ческий адрес узла сети либо любой другой аппаратный адрес, од-
нозначно связанный с узлом и имеющий длину 6 байт. Двухбайто-
вое поле «сокет» используется для идентификации прикладных
процессов, использующих протокол для пересылки данных.
Некоторые прикладные протоколы стека IPX/SPX взаимо-
действуют с протоколом межсетевого обмена пакета непосредст-
венно, а не через интерфейсы транспортного протокола SPX. Ис-
пользование сокетов в системе адресации позволяет протоколу
IPX однозначно идентифицировать прикладные процессы, кото-
рые к нему обращаются. Соответственно и процессы мульти-
плексирования, и демультиплексирования выполняются в стеке
IPX/SPX этим же протоколом, соответствующем сетевому уров-
ню модели OSI, а не транспортному и сеансовому, как в стеке
TCP/IP.
2.9. Работа протоколов стека TCP/IP
131
Рис. 2.47. Формат пакета IPX
Максимальный размер пакета IPX (рис. 2.47) составляет
576 байт, при этом 30 байт приходится на заголовок. Формат па-
кета выглядит следующим образом:
• контрольная сумма;
• длина пакета;
• управление передачей — данное поле обнуляется при от-
правке пакета и далее является своего рода счетчиком числа
промежуточных узлов, которые может пройти данный пакет
на пути от отправителя к адресату; пакет не может пройти
больше 15 промежуточных узлов, т. е. если значение данно-
го поля равно 15, то следующий (шестнадцатый) промежу-
точный узел этот пакет уничтожит;
• тип — определяет тип передаваемого пакета;
• адрес получателя — содержит 12-байтовый IPX-адрес отпра-
вителя данного пакета;
• адрес отправителя — соответственно содержит 12-байтовый
IPX-адрес получателя пакета;
• данные — содержит непосредственно передаваемые пакетом
данные и может иметь длину от 0 до 546 байт.
Тип передаваемого пакета может быть следующим (табл. 2.15).
Таблица 2.15. Типы IPX-пакетов
Тип пакета Описание
0 Обычный IPX-пакет
1 Пакете информацией о маршрутах, используется протоколом обмена маршрутной информации RIP (Routing Information Protocol)
132
Глава 2. Организация сетевого взаимодействия
Окончание табл. 2.15
Тип пакета Описание
2 Квитанция-подтверждение получения данных
3 Сообщение об ошибке передачи данных
4 Пакет используется для передачи информации прикладной программы
5 Служебное сообщение протокола последовательного пакетного обме на SPX (Sequence Packet eXchange)
17 Сообщение протокола ядра сетевой операционной системы NetWare — NCP (NetWare Core Protocol)
Протокол последовательного обмена пакетами SPX
Протокол SPX (Sequence Packet exchange) является транс-
портным протоколом стека IPX/SPX. Этот протокол использует
метод взаимодействия с установкой логического соединения
и имеет средства обеспечения гарантированной доставки переда-
ваемых данных.
Протокол последовательного обмена пакетами опирается на
средства передачи данных по сети протокола IPX. Пакет протоко-
ла SPX, состоящий из заголовка и поля данных, инкапсулируется
в IPX-пакет. При этом SPX-заголовок (рис. 2.48) является неко-
торого рода дополнением к заголовку IPX-пакета. Заголовок про-
токола последовательного обмена пакетами состоит из следую-
щих полей:
• управление соединением — данное поле содержит набор би-
тов, значения которых используются для управления пото-
0 7 15
Управление соединением Тип потока данных
Идентификатор отправителя
Идентификатор получателя
Последовательный номер
Номер подтверждения
Число буферов
Рис. 2.48. Формат заголовка протокола последовательного обмена пакетами
2.9. Работа протоколов стека TCP/IP
133
ками данных в логическом соединении, в некотором роде
аналогично полю управляющих битов протокола управле-
ния передачей;
• тип потока данных — так же, как и предыдущее поле, пред-
ставляет собой набор управляющих битов, используемых
для классификации передаваемых в пакете данных;
• идентификатор отправителя — данное поле используется
для идентификации участников информационного взаимо-
действия при мультиплексировании пакетов, отправляемых
с одного сокета;
• идентификатор получателя — данное поле используется для
идентификации участников информационного взаимодей-
ствия при демультиплексировании пакетов, пришедших на
один и тот же сокет;
• последовательный номер — порядковый номер данного па-
кета в последовательности переданных в одном направле-
нии пакетов; другими словами, это счетчик количества пе-
реданных в одном направлении пакетов;
• номер подтверждения — содержит порядковый номер по-
следнего пакета в последовательности успешно принятых,
увеличенный на единицу; данное поле аналогично одно-
именному полю заголовка TCP;
• число буферов — содержит количество буферов узла, спо-
собных принимать пакеты — используется для управления
потоками данных между участниками сетевого взаимодейст-
вия, является своеобразным аналогом поля «окно» заголов-
ка протокола управления передачей.
Механизм подтверждения доставки данных в протоколе SPX
не использует метод «окна», хотя такая возможность и есть (бла-
годаря полю «число буферов»). Отправив пакет, модуль SPX ожи-
дает, пока придет подтверждение о приеме этого пакета получате-
лем, и только после подтверждения передает следующий пакет.
Такой метод делает протокол последовательного обмена паке-
тами малопригодным для передачи данных в глобальных сетях,
имеющих зачастую довольно медленные каналы связи.
Спустя некоторое время после появления протокола SPX был
разработан еще один протокол, названный SPX II. Протокол
SPX II обеспечивает обратную совместимость с протоколом SPX.
Основная его задача — обеспечить передачу больших файлов.
134
Глава 2. Организация сетевого взаимодействия
0 7 15
Управление соединением Тип потока данных
Идентификатор отправителя
Идентификатор получателя
Последовательный номер
Номер подтверждения
Число буферов
Расширенное подтверждение
Рис. 2.49. Заголовок протокола SPX II
Размер пакета протокола SPX II может в несколько раз превышать
максимальный размер, допустимый для обычного SPX-пакета.
Кроме того, протокол SPX II ориентирован на использование
механизма подтверждения доставки данных, основанного на ме-
тоде «скользящего окна», аналогичного применяемому протоко-
лом управления передачей.
Формат пакета протокола второй версии (рис. 2.49) практиче-
ски не отличается от пакетов первой, за исключением того, что
в заголовок протокола SPX II добавлено новое поле «расширен-
ное подтверждение», используемое в механизме обеспечения га-
рантированной доставки данных.
Протокол ядра NetWare NCP
NCP (NetWare Core Protocol) — протокол ядра сетевой опера-
ционной системы Novell NetWare — является прикладным
и представляет собой средство взаимодействия серверов и удален-
ных станций пользователей для обеспечения пользователей сис-
темы сетевыми службами, например такими, как файловая служ-
ба, служба сетевой печати и т. д.
Для осуществления обмена данными между серверами и кли-
ентами NetWare протокол использует транспортные средства
протокола SPX. Однако некоторые сообщения могут передавать-
ся и минуя его, с помощью протокола более низкого, сетевого
уровня IPX.
Процесс работы NCP основан на передаче запросов на совер-
шение каких-либо действий и пользование какими-либо сетевы-
2.9. Работа протоколов стека TCP/IP
135
ми услугами от клиентской рабочей станции на сервер и ответов
на запросы от сервера соответствующим рабочим станциям.
Протокол объявления услуг SAP
SAP (Service Advertising Protocol) используется сервером сете-
вой операционной системы Novell NetWare для оповещения ра-
бочих станций о предоставляемых им сетевых услугах, их адресах.
Для передачи объявлений об услугах SAP использует средства
передачи данных протокола межсетевого обмена пакетами. Рас-
сылка объявлений является широковещательной и производится
постоянно с определенной периодичностью (обычно каждые
60 секунд). Кроме того, с помощью этих пакетов сервер инфор-
мирует другие серверы о своем присутствии.
SAP дает возможность сетевым устройствам обмениваться ин-
формацией об имеющихся сетевых сервисах и серверах, а также
о подключении к сети или отключении этих серверов.
Протоколы передачи больших пакетов
Такие протоколы, как протокол больших межсетевых пакетов
LIP (Large Internet Packet Protocol) и протокол пакетного режима
BMP (Burst Mode Protocol), были разработаны для повышения
эффективности использования каналов связи. Они позволяют пе-
редавать достаточно большие объемы данных, не дожидаясь под-
тверждения, что позволяет снизить количество передаваемых по
сети пакетов, а следовательно, и объем данных, а также повысить
производительность взаимодействия при обмене данными между
подсетями.
Контрольные вопросы
1. Поясните основные виды модуляции сигнала: амплитудную, фазо-
вую и частотную.
2. Какие коды можно использовать для коррекции ошибок передачи?
Почему?
3. Какие обязательные поля должен содержать кадр, передаваемый
по сети?
4. Для чего предназначена сетевая модель?
5. Перечислите уровни, входящие в сетевую модель OSI/ISO.
6. Поясните, для чего используются методы инкапсуляции и декапсу-
ляции пакетов?
136
Глава 2. Организация сетевого взаимодействия
7. Какие задачи решаются на сетевом уровне модели OSI/ISO?
8. Какие протоколы могут использоваться на канальном уровне в мо-
дели OSI/ISO?
9. Поддерживает ли стек TCP/IP протокол UDP?
10. Для чего предназначен протокол TCP?
11. В пределах какого сегмента сети обеспечивается уникальность
МАС-адреса?
12. К какому классу относится 192.168.0.3?
13. Сколько IP-адресов может быть в подсети, определяемой маской
255.255.255.128?
14. В чем различие статических и динамических IP-адресов?
15. Какую роль выполняет DNS-сервер?
16. Какой порт закреплен за HTTP?
17. На что влияет размер «окна» при передаче сообщений?
18. Назовите функции, обеспечиваемые протоколом FTP.
Глава 3
ОРГАНИЗАЦИЯ МЕЖСЕТЕВОГО
ВЗАИМОДЕЙСТВИЯ
3.1. Принципы согласования гетерогенных сетей
При организации взаимодействия двух или более компьюте-
ров для получения работоспособной сети достаточно использова-
ние базовой сетевой технологии.
Базовая сетевая технология — это согласованный набор про-
токолов и реализующих их программно-аппаратных средств, до-
статочный для построения вычислительной сети. Примерами ба-
зовых технологий могут служить такие технологии, как Ethernet
или Token Ring.
Имея программные и аппаратные средства, а также среду пе-
редачи данных, соответствующие одной базовой технологии,
и объединив их в соответствии с требованиями стандарта с помо-
щью данной технологии, можно организовать информационный
обмен нескольких компьютеров. Протоколы и оборудование се-
тей, построенных на основе базовых технологий, специально раз-
рабатываются для совместной работы, что избавляет от необходи-
мости использовать дополнительные средства для организации их
взаимодействия.
Появление новых стандартов и технологий не обозначает
массовый переход всех систем только на эти технологии. Дело
в том, что процесс модернизации обычно требует немалых за-
трат, связанных как со стоимостью нового оборудования и про-
граммного обеспечения, так и, например, с теми убытками, ко-
торые понесет организация в результате «простоя», вызванного
установкой, настройкой и проверкой работоспособности закуп-
ленного сетевого оборудования и программного обеспечения.
Поэтому, на практике существование рядом сетей, использую-
щих различные поколения одной и той же технологии, — явле-
ние вполне уместное.
138
Глава 3. Организация межсетевого взаимодействия
Весьма актуальной остается задача, когда требуется организо-
вать взаимодействие подобных сетей, объединенных в одну со-
ставную сеть. При этом, т. е. при построении составных сетей,
включающих в себя подсети, организованные с использованием
различающихся базовых технологий, встает проблема согласова-
ния между собой различных базовых технологий, а также различ-
ных «версий» реализации этих технологий.
Оборудование, разработанное для работы в сети, основанной
на одной технологии, зачастую оказывается далеко не всегда со-
вместимым между собой. Это связано с тем, что производители
сетевого оборудования используют свои собственные фирменные
стандарты, которые не всегда полностью идентичны официаль-
ным. Происходить такое может в результате неточной, ошибоч-
ной реализации официальных стандартов либо в результате по-
пыток эти стандарты улучшить (расширить), т. е. внести новые
дополнительные функции или свойства, призванные улучшить
работы производимого оборудования.
Поэтому при объединении подсетей, использующих сетевое
оборудование разных фирм, иногда возникает необходимость
выбора: либо установка нового оборудования только от одного
производителя, либо переконфигурация всего имеющегося обо-
рудования на работу по стандартным протоколам и технологиям,
чтобы оно стало совместимо с оборудованием других произво-
дителей.
Другой сложностью, возникающей при объединении не-
скольких сетей, использующих различные технологии и архитек-
туры, является применение в этих сетях различных стеков прото-
колов.
В США попытка перевести все сети на единый стек протоко-
лов OSI не увенчалась большим успехом. Это можно объяснить
тем, что в сети Интернет стандартом де-факто стал стек TCP/IP,
а кроме того, стеки IPX/SPX, NetBEUI и ряд других все еще не
потеряли своей популярности.
Для согласования протоколов, принадлежащих разным сте-
кам, используются три основных метода:
• инкапсуляция;
• трансляция;
• мультиплексирование.
Инкапсуляция (или туннелирование) протоколов — метод
согласования разнородных сетей, использующих различные тех-
3.1. Принципы согласования гетерогенных сетей
139
нологии транспортировки данных. Данный метод применяется,
если нужно организовать обмен данными между двумя сетями,
построенными по одинаковой технологии. Такие сети могут
быть связаны не непосредственно, а посредством других проме-
жуточных сетей, использующих отличные технологии построе-
ния сетей. Метод инкапсуляции, применяемый в этом случае,
использует промежуточные сети в качестве транзитных, переда-
вая информацию через них посредством их же транспортных
средств.
Принцип инкапсуляции протоколов имеет сходство с прин-
ципом инкапсуляции пакетов при их продвижении по стеку про-
токолов. Пакеты транспортного протокола, которые нужно пере-
слать через транзитную сеть, инкапсулируются в пакеты транс-
портного протокола этой транзитной сети. После прохождения
промежуточной, транзитной сети происходит обратный про-
цесс — полученные пакеты декапсулируются и пересылаются не-
посредственно адресату.
Инкапсуляция может быть использована для транспортных
протоколов любого уровня и зачастую является наиболее про-
стым и быстрым решением среди остальных методов согласова-
ния протоколов. Однако инкапсуляция не обеспечивает возмож-
ности взаимодействия с узлами транзитной сети.
Метод трансляции обеспечивает согласование двух протоко-
лов за счет конвертирования формата сообщений, поступающих
из одной сети, в формат другой сети. Задачи трансляции обычно
берут на себя аппаратно-технические средства, служащие для ор-
ганизации межсетевого взаимодействия.
Сложность выполнения трансляции зависит от степени раз-
личий транслируемых протоколов между собой, от используемых
этими протоколами систем адресации и представления данных.
Например, конвертирование сообщения Ethernet в сообщение
Token Ring выполняется достаточно просто, поскольку они ис-
пользуют одинаковую систему адресации пакетов.
К числу преимуществ трансляции перед другими методами
можно отнести:
• отсутствие необходимости устанавливать дополнительное
программное обеспечение на рабочих станциях;
• упрощение процессов администрирования, поиска неис-
правностей и обеспечения сетевой безопасности за счет
140
Глава 3. Организация межсетевого взаимодействия
локализации места возникновения проблем, связанных
с межсетевым взаимодействием.
Недостатки трансляции:
• транслятор представляет собой «узкое место» составной се-
ти, так как через него должен проходить весь межсетевой
обмен данными, и при увеличении числа пользователей, за-
прашивающих ресурсы другой подсети, уровень работоспо-
собности сети может значительно упасть;
• трансляция зачастую оказывается весьма трудоемким с точ-
ки зрения вычислительных мощностей методом, что может
уменьшать фактическую скорость передачи данных.
Мультиплексирование является еще одним методом согласова-
ния протоколов. Данный метод основан на принципе универ-
сальности отдельных узлов, участвующих во взаимодействии. На
этих узлах производится установка и настройка одновременной
работы сразу нескольких стеков протоколов, что позволяет им об-
рабатывать сообщения, получаемые от узлов, использующих раз-
личные стеки протоколов.
При этом задачи определения, с использованием какого
именно стека происходит обработка полученного сообщения, вы-
полняются специальными программными средствами, называе-
мыми мультиплексорами или менеджерами протоколов.
Таким образом, мультиплексор протоколов выполняет ком-
мутацию пакетов между протоколами соседних уровней различ-
ных стеков.
Примером использования метода мультиплексирования про-
токолов может служить некий сервер, поддерживающий приклад-
ные протоколы NCP и NFS и способный благодаря этому выпол-
нять запросы рабочих станций, находящихся в сетях NetWare
и Windows NT одновременно.
По сравнению с прочими методами согласования протоколов
мультиплексирование позволяет избавиться от «узкого места» се-
ти, а значит, и от задержек, возникающих в результате ожидания
очереди на обработку.
Однако при этом страдает простота администрирования
и контроля работоспособности сети. Кроме того, данный метод
требует установки на рабочие станции дополнительных стеков
протоколов.
3.2. Маршрутизация пакетов
141
3.2. Маршрутизация пакетов
3.2.1. Принципы маршрутизации пакетов
Под термином «маршрутизация пакетов» можно понимать не-
кий механизм, позволяющий осуществить передачу пакета с од-
ного узла составной сети на другой.
Как уже говорилось ранее, локальная сеть может быть разде-
лена на две подсети с помощью таких сетевых устройств, как мос-
ты и коммутаторы. Однако, очевидно, что эти же устройства мо-
гут использоваться и для объединения двух и более сетей в еди-
ную составную сеть.
Мосты и коммутаторы относятся к средствам физического
и канального уровня сетевой модели OSI. В силу этого, объеди-
ненная с их помощью сеть будет иметь ряд ограничений и недо-
статков, связанных с базовыми технологиями, по которым по-
строены входящие в нее подсети.
Прежде всего, топология составной сети, построенной с ис-
пользованием сетевого оборудования первого и второго уровней
модели OSI, не должна содержать петель, т. е. между отправите-
лем и получателем всегда должен существовать только один един-
ственный путь или маршрут. Такое ограничение существенно
снижает надежность сети из-за отсутствия резервных маршрутов
пересылки данных.
Кроме того, возникают проблемы, связанные с системой ад-
ресации, необходимой для обеспечения обмена данными между
любыми узлами составной сети. Система физических адресов, ис-
пользуемая на нижних уровнях сетевой модели, в масштабах со-
ставной сети оказывается недостаточно гибкой и удобной.
Возникает и ряд других сложностей, связанных с разнородно-
стью объединенных сетей.
Решением этих проблем стало использование маршрутизато-
ров — аппаратных и программных средств, способных выполнять
функции третьего, сетевого уровня модели OSL
Сетевое оборудование первых двух и третьего уровня исполь-
зует различную информацию в процессе ее перемещения от ис-
точника к адресату, т. е. выполняет схожие задачи, но принципи-
ально разными способами.
Объединение разнородных подсетей с помощью маршрутиза-
торов (рис. 3.1) допускает наличие петель в топологии сети. Обыч-
142
Глава 3. Организация межсетевого взаимодействия
Рис. 3.1. Объединение гетерогенных подсетей в составную
но в сложных составных сетях практически всегда существует не-
сколько альтернативных маршрутов, по которым возможна пере-
дача данных между двумя узлами. Кроме того, крупные составные
сети могут включать в себя сети различных масштабов — от ло-
кальных до территориально-распределенных глобальных сетей.
Маршрутом пересылки пакета с одного узла составной сети
на другой является порядок прохождения этим пакетом транзит-
ных сетей, соединяющих сети, в которых расположены источник
и адресат данного пакета.
Составные сети, в которых требуется маршрутизация пакета
на сетевом уровне, должны быть объединены между собой по-
средством маршрутизаторов. Поэтому маршрутом пересылки па-
кета по сети можно назвать последовательность маршрутизато-
ров, через которые этот пакет будет переправлен в процессе сле-
дования к своему адресату.
Маршрутизация пакетов включает в себя две основные задачи:
• определение оптимального маршрута пересылки пакета по
составной сети;
• собственно пересылка пакета по сети.
Чтобы иметь возможность определить оптимальный маршрут
пересылки пакета, маршрутизатор должен иметь информацию
обо всех существующих и доступных в данный момент времени
маршрутах. Метод, основанный на таком представлении мар-
3.2. Маршрутизация пакетов
143
шрутной информации, называется маршрутизацией по источнику
и обычно используется при тестировании работы сети.
Однако такая информация, особенно в сложных и крупных
сетях, оказывается весьма громоздкой и неудобной для осуществ-
ления по ней поиска с целью выбора подходящего маршрута.
Поэтому ни узел, отправивший пакет, ни какой-либо проме-
жуточный маршрутизатор на пути их следования не хранят ин-
формацию обо всем маршруте пакета целиком. Узел-отправитель,
а также каждый маршрутизатор знают лишь адрес маршрутизато-
ра, на который нужно направить пакет, чтобы он был доставлен
по назначению. Другими словами, маршрутизатор знает, что оп-
ределенный пункт назначения может быть достигнут по опти-
мальному пути за счет отправки пакета определенному маршру-
тизатору, который знает адрес следующего на пути к конечному
пункту назначения маршрутизатора.
Таким образом, процесс маршрутизации состоит в определе-
нии следующего узла в пути следования пакета и пересылки паке-
та этому узлу. Такой узел называют хопом (от англ, hop — пры-
жок, скачок). Действительно, передача пакета по составной сети
происходит своего рода скачками от маршрутизатора к маршру-
тизатору.
Информация, ставящая в соответствие конечному адресу на-
значения пакета адрес маршрутизатора, на который нужно даль-
ше отправить пакет для достижения адреса назначения, хранится
в специальной таблице маршрутов (табл. 3.1), которая размещает-
ся на маршрутизаторе.
Запись таблицы маршрутов обычно содержит следующие эле-
менты:
• поле, содержащее адрес сети назначения;
• поле, содержащее адрес следующего по ходу следования па-
кета маршрутизатора;
• вспомогательные поля.
В зависимости от используемого алгоритма маршрутизации
таблица маршрутов может заполняться вручную администрато-
ром либо посредством специальных протоколов сбора маршрут-
ной информации.
При этом своя таблица маршрутов, даже самая элементарная,
должна быть на каждом хосте.
Чтобы информация о маршрутах оставалась актуальной и со-
ответствовала действительно существующим маршрутам, мар-
144
Глава 3. Организация межсетевого взаимодействия
Таблица 3.1. Пример таблицы маршрутов программного маршрутизатора операцион-
ной системы Windows ХР
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метри ка
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.167 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.167 192.168.0.167 20
192.168.0.167 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.0.255 255.255.255.255 192.168.0.167 192.168.0.167 20
224.0.0.0 240.0.0.0 192.168.0.167 192.168.0.167 20
255.255.255.255 255.255.255.255 192.168.0.167 192.168.0.167 1
шрутизаторы в процессе своей работы по специальным протоко-
лам обмениваются сообщениями, содержащими информацию об
обнаруженных изменениях в топологии сети, например в резуль-
тате разрыва какой-либо связи, а, следовательно, и об изменени-
ях в допустимых маршрутах. На основе таких сообщений маршру-
тизаторы производят обновления таблиц маршрутов.
Выбор того или иного маршрута из таблицы происходит на
основе применяемого данным маршрутизатором алгоритма мар-
шрутизации, базирующегося на различных критериях.
3.2.2. Алгоритмы маршрутизации
Алгоритмы маршрутизации могут различаться по нескольким
характеристикам:
• по задачам, решаемым алгоритмом;
• по принципу сбора и представления информации о сети;
• по методу расчета оптимального маршрута.
Кроме того, алгоритмы маршрутизации должны максимально
удовлетворять следующим требованиям:
• выбираемый маршрут должен быть наиболее оптимальным;
• реализация алгоритма должна быть простой, а его функцио-
нирование не требовательным к вычислительным мощностям;
• алгоритм должен обладать высокой отказоустойчивостью;
• адаптация работы алгоритма к изменяющимся условиям
должна происходить как можно быстрее.
3.2. Маршрутизация пакетов
145
Таким образом, алгоритмы маршрутизации можно классифи-
цировать следующим образом:
• по актуальности используемых маршрутов:
статические;
динамические;
• по принципу обмена маршрутной информацией:
состояния канала;
дистанционно-векторные.
• по количеству определенных маршрутов:
одномаршрутные;
многомаршрутные;
• по используемой структуре маршрутизации:
одноуровневые;
иерархические;
• по отношению к домену:
внутридоменные;
междоменные;
Статические алгоритмы маршрутизации основаны на ручном
составлении таблиц маршрутизации администратором сети и обыч-
но применяются в небольших сетях с простой топологией связей.
В динамических или адаптивных алгоритмах таблицы мар-
шрутизации, и соответственно, сами маршруты постоянно обнов-
ляются в соответствии с меняющейся топологией сети.
Алгоритмы состояния канала отличаются от дистанцион-
но-векторных в зависимости от того, куда и какая маршрутная
информация рассылается. Рассылка маршрутной информации
необходима для синхронизации таблиц маршрутов на всех мар-
шрутизаторах сети. Алгоритмы состояния каналов рассылают об-
новленную маршрутную информацию небольшими порциями по
всем направлениям. Дистанционно-векторные алгоритмы обме-
ниваются сообщениями, содержащими большие объемы инфор-
мации, однако обмен происходит только с соседними маршрути-
заторами.
Различные алгоритмы могут определять один или несколько
маршрутов для достижения какого-либо узла или подсети. В мно-
гомаршрутных алгоритмах каждому из возможных маршрутов
в зависимости от его пропускной способности и других показате-
лей назначается приоритет, на основании которого происходит
выбор пути пересылки пакета. При этом обычно один маршрут
является основным, а остальные — резервными.
146
Глава 3. Организация межсетевого взаимодействия
Одноуровневые и иерархические алгоритмы работают в соот-
ветствующих системах маршрутизации. При этом в одноуровне-
вой системе все маршрутизаторы равноправны по отношению
друг к другу. Иерархическая маршрутизация основывается на раз-
биении большой сети на иерархически организованные подсети
с собственной маршрутизацией внутри каждого уровня.
Системы маршрутизации могут обеспечивать выделение ло-
гических групп узлов, называемых доменами или областями. При
этом отдельные алгоритмы маршрутизации могут действовать
только в пределах доменов, другие же могут работать как в преде-
лах доменов, так и между ними.
Для определения оптимальности того или иного маршрута ал-
горитмы используют показатели, характеризующие передачу дан-
ных по этому маршруту, например с точки зрения длины маршру-
та, качества канала связи и т. п. Такие показатели называются
метриками маршрутов.
Более сложные алгоритмы в качестве метрик зачастую ис-
пользуют комбинацию нескольких показателей.
Наиболее распространенными метриками, используемыми
в алгоритмах маршрутизации, являются:
• длина маршрута — обычно это количество хопов, т. е. коли-
чество маршрутизаторов, через которые пакет должен прой-
ти на пути к адресату;
• надежность — степень отказоустойчивости канала связи
либо соотношение возникающих ошибок к общему числу
бит, передаваемых по этому каналу;
• ширина полосы пропускания — характеризуется пропуск-
ной способностью канала связи;
• задержка — время продвижения пакета от источника до
пункта назначения с учетом загруженности сети, времени
ожидания в очереди на обработку на маршрутизаторах;
• физическое расстояние между узлами;
• стоимость связи и т. д.
3.2.3. Протоколы обмена маршрутной информацией
Для отслеживания изменений в топологии связей сети, изме-
нений в существующих маршрутах и синхронизации таблиц мар-
3.2. Маршрутизация пакетов
147
шрутизации среди маршрутизаторов и узлов сети используются
протоколы обмена маршрутной информацией.
При этом эти протоколы могут основываться на дистанцион-
но-векторных алгоритмах, примером использования которых яв-
ляется протокол RIP, имеющий реализации для работы в различ-
ных стеках протоколов, таких, как TCP/IP или IPX/SPX, или на
алгоритмах состояния связей, например как протоколы IS-IS сте-
ка OSI, NLSP стека IPX/SPX, OSPF стека TCP/IP.
Дистанционно-векторный протокол
Самым распространенным протоколом обмена маршрутной
информацией, основанным на алгоритме дистанционно-вектор-
ного типа, является протокол RIP (Routing Information Proto-
col) — протокол маршрутной информации.
В качестве метрик различные реализации протокола RIP ис-
пользуют широкий спектр показателей, таких, как пропускная
способность, задержки, надежность каналов связи, однако наибо-
лее распространенной в протоколах данного типа является метри-
ка, учитывающая количество хопов.
RIP применяется в сравнительно небольших и относительно
однородных сетях, где расстояние между двумя любыми узлами
не должно превышать 15 хопов.
Для определения оптимального маршрута до требуемого узла
данный протокол использует дистанционно-векторный алгоритм
Беллмана-Форда.
Процесс работы протокола состоит в рассылке, получении
и обработке векторов расстояний до сетей, находящихся в облас-
ти действия протокола, т. е. в данной RIP-системе.
Результатом работы протокола на каждом конкретном мар-
шрутизаторе является таблица маршрутов, где каждой сети дан-
ной RIP-системы соответствует расстояние до этой сети, выра-
женное посредством метрики (например, в хопах), а также адрес
следующего маршрутизатора, на который необходимо направлять
пакеты для достижения ими заданного адреса.
При этом информация о номере сети и адресе следующего
маршрутизатора, хранящаяся в таблице, необходима для комму-
тации, т. е. пересылки поступающих пакетов, а информация
о расстоянии до сети — метрика — используется при обработке
векторов расстояний.
148
Глава 3. Организация межсетевого взаимодействия
Рис. 3.2. Пример RlP-системы
Вектором расстояний при этом
называется совокупность пар значе-
ний: идентификатор сети — расстоя-
ние до этой сети.
Маршрутизаторы, работающие
в RIP-системе, периодически произ-
водят широковещательную рассылку
своих векторов расстояний, постро-
енных на основе записей таблицы
маршрутов, во все сети, к которым
эти маршрутизаторы непосредствен-
но подключены.
Получив чужой вектор расстояний, маршрутизатор увеличи-
вает расстояние на единицу, после этого сравнивает с данными из
своей таблицы маршрутов. Если расстояние до какой-либо сети,
увеличенное на единицу, в полученном векторе меньше, чем рас-
стояние до этой же сети, указанное в таблице маршрутов, то про-
исходит замена записи таблицы значениями, полученными в век-
торе расстояний. При этом в поле, содержащем адрес следующего
маршрутизатора, записывается адрес маршрутизатора, прислав-
шего данный вектор расстояний.
В следующий раз при широковещательной рассылке в сеть
будет передан уже вектор расстояний, построенный на основе из-
мененной таблицы маршрутов.
Если представить составную сеть упрощенно в виде графа
(рис. 3.2), то подсети будут ребрами этого графа, а соединяющие
их маршрутизаторы — вершинами.
В исходном состоянии маршрутизаторы имеют информацию
только о тех сетях, к которым они непосредственно подключены.
При этом таблица маршрутов, например маршрутизатора Ml, мо-
жет выглядеть примерно так (табл. 3.2).
Таблица 3.2. Таблица маршрутов Ml (состояние 0)
Сеть назначения Расстояние до сети Следующий маршрутизатор
А 1 Ml
В 1 Ml
F 1 Ml
3.2. Маршрутизация пакетов
149
Таблица 3.3. Таблица маршрутов М5
Сеть назначения Расстояние до сети Следующий маршрутизатор
С 1 М5
В 1 М5
Таблицы маршрутов других маршрутизаторов будут выглядеть
аналогично, например для маршрутизатора М5 см. табл. 3.3.
После подачи питания на маршрутизаторы и их инициализа-
ции они начинают широковещательную рассылку своих векторов
расстояний. При этом маршрутизатор Ml будет рассылать вектор
типа:
• сеть А, расстояние 1;
• сеть В, расстояние 1;
• сеть F, расстояние I,
который получат маршрутизаторы М2, М3 и М4. Эти маршрути-
заторы также будут рассылать свои векторы расстояний. Маршру-
тизатор Ml, получив эти векторы, увеличивает в них каждое рас-
стояние на единицу и запоминает, от какого маршрутизатора по-
лучен тот или иной вектор.
Допустим, что первым пришел вектор расстояний с маршру-
тизатора М3. Ml увеличивает все расстояния этого вектора на
единицу и сравнивает с записями из своей таблицы маршрутов.
Протокол RIP меняет запись в таблице маршрутов о какой-либо
сети только в том случае, если расстояние до этой сети, указанное
в полученном векторе, меньше, чем то, что содержится в этой
таблице. Сведения о сетях Е и G в таблице не содержатся, поэто-
му в нее необходимо эти сведения добавить. При этом идентифи-
каторы сетей и расстояния до них берутся из полученного вектора
расстояний, а в качестве адреса следующего маршрутизатора за-
писывается адрес маршрутизатора, приславшего этот вектор рас-
стояний, в данном случае это маршрутизатор М3. Расстояние до
сети F, указанное в векторе расстояний, больше, чем расстояние
в таблице маршрутов, поэтому эта запись игнорируется.
Таким образом, измененная таблица маршрутов Ml будет со-
держать следующие записи (табл. 3.4).
Аналогично, получив векторы расстояний от М2 и М4, мар-
шрутизатор Ml обрабатывает пришедшие сведения и в соответст-
вии с ними обновляет свою таблицу маршрутов (табл. 3.5).
150
Глава 3. Организация межсетевого взаимодействия
Таблица 3.4. Таблица маршрутов Ml (состояние 1)
Сеть назначения Расстояние до сети Следующий маршрутизатор
А 1 Ml
В 1 Ml
Е 2 М3
F 1 Ml
G 2 М3
Таблица 3.5. Таблица маршрутов Ml (состояние 2)
Сеть назначения Расстояние до сети Следующий маршрутизатор
А 1 Ml
В 1 Ml
С 2 М2
D 2 М4
Е 2 М3
F 1 Ml
G 2 М3
Данные о сетях Е и G, полученные от маршрутизаторов М2
и М4 игнорируются, поскольку в таблице МI уже содержаться за-
писи об этих сетях, пришедшие ранее от маршрутизатора М3
и имеющие значения расстояний, равные двум, т. е. являющиеся
равнозначными по отношению к полученным позднее.
Аналогичным образом происходят обновления таблиц мар-
шрутов и на других маршрутизаторах. Внеся изменения в табли-
цу, каждый маршрутизатор снова рассылает вектор расстояний,
который уже содержит обновленные данные.
При приеме таких векторов процесс их обработки не меняет-
ся: маршрутизатор увеличивает все содержащиеся в векторах рас-
стояния на единицу, после этого сравнивает их с теми, что хра-
нятся в его таблице маршрутов, которая может корректироваться
в соответствии с результатами сравнения.
На каждом маршрутизаторе для каждой записи в таблице мар-
шрутов определено время жизни. Если в течение 180 секунд мар-
3.2. Маршрутизация пакетов
151
шрутизатор не получает векторов, подтверждающих или устанав-
ливающих новое значение расстояния до сети, которой соответст-
вует данная запись, то такая сеть отмечается как недостижимая —
расстояние до нее приравнивается 16. Спустя некий промежуток
времени все записи о недостижимых сетях из таблицы маршрутов
удаляются.
В ходе обмена векторами расстояний и корректировки на их
основе таблиц маршрутов наступает момент, когда в отсутствие
каких-либо нарушений в топологии RIP-системы никакие векто-
ры расстояний уже больше не внесут изменений ни в одну из таб-
лиц. При этом между двумя любыми узлами определен некий оп-
тимальный маршрут.
Однако периодический обмен маршрутной информацией ме-
жду маршрутизаторами по-прежнему необходим для оперативно-
го и своевременного реагирования на изменения в топологии се-
ти, например как в результате появления новых или обрывов су-
ществующих соединений, так и в результате отключения или
включения в сеть дополнительных маршрутизаторов.
Появление новых маршрутов практически не нарушает работу
сети. Информация о новом маршруте в ходе работы протокола
RIP распространяется среди маршрутизаторов, которые с учетом
этой информации обновляют свои таблицы маршрутов.
Изменение топологии сети в результате разрыва соединения
в этой сети, отключения или выхода из строя маршрутизатора об-
рабатывается по аналогичному принципу.
Например, если соединение маршрутизатора Ml с сетью F
окажется по каким-либо причинам нарушенным (рис. 3.3), то
маршрутизатор, обнаружив эти изме-
нения, изменит свою таблицу мар-
шрутов.
Расстояние до сети F, а также до
всех сетей, доступных через F, будет
равно 16. Поскольку расстояние ме-
жду двумя любыми узлами RIP-сис-
темы не должно превышать 15 хо-
пов, то расстояние, равное 16 хопам,
будет соответствовать бесконечно-
сти, ЧТО говорит О ТОМ, ЧТО сеть не- Рис. 3.3. Пример RIP-системы
доступна.
(обрыв связи с F)
152
Глава 3. Организация межсетевого взаимодействия
Таблица 3.6. Таблица маршрутов Ml (состояние 3)
Сеть назначения Расстояние до сети Следующий маршрутизатор
А 1 Ml
В 1 Ml
С 2 М2
D 2 М4
Е 16 М3
F 16 Ml
G 16 М3
Таким образом, таблица маршрутов Ml будет выглядеть сле-
дующим образом (табл. 3.6).
На основании табл. 3.6 строится вектор расстояний, который
рассылается в сеть маршрутизатором Ml, чтобы другие маршру-
тизаторы, пересылающие пакеты через М1 в ставшие недоступ-
ными сети, изменили свои таблицы маршрутов.
Поскольку процесс обмена сообщениями, содержащими век-
торы расстояний, идет постоянно, то спустя какое-то время мар-
шрутизатор Ml получит векторы расстояний М2 и М4
Маршрутизатор М2:
сеть А, расстояние I;
сеть В, расстояние 2;
сеть С, расстояние 1;
сеть D, расстояние 2;
сеть Е, расстояние 1;
сеть F, расстояние 16;
сеть G, расстояние 2;
Маршрутизатор М4:
сеть А, расстояние 2;
сеть В, расстояние I;
сеть С, расстояние 2;
сеть D, расстояние 1;
сеть Е, расстояние 2;
сеть F, расстояние 2;
сеть G, расстояние 1.
Сравнив данные этих векторов, увеличенные на единицу,
с данными своей таблицы маршрутов, М1 обнаружит, что сущест-
вуют маршруты до сетей F, Е и G, имеющие лучшую метрику, не-
жели 16. Изменив соответственно записи таблицы маршрутов,
М1 определит новые «обходные» маршруты к ставшим недоступ-
ными ему в результате разрыва соединения сетям.
При этом таблица маршрутов М1 будет выглядеть так (табл. 3.7).
3.2. Маршрутизация пакетов
153
Таблица 3.7. Таблица маршрутов М1 (состояние 4)
Сеть назначения Расстояние до сети Следующий маршрутизатор
А 1 Ml
В 1 Ml
С 2 М2
D 2 М4
Е 2 М2
F 3 М2
G 2 М4
Однако очень часто подобные изменения в топологии сети
приводят к возникновению сбоев и некорректной работе прото-
кола RIP.
Например, если после разрыва соединения маршрутизатора
Ml с сетью F, Ml не успел оповестить другие маршрутизаторы
о недоступности этой сети, то он получает вектор расстояний от
маршрутизатора М2, построенный на основе его таблицы мар-
шрутов (табл. 3.8).
Проанализировав полученный вектор, Ml определяет, что по-
лученная метрика расстояния до сети F лучше бесконечности,
и корректирует свою таблицу маршрутов (табл. 3.9).
Таблица 3.8. Таблица маршрутов Ml (состояние 5)
Сеть назначения Расстоян ие до сети Следующий маршрутизатор
А 1 М2
В 2 Ml
С 1 М2
D 2 М5
Е 1 М2
F 2 Ml
G 2 М3
154
Глава 3. Организация межсетевого взаимодействия
Таблица 3.9. Таблица маршрутов Ml (состояние 6)
Сеть назначения Расстоян не до сети Следующий маршрутизатор
А 1 Ml
В 1 Ml
С 2 М2
D 2 М4
Е 2 М2
F 3 М2
G 3 М2
Таким образом происходит зацикливание: чтобы достичь сети
F маршрутизатор Ml будет передавать пакеты маршрутизатору
М2, который в свою очередь на основе таблицы маршрутов будет
возвращать их обратно на Ml.
Еще одним примером некорректной работы RIP в результате
нарушения соединения в сети является так называемый «счет до
бесконечности». При этом маршрутизаторы последовательно об-
мениваются векторами, расстояние до недоступной сети в кото-
рых меньше 16. С каждым новым вектором это расстояние увели-
чивается на единицу. Обмен векторами, содержащими сведения
о несуществующем маршруте, продолжается до тех пор, пока
в таблицах маршрутов всех маршрутизаторов сети метрика этого
маршрута не будет равна 16.
Таким образом, разрыв соединения с одной из сетей обнару-
живается не сразу, а спустя некоторое время, в течение которого
считается, что вся составная сеть функционирует нормально.
Существует несколько различных способов снизить вероят-
ность некорректной работы протокола RIP.
Для устранения вероятности появления зацикливания обыч-
но используют некоторые ограничения на то, как и куда маршру-
тизаторы должны рассылать свои векторы расстояний.
Например, маршрутная информация, хранящаяся в таблице
на одном из маршрутизаторов, при рассылке векторов расстоя-
ний ни в коем случае не должна быть передана на тот же маршру-
тизатор, с которого она была получена.
3.2. Маршрутизация пакетов
155
Кроме того, зачастую используются специальные задержки,
влияющие на то, когда маршрутизатор может передать в сеть ин-
формацию об изменении, например, расстояния до какой-либо
сети и на то, когда маршрутизатор, получивший эту информа-
цию, может внести изменения в свою таблицу маршрутов.
Для стека протоколов TCP/IP существует две версии реализа-
ции RIP. В отличие от первой, вторая версия RIP имеет возмож-
ность передачи информации о масках сетей, использовании ау-
тентификации RIP-сообшений, а также некоторые другие улуч-
шения.
Для обмена своими сообщениями между узлами сети RIP ис-
пользует протокол UDP. Существует два типа RIP-сообшений
(рис. 3.4) — запрос и ответ.
Посредством сообщения «запроса» маршрутизаторы запра-
шивают друг у друга сведения маршрутных таблиц.
Сообщение «ответ» представляет собой вектор расстояний,
рассылаемый маршрутизатором по широковещательному адресу.
Формат сообщения протокола RIP версии 1 состоит из сле-
дующих полей:
• команда — определяет тип сообщения: 1 — запрос, 2 — от-
вет;
• версия — соответственно версия протокола RIP;
• идентификатор семейства адресов — в реализации для стека
TCP/IP содержит значение 2, обозначающее IP-адреса;
• IP-адрес — адрес сети назначения;
• метрика — содержит метрику, обычно характеризующую
расстояние до сети назначения.
Рис. 3.4. Формат сообщения протокола RIP
156
Глава 3. Организация межсетевого взаимодействия
7 15 23 I 31
Команда Версия Домен маршрутизации
Идентификатор семейства адресов
Маршрутная метка
IP-адрес
Маска подсети
Следующий маршрутизатор
Метрика
Рис. 3.5. Формат сообщения протокола RIP второй версии
При этом поля, следующие после первых четырех байтов со-
общения, представляют собой элементы вектора расстояний, со-
держащие адрес сети назначения, ее метрику, а также некоторую
служебную информацию. Каждый элемент имеет длину в 20 байт
и в одном RIP-сообщении их может быть до 25.
В версии 2 в RIP-сообшение (рис. 3.5) добавляется еще не-
сколько полей:
• домен маршрутизации — идентификатор данной RIP-систе-
мы;
• маршрутная метка — используется при работе с протокола-
ми внешней маршрутизации;
• маска подсети — значение маски подсети назначения;
• следующий маршрутизатор — указывает адрес следующего
маршрутизатора для пересылки пакета в том случае, если
его адрес должен отличаться от адреса маршрутизатора,
приславшего это сообщение.
Протокол состояния связей
Протокол OSPF (Open Shortest Path First — «найди кратчай-
ший путь первым») является примером протокола, основанного
на использовании алгоритма состояния связей (рис. 3.6).
OSPF используется для внутренней маршрутизации в сетях
любой сложности. Метрика OSPF представляет собой оценку ка-
чества связи, обычно это пропускная способность данной сети.
Причем метрика маршрута составляет сумму метрик всех хопов
маршрута.
3.2. Маршрутизация пакетов
157
0 7 15 23 | 31
Версия Тип Длина пакета
Идентификатор маршрутизатора
Идентификатор области
Контрольная сумма Тип аутентификации
Аутентификация
Рнс. 3.6. Формат заголовка OSPF-сообшения
Рис. 3.7. Формат сообщения hello
Для определения наиболее оптимального маршрута каждый
маршрутизатор собирает информацию о топологии сети.
Первым делом, маршрутизаторы рассылают так называемые
сообщения hello (рис. 3.7), необходимые для обнаружения сосе-
дей, т. е. соседних подключенных к одной и той же подсети мар-
шрутизаторов. Получив сообщение hello, маршрутизатор должен
послать сообщение типа hello в ответ.
Поле обнаружения соседей маршрутизаторы обмениваются
сведениями об известных им соединениях. При этом маршрути-
заторы не изменяют эту информацию, а передают ее такой,
какой получили. В результате такого обмена все маршрутизато-
ры OSPF-системы получают практически одинаковые сведения
158
Глава 3. Организация межсетевого взаимодействия
о топологии сети. Таким образом, на каждом маршрутизаторе
постепенно строится база данных состояния связей, представ-
ляющая собой описание графа связей всей OSPF-системы.
Обмен маршрутизаторов сведениями об известных им соеди-
нениях подразумевает синхронизацию имеющихся у них баз дан-
ных состояния связей. Первым шагом соседние маршрутизаторы
обмениваются сообщениями, содержащими описания их баз дан-
ных, а точнее идентификаторы записей и их версии. Это позволя-
ет отказаться от пересылки всей базы данных целиком, что дает
возможность снизить излишнюю загрузку сети.
После обмена информацией о базах данных маршрутизаторы
могут определить, записей о каких связях им не хватает. Эти записи
запрашиваются у маршрутизатора-соседа посредством специально-
го сообщения «запрос о состоянии связей». В ответ маршрутиза-
тор-сосед посылает сообщение «обновление состояния связей».
Для поиска кратчайшего пути в графе связей сети применяет-
ся алгоритм Дейкстры. Таким образом, кратчайший путь в графе
будет соответствовать наиболее оптимальному маршруту пере-
сылки пакета по сети. Каждый маршрутизатор ищет оптимальные
маршруты до каждой известной ему сети. Определив такой мар-
шрут, маршрутизатор помещает в свою таблицу маршрутов адрес
сети назначения и адрес маршрутизатора, на который следует пе-
ресылать пакет, адресованный в эту сеть.
При этом маршрутизатор, работающий по протоколу OSPF,
может хранить информацию одновременно о нескольких мар-
шрутах, ведущих к одной и той же сети. Иногда маршрутизатору
может быть назначен некоторый приоритет, который оказывает
влияние на выбор того или иного маршрута.
В ходе дальнейшей работы OSPF-маршрутизаторы периоди-
чески обмениваются сообщениями hello, контролируя тем самым
состояния связей. При возникновении каких-либо изменений
в топологии сети маршрутизатор, обнаруживший эти изменения,
также рассылает сообщение «обновление состояния связей», опо-
вещая тем самым все остальные маршрутизаторы.
Получение этих сообщений маршрутизаторами подтвержда-
ется в свою очередь сообщениями «подтверждение состояния
связей». Обновив базы данных, маршрутизаторы вынуждены за-
ново выбрать оптимальные маршруты до каждого узла сети вме-
сто тех маршрутов, которые были затронуты изменениями в топо-
логии сети.
3.2. Маршрутизация пакетов
159
Протокол OSPF обладает довольно высокой степенью вычис-
лительной сложности, растущей с увеличением числа маршрути-
заторов и связей и, соответственно, числа маршрутов, которые
нужно проанализировать.
Для упрощения вычислений, связанных с нахождением опти-
мального маршрута, а также для уменьшения размеров базы дан-
ных, которую должны хранить маршрутизаторы, OSPF-систему
часто делят на отдельные независимые области. При этом каждая
область представляет подобие самостоятельной OSPF-системы,
базы данных которой содержат сведения о состоянии связей толь-
ко внутри данной области. Взаимодействие между областями осу-
ществляется пограничными маршрутизаторами, способными ра-
ботать сразу с несколькими базами данных, принадлежащими
подключенным к ним областям.
Все OSPF-сообщения имеют одинаковый заголовок (см.
рис. 3.6) содержащий следующие поля:
• версия — соответствует версии протокола;
• тип — характеризует тип сообщения;
• длина пакета — содержит длину всего сообщения в байтах;
• идентификатор маршрутизатора — определяет маршрутиза-
тор, отправивший это сообщение;
• идентификатор области — определяет область, к которой
относится это сообщение;
• контрольная сумма — контрольная сумма, вычисленная для
всего сообщения целиком;
• тип аутентификации — соответственно тип аутентификации
этого сообщения (0 — аутентификация отсутствует, 1 — ис-
пользуется пароль);
• аутентификация — данные для аутентификации (например,
пароль).
Существует пять типов OSPF-сообщений:
1) hello;
2) описание базы данных (Database Description);
3) запрос о состоянии связей (Link State Request);
4) обновление состояния связей (Link State Update);
5) подтверждение состояния связей (Link State Acknowledg-
ment).
Формат тела сообщений различается в зависимости от типа
сообщения, т. е. от выполняемых этим сообщением функций.
160
Глава 3. Организация межсетевого взаимодействия
Например, сообщение первого типа, т. е. сообщение hello
(см. рис. 3.7), содержит следующие поля:
• маска подсети — значение маски подсети, в которой нахо-
дится маршрутизатор, отправивший это сообщение;
• интервал между hello — временной интервал между посыл-
ками сообщения hello;
• опции — данное поле используется для согласования рабо-
ты соседних маршрутизаторов;
• приоритет — определяет приоритет маршрутизатора, по-
славшего это сообщение;
• время отключения — временной интервал, в течение кото-
рого от маршрутизатора-соседа ожидается сообщение hello,
если сообщение так и не пришло, то маршрутизатор счита-
ется отключенным;
• выделенный маршрутизатор — идентификатор маршрутиза-
тора, используемого для синхронизации базы данных со-
стояния связей, а также для рассылки широковещательных
сообщений об обнаруженных изменениях в топологии сети;
• запасной выделенный маршрутизатор — соответственно
идентификатор запасного выделенного маршрутизатора;
• сосед — содержит адрес маршрутизатора, от которого было
получено сообщение hello, за интервал времени после вклю-
чения маршрутизатора.
OSPF-маршрутизаторы способны работать с маршрутизатора-
ми, использующими другие протоколы, например протокол RIP,
что делает реальным их использование при объединении разно-
родных сетей.
С точки зрения возможности быстро и без ошибок адаптиро-
ваться к изменившейся структуре сети протокол OSPF значитель-
но превосходит протокол RIP. При отказе какого-либо соедине-
ния OSPF-системы зацикливания пакетов не происходит, т. е.
сеть не «засоряется» пакетами, которые нельзя доставить по на-
значению.
3.3. Фильтрация пакетов
Фильтрация пакетов — это избирательное управление потока-
ми входящих или исходящих пакетов, основанное на анализе за-
головка каждого пакета.
3.4. Маршрутизатор
161
Фильтр пакетов (или па-
кетный фильтр) выполняет
функцию разграничения до-
ступа узлов одного сегмента
сети к отдельному узлу или
множеству узлов другого сег-
мента компьютерной сети.
Наиболее часто фильтры па-
кетов используют, чтобы от-
делить, например, небольшую
локальную сеть или сервер от
более крупной сети (рис. 3.8),
например сети Интернет.
На основе анализа сведе-
ний, полученных из заголов-
ков поступающих на фильтр
пакетов, в соответствии с оп-
ределенными правилами и на-
стройками принимается реше-
Локальная сеть
Рис. 3.8. Защита локальных сетей от дос-
тупа из внешней сети посредством сете-
вого фильтра
ние о дальнейшей судьбе этих пакетов. Они могут быть отброшены,
т. е. уничтожены; приняты, при этом пакеты проходят через фильтр
и направляются далее по своим маршрутам; или отклонены — такие
пакеты попросту отвергаются, однако об этом уведомляется отпра-
витель этих пакетов. Фильтрация пакетов подразумевает выбор
и осуществление одного из этих действий.
Ограничение доступа, достигаемое при использовании пакет-
ных фильтров, является одним из методов защиты узлов и распо-
ложенных на них ресурсов локальной сети от несанкционирован-
ного доступа к ним из внешней сети. В зависимости от ресурсов
и того, кому они принадлежат, целью попыток получить незакон-
ный доступ может быть как элементарное компьютерное хулиган-
ство или вандализм, так и стремление завладеть информацией,
представляющей коммерческую тайну, промышленный шпио-
наж, попытки саботажа работы той или иной организации.
3.4. Маршрутизатор
Маршрутизатор — устройство, обеспечивающее взаимодейст-
вие между локальными сетями. Маршрутизаторы, как и мосты
или коммутаторы, способны ретранслировать пакеты из одной
162
Глава 3. Организация межсетевого взаимодействия
подсети в другую. Однако работа маршрутизаторов основана на
использовании не физических, а логических сетевых адресов (на-
пример, IP-адресов). При этом ретрансляции подлежат только те
пакеты, которые адресованы в ту или иную подсеть, к которой
данный маршрутизатор подключен. Кроме того, маршрутизаторы
позволяют строить сети, имеющие петли, т. е. более одного пути
возможного следования пакета от одного узла сети к другому. Не-
сколько путей позволяют повышать пропускную способность се-
ти, а также служат резервными каналами передачи данных на слу-
чай выхода из строя основных. При этом маршрутизатор отвечает
за выбор маршрута.
Повторители и концентраторы дублируют поступающие на
них пакеты — данную работу можно охарактеризовать как соот-
ветствующую первому физическому уровню модели OSL
Мосты и коммутаторы ретранслируют из одного сегмента
в другой только межсегментные и широковещательные пакеты —
второй, канальный уровень модели OSL
Маршрутизаторы позволяют обеспечить взаимодействие меж-
ду двумя практически независимыми сетями, которые могут быть
построены на основе различных базовых технологий, и использо-
вать разные стеки протоколов. Таким образом, можно сказать,
что маршрутизаторы функционируют на третьем, сетевом уровне
модели OSI.
Основные функции, выполняемые маршрутизатором, можно
разделить в соответствии с уровнями модели OSI на:
• сетевой:
— создание и ведение таблицы маршрутизации;
— определение маршрута по таблице маршрутизации;
— анализ информации из заголовка сетевого уровня пакета,
изменение этого заголовка при необходимости (время
жизни пакета и т. п.);
— фильтрация пакетов;
— проверка контрольной суммы пакетов, отбрасывание па-
кетов, содержащих ошибки;
— буферизация пакетов, управление очередями пакетов;
• канальный:
— инкапсуляция пакетов сетевого уровня в кадры канально-
го уровня при передаче пакетов, обратный процесс при их
приеме и обработке;
3.4. Маршрутизатор
163
— преобразование адреса следующего маршрутизатора или
узла назначения из сетевого в физический;
• физический:
— обеспечение интерфейса со средой передачи данных;
— прием и передача кадров.
Маршрутизаторы применяются для объединения нескольких
локальных сетей в единую составную сеть либо же, наоборот, для
разграничения большой сети на несколько независимых малых
подсетей.
Маршрутизаторы применяются для объединения разнород-
ных сетей как локальных, так и глобальных. Например, для со-
единения локальной сети с глобальной сетью, такой как Интер-
нет, или для объединения сетей, работающих на различных ско-
ростях передачи данных, например Ethernet и Fast Ethernet.
Немаловажным является тот факт, что маршрутизаторы позво-
ляют сделать невидимыми сетевые адреса узлов локальной сети из
внешней сети, подменяя их своим адресом. Такой прием использу-
ется как мера безопасности, усложняющая несанкционированное
проникновение в «скрытую» с помощью маршрутизатора сеть,
и как мера, позволяющая увеличить адресное пространство, по-
скольку адреса внутри локальных сетей, можно сказать, не сущест-
вуют для внешней глобальной сети и могут совпадать. Такое со-
крытие называется трансляцией сетевых адресов.
В зависимости от областей применения и функциональной
сложности маршрутизаторы могут быть как программными, так
и аппаратными. При этом маршрутизаторы делятся на несколько
классов.
Первый класс — магистральные маршрутизаторы, применяе-
мые для сетей операторов связи и провайдеров сетевых услуг.
Для таких маршрутизаторов характерны очень высокий уровень
производительности, а также наличие мощных средств обеспе-
чения отказоустойчивости, причем как отдельного узла, так
и всей сети в целом, использование сверхскоростных интерфей-
сов (10—40 Гбит/с).
Второй класс — маршрутизаторы корпоративных сетей, ис-
пользуемые как в этих сетях, так и для подключения к каналам
операторов связи. Характеристики данного класса гораздо скром-
нее, однако функциональные возможности оказываются зачас-
тую более широкими, так в маршрутизаторах данного класса час-
164
Глава 3. Организация межсетевого взаимодействия
то бывает реализована поддержка разнообразных телефонных
стандартов связи.
Третий класс — маршрутизаторы локальных сетей, ориенти-
рованные на использование в небольших компаниях или в не-
больших домашних сетях пользователей. Такие маршрутизаторы
достаточно просты в настройке и являются сравнительно недоро-
гими. Кроме того, маршрутизаторы этого класса часто снабжают-
ся дополнительными возможностями, такими как встроенные
серверы печати или точки беспроводного доступа.
3.5. Сетевой шлюз
Сетевым шлюзом (networking gateway или просто gateway) на-
зывают аппаратное или программное обеспечение либо их ком-
бинацию, обеспечивающую передачу данных между несовмести-
мыми прикладными программами или между сетями, использую-
щими различные протоколы.
Подобно шлюзам на космическом корабле или на подводной
лодке, которые обеспечивают безопасный переход из одной фи-
зической среды в другую, сетевые шлюзы обеспечивают передачу
информации из одной сети в другую. Если эти сети оказываются
гетерогенными, то информацию недостаточно просто передать,
ее необходимо преобразовать к виду, используемому в сети, куда
эта информация направляется.
Обычно сетевым шлюзом называют устройство, объединяю-
щее, прежде всего, именно разнородные сети или системы, для
обеспечения взаимодействия которых требуется преобразование
передаваемой информации.
Например, сетевыми шлюзами третьего или сетевого уровня
называют маршрутизаторы, объединяющие две или больше сетей
и способные согласовать их работу, т. е. обеспечить «шлюзова-
ние» передаваемой между сетями информации — преобразование
поступающих из одной сети пакетов в пакеты, совместимые
с другой сетью и способные в ней обращаться.
Сетевыми шлюзами прикладного уровня модели OSI называ-
ют прокси-серверы (proxy-server, от англ, proxy — уполномочен-
ный, заместитель, доверенное лицо, передача полномочий).
Прокси-сервер — отдельный узел сети с установленным на
нем программным обеспечением, который специализируется на
3.6. Брандмауэр
165
обработке запросов пользовательских приложений, направлен-
ных серверам, расположенным в сети, а также сохраняет получен-
ные на эти запросы ответы, что позволяет при повторном запросе
выдать пользователю ответ немедленно, не дожидаясь прихода
результата с сервера внешней сети. Все потоки информации от
приложений до запрашиваемых ими серверов проходят через
прокси-сервер.
Прокси-сервер является своего рода «заместителем» или «до-
веренным лицом», т. е. осуществляет запрос к нужному вам сер-
веру от своего имени, тем не менее возвращая полученные ре-
зультаты вам. Другими словами, прокси-сервер выступает в роли
посредника между пользователями локальной сети и запрашивае-
мыми ими сетевыми сервисами, находящимися во внешней сети.
Он запрашивает и собирает из внешней сети информацию, нуж-
ную пользователям, а пользователи получают эту информацию
с данного прокси-сервера.
При этом прокси-сервер выполняет функции сетевого шлюза,
преобразуя запросы и сообщения в зависимости от требований
совместимости различных приложений и сетевых сервисов.
3.6. Брандмауэр
Брандмауэр (от нем. brandmauer) — это устаревшее название
защитной противопожарной стены, которая на английском языке
называется файерволом (firewall).
В сфере компьютерных технологий брандмауэром или файер-
волом называют некий комплекс программных й/или аппаратных
средств, позволяющий разделить сеть на две или более частей
и обеспечить между ними сетевое взаимодействие, основанное на
наборе правил, определяющих условия прохождения информа-
ции из одной части в другую. Брандмауэр, работающий в сети, по
сути, является той же стеной, защищающей только не от огня,
а от любых нежелательных воздействий, способных нанести вред
или ущерб пользователям сети, а также хранящейся в этой сети
информации. Другими словами, брандмауэр — это пакетный
фильтр, обычно достаточно сложный и обеспеченный широкими
функциональными возможностями. Брандмауэр также можно на-
звать и своего рода сетевым шлюзом, поскольку он обеспечивает
информационное взаимодействие между отдельными сетями.
166
Глава 3. Организация межсетевого взаимодействия
Таблица 3.10. Основные функции элементов сетевого управления
Уровень модели OSI Название Основная функция
7 Прокси-сервер Выполнение роли посредника при пере- сылке запросов от пользовательских при- ложений к сетевым серверам и получении ответов на эти запросы
3-7 Брандмауэр, файервол, сетевой фильтр Управление информационными потоками в соответствии со специально определен- ными правилами
3-7 Сетевой шлюз Согласование разнородных сетей
3 Маршрутизатор Маршрутизация пакетов
2 Мост, коммутатор Коммутация пакетов — ретрансляция па- кетов в сегмент, где находится адрес их назначения
1 Повторитель, концентратор Повторение, ретрансляция пакетов из од- ного сегмента в другой
Функции брандмауэра может выполнять маршрутизатор,
шлюз, отдельный хост или группа хостов. Обычно брандмауэр
устанавливается на узлы, в том числе маршрутизаторы, соеди-
няющие локальную сеть с внешней сетью, например с Интерне-
том. Однако брандмауэр может также располагаться и на других
узлах сети, в случае, когда нужно защитить только часть узлов
этой сети или входящих в нее подсетей.
Набор функций и задач различных брандмауэров может очень
широко различаться, однако обшей является задача защитить
узел сети от негативных и нежелательных внешних воздействий,
а также оповестить пользователя о несанкционированных попыт-
ках передачи информации как из внешней сети на его рабочую
станцию, так и с рабочей станции во внешнюю сеть.
Брандмауэр инспектирует и фильтрует все проходящие через
него пакеты. Решение пропустить данный пакет или отбросить
принимается на основе специального набора правил. Правила
обычно прописываются при настройке брандмауэра, однако мо-
гут меняться в процессе его работы администратором сети.
Составление правил обработки пакетов заключается в опреде-
лении действий, которые необходимо проделать с пакетом в зави-
3.6. Брандмауэр
167
симости от типа пакета, адреса и порта назначения и источника
данного пакета, а также некоторых других параметров (например,
текущая дата или время).
Набор функций и задач, реализуемых на разных уровнях
модели OSI, приведен в табл. 3.10. Современные программ-
но-аппаратные комплексы, используемые в различных узлах
сети, позволяют интегрировать несколько функций в одном
устройстве, это повышает надежность сети и облегчает ее на-
стройку и управление.
Контрольные вопросы
1. Какие методы применяются для согласования протоколов, принад-
лежащих разным стекам?
2. Какие основные задачи решает маршрутизация пакетов?
3. Какая информация хранится в таблице маршрутов, размещаемой
в маршрутизаторе?
4. Может ли в таблице маршрутов быть несколько маршрутов для дос-
тижения какого-либо узла?
5. Назовите метрики, используемые в алгоритмах маршрутизации.
6. Зачем маршрутизаторы, работающие в RIP-системе, производят
широковещательную рассылку своих векторов расстояний?
7. Поясните, как происходит изменение таблицы маршрутов при раз-
рыве соединения одного из портов.
8. Для чего OSPF-маршрутизаторы обмениваются сообщениями типа
hello?
9. Какие действия может совершить сетевой фильтр с входящими па-
кетами?
10. Перечислите основные функции маршрутизаторов.
11. В каком случае прокси-сервер может снизить внешний трафик
в сети?
12. В чем заключается главная функция брандмауэров?
лабораторный практикум
Лабораторная работа № 1
Аппаратные средства и оборудование ЛВС
Цель работы: ознакомиться с основными аппаратными сред-
ствами и оборудованием ЛВС.
Продолжительность работы — 4 ч.
Постановка задачи
Изучить следующие аппаратные средства и оборудование
ЛВС:
I. Виды кабелей для сетей (коаксиальный, неэкранированная
витая пара, оптоволокно).
2. Устройства соединения BNC, RJ-45, настенные и модуль-
ные розетки, терминаторы.
3. Элементы ЛВС: монтажные короба, патч-панели, патч-кор-
ды, абонентские шнуры.
4. Разделка кабеля UTP по стандартам TIA/EIA-568 А/В.
5. Варианты исполнения активных концентраторов (хабы,
коммутаторы, MAU).
Краткие теоретические сведения
Коаксиальные кабели
В начале развития локальных сетей коаксиальный кабель как
среда передачи был наиболее распространен. Он использовался
и используется преимущественно в сетях Ethernet и отчасти
ARCnet. Различают «толстый» и «тонкий» кабели.
«Толстый Ethernet», как правило, используется следующим
образом. Он прокладывается по периметру помещения или зда-
ния, и на его концах устанавливаются 50-омные терминаторы.
Из-за своей толщины и жесткости кабель не может подключаться
непосредственно к сетевой плате. Поэтому на кабель в нужных
Лабораторная работа № 1
169
местах устанавливаются переходники — «вампиры» — специаль-
ные устройства, прокалывающие оболочку кабеля и подсоеди-
няющиеся к его оплетке и центральной жиле. «Вампир» настоль-
ко прочно сидит на кабеле, что после установки его невозможно
снять без специального инструмента. К «вампиру», в свою оче-
редь, подключается трансивер — устройство, согласовывающее
сетевую плату и кабель. И наконец, к трансиверу подключается
гибкий кабель с 15-контактными разъемами на обоих концах —
вторым концом он подсоединяется к разъему AUI (attachment unit
interface) на сетевой плате.
Все эти сложности были оправданы только одним — допусти-
мая максимальная длина «толстого» коаксиального кабеля со-
ставляет 500 метров. Соответственно одним таким кабелем можно
обслужить гораздо большую площадь, чем «тонким» кабелем,
максимально допустимая длина которого составляет, как извест-
но, 185 метров. При наличии некоторого воображения можно
представить себе, что «толстый» коаксиальный кабель — это рас-
пределенный в пространстве Ethernet-концентратор, только пол-
ностью пассивный и не требующий питания. Других преиму-
ществ у него нет, недостатков же хоть отбавляй — прежде всего,
высокая стоимость самого кабеля (порядка 2,5 долл, за метр), не-
обходимость использования специальных устройств для монтажа
(25—30 долл, за штуку), неудобство прокладки и т. п. Это посте-
пенно привело к тому, что «толстый Ethernet» медленно, но верно
сошел со сцены, и в настоящее время мало где применяется.
«Тонкий Ethernet» распространен значительно шире, чем его
«толстый» собрат. Принцип использования у него тот же, но благо-
даря гибкости кабеля он может присоединяться непосредственно
к сетевой плате. Для подключения кабеля используются разъемы
BNC (bayonet nut connector), устанавливаемые собственно на ка-
бель, и Т-коннекторы (рис. Л 1.1),
служащие для отвода сигнала от ка-
беля в сетевую плату. Разъемы типа
BNC бывают обжимные и разбор-
ные (пример разборного разъема —
отечественный разъем СР-50-74Ф).
Для монтажа разъема на кабель
вам потребуется либо специальный
инструмент для обжимки, либо па-
яльник и плоскогубцы.
Рис. Л1.1. Т-коннектор
170
Лабораторный практикум
Кабель необходимо подготовить следующим образом:
1. Аккуратно отрежьте так, чтобы его торец был ровным. На-
деньте на кабель металлическую муфту (отрезок трубки), который
поставляется в комплекте с BNC-разъемом.
2. Снимите с кабеля внешнюю пластиковую оболочку на дли-
ну примерно 20 мм. Будьте аккуратны, чтобы не повредить по
возможности ни один проводник оплетки.
3. Оплетку аккуратно расплетите и разведите в стороны. Сними-
те изоляцию с центрального проводника на длину примерно 5 мм.
4. Установите центральный проводник в штырек, который
также поставляется в комплекте с разъемом BNC. Используя
специальный инструмент, надежно обожмите штырек, фикси-
руя в нем проводник, либо впаяйте проводник в штырек (в этом
случае надо снять изоляцию с центрального проводника на
длину примерно 10 мм). При пайке будьте особенно аккуратны
и внимательны — плохая пайка через некоторое время станет
причиной отказов в работе сети, причем локализовать это ме-
сто будет достаточно трудно.
5. Вставьте центральный проводник с установленным на него
штырьком в тело разъема до щелчка. Щелчок означает, что шты-
рек сел на свое место в разъеме и зафиксировался там.
6. Равномерно распределите проводники оплетки по поверх-
ности разъема, если необходимо, обрежьте их до нужной длины.
Надвиньте на разъем металлическую муфту.
7. Специальным инструментом (или плоскогубцами) аккурат-
но обожмите муфту до обеспечения надежного контакта оплетки
с разъемом. Не обжимайте слишком сильно — можно повредить
разъем или пережать изоляцию центрального проводника. По-
следнее может привести к неустойчивой работе всей сети. Но
и обжимать слишком слабо тоже нельзя — плохой контакт оплет-
ки кабеля с разъемом также приведет к отказам в работе.
Отметим, что отечественный разъем СР-50 монтируется при-
мерно так же, за исключением того, что оплетка в нем заделыва-
ется в специальную разрезную втулку и закрепляется гайкой.
В некоторых случаях это может оказаться даже удобнее.
Кабели на основе витой пары
Витая пара (unshielded/shielded twisted pair — UTP/STP) в на-
стоящее время является наиболее распространенной средой пе-
Лабораторная работа № 1
171
редачи сигналов в локальных
сетях. Кабели UTP/STP исполь-
зуются в сетях Ethernet, Token
Ring и ARCnet. Они различают-
ся по категориям (в зависимо-
сти от полосы пропускания)
и типу проводников (гибкие
или одножильные). В кабеле
5-й категории, как правило, на-
ходятся восемь проводников,
перевитых попарно (т. е. четыре
пары) (рис. Л 1.2).
Структурированная кабель-
ная система, построенная на
основе витой пары 5-й катего-
рии, имеет очень большую гиб-
кость в использовании. Ее идея
заключается в следующем.
На каждое рабочее место ус-
танавливается не менее двух (ре-
комендуется три) четырехпар-
ных розеток RJ-45 (рис. Л 1.3).
Каждая из них отдельным кабе-
лем 5-й категории соединяется
Рис. Л1.3. Розетка на 2 порта
с кроссом или патч-панелью, ус-
тановленной в специальном помещении, — серверной. В это поме-
щение заводятся кабели со всех рабочих мест, а также городские те-
лефонные вводы, выделенные линии для подключения к глобаль-
ным сетям и т. п. В помещении, естественно, монтируются серверы,
а также офисная АТС, системы сигнализации и прочее коммуника-
ционное оборудование.
Благодаря тому, что кабели со всех рабочих мест выведены на
общую панель, любую розетку можно использовать как для под-
ключения рабочего места к ЛВС, так и для телефонии или вообще
чего угодно. Допустим, две розетки на рабочем месте были под-
ключены к компьютеру и принтеру, а третья — к телефонной
станции. В процессе работы появилась необходимость убрать
принтер с рабочего места и установить вместо него второй теле-
фон. Нет ничего проще — патч-корд соответствующей розетки
отключается от концентратора и переключается на телефонный
172
Лабораторный практикум
Рис. Л1.4. Патч-панель
кросс, что займет у администратора сети никак не больше не-
скольких минут.
Патч-панель, или панель соединений (рис. Л 1.4), представля-
ет собой группу розеток RJ-45, смонтированных на пластине ши-
риной 19 дюймов. Это стандартный размер для универсальных
коммуникационных шкафов — рэков (rack), в которых устанав-
ливается оборудование (концентраторы, серверы, источники бес-
перебойного питания и т. п.). На обратной стороне панели смон-
тированы соединители, в которые монтируются кабели.
Кросс в отличие от патч-панели розеток не имеет. Вместо
них он несет на себе специальные соединительные модули.
В данном случае его преимущество перед патч-панелью в том,
что при его использовании в телефонии вводы можно соединять
между собой не специальными патч-кордами, а обычными про-
водами. Кроме того, кросс можно монтировать прямо на стену —
наличия коммуникационного шкафа он не требует. В самом де-
ле, нет смысла приобретать дорогостоящий коммуникационный
шкаф, если вся ваша сеть состоит из одного-двух десятков ком-
пьютеров и сервера.
Кабели с гибкими многожильными проводниками использу-
ются в качестве патч-кордов, т. е. соединительных кабелей между
розеткой и сетевой платой, либо между розетками на панели
соединений или кроссе. Кабели с одножильными проводниками
применяются для прокладки собственно кабельной системы.
Лабораторная работа № 1
173
а — заводская опресовка; б — разъем RJ-45
Монтаж разъемов и розеток на эти кабели совершенно иденти-
чен, но обычно кабели с одножильными проводниками монтиру-
ются на розетки рабочих мест пользователей, панели соединений
и кроссы, а разъемы устанавливают на гибкие соединительные
кабели.
Наиболее распространены следующие виды разъемов:
• S110 — общее название разъемов для подключения кабеля
к универсальному кроссу «НО» или коммутации между вво-
дами на кроссе;
• RJ-11 и RJ-12 — разъемы с шестью контактами. Первые
обычно применяются в телефонии общего назначения — вы
можете встретить такой разъем на шнурах телефонных аппа-
ратов. Второй обычно используется в телефонных аппара-
тах, предназначенных для работы с офисными мини-АТС,
а также для подключения кабеля к сетевым платам ARCnet;
• RJ-45 — восьмиконтактный разъем (рис. Л 1.5), использую-
щийся обычно для подключения кабеля к сетевым платам
Ethernet либо для коммутации на панели соединений.
В зависимости от того, что с чем нужно коммутировать,
применяются различные патч-корды: «45-45» (с каждой стороны
по разъему RJ-45), «110-45» (с одной стороны S110, с другой —
RJ-45) или «110-110».
Для монтажа разъемов RJ-11, RJ-12 и RJ-45 используются
специальные обжимочные приспособления, различающиеся ме-
жду собой количеством ножей (6 или 8) и размерами гнезда для
фиксации разъема. В качестве примера рассмотрим монтаж кабе-
ля 5-й категории в разъем RJ-45.
1. Аккуратно обрежьте конец кабеля. Торец кабеля должен
быть ровным.
174
Лабораторный практикум
Рис. Л1.6. Приспособление для снятия изоляции и обжимки разъема
2. Используя специальный инструмент, снимите с кабеля
внешнюю изоляцию на длину примерно 30 мм и обрежьте нить,
вмонтированную в кабель (нить предназначена для удобства сня-
тия изоляции с кабеля на большую длину). Любые повреждения
(надрезы) изоляции проводников абсолютно недопустимы —
именно поэтому желательно использовать специальный инстру-
мент, лезвие резака которого выступает ровно на толщину внеш-
ней изоляции (рис. Л 1.6).
Аккуратно разведите, расплетите и выровняйте проводники.
Выровняйте их в один ряд, при этом соблюдая цветовую марки-
ровку. Существует два наиболее распространенных стандарта по
разводке цветов по парам: Т568А (рекомендуемый компанией
Siemon) и Т568В (рекомендуемый компанией AT&T и фактиче-
ски наиболее часто применяемый):
Номер пары ЦветпоТ568В Цвет по Т568А
1 Синий Синий
2 Оранжевый Зеленый
3 Зеленый Оранжевый
4 Коричневый Коричневый
На разъеме RJ-45 цвета проводников располагаются так:
Номер контакта Цвет по Т568В Цвет по Т568А
1 Бело-оранжевый Бело-зеленый
2 Оранжевый Зеленый
3 Бело-зеленый Бело-оранжевый
4 Синий Синий
Лабораторная работа № 1
175
Продолжение
Номер контакта Цвет по Т568В Цвет по Т568А
5 Бело-синий Бело-синий
6 Зеленый Оранжевый
7 Бело-коричневый Бело-коричневый
8 Коричневый Коричневый
Проводники должны располагаться строго в один ряд, без на-
хлестов друг на друга. Удерживая их одной рукой, другой ровно
обрежьте проводники так, чтобы они выступали над внешней об-
моткой на 8—10 мм.
Держа разъем защелкой вниз, вставьте в него кабель. Каждый
проводник должен попасть на свое место в разъеме и упереться
в ограничитель. Прежде чем обжимать разъем, убедитесь, что вы
не ошиблись в разводке проводников. При неправильной развод-
ке помимо отсутствия соответствия номерам контактов на концах
кабеля, легко выявляемого с помощью простейшего тестера, воз-
можна более неприятная вещь — появление «разбитых пар»
(splitted pairs).
Для выявления такого брака обычного тестера недостаточно,
так как электрический контакт между соответствующими контак-
тами на концах кабеля обеспечивается и с виду все как будто бы
нормально. Но такой кабель не сможет обеспечить нормальное
качество соединения даже в 10-мегабитовой сети на расстояние
более 40—50 метров. Поэтому нужно быть внимательным и не то-
ропиться, особенно если у вас нет достаточного опыта.
Вставьте разъем в гнездо на обжимочном приспособлении
и обожмите его до упора-ограничителя на приспособлении. В ре-
зультате фиксатор на разъеме встанет на свое место, неподвижно
удерживая оболочку кабеля в разъеме. При этом, контактные но-
жи разъема врежутся каждый в свой проводник, обеспечивая на-
дежный контакт.
Аналогичным образом можно осуществить монтаж разъемов
RJ-11 и RJ-12, используя соответствующий инструмент.
Для монтажа разъема S110 специального обжимочного инст-
румента не требуется. Сам разъем поставляется в разобранном ви-
де. Кстати, в отличие от «одноразовых» разъемов типа RJ разъем
S110 допускает многократную разборку и сборку, что очень удоб-
но. Последовательность действий при монтаже следующая:
1. Снимите внешнюю изоляцию кабеля на длину примерно
40 мм, разведите в стороны пары проводников, не расплетая их.
176
Лабораторный практикум
2. Закрепите кабель (в той половинке разъема, на которой нет
контактной группы) с помощью пластмассовой стяжки и отрежь-
те получившийся «хвост».
3. Аккуратно уложите каждый проводник в органайзер на
разъеме. Не расплетайте пару на большую, чем требуется,
длину — это ухудшит характеристики всего кабельного соедине-
ния. Последовательность укладки пар обычная — синяя-оранже-
вая-зеленая-коричневая; при этом светлый провод каждой пары
укладывается первым.
Острым инструментом (бокорезами или ножом) обрежьте ка-
ждый проводник по краю разъема.
Установите на место вторую половинку разъема и руками
обожмите ее до защелкивания всех фиксаторов. При этом ножи
контактной группы врежутся в проводники, обеспечивая контакт.
Оптоволоконный кабель
Оптоволоконные кабели — наиболее перспективная и обеспе-
чивающая наибольшее быстродействие среда распространения
сигналов для локальных сетей и телефонии. В локальных сетях
оптоволоконные кабели используются для работы по протоколам
ATM и FDDL
Оптоволокно, как понятно из его названия, передает сигналы
с помощью импульсов светового излучения. В качестве источни-
ков света используются полупроводниковые лазеры, а также све-
тодиоды. Оптоволокно подразделяется на одно- и многомодовое.
Одномодовое волокно очень тонкое, его диаметр составляет
порядка 10 микрон. Благодаря этому световой импульс, проходя
по волокну, реже отражается от его внутренней поверхности, это
обеспечивает меньшее затухание. Соответственно одномодовое
волокно обеспечивает большую дальность без применения повто-
рителей. Теоретическая пропускная способность одномодового
волокна составляет 10 Гбит/с. Его основные недостатки — высо-
кая стоимость и высокая сложность монтажа. Одномодовое во-
локно применяется в основном в телефонии.
Многомодовое волокно имеет больший диаметр — 50 или 62,5
микрона. Этот тип оптоволокна чаше всего применяется в компь-
ютерных сетях. Большее затухание в многомодовом волокне объ-
ясняется более высокой дисперсией света в нем, из-за которой
Лабораторная работа Ле 1
177
его пропускная способность существенно ниже — теоретически
она составляет 2,5 Гбит/с.
Для соединения оптического кабеля с активным оборудова-
нием применяются специальные разъемы. Наиболее распростра-
нены разъемы типа SC и ST.
Монтаж соединителей на оптоволоконный кабель — очень
ответственная операция, требующая опыта и специального обуче-
ния, поэтому не стоит заниматься этим, не будучи специалистом.
Если вам необходимо построить фрагмент сети с использованием
оптоволокна, легче приобрести готовые кабели с соединителями.
Впрочем, учитывая стоимость кабеля, соединителей, а также ак-
тивного оборудования для оптики, можно предположить, что
в домашних и небольших ЛВС это оборудование будет использо-
ваться еще не скоро.
Ход работы
Рассмотреть следующие аппаратные средства и оборудова-
ние ЛВС:
I. Сетевые адаптеры Ethernet и Token Ring для шин ISA, PCI,
MCA.
2. Сетевые кабели (коаксиальный, витая пара, оптоволокно).
3. Устройства соединения BNC, RJ-45, настенные и модуль-
ные розетки, терминаторы.
4. Элементы ЛВС: монтажные короба, патч-панели, патч-кор-
ды, абонентские шнуры.
5. Активные элементы сетей: концентраторы, коммутаторы,
MAU.
Освоить методы монтажа и проверки работоспособности Л ВС:
1. Разделка кабеля UTP по стандартам TIA/E1A-568 А/В.
2. Тестирование сетевых адаптеров с помощью утилит на-
стройки.
Контрольные вопросы
1. Какие виды кабелей используются при создании ЛВС?
2. В чем различие UTP- и STP-кабелей?
3. В чем заключается основное преимущество структурированной ка-
бельной системы?
4. Для чего используется цветовая маркировка проводов в кабелях
UTP?
178
Лабораторный практикум
Лабораторная работа № 2
Организация обмена данными с использованием
протокола TCP/UDP
Цель работы: 1. Изучить принципы работы с блокирующими
сокетами с использованием библиотеки Winsock2 для ОС Win-
dows.
2. Изучить основы построения «клиент-серверных» приложе-
ний с использованием сокетов.
Продолжительность работы — 4 ч.
Краткие теоретические сведения.
Принципы работы с Winsock
Winsock — это интерфейс, который упрощает разработку сете-
вых приложений под Windows. Все что нам нужно знать, это то,
что Winsock представляет собой интерфейс между приложением
и транспортным протоколом, выполняющим передачу данных.
Протокол управления передачей TCP (Transmission Control
Protocol) и протокол дейтаграмм пользователя UDP (User
Datagram Protocol) функционируют на основном уровне стека
TCP/IP, называемом также транспортным. Протокол TCP обес-
печивает надежную передачу сообщений между удаленными при-
кладными процессами за счет образования логических соедине-
ний. Этот протокол позволяет равноранговым объектам на ком-
пьютере-отправителе и на компьютере-получателе поддерживать
обмен данными в дуплексном режиме. TCP позволяет без ошибок
доставить сформированный на одном из компьютеров поток бай-
тов в любой другой компьютер, входящий в составную сеть. TCP
делит этот поток на части — сегменты — и передает их нижележа-
щему уровню межсетевого взаимодействия. После того как эти
сегменты будут доставлены средствами уровня межсетевого взаи-
модействия в пункт назначения, TCP снова соберет их в непре-
рывный поток.
Протокол UDP обеспечивает передачу прикладных пакетов
дейтаграммным способом, как и главный протокол уровня меж-
сетевого взаимодействия IP, и выполняет только функции свя-
зующего звена (мультиплексора) между сетевым протоколом
и многочисленными службами прикладного уровня и пользова-
тельскими процессами.
Лабораторная работа Ла 2
179
1. Заголовочные файлы и библиотеки
Для того чтобы использовать Winsock, во-первых, необходимо
выполнить подключение библиотек и заголовков:
itinclude "winsock.h"или itinclude "winsock2.h"— в зависимости
от того, какую версию Winsock вы будете использовать.
Также в проект должны быть включены все соответствующие
lib-файлы (Ws2_32.lib или Wsock32.lib\
2. Инициализация
Теперь можно использовать функции WinsockAPI (полный
список функций можно найти в соответствующих разделах
MSDN).
Для инициализации Winsock используется функция WSAStartup.
int WSAStartup(
WORD wVersionRequested, // Версия интерфейса Winsock
LPWSADATA IpWSAData // Информация о проинициализированной версии
// Winsock
);
Параметр WORD wVersionRequested — младший байт — вер-
сия, старший байт — подверсия интерфейса Winsock. Возможные
версии — 1.0, 1.1, 2.0, 2.2... Для «сборки» этого параметра исполь-
зуем макрос MAKEWORD. Например: MAKEWORD (I, I) — вер-
сия l.l. Более поздние версии отличаются наличием новых функ-
ций и механизмов расширений. Параметр IpWSAData — указатель
на структуру WSADATA. При возврате из функции данная струк-
тура содержит информацию о проинициализированной нами вер-
сии WinsockAPI.
Так это выглядит на практике:
WSADATA ws;
if (FAILED (WSAStartup (MAKEWORD( 1, 1 ), &ws) ) )
{
// Ошибка...
error = WSAGetLastError();
}
При ошибке функция возвращает SOCKET ERROR. В таком
случае можно получить расширенную информацию об ошибке,
180
Лабораторный практикум
используя вызов WSAGetLastError(). Данная функция возвращает
код ошибки (тип int)
3. Создание сокета
Следующий этап — создание основного средства коммуника-
ции в Winsock — сокета (socket). С точки зрения WinsockAPI,
сокет — это дескриптор, который может получать или отправлять
данные. На практике все выглядит так: мы создаем сокет с опре-
деленными свойствами и используем его для подключения, прие-
ма/передачи данных и т. п. Создавая сокет, мы должны указать
его параметры: сокет использует TCP/IP-протокол или IPX (если
TCP/IP, то какой тип и т. д.). Так как данная лабораторная работа
ориентирована на TCP/IP-протокол, то остановимся на особен-
ностях сокетов, использующих этот протокол. Мы можем создать
два основных типа сокетов, работающих по TCP/IP-протоколу —
SOCK STREAM и SOCK_DGRAM. Различие в том, что для перво-
го типа сокетов (их еще называют TCP или connection-based socket)
для отправки данных сокет должен постоянно поддерживать со-
единение с адресатом, при этом доставка пакета адресату гаран-
тирована. Во втором случае наличие постоянного соединения не
нужно, но информацию о том, дошел ли пакет или нет — полу-
чить невозможно (так называемые СРРили connectionless sockets).
И первый, и второй типы сокетов имеют свое практическое при-
менение. Рассмотрим TCP (connection-based) сокет. Для начала
объявим его:
SOCKET s;
Создать сокет можно с помощью функции socket
SOCKET socket (int af,// Протокол (TCP/IP, IPX...)
int type , // Тип сокета (SOCKSTREAM / SOCKJJGRAM)
int protocol // Для Windows-приложений может быть О
);
Первый аргумент — af, указывает на семейство используемых
протоколов. Для интернет-приложений он должен иметь значе-
ние AFJNET.
Последний аргумент уточняет, какой транспортный протокол
следует использовать. Нулевое значение соответствует выбору по
умолчанию: TCP — для SOCK STREAM сокетов и UDP для
Лабораторная работа Ле 2
181
SOCK_DGRAM. В большинстве случаев нет никакого смысла за-
давать протокол вручную и обычно полагаются на автоматиче-
ский выбор по умолчанию.
Пример:
if (INVALID-SOCKET == (s = socket (AF_INET, SOCK_STREAM, 0) ) )
{
// Ошибка...
error = WSAGetLastError( );
}
Если функция завершилась успешно, она вернет дескриптор
сокета. В случае возникновения ошибки будет возвращено значе-
ние INVALID SOCKET, расширенную информацию об ошибке
можно получить, используя вызов WSAGetLastErrorf).
4. Клиентское приложение. Установка соединения
В предыдущем примере мы создали сокет. Теперь его можно
использовать для обмена данными с другими клиентами и не
только. Для того чтобы установить соединение с другой машиной,
необходимо знать ее IP-адрес и порт. Удаленная машина должна
«слушать» этот порт на предмет входящих соединений (т. е. она
выступает в качестве сервера). В таком случае наше
приложение — это клиент.
Для установки соединения используем функцию connect.
int connect(
SOCKET s, // Сокет (наш сокет)
const struct sockaddr FAR *name, // Адрес
int namelen // Длина адреса
);
Пример:
Объявим переменную для хранения адреса
sockaddr__in s_addr;
Заполним ее:
ZeroMemory (&s_addr, sizeof (saddr));
// Тип адреса (TCP/IP)
182
Лабораторный практикум
s_addr.sin_family = AF_INET;
// Адрес сервера. Так как TCP/IP представляет адреса в числовом
// виде, то для перевода адреса используем функцию inet_addr.
s_addr.sin_addr.S_un.S_addr = inet_addr ("127.0.0.1");
// Порт. Используем функцию htons для перевода номера порта из
// обычного в ТСР/1Р-представление.
s_addr.sin_port = htons (1234);
Дальше выполняем соединение:
if (SOCKET_ERROR == ( connect (s, (sockaddr *) &s_addr,
sizeof (s_addr) ) ) )
{
// Ошибка...
error = WSAGetLastErrorO;
}
Если функция завершилась успешно, она вернет ноль. При
ошибке будет возвращено значение SOCKET_ERROR, расширен-
ную информацию об ошибке можно получить, используя вызов
WSA GetLastErrorf).
Теперь сокет s связан с удаленной машиной и может посы-
лать/принимать данные только с нее.
Примечание: t/DP-сокеты работают без установки соединения,
поэтому обычно не обращаются к функции connect. За словом
«обычно» кроется один хитрый прием программирования — вы-
зов connect позволяет tZDP-сокету обмениваться данными с узлом
не только функциями sendto, recvfrom, но и более удобными
и компактными send и recv. Эта тонкость описана в Winsock SDK
и широко используется как самой Microsoft, так и сторонними
разработчикам. Поэтому ее использование вполне безопасно.
5. Серверное приложение
5.1. Связывание сокета
Прежде чем сервер сможет использовать сокет, он должен
связать его с локальным адресом. Локальный, как впрочем, и лю-
бой другой адрес Интернета, состоит из IP-адреса узла и номера
порта. Если сервер имеет несколько IP-адресов, то сокет может
быть связан как со всеми сразу (для этого вместо IP-адреса следу-
Лабораторная работа Хе 2
183
ет указать константу INADDR_ANY, равную нулю), так и с ка-
ким-то одним.
Связывание осуществляется путем вызова функции:
int bind (
SOCKET s, // Дескриптор сокета
const struct sockaddr FAR* name, // Адрес привязки сокета
int namelen // Длина структуры sockaddr
):
Первым аргументом передается дескриптор сокета, возращен-
ный функцией socket, за ним следуют указатель на структуру
sockaddr и ее длина.
Строго говоря, клиент также должен связывать сокет с ло-
кальным адресом перед его использованием, однако за него это
делает функция connect, ассоциируя сокет с одним из портов,
случайно выбранных из диапазона 1024—5000. Сервер же дол-
жен использовать заранее определенный порт, например,
21 для FTP, 23 для telnet, 25 для SMTP, 80 для WEB, 110 для
POP3 и т. д. Поэтому ему приходится осуществлять связывание
«вручную».
При успешном выполнении функция вернет нулевое значение.
В противном случае будет возвращено значение SOCKET ERROR,
расширенную информацию об ошибке можно получить, используя
вызов WSAGetLastError().
5.2. Ожидание подключений
Выполнив связывание, потоковый сервер переходит в режим
ожидания подключений, вызывая функцию:
int listen (
SOCKET s, // Дескриптор сокета
int backlog // Максимально допустимый размер очереди
// сообщений
);
Размер очереди ограничивает количество одновременно обра-
батываемых соединений. На выбор этого параметра функции
влияет несколько обстоятельств. При маленьком значении оче-
редь быстро заполнится, и очередной клиент при попытке уста-
184
Лабораторный практикум
новить соединение получит отказ (ГСР-пакет с установленным
флагом RST). С другой стороны, разрешая большое количество
подключений, мы должны учитывать производительность серве-
ра, объем оперативной памяти и т. д.
При успешном выполнении функция вернет нулевое значение.
В противном случае будет возвращено значение SOCKET ERROR,
расширенную информацию об ошибке можно получить, используя
вызов WSAGetLast Error ().
Примечание: UDP-серверы не вызывают функцию listen, так
как работают без установки соединения и сразу же после выпол-
нения связывания могут вызывать recvfrom для чтения входящих
сообщений.
5.3. Извлечение запросов на подключение
Извлечение запросов на соединение из очереди осуществля-
ется функцией:
SOCKET accept(
SOCKET s, // Дескриптор сокета
struct sockaddr FAR* addr, // Адрес извлеченного из очереди
// сокета
int FAR* addrlen // Длина структуры sockaddr
);
Данная функция автоматически создает новый сокет, выпол-
няет связывание и возвращает его дескриптор, а в структуру
sockaddr заносит сведения о подключившемся клиенте (1Р-адрес
и порт). Если в момент вызова accept очередь пуста, функция нс
возвращает управление до тех пор, пока с сервером не будет ус-
тановлено хотя бы одно соединение. При возникновении ошиб-
ки функция возвращает INVALID SOCKET, а расширенную
информацию об ошибке можно получить, используя вызов
WSA GetLastError().
Для параллельной работы с несколькими клиентами следует
сразу же после извлечения запроса из очереди порождать новый
поток (процесс), передавая ему дескриптор созданного функцией
accept сокета, затем вновь извлекать из очереди очередной запрос
и т. д. В противном случае, пока не завершит работу один клиент,
сервер не сможет обслуживать всех остальных.
Лабораторная работа Хе 2
185
6. Отправка и прием данных
6.1. Функция send
Для того чтобы послать данные на машину, с которой мы
предварительно установили соединение, используем функцию
send
int send(
SOCKET s, // Сокет-отправитель
const char FAR *buf, // Указатель на буфер с данными
int len, // Длина данных
int flags // Флаги (может быть 0)
);
Пример использования данной функции:
if (SOCKET—ERROR == ( send (s, (char* ) & buff), 512, 0 ) )
{
// Ошибка...
error = WSAGetLastErrorO;
}
При ошибке функция возвращает SOCKET ERROR.
Длина пакета данных ограничена самим протоколом. Возврат
из функции не происходит до тех пор, пока данные не будут от-
правлены.
Примечание: Функция send возвращает управление сразу же
после ее выполнения независимо от того, получила ли прини-
мающая сторона наши данные или нет. При успешном заверше-
нии функция возвращает количество передаваемых (не передан-
ных) данных, т. е. успешное завершение пересылки еще не свиде-
тельствует об успешной доставке. В общем-то, протокол TCP (на
который опираются потоковые сокеты) гарантирует успешную
доставку данных получателю, но лишь при условии, что соедине-
ние не будет преждевременно разорвано. Если связь прервется до
окончания пересылки, данные останутся не переданными, но вы-
зывающий процесс не получит об этом никакого уведомления.
Ошибка возвращается лишь в том случае, если соединение разо-
рвано до вызова функции send.
186
Лабораторный практикум
6.2. Функция recv
Принять данные от машины, с которой мы предварительно
установили соединение, позволяет функция recv.
int recv(
SOCKET s, // Сокет-получатель
char FAR *buf, // Адрес буфера для приема данных
int len, // Длина буфера для приема данных
int flags // Флаги (может быть 0)
);
Если вы заранее не знаете размер входящих данных, то длина
буфера-получателя должна быть не меньше чем максимальный
размер пакета, иначе сообщение может не поместиться в него
и будет обрезано. В этом случае функция возвращает ошибку.
Пример:
int actual_len = 0;
if (SOCKET_ERROR == (actual_len = recv (s, (char* ) & buff),
MAX_PACKET_SIZE, 0 ) )
{
// Ошибка...
error = WSAGetLastError();
}
Если данные получены, то функция возвращает размер полу-
ченного пакета данных (в примере — actual_len). При ошибке
функция возвращает SOCKET_ERROR.
Примечание: Функция recv возвращает управление только по-
сле того, как получит хотя бы один байт. Точнее говоря, она ожи-
дает прихода целой дейтаграммы. Дейтаграмма — это совокуп-
ность одного или нескольких IP-пакетов, посланных вызовом
send. Упрощенно говоря, каждый вызов recv за один раз получает
столько байтов, сколько их было послано функцией send. При
этом подразумевается, что функции recv предоставлен буфер до-
статочных размеров — в противном случае ее придется вызвать
несколько раз. Однако при всех последующих обращениях дан-
ные будут браться из локального буфера, а не приниматься из се-
Лабораторная работа № 2
187
ти, так как TCP-провайдер не может получить «кусочек» дейта-
граммы, а только всю ее целиком.
Заметим, что функции send/recv будут ждать, пока не закон-
чится тайм-аут или не отправится/придет пакет данных. Это со-
ответственно вызывает задержку в работе программы. Как избе-
жать этого рассмотрим в следующей лабораторной работе.
6.3. Функции sendto и recvfrom
Дейтаграммный сокет может пользоваться функциями send
и recv, если предварительно вызовет connect, но у него есть и свои,
«персональные», функции:
int sendto(
SOCKET s, // Дескриптор сокета
const char FAR * buf, // Буфер с отправляемыми // данными
int len, // Длина буфера
int flags, // Флаги (может быть 0)
const struct sockaddr FAR * to, // Указатель на адрес // получателя данных
int tolen ); // Длина адреса
int recvfrom(
SOCKET s, // Дескриптор сокета
char FAR* buf, // Указатель на буфер для // приема данных
int len, // Длина буфера
int flags, // Флаги (может быть 0)
struct sockaddr FAR* from, // Указатель на адрес, с
// которого пришли данные
int FAR* fromlen // Длина адреса
Данные функции очень похожи на send и recv — разница лишь
в том, что sendto и recvfrom требуют явного указания адреса узла,
принимающего или передающего данные. Вызов recvfrom не тре-
бует предварительного задания адреса передающего узла — функ-
ция принимает все пакеты, приходящие на заданный СДР-порт
со всех 7Р-адресов и портов. Напротив, отвечать отправителю
188 Лабораторный практикум
следует на тот же самый порт, откуда пришло сообщение. По-
скольку функция recvfrom заносит /P-адрес и номер порта клиен-
та после получения от него сообщения, программисту фактиче-
ски ничего делать не нужно — только передать sendto тот же са-
мый указатель на структуру sockaddr, который был ранее передан
функции recvfrom, получившей сообщение от клиента.
6.4. Особенности работы функций send/sendto, recv/recvfrom
Работой всех функций можно управлять с помощью флагов,
передаваемых в одной переменной flag? типа int. Эта переменная
может принимать одно из двух значений: MSG_PEEK, MSG_OOB.
Флаг MSG_PEEK заставляет функцию recv/recvfrom про-
сматривать данные вместо их чтения. Просмотр, в отличие от
чтения, не уничтожает просматриваемые данные. Некоторые ис-
точники утверждают, что при взведенном флаге MSG_PEEK
функция recv не задерживает управления, если в локальном бу-
фере нет данных, доступных для немедленного получения. Это
неверно! Аналогично, иногда приходится встречать откровенно
ложное утверждение, якобы функция send со взведенным фла-
гом MSG-РЕЕК возвращает количество уже переданных байтов
(вызов send не блокирует управления). На самом деле функция
send игнорирует этот флаг.
Флаг MSG_OOB предназначен для передачи и приема сроч-
ных (Out Of Band) данных. Срочные данные не имеют преимуще-
ства перед другими при пересылке по сети, а всего лишь позволя-
ют оторвать клиента от нормальной обработки потока обычных
данных и сообщить ему «срочную» информацию. Если данные
передавались функцией send/recv с установленным флагом
MSG_OOB, для их чтения флаг MSG_OOB функции recv также
должен быть установлен.
Замечание: Настоятельно рекомендуется воздержаться от ис-
пользования срочных данных в своих приложениях. Во-первых,
они совершенно необязательны — гораздо проще, надежнее
и элегантнее вместо них создать отдельное соединение. Во-вто-
рых, по поводу их реализации нет единого мнения, и интерпрета-
ции различных производителей очень сильно отличаются друг от
друга. Так, разработчики до сих пор не пришли к окончательному
соглашению по поводу того, куда должен указывать указатель
срочности: или на последний байт срочных данных, или на байт,
Лабораторная работа Л» 2
189
следующий за последним байтом срочных данных. В результате
отправитель никогда не имеет уверенности, что получатель смо-
жет правильно интерпретировать его запрос.
Еще существует флаг MSG_DONTROUTE, предписывающий
передавать данные без маршрутизации, но он не поддерживается
Winsock и, поэтому, здесь не рассматривается.
Еще одна деталь — транспортный протокол UDP, на который
опираются дейтаграммные сокеты, не гарантирует успешной до-
ставки сообщений, и эта задача ложится на плечи самого разра-
ботчика. Решить ее можно, например, посылкой клиентом под-
тверждения об успешности получения данных. Правда, клиент
тоже не может быть уверен, что подтверждение дойдет до сервера,
а не потеряется где-нибудь в дороге. Подтверждать же получение
подтверждения — бессмысленно, так как это рекурсивно неразре-
шимо. Лучше вообще не использовать дейтаграммные сокеты на
ненадежных каналах.
7. Закрытие соединения
Процедура закрытия активного соединения происходит с по-
мощью функций shutdown и closesocket. Различают два типа за-
крытия соединений: abortive и graceful. Первый вид — это экс-
тренное закрытие сокета (closesocket). В таком случае соединение
разрывается моментально. Вызов closesocket имеет мгновенный
эффект. После вызова closesocket сокет уже недоступен.
int shutdown(
SOCKET s, // Закрываемый сокет
int how // Способ закрытия
);
int closesocket(
SOCKET s // Закрываемый сокет
);
Пример:
closesocket (s);
Примечание: Существуют более сложные приемы закрытия
соединения — протокол TCP позволяет выборочно закрывать со-
190
Лабораторный практикум
единение любой из сторон, оставляя другую сторону активной.
Например, клиент может сообщить серверу, что не будет больше
передавать ему никаких данных и закрывает соединение «кли-
ент-сервер», однако готов продолжать принимать от него данные
до тех пор, пока сервер будет их посылать, т. е. хочет оставить со-
единение «клиент—сервер» открытым. Для этого необходимо вы-
звать функцию shutdown, передав в аргументе how одно из следую-
щих значений: SD_RECEIVE — для закрытия канала «сервер—кли-
ент», SD_SEND — для закрытия канала «клиент—сервер»,
и наконец, SD_BOTH - для закрытия обоих каналов.
Последний вариант выгодно отличается от closesocket «мяг-
ким» закрытием соединения — удаленному узлу будет послано
уведомление о желании разорвать связь, но это желание не будет
воплощено в действительность, пока удаленный узел не возвратит
свое подтверждение. Таким образом, можно не волноваться, что
соединение будет закрыто в самый неподходящий момент.
Внимание: Вызов shutdown не освобождает от необходимости
закрытия сокета функцией closesocket.
8. Деинициализация
Инициализация Winsock осуществлялась с помощью функ-
ции WSAStartup. Для завершения работы с Winsock необходимо
правильно деинициализировать библиотеку Winsock и освободить
используемые нашим приложением ресурсы. Приложению необ-
ходимо вызвать функцию WSACleanup().
int WSACleanup (void);
Пример:
WSACleanup();
9. Заключение
Рассмотренный Winsock-механизм обмена данными доста-
точно прост. От программиста требуется лишь выработать свой
«протокол» общения удаленных машин и реализовать его с помо-
щью данных функций. Конечно, рассмотренные примеры не от-
ражают всех возможностей Winsock.
Лабораторная работа № 2
191
Задания для самостоятельной работы
Вариант № 1
Необходимо разработать приложение для обмена файлами
между различными узлами сети с использованием блокирующих
сокетов, протокола UDP, библиотеки Winsock2 под ОС Windows.
Вариант № 2
Необходимо разработать приложение для обмена файлами
между различными узлами сети с использованием блокирующих
сокетов, протокола TCP, библиотеки Winsock2 под ОС Windows.
Вариант № 3
Необходимо разработать приложение-чат для обмена сообще-
ниями между одним сервером и несколькими клиентами с ис-
пользованием блокирующих сокетов, протокола UDP, библиоте-
ки Winsock2 под ОС Windows.
Вариант № 4
Необходимо разработать приложение-чат для обмена сообще-
ниями между одним сервером и несколькими клиентами с ис-
пользованием блокирующих сокетов, протокола TCP, библиоте-
ки Winsock2 под ОС Windows.
Контрольные вопросы
1. Что такое Winsock?
2. Что такое сокет?
3. В чем различие протоколов TCP и UDP?
4. Можно ли обмениваться сообщениями по протоколу UDP методами
recv/send?
5. Как работает функция listen?
6. Как работает функция accept?
7. В чем отличие UPD-сервера от ТСР-сервера?
8. Что такое очередь подключений?
9. В чем отличие функции shutdown от функции closesocket?
10. Назначение флагов функций send/sendto, recv/recvfrom.
192
Лабораторный практикум
Лабораторная работа № 3
Организации обмена данными с FTP/HTTP-сервером.
Сокеты без блокировки
Цель работы: 1. Изучить принципы работы с HTTP/FTP сер-
вером с использованием Winsock2.
2. Изучить механизм работы с неблокирующими сокетами.
Продолжительность работы — 4 ч.
1. Краткие теоретические сведения. Принцип работы
с FTP/HTTP-сервером
Для примера рассмотрим следующее техническое задание: не-
обходимо написать программу, которая получает с удаленного
http-сервера нужную нам HTML-страничку. Например, взять
HTML-страничку /enp/rfc/rfc768.txt с сайта www.networksor-
cery.com — значит, выполнить обращение по адресу www.network-
sorcery.com/enp/rfc/rfc768.txt. Для выполнения таких действий
необходимо написать программу, в какой-то мере напоминаю-
щую интернет-браузер.
В качестве протокола обмена данными с сервером можно ис-
пользовать HTTP (стандарт RFC 2616), FTP (RFC 959) и другие
протоколы. Мы будем использовать //77Р-протокол. В принципе,
Winsock все равно, какой протокол вы используете для связи
с сервером. Его задача — доставить данные серверу и получить от-
вет. В данной лабораторной работе не рассматриваются особен-
ности протокола HTTP (достаточно подробное описание HTTP
дано в гл. 2). Все что приложению нужно знать, для того чтобы ус-
тановить соединение с каким-нибудь сервером, это его адрес и
порт. Например, 66.27.58.123 — это адрес 7777Р-сервера «Network
Sorcery». Протокол HTTP использует порт 80, протокол FTP — 21.
Проблема в том, что некоторые серверы имеют динамические ад-
реса. В таком случае их адреса вычисляются с помощью специ-
альных функций Winsock API.
Для того чтобы узнать IP-адрес машины, зная ее имя, сущест-
вует функция gethostbyname. Для получения имени машины по ее
адресу используем функцию gethostbyaddr. Рассмотрим эти функ-
ции подробнее.
struct hostent FAR- *gethostbyname(
const char FAR *name
);
Лабораторная работа № 3
193
Пример вызова:
hostent* d_addr; // Структура, в которую будет помещен 1Р-адрес,
// при возврате.
hostent* hn = gethostbyname Cwww.networksorcery.com ");
Если функция отработала успешно, то структура hn содержит
нужные нам данные, иначе gethostbyname возвращает NULL.
Рассмотрим структуру hn.
struct hostent {
char FAR » h_name; // Официальное имя машины
char FAR * FAR * h_aliases; // Массив альтернативных имен
// машины (заканчивающийся 0)
short h_addrtype; // Тип адреса (AF_INET...)
short h_length; // Длина адреса в байтах
char FAR * FAR * h_addr_list; // Список адресов
// (заканчивающийся 0)
};
Итак, после вызова gethostbyname нас интересуют следующие
поля этой структуры:
h name — можем узнать официальное имя машины;
haddrtype — тип адреса (для TCP/IP должно быть AFINET);
h_length — длина адреса (для TCP/IP V4 — 4 байта);
h_addr_list — массив адресов (заканчивающийся 0).
Для получения первого адреса в массиве можно использовать
макрос h_addr_Ust[O].
Для того чтобы получить адрес интересующей нас машины,
необходимо вызвать gethostbyname (имя машины) и, проанализи-
ровав полученные назад данные, выбрать из массива h_addr_list
ее адрес. Адрес машины сохраним в структуре sockaddr_in.
Полный пример:
sockaddr_in adr;
hostent* d_addr = gethostbyname ("www.networksorcery.com ");
adr.sin_addr.S_un.S_addr = ‘(DWORD* ) hn->h_addr_list[O];
Функция gethostbyaddr, получая на вход адрес, тип адреса
и” его длину, возвращает имя машины.
194
Лабораторный практикум
struct HOSTENT FAR * gethostbyaddr(
const char FAR *addr, // Адрес машины (в сетевом виде)
int len, // Длина адреса
int type // Тип адреса
);
Пример:
DWORD а = inet_addr (”192.168.0.4”); // Адрес машины в сетевом
// формате
hn = gethostbyaddr ((char* )&а, 4, AF_INET);
Если выполнение функции завершено успешно, поле h_name
структуры hn будет содержать имя машины.
Вернемся к написанию программы. Структура программы та-
кова:
1. Узнаем IP-адрес сервера.
2. Устанавливаем соединение.
3. Посылаем серверу запрос (в http-формате).
4. Получаем ответ и выводим его на экран.
5. Закрываем соединение и завершаем работу.
Примечание: Рассматриваемый код будет работать только на
машинах, имеющих «прямой» выход и Интернет (не через про-
кси-сервер).
Вот исходный код программы.
«include "stdafx.h”
«include ”winsock2.h"
// Необходимые макроопределения
«define request "GET /enp/rfc/rfc768.txt HTTP/1.0\r\nHost: ” \
”www.networksorcery. com\r\n\r\n" // HTML-запрос.
«define MAX_PACKET_SIZE 1024
// Напечатать код последней ошибки
void print_WSAGetLastError(const char* function_name)
{
int res = WSAGetLastError ();
printf ("\nERROR: \tFunction \”%s\" call failed, \n \t
WSAGetLastError() return error code: dec = [%d], hex = [0x%0x]\n”,
function_name , res, res);
}
int main(int argc, char* argv[])
Лабораторная работа № 3
195
WSADATA ws;
SOCKET s;
sockaddr_in adr;
hostent* hn;
char buff [MAX_PACKET_SIZE];
// Инициализация
if (WSAStartup (0x0101, &ws) != 0)
print_WSAGetLastError("WSAStartup");
return -1;
}
// Создаем сокет
if (INVALID_SOCKET == (s = socket (AF_INET, SOCK.STREAM,
IPPROTO_TCP) ) )
{
print_WSAGetLastError("socket");
return -1;
}
// Получаем адрес
if (NULL == (hn = gethostbyname("www.networksorcery.com")))
{
print_WSAGetLastError("get hostbyname");
return -1;
}
// Заполняем поля структуры adr для использования ее в
// connect
adr.sin_family = AF_INET;
adr.sin_addr.S_un.S_addr = *(DWORD* ) hn->h_addr_list[O];
adr.sin_port = htons (80);
// Устанавливаем соединение с сервером
if (S0CKET_ERR0R == connect(s, (sockaddr*) &adr,
sizeof(adr) ) )
{
pr int_WSAGetLast Error("connect");
return -1;
196
Лабораторный практикум
// Посылаем запрос серверу
if (SOCKET_ERROR == send (s, &request, sizeof(request), 0))
{
print_WSAGetLastError("send");
return -1;
}
// Ждем ответа
int len = recv (s, (char *) &buff, MAX_PACKET_SIZE, 0);
if ( (len == SOCKET_ERROR) || (len == 0) )
{
print_WSAGetLastError("recv");
return -1;
}
// Выводим ответ сервера
for (int i = 0; i < len; i++)
printf ("%c", buff [i]);
printf("\n");
// Закрываем соединение
if (SOCKET_ERROR == closesocket (s) )
<
print_WSAGetLastError("closesocket");
return -1;
}
return 1;
}
Если открыть ссылку http://www.networksorcery.com/ епр/rfc/
rfc768.txt, в окне браузера должна появится информация с описа-
нием «User Datagram Protocol». Такой же ответ должна выдать
и программа после системной информации сервера.
2. Прием фрагментированных данных
В предыдущем примере программы есть такой фрагмент кода:
// Ждем ответа
int len = recv (s, (char *) &buff, MAX_PACKET_SIZE, 0);
Лабораторная работа № 3
197
На первый взгляд вроде бы все нормально. Но это не так. В вы-
зове функции recv присутствует параметр MAX_PACKET_SIZE, ко-
торый определяет длину буфера приема данных, т. е., Winsock-npo-
токолы (TCP/UDP) могут «отправить» пакет размером и 65 535 байт.
Однако реальный размер IP-пакета может быть меньше передавае-
мых данных для конкретного типа сети (величина MTU-размер
наибольшего допустимого кадра в локальной сети или глобальном
канале) и поэтому данные фрагментируются (см. описание
TCP/IP-протокола). При этом фрагментированные данные могут
идти с задержками. Если приложение запросит у удаленного
Web-сервера не такой маленький кусочек HTML-кода, как в при-
мере, то в ответ оно получит только первую порцию данных от сер-
вера. Остальная часть данных будет, скорее всего, утеряна. Выход
из данного положения очень прост. Он основан на знании прин-
ципа работы HTTP- и ТСР/7Р-протоколов и некоторых особенно-
стей Winsock. В нашем случае Web-сервер, передав последнюю
порцию данных, закроет соединение. А функция recv в таком слу-
чае после получения последнего фрагмента данных возвращает
ноль. Вывод напрашивается сам: мы должны читать входящие дан-
ные до тех пор, пока функция recv не вернет ноль.
Вот новый вариант кода:
// Ждем ответа
int len = 0;
do
{
if (SOCKET_ERROR == (len = recv (s, (char *) &buff,
MAX_PACKET_SIZE, 0) ) )
{
print_WSAGetLastError("recv");
return -1;
}
for (int i = 0; i < len; i++)
printf ("%c", buff [i]);
}
while (len!=0); // Получаем данные no частям, пока не len != 0.
При такой организации считывания данных потерь не будет.
3. Проблема блокировки сокета и ее решение
Если выполнять программу из примера в пошаговом режиме,
то можно заметить, что некоторые Winsock-функции ожидают за-
198
Лабораторный практикум
вершения выполняемых ими операций. Особенно надолго «под-
висает» функция recv. Другими словами, выход из функции
не происходит до момента завершения текущей операции. Эта
особенность не очень хорошо подходит для программ, которые
кроме получения/отправки данных должны выполнять еще мно-
жество других действий (отслеживание состояния системы меню,
вывод информации, опрос других устройств ввода/вывода). Избе-
жать этого можно несколькими способами. Можно обойтись
средствами мультизадачное™, и процедуру обмена данными реа-
лизовать как отдельную ветвь приложения. А можно решить про-
блему средствами Winsock. В любом случае выбор конкретного
метода остается за программистом. В данной работе рассматрива-
ются механизмы блокировки TCP-сокетов в Winsock. Итак, рас-
смотрим два метода устранения проблемы блокировки.
4. Функция ioctlsocket
Функция ioctlsocket позволяет менять/получать режим вво-
да/вывода конкретного сокета.
int ioctlsocket(
SOCKET s, // Сокет [in]
long emd, // Команда [in]
u_long FAR *argp // Параметр/значение [in/out]
);
Для перевода сокета в неблокируемое состояние (nonblocking
mode) используется команда FIONBIO. Аргумент argp должен
указывать на ненулевое значение.
Пример:
BOOL 1 = TRUE;
if (SOCKET_ERROR == ioctlsocket (s, FIONBIO, (unsigned long* ) &1) )
{
print_WSAGetLastError("ioctlsocket");
return -1;
}
Кроме команды FIONBIO, существуют команды FIONREAD
и SIOCATMARK. Если коротко, то FIONREAD позволяет полу-
чить количество байтов информации, поступившей в буфер на
данный момент операции чтения, a SIOCATMARK используется
при работе с ООВ-данными. Остановимся на команде FIONBIO.
Лабораторная работа № 3
199
Вернемся к примеру. После вызова ioctlsocket сокет s стал не-
блокируемым, т. е. Winsock-функции для этого сокета не дожида-
ются окончания операций ввода/вывода, что в свою очередь не вы-
зывает нежелательных пауз в работе программы. Однако возврат из
функции recv может произойти до момента получения данных. Как
определить, что текущая операция ввода/вывода полностью за-
вершена? Необходимо воспользоваться WSAEWOULDBLOCK —
это код ошибки, которую возвращают Winsock-функции для
nonblocked-сокела, если текущая операция не завершена. То есть,
если функция revc вернула этот код ошибки, значит, данные еще
не готовы для чтения, и операцию придется повторить позже. В та-
ком случае, программа может выполнять другие действия, попутно
проверяя, не завершена ли текущая операция ввода/вывода.
Пример:
// Устанавливаем nonblocked mode
BOOL 1 = TRUE;
if (SOCKET_ERROR == ioctlsocket (s, FIONBIO, (unsigned long* ) &1))
print_WSAGetLastError("ioctlsocket");
return -1;
}
// Получаем данные. . .
int len = 0;
do
{
if (SOCKET_ERROR == (len = recv (s, (char *) &buff,
MAX_PACKET_SIZE, 0) ) )
{
int res = WSAGetLastError();
if (res != WSAEWOULDBLOCK)
print_WSAGetLastError("recv”);
return -1;
}
else len = 1;
}
else
for (int i = 0; i<len; i++)
printf ("%c", buff [i]);
200
Лабораторный практикум
// Если recv вернул ошибку WSAEWOULDBLOCK, то можем
// продолжать работу.
// Перед следующим вызовом recv (. ..) делаем все
// необходимые нам действия...
}
while (1еп!=0);
5. Функция select
Функция select позволяет определить текущее состояние од-
ного или более сокетов. То есть из какого-то входящего множест-
ва сокетов она формирует выходящее множество сокетов, готовых
к операциям чтения/записи/....
int select(
int nfds, // He используется (оставлен для совместимости)
fd_set FAR *readfds, // Множество сокетов, проверяемых на готовность
к чтению
fd_set FAR *writefds, // Множество сокетов, проверяемых на готовность
к отсылке
fd_set FAR *exceptfds,// Множество сокетов, проверяемых на ошибку/ООВ
данных
const struct timeval FAR ‘timeout // Тайм-аут проверки
);
Каждый из параметров readfds, writefds, exceptfds, timeout явля-
ется необязательным и может быть проигнорирован (установлен
в NULL). В случае readfds/writefds/exceptfds == NULL проверка
на опушенные типы сокетов просто не будет производиться.
В случае timeout == NULL функция select вызовет блокировку
(до первого готового к вводу/выводу сокета). Функция возвраща-
ет общее количество сокетов (во всех заданных множествах
readfds/writefds/exceptfds), готовых к операциям ввода/вывода.
Параметры readfds/writefds/exceptfds — указатели на тип fd_set
(представляющий собою множество сокетов). Для работы с этим
типом данных объявлены такие макросы:
FD_CLR (s, *set) // Удаляет дескриптор s из set.
FD_ISSET(s, *set) // Возвращает ненулевое значение, если s
// присутствует в set. Иначе, возвращает ноль.
FD_SET(s, »set) // Добавляет s к set.
FD_ZERO(«set) // Очищает множество set
Лабораторная работа 3
201
Параметр timeout — указатель на структуру timeval, позволяет
задать тайм-аут, в течение которого сокеты будут проверяться на
готовность.
struct timeval {
long tv_sec; // Секунды
long tv_usec; // Микросекунды
};
С помощью функции select и этого набора макросов можно
проверять конечное множество сокетов на готовность к считыва-
нию/отсылке данных, выполнению connect, на предмет входящих
соединений, наличия ООВ-сообшений и т. п. При проверке соке-
та на возможность считывания данных можно ограничиться са-
мым простым вызовом select. Для этого нам необходимо вклю-
чить наш сокет в то множество, на которое будет указывать
readfils (в примере это read_s), задать timeout и выполнить select.
Пример:
// Ждем ответа
int len, res;
fd_set read_s;
timeval time_out;
time_out.tv_sec = 0; time_out.tv_usec = 500000; // 0.5 sec.
do
{
FD_ZER0 (&read_s); // Обнуляем множество
FD-SET (s, &read_s); // Заносим в него наш сокет
if (SOCKET-ERROR == (res = select (0, &read_s, NULL, NULL,
&time_out) ) )
{
print_WSAGetLastError("select");
return -1;
}
if ((res!=0) && (FD_ISSET (s, &read_s)) )
{
// Данные готовы к чтению. . .
if (SOCKET.ERROR == (len = recv (s, (char *) &buff,
MAX_PACKET_SIZE, 0) )
{
print_WSAGetLastError("recv");
202
Лабораторный практикум
return -1;
}
// Выводим их на экран.
for (int i = 0; i<len; i++)
printf ("%c", buff [i]);
}
// Делаем все необходимые нам действия. . .
}
while (len!=0);...
6. Заключение
В лабораторной работе рассмотрены некоторые нюансы ис-
пользования сокетов и простейшие способы решения проблемы
блокировки.
7. Задания для самостоятельной работы
Вариант № 1
Реализация простейшего HTTP-клиента с использованием
неблокирующих сокетов, библиотеки Winsock2 под ОС Windows,
протоколов TCP и HTTP.
Вариант № 2
Реализация простейшего FTP-клиента с использованием не-
блокирующих сокетов, библиотеки Winsock2 под ОС Windows,
протоколов TCP и FTP.
Контрольные вопросы
1. Что такое Winsock?
2. Что такое сокет?
3. Расскажите коротко о стандартах RFC 2616 и RFC 959.
4. Для чего нужен протокол HTTP?
5. Для чего нужен протокол FTP?
6. Какие сокеты называются неблокирующими?
7. В чем заключается принцип решения проблемы блокировки соке-
тов на основе функции ioctlsocket?
8. Как работает функция ioctlsocket?
9. В чем заключается принцип решения проблемы блокировки соке-
тов на основе функции select?
10. Как работает функция select?
11. Как с .помощью функции recv можно принять большую порцию
данных?
Лабораторная работа Л» 4
203
Лабораторная работа № 4
Сетевое программирование с использованием
RAW-сокетов
Цель работы: 1. Изучить принципы работы с RAW-сокетами.
2. Научиться формировать IP-, TCP-, UDP-, ICMP-пакеты на
RAW-сокетах.
Продолжительность работы — 4 ч.
1. RAW-сокеты в Windows 2000/ХР
Фундаментальной единицей всего сетевого программирова-
ния практически во всех операционных системах является сокет.
Так же, как функции файлового ввода-вывода, определяют ин-
терфейс взаимодействия с файловой системой, сокет соединяет
программу с сетью. Существует несколько типов сокетов, однако
чаще всего встречаются следующие три типа:
SOCK STREAM — обеспечивает надежный дуплексный про-
токол на основе установления логического соединения. Если го-
ворить о семействе протоколов TCP/IP, которое сейчас получило
самое широкое распространение, то это TCP',
SOCKDGRAM — обеспечивает надежный сервис доставки
дейтаграмм. В рамках TCP/IP это будет протокол UDP;
SOCKRAW— предоставляет доступ практически ко всем слу-
жебным полям заголовков протоколов, таких, как IP, TCP, UDP
и ICMP.
Два первых типа сокетов чаще всего применяются на практи-
ке. По работе с ними написано очень много статей и книг. В дан-
ной лабораторной работе будет рассмотрено программирование
именно третьего вида сокетов (низкоуровневых сокетов). Иногда
бывает необходимо создать пакет, неважно какой — IP, TCP, UDP
или ICMP — с заданными служебными полями, будь то для ска-
нирования портов, прохождения через файервол, определения
операционной системы или просто проведения DOS-атаки. Для
этих целей подходят низкоуровневые («сырые») сокеты. Рассмот-
рим основы работы с данным типом сокетов и в ходе лаборатор-
ной работы напишем генератор IP-, TCP-, UDP- и ICMP-пакетов.
Для работы с ЛЛИ^сокетами, прежде всего, нам необходима биб-
лиотека Winsock 2.2 и знание основных структур, используемых
при работе с ними.
204
Лабораторный практикум
Данная структура содержит IP-адрес 4-й версии:
struct in_addr
I
in_addr_t s_addr;
};
Структура, содержащая адресную информацию о сокете:
struct sockaddr_in
{
u_int8_t sin_len;
sa_family_t sin_family;
in_port_t sin_port;
struct in_addr sin_addr;
int8_t sin_zero[8];
};
Далее коротко рассмотрим формат заголовков используемых
протоколов, а также структуры, описывающие эти заголовки.
2. Формат заголовков
2.1. Протокол IP (RFC791)
Заголовок данного протокола описывается следующей струк-
турой: struct ip_header
{ unsigned char ver_ihl; // Длина заголовка (4 бита) // (измеряется в словах по 32 бита) х // х Номер версии протокола (4 бита)
unsigned char tos; // Тип сервиса
unsigned short tlen; // Общая длина пакета
unsigned short id; // Идентификатор пакета
unsigned short flags_fo; // Управляющие флаги (3 бита) // х Смещение фрагмента (13 бит)
unsigned char ttl; // Время жизни пакета
unsigned char proto; // Протокол верхнего уровня
unsigned short сгс; // СПС-заголовка
unsigned int src_addr; // IP-адрес отправителя
unsigned }; int dst_addr; // IP-адрес получателя
Лабораторная работа Ле 4
205
Определим вспомогательные макроопределения:
// Версия 1Р-пакета
«define RS_IP_VERSION 0x40
// IP-флаги фрагментации
«define IP_FLAG_FO_MASK ОхЕООО
«define IP_FLAG_MORE_FRAG 0x2000
«define IP_FLAG_DONT_FRAG 0x4000
// Тип IP-сервиса
«define IP_T0S. 0x00 0x00
«define IP_T0S. .0x02 0x02
«define IP_T0S. .0x04 0x04
«define IP-TOS. .0x08 0x08
«define IP-TOS. .0x10 0x10
2.2. Протокол TCP (RFC 793)
Заголовок данного протокола описывается следующей струк-
турой:
struct tcp_header
{
unsigned short src_port; // Порт отправителя
unsigned short dst_port; // Порт получателя
unsigned int seq_n; // Номер очереди
unsigned int ack_n: // Номер подтверждения
unsigned char offset; // Смещение данных (4 бита)
// х Зарезервировано (4 бита)
unsigned char flags; // Зарезервировано (2 бита)
// х флаги (6 бит)
unsigned short win; // Размер окна
unsigned short сгс; // Контрольная сумма заголовка
unsigned short padding; // Дополнение до 20 байт
};
Определим вспомогательные макроопределения:
// TCP-флаги
«define TCP_FIN 1
«define TCP_SYN 2
«define TCP_RST 4
«define TCP_PSH 8
«define TCP_ACK 16
206
Лабораторный практикум
2.3. Протокол UDP (RFC 768)
Заголовок данного протокола описывается следующей струк-
турой:
struct udp_header
unsigned short src_port ; // Номер порта отправителя
unsigned short dstjort ; // Номер порта получателя
unsigned short length; // Длина дейтаграммы
unsigned short crc; // Контрольная сумма заголовка
2.4. Протокол ICMP (RFC 792)
Заголовок данного протокола описывается следующей струк-
турой:
struct icmp_header
{
unsigned char type; // Тип ICMP-пакета
unsigned char code; // Код ICMP-пакета
unsigned short crc ; // Контрольная сумма
union {
struct { unsigned chared, uc2, uc3, uc4; } s ue:
struct { unsigned short us1, us2; } s_us;
unsigned long s_ul;
} s_icmp; // Зависит от типа
};
Определим вспомогательные макроопределения:
// тип ICMP-пакета
«define ICMP_ECHO_REPLY О
«define ICMP_UNREACHABLE 3
«define ICMP_QUENCH 4
«define ICMP_REDIRECT 5
«define ICMP_ECH0 8
«define ICMP_TIME 11
«define ICMP_PARAMETER 12
«define ICMP_TIMESTAMP 13
«define ICMP_TIMESTAMP_REPLY 14
«define ICMP_INFORMATION- 15
«define ICMP_INFORMATION_REPLY 16
Лабораторная работа Ле 4
207
2
3
// ICMP-коды для ICMP типа ICMP_UNREACHABLE
«define ICMP_UNREACHABLE_NET О
«define ICMP_UNREACHABLE_HOST 1
«define ICMP_UNREACHABLE_PROTOCOL 2
«define ICMP_UNREACHABLE_PORT 3
«define ICMP_UNREACHABLE_FRAGMENTATION 4
«define ICMP_UNREACHABLE_SOURCE 5
«define ICMP_UNREACHABLE_SIZE 8
// ICMP-коды для ICMP типа ICMP_TIME
«define ICMP_TIME_TRANSIT 0
«define ICMP_TIME_FRAGMENT 1
// ICMP-коды для ICMP типа ICMP_REDIRECT
«define ICMP_REDIRECT_NETWORK 0
«define ICMP_REDIRECT_HOST 1
«define ICMP_REDIRECT_SERVICE_NETWORK 2
«define ICMP_REDIRECT_SERVICEJOST 3
3. Псевдозаголовок для TCP- и UDP-пакетов
Также необходимо ввести структуру псевдозаголовка, которая
позволит вычислять контрольную сумму в TCP- и {//)Р-пакетах.
struct pseudo_header
{
unsigned int src_addr; // Адрес отправителя
unsigned int dst_addr; // Адрес получателя
unsigned char zero ; // Начальная установка
unsigned char proto; // Протокол
unsigned short length; // Длина заголовка
};
4. Порядок байтов при работе с сокетами
Далее требуется вспомнить порядок байт при работе с сокета-
ми. Существуют сетевой (network) и хостовый (host) порядки бай-
та. Например, адреса источника и назначения, порты источника
и назначения должны быть в сетевом порядке байта. Для перевода
из одного порядка байта используются следующие функции:
htons // "Host to Network Short"
htonl // "Host to Network Long"
ntohs // "Network to Host Short"
ntohl // "Network to Host Long"
208
Лабораторный практикум
«h» — означает хост, «п» — сеть, «s» — тип short, «1» — тип long.
Например, для того чтобы перевести порт назначения (25) из
хостового порядка байта в сетевой, необходимо сделать так:
htons(25);
Можно использовать эти функции для перевода любого из
полей TCP/IP-заголовка в сетевой порядок байта и обратно, но
для IP-адреса используется другая функция. В случае если есть
строка типа «192.168.1.1» и необходимо перевести ее в сетевой по-
рядок байта, то используется одна из следующих функций:
in_addr_t inet_addr(const char »ср);
int inet_aton(const char *cp, struct in_addr *addr);
Использование последней функции предпочтительней, по-
скольку inet_addr устарела.
5. Контрольная сумма пакета
5.1. IP- и ICMP-пакеты
Рассмотрим вопрос о подсчете контрольных сумм в генери-
руемых пакетах. Контрольную сумму в IP- и /СМР-пакетах счи-
тает следующая функция:
unsigned short rs_crc (unsigned short * buffer, int length)
{
unsigned long crc = 0;
// Вычисление CRC
while (length > 1)
{
crc += *buffer++;
length -= sizeof (unsigned short);
}
if (length) crc += ‘(unsigned char*) buffer;
// Закончить вычисления
crc = (crc > 16) + (crc & Oxffff);
crc += (crc > 16);
// Возвращаем инвертированное значение
return (unsigned short)(~crc);
Лабораторная работа № 4
209
5.2. TCP- и UDP-пакеты
Для подсчета CRC в TCP- и UDP-пакетах необходимо вос-
пользоваться следующей функцией, которая сначала создает
псевдозаголовок, а уже потом вычисляет контрольную сумму,
unsigned short rs_pseudo_crc( char «data, int data_length,
unsigned int srcaddr,
unsigned int dstaddr,
int packet_length,
unsigned char proto)
{
char » buffer;
unsigned int full_length;
unsigned char header_length;
struct pseudo_header ph;
unsigned short pcrc = 0;
// Заполнение структуры псевдозаголовка
ph.src_addr = src_addr;
ph.dst_addr = dst_addr;
ph.zero = 0;
ph.proto = proto;
ph.length = htons (packet_length);
header_length = sizeof (struct pseudo_header);
full_length = header_length + data_length;
buffer =(char *) calloc (full_length, sizeof (char));
// Генерация псевдозаголовка
memcpy (buffer, &ph, header_length);
memcpy (buffer + header_length, data, data_length);
// Вычисление CRC
p_crc = rscrc ((unsigned short*) buffer, fulllength),
free (buffer);
return p_crc;
}
Теперь, когда мы имеем всю необходимую справочную ин-
формацию, можем приступать непосредственно к описанию ос-
новных функций, необходимых для работы с ЯЛИ'-сокетами.
210
Лабораторный практикум
6. Принципы работы с RA W-сокетами
6.1. Инициализация библиотеки Winsock
Первым шагом будет инициализация библиотеки Winsock 2.2.
int rs_init (int v_major, int v_minor)
WSAOATA wsadata;
// Инициализация Win Sock заданной версии
if (WSAStartup(MAKEWORD(v_major, v_minor), &wsadata))
{
return WSAGetLastError();
}
// Проверка версии WinSock
if (LOBYTE(wsadata.wVersion) != v_minor ||
HIBYTE(wsadata.wVersion) != v_major)
{
rs_exit();
return WSAGetLastError();
}
return 0;
}
6.2. Создание RAW-сокета
Создать RAW-сокет можно следующим образом:
WSASocket (AF_INET, SOCK_RAW, IPPROTO_RAW, NULL, 0,
WSA_FLAG_OVERLAPPED);
6.3. Настройка RAW-сокета
Установки опции TOS для сокета:
int rs_set_tos (SOCKET s, unsigned char new_tos)
{
int tos = new_tos;
int tos_len = sizeof (tos);
int per=setsockopt(s, IPPROTO_IP, 3, (char *)&tos,
tos_len);
if (per == SOCKET.ERROR)
{
return WSAGetLastErrorO;
}
return 0;
Лабораторная работа № 4
211
Установка опции RAW для сокета:
int rs_set_raw (SOCKET s)
{
unsigned int use_own_header = 1;
// Установка опции RAW для сокета, что говорит о том,
// что мы вручную будем формировать заголовки пакетов
if ( setsockopt (s, IPPROTO_IP, 2, (char*)&use_own_header,
sizeof(use_own_header))== SOCKET_ERROR)
{
return WSAGetLastErrorO;
}
return 0;
}
Используя описанные методы, можно создать RAW-сокет
следующим образом:
// Создание RAW-сокета
SOCKET s = WSASocket (AF_INET, S0CK_RAW, IPPROTO_RAW, NULL, 0,
WSA_FLAG_OVERLAPPED);
rs_set_tos (s, 0);
rs_set_raw (s);
6.4. Отправка пакетов
Далее необходимо объявить структуры заголовков создавае-
мых пакетов. После этого производится заполнение заголовка
IP-пакета. На следующем шаге создаем RAW-сокет, и если нет
вложений протоколов верхнего уровня в пакет IP, то отправляем
его, используя следующую функцию:
int rs_send_ip (SOCKET s, struct ip_header iph,
unsigned char * data,
int data_length,
unsigned short dst_port_raw)
{
char * buffer;
int result;
sockaddr_in target;
unsigned char header_length;
unsigned int packet_length;
212
Лабораторный практикум
memset (&target, 0, sizeof (target));
target.sin_family = AF_INET;
target.sin_addr.s_addr = iph.dst_addr;
target.sin_port = dst_port_raw;
// Вычисление длины и заголовка пакета
header_length = sizeof (struct ip_header);
packetjength = headerlength + data_length;
// Установка CRC
iph.crc = 0;
// Заполнение некоторых полей заголовка IP
iph.ver_ihl = RS_IP_VERSION;
// Если длина пакета не задана, то длина пакета
// приравнивается к длине заголовка
if (!(iph.ver_ihl & OxOF))
iph.ver_ihl |= OxOF & (header_length / 4);
buffer =(char *) calloc (packet_length, sizeof (char)):
// Копирование заголовка пакета в буфер ( СПС равно 0)
memcpy (buffer, &iph, sizeof (struct ip_header));
// Копирование данных в буфер
if (data) memcpy (buffer + header_length, data,
data_length);
// Вычисление CRC
iph.crc = rs_crc((unsigned short *) buffer,
packet_length);
// Копирование заголовка пакета в буфер (CRC посчитана)
memcpy (buffer, &iph, sizeof (struct ip_header));
// Отправка IP-пакета в сеть
result = sendto ( s, buffer, packet_length, 0,
(struct sockaddr *)&target,
sizeof (target));
free (buffer);
return result;
}
Лабораторная работа Ле 4
213
Если в /P-пакет вложен пакет протокола более высокого
уровня, то сначала вызываем функцию заполнения и отправки
пакета протокола более высокого уровня, которая в свою очередь
вызовет функцию генерации и отправки ZP-пакета в сеть, причем
в качестве вложенных данных в /P-пакет будет передан сформи-
рованный заголовок протокола более высокого уровня. Для гене-
рации пакетов TCP, UDP и ICMP служат следующие функции,
соответственно:
int rssend-tcp (SOCKET s, struct ip_header iph,
struct tcp_header tcph,
unsigned char * data,
int data_length)
{
char * buffer;
int result;
unsigned char header_length;
unsigned int packet-length;
// Вычисление длин пакета и заголовка
headerlength = sizeof (struct tcpheader);
packet-length = header_length + data_length;
// Установка CRC
tcph.crc = 0;
// Установка поля offset
tcph.offset = OxFO & ((headerlength / 4) < 4);
buffer =(char *) calloc (packetlength, sizeof (char));
// Копирование заголовка пакета в буфер ( CRC равно 0)
memcpy (buffer, &tcph, sizeof (struct tcp_header));
// Копирование протокола более высокого уровня (данных)
if (data) memcpy (buffer + header_length, data,
datalength);
// Вычисление CRC
tcph.crc = rs_pseudo_crc (buffer, packet-length,
iph. src_addr,
iph.dst_addr,
packetlength,
214
Лабораторный практикум
IPPROTO.TCP);
// Копирование заголовка пакета в буфер (CRC посчитано)
memcpy (buffer, &tcph, sizeof (struct tcp_header));
// Посылка IP-пакета с вложенным ТСР-пакетом
result = rs_send_ip (s, iph, buffer, packet_length,
tcph.dst_port);
free (buffer);
return result;
}
int rs_send_udp (SOCKET s, struct ip_header iph,
struct udp_header udph,
unsigned char * data,
int data_length)
{
char * buffer;
int result;
unsigned char header_length;
unsigned int packet_length;
// Вычисление длин пакета и заголовка
header_length = sizeof (struct udp_header);
packet_length = header_length + data_length;
// Установка CRC
udph.crc = 0;
// Если длина пакета не задана, то длина пакета
// приравнивается к длине заголовка
if (!udph.length) udph.length = htons (packet-length);
buffer =(char *) calloc (packet-length, sizeof (char));
// Копирование заголовка пакета в буфер (CRC равно 0)
memcpy (buffer, &udph, sizeof (struct udp_header));
// Копирование протокола более высокого уровня (данных)
if (data) memcpy (buffer + header_length, data,
data_length);
Лабораторная работа № 4
215
// Вычисление CRC
udph.crc = rs_pseudo_crc (buffer, packet_length,
iph.src_addr,
iph.dst_addr,
packet_length,
IPPROTOJJDP);
// Копирование заголовка пакета в буфер (CRC посчитано)
memcpy (buffer, &udph, sizeof (struct udp_header));
// Отправка IP-пакета с вложенным UDP-пакетом
result = rs_send_ip (s, iph, buffer, packet_length,
udph.dst_port);
free (buffer);
return result;
int rs_send_icmp (SOCKET s, struct ip_header iph,
struct icmp_header icmph,
unsigned char * data,
int data_length)
{
char * buffer;
int result;
unsigned char header_length;
unsigned int packet_length;
data_length = 0;
// Вычисление длин пакета и заголовка
header_length = sizeof (struct icmp_header);
packet_length = header_length + data_length;
icmph.crc = 0;
buffer = (char *)calloc (packet_length, sizeof (char));
// Копирование заголовка пакета в буфер ( CRC равно 0)
memcpy (buffer, &icmph, sizeof (struct icmp_header));
// Вычисление CRC
icmph.crc = rs_crc ((unsigned short *) buffer,
packet_length);
216
Лабораторный практикум
// Копирование заголовка пакета в буфер (CRC посчитано)
memcpy (buffer, Sicmph, sizeof (struct icmp_header));
// Отправка IP-пакета с вложенным ICMP-пакетом
result = rs_send_ip (s, iph, buffer, packet_length, 0);
free (buffer);
return result;
6.5. Закрытие соединения
(См. лабораторную работу № 2.)
6.6. Деинициализация библиотеки Winsock
Опишем функцию деинициализации библиотеки Winsock:
int rs_exit(void)
{
// Закрытие библиотеки Winsock
WSACleanup ();
return 0;
7. Заключение
Описанный механизм позволяет создавать полноценные при-
ложения для работы с RAW-сокетами без использования допол-
нительных библиотек. Однако необходимо уточнить, что для ра-
боты с RAW-сокетами, необходимы права администратора.
8. Задания для самостоятельной работы
Вариант № 1
Реализация генератора IP-пакетов с использованием библио-
теки Winsock2 под ОС Windows и стандарта RFC 791.
Вариант № 2
Реализация генератора UDP-пакетов с использованием биб-
лиотеки Winsock2 под ОС Windows и стандарта RFC 768.
Лабораторная работа № 4
217
Вариант № 3
Реализация генератора TCP-пакетов с использованием биб-
лиотеки Winsock2 под ОС Windows и стандарта RFC 793.
Вариант № 4
Реализация генератора ICMP-пакетов с использованием биб-
лиотеки Winsock2 под ОС Windows и стандарта RFC 792.
Контрольные вопросы
1. Что такое Winsock?
2. Что такое сокет?
3. Какие сокеты называются «сырыми»?
4. Расскажите коротко о стандарте RFC 791.
5. Расскажите коротко о стандарте RFC 768
6. Расскажите коротко о стандарте RFC 793.
7. Расскажите коротко о стандарте RFC 792.
218
Лабораторный практикум
Лабораторная работа № 5
Реализация эхо-сообщения ICMP на базе RAW Socket
Цель работы: 1. Изучить принципы работы с протоколом
ICMP на RAW-сокетах.
2. Научиться формировать ICMP эхо-сообщения.
Продолжительность работы — 4 часа.
1. Общая характеристика протокола ICMP
Протокол обмена управляющими сообщениями ICMP
(Internet Control Message Protocol) позволяет маршрутизатору сооб-
щить конечному узлу об ошибках, с которыми машрутизатор
столкнулся при передаче какого-либо IP-пакета от данного ко-
нечного узла.
Управляющие сообщения ICMP не могут направляться про-
межуточному маршрутизатору, который участвовал в передаче то-
го пакета, с которым возникли проблемы. Для такой посылки
просто нет адресной информации — пакет несет в себе только ад-
рес источника и адрес назначения, не фиксируя адреса промежу-
точных маршрутизаторов.
Протокол ICMP — это протокол сообщения об ошибках, а не
протокол коррекции ошибок. Конечный узел может предпринять
некоторые действия для того, чтобы ошибка больше не возника-
ла, но эти действия протоколом ICMP не регламентируются.
Каждое сообщение протокола ICMP передается по сети внут-
ри пакета IP. Пакеты IP с сообщениями ICMP маршрутизируют-
ся точно так же, как и любые другие пакеты, без приоритетов, по-
этому они также могут теряться. Кроме того, в загруженной сети
они могут вызывать дополнительную загрузку маршрутизаторов.
Для того чтобы не вызывать лавины сообщения об ошибках, по-
тери пакетов IP, переносящие сообщения ICMP об ошибках, не
могут порождать новые сообщения ICMP.
2. Формат сообщений протокола ICMP
Существует несколько типов сообщений ICMP. Каждый тип
сообщения имеет свой формат, при этом все они начинаются
с общих трех полей: 8-битового целого числа, обозначающего тип
сообщения (TYPE), 8-битового поля кода (CODE), который кон-
Лабораторная работа № 5
219
Таблица Л5.1. Коды типов сообщений
Значение Тип сообщения
0 Эхо-ответ (Echo Replay)
3 Узел назначения недостижим (Destination Unreachable)
4 Подавление источника (Source Quench)
5 Перенаправление маршрута (Redirect)
8 Эхо-запрос (Echo Request)
11 Истечение времени дейтаграммы (Time Exceeded fora Datagram)
12 Проблема с параметром пакета (Parameter Problem on a Datagram)
13 Запрос отметки времени (Timestamp Request)
14 Ответ отметки времени (Timestamp Replay)
17 Запрос маски (Address Mask Request)
18 Ответ маски (Address Mask Replay)
кретизирует назначение сообщения, и 16-битового поля кон-
трольной суммы (CHECKSUM). Кроме того, сообщение ICMP
всегда содержит заголовок и первые 64 бита данных пакета IP, ко-
торый вызвал ошибку. Это делается для того, чтобы узел-отпра-
витель смог более точно проанализировать причину ошибки, так
как все протоколы прикладного уровня стека TCP/IP содержат
наиболее важную информацию для анализа в первых 64 битах
своих сообщений.
Поле типа сообщения может иметь следующие значения
(табл. Л5.1).
Как видно из используемых типов сообщений, протокол
ICMP представляет собой некоторое объединение протоколов,
решающих свои узкие задачи.
3. Эхо-протокол
Протокол ICMP предоставляет сетевым администраторам
средства для тестирования достижимости узлов сети. Эти средст-
ва представляют собой очень простой эхо-протокол, включаю-
щий обмен двумя типами сообщений: эхо-запрос и эхо-ответ.
Компьютер или маршрутизатор посылает по интерсети эхо-за-
220
Лабораторный практикум
прос, в котором указывают IP-адрес узла, достижимость которого
нужно проверить. Узел, который получает эхо-запрос, формирует
и отправляет эхо-ответ и возвращает сообщение узлу-отправите-
лю запроса. В запросе могут содержаться некоторые данные, ко-
торые должны быть возвращены в ответе. Так как эхо-запрос
и эхо-ответ передаются по сети внутри IP-пакетов, то их успеш-
ная доставка означает нормальное функционирование всей
транспортной системы интерсети.
Во многих операционных системах используется утилита ping,
которая предназначена для тестирования достижимости узлов.
Эта утилита обычно посылает серию эхо-запросов к тестируемо-
му узлу и предоставляет пользователю статистику об утерянных
эхо-ответах и среднем времени реакции сети на запросы.
4. Сообщения о недостижимости узла назначения
Когда маршрутизатор не может передать или доставить IP-па-
кет, он отсылает узлу, отправившему этот пакет, сообщение «Узел
назначения недостижим» (тип сообщения — 3). Это сообщение
содержит в поле кода значение, уточняющее причину, по которой
пакет не был доставлен. Причина кодируется следующим образом
(табл. Л5.2).
Маршрутизатор, обнаруживший по какой-либо причине, что
он не может передать IP-пакет далее по сети, должен отправить
ICMP-сообщение узлу-источнику и только потом отбросить пакет.
Кроме причины ощибки, ICMP-сообщение включает также заго-
ловок недоставленного пакета и его первые 64 бита поля данных.
Узел или сеть назначения могут быть недостижимы из-за вре-
менной неработоспособности аппаратуры, из-за того, что отпра-
витель указал неверный адрес назначения, а также из-за того, что
маршрутизатор не имеет данных о маршруте к сети назначения.
Недостижимость протокола и порта означают отсутствие реа-
лизации какого-либо протокола прикладного уровня в узле на-
значения или же отсутствие открытого порта протоколов UDP
или TCP в узле назначения.
Ошибка фрагментации возникает тогда, когда отправитель по-
слал в сеть пакет с признаком DF, запрещающим фрагментацию,
а маршрутизатор столкнулся с необходимостью передачи этого па-
кета в сеть со значением MTU, меньшим, чем размер пакета.
Лабораторная работа № 5
221
Таблица Л5.2. Коды ошибок
Код Причина
0 Сеть недостижима
1 Узел недостижим
2 Протокол недостижим
3 Порт недостижим
4 Требуется фрагментация, а бит DF установлен
5 Ошибка в маршруте, заданном источником
6 Сеть назначения неизвестна
7 Узел назначения неизвестен
8 Узел-источник изолирован
9 Взаимодействие с сетью назначения административно запрещено
10 Взаимодействие с узлом назначения административно запрещено
11 Сеть недостижима для заданного класса сервиса
12 Узел недостижим для заданного класса сервиса
5. Перенаправление маршрута
Маршрутные таблицы у компьютеров обычно являются ста-
тическими, так как конфигурируются администратором сети,
а у маршрутизаторов — динамическими, формируемыми автома-
тически с помощью протоколов обмена маршрутной информа-
ции. Поэтому с течением времени при изменении топологии сети
маршрутные таблицы компьютеров могут устаревать. Кроме того,
эти таблицы обычно содержат минимум информации, например
только адреса нескольких маршрутизаторов.
Для корректировки поведения компьютеров маршрутизатор
может использовать сообщение протокола ICMP, называемое
«Перенаправление маршрута» (Redirect).
Это сообщение посылается в том случае, если маршрутизатор
видит, что компьютер отправляет пакет некоторой сети назначе-
ния нерациональным образом, т. е. не тому маршрутизатору ло-
кальной сети, от которого начинается более короткий маршрут
к сети назначения.
Механизм перенаправления протокола ICMP позволяет ком-
пьютерам содержать в конфигурационном файле только IP-адре-
са его локальных маршрутизаторов. С помощью сообщений о пе-
222
Лабораторный практикум
ренаправлении маршрутизаторы будут сообщать компьютеру всю
необходимую ему информацию о том, какому маршрутизатору
следует отправлять пакеты для той или иной сети назначения.
То есть маршрутизаторы передадут компьютеру нужную ему часть
их таблиц маршрутизации.
В сообщении «Перенаправление маршрута» маршрутизатор
помешает IP-адрес маршрутизатора, которым нужно пользовать-
ся в дальнейшем, и заголовок исходного пакета с первыми 64 би-
тами его поля данных. Из заголовка пакета узел узнает, для какой
сети необходимо пользоваться указанным маршрутизатором.
6. Пример программы
Программа из данного примера основана на коде из лабора-
торной работы №4.
// Напечатать код последней ошибки
void print_WSAGetLastError(const char* function_name)
{
int res = WSAGetLastError ();
printf ("\nERR0R: \tFunction \"%s\" call failed, \n
\tWSAGetLastError() return error code: dec = [%d], hex = [0x%0x]\n”,
function_name ,res, res);
}
// Создать сокет
SOCKET rs_create_socket(void)
{
SOCKET socket = WSASocket (AF_INET, S0CK_RAW, IPPR0T0_RAW,NULL, 0,
WSA_FLAG_OVERLAPPED);
return socket;
}
// Закрыть сокет
int rs_close_socket(SOCKET s)
{
return closesocket(s);
}
int main()
{
// Инициализация
if (rs_init(2,2))
Лабораторная работа № 5
223
{
print_WSAGetLastError(." rs_init");
return -1;
}
// Создание сокета
SOCKET s = rs_create_socket();
if(INVALID_SOCKET == s)
{
print_WSAGetLastError("rs_init;
rs_exit();
return -1;
}
// Установки опции TOS для сокета
if(rs_set_tos (s, 0))
{
print_WSAGetLastError("rs_set_tos");
rs_exit();
return -1;
}
// Установка опции RAW для сокета
if(rs_set_raw (s))
{
print_WSAGetLastError(" rs_set_raw'');
rs_exit();
return -1;
}
ip_header iph;
icmp_header icmph;
char src_ip[] = <наш 1Р-адрео>;
char dst_ip[] = <1Р-адрес цели>;
int header_size = sizeof(ip_header) / 4;
// Заполнение заголовка IP-пакета
iph.ver_ihl = (OxFO & RS_IP_VERSION) | (OxOF & header_size);
iph.tlen = htons(60); // Длина в октетах
iph.id = htons(l); // Идентификатор
iph.ttl = 255; // TTL
// "He фрагментировать"
224
Лабораторный практикум
iph.flags_fo = htons((IP_FLAG_FO_MASK & IP_FLAG_DONT_FRAG));
iph.tos = IP_T0S_0x00;
iph.src_addr = inet_addr(src_ip);
iph.dst_addr = inet_addr(dst_ip);
// Заполняем заголовок ICMP-пакета
iph.proto = IPPR0T0_ICMP;
icmph.type = ICMP_ECH0;
// Отправляем ICMP-пакет
if(SOCKETERROR == rs_send_icmp (s, iph, icmph, NULL, 0))
{
print_WSAGetLastError(”rs_send_icmp");
}
// Прием ICMP-ответа
// ...
// Закрытие сокета
rs_close_socket(s);
// Деинициализация
rs_exit();
return 0;
7. Задание для самостоятельной работы
Необходимо разработать программу для определения вре-
мени двойного оборота пакета до тестируемого узла и обратно
(аналог утилиты Ping), используя RAW-socket (1СМР_ЕСНО
и ICMPECHOREPLY).
Контрольные вопросы
1. Что такое Winsock?
2. Что такое сокет?
3. Какие сокеты называются «сырыми сокетами»?
4. Расскажите коротко о стандарте RFC 792.
Лабораторная работа Лг 6
225
Лабораторная работа № 6
Программирование сетевых приложений
посредством протокола IPX
Цель работы: изучить протокол IPX и получить навыки про-
граммирования в сетях под управлением Novell Netware.
Продолжительность работы — 4 часа.
1. Краткие теоретические сведения
При разработке современных пользовательских приложений
программистам необходимо предусматривать возможность их ис-
пользования в локальных сетях — LAN (Local Area Network). Ло-
кальные сети позволяют крупным компаниям с минимальными
издержками организовать пересылку различных данных с одних
компьютеров на другие. Их использование существенно упрощает
процесс обмена информацией между компьютерами и, как следст-
вие, ускоряет выполнение основных функций сотрудниками.
При решении такого рода задач зачастую неудобно или про-
сто невозможно использовать универсальное программное обес-
печение и возникает необходимость в создании своего собствен-
ного ПО, которое будет отвечать всем требованиям, предъявляе-
мым спецификой поставленной задачи. Такими требованиями
могут быть: надежность обмена, скорость обмена, зашита инфор-
мации, возможность пересылки между несколькими компьютера-
ми одновременно и т. п.
Эта лабораторная работа направлена на получение навыков
использования протокола обмена IPX для создания эффективных
программ в среде Novell Netware.
1.1. Общие сведения о протоколе IPX
Основное внимание в лабораторной работе будет уделено не
техническим особенностям локальных сетей Novell, а программи-
рованию посредством универсального протокола обмена инфор-
мацией IPX. Данный протокол — The Advanced Netware Internet-
work Packet Exchange (IPX) Protocol является пратическим осуще-
ствлением протокола компании Xerox — Xerox’s Internetwork
Packet Protocol. Целью протокола IPX является предоставление
приложениям, работающим на рабочих станциях, возможности
226
Лабораторный практикум
связи с другими рабочими станциями, серверами или устройства-
ми, подключенными к сети.
IPX — это служба, позволяющая приложениям посылать
и получать индивидуальные пакеты сети. В сетях Advanced
NetWare (сети, составленные из одной или более локальных се-
тей, использующих Advanced NetWare) каждый узел (устройство,
присоединенное к сети) имеет уникальный адрес в сети. Исполь-
зуя IPX, рабочие станции NetWare могут посылать или получать
пакеты от любого узла сети (рис. Л6.1). Пересылка пакетов между
узлами, которая происходит по-разному на физически разных се-
тях, по большей части автоматическая и программно прозрачная.
Эта прозрачность осуществляется с помощью гибкости IPX в со-
единении со службами мостов Advanced NetWare.
Сетевые устройства предпринимают максимум усилий по фи-
зической отправке пакетов, но не гарантируют отправку. Осуще-
ствление надежной отправки потока данных и других протоколов
более высокого уровня может быть проведено на основе протоко-
ла IPX при необходимости для специальных приложений. Прото-
кол IPX предназначается для использования в качестве основы,
на которой может быть создан ряд сложных приложений, вклю-
чая коммуникационные серверы, концентраторы между PC
и центральными ЭВМ (mainframe), или системы прямого сообще-
ния между рабочими станциями.
Станция 1 Станция 2
Рис. Л6.1. Схема, поясняющая взаимодействие программ
Лабораторная работа № 6
227
IPX полностью поддерживается всеми топологиями LAN, ко-
торые поддерживаются Advanced NetWare v2.0. Этот протокол
предоставляет полную прозрачность и постоянство в любой сети
Advanced NetWare.
1.2. Описание протокола IPX
Структура пакетов сети определяется сетевым стандартом
Xerox — Xerox Network Standard (XNS). Она будет кратко описана
ниже; интересующиеся могут обратиться к следующему докумен-
ту корпорации Xerox: «Internetwork Transport Protocol» (Xerox
Corporation, Xerox System Integration Standard; Stamford; Connecti-
cut; December 1981; XSIS-028112) для более детального рассмот-
рения пакета протокола XNS.
Пакет IPX состоит из 30 байтового заголовка с последующими
данными, занимающими от 0 до 546 байт. Таким образом, мини-
мальная длина пакета — 30 байт, а максимальная — 576 байт.
Содержание и структура области данных в пакете полностью
являются заботой приложения, использующего IPX, и могут на-
ходиться в нужном формате.
1.3. Структура заголовка пакета IPX
Заголовок IPX (первые 30 байт всех пакетов) имеет следую-
щий формат (табл. Л6.1)
Таблица Л6.1
Смешение Поле Размер,байт Тип данных
0 Checksum 2 Целое вида h-1
2 Length 2 Целое без знака вида h-l
4 Transport Control 1 Целое без знака
5 Packet Type 1 Целое без знака
6 Dest. Network 4 Целое без знака вида h-l
10 Dest. Node 6
16 Dest. Socket 2
18 Source Network 4
22 Source Node 6
. 28 Source Socket 2
228
Лабораторный практикум
Заметим, что числовые поля, состоящие из более чем 1 байта,
могут быть представлены в двух противоположных форматах:
high-low (h-1) и low-high. Числа вида high-low содержат самый
старший байт в первом байте поля, следующий по старшинству —
во втором, и т. д., с самым младшим байтом в конце. Числа вида
low-high хранятся в противоположном порядке.
1.4. Описание полей заголовка пакета IPX
Содержимое полей заголовка пакета IPX используется раз-
личными сетевыми службами и должно соответствовать следую-
щему:
Checksum
Это поле является контрольной суммой 16-битовых слов в за-
головке. Поле содержит FFFFh (-ноль), если контрольная сумма
не требуется. Если вычисленная контрольная сумма получается
равной FFFFh, она должна быть изменена на OOOOh (+ноль).
Заметим, что это контрольная сумма только 30-байтового за-
головка. Если приложениям нужно проверять контрольную сум-
му своих данных, они должны разместить ее каким-либо образом
внутри области данных.
Имеющаяся оболочка NetWare может не проверять контроль-
ную сумму при получении пакета. Если нужна проверка, она долж-
на производиться приложением, которому посылается пакет.
Length
Это поле содержит длину полного сетевого пакета, которая
является длиной заголовка плюс длина области данных. Таким
образом, минимальная длина пакета — 30 байт, а максималь-
ная — 576 байт.
Transport Control
Это поле используется Advanced Netware Internetwork Bridges
и всегда устанавливается в ноль прежде, чем пакет послан.
Packet Туре
Это поле указывает «тип» службы, предлагаемой или требуе-
мой пакетом (табл. Л6.2).
Лабораторная работа Хе 6
229
Таблица Л6.2
Тип пакета Описание
0 Обычный IPX-пакет
1 Пакете информацией о маршрутах, используется протоколом обмена маршрутной информации RIP (Routing Information Protocol)
2 Квитанция-подтверждение получения данных
3 Сообщение об ошибке передачи данных
4 Пакет используется для передачи информации прикладной программы
5 Служебное сообщение протокола последовательного пакетного обме на SPX (Sequence Packet exchange)
17 Сообщение протокола ядра сетевой операционной системы NetWare — NCP (NetWare Core Protocol)
Пользователям рекомендуется использовать пакеты типа О
или 4.
Destination Network
Это поле содержит номер сети узла, которому адресован па-
кет.
При использовании Advanced NetWare соединенным сетям
присваиваются 4-байтовые номера. Каждая сеть в общей сети
должна иметь уникальный номер.
Если это поле установлено в 0, узел адресата считается распо-
лагающимся в физической сети, к которой исходный узел при-
соединен; пакет будет послан без вовлечения Advanced Netware
Internetwork Bridge.
Destination Node
Это поле содержит 6-байтовое число, которое идентифициру-
ет физический адрес (на сети адресата) узла, которому предназна-
чен пакет.
Заметим, что не все физические топологии LAN используют
одинаковый размер поля адреса. Узел на сети EtherNet потребо-
вал бы все 6 байт для определения адреса, в то время как узел на
сети OmniNet потребовал бы только 1 байт.
230
Лабораторный практикум
Если физическая сеть нуждается менее чем в 6 байтах, чтобы
определить адрес узла, то необходимая часть адреса должна за-
нять наименьшую значащую (последнюю) часть этого поля,
и первые байты поля должны быть установлены в нули.
Установка всех шести байтов в FFh указывает, что пакет дол-
жен быть передан всем узлам на определенной сети. Передача
всем узлам в сети может поддерживаться или нет в зависимости
от физических характеристик (т. е. поддержка обшей передачи)
сети, которой предназначен пакет.
Destination Socket
Это поле содержит адрес сокета, которому предназначен па-
кет.
Номера сокетов используются для идентификации участни-
ков информационного взаимодействия при мультиплексирова-
нии пакетов, отправляемых с одного сокета.
Сокеты с номерами ниже 3000 (десятичное) рассматриваются
как «общеизвестные» сокеты со статически назначенными номе-
рами, в то время как сокеты с номерами большими, чем 3000,
считаются динамически присваиваемыми.
Source Network
Это поле содержит номер сети LAN, к которой присоединен
узел, инициировавший пакет.
Это поле может содержать значение ноль, указывая «неиз-
вестный» номер сети, к которому исходный узел физически при-
соединен.
Все пакеты с нулем в этом поле, передаваемые через Advanced
Netware Internetwork Bridge, будут иметь в этом поле реальный ис-
ходный номер сети. Таким образом, когда пакет получен от узла
с другой сети, поле Source Network будет всегда устанавливаться
правильно; только пакеты, инициированные в узле той же самой
сети, могут все еще содержать значение нуля в этом поле.
Source Node
Это поле содержит физический адрес узла, из которого ини-
циирован пакет.
Лабораторная работа № 6
231
Сколько байтов этого адреса фактически используются, опре-
деляет физическая сеть, к которой присоединен узел (аналогично
содержимому поля Destination Node).
Source socket
Это поле содержит адрес сокета, используемый программным
обеспечением, которое инициировало пакет. Данное поле ис-
пользуется для идентификации участников информационного
взаимодействия при демультиплексировании пакетов, пришед-
ших на один и тот же сокет.
2. События и блоки управления событиями
Блок Управления Событием (Event Control Block, ЕСВ) —
структура данных, которая содержит информацию, требуемую
для активации некоторых желательных операций. Почти все
функции IPX работают через блоки ЕСВ и информацию, которую
они предоставляют. Все события имеют связанные с ними блоки
ЕСВ. Например, когда прикладная программа желает передать
IPX-пакет, она должна сначала подготовить ЕСВ, который опи-
сывает, где получить данные пакета. Завершенная посылка пакета
представляет собой «событие посылки IPX».
Когда прикладная программа желает получать пакеты, она
должна сделать один или несколько ECBs доступными IPX, что-
бы описать, где сохранить данные получаемого пакета. Получе-
ние пакета вызовет «событие получения IPX».
Имеется два метода, с помощью которых событие может быть
обнаружено и обработано прикладной программой: опрос флага
«in use» или обеспечение сервисной подпрограммы, которая мо-
жет вызываться способом, подобным вызову прерывания.
Каждый ЕСВ имеет флаг состояния «in use». Этот флаг авто-
матически устанавливается в ненулевое значение всякий раз, ко-
гда ЕСВ передан функции IPX, чтобы запросить событие. Пока
этот флаг отличен от нуля, прикладная программа не должна из-
менять содержимое ЕСВ. Когда IPX закончил выполнять функ-
цию запроса, включающую определенный ЕСВ, флаг «in use» бу-
дет автоматически установлен в ноль. В этот момент прикладная
программа может управлять ЕСВ и связанными с ним данными.
232
Лабораторный практикум
Каждый ЕСВ обеспечивает способ определения адреса под-
программы обслуживания события (ESR), которая будет вызвана
подобно прерыванию, когда ожидаемое событие произошло. Ис-
пользование ESR является средством обработки событий в реаль-
ном времени.
2.1. Структура (ЕСВ)
В этом разделе будут описаны формат IPX-ЕСВ и значения
каждого поля (табл. Л6.3).
Как можно видеть в вышеописанной структуре, IPX-ЕСВ со-
стоит из двух частей.
Первая, фиксированная часть (длиной 36 байтов), содержит
поля состояния и информации, а также рабочую область для ис-
пользования IPX и сетевыми аппаратными драйверами.
Вторая, переменная часть, содержит список одного или
более буферных адресов фрагмента и их длин. Этот Fragment
Descriptor List определяет места в памяти, из которых будет соб-
ран пакет для посылки, или на которые пакет будет разбит после
получения.
Таблица Л6.3. Структура ЕСВ
Смещение Поле Размер,байт Тип данных
0 Link 4 Дальний адрес
4 ESR Address 4 Дальний адрес
8 In Use 1 Целое без знака
9 Completion Code 1 Целое без знака
10 Socket Number 2 Целое без знака (h-1)
12 1PX Workspace 4 N/A
16 Driver Workspace 12 N/A
28 Immediate Address 6 Целое без знака (h-1)
34 Fragment Count 2 Целое без знака (h-1)
30+п*6 Fragment Descriptor n*6 Структура
Address 4 Дальний адрес
Size 2 Целое без знака (h-1)
Лабораторная работа Ле 6 233
2.2. Описание Полей
Link
Это поле используется JPX, когда ЕСВ занят. Когда ЕСВ сво-
боден, прикладная программа может использовать это поле, если
требуется. Наиболее часто оно используется как поле связи для
хранения ЕСВ в списках или очередях.
ESR Address
Это поле содержит адрес подпрограммы обслуживания собы-
тия (ESR), определенного прикладной программой, которую вы-
зовет IPX, когда ожидаемое событие (пакет послан или получен)
будет завершено.
Если для обслуживания события подпрограмма не требуется,
то ESR Address должен быть установлен в пустой указатель (четы-
ре нулевых байта).
In Use
Это поле содержит значение, отличное от нуля всякий раз,
когда ЕСВ используется IPX (занят). Ниже приведен список воз-
можных значений и их смысл:
FFh — ЕСВ используется для передачи;
FEh — ЕСВ принимает на некотором сокете прибывающий
пакет;
FBh — событие получения или отправки произошло, но ЕСВ
находится во временной задерживающей очереди, ожидая обра-
ботки.
IPX сбросит это поле в ноль после завершения запроса.
Completion Code
Это поле устанавливается IPX-подпрограммами, чтобы ука-
зать код возврата. Это поле не может считаться верным, пока IPX
не сбросил поле InUse в ноль. Когда ЕСВ передается IPX с целью
посылки пакета, может быть получен любой из следующих кодов
завершения:
00h — посылка была завершена успешно. Это не гарантирует
того, что пакет был получен успешно. Пакет может потеряться
где-нибудь по пути или там может не оказаться доступных буфе-
ров для получения;
234
Лабораторный практикум
FFh — физически невозможно послать пакет (отказ аппарат-
ных средств или сети);
FEh — пакет невозможно доставить (не обнаружен адресат,
нет доступных Internetwork Bridges или отказ аппаратных
средств);
FDh — неправильно сформированный пакет (общая длина
меньше 30 байт или больше 576 байт, первый фрагмент слишком
маленький для IPX-заголовка или Fragment Count — ноль);
FCh — запрос на посылку был отменен.
Если ЕСВ был передан IPX с целью прослушивания посту-
пающих пакетов, может быть получен любой из следующих кодов
завершения:
00h — пакет был получен успешно;
FFh — сокет закрыт. Сокет, который должен был слушать
IPX, не был открыт;
FDh — переполнение пакета. Пакет был получен, но Frag-
ment Count в ЕСВ был равен нулю, или доступное пространство,
описанное в Fragment Descriptor, было недостаточным для всего
пакета;
FCh — запрос на прослушивание пакета был отменен.
Socket Number
Поле содержит номер сокета, с которым связан этот ЕСВ. Ко-
гда ЕСВ используется для посылки, оно содержит сокет-отправи-
тель; при получении это поле содержит сокет, на котором пакет
был получен.
IPX Workspace
Это 4-байтовое поле зарезервировано для использования под-
программами IPX. Его не нужно инициализировать никакими зна-
чениями, и оно не должно изменяться, пока блок управления ис-
пользуется IPX-подпрограммами. Когда ЕСВ не используется IPX,
эта область может использоваться любым желаемым способом.
Driver Workspace
Это 12-байтовое поле зарезервировано для использования
физическими сетевыми драйверами. Его не нужно инициализи-
ровать никакими значениями, и оно не должно изменяться, пока
Лабораторная работа Ле 6
235
блок управления используется IPX-подпрограммами. Когда ЕСВ
не используется IPX, эта область может использоваться любым
желаемым способом.
Immediate Address
Это 6-байтовое поле содержит адрес узла, которому пакет был
только что послан или из которого он только что прибыл (это бу-
дет адрес Internetwork Bridge в локальной сети, если пакет не был
передан внутри локальной сети).
Fragment Count
Это поле содержит количество буферов фрагментов, на кото-
рые пакет должен быть разбит для пересылки, или количество бу-
феров, в которые полученный пакет должен быть сформирован.
Значение этого поля должно быть больше нуля. Значение 1 про-
сто указывает, что пакет должен быть послан (получен) в непре-
рывную область памяти. Другими словами, первый фрагмент со-
держит весь пакет.
Fragment Descriptor List
Fragment Descriptor точно идентифицирует, где находится
часть пакета, который будет послан, или куда поместить часть по-
лученного пакета. Fragment Descriptor имеет два составляющих
поля:
Address
Адрес буфера, из которого берутся данные пакета при посыл-
ке или куда помещается часть полученного пакета.
Size
Размер буфера фрагмента, на который указывает предшест-
вующий адрес.
Любой ЕСВ IPX должен иметь, по крайней мере, один Frag-
ment Descriptor и любое число дополнительных описателей, если
необходимо. Эти описатели составляют Fragment Descriptor List.
236
Лабораторный практикум
Позволяя «собирать» заголовки пакета и данные из несколь-
ких мест или «разбивать» по нескольким местам, функции IPX
устраняют необходимость в прикладных программах неоднократ-
ного копировании данных из разных мест.
Заметим, посылка и получение полных пакетов из/или в не-
прерывную область памяти могут быть выполнены установкой по-
ля Fragment Count в 1, используя только один Fragment Descriptor.
При посылке пакета IPX «соберет» содержимое пакета из про-
извольного числа фрагментов; тем не менее буфер фрагмента,
идентифицированный первым описанием в Fragment Descriptor
List, должен быть, по крайней мере, длиной 30 байт и содержать
полный заголовок пакета IPX. Общий размер пакета (сумма всех
размеров индивидуальных фрагментов) не должен превысить
576 байт.
3. Краткое описание функций IPX
В этом разделе указаны входные и выходные значения регист-
ров процессора х86.
3.1. Открыть сокет
Вход
Вх = Oh
Al = Флаг времени существования сокета
00h = Открыто, пока не завершена программа
FFh = Открыто, пока не закрыто
Ох = Номер гнезда
OOOOh = IPX сам назначает номер сокета
не ноль = открыть этот сокет
Выход
Al = Completion Code функции
00h = успешное открытие
FFh = гнездо уже открыто
FEh = таблица сокетов заполнена
Ох = Присвоенный номер сокета
Лабораторная работа № 6
237
Описание:
Эта функция открывает определенный сокет для использова-
ния приложением. В данной лабораторной работе используются
динамические номера сокетов и на входе Dx = OOOOh.
3.2. Закрыть сокет
Вход
Вх = 1h
Ох = Номер закрываемого сокета.
Выход
Ничего
Описание:
Эта функция закрывает указанный сокет.
3.3. Послать пакет
Вход
Вх = 3h
ES:DI = указатель на блок ЕСВ
В блоке ЕСВ поля ESR Address, Socket Number, Immediate Address,
Fragment Count и Fragment Descriptor List должны быть
инициализированы. В заголовке пакета IPX поля Packet Type, Destination
Network, Destination Node и Destinaton Socket должны быть
инициализированы.
Выход
Ничего
Описание:
Функция делает запрос на посылку пакета. Выполняется в ре-
альном времени.
3.4. Слушать пакет
Вход
Вх = 4h
ES:DI =указатель на ЕСВ
238
Лабораторный практикум
В ЕСВ поля ESR Address, Socket Number, Fragment Count, и Fragment
Descriptor List должны быть инициализированы.
Выход
Ничего
Описание:
Функция передает ЕСВ и описываемый им размер буфера IPX
для получения пакета. Сделав это, она передает управление при-
ложению. Функция работает также в фоновом режиме, т. е. не
ждет получения пакета.
Как и для всех фоновых функций IPX, выполнение функции
считается завершенным, когда флаг In Use = 0. Результат смот-
рится в поле Completion Code. Полученный пакет находится в
указанном буфере.
3.5. Отменить событие
Вход
Вх = 6h
ES:DI = указатель на ЕСВ, используемый IPX
Выход
Al = Completion code функции
00h, если событие отменено
FFh, если данный ЕСВ не использовался IPX
F9h, если невозможно отменить данное событие
Описание:
Эта функция отменяет событие.
3.6. Получить межсетевой адрес
Вход
Вх = 9h
ES:DI = указатель на 10-байтовый буфер
Выход
4-байтовый Network Number и 6-байтовый Node Address в указанном буфере
Описание:
Эта функция позволяет программе определить межсетевой ад-
рес узла, на котором она исполняется.
Лабораторная работа As 6
239
3.7. Передать управление
Вход
Вх = Ah
Выход
Ничего
Описание:
Эта функция передает управление IPX для ускорения его ра-
боты (IPX начинает работать в нефоновом режиме).
Очевидно, что это далеко не полный перечень функций про-
токола IPX. Здесь приведены лишь самые необходимые для вы-
полнения данной работы. Реализация этих и некоторых других
функций находится в модуле IPX.PAS, в комментариях которого
описаны форматы вызова нужных процедур.
Исходный текст модуля можно найти в приложении в конце
разработки. Там же находится пример программы по установке свя-
зи и обмену сообщениями, который можно использовать для напи-
сания собственной программы (основной файл — CHAT.PAS).
Для компиляции программы необходимо воспользоваться
транслятором Turbo Pascal.
4. Краткие указания к написанию программ в сети Novell
Процедура связи компьютеров по сети с помощью драйвера
IPX состоит из следующих шагов:
1. Установление соединения.
Открытие необходимых сокетов (обычно с разными номера-
ми) для принятия и посылки данных.
Цикл установления связи, в котором программы на двух ком-
пьютерах посылают всем пакеты, содержащие некоторое кодовое
слово и свой полный адрес, и одновременно принимают пакеты,
пытаясь найти в них свое кодовое слово.
Таким образом, программы узнают полный адрес оппонента.
Кодовое слово необходимо для того, чтобы программа смогла
найти среди всех пакетов, которые она получила, тот, который
предназначен ей и содержит адрес ее оппонента.
240
Лабораторный практикум
2. Основной цикл (Пересылка данных).
В этом цикле программа посылает и/или принимает данные,
используя сокеты, предназначенные для посылки и приема (номе-
ра их указаны в вариантах заданий). При работе с оппонентом ис-
пользуется адрес, полученный на этапе установления соединения.
3. Окончание связи.
Закрытие всех сокетов, открытых программой.
5. Варианты лабораторных заданий
Каждое задание выполняется двумя студентами. При написа-
нии программы использовать номера сокетов, указанные в номе-
ре варианта. Первый номер — сокет для приема, второй — сокет
для посылки (числа шестнадцатеричные).
Вариант № 1
Пересылка текстового файла с одного компьютера на другой с
его записью на диск компьютера-приемника. Файлы пересыла-
ются пакетами по 512 байт.
Номера сокетов: 6001, 6002.
Вариант № 2
Пересылка кодированных строк. Один компьютер кодирует
строку простым алгоритмом (например, к каждому символу при-
бавлять ключевой байт) и пересылает ее вместе с ключевым бай-
том, с последующим выводом на экран. Ключевые байты разные
для каждой строки (генерируются Random(255)).
Номера сокетов: 6003, 6004.
Вариант № 3
Игра «сетевые крестики-нолики» с размером поля 3x3.
Номера сокетов: 6005, 6006.
Вариант № 4
Одновременное редактирование текста на экране (размер тек-
ста не больше размера экрана). Текст, введенный разными поль-
зователями, отличается цветом. Каждый пользователь может вво-
дить текст в любое место экрана, перемещая курсор.
Номера сокетов: 6007, 6008.
Лабораторная работа Ле 6
241
Вариант № 5
Одна программа посылает другой строку текста. Приемник
заменяет в ней маленькие буквы на большие, и наоборот, и посы-
лает результат обратно. Принятый результат выводится на экран.
Номера сокетов: 6009, 600А.
Вариант № 6
Написать программу перехвата строк, посланных другими
станциями, используя «чужие» номера сокетов для приема. Полу-
ченные строки выводить на экран с выводом полного адреса ис-
точника «перехваченного» сообщения. Номер сокетов задавать
с клавиатуры.
Номера сокетов: вводятся с клавиатуры.
Вариант № 7
Программа протокола сообщений. Один компьютер посылает
сообщения, другой — записывает их в файл, добавляя дату и вре-
мя получения.
Номера сокетов: 600D, 600Е.
Вариант № 8
«Сетевой сумматор». На первом компьютере с клавиатуры
вводятся числа и посылаются на второй компьютер, который
складывает их. При получении нуля сумма пересылается на пер-
вый компьютер, который выводит ее на экран.
Номера сокетов: 600F, 6010.
Вариант № 9
Пересылка текстового файла с одного компьютера на другой
с выводом на экран каждой второй его строки. Файлы пересыла-
ются пакетами по 512 байт.
Номера сокетов: 6011, 6012.
Вариант № 10
Игра «сетевой морской бой» на поле 10x10.
Номера сокетов: 6013, 6014.
Вариант № 11
Программа вывода на экран системного времени своего ком-
пьютера и времени, полученного с другого при нажатии клавиши
242
Лабораторный практикум
Esc. Вторая программа только посылает основное текущее время
до получения сигнала окончания работы.
Номера сокетов: 6015, 6016.
Вариант № 12
Программа вычисления суммы элементов матрицы 5x5, полу-
ченной с другого компьютера. Исходный компьютер считывает
элементы матрицы с клавиатуры, посылает матрицу оппоненту,
после чего сам вычисляет сумму и также передает ее. Компью-
тер-приемник выводит свою и полученную суммы на экран.
Номера сокетов: 6017, 6018.
6. Примеры программ
Текст программы IPX.PAS
Unit IPX;
Interface
Uses DOS;
type
MessageStr = String;
IPX_Regs = Registers;
Byte4 = Array[0..3] of Byte;
NetWorkNumber = Byte4;
NetWorkNode = Array[0..5] of Byte;
ECB = Record
Link_Address : Pointer;
Event_Service_Routine : : Pointer;
In_Use : Byte;
Completion_Code : Byte;
Socket-Number : Word;
IPX_WorkSpace : Byte4;
Driver_WorkSpace : Array[O..11] of Byte;
Immediate_Address : NetWorkNode;
Fragment-Count : Word;
Fragment : Array [0.. 1] of Record
Address : Pointer
Length : Word;
end;
end;
Лабораторная работа Ле 6
243
IPXHeader = Record
Checksum Word;
Length Word;
Т ransport_Control Byte;
Packet_Type Byte;
Dest_NetWork_Number NetWorkNumber
Dest_NetWork_Node NetWorkNode;
Dest_NetWork_Socket Word;
Source_NetWork_Number NetWorkNumber
Source_NetWork-Node NetWorkNode;
Sou rce_NetWo rk_Socket Word;
End;
{ ZeroEcb - запись нулей во все поля ecb.
До : е - ЕСВ.
После : е обнулено. }
procedure ZeroEcb( var е : ЕСВ );
{ ZeroHeader - запись нулей во все поля заголовка.
До : h - IPXHEADER.
После : h обнулено. }
Procedure ZeroHeader( Var H : IPXHeader );
{ GetlnternetAddress - получить свой адрес
До : ничего
После : NetWork_Number - номер сети
NetWork_Node - номер узла
}
Procedure GetInternetAddress(Var NetWork_Number : NetWorkNumber;
Var NetWork_Node : NetWorkNode);
{ IPXInstalled - определить, установлен ли IPX на станции.
До : IPX установлен или не установлен.
После : Если IPX установлен, то инициализирует глобальную переменную
IPXLocation точкой входа IPX и возвращает TRUE.
Иначе инициализирует глобальную переменную IPXLocation
точкой входа IPXSPXNotLoaded и возвращает FALSE. }
Function IPXInstalled : Boolean;
{ IPXSPX - вызвать ipxspx no адресу из IPXLocation.
До : IPXInstalled была вызвана.
IPX установлен и полям NovRegs присвоены значения функции
IPX или SPX и значения параметров.
244
Лабораторный практикум
Проверка не осуществляется.
После : Функция IPX или SPX вызвана.
Переменной NovRegs присвоено значение, возвращенное
после вызова функции. }
Procedure IPXSPX(Var NovRegS:Registers);
{ IPXRelinquishControl - Дает ipx временный контроль над CPU.
До : IPX загружен.
После : Работа IPX завершена. }
procedure IPXRelinquishControl;
{ IPXCancelEvent - Отменяет событие, связанное с ЕСВ.
До: е-корректный ЕСВ.
После: 00 - Успех.
F9 - ЕСВ не может быть отменено.
FF - ЕСВ не использовался}
Function IPXCancelEvent( Var Е : ЕСВ ) : Byte;
{ IPXOpenSocket - Открыть сокет приложения.
До : socket - сокет для использования (BBA-7FFF). Считается
временным.
После : 00 - Успешное завершение.
FE - Таблица сокетов переполнена.
FF - Сокет уже открыт. }
function IPXOpenSocket( socket : word ) : byte;
{ IPXCloseSocket - Закрыть сокет. Безвредно, если сокет уже закрыт.
До : socket - закрываемый сокет.
После : Сокет закрыт. }
procedure IPXCloseSocket( socket : word );
{ IPXListenForPacket - Назначить ЕСВ для приема пакета.
До: е - ЕСВ .
е.socket_number открыт.
е.event_svc-routine = nil.
е.fragment_count обычно 2.
е.fragment[0].address буфера заголовка IPX.
е.fragmented].length = 30.
е.fragment[1].address на область данных <=546 байт.
е.fragmentf1].length = длина области данных.
После: Если сокет открыт, то возвращает TRUE
иначе FALSE. }
function IPXListenForPacket( var e : ЕСВ ) : Boolean;
Лабораторная работа Ле 6
245
{ IPXSendPacket - Послать пакет, используя ЕСВ.
До: е - ЕСВ .
е.socket_number открыт.
е.event_svc-routine = nil.
е.immediate_address адрес адресата.
е.fragmentcount обычно 2.
е.fragment[O],address буфера заголовка IPX.
е.fragment[O].length = 30.
е.fragment[1].address на область данных <=546 байт.
е.fragment[1].length = длина области данных.
После:
е.completion_code of:
00 - Сообщение отправлено.
FC - Событие отменено
FD - Плохой пакет. }
Procedure IPXSendPacket( Var Е: ЕСВ );
{ IPXSend - Послать пакет по адресу network:node:socket, используя
Send_ecB и SendHeader.
Переменные Send_ecB/Send_Header должны быть определены
вне IPXSend, так как обе могут использоваться IPX после
завершения IPXSend, освобождающей любые локальные
переменные.
До : Dest_NetWo^ - номер сети назначения.
После Dest_Node - сетевой узел назначения. Dest_SoCKET - сокет назначения. PackET_Ptr - указатель на посылаемый пакет. PackET_Len - длина посылаемого пакета Send_ecB - есВ для использования при посылке. Send_Header - IPXHeader для использования при посылке. Send_Socket - сокет для использования при посылке. : Если назначение может быть достигнуто, то пакет послан. }
Procedure IPXSend( Var Dest_NetWork : NetWorkNumber; Var Dest_Node : NetWorkNode; dest_socket : word; { hi:lo } packet_ptr : Pointer; packet_len : integer; var send_ecb : ECB; var send_header : IPXHEADER; send_socket : word );
{ IPXReceive - Назначить ECB/header
и буфер для принятия сообщения
246
Лабораторный практикум
До: receive_ecb - ЕСВ, предназначенный для приема.
receive_header - IPXHEADER, предназначенный для приема.
receive_socket - сокет, предназначенный для приема.
После: message - сообщение
message_size - размер сообщения.
}
procedure IPXReceive( var receive_ecb : ЕСВ;
var receive_header : IPXHEADER;
receive_socket : word;
Message : Pointer;
Message_Size : Word );
implementation
type
RequestBuffer = Record
dest_network_number : NetWorkNumber;
dest_network_node : NetworkNode;
dest_network_socket : word;
end;
ReplyBuffer = Record
node_address ; NetworkNode;
end;
Var IPXLocation : Pointer;
{$F+}
procedure ZeroEcb( var e : ECB );
Begin
FillChar (E, SizeOf (E),0);
end;
Procedure ZeroHeader( Var H : IPXHeader );
Begin
FillChar (H, SizeOf (H),0);
End;
function IPXInstalled : Boolean;
var NovRegs : IPX_REGS;
begin
with NovRegs do begin
AX := $7A00;
Intr($2F, NovRegs);
If AL = $FF then Begin
Лабораторная работа Лг 6
247
IPXInstalled := True;
IPXLocation := Ptr(ES.DI);
End
else begin
IPXInstalled := False;
IPXLocation := nil;
end;
end;
end;
procedure IPXSPX(var NovRegs:Registers);
var Ax_, Bx_, Dx_, Di_, Si_, Es_ : word;
begin
With NovRegs do Begin
AX_ := AX;
Bx_ := Bx;
Dx_ := Dx;
Di_ := Di;
Si_ := Si;
Es_ := Es;
end;
asm
mov Ax, Ax_
mov Bx, Bx_
mov Dx, Dx_
mov Di, Di-
mov Si, Si_
mov Es, Es_
push Bp
call dword ptr IPXLocation
pop Bp
mov Ax_, Ax
mov Dx_, Dx
end;
NovRegs.AX := AX_;
NovRegs.Dx := Dx_;
end;
procedure IPXRelinquishControl;
var NovRegs : IPX_REGS;
begin
248
Лабораторный практикум
with NovRegs do begin
Bx := $0a;
IPXSPX(NovRegs);
end
end;
function IPXCancelEvent( var e : ECB ) : byte;
var NovRegs : IPX_REGS;
begin
with NovRegs do begin
Bx := $06;
ES := Seg(E);
SI := Ofs(e);
IPXSPX(NovRegs);
IPXCancelEvent := AL;
end
end;
function IPXOpenSocket( socket : word ) : byte;
var NovRegs : IPXREGS;
begin
with NovRegs do begin
Dx := socket;
Bx := 0;
Al := 0;
IPXSPX(NovRegs);
Ah := 0;
IPXOpenSocket := Ax;
end
end;
procedure IPXCloseSocket( socket : word );
var NovRegs : IPX_REGS;
begin
with NovRegs do begin
Dx := socket;
Bx := $0001;
IPXSPX(NovRegs);
end
end;
Function IPXListenForPacket( Var E : ECB ) : Boolean;
Var NovRegs : IPX_Regs;
begin
Лабораторная работа As 6
249
with NovRegs do begin
BX := $0004;
ES := Seg(E);
SI := Ofs(E);
IPXSPX(NovRegs);
IPXListEnForPacket := AL = 00;
End
End;
procedure IPXSendPacket( var e; ECB );
var NovRegs : IPX_REGS;
begin
with NovRegs do begin
ES := Seg(E);
SI := Ofs(E);
BX := $0003;
IPXSPX(NovRegs);
end
end;
procedure IPXSend( var dest_network NetworkNumber
var dest_node NetworkNode;
dest_socket word; { hi:lo
packet_ptr Pointer;
packet_len integer;
var sendecb ECB;
var send_header IPXHEADER;
Send_Socket : Word );
Function IPXGetLocalTarget( Var Dest_NetWork
Var Dest_Node
dest_socket
var bridge_address
NetWorkNumber;
NetWorkNode;
word;
NetworkNode ) :
byte;
var
NovRegs
Request
Reply
: Registers;
: record
network_number
physical_node
socket
end;
: record
local_target
end;
NetworkNumber;
NetworkNode;
word;
NetworkNode;
250
Лабораторный практикум
begin
with Request do begin
network_number := dest_network;
physical_node := dest_node;
socket := dest_socket;
end;
with NovRegs do begin
Es := Seg(Request);
Si := Ofs(Request);
Di := Ofs(Reply);
Bx := $0002;
IPXSPX(NovRegs);
Ah ;= 0;
IPXGetLocalTarget := Ax;
bridge_address := Reply.local_target;
end
end;
begin
ZeroEcb(send_ecb);
ZeroHeader(send_header);
Send_ECB.Socket-Number := Send_Socket;
If IPXGetLocalTarget( Dest_NetWork,
dest_node,
dest_socket,
send_ecb.immediate_address ) = 0
then begin
with send_ecb do begin
fragment_count := 2;
fragment[0].address := @send_header;
fragment[O].length := sizeof(IPXHEADER);
fragment[1],address := packet_ptr;
fragment[1].length := packet_len;
end;
with send_header do begin
packet_type := 4;
dest_network_number := dest_network;
dest_network_node := dest_node;
dest_network_socket := dest_socket;
end;
IPXSendPacket( send_ecb );
end;
end;
Лабораторная работа № 6
251
procedure IPXReceive( var receive_ecb : ЕСВ;
var receive_header : IPXHEADER;
receive_socket ; word;
message : Pointer;
message_size : word );
begin
ZeroEcb(receive_ecb);
ZeroHeader(receive_header);
With Receive_ECB do Begin
Socket_Number := Receive_Socket;
Fragment_Count := 2;
fragment[O],address := @receive_header;
fragment[O].length := sizeof(IPXHEADER);
fragment[1].address := message;
fragment[1],length := message_size;
end;
if not IPXListenForPacket( receive„ecb ) then
Message..Size ; = 0;
IPXRellnQUIsHControl;
End;
Procedure GetInternetAddress(Var NetWork_Number : NetWorkNumber;
Var NetWork_Node : NetWorkNode);
Var A: Array[1..10] of Byte;
NovRegs : IPX_Regs;
Begin
FillChar (A,Size0f(A),0);
with NovRegs do begin
ES := Seg(A);
DI := Ofs(A);
BX := $0009;
IPXSPX(NovRegs);
End;
Move (A[7],NetWork_Number,4);
Move (A[1],NetWork_Node,6);
End;
End.
252
Лабораторный практикум
Текст программы CHAT.PAS
{ Пример программы, которая устанавливает связь и позволяет
вести обмен сообщениями между компьютерами }
uses Crt, Ipx;
Const
Receive_Socket = $6001;
Send_Socket = $6002;
AU = ‘AU’;
procedure abort(message:string);
begin
writeln(message);
halt(1);
end;
(«сокет приема*)
(*сокет посылки*)
(♦ключевое слово*)
(*вывод сообщения*)
(♦выход из программы*)
function NodeEqualFF(N: NetworkNode); boolean;(«проверка, равен ли
номер узла FFFFFFFFFFFF - было ли сообщение послано всем узлам
сети*)
var
i: byte;
begin
NodeEqualFF:=False;
for i := 0 to 5 do if N[i]$FF then Exit;
NodeEqualFF:=True;
end;
var
connectionnumber:word;
NetWork_Number, MyNetWork_Number:NetWorkNumber;
NetWork_Node, MyNetWork_Node:NetworkNode;
receive_ecb,send_ecb:ECB;
receive_header,send_header:IPXHeader;
receive_message,send_message:MessageSTR;
done : boolean;
X,Y, X1, Y1, i :byte;
flagl, flag2, First : boolean;
Const_Msg : string;
begin
If not IPXInstalled then Abort(‘IPX not loaded’); (‘Проверка,
установлен ли IPX на рабочей станции*)
Лабораторная работа Ле 6
253
FillChar(NetWork_Number, SizeOf (NetWork_Number), 0);(‘записать
нули в номер сети оппонента - работаем в пределах одной локальной
сети*)
FillChar (NetWork_Node, SizeOf (NetWork_Node). $FF);(«записать
FFFFFFFFFFFF - в номер узла оппонента - передаем сообщение
всем узлам локальной сети*)
Get InternetAddress(MyNetWork_Number,MyNetWork_Node); («получить
свой физический адрес - номер сети и номер узла в сети»)
IPXCloseSocket (Send_Socket); («закрыть сокет посылки*)
IPXCloseSocket (Receive_Socket); («закрыть сокет приема*)
if IPXOpenSocket(send_socket) 0 then abort( ‘ Socket error.');
(♦открыть сокет посылки и проверить его успешное открытие»)
if IPXOpenSocket(receive_socket) 0 then abort(‘Socket error.’);
(«открыть сокет приема и проверить его успешное открытие*)
Window(1,1,80,25);
TextAttr := 15;
ClrScr;
writeln(‘Attempting to connect ...’);
Const_Msg := AU; («записать в Const_Msg ключевое слово*)
Move (MyNetWork_Node, Const_Msg[Byte(Const_Msg[0])+1], 6);
(«дописать в Const_Msg после ключевого слова номер своего узла*)
Inc (Byte (Const_Msg[0]), 6); («увеличить длину Const_Msg на 6*)
Move (MyNetWork_Number, Const_Msg[Byte(Const_Msg[0])+1], 4);
(«дописать в Const_Msg номер своей сети*)
Inc (Byte (Const_Msg[0]), 4); («увеличить длину Const_Msg на 4«)
flagl := False; {еще не знаем адрес оппонента }
flag2 := False; {оппонент еще не знает наш адрес }
First := False; { наша программа не опережает оппонента }
repeat
if receive_ecb.inuse = 0
then begin («пакет либо еще не был передан, либо передача паке-
та уже завершилась*)
if Сору(receive_message, 1, length(AU))=AU
then («принятое сообщение начинается со своего ключевого
слова - возможно, оно передано этой программе*)
254
Лабораторный практикум
if receive_messageConst_Msg
then begin(«принятое сообщение не совпадает с Const_Msg
- это обращение оппонента, а не то сообщение, которое
было послано данной программой всем узлам в сети*)
if not NodeEqualFF(receive_header.Dest_Network_Node)
then begin(«номер узла полученного сообщения не
равен FFFFFFFFFFFF - это ответ оппонента на наше
обращение*)
Flag2 := True; («оппонент знает наш адрес*)
if not flagl then First := True;(«оппонент
знает наш адрес, а мы его не знаем, наша про-
грамма при установке связи опережает оппонента*)
end;
if not flagl
then begin (*мы еще не знаем адрес оппонента*)
Move(Receive_Message[Byte
(Receive_Message[0])-3],
NetWork_Number, 4);(«записать номер се-
ти оппонента в NetWork_Number*)
Move(Receive_Message[Byte
(Receive_Message[0])-9],
NetWork_Node, 6);(‘записать номер узла
оппонента в NetWork_Node*)
flagl := True;(«программа знает номер
оппонента*)
end;
end;
if (not Flagl) or (not flag2)
then («возможные причины:
- мы не знаем адрес оппонента - т.е. сообщения
либо не было,
либо оно было не нам,
либо мы получили свое же собственное сообщение, посланное всем узлам;
- оппонент не знает наш адрес - он был первым и не получил еще наш
ответ»)
IPXReceive(receive_ecb, receive_header, receive_socket,
@receive_message, sizeof(receive_message));
(♦устанавливаем ecb на принятие сообщения - ждем
сообщение от оппонента или сообщение, посланное всем узлам*)
end;
Лабораторная работа № 6
255
Send_Message := Const_Msg;
(‘записываем в посылаемое сообщение Const_Msg*)
IPXSend(network_number,
network_node,
receive„socket,
@>send_message,
length(send_message)+1,
send_ecb,
send_header,
send_socket); («посылаем сообщение оппоненту или всем
узлам на сети*)
while (send_ecb.in_UseO) do ; (*ждем окончания посылки*)
until flagl and flag2;(‘повторяем цикл до тех пор, пока либо мы
не узнаем адрес оппонента, либо оппонент не узнает наш адрес»)
if First
then(*Hauja программа была первой - 20 раз посылаем сообщение с
ключевым словом, адресом оппонента и своим адресом для
установления надежной связи*)
for i := 1 to 20
do begin
Send_Message := Const_Msg;
IPXSend(network_number,
network_node,
receive_socket,
@send jnessage,
length(send_message)+1,
send_ecb,
send_header,
send_socket); (‘посылаем сообщение оппоненту*)
while (send_ecb. in llseO) do ; (*ждем окончания посылки*)
end;
{ Соединение установлено }
WriteLn(‘ Connection established ‘);
Receive_Message :=
done := false;
256
Лабораторный практикум
Window(1,1,80,25);
TextAttr := 15;
Write(‘ Message sent Message received');
GotoXY(31, 25);
textAttr := 12;
Write('Press Esc to exit');
window(1,2,40,24);
TextBackground(2);
TextColor(14);
ClrScr;
X:=WhereX;
Y:=WhereY;
window(41,2,80,24);
TextBackground(l);
ClrScr;
X1:=WhereX;
Y1:=WhereY;
repeat { Основной цикл обмена сообщениями }
if (receive_ecb.completioncode = 0) and (receive_ecb.inuse = 0)
then
begin
window(41,2,80,24);
TextBackground(l);
textcolor(lightgreen);
GotoXY(X1,Y1);
if Copy(receive_message, 1, length(AU))AU then
write(receive_message);
if receive_message=chr(13) then writein;
IPXReceive( receive_ecb, receive_header, receive_socket,
@>receive_message, sizeof(receive_message));
X1:=WhereX;
Y1:=WhereY;
window(1,2,40,24);
GotoXY(X, Y);
end;
IPXRelinquishControl;
if KeyPressed then
Лабораторная работа Ле 6
257
begin
send_message := ReadKey;
window(1,2,40,24);
TextBackground(2);
textcolor(yellow);
GotoXY(X,Y);
write(send_message);
if send_message=chr(13) then writein;
IPXSend(network_number,
network_node,
receive_socket,
@send_message,
length(send_message)+1,
send_ecb,
send_header,
send_socket);
X:=WhereX;
Y:=WhereY;
end;
if (send_message = #27) or (receive_message= #27) then
begin
done := true;
IPXCloseSocket(send_socket);
IPXCloseSocket(receive_socket);
end;
until done; { Окончание работы }
end.
Контрольные вопросы
1. Для чего используется протокол IPX?
2. Что такое сокет?
3. Какие сокеты называются «чужими»?
4. Расскажите о структуре пакета IPX.
5. Расскажите о назначении ЕСВ.
6. Расскажите о структуре данных ЕСВ.
Список литературы
1. Олифер В., Олифер Н. Компьютерные сети. Принципы, тех-
нологии, протоколы. — СПб.: Питер, 2006. 960 с.
2. Кульгин М.В. Коммутация и маршрутизация 1Р/1РХ-трафи-
ка. — М.: КомпьютерПресс, 1998. 320 с.
3. Шатт Стэн. Мир компьютерных сетей: Пер. с англ. — Ки-
ев: BHV-Киев, 1996. 288 с.
4. Щербо В.К., Киреичев В.М., Самойленко С.И. Стандарты по
локальным вычислительным сетям. — М.: Радио и связь, 1990.
304 с.
5. Нанс Бэрри. Компьютерные сети: Пер. с англ. — М.:
БИНОМ, 1996. 400 с.
6. Норенков И.П., Трудоношин В.А. Телекоммуникационные
технологии и сети. — М.: Изд-во МГТУ им. Н.Э. Баумана, 1998.
232 с.
7. Новиков Ю.В., Карпенко Д.Г. Аппаратура локальных сетей:
функции, выбор, разработка/Под обшей ред. Ю.В. Новикова. —
М.: ЭКОМ, 1998. 288 с.
8. Фролов А.В., Фролов Г.В. Локальные сети персональных
компьютеров: Использование протоколов IPX, SPX, NETBIOS. —
2-е изд. — М.: Диалог, 1995. 160 с.
9. Палмер М., Синклер Р.Б. Проектирование и внедрение ком-
пьютерных сетей. Учебный курс (2-е изд.). — СПб.: БХВ —
Санкт-Петербург, 2003. 240 с.
10. Кондратенко С.В., Новиков Ю.В. Основы локальных сетей.
Курс лекций: Учеб, пособие для вузов. — М.: ИНТУИТ.РУ, 2005.
360 с.
11. Спартак М., Паппас Ф., Резинг Э. Компьютерные сети.
Кн. 1. Всеобъемлющее руководство по устройству, работе и про-
ектированию. Энциклопедия пользователя. — М.: ДиаСофт, 1998.
432 с.
12. Храмцов П.Б. Администрирование сети и сервисов Internet.
Центр Информационных Технологий, 1997.
13. Douglas Е. Comer, Internetworking with TCP/IP, Vol. I, 2:
Principles, Protocols, and Architecture (Third Edition), Prentice-Hall,
1995.
Приложение
Коды ошибок TCP/IP
Код/Обозначение Описание
6 WSAINVALIDHANDLE Specified event object handle is invalid (Неверный указатель объекта события)
8 WSA_NOT_ENOUG Н_М EMORY Insufficient memory available (Недостаточно па- мяти)
87 WSAINVALIDPARAM ETER One or more parameters are invalid (Недопусти- мые параметры). Приложение, использующее функцию WinSock, напрямую обращается к функции Win32. Функ- ция Win32 указывает на проблему с одним или несколькими параметрами
996 WSAI O_I NCOM PLETE Overlapped I/O event object not in signaled state
997 WSAIOPENDING Overlapped operations will complete later (Перекры- вающиеся операции будут завершены позже). Приложение инициировало перекрывающую- ся (overlapped) операцию, которая не может быть завершена немедленно. О завершении операции будет сигнализировано позднее
10004 WSAEINTR Interrupted function call (Прерван вызов функ- ции). Блокирующая операция прервана вызовом WSACancelBlockingCall()
10013 WSAEACCESS Permission denied (Доступ запрещен). Попытка доступа к сокету способом, за- прещенным привилегиями доступа. Напри- мер, использование широковещательного адреса в функции sendto() без установки со- ответствующего разрешения с помощью setsockopt(SOBROADCAST)
260
Приложение
Продолжение прил.
Код/Обозначение Описание
10014 WSAE FAULT Bad address (Неверный адрес). Система обнаружила неверный указатель на адрес при попытке использовать его в вызове функции. Эта ошибка происходит при пере- даче приложением неверного указателя или если размер буфера слишком мал — напри- мер, если длина аргумента, представляющего собой структуру типа sockaddr, меньше, чем sizeof(struct sockaddr)
10022 WSAE1NVAL Invalid argument (Недопустимый аргумент). Передан недопустимый аргумент (напри- мер, указан неверный уровень в функции setsockopt()). В некоторых случаях это также ссылается на состояние сокета: например, вызов accept() на сокете, который не слушает (listenO)
10024 WSAEMFILE Too many open files (Слишком много открытых файлов). Слишком много открытых сокетов. Каждая реализация имеет свое максимальное количе- ство открытых сокетов либо глобально, либо для каждого процесса/потока
10035 WSAEWOULDBLOCK Resource temporarily unavailable (Ресурс времен- но недоступен). Эта ошибка возвращается операциями с не- блокирующими сокетами, которые не могут быть немедленно завершены. Это не фаталь- ная ошибка. Обычно WSAEWOULDBLOCK возвращается как результат вызова connect() на неблокирующем сокете SOCK STREAM, по- скольку для установления соединения требует- ся некоторое время
10036 WSAEINPROGRESS Operation now in progress (Операция выполня- ется). Выполняется блокирующая операция. Сокеты Wi ndows позвол я ют тол ько одну блоки ру ющу ю операцию на задачу или поток. Если выполня- ется вызов любой другой функции (независи- мо от того, ссылается она на этот или другой сокет), то возникает эта ошибка
Коды ошибок TCP/IP
261
Продолжение прил.
Код/Обозначсние Описание
10037 WSAEALREADY Operation already in progress (Операция уже осу- ществляется). Неблокирующий сокет, на котором предпри- нята операция, уже выполняет операцию. Та- кая ошибка происходит, например, при по- вторном вызове connect() на неблокирующем сокете, который находится в процессе под- ключения или отмены асинхронного запроса WSAAsyncGetXbyYO
10038 WSAENOTSOCK Socket operation on non-socket. Попытка операции на чем-то, что не является сокетом. Либо это операция с указателем, ко- торый не ссылается на допустимый сокет, или, в случае select(), недопустимый член fd set
10039 WSAEDESTADDRREQ Destination address required (Требуется указание удаленного адреса). При операции с сокетом не указан требуемый адрес. Например, эта ошибка возвращается при вызове sendtoQ с адресом INADDR_ANY
10040 WSAEMSGSIZE Message too tong (Слишком длинное сообще- ние). Сообщение, посланное в датаграммный сокет, превышает длину внутреннего буфера или дру- гие сетевые ограничения, или буфер, исполь- зуемый для приема датаграмм, меньше, чем датаграмма
10041 WSAEPROTOTYPE Protocol wrong type for socket (Неверный тип про- токола для сокета). При вызове функции socket() указан прото- кол, который не поддерживает семантику за- прошенного типа сокета. Например, прото- кол UDP нельзя указывать с типом сокета SOCKSTREAM
10042 WSAENOPROTOOPT Bad protocol option (Неверная опция прото- кола). При вызовеgetsockopt() или setsockoptQ указа- на неизвестная, недопустимая или неподдер- живаемая опция
262
Приложение
Продолжение прил.
Кол/Обозначение Описание
10043 WSAEPROTONOSUPPORT Protocol not supported (Протокол не поддержива- ется). Запрашиваемый протокол не сконфигуриро- ван в системе или не существует его реализа- ции
10044 WSAESOCKTNOSUPPORT Socket type not supported (Неподдерживаемый тип сокета)
10045 WSAEOPNOTSUPP Operation not supported (Операция не поддержи- вается). Предпринятая операция не поддерживается для ссылающегося объекта; например, попыт- ка принять соединение на сокете датаграмм
10046 WSAEPFNOSUPPORT Protocol family not supported (Семейство прото- колов не поддерживается). Семейство протоколов не сконфигурировано в системе или для него вообще не существует реализации. Эта ошибка слегка отличается от WSAEAFNOSUPPORT, но в большинстве слу- чаев означает то же самое. Все функции Win- dows Sockets, возвращающие эту ошибку, воз- вращают WSAEAFNOSUPPORT
10047 WSAEAFNOSUPPORT Address family not supported by protocol family (Се- мейство адресов не поддерживается семейст- вом портов). Адрес несовместим с используемым протоко- лом. Все создаваемые сокеты ассоциируются с некоторым семейством адресов (например, AF1NET для протоколов Интернет) и общим типом протокола (например, SOCK_STREAM). Эта ошибка возникает, если в вызове socket() указан неверный протокол или указано неверное семейство адресов
Коды ошибок TCP/IP
263
Продолжение прил.
Код/Обозначение Описание
10048 WSAEADDRINUSE Address already in use (Адрес уже используется). Обычно разрешено только одно использова- ние адреса сокета (протокол/адрсс 1Р/порт). Эта ошибка возникает, когда приложение пы- тается привязаться к сокету функцией bind(), но комбинация адрес IP/портуже использует- ся существующим сокетом, или сокет не был корректно закрыт, или продолжается процесс закрытия сокета. Для серверных приложений, требующих привязки нескольких сокетов к од- ному и тому же номеру порта, следует исполь- зовать sctsockopt(SOREUSEADDR). Клиент- ские приложения обычно не используют bind() — функция connect() автоматически вы- бирает неиспользуемый порт
10049 WSAEADDRNOTAVAIL Cannot assign requested address (Невозможно на- значить требуемый адрес). Запрашиваемый адрес недопустим в его кон- тексте. Обычно это возникает при вызове bind() для адреса, который недопустим для ло- кальной машины, или вызовconnect()/sendto() с адресом или портом, недоспутимыми для удаленной машины (например, номер порта0)
10050 WSAENETDOWN Network is down (Сеть отключена). Операция с сокетом обнаружила мертвую сеть. Это может означать серьезную проблему в се- ти, например, проблему со стеком протокола WinSock DLL, с сетевым интерфейсом, с ло- кальной сетью
10051 WSAENETUNREACH Network is unreachable (Сеть недостижима). Попытка осуществить операцию с сокетом на недостижимой сети. Обычно это означает, что локальные программы не имеют маршрута к удаленному хосту
10052 WSAENETRESET Network dropped connection on reset (Сеть сброси- ла соединение). Хост, к которому вы подключены, перезагру- зился или на нем произошла авария. Эта ошиб- ка может возвращаться функцией setsockopt() при попытке установить SO KEEPALIVE на соединении, установление которого уже завер- шилось неудачей
264
Приложение
Продолжение прил.
Код/Обозначение Описание
10053 WSAECONNABORTED Software caused connection abort (Програм ма вы- звала аварийное завершение соединения). Установленное соединение прервано про- граммным обеспечением на вашей хост-ма- шине, возможно вследствие тайм-аута переда- чи данных или ошибки протокола
10054 WSAECONN RESET Connection reset by peer (Соединение сброшено удаленной системой). Существующее соединение принудительно закрыто удаленной стороной. Обычно это случается в случае неожиданного останова приложения на удаленной стороне, при пере- загрузке удаленной машины или в случае, ко- гда удаленный хост использует «жесткое за- крытие» ( setsockopt(SO_LINGER)) удален- ного сокета
10055 WSAENOBUFS No buffer space available (Закончились буферы). Невозможно осуществить опсраци ю с сокетом, поскольку системе не хватает буферного про- странства или переполнена очередь. Это озна- чает, что WinSock временно не хватает буфе- ров. Это не должно вызывать проблем, если нс продолжается долгое время
10056 WSAEISCONN Socket is already connected (Сокет уже подклю- чен). На уже подключенный сокет сделан запрос со- единения. Некоторые реализации также воз- вращают эту ошибку, если sendto() вызывается на подключенном сокете SOCK DG RAM. Для сокетов SOCK_STREAM параметр to в функ- ции sendto() игнорируется, хотя в других реа- лизациях это допустимо
10057 WSAENOTCONN Socket is not connected (Сокет нс подключен). Была предпринята попытка передать или при- нять данные через неподключенный сокет или попытка посылки датаграммы с помощью sendtoQ без указания адреса. Эту ошибку может также вернуть любой другой тип операции, на- пример установка SO_ KEEPALIVE в setsockopt() на сброшенном соединении
10058 WSAES HUTDOWN Cannot send after socket shutdown (Невозможно послать данные после закрытия сокета)
Коды ошибок TCP/IP
265
Продолжение прил.
Код/Обозначсние Описание
10059 WSAETOOMANYREFS Too many references (Слишком много ссылок). На какой-то объект ядра создано слишком много ссылок, превышающих системные ре- сурсы
10060 WSAET1MEDOUT Connection timed out (Истекло время ожидания соединения). Попытка соединения завершилась неудачей, поскольку удаленная сторона не ответила в те- чение определенного времени
10061 WSAECONNREFUSED Connection refused (Соедиенение отклонено). Невозможно установить соединение, посколь- ку удаленная машина его отвергает. Обычно это происходит при попытке подключиться к службе, которая нс выполняется на удален- ной машине
10062 WSAELOOP Too many levels of symbolic links. A pathname lookup involved more than eight sym- bolic links. (Too many links were encountered in translating a pathname.)
10063 WSAENAMETOOLONG Name too long (Слишком длинное имя)
10064 WSAEHOSTDOWN Host is down. Операция с сокетом неуспешна, поскольку удаленный хост нс отвечает. Операция с соке- том обнаружила мертвый хост. Сетевая актив- ность на локальном хосте не инициируется. Это чаще всего происходит при ошибке WSAETIMEDOUT
10065 WSAEHOSTUNREACH No route to host (Нет маршрута к хосту). Попытка обращения к хосту, к которому невозможно определить маршрут. См. WSAENETUNREACH
10066 WSAENOTEMPTY Directory not empty
266
Приложение
Продолжение прил.
Код/Обозначение Описание
10067 WSAEPROCL1M Too many processes (Слишком много про- цессов). Реализация Windows Sockets может иметь пре- дельное количество приложений, способных работать одновременно. WSAStartupQ может завершиться неудачей, если этот предел дос- тигнут
10068 WSAEUSERS Too many users. Слишком много пользователей
10069 WSAEDQUOT Disk quota exceeded. Превышена дисковая квота
10070 Stale NFS file handle. Попытка получить доступ к файлу, находящемуся в NFS, который стал недоступным. Возможно, файл удален на сер- вере NFS
10091 WSASYSNOTREADY Network subsystem is unavailable (Сетевая под- система недоступна). Эта ошибка возвращается функцией WSAStartupO, если Windows Sockets не может вызвать нужную функцию в данное время, по- скольку низлежашая система, предоставляю- щая сетевые службы, недоступна. Пользовате- ли должны проверить следующее: • файл WINSOCK.DLL находится в текущем маршруте поиска; • WINSOCK.DLL того же производителя, что и стек протоколов. Их нельзя смешивать; • используется одновременно только одна реализация WinSock. Если в системе есть не- сколько реализаций WINSOCK DLL, убеди- тесь, что загружена нужная версия; • убедитесь, что инсталлированы и сконфигу- рированы все необходимые компоненты реализации WinSock
10092 WSAVERNOTSUPPORTED WINSOCK.DLL version out of range (Неверная версия файла WINSOCK.DLL). Текущая реализация WinSock не поддерживает версию спецификации, запрашиваемую при- ложением. Убедитесь, что у вас нет старых вер- сий файла WINSOCK.DLL или обратитесь к поставщику стека за получением обновлен- ной версии
Коды ошибок TCP/IP
267
Окончание прил.
Код/Обозначение Описание
10093 WSANOTINITIAL1SED Successful WSAStartupO not yet performed (Несде- лан вызов функции WSAStartupO). Либо приложение еще не сделало вызов WSAStartupO, либо вызов WSAStartupO завер- шился неудачей. Приложение могло также по- требовать доступ к чужому сокету, владельцем которого не является
10094 WSAEDISCON Graceful shutdown in progress (Процесс аккурат- ного закрытия). Возвращается функциями recv(), WSARecv() для обозначения того, что удаленная сторона инициировала процедуру аккуратного закры- тия соединения
11001 WSAHOST_NOT_ FOUND Host not found (Хост не найден). Указанный хост неизвестен: имя не является официальным hostname или псевдонимом (alias) или его не удается найти в запрашивае- мых базах данных. Эта ошибка может возвра- щаться при запросах протоколов и служб; она указывает на то, что указанное имя нельзя най- ти в соответствующей базе данных
11002 WSATRYAGA1N Non-authoritative host not found. Обычно это временная ошибка, возникающая в процессе разрешения имени и означающая, что локальный сервер не получил ответа от ав- торитетного сервера. Последующая попытка может быть успешной
11003 WSANORECOVERY This is a non-recoverable error (Невосстановимая ошибка). При просмотре базы данных произошла невос- становимая ошибка. Это может случиться при отсутствии файлов базы данных — файлов hosts, services или protocols, или запрос DNS вернул ошибку
11004 WSANO_DATA Запрашиваемое имя правильное и найдено в базе данных, но имеет неожиданный тип дан- ных. Обычно это происходит при трансляции имени в адрес (функциями gethostbyname() или WSAAsyncGetHostByNameO), которое ис- пользует DNS. Возвращается запись MX, а не запись А, что свидетельствует о том, что хост сушествует, но напрямую недостижим
Оглавление
Введение........................................................3
Предисловие ................................................... 4
Глава 1. ПОСТРОЕНИЕ КОМПЬЮТЕРНЫХ СЕТЕЙ.........................6
l.l. Архитектура компьютерных сетей........................6
l.l.l. Классификация компьютерных сетей................6
I.I.2. Топологии компьютерных сетей ...................9
1.1.3. Среды передачи данных..........................12
1.1.4. Методы доступа к среде передачи данных..........17
1.2. Аппаратные компоненты локальных
компьютерных сетей........................................21
1.2.1. Структурированная кабельная система............21
1.2.2. Сетевые адаптеры...............................22
1.2.3. Концентраторы..................................24
1.2.4. Мосты..........................................26
1.2.5. Коммутаторы....................................28
1.3. Стандарты построения локальных сетей.................30
1.3.1. Ethernet.......................................30
1.3.2. Token Ring.....................................33
1.3.3. FDDI...........................................35
1.3.4. Token Bus......................................36
1.3.5. Fast Ethernet .................................38
1.3.6. lOOVG-AnyLAN...................................39
1.3.7. Gigabit Ethernet...............................40
1.3.8. 10 Gigabit Ethernet............................41
1.3.9. Wireless Ethernet..............................42
Оглавление
269
Глава 2. ОРГАНИЗАЦИЯ СЕТЕВОГО ВЗАИМОДЕЙСТВИЯ .... 46
2.1. Физическая передача данных..........................46
2.1.1. Физическое кодирование данных.................46
2.1.2. Способы проверки правильности передачи данных . . . 50
2.1.3. Способы обнаружения и устранения ошибок
при передаче данных.................................52
2.2. Принципы пакетной передачи данных................54
2.2.1. Методы взаимодействия.........................55
2.2.2. Обобщенный формат пакета......................56
2.2.3. Формат кадров Ethernet........................57
2.2.4. Формат кадров Token Ring .....................61
2.3. Сетевые модели......................................64
2.3.1. Понятие сетевой модели........................64
2.3.2. Сетевая модель OSI............................64
2.3.3. Задачи и функции по уровням модели OSI........68
2.4. Стеки протоколов....................................69
2.4.1. Стек протоколов OS1...........................71
2.4.2. Стек протоколов TCP/IP........................73
2.4.3. Стек протоколов IPX/SPX.......................75
2.4.4. Стек протоколов NetB10S/SM В..................77
2.4.5. Другие стеки протоколов.......................78
2.5. Различия и особенности распространенных
протоколов ..............................................79
2.6. Принципы работы протоколов разных уровней .... 81
2.7. Предоставление сетевых услуг........................81
2.8. Адресация в сетях...................................83
2.8.1. Адресное пространство с плоской структурой...83
2.8.2. Адресное пространство с иерархической структурой . . 85
2.8.3. Адреса в виде символьной последовательности..92
270
Оглавление
2.9. Работа протоколов стека TCP/IP..................95
2.9.1. Межсетевой протокол IP ...................95
2.9.2. Протокол межсетевых управляющих
сообщений ICMP .................................100
2.9.3. Протокол пользовательских дейтаграмм UDP.112
2.9.4. Протокол управления передачей TCP........117
2.9.5. Прикладные протоколы ....................126
Глава 3. ОРГАНИЗАЦИЯ МЕЖСЕТЕВОГО
ВЗАИМОДЕЙСТВИЯ..........................................137
3.1. Принципы согласования гетерогенных сетей .... 137
3.2. Маршрутизация пакетов .........................141
3.2.1. Принципы маршрутизации пакетов...........141
3.2.2. Алгоритмы маршрутизации..................144
3.2.3. Протоколы обмена маршрутной информацией .... 146
3.3. Фильтрация пакетов ............................160
3.4. Маршрутизатор..................................161
3.5. Сетевой шлюз ..................................164
3.6. Брандмауэр.....................................165
ЛАБОРАТОРНЫЙ ПРАКТИКУМ..................................168
Лабораторная работа № 1
Аппаратные средства и оборудование ЛВС..............168
Лабораторная работа № 2
Организация обмена данными с использованием
протокола TCP/UDP...................................178
Лабораторная работа № 3
Организации обмена данными с FTP/HTTP-сервером.
Сокеты без блокировки...............................192
Оглавление
271
Лабораторная работа № 4
Сетевое программирование с использованием
RAW-сокетов........................................203
Лабораторная работа № 5
Реализация эхо-сообщения ICMP
на базе RAW Socket.................................218
Лабораторная работа № 6
Программирование сетевых приложений посредством
протокола IPX .....................................225
Список литературы......................................258
Приложение. Коды ошибок TCP/IP.........................259
Белла Дмитриевна Виснадул
Сергей Андреевич Лупин
Сергей Владимирович Сидоров
Павел Юрьевич Чумаченко
Основы компьютерных сетей
Учебное пособие
Редактор А. В. Волковицкая
Корректор А. В. Алешина
Компьютерная верстка Л. В. Софейчук
Оформление серии Р. Остроумова
Сдано в набор 24.04.2006. Подписано в печать 14.06.2006. Формат 60x90/16.
Печать офсетная. Гарнитура «Таймс». Усл. печ. л. 17. Уч.-изд. л. 17,4-
Бумага типографская. Тираж 3000 экз. Заказ № 3789.
ЛР № 071629 от 20.04.98
Издательский Дом «ФОРУМ»
101000, Москва — Центр, Колпачный пер., д. 9а
Тел./факс: (495) 625-32-07, 625-39-27
E-mail: fomm-books@mail.ru
ЛР № 070824 от 21.01.93
Издательский Дом «ИНФРА-М»
127282, Москва, Полярная ул., д. 31 в
Тел.: (495) 380-05-40
Факс: (495) 363-92-12
E-mail: books@infra-m.ru
Http://www.infra-m.ru
Отпечатано в полном соответствии с качеством
предоставленных диапозитивов в ОАО “Тульская типография”.
300600, г. Тула, пр. Ленина,109.
Этот файл был взят с сайта
http://all-ebooks.com
Данный файл представлен исключительно в
ознакомительных целях. После ознакомления с
содержанием данного файла Вам следует его
незамедлительно удалить. Сохраняя данный файл
вы несете ответственность в соответствии с
законодательством.
Любое коммерческое и иное использование кроме
предварительного ознакомления запрещено.
Публикация данного документа не преследует за
собой никакой коммерческой выгоды.
Эта книга способствует профессиональному росту
читателей и является рекламой бумажных изданий.
Все авторские права принадлежат их уважаемым владельцам.
Если Вы являетесь автором данной книги и её распространение
ущемляет Ваши авторские права или если Вы хотите
внести изменения в данный документ или опубликовать
новую книгу свяжитесь с нами по email.