Здравствуйте, ononim, Вы писали:
O>Набор кастомных драйверов сетевых адаптеров со своими либами, заточенные под конкретное железо, начатая по инициативе интеля vs наколенная реализация транспортного протокола поверх UDP методом "а давайте запилим, и пофиг че получится по бенчмаркам, у нас бабок много"? O>Очень популистское сравнение. Но на стадных девелоперов подействует.
Знаю одну контору, запилили на коленке кастомные дрова с прямым доступом к буферам сетевухи (чтоб без копирования памяти туда-сюда) — получился неплохой пулемёт для тестирования стрессоустойчивости сети и инфраструктуры. К сожалению, не под Windows (и не под Linux, гы). Если кто-то из мажорных игроков, типа Intel, сможет протащить нечто подобное в стандартизированную форму безотносительно ОС (и при этом без дырок в безопасности, как было в raw sockets) — это будет очень интересно.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Cyberax, Вы писали:
C>>OSI сдохла уже давно. MD>Хммм… А мужики-то не знают! Как же она сдохла, неужели фейсбуки с контактами прямо в Ethernet-кадры данные оборачивают?
Нет. Но работа протокола IP зависит от протокола ICMP, который работает поверх IP. Нужно объяснять, что это прямое нарушение модели?
MD>P.S. Тот факт что 99% девелоперов разрабатывают application-level протоколы, вовсе не значит, что остальных 6 уровней уже более нет в природе.
В природе? Нету. OSI существует только в учебниках.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: S>Нет. Но работа протокола IP зависит от протокола ICMP
Пардон, WAT? Работа протокола IP не зависит от ICMP. ICMP — не более чем диагностика, её наличие или отсутствие никак не влияет на работоспособность узлов. Более того, многие публичные сервисы дропают ICMP, чтобы не платить за этот трафик (если на отправителя нет пирингового соглашения) и не забивать своё оборудование лишней нагрузкой (гуглим "ICMP атака").
S>В природе? Нету. OSI существует только в учебниках.
Значит, самое время их почитать
Здравствуйте, Sinclair, Вы писали:
C>>>OSI сдохла уже давно. MD>>Хммм… А мужики-то не знают! Как же она сдохла, неужели фейсбуки с контактами прямо в Ethernet-кадры данные оборачивают? S>Нет. Но работа протокола IP зависит от протокола ICMP, который работает поверх IP. Нужно объяснять, что это прямое нарушение модели?
Он и от BGP зависит. И от DHCP, который поверх UDP. И от ещё массы вещей.
Это не нарушает главного — что уровневый принцип, близкий к тому, что описан в OSI модели и ISO стеке, актуален и его упоминание и обучение необходимо для того, чтобы понимать структуру сети.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Sinclair, Вы писали: S>>Нет. Но работа протокола IP зависит от протокола ICMP MD>Пардон, WAT? Работа протокола IP не зависит от ICMP. ICMP — не более чем диагностика, её наличие или отсутствие никак не влияет на работоспособность узлов. Более того, многие публичные сервисы дропают ICMP, чтобы не платить за этот трафик (если на отправителя нет пирингового соглашения) и не забивать своё оборудование лишней нагрузкой (гуглим "ICMP атака").
Мы сейчас о хитрожопых реализациях или о стандарте?
ICMP, uses the basic support of IP as if it were a higher level protocol, however, ICMP is actually an integral part of IP, and must be implemented by every IP module.
MD>Значит, самое время их почитать
Лучше всего про модель OSI читать в учебниках по менеджменту — в разделе "отрицательные примеры влияния комитетного подхода к решению инженерных задач".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, netch80, Вы писали:
N>Он и от BGP зависит. И от DHCP, который поверх UDP. И от ещё массы вещей.
Нет, не зависит. Роутить IP можно безо всякого DHCP, и без всякого BGP. То, что на практике DHCP часто используется для авто-конфигурации IP — это просто особенность нынешнего интернета. Как и использование BGP.
На всякий случай напомню, что технически ничто не мешает нам реализовать IP поверх голубиной почты. N>Это не нарушает главного — что уровневый принцип, близкий к тому, что описан в OSI модели и ISO стеке, актуален и его упоминание и обучение необходимо для того, чтобы понимать структуру сети.
Согласен. В качестве красивой картинки этот принцип стоит изучать, отдав ему 5-10 минут на лекции. А затем переходить к тому, как дизайнятся реальные протоколы, решающие реальные задачи (а не задачу "оправдать работу семи подкомитетов комитета по разработке стандарта").
Точно так же, как мы говорим о желательности отсутствия кольцевых зависимостей в модулях программы, а затем сразу переходим к тому, как скомпилировать DLL которые необходимым образом зависят друг от друга.
Потому что класс String невозможно описать, не используя класс Type (ведь как и у всех, у него есть метод GetType()), а класс Type невозможно описать, не используя класс String (ведь у него есть String Name).
И прагматичные цели часто заставят нас складывать эти типы в разные DLL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
нет, -17 не будет финализироваться, много багрепортов выползло. До июля тестируем интероп, в июле смотрим. Плюс у меня есть планы всерьёз набросить на вентилятор, так что, если получится, то и в июле не будет финала. Но шансы 50/50.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Sinclair, Вы писали: S>>Нет. Но работа протокола IP зависит от протокола ICMP MD>Пардон, WAT? Работа протокола IP не зависит от ICMP.
Для IPv6 строго зависит, так как фрагментации на уровне IP больше нет и ICMP Packet Too Big становится критически важным.
Здравствуйте, Mr.Delphist, Вы писали:
C>>OSI сдохла уже давно. MD>Хммм… А мужики-то не знают!
Да знают уже давно. Потому и пилят всякие DoH.
MD>Как же она сдохла, неужели фейсбуки с контактами прямо в Ethernet-кадры данные оборачивают?
Они нынче делают эмуляцию TCP/IP поверх HTTPS.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, ononim, Вы писали:
O>>Набор кастомных драйверов сетевых адаптеров со своими либами, заточенные под конкретное железо, начатая по инициативе интеля vs наколенная реализация транспортного протокола поверх UDP методом "а давайте запилим, и пофиг че получится по бенчмаркам, у нас бабок много"? O>>Очень популистское сравнение. Но на стадных девелоперов подействует.
MD>Знаю одну контору, запилили на коленке кастомные дрова с прямым доступом к буферам сетевухи (чтоб без копирования памяти туда-сюда) — получился неплохой пулемёт для тестирования стрессоустойчивости сети и инфраструктуры. К сожалению, не под Windows (и не под Linux, гы). Если кто-то из мажорных игроков, типа Intel, сможет протащить нечто подобное в стандартизированную форму безотносительно ОС (и при этом без дырок в безопасности, как было в raw sockets) — это будет очень интересно.
Эка невидаль. Я 10 лет назад такое писал используя драйвер winpcap. Пакетики строились по RFC. Положить сеть можно было за пару минут.
Здравствуйте, Sinclair, Вы писали:
N>>Он и от BGP зависит. И от DHCP, который поверх UDP. И от ещё массы вещей. S>Нет, не зависит. Роутить IP можно безо всякого DHCP, и без всякого BGP. То, что на практике DHCP часто используется для авто-конфигурации IP — это просто особенность нынешнего интернета. Как и использование BGP.
Всё-таки ты не о том.
В модели OSI есть 4 принципиально разных аспекта:
1. Количество и состав уровней. Этот аспект на сейчас сохраняется с несущественными изменениями (в основном в районе L2: что происходит на стыке с L1, деление LLC/MAC, и так далее).
2. Строгая направленность иерархии уровней. Убита туннелированием и криптографией, но так, что исключение подтверждает существование и смысл правила — все инверсии делаются так, что не нарушают предыдущую логику.
3. Привязка формального управления уровнем к тому же уровню. Вот тут больше всего взъедаются на OSI, но мне этот момент как раз кажется маловажным: скорее всего, тут произошла накладка в виде административного влияния каких-то старцев-маразматиков или их бюрократических эквивалентов, потому что любому нормальному человеку очевидно, что если у нас есть управляющие команды и ответы, то у нас есть полные аналоги L4...L7, и не называть их так не имеет смысла.
4. Конкретная реализация уровней (типа, G.703, FrameRelay, X.25 и так далее). Вот тут потеряно практически всё. Но и в случае IP оно теряется (кто помнит, как выглядели IPv2, IPv3, безальтернативная классовая адресация и т.п.? а ведь нам постепенно настаёт полный и окончательный v6), а навстречу идёт понимание того, в чём ISO народ был прав (и выливается в штуки типа SCTP).
И именно противоречие в том, что для первичного введения в учебнике нужен {1}, а для нормального понимания {neg(3)}, и приводит к тому, что за OSI ломаются копья.
Я по этой причине всегда говорю о "народной" или "современной" реализации модели OSI, со всеми необходимыми поправками согласно пп.1-4, с отличением от "строгой", которая была привязана к конкретному вымершему стеку.
S>На всякий случай напомню, что технически ничто не мешает нам реализовать IP поверх голубиной почты.
Не мешает. И даже с QoS, как известно. Но к общему вопросу это не имеет отношения: это просто ещё один вид транспорта ниже сетевого уровня.
Тем более что, если практически его реализовывать, очень быстро появятся L2 domains в пределах типичного расстояния полёта голубя и маршрутизаторы между ними
N>>Это не нарушает главного — что уровневый принцип, близкий к тому, что описан в OSI модели и ISO стеке, актуален и его упоминание и обучение необходимо для того, чтобы понимать структуру сети. S>Согласен. В качестве красивой картинки этот принцип стоит изучать, отдав ему 5-10 минут на лекции. А затем переходить к тому, как дизайнятся реальные протоколы, решающие реальные задачи (а не задачу "оправдать работу семи подкомитетов комитета по разработке стандарта").
Так второго сейчас и не делают. Ты воюешь с ветряными мельницами.
Обычно, стандартная семиуровневая картинка тут же проецируется на реальность, и показывается уже на примере IP.
S>Точно так же, как мы говорим о желательности отсутствия кольцевых зависимостей в модулях программы, а затем сразу переходим к тому, как скомпилировать DLL которые необходимым образом зависят друг от друга. S>Потому что класс String невозможно описать, не используя класс Type (ведь как и у всех, у него есть метод GetType()), а класс Type невозможно описать, не используя класс String (ведь у него есть String Name). S>И прагматичные цели часто заставят нас складывать эти типы в разные DLL.
Аналогия понятна, но не вижу её связи с предыдущим вопросом.
Здравствуйте, Sharov, Вы писали:
C>>Они нынче делают эмуляцию TCP/IP поверх HTTPS. S>Зачем?
Потому, что через нынешний Интернет ничего другое не пролазит.
Здравствуйте, netch80, Вы писали:
N>2. Строгая направленность иерархии уровней. Убита туннелированием и криптографией, но так, что исключение подтверждает существование и смысл правила — все инверсии делаются так, что не нарушают предыдущую логику.
Уже не так. Тот же NAT ломает изоляцию между сетевым слоем и транспортным/сессионным. Причём ломает вдребезги — теряется возможность двунаправленной коммуникации, и маршрутизаторы сетевого слоя обязаны знать детали транспортного слоя. Мелочи типа DoH — уже вишенка на торте.
Современный Интернет, в итоге, выглядит совершенно отлично от идеализированного OSI. В частности, критично важные части в OSI не затронуты:
1) Механизм разрешение имён.
2) Асимметричность доступа к ресурсам.
3) Непрозрачность сетевых устройств.
4) Шифрование и инфраструктура для него.
N>4. Конкретная реализация уровней (типа, G.703, FrameRelay, X.25 и так далее). Вот тут потеряно практически всё. Но и в случае IP оно теряется (кто помнит, как выглядели IPv2, IPv3, безальтернативная классовая адресация и т.п.? а ведь нам постепенно настаёт полный и окончательный v6), а навстречу идёт понимание того, в чём ISO народ был прав (и выливается в штуки типа SCTP).
SCTP, по сути, сдох так и не родившись. Там сейчас нет ничего существенно интересного, кроме сегментации пакетов на уровне протокола и multihoming (который и для TCP тоже есть). При этом реальные железные штуки типа синхронных колец с реальным выделением гарантированной полосы для абонентов вообще не получили какого-либо успеха.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
C>>>Они нынче делают эмуляцию TCP/IP поверх HTTPS. S>>Зачем? C>Потому, что через нынешний Интернет ничего другое не пролазит.
Здравствуйте, Mr.Delphist, Вы писали:
C>>OSI сдохла уже давно. MD>Хммм… А мужики-то не знают! Как же она сдохла, неужели фейсбуки с контактами прямо в Ethernet-кадры данные оборачивают?
MD>P.S. Тот факт что 99% девелоперов разрабатывают application-level протоколы, вовсе не значит, что остальных 6 уровней уже более нет в природе.
Распишешь эти 7 уровней? Вот у меня компьютер к роутеру подключен Ethernet-проводком. Отправляю я это сообщение POST-запросом на https://rsdn.org/. Давай по уровням выписывай 7 задействованных протоколов.
Здравствуйте, Sharov, Вы писали:
C>>Потому, что через нынешний Интернет ничего другое не пролазит. S>А зачем фб что-то другое кроме http(s)?
Например, для голосового и видеочата. Или для игр.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
C>>>Потому, что через нынешний Интернет ничего другое не пролазит. S>>А зачем фб что-то другое кроме http(s)? C>Например, для голосового и видеочата. Или для игр.
А на фига, т.е. у нас дважды кадр ip\tcp — сначала для http пакета, затем для его содрежимого. Так?
Здравствуйте, Sharov, Вы писали:
C>>>>Потому, что через нынешний Интернет ничего другое не пролазит. S>>>А зачем фб что-то другое кроме http(s)? C>>Например, для голосового и видеочата. Или для игр.
S>А на фига, т.е. у нас дважды кадр ip\tcp — сначала для http пакета, затем для его содрежимого. Так?
Голос и видео в реальном виде требуют синхронный тип трафика, при котором транспортные проблемы скорее приводят к потерям пакетов, чем к их задержкам. Провалы звука и изображения (в разумных пределах) восстанавливаются и легче воспринимаются, чем "плавающий" звук.
Аналогичные проблемы характерны для многих других видов взаимодействия, включая игры — если на тебя едет танк, лучше, если он "прыгнет", но вовремя (такой же эффект, как если ты сам отвернулся на пару секунд), чем если ты через полминуты получишь подробную последовательность его шагов, когда он тебя уже расстрелял.
TCP, как и всё, что бегает поверх него, обеспечивает только наливной (bulk) трафик, с защитой от потерь, но ценой задержек и переповторов. Условная гарантия доставки обеспечивается отсутствием гарантии реалтаймовости. Пропустить переповтор устаревших данных невозможно, протокол на это не рассчитан принципиально.
Таким образом, TCP и всё, что поверх него (HTTP, HTTPS) тупо непригоден для реализации синхронных взаимодействий. Для них обычно используются свои протоколы поверх UDP, и не дай бог какой-то дурак затуннелирует это поверх TCP (к сожалению, всякие openvpn такое умеют, и есть имбецильные любители настраивать такое).
С SCTP с этим лучше — у него есть возможность задавать для каждой датаграммы ограничение доставки по времени или по количеству переповторов, не подтвердили получение — фиг с ним. Но сам SCTP подозрительно мало используется.
Здравствуйте, netch80, Вы писали:
N>Голос и видео в реальном виде требуют синхронный тип трафика, при котором транспортные проблемы скорее приводят к потерям пакетов, чем к их задержкам. Провалы звука и изображения (в разумных пределах) восстанавливаются и легче воспринимаются, чем "плавающий" звук. N>Аналогичные проблемы характерны для многих других видов взаимодействия, включая игры — если на тебя едет танк, лучше, если он "прыгнет", но вовремя (такой же эффект, как если ты сам отвернулся на пару секунд), чем если ты через полминуты получишь подробную последовательность его шагов, когда он тебя уже расстрелял.
N>TCP, как и всё, что бегает поверх него, обеспечивает только наливной (bulk) трафик, с защитой от потерь, но ценой задержек и переповторов. Условная гарантия доставки обеспечивается отсутствием гарантии реалтаймовости. Пропустить переповтор устаревших данных невозможно, протокол на это не рассчитан принципиально.
N>Таким образом, TCP и всё, что поверх него (HTTP, HTTPS) тупо непригоден для реализации синхронных взаимодействий. Для них обычно используются свои протоколы поверх UDP, и не дай бог какой-то дурак затуннелирует это поверх TCP (к сожалению, всякие openvpn такое умеют, и есть имбецильные любители настраивать такое).
Так выше было написано, что фб для игр и звука гоняте все поверх http, который поверх tcp\ip. И в чем тогда смысл, эмуляция реалтаймовости?
