The OpenNET Project / Index page

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



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

Оглавление

В ночных и бета сборках Firefox включена по умолчанию поддержка HTTP/3 , opennews (ok), 21-Мрт-21, (0) [смотреть все]

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


9. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +9 +/
Сообщение от timur.davletshin (ok), 21-Мрт-21, 09:00 
> Странный вы народ: в срачах про микроядро vs монолит вы вовсю кричите
> что надо все в юзерспейс. А сейчас (и ещё помню новость
> про FUSE) уже ярые противники этого подхода.

Для начала, я никогда не кричал такого. Есть просто имеющийся сетевой стек и в нём управление потоком для TCP в ядре, а UDP по дизайну не гарантирует доставку, поэтому там управление потоком и его целостностью должно быть выше. Дело даже не в том, что ядерные алгоритмы оттестированы и не страдают склонностью к вендорлоку, а в том, что процесс, управляющий потоком, работать будет с пользовательским приоритетом, что недопустимо для realtime задачи управления потоком. В загруженных условиях пользовательская реализация будет страдать от той же проблемы, на которую наступил когда-то pulseaudio. Сколько тут было орущих про "икание" звука после перехода на pulseaudio (сама идея вообще хороша)? Так вот, это банально из-за невозможности управления realtime задачей из пользовательского пространства в условиях высокой загрузки.

Скрытый же мотив гугла в том, чтобы вынести по максимуму всё в зависящий только от cебя блоб. Даже то же обоснование о том, что мультиплексированный в HTTP/2 поток дропает всё в случае потери пакета, и повышенная пропускная способность UDP на беспроводных, нивелируется тем, что тот же оверхед, необходимый для контроля целостности потока, реализуется уже внутри самого QUIC. И он не меньше, а в реальности даже больше, чем у TCP vs UDP.

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

25. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  –2 +/
Сообщение от Нанобот (ok), 21-Мрт-21, 10:08 
> процесс, управляющий потоком, работать будет с пользовательским приоритетом, что недопустимо для realtime задачи управления потоком.

Если взлетит, потом всегда можно будет добавить добавить реализацию в ядро.

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

28. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от timur.davletshin (ok), 21-Мрт-21, 10:19 
> Если взлетит, потом всегда можно будет добавить добавить реализацию в ядро.

Милый, там congestion алгоритмов уже выше крыши, выбирай на вкус.


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

44. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  –1 +/
Сообщение от Аноним (44), 21-Мрт-21, 12:06 
Но этими алгоритмами пользуется тольлко TCP. А в UDP/QUIC поддержку это придётся добавить.
Ответить | Правка | Наверх | Cообщить модератору

51. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от lockywolf (ok), 21-Мрт-21, 12:56 
Зачем вообще гонять http по udp??? UDP же дня всякого треша, который устаревает до того, как пакет успевает долететь до получателя, вроде потокового видео, аудио, или игр.

Что за странная идея реализовывать гарантированную доставку по udp?

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

75. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Аноним (75), 21-Мрт-21, 14:25 
Они нашли у TCP фатальный недостаток. TCP connect + ssl + http request занимают непростительно много времени, особенно в мобильных сетях. К тому же им хочется, чтобы сервер имел возможность определить пропускную способность клиента для всех подключений вместе и крутить им приоритеты, чтобы баннеры грузились быстрее стилей. Это можно провернуть и с TCP, но для этого нужно лезть в ядро, а у них лапки.
Ответить | Правка | Наверх | Cообщить модератору

133. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Аноним (133), 21-Мрт-21, 19:43 
Просто TCPшный congestion control на беспроводных линках вытворяет черт знает что, и вы телепаете со скоростью диалапа от того что там какой-то всперд помех в канале изредка случается. TCP из эпохи диалапа не в курсе радиопроблем и полагает что линк перегружен. И вот у вас 100 мегабитный линк, не занятый ничем, а вот тспшная конекция со скоростью диалапа. Думающая что линк типа-перегружен, раз пакеты теряет или RTT прыгает. Хотя это просто нормальный курс событий при радиолинке.
Ответить | Правка | Наверх | Cообщить модератору

160. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +1 +/
Сообщение от timur.davletshin (ok), 21-Мрт-21, 20:58 
> Просто TCPшный congestion control на беспроводных линках вытворяет черт знает что, и
> вы телепаете со скоростью диалапа от того что там какой-то всперд
> помех в канале изредка случается. TCP из эпохи диалапа не в
> курсе радиопроблем и полагает что линк перегружен. И вот у вас
> 100 мегабитный линк, не занятый ничем, а вот тспшная конекция со
> скоростью диалапа. Думающая что линк типа-перегружен, раз пакеты теряет или RTT
> прыгает. Хотя это просто нормальный курс событий при радиолинке.

Ну давно же уже всё протестировали и даже статью на русский на Хабре перевели. Зачем повторять малорелевантные профессиональные заблуждения?

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

162. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  –2 +/
Сообщение от Аноним (-), 21-Мрт-21, 21:46 
> Ну давно же уже всё протестировали и даже статью на русский на
> Хабре перевели. Зачем повторять малорелевантные профессиональные заблуждения?

Я не знаю какие вебмакаки с хабры что "тестировали" и переводили - поэтому говорю то что видел своими глазами, лично. TCP с кубиком может в определенных ситуациях drop to the floor! На ровном месте практически. А уж если там какой дисконект случился, или что еще, и нетворкменеджер целые 5 секунд ждал реконекта - вообще 3.14-ц конекции, будет полминуты одуплять. При том что канал есть, идеальный, но, вот шизанутая логика кубиков и ко с конским таймаутом когда он следующую попытку чуть не через минуту будет делать - имеется. И при малейих отклонениях от идеала в линке (что для беспроводки норма жизни) оно умеет совершенно по дурацки коллапсировать на ровном месте.

Собственно поэтому гугол и накодил BBR, закомитив его в майнлайн на секундочку (может даже заенаблил ведроидам, черт знает). Есть еще CDG похожий по смыслу, мне он показался менее эффективным, но и менее чудесатым. BBR более вменяемо реагирует - пытается различать вот реально долговременный перегруз и кратковременные всперды в канале. Но делает он это с переменным успехом, а самое печальное во всей этой истории - то что у юзеров винды его нет и не будет. Поэтому они в ряде ситуаций получают реально околодиалапные скорости и делают мозг саппорту гугля что мол видео на ютубе отлипает.

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

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

169. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от timur.davletshin (ok), 21-Мрт-21, 22:16 
> Так что cubic и ко это как раз пример технологии эры диалапа

Краткое понимание глубины вопроса.

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

185. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Аноним (-), 21-Мрт-21, 23:07 
> Краткое понимание глубины вопроса.

Я эту глубину вопроса в отличие от хабры таки потестировал самолично - и остался недоволен тем как это работает в условиях отличных от идеала.

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

166. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +2 +/
Сообщение от Ivan_83 (ok), 21-Мрт-21, 22:08 
Вы просто вообще и близко не в теме, даже похоже тут новости не читаете.
СС нынче больше десятка разных есть, самые современные это rack* и bbr.
Более старые но всё ещё клёвые htcp, hybla, ну и потом кубики с ньюрено.
Разница между htcp и bbr/rack* на плохих линках может до 5 раз доходить, из того что я видел, те где htcp даёт 1 мегабайт/сек bbr держит 3, прыгая до 5.
Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

188. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Аноним (188), 21-Мрт-21, 23:18 
> Вы просто вообще и близко не в теме, даже похоже тут новости не читаете.
> СС нынче больше десятка разных есть, самые современные это rack* и bbr.

Спасибо кэп! Собственно вторым я и пользуюсь на беспроводных линках. Но работает он все же достаточно чудесато временами.

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

> Более старые но всё ещё клёвые htcp, hybla, ну и потом кубики с ньюрено.

Есть несколько фундаментальных проблемок. Сущая ерунда:
1) Это требует мануальной настройки админами.
2) По поводу чего хренова куча серверов которые этим не парились.
3) Юзерам виндов во всех их ипостасях все это счастье не светит в принципе.
4) Сервера на винде таки тоже бывают. Вон любимые эксченжи поха подтвердят :)

> Разница между htcp и bbr/rack* на плохих линках может до 5 раз
> доходить, из того что я видел, те где htcp даёт 1
> мегабайт/сек bbr держит 3, прыгая до 5.

Теперь попробуйте все это на винде устроить, решатели проблем, итить. Нуагули, гугол с сабжем будет более-менее одинаково работать везде. Потому что их congestion control не завязан на причуды конкретного кернела как раз. Который у юзеров винды малость проблематично пропатчить.

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

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

201. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Ivan_83 (ok), 22-Мрт-21, 04:10 
Это проблемы вашего линуха, у меня нет линуха, а у гугла нет в нём проблем :)

Если этим никто не парился - значит у людей нет такой проблемы.
Сервера на венде могут стоять и за прокси в виде nginx, который будет менять СС по сути, так что это не проблема даже для тех кто держит сервисы на венде.

Я вам ещё раз говорю: на венде обычно потребляют трафик и поэтому какой там у них СС никого не колышит.

Не знаю что вы там анализировали, у меня была всегда простая цель: получить либо максимальную скорость либо достаточную чтобы иптв не заикалось, и мне даже hybla под линухом хватало.
Во фре были проблемы, до появления rack, возможно там сейчас и дефолтный tcp допилят в 13-14 версиях до состояния как линухе.

Эра не венды/огрызка только начинается, но вы этого не видите ещё.

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

247. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Аноним (247), 22-Мрт-21, 23:44 
> Это проблемы вашего линуха,

В _моем_ линухе эта проблема (как минимум частично) решена. Но есть нюансы. Я - не вся планета. И даже на гугле мир не заканчивается.

> у меня нет линуха, а у гугла нет в нём проблем :)

Это не решение способное принести счастье если не всем то большинству юзеров. Кроме гугла есть еще 100500*100500 сайтов, у клиентов есть винды всякие, и проч. При том последнее не подконтрольно даже гуглу. Собственно оттуда и идея юзать UDP.

> Если этим никто не парился - значит у людей нет такой проблемы.

Уход в отрицание? Если прочитать топик - можно заметить что сетевые инженеры гугла (а теперь и мазилы) иного мнения. И с чего бы это вдруг они UDP юзать взялись? Может с того что строить всех академморонов и индусов на тему congestion control за столько лет заколебало даже гугл? :)

> будет менять СС по сути, так что это не проблема даже
> для тех кто держит сервисы на венде.

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

> Я вам ещё раз говорю: на венде обычно потребляют трафик и поэтому
> какой там у них СС никого не колышит.

Красиво было на бумаге да забыли про овраги. И выбирая между вами и инженерами гугла, гугловым я таки больше верю. У них это напрямую в бабки и churn отливается.

> Не знаю что вы там анализировали, у меня была всегда простая цель:
> получить либо максимальную скорость либо достаточную чтобы иптв не заикалось, и
> мне даже hybla под линухом хватало.

А теперь простой эксперимент: попробуйте сие посмотеть взяв мобилку и плюхнувшись в кресло в машине (пассажирское конечно) едучи по трассе, с не особо стабильным покрытием. И как, хорошо получается? Можете в фоне пустить хотя-бы пинг для понимания фактической доступности канала, прикинуть utilisation канала и проч. Если вы этим профессионально заниметесь то наверное и получше это сможете организовать.

> Во фре были проблемы, до появления rack, возможно там сейчас и дефолтный
> tcp допилят в 13-14 версиях до состояния как линухе.

Как вы понимаете проблема TCP congestion control несколько более многогранна. И по моим наблюдениям оно даже в линухе не умеет в адаптив со скоростью потребной для юзера едушего в авто или поезде. Ну вот не те порядки величин времянок + вымахивающий до дичи вплоть до 60, чтоли, секунд таймаут на retry. А потеря соты на несколько секунд - не "перегруз сети", что ты там этот крап себе внутрях не мнил.

> Эра не венды/огрызка только начинается, но вы этого не видите ещё.

Я много чего вижу. А кроме всего прочего - вот натыкаюсь на самую странную дичь. Скажем олдскульные юзеры привыкли пыриться в ящик ДНЯМИ. Они не хоят ничего знать про проблемы ваших пакетов. Но если так делать, даже на хорошем в целом радиолинке бывает так что 1-2 раза в сутки теорвер прикалывается, до состояния когда у tcp таймауты вымахивают до невменяемых величин, и видео все же икает, юзеры кроют эти ваши интернеты на чем свет стоит. При том имея вполне валидные основания - "computer is thrashing". В линке дофига бандвиза, фатально ничего не перегружено, но скорость адаптива vs конские таймауты буфер не удержали и юзер злой.

При том гугол далеко не хучший вариант. У них плеер по крайней мере динамически бандвиз менять умеет и может чанксервер сменить (при этом затупившая конекция со всеми причудами congestion control просто идет на йух, а новая по дефолту как правило сильно бодрей и улучшение достигается). А вот какие-нибудь мелкие местечковые сервисы гонящие поток с какой-нибудь камеры или типа того, с никакими админами и рыхлым, жирным потоком в разы больше ютуба - вот там жесткач.

Еще бывают корпы и впн. Как работает TCP в TCP все догадываются, а корпадминам обычно впадлу что-то кроме TCP/443 на фаере открывать. Так что, мол, гоняйте впн через это, и познайте все прелести эффекта домино... сабж на них поднажмет малость.

Поэтому сабж имхо все же постепенно улучшит картину мира. Без особого упования на интеллект админов, юзеров или кого еще. В нем это factored out. Достаточно браузер сменить.

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

53. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  –2 +/
Сообщение от timur.davletshin (ok), 21-Мрт-21, 13:02 
> Но этими алгоритмами пользуется тольлко TCP. А в UDP/QUIC поддержку это придётся
> добавить.

Дурилка, для UDP они не нужны по дизайну.

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

120. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Аноним (44), 21-Мрт-21, 17:51 
Для UDP (RFC 1980-x годов) не нужны, но речь про QUIC. Вот эти (с Гугелем не связаны) https://udt.sourceforge.io/ тоже считают UDP недостатком и надстраивают.
Ответить | Правка | Наверх | Cообщить модератору

128. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  –1 +/
Сообщение от timur.davletshin (ok), 21-Мрт-21, 19:33 
> Для UDP (RFC 1980-x годов) не нужны, но речь про QUIC. Вот
> эти (с Гугелем не связаны) https://udt.sourceforge.io/ тоже считают UDP недостатком и
> надстраивают.

Я тебе ещё раз говорю, что гугл просто реализует ещё один уровень абстракций для передачи пользовательского трафика. QUIC - это самый обычный UDP, поверх которого надстроен контроль целостности потока (из глобальных вещей).

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

134. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  –1 +/
Сообщение от Аноним (133), 21-Мрт-21, 19:44 
И, вероятно какой-то кастомный congestion control. Совсем без него видите ли есть шанс глобально завалить сети.
Ответить | Правка | Наверх | Cообщить модератору

131. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  –2 +/
Сообщение от Аноним (-), 21-Мрт-21, 19:40 
> Милый, там congestion алгоритмов уже выше крыши, выбирай на вкус.

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

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

211. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Аноним (211), 22-Мрт-21, 08:11 
делать нормальные сайты пробовал?
Ответить | Правка | Наверх | Cообщить модератору

248. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Аноним (-), 22-Мрт-21, 23:54 
> делать нормальные сайты пробовал?

Сайтов видите ли сейчас миллиард, чтоли. Переделать весь миллиард по фэншую у меня кишка все-таки тонка.

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

228. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Я (??), 22-Мрт-21, 13:50 
но http/3 открытый стандарт не зависящий от хромого блоба.. просто не используйте http/3 для решения задач для которых он не подходит и не предназначен. разные протоколы существуют и поддерживаются не просто от NIH синдрома а для решения разных задач разными методами.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

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

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




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

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