Простой шлюз общего назначения (SCGI): протокол взаимодействия веб-сервера и приложения.
Simple Common Gateway Interface
SCGI: протокол для веб-приложений, альтернатива CGI. Упрощенный парсинг, постоянные соединения, высокая скорость и масштабируемость. Оптимизация работы сервера!
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Simple Common Gateway Interface (SCGI) — это протокол для взаимодействия приложений с HTTP-серверами, являющийся альтернативой протоколу CGI. Он аналогичен FastCGI, но разработан с учетом упрощения разбора. В отличие от CGI, SCGI позволяет длительно работающему процессу обслуживания продолжать обработку запросов, избегая задержек в ответах, вызванных накладными расходами на настройку (например, подключением к базе данных). SCGI — это протокол, определяющий связь между веб-сервером и сервером приложений. Это отличается от CGI, который представляет собой более ранний интерфейс приложения (шлюз), предназначенный для того, чтобы программист приложения мог избежать сложности работы с сокетами и длительно работающими процессами обслуживания, когда допустимы низкая масштабируемость и высокие накладные расходы. Протокол SCGI использует тот факт, что веб-сервер уже выполнил разбор и проверку HTTP-запроса и передает запрос серверу SCGI в каноническом виде, избавляя программиста приложения от необходимости разбирать неоднозначности и граничные случаи протокола. Это позволяет избежать сложных правил разбора и объединения заголовков, определенных в RFC 2616, что значительно упрощает процесс работы сервера SCGI.
The Simple Common Gateway Interface (SCGI) is a protocol for applications to interface with HTTP servers, as an alternative to the CGI protocol. It is similar to FastCGI but is designed to be easier to parse. Unlike CGI, it permits a long running service process to continue serving requests, thus avoiding delays in responding to requests due to setup overhead (such as connecting to a database). SCGI is a protocol which defines communication between a web server and an application server. This is in contrast to CGI, which is an earlier application (gateway) interface designed to let the application programmer avoid the complexity of sockets and long running service processes when poor scalability and high overhead are acceptable. The SCGI protocol leverages the fact that the web server has already parsed and validated the HTTP request, and canonically communicates the request to the SCGI server while letting the application programmer avoid parsing ambiguities and protocol edge cases. This avoids the complicated header parsing and header combining rules from RFC 2616, saving significant complexity in the SCGI server process.
История
Нил Шемэнауэр опубликовал оригинальную спецификацию протокола SCGI, датированную октябрем 2001 года. Он разработал первые реализации SCGI и впервые опубликовал их в апреле 2002 года.
Neil Schemenauer published the original SCGI protocol specification dated October 2001. He developed the first implementations of SCGI and initially published them in April 2002.
Спецификация
Клиент подключается к SCGI-серверу по надёжному протоколу потока, обеспечивающему передачу 8-битных байтов. Клиент начинает с отправки запроса. Когда SCGI-сервер определяет конец запроса, он отправляет ответ и закрывает соединение. Формат ответа протоколом не определён, однако обычно используются ответы HTTP, эквивалентные CGI.
The client connects to a SCGI server over a reliable stream protocol allowing transmission of 8 bit bytes. The client begins by sending a request. When the SCGI server sees the end of the request it sends back a response and closes the connection. The format of the response is not specifically specified by this protocol, although CGI equivalent HTTP responses are generally used.
Формат запроса
Запрос SCGI представляет собой конкатенацию заголовков, закодированных в формате netstring, и тела. Ответ SCGI — это обычный HTTP-ответ. Каждый заголовок состоит из пары имя-значение, где и имя, и значение являются null-терминированными строками (C-строками). Значение может быть пустой строкой, в этом случае завершающий null-символ всё равно остаётся. Ни имя, ни значение не могут содержать встроенные null-байты. Эти требования стандартны для C-строк, но часто вызывают путаницу у программистов, привыкших к другим стандартам обработки строк. Все предоставленные заголовки объединяются в единую последовательность байтов, а затем кодируются в формате netstring. Далее, при наличии, добавляется необработанное тело. Дублирующие имена в заголовках запроса недопустимы; объединение заголовков, соответствующее RFC 2616, должно быть выполнено заранее. Первый заголовок запроса должен иметь имя "CONTENT LENGTH" и значение, равное длине тела запроса в десятичном формате. Заголовок запроса "CONTENT LENGTH" всегда должен присутствовать, даже если его значение равно "0". Также всегда должен присутствовать заголовок запроса с именем "SCGI" и значением "1". Для обеспечения совместимости при преобразовании старых CGI-программ в SCGI, стандартные переменные окружения CGI должны быть предоставлены в заголовках SCGI. Тело запроса (если оно есть) следует за заголовками; его длина указывается в заголовке запроса "CONTENT LENGTH". Хотя протокол SCGI изолирует разработчика сервиса от некоторых аспектов HTTP, различные детали (например, интерпретация октетов тела сообщения в соответствии с заголовком Transfer Encoding, а также то, что CONTENT LENGTH представляет собой количество октетов после кодирования тела для передачи и т.д.) всё ещё требуют знания спецификации протокола HTTP.
A SCGI request is the concatenation of netstring encoded headers and a body. A SCGI response is a normal HTTP response. Each header consists of a name–value pair, where both the name and the value are null terminated strings (C strings). The value can be an empty string, in which case the terminating null still remains. Neither name nor value can contain any embedded null bytes. These considerations are standard for C strings, but are often confusing for programmers used to other standards for string handling. All provided headers are concatenated to form a single byte sequence, then netstring encoded. The raw body, if any, is then appended. Duplicate names are not allowed in the request headers; RFC 2616 compliant header combining must already have taken place. The first request header must have the name "CONTENT LENGTH" and a value that is the length of the body in decimal. The "CONTENT LENGTH" request header must always be present, even if its value is "0". There must also always be a request header with the name "SCGI" and a value of "1". Standard CGI environment variables should be provided in SCGI headers for compatibility when converting older CGI programs to SCGI. The body (if any) provided in the request follows the headers; its length is specified by the "CONTENT LENGTH" request header. While the SCGI protocol insulates the service programmer from some HTTP considerations, various details (such as interpreting the octets of the message body as per the Transfer Encoding header, the CONTENT LENGTH being the number of octets after the body has been encoded for transmission, etc.) still require knowledge of the HTTP protocol specification.