The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Протокол HTTP/3.0 получил статус предложенного стандарта, opennews (ok), 07-Июн-22, (0) [смотреть все]

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


17. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +17 +/–
Сообщение от timur.davletshin (ok), 07-Июн-22, 09:53 
Проблема в том, что пропихивающие QUIC не говорят о его недостатках. Плюс, корявые реализации (попробуйте загрузить большой файл на Youtube из этого вашего FF) и бай-дизайн большая нагрузка на сервера и клиенты из-за выноса задачи реального времени (управление потоком данных) в userspace. Последнее обстоятельство можно сравнить с выносом операции ресэмплинга звука из ядра в pulseaudio. Сколько ора на тему того, что звук икает из-за иссякания буфера при пиковых нагрузках? Второе же с низкой производительностью файловых систем реализованных в пользовательском пространстве (привет, FUSE/NTFS). В HTTP/3 проблемы возникают аналогичные, только пользователю они сразу не заметны. Сервера действительно начинают жрать больше, а jitter в соединениях только растёт.
Ответить | Правка | Наверх | Cообщить модератору

25. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (25), 07-Июн-22, 10:32 
Think different. Это не недостатки, а новые возможности.  
Ответить | Правка | Наверх | Cообщить модератору

26. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/–
Сообщение от timur.davletshin (ok), 07-Июн-22, 10:33 
> Think different. Это не недостатки, а новые возможности.  

У thinkdifferent'ов хоть ECN включен в дефолте )))

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

70. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (70), 07-Июн-22, 14:50 
Как в анекдоте.
Меня коучи научили, что вместо "проблема" надо говорить "вызов".
Так вот, у меня теперь "вызов" с головой
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

52. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/–
Сообщение от n00by (ok), 07-Июн-22, 13:00 
На мой дилетантский взгляд сравнение с pulseaudio не вполне корректно. Даёт наглядное (точнее - воспринимаемое ухом) представление о проблеме, но скрывает её масштаб. Обработка звука это, грубо, всего 1% нагрузки. А QUIC, если на сервере, насколько больше?
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

53. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/–
Сообщение от timur.davletshin (ok), 07-Июн-22, 13:08 
> На мой дилетантский взгляд сравнение с pulseaudio не вполне корректно. Даёт наглядное
> (точнее - воспринимаемое ухом) представление о проблеме, но скрывает её масштаб.
> Обработка звука это, грубо, всего 1% нагрузки. А QUIC, если на
> сервере, насколько больше?

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

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

56. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от n00by (ok), 07-Июн-22, 13:29 
То есть, после повсеместного внедрения стандарта, придётся переносить реализацию в ядро? Но Гугл не обязательно этим со всеми поделится.
Ответить | Правка | Наверх | Cообщить модератору

61. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +3 +/–
Сообщение от timur.davletshin (ok), 07-Июн-22, 14:17 
> То есть, после повсеместного внедрения стандарта, придётся переносить реализацию в ядро?
> Но Гугл не обязательно этим со всеми поделится.

Соль была в том, чтобы иметь реализацию в пользовательском пространстве. Мол, так алгоритм управления потоком Google сможет апдейтить просто обновляя Chrome (например). Этим алгоритмом был BBR, который не очень взлетел. Да, у него есть интересные моменты, но нет, например поддержки ECN, и проблемы с честностью (он склонен душить другие соединения). Алгоритм не взлетел, но сама идея вынести всё в userspace осталась. В теории можно перенести в ядро, но это потянет целый ворох ненужного в ядро. Только каких-нибудь подгружаемых сертификатов извне там не хватало. Вон, wireguard тащит всё в ядро, мол, управлять потоком там сподручнее и это ВОООН какой профит даёт, а google тащит аналогичные вещи в userspace и поёт о том, какой профит им это даёт.

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

P.S. вообще на самом деле нынешний CUBIC+HYSTART+SACK+ECN почти богоподобен. Да, оно плохо подстраивается под внезапные увеличения в доступной пропуской способности беспроводных сетей, но я бы решал эту проблему пробросом информации из более низкого уровня. Например, расширить концепцию ECN сигналом явно уведомляющим об освобождении полосы. Даже в поле ECN есть неиспользующийся сигнал ECT1, который сейчас интерпретируется как равный ECT0. А городить сложные алгоритмы (BBR - самый сложный из congestion control'ов) в userspace... — ну такое себе.

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

225. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 10-Июн-22, 18:02 
> P.S. вообще на самом деле нынешний CUBIC+HYSTART+SACK+ECN почти богоподобен.

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

> Да, оно плохо подстраивается под внезапные увеличения в доступной пропуской способности

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

> сетей, но я бы решал эту проблему пробросом информации из более низкого уровня.

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

> интерпретируется как равный ECT0. А городить сложные алгоритмы (BBR - самый
> сложный из congestion control'ов) в userspace... — ну такое себе.

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

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

226. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:08 
> BBR таки немного получше работает и такой не от хорошей жизни. Но даже он иногда вытворяет черти что, демоенстрируя издевательскую утилизацию линка.

Простите, но его даже не ради этого создавали. Я уже не говорю о том, что он и не может выдавать лучший вариант, т.к. его логика работы состоит в том, что периодически пытаться слать больше, чем лезет, и смотреть, что из этого получается. Дропы — не увеличиваем скорость, пролезло — можно больше.

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

255. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 11-Июн-22, 01:53 
> Простите, но его даже не ради этого создавали.

А мне похрен. Если протокол не покрывает столь базовый и массовый кейс, его время в том качестве явно вышло. И настало время решений которые смогут нормально работать и в вон тех случаях. О чем и сабж.

> его логика работы состоит в том, что периодически пытаться слать больше,
> чем лезет, и смотреть, что из этого получается. Дропы — не
> увеличиваем скорость, пролезло — можно больше.

И все же...
1) BBR иногда начинает иметь довольно странное мнение о доступном бандвизе линка. Вероятно, его тайминги неудачно стыкуются с перетурбациями линка, или типа того, но он может упереться рогом и юзать целые 20-30% бандвиза. Многопоточные качалки получают +1 пойнт...

2) Даже он иногда может уйти в конские таймауты без должного основания. Видимо тоже случается хрень типа того что вот именно в момент перепосылки - соты не оказалось/пакет выпал, и неплохой в целом линк используется... да почти ни на сколько, протокол уходит в туповэйтинг. Если новую конекцию открыть - как из пушки прет, но уже существующая туповэйтит хоть там что. Сказано же, таймер на полчаса и все тут. И потом вы удивляетесь что кто-то хочет это переделать? :)

Есть thin linear timeouts еще, но опять же это какая-то эвристика, довольно наркоманская, и работает она тоже весьма малопредсказуемо и криво. А висящая минуту SSH сессия так то тоже бесит, если что.

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

274. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 11-Июн-22, 19:26 
> А мне похрен. Если протокол не покрывает столь базовый и массовый кейс, его время в том качестве явно вышло.

У тебя каша в голове. Протокол - IP, а BBR, на который ты так наяриваешь, это алгоритм управления перегрузками (congestion control), который был реализован для TCP и для UDP/QUIC. Всё.

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

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

277. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 12-Июн-22, 00:38 
> У тебя каша в голове. Протокол - IP,

Спасибо Кэп, это подразумевалось. Правда с оговоркой что TCP/IP.

> а BBR, на который  так наяриваешь, это алгоритм управления перегрузками (congestion control),
> который был реализован для TCP и для UDP/QUIC. Всё.

Еще раз спасибо кэп. Только...
1) В UDP/QUIC гугол во первых сможет его рихтовать в цать раз оперативнее. Хоть в каждой версии браузера.
2) Это можно оперативно раздать всяким юзерам винды и чего там еще, улучшив user experience и для них. Прожать майкрософт до внедрения BBR в ядро NT - малореально.
2) Вменяемые алгоритмы контроля будут заведомо на обоих сторонах линка. В случае TCP - окажется с той стороны какой-нибудь гадский кубик и проч - и таки нагадит. Это ж в 2 стороны работает и мы может вообще ничего слать не хотели. А то что ремота туповэйтила по таймеру минуту - мы и будем дергаться через минуту, когда они расчехлятся вообще пакет прислать.

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

Вот то что тебя никто не будет спрашивать с твоим уровнем квалификации - я таки уверен. И кстати вот именно тебя я забуду спросить что мне жрать. То что я жру от тебя вообще никак не зависит.

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

286. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 12-Июн-22, 04:32 
> В UDP/QUIC гугол во первых сможет его рихтовать в цать раз оперативнее. Хоть в каждой версии браузера.

Браузер по определению скачивает данные в основном. Наличие убер-протокола никак не поможет серверу. Надеюсь, ты это в состоянии понять?

> Это можно оперативно раздать всяким юзерам винды и чего там еще, улучшив user experience и для них. Прожать майкрософт до внедрения BBR в ядро NT - малореально.

Ты в курсе, что разработку оригинального BBR бросили? Даже сам Google пользуется чем-то другим с заметно отличной логикой. Если бы он был так хорош, то почему на него не перешли даже в самом HTTP/3?

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

302. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 12-Июн-22, 21:33 
> Браузер по определению скачивает данные в основном.

В целом - да, но...
1) Чтобы сервер вообше что-то послал - сначала это надо запросить! Путем ОТПРАВКИ запроса. Если мы при этом туповэйтили минуту, сервер вообще не знал что мы от него хотим. Надеюсь, ты в состоянии это понять, великий эксперт?
2) Юзеры так то нынче совсем не прочь аплоадить фоточки и видео нефигового размера, и это кажется не даунлоад.
3) Внезапно сервера будут юзать вообще сразу и по дефолту какую-то сильно менее ретарднутую реализацию чем гребаный кубик и т.п. как в TCP. Так что и тут скорее всего мобильно-беспроводным будет лучше. И кстати либы всего этого будут апдейтить и твикать... явно резвее чем некоторые, особенно типа майкрософта.

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

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

> Ты в курсе, что разработку оригинального BBR бросили? Даже сам Google пользуется
> чем-то другим с заметно отличной логикой. Если бы он был так хорош, то почему
> на него не перешли даже в самом HTTP/3?

Он не "хорош" но "лучше чем другие в этом позорном гадюшнике" при натурных испытаниях в поле. И таки в линуксе он тоже вроде какой-то допатченый и затвиканый. А что там и где "бросили" я не знаю. В линукс кернеле не бросили - иначе он был бы оттуда выпилен как orphaned, вероятно.

Все остальное на беспроводке рабоатет еще хуже. Что-то вменяемое может еще разве что CDG, но он временами делает какие-то очень странные вещи. BBR их так то тоже пытался делать но это починили 3-4 релиза назад.

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

312. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 13-Июн-22, 02:51 
> BBR их так то тоже пытался делать но это починили 3-4 релиза назад

Там из заметного только механизм pacing rate изменили... Оно никак не поменяло логику алгоритма.

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

320. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:29 
> Путем ОТПРАВКИ запроса.

И сколько там запрос GET занимает? В запросном канале ВСЕ алгоритмы ведут себя одинаково, они даже не уходят ни разу в потолок. Твой BBR не сможет задетектить рост RTT, а классический Cubic/Reno не получит первого дропа. Оговариваюсь про классический, т.к. сейчас везде (в Linux/Android хотя бы) уже гибридный старт, который сделал из Cubic аналог твоего BBR на начальном этапе или этапе slow start... там меряются RTT "паровозиков" из пакетов. Если же у тебя лежит канал, то обработка этого события ведётся по а) непревышению таймаута соединения (который НЕ ЗАВИСИТ от алгоритма congestion control'а; б) алгоритм сбросит тебя в режим slow start и перезапросит выборочно потерянные пакеты, если включен SACK (включен по умолчанию у всех).

Никакого другого варианта просто нет. Ты банально демонстрируешь непонимание того, как работает сетевой стек.

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

321. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:41 
> А что там и где "бросили" я не знаю.

Google его не использует. Он использует некую модифицированную версию (погугли "The Great Internet TCP Congestion Control Census"), отличающуюся заметно от той, что скормили в ядро Linux. Стриминговые сервисы используют Cubic или Reno+RACK, Youtube какую-то модифицированную версию BBR (но не BBRv2), даже на остальных сервисах (не серверах доставки видео) Google использует Cubic.

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

287. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 12-Июн-22, 04:34 
> Спасибо Кэп, это подразумевалось. Правда с оговоркой что TCP/IP.

Нет, милок, именно IP в данном контексте.

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

227. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:09 
> Ее даже немного пробрасывают вроде, но в целом оно работает дерьмово.

Протокол проброса информации в студию! А то пацаны-то не знают.

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

256. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 11-Июн-22, 01:58 
> Протокол проброса информации в студию! А то пацаны-то не знают.

Не знаю можно ли называть протоколом кучу эвристики и кой-какие сведения от линуксного ядра. И это, у разных протоколов достаточно разные понятия бывают, их все под 1 гребенку насчет проблем физического уровня причесать так то не очень просто. И какого-то устоявшегося механизма "для всех" нет. Более того - какой-нибудь сотовый модем это в стандартном виде вообще не отдает обычно, ну вот нет устоявшегося интерфейса для этого. Если я любопытный то конечно vendor cmd и прочей отладочной статистикой увижу и уровень сигнала в -dBm, и snr, и что там еще, но вот кернель про это все не очень в курсе.

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

273. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 11-Июн-22, 19:23 
> Не знаю можно ли называть протоколом кучу эвристики и кой-какие сведения от линуксного ядра.

Проброс делается не эвристикой, а просто внесением изменений в протокол IP. Надо выделить новое поле, которое будет кодировать увеличение или уменьшение символьной скорости физического линка. Делать это никто не хочет.

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

278. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 12-Июн-22, 01:02 
> Проброс делается не эвристикой, а просто внесением изменений в протокол IP. Надо
> выделить новое поле, которое будет кодировать увеличение или уменьшение символьной скорости
> физического линка. Делать это никто не хочет.

А смысл этого какой?
1) Беспроводные интерфейсы сейчас довольно адаптивные, за сменой битрейта/модуляции не ржавеет, они могут чуть не попакетно менять, выжимая из линка фактически доступный в этих условиях максимум. Какая ценность значения в хидере? Вафля вообще насколько я помню может указывать конкретный битрейт например пакетам beacons "и пофиг на остальное". То-есть минимум 10 раз в секунду девайс может бросить все, сменить битрейт/модуляцию на потребную для beacon, оформить beacon и заняться дальше передачей данных. Ах да, заподозрить об этом можно просто помониторив статистику вафли или сотового модема. Но видимо это недостойное занятие для гуру.

2) Интернет вообще-то сеть, в которой я вообще-то с дофига систем коммуницирую. Допустим у меня пара десятков программ что-то делают по TCP, UDP, а может и еще чему, ICMP например. И чего в хидере вот конкретно этого данного пакета при таком раскладе писать? Бандвиз же не будет целиком вот этой вот ремоте отдан при таком раскладе. Более того - это еще и от того что будут дальше ремотные системы делать зависит. Может, половина через 5 секунд решат что накоммуницировались и отвалят. А может наоборот мег данных пульнут. Это вообще от них зависит.

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

229. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:11 
> На мобильном линке с движущемся транспорте он подобен разве что каре господня,
> когда ваше терпение поджаривают на медленном огне, глумясь над процентом утилизации
> линка.

Проблема в том, что ничего лучшего нет, т.к. при отсутствии проброса информации с нижележащего уровня логику определения оптимальной скорости трудно представить кроме той, что уже были реализованы (не только в CUBIC).

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

257. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 11-Июн-22, 02:04 
> Проблема в том, что ничего лучшего нет, т.к. при отсутствии проброса информации
> с нижележащего уровня логику определения оптимальной скорости трудно представить кроме
> той, что уже были реализованы (не только в CUBIC).

Я вообще не представляю себе логику определения скорости линка когда я чешу в поезде и SNR и вообще наличие сот плавает в широком пределе и быстро. ИМХО там только быстрый агрессивный адаптив сможет что-то вменяемое делать.

В принципе CDG и BBR как я понял пытаются ловить перегруз линка по росту RTT. Но это у них довольно криво получается, лажа все равно иногда выходит.

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

271. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 11-Июн-22, 19:15 
> В принципе CDG и BBR как я понял пытаются ловить перегруз линка по росту RTT. Но это у них довольно криво получается, лажа все равно иногда выходит.

Ловить перегруз по росту RTT пытаются уже больше 20 лет и все алгоритмы только на нём (RTT) сливают по своему определению всем остальным по всем параметрам кроме RTT. Caia (CDG) в своём дефолтном состоянии примерно равен BBR. Но, функциональнее, за счёт поддержки ECN (да, Google его не осилил в BBR) и за счёт наличия алгоритма гибридного старта (единственный, кроме Cubic, где он есть). Плюс CDG в том, что уровень его агрессивности (он двухрежимный) легко регулируется в широких пределах (в отличие от BBR), особенно в реализации Linux (родная BSD'шная убога по настройкам и нет гибридного старта). Сломать настройками в CDG мало получится, т.к. в предельном случае ты получишь продвинутый вариант классического Reno со всеми его недостатками. Но по дефолту он больше на low priority алгоритм тянет. Собственно, можешь погуглить, есть академический бенчмарк оценки алгоритмов для задачи низкоприоритетной доставки с низкими задержками. CDG там лидер.

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

279. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 12-Июн-22, 01:31 
> Ловить перегруз по росту RTT пытаются уже больше 20 лет и все
> алгоритмы только на нём (RTT) сливают по своему определению всем остальным
> по всем параметрам кроме RTT.

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

> Caia (CDG) в своём дефолтном состоянии примерно равен BBR. Но, функциональнее,
> за счёт поддержки ECN (да, Google его не осилил в BBR) и за счёт наличия алгоритма
> гибридного старта (единственный, кроме Cubic, где он есть).

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

> Плюс CDG в том, что уровень его агрессивности (он двухрежимный) легко регулируется
> в широких пределах  (в отличие от BBR),

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

> особенно в реализации Linux (родная BSD'шная убога по настройкам и нет
> гибридного старта). Сломать настройками в CDG мало получится, т.к. в
> предельном случае ты получишь продвинутый вариант классического Reno со всеми
> его недостатками. Но по дефолту он больше на low priority алгоритм тянет.

Как по мне - довольно странная идея для дефолтов. Но меня в нем больше всего напрягало очень странное мнение о доступных скоростях временами. Если конекцию спихнуть и новую открыть, будет шустренько. А если не спихнуть, так и будет на 1/3 скорости линка пехать. Мне что, каждый раз ему такую мануальную терапию делать? Да ну нафиг.

> Собственно, можешь погуглить, есть академический бенчмарк оценки
> алгоритмов для задачи низкоприоритетной доставки с низкими задержками. CDG там лидер.

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

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

285. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 12-Июн-22, 04:27 
> Академики живут где-то в своих кельях, и, кажется, прогуляться с мобилкой или ноутом со сниффером банально не пробовали. В гугле же есть и хипстюки с мобилками, которые могут без обиняков сообщить обитателям келий что получился все-таки булшит.

Потрудитесь полистать https://researchbank.swinburne.edu.au/file/1560d7f6-6fa3-4ad...

... теперь понимаешь, что твои тезисы на уровне шариковских?

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

272. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 11-Июн-22, 19:18 
Касательно CDG была защищена докторская пару лет назад с описанием улучшенного алгоритма. По бенчмаркам не офигенный прорыв, но многие недостатки двухрежимного гибридного алгоритма действительно улучшил ощутимо. Но, опять же, в реальной жизни вкатывание и отладка их занимает годы. Напомню, что настраивать надо в первую очередь ту сторону, которая отдаёт данные. Если ты у себя настроишь свой любимый BBR, то результата для клиентской машины будет чуть больше нуля.
Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

304. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 12-Июн-22, 23:26 
> Касательно CDG была защищена докторская пару лет назад с описанием улучшенного алгоритма.

Академы пэйперы пишут специфично. Их интересует не то что будет с юзером в поле, а доказательство что они и их тезис - офигенные. Замеры перекошены в эту сторону. Это НЕ ЕСТЬ объективная оценка свойств алгоритма. Иначе wannabe-доктор может степень не получить а это ему не катит. Поэтому в пейперах почти все офигенно. На бумаге.

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

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

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

Особенно обломно в чем-то типа VPN по TCP - CDG его может удушить до дурной скорости, а потом так и будет тупить пока не рестартанешь, но это ж линк роняет, неудобно. Ах конечно академы про такие кейсы небось не думали. Дада, впн надо по удп и проч, вон тому корп фаеру и прокси это еще расскажи.

> Напомню, что настраивать надо в первую очередь ту сторону, которая отдаёт данные.

Напомню, коммуникации двухсторонние. Чтобы сервер начал что-то отдавать, клиент должен запрос прислать. Иначе кто его там знает что он вообще хотел. В этом месте не совсем тупые персонажи начнут догадываться почему столько внимания числу RTT до начала передачи данных а еще более сообразительные осознают и проблему head of line blocking.

> Если ты у себя настроишь свой любимый BBR, то результата для клиентской машины
> будет чуть больше нуля.

Его в идеале с обоих сторон надо - но в случае TCP это довольно трудно достичь в общем случае. Особенно если 1 из клиентов маздай какой-то.

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

317. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:12 
> Академы пэйперы пишут специфично. Их интересует не то что будет с юзером в поле, а доказательство что они и их тезис - офигенные. Замеры перекошены в эту сторону. Это НЕ ЕСТЬ объективная оценка свойств алгоритма. Иначе wannabe-доктор может степень не получить а это ему не катит. Поэтому в пейперах почти все офигенно. На бумаге.

Чем публикация тестов Google лучше? Оно даже по критериям академичности не прокатывает.

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

318. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:15 
> Ну и вот в реальной жизни реальная имплементация CDG в линуксе умеет делать какую-то хрень и не очень то хочет рекаверится из этого состояния.

Есть такая вещь в параметрах модуля backoff_factor (у реализации BSD она иначе зовётся), попробуй её понастраивать. Можешь начать со значения 1.

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

319. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:19 
> Его в идеале с обоих сторон надо - но в случае TCP это довольно трудно достичь в общем случае. Особенно если 1 из клиентов маздай какой-то.

Проблемы масдая не в кубике, а в том, что там отключены tcp timestamp'ы (уточни, так ли это в последних версиях) и джиттер может привести его в состояние повышенного дропа пакетов. Но timestamp'ы и там включаются лёгким движением мыши.

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

231. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:13 
> Еще хуже когда это были соты с прорехами в покрытии и движущийся
> юзер, а этот кал удумал что это перегруз сети и ушел
> в дикие таймауты измеряемые минутами.

А как ты себе представляешь обработку такой ошибки? Просто пофантазируй и опиши её техническими терминами.

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

258. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 11-Июн-22, 02:09 
> А как ты себе представляешь обработку такой ошибки? Просто пофантазируй и опиши
> её техническими терминами.

В идеале - качаем данные на полной скорости линка пока он есть, на лету адаптируясь к ее изменениям, быстро, реалтаймно. Ну и не качая пока линка нет.

И в конце концов стремиться надо к чему-то такому. Ну вот "агрессивный" BBR к этому немного ближе ретарднутых уродов типа кубиков всяких. Но даже он иногда делает фиг знает что, у кернела свои заскоки насчет TCP, а юзерам windows этот BBR вообще не раздашь нифига в их маздайный кернел. Я вообще не знаю умеет ли маздайный кернел в разные алгоритмы congestion control.

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

270. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 11-Июн-22, 19:02 
> В идеале - качаем данные на полной скорости линка пока он есть, на лету адаптируясь к ее изменениям, быстро, реалтаймно. Ну и не качая пока линка нет.

Собственно ты словами и описываешь классический алгоритм. Задайся вопросом о том, как алгоритм может знать о скорости линка вслепую, без проброса этой информации снизу. Поверь, там уже далеко ушло от твоего понимания данного вопроса. Почитай потом, например, про проблему медленного старта (это название этапа, если что) и как её пытается решить гибридный старт (а это алгоритм). А дальше, если поймёшь вышеозначенное, уже сам начнёшь читать.

> Ну вот "агрессивный" BBR к этому немного ближе ретарднутых уродов типа кубиков всяких.

Как думаешь, долго можно оставаться нахалом в очереди? Вот так и BBR будет оставаться агрессивным ровно до тех пор, пока коса его агрессивности не столкнётся с аналогичным потоком BBR. Странно, но реальные тесты BBR показывают, что он - говно. Он обгоняет Cubic процентов на 10% только на длинном пинге c увеличенным дропом. Во всех остальных он безбожно сливает (но, оговорюсь, держит низкий пинг при максимальной для него нагрузке). В локальной сети при пинге 1 мс он проседает процентов на 30%! Можешь с лёгкостью проверить это у себя дома, благо tcp_bbr.ko есть сейчас у всех десктопных Линуксов.

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

280. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 12-Июн-22, 02:09 
> Собственно ты словами и описываешь классический алгоритм.

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

> Задайся вопросом о том, как алгоритм может знать о скорости линка вслепую,

Лучший индикатор который я знаю это RTT. Я вижу вполне прямую корреляцию роста RTT c "линк перегружен" на почти всех типах линков. При том это довольно универсальная метрика. Ну вот например вафля. Может декларить 150Мбит рейт, но сделать 3 перепосылки. Или 75, но влупить за 1 раз. Если любопытно - зазырь что на этот счет Minstrel делает, но он там это делает где-то внутрях себя, а у многих других девайсов эти решения вообще фирмвар принимает по одному ему ведомым критериям. И этот фирмвар может и не вывешивать столько сведений наружу. И это, глядя на статистику minstrel'а я даже не знаю что там номинальной символьной скоростью назвать.

И вот кстати его эвристика работает довольно недурно, но вот у него таки есть доступ к весьма детальному статусу его железки. Специфично для его железки. Экспортировать ЭТО в TCP? А счастьем точно не зашибет? :)

> без проброса этой информации снизу. Поверь, там уже далеко ушло от твоего понимания
> данного вопроса.

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

> Почитай потом, например, про проблему медленного старта (это название этапа, если
> что) и как её пытается решить гибридный старт (а это алгоритм).
> А дальше, если поймёшь вышеозначенное, уже сам начнёшь читать.

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

Не, если ты по проводному эзернету, по одной TCP конекции гонишь данные, ок, там понятно. А если это 20 endpoint'ов на прыгающей как блоха беспроводке, да еще зависит от действий ремотных систем, то чего туда писать и какой смысл это все несет?

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

Тем не менее, нахальность обеспечивает ему лучший трекинг "огибающей доступного бандвиза линка". Это довольно быстро фаломорфирующая в беспроводке величина если ты не понял. Варьируется от нуля (сота пропала/линк отпал) до весьма солидных значений в сотни мегабитов и довольно резво.

> Странно, но реальные тесты BBR показывают, что он - говно.

Смотря кто и что тестировал. Кто-то вообще пробовал оттестировать следование алгоритмов огибающей реально доступного бандвиза линка и прикинуть процент утилизации того что было фактически доступно? Это довольно сложно - и я плохо представляю себе как это сделать воспроизводимо.

Понимаешь, когда качается с 1/3 доступной скорости линка или 10-секундный вылет апгрейдится до минутного - мне реально похрен что твои синтетические бенчи рисуют. И победитель для меня тот кто избавит от этого трешака.

> Он обгоняет Cubic процентов на 10% только на длинном пинге c увеличенным дропом.

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

> Во всех остальных он безбожно сливает (но, оговорюсь, держит низкий пинг
> при максимальной для него нагрузке).

И явно лучше адаптируется к изменчивым линкам. Не обваливаясь в полное дно так легко и просто как кубик.

> В локальной сети при пинге 1 мс он проседает процентов на 30%!

А в беспроводке твой кубик может и на почти бесконечность процентов слить. А сколько процентов записать протоколу почти не качающему данные вообще? :)

> Можешь с лёгкостью проверить это у себя дома, благо tcp_bbr.ko есть сейчас у
> всех десктопных Линуксов.

Ну вообще-то я на беспроводных линках как раз прицельно поэкспериментировал с разными и пришел к выводу что там мне больше всего нравится BBR. И знаешь, когда чатик в поезде датыкается на минуту, меня это больше напрягает чем 10 или даже 30% бандвиза в локалке.

Ну и применительно к браузеру - я не думаю что основное применение браузеров это кач файлов с локалки, так что вон те 30% никто не увидит. Зато на беспроводке юзеры будут ощущать себя куда лучше чем сейчас.

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

284. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 12-Июн-22, 04:18 
Ты демонстрируешь полное непонимание вопроса.

> Ну вообще-то я на беспроводных линках как раз прицельно поэкспериментировал с разными и пришел к выводу что там мне больше всего нравится BBR.

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

> И знаешь, когда чатик в поезде датыкается на минуту...

Т.е. ты хочешь сказать, что ты можешь в этот самый момент слать UDP, а TCP в этот момент молчишь? Просто, исходник tcp.c не такой большой, покажи мне этот момент в коде.

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

305. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 12-Июн-22, 23:34 
> Ты демонстрируешь полное непонимание вопроса.

Я демонстрирую то что увидел по факту в снифере и статистике сокетов. И если в энных ситуациях факты выглядят вот так - значит вот так. И какая разница что там в пейперах написано при этом?

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

А это не тезис и не теория. Это констатация того что я в снифере и статистике сокетов вижу. Маленький такой нюансик.

> Т.е. ты хочешь сказать, что ты можешь в этот самый момент слать
> UDP, а TCP в этот момент молчишь? Просто, исходник tcp.c не
> такой большой, покажи мне этот момент в коде.

Я хочу сказать что tcp уходит в аццкий timer, типа-борясь с типа-congestion. Которым поезд нырнувший под мост и потерявший на сколько-то секунд линк, очевидно, не является. И вот это поведение выглядит довольно идиотским. ИМХО в сабже его пролечат на корню а такие как ты будут пиндеть про "более агрессивный". А что делать, если только так адаптив к свойствам нестабильного быстро меняющегося линка околореалтаймно получается? Остальные потуги там работают как УГ.

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

316. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:10 
> Я хочу сказать что tcp уходит в аццкий timer, типа-борясь с типа-congestion. Которым поезд нырнувший под мост и потерявший на сколько-то секунд линк, очевидно, не является. И вот это поведение выглядит довольно идиотским. ИМХО в сабже его пролечат на корню а такие как ты будут пиндеть про "более агрессивный". А что делать, если только так адаптив к свойствам нестабильного быстро меняющегося линка околореалтаймно получается? Остальные потуги там работают как УГ.

Простите, давайте ближе к "телу". Про какой такой таймер вы говорите и в каком сниффере. В идеале я бы ждал скрин, но можно просто терминами. Я пойму.

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

288. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 12-Июн-22, 04:37 
> Если любопытно - зазырь что на этот счет Minstrel делает...

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

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

310. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 13-Июн-22, 00:17 
> Я тут внезапно понял, что ты не в курсе, как коррекция ошибок
> в беспроводных протоколах работает, и весь твой трёп сводится фактически к этому.

Ух, конечно-конечно, о великий гуру. Есть правда маленький нюансик. Я таки накодил пару небольших беспроводных линков. Даже с FEC. Это конечно не предел мечтаний, но придает пикантности твоим предъявам.

А если бы ты не был столь глупым то заметил бы еще и что я так то указал две радикально разные ситуации, которые однако обе могут вбить TCP в асфальт. Коррекция ошибок на ситуации "всплеск помех" и "линк вообще вышибло т.к. поезд заехал под мост" реагирует все же довольно по разному.

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

313. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 13-Июн-22, 02:53 
> Коррекция ошибок на ситуации "всплеск помех" и "линк вообще вышибло т.к. поезд заехал под мост" реагирует все же довольно по разному.

А на каком уровне OSI происходит коррекция ошибок?

> FEC

LDPE нормальные люди используют давно.

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

323. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 16-Июн-22, 14:04 
https://legacy.netdevconf.info/2.1/papers/compare-tcp-highwa... — не читай вывод, смотри на графики. Исследование твоего BBR в дикой природе. Как разница?
Ответить | Правка | Наверх | Cообщить модератору

289. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 12-Июн-22, 04:47 
Ладно, юзай там свой BBR. Я выше уже писал, что есть категория совершенно полоумных, которые включают его на основании малограмотных советов из бложиков в Medium, а потом рассказывают, что у них кол-во таймаутов уменьшилось, скорости выросли и волосы стали гладкими и шелковистыми. Ещё раз напомню, что это из разряда психологии. У меня был один такой коллега, у которого после обновления дистрибутива сервера быстрее начинали, по его признанию, работать. Эффект держался иногда до месяца. Когда в коллективе появился аудиофил, то они нашли друг дружку. Сила самоубеждения творила с ними страшные вещи. Главное, бенчмарки не проводить грамотные 😆
Ответить | Правка | К родителю #280 | Наверх | Cообщить модератору

306. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 12-Июн-22, 23:45 
Я вообще-то на беспроводках тупо поэкспериментировал и посмотрел что лучше всего будет работать. Ну и как-то в среднем по больнице больше всего понравился BBR. CDG лучше дефолтов, но увы, умеет одуревать и необоснованно душить скорость - и что хуже - не очень то вытряхиваясь из этого состояния за обозримое время.

Пролюбить 10% бандвиза если это дает взамен что-то внятное типа уменьшения бесящих полных клинчей линка? Окей! Пролюбить 70% бандвиза? Надолго? После какой-то редкой но меткой последовательности событий? Не, вот это - не окей, когда оно потом само не очень то и рекаверится. Может даже в теории это быть и не должно, а на практике это таки конкретный факап, нагибающий всю идею.

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

314. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:05 
> Я вообще-то на беспроводках тупо поэкспериментировал и посмотрел что лучше всего будет работать.

Люди давно поэкспериментировали в реальных и виртуальных условиях и составили карту, где BBR может выигрывать. Это линки с большим равномерно (упор на это слово) распределённым дропом с пингом выше 100 мс и скоростью физ. интерфейса 200+. В остальных случаях оно или равно Cubic или гораздо хуже его (линки со скоростью меньше 10 мс).

> Пролюбить 10% бандвиза если это дает взамен что-то внятное типа уменьшения бесящих полных клинчей линка?

Создать "шторм" затупов на 30+ секунд ни один из алгоритмов не может в принципе. Он может перейти в режим slow start (и это будет видно в статистике), но это как начать соединение заново (в плане вычерчивания графика скорости).

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

239. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:43 
> ... подобен разве что каре господня (-ня? -ней?), когда ваше терпение поджаривают на медленном огне, глумясь...

Вы чёрта в Господом даже умудрились спутать )))

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

296. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (128), 12-Июн-22, 18:06 
Раб божий, что ты забыл в интернете?
Ответить | Правка | Наверх | Cообщить модератору

307. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 12-Июн-22, 23:48 
> Раб божий, что ты забыл в интернете?

Он просто не понял мой тонкий отсыл что TCP поверх беспроводки - это просто срань господня. С BBR немного меньшая срань, но тоже далеко не предел мечтаний.

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

72. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от lockywolf (ok), 07-Июн-22, 15:05 
Всё это совершенные мелочи по сравнению с проблемами tcp.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

82. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +2 +/–
Сообщение от timur.davletshin (ok), 07-Июн-22, 16:12 
>  Всё это совершенные мелочи по сравнению с проблемами tcp.

Ограничения TCP известны и изучены. CUBIC/Reno и все эти SACK, ECN, гибридный старт годами отлажены и отполированы. А придуманный, пускай даже и в Google, BBR оказался переусложнённым и ничем не выдающимся с функциональной стороны. Зато с кучей новых проблем...

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

164. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –2 +/–
Сообщение от lockywolf (ok), 08-Июн-22, 09:43 
Отлажены, отполированы, но не работают.

И работать не будут. Пока промежуточные роутеры знают что-нибудь про состояние потока, они всегда будут что-нибудь портить.

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

166. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/–
Сообщение от timur.davletshin (ok), 08-Июн-22, 09:48 
> И работать не будут. Пока промежуточные роутеры знают что-нибудь про состояние потока,
> они всегда будут что-нибудь портить.

Простите, а какое отношение congestion control и selective acknowledgment имеют к роутерам? Просто интересуюсь, как вы представляете их работу.

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

185. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/–
Сообщение от lockywolf (ok), 08-Июн-22, 19:49 
>простите, а какое отношение congestion control и selective acknowledgment имеют к роутерам?
> Просто интересуюсь, как вы представляете их работу.

Если количество пакетов не совпадает с количеством ack'ов, один из NAT'ов по дороге с большой вероятностью дропает коннект.

Не говоря уже о том, что когда коннект выглядит нетипично на DPI, его приоритизируют ниже.

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

187. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 08-Июн-22, 20:26 
> Если количество пакетов не совпадает с количеством ack'ов, один из NAT'ов по
> дороге с большой вероятностью дропает коннект.

Мне вот тут интересно стало, а что такое в твоём понимании TCP window scaling?

> Не говоря уже о том, что когда коннект выглядит нетипично на DPI,
> его приоритизируют ниже.

Бред сивой кобылы. А приоритет выражается в понижении приоритета где? В изменении значения DSCP? Так его 4 из 5 провайдеров нижнего уровня вообще режут на первом же хопе.

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

190. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/–
Сообщение от lockywolf (ok), 09-Июн-22, 04:08 
> Мне вот тут интересно стало, а что такое в твоём понимании TCP
> window scaling?

Какая-то TCP опция, которую файрволы по дороге переписывают так, как им заблагорассудится.


> Бред сивой кобылы. А приоритет выражается в понижении приоритета где? В изменении
> значения DSCP? Так его 4 из 5 провайдеров нижнего уровня вообще
> режут на первом же хопе.

Детали работы DPI не публикуются. Эмпирически приоритизация очень хорошо заметна. Например, RTT на 22 и 443 порты в три раза меньше, чем на все остальные.

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

191. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 09-Июн-22, 06:25 
> Какая-то TCP опция, которую файрволы по дороге переписывают так, как им заблагорассудится.

Очень глубокое понимание работы протокола. Кстати, именно поэтому кол-во ACK'ов не совпадает с кол-вом пакетов, но на каждый пакет есть ACK! Представть, если бы в потоке в несколько десятков гигабит надо было тут же на каждый пакет отсылать ACK. Интересная бы производительность у протокола тогда была. Вот такая вот, на первый взгляд, противоречивая фигня. Вообще попробуй разобрать любую сессию в Wireshark ради примера. Сейчас многое изменилось со времён оригинального TCP и от учебника и википедии отличается )))

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

193. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 09-Июн-22, 06:36 
> которую файрволы по дороге переписывают так, как им заблагорассудится

Нет в абсолютно подавляющем большинстве.

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

195. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/–
Сообщение от lockywolf (ok), 09-Июн-22, 08:49 
>> которую файрволы по дороге переписывают так, как им заблагорассудится
> Нет в абсолютно подавляющем большинстве.

Sweet summer child. Всё, что можно переписать, переписывается. Не переписывается только то, что зашифровано, и именно поэтому quic по-умолчанию зашифрован.

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

196. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/–
Сообщение от timur.davletshin (ok), 09-Июн-22, 09:53 
> Sweet summer child. Всё, что можно переписать, переписывается.

А кроме как языком доказать сможешь? Ну, начнём с того же TCP window scaling (раз уж его упомянули). Я просто к чему это говорю, просто эта вещь ломает работу канала. Я даже и бородатый баг с разбором проблемы среди разработчиков ядра могу привести алаверды на доказательство твоего тезиса.

> Не переписывается только то, что зашифровано, и именно поэтому quic по-умолчанию зашифрован.

Что там кроме payload защифровано, сказочник? Там та же логика управления каналом, что и у TCP, только реализованo поверх UDP. Даже алгоритмы носят имена идентичные — CUBIC/Reno/BBR :)

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

202. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от lockywolf (ok), 09-Июн-22, 12:15 
> Что там кроме payload защифровано, сказочник? Там та же логика управления каналом,
> что и у TCP, только реализованo поверх UDP. Даже алгоритмы носят
> имена идентичные — CUBIC/Reno/BBR :)

21.1.1.4.  Parameter Negotiation

   The entire handshake is cryptographically protected, with the Initial
   packets being encrypted with per-version keys and the Handshake and
   later packets being encrypted with keys derived from the TLS key
   exchange.  Further, parameter negotiation is folded into the TLS
   transcript and thus provides the same integrity guarantees as
   ordinary TLS negotiation.  An attacker can observe the client's
   transport parameters (as long as it knows the version-specific salt)
   but cannot observe the server's transport parameters and cannot
   influence parameter negotiation.

   Connection IDs are unencrypted but integrity protected in all
   packets.

   This version of QUIC does not incorporate a version negotiation
   mechanism; implementations of incompatible versions will simply fail
   to establish a connection.


https://datatracker.ietf.org/doc/rfc9000/

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

211. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 09-Июн-22, 20:03 
На этом разговор и закончим, мне всё ясно.
Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

192. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 09-Июн-22, 06:30 
> Детали работы DPI не публикуются.

На этом можно было бы и закончить гадать...

> Например, RTT на 22 и 443 порты в три раза меньше, чем на все остальные.

А вы уверены, что софт, торчащий на тех портах, не генерирует задержку банально, которую вы упорно измеряете? И дело совершенно не в DPI, а в том, что задержка генерируемая Nginx, закономерно отличается от OpenSSH 😄

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

194. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/–
Сообщение от lockywolf (ok), 09-Июн-22, 08:46 
>> Детали работы DPI не публикуются.
> На этом можно было бы и закончить гадать...

Можете закончить, а мне нужно данные передавать.


>> А вы уверены, что софт, торчащий на тех портах, не генерирует задержку
> банально, которую вы упорно измеряете? И дело совершенно не в DPI,
> а в том, что задержка генерируемая Nginx, закономерно отличается от OpenSSH
> 😄

Я уверен, потому что я измерял задержку до RST заблокированных портов


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

197. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 09-Июн-22, 09:57 
> Я уверен, потому что я измерял задержку до RST заблокированных портов

Жду однострочник, с нетерпением.

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

198. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от lockywolf (ok), 09-Июн-22, 11:44 
>> Я уверен, потому что я измерял задержку до RST заблокированных портов
> Жду однострочник, с нетерпением.

Однострочники называются nping и hping3.

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

201. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 09-Июн-22, 12:05 
я так и знал 😆
Ответить | Правка | Наверх | Cообщить модератору

203. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/–
Сообщение от lockywolf (ok), 09-Июн-22, 12:16 
> я так и знал 😆

И что ты знал, болтун? Какая разница, чем слать пакеты?

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

259. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 11-Июн-22, 02:12 
> Однострочники называются nping и hping3.

Хорошие, кстати, однострочники если хочется потыкать пакеты палочкой в нестандартном виде.

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

146. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/–
Сообщение от Ivan_83 (ok), 08-Июн-22, 04:32 
Какие проблемы то?
В начале браузеростроители ограничивают количество TCP соединений типа чтобы сервера не перегружать, а потом гуглы от скуки изобретают квик, где типа по одному соединению всё передаётся, просто хитро мультиплексируется.
А суть то в том, что они эти самые 100500 TCP соединений упихнули внутрь своего udp, и теперь сравнивают и делают выводы.

На практике они конечно добились эффекта, но не за счёт мультиплексирования "каналов" внутри, а за счёт того что срезали все лишнее что им было не нужно и поменяв приоритеты.

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

И так во всём.

Но по сути их работа не добавила ничего нового и не создала новых ценностей.
Вот DHT, uTP - добавили и создали.

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

165. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от lockywolf (ok), 08-Июн-22, 09:45 
> Какие проблемы то?

Проблема в том, что скорость потока зависит от процента потерь пакетов (обратно) экспоненциально (тогда как должна линейно). А в мире есть миллиарды человек, которые сидят на соединениях, у которых 30-40% потерь -- норма жизни.

>Вот DHT, uTP - добавили и создали.

Они легко детектируются и банятся.

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

297. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (128), 12-Июн-22, 18:09 
> Они легко детектируются и банятся

Портить вообще довольно просто. На крайний случай можно кабель вырвать вместе с портом.

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

224. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от Аноним (-), 10-Июн-22, 17:32 
> А суть то в том, что они эти самые 100500 TCP соединений
> упихнули внутрь своего udp, и теперь сравнивают и делают выводы.

Ну так это...
- Пайплайнинг в тупом его виде HTTP/1.x жестко клевал по head of line blocking.
- Сетап новых соединений для уменьшения того эффекта может занять ощутимое время.

В целом вебпага грузилась как уг и приходилось делать костыли типа впихивания всех ассетов в 1 файл ради скорости.

> На практике они конечно добились эффекта, но не за счёт мультиплексирования "каналов"
> внутри, а за счёт того что срезали все лишнее что им
> было не нужно и поменяв приоритеты.

И еще убрав из процесса горе прожектеров с их congestion control непригодным для беспроводки.

> Те был TCP, потом с помощью TLS его сделали секурным и не сломали ничего.

Но roundtrip'ов добавили - так что вон то еще усугубилось. Оно наверное круто в датацентре с пингом до сервака менее 1мс, а если в поле с мобилкой с пингом 150 мс?!

> Но по сути их работа не добавила ничего нового и не создала новых ценностей.

Кроме того что это сможет наконец нормально работать по беспроводке.

> Вот DHT, uTP - добавили и создали.

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

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

78. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/–
Сообщение от Аноним (75), 07-Июн-22, 15:40 
У тех серьёзных ребят, у которых этот протокол внедрён и которым от него профит, это всё ведь не юзерспейсом обрабатывается, а специализированным аппаратно-программным комплексом.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

87. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 07-Июн-22, 16:33 
> У тех серьёзных ребят, у которых этот протокол внедрён и которым от
> него профит, это всё ведь не юзерспейсом обрабатывается, а специализированным аппаратно-программным
> комплексом.

Шта?


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

162. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –2 +/–
Сообщение от onanim (?), 08-Июн-22, 07:38 
какой-нибудь Intel Quick Assist
Ответить | Правка | Наверх | Cообщить модератору

163. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 08-Июн-22, 08:56 
> какой-нибудь Intel Quick Assist

Ты действительно полагаешь, что он имеет какое-то отношение к TCP/UDP или HTTP?

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

269. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от onanim (?), 11-Июн-22, 18:41 
>> какой-нибудь Intel Quick Assist
> Ты действительно полагаешь, что он имеет какое-то отношение к TCP/UDP или HTTP?

* какой-нибудь аналог Intel Quick Assist

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

108. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/–
Сообщение от Аноним (108), 07-Июн-22, 18:34 
> выносом операции ресэмплинга звука из ядра в pulseaudio.

Вообще-то ядерная часть ALSA никогда не умела делать ресэмплинг, этим всегда занималась юзерспейсная библиотека. Ядерная часть могла только переключить DAC в режим воспроизведения другого формата, но это возможно и через pulseaudio (но выключено по умолчанию).

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

113. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/–
Сообщение от timur.davletshin (ok), 07-Июн-22, 19:03 
Спасибо за поправку. Tы прав, это делала libalsa.
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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