Исходное сообщение
"Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." Отправлено timur.davletshin, 06-Май-22 15:43
> Клюк в ядре не нужен. Он вполне может существовать в юзерспейсе - > пакеты приходят всё тому же адресату, который занимается и управлением потоком. А чё он тогда на 30% жручее до CPU? В чём профит тогда? В обновляемости congestion control'а? Так фуфло это. Гуглу одинаково легко обновить что bbr.ko, что код веб-сервера. А сторона клиента значения не имеет от слова вообще (если ты только не загружаешь что-то). Я уже не говорю про конкретные реализации QUIC с их конкретными глюками и затупами. Чего только в 2-5 раз более медленная загрузка на Firefox/QUIC стоит.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Клюк в ядре не нужен. Он вполне может существовать в юзерспейсе - >> пакеты приходят всё тому же адресату, который занимается и управлением потоком. > А чё он тогда на 30% жручее до CPU? В чём профит > тогда? В обновляемости congestion control'а? Так фуфло это. Гуглу одинаково легко > обновить что bbr.ko, что код веб-сервера. А сторона клиента значения не > имеет от слова вообще (если ты только не загружаешь что-то). Я > уже не говорю про конкретные реализации QUIC с их конкретными глюками > и затупами. Чего только в 2-5 раз более медленная загрузка на > Firefox/QUIC стоит.
	Введите код, изображенный на картинке: