--- aliases: - HTTP tags: - maturity/🌱 date: 2024-10-29 --- НТТР (англ. Hyper Text Transfer Protocol - «протокол передачи гипертекста») - протокол прикладного уровня передачи данных. Изначально - в виде гипертекстовых документов в формате «HTML», в настоящий момент используется для передачи произвольных данных. HTTP сообщения состоят из трех частей, которые передаются в указанном порядке: - Стартовая строка - определяет тип сообщения - HTTP-заголовки - характеризуют тело сообщения, параметры передачи и прочие сведения - Пустая строка для отделения данных от заголовков. - Тело сообщения - данные. - [[Cookie|Cookie]] ## Http методы - GET - получить содержимое указанного ресурса - HEAD - получить только заголовки - POST - отправить данные на создание - PUT - отправить данные на обновление - DELETE - удалить указанный ресурс - OPTIONS - определить параметры сервера ## HTTP заголовки Заголовки - строки в 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 ![[../../meta/files/images/Pasted image 20241103014445.png]] **HTTP 1.0** был завершён и полностью задокументирован в 1996 году. Для каждого запроса к одному и тому же серверу требуется отдельное [[../../../../knowledge/dev/network/TCP|TCP]]-соединение. **HTTP 1.1** был опубликован в 1997 году. [[../../../../knowledge/dev/network/TCP|TCP]]-соединение теперь можно оставить открытым для повторного использования (постоянное соединение), но проблема блокировки первой строки (Head-of-Line, HOL) не решена. > [!NOTE] Head-of-Line, HOL > Ситуация, когда лимит параллельных запросов в браузере исчерпан, и последующие запросы вынуждены ждать завершения предыдущих. ![[../../meta/files/images/Pasted image 20241127084201.png]] - Для идентификации ресурсов использует [[Uniform Resource Identifier|URI]]. - Стартовая строка и заголовок являются обязательными - Обязательно содержится заголовок Host **HTTP 2.0** был опубликован в 2015 году. Он решает проблему HOL на уровне приложения благодаря мультиплексированию запросов, устраняя блокировку HOL на этом уровне. Однако проблема остаётся на транспортном уровне ([[../../../../knowledge/dev/network/TCP|TCP]]). Как показано на диаграмме, HTTP 2.0 ввёл концепцию HTTP “streams”: это абстракция, которая позволяет мультиплексировать различные HTTP-запросы в рамках одного [[../../../../knowledge/dev/network/TCP|TCP]]-соединения. Каждый поток может передаваться независимо от остальных. **HTTP 3.0** впервые был опубликован в виде черновика в 2020 году. Он предложен как преемник HTTP 2.0. Вместо [[../../../../knowledge/dev/network/TCP|TCP]] для транспортного уровня используется протокол QUIC, что устраняет блокировку HOL на уровне транспорта. **QUIC** основан на протоколе **UDP**. Он вводит потоки как полноценные сущности на уровне транспорта. Потоки QUIC используют одно и то же соединение QUIC, поэтому для создания новых потоков не требуется дополнительных рукопожатий и медленного старта. При этом потоки QUIC доставляются независимо друг от друга, что означает, что в большинстве случаев потеря пакетов, влияющая на один поток, не затрагивает остальные. ## HTTPS ![[../../meta/files/images/photo_2024-10-29 18.27.09.jpeg]] ![[../../meta/files/images/Pasted image 20241103035804.png]] **Как происходит шифрование и дешифрование данных** - **Шаг 1** — Клиент (браузер) и сервер устанавливают [[../../../../knowledge/dev/network/TCP|TCP]]-соединение. - **Шаг 2** — Клиент отправляет серверу сообщение «client hello». Это сообщение содержит набор поддерживаемых алгоритмов шифрования (наборов шифров) и последнюю версию TLS, которую клиент может поддерживать. Сервер отвечает сообщением «server hello», чтобы сообщить клиенту, какие алгоритмы и версия TLS поддерживаются. - Затем сервер отправляет клиенту SSL-сертификат, который содержит публичный ключ, имя хоста, срок действия сертификата и другую информацию. Клиент проверяет подлинность сертификата. - **Шаг 3** — После успешной проверки SSL-сертификата клиент генерирует сеансовый ключ и шифрует его с помощью публичного ключа. Сервер получает зашифрованный сеансовый ключ и дешифрует его с использованием своего приватного ключа. - **Шаг 4** — Теперь, когда и клиент, и сервер обладают одним и тем же сеансовым ключом (симметричное шифрование), данные передаются в зашифрованном виде по защищённому двустороннему каналу. **Почему HTTPS переключается на симметричное шифрование для передачи данных?** 1. **Безопасность**: Асимметричное шифрование работает только в одну сторону. Это означает, что если сервер попытается отправить зашифрованные данные обратно клиенту, любой сможет расшифровать их, используя публичный ключ. 2. **Ресурсы сервера**: Асимметричное шифрование требует значительных вычислительных ресурсов из-за сложных математических операций. Это делает его непригодным для передачи данных в долгих сессиях. *** ## Мета информация **Область**:: [[../../meta/zero/00 Сети|00 Сети]] **Родитель**:: **Источник**:: **Создана**:: [[2024-11-03]] **Автор**:: ### Дополнительные материалы - ### Дочерние заметки - [[Cookie]]