Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Get Hands-On with NGINX and QUIC+HTTP/3
Similar to Get Hands-On with NGINX and QUIC+HTTP/3 (20)
More from NGINX, Inc.
More from NGINX, Inc. (20)
Recently uploaded
Recently uploaded (20)
Get Hands-On with NGINX and QUIC+HTTP/3
- 1. Getting Hands On with QUIC+ HTTP/3 Robert Haynes NGINX Technical Marketing
- 2. ©2023 F5 2 • This webinar will be recorded • The slides will be available to view • The labs will be available for a few hours after the event To get to the recording and slides, visit the same link you used to attend the webinar. Housekeeping
- 3. ©2023 F5 3 What is QUIC? QUIC + HTTP/3 Compared to TCP+TLS+HTTP/1-2 NGINX QUIC installation NGINX QUIC configuration NGINX directives and variables Lab overview Hands-on lab Wrap up Agenda
- 4. ©2023 F5 4 To improve the speed and security of web (and other) traffic. The What and Why of QUIC + HTTP/3 Why QUIC? Because TCP is Linux kernel function so slower to change and because of ‘middleboxes’. QUIC is a transport layer built on top of UDP that manages connections, encryption, and streams Why not improve TCP? What is QUIC?
- 5. ©2023 F5 5 QUIC+HTTP/3 Compared to TCP+TLS+HTTP/1-2 HTTP/3 UDP QUIC IP HTTP/1+2 TCP TLS IP Addressing Data Transport Reliable Delivery Encryption Streams Request and Response
- 6. ©2023 F5 6 HTTP/1.1 vs HTTP/2 vs HTTP/3 1 request at a time per connection No HTTP header compression Text Streams for request multiplexing Server Push Server Push HPAK Compression HPAK Compression Binary Binary Handled by QUIC No server push HTTP/1.1 HTTP/2 HTTP/3
- 7. ©2023 F5 7 QUIC Streams vs HTTP/2 Streams Packets Packets TCP + HTTP/2 QUIC + HTTP/3 Due to TCP in-order delivery, all streams are blocked until missing packet is retransmitted, and TCP session recovered. TCP is not aware of streams as they are HTTP/2 objects Stream fragments from lost packet must be retransmitted Streams not in lost packet are delivered to HTTP/3 Stream Fragment
- 8. ©2023 F5 8 QUIC+HTTP/3 Connection Establishment Client Server Connection Setup TLS Key Exchange QUIC connection setup combines connection establishment with TLS1.3 key exchange for a low latency connection establishment.
- 9. ©2023 F5 9 Potential DoS issues with QUIC connections Reflection Attacks Compromised devices make QUIC connections with spoofed source IP QUIC servers all respond to victim DDoS Attacks Compromised devices make QUIC connections with multiple spoofed source IP.s. QUIC server has to perform crypto operations before responding
- 10. ©2023 F5 10 Using Retry Packets and Minimum Packet Size Client Server Connection Setup TLS Key Exchange Server delays complex crypto operations until client address is validated Packets must be 1200bytes, making client connections more ‘expensive’
- 11. ©2023 F5 11 Client Server TCP+TLS+HTTP/1.1 UDP+QUIC+HTTP/3 The Alt-Svc HTTP Header Most clients will connect over TCP+TLS+HTTP/1 The Alt-Svc header tells clients the same service is available over HTTP/3 The client reconnects over QUIC
- 12. ©2023 F5 12 NGINX and QUIC+HTTP/3 HTTP/3 Client UDP | QUIC | HTTP/3 TCP | HTTP/1.1 TCP | HTTP/1.1 TCP | HTTP/1.1 NGINX Application Server QUIC Connection with multiple streams Multiple HTTP/1.1 connections
- 13. ©2023 F5 13 NGINX QUIC “Fun” facts NGINX QUIC is currently in preview NGINX QUIC is a separate package In future releases QUIC will be in mainline NGINX OSS and Plus This is (mostly) due to OpenSSL QUIC support timing
- 14. ©2023 F5 14 NGINX Installation Steps Install pre-requisite packages Add NGINX Signing key Add NGINX-QUIC repository Install NGINX-QUIC Start NGINX-QUIC
- 15. ©2023 F5 15 A Simple NGINX QUIC Configuration http { log_format quic '$remote_addr - $remote_user [$time_local]' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" "$server_protocol"’; access_log logs/access.log quic; server { # for better compatibility it's recommended # to use the same port for quic and https listen 8443 http3 reuseport; listen 8443 ssl; ssl_certificate certs/example.com.crt; ssl_certificate_key certs/example.com.key; ssl_protocols TLSv1.3; location / { # required for browsers to direct them into quic port add_header Alt-Svc 'h3=":8443"; ma=86400’; } } }
- 16. ©2023 F5 16 Some Additional QUIC Configuration Directives Directive Context Effect quic_bpf on; main Use eBPF to route packets to workers quic_retry on; http | stream, server Use retry packets in connection setup ssl_early_data on; http | stream, server Allow for 0-RTT connection reestablishment quic_timeout <N>s; http | stream, server Set timeouts for connection quic_mtu <size>; http | stream, server Limit maximum UDP payload size
- 17. ©2023 F5 17 Additional HTTP/3 Directives and variables Directive Context Effect http3_push uri | off ; http, server, location Configures NGINX to preemptively send content to clients http3_max_concurrent_streams number; http, server Maximum number of streams in a connection Variable Use $server_protocol Identifies the server protocol : “HTTP/1.0”, “HTTP/1.1”, “HTTP/2.0”, or “HTTP/3.0” $http3 Will be set to “quic” if the connection is using QUIC (and is not set otherwise – we advise you to use $server_protocol above instead)
- 20. ©2023 F5 20 Lab Housekeeping 1. Click link in Related Content box 2. Complete the lab • Estimated Time: 20-30 minutes • Max Time: 45 minutes • Attempts: 3 • Your invite is good for 3 hours 3. Problems? Use webinar chat!
- 21. ©2023 F5 21 Your Lab Environment Shell Instructions Check Button
- 22. ©2023 F5 22 Over to You!
- 23. ©2023 F5 23 Docs: • https://quic.nginx.org Blogs: • Binary Packages : https://www.nginx.com/blog/binary-packages-for-preview-nginx-quic-http3-implementation/ • QUIC Networking Primer: Comminig soon! Community: • Slack: https://nginxcommunity.slack.com and post in the #quic-http3 channel Wrap Up
Editor's Notes
- Welcome to the webinar
- Important housekeeping
- Talk about what we are going to talk about
- Why was QUIC developed? To make internet traffic faster and more secure. How does switching from a reliable delivery like TCP to unreliable delivery make it better? With QUIC, although the transport is UDP, loss and congestion are dealt with at the application layer, and encryption is included in the protocol. Why couldn’t we just improve TCP/HTTP ? TCP is dealt with in the kernel, and making changes to kernel code is slower and more complex (in terms of rolling it out), since QUIC is handled in user space, it can be developed an iterated faster. In addition there are a lot of TCP terminating devices, like firewalls, load balancers etc, that make changing TCP difficult. (ossification) So What is QUIC? It’s a transport protocol that allows rapid, encrypted connection establishment, avoids head of line blocking, and provides encryption by default (using TLS1.3) QUIC also implements independent data streams at the transport layer, removing the need for things like HTTP/2 streams. QUIC also separates connections form the underlying transport, making dealing with a change in the client’s IP address much more graceful. What’s HTTP/3 then – it’s essentially HTTP/2, - a binary transport with header compression and server push but with out streams (as these are supplied by QUIC)
- Let’s look at this in a bit more detail On the left here we have the existing stack, with IP supplying addressing ##, TCP## managing data transport and reliable delivery, ## TLS providing encryption, and HTTP ## managing requests and responses. Now over here let’s look at the new stack, still with IP ## managing addressing, but UDP is providing transport##, and QUIC ## is managing reliable delivery, encryption(still via TLS) and HTTP/3 ## dealing with requests and responses.
- Just a quick comparison of HTTP/1,2, and 3 ## With HTTP1 we had only 1 request at a time per connection, so browsers would make multiple connections, and there were wacky techniques like domain sharding to improve connections HTTP/2 give us streams to multiplex multiple requests on the same connection, but as the underlying transport was not streams aware, if there was a network problem, there was still a big impact. In HTTP/3, the streams are handled by the transport, which delivers multiple requests on the same connection, but in a transport aware way (we will look at this in detail next) ## Server push – where content is pushed to the client before it’s requested was implemented in HTTP/2 and remains in HTTP/3 ##HTTP/2 and 3 have header compression using HPAC, which is more like a deduplication than compression really ## Finally HTTP/3 keeps the change to a binary transport that was developed for HTTP/2
- OKStreams, In HTTP/2 we could multiplex multiple requests on a single connection, but if we lost a packet ## (very careless) the whole connection stopped,## including al the streams until we could recover that missing packet, because everything needed to be delivered to the server in order. With Streams in QUIC ## We can still multiplex, but in the event of a packet getting lost ##, only streams in those lost packet are stopped,## and other streams will still deliver content. The timeouts to detect packet loss are and retransmission algorithms are similar to TCP.
- OK, Another significant improvement is a low latency connection setup. With quic, there is a single roundtrip## to both establish the connection and exchange encryption keys, ##compared to the three way hand shake## and then TLS session set up in TCP+TLS – this obviously improves the user experience, especially in higher latency environments
- Although this is great, it does leave open some DDoS vectors – since UDP packets source IP can be spoofed, we can mount a reflections attack ## where a target device gets flooded with responses it did not initiate##, Another problem is that the CPU intensive work happens on the server before addresses are validated, ## so the QUIC server might be an easy target.
- A solution to this is the QUIC. Retry packet, ## where the server sends the client a response with a token, which they must reply with before the server performs the crypto set up ( the initial parts are still encrypted, but with a well known key) ## In addition client hello packets need to be a minimum of 1200 bytes##, making a DoS attack harder work.
- OK, but most (all?) web clients will connect over TCP ## to a new web service? How do we get them to switch to QUIC? The answer is the Alt-Svc header, which the server will respond with in the first request## The Alt-scv header will tell the clint that the same service is available over HTTP/3 and can optionally supply a new address and port to use. ## the client then connects back over QUIC (there is also a timeout saying how long this service will be available for.
- NGIX acts as a QUIC proxy, creating a multi-stream HTTP/3 connection on the server side ## and using multiple HTTP1.1 connections on the backend. In our lab we will simply be serving content from NGINX, but the principle is the same.
- Talk through
- Here’s a simple config note the ## http3 listen line and ## the add_header directive – it’s realty as simple as that.
- Talk through these directives (briefly)
- And again note that $server _protocol is better tan $http3 in practice.