LINUX.ORG.RU
решено Форум — Admin  

TCP connection stuck in ESTABLISHED

 , ,


0

1

Всем доброго времени суток.

Есть сервер с приложением, которое работает на 3737 порту. Задача его (приложения) состоит в авторизации пользователей. Недавно обнаружил такую проблему: при невыясненном стечении обстоятельств, в подключениях висят сотни ESTABLISHED. Выглядит это так: 

# netstat -tapn | grep 3737
tcp        0      0 192.168.0.11:3737     0.0.0.0:*              LISTEN      17871/auth
tcp        0      0 192.168.0.11:3737     192.168.0.20:4525      ESTABLISHED 17871/auth
tcp        0      0 192.168.0.11:3737     192.168.0.14:60966     ESTABLISHED 17871/auth
tcp        0      0 192.168.0.11:3737     192.168.0.14:60745     ESTABLISHED 17871/auth
Последние 3 соединения (см. выше) уже не активны, передачи данных по ним нет. В нормальном режиме - приложение открывает соединение, пользователь авторизуется и соединение закрывается.

Пробовал играться с параметрами sysctl: 

net.netfilter.nf_conntrack_tcp_loose = 0
net.netfilter.nf_conntrack_tcp_timeout_close = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 30
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 30
Результата нет... Соединения висят до тех пор, пока приложение работает.

Почему происходит такая ерунда и как с ней бороться?

если такое часто, то криво написаны клиент/сервер, если редко, то может быть проблема сети

anonymous
()
Ответ на: комментарий от anonymous

Почему тогда соединение продолжает «висеть», даже когда передачи данных по нему нет? Так же не понятно, почему параметр «nf_conntrack_tcp_timeout_established» в данном случае никак не регулирует эту ситуацию.

kill2kill
() автор топика
Ответ на: комментарий от kill2kill

nf_conntrack_* управляют поведением таблицы conntrack. На соединения, терминирующиеся на хосте, они не влияют.

Сервер должен закрывать соединения по таймауту неактивности. А он этого не делает. Плохой сервер.

iliyap ★★★★★
()

В нормальном режиме - приложение открывает соединение, пользователь авторизуется и соединение закрывается.

Скорее всего, соединение не закрывается. С бОльшей долей вероятности проблема софта.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от kill2kill

да причем тут вообще параметры сетевого фильтра?
смотри 

# sysctl -a | grep keepalive
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200
#
и # netstat -ot

anonymous
()
Ответ на: комментарий от anonymous 
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_time = 60

tcp        0      0 192.168.0.11:3737     192.168.0.37:1040      ESTABLISHED off (0.00/0/0)
kill2kill
() автор топика

В общем, первый комментарий натолкнул на еще один момент, который не рассматривался подробно - софт. Сервер написан с использованием boost::asio и проблема кроется именно в нем. При непредвиденном закрытии соединения со стороны клиента, сервер продолжает думать, что с соединением все ок.

kill2kill
() автор топика
Ответ на: комментарий от kill2kill

Если сервер самописный, то там где-то должна быть возможность добавить к сокету опцию SO_KEEPALIVE. Тогда, по умолчанию, через 2 часа с копейками будет закрывать соединение.

anto215 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin