목차
현재 개발중인 FlipMate에서는 오른쪽에 있는 사용자가 학습을 시작했다면 왼쪽에 있는 사용자에게 새로고침이나 페이지 이동을 하지 않더라도 반영이 되어야 한다.
처음에는 당연히 Web Socket을 사용해야 겠다고 생각했다. 클라이언트가 서버에 Socket을 통해 연결이 되어 있어야 이러한 변화에 대해서 서버로부터 응답받을 수 있다고 생각했기 때문이다.
하지만 Web Socket 이전에 Polling 방식으로 요청을 주기적으로 보내는 방법이 있다는 것을 알게 되었다.(사실 이전에도 들었는데 ‘아 이게 이거구나’ 하고 매치가 늦게 됐다...ㅎ)
그리고 동시에, Web Socket이 Polling의 단점을 해결하기 위해 나온 기술이긴 하지만 많은 서비스에서 이 Polling 방식을 계속 사용중이라는 것도 알게 되었다.
많은 글들에서 Web Socket이 Polling보다 우세한 점에만 초점을 맞춰 작성되어 있어서 어떤 상황에서 어떤 기술을 선택하는 게 옳을지에 대한 결론을 내리기가 어려워 이번 기회에 여러 시도들을 해보며 비교해 보려 한다.
polling은 서버로 일정 주기로 요청을 보내고 응답을 보내면 connection을 끊는 방식이다. 이로 인해 바뀐게 없는데도 불필요한 request와 connection을 생성하게 되고, HTTP 프로토콜은 단발성 통신이기 때문에 Header가 다른 프로토콜 대비 무거워서 이 프로토콜이 계속 보내진다면 서버에게 많은 부하를 줄 수 있다.
반면, WebSocket은 처음 연결수립과정(HTTP로 핸드 쉐이킹)을 제외하면 이 소켓을 유지하기 때문에, 클라이언트와 서버가 메시지를 보낼때 매번 connection을 생성할 필요 없이 ws프로토콜의 작은 헤더 크기로 데이터를 주고받을 수 있다.
그래서 위의 정보들을 토대로 아래와 같은 결론을 내리게 되었다.
“HTTP 폴링은 요청의 주기가 짧아질수록 실시간에 가까워지는데 그만큼 불필요한 네트워크 트래픽도 증가하네.. 실시간성이 중요한 서비스는 WebSocket 프로토콜 처럼 Socket이 연결되어 있어야 더 효율적이겠네!”
하지만… 실시간성이 그렇게 중요하지 않은 경우에는 어떨까?