Добавил:

Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Санкт-Петербургский государственный университет телекоммуникаций им. проф. М.А. Бонч-Бруевича

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

KONYeChNAYa_PYeChAT.docx

Скачиваний:

Добавлен:

21.04.2019

Размер:

1.67 Mб

Скачать

☆

<<< < Предыдущая 1 2 3 4 5 6 7 8 9 10 1112 / 1212

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

Движущееся окно, внутрь которого помещено 8 пакетов (а); при получении подтверждения о приеме пакета 1 окно сдвигается на один пакет вправо, и в сеть отправляется 9-й пакет (б). Если для какого-либо пакета, попавшего в окно, не получен сигнал подтверждения, то выполняется повторная передача этого пакета

Режим окна определяется во вспомогательных параметрах ТСР заголовка.

14 Вспомогательные параметры (опции) протокола TCP и примеры их использования.

Брать из лекций стр 6-10

15 Механизмы управления потоком сообщений на уровне TCP

Брать из лекций стр 19-22 (Медленный старт, Reno, Tahoe)

16 Методы борьбы с перегрузками на уровне TCP.

Брать из лекций стр 23-25

17 Протокол пользовательских дейтаграмм UDP и его характеристика. Формат заголовка, назначение его полей

UDP — User Datagram Protocol, RFC 768

Данный протокол иногда называют протоколом ненадёжной доставки. Этот протокол предоставляет прикладным процессам транспортные услуги, которые немногим отличаются от услуг протокола IP (сетевого уровня)

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

Формат протокола udp имеет следующий:

Формат udp-дейтаграммы

Видно, что формат протокола UDP размещается в поле данных IP-пакета (или после заголовка IP-пакета) и содержит следующие поля:

Поле «Порт источника» (Source Port) указывает порт процесса источника, куда может быть адресован ответ на данное сообщение.

Поле «Порт получателя» (Destination Port) является частью межсетевого адреса. Под «портом» понимается адрес (номер) некой точки доступа к услугам другого уровня. В случае архитектуры TCP/IP под портом понимается некий номер области памяти, где размещаются передаваемые в сеть (протоколу UDP или TCP) и принимаемые из сети (поступающие в распоряжение операционной системы) данные. Номера портов на передачу и приём в общем случае могут различаться. На приёмной и передающей сторонах взаимодействие процессов в общем случае может происходить через разные номера портов, поэтому указание порта в заголовке UDP-дейтаграммы необходимо.

В поле «Длина» (Length) указывается размер данной дейтаграммы с учётом длины заголовка в байтах.

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

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

Номера портов, используемые в протоколе UDP
Номер порта	Идентификатор в стандарте	Идентификатор в UNIX	Описание
7	ECHO	echo	Эхо
15	-	netstat	Программа выдачи состояния сети
37	TIME	time	Текущее время
42	NAMESERVER	name	Сервер имен хостов
43	NICNAME	whois	Информация о пользователе
53	DOMAIN	nameserver	Сервер доменных имен (DNS)
67	BOOTPS	bootps	Сервер BOOTP или DHCP
68	BOOTPC	bootpc	Клиент BOOTP или DHCP
69	TFTP	tftp	Простейший протокол передачи файлов (TFTP)
88	KERBEROS	kerberos	Служба аутентификации Kerberos
123	NTP	ntp	Протокол синхронизации сетевого времени (NTP)
161	-	snmp	Простой протокол сетевого управления SNMP)
162	-	snmp-trap	Прерывания протокола SNMP
512	-	biff	Сервер UNIX comsat

18 Протокол межсетевого взаимодействия ip. Структура ip-пакета. Заголовок iPv4, характеристика его полей.

Последняя версия IPv4 - RFC-791 (1981 г.).

Назначение протокола IP

Протокол межсетевого взаимодействия - IP - это ненадежный, не требующий установки соединения с получателем, механизм доставки сообщений в виде отдельных пакетов. "Ненадежность доставки":

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

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

Межсетевая дейтаграмма

Пакет, передаваемый по сети Internet, называют IP-дейтаграммой или IP-пакетом.

Структура пакета: заголовок и блок данных.

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

Формат ip пакета

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

IP-адреса, содержащиеся в заголовке, являются 32-битовыми идентификаторами объектов сети - оконечных установок и маршрутизаторов. Они состоят из идентификаторов сетей и идентификаторов оконечных установок, причем в зависимости от класса сети число бит, выделяемых для идентификации сетей и оконечных установок, может меняться. Предусмотрена также возможность использования групповых адресов. Существуют 5 классов IP-адресов отличающихся количеством бит в сетевом номере и номере оконечной установки (узла). Класс адреса определяется значением его первого октета.

Для устранения из сети пакетов, задержанных вследствие каких-либо причин, в заголовке указывается "время жизни" (TTL - Time To Live), т.е. время, в течение которого пакет должен существовать в сети. Значение этого времени уменьшается при прохождении пакета по сети, а по его истечении пакет уничтожается с уведомлением отправителя. Такая мера защищает сеть от циклических маршрутов и от перегрузок.

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

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

В большинстве типов локальных и глобальных сетей определяется такое понятие как максимальный размер поля данных кадра или пакета, в которые должен инкапсулировать свой пакет протокол IP (MTU). Так, например, сети Ethernet имеют значение MTU, равное 1500 байт, сети FDDI - 4096 байт, а сети Х.25 чаще всего работают с MTU в 128 байт.

Для уменьшения вероятности искажения адресной части пакета и, как результат, отправки его не по адресу (и потере) заголовок пакета препровождается проверочной последовательностью - контрольной суммой (Header Checksum), занимающей 2 байта и рассчитываемой по всему заголовку. В заголовке IP-пакета также указывается протокол транспортного уровня (UDP или TCP), для которого предназначена информация, содержащаяся в поле данных пакета IP.

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

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

Поле "тип сервиса" (Type of Service)

Биты D,T,R - только как рекомендуемые, а не как обязательные для исполнения.

Поле "общая длина" (Total Length) определяет общую длину дейтаграммы в октетах (байтах), включая заголовок и полезную нагрузку.

19 Классовая адресация в ip-сетях (iPv4). Структура адресов. Специальные адреса. Форма представления адреса. Подсети. Выделение идентификаторов сети и подсети.

IP-адрес – это адрес сетевого уровня. IP-адреса представляют собой основной тип адресов, на основании которых сетевой уровень передает пакеты между сетями. Эти адреса состоят из 4 байт, например, 109.26.17.100. IP-адрес назначается администратором во время конфигурирования компьютеров и маршрутизаторов. IP-адрес состоит из двух частей: номера сети и номера узла. Номер узла назначается независимо от локального адреса узла.

Классовая система адресации

Специальные адреса

a)
00000000	00000000		00000000		00000000
Разрешено использовать только в процессе инициализации сетевого программного обеспечения
b)
11111111	11111111		11111111		11111111
Ограниченный широковещательный адрес в своей локальной сети
c)
00000000	Идентификатор узла
00000000	00000000		Идентификатор узла
00000000	00000000		00000000		Идентификатор узла
Компьютер в своей сети
d)
Идентификатор сети	11111111		11111111		11111111
Идентификатор сети		11111111		11111111
Идентификатор сети				11111111
Направленный широковещательный адрес в указанной сети
e)
01111111	Специальные комбинации
Петля обратной связи

Класс сети	Количество сетей	Количество узлов в сети	Диапазон значений первого байта идентификаторов сети
Класс A	126	16 777 214	1-126
Класс B	16384	65 534	128-191
Класс C	2 097 152	254	192-223

Класс D имеет следующую сетку групповых IP-адресов: от 224.0.0.0 до 239.255.255.255.

Назначение идентификаторов сетей

Для подключения сети к Интернет необходимо получить идентификатор сети от Информационного Центра Интернет (InterNIC- Internet NetworkInformation Center). Идентификатор сети должен охватывать все узлы, подключенные к одной физической сети.

Подсети

Традиционная схема деления IP-адреса на номер сети и номер узла основана на понятии класса, который определяется значениями нескольких первых бит адреса. Именно потому, что первый байт адреса 185.23.44.206 попадает в диапазон 128-191, можно сказать, что этот адрес относится к классу B, а значит, номером сети являются первые два байта, дополненные двумя нулевыми байтами – 185.23.0.0, а номером узла – 0.0.44.206. В таком представлении IP-адрес состоит из двух иерархических уровней. Необходимость во введении третьего уровня иерархии – уровня подсетей – была продиктована возникновением дефицита номеров сетей и резким ростом таблиц маршрутизации маршрутизаторов в сети Интернет. После введения уровня подсети номер узла разделяется на две части – номер подсети и номер узла в этой подсети.

Формирование трехуровневой иерархии

Увеличение количества уровней снимает проблему роста таблиц маршрутизации благодаря тому, что информация о топологии частных сетей становится ненужной магистральным маршрутизаторам Интернета. Маршруты из сети Интернет до любой конкретной подсети, расположенной в сети с данным IP-адресом, одинаковы и не зависят от того, в какой подсети расположен получатель. Это стало возможным благодаря тому, что все подсети сети с данным номером используют один и тот же номер сети, хотя их номера (номера подсетей) разные. Маршрутизаторам в частной сети требуется различать отдельные подсети, но для маршрутизаторов Интернета все подсети относятся к единственной записи в таблице маршрутизации. Это позволяет администратору частной сети вносить любые изменения в логическую структуру своей сети, не влияя на размер таблиц маршрутизации маршрутизаторов Интернета.

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

Маски сетей

Маска сети - это 32-разрядная двоичная последовательность,используемая для выделения (маскирования) из IP-адреса его частей: идентификаторов сети и узла. Такая процедура позволяет выяснить, относится ли тот или иной адрес к своей локальной сети.

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

Значение маски сети по умолчанию определяется классом сети.

Класс адресов	Двоичная запись маски сети	Десятичная запись маски сети
Класс A	11111111 00000000 00000000 00000000	255.0.0.0
Kласс B	11111111 11111111 00000000 00000000	255.255.0.0
Класс C	11111111 11111111 11111111 00000000	255.255.255.0

Маски для подсетей, создаваемых в сети класса в

Количество подсетей	Требуемое число бит	Маска подсети	Количество узлов в подсети
2	2	255.255.192.0	16 382
6	3	255.255.224.0	8 190
14	4	255.255.240.0	4 096
30	5	255.255.248.0	2 046
62	6	255.255.252.0	1 022
126	7	255.255.254.0	510
254	8	255.255.255.0

Протоколы разрешения адресов arp и rarp (самостоятельное изучение с учетом лабораторной работы по arp).

ARP (англ. Address Resolution Protocol — протокол определения адреса) — использующийся в компьютерных сетях протокол низкого уровня, предназначенный для определения адреса канального уровня по известному адресу сетевого уровня. Наибольшее распространение этот протокол получил благодаря повсеместности сетей IP, построенных поверх Ethernet, поскольку практически в 100 % случаев при таком сочетании используется ARP.

Существуют следующие типы сообщений ARP: запрос ARP (ARP request) и ответ ARP (ARP reply). Система-отправитель при помощи запроса ARP запрашивает физический адрес системы-получателя. Ответ (физический адрес узла-получателя) приходит в виде ответа ARP.

Перед тем как передать пакет сетевого уровня через сегмент Ethernet, сетевой стек проверяет кэш ARP, чтобы выяснить, не зарегистрирована ли в нём уже нужная информация об узле-получателе. Если такой записи в кэше ARP нет, то выполняется широковещательный запрос ARP. Этот запрос для устройств в сети имеет следующий смысл: «Кто-нибудь знает физический адрес устройства, обладающего следующим IP-адресом?» Когда получатель с этим IP-адресом примет этот пакет, то должен будет ответить: «Да, это мой IP-адрес. Мой физический адрес следующий: …» После этого отправитель обновит свой кэш ARP и будет способен передать информацию получателю. Ниже приведён пример запроса и ответа ARP.

Записи в кэше ARP могут быть статическими и динамическими. Пример, данный выше, описывает динамическую запись кэша. Можно также создавать статические записи в таблице ARP. Это можно сделать при помощи команды:

arp -s <IP-адрес> <MAC-адрес>

Записи в таблице ARP, созданные динамически, остаются в кэше в течение 2-х минут. Если в течение этих двух минут произошла повторная передача данных по этому адресу, то время хранения записи в кэше продлевается ещё на 2 минуты. Эта процедура может повторяться до тех пор, пока запись в кэше просуществует до 10 минут. После этого запись будет удалена из кэша, и будет отправлен повторный запрос ARP.

Принцип работы

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

Преобразование адресов выполняется путем поиска в таблице. Эта таблица, называемая ARP-таблицей, хранится в памяти и содержит строки для каждого узла сети. В двух столбцах содержатся IP- и Ethernet-адреса. Если требуется преобразовать IP-адрес в Ethernet-адрес, то ищется запись с соответствующим IP-адресом. Ниже приведен пример упрощенной ARP-таблицы.

| IP-адрес Ethernet-адрес |

---------------------------------------------

| 223.1.2.1 08:00:39:00:2F:C3 |

| 223.1.2.3 08:00:5A:21:A7:22 |

| 223.1.2.4 08:00:10:99:AC:54 |

---------------------------------------------

RARP (англ. Reverse Address Resolution Protocol — Обратный протокол преобразования адресов) — протокол третьего (сетевого) уровня модели OSI, выполняет обратное отображение адресов, то есть преобразует аппаратный адрес в IP-адрес.

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

RARP позволяет разделять IP-адреса между не часто используемыми хост-узлами. После использования каким либо узлом IP-адреса он может быть освобождён и выдан другому узлу.

RARP является дополнением к ARP, и описан в RFC 903.

RARP отличается от «обратного» ARP (Inverse Address Resolution Protocol, или InARP), описанного в RFC 2390, который предназначен для получения IP-адреса, соответствующего MAC-адресу другого узла. InARP является дополнением к протоколу разрешения адресов и используется для обратного поиска. RARP является скорее аналогом DHCP/BOOTP.

21 Размеры ip-дейтаграмм, mtu. Процедура фрагментации, управление фрагментацией, сборщик фрагментов.

Размер дейтаграммы, MTU и процесс фрагментации. MTU (maximum transfer unit)- максимальная единица данных в сети. IP-пакет: Lmax = 216 - 1=65 535 октетов (байт) Ethernet: MTU = 1500 FDDI: MTU = 4500 Xmodem: MTU = 128

Фрагментация

Части, на которые разделяется дейтаграмма (IP-пакет), называются фрагментами, а сам процесс разделения - фрагментацией.

Рис. 3.4. Фрагментация IP-пакетов при передаче между сетями с разными MTU

Рис. 3.5. Пример выполнения фрагментации в сети

22 Время жизни дейтаграмм (iPv4). Контроль за временем жизни. Механизмы установления времени жизни ip-дейтаграммы.

Для устранения из сети пакетов, задержанных вследствие каких-либо причин, в заголовке в поле Время жизни (TTL - Time To Live) указывается время, в течение которого пакет должен существовать в сети. Значение этого времени уменьшается при прохождении пакета по сети, а по его истечении пакет уничтожается с уведомлением отправителя соответствующим ICMP-сообщеним. Такая мера защищает сеть от циклических маршрутов и от перегрузок.

«Время жизни» задаётся в секундах — максимально 255 секунд (приблизительно 4,3 минуты). Однако часто в этом поле указывается максимальное количество хостов, через которые может пройти дейтаграмма. Это является полезным в том случае, когда задержки в сети имеют достаточно большие значения; тогда даже при суммарной задержке более 255 секунд есть вероятность доставки дейтаграммы получателю, если количество транзитных хостов не превысило максимально допустимое значение, определённое в данном поле.

TTL (время жизни) IP-пакетов

В IPv4 TTL представляет собой восьмиразрядное поле IP-заголовка. Оно находится в девятом октете из двадцати. Значение TTL может рассматриваться как верхняя граница времени существования IP-датаграммы в сети. Поле TTL устанавливается отправителем датаграммы, и уменьшается каждым узлом (например, маршрутизатором) на пути его следования, в соответствии со временем пребывания в данном устройстве или согласно протоколу обработки.

Если поле TTL становится равным нулю до того, как дейтаграмма прибудет в пункт назначения, то такая датаграмма отбрасывается и отправителю отсылается ICMP-пакет с кодом 11 — «Превышение TTL».

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

По стандарту RFC791 время на жизнь измеряется в секундах, но каждый узел, через который проходит датаграмма, должен уменьшить значение TTL по крайней мере на одну единицу. На практике, если обработка занимает меньше секунды, поле TTL уменьшается на единицу на каждом хопе. Для того чтобы отразить это, в протоколе IPv6 поле называют «хоп лимитом». Также в некоторых реализациях IP-протокола TTL измеряется в шагах (хопах), в этом случае каждый маршрутизатор уменьшает значение TTL ровно на единицу.

26 Протокол межсетевых управляющих сообщений icmp. Назначение. Типы сообщений. Механизм передачи icmp-сообщений в сети Internet.

Протокол межсетевых управляющих сообщений ICMP (Internet Control Message Protocol) является обязательным стандартом TCP/IP, описанным в документе RFC 792, «Internet Control Message Protocol (ICMP)». Используя ICMP, узлы и маршрутизаторы, связывающиеся по протоколу IP, могут сообщать об ошибках и обмениваться ограниченной управляющей информацией и сведениями о состоянии.

ICMP-сообщения обычно автоматически отправляются в следующих случаях.

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

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

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

Наиболее часто встречающиеся ICMP-сообщения перечислены и описаны в следующей таблице.

Эхо-запрос (Echo request)

Определяет, доступен ли в сети IP-узел (компьютер или маршрутизатор).

Эхо-ответ (Echo reply)

Отвечает на эхо-запрос ICMP.

Адресат недоступен (Destination unreachable)

Информирует узел о том, что датаграмма не может быть доставлена.

Замедление источника (Source quench)

Требует от узла снизить скорость отправки датаграмм, так как в сети возник затор.

Перенаправление (Redirect)

Информирует узел о наличии лучшего маршрута.

Истечение времени (Time exceeded)

Сообщает, что время жизни IP-датаграммы (TTL) истекло.

Для отправки эхо-запросов ICMP и приема эхо-ответов ICMP можно использовать команду ping. Эти сообщения позволяют выявлять неполадки в работе сетей и узлов, а также устранять другие неполадки TCP/IP-соединений.

Дополнительные сведения о протоколе ICMP см. в документе RFC 792, «Internet Control Message Protocol (ICMP)». Дополнительные сведения о получении документов RFC см. в разделе Документы RFC по TCP/IP.

27 Межсетевой пакетный тестер ping. Целевое назначение. Форматы icmp-сообщений запроса на эхо и ответа на него.

Ping – пакетный тестер IP-сети:

Проверяет достижимость узла + временные метки
Определяет потери до узла

Формат сообщения запроса эха и ответа эха

Рисунок содержит формат сообщений запроса эха и ответа на запрос эха.

0 8 16

--------------------------------------------------------------------------------

|тип(8 или 0)| код(0) | Контрольная сумма |

--------------------------------------------------------------------------------

| идентификатор | последовательный номер |

--------------------------------------------------------------------------------

| необязательные данные |

--------------------------------------------------------------------------------

| ...... |

--------------------------------------------------------------------------------

Рисунок 9.2 Формат сообщения запроса эха и ответа на него

Поле, названное НЕОБЯЗАТЕЛЬНЫЕ ДАННЫЕ имеет переменную длину и содержит данные, которые надо вернуть отправителю. Ответ на эхо всегда возвращает те же самые данные, что были получены им в запросе. Поля ИДЕНТИФИКАТОР и ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР используются отправителем для проверки соответствия ответов запросам. Значение поля ТИП определяет, является ли сообщение запросом(8) или ответом(0).

28 Icmp-сообщение о недостижимости получателя. Формат этого icmp-сообщения

Сообщения о недостижимости назначения

Когда шлюз не может доставить IP-дейтаграмму, он посылает сообщение "назначение недостижимо" обратно первоначальному отправителю, используя формат, приведенный на рисунке 9.3.

0 8 16

----------------------------------------------------------------------

|тип(3) | код(0-5) | Контрольная сумма |

----------------------------------------------------------------------

| не используется(должно быть равно нулю) |

----------------------------------------------------------------------

| межсетевой заголовок плюс первые 64 бита дейтаграммы |

---------------------------------------------------------------------

| ...... |

---------------------------------------------------------------------

Рисунок 9.3 Формат сообщения о недостижимости назначения

Поле КОД в сообщении о недостижимости назначения содержит целое число, которое описывает причину. Возможны следующие значения:

0 Сеть недостижима

1 ГВМ недостижим

2 Протокол недостижим

3 Порт недостижим

4 Требуется фрагментация

5 Ошибка при маршрутизации источника

6 Сеть назначения неизвестна

7 ГВМ назначения неизвестен

8 ГВМ источника изолирован

9 Взаимодействие с сетью назначения административно запрещено

10 Взаимодействие с ГВМ назначения административно запрещено

11 Сеть недостижима из класса обслуживания

12 ГВМ недостижим из-за класса обслуживания

Хотя IP является механизмом ненадежной доставки, дейтаграммы не уничтожаются просто так. Всякий раз, когда ошибка мешает шлюзу произвести маршрутизацию или доставку дейтаграммы, шлюз посылает сообщение о недостижимости назначения обратно его источнику, а затем уничтожает дейтаграмму. Ошибки недостижимости сети обычно являются следствием ошибок маршрутизации; ошибки недостижимости ГВМ - следствие ошибок при доставке(исключением является случай, когда шлюзы используют схему адресации подсетей, описанную в главе 16. Они сообщают об ошибке при маршрутизации к подсети с помощью сообщения ICMP о недостижимости ГВМ). Так как сообщение содержит короткий префикс дейтаграммы, вызвавшей ошибку, то источник будет точно знать, какой адрес недостижим.

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

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

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

29 Icmp-сообщение о подавлении источника данных. Целевое назначение. Формат такого icmp-сообщения. Формат подавления источника

Помимо обычных полей ICMP ТИП, КОД и КОНТРОЛЬНАЯ СУММА, и неиспользуемого 32-битового поля, сообщения о подавлении источника имеют поле, содержащее префикс дейтаграммы. Рисунок 9.4 иллюстрирует этот формат. Как и в других сообщениях об ошибках ICMP поле префикса дейтаграммы содержит префикс дейтаграммы, вызвавшей этот запрос подавления источника.

0 8 16 31

-------------------------------------------------------------------

|тип(4) | код(0) | Контрольная сумма |

-------------------------------------------------------------------

| не используется(должно быть равно нулю) |

-------------------------------------------------------------------

| межсетевой заголовок плюс первые 64 бита дейтаграммы |

-------------------------------------------------------------------

| ...... |

-------------------------------------------------------------------

Рисунок 9.4

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

30 Icmp-сообщения запроса временной метки и ответа на него. Форматы сообщений. Синхронизация часов и оценка времени передачи

Хотя машины в интернете могут взаимодействовать, обычно они работают независимо друг от друга, причем у каждой машины свое понятие о текущем времени. Сильно отличающиеся часы могут смущать пользователей распределенных систем. Стек протоколов TCP/IP включает несколько протоколов, которые могут использоваться для синхронизации часов. Одна из простейших технологий использует сообщения ICMP для получения значения времени от другой машины. Запрашивающая машина посылает сообщение ICMP "запрос временной метки" другой машине, ожидая, что вторая машина вернет ей текущее значение времени. Принимающая машина возвращает "ответ временной метки" машине, выдавшей запрос. Рисунок 9.9 показывает формат сообщений запроса и ответа временной метки.

0 8 16

-----------------------------------------------------------------------

|тип(13, 14) | код(0) | Контрольная сумма |

-----------------------------------------------------------------------

| идентификатор | последовательный номер |

-----------------------------------------------------------------------

| межсетевой заголовок плюс первые 64 бита дейтаграммы |

-----------------------------------------------------------------------

| временная метка отправителя |

-----------------------------------------------------------------------

| временная метка приема |

-----------------------------------------------------------------------

| временная метка передачи |

-----------------------------------------------------------------------

Рисунок 9.9 Формат сообщений ICMP запроса и ответа временной метки

Поле ТИП идентифицирует сообщение как запрос(13) или ответ(14); поля ИДЕНТИФИКАТОР и ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР используются источником для связи между ответами и запросами. Оставшиеся поля специфицируют времена, указанные в миллисекундах после полуночи, по Гринвичу. Поле ВРЕМЕННАЯ МЕТКА ОТПРАВИТЕЛЯ заполняется первоначальным отправителем перед передачей пакета, поле ВРЕМЕННАЯ

МЕТКА ПРИЕМА заполняется сразу после приема запроса, и поле ВРЕМЕННАЯ МЕТКА ПЕРЕДАЧИ заполняется непосредственно перед отправкой ответа.

ГВМ используют эти три поля временных меток для определения ожидаемого времени передачи между ними и синхронизации своих часов. Так как ответ включает поле ВРЕМЕННАЯ МЕТКА ОТПРАВИТЕЛЯ, ГВМ может вычислить общее время, требуемое для передачи запроса к назначению, формирования ответа на него и возвращения ответа. Так как ответ содержит как время прихода запроса на удаленную машину, так и время выдачи ответа, ГВМ может вычислить время передачи по сети, а на его основе - разницу между своими и удаленными часами. На практике бывает трудно точно оценить время передачи по сети, что ограничивает полезность сообщений ICMP о временных метках. Конечно, для получения точной оценки времени передачи по сети нужно сделать много измерений и усреднить их. Тем не менее, время передачи по сети между двумя машинами, присоединенными к большому интернету, может сильно меняться, даже за короткий отрезок времени. Более того, напомним, что так как IP является технологией с негарантированной доставкой, дейтаграммы могут быть потеряны, задержаны или доставлены не по порядку. Поэтому, простые измерения не гарантируют согласованности; требуется сложный статистический анализ для точной оценки.

31 Утилита traceroute. Назначение и принципы работы

Traceroute – анализирует сеть для получения маршрута, по которому пакет добирается от пункта А до В.

Используемый тип 11

Программа Traceroute, написанная Van Jacobson, - отладочное средство, которое позволяет лучше понять устройство протоколов TCP/IP. Обычно две последовательные датаграммы отправленные от одного и того же источника к одному и тому же пункту назначения проходят по одному и тому же маршруту, однако гарантировать

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

Функционирование программы Traceroute

Уже описана IP опция записи маршрута(например, программа ping). Тогда возникает вопрос: «Зачем писать новое приложение?» Есть три причины.

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

Во-вторых, запись маршрута обычно осуществляется в одном направлении. Отправитель включает опцию, а получатель должен вставить все значения из принятого IP заголовка и каким-либо образом вернуть их отправителю. Traceroute требует только того, чтобы на пункте назначения присутствовал работающий UDP модуль – никаких специальных серверных приложений не требуется.
Третья и основная причина заключается в том, что размер, предоставляемый для опций в IP заголовке, недостаточен для того, чтобы обработать большинство маршрутов. В поле опций IP заголовка входит всего 9 IP адресов. На сегодняшний день этого слишком мало. Traceroute использует ICMP и поле TTL в IP заголовке. Поле TTL (время жизни) это 8-битное поле, которое отправитель устанавливает в какое-либо значение. Рекомендуемое исходное значение указано в Assigned Numbers RFC и в настоящее время равно 64. Каждый маршрутизатор, который обрабатывает датаграмму, уменьшает значение TTL на единицу или на количество секунд, в течение которых маршрутизатор обрабатывал датаграмму. Так как большинство маршрутизаторов задерживает датаграмму меньше чем секунду, поле TTL, как правило, уменьшается на единицу и довольно точно соответствует количеству пересылок.

С помощью поля TTL предотвращается зацикливание датаграммы в петлях маршрутизации. Например, если маршрутизатор вышел из строя или соединение между 2 маршрутизаторами потеряно, может потребоваться некоторое время (от нескольких секунд до нескольких минут), для того чтобы определить, что маршрут потерян и что его необходимо обойти. В это время существует вероятность, что датаграмма будет уничтожена в петле маршрутизации. Чтобы предотвратить потерю датаграммы, поле TTL устанавливается в максимальную величину.

Когда маршрутизатор получает IP датаграмму с TTL равным либо 0,либо 1, он не должен отправлять эту датаграмму дальше. (Хостприемник должен доставить подобную датаграмму в приложение, таккак датаграмма не может быть смаршрутизировна. Как правило,системы не должны получать датаграммы с TTL равным 0.) Если такуюдатаграмму получает маршрутизатор, он уничтожает ее и посылаетхосту, который ее отправил ICMP сообщение "время истекло" (time exceeded). Принцип работы Traceroute заключается в том, что IPдатаграмма, содержащая это ICMP сообщение, имеет в качествеадреса источника IP адрес маршрутизатора.

Теперь мы можем понять, как работает Traceroute.

На хост назначения отправляется IP датаграмма с TTL, установленным в единицу. Первый маршрутизатор, который должен обработать датаграмму, уничтожает ее (так как TTL равно 1) и отправляет ICMP сообщение об истечении времени. Таким образом, определяется первый маршрутизатор в маршруте. Затем Traceroute отправляет датаграмму с TTL равным 2, что позволяет получить IP адрес второго маршрутизатора. Это

продолжается до тех пор, пока датаграмма не достигнет хоста назначения. Однако, если датаграмма прибыла именно на хост назначения, он не уничтожит ее и не сгенерирует ICMP сообщение об истечении времени, так как датаграмма достигла своего конечного

назначения. Как можно определить, что датаграмма достигла конечного пункта назначения?

В UDP датаграммах, которые посылает Traceroute, устанавливается несуществующий номер UDP порта (больше чем 30000), что делает невозможным обработку этой датаграммы каким-либо приложением. Поэтому, когда прибывает подобная датаграмма, UDP модуль хоста назначения генерирует ICMP сообщение "порт недоступен" (port unreachable). В этом случае Traceroute необходимо определить тип принятого ICMP сообщения - либо об истечении времени, либо о недоступности порта. Именно таким образом мы узнаем, доставлена ли датаграмма в пункт назначения.

32 Новая версия протокола iPv6. Требования к новой версии. Общая структура дейтаграммы протокола iPv6. Формат основного заголовка дейтаграммы iPv6. Сравнить с заголовком iPv4.

IPv6 – адрес является уникальным 128-битным идентификатором IP-интерфейса в сети Интернет (иногда называют Internet-2).

Основные проблемы протокола IPv4 и пути их решения

1. Быстрое исчерпание адресного пространства.

В настоящее время наблюдается дефицит IP-адресов. Например, очень трудно получить адрес класса B и практически невозможно стать обладателем адреса класса А.

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

Очень часто владельцы сети класса C расходуют лишь небольшую часть из имеющихся у них 254 адресов.

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

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

Рис. 3.17. Пример нерационального использования пространства IP-адресов

Если некоторая IP-сеть создана для работы в «автономном режиме», без связи с Internet, то администратор этой сети может назначить ей произвольно выбранный номер.

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

Адреса, зарезервированные для локальных целей:

в классе A – это сеть 10.0.0.0;

в классе B – это диапазон из 16 номеров сетей 172.16.0.0 - 172.31.0.0;

в классе C – это диапазон из 255 сетей – 192.168.0.0 - 192.168.255.0.

Данная проблема привела к необходимости использования трансляторов сетевых адресов NAT (Network Address Translator), которые отображают несколько частных адресов в один открытый IP-адрес.

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

2. Отсутствие поддержки иерархии.

Вследствие предопределенной внутренней организации классов в протоколе IPv4 отсутствует поддержка подлинной иерархии. Невозможно структурировать IP-адреса таким образом, каким они на самом деле отображаются в топологии сети.

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

3. Сложность настройки сети.

Для использования протокола IPv4 адреса должны присваиваться статически или с помощью таких протоколов конфигурации, как протокол DHCP.

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

4. Отсутствие встроенных систем проверки подлинности и конфиденциальности.

Протокол IPv4 не требует поддержки какого-либо механизма, который при обмене данными обеспечивал бы проверку их подлинности или шифрование.

Для решения отмеченных проблем разработчики стека TCP/IP предлагают разные подходы. Принципиальным решением является переход на протокол – Internet Protocol версии 6 (IPv6).

В июне 1992 года в Кобе (Япония) прошла встреча, на которой были выдвинуты предложения относительно нового IP-протокола. В 1994 году уже можно было говорить о появлении нового протокола IPv6, хотя его окончательная разработка продолжалась и позже. Скачок от версии 4 сразу к версии 6 объясняется тем, что номер "5" был уже занят параллельно разрабатываемым эксперементальным протоколом для передачи данных в реальном времени.

Протокол IPv6 — это новый набор стандартных протоколов для сетевого уровня Интернета. Новый набор протоколов должен удовлетворять следующим основным требованиям.

• Широкомасштабная маршрутизация и адресация с низкими дополнительными издержками.

• Автоконфигурация для разных способов подключения.

• Встроенная система проверки подлинности и конфиденциальности.

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

(В документах рабочей группы IETF по вопросам смены версий протокола IP (Next Generation Transition, NGTRANS) указывается, что IPv4 и IPv6 могут сосуществовать в течение неограниченного времени).

Поэтому способ перехода должен предусматривать сохранение совместимости новых узлов и сетей с доминирующим сейчас в сети протоколом IPv4.

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

Формы представления адресов в iPv6

В протоколе IPv6 адреса имеют длину 128 битов (16-байт).

Рекомендованы три формы для представления адресов.

1. Форма шестнадцатеричных чисел и двоеточий. Эта форма является предпочтительной и имеет вид n:n:n:n:n:n:n:n.

Каждый знак n соответствует 4-х значному шестнадцатеричному числу (всего 8 шестнадцатеричных чисел, для каждого числа отводится 16 бит).

Например: 3FFE:FFFF:7654:FEDA:1245:BA98:3210:4562.

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

Например, адрес групповой рассылки FFED:0:0:0:0:BA98:3210:4562 имеет сжатую форму FFED::BA98:3210:4562. Адрес одноадресной рассылки 3FFE:FFFF:0:0:8:800:20C4:0 в сжатой форме имеет вид: 3FFE:FFFF::8:800:20C4:0. Шлейфовый адрес 0:0:0:0:0:0:0:1 в сжатой форме выглядит так ::1. Неопределенный адрес 0:0:0:0:0:0:0:0 превращается в :: .

3. Смешанная форма. Эта форма представляет собой сочетание адресов протоколов IPv4 и IPv6. В этом случае адрес имеет формат n:n:n:n:n:n:d.d.d.d, где каждый символ n соответствует 4-х значному шестнадцатеричному числу (6 шестнадцатеричных чисел, для каждого числа отводится 16 бит), а d.d.d.d - часть адреса, записанная в формате IPv4 (32 бита).

Типы адресов в iPv6

Конкретный тип адреса протокола IPv6 определяют его начальные биты.

Поле, содержащее эти биты, называется префиксом формата (FP) или адресным префиксом и имеет переменную длину.

Адрес одноадресной рассылки в протоколе IPv6 разделяется на две части. Первая часть содержит адресный префикс, а вторая – идентификатор интерфейса.

Краткий способ представления адреса выглядит следующим образом: ipv6-адрес/длина префикса.

Пример адреса с 64-битным префиксом.

3FFF:FFFF:0:CD30:0:0:0:0/64 .

Префиксом в этом примере является 3FFE:FFFF:0:CD30.

Адрес также может быть записан в сжатой форме, например: 3FFE:FFFF:0:CD30::/64 .

Протокол IPv6 определяет следующие типы адресов.

1. Адрес одноадресной рассылки. Идентификатор в адресе определяет один интерфейс. Пакет, посланный на этот адрес, доставляется по указанному адресу. Адреса одноадресной рассылки отличаются от адресов групповой рассылки значением старшего октета. Старший октет адресов групповой рассылки имеет шестнадцатеричное значение FF. Все остальные значения этого октета определяют адрес одноадресной рассылки.

Рассмотрим различные типы адресов одноадресной рассылки.

• Адреса локальной связи. Эти адреса используются для одной линии связи и имеют формат: FE80::InterfaceID. Адреса локальной связи используются между узлами для автоконфигурации адресов, обнаружения соседа или при отсутствии маршрутизаторов.

Адреса локальной связи используются в основном во время запуска и в случае, если система ещё не получила адреса в большем адресном пространстве.

• Адреса локальных веб-узлов. Эти адреса используются на одном веб-узле и имеют следующий формат: FEC0::SubnetID:InterfaceID.

Адреса локальных веб-узлов используются для адресации внутри узла и не требуют глобального префикса.

• Глобальные адреса одноадресной рассылки протокола IPv6. Эти адреса могут использоваться для связи через Интернет и имеют следующий формат:

010 (FP, 3 бита) TLA ID (13 битов) Резерв (8 битов) NLA ID (24 бита) SLA ID (16 битов) InterfaceID (64 бита).

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

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

Адреса для всех типов рассылок получаются из пространства адресов одноадресной рассылки и синтаксически не отличаются друг от друга. Для адресуемого интерфейса разница между адресом для всех типов рассылок и адресом одноадресной рассылки определяется во время конфигурации.

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

Одноадресатный (unicast) Определяет одного получателя в сети (компьютер или маршрутизатор). Дейтаграмма должна передаваться к месту назначения по кратчайшему маршруту

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

Многоадресатный (multicast) Определяет группу компьютеров, возможно, расположенных в различных местах объединенной сети. Дейтаграмма, посланная по многоадресатному адресу, будет доставлена каждому члену группы. При этом используется многоадресатный или широковещательный режим передачи сетевого оборудования (если, конечно, он поддерживается)

Общая структура дейтаграммы протокола IPv6 и форматы основного и дополнительных заголовков

Общая структура дейтаграммы протокола IPv6 с несколькими заголовками. Обязательным является присутствие только основного заголовка; дополнительные заголовки могут быть опущены

Формат 40-октетного основного заголовка, расположенного в начале каждой дейтаграммы протокола IPv6

Формат заголовка IPv4

Общие недостатки протокола IPv4:

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

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

1)Основной

Заголовок

След. = маршрутный

2)Маршрутный

заголовок

След.= Аутентификация

3)Заголовок

аутентификации

След .= TCP-сегмент

4)TCP-сегмент

Формат с основным и двумя дополнительными заголовками

Формат дополнительного заголовка фрагментации

Формат маршрутного заголовка протокола IPv6. В настоящее время определён только тип 0 (неточная маршрутизация от источника)

34 Адресация в iPv6. Сопряжение версий iPv4 и iPv6. Взаимодействие систем, работающих с разными стеками протоколов

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

трансляция;
мультиплексирование;
инкапсуляция (туннелирование).

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

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

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

В процессе инкапсуляции принимают участие три типа протоколов:

транспортируемый протокол;
несущий протокол;
протокол инкапсуляции.

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

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

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

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

Кодирование адресов IPv4 в протоколе IPv6. В 16-битовом поле содержится 0000, если узел имеет также одноадресатный адрес IPv6, и FFFF – в противном случае

Метод двойного стека

Туннелирование

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

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

Минимальное значение максимального размера пакета, который может быть отправлен через интерфейс (Maximum Transmission Unit, MTU) для IPv6 составляет 1280 байт. Для того чтобы избежать излишней фрагментации, инкапсулирующая система должна, по возможности, использовать такое значение MTU для пакета IPv6, чтобы он помещался вместе со своим заголовком в разрешенном значении MTU для IPv4. Если размер присылаемого пакета IPv6 не позволяет разместить его целиком в поле данных пакета IPv4, инкапсулирующий узел может отправить узлу-источнику трафика IPv6 управляющее сообщение ICMPv6. При передаче трафика IPv6 через туннель в сети IPv4 протокол IPv4 играет роль канальной среды, поэтому, когда пакет проходит через туннель, счетчик транзитных узлов маршрута (hop counter) уменьшается на 1. Это делает туннель прозрачным на уровне IPv6

35 Протокол rtp и его характеристика. Формат заголовка, назначение полей. Протокол rtp. Организация передачи трафика реального времени по сети Интернет. Мультимедиа

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

Протокол передачи видео- и аудиоинформации в реальном масштабе времени — RTP

Почему нужен rtp

В Интернет возможна потеря пакетов, изменение их порядка в процессе транспортировки, а также вариация времени доставки в достаточно широких пределах.

В приложениях реального времени (аудио- и видеоконференции, живое видео, удаленная диагностика в медицине, компьютерная телефония, игры, мониторинг в реальном времени и др.) отправитель генерирует поток данных с постоянной скоростью, а получатель (или получатели) должен предоставить эти данные приложению с той же самой скоростью.

Протокол транспортного уровня — TCP не подходит для приложений реального времени:

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

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

TCP не имеет удобного механизма привязки информации о синхронизации к сегментам.

Для согласования требований приложений реального времени с возможностями Интернет был разработан транспортный протокол реального времени — RTP (Real-Time Transport Protocol).

Протокол RTP (RFC 1889 — A Transport Protocol for Real-Time Applications” H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson) обеспечивает в IP-сетях доставку адресатам аудио- и видеопотоков в масштабе реального времени. Согласно стеку рекомендаций H.323, в сетях с негарантированной полосой пропускания с целью минимизации задержек и максимального использования имеющейся полосы пропускания для передачи аудио- и видеопотоков, а также сигнализации RAS применяется протокол User Datagram Protocol (UDP). Этот протокол задействует механизм многоадресной рассылки (IP Multicast) для негарантированной доставки звука и видео определенному числу пользователей. Поверх IP Multicast работает RTP, который создает необходимые условия для нормального воспроизведения полученных потоков на абонентских терминалах.

Принципы построения протокола rtp

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

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

Реализацию функций RTP контролирует транспортный протокол управления передачей в режиме реального времени RTCP — Real-time Transport Control Protocol (RFC 1889). Он также отслеживает качество обслуживания и снабжает соответствующей информацией участников конференции. RTCP использует тот же самый базовый транспортный протокол, что и RTP (обычно UDP), но другой номер порта.

RTP работает поверх UDP и может поддерживать передачу данных в реальном времени между несколькими участниками RTP-сеанса.

RTCP выполняет несколько функций:

Обеспечение и контроль качества услуг и обратная связь в случае перегрузки. Так как RTCP-пакеты являются многоадресными, все участники сеанса могут оценить, насколько хороши работа и прием других участников. Сообщения отправителя позволяют получателям оценить скорость данных и качество передачи. Сообщения получателей содержат информацию о проблемах, с которыми они сталкиваются, включая утерю пакетов и избыточную неравномерность передачи. Обратная связь с получателями важна также для диагностирования ошибок при распространении. Анализируя сообщения всех участников сеанса, администратор сети может определить, касается данная проблема одного участника или носит общий характер. Если приложение-отправитель приходит к выводу, что проблема характерна для системы в целом, например, по причине отказа одного из каналов связи, то оно может увеличить степень сжатия данных за счет снижения качества или вообще отказаться от передачи видео — это позволяет передавать данные по соединению низкой емкости.
Идентификация отправителя. Пакеты RTCP содержат стандартное текстовое описание отправителя. Они предоставляют больше информации об отправителе пакетов данных, чем случайным образом выбранный идентификатор источника синхронизации. Кроме того, они помогают пользователю идентифицировать потоки, относящиеся к различным сеансам.
Оценка размеров сеанса и масштабирование. Для обеспечения качества услуг и обратной связи с целью управления загруженностью, а также с целью идентификации отправителя, все участники периодически посылают пакеты RTCP. Частота передачи этих пакетов снижается с ростом числа участников. При небольшом числе участников один пакет RTCP посылается максимум каждые 5 секунд. RFC 1889 описывает алгоритм, согласно которому участники ограничивают частоту RTCP-пакетов в зависимости от общего числа участников. Цель состоит в том, чтобы трафик RTCP не превышал 5% от общего трафика сеанса.

При организации видеоконференции каждый участник должен иметь IP-адрес и две пары UDP-портов: для RTP и RTCP, так как звук и изображение передаются как два независимых потока. RTCP-пакеты посылаются независимо для каждой из этих двух сессий.

На уровне RTP не существует какой-либо взаимосвязи между аудио- и видео сессиями. Только RTCP-пакеты несут в себе одни и те же имена участников.

Определения

Пакет RTP. Информационный пакет, содержащий фиксированный заголовок. Один пакет транспортного нижнего уровня, например UDP, обычно содержит один RTP-пакет.

Поле данных RTP. Информация, пересылаемая в пакете RTP, например, фрагменты звука или сжатые видео данные.

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

Транспортный адрес. Комбинация сетевого адреса и порта, которая идентифицирует конечную точку канала (например, IP-адрес и UDP-порт). Пакеты следуют от транспортного адреса отправителя к транспортному адресу получателя.

Сессия RTP. Период с момента установления группой участников RTP-обмена до его окончания.

Источник синхронизации (SSRC - Synchronization SouRCe). Источник потока RTP-пакетов, определяется 32-битным числовым SSRC-идентификатором, который записывается в заголовок RTP-пакета и не зависит от сетевого адреса. Все пакеты от источника синхронизации содержат временную привязку и нумерацию. Эти данные используются принимающей стороной при воспроизведении. Источниками синхронизации могут служить источники первичного сигнала (микрофоны или видеокамеры), а также RTP-смесители. SSRC-идентификатор представляет собой случайное число, которое является уникальным для данной RTP-сессии. Если формируется несколько потоков в рамках одной RTP-сессии (например, от нескольких видеокамер), то каждый поток должен быть снабжен уникальным SSRC-идентификатором.

Информационный источник (CSRC - Contributing SouRCe). Источник потока RTP-пакетов, который вносит вклад в общий поток, формируемый RTP-смесителем. Смеситель вставляет список SSRC-идентификаторов, которые идентифицируют отдельные источники, в заголовок RTP-пакетов. Этот список называется CSRC-списком. Примером приложения может быть аудио-конференция, где смеситель отмечает всех говорящих, чей голос порождает исходящие пакеты. Это позволяет принимающей стороне идентифицировать говорящего, хотя все пакеты имеют один и тот же SSRC-идентификатор.

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

Кроме оконечных систем RTP поддерживает трансляторы и смесители, которые рассматриваются как промежуточные системы на уровне RTP.

Смеситель. Промежуточная система, которая получает RTP-пакеты от одного или нескольких источников, при необходимости меняет их формат, объединяет и пересылает их адресатам. Например, смеситель преобразует поток аудио-пакетов в последовательность пакетов, которая соответствует возможностям узкополосного канала. Так как временная привязка входных пакетов может отличаться, смеситель осуществляет их синхронизацию и генерирует свой собственный поток RTP-пакетов. Таким образом, все посылаемые пакеты имеют в качестве источника синхронизации смеситель.

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

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

Заголовок пакета rtp

Первые 12 октетов присутствуют во всех RTP-пакетах. Список CSRC-идентификаторов присутствует только тогда, когда пакет формируется смесителем.

V (2 бита) - поле версии протокола RTP. Текущая версия — вторая.

P (1 бит) - поле заполнения. Если Р=1, пакет содержит один или более дополнительных октетов-заполнителей в конце поля данных (заполнители не являются частью поля данных). Последний октет заполнителя содержит число октетов, которые должны игнорироваться. Заполнитель нужен при использовании некоторых алгоритмов шифрования при фиксированном размере блоков или при укладке нескольких RTP-пакетов в один UDP.

X(1 бит) поле расширения заголовка. Если Х=1, то за основным заголовком следует еще один дополнительный, используемый в экспериментальных расширениях RTP.

CC (CSRC count – число CSRC, 4 бита). Это поле содержит количество идентификаторов отправителей, чьи данные находятся в пакете, причем сами идентификаторы следуют за основным заголовком.

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

PT (7 битов) - поле типа полезной нагрузки. Идентифицирует тип полезной нагрузки и формат данных RTP-пакета, включая сжатие и шифрование данных и определяет интерпретацию поля данных приложением.

Порядковый номер пакета (Sequence Number, 16 битов). Каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым посланным пакетом данных RTP. Это позволяет обнаружить потерю пакетов и определить порядок пакетов с одинаковой отметкой о времени. Несколько последовательных пакетов могут иметь одну и ту же отметку о времени, если логически они порождены в один и тот же момент, как, например, пакеты, принадлежащие к одному и тому же видеокадру.

Временная метка (Timestamp, 32 бита). Поле отметки о времени. Это поле содержит момент времени, в который первый октет данных полезной нагрузки был создан. Единицы, в которых время указывается в этом поле, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя. Начальное значение временной метки является случайным. Несколько последовательных RTP-пакетов могут иметь идентичные временные метки, если логически они генерируются одновременно (например, относятся к одному и тому же видеокадру).

SSRC (Synchronization Source Identifier, 32 бита). Поле SSRC идентифицирует источник синхронизации. Этот идентификатор выбирается случайным образом, так чтобы в пределах одной RTP-сессии не было двух равных SSRC-кодов, и не зависит от сетевого адреса. Все приложения должны быть способны выявлять случаи равенства SSRC-кодов. Если отправитель изменяет свой транспортный адрес, он должен также сменить и SSRC-идентификатор.

CSRC-список (Contributing source Identifier, 32 бита). Список полей идентификаторов источников, "подмешанных" в основной поток, например, с помощью смесителя. Количество элементов в списке: от 0 до 15. Число идентификаторов задается полем CC. Примером может служить аудио-конференция, в RTP-пакеты которой собраны речи всех участников, каждый со своим CSRC — они-то и образуют список CSRC. При этом вся конференция имеет общий SSRC.

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

Протокол RTCP, как и всякий управляющий протокол, значительно сложнее и по структуре, и по выполняемым функциям. Хотя основу протокола RTCP составляет RTP, он содержит множество дополнительных полей, с помощью которых он реализует свои функции.

36 Межсетевое взаимодействие в Internet. Маршрутизаторы и их функции. Внутренняя и внешняя маршрутизация. Пример продвижения IP-дейтаграмм по сети Internet через различные подсети. По какому признаку находится в сети нужный маршрутизатор. Принцип “Hop-by-Hop”.

Проблема маршрутизации в сети Internet

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

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

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

алгоритм маршрутизации должен распознавать отказ и восстановление каналов связи или других IP-маршрутизаторов и переключаться на другие, подходящие маршруты. Время переключения маршрутов должно быть меньшим, чем типичный тайм-аут пользователя протокола ТСР (примерно 1 мин);
алгоритм должен исключать образование циклов, петель и эффекта «пинг-понг» в назначаемых маршрутах как между соседними IP – маршрутизаторами, так и для удалённых IP – маршрутизаторов. Существование вышеперечисленных эффектов не должно превышать типичного тайм-аута пользователя протокола TCP (примерно 1 минута);
нагрузка, создаваемая управляющими сообщениями, которые необходимы для работы алгоритма маршрутизации, не должна ощутимо ухудшать или нарушать нормальную работу сети. Изменение состояния сети, которое может прервать нормальную работу в некоторой локальной области сети, не должно оказывать воздействия на удалённые участки;
поскольку размеры сети постоянно увеличиваются, необходимо обеспечить эффективное использование сетевых ресурсов, например, изменение матриц маршрутов выполнять по частям, передавая по глобальным сетям только дополнения к базам данных по маршрутизации;
размер базы данных по маршрутизации не должен превышать некоторой константы, не зависящей от топологии сети, умноженной на количество узлов и на среднюю связность сети. Хорошая реализация не должна требовать хранения полной базы данных по маршрутизации в каждом IP - маршрутизаторе;
если используются метрики, основанные на достижимости узла и задержке в доставке пакета, то они не должны зависеть от прямой связности со всеми другими IP-маршрутизаторами или от использования механизмов широковещательной передачи, специфичных для некоторых сетей. Процедуры опроса не должны вносить существенных дополнительных расходов;
маршруты по умолчанию следует использовать в качестве первоначальных предположений о маршрутизации, чтобы затем выбирать окончательное направление передачи.

Кроме перечисленных выше задач IP-маршрутизатор должен обеспечивать эффективное распределение собственных ресурсов как по пропускной способности каналов, так и по объёму буферных ЗУ, используемых для хранения пакетов, ожидающих передачу. Самая очевидная стратегия «первым пришёл — первым обслужен» (FCFS — First Come First Served) может оказаться неприемлемой в условиях перегрузки сети.

Так, например, нельзя допустить, чтобы высокоскоростной канал захватил весь объём буферных ЗУ, ничего не оставив низкоскоростному каналу. В хороших алгоритмах обязательно должно учитываться поле «тип услуг» заголовка IP-пакета; IP-маршрутизатор может назначить больший приоритет IP-пакетам, передающим управляющую или служебную информацию.

Наконец, алгоритм маршрутизации должен обеспечивать надёжный алгоритм определения состояния каждого канала связи и узла в базовой сети и, если требуется, состояние хост-ЭВМ. Для этого нужен, по крайней мере, протокол канального уровня, предполагающий периодический обмен кадрами через каждый канал связи. Однако этого часто оказывается недостаточно, поэтому дополнительно требуется специальный механизм в алгоритмах маршрутизации. По техническим, административным, географическим, а также иногда и политическим соображениям IP-маршрутизаторы группируются в так называемые «автономные системы». IP-маршрутизаторы, входящие в одну автономную систему, контролируются одной организацией, обеспечивающей их сопровождение, и используют общие для данной автономной системы алгоритмы маршрутизации.

Существуют статические и динамические алгоритмы обновления таблицы.

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

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

Шлюзы, работающие по алгоритму Беллмана-Форда, хранят вектор длин кратчайших маршрутов до всех сетей, входящих в состав объединённой сети. Периодически каждый шлюз передаёт свой вектор соседним шлюзам автономной системы, а элементы вектора, принятого от соседнего шлюза, складываются с длинами исходящих линий связи. На основе полученной таблицы строится новый вектор длин кратчайших маршрутов — алгоритм Беллмана-Форда (DV — алгоритм Distance Vector). Протоколы на основе DV-алгоритма достаточно просто реализуются, требуют мало памяти и процессорного времени, однако они обладают рядом общих недостатков. При увеличении количества сетей, входящих в состав автономной системы, резко возрастает количество передаваемой информации, т.к. DV-алгоритм требует, чтобы все шлюзы периодически передавали свои векторы длин маршрутов.

Пары - (V,D) V -вектор (определяет получателя); D - дистанция (расстояние)

Шлюзы, работающие по алгоритму Дейкстры (Shortest Path First — SPF-алгоритм), сначала определяют кратчайшие маршруты по всем сетям автономной системы. Для этого в каждом шлюзе строится полное дерево кратчайших путей с корнем в данном шлюзе. Процедура построения дерева кратчайших путей использует принцип, согласно которому в дерево кратчайших путей первой включается дуга с наименьшей длиной, поэтому алгоритм Дейкстры часто называют первым кратчайшим путем. После того как в шлюзе построено дерево кратчайших путей, изменения характеристик линий связи, определяющих длины соответствующих дуг графа, изменения топологии сети приводят к небольшим дополнительным вычислениям для корректирования дерева кратчайших путей. Шлюзы обмениваются только сведениями о длинах исходящих линий связи, а не векторами длин маршрутов, как в случае алгоритма Беллмана-Форда. Размер корректирующих пакетов со служебной информацией для маршрутизации мал и не зависит от числа сетей в автономной системе. Каждый шлюз посылает такие пакеты с помощью лавинной маршрутизации. При появлении в сети нового шлюза или включении новой линии связи изменения в топологии сети не учитываются при маршрутизации в течение некоторого времени для того, чтобы информация о происшедших изменениях успела достигнуть всех шлюзов автономной системы.

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

Архитектура маршрутизатора

Обработка на входном порту

Три метода коммутации

Память

Матричный коммутатор

Шина

Обработка данных на выходном порту

Функциональная модель маршрутизатора

37 Принципы статической и динамической маршрутизации. Формирование маршрутных таблиц, их содержание. Понятие об алгоритмах Беллмана–Форда и Дийкстра.

Существуют статические и динамические алгоритмы обновления таблицы.

Пары - (V,D) V -вектор (определяет получателя); D - дистанция (расстояние)

38 Протоколы внутренней маршрутизации rip1, rip2. Форматы сообщений. Недостатки. Взаимодействие с транспортными протоколами.

Внутренние протоколы маршрутизации

Протокол GGP (Gateway to Gateway Protocol, RFC 823) был разработан и реализован фирмой BBN для первых экспериментальных шлюзов сети Internet. Он до сих пор используется в шлюзах фирмы BBN LSI/11, хотя считается, что GGP имеет серьёзные недостатки и позднее был заменён на алгоритм SPF. Алгоритм протокола GGP определяет маршрут с минимальным числом переприёмов, т.е. его мерой длины является просто число транзитных участков сети между парами шлюзов. Он реализует распределённый алгоритм кратчайшего пути, который требует глобальной сходимости маршрутных таблиц после изменений в топологии или связности.

Протокол RIP (Routing Information Protocol, RFC 1058, 1581, 1582, 1724) часто используется для класса протоколов маршрутизации, базирующихся на протоколах XNS (Xerox Network System — сетевая система Xerox) фирмы Xerox. Реализация протокола RIP для семейства протоколов TCP/IP широко доступна, поскольку входит в состав программного обеспечения ОС UNIX, например, FreeBSD или Linux. В силу своей простоты протокол RIP имеет наибольшие шансы превратиться в «открытый» протокол IGP, т.е. протокол, который может использоваться для совместной работы шлюзов, поставляемых разными фирмами. При использовании протокола RIP работает алгоритм динамического программирования Беллмана-Форда. В качестве метрики маршрутизации RIP использует число скачков (шагов) до цели. Такой вид метрики не учитывает различий в пропускной способности или загруженности отдельных сегментов сети. Каждому маршруту ставится в соответствие таймер тайм-аута и «сборщик мусора». Таймер тайм-аута сбрасывается каждый раз, когда маршрут инициализируется или корректируется. Если со времени последней коррекции прошло 3 минуты или получено сообщение в том, что вектор расстояния равен 16, маршрут считается закрытым, но запись о нём не стирается, пока не истечёт время «уборки мусора» (2 минуты). При появлении эквивалентного маршрута переключение на него не происходит. Протокол RIP достаточно простой, но не лишённый недостатков:

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

Случай неустойчивой работы сети по протоколу RIP при изменении конфигурации - отказе линии связи маршрутизатора M1 с сетью 1. При работоспособном состоянии этой связи в таблице маршрутов каждого маршрутизатора есть запись о сети с номером 1 и соответствующим расстоянием до нее:

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

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

Формат сообщения протокола rip 1

1 - запрос на частичную или полную маршрутную информацию;

2 - ответ на запрос, содержащий пары чисел (адрес сети, расстояние), взятые из таблицы маршрутизации отправителя;

9 - запрос на обновление;

10 - ответ на запрос на обновление

Формат сообщения протокола rip 2

39 Протокол внутренней маршрутизации ospf. Формат ospf–сообщений. Механизм рассылки маршрутной информации.

Протокол OSPF (Open Shortest Path First, RFC 1850, 1583, 1584, 1587) представляет собой протокол состояния маршрута, причём в качестве метрики используется коэффициент качества обслуживания. Каждый маршрутизатор обладает полной информацией о состоянии всех интерфейсов шлюзов автономной системы. Определяющими являются три характеристики: задержка, пропускная способность и надёжность. Преимущества OSPF:

для каждого адреса может быть несколько маршрутных таблиц, по одной на каждый вид IP-операции;
каждому интерфейсу присваивается безразмерная цена, учитывающая пропускную способность, время транспортировки сообщения; каждой IP-операции может быть присвоена своя цена;
при существовании эквивалентных маршрутов OSPF распределяет поток равномерно по этим маршрутам;
при связи «точка–точка» не требуется IP-адрес для каждого из концов;
применяется мультикастинг вместо широковещательной адресации, что снижает загрузку не вовлечённых в обмен сегментов.

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

Иерархически структурированная автономная сеть OSPF с четырьмя областями

Непосредственно связанные (то есть достижимые без использования промежуточных маршрутизаторов) маршрутизаторы называются "соседями". Каждый маршрутизатор хранит информацию о том, в каком состоянии по его мнению находится сосед. Маршрутизатор полагается на соседние маршрутизаторы и передает им пакеты данных только в том случае, если он уверен, что они полностью работоспособны. Для выяснения состояния связей маршрутизаторы-соседи достаточно часто обмениваются короткими сообщениями HELLO.

Для распространения по сети данных о состоянии связей маршрутизаторы обмениваются сообщениями другого типа. Эти сообщения называются router links advertisement - объявление о связях маршрутизатора (точнее, о состоянии связей). OSPF-маршрутизаторы обмениваются не только своими, но и чужими объявлениями о связях, получая в конце-концов информацию о состоянии всех связей сети. Эта информация и образует граф связей сети, который, естественно, один и тот же для всех маршрутизаторов сети.

Кроме информации о соседях, маршрутизатор в своем объявлении перечисляет IP-подсети, с которыми он связан непосредственно, поэтому после получения информации о графе связей сети, вычисление маршрута до каждой сети производится непосредственно по этому графу по алгоритму Дэйкстры. Более точно, маршрутизатор вычисляет путь не до конкретной сети, а до маршрутизатора, к которому эта сеть подключена. Каждый маршрутизатор имеет уникальный идентификатор, который передается в объявлении о состояниях связей. Такой подход дает возможность не тратить IP-адреса на связи типа "точка-точка" между маршрутизаторами, к которым не подключены рабочие станции.

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

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

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

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

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

В протоколе OSPF используется несколько временных параметров, и среди них наиболее важными являются интервал сообщения HELLO и интервал отказа маршрутизатора (router dead interval).

Формат сообщения

Типы OSPF-сообщений:

1 - сообщение HELLO (используется для проверки достижимости);

2 - описание базы данных (топология);

3 - запрос о состоянии соединения;

4 - обновление состояния соединения;

5 - уведомление о состоянии соединения

Формат сообщения HELLO протокола OSPF

40 Протокол внешней маршрутизации bgp и его функции. Виды bgp-сообщений. Механизм распространения маршрутной информации.

Протокол BGP (Border Gateway Protocol, RFC 1267) — это протокол маршрутизации между автономными системами в сети Internet; он построен на основе опыта, накопленного при эксплуатации протокола EGP. Главная цель BGP — сократить транзитный трафик. Протокол BGP использует расширенное понятие автономной системы. В данном случае внутри автономной системы шлюзы могут использовать несколько различных протоколов маршрутизации и несколько метрик. Однако внутри автономной системы должен существовать единый план маршрутизации, позволяющий рассматривать автономную систему как единое целое.

В зависимости от того, с каким трафиком имеет дело автономная система, она причисляется к одной из следующих категорий:

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

Протокол BGP использует в качестве транспортного протокола протокол ТСР. Хост-ЭВМ, выполняющие протокол BGP, не обязательно должны одновременно являться шлюзами. Хост-ЭВМ, не являющаяся шлюзом, может обмениваться маршрутной информацией со шлюзами при помощи протокола EGP или внутреннего протокола маршрутизации. Эта хост-ЭВМ может затем использовать протокол BGP для обмена маршрутной информацией с граничным шлюзом другой автономной системы.

Формат bgp-сообщения об обновлении

Формат bgp-сообщения об открытии bgp-соединения

Поддержка бесклассовой адресации

Сжатый формат, используемый в протоколе BGP для хранения адреса получателя и соответствующей ему маски

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

BGP, в отличие от предшествующих протоколов маршрутизации, которые взаимодействуют напрямую с протоколом IP, работает поверх протокола транспортного уровня. Например, при работе поверх TCP BGP использует порт 179. Это позволяет не нагружать сервисы обработки протокола BGP механизмами фрагментации или обеспечения достоверности доставки пакетов. Схемы аутентификации протоколов транспортного уровня также могут быть использованы BGP в дополнение к собственной системе аутентификации. Кроме того, хотя BGP разработан как протокол маршрутизации между AS, он может использоваться для маршрутизации и внутри AS.

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

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

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

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

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

Открывающие сообщения (open message). После того, как организовано соединение протокола транспортного уровня, первым сообщением, отправляемым каждой стороной, является открывающее сообщение. Пакет открывающего сообщения содержит, в дополнение к основному заголовку BGP (рис. 4), несколько дополнительных параметров. Параметр версия (version) — номер версии BGP дает возможность получателю проверять, совпадает ли его версия с версией отправителя. Параметр автономная система (autonomous system) содержит номер AS отправителя. Параметр время удерживания (hold time) указывает максимальное число секунд, которые могут пройти без получения какого-либо сообщения от передающего устройства, прежде чем считать его отказавшим. Параметр код аутентификации (authentication code) указывает на используемый код удостоверения, если, конечно, таковой имеется- Параметр данных аутентификации (authentication data) содержит возможные данные аутентификации.

Сообщения о корректировке (update message). Сообщения о корректировках BGP обеспечивают корректировки маршрутизации для других систем BGP. Информация этих сообщений используется для построения графа, описывающего взаимоотношения между различными AS.

Источник (origin). Может иметь одно из трех значений: 1GP, EGP и incomplete (незавершенный). Атрибут 1GP означает, что данная сеть является частью данной AS. Атрибут EGP означает, что первоначальные сведения о данной информации получены от протокола EGP. Реализации BGP склонны отдавать предпочтение маршрутам 1GP перед маршрутами EGP, так как маршрут EGP отказывает при наличии маршрутных петель. Атрибут incomplete используется для указания того, что о данной сети известно через какие-то другие средства.

Путь (path). Путь AS. Обеспечивает фактический перечень AS на пути к пункту назначения.

Следующая пересылка (next hop). Содержит адрес IP-роутера, который должен быть использован в качестве следующей пересылки к сетям, перечисленным в сообщении о корректировке.

Недосягаемый (unreachable). Указывает, что какой-нибудь маршрут больше не является досягаемым.

Показатель оптимальности маршрута между AS (inter-AS metric). Обеспечивает для какого-нибудь роутера BGP возможность тиражировать свои затраты на маршруты к пунктам назначения, находящимся в пределах его AS. Эта информация может быть использована роутерами, которые являются внешними по отношению к AS тиражирующего роутера, для выбора оптимального маршрута к конкретному пункту назначения, находящемуся в пределах данной AS.

Сообщения "продолжай действовать" (keepalive message). Эти сообщения не содержат каких-либо дополнительных полей помимо тех, которые содержатся в заголовке BGP.

Уведомления об ошибках (error message). Уведомления отправляются в том случае, если была обнаружена сбойная ситуация и один роутер хочет сообщить другому, почему он закрывает соединение между ними. В сообщении содержится код ошибки (error code), подкод ошибки (error subcode) и данные ошибки (error data).

41 Механизмы открытия bgp–соединения, обновления маршрутной информации. Взаимодействие с транспортными протоколами. Передача bgp-сообщений в сетях с бесклассовой адресацией

Формат BGP-сообщения об обновлении

Формат BGP-сообщения об открытии BGP-соединения

Поддержка бесклассовой адресации

Сжатый формат, используемый в протоколе BGP для хранения адреса получателя и соответствующей ему маски

42 Групповая рассылка пакетов в сети Интернет. Протокол групповой маршрутизации igmPv2. Формат igmp-сообщений. Механизм переноса igmp-сообщений.

Способы групповой рассылки

Алгоритмы групповой маршрутизации

Иллюстрация проблемы групповой маршрутизации

Два подхода в построении дерева:

общее дерево;
дерево для каждого из отправителей в отдельности.

Групповая маршрутизация с общим деревом

Единое общее дерево

Дерево наименьшей стоимости для группы

Формирование дерева с центральным узлом

Условные обозначения:

Путь и порядок, в котором генерируются сообщения

Групповая маршрутизация с деревом у каждого отправителя

Алгоритм продвижения данных по обратным маршрутам(RPF - Reverse Path Forwarding)

Условные обозначения:

	Пакет пересылается дальше
	Пакет дальше не пересылается

Для отправителя S строится дерево для каждого из представителей этой группы Отправляется групповая дейтаграмма, каждый маршрутизатор, получивший это сообщение отправит его своим соседям. Маршрутизатор либо отправляет дальше, либо - нет (отправляет дальше в том случае, если информация поступила по кратчайшему пути.)

Межсетевой протокол управления группами igmp (Internet Group Management Protocol)rfc 2236, версия 2

Две составляющие групповой рассылки сетевого уровня: протокол igmp и протоколы групповой маршрутизации

Формат IGMP-сообщения:

Типы сообщений протокола IGMP

Тип	Адрес группы	Описание
0x11	Отсутствует (ноль)	Запрос о членах всех групп
0x11	Используется	Запрос о членах определенной группы
0x16	Используется	Отчет о членах группы
0x17	Используется	Отключение от группы

Протоколы групповой рассылки:

дистанционно-векторный протокол многоадресатной маршрутизации DVMRP;
многоадресатное расширение протоколаOSPF (MOSPF);

Туннели для групповой рассылки Физическая топология

A, B, C - поддерживают групповую топологию. Остальные работают в режиме транзита (туннель)

Логическая топология

43 Абонентский доступ к сети Internet. Протоколы slip и ppp. Сравнение (самостоятельное изучение)

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

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

SLIP (Serial Line Internet Protocol) — устаревший сетевой протокол канального уровня эталонной сетевой модели OSI для доступа к сетям стека TCP/IP через низкоскоростные линии связи путём простой инкапсуляции IP-пакетов. Используются коммутируемые соединения через последовательные порты для соединений клиент-сервер типа точка-точка. В настоящее время вместо него используют более совершенный протокол PPP.

Принципы работы

Для установления связи необходимо заранее задать IP-адреса, так как в протоколе SLIP нет системы обмена адресной информацией.
В принимаемом потоке бит SLIP позволяет определить признаки начала и конца пакета IP. По этим признакам SLIP собирает полноценные пакеты IP и передаёт верхнему уровню. При отправлении IP-пакетов происходит обратная операция — они переформатируются и посимвольно отправляются получателю через последовательную линию.
Для передачи необходимо использовать конкретную конфигурацию UART: 8 бит данных (8 data bits), без паритета (no parity), аппаратное управление каналом передачи (EIA hardware flow control) или трёхпроводный нуль-модемный кабель(3-wire null-modem — CLOCAL mode).

Недостатки

Нет возможности обмениваться адресной информацией — необходимость предустановки IP-адресов.
Отсутствие индикации типа инкапсулируемого протокола — возможно использование только IP.
Не предусмотрена коррекция ошибок — необходимо выполнять на верхних уровнях, рекомендуется использовать протокол TCP.
Высокая избыточность — из-за использования стартовых и стоповых битов при асинхронной передаче (+20 %), передачи в каждом SLIP-кадре полного IP-заголовка (+20 байт) и полных заголовков верхних уровней, байт-стаффинга.
В некоторых реализациях протокола максимальный размер кадра ограничен 1006 байтами для достижения обратной совместимости с реализацией в Berkeley Unix.

PPP (англ. Point-to-Point Protocol) — двухточечный протокол канального уровня (Data Link) сетевой модели OSI. Обычно используется для установления прямой связи между двумя узлами сети, причем он может обеспечить аутентификацию соединения, шифрование и сжатие данных. Используется на многих типах физических сетей: нуль-модемный кабель, телефонная линия, сотовая связь и т. д.

Часто встречаются подвиды протокола PPP такие, как Point-to-Point Protocol over Ethernet (PPPoE) , используемый для подключения по Ethernet, и иногда через DSL; и Point-to-Point Protocol over ATM (PPPoA), который используется для подключения по ATM Adaptation Layer 5 (AAL5), который является основной альтернативой PPPoE для DSL.

PPP представляет собой целое семейство протоколов: протокол управления линией связи (LCP), протокол управления сетью (NCP), протоколы аутентификации (PAP, CHAP), многоканальный протокол PPP (MLPPP).

Основные характеристики

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

Автоматическая настройка

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

RFC 1994 описывает Challenge-handshake authentication protocol (CHAP)), который является предпочтительным для соединений с провайдерами. Уже устаревший, Password authentication protocol (PAP) всё еще иногда используется.

Другим вариантом аутентификации через PPP является Extensible Authentication Protocol (EAP).^[1]

После того, как соединение было установлено, поверх него может быть настроена дополнительная сеть. Обычно, используется Internet Protocol Control Protocol (IPCP) , хотя Internetwork Packet Exchange Control Protocol (IPXCP) и AppleTalk Control Protocol (ATCP) были когда-то популярны. Internet Protocol Version 6 Control Protocol (IPv6CP) получит большее распространение в будущем, когда IPv6 заменит IPv4 как основной протокол сетевого уровня.

Многопротокольная поддержка

PPP позволяет работать нескольким протоколам сетевого уровня на одном канале связи. Другими словами, внутри одного PPP-соединения могут передаваться потоки данных различных сетевых протоколов (IP, Novell IPX и т. д.), а также данные протоколов канального уровня локальной сети. Для каждого сетевого протокола используется Network Control Protocol (NCP) который его конфигурирует (согласовывает некоторые параметры протокола).

Обнаружение закольцованных связей

PPP обнаруживает закольцованные связи, используя особенность, включающую magic numbers. Когда узел отправляет PPP LCP сообщения, они могут включать в себя магическое число. Если линия закольцована, узел получает сообщение LCP с его собственным магическим числом вместо получения сообщения с магическим числом клиента.

44 Механизмы обеспечения качества обслуживания в IP-сетях. Критерии качества.

Критерии качества

Время задержки IP пакетов
Джиттер
Пропускная способность
Рпот

Возможные меры по обеспечению QoS

Увеличение пп
Задание приоритета данных
Организация очередей
Предотвращение перегрузок
Формирование трафика

Более подробно Смотри конспект Гольдштейна

45 Нормативные требования к QoS в ip-сетях для различных услуг в соответствии с рд.45.128-2000

4.3.1. В современных сетях по протоколу IP не гарантируется качество обслуживания (предоставляются услуги с негарантированным качеством обслуживания). В настоящее время разрабатываются и внедряются способы обеспечения качества обслуживания. Намечаемые показатели качества обслуживания в сетях по протоколу IP согласно Рекомендации МСЭ-Т I.380 приведены в табл. 4.7.

Таблица 4.7

Показатели качества обслуживания в службах ПД

с коммутацией пакетов по протоколу IP

Функция службы передачи данных	Показатели для критериев оценки
	Скорость	Правильность	Определенность
Доступ	Время доступа
Передача сообщений пользователя	Время переноса IP-пакета Вариация времени переноса IP-пакета Пропускная способность для IP-пакетов	Коэффициент ошибок в IP-пакетах Интенсивность появления ложныхIP-пакетов	Коэффициент потериIP-пакетов
Освобождение	Время освобождения
Критерий отказа Коэффициент готовности службы Среднее время между отказами службы

4.3.2. Нормы для этих показателей качества обслуживания в настоящее время изучаются. Предварительно (на основе проекта Рекомендации МСЭ-Т Y.1541) устанавливаются классы обслуживания, приведенные в табл. 4.8. Кроме того, предварительно рекомендуются следующие нормы для всех классов обслуживания, кроме “приемлемого”:

- время доступа: не более 5 с;

- коэффициент потери IP-пакетов: не более 1х10^-3;

- коэффициент ошибок в IP-пакетах: не более 1х10^-4;

- критерий отказа: отказом считается ситуация, при которой коэффициент потери IP-пакетов превышает 0,75.

4.3.3. Указанные нормы приведены для связи между оконечными точками (от конца до конца) IP-сети, имеющей архитектурную модель, которая определена в Рекомендации МСЭ-Т Y.1231. Нормы приведены для международной связи длиной 27500 км. Качество обслуживания в сетях отдельных операторов должно быть не хуже указанного в табл. 4.8.

4.3.4. Нормы для остальных показателей качества обслуживания подлежат разработке.

Таблица 4.8

Предварительно рекомендуемые нормы для классов обслуживания в службах ПД с коммутацией пакетов по протоколу IP

Класс обслуживания в службе ПД с IP	Нормы для международной связи
Класс обслуживания в службе ПД с IP	Время переноса IP-пакета	Вариация времени переноса IP-пакета
Приемлемый (с негарантированным качеством обслуживания)	Нормы не устанавливаются
Средний	Не более 1 с	Не более 1 с
Высокий	Не более 400 мс	Не более 50 мс
Высший	Не более 150 мс	Не более 50 мс

4.3.5. Выбор классов обслуживания, которые реализуются в конкретной IP-сети, производится оператором, владеющим этой сетью.

Информационная безопасность включает следующие понятия:

Конфиденциальность;
Аутентификация;
Целостность сообщения;
Управление доступом.

Безопасность в ip-сети – Конфиденциальность. Алгоритмы.

Конфиденциальность – это шифрование данных, т. Е. криптографическая защита.

Методы шифрования

Симметричные ключи (системы с общим секретным ключом).

Пример: стандарт DES (Data Encryption Standard), США, принят в 1977 г.

Асимметричные ключи (использование пары ключей – открытого и закрытого).

Шифрование текста

Пример: технология RAS (Rivest, Shamir, Aldeman), США, Массачусетский Технологический институт, принят в 1977 г.

Безопасность в ip-сети – Аутентификация (Цифровая подпись). Заголовок ан.

Аутентификация – это проверка подлинности источника данных, в частном случае это цифровая подпись

Цифровая подпись

Цифровая подпись и шифрование текста

Алгоритмы шифрования

Стандарт DES

Основные операции алгоритма DES

стандарты FEAL-N и FEAL-NX, 1989 г. N – число внутренних циклов (итераций), длина ключей – 64 и 128 бит.
ГОСТ 28147-89, СССР, принят в 1989г., впервые опубликован в 1992г., длина ключа – 256 бит.

Алгоритмы электронной цифровой подписи

Впервые идею ЭЦП предложили в 1976г. У. Диффи и М. Хеллман, Стенфордский университет, США. В основе алгоритма – общий секретный ключ. Стандарт RSA, 1977г., Массачусетский Технологический институт США. В основе алгоритма – открытый и закрытый (секретный) ключи. Метод Эль Гамаля, 1985г., США. В основе алгоритма – идея дискретного логарифмирования. ГОСТ Р 34.10-94 «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного алгоритма».

Безопасность глобальной сети Internet

Группа IETF разработала набор протоколов, которые обеспечивают информационную безопасность в глобальной сети Internet. Все вместе они называются семейством протоколов IPsec (IP security или защищенный протокол IP).

Аутентификация в протоколах ip

Заголовок IPv4

Заголовок TCP

Данные протокола IP

(а)

Заголовок IPv4

Заголовок аутентификации

Заголовок TCP

Данные протокола IP

(б)

Формат заголовка аутентификации

По AH (authentification header) смотри конспект стр 56-58

Безопасность в ip-сети – Проверка целостности сообщения Цифровая подпись

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

Хеш-функция

"Хэш-функция" действует таким образом, что в случае какого-либо изменения информации, пусть даже на один бит, результат "хэш-функции" будет совершенно иным. С помощью "хэш-функции" и закрытого ключа создается "подпись", передаваемая программой вместе с текстом. При получении сообщения получатель использует PGP для восстановления исходных данных и проверки подписи. При условии использования надежной формулы "хэш-функции" невозможно вытащить подпись из одного документа и вложить в другой, либо каким-то образом изменить содержание сообщения. Любое изменение подписанного документа сразу же будет обнаружено при проверке подлинности подписи.

Хэш-сумму/функцию также называют Дайджестом сообщения

Алгоритм передачи с дайджестом сообщения и цифровой подписью см. в конспекте стр 56

49. Служба Skype, принципы организации и её возможности

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

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

В отличие от многих других программ IP-телефонии, для передачи данных Skype использует P2P-архитектуру.

Каталог пользователей Skype распределён по компьютерам пользователей сети Skype, что позволяет сети легко масштабироваться до очень больших размеров (в данный момент более 100 миллионов пользователей, 15—25 миллионов онлайн) без дорогой инфраструктуры централизованных серверов.

Кроме того, Skype может маршрутизировать звонки через компьютеры других пользователей. Это позволяет соединяться друг с другом пользователям, находящимся за NAT (преобразовывает IP-адреса транзитных пакетов) или брандмауэром (комплекс аппаратных или программных средств, осуществляющий контроль и фильтрацию проходящих через него сетевых пакетов в соответствии с заданными правилами.), однако создаёт дополнительную нагрузку на компьютеры и каналы пользователей, подключённых к Интернету напрямую.

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

Благодаря используемым Skype кодекам (алгоритмам сжатия данных) Silk (8-24 кГц), G.729 (8 кГц) и G.711 (ранее использовались также ILBC и ISAC) и при достаточной скорости интернет-соединения (30—60 кбит/с) в большинстве случаев качество звука сопоставимо с качеством обычной телефонной связи.

VoIP-протокол Skype закрыт и используется только оригинальным программным обеспечением Skype.

Для стабильного использования видеосвязи необходима скорость интернет-соединения более 200 кбит/с и желательна тактовая частота процессора не менее 1 ГГц.

Мобильный Интернет, принципы организации и его возможности

2.5 G Надстройка над gsm – gprs/edge

Самый распространенный в России стандарт беспроводной передачи данных это GPRS и EDGE. Они являются надстройкой над технологией сотовой GSM связи. Данные собираются в пакеты и передаются через виртуальный канал, который предоставляется абоненту на время подключения GPRS сеанса. Для подключения к интернету можно воспользоваться сотовым телефоном с поддержкой GPRS или EDGE. Теоретически максимально-возможная скорость передачи данных при использовании GPRS – 171,2 Кбит/с, при использовании EDGE – 473,6 Кбит/с. На практике скорость намного меньше и составляет в среднем 40-45 Кбит/с.

EDGE – традиционный GSM с увеличенной спектральной плотностью

GPRS – технология пакетной передачи данных на выделенной частоте в выделенном ВИ(временном интервале)

2.5 G CDMA EV-DO

Довольно распространенный стандарт связи, присутствующий на российском рынке. Наиболее известным CDMA-оператором является SkyLink. В виду невысоких скоростей, которые поддерживает CDMA стандарт, для нас он не является интересным с точки зрения беспроводного интернет-доступа, так как скорость соединения ограничена 153 Кбит/сек. Намного интереснее надстройка над CDMA стандартом – EV-DO.

Пользователи, выбравшие EV-DO, получают такие возможности, как свободный доступ в интернет из любого местоположения, без зависимости от проводов, возможность использования VPN-сетей, неограниченный доступ в базы мобильного мультимедиа и многие другие. При этом максимальная скорость передачи данных в сети достигает 2,4 Мбит/с. Расширенная модификация стандарта – EV-DO Rev. A – скорость передачи данных до 3.1 Мбит/с и самая мощная ревизия EV-DO Rev. B – до 4.9 Мбит/с. Такой скорости уже более чем достаточно для комфортной работы в сети интернет. Если для GPRS задержка при прохождении пакетов с данными составляет 500-800 мс, то в CDMA сетях она снижена до 100-150 мс, что в свою очередь позволяет вести работу с приложениями, которые чувствительны к задержкам, типа VoIP, видеотелефония и видеоконференции, сетевые игры и многое другое.

Мобильный 3G интернет: WCDMA и UMTS

Технологический прорыв в области телекоммуникаций приходится в России на несколько последних лет и связан он со строительством сотовых сетей третьего поколения – 3G. WCDMA – широкополосный множественный доступ с кодовым разделением каналов и UMTS – универсальная система мобильной связи – это прием и передача данных на более высоких скоростях, чем в сетях GPRS и EDGE, возможность одновременно пользоваться мобильным интернетом и вести разговор.

Опять же, при скорости 384 Кбит/с UMTS не доставит большой радости любителям быстрого интернета, и даже его надстройка HSDPA, которая только теоретически имеет максимальную скорость соединения в 14,4 Мбит/с, а на практике едва достигает 3 Мбит/с.

Мобильный 4G интернет: WiMAX

Это беспроводная технология высокоскоростной передачи данных на больших расстояниях для широкого спектра устройств. Технология WiMax основана на стандарте IEEE 802.16, пропускная способность одной базовой станции WiMax при 6 секторах и ширине полосы 20МГц составляет 180 Мбит/с. Следует отметить, что существует фиксированный и мобильный WiMax. Нас интересует мобильная реализация, максимальная скорость соединения у которой 30 Мбит/c, причем интернет доступен даже при движении на скорости до 120 км/час.

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

Следующее поколение мобильного 4G интернета – LTE

Логическое продолжение развития технологий CDMA и UMTS, направленное на удовлетворение растущих потребностей в скорости передачи данных в мобильных сетях. Теоретическая скорость соединения в сети LTE достигает 326,4 Мбит/сек в сторону абонента и 172,8 Мбит/с в сторону базовой станции. LTE – это беспроводные сети 4-го поколения с коммутацией пакетов.

Технология LTE более эффективно использует частотный спектр, отличается повышенной емкостью и меньшими значениями задержки при передаче и для небольших пакетов может снижаться до значения всего в 5 мс! За счет этого происходит увеличение скорости передачи данных и повышение качества предоставляемых сервисов. Несомненное преимущество перед WCDMA (требующей полосы в 5 МГц) способность LTE работать с шириной полосы от 1.5 МГц до 20 МГц.

К сожалению, для строительства LTE сетей в России пока нет свободного частотного ресурса, и не понятно, когда он появится. Поэтому рассматривать данный стандарт как конкурирующий с проводным доступом в интернет мы не будем.

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

Получение новостей в Интернете – услуга, которая всегда востребована. Способы ее реализации расширяются по мере развития технологии.

На данный момент существует множество реализаций:

Подписка на новости по электронной почте – самое простое
SMS информирование через интернет (Пример – платформа SMS Inform у Мегафона)
Получение новостей через мобильный интернет
Получение новостей с новостных серверов по специализированным протоколам (NNTP)
И др.

Сетевой протокол передачи новостей (nntp)

Сетевой протокол передачи новостей (Network News Transfer Protocol, NNTP) — это основной протокол, применяемый клиентами и серверами для управления публикацией объявлений в новостных группах Usenet.

Серверы, применяющие NNTP, координируют всемирную сеть новостных групп Usenet. Для доступа к новостным группам, хранящимся на таких серверах, необходим NNTP-клиент. Они включены в большинство ведущих Web-браузеров, но могут выступать и в качестве отдельных продуктов с дополнительными функциями, наподобие Agent или Free Agent. Эти автономные клиенты называются программами чтения новостей.

По умолчанию NNTP действует через порт 119, работает на прикладном уровне модели OSI поверх протокола TCP

Если по-простому то: протокол нужен для доступа к новостным группам (которые хранятся на новостных серверах) и закачки материала из них

52. Электронные платежные системы в Интернет, обзор, характеристика

Платежная система в Интернете - это система проведения расчетов между финансовыми, коммерческими организациями и пользователями Интернета в процессе покупки/ продажи товаров и услуг через Интернет. В системе электронной коммерции платежи совершаются при соблюдении ряда условий:

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

В России и странах СНГ лидером является система WebMoney, которая хранит деньги в специальных электронных кошельках и открывает счета для пользователей в долларах, российских рублях и евро.

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

В Европе распространение получила система E-Gold, использующая весовые части драгоценных металлов – платины, золота, серебра или палладия. На Западе большее предпочтение отдается такому виду платежей, так как расчеты не зависят от валютных курсов. Работа полностью осуществляется в онлайн-режиме, курсы валют и драгоценных металлов могут быть сравнимы в любой момент, а операции являются доступными и простыми.

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

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

У WebMoney имеется достойный конкурент – система PayCash, именующая себя «первой платежной системой в России, которая базируется на классической технологии цифровой наличности…» Можно отметить, что Yandex.Деньги базируется на этой системе и функционирует в постоянном контакте с ней.

С октября 2006 года система PayPal функционирует в России. Хотя данная система получила мировое признание, на российском рынке возникли некоторые проблемы, так как система не предоставляет полного перечня услуг. Товары оплачивать можно, а остальные платежи пока недоступны. Данная система опасается массового мошенничества.

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

<<< < Предыдущая 1 2 3 4 5 6 7 8 9 10 1112 / 1212

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

#
29.03.2016227.59 Кб33Komissarov_A_B_i_dr_Tekhnicheskiy_inostranny_yazyk_Angliyskiy_Uchebnoe_posobie.docx
#
15.03.2015580.61 Кб95kompyuternye_sistemy_podderzhki_prinyatiya_res.doc
#
15.03.20151.47 Mб75KONSPEKT_LEKTsIJ_PO_FOE.doc
#
15.03.2015292.95 Кб11KONTRA_word.pdf
#
15.03.2015331.99 Кб25kontr_antonov.pdf
#
21.04.20191.67 Mб9KONYeChNAYa_PYeChAT.docx
#
15.03.2015879.1 Кб19Korzhenevsky.doc
#
24.11.2018539.46 Кб7kozin_s_v_korobov_s_a_metodicheskie_ukazaniya_k....docx
#
29.03.20166.09 Mб74kp- pr i str-vo vols-izd..doc
#
15.03.20152.32 Mб34Krakovetskyi-KogdaYaGovoril.pdf
#
15.03.20151.73 Mб373KURSOVA 111.docx

Формат протокола udp имеет следующий:

Формат udp-дейтаграммы

18 Протокол межсетевого взаимодействия ip. Структура ip-пакета. Заголовок iPv4, характеристика его полей.

Формат ip пакета

Поле "тип сервиса" (Type of Service)

19 Классовая адресация в ip-сетях (iPv4). Структура адресов. Специальные адреса. Форма представления адреса. Подсети. Выделение идентификаторов сети и подсети.

Классовая система адресации

Специальные адреса

Назначение идентификаторов сетей

Подсети

Формирование трехуровневой иерархии

Маски сетей

Маски для подсетей, создаваемых в сети класса в

Протоколы разрешения адресов arp и rarp (самостоятельное изучение с учетом лабораторной работы по arp).

Принцип работы

21 Размеры ip-дейтаграмм, mtu. Процедура фрагментации, управление фрагментацией, сборщик фрагментов.

Фрагментация

22 Время жизни дейтаграмм (iPv4). Контроль за временем жизни. Механизмы установления времени жизни ip-дейтаграммы.

26 Протокол межсетевых управляющих сообщений icmp. Назначение. Типы сообщений. Механизм передачи icmp-сообщений в сети Internet.

27 Межсетевой пакетный тестер ping. Целевое назначение. Форматы icmp-сообщений запроса на эхо и ответа на него.

28 Icmp-сообщение о недостижимости получателя. Формат этого icmp-сообщения

29 Icmp-сообщение о подавлении источника данных. Целевое назначение. Формат такого icmp-сообщения. Формат подавления источника

30 Icmp-сообщения запроса временной метки и ответа на него. Форматы сообщений. Синхронизация часов и оценка времени передачи

31 Утилита traceroute. Назначение и принципы работы

1. Быстрое исчерпание адресного пространства.

2. Отсутствие поддержки иерархии.

3. Сложность настройки сети.

4. Отсутствие встроенных систем проверки подлинности и конфиденциальности.

Формы представления адресов в iPv6

Типы адресов в iPv6

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

34 Адресация в iPv6. Сопряжение версий iPv4 и iPv6. Взаимодействие систем, работающих с разными стеками протоколов

Метод двойного стека

Туннелирование

35 Протокол rtp и его характеристика. Формат заголовка, назначение полей. Протокол rtp. Организация передачи трафика реального времени по сети Интернет. Мультимедиа

Почему нужен rtp

Принципы построения протокола rtp

Определения

Заголовок пакета rtp

Архитектура маршрутизатора

37 Принципы статической и динамической маршрутизации. Формирование маршрутных таблиц, их содержание. Понятие об алгоритмах Беллмана–Форда и Дийкстра.

38 Протоколы внутренней маршрутизации rip1, rip2. Форматы сообщений. Недостатки. Взаимодействие с транспортными протоколами.

Формат сообщения протокола rip 1

Формат сообщения протокола rip 2

39 Протокол внутренней маршрутизации ospf. Формат ospf–сообщений. Механизм рассылки маршрутной информации.

40 Протокол внешней маршрутизации bgp и его функции. Виды bgp-сообщений. Механизм распространения маршрутной информации.

Формат bgp-сообщения об обновлении

Формат bgp-сообщения об открытии bgp-соединения

Поддержка бесклассовой адресации

42 Групповая рассылка пакетов в сети Интернет. Протокол групповой маршрутизации igmPv2. Формат igmp-сообщений. Механизм переноса igmp-сообщений.

Групповая маршрутизация с общим деревом

Групповая маршрутизация с деревом у каждого отправителя

Межсетевой протокол управления группами igmp (Internet Group Management Protocol)rfc 2236, версия 2

Две составляющие групповой рассылки сетевого уровня: протокол igmp и протоколы групповой маршрутизации

Туннели для групповой рассылки Физическая топология

Логическая топология

43 Абонентский доступ к сети Internet. Протоколы slip и ppp. Сравнение (самостоятельное изучение)

Принципы работы

Недостатки

Основные характеристики

Автоматическая настройка

Многопротокольная поддержка

Обнаружение закольцованных связей

45 Нормативные требования к QoS в ip-сетях для различных услуг в соответствии с рд.45.128-2000

Безопасность в ip-сети – Конфиденциальность. Алгоритмы.

Безопасность в ip-сети – Аутентификация (Цифровая подпись). Заголовок ан.

Безопасность глобальной сети Internet

Аутентификация в протоколах ip

Формат заголовка аутентификации

Безопасность в ip-сети – Проверка целостности сообщения Цифровая подпись

49. Служба Skype, принципы организации и её возможности

Мобильный Интернет, принципы организации и его возможности

2.5 G Надстройка над gsm – gprs/edge

Сетевой протокол передачи новостей (nntp)

52. Электронные платежные системы в Интернет, обзор, характеристика