프록시를 통한 WebSocket Ping과 TCP Keepalive 비교

살아 있는 TCP 소켓, 응답하는 WebSocket 피어, 유용한 애플리케이션 진행은 서로 다른 관측입니다.

포워드 프록시는 보통 클라이언트 쪽과 목적지 쪽에 별도의 연결을 유지합니다. 클라이언트의 TCP 피어는 프록시이고, 설정된 터널 내부의 Ping은 WebSocket 엔드포인트까지 이동합니다.

일치하는 Pong

프로토콜은 응답하는 Pong이 Ping의 애플리케이션 데이터를 담도록 요구합니다. 이 대응을 사용해 미완료된 검사를 식별하십시오. 요청하지 않은 Pong은 허용되지만 확인을 요구하지 않습니다. 각 데이터 메시지 뒤에 보내면 다른 증거가 됩니다.

라이브러리가 지원하는 하트비트 방식을 우선하십시오. 브라우저 JavaScript는 대신 애플리케이션 수준 하트비트 계약이 필요합니다. 간격과 실패 임계값은 작업 부하와 네트워크 정책에 맞춰 선택하십시오. 스케줄링 중단이나 과부하된 이벤트 루프는 네트워크 장애를 입증하지 않은 채 공격적인 임계값을 놓칠 수 있습니다.

수신기를 계속 동작시키십시오

클라이언트는 제어 프레임을 받아 처리하기 위해 지속적인 입출력이 필요합니다. 그 장치를 막으면 로컬 고갈이 장애처럼 보일 수 있습니다.

Ping은 터널 트래픽을 만들지만, 각 중간 장치는 자신의 유휴 정책을 무엇이 충족하는지 스스로 결정합니다. 어떤 하트비트도 연결 수명의 절대 한계에 대한 보호를 보장하지 않습니다.

피어는 애플리케이션이 업데이트 생성을 멈춰도 Ping에 응답할 수 있고, 조용한 구독이 건강할 수도 있습니다. 둘 다 중요할 때는 마지막 유효 Pong과 의미 있는 애플리케이션 이벤트를 따로 추적하십시오. 실패 시 경로, 경과 시간, 미완료 검사를 보존한 뒤 지원되는 수명 주기를 통해 닫거나 복구하십시오.