HTTP1, HTTP2, HTTP3

HTTP

Все они заранее подготовлены для интервью, а потом различные конспекты, некоторые скопированы из брифбука, а некоторые добавлены мной. Надеюсь, это поможет всем~

Разница между HTTP1 и HTTP1.1

1. Улучшите постоянные соединения

Каждый раз, когда HTTP/1.0 выполняет HTTP-связь, он должен пройти три этапа: установление TCP-соединения, передача данных HTTP и отключение TCP-соединения (как показано на рисунке ниже).

В то время, поскольку файлы сообщений были относительно небольшими, и на каждой странице было немного ссылок, такая форма передачи не была большой. Но поскольку браузер популярен, файлы изображений на одной странице увеличиваются, иногда страница может содержать сотни файлов внешних ссылок.Если вы загружаете каждый файл, вам нужно испытать установление TCP-соединений.Шаги для передачи данных и разъединение, несомненно, увеличит большое количество ненужных накладных расходов. Чтобы решить эту проблему, в HTTP / 1.1 добавлен метод постоянного подключения, который характеризуется передачей нескольких HTTP-запросов по TCP-соединению.Пока браузер или сервер явно не отключены, TCP-соединение будет поддерживаться. .

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

Постоянные подключения включены по умолчанию в HTTP/1.1, поэтому вам не нужно настраивать информацию заголовка HTTP-запроса специально для постоянных подключений.Если вы не хотите использовать постоянные подключения, вы можете добавить **Connection: close Заголовок HTTP-запроса (по умолчанию для Connection:keep-alive)****. **В настоящее время для одного и того же доменного имени в браузере одновременная установка разрешена по умолчанию.6个TCP持久连接.

2. Незрелая конвейерная обработка HTTP

Хотя постоянное соединение может уменьшить количество установлений и отключений TCP, оно должно дождаться возврата предыдущего запроса, прежде чем делать следующий запрос. Если запрос в TCP-канале по какой-либо причине не возвращается вовремя, все последующие запросы будут заблокированы, что является известной проблемой блокировки заголовка строки.

HTTP/1.1 пытается решить проблему блокировки очереди с помощью конвейерной технологии. Конвейерная обработка в HTTP/1.1 относится к технологии отправки нескольких HTTP-запросов на сервер пакетами.Хотя запросы могут отправляться пакетами, серверу все равно необходимо отвечать на запросы браузера в соответствии с последовательностью запросов. FireFox и Chrome экспериментировали с конвейерной обработкой, но по разным причинам в конце концов отказались от этой технологии.

3. Обеспечьте поддержку виртуального хоста

В HTTP/1.0 каждое доменное имя привязано к уникальному IP-адресу, поэтому сервер может поддерживать только одно доменное имя. Однако с развитием технологии виртуальных хостов необходимо привязать несколько виртуальных хостов к одному физическому хосту, каждый виртуальный хост имеет свое собственное отдельное доменное имя, и эти отдельные доменные имена имеют один и тот же IP-адрес. Поэтому поле Host добавляется в заголовок запроса HTTP/1.1 для указания текущего адреса доменного имени, чтобы сервер мог выполнять различную обработку в соответствии с разными значениями Host.

4. Идеальная поддержка динамически генерируемого контента.

При разработке HTTP/1.0 необходимо установить полный размер данных в заголовке ответа, например, Content-Length: 901, чтобы браузер мог получать данные в соответствии с установленным размером данных. Однако с развитием серверных технологий содержимое многих страниц генерируется динамически, поэтому окончательный размер данных неизвестен до того, как данные будут переданы, из-за чего браузер не знает, когда будут получены все данные файла.

HTTP/1.1 решает эту проблему, вводя механизм передачи фрагментов,Сервер разделит данные на несколько фрагментов произвольного размера., каждый блок данных будет отправлен с длиной предыдущего блока данных, и, наконец, блок нулевой длины будет использоваться как знак того, что данные отправлены. Это обеспечивает поддержку динамического содержимого.

5. Клиентский файл cookie, механизм безопасности

Резюме
  • HTTP — это язык общения между браузерами и серверами.
  • В начале своего рождения HTTP/0.9 имеет простые требования, поэтому процесс связи с сервером относительно прост.
  • HTTP/1.0 вводит заголовки запросов и заголовки ответов, в основном для поддержки различных типов загрузки файлов; во-вторых, он также предоставляет базовую информацию, такую ​​как механизм кэширования, пользовательский агент и код состояния.
  • С развитием технологий и спросом люди предъявляют все более высокие требования к скорости передачи файлов, поэтому на основе HTTP/1.0 был запущен HTTP/1.1, а для повышения эффективности соединения был добавлен метод постоянного соединения. время она также пыталась использовать конвейерную технологию для повышения эффективности (хотя по разным причинам основные производители в конечном итоге отказались от конвейерной технологии). Кроме того, в HTTP/1.1 также представлены такие функции, как файлы cookie, поддержка виртуальных хостов и поддержка динамического содержимого.

Разница между HTTP1.1 и HTTP2

Улучшения и недостатки HTTP1

Улучшить и оптимизировать

Мы знаем, что HTTP/1.1 сделал большую оптимизацию для повышения эффективности сети, и ядро ​​имеет следующие три пути:

1\.  增加了持久连接;
2\.  浏览器为每个域名最多同时维护6个TCP持久连接; 
3\.  使用CDN的实现域名分片机制。

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

На этом рисунке введен CDN и поддерживается 6 подключений для каждого доменного имени одновременно, что значительно сокращает время загрузки всего ресурса. Здесь мы можем просто посчитать: если используется одно постоянное TCP-соединение, время загрузки 100 ресурсов составляет 100*n*RTT, а при использовании вышеуказанной технологии все время можно сократить до 100*n*RTT/. (6 * количество CDN). В результате этого расчета скорость загрузки нашей страницы стала намного выше.

существующие проблемы

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

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

Причина, по которой HTTP/1.1 не идеален для использования пропускной способности, заключается в том, что HTTP/1.1 трудно использовать пропускную способность. Например, при пропускной способности 100 М, о которой мы часто говорим, фактическая скорость загрузки может достигать 12,5 М/с, но при использовании HTTP/1.1 при загрузке ресурсов страницы может использоваться только до 2,5 М/с, и это сложно. использовать все 12,5 М. Полный.

  • Первая причина — медленный старт TCP.

Как только соединение TCP установлено, оно переходит в состояние отправки данных.В начале протокол TCP будет использовать очень медленную скорость для отправки данных, а затем медленно увеличивать скорость отправки данных, пока скорость отправки данных не достигнет идеальной состояние.Этот процесс называется慢启动.

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

Медленный запуск — это стратегия, используемая TCP для уменьшения перегрузки сети, и мы никак не можем изменить ее.

Причина, по которой медленный запуск приводит к проблемам с производительностью, заключается в том, что некоторые ключевые файлы ресурсов, обычно используемые на страницах, невелики, например файлы HTML, файлы CSS и файлы JavaScript.Обычно эти файлы инициируют запрос после установления TCP-соединения.Да , но этот процесс запускается медленно, поэтому он занимает намного больше времени, чем обычно, что задерживает драгоценный первый рендеринг страницы.

  • Вторая причина заключается в том, что одновременно открывается несколько TCP-соединений, поэтому эти соединения будут конкурировать за фиксированную пропускную способность.

Вы можете представить себе, что система устанавливает несколько TCP-соединений одновременно.Когда пропускная способность достаточна, скорость отправки или получения каждого соединения будет постепенно увеличиваться, а когда пропускной способности недостаточно, эти TCP-соединения будут замедлять отправку или скорость приема.. Например, страница имеет 200 файлов и использует 3 CDN, то при загрузке страницы ей необходимо установить 6*3, то есть 18 TCP-соединений для загрузки ресурсов; в процессе загрузки, когда пропускная способность оказывается недостаточной , каждое TCP-подключение должно динамически снижать скорость получения данных. Это вызовет проблему, потому что некоторые соединения TCP загружают некоторые ключевые ресурсы, такие как файлы CSS, файлы JavaScript и т. д., в то время как некоторые соединения TCP загружают обычные файлы ресурсов, такие как изображения и видео, но несколько соединений TCP невозможно согласовать. какие ключевые ресурсы должны быть загружены в первую очередь, что может повлиять на скорость загрузки этих ключевых ресурсов.

  • Третья причина — проблема блокировки заголовка строки HTTP/1.1.

Мы знаем, что при использовании постоянных подключений в HTTP/1.1, несмотря на то, что конвейер TCP может быть общим, в каждый момент времени в конвейере может обрабатываться только один запрос, а другие запросы могут быть заблокированы только до тех пор, пока текущий запрос не завершится. Это означает, что мы не можем произвольно отправлять запросы и получать контент в конвейере.

Это очень серьезная проблема, потому что есть много факторов, которые блокируют запросы, и все они являются неопределенными факторами.Если некоторые запросы будут заблокированы на 5 секунд, последующие запросы в очереди будут задержаны на 5 секунд.В этом В процессе ожидания , пропускная способность и ЦП тратятся зря.

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

Некоторые из основных проблем с HTTP/1.1: Медленный старт и TCP-соединения, конкурирующие за пропускную способность, вызваны самим механизмом TCP, в то время как блокировка заголовка строки вызвана механизмом HTTP/1.1.

Улучшения HTTP2 (мультиплексирование)

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

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

Итак, решение HTTP/2 можно резюмировать следующим образом:Используйте только одно TCP-соединение для доменного имени и устраните проблемы с блокировкой заголовков**. ** Пожалуйста, обратитесь к изображению ниже:

Эта диаграмма является основным, наиболее важным и наиболее разрушительным механизмом мультиплексирования HTTP/2. На рисунке видно, что каждый запрос имеет соответствующий идентификатор, например, поток1 представляет запрос на index.html, а поток2 представляет запрос на foo.css. Таким образом, на стороне браузера запрос может быть отправлен на сервер в любое время.

После того, как сервер получит эти запросы, он решит, какой контент следует вернуть первым, в соответствии со своими предпочтениями. Например, сервер может кэшировать информацию заголовка ответа index.html и bar.js, поэтому, когда он получает запрос, он может немедленно вернуть информацию заголовка ответа index.html и bar.js в браузер, а затем вернуть данные тела ответа index.html и bar.js в браузер. Причина, по которой его можно отправить по желанию, заключается в том, что каждый фрагмент данных имеет соответствующий идентификатор.После того, как браузер его получит, он отфильтрует контент с тем же идентификатором и объединит его в полные данные HTTP-ответа.

HTTP/2 использует технологию мультиплексирования, которая может разделить запрос на покадровые данные для передачи, что дает дополнительное преимущество, заключающееся в том, что при получении высокоприоритетного запроса, такого как JavaScript или для запросов критически важных ресурсов CSS, сервер может приостанавливать выполнение предыдущих запросов для приоритизации запросов на критические ресурсы.

Реализация мультиплексирования

Теперь мы знаем, что для решения проблем HTTP/1.1 в HTTP/2 используется механизм мультиплексирования.Как HTTP/2 достигает мультиплексирования?Сначала вы можете посмотреть на следующую картинку:

Как видно из рисунка, HTTP/2 добавляетДвоичный слой кадрирования, то разберем процесс запроса и приема HTTP/2 в сочетании с диаграммой.

  • Сначала браузер подготавливает данные запроса, включая строку запроса, заголовок запроса и др. Если это метод POST, то есть и тело запроса.
  • После того, как эти данные будут обработаны бинарным уровнем кадрирования, они будут преобразованы в кадры с идентификационными номерами запроса, и эти кадры будут отправлены на сервер через стек протоколов.
  • После того, как сервер получит все кадры, он объединит все кадры с одинаковым идентификатором в полное сообщение запроса.
  • Затем сервер обрабатывает запрос и отправляет обработанную строку ответа, заголовок ответа и тело ответа на уровень двоичного кадрирования.
  • Точно так же уровень двоичного кадрирования преобразует эти данные ответа в кадры с идентификационными номерами запроса и отправляет их в браузер через стек протоколов.
  • После того, как браузер получит кадр ответа, он отправит данные кадра на соответствующий запрос в соответствии с номером ID.

Как видно из вышеописанного процесса, за счет введения бинарного уровня кадрирования реализуется технология мультиплексирования HTTP.

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

Другие особенности HTTP/2

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

  1. Вы можете установить приоритет запроса Мы знаем, что некоторые данные в браузере очень важны, но в момент отправки запроса запрос может быть важным позже, чем те не очень важные запросы, если сервер для того, чтобы отвечать на запросы данных, то эти важные данные, вероятно, будут отложены на долгое время для обслуживания браузером, что для пользователя очень недружелюбно. Чтобы решить эту проблему, HTTP / 2 обеспечивает приоритет запроса, может быть отмечен приоритет запроса на передачу запроса, после чего сервер, получивший этот запрос, получает приоритет запросов с высоким приоритетом.
  2. Сервер нажимает в дополнение к настройке приоритета запросов, HTTP / 2 также может загружать данные непосредственно в браузер заранее. Вы можете себе представить сценарий, когда пользователь запрашивает страницу HTML, сервер знает, что HTML-страница будет ссылаться на несколько важных файлов JavaScript и файлов CSS, а затем после получения HTML-запроса, он прикрепит файлы CSS и файлы JavaScript, которые будут использоваться . Отправьте его в браузер одновременно, так что, когда браузер завершит анализ файла HTML, он может напрямую получить необходимый файл CSS и файл JavaScript, который играет решающую роль в скорости открытия страницы в первый раз Отказ
  3. Сжатие заголовков Будь то HTTP/1.1 или HTTP/2, они имеют заголовки запросов и заголовки ответов, что является языком общения между браузерами и серверами. HTTP/2 сжимает заголовки запросов и заголовки ответов.Вы можете подумать, что файл заголовка HTTP не очень большой, и может не иметь значения, сжат он или нет, но если вы думаете об этом таким образом, когда браузер отправляет запрос , это в основном При отправке заголовков HTTP-запроса отправляется очень мало тел запроса.Обычно на странице находится около 100 ресурсов.Если данные этих 100 заголовков запроса сжимаются до 20% исходных данных, эффективность передачи будет обязательно сильно улучшится.

Резюме

Сначала мы проанализируем три основных фактора, влияющих на эффективность HTTP/1.1:TCP的慢启动,多条TCP连接竞争带宽а также队头阻塞.

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

Спецификация протокола HTTP/2 была официально выпущена в мае 2015 года, и с тех пор протокол широко внедряется и развертывается в Интернете и всемирной паутине. Судя по текущей ситуации, некоторые ведущие сайты в стране и за рубежом в основном реализовали развертывание HTTP/2. Использование HTTP/2 может повысить эффективность примерно на 20-60%, а 20% или 60% зависит от степени оптимизации. Короче говоря, мы тоже должны идти в ногу со временем, отказаться от HTTP/1.1 и его методов оптимизации производительности и «принять» HTTP/2.

Мысль: Хотя HTTP/2 решает проблему блокировки заголовка строки в HTTP/1.1, HTTP/2 по-прежнему основан на протоколе TCP, а протокол TCP по-прежнему имеет проблему блокировки заголовка строки в пакете. Как блокировка влияет на производительность HTTP/2?

Недостатки, которые все еще существуют в HTTP2

Блокировка заголовка TCP

Хотя HTTP/2 решает проблему блокировки заголовка строки на уровне приложения, как и HTTP/1.1, HTTP/2 по-прежнему основан на протоколе TCP, который изначально был разработан для одного соединения. Вы можете думать о TCP-соединении как о виртуальном канале между двумя компьютерами.Один конец компьютера размещает данные для передачи в канал по порядку, и окончательные данные появляются в том же порядке на другом конце канала. Далее давайте проанализируем, как TCP передает данные в стеке протоколов HTTP/1.1. Для интуитивного понимания вы можете обратиться к следующему рисунку:

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

Однако, если пакет данных потерян из-за сбоя сети или по другим причинам во время передачи данных, все соединение TCP будет приостановлено, ожидая повторной передачи потерянного пакета данных. Вы можете думать о TCP-соединении как о конвейере, который последовательно передает данные.Если какие-либо данные в конвейере потеряны, последующие данные должны ждать повторной передачи данных. Для интуитивного понимания вы можете обратиться к следующему рисунку:

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

Из этого рисунка мы знаем, что в HTTP/2 несколько запросов выполняются в конвейере TCP.Если какая-либо потеря пакетов происходит в любом из потоков данных, все запросы в TCP-соединении будут заблокированы. Это отличается от HTTP/1.1.При использовании HTTP/1.1 браузер открывает 6 TCP-соединений для каждого доменного имени.Если одно из TCP-соединений заблокировано головой очереди, другие 5 соединений могут продолжать передавать данные. . . .

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

Задержка установления TCP-соединения

В дополнение к блокировке заголовков TCP процесс квитирования TCP также является важным фактором, влияющим на эффективность передачи. Чтобы понять задержку установления соединения по протоколу TCP, давайте сначала рассмотрим концепцию сетевой задержки, которая поможет вам понять следующее содержание. Сетевая задержка также называется RTT (время приема-передачи). Мы называем все время приема-передачи пакета от браузера к серверу и возврата пакета от сервера к браузеру как RTT (как показано на рисунке ниже). RTT — важный показатель, отражающий производительность сети.

Сколько RTT требуется для установления TCP-соединения, посчитаем. Мы знаем, что HTTP/1 и HTTP/2 передаются с использованием протокола TCP, и если используется HTTPS, для безопасной передачи необходимо использовать протокол TLS, а использование TLS также требует процесса рукопожатия, который требует двух рукопожатий. задерживает процесс.

  1. При установлении TCP-соединения необходимо выполнить трехстороннее рукопожатие с сервером, чтобы подтвердить, что соединение успешно, то есть ему нужно потреблять 1,5 RTT перед передачей данных.
  2. Для подключения TLS TLS имеет две версии: TLS1.2 и TLS1.3. Время, необходимое для установления соединения, отличается для каждой версии, требуется примерно от 1 до 2 RTT. Мы подробно расскажем о HTTPS позже в модуле безопасности. .

В заключение, нам нужно потратить 3-4 RTT перед передачей данных. Если физическое расстояние между браузером и сервером близко, то время 1 RTT может быть в пределах 10 миллисекунд, что означает, что в общей сложности будет израсходовано от 30 до 40 миллисекунд. Это время может быть приемлемым для пользователя, но если серверы находятся далеко друг от друга, то одно RTT может занимать более 100 миллисекунд, в этом случае весь процесс рукопожатия занимает от 300 до 400 миллисекунд, и пользователь явно чувствует «медленность». .

Протокол TCP жесткий

Теперь, когда мы знаем, что протокол TCP имеет такие недостатки, как блокировка очереди и задержка установления соединения, можем ли мы решить эти проблемы, улучшив протокол TCP?

Ответ: очень сложно. Для этого есть две основные причины.

Во-первых, это жесткость промежуточного программного обеспечения. Чтобы понять, что такое промежуточное устройство, мы должны сначала понять, что такое промежуточное устройство. Мы знаем, что Интернет представляет собой ячеистую структуру, соединенную между собой множеством сетей.Для того, чтобы обеспечить нормальную работу Интернета, нам необходимо везде в Интернете построить различные устройства.Эти устройства называются промежуточными устройствами.

Существует много типов этих промежуточных устройств, и каждое из них имеет свое назначение.Эти устройства включают маршрутизаторы, брандмауэры, NAT, коммутаторы и т. д. Обычно они полагаются на какое-то редко обновляемое программное обеспечение, использующее множество функций TCP, которые настраиваются и редко обновляются.

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

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

Понимание HTTP3: избавьтесь от бремени TCP и TLS и создайте эффективную сеть

Протокол QUIC (полное название Quick UDP Internet Connections, быстрое интернет-соединение UDP)

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

Но это также сталкивается с теми же проблемами, что и изменение TCP, из-за жесткости промежуточных устройств эти устройства распознают только TCP и UDP, и если новый протокол принят, новый протокол также не будет хорошо поддерживаться в этих устройствах.

Поэтому HTTP/3 выбрал метод компромисса - протокол UDP.На основе UDP он реализует такие функции, как несколько потоков данных и надежность передачи, аналогичные TCP.Мы называем этот набор функций протоколом QUIC. Для сравнения стеков протоколов HTTP/2 и HTTP/3 вы можете обратиться к следующему рисунку:

Из приведенного выше рисунка видно, что HTTP/3QUIC-протоколИнтегрированы следующие функции.

  • Он реализует функции управления потоком и надежностью передачи, аналогичные TCP. Хотя UDP не обеспечивает надежной передачи, QUIC добавляет слой поверх UDP для обеспечения надежной передачи данных. Он обеспечивает повторную передачу пакетов, управление перегрузкой и некоторые другие функции, присутствующие в TCP.
  • Шифрование TLS интегрировано. QUIC в настоящее время использует TLS 1.3, по сравнению с более ранними версиями, TLS 1.3 имеет больше преимуществ, самое важное из которых — уменьшение количества RTT, затрачиваемых на рукопожатия.
  • Реализует функцию мультиплексирования в HTTP/2. В отличие от TCP, в QUIC реализовано, что на одном и том же физическом соединении может быть несколько независимых логических потоков данных (как показано на рисунке ниже). Реализована раздельная передача потока данных, что решает проблему блокировки головного отряда ПТС.

  • Включите функцию быстрого рукопожатия. Поскольку Quic представляет собой UDP на основе UDP, QUIC может использовать 0-RTT или 1-RTT для установления соединения, а это означает, что Quic может отправлять и получать данные с самой высокой скоростью, что может значительно увеличить скорость первого открытия. .

Проблема HTTP/3

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

Во-первых, исходя из текущей ситуации, ни сервер, ни браузер не обеспечивают полной поддержки HTTP/3. Хотя Chrome начал поддерживать версию QUIC от Google несколько лет назад, эта версия QUIC сильно отличается от официальной версии QUIC.

Во-вторых, развертывание HTTP/3 также очень проблематично. Поскольку оптимизация UDP ядром системы далека от оптимизации TCP, это также является важной причиной торможения QUIC.

В-третьих, проблема жесткого промежуточного оборудования. Эти устройства гораздо менее оптимизированы для UDP, чем для TCP.Согласно статистике, при использовании протокола QUIC уровень потери пакетов составляет от 3% до 7%.

Резюме

Сначала мы проанализировали некоторые проблемы, существующие в HTTP/2, в основном в том числеБлокировка заголовка TCP, задержка в установлении TCP-соединений, жесткость протокола TCPИ другие вопросы.

Все эти проблемы являются внутренними проблемами TCP, поэтому для решения этих проблем необходимо оптимизировать TCP или «начать с нуля» для создания новых протоколов. Из-за множества проблем с оптимизацией протокола TCP чиновник решил создать новый протокол QUIC.

HTTP/3 основан на протоколе QUIC.Вы можете думать о QUIC как о наборе протоколов, объединяющих «мультиплексирование TCP+HTTP/2+TLS и другие функции». Это протокол, который объединяет сильные стороны многих людей.Он тщательно оптимизировал передачу файлов в Интернете с нижнего уровня протокола.Поэтому, когда экология относительно зрела, его можно использовать для создания более эффективной сети, чем текущий HTTP/2.

Хотя этот протокол решает проблемы, вызванные TCP в HTTP/2, он по-прежнему сталкивается с огромными проблемами при продвижении, поскольку он изменяет базовый протокол.

Категории