Http를 통한 양방향 통신

Http

클라이언트가 서버에 요청을 보내고 응답을 받으면 연결이 끊긴다.

서버-클라이언트의 실시간 상호 작용이 불가능하다.

 

=> 실시간 상호 작용을 위한 기술이 필요

 

1. Polling

클라이언트가 서버로 http request를 계속 보낸다.

서버에 이벤트가 없어도 계속 요청을 보내기 때문에 서버와 클라이언트의 부담 급증 

 

2.  Long Polling

클라이언트가 서버로 http requestf를 일단 보낸다.

서버에서 해당 클라이언트로 전달한 이벤트가 생기면 응답 메시지 전달 후 연결 종료

클라이언트는 다시 새로운 request를 보낸다.

 

3. Streaming

클라이언트가 서버에 requst를 보낸다.

연결이 끊기지 않은 상태로 끊임없이 데이터를 받는다.

하지만 클라이언트가 서버로 요청을 보내기가 힘들다.

 

4. WebSocket

Http기반으로 하면서 Http의 문제 해결이 목표

송신과 수신을 동시에 처리할 수 있으며 socket connection 을 유지하기 때문에 양방향 통신과 데이터 전송이 가능하다.

기존의 TCP socket과 다른 점은 

WebSocket은 최초 접속이 일반 http 요청을 이용한 handshaking으로 이루어진다.

또한 TCP socket은 바이트 스트림을 사용하지만

웹소켓을 통해 전달되는 텍스트는 UTF-8 포맷을 가진다.

 

• Stateful : 클라이언트와 한번 연결이 되면 계속 같은 라인 사용해 통신하기 때문에 HTTP사용시 필요없이 발생되는 HTTP와 TCP연결 트래픽을 피할 수 있다(웹소켓은 HTTP와 달리 최초 접속을 제외하고 헤더정보를 보내지 않기에 네트워크 비용측면에서 이득)
• HTTP 요청을 그대로 사용하기에 기존 80(HTTP포트), 443(HTTPS)포트로 접속하므로 추가 방화벽을 열지 않아도 되고 HTTP의 규격인 CORS적용이나 인증등의 과정을 기존과 동일하게 가져갈 수 있다.

기본적으로 웹소켓API(자바크립트)는 간단한 기능만 제공하기에 대부분의 경우 socket.io같은 오픈 소스 라이브러리를 많이 사용한다.

SockJS(http://sockjs.org)

springframework에서 WebSocket을 지원한다. 스프링 메뉴얼에 webSocket 부분을 보면 위와 같은 브라우저 문제를 해결하기 위한 방법으로 SockJS를 솔루션으로 제시한다. 역시 자체 스팩으로 webScoket 미지원 브라우저를 관리한다. 서버개발시 스프링 설정에서 일반 webSocket 으로 통신할지 SockJS 호환으로 통신할지 결정할 수 있다. 클라이언트쪽은SockJS client를 통해 서버와 통신한다.

출처: https://adrenal.tistory.com/20 [시나몬 브레드]

 

WebSocket은 HTTP와 TCP의 특성을 섞어 놓은 프로토콜이며

결국 핵심은 웹 브라우저 환경에서 연결지향 통신하기 위한 기술이라는 점이다.