Websocket, long polling

실시간 서비스에 이용되는 websocket protocol을 간단하게 알아보았다.

기존 HTTP protocol에서는 request-response 방식의 mechanism으로 되어 있었다. 이때 실시간으로 서버의 data가 변하는 상황에서는 클라이언트가 이 변동사항을 반영하고자 변화가 생길 때마다 request를 보내면 되겠지만
client입장에서는 언제 server에서 data가 변경되었는지 알 수 없다. 이렇게 실시간으로 변하는 실시간 서비스를 하기 위한 노력들이 있었고 오늘은 그 중 long polling 방식과 websocket을 보게 되었다. 사실 websocket이 궁금했는데 websocket에 관한 설명을 보면 long polling이 빠지지 않고 등장하였다.

long polling

long polling 방식 이전에는 connection 요청이 오면 connection을 유지해야하고, http reqeust를 지속적으로 보내고, 그에 응답하는 response 또한 전달되어야한다. 서버에서는 data의 변화가 없는데 연결이 되어있는 모든 클라이언트가 지속적으로 request를 계속보내오고, 이를 지속적으로response를 해주는 것은 상당히 부담스러운 일이고 overhead가 크게 발생한다.

이러한 상황을 long polling 방식에서는 개선을 시켰다. 매번 request가 올때 마다 response를 하는 것이 아니라 request가 온걸 받아뒀다가, 데이터의 변화가 발생했을 때 response를 해 준다.

websocket

Websockt은 TCP/IP 위의 thin transport layer이다.

client가 server에 request를 보내지 않고도 메세지를 주고받을 수 있게 한다. 이를 위해 Http upgrage header를 보내 WebSocket handshake 과정을 거친 후 connection을 open 상태로 클라이언트와 서버가 메세지를 주고받게 된다.

HTTPS 인 443 포트에서도 종작할 뿐만아니라 proxy같은 중간 서버가 있어도 동작하게 되어 있다.

protocol handshake 예시

client

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket		// websocket 으로
Connection: Upgrade 	// 우리의 연결을 upgrade하자.
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

server

HTTP/1.1 101 Switching Protocols
Upgrade: websocket // websocket으로 
Connection: Upgrade // upgrade 되었음!
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

socket.io

socket.io 는 기존의 실시간 서비스를 위한 long polling, streaming, websocket 방식 중 우선 long polling 방식으로 연결하고 이후 연결된 브라우저에 적합한 방식으로 실시간 연결을 하게 해준다.

websocket 은 연결이 끊어졌을 때, 다시 연결 혹은 다른 방식으로 연결 하는 등의 설정이 필요하고 barebone 에 가깝다면 socket.io는 이러한 설정들을 프로그래머 편의를 위해 제공한다. 프로그래머가 각 기술 polling, streaming, websocket 등을 모르거나 구현 방법을 잘 알지 못해도 사용할 수 있다. (필자의 경험)
단점은 Memory leak 현상들이 발생하곤 한다는 report들이 올라오는데, 변화나 commit이 최근들어 잘 되고있지 않다고 한다.