Какие коды ответов ты знаешь

Основные коды ответов HTTP

Коды состояния HTTP (HTTP Status Codes) — это стандартизированные числовые ответы сервера на клиентские запросы, которые указывают на результат обработки запроса. Как DevOps Engineer, я работаю с ними ежедневно для мониторинга, отладки и обеспечения доступности сервисов. Коды разделены на пять классов по первой цифре.

1xx: Информационные коды (Informational)

Эти коды указывают, что запрос принят и обработка продолжается. Чаще встречаются в долгих или асинхронных операциях.

• 100 Continue: Сервер получил заголовки запроса и клиент может отправлять тело запроса.
• 101 Switching Protocols: Сервер согласен сменить протокол (например, с HTTP на WebSocket).
• 102 Processing: Сервер обрабатывает запрос, но ответ ещё не готов (используется в WebDAV).

2xx: Коды успеха (Success)

Запрос успешно обработан. Для DevOps критически важно, чтобы основная доля запросов попадала в этот диапазон.

• 200 OK: Стандартный ответ для успешных запросов. Тело ответа содержит запрошенные данные.

  HTTP/1.1 200 OK
  Content-Type: application/json
  {"status": "success", "data": {...}}
  

• 201 Created: Запрос выполнен, новый ресурс создан (например, после POST).
• 202 Accepted: Запрос принят, но обработка ещё не завершена (асинхронные задачи).
• 204 No Content: Сервер успешно обработал запрос, но тело ответа отсутствует (удачное DELETE).

3xx: Коды перенаправления (Redirection)

Требуется дополнительное действие со стороны клиента (чаще всего — переход по другому URL). DevOps часто настраивает их на уровне веб-серверов (Nginx/Apache).

• 301 Moved Permanently: Ресурс постоянно перемещён на новый URI.
• 302 Found (или 307 Temporary Redirect): Временное перенаправление.
• 304 Not Modified: Используется для кэширования. Ресурс не изменился с момента последнего запроса (Cache-Control, ETag).

4xx: Ошибки клиента (Client Error)

Запрос содержит ошибку или сервер не может его выполнить из-за клиентской стороны (неверный синтаксис, авторизация и т.д.). Мониторинг этих ошибок помогает выявить проблемы в клиентских приложениях или конфигурации.

• 400 Bad Request: Общая ошибка из-за неверного синтаксиса запроса.
• 401 Unauthorized: Требуется аутентификация. Заголовок WWW-Authenticate указывает схему.
• 403 Forbidden: Сервер понял запрос, но отказывается его авторизовать (нет прав).
• 404 Not Found: Самый известный код — ресурс не найден.

  # Пример в логах Nginx
  192.168.1.1 - - [15/Oct/2023:10:00:00] "GET /old-page.html HTTP/1.1" 404 123 "-"
  

• 429 Too Many Requests: Клиент отправил слишком много запросов за короткое время (защита от DDoS, rate limiting).

5xx: Ошибки сервера (Server Error)

Сервер не смог выполнить валидный запрос. Для DevOps это наиболее критический класс ошибок, напрямую указывающий на проблемы в инфраструктуре или приложении. Их появление требует немедленного реагирования.

• 500 Internal Server Error: Общая ошибка сервера без конкретной причины (сбой в коде приложения, исключение).
• 502 Bad Gateway: Сервер, выступая в роли шлюза или прокси, получил недействительный ответ от вышестоящего сервера (частая проблема при падении бэкенд-сервиса или неправильной конфигурации прокси).
• 503 Service Unavailable: Сервис временно недоступен (перегрузка, плановое обслуживание). Часто сопровождается заголовком Retry-After.
• 504 Gateway Timeout: Таймаут при ожидании ответа от вышестоящего сервера (проблемы с сетью или долгим ответом бэкенда).

Практическое значение для DevOps

Понимание и анализ этих кодов — базовая компетенция:

1. Мониторинг и алертинг: Настройка дашбордов в Prometheus/Grafana или Datadog с отдельным отслеживанием rate 5xx и 4xx ошибок. Рост 5xx — повод для PagerDuty.
2. Анализ логов: Поиск паттернов в ELK Stack или Loki.

   # Поиск 5xx ошибок в access.log
   grep '" 5[0-9][0-9] ' /var/log/nginx/access.log | head -20
   

3. Настройка балансировщиков и прокси: В Nginx или HAProxy конфигурируется поведение при получении определенных кодов от бэкенда (retry, fallback).

   # Пример конфигурации Nginx для обработки ошибок бэкенда
   upstream backend {
       server backend1:8080 max_fails=3 fail_timeout=30s;
       server backend2:8080 backup;
   }
   error_page 502 503 504 /50x.html;
   location = /50x.html { ... }
   

4. Тестирование и resilience: Использование инструментов вроде k6 или Locust для нагрузочного тестирования и проверки, не появляются ли 5xx под нагрузкой.
5. Rate Limiting и безопасность: Блокировка IP-, выдающих слишком много 4xx (сканирование уязвимостей) на уровне WAF или самого веб-сервера.

Таким образом, коды HTTP — это не просто абстрактные числа, а ключевой язык взаимодействия между компонентами распределённой системы. Их правильная интерпретация и реакция на них лежат в основе обеспечения высокой доступности (High Availability), отказоустойчивости (Fault Tolerance) и производительности (Performance) сервисов.