Protokol QUIC sangat menarik untuk dilihat, itulah sebabnya kami senang menulis tentangnya. Namun jika publikasi sebelumnya tentang QUIC lebih bersifat historis (sejarah lokal, jika Anda suka) dan perangkat keras, hari ini kami dengan senang hati menerbitkan terjemahan dari jenis yang berbeda - kami akan berbicara tentang penerapan protokol yang sebenarnya pada tahun 2019. Selain itu, kita tidak berbicara tentang infrastruktur kecil yang berbasis di garasi, tetapi tentang Uber, yang beroperasi hampir di seluruh dunia. Bagaimana para insinyur perusahaan mengambil keputusan untuk menggunakan QUIC dalam produksi, bagaimana mereka melakukan pengujian dan apa yang mereka lihat setelah meluncurkannya dalam produksi β di bawah batas.
Gambar-gambarnya dapat diklik. Selamat membaca!
Uber memiliki skala global, yaitu kehadiran di 600 kota, yang masing-masing kota aplikasinya bergantung sepenuhnya pada Internet nirkabel dari lebih dari 4500 operator seluler. Pengguna mengharapkan aplikasinya tidak hanya cepat, namun juga real-time - untuk mencapai hal ini, aplikasi Uber memerlukan latensi rendah dan koneksi yang sangat andal. Sayangnya, tapi tumpukannya tidak bekerja dengan baik dalam jaringan nirkabel yang dinamis dan rawan kehilangan. Kami menyadari bahwa dalam kasus ini, kinerja rendah berhubungan langsung dengan implementasi TCP di kernel sistem operasi.
Untuk mengatasi masalah tersebut, kami menerapkan , protokol multiplexing saluran modern yang memberi kita kontrol lebih besar atas kinerja protokol transport. Saat ini kelompok kerja menstandarkan QUIC sebagai .
Setelah pengujian ekstensif, kami menyimpulkan bahwa penerapan QUIC dalam aplikasi kami akan menghasilkan latensi ekor yang lebih rendah dibandingkan dengan TCP. Kami mengamati pengurangan dalam kisaran 10-30% untuk lalu lintas HTTPS di aplikasi pengemudi dan penumpang. QUIC juga memberi kami kendali menyeluruh atas paket pengguna.
Pada artikel ini, kami berbagi pengalaman dalam mengoptimalkan TCP untuk aplikasi Uber menggunakan tumpukan yang mendukung QUIC.
Teknologi terbaru: TCP
Saat ini, TCP adalah protokol transport yang paling banyak digunakan untuk mengirimkan lalu lintas HTTPS di Internet. TCP menyediakan aliran byte yang andal, sehingga mengatasi kemacetan jaringan dan hilangnya lapisan tautan. Meluasnya penggunaan TCP untuk lalu lintas HTTPS disebabkan oleh keberadaan TCP di mana-mana (hampir setiap OS berisi TCP), ketersediaan di sebagian besar infrastruktur (seperti penyeimbang beban, proxy HTTPS, dan CDN), dan fungsionalitas siap pakai yang tersedia. di hampir sebagian besar platform dan jaringan.
Sebagian besar pengguna menggunakan aplikasi kami saat bepergian, dan latensi ekor TCP sama sekali tidak memenuhi permintaan lalu lintas HTTPS real-time kami. Sederhananya, pengguna di seluruh dunia pernah mengalami hal ini - Gambar 1 menunjukkan penundaan di kota-kota besar:
Gambar 1: Latensi ekor bervariasi di kota-kota utama Uber.
Meskipun latensi di jaringan India dan Brasil lebih tinggi dibandingkan di AS dan Inggris, latensi ekor jauh lebih tinggi daripada latensi rata-rata. Dan hal ini berlaku bahkan di Amerika dan Inggris.
TCP melalui kinerja udara
TCP diciptakan untuk kabel jaringan, yaitu dengan penekanan pada tautan yang sangat dapat diprediksi. Namun, nirkabel jaringan mempunyai karakteristik dan kesulitan tersendiri. Pertama, jaringan nirkabel rentan terhadap kerugian akibat interferensi dan redaman sinyal. Misalnya, jaringan Wi-Fi sensitif terhadap gelombang mikro, bluetooth, dan gelombang radio lainnya. Jaringan seluler mengalami kehilangan sinyal () akibat pemantulan/penyerapan sinyal oleh benda dan bangunan, serta dari dari tetangga . Hal ini menyebabkan lebih signifikan (4-10 kali lipat) dan lebih beragam dan kehilangan paket dibandingkan dengan koneksi kabel.
Untuk mengatasi fluktuasi dan kehilangan bandwidth, jaringan seluler biasanya menggunakan buffer besar untuk lonjakan lalu lintas. Hal ini dapat menyebabkan antrian berlebihan, yang berarti penundaan lebih lama. Sangat sering TCP memperlakukan antrian ini sebagai pemborosan karena waktu tunggu yang diperpanjang, sehingga TCP cenderung melakukan relay dan dengan demikian mengisi buffer. Masalah ini dikenal sebagai (), dan ini sangat internet modern.
Terakhir, kinerja jaringan seluler bervariasi menurut operator, wilayah, dan waktu. Pada Gambar 2, kami mengumpulkan median penundaan lalu lintas HTTPS di seluruh sel dalam rentang 2 kilometer. Data dikumpulkan untuk dua operator seluler besar di Delhi, India. Seperti yang Anda lihat, kinerja bervariasi dari sel ke sel. Selain itu, produktivitas satu operator berbeda dengan produktivitas operator kedua. Hal ini dipengaruhi oleh faktor-faktor seperti pola masuk jaringan dengan mempertimbangkan waktu dan lokasi, mobilitas pengguna, serta infrastruktur jaringan dengan mempertimbangkan kepadatan menara dan rasio jenis jaringan (LTE, 3G, dll).
Gambar 2. Delay dengan contoh radius 2 km. Delhi, India.
Selain itu, kinerja jaringan seluler bervariasi dari waktu ke waktu. Gambar 3 menunjukkan latensi median berdasarkan hari dalam seminggu. Kami juga mengamati perbedaan dalam skala yang lebih kecil, dalam satu hari dan satu jam.
Gambar 3. Keterlambatan tail dapat bervariasi secara signifikan antar hari, namun untuk operator yang sama.
Semua hal di atas menyebabkan kinerja TCP tidak efektif di jaringan nirkabel. Namun, sebelum mencari alternatif selain TCP, kami ingin mengembangkan pemahaman yang tepat tentang poin-poin berikut:
- apakah TCP penyebab utama di balik latensi ekor dalam aplikasi kita?
- Apakah jaringan modern memiliki penundaan bolak-balik (RTT) yang signifikan dan bervariasi?
- Apa dampak RTT dan kerugian terhadap kinerja TCP?
Analisis Kinerja TCP
Untuk memahami cara kami menganalisis kinerja TCP, mari kita lihat sekilas cara TCP mentransfer data dari pengirim ke penerima. Pertama, pengirim membuat koneksi TCP, melakukan tiga arah : Pengirim mengirimkan paket SYN, menunggu paket SYN-ACK dari penerima, kemudian mengirimkan paket ACK. Jalur tambahan kedua dan ketiga digunakan untuk membuat koneksi TCP. Penerima mengakui penerimaan setiap paket (ACK) untuk memastikan pengiriman yang dapat diandalkan.
Jika sebuah paket atau ACK hilang, pengirim mengirimkannya kembali setelah batas waktu habis (RTO, ). RTO dihitung secara dinamis berdasarkan berbagai faktor, seperti perkiraan penundaan RTT antara pengirim dan penerima.
Gambar 4. Pertukaran paket melalui TCP/TLS mencakup mekanisme transmisi ulang.
Untuk menentukan bagaimana kinerja TCP dalam aplikasi kami, kami memantau paket TCP menggunakan selama seminggu untuk lalu lintas pertempuran yang datang dari server edge India. Kami kemudian menganalisis koneksi TCP menggunakan . Selain itu, kami membuat aplikasi Android yang mengirimkan lalu lintas yang ditiru ke server pengujian, sebanyak mungkin meniru lalu lintas nyata. Ponsel pintar dengan aplikasi ini dibagikan kepada beberapa karyawan, yang mengumpulkan log selama beberapa hari.
Hasil kedua percobaan itu konsisten satu sama lain. Kami melihat latensi RTT yang tinggi; nilai ekor hampir 6 kali lebih tinggi dari nilai median; rata-rata aritmatika penundaan lebih dari 1 detik. Banyak koneksi terputus, menyebabkan TCP mengirimkan ulang 3,5% dari seluruh paket. Di daerah yang padat seperti bandara dan stasiun kereta api, kami melihat kerugian sebesar 7%. Hasil ini menimbulkan keraguan terhadap kebijakan konvensional yang digunakan dalam jaringan seluler secara signifikan mengurangi kerugian di tingkat transportasi. Berikut hasil pengujian dari aplikasi βsimulatorβ :
Metrik jaringan
Nilai-nilai
RTT, milidetik [50%,75%, 95%,99%]
[350, 425, 725, 2300]
Divergensi RTT, detik
Rata-rata ~1,2 detik
Paket hilang karena koneksi tidak stabil
Rata-rata ~3.5% (7% di area yang kelebihan beban)
Hampir setengah dari koneksi ini mengalami setidaknya satu paket yang hilang, sebagian besar merupakan paket SYN dan SYN-ACK. Kebanyakan implementasi TCP menggunakan nilai RTO 1 detik untuk paket SYN, yang meningkat secara eksponensial untuk kerugian berikutnya. Waktu pemuatan aplikasi mungkin bertambah karena TCP membutuhkan waktu lebih lama untuk membuat koneksi.
Dalam kasus paket data, nilai RTO yang tinggi sangat mengurangi pemanfaatan jaringan dengan adanya kerugian sementara dalam jaringan nirkabel. Kami menemukan bahwa waktu transmisi ulang rata-rata adalah sekitar 1 detik dengan penundaan ekor hampir 30 detik. Latensi tinggi di tingkat TCP ini menyebabkan waktu habis dan permintaan ulang HTTPS, sehingga semakin meningkatkan latensi dan inefisiensi jaringan.
Meskipun persentil ke-75 dari RTT yang diukur adalah sekitar 425 ms, persentil ke-75 untuk TCP hampir 3 detik. Hal ini mengisyaratkan bahwa kerugian tersebut menyebabkan TCP memerlukan 7-10 lintasan agar berhasil mengirimkan data. Hal ini mungkin disebabkan oleh perhitungan RTO yang tidak efisien, ketidakmampuan TCP untuk merespons kehilangan dengan cepat di jendela dan ketidakefisienan algoritma kontrol kemacetan, yang tidak membedakan antara kerugian nirkabel dan kerugian akibat kemacetan jaringan. Di bawah ini adalah hasil tes kerugian TCP:
Statistik kehilangan paket TCP
Nilai
Persentase koneksi dengan setidaknya 1 paket hilang
45%
Persentase koneksi yang terputus selama pengaturan koneksi
30%
Persentase koneksi yang hilang selama pertukaran data
76%
Distribusi penundaan transmisi ulang, detik [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Distribusi jumlah transmisi ulang untuk satu paket atau segmen TCP
[1,3,6,7]
Penerapan QUIC
Awalnya dikembangkan oleh Google, QUIC adalah protokol transport modern multi-thread yang berjalan di atas UDP. Saat ini QUIC sudah masuk (kami sudah menulis bahwa ada dua versi QUIC, penasaran β kira-kira. Penerjemah). Seperti yang ditunjukkan pada Gambar 5, QUIC ditempatkan di bawah HTTP/3 (pada kenyataannya, HTTP/2 di atas QUIC adalah HTTP/3, yang sekarang sedang distandarisasi secara intensif). Ini sebagian menggantikan lapisan HTTPS dan TCP dengan menggunakan UDP untuk membentuk paket. QUIC hanya mendukung transfer data yang aman karena TLS sepenuhnya terintegrasi dalam QUIC.
Gambar 5: QUIC berjalan di bawah HTTP/3, menggantikan TLS, yang sebelumnya berjalan di bawah HTTP/2.
Berikut adalah alasan yang meyakinkan kami untuk menggunakan QUIC untuk amplifikasi TCP:
- Pembentukan koneksi 0-RTT. QUIC memungkinkan penggunaan kembali otorisasi dari koneksi sebelumnya, sehingga mengurangi jumlah jabat tangan keamanan. Di masa depan akan mendukung 0-RTT, tetapi jabat tangan TCP tiga arah masih diperlukan.
- mengatasi pemblokiran HoL. HTTP/2 menggunakan satu koneksi TCP per klien untuk meningkatkan kinerja, namun hal ini dapat menyebabkan pemblokiran HoL (head-of-line). QUIC menyederhanakan multiplexing dan mengirimkan permintaan ke aplikasi secara mandiri.
- pengendalian kemacetan. QUIC berada di lapisan aplikasi, sehingga memudahkan pembaruan algoritma transport utama yang mengontrol pengiriman berdasarkan parameter jaringan (jumlah kerugian atau RTT). Kebanyakan implementasi TCP menggunakan algoritma ini , yang tidak optimal untuk lalu lintas yang sensitif terhadap latensi. Algoritma yang baru dikembangkan seperti , memodelkan jaringan dengan lebih akurat dan mengoptimalkan latensi. QUIC memungkinkan Anda menggunakan BBR dan memperbarui algoritme ini saat digunakan. .
- pengisian kembali kerugian. QUIC memanggil dua TLP () sebelum RTO dipicu - bahkan ketika kerugiannya sangat besar. Ini berbeda dengan implementasi TCP. TLP mengirimkan ulang sebagian besar paket terakhir (atau paket baru, jika ada) untuk memicu pengisian ulang yang cepat. Menangani penundaan ekor (tail delay) sangat berguna untuk cara Uber mengoperasikan jaringannya, yaitu untuk transfer data yang pendek, sporadis, dan sensitif terhadap latensi.
- ACK yang dioptimalkan. Karena setiap paket memiliki nomor urut unik, tidak ada masalah paket ketika dikirim ulang. Paket ACK juga berisi waktu untuk memproses paket dan menghasilkan ACK di sisi klien. Fitur-fitur ini memastikan QUIC menghitung RTT dengan lebih akurat. ACK di QUIC mendukung hingga 256 band , membantu pengirim menjadi lebih tangguh terhadap pengacakan paket dan menggunakan lebih sedikit byte dalam prosesnya. ACK Selektif () di TCP tidak menyelesaikan masalah ini di semua kasus.
- migrasi koneksi. Koneksi QUIC diidentifikasi dengan ID 64-bit, jadi jika klien mengubah alamat IP, ID koneksi lama dapat terus digunakan pada alamat IP baru tanpa gangguan. Ini adalah praktik yang sangat umum untuk aplikasi seluler di mana pengguna beralih antara koneksi Wi-Fi dan seluler.
Alternatif untuk QUIC
Kami mempertimbangkan pendekatan alternatif untuk memecahkan masalah sebelum memilih QUIC.
Hal pertama yang kami coba adalah menerapkan TPC PoP (Points of Presence) untuk mengakhiri koneksi TCP lebih dekat dengan pengguna. Pada dasarnya, PoP mengakhiri koneksi TCP dengan perangkat seluler yang lebih dekat ke jaringan seluler dan mem-proxy lalu lintas kembali ke infrastruktur asli. Dengan mengakhiri TCP lebih dekat, kita berpotensi mengurangi RTT dan memastikan bahwa TCP lebih responsif terhadap lingkungan nirkabel yang dinamis. Namun, percobaan kami menunjukkan bahwa sebagian besar RTT dan kerugian berasal dari jaringan seluler dan penggunaan PoP tidak memberikan peningkatan kinerja yang signifikan.
Kami juga melihat penyetelan parameter TCP. Menyiapkan tumpukan TCP di server edge heterogen kami sulit dilakukan karena TCP memiliki implementasi yang berbeda di berbagai versi OS. Sulit untuk menerapkan ini dan menguji konfigurasi jaringan yang berbeda. Mengonfigurasi TCP secara langsung di perangkat seluler tidak dapat dilakukan karena kurangnya izin. Lebih penting lagi, fitur seperti koneksi 0-RTT dan peningkatan prediksi RTT sangat penting untuk arsitektur protokol, dan oleh karena itu tidak mungkin mencapai manfaat yang signifikan hanya dengan menyetel TCP saja.
Terakhir, kami mengevaluasi beberapa protokol berbasis UDP yang memecahkan masalah streaming videoβkami ingin melihat apakah protokol ini dapat membantu dalam kasus kami. Sayangnya, pengaturan keamanannya sangat kurang, dan juga memerlukan koneksi TCP tambahan untuk metadata dan informasi kontrol.
Penelitian kami menunjukkan bahwa QUIC mungkin merupakan satu-satunya protokol yang dapat membantu mengatasi masalah lalu lintas Internet, dengan tetap mempertimbangkan keamanan dan kinerja.
Integrasi QUIC ke dalam platform
Agar berhasil menyematkan QUIC dan meningkatkan kinerja aplikasi di lingkungan konektivitas yang buruk, kami mengganti tumpukan lama (HTTP/2 melalui TLS/TCP) dengan protokol QUIC. Kami menggunakan perpustakaan jaringan dari , yang berisi protokol versi Google asli - gQUIC. Implementasi ini juga terus ditingkatkan untuk mengikuti spesifikasi IETF terbaru.
Kami pertama kali mengintegrasikan Cronet ke dalam aplikasi Android kami untuk menambahkan dukungan untuk QUIC. Integrasi dilakukan sedemikian rupa untuk mengurangi biaya migrasi semaksimal mungkin. Daripada sepenuhnya mengganti tumpukan jaringan lama yang menggunakan perpustakaan , kami telah mengintegrasikan Cronet DI BAWAH kerangka API OkHttp. Dengan melakukan integrasi dengan cara ini, kami menghindari perubahan pada panggilan jaringan kami (yang digunakan oleh ) di tingkat API.
Mirip dengan pendekatan untuk perangkat Android, kami menerapkan Cronet ke aplikasi Uber di iOS, mencegat lalu lintas HTTP dari jaringan menggunakan . Abstraksi ini, yang disediakan oleh iOS Foundation, menangani data URL khusus protokol dan memastikan bahwa kami dapat mengintegrasikan Cronet ke dalam aplikasi iOS kami tanpa biaya migrasi yang signifikan.
Menyelesaikan QUIC di Google Cloud Balancer
Di sisi backend, penyelesaian QUIC disediakan oleh infrastruktur penyeimbangan beban Google Cloud, yang menggunakan header sebagai tanggapan untuk mendukung QUIC. Secara umum, penyeimbang menambahkan header alt-svc ke setiap permintaan HTTP, dan ini sudah memvalidasi dukungan QUIC untuk domain tersebut. Saat klien Cronet menerima respons HTTP dengan header ini, ia menggunakan QUIC untuk permintaan HTTP berikutnya ke domain tersebut. Setelah penyeimbang menyelesaikan QUIC, infrastruktur kami secara eksplisit mengirimkan tindakan ini melalui HTTP2/TCP ke pusat data kami.
Kinerja: Hasil
Performa keluaran adalah alasan utama kami mencari protokol yang lebih baik. Untuk memulainya, kami membuat stand dengan untuk mengetahui bagaimana QUIC akan berperilaku dalam profil jaringan yang berbeda. Untuk menguji kinerja QUIC di jaringan dunia nyata, kami menjalankan eksperimen saat berkendara di sekitar New Delhi menggunakan lalu lintas jaringan yang ditiru yang sangat mirip dengan panggilan HTTP di aplikasi penumpang.
Eksperimen 1
Peralatan untuk percobaan:
- menguji perangkat Android dengan tumpukan OkHttp dan Cronet untuk memastikan bahwa kami mengizinkan lalu lintas HTTPS masing-masing melalui TCP dan QUIC;
- server emulasi berbasis Java yang mengirimkan jenis header HTTPS yang sama sebagai respons dan memuat perangkat klien untuk menerima permintaan dari perangkat tersebut;
- proxy cloud yang secara fisik berlokasi dekat dengan India untuk mengakhiri koneksi TCP dan QUIC. Sedangkan untuk terminasi TCP kami menggunakan reverse proxy , sulit menemukan proksi terbalik sumber terbuka untuk QUIC. Kami membuat sendiri proxy terbalik untuk QUIC menggunakan tumpukan QUIC dasar dari Chromium dan itu menjadi chromium sebagai open source.
Gambar 6. Rangkaian uji jalan TCP vs QUIC terdiri dari perangkat Android dengan OkHttp dan Cronet, proxy cloud untuk mengakhiri koneksi, dan server emulasi.
Eksperimen 2
Saat Google menyediakan QUIC dengan , kami menggunakan inventaris yang sama, tetapi dengan satu modifikasi: alih-alih NGINX, kami menggunakan penyeimbang beban Google untuk menghentikan koneksi TCP dan QUIC dari perangkat, serta merutekan lalu lintas HTTPS ke server emulasi. Penyeimbang didistribusikan di seluruh dunia, tetapi menggunakan server PoP yang paling dekat dengan perangkat (berkat geolokasi).
Gambar 7. Pada percobaan kedua, kami ingin membandingkan latensi penyelesaian TCP dan QUIC: menggunakan Google Cloud dan menggunakan proxy cloud kami.
Hasilnya, beberapa wahyu menanti kita:
- penghentian melalui PoP meningkatkan kinerja TCP. Karena penyeimbang mengakhiri koneksi TCP lebih dekat dengan pengguna dan sangat dioptimalkan, hal ini menghasilkan RTT yang lebih rendah, sehingga meningkatkan kinerja TCP. Meskipun QUIC tidak terlalu terpengaruh, QUIC masih mengungguli TCP dalam hal mengurangi latensi ekor (sebesar 10-30 persen).
- ekor terpengaruh . Meskipun proksi QUIC kami lebih jauh dari perangkat (latensi sekitar 50 ms lebih tinggi) dibandingkan penyeimbang beban Google, proksi QUIC memberikan kinerja yang serupa - pengurangan latensi sebesar 15% dibandingkan pengurangan persentil ke-20 untuk TCP sebesar 99%. Hal ini menunjukkan bahwa transisi mil terakhir merupakan hambatan dalam jaringan.
Gambar 8: Hasil dari dua percobaan menunjukkan bahwa QUIC secara signifikan mengungguli TCP.
Memerangi lalu lintas
Terinspirasi oleh eksperimen, kami telah menerapkan dukungan QUIC di aplikasi Android dan iOS kami. Kami melakukan pengujian A/B untuk mengetahui dampak QUIC di kota-kota tempat Uber beroperasi. Secara umum, kami melihat penurunan yang signifikan pada tail delay di kedua wilayah, operator telekomunikasi, dan jenis jaringan.
Grafik di bawah menunjukkan persentase peningkatan pada bagian ekor (persentil 95 dan 99) berdasarkan wilayah makro dan jenis jaringan yang berbeda - LTE, 3G, 2G.
Gambar 9. Dalam uji pertempuran, QUIC mengungguli TCP dalam hal latensi.
Hanya maju
Mungkin ini baru permulaan - peluncuran QUIC ke dalam produksi telah memberikan peluang luar biasa untuk meningkatkan kinerja aplikasi baik di jaringan yang stabil maupun tidak stabil, yaitu:
Peningkatan cakupan
Setelah menganalisis kinerja protokol pada lalu lintas nyata, kami melihat bahwa sekitar 80% sesi berhasil menggunakan QUIC Semua permintaan, sementara 15% sesi menggunakan kombinasi QUIC dan TCP. Kami berasumsi bahwa kombinasi ini disebabkan oleh waktu tunggu perpustakaan Cronet kembali ke TCP, karena tidak dapat membedakan antara kegagalan UDP yang sebenarnya dan kondisi jaringan yang buruk. Kami sedang mencari solusi untuk masalah ini sambil berupaya menerapkan QUIC selanjutnya.
Pengoptimalan QUIC
Lalu lintas dari aplikasi seluler sensitif terhadap latensi, namun tidak sensitif terhadap bandwidth. Selain itu, aplikasi kami terutama digunakan pada jaringan seluler. Berdasarkan percobaan, tail latency masih tinggi meskipun menggunakan proxy untuk menghentikan TCP dan QUIC yang dekat dengan pengguna. Kami secara aktif mencari cara untuk meningkatkan manajemen kemacetan dan meningkatkan efisiensi algoritma pemulihan kerugian QUIC.
Dengan hal ini dan beberapa perbaikan lainnya, kami berencana untuk meningkatkan pengalaman pengguna terlepas dari jaringan dan wilayahnya, menjadikan transportasi paket yang nyaman dan lancar menjadi lebih mudah diakses di seluruh dunia.
Sumber: www.habr.com