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

В этой статье поговорим о том, что же такое 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. Расширение абсолютно бесплатное и не только защитит ваш сайт, но и ускорит!

Протокол 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 и HTTPS, покажу разницу и отличия между ними. Приятного чтения!

HTTP 1.1 - что это за протокол?

HTTP (англ. «протокол передачи гипертекста») - сетевой протокол верхнего уровня для передачи гипертекстовых и произвольных данных в интернете.

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

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

Актуальная версия протокола - 1.1. Ее описание находится в спецификации RFC.

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

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

Более того, HTTP часто выступает как протокол-транспорт для трансфера других прикладных протоколов и их API: WebDAV, XML-RPC, REST, SOAP. Ну а данные передаваемые по API могут иметь самый разный формат: XML, JSON и другие.

Как передаются эти данные? Чаще всего по TCP/IP-соединению: приложение-клиент по умолчанию использует TCP-порт 80, а сервер может использовать любой другой, но обычно это тоже 80 порт.

Объект манипуляций в HTTP это ресурс, указываемый в URI запроса клиентского приложения, чтобы корректно идентифицировать «что вообще нужно». Обычно это файлы, данные или логические объекты, которые хранятся на сервере. При этом в запросе можно указать, как именно представить одни и те же данные: какой выбрать формат, кодировку, язык. Такая «фича» позволяет обмениваться не только гипертекстом, но и двоичными данными.

Второй особенностью HTTP является отсутствие сохранения состояния между последовательными парами «запрос-ответ». Но это не проблема, потому что компоненты приложений на клиентской или серверной стороне само могут хранить информацию о состоянии последних запросов и ответов. На стороне клиента такая информация называется cookies («куки»), на стороне сервера - sessions («сессии»).

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

Принимать участие в передаче данных могут и посредники (прокси-сервера), для того чтобы отличить прокси от конечных серверов (т.н. «исходный сервер»).

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

HTTP/2 - а это что за протокол?

Первоначальная версия протокола HTTP появилась в ЦЕРНЕ (CERN) в 1991 году. Уже в 1992 году была опубликована публичная версия HTTP 0.9 и его спецификация, благодаря чему были упорядочены правила взаимодействия между клиентскими и серверными приложениями, а также четкому разграничению функциональности.

В 1996 году появился HTTP/1.0, а современная версия протокола - HTTP/1.1 - в 1999 году. На рубеже тысячелетий, протокол HTTP научился поддерживать режим постоянного соединения, т.е. оставлять соединение открытым после того как получен ответ на запрос. Это позволило за одно соединение посылать сразу несколько запросов, а не открывать-закрывать сессию каждый раз.

Шло время и по мере развития интернета размер страниц увеличивался, росло количество запросов - требовалось все больше ресурсов. Так сформировалась потребность в новом протоколе.

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

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

Ключевые особенности HTTP/2, которые будут полезны для сайтов:

  • Расстановка и управление приоритетами запросов/потоков - клиент самостоятельно задает для сервера приоритетность ресурсов и данных
  • Сжатие HTTP заголовков;
  • Мультиплексирование запросов или параллельная загрузка по TCP-соединению нескольких элементов сайта - через одно соединение отправляется несколько запросов, а ответы клиент может получать в любом порядке т.е. теперь не нужны несколько открытых TCP-соединений;
  • Наличие и поддержка со стороны сервера проактивных push-уведомлений - сервер самостоятельно может отправлять данные для клиента, которые тот еще не запросил (например на основании информации о том, какую страницу пользователь откроет после этой).

Конечно, главное здесь это мультиплексирование потоков. Принцип работы объяснить проще простого: пакеты TCP/IP-соединения смешиваются в рамках одного соединения. Так, в смешанном режиме происходит соединение нескольких «вагонов данных» в один «состав поезда», которые разделяются «по приезду». Ранее «вагоны» были вынуждены ехать дольше и раздельно, сейчас они будут ехать вместе и быстрее.

Вышеперечисленные преимущества протокола HTTP/2 позволят веб-разработчикам дышать полной грудью и отказаться от таких «костылей» как:

  • Использование большего числа родственных доменов для обеспечения установки большого количества TCP/IP-соединений (для скачивания файлов);
  • Спрайты картинок - когда изображения объединяются в один файл, чтобы снизить число запросов к веб-серверу (а сам файл «раздувается» ведь в него записано больше изображений);
  • Объединение CSS- и JS-файлов, которые тоже делаются для уменьшения запросов.

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

Словом, заживем!

HTTP/2 создан и разработан на основе черновика протокола SPDY/3 (Google) и превзошел его - компания Гугл признала преимущества HTTP/2 более многообещающими и в будущем откажется от поддержки SPDY/2.

Прогнозируемое ускорение ответа сервера по протоколу HTTP/2 составит порядка 30%, - реальные тесты уже показали скорости на 19-23% выше и это не предел.

По результатам тестов компании Айри.рф, только от включения протокола HTTP/2 прирост скорости составляет 13-18% (без оптимизации). Почему это важно?

Несмотря на то, что поддержка сайтом протокола HTTP/2 на данный момент не влияет напрямую на ранжирование сайтов в Гугле и Яндекса, на позиции в выдаче влияет скорость загрузки. И раз протокол показывает более высокую скорость загрузки (что является довольно значительным фактором), косвенно он влияет и на ранжирование.

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

Большая часть современных браузеров уже поддерживает HTTP/2 - через них проходит ~70% интернет-трафика:

  • Chrome 41-52 и Chrome 46+ в Android;
  • Firefox 36-48 и Firefox 41+ в Android;
  • Opera 28-34 и Opera 30+ в Android;
  • Safari 9 и Safari в iOS 9.1;
  • IE 11 в Windows 10 и браузер Edge 12, 13.

Когда произойдет полноценный переход на HTTP/2 пока непонятно - вероятнее всего в самом ближайшем будущем. Главное что от HTTP/1.x никто не собирается поспешно отказываться. Как говорится: «Работает - не трогай».

Что значит и где применяется HTTPS-протокол?

Ну, про обмен данными по протоколу HTTP вы уже все знаете: любая передача данных осуществляется через запросы по этому протоколу-транспорту. А зачем тогда нужен HTTPS и что он из себя представляет? Ведь жили же нормально и без него?

Проблема в том что данные по HTTP не защищаются и передаются в открытом виде. Интернет - глобальная распределенная сеть узлов. И если вы передаете открытые данные по незащищенному протоколу (Wi-Fi в ТРЦ сюда тоже относится), то один из этих узлов может перехватить их.

Не специально конечно, может быть просто взлом усилиями злоумышленников. HTTPS и создан для того чтобы соединение было безопасным, а данные передавались в зашифрованном виде по криптографическому протоколу SSL/TLS. Это специальная «обертка» поверх HTTP, она шифрует данные, делая их недоступными для злоумышленников и посторонних людей.

HTTPS - англ. «безопасный протокол передачи гипертекста».

Так что в отличие от 80 порта, используемого по умолчанию в HTTP, в HTTPS используется TCP-порт 443 и есть ключ для шифрования. Ключ может быть длиной 40, 56, 128 или 256 бит, достаточный уровень безопасности на данный момент начинается со 128-битных ключей.

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

Жизненно важно использовать HTTPS в следующих сервисах:

  • Электронные платежные системы (банки, электронные деньги и прочее);
  • Сервисы принимающие и отправляющие приватную информацию и персональные данные, например у Яндекса это: Паспорт, Такси, Директ , Метрика, Почта, Деньги , Вебмастер и другие;
  • Социальные сети и личные кабинеты в интернет-сервисах;
  • Поисковые системы.

Работает HTTPS просто. Объясню на примере.

Вы кладете важную информацию (логин, пароль, данные карты, персональные данные) в ячейку, «запираете ее на ключ»: ячейка шифрует ваши данные при помощи этого ключа.

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

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

Все - вот так просто работает HTTPS.

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

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

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

А вот как выглядит сам сертификат:

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

Осуществляя взаимодействие «клиент-сервер» по протоколу HTTPS можно не беспокоиться за сохранность данных - вы надежно защищены от прослушивания сетевого соединения: атак снифферов и man-in-the-middle.

Что означает перечеркнутый значок HTTPS и зеленый значок HTTPS, в чем разница? В безопасности. Зеленый - безопасный, красный и перечеркнутый - небезопасный.

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

Что лучше HTTP 1.1, HTTP/2 или HTTPS?

В качестве подведения итога затрону тему предпочтительного использования протоколов.

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

При этом, вряд ли возможно, что все сайты перейдут HTTPS, потому что для целей потребления развлекательного контента шифрование ни к чему. Да, сейчас уже 10% сайтов используют HTTPS в рейтинге наиболее посещаемых веб-ресурсов «Alexa». Но это всего десять процентов, среди которых такие гиганты как Гугл, ПейПал, Амазон, Алиэкспресс и другие. То есть множество сайтов, где не использовать HTTPS означает нарушать право интернет-пользователя на безопасность и сохранность данных.

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

Так что в ближайшем будущем мы станем постепенно отходить от HTTP 1.1 в пользу HTTP/2 и HTTPS.

  • Перевод

Недавно вышла новая версия стандарта HTTP. В мае 2015 года был утвержден HTTP/2, который получил распространение среди браузеров и веб-серверов (включая NGINX и NGINX Plus). На данный момент более 60% используемых браузеров поддерживают HTTP/2, причем эта цифра продолжает увеличиваться с каждым месяцем.

Стандарт HTTP/2 основан на протоколе SPDY, разработанном компанией Google. В Google Chrome поддержка SPDY будет осуществляться до начала 2016 года . NGINX одним из первых реализовал протокол SPDY и сейчас играет ведущую роль в продвижении HTTP/2. Была опубликована , в которой дано подробное описание HTTP/2, приводится сравнение со SPDY и подробно описывается процесс внедрения нового протокола.

Основные особенности HTTP/2 аналогичны SPDY:

  • HTTP/2 бинарный, а не текстовый протокол, что делает его компактнее и эффективнее.
  • В HTTP/2 используется только одно мультиплексирующее соединение до хоста, вместо множества соединений передающих по одному файлу.
  • В HTTP/2 используется сжатие заголовков специализированным протоколом HPACK (вместо gzip, который использовался в SPDY).
  • В HTTP/2 применяется сложный механизм приоритезации, чтобы отдавать браузерам наиболее необходимые файлы в первую очередь (в SPDY использовался более простой алгоритм).
Теперь необходимо углубиться и рассмотреть подробнее особенности нового протокола. Эта статья написана с целью помочь принять решение о переходе на HTTP/2, а также рассматривает возможные оптимизации при внедрении протокола.
  1. Терминируйте HTTP/2
  2. Начните с использования SPDY
  3. Откажитесь от HTTP/1.x оптимизации
  4. Внедрите HTTP/2 или SPDY
  5. Пересмотрите HTTP/1.x оптимизации
  6. Рассмотрите дружественный HTTP/2 шардинг
Примечание: строго говоря, для использования SPDY и HTTP/2 не требуется TLS, но основные преимущества проявляются при включении SSL/TLS, поэтому браузеры поддерживают SPDY и HTTP/2 только при наличии SSL/TLS.

Оцените необходимость внедрения HTTP/2

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

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

  1. Используется только одно соединение с сервером вместо множества соединений, передающих по одному файлу. Другими словами, уменьшается количество соединений, что особенно полезно при использовании TLS.
  2. Эффективное использование TLS. HTTP/2 делает только один TLS хэндшейк, а мультиплексирование позволяет эффективно использовать это соединение. HTTP/2 также сжимает данные заголовка, а устранение HTTP/1.x оптимизаций (таких как конкатенация файлов) позволяет алгоритму кэширования работать более эффективно.
  3. Упрощение веб-приложений. При использовании HTTP/2 можно избавиться от HTTP/1.x оптимизаций, которые доставляют лишение неудобства и разработчикам.
  4. Отлично подходит для сложных веб-страниц. HTTP/2 отлично подходит для веб-страниц, которые одновременно используют HTML, CSS, JavaScript, картинки и видеоролики. Браузеры могут приоритезировать запросы к файлам, чтобы наиболее необходимые части страницы присылались в первую очередь.
  5. Безопасность соединения. Хотя при использовании HTTP/2 может произойти потеря производительности из-за использования TLS, но в то же время TLS сделает веб-приложения более безопасными для пользователей.

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

  1. Большие затраты для одного соединения. Алгоритм сжатия данных HPACK требует поддержки таблицы преобразования на обоих концах. Также для одного соединения требуется больше памяти.
  2. Возможно использование TLS избыточно. Если передаваемая информация не нуждается в защите или уже защищена с помощью DRM (или другого шифрования), то в этом случае TLS вряд ли будет полезен.
  3. Поиск и удаление существующих HTTP/1.x оптимизаций необходимы для увеличения производительности HTTP/2, что является дополнительной работой.
  4. Не дает преимуществ при загрузке больших файлов. Если веб-приложение в основном рассчитано на загрузку больших файлов или видеостриминг, то, скорее всего, использование TLS будет ошибочно, а мультиплексирование не принесет никакой пользы.
  5. Безопасность не важна. Возможно посетителям не важно, что видео с котиками, которыми они делятся на вашем сайте, не защищено TLS и HTTP/2 (что может быть верно).
Все сводится к производительности и здесь есть хорошие и плохие новости.

Хорошие новости в том, что исходя из тестов, которые были проведены в NGINX следуют результаты предсказанные из теории: для сложных веб-страниц, запрошенных с типичными задержками (latency), производительность HTTP/2 выше, чем HTTP/1.x и HTTPS. Результаты разделены на три группы в зависимости от типичного round-trip time (RTT):

  • Очень низкое RTTs (0-20 мс): практически никакой разницы между HTTP/1.x, HTTP/2, и HTTPS не наблюдается.
  • Среднее (типичное для интернета) RTTs (30-250 мс): HTTP/2 быстрее чем HTTP/1.x, и оба быстрее чем HTTPS. Для соседних городов в США, RTT составляет около 30 мс, и около 70 мс от одного берега до другого (около 3000 миль). По одному из самых коротких маршрутов между Токио и Лондоном, RTT составляет около 240 мс.
  • Высокое RTTs (300 мс и выше): HTTP/1.x быстрее чем HTTP/2, который быстрее чем HTTPS.

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

Более подробно с процессом тестирования и результатами можно ознакомиться в презентации с конференции nginx.conf 2015.

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

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

Терминируйте HTTP/2

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


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

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

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

Начните с использования SPDY

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

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

Откажитесь от HTTP/1.x оптимизаций

Перед внедрением HTTP/2 необходимо выявить оптимизации для HTTP/1.x. Далее перечислены четыре типа оптимизаций, на которые стоит обратить внимание:
  1. Шардинг. Размещение файлов на разных доменах для параллельной передачи браузеру; сети доставки контента (CDNs) делают это автоматически. Такая оптимизация может повредить производительности HTTP/2. Вы можете использовать дружественный с HTTP/2 шардинг для пользователей HTTP/1.x (см. дружественный HTTP/2 шардинг).
  2. Использование спрайтов. Спрайтами называют коллекции картинок, которые передаются в виде одного файла; после этого на стороне клиента картинки по необходимости извлекаются из коллекции. Эта оптимизация менее эффективна при использовании HTTP/2, хотя все равно может быть полезна.
  3. Объединение файлов. Подобно спрайтам, часть файлов, которые обычно хранятся отдельно, объединяются в один. После чего браузер находит и запускает код по мере необходимости в рамках склеенного файла.
  4. Встраивание файлов. CSS, JavaScript и даже изображения вставляются непосредственно в HTML-файл, что уменьшает количество передаваемых файлов, за счет увеличения исходного HTML-файла.
Последние три типа оптимизации по объединению маленьких файлов в более крупные, сокращению новых связей и инициализации дополнительных соединений, особенно важны при использовании TLS.

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

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

Внедрите HTTP/2 или SPDY

На самом деле переход на HTTP/2 или SPDY довольно прост. Для пользователей NGINX, необходимо просто «включить» протокол в конфигурации NGINX, как описано на примере HTTP/2. После этого, сервер будет уведомлять браузер клиента о возможности использования HTTP/2 или SPDY.

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

Примечание: Так как при включении HTTP/2 используется одно соединение, то некоторые настройки конфигурации в NGINX становятся более важными. Рекомендуется просмотреть конфигурацию NGINX с особым вниманием к настройке и тестированию параметров таких директив, как output_buffers, proxy_buffers и ssl_buffer_size. Следует обратить внимание на , конкретные советы по TLS ( и ), и о производительности NGINX при использовании TLS.

Примечание: При использовании шифров совместно с HTTP/2, следует обратить внимание на следующее: RFC для HTTP/2 имеет длинный список шифров, которых следует избегать. Если у вас есть желание настроить список шифров самостоятельно, то в таком случае рекомендуется рассмотреть настройку ssl_ciphers и включение ssl_prefer_server_ciphers on , после чего протестировать подходящие шифры со всеми популярными версиями браузеров. Индикатор для популярных браузеров Qualys’ SSL Server test (на ноябрь 2015) считается ненадежным для подсчета HTTP/2 хэндшейков .

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

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

  • Все уже готово. Если приложения не были оптимизированы под HTTP/1.x или были сделаны незначительные изменения, то все готово, чтобы использовать HTTP/2.
  • Смешанный подход. Можно уменьшить конкатенацию данных, но не устранить полностью. Например, некоторые спрайты изображений могут остаться, в то же время избавиться от данных, встроенных в HTML.
  • Полный отказ от HTTP/1.x оптимизации (но см. дружественный HTTP/2 шардинг и примечания). Можно просто полностью избавиться от оптимизаций.
Кэширование имеет некоторые особенности. В теории кэширование работает эффективно в случае, когда применяется ко множеству небольших файлов. Тем не менее, в этом случае выполняется большое количество операций I/O. Поэтому объединение связанных между собой файлов может быть полезным, как для рабочего процесса, так и для производительности приложений. Шардинг является, пожалуй, самой непростой, и в то же время, возможно, самой успешной стратегией оптимизации HTTP/1.x. Шардинг можно использовать для повышения производительности HTTP/1.x, но для HTTP/2 (в котором используется только одно соединение) он в основном игнорируется.

Для использования шардинга в паре с HTTP/2, следует сделать две вещи:

  • Сделать так, чтобы доменные имена для шардинговых ресурсов резолвились в одинаковые IP-адреса.
  • Убедиться в том, что используется wildcard-сертификат - в таком случае он будет валидным для всех доменных имен, используемых при шардинге. Либо убедиться, в наличии соответствующего мультидоменного сертификата.
Подробную информацию можно найти .

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

Заключение

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

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

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