forum.opennet.ru

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

Оглавление

Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC , opennews (??), 24-Ноя-23, (0) [смотреть все]

Интересно, они действительно туда полную реализацию Quic затолкали Если да, то , timur.davletshin (ok), 11:25 , 24-Ноя-23, (5) –1 //

если интересно 8212 читай исходники, Аноним (12), 11:43 , 24-Ноя-23, (12) –1 //

Спасибо за дельный совет , timur.davletshin (ok), 12:00 , 24-Ноя-23, (18) +2

Это ужасно, что вместо создания и использования набора абстрактных интерфейсов, , Аноним (13), 11:43 , 24-Ноя-23, (13) //

Гугл в своё время объяснил, что специально решил делать поддержку QUIC в юзерспе, Аноним (19), 12:04 , 24-Ноя-23, (19) //

ЛПП, протокол стабилен Они хотели вынести управление потоком из ядра, чтобы опт, timur.davletshin (ok), 12:13 , 24-Ноя-23, (20) –4

Не решает проблему со стороны клиента Как ты tcp_bbr ko в винде грузить будеш, Аноним (-), 16:56 , 24-Ноя-23, (46) –1

В школу, читай матчасть Поддержка того же BBR на стороне клиента не интересует , timur.davletshin (ok), 17:02 , 24-Ноя-23, (47) +1

Со школой ты тут уже как-то блеснул эрудицией, разведя кучу умствований про quic, Аноним (-), 17:20 , 24-Ноя-23, (52) –1

Что я читаю Мс не может себе в апдейте сетевой стек обновить Считаю отдачу пото, Аноньимъ (ok), 19:41 , 24-Ноя-23, (57)

У них нет нормального деления системы на компоненты, внезапно Поэтому раздать к, Аноним (70), 19:24 , 25-Ноя-23, (70)

Можно не модулярно Деление есть Вы на пустом месте фантазируете черт знает что З, Аноньимъ (ok), 01:26 , 26-Ноя-23, (73) +1
Я же говорю, что ты не понял базового Это не проблема сетевого уровня Это особ, timur.davletshin (ok), 13:36 , 26-Ноя-23, (81)
Я тебе немного разочарую Производительность этого самого Quic ОЧЕНЬ сильно зави, timur.davletshin (ok), 15:26 , 26-Ноя-23, (85)

На первый курс шуруй Не знаю, кому ты там что доказал, но Quic да, нету там k, timur.davletshin (ok), 17:08 , 25-Ноя-23, (68) +1

Да вот знаешь что, эксперт по курсам, ты меня насчет BBR уже дезинформировал вна, Аноним (70), 20:54 , 25-Ноя-23, (71) –1

https blog apnic net 2020 01 10 when-to-use-and-not-use-bbr - я, в отличие от, timur.davletshin (ok), 13:20 , 26-Ноя-23, (77)
Давай поменьше трындежу, а побольше ссылок, где я тебя обманул А то было же уже, timur.davletshin (ok), 13:23 , 26-Ноя-23, (78)
Судя по остроте твоей реакции, тебя выперли ещё с общеобразовательного курса , timur.davletshin (ok), 13:29 , 26-Ноя-23, (79)
Ты в контру переиграл, в контексте разговора должно быть CC , timur.davletshin (ok), 13:31 , 26-Ноя-23, (80)
https bugzilla mozilla org show_bug cgi id 1851908 - кстати, вот для клоунов , timur.davletshin (ok), 10:57 , 02-Дек-23, (91)

А каждый раз собственную реализацию делать, конечно же, намного больше смысла , YetAnotherOnanym (ok), 13:09 , 24-Ноя-23, (25)

Для гугла 8212 может быть QUIC изначально задумывался к средство общения хром, Аноним (19), 13:43 , 24-Ноя-23, (30)

Возможно, ты будешь удивлён, но не у Хромого самая последняя версия протокола , timur.davletshin (ok), 15:31 , 24-Ноя-23, (41) +1
Вообще-то они его как стандарт оформили И теперь оно не хуже и не лучше других , Аноним (-), 17:03 , 24-Ноя-23, (48)

И тем не менее в протоколе есть поле версия Задумайся, зачем она там и как , timur.davletshin (ok), 17:14 , 24-Ноя-23, (50)

Ну спасибо тебе, Капитан Очевидность , Аноним (53), 17:30 , 24-Ноя-23, (53)

Прежде чем говорить спасибо, неплохо было понять, зачем же она всё же использует, timur.davletshin (ok), 15:18 , 26-Ноя-23, (83)

Ну это openssl - одна из самых д рьмовых либ придуманных человечеством Ужасные , Аноним (-), 16:51 , 24-Ноя-23, (45) –2 //

Странно, почему все ещё на mbedTLS не перешли Вопрос риторический , timur.davletshin (ok), 17:16 , 24-Ноя-23, (51) +1

Потому что - ну - вот - удобно И хрен с ней с безопасностью зеленый замочек,, Аноним (53), 17:32 , 24-Ноя-23, (54)

Ответ неправильный Не удобно Не перешли потому, что попробовали на хайпе-то и, _ (??), 07:59 , 25-Ноя-23, (66) +1

Поздравляю с прозрением Какой протокол - такие и либы Однако, качество ряда ли, Аноним (70), 21:36 , 25-Ноя-23, (72) –2

Бедняжка снежинка - как ты вообще можешь жить нп такой несовершенной планете , _ (??), 07:23 , 27-Ноя-23, (86)

https www openssl org roadmap html, Ilya Indigo (ok), 15:54 , 24-Ноя-23, (43)
судя по гитхабу они включили реализацию от cloudflare - quiche и да это раст , Аноним (67), 09:21 , 25-Ноя-23, (67) //

Да, значит это дыра, scriptkiddis (?), 19:31 , 27-Ноя-23, (90)

Скрыто модератором, Zenitur (ok), 11:57 , 24-Ноя-23, (17) //

Скрыто модератором, Аноним (12), 12:20 , 24-Ноя-23, (21)
Скрыто модератором, Аноним (39), 15:11 , 24-Ноя-23, (39) +1

Осталось добавить поддержку QUIC в РФ , name (??), 12:32 , 24-Ноя-23, (22) //

Так, вроде как, VK им на все деньги балуется https m vk com press quic, dullish (ok), 12:39 , 24-Ноя-23, (23) //

Да, а забугорное блочится , name (??), 13:13 , 24-Ноя-23, (27) //

Основной QUIC-провайдер 8212 Cloudflare А он в этой стране вполне локализова, Аноним (19), 13:14 , 24-Ноя-23, (28)

https ntc party t D0 BE D0 B3 D1 80 D0 B0 D0 BD D0 B8 D1 87 D0 B5 D0 BD D0 B8, name (??), 13:17 , 24-Ноя-23, (29)
Quick до cf полностью блокируется , Quick (?), 14:31 , 24-Ноя-23, (35) –1

Значит, это делает сам CF , Аноним (19), 14:37 , 24-Ноя-23, (37) –2

Только что проверил Ничего не блочится Провайдер - МТС, а у него в наличии и, dullish (ok), 13:50 , 24-Ноя-23, (31) +3

В реальности обычно всё не так, как на самом деле , Аноним (19), 14:07 , 24-Ноя-23, (32) +1

Это база , dullish (ok), 14:12 , 24-Ноя-23, (34)

Ростелеком QUIC включая иностранные , ESNI тоже работает ЧЯДНТ , timur.davletshin (ok), 16:46 , 24-Ноя-23, (44) +2

Добавляют уже По сотне метров в день , Аноним (42), 15:43 , 24-Ноя-23, (42)

Э Вроде ж ещё диды так делали, в чём тут повод отдельно акцентировать на таком , YetAnotherOnanym (ok), 13:10 , 24-Ноя-23, (26) +2 //

Это протокол гугла, в принципе не работающий без шифрования, и с обфусцированным, Аноним (33), 14:12 , 24-Ноя-23, (33) //

Вы все перепутали Квик как раз сложнее перехватывать или анализировать для ценз, Quic (?), 14:34 , 24-Ноя-23, (36) –1 //

Нет Ну да, всякие фишки с TLS fingerprinting определённо нужны для моей свободы , Аноним (19), 14:38 , 24-Ноя-23, (38)
Это ковидка так на тебя повлияла Раньше рассказывали про госудрство плохое Так, Аноним (55), 18:19 , 24-Ноя-23, (55) –1

Зачем тогда опнсорс-реализации, если они нигде не используются, кроме как у 2-3х, Аноним (59), 20:55 , 24-Ноя-23, (59)

Из сопряжённых новостей - в haproxy 2 8 4 добавлена поддержка QUIC и для штатной, Tron is Whistling (?), 21:01 , 24-Ноя-23, (61) +1 //

Блин, тихо и незаметно Вы-то как об этом узнали , Аноним (19), 11:47 , 26-Ноя-23, (76)

Откуда взялась эта мода удалять предыдущие реализации из прикладных системных би, Аноним (62), 23:07 , 24-Ноя-23, (62) +1 //

В чем проблема взял затащил себе в код и используй сколько хочешь Опять же мнени, Аноним (65), 04:13 , 25-Ноя-23, (65) //

Они же нарушают совместимость во всей экосистеме Понятно, что на своём компе я м, Аноним (74), 03:54 , 26-Ноя-23, (74)

Кому должна Скажи мнеУ тебя есть письменный договор с разработчиками в котором т, Второй из Кукуева (?), 09:37 , 27-Ноя-23, (88)
От Гуглага Ему важно, чтобы ты не мог перекомпилировать только криптобиблиотеку, Аноним (89), 11:49 , 27-Ноя-23, (89)

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

13. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от Аноним (13), 24-Ноя-23, 11:43

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

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

19. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от Аноним (19), 24-Ноя-23, 12:04

Гугл в своё время объяснил, что специально решил делать поддержку QUIC в юзерспейсе, а не в ядре, чтобы можно было менять протокол практически ежемесячно.
Какой смысл делать абстрактный интерфейс, если протокол by design постоянно меняется?

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

20. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " –4 +/–

Сообщение от timur.davletshin (ok), 24-Ноя-23, 12:13

> если протокол by design постоянно меняется?
ЛПП, протокол стабилен. Они хотели вынести управление потоком из ядра, чтобы оптимизировать трафик со своей стороны. Но мотивация была странная, т.к. управляет потоком отправляющая сторона, а для Google одинаково легко перезагрузить что модуль tcp_bbr.ko, что сервис с реализацией Quic. К тому же BBR оказался далеко не тортом и по дефолту все юзают Cubic в Quic.
Да, давайте не возвращаться к спору о том, что там в исходниках, т.к. вопрос уже выясняли. В библиотеках Cubic.

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

46. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " –1 +/–

Сообщение от Аноним (-), 24-Ноя-23, 16:56

> сторона, а для Google одинаково легко перезагрузить что модуль tcp_bbr.ko,
> что сервис с реализацией Quic.
Не решает проблему со стороны клиента. Как ты "tcp_bbr.ko" в винде грузить будешь? А если от клиента запрос чанка видео еще не приехал - так и ответить на него нельзя.
А тут они просто отгрузят всем клиентам то что посчитают нужным. Послав желающих поумничать на тему что там торт и как надо, типа теба, курить бамбук - и просто сделав так как лучше работает для их клиентов, с полным похреном на концепции, вэйности и прочий булшит. А как ты там в своих приложеньках будешь сношаться с своими лагучими кубиками и разгребать проблемы реализаций - гугла вот уже вообще совершенно не интересует, и если их траф будет давить твой - так это вообще фича, ниипет. Их интересует первоклассный экспериенс их клиентов, особенно ютуба и тому подобного.

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

47. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +1 +/–

Сообщение от timur.davletshin (ok), 24-Ноя-23, 17:02

>> сторона, а для Google одинаково легко перезагрузить что модуль tcp_bbr.ko,
>> что сервис с реализацией Quic.
> Не решает проблему со стороны клиента. Как ты "tcp_bbr.ko" в винде грузить
> будешь? А если от клиента запрос чанка видео еще не приехал
> - так и ответить на него нельзя.
В школу, читай матчасть. Поддержка того же BBR на стороне клиента не интересует Google, т.к. управлением потока занимается тот, кто передаёт данные (это сервер Google). Ты на своей венде успешно получаешь данные с серверов Ютуба, на которых реализован неопубликованный (проприетарный) протокол управления потоком. То, что там свой протокол, выясняется по форме кривой, которую рисуют пакетики, прилетающие от сервера. Можешь поискать на github софт и академическую работу, где проводится перепись протоколов управления потоком, которые используются на самых популярных серверах Интернета.
Весь последующий нетехнический трындёж можно не читать, т.к. ты не вкурил в базовые основы управления потоком в TCP и реализованных поверх UDP пердолях (Quic не один такой, например, ещё есть uTP, а ещё есть IP телефония...).
Первоклассный экспириенс сегодня Аноним доставляет )))

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

52. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " –1 +/–

Сообщение от Аноним (-), 24-Ноя-23, 17:20

> В школу, читай матчасть.
Со школой ты тут уже как-то блеснул эрудицией, разведя кучу умствований про quick - в либе которая вообще внешнюю либу юзала для него, как показало изучение сорца. Отдавая вопрос на откуп ей. Так что твой уровень экспертизы ты уже продемонстрировал, "учитель".
> Поддержка того же BBR на стороне клиента не интересует Google,
> т.к. управлением потока занимается тот, кто передаёт данные.
HTTP это протокол в стиле запрос-ответ. Поэтому не важно какое направление заткнулось, одинаково фатально для user experience. Если юзер не смог послать запрос чанка к серверу ютуба вовремя - кино у него лагать будет. Даже если б сервак и налил, он не знал заранее что именно лить. Авансом лить сильно дофига гугл не любит: юзеры часто сруливают недосмотрев, перематывают, другой мувик пускают и проч - получается много трафа ни на что. TCP таки может в real world условиях уходить в таймауты которые выбесили бы даже диалаперов.
> Ты на своей венде успешно получаешь данные с серверов Ютуба,
> на которых реализован неопубликованный (проприетарный) протокол управления потоком.
Только если клиент запросить чанк смог. А если вместо этого TCP у клиента проскочившего тоннель ушел в туповэйтинг - и что с ним делать? Неизвестно же какой чанк ему надо лить. Ну серваки и подождут запроса. А пребуфер тем временам как раз и закончится. Тут гугол просто подрихтует алго и на серверах и в своем браузере чтобы этого бреда не было - и дело с концом. Ну а вы там можете туповейтить 2 минуты после туннеля если хотите. Гуглу это сильно пофигу, это уже ты и твои юзеры будете разбираться - надо ли им такой экспериенс нетворкинга, особенно в мобильном мире. А вот гугл свои проблемы сможет таки решить. Теперь на обеих сторонах линка, ниипет. Не, с майкрософтом договориться был совсем не вариант. Даже если бы вдруг майкрософт пошел навстречу - а они не могут раздать в апдейте такой компонент системы! Чисто технически. И стало быть - чтобы подрихтовать алго надо ждать новый релиз винды. А то что майкрософт вообще пойдет навстречу - не факт. Гугл их конкурент.

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

57. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от Аноньимъ (ok), 24-Ноя-23, 19:41

> Даже если бы вдруг майкрософт пошел навстречу - а они не могут раздать в апдейте такой компонент системы! Чисто технически
Что я читаю? Мс не может себе в апдейте сетевой стек обновить?
> HTTP это протокол в стиле запрос-ответ. Поэтому не важно какое направление заткнулось
Считаю отдачу потокового видео через хттп преступлением маньяков психопатов против здравого смысла. Но тут уже ничего видимо не поделать.
> А если вместо этого TCP
И причём тут тцп вообще? Вроде о квике речь идёт.

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

70. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от Аноним (70), 25-Ноя-23, 19:24

> Что я читаю? Мс не может себе в апдейте сетевой стек обновить?
У них нет нормального деления системы на компоненты, внезапно! Поэтому раздать какие-то улучшения модулярно - им слабо. Там придется какой-то кус кернеля пропатчить (сделать новыми драйверами-довесками?) + юзермод апи, дабы дать софту возможность выбора и вписать доступные варианты). Они не умеют такое явно оформлять как какие-то компоненты, не предусмотрено такое.
Они с этим аргументом даже жирных партнеров заворачивают влет с крутыми багами, мол, ждите новую винду. А каких-то левых блохастиков + конкурирующую корпу и подавно отправят.
А еще видите ли у того же BBR например вышел косяк, когда оказалось что в определенной ситуации он может скорость обвалить до плинтуса. Теперь представьте что новая винда релизнулась, косяк всплыл, и... ну вам повезет, если вы до фикса вообще доживете. А пока сколько там лет наслаждайтесь лагами, багами и факапами. Как это повлияет на профиты с сервиса гоняющего видео - ну вы поняли. А вот у майкрософта крупных сервисов сервировки видео вроде нет, так что их марже достанется меньше. Ну и куда вот им спешить с фиксами? Можно пару версий винды юзеров и конкурента помариновать. А что им за это будет то?! :)
Это в линухе - прислали патч, в новой версии отрасла +1 опция, софт можно и не менять, только фичой пользоваться не сможет, апи в новых либсах или там где уже донавесили, глобальные дефолты можно вон там затвикать... но там системы так то на пакетики попилены, а апи и конфигурация параметров сделаны так что можно экстеншнов втулить ничего не ломая, это сильно проще было. И, вот, патч с фиксом BBR - а как нашли косяк, так и прислали. А не через пару релизов виндов.
>> HTTP это протокол в стиле запрос-ответ. Поэтому не важно какое направление заткнулось
> Считаю отдачу потокового видео через хттп преступлением маньяков психопатов против здравого
> смысла. Но тут уже ничего видимо не поделать.
Ну как бы оно уже выросло в то что выросло - среду для приложений и проч. А сам по себе HTTP как протокол файлтрансфера мало не хуже остальных.
Да и...
1) Если забыть про тупняки TCP, у гугли плеер довольно неглупый и адаптивный, работает лучше много чего еще даже так.
2) Если вам хотелось lossy - с этим обгадились даже эфирные броадкастеры, достаточно посмотреть что DVB вообще вытворяет при выпадении данных. Жуткие артефакты, клин картинки на 10 секунд и более, заикания звука или оскорбляющие слух чирикания, все прелести. В онлайне все так же - только еще хуже. Ну вот не заточена цифра на это.
3) Существующее сетевое оборудование имеет тенденцию гасить непонятные левые сетевые протоколы, нечто застревающее на первом фаере, нате и прокси никому не надо, сорянчики. Это мучение и для юзерей и для хостингов (сапортов).
Поэтому HTTP используют потому что во первых не очень ухучшает тот позор с одной стороны, и снимает ряд траблов с другой. Ютуб проиграется даже в корпоративном интранете. Попробуйте так с вашим самопалом так. Вот ща корп админы будут вам енаблить ваш левак явно у себя. Аж два раза. Ну планктон и не будет юзать ваш недо-сервис, соответственно.
>> А если вместо этого TCP
> И причём тут тцп вообще? Вроде о квике речь идёт.
Ну а вот квик появился как аналог тцп где - вот - гугол может адекватно контролировать что творится на обеих сторонах линка. Без лизания ботинок майкрософту и попыток обучить старого пса новым трюкам, что не очень хорошо работало, мягко говоря. И теперь вместо слушания всяких теоретиков они просто сделают себе ЗБС. А заодно в принципе и еще кому-то может ЗБС стать.
И да, у них тоже будут частисно вон те проблемы, но UDP все же не особо экзотичная штука, а generic использование этой штуки и для просто передачи страниц в интернете и проч быстро отшибет вон те траблы с фаерами, натами, прокси и проч. Есть довольно большая разница, прожать через корп админов выделенный протокол для видео - и generic HTTP/NextGen. Первое - вы умрете с этой мечтой. Второе - заимплементят, никуда не денутся. В отличие от вас гугл это понимает. Поэтому оно и взлетит. А ну да, когда теоретиков волновали вопросы практического деплоя и какие при этом траблы?! Гугл - вот - в отличие от них догадывается о некоторых моментах. Поэтому и сможет, в отличие от тех жалких потуг академов не от мира сего.

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

73. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +1 +/–

Сообщение от Аноньимъ (ok), 26-Ноя-23, 01:26

> У них нет нормального деления системы на компоненты, внезапно! Поэтому раздать какие-то улучшения модулярно - им слабо.
Можно не модулярно.
Деление есть.
Вы на пустом месте фантазируете черт знает что.
> Они с этим аргументом даже жирных партнеров заворачивают влет с крутыми багами, мол, ждите новую винду.
Заворачивать они могут и просто с fuck you little maggots, но в английском не принято говорить прямо, поэтому говорят вежливо витиевато и запутанно.

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

81. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от timur.davletshin (ok), 26-Ноя-23, 13:36

> ... клин картинки на 10 секунд и более...
Я же говорю, что ты не понял базового. Это не проблема сетевого уровня. Это особенность кодирования в MPEG-подобных потоковых форматах. Почитай про типы кадров и для чего они используются. Есть там такая вещь, которая позволяет настраивать этот твой "клин картинки на 10 секунд". Это твоё ДЗ. Завтра проверю.

Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

85. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от timur.davletshin (ok), 26-Ноя-23, 15:26

> Ну а вот квик появился как аналог тцп где - вот - гугол может адекватно контролировать что творится на обеих сторонах линка.
Я тебе немного разочарую. Производительность этого самого Quic ОЧЕНЬ сильно зависит от настройки буферов операционной системы. Предлагаю погуглить всё ещё нерешённую драму с оптимизацией размеров буферов в FF. В Chrome производительность лучше, но у него с задержкой проблемы... Кто бы мог подумать, что такое может быть. Года через 2 кто-то померяет jitter и скажет "это же какой-то швах" )))

Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

68. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +1 +/–

Сообщение от timur.davletshin (ok), 25-Ноя-23, 17:08

На первый курс шуруй. Не знаю, кому ты там что доказал, но Quic (да, нету там "k") не юзает BBR в дефолте в том же Хроме.

Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

71. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " –1 +/–

Сообщение от Аноним (70), 25-Ноя-23, 20:54

> На первый курс шуруй. Не знаю, кому ты там что доказал, но
> Quic (да, нету там "k") не юзает BBR в дефолте в том же Хроме.
Да вот знаешь что, эксперт по курсам, ты меня насчет BBR уже дезинформировал внаглую по части майнлайна линуха. Точнее, попытался. Но это было детектировано и нейтрализовано. Потому что я таки вспомнил что видел какие-то патчи туда, чинящие специфичные взбрыки этой штуки. А то что софт могут оказывается девелопать итеративно, патча взбрыки "in situ" - великий эксперт, видимо, не в курсе был, поэтому на голубом глазу рассказывал мне про версии BBR в линуксе с уверенной мордой лица.
А чисто по человечески мне вообще интересно - где б в твоем совдепе CS еще нормальный был бы, да еще без отрыва от реальности, чтоб потом с этим знанием - пойти и сделать, и чтоб это еще и работало. С этим и в топовых западных то вузах - доучиваться придется, и много, in site. А в рфии... да знаешь, потуги делать "затосвои" хостинги и как это работает говорят о уровне экспертизы лучше любых дипломов. Когда это у тебя будет работать не хуже гугли - твой пиндеж про курсы и экспертизу будет чего-то стоить. А до тех пор - послушаем лучше гугл и его разработчиков. В том числе и на тему этих алгоритмов.

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

77. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от timur.davletshin (ok), 26-Ноя-23, 13:20

https://blog.apnic.net/2020/01/10/when-to-use-and-not-use-bbr/ - я, в отличие от тебя, могу провести тестирование. Это об области применимости твоего BBR. И это без учёта конкуренции с иными алгоритмами. А это то место, где BBR плох.

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

78. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от timur.davletshin (ok), 26-Ноя-23, 13:23

Давай поменьше трындежу, а побольше ссылок, где я тебя обманул. А то было же уже (я поэтому и сделал оговорку в начале ветки) на тему изучения исходников.
Ты не можешь понять работы BBR, т.к. ты не понимаешь базовых принципов. Чуть выше ты писал, что для Google очень актуально для внедрения BBR делать на стороне клиента. А на венде, мол, нельзя tcp_bbr.ko подгрузить. Гвидон, не надо распаляться там, где ты "плаваешь".

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

79. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от timur.davletshin (ok), 26-Ноя-23, 13:29

> совдеп, дипломы, РФия, го...но.
Судя по остроте твоей реакции, тебя выперли ещё с общеобразовательного курса )))

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

80. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от timur.davletshin (ok), 26-Ноя-23, 13:31

> ... CS...
Ты в контру переиграл, в контексте разговора должно быть CC ))

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

91. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от timur.davletshin (ok), 02-Дек-23, 10:57

https://bugzilla.mozilla.org/show_bug.cgi?id=1851908 - кстати, вот для клоунов: available CC algorithms include Cubic and New Reno. А где же BBR в этом благословенном QUIC?

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

25. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от YetAnotherOnanym (ok), 24-Ноя-23, 13:09

А каждый раз собственную реализацию делать, конечно же, намного больше смысла.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

30. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от Аноним (19), 24-Ноя-23, 13:43

Для гугла — может быть.
QUIC изначально задумывался к средство общения хрома с серваками гугла. А это означает, что его жизненный цикл зависит от разработки хрома и гуглосерверов.

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

41. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +1 +/–

Сообщение от timur.davletshin (ok), 24-Ноя-23, 15:31

Возможно, ты будешь удивлён, но не у Хромого самая последняя версия протокола.

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

48. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от Аноним (-), 24-Ноя-23, 17:03

> QUIC изначально задумывался к средство общения хрома с серваками гугла.
> А это означает, что его жизненный цикл зависит от разработки хрома и гуглосерверов.
Вообще-то они его как стандарт оформили. И теперь оно не хуже и не лучше других стандартов интернета. И есть эн совершенно посторонних реализаций. Включая и +1 вот эту вот.

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

50. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от timur.davletshin (ok), 24-Ноя-23, 17:14

> Вообще-то они его как стандарт оформили. И теперь оно не хуже и
> не лучше других стандартов интернета. И есть эн совершенно посторонних реализаций.
> Включая и +1 вот эту вот.
И тем не менее в протоколе есть поле "версия"... Задумайся, зачем она там и как используется.

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

53. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от Аноним (53), 24-Ноя-23, 17:30

> И тем не менее в протоколе есть поле "версия"... Задумайся, зачем она
> там и как используется.
Ну спасибо тебе, Капитан Очевидность!

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

83. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от timur.davletshin (ok), 26-Ноя-23, 15:18

> Ну спасибо тебе, Капитан Очевидность!
Прежде чем говорить спасибо, неплохо было понять, зачем же она всё же используется в протоколе... Вот загадка! Правда?

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

45. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " –2 +/–

Сообщение от Аноним (-), 24-Ноя-23, 16:51

> Это ужасно, что вместо создания и использования набора абстрактных интерфейсов,
> позволяющих задействовать любые независимые реализации QUIC, в библиотеки включают
> "поддержку QUIC" путём либо написания своей реализации, либо вендоринга чужой,
> либо гвоздями прибивания к чужой.
Ну это openssl - одна из самых д@рьмовых либ придуманных человечеством. Ужасные апи, куча CVE, более 9000 алгоритмов на выбор и 100500 рукояток, так что удачи вообще получить именно секурный набор параметров если вы не криптограф с 20-летним опытом.
Замечательная либа. Показывающая как НЕ НАДО было делать криптографию. Да, удобно. Да, весь фарш. И в результате - почти ни 1 программа не использует ЭТО секурно. И CVE каждый месяц. Все как мы любим, особенно в криптолибах. Вполне возможно что сабж - мировой рекордсмен по числу CVE в либе.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

51. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +1 +/–

Сообщение от timur.davletshin (ok), 24-Ноя-23, 17:16

> Ну это openssl - одна из самых д@рьмовых либ придуманных человечеством.
Странно, почему все ещё на mbedTLS не перешли? Вопрос риторический.

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

54. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от Аноним (53), 24-Ноя-23, 17:32

>> Ну это openssl - одна из самых д@рьмовых либ придуманных человечеством.
> Странно, почему все ещё на mbedTLS не перешли? Вопрос риторический.
Потому что - ну - вот - удобно. И хрен с ней с безопасностью... зеленый замочек, или что там, показали - а там хоть не рассветай. Промямлили что-то про безопсность, а проблемы юзерей и майнтайнеров - это ж не проблемы у кодеров и манагеров, в самом то деле?!

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

66. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +1 +/–

Сообщение от _ (??), 25-Ноя-23, 07:59

>>> Ну это openssl - одна из самых д@рьмовых либ придуманных человечеством.
>> Странно, почему все ещё на mbedTLS не перешли? Вопрос риторический.
>Потому что - ну - вот - удобно.
Ответ неправильный!
Не удобно.
Не перешли потому, что попробовали (на хайпе-то!) и вдруг оказалось что __все__ новые mean and lean либы-"убийцы" OpenSSL - на деле такое же (если не большее!) дверьмо да и ещё и обкоцанное по самые помидоры и несовместимое ... :(
В общем - всё так же как с линуксом ... или водкой :) Ибо! Хуже водки - лучше нет! :)

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

72. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " –2 +/–

Сообщение от Аноним (70), 25-Ноя-23, 21:36

> что __все__ новые mean and lean либы-"убийцы" OpenSSL - на деле такое же
Поздравляю с прозрением. Какой протокол - такие и либы. Однако, качество ряда либ таки - получше openssl как ни крути.
> (если не большее!) дверьмо да и ещё и обкоцанное по самые помидоры и несовместимое ... :(
А зачем делать очередную горбатую либу с кучей легаси под совершенно уб-дское апи? Пойнт этой активности будет вообще какой? Сделать openssl еще раз? Он один уже есть. Второго не надо.
> В общем - всё так же как с линуксом ... или водкой :)
> Ибо! Хуже водки - лучше нет! :)
Мне с бухарями не по пути, мой путь это путь разума. И уж тем более слушать на тему апи и протоколов лучше все же тех кто предпочитает свой мозг в работающем состоянии.

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

86. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC " +/–

Сообщение от _ (??), 27-Ноя-23, 07:23

>Какой протокол - такие и либы.
Бедняжка снежинка - как ты вообще можешь жить нп такой несовершенной планете ? :-)
>Второго не надо.
Ну вот это внезапно и дошло до всех. Какой смайл ставить - даже и не знаю.
>Мне с бухарями не по пути, мой путь это путь разума.
Понятно но шЫрятся оставлю разумным снежинкам. :-р :-D

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	13. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от Аноним (13), 24-Ноя-23, 11:43
	Это ужасно, что вместо создания и использования набора абстрактных интерфейсов, позволяющих задействовать любые независимые реализации QUIC, в библиотеки включают "поддержку QUIC" путём либо написания своей реализации, либо вендоринга чужой, либо гвоздями прибивания к чужой.
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	19. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от Аноним (19), 24-Ноя-23, 12:04
	Гугл в своё время объяснил, что специально решил делать поддержку QUIC в юзерспейсе, а не в ядре, чтобы можно было менять протокол практически ежемесячно. Какой смысл делать абстрактный интерфейс, если протокол by design постоянно меняется?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	–4 +/–
	Сообщение от timur.davletshin (ok), 24-Ноя-23, 12:13
	> если протокол by design постоянно меняется? ЛПП, протокол стабилен. Они хотели вынести управление потоком из ядра, чтобы оптимизировать трафик со своей стороны. Но мотивация была странная, т.к. управляет потоком отправляющая сторона, а для Google одинаково легко перезагрузить что модуль tcp_bbr.ko, что сервис с реализацией Quic. К тому же BBR оказался далеко не тортом и по дефолту все юзают Cubic в Quic. Да, давайте не возвращаться к спору о том, что там в исходниках, т.к. вопрос уже выясняли. В библиотеках Cubic.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	–1 +/–
	Сообщение от Аноним (-), 24-Ноя-23, 16:56
	> сторона, а для Google одинаково легко перезагрузить что модуль tcp_bbr.ko, > что сервис с реализацией Quic. Не решает проблему со стороны клиента. Как ты "tcp_bbr.ko" в винде грузить будешь? А если от клиента запрос чанка видео еще не приехал - так и ответить на него нельзя. А тут они просто отгрузят всем клиентам то что посчитают нужным. Послав желающих поумничать на тему что там торт и как надо, типа теба, курить бамбук - и просто сделав так как лучше работает для их клиентов, с полным похреном на концепции, вэйности и прочий булшит. А как ты там в своих приложеньках будешь сношаться с своими лагучими кубиками и разгребать проблемы реализаций - гугла вот уже вообще совершенно не интересует, и если их траф будет давить твой - так это вообще фича, ниипет. Их интересует первоклассный экспериенс их клиентов, особенно ютуба и тому подобного.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+1 +/–
	Сообщение от timur.davletshin (ok), 24-Ноя-23, 17:02
	>> сторона, а для Google одинаково легко перезагрузить что модуль tcp_bbr.ko, >> что сервис с реализацией Quic. > Не решает проблему со стороны клиента. Как ты "tcp_bbr.ko" в винде грузить > будешь? А если от клиента запрос чанка видео еще не приехал > - так и ответить на него нельзя. В школу, читай матчасть. Поддержка того же BBR на стороне клиента не интересует Google, т.к. управлением потока занимается тот, кто передаёт данные (это сервер Google). Ты на своей венде успешно получаешь данные с серверов Ютуба, на которых реализован неопубликованный (проприетарный) протокол управления потоком. То, что там свой протокол, выясняется по форме кривой, которую рисуют пакетики, прилетающие от сервера. Можешь поискать на github софт и академическую работу, где проводится перепись протоколов управления потоком, которые используются на самых популярных серверах Интернета. Весь последующий нетехнический трындёж можно не читать, т.к. ты не вкурил в базовые основы управления потоком в TCP и реализованных поверх UDP пердолях (Quic не один такой, например, ещё есть uTP, а ещё есть IP телефония...). Первоклассный экспириенс сегодня Аноним доставляет )))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	52. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	–1 +/–
	Сообщение от Аноним (-), 24-Ноя-23, 17:20
	> В школу, читай матчасть. Со школой ты тут уже как-то блеснул эрудицией, разведя кучу умствований про quick - в либе которая вообще внешнюю либу юзала для него, как показало изучение сорца. Отдавая вопрос на откуп ей. Так что твой уровень экспертизы ты уже продемонстрировал, "учитель". > Поддержка того же BBR на стороне клиента не интересует Google, > т.к. управлением потока занимается тот, кто передаёт данные. HTTP это протокол в стиле запрос-ответ. Поэтому не важно какое направление заткнулось, одинаково фатально для user experience. Если юзер не смог послать запрос чанка к серверу ютуба вовремя - кино у него лагать будет. Даже если б сервак и налил, он не знал заранее что именно лить. Авансом лить сильно дофига гугл не любит: юзеры часто сруливают недосмотрев, перематывают, другой мувик пускают и проч - получается много трафа ни на что. TCP таки может в real world условиях уходить в таймауты которые выбесили бы даже диалаперов. > Ты на своей венде успешно получаешь данные с серверов Ютуба, > на которых реализован неопубликованный (проприетарный) протокол управления потоком. Только если клиент запросить чанк смог. А если вместо этого TCP у клиента проскочившего тоннель ушел в туповэйтинг - и что с ним делать? Неизвестно же какой чанк ему надо лить. Ну серваки и подождут запроса. А пребуфер тем временам как раз и закончится. Тут гугол просто подрихтует алго и на серверах и в своем браузере чтобы этого бреда не было - и дело с концом. Ну а вы там можете туповейтить 2 минуты после туннеля если хотите. Гуглу это сильно пофигу, это уже ты и твои юзеры будете разбираться - надо ли им такой экспериенс нетворкинга, особенно в мобильном мире. А вот гугл свои проблемы сможет таки решить. Теперь на обеих сторонах линка, ниипет. Не, с майкрософтом договориться был совсем не вариант. Даже если бы вдруг майкрософт пошел навстречу - а они не могут раздать в апдейте такой компонент системы! Чисто технически. И стало быть - чтобы подрихтовать алго надо ждать новый релиз винды. А то что майкрософт вообще пойдет навстречу - не факт. Гугл их конкурент.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от Аноньимъ (ok), 24-Ноя-23, 19:41
	> Даже если бы вдруг майкрософт пошел навстречу - а они не могут раздать в апдейте такой компонент системы! Чисто технически Что я читаю? Мс не может себе в апдейте сетевой стек обновить? > HTTP это протокол в стиле запрос-ответ. Поэтому не важно какое направление заткнулось Считаю отдачу потокового видео через хттп преступлением маньяков психопатов против здравого смысла. Но тут уже ничего видимо не поделать. > А если вместо этого TCP И причём тут тцп вообще? Вроде о квике речь идёт.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	70. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от Аноним (70), 25-Ноя-23, 19:24
	> Что я читаю? Мс не может себе в апдейте сетевой стек обновить? У них нет нормального деления системы на компоненты, внезапно! Поэтому раздать какие-то улучшения модулярно - им слабо. Там придется какой-то кус кернеля пропатчить (сделать новыми драйверами-довесками?) + юзермод апи, дабы дать софту возможность выбора и вписать доступные варианты). Они не умеют такое явно оформлять как какие-то компоненты, не предусмотрено такое. Они с этим аргументом даже жирных партнеров заворачивают влет с крутыми багами, мол, ждите новую винду. А каких-то левых блохастиков + конкурирующую корпу и подавно отправят. А еще видите ли у того же BBR например вышел косяк, когда оказалось что в определенной ситуации он может скорость обвалить до плинтуса. Теперь представьте что новая винда релизнулась, косяк всплыл, и... ну вам повезет, если вы до фикса вообще доживете. А пока сколько там лет наслаждайтесь лагами, багами и факапами. Как это повлияет на профиты с сервиса гоняющего видео - ну вы поняли. А вот у майкрософта крупных сервисов сервировки видео вроде нет, так что их марже достанется меньше. Ну и куда вот им спешить с фиксами? Можно пару версий винды юзеров и конкурента помариновать. А что им за это будет то?! :) Это в линухе - прислали патч, в новой версии отрасла +1 опция, софт можно и не менять, только фичой пользоваться не сможет, апи в новых либсах или там где уже донавесили, глобальные дефолты можно вон там затвикать... но там системы так то на пакетики попилены, а апи и конфигурация параметров сделаны так что можно экстеншнов втулить ничего не ломая, это сильно проще было. И, вот, патч с фиксом BBR - а как нашли косяк, так и прислали. А не через пару релизов виндов. >> HTTP это протокол в стиле запрос-ответ. Поэтому не важно какое направление заткнулось > Считаю отдачу потокового видео через хттп преступлением маньяков психопатов против здравого > смысла. Но тут уже ничего видимо не поделать. Ну как бы оно уже выросло в то что выросло - среду для приложений и проч. А сам по себе HTTP как протокол файлтрансфера мало не хуже остальных. Да и... 1) Если забыть про тупняки TCP, у гугли плеер довольно неглупый и адаптивный, работает лучше много чего еще даже так. 2) Если вам хотелось lossy - с этим обгадились даже эфирные броадкастеры, достаточно посмотреть что DVB вообще вытворяет при выпадении данных. Жуткие артефакты, клин картинки на 10 секунд и более, заикания звука или оскорбляющие слух чирикания, все прелести. В онлайне все так же - только еще хуже. Ну вот не заточена цифра на это. 3) Существующее сетевое оборудование имеет тенденцию гасить непонятные левые сетевые протоколы, нечто застревающее на первом фаере, нате и прокси никому не надо, сорянчики. Это мучение и для юзерей и для хостингов (сапортов). Поэтому HTTP используют потому что во первых не очень ухучшает тот позор с одной стороны, и снимает ряд траблов с другой. Ютуб проиграется даже в корпоративном интранете. Попробуйте так с вашим самопалом так. Вот ща корп админы будут вам енаблить ваш левак явно у себя. Аж два раза. Ну планктон и не будет юзать ваш недо-сервис, соответственно. >> А если вместо этого TCP > И причём тут тцп вообще? Вроде о квике речь идёт. Ну а вот квик появился как аналог тцп где - вот - гугол может адекватно контролировать что творится на обеих сторонах линка. Без лизания ботинок майкрософту и попыток обучить старого пса новым трюкам, что не очень хорошо работало, мягко говоря. И теперь вместо слушания всяких теоретиков они просто сделают себе ЗБС. А заодно в принципе и еще кому-то может ЗБС стать. И да, у них тоже будут частисно вон те проблемы, но UDP все же не особо экзотичная штука, а generic использование этой штуки и для просто передачи страниц в интернете и проч быстро отшибет вон те траблы с фаерами, натами, прокси и проч. Есть довольно большая разница, прожать через корп админов выделенный протокол для видео - и generic HTTP/NextGen. Первое - вы умрете с этой мечтой. Второе - заимплементят, никуда не денутся. В отличие от вас гугл это понимает. Поэтому оно и взлетит. А ну да, когда теоретиков волновали вопросы практического деплоя и какие при этом траблы?! Гугл - вот - в отличие от них догадывается о некоторых моментах. Поэтому и сможет, в отличие от тех жалких потуг академов не от мира сего.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	73. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+1 +/–
	Сообщение от Аноньимъ (ok), 26-Ноя-23, 01:26
	> У них нет нормального деления системы на компоненты, внезапно! Поэтому раздать какие-то улучшения модулярно - им слабо. Можно не модулярно. Деление есть. Вы на пустом месте фантазируете черт знает что. > Они с этим аргументом даже жирных партнеров заворачивают влет с крутыми багами, мол, ждите новую винду. Заворачивать они могут и просто с fuck you little maggots, но в английском не принято говорить прямо, поэтому говорят вежливо витиевато и запутанно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	81. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от timur.davletshin (ok), 26-Ноя-23, 13:36
	> ... клин картинки на 10 секунд и более... Я же говорю, что ты не понял базового. Это не проблема сетевого уровня. Это особенность кодирования в MPEG-подобных потоковых форматах. Почитай про типы кадров и для чего они используются. Есть там такая вещь, которая позволяет настраивать этот твой "клин картинки на 10 секунд". Это твоё ДЗ. Завтра проверю.
	Ответить \| Правка \| К родителю #70 \| Наверх \| Cообщить модератору


	85. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от timur.davletshin (ok), 26-Ноя-23, 15:26
	> Ну а вот квик появился как аналог тцп где - вот - гугол может адекватно контролировать что творится на обеих сторонах линка. Я тебе немного разочарую. Производительность этого самого Quic ОЧЕНЬ сильно зависит от настройки буферов операционной системы. Предлагаю погуглить всё ещё нерешённую драму с оптимизацией размеров буферов в FF. В Chrome производительность лучше, но у него с задержкой проблемы... Кто бы мог подумать, что такое может быть. Года через 2 кто-то померяет jitter и скажет "это же какой-то швах" )))
	Ответить \| Правка \| К родителю #70 \| Наверх \| Cообщить модератору


	68. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+1 +/–
	Сообщение от timur.davletshin (ok), 25-Ноя-23, 17:08
	На первый курс шуруй. Не знаю, кому ты там что доказал, но Quic (да, нету там "k") не юзает BBR в дефолте в том же Хроме.
	Ответить \| Правка \| К родителю #52 \| Наверх \| Cообщить модератору


	71. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	–1 +/–
	Сообщение от Аноним (70), 25-Ноя-23, 20:54
	> На первый курс шуруй. Не знаю, кому ты там что доказал, но > Quic (да, нету там "k") не юзает BBR в дефолте в том же Хроме. Да вот знаешь что, эксперт по курсам, ты меня насчет BBR уже дезинформировал внаглую по части майнлайна линуха. Точнее, попытался. Но это было детектировано и нейтрализовано. Потому что я таки вспомнил что видел какие-то патчи туда, чинящие специфичные взбрыки этой штуки. А то что софт могут оказывается девелопать итеративно, патча взбрыки "in situ" - великий эксперт, видимо, не в курсе был, поэтому на голубом глазу рассказывал мне про версии BBR в линуксе с уверенной мордой лица. А чисто по человечески мне вообще интересно - где б в твоем совдепе CS еще нормальный был бы, да еще без отрыва от реальности, чтоб потом с этим знанием - пойти и сделать, и чтоб это еще и работало. С этим и в топовых западных то вузах - доучиваться придется, и много, in site. А в рфии... да знаешь, потуги делать "затосвои" хостинги и как это работает говорят о уровне экспертизы лучше любых дипломов. Когда это у тебя будет работать не хуже гугли - твой пиндеж про курсы и экспертизу будет чего-то стоить. А до тех пор - послушаем лучше гугл и его разработчиков. В том числе и на тему этих алгоритмов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	77. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от timur.davletshin (ok), 26-Ноя-23, 13:20
	https://blog.apnic.net/2020/01/10/when-to-use-and-not-use-bbr/ - я, в отличие от тебя, могу провести тестирование. Это об области применимости твоего BBR. И это без учёта конкуренции с иными алгоритмами. А это то место, где BBR плох.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от timur.davletshin (ok), 26-Ноя-23, 13:23
	Давай поменьше трындежу, а побольше ссылок, где я тебя обманул. А то было же уже (я поэтому и сделал оговорку в начале ветки) на тему изучения исходников. Ты не можешь понять работы BBR, т.к. ты не понимаешь базовых принципов. Чуть выше ты писал, что для Google очень актуально для внедрения BBR делать на стороне клиента. А на венде, мол, нельзя tcp_bbr.ko подгрузить. Гвидон, не надо распаляться там, где ты "плаваешь".
	Ответить \| Правка \| К родителю #71 \| Наверх \| Cообщить модератору


	79. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от timur.davletshin (ok), 26-Ноя-23, 13:29
	> совдеп, дипломы, РФия, го...но. Судя по остроте твоей реакции, тебя выперли ещё с общеобразовательного курса )))
	Ответить \| Правка \| К родителю #71 \| Наверх \| Cообщить модератору


	80. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от timur.davletshin (ok), 26-Ноя-23, 13:31
	> ... CS... Ты в контру переиграл, в контексте разговора должно быть CC ))
	Ответить \| Правка \| К родителю #71 \| Наверх \| Cообщить модератору


	91. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от timur.davletshin (ok), 02-Дек-23, 10:57
	https://bugzilla.mozilla.org/show_bug.cgi?id=1851908 - кстати, вот для клоунов: available CC algorithms include Cubic and New Reno. А где же BBR в этом благословенном QUIC?
	Ответить \| Правка \| К родителю #71 \| Наверх \| Cообщить модератору


	25. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от YetAnotherOnanym (ok), 24-Ноя-23, 13:09
	А каждый раз собственную реализацию делать, конечно же, намного больше смысла.
	Ответить \| Правка \| К родителю #19 \| Наверх \| Cообщить модератору


	30. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от Аноним (19), 24-Ноя-23, 13:43
	Для гугла — может быть. QUIC изначально задумывался к средство общения хрома с серваками гугла. А это означает, что его жизненный цикл зависит от разработки хрома и гуглосерверов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+1 +/–
	Сообщение от timur.davletshin (ok), 24-Ноя-23, 15:31
	Возможно, ты будешь удивлён, но не у Хромого самая последняя версия протокола.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 17:03
	> QUIC изначально задумывался к средство общения хрома с серваками гугла. > А это означает, что его жизненный цикл зависит от разработки хрома и гуглосерверов. Вообще-то они его как стандарт оформили. И теперь оно не хуже и не лучше других стандартов интернета. И есть эн совершенно посторонних реализаций. Включая и +1 вот эту вот.
	Ответить \| Правка \| К родителю #30 \| Наверх \| Cообщить модератору


	50. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от timur.davletshin (ok), 24-Ноя-23, 17:14
	> Вообще-то они его как стандарт оформили. И теперь оно не хуже и > не лучше других стандартов интернета. И есть эн совершенно посторонних реализаций. > Включая и +1 вот эту вот. И тем не менее в протоколе есть поле "версия"... Задумайся, зачем она там и как используется.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	53. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от Аноним (53), 24-Ноя-23, 17:30
	> И тем не менее в протоколе есть поле "версия"... Задумайся, зачем она > там и как используется. Ну спасибо тебе, Капитан Очевидность!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	83. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от timur.davletshin (ok), 26-Ноя-23, 15:18
	> Ну спасибо тебе, Капитан Очевидность! Прежде чем говорить спасибо, неплохо было понять, зачем же она всё же используется в протоколе... Вот загадка! Правда?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	–2 +/–
	Сообщение от Аноним (-), 24-Ноя-23, 16:51
	> Это ужасно, что вместо создания и использования набора абстрактных интерфейсов, > позволяющих задействовать любые независимые реализации QUIC, в библиотеки включают > "поддержку QUIC" путём либо написания своей реализации, либо вендоринга чужой, > либо гвоздями прибивания к чужой. Ну это openssl - одна из самых д@рьмовых либ придуманных человечеством. Ужасные апи, куча CVE, более 9000 алгоритмов на выбор и 100500 рукояток, так что удачи вообще получить именно секурный набор параметров если вы не криптограф с 20-летним опытом. Замечательная либа. Показывающая как НЕ НАДО было делать криптографию. Да, удобно. Да, весь фарш. И в результате - почти ни 1 программа не использует ЭТО секурно. И CVE каждый месяц. Все как мы любим, особенно в криптолибах. Вполне возможно что сабж - мировой рекордсмен по числу CVE в либе.
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	51. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+1 +/–
	Сообщение от timur.davletshin (ok), 24-Ноя-23, 17:16
	> Ну это openssl - одна из самых д@рьмовых либ придуманных человечеством. Странно, почему все ещё на mbedTLS не перешли? Вопрос риторический.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	54. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+/–
	Сообщение от Аноним (53), 24-Ноя-23, 17:32
	>> Ну это openssl - одна из самых д@рьмовых либ придуманных человечеством. > Странно, почему все ещё на mbedTLS не перешли? Вопрос риторический. Потому что - ну - вот - удобно. И хрен с ней с безопасностью... зеленый замочек, или что там, показали - а там хоть не рассветай. Промямлили что-то про безопсность, а проблемы юзерей и майнтайнеров - это ж не проблемы у кодеров и манагеров, в самом то деле?!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	+1 +/–
	Сообщение от _ (??), 25-Ноя-23, 07:59
	>>> Ну это openssl - одна из самых д@рьмовых либ придуманных человечеством. >> Странно, почему все ещё на mbedTLS не перешли? Вопрос риторический. >Потому что - ну - вот - удобно. Ответ неправильный! Не удобно. Не перешли потому, что попробовали (на хайпе-то!) и вдруг оказалось что __все__ новые mean and lean либы-"убийцы" OpenSSL - на деле такое же (если не большее!) дверьмо да и ещё и обкоцанное по самые помидоры и несовместимое ... :( В общем - всё так же как с линуксом ... или водкой :) Ибо! Хуже водки - лучше нет! :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	72. "Выпуск OpenSSL 3.2.0 с клиентской поддержкой протокола QUIC "	–2 +/–
	Сообщение от Аноним (70), 25-Ноя-23, 21:36
	> что __все__ новые mean and lean либы-"убийцы" OpenSSL - на деле такое же Поздравляю с прозрением. Какой протокол - такие и либы. Однако, качество ряда либ таки - получше openssl как ни крути. > (если не большее!) дверьмо да и ещё и обкоцанное по самые помидоры и несовместимое ... :( А зачем делать очередную горбатую либу с кучей легаси под совершенно уб-дское апи? Пойнт этой активности будет вообще какой? Сделать openssl еще раз? Он один уже есть. Второго не надо. > В общем - всё так же как с линуксом ... или водкой :) > Ибо! Хуже водки - лучше нет! :) Мне с бухарями не по пути, мой путь это путь разума. И уж тем более слушать на тему апи и протоколов лучше все же тех кто предпочитает свой мозг в работающем состоянии.
	Ответить \| Правка \| Наверх \| Cообщить модератору