네트워크 요청인 Long Polling에 관한 글입니다.
글 작성 계기
최근에 Ajax와 Rest API와 같이 서버와 통신 하는 개념에 대해서 알아보다가 https://ko.javascript.info/ 에서 네트워크 요청 부분에 Long Polling 이라는 항목이 있었습니다. 이 Long Polling에 대해서 읽어보면서 이것이 무엇인지 궁금해졌고 조사하여 글을 작성하게 되었습니다.
Polling과 HTTP
Polling
위키백과에서 Polling 이란 하나의 장치(또는 프로그램)가 충돌 회피 또는 동기화 처리 등을 목적으로 다른 장치(또는 프로그램)의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료처리를 하는 방식을 말한다고 합니다.
출처: https://ko.wikipedia.org/wiki/%ED%8F%B4%EB%A7%81_(%EC%BB%B4%ED%93%A8%ED%84%B0_%EA%B3%BC%ED%95%99)
그렇다면 이 polling이 왜 나오게 된 것인지 찾아보았는데 그것은 바로 HTTP의 특성과 관련되어 있었습니다.
HTTP
HTTP 프로토콜의 가장 큰 특성은 비연결성 입니다. 이 특성으로 인해, HTTP 프로토콜을 사용하는 웹페이지의 경우 클라이언트와 서버가 한 번 연결을 맺은 후, 클라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어버리는 성질을 말합니다.(연결을 유지하기 위한 리소스를 줄이기 위해)
따라서 웹 소켓이 등장하기 전, 리얼타임 웹을 위한 기법으로 일정한 주기를 가지고 서버와 응답을 주고 받기 위해 polling이라는 방법을 사용하였습니다.
Polling의 특징
이 polling은 다음과 같은 특징을 가지고 있습니다.
- 주기적으로 요청하여 결과를 확인하는 방식입니다.
- 요청 주기가 짧아지게 되면 서버에 부담이 커지게 됩니다.
- 반대로 주기가 길면 실시간 성능이 떨어지게 됩니다.
이를 보완하기 위해 Long polling과 Streaming 방식이 존재합니다.
Long Polling
Long Polling 방식은 polling과 기본방식이 유사하지만 클라이언트가 서버에 HTTP Request를 요청하면, 서버는 대기하고 있다가 이벤트가 발생 시 응답을 하는 방식입니다. 이 Long Polling은 데이터가 업데이트 되면 그 즉시 클라이언트에게 응답을 보내고 전달받은 데이터를 처리하므로 실시간성이 아주 높습니다.
그러나 다수의 클라이언트가 존재하여 동시에 이벤트가 발생할 경우, 서버는 각 클라이언트들 마다 응답을 해주어야하기 때문에 이 순간 서버의 부담이 증가하게 되며 데이터가 주어지는 즉시 바로 반응하고 보내므로 요청 간격이 줄어든다면 polling보다 훨씬 데이터를 많이 보내게 됩니다.
아래는 Long Polling이 JS 코드에서 어떤식으로 구현되는지 알아보기 위해 async await를 사용하여 간단한 클라이언트측 구독 기능의 예제를 https://ko.javascript.info/long-polling 에서 가져와보았습니다.
async function subscribe() {
let response = await fetch("/subscribe");
if (response.status == 502) {
// Status 502 is a connection timeout error,
// may happen when the connection was pending for too long,
// and the remote server or a proxy closed it
// let's reconnect
await subscribe();
} else if (response.status != 200) {
// An error - let's show it
showMessage(response.statusText);
// Reconnect in one second
await new Promise(resolve => setTimeout(resolve, 1000));
await subscribe();
} else {
// Get and show the message
let message = await response.text();
showMessage(message);
// Call subscribe() again to get the next message
await subscribe();
}
}
subscribe();Streaming
스트리밍 방식은 하나의 웹 요청에 대해 웹 접속을 계속 열어두고 데이터를 이벤트 때마다 지속적으로 내려받는 방식입니다. 이는 응답마다 다시 요청하는 Long Polling에 비해 효율적이고 서버의 상태 변경이 잦은 경우 유리하지만 연결을 언제까지 맺을 것인지에 관한 유효성 관리 등의 부담이 발생합니다.
결론
앞서 살펴본 3가지는 HTML5 WebSocket이 나오기 이전 HTTP로 리얼타임 앱을 구현하기 위해 사용하던 방식이었습니다. Websocket은 웹 서버와 웹 브라우저간 실시간 양방향 통신환경을 제공해주는 기술로, Polling 방식과 다르게 양방향으로 원할때 요청을 보낼 수 있고, HTTP 요청/응답 헤더 데이터가 존재하지 않아 오버헤드가 적다고 합니다.
따라서 WebSocket이 나온 현재, 실시간으로 통신하는 앱을 구현할 때에는 WebSocket을 사용하는 것이 더 타당할 것입니다. 그러나 이 기술이 나오기 전, 이 기능을 구현하기 위해 어떠한 방법들이 있었고, 무슨 불편함과 단점들이 있었는 지 아는 것은 중요하다고 생각합니다. 그 기술의 필요성을 더 잘 느끼는 것뿐만아니라, 이 기술이 왜 이러한 방식으로 동작하는 지와 같은 이해하는 측면에 있어서 많은 도움을 주기 때문입니다.
참고자료
