Опубликован: 28.09.2007 | Уровень: специалист | Доступ: платный
Лекция 1:

Введение в Интернет

Лекция 1: 12345678 || Лекция 2 >

1.1. Протокол IP

В Интернет используется много различных типов пакетов, но один из основных — IP-пакет (RFC-791), именно он вкладывается в кадр Ethernet и именно в него вкладываются пакеты UDP, TCP и ICMP. IP-протокол предлагает ненадежную транспортную среду: ненадежную в том смысле, что не существует гарантии благополучной доставки IP-дейтаграммы. Алгоритм доставки в рамках данного протокола предельно прост: при ошибке дейтаграмма выбрасывается, а отправителю посылается соответствующее ICMP-сообщение (или не посылается ничего). Обеспечение же надежности возлагается на более высокий уровень (UDP или TCP). Формат IP-пакетов показан на рисунке 1.5.

Поле версия характеризует версию IP-протокола (например, 4 для v4 или 6 – для v6). Формат пакета определяется программой и, вообще говоря, может быть разным для разных значений поля версия. Только размер и положение этого поля незыблемы. Поэтому в случае изменений длины IP-адреса или других вариаций заголовка слишком тяжелых последствий не произойдет. Понятно также, что значение поля версия во избежание непредсказуемых последствий должно контролироваться программой. Поле версия определяет то, что следует далее делать с заголовком дейтаграммы и полем данных. Ниже на рис. 1.5а для сравнения приведен формат заголовка дейтаграммы IPv6 (RFC-2460). Заголовок для IPv6 имеет размер в два раза больше, чем для IPv4.

Общим полем для заголовков является только версия. Поле длина заголовка Hlen (v4) нужно из-за возможности присутствия полей опций. Hlen — длина заголовка, измеряемая в 32-разрядных словах, обычно заголовок содержит 20 октетов (Hlen=5, без опций и заполнителя). В версии 6 заголовок имеет фиксированную длину, и необходимость в поле длины заголовка отпадает. Функция тип сервиса (ToS IPv4) реализуется в IPv6 в несравненно большем объеме с помощью полей класс трафика и метка потока. Функции полей идентификатор, флаги и указатель фрагмента, управляющие фрагментацией, реализуются, если требуется, с помощью полей метка потока или следующий заголовок (IPv6).

Поля идентификатор, флаги (3 бита) и указатель фрагмента (fragment offset; IPv4) управляют процессом фрагментации и последующей "сборки" дейтаграммы. Идентификатор представляет собой уникальный код дейтаграммы, позволяющий идентифицировать принадлежность фрагментов и исключить ошибки при "сборке" дейтаграмм. Бит 0 поля флаги является резервным, бит 1 служит для управления фрагментацией пакетов (0 — фрагментация разрешена; 1 — запрещена), бит 2 определяет, является ли данный фрагмент последним (0 — последний фрагмент; 1 — следует ожидать продолжения). Поле полная длина (IPv4) функционально эквивалентно полю размер поля данных (IPv6). Поле полная длина определяет полную длину IP-дейтаграммы (до 65535 октетов), включая заголовок и данные. В случае Ethernet длина дейтаграммы не может быть больше 1500 байт.

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

Протокол IPv6 требует, чтобы каждый канал в Интернет имел MTU = 576 октетов или более. Для каждого канала, который не способен обеспечить длину пакетов в 576 октетов, должна быть обеспечена фрагментация/дефрагментация на уровне ниже IPv6.

Формат дейтаграммы Интернет IPv4

Рис. 1.5. Формат дейтаграммы Интернет IPv4
Формат заголовка дейтаграммы IPv6

Рис. 1.5a. Формат заголовка дейтаграммы IPv6

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

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

Поле TTL относится к числу переменных полей заголовка. При прохождении через маршрутизатор над содержимым этого поля производится операция TTL=TTL-1, при этом должна быть пересчитана контрольная сумма. И, если TTL=0, дейтаграммы отбрасываются.

Потенциально переменными полями заголовка в IPv4 являются также флаги и указатель фрагмента.

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

Однооктетное поле тип сервиса (TOS — type of service; IPv4) характеризует то, как должна обрабатываться дейтаграмма, как производится буферизация. Это поле делится на 6 субполей (рис. 1.5б.).


Рис. 1.5b.

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

0 — обычный уровень

1 — приоритетный

2 — немедленный

3 — срочный

4 — экстренный

5 — ceitic/ecp

6 — межсетевое управление

7 — сетевое управление

Формат поля TOS определен в документе RFC-1349. Биты C, D, T и R характеризуют пожелание относительно способа доставки дейтаграммы. Так, D=1 требует минимальной задержки, T=1 — высокую пропускную способность, R=1 — высокую надежность, а C=1 — низкую стоимость. В таблице 1.1 приведены рекомендуемые значения TOS.

Только один бит из четырех в TOS может принимать значение 1. Значения по умолчанию равны нулю. Большинство из рекомендаций самоочевидны. Так, при telnet наибольшую важность имеет время отклика, а для SNMP (управление сетью) — надежность.

Таблица 1.1. Значения TOS для разных протоколов
процедура минимал задержка максим пропускная способность максим надежность минимал стоимость код TOS
FTP управление,

FTP данные

1 0 0 0 0x10
0 1 0 0 0x08
TFTP 1 0 0 0 0x10
DNS,

UDP,

TCP

1 0 0 0 0x00
0 0 0 0 0x10
0 0 0 0 0x00
telnet 1 0 0 0 0x10
ICMP 0 0 0 0 0x00
IGP 0 0 1 0 0x04
SMTP управление

SMTP данные

1 0 0 0 0x10
0 1 0 0 0x08
SNMP 0 0 1 0 0x04
NNTP 0 0 0 1 0x02

До середины 90-х годов поле TOS в большинстве реализаций игнорировалось. Но после начала разработок средств обеспечения качества обслуживания (QoS) внимание к этому возросло. Появилось предложение замены поля TOS на поле DSCP (Differentiated Services Code Point), которое также имеет 8 бит (см. RFC-2474). (Смотри рис. 1.6.). Биты CU пока не определены. Иногда это поле называется байтом DS (Differentiated Services).

Формат поля DSCP.

Рис. 1.6. Формат поля DSCP.

Биты DS0-DS5 определяют селектор класса. Значения этого кода представлены в таблице ниже. Стандартным значением DSCP по умолчанию является 000000 (Таблица . 1.1.1.).

Таблица 1.1.1.
Селектор класса DSCP
Приоритет 1 001000
Приоритет 2 010000
Приоритет 3 011000
Приоритет 4 100000
Приоритет 5 101000
Приоритет 6 110000
Приоритет 7 111000

На базе DSCP разработана технология "пошагового поведения" PHB (Per Hop Behavior). В рамках этой политики определяются коды DSCP внутри классов. Например, для политики немедленной переадресации EF рекомендуемое значение DSCP=101110. Эта политика соответствует наиболее высокому уровню обслуживания.

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

Поле время жизни (TTL — time to live) раньше задавало время жизни дейтаграммы в секундах, т.е. предельно допустимое время пребывания дейтаграммы в пути. В настоящее время TTL определяет предельное число маршрутизаторов, через которые может пройти дейтаграмма. При каждой обработке дейтаграммы, например в маршрутизаторе, это время уменьшается в соответствии со временем пребывания в данном устройстве или согласно протоколу обработки. Если TTL=0, дейтаграмма из системы удаляется. Во многих реализациях TTL измеряется в числе шагов, в этом случае каждый маршрутизатор выполняет операцию TTL=TTL-1. TTL помогает предотвратить зацикливание пакетов. Поле протокол аналогично полю тип в Ethernet-кадре и определяет алгоритм обработки поля данные (см. табл. 1.1.1).

Поле контрольная сумма заголовка вычисляется с использованием операций сложения 16-разрядных слов заголовка по модулю 1. Сама контрольная сумма является дополнением по модулю один полученного результата сложения. Обратите внимание, здесь осуществляется контрольное суммирование заголовка, а не всей дейтаграммы. Поле опции не обязательно присутствует в каждой дейтаграмме. Размер поля опции зависит от того, какие опции применены. Если используется несколько опций, они записываются подряд без каких-либо разделителей. Каждая опция содержит один октет кода опции, за которым может следовать октет длины и серия октетов данных. Если место, занятое опциями, не кратно 4 октетам, то используется заполнитель. Структура октета кода опции отражена на рис. 1.7.

Таблица 1.2. Коды протоколов Интернет
код протокола Интернет Сокращенное название протокола описание
0 - Зарезервировано
1 ICMP Протокол контрольных сообщений [rfc-792]
2 IGMP Групповой протокол управления [rfc-1112]
3 GGP Протокол маршрутизатор-маршрутизатор [RFC-823]
4 IP IP поверх IP (инкапсуляция/туннели)
5 ST Поток [rfc-1190]
6 TCP Протокол управления передачей [RFC-793]
7 UCL UCL
8 EGP Протокол внешней маршрутизации [RFC-888]
9 IGP Протокол внутренней маршрутизации
10 BBN-MON BBN-RCC мониторирование
11 NVP-II Сетевой протокол для голосовой связи [RFC-741]
12 PUP PUP
13 ARGUS Argus
14 Emcon Emcon
15 Xnet Перекрестный сетевой отладчик [IEN-158]
16 Chaos Chaos
17 UDP Протокол дейтаграмм пользователя [RFC-768]
18 MUX Мультиплексирование [IEN-90]
19 DCN-MEAS DCN измерительные субсистемы
20 HMP Протокол мониторирования ЭВМ (host [RFC-869])
21 PRM Мониторирование при передаче пакетов по радио
22 XNS-IDP Xerox NS IDP
23 Trunk-1 Trunk-1
24 Trank-2 Trunk-2
25 Leaf-1 Leaf-1
26 Leaf-2 Leaf-2
27 RDP Протокол для надежной передачи данных [RFC-908]
28 IRTP Надежный TP для Интернет [RFC-938]
29 ISO-TP4 ISO транспортный класс 4 [RFC-905]
30 Netblt Массовая передача данных [RFC-969]
31 MFE-NSP Сетевая служба MFE
32 Merit-INP Межузловой протокол Merit
33 SEP Последовательный обмен
34 не определен
35 IDRP Междоменный протокол маршрутизации
36 XTP Xpress транспортный протокол
37 DDP Протокол доставки дейтаграмм
38 IDPR-CMTP IDPR передача управляющих сообщений
39 TP++ TP++ транспортный протокол
40 IL IL-транспортный протокол
41 SIP Простой Интернет-протокол
42 SDRP Протокол маршрутных запросов для отправителя
43 SIP-SR SIP исходный маршрут
44 SIP-Frag SIP-фрагмент
45 IDRP Интер-доменный маршрутный протокол
46 RSVP Протокол резервирования ресурсов канала
47 GRE Общая инкапсуляция маршрутов
49 BNA BNA
50 SIPP-ESP SIPP ESЗ
52 I-NLSP Интегрированная система безопасности сетевого уровня
53 Swipe IP с кодированием
54 NHRP Nbma протокол определения следующего шага
55-60 не определены
61 Любой внутренний протокол ЭВМ
62 CFTP CFTP
63 Любая локальная сеть
64 Sat-Expak Satnet и Expak
65 MIT-Subn Поддержка субсетей MIT
66 RVD Удаленный виртуальный диск MIT
67 IPPC IPPC
68 Любая распределенная файловая система
69 Sat-Mon Мониторирование Satnet
70 не определен
71 IPCV Базовая пакетная утилита
75 PVP Пакетный видео-протокол
76 BRsat-Mon Резервное мониторирование Satnet
78 Wb-mon Мониторирование Expak
79 Wb-expak Широкополосная версия Expak
80 ISO-IP ISO Интернет протокол
88 IGRP IGRP (Cisco) — внутренний протокол маршрутизации
89 OSPFIGP OSPFIGP — внутренний протокол маршрутизации
92 MTP Транспортный протокол мультикастинга
101-254 не определены
255 Зарезервировано
Формат описания опций

Рис. 1.7. Формат описания опций
Лекция 1: 12345678 || Лекция 2 >
Евгений Виноградов
Евгений Виноградов

Прошел экстерном экзамен по курсу перепордготовки "Информационная безопасность". Хочу получить диплом, но не вижу где оплатить? Ну и соответственно , как с получением бумажного документа?

Илья Сидоркин
Илья Сидоркин

Добрый день! Подскажите пожалуйста как и когда получить диплом, после сдичи и оплаты?????

виктор виноградов
виктор виноградов
Россия, Курская область
Евгений Миловзоров
Евгений Миловзоров
Россия, Пенза, ПГУ, 2004