Tiga setengah tahun telah berlalu sejak adopsi standar HTTP / 2: spesifikasi RFC 7540 diterbitkan pada Mei 2015, tetapi belum digunakan secara universal. Protokol telah diterapkan di semua browser sejak akhir 2015 , dan setelah tiga tahun hanya 31,2% dari 10 juta situs Internet paling populer yang mendukung HTTP / 2. Dari situs paling populer, Google, Youtube, Wikipedia, Twitter, Vk.com dan lainnya telah beralih ke sana.

Namun demikian, kemajuan tidak berhenti - dan pekerjaan sedang berlangsung pada versi HTTP / 3 berikutnya. Seperti diketahui sekarang, pengembang dari dua opsi alternatif telah mencapai kompatibilitas, dan protokol HTTP-over-QUIC sekarang mengubah namanya dan secara resmi disebut HTTP / 3 . Karenanya, dalam versi HTTP yang akan datang, transport TCP akan digantikan oleh QUIC.

Kebingungan dengan berbagai opsi QUIC

QUIC adalah pengganti TCP yang berfungsi di atas UDP. Awalnya, teknologi ini dibuat oleh para insinyur Google, seperti protokol SPDY sebelumnya, yang menjadi dasar HTTP / 2. Pada awalnya, QUIC disebut "HTTP / 2-encrypted-over-UDP".

Pengembangan QUIC kemudian ditransfer ke IETF untuk standardisasi. Di sini dibagi menjadi dua bagian: transportasi dan HTTP. Idenya adalah bahwa protokol transport juga dapat digunakan untuk mentransfer data lain, dan tidak hanya secara eksklusif untuk protokol HTTP atau seperti HTTP. Namun, namanya tetap sama: QUIC. Protokol transportasi dikembangkan oleh Kelompok Kerja QUIC dari Internet Engineering Council (IETF).

Pada saat yang sama, Google terus mengerjakan implementasinya sendiri - dan mengimplementasikannya di browser Chrome. Meskipun tes menunjukkan bahwa implementasi QUIC Google secara signifikan lebih buruk daripada TCP, jika jaringan tidak menjamin pengiriman paket .


Perbedaan kinerja antara QUIC dengan TCP (dalam persen) pada jaringan dengan 112 ms RTT dan 10 ms jitter, sumber


Perbedaan kinerja antara QUIC dengan TCP (dalam persen) pada jaringan dengan RTT 112 ms dan jitter 10 ms, yang mengubah urutan paket, sumber

Beberapa pengembang umumnya menyebut versi QUIC di UDP sebagai "eksperimen terliar" .

Perselisihan dalam versi dan penamaan QUIC dijelaskan oleh Daniel Stenberg, pengembang ikal utama di Mozilla yang telah mengikuti kisah ini sejak lama.

Menurutnya, nama-nama informal dari dua versi QUIC telah menyebar di kalangan pengembang, karena opsi dari IETF dan Google sangat berbeda dalam detail implementasi:

• iQUIC (versi IETF)
• gQUIC (versi Google)

Protokol untuk mengirim HTTP over iQUIC (versi IETF) telah lama disebut "hq" (HTTP-over-QUIC).

Secara umum, tidak ada nama mapan untuk versi yang berbeda. Pada seminar Workshop QUIC, Mike Bishop menakuti semua orang dengan slide seolah itu sebuah logo.


Geser dari presentasi Mike Bishop

Fasilitator lokakarya meminta Mike untuk tidak menunjukkannya lagi .

Namun, pada 7 November 2018, salah satu pengembang protokol terkemuka, Dmitry Tikhonov, mengumumkan bahwa LiteSpeed ​​Tech dan Facebook telah mencapai kompatibilitas protokol, dan sekarang pengembangan akan berlanjut di jalur yang sama.

Menggabungkan iQUIC dan gQUIC yang disebut HTTP / 3 pada bulan September diusulkan oleh Mark Nottingham, salah satu insinyur IETF yang paling berpengaruh, penulis bersama beberapa standar web. Menurutnya, ini akan membantu menghilangkan kebingungan antara transportasi QIUC dan pembungkus QUIC untuk HTTP.

Dengan demikian, HTTP / 3 adalah versi baru HTTP yang akan menggunakan transport QUIC .

Transportasi QUIC

Apa kelebihan protokol transport QUIC dari TCP? Ada banyak keuntungan, dan menurut Mark Nottingham sendiri, transisi dari TCP yang sudah ketinggalan zaman ke protokol baru tidak bisa dihindari, karena sekarang jelas bahwa TCP menderita masalah inefisiensi.

“Karena TCP adalah protokol pengiriman paket secara berurutan, hilangnya satu paket dapat mengganggu pengiriman paket selanjutnya dari buffer ke aplikasi. Dalam protokol multiplexing, ini dapat menyebabkan kerugian besar dalam kinerja, ” jelas Mark Nottingham. "QUIC sedang mencoba menyelesaikan masalah ini dengan membangun kembali semantik TCP secara efektif (bersama dengan beberapa aspek model aliran HTTP / 2) melalui UDP."



Selain mengalihkan sejumlah besar lalu lintas dari TCP ke UDP, Google QUIC (gQUIC) dan IETF QUIC (iQUIC) memerlukan enkripsi: QUIC yang tidak dienkripsi sama sekali tidak ada . iQUIC menggunakan TLS 1.3 untuk mengatur kunci sesi dan kemudian mengenkripsi setiap paket. Tetapi karena didasarkan pada UDP, banyak informasi sesi dan metadata yang dibuka di TCP dienkripsi dalam QUIC.

Dalam artikel "Masa Depan Protokol Internet," Mark Nottingham berbicara tentang peningkatan keamanan yang signifikan dengan beralih ke QUIC:

Sebenarnya, "header pendek" saat ini iQUIC - yang digunakan untuk semua paket kecuali untuk jabat tangan - hanya memberikan nomor paket, pengenal koneksi opsional dan byte status, yang diperlukan untuk proses seperti mengubah kunci enkripsi dan tipe paket (yang juga dapat dienkripsi). Segala sesuatu yang lain dienkripsi - termasuk paket ACK, yang sangat meningkatkan bar untuk serangan dengan analisis lalu lintas .

Selain itu, menjadi tidak mungkin untuk mengevaluasi RTT dan packet loss secara pasif hanya dengan memonitor koneksi; tidak ada informasi yang cukup untuk ini.

Kurangnya keterlihatan menyebabkan keprihatinan serius di antara beberapa perwakilan dari komunitas operator telekomunikasi. Mereka mengatakan bahwa pengukuran pasif seperti itu sangat penting untuk debugging dan menganalisis jaringan mereka.

Salah satu saran untuk mengatasi masalah ini adalah pengenalan bit spin . Ini sedikit di header yang mengubah nilainya sekali pada round-trip, sehingga pengamat dapat mengevaluasi RTT. Karena tidak terikat dengan keadaan aplikasi, itu tidak boleh menghasilkan informasi tentang titik akhir, kecuali untuk perkiraan perkiraan lokasi jaringan.

Mungkin adopsi standar QUIC akan terjadi lebih awal jika Google tidak terburu-buru mengimplementasikan implementasinya di browser Chrome, jadi sekarang versi eksklusif akun iQUIC untuk lebih dari 7% lalu lintas Internet.

Namun demikian, kemajuan tidak dapat dihindari - dan di tahun-tahun mendatang, standardisasi dan implementasi luas berbagai protokol generasi baru, termasuk HTTP / 3 pada transportasi QUIC, pasti akan terus berlanjut.

---