HTTP from beginning to 2.0

HTTP0.9

In 1991, Berners-Lee outlined the motivation for the new protocol.
The goal is file transfer functionality, ability to request an index search of a hypertext archive, format negotiation, and an ability to refer the client to another server.
It is basically a extremely simple, Telnet-friendly protocol that only transfer html file(connection is terminated after the document transfer is complete).

Most of the machine still have telnet(expect MacOS High Seirra). You can try the following command.

$> telnet google.com 80

Trying xxx.xxx.xxx.xxx...
Connected to google.com.

GET /about/

(hypertext response)
(connection closed)

HTTP 1.0

The period from 1991 to 1995 is one of rapid coevolution of the HTML specification, Web browser and made a big change on internet.
Some key changes:

Request/response consist of multiple newline separated header field.
Response has its own header.
Response object is not limited to hytpertext.

All request require new TCP connection(high cost to web service).

$> telnet google.com 80

Connected to xxx.xxx.xxx.xxx

GET /humans.txt HTTP/1.0
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Accept: */*

HTTP/1.0 200 OK
Accept-Ranges: none
Vary: Accept-Encoding
Content-Type: text/plain
Date: Sun, 22 Apr 2018 04:35:53 GMT
Expires: Sun, 22 Apr 2018 04:35:53
Cache-Control: private, max-age=0
Last-Modified: Thu, 08 Dec 2016 01:
X-Content-Type-Options: nosniff
Server: sffe
X-XSS-Protection: 1; mode=block

(plain-text response)
(connection closed by foreign host)

HTTP 1.1

The work on turning HTTP into an official IETF Internet standard proceeded in parallel with the documentation effort around HTTP/1.0 and happened over a period of roughly four years: between 1995 and 1999.

The HTTP/1.1 standard resolved a lot of the protocol ambiguities found in earlier versions and introduced a number of critical performance optimizations: keepalive connections, chunked encoding transfers, byte-range requests, additional caching mechanisms, transfer encodings, and request pipelining.

HTTP/1.1 changed the semantics of the HTTP protocol to use connection keepalive by default. Meaning, unless told otherwise (via Connection: close header), the server should keep the connection open by default.

However, this same functionality was also backported to HTTP/1.0 and enabled via the Connection: Keep-Alive header. Hence, if you are using HTTP/1.1, technically you don’t need the Connection: Keep-Alive header, but many clients choose to provide it nonetheless.

(Keep alive implementation in nodejs:
nodejs close connection when there is no request in queue that need the connection.)

One thing you can try in 1.1 is its connect allow multiple connection.

$> telnet google.com 80
Connected to xxx.xxx.xxx.xxx

GET /humans.txt HTTP/1.1 

HTTP/1.1 200 OK
Accept-Ranges: none
Vary: Accept-Encoding
Content-Type: text/plain
Date: Sun, 22 Apr 2018 05:06:24 GMT
Expires: Sun, 22 Apr 2018 05:06:24 GMT
Cache-Control: private, max-age=0
Last-Modified: Thu, 08 Dec 2016 01:00:57 G
X-Content-Type-Options: nosniff
Server: sffe
X-XSS-Protection: 1; mode=block
Transfer-Encoding: chunked

(plain-text response)

GET /humans.txt HTTP/1.1 

HTTP/1.1 200 OK
Accept-Ranges: none
Vary: Accept-Encoding
Content-Type: text/plain
Date: Sun, 22 Apr 2018 05:06:24 GMT
Expires: Sun, 22 Apr 2018 05:06:24 GMT
Cache-Control: private, max-age=0
Last-Modified: Thu, 08 Dec 2016 01:00:57 G
X-Content-Type-Options: nosniff
Server: sffe
X-XSS-Protection: 1; mode=block
Transfer-Encoding: chunked

(plain-text response)

You could see that connection didn't closed.

HTTP 2.0

The primary focus of HTTP/2 is on improving transport performance and enabling both lower latency and higher throughput. The major version increment sounds like a big step, which it is and will be as far as performance is concerned, but it is important to note that none of the high-level protocol semantics are affected: all HTTP headers, values, and use cases are the same.

Any existing website or application can and will be delivered over HTTP/2 without modification: you do not need to modify your application markup to take advantage of HTTP/2. The HTTP servers will have to speak HTTP/2, but that should be a transparent upgrade for the majority of users. The only difference if the working group meets its goal, should be that our applications are delivered with lower latency and better utilization of the network link!

One interesting improvement in 2.0 is server push.
Following the practice above. Server push allow server to guess what files will be requested by client. So instead of wait for request from client, server is able to push files directly to client without request.

Reference:
https://hpbn.co/
https://github.com/nodejs/node/issues/10774