502, 503, 504...
502, 503, 504... • Вы наверняка сталкивались с ошибками 502 Bad Gateway, 503 Service Unavailable и 504 Gateway Timeout. Эти ошибки появляются неожиданно и пугают тем, что где-то что-то упало. Но откуда вообще они взялись и что означают? • Дело в том, что когда протокол HTTP только появился, он был удивительно прост - браузер шёл к одному серверу, и тот почти всегда отвечал. В ранних версиях вроде HTTP/0.9 никаких статусов вообще не существовало, поэтому интерпретировать там было нечего. • Нумерация ответов появилась в HTTP/1.0, в середине девяностых. Тогда между клиентом и сервером начали появляться посредники, а вместе с ними и классические 500-е коды. Именно тогда оформились 502 Bad Gateway и 503 Service Unavailable. То есть понимание о том, что ломаться может не приложение, а путь к нему, появилось задолго до эпохи облаков. • С HTTP/1.1 в 1997–1999 годах архитектуры стали многоуровневыми - появились прокси, балансировщики, шлюзы, а чуть позже и API-шлюзы. Под такую реальность в стандарт добавили 504 Gateway Timeout. • Код 502 Bad Gateway означает, что сервер, выступающий как шлюз или прокси, получил недействительный (ошибочный) ответ от вышестоящего сервера. Формально ответ есть, но он "битый", странный или просто не соответствует ожиданиям. Почти всегда ошибка "Плохой шлюз" указывает на проблему взаимодействия между компонентами инфраструктуры. • 503 Service Unavailable означает, что сервер временно не может обработать запрос из-за перегрузки или обслуживания. Этот код не описывает как таковой сбой, а фиксирует отказ в обслуживании в текущий момент времени. Ошибку "Сервис временно недоступен" может возвращать как само приложение, так и балансировщик или фронтовый сервер. В отличие от 502, здесь нет проблемы в передаче данных между узлами - система сообщает, что не готова принимать новые запросы. • 504 Gateway Timeout (Таймаут шлюза) - ошибка, сообщающая, что сервер-посредник не получил ответа от вышестоящего сервера в пределах установленного времени ожидания. То есть вместо некорректного ответа в этом случае его просто нет в отведённый таймаут. Типовая архитектура здесь та же, что и у 502: прокси или балансировщик отправляет запрос к бэкенду и ожидает ответ в течение заданного тайм-аута. Если бэкенд отвечает слишком медленно или не отвечает вовсе, посредник завершает ожидание и возвращает клиенту 504. Причиной может быть перегруженное приложение, медленная база данных, внешнее API с высокой латентностью или сетевые задержки. • Так вот, 502, 503 и 504 - самые частые представители семейства 500-х, потому что именно они отражают реальное устройство веба. Сегодня запросы почти не идут напрямую от клиента к приложению, они проходят через длинную цепочку промежуточных узлов, и каждый из них имеет собственные условия отказа. То есть чем сложнее архитектура, тем больше мест, где можно получить эти ошибки, не имея при этом ни одного "упавшего сервера"... #Разное #Оффтоп