Сервлет Tomcat 7 должен принудительно завершить длительное соединение NIO

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

Пара мыслей:

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