| 1.5, Аноним (5), 08:59, 17/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.
Интересно как? Кто в курсе дайте ссылку на алгоритмы. Если использовать просто дубляж данных, то общий трафик вырастет, а в протоколе выше заявлено уменьшение трафика по сравнению с TCP с классическим методом коррекции ошибок - запросом некоректного пакета.
| | |
| |
| |
| 3.29, Урри (ok), 11:23, 17/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Процент битых пакетов в сети - один на миллион. Несоизмеримо чаще ситуация, когда они просто не приходят.
Поэтому добавлять поверх существующей чексумы еще и какие-нибудь коды грея, это совершенно лишняя трата трафика.
| | |
| |
| 4.34, Аноним (9), 12:23, 17/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
 Согласен, это определенный оверхед, однако при всём при этом сервер может поправить битый пакет сам, не запрашивая его вновь, а какой там процент битых, 1/1е6 или 1/100, уж лучше скажут профессионалы с какой-либо статистикой на руках, не нам об этом судить.
Напоминаю, что о конкретном алгоритме коррекции в HTTP/3 не знаю ничего, лучше почитать драфт стандарта
| | |
| 4.52, Аноним (-), 23:47, 17/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Процент битых пакетов в сети - один на миллион
Угу, теперь попробуй это по вафле с соседом качающим торент или мобильному линку на грани приема. А то что ты там можешь в датацентре напрямую в сервак патчкордом воткнуться - здорово, конечно, но патчкорд у тебя все же фуфельный.
| | |
| 4.77, Онаним (?), 20:18, 19/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Можно добавлять один пакет с ECC на 100 пакетов допустим.
Который позволит восстановить любой из 100 пакетов при потере.
Правда ресурс проца это пожрёт слегка.
| | |
|
|
| 2.23, Аноним (23), 10:20, 17/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ищите по QUIC-FEC, но мне кажется это сих пор находится в зачаточном состоянии.
| | |
| |
| 3.24, Аноним (23), 10:29, 17/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да, это в планах. "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."
| | |
|
| 2.43, Аноним (43), 18:48, 17/04/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
 >а в протоколе выше заявлено уменьшение трафика по сравнению с TCP
>с классическим методом коррекции ошибок - запросом некоректного пакета.
Только в каких-то синтетических тестах такое может произойти, из за мизерного трафика от самих запросов повторной отправки и заголовков IP пакета вместе с TCP, но только если коррекция ошибок настроена на 10% потерь и в канале как раз ровно 10% потерь. Такую коррекцию ошибок плохих каналов лучше делать на физическом уровне, а не на уровне приложения. Профит состоит только в том, что YouTube начнёт открываться быстрее на очень плохих каналах за счёт отказа от буферизации. Зачем это делать на уровне приложения? Ну Google не Cisco, где могут, там и внедряют свои хотелки.
| | |
| |
| 3.53, Аноним (-), 23:52, 17/04/2021 [^] [^^] [^^^] [ответить] | +/– | Физический уровень видите ли затратно переделывать - никто не будет резко менять... большой текст свёрнут, показать | | |
| 3.78, Онаним (?), 20:20, 19/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Если коррекция ошибок способна восстановить 10 пакетов из 100 - она способна восстановить и 9, и 8, и 7, и 1. Т.е. будет работать на любых каналах с <= 10/100 потерь (не усреднять до 10%).
| | |
| |
| 4.86, Аноним (43), 04:21, 20/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Но ценой увеличения трафика на 10%, чудес не бывает. Повторная же передача увеличивает трафик исключительно по необходимости. Конечно избыточность можно регулировать вплоть до нуля, но при превышении процента потерь всё равно потребуются повторные передачи. Поэтому я и считаю, что проблему последних метров, нужно решать на последних метрах. К тому же всё ещё остаётся вопрос: как регулировать скорость канала, если нам неизвестна причина потерь? Ведь если все начнут реагировать на перегрузку канала, увеличением избыточности, то потерь будет становиться всё больше и больше и больше.
| | |
| |
| 5.87, Онаним (?), 09:46, 20/04/2021 [^] [^^] [^^^] [ответить]
| +/– | |
На последних метрах (если это не копеечные Ethernet свитчи, а какой-нибудь VDSL/GPON) - они как раз таки и решаются FEC/ECC.
Увеличение избыточности может привести к дополнительным потерям, но в случае этих самых дополнительных потерь начинает срабатывать стандартная перепосылка, поэтому в этом плане ничего не теряется - некоторый уровень избыточности + перепосылка при фейлах такового.
Сейчас ситуация достаточно проста: пропускные способности каналов наращиваются. А вот с задержками не сделать банально ничего, и при переотправке задержки начинают играть существенную роль. FEC - это трейдофф между некоторым избыточным использованием полосы и собственно влиянием дополнительных задержек на переотправку, которых FEC позволяет избежать. Поэтому оно оправдано.
| | |
| |
| 6.94, Аноним (-), 05:40, 21/04/2021 [^] [^^] [^^^] [ответить] | +/– | А беспроводных линков в вашей картине мира вообще не существует Там конечно FEC... большой текст свёрнут, показать | | |
| |
| 7.103, Онаним (?), 09:56, 21/04/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> А беспроводных линков в вашей картине мира вообще не существует?
На "пользовательских" беспроводных линках единичные потери как раз частый случай, кстати.
Просто из-за шума в среде, с которым линейный ECC самого линка не справляется.
| | |
|
|
| 5.93, Аноним (-), 05:33, 21/04/2021 [^] [^^] [^^^] [ответить] | +/– | 1 Обычно даже больше чем на 10 2 На хороших линках можно понизить градус и... большой текст свёрнут, показать | | |
|
|
|
|
| 1.10, Аноним (10), 09:29, 17/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Странно, что никто до сих пор по поводу Rust не оскорбился... как же так? Где ваша бдительность?
| | |
| |
| 2.35, Аноним (35), 13:27, 17/04/2021 [^] [^^] [^^^] [ответить]
| –2 +/– |
А чего оскорбляться-то? Тут умные люди, и даже те, кому он чем-то не нравится (читай: не осилили) понимают, что альтернативы Rust пока в общем-то и нет.
| | |
| |
| 3.66, Ыноним (?), 22:30, 18/04/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Но ведь явно назрела необходимость в альтернативе, в которой краб, говорящий хелло, будет тянуть не 26 зависимостей, как в расте, а хотя бы 100. А то системным программистам, пришедшим из вебдева, неудобно, когда слишком мало зависимостей.
\
\
_~^~^~_
\) / o o \ (/
'_ - _'
/ '-----' \
| | |
|
| 2.45, Аноним (45), 19:11, 17/04/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да пофиг всем на раст.
И в новости про фф заходят только поржать.
| | |
|
| 1.17, dalco (ok), 09:42, 17/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Хз, сколько раз включал по приколу в FF всяческие QUIC, HTTP/2, HTTP/3, столько раз кончалось одним и тем же - часть сайтов подвисала, грузилась через раз, грузилась с глюками. Но тестовые сайты для проверки новых протоколов, те, да, грузились заметно быстрее.
Хотя, казалось бы, если большинство сайтов не в курсе всех этих нововведений, то и проблем быть не должно - просто должно втихую через классический HTTP(S) работать.
| | |
| |
| 2.19, Total Anonimus (?), 09:49, 17/04/2021 [^] [^^] [^^^] [ответить]
| –2 +/– |
Потому что сначала пробуется новое , не работает - откатывается на старое . На проверку уходит время . И так во всех новых технологиях . Потому лучше не спешить , пока не устаканится .
| | |
| |
| 3.30, Урри (ok), 11:26, 17/04/2021 [^] [^^] [^^^] [ответить]
| –4 +/– | |
Ох уж это поколение смузи...
Сначала надо подумать(!), проработать архитектуру, посчитать (не прикинуть, а именно что посчитать!) как твоя задумка отразится на существующем порядке вещей. И только после этого писать и пытаться внедрять.
А не "Давайте запилим. Плохо работает? Вот вам заплатка. Все еще плохо? Вот вам еще одна.", и так годами.
| | |
| |
| 4.33, Total Anonimus (?), 12:03, 17/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
Так "в теории" и на сайтах поддерживающих - всё в шоколаде . Только в реальности : пробуем соединиться по HTTP3 , сайт не поддерживает > откатываемся на HTTP2 , пробуем соединится , сайт так же не поддерживает > откатываемся в "каменный век" . И на каждом этапе время ...
| | |
| |
| 5.44, Аноним (43), 19:07, 17/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Мне вот даже стало интересно. А нельзя ли было изменить URL на http3s://example.com/ ? Что за горе-инженеры это создают? WebSocket вот тоже зачем то пытались завернуть в обычный http, понятный брандмауэрам древним как говно мамонта. И которые ничего кроме http через себя не пропускают. В итоге сказали ssl-only идете на ***.
| | |
| |
| 6.46, Аноним (45), 19:14, 17/04/2021 [^] [^^] [^^^] [ответить]
| +/– | |
>> http, понятный брандмауэрам
Именно поэтому. А они ещё и аппаратные бывают.
| | |
| 6.54, Аноним (-), 23:56, 17/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
> http3s://example.com/ ? Что за горе-инженеры это создают? WebSocket вот тоже зачем
> то пытались завернуть в обычный http, понятный брандмауэрам древним как говно мамонта.
Ну, как, протокол который будет застревать на всех фаерах и натах использовать массово не особо то получится - юзеры админов жалобами на неработу этой штуки задолбают и затея накроется медным тазом.
> И которые ничего кроме http через себя не пропускают. В итоге сказали ssl-only идете на ***.
Кто и где это сказал в ws? Вы его с http/2 не путаете случайно? А то это разные вещи.
| | |
|
|
| 4.40, kai3341 (ok), 17:07, 17/04/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Сначала надо подумать(!), проработать архитектуру, посчитать (не прикинуть, а именно что посчитать!) как твоя задумка отразится на существующем порядке вещей. И только после этого писать и пытаться внедрять.
На этапе реализации стандарта QUIC / HTTP/3 уже подумали и посчитали. Только реальные ходовые испытания показывают, есть ли от всех этих размышлизмов толк или нет. Ещё раз -- только реальная эксплуатация показывает, идея работает или нет. Все остальные расчёты, размышления -- лирика. А то, что fallback работает с ошибками -- это проблема не HTTP/3, а багов в реализации fallback, и они исправляются за конечное время.
Как будто вы ни одного проекта не видели, утонувшего в бесконечных совещаниях и согласованиях.
| | |
| |
| 5.55, Аноним (-), 23:58, 17/04/2021 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> в реализации fallback, и они исправляются за конечное время.
Исправьте хоть что-нибудь за конечное время в сетевом стеке виндов.
> Как будто вы ни одного проекта не видели, утонувшего в бесконечных совещаниях и согласованиях.
Это уже явно не утонет, имплементеров больно много. А так то .n draft вообще внаглую продавали задолго до ратификации, настолько лучше .g было. Ну вот и пришлось как-то так, да, ратифицировать то что имеется, с минимуом поправок.
| | |
|
| 4.95, Аноним (-), 05:47, 21/04/2021 [^] [^^] [^^^] [ответить] | +/– | Любой инженер скажет тебе что для любой достаточно большой системы этот мир дост... большой текст свёрнут, показать | | |
|
|
| 2.28, kissmyass (?), 11:14, 17/04/2021 [^] [^^] [^^^] [ответить]
| –3 +/– | |
я тестил на сайте заказчика, включение HTTP/2 замедляло загрузку на несколько процентов
разницы почти нет, но это был даже не прирост
| | |
| |
| 3.79, Онаним (?), 20:24, 19/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Ну вот кстати факт.
HTTP/2 убирает затраты на дополнительные соединения, но по сравнению с HTTPS увеличивает затраты на обработку протокола.
И не всегда это выходит в пользу HTTP/2.
Если линк длинный, а контент переизмельчён - да, раундтрип играет существенную роль.
Если линк короткий, а контент собран в большие агрегированные блоки - внутренности протокола начинают перевешивать.
| | |
| |
| 4.81, kissmyass (?), 21:41, 19/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
> Ну вот кстати факт.
> HTTP/2 убирает затраты на дополнительные соединения, но по сравнению с HTTPS увеличивает
> затраты на обработку протокола.
> И не всегда это выходит в пользу HTTP/2.
> Если линк длинный, а контент переизмельчён - да, раундтрип играет существенную роль.
> Если линк короткий, а контент собран в большие агрегированные блоки - внутренности
> протокола начинают перевешивать.
контент собран, в приложении все активно бандлится, js, css и т.д., львииный объем контента выбирается в первые 4 запроса
пинг до сервера ~40 ms, канал 100 mbit
| | |
| |
| 5.85, Онаним (?), 00:21, 20/04/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> контент собран, в приложении все активно бандлится, js, css и т.д., львииный объем контента выбирается в первые 4 запроса
А вот делали бы как нынешние конфетковерстальщики - 100500 css, 100500 ajax'ов только для отображения, и 10005000 js'ов - вот тут бы HTTP/2 и засиял радужными оттенками.
| | |
| |
| 6.96, Аноним (-), 05:48, 21/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
> А вот делали бы как нынешние конфетковерстальщики - 100500 css, 100500 ajax'ов
> только для отображения, и 10005000 js'ов - вот тут бы HTTP/2
> и засиял радужными оттенками.
ЧСХ и засияет. Как и HTTP/3.
| | |
|
|
|
|
| 2.90, Kuromi (ok), 23:01, 20/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
 Ну положим HTTP2 уже давно не тестовый, и внедряется уже весьма широко.
| | |
| |
| 3.92, dalco (ok), 04:05, 21/04/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну положим HTTP2 уже давно не тестовый, и внедряется уже весьма широко.
Так это не сейчас, а лет сколько-то назад, когда вышла такая же новость "в состав FF включена поддержка HTTP/2, для включения дерните такую-то переменную". И на тестовом сайте оно, да, отлично работало. Но вот почему-то на некоторых реальных сайтах, причём весьма популярных, приводило к множеству багов.
| | |
| |
| 4.97, Аноним (-), 05:50, 21/04/2021 [^] [^^] [^^^] [ответить]
| +/– | |
А сейчас он уже много лет как включен у всех по дефолту - и просто работает. А о том что это HTTP/2 был вы вообще узнаете только открыв дебагтулсы браузеров...
Его уже чисто статистиески более 50% сайтов умеют. Поэтому с хорошей вероятностью вы ходите на сайты с HTTP/2 и не паритесь даже.
| | |
| |
| 5.99, dalco (ok), 05:59, 21/04/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Очень даже может быть :) На самом деле мой пост был вовсе не о том, что новые протоколы - это плохо, а о том, что лучше не бежать впереди паровоза - огребёте почти наверняка.
Вот когда сами мозиловцы поддержку протокола включают по умолчанию, вот тогда и пользоваться можно без проблем...
| | |
|
|
|
|
| 1.25, Аноним (25), 10:43, 17/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>> HTTP/3 определяет использование протокола QUIC в качестве транспорта для HTTP/2.
Что?
| | |
| |
| |
| |
| 4.67, Аноним (-), 00:59, 19/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это же гаргулья из первых Heroes of Might and Magic! Там еще и ручка^W хвост есть для пущего антуражу.
| | |
|
|
|
| 1.32, msgod (ok), 11:33, 17/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Хттп1.1 всем хватит.
Ишь чо удумоле еще на 2 не перешел никто а уже 3 добавляют.
| | |
| |
| |
| 3.68, Аноним (-), 01:00, 19/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
На самом деле много кто перешел. Позырьте нетконсольку в процессе браузинга. А хренли - кому быстро грузящийся сайт не надо?
| | |
| |
| 4.91, Kuromi (ok), 23:04, 20/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Необязательно смотреть в консоль. Пока Proton еще не включили можно использовать аддон "HTTP/2 Indicator", он в панели адреса показывает если HTTP2 задействован на текущем сайте и вот оказывается что применяют его уже весьма широко. Весь крупняк так точно.
| | |
| |
| 5.98, Аноним (-), 05:52, 21/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Я не знаю что там за протоны и электроны у вебмакак сейчас, но по вон той метрике HTTP/2 уже более чем на 50% сайтов есть, а мне и под сниффером/нетконсольками нормально без всякого хайпошита.
| | |
|
|
|
| 2.47, Аноним (43), 19:32, 17/04/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
2 нужен только сайтам с огромной кучей очень мелких файлов из за которых клиенты большую часть времени тратят на ожидание, а не приём данных. 3 нужен только любителям смотреть ютюб через чужой Wi-Fi 2.4 ГГц с одной долькой сигнала. Ах да, ещё он героически решает проблему долгого времени создания ssl соединения созданную самим гуглом. Большинству сайтов за глаза хватило бы цифровых подписей важных файлов. Ключи можно было получить параллельно с получением контента, а не до первого запроса.
| | |
| |
| 3.56, Аноним (-), 00:04, 18/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
> ГГц с одной долькой сигнала. Ах да, ещё он героически решает
> проблему долгого времени создания ssl соединения созданную самим гуглом.
А также двум легионам всяких мобильных (неу)дачников и прочих желающих пользоваться вебом даже в транспорте каком, когда соты просто отваливаются раз в цать секунд. Ну да, подумаешь, опеннетадмины почти всех своих юзерей как раз и забыли. Потому что локалхост админят.
| | |
| |
| 4.57, Аноним (43), 04:04, 18/04/2021 [^] [^^] [^^^] [ответить]
| +/– | |
>когда соты просто отваливаются раз в цать секунд
В этом случае http3 не поможет. Он ничего не сможет сделать, если Вы потеряли 90-100% пакетов из группы идущих подряд пакетов. Если Вы на несколько секунд потеряли связь с башней, то будете перезапрашивать все данные вместе с данными восстановления. Он защищает только от стабильных потерь из за повреждения некоторых кадров.
Для того, чтобы идеально пересекать GSM базы, нужно чтобы в каждой точке мира было "видно" 1.5 башни. На прикладном уровне эту проблему не решить.
| | |
| |
| 5.69, Аноним (-), 01:07, 19/04/2021 [^] [^^] [^^^] [ответить] | +/– | Еще как поможет - вместо сношений с идиотией встроенных в ОС congestion control ... большой текст свёрнут, показать | | |
|
| 4.73, rvs2016 (ok), 11:13, 19/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
 > когда соты просто отваливаются раз в цать секунд
В этом случае должны спасать кеши, в которые предварительно накачиваются следующие цать минут видоса, который зырит юзер, перемещаясь меджу сотами очень быстро. Пока переключается на новую соту, минуты видоса по время провала он связи вытаскивает из кеша своего браузера.
| | |
| |
| 5.100, Аноним (-), 06:05, 21/04/2021 [^] [^^] [^^^] [ответить] | +/– | 1 С лагами TCP по цать секунд он иногда проигрывает теорвер настолько, что при ... большой текст свёрнут, показать | | |
|
|
|
|
| |
| 2.65, анонимуслинус (?), 22:18, 18/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
я вообще фокса поставлю в бан на оюнову. иногда фтпшки использую. можно конечно из консоли по старинке, но иногда в лом.
| | |
|
| 1.39, Ivan_83 (ok), 17:00, 17/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
 Враньё про производительность.
Какой то мир вранья сплошной: потепление, кетайская чумка и вот этот udp недостандарт.
Откуда тут взятся производительности, когда это целиком херит sendfile() на стороне сервера!?
Нынче вон TLS запихнули в ядро, только чтобы sendfile() ускорить.
Сплошные дополнительные выбросы углерода и тепловая смерть вселенной! :)
| | |
| 1.41, th3m3 (ok), 18:11, 17/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Активировал. Ютуб - пока особо не заметил разницы. А вот FB, вроде по шустрее стал грузить.
| | |
| |
| 2.48, Аноним (48), 19:51, 17/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Там сейчас весь код выглядит так:
Если (http/3) То <оптимизированный_код> Иначе <лишь_бы_ползающий_код>
| | |
|
| 1.58, Начальника (?), 05:18, 18/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Объясните в чём прикол однопоточности http2/3. Разве чем больше потоков (как в http1.1) тем не быстрее грузится контент с сайта?
| | |
| |
| 2.59, Аноним (43), 07:20, 18/04/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
Отнопоточные они только с виду. Внутри прячутся собственные потоки с более низким временем создания, с управляемым приоритетом и возможностью протолкнуть не запрошенные данные. Если разработчик заморочится, то сайт будет загружать компоненты в установленном порядке, а не как TCP решит. И всё это без потери скорости. Например первыми будут грузиться картинки, что должны быть отображена прямо сейчас, а нижние пойдут следом. Но это только если разработчик заморочится иначе может стать даже хуже чем было, ведь эти виртуальные потоки создают оверхед.
Сами же TCP потоки можно разгонять до бесконечности, пока пропускная способность есть.
| | |
| |
| 3.61, Аноним (48), 11:39, 18/04/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> и возможностью протолкнуть не запрошенные данные
Дак гугл недавно как раз рассказывал, что это оказалось тормозом и забитием канала невостребованным мусором.
| | |
| 3.62, Аноним (48), 11:40, 18/04/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> Например первыми будут грузиться картинки, что должны быть отображена прямо сейчас, а нижние пойдут следом
Нормальные браузеры уже давно так делают, чем дальше картинка от амбразуры просмотра - тем ниже приоритет загрузки.
| | |
| |
| 4.63, Аноним (48), 11:43, 18/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
P.S. Тем более, что браузеры запоминают ещё и позицию скрола на странице, и когда открываешь сайт сразу на середине, этот "server-side-order" сделает подлянку, подсовывая не те картинки, которые сейчас нужны.
| | |
| 4.64, Аноним (43), 11:52, 18/04/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Нормальные браузеры уже давно так делают, чем дальше картинка от амбразуры просмотра
> - тем ниже приоритет загрузки.
Браузеры это делают через приостановку приёма данных через сокет, но во первых буфер сокета всё равно будет заполнятся пока не забьётся, а во вторых нужно очень хорошо высчитать тайминг, чтобы сервер продолжил отправлять файлы в тот самый момент, когда закончил передачу приоритетных. Учитывая общую асимметрию маршрутов в интернете это всё сизифов труд. На сервере это сделать проще, но скриптам придётся отправлять серверу информацию о том, что для него приоритетнее прямо сейчас.
| | |
|
|
|
| |
| 2.101, Аноним (-), 06:09, 21/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> LiteSpeed тоже поддерживает http3 но только в платной версии.
С учетом наличия толпы халявных реализаций творческих им узбеков.
| | |
|
| 1.74, rvs2016 (ok), 11:35, 19/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Ну и как этот хттп3 реально применять не только гуглам да фейсбукам, но ещё и на практике?
Вот надо, например, с веб-сервера передать в браузер страницу, которая содержит только 5 тегов <IMG>.
Ну великий хттп3 дарит возможность отправить все эти 5 картинок "одновременно" пятью параллельными потоками.
Чё надо в Апаче подкрутить, чтобы он именно так все эти "100500+" картинок (да и всего остального) одновременно погнал?
| | |
| 1.111, Аноним (111), 18:04, 31/10/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну и как это работает? 🤔
Похоже, что вообще никак - в about:networking все соединения HTTP/2, кроме любимого опеннетика
| | |
|
