запрос обработан что значит
Коды ответов сервера — подробное описание
В статье:
При каждом обращении к серверу вы получаете от него код статуса ответа. Коды связаны с функциональностью страниц сайта и сигнализируют о состоянии страницы. Благодаря значению, которое несет код, сервер корректирует обработку документа после запроса пользователя. Самые популярные коды — 200, который показывает, что запрос выполнен успешно, и 404, показывающий ошибку, если ресурс не найден.
На код ответа сервера обращают внимание поисковые боты и браузеры.
Как проверить код ответа сервера
Посмотреть код ответа на странице можно бесплатно за пару кликов. В браузере информация находится на панели разработчика: в Google Chrome для вызовите панель горячей клавишей F12, откройте вкладку Network и обновите страницу.
Результаты просмотра кода в браузере
Для просмотра кода есть браузерные расширения: HTTP Headers для Google Chrome, HTTP Header для Opera.
Результаты проверки инструментом
Инструмент проверки заголовков сервера от PR-CY определит HTTP статусы сайта и доменного имени.
Результаты проверки инструментом
Значения кодов ответов сервера
Код состоит из трех цифр и начинается с 1-5 в зависимости от группы, к которой принадлежит. После числового обозначения есть приписка на английском, которая поясняет его значение.
Принадлежность кода к группе определяется по первой цифре:
Коды ответов, сигнализирующих об ошибке, содержат информацию об их причинах. Отслеживать ошибки и устранять их можно по лог-файлам сервера — в логах содержится детальная информация о проблемах.
Информационные коды
Коды этой группы информируют о том, что сервер принял запрос и будет его обрабатывать.
100 Continue
Сервер принял запрос и удовлетворен начальными сведениями. Процесс обработки будет продолжен.
101 Switching Protocols
Сервер одобрил переключение типа протокола, которое запросил пользователь. Код используется, когда сервер предлагает перейти на новую версию HTTP. В поле Update будут перечислены доступные протоколы, пользователь может выбрать один из них.
102 Processing
Сервер сигнализирует, что принял запрос, но на обработку требуется больше времени. Клиенту не нужно разрывать соединение, он должен сбросить таймер и дождаться следующей команды.
Коды успешной обработки запроса
Коды группы сигнализируют о том, что запрос принят и успешно обработан.
200 ОК
Это один из самых популярных ответов, он означает, что запрос принят и успешно обработан, страница открыта и доступна к просмотру. Все страницы, которые будут проиндексированы, должны отдавать код 200 ОК.
201 Created
Ответ означает, что сервер принял запрос, обработал и создал новый ресурс. Код можно увидеть, к примеру, если пользователь создал новую страницу. Если новый ресурс создать невозможно, или он перестанет существовать к тому времени, когда клиент получит сообщение, то сервер отдаст код 202 Accepted.
202 Accepted
Сервер принял запрос, но не завершил его обработку. Запрос можно отклонить, поскольку на его выполнение может потребоваться слишком много времени.
203 Non-Authoritative Information
Код ответа 203 означает, что операция прошла успешно, но от кода 200 он отличается указанием источника информации. Данные получены не из первоисточника, а с другого сервера или резервной копии. Возможно, информация устарела, о чем и предупреждает код ответа.
204 No Content
Обработка запроса прошла успешно, но серверу нечего отправить в ответ. Ответ не содержит тело сообщения, только заголовки. Обычно такой код включается в первую пустую строку кода, чтобы разрешить запуск скриптов, не меняя содержимого и не обновляя страницу.
205 Reset Content
Сервер сигнализирует, что запрос успешно обработан и клиенту нужно сбросить введенные данные. Обновление документа не требуется, сервер не передает тело сообщения.
206 Partial Reset
Этот код обычно используют инструменты кэширования. Сервер в ответе возвращает только часть контента страницы, которую и запрашивает пользователь.
207 Multi-Status
Код обозначает мультистатусность ответа: сервер обработал несколько операций,не зависящих друг от друга. Результаты отображаются в теле сообщения как XML-документ с объектом multistatus.
226 IM Used
Сервер успешно завершил операцию: принял заголовок A-IM и вернул содержимое с учетом указанных параметров.
Коды редиректов
Класс кодов показывает, что для успешного выполнения запроса клиенту нужно совершить переход, то есть редирект.
300 Multiple Choices
Робот не может проиндексировать страницу, поскольку не может сопоставить ресурс и URL. Частая причина — ресурс перемещен на другой адрес. Сервер предлагает клиенту выбор альтернатив для перехода. Для успешной индексации нужно либо правильно указать ресурс, либо поправить заголовки.
301 Moved Permanently
Если у проиндексированной страницы изменился адрес, то со старого URL на новый настраивают 301 редирект. Код ответа показывает, что запрашиваемый документ был навсегда перенесен на другой URL, куда пользователя перенаправляет ссылка. Робот проиндексирует страницу, на которую ведет редирект, и склеит исходный адрес и новый.
302 Found
Код означает не постоянное, а временное перемещение страницы на другой адрес, поэтому страницу удалять из индекса не нужно. В ответе указано новое расположение данных.
Страница остается в индексе, ссылочный вес продолжает передаваться.
303 See Other
Сервер сигнализирует, что ресурс, который указан в запросе, расположен на другом адресе. Обычно он используется для перенаправления пользователя к выбранному ресурсу выводом данных POST-активированного скрипта.
В ответе сервера будет указан адрес, по которому нужно искать результат, удовлетворяющий запрос.
304 Not Modified
Код рекомендуется выдавать, если страница не менялась с момента ее последнего посещения роботом. Сервер дает сигнал об этом боту, бот получает от документа http-заголовки, не загружая страницу повторно, из-за чего индексирование проходит быстрее и уменьшается нагрузка на сервер.
305 Use Proxy
Код ответа связан с безопасностью данных. Сервер выдает код 305, если доступ к ресурсу, который запрашивает клиент, возможен только с прокси. Прокси указан там же в ответе сервера.
307 Temporary Redirect
Код 307 похож на 302, но дает более конкретный ответ. Код означает, что ресурс, который требует клиент, на время переведен на другой адрес, а новый URL нужно прописать в Location.
Коды ошибок клиента
Коды ответов этой группы означают ошибки по вине клиента или невозможность выдать результат, потому что на странице нет данных.
400 Bad Request
Запрос некорректен, где-то в нем есть синтаксическая ошибка, поэтому сервер не может выдать результат. Для успешного выполнения запроса нужно исправить синтаксис, обычно помогает очистка куки или кэша страниц, исправление запроса пользователем.
401 Unauthorized
Информация доступна только зарегистрированным пользователям или запаролена. Если пользователь не авторизовался, доступ к странице невозможен.
403 Forbidden
Если пользователю www-data, под которым запущен сервер, закрыт доступ к чтению файла, поможет команда sudo chmod o=r /usr/share/nginx/html/index.html
Еще одна причина — пользователь обратился к закрытому каталогу, в котором нет индексного файла. Разрешение на просмотр каталога включается в настройках сервера.
404 Not Found
Серверу не удалось найти ресурс, который запрашивает пользователь, документа по этому адресу не существует.
Это частая ошибка, она может быть связана с тем, что пользователь ошибся в адресе страницы, у пользователя нет прав на чтение и исполнение файла, файл на сервере переместили иди удалили, корневой каталог указали с ошибкой или сервер не настроен для работы с символьными «мягкими» ссылками, которые использованы для обработки.
Код ответа 404 Not Found
Ссылки на удаленные разделы сайта будут возвращать код 404. На такие документы не нужно тратить краулинговый бюджет, поэтому в файле robots.txt запрещают роботу посещение и индексацию таких страниц.
405 Method Not Allowed
Недоступен метод, которым совершается запрос. Сервер выдает этот код для конкретных отдельных объектов на странице. К примеру, строка запроса, запускающая скрипт, отличается от запроса, который совершает пользователь.
406 Not Acceptable
Код ответа означает, что запрашиваемый файл существует, запрос сформулирован верно, но кодировка документа недоступна для расшифровки роботом.
407 Proxy Authentication Required
Этот код похож на 401 и 407, он используется, если вопрос корректен, но клиент может получить доступ к документу только с помощью авторизации через прокси. Клиент авторизуется, если прокси вернет поле с заголовком proxy-authenticate.
408 Request Timeout
Сервер возвращает этот код ответа, если в установленное время ожидания клиент не сделал ни один запрос. Код 408 не возвращается, если пользователь сам отменил запрос, или соединение оборвалось, а отправить ответ нет возможности.
409 Conflict
Код означает, что в системе конфликт: к примеру, пользователь загружает файл на сервер, где уже есть такой файл в новой версии.
410 Gone
Код ответа похож на 404 код, он означает, что документ, к которому направлен запрос, больше недоступен. Если сервер возвращает код 404, то робот еще вернется на страницу, чтобы проверить ее состояние, а в случае ответа 410 робот поймет, что страница удалена навсегда.
411 Length Required
Сервер не может принять и обработать запрос, если в заголовке content-length не указана длина контента.
413 Request Entity Too Large
Если в теле запроса слишком большой объем информации и сервер не может обработать такой большой запрос, то он возвращает код ошибки 413. Если это временная проблема, в поле Retry-After сервер укажет время, которое нужно подождать.
414 Request-URL Too Long
Аналогично с кодом 413, за исключением того, что 414 код отображается, если в запросе указан слишком длинный URL.
422 Unprocessable Entity
Сервер возвращает этот код, если он принял и распознал запрос, но в теле запроса допущена логическая ошибка, которая мешает его выполнить.
424 Failed Dependency
Если выполнение этой операции зависит от исхода других связанных с ней операций, сервер вернет этот запрос.
429 Too Many Requests
Код 429 означает, что пользователь посылает слишком много запросов за короткий временной промежуток, и сервер не может обработать такое количество.
431 Request Header Fields Too Large
Если в запросе указаны слишком большие поля заголовков, сервер не сможет справиться с таким запросом и вернет код ошибки 431.
451 Unavailable For Legal Reasons
Код отображает то же, что и 403, но с уточнениями. Он используется, если доступ к серверу заблокирован по решению суда, обычно из-за нарушения авторских прав, а также если доступ закрыт на государственном уровне.
418 I’m a teapot
Это забавный код, возвращающий ошибку «Я чайник», связан с гипертекстовым протоколом управления кофеваркой — Hyper Text Coffee Pot Control Protocol. Ошибка означает, что запрос некорректен, с помощью чайника нельзя приготовить кофе. Протокол и код этой ошибки были созданы в шутку в 1998 году к 1 апреля.
Код 418 I’m a teapot
Коды ошибок сервера
Коды этой группы обозначают ошибки на стороне сервера.
500 Internal Server Error
501 Not Implemented
Сервер возвращает этот код, когда не может обработать запрос: он не поддерживает возможности для обработки или не может распознать метод. К примеру, эта ошибка появится, если распространенные протоколы HEAD, POST, GET и другие по какой-то причине не поддерживаются сервером.
502 Bad Gateway
За обработку запроса отвечают бэкенд серверы, которые передают данные прокси-серверу или шлюзу. Если запрос был направлен к такому шлюзу, который не получил ответ от бэкенда, сервер вернет 502 код. Для исправления нужно проверить настройку прокси-сервера.
503 Service Unavailable
Код свидетельствует о перегрузке сервера, запрос не может быть выполнен в данный момент. Второй причиной может быть обслуживание сервера: ему не хватает памяти или ресурсов, чтобы обработать запрос. Такой ответ может вернуться, если на сервере ограничено количество пользователей.
504 Gateway Timeout
Код похож на 502, но ошибка 504 означает, что истек срок ожидания ответа от сервера. Необходимое количество времени истекло, а ответ от бэкенд-сервера не пришел.
Причина может быть в сетевом соединении, недостатке ресурсов, версии протокола HTTP или настройке сервера, если выставлен слишком короткий таймаут.
506 Variant Also Negotiates
Код ответа 506 означает, что сервер настроен некорректно: ошибка в конфигурации зацикливает обращение сервера, и он указывает сам на себя.
507 Insufficient Storage
Если сервер загружен настолько, что для выполнения запроса не хватает памяти, он вернет ошибку 507. Это бывает, если на сервере нет места для данных в принимаемом запросе.
510 Not Extended
Код 510 возвращается в случае, если сервер не поддерживает расширение, которое указано в запросе. В этом же ответе сервер может указать, какие расширения доступны.
511 Network Authentication Required
Эта ошибка возвращается клиенту, если пользователь не авторизовался в сети. К примеру, если он не согласился на условия использования интернета, когда подключался к wi-fi, или не ввел пароль.
На коды ответов сервера обращают внимание поисковые роботы, с помощью этих сигналов они узнают, как им нужно вести себя со страницей — индексировать, пропустить, вернуться к ней позже. Веб-мастерам важно распознавать сигналы с ошибками, чтобы направлять поисковых ботов и исправлять часть ошибок, если причина ошибки им доступна.
Все, что вы хотели знать об обработке запросов, но стеснялись спросить
Что такое сетевой сервис? Это программа, которая принимает входящие запросы по сети и обрабатывает их, возможно, возвращая ответы.
Есть много аспектов, в которых сетевые сервисы отличаются друг от друга. В этой статье я акцентрирую внимание на способе обработки входящих запросов.
Выбор способа обработки запросов имеет далеко идущие последствия. Как сделать чат-сервис, выдерживающий 100.000 одновременных соединений? Какой подход выбрать для извлечения данных из потока слабоструктурированных файлов? Неправильный выбор приведет к пустой трате сил и времени.
В статье рассмотрены такие подходы как пул процессов/потоков, событийно-ориентированная обработка, half sync/half async паттерн и многие другие. Приводятся многочисленные примеры, рассматриваются плюсы и минусы подходов, их особенности и области применения.
Введение
Тема способов обработки запросов не нова, смотрите, например: один, два. Однако большинство статей рассматривают её лишь частично. Данная статья призвана заполнить пробелы и привести последовательное изложение вопроса.
Будут рассмотрены следующие подходы:
Нужно обратить внимание, что сервис, обрабатывающий запросы — это не обязательно сетевой сервис. Это может быть сервис, который получает новые задачи из БД или очереди задач. В данной статье подразумеваются именно сетевые сервисы, но нужно понимать, что рассматриваемые подходы имеют более широкую область применения.
В конце статьи приводится список с кратким описанием каждого из подходов.
Последовательная обработка
Приложение состоит из единственного потока в единственном процессе. Все запросы обрабатываются только последовательно. Параллелизма нет. Если к сервису приходит одновременно несколько запросов, один из них обрабатывается, остальные попадают в очередь.
Плюс данного подхода в простоте реализации. Нет никаких блокировок и конкуренции за ресурсы. Очевидный минус — невозможность масштабироваться при большом количестве клиентов.
Процесс на запрос
Приложение состоит из основного процесса, который принимает входящие запросы, и рабочих процессов. На каждый новый запрос основной процесс создает рабочий процесс, который обрабатывает запрос. Масштабирование по количеству запросов простое: каждый запрос получает свой собственный процесс.
В этой архитектуре тоже нет ничего сложного, но у неё есть проблемы ограничения:
Эти проблемы отнюдь не являются стоповыми. Ниже будет показано, как они обходятся в РСУБД PostgeSQL.
Плюсы этой архитектуры:
Примеры:
В целом нужно сказать, что этот подход имеет свои преимущества, которые обуславливают его область применения, но возможности масштабирования сильно ограничены.
Поток на запрос
Этот подход во многом похож на предыдущий. Отличие в том, что вместо процессов используются потоки. Это позволяет использовать общую память «из коробки». Однако другие плюсы предыдущего подхода использовать уже не получится, в то время как потребление ресурсов так же будет высоким.
Плюсы:
Минусы:
В качестве примера использования можно привести MySQL. Но нужно заметить, что в MySQL используется смешанный подход, поэтому этот пример будет рассмотрен в следующем разделе.
Пул процессов/потоков
Потоки (процессы) создавать дорого и долго. Чтобы не тратить ресурсы впустую, можно использовать один и тот же поток многократно. Ограничив дополнительно максимальное количество потоков, получим пул потоков (процессов). Теперь основной поток принимает входящие запросы и складывает их в очередь. Рабочие процессы берут запросы из очереди и обрабатывают. Этот подход можно воспринимать как естественное масштабирование последовательной обработки запросов: каждый рабочий поток может обрабатывать потоки только последовательно, объединение их в пул позволяет обрабатывать запросы параллельно. Если каждый поток может обрабатывать 1000 rps, то 5 потоков будут обрабатывать нагрузку близкую к 5000 rps (при условии минимальной конкуренции за общие ресурсы).
Пул может быть создан заранее при старте сервиса или формироваться постепенно. Использование пула потоков более распространено, т.к. позволяет применять общую память.
Размер пула потоков не обязательно должен быть ограничен. Сервис может использовать свободные потоки из пула, а если таких нет — создавать новый поток. После завершения обработки запроса поток присоединяется к пулу и ожидает следующего запроса. Данный вариант — комбинация подхода поток на запрос и пул потоков. Ниже будет приведен пример.
Плюсы:
Минусы:
Примеры:
Пожалуй, это один из наиболее распространенных подходов к построению сетевых сервисов, если не самый распространенный. Он позволяет хорошо масштабироваться, достигая больших rps. Основное ограничение подхода — количество одновременно обрабатываемых сетевых соединений. Фактически этот подход работает хорошо, только если запросы короткие или клиентов мало.
Событийно-ориентированная обработка (reactor паттерн)
Две парадигмы — синхронная и асинхронаая — вечные конкуренты друг друга. До сих пор речь шла только о синхронных подходах, но было бы неправильно игнорировать асинхронный подход. Событийно ориентированная или реактивная обработка запросов — это подход, в котором каждая IO операция выполняется ассинхронно, а по окончании выполнения операции вызывается обработчик (handler). Как правило, обработка каждого запроса состоит из множества асинхронных вызовов с последующим выполнением handler’ов. В каждый конкретный момент однопоточное приложение выполняет код только одного handler’а, но выполнение handler’ов различных запросов чередуется между собой, что позволяет одновременно (псевдопараллельно) обрабатывать множество параллельных запросов.
Полное рассмотрение этого подхода выходит за рамки этой статьи. Для более глубокого ознакомления можно порекомендовать Reactor (Реактор), В чем секрет скорости NodeJS?, Inside NGINX. Здесь ограничимся только рассмотрением плюсов и минусов данного подхода.
Плюсы:
Минусы:
Примеры:
Half sync/half async
Название взято из книги POSA: Patterns for Concurrent and Networked Objects. В оригинале этот паттерн трактуется очень широко, однако для целей данной статьи я буду понимать этот паттерн несколько уже. Half sync/half async — это подход к обработке запросов, в котором для каждого запроса используется легковесный поток управления (зеленый поток). Программа состоит из одного или нескольких потоков уровня операционной системы, однако система исполнения программы поддерживает зеленые потоки, которые ОС не видит и которыми не может управлять.
Несколько примеров, чтобы сделать рассмотрение конкретнее:
В сущности этот подход призван совместить высокую производительность асинхронного подхода с простотой программирования синхронного кода.
При использовании этого подхода, несмотря на иллюзию синхронности, программа будет работать асинхронно: система исполнения программы будет управлять event loop’ом, а каждая «синхронная» операция на самом деле будет асинхронной. При вызове такой операции система исполнения будет вызывать асинхронную операцию с помощью средств ОС и регистрировать handler завершения выполнения операции. Когда асинхронная операция будет завершена, система исполнения вызовет ранее зарегестрированный handler, который продолжит выполнение программы в точке вызова «синхронной» операции.
В результате подход half sync/half async содержит в себе как некоторые плюсы, так и некоторые минусы асинхронного подхода. Объем статьи не позволяет рассмотреть этот подход во всех деталях. Интересующимся советую прочесть одноименную главу в книге POSA: Patterns for Concurrent and Networked Objects.
Сам по себе подход half sync/half async вводит новую сущность «зеленый поток» — легковесный поток управления на уровне системы исполнения программы или библиотеки. Что делать с зелеными потоками — выбор программиста. Он может использовать пул зеленых потоков, может создавать новый зеленый поток на каждый новый запрос. Разница по сравнению с потоками/процессам ОС в том, что зеленые потоки намного дешевле: они расходуют гораздо меньше оперативной памяти и создаются намного быстрее. Это позволяет создавать огромное количество зеленых потоков, например, сотни тысяч в языке Go. Такое огромное количество делает оправданным использование подхода «зеленый поток на запрос».
Плюсы:
Минусы:
В зависимости от реализации этот подход хорошо масштабируется по ядрам CPU (Golang) или не масштабируется вовсе (Python).
Этот подход так же, как и асинхронный, позволяет обрабатывать большое количество одновременных соединений. Но программировать сервис с использованием этого подхода проще, т.к. код пишется в синхронном стиле.
Конвейерная обработка
Как можно догадаться из названия, в этом подходе запросы обрабатываются по конвейеру. Обрабатывающий процесс состоит из нескольких потоков ОС, выстроенных в цепочку. Каждый поток — это звено цепочки, он выполняет определенное подмножество операций, необходимых для обработки запроса. Каждый запрос последовательно проходит через все звенья цепочки, а разные звенья в каждый момент времени обрабатывают разные запросы.
Плюсы:
Минусы:
Примеры:
Конвейерная обработка широко используется, однако чаще всего звеньями являются отдельные компоненты в независимых процессах, которые обмениваются сообщениями, например, через очередь сообщений или БД.
Резюме
Краткая сводка рассмотренных подходов:
Список выше не является исчерпывающим, но он содержит основные подходы к обработке запросов.
Обращаюсь к читателю: какие подходы используете Вы? Какие плюсы и минусы, особенности их работы Вы узнали на собственном опыте?