소켓
소켓이란 두 프로그램이 네트워크 상에서 데이터를 송수신할 수 있도록 양쪽에 생성되는 통신의 종착점(Endpoint) 단자이다.
HTTP 통신
클라이언트가 서버로 request를 전송하면 서버는 이에 대한 response를 전송하는 통신 방식이다.
단방향 통신이다: 서버는 클라이언트의 request가 있을 때에만 response를 전송한다.비연결성 통신이다: 클라이언트가 request를 보내고, 서버가 response를 보내면 연결이 끊어진다. (Keep Alive 옵션으로 연결 유지를 할 수 있다)
소켓 통신
클라이언트와 서버가 각각 상대에게 메시지를 전송하는 통신 방식이다.
양방향 통신이다: 클라이언트가 서버에게 메시지를 보낼 수 있고, 서버도 클라이언트에게 메시지를 보낼 수 있다.연결이 유지된다: connection을 계속 유지하기 때문에 HTTP 통신에 비해 리소스 소모가 크다양 측에서 실시간으로 메시지를 주고 받아야 할 경우 HTTP 통신보다 소켓 통신이 적절하다
소켓의 유형
TCP/IP 기반의 Stream 방식양방향 연결이 필요하다.
신뢰성있는 데이터 전달을 보장한다.
데이터의 순서를 보장한다.
프로토콜 : TCP
UDP/IP 기반의 Datagram 방식양방향 연결이 필요하지 않다
데이터가 중간에 소실될 수 있다
프로토콜 : UDP
HTTP 실시간성 기술
HTTP 실시간성 기술이란 HTTP로 실시간 통신을 흉내내는 기법으로 3가지 기법이 존재한다.
Polling: 클라이언트가 서버에게 주기적으로 request를 보내어 새로운 event를 감지하는 방식서버에서 새로운 event가 발생하지 않으면 empty response를 보내고, event가 발생하면 데이터를 담아 response를 보낸다
문제점: 불필요한 통신이 주기적으로 이뤄져 네트워크 트래픽이 팔생하고, 서버는 계속 response를 보내기 때문에 리소스가 낭비된다
Long Polling: 클라이언트가 request를 보내면 서버는 기다렸다가 event 발생시에 response를 보낸다.클라이언트는 request를 보내고 TIME_OUT이 될 때까지 response를 기다린다.
클라이언트가 response를 받으면 그 즉시 request를 보낸다.
connection이 계속 유지되기 때문에 사실상 실시간 통신이 가능하다
문제점: event가 자주 발생하면 polling과 다를바가 없다.
Streaming: 클라이언트가 request를 보내면 서버는 response를 완성하지 않고 부분 데이터(chunk data, stream, response part)를 보낸다.클라이언트는 서버 측의 파일을 모두 다운로드 받지 않고도 일부를 재생할 수 있다
Long Polling 방식 처럼 클라이언트가 재 연결을 시도할 필요가 없어서 효율적이다
HLS(HTTP Live Streaming)
HLS는 UDP가 아닌 TCP를 사용한다.
HLS는 화상 회의처럼 실시간일 필요가 없기 때문에 UDP가 아닌 TCP를 사용한다.
넷플릭스, 유투브는 TCP 기반의 HLS 방식을 사용한다.
HLS로 재생되는 비디오는 HTTP 서버 내의 특정 URL로 접근할 수 있는 파일로 저장된다.
HTTP Live Streaming vs UDP Streaming
UDP Streaming
서버와 클라이언트 사이의 예측하기 어려운 대역폭 변화로 인해 비디오를 원활하게
연속적으로 재생하기 힘들다.UDP Streaming은 클라이언트와 서버간의 대화식 요청과 상태 추적을 위해 중간에 RTSP 서버와 같은
미디어 제어 서버가 필요하다. (비용 문제)많은
방화벽 시스템이 UDP 트래픽을 차단하도록 설정되어 있다.
HTTP Live Streaming
TCP 기반의 HLS는 방화벽이나 주소변환기(NAT)를 쉽게 통과한다 (대부분의 장비들이 UDP 트래픽을 차단하지만 HTTP 트래픽은 쉽게 통과 시킨다)
RTSP 서버와 같은 미디어 제어 서버가 필요없기 때문에 비용이 절감된다.
TCP 기반의 신뢰성이 보장된 데이터 전송으로 비디오를 원활하게 재생할 수 있다.
HTTP 실시간 기술의 문제점
HTTP Header가 불필요하게 크다
각 브라우저마다 HTTP 실시간성 기술을 구현하는 방법이 다르다
웹 소켓 프로토콜
HTTP 실시간성 기술(polling, long polling, streaming)은 각 브라우저마다 구현방법이 달라 발생하는 문제를 해결하기 위해 HTML5 표준의 일부로 웹 소켓 프로토콜이 만들어졌다.
동작 원리
Opening Handshake: HTTP request, response를 주고 받으며 웹 서버로 최초 접속하는 과정클라이언트는 웹 소켓 통신을 위해 필요한 정보를 헤더에 담아 request를 전송한다(Upgrade 필드에 “websocket” : 웹소켓 프로토콜로 변경하겠다는 의미)
서버는 웹소켓 연결이 되었음을 알려주는 정보를 헤더에 담아 response를 전송한다(Sec-WebSocket-Accept 필드에
클라이언트가 보낸 Sec-WebSocket-Key 값+uniqueId를 해싱하여 Base64 인코딩한 값을 넣음)
Data Transfer: 웹 소켓 connection이 수립되면 데이터 전송이 시작된다프로토콜이
ws또는wss로 변경된다 (wss은 SSL 이 적용된 프로토콜)클라이언트와 서버는
message라는 개념의 데이터를 주고 받는다message는 한 개 이상의 frame으로 구성된다.
frame에는 텍스트(
UTF-8), 데이터, 바이너리 데이터, 헤더로 이루어져있다. (작은헤더 + payload = frame)헤더 사이즈가 크다는 HTTP의 단점을 해소하기 위해 작은 헤더를 사용하는 frame을 사용하는 것같음
opening handshake가 끝난 시점부터 connection이 유지되는지 확인하기 위해 주기적으로 ping을 보낸다 (서버 또는 클라이언트 양측에서 설정할 수 있음)
Closing Handshake: 웹 소켓 connection을 종료하기 위해 control frame을 전송한다.서버가 웹 소켓 connection을 종료한다는 frame을 전송하면, 클라이언트는 이에 대한 응답으로 close frame을 전송한다.
웹 소켓 connection이 종료된 이후 전송되는 message는 버려진다
웹 소켓 프로토콜의 장점
HTTP request를 그대로 사용하기 때문에 80, 433 포트를 통해 웹 서버에 접속할 수 있기 때문에 추가적으로 방화벽을 열지 않아도 된다.
웹 소켓에 대한 CORS 적용이나 인증과정을 기존 HTTP 통신과 동일하게 적용할 수 있다.
웹 소켓 프로토콜의 한계
주고 받는 데이터가 UTF-8 문자열 뿐이다
문자열에 대한 해독은 어플리케이션 단에서 해야한다
문자열에 대한 형식이 정해지지 않아서 어플리케이션에서 이를 해석하기 힘들다
HTML5 이전 환경에서 웹 소켓을 지원하지 않는다 →
Socket.io또는SockJS를 사용한다
Socket.io,SockJS
웹소켓을 지원하지 않는 브라우저에서도 웹소켓을 사용하는 것과 비슷한 환경을 제공해준다.
Last updated
