Живой TCP-сокет, отвечающий партнёр WebSocket и полезный прогресс приложения — это разные наблюдения:

СвидетельствоЧто оно устанавливает
Живость на уровне TCPПроверяемый транспортный путь отвечает на этом уровне
Совпадающий WebSocket PongПартнёр ответил на этот управляющий кадр
Подтверждение от приложенияПриложение подтвердило операцию по своему протоколу

Прямой прокси обычно поддерживает отдельные соединения с клиентом и с пунктом назначения. TCP-партнёром клиента является прокси, а Ping внутри установленного туннеля доходит до конечной точки WebSocket.

Совпадающий Pong

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

Предпочитайте механизм heartbeat, поддерживаемый библиотекой. JavaScript в браузере нуждается вместо этого вконтракте heartbeat приложения. Выбирайте интервалы и пороги отказа под нагрузку и сетевую политику. Паузы планировщика или перегруженный цикл событий могут пропустить агрессивный порог, так и не установив отказа сети.

Держите приёмник работающим

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

Ping создаёт трафик в туннеле, но каждый посредник сам решает, что удовлетворяет его политику простоя. Ни один heartbeat не гарантирует защиты от абсолютного ограничения времени жизни соединения.

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

Похожие статьи