Здравствуйте, Danchik, Вы писали:

D>Лучше почитать. Начиная от бинарных хидеров и продолжая server push. Упрощенно, когда ты запрашиваешь страничку, сервер, зная что страничка зависит от N картинок и от J жава скриптов, в том же соединении прокидывает их клиенту паралельно, без дополнительных запросов с клиента.

Я как раз в режиме slef-paced прохожу стэнфордский курс от 2012-2013 годов по сетям, и там для http1.1 разбирали подобный запрос, и отличий от того, что написано выше я не вижу, т.е. одно соедиение для всего, а не для каждого файла
свое соединение. Ну и где улучшения в этом плане http2?

Здравствуйте, Ikemefula, Вы писали:

I>htt2 реюзает коннекшн, имеет встроеное мультиплексирование,

Тоже и в http1.1, разве нет?

I>сервер пуш, сжатие хидеров и тд.

server push -- это и есть стандартизация ws, но как енто все влияет на ускорение загрузки, кроме сжатия header'ов?

Здравствуйте, Sharov, Вы писали:

I>>htt2 реюзает коннекшн, имеет встроеное мультиплексирование,
S>Тоже и в http1.1, разве нет?
Нет, там keep-alive, это другое.

И даже может переупорядочивать, возвращая результаты по мере возможности:

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Sharov, Вы писали:

I>>>htt2 реюзает коннекшн, имеет встроеное мультиплексирование,
S>>Тоже и в http1.1, разве нет?
·>Нет, там keep-alive, это другое.

Ага, оно. Экономия на новых ненужных соединениях в 1.1 появилось.

·>Image: RD4WE.png
·>И даже может переупорядочивать, возвращая результаты по мере возможности:
·>Image: HTTP-Request-pipelining-and-Request-Multiplexing.png


Теперь ясно, благодарю за картинки!

Здравствуйте, Sharov, Вы писали:

S> Я в вопросе не очень разбираюсь, а в чем отличие http2 от http1.1 при загрузке этих файлов? Там же вся суть в том, что в http2 встроили web-socket'ы, а с тз. быстродействия разве что-либо поменялось?

HTTP/2 может использовать одно TCP соединение для одновременной загрузки нескольких файлов в то время как для HTTP/1 требовалось открытие нескольких соединений и в рамках каждого из них запросы шли последовательно (картинки уже дали выше).

В теории нет различия между теорией и практикой, а вот на практике есть — идеальная картинка мира начинает спотыкаться о несовершенство сетей передачи данных где внезапно есть дешевые мобилки с 2/3G, потери пакетов, congestion window, rtt и т.д.

Как итог, типичный pipeline загрузки начинает выглядеть следующим образом (лень было рисовать красиво, но суть, думаю, понятна):



Проблемы, которые из этого вытекают, достаточно очевидны. Например, если HTTP/1 рендерил ресурсы (пусть будут изображения) по мере их загрузки, то в случае HTTP/2 мы можем долго видеть пустую страницу которая в какой-то момент вдруг "материализуется". При этом время полного рендеринга в обоих случаях приблизительно одинаково.

Это если очень упрощенно. Если рассматривать реальные сайты, то там все гораздо веселее, но итог один — чуда без основательных приседаний не случится, а после приседаний версия протокола особо уже ни на что не влияет.

Здравствуйте, Sharov, Вы писали:

S>server push -- это и есть стандартизация ws, но как енто все влияет на ускорение загрузки, кроме сжатия header'ов?

Сервер пуш это не ws, это механизм который позволяет слать файло вдогонку, клиентским джаваскриптом не контролируется. То есть, не "пошли мне для home page все её ресурсы, кроме картинок". Вместо этого сервер делает всё сам "попросили Home page, отправлю им всё, кроме картинок, все равно понадобится"

Здравствуйте, Ikemefula, Вы писали:

I> В твоей реальности патч невозможен, остаётся переинстал, а следовательно — в 10 раз больше расход диска, трафика.
Сколько я прикладного софта ни патчил, патчи приходили размером сравнимые с всем инсталляком.
Откуда вдруг 10 раз?

I>До кучи отдельные экзешники требуют больше оперативы.
С чего бы?

Здравствуйте, Ikemefula, Вы писали:

I>Если последовать твоему совету, то все экзешники гита, коих около пяти сотен
А зачем там 5 сотен разных exeшников?
Посмотрел — упал пацтол.
Это пц граждане, криворучие просто эпических масштабов.
Эти придурки ниасилили сделать нормальный порт, там в комплекте к git.exe идёт 109MB каталог с mingw, bash, sh, 154 MB usr каталога с nix барахлом AKA Cygwin. Потому что "parts of Git are implemented in shell script", как и принятно у альтернативно одарённых.

Отличный пример ты привёл! Именно за этот банный пц вменяемые люди ненавидят nix way.
Так что да, был бы git написан ровными руками то git.exe был бы одним exeшником, без внешних (не системных) зависимостей.

I>Фолдер Git у меня занимает 600мб, все это вырастет до 6 гигов
Потому что у его авторов руки из адских глубин жопы.

I>Полусотня экзешников офиса станет превратится в 20гб, вместо 2гб.
У меня в D:/Soft/Office нашлось 6 exeшников: excel.exe, msohtmed.exe, ois.exe, proflwiz.exe, winword.exe, msohelp.exe
Я поставил только то, чем пользовался и уже сто лет не запускал.

Здравствуйте, CreatorCray, Вы писали:

CC>Это пц граждане, криворучие просто эпических масштабов.
CC>Эти придурки ниасилили сделать нормальный порт, там в комплекте к git.exe идёт 109MB каталог с mingw, bash, sh, 154 MB usr каталога с nix барахлом AKA Cygwin. Потому что "parts of Git are implemented in shell script", как и принятно у альтернативно одарённых.

И никто не смог. Экономика не той системы. Гит выиграл у первоклассно написаных систем контроля версий и это реальная действительность.

И большая часть причин в том, что умные системщики за тридцать лет винды не могут Апи внятное сделать. Рекурсивное создание фолдера еле родили. И то, не сильно в этом уверен. Как только начинаешь бороться с путями, файлами, фолдерами, сразу хочется перебить всех системщиков в округе. Одна функция умеет одни пути, другая — другие. Одна умеет рекурсивные фолдеры, другая не умеет. Одна может работать с длинными путями, другая не может. Рокет саенс, не иначе.

CC>Так что да, был бы git написан ровными руками то git.exe был бы одним exeшником, без внешних (не системных) зависимостей.

Да, в сказке гит так и написан.

I>>Фолдер Git у меня занимает 600мб, все это вырастет до 6 гигов
CC>Потому что у его авторов руки из адских глубин жопы.

Намекаешь, что смог бы лучше?

CC>Я поставил только то, чем пользовался и уже сто лет не запускал.

Всем на тебя переориентироваться?

Вобщем, краткий пересказ — все говно, один ты крутой. Что еще пропустил?

Здравствуйте, CreatorCray, Вы писали:

CC>Сколько я прикладного софта ни патчил, патчи приходили размером сравнимые с всем инсталляком.
CC>Откуда вдруг 10 раз?

Из опыта. Я уже насмотрелся на такие предложения в действии. Все, что сложнее калькулятора, разбивают на части.

I>>До кучи отдельные экзешники требуют больше оперативы.
CC>С чего бы?

А потому, что код длл один на все экзешники, а влинкуешь статически — по одному в каждом.

Здравствуйте, Ikemefula, Вы писали:

I>Из опыта. Я уже насмотрелся на такие предложения в действии. Все, что сложнее калькулятора, разбивают на части.
На части разбивают только то, что реально надо шарить.

I>А потому, что код длл один на все экзешники, а влинкуешь статически — по одному в каждом.
Ещё раз напоминаю, exeшник должен быть один.

Здравствуйте, Ikemefula, Вы писали:

I>Гит выиграл у первоклассно написаных систем контроля версий и это реальная действительность.
"Выиграла" идея организации репы, имплементация же отвратительна.

I>И большая часть причин в том, что умные системщики за тридцать лет винды не могут Апи внятное сделать.
Щито? После виндового API на мешанину позикса без рвотных позывов смотреть нельзя.

I> Рекурсивное создание фолдера еле родили.
О боги, rocket science! Без подгузников прикладники не в состоянии из готовых кубиков этот примитив сделать?

I>Как только начинаешь бороться с путями, файлами, фолдерами
О чём ты?

I>Одна функция умеет одни пути, другая — другие.
Например?

I>Одна может работать с длинными путями, другая не может.
Например?

I>>>Фолдер Git у меня занимает 600мб, все это вырастет до 6 гигов
CC>>Потому что у его авторов руки из адских глубин жопы.
I>Намекаешь, что смог бы лучше?
Да.

Здравствуйте, Ikemefula, Вы писали:

I>Сервер пуш это не ws, это механизм который позволяет слать файло вдогонку, клиентским джаваскриптом не контролируется. То есть, не "пошли мне для home page все её ресурсы, кроме картинок". Вместо этого сервер делает всё сам "попросили Home page, отправлю им всё, кроме картинок, все равно понадобится"

И это не обязательно хорошо: может увеличить время для первой отрисовки, когда в параллель с необходимым шлется еще не очень для нее нужное, а канал тонкий.

Здравствуйте, Ikemefula, Вы писали:

I>И никто не смог. Экономика не той системы. Гит выиграл у первоклассно написаных систем контроля версий и это реальная действительность.

I>И большая часть причин в том, что умные системщики за тридцать лет винды не могут Апи внятное сделать. Рекурсивное создание фолдера еле родили. И то, не сильно в этом уверен. Как только начинаешь бороться с путями, файлами, фолдерами, сразу хочется перебить всех системщиков в округе. Одна функция умеет одни пути, другая — другие. Одна умеет рекурсивные фолдеры, другая не умеет. Одна может работать с длинными путями, другая не может. Рокет саенс, не иначе.

И как же hg вместе с черепахой умудряется в 90М помещаться?

Здравствуйте, Ops, Вы писали:

I>>Сервер пуш это не ws, это механизм который позволяет слать файло вдогонку, клиентским джаваскриптом не контролируется. То есть, не "пошли мне для home page все её ресурсы, кроме картинок". Вместо этого сервер делает всё сам "попросили Home page, отправлю им всё, кроме картинок, все равно понадобится"

Ops>И это не обязательно хорошо: может увеличить время для первой отрисовки, когда в параллель с необходимым шлется еще не очень для нее нужное, а канал тонкий.
Не понял каким образом. Это как раз http1 подразумевает несколько открытых сокетов и они шлют в параллель. А http2 позволяет слать ответы в одном сокете последовательно. Экономия за счёт раундтрипов — сервер сразу же всё шлёт, притом в том порядке как считает нужным, а не как запросы к нему придут.
К тому же, сейчас применяют data:-урлы, которые раздувают объём и замедляют отрисовку.

Здравствуйте, ·, Вы писали:

·>К тому же, сейчас применяют data:-урлы, которые раздувают объём и замедляют отрисовку.
Сейчас "дезихнеры" шрифты в base64 в CSS запихивают — вот за что надо конечности обрубать по самую жопу.

Здравствуйте, ·, Вы писали:

·>Не понял каким образом. Это как раз http1 подразумевает несколько открытых сокетов и они шлют в параллель. А http2 позволяет слать ответы в одном сокете последовательно. Экономия за счёт раундтрипов — сервер сразу же всё шлёт, притом в том порядке как считает нужным, а не как запросы к нему придут.
Ну вот смотри, самое простое: сервер послал сначала малополезный на этапе отрисовки скрипт, а потом только стили, в результате отрисовка началась позже, на время передачи скрипта.

Картинки прикольные.
В HTTP/1.1 есть pipelining (https://en.wikipedia.org/wiki/HTTP_pipelining) в результате которого от multiplexing (HTTP/2) внутри единственного tcp толку почти нет (HTTP/2 — это tcp, а не upd (QUIC), который HTTP/3). Так что алгоритм прост: открываем два соединения, по первому запрашиваем html и скрипты, по второму css и картинки (сервер после отдачи первого запроса внутри pipelined keep-alive соединения сразу начнет отдавать второй, никакого ожидания запроса не будет, более того, первый ответ сервер скопирует в буфер ядра из которого и будут отдаваться данные в сеть и одновременно сервер начнет генерировать ответ для следующего запроса, так что передача ответов будет с максимальной скоростью tcp соединения).
Чё тут можно ускорить мультиплексированием (HTTP/2)?

Здравствуйте, CreatorCray, Вы писали:

CC>Отличный пример ты привёл! Именно за этот банный пц вменяемые люди ненавидят nix way.
CC>Так что да, был бы git написан ровными руками то git.exe был бы [b]одним exeшником, без внешних (не системных) зависимостей.[/b]
А зачем? Чтобы фапать на один экзешник?

Здравствуйте, Masterspline, Вы писали:

M>В HTTP/1.1 есть pipelining (https://en.wikipedia.org/wiki/HTTP_pipelining) в результате которого от multiplexing (HTTP/2) внутри единственного tcp толку почти нет (HTTP/2 — это tcp, а не upd (QUIC), который HTTP/3).
У HTTP/1.1 Pipelineing'а есть определённые проблемы:

1) Head-of-line blocking. Если CSS будет в 10Мб, то придётся ждать пока он весь проедет. В HTTP2 потоки будут мультиплексированы в одном соединении.

2) Оно используется только для GET-ов.

3) Оно не работает: https://en.wikipedia.org/wiki/HTTP_pipelining#Implementation_in_web_browsers