The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Уязвимость в uClibc и uClibc-ng, позволяющая подменить данные в кэше DNS"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Уязвимость в uClibc и uClibc-ng, позволяющая подменить данные в кэше DNS"  +/
Сообщение от opennews (??), 04-Май-22, 14:40 
В стандартных Си-библиотеках uClibc и uClibc-ng, применяемых во многих встраиваемых и портативных устройствах, выявлена уязвимость (CVE не присвоен), позволяющая подставить фиктивные данные в кэш DNS, что можно использовать для подмены в кэше IP-адреса произвольного домена и перенаправления обращений к домену на сервер злоумышленника...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57131

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 04-Май-22, 14:40   +4 +/
Никогда не было, и вот опять
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43

2. Сообщение от Аноним (2), 04-Май-22, 14:43   –6 +/
Programs written on C be like:
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #10

3. Сообщение от Аниме (?), 04-Май-22, 14:44   +/
Надо переписать на Hare
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8

4. Сообщение от Аноним (4), 04-Май-22, 14:48   +2 +/
Не, ну с printf было забавнее, я так понимаю у них у всех качество кода примерно одинаковое.
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от timur.davletshin (ok), 04-Май-22, 14:54   +1 +/
OpenWRT же на musl переезжал, нет?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #18

6. Сообщение от Аноним (6), 04-Май-22, 15:02   –3 +/
UDP маздай.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9

7. Сообщение от Аноним (7), 04-Май-22, 15:04   +3 +/
Да-да, Rust бы здесь помог ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #13

8. Сообщение от Аноним (7), 04-Май-22, 15:06   +/
Hare внезапно бы сам догадался, что вот здесь надо рандомизировать ID.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

9. Сообщение от Аноним (7), 04-Май-22, 15:07   +/
Однако, NAT он пробивает лучше, чем TCP.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #12

10. Сообщение от Аноним (10), 04-Май-22, 15:10   +/
Debian with Glibc ннада?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

11. Сообщение от Мохнатый пись (?), 04-Май-22, 15:11   +/
Деды-пердуны на 19.07 могут иметь uClibc
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #16

12. Сообщение от Мохнатый пись (?), 04-Май-22, 15:13   –1 +/
NAT не нужен, но UDP ещё и канал лучше утилизирует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #17, #24

13. Сообщение от НяшМяш (ok), 04-Май-22, 15:18   +6 +/
Был бы uClibc написан на расте, тут было бы 300+ постов экспертных мнений. А так под комменты даже не пообедать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

15. Сообщение от pashev.ru (?), 04-Май-22, 15:40   +1 +/
Теперь народ начнёт понимать, почему glibc такая "жирная" 🙂
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32, #35

16. Сообщение от timur.davletshin (ok), 04-Май-22, 15:47   +1 +/
Там тоже musl.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

17. Сообщение от timur.davletshin (ok), 04-Май-22, 15:52   +/
Он использует те же алгоритмы управления потоком, что и TCP. Просто напулять пакетов без проверки доставки можно больше, но кому такое нужно? Даже realtime видео нафиг не упало, если оно рассыпается на кашу из квадратов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #20

18. Сообщение от Аноним (18), 04-Май-22, 16:19   +/
> musl

Там же тоже какие-то застаревшие проблемы с сетью, с тем же DNS, нет?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #19, #29

19. Сообщение от timur.davletshin (ok), 04-Май-22, 16:20   +/
>> musl
> Там же тоже какие-то застаревшие проблемы с сетью, с тем же DNS,
> нет?

Нет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #21

20. Сообщение от Мохнатый пись (?), 04-Май-22, 16:31   –1 +/
QUIC может использовать свои алгоритмы для проверки доставки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #23

21. Сообщение от Аноним (18), 04-Май-22, 16:31   +/
А пишут, что musl = based but still immature with a lot of network issues, glibc = cringe but rock solid.

Уже нет? :) Ура!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #22

22. Сообщение от timur.davletshin (ok), 04-Май-22, 16:37   +3 +/
Ты накидывай лучше сразу ссылки на уязвимости в DNS, а не языком по широкому холсту.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #27

23. Сообщение от timur.davletshin (ok), 04-Май-22, 16:42   +/
> QUIC может использовать свои алгоритмы для проверки доставки.

Проверка доставки или всё же управление потоком? Так-то в подавляющем большинстве реализаций обычный CUBIC стоит в дефолте. Почему выносить из усерспейса VPN в ядро считается хорошим (Wireguard), а перенос realtime управления потоком из ядра в узерспейс (TCP → QUIC) не считается плохой идеей? Вам не кажется, что где-то в одном из двух случаев логика даёт сбой и создатели протокола просто "залечивают" без должного обоснования.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #25, #30

24. Сообщение от Аноним (7), 04-Май-22, 16:44   +/
Скажи это провайдерам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #28

25. Сообщение от Аноним (7), 04-Май-22, 16:47   +1 +/
QUIC - синдром NIH Гугли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

27. Сообщение от Nr (?), 04-Май-22, 17:03   +/
Есть и musl, и glibc https://openwrt.org/releases/22.03/notes-22.03.0-rc1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #33

28. Сообщение от Мохнатый пись (?), 04-Май-22, 17:20   +/
Говорю каждый раз, пора бы уже ipv6 внедрять. Внедрение ipv6 во всём постсовсовке на уровне стран африки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #45, #46

29. Сообщение от Аноним (29), 04-Май-22, 17:56   +/
ага, например, musl не умеет в DNS через TCP
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #36

30. Сообщение от Аноним (-), 04-Май-22, 18:02   –1 +/
> Почему выносить из усерспейса VPN в ядро считается хорошим (Wireguard), а перенос realtime управления потоком из ядра в узерспейс (TCP → QUIC) не считается плохой идеей?

Потому что это разные задачи. Разным задачам, разные решения. Ты не знал об этом? Всё ищешь серебряную пулю? Успехов в поисках, тогда.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #31

31. Сообщение от timur.davletshin (ok), 04-Май-22, 18:16   +/
> Потому что это разные задачи. Разным задачам, разные решения. Ты не знал
> об этом? Всё ищешь серебряную пулю? Успехов в поисках, тогда.

Господин, вы бредите. Когда-нибудь на досуге попробуй джиттер померять в userspace реализациях и в kernel. Гарантирую, ты прозреешь. Как ресэмплинг звука в userspace вынесли, так все начали ныть про кривой pulseaudio, хотя он просто старые алгоритмы вынес в пользовательское пространство. В сетевых протоколах есть абсолютно идентичный негативный эффект от подобного переноса и не важно, это VPN или CUBIC/Reno, реализованные поверх UDP.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #34

32. Сообщение от Аноним (32), 04-Май-22, 18:20   –1 +/
Думаешь в glibc нет бэкдоров? Поверь мне, их там еще больше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #39

33. Сообщение от timur.davletshin (ok), 04-Май-22, 18:23   +/
> Есть и musl, и glibc https://openwrt.org/releases/22.03/notes-22.03.0-rc1

Это тулчейн. Как оно компиляется по большому счёту никому нет дела. А libc в самом OpenWRT от musl.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

34. Сообщение от Аноним (-), 04-Май-22, 18:37   –1 +/
Нет ты.

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

Во-вторых, разработка чего-либо в ядре гораздо дороже. Строчка кода ядра обходится дороже, чем строчка кода юзерспейса. Поддержка этой строчки кода обходится резко дороже. Это ещё помножается на то, что ядерная разработка будет работать только с одним ядром, и если ты хочешь кроссплатформенности, то тебе придётся вести несколько разработок под разные ядра. OpenVPN тоже исходно разрабатывался в юзерспейсе, несмотря на весь этот твой бла-бла-бла про джиттер. Почему? Разработчики, что тупее тебя были? Нет, они как раз были умнее. Они знали, что разработка в ядре дорого, и поэтому нащупывать правильную архитектуру для реализации VPN, правильные структуры данных, правильные алгоритмы, структуру конфига, и всё остальное лучше в юзерспейсе. В юзерспейсе дешевле разрабатывать код, дешевле его мейнтейнить, дешевле дебажить, дешевле профайлить, ошибки (как архитектурные так и вида use-after-free) обходятся и исправляются дешевле, и поэтому в юзерспейсе было возможно разработать OpenVPN, в ядре практически невозможно. Вот теперь, когда накоплен опыт разработки VPN, опыт использования VPN, когда можно профайлить работу VPN со всех сторон, выясняя где и какие бутылочные горлышки возникают, вот теперь можно запилить и ядерную реализацию, причём сразу отливая её в граните так, чтобы потом не перелопачивать каждый год, когда очередная гениальная идея в голову пришла, или когда какое-нибудь важное наблюдение о строчке кода-источнике джиттера было сделано.

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

QUIC -- это сырой протокол. Из которого хрен знает, что выйдет, и выйдет ли. Вероятно гугл применил кучу теории, для того, чтобы предсказать результат, но теория на то и теория, чтобы проверяться практикой. Только опеннетовец может ратовать за то, чтобы вбухивать сотни нефти в разработку этого QUIC прям сразу в ядре. Любой разумный человек будет разрабатывать его в юзерспейсе поверх стандартного для многих платформ API сокетов, внедрять на все платформы в юзерспейс, собирать данные с практического применения, и вот только после этого ставить вопрос: а не занести ли QUIC в ядро?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #37, #38

35. Сообщение от Аноним (-), 04-Май-22, 18:44   +/
Все кто любят юникс, первым делом выпиливают юниксовые "убства" в первую очередь. Либси должна содержать наборчик макросов 90% скопипащеных с ядра и неболее ящитаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

36. Сообщение от Аноним (18), 04-Май-22, 19:32   –1 +/
То есть DoT/DoH в Alpine Linux не будет работать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #55

37. Сообщение от timur.davletshin (ok), 04-Май-22, 19:42   +/
> Нет ты.
> Во-первых, VPN и HTTPS -- это разные протоколы под разные задачи. Если
> ты говоришь, что они принципиально не отличаются по своим требованиям к
> реализации, то давай обосновывай нам, почему они принципиально не различаются. Давай-давай.

Читай внимательно, что я написал. Мне до твоего HTTPS дела нет, я писал про управление потоком в QUIC как пример корявости, т.к. данное действие является задачей близкой к realtime'у. А ведь именно уменьшение накладных расходов на операции подобного приоритета стали обоснованием для выноса протокола Wireguard в ядро. Будто до этого VPN'ов на уровне ядра не было...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #56

38. Сообщение от timur.davletshin (ok), 04-Май-22, 19:47   +/
> Почему? Разработчики, что тупее тебя были? Нет, они как раз были умнее.
> QUIC -- это сырой протокол. Из которого хрен знает, что выйдет, и
> выйдет ли. Вероятно гугл применил кучу теории, для того, чтобы предсказать
> результат, но теория на то и теория, чтобы проверяться практикой.

Разрабы Google, выходит, у тебя лохи печальные, а в Wireguard ну просто гении. Дружище, научись писать внутренне непротиворечивые тексты для начала. А там, может, и до деталей реализации RTP дойдём.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

39. Сообщение от Онаним (?), 04-Май-22, 19:53   +/
Системы с glibc обычно не проблема обновить.
А вот то, где uclibc - многое из этого уже (древнющее и не очень) легаси, в т.ч. разряда хоаксного iot, для которого вендор прошивку выпускать уже не будет, да и есть ли он.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #41

40. Сообщение от Аноним (40), 04-Май-22, 21:30   +1 +/
Гордый суффикс "-ng" прикрутили, а на прикрутить рандом "не в состоянии исправить"? :D
Ответить | Правка | Наверх | Cообщить модератору

41. Сообщение от Аноним (41), 04-Май-22, 22:31   +/
Обновишь и получишь еще больше бэкдоров, руткитов, вирусов, телеметрии, малвари и фингерпринтинга.
Сомнительное преимущество.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #42

42. Сообщение от Онаним (?), 04-Май-22, 22:33   +1 +/
Всё ещё сидишь на ядре 2.0?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

43. Сообщение от Аноним (43), 04-Май-22, 22:46   +/
Опять детский сад и школа виноваты? 👀 )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

45. Сообщение от Онаним (?), 04-Май-22, 23:58   +/
Открою тебе секрет - и не только в постсовке.
У нас есть полтора пользователя IPv6, Европа, причём западная.
Они даже им вроде как пользуются.
Но абсолютное и подавляющее большинство им не интересуется вообще.
Не взлетело.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

46. Сообщение от Онаним (?), 05-Май-22, 00:00   +/
(нет, мы можем всем выдать по /64 автоматом, и даже пробовали на все серверы его развесить (не зашло, поубирали) - и после бодро отрапортоваться о 100% пенетрации, но клиентам от этого будет только хуже - жалобы на откровенно хреновую работу при попытке подобное делать были, есть, и будут есть)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #47

47. Сообщение от Онаним (?), 05-Май-22, 00:02   +/
А не зашло потому, что какому-то <beep> пришло в дурную голову AAAA при резолве DNS сделать приоритетным.
В итоге некоторые внешние юзеры того же хостинга начинают вместо 30-40мс отклика иметь 80-120, а то и вообще ничего не иметь, и начинают жаловаться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #49

49. Сообщение от Мохнатый пись (?), 05-Май-22, 00:34   +1 +/
> А не зашло потому, что какому-то <beep> пришло в дурную голову AAAA
> при резолве DNS сделать приоритетным.
> В итоге некоторые внешние юзеры того же хостинга начинают вместо 30-40мс отклика
> иметь 80-120, а то и вообще ничего не иметь, и начинают
> жаловаться.

Кулстори какие-то. Сижу через туннель, ибо провайдер дебил, пинг из-за европейского сервера выше на 80мс до яндекса. И знаешь что? Различий вообще почти не вижу, может у вас такая реализация была классная? А чтобы колическо пользователей выросло, то надо свои роутеры через TR-69 настраивать и пользователям говорить, чтобы ipv6 включали, либо (что менее вероятно из-за кривых приложений с захардкоженным ipv4 адресом) сразу отрубать ipv4, выпускать только с ipv6 и NAT64. Так кстати некоторые новые провайдеры делают и мобильные операторы, ибо ipv4 уже на вес золота.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #51, #52

51. Сообщение от Онаним (?), 05-Май-22, 22:05   +1 +/
> отрубать ipv4, выпускать только с ipv6 и NAT64

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

52. Сообщение от Онаним (?), 05-Май-22, 22:21   +/
Ну а чего кулстори. Есть провайдеры в местных (ну, не местных, соседние страны) залупищенсках, трасса по IPv6 от которых идёт через такие дрындыня, что закачаешься. И вот когда на сервере вывешиваешь IPv6, из этой страны начинают ходить по болотам вприпрыжку, потому что академичные дятлы заприорили AAAA, всем по IPv6 и нивалнуед, что там потери, и лейтенси двукратный. А между странами всего 150 км расстояния, и они друг к другу в магазины ходят :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #53

53. Сообщение от Онаним (?), 05-Май-22, 22:22   +/
Это сейчас ещё хецнеровские туннели убились - стало полегче, раньше можно было легко на них нарваться, там вообще благодать была.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

55. Сообщение от ilyafedin (ok), 06-Май-22, 06:45   +/
DoT/DoH не через libc работают
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

56. Сообщение от Онаним (?), 06-Май-22, 09:40   –1 +/
Вирегад в ядро вытащен только по одной причине, по той же, по которой опенжпн свой ядерный модуль пилит.
Если подавать данные для декодирования через юзерспейс - это лишняя смена контекста на каждый долбаный пакет.

В случае клюка совершенно не актуально, потому что тот, кто его танцует, его и ужинает.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #57

57. Сообщение от timur.davletshin (ok), 06-Май-22, 10:14   +/
> Вирегад в ядро вытащен только по одной причине, по той же, по
> которой опенжпн свой ядерный модуль пилит.
> Если подавать данные для декодирования через юзерспейс - это лишняя смена контекста
> на каждый долбаный пакет.

Т.е. QUIC в таком случае не должен существовать. Спасибо, что хоть на таком уровне со мной согласились.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #58

58. Сообщение от Онаним (?), 06-Май-22, 13:49   +/
Клюк в ядре не нужен. Он вполне может существовать в юзерспейсе - пакеты приходят всё тому же адресату, который занимается и управлением потоком.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #59

59. Сообщение от timur.davletshin (ok), 06-Май-22, 15:43   +/
> Клюк в ядре не нужен. Он вполне может существовать в юзерспейсе -
> пакеты приходят всё тому же адресату, который занимается и управлением потоком.

А чё он тогда на 30% жручее до CPU? В чём профит тогда? В обновляемости congestion control'а? Так фуфло это. Гуглу одинаково легко обновить что bbr.ko, что код веб-сервера. А сторона клиента значения не имеет от слова вообще (если ты только не загружаешь что-то). Я уже не говорю про конкретные реализации QUIC с их конкретными глюками и затупами. Чего только в 2-5 раз более медленная загрузка на Firefox/QUIC стоит.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #60, #61

60. Сообщение от Онаним (?), 06-Май-22, 17:06   +/
Жручее по сравнению с чем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #62

61. Сообщение от Онаним (?), 06-Май-22, 17:06   +/
И да, всё правильно. В обновляемости алкоритмов, написанных с бодуна под смузи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

62. Сообщение от timur.davletshin (ok), 06-Май-22, 18:56   +/
> Жручее по сравнению с чем?

В сравнении с TCP.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #63

63. Сообщение от Онаним (?), 06-Май-22, 19:21   +/
Э, а ничего, что там SSL сверху?
Тогда уж с HTTPS сравнивай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #64

64. Сообщение от timur.davletshin (ok), 06-Май-22, 21:45   +/
> Э, а ничего, что там SSL сверху?
> Тогда уж с HTTPS сравнивай.

Сравнивали и не один раз:
https://www.fastly.com/cimages/6pk8mg3yh2ee/495gZP7ZprKQUsEj...

Если сравнивать BBR vs CUBIC, то первый сливает везде, кроме линий с большим дропом и большой задержкой.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #65, #66

65. Сообщение от Онаним (?), 06-Май-22, 22:04   +/
Опять какое-то тёплое с мягким.
Можно CPU usage при одинаковом throughput, а не сферических коней в вакууме?
Впрочем я уверен, у QUIC он будет больше - разбирать подобие DTLS (мелкими блоками) - так себе затея.
Другое дело, что он не для передачи гигабит в секунду, он больше для контроля latency на куче смузи-опилок, из которых современные говносайты построены.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #67

66. Сообщение от Онаним (?), 06-Май-22, 22:06   +/
К слову, в том, что кряк - говно, я не сомневаюсь ни разу.
Но там дело не в том, что он не в ядре.
Дело в попытке соплями и скотчем примотать L4 к L7.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

67. Сообщение от timur.davletshin (ok), 06-Май-22, 22:25   +/
> Можно CPU usage при одинаковом throughput, а не сферических коней в вакууме?

Можно: https://conferences.sigcomm.org/sigcomm/2020/files/slides/ep...

Советую почитать выводы. Протокол, который обещал при создании обновления алгоритма без вмешательства в систему, требует сетевое оборудование с GSO и нужно патчить реализацию UDP sendmsg для обеспечения более-менее сравнимой скорости. Я нахожу это ироничным.

> Другое дело, что он не для передачи гигабит в секунду, он больше
> для контроля latency на куче смузи-опилок, из которых современные говносайты построены.

Посмотри обоснование для его создания.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #68, #69

68. Сообщение от Онаним (?), 08-Май-22, 18:20   +/
> Можно: https://conferences.sigcomm.org/sigcomm/2020/files/slides/ep...

Опять какие-то сферические гуглы в вакууме.
Но даже если попытаться из этой ахинеи какие-то выводы сделать - то оно реально колышется где-то на уровне HTTPS ныне, плюс минус вечность в зависимости от имплементации.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

69. Сообщение от Онаним (?), 08-Май-22, 18:22   +/
Но кстати вот эта смузи-презенташка моё предположение подтвердила неожиданно, разбирать и слать DTLS - очень накладно.

Но я вангую что с клюком нас ждёт огромная масса смешного секса, и в итоге оно будет о полутора землекопах. Не потому, что там с производительностью плохо. Я тут погуглил на тему интеропа имплементаций этого счастья, и мне поплохело.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру