HTTP/2

HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  

It also introduces unsolicited push of representations from servers to clients. 
This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  

HTTP's existing semantics remain unchanged.

　HTTP1.1 Disadvantages

　One open request per connection
　Duplication of data

　HTTP/2 Advantages

　Header compression using HPACK

　Server Push

　is binary, instead of textual

　is fully multiplexed, instead of ordered and blocking

　can therefore use one connection for parallelism

　uses header compression to reduce overhead

　allows servers to “push” responses proactively into client caches

1.Binary Framing

All frames begin with a fixed 9-octet header followed by a variable-
   length payload.

    +-----------------------------------------------+
    |                 Length (24)                   |
    +---------------+---------------+---------------+
    |   Type (8)    |   Flags (8)   |
    +-+-------------+---------------+-------------------------------+
    |R|                 Stream Identifier (31)                      |
    +=+=============================================================+
    |                   Frame Payload (0...)                      ...
    +---------------------------------------------------------------+

                          Figure 1: Frame Layout

• Frame : Smallest unit during communication
• Message : Consist of one or more frame, such as request & response
• Connection : same as HTTP1.1, refer to TCP connect
• Stream : A "stream" is an independent, bidirectional sequence of frames exchanged between the client and server within an HTTP/2 connection.

HTTP/2, data stream send via message,and message consist of multiple frame, frame can be unordered.

2.Request and Response Multiplexing

　　With HTTP/1.x, if the client wants to make multiple parallel requests to improve performance, then multiple TCP connections must be used.

　　This behavior is a direct consequence of the HTTP/1.x delivery model, which ensures that only one response can be delivered at a time (response queuing) per connection. Worse, this also results in head-of-line blocking and inefficient use of the underlying TCP connection.

　　The new binary framing layer in HTTP/2 removes these limitations, and enables full request and response multiplexing, by allowing the client and server to break down an HTTP message into independent frames, interleave them, and then reassemble them on the other end.

　　A single http2 connection can contain multiple concurrently-open streams, with either endpoint interleaving frames from multiple streams. Streams can be established and used unilaterally or shared by either the client or server and they can be closed by either endpoint. The order in which frames are sent within a stream is significant. Recipients process frames in the order they are received.

Multiplexing the streams means that packages from many streams are mixed over the same connection. Two (or more) individual trains of data are made into a single one and then split up again on the other side.

3.Stream priority

Once an HTTP message can be split into many individual frames, and we allow for frames from multiple streams to be multiplexed, the order in which the frames are interleaved and delivered both by the client and server becomes a critical performance consideration. To facilitate this, the HTTP/2 standard allows each stream to have an associated weight and dependency:

• Each stream may be assigned an integer weight between 1 and 256
• Each stream may be given an explicit dependency on another strea

4.Server push

Another powerful new feature of HTTP/2 is the ability of the server to send multiple responses for a single client request. That is, in addition to the response to the original request, the server can push additional resources to the client, without the client having to request each one explicitly!

At the protocol level, HTTP/2 server push is driven by PUSH_PROMISE frames. A PUSH_PROMISE describes a request that the server predicts the browser will make in the near future. As soon as the browser receives a PUSH_PROMISE, it knows that the server will deliver the resource. If the browser later discovers that it needs this resource, it will wait for the push to complete rather than sending a new request. This reduces the time the browser spends waiting on the network.

NodeJS example:

const http2 = require('http2')
const server = http2.createSecureServer(
  { cert, key },
  onRequest
)

function push (stream, filePath) {
  const { file, headers } = getFile(filePath)
  const pushHeaders = { [HTTP2_HEADER_PATH]: filePath }

  stream.pushStream(pushHeaders, (pushStream) => {
    pushStream.respondWithFD(file, headers)
  })
}

function onRequest (req, res) {
  // Push files with index.html
  if (reqPath === '/index.html') {
    push(res.stream, 'bundle1.js')
    push(res.stream, 'bundle2.js')
  }

  // Serve file
  res.stream.respondWithFD(file.fileDescriptor, file.headers)
}

 

5.Header Compression

 Each HTTP transfer carries a set of headers that describe the transferred resource and its properties. In HTTP/1.x, this metadata is always sent as plain text and adds anywhere from 500–800 bytes of overhead per transfer, and sometimes kilobytes more if HTTP cookies are being used; see Measuring and Controlling Protocol Overhead. To reduce this overhead and improve performance, HTTP/2 compresses request and response header metadata using the HPACK compression format that uses two simple but powerful techniques.

 

 

6.APLN:Aplication Layer Protocol Negotiation

•  If client support HTTP/2, then request will contains 'Upgrade' field

　　　　GET /page HTTP/1.1 
　　　　Host: server.example.com 
　　　　Connection: Upgrade, HTTP2-Settings 
　　　　Upgrade: HTTP/2.0 
　　　　HTTP2-Settings: (SETTINGS payload) 

• if server not support HTTP/2

　　　　HTTP/1.1 200 OK 

　　　　Content-length: 243 
　　　　Content-type: text/html 
　　　　(... HTTP 1.1 response ...) 

• if server support HTTP/2

　　　　HTTP/1.1 101 Switching Protocols
　　　　Connection: Upgrade
　　　　Upgrade: HTTP/2.0
　　　　(... HTTP 2.0 response ...)

7.Browser support table for HTTP/2

 

refers:
https://tools.ietf.org/html/rfc7540
http://chimera.labs.oreilly.com/books/1230000000545/index.html
https://www.cnblogs.com/yingsmirk/p/5248506.html