Post on 15-Apr-2017
Cleaning Up the Dirt of the Nineties
How New Protocols areModernizing the Web
Steffen Gebert(with help from Thomas Zinner and Benedikt Pfaff)
Photos:
Agenda
What happened…and is still happening
HTTP/2A small step for the Web
QUICGetting rid of TCP
Multipath TCPOne path is not enough
Siri: “Sometimes, we talk via MPTCP”
About Me
PhD Student Comm. Networkssince 2011
Contributor2008 – 2010
Core Team2010 - 2013
Server Admin Teamsince 2011
Visiting Researcher10/2011 – 01/2012
ISO/OSI Model vs. TCP/IP Model
Physical
Data Link
Network
Transport
Session
Presentation
Application
Host-to-Network
Internet
Transport
Application
Ethernet / xG
IPv4 / IPv6
TCP
HTTP
Transmission Control Protocol (TCP)
Host-to-Network
Internet
Transport
Application
Ethernet / xG
IPv4 / IPv6
TCP
HTTP
☑ Connection-oriented Transmission☑ Segmentation☑ Flow Control☑ Congestion Control☑ Reliable Transport
HTTP/2 QUIC MPTCPHTTP/1
*HTTP
Map of Protocols (of this talk)
Host-to-Network
Internet
Transport
Application
IPv4 / IPv6
Ethernet, xG
TCP
TLS
UDP TCPMPTCP
QUIC
SPDY
HTTP/0.9 (1991)
• One-lineprotocol• OnewebsiteperIP
$ telnet example.com 80GET /index.html
<html><head>…
HTTP/1
HTTP
IP
TCP
TLS
HTTP/1.0 (1996)
• Header (Content-Type, Set-Cookie, etc.)• Status codes (200, 404, ..)• Virtual Hosts
• Server tears down connectionafter last byte (no keep-alive)
Connection Setup
TCP+TLS
SYN
SYNACK
ServerHelloCertificate
ChangeCipherSpec
ACK
ClientHelloClientKeyExchange
ChangeCipherSpec
GET / HTTP/1.1
HTTP/1.1 (1997)• Keep-alive: persistent TCP connection
• Chunked Transfer: Response size doesn’t need be known a priori• Byte Range Requests: Requesting parts of a file
• Content-Encoding: Gzip compression• Cache-Handling
HTTP/1.1 (1997)• Keep-alive: persistent TCP connection
• Chunked Transfer: Response size doesn’t need be known a priori• Byte Range Requests: Requesting parts of a file
• Content-Encoding: Gzip compression• Cache-Handling
• Pipelining
Binary Framing Layer
• HTTP/2 isn‘t plain-text protocol
• Header and payload transferred independet• Binary encoding is transparent for upper layers
• Request/response semantics still exist
39
HTTP/2
TLS
IP
TCP
SPDY
HTTP
Streams•Oneperrequest/responsepair•Prioritiesforeachrequest•Prioritycanbechangedon-the-fly
Frames•HEADERS,DATA,PRIORITY•RST_STREAM,END_STREAM•PING,SETTINGS,WINDOW_UPDATE
GET /web/de/startseite/startseiteHost: www.example.comConnection: keep-aliveCache-Control: max-age=0Accept: text/html,application/application/xml;q=0.9,image/webpUpgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36DNT: 1Accept-Encoding: gzip, deflate, Accept-Language: en-US,en;q=0.8,de;q=0.6Cookie: DCITY=10.252.143.135.1460643850490027; JSESSIONID=0000rpB0IxIdB3V82nn9QiyGZoq:18hscq3v5; NETMIND_PERMSID=50f92660aa-81644881aa5e01d0c9aa-1460643849; NETMIND_SID=6e43607baaa590f201aa-c3bb2012aa-e48932f0aaIf-None-Match: "NETMIND:6e43607baac3bb2012aa-e48932f0aa-1460737470”If-Modified-Since: Fri, 15 Apr 2016 16:24:30 GMT
HTTP/1.1 200 OKDate: Fri, 15 Apr 2016 16:24:51 GMTServer: ApacheX-Powered-By: Servlet/3.0Vary: Accept-EncodingContent-Type: text/htmlContent-Language: en-USExpires: Fri, 15 Apr 2016 16:24:51 GMTLast-Modified: Fri, 15 Apr 2016 16:24:51 GMTNetMindSessionID: 6e43607baa-a590f201aac3bb2012aa-e48932f0aaETag: "NETMIND:6e43607baa-a590f201aae48932f0aa-1460737491”Set-cookie: NETMIND_PERMSID=50f92660aa81644881aa-a898c907aa-5e01d0c9aaDomain=.datev.de; Path=/ ; Expires=Thu, 14 Jul 2016 16:24:51 GMTSet-cookie: NETMIND_SID=6e43607baac3bb2012aa-e48932f0aa-1460737491; Domain=.datev.de; Path=/Content-Length: 19485Keep-Alive: timeout=5, max=100Connection: Keep-Alive
Header Compression (HPACK)
43
• Compression of HTTP headers to reduce overhead
• Client and server store (identical) compression tables• Static table: Frequently used, standardized headers• Dynamic table: Connection-specific fields
• Previously used headers are only referenced
Request Headers Static Table Encoded Headers
Dynamic Table
Server Push• Servercan answer one request with additionalresponses
• Servercan managethe client‘s cache• Pushresources,invalidate resource,increase TTL
• Requires server-side knowledgeof webapplication
• No overlap with Server-Sent Events/WebSockets• Statenotknown to the webapplication (akaJavaScript)
45
Link: “</css/site.css>;rel=preload“Link: "</images/logo.jpg>;rel=preload“
Bye bye, TCP!
Host-to-Network
Internet
Transport
Application
Ethernet / xG
IPv4 / IPv6
TCP
HTTP
☑ Connection-orientedTransmission
☑ Segmentation☑ Flow Control☑ Congestion Control☑ Reliable Transportx
QUIC
QUIC
IP
UDP
SPDY
HTTP
Connection Setup
TCP+TLS
SYN
SYNACK
ServerHelloCertificate
ChangeCipherSpec
ACK
ClientHelloClientKeyExchange
ChangeCipherSpec
GET / HTTP/1.1
Congestion Control
58
• Similar to TCP Cubic• ACK includes NACK• Retransmissions have
sequence numbers• More precise RTT
estimation
¿Hablas QUIC?• How does client now about availability of QUIC?• Alternate Service Header inform HTTP clients about QUIC service
QUIC Status
• Currently, only Google knows• Currently, only Google uses it• Open Source QUIC server (Chromium) outdated• No reliable information about efficiency
Advantages
• Increased throughput thanksto load balancing
• Resilience throughusage of alternativepath
• Moreflexibility:Simultaneousconnection viamultiplemedia (e.g.WiFi,xG)
Src Dst
Graphics by Olivier Bonaventure
Multipath TCP (MPTCP)
Host-to-Network
Internet
Transport
Application
Ethernet
IPv4 / IPv6
TCP
HTTP, IMAP
MPTCP
IP
TCPMPTCP
HTTP
Resource Pooling
Collection of resources behave as it were one combined resource.
Graphics by Olivier Bonaventure
Requirements• Load balacing: prefer
uncongested paths
• Resource Pooling
• Fairness• TCP vs. MPTCP • MPTCP vs. TCP• MPTCP vs. MPTCP
• Stability
Graphics by Olivier Bonaventure
Coupling of Subflows
u Fully uncoupled
§ Bad load balacning§ No resource pooling
u Fully coupled
§ Good load balancing§ Resource pooling
Han, Towsley et al:Fully coupled works well(fluid models)
Fully coupledsubflows
Uncoupledsubflows
Degree of coupling
Reality:Does not work in practice(capture effect)
RTT Compensation
• RTT Compensation: Respect RTTs when computing receive window(be more aggressive on higher RTT path)
RTT CompensationBase line
Option2: Apple is Boring(use MPTCP only for failover)
MobileBackup connection
MobileBackup connection
WiFiPrimary connection
WiFiPrimary connection
Conclusion
HTTP/2 was overdueVery good browser support, good server supportFully backwards-compatbileNew features (priorities, server push) to be exploited
Successor (?) QUIC under developmentUDP instead of TCPAllows handover between different connectionsLittle known about actual benefits
Multipath TCPUses multiple paths for load balancing and resilienceWell-engineered protocol to achieve fairness criteria No public, large-scale deployment yet