1. 개요

요즘  WebSocket(웹소켓)이라는 단어를 많이 들을 수 있다. 대체 WebSocket이 무엇일까?


2. 역사 

WebSocket은 HTTP의 단점을 보완하기 위하여 등장했다. 1991년 발표된 HyperText Transfer Protocol인 HTTP는 오랜 시간 우리 곁에 있었다. 우리의 브라우저 창에는 늘 http:// 가 따라 붙고 있으니 말이다.

그러나, 이 오랜 시간 사용된 HTTP는 Client-Server간 접속을 유지하지 않으며, Client-Server간 한 번에 한 방향으로만 통신이 가능한 half-duplex이다.

점차 서로간 주고받는 데이터의 량이 많아지면서 half-duplex로 인한 성능 저하는 피할 수 없게 되었다.

또한 HTTP는 지나치게 많은 헤더 데이터를 가지고 있다. 특히 Client(브라우저)가 요청을 보내지 않아도 Server가 데이터를 보내주는 기능의 구현에 있어서는 많은 고민이 있어왔지만 HTTP의 근본적 메커니즘 탓에 한계가 있어왔다. (Polling, Long Polling 등) 그래서 HTML5에 이 WebSocket이 포함되었다. 이름처럼, 이  WebSocket을 사용하면 더 이상 ActiveX를 사용하지 않고도 TCP/IP 소켓통신을 구현할 수 있다. 또한 네트워크의 과부하를 줄이고 애플리케이션의 반응성을 높일 수 있게 된다.

앞서 말한 HTTP 헤더 크기 문제도 800byte에서 수 kbyte의 헤더 크기를 가지고 있는 HTTP와 달리 WebSocket은 수 byte 수준으로 압축이 가능하다.

물론 WebScoekt이 HTTP를 대체하는 것은 아니다. 다만 HTTP가 적합치 않은 메세징, 트랜잭션 및 애플리케이션 특성 상 트래픽이 높고 지연시간이 낮은 환경에서 유용하다. RMI(Rremote Method Invocation), JMS(Java Messaging Service), XMPP(Extensible Messaging and Presence Protocol) 등이 그 예이다.


3. 특징

사용자는 WebSocket을 사용할 수 있는지 서버에 묻고 HTTP 연결을 WebSocket으로 업그레이드(upgrade) 시도한다. 서버가 WebSocket으로 하겠다고 응답하면 이제부터 WebSocket 프로토콜로 통신된다.

3.1. 장점

Polling과 같은 불필요한 요청 없이 처리 가능하다.

3.2. 단점

코드 수준의 관리가 어렵고, 이벤트 리스너 / 이벤트 함수를 등록하여 사용해야 한다. 


4. 지원

  • WebSocket 클라이언트는 다음과 같은 6개 API를 사용한다.
  • onopen : WebSocket 열리면 호출
  • onmessage : 메시지 도착하면 호출
  • onerror : 에러 발생하면 호출
  • onclose : WebSocket 닫히면 호출
  • send : 메시지 전송
  • close : WebSocket 닫기

현재 주요 브라우저 별 WebSocket 지원여부는 아래와 같다. (최신 브라우저는 대개 지원함)

  • IE : 11.0
  • IE Mobile : 10.0
  • Firefox : 29.0 ~
  • Chrome : 34.0 ~
  • Safari : 7.0
  • iOS Safari : 7.0 

WebSocket은 http://www.websocket.org/echo.html 에서 체험해 볼 수 있다.


5. 드래프트 버전

초기 WebSocket 드래프트 버전은 JSR-356으로 표준화되었다. 단 이 과정에서 컨테이너 변경 시 코드의 변경 등이 동반되어야 한다. 예를 들어 Jetty 8 기반으로 WebSocket 기능을 구현했다면 Jetty 9 에서는 다른 방식으로 구현해야 할 것이다.