Struchkov Mark
7d78047f43
All checks were successful
continuous-integration/drone/push Build is passing
102 lines
9.6 KiB
Markdown
102 lines
9.6 KiB
Markdown
---
|
||
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]]
|
||
**Автор**::
|
||
### Дополнительные материалы
|
||
-
|
||
|
||
### Дочерние заметки
|
||
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||
<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||
- [[Cookie]]
|
||
<!-- SerializedQuery END -->
|
||
|