실시간웹, 폴링, comet, socket

실시간웹구현의 한계 -> HTTP의 특성 때문

Connectionless  비연결지향 특성

클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징 HTTP는 먼저 클라이언트가 request를 서버에 보내면, 서버는 클라이언트에게 요청에 맞는 response를 보내고 접속을 끊는 특성이 있다.   -> 헤더에 keep-alive라는 값을 줘서 커넥션을 재활용하는데 HTTP1.1에서는 이것이 디폴트다.   HTTP가 tcp위에서 구현됨 tcp는 연결지향,udp는 비연결지향 keep-alive는 옵션으로 connectionless 극복

 

Stateless 상태를 저장하지 않는다

통신이 끝나면 상태를 유지하지 않는 특징 연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다. 쿠키와 세션은 위의 두 가지 특징을 해결하기 위해 사용합니다. 예를 들어, 쿠키와 세션을 사용하지 않으면 쇼핑몰에서 옷을 구매하려고 로그인을 했음에도,  페이지를 이동할 때 마다 계속 로그인을 해야 된다면 매우 불편   쿠키와 세션을 사용했을 경우, 한 번 로그인을 하면 어떠한 방식에 의해서 그 사용자에 대한 인증을 유지하게 됩니다.

 

HTTP의 특성상, Request 주고, 다시 받은 Response를 브라우저에 다시 그려줘야 된다

즉, 화면이 한번 깜빡여야됨

-> 초기에 그점을 개선하기 위한 RIA(Rich Internet Application) 기술이 발달하기 시작함
Hidden Frame, Long pooling Stream 등등 기술

실시간 웹서비스를 만드려면, 양방향 송수신이 필요하다. ->

그래서 HTML5 표준안의 일부로 WebSocket API(이후 WebSocket)가 등장하게 됨

 

 

그래서 => 폴링

 

폴링	Pooling   충돌 회피 또는 동기화 처리 등을 목적으로 다른 장치(또는 프로그램)의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료처리를 하는 방식   클라이언트가 서버에게 일정한 주기를 가지고 응답을 주고받는 폴링 방식을 사용한다. AJAX polling   폴링의 문제점 폴링의 주기가 짧으면 서버의 성능에 부담이 간다. 주기가 길면 실시간성이 떨어진다. 정보가 변하지 않으면 리소스를 낭비하고 오버헤드/트래픽이 발생한다.   -> 롱폴링기법, 스트리밍 방식 단, 롱폴링기법은 변경이 빈번하다면 얻을 수 있는 이점이 크지 않다.
Comet	웹 클라이언트(보통 웹 브라우저)의 명시적인 요청이 없어도 서버에서 클라이언트로 데이타를 밀어넣는(PUSH) 방식으로 동작하는 웹 프로그래밍 모델, 모델임  즉 Comet = Reverse Ajax = Ajax Push = Two-Way-Web = HTTP server Push = HTTP streaming 등등 다 같은 의미이다.
WebSocket	HTTP의 한계를 극복하고 실시간(양방향통신) 서비스 개발을 위해 태어남 HTTP 요청과 마찬가지로 80번 포트를 통해 웹 서버에 연결 클라이언트/서버 모두 WebSocket지원해야됨. 브라우져는 모두 지원함. 서버는... Apache에서 별도의 모듈을 설치하여 WebSocket을 사용가능 Node.js에서도 WebSocket을 사용 가능
Socket.io	JavaScript를 이용하여 브라우저 종류에 상관없이 실시간 웹을 구현할 수 있도록 한 기술 표준 기술이 아니고 Node.js 모듈로써, 오픈소스임.   WebSocket, FlashSocket, AJAX Long Polling, AJAX Multi part Streaming, IFrame, JSONP Polling을 하나의 API로 추상화한 것

 

 

일반적으로 HTTP 4 이하 기반의 웹 형태로 채팅 시스템을 구현하려면, -> 폴링(Polling)사용

주기적으로 채팅서버에 새로운 대화가 있는지 찾아보고 대화가 있다면 가져오는 방식으로 실시간으로 처리를 하려면, 그만큼 더 많은 부하가 존재할 수 있다.

 

 

HTTP 5에서 지원하는 웹소켓으로 채팅 시스템을 구현하는 방법은 매우 효율적이다

문제점

웹소켓은 브라우저에서 채팅서버에 직접 연결을 시도하는 형태를 가지고 있다.

그러다보니 페이지를 갱신하게 되면 연결이 끊어지고, 다시 연결을 하는 형태를 가진다. 이러다보니 F5번을 눌러서 페이지를 습관적으로 갱신하게 된다면 세션이 끊어지고 다시 연결해야 되는 상황을 맞이할 수 있으며 더 큰문제는 웹소켓의 세션과 HTTP 세션이 서로 다르다는 것이다.

 

그러다보니, 주기적으로 웹소켓의 세션과 서버에서 저장하는 HTTP 세션을 동기화하는 모듈을 별도로 구현해야 한다. 이게 생각보다 짜증이 나서 어쩔때는 그냥 풀링 방식으로 모든 것을 구현하고 싶은 욕구가 치밀 때가 있을 것이다.(사실 풀링 방식이 더 편할때가 많다)