다중 채팅 솔루션에서 웹소켓(Web Socket) 구현 방안

    일반적으로 채팅을 개발하기 위해서 가장 많이 사용하는 방식이 바로 웹소켓(Web Socket)일 것이다. 그러나 사이트에서 프로젝트를 하거나 혹은 취미로 프로젝트를 할 때 인터넷에 떠돌아 다니는 웹소켓 채팅 솔루션을 적용하다보면 난관에 부딪힐때가 있다.

     

    대부분 채팅 + 웹소켓에 관해서 포스팅한 내용들은 완성된 프로젝트 형태가 아니라 PoC 기반의 컨셉을 구현한 경우만 많기 때문에 실제 프로젝트 코드랑 괴리감이 존재한다. 그럼 웹소켓의 차이점이 무엇인지 단점이 무엇인지 알아봐야 할 것이다.

     

    웹소켓과 HTTP Polling 방법

    폴링 방식과 웹소켓 방식의 비교

     

    일반적으로 HTTP 4 이하 기반의 웹 형태로 채팅 시스템을 구현하려면, 윗방법과 같이 폴링(Polling)하는 방법을 사용할 것이다. 주기적으로 채팅서버에 새로운 대화가 있는지 찾아보고 대화가 있다면 가져오는 방식으로 실시간으로 처리를 하려면, 그만큼 더 많은 부하가 존재할 수 있다.

     

    반대로 HTTP 5에서 지원하는 웹소켓으로 채팅 시스템을 구현하는 방법은 매우 효율적이다. 웹소켓으로 서로간에 연결하여 대화를 하면 되는 방식이다. A라는 사람이 대화를 시작하면 웹소켓을 구현한 서버에서 A와 대화를 하는 B와 연결을 해줘서 B는 폴링을 하지 않고 대화를 받을 수 있게 된다.

     

     

    여기까지보면 매우 효율적이고 좋아보이기만 하지만 치명적인 단점이 있다.

     

    웹소켓의 단점

    웹소켓의 단점인 세션 처리 문제

    웹소켓은 브라우저에서 채팅서버에 직접 연결을 시도하는 형태를 가지고 있다. 그러다보니 페이지를 갱신하게 되면 연결이 끊어지고, 다시 연결을 하는 형태를 가진다. 이러다보니 F5번을 눌러서 페이지를 습관적으로 갱신하게 된다면 세션이 끊어지고 다시 연결해야 되는 상황을 맞이할 수 있으며 더 큰문제는 웹소켓의 세션과 HTTP 세션이 서로 다르다는 것이다.

     

    그러다보니, 주기적으로 웹소켓의 세션과 서버에서 저장하는 HTTP 세션을 동기화하는 모듈을 별도로 구현해야 한다. 이게 생각보다 짜증이 나서 어쩔때는 그냥 풀링 방식으로 모든 것을 구현하고 싶은 욕구가 치밀 때가 있을 것이다.(사실 풀링 방식이 더 편할때가 많다)

     

     

    댓글

    Designed by JB FACTORY