WebSocket이란? HTTP와 차이·Handshake·실시간 양방향 통신 이해하기

WebSocket이란? HTTP와 차이·Handshake·실시간 양방향 통신 이해하기#

1장 왜 WebSocket이 필요한가#

관제 화면에서 다음 정보를 표시한다고 생각해보겠습니다.

Gate 열림·닫힘

차량 감지

장비 장애

주차 가능 면수

결제 완료

차량 입출차 Event

HTTP API와 Polling만으로도 이런 데이터를 가져올 수 있습니다.

예를 들어 1초마다:

GET /api/gates/gate-01/status

를 호출하면 됩니다.

문제는 상태가 바뀌지 않아도 계속 Request가 발생한다는 것입니다.

Client
→ 상태 바뀌었어?

Server
→ 아니

Client
→ 지금은?

Server
→ 아니

Client
→ 지금은?

Server
→ 차량 들어옴

Client가 많아지고 조회 주기가 짧아질수록 불필요한 Request도 증가합니다.

이 문제를 다른 방식으로 해결하는 기술 중 하나가 WebSocket입니다.

WebSocket은 연결을 한 번 만든 뒤 그 Connection을 유지하면서 Client와 Server가 필요할 때 Message를 주고받을 수 있도록 합니다.

2장 HTTP와 WebSocket의 가장 큰 차이#

일반적인 HTTP 통신은 Request와 Response가 기본 단위입니다.

Client
  │
  │ Request
  ├─────────────>
  │
  │ Response
  <─────────────┤

Client가 먼저 Request해야 Server가 Response합니다.

WebSocket은 연결 이후 구조가 달라집니다.

Client                Server

   │                     │
   │ WebSocket 연결      │
   ├────────────────────>│
   │                     │
   │<──── Message ───────│
   │                     │
   │───── Message ──────>│
   │                     │
   │<──── Message ───────│

연결이 유지되어 있기 때문에 Server가 새로운 Event가 발생했을 때 Client에 Message를 보낼 수 있습니다.

이것이 관제 Dashboard나 실시간 알림 시스템에서 중요한 이유입니다.

3장 WebSocket도 처음에는 HTTP로 시작한다#

WebSocket이 HTTP와 완전히 무관한 별도 연결로 갑자기 시작되는 것은 아닙니다.

WebSocket 연결은 일반적으로 HTTP 요청으로 시작합니다.

Client가 다음과 같은 요청을 보낼 수 있습니다.

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

여기서 핵심은:

Upgrade: websocket
Connection: Upgrade

입니다.

Client는 Server에:

이 HTTP Connection을 WebSocket으로 전환하고 싶다.

라고 요청하는 것입니다.

4장 Server는 101 Switching Protocols로 응답한다#

Server가 WebSocket 전환을 받아들이면 다음과 같은 Response를 보냅니다.

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: ...

101 Switching Protocols는 Protocol 전환을 허용했다는 의미입니다.

이 시점 이후에는 기존 HTTP Request·Response를 반복하는 방식이 아니라 WebSocket Frame을 주고받습니다.

흐름은 다음과 같습니다.

HTTP Request
↓
Upgrade: websocket
↓
HTTP 101
↓
WebSocket Connection
↓
Message ↔ Message

5장 Sec-WebSocket-Key는 인증 Token이 아니다#

Handshake를 처음 보면:

Sec-WebSocket-Key: ...

를 보고 보안 인증 Key라고 생각하기 쉽습니다.

하지만 이 값 자체는 사용자 인증용 Password나 API Key가 아닙니다.

WebSocket Handshake 과정에서 Client와 Server가 정상적인 WebSocket Upgrade를 수행하고 있는지 확인하는 데 사용되는 값입니다.

따라서:

Sec-WebSocket-Key
=
로그인 인증

으로 이해하면 안 됩니다.

사용자나 Device 인증이 필요하다면 별도의 인증 방식을 설계해야 합니다.

6장 WebSocket 연결 이후에는 Message를 주고받는다#

Handshake가 끝나면 양쪽은 WebSocket Frame을 이용해 데이터를 전달합니다.

Message는 크게:

Text

Binary

형태로 전달할 수 있습니다.

예를 들어 관제 Server가 Browser에 다음 Text Message를 보낼 수 있습니다.

{
  "type": "gate-status",
  "gateId": "GATE-01",
  "status": "open"
}

JSON을 Text Message로 보내는 방식입니다.

하지만 WebSocket이 JSON만 지원하는 것은 아닙니다.

Binary Data도 보낼 수 있습니다.

WebSocket
├─ Text Frame
│  └─ JSON 등
│
└─ Binary Frame
   └─ Binary Protocol·Protobuf 등

어떤 Data Format을 사용할지는 Application Protocol이 결정합니다.

7장 WebSocket은 Full Duplex 통신이다#

WebSocket의 중요한 특징 중 하나는 Full Duplex입니다.

연결된 이후에는:

Client → Server

Server → Client

양쪽 모두 필요할 때 Message를 보낼 수 있습니다.

예를 들어:

Gate Controller
→ 차량 감지 Event
→ Server

와 동시에 Server가:

Server
→ 상태 조회 Command
→ Gate Controller

를 보낼 수 있습니다.

HTTP Request·Response처럼 반드시 한쪽 Request 뒤에 Response가 오는 구조만 강제하지 않습니다.

8장 Polling·Long Polling·WebSocket은 무엇이 다른가#

Short Polling#

Request
↓
Response
↓
대기
↓
Request
↓
Response

Client가 계속 상태를 물어봅니다.

Long Polling#

Request
↓
Server 대기
↓
Event 발생
↓
Response
↓
새 Request

Server가 Event가 발생할 때까지 Response를 늦춥니다.

WebSocket#

Connection
↓
지속 유지
↓
Message
↕
Message
↕
Message

연결을 계속 유지하면서 양방향 Message를 주고받습니다.

9장 세 방식을 비교하면 선택 기준이 보인다#

항목 Short Polling Long Polling WebSocket
연결 방식 반복 Request 긴 Request 반복 지속 연결
Server Push 어려움 가능 가능
양방향 통신 HTTP Request 중심 제한적 자연스러움
실시간성 Polling 주기 영향 비교적 좋음 높게 설계 가능
구현 난이도 낮음 중간 상대적으로 높음
연결 관리 단순 필요 중요
재접속 설계 필요 필요 중요
Proxy 설정 비교적 단순 Timeout 고려 Upgrade·Timeout 고려

WebSocket이 항상 가장 좋은 선택은 아닙니다.

요구사항에 맞춰 선택해야 합니다.

10장 주차관제에서는 WebSocket을 어디에 사용할까#

주차관제 시스템을 다음처럼 구성했다고 하겠습니다.

Loop Sensor
↓
Gate Controller
↓
Local Agent
↓
Central Server
↓
Control Dashboard

WebSocket은 특히:

Central Server
↔
Control Dashboard

구간에서 유용할 수 있습니다.

Gate Event가 발생하면 Server가 Browser에 즉시 알립니다.

{
  "type": "vehicle-enter",
  "gateId": "GATE-01",
  "vehicleNumber": "12가3456",
  "timestamp": "2026-09-24T15:30:10+09:00"
}

Browser는 별도의 Polling 없이 즉시 화면을 갱신할 수 있습니다.

11장 장비 자체가 WebSocket Client가 될 수도 있다#

지원되는 장비라면 다음 구조도 가능합니다.

Gate Controller
        │
        │ WebSocket
        ▼
Central Server

장비가 Server로 Connection을 만들고 유지합니다.

차량 Event가 발생하면:

Gate
↓
WebSocket Message
↓
Server

로 바로 전달합니다.

Server도 필요한 경우 같은 Connection을 통해 장비로 Message를 보낼 수 있습니다.

다만 모든 Embedded Device가 WebSocket을 안정적으로 지원하는 것은 아닙니다.

CPU·Memory·Firmware·Network 환경을 확인해야 합니다.

12장 연결이 살아 있다고 장비도 정상이라는 뜻은 아니다#

WebSocket Connection 상태가:

OPEN

이라고 하겠습니다.

그렇다고 Application이 정상이라는 보장은 없습니다.

예를 들어:

TCP Connection 정상

WebSocket Connection 정상

하지만

Device Application Hang

상태일 수도 있습니다.

그래서 Application Level에서 연결 상태를 확인하는 방법이 필요할 수 있습니다.

13장 Ping과 Pong으로 연결 상태를 확인한다#

WebSocket Protocol에는 Control Frame으로 Ping과 Pong이 있습니다.

개념적으로:

Client
→ Ping

Server
→ Pong

또는 반대로 Server가 Ping을 보내고 Client가 Pong으로 응답할 수도 있습니다.

이를 통해 Connection 상태를 확인하는 데 활용할 수 있습니다.

하지만 Ping/Pong이 있다고 해서:

장비의 실제 업무 Logic까지 정상

임을 보장하는 것은 아닙니다.

필요하다면 별도의 Application Heartbeat를 사용할 수도 있습니다.

WebSocket Ping과 Application Heartbeat는 다르다#

WebSocket Ping/Pong:

연결 계층 상태 확인

Application Message:

{
  "type": "heartbeat",
  "deviceId": "GATE-01",
  "status": "normal"
}

는:

Application 상태 확인

용도로 사용할 수 있습니다.

둘을 구분하면 장애 판단이 더 정확해집니다.

14장 WebSocket 연결은 언젠가 반드시 끊어진다고 생각해야 한다#

실제 Network에서는 Connection이 영원히 유지되지 않습니다.

다음 원인으로 끊어질 수 있습니다.

Network 단절

Wi-Fi 변경

Mobile Network 변경

Firewall

NAT Timeout

Proxy Timeout

Server Restart

Deployment

Load Balancer

장비 Restart

Token 만료

그래서 WebSocket Application은:

연결 성공

만 구현해서는 부족합니다.

반드시:

연결 끊김
↓
감지
↓
재접속
↓
상태 복구

까지 설계해야 합니다.

15장 끊기자마자 무한 재접속하면 안 된다#

Server 장애가 발생했다고 하겠습니다.

Client 10,000개가 모두 Connection을 잃었습니다.

모든 Client가:

즉시 reconnect
즉시 reconnect
즉시 reconnect

를 반복하면 Server가 복구되기도 전에 다시 부하를 받을 수 있습니다.

따라서 재연결에는 Backoff를 적용하는 경우가 많습니다.

예:

1초
↓
2초
↓
4초
↓
8초
↓
16초

그리고 Client마다 약간 다른 시간을 사용하도록 Jitter를 추가할 수 있습니다.

16장 재연결하면 놓친 Message는 어떻게 할까#

WebSocket의 중요한 실무 문제입니다.

다음 상황을 생각해보겠습니다.

Event 100
↓
Event 101
↓
Connection 끊김
↓
Event 102
Event 103
Event 104
↓
Reconnect

Client는:

102
103
104

를 보지 못했습니다.

Connection만 복구한다고 Data가 자동으로 복구되는 것은 아닙니다.

그래서 Application 수준에서 별도의 동기화 방식이 필요할 수 있습니다.

Sequence Number를 사용할 수 있다#

각 Event에:

{
  "sequence": 104,
  "type": "gate-status"
}

처럼 Sequence를 붙일 수 있습니다.

Client가 마지막으로 받은 값이:

101

인데 새 Message가:

105

라면:

102~104 누락 가능성

을 감지할 수 있습니다.

Snapshot API와 함께 사용할 수도 있다#

WebSocket은 실시간 Event 전달에 사용하고 HTTP API는 전체 상태 복구에 사용하는 방식입니다.

WebSocket
→ 실시간 Event

HTTP GET
→ 현재 전체 상태

Reconnect 후:

WebSocket 재연결
↓
GET /api/status
↓
현재 상태 재동기화

하는 방법입니다.

실무에서 매우 유용한 조합입니다.

17장 ACK가 필요하면 Application에서 설계해야 한다#

WebSocket을 사용한다고 모든 업무 Message의 처리가 자동으로 확인되는 것은 아닙니다.

예:

{
  "messageId": "cmd-1001",
  "type": "open-gate"
}

를 보냈다고 하겠습니다.

필요하다면 상대가:

{
  "messageId": "cmd-1001",
  "type": "ack",
  "status": "accepted"
}

같은 Application ACK를 보내도록 설계할 수 있습니다.

하지만:

ACK
=
Gate 실제 개방 완료

라고 단정하면 안 됩니다.

실제 동작 완료 Event를 별도로 둘 수 있습니다.

Command
↓
ACK
↓
Motor 동작
↓
Sensor 확인
↓
GATE_OPENED

18장 HTTP 101 이후에는 HTTP Status Code를 주고받는 방식이 아니다#

Handshake 단계에서는:

HTTP/1.1 101 Switching Protocols

같은 HTTP Response를 사용합니다.

하지만 WebSocket 연결로 전환된 이후 Message마다:

200 OK

404 Not Found

500 Internal Server Error

같은 HTTP Status Code를 사용하는 것은 아닙니다.

Application Message 자체에 상태를 정의할 수 있습니다.

예:

{
  "type": "error",
  "code": "DEVICE_OFFLINE",
  "message": "Gate controller is offline"
}

처럼 설계할 수 있습니다.

19장 ws와 wss는 무엇이 다른가#

WebSocket URL은 흔히 다음 형태입니다.

ws://

또는:

wss://

wss는 TLS를 적용한 WebSocket입니다.

관계를 단순화하면:

ws
→ WebSocket

wss
→ WebSocket over TLS

입니다.

운영 환경에서 인증 정보나 장비 데이터가 오간다면 일반적으로 wss를 사용하는 방향이 적절합니다.

20장 WebSocket 인증은 어떻게 할까#

WebSocket은 연결 전에 인증 전략을 정해야 합니다.

가능한 방식은 Application과 Client 환경에 따라 다릅니다.

예를 들어:

Session Cookie

Bearer Token

Short-lived Connection Token

mTLS

Gateway Authentication

등을 사용할 수 있습니다.

중요한 것은:

연결됐으니 인증됨

이라고 생각하면 안 된다는 것입니다.

Token을 URL Query에 넣을 때는 주의한다#

예:

wss://example.com/ws?token=SECRET

같은 방식을 구현할 수도 있지만 URL이:

Proxy Log

Access Log

Browser History 일부 환경

Monitoring System

등에 남을 가능성을 고려해야 합니다.

민감한 Credential을 URL에 노출하는 설계는 신중해야 합니다.

21장 Origin 검증도 고려해야 한다#

Browser 기반 WebSocket에서는 Server가 허용된 Origin인지 확인하는 정책을 둘 수 있습니다.

특히 Web Application에서 인증 Cookie와 WebSocket을 함께 사용하는 경우:

어떤 Site에서 연결 요청이 발생했는가?

를 검증하는 것이 중요할 수 있습니다.

Authentication과 Origin Validation은 서로 다른 문제입니다.

22장 Proxy와 Load Balancer가 WebSocket을 이해해야 한다#

실제 운영 구조는 다음처럼 될 수 있습니다.

Browser
↓
Firewall
↓
Load Balancer
↓
Reverse Proxy
↓
WebSocket Server

Handshake가 중간 장비를 통과해야 합니다.

문제가 발생하면 다음을 확인합니다.

Upgrade Header 전달

Connection Header 처리

HTTP Version

Idle Timeout

Backend Routing

TLS Termination

입니다.

연결은 되는데 일정 시간이 지나면 끊긴다면#

예:

정확히 60초마다 Disconnect

가 반복된다면 Application Bug라고 바로 판단하지 않습니다.

가능한 원인:

Proxy Idle Timeout

Load Balancer Idle Timeout

Firewall Session Timeout

Application Timeout

등을 확인합니다.

일정한 주기로 끊기는 문제는 중간 Network 장비의 Timeout과 관련된 경우가 있습니다.

23장 Load Balancing도 HTTP API와 조금 다르게 생각해야 한다#

일반 HTTP Request는:

Request 1
→ Server A

Request 2
→ Server B

처럼 분산하기 쉽습니다.

WebSocket은 Connection이 오래 유지됩니다.

Client 1
──────── Server A

Client 2
──────── Server B

Client 3
──────── Server A

Server 간에 실시간 Message를 공유해야 한다면 추가 구조가 필요할 수 있습니다.

예:

WebSocket Server A
       │
       │
Message Broker
       │
       │
WebSocket Server B

Kafka, Redis Pub/Sub 또는 별도 Broker 등을 이용하는 Architecture를 구성할 수도 있습니다.

24장 WebSocket Message 크기도 관리해야 한다#

WebSocket으로 무엇이든 보낼 수 있다고 Payload 크기를 무제한으로 두면 문제가 생길 수 있습니다.

예를 들어 Camera Image 전체를 매번 WebSocket으로 전송하면:

Network 사용량 증가

Memory 사용량 증가

Message Parsing 비용 증가

Slow Client 문제

등이 발생할 수 있습니다.

큰 File이나 Image는:

Object Storage
↓
URL
↓
WebSocket에는 Metadata만 전달

하는 방식을 고려할 수도 있습니다.

25장 느린 Client도 문제를 만들 수 있다#

Server가 초당 100개의 Message를 생성하는데 Client는 초당 10개밖에 처리하지 못한다고 하겠습니다.

그러면:

Server 생성 속도
>
Client 처리 속도

가 됩니다.

이런 상황에서는:

Send Buffer 증가

Memory 사용 증가

Latency 증가

Connection 종료

등의 문제가 생길 수 있습니다.

따라서 다음 정책이 필요할 수 있습니다.

Queue 크기 제한

오래된 상태 Message 폐기

최신 Snapshot 우선

Client별 Rate Limit

Connection 종료 기준

입니다.

26장 상태 업데이트와 Event는 다르게 다룰 수 있다#

예를 들어 Gate 상태가:

CLOSED
CLOSED
CLOSED
OPEN

으로 계속 전달된다고 하겠습니다.

상태 정보라면 오래된 값보다:

가장 최신 상태

가 중요할 수 있습니다.

반면:

차량 입차 Event 100

결제 Event 101

출차 Event 102

는 하나라도 잃으면 문제가 될 수 있습니다.

따라서:

State
→ 최신 값 중심

Event
→ 순서·누락·중복 관리

처럼 다른 전략을 사용할 수 있습니다.

27장 WebSocket을 쓴다고 Message 전달이 자동으로 보장되는 것은 아니다#

WebSocket은 TCP 위에서 동작하므로 연결된 상태에서는 TCP의 순서 보장과 재전송 특성을 이용합니다.

하지만 Application 관점에서는:

연결이 끊긴 동안 발생한 Event

Server 처리 전에 Disconnect된 Message

Application Restart

Reconnect 과정

등을 별도로 처리해야 합니다.

즉:

WebSocket
=
업무 Message 영구 보장

은 아닙니다.

업무적으로 중요한 Event라면:

Message ID

Sequence

ACK

Persistent Queue

Event Store

재동기화 API

등을 추가로 설계할 수 있습니다.

28장 관제 시스템 구조를 하나 만들어보자#

예를 들어 다음 구조를 사용할 수 있습니다.

Gate Controller
↓
HTTP POST
↓
API Server
↓
Database / Event Broker
↓
WebSocket Server
↓
Control Dashboard

차량 입차 Event:

Gate
↓
POST /events
↓
Server 저장
↓
WebSocket Push
↓
관제 화면

이 구조의 장점은 Device와 Browser가 반드시 동일한 Protocol을 사용할 필요가 없다는 것입니다.

Device → Server
HTTP REST

Server → Browser
WebSocket

처럼 역할에 맞게 분리할 수 있습니다.

29장 WebSocket 장애를 계층별로 진단한다#

연결 자체가 안 된다#

확인:

DNS

IP

Port

Firewall

TLS

Proxy

WebSocket Endpoint

HTTP Response가 101이 아니다#

확인:

Upgrade Header

Authentication

Proxy Configuration

URL

연결 직후 끊긴다#

확인:

Authentication

Protocol 오류

Server Log

Message Format

일정 시간 후 끊긴다#

확인:

Idle Timeout

Ping / Pong

Proxy

Load Balancer

Firewall

Reconnect 후 화면 상태가 이상하다#

확인:

누락 Event

Sequence

Snapshot Sync

중복 Message

이렇게 나누면 WebSocket이 안 된다는 하나의 증상을 훨씬 구체적으로 분석할 수 있습니다.

30장 현장 판단표#

증상 먼저 확인할 항목
WebSocket 연결 실패 URL·Port·TLS·Firewall
101이 나오지 않음 Upgrade·Proxy·인증
일정 시간 후 종료 Idle Timeout·Ping/Pong
Message가 안 옴 Subscription·Server Logic
Message가 중복됨 Reconnect·Message ID
Reconnect 후 Data 누락 Sequence·Snapshot
Server Memory 증가 Connection·Queue·Slow Client
일부 Client만 느림 Network·Client 처리 속도
대량 접속 시 실패 Connection Limit·File Descriptor·Load Balancer
화면과 실제 장비 상태 불일치 Event 누락·Snapshot 동기화

31장 흔히 하는 잘못된 판단#

WebSocket은 HTTP보다 무조건 빠르다#

항상 그렇지는 않습니다.

지연은 Network, Server 처리, Message 크기와 Architecture 전체의 영향을 받습니다.

WebSocket은 TCP를 사용하지 않는다#

일반적인 WebSocket은 TCP 기반으로 동작합니다.

WebSocket이면 연결이 절대 끊기지 않는다#

실제 Network에서는 언제든 Connection이 끊길 수 있습니다.

Ping/Pong이 정상이면 장비 전체가 정상이다#

Connection은 정상이어도 Application이나 실제 장비 Hardware에 문제가 있을 수 있습니다.

WebSocket이면 Message 유실을 걱정할 필요가 없다#

Connection 단절과 Application Restart 등을 고려한 별도 복구 정책이 필요합니다.

HTTP와 WebSocket 중 하나만 사용해야 한다#

그렇지 않습니다.

HTTP REST와 WebSocket을 역할에 따라 같이 사용하는 Architecture가 흔합니다.

32장 WebSocket 설계 체크리스트#

□ 정말 Server Push가 필요한가?

□ 양방향 통신이 필요한가?

□ Polling으로 충분하지 않은가?

□ WebSocket Endpoint를 정의했는가?

□ wss를 사용하는가?

□ 연결 인증 방법을 정의했는가?

□ Origin 정책을 검토했는가?

□ Ping·Pong 정책이 있는가?

□ Application Heartbeat가 필요한가?

□ Idle Timeout을 확인했는가?

□ Proxy Timeout을 확인했는가?

□ Load Balancer가 WebSocket을 지원하는가?

□ Reconnect Backoff가 있는가?

□ Jitter를 적용했는가?

□ Message ID가 있는가?

□ Sequence가 필요한가?

□ Duplicate 처리가 가능한가?

□ Reconnect 후 Snapshot 동기화가 가능한가?

□ Message Queue 크기를 제한했는가?

□ Slow Client 정책이 있는가?

□ 대규모 Connection Monitoring을 하는가?

33장 자기 점검#

WebSocket 연결은 어떻게 시작되는가#

일반적으로 HTTP Upgrade Request로 Handshake를 시작하고 Server가 101 Switching Protocols로 받아들이면 WebSocket 통신으로 전환됩니다.

WebSocket과 Polling의 가장 큰 차이는 무엇인가#

Polling은 Client가 반복해서 Server에 상태를 물어보지만 WebSocket은 연결을 유지하면서 Server와 Client가 필요할 때 Message를 주고받을 수 있습니다.

Sec-WebSocket-Key는 사용자 인증 Token인가#

아닙니다. WebSocket Handshake에 사용하는 값이며 Application 사용자 인증은 별도로 설계해야 합니다.

Connection이 끊겼다가 다시 연결되면 놓친 Message도 자동으로 복구되는가#

아닙니다. 중요한 Message라면 Sequence, Message ID, Queue 또는 Snapshot API 같은 별도의 복구 방법이 필요합니다.

WebSocket이 연결되어 있으면 실제 Gate도 정상인가#

아닙니다. WebSocket 연결 상태, Application 상태, Device 상태와 실제 물리 상태는 각각 별도로 확인해야 합니다.

34장 이 글을 마치며#

WebSocket의 핵심은 단순히:

Connection을 오래 유지한다.

는 것이 아닙니다.

전체 흐름은 다음과 같습니다.

HTTP Upgrade
↓
101 Switching Protocols
↓
Persistent Connection
↓
Text / Binary Message
↓
Full Duplex 통신
↓
Ping / Pong
↓
Disconnect
↓
Reconnect
↓
상태 재동기화

입니다.

그리고 실제 운영 시스템에서는 여기에:

Authentication

TLS

Message ID

Sequence

Retry

Backoff

Queue

Proxy

Load Balancer

Monitoring

까지 함께 고려해야 합니다.

특히 다음 다섯 가지를 기억하면 됩니다.

WebSocket은 HTTP Upgrade Handshake로 시작한 뒤 지속적인 Connection에서 양방향 Message를 주고받는 Protocol입니다.

Polling과 달리 Server가 Event 발생 시 Client에 바로 Message를 보낼 수 있어 실시간 상태 전달에 유용합니다.

Persistent Connection은 영구 연결을 의미하지 않으므로 끊김 감지와 Backoff 기반 재접속을 반드시 고려해야 합니다.

WebSocket 자체가 업무 Message의 영구 저장이나 누락 복구를 보장하지 않으므로 중요한 Event에는 Message ID·Sequence·Queue·Snapshot 동기화 같은 Application 설계가 필요합니다.

WebSocket 연결 성공과 Application 정상, 실제 장비 동작 성공은 서로 다른 상태이므로 관제 시스템에서는 각각을 별도로 추적해야 합니다.

결국 WebSocket을 이해한다는 것은 ws:// 주소를 만들고 Connection을 여는 방법을 아는 것이 아닙니다.

연결을 유지하면서 실시간 Message를 전달하고, 연결이 끊겼을 때 안전하게 복구하며, 누락·중복·지연이 발생해도 최종 상태를 다시 맞출 수 있도록 전체 통신 구조를 설계하는 것이 핵심입니다.

이 페이지의 목차