Web Socket (웹 소켓)

HTTP 통신과 단방향의 한계Polling의 개념과 문제점

• Short Polling: 클라이언트가 일정한 간격으로 서버에 요청을 보내는 방식입니다. 업데이트가 없더라도 요청이 계속해서 발생하기 때문에 불필요한 트래픽이 서버에 과부하를 줄 수 있습니다.
• Long Polling: 클라이언트가 요청을 보낸 후 서버에서 업데이트가 발생할 때까지 대기했다가 응답을 받는 방식입니다. 이 방식은 요청에 대한 대기 시간이 길어져 서버 리소스를 많이 소모할 수 있습니다.

Polling 방식은 이러한 한계로 인해 대규모 사용자 기반의 애플리케이션에서 비효율적일 수 있습니다.WebSocket은 HTTP와 달리 클라이언트와 서버 간 양방향 통신을 지원합니다. HTTP가 "요청-응답" 구조라면, WebSocket은 서로 자유롭게 메시지를 주고받는 전화 통화와 같습니다.

 

1. Handshake
   • 클라이언트는 HTTP를 통해 WebSocket 연결 요청을 보냅니다.
   • 서버는 요청을 수락하고 WebSocket 프로토콜로 업그레이드합니다.
   • 이 과정을 Handshake라고 부릅니다.
2. WebSocket 프로토콜 시작
   • Handshake가 완료되면 클라이언트와 서버는 HTTP가 아닌 WebSocket 프로토콜을 사용해 통신합니다.
   • WebSocket은 헤더 크기가 작고 오버헤드가 적어 HTTP보다 효율적입니다.
3. 연결 종료
   • 한쪽에서 close 프레임을 보내면 상대방이 이를 확인하고 응답하며 연결이 종료됩니다.

 

Handshake의 세부 과정

• 클라이언트의 요청 헤더에는 Sec-WebSocket-Key라는 랜덤 문자열이 포함됩니다.
• 서버는 이 키에 GUID라는 고정 문자열을 추가하고, 이를 SHA-1 해시 알고리즘으로 해싱한 뒤 Base64로 인코딩한 값을 반환합니다.
• 클라이언트는 반환된 값을 검증해 연결의 유효성을 확인합니다.

이 과정은 WebSocket 연결이 정상적으로 이루어졌는지를 확인하는 데 핵심적인 역할을 합니다.WebSocket은 효율적인 통신을 제공하지만, 사용 시 몇 가지 한계를 염두에 두어야 합니다.

1. 구현 복잡성
   • WebSocket은 서버 설계가 복잡할 수 있습니다. 특히 로드 밸런싱이 적용된 환경에서는 클라이언트와 특정 서버 간의 연결을 유지하도록 별도의 설정(예: 세션 스티키)이 필요합니다.
2. 메시지 크기 제한
   • WebSocket 메시지는 브라우저, 서버, 네트워크 환경에 따라 크기 제한이 있을 수 있습니다. 대용량 데이터를 처리할 때는 메시지를 분할하거나 다른 전송 방식을 고려해야 합니다.
3. 보안 문제
   • WebSocket의 기본 프로토콜인 WS는 암호화되지 않으므로, 보안이 중요한 애플리케이션에서는 SSL/TLS를 적용한 WSS(WebSocket Secure)를 사용해야 합니다.
4. 리소스 부담
   • 많은 사용자가 동시에 접속하면 유지해야 할 TCP 연결 수가 증가합니다. 또한 빈번한 메시지 송수신은 네트워크 대역폭과 서버의 CPU 사용량을 증가시킬 수 있습니다.