Модель OSI

Разбираем, что такое семиуровневая модель OSI, и какие уровни в ней бывают.

[@nikolaybaranov2213]

Жаль, что в начале 90х, когда нас учили в институте этому, не было ни интернета, ни этой лекции на Ютубе. Огромное спасибо за отличное изложение!

[@morbiuzx]

Спасибо за видео. Рад, что ваш канал жив! То, что TCP это ещё и 5 уровень OSI, я даже и не задумывался, но ведь там действительно идёт установление сессии... Для меня это сравни пониманию, что OSPF не совсем Link-state протокол, ведь между aria он работает, как distance-vector. Всегда интересно узнавать такие вот неожиданные мелочи в том, что ты считал, что знаешь хорошо!

[@NetworkeducationRu]

Модель OSI вызывает, пожалуй, самое большое удивление в IT. Кого ни спроси - он ответит, что знает ее хорошо, но при этом людей, которые ее знали хотя бы как-то - единицы, большинство вообще не имеет представления о том, что написано в стандарте.

[@sergeyyakovlev6190]

как перевернуть мир с головы на ноги, посмотреть это. Огромное спасибо. Просто великолепно.

[@NetworkeducationRu]

Всегда пожалуйста, приходите еще :)

[@senseix6301]

Просто великолепное видео, спасибо!

[@subarudriver6027]

Отличная работа.

[@vasiliyk6775]

Это золото. Спасибо за видео!

[@anjelomanoranjan3908]

Благодарю) Шикарное видео

[@germanfergyson8098]

Просто супер видео!

[@ruslanruslan5583]

Превосходно супер чувствуется радиотехническое образование

[@Vic7bd]

Стандарт и правда много кто не видел, реального, больше видим то, что уже переведено и предоставляется в учебном пособии. Бывает даже по описанию не понятно если "требуется обеспечить работу на L2 и L3", что это относится именно к "Layer OSI". В данном видео вы привели пример именно выдержки из с стандарта, в то время как большинство сразу показывает картинку уровней. Для наглядного понимания с картинками понимается естественно лучше, но думаю в рамках этого примера другая задача была. Спасибо.

[@NetworkeducationRu]

Картинка с уровнями чревата тем, что возникает ассоциация со стеком заголовков. Если требуется объяснить "с нуля", то такую картинку неизбежно приходится рисовать, хотя она и не имеет никакого отношения к самой модели. Более того, если не рассказать, что на самом деле к уровням модели OSI протоколы и их заголовки не относятся вовсе, то сложится превратное впечатление о том, что бывают те самые "уровни 2.5", которые должны представляться протоколами, заголовки которых могут лежать между заголовком №2 и заголовком №3.

[@Vic7bd]

Спасибо. Я и не спорю, но про "уровни 2,5" от вас впервые услышал :-) Забавно увидеть было бы такой "полуторный кадр" в деле :-)

[@Deznak666]

Спасибо за видео. И давайте уже поговорим про те самые 2.5 протоколы) Получается mpls l2 VPN решает задачи канального уровня? И корректно сказать что это технологии именно канального уровня, в частности например xconnect или PW, несмотря на то что работают опираясь на igp?

[@NetworkeducationRu]

> несмотря на то что работают опираясь на igp? Все равно, на что они опираются, важно лишь то, какие задачи они решают. > Получается mpls l2 VPN решает задачи канального уровня? MPLS L2 VPN эмулирует общую среду передачи ("канал", "data link", "network" - можно как угодно назвать). С виртуальными сущностями за счет появления дополнительных абстракций все несколько сложнее, чем с физическими, но все равно их функции можно описать и отнести к тем или иным уровням модель OSI. Да, эти функции наверняка будут отнесены к разным уровням: часть к канальному, часть к сетевому. Честно говоря, некоторые функции, описанные в ISO/IEC 7498-1, дублируются в канальном и сетевом уровне (например, routing and relaying или error recovery), поэтому в случае обсуждения такой технологии, как псевдопровод, нужно четко понимать, что за задачу мы решаем. Если задача сформулирована как "организовать передачу данных в пределах псевдопровода", то это задача канального уровня. Если задача формулируется как "передавая пакеты между узлами, организовать эмуляцию псевдопровода для вышестоящих приложений", то там вылезают и признаки сетевого уровня, и транспортного (если будет два псевдопровода между двумя узлами, например), а то и уровня приложения (если организация этого провода - самоцель, т.е. он создан не для передачи сетевых данных поверх него). Все это очень наглядно иллюстрирует одно: конкретный протокол нельзя относить к уровням модели OSI, потому что модель OSI ничего не говорит про отнесение каких-либо протоколов к каким-либо уровням, потому что к уровням в этой модели относятся сетевые функции. Более того, конкретная функция для того, чтобы система была "открытой" с точки зрения модели OSI, не должна зависеть от функций не-соседних уровней. Формально говоря, никто не мешает конкретной системе реализовать любые функции как угодно, но тогда такая система не будет соответствовать стандарту ISO/IEC 7498-1 и не сможет называться открытой. Собственно, в случае с MPLS или другими излишне костыльными современными технологиями так и есть - они уже не полностью соответствуют требованиям этого стандарта, и потому относить их функции к уровням можно только для доказательства того, что они "недостаточно открыты" :).

[@Deznak666]

Спасибо за ответ, единственное с чем бы я не согласился так это с костыльностью MPLS. Но вероятно вы имели виду с точки зрения OSI. Сама по себе технология на мой взгляд отличная, все закономерно, существует потребности современного телекома (в данном случае потребности в туннелях различного рода) как следствие возникает решение. Такие потребности вызваны необходимостью обьеденения различных сетей передачи данных в единое облако. И MPLS с точки зрения удобства и масштабируемости прекрасно решает эти задачи.

[@NetworkeducationRu]

Естественно, имелась в виду костыльность с точки зрения как оригинального протокола IP, так и ISO-шного стека протоколов.

[@letbrick2286]

Отличнейший уроки! А правильно ли будет говорить, что к примеру bgp работает на прикладном уровне стека tcp/ip, но на сетевом OSI? И какие транспортные протоколы вообще кроме UDP и TCP? icmp, igmp, gre нет?

[@NetworkeducationRu]

> правильно ли будет говорить, что к примеру bgp работает на прикладном уровне BGP не работает ни на каком уровне. Протоколы не относятся к уровням. Если использование BGP - самоцель (например, вы хотите поставить сервер looking glass), то решаемая им задача относится к прикладному уровню. Если вы используете BGP для маршрутизации, то решаемая им задача относится к уровню межсетевого взаимодействия (network в OSI, internet в TCP/IP). Еслди вы хотите решить обе задачи, то один и тот же BGP у вас будет решать две задачи: одну третьего, и одну седьмого уровня. > какие транспортные протоколы вообще кроме UDP и TCP Вопрос сложный в силу размытости терминологии. Если считать транспортным протокол, в котором среди прочих решается задача мультиплексирования потоков приложений (т.е. то, что относится к "транспортному" уровню обеих упомянутых моделей), то традиционно к ним принято относить TCP с UDP (популярные) а также всякую экзотику (SCTP, DCCP,..) и некрофилию (RUDP, SPX,..). Если речь идет про то, что в протоколе передается просто какой-то пейлоад, относящийся к приложению, то в зависимости от усердия сюда можно вообще что угодно приплести. ICMP и IGMP назвать транспортными в любом сложновато, т.к. в них пользовательского пейлоада нет, это самостоятельные протоколы. Впрочем, при должной доле наркомании, можно инкапсулировать IP внутрь ICMP: github.com/jakkarth/icmptx

[@user-rp3um8xq2b]

Добрый день. У меня вопрос, если протоколы не относятся к уровням, тогда для чего существуют RFC 1122 и RFC1123?

[@sashashad]

Выходит, когда DNS определяет сетевой адрес узла по доменному имени - служба выполняет функции сетевого уровня?

[@olegchervyakov5924]

Иннокентий, а почему пакеты RIP использующие в качестве транспорта UDP это не уровень приложения? С таким же успехом можно назвать ssh сетевым уровнем, когда используя его мы прописываем статический маршрут.

[@NetworkeducationRu]

Потому что к уровням относятся не протоколы, а функции (решаемые задачи, если угодно). Если решаемая задача - пополнение таблиц маршрутизации на транзитных узлах, то это сетевой уровень. Если цель работы протокола вы видите в том, чтобы наблюдать прохождение по сети определенных пакетов (например, запустив Wireshark), то это будет уровень приложения. Все зависит от задачи, как видите :). RIP в этом смысле не самый иллюстративный, куда забавнее в этом смысле BGP: покуда вы его используете для маршрутизации - он решает задачу сетевого уровня, а когда вы используете его на сервере Looking Glass - решаемая задача начинает относиться к уровню приложения. Пакеты, понятно, бегают те же самые, разница только в решаемой задаче.

[@NetworkeducationRu]

Ну и да, если вы будете и пользовать SSH только и исключительно для назначения сетевых адресов - решаемая им задача будет сетевого уровня. Чаще все-таки мы не ограничиваем себя возможностью только управления сетевыми адресами, но позволяем отправлять через SSH произвольные команды, которые уже относятся к уровню приложения. Запустили show version хотя бы раз - все, уже зашквар, уже не сетевой уровень.

[@Tamago4a]

Отсутствует графическая составляющая видео. Воспринимается информация очень сложно. Много профессиональных терминов которые не понятны новичкам.