실시간 통신 서비스를 구현할 때 보통 실시간 통신 layer 에서 사용할 방법을 선택하게 된다.
보편적으로 선택가능한 WebSocket 과 HTTP Long Polling 두가지가 있다.
각각의 특징에 대해서 알아보자.
Long Polling
HTTP 프로토콜을 기반으로 한 기술이다.
http 통신은 stateless 이다.
즉 요청을 보내고 응답을 받으면 끝인데, 이 방식으로는 실시간 통신에 대한 지원이 쉽지않다.
Long Polling 은 약간의 꼼수로 실시간 통신인 것 처럼 지원을 한다.
단순하게 살펴보면 아래와 같이 동작한다.
- client 는 서버에 요청을 한다.
- server 는 client 에 즉시 응답하지 않고 connection 을 열어둔 상태로 대기한다.
- client 에 update 할 정보가 생기면 그때 서버는 reponpse 를 전송한다.
- client 는 server 에서 온 정보를 처리하고 다시 요청을 하고 응답을 대기한다.
1-4 번의 동작을 계속 반복하면 실시간 통신인 것 처럼 동작하는 서비스를 구현할 수 있다.
다만 위 Long Polling 방식에는 몇가지 문제점이 있다.
비효율적인 리소스 사용
HTTP 프로토콜을 사용하기 때문에 매 데이터 전송시 항상 handshake 과정을 거치게 된다.
또 매번 데이터 전송 시 header 정보가 항상 포함된다.
메시지 순서 보장이 어려움
여러 개의 독립적인 HTTP 요청과 응답으로 이루어지기 때문에, 메시지의 순서를 보장하기 어렵다.
websocket 은 위와 같은 문제를 해결할 수 있는 프로토콜이다.
WebSocket
Long Polling 은 HTTP 기반의 기술이지만,
WebSocket 은 TCP 기반의 독립적인 프로토콜이다.
특히 WebSocket은 실시간, 양방향 통신을 제공하기 위해 설계되었기 때문에 long polling 대비 장점이 있다.
연결을 수립하는 방식이 조금 독특하다.
- Upgrade 헤더와 함께 http get request 를 보낸다.
- 서버에서 응답이 오면 websocket 프로토콜로 전환한다.
Websocket 은 하나의 socket 으로 양방향 통신을 하기 때문에 long polling 대비 아래와 같은 장점이 있다.
- 자체적인 프로토콜을 사용한다. http 보다 더 간결하게 데이터를 전송할 수 있도록 frame 이라는 단위를 사용하는데 불필요한 정보가 많이 줄어서 효율적이다.
- 매번 연결할 필요가 없다.
- 메세지 순서보장 단일 연결을 통해 데이터가 순차적으로 전송되므로 메시지의 순서가 보장된다.
보다시피 Websocket 이 우월하다.
그래서 현재는 long polling 은 아주 오래된 브라우저를 지원하기 위해 사용되고
왠만한 실시간 기능은 websocket 을 사용한다.