사이드 프로젝트에서 webSocket으로 스트리밍을 구현했는데 이 과정에서 웹소켓에 대한 이해도를 위해 공부하며 webSocket의 등장 이전의 방식들과 webSocket에 대해 정리해보았다.
webSocket은 웹페이지와 서버 간 실시간 통신을 위해 만들어졌다.
기존의 http는 단방향 통신을 위해 만들어진 방법이다.
webSocket 이전에는 실시간 통신을 위해 http에 트릭을 사용해서 실시간인 것처럼 작동하게 하는 기술을 사용했다.
WebSocket
클라이언트와 서버를 연결하고 실시간으로 양방향 통신이 가능하도록 하는 통신 프로토콜
- HTML5 표준기술로, 2011년 RFC 6455에 의해 표준화
- TCP에서 동작함
- WebSocket HandShake 요청을 통해서 HTTP -> Socket 통신으로 전환
WebSocket의 특징
- 양방향 통신(Full Duplex)
- 데이터 송수신 동시에 처리 가능
- 클라이언트와 서버가 원할 때 데이터를 주고받을 수 있음
- 하나의 TCP 커넥션으로 전이중(full duplex) 통신 채널을 제공
- 실시간 네트워킹
- 연속된 데이터를 빠르게 노출시킬 수 있음
- 여러 단말기에서 빠른 데이터 교환이 가능
- Stateful
- 주로 채팅, 게임, 주식 등에 사용
🔎 full duplex
- 두 대의 단말기가 데이터를 송수신하기 위해 동시에 각각 독립된 회선을 사용하는 통신 방식
- 송신선과 수신선이 각각 존재함 -> 데이터 송신과 동시에 수신 가능
기존의 HTTP를 이용한 실시간 통신
HTTP
- 텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을 수 있는 프로토콜
- 통신방법은 단방향
- 클라이언트에서 서버로 Request(요청) -> 서버는 클라이언트로 Response(응답)
- 클라이언트의 request가 없다면 웹 서버에서는 직접적으로 클라이언트에게 구성요소와 정보들을 보낼 수 없다.
- request-response라는 하나의 사이클이 종료 -> 브라우저-서버의 통신도 종료
이러한 HTTP 통신방식으로 실시간 채팅을 구현한다면 상대방의 메세지를 읽기 위해 각각의 클라이언트 모두가 매번 새로고침을 통해 서버에 request-response를 요청하게 될 것이다.
그래서 HTTP는 polling, long polling 등의 기술을 도입하여 이를 해결하고자 했다.
Polling
클라이언트가 일정 주기로 서버에 http request를 보내서 이벤트 내용을 전달받는 방식
HTTP의 Stateless와 Connectionless
- 서버에서 클라이언트에게 발송할 데이터가 생겨도 일방적으로 응답 전송 불가능
- 요청을 받아야만 응답 보내기 가능
이를 해결한 방식이 Polling!
- 요청을 주기적으로 계속 보내면서 서버가 전달하고자하는 게 있는지, 이벤트가 발생했는지 확인해서 가져오는 것이다.
- HTTP 오버헤드 발생 - 불필요한 요청 발생
- 커넥션을 맺기 위해 비용이 계속 발생
- 클라이언트가 많아질수록 서버 부담이 급증
client: 안녕! 거기 채팅 메시지 좀 줄래?
server: 없어요.
client: 안녕! 거기 채팅 메시지 좀 줄래?
server: 아니 없어요.
client: 안녕! 거기 채팅 메시지 좀 줄래?
server: 어 생겼어요! 줄게요!Long Polling
클라이언트 요청에 대해서 서버가 일정시간 기다렸다가 클라이언트에게 응답을 주는 방식
- Polling이 계속 요청을 날린다면 Long Polling은 시간을 최대한 늘려서 이벤트가 발생할 때까지 대기하도록 한다.
- 먼저 클라이언트에서 서버로 일단 http request를 보낸다.
- 서버는 커넥션을 끊지 않고 기다린다.
- 만약 이벤트가 발생하는 경우(메시지가 온 경우) 서버에서 response를 전달하고 연결이 종료된다.
- 응답 후 클라이언트는 다시 서버에게 요청을 보낸다.
client: 안녕! 거기 채팅 메시지 좀 줄래?
server: (기다리는 중)...'없다'는 상태값 설정 되어있을 시 없음을 전달, 아니면 올 때까지 기다려.....
client: 안녕! 거기 채팅 메시지 좀 줄래?
server: (기다리는 중에 채팅 메시지 옴)...왔다! 여기있어!- 데이터가 빈번히 변하는 경우 polling보다 많은 요청-응답을 하게 될 수 있음
- 다수의 클라이언트에서 동시 이벤트 발생 시 요청 또한 동시에 보내므로 서버 부담이 급증
WebSocket의 동작
WebSocket의 동작은 핸드 쉐이킹(Opening Handshake), 데이터 전송(Data Transfer), 연결 종료(Close Handshake)의 과정으로 이루어진다.
- 웹 소켓은 최초 접속 시 HTTP 프로토콜 위에서 handshake한다.
- 이후 프로토콜이 http/https에서 ws/wss로 변경된다.
- 웹소켓은 커넥션이 Open-Close 되어있는지를 체크하고 브라우저가 서버와 통신을 Open한 경우에는 양방향 통신이 가능하며 Close하기 전까지는 통신이 유지된다.
🔎 handshake 악수
정상적인 통신을 하기 전에, 일련의 과정을 거쳐 연결을 성립시키는 것
WebSocket의 한계
- WebSocket을 미지원하는 브라우저의 경우 동작하지 않는다.
- sever-client중간에 위치한 proxy가 upgrade헤더를 해석하지 못해 서버에 전달하지 못할 수 있다.
- server-client 중간에 위치한 proxy가 유휴상태에서 도중에 커넥션이 조기 종료될 수 있다.
이러한 문제들을 해결하기 위해 클라이언트에서는 보통 SockJS와 Socket.io같은 라이브러리를 사용한다.
- HTML5 이전의 기술로 구현된 서비스에서 WebSocket과 유사한 실시간성을 보장하도록 함
- SockJS는 stomp 프로토콜을 따르기 때문에 서버가 스프링(자바)일 때 사용함
- Socket.io는 서버가 Node.js인 경우 사용함
SockJS와 Socket.io와 STOMP에 대해서는 다음글에 이어진다.
