HTTP에서 웹소켓으로 전환되는 과정이 어떻게 이루어지나요?
1. 클라이언트가 서버에 WebSocket 업그레이드 요청
WebSocket 연결은 기존의 HTTP 요청을 통해 시작됩니다.
클라이언트는 HTTP 요청의 Upgrade 헤더를 사용하여 WebSocket 연결로의 업그레이드를 서버에 요청합니다.
HTTP 요청 예시
GET /chat HTTP/1.1
Host: example.com:80
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
주요 헤더 설명:
- Upgrade: websocket: HTTP 프로토콜에서 WebSocket 프로토콜로 업그레이드를 요청.
- Connection: Upgrade: 연결 업그레이드 요청임을 알림.
- Sec-WebSocket-Key: 클라이언트가 랜덤하게 생성한 Base64로 인코딩된 키. 서버가 이를 기반으로 응답을 생성.
- Sec-WebSocket-Version: 클라이언트가 지원하는 WebSocket 프로토콜 버전(일반적으로 13).
2. 서버가 WebSocket 업그레이드 승인
서버는 클라이언트의 요청을 확인하고, WebSocket 프로토콜로 업그레이드가 가능하면 HTTP 상태 코드 101 Switching Protocols로 응답합니다.
HTTP 응답 예시
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
주요 헤더 설명:
- Upgrade: websocket: WebSocket 업그레이드 요청 수락.
- Connection: Upgrade: 연결 업그레이드가 성공적으로 이루어졌음을 알림.
- Sec-WebSocket-Accept: 클라이언트의 Sec-WebSocket-Key를 기반으로 생성된 응답 키. 이 키는 서버가 클라이언트의 요청을 확인했음을 증명하는 데 사용됩니다.
- 생성 방식: Sec-WebSocket-Key + 고정 GUID(“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”)를 SHA-1 해싱한 후 Base64로 인코딩.
3. WebSocket 연결이 성공적으로 전환
- 서버가 101 응답을 반환하면 클라이언트와 서버 간의 연결은 HTTP에서 WebSocket으로 전환됩니다.
- 이후 통신은 HTTP가 아닌 WebSocket 프로토콜을 사용하여 진행됩니다.
- WebSocket은 프레임(Frame) 단위로 데이터를 송수신하며, 텍스트 또는 바이너리 메시지를 교환할 수 있습니다.
4. WebSocket 연결 이후 데이터 송수신
- WebSocket 프레임 구조: WebSocket은 요청/응답 기반이 아닌 지속적인 양방향 통신을 지원합니다.
- 클라이언트와 서버는 요청-응답 없이 데이터를 실시간으로 송수신 가능.
- 데이터는 텍스트 또는 바이너리 형태의 프레임으로 전송.
WebSocket 데이터 전송 예시:
1. 텍스트 메시지 전송:
클라이언트
Hello, WebSocket!
서버
Welcome to WebSocket!
2. 바이너리 데이터 전송:
이미지, 파일 등 바이너리 데이터도 WebSocket 프레임으로 전송 가능.
WebSocket 전환 과정 요약
1. HTTP 요청:
클라이언트가 HTTP 요청으로 WebSocket 연결 업그레이드 요청.
2. 서버 응답:
서버가 HTTP 상태 코드 101로 업그레이드 승인.
3. 프로토콜 전환:
HTTP에서 WebSocket으로 전환 후 양방향 통신 시작.
4. 지속적 연결:
연결 유지 상태에서 클라이언트와 서버는 실시간 데이터 교환.
Websocket 전환의 주요 특징이 어떻게 되나요?
WebSocket 전환의 주요 특징은 기존의 HTTP 프로토콜과 달리, 양방향 통신과 지속적인 연결을 통해 실시간 데이터 교환이 가능하다는 점입니다.
1. 양방향 통신 (Bi-directional Communication)
설명: 클라이언트와 서버가 모두 데이터를 보낼 수 있는 상호작용이 가능.
클라이언트 → 서버: 요청을 보낼 필요 없이 자유롭게 데이터 전송 가능.
서버 → 클라이언트: 이벤트 발생 시 즉시 데이터를 푸시(Push) 가능.
장점:
HTTP와 달리 요청-응답 주기 없이 클라이언트와 서버 간 실시간 데이터 교환.
채팅, 실시간 알림, 게임 등 실시간성이 중요한 애플리케이션에 적합.
2. 지속적인 연결 (Persistent Connection)
설명: HTTP 요청처럼 매번 새로운 연결을 생성하지 않고, 최초 핸드셰이크 후 연결을 유지.
장점:
클라이언트와 서버 간 연결 상태를 유지하여 통신 지연(Latency) 감소.
반복적인 TCP 핸드셰이크와 HTTP 헤더 오버헤드 제거.
3. 저지연 (Low Latency)
설명: WebSocket은 연결 유지 상태에서 데이터를 즉시 전송하므로 지연 시간이 매우 낮음.
장점:
실시간 데이터를 빠르게 전달.
HTTP Polling(주기적 요청) 대비 효율적.
게임, 주식 시세, IoT 애플리케이션 등에 이상적.
4. 소켓 기반 데이터 전송
설명: WebSocket은 텍스트와 바이너리 데이터를 모두 처리할 수 있음.
특징:
텍스트 기반 데이터(예: JSON) 전송.
바이너리 데이터(예: 이미지, 파일) 전송.
프레임 단위로 데이터를 주고받아 효율적.
5. 낮은 네트워크 오버헤드
설명: HTTP는 요청마다 헤더를 포함해야 하지만, WebSocket은 초기 핸드셰이크 후 최소한의 헤더만 사용.
장점:
데이터 전송에 필요한 네트워크 트래픽 감소.
대규모 연결을 처리할 때 비용 효율적.
6. 실시간성 (Real-time Communication)
설명: 클라이언트와 서버 간의 데이터를 실시간으로 송수신 가능.
장점:
HTTP 기반의 폴링(Polling)이나 롱 폴링(Long Polling)보다 실시간성 향상.
서버는 데이터가 준비되자마자 클라이언트에게 푸시(Push) 가능.
7. 프로토콜 독립성
설명: WebSocket은 애플리케이션 레벨에서 특정 데이터 포맷(JSON, XML, 바이너리 등)을 강제하지 않음.
장점:
애플리케이션 요구사항에 맞는 데이터 포맷을 자유롭게 선택 가능.
8. 스케일링 및 확장성
설명: 지속적인 연결을 유지하면서도 효율적으로 대규모 클라이언트 요청을 처리 가능.
장점:
단일 연결로 많은 클라이언트를 처리 가능.
서버 리소스를 효과적으로 사용.
Websocket과 HTTP Polling 비교 표
| 특징 | Websocket | HTTP Polling |
| 통신 방식 | 양방향(Bi-directional) | 단방향 요청-응답(Request-Response) |
| 연결 방식 | 지속 연결(Persistent Connection) | 요청마다 새 연결(Stateless) |
| 실시간성 | 실시간성 우수 | 지연 발생 가능 |
| 오버헤드 | 낮음 | 높음 |
| 데이터 전송 방식 | 프레임(Frame) 단위 | HTTP 요청/응답 단위 |
Websocket의 활용 사례 중 어떤것들이 있나요?
1. 채팅 애플리케이션
실시간 메시지 송수신 및 읽음 확인.
2. 실시간 알림
푸시 알림 시스템.
3. 게임
다중 사용자 간 실시간 상호작용.
4. 주식/환율
실시간 데이터 업데이트.
5. IoT
디바이스 간 실시간 통신.