.png&blockId=3197e115-ee0d-4d9c-9f5d-4b57cb28634e)
Polling
•
가장 기본적인 데이터 처리방식으로, 특정 주기를 가지고 서버에 http request을 하는 방식
•
Polling방식은 언제 통신이 발생할 지 예측이 불가능하기 때문에 클라이언트가 평범한 http request를 일정한 주기로 서버에 요청하여 이벤트 내용을 전달받는 가장 간단한 방법
•
언제 통신이 발생할지 예측이 불가능하다는 점에서 클라이언트가 계속적으로 요청을 하기때문에 클라이언트가 많아지면 서버의 부담이 급증하게 된다. (실시간 통신이라고 부르기는 하지만 실시간 정도의 빠른 응답을 기대하기는 어렵다.)
•
장점
◦
클라이언트, 서버 모두 구현이 단순하다
•
단점
◦
주기가 짧으면 서버에 무리를 줄 수 있고 서버의 상태가 변경되지 않아도 불필요한 요청/응답이 발생할 수 있다
Long Polling
•
Polling과 비슷한 기법이나 실시간으로 데이터를 처리할 수 있는 방식
•
클라이언트에서 서버로 Request를 보내고 기다리다가 서버에서 해당 클라이언트로 전달할 이벤트가 있다면 그 순간 Response 메세지를 전달하며 연결이 종료
•
해당 작업이 완료된 이후에는 클라이언트에서 Request를 보내 서버의 다음 이벤트를 기다리게 된다.
•
일반 polling 방식보다는 서버의 부담이 줄겠지만 클라이언트로 보내는 이벤트들의 시간간격이 좁다면 polling 과 별 차이가 없게 되며, 다수의 클라이언트에게 동시에 이벤트가 발생될 경우에는 곧바로 다수의 클라이언트가 서버로 접속을 시도하면서 서버의 부담이 급증하게 된다.
•
장점
◦
Polling 방식에 비해 불필요한 요청/응답 트랜잭션을 덜 유발
◦
'덜 유발한다'고 한 이유는 Long Polling 방식도 보통 서버 응답을 무한정 기다리는 게 아니라 특정 시간이 지나면 해당 요청/응답 트랜잭션을 완료하고 새로이 요청하는 방식으로 구현하기 때문
•
단점
◦
무조건 요청을 보내기 때문에, 트래픽이 심하게 과부화 걸린다.
Pulling
•
서버의 데이터를 클라이언트가 직접 주기적으로 가져간다.
◦
클라이언트가 서버의 데이터를 알아서 가져가는 것.
•
안드로이드 api 서버들을 Pulling 방식이다.
websocket
•
양방향 채널을 이용해 채팅방 처럼 양방향 통신이 가능하다.
•
기존 http 통신은 client가 요청을 보내는 경우에만 서버가 응답하는 단방향 통신이고, 양방향은 서로가 원할때에 언제든지 데이터를 주고 받을 수 있는 통신이다.
•
접속 확입에 HTTP를 사용하지만, 그 후의 통신은 WS라는 프로토콜을 이용한다.
◦
header가 작아 overhead가 적다
•
장점
◦
최초 접속시 헤더 정보를 보내고 더 이상 헤더 정보를 보내지 않음
◦
계속적으로 Connection을 열어두고 있다가 바로 그에 대한 결과값을 받기에 실시간성이 보장
•
단점
◦
양방향 통신에 적합한 방식이므로 알림 서버스에서는 적합하지 않음
SSE (Server-Sent Events)
•
HTML5 표준안이며 어느정도 웹소켓의 역할을 하면서 더 가볍다.
•
websocket 과 같이 양방향이 아닌 단방향이기에 서버의 알림 기능을 클라이언트한테 보내는 작업에 유용하게 사용될 수 있다.
•
server -> client 단방향
•
장점
◦
HTTP 프로토콜만으로 사용이 가능하기에 훨씬 가볍다.
•
단점
◦
접속에 문제가 있으면 자동으로 재연결을 시도하지만 클라이언트가 페이지를 닫아도 서버에서 감지하기가 어렵다.
