WebSocket이란?
WebSocket이란 Transport protocol의 일종으로 쉽게 이야기하면 웹버전의 TCP 또는 Socket (소켓)이라고 이해하시면 됩니다. WebSocket은 서버와 클라이언트 간에 socket connection을 유지해서 언제든 양방향 통신 또는 데이터 전송이 가능하도록 하는 기술이며 2008년에 HTML5에 포함이 되어서 여러 번의 토론을 통해 프로토콜이 제정되었고 2009년 구글 크롬을 시작으로 여러 웹브라우저에서 이 기술을 적용하여서 현재 Real-time web application 구현을 위해 널리 사용되어지고 있습니다. 참고로 Real-time web application이란 서버 쪽 또는 클라이언트 쪽 데이터가 실시간으로 업데이트 되는 웹 어플리케이션을 의미합니다.왜 사용하는가요?
WebSocket을 사용하는 이유 또는 사용시 얻을 수 있는 장점에 대해서 이해를 하려면 WebSocket 이전에 사용되었던 기술과 어떤 차별성이 있는지를 이해하는게 중요합니다. 우선 웹어플리케이션에서 기존의 서버와 클라이언트 간의 통신은 대부분 HTTP를 통해 이루어 졌으며 HTTP는 Request/Response 기반의Stateless protocol입니다. 무슨 말이냐 하면 서버와 클라이언트 간의 Socket connection 같은 영구적인 연결이 되어 있지 않고 클라이언트 쪽에서 (예를 들어 웹브라우저 쪽에서) 필요할 때 Request를 할 때만 서버가 Response를 하는 방식으로 통신이 진행되는 프로토콜이란 뜻입니다. (짧게 이야기하면 클라이언트 쪽에서만 대화를 시작할 수 있는 한 방향 통신입니다.) 그래서 어떤 문제가 생기냐면 서버 쪽 데이터가 업데이트 되더라도 클라이언트 쪽 (예를 들어 웹페이지)에는 화면을 Refresh 하지 않는 한 바뀐 데이터가 업데이트가 되지 않는 문제가 발생합니다. 그렇지만 이런 문제는 일반적은 웹 어플리케이션에서는 기존에 있던 임시 방편인 Long polling 이라던가 Ajax를 사용해도 어느 정도 해결이 가능하지만 데이터의 빠른 업데이트가 아주 중요한 요소 중에 하나인 어플리케이션 (예를 들어 주식 관련 사이트라던가 비디오 채팅 어플리케이션)에서는 실시간 업데이트가 아주 중요하기 때문에 (그리고 기존의 Long Polling 같은 기술은 서버에 많은 부담을 주는 부작용이 있기 때문에) WebSocket이 아주 유용하고 중요한 기술로 사용되고 있습니다.
또한 WebSocket은 Stateful protocol이기 때문에 클라이언트와 한 번 연결이 되면 계속 같은 라인을 사용해서 통신을 하기 때문에 HTTP 사용 시 필요없이 발생되는 HTTP와 TCP 연결 트래픽을 피할 수 있습니다. 마지막으로 WebSocket은 HTTP와 같은 포트 (80)을 사용하기 때문에 (Secure한 채널 같은 경우에는 HTTPS와 같은 443을 이용) 기업용 어플리케이션에 적용할 때 방화벽을 재설정하지 않아도 되는 장점도 있습니다. (대부분의 기업 방화벽은 외부에서의 접속은 HTTP나 HTTPS만을 기본으로
허용하고 있으며 만약 이외의 포트를 허용해야 할 경우에는 방화벽의 설정을 수정해야 하는데 큰 회사일 수록 방화벽 설정 수정 절차가 복잡하기 때문에 HTTP와 같은 포트를 사용한다는 점이 꽤 큰 장점이 될 수도 있습니다.)
작동 원리 및 그 외의 정보
우선 서버와 클라이언트 간의 WebSocket 연결은 HTTP 프로토콜을 통해 이루어집니다. 만약 연결이 정상적으로 이루어진다면 서버와 클라이언트 간에 WebSocket 연결 (TCP/IP 기반으로 하는)이 이루어지고 일정 시간이 지나면 HTTP 연결은 자동으로 끊어집니다.기본적으로 WebSocket API는 아주 간단한 기능들만을 제공하기 때문에 대부분의 경우 SockJS나 Socket.IO 같은 오픈 소스 라이브러리를 많이 사용하고 있으며 메세지 포멧 또한 STOMP 같은 프로토콜을 같이 이용합니다. 마지막으로 스프링 프레임워크도 WebSocket을 간단한 메세지 브로커랑 SockJS 그리고 STOMP와 같이 지원하고 있습니다.
WebSocket 사용의 어려운 점
WebSocket은 사용시 위에 서술한 것과 같은 장점들을 주지만 그에 못지 않는 비용을 지불해야 합니다. 아래는 WebSocket 사용 시 발생할 수 있는 어려운 점 또는 문제점들입니다.1. 프로그램 구현에 보다 많은 복잡성 초래: WebSocket은 HTTP와 달리 Stateful protocol이기 때문에 서버와 클라이언트 간의 연결을 항상 유지해야 하며 만약 바정상적으로 연결이 끊어졌을 때 적절하게 대응해야 합니다. 이는 기존의 HTTP 사용 시와 비교했을 때 코딩의 복잡성을 가중시키는 요인이 될 수 있습니다.
2. 서버와 클라이언트 간의 Socket 연결을 유지한다는 것 자체가 비용이 드는 일입니다. 특히나 트래픽양이 많은 서버 같은 경우에는 CPU에 큰 부담이 될 수 있습니다.
3. 오래된 버전의 웹 브라우저에서는 지원하지 않습니다. (물론 SockJS 라이브러리 같은 경우에는 Fallback option을 제공하고 있습니다.) 참고로 인터넷 익스플로어 같은 경우에는 10 버전부터 지원합니다.
4. 이건 제 개인적인 경험인데 서버와 클라이언트 간의 연결이 끊어졌을 때 생성되는 에러 메세지가 구체적이지 않아서 (예를 들어 여러가지 다른 이유로 연결이 끊어졌는데 에러 메세지가 같은 경우) 디버깅을 하는데 어려움이 많았습니다.
아무리 좋은 기술이라 할지라도 모든 경우에 유용할 수는 없는 법이기 때문에 프로그램에 꼭 필요한 기술인지 잘 체크하고 수용 여부를 결정하는 것이 바람직합니다.
대표적인 사용예
1. 페이스북 같은 SNS 어플리케이션2. LOL 같은 멀티플레이어 게임들
3. 구글 Doc 같이 여러 명이 동시 접속해서 수정할 수 있는 Tool
4. 클릭 동향 분석 데이터 어플 (특정 시간동안 어느 사이트에 주로 접속했는지 등의 정보를 파악하는 어플)
5. 증권 거래 정보 사이트 및 어플
6. 스포츠 업데이트 정보 사이트 및 어플
7. 화상 채팅 어플
8. 위치 기반 어플
9. 온라인 교육 사이트 및 어플
References
https://www.websocket.org/aboutwebsocket.htmlhttp://www.javaworld.com/article/2071232/java-app-dev/9-killer-uses-for-websockets.html
https://en.wikipedia.org/wiki/WebSocket
https://samsaffron.com/archive/2015/12/29/websockets-caution-required
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
