Что такое http 2: что это и зачем он вам

Posted:

Дек 28, 2022

Comments:

Что такое http 2: что это и зачем он вам — SEO на vc.ru

Содержание

что это и зачем он вам — SEO на vc.ru

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

3668
просмотров

Наглядное отличие принципа работы протокола HTTP/2 от HTTP/1

Необходимое предисловие

Меня спросят: «Эй, а ты зачем в 2022 году вообще пишешь про HTTP/2, когда на подходе HTTP/3?» – и я скажу вот что. Я регулярно провожу аудиты сайтов, в том числе – в рамках конкурентного анализа. В аудит входит и проверка используемого протокола передачи данных. И увы, вижу, что примерно половина сайтов работает на уже устаревшем протоколе данных, а многие полезные фичи HTTP/2 используются разве что теми, кто использует выделенные сервера.

Личное же общение со многими вебмастерами показывает, что они либо вообще не знают об имеющихся возможностях, либо что-то такое слышали, но без подробностей. А тема – достаточно важная, чтобы потратить пять-десять минут на ликбез. К нему и перейдём.

Что происходит во время загрузки сайта

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

Браузер запрашивает IP заданного домена, обращаясь к серверу доменных имен (DNS). Домен – это просто имя, понятное человеку, а вот IP можно сравнить с телефонным номером этого человека.
Получив данные об IP сайта, браузер обращается к нему через TCP-соединение через один из стандартных портов: 80-й порт для сайтов без SSL, или через защищенный 443 порт, если настроен HTTPS.
После подключения браузер отправляет запросы, а сервер отправляет в ответ HTML или перенаправляет на другой URL, или сообщит, что тут такого нету (404).
Браузер обрабатывает ответ сервера, анализирует полученный HTML и начинает выстраивать объектную модель документа (DOM). В процессе анализа он обнаруживает ссылки на дополнительные ресурсы, которые нужны для правильного отображения страницы, и запрашивает их у сервера. Некоторые из этих ресурсов содержат дополнительные ссылки на другие ресурсы, и эти ссылки добавляются в список запросов.
Получив достаточный объём этих ресурсов, браузер наконец-то начинает процесс рендеринга страницы, и посетитель сайта (вы) его уже видит. Однако это ещё не конец: браузер продолжает подгружать картинки, вспомогательные скрипты, виджеты и т.п.
По завершении процесса загрузки браузер запускает событие OnLoad Javascript, страничка готова к работе. Однако и это ещё не конец: страничка может что-то подгружать фоном, отправлять данные в системы статистики и т.д.

Каскадная диаграмма загрузки сервиса webpagetest.org наглядно показывает, что, когда и как происходит во время загрузки сайта

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

Особенности HTTP ранних версий

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

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

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

С появлением метода HEAD клиент мог загружать все метаданные, не загружая сам ресурс. Благодаря этому поисковые системы смогли проверять, обновлялся ли URL, и загружать только обновленные данные.

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

Большим ограничением протокола стала количество одновременно отправляемых запросов, в среднем – 5-8, тогда как среднестатистический сайт уже 10 лет назад редко ограничивался 50-70.

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

HTTPS

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

Протокол HTTPS шифрует передаваемые сообщения с помощью протокола TLS или уже устаревшего SSL. Благодаря HTTPS протокол HTTP получил три важных свойства:

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

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

Но самое важное в контексте этой статьи: протокол HTTPS подразумевает дополнительные запросы и «рукопожатия», ещё более осложняя процесс отправки запросов и загрузки данных.

Основные проблемы HTTP/1

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

В результате развития протокола HTTP стало возможным передавать не только текстовое содержимое, но и мультимедийные файлы, сохранять соединение открытым и отправлять несколько запросов одновременно. Современный сайт загружает около 2,3 МБ данных при отправляемых 70 запросов в целом (фактически, число запросов может доходить до 150 на плохо оптимизированном шаблоне). С учётом того, что современный интернет в большей мере – мобильный, загрузка такого сайта становится слишком долгой.

Проблему можно охарактеризовать несколькими основными моментами:

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

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

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

Как решаются проблемы быстродействия HTTP/1.1

Основными решениями долгие годы были следующие способы оптимизации быстродействия:

Уменьшение количества запросов благодаря объединению ресурсов (минимизируем CSS и JS, объединяем файлы, вместо отдельных картинок используем CSS-спрайты и т.п.)
Создание параллельных HTTP-соединений и использование CDN
Приоритизация списка запросов (сначала – HTML, важнейшие CSS, потом изображения и JS)
Сжатие используемых ресурсов (в первую очередь – мультимедийных файлов) и использование изображений в сильно «пожатых» веб-форматах
Передача данных в архивированном виде (gzip)

и т.п.

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

Создание параллельных HTTP-соединений было самым простым. Однако и тут есть ограничение в 4-8 соединений на домен. Чтобы обойти это ограничение, статические ресурсы размещают на CDN (файловом сервере) или на вспомогательном домене, открывающем дополнительные соединения. Благодаря тому, что речь идёт о другом домене (субдомене), браузер видит несколько разных серверов и может обращаться к ним одновременно.

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

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

HTTP/2

В 2014 году спецификация HTTP/2 была утверждена как стандарт, а с 2015 года получила поддержку во всех основных браузерах. Новые возможности включали:

Мультиплексированная асинхронная передача данных: на одном соединении запросы разделяются на чередующиеся пакеты, сгруппированные в отдельные потоки.
Запросы приоритизируются, благодаря чему снимается проблема с одновременной отправкой всех запросов.
Реализовано сжатие HTTP-заголовков. Каждый отправленный заголовок содержит информацию об отправителе и получателе, а это – избыточные объёмы. Благодаря сжатию полная информация отправляется только в первом заголовке, в последующих отправленных заголовках такой информации уже нет.
В отличие от текстового протокола HTTP, HTTP/2 — бинарный. Благодаря этому можно обрабатывать небольшие сообщения, из которых формируются более крупные.
Server Push. Если в версии HTTP/1 браузер должен был сначала получить домашнюю страницу, и лишь из неё понять, какие ресурсы ему необходимы для рендеринга, то HTTP/2 позволяет отправить все необходимые ресурсы сразу, при первичном обращении к серверу.

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

Наглядное отличие в работе протокола HTTP/2 от предшественника

Главное отличие этого протокола – использование двоичных данных вместо текстовых. Компьютерам сложнее работать с текстами, чем с двоичным протоколом. Кроме того, современный интернет уже сложно представить в исключительно текстовом формате.

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

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

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

Браузеру уже не нужно составлять очередь из запросов, поскольку все или почти все запросы можно отправить разом (лимит в среднем составляет сотню запросов). Единственный негативный момент: это может привести к снижению пропускной способности, особенно если вы используете неоптимизированные изображения.

Важно определить приоритеты потоков, чтобы в первую очередь сервер отправлял важнейшие ресурсы. Это делается на уровне сервера. С помощью push-загрузки сервер может сразу отправить важные CSS и JS, и браузер может отобразить страницу быстрее, поскольку всё важное уже попало в браузерный кэш.

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

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

Рассмотрим, что именно может стать лучше при переходе на HTTP/2.

Если вы всерьёз тратили ресурсы (время и деньги) на оптимизацию процессов загрузки – можете расслабиться. Практика показывает, что в среднем одно лишь внедрение HTTP/2 способно улучшить ваши показатели на 50-80% благодаря ликвидации задержки в отправке запросов. Однако надо понимать, что в ряде случаев внедрение HTTP/2 может сказаться и негативно. Эти случаи рассмотрим ниже.
Отпадает необходимость использования CDN для ускорения загрузки сайта. При достаточной пропускной полосе вы можете загружать быстрее даже «тяжелые» медиа. Однако учитывайте, что CDN полезны не только оптимизацией процессов загрузки за счёт увеличения количества потоков. CDN – это в большей мере про ближайший к вашему посетителю сервер, вопросы безопасности и т.д.
Упрощается процесс сканирования сайта поисковыми роботами, что критически важно для Google с его лимитами на обход сайта. Известно, что даже при возможности использовать HTTP/2 гуглобот может использовать старый протокол передачи данных (HTTP/1.1), и повлиять на это нельзя. Но если речь идёт о большом и нагруженном сайте, явно стоит предоставить роботу такую возможность.
Снимается ряд проблем с Core Web Vitals. Браузер сразу получает все критически важные ресурсы, и процесс рендеринга страницы проходит быстрее, более плавно, без необходимости перестраивать блоки по мере получения новой информации о странице. Это, как минимум, должно положительно сказываться на пользовательском опыте: вашему посетителю не придётся чертыхаться, не попав в нужную кнопку или попав в ненужную.
Поведенческие боты преимущественно используют протокол HTTP/1 и HTTP/1. 1. Если вы хотите заблокировать их – обрубайте такой трафик. Учтите, что по этому протоколу могут идти и люди, использующие какие-нибудь дико устаревшие браузеры, но их количество – околонулевое.

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

Возможные проблемы с HTTP/2

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

В некоторых случаях запросы могут требовать больше времени, если у клиента или сервера низкая пропускная способность. Это может негативно сказываться на подгрузке файлов большого размера и легко объясняется физически. Одно соединение HTTP/2 с малой пропускной способностью потребует больше времени, чем несколько соединений HTTP/1. 1 с очередью из нескольких запросов.
HTTP/2 не устраняет полностью все проблемы своего предшественника: вы просто получаете возможность одновременно отправлять 100 запросов вместо 5-8. По достижении лимита вам так же придётся ждать выполнения первых запросов. Для шаблона сайта, отправляющего 150 запросов к серверу, это ощутимо, просто эффект проявляется реже и чуть слабее. Хотя надо понимать, что для посетителя важнее общее время загрузки, и тут HTTP/2 получает явное преимущество перед HTTP/1.1.
Если вы уже использовали основные трюки по оптимизации загрузки сайта, прирост скорости загрузки может быть менее заметен. HTTP/2 обеспечивает подобные результаты без серьёзных усилий, состоящих из минификации и объединения файлов, сжатия изображений, искусственного увеличения количества потоков и т.п.

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

Как подключить

Единого способа нет, реализация в каждом конкретном случае зависит от сервера или хостинг-провайдера. В некоторых случая всё предельно просто. Например, на Timeweb вопрос решается единственной кнопкой. Возможности, правда, тоже очень ограничены.

Подключение HTTP/2 на хостинге

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

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

Как проверить, доступен ли ваш сайт по HTTP/2

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

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

Воспользуйтесь одним из онлайн-сервисов. Их много. Начните с https://http2.pro/

Старый сервер ещё не поддерживает HTTP/2

Посмотрите на результаты аудита странички в Lighthouse (Chrome). Если HTTP/2 недоступен, вы увидите соответствующую рекомендацию.

Воспользуйтесь инструментами разработчика в консоли Chrome. В списке ресурсов в колонке «Протокол» они будут помечены как «h3». (Колонка «Протокол» по умолчанию не отображается. Кликните правой кнопкой по заголовку таблички и поставьте галочку в соответствующей строке).

С помощью консоли в Chrome вы можете увидеть, по какому протоколу доступны ресурсы сайта

Заключение

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

И не забывайте: веб-технологии не стоят на месте, и уже скоро стандартом станет новый протокол, известный сейчас как QUIC – его чаще всего и называют HTTP/3. Поддержка QUIC в современных браузерах уже есть, но я ни разу не слышал, чтобы виртуальный хостинг в РФ уже предлагал клиентам этот протокол. Кроме того, при нынешней моде на блокировки всего подряд HTTP/3 также попадает под раздачу – но это тема для совершенно других материалов.

В чем разница между HTTP/1.1 и HTTP/2?

Hypertext Transfer Protocol, или HTTP – это протокол прикладного уровня, который с момента изобретения (в 1989 году) является стандартом для связи во Всемирной паутине. С момента выпуска HTTP/1.1 в 1997 году и до недавнего времени в протокол было внесено не так уж много изменений. Но в 2015 году появилась новая версия HTTP/2, в которой предлагается несколько способов снижения задержки, особенно при работе с мобильными платформами, а также с графикой и видео, интенсивно использующими сервер. С тех пор протокол HTTP/2 становится все более популярным: по некоторым оценкам, его поддерживают около трети всех веб-сайтов в мире. В этом переменчивом ландшафте веб-разработчики должны понимать технические различия между HTTP/1.1 и HTTP/2 и использовать их преимущества. Это позволяет принимать обоснованные и эффективные решения.

Разработанный Тимоти Бернерсом-Ли (Timothy Berners-Lee) в 1989 году в качестве стандарта связи для Всемирной паутины, HTTP – это протокол верхнего (прикладного) уровня, который обеспечивает обмен информацией между клиентским компьютером и локальным или удаленным веб-сервером. В этом процессе клиент отправляет текстовый запрос на сервер, вызывая метод (GET или POST). В ответ сервер отправляет клиенту ресурс, например, HTML-страницу.

Этот запрос использует метод GET, который запрашивает данные с хост-сервера, указанного после Host:. В ответ на этот запрос веб-сервер example.com возвращает клиенту HTML-страницу вместе с изображениями, таблицами стилей или другими ресурсами, запрашиваемыми в HTML. Обратите внимание, что при первом обращении к данным клиенту возвращаются не все ресурсы. Запросы и ответы будут передаваться между сервером и клиентом до тех пор, пока веб-браузер не получит все ресурсы, необходимые для отображения содержимого HTML-страницы на вашем экране.

Хост (браузер)		Цель (веб-сервер)
↓		↑
Прикладной уровень (HTTP)		Прикладной уровень (HTTP)
↓		↑
Транспортный уровень (TCP)		Транспортный уровень (TCP)
↓		↑
Сетевой уровень (IP)		Сетевой уровень (IP)
↓		↑
Канальный уровень		Канальный уровень
————→ Интернет ————→

HTTP/2 появился как протокол SPDY, разработанный в основном в Google с целью снижения задержки загрузки веб-страниц такими методами, как сжатие, мультиплексирование и приоритизация. Этот протокол послужил шаблоном для HTTP/2, когда группа httpbis (это рабочая группа Hypertext Transfer Protocol) из IETF (Internet Engineering Task Force) объединила стандарт. Так в мае 2015 года случился релиз HTTP/2. С самого начала многие браузеры (включая Chrome, Opera, Internet Explorer и Safari) поддерживали эту попытку стандартизации. Частично благодаря этой поддержке с 2015 года наблюдается высокий уровень внедрения протокола, особенно среди новых сайтов.

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

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

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

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

К сожалению, в этой стратегии оптимизации есть узкое место. Поскольку при отправке в один и тот же пункт назначения несколько пакетов данных не могут проходить друг через друга, возникают ситуации, когда запрос в начале очереди, который не может извлечь требуемый ресурс, блокирует все запросы, находящиеся за ним. Это называется блокировкой очереди (head-of-line blocking, или HOL) и представляет собой серьезную проблему оптимизации эффективности соединения в HTTP/1.1. Добавление отдельных параллельных TCP-соединений может решить эту проблему, но в протоколе существуют ограничения на количество одновременных TCP-соединений между клиентом и сервером, и каждое новое соединение требует значительных ресурсов.

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

Поток 1

↔

Поток N

Сообщение 1

Сообщение 2

Сообщение N

Сообщение 1

Сообщение 2

Сообщение N

кадр

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

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

Единое соединение TCP также повышает производительность протокола HTTPS, поскольку клиент и сервер могут повторно использовать один и тот же защищенный сеанс для нескольких запросов/ответов. В HTTPS во время рукопожатия TLS или SSL обе стороны договариваются об использовании одного ключа в течение сеанса. Если соединение прерывается, начинается новый сеанс, для которого требуется новый сгенерированный ключ. Таким образом, поддержание одного соединения может значительно уменьшить ресурсы, необходимые для работы HTTPS. Обратите внимание: хотя спецификации HTTP/2 не требуют использовать уровень TLS, многие основные браузеры поддерживают только HTTP/2 с HTTPS.

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

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

Как вы теперь знаете, двоичный уровень кадрирования организует сообщения в параллельные потоки данных. Когда клиент отправляет параллельные запросы на сервер, он может расставить приоритеты запрашиваемых им ответов, присваивая вес от 1 до 256 каждому потоку. Чем выше вес, тем выше приоритет. Кроме того, клиент также определяет зависимости между потоками (указывая ID потока, от которого будет зависеть тот или иной поток). Если родительский идентификатор опущен, считается, что поток зависит от корневого потока.

Канал
Stream ID=1	Stream ID=2	Stream ID=3	Stream ID=4	Stream ID=5	Stream ID=6
Parent ID=nil	PID=1	PID=2	PID=2	PID=3	PID=3
Вес=4	Вес=6	Вес=2	Вес=4	Вес=6	Вес=6

На этой иллюстрации канал содержит шесть потоков, каждый из которых имеет уникальный идентификатор и связан с определенным весом. Поток 1 не имеет родительского ID, связанного с ним, и по умолчанию связан с корневым узлом. Все остальные потоки помечены родительским ID. Распределение ресурсов для каждого потока будет основываться на их весе и зависимостях, которые им требуются. Например, потоки 5 и 6, которым на рисунке назначен одинаковый вес и один и тот же родительский поток, при распределении ресурсов будут иметь одинаковую приоритетность.

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

SID=Stream ID

		*
		↓
		SID=1 Вес=4
		↓
		SID=2 Вес=6
		↓
	← ←	← ↔ →	→ →
	↓		↓
	SID=3 Вес=2		SID=4 Вес=4
← ←	← ↔ →	→ →
↓		↓
SID=5 Вес=6		SID=6 Вес=6

В этом дереве зависимостей поток 1 зависит от корневого потока. Поскольку это единственный поток, порождаемый корневым потоком, все доступные ресурсы будут выделяться потоку 1 раньше других. Поскольку дерево указывает, что поток 2 зависит от завершения потока 1, поток 2 не будет обрабатываться, пока не будет завершена задача потока 1. Теперь давайте рассмотрим потоки 3 и 4. Оба они зависят от потока 2. Как и в случае с потоком 1, поток 2 получит все доступные ресурсы раньше, чем 3 и 4. После того, как поток 2 завершит свою задачу, потоки 3 и 4 получат ресурсы; они делятся в соотношении 2: 4, в соответствии с их весом, что передает большую часть ресурсов потоку 4. Наконец, когда поток 3 будет обработан, доступные ресурсы в равных частях получат потоки 5 и 6. Это может произойти до выполнения потока 4, даже если поток 4 получает большую часть ресурсов. Потоки более низкого уровня могут запускаться, как только завершатся потоки верхнего уровня, от которых они зависят.

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

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

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

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

В HTTP / 1.1 управление потоком основывается на базовом TCP-соединении. Когда это соединение инициируется, клиент и сервер устанавливают размеры буфера, используя системные настройки по умолчанию. Если буфер получателя частично заполнен данными, он сообщит отправителю свое окно приема, то есть количество доступного пространства, которое остается в буфере. Это окно приема объявляется в сигнале, известном как пакет ACK (это пакет данных, который отправляет приемник, чтобы подтвердить, что он принял сигнал открытия). Если этот объявленный размер окна приема равен нулю, отправитель не будет отправлять данные, пока клиент не очистит свой буфер и затем не запросит возобновить передачу данных. Здесь важно отметить, что использование окон приема, основанных на базовом TCP-соединении, может реализовать управление потоком на одном из концов соединения.

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

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

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

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

В типичном веб-приложении клиент отправляет GET-запрос и получает страницу в формате HTML. Обычно это индексная страница сайта. Исследуя содержимое страницы, клиент может обнаружить, что для полной визуализации страницы ему необходимо извлечь дополнительные ресурсы, такие как файлы CSS и JavaScript. Клиент определяет, что эти дополнительные ресурсы ему нужны, только после получения ответа от исходного GET-запроса. Таким образом, он должен сделать дополнительные запросы для извлечения этих ресурсов и завершения соединения страницы. Эти дополнительные запросы в конечном итоге увеличивают время загрузки.

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

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

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

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

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

В HTTP/2 этот процесс начинается, когда сервер отправляет кадр PUSH_PROMISE, чтобы сообщить клиенту, что он собирается отправить ресурс. Этот кадр включает в себя только заголовок сообщения и позволяет клиенту заранее узнать, какой ресурс отправит сервер. Если ресурс уже кэширован, клиент может отклонить отправку, отправив в ответ кадр RST_STREAM. Кадр PUSH_PROMISE также предотвращает отправку дублированного запроса на сервер (поскольку клиент знает, какие ресурсы сервер собирается отправить).

Здесь важно отметить, что Server Push делает акцент на контроль клиента. Если клиенту необходимо отрегулировать приоритет Server Push или даже отключить его, он может в любое время отправить кадр SETTINGS для изменения этой функции HTTP/2.

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

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

Такие программы, как gzip, давно используются для сжатия данных, отправляемых в сообщениях HTTP, особенно для уменьшения размера файлов CSS и JavaScript. Однако компонент заголовка сообщения всегда отправляется в виде простого текста. Несмотря на то, что каждый заголовок довольно мал, объем этих несжатых данных увеличивает нагрузку на соединение по мере того как клиент отправляет больше запросов. Особенно это касается сложных веб-приложений с тяжелым API, которые требуют много разных ресурсов и, следовательно, много разных запросов. Кроме того, использование файлов cookie иногда может значительно увеличить заголовки, что, в свою очередь, увеличивает потребность в сжатии.

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

Поля в этих запросах (method, scheme, host, accept и user-agent) имеют одинаковые значения; только поле path использует другое значение. В результате при отправке запроса 2 клиент может использовать HPACK для отправки индексированных значений, необходимых для восстановления общих полей и нового кодирования поля path. Кадры заголовка будут выглядеть следующим образом:

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

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

HTTP/2 был выпущен в 2015 году как основная версия протокола HTTP/1.1. Он был создан на основе протокола SPDY как способ улучшить работу в Интернете за счет ускорения загрузки страниц и сокращения времени приема-передачи (RTT), особенно на ресурсоемких веб-страницах.

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

В 2010 году Google выпустила протокол SPDY, чтобы изменить способ обработки запросов и ответов HTTP. Его внимание было сосредоточено на сокращении задержки с помощью конвейерной обработки TCP и обеспечении обязательного сжатия, среди других функций.

Хотя HTTP/2 изначально создавался по образцу SPDY, вскоре он был изменен, чтобы включить уникальные функции, в том числе фиксированный алгоритм сжатия заголовков (в отличие от динамического сжатия на основе потоков SPDY). После его выпуска Google объявил, что прекратит поддержку SPDY в пользу HTTP/2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted:

Comments: