WebSocket에 대해 알아보자
WebSocket - 실시간 양방향 통신 프로토콜
HTTP 기반 통신 한계
HTTP는 기본적으로 client의 request에 대해 server가 response를 주는 request-response 모델임
HTTP/1.1 부터는 keep-alive로 하나의 TCP connection을 재사용할 수 있지만, 여전히 *half-duplex 방식이라 server가 client에게 먼저 데이터를 push할 수 없음
따라서 실시간 양방향 통신을 흉내내려면 아래와 같은 기법을 사용해야함
1. Polling
Client가 주기적으로 server에게 request를 보내 새로운 데이터가 있는지 확인
데이터가 없어도 request를 계속 보내기 때문에 빈 response가 발생함 -> 불필요한 http overhead가 커짐
2. Long Polling
Server가 응답 가능한 데이터가 없으면 해당 request를 holding한 채로 wait
데이터가 준비되면 그때 reponse를 보냄 -> server가 어느정도 push 하는 효과 보여줌
client는 응답 받자마자 바로 다음 request 보냄
각 request에는 timeout이 존재하므로 client는 주기적으로 reconnect 해야 함 -> 여전히 resource-intensive
WebSocket
WebSocket은 위와 같은 http 기반 방식의 한계를 해결하기 위해 등장한 프로토콜임
하나의 unique connection을 열린 상태로 계속 유지할 수 있어 latency 문제를 제거할 수 있음
또한 full-duplex asynchronous messaging을 지원함 -> client와 server가 동일한 TCP connection 위에서 동시에 message를 stream할 수 있음
HTTP처럼 매 요청마다 큰 header를 붙이는 대신 작은 frame header(2~14bytes)만으로 데이터를 주고받기 때문에 overhead가 훨씬 적음
워래는 browser와 server간 통신 위해 설계 되었지만 WhatsApp이나 Facebook Messenger 같은 messagin app에서도 널리 사용됨
WebSocket 방식
1. Handshake 요청
Client가 HTTP GET 요청에 {Upgrade: websocket, Connection: Upgrade} 헤더를 담아 보내 WebSocket connection 시도함
2. Protocol upgrade
Server가 Websocket을 지원하면 101 Switching Protocols 응답을 보내 handshake를 완료함
이때 새로운 TCP connection이 만들어지는 게 아니라 기존 HTTP connection을 그대로 유지한 채로 protocol만 WebSocket으로 전환됨
3. 양방향 통신 시작
이 시점부터 client와 server 양쪽 모두 자유롭게 데이터 주고받기 가능
WebSocket Handler
WebSocket이 사용될 때는 보통 user별로 WebSocket handler가 연결됨
WebSocket handler는 lightweight server machine으로 모든 active user에 대한 open connection을 유지하는 역할을 함
물론 WebSocket도 한계가 존재함
Stateful connection이라 server scaling이 까다로움 (load balance, sticky session 이슈)
Connection이 끊겼을 때 reconnection 로직을 직접 구현해야 함
일부 corporate proxy/firewall에서 차단될 수 있어 wss://사용이 권장됨 -> 실제 증권사 API들이 대부분 wss://만 지원함