안녕하세요. 저는 STOMP 웹소켓 프로그래밍이라는 주제로 발표한 문찬욱입니다.
저는 이번 프로젝트에서 채팅 기능을 구현하고 있는데요, 그 과정에서 사용한 기술에 대해 공유드리고자 이 주제를 선정했습니다.
이 글에서 웹소켓이 무엇인지, http와 웹소켓의 차이점이 무엇인지, 웹소켓 동작 방식은 어떤지, STOMP이 무엇인지 알려드리고자 합니다.
1. 웹소켓
웹소켓은 http 환경에서 클라이언트와 서버 사이에 하나의 TCP 커넥션을 통해 실시간으로 전이중 통신을 가능하게 하는 프로토콜입니다.
여기서 전이중 통신은 전화기처럼 양방향으로 송신과 수신이 가능한 통신을 뜻합니다.
2. HTTP vs 웹소켓
그럼 이러한 웹소켓과 HTTP와의 차이점은 무엇일까요?
Http는 클라이언트가 요청을 보낼 때마다 연결을 맺고 응답을 받은 후 연결을 끊어버리기 때문에 비 연결성 프로토콜입니다.
그리고 클라이언트가 요청하고 서버가 응답하는 단방향 통신입니다.
반면에 웹소켓은 한번 연결을 맺으면 어느 한쪽에서 연결을 끊으라는 요청을 보내기 전까진 연결을 유지하기 때문에 연결 지향 프로토콜입니다.
그리고 양 쪽에서 데이터를 주고 받을 수 있는 양방향 통신입니다.
실시간 측면에서는…?
http는 비 연결성이기 때문에 데이터를 주기 위해선 매번 연결해야 하고 그만큼 연결 비용이 발생하게 됩니다.
즉, 오버헤드가 커집니다.
위 이미지에서 왼쪽은 일반적인 http로 주고받는 데이터양이고, 오른쪽 위는 웹소켓 연결요청할 때의 데이터양이고, 그 아래는 연결 이후의 데이터양입니다.
웹소켓은 처음 연결할 때 http로 하기 때문에 처음 데이터 양은 유사하지만, 이후 데이터 양이 매우 줄어든 것을 확인할 수 있습니다.
이러한 점들에서 웹소켓이 http 보다 실시간성에 더 유리합니다.
3. 웹소켓 동작 방식
웹소켓의 동작 방식은 크게 3가지로 나눌 수 있는데요,
빨간 박스는 Opening Handshake,
노란 박스는 Data transfer,
보라 박스는 Closing Handshake에 해당됩니다.
Opening Handshake
빨간 박스 부분인 Opening Handshake는 먼저 웹소켓 클라이언트에서 http 프로토콜을 통해 웹소켓으로 Upgrade 해달라는 요청을 보냅니다.
이 요청의 의미는 웹소켓 프로토콜로 전환해달라는 것입니다.
그 다음 웹소켓 서버는 101 응답과 함께 웹소켓 프로토콜로의 전환을 승인했음을 알립니다.
Data Transfer
노란 박스 부분인 Data Transfer는 Opening Handshake가 끝나서 전환된 웹소켓 프로토콜을 통해 클라이언트와 서버 간 실시간 전이중 통신을 하는 부분입니다.
Closing Handshake
보라 박스 부분인 Closing Handshake는 서로 간의 커넥션을 종료하는 부분입니다.
4. STOMP
STOMP는 streaming text oriented messaging protocol의 줄임말이며,
메세지 브로커를 활용하여 쉽게 메시지를 주고 받을 수 있는 프로토콜입니다.
이 프로토콜은 웹소켓 위에 얹어 하위 프로토콜로 함께 사용할 수 있습니다.
웹소켓만 사용하는 것 비해 어떤 이점이…?
웹소켓 프로토콜은 메시지 데이터 타입이 Text인지 Binary인지는 정의하지만, 메시지 내용에 대해서는 정의하지 않습니다.
이는 복잡한 메시지를 주고 받으려면 어떤 메시지인지 알기 위한 로직이 필요하다는 것입니다.
STOMP 프로토콜은 메시지 내용을 구조화 할 수 있어서 효과적인 메시징을 도와줍니다.
예를 들어, A라는 사람이 B라는 사람에게 “안녕”이라는 내용으로 보내는 메시지가 있다고 해보겠습니다.
웹소켓로 보낼 때는 “안녕”이라는 메시지만 보내면 됩니다.
클라이언트가 1명이라면 문제가 없지만, 클라이언트가 여러명이라면, 이 메시지를 누가 보냈는지, 누구한테 가야하는지, 어떤 용도로 보내는 것인지 서버가 알 수가 없습니다.
물론, 단순히 안녕이 아닌 모든 정보가 담긴 한줄의 긴 텍스트 문자열로 보낼 수 있습니다.
하지만 이러면, 서버가 이 메시지를 이해하고 처리하기 쉽지 않을 수 있습니다.
또한 연결된 클라이언트 주소마다 메시지 핸들러를 구현해야 합니다.
STOMP는 이미지처럼
destination /app/chat/message로 보내는, sender A가,
content “안녕”의 내용의 메시지를,
send 전송했음을
구조화 된 형태로 보낼 수 있기 때문에 서버는 이 메시지가 어떤 메시지인지 이해하고 처리하기 쉽습니다.
또 다른 이점은 STOMP는 pub/sub 구조로 되어있다는 것입니다.
pub/sub 구조란 이 이미지처럼 publisher에서 메시지 브로커의 Topic1이라는 특정 토픽에 메시지를 보내면, Topic1을 구독하고 있는 subscribe들에게 메세지를 전달하는 구조를 말합니다.
이 구조로 인해 최대 토픽별로만 메시지 핸들러를 구현해주면 되기 때문에 웹소켓로만 구성된 것에 비해 메시지 핸들러 구현 양이 줄어든다는 이점이 있습니다.
pub/sub 구조의 특징
저는 pub/sub 구조의 특징을 크게 3가지로 나눠볼 수 있었습니다.
첫째, pub과 sub을 쉽게 추가할 수 있어서 확장성이 좋습니다.
둘째, pub과 sub 간에 강한 의존성이 없어서 비동기적으로 처리할 수 있습니다.
셋째, sub은 관심 토픽에 대한 메시지만 받을 수 있어서 선택적 수신이 가능합니다.
5. 마무리
채팅, 실시간 업데이트, 알림 같은 실시간성 기능을 구현하고자 하면,
STOMP도 선택지 중 하나라고 생각합니다.