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

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

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

Настоящие ловушки HTTP/1

Согласно исследованиям Google, для загрузки веб-страницы требуется в среднем 100 запросов. С HTTP/1 браузер может установить максимум 6 параллельных соединений с сервером. В результате на одно соединение приходится около 16 ресурсов. Предполагая, что среднее время загрузки каждого ресурса составляет 35 мс, для загрузки всех ресурсов потребуется примерно 500 мс. То есть полсекунды ожидания и ничегонеделания! Примите во внимание тот факт, что браузеру нужно запускать скрипты после загрузки, строить DOM, рисовать на экране и т. д. — это будет казаться вечностью. Если доступ к странице осуществляется с мобильного устройства с более низкой пропускной способностью в географическом регионе, удаленном от сервера на полмира, это будет просто рецепт разочарования пользователя.

HTTP/2 в помощь

HTTP/2 был разработан для обеспечения скорости и безопасности. Это формализованная эволюция SPDY, протокола, разработанного Google для повышения скорости загрузки страниц. Он обеспечивает безопасность, применяя TLS. Хотя спецификация не обеспечивает принудительного применения, все основные поставщики браузеров отказались от поддержки HTTP/2 без TLS, тем самым обеспечивая безопасность.

Как HTTP/2 решает проблему скорости загрузки страницы? Для начала вместо 6 параллельных соединений между браузером и сервером он устанавливает одно соединение. Я знаю, вы думаете: «Как одно соединение вместо шести сделает его быстрее?». Секрет в том, как данные загружаются в одно доступное соединение, которое, как доказано, увеличивает время загрузки страницы до 50%. Давайте посмотрим на некоторые основные изменения в HTTP/2:

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

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

  1. Сжатие заголовков
  2. Передача ссылок на заголовки вместо фактических заголовков

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

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

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

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

Если это было слишком сложно, просто рассмотрите это как разборку данных на одном конце связи и повторную сборку на другом конце.

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

Отправить сервер

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

При традиционном общении браузер запрашивает, скажем, index.html, а сервер возвращает его. Затем браузер начинает анализировать его и понимает, что ему нужен определенный файл CSS, а затем запрашивает его. Далее при парсинге он натыкается на файл JavaScript и запрашивает его и так далее.

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

Я разработчик приложений — что теперь?

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

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

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

Браузеры поддерживают переключение между HTTP/1 и HTTP/2.В зависимости от того, поддерживает ли сервер HTTP/1 или HTTP/2, браузер автоматически переключает передачи. Разработчику приложений делать нечего. О поддержке браузерами HTTP/2 можно узнать на caniuse.

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

Веб-серверы. Большинство веб-серверов, включая облачные решения, такие как AWS, Google Cloud и т. д., уже поддерживают HTTP/2. Другие популярные веб-серверы, такие как Apache, Nginx и другие, также могут быть настроены для HTTP/2. Для тех, кто хочет знать, как это делается, этот замечательный пост покажет вам именно это.

Вывод

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

Хотя в HTTP/2 есть много других замечательных функций, таких как приоритизация потоков, управление потоком и т. д., цель этого поста — дать некоторое базовое знакомство с HTTP/2 и подчеркнуть необходимость начать использовать HTTP/2. Я изучил свои основы, читая сообщения в блоге и это замечательное введение в HTTP/2, написанное Ильей Григориком и Сурма на developers.google.com.