HTTP Basic Flow Overview

HTTP
Http protocol has been designed to serve and transfer information, resources across the world wide web with an architecture style (REST) which discourages bottleneck (by utilizing routers, gateways, proxys, tunneling etc), network congestion (by limiting no. of connection at a time, Connection timeout etc) and encourages Uptime and availability (using Stateless protocol, Connection close on Response),Scalability (using Stateless, Client-Server model, etc.), Uniformity (by defining a set of Methods like PUT, POST, GET, DELETE, HEAD, OPTION etc. for all and pre-defined purposes).

• It states that a client should first establish a communication channel and send an Http request. Then each Http request for a resource or information must be acknowledged with an Http Response and then the communication channel should be disconnected from the server immediately.
• It also states that an established but idle channel should be time-out and disconnected automatically.
• It also recommends that an Http Client (for e.g. a browser) should make at most 2 connections per server at any given point of time.
• Http should not be used for a stateful, client server based model where dedicated and active connections are required for communication. It should not be used where both way communications can be initiated even through an established channel, but only for pull based Request/Response flow model.

HTTP and HTTP based server push

Overview
HttpPush refers to the mechanism whereby an Http Server is able to send data to the HttpClient as and when it is available instead of waiting for client to Poll the server, thereby facilitating an http based real time notification platform. This blog discusses and showcase the available approaches for designing an Http Server Push (unlike the conventional Http Pull) based solution for a business model. This document does not make a comparative study between the different approaches as each one of them is suitable for a particular business scenario. It also discusses some finer details of Http protocols (but not all) for better understating of the protocol, the Http push approaches and its limitations. It highlights the end to end flow between an Http Client and Server for each of the approaches.
The below section is divided into two parts - HTTP Overview and Server push approaches.
Http Overview: Please follow HTTP Basic Flow Overview
Server push approaches

ShortPolling
This approach is not exactly an Http Push, but still can be used to get data in near real time from the Http Server. This is applicable for both Http1.0 and Http1.1. Typically; this is chosen when no other option is available due to some constraints on the client side programming. As the name suggest, ShortPolling is a mechanism to continuously poll the Http server. With each Http Request, the server should check if there is any new data available, then it sends the same else send a blank Http Response. HttpClient makes a next request after a delay (say 1 sec) after the HttpResponse for the previous one is received. And this goes on and on and on.

• Though with Http1.1 (Persistent Connection), it can use the same (persistent) connections for all the requests/responses, but still this is a waste of resource, time, bandwidth, network where the chances of getting new data with every request is less. This may be useful where there is chance of high data availability every second like the Stock market
• This can be useful when a server can determine the time for next availability of data and instead of sending back a blank response, it sends the (future) time for availability of new data. The next request from the client can be triggered based on the time received with the previous response.