[네트워크] 실시간 통신 개념 정리 2 - 웹소켓

소켓 & 웹소켓

→ 이름이 비슷해서 헷갈리지만, 가장 큰 차이점 작동하는 레이어 자체가 다름

 

 

소켓

• 프로그램이 네트워크를 통해 데이터를 보내고 받을 수 있도록 OS가 제공하는 통로
• 전송 계층(TCP/UDP)을 사용하는 OS 레벨 인터페이스
• 앱이 단순히 소켓에 write() 하면 OS가 나머지(TCP 세크먼트 생성, IP패킷화 등)를 모두 처리

[ Application ]  
       ↓ (소켓 API)  
[ OS Kernel (TCP/IP Stack) ]
       ↓  
[ 네트워크 ]

 

 

 

웹소켓

• 웹 전용 실시간 프로토콜
• 웹 브라우저 ↔ 서버 사이의 지속적인 양방향 통신을 위해 만들어진 응용 계층 프로토콜
• 응용 계층에서 동작하며 HTTP를 기반으로 시작
• 처음엔 HTTP 요청으로 시작

연결 방식

1. Client가 HTTP Upgrade 요청
2. Server가 수락하면→ 101(상태 코드) Switching Protocols
3. 이후: WebSocket 양방향 통신

• 성공하면 연결을 업그레이드(Upgrade: websocket)해서 지속적인 양방향 통신 가능하게 함

 

 

 

웹소켓이 필요한 이유

→ 웹소켓은 HTTP의 구조적 한계를 해결하기 위해 등장

 

1️⃣ HTTP의 단점

• 비연결성 + 무상태성(Stateless, Connectionless)
  • 클라이언트가 요청을 보내고 서버가 응답하면 연결이 바로 끊김
  • 매 요청마다 연결해야함
• 서버 → 클라이언트 푸시 불가능
  • HTTP 연결에서는 오직 클라이언트만 요청 시작 가능
• 실시간 통신처럼 보이게만 가능
  • Polling (주기적으로 요청)
  • Long Polling
  • SSE

→ 실시간 통신을 하기엔 모두 추가 비용이 크고, 비효율적임

 

 

 

2️⃣ 웹소켓  장점

• 메시지가 최소한의 헤더만 담고 이동

실시간 채팅에서 “ㅎㅇ” 같은 3바이트를 보내는데
HTTP는 매번 300~800바이트의 헤더를 붙여 보냄
→ 낭비 심함

- 웹소켓 프레임 헤더는 기본 2바이트
- 페이로드 길이에 따라 2~12까지 확장가능

• 메시지 전송방식 → 메시지 기반
  • Websocket은 TCP를 기반으로 동작하지만 바이트 스트림이 아닌 메시지 단위로 전송
  • TCP는 바이트 스트림이기 때문에 메시지 경계를 직접 관리해야 하지만 WebSocket은 프레임 단위로 메시지 경계를 보장

[WebSocket Header (2~12 bytes)]
[
     0x81            // FIN + Text Frame
     0x82           // MASK + 길이(2 bytes)
     Masking Key(4B)
]
[Payload: "안녕"(UTF-8)] 

• 실시간 채팅, 게임, 방송 등 구현 가능

바이트 스트림

- 데이터 구분 없이 0과 1로 연속된 흐름으로 보는 방식

 

페이로드

- 헤더를 제외한 실제 전송하고자 하는 본문 데이터

 

 

3️⃣ "안녕"을 보낼때 실제 구조

사용자가 “안녕” 입력 → 앱이 메시지 생성

[ FIN=1 | OP=Text ]      // 1 byte
[ MASK=1 | length ]      // 1 byte
[ Masking Key (4 byte) ] // 클라이언트 전송 시 필수
[ UTF-8 Payload "안녕" ]  // 6 bytes

총 약 2 + 4 + 6 = 12 bytes 만 전송됨

HTTP로 전송 시 300~800 bytes 와 비교했을 때 훨씬 효율적

 

 

 

 

정리

항목	소켓	웹소켓
동작 계층	전송 계층(TCP/UDP 위 인터페이스)	응용 계층(HTTP 기반)
역할	앱과 OS(TCP/IP) 사이의 통로	실시간 양방향 통신 프로토콜
연결 방식	TCP/UDP	HTTP Handshake 후 TCP 지속 연결
용도	모든 네트워크 프로그램의 기반	실시간 서비스(채팅, 알림 등)