Серпуху Tomcat 7 необходимо принудительно закрыть длительное соединение NIO

Question

У меня есть сервлет Tomcat 7, принимающий соединения с удаленными клиентами и поддерживающие эти соединения в течение нескольких часов или дней, если это возможно. Итак, мы используем разъем NIO. Полоса пропускания по физическим соединениям может быть дорогостоящей, поэтому трафик должен быть сведен к абсолютному минимуму, поэтому мы запрограммировали удаленные клиенты для проверки соединения с очень редким пингом.

Иногда сервлету сообщается, что соединение закрыто, но кажется, что удаленным клиентам не сообщается. Клиенты не узнают, пока не сделают пинг, и в это время они могут установить новое соединение. Нам нужно сократить время, в течение которого клиенты не подключены, не используя больше пингов.

Один из способов, который работает, - закрыть сервер Tomcat. Клиенты знают, что они немедленно отключены. Очевидно, мы не хотим закрывать Tomcat - моя точка зрения - должен быть какой-то сигнал, который делает это через нормально-тихое соединение.

Как заставить Tomcat отправить этот сигнал? Пожалуйста, не отвечайте, что я не могу, если вы не можете сказать мне, почему, со спецификой, отчасти потому, что я не могу в это поверить, и в основном потому, что я не хочу в это верить. Кажется странным - как будто вы не можете повесить трубку на кого-то.

Альтернативный вопрос # 1 - может ли сервлет восстановить соединение, которое было сказано, закрыто?

Альтернативный вопрос №2 - может ли кто-нибудь подумать о чем-нибудь еще, что может помочь?

Answer 1

Пара мыслей:

• Я удивлен, что клиенты не знают о том, что соединение было закрыто. Вы уверены, что исключение не проглатывается где-то на стороне клиента?
• С длинными днями подключения я бы начал смотреть на то, что происходит на уровне TCP. Вы не указали какую-либо диагностику или информацию ...
  • Вы пытались определить, существует ли существующее соединение TCP/IP для этих проблемных соединений клиент/сервер?
  • Насколько стабильной является сеть между клиентом и сервером?
  • Являются ли их потенциально ошибочные сетевые устройства, например, прокси или маршрутизаторы?
• Я действительно не вижу преимущества использования разъема NIO в этом контексте долгоживущих соединений. Сколько запросов в секунду? Да. Но только для долгоживущих связей? №
  • В прошлом у меня была странная проблема с разъемом NIO и шлюзом протокола сервлетов (OpenAMF), который волшебным образом ушел с использованием стандартного HTTP-коннектора.
  • Проверьте другие два разъема (HTTP, собственный ARP), сравните их.
• Я бы также рассмотрел вопрос о подключении любого протокола на основе TCP (например, HTTP) в пользу некоторого подхода на основе UDP. Таким образом, ваши соединения будут безразличными и с настроенной нагрузкой на заказ пакеты очень маленькие.

Answer 2

Я отвечаю на этот старый вопрос, как мы уже видели один и тот же вопрос с HTTP-соединений (или любых TCP соединений) в открытом положении в течение десятков минут без движения через брандмауэр. Если на самом деле нет брандмауэра, тогда мой ответ не применяется.

Вы можете подтвердить эту теорию одновременным tcpdump/wireshark на клиенте и сервере и немного терпения.

Если есть брандмауэр, то вам нужно убедиться, что пакеты «ping» встречаются чаще, чем время простоя TCP-соединения брандмауэра, чтобы поддерживать соединение. Подумайте дважды, прежде чем увеличивать время брандмауэра, брандмауэр может не справиться с этим, как я объясню.

Брандмауэр между вашими клиентами и сервером может выполнять NAT или проверку пакетов. Эти функции требуют ресурсов на брандмауэре, и существует ограничение на количество подключений брандмауэра. Таким образом, по умолчанию он будет «молча закрывать» эти соединения после простоя, чтобы сохранить ресурсы.

Я говорю молча, потому что брандмауэр не будет отправлять какие-либо пакеты в обе стороны, пока клиент или сервер не отправят трафик. На данный момент брандмауэр обычно отвечает пакетом RST. Мы проследили это с помощью tcpdump как от клиента, так и от сервера. Он показал, что брандмауэр отправляет этот пакет RST, как будто со стороны подключения. Однако tcpdump с другой стороны подтвердил, что этот пакет не был отправлен. Это должен быть брандмауэр.

Увеличение размера таймаута простоя на брандмауэре может привести к большему количеству проблем, так как брандмауэр не сможет обрабатывать количество подключений. Это может привести к общему сбросу брандмауэра, где вы можете увидеть все сокеты tcp через брандмауэр.

Как вы должны использовать TCP, тогда избегайте любой функции брандмауэра, которая потребует отслеживания соединений на брандмауэре (NAT, учет, проверка пакетов). Или убедитесь, что у вас есть брандмауэр с достаточным количеством ресурсов для отслеживания всех подключений.