[CS] polling push pull

 

방식

 

Pull

ex) http request

클라이언트가 서버에게 데이터를 요청하는 것

 

---

Polling

ex) ajax

하나의 장치(프로그램)가 충돌 회피 또는 동기화 처리 등을 목적으로 다른 장치(프로그램)의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료처리를 하는 방식

(주기적으로 서버에 연산을 요청)

Loop 및 while문 내에서 반복적으로 외부 입력을 감시하는 문법으로 구현된다.

 

Real-Time 웹을 위한 기법으로, 일정한 주기를 가지고 서버와 응답을 주고 받는 방식

(RealTime : 사용자가 즉시라고 느낄 정도로 충분히 빠르거나, 컴퓨터 외부에서 진행되는 처리에 빠르게 동작하는 컴퓨터 반응 수준)

 

polling은 http의 단점을 보완하기 위해 고안된 기법이다.

웹이 태생적으로 실시간을 위해 필수적인  persistent connection이 불가능하기 때문이다.

(HTTP는 요청-응답 후 연결이 끊어진다.)

http통신은 서버에서 클라이언트로 역으로 요청하는 것은 불가능하다. (단방향성!)

클라이언트만 서버로 요청할 수 있고, 서버는 클라이언트의 요청에 대한 응답만 가능하다.

( 지금은 웹소켓이 있지만 과거에는 웹은 http말고는 방법이 없었다. )

그래서 통신하는 것처럼 느끼게 만드는 방법의 초기 모델인 polling기법이 나왔다.

가장 무식한 방법.

스토킹 마냥 계속해서 일정 시간으로 물어보는 방식.

 

특징

1. 주기적으로 물어보므로 응답 간겨을 일정하게 할 수 있다.

2. 주기적으로 몰아서 물어보는게 가능하므로 자동으로 배치프로세싱(일괄처리)되어서 db튜닝을 하는 효과가 나온다.

 

문제점

1. 폴링의 주기가 짧으면 서버의 성능에 부담이 간다(오버헤드/트래픽)

2. 주기가 길면 실시간성이 떨어진다.

3. 보낼 테이터가 없어도 계속해서 데이터를 줘야하므로 서버의 리소스를 낭비

4. 정보가 변하지 않으면 리소스를 낭비하고 오버헤드/트래픽 발생

이를 해결하기 위해 COMET가 나왔다.

---

 

COMET

클라이언트가 웹 서버에서 새로운 내용이 있는지 물어보았을 때 웹 서버에 새로운 내용이 없다면 대답하지 않다가 새로운 내용이 생기면 대답해주는 방식

실시간 웹을 구현하기 위해 만들어진 기술 모델

 

● Long Polling

서버측에서 접속을 열어두는 시간을 길게 한다. 이벤트가 발생하면 응답이 바로 이루어짐

이벤트가 발생(변경된 데이터가 있을 때만 응답)하면 바로 응답이 이루어지기 때문에 실시간성이 아주 높으며, 스트리밍 방식과 달리 웹 브라우저 환경에 관계없이 사용할 수 있기에 흔히 사용하는 방식.

ex) 브라우저가 서버로 요청을 보내면 서버는 요청한 데이터가 변경되었을 때만 응답을 보낸다.

 

poling은 주기적으로 계속 물어본다면 long polling은 일단 보내고 time out이 될 때까지 무한정 기다리는 것

 

특징

1. 항상 연결이 유지되어 있다.

2. 변경에 매우 민감하게 반응한다. 실시간 통신 가능

3. 데이터가 주어지는 즉시 바로 반응하고 보내지므로 요청 간격이 줄어든다면 polling보다 훨씬 데이터를 많이 보내게 된다. BUT 데이터 이동이 활발하다면 오히려 주기적으로 한번에 보내는 polling보다 많은 데이터를 보내게 된다. http는 헤더의 크기가 크기에 데이터를 많이 보낸다는 것은 비용이 크다는 뜻이다.

 

문제점

실시간으로 응답을 받는 경우에 적합하고 서버의 부하도 줄여주지만!

데이터가 자주 변경되는(대용량 채팅)의 경우 한명의 유저가 채팅을 입력하면 엄청난 수의 변경 호출이 일어나서 적합하지 않다. 

또한 polling과 long polling모두 오랫동안 연결되어 있는 커넥션을 최적화하지 못하는 문제가 있다.

이 방식을 사용하기 위해서는 연결된 커넥션과 요청 리스트들을 가지고 있어야 한다.

 

●  Streaming

웹 접속을 계속 열어두고 발생할 때 마다 부분적으로 브라우저에 응답

클라이언트와 서버가 계속 접속을 유지한 상태로 있어, 이벤트가 발생할 때마다 클라이언트로 데이터를 보낸다.

---

 

Push

ex) STMP, websocket

push server는 클라이언트의 요청이 오면 응답해주는 방식이 아닌 서버가 클라이언트에게 공지사항과 같은 무언가를 통지해주기 위한 방법

클라이언트의 요청 없이도 서버는 클라이언트에게 응답하는 방식

 

통신 모델

동기 통신 모델

REST API통신

REST 아키텍처 패턴은 일반적으로 동기 통신을 한다.

클라이언트는 HTTP엔드포인트를 호출할 때 마다 즉각적인(약 60초 내)응답을 기다리고, 제한 시간 내에 응답을 받지 못하면 시간 초과 메시지와 함께 에러를 던진다.

 

요청 시간이 오래걸린다면 클라이언트가 응답을 기다리지 않고 요청이 처리된 후 결과를 확인할 수 있도록 비동기 통신을 고려해 볼 수 있다.

 

비동기 통신을 사용하면 클라이언트는 응답을 기다리는 시간을 효율적으로 사용할 수 있다. 

응답을 기다리는 동안 스레드가 block상태가 되지 않고, 다른 작업에 사용 가능하다.

트랜잭션에서 문제가 발생하면 서버는 전체 프로세스를 다시 시작하고 사용자에게 결과를 알릴 수 있다.

 

 

 

 

비동기 통신 모델

Polling Model

polling : 다른 프로그램의 상태를 주기적으로 검사하여 일정 조건을 만족할 때 데이터를 처리하는 방식

클라이언트는 서비스에 요청을 보내 작업을 제출하고, 제출한 작업과 관련된 토큰을 즉시 응답받는다.

즉시 응답!

클라이언트는 제출한 작업의 상태를 추적하기 위해 이 토큰을 사용하여 서비스를 폴링해야 한다.

단점

만약 서버의 응답이 지연될 경우, 클라이언트 스레드는 여러번 응답을 확인해야 하므로 오버헤드가 발생할 수 있다.

장점

클라이언트 측에서 중단이 발생하는 경우 클라이언트가 제출한 작업에 대한 폴링을 재개할 수 있으므로 제출된 작업의 상태/출력이 손실되지 않는다.

특히, 클라이언트 측 인바운드 트래픽이 허용되지 않는 네트워크 설정이 있는 경우 유리하다.

 

Callback Model

클라이언트(Caller)는 요청을 보낸 후 응답이 오는 것을 신경쓰지 않는다.

서버(Callee)에서 작업이 완료된 후에는 지정된 콜백 URI를 통해 응답을 전달받는다.

이러한 콜백 모델에서는 통제권의 역전이 일어난다.

작업이 완료되면 클라이언트에게 작업 결과를 알리는 것이 서비스의 책임이된다.

클라이언트가 서비스 end-point를 노출하고, 서비스 end-point를 콜백 URI로 서비스에서 사용하게 된다.

클라이언트는 더 이상 단순한 클라이언트가 아니며 이제 서버이기도 하다.

 

장점 : 서버의 응답을 여러번 확인하지 않아도 된다 .

단점 : 콜백이 누락될 수 있다.

 

 

 

 

 

참고

 

https://pakss328.medium.com/%EB%8D%B0%EC%9D%B4%ED%84%B0-%ED%86%B5%EC%8B%A0-%EB%B0%A9%EC%8B%9D-realtime-push-polling-4cdb696fb7ad

https://sanketdaru.com/blog/polling-model-async-rest-spring-boot/

https://forward-movement.tistory.com/129

https://m.blog.naver.com/loverjmc/220784040532