Luwih saka 20 taun kita wis ndeleng kaca web nggunakake protokol HTTP. Umume pangguna ora mikir babagan apa lan cara kerjane. Liyane ngerti yen nang endi wae ing HTTP ana TLS, lan ing ngisor iki yaiku TCP, ing ngisor iki IP, lan liya-liyane. Lan liyane - wong sesat - percaya yen TCP minangka barang sing kepungkur; dheweke pengin sing luwih cepet, luwih dipercaya lan aman. Nanging ing upaya kanggo nemokke protokol becik anyar, padha bali menyang teknologi 80s lan nyoba kanggo mbangun donya anyar wani ing.
Sajarah sethitik: HTTP / 1.1
Ing taun 1997, protokol pertukaran informasi teks HTTP versi 1.1 entuk RFC dhewe. Ing wektu iku, protokol wis digunakake dening browser kanggo sawetara taun, lan standar anyar tahan liyane limalas. Protokol kasebut mung makarya ing prinsip panjalukan-tanggapan lan ditrapake utamane kanggo ngirim informasi teks.
HTTP dirancang kanggo mbukak ing ndhuwur protokol TCP, mesthekake yen paket-paket dikirim kanthi dipercaya menyang panggonan sing dituju. TCP dianggo kanthi nggawe lan njaga sambungan sing bisa dipercaya ing antarane titik pungkasan lan mecah lalu lintas dadi segmen. Segmen duwe nomer seri lan checksum dhewe. Yen dumadakan salah sawijining segmen ora teka utawa teka kanthi checksum sing salah, mula transmisi bakal mandheg nganti bagean sing ilang dibalekake.
Ing HTTP/1.0, sambungan TCP ditutup sawise saben panyuwunan. Iki boros banget, amarga ... nggawe sambungan TCP (3-Way-Handshake) iku proses alon. HTTP / 1.1 ngenalaken mekanisme tetep-urip, sing ngijini sampeyan kanggo nggunakake maneh siji sambungan kanggo macem-macem panjalukan. Nanging, amarga bisa gampang dadi bottleneck, macem-macem implementasi HTTP/1.1 ngidini sawetara sambungan TCP dibukak menyang host sing padha. Contone, Chrome lan versi Firefox paling anyar ngidini nganti enem sambungan.
Enkripsi uga kudu ditinggalake menyang protokol liyane, lan kanggo iki, protokol TLS digunakake liwat TCP, sing bisa dipercaya nglindhungi data kasebut, nanging luwih akeh wektu sing dibutuhake kanggo nggawe sambungan. Akibaté, proses salaman wiwit katon kaya iki:
Ilustrasi Cloudflare
Mangkono HTTP / 1.1 duwe sawetara masalah:
- Persiyapan sambungan alon.
- Data ditularake ing wangun teks, tegese transmisi gambar, video lan informasi non-teks liyane ora efektif.
- Siji sambungan TCP digunakake kanggo siji panjalukan, sing tegese panjalukan liyane kudu nemokake sambungan liyane utawa ngenteni nganti panjalukan saiki ngeculake.
- Mung model tarik sing didhukung. Ora ana apa-apa ing standar babagan server-push.
- Judhul dikirim ing teks.
Yen server-push paling sethithik dileksanakake nggunakake protokol WebSocket, mula masalah sing isih ana kudu ditangani kanthi luwih radikal.
A modernitas sethitik: HTTP / 2
Ing 2012, Google wiwit nggarap protokol SPDY (diucapake "cepet"). Protokol kasebut dirancang kanggo ngatasi masalah utama HTTP / 1.1 lan ing wektu sing padha kudu njaga kompatibilitas mundur. Ing 2015, grup kerja IETF ngenalake spesifikasi HTTP/2 adhedhasar protokol SPDY. Mangkene bedane ing HTTP/2:
- Serialisasi binar.
- Multiplexing sawetara panjalukan HTTP menyang sambungan TCP siji.
- Server-push metu saka kothak (tanpa WebSocket).
Protokol kasebut minangka langkah maju. Dheweke kuwat lan ora mbutuhake nggawe sawetara sambungan TCP: kabeh panjalukan kanggo siji host sing multiplexed dadi siji. Tegese, ing siji sambungan ana sawetara sing diarani stream, sing saben duwe ID dhewe. Bonus punika server-push kothak.
Nanging, multiplexing nyebabake masalah utama liyane. Bayangake manawa kita nindakake 5 panjaluk kanthi ora sinkron menyang siji server. Nalika nggunakake HTTP / 2, kabeh panjalukan iki bakal ditindakake ing sambungan TCP sing padha, sing tegese yen salah sawijining segmen panyuwunan ilang utawa salah ditampa, transmisi kabeh panjaluk lan tanggapan bakal mandheg nganti segmen sing ilang. dibalèkaké. Temenan, kualitas sambungan sing luwih elek, HTTP / 2 luwih alon. , ing kahanan ngendi paket ilang akun kanggo 2% saka kabeh paket, HTTP / 1.1 ing browser performs luwih apik tinimbang HTTP / 2 amarga kasunyatan sing mbukak 6 sambungan tinimbang siji.
Masalah iki diarani "head-of-line blocking" lan, sayangé, ora bisa diatasi nalika nggunakake TCP.
Ilustrasi dening Daniel Steinberg
Akibaté, pangembang standar HTTP / 2 nindakake tugas sing apik lan nindakake meh kabeh sing bisa ditindakake ing lapisan aplikasi model OSI. Wektu kanggo mudhun menyang lapisan transportasi lan nggawe protokol transportasi anyar.
Kita butuh protokol anyar: UDP vs TCP
Cukup cepet dadi cetha yen ngleksanakake protokol lapisan transportasi sing anyar minangka tugas sing ora mungkin ing kasunyatan saiki. Kasunyatane yaiku hardware utawa kothak tengah (router, firewall, server NAT ...) ngerti babagan lapisan transportasi, lan mulang babagan sing anyar minangka tugas sing angel banget. Kajaba iku, dhukungan kanggo protokol transportasi dibangun ing kernel sistem operasi, lan kernel uga ora pengin ngganti.
Lan ing kene ana wong sing bisa ngunggahake tangan lan ujar "Kita, mesthi, bakal nggawe HTTP / 3 anyar kanthi pilihan lan courtesans, nanging butuh 10-15 taun kanggo dileksanakake (sawise babagan wektu iki, akeh hardware bakal dadi diganti)," nanging ana siji liyane ora dadi Opsi sing jelas yaiku nggunakake protokol UDP. Ya, ya, protokol sing padha digunakake kanggo mbuwang file liwat LAN ing pungkasan taun nineties lan awal XNUMXs. Meh kabeh hardware saiki bisa digunakake.
Apa kaluwihan UDP tinimbang TCP? Kaping pisanan, kita ora duwe sesi lapisan transportasi sing hardware ngerti. Iki ngidini kita nemtokake sesi ing titik pungkasan dhewe lan ngrampungake konflik ing kana. Tegese, kita ora diwatesi mung siji utawa sawetara sesi (kaya ing TCP), nanging bisa nggawe akeh sing dibutuhake. Kapindho, transmisi data liwat UDP luwih cepet tinimbang liwat TCP. Mangkono, ing teori, kita bisa ngilangi langit-langit kacepetan saiki sing diraih ing HTTP / 2.
Nanging, UDP ora njamin transmisi data sing dipercaya. Nyatane, kita mung ngirim paket, ngarep-arep yen ujung liyane bakal nampa. Durung nampa? Ya, ora luck ... Iki cukup kanggo ngirim video kanggo wong diwasa, nanging kanggo perkara sing luwih serius sampeyan butuh linuwih, tegese sampeyan kudu mbungkus liyane ing ndhuwur UDP.
Kaya HTTP / 2, gaweyan nggawe protokol anyar diwiwiti ing Google ing 2012, yaiku, ing wektu sing padha karo SPDY diwiwiti. Ing 2013, Jim Roskind presented kanggo masyarakat umum , lan wis ing 2015 Draft Internet dikenalaké kanggo standarisasi ing IETF. Saiki, protokol sing dikembangake dening Roskind ing Google beda banget karo standar, mula versi Google wiwit diarani gQUIC.
Apa iku QUIC
Kaping pisanan, kaya sing wis kasebut, iki minangka pambungkus UDP. Sambungan QUIC munggah ing ndhuwur UDP, sing, kanthi analogi karo HTTP / 2, sawetara aliran bisa ana. Aliran iki mung ana ing titik pungkasan lan dilayani kanthi mandiri. Yen mundhut paket dumadi ing siji stream, iku ora bakal mengaruhi liyane.
Ilustrasi dening Daniel Steinberg
Kapindho, enkripsi ora ditindakake maneh ing tingkat sing kapisah, nanging kalebu ing protokol kasebut. Iki ngidini sampeyan nggawe sambungan lan ijol-ijolan tombol umum ing salaman siji, lan uga ngidini sampeyan nggunakake mekanisme jabat tangan 0-RTT sing pinter lan ngindhari telat jabat tangan kabeh. Kajaba iku, saiki bisa ndhelik paket data individu. Iki ngidini sampeyan ora ngenteni rampung nampa data saka stream, nanging dekripsi paket sing ditampa kanthi mandiri. Mode operasi iki umume mokal ing TCP, amarga TLS lan TCP makarya kanthi mandiri, lan TLS ora bisa ngerti babagan potongan data TCP sing bakal dipotong. Mula, dheweke ora bisa nyiapake segmen kasebut supaya pas karo segmen TCP siji-siji lan bisa didekripsi kanthi mandiri. Kabeh dandan iki ngidini QUIC nyuda latensi dibandhingake karo TCP.
Katelu, konsep streaming cahya ngidini sampeyan ngilangi sambungan saka alamat IP klien. Iki penting, contone, nalika klien ngalih saka siji titik akses Wi-Fi liyane, ngganti IP sawijining. Ing kasus iki, nalika nggunakake TCP, ana proses dawa nalika sambungan TCP ana wektu entek lan sambungan anyar digawe saka IP anyar. Ing kasus QUIC, klien mung terus ngirim paket menyang server saka IP anyar kanthi ID stream lawas. Amarga ID stream saiki unik lan ora digunakake maneh; server ngerti yen klien wis ngganti IP, ngirim maneh paket sing ilang lan terus komunikasi ing alamat anyar.
Kaping papat, QUIC diimplementasikake ing level aplikasi, dudu level sistem operasi. Iki, ing tangan siji, ngidini sampeyan nggawe owah-owahan kanthi cepet ing protokol, amarga Kanggo entuk nganyari, sampeyan mung kudu nganyari perpustakaan, tinimbang ngenteni versi OS anyar. Ing tangan liyane, iki ndadékaké kanggo Tambah kuwat ing konsumsi prosesor.
Lan pungkasane, judhul. Kompresi header minangka salah sawijining perkara sing beda antarane QUIC lan gQUIC. Aku ora weruh titik kanggo nyawisake akeh wektu kanggo iki, aku mung bakal ngomong yen ing versi sing dikirim kanggo standarisasi, kompresi header digawe meh padha karo kompresi header ing HTTP / 2. Sampeyan bisa maca liyane .
Carane luwih cepet iku?
Iku pitakonan angel. Kasunyatane yaiku nganti kita duwe standar, ora ana sing kudu diukur. Mbok menawa mung statistik sing kita duweni yaiku statistik saka Google, sing wis nggunakake gQUIC wiwit 2013 lan ing 2016. yen udakara 90% lalu lintas menyang server saka browser Chrome saiki nggunakake QUIC. Ing presentasi sing padha, dheweke nglaporake manawa kaca mbukak kira-kira 5% luwih cepet liwat gQUIC lan ana 30% luwih sithik gagap ing streaming video dibandhingake karo TCP.
Ing 2017, klompok peneliti sing dipimpin Arash Molavi Kakhki diterbitake kanggo sinau kinerja gQUIC dibandhingake TCP.
Panliten kasebut nuduhake sawetara kelemahane gQUIC, kayata ketidakstabilan ing campuran paket jaringan, rakus (ora adil) kanggo saluran bandwidth lan transfer obyek cilik (nganti 10 kb) luwih alon. Sing terakhir, Nanging, bisa menehi ganti rugi kanthi nggunakake 0-RTT. Ing kabeh kasus liyane sing diteliti, gQUIC nuduhake peningkatan kacepetan dibandhingake karo TCP. Iku angel kanggo pirembagan bab nomer tartamtu kene. Luwih apik maca utawa .
Ing kene kudu dikandhakake manawa data iki khusus babagan gQUIC, lan ora cocog karo standar sing dikembangake. Apa sing bakal kelakon kanggo QUIC: isih rahasia, nanging ana pangarep-arep yen kelemahane sing diidentifikasi ing gQUIC bakal dianggep lan didandani.
A dicokot saka mangsa: apa bab HTTP / 3?
Nanging ing kene kabeh cetha banget: API ora bakal diganti kanthi cara apa wae. Kabeh bakal tetep padha kaya ing HTTP/2. Ya, yen API tetep padha, transisi menyang HTTP / 3 kudu ditanggulangi kanthi nggunakake versi perpustakaan anyar ing backend sing ndhukung transportasi QUIC. Bener, sampeyan kudu tetep mundur ing versi HTTP lawas kanggo sawetara wektu, amarga Internet saiki durung siyap kanggo transisi lengkap menyang UDP.
Sing wis ndhukung
kene implementasi QUIC ana. Sanajan ora ana standar, dhaptar kasebut ora ala.
Ora ana browser sing saiki ndhukung QUIC ing rilis produksi. Bubar ana informasi sing ndhukung HTTP / 3 kalebu ing Chrome, nanging nganti saiki mung ing Canary.
Saka backends, HTTP / 3 mung ndhukung и , nanging isih eksperimen. NGINX ing pungkasan musim semi 2019 , sing padha miwiti nggarap dhukungan HTTP/3, nanging durung rampung.
Apa masalahe?
Sampeyan lan aku manggon ing donya nyata, ing ngendi ora ana teknologi gedhe sing bisa nggayuh massa tanpa nemoni perlawanan, lan QUIC ora ana sing istiméwa.
Ingkang paling penting yaiku sampeyan kudu njlentrehake menyang browser manawa "https: //" ora dadi kasunyatan sing ndadékaké menyang port TCP 443. Bisa uga ora ana TCP. Header Alt-Svc digunakake kanggo iki. Iki ngidini sampeyan ngandhani browser manawa situs web iki uga kasedhiya ing protokol kasebut ing alamat kasebut. Ing teori, iki kudu kaya pesona, nanging ing praktik kita bakal nemokake kasunyatan manawa UDP bisa, contone, dilarang ing firewall kanggo nyegah serangan DDoS.
Nanging sanajan UDP ora dilarang, klien bisa uga ana ing mburi router NAT sing dikonfigurasi kanggo nyekel sesi TCP kanthi alamat IP, lan wiwit kita nggunakake UDP, sing ora duwe sesi hardware, NAT ora bakal terus sambungan, lan sesi QUIC .
Kabeh masalah iki amarga kasunyatan sing UDP sadurunge wis ora digunakake kanggo ngirim isi Internet, lan manufaktur hardware ora bisa foresee sing iki bakal tau kelakon. Kanthi cara sing padha, pangurus durung ngerti carane ngatur jaringan kanthi bener supaya QUIC bisa digunakake. Kahanan iki mboko sithik diganti, lan, ing kasus apa wae, owah-owahan kasebut bakal njupuk wektu kurang saka implementasi protokol lapisan transportasi anyar.
Kajaba iku, kaya sing wis diterangake, QUIC nambah panggunaan CPU. Daniel Stenberg wutah prosesor nganti kaping telu.
Nalika HTTP / 3 bakal teka?
Standar ing Mei 2020, nanging amarga dokumen sing dijadwalake kanggo Juli 2019 isih durung rampung, kita bisa ujar manawa tanggal kasebut bakal mundur.
Ya, Google wis nggunakake implementasi gQUIC wiwit 2013. Yen sampeyan ndeleng panjalukan HTTP sing dikirim menyang mesin telusur Google, sampeyan bakal weruh iki:
temonan
QUIC saiki katon kaya teknologi sing rada mentah, nanging njanjeni banget. Ngelingi yen sajrone 20 taun kepungkur, kabeh optimasi protokol lapisan transportasi utamane prihatin karo TCP, QUIC, sing biasane duwe kinerja paling apik, wis katon apik banget.
Nanging, isih ana masalah sing durung rampung sing kudu ditangani ing sawetara taun sabanjure. Proses kasebut bisa uga ditundha amarga ana hardware, sing ora ana sing seneng nganyari, nanging kabeh masalah katon bisa diatasi, lan cepet utawa mengko kita bakal duwe HTTP / 3.
Masa depan mung cedhak!
Source: www.habr.com