[WebSocket] 웹소켓 정리 ↔️ | 개념, 특징, 작동방식, 장단점 등등

[WebSocket] 웹소켓 ↔️

개념, 특징, 작동방식, 장단점 등등 구현을 제외한 정리입니다.

---

📌 웹소켓

웹소켓은 클라이언트와 서버 간의 실시간 양방향(전이중) 통신을 가능하게 하는 프로토콜이다.

기존 HTTP는 요청–응답 기반이라 서버가 클라이언트에 직접 데이터를 보낼 수 없었지만(단방향 통신 한계), 웹소켓은 한 번 연결이 맺어지면 서버 ↔ 클라이언트 간 자유로운 데이터 송수신이 가능하다.

전이중 (Full-Duplex) 통신: 클라이언트와 서버가 서로에게 동시에 데이터를 전송할 수 있는 방식

상태 유지 (Stateful): 한 번 연결(Connection)을 맺으면 명시적으로 연결을 끊기 전까지 지속적으로 유지

---

⚙️ 작동 방식 (Handshake와 프로토콜 스위칭)

웹소켓은 HTTP 프로토콜을 기반으로 시작하여, 통신 중에는 웹소켓 프로토콜로 전환하는 독특한 방식을 사용한다.

1. 핸드셰이크 (Handshake): 클라이언트가 서버에 일반 HTTP 요청 보냄.
   • 이 요청에는 `Upgrade: websocket` 및 `Connection: Upgrade` 헤더가 포함되어 "웹소켓 연결로 전환하고 싶다"는 의사 전달
2. 프로토콜 스위칭 (Protocol Switching): 서버가 이를 수락하면, 연결이 HTTP에서 웹소켓 프로토콜(ws 또는 wss)로 변경
3. 지속적인 연결: 프로토콜 스위칭이 완료된 후부터는 해당 연결을 통해 서버와 클라이언트 모두 순서에 관계없이 자유롭게 데이터를 주고받을 수 있음

즉,
1. 클라이언트 → 서버
   • HTTP 요청을 통해 “웹소켓으로 연결하자”는 요청 전송 (Handshake 요청)

2. 서버 → 클라이언트
  • 수락 시 HTTP 응답으로 연결 승인

3. 연결 후
  • HTTP가 아닌 웹소켓 프로토콜(WS/WSS) 로 통신 시작
  • 메시지를 주고받으며 연결 유지

4. 종료 시
  • 한쪽이 close 프레임 전송 → 상대방이 응답 후 연결 종료

 

+) 비정상적 종료 상황

• 지정된 시간동안 메시지 없을 시 확인 패킷 보내기
• 주기적으로 핑퐁 프레임 주고 받아서 접속 여부 확인

---

📌 헤더 및 HandShake 분석

• `Connection : Upgrade`
  • HTTP 통신 → 웹소켓 통신으로 업그레이드 요청

• `Sec-WebSocket-Key : ~`
  • 서버 요청 받은 후 → CUID라 불리는 정해진 문자열을 그 키에 이어붙인 뒤 SHA-1로 계산해서 다시 base64로 인코딩
  • 이 값 다시 헤더에 담아 클라이언트에 보냄
  • 클라이언트 → 자기가 보낸 키로부터 생성된 값이 맞는지 확인

---

📌 특징

• HTML5 표준에 새롭게 추가
• 텍스트 / 바이너리 데이터 모두 전송 가능
• 메시지를 프레임 단위로 주고받음 → 오버헤드 적음
• HTTP 대비 헤더가 작고 효율적
• TCP 기반으로 순서와 신뢰성 보장
• 기본 프로토콜: ws://, 보안 버전: wss:// (마치 HTTP / HTTPS 와 같음)
  → 보안과 신뢰성 차이

+) 차이점
• WebSocket : 응용 계층인 7계층 (TCP 소켓 기반으로 작동)
• TCP, UDP Socket : 전송 계층인 4계층

---

📌 장점

• 오버헤드가 적고 지속 연결 유지로 실시간성 우수
• Long Polling보다 자원 소모 적음
• TCP 기반으로 안정적인 데이터 전송 가능

---

⚠️ 단점 및 고려사항

문제	설명	해결 방안
구현 복잡도	연결 지속성 관리, 예외 처리 필요	프레임워크(STOMP, SockJS 등) 활용
로드밸런싱	연결 유지 특성상 서버 간 분배 어려움	NGINX, ELB 등 WebSocket 지원 LB 사용
메시지 크기 제한	브라우저/서버별로 제한 존재	대용량은 분할 전송 또는 다른 프로토콜 사용
보안 문제	기본 WS는 암호화 미지원	SSL/TLS 기반의 WSS 사용
서버 부담	다수 연결 유지 시 자원 증가	커넥션 풀 관리, 스케일링 고려

 

---

📌 WebSocket vs 기존 방식

방식	특징	단점
Polling	클라이언트가 주기적으로 서버에 요청	비효율적, 지연
Long Polling	응답이 생길 때까지 서버가 요청 유지	자원 부담
Streaming (SSE)	서버 → 클라이언트 단방향 실시간 전송	클라이언트 → 서버 불가
WebSocket	양방향 통신, 효율적 실시간 처리	구현 복잡, 자원 관리 필요

 

특징	웹소켓 (WebSocket)	HTTP 폴링 (Polling) / 롱 폴링 (Long Polling)
통신 방향	양방향 (Full-Duplex)	클라이언트 시작 단방향 요청-응답
연결 상태	상태 유지 (Stateful) 및 지속적 유지	요청마다 연결/해제 (Stateful 아님)
지연 시간	매우 짧음 (Low Latency). 즉각적인 통신 가능.	이벤트 발생 시까지 대기/주기적 요청 필요. 지연 시간 김.
네트워크 오버헤드	최소화. 핸드셰이크 후에는 작은 프레임 헤더만 사용.	매 요청/응답마다 전체 HTTP 헤더를 포함하여 비효율적.
서버 부하	낮음. 지속적인 연결을 통해 서버 자원을 효율적으로 사용.	높음. 이벤트가 없어도 불필요한 요청(트래픽)이 발생.

 

---

📌 STOMP / Socket.io, SockJS

• STOMP (Simple Text Oriented Message Protocol)
  • 텍스트 기반 메시지 프로토콜
  • pub/sub 구조: 토픽 구독자에게 메시지 전달
  • 주로 채팅, 알림 서비스에 사용
• Socket.io / SockJS
  • 브라우저가 웹소켓 미지원일 경우 HTTP 방식으로 대체 (fallback)
  • 웹소켓 → HTTP Streaming → HTTP Long Polling 순서로 전환

---

📈 정리

웹소켓은 실시간 양방향 통신을 가능하게 하여 채팅, 알림, 주가 시스템 등에서 효율적이며,

보안(WSS)과 서버 부하 관리, 로드밸런싱 고려가 중요하다.

 

다음에는 구현과 관련된 내용으로 포스팅하겠습니다. 감사합니다.

 

---

Reference

• https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/socket/config/annotation/WebSocketHandlerRegistration.html
• https://www.youtube.com/watch?v=2oMPf-ueQic
• https://www.youtube.com/watch?v=SwLKZUj9urY