История и основы протокола IP: классовая адресация

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

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

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

У нас есть компьютер, у него есть два интерфейса — раз и два. И дальше у нас возникает желание отправить IP-пакет с нашего узла на узел D. Адрес узла D нам каким-то образом известен, например, мы запустили приложение, и пользователь в явном виде этот адрес D вбил с клавиатуры. Когда мы делаем пинг 8.8.8.8. Адрес получателя нам известен, адрес отправителя и все остальное — оно какое-то динамическое, случайно выберется, нас сейчас это не сильно интересует. У нас есть узел D, который мы хотим попингать, и дальше нашему компьютеру — давайте назовем его X — ему надо определить, в какой интерфейс отправляем пакет. То ли сюда, то ли сюда. Нам-то глазками очень хорошо понятно, что надо отправлять направо, потому что узел находится справа, но компьютер про это не знает. Ему надо из двух интерфейсов выбрать один, и он должен это каким-то образом сделать.

Если вдруг он по каким-то причинам поймет, что он не находится с получателем в одном канале, то надо будет опять же принять то же самое решение — в какой из интерфейсов, если у нас их несколько, отправить пакет, и заодно на какой канальный адрес транзитного маршрутизатора отправить такой пакет. Представьте себе ситуацию: у вас есть компьютер, ноутбук, и у него есть, во-первых, Wi-Fi, во-вторых, дырочка для Ethernet, медного Ethernet по витой паре, и, в-третьих, еще свисток торчит 3G-шный, 4G-шный. Фактически три разных интерфейса, и по трем разным интерфейсам можно отправлять пакеты. Когда мы хотим попингать 8.8.8.8, куда именно пойдет пакет? То ли в провод Ethernet, то ли по Wi-Fi, то ли по 4G. В этой ситуации процедура выбора интерфейса, выбора канального адреса будет важна. Кому отправляем и в какой интерфейс? Логика должна быть такая: если мы знаем, где сидит получатель, отправляем напрямую, если мы не знаем, отправляем тому, кто находится ближе к получателю, чтобы он отправил пакет дальше куда-то в сторону получателя.

Для этого нам будет нужно знать IP-адрес получателя и знать Network ID. По крайней мере, наш Network ID. Смысл в том, что если у вас есть несколько узлов, и один узел хочет отправить данные к какому-то другому узлу, который находится с ним в одном канале, он это может очень легко определить. У них Network ID будут одинаковые. У нас есть какой-то IP-шник. У нас есть IP-шник, у него есть левая часть Network ID и правая часть Host ID. И есть какой-то другой IP-шник у получателя. Это Source. Это кто мы. Это destination, кому мы хотим отправить пакет. И у него тоже есть левая часть и правая часть. Как определить, что узлы находятся в одном канале за одним интерфейсом? Сравнить просто левую часть. Если она одинаковая, то мы находимся в одном канале. Если же мы не находимся в одном канале, значит, будет там какая-то дополнительная сложность.

Каким образом этот Network ID будет назначаться и как он будет работать? Назначается он, как вы помните, таким образом, чтобы у всех узлов в одном канале он был одинаковый. Если у вас есть два узла в разных каналах, он обязан различаться у этих IP-шников в двух разных узлах в разных каналах. Мы знаем размер своего Network ID. Как следствие, если мы знаем свой IP-шник и свою левую часть Network ID, и у нас есть какой-то другой IP-шник, у него тоже есть левая часть Network ID и правая часть Host ID, но нам не надо знать, какого размера эти две части будут у узла получателя. Нам достаточно посмотреть того же самого размера левую часть, как у нас Network ID, у получателя. Совпадает она с нашей или нет? Если есть точное совпадение, значит, Network ID у получателя точно такая же, как у нас. Если у соседа Network ID вдруг будет другого размера, то у него левая часть в любом случае будет отличаться.

Значит, нам не надо знать размер соседской Network ID. Нам достаточно знать размер своей Network ID и сравнивать у своего IP-адреса свою Network ID с тем, что находится на месте нашей Network ID у соседа. Если есть совпадение, значит, мы в одном канале. Если совпадения нет, значит, мы в разных каналах. Наш Network ID и его Network ID не совпадают. Смотрите, нам нужно будет определить, находимся мы с ним в одном канале или нет. Если мы находимся в одном канале, сравниваем то, что у нас Network ID, с тем, что у него находится на месте нашего Network ID, и смотрим совпадение. Если есть совпадение, мы в одном канале. Если нет совпадения, у него Network ID какой-то другой. Неважно, какого размера, главное, что он просто другой. Размер этого поля Network ID может быть разным в зависимости от ваших хотелок. Если вдруг вы находитесь в какой-то среде, где мало узлов и не требуется большое количество бит под Host ID, то вы можете сделать Network ID побольше.

Всего у нас размер IP-адреса 32 бита. Если вам вдруг нужно, допустим, 8 бит под Host ID, то вы можете сделать 24 бита под Network ID. Или наоборот, вы хотите, чтобы у вас было много-много узлов в одной сети, поэтому вы делаете 24 бита под Host ID и 8 бит под Network ID. Где проходит эта граница между левой и правой частью, стандарт не указывает. Это в каждом конкретном случае определяется отдельно. Но чем больше вы отводите бит под Host ID, тем меньше у вас получается размер Network ID. Получится, что в среде, в которой много-много компьютеров, вам потребуется много этих битиков, и тогда таких сетей будет мало, потому что Network ID будет маленький. Либо наоборот. Если у вас есть маленькая какая-то сеть, то размер Network ID у нее будет достаточно большой, и получится, что вы можете плодить много-много таких сетей мелкого размера, и таким образом вы можете фактически выбирать тот размер Network ID,

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

Я сейчас рисую 4 подряд адреса. У нас эта Network ID у всех будет одинаковая. Network ID и Network ID. Эта часть — это Host ID, она у всех будет разная. Все узлы, все IP-адреса, у которых левая часть одинаковая, должны находиться в одном канале. Никогда, ни при каких условиях узлы, у которых Network ID такой же, как у нас, не могут находиться с нами не в одном канале. Поэтому все возможные IP-адреса, у которых левая часть будет такая же, как у нас, все-все-все находятся с нами в одном канале, и у них значения Host ID должны пробегать все возможные значения от 0, 0, 0, 0, 0, 0, 0, 0, 0 до 1, 1, 1, 1, 1, 1, 1. Самый первый адрес — у него все биты Host ID будут нулевые. А самый последний будет со всеми битами Host ID единичками. Все промежуточные значения будут здесь присутствовать.

Таким образом, мы можем сказать, что у нас есть некий набор IP-адресов, у которых левая часть одинаковая, а правая пробегает все возможные значения. И два адреса из этой пачки IP-адресов будут использоваться для специальных служебных нужд. Для обозначения самого адреса сети будет использоваться адрес, у которого Host ID содержит все нули. Если мы говорим, что у нас есть некий набор адресов, у которых левая часть зафиксирована, а правая пробегает все возможные значения, то если мы возьмем биты Host ID и запишем их в виде нулей, получится какой-то IP-шник. Например, 192.168.1.0. Это и будет адрес всей сети, или адрес диапазона адресов, у которых некоторые начальные биты зафиксированы, а остальные пробегают все возможные значения. Дальше. Самый последний адрес —

это тот, у которого все биты Host ID будут выставлены в единичку. Он используется для широковещательной рассылки в канале. Смысл этого адреса заключается в том, что он никому конкретно не принадлежит, вы его не можете никому назначить, но все узлы воспринимают его как принадлежащий им. Допустим, у нас есть узел с IP-шником 192.168.1.17. Если мы назначаем этот адрес на конкретный узел, все пакеты, которые будут приходить на 192.168.1.17, он будет говорить: да, это мне, я не выкидываю такой пакет, я его обрабатываю, он мне действительно интересен. И маршрутизатор, который будет доставлять пакеты, он тоже должен быть каким-то образом уверен, что именно до того узла будут доставляться пакеты с таким IP-шником. Но также на него будут доставляться пакеты на адрес 192.168.1.255. 255 — это Host ID из всех единиц. И до него, до 1.17,

до конкретного хоста с таким IP-шником, такие пакеты тоже будут доставляться. И узел с IP-шником 192.168.1.17 будет воспринимать пакеты, приходящие на адрес 192.168.1.255, как на свой собственный адрес. Два адреса в каждой сети будут служебные. Их на хосты назначать нельзя. Классовая адресация заключалась в том, что если у вас есть IP-сеть, всё это internetwork-взаимодействие, которое может обеспечивать передачу пакетов между разными канальными средами, то размер сетей может быть ровно один из трех вариантов. Сегодня мы к этому абсолютно не привыкли. Мы привыкли говорить, что если у нас есть какая-то маленькая сеть, то надо будет выбрать такие адреса, чтобы они максимально эффективно использовали адресное пространство. В 1974 году, когда придумывали протокол IP, не задумывались на тему экономии IP-адресов.

Поэтому размер сетей или позиция этого разделения между Network ID и Host ID могла в тот момент быть в одном из трех вариантов. Первые сети, которые были, первые по порядку в нашем случае, это сети безумного размера. У нас плановый размер сети — безумный. Не знаю, смотрели, может быть, фильм «Космобольцы», «Spaceballs»? Там был такой космический корабль, «Spaceball-1», и он мог перемещаться на скорости света, разумной скорости и безумной скорости. Вот это безумная скорость, безумная сеть класса A. Почему она безумная? Дело в том, что у нее размер поля Network ID был 8 бит, и размер Host ID был 24 бита. 24 бита возможных значений — это 16 миллионов 777 тысяч 216 штук. Два из этих 16 миллионов с копейками адресов будут служебными.

Оставшиеся 16 миллионов 777 тысяч 214 адресов вы должны будете назначать на узлы в одном, если хотите, проводе, в одном широковещательном домене. Вы не можете их использовать где-то в другом месте, помимо одного единственного провода. Если вы хотя бы один адрес из этой сети использовали для хоста в каком-то канале, то все остальные хосты должны тоже быть в этом канале. IP-канал, провод, общий провод, если хотите, на 16 миллионов абонентов — это явление малореальное в современном мире и еще более малореальное для 1978 года. Поэтому эту штуку заложили просто на всякий случай — вдруг когда-нибудь пригодится, вдруг кто-нибудь сделает интрапланетарное взаимодействие со связью через спутник, чтобы спутник на орбите висел над разными абонентами, и в одном канале, в одной среде накрывал бы

большую территорию, в этой территории могло бы быть 16 миллионов абонентов. Для примерно таких раскладов эту штуку придумали. Правда, на тот момент было уже понятно, что это очень маловероятный сценарий — гипотетически, конечно, можно представить себе такой сценарий, что спутник висит и накрывает территорию, но практически это слабо реализуемо. Поэтому таких сетей сделали довольно мало. Договорились, что сетей такого размера много не будет, и договорились, что по внешнему виду такие сети будут отличаться тем, что у них самый первый битик в IP-адресе будет нулевой. Если мы смотрим на какой-нибудь IP-шник, который записан в 32-битном виде, мы смотрим на самый старший битик, если мы там видим ноль, мы говорим: это адрес класса A. Давайте попробуем нарисовать. У нас есть адрес, он состоит из 32 бит. Здесь самый младший битик, здесь самый старший. Если у него самый старший битик нулевой, то это адрес класса A. У адреса

класса А границы между левой и правой частью проходят между седьмым и восьмым, между восьмым и девятым битами. Например, адрес 0.1, 0.1, 0.1, 0.1, и дальше там какие-то 24 бита ещё. Это адрес класса А, потому что у него самый первый бит будет нулевой. И в такой сети может быть 2 в 24-й минус 2 абонентов, то есть дофигища. Несложно посчитать, что если у нас размер поля Network ID — это 8 бит, и причём один бит зафиксирован в 0, то оставшиеся 7 бит могут принимать 2 в седьмой степени — 128 различных значений. Таких сетей безумного размера до 128 штук предусмотрели авторы протокола. Логика была такая, что гипотетически на планете около полутора сотен стран, причём некоторые из этих стран откровенно мелкие, типа Ватикана, Сан-Марино, Монако, Андорры, Сингапура — такие

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

которые не могли начинаться с нолика, поэтому они начинались на битовую единичку. А второй бит — это был нолик. И адреса класса B отличались от адресов класса А тем, что это были сети гигантского размера. У нас большие, гигантские или безумные. Безумные — это просто мусор. У них Network ID 8 бит и Host ID 24 бита. Класс B — это 16 бит под Network ID и 16 бит под Host ID. И таких сетей можно было сделать... 16 384 штуки, потому что 2 бита зафиксированы. Самый старший — единица, и рядом с ним нолик. 2 бита зафиксированы. Из 16 бит Network ID 14 пробегают все возможные значения. 2 в 14 степени — это 16 тысяч сетей. И в каждой сети 65 536 адресов. Два из которых служебные, остальные можно назначать хостам. Сеть на 65 тысяч абонентов уже с некоторой натяжкой

можно себе представить. Пусть даже не всю целиком сеть мы сможем задействовать, но хотя бы на тысячу абонентов — это уже гипотетически реализуемо. Та же самая вышка сотовой связи — она накроет тысячу, две тысячи, десять тысяч абонентов. Это уже хоть что-то похожее на правду, хоть сколько-то приближённое к реальности. Но всё равно 65 тысяч абонентов в одном канале — это перебор. Это тоже выбрасывание адресов на ветер, потому что по факту чаще всего мы всё-таки используем проводные соединения, и если мы используем в проводе какое-то количество абонентов, то у нас не может 65 тысяч адресов быть в одном проводе. Все остальное — адреса класса С. Адреса класса С не могут начинаться на битовый нолик, потому что это тогда был бы адрес класса А. Первый бит у них единичка. Второй бит у них не может быть нолик, потому что это был бы адрес класса B. А третий бит — это нолик.

Адреса класса С начинаются на битовый 1.1.0. И из первых бит, которые относятся к Network ID, три бита зафиксированы. А всего Network ID у адресов класса С занимал 24 бита. И получается 2 в 21 степени — это 2 миллиона таких сетей. В каждой сети у нас 8 бит под Host ID, 256 хостов могло быть адресовано. 254 хоста и два адреса служебных. Это адреса для больших сетей. 256 или 254 хоста в одной сети — это много, но в любом случае это был самый маленький размер, который был предусмотрен авторами протокола. Меньше не смогли придумать. Получалось, что если у вас использовалась классовая адресация, вы по первым битам IP-адреса могли сразу понять, где проходит у этого адреса граница между левой и правой частью. Расплатой за это было то, что сети

могут быть только трёх размеров. Либо большие, либо гигантские, либо безумные. Причём самая маленькая сеть, которую вы могли адресовать, она была просто большой. Как по внешнему виду человекопонятной записи IP-адреса определить, к какому классу адрес относился? Если первый бит был нулевой, то самое маленькое значение — это 0, 0, 0, 0, 0, 0, 0, 0, это ноль, а максимальное — 0, 1, 1, 1, 1, 1, 1, 1, это 127. Если вы видите IP-адрес, и у него первый октет — что-то в диапазоне от 0 до 127, то это адрес класса А. Если вы видите адрес, который начинается на битовый 1, 0, то это будет число от 128 до 191. Если вы видите число в этом диапазоне в первом октете, это адрес класса B. В третьем случае — диапазон со 192 по 223, и это класс С.

Всё остальное — это было адресное пространство класса D, и оно было зарезервировано, использовать его никаким образом было нельзя. Чем хороша была классовая адресация? Тем, что просто на внешний вид IP-адреса посмотрели, сразу поняли, где граница между левой и правой частью. Это один единственный плюс. Всё остальное — это минусы. Сетей мало: у нас даже самых мелких сетей получилось всего 2 миллиона штук. Мы не более 2 миллионов канальных сред можем использовать для связи всех узлов в мире. Потрясающе неэффективное использование адресного пространства. Если мы возьмём и нарисуем числовую ось — мы помним, что IP-адреса — это просто числа — с числа 0 по число 4 миллиарда 295 миллионов с чем-то. 2 в 32 степени минус 1. Где-то здесь число 1, где-то здесь число 2, где-то число

миллион, миллиард и так далее. 4 миллиарда 295 миллионов — это максимальное число. Это соответствует адресу 255.255.255.255. Мы говорили, что эти записи — 4 числа через точку, 4 октета — это человекопонятная запись, на самом деле это просто число, и компьютер работает просто с числами. Сразу можно сказать, что левая половина этого адресного пространства, все числа с нуля по 2 миллиарда с лишним, — это выброшенное впустую адресное пространство. Его по факту использовать сколько-нибудь эффективно невозможно, потому что здесь 128 сетей класса А, в каждой из которых мы реально не можем даже миллионы адресов задействовать. Поэтому если мы будем что-то использовать, какие-то адреса, то это будут реально единичные IP-адреса, которые мы сможем назначить.

Тысячи их будут, две тысячи, пусть даже 100 тысяч, но их тут 2 миллиарда. Поэтому это мы сразу выкидываем. Это половина всего адресного пространства. Этот IP-адрес — 127.255.255.255. А этот адрес — 128.0.0.0. Тоже делим на части. Это адресное пространство класса А, это адресное пространство класса B, и аналогично — адресное пространство класса C и D. D тоже зарезервирован, и в нём вообще адреса использовать нельзя. Это одна вторая, 50% адресного пространства. Это 25% адресного пространства. И этих по 12% адресного пространства. Класс B неэффективно использует адреса, потому что если есть сеть класса B, она позволяет нам адресовать до 65 тысяч узлов.

В реальности, если мы в провод напихаем абонентов, ну 500, ну 1000 абонентов мы сможем в один провод поместить. Поэтому по факту в адресном пространстве класса B тоже адресное пространство используется неэффективно и очень рыхло. Поэтому весь класс B тоже не может быть сколько-нибудь надёжно использован. В реальности только класс C остаётся под использование, под какое-то реальное взаимодействие, в котором можно хоть сколько-нибудь эффективно раздавать адресное пространство. И в итоге выясняется, что из 4 миллиардов с копейками адресов только 12%, примерно полмиллиарда, — это адреса, которые можно как-то использовать. Там их 2 миллиона по 256 адресов в каждом. И получается, что адресов реально мало. И более того, самих сетей мало. Все сети живут в адресном пространстве класса С. Если нам надо 2 роутера между собой связать прямым проводом, вы должны будете на этом проводе на одном роутере IP-адрес повесить и на другом роутере IP-адрес повесить.

Здесь и здесь должны висеть по IP-адресу. На весь этот провод, на всю эту канальную среду вы должны выделить адресное пространство как минимум класса С. И поэтому получается, что если вам нужно point-to-point link сделать, вы должны сюда 256 адресов закопать, и из них 2 повесить на интерфейсы, а 254 ничего с ними не делать — они просто служебные висят, и вы их нигде задействовать не можете. Поэтому даже в адресном пространстве класса С у нас всё равно адреса будут располагаться довольно рыхло. И поэтому в реальности классовая адресация не позволяет нам адресовать в интернете, в глобальной информационной сети, больше чем, по разным оценкам, примерно 100 миллионов абонентов. Как бы мы ни старались, 100 миллионов — это максимум, на который она теоретически способна. В интернете с момента его появления начался бурный рост. В 1981 году у нас появился интернет, началось взаимодействие, и количество используемых адресов стало расти ужасающими темпами на тот момент.

И даже спустя всего 4 года после официального старта проекта уже стало понятно, что классовая адресация не протянет хоть сколько-нибудь долго. Авторы протокола — не авторы, а рабочая группа по вопросам развития интернета — смотрели немножко с запасом вперёд, и понимали, что если рост будет продолжаться такими же темпами, как он начался в 80-х годах, то примерно к середине 90-х годов адресного пространства не останется вообще. И для того чтобы бороться с этой проблемой, стало развиваться несколько направлений деятельности. Первое направление — бесклассовая маршрутизация. Второе направление, появившееся чуть позже, — всякие механизмы типа NAT, механизмы типа IPv6 — следующая версия протокола, которая была бы избавлена от недостатка с дефицитом IPv4-адресов. Ещё одна проблема была связана с тем, что в классовой адресации на каждую сеть

выделялся отдельный Network ID, и про все Network ID вообще все узлы в интернете должны были знать. Каждый узел, который вообще в интернете был, должен был знать, кто где сидит. Это должна была быть строчка в оперативной памяти, и по этой оперативной памяти надо было на лету каждый раз искать, кто где. Сетей класса С, даже если бы мы их плотно запихали, не более чем 2 миллиона. Даже 2 миллиона на начало 80-х годов — это был катастрофически огромный объём информации, который просто невозможно было впихнуть в оперативную память. Количество оперативки на тот момент исчислялось обычно килобайтами. Если у нас 2 миллиона записей в таблице, кто где сидит, то даже если мы на каждый Network ID хотя бы 1 байт информации будем хранить, это будет 2 мегабайта информации. На тот момент просто недостижимо большой объём, который не могли переварить тогдашние маршрутизаторы, тогдашние коммутаторы.

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

У нас есть IP-адрес получателя 172.16.32.0. Что в этой ситуации делает компьютер, который хочет принять решение, куда отправлять такой пакет? С выбором канального адреса мы сейчас пока не будем заморачиваться, а вот как определить интерфейс, куда будет отправляться пакет? Берём свой первый интерфейс просто по списку. У нас на интерфейсе висит IP-адрес 192.168.1.1. Это адрес класса С. Мы по 192 хорошо это видим, потому что 192 — это число, которое начинается на битовый 1.1.0. Это адрес класса С. У него левая часть вот такая по размеру, а правая — 8 бит. И мы берём и сравниваем левую часть своего IP-адреса с такой же по размеру левой частью IP-адреса получателя. И видим, что совпадений нет. Узел 172.16.32.0 с нами не находится в одном канале с интерфейсом 192.168.1.1.

Дальше делаем то же самое со всеми остальными интерфейсами. У нас есть адрес 172.16.1.1. Должны определить, находится ли с нами узел в одном канале — 172.16.32.0 — или нет. 172.16 — это адрес класса B. Он начинается на битовый 1.0. Мы берём левые 16 бит. У класса B 16 бит на Network ID. Сравниваем с 16 левыми битами адреса получателя. И видим, что есть совпадение. С нами в одном канале за интерфейсом 2 находится напрямую получатель. Мы отправляем напрямую ему в этот интерфейс пакет. Если вдруг получатель находится в другом канале, не в одном общем канале с нами, то мы должны будем принять решение, к какому транзитному маршрутизатору мы отправляем пакет. И для этого нам придётся знать вообще все сети в интернете — за какими интерфейсами, за какими маршрутизаторами они находятся. Нам придётся это делать. Нам придётся на каждом узле знать всё про всех.

Допустим, у нас есть IP-адрес получателя 10.255.255.254. И у нас тот же самый компьютер с такими же IP-адресами: 192.168.1.1, 172.16.1.1. Он посмотрел: 192.168.1 — не подходит. 172.16 — не подходит. Он принял решение, что ни через один интерфейс напрямую до получателя достучаться не получится. Значит, он берёт, открывает свою табличку, в которой он знает всё про всех, и начинает проверять. Первая строчка в этой табличке: есть сеть 10.0.0.0. Этот адрес сети — мы уже говорили, что для обозначения самой сети используется такой IP-адрес, у которого левые биты Network ID зафиксированы вместе со всеми остальными узлами в этом же канале, а правые биты зафиксированы в нуле. В нашем случае мы говорим 10.0.0.0. Это адрес класса А, следовательно, у него Network ID 8 бит, и действительно мы видим, что правые 24 бита зафиксированы в нуле. Проверяем.

10. Совпадение есть. Эта сеть действительно содержит IP-адрес 10.255.255.254. Никакая другая классовая сеть не может содержать такой IP-адрес. Поэтому если мы нашли совпадение, мы на этом останавливаемся, и дальше уже остальное не проверяем. Мы говорим, что эта сеть доступна за интерфейс M1, и по-хорошему здесь должно ещё быть указание, какой конкретно маршрутизатор, если вдруг их там несколько, используется для доставки трафика в эту сеть 10.0.0.0. По-хорошему. Дальше. Если вы просто обычный узел, то вообще все сети в мире, как правило, у вас будут доступны за всего одним маршрутизатором. Обычная нормальная ситуация: у нас есть маршрутизатор, он подключён к длинному жёлтому коаксиалу, в котором сидят абоненты. И вообще все сети в мире доступны через этот самый маршрутизатор. Ни при каких условиях мы не должны будем направлять трафик куда-либо,

кроме как до маршрутизатора, который уже знает, как добраться до всех остальных сетей. У него есть понимание, что одни сети слева, другие справа, третьи сверху, четвёртые снизу. Но для всех этих абонентов точка входа в весь остальной мир в любом случае будет этот маршрутизатор. Вы, вообще-то говоря, должны будете знать про все сети в мире, в какую сторону они находятся. Но если вы просто обычный узел и у вас все сети в мире доступны через один и тот же транзитный маршрутизатор, то вы можете немножко схалявить. Вы можете сказать, что у вас есть некая классовая сеть, и эта классовая сеть смотрит в определённую сторону. Как можно добраться до некоторой конкретной классовой сети — пойти вон туда, через тот интерфейс, возможно, через того соседа. И вы можете её пометить как так называемую сеть по умолчанию. Берёте классовую сеть, одну какую-то конкретную, например 172.16.0.0 —

классовая сеть класса B. Вы её взяли и пометили звёздочкой. И эта помеченная звёздочкой сеть будет указывать на то, что если вдруг у нас есть много-много сетей, которые смотрят все в одно и то же направление, и это направление совпадает с сетью, помеченной звёздочкой, то все остальные сети можно не писать. Они все такие же. Мы берём табличку, перебираем эту табличку по списку. Если находим явное совпадение в табличке, окей, у нас есть совпадение, мы обрабатываем пакет так, как он должен был обрабатываться. А если совпадения нету, то мы повторно перебираем табличку, находим сеть со звёздочкой. И говорим, что если не получилось найти явное совпадение, то мы отправляем пакет по маршруту сети по умолчанию. Такая табличка «Кто где сидит?» она есть абсолютно у всех. Если вы просто обычный абонент, у вас в этой табличке может быть халявка в виде сети со звёздочкой. Если вы транзитный маршрутизатор,

и у вас есть левая половина интернета и правая половина интернета, и вы не можете сказать, что все сети в мире находятся в одном направлении, потому что половина интернета тут, а половина интернета тут, то вы так схалявить уже не можете. Вы должны будете про всех всё знать прям по-честному. И здесь возникает как раз проблема в классовой маршрутизации, что 2 миллиона сетей класса C, одних надо знать, где они находятся, и у маршрутизаторов столько памяти просто нету, и никогда не было. Вот пример того, как это могло выглядеть. У нас тут такая, в кавычках, корпоративная сеть. Есть обычные абоненты. У них таблица маршрутизации практически вырожденная. Там есть только одна сетка, которая к ним непосредственно напрямую подключена. Например, 12.0.0.0. И она же сеть со звёздочкой. И весь трафик, который мы будем посылать, мы будем посылать в интерфейс Ethernet 0 на этом компьютере. Потому что у нас другого варианта просто нет.

У нас есть своя сетка 12.0.0.0. Здесь 12.0.0.1 — это на роутере IP-шник. 12.0.0.2 — наш собственный IP-шник. Если вдруг мы будем посылать какие-то пакеты узлам, начинающимся на 12, вот здесь они могут жить. Больше им негде жить. А любые другие пакеты мы тоже туда же посылаем, потому что у нас других вариантов просто и нет. То же самое происходит тут, то же самое происходит здесь. На обычных абонентах у нас есть всего одна дырка, куда можно посылать трафик. И что там с таблицей, что без таблицы, всё равно результат будет одинаковый. Что касается транзитных роутеров, например, у нас есть вот этот товарищ. У него получается есть две сети. Одна сеть тут и другая сеть тут. А есть ещё все остальные сети помимо этого. И он про эти две сети будет знать. Он говорит, есть одна сетка, начинающаяся на десятку. Вот она здесь. Есть сетка 112.168.1.0. Вот она здесь. И все остальные сети тоже находятся здесь.

Если вдруг я хочу направить трафик именно на десятку, я направляю на Ethernet 0. Если я вдруг хочу направить именно на 112.168.1, я направляю вот сюда. И если я хочу куда-либо ещё направить трафик, я всё равно направляю вот сюда. И третий роутер, он здесь самый сложный, который находится в центре всего этого безобразия. Это будет вот этот товарищ. У него есть сетка 12-я connected. У него есть сетка 11-я connected. Если он хочет направить трафик на 11-ю сетку, на 12-ю сетку, у него прямо напрямую есть интерфейсы, которые в эти сети смотрят. Там можно найти напрямую получателей. У него есть сетка 112.168.1.0. Она тоже connected на интерфейсе Ethernet 3. И у него есть 112.168.0.0. Эта сетка, которая смотрит на какой-то провайдерский роутер. Там Ethernet 0. Есть указание, что вообще все сети в мире доступны через этот самый провайдерский роутер.

Поэтому эта сетка помечается звёздочкой. Если вдруг мы хотим направить трафик не на 11-ю, не на 12-ю сеть, не на 112.168.0, а на какой-то там 8-8-8-8, то мы направляем пакет по маршруту со звёздочкой. Default Route. И пакет уходит вот сюда. Есть нюанс, который заключается в том, что если вдруг нам надо на десятку трафик отправить, то нам надо не через интернет это отправлять, а через эту сеть. Поэтому отдельное указание: десятка доступна через интерфейс Ethernet 3, там же, где эта сетка. Таким образом таблица маршрутизации выглядела. И если вы находились в транзите между какими-то сетями, то вам про все свои собственные сети, которые через вас могли ходить, вы должны были через себя пропускать их трафик и знать, где они находятся, как вам возвращать трафик обратно. Таким образом это всё дело и выглядело. Так, про бродкаст. Я уже сказал, что есть специальный адрес,

который заканчивается на все битовые единички, но на самом деле есть два вида бродкаста. На экзамене вряд ли про это будет вопрос, но знать это, пожалуй, стоит. Первый вид бродкаста, я уже сказал, что это адрес, который заканчивается на все битовые единички. Это так называемый directed broadcast. И у него network ID такой же, как у всех остальных, и host ID — все единички. Это маршрутизируемый адрес. Если вдруг вы будете пропускать такие пакеты через маршрутизаторы, они нормально проходят. Это нормальный полноценный айпишник. Если вдруг вы увидите айпи-пакет, который идёт на адрес, destination адрес, 11.255.255.255. 11.255. И так далее. То нормальный пакет, он дойдёт до получателя. Он по табличке промаршрутизируется. И когда он дойдёт до маршрутизатора, который в этот канал смотрит напрямую, у которого такая сеть connected, он просто отправит этот пакет в среду, и эта среда сама распространит такой пакет на всех получателей.

Условно говоря, свитч, если тут свитч, он его разбросает на все свои порты, потому что там тоже будет бродкаст FFFF. И бывает ещё один вид бродкаста, local broadcast. Это просто айпишник, состоящий из всех единиц. Вообще говоря, он относится к классу D. Это, вообще говоря, диапазон зарезервированный, но именно этот айпишник может быть использован. И это немаршрутизируемый бродкаст. Он отправляется только в пределах своего канала. Если вы отправите на этом роутере пакет на адрес 255.255.255.255, то его получат только соседние роутеры, больше никто. И он не промаршрутизирует его дальше. Все узлы обязательно присоединяются к своему directed broadcast. Вы назначаете айпишник 11.0.0.1 на узел, он сразу считает, в какой сети он находится, он понимает, что его network ID — 11, и говорит: я сейчас возьму и посмотрю, что я нахожусь в сети 11.0.0.0, и я присоединяюсь к бродкасту 11.255.255.255.

И то же самое делает второй узел. Он говорит: у меня адрес сети 11.0.0.0, и я присоединяюсь к бродкасту 11.255.255.255. И поэтому по факту назначения айпишника на узел, вы сразу как узел понимали, к какому бродкасту вам следует присоединиться, какой бродкаст начинать слушать. Естественно, 255.255.255.255 слушают вообще все. Так, давайте на сегодня закончим. И следующая тема, которая у нас будет, это будет бесклассовая адресация, которая по факту используется сегодня в 100% случаев. То, что мы сейчас разобрали, будет являться основой для неё. Поэтому, несмотря на то, что то, что мы сейчас разобрали, не используется в современном мире, оно является основой для того, что используется. И мы как раз это и разберём. Уже в следующем модуле.