QUIC, TLS 1.3, DNS-over-HTTPS, lalu di mana-mana

Habr, halo! Ini adalah transkripsi laporan Artyom ximaera Gavrichenkov, yang ia baca di BackendConf 2018 sebagai bagian dari festival RIT ++.

- Halo!

Judul laporan berisi daftar protokol yang panjang, kita akan membahasnya secara bertahap, tetapi mari kita mulai dengan apa yang tidak ada dalam judul.

Judul ini (di bawah potongan) dari salah satu blog, di Internet Anda bisa melihat banyak judul seperti itu. Dalam posting itu tertulis bahwa HTTP / 2 bukan masa depan yang jauh, ini adalah milik kita; Ini adalah protokol modern yang dikembangkan oleh Google dan ratusan profesional dari banyak perusahaan maju, dirilis oleh IETF sebagai RFC pada tahun 2015, yaitu, sudah 3 tahun yang lalu.

Standar IETF diterima oleh industri, seperti dokumen beton bertulang seperti batu nisan, pada kenyataannya.



Direncanakan bahwa mereka menentukan perkembangan Internet dan memperhitungkan semua skenario penggunaan yang mungkin. Artinya, jika kita memiliki versi lama dari protokol, dan kemudian yang baru muncul, maka itu pasti memelihara kompatibilitas dengan semua kasus pengguna sebelumnya dan juga menyelesaikan banyak masalah, mengoptimalkan pekerjaan, dan sebagainya.

HTTP / 2 harus disesuaikan untuk web lanjutan, siap digunakan dalam layanan dan aplikasi modern, pada kenyataannya, menjadi pengganti drop-in untuk protokol HTTP versi lama. Itu seharusnya meningkatkan kinerja situs, sambil mengurangi beban backend.



Bahkan para SEO mengatakan mereka membutuhkan HTTP / 2.



Dan tampaknya sangat mudah untuk didukung. Secara khusus, Neil Craig dari BBC menulis di blog-nya bahwa itu cukup untuk "mengaktifkannya" di server. Anda masih dapat menemukan banyak presentasi di mana dikatakan bahwa HTTP / 2 disertakan sebagai berikut: jika Anda memiliki Nginx, maka Anda dapat memperbaiki konfigurasi di satu tempat; jika tidak ada HTTPS, Anda perlu menambahkan sertifikat; tetapi, pada prinsipnya, ini adalah masalah satu token dalam file konfigurasi.

Dan, tentu saja, setelah Anda mendaftar token ini, Anda segera mulai menerima bonus dari peningkatan produktivitas, fitur baru yang tersedia, peluang - secara umum, semuanya menjadi luar biasa.


<sup>Tautan dari slide:
1. medium.com/@DarkDrag0nite/how-http-2-reduces-server-cpu-and-bandwidth-10dbb8458feb
2.www.cloudflare.com/website-optimization/http2</sup>

Sejarah selanjutnya didasarkan pada peristiwa nyata. Perusahaan memiliki beberapa layanan online yang memproses sekitar 500-1000 permintaan HTTP per detik. Layanan ini di bawah perlindungan DDoS dari Cloudflare.

Ada banyak tolok ukur yang mengkonfirmasi bahwa beralih ke HTTP / 2 mengurangi beban di server karena fakta bahwa ketika beralih ke HTTP / 2, browser tidak membangun 7 koneksi, tetapi satu sesuai dengan rencana. Diharapkan ketika beralih ke HTTP / 2 dan memori yang digunakan akan menjadi lebih sedikit, dan prosesor akan lebih sedikit dimuat.

Plus, blog Cloudflare dan situs web Cloudflare menyarankan untuk mengaktifkan HTTP / 2 hanya dengan satu klik. Pertanyaan: Mengapa tidak melakukan ini?



Pada 1 Februari 2018, perusahaan menyertakan HTTP / 2 dengan tombol ini di Cloudflare, dan pada Nginx lokal juga memasukkannya. Data bulan dikumpulkan. Pada 1 Maret, sumber daya yang dikonsumsi diukur, dan kemudian sysop melihat jumlah permintaan dalam log yang datang melalui HTTP / 2 ke server di belakang Cloudflare. Slide berikutnya adalah persentase permintaan yang datang ke server melalui HTTP / 2. Angkat tangan, siapa yang tahu berapa persen ini?

[Dari penonton: "1-2%!"]



- Nol. Untuk alasan apa?



Cloudflare, serta layanan perlindungan serangan lainnya, MSSP, dan layanan cloud, beroperasi dalam mode proxy terbalik . Jika dalam situasi normal browser langsung terhubung ke Nginx Anda, yaitu koneksi langsung dari browser ke server HTTP Anda, maka Anda dapat menggunakan protokol yang didukung browser.

Jika ada cloud antara browser dan server Anda, koneksi TCP yang masuk diakhiri di cloud, TLS juga diakhiri di sana, dan permintaan HTTP pertama kali pergi ke cloud, maka cloud sebenarnya memproses permintaan ini.

Cloud memiliki server HTTP sendiri, dalam kebanyakan kasus Nginx yang sama, dalam kasus yang jarang terjadi adalah server yang "ditulis sendiri". Server ini mem-parsing permintaan, entah bagaimana memprosesnya, berkonsultasi dengan cache dan, pada akhirnya, membentuk permintaan baru dan mengirimkannya ke server Anda menggunakan protokol yang didukungnya.

Semua cloud yang ada yang mengklaim mendukung HTTP / 2 mendukung HTTP / 2 di sisi browser. Tetapi jangan mendukung dia di samping melihat ke arah Anda.



Mengapa

Sebuah jawaban yang sederhana dan tidak sepenuhnya benar: "Karena dalam kebanyakan kasus mereka memiliki Nginx dikerahkan, dan Nginx tidak dapat pergi melalui HTTP / 2 ke hulu." Oke, well, jawaban ini benar , tetapi tidak lengkap .



Jawaban lengkap diberikan kepada kami oleh para insinyur Cloudflare. Faktanya adalah bahwa fokus spesifikasi HTTP / 2, ditulis dan dirilis pada tahun 2015, adalah untuk meningkatkan kinerja browser pada kasus penggunaan tertentu, misalnya, untuk Google.

Google menggunakan teknologinya sendiri, tidak menggunakan reverse proxy di depan server produksinya, jadi tidak ada yang memikirkan reverse proxy, dan itulah sebabnya HTTP / 2 dari cloud ke hulu tidak digunakan. Di sana, pada kenyataannya, ada sedikit keuntungan, karena dalam mode proksi terbalik, dari apa yang dijelaskan dalam protokol HTTP / 2, misalnya, Server Push tidak didukung, karena tidak jelas bagaimana cara kerjanya jika kita memiliki pipelining.

Fakta bahwa HTTP / 2 menyimpan koneksi itu keren, tetapi reverse proxy sendiri menyimpannya karena tidak membuka satu koneksi per pengguna. Ada sedikit gunanya mendukung HTTP / 2 di sini, dan overhead dan masalah yang terkait dengan ini besar.



Yang penting: reverse proxy adalah teknologi yang mulai aktif digunakan sekitar 13 tahun yang lalu. Artinya, ini adalah teknologi pertengahan 2000-an: saya pergi ke sekolah saat itu sudah digunakan. Tidak disebutkan dalam standar yang dikeluarkan pada tahun 2015, tidak didukung, dan upaya untuk mendukungnya saat ini tidak dilakukan dalam kelompok kerja httpbis di IETF.

Ini adalah salah satu contoh masalah yang muncul ketika orang mulai menerapkan HTTP / 2. Bahkan, ketika Anda berbicara dengan orang-orang yang telah ditempatkan dan sudah memiliki pengalaman dengannya, Anda terus-menerus mendengar tentang kata-kata yang sama.



Mereka dirumuskan dengan baik oleh Maxim Matyukhin dari Badoo dalam sebuah posting di Habré, di mana ia berbicara tentang bagaimana HTTP / 2 Server Push bekerja. Dia menulis bahwa dia sangat terkejut betapa berbedanya interaksi fungsi khusus ini dengan browser, karena dia pikir itu adalah fitur yang dikembangkan sepenuhnya, siap digunakan dalam produksi . Saya telah mendengar frasa ini sehubungan dengan HTTP / 2 berkali-kali: kami pikir itu adalah protokol pengganti drop-in - yaitu, Anda menyalakannya, dan semuanya baik-baik saja - mengapa semuanya begitu rumit dalam praktiknya, di mana semua masalah ini berasal dan kekurangan?

Mari kita cari tahu.



Secara historis, di zaman kuno, arsitektur Internet terlihat seperti ini. Tidak ada kotak hijau di beberapa titik, tetapi kemudian muncul.

Protokol berikut digunakan: karena kita berbicara tentang Internet dan bukan tentang jaringan lokal, di level bawah kita mulai dengan IPv4. Di atasnya, protokol TCP atau UDP digunakan, tetapi untuk 90% kasus (karena 80-90% lalu lintas di Internet adalah Web), lalu TCP berikutnya, lalu SSL (yang kemudian digantikan oleh TLS), dan di atas adalah hiperteks HTTP . Secara bertahap, situasi berkembang bahwa, sesuai rencana, pada tahun 2020 arsitektur Internet seharusnya telah berubah secara radikal.



IPv6 telah bersama kami untuk waktu yang sangat lama. TLS baru-baru ini diperbarui, kami masih akan membahas bagaimana ini terjadi. Dan protokol HTTP / 2 juga telah diperbarui.

Penulis fiksi ilmiah dalam negeri yang indah, Vadim Panov dalam siklus Enclave memiliki ungkapan yang begitu indah : “Anda sedang menunggu masa depan. Apakah Anda menginginkan masa depan? Itu telah datang. Anda tidak menginginkannya? Itu sudah datang. ” Satu-satunya hal yang tetap tidak tersentuh - pada beberapa tahun yang lalu - adalah protokol TCP.

Orang-orang yang terlibat dalam desain Internet, tidak bisa melewati ketidakadilan yang mencolok dan memutuskan untuk membuang protokol TCP juga.

Oke, ini, tentu saja, lelucon. Masalahnya bukan hanya protokolnya sudah terlalu tua. Ada kekurangan dalam TCP. Sangat mengkhawatirkan bagi banyak orang bahwa protokol HTTP / 2 sudah ditulis, standar 2015 sudah diimplementasikan, tetapi itu tidak selalu bekerja secara khusus dengan TCP, dan akan menyenangkan untuk meletakkan beberapa transportasi lain di bawahnya, lebih cocok untuk apa yang dulu disebut SPDY ketika percakapan itu pergi, dan kemudian untuk HTTP / 2.



Protokol memutuskan untuk memanggil QUIC. QUIC adalah protokol yang saat ini sedang dikembangkan untuk transportasi. Ini didasarkan pada UDP, yaitu, itu adalah protokol datagram . Draf pertama standar ini dirilis pada Juli 2016, dan versi draf saat ini ...

[Speaker memeriksa surat di telepon]

"... ya, masih tanggal 12."

Saat ini, QUIC belum menjadi standar - ini sedang ditulis secara aktif. Jika saya tidak salah - saya tidak menulis di slide karena saya takut membuat kesalahan - tetapi di IETF 101 di London dikatakan bahwa pada November 2018 direncanakan untuk merilisnya sebagai dokumen akhir. Ini adalah standar QUIC itu sendiri, karena ada delapan dokumen lagi dalam kelompok kerja dokumen.



Artinya, belum ada standar, tetapi hype aktif sudah berlangsung. Saya hanya mendaftar konferensi-konferensi di mana saya telah selama enam bulan terakhir, di mana ada setidaknya satu presentasi tentang QUIC. Tentang "betapa kerennya itu", "bagaimana kita perlu beralih ke sana", "apa yang harus dilakukan untuk operator", "berhenti memfilter UDP - QUIC akan mengerjakannya sekarang". Semua hype ini telah berlangsung cukup lama - saya telah melihat banyak artikel yang mendesak industri game untuk beralih ke QUIC daripada UDP yang biasa.


<sup>Tautan dari slide:
1. conferences.sigcomm.org/imc/2017/papers/imc17-final39.pdf
2. blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop</sup>

Pada November 2017, tautan berikut ini muncul di milis kelompok kerja QUIC: yang teratas ada di whitepaper, dan yang paling bawah bagi mereka yang kesulitan membaca whitepaper adalah tautan ke blog APNIC dengan ringkasan.

Para peneliti memutuskan untuk membandingkan kinerja TCP dan QUIC dalam bentuknya saat ini. Sebagai perbandingan, agar tidak berurusan dengan siapa yang harus disalahkan dan di mana Windows dapat disalahkan, di sisi klien mereka mengambil Chrome di bawah Ubuntu, dan juga mengambil 2 perangkat seluler: satu Nexus dan beberapa Samsung (catatan editor: Nexus 6 dan MotoG) dengan versi Android 4 dan 6, dan mereka juga meluncurkan Chrome.

Di sisi server, mereka menginstal Apache untuk melihat cara kerja server TCP, dan untuk memantau QUIC, mereka merobek sepotong kode sumber terbuka yang ada di proyek Chromium. Hasil benchmark menunjukkan bahwa sementara dalam semua kondisi rumah kaca QUIC benar-benar mengungguli TCP, ada beberapa pilar yang hilang.



Sebagai contoh, implementasi QUIC Google bekerja jauh lebih buruk daripada TCP jika pengurutan paket terjadi pada jaringan, yaitu, paket-paket tiba dengan urutan yang salah ketika dikirim oleh server. Pada 2017-2018, di usia jaringan seluler dan nirkabel, umumnya tidak ada jaminan bahwa paket tersebut akan terbang secara prinsip, belum lagi dalam urutan apa. QUIC bekerja sangat baik pada jaringan kabel, tetapi siapa yang menggunakan jaringan kabel sekarang?



Secara umum, pengembang kode ini di Google, tampaknya, benar-benar tidak suka ponsel.

QUIC adalah protokol yang diimplementasikan di atas UDP di ruang pengguna. Dan di perangkat seluler juga di ruang pengguna. Menurut hasil pengukuran, dalam situasi normal, yaitu, ketika bekerja melalui jaringan nirkabel, implementasi protokol QUIC menghabiskan 58% dari waktu di Android dalam keadaan "Application Limited". Kondisi apa ini Ini adalah keadaan ketika kami mengirim beberapa data dan sedang menunggu konfirmasi. Sebagai perbandingan, pada desktop ada angka sekitar 7%.

Hanya 2 kasus penggunaan: yang pertama adalah jaringan nirkabel, yang kedua adalah perangkat seluler; dan QUIC berfungsi sebagai TCP, atau jauh lebih buruk. Secara alami, ini ternyata berada dalam kelompok kerja IETF yang dikhususkan untuk QUIC dan, tentu saja, Google bereaksi terhadap hal ini. Tanggapan Google adalah sebagai berikut:


^{mailarchive.ietf.org/arch/msg/quic/QktVML_qNDfqjIGirj4t5D0JRGE}

Ya, kami tertawa, tetapi sebenarnya itu sangat logis.

Mengapa Karena desain QUIC - meskipun kita sudah berbicara tentang implementasi dalam produksi, tetapi - pada kenyataannya, percobaan paling liar.

Inilah, katakanlah, model ISO / OSI tujuh tingkat. Siapa yang mengingatnya di sini? Ingat levelnya: fisik, saluran, jaringan, transportasi, omong kosong, omong kosong dan diterapkan, kan?

Ya, itu sudah dikembangkan sejak lama, dan entah bagaimana kami hidup dengan model level ini. QUIC adalah percobaan untuk menghilangkan sistem tier jaringan itu sendiri. Ini menggabungkan enkripsi, transportasi, pengiriman data yang andal. Semua ini bukan dalam struktur tier, tetapi dalam penggabungan, di mana setiap komponen memiliki akses ke API komponen lainnya.



Mengutip salah satu perancang protokol QUIC, Christian Guitem: "Salah satu keunggulan utama QUIC dari sudut pandang arsitektur adalah tidak adanya struktur level." Kami memiliki pengakuan, kontrol aliran, enkripsi, dan semua kriptografi - semua ini sepenuhnya dalam satu transportasi, dan inovasi transportasi kami menyiratkan akses semua ini langsung ke API jaringan, jadi kami tidak ingin arsitektur berjenjang di QUIC.



Pembicaraan dalam kelompok kerja tentang hal ini dimulai karena fakta bahwa pada awal Maret perancang protokol QUIC lainnya, yaitu Eric Rescorla, memutuskan untuk mengusulkan untuk membahas varian di mana semua enkripsi dihapus dari QUIC, secara umum. Yang tersisa hanyalah fungsi transportasi yang berjalan di atas DTLS. DTLS, pada gilirannya, adalah TLS lebih dari UDP, total ternyata: QUIC lebih dari TLS lebih dari UDP.

Dari mana datangnya tawaran seperti itu? Ngomong-ngomong, Rescorla menulis sebuah dokumen besar, tetapi sama sekali tidak menjadi standar - dokumen itu menjadi bahan diskusi karena dalam proses mendesain arsitektur QUIC, dalam proses pengujian interoperabilitas dan implementasi, banyak masalah muncul. Terutama terkait dengan "streaming 0".

Apakah streaming 0 dalam QUIC? Ini adalah ide yang sama seperti di HTTP / 2: kami memiliki satu koneksi, di dalamnya kami memiliki beberapa aliran multiplexing. Dengan desain QUIC, saya ingat, enkripsi disediakan oleh protokol yang sama. Ini dilakukan sebagai berikut: aliran "ajaib" nomor 0 dibuka, yang bertanggung jawab untuk membangun koneksi, berjabat tangan dan enkripsi, setelah itu aliran 0 ini dienkripsi dan yang lainnya dienkripsi juga. Dengan ini banyak masalah telah muncul, mereka terdaftar di milis, ada 10 item, saya tidak akan berhenti di masing-masing. Saya hanya akan memilih satu yang sangat saya sukai.


^{www.ietf.org/mail-archive/web/quic/current/msg03498.html}

Masalah dengan utas 0, salah satunya, adalah jika kita kehilangan paket, kita perlu mengirimnya kembali. Dan pada saat yang sama, misalnya, di sisi server, koneksi sudah dapat ditandai sebagai terenkripsi, dan paket yang hilang tanggal kembali ke waktu ketika itu tidak terenkripsi. Dalam hal ini, ketika meneruskan, implementasi dapat mengenkripsi paket secara acak.

Sekali lagi:



Enkripsi paket secara acak.

Ini cukup sulit untuk dikomentari, selain menceritakan bagaimana semua ini sebenarnya dirancang. Pengembangan QUIC sebenarnya menggunakan pendekatan ersatz-agile. Artinya, bukan seseorang yang menulis standar beton bertulang yang bisa dirilis secara resmi setelah beberapa kali pengulangan. Tidak.



Pekerjaannya adalah sebagai berikut:
1. Draf standar dimulai, misalnya, nomor 5;
2. Di milis, juga pada pertemuan-pertemuan IETF - tiga potong setahun - diskusi diadakan, kemudian implementasi dilakukan di hackathons, pengujian interop, umpan balik dikumpulkan;
3. Google mengimplementasikan beberapa perubahan di Chrome, di infrastrukturnya sendiri, menganalisis konsekuensi dan kemudian penghitung bertambah dan standar 6 muncul.

Sekarang, saya ingatkan Anda, versi 12.
Catatan Ed.: Pada 10 Juli 2018, ini sudah tanggal 13.

Apa yang penting di sini?

Pertama, kami baru saja melihat kontra, tetapi ada plus. Bahkan, Anda dapat berpartisipasi dalam proses ini. Umpan balik dikumpulkan dari semua pihak yang terlibat: jika Anda terlibat dalam permainan, jika Anda berpikir bahwa Anda dalam industri game dapat dengan mudah mengubah dan mengubah UDP, tetapkan QUIC sebagai gantinya, dan semuanya akan berfungsi - tidak, itu tidak akan berhasil. Tetapi pada saat Anda dapat mempengaruhinya, Anda entah bagaimana dapat bekerja dengannya.



Dan ini sebenarnya adalah cerita yang umum. Umpan balik dari Anda diharapkan, semua orang ingin melihatnya.

Google sedang mengembangkan protokol, memasukkan beberapa ide ke dalamnya - untuk tujuannya sendiri. Perusahaan yang melakukan hal-hal lain (jika itu bukan Web, game atau aplikasi seluler yang tipikal, SEO adalah sama), mereka secara default tidak dapat mengharapkan protokol untuk memperhitungkan minat mereka: tidak hanya karena tidak menarik minat siapa pun, tetapi karena tidak ada yang tahu tentang minat ini.

Kebetulan ini adalah sebuah pengakuan. Tentu saja, pertanyaannya adalah bagi saya mengapa kami, sebagai Lab Qrator , khususnya, tidak berpartisipasi dalam pengembangan protokol HTTP / 2 dan tidak memberi tahu siapa pun tentang reverse proxy. Tetapi Cloudflare dan Nginx yang sama juga tidak berpartisipasi di sana.

Sementara industri tidak terlibat dalam hal ini, Google, Facebook, beberapa perusahaan dan akademisi lainnya sedang berkembang. Untuk memberi tahu Anda, di pesta dekat-IETF, kata "akademisi" adalah, katakanlah, tidak terpuji. Kedengarannya seperti julukan "skizofrenia" dan "hypochondriac". Orang sering datang tanpa tujuan praktis, tanpa memahami tugas-tugas nyata, tetapi cocok di sana, karena lebih mudah untuk mendapatkan disertasi doktoral.

Tentu saja, seseorang harus berpartisipasi dalam hal ini dan tidak ada pilihan lain.



Kembali ke QUIC: jadi, protokol diterapkan di ruang pengguna, pada perangkat seluler ada ... Blah blah. "Diimplementasikan di ruang pengguna." Mari kita bicarakan.

Bagaimana kami secara umum mengatur transportasi sebelum kami membuat QUIC? Bagaimana cara kerjanya sekarang dalam produksi? Ada protokol TCP jika kita berbicara tentang Web.



Dalam TCP, ada yang namanya jabat tangan tiga : SYN, SYN / ACK, ACK. Hal ini diperlukan untuk beberapa hal: untuk mencegah server digunakan untuk menyerang orang lain, untuk berhasil menyaring serangan tertentu pada protokol TCP, seperti banjir SYN . Hanya setelah 3 segmen jabat tangan tiga berlalu, kami mulai mengirim data.



Pada saat yang sama, ada 4 tindakan, 3 di antaranya terjadi di kernel, mereka terjadi cukup efisien, dan data sudah masuk ke ruang pengguna saat koneksi dibuat.



Dalam situasi dengan QUIC, semua kebahagiaan ini ada di userspace.Ada tanda bintang di sini, karena ada terminologi yang tidak cukup "SYN, SYN / ACK", tetapi, pada kenyataannya, ini adalah jabat tangan yang sama yang baru saja pindah sepenuhnya ke ruang pengguna. Jika banjir 20 Gbit / s terbang dan sebelum di TCP mereka dapat diproses di kernel dengan cookie SYN , sekarang mereka perlu diproses di ruang pengguna, karena mereka terbang melalui seluruh kernel melalui seluruh konteks konteks. Dan di sana mereka perlu didukung, entah bagaimana.

Mengapa ini dilakukan? Mengapa QUIC adalah protokol ruang pengguna? Meskipun transportasi, tampaknya, tempat yang tepat baginya di suatu tempat di tingkat sistem.



Karena, sekali lagi, ini adalah kepentingan Google dan anggota tim lainnya. Mereka ingin melihat protokol baru diimplementasikan, mereka tidak ingin menunggu sampai semua sistem operasi di kabupaten diperbarui. Jika diterapkan di ruang pengguna, itu dapat digunakan (khususnya, di browser, tetapi tidak hanya) sekarang.

Fakta bahwa Anda perlu menghabiskan banyak sumber daya di sisi server bukan masalah bagi Google. Di suatu tempat ada pepatah yang mengatakan bahwa untuk menyelesaikan sebagian besar masalah kinerja di backend dari Internet modern, Google hanya perlu menyita setengah dari server (dan lebih disukai tiga perempat). Yang bukan tanpa akal sehat, karena Google, memang, tidak ditukar dengan hal sepele seperti itu.


^{www.ietf.org/mail-archive/web/quic/current/msg03736.html}

Di layar ada kutipan literal dari milis QUIC, di mana diskusi hanya tentang protokol yang direncanakan untuk implementasi di ruang pengguna. Ini adalah kutipan literal: “Kami ingin menyebarkan QUIC ke mesin apa pun tanpa dukungan sistem operasi. Jika ada yang memiliki masalah kinerja, mereka akan membawa semuanya ke inti. " QUIC sudah sangat longgar sehingga menakutkan untuk membawa ini ke inti dengan enkripsi dan yang lainnya, tetapi kelompok kerja pada topik ini juga tidak terlalu khawatir.



Dan mengapa pendekatan ini digunakan di sisi klien - saya bisa mengerti. Tetapi pendekatan yang sama digunakan di sisi server. Secara teoritis, dalam hal ini, QUIC benar-benar layak untuk dibawa ke inti, tetapi, sekali lagi, bekerja pada hal ini tidak berkelanjutan, dan ketika selesai, kita akan menjadi yang paling beruban, dan saya tidak berencana untuk hidup selamanya. Dan ketika ini terjadi - tidak terlalu jelas.

Berbicara tentang kernel Linux, orang tidak dapat membantu tetapi menyebutkan bahwa salah satu alasan utama keberadaan QUIC adalah bahwa ia diimplementasikan di atas protokol UDP yang ringan, dan karena ini bekerja lebih efisien, lebih cepat ... dan mengapa kita memerlukan TCP yang begitu besar dan rumit.


^{vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf}

Berikut ini tautan lain ke tolok ukur. Ternyata mengirim datagram UDP ke Linux lebih mahal daripada mengirim aliran TCP, jauh lebih mahal, jauh lebih mahal. Ada 2 poin utama (yaitu banyak poin, tetapi hanya dua poin utama):

1. Pencarian tabel routing membutuhkan waktu lebih lama dalam hal datagram UDP;
2. Sepotong yang disebut "large segment offload". Dalam TCP, kita cukup mengunggah aliran data besar ke transmisi, kita tidak harus membaginya menjadi segmen-segmen pada CPU, sementara di UDP kita perlu menyiapkan setiap datagram, kita tidak memiliki aliran. Saat ini, pengembang kernel memikirkan apa yang harus dilakukan dengannya, tetapi, pada umumnya, pada saat ini, TCP bekerja untuk mengirim data besar yang tidak masuk ke dalam satu paket, lebih efisien daripada UDP, yang menjadi dasar QUIC.


^{www.ietf.org/mail-archive/web/quic/current/msg03720.html}

Ini lagi kutipan dari seorang karyawan Google, khususnya saya juga menanyakan pertanyaan ini kepadanya. Bagaimanapun, kita bisa saja menyalahkan Linux, katakan bahwa di bawah Windows, mungkin semuanya tidak terlalu buruk, tapi tidak. Diduga bahwa pada platform apa pun di mana Google menempatkan QUIC, ada masalah dengan kenaikan biaya (dari sudut pandang prosesor sentral) mengirim paket UDP terhadap aliran TCP. Artinya, ini bukan hanya Linux seperti itu, tetapi pendekatan umum.



Yang menuntun kita ke satu pemikiran sederhana.

Berhentilah berbicara tentang QUIC. Cukup. Gagasan sederhana untuk keluar dari sini adalah bahwa sebelum menerapkan protokol baru alih-alih yang lama: HTTP / 2 vs. HTTP / 1.1, QUIC alih-alih TCP, enkripsi DNS, IPv6, bukan IPv4 ... hal pertama yang harus dilakukan sebelum membuat keputusan dan meletakkan pada produksi, tentu saja, pembandingan.

Jangan percaya siapa pun yang mengatakan bahwa protokol "Anda bisa mengubah / mengaktifkan / menekan tombol" - tidak ! Ini tidak akan pernah terjadi - dan tidak akan pernah terjadi, dan tidak akan pernah ada di masa depan, dan tidak ada yang menjaminnya.

Karena itu, hanya tolok ukur, dan, tentu saja, bahwa jika Anda tidak melakukan ini, tetapi hanya menyebarkan sesuatu, maka, tentu saja, tidak ada yang akan memberi Anda jaminan kualitas pekerjaan.



By the way, tentang IPv6. Faktanya adalah bahwa pada masa IPv6, ketika dikembangkan, protokol dikembangkan dengan cara yang agak lebih langsung, yaitu, tanpa teknologi yang gesit. Tetapi adaptasi mereka di Internet masih memakan waktu yang sangat besar. Dan, saat ini, masih berlangsung, dan masih tergantung pada 10-20% dalam kasus IPv6. Apalagi tergantung negaranya, karena di Rusia justru lebih rendah.

Dalam perjalanan untuk mengimplementasikan IPv6, banyak masalah diselesaikan. Siapa yang tahu apa itu Happy Eyeballs? Secara umum, ada banyak masalah yang terkait dengan IPv6, apalagi, ketika pengguna langsung mengeluh. Katakanlah Anda menutup laptop Anda, meninggalkan rumah di mana Anda memiliki IPv6, datang ke kafe di mana tidak ada IPv6, buka laptop - tidak ada yang berhasil, karena cache browser dan sistem operasi terus melihat IPv6, tetapi tidak ada konektivitas lokal .

Suatu pendekatan yang disebut "Happy Eyeballs" (juga standar yang dikeluarkan oleh IETF) ditemukan : jika dalam 0,3 detik kami tidak menemukan konektivitas IPv6, tidak dapat terhubung, kami kembali ke IPv4.

Seekor kruk, tetapi tampaknya hampir selalu berhasil, tetapi! Masalah mistis dengan implementasi terus muncul. Secara khusus, untuk beberapa alasan, salah satu masalah paling populer adalah dengan iPad, yang beralih dari IPv6 ke IPv4 dan kembali jauh lebih lambat daripada dalam 0,3 detik: sekitar 1 detik, atau bahkan 1 menit.

Bahkan pada titik tertentu, tawaran gila muncul di IETF 99 di Praha: "Biarkan Happy Eyeballs ada di setiap jaringan melalui syslog ke server terpusat, jika ada masalah mengirim sesuatu." Kumpulkan syslog dari semua perangkat yang terhubung - tentu saja, tidak ada yang menyetujui ini. Tetapi ini merupakan indikator bahwa ada banyak masalah.

Masalah lain adalah perang melawan semua jenis kegiatan jahat, karena jaringan lokal di IPv6 adalah / 64 dan ada banyak alamat yang penyerang dapat mulai memilah-milah, perlindungan perlu mengumpulkan mereka dalam waktu, dan semua itu. Penting untuk entah bagaimana berurusan dengan ini, semua ini harus direalisasikan.

Akibatnya, kami masih mendapatkan masalah implementasi, yang tidak hanya dinyatakan dalam kenyataan bahwa seseorang secara perlahan mengimplementasikan IPv6. Tidak, mereka mulai mematikannya lagi. Kembali ke IPv4. Karena bahkan tanpa masalah, sulit untuk membenarkan manfaat transisi ke manajemen, tetapi jika, setelah dinyalakan, pengguna juga mulai mengeluh, itu saja. Ini adalah contoh ketika bahkan protokol yang dikembangkan dengan pandangan untuk implementasi masih menyebabkan masalah terliar dengan implementasi, yang dinyatakan dalam headwash ke departemen teknis.

Bayangkan apa yang akan terjadi ketika menerapkan protokol yang tidak dirancang untuk implementasi skala besar dalam kasus penggunaan masing-masing.


^{blog.apnic.net/2018/02/26/peak-dnssec}

Contoh lain tentang topik ini adalah DNSSEC. Saya tidak akan meminta Anda mengangkat tangan untuk mencari tahu siapa yang memilikinya, karena saya tahu tidak ada yang memilikinya.

Penyebaran IPv6, di satu sisi, sedang berkembang, di sisi lain, ada masalah dengan itu, tapi setidaknya itu akan datang. Sejak akhir tahun lalu, implementasi DNSSEC di dunia telah melambat dan bergerak ke arah yang berlawanan.

Dalam grafik ini, kita melihat jumlah pengguna Internet harian (yang diukur oleh APNIC Labs) menggunakan resolver yang memvalidasi DNSSEC. Tren bearish sangat jelas terlihat di sini: ini dimulai setelah puncak terakhir, dan puncak ini Oktober 2016.

DNSSEC memiliki tujuan, memiliki tugas yang tepat, tetapi penyebarannya benar-benar berhenti dan beberapa jenis proses mundur telah dimulai, dan masih harus diselidiki. dari mana proses ini berasal.


^{datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-01}

Secara umum, ada banyak masalah dengan DNS. Kelompok kerja IETF dnsop sekarang memiliki 3 ketua, 15 konsep tentang apa yang disebut “dalam penerbangan” : mereka bersiap-siap untuk dibebaskan sebagai RFC.

DNS, khususnya, belajar mentransfer di atas segalanya. Di atas TCP, itu bekerja untuk waktu yang lama (tetapi orang masih perlu menunjukkan bagaimana melakukannya dengan benar ). Sekarang mereka mulai menjalankannya di atas TLS , melalui HTTPS , melalui QUIC .

Semua ini tampak sangat luar biasa sampai orang-orang mulai menyadarinya, dan mereka tidak mulai terluka pada poin kelima. Pada bulan Maret 2017, pengembang OpenDNS membawa presentasi yang disebut "DNS Camel" ke IETF, atau "unta dns". Presentasi bermuara pada pemikiran berikut: berapa banyak lagi yang bisa kita muat unta ini (alias protokol DNS) sebelum ranting berikutnya mematahkan tulang punggungnya?

Ini adalah pendekatan umum tentang bagaimana kita melihat desain sekarang. Fitur ditambahkan, ada banyak fitur, mereka saling mengganggu dengan cara yang berbeda. Dan tidak selalu dengan cara yang dapat diprediksi, dan tidak selalu penulis implementasi memahami semua kemungkinan titik gangguan. Implementasi dari setiap fitur baru tersebut, implementasi, implementasi dalam produksi - tambahkan serangkaian titik kegagalan potensial di setiap tempat di mana gangguan tersebut terjadi. Tanpa patokan, tanpa pemantauan - tidak ada tempat.



Mengapa penting untuk berpartisipasi dalam seluruh proses ini? Karena standar IETF - "RFC" - masih merupakan standar. Ada statistik yang sangat bagus: jadwal pengembangan untuk berbagai versi protokol enkripsi SSL dan TLS.

Perhatikan bahwa versi SSL dimulai pada nomor 2, karena versi 0.9 dan 1.0 tidak pernah dirilis dalam produksi, mereka lebih bocor daripada yang bisa dikeluarkan oleh Netscape. Oleh karena itu, cerita dimulai dengan protokol SSL 2.0, yang dikembangkan setahun. Kemudian SSL 3.0 dikembangkan satu tahun lagi.

Kemudian TLS 1.0 dikembangkan selama 3 tahun; versi 1.1 - 7 tahun; 1.2 dikembangkan hanya 2 tahun, karena tidak ada perubahan besar; tetapi versi terakhir, yang dirilis pada bulan Maret tahun ini - draft ke-27, dikembangkan - dikembangkan 10 tahun .

Dalam kelompok kerja yang sesuai, pada beberapa titik ada kepanikan besar pada topik ini, karena ternyata TLS 1.3 memecahkan banyak kasus penggunaan, terutama di organisasi keuangan, dengan pemantauan dan firewall mereka. Tetapi bahkan perusahaan besar seperti Bank AS tidak dapat mengubah ini, setelah mencapai realisasi pada tahap draft kedelapan belas. Mereka tidak punya waktu untuk melakukan apa-apa tentang itu, karena ketika Anda datang ke pesta pada saat semua orang sudah diberi tagihan, Anda tidak dapat berharap bahwa proposal Anda untuk melanjutkan kesenangan akan diperlakukan dengan pengertian .

Oleh karena itu, jika dalam beberapa protokol - ini lagi pertanyaan untuk umpan balik - ada / akan / ada fitur yang tidak sesuai dengan Anda, satu-satunya pilihan adalah untuk melacak ini dalam waktu dan campur tangan dalam waktu, karena jika tidak maka akan dirilis dan harus membangun kruk di sekitar ini.



Di sini, pada slide, sebenarnya, ada tiga kesimpulan utama dari keseluruhan proses.

Pertama: seperti yang saya katakan, memperkenalkan protokol baru tidak mudah dalam konfigurasi "tweak sesuatu". Ini adalah rencana implementasi yang terencana, penilaian kelayakan dengan tolok ukur wajib, karena dalam kenyataannya semua akan berperilaku.

Poin nomor dua: protokol tidak dikembangkan oleh alien, mereka tidak diberikan kepada kami dari atas, Anda dapat dan harus berpartisipasi dalam proses ini, karena tidak ada yang akan mempromosikan kasus pengguna Anda untuk Anda.

Dan yang ketiga, sungguh: dibutuhkan umpan balik . Yang paling penting adalah bahwa Google itu sendiri, bukan jahat, hanya mengejar tujuannya sendiri, tidak memiliki tugas untuk mengembangkan protokol untuk Anda dan untuk Anda, hanya Anda yang bisa melakukannya.

Oleh karena itu, dalam kasus umum, pengenalan sesuatu yang baru dan bukan sesuatu yang lama, terlepas dari banyaknya artikel pujian di blog, dimulai dengan fakta bahwa Anda perlu berinvestasi tidak hanya dalam penyebaran, tetapi dalam proses desain protokol, lihat cara kerjanya, dan hanya kemudian membuat keputusan berdasarkan informasi.

Terima kasih