Selama lebih daripada 20 tahun kami telah melihat halaman web menggunakan protokol HTTP. Kebanyakan pengguna tidak memikirkan apa itu dan cara ia berfungsi. Orang lain tahu bahawa di suatu tempat di bawah HTTP terdapat TLS, dan di bawahnya adalah TCP, di bawahnya adalah IP, dan seterusnya. Dan yang lain lagi - bidaah - percaya bahawa TCP adalah perkara yang sudah lama mereka mahukan sesuatu yang lebih cepat, lebih dipercayai dan selamat. Tetapi dalam percubaan mereka untuk mencipta protokol ideal baharu, mereka telah kembali kepada teknologi tahun 80-an dan cuba membina dunia baharu mereka yang berani di atasnya.
Sedikit sejarah: HTTP/1.1
Pada tahun 1997, protokol pertukaran maklumat teks HTTP versi 1.1 memperoleh RFC sendiri. Pada masa itu, protokol telah digunakan oleh penyemak imbas selama beberapa tahun, dan standard baharu itu bertahan lima belas lagi. Protokol berfungsi hanya pada prinsip permintaan-tindak balas dan bertujuan terutamanya untuk penghantaran maklumat teks.
HTTP direka bentuk untuk berjalan di atas protokol TCP, memastikan bahawa paket dihantar dengan pasti ke destinasi mereka. TCP berfungsi dengan mewujudkan dan mengekalkan sambungan yang boleh dipercayai antara titik akhir dan memecahkan trafik kepada segmen. Segmen mempunyai nombor siri dan jumlah semak sendiri. Jika tiba-tiba salah satu segmen tidak tiba atau tiba dengan jumlah semak yang salah, maka penghantaran akan berhenti sehingga segmen yang hilang dipulihkan.
Dalam HTTP/1.0, sambungan TCP telah ditutup selepas setiap permintaan. Ini sangat membazir, kerana... mewujudkan sambungan TCP (3-Way-Handshake) adalah proses yang perlahan. HTTP/1.1 memperkenalkan mekanisme keep-alive, yang membolehkan anda menggunakan semula satu sambungan untuk berbilang permintaan. Walau bagaimanapun, memandangkan ia boleh menjadi halangan dengan mudah, pelbagai pelaksanaan HTTP/1.1 membenarkan berbilang sambungan TCP dibuka kepada hos yang sama. Contohnya, Chrome dan versi terbaru Firefox membenarkan sehingga enam sambungan.
Penyulitan juga sepatutnya diserahkan kepada protokol lain, dan untuk ini, protokol TLS digunakan melalui TCP, yang melindungi data dengan pasti, tetapi meningkatkan lagi masa yang diperlukan untuk mewujudkan sambungan. Akibatnya, proses berjabat tangan mula kelihatan seperti ini:
Ilustrasi Cloudflare
Oleh itu HTTP/1.1 mempunyai beberapa masalah:
- Persediaan sambungan perlahan.
- Data dihantar dalam bentuk teks, yang bermaksud penghantaran gambar, video dan maklumat bukan teks lain adalah tidak berkesan.
- Satu sambungan TCP digunakan untuk satu permintaan, yang bermaksud permintaan lain mesti sama ada mencari sambungan lain atau menunggu sehingga permintaan semasa mengeluarkannya.
- Hanya model tarik disokong. Tiada apa-apa dalam standard tentang server-push.
- Tajuk dihantar dalam teks.
Jika server-push sekurang-kurangnya dilaksanakan menggunakan protokol WebSocket, maka masalah yang selebihnya terpaksa ditangani dengan lebih radikal.
Sedikit kemodenan: HTTP/2
Pada tahun 2012, Google mula mengusahakan protokol SPDY (disebut "cepat"). Protokol ini direka untuk menyelesaikan masalah utama HTTP/1.1 dan pada masa yang sama sepatutnya mengekalkan keserasian ke belakang. Pada tahun 2015, kumpulan kerja IETF memperkenalkan spesifikasi HTTP/2 berdasarkan protokol SPDY. Berikut ialah perbezaan dalam HTTP/2:
- Pensirian binari.
- Memultiplekskan berbilang permintaan HTTP ke dalam satu sambungan TCP.
- Tolak pelayan keluar dari kotak (tanpa WebSocket).
Protokol itu adalah satu langkah besar ke hadapan. Dia dengan kuat dan tidak memerlukan penciptaan berbilang sambungan TCP: semua permintaan kepada satu hos dimultiplekskan menjadi satu. Iaitu, dalam satu sambungan terdapat beberapa aliran yang dipanggil, masing-masing mempunyai ID sendiri. Bonusnya ialah tolakan pelayan berkotak-kotak.
Walau bagaimanapun, pemultipleksan membawa kepada masalah utama yang lain. Bayangkan bahawa kami sedang melaksanakan 5 permintaan secara tidak segerak kepada satu pelayan. Apabila menggunakan HTTP/2, semua permintaan ini akan dijalankan dalam sambungan TCP yang sama, yang bermaksud bahawa jika salah satu daripada segmen mana-mana permintaan hilang atau diterima secara tidak betul, penghantaran semua permintaan dan respons akan berhenti sehingga segmen yang hilang itu dipulihkan. Jelas sekali, semakin teruk kualiti sambungan, semakin perlahan HTTP/2 berfungsi. , dalam keadaan di mana paket yang hilang menyumbang 2% daripada semua paket, HTTP/1.1 dalam penyemak imbas berprestasi lebih baik daripada HTTP/2 disebabkan fakta bahawa ia membuka 6 sambungan berbanding satu.
Masalah ini dipanggil "penyekatan ketua baris" dan, malangnya, ia tidak dapat diselesaikan apabila menggunakan TCP.
Ilustrasi oleh Daniel Steinberg
Akibatnya, pembangun standard HTTP/2 melakukan kerja yang hebat dan melakukan hampir semua perkara yang boleh dilakukan pada lapisan aplikasi model OSI. Sudah tiba masanya untuk turun ke lapisan pengangkutan dan mencipta protokol pengangkutan baharu.
Kami memerlukan protokol baharu: UDP vs TCP
Dengan cepat ia menjadi jelas bahawa melaksanakan protokol lapisan pengangkutan yang benar-benar baharu adalah tugas yang mustahil dalam realiti hari ini. Hakikatnya ialah perkakasan atau kotak tengah (penghala, tembok api, pelayan NAT...) mengetahui tentang lapisan pengangkutan, dan mengajar mereka sesuatu yang baharu adalah tugas yang amat sukar. Di samping itu, sokongan untuk protokol pengangkutan dibina ke dalam kernel sistem pengendalian, dan kernel juga tidak begitu bersedia untuk berubah.
Dan di sini seseorang boleh mengangkat tangan dan berkata "Kami, sudah tentu, akan mencipta HTTP/3 baharu dengan keutamaan dan penghormatan, tetapi ia akan mengambil masa 10-15 tahun untuk dilaksanakan (selepas kira-kira masa ini kebanyakan perkakasan akan digantikan)," tetapi terdapat satu lagi yang tidak begitu Pilihan yang jelas ialah menggunakan protokol UDP. Ya, ya, protokol yang sama yang kami gunakan untuk membuang fail melalui LAN pada akhir tahun sembilan puluhan dan awal XNUMX-an. Hampir semua perkakasan hari ini boleh berfungsi dengannya.
Apakah kelebihan UDP berbanding TCP? Pertama sekali, kami tidak mempunyai sesi lapisan pengangkutan yang diketahui oleh perkakasan. Ini membolehkan kami menentukan sendiri sesi pada titik akhir dan menyelesaikan konflik di sana. Iaitu, kami tidak terhad kepada satu atau beberapa sesi (seperti dalam TCP), tetapi boleh mencipta seberapa banyak sesi yang kami perlukan. Kedua, penghantaran data melalui UDP adalah lebih pantas daripada melalui TCP. Oleh itu, secara teori, kita boleh menembusi siling kelajuan semasa yang dicapai dalam HTTP/2.
Walau bagaimanapun, UDP tidak menjamin penghantaran data yang boleh dipercayai. Sebenarnya, kami hanya menghantar paket, dengan harapan bahawa hujung yang lain akan menerimanya. Belum terima? Nasib baik... Ini sudah cukup untuk menghantar video untuk orang dewasa, tetapi untuk perkara yang lebih serius anda memerlukan kebolehpercayaan, yang bermaksud anda perlu membungkus sesuatu yang lain di atas UDP.
Seperti HTTP/2, kerja untuk mencipta protokol baharu bermula di Google pada tahun 2012, iaitu, pada masa yang sama dengan kerja pada SPDY bermula. Pada tahun 2013, Jim Roskind membentangkan kepada orang ramai , dan sudah pada tahun 2015 Draf Internet telah diperkenalkan untuk penyeragaman dalam IETF. Pada masa itu, protokol yang dibangunkan oleh Roskind di Google sangat berbeza daripada standard, jadi versi Google mula dipanggil gQUIC.
Apa itu QUIC
Pertama, seperti yang telah disebutkan, ini adalah pembalut atas UDP. Sambungan QUIC meningkat di atas UDP, di mana, dengan analogi dengan HTTP/2, beberapa aliran boleh wujud. Strim ini hanya wujud pada titik akhir dan disajikan secara bebas. Jika kehilangan paket berlaku dalam satu aliran, ia tidak akan menjejaskan yang lain.
Ilustrasi oleh Daniel Steinberg
Kedua, penyulitan tidak lagi dilaksanakan pada tahap yang berasingan, tetapi dimasukkan dalam protokol. Ini membolehkan anda membuat sambungan dan menukar kunci awam dalam satu jabat tangan, dan juga membolehkan anda menggunakan mekanisme jabat tangan 0-RTT yang bijak dan mengelakkan kelewatan jabat tangan sama sekali. Di samping itu, kini mungkin untuk menyulitkan paket data individu. Ini membolehkan anda tidak menunggu selesai menerima data daripada aliran, tetapi untuk menyahsulit paket yang diterima secara bebas. Mod operasi ini secara amnya mustahil dalam TCP, kerana TLS dan TCP berfungsi secara berasingan antara satu sama lain, dan TLS tidak dapat mengetahui bahagian mana data TCP akan dicincang. Oleh itu, dia tidak dapat menyediakan segmennya supaya ia masuk ke dalam segmen TCP satu ke satu dan boleh dinyahsulit secara bebas. Semua penambahbaikan ini membolehkan QUIC mengurangkan kependaman berbanding dengan TCP.
Ketiga, konsep penstriman cahaya membolehkan anda memisahkan sambungan daripada alamat IP pelanggan. Ini penting, sebagai contoh, apabila pelanggan beralih dari satu titik akses Wi-Fi ke yang lain, menukar IPnya. Dalam kes ini, apabila menggunakan TCP, proses yang panjang berlaku semasa sambungan TCP sedia ada tamat masa dan sambungan baharu dibuat daripada IP baharu. Dalam kes QUIC, pelanggan hanya terus menghantar paket ke pelayan daripada IP baharu dengan ID aliran lama. Kerana ID aliran kini unik dan tidak digunakan semula pelayan memahami bahawa klien telah menukar IP, menghantar semula paket yang hilang dan meneruskan komunikasi di alamat baharu.
Keempat, QUIC dilaksanakan pada peringkat aplikasi, bukan peringkat sistem pengendalian. Ini, dalam satu tangan, membolehkan anda dengan cepat membuat perubahan pada protokol, kerana Untuk mendapatkan kemas kini, anda hanya perlu mengemas kini perpustakaan, bukannya menunggu versi OS baharu. Sebaliknya, ini membawa kepada peningkatan yang kukuh dalam penggunaan pemproses.
Dan akhirnya, tajuk utama. Mampatan pengepala ialah salah satu perkara yang berbeza antara QUIC dan gQUIC. Saya tidak nampak gunanya menumpukan banyak masa untuk perkara ini, saya cuma akan mengatakan bahawa dalam versi yang diserahkan untuk penyeragaman, pemampatan pengepala dibuat sama mungkin dengan pemampatan pengepala dalam HTTP/2. Anda boleh membaca lebih lanjut .
Berapa cepatkah ia?
Ia adalah soalan yang sukar. Hakikatnya sehingga kita mempunyai standard, tiada apa yang istimewa untuk diukur. Mungkin satu-satunya statistik yang kami ada ialah statistik daripada Google, yang telah menggunakan gQUIC sejak 2013 dan pada 2016 bahawa kira-kira 90% daripada trafik yang pergi ke pelayan mereka daripada penyemak imbas Chrome kini menggunakan QUIC. Dalam pembentangan yang sama, mereka melaporkan bahawa halaman dimuatkan kira-kira 5% lebih cepat melalui gQUIC dan terdapat 30% kurang gagap dalam penstriman video berbanding TCP.
Pada 2017, sekumpulan penyelidik yang diketuai oleh Arash Molavi Kakhki menerbitkan untuk mengkaji prestasi gQUIC berbanding TCP.
Kajian itu mendedahkan beberapa kelemahan gQUIC, seperti ketidakstabilan pada pencampuran paket rangkaian, ketamakan (ketidakadilan) untuk menyalurkan lebar jalur dan pemindahan objek kecil (sehingga 10 kb) yang lebih perlahan. Yang terakhir, bagaimanapun, boleh diberi pampasan dengan menggunakan 0-RTT. Dalam semua kes lain yang dikaji, gQUIC menunjukkan peningkatan dalam kelajuan berbanding dengan TCP. Sukar untuk bercakap tentang nombor tertentu di sini. Lebih baik membaca atau .
Di sini mesti dikatakan bahawa data ini khusus mengenai gQUIC, dan ia tidak relevan untuk standard yang dibangunkan. Apa yang akan berlaku untuk QUIC: ia masih rahsia, tetapi ada harapan bahawa kelemahan yang dikenal pasti dalam gQUIC akan diambil kira dan diperbetulkan.
Sedikit masa depan: bagaimana dengan HTTP/3?
Tetapi di sini semuanya jelas: API tidak akan berubah dalam apa jua cara. Semuanya akan kekal sama seperti dalam HTTP/2. Nah, jika API kekal sama, peralihan kepada HTTP/3 perlu diselesaikan dengan menggunakan versi baharu perpustakaan pada bahagian belakang yang menyokong pengangkutan QUIC. Benar, anda perlu menyimpan sandaran pada versi lama HTTP untuk beberapa lama, kerana Internet pada masa ini tidak bersedia untuk peralihan lengkap kepada UDP.
Siapa yang sudah menyokong
di sini ialah pelaksanaan QUIC sedia ada. Walaupun kekurangan standard, senarai itu tidak buruk.
Tiada penyemak imbas pada masa ini menyokong QUIC dalam keluaran pengeluaran. Baru-baru ini terdapat maklumat bahawa sokongan untuk HTTP/3 disertakan dalam Chrome, tetapi setakat ini hanya dalam Canary.
Daripada bahagian belakang, HTTP/3 hanya menyokong и , tetapi masih eksperimen. NGINX pada penghujung musim bunga 2019 , bahawa mereka mula bekerja pada sokongan HTTP/3, tetapi belum menyelesaikannya lagi.
Apakah masalahnya?
Anda dan saya hidup di dunia nyata, di mana tiada teknologi besar yang boleh menjangkau orang ramai tanpa menghadapi rintangan, dan QUIC tidak terkecuali.
Perkara yang paling penting ialah anda perlu menjelaskan kepada penyemak imbas bahawa "https://" bukan lagi fakta bahawa ia membawa kepada port TCP 443. Mungkin tiada TCP sama sekali. Pengepala Alt-Svc digunakan untuk ini. Ia membolehkan anda memberitahu penyemak imbas bahawa laman web ini juga tersedia pada protokol itu dan itu di alamat itu dan itu. Secara teori, ini sepatutnya berfungsi seperti azimat, tetapi dalam praktiknya kita akan menemui fakta bahawa UDP boleh, sebagai contoh, dilarang pada tembok api untuk mengelakkan serangan DDoS.
Tetapi walaupun UDP tidak dilarang, pelanggan mungkin berada di belakang penghala NAT yang dikonfigurasikan untuk mengadakan sesi TCP melalui alamat IP, dan sejak kami menggunakan UDP, yang tidak mempunyai sesi perkakasan, NAT tidak akan memegang sambungan, dan sesi QUIC .
Semua masalah ini disebabkan oleh fakta bahawa UDP sebelum ini tidak pernah digunakan untuk menghantar kandungan Internet, dan pengeluar perkakasan tidak dapat menjangka perkara ini akan berlaku. Dengan cara yang sama, pentadbir belum benar-benar memahami cara mengkonfigurasi rangkaian mereka dengan betul agar QUIC berfungsi. Keadaan ini akan berubah secara beransur-ansur, dan, dalam apa jua keadaan, perubahan tersebut akan mengambil masa kurang daripada pelaksanaan protokol lapisan pengangkutan baharu.
Selain itu, seperti yang telah diterangkan, QUIC sangat meningkatkan penggunaan CPU. Daniel Stenberg pertumbuhan pemproses sehingga tiga kali ganda.
Bilakah HTTP/3 akan tiba?
Standard menjelang Mei 2020, tetapi memandangkan dokumen yang dijadualkan pada Julai 2019 masih belum selesai pada masa ini, kita boleh mengatakan bahawa tarikh itu berkemungkinan besar akan ditarik balik.
Nah, Google telah menggunakan pelaksanaan gQUICnya sejak 2013. Jika anda melihat permintaan HTTP yang dihantar ke enjin carian Google, anda akan melihat ini:
Penemuan
QUIC kini kelihatan seperti teknologi yang agak kasar, tetapi sangat menjanjikan. Memandangkan sepanjang 20 tahun yang lalu, semua pengoptimuman protokol lapisan pengangkutan terutamanya melibatkan TCP, QUIC, yang dalam kebanyakan kes mempunyai prestasi terbaik, sudah kelihatan sangat baik.
Walau bagaimanapun, masih terdapat masalah yang belum diselesaikan yang perlu ditangani dalam beberapa tahun akan datang. Proses ini mungkin tertunda kerana fakta bahawa terdapat perkakasan yang terlibat, yang tiada siapa yang suka mengemas kini, tetapi bagaimanapun, semua masalah kelihatan agak boleh diselesaikan, dan lambat laun kita semua akan mempunyai HTTP/3.
Masa depan sudah dekat!
Sumber: www.habr.com
