Вредоносное ПО (malware) - это назойливые или опасные программы,...
![Лучшие утилиты для удаления вирусов и вредоносных программ](https://i2.wp.com/webhelper.info/images/danger.jpg)
Протокол передачи гипертекста (HTTP , англ. HyperText Transfer Protocol) - протокол, который управляет соединением между вашим сервером и браузерами клиентов. Впервые после 1999 года, появилась новая версия этого протокола ,и это обещает значительно ускорить каждый сайт.
В этой статье мы опишем основы HTTP/2 для дизайнеров и разработчиков. Я объясню некоторые ключевые особенности нового протокола, рассмотрю совместимость (серверную и браузерную) и остановлюсь подробнее на вещах, над которыми нужно задуматься, поскольку все чаще видим внедрение HTTP/2 . Прочитав эту статью, вы получите обзор того, что нужно изменить в вашей работе в кратко- и долгосрочной перспективе. Также я включу множество дополнительных ресурсов, на тот случай, если вы захотите углубится в вопрос. Моя цель - предоставить достаточное количество знаний, которое поможет принят правильное решение о переходе на HTTP/2 .
Если у ваш сайт использует только http, тогда мое предложение как можно скорее перейти на https, и уже тогда определится с HTTP/2 стратегией.
В HTTP/1.1 получение одного большого изображения намного эффективней для браузеров, чем множество мелких запросов. Это происходит потому, что несколько запросов выстраиваются в очередь друг за другом. Объединение мелких файлов в спрайты было временным решением этой проблемы.
Результирующий спрайт возвращался одним http запросом, предупреждая проблему очереди запросов. Однако, даже если посетитель находится на страничке, где отображаются только несколько иконок, ему все равно нужно загрузить намного больший файл.
С мультиплексирующей способностью HTTP/2 , очередь ресурсов больше не является проблемой. Отдача мелких изображений отдельно будет лучшим решением во многих случаях; вам нужно обрабатывать только то, что необходимо для запрошенной страницы. Но создание спрайтов и дальше будет оправданным во многих случаях. HTTP реквесты - это только один аспект производительности. Объединение некоторых изображений вместе в спрайт позволяет достичь лучшего сжатия, и, как результат, меньшего объема загрузки, особенно, если все изображения используются на странице. Однако, спрайты больше не всегда будут лучшим решением.
Другое обходное решение проблемы множества HTTP-запросов - встраивание изображений в css с использованием data uri . Использование изображений подобным способом делает css-файл намного больше. Если вы в добавок используете сжатие и объединение ассетов, посетители будут загружать огромное количество кода, даже если никогда не перейдут на страницу, где он действительно нужен.
С оптимизацией HTTP-запросов у HTTP/2 , эта "лучшая практика" будет больше мешать, нежели помогать улучшению производительности.
Многие из нас используют объединение мелких css и javascript файлов. Зачастую мы хотим содержать их раздельно во время разработки - для лучшего понимания, но мы знаем, что загрузка одного файла браузером намного эффективней, чем пяти. Еще раз, мы ограничиваем количество HTTP-запросов.
Если вы делаете это, посетитель, открыв главную страницу, загрузит все css- и javascript файлы, необходимы для работы сайта, даже если не использует большинство из них. Как разработчик, вы можете уменьшить проблему путем тщательного подбора подключаемых файлов для каждой страницы сайта, но для этого требуется слишком много работы.
Еще одна дополнительная проблема с объединением файлов - очистка кэша: чистится все вместе. Вы не можете указать файлам, которые никогда не меняются, долгое время жизни, и короткое часто изменяемым. Весь кэш должен быть обновлен, даже если поменялась одна строка в css-файле.
Предполагаю, вы понимаете, к чему я клоню! HTTP-запросы дешевые в HTTP/2 мире. Распределение ассетов на используемых страницах будет намного более оптимально. Вы сможете отдавать только реально используемый код. Загрузка множества мелких файлов не будет иметь значения. Также вы сможете распределять файлы по частоте их изменений.
C HTTP/1.1 , вы ограничены количеством открытых соединений. Если невозможно избежать загрузки, один из способов решения проблемы - получение ресурсов с разных доменов. Эта методика называется domain sharding . Это хотя и ускоряет время загрузки, но может вызвать новые проблемы , не говоря уже о том, что это требует дополнительных расходов во время разработки.
HTTP/2 упраздняет необходимость domain sharding, потому что снято ограничение количества одновременно загружаемых ресурсов. Более того, это может плохо повлиять на производительность, поскольку открывает дополнительные TCP соединения и мешает обрабатывать HTTP/2 приоритеты ресурсов.
Если вы стартуете долговечный проект проект, но по какой-то причине не можете запустить его с HTTP/2 , возможно, по причинам поддержки сервера, лучше сразу подготовится до HTTP/2 . Вы можете добавить несколько вещей, которые упростят переход в будущем.
Если вы создаете спрайты, позаботьтесь также о создании и оптимизации мелких ассетов, или меньших спрайтов под индивидуальные страницы, если видите, что это улучшит производительность. Это упростит переход от больших спрайтов до более мелких, если будет необходимо.
Это также касается и data uri. Если используете в css, подготовьте также картинки для того времени, когда вы откажетесь от этой техники.
Из-за использования объединения css и javascript файлов, существует соблазн объединять их и на этапе разработки, так как они все равно потом собираются в один файл. Когда вы переключитесь на HTTP/2 , вы получите лучшую производительность, если будете тщательно разделять ресурсы, не загружая ничего лишнего. Следовательно, организация ассетов теперь будет иметь ценность. Сейчас вы можете продолжать объединять ассеты, а при необходимости сразу же начать отдавать их по отдельности.
Текущая лучшая практика для HTTP/1.1 - ограничение sharding двумя хостами. В HTTP/2 возможно объединить соединения, если TLS сертификат валидный для обеих хостов и хост резолвится для одного IP-адресса. Поскольку браузерная реализация требует, чтобы HTTP/2 работал через https, необходимо получить TLS сертификат, чтобы использовать HTTP/2 . Посмотрите больше на 26 слайде Ilya Grigorik’s с Velocity Conference.
В конечном счете, мы получим множество лучших практик для HTTP/2 . Для лучшей производительности, этот протокол даст вам множество возможностей для управления, и вам придется принимать решения для каждого проекта. Я не рассказала в этой статье, как использовать преимущества от новых фич HTTP/2 , таких, как, к примеру, серверный пуш. Эта технология позволяет вам решать, какие ресурсы приоритетней и заставляет сервер обрабатывать их раньше, чем остальные.
Для дизайнеров и разработчиков, у которых нету полного контроля над сервером, это может подождать до обновления серверов. Существуют хостинг-провайдеры, которые уже предлагают HTTP/2 - даже шаред хостинги, так что вы можете рекомендовать клиенту такие решения, если видите преимущества.
Если сайт размещен на сервере, который поддерживает HTTP/2 , решение оптимизировать под HTTP/1.1 или HTTP/2 должно быть принято в зависимости от протокола, который поддерживают браузеры большинства пользователей. Помните, что HTTP/2 обратно совместимый - вам не придется делать ничего особенного. Решение, которое вам нужно принять - когда именно оптимизировать под новый протокол.
Вам нужно будет принять решение, пользуясь данными аналитики. Если большинство пользователей использует браузеры, которые поддерживают HTTP/2 , тогда есть смысл оптимизировать под этих пользователей. Многие из на уже достигли этого момента . Вам нужно использовать данные с таких сайтов, как Can I Use вместе с данными, собираемыми с собственной аналитики и понимания интересов аудитории. К примеру, большинство преимуществ HTTP/2 почувствуют пользователи мобильных устройств. Если у вас больше мобильного трафика, это может свидетельствовать о необходимости ближайшего перехода. Однако, если много пользователей используют Opera Mini, тогда нужно повременить с переходом на HTTP/2 , так как, несмотря на множество пользователей в некоторых странах мира, этот браузер не поддерживает новый стандарт.
Если вы создаете новый сайт сегодня, можно посоветовать сразу помнить об оптимизации для HTTP/2 во время разработки. Если во время запуска, вы поймете, что нужно сделать уступку в пользу HTTP/1.1 из-за проблем совместимости сервера/браузеров, оптимизировать можно во время процесса сборки, таким образом, оставляя возможность быстро перейти на HTTP/2 .
1. Запустите проект, или перейдите но TLS сейчас.
Это должно быть вашим приоритетом.
2. Подготовьте ваш процесс сборки до HTTP/2 .
Любой сайт в долгосрочной перспективе получит преимущества при переходе на HTTP/2 . Так что создавайте такой процесс сборки, который можно оптимизировать под оба протокола.
3. Проверьте вашу статистику
Проверив статистику использования браузеров и таблицу совместимости Can I Use , вы сможете увидеть, сколько процентов посетителей получать преимущества при оптимизации под HTTP/2 .
4. Проверьте свой хостинг
Когда вы достигнете момента, когда будут преимущества в переходе на новый протокол, вы должны проверить, что хостинг поддерживает HTTP/2 . Поговорите с хостинг провайдером или администратором сервера, чтобы узнать их планы о переходе.
5. Займитесь оптимизацией под HTTP/2 .
Когда ваш сервер поддерживает HTTP/2 , остальное за вами. Перестаньте использовать старые лучшие практики и переключитесь на новые. Это будет значить, что пользователи, браузеры которых не поддерживают HTTP/2 , получат меньшую производительность, поэтому решающим фактом должно стать количество пользователей, которые получать преимущества.
После перехода на HTTP/2 , будет здорово протестировать прирост скорости и увидеть, какая техника больше всего улучшила сайт. Я ищу информацию о том, как люди переносили реальные сайты на новый протокол. Эта информация поможет нам разработать новое поколение лучших практик.
Возрастающее количество информации оHTTP/2 доступно онлайн. Некоторые ресурсы размещу здесь, часть из них были использованы при написании статьи.
Этот плагин для браузера показывает, работает ли сайт с HTTP/2 .
HTTP/2 - новая версия сетевого протокола HTTP, основанная на разработанном компанией Google протоколе SPDY. Предыдущая версия протокола HTTP/1.1 принята в далеком 1999 году, когда сайты очень сильно отличались от современных. В наше время веб-технологии развиваются слишком стремительно, поэтому новая версия протокола - очень важное и нужное нововведение, направленное на повышение безопасности, эффективности и скорости работы сайтов.
Ключевые особенности HTTP/2
Поддержка браузерами
На сегодняшний день все популярные браузеры для компьютеров и мобильных устройств поддерживают работу по протоколу HTTP/2. Протокол HTTP/1.1 будет использоваться в том случае, если браузер не поддерживает новый протокол. Таким образом, HTTP/2 включается автоматически всегда, когда это возможно.
Важно! Протокол HTTP/2 не требует обязательного шифрования, однако разработчики браузеров приняли решение реализовать работу с новым протоколом только через TLS (HTTPS). Поэтому наличие установленного (коммерческого или бесплатного) является обязательным условием для работы по протоколу HTTP/2.
Ниже наглядно представлены версии браузеров, для которых реализована поддержка протокола HTTP/2 (выделены зеленым фоном). В Internet Explorer 11 новый протокол поддерживается только в Windows 10, в Safari - OSX 10.11 и выше.
Сегодня все больше посетителей используют для доступа к сайтам мобильные устройства. Возможности HTTP/2 хорошо работают для уменьшения задержек при доступе к ресурсам в мобильных сетях передачи данных, в которых пропускная способность зависит от разных факторов, а качество связи не всегда приемлемо. Учитывая поддержку HTTP/2 всеми основными мобильными браузерами преимущества нового протокола на мобильных устройствах особенно очевидны.
HTTP/2 и поисковая оптимизация (SEO)
Несомненно, многих владельцев веб-сайтов волнует вопрос оптимизации своих ресурсов для поисковых систем. Одним из важных факторов ранжирования для поисковых систем является скорость загрузки сайтов. Поэтому сайты, которые работают по протоколу HTTP/2, получат бонус в ранжировании именно за скорость загрузки. Отметим, что теперь еще выгоднее переходить на HTTPS, так как это позволит дополнительно получить бонус в ранжировании поисковых систем и за использование HTTPS.
HTTP/2 и оптимизация сайтов
Для протокола HTTP/1.1 веб-разработчики успешно использовали ряд оптимизаций, чтобы обойти ограничения протокола. Но не все оптимизации будут хорошо работать в HTTP/2 - некоторые из них необходимо модифицировать, а от некоторых вовсе отказаться. Напомним, что HTTP/2 обратно совместим с HTTP/1.1, поэтому можно не предпринимать никаких действий - сайт будет работать как и прежде. Ниже рассмотрим детально на что следует обратить внимание.
Как проверить, поддерживает ли сайт протокол HTTP/2
Существуют онлайн-сервисы, с помощью которых можно легко и быстро проверить наличие поддержки HTTP/2. Например, .
Для браузеров и есть расширения, которые иконкой-индикатором оповещают о том, что сайт открыт по протоколу HTTP/2.
Рассмотрим для примера просмотр протокола в инструментах разработчика в браузерах Chrome и Firefox.
Для каждого ресурса в столбце «Protocol» отображается протокол, по которому он загружен:
Firefox:
Для каждого ресурса в столбце «Протокол» отображается протокол, по которому он загружен:
В прошлом году в мире сетевых технологий произошло очень важное событие: была утверждена и стандартизирована новая версия протокола HTTP — HTTP/2. HTTP/2 уже поддерживается в популярных веб-серверах: Apache и Nginx. Идёт работа по внедрению HTTP/2 в IIS. Реализована поддержка и в большинстве современных браузеров.
Использование HTTP/2 за последнее время существенно расширилось.
По данным на середину 2015 года, процент сайтов и веб-сервисов, перешедших на HTTP/2, был невелик ― всего 0,4%. Совсем свежая статистика (январь 2016) свидетельствует о значительном росте: с 0,4 до 6,5%. Есть все основания полагать, что в ближайшее время темпы роста будут увеличиваться.
Задуматься о практических аспектах перехода на HTTP/2 стоит уже сейчас. Эту тему мы хотели бы затронуть в сегодняшней статье. Особенно нас будет интересовать проблема адаптации существующих приёмов оптимизации производительности веб-сайтов под специфику нового протокола.
Прежде чем перейти непосредственно к рассмотрению этого вопроса, обратимся к истории протокола HTTP/2 и кратко опишем основные нововведения, отличающие его от HTTP/1.1.
Из-за ограничения на количество одновременных подключений в HTTP/1.1 загрузка страниц, содержащих большое количество «тяжёлого» контента, осуществляется медленно. Можно выделить два пути решения этой проблемы. Первый заключается в использовании различных техник оптимизации производительности (о некоторых из них мы уже писали), а второй — в попытке модификации самого протокола HTTP с целью устранения возможных узких мест. Рассмотрим такие попытки более подробно.
Первый масштабный проект реформирования HTTP был представлен в 2009 году инженерами Google. Это протокол SPDY , целью которого в первую очередь было ускорение работы веб-сайтов и приложений путём модификации традиционных способов приёма и отправки запросов.
SPDY требует поддержки как на стороне сервера, так и на стороне клиента. Разработчики Google создали специализированные модули для Apache (mod_spdy) и для Nginx (ngx_http_spdy_module). Поддерживается он и практически во всех популярных браузерах.
HTTP/2, представленный шестью годами позже, во многом основывается на SPDY. Новая версия HTTP была создана рабочей группой Hypertext Transfer Protocol working group. В мае 2015 года спецификация HTTP/2 была опубликована как RFC 7540 .
Протокол HTTP/2 обратно совместим с HTTP/1.1. Изменения, направленные на устранение узких мест и повышения производительности, во многом продолжают линию SPDY. Рассмотрим вкратце наиболее важные из них.
В современных браузерах количество одновременных TCP-соединений ограничено. Поэтому страницы с большим количеством статического контента загружаются не так быстро, как хотелось бы.
В HTTP/2 благодаря мультиплексированию статические элементы загружаются параллельно, и благодаря этому существенно улучшается производительность.
В первом подходе каждый поток получает определённый вес. Потом на основе веса сервер распределяет нагрузку между потоками. Такой подход уже использовался в протоколе SPDY.
Второй метод, являющийся основным в HTTP/2, заключается в следующем: браузер просит сервер загружать определённые элементы контента в первую очередь. Например, браузер может попросить сервер сначала загрузить CSS-файлы или JavaScript, а уже потом — HTML или изображения.
В HTTP/2 приоритизация является не обязательным, а желательным методом. Однако мультиплексирование без неё работать должным образом не будет. Скорость загрузки может быть даже ниже, чем HTTP/1.1. Ресурсы с более низким приоритетом будут занимать полосу, что приведёт снижению производительности.
В HTTP/2 заголовки передаются в сжатом виде. Благодаря этому уменьшается количество информации, которой обмениваются между собой сервер и браузер. Вместо алгоритмов gzip/deflate используется HPACK . Это снижает уязвимость к атакам типа BREACH .
Это нужно не только для HTTP/2. В поиске Google использование безопасного соединения является одним из критериев ранжирования . Браузеры (см. и ) скоро будут помечать сайты, не поддерживающие https, как «небезопасные». Добавим также, что многие возможности HTML5 ― например, геолокация ― без безопасного соединения будут недоступны .
После этого откройте конфигурационный файл /etc/nginx/nginx.conf и найдите в секции server следующую строку:
Listen 443 ssl;
И замените её на:
Listen 443 ssl http2;
Сохраните внесённые изменения и перезагрузите Nginx:
$ sudo service nginx reload
# for a https server Protocols h2 http/1.1 # for a http server Protocols h2c http/1.1
После этого перезапустите Apache. Вот и всё — для базовой настройки этого вполне достаточно.
Многие способы оптимизации, успешно используемые в HTTP/1.1, в HTTP/2 работать не будут. Некоторые из них потребуется модифицировать, а от некоторых ― отказаться вообще. Рассмотрим этот вопрос более подробно.
Спрайт возвращался в ответ на единственный запрос. Даже если пользователь заходил на страницу, на которой находится всего одно небольшое изображение, нужно было загрузить весь спрайт.
В HTTP/2 c его мультиплексированием таких проблем нет, однако использование спрайтов в определённых ситуациях может оказаться полезным. Объединение нескольких изображений в спрайт (особенно если все эти изображения находятся на одной странице) помогает улучшить сжатие и таким образом снизить общий объём загружаемых данных.
Если одновременно со встраиванием изображений для оптимизации используется ещё и конкатенация JS и CSS, пользователю скорее всего придётся загрузить весь соответствующий код, даже если он не будет посещать страницу с этими изображениями.
В HTTP/2 такая практика скорее ухудшит, а не улучшит производительность.
Однако при использовании конкатенации может возникнуть та же проблема, что и со спрайтами: зайдя на какую-то одну страницу сайта, пользователь загрузит все используемые на нём СSS- и JS-файлы (при этом очень вероятно, что большинство из этих файлов ему никогда не понадобятся). Конечно, можно тщательно отбирать файлы для каждой страницы сайта, но это будет занимать слишком много времени.
Ещё одна сложность заключается в том, что все элементы конкатенированного файла нужно вычищать из кэша одновременно. Невозможно сделать так, чтобы для одних элементов была выставлена одна дата истечения срока действия, а для других (которые к тому же и используются гораздо чаще) — другая. Если изменить хотя бы одну строку в CSS — срок действия истечёт сразу у всех элементов.
Стоит ли пользоваться конкатенацией в HTTP/2? Если HTTP-запросы не требуют существенных затрат ресурсов, то без неё вполне можно обойтись. Загрузка множества небольших файлов стилей никакой проблемы не составит. Не будет и трудностей с истечением сроков действия и кэшированием.
С переходом HTTP/2 необходимость в доменном шардировании отпадает. Вы можете запросить столько ресурсов, сколько вам требуется. Более того, в случае с HTTP/2 шардирование не улучшит производительность, а приведёт скорее к противоположному эффекту, так как создаст дополнительные TCP-соединения и будет мешать приоритизации.
При планировании перехода следует учитывать и особенности вашего проекта. Если у вас много пользователей, которые приходят к вам с мобильных устройств, то это означает, что вам желательно перейти на HTTP/2 как можно скорее. На смартфонах и планшетах преимущества нового протокола будут особенно очевидными. Однако и здесь нужно учитывать множество нюансов: например, во многих регионах мира до сих пор много пользователей браузера Opera Mini, а он HTTP/2 пока что не поддерживает.
Если вы планируете запускать новый веб-сервис — задумайтесь о перспективе перехода на HTTP/2. Конечно, вам ещё придётся использовать HTTP/1.1 в течение какого-то времени, но уже сейчас вы можете принять меры по оптимизации, которые облегчат вам жизнь в будущем.
Версия этого документа – 1.2.
Email: [email protected]
Twitter: @bagder
Web: daniel.haxx.se
Blog: daniel.haxx.se/blog
Если вы обнаружили опечатки, упущения, ошибки и явную ложь в этом документе, пожалуйста отправьте мне исправленную версию параграфа и я выпущу исправленную версию. Я должным образом отмечу всех, кто помог! Надеюсь, что со временем получиться сделать текст лучше.
HTTP 1.1 стал протоколом, который используется поистине для всего в Интернете. Огромные инвестиции были вложены в протоколы и инфраструктуру, которые теперь извлекают из этого прибыль. Дошло до того, что сегодня зачастую проще запустить что-либо поверх HTTP, чем создавать что-то новое вместо него.
Когда HTTP был создан и выпущен в мир, он, вероятно, воспринимался скорее как простой и прямолинейный протокол, но время показало, что это не так. HTTP 1.0 в RFC 1945 – это 60 страниц спецификации, выпущенной в 1996. RFC 2616, который описывал HTTP 1.1, был выпущен лишь тремя годами позднее в 1999 и значительно разросся до 176 страниц. Кроме того, когда мы в IETF работали над обновлением спецификации, она была разбита на шесть документов с ещё большим числом страниц в итоге. Без сомнений, HTTP 1.1 большой и включает мириады деталей, тонкостей и в не меньшей степени опциональных разделов.
Природа HTTP 1.1, заключённая в наличии большого числа мелких деталей и опций, доступных для последующего изменения, вырастила экосистему программ, где нет ни одной реализации, которая бы воплотила всё – и, на самом деле, невозможно точно сказать, что представляет из себя это «всё». Что привело к ситуации, когда возможности, которые первоначально мало использовались появлялись лишь в небольшом числе реализаций, и те кто их реализовывал после наблюдали незначительное их использование.
Позже это вызывало проблемы в совместимости, когда клиенты и сервера начали активнее использовать подобные возможности. Конвейерная обработка HTTP (HTTP pipelining
) – это один из показательных примеров подобных возможностей.
HTTP 1.1 прошёл трудный путь, чтобы по настоящему воспользоваться всей мощью и производительностью, которую даёт TCP. HTTP-клиенты и браузеры должны быть по-настоящему изобретательными, чтобы найти способы для уменьшения времени загрузки страницы.
Прочие эксперименты, которые параллельно велись в течении многих лет, также подтверждали, что TCP не так просто заменить, и поэтому мы продолжаем работать над улучшением как TCP, так и протоколов, работающих поверх него.
TCP можно легко начать использовать полноценно, чтобы избежать пауз или периодов времени, которые могли быть использованы для отправки или приёма большего количества данных. Последующие главы осветят некоторые из этих недостатков использования.
Когда смотришь на тенденции развития некоторых наиболее популярных на сегодня сайтов и сравниваешь сколько занимает времени загрузка их главной страницы, тенденции становятся очевидными. За последние несколько лет количество данных, которые требуется передать постепенно выросло до отметки 1,5Мб и выше, но что наиболее важно для нас в этом контексте, так это число объектов, которое в среднем теперь близко к сотне. Сто объектов необходимо загрузить, чтобы отобразить всю страницу целиком.
Как показывает график, тренд был растущим, но позднее нет никаких признаков, что он будет дальше меняться.
HTTP 1.1 очень чувствителен к задержкам, частично из-за того, что в конвейерной передаче HTTP по-прежнему хватает проблем и она отключена у подавляющего числа пользователей.
В то время, как все мы наблюдали значительное увеличение пропускной полосы у пользователей за последние несколько лет, мы не видели подобного уровня снижения задержки. Каналы с высокой задержкой, как у многих современных мобильных технологий, значительно снижают ощущение хорошей и быстрой веб-навигации, даже если у вас имеется действительно высокоскоростное подключение.
Другой пример, когда действительно требуется низкая задержка, это некоторые виды видео, такие как видео-конференция, игры и подобное, где требуется передать не только заранее созданный поток.
Конвейерная передача HTTP – это способ отправки очередного запроса, уже ожидая ответ на предыдущий запрос. Это похоже на очередь к кассиру в супермаркете или банке. Вы не знаете, что за люди перед вами: быстрые клиенты или надоедливые персоны, которым потребуется бесконечное время, чтобы завершить обслуживание – блокировка начала очереди.
Безусловно вы можете тщательно выбирать очередь и в итоге выбрать ту, которую посчитаете правильной, а иногда вы можете создать свою собственную очередь, но, в конце концов, вы не сможете избежать принятия решения и однажды выбрав очередь, вы не можете её сменить.
Создание новой очереди связано с производительностью и расплатой ресурсами, и не может масштабироваться за пределы небольшого числа очередей. Для этой задачи нет идеального решения.
Даже сегодня, в 2014 году, большинство веб-браузеров на десктопах поставляются с отключенным конвейером HTTP по умолчанию.
Дополнительные сведения по этой проблеме могут быть найдены в баг-трекере Firefox под номером .
Как обычно, когда люди сталкиваются с ошибками, они объединяются для поиска путей обхода. Некоторые пути обхода искусные и полезные, некоторые просто ужасающие костыли.
Создание спрайтов – это термин, который часто используется для описания действия, когда вы собираете множество маленьких изображений в одно большое. Затем используете javascript или CSS для «нарезки» частей большого изображения для отображения маленьких картинок.
Сайт использует эту уловку для ускорения. Получение одного большого запроса значительно быстрее в HTTP 1.1, чем получение ста отдельных маленьких картинок.
Конечно, это имеет свои недостатки для тех страниц сайта, которым требуется лишь одна или две маленькие картинки. Это также выбрасывает все картинки из кэша одновременно, вместо того, чтобы, возможно, оставить часть наиболее используемых.
Встраивание – это ещё одна уловка для избежания отправки отдельных изображений, использование вместо этого data – URL, встроенный в CSS файл. Это имеет те же преимущества и недостатки, что и случай со спрайтами.
Icon1 { background: url(data:image/png;base64,) no-repeat; } .icon2 { background: url(data:image/png;base64,) no-repeat; }
Также как и в двух предыдущих случаях, на сегодняшний день большие сайты могут иметь и множество javascript файлов. Утилиты разработчиков позволяют объединить все эти файлы в один огромный ком, чтобы браузер получил один файл вместо множества маленьких. Большое число данных отправляется, тогда лишь как небольшой фрагмент реально требуется. Излишнее большое количество данных требуется перезагрузить, когда потребуется сделать изменение.
Раздражение разработчиков и принуждение к выполнению этих требований – это, конечно, «просто» боль для причастных людей и не отображено ни в каких графиках производительности.
Заключительный трюк, который я упомяну, применяемый владельцами сайтов для улучшения загрузки в браузерах, часто называют «шардингом». Это в основном означает рассредоточение вашего сервиса по максимально возможному числу различных хостов. На первый взгляд это звучит безумно, но на это есть простая причина!
Первоначально HTTP разрешал использовать клиенту максимум два TCP соединения на каждый хост. Таким образом, чтобы не нарушать спецификацию продвинутые сайты просто придумывали новые имена хостов и вуаля, вы можете получить большее число соединений для вашего сайта и сократить время загрузки страницы.
Со временем, это ограничение было убрано из спецификации и сегодня клиенты используют 6-8 соединений на хост, но по прежнему имеют ограничение, поэтому сайты продолжают технику увеличения числа соединений. По мере увеличения числа объектов, как я уже показал ранее, большое число соединений стало использоваться просто чтобы убедиться, что HTTP справляется хорошо и делает сайт быстрее. Не является необычным для сайтов использование более 50 или даже 100 соединений при помощи данной техники.
Ещё одна причина шардинга – это размещение изображений и подобных ресурсов на отдельных хостах, которые не используют cookie, поскольку cookie на сегодняшний день могут быть значительного размера. Используя хосты изображений без cookie вы можете увеличить производительность просто за счёт значительно меньших HTTP-запросов!
Рисунок ниже показывает как выглядит запись пакетов при просмотре одного топ веб-сайта Швеции и как запросы распределяются по нескольким хостам.
А не было бы лучше сделать усовершенствованный протокол? Который бы включал в себя следующее…
Инженерный совет Интернета (IETF) – это организация, которая разрабатывает и продвигает интернет стандарты. Большей частью на протокольном уровне. Они хорошо известны по серии RFC-документов, документирующих всё: от TCP, DNS, FTP до лучших практик, HTTP и множества вариантов протокола, которые нигде не были применены.
Внутри IETF есть выделенные «рабочие группы», которые сформированы вокруг небольшого круга задач для достижения цели. Они составляют «устав» из набора принципов и ограничений для достижения поставленной цели. Любой и каждый может присоединиться к дискуссии и разработке. Все, кто участвует и что-либо высказывает, имеют равные возможности и шансы для влияния на результат и все учитываются как люди и личности, без оглядки на то, в какой компании работает человек.
Рабочая группа HTTPbis была сформирована в течении лета 2007 года и должна была обновить спецификацию HTTP 1.1 - отсюда и суффикс «bis». Обсуждение в группе новой версии HTTP протокола по-настоящему началось в конце 2012 года. Работа над обновлением HTTP 1.1 была завершена в начале 2014 года.
Заключительное совещание для рабочей группа HTTPbis перед ожидаемым финальным выпуском версии спецификации http2, пройдёт в Нью-Йорке в начале июня 2014 года.
Некоторых больших игроков на поле HTTP не хватало в обсуждениях и встречах рабочей группы. Я не хочу называть какую-либо конкретную компанию или имя продукта здесь, но ясно, что на сегодняшний день некоторые действующие лица в Интернете, по всей видимости, уверены, что IETF сделает всё хорошо без привлечения этих компаний…
Теги: Добавить метки
В прошлом году в мире сетевых технологий произошло очень важное событие: была утверждена и стандартизирована новая версия протокола HTTP - HTTP/2. HTTP/2 уже поддерживается в популярных веб-сервераx -Apache и Nginx. Идёт работа по внедрению HTTP/2 и в IIS. Реализована поддержка и в большинстве современных браузеров.
Использование HTTP/2 за последнее время существенно расширилось.
По данным на середину 2015 года, процент сайтов и веб-сервисов, перешедших на HTTP/2, был невелик ― всего 0,4%. Совсем свежая статистика (январь 2016) свидетельствует о значительном росте: с 0,4 до 6,5%. Есть все основания полагать, что в ближайшее время темпы роста будут увеличиваться.
Задуматься о практических аспектах перехода на HTTP/2 стоит уже сейчас. Эту тему мы хотели бы затронуть в сегодняшней статье. Особенно нас будет интересовать проблема адаптации существующих приёмов оптимизации производительности веб-сайтов под специфику нового протокола.
Прежде чем перейти непосредственно к рассмотрению этого вопроса, обратимся к истории протокола HTTP/2 и кратко опишем основные нововведения, отличающие его от HTTP/1.1.
Протокол HTTP/2 обратно совместим с HTTP/1.1. Изменения, направленные на устранение узких мест и повышения производительности, во многом продолжают линию SPDY. Рассмотрим вкратце наиболее важные из них.
Возможно, это самое главное преимущество HTTP/2. В HTTP/1.1 для каждого запроса требуется устанавливать отдельное TCP-соединение. Мультиплексирование же позволяет браузеру выполнять множество запросов в рамках одного TCP-соединения:
В современных браузерах количество одновременных TCP-соединений ограничено. Поэтому страницы с большим количеством статического контента загружаются не так быстро, как хотелось бы.
В HTTP/2 благодаря мультиплексированию статические элементы загружаются параллельно, и благодаря этому существенно улучшается производительность.
Ещё одно нововведение HTTP/2 - это приоритизация. Каждому запросу можно назначить приоритет.
Существует два подхода к назначению приоритетов: на основе веса и на основе зависимостей.
В первом подходе каждый поток получает определённый вес. Потом на основе веса сервер распределяет нагрузку между потоками. Такой подход уже использовался в протоколе SPDY.
Второй метод, являющийся основным в HTTP/2, заключается в следующем: браузер просит сервер загружать определённые элементы контента в первую очередь. Например, сначала браузер может попросить сервер сначала загрузить CSS-файлы или JavaScript, а уже потом - HTML или изображения.
В HTTP/2 приоритизация является не обязательным, а желательным методом. Однако мультиплексирование без неё работать должным образом не будет. Скорость загрузки может быть даже ниже, чем HTTP/1.1. Ресурсы с более низким приоритетом будут занимать полосу, что приведёт снижению производительности.
Современная веб-страница состоит из множества элементов: изображения, JS, CSS и другие. В запросе на загрузку каждого из этих элементов браузер передаёт HTTP-заголовок. Отправляя запрошенные элементы, сервер также добавляет к ним заголовок. Всё это сопряжено с излишним расходованием ресурсов.
В HTTP/2 заголовки передаются в сжатом виде. Благодаря этому уменьшается количество информации, которой обмениваются между собой сервер и браузер. Вместо алгоритмов gzip/deflate используется HPACK . Это снижает уязвимость к атакам типа BREACH .
Одним из важнейших требований протокола SPDY является обязательное шифрование (HTTPS) соединения между клиентом и сервером. В HTTP/2 оно обязательного характера не имеет. Однако разработчики браузеров приняли решение внедрить новый протокол только для TLS(HTTPS)-соединений. Поэтому тем, кто задумывается о переходе на HTTP/2, нужно сначала перейти на HTTPS.
Это нужно не только для HTTP/2. В поиске Google использование безопасного соединения является одним из критериев ранжирования . Браузеры (см. и ) скоро будут помечать сайты, не поддерживающие https, как «небезопасные». Добавим также, что многие возможности HTML5 ― например, геолокация ― без безопасного соединения будут недоступны .
Приведём краткие инструкции по включению и базовой настройке HTTP/2 в Nginx и Apache. Как уже было сказано выше, большинство современных браузеров работают с HTTP/2 только через TLS, поэтому в конфигурации вашего веб-сервера должны быть прописаны соответствующие настройки.
Поддержка HTTP/2 реализована только в новейших версиях Nginx (1.9.5 и выше). Если у вас установлена другая версия, вам потребуется обновить её.
После этого откройте конфигурационный файл /etc/nginx/nginx.conf и найдите в секции server следующую строку:
Listen 443 ssl;
и замените её на:
Listen 443 ssl http2;
Сохраните внесённые изменения и перезагрузите Nginx:
$ sudo service nginx reload
В Apache HTTP/2 поддерживается только в версиях 2.4.17 и выше. Если у вас установлена более ранняя версия, выполните обновление и подключите модуль mod_http2 . После этого добавьте в конфигурационный файл следующие строки:
# for a https server Protocols h2 http/1.1 # for a http server Protocols h2c http/1.1
После этого перезапустите Apache. Вот и всё - для базовой настройки этого вполне достаточно.
HTTP/2 обратно совместим с HTTP/1.1. Поэтому вы в принципе можете не предпринимать никаких действий: работе вашего сервиса ничего не угрожает.
Но по мере перехода популярных веб-серверов и веб-браузеров на HTTP/2 вы увидите, что ваш сайт, который когда-то был оптимизирован для увеличения скорости загрузки страниц и повышения производительности, уже работает не так быстро, как раньше.
Многие способы оптимизации, успешно используемые в HTTP/1.1, в HTTP/2 работать не будут. Некоторые из них потребуется модифицировать, а от некоторых ― отказаться вообще. Рассмотрим этот вопрос более подробно.
В HTTP/1.1 было удобнее загрузить одно большое изображение, чем делать множество запросов и загружать много маленьких. Это обусловлено тем, что запросы ставятся в очередь друг за другом. Самый распространённый способ увеличения скорости загрузки заключался в объединении множественных небольших изображений в спрайт-файл .
Спрайт возвращался в ответ на единственный запрос. Даже если пользователь заходил на страницу, на которой находится всего одно небольшое изображение, нужно было загрузить весь спрайт.
В HTTP/2 c его мультиплексированием таких проблем нет, однако использование спрайтов в определённых ситуациях может оказаться полезным. Объединение нескольких изображений в спрайт (особенно если все эти изображения находятся на одной странице) помогает улучшить сжатие и таким образом снизить общий объём загружаемых данных.
Ещё один популярный способ решения проблемы множественных HTTP-запросов в HTTP/1.1 ― встраивание изображений с использованием Data URI . Это существенно увеличивает в размере таблицу стилей.
Если одновременно со встраиванием изображений для оптимизации используется ещё и конкатенация JS и CSS, пользователю скорее всего придётся загрузить весь соответствующий код, даже если он не будет посещать страницу с этими изображениями.
В HTTP/2 такая практика скорее ухудшит, а не улучшит производительность.
Для оптимизации работы сайтов часто используется конкатенация небольших CSS- и JS-файлов. Много маленьких файлов объединяются в один большой. Таким образом удаётся обойти лимит на количество HTTP-запросов.
Однако при использовании конкатенации может возникнуть та же проблема, что и со спрайтами: зайдя на какую-то одну страницу сайта, пользователь загрузит все используемые на нём СSS- и JS-файлы (при этом очень вероятно, что большинство из этих файлов ему никогда не понадобятся). Конечно, можно тщательно отбирать файлы для каждой страницы сайта, но это будет занимать слишком много времени.
Ещё одна сложность заключается в том, что все элементы конкатенированного файла нужно вычищать из кэша одновременно. Невозможно сделать так, чтобы для одних элементов была выставлена одна дата истечения срока действия, а для других (которые к тому же и используются гораздо чаще) - другая. Если изменить хотя бы одну строку в CSS - срок действия истечёт сразу у всех элементов.
Стоит ли пользоваться конкатенацией в HTTP/2? Если HTTP-запросы не требуют существенных затрат ресурсов, то без неё вполне можно обойтись. Загрузка множества небольших файлов стилей никакой проблемы не составит. Не будет и трудностей с истечением сроков действия и кэшированием.
В HTTP/1.1 имеется ограничение на количество открытых соединений. Чтобы обойти это ограничение, приходится загружать статические ресурсы с нескольких поддоменов одного домена. Такой приём называется доменным шардированием; он часто используется, например, для страниц с большим количеством изображений. Это помогает увеличить скорость загрузки, но вместе с тем и создаёт дополнительные проблемы .
С переходом HTTP/2 необходимость в доменном шардировании отпадает. Вы можете запросить столько ресурсов, сколько вам требуется. Более того, в случае с HTTP/2 шардирование не улучшит производительность, а приведёт скорее к противоположному эффекту, так как создаст дополнительные TCP-соединения и будет мешать приоритизации.
Когда планировать переход на HTTP/2? Однозначного ответа на этот вопрос нет и быть не может. Дадим, однако, одну подсказку: регулярно просматривайте логи посещаемости вашего сервиса. Когда вы увидите, что большая часть посетителей используют поддерживающие HTTP/2 браузеры - можно переходить. На текущий момент поддержка HTTP/2 реализована в Chrome (в том числе и в мобильной версии для Android), Firefox, Opera, Edge, Safari.
При планировании перехода следует учитывать и особенности вашего проекта. Если у вас много пользователей, которые приходят к вам с мобильных устройств, то это означает, что вам желательно перейти на HTTP/2 как можно скорее. На смартфонах и планшетах преимущества нового протокола будут особенно очевидными. Однако и здесь нужно учитывать множество нюансов: например, во многих регионах мира до сих пор много пользователей браузера Opera Mini, а он HTTP/2 пока что не поддерживает.
Если вы планируете запускать новый веб-сервис - задумайтесь о перспективе перехода на HTTP/2. Конечно, вам ещё придётся использовать HTTP/1.1 в течение какого-то времени, но уже сейчас вы можете принять меры по оптимизации, которые облегчат вам жизнь в будущем.
В заключение приведём для заинтересованных читателей несколько полезных ссылок