Адресация

IPv4 использует 32-битные (четырёхбайтные) адреса, ограничивающие адресное пространство 4 294 967 296 (2³²) возможными уникальными адресами.

Удобной формой записи IP-адреса (IPv4) является запись в виде четырёх десятичных чисел (от 0 до 255), разделённых точками, например, 192.168.0.1. (или 128.10.2.30 — традиционная десятичная форма представления адреса)

[Править]Представление адреса

Форма записи	Пример	Преобразование из десятичной нотации с точками
Десятичная с точками (англ.)	192.0.2.235	—
Шестнадцатеричная с точками	0xC0.0x00.0x02.0xEB	Каждый октет преобразуется в шестнадцатеричную форму
Восьмеричная с точками	0300.0000.0002.0353	Каждый октет преобразуется в восьмеричную форму
Шестнадцатеричная	0xC00002EB	Конкатенация октетов из шестнадцатеричной нотации с точками
Десятичная	3221226219	32-битное число в десятичной форме
Восьмеричная	030000001353	32-битное число в восьмеричной форме

[Править]Зарезервированные адреса

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

Подсеть	Назначение
0.0.0.0/8[1]	Адрес источника пакета
127.0.0.0/8[1]	Подсеть для коммуникаций внутри хоста (см. localhost)
169.254.0.0/16[2]	Канальные (link-local) адреса
192.0.2.0/24[3]	Для примеров и документации
198.51.100.0/24[3]	Для примеров и документации
203.0.113.0/24[3]	Для примеров и документации
198.18.0.0/15[4]	Для стендов тестирования производительности
10.0.0.0/8[5]	Для использования в частных сетях
172.16.0.0/12[5]	Для использования в частных сетях
192.168.0.0/16[5]	Для использования в частных сетях
240.0.0.0/4[6]	Зарезервировано для использования в будущем
255.255.255.255[7]	Широковещательный адрес

Подсеть 224.0.0.0/4 зарезервирована для многоадресной рассылки.

[Править]Структура пакета

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

Смещение в битах	0–3	4–7	8–13	14-15	16–18	19–31
0	Версия	Размер заголовка	Differentiated Services Code Point	Explicit Congestion Notification	Размер пакета
32	Идентификатор				Флаги	Смещение фрагмента
64	Время жизни		Протокол		Контрольная сумма заголовка
96	Адрес источника
128	Адрес назначения
160	Опции ( если размер заголовка > 5 )
160 или 192+	Данные

Версия 

Первым полем пакета является версия протокола размером в четыре бита. Для IPv4 это 4.

Размер заголовка 

Следующие четыре бита содержат размер заголовка пакета в 32-х битных словах. Поскольку число опций не постоянно, указание размера важно для отделения заголовка от данных. Минимальное значения равно 5 (5×32=160 бит, 20 байт), максимальное — 15 (60 байт).

Differentiated Services Code Point (DSCP)

Изначально называлось «тип обслуживания» (Type of Service, ToS), в настоящее время определяется RFC2474 как «Differentiated Services». Используется для разделения трафика на классы обслуживания, например для установки чувствительному к задержкам трафику, такому как VoIP большего приоритета.

Указатель перегрузки (Explicit Congestion Notification, ECN) 

Предупреждение о перегрузке сети без потери пакетов. Является необязательной функцией и используется только если оба хоста ее поддерживают.

Размер пакета 

16-битный полный размер пакета в байтах, включая заголовок и данные. Минимальный размер равен 20 байтам (заголовок без данных), максимальный — 65535 байт. Хосты обязаны поддерживать передачу пакетов размером не менее 576 байт, но современные реализации обычно поддерживают гораздо больший размер. Пакеты большего размера, чем поддерживает канал связи, фрагментируются.

Идентификатор 

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

Флаги 

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

• 0: Зарезервирован, должен быть равен 0^[9].

• 1: Не фрагментировать

• 2: У пакета еще есть фрагменты

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

Флаг «есть фрагменты» должен быть установлен в 1 у всех фрагментов пакета, кроме последнего. У нефрагментированных устанавливается в 0 — такой пакет считается собственным последним фрагментом.

Смещение фрагмента 

Поле размером в 13 бит, указывает смещение текущего фрагмента от начала передачи фрагментированного пакета в блоках по 8 байт. Позволяет (2¹³-1)×8=65528 байт смещения, что превышает максимальный размер пакета. Первый фрагмент в последовательности имеет нулевое смещение.

«Время жизни» (Time to Live, TTL) пакета. 

Позволяет предотвратить закольцовывание пакетов в сети путем уничтожения пакетов, превысивших время жизни. Указывается в секундах, интервалы менее секунды округляются до одной секунды. На практике каждый маршрутизатор уменьшает время жизни пакетов на единицу (что справедливо при существующих типичных задержках в сети). Пакеты, время жизни которых стало равно нулю уничтожаются, а отправившему посылается сообщение ICMP Time Exceeded. На отправке пакетов с разным временем жизни основана трассировка их пути прохождения (traceroute).

Протокол 

Указывает, данные какого протокола содержит пакет (например, TCP или ICMP). Присвоенные номера протоколов можно найти на сайте IANA^[10].

Контрольная сумма заголовка 

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

Поскольку TTL уменьшается на каждом шаге прохождения пакета, сумма тоже должна вычисляться на каждом шаге. Метод пересчета контрольной суммы определен в RFC1071^[11].

Адрес источника 

32-х битный адрес отправителя пакета. Может не совпадать с настоящим адресом отправителя из-за трансляции адресов.

Адрес назначения 

32-х битный адрес получателя пакета.

Опции 

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

Если список опций не является концом заголовка, он должен оканчиваться опцией 0x00. Опции имеют следующий формат:

Билет№12

DNS позволяет сопоставить числовой IP-адрес и символьный, например: 194.85.92.93 = test.ru.

При этом символьный адрес в DNS представляет собой текстовую строку, составленную по особым правилам. Самое важное из этих правил – иерархия доменов. Система адресов DNS имеет древовидную структуру. Узлы этой структуры называются доменами. Каждый домен может содержать множество «подчиненных» доменов.

Дерево DNS принято делить по уровням: первый, второй, третий и так далее. При этом начинается система с единственного корневого домена (нулевой уровень). Интересно, что про существование корневого домена сейчас помнят только специалисты, благодаря тому, что современная DNS позволяет не указывать этот домен в адресной строке. Впрочем, его можно и указать. Адресная строка с указанием корневого домена выглядит, например, так: «site.test.ru.» – здесь корневой домен отделен последней, крайней справа, точкой.

Как несложно догадаться, адреса с использованием DNS записываются в виде последовательности, отражающей иерархию имен. Чем «выше» уровень домена, тем правее он записывается в строке адреса. Разделяются домены точками. Разберем, например, строку www.site.nic.ru. Здесь домен www – это домен четвертого уровня, а другие упомянутые в этой строке домены расположены в домене первого уровня RU. Например, site.nic.ru – это домен третьего уровня. Очень важно понимать, что привычный адрес веб-сайта, скажем, www.test.ru, обозначает домен третьего уровня (www), расположенный внутри домена второго уровня test.ru.

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

Наиболее важны так называемые корневые серверы DNS, обеспечивающие работу всей системы доменных имен Интернета в целом. Существует 13 таких серверов, и они принадлежат техническому центру ICANN. Ключевую роль играют также корневые серверы доменов первого уровня (например, RU), обеспечивающие распространение по всему Интернету DNS-информации о домене, находящемся в их зоне ответственности.

С точки зрения пользователя и в сильно упрощенном виде алгоритм работы DNS по поиску адресов web-сайтов можно описать следующим образом. Когда пользователь вводит в адресной строке браузера адрес web-сайта, например, site.nic.ru, компьютер выполняет запрос к тому или иному известному этому компьютеру серверу DNS, «спрашивая» сервер о том, какой IP-адрес связан с «доменным адресом», указанным пользователем. В ответ сервер DNS, проверив соответствие по своим внутренним таблицам или выполнив запрос к другим серверам DNS, присылает искомый IP-адрес. Далее браузер устанавливает соединение с web-сайтом уже по IP-адресу.

Система доменных имён разработана в 80-х годах прошлого века и продолжает успешно обеспечивать удобство работы с адресным пространством Интернета по сей день. Технологии DNS развиваются. Одним из важных и самых ожидаемых интернет-общественностью нововведений в DNS является повсеместное внедрение доменных имен, записываемых с помощью символов национальных алфавитов (например, кириллический домен первого уровня .РФ).

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

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

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

Существуют две основные схемы разрешения DNS-имен. В первом варианте работу по поиску IP-адреса координирует DNS-клиент:

DNS-клиент обращается к корневому DNS-серверу с указанием полного доменного имени;

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

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

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

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

DNS-клиент запрашивает локальный DNS-сервер, то есть тот сервер, который обслуживает поддомен, к которому принадлежит имя клиента;

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

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

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

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