WebSocket Ping a TCP Keepalive przez proxy
Wybierz kontrolę żywotności partnera WebSocket zamiast traktować żywe gniazdo TCP jako dowód, że ścieżka aplikacji odpowiada.
Żywe gniazdo TCP, reagujący partner WebSocket i użyteczny postęp aplikacji to różne obserwacje:
| Dowód | Co ustala |
|---|---|
| Żywotność na poziomie TCP | Sprawdzana ścieżka transportu odpowiada na tym poziomie |
| Pasujące WebSocket Pong | Partner odpowiedział na tę ramkę kontrolną |
| Potwierdzenie aplikacji | Aplikacja potwierdziła operację w ramach własnego protokołu |
Proxy przekazujące zwykle utrzymuje osobne połączenia do klienta i do miejsca docelowego. Partnerem TCP klienta jest proxy, a Ping w ustanowionym tunelu wędruje do punktu końcowego WebSocket.
Pasujące Pong
Protokół wymaga, aby odpowiadające Pong przenosiło dane aplikacyjne Ping. Użyj tej zgodności, aby zidentyfikować oczekującą sondę. Niewywołane Pong jest dozwolone, ale nie prosi o potwierdzenie; wysyłanie go po każdej wiadomości z danymi daje inny dowód.
Preferuj mechanizm bicia serca obsługiwany przez bibliotekę. JavaScript w przeglądarce potrzebuje zamiast tegokontraktu bicia serca aplikacji. Dobierz interwały i progi błędów do obciążenia i polityki sieci. Pauzy harmonogramu lub przeciążona pętla zdarzeń mogą przegapić agresywny próg, nie stwierdzając awarii sieci.
Utrzymuj odbiornik w ruchu
Klient potrzebuje ciągłego I/O, aby odbierać i przetwarzać ramki kontrolne. Zablokowanie tego mechanizmu może sprawić, że lokalny głód zasobów będzie wyglądał jak awaria.
Ping tworzy ruch w tunelu, ale każdy pośrednik sam decyduje, co spełnia jego politykę bezczynności. Żadne bicie serca nie gwarantuje ochrony przed bezwzględnym limitem czasu życia połączenia.
Partner może odpowiadać na Ping, gdy jego aplikacja przestaje produkować aktualizacje, a cicha subskrypcja może być zdrowa. Śledź ostatnie poprawne Pong i istotne zdarzenie aplikacji osobno, gdy oba mają znaczenie. Przy awarii zachowaj trasę, czasy i oczekującą sondę, a następnie zamknij lub odzyskaj w obsługiwanym cyklu życia.