Живий TCP-сокет, партнер WebSocket, що відповідає, і корисний прогрес застосунку — це різні спостереження:

ДоказЩо він установлює
Живучість на рівні TCPПеревірений транспортний шлях відповідає на цьому рівні
Відповідний WebSocket PongПартнер відповів на цей керівний кадр
Підтвердження від застосункуЗастосунок підтвердив операцію за власним протоколом

Прямий проксі зазвичай підтримує окремі з'єднання з клієнтом і з призначенням. TCP-партнером клієнта є проксі, а Ping усередині встановленого тунелю доходить до кінцевої точки WebSocket.

Відповідний Pong

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

Надавайте перевагу механізму heartbeat, який підтримує бібліотека. JavaScript у браузері потребує натомістьконтракту heartbeat застосунку. Вибирайте інтервали та пороги відмови відповідно до навантаження й мережевої політики. Паузи планувальника або перевантажений цикл подій можуть пропустити агресивний поріг, так і не встановивши відмови мережі.

Тримайте приймач у роботі

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

Ping створює трафік у тунелі, але кожен посередник сам вирішує, що задовольняє його політику простою. Жоден heartbeat не гарантує захисту від абсолютного обмеження часу життя з'єднання.

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

Схожі статті