Http 2 основное. Разъяснение http2. Управление domain sharding

Возможности 03.03.2019
Возможности

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

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

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

HTTP – это старый протокол, изначально определённый в 1991 году , и в последний раз серьёзно изменённый в версии HTTP/1.1 .

Сайты в 1999 году сильно отличались от тех, которые мы разрабатываем сегодня. Сейчас, чтобы отобразить домашнюю страницу среднего сайта, требуется 1,9 Мб. При этом загружается более 100 отдельных ресурсов, от изображений и шрифтов до файлов JavaScript и CSS .

HTTP/1.1 плохо работает с большим количеством ресурсов. Поэтому лучшие практики оптимизации направлены на повышение производительности этой версии протокола.

SPDY

В 2009 году два инженера корпорации Google рассказали про исследовательский проект под названием SPDY . Этот проект был нацелен на решение проблем, связанных с работой протокола HTTP/1.1. SPDY позволяет:

  • Использовать конкурирующие запросы в одном соединении TCP (мультиплексирование ).
  • Браузерам устанавливать приоритеты так, чтобы ресурсы, важные для отображения страницы, загружались первыми.
  • Сжимать и уменьшать заголовки HTTP
  • Реализовать технологию server push , в рамках которой сервер может пересылать браузеру важные ресурсы, прежде чем его об этом попросят.

В добавление к этому SPDY обязывает шифровать соединение (HTTPS ) между браузером и сервером.

SPDY не заменяет HTTP . Он скорее является туннелем для протокола и изменяет процесс отправки запросов и ответов HTTP . Для него обязательна поддержка, как на стороне сервера, так и на стороне клиента. Благодаря поддержке, доступной в NGNIX и пакетах от Google для Apache , SPDY применялся достаточно широко. При этом современные версии основных браузеров поддерживают его в полном объеме.

Поддержка SPDY браузерами по данным « Can I Use »

HTTP/2

Поддержка SPDY была прекращена в Edge из-за того, что специалисты Microsoft реализовали в новом браузере поддержку HTTP/2 – последней по времени выхода версии протокола HTTP . Но другие современные браузеры всё ещё сохраняют поддержку SPDY .


Поддержка HTTP /2 браузерами по данным « Can I Use »

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

Спецификация HTTP/2 была завершена в феврале 2015 года. Спустя год он прекрасно поддерживается браузерами. Так же, как и SPDY , HTTP/2 предполагает поддержку, как в браузере, так и на сервере.

Уже существует много его реализаций для серверов. Вы можете следить за ними в справочнике по HTTP/2 .

Придётся ли изменять сайты?

HTTP/2 обратно совместим с HTTP/1.1 , поэтому есть возможность его проигнорировать, и всё продолжит работать, как раньше. Изменение протокола незаметно для пользователей. Многие из читателей этой статьи уже используют протокол, отличный от HTTP/1.1 многие годы. Например, если у вас есть аккаунт в почтовом сервисе Gmail , и вы используете браузер Google Chrome для доступа к нему.

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

Что нужно изменить, чтобы использовать преимущества HTTP/2?

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

Переходите на TLS

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

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

Преобразование нескольких файлов изображений в спрайты

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

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

Благодаря мультиплексированию в HTTP/2 очереди запросов к ресурсам больше не являются проблемой. Предоставление изображений по отдельности лучше по нескольким причинам: нужно будет отправить только то, что запрошено.

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

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

Другой метод решения проблемы множественных запросов в HTTP/1.1 – встраивание изображений в CSS, используя data URI . Встраивание изображений таким образом сильно увеличивает размер файла стилей. Если вы сочетаете этот метод с другой техникой оптимизации, то браузер загрузит весь этот CSS ? даже если пользователь не посетит страницы, на которых используются эти изображения. В HTTP/2 эта «лучшая практика » скорее будет вредить, чем улучшать производительность.

Соединение CSS и JavaScript

На финальной стадии сборки сайта многие соединяют все мелкие файлы CSS и JavaScript , используемые на нем. Мы зачастую разделяем их при разработке, чтобы было легче управлять ими. Но доставка одного файла браузеру более эффективна в плане производительности, чем доставка пяти. И мы снова пытаемся сократить количество HTTP-запросов .

Если вы это делаете, то посетителям придётся загрузить все стили CSS и JavaScript сайта. Можно обойти эту проблему, подключая только определённые файлы для каждой области сайта в процессе его сборки.

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

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

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

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

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

Несколько советов, как подготовиться к переходу на HTTP/2 .

Создавайте отдельные изображения в дополнение к спрайтам и встраиванию изображений

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

Организуйте файлы по секциям сайта

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

Управляйте разделением между доменами

На данный момент лучшая практика для HTTP/1.1 – ограничить разделение двумя именами хостов. В HTTP/2 существует способ объединить эти соединения, если сертификат TLS действителен для обоих хостов и хосты находятся на одном IP-адресе . TLS сертификат необходим для работы через HTTP/2 .


Дальнейшие действия

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

Когда совершать переход?

Решение о переходе на HTTP/2 сводится к тому, поддерживается ли этот протокол большинством браузеров ваших пользователей . Помните, что HTTP/2 обратно совместим, поэтому вам не придётся делать ничего особенного.

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

Ваш план действий в отношении HTTP/2

  1. Запустите сайт с безопасным соединением или перейдите на TLS прямо сейчас.
  2. Подготовьтесь к HTTP/2 в процессе сборки сайта. Используйте советы, приведенные выше, чтобы создать сайт, оптимизированный под обе версии протокола.
  3. Проверьте хостинг. Удостоверьтесь в том, что ваш сервер поддерживает HTTP/2 .
  4. Разверните оптимизацию под HTTP/2 . Прекратите использовать устаревшие практики и переходите к применению новых.

После того, как вы перейдёте на HTTP/2 , стоит проверить, насколько увеличится скорость вашего сайта.

Протокол HTTP 1.1 служил верой и правдой почти 20 лет, так что появление новой спецификации было лишь вопросом времени. Его заменил HTTP/2, официально принятый в прошлом году и основанный на протоколе SPDY, разработанном Google.

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

Для включения в Nginx (версия 1.9.5 или выше) в файле конфигурации (секция server) необходимо дополнить директиву listen:

Server { listen 443 ssl http2; server_name example.com; ssl_certificate server.crt; ssl_certificate_key server.key; }

# Nginx поддерживает HTTP/2 только в паре с TLS

Ну а в Apache (начиная с версии 2.4.17 и выше) нужно дополнить файл конфигурации:

# for a https server Protocols h2 http/1.1 # for a http server Protocols h2c http/1.1

# Поддержка HTTP/2 для защищенного и незащищенного подключения

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

Ну и в-третьих, новая спецификация намного быстрее и производительнее HTTP 1.1. К тому же, более 7.1 % веб-сайтов по данным W3Techs уже поддерживают HTTP/2.

Главные отличия HTTP/2 от HTTP 1.1

Основных отличий между протоколами всего несколько.

Бинарность

В отличие от текстового HTTP 1.1, HTTP/2 — бинарный. Поэтому протокол более эффективен при парсинге, более компактный при передаче, подвержен меньшему количеству ошибок.

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

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

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

Приоритизация

Вместе с мультиплексированием появилась приоритизация трафика. Запросам можно назначить приоритет на основе важности и зависимости.

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

Компрессия заголовков HPACK

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

Server Push

При использовании протокола HTTP 1.1 браузер запрашивает страницу, сервер отправляет в ответ HTML и ждет, пока браузер его обработает и запросит все необходимые файлы: JavaScript, CSS и фото. Поэтому в новый протокол внедрили интересную функцию под названием Server Push.

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

Шифрование

Протокол HTTP/2 не требует шифрования канала. Тем не менее, все современные браузеры работают с HTTP/2 только вместе с TLS , как и Nginx. Так что массовое внедрение протокола должно поспособствовать распространению шифрования по Сети.

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

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

Главная оптимизация HTTP/2 по сравнению с HTTP 1.1 — отключение или модификация многих оптимизаций прошлой версии протокола.

  • Стоит отказаться от доменного шардинга. Такой способ распределения множества файлов по различным доменам и CDN актуален для HTTP 1.1, так как решает проблему параллельных соединений. Но в случае с новым протоколом такое решение ухудшает производительность и нивелирует приоритизацию трафика.
  • По возможности откажитесь или модифицируйте спрайты. Объединение множества маленьких картинок в одно большое изображение способно увеличить скорость загрузки страницы, но если пользователь заходил на веб-страницу с одной маленькой картинкой, то ему все-равно отправлялся весь спрайт. В случае с HTTP/2 такое решение будет менее полезным в виду появления мультиплексирования.
  • Еще один метод оптимизации изображений — встраивание при помощи DataURI. Он также может быть полезен в HTTP/2, но точно будет менее эффективным, чем в случае с прошлой версией.
  • Лучше отказаться от объединения (конкатенации) файлов. Метод похож на спрайты — все необходимые файлы, CSS и JavaScript, объединяются в один большой для передачи одним потоком по одному соединению. Так что если пользователь зашел на страницу с одним небольшим кодом JS, ему все-равно будет отправлен весь объединенный файл. Еще одна сложность — все объединенные файлы нужно выгружать из кэша одновременно, а одно изменение в коде любого из них требует обновления всего набора. Так что благодаря все тому же мультиплексированию такой подход не имеет смысла.
  • Также стоит отказаться от встраивания файлов в HTML код.

Самое главное

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

18.07.2017 11:41

HTTP/2 - это вторая версия всем известного протокола HTTP. Полностью название этого протокола выглядит как HTTP/2.0. Как известно, HTTP - или Hypertex Transfer Protocol - это протокол, который используется для передачи гипертекста. Иными словами, благодаря HTTP веб-страницы загружаются и показываются через браузер интернет-пользователям.

Протокол HTTP появился давно: первая версия - даже не первая, а 0.9 - вышла в далеком 1991 году. Через восемь лет, в 1999 году, появилась те версия HTTP, которая активно используется сейчас, - HTTP/1.1. Казалось бы, если все работает, то зачем что-то менять? Но как и везде в разработке, прогресс не стоит на месте, все меняется и требует изменений.

Разработка

Разработкой новой версии протокола занималась рабочая группа HTTPbis из Internet Engineering Task Force (Инженерного совета интернета, который разрабатывает стандарты интернета). Она была сформирована в 2007 году специально для работой над этим проектом. Однако активные действия начали происходить лишь через пять лет, в 2012 году.

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

Один из участников рабочей группы Даниэль Штенберг весной 2014 года опубликовал документ , в котором рассказано о том, зачем вообще начали работу над этим проектом, и как она происходит. Документ доступен и на русском языке: https://bagder.gitbooks.io/http2-explained/ru/

Вот кратко перечисленные в описании концепции пункты:

  • должны поддерживаться парадигмы HTTP;
  • должны остаться ссылки http:// и https://, не нужно добавлять новую схему;
  • серверы и клиенты, использующие HTTP/1, должны быть проксированы к HTTP/2-серверам;
  • возможности HTTP/2 должны быть конвертированы в HTTP/1.1 при помощи прокси;
  • сокращение числа опциональных частей в протоколе;
  • отсутствие минорных версий в HTTP/2; при необходимости будет разработан протокол HTTP/3.

Новшества

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

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

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

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

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

Отдельно стоит вопрос сжатия . HTTP является протоколом без состояния, а значит, повторяющимся протоколом. На практике это выражается в том, что если на сервер идет запрос нескольких ресурсов (к примеру, картинок), то это рождает серию запросов, которые сами по себе является практически идентичными. Поэтому логично, что сжатие необходимо.

Однако подводные камни есть и здесь. В частности, сжатие HTTPS и SPDY уязвимы к атаке BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext), использующей недочеты алгоритма сжатия gzip/DEFLATE, и атаке CRIME (Compression Ratio Info-leak Made Easy), которая также эксплуатирует алгоритмы сжатия данных.

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

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

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

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

HTTP/2 поддерживают все основные браузеры: Chrome, Firefox, Opera, Edge, Safari.
Также рекомендуется быстрее перейти на HTTP/2 тем, у кого много мобильного трафика.

Переход на HTTP/2

Тем, кто заинтересовался переходом на HTTP/2, я советую прочитать вот эту документацию на английском языке: https://cdn.wp.nginx.com/wp-content/uploads/2015/09/NGINX_HTTP2_White_Paper_v4.pdf

Итог

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

«… мы не меняем весь HTTP - методы, коды статусов и большинство заголовков остаются теми же. Мы лишь переработали его с точки зрения повышения эффективности использования, чтобы он был более щадящим по отношению к интернету…»

Важно отметить, что новая версия HTTP идёт в качестве расширения для своего предшественника, и вряд ли в обозримом будущем заменит HTTP 1.1. Реализация HTTP/2 не подразумевает автоматической поддержки всех типов шифрования, доступных в HTTP 1.1, но определённо поощряет использование более интересных альтернатив, или дополнительное обновление совместимости шифрования в ближайшем будущем. Тем не менее, в сравнениях «HTTP/2 против HTTP 1» и «SPDY против HTTP/2» герой этой статьи выходит победителем по производительности, безопасности и надёжности.

Чем был плох HTTP 1.1?

HTTP 1.1 позволяет обрабатывать лишь один поступивший запрос на одно TCP-соединение, поэтому браузеру приходится устанавливать несколько соединений, чтобы обрабатывать одновременно несколько запросов.

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

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

Сетевой индустрии фактически пришлось хакнуть эти ограничения с помощью таких методик, как доменный шардинг (domain sharding), конкатенация, встраивание и спрайтинг (spriting) данных, а также ряд других. Неэффективное использование HTTP 1.1 базовых TCP-соединений является причиной плохой приоритезации ресурсов, и в результате - экспоненциальной деградации производительности по мере роста сложности, функциональности и объёма веб-приложений.

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

Например, с помощью Cookie Hack злоумышленники могут повторно использовать предыдущую рабочую сессию для получения несанкционированного доступа к паролю пользователя. А причина в том, что HTTP 1.1 не предоставляет инструментов конечного подтверждения подлинности. Понимая, что в HTTP/2 будут искать аналогичные лазейки, его разработчики постарались повысить безопасность протокола с помощью улучшенной реализации новых возможностей TLS .

Особенности HTTP/2

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

Пересылаемая через HTTP/2 в обе стороны последовательность текстовых фреймов, которыми обмениваются между собой клиент и сервер, называется “потоком”. В ранних версиях HTTP можно было транслировать только по одному потоку за раз, с небольшой задержкой между разными потоками. Передавать таким способом большие объёмы медиа-контента было слишком неэффективно и ресурсозатратно. Для решение этой проблемы в HTTP/2 применяется новый бинарный слой фреймов.

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

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

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

Отправка данных по инициативе сервера (Server Push)

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

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

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

Реализация HTTP/2 демонстрирует высокую производительность при работе с инициативно передаваемыми ресурсами:

  • Инициативно передаваемые ресурсы сохраняются в кэше клиента.
  • Клиент может многократно использовать эти ресурсы на разных страницах.
  • Сервер может мультиплексировать инициативно передаваемые ресурсы вместе с запрошенной информацией в рамках того же TCP-соединения.
  • Сервер может приоритезировать инициативно передаваемые ресурсы. Это ключевое отличие с точки зрения производительности между HTTP/2 и HTTP 1.
  • Клиент может отклонить инициативно передаваемые ресурсы для поддержания эффективности репозитория, или может вообще отключить функцию Server Push.
  • Клиент может также ограничивать количество одновременно мультиплексированных потоков с инициативно передаваемыми данными.
В неоптимальных методиках наподобие встраивания (Inlining) также используются push-функциональности, позволяющие заставить сервер откликаться на запросы. При этом Server Push представляет собой решение на уровне протокола, помогающее избежать возни с оптимизационными хаками.

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

Двоичный протокол

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

Читать двоичные команды будет труднее, чем аналогичные текстовые, но зато сети будет легче их генерировать и парсить фреймы. Семантика остаётся без изменений. Браузеры, использующие HTTP/2, перед отправкой в сеть конвертируют текстовые команды в двоичные. Двоичный слой фреймов не имеет обратной совместимости с клиентами и серверами, использующими HTTP 1.x. Он является ключевым фактором, обеспечивающим значительный прирост производительности по сравнению с SPDY и HTTP 1.x. Какие преимущества даёт интернет-компаниям и онлайн-сервисам использование двоичных команд:

  • Низкие накладные расходы при парсинге данных - критически важное преимущество HTTP/2 по сравнению с HTTP 1.
  • Ниже вероятность ошибок.
  • Решение проблем с безопасностью, наподобие атак с разделением запросов (response splitting attack), проистекающих из текстовой природы HTTP 1.x.
  • Реализуются прочие возможности HTTP/2, включая сжатие, мультиплексирование, приоритезацию, управление потоками и эффективную обработку TLS.
  • Компактность команд упрощают их обработку и реализацию.
  • Выше эффективность и устойчивость к сбоям при обработке данных, передаваемых между клиентом и сервером.
  • Снижение сетевой задержки и повышение пропускной способности.

Приоритезация потоков

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

Приоритезация осуществляется с помощью присваивания каждому потоку зависимостей (Dependencies) и веса (Weight). Хотя все потоки, по сути, и так зависят друг от друга, ещё добавляется присваивание веса в диапазоне от 1 до 256. Детали механизма приоритезации всё ещё обсуждаются. Тем не менее, в реальных условиях сервер редко управляет такими ресурсами, как ЦПУ и подключения к БД. Сложность реализации сама по себе не даёт серверам выполнять запросы на приоритезацию потоков. Продолжение работ в этом направлении имеет особенное значение для успеха HTTP/2 в долгосрочной перспективе, потому что протокол позволяет обрабатывать многочисленные потоки в рамках единственного TCP-соединения.

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

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

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

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

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

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

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

  • Эффективную приоритезацию потоков.
  • Эффективное использование механизмов мультиплексирования.
  • Снижает накладные расходы при использовании ресурсов. Это один из первых вопросов, обсуждаемых при сравнении HTTP/2 с HTTP 1 и SPDY.
  • Кодирование больших и часто используемых заголовков, что позволяет не отправлять весь фрейм с заголовком. Передаваемый размер каждого потока быстро уменьшается.
  • Устойчивость к атакам, например, CRIME - эксплойтам потоков данных со сжатыми заголовками.

Различия между HTTP 1.x и SPDY

Базовая семантика приложения HTTP в последней итерации HTTP/2 осталась без изменений, включая коды статусов, URI, методики и файлы заголовков. HTTP/2 основан на SPDY, созданной в Google альтернативе HTTP 1.x. Основные различия кроются в механизмах обработки клиент-серверных запросов. В таблице отражены основные различия между HTTP 1.x, SPDY и HTTP/2:
HTTP 1.x SPDY HTTP2
Необходим SSL. SSL не требуется, но рекомендуется.
Медленное шифрование. Быстрое шифрование. Шифрование стало ещё быстрее.
Один клиент-серверный запрос на одно TCP-соединение. Много клиент-серверных запросов на одно TCP-соединение. Осуществляются одновременно на одном хосте. Многохостовое мультиплексирование. Осуществляются на нескольких хостах в одном экземпляре.
Нет сжатия заголовков. Введено сжатие заголовков. Используются улучшенные алгоритмы сжатия заголовков, что повышает производительность и безопасность.
Нет приоритезации потоков. Введена приоритезация потоков. Улучшенные механизмы приоритезации потоков.

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

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

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

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

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

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

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

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

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

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

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

Производительность сети

Это понятие отражает совокупный эффект всех нововведений HTTP/2. Результаты бенчмарков (см. главу «Сравнение производительности HTTPS, SPDY и HTTP/2») демонстрируют увеличение производительности при использовании HTTP/2 по сравнению с его предшественниками и альтернативными решениями.

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

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

Что происходит, когда механизмы передачи данных сметают все преграды на пути к повышению производительности сети? У высокой скорости работы сайтов есть побочные явления: пользователи получают больше удовольствия, улучшается оптимизация для поисковых сервисов, ресурсы используются эффективнее, растёт аудитория и объёмы продаж, и многое другое.

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

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

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

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

Интернет подешевле

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

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

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

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

Насыщенность мультимедиа

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

Улучшение опыта использования мобильного интернета

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

Более эффективное использование сети

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

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

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

Инновационность

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

Преимущества HTTP/2 с точки зрения SEO

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

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

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

Сравнение производительности HTTPS, SPDY и HTTP/2

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

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

Подробности тестирования:

Результаты этого теста говорят нам следующее:

  • Размеры заголовков клиентского запроса и серверного отклика : HTTP/2 демонстрирует, что использование сжатия позволяет значительно уменьшить размер заголовка. При этом SPDY уменьшает заголовок только серверного отклика для данного запроса. HTTPS вообще не уменьшает заголовки.
  • Размер сообщения серверного отклика : размер отклика HTTP/2-сервера оказался больше, но зато в нём применялось более стойкое шифрование.
  • Количество использованных TCP-соединений : при обработке многочисленных одновременных запросов(мультиплексирование) HTTP/2 и SPDY используют меньше сетевых ресурсов, следовательно, снижается задержка.
  • Скорость загрузки страницы : HTTP/2 постоянно был быстрее SPDY. HTTPS был значительно медленнее из-за отсутствия сжатия заголовков и инициативной отправки данных сервером.

Браузерная поддержка HTTP/2 и доступность

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

Клиентская поддержка

Пользователям не нужно заботиться о настройке поддержки HTTP/2 в своих браузерах - «полноценных» и мобильных. Chrome и Firefox давно поддерживают эту технологию , а в Safari поддержка HTTP/2 появилась в 2014. В IE данный протокол поддерживается только начиная с Windows 8.

Основные мобильные браузеры, включая Android Browser, Chrome для Android и iOS, а также Safari в iOS8 и выше, уже поддерживают HTTP/2. Рекомендуется на всякий случай поставить последние стабильные версии мобильных и настольных браузеров, чтобы получить максимальную производительность и преимущества в безопасности.

Серверная поддержка: Apache и Nginx

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

Nginx -серверы, составляющие 66% всех активных веб-серверов , могут похвастаться встроенной поддержкой HTTP / 2. А для обеспечения браузерной поддержки HTTP/2 на Apache, нужно воспользоваться модулем mod_spdy . Он разработан Google для внедрения поддержки в Apache 2.2 таких функций, как мультиплексирование и сжатие заголовков. Это ПО было передано в дар Apache Software Foundation.

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

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

Заключение

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

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

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

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

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

Итак, что же такое HTTP/2. Это всего лишь маркетинговое словечко или действительно что-то стоящее внимания?

HTTP/2 - это последняя версия знаменитого сетевого протокола HTTP- Hypertext Transfer Protocol , который используется во Всемирной паутине. Этот протокол даёт возможность разделить текстовую и мультимедийную информацию, используя так называемые веб линки между неподключенными узлами, такими как браузер и сервер. Например, ваш браузер использует этот протокол для загрузки данной статьи. Но без протокола HTTP не было бы Интернета!

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

СЕТЕВОЙ ПРОТОКОЛ HTTP

НТТР использует технологию “клиент-сервер”. Это значит, что ваш браузер (Firefox, Chrome и т.д.) является “клиентом”, а наш блог работает на сервере хостинга. Например, эта статья может быть идентифицирована и загружена с помощью URL - Uniform Resource Locator (уникальный определитель ресурса). Если вы открываете URL этой статьи, ваш клиент делает НТТР запрос на сервер и получает информацию в HTML формате. Как только трансфер данных (на транспортном уровне по протоколу ТСР) будет проведён, ваш браузер отобразит полученный ответ в HTML коде для вывода на экран текста, который вы сейчас читаете.

Исторический факт: Термин «hypertext» впервые был использован Тэдом Нельсоном в 1965 год (проект Xanadu). HTTP и HTML были созданы Тимом Бернерс-Ли и его командой в CERN в 1989 году. Между прочим, первый сайт был опубликован 6 августа 1991 года.

Сетевой протокол поддерживает сессии и аутентификацию. Сессия это открытая последовательность транзакций запрос-ответ по ТСР соединению на определённый порт. Порт 80 используется для НТТР и 443 для НТТРS соединений. HTTPS это HTTP поверх SSL/TLS , который обозначает, что сквозное соединение создано через зашифрованный канал с помощью криптографического протокола Transport Layer Security (TLS) .

HTTP/1.0 и HTTP/1.1

Перед тем как HTTP/2 был представлен как стандарт, предыдущий протокол HTTP/1.1 был официальным стандартом. HTTP/1.1 - это усовершенствованная версия оригинальной HTTP/1.0 версии, официально представленной в 1996 году. Самая первая версия HTTP/1.1 была представлена в 1997 году, а улучшенная и обновлённая его версия была выпущена в 1999 года и повторно в 2014. Главное отличие между этими двумя устаревшими стандартами в поддержке множественных подключений в одном запросе.

HTTP/1.0 поддерживает лишь одно подключение за один запрос ресурса, тогда как HTTP/1.1 позволяет использовать то же самое подключение несколько раз, т.е. устанавливается постоянное подключение. Это даёт меньшую задержку и помогает загрузить современный сайт быстрее. Задержка - это время между запросом (причиной) и ответом (результатом). Этот параметр был улучшен в дальнейшем в HTTP/2 , но поясним главные преимущества нового стандарта позже.

ПОДРОБНЕЕ О МЕТОДАХ ЗАПРОСА HTTP

Чуть выше мы рассказали про запросы к серверу. HTTP определяет несколько методов запроса, которые могут быть использованы для разных целей и действий на определённом ресурсе. Наиболее распространённые методы это GET и POST, которые должны быть вам знакомы.

Когда вы вызываете URL, кликая по обычной ссылке, то ваш браузер создаёт GET запрос. Вы можете видеть GET параметры прямо в URL , например?id=42 . В этом примере переменная GET это идентификатор со значением 42. Когда вы подписываетесь на услугу вводя свои данные в форме и кликаете на кнопку подтверждения, то ваш клиент выполнит POST запрос. Кроме этих методов НТТР поддерживает несколько других методов, которые обычно не используются браузером во время интернет-сёрфинга. Вот эти методы:

  • HEAD (подобное методу GET, но без тела ответа),
  • PUT (меняет или создаёт ресурс),
  • DELETE (удаляет ресурс),
  • TRACE (эхо-запрос),
  • OPTIONS (возвращает поддерживаемые HTTP методы),
  • CONNECT (преобразовывает запросы в TCP/IP туннель),
  • PATCH (применяет изменения для ресурса).

HTTP ОТВЕТЫ И КОДЫ СТАТУСОВ HTTP

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

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

  • 1 – информационный,
  • 2 – успешный,
  • 3 – переадресация,
  • 4 – клиентская ошибка,
  • 5 – серверная ошибка.

ПРЕИМУЩЕСТВА HTTP/2

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

Сервер может передавать данные клиенту даже если они ещё не были запрошены браузером, но необходимы браузеру для полного отображения страницы. Дополнительные запросы могут быть мультиплексированы (запросы или ответы комбинируются) и переданы конвейерным способом (множество запросов без ожидания получения соответствующих ответов) при одном ТСР соединении. Эти улучшения уменьшают задержку и ведут к лучшей скорости загрузки страницы.
Итак, что необходимо, чтобы начать пользоваться преимуществами HTTP/2 ? Оба, клиент и сервер, должны понимать и поддерживать этот стандарт. Все популярные современные браузеры уже имеют встроенную поддержку HTTP/2 на данный момент. Ваш браузер будет автоматически загружать веб-страницы через HTTP/2 если сервер поддерживает его. (то есть, если он включен).

КАК МНЕ АКТИВИРОВАТЬ HTTP/2 НА СВОЕМ СЕРВЕРЕ? ИСПОЛЬЗУЙТЕ PLESK!

Настройка HTTP/2 - это действительно просто! Как всегда, Plesk сделал всю трудную работу за вас, пока вы отдыхали и занимались своим бизнесом. Если у вас уже есть Plesk на вашем сервере, то вам достаточно сделать несколько кликов, чтобы включить поддержку современного, быстрого сетевого стандарта.

Команда Plesk создала расширение безопасности Security Advisor , с помощью которого можно активировать HTTP/2 , а также активировать сертификат SSL и поддержку HTTPS в 1 клик в WordPress. Откройте каталог расширений Plesk и установите Security Advisor. Расширение абсолютно бесплатное и не только защитит ваш сайт, но и ускорит!



Рекомендуем почитать