digital-garden/dev/network/HyperText Transfer Protocol.md

aliases	tags	date
HTTP	maturity/🌱	2024-10-29

НТТР (англ. Hyper Text Transfer Protocol - «протокол передачи гипертекста») - протокол прикладного уровня передачи данных. Изначально - в виде гипертекстовых документов в формате «HTML», в настоящий момент используется для передачи произвольных данных.

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

• Стартовая строка - определяет тип сообщения

• HTTP-заголовки - характеризуют тело сообщения, параметры передачи и прочие сведения

• Пустая строка для отделения данных от заголовков.

• Тело сообщения - данные.

• Cookie

Http методы

• GET - получить содержимое указанного ресурса
• HEAD - получить только заголовки
• POST - отправить данные на создание
• PUT - отправить данные на обновление
• DELETE - удалить указанный ресурс
• OPTIONS - определить параметры сервера

HTTP заголовки

Заголовки - строки в HTTP сообщении, содержащие разделенную двоеточием пару параметр-значение.

Пример заголовков:

Server: nginx/1.16.1
Date: Tue, 10 Dec 2019 16:32:07 GMT
Content-Type: image/jpeg
Content-Length: 33519
Last-Modified: Mon, 19 Feb 2018 04:59:24 GMT
Connection: keep-alive ETag: "1a7a93ac-34ef"
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: * 
Access-Control-Allow-Headers: *
Access-Control-Max-Age: 86400
Accept-Ranges: bytes

Заголовки подразделяются на четыре основные группы:

• General Headers - могут включаться в любое сообщение клиента и сервера
• Request Headers - используются только в запросах клиента
• Response Headers - используются только для ответов от сервера
• Entity Headers - сопровождают каждую сущность сообщения

Можно добавлять свои кастомные заголовки. Традиционно кастомные заголовки начинаются с префикса X-, чтобы избежать конфликта имен с существующими.

История развития HTTP

!

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 Ситуация, когда лимит параллельных запросов в браузере исчерпан, и последующие запросы вынуждены ждать завершения предыдущих.

!

• Для идентификации ресурсов использует Uniform Resource Identifier.
• Стартовая строка и заголовок являются обязательными
• Обязательно содержится заголовок Host

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 доставляются независимо друг от друга, что означает, что в большинстве случаев потеря пакетов, влияющая на один поток, не затрагивает остальные.

HTTPS

!

! Как происходит шифрование и дешифрование данных

• Шаг 1 — Клиент (браузер) и сервер устанавливают ../../../../knowledge/dev/network/TCP-соединение.
• Шаг 2 — Клиент отправляет серверу сообщение «client hello». Это сообщение содержит набор поддерживаемых алгоритмов шифрования (наборов шифров) и последнюю версию TLS, которую клиент может поддерживать. Сервер отвечает сообщением «server hello», чтобы сообщить клиенту, какие алгоритмы и версия TLS поддерживаются.
• Затем сервер отправляет клиенту SSL-сертификат, который содержит публичный ключ, имя хоста, срок действия сертификата и другую информацию. Клиент проверяет подлинность сертификата.
• Шаг 3 — После успешной проверки SSL-сертификата клиент генерирует сеансовый ключ и шифрует его с помощью публичного ключа. Сервер получает зашифрованный сеансовый ключ и дешифрует его с использованием своего приватного ключа.
• Шаг 4 — Теперь, когда и клиент, и сервер обладают одним и тем же сеансовым ключом (симметричное шифрование), данные передаются в зашифрованном виде по защищённому двустороннему каналу.

Почему HTTPS переключается на симметричное шифрование для передачи данных?

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

---

Мета информация

Область:: ../../meta/zero/00 Сети Родитель:: Источник:: Создана:: 2024-11-03 Автор::

Дополнительные материалы

Дочерние заметки

• Cookie