История http (http1.1, https, spdy, http2.0, quic, http3.0)

HTTP

В этой статье будут объяснены соответствующие точки знаний из временной шкалы непрерывного развития HTTP, включая HTTP1.1, HTTPS, SPDY, HTTP2.0, QUIC, HTTP3.0 и т. д. Содержание статьи охватывает широкий диапазон и принадлежит уровень грамотности.Я не буду углубляться в определенный пункт знаний, чтобы расширить, я надеюсь, что все читатели могут получить что-то.

1. ВЕБ-предок HTTP

Полное название HTTP: Протокол передачи гипертекста (HyperText Transfer Protocol). С рождением компьютерных сетей и браузеров также последовал HTTP 1.0. Он расположен на прикладном уровне компьютерных сетей. HTTP построен на протоколе TCP, поэтому узкое место протокола HTTP и методы его оптимизации основаны на протоколе TCP. , Его собственные характеристики, такие как 3-стороннее рукопожатие при установлении TCP-соединения и 4-сторонняя волна отключения, а также время задержки RTT, создаваемое каждым установлением соединения.

2. HTTP и современные браузеры

Уже в начале создания HTTP основной целью является передача документов на языке гипертекстовой разметки (HTML) с веб-сервера в браузер клиента. Это также означает, что для внешнего интерфейса HTML-страница, которую мы пишем, будет размещена на нашем веб-сервере, и клиент может получить доступ к URL-адресу через браузер для получения отображаемого содержимого веб-страницы, но начиная с WEB2.0, наша страница стала сложной. , не только простой текст и изображения, но и наша HTML-страница имеет CSS и JavaScript для обогащения отображения нашей страницы. Когда появляется ajax, у нас есть другой способ получить данные с сервера. На самом деле они основаны на HTTP-протокол. Также в эпоху мобильного Интернета наши страницы могут работать в браузере на мобильном телефоне, но по сравнению с ПК сетевая ситуация на мобильном телефоне более сложная, что требует от нас глубокого понимания HTTP и процесс непрерывной оптимизации.图片描述

3. Базовая оптимизация HTTP

  • пропускная способность:

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

  • Задерживать:
  1. Блокировка браузера (блокировка HOL):Браузеры блокируют запросы по ряду причин. Для одного и того же доменного имени браузер может иметь только 4 подключения одновременно (это может варьироваться в зависимости от ядра браузера).Если максимальное количество подключений браузера превышено, последующие запросы будут заблокированы.
  2. DNS-поиск:Браузер должен знать IP-адрес целевого сервера, чтобы установить соединение. Система, которая разрешает доменные имена в IP-адреса, называется DNS. Обычно этого можно достичь, используя результаты кэширования DNS, чтобы сократить это время.
  3. Установите соединение (начальное соединение):HTTP основан на протоколе TCP, и браузер может отправлять пакеты HTTP-запросов только в третьем рукопожатии как можно раньше, чтобы установить реальное соединение, но эти соединения нельзя использовать повторно, что приведет к тому, что каждый запрос будет иметь три рукопожатия и медленный запуск. . . . Трехстороннее рукопожатие оказывает существенное влияние на сценарии с высокой задержкой, в то время как медленный запуск оказывает большее влияние на запросы больших файлов. На следующем рисунке показана блок-схема трехстороннего рукопожатия:

图片描述

4. Некоторые различия между HTTP1.0 и HTTP1.1

HTTP1.0 был впервые использован на веб-страницах в 1996 году. В то время он использовался только на некоторых относительно простых веб-страницах и сетевых запросах, в то время как HTTP1.1 начал широко использоваться в текущих основных сетевых запросах браузера в 1999 году. В то же время HTTP1.1 также является наиболее широко используемым протоколом HTTP.

Основные отличия в основном отражаются в:

  1. Обработка кэша:В HTTP1.0 If-Modified-Since и Expires в заголовке в основном используются в качестве критериев оценки кеша, HTTP1.1 вводит больше стратегий управления кешем, таких как тег Entity, If-Unmodified-Since, If-Match, If-None- Match и другие необязательные заголовки кэша для управления стратегией кэширования.
  2. Оптимизация пропускной способности и использование интернет-соединения:В HTTP 1.0 есть некоторые явления траты полосы пропускания, например, клиенту нужна только часть объекта, а сервер отправляет объект целиком и не поддерживает функцию возобновления загрузки, в HTTP 1.1 это представлен в заголовке запроса. С полем заголовка диапазона оно позволяет запрашивать только определенную часть ресурса, то есть код возврата 206 (Partial Content), что облегчает свободный выбор разработчика для полного использования полосы пропускания. и связи.
  3. Управление уведомлениями об ошибках:В HTTP 1.1 добавлено 24 новых кода ответа об ошибке, например 409 (конфликт), указывающий, что запрошенный ресурс конфликтует с текущим состоянием ресурса; 410 (исчез), указывающий, что ресурс на сервере окончательно удален.
  4. Обработка заголовка хоста:В HTTP 1.0 считается, что каждый сервер привязан к уникальному IP-адресу, поэтому URL-адрес в сообщении запроса не передает имя хоста (имя хоста). Но с развитием технологии виртуальных хостов на физическом сервере может быть несколько виртуальных хостов (многосетевых веб-серверов), и они имеют общий IP-адрес. Сообщение запроса и ответное сообщение HTTP1.1 должны поддерживать поле заголовка узла, и если в сообщении запроса нет поля заголовка узла, будет сообщено об ошибке (400 Bad Request).
  5. Длинное соединение:HTTP 1.1 поддерживает постоянное соединение (PersistentConnection) и обработку конвейера запросов (Pipelining). Несколько HTTP-запросов и ответов могут передаваться по одному TCP-соединению, что снижает потребление и задержку при установлении и закрытии соединений. Постоянные соединения также соответствуют HTTP1.1 вConnection： keep-alive, в определенной степени компенсируют недостатки HTTP 1.0 созданием соединения для каждого запроса.

На следующем рисунке показан снимок экрана стандартного запроса и ответа HTTP1.1 в браузере:图片描述 图片描述

5. Некоторые существующие проблемы HTTP 1.0 и 1.1

  1. HTTP1.0 и HTTP1.1 можно назвать HTTP1.x.Как упоминалось выше, когда HTTP1.x передает данные, ему необходимо каждый раз переустанавливать соединение, что, несомненно, значительно увеличивает время задержки, особенно на мобильных терминалах. более заметным.
  2. Когда HTTP1.x передает данные, весь передаваемый контент находится в виде простого текста, и ни клиент, ни сервер не могут проверить личность другой стороны, что не может в определенной степени гарантировать безопасность данных.
  3. When HTTP1.x is used, the content carried in the header is too large, which increases the cost of transmission to a certain extent, and the header of each request basically does not change much, especially on the mobile terminal, which will increase user трафик.
  4. Хотя HTTP1.1 поддерживает поддержку активности, чтобы компенсировать задержку, вызванную созданием нескольких соединений, использование поддержки активности также приведет к значительному снижению производительности сервера и для служб, которые постоянно запрашиваются для одного файла ( таких как сайты размещения изображений), поддержка активности может значительно повлиять на производительность, поскольку она удерживает соединение без необходимости долгое время после запроса файла. Также keep-alive не может решить проблему блокировки очереди (HOL).

6. HTTPS здесь

Чтобы решить некоторые из вышеперечисленных проблем, Netscape создала HTTPS в 1994 году и использовала его в браузере Netscape Navigator. Первоначально HTTPS использовался вместе с SSL, а когда SSL постепенно превратился в TLS (на самом деле это одно, но название другое), последняя версия HTTPS также была официально определена RFC 2818, опубликованным в мае 2000 года. Проще говоря, HTTPS — это безопасная версия HTTP, и из-за более высоких требований к безопасности в современную эпоху Chrome и Firefox активно поддерживают веб-сайты, использующие HTTPS, и Apple также заставляет приложения использовать HTTPS для передачи данных в системе iOS 10. HTTPS. является обязательным.

7. Некоторые различия между HTTPS и HTTP

  1. Протокол HTTPS должен обратиться в ЦС для подачи заявки на сертификат.Как правило, бесплатных сертификатов немного, и вам нужно платить комиссию.
  2. HTTP — это протокол передачи гипертекста, информация передается в виде открытого текста, а HTTPS — безопасный протокол передачи с шифрованием TLS.
  3. HTTP и HTTPS используют совершенно разные методы подключения, и используемые по умолчанию порты также различаются: первый — 80, а второй — 443.
  4. Подключение HTTPS очень простое.Протокол HTTPS представляет собой сетевой протокол, построенный на основе протокола TLS+HTTP, который может выполнять зашифрованную передачу и аутентификацию и является более безопасным, чем протокол HTTP.

8. Преобразование HTTPS

Если веб-сайт хочет заменить весь сайт с HTTP на HTTPS, вам может потребоваться обратить внимание на следующие моменты:

  1. Установите сертификат ЦС:Общие сертификаты нужно заряжать, вот хороший сайт для покупки сертификатов: 1)Давайте зашифруем:Бесплатно, быстро, поддерживает несколько доменных имен (не подстановочные знаки) и может подписывать + экспортировать сертификаты тремя командами. Недостатком является то, что он действует только временно в течение трех месяцев, и его необходимо продлевать по истечении срока его действия. 2)Comodo PositiveSSL:Тарифы, но относительно стабильные.
  2. Настройте веб-сервер:После покупки сертификата настройте собственное доменное имя на веб-сайте, предоставленном сертификатом, загрузите сертификат, настройте собственный веб-сервер и одновременно выполните модификацию кода.
  3. HTTPS может уменьшить скорость доступа пользователя:TLS требует рукопожатия, а HTTPS в определенной степени снизит скорость, но если он правильно оптимизирован и развернут, влияние HTTPS на скорость вполне приемлемо. Во многих сценариях скорость HTTPS вообще не уступает HTTP, а при использовании SPDY скорость HTTPS даже выше, чем у HTTP. По сравнению с HTTPS, который снижает скорость доступа, нужно больше заботиться о нагрузке ЦП на стороне сервера.Вычисление большого количества ключевых алгоритмов в HTTPS потребляет много ресурсов ЦП.Только при достаточной оптимизации стоимость машины HTTPS существенно не увеличится.

порекомендовать одинTaobao трансформирует HTTPSстатья.

9. Ускорьте свой сайт с помощью SPDY

В 2012 году Google разработал план SPDY (произносится как «быстрый»), и все начали смотреть и решать проблемы старой версии самого протокола HTTP. Можно сказать, что SPDY — это передача, которая сочетает в себе преимущества как HTTPS, так и HTTP. Соглашение в основном касается:

  1. Более низкая задержка:В ответ на проблему высокой задержки HTTP SPDY элегантно использует мультиплексирование. Мультиплексирование сокращает задержку создания нескольких TCP и улучшает использование полосы пропускания за счет совместного использования одного TCP-соединения с несколькими потоками запросов.
  2. Приоритизация запросов:Новая проблема, связанная с мультиплексированием, заключается в том, что оно может привести к блокировке критически важных запросов на основе совместного использования соединения. SPDY позволяет установить приоритет для каждого запроса, чтобы на важные запросы отвечали первыми. Например, когда браузер загружает домашнюю страницу, сначала должно отображаться html-содержимое домашней страницы, а затем загружаются различные статические файлы ресурсов, файлы сценариев и т. д., чтобы пользователи могли видеть содержимое домашней страницы. веб-страницу в первый раз.
  3. Сжатие заголовка:Как было сказано выше, заголовки HTTP1.x часто избыточны и избыточны, а содержимое некоторых заголовков «огромно» без сжатия (например, файлы cookie и user-agent и т. д.). Выбор подходящего алгоритма сжатия может уменьшить размер и количество пакетов, что не только экономит ресурсы, но и уменьшает задержку доставки данных.
  4. Передача зашифрованного протокола на основе HTTPS:Функция шифрования TLS протокола HTTPS сохранена, что значительно повышает надежность передачи данных.
  5. Пуш сервера:Например, для веб-страниц, использующих SPDY, моя веб-страница имеет запрос на sytle.css. Когда клиент получает данные sytle.css, сервер передает клиенту файл index.js. Когда клиент пытается получить его снова При использовании index.js его можно получить напрямую из кеша, и нет необходимости отправлять запрос.

Схема состава СПДИ:图片描述SPDY находится под HTTP, над TCP и SSL, поэтому он может быть легко совместим со старой версией протокола HTTP (инкапсулирует содержимое HTTP1.x в новый формат кадра) и может одновременно использовать существующую функцию SSL. время. Поскольку SPDY не является стандартным протоколом, SPDY не стал формальным стандартом сам по себе, но члены команды разработчиков SPDY участвовали в процессе разработки HTTP2.0 на протяжении всего процесса. У SPDY тоже есть проблемы с совместимостью: после выхода HTTP2.0 большинство браузеров перестанут его поддерживать. Совместимость следующая:图片描述

10. Прошлое и настоящее HTTP2.0

С HTTP1.x логично появится HTTP2.0. Можно сказать, что HTTP2.0 — это обновленная версия SPDY (на самом деле изначально он был разработан на основе SPDY). Однако между HTTP2.0 и SPDY все еще есть различия, в основном в следующих двух моментах:

  1. Алгоритм сжатия заголовка сообщения HTTP2.0 использует алгоритм HPACK вместо алгоритма DEFLATE, принятого SPDY.
  2. HTTP2.0 изначально поддерживает передачу открытого текста HTTP, в то время как SPDY обеспечивает использование HTTPS, а позже оба требуют использования HTTPS.

В сентябре 2015 года Google объявил о планах отказаться от поддержки SPDY в пользу HTTP 2.0, что вступит в силу в Chrome 51.

11. Новые возможности HTTP 2.0

Большинство функций HTTP2.0 аналогичны SPDY, в основном включая следующие четыре:

  1. Новый двоичный формат:Анализ HTTP 1.x основан на тексте. Парсинг формата на основе текстового протокола имеет естественные дефекты Представление текста разнообразно Должно быть много сценариев для рассмотрения робастности Двоичный отличается, распознается только комбинация 0 и 1. Основываясь на этом соображении, при анализе протокола HTTP2.0 было принято решение использовать двоичный формат, который удобен и надежен в реализации.
  2. Мультиплексирование (мультиплексирование):Это совместное использование соединения, то есть каждый запрос представляет собой механизм совместного использования, используется как соединение. Запрос соответствует идентификатору, может быть множество таких запросов на соединение, каждый запрос может быть связан со случайным смешением вместе, затем получатель может быть отнесен к их разным запросам, обслуживание которых заканчивается в соответствии с запросом, который является идентификатором запроса. Принципы мультиплексирования и сохраняйте разницу ниже:

图片描述 3. Сжатие заголовка:Как упоминалось выше, заголовок HTTP1.x, упомянутый выше, содержит много информации, и его приходится каждый раз отправлять повторно.HTTP2.0 использует кодировщик для уменьшения размера заголовка, который необходимо передать, и обе стороны кэшируют таблица полей заголовков, которая не только позволяет избежать передачи повторяющихся заголовков, но и уменьшает размер, который необходимо передать.

  1. Пуш сервера:Как и SPDY, HTTP2.0 также имеет функцию Server Push.

В настоящее время на большинстве веб-сайтов включен протокол HTTP2.0, например на YouTube, Taobao и др. Вы можете использовать консоль Chrome, чтобы проверить, включен ли сервер Push, как показано ниже:图片描述

Разницу между мультиплексированием в HTTP2.0 и HTTP1.x можно наглядно представить на следующем рисунке:图片描述

12. Обновление HTTP 2.0

По сравнению с обновлением HTTPS приобретение HTTP2.0 будет немного проще.Вам может потребоваться обратить внимание на следующие проблемы:

  1. В предыдущей статье говорилось, что HTTP2.0 должен быть основан на HTTPS, и теперь основные браузеры, такие как Chrome и Firefox, по-прежнему поддерживают только протокол HTTP2.0 на основе развертывания TLS, поэтому, если вы хотите перейти на HTTP2.0, лучше сначала обновить HTTPS.
  2. После того, как ваш сайт был обновлен до HTTPS, гораздо проще обновить HTTP2.0.Все, что вам нужно сделать, это обновить сервер.Если вы используете Nginx, вам нужно запустить соответствующий протокол в файле конфигурации.Вы можете обратиться к «Белой книге NGINX», «Официальное руководство NGINX по настройке HTTP2.0».
  3. Если используется HTTP2.0, что мне делать с исходным HTTP1.x? На самом деле, не беспокойтесь об этой проблеме. HTTP2.0 полностью совместим с семантикой HTTP1.x. Для браузеров, не поддерживающих HTTP2 .0, Nginx автоматически станет обратно совместимым.

На панели «Сеть» в консоли Chrome вы можете увидеть протокол HTTP2.0, используемый запросом, как показано ниже:图片描述

13. Что такое HTTP3.0?

HTTP3.0, также известный как HTTP через QUIC. Ядром HTTP3.0 является протокол QUIC (произносится быстро), новый протокол, созданный на основе SPDY v3, предложенный Google в 2015 году. Традиционный протокол HTTP — это протокол, основанный на транспортном уровне TCP, тогда как QUIC основан на транспортном уровне. UDP Протокол может быть определен как: HTTP3.0 Основанный на UDP безопасный и надежный протокол HTTP2.0.

图片描述Протокол QUIC решает следующие проблемы для протокола HTTP 2.0 на основе TCP и TLS:

  1. Сокращено время трехстороннего рукопожатия TCP и рукопожатия TLS:Будь то HTTP1.0/1.1 или HTTPS, HTTP2.0 использует TCP для передачи. HTTPS и HTTP2 также требуют использования протокола TLS для безопасной передачи. Есть две задержки рукопожатия, и QUIC основан на протоколе UDP, потому что сам UDP не имеет концепции соединения, требуется только одно взаимодействие, когда соединение установлено, вдвое меньше времени рукопожатия. Разница заключается в следующем:图片描述
  2. Проблема блокировки заголовка строки при потере мультиплексированных пакетов:QUIC сохраняет функцию мультиплексирования HTTP 2.0, но даже в процессе мультиплексирования существует несколько потоков на одном и том же TCP-соединении. Если один из потоков теряет пакеты, последующие потоки будут затронуты до повторной передачи. несколько потоков по соединению в QUIC. Следовательно, когда происходит потеря пакета, затрагивается только текущий поток, что позволяет избежать проблемы блокировки начала строки.
  3. Оптимизированная стратегия ретрансляции:Предыдущая стратегия повторной передачи потерянных TCP-пакетов заключалась в следующем: отправитель помечает каждый пакет порядковым номером, и когда получатель получает пакет, он отправляет обратно отправителю пакет ACK с соответствующим номером, чтобы проинформировать отправителя. фактически было получено. Когда отправитель не получил возвращенный ACK через определенный период времени, он будет считать, что пакет потерян, запустить механизм повторной передачи и повторно отправить пакет с тем же номером, что и оригинал, чтобы убедиться, что ничего не произошло. на стороне получателя Пакет пропущен.

Такой механизм принесет некоторые проблемы, предполагается, что отправитель отправляет один и тот же пакет дважды (начальная + повторная передача) в сумме, используя один и тот же порядковый номер: номер N. Впоследствии, когда отправитель получит возвращенный ACK пакета с номером N, он не сможет определить, что ACK с номером N является ACK, возвращенным получателем после получения исходного пакета. Это увеличит затраты времени на последующие расчеты повторной передачи. Во избежание этой проблемы, когда отправитель передает пакеты, каждый исходный и повторно передаваемый пакет использует новый номер, уникальный номер пакета, и каждый номер уникален и строго увеличивается, так что каждый раз при получении ACK QUIC использует новый номер ., по номеру можно четко определить, исходит ли ACK от исходного пакета или от пакета повторной передачи. 4.управление потоком:Благодаря управлению потоком количество данных, передаваемых клиентом, может быть ограничено.При управлении потоком принимающая сторона может зарезервировать только соответствующий размер приемного буфера, чтобы оптимизировать пространство, занимаемое памятью. Но если есть очень медленный поток, всего один поток может занять все ресурсы приемника. Чтобы избежать этой потенциальной блокировки HOL, QUIC принимает управление потоком на уровне соединения (управление потоком соединения) и уровне потока (управление потоком потока), чтобы ограничить максимальный размер буфера, который может занимать один поток. 5.Миграция подключения:TCP-соединение основано на четверке (исходный IP-адрес, исходный порт, целевой IP-адрес и целевой порт).При переключении сетей по крайней мере один фактор изменится, что приведет к изменению соединения. При изменении соединения, если исходное TCP-соединение все еще используется, произойдет сбой соединения, и соединение необходимо будет восстановить после истечения времени ожидания исходного соединения, поэтому мы иногда обнаруживаем, что при переключении на новую сеть, даже если новая сеть в хорошем состоянии, но контент по-прежнему долго загружается. При правильной реализации новое TCP-соединение устанавливается, как только обнаруживается изменение сети, и даже в этом случае для установления нового соединения потребуются сотни миллисекунд. На соединение QUIC четверка не влияет, при изменении этих четырех элементов исходное соединение сохраняется. Соединение QUIC не идентифицируется четверкой, а использует 64-битное случайное число, которое называется идентификатором соединения, которое соответствует каждому потоку.Даже если IP или порт меняются, пока идентификатор соединения не меняется, соединение остается неизменным.

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

Добро пожаловать Концерн курсы: «От 0 до 1 Практические моменты разработки мобильных веб-приложений» «Практический вывод Meituan по разработке мобильных веб-приложений»

Категории