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

"В ночных и бета сборках Firefox включена по умолчанию поддержка HTTP/3 "	+/–
Сообщение от opennews (ok), 21-Мрт-21, 08:42
В ночных сборках  Firefox, а также в бета-версии включена по умолчанию поддержка протокола HTTP/3. В стабильной ветке включение HTTP/3 намечено на выпуск Firefox 88, запланированный на 20 апреля. В Chrome выборочная активация HTTP/3 началась в октябре 2020 года... Подробнее: https://www.opennet.me/opennews/art.shtml?num=54801
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от timur.davletshin (ok), 21-Мрт-21, 08:42	+13 +/–
А про недостатки почему не пишут? Тот же congestion control теперь не от ядерной реализации какого-нибудь cubic, reno зависит, а от криворукости хромоделов. Была же уже драма когда-то с внедрением первой реализации uTP в торрентах и повсеместными "укладываниями" пропускной способности. Сообразительные по части сетевых протоколов ещё парочку накидают.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #6, #129, #165, #227

2. Сообщение от Аноним (2), 21-Мрт-21, 08:47	–2 +/–
Опять rust. Опять будет пароксизм ненависти в комментариях
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #15

3. Сообщение от Аноним (5), 21-Мрт-21, 08:47	–5 +/–
Ещё дополню "преимущества" QUIC: Лучше следить за пользователями...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38, #163, #200

4. Сообщение от timur.davletshin (ok), 21-Мрт-21, 08:49	–2 +/–
Заметный прирост производительности тоже пока под вопросом. На багзилле баг висит, в котором жалуются как-раз на затупы того же Google после включения. Но, зато, по Wi-Fi производительность действительно может вырасти. По TCP вафля в среднем из-за большого оверхеда в структуре фрейма (2346 на 1500 ethernet фрейм) и на служебных сообщениях даёт от 30 до 38% заявляемой (например около 2.2 мегабайт на 54 мегабитах), а вот по UDP около 45%.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #229

5. Сообщение от Аноним (5), 21-Мрт-21, 08:51	+1 +/–
Странный вы народ: в срачах про микроядро vs монолит вы вовсю кричите что надо все в юзерспейс. А сейчас (и ещё помню новость про FUSE) уже ярые противники этого подхода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #9, #78

6. Сообщение от Аноним (6), 21-Мрт-21, 08:55	+1 +/–
Ну во-первых в мобильный браузер не залезть в about:config, а в новости про них почему-то тоже сказано. То естть включить никак, выключить никак. В гугле 1% разница в нагрузке от этой гугловской версии удп протокола.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #10, #16, #58

7. Сообщение от Аноним (6), 21-Мрт-21, 08:57	+4 +/–
Его на деле нет. Просто вафля может иметь пинг 50+ даже при идеальной связи в AC. И там не важно сколько чего куда. Там только квадратичная модуляция снижает накладные расходы на передачу данных. Это все лапша для легковерных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #17, #65

9. Сообщение от timur.davletshin (ok), 21-Мрт-21, 09:00	+9 +/–
> Странный вы народ: в срачах про микроядро vs монолит вы вовсю кричите > что надо все в юзерспейс. А сейчас (и ещё помню новость > про FUSE) уже ярые противники этого подхода. Для начала, я никогда не кричал такого. Есть просто имеющийся сетевой стек и в нём управление потоком для TCP в ядре, а UDP по дизайну не гарантирует доставку, поэтому там управление потоком и его целостностью должно быть выше. Дело даже не в том, что ядерные алгоритмы оттестированы и не страдают склонностью к вендорлоку, а в том, что процесс, управляющий потоком, работать будет с пользовательским приоритетом, что недопустимо для realtime задачи управления потоком. В загруженных условиях пользовательская реализация будет страдать от той же проблемы, на которую наступил когда-то pulseaudio. Сколько тут было орущих про "икание" звука после перехода на pulseaudio (сама идея вообще хороша)? Так вот, это банально из-за невозможности управления realtime задачей из пользовательского пространства в условиях высокой загрузки. Скрытый же мотив гугла в том, чтобы вынести по максимуму всё в зависящий только от cебя блоб. Даже то же обоснование о том, что мультиплексированный в HTTP/2 поток дропает всё в случае потери пакета, и повышенная пропускная способность UDP на беспроводных, нивелируется тем, что тот же оверхед, необходимый для контроля целостности потока, реализуется уже внутри самого QUIC. И он не меньше, а в реальности даже больше, чем у TCP vs UDP.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #25, #228

10. Сообщение от timur.davletshin (ok), 21-Мрт-21, 09:01	–2 +/–
> Ну во-первых в мобильный браузер не залезть в about:config, а в новости > про них почему-то тоже сказано. То естть включить никак, выключить никак. > В гугле 1% разница в нагрузке от этой гугловской версии удп > протокола. Последний раз, когда я туда хотел залезть, мне ничего не мешало, кроме предупреждения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #36

11. Сообщение от Аноним (11), 21-Мрт-21, 09:04	–3 +/–
Пускай пилят хоть на чем, главное чтобы был и был повсеместно. У этого протокола хорошая перспектива для маскировки VPN. То, что сейчас есть сильно тормозит - meek, например (да, это tor, но кому надо - приспособили).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #34

12. Сообщение от kusb (?), 21-Мрт-21, 09:06	+1 +/–
Сишные дыры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #45, #81

13. Сообщение от timur.davletshin (ok), 21-Мрт-21, 09:06	–2 +/–
> Пускай пилят хоть на чем, главное чтобы был и был повсеместно. У > этого протокола хорошая перспектива для маскировки VPN. То, что сейчас есть > сильно тормозит - meek, например (да, это tor, но кому надо > - приспособили). Простите, чем он лучше для маскировки VPN'а? Да-да, я не про инкаспуляцию TCP в TCP, а именно про маскировку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #14, #138

14. Сообщение от Аноним (11), 21-Мрт-21, 09:13	–1 +/–
Трафик неотличим от HTTP. К тому же сейчас с обычным TLS можно пописать в SNI какой-нибудь ненужный dropbox, facebook, или на что там ваш мобильный оператор безлимитку дает - и качайте себе весь интернет нахаляву. Как с этим в HTTP/3 не знаю, для меня это уже неактуально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #193, #199, #221

15. Сообщение от Аноним (15), 21-Мрт-21, 09:16	+57 +/–
Раст сам по себе основан на ненависти к другим языкам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #18, #23, #43

16. Сообщение от Аноним (16), 21-Мрт-21, 09:21	+/–
И в Chrome (chrome://flags), и в Firefox (about:config) можно зайти в дополнительные настройки на Android.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #26

17. Сообщение от timur.davletshin (ok), 21-Мрт-21, 09:31	–3 +/–
> Его на деле нет. Просто вафля может иметь пинг 50+ даже при > идеальной связи в AC. И там не важно сколько чего куда. > Там только квадратичная модуляция снижает накладные расходы на передачу данных. Это > все лапша для легковерных. Заходим на роутер и делаем iw dev wlan0 station dump и срём кирпичами от tx retries )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #136

18. Сообщение от YetAnotherOnanym (ok), 21-Мрт-21, 09:37	–51 +/–
Вот не надо. Язык как язык - свои принципы, свои концепции. А то, что какие-то неадекваты из числа фанатов раста хейтят Си - ну так на опеннете вообще аудитория такая, пора бы привыкнуть и не делать скоропалительных выводов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #22, #27, #173

21. Сообщение от YetAnotherOnanym (ok), 21-Мрт-21, 09:49	+9 +/–
>  данные можно передавать сразу после отправки пакета установки соединения Напоминает мою знакомую, которая, входя в комнату, бросала "Здрасьте" и сразу начинала говорить, а когда её обрывали и указывали, что люди могут быть чем-то заняты и не готовы её слушать - очень обижалась. > Не использование при повторной передаче пакета того же номера последовательности, что позволяет (...) избавиться от таймаутов Вона чё... Оказывается, таймауты не из-за заторов или неисправности линии, а из-за того, что дропнутый пакет повторно передаётся под тем же номером.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #42

22. Сообщение от Аноним (-), 21-Мрт-21, 10:04	–43 +/–
> Вот не надо. Язык как язык - свои принципы, свои концепции. А > то, что какие-то неадекваты из числа местных ванаби-сишников, жопоскриптозников и питонистов набрасывают в виде "растофанатов, хейтеров си" и сразу же "дает отпор хрустикам" - ну так на опеннете вообще аудитория такая, пора бы привыкнуть и > не делать скоропалительных выводов. Пофиксил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #24

23. Сообщение от Аноним (-), 21-Мрт-21, 10:06	–52 +/–
> Раст сам по себе основан на ненависти к другим языкам. И на постоянном нагреве реактивного сопла у опеннетчиков - это основной двигатель прогресса в раст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

24. Сообщение от Аноним (15), 21-Мрт-21, 10:07	+55 +/–
> > Раст сам по себе основан на ненависти к другим языкам. > ванаби-сишников, жопоскриптозников и питонистов Quod erat demonſtrandũ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #72, #92

25. Сообщение от Нанобот (ok), 21-Мрт-21, 10:08	–2 +/–
> процесс, управляющий потоком, работать будет с пользовательским приоритетом, что недопустимо для realtime задачи управления потоком. Если взлетит, потом всегда можно будет добавить добавить реализацию в ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #28

26. Сообщение от Нанобот (ok), 21-Мрт-21, 10:10	+2 +/–
В Firefox Beta - можно. В обычном Firefox для android - нельзя
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #49

27. Сообщение от Аноним (27), 21-Мрт-21, 10:18	+2 +/–
Си никто в здравом уме не будет хейтить. Язык, на котором столько всего написано, просто нельзя не уважать. Но вот стоит ли писать на нем что-то новое? Нельзя забывать, что он довольно примитивный (некоторые отмечают это его плюсом), устаревший, почти не развивается (опять же). Лично я выберу Раст (трейты - хорошая замена классического ООП) или Плюсы (зависит от задачи). А вот как раз чистые бессмысленные хейтеры Раста здесь есть. Которые его только на картинках видели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #62, #80

28. Сообщение от timur.davletshin (ok), 21-Мрт-21, 10:19	+/–
> Если взлетит, потом всегда можно будет добавить добавить реализацию в ядро. Милый, там congestion алгоритмов уже выше крыши, выбирай на вкус.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #44, #131

29. Сообщение от Урри (ok), 21-Мрт-21, 10:24	+11 +/–
Очередное эталонное ненужно. Я каждый раз, когда приходится что-то из современного веба имплементировать, удивляюсь глупости тех, кто это придумывал и внедрял. Хотите примеры? Пожалуйста. WebSockets. Очевидно, нужная вещь. Работающая. Полезная. Используемая на миллионах клиентов. Казалось бы, должна быть проработана до мельчайших нюансов (как всяческие другие протоколы). Но, как это принято в вебе, все равно сделанная через одно место. Для примера, есть в стандарте хендшейка веб-сокета такой момент: клиент должен сформировать некий ключ и отправить его серверу в base64. Так в стандарте (rfc6455) и написано прямым текстом "base64". А дальше этот ключ на стороне сервера никто не(!) декодирует. Его используют прямо так - текстовой строкой. Более того, к этой строке добавляется GUID, причем в стандарте так и написано прямым текстом "guid", Который, внезапно, является тоже просто строкой(!), причем прямо захардкоженой. Вот эта строка: "258EAFA5-E914-47DA-95CA-C5AB0DC85B11", можете поискать ее в интернете - увидите, что я не вру, без того, чтобы читать весь стандарт. Внимание, вопрос: почему в стандарте не написано "сгенерируйте текстовую строку из разрешенных символов? Почему не написано "к этой строке надо конкатенировать другую строку "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"? Почему там требование ненужного base64 и ненужного guid? Я отвечу - потому, что все делается на коленке болванами и торопыгами. Да, продуктивными болванами, но от этого не менее болванистыми (и более вредными). Буяк-буяк-и-в-продакшен, web 2.0, аджаааааайл, некогда думать надо делать, прыг-прыг-прыг. Придумали сначала ключ, надо передать строкой, вот вам бейз64, сервер декодирует, добавляет уникальный гуид и использует. Ой, нет, а давайте не будем декодировать, нам и так хорошо. Ой, а еще и гуид пусть один и тот же будет, зачем его менять? А что там у нас в документе написано для клиента? А, не важно, некогда все приводить к единому знаменателю, юниттесты работают и ладно, некогда объяснять надо код сдавать. Вот так base64 с гуидом и остались. Артефакты прошлой текучки. Эхо аджайла и разгильдяйства. Отголосок сломанного кривыми технологиями мозга (я намекаю на джаваскрипт). Я такое могу про много что рассказать. Например, про обязательный для всех CORS, который бесполезен целиком и полностью и элементарнейшим образом обходится любым злоумышленником, при этом добавляя неплохой оверхед к передаче данных. И куче других веб-технологий. Точно так же делаются всякие расты, из-за чего их и хейтят. Мы то знаем и помним, как правильно делать подобные вещи. А недоучкам всяким невдомек, что сначала надо думать и только тогда делать, ведь потом придется снова и снова переделывать. Так вот, повторюсь - HTTP/3 такое же непродуманное ненужно. Для веб-страничек не нужен очередной велосипедный TCP, им и классического с головой хватает. А для веб-игрушек, аудио, видео и что еще там кто себе с низким временем отклика придумает, нужен обычный отлаженный стандартизированный прекрасно уже 16 лет как работающий RTP. Зачем это гуглу? Наверное, снова хотят очередной невынимаемый зонд вставить.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #30, #35, #39, #46, #74, #94, #139

30. Сообщение от Онаним (?), 21-Мрт-21, 10:28	+1 +/–
Вот знаете... Не могу не согласиться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #59

31. Сообщение от Аноним (31), 21-Мрт-21, 10:44	+4 +/–
HTTP/G[oogle]
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #76

32. Сообщение от Аноним (32), 21-Мрт-21, 10:46	–8 +/–
Забыли упомянуть, в лучшем браузере Opera так-то HTTP3 давно есть
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #40, #48

33. Сообщение от Аноним (34), 21-Мрт-21, 11:17	+/–
>Код компонентов для поддержки HTTP/3 и QUIC написан на языке Rust. А тут возникали, что типа раст не нужен. А скоро в ядро поддержку QUIC завезут?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41, #86

34. Сообщение от Аноним (34), 21-Мрт-21, 11:20	+2 +/–
meek же вообще нахрен выпилили, чтобы выполнить требование шантажистов. >У этого протокола хорошая перспектива для маскировки VPN. Нет, это у шантажистов хорошие перспективы обязать провайдеров его заблокировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

35. Сообщение от Lex (??), 21-Мрт-21, 11:23	+/–
> Отголосок сломанного кривыми технологиями мозга (я намекаю на джаваскрипт) Ругать жс за реализацию конкретной фичи в браузере - все равно, что ругать яйцо за курицу, которая его снесла. Реализации штук типа вс в браузере «внезапно» кодятся на божественной сишечке. Т.е дело именно в криворуких сишных проггерах. А ещё дело в том, что веб - штука вполне общедоступная. Хочешь - бери и делай. Вот некоторые и делают. В то же время, у каждого из таких «дельцов» как ни странно, свои планы замыслы подходы и цели, а так же - видение будущего. И нынешний веб - это продукт работы не одной конторы, а компромисс множества хотелок множества организаций, некоторые из которых друг другу противоречат
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #37

36. Сообщение от Аноним (36), 21-Мрт-21, 11:33	+2 +/–
> Последний раз, когда я туда хотел залезть, мне ничего не мешало, кроме предупреждения. Редко заходишь, значит: в релизных мобильных версиях доступ к about:config выпилили с августа прошлого года.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #52, #83, #110, #135, #257

37. Сообщение от Урри (ok), 21-Мрт-21, 11:34	+5 +/–
> Ругать жс за реализацию конкретной фичи в браузере - все равно, что ругать яйцо за курицу, которая его снесла. Нет, тут все существенно глубже. Я по роду профессии много общаюсь с молодыми программистами. Так вот корреляция между тем, на чем они программируют (или учились программировать) и способностью связно и без грабель алгоритмизировать задачу очень четкая. И в этой корреляции джаваскрипт очень, очень плох. Конечно же, бывают исключения (это сноска для троллей "что, все 100%? да ты дурак и значит врешь"). Лично я списываю это на то, что жс сильно нелогичный и плохо структурированный, постоянное его использование учит мозги программистов мыслить нелогично и плохо структурировано. Ну а общий подход "и так сойдет" (эрроры и ворнинги все равно никто в консоли не увидит, если специально не откроет) это все полирует и закрепляет. И вот на выходе не программист, а гoвнoкодер, программистом по сути не являющийся. С, как это среди программистов принято, огромным самомнением. > И нынешний веб - это продукт работы не одной конторы, а компромисс множества хотелок множества организаций, некоторые из которых друг другу противоречат Ха-ха три раза. Что гугл захотел, то пропихнул. Раньше мс пропихивала. Остальные подтягиваются и делают как сказали. Ни вы, ни я, ни даже контора которую мы бы с вами откроем ничего в вебе не решит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #61, #64, #66, #77

38. Сообщение от leibniz (ok), 21-Мрт-21, 11:36	+/–
*следит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #235

39. Сообщение от Аноним (36), 21-Мрт-21, 11:51	+2 +/–
Я вот в целом даже согласен, но даже тут неадекватности умудрилось вылезти местами, хотя вот вроде понимающий же... Ну вот смотри, в паре соседних абзацев написал это: > Точно так же делаются всякие расты, из-за чего их и хейтят. Мы то знаем и помним, как правильно делать подобные вещи. и это > Я отвечу - потому, что все делается на коленке болванами и торопыгами. Да, продуктивными болванами, но от этого не менее болванистыми (и более вредными). Буяк-буяк-и-в-продакшен, web 2.0, аджаааааайл, некогда думать надо делать, прыг-прыг-прыг. > Артефакты прошлой текучки. Эхо аджайла и разгильдяйства. Отголосок сломанного кривыми технологиями мозга (я намекаю на джаваскрипт). Но при этом ты прекрасно знаешь, что вот это вот "Буяк-буяк-и-в-продакшен" написано на сях и плюсях. Проблема не в расте, а вот в этих вот как раз "болванами и торопыгами @ некогда думать надо делать", а раст - это такая попытка сделать плюсы в которых отстрелить себе ногу сложнее, если прямо не написать в коде: "я здесь сейчас будут стрельбой себе по ногам заниматься". Причём рабочая попытка, потому что найти тех, которые "Мы то знаем и помним, как правильно делать подобные вещи" сейчас всё сложнее. И даже они НИКОГДА не писали код (в больших объёмах если) без тех ошибок, от которых немного помогает раст (ну то есть даже у ЛУЧШИХ случались такие ошибки в коде).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #63

40. Сообщение от Лоховоз (?), 21-Мрт-21, 11:57	+3 +/–
Чем это Опера самый лучший? Просвятите неумытого ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #144

41. Сообщение от Аноним (41), 21-Мрт-21, 12:00	+1 +/–
ну там поддержку раста уже анонсировали так что скоро достаточно будет в манифесте ядра прописать neqo - и считай готово!)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

42. Сообщение от Ordu (ok), 21-Мрт-21, 12:02	+2 +/–
> Оказывается, таймауты не из-за заторов или неисправности линии, а из-за того, что дропнутый пакет повторно передаётся под тем же номером. Нет, проблема в том, что остальные пакеты не передаются, пока дропнутый пакет не будет передан повторно и не придёт подтверждение о доставке. То есть, там чуть сложнее, потому что потоком tcp одновременно передаётся несколько пакетов, и когда один потерялся, случается что-то типа сбоя конвеера в CPU.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #212

43. Сообщение от Дегенератор (ok), 21-Мрт-21, 12:04	+/–
Его придумал Гитлер! Мозила == фашизм!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

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

45. Сообщение от Аноним (44), 21-Мрт-21, 12:07	–1 +/–
Дыры от ржавчины.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

46. Сообщение от Ordu (ok), 21-Мрт-21, 12:25	–1 +/–
> Вот так base64 с гуидом и остались. Артефакты прошлой текучки. Эхо аджайла и разгильдяйства. И чё? Это приводит к каким-то неприятностям, или что? > Так в стандарте (rfc6455) и написано прямым текстом "base64". Ты точно стандарт читал? Там смотри что: > 1.3.  Opening Handshake >   _This section is non-normative._ non-normative, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #70

47. Сообщение от Аноним (48), 21-Мрт-21, 12:49	–1 +/–
Я правильно понял что HTTP2 провалился как замена HTTP1.1 ? Ну раз до его полноценного внедрения дело не дошло и его уже пришлось заменять новым протоколом? Хоть в этом есть и плюс, что выкидывают неудачные технологии, но минус в том что выкидывают и рабочие старые, в то время как новые оказывается вот таким вот мусором
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #55, #57, #68, #145

48. Сообщение от Аноним (48), 21-Мрт-21, 12:50	–1 +/–
Лучший был 12 опера и там нету хттп3 до сих пор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #71

49. Сообщение от Урри (ok), 21-Мрт-21, 12:53	+/–
Используй IceCat. Те же яйца, но можно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

50. Сообщение от Аноним (50), 21-Мрт-21, 12:55	+/–
Уже есть http/2? O_o
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #54, #89, #242

51. Сообщение от lockywolf (ok), 21-Мрт-21, 12:56	+/–
Зачем вообще гонять http по udp??? UDP же дня всякого треша, который устаревает до того, как пакет успевает долететь до получателя, вроде потокового видео, аудио, или игр. Что за странная идея реализовывать гарантированную доставку по udp?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #75

52. Сообщение от timur.davletshin (ok), 21-Мрт-21, 13:01	+/–
Я просто на бете сижу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

53. Сообщение от timur.davletshin (ok), 21-Мрт-21, 13:02	–2 +/–
> Но этими алгоритмами пользуется тольлко TCP. А в UDP/QUIC поддержку это придётся > добавить. Дурилка, для UDP они не нужны по дизайну.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #120

54. Сообщение от lockywolf (ok), 21-Мрт-21, 13:04	–1 +/–
Уже не просто есть, но уже и декомиссован.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #69, #82, #170

55. Сообщение от Total Anonimus (?), 21-Мрт-21, 13:06	+1 +/–
Неправильно . http2 - для котиков , http3 - для порнухи .
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

56. Сообщение от Аноним (56), 21-Мрт-21, 13:12	+/–
когда там уже только https по умолчанию
Ответить | Правка | Наверх | Cообщить модератору

57. Сообщение от timur.davletshin (ok), 21-Мрт-21, 13:14	+/–
Суть не в этом. Когда придумывали http/2, большая часть народу сидела через надежный кабель, позволявший вместо http pipelining времён http/1 мультиплексировать загрузку нескольких элементов внутри одного TCP соединения. А сейчас 2/3 оконечных устройств сидят через корявую wifi или через 3/4/5G и потеря одного TCP пакета ведёт к тормозам всего мультиплексированного потока... ... решили, что вернёмся во времена http/1 с множеством отдельных соединений. Только завернули это поверх UDP, т.к. он реально большую скорость на вафле даёт из-за меньшего оверхеда при передаче через беспроводной (не обязательно вафля) фрейм. Беда только в том, что контроль потока теперь не на ядре лежит, а в пространстве пользователя. Да и лично у меня после включения HTTP/3 кол-во соединений подскочило на 50%!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

58. Сообщение от Я забыл подписацца асел (?), 21-Мрт-21, 13:19	+1 +/–
Fennec с фдройд или его форк iceraven работают как надо, ничего не выпилено. Adware-мусор типа хрома и его клонов, разумеется, нерелевантны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

59. Сообщение от Андрей (??), 21-Мрт-21, 13:20	–2 +/–
«сгенерируйте текстовую строку из разрешенных символов?» Про гуид всё же понятно он «гарантировано» уникальный Если написать рожно что вы предлагаете, то имплементаторы налячкают своих горе генераторов А тут используется готовый индустриальный подход, полностью специфицированный более того его реализации есть под всё. Насчет base64 хз Возможно эти данные нужны именно строкой
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

60. Сообщение от Аноним (60), 21-Мрт-21, 13:37	+1 +/–
вы ребят в прошлом веке остались со своими "тисипи это наше все, да нееету выигрыша от удп". пройдет пару лет, поймете, что были неправы, вернитесь в этот тред, извинитесь за эти минусы. сейчас связь иная, не предназначены тайминги тисипи для скоростного мобильного интернета. ну никак. так что давите минус, фактически оценивая сами себя, мне даже забавно это печатать щас
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #73, #79, #84, #102, #171

61. Сообщение от Онаним (?), 21-Мрт-21, 13:37	+2 +/–
Алгоритмизировать задачу? :D Это уже ныне сеньор, не меньше. "Кодеры" нынешние же с алгоритмизацией вообще дружат слабо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

62. Сообщение от картинках (?), 21-Мрт-21, 13:42	–2 +/–
> Язык, на котором столько всего написано, просто нельзя не уважать. Уважения не достаточно внезапно, любители старья пусть валят смотреть мелодрамы 70х. Я выбираю быстрейший инструмент для своей задачи, и ср@ть хотел на хейтеров. Haters gonna hate (c). Раст уже обгоняет С по производительности, это отличная новость притом что компилятор еще сыроват. > Плюсы (зависит от задачи). Удовольствие куда ниже среднего, 70% функционала в депрекейтед в любом топ проекте. Куча легаси кода на радость старичью, но начинать что-то новое на плюсах смысла нет еслы ты не раб менеджера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #99, #104

63. Сообщение от Урри (ok), 21-Мрт-21, 13:44	+1 +/–
Отвечу не совсем по порядку > Но при этом ты прекрасно знаешь, что вот это вот "Буяк-буяк-и-в-продакшен" написано на сях и плюсях. Это не имеет отношения к теме разговора. Будет желание - можем обсудить отдельно. > Проблема не в расте... Структура языка раст объективно плоха. Она плоха тем, что не продумана изначально. Попытка была прекрасна - сделать очередного конкурента С (не плюсов - в плюсах есть различные умные указатели, которые проблему полностью решают; а отсутствие обычных указателей можно автоматически гарантировать на этапе приемки простым скриптом на баше; в плюсы элементарно встраивается сборщик мусора и т.д. и т.п.). Конкурента, который лучше, удобнее, безопаснее и т.д. Таких попыток, если вдруг кто не в курсе, всегда было много. Но из-за того, что изначально никто не дал себе труда подумать, начальный красивый и простой дизайн превратился в заплатанного монстра франкенштейна с кучей различных стенографических значков. Как вам поинтеры &, &mut, *const, *mut...? Как вам выражение "let r2 = &mut num as *mut i32"? Красиво? Интуитивно? Логично? В мозиле это увидели и это единственная причина, по которой раст выкинули на мороз. Им не нужен монстр. Поэтому лично я раст не люблю. Я люблю красивые и стройные языки, которые позволяют легко транслировать идею в команды компьютеру. Я люблю С (не С++), я люблю руби, я очень люблю схему (почти идеальный язык - жаль только что люди по историческим причинам предпочли инфиксную нотацию в математике, а не префиксную - тогда бы это был совсем идеальный язык), мне нравится, между прочим, шарп (хотя в свое время майкрософт сделала все, чтобы его похоронить - но он воскресает). Раст не красивый и не стройный. > найти тех, которые "Мы то знаем и помним, как правильно делать подобные вещи" сейчас всё сложнее Это больной вопрос. Вы правы, индустрия быстро растет, а профессионалов больше не особо становится. Так тем более к основным вещам надо относиться с повышенным вниманием (я вот лично к этому прикладываю по мере сил свою руку). Веб, как основа информационной ноосферы, особенно должен поддерживаться профессионалами, а не дилетантами. Вы же не наймете таджиков проектировать из говна и палок небоскребы только потому, что "нормальных архитекторов мало, сложно найти"? > И даже они НИКОГДА не писали код (в больших объёмах если) без тех ошибок, от которых немного помогает раст (ну то есть даже у ЛУЧШИХ случались такие ошибки в коде). Этот сомнительный плюс что-то вроде обязательных отступов в питоне (боже, более идиотского решения в языке я никогда и нигде не видел - кроме эзотерических, само собой), который можно решить различными статическими автоматизированными процессами и общей культурой кода в любом языке, нивелируется остальными минусами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #148, #191

64. Сообщение от Random (??), 21-Мрт-21, 13:45	+/–
Классика: "Нельзя научить программированию человека, оболваненного Бэйсиком"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

65. Сообщение от картинках (?), 21-Мрт-21, 13:46	+1 +/–
> Просто вафля может иметь пинг 50+ даже при идеальной связи в AC Это на каком-то гoвнoтике 15летней давности? Только что сопоставил з кабелем у себя - вайфай добавляет 3ms.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #97, #137

66. Сообщение от Lex (??), 21-Мрт-21, 13:52	+1 +/–
> между тем, на чем они программируют (или учились программировать) и способностью > связно и без грабель алгоритмизировать задачу очень четкая. И в этой > корреляции джаваскрипт очень, очень плох. Способность связно и без грабель алгоритмизировать приходит с опытом и обучением( в т.ч профильным вузовским, где в т.ч этому учат ). Тогда как новички, даже с высшим образованием за плечами, на сях, шарпе и жабе запросто пишут эпический гомнокод. > Лично я списываю это на то, что жс сильно нелогичный и плохо > структурированный, постоянное его использование учит мозги программистов мыслить нелогично > и плохо структурировано. Ну а общий подход "и так сойдет" (эрроры > и ворнинги все равно никто в консоли не увидит, если специально > не откроет) это все полирует и закрепляет. > И вот на выходе не программист, а гoвнoкодер, программистом по сути не > являющийся. С, как это среди программистов принято, огромным самомнением. Со своей стороны кстати заметил, что худший жс-код нередко получается у тех, кто ранее кодил на шарпе или джаве - там будто бы какая-то профессиональная деформация, что они ничего не могут делать просто: даже примитивнейшая функция-помощник для обращения к бэкенду у них превращается в несколько файлов, кучу классов с наследованием и пробросом экземпляров одного класса в другой и обмазкой костылями, что потом черт ногу сломит, а если применяется тайпскрипт, то ещё и всевозможными интерфейсами, пометками для того или иного игнора проверок и проч обмазано.. и все равно работает с багами. Хотя не исключаю, что это профессиональные заработчики, решившие чутка сменить специализацию. > Ха-ха три раза. Что гугл захотел, то пропихнул. Раньше мс пропихивала. Остальные > подтягиваются и делают как сказали. Ни вы, ни я, ни даже > контора которую мы бы с вами откроем ничего в вебе не > решит. Хоть засмейся. Это ситуация последних лет. Но веб как таковой создавался не один десяток лет.. и даже тонны разных префиксов в css не просто так существуют. И да, это именно результат компромисса: один протолкнул одно и все в итоге согласились, другой - другое, третий - третье, но остальные принципиально забили и фича загнулась. Но таки нет, есть фаерфокс, который уже не тот, если сафари и поделия на вебките, есть хром и какие-то поделия на его движке Разговоры про то, «как это бы сделать правильно» примерно из разряда «а вот если бы люди всей Земли.. », поскольку полностью игнорируют наличие множества участников, планы и приоритеты которых нечасто совпадают и тот простой факт, что реализация должна по максимуму сохранять обратную совместимость с тем что уже есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #90, #253

68. Сообщение от Random (??), 21-Мрт-21, 13:53	+1 +/–
На корпоративном NextCloud пришлось сразу отключить HTTP/2 из-за сильных тормозов. Не исключено, что проблема на самом деле в корпоративных же файрволах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #87

69. Сообщение от Аноним Наблюдающий (?), 21-Мрт-21, 13:53	–1 +/–
Брехня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

70. Сообщение от Урри (ok), 21-Мрт-21, 13:54	+3 +/–
> И чё? Это приводит к каким-то неприятностям, или что? Вот! Прекрасная иллюстрация моего комментария о говнокодерах, искалеченном мозге и невозможности им быть программистами. > non-normative, да? Дорогой Ordu, если ты не заметил, то каждый (каждый!) раздел стандарта rfc-6455 помечен плашкой "_This section is non-normative._". Это такая де-юре отметка старших умных дядей, что они эту фигню не одобряли и одобрять не собираются. Чтобы потом стыдно не было. Де-факто (и де-юре) этот стандарт принят еще в 2011 году (с парой маленьких апдейтов, по сути ничего не меняющих), "спасибо" Гуглу. Все реализации webSockets ему следуют. И если ты сделаешь иначе, то твой код не будет общаться с браузерами и веб-серверами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #85, #181

71. Сообщение от Аноним (71), 21-Мрт-21, 13:58	+/–
Не был он лучшим. Там ни аблока нормального не было, ни дополнений. Зато был свой электрон встроенный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

72. Сообщение от Аноним (-), 21-Мрт-21, 14:00	–59 +/–
>> > Раст сам по себе основан на ненависти к другим языкам. >> ванаби-сишников, жопоскриптозников и питонистов ЧСХ - ни одного ЯП. Да и "ненависти" как-то не наблюдается - так, брезгливость. > Quod erat demonſtrandũ. Quod очередной жопочтец-сам-придумвыватель-сам-опровергатель демонстрандум
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

73. Сообщение от ZyklonB (?), 21-Мрт-21, 14:04	–2 +/–
>скоростной мобильный интернет Сегодняшних скоростей хватит всем за глаза и за уши. Уродовать сетевой стек ради нетфликс-унтерменшей с их 4к на мобилках?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #115, #172

74. Сообщение от Аноним (80), 21-Мрт-21, 14:14	+/–
> к этой строке надо конкатенировать другую строку "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" Написано. Читаем внимательно. For this header field, the server has to take the value (as present    in the header field, e.g., the base64-encoded [RFC4648] version minus    any leading and trailing whitespace) and concatenate this with the    Globally Unique Identifier (GUID, [RFC4122]) "258EAFA5-E914-47DA-    95CA-C5AB0DC85B11 Вы вообще не поняли что там написано и про что этот GUID. Это просто идентификатор, что сервер поддерживает WebSocket. Это не "ключ". Вся эта церемония нужна чтобы КЛИЕНТ понял что да, ответ пришёл от сервера и этот сервер поддерживает WebSocket. И что это не ответ другому клиенту (для этого используется клиентский "ключ"). Который тоже ни фига не ключ, а просто уникальный идентификатор. Все что клиенту нужно это ответ сервера сравнить с sha1(clientKey+"...GUID") строка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #96

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

76. Сообщение от DildoZilla (?), 21-Мрт-21, 14:26	+/–
GMTP -- Google Money Transfer Protocol/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #123

77. Сообщение от DildoZilla (?), 21-Мрт-21, 14:30	+/–
А если рыть дальше, то можно увидеть взаимозависимость ещё и с основным разговорным языком и грамотностью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #91

78. Сообщение от СеменСеменыч777 (?), 21-Мрт-21, 14:34	–1 +/–
> в срачах про микроядро vs монолит вы вовсю кричите что надо все в юзерспейс все очень просто. некоторое время тому назад видеодрайвера Х были в юзерспейсе. но потом мультимедия поперла и производительности стало не хватать. так идеология проиграла практике.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

79. Сообщение от petrg (ok), 21-Мрт-21, 14:34	+/–
В треды не возвращаются <мрачная музыка>... Выше уже написано в чём проблемы и зачем этот протокол захотели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

80. Сообщение от Аноним (80), 21-Мрт-21, 14:43	+/–
Однако JavaScript за это никто не уважает, скорее наоборот. Хотя сейчас на нём написано больше всего кода в мире.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #88

81. Сообщение от Аноним (81), 21-Мрт-21, 14:48	–1 +/–
Опять растаманы перепутают ">" и "<=".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

82. Сообщение от Аноним (71), 21-Мрт-21, 14:55	–1 +/–
Там вроде нормально производительный http3 клиент не на расте до сих пор только у МС, пока не появится нормальной реализации им только полторы корпы и будут пользоваться. И если 3 проседает на воздушном соединении как и 2, то он вообще не упал пользователям, а сервера пусть используют что хотят для общения между собой (это всё же сокращение трафика и задержек, процентов на 5-15 может). Зачем в браузеры эту гадость тянуть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

83. Сообщение от kissmyass (?), 21-Мрт-21, 14:56	–1 +/–
Поставил себе IceCat и снес новую поделку мозилки. Все работает. Тот же FF только не курильщика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #140

84. Сообщение от Аноним (71), 21-Мрт-21, 15:00	+/–
Это пока не начинают приходить пакеты из будущего (что сплошь и рядом), тогда ты начинаешь ценить тцп. Да и к потерям как я посмотрю тцп куда устойчивее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #147

85. Сообщение от Ordu (ok), 21-Мрт-21, 15:00	+/–
>> И чё? Это приводит к каким-то неприятностям, или что? > Вот! Прекрасная иллюстрация моего комментария о говнокодерах, искалеченном мозге и невозможности > им быть программистами. Отличный аргумент. Я люблю такие. Убеждают на все 100%. Остальные вопросы отпадают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #93

86. Сообщение от Аноним (81), 21-Мрт-21, 15:00	–2 +/–
> раст не нужен. У FF, которого растаманы покусали, всего 1% рынка, так что - да, не нужен оказался. А про QUIC сам Гугл уже высказался, что это была ошибка, ничего хорошего на практике не получилось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #130, #230, #232

87. Сообщение от Аноним (81), 21-Мрт-21, 15:04	+/–
> отключить HTTP/2 из-за сильных тормозов Гугл уже давно именно про это и говорил, что ошиблись, вводя новый стандарт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #183, #206

88. Сообщение от kissmyass (?), 21-Мрт-21, 15:04	+/–
Так на С написано написано огромное количество хорошего кода, и при всех сложностях отличного софта. А на JS написано в основном от безысходности в том или ином виде тонны говнокода. Как бы так сказать разное наследие у этих языков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

89. Сообщение от Аноним (81), 21-Мрт-21, 15:04	+/–
Гугл уже отказывается от http/2
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #132

90. Сообщение от Урри (ok), 21-Мрт-21, 15:14	+/–
> Со своей стороны кстати заметил, что худший жс-код нередко получается у тех, > кто ранее кодил на шарпе или джаве - там будто бы > какая-то профессиональная деформация В джаве все есть класс. Так что да, профессиональная деформация. Это, кстати, большой минус джавы о котором профессионаллы не уставали говорить с момента ее появления. >> Что гугл захотел, то пропихнул. > Хоть засмейся. Это ситуация последних лет. Открываем стандарт, читаем шапку. "I. Fette, Google, Inc., A. Melnikov, Isode Ltd.". Вопрос на 100 очков - кто их этих четырех имел средства и авторитет для решающего голоса? Почему никто из этих четырех, если он действительно разрабатывал стандарт, а не пытался по быстрому продавить нужное решение, так и не сподобился за 11 лет его доделать до состояния "де-юре не драфт"? > И да, это именно результат компромисса: один протолкнул одно и все в > итоге согласились, другой - другое, третий - третье, но остальные принципиально > забили и фича загнулась. Это касается всякой бесплатной мелочи. Крупные вещи, на которых так или иначе можно заработать, усиленно проталкиваются. Тот же ssl принудительно всовывается без всякого мыла даже без попыток как-то подсластить пилюлю. > поскольку полностью игнорируют наличие > множества участников, планы и приоритеты которых нечасто совпадают Ой как вы меня сейчас насмешили... У дочери как раз сегодня андроид обновился на ее самсунге, пришла с требованием вернуть все взад, так как "они все поменяли, я не знаю где что теперь, неудобно". И что, ее планы и приоритеты кто-то учитывает? А планы и приоритеты тех сотен миллионов, у которых более неподдерживаемые версии ведроида и которые вынуждены покупать новые девайсы потому что софт на старых больше не запускается? У меня огромный телек на стене, которому еще полгода нет. Умеет в браузер. Месяц назад ютубчик на нем стал так тормозить, что невозможно смотреть. В итоге я отказался от ютуба, настроил автозакачку через youtube-dl и смотрю через minidlna. Мои и других пользователей кто-то спрашивал, прежде чем навесить еще какой-то мегатормозной фреймворк на, секундочку, страничку с одним встроенным фреймом и десятком скриншотов? Нет. Гугл просто взял и навесил. И фиолетово, что оно выедает ресурсов не как отобразить десяток картинок и немного текста, а как вычислить последствия ядерного удара на атмосферу Титана при прохождении рядом космического шторма. Наивность прям как у ребенка. > реализация должна по максимуму сохранять обратную совместимость с тем что уже есть. Вы меня сегодня доконаете. Я помру от смеха.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #209

91. Сообщение от Урри (ok), 21-Мрт-21, 15:18	+/–
> А если рыть дальше, то можно увидеть взаимозависимость ещё и с основным > разговорным языком и грамотностью. С разговорным языком это никак не связано, много уже было проведено опытов. А грамотность скорее просто следствие уровня образованности и порядка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

92. Сообщение от Аноним (-), 21-Мрт-21, 15:20	–25 +/–
>>>> +15, >>> -11 >>> +11 >> -11 > Quod erat demonſtrandũ. Хабро-истеричка совсем не палиццо ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

93. Сообщение от Урри (ok), 21-Мрт-21, 15:22	+2 +/–
> Отличный аргумент. Я люблю такие. Убеждают на все 100%. Остальные вопросы отпадают. Ну еще бы не любил. Типичный (коих 95%) человек обязательно выберет способ избавиться от неприятных и/или непонятных аргументов путем концентрации на не относящееся к делу, но потенциально обидное. Это был комментарий не для тебя, а для других. А ты проходи мимо, не порти себе нервы, эффект Даннинга-Крюгера не спит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #95

94. Сообщение от Ilya Indigo (ok), 21-Мрт-21, 15:25	–2 +/–
> WebSockets. Очевидно, нужная вещь. Работающая. Полезная. Никогда не понимал, зачем использовать это трудно-реализуемое дерьмо, если есть простой и нативный (для HTTP протокола), SSE, который в тандеме с redis отлично работает!?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #98, #223

95. Сообщение от Ordu (ok), 21-Мрт-21, 15:34	+/–
>> Отличный аргумент. Я люблю такие. Убеждают на все 100%. Остальные вопросы отпадают. > Ну еще бы не любил. Типичный (коих 95%) человек обязательно выберет способ > избавиться от неприятных и/или непонятных аргументов путем концентрации на не относящееся > к делу, но потенциально обидное. Ты льстишь себе. Ты можешь на говно изойтись тут и меня не обидеть. У тебя просто интеллекта не хватит. На самом деле ни у кого на опеннете не хватит интеллекта меня обидеть, потому оно даже потенциально не обидное. А вот ad hominem в качестве аргумента, и ноль технической аргументации -- это уже диагноз. > Это был комментарий не для тебя, а для других. Да-да, оправдывайся теперь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #100

96. Сообщение от Урри (ok), 21-Мрт-21, 15:34	+/–
> Читаем внимательно. Попробуйте, пока у вас не вышло. > Вы вообще не поняли что там написано и про что этот GUID. > Это просто идентификатор, что сервер поддерживает WebSocket. Это не "ключ". Вы не смогли осилить мой комментарий, правда? Я вам процитирую главное. --- cut --- Внимание, вопрос: почему в стандарте не написано "сгенерируйте текстовую строку из разрешенных символов? Почему не написано "к этой строке надо конкатенировать другую строку "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"? Почему там требование ненужного base64 и ненужного guid? --- cut --- Строка "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" не GUID. Это просто строка, для конкатенирования к другой строке, принятой от клиента. Не к base64-кодированным данным, а к обычной строке, ведь декодирования не происходит. GUID - это 16 байт. Конкатенируемая "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" - это строка. For this header field, the server has to take the value (as present in the header field, e.g., the base64-encoded [RFC4648] version minus any leading and trailing whitespace) and concatenate this with the Globally Unique Identifier (GUID, [RFC4122]) "258EAFA5-E914-47DA- 95CA-C5AB0DC85B11 Перевод: сервер должен взять строку из заголовка и прибавить к ней другую строку. Все. Слова base64-encoded, RFC4648, GUID, RFC4122 совершенно лишние и вообще никакого смысла в данном случае не несут. Не сервер должен декодировать base64 строку и добавить к ней сгенерированный guid. Нет. Сервер должен взять пришедшую строку и добавить к ней строку "258EAFA5-E914-47DA- 95CA-C5AB0DC85B11". Клиент, который будет проверять ответ, тоже должен взять эти строки. Не свои случайно сгенерированные 16 байт, как написано в стандарте "The value of this header field MUST be a nonce consisting of a randomly selected 16-byte value that has been base64-encoded", а уже закодированную в base64 строку. Смысла в генерации этих байт по стандарту нет. Можно сразу генерировать строку похожую на base64 (из алфавита a..z=), от этого смысл ни на йоту не поменяется. Теперь понимаете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #111

97. Сообщение от анончик (?), 21-Мрт-21, 15:37	+/–
у меня netgear orbi прошлого поколения. wifi по сравнению с кабелем -- разница меньше миллисекунды (2мс и так и так до сервера в провайдерской сети). если добавить вторую точку доступа, которая общается с первой по беспроводу, получаем плюс миллисекунду (3мс до сервера в провайдерской сети). а ещё у меня есть старый роутер из 2013, netgear r7000. там тоже две миллисекунды пинг что по проводу, что по беспроводу. интересно а у amplifi какой порядок вносимой latency? iPony, ты тут?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

98. Сообщение от Урри (ok), 21-Мрт-21, 15:41	+/–
Не знал о таком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #107

99. Сообщение от Урри (ok), 21-Мрт-21, 15:43	–1 +/–
И поэтому все ААА игрушки пишут на плюсах. Сразу видно человека сложнее хелловорлда ничего не написавшего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #127

100. Сообщение от Урри (ok), 21-Мрт-21, 15:48	+/–
Вся техническая аргументация была в первом комментарии. Не моя проблема, что твой сверхинтеллект не смог ее осилить а смог только выдавить из себя "ну работает же, не вижу проблемы". Ну да, не видишь, о чем и речь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #101

101. Сообщение от Ordu (ok), 21-Мрт-21, 15:57	+/–
> Вся техническая аргументация была в первом комментарии. Пфф... Ты вопроса моего не заметил? Просто так языком болтал? > Ну да, не видишь, о чем и речь. Старайся сильнее -- может тебе всё же удастся меня оскорбить? Докажи нам своё превосходство в интеллекте. Мы болеем за тебя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #103

102. Сообщение от Аноним (75), 21-Мрт-21, 16:08	+/–
5g обещает сверхмалые пинги. Wi-Fi AC даёт их уже на частоте 5 ГГц.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #116, #149, #220

103. Сообщение от Урри (ok), 21-Мрт-21, 16:20	+/–
Зачем мне тебя оскорблять и доказывать совершенно очевидные вещи? Ты еще попроси доказать что днем светло и ночью темно. И почему ты о себе говоришь "мы"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #113

104. Сообщение от боня (?), 21-Мрт-21, 16:25	–1 +/–
> Раст уже обгоняет С по производительности Спорное утверждение. Я бы предположил, что они примерно одинаковы по производительности. Так же есть и синтетические тесты, "доказывающее" обратное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

105. Сообщение от user90 (?), 21-Мрт-21, 16:33	–1 +/–
Честно говоря, абсолютно не интересно, чо там в бетах Фокса. Скорее такое надо оформлять в виде сводок "в очередной раз похерено вот то и вот это", но новостями это быть не может))
Ответить | Правка | Наверх | Cообщить модератору

106. Сообщение от th3m3 (ok), 21-Мрт-21, 16:48	+1 +/–
А что на счёт борьбы с цензурой в сети? Поможет сделать так, чтобы провайдеры меньше лезли в трафик пользователей?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #109

107. Сообщение от Ilya Indigo (ok), 21-Мрт-21, 16:48	+2 +/–
> Не знал о таком. https://developer.mozilla.org/ru/docs/Web/API/Server-sent_ev... Не удивительно. Google так любит кукарекать о своих монструозных и ненужных поделках, таких как websockets, AngularJS, docker, kubernates и прочих или вообще ненужных или нужных только узкому круку специалистов, занимающимися облаками, но они про них кукарекают молодым специалистам, но ни слова не говорят о самые обычном и нативном, таком как SSE, redis, systemd (capibilities). Год назад передавал свой web-проект молодому разработчику, который нишиша не знает о linux, о том как настраивать nginx и php-fpm, уже молчу про то чтобы создавать и настраивать systemd-юниты, но он знает про docker и как устанавливать nginx и php из докера! На вопрос, на хрена тебе сдался докер!? Он отвечает, что это удобно надёжно и безопасно... На мой комментарий о том, что всё что делает докер можно сделать и использую capibillities в systemd, и это будет и удобнее и надёжнее, он говорит про них он не знает для него это слишком сложно, меня учили так и мне сказали что это надёжно и безопасно... И как я и ожидал, у него хорошенько подгорело, когда он узнал что в проекте используется ещё и redis... Ведь для redis нужен отдельный контейнер и настроить взаимодействие между этими контейнерами выставив привелегии и общие файлы... И самое умное что он сделал это спросил, а нельзя ли УБРАТЬ redis из проекта. XD XD XD В общем такие гугловые специалисты растут....
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #118, #143

109. Сообщение от Аноним (81), 21-Мрт-21, 16:55	–6 +/–
Нет, не поможет... В Штатах тебя сдадут анбешникам твои же родственники.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #112

110. Сообщение от Kuromi (ok), 21-Мрт-21, 17:04	+/–
Выпилено только в релизном. В Бету about:config вернули.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #186

111. Сообщение от Аноним (80), 21-Мрт-21, 17:19	+/–
По-порядку. ---> Почему не написано "к этой строке надо конкатенировать другую строку "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" Ты английский не понимать? Я тебе прямым текстом цитату скинул в прошлый раз. Ещё раз, но попроще... ---> concatenate this with "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" in string form ----> сгенерируйте текстовую строку из разрешенных символов Там не надо ничего генерировать. Это уникальный идентификатор протокола, ты до сих пор этого не понял? Вернул эту строку - значит соответствует спецификации стандарта WebSocket. ---> Строка "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" не GUID ---> GUID - это 16 байт GUID - это стандарт того, как генерировать "уникальный" идентификатор. Если строка сгенерирована по спецификации - это GUID. Точка. Если другие строки будут сненериоованы по спецификации - шансы коллизий минимальны. Или ты хочешь сказать что если я в коде сненерировал GUID и начал им пользоваться (и сервер / клиент / пользователь) увидел его - это уже не GUID? Тут просто взяли и сгенерировали GUID и вставили в стандарт. И это GUID ровно в том самом смысле - соответствует спецификации стандарта. Открываем стандарт https://tools.ietf.org/html/rfc4122. Читаем... ---> The formal definition of the UUID string representation is... "258EAFA5-E914-47DA- 95CA-C5AB0DC85B11" - это не строка. Это строковое представление GUID. ---> Внимание, вопрос: почему в стандарте не написано "сгенерируйте текстовую строку из разрешенных символов Что там сервер будет "генерировать"?) Версию протокола? Ещё раз - этот GUID не определяет уникальность сервера, он определяет какой спецификации он соответствует. Поэтому он в тексте стандарта. Там могла быть любая, достаточно уникальная строка, типа "rfc-5432-websocket". Наоборот, подумали и перестраховались, а не влепили что попало. Это как раз показатель продуманного и хорошего стандарта. ---> ведь декодирования не происходит Не происходит. Весь смысл base64 в этом ... ---> Base encoding of data is used to store or transfer data restricted to US-ASCII [1] data. Base encoding can also be used in new applications that do not have legacy restrictions, simply because it makes it possible to manipulate objects with text editors. Те чтобы ты мог легко декодировать данные, которые приходят по HTTP. Ведь HTTP это текстовый протокол. А данные могут передаваться по нему самые разные. И этот base64 используется в сотнях, если не тысячах RFC для HTTP чтобы реально кодировать / декодировать данные. И HTTP клиенты / серверы уже имеют base64 кодировку. И есть куча библиотек для этой кодировки. Логично использовать её же, тк HTTP стандарты должны имееть преемственность и дружить друг с другом. А тут приходит такой Вася - эксперт с opennet и говорит "Нинужна! Сложна!" надо "Можно сразу генерировать строку похожую на base64 (из алфавита a..z=)". Те Вася предлагает НОВУЮ кодировку, "похожую". Под конкретно этот стандарт. Остальные заголовки будут приходит в base64, а этот "из алфавита a..z=". А потом ещё одну, под другой...и ещё одну... Хорошо что стандарты пишут "говноделы из Google", а не "эксперты с opennet". Надеюсь что так и дальше останется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #117

112. Сообщение от th3m3 (ok), 21-Мрт-21, 17:21	+2 +/–
> Нет, не поможет... В Штатах тебя сдадут анбешникам твои же родственники. Наркоман? Вопрос бы про цензуру в сети, про провайдеров которые лезут в трафик пользователей. Не было речи про что-то незаконное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #122

113. Сообщение от Ordu (ok), 21-Мрт-21, 17:21	+/–
> Зачем мне тебя оскорблять и доказывать совершенно очевидные вещи? А чем ты здесь занимаешься интересно? Если не тем и не этим, то чем? > И почему ты о себе говоришь "мы"? Ты же выше говорил о том, что твои слова предназначены всем читателям? Вот я от их лица и жду. Хоть чего-нибудь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

114. Сообщение от Аноним (115), 21-Мрт-21, 17:22	+1 +/–
Ну вот, осталось запилить HTTP/4 с обходом цензуры, и будет шикарно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #121, #151

115. Сообщение от Аноним (115), 21-Мрт-21, 17:23	–1 +/–
Скоростей хватает. А задержки никуда не делись.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #146

116. Сообщение от Аноним (115), 21-Мрт-21, 17:34	+1 +/–
Речь о пингах до оператора. Дальше пакет может улетать очень далеко и на долго. И здесь никаких перспектив, ибо скорость света ограничена, и количество промежуточных узлов, вносящх задержку, сильно не уменьшится ввиду привязке структуры сети к геополитике.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #124

117. Сообщение от Урри (ok), 21-Мрт-21, 17:36	+/–
Мда. Сплошнолй фейспалм. Ordu выше и то умнее выступил. Что я могу на все это ответить? Только одно: "Прекрасная иллюстрация #2 озвученного в первом комментарии тезиса. Даже более красноречивая, чем #1". Очередной эффект Даннинга-Крюгера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #119

118. Сообщение от Урри (ok), 21-Мрт-21, 17:39	+1 +/–
Ну тот проект я уже давно сдал, а за информацию спасибо. Почитаю и если придут с похожей задачей возможно попробую предложить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

119. Сообщение от Аноним (80), 21-Мрт-21, 17:49	+/–
Ну вот Васе и нечего по-сути ответить, по спецификации. Вася не умеет внимательно читать и, тем более, понимать спецификации. Вась, признавайся, эникейщиком работаешь али в отделе кадров засидаешь. Твой технический и экспертный уровень понятен. Он... сколько таких "Вась-экспертов" с opennet. На джуниора не тянешь. Проходи повышение квалификации, может я тебя к себе может возьму.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

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

121. Сообщение от Аноним (81), 21-Мрт-21, 17:54	–2 +/–
Надеешься обойти американскую цензуру?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #154, #176

122. Сообщение от Аноним (81), 21-Мрт-21, 17:55	–4 +/–
в Штатах никогда твой трафик не был секретом у провов. И не будет секретом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #150

123. Сообщение от Аноним (34), 21-Мрт-21, 18:06	+1 +/–
Google Monkey Tree of Palm
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

124. Сообщение от Аноним (75), 21-Мрт-21, 18:13	+/–
Вы знаете хоть одну пару мест  мире пинги между которыми больше 250 мс? 250 мс это четверть секунды, за четверть секунды к Вам прилетит потерянный фрагмент. Кстати TCP не прерывает приём данных из за потерь, просто он временно не сможет создать непрерывный поток и отдать его приложению. Но он всё ещё скачивает данные пока буфер не забъётся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #157

125. Сообщение от rvs2016 (ok), 21-Мрт-21, 18:53	–1 +/–
Это что - новый протокол управления передачей? TCP - на свалку истории? Теперь надо будет ваять туннели через http/3? Всем сервисам теперь надо добавлять функциональность over HTTP/3 поди? ssh over http/3 smtp over http/3 ну и всё остальное...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #141

127. Сообщение от Аноним (127), 21-Мрт-21, 19:21	+/–
ААА игрушки в большинстве случаев пишут не с нуля, а с использованием готовых движков, которые прибивают тебя к С++. И за 5,5 лет ещё никто не написал достаточно сложного игрового движка. Плюс у Rust и для работы с графикой и видеокартой пока не освоена на промышленном уровне. А игровым студиям зарабатывать денежки надо, а не технологии применять. > Сразу видно человека сложнее хелловорлда ничего не написавшего. Да, Урри, Вас видно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

128. Сообщение от timur.davletshin (ok), 21-Мрт-21, 19:33	–1 +/–
> Для UDP (RFC 1980-x годов) не нужны, но речь про QUIC. Вот > эти (с Гугелем не связаны) https://udt.sourceforge.io/ тоже считают UDP недостатком и > надстраивают. Я тебе ещё раз говорю, что гугл просто реализует ещё один уровень абстракций для передачи пользовательского трафика. QUIC - это самый обычный UDP, поверх которого надстроен контроль целостности потока (из глобальных вещей).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #134

129. Сообщение от Аноним (-), 21-Мрт-21, 19:38	–1 +/–
> Тот же congestion control теперь не от ядерной реализации какого-нибудь cubic, Которому в современном мире так то давно уже пора сдохнуть жестокой смертью, за саботаж нетворкинга. Ибо на вайфай или сотовом линке с минимальной потерей пакетов или нестабильным RTT он мигом сливается до скоростей диалапа, плевать хотев что там 100+ мегабит с редкими неидеальностями. Поэтому юзер телепает со скоростью диалапа пока линк бездействует и там ничерта и близко похожего на congestion, просто шум в канале какой-то проскочил. > от криворукости хромоделов. Как показал пример кубиков и рено эти господа хтонически не способны делать то что должны. Гугель с горя bbr накодил, один из самых вменяемых для беспроводных линков. Но даже он умеет дурить. Но главное... есть такая штука - винда. И в нее невозможно свой планировщик пакетов втулить. Поэтому с кодинга bbr профит наступает далеко не у всех. А юзеры винды костерят адские времена загрузки сайта. Потому что их планировщик писаный поди еще в эру диалапа работает вот так. И, вот, оказывается что единственный способ принести счастье всем это сделать подобие TCP из UDP самому. При этом более вменяемый планировщик таки достанется всем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #167

130. Сообщение от Total Anonimus (?), 21-Мрт-21, 19:39	+1 +/–
Про долю - ваша фантазия , а по гуглу - некомпетентность , гугл заменяет в хроме QUIC именно на HTTP/3 .
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #142

131. Сообщение от Аноним (-), 21-Мрт-21, 19:40	–2 +/–
> Милый, там congestion алгоритмов уже выше крыши, выбирай на вкус. А теперь придумай как сделать чтобы юзеры винды не воняли что сайт долго грузится. Пересадить их всех на линь все же оверкилл, браузер им переставить таки сильно проще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #211

132. Сообщение от Total Anonimus (?), 21-Мрт-21, 19:42	+/–
От хрома гугл тоже отказывается ? )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

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

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

135. Сообщение от Аноним (133), 21-Мрт-21, 19:46	–1 +/–
> Редко заходишь, значит: в релизных мобильных версиях доступ к about:config выпилили с > августа прошлого года. Мозилла всегда умеет пользователей порадовать. Может, им начать пистолеты с 1 патроном своим пользователям бесплатно рассылать? Ну так, на правах маркетинга. Если уж проклятые юзеры так надоели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

136. Сообщение от Аноним (-), 21-Мрт-21, 19:51	+/–
> Заходим на роутер и делаем iw dev wlan0 station dump и срём > кирпичами от tx retries ))) ЧСХ для всех этих кубиков сие в лучшем случае будет ростом пинга, в хучшем потерей пакета, если лимит retries кончился. "ААА, ЛИНК ПЕРЕГРУЖЕН". И похрен что это шум в канале, а вовсе не перегруз линка. Так что вот вам всем диалапные скорости, а линк в 100+ мегабит в это время...  ничегонеделает?! Очень оптимально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

137. Сообщение от Аноним (-), 21-Мрт-21, 19:52	+/–
> Это на каком-то гoвнoтике 15летней давности? Только что сопоставил з кабелем у > себя - вайфай добавляет 3ms. Тебя не смущает что все это зависит не только от тебя но и от шума, соседей и хрен его знает каких еще барабашек? Нет, если ты один живешь на километры вокруг - тогда, конечно, оно так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #192

138. Сообщение от Аноним (-), 21-Мрт-21, 19:54	+/–
> Простите, чем он лучше для маскировки VPN'а? Да-да, я не про инкаспуляцию > TCP в TCP, а именно про маскировку. Ну хотя-бы тем что TCP -> TCP работает как полное УГ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #159

139. Сообщение от Аноним (-), 21-Мрт-21, 19:58	+/–
> Так вот, повторюсь - HTTP/3 такое же непродуманное ненужно. Для веб-страничек не > нужен очередной велосипедный TCP, им и классического с головой хватает. Угу, пока в вафле или сотовом линке шумок в канале лаг не повысит или пару пакетов не выбьет. После этого кубические рено устраивают форменный диалап, в то время как линк бездействует и близко не перегружен. И так то оно ничего - но вот смотрит юзер ютут - бац - крутится. Хотя, казалось бы и канал в инет жирный, и вафля не загружена. А вот поди ж ты, факап на ровном месте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

140. Сообщение от macfaq (?), 21-Мрт-21, 19:59	+/–
Айскат ещё жив? Последние версии вроде бы базировались на ff pre-fenix и после 68.х не обновлялись.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #194, #195

141. Сообщение от Аноним (81), 21-Мрт-21, 20:00	–1 +/–
наоборот, ничего добавлять не надо, чтобы и /2, и /3 исдох на корню.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #152, #175

142. Сообщение от Аноним (81), 21-Мрт-21, 20:04	–2 +/–
> гугл заменяет в хроме QUIC... > заменяет QUIC > QUIC Открой глаза и перечитай, я именно это тебе и говорил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130

143. Сообщение от Аноним (-), 21-Мрт-21, 20:04	–1 +/–
Да ладно тебе, вебсокеты не монструозные. Там конечно есть скелеты в шкафу, но вообще простой дровяной протокол, его даже мелкий lwan себе запилил. И таки оно именно нормальный поток, с произвольными данными, более потребный для околореатлаймных коммуникаций типа чатика или апдейтов статусов/переменных. А не какой там HTTP на костылях. Хоть вебмакаки и навебмакачили, конечно, малость. HTTP сам по себе сильно монструознее - и имеет множество бестолковостей. В том числе очень вредных. Например желающие могут загуглить про slowloris и чего вообще можно делать с HTTP даюы нагнуть вам сервер. Ну вот например размер хидеров никак особо не лимитирован, и если саботер будет их слать в час по чайной ложке, большая часть серваков вообще конекцию не закроет и будет жрать ресурсы на обслуживание слоупока условно-вечно. Если слоупок был вредителем и наплодит таких конекций - довольно скоро сервер утрачивает способность обслуживать легитимных юзеров. Самому слоупоку атака обходится не сильно дорого по ресурсам, у него контекст может быть сильно меньше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #155

144. Сообщение от Аноним (-), 21-Мрт-21, 20:08	–1 +/–
> Чем это Опера самый лучший? Просвятите неумытого ? Просвящать немытых - прерогатива священников.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

145. Сообщение от Аноним (-), 21-Мрт-21, 20:11	–1 +/–
> до его полноценного внедрения дело не дошло и его уже пришлось > заменять новым протоколом? В смысле не дошло? Теперь буквально каждый второй сайт в дебагтулсах кажет HTTP/2. Нихрена себе не дошло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

146. Сообщение от Аноним (-), 21-Мрт-21, 20:13	–1 +/–
> Скоростей хватает. А задержки никуда не делись. А также дичь которую творит congestion control на беспроводных линках. Когда быстрый и не загруженный линк стараниями tcp congestion control резко превращается в диалап.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

147. Сообщение от Аноним (-), 21-Мрт-21, 20:15	–1 +/–
> Да и к потерям как я посмотрю тцп куда устойчивее. "Зависание - самое стабильное состояние". Примерно так это в TCP и работает - с потугами слать пакет раз в... в... в 60, чтоли, секунд максимум? Ну а вы минуту покурите бамбук, если потери пакетов в беспроводном линке так оказались. И похрен что шум в канале давно пропал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

148. Сообщение от Аноним (127), 21-Мрт-21, 20:16	+2 +/–
> в плюсах есть различные умные указатели, которые проблему полностью решают; а отсутствие > обычных указателей можно автоматически гарантировать на этапе приемки простым скриптом на баше; > в плюсы элементарно встраивается сборщик мусора и т.д. и т.п. Только вот всё совсем наоборот. Тот же Торвальдс к плюсам относится плохо, предпочитает чисты Си, в том же время против Rust ничего плохого не имеет. Хотя бы потому что > в плюсах есть различные умные указатели, которые проблему полностью решают Это неправда. > в плюсы элементарно встраивается сборщик мусора И это не совсем правда, спросите у Microsoft, запиливший реализацию C++/CLI, поддержку которого почему-то в .NET Core не завезли. Интересно - почему? Не от того ли, что С++ всё-таки плохо решает (но решает!) задачи, в которых он используется? И не от того ли Вы сами назвали Rust конкурентом C, а не C++, тогда как создатели языка никогда его так не позиционировали? > "let r2 = &mut num as *mut i32" Если Вам не нравится код, который Вы написали - может быть дело не в языке? Если Вас пугает этот код, то низкоуровневый код на С/С++ Вам точно не стоит открывать. Вот серьёзно, Вы сами выдумали, что Rust - конкурент C, из этого кучу проблем вывели. У C своя ниша, у Rust - своя, никто (кроме Вас, что как бы намекает) не называл его "убийцей C".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #164, #250

149. Сообщение от Аноним (-), 21-Мрт-21, 20:17	–1 +/–
> 5g обещает сверхмалые пинги. Wi-Fi AC даёт их уже на частоте 5 ГГц. Радио не бывает 100% надежным. Вздрист шума в канале и вот вам уже сверхмалые 50 мс. А то и потеря пакетов. А в клиническом случае и link loss. Думаете, как глушаки работают? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

150. Сообщение от Аноним (-), 21-Мрт-21, 20:18	+1 +/–
> в Штатах никогда твой трафик не был секретом у провов. И не будет секретом. В штатах АНБ не имеет права копаться в трафике граждан. Во внешнем - сколько угодно :). Они на это очень жестко кислотой плевались когда хацкеры Exchange стали выносить. Видите ли внутренних хаксоров в результате совсем не видно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

151. Сообщение от Аноним (-), 21-Мрт-21, 20:20	+1 +/–
> Ну вот, осталось запилить HTTP/4 с обходом цензуры, и будет шикарно. Так вон там в соседней новости есть прога - хоть и не с HTTP, но по части цензуры вещь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #161

152. Сообщение от Аноним (-), 21-Мрт-21, 20:21	+/–
> наоборот, ничего добавлять не надо, чтобы и /2, и /3 исдох на корню. Еще беспроводные линки не забудь запретить, где TCP работает... никакуще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #156

153. Сообщение от еманйам (?), 21-Мрт-21, 20:21	–2 +/–
http + websocket +jsonrpc2 решают все эти проблемы и велосипедить ничего не надо
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #179

154. Сообщение от Аноним (-), 21-Мрт-21, 20:22	+3 +/–
> Надеешься обойти американскую цензуру?! Кремлеботики набежали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

155. Сообщение от Ilya Indigo (ok), 21-Мрт-21, 20:24	+/–
Что за дичь Вы несёте!? Зассанный казачёк от Гугл или просто идиот? Slowloris и прочие атаки возможны только на коряво настроенном сервере. На нормальном сервере (последний nginx с дефолтными настройками) таймауты и прочие ограничения такого сделать просто не дадут, а если кто-то попытается, то в логах этот вредитель быстро будет замечен и забанен. WebSockets монструозен, по сравнению с SSE, на котором и чатики и всё остальное, включая обновления страницы в реальном времени без перезагрузки, можно гораздо легче и эффективнее организовать. Шли бы Вы со своим Иваном и прочими гулоботами отсюда нафиг!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #168

156. Сообщение от еманйам (?), 21-Мрт-21, 20:24	–1 +/–
ото udp будет работать какуще... знаем мы эти приколы с mtu и mss. стоит какому-нибудь горе-хостеру отрубить сервисные протоколы и начинаются "нипанятнаотчего" падающие пакеты. кто не в курсе, гуглите --clamp-mss-to-pmtu
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #178

157. Сообщение от Аноним (-), 21-Мрт-21, 20:24	+1 +/–
> Вы знаете хоть одну пару мест  мире пинги между которыми больше 250 мс? Попробуй центр крупного города или большой дом с соседями, чудак. Увидишь много чудес, вплоть до ютуба который что-то loading и не поспевает, хотя линк вроде бы изумительный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #158, #243

158. Сообщение от Аноним (75), 21-Мрт-21, 20:38	+/–
Речь шла о проводе после беспроводки. Страдальцам в диапазоне 2,4 ГГц можно только посоветовать переползать в 5 ГГц. По поводу "изумительного" 4g можно сказать лишь то, что сотовой оператор очень сэкономил на вышках и там тупо не хватает пропускной способности. Это не техническая проблема, а организационная. И от UDP там лучше не станет. Собственно Гугл давно по умолчанию использует quic для своих сервисов, а YouTube всё ещё лагает. Гугл кстати тоже любит деньги экономить и наивно ждать от него 4к в прайм-тайм.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #174

159. Сообщение от timur.davletshin (ok), 21-Мрт-21, 20:54	–1 +/–
> Ну хотя-бы тем что TCP -> TCP работает как полное УГ. Что характерно, именно поэтому я эту оговорку и сделал, но ты даже её не понял.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

160. Сообщение от timur.davletshin (ok), 21-Мрт-21, 20:58	+1 +/–
> Просто TCPшный congestion control на беспроводных линках вытворяет черт знает что, и > вы телепаете со скоростью диалапа от того что там какой-то всперд > помех в канале изредка случается. TCP из эпохи диалапа не в > курсе радиопроблем и полагает что линк перегружен. И вот у вас > 100 мегабитный линк, не занятый ничем, а вот тспшная конекция со > скоростью диалапа. Думающая что линк типа-перегружен, раз пакеты теряет или RTT > прыгает. Хотя это просто нормальный курс событий при радиолинке. Ну давно же уже всё протестировали и даже статью на русский на Хабре перевели. Зачем повторять малорелевантные профессиональные заблуждения?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #162

161. Сообщение от Аноним (81), 21-Мрт-21, 21:24	–1 +/–
> есть прога Каждый смотритель котиков ставит себе кучу троянов, чтобы никто не узнал, что он смотрит котиков :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151 Ответы: #177

162. Сообщение от Аноним (-), 21-Мрт-21, 21:46	–2 +/–
> Ну давно же уже всё протестировали и даже статью на русский на > Хабре перевели. Зачем повторять малорелевантные профессиональные заблуждения? Я не знаю какие вебмакаки с хабры что "тестировали" и переводили - поэтому говорю то что видел своими глазами, лично. TCP с кубиком может в определенных ситуациях drop to the floor! На ровном месте практически. А уж если там какой дисконект случился, или что еще, и нетворкменеджер целые 5 секунд ждал реконекта - вообще 3.14-ц конекции, будет полминуты одуплять. При том что канал есть, идеальный, но, вот шизанутая логика кубиков и ко с конским таймаутом когда он следующую попытку чуть не через минуту будет делать - имеется. И при малейих отклонениях от идеала в линке (что для беспроводки норма жизни) оно умеет совершенно по дурацки коллапсировать на ровном месте. Собственно поэтому гугол и накодил BBR, закомитив его в майнлайн на секундочку (может даже заенаблил ведроидам, черт знает). Есть еще CDG похожий по смыслу, мне он показался менее эффективным, но и менее чудесатым. BBR более вменяемо реагирует - пытается различать вот реально долговременный перегруз и кратковременные всперды в канале. Но делает он это с переменным успехом, а самое печальное во всей этой истории - то что у юзеров винды его нет и не будет. Поэтому они в ряде ситуаций получают реально околодиалапные скорости и делают мозг саппорту гугля что мол видео на ютубе отлипает. Так что cubic и ко это как раз пример технологии эры диалапа, которые в современном мире умеют в нехилый thrashing и саботаж если не повезло. На беспроводных линках невезение усиливается пропорционально поганости качества линка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #169

163. Сообщение от Аноним (-), 21-Мрт-21, 21:50	+2 +/–
> Ещё дополню "преимущества" QUIC: Лучше следить за пользователями... Это как? Чем он от TCP или HTTP так уж принципиально отличается в этом аспекте?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #251

164. Сообщение от Аноним (-), 21-Мрт-21, 21:54	+/–
>> в плюсах есть различные умные указатели, которые проблему полностью решают > Это неправда. Если пошла такая пьянка, Boehm GC так то и на сях есть. Наверное и еще дохрена кого, этого просто чаще всего упоминают. > У C своя ниша, у Rust - своя, никто (кроме Вас, что как бы намекает) не называл его "убийцей C". Они местами пересекаются. Может поэтому? Однако попрогать на хрусте под PIC12, имхо, хайпожорам будет слабо. Слишком мелкотравчатый, хелловорлд весь чип займет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #207

165. Сообщение от Ivan_83 (ok), 21-Мрт-21, 22:02	+/–
С uTP эпичность была в том, что некоторые провайдеры не лимитировали скорость UDP, в итоге у некоторых юзеров вместо 20 мегабит стало всего 100 для торрентов :) А СС вроде быстро утрясли, да и проблема там не имела эпических масштабов, потому что даже если отдавать на максимальной скорости - всё равно отдашь только один чанк за раз, а они не такие большие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #189

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

167. Сообщение от Ivan_83 (ok), 21-Мрт-21, 22:11	+/–
Когда юзер венды приходит смотреть видео на ютупе, то передающая сторона в виде гугла юзает bbr и юзер счастлив, а какой там СС у юзера - малозначительно, ибо он получает а не передаёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #184

168. Сообщение от Аноним (-), 21-Мрт-21, 22:12	+/–
> Зассанный казачёк от Гугл или просто идиот? Тот кто поигрался с HTTP, ws и издевательствами над ними на низком уровне, а также и потестивший всякие странные приколы. Пойдет? :) > Slowloris и прочие атаки возможны только на коряво настроенном сервере. ЧСХ на момент его появления такими были чуть более чем все. А наименее корявым - IIS (фэйспалм!) Кроме того - вот именно хорошего фикса slowloris'а не существует в природе. Попытка фикса либо будет гасить юзеров на медленных и перегруженных каналах, либо у слоупока дочерта времени слоупочить, занимая на себя ресурсы. > На нормальном сервере (последний nginx с дефолтными настройками) таймауты и > прочие ограничения такого сделать просто не дадут, а если кто-то попытается, то в > логах этот вредитель быстро будет замечен и забанен. Блажен кто верует. Во первых, так можно забанить и юзеров на протормозившем линке. Во вторых, при именно атаке сие можно и распределенно прилунить. В третьих он все-равно достаточно эффективный, я проверял, создать проблемы серваку - реально. > WebSockets монструозен, по сравнению с SSE, на котором и чатики и всё > остальное, включая обновления страницы в реальном времени без перезагрузки, можно гораздо > легче и эффективнее организовать. Я не знаю кому там и что "легче" но выглядит это как попытка натянуть сову на глобус. А ws таки может быть совершенно отдельный канал, не имеющий ничерта общего с HTTP и его протоколом после его подъема, по поводу чего там может гулять эффективный task-specific протокол, вообще никак не завязаный на HTTP и ближе всего это, натурально, к сетевому сокету. И я не вижу ничерта сложного с подъемом ws, это и в js делается парой строк, да и на стороне сервера не сильно сложнее. В lwan examples этого есть и назвать все это сложным - глум над здравым смыслом. > Шли бы Вы со своим Иваном и прочими гулоботами отсюда нафиг! Каким еще иваном? И вообще, я к гуглу прохладно отношусь, что не мешает считать вебсокет довольно удобным и простым для периодического апдейта каких-то данных или околореалтаймных штук типа чатиков. А кучка легаси и вебмакакинга в протоколе - ну да, но тупняков и в HTTP есть. Черт, мы даже не знаем размер хидеров заранее, как минимум в HTTP/1.x точно. И поэтому даже не можем сразу отлупить заведомо офигевшего клиента (типа slowloris'а) - только дурацкой эмпирикой выезжать, которая неуниверсальна и косит легитимных юзерей под шумок, виноватых тем что в каком-нибудь поезде ехали и линк тупил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155

169. Сообщение от timur.davletshin (ok), 21-Мрт-21, 22:16	+/–
> Так что cubic и ко это как раз пример технологии эры диалапа Краткое понимание глубины вопроса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #185

170. Сообщение от Аноним (-), 21-Мрт-21, 22:17	+/–
> Уже не просто есть, но уже и декомиссован. И, конечно, ты покажешь линк подтверждающей это смелое заявление? А то нетмонитор совершенно не подтверждает этот чудный тезис: 70% конекций было HTTP/2.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

171. Сообщение от Ivan_83 (ok), 21-Мрт-21, 22:22	+/–
Нет, это вы ходите кругами изобретая свой TCP, и заново СС для него.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #197

172. Сообщение от Ivan_83 (ok), 21-Мрт-21, 22:24	+/–
Нетфликс как раз не юзает UDP, они пилят rack+brr в ядро фри и вроде ядерный TLS тоже их рук дело.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

173. Сообщение от YetAnotherOnanym (ok), 21-Мрт-21, 22:26	+/–
Ого, сколько минусов. Вот это подгорело у кого-то! Я собой горжусь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #187

174. Сообщение от Аноним (-), 21-Мрт-21, 22:32	+/–
> Речь шла о проводе после беспроводки. Страдальцам в диапазоне 2,4 ГГц можно > только посоветовать переползать в 5 ГГц. Как ты думаешь, сколько каналов по 160 МГц этого вашего новомодного AC там поместится? Диапазон не резиновый :) Поэтому сорян, но в погоне за гигабитами сосед уже начал фонить в ваш канал и если он удумает торенты качать - упс! А если так с десяток козлин вокруг - еще накупивших супермощных микроволновок, т.к. иначе оно даже до соседней комнаты не долетает - в общем то там уже начинается то же самое. А чтобы вы совсем не скучали, понавесили еще всяких беспроводных допплер-радаров чуть менее чем везде (охрана и автовключение света). Эти обычно в 5ГГц гадят. Не очень мощно, но популярные и напиханы много где. > По поводу "изумительного" 4g можно сказать лишь то, что сотовой оператор очень > сэкономил на вышках и там тупо не хватает пропускной способности. Вы можете проспонсировать им пару сот. Они явно не откажутся от такого подарка. А еще только подумайте, бывает движущийся транспорт! Там беспроводные линки нестабильны by design. Хотя-бы потому что условия приемя круто и быстро меняются и с этим сложно что-то сделать. Поэтому всегда возможна ситуация когда вон те 5 секунд пакеты не летали в принципе. Для гамна типа кубика это приговор! Он будет туповэйтить минуту, за которую юзер как раз проедет мимо офигенной соты через которую мог бы уже давно скачать полинтернета и полчаса видео в буфер. А к моменту когда он расчехлится на retry, сота как раз опять пропадет - и в общем это даже не диалап. > Это не техническая проблема, а организационная. А юзер едущий в поезде или машине - это какая проблема? В мозгах тупарей не понявших что сети стали повсеместными, беспроводными, и с очень разными и динамично меняющимися условиями? > И от UDP там лучше не станет. Там принципиально нет конских таймаутов в минуту, а планировщик может как-то сильно более вменяемо реагировать на упомянутые ситуации. При том все это счастье будет доступно и юзерам виндов. А то что у гомнопровайдеров их шыт с бсд позагибается - чтож, потанцуем на могилке тех кто не умеет работать. Из время вышло. > Собственно Гугл давно по умолчанию использует quic для своих сервисов, а YouTube всё ещё лагает. Проблема в том что на TCP он не только лагает - но иногда умудряется делать это вообще на ровном месте. > Гугл кстати тоже любит деньги экономить и наивно ждать от него 4к в прайм-тайм. В этом как ни странно мы похожи. Поэтому мне эффективный протокол не делающий мозг тоже пригодится. А все эти кубики в современном мире реально заколебали и должны умереть. Они из эпохи диалапа и работат под стать, полагая что лаг в 60 секунд - ОК. За это время юзер на транспорте проезжает пару сот, бжад!!! И все эти потуги грубо иррелевантны тому что вокруг творится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158

175. Сообщение от Аноним (175), 21-Мрт-21, 22:42	+/–
Согласен, только перфокарты голубиной почтой! Остальное от хипстеров!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #180, #239

176. Сообщение от Аноним (176), 21-Мрт-21, 22:43	+1 +/–
> Надеешься обойти американскую цензуру?! У них цензура довольно беззубая по сравнению с многими другими. Ну вон git.rip рипнули, так и то - только домен, а по айпишнику он живой и веселый, чего там обходить? Конечно за стебный домен обидно, но в таком виде его стебность даже повысилась и это сойдет за фичу. К тому же это подтолкнет развитие распределенных технологий и будет полезно вовсе не только американцам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #196

177. Сообщение от Аноним (176), 21-Мрт-21, 22:46	+1 +/–
Чтобы твои хозяева и прочие сильно умные не могли лезть в мой траф, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

178. Сообщение от Аноним (176), 21-Мрт-21, 22:48	+2 +/–
> ото udp будет работать какуще... знаем мы эти приколы с mtu и mss. У udp самого по себе принципиально нет дичи с ростом таймаута перепосылок до 60 секунд как в бредокубиках, вытворяющих адский трэшак на беспроводном линке, особенно если юзер не дай боже перемещается и линк нестабильный. > стоит какому-нибудь горе-хостеру отрубить сервисные протоколы и начинаются "нипанятнаотчего" > падающие пакеты. кто не в курсе, гуглите --clamp-mss-to-pmtu ЧСХ опять же TCP-проблемы в основном.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156

179. Сообщение от Аноним (176), 21-Мрт-21, 22:49	+1 +/–
> http + websocket +jsonrpc2 решают все эти проблемы и велосипедить ничего не надо Вебсокет при неидеальностях линка точно так же уйдет в конские 60-секундные таймауты как и HTTPшная конекция. Это вообще уровнем ниже TCP делает, ему похрен что там, он и IRC таким макаром тормознет на минуту, ему не жалко.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153

180. Сообщение от Аноним (176), 21-Мрт-21, 22:51	+/–
> Согласен, только перфокарты голубиной почтой! Остальное от хипстеров! О, даешь IPFSOAC. IPFS Over Avian Carriers. Запрошенные файлы доставляет птичка с флешкой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

181. Сообщение от Аноним (181), 21-Мрт-21, 22:51	+/–
Non-normative означает всего лишь то, что секция написана языком, не соответствующим rfc2119.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

183. Сообщение от Аноним (-), 21-Мрт-21, 22:57	+1 +/–
Пруфлинк?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

184. Сообщение от Аноним (-), 21-Мрт-21, 23:04	+/–
> Когда юзер венды приходит смотреть видео на ютупе, то передающая сторона в > виде гугла юзает bbr и юзер счастлив, а какой там СС > у юзера - малозначительно, ибо он получает а не передаёт. Вообще-то линк там таки двусторонний by design и юзер периодически должен как минимум запрашивать чанки с чанксервера. Иначе он тупо не получит очередной сегмент.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #202

185. Сообщение от Аноним (-), 21-Мрт-21, 23:07	+/–
> Краткое понимание глубины вопроса. Я эту глубину вопроса в отличие от хабры таки потестировал самолично - и остался недоволен тем как это работает в условиях отличных от идеала.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

186. Сообщение от Аноним (36), 21-Мрт-21, 23:09	+/–
Ты наверное читаешь плохо? Я же сразу написал: > в релизных мобильных версиях Ты, наверное, догадываешься, что бета - это не релиз, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #237

187. Сообщение от Аноним (-), 21-Мрт-21, 23:14	+/–
> Ого, сколько минусов. Вот это подгорело у кого-то! Я собой горжусь. У меня больше (как минимум - минусов)! Кстати, тезис об истерящих питонистах-жопоскриптозниках получил довольно веское подтверждение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173

188. Сообщение от Аноним (188), 21-Мрт-21, 23:18	+/–
> Вы просто вообще и близко не в теме, даже похоже тут новости не читаете. > СС нынче больше десятка разных есть, самые современные это rack* и bbr. Спасибо кэп! Собственно вторым я и пользуюсь на беспроводных линках. Но работает он все же достаточно чудесато временами. И если уж мы про новости, в относительно недавних кернелах гугл как раз починил очень стебный баг, когда эта их офигенная мегаинновация могла в энной ситуации ... сдуреть и надолго задушить канал до вот реально диалапных величин, вообще по сути игнорируя внешние раздражители. Волшэбно, просто волшэбно. Потом ветеран-юникс-недоразумения удивляются почему это их полглобуса оказывается давно мечтает в утиль списать. Потому что компьютерные системы работающие вот так давно всех заколебали. > Более старые но всё ещё клёвые htcp, hybla, ну и потом кубики с ньюрено. Есть несколько фундаментальных проблемок. Сущая ерунда: 1) Это требует мануальной настройки админами. 2) По поводу чего хренова куча серверов которые этим не парились. 3) Юзерам виндов во всех их ипостасях все это счастье не светит в принципе. 4) Сервера на винде таки тоже бывают. Вон любимые эксченжи поха подтвердят :) > Разница между htcp и bbr/rack* на плохих линках может до 5 раз > доходить, из того что я видел, те где htcp даёт 1 > мегабайт/сек bbr держит 3, прыгая до 5. Теперь попробуйте все это на винде устроить, решатели проблем, итить. Нуагули, гугол с сабжем будет более-менее одинаково работать везде. Потому что их congestion control не завязан на причуды конкретного кернела как раз. Который у юзеров винды малость проблематично пропатчить. И если кто еще не понял, эра ветеран-юникс-недоразумений кончается как раз потому что ваши представления о юзабилити и том как работает этот мир - полное дно, оторванное от реальности. А по факту получается трэшак работающий абы как. Вы уж извините, но я очень плотно анализировал бзики TCP под сетевым анализатором, и имею свое мнение о том трэшаке который я видел. Когда линк львиную долю времени тупо idle без особых причин.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #201

189. Сообщение от Аноним (188), 21-Мрт-21, 23:22	+/–
Еще там был тупняк что при congestion он размер пакета уменьшал. Тот же объем трафа начинал создавать больше пакетов. Сие очень доставляло наколенным софтроутерам гамнолокалок - при намеке на туняки их добивало мелкими пакетами, что вызывало неиллюзорный батхерт :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165

191. Сообщение от Аноним (36), 21-Мрт-21, 23:51	+/–
> Это не имеет отношения к теме разговора. Будет желание - можем обсудить отдельно. Очень даже имеет: ты привёл в пример вебсокеты, как пример "Буяк-буяк-и-в-продакшен" (и правильно привёл), но ведь в самом популярном браузере в мире вот это вот всё  с вебсокетами написано не на расте. Сам назовёшь, на чём? > в плюсах есть различные умные указатели, которые проблему полностью решают Если решают, то почему проблема еще не решена? Это был риторический вопрос. Правда в том, что не решают. > заплатанного монстра франкенштейна с кучей различных стенографических значков. Как вам поинтеры &, &mut, *const, *mut...? Как вам выражение "let r2 = &mut num as *mut i32"? Красиво? Интуитивно? Логично? Если уж речь про красоту и интуитивность - не страшнее ассемблера выглядит, но это просто к слову. Ну вот, говорил "Мы то знаем и помним, как правильно делать подобные вещи.", а сам непривычного синтаксиса испугался. Я, кстати, читал спор, который вот так же начинался: "этот ваш синтаксис в расте - г*вно, надо было логичнее". Но на вопрос предложить лучше в каждом конкретном случае - не мог: косяки ипротиворечия лезли в "пропозалах". Вообще, для того, кто "знает и помнит, как правильно делать подобные вещи" ты ведь прекрасно должен быть в курсе, что новички требуют синтаксис поочевиднее (но он всегда получается многословнее), а профи хотят синтаксис "поэффективнее". И баланс найти сложно. И языки, котоыре выбрали первый путь или вымерли или являются нишевыми, а которые выбрали второй - стали стандартами отрасли. И именно так вместо написания очень очевидного, красивого, интуитивного и логичного "equal" во многих современных ты пишешь значок типа "=", вместо "more" "less" - "<" и ">" и т.д. Такого полно и в сях и в плюсях и еще почти во всех СЯПах. Просто там ты уже знаешь синтаксис и привык, а в расте - не знаешь и/или не привык (и не хочешь, а в этом случае уже ничего не поможет). > Вы же не наймете таджиков проектировать из говна и палок небоскребы только потому, что "нормальных архитекторов мало, сложно найти"? А это не и мне не тебе решать, увы. Нанять одних только супепрофи (и получить с них потом суперкод) еще никому не удалось. Оффтоп: к слову, о небоскрёбах - поищи фотки строителей первых Нью-Йоркских небоскрёбов - вполне себе "таджики" по американским меркам были. > Этот сомнительный плюс Если этот плюс защищает от некой (ЧАСТОЙ!) категории ошибок, то это хороший плюс. Например, это самый частый тип ошибок в коде фаерфокса, по заявлению самой мозиллы. Они из-за этого и стали раст пилить-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

192. Сообщение от анончик (?), 22-Мрт-21, 00:01	+/–
в исходном условии было сказано, что барабашек нет, смотри: > при идеальной связи
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137

193. Сообщение от Сейд (ok), 22-Мрт-21, 01:04	+/–
Как прописать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #203

194. Сообщение от kissmyass (?), 22-Мрт-21, 01:47	+/–
> Айскат ещё жив? > Последние версии вроде бы базировались на ff pre-fenix и после 68.х не > обновлялись. нет возможности сейчас посмотреть мобильный, но десктоп под мастдай 78.7.1esr (64-bit)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

195. Сообщение от kissmyass (?), 22-Мрт-21, 01:50	+/–
> Айскат ещё жив? > Последние версии вроде бы базировались на ff pre-fenix и после 68.х не > обновлялись. ну да зашел на f-droid, мобильная версия чет тухленькая Version 68.4.2 (680412) suggested Added on 2020-02-04
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #255

196. Сообщение от Аноним (81), 22-Мрт-21, 02:00	+/–
> цензура довольно беззубая Всего-то лет 20 за внутренний терpopизм дают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #198

197. Сообщение от Аноним (-), 22-Мрт-21, 02:05	+1 +/–
> Нет, это вы ходите кругами изобретая свой TCP, и заново СС для него. А что поделать если работа TCP грубо иррелевантна современным реалиям? Оно вообще полагает нормальным таймаут догонять до чуть ли не минуты. Очень офигенно работает в движущемся транспорте, соты мелькают мимо, но вы ни бита не передадите из-за туповэйтинга. Зачем такой протокол в 2021 году уперся?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171 Ответы: #205

198. Сообщение от Аноним (-), 22-Мрт-21, 02:08	+2 +/–
> Всего-то лет 20 за внутренний терpopизм дают. А вы попробуйте как шаман в капитолии потусить в кремле, для сравнения. С удовольствием засеку сколько дадут вам. Если выживите, конечно: кмк у амеров охрана сильно менее охотно в своих граждан стреляет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

199. Сообщение от kissmyass (?), 22-Мрт-21, 02:09	+1 +/–
> Трафик неотличим от HTTP. > К тому же сейчас с обычным TLS можно пописать в SNI какой-нибудь > ненужный dropbox, facebook, или на что там ваш мобильный оператор безлимитку > дает - и качайте себе весь интернет нахаляву. > Как с этим в HTTP/3 не знаю, для меня это уже неактуально. а ты уверен что он по SNI тарифицирует, а не по рейнджам или подсетям?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #204

200. Сообщение от Аноним (200), 22-Мрт-21, 03:56	+4 +/–
Следить за пользователями с QUIC становится сложнее, поэтому товарищу майору выгодно посеять к нему недоверие вот такими засланными казачками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

201. Сообщение от Ivan_83 (ok), 22-Мрт-21, 04:10	+/–
Это проблемы вашего линуха, у меня нет линуха, а у гугла нет в нём проблем :) Если этим никто не парился - значит у людей нет такой проблемы. Сервера на венде могут стоять и за прокси в виде nginx, который будет менять СС по сути, так что это не проблема даже для тех кто держит сервисы на венде. Я вам ещё раз говорю: на венде обычно потребляют трафик и поэтому какой там у них СС никого не колышит. Не знаю что вы там анализировали, у меня была всегда простая цель: получить либо максимальную скорость либо достаточную чтобы иптв не заикалось, и мне даже hybla под линухом хватало. Во фре были проблемы, до появления rack, возможно там сейчас и дефолтный tcp допилят в 13-14 версиях до состояния как линухе. Эра не венды/огрызка только начинается, но вы этого не видите ещё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188 Ответы: #247

202. Сообщение от Ivan_83 (ok), 22-Мрт-21, 04:13	+/–
СС работает только на передающей стороне, что тут непонятного? На принимающей стороне СС хоста принимающего в процессе приёма не учавствует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #249

203. Сообщение от Ivan_83 (ok), 22-Мрт-21, 04:14	+2 +/–
HTTP Injector - тема халявщиков с 4пда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #259

204. Сообщение от Ivan_83 (ok), 22-Мрт-21, 04:15	+1 +/–
Где взять столько людей чтобы уследить за этими подсетями?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199 Ответы: #234

205. Сообщение от Ivan_83 (ok), 22-Мрт-21, 04:21	+/–
Реалии отличаются от ваших представлений о них. Роуминг - это из другой оперы, но если вы собираетесь перепосылать любой пакет который не аскнули за 100-500мс то вы положите сеть, аналогично если будете перезапрашивать так агресивно. И TCP довольно гибко аскает и запрашиват ретрансмиты, если что.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #245, #263

206. Сообщение от Аноним (206), 22-Мрт-21, 04:44	+1 +/–
Можно какие-то ссылки? Интересно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

207. Сообщение от Аноним (127), 22-Мрт-21, 06:21	+/–
> Если пошла такая пьянка, Boehm GC так то и на сях есть. Наверное и еще дохрена кого, этого просто чаще всего упоминают. И как успехи у Boehm GC? Вы его сами использовали или нагуглили только что? > Они местами пересекаются. Может поэтому? Однако попрогать на хрусте под PIC12, > имхо, хайпожорам будет слабо. Слишком мелкотравчатый, хелловорлд весь чип займет. А с какой целью кто-то вообще будет писать под микроконтроллеры на языке, заточенном под современные многоядерные процессоры? Не станете же вы в борщ масло класть. Борщ - не каша, насколько мне известно. И микроконтроллеры, насколько мне известно, не спроектированы для параллелизации вычислений. Да и проблема незрелости Rust до сих пор нерешена - компилятора родного нет, пока ни Google, ни Microsoft, ни кто-либо другой не проинансировали разработку полноценного компилятора, а не того MVP, что есть сейчас.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #225, #261

209. Сообщение от Lex (??), 22-Мрт-21, 07:52	+/–
> Открываем стандарт, читаем шапку. "I. Fette, Google, Inc., A. Melnikov, Isode Ltd.". > Вопрос на 100 очков - кто их этих четырех имел средства > и авторитет для решающего голоса? Почему никто из этих четырех, если > он действительно разрабатывал стандарт, а не пытался по быстрому продавить нужное > решение, так и не сподобился за 11 лет его доделать до > состояния "де-юре не драфт"? Стандартов официальных, "стандартов" на стадии допиливания / черновиков и просто замыслов под будущие стандарты более чем немало, нередко сами конторы не совсем понимают что конкретно в итоге "выстрелит" и пример гугла с целой кучей когда-то начатых, а потом заброшенных проектов, равно как и веб-техноллогий - тому наглядный пример. Само-собой, что в итоге будет принят чей-то стандарт, который пилила в основном конкретная контора( пусть нередко и с правками и доработками, предложенными другими сторонами ), поскольку нельзя принять несколько почти_одинаковых стандартов, друг другу прямо противоречащих. С другой стороны, если другие участники упрутся "рогами" и ни в какую не захотят принимать стандарт, а далее - его исполнять, ценность подобного стандарта будет примерно нулевая( а то и отрицательная ). > Это касается всякой бесплатной мелочи. Крупные вещи, на которых так или иначе > можно заработать, усиленно проталкиваются. Тот же ssl принудительно всовывается без всякого > мыла даже без попыток как-то подсластить пилюлю. Не надо путать конечных пользователей, которых никто никогда не спрашивал и сами конторы, которые пилят сервисы, браузеры и проч. У вас то ли с головой беда, то ли вы целенаправленно уходите от темы - речь изначально шла ИСКЛЮЧИТЕЛЬНО О КОНТОРАХ, ОТВЕТСТВЕННЫХ ЗА РАЗРАБОТКУ. Про конечных пользователей разговора В ПРИНЦИПЕ не шло. Нынешний веб - результат компромисса между более-мене крупными конторами, а не конечными пользователями, многие из которых в принципе не знают, что такое сокет, шифрование или жс. >> поскольку полностью игнорируют наличие >> множества участников, планы и приоритеты которых нечасто совпадают > Ой как вы меня сейчас насмешили... У дочери как раз сегодня андроид > обновился на ее самсунге, пришла с требованием вернуть все взад, так > как "они все поменяли, я не знаю где что теперь, неудобно". > И что, ее планы и приоритеты кто-то учитывает? А планы и > приоритеты тех сотен миллионов, у которых более неподдерживаемые версии ведроида и > которые вынуждены покупать новые девайсы потому что софт на старых больше > не запускается? [2] Не надо путать конечных пользователей, которых никто никогда не спрашивал и сами конторы, которые пилят сервисы, браузеры и проч. > У меня огромный телек на стене, которому еще полгода нет. Умеет в > браузер. Месяц назад ютубчик на нем стал так тормозить, что невозможно > смотреть. В итоге я отказался от ютуба, настроил автозакачку через youtube-dl > и смотрю через minidlna. > Мои и других пользователей кто-то спрашивал, прежде чем навесить еще какой-то мегатормозной > фреймворк на, секундочку, страничку с одним встроенным фреймом и десятком скриншотов? > Нет. Гугл просто взял и навесил. И фиолетово, что оно выедает > ресурсов не как отобразить десяток картинок и немного текста, а как > вычислить последствия ядерного удара на атмосферу Титана при прохождении рядом космического > шторма. [3] Не надо путать конечных пользователей, которых никто никогда не спрашивал и сами конторы, которые пилят сервисы, браузеры и проч. > Наивность прям как у ребенка. [4] Не надо путать конечных пользователей, которых никто никогда не спрашивал и сами конторы, которые пилят сервисы, браузеры и проч. >> реализация должна по максимуму сохранять обратную совместимость с тем что уже есть. > Вы меня сегодня доконаете. Я помру Ради б.-га. Если внимательно посмотрите на веб, то "внезапно" обнаружите, что до сих пор вполне-себе работают сайты на старых версиях цсс и хтмл. Более того, последующие версии тех штук обычно являются именно дополненными предыдущими( иногда с багфиксом. Так-то много нюансов особенно касательно жс в зависимости от браузера и даже его типа - мобильный/десктоп, но сути это не меняет ). Более того, даже жс весьма старых версий( более 10 лет ) без браузероспецифичных штук - очень даже запросто будет исполняться в современных жс движках. Если с каждым выходом нового стандарта ломать обратную совместимость, от нынешнего веба останется процентов 5-10. Хотя, та замороченность с переходом на https, конечно, разговор отдельный. Есть подозрение, что конторам-браузеростроителям очень не нравится, что посредники могут перехватывать часть той "бигдаты" вместо приобретения ее у того же гугла.. или правительства могут совершенно законно контролировать траффик и ловить потенциальных террористов( без отстегивания тому же гуглу. Хотя в США они и так могут - крупные медиаконторы обязаны передавать "куда надо" ключи для расшифровки. Не передают - не работают в сша )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #224

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

212. Сообщение от Аноним (211), 22-Мрт-21, 08:18	+/–
а асинхронно запрашивать религия не позволяет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #222

220. Сообщение от Random (??), 22-Мрт-21, 11:05	+/–
Это пока 5 ГГц не так засраны (соседями), как 2.5 "Связь бывает или проводная, или никакая"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

221. Сообщение от onanim (?), 22-Мрт-21, 11:13	+/–
подробнее, пожалуйста. если я повешу к себе на сервер самоподписанный сертификат для odnoklassniki.ru или там facebook.com, то внезапно трафик к моему серверу перестанет тарифицироваться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

222. Сообщение от Ordu (ok), 22-Мрт-21, 11:36	+/–
> а асинхронно запрашивать религия не позволяет? Что асинхронно запрашивать? TCP не позволяет попросить передать вон тот файлик на 4Gb, передавая пакеты асинхронно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212

223. Сообщение от Додо (?), 22-Мрт-21, 11:56	–1 +/–
Потому что SSE односторонний - с сервера к клиенту. Для отправки данных от клиента к серверу придется использовать HTTP запросы и как-то отправлять ответ через SSE. Вебсокеты - двухсторонние. Можно получать данные от клиента, можно отправлять данные клиенту. Обработку данных можно производить в рамках одного класса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #233

224. Сообщение от Урри (ok), 22-Мрт-21, 12:03	+/–
Прочитал. Понял. Существенных возражений нет, а по несущественным сраться уже лень.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209

225. Сообщение от Урри (ok), 22-Мрт-21, 12:54	+/–
> И как успехи у Boehm GC? Вы его сами использовали или нагуглили только что? Я использовал. Это очень известный проект.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #207 Ответы: #246

226. Сообщение от anonnn (?), 22-Мрт-21, 13:40	+3 +/–
И как насчет трафика через socks proxy , теперь? Почти что нет соксов которые утп проксируют
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #244

227. Сообщение от Я (??), 22-Мрт-21, 13:46	+/–
так это же плюс. конечный пользователь на ядерные реализации протоколов влиять не может а вот сменить хром на фуррифокс где реализации получше уже может, а ещё лучше чтоб вообще про это всё не знать а мультимилионные корпорации сами следили чтоб всё работало..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

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

229. Сообщение от Я (??), 22-Мрт-21, 13:54	+/–
там ведь не на те беспроводные сети заточка делается где у вас стационарные устройства на вайфае висят, а на мобильники где сигнал переменчивый и часто плохой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #231

230. Сообщение от Я (??), 22-Мрт-21, 14:00	+/–
как растаманы могли покусать лисов если лисы вообще изначально создали раст чтобы в том числе писать на нём более безопасный код браузера и тогда у них ещё операционка мобильная была для неё он тоже создавался.?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

231. Сообщение от timur.davletshin (ok), 22-Мрт-21, 14:03	+/–
> там ведь не на те беспроводные сети заточка делается где у вас > стационарные устройства на вайфае висят, а на мобильники где сигнал переменчивый > и часто плохой. Вафля из-за интерференции давно уже вошла в эпоху траблов с появлением 80 и 160 MHz каналов и даже несмотря на все эти ваши бимформинги и прочие пердоли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229

232. Сообщение от Я (??), 22-Мрт-21, 14:04	+/–
не получилось у квика стать общепринятым и распространённым стандартом. именно поэтому он был переработан в нттр/3 так чтобы даже сафаревцы его внедрили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

233. Сообщение от Ilya Indigo (ok), 22-Мрт-21, 14:05	+/–
> Потому что SSE односторонний - с сервера к клиенту. Ещё один гуглобот... Потому что через HTTP есть дофига способов отправить сообщение от клиента к серверу, в отличие от WebSockets, который НЕ может работать через HTTP, и он ВЫНУЖДЕН реализовать канал от клиента к серверу, который в случае с SSE просто не нужен, так данные в обе стороны проходят через HTTP в рамках одного класса! И этот вынужденный костыль, маркетолухи гугла раскручивают как мегафичу...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #223 Ответы: #240

234. Сообщение от kissmyass (?), 22-Мрт-21, 15:11	+/–
> Где взять столько людей чтобы уследить за этими подсетями? так по SNI или DNS можно собрать в автоматическом режиме, а подтвердить можно например по тайтлу страницы или просто по количеству, с левым SNI будет с 10-ок человек, а к реальному пейсбуку будут ломиться тысячи запросов мне конечно опъепалово системы очень нравится, но думаю что они закроют это, если еще не закрыли
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204

235. Сообщение от Чума (?), 22-Мрт-21, 15:32	+/–
https://www.youtube.com/watch?v=GM-e46xdcUo
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

236. Сообщение от Аноним (236), 22-Мрт-21, 15:40	+1 +/–
> данные можно передавать сразу после отправки пакета установки соединения А разве не нужно сначала согласовать TLS, а потом уже данные передавать?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #238

237. Сообщение от Kuromi (ok), 22-Мрт-21, 16:02	+/–
> Ты наверное читаешь плохо? Я же сразу написал: >> в релизных мобильных версиях > Ты, наверное, догадываешься, что бета - это не релиз, да? Ты наверное не в курсе, что не так давно about:config в мобильной версии был доступен ТОЛЬКО в Nightly, так что разблокировка фичи в Бете - это уже прогресс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186

238. Сообщение от Аноним (71), 22-Мрт-21, 17:09	+/–
Обычно вначале спрашивают поддерживает ли и какие алгоритмы, в http/2 можно сделать предположение что да поддерживает и сэкономить время и трафик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #236

239. Сообщение от marginal282 (?), 22-Мрт-21, 17:09	+/–
Для голубей нужно будет стороить голубятню, закупать ячмень и следить за их здоровьем. Хотя стоп, это всё равно удобнее, чем работать с истеричками из гугл и мозилла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

240. Сообщение от Додо (?), 22-Мрт-21, 18:42	+/–
> Ещё один гуглобот... Попрошу без перехода на личности. Называть всех, кто не согласен с вашим мнением, ботами - это признак дурного тона и некомпетентности. > Потому что через HTTP есть дофига способов отправить сообщение от клиента к > серверу, в отличие от WebSockets, который НЕ может работать через HTTP, > и он ВЫНУЖДЕН реализовать канал от клиента к серверу, который в > случае с SSE просто не нужен, так данные в обе стороны > проходят через HTTP в рамках одного класса! С использованием HTTP можно отправить данные от клиента к серверу: 1. в пути запроса, через query-переменные; 2. в заголовках запроса; 3. в теле запроса (при использовании методов POST, PUT, PATCH). Это не "дофига способов", это только три. Если отправлять сообщения при помощи SSE, от сервера к клиенту, то можно указать только event и тело. В Websocket можно указать только тело сообщения. При запросе апгрейда соединения - еще query параметры и заголовки (хоть передачу заголовков мало кто поддерживает). В конечном счете все сводится к тому, что практически всегда данные передаются в теле запроса, в том или ином сериализованном виде. И с этой точки зрения нет никакой разницы, что использовать. Кстати, у SSE есть большой, жирный минус: через него нельзя передавать бинарные данные, у него используется \n\n как разделитель сообщений. > И этот вынужденный костыль, маркетолухи гугла раскручивают как мегафичу... И SSE, и Websocket были разработаны в рамках группы WHATWG. В нее как бы не только Google входит. Если смотреть на данные https://caniuse.com/ , то поддержка Websocket в Chrome появилась с версии 4, SSE с версии 6. Не такой уж большой разрыв. Кстати, там же можно заметить, что в Firefox Websocket появился в версии 4, а SSE в версии 6 (такое вот совпадение) - что, Mozilla в далеком 2011 году тоже продалась Google, раз реализовала Websocket раньше SSE? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #233 Ответы: #241

241. Сообщение от Ilya Indigo (ok), 22-Мрт-21, 19:09	+/–
> Это не "дофига способов", это только три. А этого мало, или мы за неимением аргументов переходим к придиркам к словам? > В конечном счете все сводится к тому, что практически всегда данные передаются > в теле запроса, в том или ином сериализованном виде. > этой точки зрения нет никакой разницы, что использовать. То есть Вы признаёте что двунаправленность WebSockets это просто маркетинговый пиар, а вовсе не преимущество над SSE. > Кстати, у SSE есть большой, жирный минус: через него нельзя передавать бинарные > данные, у него используется \n\n как разделитель сообщений. Необходимость передачи бинарных данные у меня и не возникала, но решается элементарно с base64. >> И этот вынужденный костыль, маркетолухи гугла раскручивают как мегафичу... > И SSE, и Websocket были разработаны в рамках группы WHATWG. В нее как бы не только Google входит. Не важно кто входит в группу, важно кто пиарит или каким-то образом поддерживает этот пиар. docker и kubernates тоже не один гугл разрабатывает, но вкладывается пиар, прямо или косвенно, именно он!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #240 Ответы: #254

242. Сообщение от Онаним (?), 22-Мрт-21, 21:47	+/–
Я его из-за багов в haproxy уже успел два раза выключить и назад включить за последние 1.5 года... С QUIC/http3, сдаётся мне, будет ещё хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

243. Сообщение от Онаним (?), 22-Мрт-21, 21:50	+/–
Да хосспаде, почти любой ресурс в Китае за 200, если из этой страны пинговать или из Европы. Спасибо их "анальному файрволу".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

244. Сообщение от Аноним (115), 22-Мрт-21, 21:51	+/–
HTTP/1 и 2 никто не отменяет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226

245. Сообщение от Онаним (?), 22-Мрт-21, 21:52	+/–
Радует пока одно: порубав UDP с src/dst=443, можно от этого счастья избавиться почти гарантированно, если сеть не позволяет работать слишком агрессивным клиентам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205

246. Сообщение от Аноним (127), 22-Мрт-21, 23:36	+/–
И как он под PIC12 идёт? Не мешает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225

247. Сообщение от Аноним (247), 22-Мрт-21, 23:44	+/–
> Это проблемы вашего линуха, В _моем_ линухе эта проблема (как минимум частично) решена. Но есть нюансы. Я - не вся планета. И даже на гугле мир не заканчивается. > у меня нет линуха, а у гугла нет в нём проблем :) Это не решение способное принести счастье если не всем то большинству юзеров. Кроме гугла есть еще 100500*100500 сайтов, у клиентов есть винды всякие, и проч. При том последнее не подконтрольно даже гуглу. Собственно оттуда и идея юзать UDP. > Если этим никто не парился - значит у людей нет такой проблемы. Уход в отрицание? Если прочитать топик - можно заметить что сетевые инженеры гугла (а теперь и мазилы) иного мнения. И с чего бы это вдруг они UDP юзать взялись? Может с того что строить всех академморонов и индусов на тему congestion control за столько лет заколебало даже гугл? :) > будет менять СС по сути, так что это не проблема даже > для тех кто держит сервисы на венде. Правильно, вместо того чтобы исправить проблему - вобьем костылей там и тут. А потом оказывается что в дороге мувик вообще не посмотришь толком, да и чатики тупят неимоверно, а нжинкса и вообще сервак с правильными настройками доперли поставить далеко не все. Надеяться на интеллект всяких эникеев ползающих под столом не приходится, а нанимают часто их, они дешевле. А потом оказывается что трансляция какой-нибудь мелкой местечковой фигни идет так что без слез не взглянешь. > Я вам ещё раз говорю: на венде обычно потребляют трафик и поэтому > какой там у них СС никого не колышит. Красиво было на бумаге да забыли про овраги. И выбирая между вами и инженерами гугла, гугловым я таки больше верю. У них это напрямую в бабки и churn отливается. > Не знаю что вы там анализировали, у меня была всегда простая цель: > получить либо максимальную скорость либо достаточную чтобы иптв не заикалось, и > мне даже hybla под линухом хватало. А теперь простой эксперимент: попробуйте сие посмотеть взяв мобилку и плюхнувшись в кресло в машине (пассажирское конечно) едучи по трассе, с не особо стабильным покрытием. И как, хорошо получается? Можете в фоне пустить хотя-бы пинг для понимания фактической доступности канала, прикинуть utilisation канала и проч. Если вы этим профессионально заниметесь то наверное и получше это сможете организовать. > Во фре были проблемы, до появления rack, возможно там сейчас и дефолтный > tcp допилят в 13-14 версиях до состояния как линухе. Как вы понимаете проблема TCP congestion control несколько более многогранна. И по моим наблюдениям оно даже в линухе не умеет в адаптив со скоростью потребной для юзера едушего в авто или поезде. Ну вот не те порядки величин времянок + вымахивающий до дичи вплоть до 60, чтоли, секунд таймаут на retry. А потеря соты на несколько секунд - не "перегруз сети", что ты там этот крап себе внутрях не мнил. > Эра не венды/огрызка только начинается, но вы этого не видите ещё. Я много чего вижу. А кроме всего прочего - вот натыкаюсь на самую странную дичь. Скажем олдскульные юзеры привыкли пыриться в ящик ДНЯМИ. Они не хоят ничего знать про проблемы ваших пакетов. Но если так делать, даже на хорошем в целом радиолинке бывает так что 1-2 раза в сутки теорвер прикалывается, до состояния когда у tcp таймауты вымахивают до невменяемых величин, и видео все же икает, юзеры кроют эти ваши интернеты на чем свет стоит. При том имея вполне валидные основания - "computer is thrashing". В линке дофига бандвиза, фатально ничего не перегружено, но скорость адаптива vs конские таймауты буфер не удержали и юзер злой. При том гугол далеко не хучший вариант. У них плеер по крайней мере динамически бандвиз менять умеет и может чанксервер сменить (при этом затупившая конекция со всеми причудами congestion control просто идет на йух, а новая по дефолту как правило сильно бодрей и улучшение достигается). А вот какие-нибудь мелкие местечковые сервисы гонящие поток с какой-нибудь камеры или типа того, с никакими админами и рыхлым, жирным потоком в разы больше ютуба - вот там жесткач. Еще бывают корпы и впн. Как работает TCP в TCP все догадываются, а корпадминам обычно впадлу что-то кроме TCP/443 на фаере открывать. Так что, мол, гоняйте впн через это, и познайте все прелести эффекта домино... сабж на них поднажмет малость. Поэтому сабж имхо все же постепенно улучшит картину мира. Без особого упования на интеллект админов, юзеров или кого еще. В нем это factored out. Достаточно браузер сменить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201

248. Сообщение от Аноним (-), 22-Мрт-21, 23:54	+/–
> делать нормальные сайты пробовал? Сайтов видите ли сейчас миллиард, чтоли. Переделать весь миллиард по фэншую у меня кишка все-таки тонка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211

249. Сообщение от Аноним (-), 23-Мрт-21, 00:03	+/–
> СС работает только на передающей стороне, что тут непонятного? > На принимающей стороне СС хоста принимающего в процессе приёма не учавствует. Спасибо кэп. Тем не менее, TCP двухсторонняя штука, как впрочем и логика запрос чанка -> данные чанка. Если юзер не сможет попросить по быстрому новый чанк - он его и не получит. А в сумме - иногда, вот, теорвер кажись стебется, искусственно раздувая туповэйтинг перепосылки пакета без реальных оснований. Ну то-есть какие-то неудачные всперды в канале попадают на тайминги перепосылок - и тогда все коллапсирует до диалапных величин. Особенно хорошо это заметно с быстро перемещающимися пользователями, попадающими в прорехи покрытия (которые таки что угодно но уж точно не перегруз сети и не по душу congestion control вообще совсем). И в мире когда юзерье хочет смотреть ютуб в режиме ящика, и чтобы QoS был такой же... эм...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

250. Сообщение от Аноним (250), 23-Мрт-21, 00:59	+/–
> C++/CLI, поддержку которого почему-то в .NET Core не завезли. Поддержку .NET Core в C++/CLI добавили в прошлом году. Тут дело не в .NET [Core], а в том, что единственным компилятором с поддержкой C++/CLI до сих пор является MSVC. Подозреваю, остальным просто нафиг не упёрлось тратить время и силы на реализацию этого мутанта, по своей природе поддерживающего только пересечение множеств фич плюсов и .NET.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #252

251. Сообщение от Anonchik (?), 23-Мрт-21, 02:16	+/–
Например, UDP-соединения не поддерживаются в Tor. Следовательно, со временем, если поддержка UDP или QUIC в цепочках так и не будет добавлена, а сайты начнут отказываться от поддержки старых версий HTTP, то интернет станет менее доступен анонимно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #260

252. Сообщение от Аноним (253), 23-Мрт-21, 02:56	+/–
Ага, "фич" плюсов. Которые почему-то даже Microsoft с огромным штатом разрабов не реализовала полностью. Какой там стандарт заявлен как полностью поддерживанмый? Насколько помню, никакой, потому что они только по кусочку из каждой новой версии стандарта добавляют. Тот же Unity почему-то тоже перешёл с плюсов на C# как основной язык. При этом .NET развивается самимильрвми шагами, наверное между C++ и .NET проблема всё-таки не в .NET.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250 Ответы: #258, #262

253. Сообщение от Аноним (253), 23-Мрт-21, 03:21	+/–
> Со своей стороны кстати заметил, что худший жс-код нередко получается у тех, > кто ранее кодил на шарпе или джаве - там будто бы какая-то профессиональная > деформация, что они ничего не могут делать просто: даже примитивнейшая > функция-помощник для обращения к бэкенду у них превращается в несколько файлов, > кучу классов с наследованием и пробросом экземпляров одного класса в другой > и обмазкой костылями, что потом черт ногу сломит, а если применяется тайпскрипт, > то ещё и всевозможными интерфейсами, пометками для того или иного игнора проверок и > проч обмазано.. и все равно работает с багами. Вот сейчас, как шарписту, работающему в команде шарпистов, было обидно. Мы наоборот стремимся минимизировать количество фронтового кода, написанного бэкендерами. Соответственно, если надо получить что-то от бека на фронт, пишется один метод (ага, без классов, интерфейсов и прочих ООП ради ООП), внутри которого выполняется get запрос и кладётся в data/store, метод занимает строк 10. С учётом обработки ошибок. Да и количество символов в строке не превышает 80. Спасибо axios за это. Может, когда-нибудь и на fetch API перейдём, но пока он в нашем случае больше бойлерплейта вынуждает писать. Про джавистов не скажу, после университета, где всё делалось на джаве, морально не мог больше на нём писать без сбегания на любую другую платформу, хоть Rust, хоть Python, хоть TypeScript. > Хотя не исключаю, что это профессиональные заработчики, > решившие чутка сменить специализацию. Это ИМХО гораздо ближе к правде. ЧСХ, курсы эти выпускают питонистов, джавистов, гошников, пхпшников и джсников - всего 5 языков популярны у "стань прогером за месяц/полгода/год". На шарпе подобных курсов крайне мало (только ITVDN и по Unity), вся актуальная инфа всё-таки на английском. Либо универские, от того же УРФУ, например, но там всё-таки основы, а не для коммерческой разработки. Знатно меня бомбануло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

254. Сообщение от Додо (?), 23-Мрт-21, 11:47	+/–
>> Это не "дофига способов", это только три. > А этого мало, или мы за неимением аргументов переходим к придиркам к > словам? Это не "дофига", это "несколько". И как раз ваш вопрос является придиркой. Аналогично можно передавать данные в query-параметрах и заголовках при осуществлении соединения по SSE или при апгрейде соединения в Websocket. Разница только в том, что для SSE и Websocket в них можно передать данные лишь в самом начале, а в HTTP-запросах - в каждом запросе. >> В конечном счете все сводится к тому, что практически всегда данные передаются >> в теле запроса, в том или ином сериализованном виде. >> этой точки зрения нет никакой разницы, что использовать. > То есть Вы признаёте что двунаправленность WebSockets это просто маркетинговый пиар, а > вовсе не преимущество над SSE. Большой минус HTTP-запросов - необходимость открывать новые соединения (постоянно для HTTP 1, периодически дли HTTP 2/3). В случае SSE при использовании HTTP 1 мы имеем 1+n соединений (1 соединение для SSE, n соединений для отправки HTTP запросов). В случае Websocket мы имеем 1 соединение в любом случае, так как через него можно и отправлять, и получать данные. >> Кстати, у SSE есть большой, жирный минус: через него нельзя передавать бинарные >> данные, у него используется \n\n как разделитель сообщений. > Необходимость передачи бинарных данные у меня и не возникала, но решается элементарно > с base64. base64 раздувает данные на треть. 4096 байт в base64 будут 5464 байт. SSE не дает отправлять сырые текстовые сообщения, по причине того же разделителя. Нужно обязательно как-то сериализовать данные, чтобы не дай боже в теле не было \n\n. Итого мы имеем... SSE: + более нативное поведение для протокола (легко реализуется); - обязательная сериализация данных (ограничение протокола); - невозможность передачи бинарных сообщений (ограничение протокола); - односторонний канал связи (ограничение протокола, требует дополнительных запросов для отправки данных). Websocket: + двухсторонний канал связи (отправка и получение данных внутри одного соединения); + возможность передачи любых сообщений в любом виде (в том числе бинарных); - отдельный протокол, требующий особой поддержки и апгрейда соединения (сложность реализации, плохо продуманный handshake). Казалось бы, зачем нужен Websocket, если у SSE "дофига" плюсов (целый один)? >>> И этот вынужденный костыль, маркетолухи гугла раскручивают как мегафичу... >> И SSE, и Websocket были разработаны в рамках группы WHATWG. В нее как бы не только Google входит. > Не важно кто входит в группу, важно кто пиарит или каким-то образом > поддерживает этот пиар. > docker и kubernates тоже не один гугл разрабатывает, но вкладывается пиар, прямо > или косвенно, именно он! SSE разработан для отправки сообщений с сервера. Websocket разработан как аналог TCP соединения в JS (с ограничениями), изначально даже назывался TCPConnection. Это _разные_ технологии, и из этих двоих Websocket более функционален. Его даже пиарить не нужно, он банально более удобен в использовании. В Websocket можно легко инкапсулировать другие протоколы, типа STOMP. А насчет пиара... Вон, Microsoft в последнее время пиарит Linux. Что теперь, отказываться от Linux и переходить на FreeBSD? Oh, wait, его же Sony пиарит, используя в своих консолях...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #241

255. Сообщение от macfaq (?), 23-Мрт-21, 19:51	+/–
>> Айскат ещё жив? >> Последние версии вроде бы базировались на ff pre-fenix и после 68.х не >> обновлялись. > ну да зашел на f-droid, мобильная версия чет тухленькая > Version 68.4.2 (680412) suggested Added on 2020-02-04 Видимо таки помер. Жаль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195 Ответы: #256

256. Сообщение от kissmyass (?), 23-Мрт-21, 20:32	+/–
>>> Айскат ещё жив? >>> Последние версии вроде бы базировались на ff pre-fenix и после 68.х не >>> обновлялись. >> ну да зашел на f-droid, мобильная версия чет тухленькая >> Version 68.4.2 (680412) suggested Added on 2020-02-04 > Видимо таки помер. Жаль. iceraven хотят добавить на f-droid ))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #255

257. Сообщение от Kuromi (ok), 23-Мрт-21, 21:08	+/–
>> Последний раз, когда я туда хотел залезть, мне ничего не мешало, кроме предупреждения. > Редко заходишь, значит: в релизных мобильных версиях доступ к about:config выпилили с > августа прошлого года. Вообще-то нет. В августе был форсированный апгрейд "старого" Fennec-based FFA на Fenix-based. А сам Fenix под названием Firefox Preview к этому момент уже почти год как существовал и был доступен для загрузки и вот в нем About:config был выключен сразу везде кроме ночнушки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

258. Сообщение от Аноним (250), 24-Мрт-21, 02:19	+/–
> даже Microsoft с огромным штатом разрабов не реализовала полностью. "Даже" Microsoft, хехе. В 2000-х у них была одержимость дотнетом и до MSVC 2013 на поддержку C++ они откровенно забивали, сейчас с этим чуть ли не лучше, чем у GCC и Clang. > Какой там стандарт заявлен как полностью поддерживанмый? Полностью 17-й и значительная часть 20-го (https://en.cppreference.com/w/cpp/compiler_support#cpp20). > Тот же Unity почему-то тоже перешёл с плюсов на C# как основной язык. AFAIK, сам движок по-прежнему на C++, на шарпе скрипты и прочая логика, не так сильно критичная к производительности. Да и так перешёл, что для борьбы с тормозами-задержками JIT-а и GC пришлось запилить уже два AOT-компилятора дотнетовского байткода в машинный код (IL2CPP, Burst).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #252

259. Сообщение от Аноним (-), 26-Мрт-21, 09:30	+/–
> HTTP Injector - тема халявщиков с 4пда. А, вы тоже в курсе этой забавной штуки :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203

260. Сообщение от Аноним (-), 26-Мрт-21, 09:36	+/–
> сайты начнут отказываться от поддержки старых версий HTTP, Это врядли. Юзеры мозг будут грызть. > то интернет станет менее доступен анонимно. Значит придется накодить это в tor :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #251

261. Сообщение от Аноним (-), 26-Мрт-21, 09:45	+/–
> И как успехи у Boehm GC? Вы его сами использовали или нагуглили только что? Сам я его не использовал, но он есть - и используется энным количеством проектов. А мне под внимание попал потому ... что его упоминали энные проекты, очевидно. > А с какой целью кто-то вообще будет писать под микроконтроллеры на языке, > заточенном под современные многоядерные процессоры? Да вон под STM32 и авр пытаются. И для языка претендующего на системность есть некий пойнт - Boot ROM, boot loader, кернелы и проч работают в специфичном и/или ограниченном окружении. - В мире есть хренова куча задач кроме переросточных мегасерверов с нафигнужным вебмакакингом. Как бы это, 1 проц крутящий движок поезда пары сотен бесполезных серверов с котиками стоит. - Си такой успешный потому что масштабируемый и универсальный. Хошь кучу тредов на 100500 ядрах, хошь микроконтроллер мелкий. Удобно. TL;DR wannabe-системный язык должен уметь в системщину очевидно. Иначе какой он системный? :) > насколько мне известно. И микроконтроллеры, насколько мне известно, не спроектированы > для параллелизации вычислений. И чего? А допустим одноплатники - это что? Там может быть 1 ядро. Или несколько. По смыслу как небольшой компьютер скорее уже. Впрочем в отличие от ламо есть и более вменяемые люди, понимающие что на очередном переростке с вебмакаками мир не кончается. > Да и проблема незрелости Rust до сих пор нерешена - компилятора родного нет, Зато синтаксис уже переколбасили до уровня плюсов, пожалуй. > пока ни Google, ни Microsoft, ни кто-либо другой не проинансировали > разработку полноценного компилятора, а не того MVP, что есть сейчас. Эти решальщики проблем на удивление талантливы в их создании.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #207

262. Сообщение от Аноним (-), 26-Мрт-21, 09:47	+/–
> Ага, "фич" плюсов. Которые почему-то даже Microsoft с огромным штатом разрабов не > реализовала полностью. Они C99 c какого там года полностью реализовать не могут? А ты эвона чего от них захотел. Им видите ли удобнее всего было бы продавать новую версию как кр00тую и улучшенную вообще без переделки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #252

263. Сообщение от Аноним (-), 26-Мрт-21, 09:54	+/–
> Реалии отличаются от ваших представлений о них. Я закатил энное количество сетевых экспериментов, странных конфиг и проч - и остался недоволен тем как это работает в ряде ситуаций. Оно хтонически не способно реагировать на динамично меняющиеся условия. BBR лучший из того что есть, но даже он иногда неоправданно протупляет, и с этим congestion control развели классическое "хотели как лучше, а получилось как всегда". > Роуминг - это из другой оперы, но если вы собираетесь перепосылать любой > пакет который не аскнули за 100-500мс то вы положите сеть, аналогично > если будете перезапрашивать так агресивно. И TCP довольно гибко аскает и > запрашиват ретрансмиты, если что. Да, да, отсутствие соты по причине "юзер движется и пропал сигнал" это, конечно, перегруз сети. Или там всплеск шума в беспроводном канале, тоже "сеть положит". В общем любую идею можно довести до маразма - и вот это вот именно туда и пришло. И в эру мобильных девайсов весь этот шит стал категорически иррелевантен. Так то если на эзернете разглагольствовать оно не проблема, но что-то никто не хочет за смартом или планшетом кабель таскать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205

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

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