[22.09.05] Daily 회고록 (Stomp, Cookie to Session, handshake interceptor)

웹소켓을 적용하기 전에 익명 사용자의 접속정보를 어떻게 유지할까 고민하다가 쿠키를 사용하여 구분하기로 정해 제작하였었다. 그런데 웹소켓을 적용하자 쿠키를 위해 사용하였던 HttpServletResponse를 STOMP(SockJS) controller의 message mapping에서 이용할 수 없었다.

그 이유를 알아보았는데 일단 쿠키는 HTTP 프로토콜의 비연결성을 지향하여 사용자의 접속 정보를 남기지 않음을 고려하여 HTTP 프로토콜 내에서 상태를 유지하기 위해 사용하는 것인데, 그에 반해 세션은 사용자 정보를 서버 측에서 관리하며 세션 ID를 부여하여 인증상태를 유지한다.

websocket은 HTTP와는 다르게 양방향향 통신을 지원하는 OSI 모델의 7계층에 위치한 프로토콜이며, 이를 기반한 stomp도 마찬가지이다. 이들은 제 4계층에 위치한 TCP에 의존하며, 80-443 포트 위에서 동작하도록 설계되어있다. HTTP에 프록시 및 중간 층을 지원하도록 설계되어 헤더를 더해(Upgrade) HTTP와 호환이 가능하다.

websocket의 handshake를 보면 http는 전송할 때마다 handshake를 통해 request와 response를 이용해 통신하는 반면, websocket은 한 번의 handshake 후에 패킷을 전달받는다. 그로 인해 웹소켓 사용 중 씬 이동이 되었을 때는 쿠키를 컨트롤러 단에서 직접 전달 받기가 애매하여, 첫 handshake에서 쿠키를 설정해주어야했는데 이 과정을 스프링 인터셉터에서 처리해주어야했고, 세션을 통해 서버에 저장하기로 했다.

HandShakeInterceptor

StompConfig

인터셉터를 추가하기 위해 Handshake 시 방문하는 HandshakeInterceptor를 implement한 클래스를 만들고, StompConfig에 추가하였더니 웹소켓 최초 연결 시에 해당 인터셉터를 잘 방문하였다. 이를 통해 세션 키를 발급 받았다.

RoomStompController

그리고 그렇게 발급 받은 키를 SimpMessageHeaderAccessor를 통해 Controller에서 접근할 수 있었고, 이를 참여자 필드로 적용하여 구분자로 사용하였다.