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

Опубликована библиотека nghttp3 1.0 с реализацией протокола HTTP/3 , opennews (ok), 22-Окт-23, (0) [смотреть все] А управление потоком там Cubic по дефолту или что , timur.davletshin (ok), 10:23 , 22-Окт-23, (1) // Боже упаси от этого куска фекалий мамонта Это половина причин по которым оно во, Аноним (-), 18:01 , 22-Окт-23, (41) –1   // Вы только по воскресеньям обдолбанный или всегда В подавляющем большинстве реал, timur.davletshin (ok), 18:36 , 22-Окт-23, (49) +3   // Гугол в mainline ядра уже давно запушил нечто, что уже точно не v1 в его изначал, Аноним (-), 18:57 , 22-Окт-23, (51) –2   Как быстро ты порвался В ядре BBRv1, который НИ ОДНОЙ фичей не был расширен с н, timur.davletshin (ok), 21:29 , 22-Окт-23, (63)   Нате вам на двоих, эксперты И реализаций QUIC - уже более одной Вы за все гово, Аноним (-), 21:41 , 22-Окт-23, (64) –1   Chrome, neqo Firefox , nginx Человек упомянул про беспроводные сети Проблема в, timur.davletshin (ok), 21:50 , 22-Окт-23, (65) +1   А это все точно к либе nghttp можно интерфейсить как реализацию quick Или тут, Аноним (-), 18:06 , 23-Окт-23, (96)   Оно обязано мочь работать с ними, ибо нафиг бы такой Quic кому нужен был , timur.davletshin (ok), 18:40 , 23-Окт-23, (99)   Обязано работать вообще ничего не говорит о шедулинге пакетов и алгоритмах Та, Аноним (101), 18:42 , 23-Окт-23, (101)   https github com mozilla neqo tree main neqo-transport src cc - нужно ещё Поищ, timur.davletshin (ok), 18:45 , 23-Окт-23, (102)   Как вот это все относится к ВОН ТОЙ либе Она подразумевает, что вы принесете св, Аноним (-), 18:36 , 25-Окт-23, (137)   Сводные данные можешь поискать по Same Standards, Different Decisions A Study , timur.davletshin (ok), 19:10 , 23-Окт-23, (104) +1   Надо на jumbo frame переходить, но чувствую это ещё сложнее чем с IPv6 Хотя по и, Ivan_83 (ok), 22:24 , 23-Окт-23, (123)   Аха, сколько копий сломали о то, как приоритеты пакетов IP агрегировать в беспро, timur.davletshin (ok), 22:44 , 23-Окт-23, (124)   Jumbo это всё что больше 1536 или как то так В принципе вифи может лимитироват, Ivan_83 (ok), 23:36 , 23-Окт-23, (129)   Там ещё мини-джамбо был Позволяет на PPP делать 1500 MTU Его много кто умеет н, timur.davletshin (ok), 23:44 , 23-Окт-23, (131)   Так передача же не одним TCP ограничивается , Аноним (135), 03:54 , 24-Окт-23, (135)   Даже используя MTU 1500 в интернете можно покушать много интересных вещей Из-, Аноним (-), 18:40 , 25-Окт-23, (138)   Если у вас потеря пакетов идёт, на вайфай, то каналу связи полная Ж пришла Ника, Аноньимъ (ok), 22:56 , 22-Окт-23, (66) +2   Справедливо, т к контроль целостности и retransmit есть в WiFi, но дроп это не , timur.davletshin (ok), 23:12 , 22-Окт-23, (68)   Радио - нестабильная среда по определению Особенно если это все не в пустыне, в, Аноним (101), 18:40 , 23-Окт-23, (100) +1   Вайфай в зоне покрытия работает нормально, ад начинается только когда вы на гран, Аноньимъ (ok), 19:34 , 23-Окт-23, (105) –1   Управляет потоком тот, кто посылает данные Есть три подхода - по потерям, по за, timur.davletshin (ok), 20:16 , 23-Окт-23, (109) +1   Спасибо Как я и думал А попыток таки протоколов в которых сетевые узлы могли , Аноньимъ (ok), 20:59 , 23-Окт-23, (113)   Читай ниже про ECN , timur.davletshin (ok), 21:10 , 23-Окт-23, (115) +1   Есть ещё управление по задержкам Идея такая, что посылающий пакеты должен каким, timur.davletshin (ok), 20:39 , 23-Окт-23, (110) +1   поэтому придумали гибридные и двухрежимные алгоритмы Одни пытаются совмести, timur.davletshin (ok), 20:45 , 23-Окт-23, (111) +1   Я тут ошибся Такие алгоритмы называются двухрежимными , timur.davletshin (ok), 22:01 , 23-Окт-23, (118)   есть ещё ECN явное уведомление о перегрузке Это поле в пакете IP, которое, timur.davletshin (ok), 20:50 , 23-Окт-23, (112) +1   Вот Оно Насколько оно распространено вообще По идее, обязать всех это соблюдать, Аноньимъ (ok), 21:06 , 23-Окт-23, (114) +1   Зайди в консоль, сделай netstat -s где-то в самом низу есть статистика InNoECTPk, timur.davletshin (ok), 21:15 , 23-Окт-23, (116) +1   Суть разборок с Quic в том, что на самом деле Quic является обычным UDP UDP не , timur.davletshin (ok), 21:25 , 23-Окт-23, (117)   Ну тут такое себе В том смысле что нетфликсу с фрёй не пришлось городить юзерс, Ivan_83 (ok), 22:21 , 23-Окт-23, (122) +1   Ага, those were the days , timur.davletshin (ok), 23:06 , 23-Окт-23, (128)   А дело не в том, что его не шейпили А в том, что uTP первой версии было агресси, _oleg_ (ok), 14:36 , 10-Ноя-23, (148)   А эти речи выдают дилетанта Который про интерференцию, поляризацию, отраженку, , Аноним (-), 19:15 , 25-Окт-23, (139)   Нет, пользоваться вайфаем в яме, под водой, или в свинцовом бункере, я запретить, Аноньимъ (ok), 15:19 , 26-Окт-23, (144)   Расскажите это RTMP и HLS - , _oleg_ (ok), 14:48 , 10-Ноя-23, (149)   Если бы ты сказал LDPC, то этот тезис можно было бы принять Он чуть лучший резу, timur.davletshin (ok), 19:54 , 23-Окт-23, (106) +1   FEC это более generic название идеи И если кто не знал их можно комбинировать , Аноним (140), 19:31 , 25-Окт-23, (140)   А где вы к этому привыкли Я прямо хочу услышать у пана про организацию управлен, timur.davletshin (ok), 19:57 , 23-Окт-23, (107) +1   Ничем незамутнённый Cubic без гибридного старта Или тебе сорцев недостаточно Н, timur.davletshin (ok), 20:02 , 23-Окт-23, (108) +1   Сорцев, блин, чего Я посмотрел сорц сабжевой либы А там и сказано что flow co, Аноним (140), 19:36 , 25-Окт-23, (141)   FEC вас не спасёт, потому что пропускную способность нельзя взять из вакуума Ес, Аноним (135), 03:58 , 24-Окт-23, (136)   Как у вас все просто и универсально то А я думал что проблемы RF каналов крайне, Аноним (140), 19:38 , 25-Окт-23, (142)   Не важно где именно идёт потеря пакетов Кроме потери пакетов бывает ещё и RTT п, Ivan_83 (ok), 22:17 , 23-Окт-23, (121)   Не могу подтвердить, что его можно в кач-ве алгоритма общего применения использо, timur.davletshin (ok), 22:49 , 23-Окт-23, (125)   htcp работает на больших RTT чуть хуже hybla С hybla вроде нет проблем в локалка, Ivan_83 (ok), 23:38 , 23-Окт-23, (130)   Про htcp ничего не могу сказать, т к не гонял в разных сценариях А вообще поищ, timur.davletshin (ok), 23:47 , 23-Окт-23, (133)   CUBIC - фигня, он работает не плохо и не хорошо Гораздо интереснее hybla и htcp , Ivan_83 (ok), 22:12 , 23-Окт-23, (120)   // Тут дело не впроизводительности даже Первый критерий - агрессивность в самом пр, timur.davletshin (ok), 22:54 , 23-Окт-23, (126)   У кого что болит В RACK даже наоборот вроде выключал какую то фичу для учёта с, Ivan_83 (ok), 23:46 , 23-Окт-23, (132)   Я говорил лишь про общий случай, про менее агрессивную относительно Cubic альтер, timur.davletshin (ok), 23:52 , 23-Окт-23, (134)   В принципе, если узкое место в WAN, а на роутере AQM ECN, то любой алгоритм, н, timur.davletshin (ok), 23:00 , 23-Окт-23, (127)   можно без шифрования юзать для клиента будет проигрышь в скорости, а для сервера, Аноним (3), 10:51 , 22-Окт-23, (3) +1 // Нельзя , Аноньимъ (ok), 11:27 , 22-Окт-23, (5) –2 Нет SSL неотъемлимая часть http 3 спецификации, Zulu (?), 15:09 , 22-Окт-23, (22) +2 // Ну так никто не же не принуждает следовать ей для внутреннего пользования Емнип, Аноним (27), 15:48 , 22-Окт-23, (27) –3 // Для внутреннего использования оно нафиг не надо А http3 без quick - это внезапно, Аноньимъ (ok), 18:57 , 22-Окт-23, (52) А ассемблер без event loop это внезапно просто ассемблер , Аноним (55), 19:25 , 22-Окт-23, (55) –1 Сумасшедший без сумасшедшего дома внезапно просто сумасшедший , Аноньимъ (ok), 19:28 , 22-Окт-23, (57) Самурай без меча подобен самураю с мечом, но только без меча , rvs2016 (ok), 03:18 , 28-Окт-23, (145) Плохо, потому что если использовать этот протокол поверх Tor I2P или др то полу, Skullnet (ok), 03:23 , 23-Окт-23, (75) // Использовать Тор и жаловаться на оверхед странно Оверхед это его второе имя , Zulu (?), 12:46 , 23-Окт-23, (89) все новое почему-то поверх , а не в корне , Sw00p aka Jerom (?), 11:14 , 22-Окт-23, (4) +5 // Потому что всё происходит из единого корня - Адам Коммон , Аноним (11), 12:37 , 22-Окт-23, (11) // лол, кек, а че не Ивана , Sw00p aka Jerom (?), 16:15 , 22-Окт-23, (29) Синтетическая теория эволюции гласит, что все ныне живущие организмы имеют ровно, Аноним (12), 12:51 , 22-Окт-23, (12) // Ну то оно и видно, - только родственники и могут весь мир поджечь, OpenEcho (?), 14:40 , 22-Окт-23, (18) –1 Ждём новостей про очередную уязвимость, вызванную обращением к уже освобождённой, ИмяХ (?), 11:29 , 22-Окт-23, (6) –3 А почему не написано на безопастном Rust , beck (??), 12:06 , 22-Окт-23, (8) +9 // Хоть на брейнфаке пиши, я разрешаю , Аноним (9), 12:18 , 22-Окт-23, (9) // Вот обычный http прост и это как раз вполне реально , kusb (?), 12:31 , 22-Окт-23, (10) +1 // Да я бы не сказал, что multipart это прям просто-просто Особенно если писать не, Хру (?), 13:42 , 22-Окт-23, (13) На память об этом у нас полно прикольных атак типа request smuggling Когда все , Аноним (-), 15:27 , 22-Окт-23, (24) Есть, хоть и не завершена, но говорят, что вроде работает https crates io crat, НяшМяш (ok), 13:46 , 22-Окт-23, (14) –2 // А вот еще один адепт хруста который даже не пробовал устриц - но мнение имеет , Аноним (25), 15:29 , 22-Окт-23, (25) +1 // А онаним хотя бы сяшечный http3 уже попробовал, или тоже лишь бы экспертом побыт, НяшМяш (ok), 12:11 , 23-Окт-23, (85) Немножко беременна, Вы забыли заполнить поле Name (?), 23:59 , 22-Окт-23, (70) Наверное потому что не у всех складывается одолеть помесь брэйнфака с ЖС, OpenEcho (?), 14:50 , 22-Окт-23, (19) –1 // Поэтому именно таким кадрам нужно доверять написание критически важных библиотек, Аноним (21), 14:58 , 22-Окт-23, (21) +2 // Проблема не языках, - вообще А в банальном как ни странно, но даже людям работ, OpenEcho (?), 15:32 , 22-Окт-23, (26) –3 Да, очевидно, С - как раз свой инструмент для критически важных сетевых библиоте, Аноним (21), 16:06 , 22-Окт-23, (28) +1 Дак в расте все те же самые дыры Раст ведь это не настоящий ЯП, он транслируетс, Аноним (36), 17:41 , 22-Окт-23, (36) –2 поэтому настоящие советские программисты с профильным инженерным образованием сч, анонист (?), 17:49 , 22-Окт-23, (40) –2 Какого ещё диска Какое намагничивание Они лезвиями вырезают дырки в перфокартах, rvs2016 (ok), 03:21 , 28-Окт-23, (146) Пришло время офигительных историй , Аноним (21), 19:27 , 22-Окт-23, (56) +3 Опеннет-специалисты тм , чо , Аноним (81), 10:09 , 23-Окт-23, (81) +2 Можно мне показать хоть один мой пост где я воевал против раста Семантика языка, OpenEcho (?), 18:06 , 22-Окт-23, (42) –1 Да, да Достаточно попросить сишника сложить две строки - и наслаждаться цирко, Аноним (21), 18:21 , 22-Окт-23, (44) +2 Причем здесь сишники и ржавые Ты уверен что по русски понимаешь что написанно , OpenEcho (?), 18:34 , 22-Окт-23, (48) –2 сложение - это операция над числами любой язык который складывает строки - помо, Аноним (50), 18:48 , 22-Окт-23, (50) –5 Если ты тут не видтишь противоречия, то да, проблема в тебе , Советский инженер (ok), 16:22 , 22-Окт-23, (30) –1 А можно как Советский инженер - бывшему sоветскому инженеру обьяснить, а в чем, OpenEcho (?), 18:31 , 22-Окт-23, (47) а что так трудно понять что язык как раз то и поощпяет к разным стилям и способа, Советский инженер (ok), 09:17 , 23-Окт-23, (77) А противоречие то здесь при чем и я , OpenEcho (?), 17:57 , 23-Окт-23, (93) Я вот правильно понимаю, что ты тут делаеш морду кирпичем, и никак не хочешь при, Советский инженер (ok), 18:05 , 23-Окт-23, (95) снова никаких противаречий , Советский инженер (ok), 18:07 , 23-Окт-23, (97) ты хотя бы зайди на официальный сайт раста да посмотри на него прежде чем ерунду, анонист (?), 17:47 , 22-Окт-23, (39) // ерунда - это обилие значков которая больше похоже на опкоды чем на поня, OpenEcho (?), 18:27 , 22-Окт-23, (45) –1 Даже не знаю где вы такое видели , Аноним (55), 19:16 , 22-Окт-23, (54) –1 рядом даже не лежали , Sw00p aka Jerom (?), 19:30 , 22-Окт-23, (58) +1 Так может есть некая причина, зачем все эти знаки добавили Или у вас традиционн, Аноним (21), 19:39 , 22-Окт-23, (60) +1 Но и ты нам тоже не обьяснишь , scriptkiddis (?), 21:16 , 22-Окт-23, (62) –1 Cobol PL 1 давно изобрели, но что-то как-то они не сильно популярны , Советский инженер (ok), 09:19 , 23-Окт-23, (78) Это Cobol то не популярен А что-ж тогда после стольких десятилетий навалом в, OpenEcho (?), 18:00 , 23-Окт-23, (94) а навалом это сколько в процентах а ты лично хоть одного живого программитса н, Советский инженер (ok), 18:09 , 23-Окт-23, (98) Выучить конкретно синтаксис - задача от силы на неделю для любого системного про, Аноним (81), 10:28 , 23-Окт-23, (82) лол, кек, ну вот асм как видно уделал всех, опкодов интел архитектуры свыше 1к, , Sw00p aka Jerom (?), 10:47 , 23-Окт-23, (83) Так об этом же писали ещё лет 25 назад в Шутке создателей Си и Юникс Затем , rvs2016 (ok), 03:27 , 28-Окт-23, (147) Потому что его авторам плевать на безопасность Дареному коню в зубы не смотрят , Аноним (21), 14:57 , 22-Окт-23, (20) +2 // Ну вот ты и используй какое-то куищще от клаудспайвари А как по мне - чтобы име, Аноним (25), 16:55 , 22-Окт-23, (33) –3 Потому, что на Расте уже написано , Аноним (32), 16:47 , 22-Окт-23, (32) +2 Потом освоят и перепишут , Bob (??), 09:34 , 23-Окт-23, (79) –1 Всё равно все будут использовать libcurl Она и 1, и 2, и 3 поддерживает, и до к, Аноним (15), 14:01 , 22-Окт-23, (15) –3 // ну у этой есть весомые преимущества -- через нее работает libcurl, Аноним (16), 14:06 , 22-Окт-23, (16) +4 Есть там и маленький патчик от меня Мелочь, а приятно , Zulu (?), 15:09 , 22-Окт-23, (23) –1 // Спасибо вам, сэр , Аноним (25), 16:42 , 22-Окт-23, (31) +2 readme поправил небось , Вы забыли заполнить поле Name (?), 00:00 , 23-Окт-23, (71) –1 // Нет, но не сильно круче Потому и написал маленький Прекрати портить мне мину, Zulu (?), 01:02 , 23-Окт-23, (73) большие проекты на сишке это ад раст реально тема, проигрался тут в playground,, анонист (?), 17:44 , 22-Окт-23, (37) –1 // Большие проекты надо сравнивать с большими , Вы забыли заполнить поле Name (?), 22:09 , 23-Окт-23, (119) Не понимаю где этот HTTP 3 вообще юзается https cloudflare-quic com Тут показы, Skullnet (ok), 02:59 , 23-Окт-23, (74) // Пообновляй страницу без Shift У меня не с первого раза грузит по quic Но раза с, Аноним (135), 09:40 , 23-Окт-23, (80) // Я уже всё перепробовал Вообще результата ноль , Skullnet (ok), 13:25 , 23-Окт-23, (90) При первом обращении всегда идет http 1 1 если нет prior knowledge, это отдельн, Zulu (?), 12:42 , 23-Окт-23, (87) +1 Это что теперь Если я пишу клиента, то мне нужно уметь ходить через HTTP 1 1, H, Страдивариус (?), 11:15 , 23-Окт-23, (84) –1 // Можешь поддерживать только один из протоколов http 1 1 , потому как http 2 и ht, Zulu (?), 12:44 , 23-Окт-23, (88) // libcurl - это довольно упоротая либа, которая многие вещи прячет в себя и не даё, Страдивариус (?), 14:12 , 23-Окт-23, (91) // Вот кстати не скажите На удивление libcurl можно как по простому и высокоуровне, Аноним (143), 21:28 , 25-Окт-23, (143) 1,3,4,6,8,15,23,37,74,84

Сообщения

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

	41. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	–1 +/–
	Сообщение от Аноним (-), 22-Окт-23, 18:01
	> А управление потоком там Cubic по дефолту или что? Боже упаси от этого куска фекалий мамонта. Это половина причин по которым оно вообще существует. Если в линух еще можно протолкать более вменяемые планировщики типа bbr, делающие что-то более разумное на беспроводке - то вот в винду это прожать даже гуглу было слабо. И это проблема. Потому что TCP на lossy, нестабильном или intermittent линке (например в едущем транспорте) - это полная задница.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+3 +/–
	Сообщение от timur.davletshin (ok), 22-Окт-23, 18:36
	Вы только по воскресеньям обдолбанный или всегда? В подавляющем большинстве реализаций Quic используется Cubic. А от BBR давно отказался даже Google (в Chrome тоже Cubic, в Mozilla Cubic). BBRv1 коряв, не дружит с ECN, катастрофически проседает на WiFi из-за того, что pacing мешает агрегации MTU, и только Анонимусы всё ещё его педалируют.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	–2 +/–
	Сообщение от Аноним (-), 22-Окт-23, 18:57
	> Вы только по воскресеньям обдолбанный или всегда? В подавляющем большинстве реализаций > Quic используется Cubic. А от BBR давно отказался даже Google (в > Chrome тоже Cubic, в Mozilla Cubic). BBRv1 коряв, не дружит с > ECN, катастрофически проседает на WiFi из-за того, что pacing мешает агрегации > MTU, и только Анонимусы всё ещё его педалируют. Гугол в mainline ядра уже давно запушил нечто, что уже точно не v1 в его изначальном виде. И в либах от гугли что угодно но не кубик в чистом виде. А ваш кубик в его изначальном варианте - и как он в ядре только на помойку вынести. Он на wi-fi при малейшей потере пакетов падает до диалапной скорости. И на мобильных линках - тоже. А если это на ходу, когда соты то видно то нет - там вообще скорость начинает в байтах в час измеряться. С утилизацией канала в 1% уже за спасибо. Гугл bbr не от хорошей жизни сделал, и если отпустить ручник, его патчили и в ядре, и сам гугл переделывал его у себя. И если гугл "отказался" от него - то как он тогда сделал v2 и v3?!
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 22-Окт-23, 21:29
	Как быстро ты порвался. В ядре BBRv1, который НИ ОДНОЙ фичей не был расширен с начального релиза. А ненавистный Cubic, например, тем же гибридным стартом обзавёлся. BBRv2 не выпущен и скорее всего не будет даже (ткни меня в репу с BBRv3). В Quic именно что Cubic везде, притом, местами урезанный (кровь и слёзы). Мало того, Quic сливает везде TCP с тем же алгоритмом (управлять из user space трафиком накладнее). Про то, что Cubic скатывается до процентов в условиях WiFi - ЛПП. Наоборот это BBR сливает. Если мозгов не хватает самому потестировать (в драйвере Atheros есть удобная статистика по кол-ву агрегированных MTU), то можешь поискать бенчмарки. ПыСы: по бенчмаркам (и не только моим) на вафле (из того, что есть в стоке) вообще неожиданно лучше всех в категории "золотая середина между задержкой, скоростью и дропом" показывает себя старый Yeah.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	–1 +/–
	Сообщение от Аноним (-), 22-Окт-23, 21:41
	> It relies on an underlying QUIC stack for flow control and connection management. Нате вам на двоих, эксперты! И реализаций QUIC - уже более одной. Вы за все говорите или за какую-то конкретную? Если да - какую именно? Урл сорца? И при чем тут какие-то статистики каких-то атеросов вообще?!
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от timur.davletshin (ok), 22-Окт-23, 21:50
	Chrome, neqo (Firefox), nginx. Человек упомянул про беспроводные сети. Проблема в том, что это именно то место, где BBR сливает. Суть проблемы в моём первом посте - pacing ухудшает процент агрегированных MTU (MTU в беспроводных сетях больше, поэтому надо бы объединять Ethernet MTU ~1500).
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Аноним (-), 23-Окт-23, 18:06
	> Chrome, neqo (Firefox), nginx. А это все точно к либе nghttp можно интерфейсить как "реализацию quick"? Или тут как обычно на опеннете - лишь бы блеснуть, не важно чем?
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 18:40
	> А это все точно к либе nghttp можно интерфейсить как "реализацию quick"? > Или тут как обычно на опеннете - лишь бы блеснуть, не > важно чем? Оно обязано мочь работать с ними, ибо нафиг бы такой Quic кому нужен был.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Аноним (101), 23-Окт-23, 18:42
	> Оно обязано мочь работать с ними, ибо нафиг бы такой Quic кому нужен был. "Обязано работать" вообще ничего не говорит о шедулинге пакетов и алгоритмах. Так что пруфы на сорцы где вот именно эти с именно вон тем и где там именно кубик. Хочется на это лично профтыкать.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 18:45
	> "Обязано работать" вообще ничего не говорит о шедулинге пакетов и алгоритмах. Так > что пруфы на сорцы где вот именно эти с именно вон > тем и где там именно кубик. Хочется на это лично профтыкать. https://github.com/mozilla/neqo/tree/main/neqo-transport/src/cc - нужно ещё? Поищи там гибридный старт в исходниках. Графиков накинуть, что такое гибридный старт и зачем он нужен?
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Аноним (-), 25-Окт-23, 18:36
	> https://github.com/mozilla/neqo/tree/main/neqo-transport/src/cc - нужно ещё? > Поищи там гибридный старт в исходниках. Графиков накинуть, что такое гибридный старт > и зачем он нужен? Как вот это все относится к ВОН ТОЙ либе? Она подразумевает, что вы принесете свою реалищацию QUIC под нее. Эта либа вообще умеет вон тот код использовать как underlying transport, интерфейсясь к нему? Чтобы весь этот спич стоил байтов на него? Если да - пруф в сорце сабжевой либы, с точностью до file:line? Дело в том что вопрос flow control, соответственно, вообще делегирован тому компоненту который QUIC уровнем ниже для сабжа обеспечивает - и в него - соответственно - не входит вообще. Ну вот такая вот экспертиза уровня опеннет получается, особено если хотя-бы ридми и сорц либы еще и немного колупнуть, вместо того чтобы верить "экспертам" надувающим щеки с умным видом.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 19:10
	> "Обязано работать" вообще ничего не говорит о шедулинге пакетов и алгоритмах. Так > что пруфы на сорцы где вот именно эти с именно вон > тем и где там именно кубик. Хочется на это лично профтыкать. Сводные данные можешь поискать по "Same Standards, Different Decisions: A Study of QUIC and HTTP/3 Implementation Diversity".
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	123. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Ivan_83 (ok), 23-Окт-23, 22:24
	Надо на jumbo frame переходить, но чувствую это ещё сложнее чем с IPv6. Хотя по идее всё новое оборудование это уже умеет и максимум нужно просто галочкой включить или не выключать.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	124. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 22:44
	> Надо на jumbo frame переходить Аха, сколько копий сломали о то, как приоритеты пакетов IP агрегировать в беспроводные MTU и прочие нюансы... а тут 9000 MTU подвезли, который сильно больше самого большого беспроводного MTU )))
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Ivan_83 (ok), 23-Окт-23, 23:36
	Jumbo это всё что больше 1536 или как то так :) В принципе вифи может лимитировать пакеты размером своего MTU, при согласовании того же TCP это легко подобрать.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 23:44
	Там ещё мини-джамбо был. Позволяет на PPP делать 1500 MTU. Его много кто умеет на самом деле. Я просто подозреваю, что провайдеры даже об этом не очень подозревают.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Аноним (135), 24-Окт-23, 03:54
	Так передача же не одним TCP ограничивается.
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

	138. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Аноним (-), 25-Окт-23, 18:40
	> Надо на jumbo frame переходить, но чувствую это ещё сложнее чем с IPv6. Даже используя MTU = 1500 в интернете можно покушать много интересных вещей. Из-за энкапсуляции, тоннелей, и вот этого всего. И вот юзает юзерь PPPoE какой, ему несколько байтов на хидеры - тынц. А пакет на 1500 байтов к нему соответственно - вообще никак. И начинаются чудеса, когда интернет вот тут ну не то что совсем не работает - но некоторые сайты, думавшие примерно так же, толи не грузятся, толи грузятся по килобайту в час, а все потому что oversized пакеты по пути кто-то убивает. > Хотя по идее всё новое оборудование это уже умеет и максимум нужно > просто галочкой включить или не выключать. Когда в цепочке из кучи этого оорудования попадется 1 не умеющий так вредитель - будет воооон то. И саппорт гениуса умрет жестокой смертью под напором злых хомячков.
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

	66. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+2 +/–
	Сообщение от Аноньимъ (ok), 22-Окт-23, 22:56
	> Он на wi-fi при малейшей потере пакетов Если у вас потеря пакетов идёт, на вайфай, то каналу связи полная Ж пришла. Никакие чудо алгоритмы транспортного уровня это никак не вылечат. Вам нужно ждать подтверждение доставки покета, и нужно перепосылать всё что не дошло. И подверждение тоже может не дойти.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	68. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 22-Окт-23, 23:12
	Справедливо, т.к. контроль целостности и retransmit есть в WiFi, но дроп это не лечит. Описываемый вами же сценарий тоже маловероятен, т.к. сейчас есть SACK почти у всех и подтверждения и перепосылки стали "дешевле", чем без оного расширения.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от Аноним (101), 23-Окт-23, 18:40
	> Если у вас потеря пакетов идёт, на вайфай, то каналу связи полная Ж пришла. Радио - нестабильная среда по определению. Особенно если это все не в пустыне, верхом на роутере. Особенно если еще и двигаться или вертеть гаджет в пространстве. Там столько факторов что уповать на стабильность этого может оптимист или дилетант. А в мобильном интернете при езде соты появляются и пропадают с изрядной скоростью, уровень сигнала дико прыгает, есть зоны с отсутствующим покрытием, всякие мосты, тоннели, низины. В свете этого хотелось бы увидеть пруф что кто-то и правда додумался до кубика в чистом виде в QUIC. > Никакие чудо алгоритмы транспортного уровня это никак не вылечат. FEC эти чудо-алгоритмы называются. Это даже работает. До известного предела, конечно. Этот предел можно расширять, достаточно произвольно, накидывая больше избыточности. Дубовый пример: если слать каждый пакет 3 раза, даже если 1-2 пакета изредка выпадет - ну и что? То что это оверхед создает - другой вопрос. В более продвинутом FEC оверхеда меньше. > И подверждение тоже может не дойти. В случае FEC с этим даже можно жить. Если зайти на гитхаб и спросить что-то типа FEC VPN можно найти довольно странные штуки для работы по бельевым веревкам, в основном китайские, они там GFW красиво дурят. Заодно - вот - разработав довольно продвинутые протоколы. Multi-path + FEC это немного повыше уровня технологий к которому вы привыкли. А так можно было. Гугол тоже может в нормальных инженеров поэтому в QUIC была как минимум опция FEC. Стала ли она часть стандарта или это WIP до сих пор - хз.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	105. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	–1 +/–
	Сообщение от Аноньимъ (ok), 23-Окт-23, 19:34
	Вайфай в зоне покрытия работает нормально, ад начинается только когда вы на границу выходите, и всё  разваливается. Но вайфай и не для того вообще... Тут кажется был раньше человек которые эти вайфаи для пром применения настраивал, от стадионов до совсем извращённой ерундой в промышленности. Мобильные сети да, в них всякая жесть бывает. Но я бы больше с ней работал через разработку приложений устойчивых к дисконекту, чем пытаясь изобрести особый стриминговый протокол устойчивый к такой жести. Переключение между сотами у вас всерано не каждую секунду происходит. > А так можно было. И это прекрасно. > Гугол тоже может в нормальных инженеров Последнее время не очень. > Радио - нестабильная среда по определению. Особенно если это все не в пустыне, верхом на роутере. Особенно если еще и двигаться или вертеть гаджет в пространстве. Там столько факторов что уповать на стабильность этого может оптимист или дилетант. Стабильность обеспечивают протоколы ниже сетевого. Потеря пакета на сетевом уровне это ситуация, в идеальном мире, всегда нештатная, независимо от среды. Хотя конечно бывают нюансы. А как вообще управление пропускной способностью происходит? По хорошему роутер должен сообщать источникам пакетов о том что у него затык, да и свитч должен, хотя к нему спроса меньше, ну не может такого быть чтобы не было такого механизма?
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 20:16
	> А как вообще управление пропускной способностью происходит? По хорошему роутер должен сообщать > источникам пакетов о том что у него затык, да и свитч > должен, хотя к нему спроса меньше, ну не может такого быть > чтобы не было такого механизма? Управляет потоком тот, кто посылает данные. Есть три подхода - по потерям, по задержкам и по ECN. Посылающий не знает пропускной способности полосы и шлёт (я тут упрощаю, т.к. механизмы SACK и контроль последовательности по TS чуток изменили, улучшили ситуацию)... и шлёт пакетов заведомо больше, чем может линия принять. Определённый алгоритм (по определённой кривой) увеличивает кол-во посылаемых данных (CWND - серия пакетов, на которые приходит один ACK, подтверждающий получение), пока не получится первый дроп. Тут мы делаем оговорку о том, кто делает этот дроп. Т.к. кабель обычно ничего не теряет. Дропает пакеты промежуточное сетевое устройство (может быть роутером). Как только у него переполняется буфер приёма пакетов, он начинает дропать вновь прибывающие. Это random early detection (RED). Есть разные алгоритмы того, что дропать, но смысл в том, что что-то должно быть убрано, чтобы освободить буфер. Возвращаемся к посылающему пакеты. Как только посылающий не получает подтверждения пакета, то он должен его вновь послать и, заодно, уменьшить кол-во посылаемых данных, т.к. сеть не готова принять такое их кол-во. Потом он вновь начинает посылать их больше, пытаясь понять, вдруг пропускная способность увеличилась (например, закрылись конкурирующие потоки). Поэтому в классике график отдельного соединения выглядит как "пила" в пике которых происходят дропы. Дропы - это обязательный элемент такого алгоритма. Cubic является его улучшенной реализацией (кубик он из-за кубической кривой, по которой увеличивается кол-во передаваемых пакетов)...
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Аноньимъ (ok), 23-Окт-23, 20:59
	Спасибо! Как я и думал... А попыток таки протоколов в которых сетевые узлы могли бы объясняться не было?
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 21:10
	> Спасибо! Как я и думал... > А попыток таки протоколов в которых сетевые узлы могли бы объясняться не > было? Читай ниже про ECN.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 20:39
	Есть ещё управление по задержкам. Идея такая, что посылающий пакеты должен каким-то хитрым способом определить стандартную RTT для соединения и увеличивать CWND до тех пор, пока она, эта задержка, из-за заполнения буферов на промежуточных устройствах не начнёт увеличиваться. Некий предел превышен - уменьшаем кол-во посылаемых данных и так далее по кругу. Всё то же самое, только без дропов. Для определения стандартной RTT используются разной степени продвинутости low-pass фильтры для отсеивания случайного "шума". Всё бы ничего, но в момент, когда первый алгоритм такой был уже придуман, было уже управление потоком по дропам (я забыл сказать, что вообще управление потоком вообще не сразу появилось, первые интернеты были вообще без управления потоком в современном понимании). А управление по дропам более агрессивное и ВСЕГДА побеждает алгоритм по задержкам. Один алгоритм душит другой до почти полного зависания проигравшего. Примите, распишитесь...
	Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

	111. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 20:45
	... поэтому придумали гибридные и двухрежимные алгоритмы. Одни пытаются совместить два сигнала, другие (гибридные) изначально работают в режиме по задержкам, но как только определяют, что есть конкурирующий агрессивный алгоритм, то переключаются в агрессивный режим.
	Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

	118. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 22:01
	> ... другие (гибридные) Я тут ошибся. Такие алгоритмы называются двухрежимными.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 20:50
	... есть ещё ECN (явное уведомление о перегрузке). Это поле в пакете IP, которое может передавать два сигнала (на самом деле три, но третий условно принимается равным второму, хотя есть давняя идея заюзать его для более полезных вещей) - флаг поддержки ECN и флаг перегрузки. Логика работы такая, что промежуточное устройство, когда у него буфер переполнен выше некоторого порогового значения, вместо дропа пакетов, выставляет флаг, сигнализирующий о перегрузке, и обычно переправляет пакет далее. Отправляющая сторона, получив такой сигнал, обязана уменьшить CWND. В идеале ECN должен мочь работать с любыми другими алгоритмами и это был бы идеальный вариант, который с одной стороны не теряет пакеты, а с другой стороны обеспечивает разумную задержку, а не конскую, какая является чертой алгоритмов, использующих потерю пакетов в кач-ве сигнала о перегрузке. На практике не все так радужно. Хотя ECN уже много лет, новый BBR не умеет в ECN и воспринимает их как обычные пакеты без сигнала о перегрузке. Финиш с этим бобиком. Второй косяк уже линуксовый. Линукс умеет в ECN туеву кучу лет, но до сих пор по дефолту это работает только в одну сторону. Т.е. никак, т.к. поддержка должна быть с двух сторон. Даже Apple на всех своих устройствах уже давно включила ECN.
	Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

	114. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от Аноньимъ (ok), 23-Окт-23, 21:06
	Вот. Оно! Насколько оно распространено вообще? По идее, обязать всех это соблюдать, а тех кто не соблюдает резать агрессивно дропами...
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 21:15
	> Вот. Оно! > Насколько оно распространено вообще? Зайди в консоль, сделай netstat -s где-то в самом низу есть статистика. InNoECTPkts - это кол-во пакетов от соединений, где нет поддержки ECN (напомню, что обе стороны должны её иметь), InECT0Pkts и InECT1Pkts - это кол-во пакетов соединений, где есть поддержка ECN (это тот сигнал, которых на самом деле два). InCEPkts - это кол-во пакетов, в которых было выставлен флаг, что соединение перегружено. Обычно их меньше всего. Процент можешь посчитать поделив сумму InECT0Pkts и InECT1Pkts на InNoECTPkts. У меня около 30 процентов. > По идее, обязать всех это соблюдать, а тех кто не соблюдает резать > агрессивно дропами... Обязать ничего никого нельзя. Есть куча legacy устройств, где поддержки никогда не будет. Просто они будут слать данные дальше, до первого дропа. Что соответсвует той логике, о которой ты и говорил.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 21:25
	> Вот. Оно! > Насколько оно распространено вообще? > По идее, обязать всех это соблюдать, а тех кто не соблюдает резать > агрессивно дропами... Суть разборок с Quic в том, что на самом деле Quic является обычным UDP. UDP не умеет на уровне ядра ни в состояние соединения (т.е. не бывает "установленного" UDP соединения), ни в управление потоком (алгоритм управления потоком реализован в TCP на уровне ядра). Поэтому Quic реализует в простанстве пользователя свой алгоритм управления потоком, как ему хочется. А т.к. управляет этим отсылающая данные сторона, то условный Google или Cf могут менять эти алгоритмы даже ничего не отдавая в ядро Linux (серверная сторона у них закрытая). Изначально Quic проектировался под алгоритм BBR (гибридный первого рода, совмещает оба сигнала для определения перегрузки и периодически пытается слать больше, для определения освободившейся полосы пропускания). Но потом, что-то пошло не так в полевых испытаниях, когда алгоритм был включен в ядро Линукс. Алгоритм оказался излишне агрессивным даже по отношению к базирующимся на дропе Cubic и Reno (был дефолтом до Cubic, те же яйца, менее агрессивная кривая). Вопреки утверждениям Анонима, сабж давно не в тренде. Его убрали из дефолтов. Google запилил на Github BBRv2 c исправлениями нареканий. Разработка вроде как в фазе где-то между альфой и бетой. Но на таком этапе она уже года три и конца этому не видно. Но самый эпичный трабл Quic даже не в том, что убрали упоминание BBR из стандарта, а в том, что алгоритм управления потоком - это алгоритм с фиксированным временем на отклик. Т.е. по факту это алгоритм реального времени, который меряет каждый раз пакетики, буферы, сигналы по много-много-много раз в секунду. А в пространстве пользователя этот алгоритм вынужден теперь конкурировать с обычными пользовательскими приложениями и затупы в десятки и даже сотни миллисекунд там являются нормальным делом. Это примерно как с Wireguard переходить назад на OpenVPN. Но у здешних гореанонимов логика дальше собственного носа не работает. Переход на внутриядерное управление в случае с VPN это большой шаг вперёд... но и переход на управление в пространстве пользователя тоже может быть большим шагом вперёд, если это предлагает уважаемая всеми мегакорпорация... ЗЫ, не надо думать, что Quic является мегановой идеей. Используемый в Bittorrent протокол uTP является тем же самым - это UDP + кастомизированный алгоритм управления потоком. Только там используется LEDBAT - относительно неагрессивный алгоритм, который уступает дефолтным (Reno и Cubic) бОльшую часть полосы. У них это не с первого раза получилось, но Аноним этого не помнит. Провайдеры отвалили порядочную кучу кирпичей после первого релиза оного и всячески пытались душить uTP.
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	122. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от Ivan_83 (ok), 23-Окт-23, 22:21
	> А т.к. управляет этим отсылающая данные сторона, то условный Google или Cf могут менять эти алгоритмы даже ничего не отдавая в ядро Linux (серверная сторона у них закрытая). Ну тут такое себе :) В том смысле что нетфликсу с фрёй не пришлось городить юзерспейс чтобы не делится ядерными патчами :) Про uTP - да, забавно тогда было :) Некоторые провайдеры вдруг узнали что UDP тоже надо шейпить :)))))
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 23:06
	> Про uTP - да, забавно тогда было :) > Некоторые провайдеры вдруг узнали что UDP тоже надо шейпить :))))) Ага, those were the days )))
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от _oleg_ (ok), 10-Ноя-23, 14:36
	> Про uTP - да, забавно тогда было :) > Некоторые провайдеры вдруг узнали что UDP тоже надо шейпить :))))) А дело не в том, что его не шейпили. А в том, что uTP первой версии было агрессивное говно и просто забивало канал. Оно не реагировало на дропы и задержки - есть задержки и дропы, значит херачим ещё больше! Тут бесполезно шейпить. Блочить сразу нахер и делов.
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

	139. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Аноним (-), 25-Окт-23, 19:15
	> Вайфай в зоне покрытия работает нормально, ад начинается только когда вы на > границу выходите, и всё  разваливается. Но вайфай и не для того вообще... А эти речи выдают дилетанта. Который про интерференцию, поляризацию, отраженку, и прочие глупости типа SNR не слышал, и даже просто врубить нормальный показометр, хотя бы уровня "iw dev wlan0 station dump" в цикле - явно не допер. В атерос дебаге есть и поинтереснее если знать на что смотреть, но для начальной оценки хватит и вон того. Про то чтобы попытаться закартировать как поле выглядит, и тем более что случается если еще и вертеть гаджет или двигаться с ним - речь, видимо, совсем не шла. Иначе вы бы побоялись выдавать такие заявления. Потому что уровень сигнала может измениться в десятки раз от перемещения на считанные сантиметры, длина волны у вафли такая. С соответствующим улучшением или ухучшением линка. А учитывая что руки юзера не особо прозрачные и параметры антенны гаджета сбивают, даже просто перехватить гаджет в руках может радикально изменить всю картину. Представляете, руки могут например резонансную частоту антенны увести хзкуда - ну а как работает антенна резонирующая на частоте отличной от рабочей? Правильно - крайне голимо. Это довольно странно для человека знающего про статистику атероса. Видимо, прочли ридмишку от такого же эксперта в интернете, уперлись рогом в 1 параметр и айда в интернете бред форсить. А почитать теорию коммуникаций, азы RF и проч - да, блин, это не ридмишка на 10 минут... А зона покрытия - это такое весьма эфемерное и абстрактное. Ну то-есть можно задать максимум таймаута соответствующий энному расстоянию от AP, и все что сильно дальше будет отпадать по таймаутам. Но выбор между хреновым линком и никаким - такое себе, так что это редко вклчают. А в типовой хате можно найти мемало мертвых зон и неудачных локаций, где когда я сижу на диване вот так, путь от меня до роутера для сигнала - метр бетона. И никакая магия через метр бетона 2.4 и тем более 5 гигагерц не протолкнет. В лучшем случае немного пересесть, или может отраженка какая поймается другой антенной, если она есть, что для мелкого гаджета совсем не факт, но... всегда есть риск что вот тут линк просто возьмет и просто просядет в хлам. А потом отплющится. > Тут кажется был раньше человек которые эти вайфаи для пром применения настраивал, > от стадионов до совсем извращённой ерундой в промышленности. У вас дома этого человека явно не было - и его оборудования тоже. И инфраструктуры под вот это все, с именно эн грамотно размещенных в правильных местах точек - у вас тоже нет. И в планирование радиоканалов вы точно не вхожи. Иначе зассали бы вон то выдавать, понимая что стадион и дом это 2 довольно больише разницы. Вон то подразумевает и правда сервировку ограниченного сегмента, бэкбон, а также нехилое изучение того что получилось оперируя -dBm и числом клиентов которые туда или сюда цепляются. В вафле так то даже есть технологии для роуминга клиентов на соседнюю точку доступа с тем же SSID. Но вы врядли этим всем пользуетесь, это специфичного сетапа требует. И не все клиенты и точки это умеют и тем более на 100% интероперабельны. > Мобильные сети да, в них всякая жесть бывает. Но я бы больше > с ней работал через разработку приложений устойчивых к дисконекту, Как вы это себе представляете для допустим видео с ютуба? Поток либо идет, либо нет. И если канал используется на единицы процентов по причине "TCP тупит" вот у гугла и возникает желание улучшить это состояние дел. А пропатчить TCP в винде они совсем отчаялись. В результате море претензий к их хостингу на ровном месте, им это не надо - так что вот вам UDP, где гугл сделает так как сочтет нужным для себя. На спрашивая вас и майкрософт вообще. > чем пытаясь изобрести особый стриминговый протокол устойчивый к такой жести. Народ едущий в транспорте совсем не прочь посмотреть вон тот клип. Предлагается им рассказать что это работать не должно, пусть TCP тупит во имя луны? Это не путь гугла, там могут и нанять нормальных инженеров. Оттуда же и респин дизайна bbr когда он пытается детектировать подобные вещи и не считать это за вот именно перегруз. Остуствие соты - это не перегруз сети. Это мертвая зона покрытия, временная потеря линка и проч. > Переключение между сотами у вас всерано не каждую секунду происходит. В быстро едущем транспорте может быть нечто довольно близкое к этому. Если попалась мертвая зона где сигнала нет - то чего? Хоть тресни но ничего не пошлешь и не примешь. И если TCP начинает брыкаться на это таймаутами по минуте - возникает спрос на то чтобы его уйти, раз это фиксу не подлежит. >> Гугол тоже может в нормальных инженеров > Последнее время не очень. И все же остатки былой роскоши - есть. И они выдают более разумные спичи чем вот тут попалось. > Стабильность обеспечивают протоколы ниже сетевого. Если демодуляция при энном соотношении синал-шум лажается, никакие протоколы с этим таки ничего сделать не могут. А вон там в низине - сигнала можно считать что совсем нет. Потому что радиоволны на тех частотах летают более-менее по прямой, как свет, через некоторые препятствия они проходят - но ослабляясь, и вот именно земля, особенно мокрая, к таким препятствиям не относится. И на этот эффект даже дома можно нарваться, там все "планирование" сводится к относительно удачному размещению роутера в не очень глупом месте. А уж на улице с рельефом "уж какой есть" - даже профессионалам много головной боли с дырами в покрытии. А если еще и ехать, там еще вопрос как алгоритмы БС и конкретной мобилы дружить будут. Что угодно может быть. > Потеря пакета на сетевом уровне это ситуация, в идеальном мире, всегда нештатная, > независимо от среды. Хотя конечно бывают нюансы. Если некто вон там на авто в тоннель заскочил - ну и где он сигнал возьмет? Не пробивают радиоволны почтенные слои земли. А ставить соты и излучающие кабели под каждую плевую трубу и мост - никаких денег не хватит. > А как вообще управление пропускной способностью происходит? По хорошему роутер >  должен сообщать источникам пакетов о том что у него затык, да и свитч > должен, хотя к нему спроса меньше, ну не может такого быть > чтобы не было такого механизма? А вот этим всем как раз congestion control и занимается, и там с этим тот еще разброд и шатания. В TCP есть ECN но это как я понимаю не решает проблему полностью. Роутер не знает что через секунду линк станет ЗБС например. А если TCP уже ушел в таймауты по 60 секунд - ну и кто б его знает что там через 60 секунд случится. Ютуб с горя отращивает ломовой буфер, пытаясь в некий адаптив на уровне вообще - плеера. Каналам похуже - поток потоньще, дроп буфера - уйдем ан 360p тощий, вероятнее что пролезет. Встряло? Откроем новый конект чтоб не ждать минуту. У них очень крутой, комплексный антилаг и адаптив + оптимизация потока по жирноте VP9/AV1. И никто ничего сравнимого не смог. Поэтому и икают в разы больше - и не могут всерьез конкурировать.
	Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

	144. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Аноньимъ (ok), 26-Окт-23, 15:19
	Нет, пользоваться вайфаем в яме, под водой, или в свинцовом бункере, я запретить никому не могу. Переотражения и прочая дичь это всё интересно, но с этим не канальный уровень борется. Мой тезис довольно простой, если у вас на вайфае пошла значительная потеря пакетов то каналу хана, и скорость передачи данных физически ниже плинтуса, и никаким чудесным тюнингом TCP это не исправить. Поправьте меня если я не прав. > Если демодуляция при энном соотношении синал-шум лажается, никакие протоколы с этим таки ничего сделать не могут. А вон там в низине - сигнала можно считать что совсем нет. Ну вот и я о том-же. > И если TCP начинает брыкаться на это таймаутами по минуте - возникает спрос на то чтобы его уйти, раз это фиксу не подлежит. Это вроде на уровне приложения настраивается при создании соединения, не? Если данные не проходят, то они не походят, канал мёртвый, хоть у вас TCP хоть что угодно другое, физически связи нет. Для стриминга видео да UDP лучше подходит, вопросов нет.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от _oleg_ (ok), 10-Ноя-23, 14:48
	> Для стриминга видео да UDP лучше подходит, вопросов нет. Расскажите это RTMP и HLS :-).
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 19:54
	> FEC эти чудо-алгоритмы называются. Это даже работает. Если бы ты сказал LDPC, то этот тезис можно было бы принять. Он чуть лучший результат даёт. А так ты просто в роли кэпа выступил. Дальше по тексту ты хвастаешь отсутствием понимания того, как работает коррекция ошибок и вообще, на скольки уровнях она есть.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	140. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Аноним (140), 25-Окт-23, 19:31
	>> FEC эти чудо-алгоритмы называются. Это даже работает. > Если бы ты сказал LDPC, то этот тезис можно было бы принять. > Он чуть лучший результат даёт. FEC это более generic название идеи. И если кто не знал их можно комбинировать. На самых разных уровнях. Наличие или отсутствие LDPC на канальном уровне никак не мешает послать чуть больше пакетов, и если парочка пролюбилась - и черт с ними, обойдемся без перезапроса сегмента потому что FEC выдюжил. Так в принципе можно попытаться переживать уже достаточно большие выпавшие блоки, ценой роста латенси потока - это же interleaving и кодирование большого сегмента, чтобы большой выпавший блок можно было развалить на N маленьких выпадений (deinterleave) и пофиксить алгоритмом FEC. Ну вот у гугли была идея FEC к quic приделать. А китайцы на гитхабе даже и реализовали и даже покруче, сделав весьма забавный софт, "ускоритель интернета". Оказывается, это не шутка. Чудо-впн может пилить поток данных на несколько каналов, а заодно - врезать избыточность, и агрегировать на вон том сервере все потоки. Так даже канал с цать % потерь пакетов пережить можно, и TCP вот как раз и не заметит ничего, покуда FEC справляется с потерями на другом уровне. Это сильно покруче LDPC в пакетах, на совсем другом уровне и даже может использовать N интернет каналов как один более жирный и надежный. > А так ты просто в роли кэпа выступил. Дальше по тексту ты хвастаешь отсутствием > понимания того, как работает коррекция ошибок и вообще, на скольки уровнях она есть. ...кроме маленького момента: я себе беспроводных линков запилил. С вот именно FEC :). И вот тут я уже могу порассуждать за BER, PER и проч. Но вам то виднее, эксперты мирового класса. Да, это небольшие линки для внутренних нужд. Но теория на них вся та же что и на остальных, куда они денутся.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 19:57
	> Multi-path + FEC это немного повыше уровня технологий к которому вы привыкли. А где вы к этому привыкли? Я прямо хочу услышать у пана про организацию управления потоком и используемый алгоритм. Давай! Это вопрос с подвохом, сразу говорю.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	108. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+1 +/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 20:02
	> В свете этого хотелось бы увидеть пруф что кто-то и правда додумался до кубика > в чистом виде в QUIC. Ничем незамутнённый Cubic без гибридного старта. Или тебе сорцев недостаточно? Напомню, что сейчас в ядро вроде как пакет улучшений его от Cf собираются принять. А в Quic никакого нет...
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	141. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Аноним (140), 25-Окт-23, 19:36
	> Ничем незамутнённый Cubic без гибридного старта. Или тебе сорцев недостаточно? Напомню, > что сейчас в ядро вроде как пакет улучшений его от Cf > собираются принять. А в Quic никакого нет... Сорцев, блин, чего?! Я посмотрел сорц сабжевой либы. А там и сказано что flow control это прерогатива реализации QUIC под этой либой. Которую вы предоставите. Вы утверждаете что вон те сорцы молиллы могут быть для вот этой либы реализацией QUIC которую она сможет юзать? Или чего? И вот получается что мы тут как раки обсуждаем то чего в этой либе ... вообще нет.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Аноним (135), 24-Окт-23, 03:58
	FEC вас не спасёт, потому что пропускную способность нельзя взять из вакуума. Если у вас потери не из-за помех вайвая, а из-за перегрузки роутера, то вы своим FEC ему настоящий ddos устройте.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	142. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Аноним (140), 25-Окт-23, 19:38
	> FEC вас не спасёт, потому что пропускную способность нельзя взять из вакуума. > Если у вас потери не из-за помех вайвая, а из-за перегрузки > роутера, то вы своим FEC ему настоящий ddos устройте. Как у вас все просто и универсально то. А я думал что проблемы RF каналов крайне разнообразны и многогранны... да, в каких-то случаях оверхед от FEC не есть айс. А в каких-то - то что доктор прописал.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Ivan_83 (ok), 23-Окт-23, 22:17
	Не важно где именно идёт потеря пакетов. Кроме потери пакетов бывает ещё и RTT (пинг) большой. В обоих случаях в линухе hybla отлично справляется и выжимает из канала максимум. Аналогично RACK+htcp во фре. Я в своё время наигрался с этим гоняя IPTV потоки через 5 часовых поясов, и там даже без WiFi сегментов хватало и потерь и проблем из за задержек. Стабильно смотрибельный результат давало только то что описано выше.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	125. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 22:49
	> В обоих случаях в линухе hybla отлично справляется и выжимает из канала > максимум. Не могу подтвердить, что его можно в кач-ве алгоритма общего применения использовать. Он, как BBRv1, применим для каналов в RTT больше 50 мс.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Ivan_83 (ok), 23-Окт-23, 23:38
	htcp работает на больших RTT чуть хуже hybla. С hybla вроде нет проблем в локалках, по крайней мере на гиговых линках.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 23:47
	> htcp работает на больших RTT чуть хуже hybla. > С hybla вроде нет проблем в локалках, по крайней мере на гиговых > линках. Про htcp ничего не могу сказать, т.к. не гонял в разных сценариях. А вообще поищи, был пару лет назад обширный census используемых алгоритмов в интернетах. Там есть много интересного.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Ivan_83 (ok), 23-Окт-23, 22:12
	CUBIC - фигня, он работает не плохо и не хорошо. Гораздо интереснее hybla и htcp тоже не плох. BBR - не уверен что хорошо работает. На фре RACK отлично работает, и его же вариант выбрал интел и гугол чтобы пихать в свои сетевухи, новость тут недавно была.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	126. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 22:54
	> CUBIC - фигня, он работает не плохо и не хорошо. Тут дело не впроизводительности даже. Первый критерий - агрессивность в самом простом случае - LAN. Запускаешь один поток Cubic в простейшем сценарии кабель-тупой свитч-кабель + дефолтный fq-codel на обоих концах. RTT < 2 мс. Запускаешь параллельно SSH и делаешь выхлоп какого-нибудь сислога. Ну как, интерактивно живётся? Дальше - больше. Параллельные потоки тестируешь. Не забыть с отложенным запуском. Конкуренцию со стандартными Reno, Cubic и пр.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от Ivan_83 (ok), 23-Окт-23, 23:46
	У кого что болит :) В RACK даже наоборот вроде выключал какую то фичу для учёта соседних соединений, ибо просто не нужно. У меня не было никогда большого трафика в локалке и необходимости что то докручивать чтобы интерактивность не страдала, всегда была проблема как отдать контент через линки с потерями или потери+RTT.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 23:52
	> У кого что болит :) > В RACK даже наоборот вроде выключал какую то фичу для учёта соседних > соединений, ибо просто не нужно. > У меня не было никогда большого трафика в локалке и необходимости что > то докручивать чтобы интерактивность не страдала, всегда была проблема как отдать > контент через линки с потерями или потери+RTT. Я говорил лишь про общий случай, про менее агрессивную относительно Cubic альтернативу. Я понимаю, что Reno и Cubic там по историческим причинам, но это не значит, что достойных альтернатив нет.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Опубликована библиотека nghttp3 1.0 с реализацией протокола ..."	+/–
	Сообщение от timur.davletshin (ok), 23-Окт-23, 23:00
	> CUBIC - фигня, он работает не плохо и не хорошо. > Гораздо интереснее hybla и htcp тоже не плох. > BBR - не уверен что хорошо работает. > На фре RACK отлично работает, и его же вариант выбрал интел и > гугол чтобы пихать в свои сетевухи, новость тут недавно была. В принципе, если узкое место в WAN, а на роутере AQM + ECN, то любой алгоритм, не игнорирующий ECN, пойдёт (можно даже без ECN). Беда в том, что внутри LAN трафик тоже гоняют и иногда немалый. И это не вещание, пускай хоть 8к, с относительно стабильным битрейтом.
	Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

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

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