Serial, non-persistent connections

(1)

HTTP/2

(2)

Serial, non-persistent connections



HTTP/1.0



One request/response per connection

 simple to implement

 server parses request, responds, and closes connection



RTT = round-trip time

total = 2RTT+transmit time

Portland State University CS 430P/530 Internet, Web & Cloud Systems

time to transmit file

initiate TCP connection

RTT request file

RTT

file received

time time

(3)

Serial, non-persistent connections

Client

Server

SYN SYN

ACK ACK

ACK

DAT DAT

DAT

DAT FIN ACK 0 RTT

1 RTT

2 RTT

3 RTT

4 RTT

Server reads from disk

FIN

Server reads from disk Client opens TCP connection

Client sends HTTP request for HTML

Client parses HTML

Client opens TCP connection

Client sends HTTP request for image

Image begins to arrive

Then delivers HTML before closing the connection

(4)

Issue



Multiple embedded objects on page

 Connection setup latency adds extra round trips per transfer (e.g. TCP’s three-way handshake)

 Server and network overhead

 Connection handling, extra packets

 Short transfers hard on TCP

 (e.g. slow-start, loss recovery algorithm)

(5)

Parallel non-persistent connections



Netscape browser (1990s)



Improve latency by using multiple concurrent connections

 Browser opens up to 6-8 parallel TCP connections to fetch referenced objects

 Different parts of Web page arrive independently on separate connections (object demux via connections)

 Can grab more of the network bandwidth than other users



Doesn’t improve response time all the time

 TCP connections contending with each other causing more packet losses and delay

 OS overhead for each TCP connection

(6)

Persistent HTTP connections



Default in HTTP/1.1

 Server leaves connection open after sending response

 Client sends additional requests on the same connection as soon as it encounters a referenced object

 Subsequent HTTP messages between same client/server sent over open connection

 On same TCP connection: server parses request, responds, parses new request, etc..

 As little as one RTT for all the referenced objects

(7)

Persistent HTTP benefits



Server overhead reduced

 Less connection setup, more data transfer



TCP congestion control behavior improved

 Longer connections with larger congestion windows



Response time improved

 Avoids multiple, serial TCP handshakes



New HTTP request header for controlling

 Connection: keep-alive

 Connection: close

(8)

Persistent HTTP connection example

Client

Server

ACK

DAT DAT

ACK 0 RTT

1 RTT

2 RTT

Server reads from disk Client sends HTTP request for HTML

Client parses HTML

Client sends HTTP request for image

Image begins to arrive

DAT

Server reads from disk

DAT

Client

(9)

HTTP example



Non-persistent HTTP/1.0

mashimaro <~> 9:11AM % nc -C chi-ni.com 80 GET / HTTP/1.0

Host: chi-ni.com HTTP/1.0 200 OK

…

Connection: close

Content-Type: text/html

<HTML>

<HEAD>

<TITLE>Jeannie's Web Site</TITLE>

</HEAD>

<BODY>

<IMG SRC="./2007_06_11-09_31_40.jpg">

</BODY>

</HTML>

mashimaro <~> 9:21AM %

(10)



Persistent HTTP/1.1

mashimaro <~> 9:20AM % nc -C chi-ni.com 80 GET / HTTP/1.1

Host: chi-ni.com

Connection: keep-alive HTTP/1.1 200 OK

…

Keep-Alive: timeout=5, max=100 Connection: Keep-Alive

Content-Type: text/html

<HTML>

<HEAD>

<TITLE>Jeannie's Web Site</TITLE>

</HEAD>

<BODY>

<IMG SRC="./2007_06_11-09_31_40.jpg">

</BODY>

</HTML>

GET /2007_06_11-09_31_40.jpg HTTP/1.1 Host: chi-ni.com

Connection: close HTTP/1.1 200 OK Content-Length: 539 Connection: close

Content-Type: image/jpeg

��JFIFHH��C

…

mashimaro <~> 9:20AM %

(11)

Problems with HTTP/1.1



Serial delivery of objects

 Head-of-line object blocking

 Stall in one object prevents delivery of others



Most useful information in first few bytes (layout info)

 Multiple connections allow incremental rendering of images

 Image courtesy of Cloudflare

(12)

HTTP operation



Want the best of both worlds

 Persistence

 Single TCP connection

 Parallel object delivery

 Ability to simultaneously retrieve embedded objects over connection



Need application/object level demux within a single TCP connection to emulate multiple connections



Leads us to SPDY (2009) and HTTP/2, then QUIC and HTTP/3

(13)

HTTP/2



Two main improvements

 Multiplexed streams

 Server-push

(14)

HTTP/2 multiplexed streams

 HTTP/1.1

• Pipelined, sequential operation on each connection

• Must use multiple connections to get parallel delivery of

objects

• Typically, 4-8 outstanding requests on 4-8 connections

• Still resource intensive on the server

 HTTP/2

• One connection, many

pipelined, concurrent requests

• Normally limited to 100

Client Server Client Server

HTTP/1.1

Sequential HTTP/2

Multiplexed

(15)

HTTP/2 multiplexed streams

 How?

 HTTP stream identifiers combined with range requests/responses

 Implemented as a framing protocol within HTTP

 Server labels data with the object it is for and the range of bytes within it

 Application-layer demultiplexing of object data

 Allows one to support pipelining but avoid HOL blocking

 Application specific solution to transport protocol problem.

(16)

Demo

 HTTP/1

 Handshaking overhead, multiple RTT to request individual tiles

 Exacerbated with lossy/wireless links and long RTTs

 Poor congestion control behavior

 HTTP/2

 One handshake, one batch of requests to make (tiles requested in a single RTT)

 Multiplexed data returned that is resilient to loss and long RTTs

 Better congestion control behavior

 No longer necessary to package objects into a single file for efficient transmission

 Test support in browser

 http://http2.golang.org/

 Demo

 http://http2.golang.org/gophertiles

(17)

HTTP/2 server push



HTTP/1.1

 Client fetches origin page

 Must parse base page for embedded objects before

submitting subsequent requests for them

 Server often knows what client will request next

RTT

parse and request embedded objects

request file

time time

send file

HTTP/1.1

(18)

HTTP/2 server push



Support for server to push content to client

 Preload content directly into browser cache so subsequent loads hit

 Especially useful for single- page applications

RTT

RTT request file

push

embedded objects

time time

send file

HTTP/2

(19)

Issues with HTTP/2



Initial connection setup

 Multiple round-trips required for a single transfer still

 TCP handshake

 TLS handshake

 HTTP request/response



TCP congestion control still a bottleneck



No support for error correction for lossy wireless links



TCP connection bound to IP address

 Instead of browser session

 Session lost upon migration from WiFi to cellular



Motivates Google's QUIC

(20)

QUIC (now HTTP/3)

(21)

QUIC



Quick UDP Internet Connections

 Google's rewrite of web protocols to improve performance

 Bypass IETF and standards process via direct implementation on Google web-sites and Chrome



QUIC approach

 A reliable, multiplexed transport over UDP

 Always encrypted

 Reduced RTT times

 Runs in user-space

 Open-source

 Servers: Google Prototype Server / LibQUIC

 Now being standardized as HTTP/3

 https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/

(22)

Why did Google do this?

 Layering great for modularity, but what about performance?

 Layer violation done historically for performance reasons

$BROWSER HTTP/1.1 TLS 1.2 TCP IP

Physical Network

google.com

???

User-perceived latency

Chrome HTTP/2 Launch your

own browser Update HTTP

Google CDN Build a

carrier-grade

network google.com

(23)

From HTTP to QUIC



Congestion control, reliability, encryption, and some HTTP/2 move

to QUIC

(24)

QUIC Features



Collapses the stack and eliminates layering

 A single protocol spanning 3 layers

 HTTP being used as the new carrier protocol for all network apps (the new waistline!)



But supports,

 Multiplexed streams and object-level demultiplexing (e.g. HTTP/2)

 0-RTT connections with encryption (TLS 1.3)

 Reliability over UDP

 Forward error correction to handle lossy wireless links

 Connection migration with IP address change

 Pluggable congestion control (including TCP Cubic, BBR)

(25)

0 Round-Trips: QUIC vs. TCP+TLS

 First connection

 TCP with TLS: TCP + certificate exchange/validation (3 RTTs)

 QUIC: 1RTT for all (TLS 1.3)

 Subsequent connections

 TCP with TLS: Add TLS restart (2 RTT)

 QUIC: 0 RTT for all (TLS 1.3)

(26)

Multiplexed streams: QUIC vs. SPDY/HTTP2

(on packet loss)

HTTP 1.0

QUIC

(27)

QUIC - Connections



UDP with encrypted and authenticated packets

 Prevents active attacks and middlebox changes (NAPT) unlike TCP



Connection UUID (64-bit) to identify connections

 Used instead of TCP/IP 5-tuple

 Connections decoupled from IP addresses to survive going from WiFi to LTE



Congestion control

 Implemented into application layer (i.e. user-space)

 Window remembered by the client for reestablished connections

(28)

Establishing a QUIC Connection



HTTP response header

 Alternate-Protocol: 443:quic



Client establishes QUIC connection in the background



Clients can cache if server supports QUIC to avoid subsequent negotiation

Client Server

QUIC Connetion

HTTP

QUIC

Alternate-Protocol:

(29)

QUIC Performance



5% latency reduction on average



30% reduction in rebuffers (video pauses) on YouTube



1 second faster at the 99th percentile for Google web search



Helps more for higher latency networks

 Example: Cellular/wireless hops

 https://eng.uber.com/employing-quic-protocol/

(30)

Deployment at Google



100% of all Android/Chrome to YouTube traffic



Now about 50-50 QUIC (UDP)/TCP

QUIC HTTP/2, TCP

HTTP 1.1, TCP

(31)

QUIC in Wireshark

(32)



HTTP/3 = QUIC (11/2018)

 https://www.zdnet.com/article/http-over-quic-to-be-renamed- http3/



Now everywhere…(9/2019)

 https://www.zdnet.com/article/cloudflare-google-chrome-and- firefox-add-http3-support/