HTTP로 실시간 통신 흉내내기 : Polling, Long Polling, Streaming, Web Hook

참고한 자료

• https://velog.io/@hahan/Polling-Long-Polling-Streaming
• https://grammy.dev/guide/deployment-types
• https://junhyunny.github.io/information/spring-boot/polling-long-polling-and-spring-example/

HTTP 통신에 트릭을 사용해 실시간인 것처럼 작동하게 하는 기술로 Polling, Long Polling, Streaming, Web Hook 기법을 알아보자. 이 통신의 목적은 서버의 변경 사항을 클라이언트가 알게되도록 하는 것이다.

 

Polling

클라이언트가 일정 주기를 가지고 서버에 http request를 하는 방식이다.

 

 

서버의 변경사항 발생 여부와 상관없이 클라이언트가 일정 주기로 질의하기 때문에, 변경사항이 없는 타이밍에 질의한 요청은 쓸데없는 트래픽이 된다. 이 구조에서 더 많은 클라이언트가 서버에 물리거나 요청 주기가 짧아지면 서버에 부하가 증가하게 되고, 서버가 뻗을 수도 있다. 또 일정 주기마다 요청이 들어오기 때문에 실시간 정도의 빠른 응답을 기대하기 어렵다.

 

Long Polling

요청을 보내 연결을 유지하다가 서버에 변경사항이 발생하면 응답을 받는 방식이다. 대부분 30초 정도 연결을 유지한다.

기본 폴링 방식과 비교했을 때 서버 부하가 덜하고 실시간 응답을 기대할 수 있다. 하지만 요청을 보내는 클라이언트 수가 한번에 많아지면 서버 부하가 똑같이 늘어나므로 서버가 뻗을 가능성이 있다. 따라서 롱 폴링 방식은 일대일이나 적은 수의 사용자가 동시에 사용하는 메신저 등의 서비스에 적합하다.

 

Streaming

연결을 유지하면서 여러번 응답을 받는 방식. Persistent Connection을 맺는다.

롱 폴링 방식은 요청 한번에 대해서 변경사항이 발생하면 바로 응답하고 연결을 종료하지만, 스트리밍 방식은 한번 연결을 맺으면 연결이 끊어지기 전까지 서버 이벤트를 계속 보낸다. 롱 폴링에 비해 연결을 맺고 끊는 횟수가 적으므로 서버 부담이 덜 하다.

 

Web Hook

클라이언트에게 연락할 URL을 서버에게 넘겨주는 방식. 서버에서 변경사항이 발생하면 서버가 알고있는 URL에 변경사항을 알려준다. Push API라고도 부른다.

 

서버에서 연락이 오지 않을 것을 대비해서 한시간에 한번 정도 서버에 요청을 주기적으로 날리는 작업도 필요하다. 롱 폴링과 비교했을 때 외부에 노출해야하는 URL을 만들어야 한다는 번거로움이 있지만, 요청이 확실히 적기 때문에 네트워크 비용이 저렴하다.

 

HTTP 통신의 단점

 

위의 방법은 모두 HTTP를 기반으로 동작하는 방식이다.

HTTP 방식은 요청과 응답 시 헤더가 불필요하게 크다는 단점이 있다.

또 HTTP는 단방향 통신을 하므로 클라이언트가 요청을 해야만 서버에서 응답이 오기 때문에,

변경사항이 발생한 서버 측에서 능동적으로 응답을 보내기 어렵다.