Сложно о простом. Самые популярные протоколы и принципы их работы. HTTP, HTTPS, SSL и TLS. Часть 3

Приветствую, коллеги! Меня зовут @ProstoKirReal. Сегодня хотелось бы продолжить обсуждение с вами о самых популярных протоколах, а также принципов их работы. В предыдущей части я говорил о протоколах динамической маршрутизации и принципы их работы.

Сегодня хотелось бы рассказать о HTTP и HTTPS протоколах, а так же немного затронуть шифрование SSL/TLS.

❯ Зачем нужна эта статья?

В предыдущих двух статьях (1 часть и 2 часть) я написал о самых популярных протоколах, а также о принципах их работы. Но данными протоколами пользуется ограниченное число пользователей, в основном сетевые инженеры. Нам сетевикам очень важно знать о таких протоколах.
Но есть один очень важный протокол, которым пользуется огромное количество человек по всему миру, заходя в интернет. Имя ему HTTP и про него я бы хотел поговорить отдельно.

В момент написания этой статьи в блоге Timeweb Cloud, вышла довольно интересная статья «HTTP-запросы: параметры, методы и коды состояния». Эта статья и многие статьи в интернете в основном говорят о истории, зачем он нужен, методах, кодах состояния и т.д. Множество статей раскрывают информацию довольно поверхностно или целевую информацию для разработчиков приложений, которые работают с запросами HTTP. Я же в свою очередь хотел бы рассказать о принципе работы данного протокола и его эволюции.

❯ Что такое HTTP?

HTTP (HyperText Transfer Protocol, или Протокол передачи гипертекста) — это протокол прикладного уровня (L7 модели OSI), разработанный для обмена данными между клиентом и сервером в сети Интернет. HTTP используется для передачи HTML-страниц, изображений, видео, текстов и других типов данных, составляющих веб-ресурсы.

❯ Что такое гипертекст?

Гипертекст — это текст, который содержит ссылки на другие фрагменты текста или ресурсы, такие как изображения, видео, страницы и документы. В отличие от обычного текста, гипертекст позволяет пользователю мгновенно переходить по этим ссылкам, тем самым делая навигацию по информации удобной и интуитивной. Это ключевая технология, лежащая в основе Всемирной паутины (World Wide Web), так как она обеспечивает гибкие связи между страницами и позволяет пользователям легко находить и изучать информацию.
В книгах гипертекстом являются отсылки к другим книгам, так называемые перекрестные ссылки. Пример гиперссылки в книгах являются ссылки к книгам одной серии автора или на другие книги другого автора. В основном данный метод используют книги научной или образовательной направленности. Но и встречаются и в обычных книгах. Самым древними гиперссылками являются цитаты, заповеди и пророчества в библии.

HTTP стал ключевым компонентом сети Интернет, так как он обеспечивает доступ к веб-страницам и API. Благодаря его простоте и расширяемости HTTP используется не только для браузеров, но и для взаимодействия между различными сервисами и приложениями.

❯ Основные особенности HTTP

1. Протокол без состояния: HTTP является протоколом без сохранения состояния (stateless), что означает, что каждое соединение между клиентом и сервером обрабатывается как независимое. Сервер не «помнит» предыдущие запросы клиента, хотя такие методы, как cookies и сессии, позволяют временно хранить данные о сессиях.

2. Текстовый и человекочитаемый формат: HTTP-запросы и ответы составлены в текстовом формате, и они легко читаемы человеком. Это делает протокол простым для понимания и отладки.

3. Архитектура клиент-сервер: HTTP построен на взаимодействии между клиентом (например, веб-браузером) и сервером. Клиент отправляет запрос, а сервер отвечает, отправляя необходимые данные.

4. Расширяемость и совместимость: HTTP поддерживает заголовки и методы, которые позволяют расширять возможности взаимодействия. Он был разработан так, чтобы быть совместимым с новыми версиями, что позволило его развитию 

❯ Как работает HTTP

Процесс взаимодействия в HTTP обычно проходит несколько этапов:

1. Установка соединения: клиент (например, браузер) инициирует соединение с сервером по адресу URL, например, http://timeweb.cloud

2. Отправка HTTP-запроса: клиент отправляет HTTP-запрос, который содержит:

• Метод запроса (например, GET, POST, PUT, DELETE и т.д.),

• URI ресурса (адрес страницы или файла),

• HTTP-версия,

• Дополнительные заголовки (headers) и тело запроса (если необходимо, например, при отправке данных через POST).

3. Обработка запроса сервером: сервер получает запрос, обрабатывает его, обращаясь к нужному ресурсу, и формирует ответ.

4. Отправка HTTP-ответа: сервер отправляет ответ, состоящий из:

• Статусной строки с кодом состояния (например, 200 OK, 404 Not Found),

• Заголовков ответа (например, Content-Type, Content-Length, Server),

• Тела ответа с содержимым запрашиваемого ресурса (например, HTML-код страницы).

5. Закрытие соединения: соединение закрывается, если оно не предусмотрено для повторного использования.

❯ В чем отличия URL и URI?

URI — это универсальный идентификатор ресурса, который указывает на него уникальным образом.

URL — это частный случай URI, который описывает точное местоположение ресурса и способ его получения.

Примеры использования

• URI можно использовать для идентификации ресурсов вне зависимости от их местоположения. Например, URI может ссылаться на ресурс с уникальным именем в системе идентификации, где его не обязательно можно будет сразу получить.

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

Основные отличия между URI и URL

❯ Методы HTTP

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

• GET: запрос ресурса. Наиболее распространённый метод.

• POST: отправка данных на сервер для обработки (например, данные формы).

• PUT: загрузка ресурса на сервер или обновление ресурса.

• DELETE: удаление ресурса с сервера.

• HEAD: запрос только заголовков ответа (без тела).

• OPTIONS: запрос на доступные методы для ресурса.

  Подробнее о методах в статье «HTTP-запросы: параметры, методы и коды состояния» от Timeweb Cloud

❯ Версии HTTP

С течением времени HTTP прошёл несколько фаз эволюции:

1. HTTP/0.9: первая версия, только метод GET, без заголовков и метаданных.

2. HTTP/1.0: добавлены заголовки, методы и статусные коды.

3. HTTP/1.1: усовершенствованное управление соединениями (persistent connections), более эффективное использование ресурсов.

4. HTTP/2: оптимизация скорости передачи, сжатие заголовков и поддержка мультиплексирования.

5. HTTP/3: новый транспортный уровень (QUIC вместо TCP), для повышения скорости и надёжности.

Все версии кроме HTTP/3 используют протокол транспортного уровня TCP. HTTP/3 использует протокол QUIC, он же UDP. Подробнее о том зачем осуществился переход от «качественного» протокола TCP к «некачественному» UDP я расскажу в разделе посвящённому HTTP/3

❯ Эволюция HTTP

❯ HTTP 0.9

Первой версией данного протокола стала не 1.0 как многие думают, а 0.9.

Данный протокол был совсем прост, как и интернет в то время и содержал только текстовые файлы. HTTP был предложен в марте 1991 года Тимом Бернерсом-Ли.

6 августа 1991 года стал вторым днём рождения сети Интернет. В этот день Тим Бернерс-Ли запустил первый в мире веб-сайт на первом веб-сервере, доступном по адресу info.cern.ch. На этом сайте было представлено понятие «Всемирной паутины», содержались инструкции по установке веб-сервера, использованию браузера и другие полезные материалы. Также этот сайт стал первым интернет-каталогом, так как Тим Бернерс-Ли позже добавил и поддерживал на нём список ссылок на другие сайты. Это было знаковое событие, которое сформировало интернет в том виде, в каком мы знаем его сегодня.

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

Структура запроса на прикладном уровне в HTTP/0.9

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

1. Метод: HTTP/0.9 поддерживал только метод GET, который передавался как первое слово в запросе. Этот метод указывал на то, что клиент хочет получить ресурс с сервера.

2. URI (Uniform Resource Identifier): после метода GET указывался путь к ресурсу, то есть URI. Путь определял, какой конкретно файл или ресурс клиент пытался получить. В HTTP/0.9 этот путь начинался с /и указывал на ресурс относительно корневого каталога веб-сервера.

   • Пример: /timeweb.cloud.html

В более поздних версиях (HTTP/1.0 и выше) добавился также HTTP-вариант пути, включающий в URI название хоста, что позволило серверам обрабатывать запросы для разных доменов.

Структура ответа на прикладном уровне в HTTP/0.9

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

1.     Тело ответа: содержимое файла или ресурса, которое сервер отправлял клиенту. Это мог быть HTML-документ, простой текст или иной текстовый контент.

В отличие от более поздних версий, где добавились заголовки, такие как Content-Type (определяет тип содержимого), Content-Length (размер тела ответа) и Server (информация о сервере), в HTTP/0.9 этих полей не было.

Как отправлялся запрос?

В HTTP/0.9 отправка запроса была максимально простой и состояла из одной строки. Чтобы запросить ресурс с сервера, клиент (обычно веб-браузер) отправлял строку с методом GET, за которым следовал путь к ресурсу. 

Всё работало очень похоже на современные версии, когда речь идет об использовании браузера: пользователю достаточно было ввести адрес сайта (URL), а браузер автоматически формировал и отправлял запрос GET к серверу.

Важно: Отсутствие поддержки виртуальных хостов

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

Теперь подробнее о том, как передаются пакеты в сети.

1. Клиент инициализирует соединение с сервером по TCP порту 80 (SYN).

2. Сервер отвечает готовностью к соединению (SYN-ACK).

3. Клиент подтверждает соединение (ACK).

4. Клиент отправляет запрос (GET).

5. Сервер обрабатывает запрос и отправляет ответ.

6. Клиент инициирует завершение сессии (FIN).

7. Сервер подтверждает завершение соединения (ACK).

8. Сервер инициирует завершение сессии (FIN).

9. Клиент подтверждает завершение соединения (ACK).

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

❯ HTTP 1.0

Первая официальная версия протокола  HTTP/1.0 — была разработана в 1996 году, заложив более формальную и структурированную основу для веб-общения по сравнению с HTTP/0.9. В отличие от предшественника, HTTP/1.0 поддерживал больше методов и заголовков, расширяя возможности клиентов и серверов для обмена более подробной информацией о запросах и ответах.

Основные улучшения в HTTP/1.0

1. Поддержка нескольких методов. HTTP/1.0 ввёл новые методы наряду с GET, такие как:

   • POST — позволял клиенту отправлять данные на сервер, например, формы или файлы;

   • HEAD — позволял запрашивать только заголовки ресурса, чтобы получить метаданные, не загружая само содержимое.

2. Введение заголовков. В HTTP/1.0 появились заголовки, которые предоставляли контекст и управляли поведением клиента и сервера. Наиболее важные из них:

   • Host: указание домена, на который отправляется запрос. Благодаря этому серверы могли обслуживать несколько веб-сайтов на одном IP-адресе (виртуальные хосты);

   • Content-Type: тип содержимого, который сервер отправляет клиенту (например, text/html);

   • Content-Length: размер тела ответа в байтах, что позволяло клиенту предсказать объём получаемых данных;

   • User-Agent: информация о клиенте (например, браузере или приложении), отправляющем запрос;

   • Server: идентификация веб-сервера, от которого получен ответ.

3. Коды состояния ответа. HTTP/1.0 расширил систему кодов состояния для большей прозрачности. Наиболее распространённые:

   • 200 OK: успешный запрос;

   • 404 Not Found: запрашиваемый ресурс не найден;

   • 500 Internal Server Error: ошибка на стороне сервера.

Структура запроса в HTTP/1.0

Запрос в HTTP/1.0 состоял из трёх основных частей:

1. Стартовая строка: содержала метод, URI и версию протокола:

GET /timeweb.cloud.html HTTP/1.0

1. Заголовки запроса: указывали метаданные запроса и ожидания клиента (например, Host: example.com,User-Agent: Mozilla/5.0).

2. Тело запроса (для методов, таких как POST): передавало данные для сервера (например, содержимое формы).

Структура ответа в HTTP/1.0

Ответ состоял из следующих частей:

1. Стартовая строка: версия протокола, код состояния и пояснение.

HTTP/1.0 200 OK

1. Заголовки ответа: информация о ресурсе, например, Content-Type, Content-Length и Server.

2. Тело ответа: содержимое запрашиваемого ресурса.

Схема обмена данными (на уровне TCP)

В HTTP/1.0 запросы отправлялись по последовательным TCP-соединениям, которые закрывались после каждого ответа. Это выглядело так:

1. Клиент инициализирует TCP-соединение с сервером по порту 80 (SYN).

2. Сервер отвечает подтверждением соединения (SYN-ACK).

3. Клиент подтверждает соединение (ACK).

4. Клиент отправляет HTTP-запрос (GET, POST или HEAD).

5. Сервер обрабатывает запрос и отправляет ответ.

6. После получения ответа соединение закрывается (FIN).

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

Некоторые серверы и браузеры экспериментально реализовали поддержку постоянных соединений в HTTP/1.0 с помощью заголовка Connection: keep-alive. Этот заголовок позволял оставить соединение открытым для повторного использования и последующих запросов, но это решение не было частью официального стандарта HTTP/1.0. Поэтому его поддержка была ограниченной и нестабильной.

Важные особенности HTTP/1.0

• Отсутствие постоянных соединений: соединение закрывалось после каждого запроса, что увеличивало накладные расходы, так как для каждого ресурса открывалось новое соединение.

• Поддержка виртуальных хостов: заголовок Host позволял серверам обслуживать несколько доменов на одном IP-адресе.

• Стандартные методы и заголовки: формализованная система методов и заголовков сделала HTTP/1.0 более гибким и подходящим для современного интернета.

HTTP/1.0 стал первым стандартом HTTP, заложив основу для эволюции веб-протокола и став важным этапом в развитии интернета.

❯ HTTP 1.1

HTTP/1.1, выпущенный в 1997 году, стал значительным шагом вперёд в развитии веб-протокола, решив множество ограничений HTTP/1.0 и улучшив производительность и гибкость взаимодействия между клиентами и серверами.

Основные улучшения в HTTP/1.1

1. Постоянные соединения (keep-alive). Одним из ключевых улучшений в HTTP/1.1 стала поддержка постоянных соединений, которые оставались открытыми для нескольких запросов и ответов между клиентом и сервером. Это решило проблему HTTP/1.0, в котором соединение закрывалось после каждого запроса, требуя открывать новое соединение для каждого ресурса.

   • В HTTP/1.1 постоянные соединения используются по умолчанию, и соединение остаётся активным, пока клиент или сервер не решат его закрыть.

   • Заголовок Connection: keep-alive теперь не требуется, так как поддержка «keep-alive» включена в стандартную работу протокола. Однако можно отправить заголовок Connection: close, чтобы явно закрыть соединение после завершения передачи данных.

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

3. Поддержка дополнительных методов: помимо стандартных методов GET, POST, и HEAD, HTTP/1.1 добавил методы:

   • PUT — для загрузки ресурса на сервер,

   • DELETE — для удаления ресурса,

   • OPTIONS — для определения поддерживаемых сервером методов,

   • TRACE — для проверки пути запроса до сервера и его преобразования.

4. Усовершенствованные заголовки: HTTP/1.1 ввёл несколько новых заголовков, увеличив гибкость и производительность протокола:

   • Host — теперь стал обязательным, что позволило использовать виртуальные хосты, обслуживающие несколько доменов на одном IP;

   • Cache-Control — улучшил управление кэшированием ресурсов на стороне клиента и сервера;

   • Transfer-Encoding: chunked — позволил передавать данные частями, что стало полезно для больших файлов и потоковых данных.

5. Управление кэшированием: HTTP/1.1 предоставил расширенные возможности управления кэшированием. Вместо устаревших заголовков Expires и Pragma появились заголовки:

   • Cache-Control — указывает, как долго и где кэшировать ресурсы;

   • ETag и If-Modified-Since — поддерживают кэширование на уровне изменённых ресурсов, что позволяет клиентам загружать только обновлённые версии ресурсов.

Структура запроса в HTTP/1.1

В HTTP/1.1 запросы и ответы были более структурированными, чем в HTTP/1.0.

1. Стартовая строка: указывала метод, путь и версию протокола.

2. Заголовки запроса: добавилась возможность указывать более сложные условия для запроса, такие как Accept-Encoding (для сжатия), User-Agent, Host (теперь обязательный).

3. Тело запроса: использовалось для передачи данных с методом POST или другими методами, такими как PUT.

Структура ответа в HTTP/1.1

1. Стартовая строка ответа: включала версию протокола, код состояния и его пояснение.

2. Заголовки ответа: сервер отправлял подробную информацию о ресурсе, его типе, длине, статусе кэширования и другом. В HTTP/1.1 эти заголовки стали более обширными.

3. Тело ответа: содержимое запрашиваемого ресурса.

Постоянные соединения: схема работы

С использованием постоянных соединений HTTP/1.1 уменьшил время загрузки веб-страниц. Теперь для каждого ресурса не требовалось открывать новое TCP-соединение.

Схема обмена данными выглядит так:

1. Клиент открывает соединение с сервером (SYN, SYN-ACK, ACK).

2. Клиент отправляет несколько запросов последовательно или параллельно через одно соединение (например, GET /timeweb.cloud.html и GET /style.css).

3. Сервер отвечает на каждый запрос, отправляя данные по одному и тому же соединению.

4. Клиент может оставлять соединение открытым для будущих запросов.

5. Когда клиент или сервер решают завершить взаимодействие, они отправляют запрос на завершение соединения (Connection: close или FIN).

Современные браузеры, которые используют HTTP/1.1 обычно используют несколько постоянных соединений для передачи нескольких запросов/ответов между сервером и клиентом. В каждом таком соединении можно передавать запросы/ответы последовательно или параллельно. Таких соединений обычно браузеры используют от 4-х до 8-ми. Такой вид передачи значительно повышают скорость работы.

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

Преимущества HTTP/1.1

HTTP/1.1 улучшил производительность интернета за счёт постоянных соединений и дополнительных возможностей, таких как:

• Снижение накладных расходов на установку TCP-соединений;

• Поддержка виртуальных хостов и более гибкое кэширование;

• Возможность отправки нескольких запросов в одном соединении с пайплайнингом.

HTTP/1.1 стал стандартом на долгие годы и до сих пор используется, хотя HTTP/2 и HTTP/3 уже внедрили новые технологии для повышения скорости и надёжности.

❯ HTTP 2

Основные улучшения и сравнение с SPDY

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

• Мультиплексирование. HTTP/2 позволяет параллельную передачу нескольких запросов и ответов в одном соединении, устраняя проблему блокировки, характерную для HTTP/1.1.

• Сжатие заголовков. Использование алгоритма HPACK для сжатия заголовков позволяет передавать меньше данных, особенно полезно при работе с частыми повторяющимися заголовками.

• Server Push. Сервер может отправлять дополнительные ресурсы, предугадывая их необходимость, что помогает сократить задержки на стороне клиента.

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

Сравнение с SPDY: SPDY был экспериментальным протоколом Google, от которого HTTP/2 перенял большинство концепций. Однако, HTTP/2 стал официальным стандартом с более широкой поддержкой и совместимостью. В отличие от экспериментального SPDY, HTTP/2 стал официальной спецификацией IETF.

Структура запроса

Запрос HTTP/2 состоит из набора фреймов (frame), каждый из которых может содержать разные типы данных, такие как заголовки или контент. Основные типы фреймов:

• HEADERS. Содержит HTTP-заголовки, использующие HPACK для сжатия;

• DATA. Фреймы данных, содержащие тело запроса.;

• PRIORITY. Указывает приоритетность обработки запроса, позволяя клиенту контролировать загрузку;

• SETTINGS. Передает параметры соединения между клиентом и сервером.

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

Структура ответа

HTTP/2-ответ также состоит из нескольких фреймов:

• HEADERS. Содержит статус ответа (например, код 200 OK) и все заголовки;

• DATA. Передает данные ответа;

• PUSH_PROMISE. Сообщает клиенту о дополнительных ресурсах, которые сервер готов отправить;

• WINDOW_UPDATE. Управляет скоростью передачи данных, контролируя окно потока.

Ответ передается в той же структуре потоков, что позволяет серверу эффективно распределять ресурсы.

Схема работы

Работа HTTP/2 начинается с установления TCP-соединения и обмена фреймами SETTINGS для настройки параметров соединения. Затем клиент отправляет запрос в виде фреймов HEADERS и DATA. Сервер отвечает фреймами HEADERS (для статуса) и DATA (для содержимого), при этом может отправить PUSH_PROMISE для ускорения загрузки ресурса.

1.  Клиент устанавливает соединение с сервером по TCP (процесс включает отправку пакетов SYN, SYN-ACK и ACK).

2.   Клиент отправляет несколько запросов параллельно по одному и тому же соединению (например, GET /timeweb.cloud.html и GET /style.css), используя технологию мультиплексирования. Это позволяет передавать несколько запросов и ответов одновременно без блокировок.

3.  Сервер обрабатывает каждый запрос и отправляет ответы в виде потоков, управляемых независимо по приоритету, через это же соединение.

4.  Клиент может оставлять соединение открытым для будущих запросов, избегая необходимости повторного установления соединения.

5.  Когда клиент или сервер хотят завершить взаимодействие, они отправляют запрос на закрытие соединения (обычно, FIN).

Для совместимости с существующей инфраструктурой некоторые клиенты и серверы могут сначала устанавливать соединение по HTTP/1.1 и использовать ALPN (Application-Layer Protocol Negotiation) — механизм TLS (про него чуть позже), позволяющий договариваться о версии протокола, — чтобы «договориться» об обновлении до HTTP/2. Если сервер поддерживает HTTP/2, соединение переключается на этот протокол, и клиент начинает использовать все возможности HTTP/2, такие как мультиплексирование, сжатие заголовков и приоритеты потоков.

Важное замечание. HTTP/2 по умолчанию использует TCP порт 443. Все версии ниже используют TCP порт 80 (Имеется в виду HTTP без шифрования).

Преимущества

• Повышенная производительность за счет мультиплексирования и сжатия заголовков.

• Меньшее количество соединений благодаря объединению нескольких потоков в одном TCP-соединении.

• Уменьшение задержек благодаря Server Push и сжатию заголовков.

❯ HTTP 3

Основные улучшения и сравнение с QUIC

HTTP/3 основан на протоколе QUIC, который разработан для улучшения передачи данных поверх UDP вместо TCP, что решает многие ограничения TCP:

• Использование QUIC поверх UDP. QUIC устраняет необходимость многократного установления соединения, свойственного TCP, и работает даже при кратковременных разрывах связи;

• Быстрое установление соединения. Благодаря встроенной поддержке TLS, QUIC минимизирует задержки при установке соединения;

• Независимые потоки. HTTP/3 устраняет блокировки потоков, присущие HTTP/2, так как каждый поток работает независимо.

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

Структура запроса

Запрос HTTP/3 также построен на фреймах, но они работают поверх независимых потоков, что обеспечивает их автономную передачу. Основные фреймы:

• HEADERS. Заголовки запроса;

• DATA. Тело запроса;

• CONTROL. Контролирующие данные для координации потоков.

Каждый запрос передается в отдельном потоке QUIC, что устраняет проблемы блокировки и снижает задержки.

Структура ответа

HTTP/3-ответ включает:

• HEADERS. Код статуса и заголовки;

• DATA. Основной контент ответа;

• CONTROL. Для обновления состояния потока.

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

Схема работы

HTTP/3 работает через UDP и использует QUIC для управления соединением. После обмена фреймами HEADERS и DATA, клиент может начинать обработку данных, а QUIC обеспечивает надёжное соединение даже в условиях сетевых потерь.

1.  Клиент открывает соединение с сервером, используя протокол QUIC поверх UDP.

2.  При установлении соединения происходит начальная настройка шифрования, встроенная в протокол QUIC, которая происходит быстрее, чем в TCP.

3.  Клиент отправляет несколько запросов (например, GET /timeweb.cloud.html и GET /style.css) одновременно в виде независимых потоков, где каждый поток обрабатывается независимо, устраняя возможную блокировку.

4.  Сервер отвечает на каждый запрос, отправляя данные по одному и тому же QUIC-соединению, причем каждый поток остается независимым — задержка или потеря данных в одном потоке не блокирует остальные.

5.  Соединение может оставаться открытым для будущих запросов, что уменьшает задержки при повторном обращении к серверу.

6.  При завершении работы клиент или сервер отправляют сообщение для закрытия соединения, и QUIC завершает его, освобождая ресурсы.

Как только сторона, получившая сообщение CONNECTION_CLOSE, подтверждает его получение, соединение считается закрытым. Это отличается от TCP, где завершение происходит поэтапно с использованием трехэтапного закрытия (FIN, FIN-ACK, ACK). QUIC упрощает этот процесс, позволяя более быстрое и эффективное освобождение ресурсов.

Приемущества

• Быстрое соединение и низкие задержки за счет устранения необходимости многократного установления соединения.

• Отсутствие блокировок потоков. Каждый поток в HTTP/3 независим, что устраняет проблемы потерь пакетов.

• Гибкость и надёжность в мобильных сетях за счет работы с динамически изменяющимся соединением.

Разница между HTTP/2 и HTTP/3

Хотя HTTP/2 и HTTP/3 оба поддерживают параллельные потоки для передачи данных, ключевые различия между ними заключаются в механизмах транспортного уровня и управлении потоками:

1. Транспортный протокол

• HTTP/2 работает поверх TCP (Transmission Control Protocol), где потоки данных передаются через одно TCP-соединение. TCP обеспечивает надежность, гарантируя доставку пакетов в правильном порядке. Однако при потере пакета в TCP, все потоки в этом соединении ожидают его повторной передачи — это вызывает явление, известное как блокировка головного узла (Head-of-Line Blocking). Несмотря на многопоточность на уровне HTTP/2, потеря пакета на уровне TCP блокирует остальные потоки.

• HTTP/3 использует QUIC вместо TCP. QUIC — это транспортный протокол, построенный поверх UDP, который поддерживает независимые потоки внутри одного соединения. Он решает проблему блокировки головного узла: потеря пакета в одном потоке не останавливает передачу данных в других потоках. Это позволяет HTTP/3 быть более эффективным, особенно при нестабильных соединениях, таких как мобильные сети.

2. Проблема блокировки головного узла

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

• HTTP/3 и QUIC устраняют эту проблему, так как каждый поток передается независимо. Потери пакетов в одном потоке не влияют на другие потоки, что снижает задержки.

3. Производительность и задержка

• HTTP/3 значительно уменьшает время установки соединения благодаря более быстрой процедуре «рукопожатия» (handshake) QUIC, которая также совмещена с начальным этапом TLS (шифрование). При повторных подключениях QUIC может пропускать часть этапов рукопожатия, что сокращает задержку.

• HTTP/2, с другой стороны, требует установления соединения TCP и отдельного TLS-рукопожатия. Это усложняет процедуру подключения, особенно при высокой задержке сети.

4. Устойчивость к сетевым изменениям

• QUIC позволяет привязать одно соединение к нескольким IP-адресам, поддерживая передачу данных даже при смене сетевого интерфейса (например, с Wi-Fi на сотовую сеть). Это делает HTTP/3 более стабильным в условиях мобильных сетей.

• HTTP/2 и TCP не поддерживают многопоточность на уровне IP, и изменение сетевого интерфейса приводит к обрыву соединения.

Итоговое сравнение

Таким образом, HTTP/3 обеспечивает более высокую производительность и стабильность благодаря отказу от TCP и использованию QUIC, что позволяет эффективно и независимо управлять потоками и уменьшать задержки.

❯ HTTPS

❯ Что такое HTTP?

HTTPS (HyperText Transfer Protocol Secure) — это расширение протокола HTTP, которое обеспечивает безопасную передачу данных в интернете. Он используется для защиты данных, передаваемых между клиентом (обычно веб-браузером) и сервером. Вот более подробное объяснение:

Безопасность данных

• HTTPS использует шифрование для защиты данных, передаваемых по сети. Это предотвращает перехват информации третьими лицами. Все данные, отправляемые и получаемые через HTTPS, шифруются с помощью протоколов SSL (Secure Sockets Layer) или TLS (Transport Layer Security).

Шифрование

• SSL и TLS: Эти протоколы обеспечивают шифрование соединения, что делает его безопасным. TLS — это более современная и безопасная версия SSL. В процессе установки соединения клиент и сервер обмениваются ключами шифрования, которые затем используются для шифрования данных.

• Защита от MITM-атак: Шифрование помогает предотвратить атаки «человек посередине» (MITM), при которых злоумышленник может перехватить и изменить передаваемую информацию.

Аутентификация

• HTTPS также обеспечивает аутентификацию веб-сайта с помощью сертификатов. Когда клиент подключается к серверу, сервер представляет цифровой сертификат, который подтверждает его личность. Этот сертификат выдается доверенной третьей стороной, называемой центром сертификации (CA).

• Проверка сертификата. Браузеры проверяют действительность сертификата перед установлением безопасного соединения. Если сертификат недействителен или не доверен, браузер может предупредить пользователя о потенциальной угрозе.

Целостность данных

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

❯ Как работает HTTPS?

1. Установка соединения: Клиент (браузер) инициирует запрос на создание HTTPS-соединения с сервером.

2. Обмен сертификатами: Сервер отправляет свой цифровой сертификат клиенту.

3. Проверка сертификата: Клиент проверяет сертификат и, если он действителен, генерирует симметричный ключ для шифрования данных.

4. Шифрование данных: Все передаваемые данные между клиентом и сервером шифруются с использованием этого ключа.

5. Завершение соединения: После обмена данными соединение может быть закрыто, или клиент и сервер могут оставить его открытым для дальнейших запросов.

Рассмотрим на примере алгоритма обмена ключами RSA (Rivest, Shamir и Adleman).

1. Клиент устанавливает соединение с сервером по TCP (процесс включает отправку пакетов SYN, SYN-ACK и ACK).

2. Клиент отправляет серверу сообщение «Hello».

3. Сервер передает открытый ключ клиенту.

4. Клиент генерирует ключ для симметричного шифрования. Зашифровывает этот ключ с помощью открытого ключа, который он получил от сервера.  Отправляет этот зашифрованный ключ серверу.

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

6. Начинается передача HTTP с шифрованием.

Преимущества использования HTTPS

• Повышенная безопасность. Защита личной информации пользователей, таких как пароли и номера кредитных карт.

• Улучшение SEO. Поисковые системы, такие как Google, отдают предпочтение сайтам с HTTPS, что может улучшить рейтинг сайта.

• Доверие пользователей. Знак «замка» в адресной строке браузера показывает пользователям, что соединение безопасно, что повышает доверие к сайту.

Области применения

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

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

Протокол HTTPS использует различные версии TLS (Transport Layer Security) в зависимости от версии HTTP. Вот как это работает:

1. HTTP/1.1 и HTTP/2

• Используемая версия TLS. Обычно используется TLS 1.2, но также может использоваться TLS 1.3.

• Причина:

  • TLS 1.2 был стандартом безопасности в течение многих лет и был широко поддерживаемым. Он обеспечивает улучшенную безопасность и производительность по сравнению с предыдущими версиями;

  • TLS 1.3, представлен в 2018 году, значительно улучшает производительность и безопасность, упрощая процесс рукопожатия и убирая устаревшие функции, которые могли подвергать систему рискам. Поскольку HTTP/2 был разработан с учетом современных требований безопасности и производительности, его реализация с TLS 1.3 является распространенной практикой.

2. HTTP/3

• Используемая версия TLS: TLS 1.3.

• Причина:

  • HTTP/3 работает поверх QUIC, который сам по себе уже включает в себя шифрование, аналогичное TLS. QUIC обеспечивает встроенное шифрование, что делает его использование более эффективным и безопасным. Поэтому для HTTP/3 применяется TLS 1.3, поскольку он оптимизирован для работы с QUIC, улучшая как безопасность, так и производительность;

  • Применение TLS 1.3 в сочетании с QUIC позволяет сократить время установления соединения благодаря более быстрому рукопожатию, что важно для повышения отзывчивости веб-приложений.

Сводная таблица:

Использование различных версий TLS с различными версиями HTTP связано с требованиями к безопасности и производительности. Новые версии протоколов, такие как TLS 1.3, были разработаны, чтобы соответствовать современным требованиям к безопасности, а также повысить эффективность передачи данных, что особенно важно для современных веб-приложений.

❯ Заключение

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

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

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

---

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩

📚 Читайте также:

• ➤ Что делать, когда хочется взломать пароль, крякнуть сенсор и попробовать Python? Ч1: исследуем ёмкостный touch screen;

• ➤ К звёздам на отечественной БИС 1537ХМ2: смотрим на модуль интегрированной инерциально-астроспутниковой системы;

• ➤ Комменты — наше все! История онлайн-комментариев;

• ➤ Не (одиночество в сети) NOW;

• ➤ Бегущий по флешбэкам.