OSI-модель: як спуститись в кролячу нору й випірнути звідти

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

Привіт, мене звати Ганна Ліхтман, я Lead Software Engineer у GlobalLogic Ukraine. У мене за плечима 10+ років в індустрії, сотні проєктів, тисячі строчок коду — і, здається, більше кави, ніж води. Наразі я поступово дрейфую у бік інжиніринг-менеджменту та архітектури — тобто на той рівень, де замість фіксити баги можна просто сказати: «а це не моя зона відповідальності» 😏

Але є одна річ, яку я люблю навіть більше за свіже оновлення в CI/CD — це пояснювати складне простою людською мовою. Так, щоб навіть пес мого сусіда, що випадково підслухав, міг кивнути лапою й подумати: «ага, маршрутизація — це не страшно».

Сьогодні я запрошую вас у невеличку (20 хвилин, зайшли і вийшли), але яскраву подорож у той світ, про який багато хто чув, але мало хто пам’ятає — модель OSI. Це та сама багаторівнева красуня з університетських заліків. Ви її, певно, вчили з таблички, зубрили для іспиту, а потім зітхнули і викреслили з оперативної пам’яті.

Дарма! Бо сьогодні ми:

• Спустимось у самі нутрощі мережевої взаємодії, аж до електронів і фотонів.
• Побачимо, як запит на Google проходить усі рівні — від прикладного до фізичного і назад.
• Пояснимо, чому OSI та TCP/IP — це як двоюрідні брати на родинному святі: схожі, але один більш серйозний, інший — більш життєвий.
• І, звісно, розберемося з такими штуками, як сегменти, пакети, фрейми, бітові імпульси, TCP vs UDP, encryption, compression, translation та інші страшні слова, що насправді не страшні.

Цей текст — для всіх, хто:

• Хоче нарешті розібратись із «тією моделлю з семи рівнів».
• Готується до технічного інтерв’ю і хоче звучати, як мережевий гуру.
• Просто хоче впорядкувати знання, щоб відповісти на «А як працює інтернет?» не блукаючим поглядом, а чіткою, красивою відповіддю зі схемками 🧠

Тож, незалежно від того, ти Front-end чарівник, Back-end алхімік, DevOps майстер чи адмін-самурай, — базове розуміння цього ландшафту точно зробить тебе крутішим.
Ну що, пристібаємось, вдягаємо мережеві шоломи — і погнали.

📡 Вступ. Мережева модель OSI — та сама «страшилка» з університету, яка виявилась... цікавою

Пам’ятаєте цей момент?

OSI — це Open Systems Interconnection basic reference model...

— казав викладач.

Окей, ще одна абревіатура в колекцію

— казали ми, стримуючи позіх.

Нам пояснювали, що це еталонна модель, яка допомагає зрозуміти, як комп’ютери спілкуються між собою — навіть якщо один зроблений у Південній Кореї, другий у Каліфорнії, а третій, здається, зібраний із деталей праски і надії.

І саме тоді наставало улюблене: сім рівнів, купа термінів, якесь «представлення», ще й «сесійний», і всі щось там «зашифровують», «маршрутизують» і «інкапсулюють».

І десь у цей момент у свідомості багатьох з’являвся внутрішній фейспалм із підписом: «Я просто хотів зробити сайт із котиками...»

Та насправді — це зовсім не страшно. І ні, вам не потрібно вивчати всі протоколи до біта (якщо тільки ви не вирішили стати мережевим чарівником або позаштатним консультантом ISO).

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

Тож уявіть:

Кожного разу, коли ви щось гуглите (чи, будьмо чесні, шукаєте «npm fix everything»), запускається міжконтинентальна пригода. Ваш текстовий запит:

16-17 травня, Київ. Квитки тут!👇

• перетворюється на потік даних;
• біжить через дроти, Wi-Fi, може навіть по оптоволокну чи лазеру (якщо ви підключені до майбутнього);
• обробляється десятками серверів;
• і вже у зворотному напрямку повертається до вас — як результат у браузері.

І ось саме тут, дорогі друзі, оживає OSI-модель. Це не просто «університетська теорія» — це інструкція до реального світу даних, яка працює щосекунди навколо нас.

Тож давайте пройдемося по всіх рівнях:

• Без нудних визначень.
• Без зубріння.
• Без страху бути викликаними до дошки.

Натомість — з прикладами, живими поясненнями і (звісно ж!) котиками 🐱

🐇 Down the Rabbit Hole: рівні OSI

Готові? Бо ми зараз зробимо те, що мало хто робить за власним бажанням — спустимось на всі сім рівнів OSI. Але цього разу — без болю, без теорії заради теорії, і вже точно без лекторських «випишіть це в зошит».

Ось вони, ті самі герої нашої подорожі:

1. Прикладний рівень — Application
2. Рівень представлень — Presentation
3. Сеансовий рівень — Session
4. Транспортний рівень — Transport
5. Мережевий рівень — Network
6. Канальний рівень — Data Link
7. Фізичний рівень — Physical

🎩 Але спершу — про капелюшки й черевички

Перед тим, як пірнути в магію рівнів, згадаємо один важливий принцип: на кожному рівні є свої операнди — ті самі «логічно неподільні елементи». Я називаю їх «мережевими молекулами». Вони маленькі, але без них — ніяк.

І от щоб ці молекули не губились у мандрах, ми кожній додаємо аксесуари:

• Header — капелюшок із вказівками.
• Trailer — черевички для впевненого приземлення.

Це ніби ви пакуєте листа: кладете текст у конверт, підписуєте, додаєте адресу, штамп — і лише тоді відправляєте. Все не просто так: щоб інший рівень або інша система знала, що з цим робити.

Коли ви надсилаєте дані з комп’ютера, вони подорожують із 7-го рівня на 1-й, і на кожному з них отримують новий Header або Trailer — як багаж у аеропорту з наклейками: куди летить, чий, що всередині.

А потім, на зворотному шляху — ми всі ці «обгортки» знімаємо. Наче відкриваємо подарунок: знімаємо стрічку, шар за шаром — і, вуаля, бачимо, що там.

Без цієї упаковки — ніякого розуміння.

А без розуміння — самі знаєте... Класичний IT-діалог:

Працює у мене — шукайте проблему у себе.

🚦 Як будемо рухатись

Ми зупинимось на кожному рівні, розберемо:

• За що він відповідає.
• Які протоколи там мешкають.
• Чому взагалі він потрібен, якщо «все і так працює».

Але без фанатизму: на одному тільки прикладному рівні — з десяток популярних протоколів. Ми не будемо занурюватись у TELNET чи X.400 (це вже для гурманів). Замість цього — згадаємо ті, що живуть у повсякденному житті: HTTP, HTTPS, FTP, SMTP...

Тож влаштовуйтесь зручно, беріть чай, каву або ритуальний бубен з бекенду —
і погнали вниз, до фізики, бітів і магії сигналів.

А потім — так, ми обов’язково винирнемо. Але вже інші. Прокачані. З новим скіллом. І зі знанням, яке справді має сенс.

Прикладний рівень — там, де живе користувач

Це вершина піраміди OSI, її верхівка, її корона. Саме тут мешкає найважливіша істота у всьому цифровому світі — користувач. Тобто ми з вами. Ми, які вранці перевіряють пошту, вдень шукають «як приготувати авокадо тост», а ввечері дивляться котиків у TikTok (точніше — котики дивляться нас, але не про це зараз).

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

А щоб ця магія не була схожа на чаклунство без інструкцій, нам допомагають протоколи. Такі собі офіційні «провідники», які знають, куди йти, з ким говорити, і як не загубити повідомлення по дорозі. Ось деякі з них:

• HTTP — той самий, що керує всіма вашими гугл-запитами. Його повна назва: HyperText Transfer Protocol. Якщо коротко: «трансферимо гіпертекст». Тобто HTML, XML, JSON, Base64 — усе, що хоч трохи схоже на текст, летить через нього.
• FTP — File Transfer Protocol, тобто дружній дядько, який переносить файли туди-сюди. Можна сказати, це кур’єр із флешкою.
• SMTP — Simple Mail Transfer Protocol, протокол простого поштового щастя. Завдяки йому листи доходять, навіть якщо у вас у темі написано «привіт» і більше нічого.

Запам’ятати легко: перші літери перед «TP» розповідають, що саме переноситься. HTTP — гіпертекст, FTP — файли, SMTP — пошта.

Все чесно. Все просто. Все по-людськи. І без цього рівня... довелося б, мабуть, знову писати листи на папері. А це вже занадто хардкорно, навіть для системних адміністраторів 🙂

Рівень представлення — шифруємо, стискаємо, перекладаємо

Отже, ми вирішили скористатися HTTP, щоб знайти в Гуглі... ну звісно ж, котика. Але перш ніж пухнаста інформація вирушить у подорож мережею, вона повинна пройти важливу перевірку стилю, граматики та безпеки — на Presentation Layer. Це ніби цифрова версія офісного менеджера, який перевіряє, чи все правильно запаковано, зашифровано і стисло, перш ніж надсилати листа босу.

Цей рівень відповідає не лише за перетворення форматів, а ще й за:

• Шифрування (encryption) — щоб ваші банківські картки не перетворились на подарунки хакерам.
• Стиснення (compression) — бо навіщо передавати 1МБ, якщо можна 200КБ? Інтернет подякує.
• Переклад (translation) — щоб різні системи, як-от IBM та ASCII, не дивилися одна на одну з підозрою, а таки розуміли, хто що мав на увазі.

Цей рівень — як перекладач на конференції: бере мову одного рівня, адаптує її до іншого, і всі задоволені. І це ще півбіди! Уяви, раніше IBM і ASCII були як два сусіди, які сваряться через паркувальне місце — кожен говорить своєю мовою, і жоден не хоче поступатися. Але Presentation Layer зміг їх помирити.

Тепер про шифрування. І про Боба з Еліс (бо як же без них? 😄)

Отже, ви не просто шукаєте котика, а, скажімо, платите за доступ до елітного котячого контенту (if you know what I mean). Тут вже не до жартів. Ваші платіжні дані мають бути захищені так, ніби це пін-код від сейфу з секретами всесвіту. І тут приходить на допомогу асиметричне шифрування.

Уявімо: у нас є Боб і Еліс.

Еліс запускає Random Number + Key Generation Program (це не магія, це просто RSA, один із популярних алгоритмів) — і вуаля, отримує пару ключів:

• Публічний ключ — можна роздавати всім підряд, хоч роздрукувати на футболці.
• Приватний ключ — зберігаємо як зубну щітку: не передавати нікому, і бажано — не губити.

Боб хоче сказати «Hello, Alice!» — але не хоче, щоб його повідомлення прочитав злий хакер Карл. Тож він кладе повідомлення в коробочку і закриває її замком (публічним ключем Еліс). Відкрити її можна тільки одним ключем — приватним, який є тільки у неї. Ніхто інший, навіть Карл із ломом і Wi-Fi зламаного сусіда, не зможе його прочитати.

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

А як дізнатися, що сайт — не шахрай?

Коли ви заходите на сайт і вводите банківські дані, ви не бачите всі ці ключі, замки й сейфи. Але вони там є. Під час так званого «хендшейку» ви отримуєте публічний ключ сайту — саме його й використовуєте для зашифрування ваших даних. Якщо бачите «https://» — це як офіційна наклейка: «тут усе під контролем, шифрування ввімкнено».

І ось, коли наш котик або номер банківської карти вже зашифрований, стиснутий, переведений і перезапакований, він готовий до наступного рівня — Session Layer. І про це вже за мить 😏

Сеансовий рівень — цифровий координатор побачень

А тепер увага, бо знову змінюється головний герой — наш оперант трансформується! Тепер замість суцільного шматка даних ми маємо більш мілкі шматочки, які чемно вишикувались у чергу, як студенти в столовій. Ми їх «чейнимо» (тобто поєднуємо у логічну послідовність), додаємо свій хедер — і вперед, на новий рівень пригод!

Дані, що прийшли з рівня представлення, уже мають вигляд: стислий .zip, перекладений, зашифрований і прикрашений усіма можливими метаданими. Але цього недостатньо. Бо що буде, якщо зв’язок перерветься посеред важливої трансакції? Хто відновить бесіду з того місця, де зупинились?

Власне, сеансовий рівень — це той самий координатор, який каже:

Так, пане користувач, ось ваш канал зв’язку. Буду стежити, щоб усе було чітко, без втрат і без «перепрошую, ми обірвались...»

Його функції дуже важливі:

📞 Керування діалогом

Рівень визначає, як саме говорять процеси один з одним: по черзі (напівдуплекс) чи одночасно (повнодуплекс). Уяви, що це Zoom-дзвінок: іноді всі говорять одночасно (хаос), а іноді — по черзі (і це вже продуктивність!).

🌀 Синхронізація

Щоб у разі збою не починати все з початку, рівень ставить контрольні точки. Такі собі сейви, як у відеогрі: впав — відновився з чекпойнта, а не з першого рівня. Це ніби у хмарному сховищі, коли якийсь сервер падає, а load balancer підбігає, струшує його за плечі й кричить: «давай, живи!» — і він оживає, ніби нічого й не сталося.

🛑 Утримання сеансу

Сеансовий рівень вміє підтримувати зв’язок навіть тоді, коли додатки нічого не роблять. Він чемно сидить і чекає, поки хтось знову заговорить, щоб не довелося щоразу все запускати з нуля. Це як той друг, який не пише місяцями, але коли пишеш ти — він відповідає миттєво, бо був «на зв’язку».

Ці три рівні — прикладний, представницький і сеансовий — можна назвати «вмістовними»: вони працюють безпосередньо з даними. А от транспортний рівень уже не розбирається, що там усередині. Йому головне — переслати сегменти. Типу:

Що саме я передаю — неважливо. Головне, щоб усе дійшло цілим і неушкодженим.

Але про це — у наступному розділі! 😏

Транспортний рівень — головний логіст у світі даних

Якщо попередні рівні гарно запакували дані в коробочки з хедерами, то транспортний рівень такий:

Чудово, хлопці, але давайте я ще один хедер притулю — про всяк випадок, щоб нічого не загубилося в дорозі.

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

Цей рівень — це ніби кур’єрська служба. Але залежно від протоколу, у вас може бути:

• Надійний FedEx із трекінгом, підписом і контрольними дзвінками (TCP), або ж
• Хлопець на скейті, який кидає посилки у двір і їде далі (UDP) 😄

TCP vs UDP — битва протоколів!

🛡 TCP — Турботливий Контролер Пакетів

Тут усе серйозно:

• Є відправник (сендер) і отримувач (ресівер).
• Відправник каже: «Привіт, ось пакет № 1. Прийняв?»
• Отримувач: «Так, дякую! Чекаю наступний.»
• І так далі, поки всі не будуть щасливі.

Це називається «триступеневий хендшейк», і завдяки йому:

• Ми точно знаємо, що пакети прийшли.
• Ми знаємо, в якому порядку.
• Ми отримуємо підтвердження доставки.
• У разі чого — можемо надіслати повторно.

TCP — це як добрий друг: перевіряє, чи ти дійшов додому, і ще й каже: «напиши, коли будеш на місці».

🎲 UDP — Удачі, Друже, Передаю!

UDP — це протокол для тих, хто живе на драйві:

• Відправив — і пішов.
• Ніяких перевірок.
• Ніякого «чи дійшло?».
• Просто «лови, якщо зможеш».

Ідеально для ситуацій, коли швидкість важливіша за надійність. Наприклад:

• Онлайн-ігри 🎮
• Відеотрансляції 📺
• Дзвінки по VoIP 📞

А тепер уяви, ти граєш у гру, і раптом усе починає лагати:
герої бігають на місці, кулі летять у зворотному напрямку, а ти вже помер, але ще не знаєш про це — класичний UDP-момент 😅

Чому TCP такий надійний, а UDP — ні?

Бо TCP напханий захистом і перевірками:

• Флаги 🏁
• Сегменти 🧱
• Порти доставки й відправлення 📦📬
• І, звісно ж, додаткові хедери, як вишенька на торті.

А UDP — ні. Взагалі. Він такий собі:

Мені не треба гарантій, я йду навпростець!

Отож, транспортний рівень — це не просто посередник. Це диригент у симфонії даних, який або грає строго за партитурою (TCP), або імпровізує джаз (UDP).

Далі буде ще цікавіше! Готові перейти до мережевого рівня? 🌐

Мережевий рівень — Google Maps для даних

Отже, настав час познайомитися з мережевим рівнем — цифровим GPS, який допомагає даним знайти правильну дорогу від точки А до точки Б. І не просто «десь туди», а чітко, швидко і з урахуванням пробок в мережі 😄

Цей рівень:

• Перетворює логічні адреси у фізичні — наприклад, перетворює адресу 123.123.11.11 на hello.com і навпаки. Це як шукати «кафе біля парку» і отримати точну адресу з індексом та поверхом.
• Визначає найоптимальніший маршрут — тобто не веде вас через сусідній район, якщо можна проскочити навпростець.
• Управляє маршрутизацією, комутацією та виявляє неполадки — бо навіть у цифровому світі бувають аварії, затори і «переїхала інтернет-вантажівка, ремонт до понеділка».

Протоколи, які тут правлять бал

• IP (Internet Protocol) — це той, хто пише на коробці з даними: «Куди доставити? Від кого? Ось адреса.» І все це у вигляді чисел — бо hello.com може звучати мило, але 142.250.184.206 знає, куди саме їхати.
• RIP (Routing Information Protocol) і OSPF (Open Shortest Path First) — це наші внутрішні Waze/Google Maps. Вони обчислюють, який шлях найкращий, найшвидший і найменш обтяжений мережевими заторами. Пам’ятаєте задачку з інституту про комівояжера, якому треба обійти всі міста й повернутись назад, витративши мінімум пального? Ось тут ті самі принципи — тільки замість комівояжера в нас пакети.

А що, якщо щось пішло не так?

Раптом на маршруті стався обрив, гроза, чи хтось просто висмикнув кабель із роутера (бо «вайфай заважає мікрохвильовці»). RIP і OSPF миттєво такі:

Окей, план Б! Рухаємось іншим шляхом, усі за мною!

І переправляють трафік через інші вузли. Все оперативно, ніхто не панікує — бо мережевий рівень вміє тримати себе в руках.

І звісно ж — ще один хедер. Бо куди ж без нього?
Тепер у нас коробочка виглядає як пиріг у десять шарів:
дані → хедери → ще хедери → а ось і мережевий хедер. Але всі вони — на своєму місці.

Переходимо до канального рівня, де вже ближче до заліза, дротів і бітів? 🧷📡

Канальний рівень — лицар бітів і захисник кадрів

Чесно? Канальний рівень — це один із тих хлопців у компанії, що працює найбільше, а хвалять найменше. Тому що він сидить між реальним залізом (фізичним рівнем) і всією цією високоінтелектуальною логікою зверху, і тихенько, мовчки збирає, пакує, перевіряє, виправляє і шле дані. Не життя — а endless-цикл.

І тут стає в пригоді наш улюблений герой із підручника — Річард Велслі Хеммінг. Він подарував світові той самий алгоритм виявлення і виправлення помилок, без якого інтернет був би схожий на пошту сов — летить щось, куди — незрозуміло, і чи дійде — Боже провидіння.

Що робить канальний рівень:

• Перетворює дані в нули й одинички (і навпаки).
• Пакує біти у кадри — ніби вантажник на складі пакує коробки: акуратно, з етикетками, і з гарантією, що все доїде цілим.
• Контролює помилки — тобто перевіряє, чи не загубилась десь «1», чи не стала «0», і якщо так — «Відправ назад, це брак!».

Розрулює доступ до мережі, працює з комутаторами, містами, і каже всім: «По черзі, не штовхайтесь, кожен отримає свій слот».

Два обличчя канального рівня

У цього рівня є два підрівні, як у хорошого бургера — верхня і нижня булочка:

1. MAC (Media Access Control) — той, хто дає доступ до фізичного середовища, дозволяє пристроям «висунути руку» і сказати: «Я наступний! Моє право передати дані!». Тут і з’являються ті самі MAC-адреси — унікальні ідентифікатори мережевих пристроїв. Можна сказати, що MAC — це ніби паспортна перевірка перед входом у нічний клуб мережі.
2. LLC (Logical Link Control) — логічний контролер, який працює з мережевим рівнем, допомагає йому спілкуватися з нижнім світом фізики та заліза.

Коли дані надходять знизу догори...

Канальний рівень — як той охоронець на вході в офіс:

• Перевіряє, чи всі пакети в порядку.
• Чи не загубилися частини.
• І якщо щось не так — повертає назад з коментарем: «Перевір ще раз. Не пущу!»

І тут вже реальний світ

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

• Комутатори (Switches).
• Мости (Bridges).
• Маршрутизатори (Routers) — так, вони багаторівневі, але з канальним теж у дружбі.

І, звісно ж, тут живе наш старий добрий знайомий — Ethernet, той самий, яким підключений ваш офісний комп’ютер.

• На канальному рівні — це Ethernet IEEE 802.3.
• А на фізичному (не буду спойлерити, це далі) — там інша версія, інші стандарти, інші танці з кабелем.

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

Фізичний рівень — і струм пішов!

Ну от, дійшли ми до найглибшого шару мережевого буття — фізичного рівня. Тут усе максимально просто і водночас максимально фундаментально. Жодних JSON, хедерів чи хендшейків. Тут уже все на рівні: є струм — 1, нема струму — 0.

Азбука Морзе? Майже. Тільки замість «тук-тук» — електричні імпульси, оптичні сигнали або навіть радіохвилі, що мчать по повітрю.

Саме фізичний рівень:

• Перетворює біти на сигнали: електричні, світлові або радіо.
• Відправляє ці сигнали через середовище: дроти, повітря, оптоволокно, Wi-Fi хвилі, або, чому б і ні — супутники!
• І приймає їх на іншому кінці, щоб усе починалось заново — тільки вже у зворотному порядку.

Тут працює справжнє залізо.

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

• Концентратори (Hubs) — безмозкі, але старанні.
• Повторювачі (Repeaters) — кричать далі те, що почули ближче.
• Медіаконвертери — перекладачі з «мідної» на «волоконну» і назад.

Протоколи теж є, і не абиякі!

На фізичному рівні ми маємо цілий зоопарк стандартів:

• Wi-Fi — бездротовий улюбленець.
• Bluetooth — для навушників і «де мій телефон?».
• Ethernet — класика, дріт, надійність.
• І ще купа інших: Zigbee, NFC, інфрачервоні пульти від телевізора (серйозно, вони теж працюють на фізичному рівні!).

У кожного свій спосіб передавати одинички й нулі. І щоб усі ці стандарти працювали без взаємного побиття — є інженери-електронники, стандартизатори, та навіть цілі альянси (типу EIA), які кажуть:

Отак передаємо, отак кодуємо, і ніяких самодіяльностей!

Transmission Medium — канал, по якому летить магія

Це може бути:

• Кручена пара (той самий LAN-кабель).
• Оптоволокно (швидко, красиво, світиться).
• Коаксіальний кабель (олдовий, але ще живий).
• Супутник (привіт, Starlink!).
• Wi-Fi роутер (король хатньої мережі).

Кожен із них — це канал, через який імпульси долають кілометри, поверхи і навіть атмосферу, аби лише твій запит «котики з бантиками» знайшов свій шлях до Google.

І от, після всього цього шляху, наш запит — від милого «пошуку в браузер котика» — перетворився на струм, сигнал, імпульс, побіг по дротах, застрибнув у Wi-Fi, перелетів між точками доступу, проскочив через роутери, комутатори, репітери, і...

💥 Винирнув у Google!

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

Тепер — пора повертатися назад. Відповідь чекає. І вона має пройти весь шлях до нас. Але є один нюанс. Ми не підемо тим самим маршрутом, крок за кроком по OSI-моделі. Ні. На сцену виходить TCP/IP — практична модель, яка каже:

Ходімо коротшим шляхом. Без зайвих церемоній.

А перед тим, як почати це нове «плавання вгору», давайте поставимо обидві моделі поруч — OSI та TCP/IP — і розберемось, хто з них за що відповідає, хто віддав фронтендерам три рівні в одні руки,і чому фізичний рівень у TCP/IP так і не дочекався окремого етапу слави.

OSI vs TCP/IP — офіційна битва протоколів

Перш ніж ми з вами «винирнемо» з усіма нашими пакетами, кадрами й хедерами, варто на мить зупинитися, щоб порівняти дві моделі — еталонну OSI і практичну TCP/IP. Адже тільки тоді ми зрозуміємо, чому спускались по семи сходинках, а підіймаємось лише по чотирьох.

Як усе було в OSI

• Верхні три рівні (прикладний, представлення, сесійний) працювали з даними.
• Потім ішли сегменти, пакети, кадри і біти — кожен рівень додавав свій хедер і структурував інформацію.
• Канальний і фізичний рівні зливались у єдину точку доступу до реального світу — струму, кабелю, хвилі.

Але TCP/IP така:

Сім рівнів? Та хто ж це витримає. Давайте все по-людськи.

І ми маємо всього чотири рівні:

1. Application Layer — замість трьох з OSI (прикладного, представлень і сесійного).
2. Transport Layer — залишився без змін.
3. Internet Layer — аналог OSIшного мережевого.
4. Network Access Layer — об’єднання канального і фізичного.

Хто за що відповідає?

• Application Layer — царство розробників.
  Тут живе фронт, бек і той самий фулстек, який каже:
  «Я все вмію, але не чіпайте мене в п’ятницю ввечері.»
• Transport Layer — частково належить бекенду, частково DevOps’ам.
  Це місце, де вирішується, буде у нас «дай відповідь» чи «надіюсь, дійшло» (TCP vs UDP).
• Internet Layer — територія мережевих інженерів, що роздають IP-адреси й пінгують усе, що рухається.
• Network Access Layer — підземелля, де працюють сісадміни і техніки.
  Вони контролюють все — від витої пари до супутникових антен, і лише вони знають, чому після «висунув і всуну кабель» інтернет знову запрацював.

🐾 Винирювання — шлях назад від Google до тебе

Ми пройшли з тобою довгий шлях — від кліку в браузері до електричних імпульсів, що побігли кабелями до серверів Google. Але тепер — час винирювати. І тут усе вже не по OSI, а по TCP/IP. Чотири рівні. Мінімум філософії, максимум ефективності.

1️⃣ Рівень доступу до мережі (Network Access Layer)

Тут об’єднали все, що було канальним і фізичним в OSI. Але роботи стало більше, ніж просто передати сигнал.

Це момент, коли дані, які прибігли з data link layer, перетворюються у біти і вирушають у мандрівку фізичним середовищем:

Після того, як сигнал прибіг, ми перевіряємо:

• Чи все добре?
• Чи не загубилась жодна одиничка або нулик?

І тільки після цього дані йдуть далі. А як саме виглядає наш Ethernet на цьому рівні — ось:

Тут і преамбула, і MAC-адреси, і тип, і контрольна сума — усе для того, щоб кадр не тільки дійшов, а ще й дійшов правильно.

Це вже архітектурний рівень: access → distribution → core. На цьому рівні працюють реальні пристрої: комутатори, маршрутизатори, точки доступу — і IT Support, який іноді буквально рятує світ.

2️⃣ Мережевий рівень (Internet Layer)

Ми випірнули вище. Тут знову з’являється IP-протокол, але вже не такий багатофункціональний, як у OSI. Він:

• Не обирає маршрут.
• Не визначає логічні адреси.
• Просто приймає, перевіряє і передає далі.
  

Інформація про версію, TTL, source/destination IP, флаги, фрагментацію та ще багато чого — все всередині цього заголовка.

3️⃣ Транспортний рівень (Transport Layer)

Ось тут — головна розвилка: UDP чи TCP?

Якщо UDP: прийшли пакети → склали → передали на відображення.
Все, не питаємо, чи дійшли правильно, в якому порядку, чи хтось загубився.
Прилетів — добре. Не прилетів — теж нічого страшного 🕊️

Якщо TCP:

• Встановлюємо з’єднання (handshake).
• Контролюємо помилки.
• Гарантуємо послідовність.
• Перевіряємо доставку.

І лише після цього — передаємо дані вище. Бо ми не хочемо побачити повідомлення «? погуляємо привіт» замість «Привіт! Давай погуляємо?».

Далі за логікою ми б переходили на сесійний рівень, але ні — у нас далі прикладний рівень, який відповідає за всі три рівні... Тому...

4️⃣ Прикладний рівень (Application Layer)

Це вершина. Фінальний бос. І він тепер виконує функції трьох рівнів OSI: прикладного, представлень і сеансового.

Тут ми:

• Розшифровуємо дані.
• Розпаковуємо і decompress’имо.
• Перекладаємо (translation).
• Передаємо їх у потрібну програму або систему.

І нарешті, ми від’єднуємо останній хедер, розгортаємо відповідь — і...

🎉 Нарешті бачимо того самого котика!

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

🔚 Підсумок: з котиків — у глибини мереж

Тож, ми з вами:

• Пройшлися по всім семи рівням OSI, від прикладного до фізичного — як справжні археологи мереж.
• Занурились до найглибших шарів — де все вже не JSON, а струм і сигнали.
• Піднялись назад, але вже не по OSI, а по TCP/IP, аби побачити, як це працює в реальних системах.
• Розібрались, хто за що відповідає: розробники, девопси, адміни, техніки, а ще — добрий старий IT Support.
• Побачили різницю між TCP та UDP: один — турботливий листоноша, інший — швидкий, але злегка безвідповідальний кур’єр.
• І побіжно згадали навіть про шифрування, стиснення, translation і архівацію — бо без них у сучасному інтернеті ні кроку.

🤔 А навіщо це все?

Для того, щоб, коли хтось скаже:

Та що там — ти просто вбиваєш URL у браузері...

...ти змог(ла) відповісти:

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

🧠 Сподіваюсь, тепер вам стало трішки легше:

• Орієнтуватися в складному світі мережевих протоколів.
• Розуміти, як працює ваш інтернет-запит насправді.
• І не боятися цих загадкових слів: OSI, TCP/IP, handshake, TTL, frame, segment...

🧩 Наостанок порада

Поверніться до цієї статті, коли готуватиметесь до інтерв’ю, писатимете мережеву частину для архітектури або просто захочете пояснити другу, що «інтернет не працює, бо згорів маршрутизатор на рівні доступу до мережі». А не тому, що «Google зламався».

І головне — пам’ятайте: кожен пінг — це міні-пригода.