[Web/Network] 웹 소켓(Web Socket)의 개념

 

웹 상에서의 채팅 프로그램을 구현하는 프로젝트를 진행하기 전, 여러 문서들을 참고하여 웹 소켓의 개념을 정리하며 이해해보자.
이후에는 Node.js 서버 상의 웹소켓을 구현해보고자 한다.

웹 소켓(Web Socket)이란?

컴퓨터 네트워크용 통신 규약의 하나이다. 인터넷의 표준화 단체인 W3C(World Wide Web Consortium)과 IETF(Internet Engineering Task Forkce)가 Web server와 Web browser간의 통신을 위한 규정을 정의한 쌍방향통신(Duplex)용 기술 규약이다. API는 W3C가 책정을 맡고 있고, WebSocket 프로토콜은 IETF가 책정을 맡고 있다.

웹 소켓은 TCP 연결에 완전한 이중 통신 채널을 제공하는 컴퓨터 프로토콜이며, 서버와 클라이언트 간의 효율적인 양방향 통신을 실현하기 위한 구조를 지닌다. 최근에는 Gmail처럼 데이터의 실시간 특성을 중시한 웹 애플리케이션이 많이 등장하여 많은 주목을 받고 있다.
자바스크립트의 처리 성능이 크게 개선된 현재, 웹 애플리케이션의 성능 면에서 병목 현상이 나타나는 것은 네트워크 통신 부분으로, 웹 소켓은 실시간 웹을 구현하기 위한 핵심 기술로 기대받고 있다.

웹 소켓은 단순한 API로 구성되어 있어, 서버와 클라이언트 간에 Socket Connection을 유지해서 언제든 양방향 통신 또는 데이터 전송이 가능하도록 하는 기술이기도 하다.
XMLHttpRequest와 Server-Sent Event를 조합하여 양방향 통신을 구현하는 경우와 비교해 통신 효율이 좋고, 설계나 구현도 간단해진다는 장점을 지니고 있다.

웹 소켓은 HTTP와는 다르다. 두 프로토콜은 모두 OSI 모델 7번째 계층에 존재하며, TCP의 4번째 계층에 의존하고 있지만, 웹 소켓은 HTTP 포트 80 및 443 이상으로 실행되도록 설계되었으며, HTTP 프록시 및 중간 계층을 지원하도록 설계되어 HTTP 프로토콜과 호환된다. 호환성을 달성하기 위해, 웹 소켓 핸드 셰이크는 HTTP 업그레이드 헤더를 사용하여 HTTP 프로토콜 내의 웹 소켓 프로토콜로 변경하여 사용이 가능하다.

웹 소켓의 등장 배경

웹 소캣이 탄생한 배경을 이해하기 위해서는 HTTP의 단점을 이해할 필요가 있다.

브라우저 창에 늘 http:// 가 따라 붙듯, HTTP는 오랜 시간 우리 곁에 있었다. 그러나 오랜 시간 사용된 HTTP는 Client-Server간 접속을 유지하지 않으며, 한 번에 한 방향으로만 통신이 가능한 half-duplex (반이중) 방식으로 구현이 되어있다.
동시에 서로 주고 받아야 하는 데이터 양이 많아지며 half-dupex로 인한 성능 저하는 피할 수 없게 되었다.

또한 HTTP는 지나치게 많은 헤더 데이터를 가지고 있다. 특히나, 브라우저가 요청을 보내지 않아도 서버가 데이터를 보내주는 기능을 구현하는데 있어, HTTP의 근본적 메커니즘 탓에 한계가 있어왔다.
따라서 HTML5부터 Web Socket이 포함되어, WebSocket을 통해 AcitveX를 사용하지 않고도 TCP/IP 소켓 통신을 구현할 수 있게 되었다. 또한 네트워크의 과부하를 줄이고, 애플리케이션의 반응성을 높일 수 있게 되었다.

또한 800byte에서 수 kbyte에 달하는 긴 헤더의 길이를 갖고 있는 HTTP와 달리, WebSocket은 수 byte 수준으로 압축이 가능하다.

WebSocket이 HTTP를 대체하는 것은 아니지만, HTTP가 적합하지 않은 메세징, 트랜잭션 및 애플리케이션 특성 상 트래픽이 높고 지연 시간이 낮아야 하는 환경에서는 WebSocket을 이용한 통신 방식이 유용하다.

WebSocket은 어디에 사용되는가?

WebSocket은 Real-time web application 구현을 위해 널리 사용되고 있다. 채팅이나 멀티플레이어 게임, 공유와 동시 작업이 가능한 google docs 문서 서비스, 증권 거래, 실시간 주식 차트 등과 같이 실시간으로 양방향 데이터 송수신이 요구되는 응용프로그램의 개발을 한층 효과적으로 구현하는데 사용된다.


결론적으로, WebSocket은 웹 서버와 웹 브라우저가 지속적으로 연결된 TCP 라인을 통해 실시간으로 데이터를 주고 받을 수 있도록 하는 HTML5의 새로운 사양이다. 따라서 웹 소켓을 이용하면 일반적인 TCP 소켓과 같이 연결지향 양방향 전이중 통신이 가능하다.

---

WebSocket을 사용하는 이유

HTTP를 통해 이루어지는 통신은 Request/Response 기반의 Stateless Protocol이다. 즉, 서버와 클라이언트 간의 Socket Connection과 같은 영구적인 연결이 아니라, 클라이언트 쪽에서 필요할 때 Request를 할 때에만 서버가 Response를 하는 방식으로 통신이 진행되는 한방향 연결 통신인 것이다.
서버 쪽에서 데이터를 업데이트 하는 경우, 클라이언트 쪽에서는 화면을 Refresh 하지 않는 한, 변경된 데이터가 업데이트 되지 않는 문제가 발생한다. 이러한 문제는 일반적인 웹 어플리케이션에서는 임시 방편으로 기존의 Lone Polling 방식, 또는 Ajax를 사용하여 어느정도 해결 가능하지만, 데이터의 실시간 업데이트가 중요한 애플리케이션의 경우, Web Socket이 중요한 기술로 사용되고 있다.


웹 소켓 이전의 실시간 통신 방법

- HTTP Polling : 서버에 일정 주기로 요청을 송신한다. 불필요한 request와 connection을 생성. 변경사항이 없어도 요청을 보내고 응답을 받아야 한다.

- Lone Polling : 서버에 요청을 보내고 이벤트가 생겨 응답을 받을 때까지 연결을 종료하지 않는다. 응답을 받으면 끊고, 다시 요청을 보낸다. 결국 많은 요청이 쏟아질 경우 polling과 동일하다.

- Streaming : 서버에 요청을 보내면 끊기지 않은 연결 상태에서 끊임없이 데이터를 수신한다. 클라이언트에서 서버로의 데이터 송신이 어렵다.

HTTP Lone Polling 방식 (서버가 데이터를 프로세스할 때까지 응답이 주어짐)

HTTP Periodic Polling (매 n초마다 요청이 전송됨)

HTTP Streaming (즉각적이고 지속적엔 데이터 push를 위해 긴 연결을 제공함)

Web Socket은 Stateful Protocol이기 때문에, 한 번 클라이언트와 연결이 되면, 계속 같은 라인을 사용하여 통신이 되므로 HTTP 사용시 필요없이 발생되는 HTTP, TCP 연결 트래픽을 피할 수 있다.
그리고 HTTP와 동일한 port 80을 사용하기 때문에, 기업용 어플리케이션에 적용할 때 방화벽은 재설정하지 않아도 된다는 장점을 지닌다.

---

HTTP vs WebSocket

공통점

- HTTP는 클라이언트가 애플리케이션을 사용하기 위해 URL에 접근하여 HTTP method, header, entity 등을 통해 요청을 한다. 서버는 그에 따른 요청에 응답을 하며 통신이 이루어진다.

차이점

- WebSocket은 초기에 연결한 오직 하나의 URL만 존재한다. 즉 모든 애플리케이션 메세지는 같은 TCP 커넥션을 통해 통신된다.
- HTTP와는 완전히 다른 방식의 비동기식 이벤트 중심 메시징 아키텍쳐를 지닌다.
- WebSocket은 HTTP 핸드 셰이크 과정에서 Sec-WebSocket-Protocol에서 STOPM와 같은 높은 수준의 메시징 프로토콜을 사용하도록 요청할 수 있다.

WebSocket의 동작 원리

 

- 서버와 클라이언트 간의 연결은 HTTP 프로토콜을 통해 이루어진다.

GET /chat HTTP/1.1
Host: dream-and-develop.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-Websocket-Key: dGhlasBsDwerW==
Sec-Websocket-Version: 13

Handshake 요청
클라이언트(브라우저)에서 요청을 할때 위와 같이 HTTP 1.1로 요청을 하고, 웹 소켓 프로토콜로 업그레이드 해줄 것을 요청학 ㅔ된다. 이 때, 요청 해더에는 소켓 버전과 소켓 비밀키 정보 등을 포함한다.

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3SfeEbsd+xoOo==

Handshake 응답
서버에서는 클라이언트로 위와 같은 Handshake 응답이 온다. HTTP 1.1에서 WebSocket으로 프로토콜 업그레이드가 성공되면 HTTP status 101 응답을 전송한다.
연결이 정상적으로 이루어진다면, 서버와 클라이언트 간에 WebSocket연결이 이루어지고, 일정 시간이 지나면 HTTP 연결은 자동으로 끊어진다.



[참고자료]
https://velog.io/@wldus9503/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-Network3.-WebSocket-%EC%9B%B9-%EC%86%8C%EC%BC%93%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C
https://medium.com/platform-engineer/web-api-design-35df8167460
https://urmaru.com/7