История изменений
Исправление
gh0stwizard,
(текущая версия)
:
Очень смешно. Сервер выдержит и 100к, имхо, т.к. написан на libev. Другое дело, что это embed сервер, который предполагается запускать совместно с nginx в виде frontend.
Я все это затеял потому, что соедениния nginx <-> httpd всегда лежат в дауне с TIME_WAIT. Хотя по логике, должно висеть постоянно скажем всего 10 соединений. Вот этого я и хочу добиться.
Вобщем, ща я выспался и внимательно читаю RFC 7230. Вот выдержки, из которых видно, что аналитики на ЛОРе прежние:
6.1. Connection
When defining new connection options, specification authors ought to
survey existing header field names and ensure that the new connection
option does not share the same name as an already deployed header
field. Defining a new connection option essentially reserves that
potential field-name for carrying additional information related to
the connection option, since it would be unwise for senders to use
that field-name for anything else.
The "close" connection option is defined for a sender to signal that
this connection will be closed after completion of the response. For
example,
Connection: close
in either the request or the response header fields indicates that
the sender is going to close the connection after the current
request/response is complete (Section 6.6).
A client that does not support persistent connections MUST send the
"close" connection option in every request message.
A server that does not support persistent connections MUST send the
"close" connection option in every response message that does not
have a 1xx (Informational) status code.
Т.о. HTTP/1.1 предполагает наличие постоянных соединений. Я это все прочитаю, засумирую и сделаю. Протестирую. Не волнуйтесь :)
6.3. Persistence
HTTP/1.1 defaults to the use of "persistent connections", allowing
multiple requests and responses to be carried over a single
connection. The "close" connection option is used to signal that a
connection will not persist after the current request/response. HTTP
implementations SHOULD support persistent connections.
Исправление
gh0stwizard,
:
Очень смешно. Сервер выдержит и 100к, имхо, т.к. написан на libev. Другое дело, что это embed сервер, который предполагается запускать совместно с nginx в виде frontend.
Я все это затеял потому, что соедениния nginx <-> httpd всегда лежат в дауне с TIME_WAIT. Хотя по логике, должно висеть постоянно скажем всего 10 соединений. Вот этого я и хочу добиться.
Вобщем, ща я выспался и внимательно читаю RFC 7230. Вот выдержки, из которых видно, что аналитики на ЛОРе прежние:
6.1. Connection
When defining new connection options, specification authors ought to
survey existing header field names and ensure that the new connection
option does not share the same name as an already deployed header
field. Defining a new connection option essentially reserves that
potential field-name for carrying additional information related to
the connection option, since it would be unwise for senders to use
that field-name for anything else.
The "close" connection option is defined for a sender to signal that
this connection will be closed after completion of the response. For
example,
Connection: close
in either the request or the response header fields indicates that
the sender is going to close the connection after the current
request/response is complete (Section 6.6).
A client that does not support persistent connections MUST send the
"close" connection option in every request message.
A server that does not support persistent connections MUST send the
"close" connection option in every response message that does not
have a 1xx (Informational) status code.
Т.о. HTTP/1.1 предполагает наличие постоянных соединений. Я это все прочитаю, засумирую и сделаю. Протестирую. Не волнуйтесь :)
Исходная версия
gh0stwizard,
:
Очень смешно. Сервер выдержит и 10к, имхо, т.к. написан на libev. Другое дело, что это embed сервер, который предполагается запускать совместно с nginx в виде frontend.
Я все это затеял потому, что соедениния nginx <-> httpd всегда лежат в дауне с TIME_WAIT. Хотя по логике, должно висеть постоянно скажем всего 10 соединений. Вот этого я и хочу добиться.
Вобщем, ща я выспался и внимательно читаю RFC 7230. Вот выдержки, из которых видно, что аналитики на ЛОРе прежние:
6.1. Connection
When defining new connection options, specification authors ought to
survey existing header field names and ensure that the new connection
option does not share the same name as an already deployed header
field. Defining a new connection option essentially reserves that
potential field-name for carrying additional information related to
the connection option, since it would be unwise for senders to use
that field-name for anything else.
The "close" connection option is defined for a sender to signal that
this connection will be closed after completion of the response. For
example,
Connection: close
in either the request or the response header fields indicates that
the sender is going to close the connection after the current
request/response is complete (Section 6.6).
A client that does not support persistent connections MUST send the
"close" connection option in every request message.
A server that does not support persistent connections MUST send the
"close" connection option in every response message that does not
have a 1xx (Informational) status code.
Т.о. HTTP/1.1 предполагает наличие постоянных соединений. Я это все прочитаю, засумирую и сделаю. Протестирую. Не волнуйтесь :)