QUIC, TLS 1.3, DNS-over-HTTPS et al. Internet-2019: how to move to it and what is the barrier to entry

Transcript

1. QUIC, TLS 1.3, DNS-over-HTTPS, далее везде. Интернет 2019 года: что это, как в нём существовать и каков порог входа? Артём Гавриченков <ximaera@qrator.net>
5. This is a true story. • 2018 год, production, 500-1000 запросов в секунду • Сайт находится под DDoS-защитой Cloudflare • Измерения подтверждают снижение нагрузки на CPU после перехода на HTTP/2 https://medium.com/@DarkDrag0nite/how-http-2-reduces- server-cpu-and-bandwidth-10dbb8458feb • “Cloudflare provides free HTTP/2 capabilities with the click of a button”. https://www.cloudflare.com/website-optimization/http2/
6. This is a true story. • 1 февраля: HTTP/2 включается в Cloudflare и на локальном Nginx • 1 марта: замер потребляемых ресурсов и числа запросов, пришедших на Nginx по HTTP/2 • Каков процент таких запросов?
8. Reverse proxy Cloud
9. Reverse proxy Cloud HTTP/2
10. Reverse proxy Cloud HTTP/2 HTTP/1.1
11. “The HTTP/2 specification is focused on improving the browser behavior at this point. Therefore we do not support SPDY or HTTP/2 between origin server and Cloudflare at this point. Instead we will always use HTTP/1.x.” – Martijn Gonlag, Cloudflare.
12. Reverse proxy • Технология середины 2000-х годов • Не поддерживается в стандарте 2015 года • Работа по поддержке – не ведётся
13. «…по-настоящему меня удивило то, насколько отличается взаимодействие [HTTP/2 Server Push] с различными браузерами – я-то всегда считал, что это полностью отработанная фича, готовая к использованию в production». – Максим Матюхин, Badoo, июнь 2017 года.
14. Архитектура Интернета, 2000 HTTP/1.1 SSL/TLS TCP IPv4
15. Архитектура Интернета, 2020 HTTP/2 TLS v1.3 TCP IPv6
16. QUIC • Новый протокол для транспорта • Основан на UDP • Первый черновик стандарта: июль 2016 г. • Текущая версия: 12
17. QUIC • Хайп: • NANOG 72 • APRICOT 2018 • RIPE 76 • You name it 2018
18. QUIC • https://conferences.sigcomm.org/imc/2017/papers/imc17-final39.pdf • https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop/ • Clientside: Chrome/Ubuntu, Chrome/Android (4.4.4, 6.0.1) • Serverside: Apache 2.4 (TCP), Chromium (QUIC)
19. QUIC • https://conferences.sigcomm.org/imc/2017/papers/imc17-final39.pdf • https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop/ • Реализация QUIC от Google существенно хуже TCP, если сеть не гарантирует порядок доставки пакетов
20. QUIC • https://conferences.sigcomm.org/imc/2017/papers/imc17-final39.pdf • https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop/ • Реализация QUIC от Google существенно хуже TCP, если сеть не гарантирует порядок доставки пакетов • QUIC реализован в userspace и на мобильных устройствах проводит 58% времени в состоянии “Application Limited”
21. QUIC • Реакция Google:
22. “It's a good read.” – Jana Iyengar, Google.
23. QUIC • Дизайн QUIC – это эксперимент.
24. “There is also beauty in not having a layered architecture. [..] It is great to see transport functions like acknowledgement or flow control fully contained in the Quic transport. Quic is about transport innovation, and that pretty much requires direct access to the network API.” – Christian Huitema.
25. QUIC-over-DTLS • DTLS: TLS-over-UDP • QUIC-over-TLS-over-UDP • Stream 0
26. “…as we've gotten further along in design and implementation, it's also become clear that it’s archictecturally kind of crufty and this creates a bunch of problems, including: * Retransmission of stream 0 frames from lost packets needs special handling to avoid accidentally encrypting them.” – Eric Rescorla.
27. “…as we've gotten further along in design and implementation, it's also become clear that it’s archictecturally kind of crufty and this creates a bunch of problems, including: * Retransmission of stream 0 frames from lost packets needs special handling to avoid accidentally encrypting them.” – Eric Rescorla.
28. “…as we've gotten further along in design and implementation, it's also become clear that it’s archictecturally kind of crufty and this creates a bunch of problems, including: * Retransmission of stream 0 frames from lost packets needs special handling to avoid accidentally encrypting them.” – Eric Rescorla.
29. QUIC: agile-подход 1. Черновик стандарта, версия N 2. Обсуждение, interop testing, feedback 3. Google внедряет изменения в Chrome и собственной инфраструктуре, анализирует последствия 4. N += 1, goto 1
30. QUIC: agile-подход 1. Черновик стандарта, версия N 2. Обсуждение, interop testing, feedback
32. QUIC • QUIC реализован в userspace и на мобильных устройствах проводит 58% времени в состоянии “Application Limited”
33. QUIC • QUIC реализован в userspace и на мобильных устройствах проводит 58% времени в состоянии “Application Limited” Давайте поговорим об этом.
34. SYN SYN/ACK ACK Data TCP
35. SYN SYN/ACK ACK Data Kernel space User space TCP
36. SYN* SYN/ACK* ACK* Data User space QUIC
37. QUIC • QUIC реализован в userspace и подразумевается* к реализации в userspace • Google и другие участники рабочей группы не хотят ждать, пока обновятся все ОС
38. “The reason we want to be able to work at the application level is backwards compatibility. It has to be possible to deploy QUIC on any machine even without OS support or it won't be deployable. It does not have to be performant on every platform. If people are using QUIC, whatever needs to be moved into the kernel for performance reasons will move there.” – Phillip Hallam-Baker.
39. QUIC • QUIC реализован в userspace и подразумевается* к реализации в userspace • Google и другие участники рабочей группы не хотят ждать, пока обновятся все ОС • Один и тот же подход к clientside и к serverside • QUIC в Linux kernel?
40. TCP vs UDP in Linux Kernel • http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf • Отправка UDP-датаграмм в Linux дороже, чем отправка TCP-потока • route table lookup • large segment offload • etc.
41. “One challenge with QUIC at the moment is the increased CPU cost of sending UDP packets vs TCP payloads. I've seen this across every platform Google has deployed QUIC on, so it's a widespread issue.” – Ian Swett, Google.
42. Benchmark it
43. IPv6 • Happy Eyeballs • Мистические проблемы с реализацией • Malicious activity • Blacklists и проблемы с памятью • Результат: проблемы с внедрением
44. DNSSEC • https://blog.apnic.net/2018/02/26/peak-dnssec/
45. DNS • IETF dnsop: 15 WG adopted-черновиков в полёте • DNS-over-whatever: TCP, TLS, HTTPS, QUIC… • “DNS Camel: How many features can we add to this protocol before it breaks?” https://datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa- the-dns-camel-01
46. 0 2 4 6 8 10 12 SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 Время разработки протоколов SSL/TLS, в годах
47. Выводы • Внедрение нового протокола – это не «тычку в конфигурации поменять». Это – план внедрения, оценка целесообразности и обязательный бенчмарк • Протоколы разрабатываются не богами на Олимпе. Это процесс, в котором можно – и нужно! – участвовать. • Google не будет разрабатывать протокол для вас. Это сможете сделать только вы.
48. Q&A To: Artyom Gavrichenkov <ximaera@qrator.net>