[네트워크] 웹 소켓(Web Socket)

웹 개발을 할 시, 서버와 클라이언트의 통신이 HTTP 프로토콜로 이루어지는 것은 맞다.

하지만, 채팅, 게임, 주식 차트 등의 실시간 통신이 필요한 서비스를 구현하고자 할 때 HTTP 프로토콜이 아닌 웹소켓 프로토콜이 더 좋다는 이야기를 접할 수 있다.

 

1. HTTP의 한계

HTTP는 사용자가 URL을 요청할 때에만 서버에서 해당 페이지를 꺼내주는 방식이다.

다시 말하자면, 사용자는 서버로부터 새로운 정보를 받기 위해서는, 반드시 URL 요청이 전제되어야 한다는 말과 동치이다.

 

 

2. AJAX의 등장

AJAX는 HTTP 규약을 뛰어넘는 방안으로써, AJAX는 프로토콜이 아닌 HTTP를 효과적으로 이용하는 기술이다.

 

만약, 기존의 HTTP 방식으로 클라이언트가 서버에 요청을 보낸다고 가정하자.

요청 페이지에서 확인을 누르게 되면, 확인을 눌렀다는 정보를 서버에 전달하게 된다.

웹 서버는 요청을 받은 후, 처리한 후에 HTML 페이지를 생성하여 유저에게 해당 HTML 페이지를 전송한다.

이 방식을 선택하게 되면, HTML(웹 페이지)을 새롭게 브라우저에 뿌리게 되고, 결국에는 새로운 페이지로 이동하는 결과를 가져온다.

 

반면, AJAX를 사용하게 되면 클라이언트는 새로운 HTML을 서버에서 받는 것이 아니다.

새로운 웹 페이지로 이동하는 것이 아닌, 동일 웹 페이지 내에서 DOM을 변경하게 된다.

DOM(Document Object Model, 문서 객체 모델)
XML이나 HTML 문서에 접근하기 위한 일종의 인터페이스로써 문서 내의 모든 요소를 정의하고 각각의 요소에 접근하는 방법을 제공한다.

결과적으로, 사용자 입장에서 페이지 이동이 일어나지 않고 페이지 내부 변화만 일어나게 된다. HTML 페이지 전체를 바꾸는 것이 아닌, 부분만 바꿀 수 있게 되는 것이다.

 

 

2-1. HTTP vs AJAX

차이 1) 전체를 변경하는가 vs 부분만 선별적으로 변경하는가

• HTTP는 클라이언트에서 Request를 보내고 서버에서 Response를 받으면 이어졌던 연결이 끊어진다. 따라서, 화면의 내용을 갱신하기 위해서는 다시 request를 보내고 response를 받은 과정이 동반되어야 한다.
• AJAX는 html 페이지 전체가 아닌 일부분만 갱신할 수 있도록 XMLHttpRequest 객체를 통해 서버에 request를 보낸다. XMLHttpRequest는 서버와의 연결을 잡아두고, Json이나 xml 형태로 필요한 데이터만 주고 받으며 DOM을 갱신하기 때문에 그만큼의 자원과 시간을 아낄 수 있다.

차이 2) 누가 서버에 요청하는가

• HTTP는 웹브라우저가 서버에 요청한다.
• AJAX는 XMLHttpRequest 객체가 서버에 요청한다.

차이 3) 페이지의 변경사항이 필요할 때마다 페이지를 이동하는가

• HTTP는 항상 페이지 이동
• AJAX는 부분적 변경이 필요할 때, 해당 페이지 내에서 변경 가능

 

 

그러나, AJAX로도 수행되지 않는 것들이 있는데, 이는 AJAX가 HTTP에 기반을 둔 기술이기 때문이다.

앞서 언급한 HTTP의 특징이었던 '클라이언트의 요청이 있고 그 다음에 서버로부터 응답을 받음'과 같은 특징을 갖기 때문이다.

 

 

3. 웹 소켓(Web Socket) 이란?

웹 소켓은 HTML5 표준 기술로, 사용자의 브라우저와 서버 사이의 동적인 양방향 연결 채널을 구성한다.

Web Socket API를 통해 서버로 메세지를 보내고, 요청 없이 응답을 받아오는 것이 가능하게 된다.

​

웹 소켓은 매우 단순한 API로 구성되어 있고, 웹소켓을 이용하면 하나의 HTTP 접속으로 양방향 메시지를 자유롭게 주고받을 수 있습니다.

​

웹 소켓 통신과 비교하면 XMLHttpRequest에서는 통신할 때마다 꼭 요청 헤더가 부여되기 때문에 불과 1바이트의 정보를 송신하고 싶어도 수 킬로바이트에 달하는 쓸데 없는 정보를 보내야한다.

예시로, 채팅 입력을 한 문자마다 서버에 송신하고 싶은 경우처럼, 실시간을 추구한 애플리케이션에서는 이 점이 성능 차이로 이어질 가능성이 크다고 할 수 있다.

 

 

▷ HTTP 통신과 WebSocket의 차이점

HTTP와 WebSocket의 결정적인 차이는 프로토콜에 있다.

 

WebSocket 프로토콜은 접속 확립에 HTTP를 사용하지만, 그 후의 통신은 WebSocket 독자의 프로토콜로 이루어지고, 또한 header가 상당히 작아 overhead가 작다는 특징이 있다.

 

장시간 접속을 전제로 하기 때문에, 접속한 상태라면 클라이언트나 서버로부터 데이터 송신이 가능하며, 더불어 데이터의 송신과 수신에 각각 커넥션을 맺을 필요가 없어, 하나의 커넥션으로 데이터를 송수신 할 수 있다.

 

▷ WebSocket이 필요한 경우

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

 

 

4. Socket.io

웹 소켓은 HTML5의 기술이기 때문에 오래된 버전의 웹 브라우저는 웹 소켓을 지원하지 않는다.

따라서 자동 업데이트가 되지 않는 익스플로러 구 버전 사용자들은 웹 소켓으로 작성된 웹 페이지를 볼 수 없게 된다.

 

따라서 이를 해결하기 위해 나온 여러 기술 중 하나가 Socket.io 이다.

웹 페이지가 열리는 브라우저가 웹 소켓을 지원하면 웹 소켓 방식으로 동작하고, 지원하지 않는 브라우저라면 일반 http를 이용해서 실시간 통신을 흉내내는 것이다.

​

Socket.io는 node.js 기반으로 만들어진 기술로, 거의 모든 웹 브라우저와 모바일 장치를 지원하는 실시간 웹 애플리케이션 지원 라이브러리다. 100% 자바스크립트로 구현되어 있으며, 현존하는 대부분의 실시간 웹 기술들을 추상화하였다.

다시 말해, Socket.io는 자바스크립트를 이용하여 브라우저 종류에 상관없이 실시간 웹을 구현할 수 있도록 한 기술이다.

​

Socket.io는 웹 브라우저와 웹 서버의 종류와 버전을 파악하여 가장 적합한 기술을 선택하여 사용하게 되고,

만약 브라우저에 FlashSocket이라는 기술을 지원하는 플러그인이 설치되어 있으면 그것을 사용하고 플러그인이 없으면 AJAX Long Polling 방식을 사용하도록 한다.

 

 

5. WebSocket의 단점

1) 프로그램 구현에 보다 많은 복잡성 초래

• WebSocket은 HTTP와 달리 Stateful protocol이기 때문에 서버와 클라이언트 간의 연결을 항상 유지해야 하며 만일 비정상적으로 연결이 끊어졌을 경우 적절히 대응해야 한다. 이는 기존의 HTTP 사용과 비교했을 때 구현의 복잡도가 가중되는 요인이 될 수 있다.

2) 비용의 문제

• 서버와 클라이언트 간의 소켓을 유지한다는 것 자체가 비용이 많이 드는 일이고, 특히 트래픽양이 많은 서버의 경우 CPU에서 큰 부담으로 다가올 수 있다.

3) 오래된 브라우저에 대한 지원 X

• 오래된 버전의 브라우저에 대해서는 지원되지 않는다.
• SockJS 라이브러리의 경우 Fallback option을 제공한다.

4) 디버깅 시의 어려움

• 서버와 클라이언트 간 연결이 끊어졌을 때 생성되는 에러 메시지가 구체적이지 않다. (다양한 이유로 연결이 끊어질 수 있는데 에러 메세지가 같음)
• 디버깅을 하는데 어려움이 많음.

 

 

[출처]

[WEB] 🌐 웹 소켓 (Socket) 정리 (역사부터 차근차근) (tistory.com)

[WEB] 🌐 웹 소켓 (Socket) 정리 (역사부터 차근차근)