HTTP
Предпосылки: TCP (соединение, сегмент), DNS (резолвинг имён).
Браузер знает IP-адрес сервера (DNS) и может установить надёжное соединение (TCP). Теперь клиенту и серверу нужен общий язык: как сформулировать “дай мне страницу /about”, как ответить “вот она”, как сообщить “такой страницы нет”. Этот язык — HTTP.
Модель запрос-ответ
HTTP (HyperText Transfer Protocol — протокол передачи гипертекста). “Гипертекст” — текст со ссылками, “hyper” — “сверх”, выход за рамки линейного чтения.
Модель проста: клиент отправляет запрос (request), сервер отправляет ответ (response). Каждый запрос независим — сервер не помнит предыдущие.
Структура запроса
GET /search?q=hello HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0
Accept: text/html
Стартовая строка: метод (GET), путь с query string (/search?q=hello), версия протокола (HTTP/1.1). Заголовки (headers) — пары “ключ: значение”, метаданные запроса. Пустая строка — разделитель между заголовками и телом. Тело (body) — данные (в GET обычно отсутствует).
Методы HTTP
| Метод | Назначение | Идемпотентный |
|---|---|---|
| GET | Получить данные | Да |
| POST | Отправить данные, создать ресурс | Нет |
| PUT | Заменить ресурс целиком | Да |
| PATCH | Частично обновить | Нет (обычно) |
| DELETE | Удалить | Да |
| HEAD | Только заголовки (без тела) | Да |
| OPTIONS | Узнать поддерживаемые методы | Да |
Идемпотентность (от латинского “idem” — тот же, “potent” — сила) — операция, которую можно выполнить много раз с тем же результатом. GET /users/123 — идемпотентный (всегда тот же пользователь). DELETE /users/123 — идемпотентный (после первого удаления пользователя уже нет). POST /users — не идемпотентный (каждый вызов создаёт нового пользователя). Это свойство критично при сетевых ошибках: идемпотентные методы можно безопасно повторить.
Структура ответа
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
<!DOCTYPE html>
<html>...</html>
Строка статуса: версия, код, текст.
Коды статуса
| Диапазон | Категория | Примеры |
|---|---|---|
| 1xx | Информационные | 100 Continue |
| 2xx | Успех | 200 OK, 201 Created, 204 No Content |
| 3xx | Перенаправления | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | Ошибки клиента | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
| 5xx | Ошибки сервера | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable |
Заголовки
В запросе: Host — домен (обязателен в HTTP/1.1, позволяет хостить несколько сайтов на одном IP), Authorization — учётные данные, Content-Type — тип данных в теле, Accept — ожидаемый тип ответа, Cookie — куки.
В ответе: Content-Type — тип данных, Content-Length — размер тела, Set-Cookie — установить куку, Cache-Control — инструкции кеширования, Location — URL для редиректа.
Cookies и сессии
HTTP — stateless (без состояния): сервер не помнит предыдущие запросы. Но для аутентификации нужно помнить, кто этот клиент. Cookie — данные, которые сервер просит браузер сохранить и отправлять с каждым запросом.
Механизм: сервер отправляет Set-Cookie: session_id=abc123; HttpOnly; Secure, браузер сохраняет и при следующих запросах прикладывает Cookie: session_id=abc123. Сервер по session_id находит сессию — данные на сервере, связанные с этим клиентом.
Атрибуты cookies: HttpOnly — недоступна из JavaScript (защита от XSS — Cross-Site Scripting, внедрение вредоносного кода через пользовательский ввод), Secure — только по HTTPS, SameSite — ограничение межсайтовых запросов (защита от CSRF — Cross-Site Request Forgery, подделка запросов от имени авторизованного пользователя), Max-Age / Expires — время жизни.
REST
REST (Representational State Transfer) — архитектурный стиль для API. Не протокол, а набор принципов: ресурсы идентифицируются через URI (/users/123), операции выражаются через HTTP-методы, сервер не хранит состояние клиента между запросами. Подробнее о проектировании API: API Design.
HTTP передаёт данные открытым текстом — любой промежуточный узел может прочитать содержимое запроса. Для защиты данных HTTP оборачивается в TLS.