양방향 통신(polling, long polling, websocket)

Polling

Polling 방식은 간단하게 특정 시간마다 클라이언트에서 서버로 요청을 하며 응답을 통해 데이터를 갱신합니다. 즉, 아무런 server의 event 가 발생하지 않더라도 모든 클라이언트는 지속적으로 server에게 XMLHttpRequest를 보내게 됩니다. 또한 실시간으로 메시지 전달이 필요한 경우 요청을 보내는 주기가 짧아질 것입니다. 이는 서버의 불필요한 트래픽이 발생합니다.

매 주기마다 서버는 Request의 Header parser 하며, query를 통해 새로운 데이터에 대한 응답을 생성해서 보낼 것입니다. 그 후 서버는 모든 리소스에 대한 정리 작업도 진행해야 할 것입니다.

 

Long Polling

기존 양방향 통신으로 사용되는 polling 방식보다 효율적인 방식의 기법입니다.

서버에 주기적으로 요청을 보내는 방식이 아닌 서버에서 클라이언트의 연결을 Keep Alive 헤더를 통해 유지하는 방식입니다.

동작 방식

• 우선 Client는 Server로 Keep Alive 헤더를 포함한 GET request를 보내며 응답을 받을 때까지 연결을 유지합니다.
• Server의 Event 가 발생 시 Client의 GET request에 대해서 응답을 보내게 됩니다.
• 응답을 받은 Client는 다시 동일한 GET request를 보내며 다음 응답을 기다립니다.

확실히 Server Event 발생 시에만 XMLHttpRequest 가 발생하며 불필요한 트래픽이 발생하지 않으며 실시간 메시지 전달이 가능합니다.

 

단점

하지만 주기적으로 데이터들을 한 번에 보내는 polling과 달리 Server Event 시마다 Server의 응답, Client의 GET 요청이 발생합니다. 당연히 서버는 동일하게 HTTP request의 header parser 작업과 응답 객체의 생성 작업을 거칩니다. 즉, 실시간으로 잦은 서버 상태 변경의 요청 즉 caching 되지 않는 request 통신이 이루어지는 경우 polling 보다 더 많은 트래픽이 발생할 수 있습니다.

추가적으로 relative message order의 문제점도 존재합니다.

동일한 서버 리소스를 사용하는 클라이언트가 다중 탭으로 동일한 요청을 보내고 해당 요청에 대해서 서버가 Database 작업을 수행한다면 중복 데이터가 2번 저장 혹은 갱신되게 됩니다.

 

또한 서버의 구현에 따라 클라이언트 인스턴스가 메시지 수신을 전혀 하지 못하는 경우가 있습니다. Server event 가 발생하여 응답을 보냈으나 네트워크, 브라우저의 문제 등의 경우로 누락된 경우 Client 가 정상적으로 응답받은 것을 확인하지 못하게 될 것입니다. Client 역시 응답이 중간에 누락된 것을 확인하지 못하고 더 이상 server 와의 통신이 이루어질 수 없을 것입니다.

 

Websocket

동작 방식

websocket 은 기존의 http protocol 요청을 사용한 양방향 통신(클라이언트가 요청이 없으면 서버에게 응답을 받을 수 없는 구조)을 문제를 해결하기 위해 나온 transport protocol입니다.

처음 서버와 클라이언트 간 http protocol 요청을 통해 handshake 과정을 거칩니다. 웹소켓 연결이 가능함을 handshake 과정에서 판단되면 서버와 클라이언트는 ws protocol로 데이터를 전송할 수 있습니다. 이때 데이터 전송에서 기존 http protocol 양방향 통신 방식의 문제 중 하나인 request header 정보로 인한 불필요한 overhead 가 적습니다.

 

단점

• 우선 2011 년 이전의 브라우저는 지원하지 않는 단점이 있습니다.
• stateful protocol 이므로 연결의 종료에 대해서 서버에서 적절한 대처가 있어야 합니다.
• 소켓을 연결을 유지하는 것만으로 비용이 듭니다. 실시간으로 통신을 유지해야 하는 경우가 아니라면 http protocol 방식이 유용할 것입니다.

Socket.io

websocket의 추가적인 단점은 개발의 피로도입니다. 이러한 피로도를 줄여주는 라이브러리가 Socket.io 입니다. Socket.io How it works 글을 읽어보면 기본 Client와 Server의 연결 방식의 설정은 long polling 방식입니다. 그러한 이유는 Websocket 방식은 브라우저 버전, 프락시, 개인 방화벽, 바이러스 백신 소프트웨어로 인해 항상 연결이 가능한 것은 아닙니다. 그 후 Websocket upgrade 가 가능하다면 Websocket 방식을 사용합니다.

이 글의 내용을 확인해 봤을 때 Socket.io 라이브러리는 Websocket 방식의 fallback으로 long polling 방식을 사용하고 있습니다. 하지만 long polling 방식은 위에서 확인한 것과 같이 단점이 존재하며 그것은 Websocket 방식 역시 마찬가지입니다.

마지막으로 필자의 생각입니다. 아직 각 양방향 통신의 단점을 완전히 해결할 수 있는 방식이 나오지 않았고 가능한지도 짐작할 수 없습니다. 현재로서는 구현하고 있는 서비스에 대한 알맞은 통신 방식을 선정하여 Socket.io fallback 설정을 하는 것을 생각해봐야 할 것 같습니다.