Постоянные соединения в HTTP для чайника (server-side)

А вебсокеты не подходят для твоей задачи?

Сервак, что я допиливаю и есть httpd, который сейчас умеет только http 1.0, 1.1 в режиме Connection: close. А нужно, чтобы он умел все.

Сейчас он не сможет веб-сокеты делать, потому что сервер закрывает все соединения. Я может чего ещё не понимаю, но без постоянных соединений выйдет ерунда.

Может кто поделиться информацией как со стороны сервера должны организовываться постоянные соединения по HTTP/1.0, HTTP/1.1

Никак.

Нужны постоянные соединения для приложения - используй что-нибудь кроме http, а http должен работать так: открыл-передал запрос-получил ответ-закрыл.

И нефиг вешать на протокол нетипичные задачи

Хорошо, тогда, что делает Keep-alive в HTTP/1.1. Какое поведение соединения между клиентом и сервером? Тоже самое открыл-передал запрос-получил ответ-закрыл? Тогда зачем это придумали, если соединения постоянно закрываются?

И главный вопрос: кто посылает эти самые keep-alive пакеты? Сервер или клиент? И в каком они виде обычно? Ну, либо спец. сформированный TCP пакет, который надо как-то парсить (тут бы не помешал линк на RFC) или как обычно: GET request с какими-то параметрами (тоже неплохо RFC на это).

keep-alive-пакеты в данном случае (в ситуации с HTTP/1.1) — ни кто не посылает.

HTTP/1.1 — не использует keep-alive уровня TCP-протокола. в HTTP/1.1 просто таймаут минут 5 (важно что не бесконечный), между запросами.

5 секунд. Должен ли я увеличить этот таймаут?

протестируй как будет вести себя этот сервер в момент подключения например 40000 клиентов.

если выдержит нормально (т е — не займёт тучу памяти и не зависнит) — значит можешь увеличить :-)

Очень смешно. Сервер выдержит и 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.

Т.о. HTTP/1.1 предполагает наличие постоянных соединений. Я это все прочитаю, засумирую и сделаю. Протестирую. Не волнуйтесь :)

хорошо! в целом это полезное дело (и не будет идти в разрез с сущестющими реализациями клиентов HTTP/1.1).

но только умоляю, если будешь реализовывать *честный* keep-alive (а не долгий timeout, напоминающий внешне keep-alive) — то пожалуйста выставь соответствующую опцию а сокете:

   int optval;
   socklen_t optlen = sizeof(optval);

   // ...

   optval = 1;
   optlen = sizeof(optval);
   if(setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, &optval, optlen) < 0) {
      perror("setsockopt()");
      close(s);
      exit(EXIT_FAILURE);
   }

(копировал из этого примера — http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/programming.html )

иначе я буду очень волноваться.. (у меня последнее время одни только нервные расстройства на почве этих-всяких keep-alive :-).. хренова туча народу уже наделала утечки ресурсов (из-за неправильных реализаций), а я только и давай им всем отписывать багрепорты — прям кошмар последнего столетия)

# P.S.: так как речь идёт об «nginx <-> httpd» — утечек ресурсов НЕ будет даже при неправильной-реализации, если обе программы запущены на одной компьютере.

Я все это затеял потому, что соедениния nginx <-> httpd всегда лежат в дауне с TIME_WAIT. Хотя по логике, должно висеть постоянно скажем всего 10 соединений. Вот этого я и хочу добиться.

http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

Вот в том-то и дело, что nginx может и умеет keepalive-соединения, а сервер httpd не умеет и кидает всегда Connection: close после любого ответа, далее тупо закрывает соединение. Исходя из RFC 7230 неясно как должны реализовываться постоянные соединения (с/без SO_KEEPALIVE, сколько они могут висеть и т.п.), тупо описано, что сервер может:

а) не закрывать соединения ( фиг знает сколкьо времени)

б) работает по принципу LRU при чтении заголовков Connection:

в) может закрыть соединение в любой момент

г) может или не может поддерживать pipeline запросы в рамках одного соединения. Если может, то должен отвечать на них ровно в той последовательности в какой пришли запросы (safe methods: GET, HEAD, OPTIONS, TRACE).

а сервер httpd не умеет и кидает всегда Connection: close после любого ответа

Дай угадаю, ты хочешь магию, которая без изменения кода httpd позволит в keepalive? У меня для тебя плохие новости.

Дай угадаю, ты хочешь магию, которая без изменения кода httpd позволит в keepalive?

Нет, не хочу. Я как раз и меняю код сервера, чтобы сделать то, что нереализовал автор. Проект почти заброшен, но потенциал огромен.

Мне нужно лишь узнать, что нужно сделать еще кроме того, что не закрывать соединения (это делается правкой 1 строчки). Сейчас, как я уже говорил, соединение после ответа висит 5 секунд, дальше прибивается по таймеру. Этот момент отчасти ясен, типа сохраняем ресурсы. Другой вопрос насколько это используется на практике. Соединение может висеть и минуту (как у nginx зашито, вроде 55 или 45 секунд для обычного клиента или я спутал с read timeout: подключаемся а дальше максимум 45 секунд мы может скармливать nginx запрос, типа very slow requests attack).

Мне нужно лишь узнать, что нужно сделать еще кроме того, что не закрывать соединения (это делается правкой 1 строчки).

Не отсылать «Connection: close» и не закрывать соединение.

Другой вопрос насколько это используется на практике.

Что значит на практике? keepalive до апстримов вполне себе распространенное явление.

А SO_KEEPАLIVE надо ставить на сокет? Сейчас не проставляется.

Далее, сколько должно это висеть соединение? Типа сколько я решу (что соответствует RFC)?

6.5. Failures and Timeouts

Servers will usually have some timeout value beyond which they will
no longer maintain an inactive connection.  Proxy servers might make
this a higher value since it is likely that the client will be making
more connections through the same proxy server.  The use of
persistent connections places no requirements on the length (or
existence) of this timeout for either the client or the server.

A client or server that wishes to time out SHOULD issue a graceful
close on the connection.  Implementations SHOULD constantly monitor
open connections for a received closure signal and respond to it as
appropriate, since prompt closure of both sides of a connection
enables allocated system resources to be reclaimed.

А SO_KEEPLIVE надо ставить на сокет?

Зачем?

Не знаю :) Поэтому и спрашиваю, т.к. пока что нифига не ясно, что должно происходить «под капотом». А на практике, браузеростроители, серверостроители уже все прояснили «для себя» и пихают SO_KEEPALIVE, а потом мой сервак валиться с ошибками, т.к. он не знает, что так принято.

Далее, сколько должно это висеть соединение?

Недолго. Для апстрима это несколько секунд.

Не знаю

Дык, прочитай.

Что и где прочитать? В RFC 7230 все расплывчато: может висеть, может закрываться. Про SO_KEEPALIVE ни слова. Я уже планирую читать исходники nginx, lighthttpd. Просто хотел узнать это без всей этой рутины.

у меня последнее время одни только нервные расстройства на почве этих-всяких keep-alive

А можно названия проектов и/или ссылки на них? Я бы посмотрел как у них сделано, чисто ради интереса.

Про SO_KEEPALIVE ни слова.

Ты будешь удивлен, но http это просто текстовый протокол. Найди место в rfc, где говорится, что соединение — это tcp connection xD

В RFC 7230 все расплывчато: может висеть, может закрываться.

Да, потому что и клиент, и сервер написаны жопорукими макаками, и сам транспорт не предполагает надежности. Если отбросить эти детали, то реализация keepalive проста до безобразия.

А можно названия проектов и/или ссылки на них? Я бы посмотрел как у них сделано, чисто ради интереса.

помню я патчил (давно) https://github.com/KeepSafe/aiohttp , на тему этих keep-alive ..

вот кстати совсем недавний коммит — https://github.com/KeepSafe/aiohttp/commit/da972ad3c34d544fcb36065f60827700f6... (этот коммит не мой.. я просто мимо проходил мимо).

ну а по поводу других проектов — там не http-сервера. например я попросил python-разработчиков кой что улучшить в XMLRPC-python-реализации (думаю это слабо можно связать с HTTP). но будет ясно к ближе версии Python-3.5

Это все понятно. Вот смотря по этому https://github.com/KeepSafe/aiohttp/blob/master/aiohttp/server.py видно, что ребята проставляют SO_KEEPALIVE, ну кроме упоминания nginx откуда они взяли, что так следует делать?

ну кроме упоминания nginx откуда они взяли, что так следует делать?

А откуда ты взял, что он нужен? Вот оттуда же они и взяли.

Скажи пожалуйста, где ты вычитал про SO_KEEPALIVE и почему запатчили aiohttp?

почему запатчили aiohttp?

если бы его не запатчили — то зловредный HTTP-клиент мог бы наоткрывать кучу keep-alive соединений, а потому бы оставил бы эти соединения незакрытыми.

сервер бы ни когда бы в жизни не «догадался» бы о том что соединения уже не актуальны и так и держал бы эти TCP-сокеты открытыми. (утечка ресурсов).

(но так как ты голой Ж не сидишь в интернете без nginx — то врядли кто будет специально делать тебе подлянку с «утечкой ресурсов»... в твоём случае «утечка ресурсов» может произойти наверное только случайно например если «nginx» и «httpd» будут на разных компах и вдруг компьютер с «nginx» резко вырубится и перезагрузится, в определённый момент состояния TCP-сессий )

где ты вычитал про SO_KEEPALIVE

трудно сказать где я первый раз вичитал про SO_KEEPALIVE — первый раз :) . эта сокетная опция слишком старая, и я тоже слишком старый.

Скажи пожалуйста, где ты вычитал про SO_KEEPALIVE

http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/

и почему запатчили aiohttp?

На всякий случай. Просто у авторов яйца не слишком блестели.

то зловредный HTTP-клиент мог бы наоткрывать кучу keep-alive соединений, а потому бы оставил бы эти соединения незакрытыми.

Они keepalive_timeout отдельно хендлят. SO_KEEPALIVE вообще там не приделах.

~/tmp/src/nginx-1.7.9 ack-grep SO_KEEPALIVE .
src/mail/ngx_mail_proxy_module.c
127:        if (setsockopt(s->connection->fd, SOL_SOCKET, SO_KEEPALIVE,
132:                          "setsockopt(SO_KEEPALIVE) failed");

src/core/ngx_connection.c
540:            if (setsockopt(ls[i].fd, SOL_SOCKET, SO_KEEPALIVE,
545:                              "setsockopt(SO_KEEPALIVE, %d) %V failed, ignored",

void
ngx_configure_listening_sockets(ngx_cycle_t *cycle)
{
...
        if (ls[i].keepalive) {
            value = (ls[i].keepalive == 1) ? 1 : 0;

            if (setsockopt(ls[i].fd, SOL_SOCKET, SO_KEEPALIVE,
                           (const void *) &value, sizeof(int))
                == -1)
            {
                ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_socket_errno,
                              "setsockopt(SO_KEEPALIVE, %d) %V failed, ignored",
                              value, &ls[i].addr_text);
            }
        }
...

/* далее еще большие навороты */
#if (NGX_HAVE_KEEPALIVE_TUNABLE)

        if (ls[i].keepidle) {
            value = ls[i].keepidle;

#if (NGX_KEEPALIVE_FACTOR)
            value *= NGX_KEEPALIVE_FACTOR;
#endif

            if (setsockopt(ls[i].fd, IPPROTO_TCP, TCP_KEEPIDLE,
                           (const void *) &value, sizeof(int))
                == -1)
            {
...

Откуда они это взяли? Это уже риторический вопрос, если кто знает — отпишитесь.

На всякий случай.

На какой случай? Знаю по личному опыту, что выставлять SO_KEEPALIVE опасно для обеих сторон, если одна из сторон не вкурсе, что такой «пакет» может придти. Пришел пакет, не распарсили, все кровь-кишки наружу с segfault в худшем случае.

Они keepalive_timeout отдельно хендлят. SO_KEEPALIVE вообще там не приделах.

это верно. там двойная перестраховка. на случай если в какой-то момент (в каком-то состоянии протокола) не проверяеися таймают очередной blahblahblah_timeout_handler-функцией.

и кстате говоря на самый первый момент вставления в код SO_KEEPALIVE — так и было (не все случаи были отловлены через свои blahblahblah_timeout_handler-функции... затем, потом уже уже отловили больше случаев, быть может даже все случаи)

Откуда они это взяли?

Ты лучше погрепай TCP_KEEPIDLE xD. А то дефолтные два часа мало подходят как средство защиты.

и кстате говоря на самый первый момент вставления в код SO_KEEPALIVE — так и было

Кстати, да. Вот и разгадка)

Знаю по личному опыту, что выставлять SO_KEEPALIVE опасно для обеих сторон, если одна из сторон не вкурсе, что такой «пакет» может придти.

Вот откуда, откуда берутся эти страшилки?

Пришел пакет, не распарсили, все кровь-кишки наружу с segfault в худшем случае.

нет. программа всегда должа быть готова к тому что TCP-сессия будет разорвана по той или иной причине (например даже потому-что интернет-провайдер (или хакер) решил слегка вмешаться в твой интернет-трафик и накидал тебе неожиданных пакетов).

http://nginx.org/ru/docs/http/ngx_http_core_module.html#keepalive_disable

Да, только эта опция не имеет никакого отношения к SO_KEEPALIVE.

Мне лень доказывать. Все там используется. Смотри сам функции ngx_http_finalize_request, ngx_http_finalize_connection.

Все там используется. Смотри сам функции ngx_http_finalize_request, ngx_http_finalize_connection.

Это просто как следствие общего механизма. Эта настройка сделана, чтоб браузеры не сходили с ума от хидера Connection, tcp опция вообще не при чем, такие дела.

Хорошо. Ладно, вроде как на большинство ответов я уже получил ответы. Надо все переварить и проверить как это будет работать.

И кстати, ты в курсе, что пока не укажешь so_keepalive в директиве listen, то nginx пользуется умолчательными настройками для сокета в конкретной операционке, то есть не вызывает setsockopt(..., SO_KEEPALIVE, ...).

Шах и мат.

а что в итоге хочешь получить? Это игры что-ли у тебя?

Посмотри еще long pulling

Есть реализации веб-сокетов, для некондиционных браузеров (обёртки на js)

Есть еще воркеры...

По сути веб-сокет это пулл соединений, создающий иллюзию постоянного соединения...

Да, я это прочитал.

Я хочу получить постоянные соединения: оставаться в состояние ESTABLISHED после отправки ответа сервером. Сейчас он отправил ответ (html-страницу, например) и закрыл соединение. По RFC это нормально, т.к. все условия соблюдены: проставляется хидер Connection: close, закрытие соединения инициирует сервер с посылкой FIN первым. А он (потенциально) может держать 10к+ соединений в ESTABLISHED, тем самым повысится немного перформанс. Ну, и вообще круто будет, имхо.

Такое интересное обсуждение, можно со своим самоваром влезть? Проблема очень похожа на описанную топикстартером. У нас это выглядит так:

1. Программист на питоне 3.5 пишет конструкцию :

conn = aiohttp.TCPConnector(verify_ssl=False, keepalive_timeout=600)
self._session = aiohttp.ClientSession(connector=conn)
return self._session

2. Программист ждёт что у него будет создано TCP-соединение с keepalive и вроде бы по документации это действительно так, фраза "By default all connectors except ProxyConnector support keep-alive connections" намекает на это. sockopts он не использует, говорит что умеет делать TCP-соединения с keepalive и bla-bla-bla.. Возможно он прав.

3. В результате, по истечении 15 мин или (как я понял) если собеседнику передаётся хотя бы байт трафика - соединение меняет статус на «off».

4. У CentOS 7.1 настройки стандартные:

net.ipv4.tcp_keepalive_time = 7200 (2 hours)
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9

5. Программист требует выяснить кто ему меняет статус соединения. Сервер крутится виртуальной машинкой под CentOS 7.1 установленном по умолчанию в облаке GCE и виновным в разрывах соединения программист (это PM с функцией программиста) предварительно назначил Google.

6. Менять tcp_keepalive_time запрещено (предложение поддержки Google поменять tcp_keepalive_time на значение менее 600 названо неудовлетворительным), системному администратору поставлена задача выяснить почему наблюдается такое поведение. Программист считает что соединение может и должно поддерживаться неограниченно долго при любом значении net.ipv4.tcp_keepalive_time для кода который приведён выше.

Что может сказать почтенная публика?

Тема древняя, лучше бы создать отдельную. Спросим, кто тут разбирается в aiohttp, user_id_68054.

требует выяснить кто ему меняет статус соединения

Ну очевидно же что таймер (в aiohttp, на чисто прикладном уровне) это сделал.

TCP_KEEPALIVE тут уж точно не причём.

Тред прочитал бегло. Тут было пару светлых советов. Главный смысл:

Не надо путать кипалайв сокетов и кипалайв хттп. Это совершенно разные вещи.

Первый вариант реально не закрывает соединение в означенный таймаут, и это должен уметь клиент на уровне сокетов.

Второй вариант на уровне хттп это чисто рекомендательный заголовок. Клиенты вообще могут класть на него.

Примеров не будет, я допиваю кофе и валю на работу.