IP-протокол та адресація

Вступ та Контекст

Чому після OSI ми неминуче приходимо до IP?

У попередньому модулі ми розглянули мережу як систему рівнів. Однак сама по собі модель OSI ще не відповідає на головне практичне питання: яким чином пакет знаходить шлях від одного вузла до іншого, якщо вони не знаходяться в одній локальній мережі?

Саме тут починається справжня територія IP (Internet Protocol). Якщо транспортний рівень дає змогу одному процесу спілкуватися з іншим процесом, а канальний рівень передає кадри в межах локального сегмента, то IP робить дещо масштабніше: він створює механізм логічної адресації та міжмережевої доставки.

Інакше кажучи, без IP сучасний Інтернет не існував би як єдина система. Існували б окремі локальні мережі, окремі технології доступу, окремі острівці комунікації. Але саме IP дав можливість з'єднати їх у глобальну "мережу мереж".

Що таке IP насправді

Не просто "адреса", а правила міжмережевої доставки

У побутовому поясненні часто кажуть: "IP — це адреса комп'ютера в Інтернеті". Таке пояснення частково корисне для першого знайомства, але воно небезпечно спрощує суть. IP — це не лише адреса і не лише формат запису на кшталт 192.168.1.10.

IP (Internet Protocol) — це протокол мережевого рівня, який визначає, як дані адресуються, інкапсулюються і передаються між вузлами через одну або кілька мереж.

У цьому визначенні важливі всі слова:

• протокол — тобто набір правил, а не просто ідентифікатор;
• мережевий рівень — отже, IP не займається ані логікою HTTP-запитів, ані електричними сигналами кабелю;
• адресуються — кожен пакет має знати, куди саме він прямує;
• інкапсулюються — дані верхніх рівнів вкладаються в IP-пакет;
• передаються через одну або кілька мереж — це ключова ідея міжмережевої взаємодії.

Яку проблему вирішує IP

Уявімо дві різні локальні мережі:

• в одній використовується Ethernet;
• в іншій — Wi-Fi;
• між ними стоять маршрутизатори;
• пристрої фізично не бачать одне одного напряму.

Без універсального протоколу логічної адресації та маршрутизації повідомлення просто не мало б "мови", якою можна пояснити, куди воно прямує і як його передавати далі. IP вирішує саме цю проблему. Він не прив'язаний до конкретного кабелю, конкретної мережевої карти чи конкретного локального сегмента. Він працює поверх різних канальних технологій.

Саме тому IP є фундаментом масштабованості. Ви можете змінити Wi-Fi на Ethernet, Ethernet на мобільний зв'язок, локального провайдера на іншого, але IP як логічний шар адресації при цьому зберігає безперервність комунікації.

Поштова аналогія і її межі

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

• IP-адреса схожа на поштову адресу.
• IP-пакет схожий на конверт із вмістом.
• Маршрутизатори схожі на сортувальні вузли.
• Маршрут схожий на ланцюг поштових центрів між відправником і адресатом.

Але є принципова відмінність: пошта зазвичай працює з фізичним об'єктом, тоді як IP працює з послідовністю бітів, яку можна багаторазово інкапсулювати, фрагментувати, передавати різними маршрутами і збирати назад на іншому кінці. Тому аналогія корисна для інтуїції, але не замінює технічного розуміння.

Ключові властивості IP

Connectionless: без попереднього встановлення з'єднання

Одна з фундаментальних властивостей IP полягає в тому, що він є connectionless протоколом. Це означає, що перед відправкою пакета не виконується окрема фаза "домовленості" між сторонами на рівні самого IP.

На цьому рівні немає діалогу у стилі:

1. Чи готовий ти приймати?
2. Так, готовий.
3. Добре, тоді починаю передачу.

IP поводиться значно простіше: він отримує дані від верхнього рівня, формує пакет і передає його в напрямку адреси призначення.

Це дуже важливий концептуальний момент. Багато початківців несвідомо змішують IP і TCP, бо в повсякденній розробці вони часто використовуються разом. Але TCP встановлює з'єднання, а IP — ні. IP просто намагається доставити окремий пакет.

Best-effort: протокол, який намагається, але не обіцяє

Друга фундаментальна властивість IP — best-effort delivery. Це один із найважливіших принципів усієї інтернет-архітектури.

IP:

• не гарантує доставку;
• не гарантує порядок прибуття;
• не гарантує відсутність дублікатів;
• не гарантує, що пакет взагалі не буде втрачено десь на маршруті.

На перший погляд це може видатися дивним або навіть неприйнятним: як може глобальна мережа працювати на протоколі, який нічого не гарантує? Саме тут проявляється інженерна глибина стеку. IP виконує лише ту роботу, яка є необхідною для масштабованого перенесення пакетів між мережами. Усе, що пов'язане з надійністю, впорядкуванням і повторною передачею, за потреби перекладається на вищі рівні, насамперед на TCP.

Цей поділ відповідальності не є недоліком. Навпаки, він робить архітектуру гнучкою:

• якщо потрібна надійність, використовується TCP;
• якщо потрібна мінімальна затримка й можна миритися з втратою частини даних, використовується UDP;
• IP при цьому залишається універсальним спільним фундаментом.

Packet-switched природа

IP працює в середовищі пакетної комутації. Це означає, що повідомлення не резервує окремий виділений канал на весь час передачі. Натомість воно розбивається на порції даних, які можуть іти різними маршрутами через спільну мережеву інфраструктуру.

Це безпосередньо пов'язано з властивістю best-effort. Оскільки пакети подорожують через маршрутизатори незалежно один від одного, кожен із них може:

• прийти пізніше за інший;
• бути втрачений;
• пройти альтернативним маршрутом;
• затриматися через перевантаження вузла.

Для розробника це не просто академічний факт. Це причина, чому в мережевому програмуванні так багато уваги приділяється timeout-ам, повторним спробам, ідемпотентності запитів, буферизації та стійкості до часткових збоїв.

Історія та еволюція IP

Чому взагалі з'явився TCP/IP

Сьогодні легко сприймати Інтернет як природне середовище, що "просто існує". Але історично все було інакше. На ранніх етапах розвитку обчислювальних систем мережі створювалися як окремі, часто несумісні між собою середовища. Кожна архітектура мала власні припущення, власні формати кадрів і власні правила взаємодії.

Проблема полягала в тому, що мережі вже існували, але не існувало достатньо універсального способу зв'язати їх між собою. Саме ця проблема міжмережевої сумісності і стала ґрунтом для появи TCP/IP.

У 1970-х роках Вінтон Серф і Роберт Кан працювали над ідеєю протокольного стеку, здатного з'єднати різні мережі в єдину систему. Їхня мета була глибшою, ніж просто "передати дані". Потрібно було створити модель, яка переживе відмінності середовищ, обладнання і локальних технологій.

IPv4: рішення, яке пережило власні очікування

Офіційна специфікація IPv4 була закріплена в RFC 791 у 1981 році. На той момент 32-бітна адресація здавалася цілком достатньою. Простір у приблизно 4.3 мільярда адрес виглядав астрономічним порівняно з реальними масштабами комп'ютерних мереж того часу.

Але саме тут історія Інтернету демонструє один із найважливіших уроків інженерії: система, спроєктована для одного масштабу, може стати жертвою власного успіху.

Спочатку Інтернет був середовищем для академічних установ, лабораторій і державних дослідницьких мереж. Потім до нього долучилися компанії. Далі — домашні користувачі. Після цього — мобільні пристрої. А згодом з'явилася епоха IoT, у якій кожен датчик, камера, телевізор, термостат або автомобіль потенційно стає учасником мережі.

Те, що в 1981 році виглядало надлишком, до 1990-х почало перетворюватися на дефіцит.

Криза IPv4 і тимчасові порятунки

Коли стало очевидно, що адресного простору IPv4 не вистачить на довгу перспективу, індустрія не перейшла на новий протокол миттєво. Натомість було винайдено кілька надзвичайно практичних рішень, які дозволили "розтягнути" життя IPv4:

1. Приватні адреси — щоб не кожен внутрішній пристрій потребував глобально унікальної публічної адреси.
2. NAT — щоб багато локальних пристроїв могли виходити в Інтернет через одну публічну адресу.
3. CIDR — щоб ефективніше розподіляти адресний простір і відмовитися від грубої класової моделі.

Ці рішення були настільки ефективними, що фактично відклали повну кризу на десятиліття. Саме тому IPv4, попри обмеженість, живе й досі.

IPv6: не "покращений IPv4", а нова адресна філософія

IPv6 було стандартизовано в 1998 році. Його головною причиною стала не косметична модернізація, а необхідність радикально розширити адресний простір. Якщо IPv4 використовує 32 біти, то IPv6 використовує 128 біт.

Ця різниця не є "у чотири рази більшою". Вона є експоненційно більшою. Простір IPv6 настільки величезний, що в повсякденних поясненнях доводиться вдаватися до майже поетичних порівнянь на кшталт "адрес вистачить кожній піщинці на Землі". Такі формулювання умовні, але вони добре передають масштаб.

Проте важливо розуміти: IPv6 виник не лише для того, щоб "дати більше адрес". Він також:

• спрощує певні аспекти маршрутизації;
• краще пристосований до великого масштабу сучасного Інтернету;
• переглядає підходи до локальної автоконфігурації;
• усуває частину історичних компромісів IPv4.

Чому перехід такий повільний

У студента часто виникає цілком логічне запитання: якщо IPv6 об'єктивно сучасніший і розв'язує адресну проблему, чому світ просто не перейшов на нього повністю?

Причина полягає не в слабкості IPv6, а в інерції реальної інфраструктури. Інтернет не можна "перезапустити" за одну ніч. Він складається з:

• маршрутизаторів провайдерів;
• корпоративних мереж;
• датацентрів;
• старих систем;
• домашніх роутерів;
• бібліотек, фаєрволів, балансувальників і мільйонів прикладних систем.

Якщо існуючий IPv4 стек досі працює завдяки NAT, тунелюванню й іншим механізмам, бізнес не має достатнього стимулу негайно відмовлятися від старої моделі. Тому перехід на IPv6 є не подією, а тривалим еволюційним процесом, у якому обидві версії існують паралельно.

Як працює IP: базова механіка

Від прикладних даних до IP-пакета

Коли прикладна програма хоче щось надіслати мережею, вона не працює з IP безпосередньо в більшості звичних сценаріїв. Наприклад, HttpClient формує HTTP-запит, транспортний рівень додає TCP-сегментацію, і лише потім мережевий рівень формує IP-пакет.

Це важливо: IP зазвичай працює не з "готовою бізнес-операцією", а з уже підготовленим корисним навантаженням (payload), отриманим із вищого рівня.

У спрощеному вигляді процес виглядає так:

1. Застосунок формує дані.
2. Транспортний рівень додає свою службову інформацію.
3. IP додає адресу джерела, адресу призначення та інші поля заголовка.
4. Пакет передається далі на канальний рівень.

Вибір маршруту: не "прямо до сервера", а через логіку таблиці маршрутів

Одна з найтиповіших помилок інтуїції полягає в припущенні, ніби комп'ютер "просто відправляє пакет на сервер". Насправді вузол спочатку повинен вирішити, куди саме віддати пакет як наступний крок.

Якщо адреса призначення належить локальній підмережі, пакет можна доставляти безпосередньо сусідньому вузлу через локальний сегмент. Якщо ж адреса належить зовнішній мережі, пакет слід передати шлюзу за замовчуванням (default gateway), тобто маршрутизатору, який уже знає, що робити далі.

Саме тому маршрутизація на вузлі починається з таблиці маршрутів. Вона містить правила на кшталт:

• для цієї підмережі використовуй такий інтерфейс;
• для всього невідомого трафіку використовуй цей шлюз;
• для loopback-адрес використовуй локальний стек.

Це одна з тих тем, де стає особливо видно, що IP — не просто "формат адреси", а частина системи прийняття рішень щодо шляху пакета.

Що робить маршрутизатор

Коли пакет потрапляє на маршрутизатор, відбувається не магія, а чітка послідовність дій:

1. Маршрутизатор приймає кадр із локального інтерфейсу.
2. Виймає з нього IP-пакет.
3. Аналізує адресу призначення.
4. Порівнює її зі своєю таблицею маршрутів.
5. Обирає наступний інтерфейс або наступний hop.
6. Передає пакет далі.

Ключовий момент полягає в тому, що маршрутизатор не "пам'ятає всю історію Інтернету" і не прокладає маршрут у романтичному сенсі слова щоразу заново. Він лише застосовує таблиці й правила маршрутизації, які сформовані локально або через маршрутизувальні протоколи.

TTL: захист від нескінченного блукання

Одна з найбільш елегантних ідей у заголовку IP-пакета — TTL (Time To Live). Попри назву, в сучасному практичному сенсі це не "час у секундах", а радше лічильник допустимих переходів через маршрутизатори.

Кожного разу, коли пакет проходить через маршрутизатор, TTL зменшується на одиницю. Якщо TTL досягає нуля, пакет відкидається.

Навіщо це потрібно? Щоб уникнути нескінченних циклів маршрутизації. Якщо через помилку конфігурації або аномалію в таблицях пакет почне "кружляти" між маршрутизаторами, TTL не дозволить йому робити це вічно.

IP у моделі OSI та стеку TCP/IP

Формальна позиція IP

У моделі OSI IP належить до мережевого рівня (Layer 3). Це означає, що його сфера відповідальності лежить між транспортом зверху і локальними технологіями доставки знизу.

З погляду стеку TCP/IP IP належить до рівня Internet. Саме тут розташовується ядро міжмережевої адресації.

Це проміжне положення є надзвичайно важливим. IP:

• не знає бізнес-смислу HTTP-повідомлення;
• не відповідає за повторну передачу втраченого сегмента;
• не займається MAC-адресами як глобальними ідентифікаторами;
• але саме він робить можливим перенесення пакета між різними мережами.

Чим IP відрізняється від TCP і від Ethernet

Для міцного розуміння варто постійно тримати в голові три різні площини:

• Ethernet / Wi-Fi відповідають за доставку в межах локального сегмента;
• IP відповідає за логічну адресацію й міжмережевий шлях;
• TCP / UDP відповідають за взаємодію між прикладними процесами.

Якщо змішати ці ролі, мережевий стек починає здаватися хаотичним. Якщо ж чітко розділити їх, стає зрозуміло, чому один і той самий HTTP-запит одночасно має:

• порт;
• IP-адресу;
• MAC-адресу;
• корисне навантаження прикладного рівня.

Це не дублювання, а накладання різних рівнів відповідальності.

Чому IP-адресація настільки важлива для розробника

На перший погляд може здатися, що деталі IP-адресації потрібні лише мережевим адміністраторам. Але це хибне враження. Прикладний розробник постійно стикається з IP, навіть якщо не помічає цього відразу.

Ви маєте справу з IP, коли:

• сервіс слухає на конкретному IPAddress або IPEndPoint;
• потрібно розрізнити localhost, приватну адресу і публічний endpoint;
• застосунок працює в Docker-мережі, VPN або Kubernetes;
• треба зрозуміти, чому один вузол доступний локально, але недоступний ззовні;
• з'являються помилки NAT, DNS, firewall rules або неправильних subnet masks.

Інакше кажучи, IP-адресація — це не вузька теорія про октети. Це фундаментальна карта того, де перебуває вузол у мережевому просторі і як до нього взагалі можна дістатися.

IPv4 адресація

Чому адреса має структуру, а не є випадковим числом

Коли студент уперше бачить адресу на кшталт 192.168.1.10, вона часто сприймається як довільний набір чотирьох чисел. Але в IP-адресації майже нічого не є випадковим. Адреса одночасно виконує дві ролі:

• вказує, до якої мережі належить вузол;
• ідентифікує конкретний вузол усередині цієї мережі.

Саме тому адреса не може розглядатися ізольовано від контексту. Щоб зрозуміти, що означає 192.168.1.10, недостатньо подивитися лише на число. Потрібно ще знати, де закінчується мережева частина і починається хостова. Саме з цього і виростає вся тема масок підмереж, CIDR та маршрутизації.

Формат IPv4

IPv4-адреса має довжину 32 біти. Для людської зручності ці 32 біти розбиваються на чотири групи по 8 біт, які записуються у десятковому форматі через крапку. Такий запис називають десятковим записом із крапками (dotted-decimal notation).

Наприклад:

192.168.1.10

Технічно ця сама адреса є лише двійковою послідовністю:

11000000.10101000.00000001.00001010

Кожен октет може набувати значення від 0 до 255, бо 8 біт дають 2^8 = 256 можливих комбінацій.

Скільки існує IPv4-адрес

Оскільки IPv4 використовує 32 біти, загальна кількість теоретично можливих адрес дорівнює:

2^32 = 4 294 967 296

У популярних поясненнях це округлюють до 4.3 мільярда адрес. Але важливо одразу зробити інтелектуальне уточнення: це не означає, що всі ці адреси доступні для довільного публічного використання. Частина простору:

• зарезервована;
• призначена для спеціальних сценаріїв;
• використовується як приватна;
• не маршрутизується в глобальному Інтернеті;
• або має історичні та технічні обмеження.

Саме тому реальна адресна економіка IPv4 є значно складнішою, ніж проста арифметика 2^32.

Спеціальні діапазони IPv4

Чому не кожна адреса означає "хост в Інтернеті"

Наївне уявлення про IP-адресацію звучить так: кожна адреса вказує на конкретний комп'ютер десь у світі. Насправді це неправда. Частина адресних діапазонів має спеціальне призначення і використовується зовсім не так, як публічні глобально маршрутизовані адреси.

Розуміння спеціальних діапазонів важливе не лише для теорії. Саме воно дозволяє правильно читати мережеві конфігурації, розуміти помилки в контейнерах, VPN, локальних сервісах, домашніх мережах і cloud-інфраструктурі.

Loopback: комп'ютер звертається до самого себе

Найвідоміша спеціальна адреса — це 127.0.0.1, яку зазвичай називають localhost. Вона належить до діапазону:

127.0.0.0/8

Це означає, що весь діапазон від 127.0.0.0 до 127.255.255.255 зарезервований для loopback-взаємодії.

Сенс loopback полягає в тому, що пакет не залишає комп'ютер і не йде в реальну фізичну мережу. Операційна система обробляє його всередині власного стеку TCP/IP. Це дає надзвичайно корисну можливість тестувати мережеві застосунки локально, не покладаючись на зовнішній інтерфейс чи маршрутизатор.

Для розробника це критично важливо:

• локальний вебсервер часто слухає 127.0.0.1;
• база даних може бути доступна лише на loopback-інтерфейсі;
• тестування HTTP API на localhost означає, що ви перевіряєте прикладну логіку без виходу в зовнішню мережу.

Приватні адреси

Окрема величезна категорія — приватні IPv4-адреси. Вони визначені для використання у внутрішніх мережах і не маршрутизуються в глобальному Інтернеті.

Існують три основні приватні діапазони:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Практично це означає:

• домашній роутер часто видає щось на кшталт 192.168.1.x;
• корпоративні мережі нерідко використовують 10.x.x.x;
• середні організації або VPN-конфігурації часто працюють у 172.16.0.0/12.

Приватна адреса не є "неповноцінною". Вона повністю функціональна всередині своєї мережі. Обмеження полягає лише в тому, що така адреса не може бути кінцевою глобально маршрутизованою адресою в Інтернеті без додаткових механізмів на кшталт NAT.

Public vs Private: важлива межа

Розрізнення між публічною і приватною адресою є одним із центральних практичних навичок розробника.

Публічна адреса:

• глобально унікальна;
• може маршрутизуватися в Інтернеті;
• видима зовнішньому світу;
• зазвичай належить провайдеру, датацентру або хмарній інфраструктурі.

Приватна адреса:

• існує всередині локального або корпоративного простору;
• може повторюватися у тисячах різних мереж;
• не є глобально маршрутизованою;
• потребує NAT або іншого механізму для виходу в публічний Інтернет.

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

Link-local і APIPA

Ще один важливий діапазон:

169.254.0.0/16

Його часто пов'язують із механізмом APIPA (Automatic Private IP Addressing) у Windows-подібних середовищах. Якщо пристрій не зміг отримати адресу від DHCP, він може автоматично призначити собі адресу з цього діапазону.

Для інженера це майже завжди діагностичний сигнал. Якщо ви бачите в інтерфейсу адресу 169.254.x.x, це, як правило, означає не "нормальну робочу конфігурацію", а проблему з отриманням адреси від мережі.

Broadcast і Multicast

Не всі адреси позначають одного конкретного отримувача.

Broadcast використовується для звернення до всіх вузлів у певному сегменті. Класичний приклад:

255.255.255.255

або broadcast-адреса конкретної підмережі, наприклад:

192.168.1.255

Водночас multicast використовується для адресування не всім, а групі отримувачів, які підписані на певний мережевий потік. Для цього зарезервовано діапазон:

224.0.0.0/4

Для прикладного розробника це важливо щонайменше з двох причин:

• деякі протоколи виявлення сервісів використовують broadcast або multicast;
• не весь мережевий трафік є моделлю "один клієнт → один сервер".

Адреса мережі і broadcast-адреса

У межах конкретної підмережі існують спеціальні значення, які не можна довільно роздавати хостам.

Наприклад, у мережі 192.168.1.0/24:

• 192.168.1.0 — це адреса мережі;
• 192.168.1.255 — це broadcast-адреса;
• реальні хости зазвичай отримують значення між ними.

Саме тут починає ставати очевидним, чому IP-адресу не можна інтерпретувати без префікса або маски. Те саме число може бути або валідною адресою хоста, або адресою мережі, залежно від контексту.

Класова IPv4-адресація

Історичний спосіб мислення про адреси

На ранніх етапах розвитку IPv4 адресний простір поділявся на класи A, B, C, D і E. Сьогодні цей підхід значною мірою застарів з практичного погляду, але знати його все одно варто. Причина проста: класова логіка вплинула на історію маршрутизації, на структуру старої документації і навіть на інтуїцію багатьох інженерів старшої школи.

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

Клас A

Адреси класу A історично використовували перший октет як мережеву частину, а решту — як простір хостів.

Типова маска:

/8

Це означає, що:

• перші 8 біт описують мережу;
• решта 24 біти описують хости.

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

Клас B

Клас B історично відповідав середнім мережам і використовував префікс:

/16

Тут уже:

• 16 біт ідентифікують мережу;
• 16 біт залишаються під хости.

Це давало значно більше мереж, ніж у класі A, але все ще залишалося досить грубим і неекономним механізмом для реального світу.

Клас C

Клас C відповідав малим мережам і використовував:

/24

Тобто:

• 24 біти — мережева частина;
• 8 біт — хостова.

Саме ця логіка багато в чому пояснює популярність домашніх мереж виду 192.168.1.0/24. Вона добре лягає на інтуїцію: маємо одну локальну мережу і до 254 придатних адрес хостів.

Чому класова модель виявилася невдалою

На перший погляд класи здаються логічними. Але проблема полягає в тому, що реальний світ не підлаштовується під три грубі розміри.

Уявімо організацію, якій потрібно приблизно 500 адрес.

• клас C із /24 дає замало;
• клас B із /16 дає абсурдно багато.

Отже, класова модель породжувала масштабне марнування адресного простору. Саме це стало однією з причин появи CIDR, який ми розглянемо нижче. У сучасній практиці класове мислення корисне передусім як історична довідка, але не як основний інструмент проєктування мереж.

Маски підмереж

Чому IP-адреси самі по собі недостатньо

Адреса без маски — це лише половина інформації. Щоб вузол міг зрозуміти, хто для нього є "локальним сусідом", а хто — "зовнішнім призначенням через маршрутизатор", він повинен знати межу між мережею та хостом.

Саме цю межу визначає маска підмережі (subnet mask).

Наприклад:

IP address: 192.168.1.100
Mask:       255.255.255.0

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

Логіка одиниць і нулів

Маска є 32-бітним значенням, у якому:

• біти, встановлені в 1, означають мережеву частину;
• біти, встановлені в 0, означають хостову частину.

Для маски 255.255.255.0 це означає:

11111111.11111111.11111111.00000000

Перші 24 біти — мережа. Останні 8 біт — хост.

Саме тому запис:

192.168.1.100/24

і запис:

192.168.1.100 with mask 255.255.255.0

у більшості контекстів означають одну й ту саму річ.

Як визначається адреса мережі

Адреса мережі обчислюється через побітову операцію AND між IP-адресою та маскою.

Для прикладного програміста це може звучати занадто низькорівнево, але цей механізм пояснює все: чому адреса належить саме цій підмережі, чому пакет іде напряму або через gateway, чому певні адреси є network/broadcast.

Приклад:

IP:    192.168.1.100
Mask:  255.255.255.0

У двійковому вигляді:

11000000.10101000.00000001.01100100
11111111.11111111.11111111.00000000
-----------------------------------
11000000.10101000.00000001.00000000

Результат:

192.168.1.0

Тобто вузол належить до мережі 192.168.1.0/24.

Чому це важливо для доставки

Коли ваш комп'ютер хоче надіслати пакет на 192.168.1.50, він порівнює цю адресу зі своєю адресою та маскою. Якщо виявляється, що обидві адреси належать до однієї мережі, пакет можна відправляти локально. Якщо ні — треба використовувати маршрутизатор.

Ось чому неправильна маска може повністю зламати мережеву логіку, навіть якщо сама IP-адреса виглядає "схожою на правильну". Вузол просто неправильно інтерпретуватиме, хто для нього локальний, а хто зовнішній.

Поширені префікси

У практиці часто трапляються такі варіанти:

Ця таблиця не є матеріалом для механічного заучування. Її справжня цінність у тому, щоб виробити відчуття масштабу: як зміна лише кількох бітів різко змінює кількість доступних адрес.

Поділ на підмережі

Навіщо ділити мережу

Можна поставити цілком раціональне запитання: якщо організація отримала мережу, навіщо взагалі дробити її на менші частини?

Причин кілька:

• зменшення broadcast-доменів;
• логічне розділення відділів або сервісів;
• підвищення керованості;
• політики безпеки;
• ефективніше використання адресного простору.

Підмережа (subnet) — це не просто математичний трюк. Це інструмент архітектури мережі.

Простий приклад subnetting

Припустімо, у нас є мережа:

192.168.1.0/24

І ми хочемо поділити її на 4 менші підмережі. Для цього потрібно "позичити" ще 2 біти під мережеву частину, бо:

2^2 = 4

Отже, отримаємо:

/26

Тепер маємо чотири підмережі:

• 192.168.1.0/26
• 192.168.1.64/26
• 192.168.1.128/26
• 192.168.1.192/26

У кожній із них буде власна:

• адреса мережі;
• діапазон хостів;
• broadcast-адреса.

Саме в таких прикладах абстрактна тема бітів перетворюється на прикладну інженерію: ви фактично проєктуєте простір адрес для окремих сегментів організації.

CIDR

Відмова від жорстких класів

CIDR (Classless Inter-Domain Routing) став відповіддю на неефективність класової моделі. Замість того щоб мислити тільки категоріями A/B/C, CIDR дозволив використовувати довільну довжину префікса.

Це означає, що мережа може бути не лише /8, /16 або /24, а, наприклад:

• /23
• /27
• /30
• /31
• /32

Тобто адресний простір почали розподіляти значно точніше під реальні потреби.

Як читати CIDR-запис

Запис:

192.168.1.0/24

означає, що:

• адреса мережі починається з 192.168.1.0;
• перші 24 біти є мережевими;
• решта 8 біт відведені під хости.

Запис:

10.0.0.0/30

означає вже зовсім інший масштаб: лише кілька адрес у межах невеликої point-to-point мережі.

Чому CIDR важливий не тільки для адрес, а й для маршрутизації

Справжня сила CIDR проявляється не лише в економії адрес, а й у агрегації маршрутів (route summarization). Якщо кілька суміжних мереж можна описати одним більшим префіксом, таблиці маршрутизації стають компактнішими і масштабованішими.

Це критично для магістрального Інтернету. Без агрегації кількість маршрутних записів зростала б набагато швидше і створювала б додатковий тиск на маршрутизатори.

CIDR як сучасна мова адресації

У сучасній інженерній практиці CIDR — це не "додаткова тема", а базова мова, якою описують мережі. Якщо ви працюєте з:

• Docker bridge networks;
• Kubernetes services;
• AWS VPC;
• Azure virtual networks;
• VPN tunnels;
• firewall rules;

то майже напевно побачите саме CIDR-префікси, а не старе класове мислення.