HTTP보다 웹소켓 프로토콜이 가벼운 이유

[ Application Layer ] ────────── HTTP, WebSocket
[ Transport Layer  ] ────────── TCP
[ Network Layer    ] ────────── IP

✅ 2. WebSocket vs HTTP: 차이점

항목	HTTP	WebSocket
연결 방식	요청/응답 기반	양방향(Full-duplex) 연결 유지
연결 지속	요청마다 새로 연결	연결 한 번, 지속 유지
헤더 크기	큼 (HTTP Header 반복 포함)	처음만 큼, 이후 작음
메시지 방식	텍스트 위주	바이너리/텍스트 모두 가능
사용 목적	웹 요청 (문서, API 등)	실시간 통신 (채팅, 게임 등)

📌 HTTP

• 매 요청마다 헤더 정보가 포함돼야 해서 부담이 큼 예:

  POST /chat HTTP/1.1
  Host: example.com
  User-Agent: Mozilla/5.0
  Accept: */*
  Content-Type: application/json
  Content-Length: 42
  Authorization: Bearer xxxxxx
  Cookie: session_id=abcd1234
  
  {"message": "Hello, this is a message"}
  

📌 WebSocket

• 처음에만 HTTP로 업그레이드 요청 (handshake)

• 이후는 프레임 기반 통신: 작고 빠른 메시지 전송 가능 (바이너리도 O)

• 지속 연결 유지하므로 중복 요청/헤더 없음

• HTTP 메시지를 보내기 때문에 토큰을 통해 유저 검증 가능

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Version: 13

WebSocket 메시지 예시 (Upgrade 이후)

📦 메시지 1개 전송 (텍스트 “hi”)

WebSocket은 자체적인 binary frame 포맷을 사용한다:

[0x81][0x82][0x37][0xfa][0x21][0x3d][0x7f][0x9f]

분석하면:

• 0x81: FIN bit + Text frame

• 0x82: Payload length (masked, 2바이트)

• 나머지: 마스킹 키 + 실제 데이터

👉 이 메시지 크기: 10바이트 내외 (동일한 내용의 HTTP 요청은 수십~백 바이트 이상)

WebSocket이 종료할 때는 양쪽 모두 Close Frame을 주고 받으며 끝낸다.

📤 클라이언트 또는 서버가 먼저 전송:

Opcode: 0x8 (Close Frame)
Payload: 상태 코드 (2바이트) + 이유(optional)

예:

• 상태 코드 1000: 정상 종료

• 상태 코드 1001: 종료 사유: 서버 내려감

• 상태 코드 1006: 네트워크 문제로 종료됨 (비정상 종료)

---

✅ 2. 종료 순서

1. 클라이언트 또는 서버가 close() 프레임 전송

2. 상대방이 ACK로 응답하는 close frame을 보냄

3. TCP 연결 종료

✅ 실제 사용 예

✅ 클라이언트 정상 종료:

ws.close(1000, "Finished chat");

✅ 서버 종료 (Spring 등):

session.close(new CloseReason(CloseCodes.NORMAL_CLOSURE, "Session expired"));

웹은 대부분 “요청-응답” 모델이 적합

HTTP는:

• 클라이언트가 요청(request) → 서버가 응답(response)

• 브라우저와 서버 사이에 가장 단순하고 안정적인 구조

📌 대다수의 웹페이지는 다음과 같은 흐름:

• 페이지 열기

• 서버에서 HTML, JS, CSS 받기

• API로 데이터 한두 번 요청

• 끝

WebSocket처럼 실시간 연결이 필요하지 않음.

실시간 연결이 필요한 채팅방, 실시간 알림, 게임 서버처럼 지속적으로 상태를 주고받는 경우엔 WebSocket이 적합