Комментарии 33
Подводя итоги:
Модель OSI писалась телекомщиками (телефонистами) и бюрократами и в полной мере учитывала интересы операторов телефонной связи и бюрократов.
Модель TCP/IP писалась бородатыми хакерами для себя и в полной мере учитывала интересы пользователей сети и разработчиков ПО для работы с сетью.
В модели OSI было очень комфортно ходить по уровням, раскладывать по красивым графикам и табличкам, где всё гладенько и ровно, а так же очень удобно пускать голосовой трафик. Интересы программистов при этом никого не волновали, а пользователи, которым этим было бы удобно пользоваться должны были ощущать удобство при использовании телефонной связи.
А бородатые хакеры хотели быстро и офигенно. С плохо выраженными уровнями (ARP/IP), с начхательством на стандарты для того, что ещё не существует (всякие «presentation level»). И оно получилось достаточно простым, чтобы его можно было реализовать в любой ОС без команды с waterfall на десять лет, достаточно эффективно, чтобы пролазить через любой канал связи и при этом работать не смотря на его качество, и достаточно понятно, чтобы любой начинающий за неделю полностью осваивался с терминологией и объектами.
Очевидно, OSI умерла. Настолько умерла, что сейчас даже связисты уже переходят на пакетную коммутацию.
Модель OSI писалась телекомщиками (телефонистами) и бюрократами и в полной мере учитывала интересы операторов телефонной связи и бюрократов.
Модель TCP/IP писалась бородатыми хакерами для себя и в полной мере учитывала интересы пользователей сети и разработчиков ПО для работы с сетью.
В модели OSI было очень комфортно ходить по уровням, раскладывать по красивым графикам и табличкам, где всё гладенько и ровно, а так же очень удобно пускать голосовой трафик. Интересы программистов при этом никого не волновали, а пользователи, которым этим было бы удобно пользоваться должны были ощущать удобство при использовании телефонной связи.
А бородатые хакеры хотели быстро и офигенно. С плохо выраженными уровнями (ARP/IP), с начхательством на стандарты для того, что ещё не существует (всякие «presentation level»). И оно получилось достаточно простым, чтобы его можно было реализовать в любой ОС без команды с waterfall на десять лет, достаточно эффективно, чтобы пролазить через любой канал связи и при этом работать не смотря на его качество, и достаточно понятно, чтобы любой начинающий за неделю полностью осваивался с терминологией и объектами.
Очевидно, OSI умерла. Настолько умерла, что сейчас даже связисты уже переходят на пакетную коммутацию.
Ох, надо было сразу отмотать на этот комментарий! Спасибо!
Хм. OSI умерла? Скорее, она даже не рождалась. Однако, именно её идеи и легли всюду, куда только можно, а её модель используется для взаимопонимания и поныне.
Как -то не сильно отличаются бородатые хакеры от бюрократов, учитывая, что модели отличаются только тем, что прикладной уровень поглотил представления и сеансовый (так как все три описывают программные вещи), а насчёт того, различаются ли в TCP/IP физический и канальный уровни, ходят споры ( en.wikipedia.org/wiki/Internet_protocol_suite#Layer_names_and_number_of_layers_in_the_literature ). С одной стороны, сложно представить разные физические уровни для Wi-Fi, а с другой — Ethernet соединения могут быть и по меди, и по оптике, и с разной скоростью.
> С плохо выраженными уровнями (ARP/IP),
Эм. А чем они плохо выражены?
> стандарты для того, что ещё не существует (всякие «presentation level»).
По-сути, идея была в том, что одно и то же можно передавать разными способами (например, через XML, JSON). По замыслу, здесь должна была бы происходить сериализация.
Как -то не сильно отличаются бородатые хакеры от бюрократов, учитывая, что модели отличаются только тем, что прикладной уровень поглотил представления и сеансовый (так как все три описывают программные вещи), а насчёт того, различаются ли в TCP/IP физический и канальный уровни, ходят споры ( en.wikipedia.org/wiki/Internet_protocol_suite#Layer_names_and_number_of_layers_in_the_literature ). С одной стороны, сложно представить разные физические уровни для Wi-Fi, а с другой — Ethernet соединения могут быть и по меди, и по оптике, и с разной скоростью.
> С плохо выраженными уровнями (ARP/IP),
Эм. А чем они плохо выражены?
> стандарты для того, что ещё не существует (всякие «presentation level»).
По-сути, идея была в том, что одно и то же можно передавать разными способами (например, через XML, JSON). По замыслу, здесь должна была бы происходить сериализация.
arp — датаграмма или фрейм?
По сути, датаграмма и фрейм — это одно и то же, только у разных уровней. Transmisson unit мне больше нравится, того самого бюрократизма меньше.
А если по определению RFC 1594:
Datagram — A self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network.
То точно фрейм, т.к. не выполняется «carrying sufficient information to be routed from the source to the destination computer» — адрес неизвестен, он широковещательный. Да и к «entity of data» и «self-contained» можно придраться.
А если по определению RFC 1594:
Datagram — A self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network.
То точно фрейм, т.к. не выполняется «carrying sufficient information to be routed from the source to the destination computer» — адрес неизвестен, он широковещательный. Да и к «entity of data» и «self-contained» можно придраться.
Ответы на arp не широковещательные и в общем случае могут быть отмаршрутизированы (но зачем?)
С другой стороны: бродкастная датаграмма — это не датаграмма?
С другой стороны: бродкастная датаграмма — это не датаграмма?
> Ответы на arp не широковещательные и в общем случае могут быть отмаршрутизированы (но зачем?)
Это не стандартное поведение. RFC 826 чётко указывает:
Send the packet to the (new) target hardware address on the same hardware on which the request was received.
> С другой стороны: бродкастная датаграмма — это не датаграмма?
Интересное словосочетание — «бродкастная датаграмма». То есть, кому-то может понадобиться отсылать данные сразу всем? Широковещание пока ещё используется (хоть это и плохая практика) для поиска: в ARP — для поиска MAC по IP, в DHCP — для поиска сервера. Корректно ли говорить что передаются данные? Я думаю, нет.
Это не стандартное поведение. RFC 826 чётко указывает:
Send the packet to the (new) target hardware address on the same hardware on which the request was received.
> С другой стороны: бродкастная датаграмма — это не датаграмма?
Интересное словосочетание — «бродкастная датаграмма». То есть, кому-то может понадобиться отсылать данные сразу всем? Широковещание пока ещё используется (хоть это и плохая практика) для поиска: в ARP — для поиска MAC по IP, в DHCP — для поиска сервера. Корректно ли говорить что передаются данные? Я думаю, нет.
А что же тогда передается?
А что такого странного в бродкастном UDP? Любой протокол может включать в себя бродкасты, и виндовая сетка отличный тому пример. DHCP всего лишь один из примеров, причём довольно специфичный (т.к. там есть ip 0.0.0.0), но есть бродкасты с юникастного адреса — и это вполне себе часть IP протокола.
То есть, кому-то может понадобиться отсылать данные сразу всем?
Рассыльщики спама давно об этом мечтают.
НЛО прилетело и опубликовало эту надпись здесь
Пожалуй, вывод можно ещё более сократить до старого, как мир: «Будь проще — и к тебе люди потянутся». :)
KISS и т.д.
Проблема же в другом — как сделать так, чтобы получившееся было при этом универсальным, высокофункциональным и при этом очень простым.
Очень, очень сложно придумать такое. Задним числом очевидно, а когда думаешь о проблеме в будущем времени, не имея примеров удачного решения той же проблемы, свалиться в «OSI-style» проще, чем кажется. Потому что с точки зрения grand design OSI проще, чем TCP/IP. Её проще объяснять и сформулировать.
Проблема же в другом — как сделать так, чтобы получившееся было при этом универсальным, высокофункциональным и при этом очень простым.
Очень, очень сложно придумать такое. Задним числом очевидно, а когда думаешь о проблеме в будущем времени, не имея примеров удачного решения той же проблемы, свалиться в «OSI-style» проще, чем кажется. Потому что с точки зрения grand design OSI проще, чем TCP/IP. Её проще объяснять и сформулировать.
Забавная статья. Насколько я понял, OSI, кроме модели, которая описана в учебниках, ещё и разрабатывала непосредственно реализации протоколов для каждого уровня. Т.е. от деятельности OSI осталась только модель, а уже конкретные протоколы Интернета были предложены DARPA.
От статьи остаётся ощущение, что OSI провалилась полностью и покрыта забвением, и у меня вопрос:
Один из самых популярных стэков протоколов (Ethernet/IP/TCP/HTTP) разве не укладывается в модели OSI?
Здесь Ethernet нормально делится на два слоя (помимо MAC-адресации, есть ведь ещё какой-то протокол на уровне электрических сигналов), а HTTP просто объединил в себе три последних прикладных уровня.
Картинка для напоминания…
От статьи остаётся ощущение, что OSI провалилась полностью и покрыта забвением, и у меня вопрос:
Один из самых популярных стэков протоколов (Ethernet/IP/TCP/HTTP) разве не укладывается в модели OSI?
Здесь Ethernet нормально делится на два слоя (помимо MAC-адресации, есть ведь ещё какой-то протокол на уровне электрических сигналов), а HTTP просто объединил в себе три последних прикладных уровня.
Картинка для напоминания…
> Один из самых популярных стэков протоколов (Ethernet/IP/TCP/HTTP) разве не укладывается в модели OSI?
Умоляю, не придумывайте свои названия для TCP/IP. Вместо HTTP может быть хотя бы HTTPS или вообще FTP, а вместо Ethernet — Wi-Fi или LTE. Но ведь это не другой стек. На вопрос я ответил выше — не то что укладываются, это, по-сути, одно и то же, только в название вошли два самых популярных протокола — TCP и IP. Хотя вместо TCP может быть UDP, а вместо IP — IPSec или ICMP.
> Здесь Ethernet нормально делится на два слоя (помимо MAC-адресации, есть ведь ещё какой-то протокол на уровне электрических сигналов)
100-BASE-T (Fast Ethernet) и им подобные не являются протоколами, это стандарты и, по сути, являются дополнением к самому Ethernet, у которого структура кадра, алгоритм работы и т.д. остаются одними и теми же. Но да, стандарты-то разные, так что тут много спекуляций и нет единого решения. Как правило, людям проще понимать и запоминать, если включать физический уровень.
> а HTTP просто объединил в себе три последних прикладных уровня.
А тут тоже можно подискутировать. Например, сказать, что TLS (и ранее SSL) — это и сеансовый уровень (учитывая, что между узлами устанавливается связь, для которой выделяется сеансовый ключ), и также уровень представления, т.к. он шифрует данные (меняет представление), не меняя самих данных.
Умоляю, не придумывайте свои названия для TCP/IP. Вместо HTTP может быть хотя бы HTTPS или вообще FTP, а вместо Ethernet — Wi-Fi или LTE. Но ведь это не другой стек. На вопрос я ответил выше — не то что укладываются, это, по-сути, одно и то же, только в название вошли два самых популярных протокола — TCP и IP. Хотя вместо TCP может быть UDP, а вместо IP — IPSec или ICMP.
> Здесь Ethernet нормально делится на два слоя (помимо MAC-адресации, есть ведь ещё какой-то протокол на уровне электрических сигналов)
100-BASE-T (Fast Ethernet) и им подобные не являются протоколами, это стандарты и, по сути, являются дополнением к самому Ethernet, у которого структура кадра, алгоритм работы и т.д. остаются одними и теми же. Но да, стандарты-то разные, так что тут много спекуляций и нет единого решения. Как правило, людям проще понимать и запоминать, если включать физический уровень.
> а HTTP просто объединил в себе три последних прикладных уровня.
А тут тоже можно подискутировать. Например, сказать, что TLS (и ранее SSL) — это и сеансовый уровень (учитывая, что между узлами устанавливается связь, для которой выделяется сеансовый ключ), и также уровень представления, т.к. он шифрует данные (меняет представление), не меняя самих данных.
От OSI осталась не только модель (которая в учебниках и ГОСТ), но и как минимум протокол маршрутизации IS-IS.
Конкретные протоколы Интернета созданы, всё-таки, участниками IETF, DARPA — это больше источник (распределитель) финансирования. Подробнее о том что, в каком порядке и кто предложил или разработал можно посмотреть, например, в книге Where wizards stay up late (не смог сходу найти ничего лучше чем amazon).
Конечно, при желании вы можете многое уложить в модель. Но это постфактум. Однако, стек TCP/IP не разрабатывался в рамках модели OSI. Он разрабатывался другими инженерами, в другой организации, для несколько другой сети. То как он нарисован напротив модели OSI на иллюстрации — это, скорее, условность. Возможно — даже подгон желаемого к действительному (или наоборот). Такой подгон делают, отчасти, что бы хоть как-то обосновать присутствие модели OSI в учебнике (и после этого, обычно, на оставшиеся 800 страниц учебника про неё забывают), отчасти потому что, как верно замечает выше amarao, в ней всё по полочкам и с моделью OSI удобнее рисовать графики и таблички.
Конкретные протоколы Интернета созданы, всё-таки, участниками IETF, DARPA — это больше источник (распределитель) финансирования. Подробнее о том что, в каком порядке и кто предложил или разработал можно посмотреть, например, в книге Where wizards stay up late (не смог сходу найти ничего лучше чем amazon).
Конечно, при желании вы можете многое уложить в модель. Но это постфактум. Однако, стек TCP/IP не разрабатывался в рамках модели OSI. Он разрабатывался другими инженерами, в другой организации, для несколько другой сети. То как он нарисован напротив модели OSI на иллюстрации — это, скорее, условность. Возможно — даже подгон желаемого к действительному (или наоборот). Такой подгон делают, отчасти, что бы хоть как-то обосновать присутствие модели OSI в учебнике (и после этого, обычно, на оставшиеся 800 страниц учебника про неё забывают), отчасти потому что, как верно замечает выше amarao, в ней всё по полочкам и с моделью OSI удобнее рисовать графики и таблички.
> Такой подгон делают, отчасти, что бы хоть как-то обосновать присутствие модели OSI в учебнике (и после этого, обычно, на оставшиеся 800 страниц учебника про неё забывают)
Такие понятия как L2 и L3 коммутаторы без моодели OSI бессмысленны. Без модели сложно объяснить, почему коммутатор не может быть шлюзом. Почему можно поменять TCP на UDP и всё будет работать, а почему нельзя поменять TCP на… HTTP или IP, например? Для чего нужна MAC адресация, если есть IP? И как вообще обмениваться данными с двухадресным устройством?
А ещё есть не-TCP/IP передача данных. Например, в промышленной автоматизации с кучей своих шин, а ещё ISDN, Dial-Up и множество разных и интересных вещей.
Такие понятия как L2 и L3 коммутаторы без моодели OSI бессмысленны. Без модели сложно объяснить, почему коммутатор не может быть шлюзом. Почему можно поменять TCP на UDP и всё будет работать, а почему нельзя поменять TCP на… HTTP или IP, например? Для чего нужна MAC адресация, если есть IP? И как вообще обмениваться данными с двухадресным устройством?
А ещё есть не-TCP/IP передача данных. Например, в промышленной автоматизации с кучей своих шин, а ещё ISDN, Dial-Up и множество разных и интересных вещей.
L3 коммутатор в IP — это просто маршрутизатор. Само понятие «L3 коммутатор» отделили от маршрутизаторов, скорее, по маркетинговым соображениям.
В модели TCP/IP L2 коммутаторы Ethernet (которые просто эмулируют общую шину) не являются необходимостью.
Про это редко говорят в учебниках, из-за OSI-мышления, но вы можете поменять TCP на UDP и [почти] всё будет работать. Вы также можете прилепить HTTP сразу поверх IP, если ваши оконечные узлы (а также любые устройства на пути трафика из числа нарушающих принцип end-to-end, например NAT) будут это поддерживать. Често, просто напишите соответствующий код. Оно [наверняка] не будет ни с чем больше совместимо (потому что редко кто так поступает), но вы, однако, можете это сделать. Вы можете настекировать двадцать разных заголовков друг на друга, если это поможет вашим данным передаваться лучше.
МАС адресация на нужна. Всё равно многие соединения — это точка-точка. МАС адреса были нужны во времена общей шины Ethernet (и, кажется, кольца TokenRing), чтобы станция на шине могла определить, следует ли ей принять и обработать фрейм с провода. Это атавизм от которого не могут отказаться по неким соображениям, например обратной совместимости. Вот, наверное, для этой совместимости в Ethernet и сохраняют МАС-адреса.
А как сейчас обмениваются данными с двухадресным устройством? Или я не понял вопрос, или возьмите в пример IPv6, где у каждого устройства на каждом интерфейсе может спокойно быть по несколько адресов.
Не TCP/IP передача данных — отдельный вопрос. Там, в промышленной автоматизации, тоже у каждого инженера своя голова и каждый, в первую очередь, проектировал как было нужно для его станка/установки. Некоторые могли отталкиваться от модели OSI, другие нет.
В дайлапе, ведь, поверх физики (которая, между делом, где-то по середине может пересекать ISDN-сеть) работает, скажем, PPP. А для доступа в Интернет по дайлапу, поверх PPP пускают IP.
Интересных вещей много, да. Сети вообще очень разнообразны. Не от хорошей жизни, полагаю. «Если бы всё пошло по плану» — всё было бы OSI. Однако от разнообразия мы рано или поздно придём к общему знаменателю. Наверное это будет IP.
В модели TCP/IP L2 коммутаторы Ethernet (которые просто эмулируют общую шину) не являются необходимостью.
Про это редко говорят в учебниках, из-за OSI-мышления, но вы можете поменять TCP на UDP и [почти] всё будет работать. Вы также можете прилепить HTTP сразу поверх IP, если ваши оконечные узлы (а также любые устройства на пути трафика из числа нарушающих принцип end-to-end, например NAT) будут это поддерживать. Често, просто напишите соответствующий код. Оно [наверняка] не будет ни с чем больше совместимо (потому что редко кто так поступает), но вы, однако, можете это сделать. Вы можете настекировать двадцать разных заголовков друг на друга, если это поможет вашим данным передаваться лучше.
МАС адресация на нужна. Всё равно многие соединения — это точка-точка. МАС адреса были нужны во времена общей шины Ethernet (и, кажется, кольца TokenRing), чтобы станция на шине могла определить, следует ли ей принять и обработать фрейм с провода. Это атавизм от которого не могут отказаться по неким соображениям, например обратной совместимости. Вот, наверное, для этой совместимости в Ethernet и сохраняют МАС-адреса.
А как сейчас обмениваются данными с двухадресным устройством? Или я не понял вопрос, или возьмите в пример IPv6, где у каждого устройства на каждом интерфейсе может спокойно быть по несколько адресов.
Не TCP/IP передача данных — отдельный вопрос. Там, в промышленной автоматизации, тоже у каждого инженера своя голова и каждый, в первую очередь, проектировал как было нужно для его станка/установки. Некоторые могли отталкиваться от модели OSI, другие нет.
В дайлапе, ведь, поверх физики (которая, между делом, где-то по середине может пересекать ISDN-сеть) работает, скажем, PPP. А для доступа в Интернет по дайлапу, поверх PPP пускают IP.
Интересных вещей много, да. Сети вообще очень разнообразны. Не от хорошей жизни, полагаю. «Если бы всё пошло по плану» — всё было бы OSI. Однако от разнообразия мы рано или поздно придём к общему знаменателю. Наверное это будет IP.
> L3 коммутатор в IP — это просто маршрутизатор. Само понятие «L3 коммутатор» отделили от маршрутизаторов, скорее, по маркетинговым соображениям.
Эээ, нет. L3 коммутатор — это-таки коммутатор, при том что он может иметь функции третьего уровня (при этом быть дешевле маршрутизатора, в чём его плюс). Да, он может поддерживать все протоколы третьего уровня, включая маршрутизирующие, но главное отличие коммутаторов и маршрутизаторов — свой IP и MAC для КАЖДОГО порта у L3 коммутаторов не сохраняется. Например, многие домашние «роутеры» (у которых всего 1 WAN порт, а все остальные — LAN + Wi-Fi) — это как раз-таки не маршрутизаторы, а коммутаторы третьего уровня, именно что по маркетинговым соображениям названные маршрутизаторами.
> В модели TCP/IP L2 коммутаторы Ethernet (которые просто эмулируют общую шину) не являются необходимостью.
В Ethernet общей шины нет уже 35 лет, так что про эмуляцию шины я не понял. И я как бы говорил об объяснении L2 коммутаторов через модель OSI, а не TCP/IP.
>Про это редко говорят в учебниках, из-за OSI-мышления, но вы можете поменять TCP на UDP и [почти] всё будет работать. Вы также можете прилепить HTTP сразу поверх IP, если ваши оконечные узлы (а также любые устройства на пути трафика из числа нарушающих принцип end-to-end, например NAT) будут это поддерживать. Често, просто напишите соответствующий код. Оно [наверняка] не будет ни с чем больше совместимо (потому что редко кто так поступает), но вы, однако, можете это сделать. Вы можете настекировать двадцать разных заголовков друг на друга, если это поможет вашим данным передаваться лучше.
Про TCP и UDP я точно также написал выше. С остальным согласен, даже дополню: можно вообще обойтись и без HTTP, и без IP, и без Ethernet, а просто написать низкоуровневый код для сетевой карты и отправлять свои биты, свои заголовки и вообще всё своё. Но никто этого не делает, конечно же: зачем, если всё это уже сделано до нас?
> МАС адресация на нужна. Всё равно многие соединения — это точка-точка. МАС адреса были нужны во времена общей шины Ethernet (и, кажется, кольца TokenRing), чтобы станция на шине могла определить, следует ли ей принять и обработать фрейм с провода. Это атавизм от которого не могут отказаться по неким соображениям, например обратной совместимости. Вот, наверное, для этой совместимости в Ethernet и сохраняют МАС-адреса.
MAC адресация не нужна в идеальном мире. Как и IPv4, например. В существующем — нужна, без этого сети не смогут работать. Самое главное применение MAC адресов на данный момент — поиск IP адреса: не нужно угадывать подсеть и адрес устройства, можно найти его по LLDP. Сильно помогает при первоначальной настройке множества узлов (когда IP один на всех, или его вообще нет) и при техобслуживании. Когда-нибудь уйдёт IPv4, скорее всего уйдёт и Ethernet вместе с MAC-ами, будет один большой IPv6 над всеми, кто знает. Но это будет не скоро, по многим причинам.
> А как сейчас обмениваются данными с двухадресным устройством? Или я не понял вопрос, или возьмите в пример IPv6, где у каждого устройства на каждом интерфейсе может спокойно быть по несколько адресов.
Вопрос был риторический. Но если вы студент или школьник, без понимания разноуровневых протоколов, сложно объяснить, как общаться между узлами. Инкапсуляция, вот это всё.
> Не TCP/IP передача данных — отдельный вопрос. Там, в промышленной автоматизации, тоже у каждого инженера своя голова и каждый, в первую очередь, проектировал как было нужно для его станка/установки. Некоторые могли отталкиваться от модели OSI, другие нет.
В промышленной автоматизации всё движется в сторону TCP/IP. Даже не движется, а уже давно используется. Однако, те самые шины должны быть внедрены в общую систему. Которую, вероятно, делают уже другие инженеры.
> Однако от разнообразия мы рано или поздно придём к общему знаменателю. Наверное это будет IP.
Скорее всего. Однако, сам IP не так-то просто модифицировать и изменить. Об IPv6 уже сто-о-о-олько лет мечтают все сетевики, хостеры, вебмастера и прочие, а вот всё никак.
Эээ, нет. L3 коммутатор — это-таки коммутатор, при том что он может иметь функции третьего уровня (при этом быть дешевле маршрутизатора, в чём его плюс). Да, он может поддерживать все протоколы третьего уровня, включая маршрутизирующие, но главное отличие коммутаторов и маршрутизаторов — свой IP и MAC для КАЖДОГО порта у L3 коммутаторов не сохраняется. Например, многие домашние «роутеры» (у которых всего 1 WAN порт, а все остальные — LAN + Wi-Fi) — это как раз-таки не маршрутизаторы, а коммутаторы третьего уровня, именно что по маркетинговым соображениям названные маршрутизаторами.
> В модели TCP/IP L2 коммутаторы Ethernet (которые просто эмулируют общую шину) не являются необходимостью.
В Ethernet общей шины нет уже 35 лет, так что про эмуляцию шины я не понял. И я как бы говорил об объяснении L2 коммутаторов через модель OSI, а не TCP/IP.
>Про это редко говорят в учебниках, из-за OSI-мышления, но вы можете поменять TCP на UDP и [почти] всё будет работать. Вы также можете прилепить HTTP сразу поверх IP, если ваши оконечные узлы (а также любые устройства на пути трафика из числа нарушающих принцип end-to-end, например NAT) будут это поддерживать. Често, просто напишите соответствующий код. Оно [наверняка] не будет ни с чем больше совместимо (потому что редко кто так поступает), но вы, однако, можете это сделать. Вы можете настекировать двадцать разных заголовков друг на друга, если это поможет вашим данным передаваться лучше.
Про TCP и UDP я точно также написал выше. С остальным согласен, даже дополню: можно вообще обойтись и без HTTP, и без IP, и без Ethernet, а просто написать низкоуровневый код для сетевой карты и отправлять свои биты, свои заголовки и вообще всё своё. Но никто этого не делает, конечно же: зачем, если всё это уже сделано до нас?
> МАС адресация на нужна. Всё равно многие соединения — это точка-точка. МАС адреса были нужны во времена общей шины Ethernet (и, кажется, кольца TokenRing), чтобы станция на шине могла определить, следует ли ей принять и обработать фрейм с провода. Это атавизм от которого не могут отказаться по неким соображениям, например обратной совместимости. Вот, наверное, для этой совместимости в Ethernet и сохраняют МАС-адреса.
MAC адресация не нужна в идеальном мире. Как и IPv4, например. В существующем — нужна, без этого сети не смогут работать. Самое главное применение MAC адресов на данный момент — поиск IP адреса: не нужно угадывать подсеть и адрес устройства, можно найти его по LLDP. Сильно помогает при первоначальной настройке множества узлов (когда IP один на всех, или его вообще нет) и при техобслуживании. Когда-нибудь уйдёт IPv4, скорее всего уйдёт и Ethernet вместе с MAC-ами, будет один большой IPv6 над всеми, кто знает. Но это будет не скоро, по многим причинам.
> А как сейчас обмениваются данными с двухадресным устройством? Или я не понял вопрос, или возьмите в пример IPv6, где у каждого устройства на каждом интерфейсе может спокойно быть по несколько адресов.
Вопрос был риторический. Но если вы студент или школьник, без понимания разноуровневых протоколов, сложно объяснить, как общаться между узлами. Инкапсуляция, вот это всё.
> Не TCP/IP передача данных — отдельный вопрос. Там, в промышленной автоматизации, тоже у каждого инженера своя голова и каждый, в первую очередь, проектировал как было нужно для его станка/установки. Некоторые могли отталкиваться от модели OSI, другие нет.
В промышленной автоматизации всё движется в сторону TCP/IP. Даже не движется, а уже давно используется. Однако, те самые шины должны быть внедрены в общую систему. Которую, вероятно, делают уже другие инженеры.
> Однако от разнообразия мы рано или поздно придём к общему знаменателю. Наверное это будет IP.
Скорее всего. Однако, сам IP не так-то просто модифицировать и изменить. Об IPv6 уже сто-о-о-олько лет мечтают все сетевики, хостеры, вебмастера и прочие, а вот всё никак.
>L3 коммутатор — это-таки коммутатор, при том что он может иметь функции третьего уровня (при этом быть дешевле маршрутизатора, в чём его плюс).
Грань между этими устройствами давно размыта. И уж говорить, что L3 свитч дешевле роутера, очень странно. L3 свитч всегда дороже программного роутера. С хардварными роутерами он вообще брат-близнец по архитектуре, различия маркетинговые. Любой нормальный роутер тоже может коммутировать.
>главное отличие коммутаторов и маршрутизаторов — свой IP и MAC для КАЖДОГО порта у L3 коммутаторов не сохраняется
Серьезно? Взять например цискины каталисты (свитчи), от какого-нибудь 3560 до 6500. При желании можно каждому физическому порту назначить свои IP и MAC. Получается, это уже роутеры? А можно на четырех портах железки включить роутинг, а остальные в один VLAN засунуть. А еще могу взять полноценный программный роутер, скажем, 2901, и настроить бриджинг с STP между его двумя портами, получу двухпортовый свитч.
>Например, многие домашние «роутеры» (у которых всего 1 WAN порт, а все остальные — LAN + Wi-Fi) — это как раз-таки не маршрутизаторы, а коммутаторы третьего уровня, именно что по маркетинговым соображениям названные маршрутизаторами.
Неверно. Домашние роутеры — это на самом деле связка из двух устройств. Представьте себе блок-схему "----(роутер)----(свитч)====(компы)". Те «роутер» и «свитч» внутри устройства физически разделены. Разве что интерфейс управления общий. С таким же успехом можно взять отдельно двухпортовый роутер и отдельно пятипортовый свитч, соединив их проводком и смотав скотчем.
>Самое главное применение MAC адресов на данный момент — поиск IP адреса: не нужно угадывать подсеть и адрес устройства, можно найти его по LLDP.
Можно развернуть мысль? LLDP — management plane. Есть костыли, запрягающие его под control plane, но это экзотика.
В целом, если вся сеть L3, потребность в ARP отпадает. Можно было бы вообще всегда слать все пакеты на ffff.ffff.ffff. Все равно устройство по ту сторону патч-корда будет маршрутизировать либо декапсулировать пакет и передавать его приложению. Это в случае ethernet.
>Об IPv6 уже сто-о-о-олько лет мечтают все сетевики, хостеры, вебмастера и прочие, а вот всё никак.
О нем мечтают по той же причине, по которой владелей погибающей кобылы мечтает о новой кобыле. Ехать-то надо. Все преимущества IPv6 за исключением адресного пространства не стоят того, чтобы идти на такой геморрой.
Грань между этими устройствами давно размыта. И уж говорить, что L3 свитч дешевле роутера, очень странно. L3 свитч всегда дороже программного роутера. С хардварными роутерами он вообще брат-близнец по архитектуре, различия маркетинговые. Любой нормальный роутер тоже может коммутировать.
>главное отличие коммутаторов и маршрутизаторов — свой IP и MAC для КАЖДОГО порта у L3 коммутаторов не сохраняется
Серьезно? Взять например цискины каталисты (свитчи), от какого-нибудь 3560 до 6500. При желании можно каждому физическому порту назначить свои IP и MAC. Получается, это уже роутеры? А можно на четырех портах железки включить роутинг, а остальные в один VLAN засунуть. А еще могу взять полноценный программный роутер, скажем, 2901, и настроить бриджинг с STP между его двумя портами, получу двухпортовый свитч.
>Например, многие домашние «роутеры» (у которых всего 1 WAN порт, а все остальные — LAN + Wi-Fi) — это как раз-таки не маршрутизаторы, а коммутаторы третьего уровня, именно что по маркетинговым соображениям названные маршрутизаторами.
Неверно. Домашние роутеры — это на самом деле связка из двух устройств. Представьте себе блок-схему "----(роутер)----(свитч)====(компы)". Те «роутер» и «свитч» внутри устройства физически разделены. Разве что интерфейс управления общий. С таким же успехом можно взять отдельно двухпортовый роутер и отдельно пятипортовый свитч, соединив их проводком и смотав скотчем.
>Самое главное применение MAC адресов на данный момент — поиск IP адреса: не нужно угадывать подсеть и адрес устройства, можно найти его по LLDP.
Можно развернуть мысль? LLDP — management plane. Есть костыли, запрягающие его под control plane, но это экзотика.
В целом, если вся сеть L3, потребность в ARP отпадает. Можно было бы вообще всегда слать все пакеты на ffff.ffff.ffff. Все равно устройство по ту сторону патч-корда будет маршрутизировать либо декапсулировать пакет и передавать его приложению. Это в случае ethernet.
>Об IPv6 уже сто-о-о-олько лет мечтают все сетевики, хостеры, вебмастера и прочие, а вот всё никак.
О нем мечтают по той же причине, по которой владелей погибающей кобылы мечтает о новой кобыле. Ехать-то надо. Все преимущества IPv6 за исключением адресного пространства не стоят того, чтобы идти на такой геморрой.
> И уж говорить, что L3 свитч дешевле роутера, очень странно. L3 свитч всегда дороже программного роутера. С хардварными роутерами он вообще брат-близнец по архитектуре, различия маркетинговые. Любой нормальный роутер тоже может коммутировать.
Роутер может коммутировать, свитч — не может маршрутизировать на всех портах и не может делать свою подсеть на каждый порт. Причём тут программные роутеры?
> Серьезно? Взять например цискины каталисты (свитчи), от какого-нибудь 3560 до 6500. При желании можно каждому физическому порту назначить свои IP и MAC.
Да? Я не силён в Cisco, прошу привести мануал. Поискал сам, нашел только IP для всего коммутатора: www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_52_se/configuration/guide/3560scg/swipaddr.html
Роутер может коммутировать, свитч — не может маршрутизировать на всех портах и не может делать свою подсеть на каждый порт. Причём тут программные роутеры?
> Серьезно? Взять например цискины каталисты (свитчи), от какого-нибудь 3560 до 6500. При желании можно каждому физическому порту назначить свои IP и MAC.
Да? Я не силён в Cisco, прошу привести мануал. Поискал сам, нашел только IP для всего коммутатора: www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_52_se/configuration/guide/3560scg/swipaddr.html
>Роутер может коммутировать, свитч — не может маршрутизировать на всех портах и не может делать свою подсеть на каждый порт.
Да? У меня множество свитчей, способных маршрутизировать на каждом порту. Своя сеть, свой мак, да. Еще ACL'ей навешать, QoSов и тому подобного.
>Я не силён в Cisco, прошу привести мануал.
Это относится не только к цискам, но и ко всем худо-бедно приличным L3 свитчам, где «L3» не просто для галочки.
Команда «no switchport» превращает порт в маршрутизируемый, ее и надо искать. Дальше, конечно, есть нюансы в зависимости от платформы. Например, на 6500 с супами 32/720 нельзя иметь суммарно более 4096 (или около того) VLANов и маршрутизируемых портов. Если у железки всего десятки VLAN'ов (а не тысячи), то все ее порты (сотни) могут роутить. Ограничение идет от того, что каждому маршрутизируемому интерфейсу (физический порт, саб, int vlan — неважно) железка втихую от администратора назначает свой внутренний номер VLAN'а, и использовать этот номер под другие задачи нельзя. У 2T с этим получше, там одно с другим не смешано, вроде 16к бридж-групп с допустимым пересечением номеров VLAN'ов.
>В смысле физически разделены? Это вполне себе одночиповые (SoC) устройства.
Свитчит на таких железках всегда ASIC. Роутингом обычно занимается general purpose CPU (в хомячковых устройствах как правило на ARM).
В том медиатеке «integrated 6-port Ethernet switch (MT7530) with five 10/100 PHYs». Ну да, получается, что тот свитч (ASIC) засунули в один корпус с ЦП, не знал, что так делают. Только это все равно физически разные устройства, хоть и размещенные под боком друг у друга. Вынесли бы из корпуса на шину PCI-E, ничего бы не изменилось кроме, может, стоимости (два чипа дороже чуть более толстого одного).
>Я не понял, что нужно разворачивать в мысли про поиск устройства протоколом поиска устройств (Link Layer Discovery Protocol).
Но это не для передачи данных. Просто для того, чтобы посмотреть, что находится за тем портом. С тем же успехом можно взять mac-arp-rdns (если надо). Причем тут поиск IP адреса не очень понял.
Или речь и идет сугубо про менеджмент? Но какой смысл делать это руками, если оно часто требуется? Скрипт, выполняющий две команды, пишется минут за 10 от силы, и готовых решений полно. Для клиентских подключений есть классная таблица dhcp snooping, в которой сразу порт, мак и IP, и они долго не експайрятся.
>И в коммутаторах, да…
Учитывая, что без поллитры не отличишь взрослый коммутатор от взрослого маршрутизатора — конечно. Ну да, есть тонкие нюансы — у роутеров обычно будет более гибкий QoS, шире выбор интерфейсов, меньше их число и т.д… Но эти отличия слишком мелочны, чтобы разделять устройства по разным классам. И внутри одного класса будет полно различий. Свитч 6500/sup2T против свитча 3750 — небо и земля по возможностям. Так что сейчас позиционирование серьезных железок скорее маркетинговое. Слабо по картинкам и списку фич определить, кто из следующих роутер, а кто — свитч? Nexus 7000, ASR 9000, Catalyst 6500, Catalyst 7600. Смотрим только крупные шасси, для (не)наглядности.
>Тут даже спорить нет смысла, т.к. всегда эта тема — сплошная спекуляция.
Те моменты, которые я затрагиваю, совершенно объективны.
Да? У меня множество свитчей, способных маршрутизировать на каждом порту. Своя сеть, свой мак, да. Еще ACL'ей навешать, QoSов и тому подобного.
>Я не силён в Cisco, прошу привести мануал.
Это относится не только к цискам, но и ко всем худо-бедно приличным L3 свитчам, где «L3» не просто для галочки.
Команда «no switchport» превращает порт в маршрутизируемый, ее и надо искать. Дальше, конечно, есть нюансы в зависимости от платформы. Например, на 6500 с супами 32/720 нельзя иметь суммарно более 4096 (или около того) VLANов и маршрутизируемых портов. Если у железки всего десятки VLAN'ов (а не тысячи), то все ее порты (сотни) могут роутить. Ограничение идет от того, что каждому маршрутизируемому интерфейсу (физический порт, саб, int vlan — неважно) железка втихую от администратора назначает свой внутренний номер VLAN'а, и использовать этот номер под другие задачи нельзя. У 2T с этим получше, там одно с другим не смешано, вроде 16к бридж-групп с допустимым пересечением номеров VLAN'ов.
>В смысле физически разделены? Это вполне себе одночиповые (SoC) устройства.
Свитчит на таких железках всегда ASIC. Роутингом обычно занимается general purpose CPU (в хомячковых устройствах как правило на ARM).
В том медиатеке «integrated 6-port Ethernet switch (MT7530) with five 10/100 PHYs». Ну да, получается, что тот свитч (ASIC) засунули в один корпус с ЦП, не знал, что так делают. Только это все равно физически разные устройства, хоть и размещенные под боком друг у друга. Вынесли бы из корпуса на шину PCI-E, ничего бы не изменилось кроме, может, стоимости (два чипа дороже чуть более толстого одного).
>Я не понял, что нужно разворачивать в мысли про поиск устройства протоколом поиска устройств (Link Layer Discovery Protocol).
Но это не для передачи данных. Просто для того, чтобы посмотреть, что находится за тем портом. С тем же успехом можно взять mac-arp-rdns (если надо). Причем тут поиск IP адреса не очень понял.
Или речь и идет сугубо про менеджмент? Но какой смысл делать это руками, если оно часто требуется? Скрипт, выполняющий две команды, пишется минут за 10 от силы, и готовых решений полно. Для клиентских подключений есть классная таблица dhcp snooping, в которой сразу порт, мак и IP, и они долго не експайрятся.
>И в коммутаторах, да…
Учитывая, что без поллитры не отличишь взрослый коммутатор от взрослого маршрутизатора — конечно. Ну да, есть тонкие нюансы — у роутеров обычно будет более гибкий QoS, шире выбор интерфейсов, меньше их число и т.д… Но эти отличия слишком мелочны, чтобы разделять устройства по разным классам. И внутри одного класса будет полно различий. Свитч 6500/sup2T против свитча 3750 — небо и земля по возможностям. Так что сейчас позиционирование серьезных железок скорее маркетинговое. Слабо по картинкам и списку фич определить, кто из следующих роутер, а кто — свитч? Nexus 7000, ASR 9000, Catalyst 6500, Catalyst 7600. Смотрим только крупные шасси, для (не)наглядности.
>Тут даже спорить нет смысла, т.к. всегда эта тема — сплошная спекуляция.
Те моменты, которые я затрагиваю, совершенно объективны.
Да, про Cisco с их изменением портов не знал, спасибо. Хоть и там, как вы и пишете, есть ограничения.
> Но это не для передачи данных. Просто для того, чтобы посмотреть, что находится за тем портом. С тем же успехом можно взять mac-arp-rdns (если надо). Причем тут поиск IP адреса не очень понял.
Или речь и идет сугубо про менеджмент? Но какой смысл делать это руками, если оно часто требуется? Скрипт, выполняющий две команды, пишется минут за 10 от силы, и готовых решений полно. Для клиентских подключений есть классная таблица dhcp snooping, в которой сразу порт, мак и IP, и они долго не експайрятся.
Я про то, что если у нас есть устройство. Любое, об IP которого мы ничего не знаем и у которого нет консольного порта, а нам очень хочется к нему подключиться. И DHCP у него выключен. Куда тут без LLDP?
> Ну да, есть тонкие нюансы — у роутеров обычно будет более гибкий QoS, шире выбор интерфейсов, меньше их число и т.д… Но эти отличия слишком мелочны, чтобы разделять устройства по разным классам. И внутри одного класса будет полно различий. Свитч 6500/sup2T против свитча 3750 — небо и земля по возможностям.
Я понял в чём дело. Вы говорите языком ISP, с Cisco-размерами и прочими вещами, я же — нет. В таких игрушках, конечно, границы уже стираются. В не-ISP мире они ещё живы, тем не менее.
> Но это не для передачи данных. Просто для того, чтобы посмотреть, что находится за тем портом. С тем же успехом можно взять mac-arp-rdns (если надо). Причем тут поиск IP адреса не очень понял.
Или речь и идет сугубо про менеджмент? Но какой смысл делать это руками, если оно часто требуется? Скрипт, выполняющий две команды, пишется минут за 10 от силы, и готовых решений полно. Для клиентских подключений есть классная таблица dhcp snooping, в которой сразу порт, мак и IP, и они долго не експайрятся.
Я про то, что если у нас есть устройство. Любое, об IP которого мы ничего не знаем и у которого нет консольного порта, а нам очень хочется к нему подключиться. И DHCP у него выключен. Куда тут без LLDP?
> Ну да, есть тонкие нюансы — у роутеров обычно будет более гибкий QoS, шире выбор интерфейсов, меньше их число и т.д… Но эти отличия слишком мелочны, чтобы разделять устройства по разным классам. И внутри одного класса будет полно различий. Свитч 6500/sup2T против свитча 3750 — небо и земля по возможностям.
Я понял в чём дело. Вы говорите языком ISP, с Cisco-размерами и прочими вещами, я же — нет. В таких игрушках, конечно, границы уже стираются. В не-ISP мире они ещё живы, тем не менее.
>Да, про Cisco с их изменением портов не знал
Причем тут Cisco? Это просто близкий мне пример. Любое оборудование худо-бедно приличных вендоров может так же, со своими нюансами.
>Хоть и там, как вы и пишете, есть ограничения.
У серьезных хардварных роутеров ограничений тоже мама не горюй, если сравнивать с программными. В самых неожиданных местах.
>Я про то, что если у нас есть устройство. Любое, об IP которого мы ничего не знаем и у которого нет консольного порта, а нам очень хочется к нему подключиться. И DHCP у него выключен. Куда тут без LLDP?
Известно только что оно подключено к такому-то порту, что у него включен LLDP и что оно своё (на него можно зайти)? Религия запрещает посмотреть по порту мак, из arp таблицы вытащить IP адрес и собственно зайти на него? Либо, что более правильно, просто заглянуть в документацию или дескрипшн порта и узнать, что там? LLDP лишь немного экономит время, никакого «куда тут без» нет.
>Вы говорите языком ISP
Я не имею никакого отношения к ISP. Причем тут провайдеры?
>В не-ISP мире они ещё живы, тем не менее.
Конечно. И — о ужас — там иногда тоже используют нормальное оборудование. Смысл зацикливаться на SOHO решениях?
Причем тут Cisco? Это просто близкий мне пример. Любое оборудование худо-бедно приличных вендоров может так же, со своими нюансами.
>Хоть и там, как вы и пишете, есть ограничения.
У серьезных хардварных роутеров ограничений тоже мама не горюй, если сравнивать с программными. В самых неожиданных местах.
>Я про то, что если у нас есть устройство. Любое, об IP которого мы ничего не знаем и у которого нет консольного порта, а нам очень хочется к нему подключиться. И DHCP у него выключен. Куда тут без LLDP?
Известно только что оно подключено к такому-то порту, что у него включен LLDP и что оно своё (на него можно зайти)? Религия запрещает посмотреть по порту мак, из arp таблицы вытащить IP адрес и собственно зайти на него? Либо, что более правильно, просто заглянуть в документацию или дескрипшн порта и узнать, что там? LLDP лишь немного экономит время, никакого «куда тут без» нет.
>Вы говорите языком ISP
Я не имею никакого отношения к ISP. Причем тут провайдеры?
>В не-ISP мире они ещё живы, тем не менее.
Конечно. И — о ужас — там иногда тоже используют нормальное оборудование. Смысл зацикливаться на SOHO решениях?
Случайно нажал Написать у предыдущего комментария.
> Неверно. Домашние роутеры — это на самом деле связка из двух устройств. Представьте себе блок-схему "----(роутер)----(свитч)====(компы)". Те «роутер» и «свитч» внутри устройства физически разделены. Разве что интерфейс управления общий. С таким же успехом можно взять отдельно двухпортовый роутер и отдельно пятипортовый свитч, соединив их проводком и смотав скотчем.
В смысле физически разделены? Это вполне себе одночиповые (SoC) устройства. Ну вот возьмём MediaTek с их чипами: wikidevi.com/wiki/MediaTek_MT7620 Это тоже два устройства?
> Можно развернуть мысль? LLDP — management plane. Есть костыли, запрягающие его под control plane, но это экзотика.
Какой ещё management и control? Управлять через протокол поиска? Я не понял, что нужно разворачивать в мысли про поиск устройства протоколом поиска устройств (Link Layer Discovery Protocol).
> В целом, если вся сеть L3, потребность в ARP отпадает.
И в коммутаторах, да…
> Все преимущества IPv6 за исключением адресного пространства не стоят того, чтобы идти на такой геморрой.
Тут даже спорить нет смысла, т.к. всегда эта тема — сплошная спекуляция.
> Неверно. Домашние роутеры — это на самом деле связка из двух устройств. Представьте себе блок-схему "----(роутер)----(свитч)====(компы)". Те «роутер» и «свитч» внутри устройства физически разделены. Разве что интерфейс управления общий. С таким же успехом можно взять отдельно двухпортовый роутер и отдельно пятипортовый свитч, соединив их проводком и смотав скотчем.
В смысле физически разделены? Это вполне себе одночиповые (SoC) устройства. Ну вот возьмём MediaTek с их чипами: wikidevi.com/wiki/MediaTek_MT7620 Это тоже два устройства?
> Можно развернуть мысль? LLDP — management plane. Есть костыли, запрягающие его под control plane, но это экзотика.
Какой ещё management и control? Управлять через протокол поиска? Я не понял, что нужно разворачивать в мысли про поиск устройства протоколом поиска устройств (Link Layer Discovery Protocol).
> В целом, если вся сеть L3, потребность в ARP отпадает.
И в коммутаторах, да…
> Все преимущества IPv6 за исключением адресного пространства не стоят того, чтобы идти на такой геморрой.
Тут даже спорить нет смысла, т.к. всегда эта тема — сплошная спекуляция.
> Один из самых популярных стэков протоколов (Ethernet/IP/TCP/HTTP) разве не укладывается в модели OSI?
Совокупность протоколов — это «семейство» (suite). Стеком обычно именуют реализацию. Все укладывания TCP/IP в модель OSI — это просто идеи создания универсального сетевого стека (API) внутри ОС.
Модель OSI разрабатывалась, когда TCP/IP уже существовала. Во-первых, они пытались устранить «фундаментальный недостаток», т.е. реализовать несколько иные принципы. Во-вторых, чисто «политически» как бы это выглядело: описали существующее, добавили несколько фич и назвали своим стандартом?
Совокупность протоколов — это «семейство» (suite). Стеком обычно именуют реализацию. Все укладывания TCP/IP в модель OSI — это просто идеи создания универсального сетевого стека (API) внутри ОС.
Модель OSI разрабатывалась, когда TCP/IP уже существовала. Во-первых, они пытались устранить «фундаментальный недостаток», т.е. реализовать несколько иные принципы. Во-вторых, чисто «политически» как бы это выглядело: описали существующее, добавили несколько фич и назвали своим стандартом?
НЛО прилетело и опубликовало эту надпись здесь
Когда вы аутентифицировались на geektimes, было кратковременно задействовано «L6» шифрование. HTTPS.
IPSec — на самом деле адское нагромождение костылей, плохо дружащее с другими костылями (NAT, любой stateful анализ) и требующее для этого отдельных костылей. Если есть просто два устройства, которые вдруг захотели зашифровать трафик между собой — наиболее логично шифровать именно на «L6», поблизости от приложения. Если какое-то промежуточное устройство начинает шифровать транзитный трафик (создает туннель) — да, тут надо надо бы пониже.
IPSec — на самом деле адское нагромождение костылей, плохо дружащее с другими костылями (NAT, любой stateful анализ) и требующее для этого отдельных костылей. Если есть просто два устройства, которые вдруг захотели зашифровать трафик между собой — наиболее логично шифровать именно на «L6», поблизости от приложения. Если какое-то промежуточное устройство начинает шифровать транзитный трафик (создает туннель) — да, тут надо надо бы пониже.
В Windows NT 4.0 (?) еще была реализация протокола OSI TP4, потом ее выпилили. Если кому хочется - можно поиграться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OSI: Интернет, которого не было