Вообще-то СС - это иногда палочка о двух концах. Должен работать на обоих сторонах TCP-соединения для максимальной эффективности. Так вот RACK из FreeBSD портировали в Windows 11, то есть он будет вместо дефолтного CC. Скоро Linux его тоже притащит, потому что выбора нет, а лицензия позволяет и собственно для этого и разрабатывается всё сетевое во FreeBSD.

Я ведь не просто так возвращаюсь в 2007-й. Я это делаю, чтобы объяснить причину технологического отставания. Разработчики ядра Linux в прошлом сделали чудовищную ошибку и с тех пор догоняют по сетям. Нужно чётко понимать разницу между инновациями (придумали что-то свое), внедрениями (приняли стандарт, который придумали другие) и техническими долгами (переписали подсистему, потому что старая реализация плохо работала).

Исторически сложилось, что ванильный Linux не пригоден ни на что кроме файрволла. Перечитайте свой же комментарий и вы увидите:
- Отсылки к OpenWRT - это прошивка которая способна реанимировать домашний роутер превратив его во что-то более менее рабочее.
- Отсылки к HW NAT Offload, потому что это то немногое, что доступно в OpenWRT и RouerOS.
В том-то и дело что Linux не придумывал это всё. Типы разгрузок делаются под BSD и согласуются с производителями чипов при участии конечных вендоров. И мы сейчас говорим про нормальные сетевые устройства такие как Cisco, Juniper и им подобных. Linux не придумывал ни один Offload он всегда догоняющий и подстраивается под чужие API и драйверы.
OpenWRT - это открытая прошивка для консюмерского железа. Она решает свою задачу но она прежде всего файрволл, она делает NAT и умеет немножко в VPN и роутинг. Коммутация это не про нее. Собственно именно на L2 и его разгрузки в Linux не сделаны. При чем ни в каком... хотя нет. Есть Cumulus Linux, но он сейчас NVIDIA работает только со спектрумами и удачи вам его поставить. Оно проприетарное настолько, насколько это вообще возможно. А и еще есть NexusOS, которая частично Linux, частично NetBSD, но там от линукса чуть менее чем ничего. Но вам всё равно, вам же не до даацентров...

Дальше нужно вам дать небольшой фактчекинг.

Факты про RSS:
- без применения RSS и без настройки профилей RSS под топологию NUMA весь трафик пойдет через одно единственное ядрро. RSS есть в Linux очень давно. Но админы Linux не умеют пользоваться ethtool и не умеют его настраивать.
- скорость 5 гигабит вам выдаст одно ядро Intel Xeon Scalable Platinum (3-го поколения). Более свежих нет под рукой для тестов.
- в условном 2007-ом оно выдавало 3 гигабита на одно ядре сколько-нибудь приличного процессора.
Адаптеры Ethernet для датаентров ходовые сейчас 25G с аплинками до 100G (c 10G уже все уходят давно) есть и более свежие 100G с аплинками в 400G. Чтобы этим пользоваться вы ОБЯЗАНЫ распаралеливать трафик, считать хэши Тёплица (https://en.wikipedia.org/wiki/Toeplitz_Hash_Algorithm), определять под вендора сетевки количество аппаратных очередей, назначать им процессоры. Желательно динамически меняя эту конфигурацию в зависимости от реальной утилизации CPU. Иначе вы не выжмете скорость. Это не "устаревшие данные" это вы просто ничего выше гигабита не видели, поэтому не знаете. Динамическое перестроение RSS indirection table средствами ядра Linux не возможно. Оно возможно в драйверах, но кто будет мониторить производительность юзерспейса и переназначать потоковую нагрузку на receive datapath? Спихнут как всегда на юзерспейс и пусть дистрибутивы пишут какого-нибудь демона для мониторинга, но они как всегда не напишут. Так как Linux не используется в корпоративных развертываниях на бареметале, то всем на это пофиг. Мальчики с Proxmox используют 1G адаптеры и не видят проблемы. Облачники сами себе дистрибутивы собрали и они не публичные. Если это станет массово нужно всем настроить, Red Hat принудительно всунет это в systemd, и Linux-фанатики еще ныть будут, типа нафига нам это всё. Мрак.

Факты про kTLS:
- реализация TLS на уровне ядра присутствует в Windows NT начиная с незапамятных времен, драйвер называется schannel. Я к тому что это не новинка.
- реализация TLS на уровне ядра во FreeBSD присутствует c момента существования Netflix. Netflix её писал и заказывал её поддержку на крипто-ASICах встроенных в сетевые адаптеры Chelsio.
И никакое это не растяжимое понятие. Просто ASIC держит на себе всю сессию и даёт TLS Offload. Вот это почесались перенести в Linux. В Mellanox там с TLS только в некоторых сетевках есть и они через TLS свой RDMA шифруют. Собственно почитайте как свои сервера делает Netflix и вы увидите. Что для сервисов бареметала у них Chelsio, а для виртуализации везде Mellanox, как и в других облаках.
- Windows не поддерживает TLS Offload на эти ASIC, потому что по историческим причинам у них свои специфические оффлоады вокруг IPsec, которые нет в других ОС, но которые годами депрекейтят, чтобы перейти на сетевые технологии из BSD.

Факты о DPDK и других разгрузках. Вам нужно не просто это юзать, а делать это осмысленно для задачи. Например, задача виртуализации предполагает, что виртуальные адаптеры ВМ-ок нужно располагать поближе к receive datapath. Планировщик гипервизора и компоненты управления в юзерспейсы должны:
1) Указать/выбрать одно или несколько ядер внутрь виртуалки для receive datapath в ОС, чтобы RSS работал внутри виртуалки тоже. Иначе вы не разовьёте и 10G при передаче данных от одной виртуалки в другую, находящихся на одном и том же хосте виртуализации.
2) Указать/выбрать аппаратные очереди сетевого адаптера для передачи данных в виртуалку по обычной шине.
3) С учетом того что у каждого виртуального адапетра свой мак вы по ним считаете суммы. На основании п.1 и п2 вы можете построить соответствие в форме таблицы какие потоки и хэши (по виртуальному маку, например) на какое ядро должны попадать
4) Далее вам нужно уметь переносить ваши виртуалки средствами гипервизора, с одного ядра на другое, чтобы достигать равномерной утилизации CPU
5) Совместно с п.4 динамически обновлять таблицу соответствия в прошивке.
6) Вы должны учесть пары не только обычных Rx/Tx аппаратных очередей, но также пары очередей SR-IOV, и включить их в динамическую балансировку утилизации.
7) В случае виртуализации вы должны разделить узлы виртуализации как минимум на 2 типа. Обычные, на которых включен LRO и LSO, и телефонно-роутерно-файрвольные, где LRO и LSO выключены. Если бы вы со всем этим работали именно на сетевках 25G и выше и у вас было бы хотя бы 50 стоек, вы бы поняли, почему упоминание QEMU+KVM+libvirt или даже Proxmox вызывает у меня гомерический хохот.

Поймите, KVM и Linux всё это умеют. Но никто этим не пользуется. Можно теоретически написать инфраструктурное решение, но его нет. То есть Hyper-V и ESXi это всё могут из коробки. А в Linux это можно сделать самому. И вот тут-то DPDK и играет ключевую роль. Роль затыкания дыры в API, потому что без него вообще из юзерпейса сделыть было бы ничего нельзя. Ну то есть оно не далеко ушло от bhyve. Те кто пишет под Linux и хотят использовать синтетические ускорения вынуждены использовать DPDK. На друних ОС есть свои API как в ядре так и в юзерспейсе. Но если ПО уже написано на DPDK и у авторов есть желание сделать его кроссплатформенным то и это тоже можно сделать.

То есть это не инновации, а внедрение того что есть у других. И я, тем более, не разделяю вашей искренней радости вокруг файрволла и асинхронного IO. Да, раньше было всё ужасно. Начиная с ядра 5.1 (ЕМНИП) оно просто стало на том же уровне как и у всех остальных. Это даже не внедрение, а банальное исправление техдолгов. И ведь все равно не хватает.
Citrix угробил Xen, потому что денежки кончились (у них долги 1.6 ярда баксов долгов). Они сократили вложения в инфраструктурные проекты и сконцентрировались исключительно на виртуальных рабочих столах и терминальниках. А инфраструктура вокруг KVM настолько ужасна, что её нужно переписывать:
- Red Hat выкинул oVirt и предлагает виртуализацию на базе OpenShift, в котором пытается догнать и предоставить реализацию того, что я писал выше в примере.
- Mirantis и куча других вендоров OpenStack также переходят на собственные сборки Kubernetes, потому что без него, как средства хоть какой-то кластеризации и автоматизации управления инфраструктурой жить нельзя.
Поймите, там где во FreeBSD и Windows было и есть системное API в Linux нет нифига. И нет стандартизации, отсюда приходится переизобретать велосипед в каждой реализации KVM каждому вендору инфраструктуры виртуализации и каждому дистрибутиву. Это страшный мрак. Настолько страшный, что проще считать KVM/Type2 виртуалку контейнером и довести до ума Kubernetes.
Но у него исторические проблемы работы с многопроцессорными серверами. Google же ставит компьют на однопроцессорные блейды, им пофиг на всех остальных. А в случае с несколькими сокетами, NUMA и связкой сетевок и HBA с разными сокетами планировщик контейнерной среды или гипервизора должен и это тоже учитывать. Отсюда в средне-крупном корпоратвином сегменте вы скорее увидите Hyper-V, чем KVM.

И вот опять про MPTCP:
Оно не просто не обратно совместимо. Оно не совместимо со своей собственной экспериментальной реализацией. О чем они гордо и честно сообщают в свежем RFC. На больших нагрузках MPTCP это бутылочное горлышко (1 ядро), потому что нужно собрать 2 или более потоков вместе перед возвратом данных в сокет. Если вам не нужна производительность, то это ваше дело, но вы в меньшинстве. И я не зря привожу пример конфликта Linux, его разработчиков и кго пользователей с объективной реальностью. Это было и 20 лет назад это происходит и сейчас, с вашим "у меня везде будет Linux". Это бред и это плохо кончается.

Что касается СС, Windows в перспективе пробует переход на RACK. Сейчас что в TCP, что в QUIC основной congestion control - это CUBIC для внешнего интернета. И DCQCN/DCTCP для служебных потоков внутри датацентров (это когда используются одновременно PFC, RED и ECN). Здесь нужно чётко разделять технологии на универсальные и узко специализированные. Например BBRv1 - это решение для Youtube как оптимизация относительно CUBIC для трафика север-юг. BBRv2, которого ЕМНИП нет в в ванильном Linux, это привнесение туда ECN и вовсе решение для трафика восток-запад. Они не нашли массового применения вне датацентров Google. Если у вас потери выше 20% вашему BBR придёт конец. Вон на сервисах Google у QUIC везде CUBIC. И он сейчас стоит по умолчанию и в Windows и в BSD. И кстати, прекрасно Windows себе всё это портирует. Я просто напомню, что CUBIC - это одно из немногого что вышло из Linux (инновация в 2006-ом году) и стало сетевым стандартом и прекрасно его Windows адаптировал.

И как бы вы этого не отрицали, но Windows нужно учитывать. Все эти технологии становятся массовыми только если:
- они пригодны для крупных ДЦ. Вендоры которые разрабатывают железо зарабатывают именно на них, а не на консьюмерской электроники.
- они массово поддерживаются на клиентских устройтсвах от Microsoft, Google и Apple.

Ну а что касается примеров, вопрос открытый. Приведите мне КОНКРЕТНЫЙ пример VPN которая работает через MPTCP. Вообще, это очень странно, потому что TCP Meltown никто не отменял и инкапусуляция TCP-over-TCP для VPN всегда кончается трагично. Как в ней победили эту проблему? И еще киньте хотя бы 2 ссылки из "дохреналиона". Я спрашиваю, потому что не знаю применения MPTCP нигде, кроме как в NFS. Но там всё сделано из рук вон плохо, и это как раз тот случай, когда проще протокол расширить.