Selama lebih dari 20 tahun kami telah melihat halaman web menggunakan protokol HTTP. Sebagian besar pengguna bahkan tidak memikirkan apa itu dan bagaimana cara kerjanya. Yang lain tahu bahwa di suatu tempat di bawah HTTP ada TLS, dan di bawahnya ada TCP, di bawahnya ada IP, dan seterusnya. Dan yang lain lagi - bidat - percaya bahwa TCP sudah ketinggalan zaman, mereka menginginkan sesuatu yang lebih cepat, lebih andal, dan aman. Namun dalam upaya mereka untuk menemukan protokol ideal baru, mereka telah kembali ke teknologi tahun 80an dan mencoba membangun dunia baru yang berani di atasnya.
Sedikit sejarah: HTTP/1.1
Pada tahun 1997, protokol pertukaran informasi teks HTTP versi 1.1 memperoleh RFC-nya sendiri. Pada saat itu, protokol tersebut telah digunakan oleh browser selama beberapa tahun, dan standar baru tersebut bertahan selama lima belas tahun lagi. Protokol ini hanya bekerja berdasarkan prinsip permintaan-respons dan dimaksudkan terutama untuk transmisi informasi teks.
HTTP dirancang untuk berjalan di atas protokol TCP, memastikan bahwa paket terkirim dengan andal ke tujuannya. TCP bekerja dengan membangun dan memelihara koneksi yang andal antara titik akhir dan membagi lalu lintas menjadi beberapa segmen. Segmen memiliki nomor seri dan checksumnya sendiri. Jika tiba-tiba salah satu segmen tidak sampai atau datang dengan checksum yang salah, maka transmisi akan terhenti hingga segmen yang hilang tersebut pulih.
Di HTTP/1.0, koneksi TCP ditutup setelah setiap permintaan. Ini sangat sia-sia, karena... membuat koneksi TCP (3-Way-Handshake) adalah proses yang lambat. HTTP/1.1 memperkenalkan mekanisme keep-alive, yang memungkinkan Anda menggunakan kembali satu koneksi untuk beberapa permintaan. Namun, karena hal ini dapat dengan mudah menjadi hambatan, berbagai implementasi HTTP/1.1 memungkinkan beberapa koneksi TCP dibuka ke host yang sama. Misalnya, Chrome dan Firefox versi terbaru mengizinkan hingga enam koneksi.
Enkripsi juga seharusnya diserahkan kepada protokol lain, dan untuk ini, protokol TLS digunakan melalui TCP, yang secara andal melindungi data, namun semakin meningkatkan waktu yang diperlukan untuk membuat koneksi. Hasilnya, proses jabat tangan mulai terlihat seperti ini:
Ilustrasi awan suar
Jadi HTTP/1.1 mempunyai sejumlah masalah:
- Pengaturan koneksi lambat.
- Data dikirimkan dalam bentuk teks, yang berarti transmisi gambar, video, dan informasi non-teks lainnya tidak efektif.
- Satu koneksi TCP digunakan untuk satu permintaan, yang berarti permintaan lain harus menemukan koneksi lain atau menunggu hingga permintaan saat ini melepaskannya.
- Hanya model tarik yang didukung. Tidak ada standar tentang server-push.
- Judul dikirimkan dalam teks.
Jika server-push setidaknya diimplementasikan menggunakan protokol WebSocket, maka masalah lainnya harus ditangani dengan lebih radikal.
Sedikit modernitas: HTTP/2
Pada tahun 2012, Google mulai mengerjakan protokol SPDY (diucapkan βspeedyβ). Protokol ini dirancang untuk memecahkan masalah utama HTTP/1.1 dan pada saat yang sama diharapkan menjaga kompatibilitas ke belakang. Pada tahun 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-push out of the box (tanpa WebSocket).
Protokol ini merupakan langkah maju yang besar. Dia dengan kuat dan tidak memerlukan pembuatan beberapa koneksi TCP: semua permintaan ke satu host dimultipleks menjadi satu. Artinya, dalam satu koneksi terdapat beberapa aliran yang disebut, yang masing-masing memiliki ID sendiri. Bonusnya adalah server-push dalam kotak.
Namun, multiplexing menimbulkan masalah utama lainnya. Bayangkan kita mengeksekusi 5 permintaan secara asinkron ke satu server. Saat menggunakan HTTP/2, semua permintaan ini akan dilakukan dalam koneksi TCP yang sama, yang berarti jika salah satu segmen permintaan hilang atau diterima secara tidak benar, transmisi semua permintaan dan respons akan berhenti hingga segmen yang hilang tersebut hilang. pulih. Jelasnya, semakin buruk kualitas koneksi, semakin lambat kerja HTTP/2. , dalam kondisi di mana paket yang hilang mencapai 2% dari seluruh paket, kinerja HTTP/1.1 di browser lebih baik daripada HTTP/2 karena ia membuka 6 koneksi, bukan satu.
Masalah ini disebut "pemblokiran head-of-line" dan sayangnya tidak dapat diselesaikan saat menggunakan TCP.
Ilustrasi oleh Daniel Steinberg
Hasilnya, para pengembang standar HTTP/2 melakukan pekerjaan dengan baik dan melakukan hampir semua hal yang dapat dilakukan pada lapisan aplikasi model OSI. Saatnya untuk turun ke lapisan transport dan menciptakan protokol transport baru.
Kami membutuhkan protokol baru: UDP vs TCP
Dengan cepat menjadi jelas bahwa penerapan protokol lapisan transport yang benar-benar baru adalah tugas yang mustahil dalam kenyataan saat ini. Faktanya adalah perangkat keras atau kotak tengah (router, firewall, server NAT...) mengetahui tentang lapisan transport, dan mengajari mereka sesuatu yang baru adalah tugas yang sangat sulit. Selain itu, dukungan untuk protokol transport sudah tertanam di dalam kernel sistem operasi, dan kernel juga tidak terlalu bersedia untuk berubah.
Dan di sini seseorang dapat mengangkat tangan dan berkata, βKami, tentu saja, akan menciptakan HTTP/3 baru dengan preferensi dan pelacur, tetapi akan memakan waktu 10-15 tahun untuk diimplementasikan (setelah sekitar waktu ini sebagian besar perangkat keras akan diganti),β tapi ada satu lagi yang tidak begitu. Pilihan yang jelas adalah menggunakan protokol UDP. Ya, ya, protokol yang sama yang kami gunakan untuk membuang file melalui LAN di akhir tahun sembilan puluhan dan awal tahun XNUMXan. Hampir semua perangkat keras saat ini dapat bekerja dengannya.
Apa kelebihan UDP dibandingkan TCP? Pertama-tama, kami tidak memiliki sesi lapisan transport yang diketahui oleh perangkat keras. Hal ini memungkinkan kami menentukan sendiri sesi di titik akhir dan menyelesaikan konflik di sana. Artinya, kita tidak dibatasi pada satu atau beberapa sesi (seperti pada TCP), tetapi dapat membuat sesi sebanyak yang kita butuhkan. Kedua, transmisi data melalui UDP lebih cepat dibandingkan melalui TCP. Jadi, secara teori, kita dapat menembus batas kecepatan yang saat ini dicapai di HTTP/2.
Namun, UDP tidak menjamin transmisi data yang andal. Faktanya, kami hanya mengirimkan paket, berharap pihak lain akan menerimanya. Belum menerima? Yah, tidak beruntung... Ini cukup untuk mentransmisikan video untuk orang dewasa, tetapi untuk hal yang lebih serius Anda memerlukan keandalan, yang berarti Anda harus membungkus sesuatu yang lain di atas UDP.
Seperti halnya HTTP/2, upaya pembuatan protokol baru dimulai di Google pada tahun 2012, yaitu sekitar waktu yang sama dengan dimulainya pengerjaan SPDY. Pada tahun 2013, Jim Roskind memperkenalkannya kepada masyarakat umum , dan pada tahun 2015, Internet Draft diperkenalkan untuk standardisasi di IETF. Bahkan saat itu, protokol yang dikembangkan oleh Roskind di Google sangat berbeda dengan standarnya, sehingga versi Google mulai disebut gQUIC.
Apa itu QUIC
Pertama, seperti yang telah disebutkan, ini adalah pembungkus UDP. Koneksi QUIC muncul di atas UDP, di mana, dengan analogi dengan HTTP/2, beberapa aliran dapat ada. Aliran ini hanya ada di titik akhir dan dilayani secara independen. Jika terjadi kehilangan paket pada satu aliran, maka tidak akan berdampak pada aliran lainnya.
Ilustrasi oleh Daniel Steinberg
Kedua, enkripsi tidak lagi diterapkan pada tingkat yang terpisah, tetapi sudah termasuk dalam protokol. Hal ini memungkinkan Anda membuat koneksi dan bertukar kunci publik dalam satu jabat tangan, dan juga memungkinkan Anda menggunakan mekanisme jabat tangan 0-RTT yang cerdas dan menghindari penundaan jabat tangan sama sekali. Selain itu, sekarang dimungkinkan untuk mengenkripsi paket data individual. Hal ini memungkinkan Anda untuk tidak menunggu selesainya penerimaan data dari aliran, tetapi untuk mendekripsi paket yang diterima secara mandiri. Mode operasi ini umumnya tidak mungkin dilakukan di TCP, karena TLS dan TCP bekerja secara independen satu sama lain, dan TLS tidak dapat mengetahui bagian mana dari data TCP yang akan dipotong. Oleh karena itu, dia tidak dapat mempersiapkan segmennya agar sesuai dengan segmen TCP satu lawan satu dan dapat didekripsi secara mandiri. Semua peningkatan ini memungkinkan QUIC mengurangi latensi dibandingkan dengan TCP.
Ketiga, konsep streaming ringan memungkinkan Anda memisahkan koneksi dari alamat IP klien. Ini penting, misalnya, ketika klien berpindah dari satu titik akses Wi-Fi ke titik akses Wi-Fi lainnya, sehingga mengubah IP-nya. Dalam hal ini, saat menggunakan TCP, proses yang panjang terjadi di mana waktu koneksi TCP yang ada habis dan koneksi baru dibuat dari IP baru. Dalam kasus QUIC, klien terus mengirim paket ke server dari IP baru dengan ID aliran lama. Karena ID aliran sekarang unik dan tidak digunakan kembali; server memahami bahwa klien telah mengubah IP, mengirim ulang paket yang hilang dan melanjutkan komunikasi di alamat baru.
Keempat, QUIC diimplementasikan pada level aplikasi, bukan pada level sistem operasi. Ini, di satu sisi, memungkinkan Anda dengan cepat membuat perubahan pada protokol, karena Untuk mendapatkan pembaruan, Anda hanya perlu memperbarui perpustakaan, daripada menunggu versi OS baru. Di sisi lain, hal ini menyebabkan peningkatan tajam dalam konsumsi prosesor.
Dan yang terakhir, berita utama. Kompresi header adalah salah satu hal yang membedakan QUIC dan gQUIC. Saya tidak melihat gunanya menghabiskan banyak waktu untuk ini, saya hanya akan mengatakan bahwa dalam versi yang diajukan untuk standarisasi, kompresi header dibuat semirip mungkin dengan kompresi header di HTTP/2. Anda dapat membaca lebih lanjut .
Seberapa cepatnya?
Itu pertanyaan yang sulit. Faktanya, sampai kita mempunyai standar, tidak ada sesuatu pun yang istimewa untuk diukur. Mungkin satu-satunya statistik yang kami miliki adalah statistik dari Google, yang telah menggunakan gQUIC sejak tahun 2013 dan pada tahun 2016 bahwa sekitar 90% lalu lintas yang masuk ke server mereka dari browser Chrome kini menggunakan QUIC. Dalam presentasi yang sama, mereka melaporkan bahwa halaman dimuat sekitar 5% lebih cepat melalui gQUIC dan 30% lebih sedikit gangguan dalam streaming video dibandingkan dengan TCP.
Pada tahun 2017, sekelompok peneliti yang dipimpin oleh Arash Molavi Kakhki menerbitkan untuk mempelajari kinerja gQUIC dibandingkan dengan TCP.
Studi ini mengungkapkan beberapa kelemahan gQUIC, seperti ketidakstabilan terhadap pencampuran paket jaringan, keserakahan (unfairness) terhadap bandwidth saluran dan lambatnya transfer objek kecil (hingga 10 kb). Namun hal terakhir ini dapat dikompensasikan dengan menggunakan 0-RTT. Dalam semua kasus lain yang diteliti, gQUIC menunjukkan peningkatan kecepatan dibandingkan dengan TCP. Sulit untuk membicarakan angka-angka tertentu di sini. Lebih baik membaca ΠΈΠ»ΠΈ .
Di sini harus dikatakan bahwa data ini khusus tentang gQUIC, dan tidak relevan dengan standar yang sedang dikembangkan. Apa yang akan terjadi pada QUIC: masih dirahasiakan, namun ada harapan bahwa kelemahan yang teridentifikasi di gQUIC akan diperhitungkan dan diperbaiki.
Sedikit masa depan: bagaimana dengan HTTP/3?
Tapi di sini semuanya jelas: API tidak akan berubah dengan cara apa pun. Semuanya akan tetap sama seperti di HTTP/2. Nah, jika API tetap sama, transisi ke HTTP/3 harus diselesaikan dengan menggunakan versi baru perpustakaan di backend yang mendukung transportasi QUIC. Benar, Anda harus tetap menggunakan versi HTTP yang lama untuk beberapa waktu, karena Internet saat ini belum siap untuk transisi lengkap ke UDP.
Siapa yang sudah mendukung
di sini adalah implementasi QUIC yang ada. Meskipun kurangnya standar, daftarnya lumayan.
Saat ini tidak ada browser yang mendukung QUIC dalam rilis produksi. Baru-baru ini ada informasi bahwa dukungan HTTP/3 disertakan di Chrome, namun sejauh ini hanya di Canary.
Dari backend, HTTP/3 hanya mendukung ΠΈ , tapi masih eksperimental. NGINX di akhir musim semi 2019 , bahwa mereka mulai mengerjakan dukungan HTTP/3, namun belum menyelesaikannya.
Apa masalahnya?
Anda dan saya hidup di dunia nyata, di mana tidak ada teknologi besar yang dapat menjangkau masyarakat luas tanpa menemui hambatan, dan QUIC tidak terkecuali.
Yang paling penting adalah Anda perlu menjelaskan kepada browser bahwa "https://" bukan lagi fakta yang mengarah ke port TCP 443. Mungkin tidak ada TCP sama sekali. Header Alt-Svc digunakan untuk ini. Ini memungkinkan Anda memberi tahu browser bahwa situs web ini juga tersedia pada protokol ini dan itu di alamat ini dan itu. Secara teori, ini seharusnya berfungsi dengan baik, tetapi dalam praktiknya kita akan menemukan fakta bahwa UDP dapat, misalnya, dilarang di firewall untuk menghindari serangan DDoS.
Namun meskipun UDP tidak dilarang, klien mungkin berada di belakang router NAT yang dikonfigurasi untuk mengadakan sesi TCP berdasarkan alamat IP, dan sejak itu kami menggunakan UDP, yang tidak memiliki sesi perangkat keras, NAT tidak akan menahan koneksi, dan sesi QUIC .
Semua masalah ini disebabkan oleh fakta bahwa UDP sebelumnya tidak digunakan untuk mengirimkan konten Internet, dan produsen perangkat keras tidak dapat memperkirakan hal ini akan terjadi. Demikian pula, administrator belum benar-benar memahami cara mengkonfigurasi jaringan mereka dengan benar agar QUIC dapat berfungsi. Situasi ini akan berubah secara bertahap, dan, bagaimanapun juga, perubahan tersebut akan memakan waktu lebih sedikit dibandingkan penerapan protokol lapisan transport baru.
Selain itu, seperti yang telah dijelaskan, QUIC sangat meningkatkan penggunaan CPU. Daniel Stenberg pertumbuhan prosesor hingga tiga kali lipat.
Kapan HTTP/3 akan tiba?
Standar paling lambat bulan Mei 2020, namun mengingat dokumen yang dijadwalkan pada bulan Juli 2019 masih belum selesai, kami dapat mengatakan bahwa tanggal tersebut kemungkinan besar akan diundur.
Ya, Google telah menggunakan implementasi gQUIC sejak 2013. Jika Anda melihat permintaan HTTP yang dikirimkan ke mesin pencari Google, Anda akan melihat ini:
Temuan
QUIC sekarang tampak seperti teknologi yang agak kasar, namun sangat menjanjikan. Mengingat bahwa selama 20 tahun terakhir, semua optimalisasi protokol lapisan transport terutama menyangkut TCP, QUIC, yang dalam banyak kasus memiliki kinerja terbaik, sudah terlihat sangat bagus.
Namun, masih ada permasalahan yang belum terselesaikan yang harus diselesaikan dalam beberapa tahun ke depan. Prosesnya mungkin tertunda karena ada perangkat keras yang terlibat, yang tidak suka diperbarui oleh siapa pun, namun demikian, semua masalah tampaknya dapat diselesaikan, dan cepat atau lambat kita semua akan memiliki HTTP/3.
Masa depan sudah dekat!
Sumber: www.habr.com