Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cleaning Up the Dirt of the Nineties - How New Protocols are Modernizing the Web

775 views

Published on

About HTTP/2, QUIC, and Multipath TCP.

Download of PDF file recommended (Slideshare screws backgrounds up)

Talk at the TYPO3camp Vienna
Vienna, Austria, 06.-08.05.2016

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Cleaning Up the Dirt of the Nineties - How New Protocols are Modernizing the Web

  1. 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. 2. Thanks to our Sponsors
  3. 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. 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
  5. 5. Growth of the Web
  6. 6. Influence Factors on Page Load Time
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. Beginnings of HTTP: Simplicity
  11. 11. 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
  12. 12. 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)
  13. 13. 1Connection per ressource
  14. 14. Connection Setup TCP+TLS SYN SYN ACK ServerHello Certificate ChangeCipher Spec ACK ClientHello ClientKey Exchange ChangeCipher Spec GET / HTTP/1.1
  15. 15. 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
  16. 16. Serial, in-order transmission
  17. 17. 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
  18. 18. HEAD OF LINE BLOCKING
  19. 19. Up to 6 conns. per origin
  20. 20. Overhead vs. Payload
  21. 21. More connections? Domain Sharding
  22. 22. Minimize # of Requests: Concatenation & Sprites + =
  23. 23. Quelle: Patrick McManus, Mozilla 74% of all HTTP/1.x connections transfer1object
  24. 24. HTTP/2
  25. 25. 11/2009 Google SPDY 03/2012 Call for Proposals 05/2015 RFCs 7540/7541
  26. 26. SPEED what else?!
  27. 27. Clean Up all the hacks
  28. 28. 1TCP connection Manystreams
  29. 29. 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
  30. 30. Streams •One per request/response pair •Priorities for each request •Priority can be changed on-the-fly Frames •HEADERS, DATA, PRIORITY •RST_STREAM, END_STREAM •PING, SETTINGS, WINDOW_UPDATE
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. Let’s go! •HTTP/2 is fully backwards compatible •No changes needed in web application
  35. 35. 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“
  36. 36. QUIC Getting rid of TCP using Quick UDP Internet Connections
  37. 37. 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
  38. 38. HEAD OF LINE BLOCKING
  39. 39. Slow Connection Setup?
  40. 40. Connection Setup TCP+TLS SYN SYN ACK ServerHello Certificate ChangeCipher Spec ACK ClientHello ClientKey Exchange ChangeCipher Spec GET / HTTP/1.1
  41. 41. ØRTT Connection Setup
  42. 42. Ø RTT (Connection Setup) you say? First Connection Subsequent Conns.
  43. 43. Packet Loss •TCP: Ale Streams blocked à Head-of-line blocking •UDP: Only directly affected stream is blocked
  44. 44. Congestion Control 58 • Similar to TCP Cubic • ACK includes NACK • Retransmissions have sequence numbers • More precise RTT estimation
  45. 45. Forward Error Correction 61 • Lost packet content can be restored • Sender decides about FEC usage
  46. 46. Connection Migration 62 QUIC Connection ID (64 bit) HTTP Source IP Source Port Dest. IP Dest. Port
  47. 47. ¿Hablas QUIC? • How does client now about availability of QUIC? • Alternate Service Header inform HTTP clients about QUIC service
  48. 48. QUIC Status • Currently, only Google knows • Currently, only Google uses it • Open Source QUIC server (Chromium) outdated • No reliable information about efficiency
  49. 49. MULTIPATH TCP All paths lead to Rome
  50. 50. 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
  51. 51. Multipath TCP (MPTCP) Host-to-Network Internet Transport Application Ethernet IPv4 / IPv6 TCP HTTP, IMAP MPTCP IP TCP MPTCP HTTP
  52. 52. Resource Pooling Collection of resources behave as it were one combined resource. Graphics byOlivier Bonaventure
  53. 53. Requirements • Load balacing: prefer uncongested paths • Resource Pooling • Fairness • TCP vs. MPTCP • MPTCP vs. TCP • MPTCP vs. MPTCP • Stability Graphics byOlivier Bonaventure
  54. 54. 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)
  55. 55. RTT Compensation • RTT Compensation: Respect RTTs when computing receive window (be more aggressive on higher RTT path) RTT CompensationBase line
  56. 56. “One” “But.. why?” “Siri, on how many paths did my packets travel?”
  57. 57. Option 1: Jaunty Firewalls Application/Session Presentation Transport TCP Options MP_CAPABLE MP_JOIN
  58. 58. Option2: Apple is Boring (use MPTCP only for failover) Mobile Backup connection Mobile Backup connection WiFi Primary connection WiFi Primary connection
  59. 59. 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

×