subiniwiki

[네트워크] 실시간 통신 기술 - ws:// 와 wss:// 차이와 WebSocket 동작 원리

subindev 2026. 4. 29. 09:40

이전에 Polling, Long Polling, WebSocket의 차이를 정리하면서
WebSocket은 “연결을 유지하면서 실시간 통신을 하는 방식”이라고 설명했다.

그런데 조금 더 깊게 들어가보면 궁금한 점이 생긴다.

  • WebSocket은 어떻게 연결되는 걸까?
  • 왜 처음에는 HTTP로 시작할까?
  • 연결 이후에는 왜 HTTP가 아닐까?
  • ws:// 와 wss:// 는 무슨 차이일까?

이번 글에서는 WebSocket이 실제로 연결되는 과정과 내부 동작 방식을 정리해보려고 한다.

1. 처음부터 WebSocket인 것은 아니다

많이 헷갈리는 부분인데,
WebSocket 연결은 처음부터 WebSocket 프로토콜로 시작하지 않는다.

처음에는 일반 HTTP 요청으로 시작한다.

즉:

클라이언트 → 서버 : HTTP 요청

으로 연결을 시작한 뒤,
이 연결을 WebSocket으로 “업그레이드(Upgrade)” 하는 방식이다.

왜 굳이 HTTP로 시작할까?

이유는 간단하다.

기존 웹 환경과 호환성을 유지하기 위해서다.

브라우저는 기본적으로 HTTP 통신을 기반으로 동작한다.

그래서:

  • 기존 웹 서버
  • 프록시 서버
  • 방화벽
  • 네트워크 인프라

와 자연스럽게 연결되기 위해 처음에는 HTTP를 사용한다.

즉, WebSocket은 기존 HTTP 위에서 시작되는 확장 프로토콜이라고 볼 수 있다.

2. WebSocket Handshake 과정

WebSocket 연결 과정에서 가장 중요한 부분이 Handshake다.

클라이언트가 서버에게:

“나 WebSocket으로 통신하고 싶은데 가능해?”

라고 요청하고,
서버가 허용하면 연결이 업그레이드된다.

클라이언트 요청

브라우저는 서버에 다음과 비슷한 HTTP 요청을 보낸다.

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

여기서 중요한 건:

Upgrade: websocket

이다.

이 헤더가:

"HTTP 연결을 WebSocket으로 바꾸고 싶다"

라는 의미다.

서버 응답

서버가 WebSocket 연결을 허용하면 다음과 같이 응답한다.

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

여기서 핵심은:

101 Switching Protocols

이다.

즉:

"좋아. 이제부터 HTTP 말고 WebSocket 프로토콜로 통신하자"

라는 의미다.

이 순간부터 연결이 WebSocket으로 전환된다.

3. 연결 이후에는 왜 HTTP가 아닐까?

Handshake 이후에는 더 이상 HTTP Request/Response 구조를 사용하지 않는다.

원래 HTTP는 이런 구조다.

요청 → 응답 → 연결 종료

하지만 WebSocket은:

연결 유지

가 핵심이다.

즉, 한 번 연결되면 끊지 않고 계속 데이터를 주고받는다.

그래서 이후에는 HTTP 헤더를 반복해서 보내지 않는다.

HTTP 방식의 문제점

만약 채팅을 HTTP만으로 처리한다고 가정하면:

메시지 보낼 때마다
HTTP 요청 + HTTP 헤더 전송

이 계속 반복된다.

즉:

  • 요청 생성
  • 헤더 전송
  • 응답 대기
  • 연결 관리

같은 비용이 계속 발생한다.

실시간 서비스에서는 굉장히 비효율적이다.

WebSocket은 왜 빠를까?

WebSocket은 최초 연결 이후에는 헤더를 반복적으로 보내지 않는다.

즉:

연결 1번
→ 이후 데이터만 계속 전송

하는 구조다.

그래서:

  • 네트워크 오버헤드 감소
  • 빠른 데이터 전송
  • 실시간 처리 가능

같은 장점이 생긴다. 채팅이나 게임에서 WebSocket을 많이 사용하는 이유도 이 때문이다.

4. ws:// 와 wss:// 차이

WebSocket 주소를 보면 보통 두 가지가 있다.

ws://
wss://

ws://

일반 WebSocket 연결이다.

HTTP와 비슷하게 암호화되지 않은 연결이다.

즉:

HTTP  ↔ ws

관계라고 볼 수 있다.

wss://

SSL/TLS 기반으로 암호화된 WebSocket 연결이다.

HTTPS의 WebSocket 버전이라고 생각하면 이해하기 쉽다.

즉:

HTTPS ↔ wss

관계다.

왜 wss:// 를 많이 사용할까?

요즘 대부분 사이트는 HTTPS 기반이다.

브라우저 보안 정책 때문에 HTTPS 사이트에서는 보통 ws:// 연결을 차단한다.

즉:

HTTPS 페이지
→ wss:// 사용 권장

이다.

실제 서비스에서는 대부분 wss:// 를 사용한다고 보면 된다.

5. WebSocket은 TCP 기반이다

이 부분도 꽤 중요하다.

WebSocket은 TCP 위에서 동작한다.

즉:

WebSocket
→ TCP 기반
→ 연결 지향 방식

이다.

그래서:

  • 데이터 순서 보장
  • 신뢰성 보장
  • 패킷 유실 최소화

같은 특징을 가진다.

반대로 UDP 기반처럼 빠르지는 않지만 안정적이다.

6. WebSocket의 한계

WebSocket은 강력하지만 단점도 있다.

연결 유지 비용

사용자마다 연결을 계속 유지해야 한다.

즉 사용자가 많아질수록:

  • 메모리 사용 증가
  • 서버 연결 수 증가

문제가 발생할 수 있다.

서버 구조 복잡도 증가

실시간 채팅 같은 서비스를 여러 서버로 운영하면:

사용자 A는 1번 서버
사용자 B는 2번 서버

처럼 연결될 수 있다.

이 경우 서버끼리 메시지를 공유해야 한다.

그래서 실제 서비스에서는 Redis Pub/Sub 같은 구조를 함께 사용하는 경우가 많다.

정리

WebSocket은 단순히 “실시간 통신 기술”이라기보다,
HTTP의 한계를 보완하기 위해 등장한 지속 연결 기반 프로토콜에 가깝다.

핵심 흐름을 정리하면:

1. HTTP 요청으로 시작
2. Upgrade 요청
3. Handshake 수행
4. WebSocket 연결 전환
5. 연결 유지 상태로 양방향 통신

 

그리고 가장 중요한 특징은:

서버와 클라이언트가
자유롭게 데이터를 주고받을 수 있다

는 점이다. 

 

 

처음에는 단순히 “WebSocket은 실시간 통신용” 정도로만 알고 있었는데,
실제로는 HTTP에서 시작해서 프로토콜을 업그레이드한다는 점이 꽤 흥미로웠다.

특히 왜 HTTP 기반 방식(Polling, Long Polling)이 비효율적이었는지,
왜 WebSocket이 등장하게 되었는지를 같이 이해하니까 전체 흐름이 훨씬 자연스럽게 연결되는 느낌이었다.