이전 프로젝트에서 실시간 채팅을 구현하기 위해 WebSocket과 SSE를 이용하여 채팅과 알림 서비스를 구현해보았다. 프로젝트 초기 계획은 WebSocket만 사용하여 채팅을 구현하려고 했는데, socket이 채팅 페이지에서만 연결 되다보니 다른 페이지에서 새로운 채팅이 왔을 때 알림을 전달할 수 있는 방법이 떠오르지 않았고, 그렇게 SSE를 추가하여 모든 페이지에서 알림을 받을 수 있도록 구현해본 적이 있다. 하지만, 이 당시에 프로젝트 마무리 단계 즈음이었고, 담당하고 있는 역할이 많았어서 SSE는 다른 팀원이 구현하게 되어 SSE에 대한 공부를 거의 하지 못해보았다. SSE를 구현하지 못한 아쉬움도 있고해서 실시간 통신 기술에 대해 공부를 해보고자 했는데 다른 프로젝트도 하다보니 3개월이 지나버렸...다.
HTTP 통신은 기본적으로 stateless(connectionless)이기 때문에, 서버가 클라이언트에게 일방적으로 응답을 보낼 수 없다. HTTP 통신은 클라이언트에게 요청을 받아야지만 응답을 보내는 구조이므로, 서버가 클라이언트에게 데이터를 보내고 싶다면 클라이언트가 요청을 보낼때까지 기다려야 한다. 서버의 event를 클라이언트로 보내는 방법은 Polling, Long Polling, SSE, WebSocket, WebRTC가 있다.
polling
클라이언트가 http request를 서버로 계속 날려서 이벤트 내용을 전달받는 방식
클라이언트가 많아지면 서버의 부담이 급증하게 된다. http request connection을 맺고 끊는것 자체가 부담이 많다. 클라이언트에서 실시간 정도의 빠른 응답을 기대하기 어렵다.
정보의 신뢰성 판단을 위해 보내지는 헤더 같은 정보 때문에 오히려 데이터량이나 처리시간이 증가한다. -> http overhead
일정하게 갱신되는 서버 데이터의 경우 유용하게 사용할 수 있다.
실시간 메시지 전달이 중요하지 않고 높은 HTTP 요청 빈도에도 안정적으로 대응할 수 있는 서버 구축 환경을 갖춘 서비스에 적합하다.
long-polling
서버 측에서 접속을 열어두는 시간을 길게하는 방식.
서버에 응답에 대한 사용 가능한 데이터가 없으면 계속 기다리다가 서버에서 해당 클라이언트로 전달할 이벤트가 있다면 그 순간 response 메시지를 전달하면서 연결이 종료된다. 클라이언트에서는 곧바로 다시 http request를 날려서 서버의 다음 이벤트를 기다리게 된다.
일반적으로 polling 방식보다 HTTP 요청 수가 줄어든다는 장점이 있다. 하지만 서버의 데이터 업데이트가 자주 일어날 경우 polling에 비해 성능상 큰 장점은 없다.
실시간 메시지 전달이 중요하지만, 잦은 데이터 전달이 없는 서비스에 적합하다.
SSE (Server-Sent Events)
HTML5 표준안이며 어느정도 웹소켓의 역할을 하면서 더 가볍다. 클라이언트에서 요청을 보내면, 서버는 응답 후 바로 연결을 종료하는 것이 아니라 연결을 유지한 채로 chunk 단위로 응답 스트림에 데이터를 보내는 방식이다.
서버에서 클라이언트로 단방향으로 서버의 event나 message를 클라이언트로 전달하는 작업에 유용하게 사용될 수 있다. 재접속 처리 같은 대부분의 저수준 처리가 자동으로 지원된다.
WebSocket과 다르게 별도의 프로토콜을 구축할 필요도 없고, Polling처럼 요청을 주기적으로 보내서 응답을 받을 필요가 없다. 단, 클라이언트의 요청없이 서버에서 클라이언트에게 단방향 통신을 하기 때문에 모든 실시간 통신이 필요한 기능에는 사용하지 못한다. 단방향 연결이기 때문에 SSE를 사용할 경우 클라이언트에서 서버로의 요청은 기존 HTTP 요청을 사용해야 한다. 클라이언트에서 연결을 close 해도 서버가 이를 감지하지 못한다.
서버에서 일방적인 데이터 전달(알림 서비스)이 필요한 곳 또는 주문형 스트리밍 서비스에 적합하다.
WebSocket
TCP위에서 동작하지만, WS 혹은 WSS라는 통신 프로토콜로 양방향 통신과 영구성을 지닌다. 따라서 HTTP와 달리 Stateful하며 주기적으로 요청을 받을 필요가 없다.
최초 접속이 일반 http request를 통해 handshaking 과정을 통해 이루어져, 기존의 ws(80), wss(443) 포트로 접속을 하므로 추가로 방화벽을 열지 않고도 양방향 통신이 가능하고, http 규격인 CORS적용이나 인증등의 과정을 기존과 동일하게 가져갈 수 있다. 단, websocket 프로토콜을 처리하기 위해 전이중 연결과 새로운 웹소켓 서버가 필요하다.
양측에서 언제든지 원하는 데이터를 보낼 수 있는 구조를 지니고 있지만, 지속적으로 연결이 끊어지지 않게 관리를 해주어야 하며, 서버에서 연결된 클라이언트 만큼의 세션을 유지해야 한다는 문제가 있다.
서버와 클라이언트의 양방향 데이터 전달이 잦고, 중요하게 필요한 상황(채팅)과 socket 통신을 위한 안정적인 서버 구축이 가능한 상황, 실시간 스트리밍 서비스에 적합하다.
WebRTC
WebRTC는 오디오, 영상 전송에 특화된 기술로 위의 기술들은 Client-Server 구조로 동작하지만, WebRTC는 P2P 방식으로 통신이 이루어지며 WebRTC는 TCP 위에서도 동작할 수 있지만, 일반적인 경우 UDP로 통신을 하기 때문에 속도적인 측면에서 빠르다는 장점을 지닌다. P2P(Peer to Peer) 기술은 각각의 클라이언트를 직접 연결하여 실시간 통신을 지원해주는 기술이다. P2P 방식인 만큼, 사용자가 많아질수록 성능이 안 좋아진다는 단점이 있다.
그렇기 때문에 주로 WebRTC는 스트리밍이나 실시간 화상 채팅 서비스에 사용됩니다.
실시간 통신이 최우선인 서비스, 1:1 혹은 소규모 대상 실시간 통신이 중점인 서비스에 적합하다.
참고 자료
SSE 통신(webSocket과 비교)
🌐 Polling / Long Polling / Server Sent Event / WebSocket 정리
실시간 통신 기술
실시간 통신 기술
서버 -> 클라이언트 실시간 통신 방법
