Spring Web Reactive | 3. WebSocket | 3.1. WebSocket 개요

Tags:

WebSocket 프로토콜인 RFC 6455는 하나의 TCP 연결을 통해 클라이언트와 서버 사이에 전이중 양방향 통신 채널을 설정하는 표준화된 방법을 제공한다. 이는 HTTP와는 다른 TCP 프로토콜이지만, 포트 80과 443을 사용하여 기존의 방화벽 규칙의 재사용을 허용하는 HTTP에서 작동하도록 설계되어 있다.

WebSocket의 대화는 HTTP Upgrade 헤더를 사용하여 업그레이드하거나 이 경우 WebSocket 프로토콜로 전환 HTTP 요청에서 시작된다. 다음의 예는 이러한 상호 작용을 보여준다.

GET /spring-websocket-portfolio/portfolio HTTP/1.1
Host: localhost:8080
Upgrade: websocket   (1)
Connection: Upgrade   (2)
Sec-WebSocket-Key: Uc9l9TMkWGbHFD2qnFHltg==
Sec-WebSocket-Protocol: v10.stomp, v11.stomp
Sec-WebSocket-Version: 13
Origin: http://localhost:8080
  • (1) Upgrade 헤더.
  • (2) Upgrade 연결을 사용한다.

일반 200 상태 코드 대신 WebSocket을 지원하는 서버는 다음과 같은 출력을 반환한다.

HTTP/1.1 101 Switching Protocols   // (1)
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 1qVdfYHU9hPOl4JYYNXF623Gzn0=
Sec-WebSocket-Protocol: v10.stomp
  • (1) 프로토콜 스위치

핸드셰이크에 성공한 후 HTTP 업그레이드 요청의 기본 TCP 소켓은 클라이언트와 서버 모두에 대해 열린 채로 메시지의 송수신을 계속한다.

WebSockets의 동작 방법의 완전한 도입은 이 문서의 범위를 벗어난다. RFC 6455, HTML5의 WebSocket의 장 또는 Web 관한 많은 도입 및 자습서 중 하나를 참조해라.

WebSocket 서버가 Web 서버(nginx 등)의 배후에서 실행되는 경우는 WebSocket 업그레이드 요청을 WebSocket 서버에 전달하도록 구성해야 할 가능성이 높은 점에 유의해라. 마찬가지로 응용 프로그램이 클라우드 환경에서 실행되고 있는 경우는 WebSocket 지원 관련 클라우드 제공자의 지침을 확인해라.

3.1.1. HTT와 WebSocket

WebSocket은 HTTP 호환되도록 설계되어 있으며, HTTP 요청으로 시작하지만, 2개의 프로토콜이 매우 다른 아키텍처와 애플리케이션 프로그래밍 모델에 연결되는 것을 이해하는 것이 중요한다.

HTTP 및 REST는 응용 프로그램은 많은 URL로 모델링된다. 응용 프로그램과 상호 작용하는 클라이언트는 이러한 URL에 액세스하고 요청/응답 스타일을 사용한다. 서버는 HTTP URL, 메소드, 헤더에 따라 요청을 적절한 핸드러로 라우팅한다.

대조적으로, WebSockets는 일반적으로 첫 번째 연결 URL은 하나뿐이다. 그 후 모든 응용 프로그램 메시지는 같은 TCP 연결에서 흐른다. 이것은 전혀 다른 비동기 이벤트 중심의 메시징 아키텍처를 말한다.

WebSocket은 낮은 레벨의 전송 프로토콜이며, HTTP와 달리 메시지의 컨텐츠에 의미(semantics)를 규정하고 있지 않다. 즉, 클라이언트와 서버가 메시지의 의미(semantics)에 동의하지 않는 한 메시지를 라우팅 또는 처리하는 방법은 없다.

WebSocket 클라이언트와 서버는 HTTP 핸드셰이크 요청의 Sec-WebSocket-Protocol 헤더를 통해 높은 레벨의 메시징 프로토콜(예 : STOMP)의 사용을 협상 할 수 있다. 이 헤더가 없으면 클라이언트와 서버는 자신들의 정책을 스스로 규정해야 한다.

3.1.2. WebSockets를 언제 사용해야 하나?

WebSockets는 Web 페이지를 역동적이고 인터랙티브하게 할 수 있다. 단, 많은 경우에는 Ajax와 HTTP 스트리밍 또는 롱 폴링의 조합으로 간단하고 효과적인 솔루션을 제공할 수 있다.

예를 들어, 뉴스, 메일, 소셜 피드는 동적으로 업데이트해야 하지만 몇 분마다 업데이트해도 문제 없다. 한편, 협업, 게임, 금융 앱은 실시간으로 더 접근해야 한다.

지연(Latency)만이 결정 요인은 아니다. 메시지의 양이 비교적 적은 경우(네트워크 오류 모니터링 등), HTTP 스트리밍 또는 폴링은 효과적인 솔루션을 제공 할 수 있다. WebSocket의 사용에 최적인 경우는 적은 대기 시간, 높은 빈도, 높은 볼륨의 조합이다.

또한, 인터넷에서는 Upgrade 헤더를 전달하도록 구성되어 있지 않거나, 유휴(idle) 상태인 것으로 보이는 긴 시간 연결을 닫기 때문에 통제 불능의 제한 프록시가 WebSocket 상호 작용을 방해 할 수 있다는 점에 유의해야 한다. 이는 방화벽의 내부 응용 프로그램에 WebSocket을 사용하는 것은 공개 응용 프로그램보다 간단한 결정임을 의미한다.




최종 수정 : 2021-04-12