프록시된 WebSocket 재연결 후에는 세션도 복원하세요

재연결 콜백이 실행되고 새 소켓이 열립니다. 그것은 전송 계층의 복구입니다. 구독, 메시지 확인 응답, 애플리케이션 세션이 이전 연결이 멈춘 지점부터 이어졌다는 뜻은 아닙니다.

같은 프록시 엔드포인트라도 새 아웃바운드 연결을 만들 수 있습니다. 출구 IP가 바뀌면 대상의 자체 세션 정책이 작동할 수도 있습니다. 새 소켓을 새 연결로 다루고 애플리케이션의 문서화된 복구 교환을 따르세요. 재연결할 때 워크플로가 프록시 경로를 유지해야 하는지 결정하세요.

마지막 URL보다 조금 더 보관하세요

유용한 복구 상태에는 승인된 세션 식별자, 원하는 구독, 마지막으로 확인된 이벤트 식별자, 아직 확인 응답을 기다리는 작업이 포함될 수 있습니다. 그 필드들은 애플리케이션 프로토콜에 속합니다. WebSocket은 보편적인 재개 토큰을 정의하지 않습니다.

커서에서 재개할지, 새 스냅샷을 받을지, 공백을 받아들일지 결정하세요. 이벤트 소스가 재생 인터페이스를 제공하지 않는다면 더 빠르게 재연결해도 메시지가 유실되지 않았음을 증명할 수 없습니다.

두 번 보내는 것은 두 번 수행하는 것일 수 있습니다

연결이 끊기기 전에 로컬에서 대기열에 들어간 메시지는 클라이언트를 떠나지 않았을 수 있습니다. 다른 메시지는 확인 응답이 유실된 채 서버에 도착했을 수 있습니다. 확인되지 않은 모든 명령을 무작정 다시 보내면 이 두 경우를 동일하게 취급합니다.

가능한 경우 서비스의 요청 식별자, 멱등성 지원, 또는 조정 메커니즘을 사용하세요. 전송 계층의 재연결은 애플리케이션 동작을 되돌릴 수 있게 만들지도, 자동으로 중복을 제거하지도 못합니다.

재연결 시도는 제한하고 애플리케이션 정책에 맞춰 간격을 두세요. RFC 6455는 비정상 종료 후 백오프를 권장합니다. 곧바로 재시도하는 클라이언트 무리는 장애 중 부하를 키울 수 있습니다.

각 시도가 어떤 프록시 경로를 선택했는지 기록하되, 경로 복구는 애플리케이션 복구와 분리하세요. “다시 연결됨”은 유용한 증거입니다. “따라잡았고 더 많은 작업을 제출할 준비가 됨”에는 그것을 확립하는 추가 애플리케이션 교환이 필요합니다.