Web Socket 기본개념

웹소켓 이전의 비슷한 기술

1. Polling

• 서버로 일정주기 요청 송신
• real-time 통신에서는 언제 통신이 발생할지 예측이 불가능
• 불필요한 request와 connention 생성
• real-time 통신이라고 부르기 애매할 정도의 실시간성

2. Long Polling

• Polling의 단점을 해소하기 위해 서버에서 좀더 대기
• 서버에 요청 보내고 이벤트가 생겨 응답을 받을 때까지 연결종료X
• 응답을 받으면 다시 재요청
• 많은 양의 메세지가 쏟아질 경우 Polling과 같음

3. Streaming

• 서버에 요청 보내고 끊기지 않은 연결상태에서 끊임없이 데이터 수신
• 요청에 대한 응답을 완료하지 않는 상태에서 데이터를 계속해서 내려받음
• 클라이언트에서 서버로의 데이터 송신이 어려움

==> 위의 모든 방법이 HTTP를 통해 통신하기 때문에 Request, Response 둘다 Header가 불필요하게 큼

---

웹소켓

• 두 프로그램 간의 메세지를 교환하기 위한 통신방법
• 웹소켓을 지원하는 브라우저의 경우 웹소켓 프로토콜을 지원 함
• 최초 접속에서만 Http 프로토콜 위에서 핸드쉐이킹을 하기 때문에 http header을 사용
• 웹소켓을 위한 별도의 포트는 없으며, 기존 포트를 사용: Http(80), Https(443)
• 프레임으로 구성된 메세지라는 논리적 단위로 송수신
• 메세지에 포함될 수 있는 교환 가능한 메세지는 텍스트와 바이너리

1. 양방향 통신

• 데이터 송수신을 동시에 처리 할수있는 통신방법
• 클라이언트와 서버가 서로에게 원할 때 데이터 주고받을 수 있음
• 일반적인 Http 통신은 클라이언트가 요청을 보내는 경우에만 서버가 응답하는 단방향 통신 임

2. 실시간 네트워킹

• 웹 환경에서 연속된 데이터를 빠르게 노출
• 예) 채팅, 주식, 비디오데이터...
• 여러 단말기에 빠르게 데이터를 교환

웹소켓 동작방법

1. 핸드 쉐이킹

• 위 사진은 연결수립을 할때의 헤더임
• 핸드 쉐이킹은 웹소켓 프로토콜이 아닌 Http 프로토콜 or Https 프로토콜을 통해 이루어짐
• HPPT버전은 1.1이상 / 반드시 Get 메서드를 사용해야함
• Host는 웹소켓 서버의 주소

• Sec-WebSocket-Key

1. 클라이언트 서버가 서로의 신원을 인증 함
2. 길이가 16바이트인 임의로 선택된 숫자를 base64로 인코딩한 값

• Origin은 웹브라우저를 사용하는 경우에 필수항목으로 클라이언트의 주소

• Sec-WebSocket-Protocol

1. 클라이언트가 요청하는 여러 서브프로토콜을 의미
2. 공백문자로 구분되며 순서에 따라 우선권이 부여
3. 서버에서 여러 프로토콜 혹은 프로토콜 버전을 나눠서 서비스 할 경우 필요한 정보

• 응답을 보자
• 101 Switching Protocols가 Response로 오면 웹소켓이 연결 되었다는 것

  • Sec-WebSocket-Accept

  1. 클라이언트로부터 받은 Sec-WebSocket-Key를 사용하여 계산된 값
  2. 클라이언트에서 계산한 값과 일치하지 않으면 연결수립 X

2. 데이터 전송

• 이때부터는 프로토콜이 ws로 변경
• wss : 데이터 보안을 위해서 SSL을 적용한 프로토콜

3. 프레임 이란?

• Length는 이 프레임에 포하된 데이터의 총길이

4. 간단 정리

5. 웹소켓의 한계

Socket.io, SockJS

• HTML5 이전의 기술로 구현된 서비스에서 웹소켓처럼 사용할 수 있도록 도와주는 기술
• 자바스크립트를 이용하여 브라우저에 상관없이 실시간 웹을 구현
• WebSocket, FlashSocket, AJAX Long Polling, AJAX Multi part Streaming, IFrame, JSONP Polling을 하나의 API로 추상화
• 즉, 브라우저와 웹서버의 종류와 버전을 파악하여 가장 적합한 기술을 선택하여 사용하는 방식

STOMP

• 웹소켓은 문자열들을 주고받을 수 있게 해줄 뿐 그 이상의 일 X
• 주고받은 문자열의 해독은 온전히 어플리케이션에 맡김
• Http는 형식을 정해두었기 때문에 모두가 약속을 따르기만 하면 해석할수 있지만, 웹소켓은 형식이 정해져 있지 않기 때문에 어플리케이션에서 쉽게 해석하기 힘듬
• 웹소켓 방식은 sub-protocols를 사용해서 주고받는 메세지 형태를 약속하는 경우가 많음
• STOMP는 채팅통신을 하기 위한 형식을 정의, 일반적으로 HTTP 위에서 사용
• HTTP와 유사하게 간단히 정의되어 해석하기 편함

아래는 STOMP 프레임 구조

참고

• https://www.youtube.com/watch?v=MPQHvwPxDUw&t=58s