Основы

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

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

Коммутация каналов vs. пакетная передача

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

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

Протокол IP позволил изменить эту модель — передавать данные пакетным образом. Пакетная доставка позволила передавать данные кусочками: вы передали кусочек на маршрутизатор, тот перекинул его дальше. Если какой-то кусочек потеряется — не страшно, можно перезапросить. Если пакет пойдет по другой трассе — это штатное явление.

Военное происхождение и надежность

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

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

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

Военных это очень привлекало, поэтому они инвестировали значительные средства в протокол IP.

Особенности доставки в IP

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

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

Основные особенности:

• Потеря пакетов — пакеты могут не дойти до получателя, и это штатная ситуация
• Изменение пакетов — IP-пакеты могут изменяться по дороге; отправляете один пакет, а до получателя может дойти другой
• Нарушение порядка — пакеты могут приходить не в том порядке, в котором были отправлены (если разные трассы имеют разную длину)
• Дублирование пакетов — пакеты могут дублироваться при передаче (был случай, когда маршрутизаторы одного производителя штатно дублировали пакеты, и производитель ссылался на спецификацию IP, которая это допускает)

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

Если вам нужна гарантия доставки, неизменность данных и соблюдение порядка — используйте протокол транспортного уровня (например, TCP).

История протокола IP

Протокол IP родился как следствие появления модели DoD (Department of Defense), она же модель TCP/IP. Придумали его Винт Серф и Роберт Кан (он же Боб Кан).

Основные вехи:

Год	Событие
1974	Работа "Протокол для пакетного межсетевого взаимодействия" (RFC 675)
1977	Появляется протокол TCP с разделением на транспортный уровень и межсетевое взаимодействие
1978	Выходит следующая версия спецификации TCP, черновик отдельного протокола межсетевого взаимодействия. Появляется версионность в поле заголовка
1978	IP версии 2 (Internet Work Protocol) — уже отдельный протокол
1978	IP версии 3 — рекомендация для внедрения
1978	IP версии 4 — привычный нам протокол IPv4
1980	RFC 760 — стандартный протокол IPv4
1981	RFC 791 — появляется классовая адресация
1990	Начинается работа над следующей версией IP
1998	Выходит IPv6 (RFC)

Обратите внимание на путаницу в версиях: самая первая версия протокола IP была частью TCP версии 3. Она выросла в отдельный протокол IP версии 2, затем версии 3, и наконец версии 4. Поэтому во всех пакетах IPv4 в поле версии заголовка стоит четверка.

Проблемы IPv4 и появление IPv6

Практически сразу стали понятны проблемы IPv4:

• Мало адресов
• Неэффективность их использования
• Невозможность контроля качества доставки

С 1990 года началась работа над следующей версией. IPv5 была промежуточной (фактически multicast для IPv4). В 1998 году вышел IPv6, который решает проблемы IPv4 путем глобального увеличения адресного пространства и устранения неэффективностей.

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

Взаимодействие IP-устройств

В IPv4 устройства делятся на два типа:

1. Конечные (терминальные) узлы — отправители и получатели
2. Промежуточные узлы — маршрутизаторы

Поведение этих двух классов устройств описывается отдельными RFC. Сам протокол IP (RFC 791 и предшественник RFC 760) описывает лишь рамочное устройство IP. А дальше: как устроен отправитель, как устроен получатель, как работает IP по конкретному типу канала — все это отдельные документы.

Поведение отправителя

Когда узел-отправитель хочет отправить данные, он выполняет следующие шаги:

1. Формирует новый пакет — берет данные, оборачивает их IP-заголовком, прописывает нужные поля
2. Определяет выходной интерфейс — в какую канальную среду нужно передать пакет (у устройства может быть несколько интерфейсов: Ethernet, Wi-Fi, Bluetooth, 3G)
3. Определяет канальный адрес соседа — если получатель в той же канальной среде, пакет отправляется ему напрямую; если нет — пакет передается маршрутизатору. Например, в случае Ethernet нужен MAC-адрес получателя или маршрутизатора
4. Выполняет передачу — занимает среду, выдает данные и забывает про пакет

Поведение получателя

Узел-получатель:

1. Получает пакет и проверяет данные на корректность
2. Убеждается, что является получателем (проверяет IP-адрес получателя в пакете)
3. Отправляет содержимое на обработку протоколу вышестоящего (транспортного) уровня

Поведение маршрутизатора

Маршрутизатор — промежуточный узел, который берет данные из одной канальной среды и передает в другую:

1. Получает IP-пакет, распаковывает, проверяет корректность
2. Убеждается, что не является получателем (если бы являлся — обработал бы пакет сам)
3. Определяет, кому из соседей передать пакет (механизм выбора — это маршрутизация, отдельная большая тема)
4. Определяет выходной интерфейс и канальный адрес соседа
5. При необходимости модифицирует определенные поля IP-пакета
6. Передает пакет дальше

Инкапсуляция IP в канальные среды

IP-пакеты можно передавать по разным канальным средам:

• Ethernet — IP-пакет вкладывается напрямую в кадр Ethernet, в поле EtherType указывается значение 0x0800
• Сети стандарта IEEE 802 (Wi-Fi 802.11, WiMAX 802.16, Bluetooth 802.15) — используются вложения SNAP/LLC по стандарту 802.2
• ATM — IP-пакет разбивается на ячейки (IP over ATM). ATM сам умеет собирать данные в нужном порядке. Сегодня ATM в основном встречается в ADSL-каналах
• Прямые каналы точка-точка — можно использовать PPP, HDLC (Cisco HDLC) и другие протоколы

Главное требование: должна быть спецификация, как взять IP-пакет и передать его по конкретному каналу.

RFC 1149 — IP поверх почтовых голубей

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

С голубем может случиться что угодно: его может съесть лиса, он может улететь не туда. IP устроен именно так — отправляет пакет, а дальше: дойдет — хорошо, не дойдет — IP это не интересует.

Энтузиасты реализовали этот RFC на практике: запустили команду ping, распечатали 5 запросов echo request на бумажках, отправили голубей. Результат: время ответа около 3200 секунд, 80% пакетов доставлено успешно.

IPv4-адреса

Формат и структура

IPv4-адрес — это просто 32-битное число. Всего существует чуть более 4 миллиардов адресов.

Адрес назначается на канальный интерфейс, поэтому у одного узла может быть несколько интерфейсов и, как следствие, несколько адресов. Более того, на одном интерфейсе тоже может быть несколько IP-адресов.

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

Network ID и Host ID

Адрес состоит из двух частей:

• Network ID (левая часть, старшие биты) — идентификатор канальной сети
• Host ID (правая часть, младшие биты) — идентификатор хоста в канале

Правила:

• Узлы в одной канальной среде обязаны иметь одинаковый Network ID
• Узлы в разных канальных средах обязаны иметь разный Network ID
• В одной канальной среде Host ID у каждого узла обязан быть уникальным
• В разных канальных средах Host ID может совпадать (это нормально)

Пример: адреса 192.168.1.1 и 192.168.2.1 вполне могут сосуществовать — они из разных сетей.

Граница между Network ID и Host ID по внешнему виду адреса не определяется — она задается отдельно.

Формат записи

Стандартного, предписанного формата записи IPv4-адреса не существует. Это просто 32-битное число, и вы можете использовать любой формат, который однозначно восстанавливает это число. Например, число 2130706433 — это адрес 127.0.0.1. Можете попробовать: наберите ping 2130706433 — и он будет пинговать 127.0.0.1.

Общепринятый формат — четыре октета, разделенных точками (dotted decimal notation). Каждый октет — 8-битное число (от 0 до 255), записанное в десятичном виде. Этот формат используется во всех RFC, хотя формально нет документа, предписывающего именно его.

В стеке BSD реализованы дополнительные экзотические форматы (только для классовых адресов):

• Класс A: октет.24-битное_число — например, 127.1 вместо 127.0.0.1
• Класс B: октет.октет.16-битное_число — например, 172.16.1 вместо 172.16.0.1

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

Несколько адресов на устройстве

На каждом устройстве, как правило, будет много адресов. Важные правила:

• В одну канальную среду на одном устройстве должен смотреть один канальный интерфейс
• Если нужно два интерфейса в одну среду — используйте агрегацию каналов
• На один интерфейс можно повесить несколько IP-адресов (даже из разных IP-сетей)

При наличии нескольких адресов на интерфейсе:

• Один адрес помечается как основной (primary), остальные — как вторичные (secondary)
• Входящий трафик принимается на все адреса одинаково
• Исходящий трафик, для которого не указан явно адрес источника, отправляется из-под основного адреса
• При ответе на входящий запрос используется тот адрес, на который запрос пришел

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

Что дальше

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