Какие ошибки при взаимодействии клиента и сервера использовал на практике

Отличный вопрос, который позволяет раскрыть как теоретические знания, так и практический опыт. За свою карьеру я сталкивался с огромным спектром ошибок на всех уровнях взаимодействия клиента и сервера. Разделю их по категориям и приведу конкретные примеры.

1. Ошибки уровня сети и транспорта

Это фундаментальные проблемы, связанные с самой доставкой запроса.

• Таймауты (Timeout): Самый частый случай. Бывает, когда сервер не отвечает в отведенное клиентом время.

    *   **На практике:** Настройка слишком агрессивных таймаутов (например, 1 секунда для тяжелого отчета) в клиентском приложении. Или, наоборот, сервер зависает из-за deadlock в БД и не отвечает вообще. Мониторинг и анализ логов сервера (например, время ответа 95-го перцентиля) были ключом к поиску.
    *   **Пример в логах/коде:**

    ```bash
    # Клиентский лог
    ERROR - Request to /api/v1/report failed: Connection timed out after 5000ms
    ```

• Разрыв соединения (Connection Reset / Aborted): Клиент или сервер неожиданно закрывает соединение.

    *   **На практике:** Происходило при скачивании больших файлов через неустойчивое мобильное соединение. Также часто случалось из-за **балансировщиков нагрузки (Load Balancer)**, которые обрывали "долгие" keep-alive соединения по своим таймаутам, меньшим, чем на сервере.

2. Ошибки уровня HTTP/Протокола приложения

Ошибки, которые сервер понимает и на которые может дать структурированный ответ.

Клиентские ошибки (4xx)

• 400 Bad Request: "Некорректный запрос".

    *   **На практике:** Чаще всего — невалидный JSON в теле запроса (пропущена кавычка, запятая). Или несоответствие формата данных: передача строки `"price": "сто рублей"` вместо числа `"price": 100` в JSON, или `email` без символа `@`.
    *   **Пример:**

    ```json
    // Клиент отправил:
    {"name": "Ivan", "age": "двадцать пять"}

    // Сервер ожидал:
    {"name": "Ivan", "age": 25}
    // Ответ: 400 с деталями в body: {"error": "Field 'age': number expected, got string"}
    ```

• 401 Unauthorized / 403 Forbidden: Путаница между аутентификацией (кто ты?) и авторизацией (что тебе можно?).

    *   **На практике:** Реализация OAuth 2.0, где просроченный или отозванный **access token** должен возвращать `401`, а попытка доступа к админ-панели обычным пользователем — `403`. Частая ошибка разработки — возвращать `403` на просроченный токен, что сбивало клиент с толку.

• 404 Not Found: "Ресурс не найден".

    *   **На практике:** Не только когда страницы нет. Частая проблема в REST API — клиент запрашивает несуществующую сущность по ID: `GET /api/users/99999`. Важно проверять, что такой ID вообще есть в БД.

• 409 Conflict: "Конфликт".

    *   **На практике:** Классический пример — попытка создать пользователя с уже существующим `email` или выполнить параллельное изменение одной и той же сущности с нарушением **оптимистичной блокировки (optimistic lock)**.

• 422 Unprocessable Entity: Более конкретная версия 400. Часто используется для ошибок бизнес-логики валидации.

    *   **На практике:** Использовали для валидации входных данных, когда запрос синтаксически корректен, но семантически ошибочен: дата рождения в будущем, сумма перевода превышает баланс.

Серверные ошибки (5xx)

• 500 Internal Server Error: "Общая ошибка сервера".

    *   **На практике:** Непойманное исключение (**unhandled exception**) в коде сервера (NullPointerException, DivisionByZero). Всегда требовал срочного расследования, так как указывал на баг.

• 502 Bad Gateway / 504 Gateway Timeout: Ошибки прокси-серверов.

    *   **На практике:** Постоянно возникали в связке **Nginx + Backend-сервер (например, Gunicorn)**. `502` — если бэкенд-процесс "упал" и Nginx не может с ним связаться. `504` — если бэкенд не ответил Nginx'у в отведенный таймаут (часто при высоких нагрузках).

• 503 Service Unavailable: "Сервис недоступен".

    *   **На практике:** Сервер перегружен и сознательно отказывается принимать новые соединения. Часто используется при planned maintenance или при срабатывании **circuit breaker** в микросервисной архитектуре.

3. Ошибки уровня данных и бизнес-логики

Самые коварные, потому что протокол считает их успешными.

• Несоответствие формата данных (Data Schema Mismatch): Сервер меняет API (добавляет/переименовывает поле), а клиентское приложение (особенно мобильное) еще не обновилось. Клиент падает при попытке распарсить ответ.

    *   **На практике:** Использовали **версионирование API (`/api/v1/`, `/api/v2/`)** и строгие контракты (например, **Swagger/OpenAPI**). А также тестирование на **обратную совместимость**.

• Частичный или некорректный ответ: Сервер отвечает 200 OK, но в теле ответа — пустой массив, null или неполные данные.

    *   **На практике:** Было в API поиска: при ошибке в Elasticsearch сервер логировал исключение, но возвращал клиенту `200` с `{ "results": [] }`. Тестирование требовало анализа логов сервера параллельно с ответом.

• Проблемы с состоянием (State Issues): Race condition при параллельных запросах. Классика: два запроса на списание средств с одного счета, прошедшие проверку баланса одновременно, приводят к отрицательному балансу.

    *   **На практике:** Обнаруживалось нагрузочным тестированием (**load testing**) и требовало исправления на уровне БД (транзакции с правильной изоляцией).

4. Ошибки, специфичные для окружения и инфраструктуры

• CORS (Cross-Origin Resource Sharing) ошибки: Браузер блокирует запрос с фронтенда на другой домен/порт, если сервер не выставляет правильные заголовки (Access-Control-Allow-Origin).

    *   **На практике:** Постоянная проблема на этапе разработки, когда фронт на `localhost:3000` стучится на бэкенд на `localhost:8080`.

• Проблемы с кэшированием: Клиент получает устаревшие данные из-за агрессивного кэширования (например, Cache-Control заголовков) или, наоборот, постоянно запрашивает одни и те же данные, потому что кэширование отключено.

• Ошибки, связанные с балансировщиком/прокси: Сессионная "липкость" (sticky session) не работает, и запросы пользователя попадают на разные инстансы приложения, где нет его состояния.

В качестве итога: Моя практика показала, что критически важно не просто фиксировать факт ошибки, а уметь триангулировать ее источник: анализировать логи клиента, логи сервера, логи сети (например, через Wireshark или tcpdump), метрики (Prometheus, Grafana) и трассировку (Jaeger, Zipkin). Это позволяет быстро определить, где находится корень проблемы: в клиентском коде, серверной логике, конфигурации инфраструктуры или в самой сети.