[Network] (실시간 통신) WebSocket이란?

소개

WebSocket은 양방향 통신을 제공하는 통신 프로토콜이다. 

기존의 HTTP 통신은 클라이언트가 서버에 요청을 보내고, 서버가 응답을 보내는 단방향 통신이였다. 

이에 반해 WebSocket은 클라이언트와 서버 간에 양방향으로 데이터를 주고받을 수 있다.

 

WebSocket의 동작 방식에 대하여 설명하겠다.

 

1. 웹소켓 클라이언트에서 핸드쉐이크 요청(HTTP Upgrade)

응답으로 핸드 셰이크 응답을 받는데, 이때 응답 코드는 101이다.

101은 '프로토콜 전환'을 서버가 승인했음을 알리는 코드이다.

이 과정에서 요청과 응답의 헤더를 살펴보겠습니다.

예제 요청 주소는 : ws://localhost:8080/chat 이다.

GET /chat HTTP/1.1
Host: localhost:8080
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: localhost:8080

header의 내용

• Upgrade : 프로토콜을 전환하기 위해 사용하는 헤더. 웹소켓 요청 시에는 반드시 websocket이라는 값을 가지며, 이 값이 없거나 다른 값이면 cross-protocol attack이라고 간주하여 웹소켓 접속을 중지시킨다.  
• Connection : 현재의 전송이 완료된 후 네트워크 접속을 유지할 것인가에 대한 정보. 웹소켓 요청 시에는 반드시 Upgrade라는 값을 가지며, Upgrade와 마찬가지로 이 값이 없거나 다른 값이면 웹소켓 접속을 중지시킨다. 
• Sec-WebSocket-Key : 유효한 요청인지 확인하기 위해 사용하는 키 값.  
• Sec-WebSocket-Protocol : 사용하고자 하는 하나 이상의 웹 소켓 프로토콜 지정. 필요한 경우에만 사용.
• Sec-WebSocket-Version : 클라이언트가 사용하고자 하는 웹소켓 프로토콜 버전. 현재 최신 버전 13
• Origin : 모든 브라우저는 보안을 위해 이 헤더를 보냅니다(Cross-Site WebSocket Hijacking와 같은 공격을 피하기 위해서). 대부분 어플리케이션은 이 헤더가 없는 요청을 거부하며, 이러한 이유로 CORS정책이 만들어진 것이다.

이 외에도 여러 메시지나 서브 프로토콜, Referer나 Cookie와 같은 공통 헤더, 인증 헤더 등을 추가해 보낼 수도 있다. 

• HTTP/1.1 101 Switching Protocols
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
  Sec-WebSocket-Protocol: chat

  • Upgrade와 Connection은 요청과 동일하다. 
  • Sec-WebSocket-Accept : 요청 헤더의 Sec-WebSocket-Key에 유니크 아이디를 더해서 SHA-1로 해싱한 후, base64로 인코딩한 결과. 웹소켓 연결이 개시되었음을 알린다. 

2.Data Trasfer

핸드쉐이크를 통해 웹소켓 연결이 수립되면, 데이터 전송 파트가 시작.

여기에서는 클라이언트와 서버가 '메시지'라는 개념으로 데이터를 주고받는데, 여기서 메시지는 한 개 이상의 '프레임'으로 구성되어 있다.

(프레임은 텍스트(UTF-8) 데이터, 바이너리 데이터, 컨트롤 프레임(프로토콜 레벨의 신호) 등이 있다)

핸드 셰이크가 끝난 시점부터 서버와 클라이언트는 서로가 살아 있는지 확인하기 위해 heartbeat 패킷을 보내며, 주기적으로 ping을 보내 체크한다.

이는 서버와 클라이언트 양측에서 설정 가능함. 

 

3. Close HandShake

클라이언트와 서버 모두 커넥션을 종료하기 위한 컨트롤 프레임을 전송할 수 있다. 

이 컨트롤 프레임은 Closing Handshake를 시작하라는 특정한 컨트롤 시퀀스를 포함한 데이터를 가지고 있다. 

위 그림에서는 서버가 커넥션을 종료한다는 프레임을 보내고, 클라이언트가 이에 대한 응답으로 Close 프레임을 전송한다. 

그러면 웹소켓 연결이 종료됩니다. 연결 종료 이후에 수신되는 모든 추가적인 데이터는 버려진다. 

---

특징

 

Websocket의 장점

 

실시간 양방향 통신: 

WebSocket은 클라이언트와 서버 간에 양방향 통신을 가능케 합니다. 서버는 언제든지 클라이언트에게 데이터를 보낼 수 있고, 반대로 클라이언트도 언제든지 서버에게 데이터를 보낼 수 있습니다.

저렴한 오버헤드: 

HTTP의 경우, 매 요청마다 새로운 연결을 맺어야 하므로 많은 오버헤드가 발생할 수 있습니다. 반면 WebSocket은 한 번의 연결로 오랫동안 데이터를 주고받을 수 있어 오버헤드가 낮습니다.

프록시와 방화벽 문제 해결: 

일부 프록시 및 방화벽은 HTTP의 특정 포트나 메서드를 차단하는 경우가 있습니다. WebSocket은 HTTP를 기반으로 하지만 별도의 프로토콜로 작동하므로 이러한 문제를 피할 수 있습니다.

이벤트 기반 모델: 

WebSocket은 이벤트 기반 모델을 사용하여 실시간 데이터를 처리합니다. 이는 서버 또는 클라이언트에서 특정 이벤트가 발생할 때마다 콜백 함수를 호출하여 데이터를 처리할 수 있도록 합니다.

 

 

실시간 통신 방식 종류

 

WebSocket:

양방향 통신을 위한 효율적인 프로토콜입니다. 단일 연결로 실시간 양방향 통신이 가능하며, 새로운 데이터가 발생하면 서버가 클라이언트에게 즉시 전달됩니다.
주로 채팅 애플리케이션, 실시간 협업 도구, 주식 거래 등에서 사용됩니다.

Server-Sent Events (SSE):

서버에서 클라이언트로 단방향 실시간 이벤트를 전송하는 메커니즘입니다. 클라이언트는 이벤트 스트림을 구독하고, 서버는 새로운 이벤트를 스트림에 푸시합니다.
특히 서버가 주도하는 업데이트가 필요한 경우에 사용됩니다. 예를 들어, 뉴스 피드, 주식 가격 업데이트 등이 해당됩니다.

Long Polling:

클라이언트가 서버에 지속적으로 요청을 보내고, 서버는 새로운 데이터가 있을 때 응답을 보내는 방식입니다. 클라이언트는 응답을 받으면 즉시 새로운 요청을 보냅니다.
WebSocket이 지원되지 않는 환경에서 사용될 수 있습니다. 그러나 HTTP 연결을 유지하기 위해 오래된 방식이며, 오버헤드가 있을 수 있습니다.

 

HTTP Polling

클라이언트가 주기적으로 서버에 요청을 보내고, 서버는 새로운 데이터가 있을 때 응답합니다.
주기적인 폴링으로 인해 지연이 발생하고 대역폭을 소비할 수 있습니다.
실시간 양방향 통신이 필요한 환경에서는 WebSocket 등이 더 효율적이나, WebSocket이 지원되지 않는 환경에서 대체 수단으로 사용될 수 있습니다.

 

WebRTC (Web Real-Time Communication):

웹 브라우저 간에 플러그인 없이 피어 투 피어 실시간 통신을 제공하는 오픈 소스 프로젝트입니다. 주로 비디오 채팅, 음성 통화 등에 사용됩니다.
주로 브라우저 간의 실시간 멀티미디어 통신에 사용됩니다.

 

MQTT (Message Queuing Telemetry Transport):

경량 메시징 프로토콜로, IoT (Internet of Things) 디바이스 및 센서 간의 효율적인 실시간 통신에 사용됩니다.
센서 데이터의 실시간 전송과 같은 IoT 시나리오에 효과적입니다.
이러한 실시간 통신 방식은 각각의 특징과 용도에 맞게 선택되어야 합니다. 선택은 프로젝트의 요구 사항, 대상 플랫폼, 네트워크 제약 사항 등을 고려하여 이루어져야 합니다.

 

---

결론

WebSocket은 주로 실시간 채팅 애플리케이션, 온라인 게임, 주식 시장 데이터 업데이트 등과 같이 실시간 통신이 필요한 분야에서 사용된다. 최근의 웹 애플리케이션에서는 WebSocket을 사용하여 사용자 경험을 향상시키는 데 널리 사용되고 있다.