Pikeun leuwih ti 20 taun urang geus nempo kaca web ngagunakeun protokol HTTP. Kaseueuran pangguna henteu mikirkeun naon éta sareng kumaha jalanna. Batur terang yén tempat di handapeun HTTP aya TLS, sareng di handapeun éta TCP, di handapeun mana IP, sareng saterasna. Sareng anu sanésna - bidat - yakin yén TCP mangrupikeun jaman baheula; aranjeunna hoyong anu langkung gancang, langkung dipercaya sareng aman. Tapi dina usaha maranéhna pikeun invent protokol idéal anyar, maranéhna balik deui ka téhnologi 80s sarta nyoba ngawangun dunya anyar gagah maranéhanana dina eta.
Sajarah saeutik: HTTP / 1.1
Dina 1997, protokol bursa informasi téks HTTP versi 1.1 kaala RFC sorangan. Dina waktu éta, protokol geus dipaké ku panyungsi salila sababaraha taun, sarta standar anyar lumangsung lima belas sejen. Protokol ngan ukur dianggo dina prinsip pamundut-réspon sareng dimaksudkeun utamina pikeun pangiriman inpormasi téks.
HTTP dirancang pikeun ngajalankeun on luhureun protokol TCP, mastikeun yén pakét anu reliably dikirimkeun ka tujuan maranéhanana. TCP jalanna ku ngadegkeun tur ngajaga sambungan dipercaya antara titik tungtung jeung megatkeun lalulintas kana bagéan. Segmen gaduh nomer séri sareng checksum sorangan. Upami ujug-ujug salah sahiji bagéan henteu sumping atanapi sumping kalayan checksum anu salah, teras pangiriman bakal lirén dugi ka bagian anu leungit dibalikeun.
Dina HTTP/1.0, sambungan TCP ditutup sanggeus unggal pamundut. Ieu pisan boros, sabab ... ngadegkeun sambungan TCP (3-Way-Sasalaman) mangrupakeun prosés slow. HTTP / 1.1 ngawanohkeun mékanisme tetep-hirup, nu ngidinan Anjeun pikeun make deui hiji sambungan pikeun sababaraha requests. Sanajan kitu, saprak éta bisa kalayan gampang jadi bottleneck a, rupa palaksanaan HTTP / 1.1 ngidinan sababaraha sambungan TCP dibuka ka host anu sarua. Contona, Chrome jeung versi panganyarna tina Firefox ngidinan nepi ka genep sambungan.
Énkripsi ogé sakuduna ditinggalkeun ka protokol séjén, sarta pikeun ieu, protokol TLS dipaké leuwih TCP, nu reliably ditangtayungan data, tapi salajengna ngaronjatna waktu diperlukeun pikeun nyieun sambungan. Hasilna, prosés sasalaman mimiti siga kieu:
Ilustrasi Cloudflare
Janten HTTP / 1.1 ngagaduhan sababaraha masalah:
- Setélan sambungan lambat.
- Data dikirimkeun dina bentuk téks, anu hartosna pangiriman gambar, pidéo sareng inpormasi non-téks sanés henteu efektif.
- Hiji sambungan TCP dipaké pikeun hiji pamundut, nu hartina requests séjén boh kudu manggihan sambungan sejen atawa antosan dugi pamundut ayeuna ngaleupaskeun eta.
- Ngan modél tarik anu dirojong. Aya nanaon dina standar ngeunaan server-push.
- Judul dikirimkeun dina téks.
Upami server-push sahenteuna dilaksanakeun nganggo protokol WebSocket, maka masalah sésana kedah diurus sacara radikal.
A modernitas saeutik: HTTP / 2
Dina 2012, Google mimiti dipake dina SPDY (dibaca "gancang") protokol. Protokol ieu dirancang pikeun ngajawab masalah utama HTTP / 1.1 sarta dina waktos anu sareng sakuduna ngajaga kasaluyuan mundur. Dina 2015, grup kerja IETF ngenalkeun spésifikasi HTTP/2 dumasar kana protokol SPDY. Ieu bédana dina HTTP/2:
- serialisasi binér.
- Multiplexing sababaraha requests HTTP kana sambungan TCP tunggal.
- Server-push out of the box (tanpa WebSocket).
Protokol éta mangrupikeun léngkah anu ageung. Anjeunna kuat sarta teu merlukeun kreasi sababaraha sambungan TCP: kabéh requests ka hiji host anu multiplexed kana hiji. Hartina, dina hiji sambungan aya sababaraha nu disebut aliran, nu masing-masing boga ID sorangan. bonus mangrupa boxed server-push.
Sanajan kitu, multiplexing ngabalukarkeun masalah konci sejen. Bayangkeun yén urang asynchronously executing 5 requests ka hiji server. Nalika nganggo HTTP / 2, sadaya pamundut ieu bakal dilaksanakeun dina sambungan TCP anu sami, anu hartosna upami salah sahiji bagéan tina pamundut anu mana waé leungit atanapi nampi henteu leres, pangiriman sadaya pamundut sareng réspon bakal lirén dugi ka bagian anu leungit. dibalikeun. Jelas, anu parah kualitas sambungan, anu laun HTTP / 2 jalan. , Dina kaayaan dimana pakét leungit akun pikeun 2% tina sakabéh pakét, HTTP / 1.1 dina browser ngalaksanakeun hadé ti HTTP / 2 alatan kanyataan yén éta muka 6 sambungan tinimbang hiji.
Masalah ieu disebut "head-of-line blocking" sareng, hanjakalna, teu mungkin pikeun ngabéréskeunana nalika nganggo TCP.
Ilustrasi ku Daniel Steinberg
Hasilna, pamekar standar HTTP / 2 ngalakukeun pakasaban hébat sarta ngalakukeun ampir sagalana nu bisa dilakukeun dina lapisan aplikasi tina model OSI. Waktosna pikeun turun ka lapisan angkutan sareng nyiptakeun protokol angkutan énggal.
Urang peryogi protokol anyar: UDP vs TCP
Cukup gancang janten écés yén ngalaksanakeun protokol lapisan angkutan lengkep anyar mangrupikeun tugas anu mustahil dina kanyataan ayeuna. Kanyataanna nyaéta hardware atanapi kotak tengah (router, firewall, server NAT ...) terang ngeunaan lapisan angkutan, sareng ngajar aranjeunna anu énggal mangrupikeun tugas anu sesah. Salaku tambahan, dukungan pikeun protokol angkutan diwangun kana kernel sistem operasi, sareng kernel ogé henteu daék robih.
Sareng di dieu anjeun tiasa ngalungkeun panangan sareng nyarios "Kami, tangtosna, bakal nyiptakeun HTTP / 3 énggal kalayan karesep sareng pelacur, tapi éta bakal nyandak 10-15 taun kanggo dilaksanakeun (sanggeus waktos ieu kalolobaan hardware bakal aya. diganti)," tapi aya hiji deui teu jadi Pilihan atra nyaéta ngagunakeun protokol UDP. Leres, enya, protokol anu sami anu biasa urang ngalungkeun file dina LAN dina ahir nineties sareng awal XNUMXan. Ampir kabéh hardware ayeuna tiasa dianggo sareng éta.
Apa keunggulan UDP dibanding TCP? Anu mimiti, urang teu boga sési lapisan angkutan nu hardware weruh ngeunaan. Hal ieu ngamungkinkeun urang pikeun nangtukeun sési dina titik tungtung sorangan sareng ngabéréskeun konflik di dinya. Nyaéta, urang henteu dugi ka hiji atanapi sababaraha sesi (sapertos dina TCP), tapi tiasa nyiptakeun saloba-lobana anu urang peryogikeun. Bréh, pangiriman data via UDP leuwih gancang ti via TCP. Ku kituna, dina tiori, urang bisa megatkeun ngaliwatan siling speed ayeuna kahontal dina HTTP / 2.
Nanging, UDP henteu ngajamin pangiriman data anu tiasa dipercaya. Kanyataanna, urang ngan saukur ngirim pakét, hoping yén tungtung séjén bakal nampa aranjeunna. Teu nampi? Nya, teu aya tuah ... Ieu cukup pikeun ngirimkeun pidéo pikeun déwasa, tapi pikeun hal anu langkung serius anjeun peryogi reliabilitas, anu hartosna anjeun kedah ngabungkus anu sanés dina luhureun UDP.
Salaku kalawan HTTP / 2, gawé dina nyieun protokol anyar dimimitian di Google dina 2012, nyaeta, sabudeureun waktu nu sarua salaku karya dina SPDY dimimitian. Dina 2013, Jim Roskind dibere ka masarakat umum , sarta geus di 2015 Draf Internet diwanohkeun pikeun standarisasi di IETF. Parantos waktos éta, protokol anu dikembangkeun ku Roskind di Google béda pisan sareng standar, janten versi Google mimiti disebut gQUIC.
Naon QUIC
Firstly, sakumaha geus disebutkeun, ieu wrapper leuwih UDP. Sambungan QUIC naék di luhur UDP, dimana, ku analogi sareng HTTP / 2, sababaraha aliran tiasa aya. Aliran ieu ngan ukur aya dina titik tungtung sareng dilayanan sacara mandiri. Upami pakét leungitna lumangsung dina hiji aliran, éta moal mangaruhan batur.
Ilustrasi ku Daniel Steinberg
Bréh, énkripsi henteu deui dilaksanakeun dina tingkat anu misah, tapi kalebet dina protokol. Hal ieu ngamungkinkeun anjeun pikeun nyieun sambungan jeung tukeur kenop publik dina sasalaman tunggal, sarta ogé ngidinan Anjeun pikeun ngagunakeun mékanisme sasalaman 0-RTT palinter tur ulah reureuh sasalaman sakabehna. Salaku tambahan, ayeuna tiasa énkripsi pakét data individu. Ieu ngamungkinkeun anjeun henteu ngantosan parantosan nampi data tina aliran, tapi pikeun ngadekrip pakét anu ditampi sacara mandiri. modeu operasi ieu umumna teu mungkin dina TCP, sabab TLS sareng TCP tiasa dianggo sacara mandiri, sareng TLS henteu tiasa terang kana potongan data TCP anu bakal dipotong. Ku alatan éta, anjeunna teu bisa nyiapkeun bagéan na ambéh maranéhanana pas kana bagéan TCP hiji-hiji sarta bisa decrypted mandiri. Sadaya perbaikan ieu ngamungkinkeun QUIC ngirangan latency dibandingkeun sareng TCP.
Katilu, konsép streaming cahaya ngamungkinkeun anjeun ngahapus sambungan tina alamat IP klien. Ieu penting, contona, nalika klien pindah ti hiji titik aksés Wi-Fi ka nu sejen, ngarobah IP na. Dina hal ieu, nalika nganggo TCP, prosés anu panjang lumangsung nalika sambungan TCP anu tos aya waktos kaluar sareng sambungan énggal didamel tina IP énggal. Dina kasus QUIC, klien saukur terus ngirim pakét ka server ti IP anyar jeung ID stream heubeul. Sabab ID aliran ayeuna unik sareng henteu dianggo deui; server ngartos yén klien parantos ngarobih IP, ngirimkeun deui pakét anu leungit sareng neraskeun komunikasi di alamat énggal.
Kaopat, QUIC dilaksanakeun dina tingkat aplikasi, sanes tingkat sistem operasi. Ieu, di hiji sisi, ngidinan Anjeun pikeun gancang nyieun parobahan protokol, sabab Pikeun meunangkeun apdet, Anjeun ngan perlu ngamutahirkeun perpustakaan, tinimbang ngadagoan versi OS anyar. Di sisi séjén, ieu ngabalukarkeun kanaékan kuat dina konsumsi processor.
Sarta pamustunganana, headline. Komprési lulugu mangrupikeun salah sahiji hal anu béda antara QUIC sareng gQUIC. Kuring teu ningali titik dina devoting loba waktu ieu, abdi ngan bakal disebutkeun yen dina versi dikintunkeun pikeun standardisasi, komprési lulugu dijieun salaku sarupa mungkin mun komprési lulugu dina HTTP / 2. Anjeun tiasa maca deui .
Sabaraha gancang éta?
Éta patarosan hésé. Kanyataanna nyaéta dugi ka urang gaduh standar, teu aya anu khusus pikeun diukur. Panginten hiji-hijina statistik anu kami gaduh nyaéta statistik ti Google, anu parantos nganggo gQUIC ti 2013 sareng 2016. yén ngeunaan 90% tina lalulintas bade server maranéhanana ti browser Chrome ayeuna ngagunakeun QUIC. Dina presentasi anu sami, aranjeunna ngalaporkeun yén halaman muka sakitar 5% langkung gancang ngalangkungan gQUIC sareng aya 30% langkung sakedik gagap dina streaming video dibandingkeun sareng TCP.
Dina 2017, grup peneliti dipingpin ku Arash Molavi Kakhki diterbitkeun pikeun diajar kinerja gQUIC dibandingkeun TCP.
Panalitian ngungkabkeun sababaraha kalemahan gQUIC, sapertos instability kana campuran pakét jaringan, rakus (unfairness) pikeun nyalurkeun rubakpita sareng transfer anu langkung laun tina objék leutik (dugi ka 10 kb). Anu terakhir, kumaha ogé, tiasa diimbalan ku ngagunakeun 0-RTT. Dina sakabeh kasus séjén ditalungtik, gQUIC némbongkeun paningkatan dina speed dibandingkeun TCP. Hésé ngobrol ngeunaan nomer khusus di dieu. Hadé maca atawa .
Di dieu kudu disebutkeun yen data ieu husus ngeunaan gQUIC, sarta teu relevan pikeun standar keur dimekarkeun. Naon anu bakal kajadian pikeun QUIC: éta masih rahasia, tapi aya harepan yén kalemahan anu diidentifikasi dina gQUIC bakal dipertimbangkeun sareng dilereskeun.
Saeutik masa depan: kumaha upami HTTP / 3?
Tapi di dieu sagalana jelas kristal: API moal robah sagala cara. Sagalana bakal tetep persis sarua jeung éta dina HTTP / 2. Nya, upami API tetep sami, transisi ka HTTP / 3 kedah direngsekeun ku ngagunakeun vérsi perpustakaan seger dina backend anu ngadukung angkutan QUIC. Leres, anjeun kedah tetep mundur dina versi HTTP lami kanggo sababaraha waktos, sabab Internét ayeuna teu siap pikeun transisi lengkep ka UDP.
Anu geus ngarojong
di dieu aya palaksanaan QUIC. Sanajan kurangna standar a, daftar teu goréng.
Henteu aya browser anu ayeuna ngadukung QUIC dina rilis produksi. Anyar-anyar ieu aya inpormasi anu ngadukung HTTP / 3 kalebet dina Chrome, tapi dugi ka ayeuna ngan di Canary.
Tina backends, HTTP / 3 ngan ngarojong и , tapi tetep ékspérimén. NGINX dina ahir musim semi 2019 , yén maranéhna mimiti dipake dina rojongan HTTP / 3, tapi teu rengse eta acan.
Naon masalahna?
Anjeun sareng kuring hirup di dunya nyata, dimana teu aya téknologi gedé anu tiasa ngahontal massa tanpa nyumponan résistansi, sareng QUIC sanés iwal.
Hal anu paling penting nyaéta anjeun kedah kumaha waé ngajelaskeun ka browser yén "https://" henteu deui kanyataan yén éta nuju ka port TCP 443. Bisa jadi teu aya TCP pisan. The Alt-Svc lulugu dipaké pikeun ieu. Eta ngidinan Anjeun pikeun ngabejaan browser nu ramatloka ieu ogé sadia on protokol misalna jeung kitu di alamat sapertos na kitu. Sacara tiori, ieu kedah dianggo sapertos pesona, tapi dina prakna urang bakal mendakan kanyataan yén UDP tiasa, contona, dilarang dina firewall pikeun nyegah serangan DDoS.
Tapi sanajan UDP teu dilarang, klien nu bisa jadi tukangeun hiji router NAT nu ngonpigurasi nyekel sési TCP ku alamat IP, sarta saprak kami nganggo UDP, nu teu boga sési hardware, NAT moal tahan sambungan, sarta sési QUIC .
Sadaya masalah ieu disababkeun ku kanyataan yén UDP saacanna henteu dianggo pikeun ngirimkeun eusi Internét, sareng produsén hardware henteu tiasa ngaduga yén ieu bakal kajadian. Dina cara anu sami, pangurus henteu acan ngartos kumaha leres ngonpigurasikeun jaringanna supados QUIC tiasa jalan. Kaayaan ieu laun-laun bakal robih, sareng, dina sagala hal, parobihan sapertos kitu bakal nyandak kirang waktos tibatan palaksanaan protokol lapisan angkutan énggal.
Salaku tambahan, sakumaha anu parantos dijelaskeun, QUIC ningkatkeun pamakean CPU. Daniel Stenberg prosésor tumuwuh nepi ka tilu kali.
Iraha HTTP / 3 bakal sumping?
standar ku Méi 2020, tapi nunjukkeun yén dokumén anu dijadwalkeun pikeun Juli 2019 tetep tacan beres ayeuna, urang tiasa nyebatkeun yén tanggal éta paling dipikaresep bakal kadorong deui.
Nya, Google parantos ngagunakeun palaksanaan gQUIC na saprak 2013. Upami anjeun ningali pamundut HTTP anu dikirim ka mesin pencari Google, anjeun bakal ningali ieu:
papanggihan
QUIC ayeuna katingalina sapertos téknologi anu rada atah, tapi ngajangjikeun pisan. Nganggap yén salami 20 taun katukang, sadaya optimasi protokol lapisan transportasi utamina prihatin TCP, QUIC, anu dina kalolobaan kasus ngagaduhan prestasi anu pangsaéna, parantos katingali saé pisan.
Sanajan kitu, masih aya masalah unresolved nu kudu diurus dina sababaraha taun ka hareup. Prosésna tiasa ditunda kusabab kanyataan yén aya hardware anu aub, anu teu aya anu resep ngapdet, tapi kumaha waé, sadaya masalah sigana tiasa direngsekeun, sareng engké atanapi engké urang sadayana bakal ngagaduhan HTTP / 3.
masa depan téh ngan sabudeureun sudut!
sumber: www.habr.com