웹 소켓을 이용해서 채팅을 구현하고자 한다.
그전에 웹 소켓이 무엇이고 어떻게 동작을 하는지 알아보자
웹소켓
웹소켓을 알아보기 전에 http를 알아보자
우리가 기본적으로 사용하고 있는 http는 대표적인 3가지 특징을 가지고 있다.
먼저, 간단함이다.
http는 요청과 응답으로 이루어져 있다.
이러한 간단 구조 인해서 서버와 통신하기가 용이하다.
두번째는 무상태이다.
무상태는 각각의 요청이 독립적이라는 것이다.
예를 들어, A요청을 보내고 난 뒤 B요청을 보냈다고 해보자.
A요청과 B요청은 독립적인 요청들이다.
즉, A요청이 B요청에 영향을 주지 못하고 B요청이 A요청에 영향을 주지 못 한다.
세번째는 비연결성이다.
http는 요청을 보내고 응답을 받으면 연결이 끊기는 특징을 가지고 있다.
이 부분이 웹소켓을 선택한 이유이다.
http로 하게 되면 실시간으로 계속해서 요청을 보내야하는 불편함이 있고 채팅은 실시간으로 통신을 해야하는데 http 요청은 일정한 시간이 걸리기 때문이다.
반면, 웹소켓은 서버와 클라이언트 간에 실시간 통신이 가능하다.
그리고 한 번 연결을 하면 연결을 끊기까지 지속적인 연결이 가능하다.
그런데 단순히 웹소켓을 통해서 채팅을 구현하는 것이 아니라
stomp를 사용해서 구현을 할 것이다.
STOMP
stomp는 웨소켓 연결을 통해서 클라이언트와 서버간에 메세지를 메세지브로커를 활용해서 교환하는 프로토콜이다.
stomp에는 pub와 sub라는 개념이 있는데 pub은 메세지를 보내는 것이고 sub는 구독하는 것 즉, 메세지를 받는 것이다.
위 이미지는 /room/1로 채팅을 보내게 되면 /room/1를 구독하고 있는 사람만 메세지를 받게 되는 형식이다.
웹소켓에 경우 문자와 바이러니 타입을 주고 받는다.
하지만 이런한 문자나 바이러니 타입을 어떤한 형식으로 주고 받을지 정해진 형식이 없다.
간단한 애플리케이션에서는 문제가 없지만 규모가 커지고 하면 어떤 타입을 받을지 보내주실 지 등 형식이 필요해진다.
stomp를 사용하면 프레임라는 커맨드, 헤더, 바디라는 형식으로 저해두었다.
그래서 이 형식을 고민할 필요가 없다.
STOMP의 동작원리
stomp를 쓰기 위해서 stomp의 동작원리를 알아보자
메세지를 보내는 사람과 메세지를 받는 사람이 있다.
메세지를 보내는 사람은 발신자라고 하고 메세지를 받는 사람을 구독자라고 하자.
구독자는 /topic을 구독하고 있다고 해보자.
발신자가 이 /topic이라는 도착주소로 보내서 바로 메세지를 보낼 수 있다.
하지만 만약 보내는 메세지에 가공이 필요한 경우가 있다면 /app라는 곳으로 메세지를 보낸다.
가공이 다 되면 /topic이라는 주소로 메세지브로커에게 전달이 되면 /topic을 구독하던 구독자들이 가공된 메세지를 볼 수 있다.
