WebSocket?

웹소켓이란?

웹소켓(WebSocket) 프로토콜은 클라이언트와 서버 간의 신속하고 보안이 유지된 양방향 통신을 위한 메커니즘입니다. 웹소켓이라는 단어가 우리에게 더 이상 낯설지 않을 정도로, 웹소켓은 실시간 웹 애플리케이션 구현을 위해 널리 사용됩니다. 서버와 클라이언트 간에 Socket 연결을 유지함으로써 양방향 통신 및 데이터 전송이 가능하도록 하는 기술로 작동 원리에 대해서는 다음 포스트에서 다루도록 하겠습니다. 

 

웹소켓은 HTTP 위에서 동작하는 HTML5의 표준으로, 아래와 같은 특징을 가집니다. 

• 실시간 양방향 통신(full-duplex)
• 80 / 443 포트를 사용 => 추가로 방화벽을 열거나, CORS(Cross Origin Resource Sharing) 적용 혹은 인증 등의 과정을 변경할 필요가 없음
• URL scheme : ws, wss(SSL) 사용
• UTF-8 인코딩을 따름
• 헤더가 상당히 작기 때문에 HTTP 통신에 비해 오버헤드가 적음
• 연결이 살아있는지 Ping/Pong으로 확인  

 

단, 유의해야 할 점은 모든 브라우저가 웹소켓을 지원하는 것은 아니라는 것입니다. 또한 현재 웹소켓을 지원하는 브라우저라고 할지라도 구버전의 경우 웹소켓이 지원되지 않는 경우도 많습니다. 

• Green : Full Supported
• Light Green : Partial Supported
• Red : Not Supported

 

최근에는 대부분의 브라우저가 웹소켓을 지원하게 되었지만, 국내의 경우 구버전의 웹브라우저를 지원해야 하는 경우가 많습니다. 웹소켓으로 만들어진 화면은 이를 지원하지 않는 구버전의 브라우저에서는 동작하지 않기 때문에 이를 유념하여 사용하여야 합니다. 

등장 배경

웹소켓은 웹의 실시간 양방향 통신을 위해 개발되었으며, 기존의 양방향 통신 방법의 단점으로 인해 등장하게 되었습니다. 웹소켓을 좀 더 잘 이해하기 위해서 어떠한 흐름으로 웹소켓이 등장하게 되었는지 간단히 살펴보도록 하겠습니다. 

 

우리가 사용하는 웹브라우저들은 HTTP 프로토콜을 기반으로 동작하며, 요청에 대한 응답을 화면에 렌더링 하는 방식으로 동작합니다. HTTP는 클라이언트-서버 간의 접속을 유지하지 않으며, 한 번에 한 방향으로만 통신이 가능한 half-duplex(단방향 통신)이기 때문에, Connection이 유지되지 않아 실시간으로 통신할 수 없습니다. 그런데 이러한 전형적인 브라우저의 렌더링 방식은 당연하게도 화면상에서 깜빡임이 발생합니다. 화면을 전부 지우고 다시 그리는 방식이기 때문입니다. 이러한 불편을 해결하기 위해서 RIA(Rich Internet Applicaion) 기술이 발달하기 시작했고, 아래와 같은 방법들이 시도되었습니다. 

폴링(Polling)

클라이언트가 서버로 주기적으로 요청을 날려 새로운 이벤트가 있는지 확인합니다. 구현하기 쉬우나 클라이언트가 계속 요청을 날리기 때문에 서버의 부담이 큽니다. HTTP  요청에 대한 응답을 받는 것은 동일하기 때문에 실시간 정도의 빠른 응답을 주지 못합니다. 또 서버에서 갱신된 데이터가 없음에도 불구하고 지속적으로 요청을 전송한다는 단점도 있습니다. 

롱 폴링(Long Polling)

클라이언트가 서버로 요청을 보내는 것은 폴링과 동일하나, 이벤트 내용이 있을 때까지 기다렸다가 응답을 보냅니다. 응답을 받은 클라이언트는 곧바로 다시 요청을 보내, 커넥션을 연결시킵니다. 

폴링에 비해 요청량이 줄어들어 서버의 부담이 줄어들지만, 이벤트가 많이 발생하여 시간 간격이 좁아지면 폴링과 큰 차이가 없게 됩니다. 또한 다수의 클라이언트에게 동시에 이벤트가 발생되면, 이 클라이언트 다수가 동시에 서버로 접속을 시도하기 때문에 마찬가지로 서버의 부담이 커집니다. 

스트리밍(Streaming)

클라이언트가 서버로 요청을 보내 커넥션을 맺은 후, 이벤트가 발생해도 서버는 이 커넥션을 끊지 않고 계속 flush 합니다. 이벤트가 많이 혹은 자주 발생하는 경우 폴링과 롱 폴링보다 매우 효율적이나, 연결의 유효성 관리 등의 부담이 발생합니다.  

 

폴링, 롱 폴링, 스트림 모두 HTTP의 단방향 통신 규칙을 변경하지 않고 구현한 방식입니다. 이렇게 웹소켓 이전의 HTTP 실시간 통신 방법을 Comet이라고 통칭하며, Comet 방식은 데이터 전송 과정에서 불필요한 많은 양의 네트워크 오버헤드를 발생시키며, 연결 대기 시간에 따른 성능 저하도 추가로 발생합니다. Comet 방식에는 우리가 익히 아는 Ajax, iframe, DHTML 등이 포함됩니다. 

 

웹소켓(WebSocket)

기존의 요청-응답 방식과 동일하게 최초 접속은 HTTP 요청을 통해 이루어집니다. 단, 80 포트로 HandShake 한 후 ws로 프로토콜을 변환해서 커넥션을 맺는다는 차이점이 있습니다. 이는 기존의 일반 TCP Socket과도 다른 점입니다. 즉, 결정적으로 앞선 방식들과 웹소켓의 결정적인 차이는 프로토콜입니다. 웹소켓을 접속하는 데 있어서는 HTTP를 사용하지만, 연결된 이후의 통신은 웹소켓 프로토콜을 통해 이루어지게 됩니다. TCP의 소켓을 사용하는 것처럼 양방향 통신이 가능하고, Comet에 비해 속도가 더 빠르고, 요청을 덜 생성하며, 대역폭을 덜 소비합니다. 

 

그렇다고 웹소켓이 만능인 것은 아닙니다. 웹소켓을 사용하는 것은 많은 장점을 가지고 있지만, 그에 못지않은 비용 역시 발생합니다. 웹소켓을 사용할 경우 발생할 수 있는 문제점은 아래와 같습니다. 

• 웹소켓을 지원하지 않는 브라우저 존재 => 부차적으로 Comet 모델을 지원하도록 만드는 것이 좋습니다.
• HTTP와 달리 Stateful 한 프로토콜이므로 연결을 항상 유지해야 하며, 비정상적으로 연결이 끊겼을 때에 대한 대응이 필요
• 기존 방식과 비교해 개발 복잡도 증가
• Socket 연결을 유지하는 자체가 비용 발생
  
  

여기까지 웹소켓이란 무엇인지, 어떻게 등장하게 되었는지 알아보았습니다. 다음 글에서 웹소켓의 동작이 어떻게 이루어지는지 살펴보도록 하겠습니다.