[NDC London] HTTP: History & Performance

By: @anabalica

Hypertext Transfer Protocol

Hypermedia Transfer Protocol

HTTP/0.9 (1991)

㱺 telnet stallman.org 80 Trying xxx.xxx.xx.xxx... Connected to stallman.org. Escape
character is '^]'. GET / <!DOCTYPE html> <html>...</html> Connection closed by foreign host.

Client request - single ASCII char string terminated by a
single CRLF Server response - ASCII char stream in HTML Connection closed after transfer complete GET method only Metadata? Never heard of that. What is content negotiation?

HTTP/1.0 (RFC 1945, 1996)

㱺 curl -v0 https://twitter.com * Connected to twitter.com port 443
(#0) > GET / HTTP/1.0 > Host: twitter.com > User-Agent: curl/7.43.0 > Accept: */* > < HTTP/1.0 200 OK < content-type: text/html;charset=utf-8 < pragma: no-cache < <!DOCTYPE html> <html>...</html> * Closing connection 0

Request may have newline separated headers Request includes HTTP version
Connection closed after transfer complete And lots of other goodies... Response has its own newline separated headers Not limited to hypertext

Operating with idealized values Real life networks are messy.

TCP-30ms SYN 0ms SYN ACK 15ms 45ms 35ms response 80ms
HTTP-65ms close connection 95ms GET / 30ms ACK

twitter.com homepage over HTTP/1.0 21 requests ~2s 1,995ms =>

modern average page over HTTP/1.0 100 requests 9.5s exactly that
just in ms =>

TCP-30ms TLS-60ms 30ms SYN 0ms SYN ACK 15ms ACK ClientHello
45ms ServerHello Certificate ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished 60ms 75ms ChangeCipherSpec Finished Application data 90ms

TCP-30ms 30ms SYN 0ms SYN ACK 15ms ACK ClientHello 45ms
ServerHello ChangeCipherSpec Finished 60ms ChangeCipherSpec Finished Application data Application data TLS-30ms

21 requests ~2.7s 2,655ms => twitter.com homepage over HTTP/1.0 with
TLS handshake for first connection and TLS session resumption for all consequent requests

100 requests 12.5s => 12,530ms with TLS handshake for first
connection and TLS session resumption for all consequent requests modern average page over HTTP/1.0

HTTP/1.1 (RFC 2068, 1997 & RFC 2616, 1999)

㱺 curl -v https://github.com > GET / HTTP/1.1 > Host:
github.com > User-Agent: curl/7.43.0 > Accept: */* > < HTTP/1.1 200 OK < Transfer-Encoding: chunked < Cache-Control: no-cache < { [1370 bytes data] * Connection #0 to host github.com left intact

㱺 curl -v -H "Range: bytes=0-1024” https://assets-cdn.github.com/../Octocat.png < HTTP/1.1 206
Partial Content < Cache-Control: max-age=31536000, public < Age: 2165764 < Content-Type: image/png < Content-Range: bytes 0-1024/35407 < Content-Length: 1025 < Connection: keep-alive < { [1025 bytes data] * Connection #0 to host left intact

Keepalive connections Better caching mechanism Pipelining Cookies spec Compression, chunked
responses & byte ranges 24 new status codes

TCP-30ms GET /js 95ms 20ms 110ms JS response 130ms HTTP
SYN 0ms SYN ACK 15ms 30ms ACK 45ms 35ms HTML response 80ms GET /

21 requests ~1.5s 1,425ms => Single connection with a TLS
handshake twitter.com homepage over HTTP/1.1

100 requests 6.5s => 6,560ms modern average page over HTTP/1.1
Single connection with a TLS handshake

~50% increase in speed for secure requests

simultaneous connections per domain 6 number can vary per browser

simultaneous connections per domain 6 priority

GET /js 95ms 20ms 110ms JS response 130ms SYN 0ms
SYN ACK 15ms 30ms ACK 45ms 35ms HTML response 80ms GET /

45ms 35ms 20ms JS response HTML response 80ms SYN 0ms
SYN ACK 15ms ACK 30ms GET /js GET /

from 200B to 2KB averaging to 700-800B HTTP headers no
compression

// webpack.config.js module.exports = { entry: ['./one.js', './two.js'], output: {
filename: 'bundle.js' }, plugins: [ new webpack.optimize.UglifyJsPlugin(), ] };

.nav-sprite { background-image: url(https://example.com/sprites.png); background-repeat: no-repeat; } #nav-logo { width:
97px; height: 29px; background-position: -10px -51px; }

HTTP/2 (drafts & RFC 7540, 2015 & ongoing work)

Binary framing layer Request and response multiplexing Header compression Server
push Single connection per origin Flow control

PUT /books/123/ HTTP/1.1 Host: www.example.com Content-Type: application/json Content-Length: 35 {“author”:
“George Orwell”} HTTP/1.1 HEADERS frame HTTP/2 DATA frame SETTINGS frame PING frame GOAWAY frame ...

Multiplexing

stream 1 stream 2 Request message Response message HEADERS frame
DATA frame HEADERS frame

Stream prioritization Each stream may another stream and be dependent
on between 1 and 256 have a weight Flow control Each receiver can set entire connection for each stream or desired window size

GET /index.html stream 1 stream 1 Response stream 2 PUSH_PROMISE
/script.js stream 3 PUSH_PROMISE /style.css 2 3 1

HPACK (RFC 7541, 2015)

61 commonly used HTTP headers Static Table Dynamic Table Static
Huffman Encoding + initially empty, consists of headers headers not yet indexed, are encoded using a code statistically obtained on a large sample of HTTP headers

+------------------------------------+ | :method| GET | +------------------------------------+ | :scheme| https |
+------------------------------------+ | :host| www.example.com | +------------------------------------+ | :path| / | +------------------------------------+ | :accept| */* | +------------------------------------+ | :user-agent| Mozilla/5.0... | +------------------------------------+ | :cookie| ... | +------------------------------------+ | :x-requested-with| XMLHttpRequest | +------------------------------------+ Request #1

+------------------------------------+ | :host| www.example.com | +------------------------------------+ | :path| / | +------------------------------------+ | :accept| */* | +------------------------------------+ | :user-agent| Mozilla/5.0... | +------------------------------------+ | :cookie| ... | +------------------------------------+ | :x-requested-with| XMLHttpRequest | +------------------------------------+ Request #1 with HPACK 1byte 1byte 1byte++ 1byte 1byte++ 1byte++ 1byte++ +++

+------------------------------------+ | | | +------------------------------------+ | | | +------------------------------------+ |
| www.example.com | +------------------------------------+ | | | +------------------------------------+ | | */* | +------------------------------------+ | | Mozilla/5.0... | +------------------------------------+ | | ... | +------------------------------------+ | :x-requested-with| XMLHttpRequest | +------------------------------------+ Request #1 with HPACK Encoded with a static Huffman code

+------------------------------------+ | | | +------------------------------------+ | | | +------------------------------------+ |
:host| www.example.com | +------------------------------------+ | | | +------------------------------------+ | :accept| */* | +------------------------------------+ | :user-agent| Mozilla/5.0... | +------------------------------------+ | :cookie| ... | +------------------------------------+ | :x-requested-with| XMLHttpRequest | +------------------------------------+ Request #1 with HPACK Saved in the dynamic table

~30-80% compression ratio of headers with HPACK

6 connections per origin image sprites naive concatenation of assets
inlining of resources ✖ * ✖ * domain sharding ✖

smart caching compress assets reduce header bytes ﬁne-tuned TCP stack
use CDNs eliminate unnecessary resources ✔ ✔ ✔ ✔ ✔ ✔

Median loadEvent (ms) 0 1250 2500 3750 5000 RTT (latency)
0 100 200 300 400 500 H1 H2 Impact of latency and HTTP/2 at ft.com Chart replicated based on statistics taken from next.ft.com, March 2016

70% 30% HTTP/2 HTTP/1.1 Traffic stats Feb 2017 from Mozilla
40% 60% 88% 12% All traffic HTTPS traffic only Top 10M websites

Percentile 0 25 50 75 100 Document complete time (onload)
(ms) 2140 2150 2160 2200 2225 2240 2250 2260 2265 2300 2310 2340 2390 2450 H1 H2 Test with 0.0% PLR by fastly Browser: Firefox; 5000/1000 KBPS; 40ms latency, 0.0%PLR

Percentile 0 25 50 75 100 Document complete time (onload)
(ms) 2300 2500 2800 2900 3000 3600 5000 5600 5700 7000 8300 H1 H2 Test with 2.0% PLR by fastly Browser: Firefox; 5000/1000 KBPS; 40ms latency, 2.0%PLR

QUIC (experimental transport layer over UDP)

Great book!1 much wow so network latency bad :(

Thank you...

[NDC London] HTTP: History & Performance

[NDC London] HTTP: History & Performance

More Decks by Ana Balica

Other Decks in Programming

Featured

Transcript