HTTP/2 is short for ‘Hyper Text Transfer Protocol Version 2’. HTTP/2 and its predecessor, HTTP/1, are the de-facto network protocols in use today.

They define things such as:

HTTP/2 evolved out of Google’s experimental SPDY protocol as a successor to HTTP/1.1. Since it maintains high-level compatibility with HTTP/1.1, let’s first take a look at HTTP/1.x.


HTTP/1.0 was developed at CERN in 1989. IETF RFC 1945 in 1996 was the first officially recognized HTTP/1.0 version. Just a few years later, HTTP/1.1 was specified in IETF RFC 2068. The standard was improved in IETF RFC 2616 in 1999.

Both of these specifications eventually were obseleted in 2007 in the following RFCs:

Thankfully it’s not necessary to become familiar with every detail of these RFCs. HTTP/1.0 is a request-response protocol. For now, we’ll just focus on this.

The Request

When a node is connected to another node via TCP/IP, it can make a request by sending ASCII text as below (the empty newline is required!):


{ data: "Test" }

Common headers are things like Authorization (for access control), and Cache-Control (for caching).

The Response

The recipient of a message responds in a similar format:

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Connection: close

{ data: "bar" }


The major differences in HTTP/2 do not lie in aspects like methods, status codes, or URIs, but in data frames and transportation.

It builds on HTTP/1.1 by adding features like:

  • Server Push, to allow the server to respond with more data than requested.
  • Multiplexing, to avoid ‘head-of-line’ blocking problem in HTTP/1.1
  • Pipelining, to reduce network wait time.
  • Compression of headers, to reduce overall network costs.

Compared to HTTP/1.1, HTTP/2.0 offers applications like TiKV many opportunities for performance gains.