SPDY - 2009
Google пошел дальше и начал экспериментировать с альтернативными протоколами, чтобы ускорить работу в Интернете и повысить веб-безопасность при одновременном снижении времени отклика веб-страниц. В 2009 году они объявили о создании SPDY.
SPDY является торговой маркой Google и не является аббревиатурой.
Было замечено, что если мы увеличиваем пропускную способность, то вначале производительность сети увеличивается, но наступает момент, когда прирост производительности невелик. Но вот снижая время отклика мы получаем постоянный прирост производительности. Это была основная идея повышения производительности SPDY - уменьшить задержку при отклике для повышения производительности сети.
Для тех, кто не знает, задержка - это время ожидания, т.е. сколько времени требуется для передачи данных между между источником и пунктом назначения (измеряется в миллисекундах), а пропускная способность - это объем данных, передаваемых в секунду (бит в секунду).
Функции SPDY включали в себя мультиплексирование, сжатие, приоритизацию, безопасность и т.д. Я не собираюсь вдаваться в подробности SPDY, так как вы получите представление, когда мы перейдем к деталям HTTP/2 в следующем разделе, поскольку я уже сказал, что HTTP/2 в основном вдохновлен SPDY.
SPDY на самом деле не пытался заменить HTTP; это был уровень трансляции поверх HTTP, который существовал на прикладном уровне и изменял запрос перед отправкой его по проводу. По факту он начал становиться стандартом, и большинство браузеров начали его внедрять.
В 2015 году в Google не хотели иметь два конкурирующих стандарта и поэтому решили объединить его с HTTP, одновременно создав HTTP/2 и отказавшись от SPDY.
HTTP/2 - 2015
К настоящему времени вы, должно быть, убедились в том, что еще была необходима одна редакция протокола HTTP. HTTP/2 был разработан для передачи контента с низким временем отклика. Ключевые особенности или отличия от старой версии HTTP/1.1:
- Двоичный код вместо текстового
- Мультиплексирование - несколько асинхронных HTTP-запросов по одному соединению
- Сжатие заголовка с помощью HPACK
- Отправка данных по инициативе сервера - Несколько ответов на один запрос
- Приоритизация запросов
- Безопасность
1. Двоичный протокол
HTTP/2 решает проблему повышенного времени отклика, которая существовала в HTTP/1.x, превращая его в двоичный протокол. Двоичный протокол легче анализировать, но, в отличие от HTTP/1.x, он недоступен человеческому глазу. Основными строительными блоками HTTP/2 являются фреймы и потоки.
Фреймы и потоки
HTTP-сообщения теперь состоят из одного или нескольких фреймов. Существует фрейм ЗАГОЛОВКОВ для метаданных и фрейм ДАННЫХ для полезной информации пакета, а также существует несколько других типов фреймов (ЗАГОЛОВКИ, ДАННЫЕ, RST_STREAM (сброс потока), НАСТРОЙКИ, ПРИОРИТЕТ и т.д.), Которые вы можете посмотреть в спецификации HTTP/2.
Каждому запросу и ответу HTTP/2 присваивается уникальный идентификатор потока, и он разделяется на фреймы. Фреймы - это не что иное, как двоичные фрагменты данных. Набор фреймов называется потоком. Каждый кадр имеет идентификатор потока, который идентифицирует поток, к которому он принадлежит, и каждый фрейм имеет общий заголовок. Кроме того, помимо того, что идентификатор потока уникален, стоит отметить, что любой запрос, инициированный клиентом, использует нечетные числа, а ответ от сервера имеет четные идентификаторы потоков.
Помимо ЗАГОЛОВКОВ и ДАННЫХ, еще один тип фрейма, который, я думаю, стоит упомянуть здесь, - это RST_STREAM, который представляет собой специальный тип фрейма, который используется для прерывания некоторого потока, т.е. клиент может отправить этот фрейм, чтобы сообщить серверу, что больше не нужен этот поток. В HTTP/1.1 единственным способом заставить сервер прекратить отправку ответа клиенту было закрытие соединения, что приводило к увеличению задержки, поскольку для любых последовательных запросов приходилось открывать новое соединение. В HTTP/2, клиент может использовать RST_STREAM и прекратить прием определенного потока, в то время как соединение все еще будет открыто, а другие потоки все еще будут в игре.
2. Мультиплексирование
Поскольку HTTP/2 является двоичным протоколом и использует фреймы и потоки для запросов и ответов, после открытия TCP-соединения все потоки отправляются асинхронно через одно и то же соединение без открытия каких-либо дополнительных подключений. И, в свою очередь, сервер отвечает таким же асинхронным образом, т.е. ответ не имеет порядка, и клиент использует назначенный идентификатор потока для идентификации потока, к которому принадлежит конкретный пакет. Это также решает проблему блокировки в начале очереди, которая существовала в HTTP/1.x, т.е. клиенту не придется ждать запроса, который требует больше времени, и другие запросы все равно будут обрабатываться.
3. Сжатие заголовка с помощью HPACK
Это была часть отдельного RFC, который был специально направлен на оптимизацию отправляемых заголовков. Суть этого заключается в том, что, когда мы постоянно обращаемся к серверу с одного и того же клиента, существует много избыточных данных, которые мы отправляем в заголовках снова и снова, и иногда могут быть файлы cookie, увеличивающие размер заголовков, что приводит к использованию полосы пропускания и увеличению времени отклика. Чтобы решить это, HTTP/2 ввел сжатие заголовков.
В отличие от запроса и ответа, заголовки не сжимаются в форматах gzip или compress и т.д., но существует другой механизм сжатия заголовков. Буквенные значения кодируются с использованием кода Хаффмана, а таблица заголовков поддерживается клиентом и сервером, и как клиент, так и сервер опускают любые повторяющиеся заголовки (например, агент пользователя и т.д.) в последующих запросах и ссылаться на них, используя таблицу заголовков, поддерживаемую обоими.
Пока мы говорим о заголовках, позвольте мне добавить здесь, что заголовки по-прежнему такие же, как в HTTP/1.1, за исключением добавления некоторых псевдо-заголовков, т.е. :method, :scheme, :host и :path
4. Отправка данных по инициативе сервера (Server Push)
Server push - это еще одна потрясающая функция HTTP/2, где сервер, зная, что клиент собирается запросить определенный ресурс, может отправить его клиенту, даже не запрашивая его у клиента. Например, предположим, что браузер загружает веб-страницу, он анализирует всю страницу, чтобы найти удаленное содержимое, которое он должен загрузить с сервера, а затем отправляет последующие запросы на сервер для получения этого содержимого.
Сервер push позволяет серверу уменьшить количество обходов, отправляя данные, которые, как он знает, будет запрашивать клиент. Как это делается, сервер отправляет специальный фрейм с именем PUSH_PROMISE, уведомляющий клиента о том, что "Эй, я собираюсь отправить вам этот ресурс! Не просите меня об этом". Фрейм PUSH_PROMISE связан с потоком, который вызвал нажатие, и он содержит идентификатор обещанного потока, то есть поток, в который сервер отправит ресурс для нажатия.
5. Приоритезация запросов
Клиент может назначить приоритет потоку, включив информацию о приоритизации в фрейм ЗАГОЛОВКОВ, с помощью которого открывается поток. В любое другое время клиент может отправить фрейм ПРИОРИТЕТА, чтобы изменить приоритет потока.
Без какой-либо информации о приоритете сервер обрабатывает запросы асинхронно, т.е. без какого-либо порядка. Если потоку присвоен приоритет, то на основе этой информации о приоритизации сервер решает, сколько ресурсов необходимо выделить для обработки того или иного запроса.
6. Безопасность
Было проведено обширное обсуждение вопроса о том, следует ли сделать безопасность (через TLS) обязательной для HTTP/2. В конце концов, было решено не делать его обязательным. Однако большинство поставщиков заявили, что они будут поддерживать HTTP/2 только тогда, когда он используется через TLS. Итак, хотя HTTP/2 не требует шифрования по спецификациям, но в любом случае оно стало обязательным по умолчанию. Учитывая это, HTTP/2 при реализации через TLS действительно накладывает некоторые требования. например, необходимо использовать TLS версии 1.2 или выше, должен быть определенный уровень минимальных размеров ключей, требуются эфемерные ключи и т.д.
HTTP/2 здесь, и он уже превзошел SPDY в адаптации. HTTP/2 может многое предложить с точки зрения повышения производительности, и нам пора начать его использовать.
По любым вопросам или комментариям обращайтесь в раздел комментариев ниже. Кроме того, если вы обнаружите какую-либо вопиющую ложь во время чтения, укажите на нее.
