Topic/Think

Ajax 와 WebSocket 에 대해

glqdlt 2016. 2. 12. 17:09

# 웹과 비동기 I/O에 대한 이해



AJAX는 HTTP의 한계성(지속적인 연결(persistent connection)의 불가능)을 극복하고자 나타난 기술(개념)이다.


일반적으로 웹의 프로토콜은(HTTP,HTTPS) 클라이언트(웹 브라우저)에서 서버에 요청을 요구해야지 서버에서 반응하여 응답을 통해 화면이 출력이 되는데, 이 방법은 실시간으로 데이터를 갱신하거나 인터렉티브한 동적인 웹서비스를 구현하기엔 불가능한 요소로 작용된다.


예를 들면 실시간으로 정보를 확인해야하는 대시보드(예: 스포츠 중계, 보안 관제서비스)의 경우 실시간으로 데이터가 재갱신(Refresh,Reload)가 자주 일어나야 하므로 기존의 방법으로는 많은 문제들에 부딪치게 된다.

 

이러한 문제를 해결하고자 세계각지의 개발자들은 여러가지 방법(혹은 편법)을 고안해내기 시작했고 이를 우리는 코멧(Comet)이라고 부르며ㅡ, 또는 Ajax(혹은 Reverse Ajax, Ajax Push)라고 얘기를 하곤 한다.


Ajax는 일반적으로 폴링방식과, 롱폴링, 스트리밍 방식이 있다.


#폴링(Polling)


폴링 방식은 화면을 업데이트 하는 함수를 작성하고 일성 시간마다 setInterval() 함수를 통하여 업데이트 함수를 호출하는 방법.



#롱 폴링(Long Polling)


롤폴링 방식은, 문자 그대로 오래 끌기라는 개념을 가지고 있다. 클라이언트에서 서버에 응답이 올 때까지 접속을 계속 유지(Long Polling)하며, 


응답이 오면 응답 내용(데이터)를 처리함과 동시에 방금 끊어지는 접속을 다시 유지하기 위한 새로운 코드를 작성해서 접속을 유지하는 방식.


쉽게 말하면 계속해서 대기+종료생성 / 대기+종료생성을 끝없이 한다고 보면 된다.


즉, 응답을 기다리다가, 데이터 응답과 동시에 다시 새접속을 만드는 것이라고 볼 수 있다.





#WebSocket(WebSocket API)


웹소켓은 HTML5에서 생긴 기술로, 문자 그대로 웹에서 사용하기 위한 소켓을 의미한다. 


AJAX로도 비동기가 가능하다곤 하지만 결국 이는 편법에 불가한 방법이고, 근본적인 해결책이 아니기 때문에 자연스레 생긴 기술이다.


이 웹소켓 기술을 사용하면 아무런 제약없이 클라이언트와 서버가 통신을 할 수 있다. 이는 일방적인 서버에서의 PUSH도 가능해진다는 얘기.


코멧처럼 무한루프를 돌리지 않아도 되고, 특정 시간마다 호출하지 않아도 된다. 또한 AJAX에는 정말 중대한 단점이 있는 데, 데이터의 과부하적인 측면이 있어 실사용에 많은 문제점이 있다.


AJAX는 요청과 응답이 계속 있는 형태이므로, 순수한 데이터로 응답이 되는 것이 아니라 Content-Type 즉 컨텐츠 헤더가 묻어서 응답이 이루어지는 데, 예를 들면 단순히 1에서 999까지의 숫자를 순서대로 실시간으로 업데이트 하는 화면이 있다고 가정하면, 1이라는 문자에는 이게 html 문서인지, json 데이터인지, 어플리케이션 데이터(다운로드 대상)인지를 알려주는 컨텐츠 헤더정보가 같이 묻어서 응답되어지기 때문에


1 + Contetns-header, 2 + Contetns-header, 3 + Contetns-header ... 999 + Contetns-header 란 식으로 쓸데없는 더미 트래픽이 계속 발생하는 문제점이 있다.


일반 유선으로 연결되어진 PC환경에서야 상관없지만, 다중 접속이 이루어지는 서비스나 모바일컨텐츠가 주를 이루는 서비스라면 많은 문제가 될 수 있는 상황.


웹 소켓은 이러한 문제없이 단순한 순수 데이터만 전송이 가능해진다.


사실 이것도 헤더 캐싱이라 해서, 쿠키와 같은 개념으로 관리를 하면 절약할 수는 있다.


하지만 아무리 그래도 header의 오버헤드 자체는 해결 할 수 없다.


위의 AJAX 예와는 달리 웹소켓으로는 1, 2, 3,  ... 999 의 순수한 데이터 전송이 가능하다.


왜냐면 요청한 클라이언트와 응답할 서버 그들만의 소켓이기 떄문에,  HTTP프로토콜 자체는 정보전달을 특정 대상 구분 없이 전송할 목적으로 만들어졌기 때문에 이 데이터가 문서인지, 어플리케이션인지에 대한 정보가 항상 들어있어야 하지만 그들만의 통신소켓에서는 굳이 이를 알려줄 필요가 없기 때문이다.


다만, 이러한 장점이 많은 웹소켓도 단점이 있다. 최신 기술이 모두 그러하듯 바로 기존 인프라에 탑재되어 있는 구버전의 브라우저에는 호환이 되지 않는 다는 점.






#비동기 플랫폼 Node.js 와 vert.x


웹소켓을 쓸 수 있는 방안은 많다. netty도 있고, 스프링도 가능하다.


이에 대해서는 많은 자료가 있으니 굳이 얘기는 하지 않겠다.


이 외에 최근에 핫해지고 있는 녀석들이 있는 데, node.js와 vert.x 두 녀석이 있다.


node.js는 속칭 mean 스택이라 부르는 누구하는 풀스택! 이란 유행을 몰고 왔다.


빠르고 쉽게 풀 스택으로 자바스크립트만 알면 mean 스택으로 제약 없는 웹 서비스가 가능하다.


다만, 이 node.js도 장점에 비해 결정적인 단점이 있는 데, 단일 스레드 처리를 한다는 점이 조금 말이 나오는 점이 있다.


vert.x는 Node.js와 달리 단일 스레드가 아닌 다중 처리가 가능한 프레임워크다.


그리고 특정 언어에 구애 받지 않는 폴리그랏이 장점이라는 데.. 굳이 이렇게 쓰고 싶다, js는 vertx 도 있고 말이다. 요금 Rx 쪽이 워낙 확산되니.. Rxpython 도 있고 -_-


vert.x는 server mode 와 embedded mode로 나누어지는 데,


server mode는 서비스(혹은 데몬) 형태로 vert.x를 실제 작동시키는 방식이고


embedded mode는 원하는 대상에 API형태로 탑재되어 작동이 되는 형태다. (예: spring 등)


기본 코어는 Netty 를 내장해서 통신 처리를 하고 있는 걸로 보인다.


Netty와 마찬가지로 전체적인 로직은 Event 헨들링 방식이다.


나중에 시간나면 좀 만져봐야겠다.



'Topic > Think' 카테고리의 다른 글

Virustotal Api license (Public vs Private)  (0) 2016.08.02
스프링 탄생에 대한 잡담  (0) 2016.05.10
빅데이터 공부를 하면서  (0) 2016.04.06
Selenium 의 정책  (0) 2016.02.12
Vm Sphere EXSI 라이센스에 대한 이야기  (0) 2016.01.07