Модель OSI — це просто!

Модель Open Systems Interconnection (OSI) — це скелет, фундамент і база всіх мережевих сутностей. Модель визначає мережеві протоколи, розподіляючи їх на 7 логічних рівнів. Протокол — це певний набір правил або угод, який визначає, як відбуватиметься обмін даними. Важливо зазначити, що в будь-якому процесі, управління мережевою передачею переходить від рівня до рівня, послідовно підключаючи протоколи на кожному з рівнів.

Нижні рівні відповідають за фізичні параметри передачі, такі як електричні сигнали. Так — так, сигнали в проводах передаються за допомогою представлення в струми :) Струми представляються у вигляді послідовності одиниць і нулів (1 і 0), потім, дані декодуються і маршрутизуються по мережі. Вищі рівні охоплюють запити, пов’язані з представленням даних. Умовно кажучи, вищі рівні відповідають за мережеві дані з точки зору користувача.

Модель OSI була спочатку придумана як стандартний підхід, архітектура або патерн, який би описував мережеву взаємодію будь-якого мережевого застосунку. Давайте розберемося детальніше?

#01: Фізичний (physical) рівень
На першому рівні моделі OSI відбувається передача фізичних сигналів (струмів, світла, радіо) від джерела до одержувача. На цьому рівні ми оперуємо кабелями, контактами в роз’ємах, кодуванням одиниць і нулів, модуляцією тощо.

Серед технологій, які живуть на першому рівні, можна виділити найосновніший стандарт — Ethernet. Він є зараз у кожному будинку.

Зазначимо, що як носій даних можуть виступати не тільки електричні струми. Радіочастоти, світлові або інфрачервоні хвилі використовуються також повсюдно в сучасних мережах.

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

#02: Канальний (data Link) рівень
Уявіть, ми отримали фізичний сигнал із першого рівня — фізичного. Це набір напруг різної амплітуди, хвиль або радіочастот. Під час отримання, на другому рівні перевіряються і виправляються помилки передачі. На другому рівні ми оперуємо поняттям «фрейм», або як ще кажуть «кадр». Тут з’являються перші ідентифікатори — MAC-адреси. Вони складаються з 48 біт і мають приблизно такий вигляд: 00:16:52:00:1f:03.

Канальний рівень складний. Тому, його умовно кажучи ділять на два підрівні: управління логічним каналом (LLC, Logical Link Control) і управління доступом до середовища (MAC, Media Access Control).

На цьому рівні мешкають такі пристрої, як комутатори і мости. До речі! Стандарт Ethernet теж тут. Він затишно розташувався на першому і другому (1 і 2) рівнях моделі OSI.

#03: Мережевий (network) рівень
Йдемо вгору! Мережевий рівень вводить термін «маршрутизація» і, відповідно, IP-адресу. До речі, для перетворення IP-адрес на MAC-адреси і назад використовується протокол ARP.

Саме на цьому рівні відбувається маршрутизація трафіку, як така. Якщо ми хочемо потрапити на сайт dou.ua , то ми відправляємо DNS-запит, отримуємо відповідь у вигляді IP-адреси і підставляємо її в пакет. Так — так, якщо на другому рівні ми використовуємо термін фрейм/кадр, як ми говорили раніше, то тут ми використовуємо пакет.

З пристроїв тут живе його величність маршрутизатор :)

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

#04: Транспортний (transport) рівень
Транспортний рівень, як можна зрозуміти з назви, забезпечує передачу даних мережею. Тут дві основні рок — зірки — TCP і UDP. Різниця в тому, що різний транспорт застосовується для різної категорії трафіку. Принцип такий:

— Трафік чутливий до втрат — немає проблем, TCP (Transmission Control Protocol)! Він забезпечує контроль за передачею даних;
— Трохи втратимо — не страшно — за фактом, зараз, коли ви читаєте цю статтю, кілька пакетів могло і загубитися. Але це не відчувається для вас, як для користувача. UDP (User Datagram Protocol) вам підійде. А якби це була телефонія? Втрата пакетів там критична, оскільки голос у реальному часі почне просто «квакати»;

#05: Сеансовий (session) рівень
Сеансовий рівень займається тим, що керує з’єднаннями, або просто кажучи, сесіями. Він їх розриває.

#06 Рівень представлення (presentation)
На шостому рівні відбувається перетворення форматів повідомлень, таке як кодування або стиснення.Тут живуть JPEG і GIF, наприклад.Так само рівень відповідальний за передачу потоку на четвертий (транспортний рівень).

#07 Рівень додатків (application)
На сьомому поверсі, на самій верхівці айсберга, мешкає рівень додатків! Тут знаходяться мережеві служби, які дають змогу нам, як кінцевим користувачам, серфити простори інтернету. Гляньте, за яким протоколом у вас відкрита дана база знань? Правильно, HTTPS. Цей хлопець із сьомого поверху. Ще тут живуть простий HTTP, FTP і SMTP.

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Джентльмени в коментах, це все ясно, що в моделі OSI все дуже складно і розпливчасто, але для того і вигадали цю модель, щоб хоч якось систематизувати і змогти пояснити що там в мережі насправді відбувається. Це просто дуже спрощена і узагальнена модель і від архітектури дуже залежить кількість та тип рівнів. Щоб щось зрозуміти, спочатку треба це дуже спростити до ідеалу, а потім вже почати додавати складності.
Згадайте школу. Спочатку, коли нас вчили рахувати, казали, що від меншого числа не можна відняти більше. Потім казали, що все таки можна і вийде від’ємне число. Далі казали, що не можна ділити на нерівні частини, в подальшому виявилось, що можна і це будуть дійсні числа. Потім казали, що кореня від від’ємного числа не існує, а в університеті виявилось, що таки існує і це буде комплексне число.

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

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

Ви любите музику? Там теж є характерний принцип розподілення по стилях, жанрах і піджанрах. Наприклад, взяти стиль рок. Жанрів дуже багато, а піджанрів ще більше. Але це творчість і її кваліфікація лиш допомагає визначитись приблизно, але кожен піджанр досить умовний і часто перетікає не тільки між собою, а навіть в інші стилі. Математика — точна, а творчість — ні. Електронні засоби зв’язку — це щось середнє між творчістю і математикою.

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

поки читав виникало почуття дежавю,потім зрозумів чому))
це випадково не переклад частин цього відосу?
www.youtube.com/watch?v=je0QFU7p5Oo

Ти що робот?? Фігасє заспотив... читаю статтю по відіо ))

Взагалі стаття халтура рівня «інтернет для чайників». А виявляється ще й плагіат)

Please
Do
Not
Throw
Sausage
Pizza
Away

згадав таку мнемонему для ОСІ))

І ще

Втрата пакетів там критична, оскільки голос у реальному часі почне просто «квакати»;

скільки років тому це писалось?

Заходи по FEC, BEC і відновленню втраченого відомі десь з 2000, якщо не раніше. Да, якщо не пішли далі G.729 — їх і не буде. Ну так це камʼяний вік.

Десь рік тому Zoom почав красиво себе поводити (може, і раніше, але я не бачив): відновивши після втрат, він запитує всю передачу з момента початку втрати, а потім передає звук прискорено — але тон не підвищується. (Якщо в mplayer прискорити голос — буде мультяшний тон, якщо в youtube — буде нормальний, він вміє так стискати.) Мабуть, поки вони не втілили досить дешевий (за процесором) алгоритм такого стискання без зміни тону, було гірше — звук пропадав зовсім. Зараз чуєш те ж саме, але пізніше і пришвидчено. Мені це подобається.

Правильно, HTTPS. Цей хлопець із сьомого поверху.

Ось тут і відкривається, що автор ще нічого не розуміє в тому, що переписав з книжок ;) і йому тільки доведеться дійти до реального знання (якщо зможе).

Прикладний рівень — це як мають себе вести програми. Для HTTP(S), наприклад, це формулює правила типа «треба встановити TCP на порт 80 або 443, якщо не вказано явно, на хост, заданий через IP або отриманий з netdb відповіді (і це не обовʼязково DNS)», і «сервер слухає вхідні зʼєднання». А все інше в HTTP — на рівні 5, сеансовому. Тобто він двохрівневий. А якщо згадати норму «тип документа не вказаний — вважаємо text/html» — то і рівень 6 тут є. Те ж саме для SMTP і інших.
А в HTTPS ще складніше, тут сеанс посеред тунелю, у якого свій сеанс — тобто іде інверсія рівнів, з 7-го (який грає роль транспорта, 4-го) знову на 5-й.

Або: каже, що UDP — транспортний коли «трохи втратимо» не страшно. QUIC працює без втрат, але він поверх UDP. Фактично в ньому свій транспортний рівень, тобто в стеку з QUIC два транспортних рівня. І він не один такий — є RUDP, є KCP... да навіть DNS має фактично свій рівень гарантії за рахунок повторів! Тобто і у нього свій допоміжний транспортний рівень. 4+, так би мовити.

Книжні знання вони такі книжні, до реальности мають дуже стороннє відношення;))

«Велика сермяжна» правда тут в тому, що «народний OSI» і канонічний OSI згідно документів це «дві великі різниці»™. Уж повірте тому, хто читав ці документи:) Те як ми розуміємо OSI це величезне спрощення і узагальнення того, що придумували там собі в вежі зі слонової кістки.

Найголовніша проблема початкових розробників — в тому, що вони не припускали, що протоколи керування нижніми рівнями можуть бути на верхніх рівнях. Якийсь наприклад BGP має свою логіку аж до програм, що його виконують, зі своїми правилами де може бути учасник і що він має робити — і це вже рівено 7, а керує він рівнем 3. І це вони не могли прийняти. Тому >90% їх наробок пішло у смітник. Щось вижило (як IS-IS), але в обмежених границях. Якось працюють тільки найнижчі рівні, і то не повністю — наприклад, ми не використовуємо IEEE 802.2/802.3, ми використовуємо Ethernet II! Різниця в інтерпретації поля протокол/довжина і в відсутности SAP і SSAP, але вона критична. І так майже всюди.

Але, да, якщо відкинути такі деталі, то 10 рівнів(*) майже так як у стандартному OSI.

(*) Рівень 8 — користувач. Рівень 9 — політичний. Рівень 10 — соціальний.
Да, це вже фольклор, але цінний.

Ось дивіться, протокол, яким можна стрімити звук і відео з великою пропускною здатністю і жорстко контрольованими затримками на стадіонах, в динаміках автомобілів з активним шумоподавленням і інших подібних застосуваннях:
avnu.org/...​Networks_Rob-Silfvast.pdf
www.ieee802.org/...​-p1722-explained-0903.pdf

Скоріше за все, більшість і не знала, що таке ганяють по езернету і бачать це вперше. А тепер хопа прикол: знайдіть у цих ознайомчих документах щось про ту OSI, а тим більше спробу розкласти IEEE1722 по шарам.
От і вся потрібність цієї абстракції.
Підозрюю, що з сучасними веб-протоколами типу QUIC така сама ерозія рівнів абстракції відбувається.

А тепер хопа прикол: знайдіть у цих ознайомчих документах щось про ту OSI

Відкриваємо титульну сторінку і читаємо: IEEE1722-2011 IEEE1722 standard for Layer 2 transport protocol for Time-Sensitive Applications in Bridged Local Area Networks.
:)

А решта рівнів куди загубилось, де там межа між L2 і не L2? Воно ж модель, має натягувати на себе різні рівні.

Наприклад, маршрутизація шляхом задання різних вланів на різні фрейми, чи навіть свідомо застосовувати double VLAN tagging для шареного доступу до одного MAC з-під різних доменів під гепервізором — це теж L2 залишається, чи все ж по логіці L3?

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

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

Не гравітація натягується на інтеграл, і не коло на багатокутники, і не протоколи на модель, а навпаки

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

Це залежить від якості людей.

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

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

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

Ну тоді чітчіше треба формувати запит :)
Ви ж просили

знайдіть у цих ознайомчих документах щось про ту OSI

Вам знайшли прямо на титульній сторінці.

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

L2, тому що VLAN на L2 лежить. Нє, тут звичайно можно почати розповідати про inter-VLAN routing на свічах L3. Але проблема у тому що на рівні VLAN хедеру (L2) нічого про L3 невідомо.

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

А задання різних dstMAC на різні фрейми це теж по логіці L2 залишається, чи все ж по логіці L3? )) І в чому тоді принципова різниця між маршрутизацією пакету свічом на певний
порт на основі dstMAC і на основі VLAN tag?

P.S.: якщо честно нема бажання вичитувати весь IEEE1722 на ніч.

А задання різних dstMAC на різні фрейми це теж по логіці L2 залишається, чи все ж по логіці L3?

По логіці — L4+, Dest MAC вказується з зарезервованого під IEEE1722 multicast діапазону (91:E0:F0:00:XX:XX), дублює ідентифікатор самого аудіо/відестріму, і власне для формування каналів не використовується. Dest MAC != Src MAC отримувача.

Ну тобто, якщо у multicast RTP (або будь якого-іншого) пакета dstMAC вказано із зарезервованого і досить таки широкого мультікаст діапазону 802.3 (визначається однім бітом) і в якому

Dest MAC != Src MAC отримувача.

то це все ще L2.
А якщо для 1722

Dest MAC вказується з зарезервованого під IEEE1722 multicast діапазону (91:E0:F0:00:XX:XX)

при чому цей діапазон являється піддіапазоном 802.3 (уважно дивимось на 91 — less significant bit of the most significant byte) — то це вже

По логіці — L4+

Тобто виходить, що певні заголовки відносяться до L2 не по логіці початкової моделі, а тому що їм (непо)щастило по формату співпасти з логічним рівнем L2 для TCP/IP.

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

Тобто виходить, що певні заголовки відносяться до L2 не по логіці початкової моделі,

Перечитайте в статті про L2. Там є про LLC, MAC та ідентифікатори фреймів, хоча дещо і спрощено. Чи для вас в езернет фреймі преамбула в 7 байт та SFD в 1 байт (на основі яких залізо вирішує що далі робити з фреймом) то нормальні ідентифікатори в логіці моделі, а мак адреси, які йдуть зразу за ними і на основі яких залізо теж вирішує що далі робити з фреймом на тому ж рівні, то не в логіці моделі ))

то нормальні ідентифікатори в логіці моделі, а мак адреси, які йдуть зразу за ними і на основі яких залізо теж вирішує що далі робити з фреймом на тому ж рівні, то не в логіці моделі

Саме так — преамбула з чексумою повного фрейму навіть у дрібних мікроконтролерах зазвичай обробляються апаратно, і невалідний фрейм просто не триггерить DMA, а от ті ж маки можуть, і часто по факту обробляються софтварно.
Туди ж, наприклад, прозоре відкидання преамбули, влан тегів і чексуми при зчитуванні фреймів з сокету, RAW L2-фрейми виявляються не зовсім RAW.

Саме так

Це якщо вузько мислити топологією «зірка» як єдиною існуючою для 802.3. Як на рахунок топології «загальна шина» (той же 10Base2, 10Base5), ідентифікаторів фреймів типу MAC і в чому принципова різниця ідентифікатору преамбули і ідентифікатору MAC у цьому випадку?

Так до вузькості мислення власне і є претензія. Он ті старі протоколи, вони як коллізії детектують, чисто на L2 по певним полям в пакеті, чи все ж на деякому «L1.5», детектуючи підвищений рівень напруги на лінії в моменти, коли сигнал інжектується відразу і локальним, і віддаленим джерелом струму?

В сучасніших реалізаціях (100BASE-T1, 1000BASE-T1) ускладненням того «L1.5» взагалі вдалось зробити дуплексну передачу без колізій, причому на відміну від xDSL чи інших технологій з розділенням каналів частотною/фазовою модуляцією, воно по завадостійкості і малості затримок практично не поступається окремим витим парам.

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

На першому рівні моделі OSI відбувається передача фізичних сигналів (струмів, світла, радіо) від джерела до одержувача.

завжди цікавило — як воно знає хто одержувач, якщо маршрутизація ще «якби не відбулась». Тобто умовно кажучи — як ті електрони, чи світло знають куди «летіти»?))

Розказати ті рівні osi — просто.. а от насправді скласти пазл до купи в голові — як воно там працює не виходить(

Так що там складати, це навіть вже не OSI правда, це вже фізика

Світло йде по оптиці куди його запустили

Електромагнітні хвилі типу радіо не мають напрямку, вони в усіх напрямках. Там частота вирішує

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

електрони

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

Електромагнітна хвиля теж зі швидкістю світла рухається.

Електромагнітні хвилі типу радіо не мають напрямку, вони в усіх напрямках

Різні типи антен дивляться на тебе з подивом.

Ну ладно тут підловив, є параболічні й інші :)

Але раз ти такий розумний, то ти також знаєш що ідеальних параболічних антен нема :D

Світло йде по оптиці куди його запустили

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

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

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

Кілька пучків світла можна розділяти частотою хвилі і передавати до*** масла до*** кінцевим користувачам одночасно, і одночасно в обидва боки. Там ще є мультилексування не тільки по частоті, що дозволяє звести до*** у ступінь до***. І в серйозних кабелях, там ще до*** волокон, тому до*** множиться ще на до***

Для модератора — все це професійна лексика

світло вилітає з одного трансівера, відбивається 100500 раз по кабелю, і попадає в інший трансівер.

так а в який інший? в якийсь конкретний? чи у всі трансівери навкруги (в мережі трансівера який випустив те світло — ака broadcast)?

Ну оптоволоконний кабель з обох кінців чпокається в трансівер. Так само як ethernet-кабель чпокається з обох кінців у порт

Броадкаст то вже про ethernet
Якщо про ethernet — то он інший дядя правильно сказав. Трансівер сидить в маршрутизаторі, свічі, чи ноді чи кінцевому пристрої, це залізна розумна коробка що знає які пакети куди далі відправляти і що з ними робити

На рівні середовища нема броадкаста, там закони фізики

трансівери навкруги

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

Тільки маршрутизатор чи свіч знає куди далі пакет слати, але це інші рівні стеку, маршрутизатор чи свіч цим і займається день і ніч 365×24×7 — розгрібає мегатони пакетів з одних портів і розсилає в інші порти

На рівні середовища нема броадкаста, там закони фізики

Ethernet IEEE 802.3 (tick coax), 802,3b (thin coax), CAN, etc і взагалі всі протоколи «фізики» з методом роздільного доступу до середи типу CSMA/CD, — дивляться на вас з подивом :)

всі протоколи «фізики» з методом роздільного доступу до середи

Я так і написав

там закони фізики

Бродкаст у широкому сенсі — це не властивість протоколу, а середовища і фізики

Телесигнал з вежі теж броадкаст в такому сенсі, як і FM радіо, телевежа на мене з подивом дивиться. А я дивлюсь на неї.

Ви замість прикопуватись до нюансів і шукати де я неправ, напишіть щось позитивне про те що знаєте ви

На рівні середовища нема броадкаста

Добре, тоді що малось на увазі в цій фразі? :) Тут же немає нічого про протокол ;-)

Ви замість прикопуватись до нюансів і шукати де я неправ, напишіть щось позитивне про те що знаєте ви

Люблю, коли мені вказують, про що писати :)

так а в який інший?

Той що на іншому кінці оптоволокна. Як у трубу. З одного боку запхали, з іншого вилізло.

Краще один раз побачити ніж сто раз почути

fiberopticsof.files.wordpress.com/...​transceiver-structure.jpg

blog.router-switch.com/...​2014/10/transceivers1.jpg

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

www.arista.com/en/products/platforms

Виглядає все це в купі десь якось так, тільки трохи не так чисто й пусто, все це дуже схоже на звичайну мідну мережу
www.fiberopticshare.com/...​of-top-of-rack-switch.png

Це все тільки про ethernet, єсішо, є купа іншого лайна типу infiniband чи fc

Схоже, це просто тролль.

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

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

Розказати ті рівні osi — просто.. а от насправді скласти пазл до купи в голові — як воно там працює не виходить(

Купіть раутера, підʼєднайте інтернет і пару лаптопів і експериментуйте — поступово складеться;)

VoIP працює на кількох протоколах, якісь пакети критичні, якісь ні.

Оба по своєму неправі

— Трохи втратимо — не страшно — за фактом, зараз, коли ви читаєте цю статтю, кілька пакетів могло і загубитися. Але це не відчувається для вас, як для користувача. UDP (User Datagram Protocol) вам підійде. А якби це була телефонія? Втрата пакетів там критична, оскільки голос у реальному часі почне просто «квакати»;

То ж рівно навпаки, HTTPS (через який ми і читаємо цю статтю) використовує TCP-сесії, а в IP-телефонії як раз використовується UDP. Ну і від втрати пакетів жоден протокол не захистить, просто TCP має вбудовані (і досить складні) механізми перезапиту втрачених пакетів.

Ну і від втрати пакетів жоден протокол не захистить

Нууу не зовсім

en.m.wikipedia.org/...​_automatic_repeat_request

Канал може бути настільки паршивим, що жоден Рід з Соломоном не допоможуть, тільки перезапитувати.

Ну але ж працює інтернет у твоїм смартфоні :)

Це не перезапитування, але воно звісно працює в комбінації, покращення ткскзть

Це не перезапитування

ARQ — як раз перезапитування, і в комбінації дійсно краще. А інтернет в смартфоні в ліфті працює хріново, наприклад :)

Ладно, ну звісно як нема сигнала, які там пакети. Але фіксити пропущені з детекшеном на льоту — цілком ріал

Пойнт же був про захистити від втрати пакетів, а не від втрати сигналу :)

Я не про ARQ, я про FEC

Як вже приколупуватися то ретрансміт і є метод захисту від втрати пакета. Просто хотілося ткскзть чистий контраргумент навести про прям захист від втрати-втрати, а не про висилку копії

Просто хотілося ткскзть чистий контраргумент навести про прям захист від втрати-втрати, а не про висилку копії

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

а в IP-телефонії як раз використовується UDP.

IP-телефонія вона, мʼяко кажучи, різна.
SIP сігналізація працює і з UDP (зі власною схемою перепосилки), і з TCP.
Голос залежить від кодека. Типово таки UDP, але є і реалізації поверх TCP. Колись «connection oriented media extentions» (драфт, який не прийняли формально, але з нього більшість була реалізована) вимагав переходу медії на TCP.
Ще є SCTP, але на нього тут якось не дуже перейшли (якщо не 3GPP аж до 5G-6G, де половина сигналізації на ньому).

OSI це шо завгодно, тільки не просто

Просто це тільки для тих хто крім пари відомих протоколів з TCP/IP іншого пороху не нюхав

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

Серед технологій, які живуть на першому рівні, можна виділити найосновніший стандарт — Ethernet

А WiFi от і не Ethernet :)

#06 Рівень представлення (presentation)
На шостому рівні відбувається перетворення форматів повідомлень, таке як кодування або стиснення.Тут живуть JPEG і GIF, наприклад

Nope, presentation ето другоє. Мирославе, сідай, два

Алк стаття зачотна, просто прикапуюсь

Створити/запрограмувати діючу модель OSI не просто.

Яка «база знань»? Ви хоч редагуйте копі пасту.

Хтось забороняє називати DOU базою знань?

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

Так, я запитую.
Це база, про яку бажано мати уявлення.

Так, це умовна ідеальна модель, яка в реальності не зустрічається, бо реальність складніша.

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

У меня неоднократно спрашивали, в эмбеддед без этого никак.

Запитують, тільки потім в реальності працюєш з TCP/IP)

Або з проблемами «як вирахувати правильний MAC адрес, якщо на іншому кінці може бути CARP, а може і не бути, а відправляється з іншого адресу» :)
До IP тут ще не дійшло.

Підписатись на коментарі