[Socket.io] Socket.io란 무엇인가?

 

이번 프로젝트에서 메시지 기능을 추가하기로 했는데, 

 

이것저것 살펴보니 양방향 통신을 위해서는 http 프로토콜이 아닌 WebSocket이라는 통신 프로토콜을 이용해야 한다고 한다. 

 

http 통신의 특징 중 하나가 stateless 이기 때문에 클라이언트가 서버에게 데이터를 요청을 하기 이전에 서버가 클라이언트에게 데이터를 주는 게 다소 어렵기 때문이다. 

 

---

 

WebSocket은 미완의 기술?

 

그래서 WebSocket에 대해 이것저것 살펴봤는데 naver D2 블로그에서 흥미로운 글을 읽었다. 

 

바로 WebSocket이 미완의 기술이라는 점!

 

지금은 많은 개발자들의 요청으로 대부분의 웹 브라우저에서 WebSocket 통신이 가능하게 해두고 있지만 (무려 97%라고 한다) 이전에는 웹 브라우저에서 WebSocket 통신이 기본 설정으로는 사용하지 못하게끔 막아뒀다고 한다. 

 

아무래도 클라이언트의 요청없이 서버에서 데이터를 넘겨줄 수 있다 보니 보안상의 심각한 문제가 있었나 보다. 

 

입 벌려 바이러스 들어간다...

 

따라서 아직까지 WebSocket은 미래의 기술이라고 블로그에는 기록되어 있었다. 

 

---

 

Socket.io === Websocket?

 

Socket.io는 node.js 개발자들이 양방향 통신을 위해서 주로 사용하는 라이브러리인데, 

 

높은 확장성과 간편한 사용방법 때문에 많은 사람들이 애용하고 있다. 

 

그렇다면 Socket.io는 어떻게 동작하는 것일까?

 

일단 기본적으로 Socket.io는 WebSocket 통신을 이용한다. 

 

문제는 3%의 웹 브라우저들은 WebSocket 통신을 지원하고 있지 않다는 점이다.

 

여기서 Socket.io의 편의성이 빛을 보게 되는데, Socket.io는 실행 전 웹브라우저가 WebSocket 통신이 가능한지 아닌지 체크한다. 

 

만약 WebSocket 통신이 불가능한 웹브라우저일 경우, Socket.io는 Long-Polling 방식으로 양방향 통신을 시도한다. 

 

 

 

The client will try to establish a WebSocket connection if possible, and will fall back on HTTP long polling if not.

 

 

---

Long-Polling

여기서 Long-Polling이란 http 프로토콜을 이용해 양방향 통신을 가능하도록 하는 통신방식을 말한다. 

 

WebSocket 이외에도 http를 이용한 양방향통신 구현 노력은 있었다. 

 

크게 세가지로 나뉘는데 아래와 같다. 

• Polling
• Long-Polling
• Stream

하지만 위 세가지 방식도 엄밀히 따지면 양방향 통신이 아니다. http 프로토콜의 태생적 구조 때문이다. Stateless 한 http 프로토콜에서는 클라이언트의 요청 없이 서버에서 데이터를 보내는 게 불가능했기 때문이다. 

 

따라서 위 세가지의 기본적인 접근법은 "클라이언트가 지속적으로 데이터 요청을 보내 마치 양방향 통신이 이루어지듯이 구현하는 것"이다. 

 

우선 Polling의 대략적인 설명은 아래와 같다. 

 

클라이언트는 계속해서 서버에 요청을 보낸다. 이때 서버는 요청을 받는 즉시 response를 클라이언트에게 보낸다. 

만약 클라이언트에 업데이트가 있는 경우라면, 클라이언트는 업데이트된 데이터를 받게 되는 방식이다. 

위 세가지 방법 중에서 가장 단순 무식한 방법이라고 볼 수 있다. 불필요한 트래픽이 많이 발생하게 되며 서버에 과도한 부담을 주게 되어 polling방식의 최대 문제점으로 꼽힌다. 

 

따라서 polling 방식은 요청 주기를 조금 길게 두기 때문에 실시간 통신에서는 이용하기 어렵다.  

 

이중 Socket.io가 활용하는 Long-Polling 방식은 Polling 방식이 가지고 있는 문제점을 해결하기 위한 방식이다. 

클라이언트는 polling과 마찬가지로 지속적인 요청을 보낸다는 점에서는 동일하지만, 위 이미지에서 보듯이 요청과 회신에 일정 텀이 주어진다. 즉, 요청을 받고 서버에서는 즉시 답을 하지 않고 일정 시간을 기다렸다가 회신을 보내는 방식이다. 

 

이렇게 되면 polling 방식 보다 불필요한 트래픽이 줄어드는 이점이 있지만, 여전히 단점이 남아있다. 

 

1:1 통신이나 10명 이하의 통신의 경우는 문제가 없지만 만약 수많은 사람들이 수많은 인터렉션을 하면

서버는 엄청나게 과도한 부담을 안게 된다. 

 

왜 그럴까?

 

Long Polling 방식은 이벤트가 발생하면 response를 보내는 방식이다. 그렇기 때문에 순간적으로 많은 이벤트가 발생하는 response를 보내고 또다시 request를 받기 때문에 queue가 순간적으로 쌓이게 되며 서버가 부담을 가지게 되는 것이다.