HTTP 2 and How does it matters

Since a decade or so we have been using HTTP 1.1 for all kind server requests in application layer.There are a lot of latency issues when we used that for our traditional request response approach and the only thing we have found is hacks around this old HTTP 1.1 to suffice or solve a particular problem.
Hence that created a need for new version of HTTP which addresses all these issues at foundational protocol level.

I have been reading and exploring this a lot lately and have some useful things listed out as I explored it and can help even a beginner figure out HTTP 2.


HTTP 2

SPDY is a networking protocol introduced by Google in 2009. Its aim was to decrease web latency(time interval between request and response) and increase security.

HTTP/2 is a clone of SPDY. Google has now stopped developing SPDY and started working on HTTP/2 with the same ideas of SPDY.

HTTP2 is a binary protocol where as HTTP1.1 is an text based protocol 

Here is a simple explanation to it : 

Binary protocol versus text protocol isn't really about how binary blobs are encoded. The difference is really whether the protocol is oriented around data structures or around text strings. Let me give an example: HTTP. HTTP is a text protocol, even though when it sends a jpeg image, it just sends the raw bytes, not a text encoding of them. 

But what makes HTTP a text protocol is that the exchange to get the jpg looks like this:

Request:

GET /files/image.jpg HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.01 [en] (Win95; I)
Host: hal.etc.com.au
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8

Response:

HTTP/1.1 200 OK
Date: Mon, 19 Jan 1998 03:52:51 GMT
Server: Apache/1.2.4
Last-Modified: Wed, 08 Oct 1997 04:15:24 GMT
ETag: "61a85-17c3-343b08dc"
Content-Length: 60830
Accept-Ranges: bytes
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/jpeg

<binary data goes here>

Note that this could very easily have been packed much more tightly into a structure that would look (in C) something like

Request:

struct request {
  int requestType;
  int protocolVersion;
  char path[1024];
  char user_agent[1024];
  char host[1024];
  long int accept_bitmask;
  long int language_bitmask;
  long int charset_bitmask;
};

Response:

struct response {
  int responseType;
  int protocolVersion;
  time_t date;
  char host[1024];
  time_t modification_date;
  char etag[1024];
  size_t content_length;
  int keepalive_timeout;
  int keepalive_max;
  int connection_type;
  char content_type[1024];
  char data[];
};

Where the field names would not have to be transmitted at all, and where, for example, the responseType in the response structure is an int with the value 200 instead of three characters '2' '0' '0'. That's what a text based protocol is: one that is designed to be communicated as a flat stream of (usually human-readable) lines of text, rather than as structured data of many different types.

HTTP/2 Aims

Here is a list of objectives of HTTP/2 protocol:

1. Reduce latency
2. Reduce total number of TCP connections i.e., reduce number of open sockets
3. Better web security.
4. Maintain compatibility with HTTP/1.1 clients and server.
5. Maintain same usability as HTTP/1.1 i.e., can be used wherever we use HTTP/1.1
6. Better web security.

HTTP/2 Features

Here is a list of features of HTTP/2

1. Multiplexing: Multiple asynchronous HTTP requests over a single TCP connection.
2. Server Push: Multiple responses for single request
3. Header Compression: Compress HTTP headers along with content.
4. Request prioritization: While making multiple HTTP requests to a same domain they can be prioritized.
5. Binary Protocol: HTTP/2 is binary protocol whereas HTTP/1.1 is text protocol.

Server push is a nice feature as we don't have to repeatedly ask the server give me this and give me that.

Here a HTTP 2 compatible server understands what would we expect once we request for a resource and send them via same TCP connection with HTTP promises.

I would surely add to this post as I understand other intricacies to it.