В ночных сборках Firefox, а также в бета-версии включена по умолчанию поддержка протокола HTTP/3. В стабильной ветке включение HTTP/3 намечено на выпуск Firefox 88, запланированный на 20 апреля. В Chrome выборочная активация HTTP/3 началась в октябре 2020 года...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54801
А про недостатки почему не пишут? Тот же congestion control теперь не от ядерной реализации какого-нибудь cubic, reno зависит, а от криворукости хромоделов. Была же уже драма когда-то с внедрением первой реализации uTP в торрентах и повсеместными "укладываниями" пропускной способности.Сообразительные по части сетевых протоколов ещё парочку накидают.
Странный вы народ: в срачах про микроядро vs монолит вы вовсю кричите что надо все в юзерспейс. А сейчас (и ещё помню новость про FUSE) уже ярые противники этого подхода.
> Странный вы народ: в срачах про микроядро vs монолит вы вовсю кричите
> что надо все в юзерспейс. А сейчас (и ещё помню новость
> про FUSE) уже ярые противники этого подхода.Для начала, я никогда не кричал такого. Есть просто имеющийся сетевой стек и в нём управление потоком для TCP в ядре, а UDP по дизайну не гарантирует доставку, поэтому там управление потоком и его целостностью должно быть выше. Дело даже не в том, что ядерные алгоритмы оттестированы и не страдают склонностью к вендорлоку, а в том, что процесс, управляющий потоком, работать будет с пользовательским приоритетом, что недопустимо для realtime задачи управления потоком. В загруженных условиях пользовательская реализация будет страдать от той же проблемы, на которую наступил когда-то pulseaudio. Сколько тут было орущих про "икание" звука после перехода на pulseaudio (сама идея вообще хороша)? Так вот, это банально из-за невозможности управления realtime задачей из пользовательского пространства в условиях высокой загрузки.
Скрытый же мотив гугла в том, чтобы вынести по максимуму всё в зависящий только от cебя блоб. Даже то же обоснование о том, что мультиплексированный в HTTP/2 поток дропает всё в случае потери пакета, и повышенная пропускная способность UDP на беспроводных, нивелируется тем, что тот же оверхед, необходимый для контроля целостности потока, реализуется уже внутри самого QUIC. И он не меньше, а в реальности даже больше, чем у TCP vs UDP.
> процесс, управляющий потоком, работать будет с пользовательским приоритетом, что недопустимо для realtime задачи управления потоком.Если взлетит, потом всегда можно будет добавить добавить реализацию в ядро.
> Если взлетит, потом всегда можно будет добавить добавить реализацию в ядро.Милый, там congestion алгоритмов уже выше крыши, выбирай на вкус.
Но этими алгоритмами пользуется тольлко TCP. А в UDP/QUIC поддержку это придётся добавить.
Зачем вообще гонять http по udp??? UDP же дня всякого треша, который устаревает до того, как пакет успевает долететь до получателя, вроде потокового видео, аудио, или игр.Что за странная идея реализовывать гарантированную доставку по udp?
Они нашли у TCP фатальный недостаток. TCP connect + ssl + http request занимают непростительно много времени, особенно в мобильных сетях. К тому же им хочется, чтобы сервер имел возможность определить пропускную способность клиента для всех подключений вместе и крутить им приоритеты, чтобы баннеры грузились быстрее стилей. Это можно провернуть и с TCP, но для этого нужно лезть в ядро, а у них лапки.
Просто TCPшный congestion control на беспроводных линках вытворяет черт знает что, и вы телепаете со скоростью диалапа от того что там какой-то всперд помех в канале изредка случается. TCP из эпохи диалапа не в курсе радиопроблем и полагает что линк перегружен. И вот у вас 100 мегабитный линк, не занятый ничем, а вот тспшная конекция со скоростью диалапа. Думающая что линк типа-перегружен, раз пакеты теряет или RTT прыгает. Хотя это просто нормальный курс событий при радиолинке.
> Просто TCPшный congestion control на беспроводных линках вытворяет черт знает что, и
> вы телепаете со скоростью диалапа от того что там какой-то всперд
> помех в канале изредка случается. TCP из эпохи диалапа не в
> курсе радиопроблем и полагает что линк перегружен. И вот у вас
> 100 мегабитный линк, не занятый ничем, а вот тспшная конекция со
> скоростью диалапа. Думающая что линк типа-перегружен, раз пакеты теряет или RTT
> прыгает. Хотя это просто нормальный курс событий при радиолинке.Ну давно же уже всё протестировали и даже статью на русский на Хабре перевели. Зачем повторять малорелевантные профессиональные заблуждения?
> Ну давно же уже всё протестировали и даже статью на русский на
> Хабре перевели. Зачем повторять малорелевантные профессиональные заблуждения?Я не знаю какие вебмакаки с хабры что "тестировали" и переводили - поэтому говорю то что видел своими глазами, лично. TCP с кубиком может в определенных ситуациях drop to the floor! На ровном месте практически. А уж если там какой дисконект случился, или что еще, и нетворкменеджер целые 5 секунд ждал реконекта - вообще 3.14-ц конекции, будет полминуты одуплять. При том что канал есть, идеальный, но, вот шизанутая логика кубиков и ко с конским таймаутом когда он следующую попытку чуть не через минуту будет делать - имеется. И при малейих отклонениях от идеала в линке (что для беспроводки норма жизни) оно умеет совершенно по дурацки коллапсировать на ровном месте.
Собственно поэтому гугол и накодил BBR, закомитив его в майнлайн на секундочку (может даже заенаблил ведроидам, черт знает). Есть еще CDG похожий по смыслу, мне он показался менее эффективным, но и менее чудесатым. BBR более вменяемо реагирует - пытается различать вот реально долговременный перегруз и кратковременные всперды в канале. Но делает он это с переменным успехом, а самое печальное во всей этой истории - то что у юзеров винды его нет и не будет. Поэтому они в ряде ситуаций получают реально околодиалапные скорости и делают мозг саппорту гугля что мол видео на ютубе отлипает.
Так что cubic и ко это как раз пример технологии эры диалапа, которые в современном мире умеют в нехилый thrashing и саботаж если не повезло. На беспроводных линках невезение усиливается пропорционально поганости качества линка.
> Так что cubic и ко это как раз пример технологии эры диалапаКраткое понимание глубины вопроса.
> Краткое понимание глубины вопроса.Я эту глубину вопроса в отличие от хабры таки потестировал самолично - и остался недоволен тем как это работает в условиях отличных от идеала.
Вы просто вообще и близко не в теме, даже похоже тут новости не читаете.
СС нынче больше десятка разных есть, самые современные это rack* и bbr.
Более старые но всё ещё клёвые htcp, hybla, ну и потом кубики с ньюрено.
Разница между htcp и bbr/rack* на плохих линках может до 5 раз доходить, из того что я видел, те где htcp даёт 1 мегабайт/сек bbr держит 3, прыгая до 5.
> Вы просто вообще и близко не в теме, даже похоже тут новости не читаете.
> СС нынче больше десятка разных есть, самые современные это rack* и bbr.Спасибо кэп! Собственно вторым я и пользуюсь на беспроводных линках. Но работает он все же достаточно чудесато временами.
И если уж мы про новости, в относительно недавних кернелах гугл как раз починил очень стебный баг, когда эта их офигенная мегаинновация могла в энной ситуации ... сдуреть и надолго задушить канал до вот реально диалапных величин, вообще по сути игнорируя внешние раздражители. Волшэбно, просто волшэбно. Потом ветеран-юникс-недоразумения удивляются почему это их полглобуса оказывается давно мечтает в утиль списать. Потому что компьютерные системы работающие вот так давно всех заколебали.
> Более старые но всё ещё клёвые htcp, hybla, ну и потом кубики с ньюрено.
Есть несколько фундаментальных проблемок. Сущая ерунда:
1) Это требует мануальной настройки админами.
2) По поводу чего хренова куча серверов которые этим не парились.
3) Юзерам виндов во всех их ипостасях все это счастье не светит в принципе.
4) Сервера на винде таки тоже бывают. Вон любимые эксченжи поха подтвердят :)> Разница между htcp и bbr/rack* на плохих линках может до 5 раз
> доходить, из того что я видел, те где htcp даёт 1
> мегабайт/сек bbr держит 3, прыгая до 5.Теперь попробуйте все это на винде устроить, решатели проблем, итить. Нуагули, гугол с сабжем будет более-менее одинаково работать везде. Потому что их congestion control не завязан на причуды конкретного кернела как раз. Который у юзеров винды малость проблематично пропатчить.
И если кто еще не понял, эра ветеран-юникс-недоразумений кончается как раз потому что ваши представления о юзабилити и том как работает этот мир - полное дно, оторванное от реальности. А по факту получается трэшак работающий абы как. Вы уж извините, но я очень плотно анализировал бзики TCP под сетевым анализатором, и имею свое мнение о том трэшаке который я видел. Когда линк львиную долю времени тупо idle без особых причин.
Это проблемы вашего линуха, у меня нет линуха, а у гугла нет в нём проблем :)Если этим никто не парился - значит у людей нет такой проблемы.
Сервера на венде могут стоять и за прокси в виде nginx, который будет менять СС по сути, так что это не проблема даже для тех кто держит сервисы на венде.Я вам ещё раз говорю: на венде обычно потребляют трафик и поэтому какой там у них СС никого не колышит.
Не знаю что вы там анализировали, у меня была всегда простая цель: получить либо максимальную скорость либо достаточную чтобы иптв не заикалось, и мне даже hybla под линухом хватало.
Во фре были проблемы, до появления rack, возможно там сейчас и дефолтный tcp допилят в 13-14 версиях до состояния как линухе.Эра не венды/огрызка только начинается, но вы этого не видите ещё.
> Это проблемы вашего линуха,В _моем_ линухе эта проблема (как минимум частично) решена. Но есть нюансы. Я - не вся планета. И даже на гугле мир не заканчивается.
> у меня нет линуха, а у гугла нет в нём проблем :)
Это не решение способное принести счастье если не всем то большинству юзеров. Кроме гугла есть еще 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. Достаточно браузер сменить.
> Но этими алгоритмами пользуется тольлко TCP. А в UDP/QUIC поддержку это придётся
> добавить.Дурилка, для UDP они не нужны по дизайну.
Для UDP (RFC 1980-x годов) не нужны, но речь про QUIC. Вот эти (с Гугелем не связаны) https://udt.sourceforge.io/ тоже считают UDP недостатком и надстраивают.
> Для UDP (RFC 1980-x годов) не нужны, но речь про QUIC. Вот
> эти (с Гугелем не связаны) https://udt.sourceforge.io/ тоже считают UDP недостатком и
> надстраивают.Я тебе ещё раз говорю, что гугл просто реализует ещё один уровень абстракций для передачи пользовательского трафика. QUIC - это самый обычный UDP, поверх которого надстроен контроль целостности потока (из глобальных вещей).
И, вероятно какой-то кастомный congestion control. Совсем без него видите ли есть шанс глобально завалить сети.
> Милый, там congestion алгоритмов уже выше крыши, выбирай на вкус.А теперь придумай как сделать чтобы юзеры винды не воняли что сайт долго грузится. Пересадить их всех на линь все же оверкилл, браузер им переставить таки сильно проще.
делать нормальные сайты пробовал?
> делать нормальные сайты пробовал?Сайтов видите ли сейчас миллиард, чтоли. Переделать весь миллиард по фэншую у меня кишка все-таки тонка.
но http/3 открытый стандарт не зависящий от хромого блоба.. просто не используйте http/3 для решения задач для которых он не подходит и не предназначен. разные протоколы существуют и поддерживаются не просто от NIH синдрома а для решения разных задач разными методами.
> в срачах про микроядро vs монолит вы вовсю кричите что надо все в юзерспейсвсе очень просто. некоторое время тому назад видеодрайвера Х были в юзерспейсе.
но потом мультимедия поперла и производительности стало не хватать.
так идеология проиграла практике.
Ну во-первых в мобильный браузер не залезть в about:config, а в новости про них почему-то тоже сказано. То естть включить никак, выключить никак. В гугле 1% разница в нагрузке от этой гугловской версии удп протокола.
> Ну во-первых в мобильный браузер не залезть в about:config, а в новости
> про них почему-то тоже сказано. То естть включить никак, выключить никак.
> В гугле 1% разница в нагрузке от этой гугловской версии удп
> протокола.Последний раз, когда я туда хотел залезть, мне ничего не мешало, кроме предупреждения.
> Последний раз, когда я туда хотел залезть, мне ничего не мешало, кроме предупреждения.Редко заходишь, значит: в релизных мобильных версиях доступ к about:config выпилили с августа прошлого года.
Я просто на бете сижу.
Поставил себе IceCat и снес новую поделку мозилки. Все работает. Тот же FF только не курильщика.
Айскат ещё жив?
Последние версии вроде бы базировались на ff pre-fenix и после 68.х не обновлялись.
> Айскат ещё жив?
> Последние версии вроде бы базировались на ff pre-fenix и после 68.х не
> обновлялись.нет возможности сейчас посмотреть мобильный, но десктоп под мастдай 78.7.1esr (64-bit)
> Айскат ещё жив?
> Последние версии вроде бы базировались на ff pre-fenix и после 68.х не
> обновлялись.ну да зашел на f-droid, мобильная версия чет тухленькая
Version 68.4.2 (680412) suggested Added on 2020-02-04
>> Айскат ещё жив?
>> Последние версии вроде бы базировались на ff pre-fenix и после 68.х не
>> обновлялись.
> ну да зашел на f-droid, мобильная версия чет тухленькая
> Version 68.4.2 (680412) suggested Added on 2020-02-04Видимо таки помер. Жаль.
>>> Айскат ещё жив?
>>> Последние версии вроде бы базировались на ff pre-fenix и после 68.х не
>>> обновлялись.
>> ну да зашел на f-droid, мобильная версия чет тухленькая
>> Version 68.4.2 (680412) suggested Added on 2020-02-04
> Видимо таки помер. Жаль.iceraven хотят добавить на f-droid ))
Выпилено только в релизном. В Бету about:config вернули.
Ты наверное читаешь плохо? Я же сразу написал:
> в релизных мобильных версияхТы, наверное, догадываешься, что бета - это не релиз, да?
> Ты наверное читаешь плохо? Я же сразу написал:
>> в релизных мобильных версиях
> Ты, наверное, догадываешься, что бета - это не релиз, да?Ты наверное не в курсе, что не так давно about:config в мобильной версии был доступен ТОЛЬКО в Nightly, так что разблокировка фичи в Бете - это уже прогресс.
> Редко заходишь, значит: в релизных мобильных версиях доступ к about:config выпилили с
> августа прошлого года.Мозилла всегда умеет пользователей порадовать. Может, им начать пистолеты с 1 патроном своим пользователям бесплатно рассылать? Ну так, на правах маркетинга. Если уж проклятые юзеры так надоели.
>> Последний раз, когда я туда хотел залезть, мне ничего не мешало, кроме предупреждения.
> Редко заходишь, значит: в релизных мобильных версиях доступ к about:config выпилили с
> августа прошлого года.Вообще-то нет. В августе был форсированный апгрейд "старого" Fennec-based FFA на Fenix-based. А сам Fenix под названием Firefox Preview к этому момент уже почти год как существовал и был доступен для загрузки и вот в нем About:config был выключен сразу везде кроме ночнушки.
И в Chrome (chrome://flags), и в Firefox (about:config) можно зайти в дополнительные настройки на Android.
В Firefox Beta - можно. В обычном Firefox для android - нельзя
Используй IceCat. Те же яйца, но можно.
Fennec с фдройд или его форк iceraven работают как надо, ничего не выпилено. Adware-мусор типа хрома и его клонов, разумеется, нерелевантны.
> Тот же congestion control теперь не от ядерной реализации какого-нибудь cubic,Которому в современном мире так то давно уже пора сдохнуть жестокой смертью, за саботаж нетворкинга. Ибо на вайфай или сотовом линке с минимальной потерей пакетов или нестабильным RTT он мигом сливается до скоростей диалапа, плевать хотев что там 100+ мегабит с редкими неидеальностями. Поэтому юзер телепает со скоростью диалапа пока линк бездействует и там ничерта и близко похожего на congestion, просто шум в канале какой-то проскочил.
> от криворукости хромоделов.
Как показал пример кубиков и рено эти господа хтонически не способны делать то что должны. Гугель с горя bbr накодил, один из самых вменяемых для беспроводных линков. Но даже он умеет дурить.
Но главное... есть такая штука - винда. И в нее невозможно свой планировщик пакетов втулить. Поэтому с кодинга bbr профит наступает далеко не у всех. А юзеры винды костерят адские времена загрузки сайта. Потому что их планировщик писаный поди еще в эру диалапа работает вот так.
И, вот, оказывается что единственный способ принести счастье всем это сделать подобие TCP из UDP самому. При этом более вменяемый планировщик таки достанется всем.
Когда юзер венды приходит смотреть видео на ютупе, то передающая сторона в виде гугла юзает bbr и юзер счастлив, а какой там СС у юзера - малозначительно, ибо он получает а не передаёт.
> Когда юзер венды приходит смотреть видео на ютупе, то передающая сторона в
> виде гугла юзает bbr и юзер счастлив, а какой там СС
> у юзера - малозначительно, ибо он получает а не передаёт.Вообще-то линк там таки двусторонний by design и юзер периодически должен как минимум запрашивать чанки с чанксервера. Иначе он тупо не получит очередной сегмент.
СС работает только на передающей стороне, что тут непонятного?
На принимающей стороне СС хоста принимающего в процессе приёма не учавствует.
> СС работает только на передающей стороне, что тут непонятного?
> На принимающей стороне СС хоста принимающего в процессе приёма не учавствует.Спасибо кэп. Тем не менее, TCP двухсторонняя штука, как впрочем и логика запрос чанка -> данные чанка. Если юзер не сможет попросить по быстрому новый чанк - он его и не получит.
А в сумме - иногда, вот, теорвер кажись стебется, искусственно раздувая туповэйтинг перепосылки пакета без реальных оснований. Ну то-есть какие-то неудачные всперды в канале попадают на тайминги перепосылок - и тогда все коллапсирует до диалапных величин. Особенно хорошо это заметно с быстро перемещающимися пользователями, попадающими в прорехи покрытия (которые таки что угодно но уж точно не перегруз сети и не по душу congestion control вообще совсем).
И в мире когда юзерье хочет смотреть ютуб в режиме ящика, и чтобы QoS был такой же... эм...
С uTP эпичность была в том, что некоторые провайдеры не лимитировали скорость UDP, в итоге у некоторых юзеров вместо 20 мегабит стало всего 100 для торрентов :)А СС вроде быстро утрясли, да и проблема там не имела эпических масштабов, потому что даже если отдавать на максимальной скорости - всё равно отдашь только один чанк за раз, а они не такие большие.
Еще там был тупняк что при congestion он размер пакета уменьшал. Тот же объем трафа начинал создавать больше пакетов. Сие очень доставляло наколенным софтроутерам гамнолокалок - при намеке на туняки их добивало мелкими пакетами, что вызывало неиллюзорный батхерт :)
так это же плюс. конечный пользователь на ядерные реализации протоколов влиять не может а вот сменить хром на фуррифокс где реализации получше уже может, а ещё лучше чтоб вообще про это всё не знать а мультимилионные корпорации сами следили чтоб всё работало..
Опять rust. Опять будет пароксизм ненависти в комментариях
Сишные дыры.
Дыры от ржавчины.
Опять растаманы перепутают ">" и "<=".
Раст сам по себе основан на ненависти к другим языкам.
Вот не надо. Язык как язык - свои принципы, свои концепции. А то, что какие-то неадекваты из числа фанатов раста хейтят Си - ну так на опеннете вообще аудитория такая, пора бы привыкнуть и не делать скоропалительных выводов.
> Вот не надо. Язык как язык - свои принципы, свои концепции. А
> то, что какие-то неадекваты из числа местных ванаби-сишников, жопоскриптозников и питонистов набрасывают в виде "растофанатов, хейтеров си" и сразу же "дает отпор хрустикам" - ну так на опеннете вообще аудитория такая, пора бы привыкнуть и
> не делать скоропалительных выводов.Пофиксил.
> > Раст сам по себе основан на ненависти к другим языкам.
> ванаби-сишников, жопоскриптозников и питонистовQuod erat demonſtrandũ.
>> > Раст сам по себе основан на ненависти к другим языкам.
>> ванаби-сишников, жопоскриптозников и питонистовЧСХ - ни одного ЯП. Да и "ненависти" как-то не наблюдается - так, брезгливость.
> Quod erat demonſtrandũ.Quod очередной жопочтец-сам-придумвыватель-сам-опровергатель демонстрандум
>>>> +15,
>>> -11
>>> +11
>> -11
> Quod erat demonſtrandũ.Хабро-истеричка совсем не палиццо ...
Си никто в здравом уме не будет хейтить. Язык, на котором столько всего написано, просто нельзя не уважать. Но вот стоит ли писать на нем что-то новое? Нельзя забывать, что он довольно примитивный (некоторые отмечают это его плюсом), устаревший, почти не развивается (опять же). Лично я выберу Раст (трейты - хорошая замена классического ООП) или Плюсы (зависит от задачи).А вот как раз чистые бессмысленные хейтеры Раста здесь есть. Которые его только на картинках видели.
> Язык, на котором столько всего написано, просто нельзя не уважать.Уважения не достаточно внезапно, любители старья пусть валят смотреть мелодрамы 70х. Я выбираю быстрейший инструмент для своей задачи, и ср@ть хотел на хейтеров. Haters gonna hate (c). Раст уже обгоняет С по производительности, это отличная новость притом что компилятор еще сыроват.
> Плюсы (зависит от задачи).
Удовольствие куда ниже среднего, 70% функционала в депрекейтед в любом топ проекте. Куча легаси кода на радость старичью, но начинать что-то новое на плюсах смысла нет еслы ты не раб менеджера.
И поэтому все ААА игрушки пишут на плюсах.Сразу видно человека сложнее хелловорлда ничего не написавшего.
ААА игрушки в большинстве случаев пишут не с нуля, а с использованием готовых движков, которые прибивают тебя к С++. И за 5,5 лет ещё никто не написал достаточно сложного игрового движка. Плюс у Rust и для работы с графикой и видеокартой пока не освоена на промышленном уровне. А игровым студиям зарабатывать денежки надо, а не технологии применять.> Сразу видно человека сложнее хелловорлда ничего не написавшего.
Да, Урри, Вас видно.
> Раст уже обгоняет С по производительностиСпорное утверждение. Я бы предположил, что они примерно одинаковы по производительности.
Так же есть и синтетические тесты, "доказывающее" обратное.
Однако JavaScript за это никто не уважает, скорее наоборот.Хотя сейчас на нём написано больше всего кода в мире.
Так на С написано написано огромное количество хорошего кода, и при всех сложностях отличного софта.А на JS написано в основном от безысходности в том или ином виде тонны говнокода.
Как бы так сказать разное наследие у этих языков.
Ого, сколько минусов. Вот это подгорело у кого-то! Я собой горжусь.
> Ого, сколько минусов. Вот это подгорело у кого-то! Я собой горжусь.У меня больше (как минимум - минусов)!
Кстати, тезис об истерящих питонистах-жопоскриптозниках получил довольно веское подтверждение.
> Раст сам по себе основан на ненависти к другим языкам.И на постоянном нагреве реактивного сопла у опеннетчиков - это основной двигатель прогресса в раст.
Его придумал Гитлер! Мозила == фашизм!
Ещё дополню "преимущества" QUIC: Лучше следить за пользователями...
*следит
https://www.youtube.com/watch?v=GM-e46xdcUo
> Ещё дополню "преимущества" QUIC: Лучше следить за пользователями...Это как? Чем он от TCP или HTTP так уж принципиально отличается в этом аспекте?
Например, UDP-соединения не поддерживаются в Tor. Следовательно, со временем, если поддержка UDP или QUIC в цепочках так и не будет добавлена, а сайты начнут отказываться от поддержки старых версий HTTP, то интернет станет менее доступен анонимно.
> сайты начнут отказываться от поддержки старых версий HTTP,Это врядли. Юзеры мозг будут грызть.
> то интернет станет менее доступен анонимно.
Значит придется накодить это в tor :)
Следить за пользователями с QUIC становится сложнее, поэтому товарищу майору выгодно посеять к нему недоверие вот такими засланными казачками.
Заметный прирост производительности тоже пока под вопросом. На багзилле баг висит, в котором жалуются как-раз на затупы того же Google после включения.
Но, зато, по Wi-Fi производительность действительно может вырасти. По TCP вафля в среднем из-за большого оверхеда в структуре фрейма (2346 на 1500 ethernet фрейм) и на служебных сообщениях даёт от 30 до 38% заявляемой (например около 2.2 мегабайт на 54 мегабитах), а вот по UDP около 45%.
Его на деле нет. Просто вафля может иметь пинг 50+ даже при идеальной связи в AC. И там не важно сколько чего куда. Там только квадратичная модуляция снижает накладные расходы на передачу данных. Это все лапша для легковерных.
> Его на деле нет. Просто вафля может иметь пинг 50+ даже при
> идеальной связи в AC. И там не важно сколько чего куда.
> Там только квадратичная модуляция снижает накладные расходы на передачу данных. Это
> все лапша для легковерных.Заходим на роутер и делаем iw dev wlan0 station dump и срём кирпичами от tx retries )))
> Заходим на роутер и делаем iw dev wlan0 station dump и срём
> кирпичами от tx retries )))ЧСХ для всех этих кубиков сие в лучшем случае будет ростом пинга, в хучшем потерей пакета, если лимит retries кончился. "ААА, ЛИНК ПЕРЕГРУЖЕН". И похрен что это шум в канале, а вовсе не перегруз линка. Так что вот вам всем диалапные скорости, а линк в 100+ мегабит в это время... ничегонеделает?! Очень оптимально.
> Просто вафля может иметь пинг 50+ даже при идеальной связи в ACЭто на каком-то гoвнoтике 15летней давности? Только что сопоставил з кабелем у себя - вайфай добавляет 3ms.
у меня netgear orbi прошлого поколения. wifi по сравнению с кабелем -- разница меньше миллисекунды (2мс и так и так до сервера в провайдерской сети). если добавить вторую точку доступа, которая общается с первой по беспроводу, получаем плюс миллисекунду (3мс до сервера в провайдерской сети).а ещё у меня есть старый роутер из 2013, netgear r7000. там тоже две миллисекунды пинг что по проводу, что по беспроводу.
интересно а у amplifi какой порядок вносимой latency? iPony, ты тут?
> Это на каком-то гoвнoтике 15летней давности? Только что сопоставил з кабелем у
> себя - вайфай добавляет 3ms.Тебя не смущает что все это зависит не только от тебя но и от шума, соседей и хрен его знает каких еще барабашек? Нет, если ты один живешь на километры вокруг - тогда, конечно, оно так.
в исходном условии было сказано, что барабашек нет, смотри:> при идеальной связи
там ведь не на те беспроводные сети заточка делается где у вас стационарные устройства на вайфае висят, а на мобильники где сигнал переменчивый и часто плохой.
> там ведь не на те беспроводные сети заточка делается где у вас
> стационарные устройства на вайфае висят, а на мобильники где сигнал переменчивый
> и часто плохой.Вафля из-за интерференции давно уже вошла в эпоху траблов с появлением 80 и 160 MHz каналов и даже несмотря на все эти ваши бимформинги и прочие пердоли.
Пускай пилят хоть на чем, главное чтобы был и был повсеместно. У этого протокола хорошая перспектива для маскировки VPN. То, что сейчас есть сильно тормозит - meek, например (да, это tor, но кому надо - приспособили).
> Пускай пилят хоть на чем, главное чтобы был и был повсеместно. У
> этого протокола хорошая перспектива для маскировки VPN. То, что сейчас есть
> сильно тормозит - meek, например (да, это tor, но кому надо
> - приспособили).Простите, чем он лучше для маскировки VPN'а? Да-да, я не про инкаспуляцию TCP в TCP, а именно про маскировку.
Трафик неотличим от HTTP.
К тому же сейчас с обычным TLS можно пописать в SNI какой-нибудь ненужный dropbox, facebook, или на что там ваш мобильный оператор безлимитку дает - и качайте себе весь интернет нахаляву.
Как с этим в HTTP/3 не знаю, для меня это уже неактуально.
Как прописать?
HTTP Injector - тема халявщиков с 4пда.
> HTTP Injector - тема халявщиков с 4пда.А, вы тоже в курсе этой забавной штуки :)
> Трафик неотличим от HTTP.
> К тому же сейчас с обычным TLS можно пописать в SNI какой-нибудь
> ненужный dropbox, facebook, или на что там ваш мобильный оператор безлимитку
> дает - и качайте себе весь интернет нахаляву.
> Как с этим в HTTP/3 не знаю, для меня это уже неактуально.а ты уверен что он по SNI тарифицирует, а не по рейнджам или подсетям?
Где взять столько людей чтобы уследить за этими подсетями?
> Где взять столько людей чтобы уследить за этими подсетями?так по SNI или DNS можно собрать в автоматическом режиме, а подтвердить можно например по тайтлу страницы
или просто по количеству, с левым SNI будет с 10-ок человек, а к реальному пейсбуку будут ломиться тысячи запросов
мне конечно опъепалово системы очень нравится, но думаю что они закроют это, если еще не закрыли
подробнее, пожалуйста.
если я повешу к себе на сервер самоподписанный сертификат для odnoklassniki.ru или там facebook.com, то внезапно трафик к моему серверу перестанет тарифицироваться?
> Простите, чем он лучше для маскировки VPN'а? Да-да, я не про инкаспуляцию
> TCP в TCP, а именно про маскировку.Ну хотя-бы тем что TCP -> TCP работает как полное УГ.
> Ну хотя-бы тем что TCP -> TCP работает как полное УГ.Что характерно, именно поэтому я эту оговорку и сделал, но ты даже её не понял.
meek же вообще нахрен выпилили, чтобы выполнить требование шантажистов.
>У этого протокола хорошая перспектива для маскировки VPN.Нет, это у шантажистов хорошие перспективы обязать провайдеров его заблокировать.
> данные можно передавать сразу после отправки пакета установки соединенияНапоминает мою знакомую, которая, входя в комнату, бросала "Здрасьте" и сразу начинала говорить, а когда её обрывали и указывали, что люди могут быть чем-то заняты и не готовы её слушать - очень обижалась.
> Не использование при повторной передаче пакета того же номера последовательности, что позволяет (...) избавиться от таймаутовВона чё... Оказывается, таймауты не из-за заторов или неисправности линии, а из-за того, что дропнутый пакет повторно передаётся под тем же номером.
> Оказывается, таймауты не из-за заторов или неисправности линии, а из-за того, что дропнутый пакет повторно передаётся под тем же номером.Нет, проблема в том, что остальные пакеты не передаются, пока дропнутый пакет не будет передан повторно и не придёт подтверждение о доставке. То есть, там чуть сложнее, потому что потоком tcp одновременно передаётся несколько пакетов, и когда один потерялся, случается что-то типа сбоя конвеера в CPU.
а асинхронно запрашивать религия не позволяет?
> а асинхронно запрашивать религия не позволяет?Что асинхронно запрашивать? TCP не позволяет попросить передать вон тот файлик на 4Gb, передавая пакеты асинхронно.
Очередное эталонное ненужно.Я каждый раз, когда приходится что-то из современного веба имплементировать, удивляюсь глупости тех, кто это придумывал и внедрял. Хотите примеры? Пожалуйста.
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.
Зачем это гуглу? Наверное, снова хотят очередной невынимаемый зонд вставить.
Вот знаете...
Не могу не согласиться.
«сгенерируйте текстовую строку из разрешенных символов?»Про гуид всё же понятно он «гарантировано» уникальный
Если написать рожно что вы предлагаете, то имплементаторы налячкают своих горе генераторов
А тут используется готовый индустриальный подход, полностью специфицированный
более того его реализации есть под всё.Насчет base64 хз
Возможно эти данные нужны именно строкой
> Отголосок сломанного кривыми технологиями мозга (я намекаю на джаваскрипт)Ругать жс за реализацию конкретной фичи в браузере - все равно, что ругать яйцо за курицу, которая его снесла.
Реализации штук типа вс в браузере «внезапно» кодятся на божественной сишечке. Т.е дело именно в криворуких сишных проггерах.
А ещё дело в том, что веб - штука вполне общедоступная. Хочешь - бери и делай. Вот некоторые и делают.
В то же время, у каждого из таких «дельцов» как ни странно, свои планы замыслы подходы и цели, а так же - видение будущего.
И нынешний веб - это продукт работы не одной конторы, а компромисс множества хотелок множества организаций, некоторые из которых друг другу противоречат
> Ругать жс за реализацию конкретной фичи в браузере - все равно, что ругать яйцо за курицу, которая его снесла.Нет, тут все существенно глубже.
Я по роду профессии много общаюсь с молодыми программистами. Так вот корреляция между тем, на чем они программируют (или учились программировать) и способностью связно и без грабель алгоритмизировать задачу очень четкая. И в этой корреляции джаваскрипт очень, очень плох.
Конечно же, бывают исключения (это сноска для троллей "что, все 100%? да ты дурак и значит врешь").Лично я списываю это на то, что жс сильно нелогичный и плохо структурированный, постоянное его использование учит мозги программистов мыслить нелогично и плохо структурировано. Ну а общий подход "и так сойдет" (эрроры и ворнинги все равно никто в консоли не увидит, если специально не откроет) это все полирует и закрепляет.
И вот на выходе не программист, а гoвнoкодер, программистом по сути не являющийся. С, как это среди программистов принято, огромным самомнением.
> И нынешний веб - это продукт работы не одной конторы, а компромисс множества хотелок множества организаций, некоторые из которых друг другу противоречат
Ха-ха три раза. Что гугл захотел, то пропихнул. Раньше мс пропихивала. Остальные подтягиваются и делают как сказали. Ни вы, ни я, ни даже контора которую мы бы с вами откроем ничего в вебе не решит.
Алгоритмизировать задачу? :D
Это уже ныне сеньор, не меньше. "Кодеры" нынешние же с алгоритмизацией вообще дружат слабо.
Классика: "Нельзя научить программированию человека, оболваненного Бэйсиком"
> между тем, на чем они программируют (или учились программировать) и способностью
> связно и без грабель алгоритмизировать задачу очень четкая. И в этой
> корреляции джаваскрипт очень, очень плох.Способность связно и без грабель алгоритмизировать приходит с опытом и обучением( в т.ч профильным вузовским, где в т.ч этому учат ).
Тогда как новички, даже с высшим образованием за плечами, на сях, шарпе и жабе запросто пишут эпический гомнокод.> Лично я списываю это на то, что жс сильно нелогичный и плохо
> структурированный, постоянное его использование учит мозги программистов мыслить нелогично
> и плохо структурировано. Ну а общий подход "и так сойдет" (эрроры
> и ворнинги все равно никто в консоли не увидит, если специально
> не откроет) это все полирует и закрепляет.
> И вот на выходе не программист, а гoвнoкодер, программистом по сути не
> являющийся. С, как это среди программистов принято, огромным самомнением.Со своей стороны кстати заметил, что худший жс-код нередко получается у тех, кто ранее кодил на шарпе или джаве - там будто бы какая-то профессиональная деформация, что они ничего не могут делать просто: даже примитивнейшая функция-помощник для обращения к бэкенду у них превращается в несколько файлов, кучу классов с наследованием и пробросом экземпляров одного класса в другой и обмазкой костылями, что потом черт ногу сломит, а если применяется тайпскрипт, то ещё и всевозможными интерфейсами, пометками для того или иного игнора проверок и проч обмазано.. и все равно работает с багами.
Хотя не исключаю, что это профессиональные заработчики, решившие чутка сменить специализацию.> Ха-ха три раза. Что гугл захотел, то пропихнул. Раньше мс пропихивала. Остальные
> подтягиваются и делают как сказали. Ни вы, ни я, ни даже
> контора которую мы бы с вами откроем ничего в вебе не
> решит.Хоть засмейся. Это ситуация последних лет. Но веб как таковой создавался не один десяток лет.. и даже тонны разных префиксов в css не просто так существуют.
И да, это именно результат компромисса: один протолкнул одно и все в итоге согласились, другой - другое, третий - третье, но остальные принципиально забили и фича загнулась.Но таки нет, есть фаерфокс, который уже не тот, если сафари и поделия на вебките, есть хром и какие-то поделия на его движке
Разговоры про то, «как это бы сделать правильно» примерно из разряда «а вот если бы люди всей Земли.. », поскольку полностью игнорируют наличие множества участников, планы и приоритеты которых нечасто совпадают и тот простой факт, что реализация должна по максимуму сохранять обратную совместимость с тем что уже есть.
> Со своей стороны кстати заметил, что худший жс-код нередко получается у тех,
> кто ранее кодил на шарпе или джаве - там будто бы
> какая-то профессиональная деформацияВ джаве все есть класс. Так что да, профессиональная деформация.
Это, кстати, большой минус джавы о котором профессионаллы не уставали говорить с момента ее появления.
>> Что гугл захотел, то пропихнул.
> Хоть засмейся. Это ситуация последних лет.Открываем стандарт, читаем шапку. "I. Fette, Google, Inc., A. Melnikov, Isode Ltd.". Вопрос на 100 очков - кто их этих четырех имел средства и авторитет для решающего голоса? Почему никто из этих четырех, если он действительно разрабатывал стандарт, а не пытался по быстрому продавить нужное решение, так и не сподобился за 11 лет его доделать до состояния "де-юре не драфт"?
> И да, это именно результат компромисса: один протолкнул одно и все в
> итоге согласились, другой - другое, третий - третье, но остальные принципиально
> забили и фича загнулась.Это касается всякой бесплатной мелочи. Крупные вещи, на которых так или иначе можно заработать, усиленно проталкиваются. Тот же ssl принудительно всовывается без всякого мыла даже без попыток как-то подсластить пилюлю.
> поскольку полностью игнорируют наличие
> множества участников, планы и приоритеты которых нечасто совпадаютОй как вы меня сейчас насмешили... У дочери как раз сегодня андроид обновился на ее самсунге, пришла с требованием вернуть все взад, так как "они все поменяли, я не знаю где что теперь, неудобно". И что, ее планы и приоритеты кто-то учитывает? А планы и приоритеты тех сотен миллионов, у которых более неподдерживаемые версии ведроида и которые вынуждены покупать новые девайсы потому что софт на старых больше не запускается?
У меня огромный телек на стене, которому еще полгода нет. Умеет в браузер. Месяц назад ютубчик на нем стал так тормозить, что невозможно смотреть. В итоге я отказался от ютуба, настроил автозакачку через youtube-dl и смотрю через minidlna.
Мои и других пользователей кто-то спрашивал, прежде чем навесить еще какой-то мегатормозной фреймворк на, секундочку, страничку с одним встроенным фреймом и десятком скриншотов? Нет. Гугл просто взял и навесил. И фиолетово, что оно выедает ресурсов не как отобразить десяток картинок и немного текста, а как вычислить последствия ядерного удара на атмосферу Титана при прохождении рядом космического шторма.Наивность прям как у ребенка.
> реализация должна по максимуму сохранять обратную совместимость с тем что уже есть.Вы меня сегодня доконаете. Я помру от смеха.
> Открываем стандарт, читаем шапку. "I. Fette, Google, Inc., A. Melnikov, Isode Ltd.".
> Вопрос на 100 очков - кто их этих четырех имел средства
> и авторитет для решающего голоса? Почему никто из этих четырех, если
> он действительно разрабатывал стандарт, а не пытался по быстрому продавить нужное
> решение, так и не сподобился за 11 лет его доделать до
> состояния "де-юре не драфт"?Стандартов официальных, "стандартов" на стадии допиливания / черновиков и просто замыслов под будущие стандарты более чем немало, нередко сами конторы не совсем понимают что конкретно в итоге "выстрелит" и пример гугла с целой кучей когда-то начатых, а потом заброшенных проектов, равно как и веб-техноллогий - тому наглядный пример.
Само-собой, что в итоге будет принят чей-то стандарт, который пилила в основном конкретная контора( пусть нередко и с правками и доработками, предложенными другими сторонами ), поскольку нельзя принять несколько почти_одинаковых стандартов, друг другу прямо противоречащих. С другой стороны, если другие участники упрутся "рогами" и ни в какую не захотят принимать стандарт, а далее - его исполнять, ценность подобного стандарта будет примерно нулевая( а то и отрицательная ).> Это касается всякой бесплатной мелочи. Крупные вещи, на которых так или иначе
> можно заработать, усиленно проталкиваются. Тот же ssl принудительно всовывается без всякого
> мыла даже без попыток как-то подсластить пилюлю.Не надо путать конечных пользователей, которых никто никогда не спрашивал и сами конторы, которые пилят сервисы, браузеры и проч.
У вас то ли с головой беда, то ли вы целенаправленно уходите от темы - речь изначально шла ИСКЛЮЧИТЕЛЬНО О КОНТОРАХ, ОТВЕТСТВЕННЫХ ЗА РАЗРАБОТКУ. Про конечных пользователей разговора В ПРИНЦИПЕ не шло.
Нынешний веб - результат компромисса между более-мене крупными конторами, а не конечными пользователями, многие из которых в принципе не знают, что такое сокет, шифрование или жс.>> поскольку полностью игнорируют наличие
>> множества участников, планы и приоритеты которых нечасто совпадают
> Ой как вы меня сейчас насмешили... У дочери как раз сегодня андроид
> обновился на ее самсунге, пришла с требованием вернуть все взад, так
> как "они все поменяли, я не знаю где что теперь, неудобно".
> И что, ее планы и приоритеты кто-то учитывает? А планы и
> приоритеты тех сотен миллионов, у которых более неподдерживаемые версии ведроида и
> которые вынуждены покупать новые девайсы потому что софт на старых больше
> не запускается?[2] Не надо путать конечных пользователей, которых никто никогда не спрашивал и сами конторы, которые пилят сервисы, браузеры и проч.
> У меня огромный телек на стене, которому еще полгода нет. Умеет в
> браузер. Месяц назад ютубчик на нем стал так тормозить, что невозможно
> смотреть. В итоге я отказался от ютуба, настроил автозакачку через youtube-dl
> и смотрю через minidlna.
> Мои и других пользователей кто-то спрашивал, прежде чем навесить еще какой-то мегатормозной
> фреймворк на, секундочку, страничку с одним встроенным фреймом и десятком скриншотов?
> Нет. Гугл просто взял и навесил. И фиолетово, что оно выедает
> ресурсов не как отобразить десяток картинок и немного текста, а как
> вычислить последствия ядерного удара на атмосферу Титана при прохождении рядом космического
> шторма.[3] Не надо путать конечных пользователей, которых никто никогда не спрашивал и сами конторы, которые пилят сервисы, браузеры и проч.
> Наивность прям как у ребенка.
[4] Не надо путать конечных пользователей, которых никто никогда не спрашивал и сами конторы, которые пилят сервисы, браузеры и проч.
>> реализация должна по максимуму сохранять обратную совместимость с тем что уже есть.
> Вы меня сегодня доконаете. Я помруРади б.-га.
Если внимательно посмотрите на веб, то "внезапно" обнаружите, что до сих пор вполне-себе работают сайты на старых версиях цсс и хтмл. Более того, последующие версии тех штук обычно являются именно дополненными предыдущими( иногда с багфиксом. Так-то много нюансов особенно касательно жс в зависимости от браузера и даже его типа - мобильный/десктоп, но сути это не меняет ).
Более того, даже жс весьма старых версий( более 10 лет ) без браузероспецифичных штук - очень даже запросто будет исполняться в современных жс движках.
Если с каждым выходом нового стандарта ломать обратную совместимость, от нынешнего веба останется процентов 5-10.Хотя, та замороченность с переходом на https, конечно, разговор отдельный.
Есть подозрение, что конторам-браузеростроителям очень не нравится, что посредники могут перехватывать часть той "бигдаты" вместо приобретения ее у того же гугла.. или правительства могут совершенно законно контролировать траффик и ловить потенциальных террористов( без отстегивания тому же гуглу. Хотя в США они и так могут - крупные медиаконторы обязаны передавать "куда надо" ключи для расшифровки. Не передают - не работают в сша )
Прочитал. Понял.
Существенных возражений нет, а по несущественным сраться уже лень.
> Со своей стороны кстати заметил, что худший жс-код нередко получается у тех,
> кто ранее кодил на шарпе или джаве - там будто бы какая-то профессиональная
> деформация, что они ничего не могут делать просто: даже примитивнейшая
> функция-помощник для обращения к бэкенду у них превращается в несколько файлов,
> кучу классов с наследованием и пробросом экземпляров одного класса в другой
> и обмазкой костылями, что потом черт ногу сломит, а если применяется тайпскрипт,
> то ещё и всевозможными интерфейсами, пометками для того или иного игнора проверок и
> проч обмазано.. и все равно работает с багами.Вот сейчас, как шарписту, работающему в команде шарпистов, было обидно. Мы наоборот стремимся минимизировать количество фронтового кода, написанного бэкендерами. Соответственно, если надо получить что-то от бека на фронт, пишется один метод (ага, без классов, интерфейсов и прочих ООП ради ООП), внутри которого выполняется get запрос и кладётся в data/store, метод занимает строк 10. С учётом обработки ошибок. Да и количество символов в строке не превышает 80. Спасибо axios за это. Может, когда-нибудь и на fetch API перейдём, но пока он в нашем случае больше бойлерплейта вынуждает писать.
Про джавистов не скажу, после университета, где всё делалось на джаве, морально не мог больше на нём писать без сбегания на любую другую платформу, хоть Rust, хоть Python, хоть TypeScript.
> Хотя не исключаю, что это профессиональные заработчики,
> решившие чутка сменить специализацию.Это ИМХО гораздо ближе к правде. ЧСХ, курсы эти выпускают питонистов, джавистов, гошников, пхпшников и джсников - всего 5 языков популярны у "стань прогером за месяц/полгода/год". На шарпе подобных курсов крайне мало (только ITVDN и по Unity), вся актуальная инфа всё-таки на английском. Либо универские, от того же УРФУ, например, но там всё-таки основы, а не для коммерческой разработки.
Знатно меня бомбануло.
А если рыть дальше, то можно увидеть взаимозависимость ещё и с основным разговорным языком и грамотностью.
> А если рыть дальше, то можно увидеть взаимозависимость ещё и с основным
> разговорным языком и грамотностью.С разговорным языком это никак не связано, много уже было проведено опытов.
А грамотность скорее просто следствие уровня образованности и порядка.
Я вот в целом даже согласен, но даже тут неадекватности умудрилось вылезти местами, хотя вот вроде понимающий же...Ну вот смотри, в паре соседних абзацев написал это:
> Точно так же делаются всякие расты, из-за чего их и хейтят. Мы то знаем и помним, как правильно делать подобные вещи.и это
> Я отвечу - потому, что все делается на коленке болванами и торопыгами. Да, продуктивными болванами, но от этого не менее болванистыми (и более вредными). Буяк-буяк-и-в-продакшен, web 2.0, аджаааааайл, некогда думать надо делать, прыг-прыг-прыг.
> Артефакты прошлой текучки. Эхо аджайла и разгильдяйства. Отголосок сломанного кривыми технологиями мозга (я намекаю на джаваскрипт).Но при этом ты прекрасно знаешь, что вот это вот "Буяк-буяк-и-в-продакшен" написано на сях и плюсях.
Проблема не в расте, а вот в этих вот как раз "болванами и торопыгами @ некогда думать надо делать", а раст - это такая попытка сделать плюсы в которых отстрелить себе ногу сложнее, если прямо не написать в коде: "я здесь сейчас будут стрельбой себе по ногам заниматься". Причём рабочая попытка, потому что найти тех, которые "Мы то знаем и помним, как правильно делать подобные вещи" сейчас всё сложнее. И даже они НИКОГДА не писали код (в больших объёмах если) без тех ошибок, от которых немного помогает раст (ну то есть даже у ЛУЧШИХ случались такие ошибки в коде).
Отвечу не совсем по порядку> Но при этом ты прекрасно знаешь, что вот это вот "Буяк-буяк-и-в-продакшен" написано на сях и плюсях.
Это не имеет отношения к теме разговора. Будет желание - можем обсудить отдельно.
> Проблема не в расте...
Структура языка раст объективно плоха. Она плоха тем, что не продумана изначально. Попытка была прекрасна - сделать очередного конкурента С (не плюсов - в плюсах есть различные умные указатели, которые проблему полностью решают; а отсутствие обычных указателей можно автоматически гарантировать на этапе приемки простым скриптом на баше; в плюсы элементарно встраивается сборщик мусора и т.д. и т.п.). Конкурента, который лучше, удобнее, безопаснее и т.д. Таких попыток, если вдруг кто не в курсе, всегда было много.
Но из-за того, что изначально никто не дал себе труда подумать, начальный красивый и простой дизайн превратился в заплатанного монстра франкенштейна с кучей различных стенографических значков. Как вам поинтеры &, &mut, *const, *mut...? Как вам выражение "let r2 = &mut num as *mut i32"? Красиво? Интуитивно? Логично?
В мозиле это увидели и это единственная причина, по которой раст выкинули на мороз. Им не нужен монстр.
Поэтому лично я раст не люблю. Я люблю красивые и стройные языки, которые позволяют легко транслировать идею в команды компьютеру. Я люблю С (не С++), я люблю руби, я очень люблю схему (почти идеальный язык - жаль только что люди по историческим причинам предпочли инфиксную нотацию в математике, а не префиксную - тогда бы это был совсем идеальный язык), мне нравится, между прочим, шарп (хотя в свое время майкрософт сделала все, чтобы его похоронить - но он воскресает). Раст не красивый и не стройный.
> найти тех, которые "Мы то знаем и помним, как правильно делать подобные вещи" сейчас всё сложнее
Это больной вопрос. Вы правы, индустрия быстро растет, а профессионалов больше не особо становится. Так тем более к основным вещам надо относиться с повышенным вниманием (я вот лично к этому прикладываю по мере сил свою руку). Веб, как основа информационной ноосферы, особенно должен поддерживаться профессионалами, а не дилетантами.
Вы же не наймете таджиков проектировать из говна и палок небоскребы только потому, что "нормальных архитекторов мало, сложно найти"?
> И даже они НИКОГДА не писали код (в больших объёмах если) без тех ошибок, от которых немного помогает раст (ну то есть даже у ЛУЧШИХ случались такие ошибки в коде).Этот сомнительный плюс что-то вроде обязательных отступов в питоне (боже, более идиотского решения в языке я никогда и нигде не видел - кроме эзотерических, само собой), который можно решить различными статическими автоматизированными процессами и общей культурой кода в любом языке, нивелируется остальными минусами.
> в плюсах есть различные умные указатели, которые проблему полностью решают; а отсутствие
> обычных указателей можно автоматически гарантировать на этапе приемки простым скриптом на баше;
> в плюсы элементарно встраивается сборщик мусора и т.д. и т.п.Только вот всё совсем наоборот. Тот же Торвальдс к плюсам относится плохо, предпочитает чисты Си, в том же время против Rust ничего плохого не имеет.
Хотя бы потому что
> в плюсах есть различные умные указатели, которые проблему полностью решают
Это неправда.
> в плюсы элементарно встраивается сборщик мусора
И это не совсем правда, спросите у Microsoft, запиливший реализацию C++/CLI, поддержку которого почему-то в .NET Core не завезли. Интересно - почему? Не от того ли, что С++ всё-таки плохо решает (но решает!) задачи, в которых он используется?
И не от того ли Вы сами назвали Rust конкурентом C, а не C++, тогда как создатели языка никогда его так не позиционировали?
> "let r2 = &mut num as *mut i32"
Если Вам не нравится код, который Вы написали - может быть дело не в языке?
Если Вас пугает этот код, то низкоуровневый код на С/С++ Вам точно не стоит открывать.Вот серьёзно, Вы сами выдумали, что Rust - конкурент C, из этого кучу проблем вывели. У C своя ниша, у Rust - своя, никто (кроме Вас, что как бы намекает) не называл его "убийцей C".
>> в плюсах есть различные умные указатели, которые проблему полностью решают
> Это неправда.Если пошла такая пьянка, Boehm GC так то и на сях есть. Наверное и еще дохрена кого, этого просто чаще всего упоминают.
> У C своя ниша, у Rust - своя, никто (кроме Вас, что как бы намекает) не называл его "убийцей C".
Они местами пересекаются. Может поэтому? Однако попрогать на хрусте под PIC12, имхо, хайпожорам будет слабо. Слишком мелкотравчатый, хелловорлд весь чип займет.
> Если пошла такая пьянка, Boehm GC так то и на сях есть. Наверное и еще дохрена кого, этого просто чаще всего упоминают.И как успехи у Boehm GC? Вы его сами использовали или нагуглили только что?
> Они местами пересекаются. Может поэтому? Однако попрогать на хрусте под PIC12,
> имхо, хайпожорам будет слабо. Слишком мелкотравчатый, хелловорлд весь чип займет.А с какой целью кто-то вообще будет писать под микроконтроллеры на языке, заточенном под современные многоядерные процессоры?
Не станете же вы в борщ масло класть. Борщ - не каша, насколько мне известно. И микроконтроллеры, насколько мне известно, не спроектированы для параллелизации вычислений.
Да и проблема незрелости Rust до сих пор нерешена - компилятора родного нет, пока ни Google, ни Microsoft, ни кто-либо другой не проинансировали разработку полноценного компилятора, а не того MVP, что есть сейчас.
> И как успехи у Boehm GC? Вы его сами использовали или нагуглили только что?Я использовал. Это очень известный проект.
И как он под PIC12 идёт? Не мешает?
> И как успехи у Boehm GC? Вы его сами использовали или нагуглили только что?Сам я его не использовал, но он есть - и используется энным количеством проектов. А мне под внимание попал потому ... что его упоминали энные проекты, очевидно.
> А с какой целью кто-то вообще будет писать под микроконтроллеры на языке,
> заточенном под современные многоядерные процессоры?Да вон под STM32 и авр пытаются. И для языка претендующего на системность есть некий пойнт
- Boot ROM, boot loader, кернелы и проч работают в специфичном и/или ограниченном окружении.
- В мире есть хренова куча задач кроме переросточных мегасерверов с нафигнужным вебмакакингом. Как бы это, 1 проц крутящий движок поезда пары сотен бесполезных серверов с котиками стоит.
- Си такой успешный потому что масштабируемый и универсальный. Хошь кучу тредов на 100500 ядрах, хошь микроконтроллер мелкий. Удобно.TL;DR wannabe-системный язык должен уметь в системщину очевидно. Иначе какой он системный? :)
> насколько мне известно. И микроконтроллеры, насколько мне известно, не спроектированы
> для параллелизации вычислений.И чего? А допустим одноплатники - это что? Там может быть 1 ядро. Или несколько. По смыслу как небольшой компьютер скорее уже. Впрочем в отличие от ламо есть и более вменяемые люди, понимающие что на очередном переростке с вебмакаками мир не кончается.
> Да и проблема незрелости Rust до сих пор нерешена - компилятора родного нет,
Зато синтаксис уже переколбасили до уровня плюсов, пожалуй.
> пока ни Google, ни Microsoft, ни кто-либо другой не проинансировали
> разработку полноценного компилятора, а не того MVP, что есть сейчас.Эти решальщики проблем на удивление талантливы в их создании.
> C++/CLI, поддержку которого почему-то в .NET Core не завезли.Поддержку .NET Core в C++/CLI добавили в прошлом году. Тут дело не в .NET [Core], а в том, что единственным компилятором с поддержкой C++/CLI до сих пор является MSVC. Подозреваю, остальным просто нафиг не упёрлось тратить время и силы на реализацию этого мутанта, по своей природе поддерживающего только пересечение множеств фич плюсов и .NET.
Ага, "фич" плюсов. Которые почему-то даже Microsoft с огромным штатом разрабов не реализовала полностью. Какой там стандарт заявлен как полностью поддерживанмый? Насколько помню, никакой, потому что они только по кусочку из каждой новой версии стандарта добавляют.Тот же Unity почему-то тоже перешёл с плюсов на C# как основной язык.
При этом .NET развивается самимильрвми шагами, наверное между C++ и .NET проблема всё-таки не в .NET.
> даже 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).
> Ага, "фич" плюсов. Которые почему-то даже Microsoft с огромным штатом разрабов не
> реализовала полностью.Они C99 c какого там года полностью реализовать не могут? А ты эвона чего от них захотел. Им видите ли удобнее всего было бы продавать новую версию как кр00тую и улучшенную вообще без переделки.
> Это не имеет отношения к теме разговора. Будет желание - можем обсудить отдельно.Очень даже имеет: ты привёл в пример вебсокеты, как пример "Буяк-буяк-и-в-продакшен" (и правильно привёл), но ведь в самом популярном браузере в мире вот это вот всё с вебсокетами написано не на расте. Сам назовёшь, на чём?
> в плюсах есть различные умные указатели, которые проблему полностью решают
Если решают, то почему проблема еще не решена? Это был риторический вопрос. Правда в том, что не решают.
> заплатанного монстра франкенштейна с кучей различных стенографических значков. Как вам поинтеры &, &mut, *const, *mut...? Как вам выражение "let r2 = &mut num as *mut i32"? Красиво? Интуитивно? Логично?
Если уж речь про красоту и интуитивность - не страшнее ассемблера выглядит, но это просто к слову. Ну вот, говорил "Мы то знаем и помним, как правильно делать подобные вещи.", а сам непривычного синтаксиса испугался.
Я, кстати, читал спор, который вот так же начинался: "этот ваш синтаксис в расте - г*вно, надо было логичнее". Но на вопрос предложить лучше в каждом конкретном случае - не мог: косяки ипротиворечия лезли в "пропозалах".
Вообще, для того, кто "знает и помнит, как правильно делать подобные вещи" ты ведь прекрасно должен быть в курсе, что новички требуют синтаксис поочевиднее (но он всегда получается многословнее), а профи хотят синтаксис "поэффективнее". И баланс найти сложно. И языки, котоыре выбрали первый путь или вымерли или являются нишевыми, а которые выбрали второй - стали стандартами отрасли.
И именно так вместо написания очень очевидного, красивого, интуитивного и логичного "equal" во многих современных ты пишешь значок типа "=", вместо "more" "less" - "<" и ">" и т.д. Такого полно и в сях и в плюсях и еще почти во всех СЯПах. Просто там ты уже знаешь синтаксис и привык, а в расте - не знаешь и/или не привык (и не хочешь, а в этом случае уже ничего не поможет).> Вы же не наймете таджиков проектировать из говна и палок небоскребы только потому, что "нормальных архитекторов мало, сложно найти"?
А это не и мне не тебе решать, увы. Нанять одних только супепрофи (и получить с них потом суперкод) еще никому не удалось. Оффтоп: к слову, о небоскрёбах - поищи фотки строителей первых Нью-Йоркских небоскрёбов - вполне себе "таджики" по американским меркам были.
> Этот сомнительный плюс
Если этот плюс защищает от некой (ЧАСТОЙ!) категории ошибок, то это хороший плюс. Например, это самый частый тип ошибок в коде фаерфокса, по заявлению самой мозиллы. Они из-за этого и стали раст пилить-то.
> Вот так base64 с гуидом и остались. Артефакты прошлой текучки. Эхо аджайла и разгильдяйства.И чё? Это приводит к каким-то неприятностям, или что?
> Так в стандарте (rfc6455) и написано прямым текстом "base64".
Ты точно стандарт читал?
Там смотри что:
> 1.3. Opening Handshake
> _This section is non-normative._non-normative, да?
> И чё? Это приводит к каким-то неприятностям, или что?Вот! Прекрасная иллюстрация моего комментария о говнокодерах, искалеченном мозге и невозможности им быть программистами.
> non-normative, да?Дорогой Ordu, если ты не заметил, то каждый (каждый!) раздел стандарта rfc-6455 помечен плашкой "_This section is non-normative._". Это такая де-юре отметка старших умных дядей, что они эту фигню не одобряли и одобрять не собираются. Чтобы потом стыдно не было.
Де-факто (и де-юре) этот стандарт принят еще в 2011 году (с парой маленьких апдейтов, по сути ничего не меняющих), "спасибо" Гуглу. Все реализации webSockets ему следуют. И если ты сделаешь иначе, то твой код не будет общаться с браузерами и веб-серверами.
>> И чё? Это приводит к каким-то неприятностям, или что?
> Вот! Прекрасная иллюстрация моего комментария о говнокодерах, искалеченном мозге и невозможности
> им быть программистами.Отличный аргумент. Я люблю такие. Убеждают на все 100%. Остальные вопросы отпадают.
> Отличный аргумент. Я люблю такие. Убеждают на все 100%. Остальные вопросы отпадают.Ну еще бы не любил. Типичный (коих 95%) человек обязательно выберет способ избавиться от неприятных и/или непонятных аргументов путем концентрации на не относящееся к делу, но потенциально обидное.
Это был комментарий не для тебя, а для других. А ты проходи мимо, не порти себе нервы, эффект Даннинга-Крюгера не спит.
>> Отличный аргумент. Я люблю такие. Убеждают на все 100%. Остальные вопросы отпадают.
> Ну еще бы не любил. Типичный (коих 95%) человек обязательно выберет способ
> избавиться от неприятных и/или непонятных аргументов путем концентрации на не относящееся
> к делу, но потенциально обидное.Ты льстишь себе. Ты можешь на говно изойтись тут и меня не обидеть. У тебя просто интеллекта не хватит. На самом деле ни у кого на опеннете не хватит интеллекта меня обидеть, потому оно даже потенциально не обидное. А вот ad hominem в качестве аргумента, и ноль технической аргументации -- это уже диагноз.
> Это был комментарий не для тебя, а для других.
Да-да, оправдывайся теперь.
Вся техническая аргументация была в первом комментарии. Не моя проблема, что твой сверхинтеллект не смог ее осилить а смог только выдавить из себя "ну работает же, не вижу проблемы".Ну да, не видишь, о чем и речь.
> Вся техническая аргументация была в первом комментарии.Пфф... Ты вопроса моего не заметил? Просто так языком болтал?
> Ну да, не видишь, о чем и речь.
Старайся сильнее -- может тебе всё же удастся меня оскорбить? Докажи нам своё превосходство в интеллекте. Мы болеем за тебя.
Зачем мне тебя оскорблять и доказывать совершенно очевидные вещи? Ты еще попроси доказать что днем светло и ночью темно.И почему ты о себе говоришь "мы"?
> Зачем мне тебя оскорблять и доказывать совершенно очевидные вещи?А чем ты здесь занимаешься интересно? Если не тем и не этим, то чем?
> И почему ты о себе говоришь "мы"?
Ты же выше говорил о том, что твои слова предназначены всем читателям? Вот я от их лица и жду. Хоть чего-нибудь.
Non-normative означает всего лишь то, что секция написана языком, не соответствующим rfc2119.
> к этой строке надо конкатенировать другую строку "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") строка.
> Читаем внимательно.Попробуйте, пока у вас не вышло.
> Вы вообще не поняли что там написано и про что этот 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=), от этого смысл ни на йоту не поменяется.
Теперь понимаете?
По-порядку.---> Почему не написано "к этой строке надо конкатенировать другую строку "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". Надеюсь что так и дальше останется.
Мда. Сплошнолй фейспалм. Ordu выше и то умнее выступил.Что я могу на все это ответить? Только одно: "Прекрасная иллюстрация #2 озвученного в первом комментарии тезиса. Даже более красноречивая, чем #1".
Очередной эффект Даннинга-Крюгера.
Ну вот Васе и нечего по-сути ответить, по спецификации.
Вася не умеет внимательно читать и, тем более, понимать спецификации.Вась, признавайся, эникейщиком работаешь али в отделе кадров засидаешь.
Твой технический и экспертный уровень понятен. Он... сколько таких "Вась-экспертов" с opennet.
На джуниора не тянешь. Проходи повышение квалификации, может я тебя к себе может возьму.
> WebSockets. Очевидно, нужная вещь. Работающая. Полезная.Никогда не понимал, зачем использовать это трудно-реализуемое дерьмо, если есть простой и нативный (для HTTP протокола), SSE, который в тандеме с redis отлично работает!?
Не знал о таком.
> Не знал о таком.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
В общем такие гугловые специалисты растут....
Ну тот проект я уже давно сдал, а за информацию спасибо. Почитаю и если придут с похожей задачей возможно попробую предложить.
Да ладно тебе, вебсокеты не монструозные. Там конечно есть скелеты в шкафу, но вообще простой дровяной протокол, его даже мелкий lwan себе запилил. И таки оно именно нормальный поток, с произвольными данными, более потребный для околореатлаймных коммуникаций типа чатика или апдейтов статусов/переменных. А не какой там HTTP на костылях. Хоть вебмакаки и навебмакачили, конечно, малость.HTTP сам по себе сильно монструознее - и имеет множество бестолковостей. В том числе очень вредных. Например желающие могут загуглить про slowloris и чего вообще можно делать с HTTP даюы нагнуть вам сервер. Ну вот например размер хидеров никак особо не лимитирован, и если саботер будет их слать в час по чайной ложке, большая часть серваков вообще конекцию не закроет и будет жрать ресурсы на обслуживание слоупока условно-вечно. Если слоупок был вредителем и наплодит таких конекций - довольно скоро сервер утрачивает способность обслуживать легитимных юзеров. Самому слоупоку атака обходится не сильно дорого по ресурсам, у него контекст может быть сильно меньше.
Что за дичь Вы несёте!?
Зассанный казачёк от Гугл или просто идиот?
Slowloris и прочие атаки возможны только на коряво настроенном сервере.
На нормальном сервере (последний nginx с дефолтными настройками) таймауты и прочие ограничения такого сделать просто не дадут, а если кто-то попытается, то в логах этот вредитель быстро будет замечен и забанен.
WebSockets монструозен, по сравнению с SSE, на котором и чатики и всё остальное, включая обновления страницы в реальном времени без перезагрузки, можно гораздо легче и эффективнее организовать.
Шли бы Вы со своим Иваном и прочими гулоботами отсюда нафиг!
> Зассанный казачёк от Гугл или просто идиот?Тот кто поигрался с HTTP, ws и издевательствами над ними на низком уровне, а также и потестивший всякие странные приколы. Пойдет? :)
> Slowloris и прочие атаки возможны только на коряво настроенном сервере.
ЧСХ на момент его появления такими были чуть более чем все. А наименее корявым - IIS (фэйспалм!)
Кроме того - вот именно хорошего фикса slowloris'а не существует в природе. Попытка фикса либо будет гасить юзеров на медленных и перегруженных каналах, либо у слоупока дочерта времени слоупочить, занимая на себя ресурсы.
> На нормальном сервере (последний nginx с дефолтными настройками) таймауты и
> прочие ограничения такого сделать просто не дадут, а если кто-то попытается, то в
> логах этот вредитель быстро будет замечен и забанен.Блажен кто верует. Во первых, так можно забанить и юзеров на протормозившем линке. Во вторых, при именно атаке сие можно и распределенно прилунить. В третьих он все-равно достаточно эффективный, я проверял, создать проблемы серваку - реально.
> WebSockets монструозен, по сравнению с SSE, на котором и чатики и всё
> остальное, включая обновления страницы в реальном времени без перезагрузки, можно гораздо
> легче и эффективнее организовать.Я не знаю кому там и что "легче" но выглядит это как попытка натянуть сову на глобус. А ws таки может быть совершенно отдельный канал, не имеющий ничерта общего с HTTP и его протоколом после его подъема, по поводу чего там может гулять эффективный task-specific протокол, вообще никак не завязаный на HTTP и ближе всего это, натурально, к сетевому сокету. И я не вижу ничерта сложного с подъемом ws, это и в js делается парой строк, да и на стороне сервера не сильно сложнее. В lwan examples этого есть и назвать все это сложным - глум над здравым смыслом.
> Шли бы Вы со своим Иваном и прочими гулоботами отсюда нафиг!
Каким еще иваном? И вообще, я к гуглу прохладно отношусь, что не мешает считать вебсокет довольно удобным и простым для периодического апдейта каких-то данных или околореалтаймных штук типа чатиков. А кучка легаси и вебмакакинга в протоколе - ну да, но тупняков и в HTTP есть. Черт, мы даже не знаем размер хидеров заранее, как минимум в HTTP/1.x точно. И поэтому даже не можем сразу отлупить заведомо офигевшего клиента (типа slowloris'а) - только дурацкой эмпирикой выезжать, которая неуниверсальна и косит легитимных юзерей под шумок, виноватых тем что в каком-нибудь поезде ехали и линк тупил.
Потому что SSE односторонний - с сервера к клиенту. Для отправки данных от клиента к серверу придется использовать HTTP запросы и как-то отправлять ответ через SSE.
Вебсокеты - двухсторонние. Можно получать данные от клиента, можно отправлять данные клиенту. Обработку данных можно производить в рамках одного класса.
> Потому что SSE односторонний - с сервера к клиенту.Ещё один гуглобот...
Потому что через HTTP есть дофига способов отправить сообщение от клиента к серверу, в отличие от WebSockets, который НЕ может работать через HTTP, и он ВЫНУЖДЕН реализовать канал от клиента к серверу, который в случае с SSE просто не нужен, так данные в обе стороны проходят через HTTP в рамках одного класса!
И этот вынужденный костыль, маркетолухи гугла раскручивают как мегафичу...
> Ещё один гуглобот...Попрошу без перехода на личности. Называть всех, кто не согласен с вашим мнением, ботами - это признак дурного тона и некомпетентности.
> Потому что через 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? :)
> Это не "дофига способов", это только три.А этого мало, или мы за неимением аргументов переходим к придиркам к словам?
> В конечном счете все сводится к тому, что практически всегда данные передаются
> в теле запроса, в том или ином сериализованном виде.
> этой точки зрения нет никакой разницы, что использовать.То есть Вы признаёте что двунаправленность WebSockets это просто маркетинговый пиар, а вовсе не преимущество над SSE.
> Кстати, у SSE есть большой, жирный минус: через него нельзя передавать бинарные
> данные, у него используется \n\n как разделитель сообщений.Необходимость передачи бинарных данные у меня и не возникала, но решается элементарно с base64.
>> И этот вынужденный костыль, маркетолухи гугла раскручивают как мегафичу...
> И SSE, и Websocket были разработаны в рамках группы WHATWG. В нее как бы не только Google входит.Не важно кто входит в группу, важно кто пиарит или каким-то образом поддерживает этот пиар.
docker и kubernates тоже не один гугл разрабатывает, но вкладывается пиар, прямо или косвенно, именно он!
>> Это не "дофига способов", это только три.
> А этого мало, или мы за неимением аргументов переходим к придиркам к
> словам?Это не "дофига", это "несколько". И как раз ваш вопрос является придиркой.
Аналогично можно передавать данные в 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 пиарит, используя в своих консолях...
> Так вот, повторюсь - HTTP/3 такое же непродуманное ненужно. Для веб-страничек не
> нужен очередной велосипедный TCP, им и классического с головой хватает.Угу, пока в вафле или сотовом линке шумок в канале лаг не повысит или пару пакетов не выбьет. После этого кубические рено устраивают форменный диалап, в то время как линк бездействует и близко не перегружен.
И так то оно ничего - но вот смотрит юзер ютут - бац - крутится. Хотя, казалось бы и канал в инет жирный, и вафля не загружена. А вот поди ж ты, факап на ровном месте.
HTTP/G[oogle]
GMTP -- Google Money Transfer Protocol/
Google Monkey Tree of Palm
Забыли упомянуть, в лучшем браузере Opera так-то HTTP3 давно есть
Чем это Опера самый лучший? Просвятите неумытого ?
> Чем это Опера самый лучший? Просвятите неумытого ?Просвящать немытых - прерогатива священников.
Лучший был 12 опера и там нету хттп3 до сих пор.
Не был он лучшим. Там ни аблока нормального не было, ни дополнений. Зато был свой электрон встроенный.
>Код компонентов для поддержки HTTP/3 и QUIC написан на языке Rust.А тут возникали, что типа раст не нужен.
А скоро в ядро поддержку QUIC завезут?
ну там поддержку раста уже анонсировали
так что скоро достаточно будет в манифесте ядра прописать neqo - и считай готово!)
> раст не нужен.У FF, которого растаманы покусали, всего 1% рынка, так что - да, не нужен оказался. А про QUIC сам Гугл уже высказался, что это была ошибка, ничего хорошего на практике не получилось.
Про долю - ваша фантазия , а по гуглу - некомпетентность , гугл заменяет в хроме QUIC именно на HTTP/3 .
> гугл заменяет в хроме QUIC...
> заменяет QUIC
> QUICОткрой глаза и перечитай, я именно это тебе и говорил.
как растаманы могли покусать лисов если лисы вообще изначально создали раст чтобы в том числе писать на нём более безопасный код браузера и тогда у них ещё операционка мобильная была для неё он тоже создавался.?
не получилось у квика стать общепринятым и распространённым стандартом. именно поэтому он был переработан в нттр/3 так чтобы даже сафаревцы его внедрили.
Я правильно понял что HTTP2 провалился как замена HTTP1.1 ? Ну раз до его полноценного внедрения дело не дошло и его уже пришлось заменять новым протоколом?
Хоть в этом есть и плюс, что выкидывают неудачные технологии, но минус в том что выкидывают и рабочие старые, в то время как новые оказывается вот таким вот мусором
Неправильно . http2 - для котиков , http3 - для порнухи .
Суть не в этом. Когда придумывали http/2, большая часть народу сидела через надежный кабель, позволявший вместо http pipelining времён http/1 мультиплексировать загрузку нескольких элементов внутри одного TCP соединения. А сейчас 2/3 оконечных устройств сидят через корявую wifi или через 3/4/5G и потеря одного TCP пакета ведёт к тормозам всего мультиплексированного потока...... решили, что вернёмся во времена http/1 с множеством отдельных соединений. Только завернули это поверх UDP, т.к. он реально большую скорость на вафле даёт из-за меньшего оверхеда при передаче через беспроводной (не обязательно вафля) фрейм. Беда только в том, что контроль потока теперь не на ядре лежит, а в пространстве пользователя. Да и лично у меня после включения HTTP/3 кол-во соединений подскочило на 50%!!!
На корпоративном NextCloud пришлось сразу отключить HTTP/2 из-за сильных тормозов.
Не исключено, что проблема на самом деле в корпоративных же файрволах.
> отключить HTTP/2 из-за сильных тормозовГугл уже давно именно про это и говорил, что ошиблись, вводя новый стандарт.
Пруфлинк?
Можно какие-то ссылки? Интересно.
> до его полноценного внедрения дело не дошло и его уже пришлось
> заменять новым протоколом?В смысле не дошло? Теперь буквально каждый второй сайт в дебагтулсах кажет HTTP/2. Нихрена себе не дошло.
Уже есть http/2? O_o
Уже не просто есть, но уже и декомиссован.
Брехня.
Там вроде нормально производительный http3 клиент не на расте до сих пор только у МС, пока не появится нормальной реализации им только полторы корпы и будут пользоваться. И если 3 проседает на воздушном соединении как и 2, то он вообще не упал пользователям, а сервера пусть используют что хотят для общения между собой (это всё же сокращение трафика и задержек, процентов на 5-15 может). Зачем в браузеры эту гадость тянуть?
> Уже не просто есть, но уже и декомиссован.И, конечно, ты покажешь линк подтверждающей это смелое заявление? А то нетмонитор совершенно не подтверждает этот чудный тезис: 70% конекций было HTTP/2.
Гугл уже отказывается от http/2
От хрома гугл тоже отказывается ? )))
Я его из-за багов в haproxy уже успел два раза выключить и назад включить за последние 1.5 года...
С QUIC/http3, сдаётся мне, будет ещё хуже.
когда там уже только https по умолчанию
вы ребят в прошлом веке остались со своими "тисипи это наше все, да нееету выигрыша от удп".
пройдет пару лет, поймете, что были неправы, вернитесь в этот тред, извинитесь за эти минусы.
сейчас связь иная, не предназначены тайминги тисипи для скоростного мобильного интернета. ну никак.
так что давите минус, фактически оценивая сами себя, мне даже забавно это печатать щас
>скоростной мобильный интернетСегодняшних скоростей хватит всем за глаза и за уши. Уродовать сетевой стек ради нетфликс-унтерменшей с их 4к на мобилках?
Скоростей хватает. А задержки никуда не делись.
> Скоростей хватает. А задержки никуда не делись.А также дичь которую творит congestion control на беспроводных линках. Когда быстрый и не загруженный линк стараниями tcp congestion control резко превращается в диалап.
Нетфликс как раз не юзает UDP, они пилят rack+brr в ядро фри и вроде ядерный TLS тоже их рук дело.
В треды не возвращаются <мрачная музыка>...Выше уже написано в чём проблемы и зачем этот протокол захотели.
Это пока не начинают приходить пакеты из будущего (что сплошь и рядом), тогда ты начинаешь ценить тцп. Да и к потерям как я посмотрю тцп куда устойчивее.
> Да и к потерям как я посмотрю тцп куда устойчивее."Зависание - самое стабильное состояние". Примерно так это в TCP и работает - с потугами слать пакет раз в... в... в 60, чтоли, секунд максимум? Ну а вы минуту покурите бамбук, если потери пакетов в беспроводном линке так оказались. И похрен что шум в канале давно пропал.
5g обещает сверхмалые пинги. Wi-Fi AC даёт их уже на частоте 5 ГГц.
Речь о пингах до оператора. Дальше пакет может улетать очень далеко и на долго. И здесь никаких перспектив, ибо скорость света ограничена, и количество промежуточных узлов, вносящх задержку, сильно не уменьшится ввиду привязке структуры сети к геополитике.
Вы знаете хоть одну пару мест мире пинги между которыми больше 250 мс? 250 мс это четверть секунды, за четверть секунды к Вам прилетит потерянный фрагмент. Кстати TCP не прерывает приём данных из за потерь, просто он временно не сможет создать непрерывный поток и отдать его приложению. Но он всё ещё скачивает данные пока буфер не забъётся.
> Вы знаете хоть одну пару мест мире пинги между которыми больше 250 мс?Попробуй центр крупного города или большой дом с соседями, чудак. Увидишь много чудес, вплоть до ютуба который что-то loading и не поспевает, хотя линк вроде бы изумительный.
Речь шла о проводе после беспроводки. Страдальцам в диапазоне 2,4 ГГц можно только посоветовать переползать в 5 ГГц. По поводу "изумительного" 4g можно сказать лишь то, что сотовой оператор очень сэкономил на вышках и там тупо не хватает пропускной способности. Это не техническая проблема, а организационная. И от UDP там лучше не станет. Собственно Гугл давно по умолчанию использует quic для своих сервисов, а YouTube всё ещё лагает. Гугл кстати тоже любит деньги экономить и наивно ждать от него 4к в прайм-тайм.
> Речь шла о проводе после беспроводки. Страдальцам в диапазоне 2,4 ГГц можно
> только посоветовать переползать в 5 ГГц.Как ты думаешь, сколько каналов по 160 МГц этого вашего новомодного AC там поместится? Диапазон не резиновый :) Поэтому сорян, но в погоне за гигабитами сосед уже начал фонить в ваш канал и если он удумает торенты качать - упс! А если так с десяток козлин вокруг - еще накупивших супермощных микроволновок, т.к. иначе оно даже до соседней комнаты не долетает - в общем то там уже начинается то же самое.
А чтобы вы совсем не скучали, понавесили еще всяких беспроводных допплер-радаров чуть менее чем везде (охрана и автовключение света). Эти обычно в 5ГГц гадят. Не очень мощно, но популярные и напиханы много где.
> По поводу "изумительного" 4g можно сказать лишь то, что сотовой оператор очень
> сэкономил на вышках и там тупо не хватает пропускной способности.Вы можете проспонсировать им пару сот. Они явно не откажутся от такого подарка. А еще только подумайте, бывает движущийся транспорт! Там беспроводные линки нестабильны by design. Хотя-бы потому что условия приемя круто и быстро меняются и с этим сложно что-то сделать. Поэтому всегда возможна ситуация когда вон те 5 секунд пакеты не летали в принципе. Для гамна типа кубика это приговор! Он будет туповэйтить минуту, за которую юзер как раз проедет мимо офигенной соты через которую мог бы уже давно скачать полинтернета и полчаса видео в буфер. А к моменту когда он расчехлится на retry, сота как раз опять пропадет - и в общем это даже не диалап.
> Это не техническая проблема, а организационная.
А юзер едущий в поезде или машине - это какая проблема? В мозгах тупарей не понявших что сети стали повсеместными, беспроводными, и с очень разными и динамично меняющимися условиями?
> И от UDP там лучше не станет.
Там принципиально нет конских таймаутов в минуту, а планировщик может как-то сильно более вменяемо реагировать на упомянутые ситуации. При том все это счастье будет доступно и юзерам виндов. А то что у гомнопровайдеров их шыт с бсд позагибается - чтож, потанцуем на могилке тех кто не умеет работать. Из время вышло.
> Собственно Гугл давно по умолчанию использует quic для своих сервисов, а YouTube всё ещё лагает.
Проблема в том что на TCP он не только лагает - но иногда умудряется делать это вообще на ровном месте.
> Гугл кстати тоже любит деньги экономить и наивно ждать от него 4к в прайм-тайм.
В этом как ни странно мы похожи. Поэтому мне эффективный протокол не делающий мозг тоже пригодится. А все эти кубики в современном мире реально заколебали и должны умереть. Они из эпохи диалапа и работат под стать, полагая что лаг в 60 секунд - ОК. За это время юзер на транспорте проезжает пару сот, бжад!!! И все эти потуги грубо иррелевантны тому что вокруг творится.
Да хосспаде, почти любой ресурс в Китае за 200, если из этой страны пинговать или из Европы.
Спасибо их "анальному файрволу".
> 5g обещает сверхмалые пинги. Wi-Fi AC даёт их уже на частоте 5 ГГц.Радио не бывает 100% надежным. Вздрист шума в канале и вот вам уже сверхмалые 50 мс. А то и потеря пакетов. А в клиническом случае и link loss. Думаете, как глушаки работают? :)
Это пока 5 ГГц не так засраны (соседями), как 2.5
"Связь бывает или проводная, или никакая"
Нет, это вы ходите кругами изобретая свой TCP, и заново СС для него.
> Нет, это вы ходите кругами изобретая свой TCP, и заново СС для него.А что поделать если работа TCP грубо иррелевантна современным реалиям? Оно вообще полагает нормальным таймаут догонять до чуть ли не минуты. Очень офигенно работает в движущемся транспорте, соты мелькают мимо, но вы ни бита не передадите из-за туповэйтинга. Зачем такой протокол в 2021 году уперся?
Реалии отличаются от ваших представлений о них.Роуминг - это из другой оперы, но если вы собираетесь перепосылать любой пакет который не аскнули за 100-500мс то вы положите сеть, аналогично если будете перезапрашивать так агресивно. И TCP довольно гибко аскает и запрашиват ретрансмиты, если что.
Радует пока одно: порубав UDP с src/dst=443, можно от этого счастья избавиться почти гарантированно, если сеть не позволяет работать слишком агрессивным клиентам.
> Реалии отличаются от ваших представлений о них.Я закатил энное количество сетевых экспериментов, странных конфиг и проч - и остался недоволен тем как это работает в ряде ситуаций. Оно хтонически не способно реагировать на динамично меняющиеся условия. BBR лучший из того что есть, но даже он иногда неоправданно протупляет, и с этим congestion control развели классическое "хотели как лучше, а получилось как всегда".
> Роуминг - это из другой оперы, но если вы собираетесь перепосылать любой
> пакет который не аскнули за 100-500мс то вы положите сеть, аналогично
> если будете перезапрашивать так агресивно. И TCP довольно гибко аскает и
> запрашиват ретрансмиты, если что.Да, да, отсутствие соты по причине "юзер движется и пропал сигнал" это, конечно, перегруз сети. Или там всплеск шума в беспроводном канале, тоже "сеть положит".
В общем любую идею можно довести до маразма - и вот это вот именно туда и пришло. И в эру мобильных девайсов весь этот шит стал категорически иррелевантен. Так то если на эзернете разглагольствовать оно не проблема, но что-то никто не хочет за смартом или планшетом кабель таскать.
Честно говоря, абсолютно не интересно, чо там в бетах Фокса. Скорее такое надо оформлять в виде сводок "в очередной раз похерено вот то и вот это", но новостями это быть не может))
А что на счёт борьбы с цензурой в сети? Поможет сделать так, чтобы провайдеры меньше лезли в трафик пользователей?
Нет, не поможет... В Штатах тебя сдадут анбешникам твои же родственники.
> Нет, не поможет... В Штатах тебя сдадут анбешникам твои же родственники.Наркоман? Вопрос бы про цензуру в сети, про провайдеров которые лезут в трафик пользователей. Не было речи про что-то незаконное.
в Штатах никогда твой трафик не был секретом у провов. И не будет секретом.
> в Штатах никогда твой трафик не был секретом у провов. И не будет секретом.В штатах АНБ не имеет права копаться в трафике граждан. Во внешнем - сколько угодно :). Они на это очень жестко кислотой плевались когда хацкеры Exchange стали выносить. Видите ли внутренних хаксоров в результате совсем не видно.
Ну вот, осталось запилить HTTP/4 с обходом цензуры, и будет шикарно.
Надеешься обойти американскую цензуру?!
> Надеешься обойти американскую цензуру?!Кремлеботики набежали.
> Надеешься обойти американскую цензуру?!У них цензура довольно беззубая по сравнению с многими другими. Ну вон git.rip рипнули, так и то - только домен, а по айпишнику он живой и веселый, чего там обходить? Конечно за стебный домен обидно, но в таком виде его стебность даже повысилась и это сойдет за фичу. К тому же это подтолкнет развитие распределенных технологий и будет полезно вовсе не только американцам.
> цензура довольно беззубаяВсего-то лет 20 за внутренний терpopизм дают.
> Всего-то лет 20 за внутренний терpopизм дают.А вы попробуйте как шаман в капитолии потусить в кремле, для сравнения. С удовольствием засеку сколько дадут вам. Если выживите, конечно: кмк у амеров охрана сильно менее охотно в своих граждан стреляет.
> Ну вот, осталось запилить HTTP/4 с обходом цензуры, и будет шикарно.Так вон там в соседней новости есть прога - хоть и не с HTTP, но по части цензуры вещь.
> есть прогаКаждый смотритель котиков ставит себе кучу троянов, чтобы никто не узнал, что он смотрит котиков :)
Чтобы твои хозяева и прочие сильно умные не могли лезть в мой траф, например.
Это что - новый протокол управления передачей?
TCP - на свалку истории?
Теперь надо будет ваять туннели через http/3?
Всем сервисам теперь надо добавлять функциональность over HTTP/3 поди?
ssh over http/3
smtp over http/3
ну и всё остальное...
наоборот, ничего добавлять не надо, чтобы и /2, и /3 исдох на корню.
> наоборот, ничего добавлять не надо, чтобы и /2, и /3 исдох на корню.Еще беспроводные линки не забудь запретить, где TCP работает... никакуще.
ото udp будет работать какуще... знаем мы эти приколы с mtu и mss. стоит какому-нибудь горе-хостеру отрубить сервисные протоколы и начинаются "нипанятнаотчего" падающие пакеты. кто не в курсе, гуглите --clamp-mss-to-pmtu
> ото udp будет работать какуще... знаем мы эти приколы с mtu и mss.У udp самого по себе принципиально нет дичи с ростом таймаута перепосылок до 60 секунд как в бредокубиках, вытворяющих адский трэшак на беспроводном линке, особенно если юзер не дай боже перемещается и линк нестабильный.
> стоит какому-нибудь горе-хостеру отрубить сервисные протоколы и начинаются "нипанятнаотчего"
> падающие пакеты. кто не в курсе, гуглите --clamp-mss-to-pmtuЧСХ опять же TCP-проблемы в основном.
Согласен, только перфокарты голубиной почтой! Остальное от хипстеров!
> Согласен, только перфокарты голубиной почтой! Остальное от хипстеров!О, даешь IPFSOAC. IPFS Over Avian Carriers. Запрошенные файлы доставляет птичка с флешкой.
Для голубей нужно будет стороить голубятню, закупать ячмень и следить за их здоровьем.Хотя стоп, это всё равно удобнее, чем работать с истеричками из гугл и мозилла.
http + websocket +jsonrpc2 решают все эти проблемы и велосипедить ничего не надо
> http + websocket +jsonrpc2 решают все эти проблемы и велосипедить ничего не надоВебсокет при неидеальностях линка точно так же уйдет в конские 60-секундные таймауты как и HTTPшная конекция. Это вообще уровнем ниже TCP делает, ему похрен что там, он и IRC таким макаром тормознет на минуту, ему не жалко.
И как насчет трафика через socks proxy , теперь? Почти что нет соксов которые утп проксируют
HTTP/1 и 2 никто не отменяет.
> данные можно передавать сразу после отправки пакета установки соединенияА разве не нужно сначала согласовать TLS, а потом уже данные передавать?
Обычно вначале спрашивают поддерживает ли и какие алгоритмы, в http/2 можно сделать предположение что да поддерживает и сэкономить время и трафик.