Menu
I am trying to understand the way the HTTP/2 protocol compresses the Data field. I didn't find an algorithm in the rfc. I know its a binary protocol. I am looking for a way to get the binary protocol back into human readable content. I thought it is gzip like writen in the header but it isn't anyone has a source where i can look for the binary protocol refernce?
Frame 55: 151 bytes on wire (1208 bits), 151 bytes captured (1208 bits) on interface 0
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst:00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Transmission Control Protocol, Src Port: 443 (443), Dst Port: 55300 (55300), Seq: 1087, Ack: 1078, Len: 85
Secure Sockets Layer
HyperText Transfer Protocol 2
Stream: HEADERS, Stream ID: 13, Length 47
Length: 47
Type: HEADERS (1)
Flags: 0x04
0... .... .... .... .... .... .... .... = Reserved: 0x00000000
.000 0000 0000 0000 0000 0000 0000 1101 = Stream Identifier: 13
[Pad Length: 0]
Header Block Fragment: 8854012a5a839bd9ab5f87497ca589d34d1f5c0333333861...
[Header Length: 177]
[Header Count: 6]
Header: :status: 200
Header: access-control-allow-origin: *
Header: content-encoding: gzip
Header: content-type: text/html
Header: content-length: 338
Header: date: Wed, 17 Aug 2016 15:14:25 GMT
Padding: <MISSING>
Frame 56: 442 bytes on wire (3536 bits), 442 bytes captured (3536 bits) on interface 0
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Transmission Control Protocol, Src Port: 443 (443), Dst Port: 55300 (55300), Seq: 1172, Ack: 1078, Len: 376
Secure Sockets Layer
HyperText Transfer Protocol 2
Stream: DATA, Stream ID: 13, Length 338
Length: 338
Type: DATA (0)
Flags: 0x01
0... .... .... .... .... .... .... .... = Reserved: 0x00000000
.000 0000 0000 0000 0000 0000 0000 1101 = Stream Identifier: 13
[Pad Length: 0]
Data: 1f8b080000096e8800ff9cd2416b1b311005e0b3ffc5eb9e...
Padding: <MISSING>
685
HTTP/2's HPACK algorithm compresses request and response metadata using Huffman encoding that results in an average reduction of 30% in header size. A proof of concept done by Cloudflare on its network found a 53% reduction in ingress traffic with HTTP/2's HPACK and a 1.4% savings on egress traffic.
There are a lot of performance benefits with HTTP/2 and one of the most exciting ones is definitely HPACK compression. Unlike HTTP/1.1, headers can now be compressed using an algorithm known as Huffman encoding which in turn reduces the amount of data being sent.
HTTP/2 Security Although the standard itself does not require the use of encryption, all major browser implementations (i.e. Firefox, Chrome, Safari, Opera, IE, Edge) have decided that they will only support HTTP/2 over TLS.
According to this statement by Mark Nottingham, chair of the IETF HTTP Working Group, "HTTP/2 doesn't require you to use TLS (the standard form of SSL, the Web's encryption layer), but its higher performance makes using encryption easier, since it reduces the impact on how fast your site seems." Yet, even with this ...
The response body of a HTTP/2 response is compressed (or not) exactly the same way as it works with HTTP/1: Accept-Encoding: in the request and Content-Encoding: in the response. HTTP/2 did nothing new with compression of the bodies, only with headers which weren't compressed at all in HTTP/1.
135
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
