728x90
반응형
HTTP 통신은 클라이언트에서 서버로의 단방향 통신을 위해 만들어진 기술로, Web Socket 기술이 나타나기 전에 실시간 통신을 위해 사용되었다.
그렇다면 Polling은 완전한 실시간 기술일까 ?
그렇지 않다. Polling은 기존의 HTTP 통신에 약간의 트릭을 더해 실시간으로 작동하는 것처럼 보이도록 한 기술이다.
HTTP 통신은 실시간이 아니므로 언제 통신이 발생할지 예측이 불가능하기 때문에 일정한 주기를 가지고 서버에 HTTP 리퀘스트를 던져 이벤트 내용을 전달받는데, 이게 Polling의 트릭이다.
본격적인 내용에 앞서, HTTP 통신에 대해 간략하게 알아보고 가자.
1. 비연결성 (connectionless)
-> 클라이언트가 보낸 요청에 대해 서버가 응답을 하면 맺었던 연결을 끊어버림
2. 무상태 (stateless)
-> 서버는 클라이언트 상태를 보존하지 않음
+ 단방향
-> 클라이언트=>서버: request, 서버=>클라이언트: response
-> 단방향 통신이기 때문에 한 번 통신할 때마다 많은 양의 데이터를 헤더에 담아서 보내게 됨
1. Polling
- 가장 기본적인 데이터 처리 방식으로, 클라이언트가 특정 주기를 가지고 서버에 HTTP 리퀘스트를 보냄
- 서버는 데이터가 있든 없든 클라이언트의 리퀘스트를 받을 때마다 즉시 응답을 보냄
- 잦은 HTTP 리퀘스트로 클라이언트가 많아지면 서버의 부하가 커짐 + 클라이언트측에서 실시간 정도의 빠른 응답 기대하기 어려움
- HTTP 오버헤드 (전송 데이터 양에 비해 헤더의 양이 큼)
2. Long Polling
- 클라이언트에서 서버로 HTTP 리퀘스트를 보내고 서버에서 응답이 올 때까지 기다림
- 서버는 클라이언트에게 보낼 데이터가 있을 때 응답 또는 시간 초과가 발생할 때까지 리퀘스트(접속)를 열어둠 (그냥 Polling과 다르게 서버가 즉시 응답하지 않음)
- 서버에서 리퀘스트가 처리되어 클라이언트로 응답을 보내며 연결 종료. 클라이언트는 응답을 받은 후 다시 리퀘스트를 보냄
- 불필요한 요청을 줄일 수 있어 그냥 Polling 방식보다는 서버의 부담이 줄어들지만 이벤트들의 시간 간격이 좁다면 Polling과 큰 차이가 없어짐 + 다수의 클라이언트가 동시에 요청시 서버 부하 급증
정리)
| Short Polling (그냥 Polling) | Long Polling | |
| 요청 간격 | 정해진 주기로 요청 (ex. 1초) | 요청 후 데이터가 생길 때까지 기다렸다 다시 요청 |
| 응답 시간 | 데이터가 없어도 즉시 응답 | 데이터가 있을 때만 응답 |
| 서버 부하 | 많음 (불필요한 요청 많음) | 낮음 (필요시에만 응답) |
| 실시간성 | 낮음 | 높음 |
3. Streaming
- TCP connection과 비슷
- 서버에서 데이터를 작은 조각(chunk) 단위로 나누어 클라이언트에게 전송
- 서버는 새로운 데이터가 생기면 바로 클라이언트에게 보내고 클라이언트는 받은 데이터를 바로 처리
- 서버는 지속적으로 데이터를 보내기 위해 연결을 유지 (일반적인 HTTP 연결과 다르게 한 번 연결되면 데이터를 계속 흘려보냄)
728x90
반응형