Хочу ARM-плату с парой eth интерфейсов 100-1000 мегабит, которая вычислительно будет способна эти 100 мегабит пороутить или зашифровать.

L5 - L7 можешь на помойку отнести, это всё один уровень.

L4 тоже такое себе.

L5 - L7 можешь на помойку отнести, это всё один уровень.

Вы «Америку не открыли», модель OSI не совпадает с стеком TCP/IP побуквенно.

L4 - это отдельный уровень TCP и UDP имеют адрес приложения (порт) и работают на базе IP пакета - который имеет адрес сетевого интерфейса. Важно: TCP/UPD имеют отдельную адресацию портов не зависимую друг от друга, TCP:80 и UDP:80 не мешают друг другу, они в разных адресных пространствах.

L5 - тоже строго изолированный уровень TLS.

L6 - не зависит от уровня L5, так как писать CRUD приложение без разницы пишется оно под HTTP или HTTPs. На уровне HTTP Фреймворка прослойка TLS прозрачна и отрабатывает внутри HTTP сервера не меняя инерфейса.

L5 - тоже строго изолированный уровень TLS.

Это бред.

Это бред.

То что TLS работает на L5 уровне OSI - это не бред, это факт.

• https://hpbn.co/transport-layer-security-tls
• Изображение: TLS в TCP/IP - OSI стеке на уровне L5.

Почему TLS на уровне L5? Потому, что одна из задач TLS это Authentication - т.е. установление доверительного соединения, а также Integrity - проверка целостности. Прямая задача «сессии». Только Encryption - кодирование относится к следующему уровню Representation. 2 из 3х - Session Level L5.

А вы наверное тролль, раз отрицаете базовые определения и как водится занимаетесь провокационным буквоедством. Хотя польза от вас есть в: OSI - 7 уровней, а не 6 как я запомнил. По мимо Application Level есть Data Representation Level. В общем, не суть, базовой картины не меняет: TLS отделен от HTTP.

Это бред, тут нет другого слоя. Это точно такой же recv как и обычный plain протокол.

А ещё он какие-то там сюстем дезигн проводит, бугага.

Это бред, тут нет другого слоя. Это точно такой же recv как и обычный plain протокол.

Изображение протоколы и интерфейсы.

Вы правы уровни L5, L6, L7 реализованы в Userspase через системный вызов recv. recv - это интерфейс между L4 и L5, реализованный как системный вызов находящийся на границе взаимодействия Kernel и Userspace.

recv - системный вызов который экспортирует из Kernel результаты работы L4, конкретно протоколов TCP/UPD. На базе этого вызова описываются вышестоящие уровни - L5, L6, L7. В этом есть архитектура, нижней слой реализует верхний слой, а взаимодействие происходит через неизменные интерфейсы. recv - это интерфейс предоставляющий услуги уровня L4.

Вывод: Вы не понимаете что такое интерфейс и протокол. Но продолжаете спорить.

Это бред, тут нет другого слоя. Это точно такой же recv как и обычный plain протокол.

То ли вы меня троллите, то ли у вас какие-то проблемы. Вам предоставили ссылки на работу всемирно известного специалиста Ильи Григорика который занимается оптимизацией быстродействия соединений. Более того дали перевод основных тезисов. Вы это просто проигнорировали.

Какой вам смысл выставлять себя идиотом? Со свой стороны я воспринимаю вас как Wing Chun Dummy, отрабатывая базовую технику объяснений.

P.S. Даже дело как бы не лично в вас - анониме с блюющим единорогом на аватарке, пишу я для сообщества. Учился в сообществе, возвращаю сообществу. Мне просто не ясно зачем выставлять себя полудурком при людно, и оспаривать базовые определения.

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

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

Чувак, ты не понимаешь азов. Тебе дали два учебника High Performance Browser Networking от Ильи Григорика, и базовый учебник технарей и вузов «Компьютерные Сети» от Олиферов. Специально главы выбрали. Перед этим я тебе подробно бъяснил механизм функционирования СRUD фреймворка через HTTP/HTTPs сервер.

Иди успокойся, умойся и выучи определения. Перестань публично позориться.

🐓🐓🐓🐓

Какого хера тут ШГ?

Неа, реально, кого у меня тут курицы вместо петухов.

Всё ещё веселее.

Практически, ты не можешь гонять произвольные битики по L2 как тебе заблагорассудится, из-за того, что L2 тоже в железе.

Т.е. на самом деле в том же ethernet есть физический L1 - провода/опта + форма сигнала, как конкретно там единички и нолики кодируются, далее идёт L2 - формат пакета c данными - преамбула, SFD, Данные, FCS, TD_IDL и всё такое. В современных компах нет возможности передавать произвольные нолики-единички по L1, хотя однокристалочками всё-же можно этого добится, вот только ни через один свитч оно не пролезет потому что оно в железе. И только потом идёт L3, со всякими ethernet header, MAC и пр. который тоже в железе, но уже более высокоуровневом. Т.е. в «официальной» OSI пропущен целый большой кусок абстракции (L2), типа потому что оно в железе, но есть следующий кусок абстракции (L3), который тоже в железе. И только потом уже идёт L4 в виде IP и т.п. При этом Applications имеют доступ ко всем уровням начиная с L3. Для Application нет проблем обмениваться данными используя только L3 без всяких там IP, TCP и пр. При помощи тех же самых recv/send

Так что всё это теоретизирование вокруг OSI - сферическая сова в вакууме натянутая на сферического коня.

По-уму, либо должно быть L1 - физика, т.е. всё вплоть до и включая ethernet, L2 - Application. Либо - L1 - физика, L2 - пакет, L3 - ethernet, L4 - Application.

Делать из TCP/IP какие-то отдельные фундаментальные сущности, отличные от Application - такое себе. И если делаешь - не лезь в железо., строй свое OSI внутри Application как хочешь. L1 - IP, L2 - TCP, L3 - TLS и т.д.

Дружище, ты зарегистрирован на LOR - 13 лет назад. За это время можно закончить техникум, вуз и еще защитить кандидатскую. И до сей поры ты не знаешь азов: разделение между интерефейсами и протоклами и реализацию этого разделения в UNIX. В Unix до 4 уровня включительно реалзиуется в Kernel, от 5 утровя и выше пишется в Userspace.

• вот схема L1-L4 OSI в Kernel, выше L5-L7 Userspase.
• вот еще схема то же самое в Windows, общий концепт Сокетов.

Учиться надо. Не то, что бы я на тебя обижался, но ты давай, это подтягивайся хотя бы до среднего уровня.

Делать из TCP/IP какие-то отдельные фундаментальные сущности, отличные от Application - такое себе. И если делаешь - не лезь в железо., строй свое OSI внутри Application как хочешь. L1 - IP, L2 - TCP, L3 - TLS и т.д.

#{удаленные эмоциональные высказывания}

Зачем переименовать уже сложившиеся термины?

L1-L7 это всемирно известные термины и они совпадают с уровнями OSI и отображаются в стек TCP/IP.

А вот тут важные ссылки по архитектуре Сетевых взаимодействий и ОС, добрым людям на будущее.

• Уровни OSI в UNIX Kernel
• ВАЖНО: протоколы и интерфейсы
• Протокол TLS как независимый L5
• Яркая статья про OSI <=> TCP/IP

#{удалено самоцензурой}

Зачем переименовать уже сложившиеся термины?

Затем что смысла в терминах которые не отражают реальность нет. Как и в модели которая реальность не отражает.

То, что они «всемирно известные» делает ситуацию только хуже и никак не помогает понимать как всё на самом деле устроено.

Если L1 - медиа и модуляция, а L2 - уже ethernet-пакет сразу с заголовком и пр., то потерян целый уровень относящийся к устройству пакета информации передаваемого по L1. Да и модуляцию я бы тоже выделил в отдельный уровень, ибо, например, медиа в 10BaseT и 100BaseT идентична, а вот модуляция разная. Если L7 это Application, то Application работающее напрямую с ethernet-пакетами (L2) вызывает взрыв мозга у секты свидетелей OSI.

В итоге, OSI ни железяникам не помогает, ни программистам. И там и там - недоделанная абстракция, очень условно описывающая объект с которым приходится работать.

Application нет проблем обмениваться данными используя только L3 без всяких там IP, TCP и пр. При помощи тех же самых recv/send

У Application есть проблема обмениваться данными при помощи recv/send так как требуется реализовывать: целостность данных и однозначно идентифицировать отправителя и получателя. Вы можете клеить собственные велосипеды или не выходить из собственной лаборатории.

Но в реальном мире эти задачи делегируются протоколу TLS, по этому существует разделение на уровни OSI. Также появляются новые протоколы QUIC/HTTP2/HTTP3 - и чтоб не переписывать в Userspace приложение полностью - его пишут согласно разделения уровней OSI. Часть функционала отдавая библиотекам и общаясь через НЕИЗМЕННЫЕ ВО ВРЕМЕНИ ИНТЕРФЕЙСЫ, а не самопальные «велосипеды» которые вынудят переписывать приложение полностью. Это еще называется контракты, и за данный вопрос отвечает дизайн приложения (вот лекция).

Таких проблем нет только у электронщиков работающих замкнуто в рамках своей лаборатории в которую никто, никогда без пропуска не зайдет. В реальном мире банковских расчетов, оптимизации скорости подключений - эти проблемы стоят в полный рост.

В итоге, OSI ни железяникам не помогает, ни программистам.

Этот тезис я детально разобрал в предыдущем комментарии. OSI - помогает во всю, чтоб не переписывать приложения под новые протоколы. SSL поменяли на TLS (1999, 2006, 2008 годы), TCP на QUIC - а приложение продолжает работать без необходимости внесения изменений.

Юзерспейс приложение, которое тупо обменивается данными с удалённым девайсом на уровне L2 - чисто по MAC адресу через НЕИЗМЕННЫЕ ВО ВРЕМЕНИ ИНТЕРФЕЙСЫ - где его место в твоей чудесной модели? Никаких TLS, TCP и даже IP вообще не используется.

В реальном мире банковских расчетов

Поржал. :) Даже если сесть и подумать, сложно выдумать что-то менее реальное, чем «банковские расчёты». :) Ты ещё расскажи сказку про самоценность фиатных валют. :)

Поржал. :) Даже если сесть и подумать, сложно выдумать что-то менее реальное, чем «банковские расчёты». :) Ты ещё расскажи сказку про самоценность фиатных валют. :)

Ну иди дядя посмейся, посмейся. «Смех без причины признак дурачины» - русская поговорка.

OSI - помогает во всю, чтоб не переписывать приложения под новые протоколы.

Да-да, приложение может либо через RS485, либо CAN, либо Ethernet работать с промышленным оборудованием. Ничего переписывать не требуется. При этом «модель OSI» в этом случае вообще ничем не помогает и даже вредна.

Юзерспейс приложение, которое тупо обменивается данными с удалённым девайсом на уровне L2 - чисто по MAC адресу через НЕИЗМЕННЫЕ ВО ВРЕМЕНИ ИНТЕРФЕЙСЫ - где его место в твоей чудесной модели? Никаких TLS, TCP и даже IP вообще не используется.

Дядя, Userspace работает через систему Сокетов, сокеты реализованы над протоколами TCP/UDP, т.е. до L4 включительно работает Kernel. Ты ничего не знаешь, но ты вылез спорить. Есть возможно просмартивать данные IP пакетов чрез raw_socket, но это не глубже L3 и то часто пакет клонируется.

Специально для работы на L3 в Kernel в Linux добавили eBPF.

Ты, дядя, сидишь и несешь чепуху. И тебе не стыдно.

Да-да, приложение может либо через RS485, либо CAN, либо Ethernet работать с промышленным оборудованием. Ничего переписывать не требуется. При этом «модель OSI» в этом случае вообще ничем не помогает и даже вредна.

На дворе кол, на колу мочало, наша песня хороша начинай сначала.

Картина Билибина

Дядя, Userspace работает через систему Сокетов, сокеты реализованы над протоколами TCP/UDP

Смешно, да. :)

sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW);

Там даже IP не пахнет, не то что TCP/UDP. :)

sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW);

Спасибо за уточнение. Но это исполнение требует root прав, и это как-бы не совсем Userspace, тут ломается вся концепция безопасной многопользовательской системы UNIX.

Процесс с правами обычного пользователя не имеет полномочий работать ниже L4. Вы продолжаете настрыно лезть из закрытого мира промышленных контроллеров в открытый всем ветрам мир бизнес приложений. Полностью игнорируя доводы и объяснения.

#{убрано самоцензурой} В бизнес приложениях данные надо шифровать, избегать взлома, менять протоколы - по этому в бизнес приложениях используется модель OSI, а в промышленных контроллерах - нет, там нет такой надобности.

Но это исполнение требует root прав, и это как-бы не совсем Userspace

Щито?

Разделение Userspace/Kernelspace никак не свзяано с юзером. Вообще. И root необязателен, достаточен CAP_NET_RAW.

Так что Userspace в чистом виде без всяких оговорок. И даже Ethernet header в буфере заполнять будешь ручками. Так что это L7 который напрямую работает с L2 в настолько чистом виде, насколько это возможно на писюковом железе.

Процесс с правами обычного пользователя не имеет полномочий работать ниже L4

Если ему CAP_NET_RAW не дать. Тогда имеет все полномочия.

А если железо не писюковое - там вообще всё намного интереснее, можно аж до L1.1 добраться, то бишь модуляции.

Вы продолжаете настрыно лезть из закрытого мира промышленных контроллеров в открытый всем ветрам мир бизнес приложений

Вот и занимайтесь своими бесмысленными «бизнес-приложениями», которые в отличии от «промышленных контроллеров» ничего реального не делают. И ко взрослым дядям со своими недоделанными OSI не лезте.

Вот и занимайтесь своими бесмысленными «бизнес-приложениями», которые в отличии от «промышленных контроллеров» ничего реального не делают. И ко взрослым дядям со своими недоделанными OSI не лезте.

Вы не «взрослый дядя», а юнный спорщик, который всё еще «меряется письками» на каком уровне абстракции работа круче. Естественно я не знаю всех тонкостей реализации нижнего уровня, потому, что работаю на более высоких уровнях абстракции, и не пытаюсь вас «срезать» - изначально предоставляя всю документацию и объясняя концепцию.

В большинстве случаев, при стандартной настройке UNIX новый пользователь не имеет прав ниже L4, и есть 1001 способ права расширить - что не отменяет общей концепции, о чем говорит создание eBPF и добавление Lua модулей в ядро NetBSD.

А вы пытаетесь напрыгнуть, уличить, оспорить, оскорбить, привести какой-то пограничный хак под конкретный тип ядра. Хотя дупля не отстреливаете в архитектуре приложений, хотя наверно каждый день оплачиваете карточкой покупки в терминалах.

Так что Userspace в чистом виде без всяких оговорок. И даже Ethernet header в буфере заполнять будешь ручками. Так что это L7 который напрямую работает с L2 в настолько чистом виде, насколько это возможно на писюковом железе.

Естественно более того потом все пакеты, фреймы - переводятся в мигание света или перепады напряжения. Почему вы останавливаетесь на уровне L2, а не идете до конца и не описывает как сигнал передается по витой паре?

Классический UNIX cокет работает с L4, без всяких хаков. С хаками можно делать, всё что угодо, начиная от включения каких-то изсыканных флагов, то прямого изменения политики работы Kernel.

Тоже могу перенять вашу игру, и буду доказывать вам, что вы ничего не умеете, нет ни каких Ethernet кадров, а есть только перепады напряжения на проводах. И вы лезите со своим никчемным программированием к взрослым дядькам - физикам.

LLM мне поможет, я узнаю какие уровни напряжения, и буду играть в тако-го же идиота, доказывая что все можно написать на ПЛИС и работать будет быстрей.

в тако-го же идиота

Давай ка ты подуспокоишься немного.

Давай ка ты подуспокоишься немного.

Да, вы правы, надо успокоиться.

А почему вы не реагируете на рассылание петухов steemandlinux и выкрики бугага с бессмысленными «ты скучен» от lesopilorama?

Вас давно замечают в избирательной модерации и злоупотреблении положением.

Жостко его затравили тут за пропаганду USB в сетевых технологиях.

Ты уже сайты микротика и openwrt посмотрел? Приглянулось что-то?

Микротик будет крайним случаем, потому что наиболее дорого и цена там не столько за железо, как мы понимаем, а совокупно - бренд, routeros, качество корпуса и дизайн и т.п.

OpenWRT сайт смотреть я не понял как - там вроде нет сортировки железок по производительности?

Если ему CAP_NET_RAW не дать. Тогда имеет все полномочия.

Еще поразмышлял над вашими комментариями. Unix-like Kernel - реализует услуги до L4 включительно, и позволяет разработчику пользоваться услугами TCP/UDP. Все последующие протоколы, а их много, TLS, DTLS, почта, веб, чаты, RSS - работают на этом базисе, и слоями зависят друг от друга.

Существуют хаки позволяющие пользователи спускаться ниже. Но эти хаки ломают переносимость кода между платформами. Усложняют кросс компиляцию. Взять к примеру Android - там жесткие политики в отношении пользовательских приложений. Код с предложенными вами хаками уже не запустить под Android (или какую-то подобную систему с усиленными требованиями к изоляции приложения, macOS к примеру).

Это именно, что платформо зависимый хак, а не универсальный, переносимый код. И это опять же отпечаток «промышленных контроллеров» - которые часто программируется под единичный экземпляр железа. В отличии от мира коммерческой разработки где требуется запускать код на различных платформах.

Можно конечно заточить пользовательское приложение для низкоуровневой работы - но смысла нет, это переписывать код библиотек и усложнять портирование. Заведомо нарушить договор между разработчиком утилиты с архитектурой OS - из седана делать трактор.

Странно, что вы этого не понимаете.

Но это исполнение требует root прав, и это как-бы не совсем Userspace.

Если ему CAP_NET_RAW не дать. Тогда имеет все полномочия.

CAP_NET_RAW это часть Capabilities, которые и есть полномочия суперпользователя. Полномочия которые ломают схему стандартных UNIX полномочий, про которые я вам говорил.

Starting with Linux 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.

Вот как получилось то. Вроде хотели «срезать», «оспорить», а не вышло. Как работают стандартные Unix сокеты над L4 так и работают, а чтоб дойти до уровня L3 и ниже, нужны особые привилегии.

схема Kernel-Userspase и Unix Socket над L4;

Но польза есть, есть. Эрудиция увеличена. Есть о чем поразмыслить, зачем нужно eBPF когда есть Capabilities.

Вроде хотели «срезать», «оспорить»

Бгг. Я даже не собирался ни «срезать» ни «оспаривать». Я просто объясняю как на самом деле обстоят дела. А со своей оторванной от реальности OSI и сферическими «Unix сокетами» в вакууме оставайтесь лучше на дне своего болота т.н. «бизнес-приложений» вместе с вебмакаками и жабокодерами. Там Вам как раз самое место, с такими-то «познаниями».

Почему вы игнорируете тезисы о переносимости кода или о необходимости удостовериться в подлинности адресата? Так фрагментарно выхватываете и переходите на оскорбления и попытки возвысить себя.

Вы не понимаете как обстоят дела на самом деле, у вас узкая техническая квалификация с полным отсутствием общего понимания. И перманентной истерикой. Вы же пользуетесь банковской картой, смартфоном - не хотите, чтоб ваши данные украли, но при этом бьетесь в истерики оскорбляя разработчиков стека который отличатся от вашего. И пользуетесь HTTPs, а не протоколом Gopher - который как раз реализуется на чистом TCP без проблем и лишних абстракций, Youtube поди вечерком смотрите, не брезгуете - а разработчиков оскорбляете.

Ваши неудобные тезисы - я разбираю, так как уверен в своей правоте, а вы избегаете моих. И постоянно оскорбляете, то чего не можете понять, например, модель OSI. Ведете себя как человек который бьется в истерики и кричит, что квадратного корня из -1 быть не может, и ваши комплексные числа туфта.

Почему вы игнорируете тезисы о переносимости кода

Потому что переносимость существенна только в вашем болоте «бизнес-приложений».

или о необходимости удостовериться в подлинности адресата?

Подлинность адресата не имеет вообще никакого отношения к сетевому стеку.

Вы же пользуетесь банковской картой, смартфоном - не хотите, чтоб ваши данные украли

Да, и именно поэтому я никогда никакие «бизнес-приложения» не использую и не собираюсь. А на смартфоне у меня разновидность Debian, в которой всё прекрасно и с IPPROTO_RAW и с правами root. :)

оскорбляя разработчиков стека который отличатся от вашего.

Разработчиков, которые разрабатывают что-либо на основе модели которая не соответствует физической реальности надо не только оскорблять, но и канделябром по мордасам лупить. Ибо от них одни проблемы мирового масштаба - от всяких «climate change», web2.0 и ведроида и заканчивая коронабесиями, ИИ хайпом и «бизнес-приложениями».

Подлинность адресата не имеет вообще никакого отношения к сетевому стеку.

Т.е. вы придумали свое определение сетевого стека, и с ним живете. Что там написано в спецификациях, учебниках - вам не тет дела. Вы выше.

Понял, принял.

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

отсеивать восторженных неофитов выучивших «сладкие слова»: USB, DMA, Шина, Опрос, ARM, Еthernet, Пакет. Но при этом ничего не понимающих

Твои последующие сообщения очень подходят под это описание.

А вы наверное тролль, раз отрицаете базовые определения

Это не базовые определения, это чья-то графомания, которая не соответствует реальности. Реальность описана в спецификациях используемых протоколов, и не надо её пытаться натягивать на графоманию.

TLS отделен от HTTP

Это «вызывающе неверная информация». https это не просто обычный http, завёрнутый в tls, и если бы ты не был столь вызывающе безграмотен, глупостей бы таких не писал.

Мне сообщения данного регистранта в этой теме уже не первый раз вызывают ассоциацию с выхлопом нейрогенератора. В связи с этим три теории:

1) это оно и есть

2) это не оно напрямую, но он его использует чтобы найти материалы для ответа, и в силу его безграмотности на выходе получается почти в неизменном виде то что ему выдал «помощник»

3) он специально косит под этот стиль т.к. где-то его увидел и посчитал что это признак крутости

как вы думаете, что из этого ближе к истине?

LLM мне поможет,

А, теория частично подтверждается.

То что твоё мышление не ушло дальше уровня неопытного студента мы это уже поняли.

https://netcert.tripod.com/ccna/internetworking/dod.html

https://en.wikipedia.org/wiki/Internet_protocol_suite

Про другие модели ты знать не знаешь и то, и что L5 - L7 это обычный send-recv, а следовательно один уровень ты понять не можешь.

А ещё покури протокол OPC-UA, он твою маня модель разрушает в ноль.

В Unix до 4 уровня включительно реалзиуется в Kernel

Это QUIC в kernel реализуется?

В реальном мире есть протоколы OPC, которые ну никак не вписываются в твои теории.

У меня приложение гоняет application данные поверх serial, bluetooth, hid и network через сокеты, упс…

сокеты реализованы над протоколами TCP/UDP

Конечно он ничего не знает:

socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM)

socket(AF_UNIX, SOCK_SEQPACKET, 0)

В бизнес приложениях данные надо шифровать, избегать взлома, менять протоколы - по этому в бизнес приложениях используется модель OSI, а в промышленных контроллерах - нет, там нет такой надобности.

1. У нас разве речь про бизнес приложения?

2. Бизнес приложения не используют socketfd?

Это получается бизнес приложение для амишей какое-то 🤔, раз он опустил всё остальное.

А платежи NFC тоже OSI модель используют, раз мы о бизнесе?