[00:01] мир HTTP — основы интернета. Мы рассмотрим, как он развивался от HTTP 1 к HTTP 2, а затем к HTTP 3. Приготовьтесь к увлекательному путешествию! HTTP расшифровывается как [00:13] Hypertext Transfer Protocol (протокол передачи гипертекста). Это протокол, с помощью которого браузеры взаимодействуют с веб-серверами: они запрашивают веб-страницы и получают их обратно. Изначально HTTP использовался для гипертекстовых документов — документов со ссылками на другие документы, но разработчики вскоре обнаружили, что HTTP [00:29] может передавать изображения и видео. Теперь он также используется для API, передачи файлов и широкого спектра веб-сервисов. Вернемся в 1996 год — именно тогда был представлен HTTP 1. [00:41] Но до этого был HTTP 0.9. Он был простым: поддерживал только GET-запросы и не имел заголовков, отправлял только HTML- файлы. Не было HTTP-заголовков или [00:53] файлы. Не было HTTP-заголовков или кодов состояния. HTTP 1.0 изменил заголовки, коды состояния и добавил новые методы POST и HEDER. Всё было просто: браузер запрашивал веб-страницу, сервер отправлял её. Для каждого запроса требовалось [01:07] собственное соединение, что означало множество обменов данными. Это было не очень эффективно. Вот обменов данными. Это было не очень эффективно. Вот почему: во-первых, существует TCP-рукопожатие — трёхсторонний процесс для начала соединения. Для HTTPS используется TLS- [01:20] рукопожатие для обеспечения безопасности. Всё это происходит до отправки каких-либо данных. В случае HTTP 1 это происходило для каждого ресурса: каждого изображения, файла CSS или файла JavaScript. Это было не [01:32] файла CSS или файла JavaScript. Это было не идеально. В 1997 году вышел HTTP 1.1, который исправил проблемы с HTTP 1. Он до сих пор широко используется, даже спустя 25 лет, и обладает рядом замечательных новых функций. HTTP 1.1 ввёл постоянные соединения: [01:48] соединения остаются открытыми, пока их не закроют. Это означало, что больше не нужно закрывать их после каждого запроса, больше нет множественных TCP-рукопожатий. Это избавило от дополнительной работы по постоянному открытию и закрытию соединений. Также была введена [02:02] конвейерная обработка (pipleline). Клиенты отправляют несколько запросов по одному TCP-соединению, им не нужно ждать ответов. Например, когда браузеру нужны два изображения, он может запросить их одно за другим. Это ускорило работу и сократило [02:17] время ожидания каждого ответа. Ещё одной ключевой особенностью стало кодирование передачи фрагментов (chunk transfer encoding). Серверы могли отправлять ответы меньшими фрагментами, им не нужно было ждать готовности всего ответа. Это могло ускорить начальную отрисовку страницы и [02:30] улучшить пользовательский опыт, особенно для большого или динамического контента. HTTP 1.1 также принёс улучшенное кэширование и условные запросы. Заголовки, такие как Cash запросы. Заголовки, такие как Cash Control и EAG, помогают управлять [02:44] содержимым кэша и сокращать ненужные передачи данных. Условные запросы с использованием заголовков, например, If Modify, позволяют клиентам запрашивать ресурсы только в том случае, если они их изменили. Это экономит пропускную способность и повышает производительность. Но по мере роста и усложнения веб-сайтов [02:58] выявилась большая проблема с HTTP 1.1: блокировка по шаблону. Если первый запрос в конвейере задерживался, все остальные тоже задерживались. Из-за этого и других проблем многие браузеры не использовали конвейерную обработку. [03:13] Разработчики нашли способы обойти эти ограничения. Одним из них было использование DomainShing: веб-сайты предоставляли статические ресурсы с поддоменов, каждый новый поддомен получал еще шесть подключений. Другой трюк заключался в создании Fel-запросов путем объединения изображений. Изображения [03:27] объединялись с помощью спрайтов. Файлы CSS и JavaScript конкатенировались. JavaScript конкатенировались. В 2015 году появился HTTP2. Он был разработан для решения проблем с производительностью HTTP 1 и принес значительные улучшения. HTTP 2 [03:41] ввел бинарный уровень кадрирования. В отличие от обычных текстовых сообщений HTTP 1, HTTP2 использует бинарный формат. Сообщения делятся на более мелкие единицы, называемые кадрами. Они [03:53] передаются по TCP-соединению. Бинарный уровень кадрирования обрабатывает все это. HTTP2 также обеспечил полную обработку запросов и ответов. Мультиплексирование клиентов и серверов позволяет разбивать HTTP-сообщения на независимые кадры, которые можно смешивать [04:08] во время передачи и снова объединять на другой стороне. Это решило проблему блокировки выравнивания заголовка из HTTP1. Приоритизация потока была еще одной ключевой особенностью HTTP2: порядок загрузки ресурсов имеет значение для веб-страниц. [04:23] Приоритизация потока позволяет разработчикам устанавливать важность запросов: браузер может сообщить серверу, какой ресурс имеет высокий приоритет; сервер затем отправляет больше кадров для этих важных запросов. HTTP2 также поддерживает серверную отправку (Server Push). HTTP2 [04:38] позволяет отправлять несколько ответов на запрос клиента: сервер может отправлять дополнительные ресурсы вместе с запрошенной HTML- страницей, это как предоставление клиенту ресурса еще до того, как он его запросит. Наконец, HTTPB2 вводит сжатие заголовков. [04:53] В HTTP1 сжимались только основные данные, заголовки отправлялись в виде обычного заголовки отправлялись в виде обычного текста. HTTPPP2 использует XACK для уменьшения размера заголовков. XACK сжимает заголовки и запоминает предыдущие заголовки; он использует эту информацию [05:07] для еще большего сжатия будущих заголовков. Но по мере усложнения веб-приложений и распространения мобильного интернета HTTPV2 демонстрирует некоторые ограничения. Природа TCP заключается в обработке пакетов, блокировка контура заголовка и снижение скорости загрузки страниц, что [05:23] особенно актуально для высокопроизводительных приложений. Задержка или сети с потерями данных привели к стандартизации HTTP 3 сети с потерями данных привели к стандартизации HTTP 3 в 2022 году. HTTP 3 использовал Quick вместо TCP. Quick был разработан Google и построен на основе UDP — [05:37] протокола без установления соединения. UDP не требует установления соединения перед отправкой данных. Quick и HTTP 3 имеют ряд существенных преимуществ: они уменьшают задержку, улучшают мультиплексирование без блокировки TCP head outline, лучше обрабатывают потери пакетов, [05:52] лучше работают в мобильных сетях с плавной сменой соединения. Когда клиент подключается к серверу с помощью HTTP 3, начинается быстрое рукопожатие. Quick сочетается с TCP 1.3 для обеспечения безопасности. Рукопожатие TL происходит [06:07] во время быстрой установки соединения, что уменьшает общую задержку. HTTP 3 устанавливает соединения быстрее, чем TCP. Если клиент и сервер уже общались ранее, Quick может обеспечить соединение за один RNG-запрос, иногда за ноль [06:21] RNG-запрос, иногда за ноль R-запросов, за ноль RT. Клиент отправляет запрос сразу, сервер обрабатывает его без полного рукопожатия. HTTP 3 также хорошо обрабатывает изменения сети. Если вы переключаетесь с Wi-Fi на сотовую связь на [06:35] своем телефоне, HTTP 3 может поддерживать соединение. Это благодаря идентификаторам соединений Quake. По состоянию на 2023 год, эти протоколы не зависят от IP-адресов. HTTP 1.1 по- прежнему широко используется, особенно для простых веб-сайтов. HTTP 2 получил широкое распространение и [06:52] обрабатывает более 60% веб-запросов. По некоторым оценкам, HTTP 3 всё ещё относительно новый, но набирает обороты. Крупные компании, такие как Google и Cloudflare, являются лидерами в его внедрении. Это путь эволюции HTTPS. Мы видели, как он [07:07] изменился от простой модели HTTP 1 до мультиплексирования HTTP 2 и быстрых соединений HTTP 3. Базовые протоколы веб-технологий адаптировались к нашей растущей потребности в быстром и надёжном онлайн- опыте. Если вам нравятся наши видео, вам [07:23] понравится и наша рассылка по системному проектированию. Мы освещаем темы и тенденции в проектировании крупномасштабных систем. Присоединяйтесь к 1 миллиону подписчиков из технологической индустрии! subscribers from the tech industry subscribe at blog. byb go.com