들어가며

이전 편에서는 HTTP 요청을 하기 위한 단계로 DNS 조회와 TCP 연결과정에 대해서 알아보았다. 이번 편에서는 주로 채팅에서 사용하는 Polling, Long Polling, SSE에 대해 알아보자.

Polling

polling은 클라이언트가 주기적으로 HTTP 요청을 보내 새로운 데이터가 있는지 물어보고, 서버에게 응답을 받는 방식이다.

Polling의 통신 과정

클라이언트 -> 서버 요청

• 클라이언트는 서버에게 새로운 채팅이 있는지 요청한다.
  

클라이언트 <- 서버 응답

• 서버는 새로운 채팅이 없기 때문에 없다고 클라이언트에게 응답한다.

클라이언트 -> 서버 재요청

• 시간이 지난 후, 클라이언트는 다시 서버에게 새로운 채팅이 있는지 요청한다.
  

클라이언트 <- 서버 재응답

• 이번에도 채팅 이벤트가 없었기 때문에 서버는 아니라는 응답을 한다.
  

서버에 채팅 이벤트 발생

• 위와 같은 HTTP 요청 과정을 반복하다가, 서버에 새로운 채팅이 오는 이벤트가 발생한다.
• 하지만 클라이언트는 이를 바로 알 수 없다. 왜냐하면 다음 폴링 요청주기까지 아직 시간이 남았기 때문에, 서버는 이벤트를 즉시 전달할 수 없다.
  

클라이언트 -> 서버 이벤트 수신

• 다음 폴링 주기가 되면 클라이언트가 다시 서버에 요청을 보낸다.
• 서버는 그 사이에 발생했던 새로운 채팅들을 응답값으로 보내준다.

Polling의 단점

위의 과정을 통해 Polling에는 크게 3가지 단점이 있다.

• 실시간성 확보 불가
  서버에 새로운 메시지 이벤트가 와도 폴링의 주기가 되기 전까지는, 응답을 받지 못 한다.
  기본적으로 폴링의 주기를 T라고 표현하면 평균 지연시간은 T/2에서 최악의 경우 T까지 걸린다.

• 트래픽 낭비
  클라이언트가 서버로부터 채팅 이벤트를 수신하기 위해 불필요한 요청을 주기적으로 해야한다.

• HTTP 오버헤드
  HTTP의 요청 및 응답에는 헤더의 정보가 추가되는데, 헤더 압축을 해도 빈 호출 자체는 남아있다는 단점이 있다.

Long Polling

폴링의 단점들을 보안하기 위한 방법으로, 롱폴링은 클라이언트의 HTTP 요청에 바로 응답하지 않고 서버에 새로운 이벤트가 발생할 때까지 대기했다가 응답하는 방식이다.
즉, HTTP 요청이 들어오면 새로운 데이터가 발생하는 시점에 응답한다. 이와 같은 방식으로 폴링보다 지연시간을 줄일 수 있다.

Long Polling의 통신 과정

클라이언트 -> 서버 요청

• 클라이언트가 서버에 새로운 채팅이 있는지 요청한다.
• 서버는 이에 바로 응답하지 않고, 새로운 채팅이 발생할 때까지 대기한다.
  

클라이언트 <- 서버 응답 (이벤트 발생 시)

• 서버에 새로운 채팅 이벤트가 발생하면 해당 요청에 응답한다.
  

클라이언트 -> 서버 요청 (재요청)

• 클라이언트가 이전 요청에 대한 응답 값을 받으면, 다시 새로운 이벤트가 있는지 요청한다.
• 서버는 새로운 이벤트가 발생할 때 까지 대기한 후, 응답한다.
  

Long Polling의 장단점

Long Polling 통신에도 몇가지 장단점이 있다.

Long Polling의 장점

• 낮은 지연시간
  롱폴링 방식은 새로운 이벤트가 생기는 즉시 응답하기 때문에, 폴링의 평균 지연시간인 T/2보다 작다.

• 불필요한 요청 감소
  클라이언트에서 이벤트가 있는지 주기적으로 요청하지 않아도 되기 때문에, 불필요한 요청이 감소된다.

Long Polling의 단점

• 클라이언트 수에 따른 서버 부하
  클라이언트가 많아질수록, 대기 상태인 클라이언트가 많아지게 되고 이 과정에서 클라이언트와 서버의 커넥션을 계속 유지해야하기 때문에 서버 부하로 이어질 수 있다.
• 양방향 통신은 분리
  서버에서 클라이언트에게 알림은 롱폴링으로 가능하지만, 클라이언트가 서버에게 요청은 기존의 POST 메서드를 필요로한다.

SSE (Server-Sent Events)

SSE는 HTTP 위에서 서버가 클라이언트로 단방향 이벤트 스트림을 보내주는 방식이다.
클라이언트가 한 번의 GET 요청으로 연결을 요청하면, 서버는 응답을 닫지 않고 이벤트를 전송한다.
롱폴링 방식과의 차이점은, 롱폴링은 이벤트가 발생하면 클라이언트로 즉시 응답하고 해당 요청 및 사이클을 종료한다. 이후 클라이언트는 다음 요청을 다시 열음
반면 SSE 방식은 클라이언트의 GET 요청에 대한 응답을 보내고 요청 및 응답 사이클을 끝내지 않고 연결을 유지하여, 새로운 이벤트가 발생하면 클라이언트이 재요청이 없어도 이벤트를 보낼 수 있다.

SSE의 통신 과정

클라이언트 -> 서버 요청 (연결 열기)

• 클라이언트가 채팅방 스트림을 구독하여 연결을 유지한다.
• 서버는 이에 바로 응답하지 않고, 새로운 채팅이 발생할 때까지 대기한다.
• 롱폴링의 방식과 동일

클라이언트 <- 서버 응답 (이벤트 발생 시)

• 서버에 새로운 채팅 이벤트가 발생하면 해당 요청에 응답한다.

클라이언트 <- 서버 응답 (재요청X, 응답전송)

• 새 메시지가 생기면 이벤트를 전송하고, 연결은 그대로 유지한다.
• 롱폴링은 1번의 요청에, 한 번의 이벤트만 전송함 (재요청 필요)
  

SSE의 단점

• 단방향 제약
  SSE는 서버가 클라이언트에게 전송만 가능하다. 따라서 채팅을 읽었다는 클라이언트 -> 서버로 이벤트를 전송해야 하는 경우, HTTP 요청 채널을 늘려야한다.
  마찬가지로, 클라이언트에게 문제가 발생했을 경우, 서버는 알아차리기 어렵다는 단점이 있다.

• 클라이언트 수에 따른 서버 부하
  클라이언트와 서버 사이의 지속적인 커넥션을 계속 유지해야하기 때문에 서버 부하로 이어질 수 있다.

마치며

이번 글에서는 Polling,Long Polling, SSE가 무엇이고 어떤 흐름으로 동작하는지 살펴보았다. 각각의 장단점이 있고 어떤 환경에서 사용해야하는지 알 수 있었다.
가장 큰 단점은 3가지 방법 모두 서버와 클라이언트가 양방향으로 통신할 수 없다는 점이다.

다음 글에서는 양뱡향 통신을 기반으로 WebSocket을 다룰 예정이다.