Struchkov Mark
935f64fcf2
6.3 KiB
| aliases | tags | date | |
|---|---|---|---|
|
2024-10-29 |
!
HTTP 1.0 был завершён и полностью задокументирован в 1996 году. Для каждого запроса к одному и тому же серверу требуется отдельное ../../../../knowledge/dev/network/TCP-соединение.
HTTP 1.1 был опубликован в 1997 году. ../../../../knowledge/dev/network/TCP-соединение теперь можно оставить открытым для повторного использования (постоянное соединение), но проблема блокировки первой строки (Head-of-Line, HOL) не решена.
[!NOTE] Head-of-Line, HOL Ситуация, когда лимит параллельных запросов в браузере исчерпан, и последующие запросы вынуждены ждать завершения предыдущих.
HTTP 2.0 был опубликован в 2015 году. Он решает проблему HOL на уровне приложения благодаря мультиплексированию запросов, устраняя блокировку HOL на этом уровне. Однако проблема остаётся на транспортном уровне (../../../../knowledge/dev/network/TCP).
Как показано на диаграмме, HTTP 2.0 ввёл концепцию HTTP “streams”: это абстракция, которая позволяет мультиплексировать различные HTTP-запросы в рамках одного ../../../../knowledge/dev/network/TCP-соединения. Каждый поток может передаваться независимо от остальных.
HTTP 3.0 впервые был опубликован в виде черновика в 2020 году. Он предложен как преемник HTTP 2.0. Вместо ../../../../knowledge/dev/network/TCP для транспортного уровня используется протокол QUIC, что устраняет блокировку HOL на уровне транспорта.
QUIC основан на протоколе UDP. Он вводит потоки как полноценные сущности на уровне транспорта. Потоки QUIC используют одно и то же соединение QUIC, поэтому для создания новых потоков не требуется дополнительных рукопожатий и медленного старта. При этом потоки QUIC доставляются независимо друг от друга, что означает, что в большинстве случаев потеря пакетов, влияющая на один поток, не затрагивает остальные.
!
!
Как происходит шифрование и дешифрование данных
- Шаг 1 — Клиент (браузер) и сервер устанавливают ../../../../knowledge/dev/network/TCP-соединение.
- Шаг 2 — Клиент отправляет серверу сообщение «client hello». Это сообщение содержит набор поддерживаемых алгоритмов шифрования (наборов шифров) и последнюю версию TLS, которую клиент может поддерживать. Сервер отвечает сообщением «server hello», чтобы сообщить клиенту, какие алгоритмы и версия TLS поддерживаются.
- Затем сервер отправляет клиенту SSL-сертификат, который содержит публичный ключ, имя хоста, срок действия сертификата и другую информацию. Клиент проверяет подлинность сертификата.
- Шаг 3 — После успешной проверки SSL-сертификата клиент генерирует сеансовый ключ и шифрует его с помощью публичного ключа. Сервер получает зашифрованный сеансовый ключ и дешифрует его с использованием своего приватного ключа.
- Шаг 4 — Теперь, когда и клиент, и сервер обладают одним и тем же сеансовым ключом (симметричное шифрование), данные передаются в зашифрованном виде по защищённому двустороннему каналу.
Почему HTTPS переключается на симметричное шифрование для передачи данных?
- Безопасность: Асимметричное шифрование работает только в одну сторону. Это означает, что если сервер попытается отправить зашифрованные данные обратно клиенту, любой сможет расшифровать их, используя публичный ключ.
- Ресурсы сервера: Асимметричное шифрование требует значительных вычислительных ресурсов из-за сложных математических операций. Это делает его непригодным для передачи данных в долгих сессиях.
Мета информация
Область:: ../../meta/zero/00 Сети Родитель:: Источник:: Создана:: 2024-11-03 Автор::