Комментарии 27
У нас порядка 1300 JS файлов. При их пофайловом включении в страницу они грузятся 10 секунд. И затык именно на стороне браузера, который плохо работает с большим числом файлов.
Вы ведь знаете, что можно это всё до одного файла сжать?
Илья говорит, что не надо так делать.
При использовании HTTP2 конечно. Но я правильно понимаю что для каждого файла будет добавлено по одному фрейму для заголовков? Вроде и не много, но зачем?
Или речь о server-push?
Ну он же объясняет почему: при изменении одного файла не надо будет загружать здоровеный «сжатый» файл.
Для каждого файла будет 2 фрейма. Суть сферического HTTP/2 в том, что его ВНЕЗАПНО все используют и правильно выставляют приоритете ресурсам, и все сервера ВНЕЗАПНО умеют учитывать эти приоритеты и все это божественно мультиплексируются.
Реальность такова:
— никто еще не умеет приоритетами пользоваться (они тупо игнорируются)
— Сервер теперт внезапно стал сложным, ему теперь состояние надо хранить
— Мультиплексирование происходит на уровне который собственно сам является реализацией мальтиплексирования
В результате HTTP/2 это костыли чтобы избежать TCP Slow start. Диванный аналитик во мне говорит, что лучше бы они SCTP приняли для этой цели (в мэйлингах это обсуждали)
Для каждого файла будет 2 фрейма. Суть сферического HTTP/2 в том, что его ВНЕЗАПНО все используют и правильно выставляют приоритете ресурсам, и все сервера ВНЕЗАПНО умеют учитывать эти приоритеты и все это божественно мультиплексируются.
Реальность такова:
— никто еще не умеет приоритетами пользоваться (они тупо игнорируются)
— Сервер теперт внезапно стал сложным, ему теперь состояние надо хранить
— Мультиплексирование происходит на уровне который собственно сам является реализацией мальтиплексирования
В результате HTTP/2 это костыли чтобы избежать TCP Slow start. Диванный аналитик во мне говорит, что лучше бы они SCTP приняли для этой цели (в мэйлингах это обсуждали)
У SCTP проблема с натами: многие SOHO роутеры не умеют его натить (будет по сути одно соединение на роутер), но это пол беды, ибо его так-же не умеют натить многие Large Scale NATы у ISP, а вот это существенно хуже (тут получится одно соединение на один внешний IP адрес).
Есть вариант SCTP over UDP, но внедрять его на несколько лет переходного периода не целесообразно.
Думаю что логичнее было-бы чуть-чуть потерпеть, и, лучше, посодействовать распространению IPv6. А когда он будет работать массово — можно смело использовать SCTP.
Есть вариант SCTP over UDP, но внедрять его на несколько лет переходного периода не целесообразно.
Думаю что логичнее было-бы чуть-чуть потерпеть, и, лучше, посодействовать распространению IPv6. А когда он будет работать массово — можно смело использовать SCTP.
А зачем слеш? Ещё один слеш? Мало слешей в http? :D С третьей минуты blip.tv/beettv/tim-berners-lee-looks-back-the-in-web-addresses-was-unnecessary-2727797
Это версия, в uri она не указывается. Сейчас вы используете HTTP/1.1
То, что в машинных беседах пробел используется в качестве разделителя между протоколом и кодом ответа (что и вынуждает использовать слеш для указания версии, ибо иначе версия будет ошибочно считаться кодом ответа), не значит что нам — человекам — стоит поступать точно так же. Пробел вполне себе неплохой символ. Но, видимо, недостаточно модный.
Круто, но судя по скринам, HTTP/2 идет к statefull.
НЛО прилетело и опубликовало эту надпись здесь
Возможно такие цифры даёт тестирование 10% пользователей Гугла.
Т.с. эффект от масштаба, а в скромных ДЦ и цифры будут скромнее.
Я давно наблюдаю за развитием SPDY и потом HTTP2, но для простого обывателя пока не вижу ни чего, что могло бы как-то улучшить работу сайта с котятками.
Т.с. эффект от масштаба, а в скромных ДЦ и цифры будут скромнее.
Я давно наблюдаю за развитием SPDY и потом HTTP2, но для простого обывателя пока не вижу ни чего, что могло бы как-то улучшить работу сайта с котятками.
У меня, собственно, тот же вопрос: в чем кардинальное улучшение HTTP/2.0 по сравнению с имеющимися технологиями объединения файлов? И можно качать хоть в 10 потоков с сервера: на канал это кардинально не повлияет. Да на 10-25% он будет лучше утилизироваться, но браузеры и так уже его утилизируют по полной, когда это возможно.
На скринах же видео, что у TCP очень много времени уходит на установку сессии.
А так же: en.wikipedia.org/wiki/Slow-start
А так же: en.wikipedia.org/wiki/Slow-start
Подождите. TCP Slow Start уже сейчас можно через пересборку nginx сделать, для этого HTTP/2.0 не нужен (Илья же и объясняет в своих статьях, как именно). И keepalive/SPDY сейчас решает проблему сессий (не решает проблему пинга, но на больших объемах и небольшом количестве файлов она вообще не существенна).
Другое дело, что с объединением/распараллеливанием файлов никто толком работать не хочет, поэтому нужен HTTP/2.0 «из коробки». Но у него и минусов в текущей формулировке хватает (взять те же блокирующие ресурсы в общем потоке).
Другое дело, что с объединением/распараллеливанием файлов никто толком работать не хочет, поэтому нужен HTTP/2.0 «из коробки». Но у него и минусов в текущей формулировке хватает (взять те же блокирующие ресурсы в общем потоке).
НЛО прилетело и опубликовало эту надпись здесь
Вы не путаете с TLS TTFB? Потому, что проблемы TCP Slow Start решаются обычно сетевым стэком ОС. Есть часовой доклад этого же Ильи в каких версиях линукса увеличили стартовое окно. Так, что долгая TCP сессия нужна, чтобы окно было оптимальным.
Одно дело качать 16 гигабайтный файл по http, да, там просто открыл пачку потоков и качаешь. Другое дело, когда браузеру надо открыть 30 соеденений, чтобы скачать два мегабайта. Сжатие заголовков опять же не плохое нововедение и то, что протокол наконец-то стал бинарным.
Одно дело качать 16 гигабайтный файл по http, да, там просто открыл пачку потоков и качаешь. Другое дело, когда браузеру надо открыть 30 соеденений, чтобы скачать два мегабайта. Сжатие заголовков опять же не плохое нововедение и то, что протокол наконец-то стал бинарным.
там 2 slow start, и Илья об обоих говорил. Правда, нам бы еще определиться, что называть Slow Start… :)
Есть TCP Slow Start это решается только на уровне ядра ОС. И у этого есть вполне внятное определение: TCP использует очень маленькое окно на свежих сессия, чтобы случайно не забить канал и постепенно увеличивает его до тех пор пока не становиться хуже — если стало хуже то уменьшает.
Есть так же TLS Time To First Byte, он уже решается реализацией и на уровне приложения: False Start, правильном хранении TLS сессий, и прочими ухищрениями. TLS TTFB же это целый набор болячек. Илья правда говорит, что повсеместное внедрение TLS ускорит сам TLS — я слабо представляю как связано между собой.
Есть так же TLS Time To First Byte, он уже решается реализацией и на уровне приложения: False Start, правильном хранении TLS сессий, и прочими ухищрениями. TLS TTFB же это целый набор болячек. Илья правда говорит, что повсеместное внедрение TLS ускорит сам TLS — я слабо представляю как связано между собой.
Initial Congestion Window ускоряется на уровне настроек, это доступно для любого сервера. icwnd = 10
Я лишь повторяю слова Ильи.
Но к моему первоначальному вопросу эти слова никак не относятся. Повторюсь: как HTTP/2.0 кардинально улучшит текущую ситуацию со скоростью сайтов? Если никак, то зачем вокруг него столько шума?
HTML 5 ввел в обращение новую семантику и медиа-форматы и позволил разрабатывать сайты проще. Это был прорыв. Где в случае HTTP/2.0 прорыв?
HTML 5 ввел в обращение новую семантику и медиа-форматы и позволил разрабатывать сайты проще. Это был прорыв. Где в случае HTTP/2.0 прорыв?
Нет никакого прорыва, это надо назвать HTTP/1.2.
Два больших изменения это:
— Бинарный, а не текстовый
— Мультиплексинг
— Ну сжатие заголовоком можно добавить, но не думаю, что принуждение сервера быть stateful это плюс.
Промизы тоже ускорят, клиент вероятно уже будет иметь файл до того как он узнает, что файл нужен. Ненужность сжатия позволит правильно использовать кэш, а не менять весь спрайтшит из-за одной иконки или еще хуже раздутый css файл из-за datauri.
Насколько я знаю, Initial Congestion Window, таки выставляется ядром на весь интерфейс. В «свежих» ядрах просто увеличили дефолтное значение.
Два больших изменения это:
— Бинарный, а не текстовый
— Мультиплексинг
— Ну сжатие заголовоком можно добавить, но не думаю, что принуждение сервера быть stateful это плюс.
Промизы тоже ускорят, клиент вероятно уже будет иметь файл до того как он узнает, что файл нужен. Ненужность сжатия позволит правильно использовать кэш, а не менять весь спрайтшит из-за одной иконки или еще хуже раздутый css файл из-за datauri.
Насколько я знаю, Initial Congestion Window, таки выставляется ядром на весь интерфейс. В «свежих» ядрах просто увеличили дефолтное значение.
Вопрос пользы от кеширования статики в браузере весьма тонкий: сейчас на (почти) любом сайте так много статики, что несколько сайтов довольно сильно могут забить кеш браузеру. У иных браузеров кеш небольшой (все мобильные, как вариант). Далее вопрос: какое количество данных в кеше браузера еще ускоряет его работу, а какое — даже и замедлит? Тем более что висит еще на новый сайт выдавливает старое из кеша.
Я бы сказал, что задать кеш в жуткую величину в 1 Гб не спасет, а усугубит проблему: файлы лягут на диск, они не будут в горячем кеше ФС, и их доставать с диска может оказаться не сильно дешевле, чем взять с сайта.
Далеко не надо ходить за примером: главная Хабра весит 3.6 Мб (точнее, столько браузер у меня принял по сети), их них только пара десятков килобайтов — сам html. Прикинем то же без сжатия, и получаем, что в кеше бы забили статикой мегабайтов 10. Но веб Хабр — не один (и даже не основной для многих) сайт, который каждый из нас посещает за сутки, так что суммарный суточный прирост кеша будет явно в сотни метров. iPad такое не выдержит, браузеры на ПК — когда как.
Я к тому, что склеить все css в единый файл в файловой системе веб-сервера — тупо все равно быстрее и надежнее, чем отправить в браузер 100 маленьких css-ок, выставив каждой время жизни в кеше в 5 лет. Потому что не доживут ни общий файл, ни 100 мелких до этих лет, выдавит их поток более свежей статики. А вот скорость загрузки одного файла даже по http 1.1 со сжатием будет вполне нормальной, и http 2 с его наворотами сильно не спасет ситуацию. То же и с js.
Я бы сказал, что задать кеш в жуткую величину в 1 Гб не спасет, а усугубит проблему: файлы лягут на диск, они не будут в горячем кеше ФС, и их доставать с диска может оказаться не сильно дешевле, чем взять с сайта.
Далеко не надо ходить за примером: главная Хабра весит 3.6 Мб (точнее, столько браузер у меня принял по сети), их них только пара десятков килобайтов — сам html. Прикинем то же без сжатия, и получаем, что в кеше бы забили статикой мегабайтов 10. Но веб Хабр — не один (и даже не основной для многих) сайт, который каждый из нас посещает за сутки, так что суммарный суточный прирост кеша будет явно в сотни метров. iPad такое не выдержит, браузеры на ПК — когда как.
Я к тому, что склеить все css в единый файл в файловой системе веб-сервера — тупо все равно быстрее и надежнее, чем отправить в браузер 100 маленьких css-ок, выставив каждой время жизни в кеше в 5 лет. Потому что не доживут ни общий файл, ни 100 мелких до этих лет, выдавит их поток более свежей статики. А вот скорость загрузки одного файла даже по http 1.1 со сжатием будет вполне нормальной, и http 2 с его наворотами сильно не спасет ситуацию. То же и с js.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Илья Григорик о внедрении HTTP/2