Соединение через веб-сокет зависло в состояниях FIN_WAIT1 FIN_WAIT2

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

На сервере, когда я выполняю lsof или netstat -an, я вижу, что многие соединения отображаются в состоянии FIN_WAIT1 и FIN_WAIT2, кроме соединений, находящихся в состоянии ESTABLISHED. На данный момент ulimit для открытых файлов составляет 1024. Будут ли соединения, застрявшие в этих двух состояниях, учитываться в списке открытых файлов? Если это так, то лимит 1024 будет исчерпан очень скоро.

/proc/sys/net/ipv4/tcp_orphan_retries равно 0, что эквивалентно 8, кажется https://serverfault.com/questions/274212/what-does-tcp-orphan-retries-set-to-0-mean/408882#408882

Я проконсультировался по этой ссылке: https://serverfault.com/questions/7689/how-do-i-get-rid-of-sockets-in-fin-wait1-state

Но я мало что понимаю. Я читал об этих двух состояниях в Интернете и понимаю, что они являются частью протокола, но я бы предпочел, чтобы соединения не зависали в состояниях, в которых они бесполезны. Могу ли я сделать это как-то? Должен ли я изменить ulimit? Но это просто означало бы, что проблема возникнет в момент времени x+y вместо x.


ubuntu tcp websocket connection ulimit
person neeraj    schedule 24.11.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Каждый раз, когда вы видите состояние Fin_Wait или любое состояние ожидания, если на то пошло, мы часто называем это 1/2 сеансами. Стек TCP следует очень строгому протоколу в отношении порядка запросов и ответов. Именно из-за этих правил он знает, как и когда, а также насколько сложно попытаться восстановиться, отправив повторные попытки. В случае любого состояния ожидания стек знает, что он чего-то ожидает. Есть только две вещи, которые удовлетворят этому условию: 1) Какой-то правильный ответ или 2) Тайм-аут.

Конечно, лучший способ пойти, чтобы получить надлежащий ответ. Необходимо провести работу, чтобы выяснить, почему так много ожиданий. Иногда это происходит из-за нестабильной коммутации, маршрутизации и других действий, связанных с сетью. Однако это также может быть результатом атаки типа «отказ в обслуживании», потому что они не заботятся о состоянии. Единственный способ высвободить необходимые ресурсы на прикладном уровне — восстановить управление приложением. TCP дает управление только в том случае, если 1) рабочий процесс нормальный или 2) истекло время ожидания или произошло другое ненормальное состояние. Например, FIN и RST могут быть отправлены вне очереди и в любое время. Они оба считаются козырем любого другого государства. Имейте в виду, что не все клиенты или хосты действуют одинаково, поскольку мы говорим о разных реализациях стека TCP.

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

person JWP    schedule 15.12.2014