> Linux-специфичное барахло.

Я юзаю линух, в том числе и потому что считаю это "барахло" полезным мне.

> работает congestion control, а у протокола TCP есть многолетняя история развития
> костылей вокруг собственного CC внутри транспортного протокола. Но не TCP единым,..
> особенно после пришествия QUIC.

Ну и если мы об этом, CC в линуксе таки тоже свои. Я даже не знаю - есть ли нечто типа BBR в бсд? Или они на беспроводке совсем инвалиды? А, да, в вафле RTC/CTS конечно бывает но в силу ненадежности эфирных дел он сильно убивает перфоманс линка - и не в фаворе. Да и апликушному уровню это все наружу не вывешено же нормально. В том числе и потому что апи лохматые, эпохи беркелея.

> (ASIC-и), которые должны заниматься реализацией той или иной функции/протокола. Linux
> - это уникальная операционная система, которая объявила бойкот этой практике

И именно поэтому они запилили более-менее унифицированое управление свичами, как минимум куски HW NAT и подобного оффлоада, и - вот как раз подсистему взаимодействия с ASIC'ами? Ну логично.

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

> и боролась с объективной реальностью +/- до 2007-го года,

Офигеть - вы копнули на почти 20 лет.

> на оптических адаптерах. Одно ядро не способно обработать более 5 гигабит
> на приём, нужно распараллеливать по ядрам

Эти данные мягко говоря устарели. Хотя на 2.6.32 или что там в 2007 было, пожалуй.

> Ну и там еще есть всякие мелочи вроде хардварной реализации расчета сумм,

...ичсх все это в линухе уже эн лет к ряду...

> точного времени и в редких случаях даже некоторых шифров TLS для
> разгрузки ядерной реализации TLS, если в системе есть крипто-ASIC.

IIRC в лине и это должно работать, для KTLS. При том крипто-асик понятие растяжимое, даже в мелких soc бывает блок хардварного крипто умеющий те или иные алго.

> Подавляющее большинство того что я написал доступно в Linux, но не средствами
> ядра, а средствами DPDK, который заботливо написал Intel

Кое-что из перечисленого (но не все) вроде юзабельно и в более обычном виде. И с чего там KTLS (или что-то иное хотевшее шифрование) вдруг не сможет поюзать поддерживаемый кернелом крипто-аксель - ну хз. Я так понимаю что ядерный движок крипто может прозрачно подменить имплементацию крипто на оптимизированую или даже HW based если в энной системе так можно.

> Обратно перенести такой софт, кстати, тоже можно. Можно написать софт завязанный
> на DPDK и потом использовать в других ОС. FreeBSD и Windows тоже могут в DPDK.

Просто это несколько отличается от идей с нетграфами и прочей концептуальщиной. И основное возражение - что вон то как достоинство сватают. А оно как достоинство - для кого и почему? И во что на практике отливается?

> nftables или iptables не имеет значение. Это реализация файрволла в модуле netfilter.

Вообще его довольно сильно перепахали и перфоманс подняли. И фич дофига. А у бсд с фаерами - какая-то трешатина творится. При всей их концЭптуальности. У них что-то типа ipset есть вообще? В нем лукап в ТУЧЕ записей - быстрый. В этом его пойнт.

> другими сервисами он способен построить демилитаризованную зону вокруг каждого клиентского
> устройства. Требовать Kerberos-предаутентификацию перед установкой простых TCP-соединений
> на протоколах, которые это не умели и пошифровать всё в Ipsec.

На мой вкус - это как раз типичный майкрософт, бессмысленный и беспощадный. Лично мне все вон то не надо. А вон тем я еще и пользуюсь.

> Linux иметь в виртуалочке и называть это NGFW.

Угу, только это немного не про сабж... :)

> А при чем здесь это вообще? Всем известно что асинхронные операции ввода-вывода
> в ядре Linux были проблемными.

При том что очень крутая и шустрая штука, которую много куда приделали. Де факто нечто типа кольцевого буфера который замаплен и в ядро и в юзера, так что можно БЫСТРО пулять данные, без переключения контекстов и проч. Когда скорости IO возрасли всем почему-то это очень захотелось.

А так у них там еще много всяких интересных core-рефакторов типа группировок страниц в подшивки (это больше пока в ФС). И крутые оптимизации везде. Так что КМК ваши знания про 5 гбит изрядно протухли.

> отвечает Deferred Procedure Call (DPC).

В лине много чего в последнее время сделали и threaded - и воркеры сделали, и проч. У ядра ядерные треды есть, kthreadd ими заведует, некоторые треды юзают для ворочания длинных джобов асинхронно как раз. И равнять это с кернелом 2007 года - просто забудьте об этом. Там ща очень активно оверхед урезают везде и всюду.

> Наряду с кучкой CC и других плюшек. Я к тому, что
> io_uring это не преимущество, а решение проблемы убожества прошлой реализации AIO.

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

> Вообще надо бы вспомнить, что реализация Linux Virtual Switch из 90-х

А таки - и в линухе много чего переписали с тех пор. А вы хотели чтобы в 90х предусмотрели вон то?

> нормальные сетевки и свитчи, и что можно снизить нагрузку на хост
> виртуализации, воспользовавшись этим функционалом. Или они вращают кубернетисы в виртуалках
> на VMware, а это тоже не располагает к понимаю бареметала и
> синтетических ускорений.

Ну тут уж каждому свое. Этим хватает того. Те решают свои проблемы. А сабжи ... рассказывают как космические корабли бороздят просторы... ээ... тихого океана, чтоли?

>> MPTCP
> Это бредовенький способ разносить соединение по разным IP/маршрутам который переписали
> так, что версия v0 и v1 не совместимы ни в какую сторону?

Это - способ передавать данные по более чем 1 пути, как и сказано в описании. Его прелесть в том что оно backward compat. Т.е. если по пути какая-то система обиделась на расширение, ну, ок, будет простой TCP.

> Навязчивое желание использовать Multipath TCP - это явный признак непонимания сетей.

А по моему прикольная идея. Нарезать поток данных и протолкать сразу через эн конекций. Это нишевое развлечение но имеет свой смысл. Иногда. Его основной плюс в обратной совместимости с TCP и софтом для него.

> Вся эта идиотская идея притащить всё в TCP уже признана ущербной (даже
> RPC-протоколы начали переводить на QUIC).

Они в основном переходить начали - потому что если в линух гугл может свой BBR и проч протолкать, то в Windows - ага, ща. И что бы они не делали у себя - а с TCP у них вообще нет контроля над этим аспектом, и если ютуб на беспроводке затыкается, они никак не смогут улучшить участь юзеров винды. А на UDP они сами себе congestion control. Я думаю тут мы понимаем проблему более-менее одинаково.

> Она не находит массового применения.

Мне похрен. Я оценил фичу. А что будет с ESXi и Windows - меня не интересует. У меня заведомо будут линуксы и на клиенте, и на серверах везде к чему я имею отношение.

> В нормальных операционных системах, таких как FreeBSD, ESXi и Windows для организации
> Multipath используется 2 метода:

...сложнее на порядок и с кучей особенностей, а потому нафиг нужно в 99% случаев где вон то может пригодиться...

> 1. Использовать сеть и разносить соединения по хэшам в привязке к RSS,

Сложно и грабельно...

> 2. Реализовать Multipath на L7. То есть если у вас есть приложение
> или протокол пользовательского типа вы можете предусмотреть возможность использовать
> несколько сессий TCP

Требует серьезной переделки...

> Тут настоящая проблема в производительности MPTCP!

Я не знаю насколько оно пытается быть производительным, но забавная идея для нескольких тощих, не очень надежных и тому подобных линков - с динамическим согласованием и откатом до просто TCP если не получилось (man graceful degradation). При том что просто нарулить.

> - Потоки могут прийти на одно и тоже ядро или на разные.

Как вам понятно объяснить что для меня интересные кейсы MPTCP вообще не будут с именно ТОЙ проблемой сталкиваться? :)

> И вот я стесняюсь спросить вы как вообще в этой ситуации будете
> собирать этот поток и эффективно обрабатывать из него данные в приложении?!

Вы почему-то решили что я MPTCP хотел для очешуенного перфоманса между чуть ли не датацентрами. А у меня были сильно более другие идеи зачем это может быть полезно.

> А вообще, пока Windows не внедрит MPTCP и не выведет его в
> прод для всех клиентских

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

> P.S. Хохмы ради приведите мне живой пример TCP-сессии,

Я могу хохмы ради показать multipath VPN с FEC от китайцев. Делает из нескольких бельевых веревок подобие нормального линка. Представляете, те кто хотел такие вещи - не обязательно датацентры с 100500 гигабитов?! Есть дохреналион других кейсов для подобных фич. Но вы и сами найдете это добро вбив в поиск гитхаба эти кейворды. У вас мышление просто порушено датацентрами и вы почему-то решили что весь мир должен вертеться только вокруг этого. Просто для понимания: я вообще не датацентр и не мегакорп. И мне бесполезно сватать фичи за дохреналион с "докупите правильные адаптеры и постройте новый датацентр как надо".