실시간웹

http://onecellboy.tistory.com/210

RealTime Web 활용사례

실시간 웹기술 응용분야로는 채팅서비스,알림서비스,실시간 대시보드,웹게임,시뮬레이션,협업툴,모니터링툴,프로그레스바 등 실시간으로 브라우져와 웹서버간 데이터를 주고받을수 있는 다양한 분야에 사용될수 있습니다.

상기 응용분야별로 구현가능한 예를 좀더 자세히 제시해 보겠습니다.

ㅁ웹 채팅
-ActiveX나 사용자 컴퓨터에 채팅 클라이언트 프로그램 설치 없이도 웹브라우져 만으로 웹서버와의
RealTime통신을 통해 채팅구현이 가능합니다.
-(유무선통합)웹채팅,그룹채팅,화상회의시스템,화이트보드

ㅁ알림서비스
-DB에 데이터가 변경되었거나 웹서버에서 특정 이벤트가 발생하면 실시간으로 웹사이트 접속 사용자들에게 알림 메시지를 발생 시킬 수 있습니다.
-쪽지서비스,스마트폰 SNS,실시간 공지 알림(학원..),대시 보드,증권정보,공시정보,경매정보,물가정보,날씨정보...

ㅁ게임
-HTML5 기술을 이용 웹 게임 구현 시 서버와의 실시간 통신에 적용
-웹게임,케주얼게임

ㅁ모니터링툴
-빌딩관리,시설물관리,공장자동화,서버관리,각종 자원들의 실시간 모니터링 데이터의 웹 기반
모니터링툴 제작에 활용
-BMS(빌딩관리시스템),BEMS(빌딩에너지관리시스템),FMS(시설물관리시스템),실시간 데이터 변경 모니터링시스템

ㅁ프로그레스바,챠트
-대용량 멀티 파일 업로드,대용량 데이터 전송 시  진행 율 정보를 실시간으로 프로그레스바로 표현가능합니다.
-대용량파일업로드컴포넌트 대체, 데이터전송 모니터링,실시간 챠트 프로그램[

[출처] http://mixedcode.com/Article/Index?aidx=1104

새로고침 없는 실시간 웹서비스를 위한 기술과 간략한 역사(?)

적은 가격으로 RIA와 같은 실시간 웹서비스에 가까운 제품을 개발하기 위해 등장한 기술들이 매우 많지요.

첫번째로 등장하는 것이 Polling 기술 입니다. Polling 기술은 요청이 없으면 결과값을 보내지 않는 웹서버의 특성을 고려하여 JAVASCRIPT를 이용해 사용자가 보이지 않도록 계속해서 서버에 요청을 보내고 결과값을 받아와 변경된 부분에 채워넣는 것입니다. 하지만 이러한 경우 변경된 부분이 없음에도 불구하고 클라이언트는 서버로 불필요한 요청을 계속해서 보내게 됩니다. 불필요한 요청을 계속해서 받고 이에대한 불필요한 결과값을 계속 응답해주는 서버측의 입장에서도 매우 비 효율적이면서 부하가 많이 발생하게 됩니다...( 한사람의 경우 초당1번의 결과값을 보낼수 있는 서버라고 가정했을 경우 10명이 접속하였을 경우 10초동안 결과값을 보내기 위한 비용이 발생하며 불필요한 트래픽 또한 증가하게 됩니다.)

이러한 비효율적 부분을 개선하고자 등장한 기술적 방안이 바로 long-Polling이라는 것입니다. long-Polling이란 요놈은 Polling 기술은 주기적으로 서버에 요청을 보내면 서버가 바로 응답을 하여 불필요한 트래픽소모를 줄이고자 고안된 방법입니다. 

Polling은 요청을 주기적으로 보내고 서버가 바로 응답하는 형식이 아니라 서버가 변경된 정보가 없을때는 클라이언트가 보낸 요청을 물고 있다가 어떠한 요청의 변경사항이 있을때 비로소 그 응답을 보내는 형식으로 동작을 합니다. long-Polling은 트래픽 적인 부분에서 Polling보다 많이 개선되었다고는 하나.... 생각해보십시오... 1000명이 A라는 이슈에 long-Polling방식으로 서버에 접속해 있을 경우 A에 갱신이 이루어졌을때 1000명의 접속자에게 한번에 응답을 보내주어야 합니다..... 응답을 받은 1000명의 접속자는 또다시 A의 정보에 대한 갱신내용을 받기위해 서버에 요청을 보내겠지요.... 제 기억에 의하면 IIS는 최대 요청갯수가 5000개 정도라고 알고 있습니다, 그렇다면 5000개가 최대 요청갯수라 가정하면, long-Polling 서비스를 사용하는 접속자가 5000명까지 밖에 소화해낼수 없다는 결론에 도달합니다. 5000개의 요청이 최대갯수라면... 그 이전에 벌써 서버는 버벅거리고 있겠지요... DDOS공격... 별다른걸보고 DDOS라고 하지 않습니다. 바로 이런경우라면 서버는 자살기도를 하는것이겠지요...^^;; (표현이 다소 거칠수 있지만 적절한 표현이 아닌가 싶습니다.)

[출처] https://www.xpressengine.com/tip/23056976

롱폴링 Vs 스트리밍

롱폴링(long polling) 

-  또 다른 대중적인 통신방법이다. 클라이언트가 서버에 있는 정보를 요청하면 지정한 시간동안 연결을 열어둔다.서버에 정보가 없으면 클라이언트가 요청한 정보가 생길 때 까지 또는 지정한 시간이 끝날 때까지 해당 요청을 열어둔다. 지정 시간이 끝나면 클라이언트는 서버에 있는 정보를 다시 요청한다. 롱 폴링은 코멧 또는 리버스 에이작스(Riverse ajax) 라고도 한다.  코멧은 서버가 클라이언트로 뭔가를 송신할 수 있을때까지 HTTP 응답 완료를 지연시킨다. 이 기법을 'GET' 또는 '미결 POST(pending -POST) 라고 부른다. 메시지 양이 많으면 롱 폴링을 사용해도 기존의 폴링에 비해 특별히 성능이 개선되지 않는 것을 염두에 두어야 한다. 클라이언트가 새 정보를 가져오기 위해 끊임 없이 서버로 재연결을 해야 하는데, 그로인해 네트워크 반응이 빠른 폴링과 같아지기 때문이다. 롱 폴링의 또다른 단점은 표준 구현이 없다는 점이다. 

스트리밍(Streaming) 

- 클라이언트가 요청을 보내면 서버는 지속적으로 업데이트 되며 무한히 또는 지정한 시간동안 열린 상태로 유지되는 오픈된 응답을 전송하고 관리한다. 서버는 메시지를 전달할 준비가 되면 응답을 업데이트 한다. 스트리밍은 왠지 예측 불가능한 메시지 전달에 적합한 해결책을 것 같아 보이지만 서버는 HTTP 응답을 완료하라는 신호를 절대 보내지 않으므로 연결이 계속 열린채로 있게 된다 이럴경우 프록시와 방화벽은 응답을 버퍼에 저장해서 메시지 전달이 더 지연될 수도 있다. 따라서 잦은 스트리밍 시도는 방화벽이나 프록시가 있는 네트워크에선 불안정하다 

[출처] https://m.blog.naver.com/PostView.nhn?blogId=khjzzangs&logNo=220407333401&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F