Keep-alive и долгие сессии: где рвётся

Держу долгий сеанс к одному узлу: вхожу один раз, дальше за смену дёргаю его сотню раз по мелочи. Между дёрганьями бывает пауза минут в десять.

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

Пока прикрутил повтор с одной попыткой, оно работает, но это заметание под ковёр. Хочу понять, кто именно кладёт трубку: посредник, узел или что-то по дороге.

requests.exceptions.ConnectionError: ('Connection aborted.',
  RemoteDisconnected('Remote end closed connection without response'))

Классика пула соединений. У вас в кармане лежит открытый сокет, вы про него думаете, что он живой и тёплый. Собеседник закрыл его десять минут назад по своему таймауту простоя, уведомление либо не дошло, либо дошло и было проглочено пулом.

Дальше вы пишете в мёртвый сокет и получаете ровно эту строчку. Тут не поломка сети, тут расхождение в бухгалтерии между вами и дальним концом.

а таймаут простоя где смотреть, у себя или у них

Хорошая формулировка, забираю. loginless, я тоже сначала копал у себя, потом насчитал в цепочке целых три места, где висит свой таймер.

Три места это ещё скромно, обычно их больше. Разложу столбиком, кто первым кладёт трубку.

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

Иногда узел прямо пишет в ответе, сколько времени вам дали:

Keep-Alive: timeout=5, max=100

Посмотреть можно на живой машине, гадать необязательно: ss -tno рисует таймер по каждому соединению. Если в колонке timer стоит keepalive и число тикает вниз, сокет держит ядро.

У себя лечил в два касания. Ограничил срок жизни сокета в пуле и добавил один вежливый повтор именно на такой обрыв.

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

s = requests.Session() r = Retry(total=2, backoff_factor=0.4, status_forcelist=[502, 503, 504]) s.mount("https://", HTTPAdapter(max_retries=r, pool_maxsize=20)) ```

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

понял, забрал себе, спасибо

Добавлю про ядро, раз его помянули. Когда сеанс правда долгий и молчаливый, включайте пробы на сокете и опускайте их время ниже самой короткой паузы в цепочке.

sudo sysctl -w net.ipv4.tcp_keepalive_time=90
sudo sysctl -w net.ipv4.tcp_keepalive_intvl=20

Иначе ядро проснётся через два часа и обнаружит обрыв, случившийся полутора часами раньше.

Померил через ss, рвётся у меня раньше всех сам узел. В заголовке ответа честно написаны те самые пять секунд.

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

Собрал итог для тех, кто придёт сюда поиском.

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