Введение в протокол IP

Мы с вами продолжаем курс ICND1. И если на предыдущих занятиях мы с вами разбирались с тем, как устроен протокол Ethernet, то сегодня мы начинаем новую тему. И эта новая тема называется протокол IP. Так же, как Ethernet, протокол IP очень популярен. Так же, как Ethernet, он вытеснил с рынка конкурирующие протоколы, которые использовались для, соответственно, схожих целей. То есть, если Ethernet у нас вытеснил с ринга всякий токен ринг и прочее, то вот IP вытеснил, например, Novel NetBIOS из того, что... Novel IPX, простите, NetBIOS. Из того, что в реальности могло бы составить ему конкуренцию. И даже более того, на самом деле, в какой-то момент времени в индустрии все были уверены, что он проиграет борьбу за право стать конкур... Как это сказать? За право стать основным протоколом и даже единственным протоколом, который можно использовать в современных сетях, потому что за его продвижением никто особо не стоял.

У того же IPX была компания Novel. Это был огромный монстр, у которого были практически неограниченные бюджеты, который мог инвестировать в развитие протокола практически неограниченное количество денег. Ну и в свое время этот протокол был нежнолюбим компаниями, которые использовали его в своих локальных сетях. Но у него было все-таки не очень удобно реализовано взаимодействие между сетями, особенно глобальное, на уровне того, что мы сегодня могли бы назвать интернетом. То есть на основе протоколов, которые существовали давным-давно, кроме IP, практически такую структуру, которая напоминала бы современный интернет, построить было бы практически невозможно. Давайте разбираться, что это за протокол такой волшебный, каким образом его рождали в MOOC и что, собственно говоря, в итоге родили. Это протокол межсетевого взаимодействия, то есть протокол практически изначально созданный для того, чтобы соответствовать требованиям модели TCPIP или модели DOD. Помните, да, там четырехуровневая модель, которую американцы придумали в 1969 году.

Вот этот самый протокол практически специально создавался для этой модели. На тот момент, когда модель DOD в 1969 году создавалась, протоколов, которые бы целиком и полностью удовлетворяли требованиям этой самой модели, особо не было. Поэтому вендоры были вынуждены разрабатывать некие костыли, которые бы подходили под требования заказчика, под требования американских военных. Ну и сами американские военные при этом тоже не сидели без дела. Они запустили специальный департамент перспективных исследований, DARPA, и в этом самом департаменте перспективных исследований пытались предположить, а какие именно протоколы могут быть им полезны. То есть не просто, чтобы вендоры что-то там свое придумывали и потом приходили и говорили, вот покупайте у нас вот это. А именно сами протоколы, которые не были привязаны к каким-то конкретным вендорам, американцы пытались придумывать и самостоятельно в рамках вот этого самого американского Министерства обороны департамента перспективных исследований.

Надо заметить, что у IP был предшественник, это протокол NCP. Не путайте с тем NCP, которые есть в PPP, если вдруг вы знаете, про что я. Ну, соответственно, да, был вот протокол NCP, Network Control Protocol, и этот протокол использовался в сети, которая называлась ARPA.NET. ARPA — это вот как раз департамент перспективных исследований, ну и, соответственно, DARPA — это департамент перспективных исследований. Вот они сделали свою маленькую сеточку, из чего попало, и запустили там протокол NCP. Ну и потом на основе этого протокола начали думать, а что же получилось хорошо и что получилось плохо. И ряд молодых ученых, которые работали в этом департаменте перспективных исследований, и на него, то есть они напрямую не были американскими военными, но они работали в интересах американских военных, они анализировали то, что получилось в итоге с NCP и предложили какой-то другой протокол, который был бы похож на NCP, решал те же самые задачи, но не содержал бы его ошибок.

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

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

там, условно говоря, 60-х годов, это все были протоколы обмена данными, которые использовали вот как раз телефонные линии. Если вам надо было передать сигнал из Seattle в Флориду, вы дозванивались, и дальше вы получали прямую электрическую цепь, поверх которой вы передавали данные в нужном вам формате. То есть вы особо не заботились тем, что именно за формат передаваемых данных было. У вас было приложение с одной стороны, приложение с другой стороны, и фактически, да, прямой провод между ними, который для вас строила телефонная компания в тот момент, когда вы дозванивались до другого конца провода. Вы клали трубку, и дальше цепь, которая для вас построила телефонная компания, она разваливалась на отдельные составляющие, этим отдельные составляющие, отдельные провода могли быть использованы для какого-то другого звонка, который уже кто-то другой бы совершил, ну, возможно, в том же самом направлении. Так, я к чему все это рассказываю? Да, в тот момент, когда протокол IP появился, стандартом было просто вот прямое взаимодействие.

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

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

это, соответственно, ну, нельзя было сделать в общем случае, потому что звонок у вас прокладывался всегда по одной и той же трассе. А вот на уровне пакетов, соответственно, это становится возможно. Если вдруг вы хотите передавать сигнал между какими-то точками, которые не напрямую между собой связаны, но через цепочку транзитных узлов, вот эти транзитные узлы, соответственно, будут передавать данные друг между другом, и они смогут работать неким определенным образом. Сейчас попробую нарисовать, что я имею в виду. Это у нас какая-то такая схема Соединенных Штатов. Вот здесь у нас условный там Сиэтл, здесь у нас условный Нью-Йорк, здесь у нас Лос-Анджелес, здесь Флорида, а здесь какой-нибудь Техас. Вот. И они вот так вот как-то соединены между собой. Так. И вот нам нужно из условного там Сиэтла во Флориду передать сигнал. Мы направляем пакетик вот сюда вот, дальше в Техасе мы должны направить пакет напрямую, но здесь вот у нас вот эта вот линия,

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

Это нормальная ситуация, это не является каким-то криминалом с точки зрения IP. IP должен выживать в таких условиях. Пакеты могут теряться по дороге. Опять же, потому что может быть такое, что вот мы отправили пакет на вот этом роутере в Техасе, дальше нужно понять, что с ним делать, вот мы видим, что у нас вот здесь вот все взорвалось, надо его направить в Нью-Йорк, но тут прибегает вторая бомба и разносит в клочья, что ж такое-то, разносит в клочья сам роутер техасский. Вот мы ничего про это не знаем. Так, почему у меня постоянно перескакивает слайд? Не понимаю. Мы ничего про это не знаем, отправитель ничего про это не знает, он никак не может проконтролировать процесс, чтобы пакет дошел до получателя, поэтому принцип работы IP это вот отправить пакет и все. Дальше IP забывает полностью про то, что такой пакет существовал, IP никак не контролирует трассу, по которой он идет, то есть отправил и забыл. И дальше, если пакет дойдет до получателя, это хорошо. Если пакет не дойдет до получателя, ну, как говорят французы,

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

Через пятый и шестое ультро. И может быть такое, что первый отправляет пакет на второй, второй отправляет пакет на третий, третий отправляет пакет на четвертый, и всё, он доходит корректно до получателя. Тут между вторым и третьим связь в какой-то момент рвётся. Второй пакет, который отправляется, он идёт от первого до второго, дальше от второго до пятого, от пятого до шестого, от шестого до третьего, от третьего до четвёртого. Время, которое пакет прошёл по сети, оно будет существенно выше. Время, которое требуется пакету для прохождения по сети, оно будет существенно выше по сравнению с первым пакетом. И потом гипотетически можем себе представить такое, что третий и следующий пакет, который будет идти, он снова пойдёт напрямую между вторым и третьим. И у нас может быть такое, что время, которое потребуется двум разным пакетам для передачи по сети, будет разным. Каждый пакет по сети может пройти по разной трассе. И может быть даже такое, что если вдруг у вас, например, первый, второй и третий пакет были отправлены

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

И мы можем условно сказать: всё равно, что произойдёт дальше, после того, как этот пакет дойдёт до получателя. Потому что этот пакет нужен для того, чтобы запустить машину судного дня. И мы можем сделать очень простую вещь. Мы можем отправить пакет, который должен разослаться по всем интерфейсам. Мы не будем выяснять, куда этот пакет надо отправить, что с ним сделать. Он просто по всем интерфейсам пусть отправится. И если есть хоть какой-то, хоть малейший способ доставить этот сигнал до получателя, полезные данные до получателя, то это в обязательном порядке сработает. И мы отправляем одну копию пакета в одну сторону, другую в другую, третью в третью. Дальше второй роутер то же самое делает. Он говорит: я отправлю копию одну сюда, одну сюда, одну сюда. Да, мы знаем, что в Ethernet в аналогичной ситуации возникает петля. Мы знаем, что в Ethernet в такой ситуации возникает петля, и сетка у нас там дохнет. Но опять же, для работы Doomsday Machine,

машины судного дня, это всё роли не играет. Она просто взрывает всю планету, и дальше те, кто успел себе найти другую планету, те молодцы. А на этой планете и сетка будет с петлёй, и радиоактивный пепел будет весело спускаться с неба. Так что в определённой ситуации авторы протокола предположили, что может быть такое будет полезно. И в этой ситуации, да, пакеты могут задублироваться. Мы отправили копию пакета на все интерфейсы. Может быть такое, что к нам по какому-то другому интерфейсу этот же пакет придёт в обратную сторону. Что же делать? Такова жизнь. Далее. IP разрабатывался, как уже было сказано, практически адресно под модель TCP/IP. Название этого протокола, интернет-протокол IP, оно следует из названия сетевого уровня модели TCP/IP, то есть протокол межсетевого взаимодействия.

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

которые бы обеспечили межсетевое взаимодействие. Такое образцово-показательное. Ещё раз подчеркну, чтобы не вендоры предлагали стандартные механизмы решения проблем, а сам DARPA, сам департамент перспективных исследований, разрабатывал свои собственные стандарты, которым должны были соответствовать новые компьютеры будущего. В конце 60-х, да. То, что мы называем сильно давним прошлым, на тот момент было сильно далёким будущим. В 1974 году двое молодых учёных, Винтон Сёрф и Роберт Канн, пишут работу. Работа называлась «Протокол пакетного взаимодействия в сетях». 1974 год, авторы предлагают идею: давайте делать пакетное взаимодействие. И с помощью пакетного взаимодействия мы будем передавать сигналы на соседние узлы, они дальше будут декодировать их, перекладывать пакеты в виде каких-то новых аналоговых сигналов дальше,

и в итоге всё это дело должно дойти до получателя. Идея понравилась, департамент перспективных исследований сказал: «Молодцы, ребята, вот вам денег, давайте работайте дальше над этой идеей». 1977 год, продолжает работу Винтон Сёрф, он пишет другую работу, которая называется «Спецификация протокола Internet Transmission Control Program». Он уже называется подобным образом на TCP, Transmission Control Program. Это не тот TCP, который мы сегодня знаем, это промежуточное рабочее название протокола, потому что он должен был управлять и передачей, и управлением соединением, и кучу всяких разных служебных задач должен был решать. Задачи, которые решались этим протоколом, они относились и к уровню межсетевого взаимодействия, и к транспортному уровню модели TCP/IP. На это дело посмотрели кураторы из американской военщины и сказали: «Слушай, мы только что придумали модель,

в рамках которой стандарты должны стараться не залезать в области, которые в разных уровнях». Ты, конечно, можешь два соседних уровня, сетевой и транспортный, закрыть одним стандартом, но лучше всё-таки разнести это по двум разным протоколам. И в 1978 году это действительно разносится на два разных протокола, там появляется всё тот же Винтон Сёрф и Джон Постел, два учёных, они пишут новые версии этого самого стандарта пакетного взаимодействия. Оно в какой-то момент называется TCP, в какой-то момент его переименовывают, он уже называется Internetworking Protocol. И в 1978 году, в декабре 1978 года, появляется работа Internetwork Protocol Specification. И это тот самый протокол, который мы сегодня знаем, с небольшими оговорками. Причём там периодически появляются номера версий, которые очень часто путают новичков. Номера версий были следующие.

Здесь вы можете видеть: идёт TCP версия 3, потом здесь версия 2. Хронологически получается, что сначала была версия 3, потом версия 2, потом версия 4. Это не должно вас смущать. Это не должно вас смущать. Действительно, такое было, что версионность была, и версионность была разная. Отдельно мы рассматриваем то, что у нас есть версии стандарта. И это версии. Сначала там была версия первая, потом версия вторая, потом версия третья. И отдельно есть ещё заголовок протокола, который предусмотрен этим самым стандартом. И в этом заголовке пишется некое число. Мы сейчас увидим формат IP-пакета, и там в заголовке есть поле, куда можно положить номер протокола. И этот номер протокола не имеет отношения к той нумерации научных работ,

которые вели Винтон Сёрф, Роберт Канн и Джон Постел. В той последней работе, Internetwork Protocol Specification версии 4, эта версия 4 — это как раз то самое число, которое авторы предлагали класть в заголовок IP для того, чтобы указать, что это именно актуальная рабочая версия стандарта, которую они предлагают использовать. При этом, учитывая, что все эти версии, которые другие были, там версия 3, версия 2, версия 1, это всё фактически были экспериментальные протоколы, существовавшие только на бумаге, реальных имплементаций их на железе не было. Мы можем сказать, что первый самый протокол, который хоть какой-то появился, хоть близко похожий на боевой, это был как раз протокол версии 4. Поэтому, если вдруг вас интересовало, есть IPv4, есть IPv6, а где IPv1, IPv2, IPv3 — это всё были экспериментальные протоколы, которые были предложены на бумаге, они отличались от своих предыдущих версий

буквально косметическими изменениями, и никогда, ни при каких обстоятельствах вы не можете увидеть эти протоколы даже в музее, реализованными на железе. В принципе не существует, допустим, роутера, ни сейчас не существует, никогда не существовало роутера для IPv3. IPv6 роутеры бывают, IPv4 роутеры бывают, IPv3 — нет. Именно потому, что это всё делалось на бумаге, и в какой-то момент просто авторам говорили их кураторы из Министерства обороны, что, ребят, это не пойдёт, потому что. Дальше они предлагали другую версию, им говорили: окей, это исправили, но теперь исправляйте вон то, потому что. И когда получилось что-то, напоминающее готовый результат, это как раз был протокол версии 4, это фактически первый протокол, который вышел из альфа-версии. Он был тогда в бете. Почему я говорю в бете? Почему я не говорю, что это был нормальный, полноценный протокол? Потому что сам Винтон Сёрф

недавно заявил, что то, что получилось в итоге, это никоим образом не был готовый протокол для взаимодействия того, что мы сейчас знаем интернетом. Это был сугубо экспериментальный протокол, который, если хотите, вырвался из лаборатории и пошёл размножаться в реальном мире. Сами авторы не ожидали такого бурного роста. Предполагалось, что это будет какой-то сугубо внутренний междусобойчик у американских военных, а выросло вон во что. 1978 год, в декабре, выходит эта бета-версия IPv4. Её практически сразу релизнули, если пользоваться терминами софтверных разработчиков. В 1980 году появляется документ Request for Comments 760. Это стандарт, который регламентирует работу IPv4. Фактически первый стандарт, который связан с межсетевым взаимодействием, с интернетом. Дальше.

Через год этот стандарт обновляется, появляется RFC 791, который исправляет какие-то косяки, которые были обнаружены на тот момент. Причём реальных пользователей на тот момент ещё особо не было. Это только американские военные, которые оплатили разработку этого протокола. Они там между собой общались и в процессе сказали, что нам ещё не нравится вот это, вот это, вот это. Не то что не нравится, они просто дополнения какие-то сделали, и в 81 году появляется RFC 791. Вплоть до сегодняшнего дня мы пользуемся IPv4, который описан как раз в RFC 791. Дальше. В 81 году RFC 791 предусматривал классовую адресацию. Мы про неё поговорим попозже, что это такое. Дальше. В 85 году от классовой адресации было принято решение потихоньку отказываться. И с 92 года никакой классовой адресации больше нет.

Поэтому если вдруг вы любите решать всякие задачки, типа к какому классу сетей относится такой-то IPv4-адрес, имейте в виду, что с 92 года эти вопросы лишены смысла. При этом, как я уже говорил, сами авторы даже говорили, что это сугубо экспериментальный протокол, в альфа или бета-версии. И у IPv4 действительно много косяков. Потому что это был протокол, который предполагалось использовать в очень конкретном применении. И никоим образом не предполагалось, что им будут пользоваться гражданские лица, к примеру. Никоим образом не предполагалось, что этим протоколом будут пользоваться огромное количество участников. Но уже в 83 году этим протоколом начинают пользоваться ученые. Европейский институт ядерных исследований ЦЕРН где-то между 83 и 85 годом начинает его использовать. Постепенно подтягиваются все другие университеты. И в 90-м году, в декабре 90-го года,

Тим Бернерс-Ли придумывает первый веб-сервер. И в 91-м году придумывает браузер, который способен рисовать веб-странички. Начиная с этого момента появляется тот самый интернет, который мы знаем сегодня. 90-й и 91-й годы. Дальше сами знаете, во что вырос интернет. С 92-го года отказ от классовой адресации. Там же появляются всякие механизмы типа NAT, но мы про них потом поговорим. И в 92-м же году начинаются работы над следующей версией протокола IP, который был лишен недостатков, свойственных IPv4. IPv4 на тот момент пользуется полторы калеки, но уже ученые понимают, что протокол получился, мягко говоря, не идеальный, с большим количеством недостатков, и надо эти недостатки устранять. С 92-го года начинается работа над IPv6. В 94-м году появляется первый стандарт. В 96-м году строится первая IPv6-сеть. В 98-м году RFC 2460 предлагает уже готовый стандарт.

Он хотя и в драфте постоянно был, но тем не менее стандарт. 2460 — это IPv6. Следующая версия протокола IP. Уже предлагается его использовать в продакшене. И сколько уже? 21 год протоколу с момента выхода, с момента публикации предложения стандарта. Приблизительно сейчас порядка 25% пользователей пользуются IPv6. Так, я вас утомил цифрами, полчаса про них рассказывал. Давайте поговорим все-таки про то, как IP работает. IP — протокол передачи данных между линками. У нас есть линки, и у нас есть железки, которые соединяют эти линки в единую магистральную сеть. Такие железки мы будем называть роутеры, то есть транзитные узлы, которые занимаются как раз перекладыванием данных между интерфейсами. Интерфейсы могут быть самые разные, линки, которыми соединены устройства,

они не обязаны быть все одинаковые, они не обязаны быть все похожи друг на друга. Единственное, что от них требуется, это способность передавать пакетные данные. Если говорить про IPv4, то ограничения на эти самые пакетные данные будут такие, что любой узел должен передавать пакеты от 576 байт длиной. 576 байт длиной — это единственное требование, которое будет для линка, для того, чтобы он мог работать с протоколом IP. Из того, что вы сегодня можете видеть, это, естественно, Ethernet. Ethernet прекрасно работает с IP, и связь IP поверх Ethernet, поверх Ethernet 2, в частности, тот способ связи, которым мы чаще всего сегодня пользуемся, описан в RFC 894. Отдельно у нас есть сам IP, который рассказывает про то, какой хороший сам IP, и отдельно есть указание, как IP будет передаваться по линку Ethernet.

В принципе, IP прекрасно работает в любых других 802-х сетях, то есть Wi-Fi, Bluetooth, WiMAX, что там еще бывает, Token Ring тот же самый, все это 802-е сети, и для них есть отдельный RFC, который указывает, как IP будет упаковываться в такие сети. Есть указание, как IP будет работать поверх ATM, есть IP поверх протокола PPP. Отдельные наборы стандартов, которые указывают, как мы берем IP-пакет и дальше просто в виде какой-то битовой сущности передаем его по некоторому каналу связи. И есть отправитель и получатель, который с этими IP-пакетами может работать. В принципе, есть еще такой полушуточный стандарт IP поверх почтовых голубей. Это так называемый первоапрельский RFC, есть некоторое количество первоапрельских RFC, в которых берут какую-то глупую штуку или смешную штуку и пытаются реализовать.

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

прилепить к этому голубю и отправить его домой. Почтовый голубь всегда находит дорогу домой. Вот такой способ связи IP поверх почтовых голубей был описан в качестве шуточного RFC, но на самом деле это очень полезный шуточный RFC, потому что он позволяет понять, что IP может и чего он не может. Свойства IP как протокола как раз на примере почтового голубя очень хорошо раскрываются. И пример того, какие свойства есть: я вам говорил, что в IP вы можете отправить пакет, и вы не знаете, долетит он до получателя или не долетит. Прекрасный пример: вы берете почтового голубя, отправляете, всё, вы дальше не видите этого голубя, как только он скрывается с ваших глаз, улетает за горизонт, вы не можете никаким образом узнать, что с этим голубем произошло. Может быть, он долетел до получателя, может быть, нет. Может быть, он в какой-то момент сел отдохнуть на дерево, его там лиса съела. Может быть такое, что у вас пакет повредится по дороге. Голубя-то вы отправили,

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

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

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

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

он проверяет, что пакет корректный, что это действительно IPv4, что IPv4 корректный, по крайней мере, в части заголовка, что пакет пришёл именно ему, и отрезает всё, что не содержит боевые данные, и отправляет боевые данные уже обработчику транспортного уровня. К примеру, у нас вложение TCP. Мы приняли пакет, посмотрели, что внутри лежит TCP, посмотрели, что это действительно IP, что это IP с правильной чек-суммой, что это IP-пакет, предназначенный именно нам. Окей, отрезаем IP-шную бошку и отправляем содержимое на обработчик TCP. Транзитный узел делает что-то промежуточное между тем, что делает отправитель и получатель. Он с одной стороны получает пакет, а с другой стороны отправляет пакет в сторону получателя. Первый шаг. Он получает пакет. Он убеждается, что пакет пришёл целостный, что это действительно IPv4, что это IPv4, не поломавшийся по дороге, и проверяет, что он не является конечным получателем. Если у вас какой-то узел просто получает какие-то данные, которые не ему,

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

Это просто число. Например, 1 — это IP-адрес, и 2 — это IP-адрес, и 159 — это IP-адрес, и 130 820 943 — это тоже IP-адрес. IP-адрес — это просто число. Число 32-битное, диапазон всех возможных IPv4-адресов — это с нуля по 4 миллиарда 295 миллионов с чем-то. Приблизительно это 4 миллиарда с небольшими копейками. Так. Адрес в IPv4 назначается на канальный интерфейс, если у нас есть интерфейс, на него можно навесить IP-шник. Может быть такое, что у вас будет несколько интерфейсов, тогда на нескольких интерфейсах у вас будут несколько разных адресов. IP-адрес должен быть уникальный в пределах всей сети, не должно быть такого, что у двух узлов будет одинаковый IP-адрес.

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

У всех узлов в этом канале левая часть должна совпадать. Эта левая часть — это битовая часть. Мы рассматриваем IP-адрес как 32-битовое число. У него есть первый бит, второй бит, третий бит, четвёртый бит. И левая часть — это самые старшие биты. Какое-то количество этих самых старших битов. А правая часть — это, соответственно, какие-то младшие биты. Старший, младший. Я думаю, что понятно, что тот бит, который сильнее влияет на результат, если его поменять, он будет называться старшим. И у всех узлов в одной среде, в одном канале левая часть обязана совпадать. И если у нас есть два узла, которые находятся в разных каналах, то у них левая часть обязана различаться. Если у нас есть другой коаксиальный провод, и в нём у нас какие-то другие компьютеры есть… Я не буду много их рисовать.

Если у нас есть два канала… У меня после перезагрузки PowerPoint-а слайды потеряли аннотации, сейчас я перерисую. Вроде всё в порядке, вроде не перелистывается. У нас есть два канала, и в этих двух каналах у нас сидят пользователи. Пять компьютеров с одной стороны, пять компьютеров с другой стороны. У всех компьютеров, которые будут иметь IP-адреса в левом канале, у них левая часть адреса должна быть одинаковой. А правая часть, естественно, будет отличаться, потому что у каждого компьютера должен быть уникальный IP-шник. Если часть этого адреса у всех одинаковая, то другая часть, естественно, должна быть разная. Если мы посмотрим на пользователей в этом канале, у них у всех IP-шников левая часть, Network ID, будет одинаковая. Здесь тоже, в правой части тоже Network ID у всех узлов будет одинаковый. Но если мы посмотрим на вот этот узел и вот этот, они находятся в разных каналах, у них Network ID должна быть разная.

Этот самый Network ID назначается администратором всей IP-сети. Если мы говорим, допустим, про интернет, у нас есть великий администратор всего интернета, и он говорит, в каком канале какой Network ID у вас должен быть. Есть некий самый главный администратор, который говорит: здесь мы используем битики 1, 0, 1, 1, 0, 1, 1, 1, 0, и сколько-то этих битиков там будет. Это Network ID 1. А здесь тот же администратор говорит: здесь у нас левые битики, Network ID, используем 1, 0, 0, 0, 1, 1, 1, 0, 0, 1, и это будет Network 2. Есть некий главный администратор, который следит за тем, чтобы в каждой сети, в каждом канале, левые части были бы уникальны. А дальше за то, чтобы в пределах каждого канала IP-шники у нас не пересекались, будет отвечать администратор уже этой самой сети. Network ID — там есть администратор,

который следит за тем, чтобы правая часть у этого компьютера и у этого компьютера была бы разная. У них левая часть одинаковая, дальше к ней надо приделать ещё какую-то правую часть, чтобы получилось 32 бита. И администратор следит за тем, чтобы эти самые правые части не пересекались. В то же самое время администратор второй сети следит за тем, чтобы не пересекались правые части в другом канале. У нас есть администратор канала, администратор канальной среды, который следит за правой частью. А левую часть он получает от верховного администратора. IP-адрес, как уже было сказано, это просто число. Миллион — это число, это IP-адрес. Формально говоря, даже такое красивое число — 2 миллиарда 130 миллионов 706 тысяч 433 — это тоже IP-адрес. Причём я думаю, что вы, наверное, предполагаете, что IP-адрес — это какая-то сущность, которая вам, в принципе, известна. И вы можете сказать: слушай, Иннокентий, как-то обычно мы под IP-адресом понимаем какую-то другую сущность, которая состоит из каких-то чисел.

И эти числа как-то по-другому обычно выглядят. Соответственно, да. Давайте попробуем посмотреть на то, что действительно это число, 2 миллиарда 130 миллионов 706 тысяч 433, — это IP-адрес. Я его сейчас попингую. И я вас уверяю, оно будет пинговаться. 2 миллиарда 130 миллионов 706 тысяч 433. Видите, пингуется. Только пингуется в другом формате немножко записано. 127.0.0.1. Какая-то более знакомая уже, наверное, запись. Да, IP-адреса могут быть записаны в разных вариантах, в разных форматах. Нет никакого универсального стандартного способа, в котором было бы написано, что только так можно, а никак больше нельзя записывать IP-адреса. Любое число — это IP-адрес. Оно должно быть 32-битным. Если в 32 бита оно влезает, значит, это IP-адрес. 2 миллиарда 130 миллионов влезает в 32 бита. Поэтому это IP-адрес. То, что вы, возможно, привыкли работать с IP-адресами, записанными немножко в другом формате, — ваше право.

Не существует никакого стандартного способа записи IP-адресов. Есть один способ, который популярный. Он состоит из четырёх чисел, разделённых точками. Это довольно часто используется. Чаще всего, наверное, чаще, чем что-либо ещё. Тот же самый адрес, 127.0.0.1. Во всех документах, которые регламентируют работу IPv4, тоже используется именно этот формат. Ещё раз подчеркну. Это часто используемый формат записи, но нигде не написано, что это единственный правильный формат записи. В принципе, можно ещё кучу разных способов представить для записи того же адреса. Например, в стеке BSD, Berkeley Software Distribution, есть для классовых адресов изначально предназначенные способы записи. Но они в бесклассовом мире тоже работают. Вы можете взять и 32 бита разделить на две пачки. Первая пачка будет 8 бит, вторая пачка 24 бита. И каждое из этих чисел вы можете записать в десятичном виде.

И вы получите тот же самый адрес 127.0.0.1. Если мы его запишем в двоичном виде, у нас получится примерно следующая картинка. 0, 1, 1, 1, 1, 1, 1, 1. Это число 127 в виде 8-битной записи. И дальше 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1. Это правая часть. Это правая часть. 23 битика нолика и 1 битик единички. Мы привычную нам запись 127.0.0.1 записали в таком виде. И вы можете сказать, что вот это число 127, а вот это число 1. И запись 127.1 — это ровно тот же адрес. И можно его попинговать. PING 127.1. Тоже он пингуется. Есть ещё способ для адресов класса B

предназначенный. Этот адрес будет записываться в виде трёх чисел. Первая пачка 8 бит, вторая пачка 8 бит, третья пачка 16 бит. 127 — вот она, первая пачка 8 бит. Потом следующая пачка 8 бит — это пачка нулей. 127.0. И дальше последние 16 бит — это будет единица. Такая запись тоже соответствует адресу 127.0.0.1. Давайте сейчас я калькулятор запущу. И покажу, что я имею в виду. Мне потребуется программистский режим. И я сейчас это число введу. 2 миллиарда 130 миллионов 706 433. Видите, в двоичном выражении оно какое значение имеет?

0, 1, 1, 1, 1, 1, 1, 1. И дальше куча нулей и единичка. Мы эти 32 бита в двоичном виде записываем в виде либо четырёх пачек по 8 бит. Первая пачка: 0, 1, 1, 1, 1, 1, 1, 1. Вторая пачка — все нули. Третья пачка — все нули. Четвёртая пачка: 0, 0, 0, 0, 0, 0, 0, 1. Это самый популярный формат записи, когда мы используем четыре числа, разделённых точками. И каждое число имеет 8 бит. Другой вариант я вам показал, когда мы записываем 8 бит и потом 24-битное число, и записываем их в десятичном формате. Ещё один способ. Это пачка 8 бит, пачка 8 бит, пачка 16 бит. И даже этим не ограничивается фантазия людей, которые могут хотеть записать IP-адрес. Например, тот же самый IP-шник, 2 миллиарда 130 миллионов 706 тысяч 433, который можно записать как 127.0.0.1, как 127.0.1, как 127.1.

Его можно записать и в других форматах. Например, ping 0x7f.1. Видите, пингуется. Казалось бы, вообще никаким боком эта штука не похожа на 127. Почему же она внезапно так сработала? Почему 0x7f.1 — это 127.0.0.1? Потому что 0x7f — это запись в шестнадцатеричном формате. Шестнадцатеричное число 7f — это как раз десятичное число 127. Или двоичное число 0, 1, 1, 1, 1, 1, 1, 1. Если вдруг вы хотите записать адрес в шестнадцатеричном формате, никаких проблем. И можно так целиком IP-шник записать. 0x7f000001. Вот так весь IP-шник 127.0.0.1 выглядит. Если хотите больше наркомании, пожалуйста, их есть у меня. Ping 0…

127.0.0.1 не очень хорошо выглядит. Давайте я вот такой IP-шник попробую попинговать: 10.10.10.10. Это просто нормальная запись адреса. 10.10.10.10 — он не пингуется, но это просто привычный нам формат записи. Если я возьму, попробую попинговать ping 010.010.010.010. Как вы думаете, что будет пинговаться? Не буду вас томить, пинговаться будет Google DNS. Если вы думаете, что за ерунда, что вообще происходит, — да, это восьмеричная запись. Если вы пишете число и предваряете его ноликом, система воспринимает эту запись как восьмеричную систему счисления. И число 10 в любой системе счисления обозначает основание системы счисления. Число 010 в восьмеричной системе счисления — это число 8, обычное наше привычное.

Поэтому 010.010.010.010 — это 8.8.8.8. Я сам на эту запись наткнулся сравнительно случайно. Был случай, когда у нас была система мониторинга, и в ней мы мониторили состояние серверов. У нас был сервер, у которого был IP-шник, к примеру, 192.168.10.1. И, соответственно, условный Zabbix или что-то подобное показывало график, красиво строило, насколько всё хорошо работает. И если что-то работало не очень хорошо, то включалась красная лампочка, загоралась сирена, и график начинал рисовать, что всё плохо. И однажды так получилось, что этот сервер просто физически сгорел. Задымился, из него пошёл дым, мы его выключили, вытащили из стойки. Потом смотрим на графики — на графиках всё хорошо, там всё зелёненькое. И как-то это подозрительно: сервер лежит, он физически сгорел, у него обуглившийся блок питания, а на графике показывается, что пинги пингуются. И мы попытались понять, что происходит,

и выяснилось, что в этом самом Zabbix был прописан IP-шник не 192.168.10.1, а 192.168.010.1. И это как раз соответствовало 192.168.8.1. То есть пинговался на самом деле другой адрес. Просто запись, которая была записана, 192.168.010.1, она как раз использовала это наркоманское представление в виде восьмеричного формата. Имейте в виду, такие подвохи могут быть. Так что если вдруг вы хотите поиздеваться над вашими друзьями, вы можете взять и предложить им попингать что-нибудь такое странное. Какое-нибудь странное, что можно предложить. Можно, кстати, двоичную запись использовать. 0.1b. По-моему, вот такое. 1b. Там есть еще пинг. 1x.

Там можно как-то двоичную запись еще делать. Я уже забыл, как. Смысл такой, что если вы хотите поиздеваться над друзьями, вы можете сказать, давайте попингаем, например, тот самый Google DNS, но каким-то кривым образом. И вот чтобы попингать Google DNS, нам нужно число 8. 8. Это число 0, 0, 0, 0, 1, 0, 0. Как бы нам это сделать, чтобы стало хорошо? Давайте. Пинг 0, 10. Точка. Это мы представили его в восьмеричной записи. А вот оставшиеся три восьмерки мы хотим записать в виде, не знаю, 16-ричного формата. Можно сделать вот такую штуку. BIN. 0, 1, 0, 0, 0. Это первая восьмерка. 0, 0, 0, 1, 0, 0, 0. Перебор.

Это вторая восьмерка. 0, 0, 0, 0, 1, 0, 0, 0. Это третья восьмерка. Но, в принципе, больше нам и не нужно. И вот в десятичном виде мы это хотим представить. 526 344. 526 344. Именно потому, что 526 344 в обычном десятичном формате соответствует на самом деле вот такой двоичной записи. Если вы думаете, что это не очень похоже на 24 разряда, то слева можно дописать еще ведущих ноликов, и вы получите как раз 24 битика. И эти 24 битика, если вы разобьете их на пачки по 8 битиков, они как раз будут представлять собой три пачки 0, 0, 0, 0, 1, 0, 0. То есть это обычное число 8. Еще раз, 0 перед десяткой — это так восьмеричная запись указывается. Если вдруг вы хотите поиздеваться над вашими друзьями, вы можете их вот таким вот образом

или каким-нибудь еще более наркоманским образом заагитировать, чтобы они попингали вот это вот. Что характерно, пингается. Так, возвращаемся к нашим баранам. Я вам все это показываю не для того, чтобы вы офигели вконец, а для того, чтобы показать, что IP-адрес — это просто число. А вот то, каким образом оно записывается, это уже представление этого числа. Никакого стандартного представления нет. Компьютер в любом случае работает с отдельными битами. Вот 32 бита есть. Как бы вы ни представляли этот IP-адрес, они в любом случае преобразуются в 32 бита, и дальше компьютеру интересны только эти самые 32 бита. Когда вы берете и записываете адрес в виде четырех чисел, разделенных точками, это только для вашего человечьего удобства. Компьютеру эти удобства нафиг не нужны. У него никаких точек в адресе нет. Дальше. На одном компьютере у вас может быть много IP-шников. Если у вас есть несколько интерфейсов,

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

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

в итоге посмотрим на пакеты. [неразборчиво] Чтобы посмотреть на пакеты.