Selama lebih dari 20 tahun sekarang, kami telah melihat halaman web menggunakan protokol HTTP. Sebagian besar pengguna tidak berpikir sama sekali tentang apa itu dan bagaimana cara kerjanya. Yang lain tahu bahwa di suatu tempat di bawah HTTP ada TLS, dan di bawahnya ada TCP, di mana IP dan sebagainya. Dan yang ketiga - bidat - percaya bahwa TCP adalah abad terakhir, mereka menginginkan sesuatu yang lebih cepat, lebih dapat diandalkan dan lebih aman. Tetapi dalam upaya mereka untuk menciptakan protokol ideal baru, mereka kembali ke teknologi tahun 80-an dan mencoba membangun dunia baru yang berani di atasnya.
Sedikit sejarah: HTTP / 1.1
Pada tahun 1997, protokol pertukaran teks HTTP versi 1.1 memperoleh RFC-nya. Pada saat itu, protokol tersebut digunakan oleh browser selama beberapa tahun, dan standar baru bertahan lima belas tahun lagi. Protokol hanya bekerja berdasarkan permintaan-respons dan dimaksudkan terutama untuk mengirimkan informasi tekstual.
HTTP dirancang untuk bekerja di atas protokol TCP, yang menjamin pengiriman paket yang dapat diandalkan ke tujuan. TCP didasarkan pada membangun dan memelihara koneksi yang andal antara titik akhir dan lalu lintas segmentasi. Segmen memiliki nomor urut dan checksum sendiri. Jika tiba-tiba salah satu segmen tidak datang atau datang dengan checksum yang salah, transmisi akan berhenti sampai segmen yang hilang dipulihkan.
Dalam HTTP / 1.0, koneksi TCP ditutup setelah setiap permintaan. Sejak itu sangat boros Membuat koneksi TCP (3-Way-Handshake) bukanlah proses yang cepat. HTTP / 1.1 memperkenalkan mekanisme keep-hidup, yang memungkinkan Anda untuk menggunakan kembali koneksi tunggal untuk beberapa permintaan. Namun, karena dapat dengan mudah menjadi hambatan, beberapa koneksi TCP / IP ke host yang sama diizinkan dalam implementasi HTTP / 1.1 yang berbeda. Misalnya, di Chrome dan di versi Firefox terbaru, hingga enam koneksi diperbolehkan.
Enkripsi juga seharusnya diserahkan kepada protokol lain, dan untuk ini, protokol TLS digunakan melalui TCP, yang dipercaya melindungi data, tetapi semakin menambah waktu yang diperlukan untuk membuat koneksi. Akibatnya, proses jabat tangan mulai terlihat seperti ini:
Ilustrasi CloudflareDengan demikian, HTTP / 1.1 memiliki sejumlah masalah:
- Pengaturan koneksi lambat.
- Satu koneksi TCP digunakan untuk satu permintaan, yang berarti bahwa seluruh permintaan harus mencari koneksi lain, atau menunggu hingga permintaan saat ini melepaskannya.
- Hanya model tarikan yang didukung. Tidak ada dalam standar tentang server-push.
- Judul ditransmisikan dalam teks.
Jika server-push entah bagaimana diimplementasikan menggunakan protokol WebSocket, maka sisa masalah harus ditangani secara lebih radikal.
Sedikit modernitas: HTTP / 2
Pada 2012, pengerjaan protokol SPDY (diucapkan “kecepatan”) dimulai di perut Google. Protokol ini dirancang untuk memecahkan masalah dasar HTTP / 1.1 dan pada saat yang sama harus mempertahankan kompatibilitas ke belakang. Pada 2015, kelompok kerja IETF memperkenalkan spesifikasi HTTP / 2 berdasarkan protokol SPDY. Berikut perbedaan HTTP / 2:
- Serialisasi biner.
- Multiplexing beberapa permintaan HTTP menjadi satu koneksi TCP.
- Server mendorong keluar dari kotak (tanpa WebSocket).
Protokol adalah langkah besar ke depan. Ini sangat
mengungguli versi pertama dan tidak memerlukan penciptaan beberapa koneksi TCP: semua permintaan ke satu host digandakan menjadi satu. Artinya, dalam satu koneksi ada beberapa yang disebut stream, masing-masing memiliki ID sendiri. Bonusnya adalah server-push kotak.
Namun, multiplikasi mengarah ke masalah landasan lainnya. Bayangkan bahwa kita secara asinkron menjalankan 5 permintaan ke satu server. Saat menggunakan HTTP / 2, semua permintaan ini akan dilakukan dalam koneksi TCP yang sama, yang berarti bahwa jika salah satu segmen dari permintaan apa pun hilang atau salah, pengiriman semua permintaan dan respons akan berhenti sampai segmen yang hilang dipulihkan. Jelas, semakin buruk kualitas koneksinya, semakin lambat HTTP / 2 berfungsi.
Menurut Daniel Stenberg , dalam situasi di mana paket yang hilang menyumbang 2% dari semua, HTTP / 1.1 di browser berkinerja lebih baik daripada HTTP / 2 karena fakta bahwa ia membuka 6 koneksi, bukan satu.
Masalah ini disebut "head-of-line blocking" dan, sayangnya, tidak mungkin untuk menyelesaikannya menggunakan TCP.
Ilustrasi Daniel SteinbergAkibatnya, para pengembang standar HTTP / 2 melakukan pekerjaan dengan baik dan melakukan hampir semua yang dapat dilakukan pada tingkat aplikasi model OSI. Sudah waktunya untuk turun ke tingkat transportasi dan menciptakan protokol transportasi baru.
Kami membutuhkan protokol baru: UDP vs TCP
Cukup cepat menjadi jelas bahwa untuk memperkenalkan protokol transport layer yang benar-benar baru adalah tugas yang tidak dapat diselesaikan dalam realitas saat ini. Faktanya adalah bahwa kelenjar atau kotak tengah (router, firewall, server NAT ...) tahu tentang tingkat transportasi, dan untuk mengajari mereka sesuatu yang baru adalah tugas yang sangat sulit. Selain itu, dukungan untuk protokol transport ditransfer ke kernel sistem operasi, dan kernel juga berubah tidak begitu dengan sukarela.
Dan di sini orang bisa menyerah dan berkata, "Kami, tentu saja, akan menciptakan HTTP / 3 baru dengan preferensi dan pelacur, tetapi akan diimplementasikan dalam 10-15 tahun (setelah sekitar waktu ini sebagian besar kelenjar akan diganti)", tetapi ada satu lagi bukan yang paling opsi yang jelas: gunakan protokol UDP. Ya, ya, protokol yang sama yang dengannya kami melemparkan file pada LAN di akhir tahun sembilan puluhan dan awal nol. Hampir semua potongan besi saat ini tahu cara bekerja dengannya.
Apa kelebihan UDP dibandingkan TCP? Pertama-tama, kami tidak memiliki sesi level transportasi yang diketahui oleh besi. Ini memungkinkan kita untuk menentukan sendiri sesi pada titik akhir dan menyelesaikan konflik yang muncul di sana. Artinya, kita tidak terbatas pada satu atau beberapa sesi (seperti dalam TCP), tetapi kita dapat membuatnya sebanyak yang kita butuhkan. Kedua, pengiriman data melalui UDP lebih cepat daripada melalui TCP. Jadi, secara teori, kita bisa menembus kecepatan tertinggi hari ini yang dicapai dalam HTTP / 2.
Namun, UDP tidak menjamin pengiriman data yang andal. Bahkan, kami hanya mengirim paket, berharap bahwa mereka akan diterima di ujung lain. Tidak menerima? Yah, tidak beruntung ... Ini sudah cukup untuk mengirimkan video untuk orang dewasa, tetapi untuk hal-hal yang lebih serius Anda memerlukan keandalan, yang berarti Anda harus memutar sesuatu yang lain di atas UDP.
Seperti HTTP / 2, pekerjaan membuat protokol baru dimulai di Google pada tahun 2012, yaitu pada waktu yang hampir bersamaan dengan dimulainya pekerjaan di SPDY. Pada tahun 2013, Jim Roskind memperkenalkan
protokol QUIC (Quick UDP Internet Connections) kepada masyarakat umum, dan sudah pada tahun 2015 Internet Draft diperkenalkan untuk menstandarisasi IETF. Sudah pada waktu itu, protokol yang dikembangkan oleh Roskind di Google sangat berbeda dari yang standar, sehingga versi Google disebut gQUIC.
Apa itu QUIC
Pertama, seperti yang telah disebutkan, ini adalah pembungkus UDP. Koneksi QUIC naik di atas UDP, di mana, secara analogi dengan HTTP / 2, beberapa aliran mungkin ada. Streaming ini hanya ada di titik akhir dan dilayani secara independen. Jika kehilangan paket terjadi dalam satu aliran, itu tidak akan mempengaruhi yang lain dengan cara apa pun.
Ilustrasi Daniel SteinbergKedua, enkripsi sekarang diimplementasikan tidak pada tingkat yang terpisah, tetapi termasuk dalam protokol. Hal ini memungkinkan Anda untuk membuat koneksi dan bertukar kunci publik dalam satu jabat tangan, dan juga memungkinkan Anda untuk menggunakan mekanisme jabat tangan 0-RTT yang rumit dan umumnya menghindari penundaan berjabat tangan. Selain itu, paket data individu sekarang dapat dienkripsi. Ini memungkinkan Anda untuk tidak menunggu penyelesaian menerima data dari aliran, tetapi untuk mendekripsi paket yang diterima secara independen. Mode operasi ini tidak mungkin sama sekali dalam TCP, karena TLS dan TCP bekerja secara independen satu sama lain, dan TLS tidak bisa mengetahui data TCP yang akan dipotong. Dan karena itu, saya tidak dapat menyiapkan segmen saya sehingga mereka masuk ke segmen TCP satu-ke-satu dan dapat didekripsi secara independen. Semua peningkatan ini memungkinkan QUIC mengurangi latensi dibandingkan dengan TCP.
Ketiga, konsep stream mudah memungkinkan Anda untuk melepaskan koneksi dari alamat IP klien. Ini penting, misalnya, ketika klien beralih dari satu titik akses Wi-Fi ke yang lain, mengubah IP-nya. Dalam hal ini, ketika menggunakan TCP, proses panjang terjadi selama koneksi TCP yang ada jatuh dalam batas waktu dan koneksi baru dibuat dari IP baru. Dalam kasus QUIC, klien hanya terus mengirim paket dari IP baru ke server dengan ID aliran lama. Karena Stream ID sekarang unik dan tidak digunakan kembali, server memahami bahwa klien telah mengubah IP, mengirimkan paket yang hilang dan melanjutkan komunikasi ke alamat baru.
Keempat, QUIC diimplementasikan pada level aplikasi, bukan sistem operasi. Ini, di satu sisi, memungkinkan perubahan protokol yang lebih cepat, seperti Untuk mendapatkan pembaruan, cukup perbarui perpustakaan, daripada menunggu versi OS yang baru. Di sisi lain, ini mengarah pada peningkatan konsumsi prosesor yang kuat.
Dan akhirnya, berita utama. Kompresi header hanya mengacu pada poin yang berbeda dalam QUIC dan gQUIC. Saya tidak melihat alasan untuk mencurahkan banyak waktu untuk hal ini, saya hanya bisa mengatakan bahwa dalam versi yang diajukan untuk standardisasi, kompresi header dibuat semirip mungkin dengan kompresi header di HTTP / 2. Lebih detail bisa dibaca di
sini .
Seberapa cepat?
Ini pertanyaan yang sulit. Faktanya adalah bahwa sementara kita tidak memiliki standar, tidak ada yang istimewa untuk diukur. Mungkin satu-satunya statistik yang kami miliki adalah statistik Google, yang telah menggunakan gQUIC sejak 2013 dan pada 2016
melaporkan kepada IETF bahwa sekitar 90% dari lalu lintas yang menuju ke server mereka dari browser Chrome sekarang menggunakan QUIC. Dalam presentasi yang sama, mereka melaporkan bahwa melalui gQUIC, halaman memuat sekitar 5% lebih cepat, dan streaming video memiliki 30% lebih sedikit pembekuan dibandingkan dengan TCP.
Pada tahun 2017, sekelompok peneliti yang dipimpin oleh Arash Molavi Kakhki menerbitkan
karya besar pada studi kinerja GQUIC dibandingkan dengan TCP.
Studi ini mengungkapkan beberapa kelemahan GQUIC, seperti ketidakstabilan untuk paket jaringan, ketidakadilan dalam kapasitas saluran dan transfer yang lebih lambat dari objek kecil (hingga 10 kb). Yang terakhir, bagaimanapun, dapat dikompensasi untuk menggunakan 0-RTT. Dalam semua kasus lain yang diselidiki, gQUIC menunjukkan peningkatan kecepatan dibandingkan dengan TCP. Sulit untuk berbicara tentang angka-angka tertentu. Lebih baik membaca
studi itu sendiri atau
posting singkat .
Di sini harus dikatakan bahwa data ini khusus tentang gQUIC, dan mereka tidak relevan untuk standar yang sedang dikembangkan. Apa yang akan terjadi untuk QUIC: sejauh ini, misteri ada di belakang tujuh segel, tetapi ada harapan bahwa kelemahan yang diidentifikasi oleh gQUIC akan diperhitungkan dan diperbaiki.
Sedikit masa depan: bagaimana dengan HTTP / 3?
Dan di sini semuanya sangat jelas: API tidak akan berubah dengan cara apa pun. Semuanya akan tetap sama persis seperti di HTTP / 2. Nah, jika API tetap sama, transisi ke HTTP / 3 harus diputuskan menggunakan versi terbaru perpustakaan yang mendukung transportasi melalui QUIC di backend. Benar, untuk waktu yang lama Anda masih harus mundur ke versi HTTP yang lebih lama, karena Internet sekarang tidak siap untuk beralih penuh ke UDP.
Siapa yang sudah mendukung
Berikut adalah
daftar implementasi QUIC yang ada. Meskipun tidak memiliki standar, daftar ini tidak buruk.
Saat ini tidak ada browser yang mendukung QUIC di rilis. Baru-baru ini ada informasi bahwa Chrome menyertakan dukungan HTTP / 3, tetapi sejauh ini hanya di Canary.
Dari backend, HTTP / 3 hanya mendukung
Caddy dan
Cloudflare , tetapi sejauh ini secara eksperimental. NGINX
mengumumkan pada akhir musim semi 2019 bahwa mereka telah mulai bekerja dengan dukungan HTTP / 3, tetapi belum menyelesaikannya.
Apa masalahnya?
Kita hidup di dunia nyata, di mana tidak satu pun teknologi besar dapat pergi ke massa tanpa menemui perlawanan, dan QUIC tidak terkecuali.
Yang terpenting, Anda perlu menjelaskan kepada browser bahwa “https: //” tidak lagi menjadi fakta yang mengarah ke port TCP ke-443. Mungkin tidak ada TCP sama sekali. Untuk melakukan ini, gunakan header Alt-Svc. Ini memungkinkan browser untuk diberitahu bahwa situs web ini juga tersedia pada protokol ini dan itu di alamat ini dan itu. Secara teori, ini harus bekerja seperti jam, tetapi dalam praktiknya, kami menemukan fakta bahwa UDP dapat, misalnya, dinonaktifkan pada firewall untuk menghindari serangan DDoS.
Tetapi bahkan jika UDP tidak dilarang, klien mungkin berada di belakang router NAT yang dikonfigurasi untuk mengadakan sesi TCP dengan alamat IP, seperti kami menggunakan UDP, di mana tidak ada sesi perangkat keras, NAT tidak akan menahan koneksi, dan sesi QUIC
akan selalu diakhiri .
Semua masalah ini terkait dengan fakta bahwa UDP sebelumnya tidak digunakan untuk mengirimkan konten Internet, dan produsen perangkat keras tidak dapat memperkirakan bahwa ini akan pernah terjadi. Dengan cara yang sama, admin belum mengerti cara mengkonfigurasi jaringan mereka untuk QUIC. Situasi ini perlahan akan berubah, dan, dalam hal apa pun, perubahan seperti itu akan memakan waktu lebih sedikit daripada pengenalan protokol layer transport baru.
Selain itu, seperti yang telah dijelaskan, QUIC sangat meningkatkan pemanfaatan prosesor. Daniel Stenberg memberi
peringkat pertumbuhan pada prosesor hingga tiga kali lipat.
Saat HTTP / 3 Datang
Mereka
ingin mengadopsi standar pada Mei 2020, tetapi mengingat bahwa dokumen yang dijadwalkan untuk Juli 2019 masih belum selesai, kita dapat mengatakan bahwa tanggal tersebut kemungkinan besar ditunda.
Ya, Google telah menggunakan implementasi GQUIC sejak 2013. Jika Anda melihat permintaan HTTP yang dikirim ke mesin pencari Google, Anda dapat melihat ini:
Kesimpulan
QUIC sekarang terlihat seperti teknologi yang agak kasar, tetapi sangat menjanjikan. Mempertimbangkan bahwa selama 20 tahun terakhir, semua optimisasi protokol transport layer terkait terutama dengan TCP, QUIC, yang dalam banyak kasus menang dalam kinerja, sekarang terlihat sangat bagus.
Namun, masih ada masalah yang belum terpecahkan yang harus ditangani dalam beberapa tahun ke depan. Proses mungkin tertunda karena fakta bahwa perangkat keras yang terlibat, yang tidak ada yang suka memperbarui, tetapi meskipun demikian semua masalah terlihat cukup dapat dipecahkan, dan cepat atau lambat kita semua akan memiliki HTTP / 3.
Masa depan tidak jauh!