h8tr

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

Свойства IP-адресов

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

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

2. IP-адрес назначается на канальный интерфейс устройства.

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

4. IP-адрес состоит из двух частей:

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

   • вторая часть IP-адреса – это номер узла или идентификатор хоста (Host ID), номер узла должен быть разным для всех узлов внутри одной сети, но может повторяться, если узлы находятся в разных канальных средах.

5. На текущий момент границу между номером сети и номером узла проводит маска подсети. Если вы не знаете маску подсети, то не сможете сказать: где у IP-адреса номер хоста, а где номер сети.

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

Номер сети и номер хоста

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

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

Все вышесказанное продемонстрировано на этой картинке.

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

Сколько IP-адресов может быть на устройстве?

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

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

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

Как записать IP-адрес

Разбираться будем с формами записи в десятичной системе счисления. Если вы выходите в интернет, то, наверное, видели IP-адреса, например, 192.168.0.1. Читатель может заметить и спросить, ну и чего тут рассказывать, вон на экране написано 192.168.0.1, это и есть форма записи IP-адреса, которая всем понятна и удобна. Я бы мог в свою очередь сказать, что это стандартная форма записи, но, насколько мне известно, в спецификации IP стандартная форма записи никак не описана.

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

Для начала запишем форму записи для 192.168.0.1 в общем виде:

А теперь давайте запишем в этом виде самый маленький и самый большой адреса:

Переведем их в двоичный вид:

В двоичном виде вместо точки я использовал пайп. Самый маленький адрес в двоичном виде представляет собой тридцать два нуля, самый большой тридцать две единицы, комбинции нулей и единиц между двумя представленными выше крайностями это все остальные IP-адреса. Фактически IP-адрес это число 32 бита, оно же может быть и десятичным. Вопрос в том, как нам записать адрес в десятичном виде одним числом и можно ли это вообще делать?

Для примера давайте пропингуем Яндекс:

Яндекс доступен по адресу: 5.255.255.242. Давайте переведем адрес в двоичный вид, каждый октет по отдельности:

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

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

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

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

Получилось число 100 663 282. Давайте его пропингуем.

Видим, что винда привела этот номер в привычный нам вид, всё успешно пропинговалось. Здесь может возникнуть справедливый вопрос: почему это мы вместо того чтобы использовать простые и понятные числа, переводим их в двоичный вид, разрезаем одно большое число на четыре куска по восемь бит, потом преобразуем эти восьмибитные двоичные числа обратно в десятичные и только потом записываем IP-адреса? Если коротко, то в таком виде удобнее разрезать сети на подсети или же наоборот (человекам, а не комплюхтерам): объединять маленькие сеточки в одну большую, если более детально, то будет отдельная тема о масках подсети.

Две не очень популярные формы записи

Я знаю еще две формы записи, которые, как я слышал, пришли из систем BSD. В общем виде их можно записать так:

Я ни разу не видел, чтобы их кто-то использовал в каких-то рабочих целях, но вдруг вы столкнетесь. Винда понимает эти формы, вот для примера пинг 8.8.8.8.

Итого у нас имеется четыре формы записи IP-адреса:

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

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

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

Вопросы для ваших ответов

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

1. Какое число больше 8.234.255.12 или 9.0.0.0?

2. Зачем IP-адресу точки?

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

4. Какой байт пропущен для адреса 1.1.1 (слева от центральной единицы или справа)?

5. У нас есть локальная сеть(не интернет), в сети есть узлы, кто этим узлам выдает IP-адреса?

6. Нужен ли роутер для взаимодействия между узлами одной подсети?

7. Схема: к Wi-Fi роутеру подключено два ноутбука по Wi-Fi, все три устройства в одной подсети, пингуем с первого ноутбука второй. Вопрос: как физически будут передаваться данные, напрямую между двумя ноутбуками или через роутер и почему?

Видео версия

Тем, кому лучше смотреть, чем читать.

Теоретическая теория здесь

Про формы записи адресов и пинги тут:

Задачи узла отправителя

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

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

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

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

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

Вроде бы никаких хитрых действий отправитель не совершает.

Задачи узла получателя

Задачи получателя несколько более простые:

1. Пакет нужно получить и убедиться в двух вещах:

   1. Получатель должен убедиться, что именно он является получателем.

   2. А также проверить корректность полученных данных.

2. Далее данные передаются вышестоящему процессу, который уже решит что с ними делать.

Если получатель сочтет нужным, то он в дальнейшем может послать ответ отправителю.

Задачи маршрутизатора (транзитного узла)

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

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

2. Далее требуется определить какому из соседей по канальной среде следует передавать пакет. Если роутер в одной канальной среде с получателем, то пакет будет передан непосредственно ему, если же нет, то следующему транзитному узлу.

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

4. Если требуется модификация пакета, то пакет модифицируется, а затем отправляется в выбранный интерфейс.

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

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

Топология и подготовка лабы

С теорией всё, давайте соберем простенькую лабу и посмотрим на IP устройства в эмуляторе. Для практики по данной теме буду использовать CPT. Пока мы ничего не будем настраивать, просто посмотрим, что эмулятор будет нам рассказывать о действиях узлов.

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

Пояснения к схеме:

1. Оранжевым обведены хосты.

2. Зеленым роутеры.

3. Синим коммутатор, в данном случае мы его не рассматриваем как IP-устройство, сейчас можно представить, что это не коммутатор, а связка проводов, которая соединяет PC2, PC3 и RO2 вместе.

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

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

Кнопка Edit Filters отвечает за появление окна на скрине выше, на вкладках IPv6 и Misc тоже нужно отключить отображение всех прочих пакетов.

Взаимодействие отправителя и получателя

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

Выполним пинг с PC2 на PC3, нужно открыть командную строку PC2 сделать это можно так:

1. В топологии кликаем на иконку PC2.

2. Появится окно, в котором нужно будет выбрать вкладку Desktop.

3. На вкладке Desktop выбираем иконку Command Prompt.

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

После того, как мы ввели команду и нажали Enter, PC2 сформировал два пакета:

1. Синий, это как раз тот пакет, который нас интересует, то есть ICMP.

2. Зеленый, это кадр с ARP запросом, он нам не интересен, сейчас нам лишь важно понимать, что протокол ARP поможет PC2 узнать канальный адрес узла PC3, в данном случае это мак-адрес.

Посмотрим содержимое синего пакета, клацнув в него.

Появившееся окно имеет две вкладки: OSI Model и Outbound PDU Details. Нам интересна первая, вторую даже смотреть не будем, на ней представлена детальная информация о структуре кадров и пакетов, она нам сейчас не интересна.

На вкладке OSI можно по шагам посмотреть что делает тот или иной узел при приеме или отправке пакета. За прием отвечает In Layers, за передачу отвечает Out Layers. Как видите, каждая половина разбита на семь уровней, это семь уровней модели OSI, если шрифт уровня тускло серого цвета, значит на нем ничего не происходит, если шрифт черный, значит на этом уровне что-то происходит и он кликабельный, переключаться между уровнями можно еще и кнопками Previous Layer/Next Layer.

На рисунке выше CPT нам показывает, что делает узел отправитель(PC2) на сетевом уровне :

1. PC2 запустил процесс Ping сразу после того, как мы выполнили команду ping.

2. Процесс Ping создает сообщение ICMP Echo Request и отправляет его нижележащему процессу. Здесь следует пояснить, что ICMP и IP это протоколы сетевого уровня, но для ICMP процесс IP это нижележащий процесс.

3. Отправитель должен подставлять в пакет свой IP-адрес, чтобы обратная сторона могла ответить, если она сочтет это нужным. При выполнении команды ping не был задан IP-адрес, поэтому устройство выбрало адрес само (оптимальный на взгляд устройства, хотя по факту он там настроен один).

4. PC2 установил, что IP-адрес узла получателя находится с ним в одной подсети, а также в пакет был добавлен IP-адрес узла получателя.

А вот что CPT нам может рассказать о канальном уровне.

На канальном уровне:

1. Узел PC2 определил, что IP адрес получателя юникастовый, а это значит, что узел должен знать или определить мак-адрес получателя. Чтобы определить канальный адрес соседа узел запустил процесс ARP.

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

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

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

1. ARP-запрос PC2 использует, чтобы изучить канальный адрес соседа, в сторону которого должен быть отправлен пакет с ICMP.

2. ARP-запрос получат все соседи PC2 по канальной среде, но ответ даст только тот сосед, чей IP-адрес будет указан в ARP-запросе, все остальные проигнорируют этот ARP-запрос. И тут два момента: если соседей с таким IP нет, то никто и не ответит; если сосед с таким адресом есть, то он ответит, в ответе будет содержаться его мак-адрес.

Вот что по этому поводу нам показывает CPT:

Узел RO2 получил запрос и проигнорировал его, это видно по красному крестику, а вот узел PC3 готов ответить на запрос. Что делает PC3 для отправки ARP мы пропустим, но в итоге мы приходим к той ситуации, что узел PC2 получил ARP ответ и изучил мак-адрес соседа, в сторону которого надо отправить пакет.

Зеленый пакет ниже это и есть ARP-ответ PC3, а синий пакет, это тот ICMP, который ранее был спрятан в буфер.

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

Напомню, что остановились на том, что у канального уровня не было мак-адреса соседа, в сторону которого надо было посылать пакет, теперь мы этот адрес знаем, поэтому:

1. ICMP пакет был извлечен из буфера для дальнейшей обработки.

2. PC2 инкапсулирует(помещает/запаковывает) IP пакет, внутри которого ICMP, внутрь Ethernet кадра.

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

А на L1 мы видим, что отправитель выбрал свой интерфейс, через который он будет готов послать сообщение в сеть, на физическом уровне Ethernet кадр превращается в последовательность бит.

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

Здесь мы видим изменения:

1. На вкладке OSI появилось описание того, что происходит на приеме, т.е. теперь у нас информация по In Layers и Out Layers.

2. Вкладок PDU Details тоже стало две.

Сейчас мы не будем заходить на вкладку из пункта два. Что касается первого пункта: PC3 должен сперва принять пакет, т.е. выполнить действия получателя, они описаны под заголовком In Layers, а затем он должен будет дать ответ, т.е. PC3 становится отправителем, что он делает для ответа описано под заголовком Out Layers.

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

Здесь узел PC3 убеждается:

1. Что мак-адрес это мак-адрес, который присвоен одному из интерфейсов PC3, либо это широковещательный мак-адрес, любо это мак-адрес многоадресной рассылки, на который должен отвечать PC3. По факту в данном случае мак-адрес юникастовый и он принадлежит PC3.

2. Ввиду того, что мак-адрес назначения, указанный в кадре, принадлежит PC3, можно снять Ethernet заголовок и заглянуть и обнаружить под ним IP-пакет.

Переходим на сетевой уровень.

Здесь происходит следующее:

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

2. Внутри пакет обнаружилось ICMP вложение, которое надо передать процессу ICMP.

3. ICMP процесс установил что тип полученного сообщения это ICMP Echo Request, на который нужно дать ответ.

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

Действия узла такие:

1. ICMP процесс решает что на данный Request следует ответить сообщением типа ICMP Echo Reply.

2. Сообщение Echo Reply отправляется процессу IP.

3. Узел видит, что IP-адрес назначения находится в одной подсети с ним, а значит пакет можно отправлять непосредственно получателю.

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

1. PC3 установил что IP-адрес назначения юникастовый, а значит надо запустить ARP процесс для того, чтобы узнать канальный адрес соседа.

2. Мак-адрес соседа находится в ARP-таблице, поэтому в дальнейшем в Ethernet-кадр в поле мак-адрес назначения будет подставлен мак-адрес, соответствующий IP-адресу 192.168.0.2, взятый из ARP-таблицы.

3. IP-пакет накрывается Ethernet-заголовком, тем самым формируется Ethernet кадр.

На физическом уровне ничего интересного нет, PC3 для отправки выбрал интерфейс Fa0, превратил кадр в битовую последовательность, которая и была направлена в сеть. В итоге ответ PC3 дойдет до PC2 и когда PC2 получит этот ответ, произойдет изменение в командной строке, появится диагностическая информация о том, что узел PC3 доступен.

Исходный отправитель превратился в получателя. Получение пакета на канальном и физическом уровнях для PC2 ничем не будут отличаться от действий на PC3, поэтому оставляю этот момент без комментариев. Вот что происходит на сетевом уровне уровне:

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

2. Под заголовком обнаруживается ICMP вложение, оно предается ICMP процессу.

3. ICMP процесс видит, что это Reply на Request, посланный ранее.

4. Процесс Ping получает от ICMP сообщение Echo Reply, в этом сообщение содержится диагностическая информация, которая затем отображается на экране командной строки.

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

По итогу:

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

2. Поверхностно разобрались с тем, как связаны канальный и сетевой уровни.

3. И убедились, что функции отправителя и получателя может выполнять одно и то же устройство.

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

Видео версия

Вот здесь теоретическая часть:

Вот здесь про прямое взаимодействие хостов:

p.s. Вопросы на подумать к данной теме смотрите в конце поста со второй частью.

Словосочетание "не гарантирует доставку пакетов" немного раскрою:

• пакеты на сети теряются, потерянный пакет IP не будет пытаться восстановить или повторно переслать, если IP-пакет потерялся, то он потерялся, средств по восстановлению пакетов или повторной их пересылки в IP нет;

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

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

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

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

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

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

Ограничусь лишь сегодняшним днем. У нас существует две актуальные версии протокола IP: IPv4 и IPv6. Работают они практически одинаково, на начало 2024 года могу сказать, что IPv4 будет еще долго актуальным, изучение немного проще начать с него, поэтому здесь и далее, если я пишу IP, то имею ввиду именно IPv4.

Ресурсы для изучения IP и вообще сетевых технологий

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

Во второй список вошли:

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

2. Пособия по подготовке к экзаменам вендоров, сам вендор не важен: HP, Cisco, Juniper, Huawei или любой другой.

3. Статьи и публикации в интернете, желательно на открытых для стороннего мнения площадках, например, Хабр.

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

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

Вот некоторые RFC для IP:

• RFC 791 это спецификация протокола IP;

• RFC 5737 содержит в себе перечень блоков IP-адресов, зарезервированных документации;

• RFC 919 это правила распространения широковещательного трафика;

• RFC 1918 описывает блоки IP-адресов, которые можно использовать в частных сетях;

• RFC 1122 описывает требования к программной реализации хостов на сетевом, канальном и транспортном уровнях.

На самом деле RFC огромное множество, есть и шуточные, которое, например, описывает работу протокола IP поверх голубиной почты RFC 2549.

Для тех, кому нравится больше смотреть:

https://www.youtube.com/watch?v=IzPgASpMG0Q&t=

p.s.

в завершении следующих постов буду стараться придумать 2-3 вопроса.

p.p.s.

Следующий пост о видах IP устройств и о том, чего они там такого делают. Готовлю, кнопка принтскрина потихоньку стерается :)