웹소켓 기본 개념과 동작 원리

개요

---

실시간 채팅 서비스를 구현하기 위해 적절한 기술 스택을 고민하던 중, 기존 HTTP 통신이 클라이언트 요청에 대해 서버가 응답하는 단방향 모델이라는 한계를 느꼈다. 채팅은 사용자 간 지속적이고 양방향으로 메시지를 주고받아야 하므로, 보다 실시간성을 보장할 수 있는 통신 방식이 필요했다.

 

이러한 요구사항을 충족하기 위해 웹소켓을 도입하게 되었고, 웹소켓은 한 번의 연결로 지속적인 양방향 통신을 가능하게 하여, 채팅과 같은 실시간 서비스에 적합하다고 판단했다. 당시 제한된 프로젝트 기간으로 인해 이론적인 부분은 간략하게 파악하고 구현했지만, 보다 깊은 이해가 필요하다고 느껴 이번 기회에 웹소켓의 기본 개념과 동작 원리에 대해 체계적으로 학습하고자 한다.

 

HTTP의 한계와 웹소켓 등장

---

기존 HTTP 프로토콜은 클라이언트가 요청을 보내면 서버가 응답을 반환하는 요청-응답 모델을 따른다.

 

이 방식은 다음과 같은 한계를 가지고 있다.

 

﹒ 실시간성 부족: 매 요청마다 새로운 연결을 맺고 해제하기 때문에, 서버에서 즉시 데이터를 푸시하기 어렵다.

﹒ 오버헤드 발생: 실시간 데이터가 필요하면 클라이언트는 짧은 주기로 폴링 또는 롱 폴링을 시도하여 네트워크와 서버 자원을 낭비한다.

 

 

웹소켓의 필요성

---

이러한 문제를 해결하기 위해, 클라이언트와 서버 간 단 한 번의 연결로 지속적인 양방향 통신을 가능하게 하는 기술이 필요했다.

그 결과 등장한 기술이 바로 웹소켓이다.

웹소켓은 HTML5에 도입된 통신 프로토콜로, TCP 기반으로 동작하여 신뢰성 있는 데이터 전송을 보장한다.

초기 연결은 HTTP 요청-응답으로 시작하되, 연결이 업그레이드(Upgrade)된 후에는 지속적인 양방향 통신 채널을 유지한다.

 

 

웹소켓의 장점

 

﹒ 양방향 통신: 클라이언트와 서버가 동시에 데이터를 주고받을 수 있어 실시간 상호작용에 적합하다.

﹒ 낮은 오버헤드: 한 번 연결을 맺으면 유지되므로, 매번 새로운 연결을 설정하는 비용이 줄어든다.

﹒ 빠른 응답성: 데이터가 즉시 전달되어 채팅, 게임, 모니터링 등 실시간 애플리케이션에 효율적이다.

 

 

웹소켓 핸드셰이크 과정

---

웹소켓 연결은 다음과 같은 핸드셰이크 과정을 통해 이루어진다.

 

 

1. 클라이언트 요청 (HTTP GET + 업그레이드 헤더)

 

﹒ 클라이언트는 HTTP GET 요청과 함께 Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key, Sec-WebSocket-Version 등의 헤더를 첨부해 웹소켓 연결을 요청한다.

 

 

2. 서버 응답 (HTTP 101 Switching Protocols)

 

﹒ 서버는 요청을 확인하고, 웹소켓 연결을 승인할 경우 HTTP/1.1 101 Switching Protocols 상태 코드로 응답한다.

﹒ 서버는 Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Accept 등의 헤더로 요청의 유효성을 확인한다.

 

 

3. 핸드셰이크 완료 및 연결 업그레이드

 

﹒ 클라이언트는 서버 응답을 수신하면 웹소켓 연결로 전환되어 지속적인 양방향 통신이 가능해진다.

﹒ 텍스트 또는 바이너리 데이터 전송이 가능하며, Ping / Pong 프레임을 통해 연결 상태를 확인할 수 있다.

 

 

클라이언트 요청 패킷 & 서버 응답 패킷

---

핸드셰이크가 정상적으로 완료되면,

HTTP 요청-응답 기반의 단방향 통신 모델에서 웹소켓 기반의 양방향 통신 모델로 업그레이드되어 지속적인 연결이 유지된다.

 

 

웹소켓의 한계와 고려 사항

 

1. 보안

 

﹒ 기본적으로 TCP 기반 통신이므로, TLS가 적용되지 않으면 암호화가 되지 않아 보안상 취약할 수 있다.

﹒ 민감한 데이터 전송 시 “wss://”를 통해 암호화된 채널을 사용하는 것이 권장된다.

 

 

2. 방화벽 및 프록시 이슈

 

﹒ 일부 네트워크 환경(방화벽 혹은 프록시 서버)에서 웹소켓 트래픽을 차단하거나 변환하면 연결이 불안정해질 수 있다.

 

 

3. 연결 유지 비용

 

﹒ 웹소켓은 연결을 지속적으로 유지하므로, 클라이언트가 많을 경우 서버 자원 관리가 중요하다.

﹒ Ping / Pong 프레임으로 연결 상태를 확인하고, 필요시 재연결 로직을 구현해야 한다.

 

 

4. 복잡성 증가

 

﹒ HTTP와 달리 상태를 유지하는 연결이므로, 연결 해제, 재연결, 그리고 예외 처리를 위한 추가 로직이 필요하다.