Спасибо за видео. Рад, что ваш канал жив! То, что TCP это ещё и 5 уровень OSI, я даже и не задумывался, но ведь там действительно идёт установление сессии... Для меня это сравни пониманию, что OSPF не совсем Link-state протокол, ведь между aria он работает, как distance-vector. Всегда интересно узнавать такие вот неожиданные мелочи в том, что ты считал, что знаешь хорошо!
Модель OSI вызывает, пожалуй, самое большое удивление в IT. Кого ни спроси - он ответит, что знает ее хорошо, но при этом людей, которые ее знали хотя бы как-то - единицы, большинство вообще не имеет представления о том, что написано в стандарте.
Стандарт и правда много кто не видел, реального, больше видим то, что уже переведено и предоставляется в учебном пособии. Бывает даже по описанию не понятно если "требуется обеспечить работу на L2 и L3", что это относится именно к "Layer OSI". В данном видео вы привели пример именно выдержки из с стандарта, в то время как большинство сразу показывает картинку уровней. Для наглядного понимания с картинками понимается естественно лучше, но думаю в рамках этого примера другая задача была. Спасибо.
Картинка с уровнями чревата тем, что возникает ассоциация со стеком заголовков. Если требуется объяснить "с нуля", то такую картинку неизбежно приходится рисовать, хотя она и не имеет никакого отношения к самой модели. Более того, если не рассказать, что на самом деле к уровням модели OSI протоколы и их заголовки не относятся вовсе, то сложится превратное впечатление о том, что бывают те самые "уровни 2.5", которые должны представляться протоколами, заголовки которых могут лежать между заголовком №2 и заголовком №3.
Спасибо за видео. И давайте уже поговорим про те самые 2.5 протоколы) Получается mpls l2 VPN решает задачи канального уровня? И корректно сказать что это технологии именно канального уровня, в частности например xconnect или PW, несмотря на то что работают опираясь на igp?
> несмотря на то что работают опираясь на 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 или другими излишне костыльными современными технологиями так и есть - они уже не полностью соответствуют требованиям этого стандарта, и потому относить их функции к уровням можно только для доказательства того, что они "недостаточно открыты" :).
Спасибо за ответ, единственное с чем бы я не согласился так это с костыльностью MPLS. Но вероятно вы имели виду с точки зрения OSI. Сама по себе технология на мой взгляд отличная, все закономерно, существует потребности современного телекома (в данном случае потребности в туннелях различного рода) как следствие возникает решение. Такие потребности вызваны необходимостью обьеденения различных сетей передачи данных в единое облако. И MPLS с точки зрения удобства и масштабируемости прекрасно решает эти задачи.
Отличнейший уроки! А правильно ли будет говорить, что к примеру bgp работает на прикладном уровне стека tcp/ip, но на сетевом OSI? И какие транспортные протоколы вообще кроме UDP и TCP? icmp, igmp, gre нет?
> правильно ли будет говорить, что к примеру 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
Иннокентий, а почему пакеты RIP использующие в качестве транспорта UDP это не уровень приложения? С таким же успехом можно назвать ssh сетевым уровнем, когда используя его мы прописываем статический маршрут.
Потому что к уровням относятся не протоколы, а функции (решаемые задачи, если угодно). Если решаемая задача - пополнение таблиц маршрутизации на транзитных узлах, то это сетевой уровень. Если цель работы протокола вы видите в том, чтобы наблюдать прохождение по сети определенных пакетов (например, запустив Wireshark), то это будет уровень приложения. Все зависит от задачи, как видите :). RIP в этом смысле не самый иллюстративный, куда забавнее в этом смысле BGP: покуда вы его используете для маршрутизации - он решает задачу сетевого уровня, а когда вы используете его на сервере Looking Glass - решаемая задача начинает относиться к уровню приложения. Пакеты, понятно, бегают те же самые, разница только в решаемой задаче.
Ну и да, если вы будете и пользовать SSH только и исключительно для назначения сетевых адресов - решаемая им задача будет сетевого уровня. Чаще все-таки мы не ограничиваем себя возможностью только управления сетевыми адресами, но позволяем отправлять через SSH произвольные команды, которые уже относятся к уровню приложения. Запустили show version хотя бы раз - все, уже зашквар, уже не сетевой уровень.
Жаль, что в начале 90х, когда нас учили в институте этому, не было ни интернета, ни этой лекции на Ютубе. Огромное спасибо за отличное изложение!
Спасибо за видео. Рад, что ваш канал жив! То, что TCP это ещё и 5 уровень OSI, я даже и не задумывался, но ведь там действительно идёт установление сессии... Для меня это сравни пониманию, что OSPF не совсем Link-state протокол, ведь между aria он работает, как distance-vector. Всегда интересно узнавать такие вот неожиданные мелочи в том, что ты считал, что знаешь хорошо!
Модель OSI вызывает, пожалуй, самое большое удивление в IT. Кого ни спроси - он ответит, что знает ее хорошо, но при этом людей, которые ее знали хотя бы как-то - единицы, большинство вообще не имеет представления о том, что написано в стандарте.
как перевернуть мир с головы на ноги, посмотреть это. Огромное спасибо. Просто великолепно.
Всегда пожалуйста, приходите еще :)
Просто великолепное видео, спасибо!
Это золото. Спасибо за видео!
Стандарт и правда много кто не видел, реального, больше видим то, что уже переведено и предоставляется в учебном пособии. Бывает даже по описанию не понятно если "требуется обеспечить работу на L2 и L3", что это относится именно к "Layer OSI". В данном видео вы привели пример именно выдержки из с стандарта, в то время как большинство сразу показывает картинку уровней. Для наглядного понимания с картинками понимается естественно лучше, но думаю в рамках этого примера другая задача была. Спасибо.
Картинка с уровнями чревата тем, что возникает ассоциация со стеком заголовков. Если требуется объяснить "с нуля", то такую картинку неизбежно приходится рисовать, хотя она и не имеет никакого отношения к самой модели. Более того, если не рассказать, что на самом деле к уровням модели OSI протоколы и их заголовки не относятся вовсе, то сложится превратное впечатление о том, что бывают те самые "уровни 2.5", которые должны представляться протоколами, заголовки которых могут лежать между заголовком №2 и заголовком №3.
Спасибо. Я и не спорю, но про "уровни 2,5" от вас впервые услышал :-) Забавно увидеть было бы такой "полуторный кадр" в деле :-)
Отличная работа.
Превосходно супер чувствуется радиотехническое образование
Выходит, когда DNS определяет сетевой адрес узла по доменному имени - служба выполняет функции сетевого уровня?
Благодарю) Шикарное видео
Просто супер видео!
Спасибо за видео. И давайте уже поговорим про те самые 2.5 протоколы) Получается mpls l2 VPN решает задачи канального уровня? И корректно сказать что это технологии именно канального уровня, в частности например xconnect или PW, несмотря на то что работают опираясь на igp?
> несмотря на то что работают опираясь на 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 или другими излишне костыльными современными технологиями так и есть - они уже не полностью соответствуют требованиям этого стандарта, и потому относить их функции к уровням можно только для доказательства того, что они "недостаточно открыты" :).
Спасибо за ответ, единственное с чем бы я не согласился так это с костыльностью MPLS. Но вероятно вы имели виду с точки зрения OSI. Сама по себе технология на мой взгляд отличная, все закономерно, существует потребности современного телекома (в данном случае потребности в туннелях различного рода) как следствие возникает решение. Такие потребности вызваны необходимостью обьеденения различных сетей передачи данных в единое облако. И MPLS с точки зрения удобства и масштабируемости прекрасно решает эти задачи.
Естественно, имелась в виду костыльность с точки зрения как оригинального протокола IP, так и ISO-шного стека протоколов.
Отличнейший уроки! А правильно ли будет говорить, что к примеру bgp работает на прикладном уровне стека tcp/ip, но на сетевом OSI? И какие транспортные протоколы вообще кроме UDP и TCP? icmp, igmp, gre нет?
> правильно ли будет говорить, что к примеру 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
Добрый день. У меня вопрос, если протоколы не относятся к уровням, тогда для чего существуют RFC 1122 и RFC1123?
Иннокентий, а почему пакеты RIP использующие в качестве транспорта UDP это не уровень приложения? С таким же успехом можно назвать ssh сетевым уровнем, когда используя его мы прописываем статический маршрут.
Потому что к уровням относятся не протоколы, а функции (решаемые задачи, если угодно). Если решаемая задача - пополнение таблиц маршрутизации на транзитных узлах, то это сетевой уровень. Если цель работы протокола вы видите в том, чтобы наблюдать прохождение по сети определенных пакетов (например, запустив Wireshark), то это будет уровень приложения. Все зависит от задачи, как видите :). RIP в этом смысле не самый иллюстративный, куда забавнее в этом смысле BGP: покуда вы его используете для маршрутизации - он решает задачу сетевого уровня, а когда вы используете его на сервере Looking Glass - решаемая задача начинает относиться к уровню приложения. Пакеты, понятно, бегают те же самые, разница только в решаемой задаче.
Ну и да, если вы будете и пользовать SSH только и исключительно для назначения сетевых адресов - решаемая им задача будет сетевого уровня. Чаще все-таки мы не ограничиваем себя возможностью только управления сетевыми адресами, но позволяем отправлять через SSH произвольные команды, которые уже относятся к уровню приложения. Запустили show version хотя бы раз - все, уже зашквар, уже не сетевой уровень.
Отсутствует графическая составляющая видео. Воспринимается информация очень сложно. Много профессиональных терминов которые не понятны новичкам.