자료 저장소

웹소켓(WebSocket) 

웹소켓은 단일 TCP 연결을 통해 전이중 통신 채널을 제공하는 통신 프로토콜이다.

웹소켓 프로토콜은 2011년 IETF에서 RFC 6455로 표준화되었고, Web IDL의 웹소켓 API는 W3C에서 표준화 되었다.

만들어진 배경

전형적인 브라우저 렌더링 방식은 HTTP 요청(HTTP Request)에 대한 HTTP 응답(HTTP Response)을 받아서 브라우저의 화면을 깨끗하게 지우고 받은 내용을 새로 표시하는 방식이다. 내용을 지우고 다시 그리면 브라우저의 깜빡임이 생기게 된다. 이러한 깜빡임 없이 원하는 부분만 다시 그리며 실시간으로 사용자와 상호작용하는 방식이 나타나고 사용자와 상호작용하는 웹 서비스를 선호하는 사용자가 증가하면서 RIA(Rich Internet Application) 기술의 발달이 촉진되었다.

상호작용하는 웹 서비스를 위해 숨겨진 프레임(Hidden Frame)을 이용한 방법이나 Long Polling, Stream 등 다양한 방법을 사용했다. 그러나 이러한 방식은 브라우저가 HTTP 요청를 보내고 웹 서버가 이 요청에 대한 HTTP 응답를 보내는 단방향 메세지 교환 '규칙'을 변경하지 않고 구현한 방식이다. 그렇기 때문에 상호작용하는 웹 페이지를 복잡하고 어려운 코드로 구현해야 했다.

보다 쉽게 상호작용하는 웹 페이지를 만들려면 브라우저와 웹 서버 사이에 더 자유로운 양방향 메시지 송수신(bi-directional full-duplex communication)이 필요하다. 그래서 HTML5 표준안의 일부로 WebSocket API(이후 WebSocket)가 등장했다.

• 폴링 (Polling)

클라이언트가 HTTP Request를 서버로 계속 날려서 이벤트 내용을 전달 받는 방식이다. 계속적인 요청으로 인해 서버에 부담이 급증하고, 잦은 connection 연결/해제로 부담이 많은 방식이다.

• 롱 폴링 (Long Polling)

클라이언트에서 서버로 HTTP Request를 날리고 계속 대기하고, 서버에서 해당 클라이언트로 전달할 이벤트가 있다면 그 순간 응답 메시지를 전달하면서 연결이 종료하는 것을 반복 하는 방식이다. 기존 폴링의 Long Term을 적용한 방식이다. 이벤트 간격이 좁아지면 결국 폴링과 동일한 문제가 발생한다. 다수의 클라이언트에게 동시에 이벤트가 발생될 경우에도 서버에 많은 부담이 발생한다.

• 스트리밍 (Streaming)

롱 폴링과 마찬가지로 클라이언트에서 서버로 일단 HTTP Reqeust를 날리고, 서버에서 클라이언트로 이벤트를 전달할 때 해당 요청을 끊지 않고 필요한 메시지만 보내기를(flush) 반복하는 방식이다. 

웹소켓을 사용하는 이유

실시간으로 사용자와 상호작용하는 웹 서비스가 일반화되어 클라이언트와 서버간에 부하를 줄이기 위해서 실시간 업데이트가 필요한 웹 서비스에 사용된다. 웹소켓은 최초 HTTP를 이용해 접속 확립후에 독자 프로토콜을 통해 양방향 통신이 이루어 진다. 또한 Header 프레임 크기가 작아서 오버헤드가 적다. 장시간 연결을 전제로 하기 때문에, 접속한 상태에서 양방향 통신이 가능하고 하나의 connection으로 데이터 송수신이 가능하다.

다음과 같은 경우 웹소켓을 사용할 수 있다.

• 실시간 양방향 데이터 통신이 필요한 경우
• 많은 수의 동시 접속자를 수용해야 하는 경우
• 브라우저에서 TCP 기반의 통신으로 확장해야 하는 경우
• 개발자에게 사용하기 쉬운 API가 필요할 경우
• 클라우드 환경이나 웹을 넘어 SOA 로 확장해야 하는 경우

참고 

http://d2.naver.com/helloworld/1336

http://adrenal.tistory.com/20

http://utk-unm.blogspot.kr/2016/10/websocket.html

http://cafe.naver.com/hermeneus/47