«Брейман А.Д. Сети ЭВМ и телекоммуникации. Глобальные сети Учебное пособие Москва, 2006 УДК 681.326(075) Сети ЭВМ и телекоммуникации. Глобальные сети. Учебное пособие. / Брейман А.Д. — М.:МГУПИ, 2006. — 116с. Настоящее ...»

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

МГУПИ

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

Государственное образовательное учреждение

высшего профессионального образования

«МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ПРИБОРОСТРОЕНИЯ И ИНФОРМАТИКИ»

Кафедра «Персональные компьютеры и сети»

Брейман А.Д.

Сети ЭВМ и телекоммуникации.

Глобальные сети Учебное пособие Москва, 2006 УДК 681.326(075) Сети ЭВМ и телекоммуникации. Глобальные сети. Учебное пособие. / Брейман А.Д. — М.:МГУПИ, 2006. — 116с.

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

Для специальности 2301 (2201) «Вычислительные машины, комплексы, системы и сети» настоящее пособие может быть использовано при изучении курсов «Сети и средства телекоммуникаций» и «Администрирование сетевых систем».

Рекомендовано Ученым Советом МГУПИ в качестве учебного пособия для специальности 2301 (2201) «Вычислительные машины, комплексы, системы и сети».

Автор: Брейман А.Д.

Рецензенты: проф., к.т.н. Рощин А.В.

доц., к.т.н. Журавлев В.А.

Работа рассмотрена и одобрена на заседании кафедры ИТ-4 “Персональные компьютеры и сети” 13 апреля 2006 г.

Зав. кафедрой ИТ-4, профессор, д.т.н. Михайлов Б.М.

© Кафедра ИТ-4 МГУПИ, 2006 г.

Содержание 1 Организация составных сетей

1.1 Корпоративные сети

1.2 Функции сетевого уровня

1.3 Составные сети

1.4 Принципы маршрутизации

1.5 Вопросы для самопроверки

2 Протоколы TCP/IP

2.1 Адресация в Internet

2.1.1 Маска подсети

2.2 Протокол IP

2.2.1 Фрагментация IP-пакетов

2.3 Протокол ARP

2.4 Протокол ICMP

2.5 Базовые утилиты для тестирования сетей TCP/IP

2.6 Протоколы транспортного уровня

2.6.1 Функции транспортного уровня

2.6.2 Протокол UDP

2.6.3 Протокол TCP

2.7 Вопросы для самопроверки

3 Маршрутизация в сетях TCP/IP

3.1 Протокол маршрутизации RIP

3.2 Протокол маршрутизации OSPF

3.3 Протоколы внутренней маршрутизации IGRP и EIGRP

3.4 Протоколы внешней маршрутизации EGP и BGP

3.5 Вопросы для самопроверки

4 Протоколы и службы на основе TCP/IP

4.1 Служба DNS

4.2 Протоколы сетевого управления

4.3 Вопросы для самопроверки

5 Технологии X.25, FRAME RELAY, PDH, SDH

5.1 Технология X.25

5.2 Технология Frame Relay

5.2.1 Структура кадра Frame Relay

5.3 Плезиохронная цифровая иерархия

5.4 Синхронная цифровая иерархия

5.5 Вопросы для самопроверки

6 Технологии ISDN И ATM

6.1 Технология ISDN

6.1.1 Интерфейсы ISDN

6.2 Технология ATM

6.2.1 Основные принципы технологии ATM

6.2.2 Стек протоколов ATM

6.2.3 Уровень адаптации AAL

6.3 Вопросы для самопроверки

7 Сетевые операционные системы

8 Технологии распределенных вычислений

8.1 Удаленный вызов процедур

8.2 Microsoft DCOM

8.3 Технология CORBA

8.4 Вопросы для самопроверки

9 Протоколы прикладного уровня

9.1 Структура и информационные услуги территориальных сетей.......... 9.2 Протоколы файлового обмена

9.2.1 Протокол передачи файлов FTP

9.2.2 Простейший протокол передачи файлов TFTP

9.3 Протоколы электронной почты

9.3.1 Простой протокол передачи почты SMTP

9.3.2 Протокол почтовой службы POP

9.3.3 Протокол доступа к Интернет-сообщениям IMAP

9.4 Протоколы дистанционного управления

9.4.1 Протокол виртуального терминала Telnet

9.4.2 Протокол безопасной командной оболочки SSH

9.5 Виды конференц-связи

9.5.1 Виды асинхронной конференц-связи

9.5.2 Виды синхронной конференц-связи

9.6 Вопросы для самопроверки

10 Web-технологии

10.1 Структура Web-ориентированного программного обеспечения..... 10.2 Протокол передачи гипертекста HTTP

10.2.1 HTTP-запрос

10.2.2 HTTP-ответ

10.2.3 Средства идентификации пользователей в протоколе HTTP........ 10.3 Языки и средства создания Web-приложений

10.4 Вопросы для самопроверки

Список литературы

1 Организация составных сетей 1.1 Корпоративные сети Корпоративной сетью (англ. corporate network) называется сеть смешанной топологии, объединяющая локальные сети (и, возможно, отдельные компьютеры) подразделений и филиалов корпорации (предприятия, организации, учреждения и т.д.). Корпоративная сеть является собственностью корпорации.

1.2 Функции сетевого уровня Сетевой (межсетевой) уровень отвечает за передачу пакетов между узлами в составных сетях, включая выбор маршрута передачи и согласование протоколов канального уровня.

Составные сети могут строиться на стандартах канального уровня, с использованием повторителей, мостов и коммутаторов. Такой подход часто бывает оправдан, однако имеет некоторые существенные недостатки и ограничения:

• в сети должны отсутствовать замкнутые маршруты (или, что то же самое, разные пути между двумя узлами); использование протокола STP позволяет коммутаторам работать в таких сетях, но только отключив часть линий связи;

• такие сети подвержены широковещательным штормам;

• сложно управлять трафиком на основе передаваемых данных;

• плоская система адресации (только MAC-адреса, привязанные к сетевым адаптерам);

канального уровня.

1.3 Составные сети Сеть, которая рассматривается как совокупность нескольких сетей, называется составной сетью или интерсетью (англ. internetwork, internet), а ее части — подсетями (англ. subnet) или просто сетями.

маршрутизаторами (англ. router). Разные подсети могут быть локальными и глобальными, строиться на разных технологиях — Ethernet, Token Ring, X25, Frame Relay, ATM и т.д. Для того чтобы не зависеть от разных способов адресации, используемых в разных технологиях (локальных адресов), вводятся сетевые адреса, уникально идентифицирующие все узлы составной сети. Как правило, сетевой адрес состоит из двух частей: номера подсети и номера узла в подсети. Существуют способы адресации, использующие в качестве номера узла локальные (MAC) адреса (например, IPX/SPX). Такой вариант имеет ограниченную сферу применения, поскольку зависит от локальных технологий.

Другие технологии назначают узлам номера независимо от их локальных адресов (например, TCP/IP).

1.4 Принципы маршрутизации Маршрутизатор, как и, например, мост, имеет несколько портов и должен для каждого поступающего пакета решить — отфильтровать его или передать на какой-то другой порт.

Как и мосты, маршрутизаторы решают эту задачу с помощью специальной таблицы — таблицы маршрутизации. По этой таблице маршрутизатор определяет, на какой порт нужно передавать пакет, чтобы он достиг нужной подсети (не обязательно сразу). Если сеть содержит петли, в таблицах маршрутизации может быть несколько записей на одну подсеть, описывающих разные возможные маршруты.

Каждый порт маршрутизатора рассматривается, как отдельный узел сети.

Другие узлы должны знать его адрес и направлять пакеты для передачи в другие подсети на этот адрес, а не просто выдавать их в канал (как при прозрачных мостах).

Рассмотрим принципы маршрутизации на примере сети, изображенной на рисунке 1.1. Здесь S1..S10 — подсети, M1..M13 — маршрутизаторы. Порты маршрутизаторов будем обозначать сочетанием имени маршрутизатора и сети, например, M5/S2 — порт маршрутизатора M5, подключенный к сети S2.

Таблица маршрутизации для маршрутизатора M7 приведена в таблице 1. Таблица 1.1 — Таблица маршрутизации для маршрутизатора M Алгоритм маршрутизации — правило назначения выходной линии связи (порта) на основе данных, содержащихся в заголовке пакета, данных, описывающих состояние маршрутизатора и сети в целом.

Эффективность алгоритмов характеризуется:

• временем доставки пакетов, • нагрузкой на сеть, • затратами ресурсов маршрутизаторов (времени и памяти).

маршрутизатор имел информацию, как о топологии сети, так и состоянии узлов и связей между ними.

В зависимости от того, какой компонент сети — узел или маршрутизатор — принимает решение о пути пакета, различают маршрутизацию от источника и одношаговую. При маршрутизации от источника (англ. source routing) узел записывает путь (последовательность адресов промежуточных маршрутизаторов) в каждый отправляемый пакет, и маршрутизаторам остается только выполнять указания узла, если это возможно. При одношаговой маршрутизации решение о том, куда дальше передавать пакет принимается на каждом шаге очередным маршрутизатором.

фиксированные и адаптивные. Решение, принимаемое при простой маршрутизации не зависит ни от топологии, ни от состояния сети. Основные варианты простой маршрутизации:

• случайная — передача пакета на любой порт, кроме исходного;

• по кратчайшей очереди — передача пакета на порт с самой короткой • лавинная — передача пакета на все порты, кроме исходного;

• по предыдущему решению — передача пакета на тот порт, куда отправлялись предыдущие пакеты от этого источника (если пакет — первый, то случайно или по кратчайшей очереди).

Фиксированная маршрутизация основана на статически заданных неизменяемых таблицах маршрутизации (например, они могут создаваться при загрузке операционной системы) и может быть однонаправленной (может быть только один маршрут для сети назначения), либо многонаправленной (допускается наличие нескольких маршрутов для одной сети).

Адаптивная маршрутизация опирается на знание топологии составной сети и может учитывать изменения состояния сети. Различают следующие виды адаптивной маршрутизации:

• локальная — только на основе информации о состоянии своих выходных каналов и очередях пакетов;

• распределенная — на основе информации, получаемой от других узлов (регулярный обмен узлов таблицами маршрутизации);

o на основе векторов расстояний (или дистанционно-векторная, англ. Distance Vector Algorithms) — рассылается вектор из o на основе состояния связей (англ. Link State Algorithms) — каждый узел строит полный граф сети (передаются ребра графа маршрутизатор-маршрутизатор и маршрутизатор-сеть);

• централизованная — с выделенным центром маршрутизации, рассылающем ее всем узлам;

• гибридная — централизованная+локальная (если путь в таблице один, то пакет отправляется по нему, иначе — на порт с самой короткой 1.5 Вопросы для самопроверки • Должны ли подсети, соединяемые в составную сеть, иметь одинаковые канальные уровни (например, Ethernet)?

• Можно ли построить составную сеть диаметром 5 км только на коммутаторах, если все ее подсети построены на Ethernet?

• Какая строка в таблице маршрутизации маршрутизатора M описывает путь к сети S12 (по рисунку 1.1)?

• По каким характеристикам маршрутизация от источника превосходит одношаговую маршрутизацию?

• При каких условиях предпочтительно применять фиксированную маршрутизацию?

• При каких условиях предпочтительно применять лавинную маршрутизацию?

• Какие преимущества и недостатки имеются у централизованной маршрутизации?

2 Протоколы TCP/IP Все протоколы стека TCP/IP, сетевые службы, принципы их реализации и другие сопутствующие вопросы описываются в документах RFC (Request For Comment — предложение для обсуждения). Исходно это были действительно документы, предназначенные для обсуждения, но впоследствии сформировавшиеся стандарты также оформлялись в виде RFC.

Рассмотрение стека протоколов TCP/IP будем сопровождать указаниями номеров RFC, описывающих тот или иной протокол. Документы RFC можно получить, например, с Web-узла РосНИИРОС: http://www.ripn.net/nic/ 2.1 Адресация в Internet Узлы сетей, входящих в Internet, используют, по крайней мере, три системы адресации: локальную (адреса канального уровня, т.е., например, MAC-адреса в локальной Ethernet-сети), сетевую (IP-адреса) и символьную (доменные имена, DNS-имена).

Локальные адреса используются для доставки пакетов в пределах подсети, сетевые адреса — для маршрутизации пакетов между подсетями, а символьные имена — для более простого и запоминающегося именования узлов.

Сетевой уровень стека TCP/IP передает пакеты между сетями, опираясь на IP-адреса (RFC 990 и RFC 997). IP-адрес (четвертой версии, являющейся основной в настоящее время) состоит из 32 бит (4 байт). Как правило, IP-адрес записывают как четыре десятичных числа (значения отдельных байтов), разделенные точками, например: 123.45.67.89. Адрес состоит из двух частей:

номера подсети и номера узла, причем номер узла не зависит от его MACадреса (или другого локального адреса). Распределение номеров подсетей для Internet осуществляется централизованно (долгое время только InterNIC, потом ICANN, в скором времени — группа независимых организаций), а для внутренних подсетей, не связанных напрямую с Internet, может назначаться администратором сети.

Все IP-адреса разделены на 5 классов (от A до E), задающих разные соотношения между количеством подсетей и количеством узлов в них. На рисунке 2.1 показана структура адресов разных классов (буквой N обозначены биты адреса, составляющие номер сети, буквой H — биты адреса, составляющие номер узла в сети, буквой M — биты адреса, составляющие номер группы рассылки).

A 0 N NNNNNNHHHHHHHHHHHHHHHHHHHHHHHH

B 1 0 NNNNNNNNNNNNNNHHHHHHHHHHHHHHHH

C 1 1 0NNNNNNNNNNNNNNNNNNNNNHHHHHHHH

D 1 1 1 0 MMMMMMMMMMMMMMMMMMMMMMMMMMMM

Некоторые IP-адреса интерпретируются специальным образом:

• адрес, все биты которого равны нулю, обозначает адрес того узла, • адрес, в поле номера сети которого стоят только нули, считается относящимся к той же сети, что и узел, выдавший этот пакет;

• адрес, все биты которого равны единице, означает, что данный пакет должны получить все узлы подсети, к которой относится узел, выдавший этот пакет (ограниченное широковещательное сообщение, • адрес, в котором все биты поля номера узла равны единице, а поле номера сети задает определенную сеть (не все нули и не все единицы), то такой пакет должен рассылаться всем узлам указанной подсети (широковещательное сообщение, англ. broadcast).

Таким образом, ни номер подсети, ни номер узла не может состоять из одних нулей или одних единиц. Это ограничивает количество узлов в подсети соотношением: Nузлов = 2n–2, где n — количество бит в поле номера узла, а количество подсетей — соотношением: Nподсетей = 2m–2, где m — количество бит в поле номера подсети.

Например, каждая из 16382 (214–2) подсетей класса B (14 бит под номер подсети, 16 бит под номер узла) максимально может включать 65534 (216–2) узла с номерами от x.x.0.1 до x.x.255.254.

Кроме того, выделяется группа адресов, первый байт которых равен 127.

Эти адреса используются для передачи данных между процессами на одном компьютере или для тестирования. Данные, отправленные по такому адресу, рассматриваются, как только что принятые из сети, в результате чего образуется как бы “петля” (англ. loopback). Обычно используется адрес 127.0.0.1, но для этих целей можно использовать любой адрес вида 127.x.x.x.

Три блока IP-адресов зарезервированы для внутреннего использования в корпоративных сетях, отделенных от Интернета маршрутизаторами с функцией трансляции сетевых адресов NAT (англ. Network Address Translation), описанной в RFC 1631. Это одна подсеть класса А (адреса с 10.0.0.0 по 10.255.255.255), 16 подсетей класса B (адреса с 172.16.0.0 по 172.31.255.255) и 256 подсетей класса C (адреса с 192.168.0.0 по 192.168.255.255). Такие адреса называются «частными» (англ. private). Маршрутизаторы Интернета не должны маршрутизировать пакеты с такими адресами получателя.

2.1.1 Маска подсети При классовой адресации определить, сколько бит адреса отведено под номер подсети, а сколько — под номер узла в подсети, можно по самому адресу (его старшим битам). Чтобы выделить эти номера из IP-адреса, можно, например, использовать 32-битовую маску, в которой старшие биты, соответствующие номеру подсети, выставлены в 1, а остальные — в 0. Тогда номер подсети выделяется операцией побитового И над адресом и маской, а номер узла — той же операцией над адресом и инвертированной маской. Такая битовая маска называется в TCP/IP маской подсети (англ. subnet mask); их принято записывать так же, как IP-адреса: четыре десятичных значения байтов, разделенных точками. Каждому классу соответствует фиксированная маска:

классу А — 255.0.0.0, классу B — 255.255.0.0, классу C — 255.255.255.0.

Сначала маски использовались только внутри программных модулей, реализующих сетевые протоколы, но со временем стали при IP-адресе указывать его маску подсети практически всегда.

Если организация получила в пользование некоторую подсеть, то она может распоряжаться всеми возможными значениями поля номера узла по своему желанию. Можно, например, продолжить идею разделения на подсети внутрь этого поля: разбить его на две части — номер подподсети и номер узла в подподсети. Такое разбиение может оказаться удобным, если у организации несколько локальных сетей и было бы желательно, чтобы можно было по IPадресу видеть, к какой локальной сети (т.е. подподсети) относится данный компьютер. При обычной классовой адресации нет возможности указать, где проходит граница между номером подподсети и номером узла в ней.

Использование масок подсети позволяет реализовать такое разбиение очень просто: если при адресе всегда передается маска подсети, то ничто не мешает считать номером узла только биты адреса, соответствующие нулевым битам маски, а остальные биты, которые в соответствии с классом адреса тоже относятся к номеру узла, считать номером подподсети. Например, адресу 194.153.99.210 с маской 255.255.255.224 соответствует подсеть класса C 195.153.99, подподсеть 6, узел 18. Поскольку маска подсети всегда имеет одинаковую структуру: старшие биты — 1, младшие — 0, вместо четырех байт маски достаточно хранить и передавать всего один байт (реально хватило бы четырех бит) — количество старших единичных бит: например, маске 255.255.255.224 соответствует суффикс подсети /19.

При нумерации подподсетей и узлов них необходимо соблюдать те же правила, что и для обычных подсетей: все нули и все единицы в номере подподсети и в номере узла используются только для служебных целей. Таким образом, при разбиении на подподсети часть адресного пространства подсети расходуется впустую.

Использование классовой адресации привело к очень неравномерному распределению адресного пространства: например, половина все возможных адресов — адреса класса A — зарезервирована за 127 подсетями, которые заведомо не используют все эти адреса. В то же время сети класса C стали дефицитом уже в середине 1990-х годов. Решением этой проблемы стала бесклассовая адресация. При бесклассовой адресации старшие биты адреса перестают нести особый смысл, а границу между номером подсети и номером узла определяет маска (или суффикс) подсети. Старые классовые адреса при этом сохраняются (с соответствующими масками).

2.2 Протокол IP Протокол IP (англ. Internet Protocol, протокол межсетевого взаимодействия) описан в RFC 791. Основная функция протокола IP — передача пакетов между узлами, принадлежащими к разным подсетям, через промежуточные подсети. Каждый пакет (дейтаграмма, англ. datagram) обрабатывается независимо от других. Доставка дейтаграмм не гарантируется.

Возможны потери дейтаграмм, доставка с ошибками, дублирование и нарушение порядка следования. Вторая функция протокола IP — выполнение фрагментации пакетов при передаче их между сетями с разным максимально допустимым размером поля данных кадра (англ. Maximum Transfer Unit, MTU).

Существенное свойство протокола IP состоит в нетрадиционном порядке передачи битов: байт передается, начиная со старшего бита. Кроме того, нумерация битов в байте также начинается со старшего: самый старший бит имеет номер 0, самый младший — номер 7.

Дейтаграмма (IP-пакет) состоит из заголовка и поля данных. Формат заголовка приведен на рисунке 2.2.

Поле Номер версии (англ. Version) [4 бита] — указывает используемый формат заголовка. В настоящее время основная используемая версия имеет номер 4.

Поле Длина заголовка (англ. Internet Header Length, IHL) [4 бита] — длина заголовка в четырехбайтовых словах, минимальное допустимое значение — 5 (соответствует длине заголовка в 20 байт). Максимальная длина заголовка — 60 байт.

Поле Тип сервиса (англ. Type of Service) [8 бит] — указывает на желаемые параметры качества обслуживания. Формат байта Типа сервиса приведен на рисунке 2.3.

Рисунок 2.3 — Структура поля «Приоритет» заголовка IP-пакета Поле Приоритета (англ. Precedence) для обычных пакетов равно 0, остальные значения (от 1 до 7) используются для служебных целей, чем больше значение, тем выше приоритет.

Поля D (англ. Delay, задержка), T (англ. Throughput, пропускная способность) и R (англ. Reliability, надежность) используются для указания наиболее важного для передающего узла параметра качества. Выбор происходит между малой задержкой, большой пропускной способностью и высокой надежностью. Соответствующий бит (биты) устанавливается в 1, остальные — в 0. Как правило, улучшение одного из параметров связано с ухудшением остальных.

Поле Общая длина (англ. Total Length) [16 бит] — длина дейтаграммы (заголовка и данных) в байтах. Хотя размер поля позволяет создавать дейтаграммы длиной до 65535 байт, стандарт требует, чтобы любой узел мог принимать, как минимум, 576-байтовые дейтаграммы (как целиком, так и частями), а отправлять дейтаграммы большей длины только, будучи уверенным, что получатель может их принять. Значение 576 выбрано, чтобы можно было передавать в одном IP-пакете 512 байт данных («блок данных разумного размера», как написано в стандарте; отметим, что 512 байт — это типичный размер сектора жесткого или гибкого диска), оставляя 64 байта под заголовки протоколов: IP-заголовок занимает от 20 до 60 байт.

Поле Идентификация (англ. Identification) [16 бит] — значение, одинаковое для всех дейтаграмм, содержащих фрагменты одного пакета («большого пакета»).

фрагментированием:

0 бит — зарезервирован, должен быть равен 0;

1 бит (DF, англ. Don’t Fragment) — «0» = можно фрагментировать, 2 бит (MF, англ. More Fragments) — «0» = последний фрагмент, Поле Смещение фрагмента (англ. Fragment Offset) [13 бит] — указывает на место в «большом пакете», с которого начинаются данные текущей дейтаграммы. Измеряется в 64-битовых (8-байтовых) словах. Например, Смещение фрагмента, равное двум, означает, что данные текущей дейтаграммы должны находиться в «большом пакете», начиная с 16-го байта. Первый фрагмент имеет нулевое смещение.

Поле Время жизни (англ. Time to Live, TTL) [8 бит] — максимальное время, которое дейтаграмма может находиться в сети. Каждый маршрутизатор должен уменьшать это значение на единицу, и отбрасывать дейтаграммы со значением TTL = 0, передавая при этом отправителю соответствующее ICMPсообщение. Наличие этого поля обеспечивает уничтожение «зациклившихся»

или «заблудившихся» дейтаграмм. Поле TTL также позволяет ограничить дальность распространения дейтаграммы (это удобно, например, при одновременной передаче множеству абонентов) и является основой для работы утилиты traceroute.

Протокол (англ. Protocol) [8 бит] — указывает, данные какого протокола верхнего уровня передаются в дейтаграмме. Возможные значения этого поля стандартизованы (RFC «Assigned Numbers»), приведем некоторые из них: 1 — ICMP, 4 — IP, 6 — TCP, 17 — UDP, 89 — OSPF.

Поле Контрольная сумма заголовка (англ. Header Checksum) [16 бит] — контрольная сумма всех полей заголовка, вычисляемая как дополнение суммы всех 16-битовых слов заголовка (с нулевыми битами в поле контрольной суммы). Поскольку некоторые поля заголовка (например, время жизни) изменяются при передаче дейтаграммы через сеть, контрольная сумма пересчитывается каждым маршрутизатором. Если получена дейтаграмма с неверной контрольной суммой, такая дейтаграмма отбрасывается.

Поле Адрес отправителя (англ. Source IP Address) [32 бита] — IP-адрес отправителя дейтаграммы.

Поле Адрес получателя (англ. Destination IP Address) [32 бита] — IP-адрес получателя дейтаграммы.

Поле Опции (англ. Options) [переменная длина] — необязательное поле, может содержать данные о безопасности, маршрут дейтаграммы (при маршрутизации от источника) и т.д. В одной дейтаграмме может быть несколько опций, каждая из которых состоит из кода опции (1 байт), длины опции (1 байт) и байтов данных опции. Если для опции не нужны дополнительные данные, она состоит из одного байта — кода опции.

Опции в настоящее время практически не используются.

Поле Дополнение (англ. Padding) — нулевые байты в таком количестве, чтобы размер заголовка был кратен 4 байтам.

2.2.1 Фрагментация IP-пакетов На пути пакета от отправителя к получателю могут встречаться локальные и глобальные сети разных типов с разными допустимыми размерами полей данных кадров канального уровня (MTU). Так, например, сети Ethernet могут передавать кадры размером до 1500 байт, сети FDDI — до 4500 байт, в других сетях действуют свои ограничения. Протокол IP умеет передавать дейтаграммы, длина которых больше MTU промежуточной сети, за счет фрагментирования — разбиения «большого пакета» на некоторое количество частей (фрагментов), размер каждой из которых удовлетворяет промежуточную сеть. После того, как все фрагменты будут переданы через промежуточную сеть, они будут собраны на узле-получателе модулем протокола IP обратно в «большой пакет». Отметим, что сборку пакета из фрагментов осуществляет только получатель, а не какой-либо из промежуточных маршрутизаторов.

Маршрутизаторы могут только фрагментировать пакеты, но не собирать их.

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

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

При делении данных пакета, размер всех фрагментов, кроме последнего, должен быть кратен 8 байтам. Это позволяет отвести меньше места в заголовке под поле «Смещение фрагмента».

Второй бит поля «Флаги» (MF), если равен единице, указывает на то, что данный фрагмент — не последний в пакете.

Если пакет отправляется без фрагментации, флаг MF устанавливается в 0, а поле Смещение фрагмента — заполняется нулевыми битами.

Если первый бит поля «Флаги» (DF) равен единице, то фрагментация пакета запрещена. Если этот пакет должен быть передан через сеть с недостаточным MTU, то маршрутизатор вынужден будет его отбросить (и сообщить об этом отправителю посредством протокола ICMP). Этот флаг используется в случаях, когда отправителю известно, что у получателя нет достаточно ресурсов по восстановлению пакетов из фрагментов.

2.3 Протокол ARP Протокол ARP (Address Resolution Protocol, Протокол Разрешения Адресов) описан в RFC 826.

При передаче пакетов внутри локальных сетей протоколы канального уровня пользуются локальными адресами узлов, отправитель же может знать только IP-адрес получателя. Для того чтобы определить, какой локальный адрес (например, MAC-адрес в сети Ethernet) соответствует данному IP-адресу, применяется протокол ARP. Этот протокол разрабатывался специально для Ethernet-сетей, но может работать в любых сетях, поддерживающих широковещательную передачу.

Все узлы, поддерживающие протокол ARP, ведут ARP-таблицу, состоящую из записей.

Когда узлу нужно определить локальный адрес другого узла, его ARPмодуль сначала ищет его в ARP-таблице, и, если нужный адрес не найден, то передает широковещательное сообщение: «Знает ли кто-нибудь локальный адрес для IP 123.45.67.89? Я 123.45.67.90, мой MAC-адрес 10:20:30:40:50:60.».

Узел, которого разыскивают, отвечает (не широковещательно, а прямой передачей): «Да, 123.45.67.89 — это я. Мой MAC-адрес 10:20:30:40:50:61». При этом он сохраняет пару искавшего его узла в своей ARP-таблице. Наконец, первый узел, получив ответ, заносит его в свою ARPтаблицу.

Как правило, записи в ARP-таблице имеют ограниченное время жизни (стандарт описывает возможные схемы ограничения времени жизни и таймаутов, но не требует их применения).

Формат сообщения ARP позволяет использовать этот протокол в сетях с разным размером адресов (до 256 бит).

Сообщения ARP не содержат IP-заголовка и непосредственно размещаются в поле данных кадра канального уровня.

2.4 Протокол ICMP Протокол ICMP (Internet Control Message Protocol, Протокол Управляющих Сообщений Интернет) описан в RFC 792.

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

Хотя сообщения ICMP вкладываются в поле данных IP-дейтаграммы, то есть ICMP как бы является протоколом более высокого уровня, чем IP, модуль обработки ICMP-сообщений входит в модуль, реализующий протокол IP.

Сообщения ICMP всегда начинаются с заголовка, состоящего из трех полей (см. рисунок 2.4), за которым следуют данные об ошибке.

Данные (переменная длина; могут отсутствовать) Поле Тип (англ. Type) [8 бит] — тип сообщения (см. таблицу 13.1).

Поле Код (англ. Code) [8 бит] — причина проблем с доставкой дейтаграммы (см. таблицы 2.1, 2.2, 2.3 и 2.4). Для остальных типов в поле Код записывается нулевое значение.

Поле Контрольная сумма (англ. Checksum) [16 бит] — контрольная сумма ICMP-сообщения (начиная с поля Тип), вычисляемая, как в протоколе IP.

Таблица 2.1 — Типы сообщений ICMP Тип Описание 0 ответ на эхо (Echo reply) 3 получатель недостижим (Destination unreachable) 4 подавление источника (Source quench) 5 изменение маршрута (Redirect) 11 время жизни дейтаграммы истекло (Time exceeded) 12 ошибка в параметре (Parameter problem) 13 запрос временной метки (Timestamp) 14 временная метка (Timestamp reply) 15 запрос информации (Information request) 16 ответ на запрос информации (Information reply) 17 запрос маски адреса (Mask request) 18 маска адреса (Mask reply) Таблица 2.2 — Коды сообщений ICMP для типа 3 (получатель недостижим) Код Описание 1 сеть недостижима 3 протокол недостижим 4 требуется фрагментация, но установлен флаг DF 5 сбой в маршрутизации от источника 6 неизвестна сеть назначения 7 неизвестно устройство назначения 8 отправитель изолирован 9 закрыт доступ к сети назначения 10 закрыт доступ к устройству назначения 11 сеть недостижима из-за требований к классу обслуживания 12 устройство недостижимо из-за требований к классу обслуживания Таблица 2.3 — Коды сообщений ICMP для типа 5 (изменение маршрута):

Код Описание 0 переадресовать дейтаграммы для сети 1 переадресовать дейтаграммы для узла 2 переадресовать дейтаграммы для типа обслуживания и сети 3 переадресовать дейтаграммы для типа обслуживания и узла Таблица 2.4 — Коды сообщений ICMP для типа 11 (время жизни дейтаграммы истекло):

Код Описание 0 время жизни истекло при передаче 1 время жизни истекло при ожидании фрагмента для сборки 2.5 Базовые утилиты для тестирования сетей TCP/IP Утилита Ping позволяет проверить существование указанного узла и измерить время передачи до него одного пакета (можно задавать разные размеры пакета для исследования промежуточных сетей). Эта утилита выполняет передачу ICMP-сообщения типа 8 (Echo request), на которое получатель должен ответить ICMP-сообщением типа 0 (Echo reply).

Утилита Traceroute показывает последовательность узлов, через которые проходит пакет на пути к получателю. Реализовано это следующим образом:

последовательно отправляются пакеты с возрастающим значением в поле TTL:

1,2,3 и т.д. Тот маршрутизатор, который уменьшит TTL до нуля, обязан будет отправить ICMP-сообщение типа 11 (Time exceeded). В результате будут получены такие ICMP-сообщения по очереди от всех маршрутизаторов на пути пакета к получателю. В различных ОС эта утилита реализована по-разному: в ОС семейства Windows отправляются ICMP-сообщения (подобно утилите ping), а в Linux/FreeBSD — UDP-сообщения.

2.6 Протоколы транспортного уровня 2.6.1 Функции транспортного уровня Отправителем и получателем данных, передаваемых через сеть, с точки зрения транспортного уровня, является приложение (процесс). Как любая программа, процессы создаются и уничтожаются, на каждом узле может выполняться несколько процессов, а каждый процесс может иметь несколько точек подключения к сети. Такие логические точки (программно организуемые, как правило, в виде очередей сообщений) называются портами (англ. port).

Номер порта однозначно идентифицирует процесс. Когда узел получает дейтаграмму транспортного уровня, он направляет ее прикладному процессу, используя номер порта, заданный при установлении связи.

Порты нумеруются положительными целыми 16-битовыми числами.

Разные протоколы транспортного уровня нумерую свои порты независимо, то есть, например, порт 20 протокола TCP и порт 20 протокола UDP совершенно не связаны друг с другом.

Некоторые номера портов заданы стандартами. Эти номера выделяются организацией IANA (англ. Internet Assigned Numbers Authority). В настоящее время под стандартные порты отведен диапазон от 0 до 1023 (ранее — до 255).Остальные порты могут свободно использоваться прикладными процессами. Порты в диапазоне от 1024 до 5000 называются временными (англ.

ephemeral). Назначение этих портов не стандартизовано, но IANA поддерживает информацию об их использовании.

Пара «порт — IP-адрес» называется (в терминологии TCP/IP) гнездом или сокетом (англ. socket) и однозначно указывает программный процесс, выполняющийся на одном из узлов в сети.

2.6.2 Протокол UDP Протокол UDP (англ. User Datagram Protocol, Протокол пользовательских дейтаграмм) описан в RFC 768. Он предоставляет прикладным процессам простейшие услуги транспортного уровня. Две основные функции UDP — распределение дейтаграмм между процессами (на основании номеров портов) и контроль передачи пользовательских данных (не только заголовка, как в протоколе IP). Как и IP, UDP не гарантирует доставку и не поддерживает установку соединений.

дейтаграммой (англ. User datagram) и состоит из заголовка и пользовательских данных. Структура заголовка приведена на рисунке 2.5. Сразу за заголовком идут пользовательские данные.

Рисунок 2.5 — Формат заголовка дейтаграммы UDP Если значение поля «Порт отправителя» не важно для получателя, в него можно записать нулевое значение.

В поле «Длина сообщения» записывается размер пользовательских данных в байтах.

Нулевое значение в поле «Контрольная сумма» означает, что контрольная сумма не вычислялась. Для расчета контрольной суммы к началу дейтаграммы приписывается псевдозаголовок, состоящий из пяти полей (см. рисунок 2.6).

Рисунок 2.6 — Формат псевдозаголовка UDP для расчета контрольной суммы Если длина дейтаграммы нечетна, то к ее концу добавляют один байт с нулевым значением. Перед началом расчета в поле «Контрольная сумма»

записывается нулевое значение. Затем вычисляется контрольная сумма (по тому же алгоритму, как и в протоколе IP), результат записывается в поле «Контрольная сумма», а псевдозаголовок отбрасывается.

2.6.3 Протокол TCP Протокол TCP (англ. Transmission Control Protocol, Протокол управления передачей) описан в RFC 793. Он обеспечивает надежную передачу потока данных, используя сервис передачи дейтаграмм протокола IP. Пакеты, передаваемые протоколом TCP, называются сегментами. Каждый TCP-сегмент размещается в одном IP-пакете (а в каждом IP-пакете может находиться только один TCP-сегмент). Надежность передачи обеспечивается при помощи нумерации байтов потока и подтверждений приема. Все байты исходного последовательности (англ. sequence number)), и с каждым сегментом передается номер в последовательности его первого байта.

Поскольку два узла могут передавать два встречных потока данные по одному TCP-соединению, для передачи подтверждений одного потока используются сегменты встречного потока. В каждом сегменте передается номер в последовательности байта, который собирается принять данный узел.

После того, как модуль TCP передаст сегмент модулю IP, он записывает его копию в очередь на повторную передачу и запускает таймер для этого сегмента. Когда поступит подтверждение приема сегмента (то есть будет принят сегмент, в котором будет заявлено, что та сторона готова принять байт с номером, большим всех номеров байтов сегмента, ждущего повторной передачи), сегмент удаляется из очереди. Если подтверждение не поступает до срабатывания таймера, сегмент отправляется повторно.

Сегмент состоит из заголовка и поля данных. Формат заголовка сегмента TCP приведен на рисунке 2.7.

Рисунок 2.7 — Формат заголовка TCP-сегмента Поле Порт отправителя (англ. Source port) и Порт получателя (англ.

Destination port) [16 бит] — номера портов на узлах.

Поле Номер в последовательности (англ. Sequence Number) [32 бита] — номер в потоке первого байта данных этого сегмента. Если установлен управляющий бит SYN, то в этом поле содержится начальный номер в последовательности (англ. Initial Sequence Number, ISN) и первый байт данных сегмента имеет номер в потоке ISN+1.

Поле Номер подтверждения (англ. Acknowledgement number) [32 бита] — номер байта в потоке, ожидаемого отправителем данного сегмента. При этом должен быть установлен управляющий бит ACK.

Поле Смещение данных (англ. Data offset) [4 бита] — количество 32битовых слов в заголовке TCP-сегмента. Минимальное значение поля — 5 (20байтовый заголовок).

Поле Резерв (англ. Reserved) [6 бит] — должны быть заполнены нулями.

Поле Биты управления (англ. Control bits) [6 бит] — от старшего к младшему:

• URG (англ. Urgent Pointer field significant) — принимать во внимание поле «Указатель срочности»;

• ACK (англ. Acknowledgement field significant) — принимать во внимание поле «Номер подтверждения»;

• PSH (англ. Push function) — сегмент был принудительно отправлен не дожидаясь заполнения данными;

• RST (англ. Reset the connection) — прервать связь;

• SYN (англ. Synchronize sequence numbers) — синхронизировать • FIN (англ. No more data from sender) — отправитель больше не Поле Окно (англ. Window) [16 бит] — размер окна — количество байтов данных, начиная с указанного в поле «Номер подтверждения», которые отправитель данного сегмента готов принять.

Поле Контрольная сумма (англ. Checksum) [16 бит] — контрольная сумма всего сегмента (заголовка и данных), вычисляется по алгоритму протокола IP.

Как и в UDP, перед вычислением контрольной суммы к сегменту приписывается псевдозаголовок (той же структуры, что и в UDP).

Поле Указатель срочности (англ. Urgent Pointer) [16 бит] — содержит номер первого байта, имеющего обычный статус срочности. При этом должен быть установлен управляющий бит URG.

Поле Опции (англ. Options) [переменный размер] — дополнительная служебная информация. Подобно опциям заголовка IP-дейтаграммы, имеют переменную длину и могут вообще отсутствовать.

Поле Выравнивание (англ. Padding) — поле, используемое для доведения размера заголовка до целого числа 32-битовых слов.

Установление соединения Прежде, чем процессы смогут обмениваться данными по TCP, необходимо установить TCP-соединение (англ. session); при этом используется процедура трехэтапного приветствия (англ. three-way handshake):

• Клиент генерирует случайное число, которое будет использовано в качестве ISN (т.е. клиент будет нумеровать отправляемые байты начиная с этого числа), и отправляет сегмент с установленным последовательности».

• Сервер, получив сегмент с управляющим битом SYN, сохраняет пришедший в нем ISN клиента, генерирует свой ISN как случайное число, начиная с которого он будет нумеровать отправляемые байты, и отправляет сегмент с установленными управляющими битами SYN и АСК, своим ISN в поле «Номер в последовательности» и полученным от клиента ISN+1 в поле «Номер подтверждения».

• Клиент, получив сегмент с управляющими битами SYN и ACK, сохраняет пришедший в нем ISN сервера и отправляет сегмент с установленным управляющим битами АСК, своим ISN в поле «Номер в последовательности» и полученным от сервера ISN+1 в поле «Номер подтверждения».

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

Отметим, что на SYN-сегмент расходуется одно значение номера в последовательности (равное ISN), хотя в нем не передаются байты пользовательских данных.

Разрыв соединения противоположно направленных канала передачи данных, для корректного разрыва соединения необходимо и достаточно закрыть оба этих канала.

Если одна из сторон больше не собирается передавать данные по соединению, она должна передать сегмент с установленным управляющим битом FIN. Получив такой сегмент, вторая сторона должна подтвердить его получение сегментом с установленным управляющим битом ACK. После этого один из пары каналов (тот, по которому передавался FIN-сегмент) считается закрытым. Второй канал закрывается аналогично (FIN-сегмент в одну сторону, ACK-сегмент в ответ), но по инициативе другой стороны. Соединение может быть наполовину закрытым сколь угодно долго.

Таким образом, для корректного разрыва соединения нужно передать четыре сегмента. Отметим, что, как и при установлении соединения, на каждый FIN-сегмент расходуется одно значение номера в последовательности, хотя в нем не передаются байты пользовательских данных.

Если один из компьютеров, установивших соединение, отключается от сети, не выполнив корректного разрыва соединения (например, при сбое ОС или при нарушении работы канала связи), то вторая сторона соединения разорвет соединение не сразу, а только после истечения достаточно длительного промежутка времени. Это дает возможность первому компьютеру продолжить обмен данными по этому соединению (например, после восстановления работоспособности канала связи).

Размер сегмента При формировании TCP-сегментов желательно, чтобы они имели такой размер, чтобы несущие их IP-пакеты не нужно было фрагментировать. Это значит, что максимальный размер сегмента должен зависеть от того, по сетям каких технологий пролегает путь между двумя узлами, установившими TCPсоединение: если на этом пути встречаются сети с маленьким размером кадра (например, сети X.25 с размером кадра 512 байт), максимальный размер данных поля сегмента должен быть таким, чтобы размер IP-пакета (т.е. размер данных + размер TCP-заголовка (обычно 20 байт) + размер IP-заголовка (обычно байт)), в котором он размещен, не превосходил минимальный размер кадра промежуточных сетей.

В любом случае, максимальный размер IP-пакета, несущего TCP-сегмент, не должен превышать максимального размера поля данных кадра сети, к которой непосредственно подключен узел. Например, для сетей Ethernet с максимальным размером поля данных кадра, равным 1500 байт (для кадров Ethernet II/DIX и 802.3), максимальный размер сегмента (англ. MSS, Maximum Segment Size) не должен превышать 1460 байт.

Если есть возможность увеличения MSS (например, известно, что обмен данными по TCP происходит только в локальной сети Ethernet), то ею не стоит пренебрегать: чем больше MSS, тем больше данных переносится в одном кадре, тем меньше накладные расходы и тем эффективнее передача данных.

По умолчанию (если в настройках TCP/IP не указано иное значение) размер сегмента равен 536 байт (поскольку максимальный размер IP-пакета по умолчанию равен 576 байт).

Окна приема Протокол TCP имеет средства управления потоком данных: если принимающая данные сторона не успевает их обрабатывать, отправитель замедляет или приостанавливает передачу.

В процессе установки соединения каждая из сторон выделяет память под входной и выходной буферы и передает (в поле «Окно» того же SYN-сегмента, в котором передается ISN) второй стороне количество байт, которые она готова принять (не больше, чем размер своего входного буфера); это число в TCP называется окном приема (англ. receive window). Получив значение окна приема, вторая сторона сохраняет его в блоке управления передачей, связанном с соединением, и в процессе передачи данных следит за тем, чтобы объем отправленных, но неподтвержденных данных никогда не превышал размер окна приема.

В процессе передачи данных стороны могут изменять свои окна приема (размер окна приема передается в каждом сегменте в поле «Окно»): например, если приемник перегружен, он может передать сегмент с полем «Окно», равным нулю (чтобы отправитель приостановил передачу), а когда перегрузка приемника закончится, передать сегмент с нормальным значением в поле «Окно».

В начале передачи данных, пока приемник и передатчик не уверены в качестве соединяющих их каналов связи, обычно обе стороны устанавливают небольшое окно приема (размером в один MSS). По мере того, как приходят подтверждения, размер окна увеличивается экспоненциально (после первого подтверждения — два MSS, после второго — четыре MSS, после третьего — восемь MSS и т.д.) до некоторого порога, после которого растет линейно (с каждым новым подтверждением окно увеличивается на один MSS). Если хотя бы один сегмент не подтвержден (или пришел сегмент с запросом повторной передачи), размер окна уменьшается вдвое с каждым неподтвержденным или перезапрошенным сегментом, пока сегменты не начнут снова подтверждаться.

Дальше окно приема опять начинает расти.

Блок управления передачей и состояния соединения Каждый раз при установлении соединения модуль TCP создает структуру данных — Блок управления передачей (англ. Transmission Control Block, TCB), хранящую постоянную информацию о соединении (IP-адреса, номера портов, указатели на входной и выходной буферы, очередь повторной отправки и т.д.) и текущие значения переменных, описывающих текущее состояние соединения.

К этим переменным относятся:

• SND.UNA — не подтвержденная посылка;

• SND.NXT — следующий сегмент на отправку;

• SND.WND — окно передачи;

• SND.UP — указатель срочности для отправляемых данных;

• SND.WL1 — номер в последовательности, использованный для последней коррекции окна;

• SND.WL2 — номер подтверждения, использованный для последней • ISS — начальный номер в последовательности для отправки;

• RCV.NXT — следующий сегмент, который можно принять;

• RCV.WND — окно приема;

• RCV.UP — указатель срочности для принимаемых данных;

• IRS — начальный номер в последовательности для приема.

Кроме того, значения некоторых полей заголовка текущего сегмента тоже переносятся в переменные TCB:

• SEG.SEQ — номер в последовательности;

• SEG.ACK — номер подтверждения;

• SEG.LEN — длина сегмента;

• SEG.WND — размер окна;

• SEG.UP— указатель срочности;

• SEG.PRC — приоритет.

TCP-соединение в каждый момент времени находится в одном из следующих состояний:

• LISTEN (Прослушивание) — ожидание запроса на соединение;

• SYN-SENT (Синхронизация отправлена) — ожидание парного запроса на соединение (после того, как был отправлен запрос на соединение);

подтверждения после обмена запросами на соединение;

• ESTABLISHED (Установлено) — соединение установлено и может передавать пользовательские данные; основное рабочее состояние;

• FIN-WAIT-1 (Ожидание завершения 1) — ожидание запроса на завершение соединения или подтверждения своего запроса на завершение соединения;

• FIN-WAIT-2 (Ожидание завершения 2) — ожидание запроса на завершение соединения;

• CLOSE-WAIT (Ожидание закрытия) — ожидание запроса на закрытие соединения от своего прикладного процесса;

• CLOSING (Закрытие) — ожидание подтверждения запроса на закрытие соединения;

• LAST-ACK (Последнее подтверждение) — ожидание подтверждения подтверждение запроса на закрытие соединения);

• TIME-WAIT (Ожидание) — пауза для уверенности, что дальняя сторона соединения получила подтверждение своего запроса на закрытие соединения • CLOSED (Закрыто) — соединение закрыто.

2.7 Вопросы для самопроверки • Необходимы ли символьные адреса (обеспечиваемые, например, серверами DNS) для обмена данными между узлами TCP/IP-сети?

• Для чего IP адрес состоит из двух полей — номера подсети и номера узла в подсети?

• Для чего используется IP адрес 255.255.255.255?

• Зачем нужны маски подсети?

• Как протокол IP обеспечивает надежную доставку дейтаграмм?

• Данными из какого поля заголовка IP-пакета пользуются маршрутизаторы для определения зациклившихся пакетов?

• Для чего служит поле «Протокол» в заголовке IP-пакета?

• Как получатель определяет, что два IP-пакета являются фрагментами одного «большого пакета»?

• Достаточно ли для передачи данных между двумя узлами локальной сети им знать IP-адреса друг друга?

• Что позволяет отправителю рассчитывать на то, что его ARP-запрос увидят все соседние узлы?

• Какое сообщение ICMP отправит маршрутизатор, если не сможет определить локальный адрес узла-получателя пакета, чей IP-адрес принадлежит к его локальной сети?

• Для чего транспортные протоколы используют порты?

• В каких случаях предпочтительно использовать протокол UDP?

• Как протокол TCP обеспечивает надежную доставку данных?

• Почему протокол TCP генерирует случайный исходный номер в последовательности для каждого соединения, а не просто нумерует байты, начиная с 0 или 1?

• Что такое «трехэтапное приветствие» в протоколе TCP?

• Для чего используются окна приема в протоколе TCP?

3 Маршрутизация в сетях TCP/IP Протокол маршрутизации — это набор правил, описывающий способ передачи маршрутизаторами друг другу информации о доступных им сетях. На основе этой информации каждый маршрутизатор может выбирать наилучший путь передачи для каждого пакета.

Важно различать маршрутизируемые (англ. routed) протоколы и протоколы маршрутизации (англ. routing). Маршрутизируемый протокол — это тот протокол, ради которого выполняется маршрутизации, например, IP в сетях TCP/IP. Протокол маршрутизации (например, RIP, OSPF или IGRP) является служебным протоколом, обеспечивающим наличие у каждого маршрутизатора достаточной информации для выполнения маршрутизации IP-пакетов.

Основная задача маршрутизации — выбор для каждого пакета пути от исходного узла к узлу назначения. В объединенных TCP/IP сетях она сводится к более простой задаче нахождения шлюзов (маршрутизаторов), соединяющих подсети на этом пути. В каждой отдельной подсети пакеты доставляются средствами локальной технологии (как правило, канального уровня).

Информация, используемая маршрутизатором при выборе путей передачи пакетов, сводится в таблицу маршрутизации (англ. routing table). Как минимум, таблица маршрутизации должна содержать следующие столбцы:

• подсеть назначения;

• выходной интерфейс;

• расстояние до подсети назначения (метрика);

• IP-адрес следующего маршрутизатора.

Для того чтобы маршрутизатор мог выбрать из нескольких возможных путей наилучший, каждому пути сопоставляется числовое значение — метрика.

Как правило, чем метрика меньше, тем путь лучше.

Ранние протоколы маршрутизации в качестве метрики использовали длину пути (т.е. количество промежуточных маршрутизаторов; используется также термин ‘хоп’, от англ. hop — hands-off points (точки передачи)). Однако этот способ не позволяет учесть, например, разную пропускную способность каналов, что приводит к неэффективной работе. При использовании такой метрики, например, прямой канал через асинхронный модем (56 кбит/с, метрика равна 1) окажется предпочтительнее пути по двум каналам с пропускной способностью по 100 Мбит/с, но через лишний маршрутизатор ( Мбит/с, метрика равна 2).

Современные протоколы маршрутизации используют сложные метрики, учитывающие следующие факторы:

• пропускная способность канала;

• время задержки;

• загруженность канала;

• надежность канала;

• количество промежуточных маршрутизаторов;

• стоимость пользования каналом.

Для просмотра таблицы маршрутизации в ОС семейства Windows используется команда ‘route PRINT’, в ОС семейства Unix — ‘netstat —r’, в ОС сетевого оборудования фирмы Cisco (IOS) — ‘show ip route’.

Топология сетей, особенно больших, может изменяться: подключаются и отключаются каналы, меняются настройки маршрутизаторов, происходят сбои в оборудовании. Маршрутизаторам необходимо поддерживать общее, согласованное с действительностью представление о сети. Если достигнуто именно такое положение дел, говорят, что сеть «сходится» (англ. converge).

Время, которое требуется для того, чтобы сеть «сошлась» после изменения ее топологии, называется временем схождения. Время схождения зависит от протокола маршрутизации. Чем меньше время схождения, тем лучше.

В зависимости от предназначения протоколы маршрутизации делятся на протоколы внутренней маршрутизации (англ. Interior Gateway Protocol, IGP) и протоколы внешней маршрутизации (англ. Exterior Gateway Protocol, EGP).

Внутренняя маршрутизация осуществляется в пределах автономной системы (англ. Autonomous System, AS) — совокупности сетей и подсетей с единым управлением (например, принадлежащих одной организации). Протоколы внутренней маршрутизации должны выбирать наилучшие пути для пакетов по сетям, входящим в автономную систему, исходя только из технических характеристик сетей и каналов связи. Внешняя маршрутизации, напротив, гораздо сильнее зависит от установленных политик маршрутизации, чем от технических характеристик сетей. Так, например, может быт установлен запрет на передачу пакетов через соседнюю автономную систему, взимающую слишком высокую плату за трафик, невзирая на качество канала связи с ней.

Протоколы маршрутизации в зависимости от способа расчета маршрутов делятся на три типа: дистанционно-векторные протоколы (англ. distance vector routing protocol), протоколы на основе состояний связей (англ. link-state routing protocol) и гибридные протоколы.

Маршрутизаторы, выполняющие дистанционно-векторный протокол, периодически рассылают всем соседним маршрутизаторам обновления своей таблицы маршрутизации. Получив от соседа обновление, маршрутизатор соответственно корректирует свою таблицу маршрутизации и рассылает всю таблицу или только изменившуюся ее часть всем своим соседям.

Процесс рассылки обновлений (англ. routing update) выполняется маршрутизации каждые 30 секунд, а протокол IGRP — только изменившуюся часть таблицы каждые 90 секунд.

Протоколы на основе векторов расстояний обычно используют простую используется алгоритм Беллмана-Форда.

Одна из основных проблем, связанная с этой группой протоколов — возможность создания бесконечных циклов при отключении отдельных подсетей. При этом два маршрутизатора могут быть уверены, что отключенная сеть доступна через соседа, и бесконечно передавать пакет друг другу. Для предотвращения таких ситуаций или уменьшения их негативного влияния протоколы на основе векторов расстояний часто реализуют дополнительные функции, среди которых:

• счет до бесконечности (англ. count to infinity): при добавлении к таблице маршрутизации новых записей, полученных от соседа, все метрики в этих записях увеличиваются на 1; если метрика превысила 15 (бесконечность в данном случае принимается равной 16), то соответствующая сеть помечается как недоступная;

• расщепленный горизонт (англ. split horizon): маршрутизатор никогда не передает информацию о сетях, полученную от некоторого соседа, обратно этому соседу;

• расщепленный горизонт c ответом-заглушкой (англ. split horizon with poison reverse): до передачи обновлений по методу расщепленного горизонта, маршрутизатор присваивает записям об отключенных сетях • пережидание (англ. hold-down): после того, как маршрутизатор пометил сеть, как недоступную, он в течение нескольких (по игнорировать любую информации о достижимости этой сети (кроме как от того маршрутизатора, который сообщил о недоступности сети);

• мгновенное обновление (англ. triggered updates): маршрутизатор будет рассылать обновления сразу после того, как изменилась метрика у какого-либо маршрута (а не будет дожидаться момента регулярной • балансировка нагрузки (англ. load balancing): если к сети назначения ведут несколько путей с одинаковыми метриками, маршрутизатор будет распределять поток пакетов по всем этим путям равномерно.

Целью работы протоколов на основе состояний связей является построение каждым из маршрутизаторов полного графа связности сети (как правило, с указанием характеристик связей — пропускной способности, загрузки каналов и т.д.) При этом маршрутизаторы передают друг другу не полную свою таблицу маршрутизации, а только информацию о ребрах графа сети — связях «маршрутизатор — маршрутизатор» и «маршрутизатор — подсеть». На основании этой информации каждый маршрутизатор строит полный граф сети, затем для каждой достижимой сети ищет на этом графе путь с минимальной суммой метрик (как правило, по алгоритму Дейкстры) и заносит его в таблицу маршрутизации. Собственно маршрутизация пакетов осуществляется на основании таблицы маршрутизации (а не графа сети).

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

Основные достоинства таких протоколов — быстрая сходимость, возможность учета разных характеристик каналов связи, небольшая нагрузка на сеть при передаче служебной информации (и объем данных, и частота их передачи меньше, чем в протоколах на основе векторов расстояний).

Основные недостатки протоколов на основе состояний связей — большая вычислительная сложность, которая влечет необходимость применения более быстродействующих процессоров и большой размер графов сети, что влечет необходимость использования больших объемов оперативной памяти. Кроме того, в начале работы сети все маршрутизаторы обмениваются большими объемами топологической информации, что приводит к скачкообразному росту нагрузки на сеть. К этой группе протоколов относится OSPF.

Третий тип протоколов маршрутизации, гибридные протоколы, выбирают маршруты на основе векторов расстояний, но выполняют обновление таблиц сразу, как только изменяется топология. В результате гибридные протоколы сходятся практически так же быстро, как протоколы на основе состояний связей, но требуют гораздо меньше ресурсов (прежде всего памяти и процессорного времени). К гибридным протоколам относятся IS-IS и EIGRP.

3.1 Протокол маршрутизации RIP Первая версия протокола RIP (англ. Routing Information Protocol version 1, RIPv1) использует технологию векторов расстояний и рассылает полную таблицу маршрутизации каждые 30 секунд. Максимальный диаметр сети — переходов. Полное описание RIPv1 содержится в RFC 1058.

Поддержка RIP в маршрутизаторах может быть либо пассивной (только прослушивание RIP-сообщений и модификация своей таблицы маршрутизации), либо активной (и прослушивание, и рассылка RIPсообщений). Узлы могут поддерживать RIP только в пассивном режиме.

При внесении в таблицу маршрутизации записи, полученной от другого маршрутизатора, с ней связывается таймер. Если за 180 секунд (шестикратный период рассылки) не будет получено повторное сообщение, содержащее этот же маршрут, запись станет недействительной.

Протокол RIP использует UDP-дейтаграммы, передаваемые через 520-й порт. Каждое сообщение протокола RIP состоит из заголовка фиксированной длины (4 байта, см. рисунок 3.1) и нескольких (от 1 до 25) записей (длиной по 20 байт, см. рисунок 3.2), соответствующих записям таблицы маршрутизации.

Первая версия протокола RIP использует только часть полей, имеющихся в заголовке и записях; все остальные биты должны быть установлены в “0”. Если размер таблицы маршрутизации превышает 25 записей, то она передается в нескольких сообщениях.

Команда Версия Рисунок 3.1 — Формат заголовка сообщения протокола RIPv Идентификатор адресной схемы 00 Рисунок 3.2 — Формат записи сообщения протокола RIPv маршрутизатор, приняв это сообщение. Основные используемые значения:

«1» — запрос, «2»— ответ.

Поле Версия хранит номер версии протокола RIP.

Поле Идентификатор адресной схемы указывает тип адреса (IP-адресам соответствует идентификатор «2»).

Поле IP-адрес хранит IP-адрес сети или узла назначения (кроме того, в этом поле может содержаться значение «0», соответствующее маршруту по умолчанию). Восемь следующих байт в случае IP-адресов должным быть заполнены нулями, но при других адресных схемах (с более длинными сетевыми адресами) могут хранить последующие байты адреса.

Поле Метрика хранит количество переходов от данного маршрутизатора до указанной сети или узла. При вычислении метрики в RIP маршрутизатор всегда учитывает самого себя, т.е. непосредственно подключенная сеть находится на расстоянии одного перехода, сеть, непосредственно подключенная к соседнему маршрутизатору — двух переходов и т.д.

Администратор может вручную устанавливать большие метрики для сетей, подключенных через низкоскоростные каналы. Значение метрики, равное 16, указывает на отсутствие соединения с данной сетью (прием “poison reverse”).

Вторая версия протокола RIP (описанная в RFC 1388) поддерживает маски подсети, бесклассовую маршрутизацию CIDR и групповую передачу.

Форматы заголовка и записи сообщения протокола RIP версии 2 показаны на рисунках 3.3 и 3.4. соответственно.

Команда Версия Домен маршрутизации Рисунок 3.3 — Формат заголовка сообщения протокола RIPv Рисунок 3.4 — Формат записи сообщения протокола RIPv Поле Домен маршрутизации может использоваться при внешней маршрутизации. По умолчанию оно должно содержать нули.

Наиболее существенное отличие RIPv2 от RIPv1 — в наличии поля Маска подсети, позволяющего выполнять маршрутизацию не только для сетей классов A,B и C, но и для любых подсетей.

Поле Метка маршрута может использоваться, если RIP выполняет функции протокола внешней маршрутизации; в этом случае в это поле должен быть записан номер автономной системы.

Поле Следующий хоп содержит адрес ближайшего маршрутизатора, через который пролегает путь к данной сети (от маршрутизатора, сформировавшего данное RIP-сообщение).

В отличие от RIPv1, не поддерживающего аутентификацию отправителя сообщения, RIPv2 допускает замену первой записи после заголовка на запись аутентификации (см. рисунок 3.5), и в безопасном режиме игнорирует сообщения от неаутентифицированных источников.

Данные для аутентификации (продолжение) Данные для аутентификации (продолжение) Данные для аутентификации (продолжение) Рисунок 3.5 — Формат записи аутентификации сообщения протокола RIPv Протокол RIP хорошо подходит для использования в небольших сетях, в качестве протокола внутренней маршрутизации в автономных системах с небольшим количеством маршрутизаторов 3.2 Протокол маршрутизации OSPF Протокол OSPF (англ. Open Shortest Path First) использует технологию состояний связей и описан в RFC 1247 и RFC 2328.

Сообщения OSPF передаются в IP-дейтаграммах со значением «89» в поле заголовка «Протокол». Информация о состоянии каналов широковещательно рассылается каждым маршрутизатором всем своим соседям каждые 30 минут (даже в том случае, если никаких изменений с момента прошлой рассылки не было). Если топология сети изменилась, сообщения об этом рассылаются немедленно.

Протокол OSPF позволяет администратору либо задавать метрики маршрутов произвольно (исходя из собственных, часто неформализуемых соображений), либо выбирать способ вычисления сложной метрики. Метрика по умолчанию — время передачи по каналу одного бита, деленное на наносекунд (10-8 c), например, для Ethernet 10 Мбит/с эта метрика равна ((1/107)/10-8 = 10), для Ethernet 100 Мбит/с — 1, а для модемного канала связи с пропускной способностью 28800 бит/с — 3472.

Каждый маршрутизатор строит описание графа сети (вершины — маршрутизаторы и сети, ребра — однонаправленные связи между ними) в виде базы данных состояний связей: для каждой связи хранится ее метрика. Графы, построенные всеми маршрутизаторами, должны совпадать. По базе данных состояний связей алгоритм Дейкстры вычисляет кратчайшие пути от заданной вершины (соответствующей данному маршрутизатору) до всех остальных вершин. Результат его работы заносится в таблицу маршрутизации.

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

На рисунке 3.6 показан заголовок сообщения протокола OSPF.

Данные для аутентификации (продолжение) Рисунок 3.6 — Формат заголовка сообщения протокола OSPF Поле Версия — номер версии протокола OSPF (текущая версия — 2).

Поле Тип — содержит тип сообщения из следующего перечня:

1 — проверка достижимости (англ. HELLO), 2 — описание базы данных (англ. Database description), 3 — запрос состояния связей (англ. Link state request), 4 — обновление состояния связей (англ. Link state update), 5 — подтверждение состояния (англ. Link state acknowledgement).

Поле Длина сообщения — длина сообщения (с заголовком) в байтах.

Поле IP-адрес маршрутизатора — адрес маршрутизатора, отправившего сообщение (должен быть выбран адрес одного из интерфейсов).

Поле Идентификатор области — номер области, к которой относится сообщение; обычно используется IP-адрес подсети.

Поле Контрольная сумма — вычисляется для всего сообщения (с заголовком, но без полей аутентификационных данных) по алгоритму протокола IP.

Поле Тип аутентификации: «0» — нет аутентификации, Поле Аутентификационные данные: если аутентификация используется, то в этом поле хранится, например, пароль.

3.3 Протоколы внутренней маршрутизации IGRP и EIGRP Протокол IGRP (англ. Interior Gateway Routing Protocol, внутренний протокол маршрутизации шлюзов) разработан фирмой Cisco Systems в начале 1980-х и использует технологию векторов расстояний. Протокол IGRP используется только в маршрутизаторах фирмы Cisco. Его принципиальные отличия от RIPv1 сводятся к следующему:

• метрика вычисляется исходя из пропускной способности, задержки, нагрузки и надежности связей;

• максимальный диаметр сети — 255 хопов (по умолчанию — 100);

• период рассылки обновлений — 90 секунд;

• при использовании нескольких путей к одной сети нагрузка распределяется не равномерно, а пропорционально их метрикам;

• более экономная структура служебных пакетов.

В протоколе IGRP используются многие из перечисленных выше дополнительных функций протоколов на основе векторов расстояний:

расщепленный горизонт (англ. split horizon), расщепленный горизонт c ответомзаглушкой (англ. split horizon with poison reverse), пережидание (англ. holddown), мгновенное обновление (англ. triggered updates или flash updates).

Гибридный протокол EIGRP (англ. Enhanced Interior Gateway Routing Protocol, усовершенствованный внутренний протокол маршрутизации шлюзов) разработан фирмой Cisco Systems на основе IGRP в ответ на появление протокола OSPF. Как и IGRP, протокол EIGRP используется только в маршрутизаторах фирмы Cisco. Перечислим основные усовершенствования EIGRP по сравнению с IGRP:

• специальный алгоритм распространения информации об изменениях топологии сети — алгоритм DUAL (англ. Diffuse Update Algorithm, алгоритм распространения обновлений);

• поддержка бесклассовой адресации;

• поддержка других протоколов сетевого уровня (кроме IP);

• передача частичных обновлений таблицы маршрутизации.

Алгоритм DUAL основан на определении для каждой подсети назначения двух (а не единственного, как в других протоколах) маршрутизаторов:

преемника (англ. successor) и возможного преемника (англ. feasible successor).

Для каждого возможного маршрута до подсети назначения вычисляются две метрики: объявленное расстояние (англ. advertised distance) и возможное расстояние (англ. feasible distance). Объявленное расстояние вычисляется как сумма метрик всех связей, составляющих маршрут, кроме самой первой.

Возможное расстояние — это просто сумма метрик всех связей, составляющих маршрут.

Маршрутизатором — преемником для подсети назначается тот из соседних маршрутизаторов, через который проходит маршрут с минимальным значением объявленного расстояния. Маршрутизатором — возможным преемником для подсети назначается тот из соседних маршрутизаторов, через который проходит маршрут, объявленного расстояние для которого меньше, чем возможное расстояние для маршрута через преемника. Возможный преемник используется для доставки пакетов к подсети назначения в том случае, если доставка пакетов через преемника невозможна.

3.4 Протоколы внешней маршрутизации EGP и BGP Напомним, что автономная система (AS) — это совокупность сетей, с единым организационным управлением, соединенных группой маршрутизаторов, имеющих единые правила маршрутизации. Всеми остальными маршрутизаторами сети данная автономная система воспринимается как единое целое. Каждой автономной системе Реестром Интернета назначается уникальный идентификационный номер. Каждая автономная система может самостоятельно и независимо от других автономных систем выбирать протокол (или протоколы) внутренней маршрутизации.

Различают следующие типы автономных систем: одноканальные (англ.

single-homed), многоканальные без транзита (англ. multi-homed nontranzit) и многоканальные с транзитом (англ. multi-homed tranzit).

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

Автономная система называется многоканальной, если она имеет несколько соединений с Интернетом. Автономная система без транзита не разрешает передавать через себя чужой трафик, для чего сообщает другим автономным системам только свои собственные маршруты (т.е. маршруты до своих пограничных маршрутизаторов). Автономная система с транзитом разрешает транзитное прохождение чужого трафика и сообщает не только собственные маршруты, но и маршруты, полученные ими от других автономных систем.

Протоколы внешней маршрутизации используются для определения маршрутов передачи данных между автономными системами. Метрики маршрутов в таких протоколах рассчитываются не относительно своих интерфейсов маршрутизатора, а относительно некоторой сети (называемой исходной сетью, англ. Source Network), достижимой из всех сетей данной автономной системы.

Протокол EGP (англ. Exterior Gateway Protocol, внешний протокол шлюзов) был первым протоколом внешней маршрутизации в Интернете и описан в RFC 904. В настоящее время стандартом де-факто является протокол BGP (англ. Border Gateway Protocol, граничный протокол шлюзов) версии описанный в RFC 1771. Он более интеллектуален, чем EGP, в частности, использует метрики для выбора каналов и умеет предотвращать образование петель.

С точки зрения протокола BGP, весь Интернет представляет собой граф, узлами которого являются автономные системы с уникальными идентификаторами, а ребрами — соединения между автономными системами.

от Последовательность ребер, проходя по которым можно попасть из одной автономной системы в другую, называется маршрутом. Каждый маршрутизатор BGP хранит таблицу маршрутов от своей автономной системы до всех достижимых автономных систем.

Маршрутизаторы, поддерживающие BGP, называются спикерами (англ.

speaker) BGP. Два спикера BGP, устанавливающие соединение друг с другом, называются соседями (англ. neightbors) или одноранговыми (англ. peers). Для соединения спикеры BGP используют порт 179 протокола TCP.

В начале сеанса соседи обмениваются всей имеющейся у них маршрутной информацией, а в дальнейшем передают друг другу только информацию о новых и удаленных маршрутах — инкрементные обновления (англ. incremental updates) — в пакетах UPDATE. Если никаких изменений в структуре маршрутов нет, соседи периодически обмениваются только маленькими пакетами KEEPALIVE (размером 19 байт), подтверждающими наличие соединения.

Заголовок сообщения в BGP состоит из трех полей, приведенных на рисунке 3.7.

Рисунок 3.7 — Формат заголовка сообщения протокола BGP Поле маркера используется для аутентификации (с использованием алгоритма MD5) входящих сообщений. В поле длины хранится длина сообщения в байтах, включая заголовок. Наименьшая длина сообщения — байт, наибольшая — 4096 байт. Поле типа определяет один из четырех типов сообщения:

• OPEN (открытие соединения), • UPDATE (обновление маршрутной информации), • NOTIFICATION (сообщение об ошибке), • KEEPALIVE (подтверждение наличия соединения).

Информация о действующих маршрутах передается в сообщениях UPDATE, каждое из которых состоит из трех частей: недостижимые маршруты (т.е. те маршруты, которые были в таблице маршрутизации, но стали недействительными), атрибуты маршрута и информация о доступности сети NLRI (англ. Network Layer Reachability Information), 3.5 Вопросы для самопроверки • Какие протоколы маршрутизации требуют больше оперативной памяти на маршрутизаторе — дистанционно-векторные или состояния • Какие недостатки первой версии протокола RIP привели к разработке • Чем отличаются метрики в протоколах RIP и OSPF?

• Для чего протокол OSPF строит полный граф сети?

• Какие проблемы позволяет предотвратить метод расщепленного горизонта (split horizon)?

• Для чего используется мгновенное обновление (triggered update)?

• Что такое «исходная сеть» (source network) в протоколе BGP?

4 Протоколы и службы на основе TCP/IP 4.1 Служба DNS Служба именования доменов (DNS, Domain Name System) описана в RFC и предназначена для установления глобального соответствия между символическими имена узлов и их IP-адресами. На ранних этапах развития TCP/IP сетей нужды в распределенной службе имен не было: существовал один текстовый файл, в котором были перечислены все имена узлов и их IP-адреса.

Однако с ростом количества узлов такое решение стало неприемлемым.

DNS использует иерархическую схему выделения имен, позволяя децентрализовать управление отдельными участками пространства имен.

DNS-сервер домена должен поддерживать таблицу соответствий IPадресов и символических имен для всех узлов, входящих в домен.

Каждый узел домена должен знать только IP-адрес своего сервера домена и направлять ему все запросы на преобразование символических имен узлов в IP-адреса (такие запросы называются рекурсивными (англ. recursive); сервер, получивший рекурсивный запрос, должен самостоятельно его обслужить и вернуть либо IP-адрес, соответствующий запрошенному имени, либо сообщение об ошибке). Если сервер домена не может самостоятельно ответить на запрос (например, запрошен IP-адрес узла, принадлежащего к другому домену), он может обратиться к корневому DNS-серверу, узнать он него IPадрес сервера требуемого домена, а затем обратиться уже к этому серверу домена. Такие запросы от одного сервера к другому называются итеративными (англ. iterative); сервер, получивший итеративный запрос, может либо обслужить его полностью, либо выдать IP-адрес другого сервера, обладающего более полной информацией. Естественно, DNS-сервер может запоминать результаты подобных поисков и при повторном обращении за той же информацией не повторять весть путь, а сразу выдавать кэшированные данные.

DNS-сервер хранит, в первую очередь, пары «символическое имя—IPадрес» для всех узлов своего домена. Кроме того, в базе данных DNS-сервера имеется информация об адресах всех DNS-серверов данного домена (для повышения надежности поддерживается, как правило, не менее двух DNSсерверов для каждого домена, причем все они должны располагаться в разных IP-подсетях), списки псевдонимов (один и тот же узел может иметь несколько символических имен), а также список почтовых серверов данного домена.

Для передачи запросов на разрешение адресов (и ответов на них) протокол DNS использует UDP-дейтаграммы, передаваемые через порт 53. Для повышения безопасности может использоваться протокол TCP (также порт 53).

4.2 Протоколы сетевого управления Для управления сетевым оборудованием создано два протокола: SNMP (англ. Simple Network Management Protocol, RFC 1157, 1215, 1187, 1089;

разработан в 1988 году) и CMOT (англ. Common Management Information Services and Protocol Over TCP/IP, RFC 1095, в последнее время применение этого протокола ограничено). Протокол SNMP для передачи сообщений использует UDP и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию о положении в TCP/IP-сети. Протокол определяет формат данных, а их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети. SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При своей работе SNMP использует управляющую базу данных (англ.

Management Information Base, MIB, RFC 1213, 1212).

Алгоритмы управления в Интернет обычно описывают в нотации ASN. (

Abstract

syntax notation). Все объекты в Интернет разделены на 10 групп и описаны в MIB: система, интерфейсы, обмены, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу «система» входит название и версия оборудования, операционной системы, сетевого программного обеспечения и т.п. В группу «интерфейсы” «ходит число поддерживаемых интерфейсов, тип интерфейса, работающего под IP (Ethernet, LAPB и т.п.), размер дейтаграмм, скорость обмена, адрес интерфейса. Группа «IP» включает в себя время жизни дейтаграмм, информация о фрагментации, маски подсетей и т.д. В группу «TCP» входят параметры алгоритма повторной пересылки — максимальное число повторных пересылок и т.д. В таблице 4.1 приведен перечень команд SNMP.

Таблица 4.1 — Команды SNMP GET request 0 Получить значение указанной переменной GET next request 1 Получить значение следующей переменной GET response 3 Ответ на команды с кодами 0-2, содержит информацию о GetBulkRequest 5 Запрос пересылки большого объема данных SNMPv3 TRAP 7 Уведомление о наступлении события (новые SNMP-клиент ожидает поступления дейтаграмм на UDP-порт 161. Если SNMP-менеджер заказывает уведомление, то клиент отправляет UDPдейтаграмму с уведомлением на порт 162 менеджера.

4.3 Вопросы для самопроверки • Какие запросы отправляет DNS-сервер (с пустым кэшем), которому пришел запрос на поиск узла www.mgapi.edu?

• Может ли узел, не являющийся DNS-сервером, выдавать итеративные • Какая информация предоставляется узлами по протоколу SNMP?

5 Технологии X.25, FRAME RELAY, PDH, SDH 5.1 Технология X. Глобальные сети X.25 основаны на коммутации пакетов, и долгое время являлись единственными сетями с коммутацией пакетов, гарантирующими готовность. Структурно сеть X.25 состоит из аппаратуры передачи данных (АПД, англ. Data Terminal Equipment, DTE) — терминалы, компьютеры и т.д., аппаратуры окончания канала данных (АОКД, англ. Data Circuit-Terminating Equipment, DCE) —телекоммуникационного оборудования, модемов и т.п. и центров коммутации пакетов (ЦКП, англ. Packet Switching Exchange, PSE).

Кроме того, применяются сборщики-разборщики пакетов (СРП, англ. Packet Assembler/Disassembler, PAD), буферизующие потоки байтов от асинхронных “тупых” терминалов и преобразующие их в потоки пакетов (и производящие обратные преобразования).

Рекомендации ITU-T X.25 «Интерфейс между оконечным оборудованием данных и аппаратурой передачи данных для терминалов, работающих в пакетном режиме в сетях передачи данных общего пользования» охватывают три нижних уровня модели ВОС.

На физическом уровне определены последовательные синхронные интерфейсы X.21 и X.21bis (допустимо использование интерфейсов V.24, V.35, RS-232C, RS-449, G.703). Физический уровень не контролирует правильность передачи.

Интерфейс X. Цепь сигнальной земли G (англ. ground) устанавливает общий уровень, относительно которого измеряются уровни сигналов. Цепь передачи T (англ.

transmit) используется для передачи данных от АПД к АОКД, т.е. от узла в сеть.

Цепь приема R (англ. receive) используется для приема данных АПД от АОКД.

Цепь управления C (англ. control) используется АПД для того, чтобы сообщить АОКД состояние интерфейса: на протяжении всего времени передачи данных по цепи T АПД поддерживает цепь C в активном состоянии. Аналогичную функцию несет цепь индикации I (англ. indication): АОКД переводит ее в активное состояние, чтобы сообщить АПД о передаче данных по цепи R.

По цепи битовой синхронизации S (англ. signal element timing) АОКД постоянно передает синхросигнал. Цепь байтовой синхронизации B (англ. byte timing) также управляется АОКД: цепь B активна во время передачи всех битов байта, кроме последнего, а при передаче последнего бита — пассивна.

На канальном уровне сеть гарантирует доставку, обеспечивает целостность данных и управление потоком. Канальный уровень реализуется подмножеством протокола HDLC — протоколом LAP-B (Link Access Protocol — Balanced). Протокол LAP-B функционирует подобно протоколу LLC2 (IEEE 802.2), то есть требует передачи квитанций и выполняет повторную передачу потерянных пакетов.

На сетевом уровне определен протокол X.25/3 (англ. Packet Layer Protocol, PLP), описывающий обмен пакетами между АПД и СПД. Он выполняет функции маршрутизации пакетов, установления и разрыва виртуального канала, управления потоком пакетов.

После установления соединения АПД с коммутатором на канальном уровне, АПД передает пакет запроса виртуального соединения с другим АКП (англ. Call Request), который маршрутизируется коммутаторами, прокладывая виртуальный канал.

Протокол X.25 допускает длину поля данных пользователя в пакете до 4096 байт, но предпочтительной является длина по умолчанию 128 байт.

Адресация узлов в сети X.25, не связанной с другими сетями, может быть произвольной (до 16 байт на адрес). Для сетей передачи общего пользования Рекомендация ITU-T X.121 определяет международную систему нумерации адресов. Первая цифра указывает на формат остальной части адреса: «0» — полный международный сетевой адрес (три следующих десятичных цифры указывают на страну, например, 250 или 251 — Россия, затем одна цифра под номер сети в стране, затем до десяти цифр номер узла в сети), «9» — полный международный телефонный номер (следующие цифры содержат телефонный код страны, например, 7 — Россия, затем код города и номер телефона в городе, всего до 14 цифр).

Производительность коммутаторов X.25 обычно составляет несколько тысяч пакетов в секунду, что существенно ограничивает пропускную способность сети. Это связано с тем, что протоколы X.25 предназначались для использования на низкоскоростных линиях связи с высоким уровнем помех, поэтому каждый коммутатор должен подтвердить каждый принятый пакет, выполнить разбор пакета для определения дальнейшего пути и повторную его упаковку в кадр LAP-B. При этом задержка коммутации составляет сотни миллисекунд.

5.2 Технология Frame Relay Сети с ретрансляцией кадров (англ. Frame Relay) представляют собой сети с коммутацией пакетов, ориентированные на цифровые линии связи со скоростью до 45 Мбит/с (изначально — до 2 Мбит/с). Frame Relay работает в дейтаграммном режиме с малыми задержками, не гарантирует доставку, целостность данных и управление потоком. При этом сети Frame Relay могут гарантировать среднюю скорость передачи данных по виртуальному каналу при допустимых пульсациях трафика (подобные гарантии качества обслуживания сегодня предоставляет только технология ATM).

Технология Frame Relay происходит из сетей ISDN, где в начале 1980-х она была стандартизована как одна из служб пакетного режима. Frame Relay предназначена для динамического разделения пропускной способности физического канала между отдельными процессами передачи данных (фактически, сети Frame Relay используются не столько для соединения отдельных узлов, сколько для соединения отдельных локальных сетей). При использовании Frame Relay предполагается, что канал передачи данных достаточно надежен, что позволяет перенести контроль ошибок и управление потоком на вышележащие уровни. В результате кадры Frame Relay несут минимальное количество служебной информации и максимально быстро обрабатываются сетевым оборудованием.

Frame Relay обеспечивает установление постоянных (англ. Permanent Virtual Circuit, PVC) и коммутируемых (англ. Switched Virtual Circuit, SVC) виртуальных каналов. В отличие от X.25, Frame Relay передает кадры только по протоколам физического и канального уровня, не затрагивая сетевой уровень.

Протокол канального уровня LAP-F является упрощенной версией протокола LAP-D, работающего в сетях ISDN по D-каналам. В основном режиме LAP-F кадры передаются без преобразований и контроля, как при коммутации в локальных сетях. Хотя для кадров используется синхронный формат HDLC с длиной поля данных до 4 Кбайт и двухбайтовым полем CRC, значение CRC коммутаторами не проверяется. Пакеты могут аннулироваться в случае перегрузки сети.

Идентификация виртуального канала, к которому относится пакет, происходит по 10-битовому полю заголовка кадра DLCI (англ. Data Link Connection Identifier). При необходимости размер DLCI можно довести до бит.

Основу сети Frame Relay образуют специализированные коммутаторы — FRAD (англ. Frame Relay Access Device, устройство доступа к сети с ретрансляцией кадров).

5.2.1 Структура кадра Frame Relay Структура кадра Frame Relay приведена на рисунке 5.1.

Флаг Заголовок Данные пользователя Контрольная сумма Флаг Поля «Флаг» обозначают начало и конец кадра. Двоичное значение этого поля — ‘01111110’.

Поле «Данные пользователя» может иметь размер до 4056 байт и предназначено для данных, передаваемых протоколами верхних уровней.

Поле «Контрольная сумма» содержит 16-ти разрядную контрольную сумму для полей «Заголовок» и «Данные пользователя».

Поле «Заголовок» несет информацию, необходимую для управления передачей данных и имеет формат, приведенный на рисунке 5.2.

DLCI FECN BECN DE EA

Рисунок 5.2 — Структура поля Заголовок кадра Frame Relay Поля EA0 И EA1 (англ. Effective Address, исполнительный адрес) управляют размером заголовка. Если бит EA сброшен (EA0), то в следующем байте содержатся дополнительные биты DLCI. Если бит EA установлен (EA1), то данный байт — последний в заголовке. Минимальный заголовок приведен на рис. и состоит из двух байт, в первом из которых бит EA сброшен, а во втором — установлен. Возможны также трех- и четырехбайтовые заголовки, в которых все байты, кроме последнего, имеют признак EA0, а последний — EA1.

Поле DLCI (англ. Data Link Connection Identifier, идентификатор виртуального соединения) используют коммутаторы (FRAD) для указания друг другу какие данные передаются в этом кадре. При двухбайтовом заголовке поле имеет длину 10 бит, при трехбайтовом — 16 бит, а при четырехбайтовом — бита. Стандарт резервирует интервалы значений DLCI 0..15 и 992..1023 для служебных целей, внутрисетевых соединений и управления канальным уровнем. Пользователями для нумерации PVC и SVC могут использоваться идентификаторов DLCI с номерами от 16 до 991.

Поля FECN (англ. Forward Explicit Congestion Notification, явное уведомление о заторе в прямом направлении) и BECN (англ. Backward Explicit Congestion Notification, явное уведомление о заторе в обратном направлении) используются коммутаторами при возникновении перегрузок в сети. Если коммутатор получает больше кадров, чем он может обработать, то он устанавливает в кадрах, отправляемых источнику избыточных данных, бит BECN, а в кадрах, отправляемых получателю избыточных данных — бит FECN.

Поступление кадра с установленным битом BECN означает, что часть выдаваемых кадров может быть отброшена коммутаторами и нужно замедлить выходной поток. Поступление кадра с установленным битов FECN означает, что в данном потоке возможны (хотя и не обязательно произойдут) выпадения кадров.

Поле DE (англ. Discard Eligibility, приемлемость удаления) устанавливается отправителем кадра и означает, что данный кадр при возникновении перегрузок можно удалить.

Поле C/R (англ. Command/Reply, команда/ответ), когда равно 1, в кадрах, содержащих команды, требует, чтобы на команду был дан ответ, а в кадрах, содержащих ответы, указывает на последний кадр ответа.

5.3 Плезиохронная цифровая иерархия Плезиохронная цифровая иерархия (англ. Plesiochronous Digital Hierarchy, PDH) разработана корпорацией AT&T (Bell Labs) в 1960-х годах для передачи множества потоков оцифрованной голосовой информации по каналам связи.

Основная цель разработки заключалась в повышении скорости многоканальной связи крупных телефонных коммутаторов друг с другом.

Цифровое представление звуковых сигналов Канал, выделяемый телефонными сетями для одного соединения, имеет полосу пропускания 4 кГц, достаточную для приемлемой передачи человеческой речи. Соответственно, характеристики базового цифрового канала выбирались так, чтобы по одному такому каналу можно было передавать данные одного телефонного соединения. В соответствии с теоремой Котельникова-Найквиста, для того, чтобы было можно восстановить исходный сигнал, частота дискретизации должна быть не меньше 2*4 кГц = 8 кГц. Для приемлемого представления человеческой речи достаточно 12-ти бит на отсчет, что соответствует 4096-ти различимым уровням сигнала, а логарифмическое преобразование позволяет снизить разрядность отсчетов до 8 бит, сохраняя субъективное качество сигнала. Логарифм является положительной функцией только при аргументе, превышающем единицу, соответственно, для диапазона аргументов от 0 до 1 необходимо использовать какую-то другую функцию. В Европе и США используют разные преобразования — A-зависимость и µ-зависимость соответственно. В Европе для «малых» аргументов используют линейную функцию y ~ ax, а для «больших» — непосредственно логарифмическую: y = (1+ln A x)/(1+ln A), где A = 87,6. В США сдвигают график функции на единицу в сторону оси ординат: y ~ log(1+ µx).

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