Skip to content

HTTP-proto.md

Latest commit

 

History

History
196 lines (170 loc) · 10.6 KB

HTTP-proto.md

File metadata and controls

196 lines (170 loc) · 10.6 KB

HTTP/1.0 (1996)

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

Пример GET-запроса:

GET /index.html HTTP/1.1
Host: www.example.com
Connection: close

Пример POST-запроса:

POST /submit-form HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
Connection: close

name=John&age=30&city=NY
  • Стартовая строка
    • Метод
      • GET
      • POST
      • HEAD
    • URI
      • Url encoding:
        • Пробел → %20
        • = → %3D
        • ; → %3B
    • Версия
  • Заголовки (Headers)
    • Host — обязательный заголовок
    • Cookie
    • Accept
    • Accept-encoding
    • Accept-language:
    • Cache-control
    • Referer
    • User-agent
    • Content-Type
  • Тело (Body)
    • Рассказать о различных Content-Type, включая application/x-www-form-urlencoded

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

HTTP/1.1 200 OK
Date: Mon, 07 Jan 2025 12:00:00 GMT
Content-Type: text/html; charset=UTF-8
Connection: close

<!DOCTYPE html>
<html>
<head><title>Example Page</title></head>
<body><h1>Welcome to Example!</h1></body>
</html>
  • Стартовая строка
    • Коды состояния
      • 1xx — Info
      • 2xx — Success
      • 3xx — Redirection
      • 4xx — Client Error
      • 5xx — Server Error
  • Заголовки
    • Content-type
    • Content-language
    • Date / Expires / Last-modified
  • Тело

Cookies

  • Зачем нужны и как использовать
  • Cookie на сервере
  • Set-Cookie на клиенте
  • Формат отдельного параметры cookie: name=value
centralauth_User=Despairr; ruwikiss0-UserName=Despairr; ruwikiUserName=Despairr; centralauth_ss0-Token=65bc2c8c0fcaed5b5f81baa8c72f746f; centralauth_Token=65bc2c8c0fcaed5b5f81baa8c724746d; GeoIP=RU:SAM:Samara:53.19:50.16:v4; ruwikimwuser-sessionId=9166d9b351c54d332bbe; ruwikiSession=0bs3ajkjcii8v0hm6fc5cd2njrgf9tqa; centralauth_Session=97cb6f92a6ca55e555d2805f2acabbb1; WMF-Last-Access=07-Jan-2025; WMF-Last-Access-Global=07-Jan-2025; NetworkProbeLimit=0.001; WMF-DP=d04,430
  • Ограничения на значения cookies:
    • Стандарт допускает в значениях cookies буквы, цифры и следующие символы: ! # $ % & ' ( ) * + - . / : < = > ? @ [ \ ] ^ _ { | } ~
  • Кодирование значений cookie
    • url encoding
    • base64

HTTP/1.1 (1997, RFC 2068, обновлён в 1999 году RFC 2616)

Наиболее распространённая версия до появления HTTP/2. Особенности:

  • Постоянные соединения (Keep-Alive) для многократных запросов через одно подключение.
    • Connection: close
    • Connection: keep-alive
    • Keep-Alive: 300
  • Пайплайнинг: возможность отправки нескольких запросов до получения ответа (но это редко использовалось из-за сложностей с реализацией).
  • Поддержка кеширования и улучшение обработки ошибок.
  • Новые методы: PUT, DELETE, OPTIONS, TRACE.
  • Поддержка chunked transfer encoding (передача данных частями)

HTTP/2 (2015, RFC 7540)

Основное нововведение для ускорения работы веб-приложений. Особенности:

  • Бинарный формат вместо текстового: меньше ошибок, выше производительность.
  • Мультиплексирование: возможность отправки нескольких запросов одновременно через одно соединение.
  • Сжатие заголовков: уменьшение объёма данных благодаря HPACK.
  • Server Push: сервер может отправлять ресурсы (например, CSS или JS), даже если клиент их не запрашивал.
  • Улучшение производительности на медленных и высоколатентных соединениях.

Недостатки:

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

Основные особенности бинарного формата в HTTP/2:

  1. Бинарные фреймы:
    • HTTP/2 разбивает данные на фреймы (frames), которые передаются в бинарном формате.
    • Примеры фреймов:
      • HEADERS: для передачи заголовков.
      • DATA: для передачи содержимого.
      • SETTINGS: для настройки соединения.
  2. Мультиплексирование:
    • Разные потоки данных передаются параллельно в рамках одного TCP-соединения.
    • Бинарные фреймы позволяют легче разделять данные разных потоков.
  3. Сжатие заголовков (HPACK):
    • Заголовки HTTP/2 передаются в сжатом бинарном формате для уменьшения накладных расходов.

Что даёт бинарный формат в реальной жизни: Размер:

  • Заголовки в HTTP/2 в среднем на 30-50% меньше по размеру по сравнению с HTTP/1.x благодаря сжатию HPACK
  • На реальном трафике компрессия заголовков дает экономию 20-88% в зависимости от типа запросов Скорость парсинга:
  • Бинарный парсинг HTTP/2 на 20-40% быстрее текстового HTTP/1.x
  • Основной выигрыш в скорости достигается за счет:
    • Отсутствия необходимости текстового парсинга
    • Фиксированных форматов полей
    • Более эффективной обработки бинарных данных

Согласование версии протокола (для бинарного протокола)

Как HTTP-клиент узнаёт, что сервер поддерживает бинарный протокол HTTP/2?

  1. Через механизм ALPN (Application-Layer Protocol Negotiation)
    • Клиент в процессе установки TLS-соединения через механизм ALPN отправляет список поддерживаемых протоколов, например: h2, http/1.1
  2. Через Upgrade-заголовок (для HTTP на TCP)
    • В случае незашифрованного соединения (HTTP/1.1) клиент может попробовать инициировать использование HTTP/2 через заголовок Upgrade:
GET / HTTP/1.1
Host: example.com
Upgrade: h2c
Connection: Upgrade

Если сервер поддерживает HTTP/2, он отвечает:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c

После этого клиент и сервер переключаются на HTTP/2. Этот метод редко используется, так как большинство HTTP/2-соединений работают через TLS. Для максимальной безопасности ALPN предпочтителен.

HTTP/3 (2022, RFC 9114)

Построен на базе протокола QUIC (разработан Google). Особенности:

  • Использует UDP вместо TCP: меньше задержек на установку соединений.
  • Интеграция TLS 1.3: безопасность встроена с самого начала.
  • Устойчивость к потере пакетов: отдельные потоки не блокируют друг друга.
  • Более быстрая загрузка веб-страниц, особенно на мобильных устройствах и в условиях нестабильного подключения. Недостатки: • Требует обновления серверов и клиентских приложений. • Ограниченная поддержка в старых системах.

HTTP/3 работает исключительно через протокол UDP с использованием транспортного протокола QUIC. Этот дизайн является фундаментальной особенностью HTTP/3 и не поддерживает работу через TCP.

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

Версия Протокол Подключение Основные улучшения
HTTP/1.0 TCP Одноразовое Заголовки, статусы
HTTP/1.1 TCP Постоянное Пайплайнинг, кеширование
HTTP/2 TCP Постоянное Бинарный формат, мультиплексирование
HTTP/3 UDP (QUIC) Постоянное Быстрее соединение, TLS 1.3

Полезные ссылки

gRPC