Триколор 

Что такое http 2. Что такое HTTP. Встраивание изображений с помощью Data URI

Группа экспертов W3C разработала новый протокол http/2, который ускоряет загрузку сайтов. Разбираемся, как это повлияет на сайтостроительство, SEO и другие аспекты.

Что такое http/2 и зачем он нужен

Протокол http/1.1 используется с 1999 года и со временем обрел одну существенную проблему. Современные сайты в отличие от того, что было распространено в 1999-м году, используют множество различных элементов: скрипты на Javascript, стили на CSS, иногда еще и flash-анимацию. При передаче всего этого хозяйства между браузером и сервером создаются несколько соединений.

Протокол http/2 существенно ускоряет открытие сайтов за счет следующих особенностей:

    Соединения: несколько запросов могут быть отправлены через одно TCP-соединение, и ответы могут быть получены в любом порядке, таким образом отпадает необходимость в том, чтобы держать несколько TCP-соединений.

    Приоритеты потоков: клиент может задавать серверу приоритеты — какого типа ресурсы для него более важны, чем другие.

    Сжатие заголовка: размер заголовка http может быть сокращен.

    Push-отправка данных со стороны сервера: сервер может отправлять клиенту данные, которые тот еще не запрашивал, например, на основании данных о том, какую страницу скорее всего откроет пользователь следующей.

Разработка протокола http/2 основывалась на другом протоколе SPDY, который был разработан Google, но компания Google уже объявила о том, что откажется от дальнейшей поддержки SPDY в пользу более многообещающего http/2.

Действительно ли http/2 работает быстрее?

Специалисты из HttpWatch провели несколько тестов и выявили серьезное ускорение от использования http/2.

Как видите, скорость загрузки выросла на 23%. Эксперты HttpWatch также отмечают, что технология пока не до конца оптимизирована, и ожидают реальное ускорение в районе 30%.

Однако не все эксперименты столь однозначны. На Хабре был описан эксперимент , поставленный командой Яндекс.Почты.

Тестировался протокол SPDY, не http/2, но напомним, что http/2 разрабатывался на основе SPDY и он очень близок к нему в плане используемых методов.

Команда Яндекс.Почты, протестировав SPDY, на части своих реальных пользователей установила, что среднее время загрузки изменилось всего лишь на 0,6%, и не превысило статистической погрешности.

Однако специалисты Яндекс.Почты обнаружили тем не менее положительный момент от использования SPDY. Поскольку число соединений с серверами уменьшилось (это ключевая особенность SPDY и http/2), то нагрузка на сервера заметно сократилась.

Команда облачного сервиса по ускорению и защите сайтов Айри.рф провела собственное тестирование, насколько HTTP/2.0 может быть полезен для ускорения сайтов. Для сайтов средней посещаемости (до 10 000 посетителей в сутки) дополнительно к уже примененным мерам по ускорению был включен HTTPS и HTTP/2.0. По результатам за месяц среднее время загрузки сайтов контрольной группы сократилось на 13-20% (данные собирались от реальных пользователей из браузера при помощи Performance Timing API). И это уже после стандартных мероприятий по оптимизации скорости загрузки — сжатию, кэшированию, объединению файлов и оптимизации изображений.

Почему так важно ускорение загрузки страниц сайта?

После показанных HttpWatch результатов в пору задуматься: «Ок, выиграли там что-то около трех десятых секунд на одной странице, что это даст мне как бизнесу?»

Оказывается, очень много. Вас вряд ли удивит тот факт, что пользователи часто уходят с сайта не дождавшись его загрузки до конца. Насколько сильно это влияет на бизнес? Специалисты Amazon подсчитали, что если время загрузки сайта Amazon по каким-то причинам увеличится всего лишь на одну секунду, это обойдется компании в 1,6 млрд. долларов недополученного дохода от потерянных продаж.

Специалисты Google также провели свои расчеты и убедились в том, что если время отклика поиска Google увеличится всего лишь на 0,4 секунды, то компания потеряет 8 миллионов показов страниц поиска в день! Представляете, сколько дохода недополучит компания от рекламы в поиске?

Возможно, мы не управляем проектами уровня Google или Amazon, но факт остается фактом — чем быстрее загружается сайт, тем больше дохода вы получаете.

Http/2 и SEO

А как с точки зрения SEO? Помогает ли http/2 ранжированию в поиске, а может быть вредит?

Конечно инженеры поисковых систем стараются держать в глубокой тайне алгоритмы ранжирования, чтобы у нас не было возможности создать «идеальную страницу» под какой-то поисковый запрос.

Джон Мюллер, аналитик из команды Google Webmaster Trends, в своем блоге написал, что наличие на сайте поддержки http/2 не является напрямую ранжирующим фактором в Google. В то же время скорость загрузки сама по себе является значимым фактором ранжирования, поэтому имеет смысл начать использовать http/2 для целей SEO-продвижения.

Он добавил, что само по себе ускорение работы сайта должно положительно влиять на ранжирование за счет поведенческих факторов. То есть у более быстрой страницы будет меньше процент отказов, скорее всего больше пользователей что-то сделают на такой странице, и таким образом будут влиять на повышение ранга страницы в поиске.

Однако Джон Мюллер также сообщил, что Googlebot скоро начнет поддерживать http/2, и кто знает, может быть в будущем наличие http/2 на сайте и станет ранжирующим фактором. Ведь поисковики постоянно меняют свои алгоритмы.

Введение

Протокол передачи гипертекста (HTTP) – простой, ограниченный и, в конечном счете, скучный протокол уровня приложений, который формирует основу Всемирной паутины. HTTP позволяет получать доступ к сетевым ресурсам, доступным в киберпространстве. А HTTP/2 – это следующая ступень данного протокола. И сегодня мы подробно рассмотрим все то, что касается протокола HTTP/2.

В этой статье мы рассмотрим следующие ключевые аспекты HTTP/2:

  • Что такое HTTP/2
  • Цель создания HTTP/2
  • Что было не так с HTTP1.1?
  • Качественные новшества HTTP/2
  • Как работает HTTP/2 с HTTPS
  • Особенности сходства между HTTP1.x, SPDY и HTTP/2
  • Основные преимущества HTTP/2
  • Поддержка и доступность браузерами HTTP/2
  • Как можно начать использовать HTTP/2

Что такое HTTP/2?

HTTP был первоначально предложен Тимом Бернерс-Ли, пионером Всемирной паутины, который разработал протокол приложения с такой простотой, чтобы была возможность выполнять высокоуровневые функции обмена данными между веб-серверами и клиентами.

Первая документально подтвержденная версия HTTP была выпущена в 1991 году как HTTP0.9, которая позже привела к официальному внедрению HTTP1.0 в 1996 году. Версия HTTP1.1 была в 1997 году и с тех пор у нее было мало итерационных улучшений.

В феврале 2015 года рабочая группа HTTP Инженерного совета Интернета (IETF) пересмотрела протокол HTTP и разработала вторую основную версию протокола приложения в виде HTTP/2. В мае 2015 года спецификация внедрения HTTP/2 официально была стандартизирована в ответ на HTTP-совместимый протокол SPDY от Google.

Что такое протокол?

Протокол представляет собой набор правил, которые регулируют механизмы обмена данными между клиентами (например, веб-браузеры, используемые пользователями Интернета для запроса информации) и серверы (машины, содержащие запрошенную информацию).

Протоколы обычно состоят из трех основных частей: Заголовок, Полезная нагрузка и Футер. Заголовок содержит различную информацию, например, адреса источника и получателя, размер и тип, и идет перед Полезной нагрузкой. Полезная нагрузка – это фактическая (основная) информация, передаваемая с использованием протокола. Футер следует за Полезной нагрузкой и работает как контрольное поле для маршрутизации запросов клиент-сервер для предполагаемых получателей и вместе с Заголовком убеждается, что передача данных проходит без ошибок.

Такая система похожа на почтовую службу. Письмо (Полезная нагрузка) вставляется в конверт (Заголовок) с адресом получателя, записанным на нем, запечатывается клеем и подтверждается почтовой маркой (Футер) перед отправкой. За исключением того, что передача цифровой информации в виде двоичной записи (0 и 1) не так проста и требует введения нового измерения в ответ на повышение технологических достижений, возникающих при взрывном росте использования Интернета.

Протокол HTTP первоначально состоял из основных команд: GET (для получения информации с сервера) и POST (для доставки запрошенной информации клиенту). Этот простой и, по-видимому, скучный набор из нескольких команд для GET-данных и POST-ответов по существу сформировал основу для построения других сетевых протоколов. Протокол является еще одним шагом для улучшения пользовательского опыта и эффективности, что требует внедрения протокола HTTP/2 для улучшения работы в Интернете.

Цель создания HTTP/2

С момента своего создания в начале 1990-х годов, HTTP подвергался нескольким крупным капитальным ремонтам. Самая последняя версия HTTP1.1 уже более 15 лет обслуживает Интернет пространство. Веб-страницы в текущую эпоху динамических обновлений информации, ресурсоемкие форматы мультимедийных материалов и чрезмерное стремление к производительности в Интернете оттеснили старые технологии протоколов в категорию устаревших. Эти тенденции требуют значительных изменений HTTP/2 для улучшения Интернета.

Основная цель исследований и разработок для новой версии HTTP базируется на трех качествах, редко связанных с одним сетевым протоколом без необходимости создания дополнительных сетевых технологий – простота, высокая производительность и надежность. Эти цели достигаются за счет внедрения возможностей, которые уменьшают задержку в обработке запросов браузером с такими методами, как мультиплексирование, сжатие, приоритизация запроса и технология сервер push. Такие механизмы, как управление потоком, обновление и обработка ошибок, работают в качестве усовершенствования протокола HTTP для разработчиков, что позволяет обеспечивать высокую производительность и устойчивость веб-приложений. Коллективная система позволяет серверам эффективно реагировать на большее количество контента, чем первоначально запрашивалось клиентами, ограничивая возможности пользователя создавать непрерывные запросы информации до тех пор, пока веб-сайт не будет полностью загружен в веб-браузер. Например, возможность Push-сервера с помощью HTTP/2 позволяет серверам отвечать полным содержимым страницы, кроме информации, которая уже доступна в кеше браузера. Эффективное сжатие файлов заголовков HTTP минимизирует накладные расходы протокола для повышения производительности при каждом запросе браузера и ответе сервера.

Изменения HTTP/2 предназначены для обеспечения совместимости и сочетаемости с HTTP1.1. Ожидается, что преимущества HTTP/2 со временем будут только возрастать, и его способность решать проблемы, связанные с производительностью в реальном сравнении с HTTP1.1, значительно повлияет на его эволюцию в долгосрочной перспективе.

Важно отметить, что новая версия HTTP является расширением для своего предшественника и в ближайшее время не ожидается замены HTTP1.1. Реализация HTTP/2 не будет включать автоматическую поддержку всех типов шифрования, доступных с помощью HTTP1.1, но в ближайшем будущем определенно откроет двери для лучших альтернатив или дополнительных обновлений совместимости с шифрованием. Однако сравнение характеристик на уровне HTTP/2 vs HTTP1 и SPDY vs HTTP/2 определяет только последний (по дате) протокол в качестве победителя с точки зрения производительности, безопасности и надежности.

Что было не так с HTTP1.1?

HTTP1.1 ограничивался обработкой только одного запроса на одно TCP-соединение, заставляя браузеры использовать несколько TCP-соединений для одновременной обработки нескольких запросов. Однако использование слишком большого количества параллельных TCP-соединений приводит к перегрузке TCP, что приводит к несправедливой оккупации сетевых ресурсов. Веб-браузеры, использующие несколько подключений для обработки дополнительных запросов, занимают большую долю доступных сетевых ресурсов, следовательно, они снижают производительность сети для других пользователей.

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

Естественно, это вынуждало использовать такие методы, как клонирование домена, конкатенация, вложение данных и написание спрайтов. Неэффективное использование базовых TCP-соединений с HTTP1.1 также приводит к плохой приоритизации ресурсов, что приводит к возрастающему снижению производительности по мере роста веб-приложений с точки зрения сложности, функциональности и объема.

Веб значительно расширился, несмотря на устаревшие сетевые технологии на базе HTTP. Основные качества HTTP1.1, разработанные более десяти лет назад, открыли двери для злоупотреблений.

Например, взлом куки позволяет киберпреступникам повторно использовать предыдущий рабочий сеанс для компрометации паролей учетных записей, поскольку HTTP1.1 не предоставляет никаких средств для идентификации данных сеанса. Хотя аналогичные проблемы безопасности будут продолжать преследовать HTTP/2, новый протокол приложения разработан с лучшими возможностями безопасности, такими как улучшенная реализация новых функций TLS.

Качественные новшества HTTP/2

Мультиплексирован ие

Двунаправленная последовательность фреймов текстового формата, передаваемых по протоколу HTTP/2, обмениваемых между сервером и клиентом, называется «потоками». Ранее итерации протокола HTTP были способны передавать только один поток одновременно с некоторой временной задержкой между каждой передачей потока.
Получение гигабайтов медиаконтента через отдельные потоки, отправленные один за другим, неэффективно и ресурсоемко. Изменения HTTP/2 помогли создать новый двоичный структурный слой для решения этих проблем.
Этот уровень позволяет клиенту и серверу распределять полезную нагрузку HTTP на небольшую, независимую и управляемую чередующуюся последовательность фреймов. Затем эта информация снова собирается на другом конце.

Форматы двоичных фреймов позволяют осуществлять обмен несколькими одновременными открытыми независимыми двунаправленными последовательностями без задержки между последовательными потоками.

Этот подход представляет собой ряд преимуществ HTTP/2, описанных ниже:

  • Запросы и ответ параллельного мультиплексирования не блокируют друг друга.
  • Единственное TCP-соединение используется для обеспечения эффективного использования сетевых ресурсов, несмотря на передачу нескольких потоков данных.
  • Нет необходимости применять ненужные оптимизационные хаки, такие как спрайты изображений, конкатенация и дублирование доменов, — что может негативно влиять на другие области производительности сети.
  • Снижение задержек, более быстрая производительность Интернета, лучшее ранжирование в поисковых системах.
  • Сокращение OpEx (операционные затраты) и CapEx (капитальные расходы) при запуске сетевых и IT-ресурсов.

Благодаря этой возможности пакеты данных из нескольких потоков по существу смешиваются и передаются по одному TCP-соединению. Затем эти пакеты разбиваются на принимающей стороне и представляются в виде отдельных потоков данных. Передача нескольких параллельных запросов одновременно с использованием HTTP версии 1.1 или более ранней версии требовала нескольких TCP-соединений, что по своей сути затрудняет общую производительность сети, несмотря на более высокую передачу потоков данных. HTTP/2 обеспечивает более низкую задержку, более высокую производительность, лучшие рейтинги SEO.

Сервер Push

Эта возможность позволяет серверу отправлять дополнительную кэшируемую информацию клиенту, которая не запрашивается, но ожидается в будущих запросах. Например, если клиент запрашивает ресурс X, и понятно, что ресурс Y ссылается на запрошенный файл, сервер может решить отправить и Y вместе с X вместо того, чтобы ждать соответствующего запроса клиента.

Клиент (браузер) помещает отправленный ресурс Y в свой кеш для будущего использования. Этот механизм сохраняет обратную связь с запросом и уменьшает задержку сети. Server Push был первоначально представлен в протоколе SPDY от Google. Идентификаторы потоков, содержащие псевдо-заголовки, такие как:path позволяют серверу инициировать Push для информации, которая должна быть кэшируемой. Клиент должен явно разрешить серверу использовать кэшируемые ресурсы с помощью HTTP/2 или завершать отправляемые потоки с помощью определенного идентификатора потока.

Другие изменения HTTP/2, такие как Server Push, проактивно обновляют или аннулируют кеш клиента и также называются «Cache Push». Долгосрочные последствия зависят от способности серверов идентифицировать возможные push-ные ресурсы, которые клиенту фактически не нужны.
Реализация HTTP/2 обеспечивает значительную производительность для перенаправленных ресурсов, а также другие преимущества HTTP/2, описанные ниже:

  • Клиент сохраняет вложенные ресурсы в кеш.
  • Клиент может повторно использовать эти кэшированные ресурсы на разных страницах.
  • Сервер может мультиплексировать перенаправленные ресурсы вместе с первоначально запрошенной информацией в рамках одного и того же TCP-соединения.
  • Сервер может назначать приоритеты перенаправленным ресурсам –ключевому отличию в производительности по протоколу HTTP/2 и HTTP1.
  • Клиент может отказаться от перенаправленных ресурсов для поддержания эффективного хранилища кэшированных ресурсов или полностью отключить Server Push.
  • Клиент также может одновременно ограничить количество одновременных мультиплексированных потоков.

Подобные возможности Push уже доступны с субоптимальными технологиями, такими как Встраивание ответов сервера, тогда как Server Push представляет собой решение на уровне протокола, чтобы избежать сложностей с оптимизационными хаками, вторичными по отношению к базовым возможностям самого протокола приложения.

HTTP/2 мультиплексирует и приоритизирует поток встраиваемых данных, чтобы обеспечить лучшую производительность передачи, как видно из других потоков данных запроса-ответа. В качестве встроенного механизма безопасности сервер должен иметь право направить ресурсы заранее.

Бинарные протоколы

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

Хотя, вероятно, потребуется больше усилий для чтения бинарных текстовых команд по сравнению с текстовыми командами, для сети проще создавать и анализировать фреймы, доступные в двоичном формате. Фактическая семантика остается неизменной.

Браузеры, использующие реализацию HTTP/2, будут преобразовывать одни и те же текстовые команды в двоичные файлы перед передачей по сети. Бинарный структурный слой не обратно совместим с клиентами и серверами HTTP1.x и является ключевым фактором, обеспечивающим значительные преимущества по производительности по сравнению с SPDY и HTTP1.x. Использование двоичных команд позволяют обеспечивать ключевые бизнес-преимущества для интернет-компаний и онлайн-бизнеса:

  • Низкие накладные расходы при анализе данных
  • Меньше подвержены ошибкам
  • Более легкое сетевое пространство
  • Эффективное использование сетевых ресурсов
  • Устранение проблем безопасности, связанных с текстовой природой HTTP1.x, таких как атаки на перехват ответа
  • Другие возможности HTTP/2, включая сжатие, мультиплексирование, определение приоритетов, управление потоком и эффективная обработка TLS.
  • Компактное представление команд для упрощения обработки и реализации.
  • Эффективное и надежное с точки зрения обработки данных между клиентом и сервером.
  • Снижение задержек сети и повышение пропускной способности.

Оптимизация потока HTTP/2

Реализация позволяет клиенту предоставлять предпочтение конкретным потокам данных. Хотя сервер не обязан следовать этим инструкциям от клиента, этот механизм позволяет серверу оптимизировать распределение сетевых ресурсов на основе требований конечного пользователя. Приоритизация потоков работает с зависимостями и весом, назначенными каждому потоку. Хотя все потоки по своей сути зависят друг от друга, за исключением того, что зависимым потокам также назначается вес между 1 и 256. Детали для механизмов приоритизации потока все еще обсуждаются.

Однако в реальном мире сервер редко контролирует ресурсы, такие как CPU и подключение к базам данных. Сама сложность реализации не позволяет серверам выполнять запросы приоритета потока. Исследования и разработки в этой области особенно важны для долгосрочного успеха HTTP/2, поскольку протокол способен обрабатывать несколько потоков данных с помощью одного TCP-соединения. Эта возможность может привести к одновременному приходу запросов сервера, которые фактически отличаются с точки зрения приоритета с позиции конечного пользователя. Удержание запросов обработки потока данных на случайной основе подрывает эффективность и опыт конечного пользователя, обещанный изменениями HTTP/2.

В то же время интеллектуальный и широко принятый механизм приоритизации потока представляет преимущества HTTP/2, объясняемые следующим образом:

  • Эффективное использование сетевых ресурсов.
  • Сокращение времени на доставку первичных запросов контента.
  • Улучшенная скорость загрузки страниц и конечный пользовательский интерфейс.
  • Оптимизированная передача данных между клиентом и сервером.
  • Снижение негативного влияния проблем с задержкой в ​​сети.

Сжатие заголовка с отслеживанием состояния

Обеспечение высокого качества пользовательского опыта нужно сайтам, которые насищены контентом и графикой.

Протокол HTTP не зависит от состояния, что означает, что каждый запрос клиента должен содержать столько информации, сколько серверу необходимо для выполнения нужной операции. Этот механизм заставляет потоки данных переносить несколько повторяющихся фреймов информации, поэтому сервер не должен хранить информацию из предыдущих клиентских запросов.

В случае веб-сайтов, обслуживающих большой мультимедийный контент, клиенты используют несколько почти идентичных фреймов заголовка, что приводит к задержке и ненужному потреблению ограниченного сетевого ресурса. Приоритетное сочетание потоков данных не может достичь желаемых стандартов производительности параллельности без оптимизации этого механизма.

Реализация HTTP/2 решает эти проблемы с возможностью сжатия большого количества избыточных фреймов заголовка. Она использует спецификацию HPACK как простой и безопасный подход к сжатию заголовков. И клиент и сервер поддерживают список заголовков, используемых в предыдущих запросах клиент-сервер.

HPACK сжимает индивидуальное значение каждого заголовка до его передачи на сервер, а затем просматривает закодированную информацию в списке ранее перенесенных значений заголовка для восстановления полной информации заголовка. Сжатие заголовка HPACK для реализации протокола HTTP/2 дает огромные преимущества в производительности, включая некоторые преимущества HTTP/2, описанные ниже:

  • Эффективная приоритизация потока.
  • Эффективное использование механизмов мультиплексирования.
  • Сокращение накладных ресурсов – одна из самых ранних проблем в дебатах по HTTP/2 vs HTTP1 и HTTP/2 vs
  • Кодирует большие заголовки, а также обычно используемые заголовки, что исключает необходимость отправки всего фрейма заголовка. Индивидуальный размер передачи каждого потока данных быстро сокращается.
  • Не уязвим для атак безопасности, таких как CRIME, использующих потоки данных со сжатыми заголовками.

Сходство HTTP/2 с HTTP1.x и SPDY

Основная семантика HTTP, включая коды состояния HTTP, URI, методологии и файлы заголовков остаются такими же в последней версии HTTP/2. HTTP/2 основан на SPDY, альтернативе Google для HTTP1.x. Реальные различия заключаются в механизмах, используемых для обработки запросов клиент-сервер. Следующая таблица идентифицирует несколько областей сходства и улучшений среди HTTP1.x, SPDY и HTTP/2:

HTTP1.x SPDY HTTP2
SSL требуется SSL не требуется, но рекомендуется
Медленное шифрование Быстрое шифрование Даже более быстрое шифрование
Один клиент-серверный запрос на одно TCP-соединение Несколько запросов клиент-сервер на одно TCP-соединение. Происходит на одном хосте одновременно Мультиплексирование с несколькими хостами. Происходит на нескольких хостах одновременно
Нет сжатия заголовка Включено сжатие заголовка Сжатие заголовков с использованием улучшенных алгоритмов, которые повышают производительность, а также безопасность
Нет приоритета потока Приоритет потока включен Улучшены механизмы определения приоритетов потока

Как работает HTTP/2 с HTTPS

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

Поддержка браузерами HTTP/2 включает в себя HTTPS-шифрование и фактически дополняет общую производительность безопасности развертываний HTTPS. Такие функции, как меньшее количество рукопожатий TLS, низкое потребление ресурсов на стороне клиента и сервера и улучшенные возможности повторного использования существующих веб-сеансов при устранении уязвимостей, связанных с HTTP1.x, представляют собой HTTP/2 в качестве ключевого средства защиты цифровой связи в уязвимых сетевых средах.

HTTPS не ограничивается крупными организациями, и кибербезопасность столь же ценна для владельцев онлайн-бизнеса, обычных блоггеров, торговцев электронной коммерцией и даже пользователей социальных сетей. HTTP/2 по своей сути требует последнюю, самую безопасную версию TLS и все онлайн-сообщества, владельцы бизнеса и веб-мастера должны обеспечить наличие на своих веб-сайтах использование HTTPS по умолчанию.

Для включения HTTPS нужно: купить, активировать и установить сертификат безопасности на сервер и, наконец, обновление контента веб-сайта для использования HTTPS. Детальнее по установке HTTPS читайте .

Основные преимущества HTTP/2

Интернет-индустрии пришлось заменить стареющий HTTP1.x альтернативными перспективными улучшениями для обычного пользователя. Переход от HTTP1.x к HTTP/2 почти полностью основан на максимизации потенциала технологических достижений для удовлетворения этих ожиданий.

С точки зрения интернет-бизнеса и интернет-потребителей, Интернет становится все медленнее, поскольку он заполняется растущими объемами нерелевантного мультимедийного контента.

Чтобы онлайн-бизнес мог быстро достичь своего целевого рынка и чтобы интернет-пользователи быстрее получали доступ к более эффективному веб-контенту, изменения HTTP/2 разрабатываются для повышения эффективности передачи данных на клиент-сервер. И, кроме того, Интернет более ситуативен, чем когда-либо.

Скорость Интернета не одинакова во всех сетях и географических точках. Мобильная пользовательская база все больше требует бесшовного высокопроизводительного Интернета во всех форм-факторах устройства, даже если перегруженные мобильные сети не могут конкурировать с высокоскоростным широкополосным доступом в Интернет. Полностью обновленный и переработанный механизм передачи данных и передачи данных в виде HTTP/2 стал жизнеспособным решением со следующими существенными преимуществами.

Веб-производительность

Способность протокола отправлять и получать больше данных на клиент-серверный цикл связи – это реальное, реализуемое и практичное преимущество HTTP/2 с точки зрения производительности.

Такие технологии, как мультиплексирование, создают дополнительное пространство для переноса и передачи большего количества данных одновременно.

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

Производительность мобильных веб-сайтов

Миллионы пользователей Интернета получают доступ к Интернету со своих мобильных устройств в качестве основного пути в кибер-мир. HTTP/2 разработан в контексте современных тенденций использования Интернета. Возможности, такие как мультиплексирование и сжатие заголовков, хорошо работают для уменьшения задержек при доступе к интернет-сервисам в мобильных сетях передачи данных, обеспечивающих ограниченную пропускную способность для каждого пользователя.

HTTP/2 оптимизирует веб-интерфейс для мобильных пользователей с высокой производительностью и безопасностью, которые ранее были привязаны только к использованию ПК.

Дешевый Интернет

Повышенная пропускная способность HTTP/2 и повышение эффективности передачи данных позволят операторам телекоммуникационных услуг сократить эксплуатационные расходы при сохранении стандартов высокоскоростного интернета. Сокращение OpEx будет стимулировать поставщиков услуг к снижению цен на рынке и внедрению высокоскоростных уровней обслуживания для существующей модели ценообразования.

Экспансивный охват

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

Улучшенный мобильный опыт

Прогрессивные онлайн-компании следуют стратегии Mobile-First, чтобы покрывать спрос быстрорастущей мобильной базы пользователей. Ограничения на аппаратное обеспечение мобильных устройств, пожалуй, являются самым большим ограничением для мобильного веб-сайта, на которое влияет длительное время обработки запросов браузера. HTTP/2 сокращает время загрузки и задержки мобильной сети до управляемых уровней.

Улучшение использования технологий

Потребление ресурсов значительно увеличилось для запросов браузеров и обработчиков серверов при доставке мультимедийных ресурсов и сложных веб-проектов. Такие функции, как сжатие заголовков, серверная нагрузка, потоковые зависимости и мультиплексирование, способствуют улучшению использования сети в качестве ключевого преимущества HTTP/2.

Безопасность

Преимущества HTTP/2 выходят за рамки производительности, поскольку алгоритм HPACK позволяет HTTP/2 обойти распространенные угрозы безопасности, ориентированные на текстовые протоколы прикладного уровня. HTTP/2 содержит команды в двоичном формате и разрешает сжатие метаданных заголовка HTTP в соответствии с подходом «Безопасность по умолчанию» для защиты конфиденциальных данных, передаваемых между клиентами и серверами. Протокол также может похвастаться полной поддержкой шифрования и требует улучшенной версии Transport Layer Security (TLS1.2) для лучшей защиты данных.

Новаторство

HTTP/2 воплощает инновации и концепцию высокопроизводительной сети. HTTP/2 подкрепляет кибер-мир, как мы его знаем сегодня, а изменения HTTP/2 в основном основаны на протоколе SPDY от Google, который совершил гигантский скачок по сравнению со старыми версиями HTTP1.x и почти полностью заменит SPDY, а также все предыдущие HTTP-итерации в ближайшем будущем. HTTP/2 – это самое большое, самое инновационное изменение в семействе протоколов с 1999 года.

Преимущество HTTP/2 для SEO

SEO-маркетинг находится где-то между искусством и наукой. Интернет-компании должны соответствующим образом развивать свою маркетинговую тактику. Более разумные инвестиции в виде внедрения тщательно разработанных веб-сайтов, которые не просто оптимизированы для скорости, но созданы для обеспечения превосходной производительности, безопасности и пользовательского опыта с нуля. Эти атрибуты позволяют пользователям находить наиболее релевантные ответы при поисковых запросах.

Поддержка браузерами

Пользователям Интернета не нужно беспокоиться о настройке своих настольных и мобильных веб-браузеров для поддержки HTTP/2. Google Chrome и Firefox уже много лет поддерживают эту технологию, и Apple добавила поддержку в браузер Safari в 2014 году. Для Internet Explorer нужна версия ОС не ниже Windows 8 для поддержки последнего протокола.

Крупные мобильные веб-браузеры, в том числе Android с Android-браузером, Chrome для Android и iOS, а также Safari в iOS 8 и выше поддерживают HTTP/2 для мобильного доступа в Интернет. Пользователям Интернета рекомендуется установить последние стабильные версии мобильных и настольных веб-браузеров, чтобы получить максимальную производительность и преимущества безопасности протокола приложения, как показано в тестах HTTP/2.

Поддержка веб-сервера ми : Apache и Nginx

На хостинге для внутренних серверов (или в облаке) придется обновлять и настраивать веб-серверы, чтобы добавить поддержку HTTP/2.

Серверы Nginx, составляющие 66 процентов всех активных веб-серверов, имеют встроенную поддержку HTTP/2, тогда как серверы Apache используют модуль mod_spdy для поддержки браузерами HTTP/2. Модуль был разработан компанией Google для поддержки функций SPDY, таких как мультиплексирование и сжатие заголовков для серверов Apache 2.2.

Как начать использовать HTTP/2

Следуйте этим простым шагам, чтобы настроить HTTP/2 для своего сайта:

  1. Убедитесь, что HTTPS включен на сайте:
  • Приобретите сертификат SSL или TLS у доверенного поставщика.
  • Активируйте сертификат безопасности.
  • Установите сертификат.
  • Обновите веб-сайт, чтобы включить протокол HTTPS.
  1. Убедитесь, что базовая сетевая инфраструктура, включая серверное программное обеспечение, поддерживает HTTP/2. Серверы Nginx поддерживают HTTP/2 изначально, в то время как Apache добавила встроенную поддержку в октябре 2015 года (в версии 2.4), что означает, что серверам Apache могут потребоваться дополнительные модули для обмена данными для поддержки браузерами HTTP/2.
  2. Обновите, настройте и протестируйте свои серверы для поддержки HTTP/2. Свяжитесь со службой поддержки вашего хостинга, чтобы убедиться, что HTTP/2 готов для вашего сайта.
  3. Используйте этот онлайн-инструмент , чтобы проверить, правильно ли вы настроили HTTP/2.

В прошлом году в мире сетевых технологий произошло очень важное событие: была утверждена и стандартизирована новая версия протокола 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 к HTTP/2

Немного истории

Протокол HTTP/2 обратно совместим с HTTP/1.1. Изменения, направленные на устранение узких мест и повышения производительности, во многом продолжают линию SPDY. Рассмотрим вкратце наиболее важные из них.

HTTP/2: основные нововведения

Мультиплексирование

Возможно, это самое главное преимущество HTTP/2. В HTTP/1.1 для каждого запроса требуется устанавливать отдельное TCP-соединение. Мультиплексирование же позволяет браузеру выполнять множество запросов в рамках одного TCP-соединения:

В современных браузерах количество одновременных TCP-соединений ограничено. Поэтому страницы с большим количеством статического контента загружаются не так быстро, как хотелось бы.

В HTTP/2 благодаря мультиплексированию статические элементы загружаются параллельно, и благодаря этому существенно улучшается производительность.

Приоритеты

Ещё одно нововведение HTTP/2 - это приоритизация. Каждому запросу можно назначить приоритет.
Существует два подхода к назначению приоритетов: на основе веса и на основе зависимостей.

В первом подходе каждый поток получает определённый вес. Потом на основе веса сервер распределяет нагрузку между потоками. Такой подход уже использовался в протоколе SPDY.

Второй метод, являющийся основным в HTTP/2, заключается в следующем: браузер просит сервер загружать определённые элементы контента в первую очередь. Например, сначала браузер может попросить сервер сначала загрузить CSS-файлы или JavaScript, а уже потом - HTML или изображения.

В HTTP/2 приоритизация является не обязательным, а желательным методом. Однако мультиплексирование без неё работать должным образом не будет. Скорость загрузки может быть даже ниже, чем HTTP/1.1. Ресурсы с более низким приоритетом будут занимать полосу, что приведёт снижению производительности.

Сжатие HTTP-заголовков

Современная веб-страница состоит из множества элементов: изображения, JS, CSS и другие. В запросе на загрузку каждого из этих элементов браузер передаёт HTTP-заголовок. Отправляя запрошенные элементы, сервер также добавляет к ним заголовок. Всё это сопряжено с излишним расходованием ресурсов.

В HTTP/2 заголовки передаются в сжатом виде. Благодаря этому уменьшается количество информации, которой обмениваются между собой сервер и браузер. Вместо алгоритмов gzip/deflate используется HPACK . Это снижает уязвимость к атакам типа BREACH .

HTTP/2 и безопасность

Одним из важнейших требований протокола SPDY является обязательное шифрование (HTTPS) соединения между клиентом и сервером. В HTTP/2 оно обязательного характера не имеет. Однако разработчики браузеров приняли решение внедрить новый протокол только для TLS(HTTPS)-соединений. Поэтому тем, кто задумывается о переходе на HTTP/2, нужно сначала перейти на HTTPS.

Это нужно не только для HTTP/2. В поиске Google использование безопасного соединения является одним из критериев ранжирования . Браузеры (см. и ) скоро будут помечать сайты, не поддерживающие https, как «небезопасные». Добавим также, что многие возможности HTML5 ― например, геолокация ― без безопасного соединения будут недоступны .

Базовая настройка HTTP/2 в Nginx и Apache

Приведём краткие инструкции по включению и базовой настройке HTTP/2 в Nginx и Apache. Как уже было сказано выше, большинство современных браузеров работают с HTTP/2 только через TLS, поэтому в конфигурации вашего веб-сервера должны быть прописаны соответствующие настройки.

Nginx

Поддержка HTTP/2 реализована только в новейших версиях Nginx (1.9.5 и выше). Если у вас установлена другая версия, вам потребуется обновить её.

После этого откройте конфигурационный файл /etc/nginx/nginx.conf и найдите в секции server следующую строку:

Listen 443 ssl;

и замените её на:

Listen 443 ssl http2;

Сохраните внесённые изменения и перезагрузите Nginx:

$ sudo service nginx reload

Apache

В 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/2 обратно совместим с HTTP/1.1. Поэтому вы в принципе можете не предпринимать никаких действий: работе вашего сервиса ничего не угрожает.
Но по мере перехода популярных веб-серверов и веб-браузеров на HTTP/2 вы увидите, что ваш сайт, который когда-то был оптимизирован для увеличения скорости загрузки страниц и повышения производительности, уже работает не так быстро, как раньше.

Многие способы оптимизации, успешно используемые в HTTP/1.1, в HTTP/2 работать не будут. Некоторые из них потребуется модифицировать, а от некоторых ― отказаться вообще. Рассмотрим этот вопрос более подробно.

Объединение изображений в спрайты

В HTTP/1.1 было удобнее загрузить одно большое изображение, чем делать множество запросов и загружать много маленьких. Это обусловлено тем, что запросы ставятся в очередь друг за другом. Самый распространённый способ увеличения скорости загрузки заключался в объединении множественных небольших изображений в спрайт-файл .

Спрайт возвращался в ответ на единственный запрос. Даже если пользователь заходил на страницу, на которой находится всего одно небольшое изображение, нужно было загрузить весь спрайт.

В HTTP/2 c его мультиплексированием таких проблем нет, однако использование спрайтов в определённых ситуациях может оказаться полезным. Объединение нескольких изображений в спрайт (особенно если все эти изображения находятся на одной странице) помогает улучшить сжатие и таким образом снизить общий объём загружаемых данных.

Встраивание изображений с помощью DataURI

Ещё один популярный способ решения проблемы множественных HTTP-запросов в HTTP/1.1 ― встраивание изображений с использованием Data URI . Это существенно увеличивает в размере таблицу стилей.

Если одновременно со встраиванием изображений для оптимизации используется ещё и конкатенация JS и CSS, пользователю скорее всего придётся загрузить весь соответствующий код, даже если он не будет посещать страницу с этими изображениями.
В HTTP/2 такая практика скорее ухудшит, а не улучшит производительность.

Конкатенация JS и CSS

Для оптимизации работы сайтов часто используется конкатенация небольших 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 в течение какого-то времени, но уже сейчас вы можете принять меры по оптимизации, которые облегчат вам жизнь в будущем.

Полезные ссылки

В заключение приведём для заинтересованных читателей несколько полезных ссылок

Это документ, описывающий http2 с позиции технического и протокольного уровня. Первоначально он появился как презентация, которую я представлял в Стокгольме в апреле 2014 года. Я получил с тех пор множество вопросов о содержимом презентации от людей, которые не смогли посетить мероприятие, поэтому я решил сконвертировать его в полноценный документ с деталями и надлежащими пояснениями.
На момент написания (28 апреля 2014), окончательная спецификация http2 не завершена и не выпущена. Текущая версия черновика называется draft-12 , но мы ожидаем увидеть ещё по крайне мере одну версию перед тем как http2 будет завершён. Данный документ описывает текущую ситуацию, которая может измениться или не измениться в окончательной спецификации. Все ошибки в данном документе – мои собственные, появившиеся по моей вине. Пожалуйста сообщите мне о них и я выпущу обновление с исправлениями.

Версия этого документа – 1.2.

Автор
Меня зовут Даниэль Штенберг и я работаю в Mozilla. Открытым программным обеспечением и сетями я занимаюсь уже более двадцати лет в различных проектах. Вероятно, я наиболее известен, как основной разработчик curl и libcurl. Многие годы я был вовлечён в рабочую группу IETF HTTPbis и работал как над поддержкой HTTP 1.1, для соответствия новейшим требованиям, так и работой над стандартизацией http2.

Email: [email protected]
Twitter: @bagder
Web: daniel.haxx.se
Blog: daniel.haxx.se/blog

Помогите!

Если вы обнаружили опечатки, упущения, ошибки и явную ложь в этом документе, пожалуйста отправьте мне исправленную версию параграфа и я выпущу исправленную версию. Я должным образом отмечу всех, кто помог! Надеюсь, что со временем получиться сделать текст лучше.

Лицензия
Этот документ лицензируется под лицензией Creative Commons Attribution 4.0: creativecommons.org/licenses/by/4.0

HTTP сегодня

HTTP 1.1 стал протоколом, который используется поистине для всего в Интернете. Огромные инвестиции были вложены в протоколы и инфраструктуру, которые теперь извлекают из этого прибыль. Дошло до того, что сегодня зачастую проще запустить что-либо поверх HTTP, чем создавать что-то новое вместо него.

HTTP 1.1 огромен

Когда 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 ) – это один из показательных примеров подобных возможностей.

Неполноценное использование TCP

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-запросов!

Рисунок ниже показывает как выглядит запись пакетов при просмотре одного топ веб-сайта Швеции и как запросы распределяются по нескольким хостам.

Обновление HTTP

А не было бы лучше сделать усовершенствованный протокол? Который бы включал в себя следующее…

  1. Создать протокол, который был бы менее чувствителен к RTT
  2. Исправить конвейерную обработку и проблему блокировки начала очереди
  3. Остановить необходимость и желание в увеличении числа соединений к каждому хосту
  4. Сохранить существующие интерфейсы, всё содержимое, формат URI и схемы
  5. Сделать это внутри рабочей группы IETF HTTPbis
IETF и рабочая группа HTTPbis

Инженерный совет Интернета (IETF) – это организация, которая разрабатывает и продвигает интернет стандарты. Большей частью на протокольном уровне. Они хорошо известны по серии RFC-документов, документирующих всё: от TCP, DNS, FTP до лучших практик, HTTP и множества вариантов протокола, которые нигде не были применены.

Внутри IETF есть выделенные «рабочие группы», которые сформированы вокруг небольшого круга задач для достижения цели. Они составляют «устав» из набора принципов и ограничений для достижения поставленной цели. Любой и каждый может присоединиться к дискуссии и разработке. Все, кто участвует и что-либо высказывает, имеют равные возможности и шансы для влияния на результат и все учитываются как люди и личности, без оглядки на то, в какой компании работает человек.

Рабочая группа HTTPbis была сформирована в течении лета 2007 года и должна была обновить спецификацию HTTP 1.1 - отсюда и суффикс «bis». Обсуждение в группе новой версии HTTP протокола по-настоящему началось в конце 2012 года. Работа над обновлением HTTP 1.1 была завершена в начале 2014 года.

Заключительное совещание для рабочей группа HTTPbis перед ожидаемым финальным выпуском версии спецификации http2, пройдёт в Нью-Йорке в начале июня 2014 года.

Некоторых больших игроков на поле HTTP не хватало в обсуждениях и встречах рабочей группы. Я не хочу называть какую-либо конкретную компанию или имя продукта здесь, но ясно, что на сегодняшний день некоторые действующие лица в Интернете, по всей видимости, уверены, что IETF сделает всё хорошо без привлечения этих компаний…

Суффикс «bis»
Группа названа HTTPbis, где суффикс «bis» происходит от латинского наречия, которое означает «два». Бис часто используют как суффикс или часть имени внутри IETF для обновления или второй попыткой работы над спецификацией. Также, как в случае HTTP 1.1.

Теги: Добавить метки

Протокол передачи гипертекста (HTTP , англ. HyperText Transfer Protocol) - протокол, который управляет соединением между вашим сервером и браузерами клиентов. Впервые после 1999 года, появилась новая версия этого протокола ,и это обещает значительно ускорить каждый сайт.

В этой статье мы опишем основы HTTP/2 для дизайнеров и разработчиков. Я объясню некоторые ключевые особенности нового протокола, рассмотрю совместимость (серверную и браузерную) и остановлюсь подробнее на вещах, над которыми нужно задуматься, поскольку все чаще видим внедрение HTTP/2 . Прочитав эту статью, вы получите обзор того, что нужно изменить в вашей работе в кратко- и долгосрочной перспективе. Также я включу множество дополнительных ресурсов, на тот случай, если вы захотите углубится в вопрос. Моя цель - предоставить достаточное количество знаний, которое поможет принят правильное решение о переходе на HTTP/2 .

Для дальнейшего прочтения

  • Все, что вы должны знать о сайтах, оптимизированных для мобильных устройств

Краткая история HTTP .

Если у ваш сайт использует только http, тогда мое предложение как можно скорее перейти на https, и уже тогда определится с HTTP/2 стратегией.

Объединение множества изображений в спрайты

В HTTP/1.1 получение одного большого изображения намного эффективней для браузеров, чем множество мелких запросов. Это происходит потому, что несколько запросов выстраиваются в очередь друг за другом. Объединение мелких файлов в спрайты было временным решением этой проблемы.

Результирующий спрайт возвращался одним http запросом, предупреждая проблему очереди запросов. Однако, даже если посетитель находится на страничке, где отображаются только несколько иконок, ему все равно нужно загрузить намного больший файл.

С мультиплексирующей способностью HTTP/2 , очередь ресурсов больше не является проблемой. Отдача мелких изображений отдельно будет лучшим решением во многих случаях; вам нужно обрабатывать только то, что необходимо для запрошенной страницы. Но создание спрайтов и дальше будет оправданным во многих случаях. HTTP реквесты - это только один аспект производительности. Объединение некоторых изображений вместе в спрайт позволяет достичь лучшего сжатия, и, как результат, меньшего объема загрузки, особенно, если все изображения используются на странице. Однако, спрайты больше не всегда будут лучшим решением.

Встраивание изображений за счет использования data uri

Другое обходное решение проблемы множества HTTP-запросов - встраивание изображений в css с использованием data uri . Использование изображений подобным способом делает css-файл намного больше. Если вы в добавок используете сжатие и объединение ассетов, посетители будут загружать огромное количество кода, даже если никогда не перейдут на страницу, где он действительно нужен.

С оптимизацией HTTP-запросов у HTTP/2 , эта "лучшая практика" будет больше мешать, нежели помогать улучшению производительности.

Объединение CSS и Javascript

Многие из нас используют объединение мелких css и javascript файлов. Зачастую мы хотим содержать их раздельно во время разработки - для лучшего понимания, но мы знаем, что загрузка одного файла браузером намного эффективней, чем пяти. Еще раз, мы ограничиваем количество HTTP-запросов.

Если вы делаете это, посетитель, открыв главную страницу, загрузит все css- и javascript файлы, необходимы для работы сайта, даже если не использует большинство из них. Как разработчик, вы можете уменьшить проблему путем тщательного подбора подключаемых файлов для каждой страницы сайта, но для этого требуется слишком много работы.

Еще одна дополнительная проблема с объединением файлов - очистка кэша: чистится все вместе. Вы не можете указать файлам, которые никогда не меняются, долгое время жизни, и короткое часто изменяемым. Весь кэш должен быть обновлен, даже если поменялась одна строка в css-файле.

Предполагаю, вы понимаете, к чему я клоню! HTTP-запросы дешевые в HTTP/2 мире. Распределение ассетов на используемых страницах будет намного более оптимально. Вы сможете отдавать только реально используемый код. Загрузка множества мелких файлов не будет иметь значения. Также вы сможете распределять файлы по частоте их изменений.

Распределение ресурсов между хостами: sharding

C HTTP/1.1 , вы ограничены количеством открытых соединений. Если невозможно избежать загрузки, один из способов решения проблемы - получение ресурсов с разных доменов. Эта методика называется domain sharding . Это хотя и ускоряет время загрузки, но может вызвать новые проблемы , не говоря уже о том, что это требует дополнительных расходов во время разработки.

HTTP/2 упраздняет необходимость domain sharding, потому что снято ограничение количества одновременно загружаемых ресурсов. Более того, это может плохо повлиять на производительность, поскольку открывает дополнительные TCP соединения и мешает обрабатывать HTTP/2 приоритеты ресурсов.

Как теперь подготовиться до HTTP/2 ?

Если вы стартуете долговечный проект проект, но по какой-то причине не можете запустить его с HTTP/2 , возможно, по причинам поддержки сервера, лучше сразу подготовится до HTTP/2 . Вы можете добавить несколько вещей, которые упростят переход в будущем.

Создайте индивидуальные ассеты, дополнительно до спрайтов и data uri

Если вы создаете спрайты, позаботьтесь также о создании и оптимизации мелких ассетов, или меньших спрайтов под индивидуальные страницы, если видите, что это улучшит производительность. Это упростит переход от больших спрайтов до более мелких, если будет необходимо.

Это также касается и data uri. Если используете в css, подготовьте также картинки для того времени, когда вы откажетесь от этой техники.

Упорядочьте ассеты по разделам сайта

Из-за использования объединения css и javascript файлов, существует соблазн объединять их и на этапе разработки, так как они все равно потом собираются в один файл. Когда вы переключитесь на HTTP/2 , вы получите лучшую производительность, если будете тщательно разделять ресурсы, не загружая ничего лишнего. Следовательно, организация ассетов теперь будет иметь ценность. Сейчас вы можете продолжать объединять ассеты, а при необходимости сразу же начать отдавать их по отдельности.

Управление domain sharding

Текущая лучшая практика для 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 .

План действий по работе с 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 доступно онлайн. Некоторые ресурсы размещу здесь, часть из них были использованы при написании статьи.