На вершине инфраструктуры Интернета поверх физического уровня находятся стек протоколов TCP/IP известные как протоколы транспортного и сетевого уровней. Это суть, лежащая в основе большинства интернет-коммуникаций.
Уровень протокола более высокого уровня, который мы используем поверх этого, является прикладным уровнем. На этом уровне различные приложения используют разные протоколы для соединения и передачи информации. У нас есть SMTP, POP3 и IMAP для отправки и получения электронной почты, IRC и XMPP для чата, SSH для удаленного доступа и т. д.
Наиболее известным протоколом среди них, который стал синонимом использования интернета, является HTTP (протокол передачи гипертекста). Это то, что мы используем для доступа к веб-сайтам каждый день. Он был разработан Тимом Бернерсом-Ли в CERN еще в 1989 году. Спецификация для версии 1.0 была выпущена в 1996 году (RFC 1945) и 1.1 в 1999 году.
Спецификация HTTP поддерживается консорциумом World Wide Web и может быть найдена здесь.
Первое поколение этого протокола — версии 1 и 1.1 — доминировало в сети вплоть до 2015 года. Но с выходом протокола HTTP/2 отрасль отреагировала быстрым внедрением его в браузеры и веб-серверы.
HTTP/1
HTTP — это протокол без сохранения состояния, основанный на структуре «запрос-ответ» и означает, что клиент делает запросы к серверу, но эти запросы являются атомарными: любой отдельный запрос не знает о предыдущих запросах. (Вот почему мы используем файлы cookie — для устранения разрыва между несколькими запросами в одной пользовательской сессии, например, чтобы иметь возможность обслуживать персональную версию веб-сайта для зарегистрированных пользователей.)
Передачи обычно инициируются клиентом, то есть браузером пользователя, и серверы в большинстве случаев просто отвечают на эти запросы.
Можно сказать, что текущее состояние HTTP довольно «примитивное», а еще лучше — низкоуровневое, с большим количеством «подсказок», которые необходимо предоставить браузерам и серверам о том, как эффективно взаимодействовать.
Во многих отношениях, данная модель с атомарной концепцией запрос-ответ, стала узким местом и многими лидерам индустрии таким как Google, Facebook пришлось прибегать к необычным методам обхода ограничений.
Обычный сценарий, который реализуется различными способами, заключается в том, что посетитель запрашивает веб-страницу, а когда браузер получает ее от сервера, то он парсит HTML и находит другие ресурсы, такие как CSS и изображения и JavaScript, необходимые для отображения страницы. Обнаружив эти ссылки на ресурсы, браузер перестает загружать все остальное и запрашивает у сервера указанные ресурсы. Он не двигается ни на миллиметр, пока не получит этот ресурс. Затем он запрашивает другой и так далее. Данный процесс включает в себя много очередей, обращений туда и обратно, во время которых наш посетитель видит только белый экран или не наполненный контентом сайта. Это потраченные впустую секунды. Большая часть доступной полосы пропускания простаивает и не используется во время этих циклов запроса.
CDN могут облегчить многие из этих проблем, но даже они не более чем полезные фичи.
Как отметил Даниэль Стенберг (один из специалистов по стандартизации HTTP/2) из Mozilla, первая версия протокола испытывает трудности с полным использованием возможностей базового транспортного уровня TCP.
Многие пользователи, работавшие над оптимизацией скорости загрузки сайта, знают об этой проблеме.
Со временем пропускная способности интернета резко возросла, но инфраструктура эры HTTP/1.1 не использовала ее в полной мере. Она все еще боролась с такими проблемами, как конвейерная передача HTTP — увеличение количества запросов через одно и то же TCP-соединение.
Клиентская поддержка в браузерах затягивалась все больше: Firefox и Chrome отключили ее по умолчанию, а IE, Firefox версии 54+ вообще ее не поддерживали.
Многим разработчикам веб-приложений для оптимизации приходилось прибегать к модели HTTP/1, чтобы оптимизировать свои веб-сайты, включая спрайты изображений, конкатенацию CSS и JavaScript, сегментирование (распределение запросов посетителей на ресурсы по нескольким доменам или поддоменам) и т. д.
Индустрия застыла в ожидании нового решения.
SPDY
В 2009 году Google анонсировал проект с использованием нового собственного протокола SPDY (произносится как скоростной).
Поддержка браузера Chrome добавила популярность SPDY и распространила его на многие веб-сервисы в последующие годы. Затем присоединились Twitter, разработчики серверов: Apache, nginx, Node.js. Затем присоединились Facebook, WordPress.com и большинство поставщиков CDN.
В SPDY введено мультиплексирование — отправка нескольких сообщений параллельно через одно TCP-соединение. Соединения шифруются по умолчанию, а данные сжимаются. Предварительные тесты в официальном документе SPDY, проведенном на 25 лучших площадках, показали повышение скорости с 27% до более 60%.
После того, как проект SPDY версии 3 зарекомендовал себя в интернете, он стал основой для первого проекта HTTP/2 , созданного рабочей группой протокола передачи гипертекста httpbis (где bis означает «ещё раз», «на бис») в 2015 году.
HTTP/2 направлен на решение проблем, связанных с первой версией протокола (задержек) путем:
- Сжатия данных в заголовках HTTP
- Использования push-технологий на серверной стороне
- Мультиплексирование запросов по одному соединению.
Он также направлен на решение проблемы блокировки заголовков. Передаваемые данные представлены в двоичном формате, что повышает эффективность и по умолчанию требует шифрования (или, по крайней мере, это требование, предъявляемое основными браузерами).
Сжатие заголовка выполняется с помощью алгоритма HPACK, устраняя уязвимость в SPDY и уменьшая размеры веб-запросов вдвое.
Использования push-технологий на серверной стороне — это одна из функций, нацеленная на решение проблемы затраченного времени ожидания путем предоставления ресурсов браузеру посетителя до того, как браузер потребует его. Что сильно сокращает время в модели «запрос-ответ», как узким местом в оптимизации сайтов.
Необходимо отметить, что экономия времени загрузки становится более очевидной, чем больше ресурсов у сайта.
Как узнать, обслуживает ли веб-сайт ресурсы по HTTP/2
В основных браузерах, таких как Firefox или Chrome, мы можем проверить поддержку веб-сайта для протокола HTTP/2 в инструменте инспектора, открыв вкладку Network и щелкнув правой кнопкой мыши на полосе над списком ресурсов. Здесь мы можем включить пункт Protocol.
