В 2012 году был объявлен конкурс идей для новой версии HTTP. Это очень значительная перемена, так как HTTP по сути уже влияет на нашу повседневную жизнь. Скорее всего, наших рабочих мест, компаний и прочего и не существовало бы без HTTP. Этот конкурс, пожалуй, возвестил начало новой эры для интернет-сообщества. Ведь речь идет о принципиально новой версии протокола, ставшего уже священным.
Зачем что-то менять? Давайте мысленно вернемся в 1999 год, когда HTTP/1.1 позволял публиковать веб-сайты, состоящие из некоторого текста, пары картинок, ну, и, возможно, рекламного баннера. Это было слишком просто. К Интернету мы, кстати, подключались через 56k модем. Перемещаемся на 16 лет вперед – 16 лет, ставшими целой эпохой для Интернета – смотрите, все изменилось. Изменилось намного сильнее, чем мы ожидали. Теперь, если страница загружается не моментально, то мы думаем, что она загружается очень медленно. Мало того, эта страница еще должна быть отзывчивой и адаптироваться под любое устройство, с которого ее будут просматривать. Нам нужно все это для удобной работы в Интернете со своих смартфонов и планшетов в любой точке мира. Не кажется ли, что это слишком жесткие требования для того, что было изобретено всего пару десятилетий назад
Цели HTTP/2 были довольно просты: улучшить производительность HTTP, воздействовать на столь широко используемый сегодня протокол. Другими словами – заставить сайты загружаться и работать быстрее.
Спустя три года, вложив огромное количество труда, IETF утвердили HTTP/2 стандарт. Лидирующие браузеры поддерживают его. Каждый, кто использует последние версии Firefox, Chrome или использует Internet Explorer, входящий в комплект Windows 10, вероятно, уже используют HTTP/2.
Что это такое?
HTTP/2 имеет множество функций, которые помогут ускорить работу в Интернете. Вот, пожалуй, главные из них:- Мультиплексинг
- Сжатие заголовков
- Зависимости и приоритеты
- Технология Push (Server push)
Мультиплексинг
Мультиплексинг для HTTP подразумевает запрашивание и получение более чем одного элемента за единицу времени. Это «вылечит» имевшую место быть в HTTP/1.1 возможность блокировки линии.
Каждый запрос от клиента должен ждать, пока сервер ответит на предыдущие запросы. Это может занять много времени, если, например, данная веб страница содержит порядка 100 объектов. И каждый из этих запросов может быть отправлен по разным причинам, что еще сильнее снизит скорость загрузки страницы. Так, при HTTP/1.1 браузеры использовали множественные подключения к серверу для достижения некоторого подобия параллеллизации запросов, но это не решало проблемы скорости загрузки и блокировки линии.
HTTP/2 — это binary framed протокол. Это означает, что запросы к серверу и его ответы распределяются по небольшим комплексам, называемым фреймами, те, в свою очередь, несут в себе мета-информацию, которая идентифицирует, с какими запросами и ответами они ассоциированы. Это позволяет запросам/ответам, касающимся обработки множественных объектов перекрыть это соединение, не вызывая путаницы. Получены ответы будут тогда, когда сервер сможет их выдать. Например, первый запрос может быть сложнее, что требует больше времени на его обработку, но он не будет блокировать обработку следующих за ним объектов. Как результат — быстрая загрузка и визуализация страницы.
Сжатие заголовков
Заголовки — это мета информация, которую браузер отправляет вместе с запросами, чтобы лучше информировать сервер о том, что ему нужно. Изначально заголовки весят не так много. Браузер, например, использует заголовки, чтобы указать сервер на то, что он поддерживает сжатие gzip или WebP изображения. Одна из характеристик заголовков в том, что они особо не изменяются между запросами. Согласно природе HTTP/1, браузеру необходимо объявлять о том, является ли данный формат файла или язык поддерживаемым. Эти объявления могут генерировать много избыточных байтов.
HTTP/2 помогает решить проблему. С помощью комбинации lookup-таблиц и Huffman-кодирования возможно сократить количество байт в запросе вплоть до нуля. В течение конкретной веб-сессии в степени сжатия ~90% нет ничего необычного, и в случае со среднестатистической страницей это почти никак не влияет на сторону, отвечающую на запросы. Однако для стороны, которая запросы отправляет, результаты довольно ощутимы. Даже скромная страничка с примерно 75 объектами, и средним заголовком размером в где-то 500 байт, может заставить браузер 4 раза по кругу пытаться отправлять запросы до того, как они наконец все будут отправлены. Со этими же параметрами страницы, но с использованием сжатия 90%, которое дает нам HTTP/2, браузер может отправить все эти запросы за один раз.
Выстроение зависимостей и приоритезация
Мультиплексинг и сжатие заголовков имеют огомное значение, но они также создают некоторую проблему. Разработчики браузеров ввели специальные пре-лоадеры чтобы при отправке запросов сортировать их по важности. Например, CSS код очень важен для определения вида страницы, а логотип, который находится в футере сайта — не очень. Значит CSS запрашивается первым. Но, согласно новой модели HTTP/2, браузер должен запрашивать все одновременно, чтобы позволить серверу вернуть результат максимально быстро. Ирония в том, что стандарт HTTP/2, Как мы писали выше, ускоряет загрузку страниц за счет того, что запросы сбиваются в отдельные группы, и ответы сервер возвращает примерно в таком же виде, но такая система противоречит той, которую внедрили разработчики браузеров — согласитесь, логично, что сортировка запросов по важности удобнее осуществляется тогда, когда каждый запрос находится отдельно от остальных. Вместо того, чтобы решать проблему в браузерах, разработчики решают эту проблему путем модификаций протокола. Если сообщить серверу, какой объект зависит от какого, то он может выстроить некоторый приоритет, обозначить «критические» Данные и обеспечить получение их браузером в первую очередь.
Push технология (Server push)
Один из способов решения проблемы задержки запросов HTTP и получения ответов от сервера является отправка браузеру объектов до того, как он их запросит. Это тот момент, когда включается Server Push. Преимущество, на первый взгляд, очевидно — вся страница доставляется почти моментально даже при худших условиях. Но для того, чтобы «подтолкнуть» правильные (нужные) объекты, сервер каким-то образом должен знать, какие из них понадобятся пользователю в данный момент, и в каком стоянии кэш браузера. Это сложно, поэтому общих универсальных приложений для работы технологии server push пока не существует в протоколах типа SPDY. Несмотря на то, что HTTP/2 обеспечивает некоторый инструмент для этой технологии, этого недостаточно, но я думаю, что мы увидим инновации в этой области в ближайшем будущем.