직접 만들어 보면서 이해하는 웹소켓 (1) - 왜 웹소켓(WebSocket)인가?

💡 왜 웹소켓(WebSocket)인가?

 포털 사이트의 실시간 검색 순위, 주식이나 코인 거래소의 실시간 차트 정보, 음악 사이트의 실시간 음원 순위 등 웹 기반의 애플리케이션에서 실시간 정보 공유는 사용자 경험을 대폭 향상할 수 있는 중요한 요소이다. 그러나 전통적인 HTTP 통신 방식은 이러한 실시간 정보 공유에 몇 가지 제약이 있다. 이 글에서는 실시간 통신에 있어 기존 HTTP 통신 방식의 문제점에 대해 알아보고 이를 해결할 수 있는 몇 가지 방법을 논의한 후 왜 웹소켓이 실시간 통신에 있어 가장 우수한 선택인지를 직접 구현해 봄으로써 이해하려고 한다.

🥲 실시간 통신에서 HTTP의 한계

• HTTP 통신은 클라이언트가 서버에 요청을 보내고, 서버가 그 요청에 대한 응답을 보내는 요청-응답(Request-Response) 패턴을 기반으로 한다.
• 이러한 패턴은 웹 페이지나 애플리케이션의 대부분의 기능을 위해 잘 작동하지만 실시간으로 데이터를 교환해야 하는 상황에서는 몇 가지 문제가 발생한다.
• 실시간 통신 기술이 필요한 기능 중 하나인 채팅으로 예시를 들어보겠다.
  • 예를 들어 채팅 애플리케이션에서 사용자가 다른 사용자에게 메시지를 보낸다.
  • 사용자는 이 메시지가 상대방에게 즉각적으로 전달되기를 원하지만 HTTP 요청-응답 패턴에서는 이러한 실시간 통신이 어렵다.
    • 클라이언트(메시지를 받는 사용자)가 서버에 주기적으로 "새 메시지가 있는지" 확인을 요청하지 않는 한 서버는 클라이언트에게 자동으로 메시지를 전송할 수 없기 때문이다.

📃 예시

• A 사용자가 B 사용자와의 채팅에서 "안녕!"이라고 보내면 서버에는 A 사용자가 보낸 "안녕!"이란 메시지가 저장될 것이다.
• 그러나, 서버가 B 사용자에게 메시지를 전달하기 위해서는 B 사용자가 직접 서버에 메시지를 조회 요청을 해야 한다.
• B 사용자는 언제 A 사용자가 자신에게 메시지를 보냈는지 모르는 상황에서 무작정 요청을 계속 보낼 수도 없는 노릇이고 곤란한 상황에 빠지게 된다.

🥲 Polling(폴링)과 그 한계

• 위의 문제를 해결하기 위한 대표적인 방법 중 하나가 "Polling"이다.
• Polling은 클라이언트가 정해진 시간 간격으로 서버에 요청을 보내어 새로운 데이터가 있는지 주기적으로 확인하는 방법이다.
• 이 방법은 구현하기가 비교적 간단하며 실시간 정보 공유의 기본적인 형태를 제공할 수 있다.
  그러나 Polling에는 몇 가지 단점이 있다.
  • 첫째, 실제로 새로운 데이터가 없더라도 클라이언트는 계속해서 서버에 요청을 보내야 한다.
    • 이는 서버와 네트워크에 불필요한 부하를 초래할 수 있다.
  • 둘째, 정보의 실시간성이 정해진 Polling 간격에 의존하기 때문에 정보가 실제로 실시간으로 전달되지 않을 수 있다.
    • 10분에 한 번씩이라면 메시지를 전달하고 받는 데에 걸리는 시간이 최대 10분이나 걸린다.

 

🤔 Long Polling과 WebSocket

• Polling의 단점을 극복하기 위한 방법으로 "Long Polling"과 "WebSocket"이 있다.

 

🥲 Long Polling

• Long Polling은 클라이언트가 서버에 요청을 보낸 후, 서버가 새로운 데이터가 생길 때까지 응답을 지연시키는 방법이다.
• 새로운 데이터가 생기면 즉시 응답을 보내고 클라이언트는 새로운 요청을 보내 다시 대기한다.
• 이 방법은 Polling에 비해 서버 부하를 줄일 수 있지만, 여전히 실시간 통신의 한계가 있다.

 

🤗 WebSocket

• WebSocket은 클라이언트와 서버 간에 양방향 통신 채널을 생성하는 기술이다.
• HTML5 표준 기술이다.
• HTTP 환경에서 클라이언트와 서버 사이에 하나의 TCP 연결을 통해 실시간으로 전이중 통신을 가능하게 하는 프로토콜이다.
  • 전이중 통신이란 일방적인 송신 또는 수신만이 가능한 단방향 통신과 달리 가정에서의 전화와 같이 양방향으로 송수신하는 것을 말한다.
• WebSocket 연결이 수립되면 클라이언트와 서버는 서로에게 데이터를 즉시 보낼 수 있으며 이는 진정한 실시간 통신을 가능하게 한다.
• WebSocket은 HTTP와 달리 연결을 유지하는 동안 지속적인 데이터 교환을 허용하기 때문에 채팅 애플리케이션, 게임, 금융 시장 데이터 스트리밍과 같은 실시간 기능을 필요로 하는 애플리케이션에 이상적이다.

 

❓ 웹소켓이 기존 HTTP 통신보다 서버 부하가 감소되는 이유?

🥸 HTTP 통신과 Polling 방식의 서버 부하

• Polling 방식에서 클라이언트는 주기적으로 서버에 데이터가 있는지 확인을 위해 요청을 보낸다.
• 대부분의 경우, 새로운 데이터가 없음에도 불구하고 요청은 계속 발생하며 이는 서버에 불필요한 부하를 발생시킨다.

연결 설정과 해제 비용

• HTTP 요청은 매번 새로운 연결을 열고 데이터 전송 후 연결을 닫는 과정을 거친다.
• 이러한 연결 설정과 해제 과정은 서버 자원을 소모하는 작업이다.

헤더 오버헤드

• HTTP 요청은 헤더 정보를 포함하고 있어 실제 필요한 데이터와는 관계없는 불필요한 데이터가 많아 오버헤드를 발생시킬 수 있다.
  • 특히 Polling 방식에서는 이러한 오버헤드가 빈번하게 발생한다.
•  

🤗 웹소켓의 경우

효율적인 데이터 전송

• 웹소켓은 클라이언트와 서버 간의 지속적인 양방향 통신 채널을 제공함으로써 서버 부하를 효과적으로 감소시킨다.
• 영구적 연결 웹소켓은 연결이 한 번 수립되면 그 연결을 유지하고 데이터가 필요할 때마다 양방향으로 데이터를 전송할 수 있다.
  • 이는 연결 설정과 해제 과정을 반복하지 않아도 되므로 서버 부하를 크게 줄인다.
• 웹소켓 프로토콜은 데이터 전송 시 오버헤드를 최소화한다.
  
  • 초기 핸드셰이크(HTTP)를 제외하고 데이터 교환 시 헤더의 크기 또한 작다.

 

❓ 웹소켓의 동작 방식

• 웹소켓 연결의 초기 과정은 HTTP를 통해 이루어진다.
• 한 번 연결이 수립되면 이후의 데이터 교환은 웹소켓 프로토콜을 통해 이루어진다.

1. 핸드셰이크(Handshake)

• 웹소켓 연결은 클라이언트가 서버에 HTTP 요청을 보내면서 시작된다.
• 이 요청은 HTTP 메시지 헤더에 특별한 헤더(`Upgrade: websocket` 및 `Connection: Upgrade`)를 포함하여 웹소켓 연결로의 업그레이드를 요청한다.
• 서버가 이 요청을 승인하면, HTTP 연결은 웹소켓 연결로 전환된다.
• 이때 서버는 응답 코드를 101로 준다.

2. 데이터 전송

• 연결이 수립되면 클라이언트와 서버는 프레임 단위로 데이터를 주고받을 수 있다.
• 웹소켓 프로토콜은 텍스트와 바이너리 데이터 모두를 지원하며 데이터를 주고받는 동안 추가적인 HTTP 요청 없이도 통신할 수 있다.

3. 연결 종료

• 클라이언트나 서버가 연결을 종료하고 싶을 때 양쪽 모두 연결 종료 프로토콜을 이용해 이를 수행할 수 있다.

📌 기타 사항

• ws와 wss의 차이점은 http와 https와 같이 통신에 보안이 적용된 데에 있다.
• 웹소켓을 사용하기 위한 별도의 포트를 열 필요가 없다. 위에 설명했듯이 HTTP 통신에서 전환하는 방식으로 동작하기 때문이다.

 

다음 글에서는 웹소켓으로 간단한 채팅방을 구현해 보겠다.

 

 

 

참고

뤼튼

https://brunch.co.kr/@springboot/695