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

"Уязвимость в uClibc и uClibc-ng, позволяющая подменить данные в кэше DNS"	+/–
Сообщение от opennews (??), 04-Май-22, 14:40
В стандартных Си-библиотеках uClibc и uClibc-ng, применяемых во многих встраиваемых и портативных устройствах, выявлена уязвимость (CVE не присвоен), позволяющая подставить фиктивные данные в кэш DNS, что можно использовать для подмены в кэше IP-адреса произвольного домена и перенаправления обращений к домену на сервер злоумышленника... Подробнее: https://www.opennet.me/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	+2 +/–
Там тоже 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 | Индекс форумов | Темы | Пред. тема | След. тема