Cleaning Up the Dirt of the Nineties - How New Protocols are Modernizing the Web
1 like•1,565 views
This document summarizes recent developments in web protocols, including HTTP/2, QUIC, and Multipath TCP (MPTCP). HTTP/2 modernized HTTP by introducing binary framing, multiplexing, header compression and server push. QUIC aims to replace TCP with UDP to reduce latency during connection setup. MPTCP leverages multiple network paths simultaneously for increased throughput and resilience.
Cleaning Up the Dirt of the Nineties - How New Protocols are Modernizing the Web
- 1. Cleaning Up the Dirt of the Nineties How New Protocols are Modernizing the Web Steffen Gebert (with help from Thomas Zinner and Benedikt Pfaff) Photos:
- 2. Thanks to our Sponsors
- 3. Agenda What happened… and is still happening HTTP/2 A small step for the Web QUIC Getting rid of TCP Multipath TCP One path is not enough Siri: “Sometimes, we talk via MPTCP”
- 4. About Me PhD Student Comm. Networks since 2011 Contributor 2008 – 2010 Core Team 2010 - 2013 Server Admin Team since 2011 Visiting Researcher 10/2011 – 01/2012
- 8. Growth of the Web
- 9. Influence Factors on Page Load Time
- 10. 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
- 11. 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
- 12. 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 TCP MPTCP QUIC SPDY
- 14. HTTP/0.9 (1991) • One-line protocol • One web site per IP $ telnet example.com 80 GET /index.html <html><head>… HTTP/1 HTTP IP TCP TLS
- 15. HTTP/1.0 (1996) • Header (Content-Type, Set-Cookie, etc.) • Status codes (200, 404, ..) • Virtual Hosts • Server tears down connection after last byte (no keep-alive)
- 18. HTTP/1.1 (1997) • Keep-alive: persistent TCP connection • Chunked Transfer: Response size doesn’t need be known a priori • Byte Range Requests: Requesting partsof a file • Content-Encoding: Gzip compression • Cache-Handling
- 20. HTTP/1.1 (1997) • Keep-alive: persistent TCP connection • Chunked Transfer: Response size doesn’t need be known a priori • Byte Range Requests: Requesting partsof a file • Content-Encoding: Gzip compression • Cache-Handling • Pipelining
- 22. Up to 6 conns. per origin
- 25. Minimize # of Requests: Concatenation & Sprites + =
- 28. HTTP/2
- 29. 11/2009 Google SPDY 03/2012 Call for Proposals 05/2015 RFCs 7540/7541
- 31. Clean Up all the hacks
- 33. 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
- 35. GET /web/de/startseite/starts Host: www.example.com Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application application/xml;q=0.9,image/w Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Maci X 10_11_3) AppleWebKit/537.36 Chrome/49.0.2623.112 Safari/5 DNT: 1 Accept-Encoding: gzip, deflat Accept-Language: en-US,en;q=0 Cookie: DCITY=10.252.143.135. JSESSIONID=0000rpB0IxIdB3V82n NETMIND_PERMSID=50f92660aa-81 5e01d0c9aa-1460643849; NETMIN a590f201aa-c3bb2012aa-e48932f If-None-Match: "NETMIND:6e436 c3bb2012aa-e48932f0aa-1460737 If-Modified-Since: Fri, 15 Ap
- 36. HTTP/1.1 200 OK Date: Fri, 15 Apr 2016 16:24: Server: Apache X-Powered-By: Servlet/3.0 Vary: Accept-Encoding Content-Type: text/html Content-Language: en-US Expires: Fri, 15 Apr 2016 16: Last-Modified: Fri, 15 Apr 20 NetMindSessionID: 6e43607baa- c3bb2012aa-e48932f0aa ETag: "NETMIND:6e43607baa-a59 e48932f0aa-1460737491” Set-cookie: NETMIND_PERMSID=5 81644881aa-a898c907aa-5e01d0c Domain=.datev.de; Path=/ ; Ex 2016 16:24:51 GMT Set-cookie: NETMIND_SID=6e436 c3bb2012aa-e48932f0aa-1460737 Domain=.datev.de; Path=/ Content-Length: 19485 Keep-Alive: timeout=5, max=10 Connection: Keep-Alive
- 37. 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
- 38. Let’s go! •HTTP/2 is fully backwards compatible •No changes needed in web application
- 39. Server Push • Server can answer one request with additional responses • Server can manage the client‘s cache • Push resources, invalidate resource, increase TTL • Requires server-side knowledgeof web application • No overlap with Server-Sent Events / WebSockets • State not known to the web application(aka JavaScript) 45 Link: “</css/site.css>;rel=preload“ Link: "</images/logo.jpg>;rel=preload“
- 40. QUIC Getting rid of TCP using Quick UDP Internet Connections
- 41. Bye bye, TCP! Host-to-Network Internet Transport Application Ethernet / xG IPv4 / IPv6 TCP HTTP ☑ Connection-oriented Transmission ☑ Segmentation ☑ Flow Control ☑ Congestion Control ☑ Reliable Transportx QUIC QUIC IP UDP SPDY HTTP
- 46. Ø RTT (Connection Setup) you say? First Connection Subsequent Conns.
- 48. Congestion Control 58 • Similar to TCP Cubic • ACK includes NACK • Retransmissions have sequence numbers • More precise RTT estimation
- 49. Forward Error Correction 61 • Lost packet content can be restored • Sender decides about FEC usage
- 50. Connection Migration 62 QUIC Connection ID (64 bit) HTTP Source IP Source Port Dest. IP Dest. Port
- 51. ¿Hablas QUIC? • How does client now about availability of QUIC? • Alternate Service Header inform HTTP clients about QUIC service
- 52. QUIC Status • Currently, only Google knows • Currently, only Google uses it • Open Source QUIC server (Chromium) outdated • No reliable information about efficiency
- 53. MULTIPATH TCP All paths lead to Rome
- 55. Advantages • Increased throughput thanks to load balancing • Resilience through usage of alternative path • More flexibility: Simultaneous connection via multiple media (e.g. WiFi , xG) Src Dst Graphics byOlivier Bonaventure
- 56. Multipath TCP (MPTCP) Host-to-Network Internet Transport Application Ethernet IPv4 / IPv6 TCP HTTP, IMAP MPTCP IP TCP MPTCP HTTP
- 57. Resource Pooling Collection of resources behave as it were one combined resource. Graphics byOlivier Bonaventure
- 58. Requirements • Load balacing: prefer uncongested paths • Resource Pooling • Fairness • TCP vs. MPTCP • MPTCP vs. TCP • MPTCP vs. MPTCP • Stability Graphics byOlivier Bonaventure
- 59. 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) Fullycoupled subflows Uncoupled subflows Degree of coupling Reality: Does not work in practice (capture effect)
- 60. RTT Compensation • RTT Compensation: Respect RTTs when computing receive window (be more aggressive on higher RTT path) RTT CompensationBase line
- 61. “One” “But.. why?” “Siri, on how many paths did my packets travel?”
- 62. Option 1: Jaunty Firewalls Application/Session Presentation Transport TCP Options MP_CAPABLE MP_JOIN
- 63. Option2: Apple is Boring (use MPTCP only for failover) Mobile Backup connection Mobile Backup connection WiFi Primary connection WiFi Primary connection
- 64. Conclusion HTTP/2 was overdue Very good browser support, good server support Fully backwards-compatbile New features (priorities, server push) to be exploited Successor (?) QUIC under development UDP instead of TCP Allows handover between different connections Little known about actual benefits Multipath TCP Uses multiple paths for load balancing and resilience Well-engineered protocol to achieve fairness criteria No public, large-scale deployment yet