Компания Mozilla сообщила о намерении начать поэтапное включение протоколов HTTP/3 и QUIC в выпуске Firefox 88, намеченном на 19 апреля (изначально, релиз ожидался 20 апреля, но, судя по графику, сдвинут на один день). Вначале поддержка HTTP/3 будет активирована лишь для небольшого процента пользователей и, если не возникнет непредвиденных проблем, будет доведена до всех к концу мая. В ночных сборках и бета-версиях HTTP/3 был включён по умолчанию в конце марта...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54979
Как там было в одном мультфильме (очень фапабельный, кстати): Circle ⭕ of life.
Выкинули вон FTP (устаревшие технологии), вот запилили HTTP/3 👍
> в одном мультфильме (очень фапабельный, кстати)как это можно делать на м/ф?.. 🤔
Разве не хентай?
да как бы не «My Little Pony»
>да как бы не «My Little Lion»Исправил.
Как говорится, каждый строчит как он хочет.
> как это можно делать на м/ф?.. 🤔Ну, как, белоснежку и 7 гномов скачай. Там тема раскрыта.
Спасибо за рассказ о ваших личных пристрастиях.
Обязательно потроллить всех сразу...
Посмотрел начало мультфильма и понял, что это не троллинг. Ну, может, только про FTP.
>Circle ⭕ of life.Фу бля. Думал, там нормальный рисованный хентай, а там мерзкое 3D
Вот поколение пошло! Оригинал 1994 года не видела, а лишь тот б-гомерский ремейк 2019 года!
Посоветовал "Тетрадь смерти" одному товарищу, сказал, что именно аниме, он жаловался что за г***о :) Наверное, понятно, что посмотрел он распоследнюю свежайшую USA версию, ведь чем новее, тем лучше, разве нет? :)
Выпилили устаревший FTP, вкрячили нестандартизированный HTTP/3: теперь заживём!
> Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.Интересно как? Кто в курсе дайте ссылку на алгоритмы. Если использовать просто дубляж данных, то общий трафик вырастет, а в протоколе выше заявлено уменьшение трафика по сравнению с TCP с классическим методом коррекции ошибок - запросом некоректного пакета.
Например вот так https://www.opennet.ru/docs/RUS/inet_book/2/28/corec_28.htmlЧто конкретно используется в HTTP/3 не знаю
Процент битых пакетов в сети - один на миллион. Несоизмеримо чаще ситуация, когда они просто не приходят.Поэтому добавлять поверх существующей чексумы еще и какие-нибудь коды грея, это совершенно лишняя трата трафика.
Согласен, это определенный оверхед, однако при всём при этом сервер может поправить битый пакет сам, не запрашивая его вновь, а какой там процент битых, 1/1е6 или 1/100, уж лучше скажут профессионалы с какой-либо статистикой на руках, не нам об этом судить.Напоминаю, что о конкретном алгоритме коррекции в HTTP/3 не знаю ничего, лучше почитать драфт стандарта
> Процент битых пакетов в сети - один на миллионУгу, теперь попробуй это по вафле с соседом качающим торент или мобильному линку на грани приема. А то что ты там можешь в датацентре напрямую в сервак патчкордом воткнуться - здорово, конечно, но патчкорд у тебя все же фуфельный.
Можно добавлять один пакет с ECC на 100 пакетов допустим.
Который позволит восстановить любой из 100 пакетов при потере.
Правда ресурс проца это пожрёт слегка.
Ищите по QUIC-FEC, но мне кажется это сих пор находится в зачаточном состоянии.
Да, это в планах. "Additionally, the protocol can be extended with forward error correction (FEC) to further improve performance when errors are expected, and this is seen as the next step in the protocol's evolution."
>а в протоколе выше заявлено уменьшение трафика по сравнению с TCP
>с классическим методом коррекции ошибок - запросом некоректного пакета.Только в каких-то синтетических тестах такое может произойти, из за мизерного трафика от самих запросов повторной отправки и заголовков IP пакета вместе с TCP, но только если коррекция ошибок настроена на 10% потерь и в канале как раз ровно 10% потерь. Такую коррекцию ошибок плохих каналов лучше делать на физическом уровне, а не на уровне приложения. Профит состоит только в том, что YouTube начнёт открываться быстрее на очень плохих каналах за счёт отказа от буферизации. Зачем это делать на уровне приложения? Ну Google не Cisco, где могут, там и внедряют свои хотелки.
Физический уровень видите ли затратно переделывать - никто не будет резко менять все wifi роутеры и соты только потому что вам кажется что это круто.Более того - вон то не поможет если какой-то дурной линк или роутер по пути 10% пакетов теряет. Так что на самом деле _адаптивный_ механизм, когда FEC запрашивается/усиливается если линк не ахти, и не делается/делается минимально если линк ОК.
А в чем проблема? TCP погано работает на беспроводных линках, как только условия приема отличаются от идеала, TCP выпадает в совершенно чебурашью скорость и невменяемый RTT.
А пытаться сделать идеальный линк из беспроводки дохлый номер. Ну вот едет юзер между сотами, прием то есть, то нет. Для TCP это "переруз канала", айда с ним бороться. Юзер уже пару сот проеахл с отличным линком, а крап из эпохи диалапа ...цатисекундный таймаут во имя богов congestion'а отсчитывает. Извиние, но так работать нельзя.
Если коррекция ошибок способна восстановить 10 пакетов из 100 - она способна восстановить и 9, и 8, и 7, и 1. Т.е. будет работать на любых каналах с <= 10/100 потерь (не усреднять до 10%).
Но ценой увеличения трафика на 10%, чудес не бывает. Повторная же передача увеличивает трафик исключительно по необходимости. Конечно избыточность можно регулировать вплоть до нуля, но при превышении процента потерь всё равно потребуются повторные передачи. Поэтому я и считаю, что проблему последних метров, нужно решать на последних метрах. К тому же всё ещё остаётся вопрос: как регулировать скорость канала, если нам неизвестна причина потерь? Ведь если все начнут реагировать на перегрузку канала, увеличением избыточности, то потерь будет становиться всё больше и больше и больше.
На последних метрах (если это не копеечные Ethernet свитчи, а какой-нибудь VDSL/GPON) - они как раз таки и решаются FEC/ECC.Увеличение избыточности может привести к дополнительным потерям, но в случае этих самых дополнительных потерь начинает срабатывать стандартная перепосылка, поэтому в этом плане ничего не теряется - некоторый уровень избыточности + перепосылка при фейлах такового.
Сейчас ситуация достаточно проста: пропускные способности каналов наращиваются. А вот с задержками не сделать банально ничего, и при переотправке задержки начинают играть существенную роль. FEC - это трейдофф между некоторым избыточным использованием полосы и собственно влиянием дополнительных задержек на переотправку, которых FEC позволяет избежать. Поэтому оно оправдано.
> На последних метрах (если это не копеечные Ethernet свитчи, а какой-нибудь VDSL/GPON)
> - они как раз таки и решаются FEC/ECC.А беспроводных линков в вашей картине мира вообще не существует? Там конечно FEC тоже бывает. Но таки в специфичном виде и никакой FEC канального уровня ничего не сделает с тем фактом что вы вообще выпали из зоны действия соты на 10 секунд. Он на такое тупо не расчитан. А TCP за это время решит что перегруз и начнет тупить как слизняк.
> Увеличение избыточности может привести к дополнительным потерям, но в случае этих самых
> дополнительных потерь начинает срабатывать стандартная перепосылка, поэтому в этом плане
> ничего не теряется - некоторый уровень избыточности + перепосылка при фейлах такового.Данные с FEC можно до известного предела не перепосылать совсем. DVB-T вон вообще наглухо односторонний. И он либо полностью декодабелен, либо вот вам черный экран.
Последнее кстати частично подбешивает юзерей, так что для 2-сторонних линков есть интересные эксперименты с graceful degradation подобного потока когда разрешение/FPS/качество кодирования снижают. Ессно это не для обычных применений а для видео юзают.
> Сейчас ситуация достаточно проста: пропускные способности каналов наращиваются. А вот
> с задержками не сделать банально ничего, и при переотправке задержки начинают
> играть существенную роль.Более того - то что TCP вытворяет при каком-нибудь выпадении соты на 10 секунд "потому что юзер едет в транспортте" не лезет ни в какие ворота. Чо-чо, максимальный таймаут 60 секунд, чтоли, чтобы не забить какой там T1 ссаный на котором при диалапе висел целый легион? А ща у хомячков даже спутниковые линки другие велечины имеют, Элонмаск подтвердит.
> FEC - это трейдофф между некоторым избыточным использованием полосы и собственно
> влиянием дополнительных задержек на переотправку, которых FEC позволяет избежать.
> Поэтому оно оправдано.В ряде случаев похоже таки да. Особенно когда девы TCP/IP демонстрируют полную творческую импотенцию, доказывая что экспериенс уровня диалапа на многомегабитном беспроводном линке так и задуман.
> А беспроводных линков в вашей картине мира вообще не существует?На "пользовательских" беспроводных линках единичные потери как раз частый случай, кстати.
Просто из-за шума в среде, с которым линейный ECC самого линка не справляется.
> Но ценой увеличения трафика на 10%, чудес не бывает.1) Обычно даже больше чем на 10%.
2) На хороших линках можно "понизить градус" или вообще не пользоваться этим.> Повторная же передача увеличивает трафик исключительно по необходимости.
С другой стороны, она дает penalty величиной в RTT канала сама по себе. В это время канал попросту бездействует. Просто потому что ремота еще не знает что пакеты вообще надо послать.
А тот миндфак который в TCP сделали к тому же восходит к временам диалапа и проч и умеет коллапсировать в совершенно идиотские величины задержек между повторными попытками.
И когда толпа гранд-комитет-нечто и ветеран-чтототам не может справиться с очевидными сетевыми проблемами, демонстрируя "designed by committee" в хучшем вид, корпы таки решат проблему и без их участия, сделав так чтобы для их юзерей все просто работало, а канали и оборудование не простаивали. Обратное ставит их на бабки.
> Конечно избыточность можно регулировать вплоть до нуля, но при превышении
> процента потерь всё равно потребуются повторные передачи.FEC можно задизайнить под почти произвольный процент потерь. Просто процент оверхеда будет невкусный, но это может работать даже на односторонних линках. DVB-T и космические линки так и делают. В DVB видите ли зомбоящики передавать не умеют, а в космических линках - ну вон до марса пинг в 1 сторону 2 часа, чтоли по поводу чего перезапрос это минимум 4 часа канала вхолостую.
Простой пример: если слать по 10 одинаковых пакетов, потери 20% не такая уж и проблема. В среднем будет выпадать лишь 2 из 10 и в целом будет декодабельно. С очень редкими выпадениями. Это правда неэффективно, есть сильно более удачные идеи.
Кстати можно гонять FEC поверх FEC (interleaving) так что невозможность декода приведет не к недекодабельности вон того пакета, а к тому что после de-interleave декодированы все пакеты но в них в каждом побит допустим 10-й байт. С чем прекрасно справится "внутренний" FEC. CD-ROM так делает, по поводу чего кой-как живет даже с царапинами и довольно серьезным BER чтения.
> Поэтому я и считаю, что проблему последних метров, нужно решать на последних метрах.
Удачи в этом направлении для радиолинков всех мастей и направлений. Представляете, юзеры ща не хотят в кафушке к эзернету стыковаться. И едучи в поезде мувик посмотреть тоже так то мало кто отказался бы.
> К тому же всё ещё остаётся вопрос: как регулировать скорость канала, если нам
> неизвестна причина потерь?У настоящего congestion есть сопутствующие атрибуты - например рост RTT. Это можно пытаться детектить. Но вообще-то если где-то есть congestion, вот к нему и надо применить вон ту логику - как то устранить эту проблему, а не пытаться с ним сюсюкаться на уровне протоколов факапя десятки других юзкейсов.
> Ведь если все начнут реагировать на перегрузку канала, увеличением избыточности,
> то потерь будет становиться всё больше и больше и больше.Возможно, это вообще сойдет за фичу - ленивые админы и жадные провы наконец снимутся с ручника. Или потеряют кастомеров на своих бельевых веревках, и проблема решится другим методом.
Странно, что никто до сих пор по поводу Rust не оскорбился... как же так? Где ваша бдительность?
Фрактала ждём.
А чего оскорбляться-то? Тут умные люди, и даже те, кому он чем-то не нравится (читай: не осилили) понимают, что альтернативы Rust пока в общем-то и нет.
Но ведь явно назрела необходимость в альтернативе, в которой краб, говорящий хелло, будет тянуть не 26 зависимостей, как в расте, а хотя бы 100. А то системным программистам, пришедшим из вебдева, неудобно, когда слишком мало зависимостей.\
\
_~^~^~_
\) / o o \ (/
'_ - _'
/ '-----' \
Да пофиг всем на раст.
И в новости про фф заходят только поржать.
Хз, сколько раз включал по приколу в FF всяческие QUIC, HTTP/2, HTTP/3, столько раз кончалось одним и тем же - часть сайтов подвисала, грузилась через раз, грузилась с глюками. Но тестовые сайты для проверки новых протоколов, те, да, грузились заметно быстрее.Хотя, казалось бы, если большинство сайтов не в курсе всех этих нововведений, то и проблем быть не должно - просто должно втихую через классический HTTP(S) работать.
Потому что сначала пробуется новое , не работает - откатывается на старое . На проверку уходит время . И так во всех новых технологиях . Потому лучше не спешить , пока не устаканится .
Ох уж это поколение смузи...Сначала надо подумать(!), проработать архитектуру, посчитать (не прикинуть, а именно что посчитать!) как твоя задумка отразится на существующем порядке вещей. И только после этого писать и пытаться внедрять.
А не "Давайте запилим. Плохо работает? Вот вам заплатка. Все еще плохо? Вот вам еще одна.", и так годами.
Так "в теории" и на сайтах поддерживающих - всё в шоколаде . Только в реальности : пробуем соединиться по HTTP3 , сайт не поддерживает > откатываемся на HTTP2 , пробуем соединится , сайт так же не поддерживает > откатываемся в "каменный век" . И на каждом этапе время ...
Мне вот даже стало интересно. А нельзя ли было изменить URL на http3s://example.com/ ? Что за горе-инженеры это создают? WebSocket вот тоже зачем то пытались завернуть в обычный http, понятный брандмауэрам древним как говно мамонта. И которые ничего кроме http через себя не пропускают. В итоге сказали ssl-only идете на ***.
>> http, понятный брандмауэрамИменно поэтому. А они ещё и аппаратные бывают.
> http3s://example.com/ ? Что за горе-инженеры это создают? WebSocket вот тоже зачем
> то пытались завернуть в обычный http, понятный брандмауэрам древним как говно мамонта.Ну, как, протокол который будет застревать на всех фаерах и натах использовать массово не особо то получится - юзеры админов жалобами на неработу этой штуки задолбают и затея накроется медным тазом.
> И которые ничего кроме http через себя не пропускают. В итоге сказали ssl-only идете на ***.
Кто и где это сказал в ws? Вы его с http/2 не путаете случайно? А то это разные вещи.
> Сначала надо подумать(!), проработать архитектуру, посчитать (не прикинуть, а именно что посчитать!) как твоя задумка отразится на существующем порядке вещей. И только после этого писать и пытаться внедрять.На этапе реализации стандарта QUIC / HTTP/3 уже подумали и посчитали. Только реальные ходовые испытания показывают, есть ли от всех этих размышлизмов толк или нет. Ещё раз -- только реальная эксплуатация показывает, идея работает или нет. Все остальные расчёты, размышления -- лирика. А то, что fallback работает с ошибками -- это проблема не HTTP/3, а багов в реализации fallback, и они исправляются за конечное время.
Как будто вы ни одного проекта не видели, утонувшего в бесконечных совещаниях и согласованиях.
> в реализации fallback, и они исправляются за конечное время.Исправьте хоть что-нибудь за конечное время в сетевом стеке виндов.
> Как будто вы ни одного проекта не видели, утонувшего в бесконечных совещаниях и согласованиях.
Это уже явно не утонет, имплементеров больно много. А так то .n draft вообще внаглую продавали задолго до ратификации, настолько лучше .g было. Ну вот и пришлось как-то так, да, ратифицировать то что имеется, с минимуом поправок.
> Сначала надо подумать(!), проработать архитектуру, посчитать (не прикинуть, а именно что
> посчитать!) как твоя задумка отразится на существующем порядке вещей. И только
> после этого писать и пытаться внедрять.Любой инженер скажет тебе что для любой достаточно большой системы этот мир достаточно сложный и плохо моделируемый для того чтобы твои расчеты в самом лучшм случае оказались какой-то очень приближенной экстраполяцией реального состояния дел.
По поводу чего вполне валидно прогнать в 20 раз более простые прикидки - и в результате ничерта не потерять, поскольку проблемы все-равно вылезут и так и так, что-то придется твикать и костылить чисто эмпирически, по принципу "так лучше работало в реальном мире".
> А не "Давайте запилим. Плохо работает? Вот вам заплатка. Все еще плохо?
> Вот вам еще одна.", и так годами.Ну, если вы сможете богов, способных полностью просчитать состояние вселенной до последнего атома... (то у вас будет много других проблем).
я тестил на сайте заказчика, включение HTTP/2 замедляло загрузку на несколько процентовразницы почти нет, но это был даже не прирост
Ну вот кстати факт.
HTTP/2 убирает затраты на дополнительные соединения, но по сравнению с HTTPS увеличивает затраты на обработку протокола.
И не всегда это выходит в пользу HTTP/2.
Если линк длинный, а контент переизмельчён - да, раундтрип играет существенную роль.
Если линк короткий, а контент собран в большие агрегированные блоки - внутренности протокола начинают перевешивать.
> Ну вот кстати факт.
> HTTP/2 убирает затраты на дополнительные соединения, но по сравнению с HTTPS увеличивает
> затраты на обработку протокола.
> И не всегда это выходит в пользу HTTP/2.
> Если линк длинный, а контент переизмельчён - да, раундтрип играет существенную роль.
> Если линк короткий, а контент собран в большие агрегированные блоки - внутренности
> протокола начинают перевешивать.контент собран, в приложении все активно бандлится, js, css и т.д., львииный объем контента выбирается в первые 4 запроса
пинг до сервера ~40 ms, канал 100 mbit
> контент собран, в приложении все активно бандлится, js, css и т.д., львииный объем контента выбирается в первые 4 запросаА вот делали бы как нынешние конфетковерстальщики - 100500 css, 100500 ajax'ов только для отображения, и 10005000 js'ов - вот тут бы HTTP/2 и засиял радужными оттенками.
> А вот делали бы как нынешние конфетковерстальщики - 100500 css, 100500 ajax'ов
> только для отображения, и 10005000 js'ов - вот тут бы HTTP/2
> и засиял радужными оттенками.ЧСХ и засияет. Как и HTTP/3.
http/2 работает стабильно.
Ну положим HTTP2 уже давно не тестовый, и внедряется уже весьма широко.
> Ну положим HTTP2 уже давно не тестовый, и внедряется уже весьма широко.Так это не сейчас, а лет сколько-то назад, когда вышла такая же новость "в состав FF включена поддержка HTTP/2, для включения дерните такую-то переменную". И на тестовом сайте оно, да, отлично работало. Но вот почему-то на некоторых реальных сайтах, причём весьма популярных, приводило к множеству багов.
А сейчас он уже много лет как включен у всех по дефолту - и просто работает. А о том что это HTTP/2 был вы вообще узнаете только открыв дебагтулсы браузеров...Его уже чисто статистиески более 50% сайтов умеют. Поэтому с хорошей вероятностью вы ходите на сайты с HTTP/2 и не паритесь даже.
Очень даже может быть :) На самом деле мой пост был вовсе не о том, что новые протоколы - это плохо, а о том, что лучше не бежать впереди паровоза - огребёте почти наверняка.Вот когда сами мозиловцы поддержку протокола включают по умолчанию, вот тогда и пользоваться можно без проблем...
>> HTTP/3 определяет использование протокола QUIC в качестве транспорта для HTTP/2.Что?
А что? Летим вперёд со всё большей и большей скоростью :)
Летим. Жопой вперёд.
Это же гаргулья из первых Heroes of Might and Magic! Там еще и ручка^W хвост есть для пущего антуражу.
Хттп1.1 всем хватит.Ишь чо удумоле еще на 2 не перешел никто а уже 3 добавляют.
Ютуб перешёл, например.
На самом деле много кто перешел. Позырьте нетконсольку в процессе браузинга. А хренли - кому быстро грузящийся сайт не надо?
Необязательно смотреть в консоль. Пока Proton еще не включили можно использовать аддон "HTTP/2 Indicator", он в панели адреса показывает если HTTP2 задействован на текущем сайте и вот оказывается что применяют его уже весьма широко. Весь крупняк так точно.
Я не знаю что там за протоны и электроны у вебмакак сейчас, но по вон той метрике HTTP/2 уже более чем на 50% сайтов есть, а мне и под сниффером/нетконсольками нормально без всякого хайпошита.
2 нужен только сайтам с огромной кучей очень мелких файлов из за которых клиенты большую часть времени тратят на ожидание, а не приём данных. 3 нужен только любителям смотреть ютюб через чужой Wi-Fi 2.4 ГГц с одной долькой сигнала. Ах да, ещё он героически решает проблему долгого времени создания ssl соединения созданную самим гуглом. Большинству сайтов за глаза хватило бы цифровых подписей важных файлов. Ключи можно было получить параллельно с получением контента, а не до первого запроса.
> ГГц с одной долькой сигнала. Ах да, ещё он героически решает
> проблему долгого времени создания ssl соединения созданную самим гуглом.А также двум легионам всяких мобильных (неу)дачников и прочих желающих пользоваться вебом даже в транспорте каком, когда соты просто отваливаются раз в цать секунд. Ну да, подумаешь, опеннетадмины почти всех своих юзерей как раз и забыли. Потому что локалхост админят.
>когда соты просто отваливаются раз в цать секундВ этом случае http3 не поможет. Он ничего не сможет сделать, если Вы потеряли 90-100% пакетов из группы идущих подряд пакетов. Если Вы на несколько секунд потеряли связь с башней, то будете перезапрашивать все данные вместе с данными восстановления. Он защищает только от стабильных потерь из за повреждения некоторых кадров.
Для того, чтобы идеально пересекать GSM базы, нужно чтобы в каждой точке мира было "видно" 1.5 башни. На прикладном уровне эту проблему не решить.
Еще как поможет - вместо сношений с идиотией встроенных в ОС congestion control'ей можно просто взять и запилить свое, как надо для того чтобы нормально работало. Не доказывая толпе мамонтов чуть менее чем нихрена и не пытаясь убедить майкрософт втащить это в свой кернел.> Если Вы на несколько секунд потеряли связь с башней, то будете перезапрашивать
> все данные вместе с данными восстановления.Тупорылый TCP посчитает это за перегруз сети, уйдет в ломовые таймауты чуть не минуту и хотя мимо вас уже просвистело три соты, он там цать секунд таймаута отсчитывает, ему похрен. И все эти цать секунд трафика нет. Хоть те соты и налили бы по дохрена магеабайт каждая при появлении в видимости.
> На прикладном уровне эту проблему не решить.
На прикладном уровне можно
1) Угрохать идиотские таймауты из эры диалапа к архидьяволу, никого не спрашивая.
2) Пульнув FEC можно вообще не заморачиваться перезапросом пакетов, если он выдюжил. Актуально для не очень надежных или high-RTT линков, где перезапрос, вообще, имеет тенденцию к коллапсу в дурацкую спираль и проигрыш теорвера, порой обваливаясь в хлам по весьма мелочным вещам.
> когда соты просто отваливаются раз в цать секундВ этом случае должны спасать кеши, в которые предварительно накачиваются следующие цать минут видоса, который зырит юзер, перемещаясь меджу сотами очень быстро. Пока переключается на новую соту, минуты видоса по время провала он связи вытаскивает из кеша своего браузера.
> В этом случае должны спасать кеши, в которые предварительно
> накачиваются следующие цать минут видоса,1) С лагами TCP по цать секунд он иногда проигрывает теорвер настолько, что при неудачном совпадении времянок его таймаутов с пролетом сот мимо вас вы по сути вообще ничерта не скачаете. Попробуйте попользоваться интернетом в метро/поезде/авто например, особенно чуть в стороне от крупных городов.
2) Лить вам цать минут видео никто не хочет. С вероятностью 50/50 вы может быть его вообще смотреть не будете и лить вам столько - напрасная трата траффика. Это стоит видеохостерам бабок и даже ютуб морально готов вам лить 2 минуты максимум. Так что вы либо разбираетесь за 2 минуты, либо сорян. И да, поезд или авто за это время проезжает несколько километров так что если там вообще люди в этой территори живут, условия могут радикально улучшиться.> который зырит юзер, перемещаясь меджу сотами очень быстро.
TCP видите ли плохо реагирует на ситуацию когда он retry пробовал а тот не прошел потому что соты сейчас нет. Он коллапсирует в редкие потуги возобновить конект, при этом совсем не факт что в тот момент линк будет. И в результате можно вообще получить соединение по которому ничерта не качается по сути, хотя периодически под боком пролетают весьма приличные БСки.
> Пока переключается на новую соту, минуты видоса по время провала он связи
> вытаскивает из кеша своего браузера.А заодно там вон TCP будет 60 секунд таймаута считать, чисто для лулзов. За это время сота как раз просвистит мимо вас и когда тот попробует retry - может опять зафэйлиться. Поэтому вполне реально получить TCP конекцию которая вообще данные не качает, хотя соты вот, пролетают между вас. Ну, я проверял в метро/поездах/авто. И работало "не очень".
> еще на 2 не перешел никто
> network.http.http3.enabledХорошая опция, обязательно её выключу.
я вообще фокса поставлю в бан на оюнову. иногда фтпшки использую. можно конечно из консоли по старинке, но иногда в лом.
Враньё про производительность.
Какой то мир вранья сплошной: потепление, кетайская чумка и вот этот udp недостандарт.Откуда тут взятся производительности, когда это целиком херит sendfile() на стороне сервера!?
Нынче вон TLS запихнули в ядро, только чтобы sendfile() ускорить.
Сплошные дополнительные выбросы углерода и тепловая смерть вселенной! :)
Активировал. Ютуб - пока особо не заметил разницы. А вот FB, вроде по шустрее стал грузить.
Там сейчас весь код выглядит так:Если (http/3) То <оптимизированный_код> Иначе <лишь_бы_ползающий_код>
Объясните в чём прикол однопоточности http2/3. Разве чем больше потоков (как в http1.1) тем не быстрее грузится контент с сайта?
Отнопоточные они только с виду. Внутри прячутся собственные потоки с более низким временем создания, с управляемым приоритетом и возможностью протолкнуть не запрошенные данные. Если разработчик заморочится, то сайт будет загружать компоненты в установленном порядке, а не как TCP решит. И всё это без потери скорости. Например первыми будут грузиться картинки, что должны быть отображена прямо сейчас, а нижние пойдут следом. Но это только если разработчик заморочится иначе может стать даже хуже чем было, ведь эти виртуальные потоки создают оверхед.
Сами же TCP потоки можно разгонять до бесконечности, пока пропускная способность есть.
> и возможностью протолкнуть не запрошенные данныеДак гугл недавно как раз рассказывал, что это оказалось тормозом и забитием канала невостребованным мусором.
> Например первыми будут грузиться картинки, что должны быть отображена прямо сейчас, а нижние пойдут следомНормальные браузеры уже давно так делают, чем дальше картинка от амбразуры просмотра - тем ниже приоритет загрузки.
P.S. Тем более, что браузеры запоминают ещё и позицию скрола на странице, и когда открываешь сайт сразу на середине, этот "server-side-order" сделает подлянку, подсовывая не те картинки, которые сейчас нужны.
> Нормальные браузеры уже давно так делают, чем дальше картинка от амбразуры просмотра
> - тем ниже приоритет загрузки.Браузеры это делают через приостановку приёма данных через сокет, но во первых буфер сокета всё равно будет заполнятся пока не забьётся, а во вторых нужно очень хорошо высчитать тайминг, чтобы сервер продолжил отправлять файлы в тот самый момент, когда закончил передачу приоритетных. Учитывая общую асимметрию маршрутов в интернете это всё сизифов труд. На сервере это сделать проще, но скриптам придётся отправлять серверу информацию о том, что для него приоритетнее прямо сейчас.
LiteSpeed тоже поддерживает http3 но только в платной версии.
> LiteSpeed тоже поддерживает http3 но только в платной версии.С учетом наличия толпы халявных реализаций творческих им узбеков.
Ну и как этот хттп3 реально применять не только гуглам да фейсбукам, но ещё и на практике?Вот надо, например, с веб-сервера передать в браузер страницу, которая содержит только 5 тегов <IMG>.
Ну великий хттп3 дарит возможность отправить все эти 5 картинок "одновременно" пятью параллельными потоками.
Чё надо в Апаче подкрутить, чтобы он именно так все эти "100500+" картинок (да и всего остального) одновременно погнал?
Ну и как это работает? 🤔
Похоже, что вообще никак - в about:networking все соединения HTTP/2, кроме любимого опеннетика