HTTP Pull 과 HTTP Push

HTTP 데이터 전송은 HTTP Pull과 HTTP Push 두가지로 나뉜다.

HTTP Pull

항상 client의 request에서 통신이 시작된다는 사실을 기억하자.
이것이 바로 HTTP Pull이다. (default 임)

서버에서 데이터를 받아오는 방법은 두가지가 있다.

1. HTTP GET request를 이용하는 방법 (사용자가 이벤트를 발생시킨다.)
2. AJAX를 이용한다. 사용자 개입이 없이 동적으로 호출하는 방법이다. (AJAX를 정기적으로 호출하는 것을 polling이라고도 한다.)

모든 request는 TTL(Time To Live)을 가진다. TTL은 브라우저 별로 다르다. 보통 30 ~ 60초다.
TTL안에 response를 못받으면 브라우저가 연결을 강제로 해제한다. 이렇게 안하면 연결이 안끊긴 상태에서 계속 새로운 연결이 들어오면서 결국에 서버가 다운되는 상태에 이르게 된다.

그런데 나의 request가 reponse되기 위해서 필요한 시간이 브라우저의 TTL보다 확실히 크다는 것을 이미 알고 있다면 어떻게 해야할까. (응답까지 61초 걸리는데 TTL은 60초이면?)

persistence connection

일회성 통신이 아니라 몇 회 더 묶어서 통신을 하면 된다. 그런데 브라우저는 TTL이 지나면 강제로 연결을 종료하는데
어떻게 하면 계속 연결이 될 수 있을까.

Heartbeat Interceptors
연결이 끊기지 않도록 내용이 없는 request와 reponse를 지속적으로 주고 받는 것을 의미한다.
지속적으로 통신을 하기 때문에 연결은 종료되지 않으나,
HTTP Pull과 비교하면 대역폭이나 자원의 낭비는 분명히 발생한다.
그럼에도 불구하고 사용자 경험 측면에서 안끊기는 것이 더 나은 경우가 있다. 대표적으로 웹 게임을 그 예로 들 수 있다.

HTTP Push

모든 server와 client간의 통신은 대역폭을 소비한다. 그런데 신규, 변경 데이터가 없어도 client는 이 사실을 알지 못하기 때문에 같은 데이터임에도 불구하고 계속 request를 보낸다. 굉장히 비효율적이라고 할 수 있다. 그렇다면 변경사항이 있을 때만 보내면 좋은데 어떻게 안되나 싶다.

그래서 푸시한다.

client는 특정 정보를 server에 단 한번 보낸다. 그 이후에 server는 변경, 신규 데이터가 있을 때 client로 전송한다. 이 방법은 지속적으로 request를 단 한번 보내기 때문에 server에 부하가 줄어든다. (callback 이라고도 한다.)

이 push 방식에는 몇가지 종류가 있다.

• Ajax Long polling
• Web Sockets
• HTML5 Event Source
• Message Queues
• Streaming over HTTP

하나씩 알아보자..

• Ajax Long polling

이 친구는 Ajax와 Web Sockets 사이 어딘가에 있다. client가 request를 보낸다고 server가 바로 응답하지 않고 보류한다. 변경사항이 발생하는 순간 response를 보낸다. heartbeat interceptors처럼 공수표를 날리면서 연결을 유지하는것은 아니다.
기본적인 polling보다 조금더 길게 연결을 하고, 연결이 끊어지면 재연결이 필요하다.
일반적인 polling에 비해 request 횟수가 적다는 장점이 있다.

• web sockets
low latency data stream에 선호되는 방식이다.
원하는 만큼 연결을 유지할 수 있고, HTTP가 아닌 TCP통신을 한다.
양방향 통신이기 때문에 server, client 둘 다 web sockets을 지원해야 가능하다.
• HTML5 Event-Source API and Server Sent Events
SSE는 client가 polling하는 것이 아니라 server가 변경사항이 발생하면 자동으로 push 하는 형태이다. 이 때 메시지는 이벤트로 처리가 된다.
client가 초기 request와 연결을 설정하면 server는 데이터 전송을 시작할 수 있게 된다.
이 방식 또한 heartbeat interceptors을 사용하지 않기 때문에 낭비자원이 없다.
그리고 데이터는 server -> client 단방향으로 일방적으로 전달된다.
• Streaming over HTTP
데이터를 chunk라는 단위로 쪼개서 부분 다운로드 받는 것처럼 영상을 시청 가능하게 해준다.