> Вообще-то СС - это иногда палочка о двух концах.Абсолютно, и 1 из фэйлов что приложения не могут это оверлоадить, если не прокатило. Особенно в винде.
> и собственно для этого и разрабатывается всё сетевое во FreeBSD.
После появления QUIC? Just in time, как обычно.
> чудовищную ошибку и с тех пор догоняют по сетям.
За почти 20 лет много изменилось.
> Нужно чётко понимать разницу между инновациями (придумали что-то свое),
> внедрениями (приняли стандарт, который придумали другие) и техническими долгами
> (переписали подсистему, потому что старая реализация плохо работала).
ИМХО:
1) Что-то придумать мало. Надо довести до ума.
2) ИМХО внедрение и стандарты связаны слабо. Какой у WinAPI стандарт? А вайргада уже имхо сильно больше чем айписека. ISO8859-5 вы юзали когда-то?
3) В линухе такого есть - но баг бывает фичой. Если крутые концепции не стоят на пути, рефакторить проще.
> Исторически сложилось, что ванильный Linux не пригоден ни на что кроме файрволла.
Прохладные истории из 2007? Почти все сетевое и серверное сейчас на линухе, от роутеров мыльниц и телевизоров до мощные роутеров, серверов, суперкомпьютеров и проч. Это - наблюдаемая реальность. Теории должны ее описывать. Иначе это хреновые теории.
> - Отсылки к OpenWRT - это прошивка которая способна реанимировать домашний роутер
> превратив его во что-то более менее рабочее.
Это де факто лишь особо-компактная сборка линуха, близкая к майнлайну на данный момент.
> - Отсылки к HW NAT Offload, потому что это то немногое, что
> доступно в OpenWRT и RouerOS.
Это насколько я помню - в майнлайне, и в целом некий механизм нарулили.
> делаются под BSD и согласуются с производителями чипов при участии конечных вендоров.
Как там в 2007? В 2024 вспоминается как яндекс послал фряху, устав драйверы писать.
> И мы сейчас говорим про нормальные сетевые устройства такие как
> Cisco, Juniper и им подобных. Linux не придумывал ни один Offload
В лине сейчас FB, Goog, и проч. Они достаточно круты чтобы с ноля роутеры делать под себя, проприетарь их достала. Им хочется соотв подсистемы. А какие-нибудь цыски могли разве что быренько подсуетиться предложив апи нашару в майнлайн, иначе просто другое будет.
> но она прежде всего файрволл, она делает NAT и умеет немножко в VPN и роутинг.
FYI оно прежде всего суперкомпактный дистр. И точка доступа. А фаер там - не очень имхо.
> Коммутация это не про нее. Собственно именно
> на L2 и его разгрузки в Linux не сделаны.
Однако даже там есть swconfig, которым можно порулить свичом как белый человек. От просмотра статистики до управления портами, вланами, режимом линка на порту, LED, ... так что бонусом копеечная мыльница = управляемый свич. Энтерпрайзникам понравилось, захотели такое же IIRC.
> чем ничего. Но вам всё равно, вам же не до даацентров...
Лично мне - да. Но вон та активность немного попала под внимание, когда были анонсы мощных открытых роутеров и стандартов, на именно линухе. FB/GooG старались.
...
> - скорость 5 гигабит вам выдаст одно ядро Intel Xeon Scalable Platinum
> (3-го поколения). Более свежих нет под рукой для тестов.
А это все, надеюсь, на последнем кернеле тестилось? А не 2007 года? Потому что там довольно крутые оптимизации не так давно были. В догонялках главное не проспать когда обошли на круг.
> Адаптеры Ethernet для датаентров ходовые сейчас 25G с аплинками до 100G (c
> 10G уже все уходят давно) есть и более свежие 100G
Некто Jens Axboe не так давно с 100 гбит и развлекался. И по части TCP и по части PPS'а. Довольно успешно.
[...]
> Так как Linux не используется в корпоративных развертываниях на бареметале, то
> всем на это пофиг.
На вашем корпоративе мир не заканчивается. И почему-то я вижу дофига линуха на bare metal. А чего туда еще ставить? Винду дорого, сабж в проде нафиг надо, макос не очень и хотел. И?!
> всунет это в systemd, и Linux-фанатики еще ныть будут, типа нафига
> нам это всё. Мрак.
А тем временем хостинги с KVM неспешно спустились с холма и захватили планету. Мне сие - то что надо. Недорого и круто.
> - реализация TLS на уровне ядра присутствует в Windows NT
Я от проблем винды (уже) далек.
> Netflix. Netflix её писал и заказывал её поддержку на крипто-ASICах встроенных
> в сетевые адаптеры Chelsio.
Т.е. прибито на гвозди к 1 вендору? Гениально.
> И никакое это не растяжимое понятие. Просто ASIC держит на себе всю
> сессию и даёт TLS Offload. Вот это почесались перенести в Linux.
В Linux менее отшибленые люди, там и иные варианты, типа более обычных адаптеров, но юзания альтернативных реализаций крипто - в том числе хардварно ускореных железками. А юзать опенсорц чтобы влететь в вендорлок - щнобелесвкую премию выдать. В номинации (эпикфейлов) прожектменеджмента конечно.
> делает Netflix и вы увидите. Что для сервисов бареметала у них
> Chelsio, а для виртуализации везде Mellanox, как и в других облаках.
А я не нетфликс и не фанат вендорлоков. Поэтому буду горой за решения которые не идут в комплекте с такими допущениями и доступнее для смертных.
> историческим причинам у них свои специфические оффлоады вокруг IPsec, которые нет
> в других ОС, но которые годами депрекейтят, чтобы перейти на сетевые технологии из BSD.
И эти "сетевые технологии из BSD" себя проявляют - в чем? Почему-то нетграф никто тырить не стал. Да и геом (хоть он и не про сеть). В ФС развитие вообще получают вообще интегрированые файлухи, так лучше работает, те концептуальные упражнения - попахали на мусорный бак.
> Факты о DPDK и других разгрузках. Вам нужно не просто это юзать,
> а делать это осмысленно для задачи.
Несомненно. Если кого-то ТУДА занесло, придется узнать много нового и думать о именно своих задачах. Специфичная штука для тех кому надо странного и - много. А вспомнился в этом контексте потому что с линухом это видал, а с BSD - нет.
> и 10G при передаче данных от одной виртуалки в другую, находящихся
> на одном и том же хосте виртуализации.
Ну, вообще, это довольно нишевая и специфичная задача. Хостерам например не интересно почти.
> работали именно на сетевках 25G и выше и у вас было
> бы хотя бы 50 стоек, вы бы поняли, почему упоминание QEMU+KVM+libvirt
> или даже Proxmox вызывает у меня гомерический хохот.
А мне забавно, когда тип с "аж" 50 стойками спорит - со всей планетой и ЛЕГИОНОМ KVMных хостингов. Продающих виртуалки оптом и в розницу. Я даже некоторые из - купил.
> Поймите, KVM и Linux всё это умеют. Но никто этим не пользуется.
> Можно теоретически написать инфраструктурное решение, но его нет.
Это довольно нишевые проблемы "крупняка без своей экспертизы" а не центр вселенной.
> То есть Hyper-V и ESXi это всё могут из коробки.
1) Вмварь так то продалась броадкому, их клиентуре станет интересно, имхо!
2) HyperV я нигде кроме абажура и пары партнеров MS не видел. Единственный публично доступный хостинг с этим известный мне - абажур.
> А в Linux это можно сделать самому. И вот тут-то DPDK и играет ключевую роль.
Чем мне нравится Linux - так это тем что если чего-то нет но оно надо, в отличие от проприетарных решений - пути открыты. Я в иной области это использую, но суть та же. А винду я бы в жизни не смог изогнуть как линух. Ну она мне и пофиг.
> юзерпейса сделыть было бы ничего нельзя. Ну то есть оно не
> далеко ушло от bhyve.
То-есть, я вижу кучу хостингов продающих KVM виртуалки недорого - и покупаю некоторые из. И на их bare metal, очевидно, стоит пингвин. Вопреки заявам. А bhyve вообще где?...
> уже написано на DPDK и у авторов есть желание сделать его
> кроссплатформенным то и это тоже можно сделать.
Плохо представляю себе кто и зачем будет что-то портировать на сабжа.
> Citrix угробил Xen, потому что денежки кончились (у них долги 1.6 ярда
> баксов долгов).
Да вот KVM пришел, virtio запилили, улучшили, стало резвенько, зачем Xen нужен малопонятно. Возиться с линем в Dom0 всерно придется, только эзотерично. Проще поставить единообразно ту же ос что в гуесты, и не делать мозг. Уменьшение BoM.
> исключительно на виртуальных рабочих столах и терминальниках. А инфраструктура вокруг
> KVM настолько ужасна, что её нужно переписывать:
Кому нужно - тому и карты в руки. Для _моих_ целей я использую или "raw" форму оной или свой собственный обвес. И это вполне по зубам 1 смертному. В отличие от покусаного энтерпрайзом проприетарного барахла где все прибито на гвозди.
> Поймите, там где во FreeBSD и Windows было и есть системное API
> в Linux нет нифига.
В линухе тоже есть свои апи. Для много чего. Например, для того же создания виртуалок. Не, qemu для этого - на самом деле не нужен. А на более высоком уровне тот же редхат сделал libvirt допустим, если кому надо. И так далее.
> И нет стандартизации, отсюда приходится переизобретать велосипед
Кто и с кем сие обсуждать будет? С жадным проприетарным вендорлокером? Уже с OOXML посмотрели как это. С BSDшниками вопящими что нинужна, 10 лет, пока в лине фичу юзают? Как с графикой было?
> Это страшный мрак. Настолько страшный, что проще считать KVM/Type2 виртуалку контейнером
> и довести до ума Kubernetes.
Проще? Считайте. Доводите. Я тут при чем?
> Отсюда в средне-крупном корпоратвином сегменте вы скорее увидите Hyper-V, чем KVM.
Капля в море по сравнению с KVM и числом его пользователей на планете. А работать в вон тех я не планирую.
> И вот опять про MPTCP:
> Оно не просто не обратно совместимо.
Если не получился MP - возможен fallback на просто TCP. Это совместимо с существующим оборудованием, насколько это возможно. Я про это.
> Оно не совместимо со своей собственной экспериментальной реализацией.
У меня это в итоге будут делать - линухи. Они между собой сконектятся. Остальное мне интересно сильно меньше и "до кучи", мелкий бонус.
> О чем они гордо и честно сообщают в свежем RFC. На больших нагрузках MPTCP это
> бутылочное горлышко (1 ядро),
Для многих сцераниев - это не будет проблемой. А где будет - вот там пусть у господ и болит голова. Это средство улучшения availability прежде всего. Относительно простое. А так Jens Axboe кажется подогнал малость лекарств вон тем.
> в сокет. Если вам не нужна производительность, то это ваше дело,
> но вы в меньшинстве.
Я думаю что таких как я очень сильно больше, чем тех кого вон то интересует. И технология найдет свое применение, соответственно. Впрочем у меня критерий простой: пролезает через существующее оборудование? Работает с моими конфигами? Будет поюзано.
> И я не зря привожу пример конфликта
> Linux, его разработчиков и кго пользователей с объективной реальностью.
А вы уверены что это не вы - конфликтуете с объективной реальностью? Для себя я вообще считаю здоровые жирные дорогие переростки динозаврами. Страшные, большие, но - ошибка эволюции. Будущее принадлежит распределенным системам, имхо. Там такие дино не требуются. Гигантомания - признак фэйла в архитектуре.
> меня везде будет Linux". Это бред и это плохо кончается.
Насколько я вижу, бред по архидорогим вендорлокнутым переросткам кончается хуже. Для его носителей.
> Что касается СС, Windows в перспективе пробует переход на RACK.
Перспективу на хлеб не намажешь, а гуглу надо решать свои проблемы с UX здесь и сейчас. Потому и QUIC.
> технологии на универсальные и узко специализированные. Например BBRv1 - это решение
> для Youtube как оптимизация относительно CUBIC для трафика север-юг. BBRv2, которого
> ЕМНИП нет в в ванильном Linux, это привнесение туда ECN и
> вовсе решение для трафика восток-запад.
В линух точно не ванильный BBRv1 в изначальном виде, его потом чинили, что может в ряде ситуаций скорость просадить, потом гугл еще какие-то патчи слал. И чему оно там соответствует - кто его знает? Знаю что на беспроводке работает лучше остального хлама в целом. И да, это сейчас колышет немного больше юзеров чем какие-то там датацентры.
> Они не нашли массового применения вне датацентров Google. Если у вас потери
> выше 20% вашему BBR придёт конец.
С такими потерями TCP вообще коллапсирует как правило. Но вон там господа из китая придумали как из бельевых веревок делать нормальные линки. Тоже multipath + FEC, и вот уже несколько бельевых веревок = нормальный линк. Но тоже нишевая штука. Китайцев интересовало еще и потому что великий фаер от этого сходит с ума.
> Вон на сервисах Google у QUIC везде CUBIC.
Гугл подробно отчитывается вам что они себе в апликущный уровень вкатили?
> И он сейчас стоит по умолчанию и в Windows и в BSD.
Это не годится для беспроводных соединений. Это имхо 80% причин по которым QUIC появился. Еще 20 это оптимизация хендшейка. И теперь гугл сможет делать как лучше работает. Что в хроме, что в проге ютуба. Вместо упования на алго навязаные на уровне системы.
> И кстати, прекрасно Windows себе всё это портирует.
Не помню чтобы в винде хотя-бы congestion control можно было выбрать.
> И как бы вы этого не отрицали, но Windows нужно учитывать.
Кому нужно, тот и учитывает. А гугол - вот - учел в понятном MS формате. Перенеся сие на уровень приложений, где он сделает так как ему удобно будет. MS только так понимает.
> на них, а не на консьюмерской электроники.
> - они массово поддерживаются на клиентских устройтсвах от Microsoft, Google и Apple.
Вика утверждает что Siri юзает MPTCP, если уж мы про это. Корпы довольно юркие когда вопрос в том чтобы конкурентов обставить.
> Ну а что касается примеров, вопрос открытый. Приведите мне КОНКРЕТНЫЙ пример VPN
> которая работает через MPTCP.
По сути любую программу юзающую TCP можно завести. Точно работает OpenVPN. Да и много чего еше. Шадоусоксы какие. Да, надо или чуток поменять сорц, или есть пара системных "хаков". В целом отличие только в создании сокета.
> Вообще, это очень странно, потому что TCP Meltown никто не отменял
> и инкапусуляция TCP-over-TCP для VPN всегда кончается трагично.
Сработает с (почти?) любыми TCP программами и не обязано быть впном.
> Как в ней победили эту проблему? И еще киньте хотя
> бы 2 ссылки из "дохреналиона".
Не понимаю, вас забанил гугол? Вбил наобум MPTCP VPN, нашел пример с openvpn, и что-то с соксами. А заодно и упоминание что эпловская сиря юзает это.
> Я спрашиваю, потому что не знаю применения MPTCP нигде, кроме как в NFS.
Любая программа которая умеет TCP, по сути умеет и MPTCP. По минимуму они могут ничего о нем не знать. А в лине есть и ряд иных забавных вещей. Вайргад впервые появился там. А сабж показал просто треш-парад с ЭТИМ.
Вариант для распечатки
