В чём разница между http1.x, http2.0 и http3.0?

Узнайте больше о различиях между различными версиями http

Что такое протокол http? Почему он делится на http1.x, http2.0,http3.0В чём разница между этими тремя версиями? Ниже представлено подробное описание различий между каждой версией протокола http, которое поможет вам лучше понять его.

Что такое HTTP?

Протокол передачи гипертекстаПротокол передачи гипертекста (HTTP) — наиболее распространённый сетевой протокол в Интернете. Изначально HTTP был разработан для публикации и получения HTML-страниц. Ресурсы, запрашиваемые по HTTP или HTTPS, идентифицируются унифицированными идентификаторами ресурсов (URI).

HTTP — это протокол прикладного уровня, состоящий из запросов и ответов, построенный по стандартной клиент-серверной модели. Это протокол без установления соединения и сохранения состояния, основанный на TCP/IP (каждое HTTP-сообщение не зависит от состояния предыдущего сообщения). HTTP предполагает, что его базовые протоколы обеспечивают надёжную передачу данных. Поэтому он использует TCP в качестве транспортного уровня в рамках стека протоколов TCP/IP.

Основные характеристики протокола HTTP можно резюмировать следующим образом:

Просто: когда клиент запрашивает услугу у сервера, ему достаточно указать метод запроса и путь. Распространенные методы запроса — GET, HEAD и POST. Каждый метод определяет свой тип взаимодействия между клиентом и сервером.
Гибкость: HTTP позволяет передавать объекты данных любого типа. Передаваемый тип обозначается параметром Content-Type.
Режим «запрос-ответ»: каждый раз, когда клиент отправляет запрос серверу, устанавливается соединение, и сервер отключается после обработки запроса клиента.
Без сохранения состояния: HTTP — это протокол без сохранения состояния. Отсутствие состояния означает, что протокол не запоминает транзакции. Отсутствие состояния означает, что если для последующей обработки потребуется предыдущая информация, её необходимо будет передать повторно.

Рабочий процесс HTTP

HTTP состоит из запросов и ответов и представляет собой стандартную модель клиент-сервер (B/S). Протокол HTTP всегда начинается с того, что клиент инициирует запрос, а сервер отправляет ответ.

1. Клиент (браузер) активно отправляет запрос на соединение серверу (веб-серверу) (этот шаг может потребовать протокола разрешения DNS для получения IP-адреса сервера).

2. Сервер принимает запрос на соединение и устанавливает соединение. (Шаги 1 и 2 представляют собой хорошо известное трёхстороннее рукопожатие TCP.)

3. Клиент отправляет HTTP-команды, такие как GET, на сервер через это соединение («сообщение-запрос HTTP»).

4. Сервер получает команду и отправляет клиенту соответствующие данные согласно команде («сообщение-ответ HTTP»).

5. Клиент получает данные, отправленные с сервера.

6. После отправки данных сервер активно закрывает соединение («четырехстороннее разрыв соединения TCP»).

Подводя итог, процесс передачи данных клиент/сервер можно разделить на четыре основных этапа:

1) Браузер устанавливает соединение с сервером (трехстороннее рукопожатие TCP)

2) Браузер отправляет HTTP-запрос на сервер;

3) Сервер отвечает на запрос браузера;

4) Отключение. («Четырехстороннее разрыв TCP»).

Принципы HTTP1.X

В процессе работы http1.0 передача данных HTTP должна проходить через три рукопожатия и четыре волны, что увеличивает задержку

В http1.1 был добавлен Keep-alive, чтобы поддерживать TCP-соединение открытым и сократить некоторые задержки.

Проблемы с HTTP 1.x

Ошибки повторного использования соединения приводят к тому, что каждый запрос проходит трёхстороннее согласование и медленный старт. Трёхстороннее согласование оказывает более существенное влияние в сценариях с высокой задержкой, в то время как медленный старт оказывает большее влияние на запросы большого объёма для небольших файлов.
Блокировка очереди (HOLB) приводит к тому, что полоса пропускания не используется в полной мере, а последующие запросы на работоспособность блокируются.ХОЛББлокировка начала очереди (HOLB) подразумевает блокировку серии пакетов из-за блокировки первого пакета. Когда страница требует много ресурсов, HOLB (блокировка начала очереди) заставляет оставшиеся ресурсы ожидать завершения других запросов на ресурсы, прежде чем инициировать запросы после достижения максимального количества запросов. Были опробованы следующие решения для блокировки начала очереди:

HTTP 1.0: Следующий запрос должен быть отправлен после возврата предыдущего запроса.запрос-ответОчевидно, что если запрос не возвращается в течение длительного времени, то все последующие запросы будут заблокированы.
HTTP 1.1: Для решения этой проблемы была предпринята попытка использования конвейеризации, позволяющей браузеру отправлять несколько запросов одновременно (к одному доменному имени и по одному TCP-соединению). Однако конвейеризация требует, чтобы ответы возвращались по порядку. Поэтому, если предыдущий запрос занимал много времени (например, обработка большого изображения), последующие запросы всё равно будут ожидать завершения предыдущего запроса, прежде чем будут возвращены по порядку, даже если сервер уже обработал его. Таким образом, конвейеризация решает проблему HOLB лишь частично.
Внедрение спрайт-изображений, встраивание небольших изображений и т. д.

Заголовки запросов требуют больших затрат. Поскольку заголовки сообщений обычно содержат множество фиксированных полей, таких как «User Agent», «Cookie», «Accept» и «Server», как показано ниже, их длина может составлять сотни или даже тысячи байт. Однако тело запроса часто занимает всего несколько десятков байт. Большие заголовки в некоторой степени увеличивают стоимость передачи.
Факторы безопасности: При передаче данных по протоколу HTTP 1.x весь передаваемый контент представляет собой открытый текст. Ни клиент, ни сервер не могут проверить подлинность другой стороны, что в определённой степени не гарантирует безопасность данных.
Серверные push-сообщения не поддерживаются, поскольку в HTTP/1.x нет механизма push-уведомлений. Поэтому обычно используются два подхода: опрос, когда клиент регулярно опрашивает данные, и веб-сокет.

2.0 Как это работает

В 2015 году был выпущен HTTP/2. HTTP/2 заменяет текущий протокол HTTP (HTTP/1.x), но не является его полной переработкой. Методы HTTP, коды состояния и семантика аналогичны HTTP/1.x.HTTP/2 основан на SPDY и ориентирован на производительность. Одна из его главных целей — использование только одного соединения между пользователем и веб-сайтом..

Проблемы, которые решает HTTP2

В ответ на проблемы, существующие в http1.x, в http2 предусмотрены следующие решения:

Двоичная передача: HTTP/2 передаёт данные в двоичном формате, а не в текстовом, как HTTP 1.x. Двоичные протоколы более эффективны для анализа. Запросы и ответы HTTP/1 состоят из начальной строки, заголовков и необязательного тела сущности, каждое из которых разделено символом переноса строки. HTTP/2 разбивает данные запроса и ответа на более мелкие кадры, которые кодируются в двоичном формате.
Прежде чем понимать HTTP/2, важно знать некоторые общие термины:
1. Поток: двунаправленный поток. Соединение может иметь несколько потоков.
2. Сообщение: Это логичный запрос и ответ.
3. Кадр: наименьшая единица передачи данных. Каждый кадр принадлежит определённому потоку или всему соединению. Сообщение может состоять из нескольких кадров. Кадр — наименьшая единица передачи данных в HTTP/2. Кадр определяется следующим образом:
  Длина: Длина кадра. Максимальная длина по умолчанию — 16 КБ. Если вы хотите отправить кадр большего размера, необходимо явно указать максимальный размер кадра.
  Тип: Тип фрейма, например ДАННЫЕ, ЗАГОЛОВКИ, ПРИОРИТЕТ и т. д.
  Флаг и R: зарезервированные биты.
  Идентификатор потока: определяет поток, к которому принадлежит кадр. Если он равен 0, это означает, что кадр принадлежит всему соединению.
  Полезная нагрузка кадра: имеет различные форматы в зависимости от типа.
Stream имеет множество важных функций:
1. Соединение может содержать несколько потоков, и данные, отправляемые несколькими потоками, не влияют друг на друга.
2. Поток может использоваться односторонне или совместно клиентом и сервером.
3. Поток может быть закрыт любым из потоков.
4. Поток определяет порядок отправки кадров, а другая сторона обрабатывает их в порядке их получения.
5. Поток идентифицируется уникальным идентификатором. Если поток создан клиентом, идентификатор представляет собой нечётное число; если поток создан сервером, идентификатор представляет собой чётное число.

Двоичная передача переносит некоторые функции TCP на прикладной уровень, разбивая исходное сообщение «Заголовок+Тело» на несколько меньших двоичных «кадров», используя кадры «HEADERS» для хранения данных заголовка и кадры «DATA» для хранения самих данных. После формирования фреймов данных HTTP/2 структура сообщения «Заголовок+Тело» полностью исчезает, и протокол видит только фрагменты.

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

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

В HTTP/1 заголовки передаются в текстовом формате. Если заголовки содержат файлы cookie и пользовательские агенты, может потребоваться повторная передача сотен и тысяч байтов каждый раз. HTTP/2 не использует традиционные алгоритмы сжатия. Вместо этого разработан специализированный алгоритм HPACK. Этот алгоритм создаёт «словарь» как на клиенте, так и на сервере, использует индексы для представления повторяющихся строк и использует кодирование Хаффмана для сжатия целых чисел и строк, достигая высокой степени сжатия от 50% до 90%.

Подробности следующие:

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

Мультиплексирование (мультиплексирование запросов и ответов). Одно и то же доменное имя должно занимать только одно TCP-соединение. По одному TCP-соединению мы можем непрерывно отправлять кадры другой стороне. Идентификатор потока каждого кадра указывает, к какому потоку он принадлежит. Затем, когда другая сторона получает данные, все кадры каждого потока объединяются в соответствии с идентификатором потока, формируя полный блок данных.
Идентификатор потока, упомянутый в анализе протокола выше, используется в качестве механизма совместного использования соединения. Запрос соответствует потоку и получает идентификатор. Таким образом, в одном соединении может быть несколько потоков, и кадры каждого потока могут случайным образом перемешиваться. Получатель может затем отнести кадры к разным запросам на основе идентификатора потока. Запросы и ответы не влияют друг на друга.
Мультиплексирование — это улучшение длинных соединений. Каждый запрос может быть случайным образом смешан с другим, и получатель может отнести его к разным запросам сервера на основе идентификатора запроса.
При мультиплексировании поддерживаются приоритеты потоков (зависимости потоков), что позволяет клиенту сообщать серверу, какой контент является ресурсом с более высоким приоритетом и может передаваться в первую очередь.
Ещё одна важная новая функция, добавленная HTTP/2, заключается в том, что сервер может отправлять несколько ответов на клиентский запрос. Другими словами, помимо ответа на первоначальный запрос, сервер может передавать клиенту дополнительные ресурсы без явного запроса со стороны клиента.
Сервер может активно отправлять данные, а клиент также имеет право выбора. Если отправленный сервером ресурс был закэширован браузером, браузер может отклонить его, отправив кадр RST_STREAM.
Активная отправка соответствует политике единого источника. Сервер не может отправлять сторонние ресурсы клиенту по своему усмотрению, но должна быть подтверждена обеими сторонами.
Улучшенная безопасность. HTTP/2 продолжает использовать функцию «открытого текста» HTTP/1. Данные, как и прежде, могут передаваться в виде открытого текста, и шифрование не является обязательным. Однако формат остаётся двоичным, но расшифровка не требуется.
Поскольку HTTPS является преобладающим трендом, а такие популярные браузеры, как Chrome и Firefox, публично заявили о поддержке только зашифрованного HTTP/2, HTTP/2 фактически зашифрован. Другими словами, HTTP/2, который обычно используется в интернете, использует название протокола «https» и работает по протоколу TLS. Протокол HTTP/2 определяет два строковых идентификатора: «h2» для зашифрованного HTTP/2 и «h2c» для открытого HTTP/2.

Проблемы с HTTP2

HTTP 1.x и HTTP 2 основаны на TCP. TCP, будучи безопасным и надёжным транспортным протоколом, может испытывать высокую задержку установления соединения. Это в первую очередь связано с задержкой установления соединения TCP и TCP+TLS.
Решить проблему перегрузки заголовка TCP невозможно. HTTP2 решает проблему перегрузки заголовка HTTP-уровня с помощью мультиплексирования, но проблема повторной передачи сбоев TCP по-прежнему неразрешима.

Принципы HTTP 3.0

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

По этой причине,Google разработала протокол QUIC на основе протокола UDP и использовала его в HTTP/3.Ранее HTTP/3 был известен как HTTP-over-QUIC. Как следует из названия, наиболее значительным изменением в HTTP/3 является использование протокола QUIC. QUIC (Quick UDP Internet Connections) основан на UDP, используя его скорость и эффективность. QUIC также интегрирует и оптимизирует преимущества TCP, TLS и HTTP/2.

Второстепенные цели QUIC включают в себя сокращение задержки соединения и передачи, выполнение оценки полосы пропускания в каждом направлении для предотвращения перегрузки, перемещение алгоритма управления перегрузкой в пространство пользователя вместо пространства ядра и расширение его с помощью прямой коррекции ошибок (FEC) для дальнейшего повышения производительности при наличии ошибок.

HTTP3-функции

Для HTTP/2-соединений, реализующих функцию быстрого рукопожатия, требуется три RTT. Если рассматривается повторное использование сеанса (т.е. кэширование симметричного ключа, рассчитанного при первом рукопожатии), также требуется два RTT. Более того, при обновлении TLS до версии 1.3 для HTTP/2-соединения требуется два RTT, тогда как для повторного использования сеанса требуется только один RTT. Однако для HTTP/3 требуется только один RTT для начального соединения и ноль RTT для последующих соединений.
Клиент и сервер, использующие протокол QUIC, используют 1RTTОбмен ключами, используемый алгоритм обмена — DH (Диффи-Хеллман)Алгоритм Диффи-Хеллмана.
При первом подключенииПроцесс согласования ключей и передачи данных между клиентом и сервером, который включает в себя базовый процесс алгоритма DH:
1. Сначала клиент отправляет клиентский приветственный запрос серверу, к которому он подключается в первый раз.
2. Сервер генерирует простое число p и целое число g, а также случайное число в качестве закрытого ключа a. Затем он вычисляет открытый ключ A = mod p. Сервер упаковывает три элемента A, p и g в пакет с именем config и затем отправляет его клиенту.
3. Клиент случайным образом генерирует свой закрытый ключ b, считывает g и p из конфигурации и вычисляет открытый ключ клиента B = mod p. Затем клиент вычисляет начальный ключ K на основе A, p и b. После вычисления B и K клиент использует K для шифрования HTTP-данных и отправляет их вместе с B на сервер.
4. Клиент использует свой собственный закрытый ключ b и открытый ключ сервера, считанный из конфигурации, отправленной сервером, для генерации ключа K = mod p для последующего шифрования данных.
5. Клиент использует ключ K для шифрования бизнес-данных и добавляет свой собственный открытый ключ, который затем передается на сервер.
6. Сервер генерирует клиентский ключ шифрования K = mod p на основе своего собственного закрытого ключа a и открытого ключа клиента B.
7. Для обеспечения безопасности данных сгенерированный выше ключ K будет использован только один раз. Впоследствии сервер сгенерирует новый набор открытых и закрытых ключей по тем же правилам и использует этот набор для генерации нового ключа M.
8. Сервер отправляет клиенту данные, зашифрованные новым открытым ключом и новым ключом M. Клиент вычисляет текущий ключ M на основе нового открытого ключа сервера и своего исходного закрытого ключа и расшифровывает его.
9. Все последующие взаимодействия с данными между клиентом и сервером выполняются с использованием ключа M, а ключ K используется только один раз.

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

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

Интегрированная функция шифрования TLS
1. Безопасный переходЗащита данных в режиме прямой передачи означает, что даже в случае утечки ключа ранее зашифрованные данные не будут украдены. Защита затрагивает только текущие данные и не влияет на предыдущие..
  QUIC использует период действия конфигурации и впоследствии генерирует новый ключ для шифрования и дешифрования, который затем уничтожается после завершения взаимодействия, тем самым обеспечивая прямую безопасность.
2. Прямая коррекция ошибок (FEC) — это метод повышения надёжности передачи данных. В одностороннем канале связи после обнаружения ошибки получатель больше не сможет запросить передачу.
  FEC — это метод передачи избыточной информации с использованием данных, который позволяет приемнику восстановить данные при возникновении ошибок во время передачи.
  Каждый раз, когда QUIC отправляет группу данных, он обрабатывает эти данныеОперация XORРезультат отправляется в виде пакета FEC. Получив эти данные, получатель вычисляет контрольную сумму и выполняет коррекцию ошибок на основе пакета данных и пакета FEC. После того, как сегмент данных разделён на 10 пакетов, каждый пакет последовательно подвергается операции XOR. Результат передаётся вместе с пакетом данных в виде пакета FEC. Если пакет данных теряется во время передачи, данные потерянного пакета могут быть получены из оставшихся девяти пакетов и пакета FEC, что значительно повышает отказоустойчивость протокола.
Мультиплексирование решает проблему блокировки начала очереди в протоколе TCP HTTP2.0Механизм мультиплексированияРешить проблему блокировки заголовка на уровне HTTP, ноУровень TCP все еще имеет проблему блокировки начала очереди..
После того как протокол TCP получает пакет данных, эта часть данных может поступать в неупорядоченном виде, но TCP должен собрать, отсортировать и интегрировать все данные для использования верхним уровнем.Если один из пакетов теряется, он должен ждать повторной передачи, что приводит к потере пакета и блокировке использования данных всего соединения..
Протокол QUIC реализован на основе протокола UDP.Несколько потоков, между потоками естьНет взаимного влиянияКогда в потоке происходит потеря пакетов, последствия очень незначительны, что решает проблему блокировки начала очереди.
Реализация управления потоком данных по принципу TCP (…эта часть длинная, см. ссылку)