Evolving HTTP and making things QUIC
•
0 likes•95 views
This document summarizes Natasha Rooney's presentation on QUIC and the evolution of HTTP. Some key points include: - QUIC aims to improve performance over TCP by eliminating head-of-line blocking and reducing latency through 0-RTT connections. - It achieves this by multiplexing streams over a UDP connection and integrating TLS 1.3 for encryption to provide security. - Early results show QUIC reducing page load times by 15-18% for video and 3.6-8% for search queries on Google's services. - As QUIC becomes more widely adopted, it may continue to improve performance for a "long tail" of users on slower or more unreliable networks.
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Evolving HTTP and making things QUIC
Similar to Evolving HTTP and making things QUIC (20)
More from Natasha Rooney
More from Natasha Rooney (10)
Recently uploaded
Recently uploaded (20)
Evolving HTTP and making things QUIC
- 1. @thisNatasha Down the Line: evolving HTTP and making things QUIC Natasha Rooney on version negotiation, end-point capabilties, and successful TLS handshake.”
- 4. @thisNatasha Protocols: a set of instructions
- 5. @thisNatasha
- 12. @thisNatasha Only one way! And as the crow flies...
- 16. @thisNatasha Mobile Network (not wifi) The Internet
- 17. @thisNatasha@thisNatasha Distance Capped by Speed of Light
- 18. @thisNatasha
- 19. @thisNatasha
- 20. @thisNatasha
- 21. @thisNatasha@thisNatasha Distance Capped by Speed of Light Amount of Data >100 objects per page 800k to 2.5mb data >50 resources on same domain
- 27. @thisNatasha
- 28. @thisNatasha
- 33. @thisNatasha
- 34. @thisNatasha
- 39. @thisNatasha HTTP/1 TLS TCP IP HTTP/1 TLS TCP TCP Setup TLS Setup HTTP Request/Response
- 40. @thisNatasha
- 41. @thisNatasha Wasting bytes, wasting time. TCP setup, HTTP and TCP headers, waiting on HTTP response before sending again, not fit for today’s internet!
- 46. @thisNatasha@thisNatasha SPDY A Protocol by Google 2009 Header Compression Parallel Connections Multiplexing Priority Marking Server Push TLS (to work)
- 47. @thisNatasha
- 48. @thisNatasha
- 49. @thisNatasha
- 50. @thisNatasha
- 52. @thisNatasha “Idea was to maintain HTTP semantics but change how it is transported.” Daniel Stenberg https://daniel.haxx.se/blog/
- 55. @thisNatasha@thisNatasha HTTP2 A Protocol by IETF (SDPY base) Binary Header Compression Multiplexing Server Push TLS...
- 56. @thisNatasha@thisNatasha HTTP2 A Protocol by IETF (SDPY base)
- 57. @thisNatasha
- 58. @thisNatasha@thisNatasha Stats Gimme gimme 35% Requests 70% HTTPS Connections 13% Top 1,000,000 Sites 29% Top 1000 Sites “90% your site”
- 59. @thisNatasha 2% packet loss HTTP1 is better.
- 60. @thisNatasha Mobile Network (not wifi) The Internet
- 61. @thisNatasha Head of Line Blocking Problem for HTTP and TCP
- 63. @thisNatasha TCP: In order, reliable protocol. Image Source: http://ariecazz.blogspot.com/2015/02/protokol-tcp-dan-udp.html
- 70. @thisNatasha 3
- 73. @thisNatasha “We want QUIC to work on today’s internet” Jana Iyengar QUIC Editor, Fastly
- 76. @thisNatasha
- 77. @thisNatasha@thisNatasha TCP Suffers from Head of Line Blocking UDP Can work...with help. Transport Layer
- 78. @thisNatasha TCP: In order, reliable protocol. Image Source: http://ariecazz.blogspot.com/2015/02/protokol-tcp-dan-udp.html
- 79. @thisNatasha UDP is not a transport. UDP is a way to build a transport - it has no function alone.
- 81. @thisNatasha@thisNatasha TCP Suffers from Head of Line Blocking UDP Can work...with help. Transport Layer
- 83. @thisNatasha@thisNatasha QUIC A Protocol by Google Goo
- 84. @thisNatasha HTTP/2 TLS 1.2+ TCP IP HTTP over QUIC QUIC UDP TLS 1.3
- 86. @thisNatasha HTTP/2 QUIC TLS 1.3 HTTP/2 QUIC TLS 1.3 TCP Connection UDP Connection
- 87. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3
- 88. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3
- 89. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3
- 90. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3 Head of Line Blocking! Multiplexing! ✓
- 91. @thisNatasha Connection establishment. Lots of RTTs. Especially when we encrypt.
- 92. @thisNatasha Round Trips are Evil Killer for Connection Establishment
- 94. @thisNatasha HTTP/1 TLS TCP IP HTTP/1 TLS TCP TCP Setup TLS Setup HTTP Request/Response
- 95. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3 0RTT: Setup + Data 2RTT: If QUIC version negotiation needed 1RTT: New Crypto Keys
- 97. @thisNatasha
- 98. @thisNatasha The Internet can be unreliable. Stuff gets lost. Networks get blocked.
- 100. @thisNatasha ACK Based - Estimate RTT - Retransmit when ACK not received after RTT estimate threshold Timer Based - Aggressive CRYPTO retransmission - Tail Loss Probe - Retransmission timer Loss Detection
- 102. @thisNatasha Slow Start Congestion Avoidance
- 106. @thisNatasha HTTP/2 TLS 1.2+ TCP IP HTTP over QUIC QUIC UDP TLS 1.3
- 108. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3 0RTT: Setup + Data 2RTT: If QUIC version negotiation needed 1RTT: New Crypto Keys
- 111. @thisNatasha Handshake Flow TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Key Exchange Authentication Algorithm Strength Mode Cipher MAC or PRF TLS/HandshakeCheatSheet Key Exchange Method: creates the pre master secret. Premaster secret is combined with PRF to create master secret RSA, DHE_RSA, ECDHE_RSA, ECDHE_ECDSA Authentication Method: Uses public key crypto and certificates public key together. Once certificate is validated the client can used public key. RSA or ECDSA Certs: X.509, ASN.1 DER encoding. Server Hello, Certificate - Server selects cipher & compression method - Server send certificate - Client authenticates Key Exchange Pre-master secret exchanged between client & server, client validates certificate Master Secret Client & Server can compute Master Secret. MAC Server verifies MAC, returns to client to verify also. Finished Handshake complete. Client Hello Client sends TLS Version, Ciphersuites, Compression methods Ciphers, Standards and Terms Encryption 3DES, AES, ARIA, CAMELLIA, RC4, and SEED [1] Steam: adds MAC [2] Block: adds IV and padding after encryption [3] Encryption (AEAD): encryption and integrity validation, using nonce, no padding, no IV. Master Secret Pre-master secret: combines params to help client and server create master secret. Master Secret: both server and client create this from pre-master secret to symmetrically encrypt Integrity Validation PRF: Pseudorandom Function. Takes a secret, a seed, and a unique label. TLS1.2 suites use PRF based on HMAC and SHA256 MAC: used for integrity validation in handshake and record.
- 112. @thisNatasha QUIC: encrypt everything possible. Security & Ossification
- 113. @thisNatasha Traffic Amplification Address validation with byte limitation Spoofing Path validation during connection migration Passive Observation Changing Connection IDs. Encryption. Limited data till sure of encryption and valid path. Denial of Service Authentication through encrypted handshake Stream Commitment Active streams is limited by the concurrent stream limit transport parameter. Explicit Congestion Notification Attacks Ignore duplicate ECN packets Downgrade Three fields that encode version information, included in TLS handshake also. Packet Reflection Authenticate source address, strictly limiting UDP datagrams in first flight Attack Mitigation
- 115. @thisNatasha
- 116. @thisNatasha
- 117. @thisNatasha
- 118. @thisNatasha 7% Internet Traffic 35% Google Egress Traffic
- 119. @thisNatasha
- 120. @thisNatasha
- 121. @thisNatasha Video Rebuffers 15 - 18%
- 122. @thisNatasha Search Latency 3.6 - 8%
- 124. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3 0RTT: Setup + Data 2RTT: If QUIC version negotiation needed 1RTT: New Crypto Keys
- 126. @thisNatasha
- 127. @thisNatasha
- 129. @thisNatasha
- 130. @thisNatasha@thisNatasha Quic What’s next? Standardised this week? Spin bit DNS over QUIC WebRTC over QUIC
- 131. @thisNatasha How does this affect me?
- 132. @thisNatasha Abstraction Is a computer scientist’s friend / fiend
- 136. @thisNatasha@thisNatasha Some things If you have to do something... Manage your resources logically Detect on upgrade header and adapt Measure Remember Physics!
- 137. @thisNatasha Thank-you People: Martin Thomson, Mark Nottingham, Jana Iyengar, Mike Bishop, Eric Rescola, Ian Swett
- 139. @thisNatasha
- 140. @thisNatasha
- 141. @thisNatasha 7. Application Data HTTP / IMAP 6. Data Presentation, Encryption SSL / TLS 5. Session and connection management - 4. Transport of packets and streams TCP / UDP 3. Routing and delivery of datagrams on the Network IP / IPSec 2. Local Data Connection Ethernet 1. Physical data connection (cables) CAT5 OSI Model
- 142. @thisNatasha Handshake Flow TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Key Exchange Authentication Algorithm Strength Mode Cipher MAC or PRF TLS/HandshakeCheatSheet Key Exchange Method: creates the pre master secret. Premaster secret is combined with PRF to create master secret RSA, DHE_RSA, ECDHE_RSA, ECDHE_ECDSA Authentication Method: Uses public key crypto and certificates public key together. Once certificate is validated the client can used public key. RSA or ECDSA Certs: X.509, ASN.1 DER encoding. Server Hello, Certificate - Server selects cipher & compression method - Server send certificate - Client authenticates Key Exchange Pre-master secret exchanged between client & server, client validates certificate Master Secret Client & Server can compute Master Secret. MAC Server verifies MAC, returns to client to verify also. Finished Handshake complete. Client Hello Client sends TLS Version, Ciphersuites, Compression methods Ciphers, Standards and Terms Encryption 3DES, AES, ARIA, CAMELLIA, RC4, and SEED [1] Steam: adds MAC [2] Block: adds IV and padding after encryption [3] Encryption (AEAD): encryption and integrity validation, using nonce, no padding, no IV. Master Secret Pre-master secret: combines params to help client and server create master secret. Master Secret: both server and client create this from pre-master secret to symmetrically encrypt Integrity Validation PRF: Pseudorandom Function. Takes a secret, a seed, and a unique label. TLS1.2 suites use PRF based on HMAC and SHA256 MAC: used for integrity validation in handshake and record.
- 143. @thisNatasha [1] Client Hello Cli-ant Ser-ver Server Hello [2] Certificate [3] Server Key Exchange [4] Server Hello Done [5] [6] Client Key Exchange [7] (Change Cipher Spec) [8] Finished (Change Cipher Spec) [9] Finished [10] TLS Handshake
- 144. @thisNatasha Cli-ant Ser-ver TCP and TLS with Session Tickets TCP Fast Open Handshake [1] Client Hello Server Hello [2] (Change Cipher Spec) [3] Finished [4] [5] (Change Cipher Spec) [6] Finished
- 145. @thisNatasha TLS Encryption Levels ● CRYPTO frames MAY appear in packets of any encryption level except 0-RTT. ● CONNECTION_CLOSE MAY appear in packets of any encryption level other than 0-RTT. ● APPLICATION_CLOSE MAY appear in packets of any encryption level other than Initial and 0-RTT. ● PADDING frames MAY appear in packets of any encryption level. ● ACK frames MAY appear in packets of any encryption level other than 0-RTT, but can only acknowledge packets which appeared in that packet number space. ● STREAM frames MUST ONLY appear in the 0-RTT and 1-RTT levels. ● All other frame types MUST only appear at the 1-RTT levels.
- 146. @thisNatasha Cryptographic handshake ● authenticated key exchange, where ○ a server is always authenticated, ○ a client is optionally authenticated, ○ every connection produces distinct and unrelated keys, ○ keying material is usable for packet protection for both 0-RTT and 1-RTT packets, and ○ 1-RTT keys have forward secrecy ● ● authenticated values for the transport parameters of the peer (see Section 7.3) ● authenticated confirmation of version negotiation (see Section 7.3.3) ● authenticated negotiation of an application protocol (TLS uses ALPN [RFC7301]for this purpose)
- 148. @thisNatasha