Sa loob ng higit sa 20 taon, tinitingnan namin ang mga web page gamit ang HTTP protocol. Karamihan sa mga gumagamit ay hindi nag-iisip tungkol sa kung ano ito at kung paano ito gumagana. Alam ng iba na sa isang lugar sa ilalim ng HTTP ay mayroong TLS, at sa ilalim nito ay TCP, sa ilalim nito ay IP, at iba pa. At ang iba pa - mga erehe - ay naniniwala na ang TCP ay isang bagay ng nakaraan; gusto nila ng isang bagay na mas mabilis, mas maaasahan at secure. Ngunit sa kanilang mga pagtatangka na mag-imbento ng bagong ideal na protocol, bumalik sila sa teknolohiya noong dekada 80 at sinusubukang itayo ang kanilang matapang na bagong mundo dito.
Isang maliit na kasaysayan: HTTP/1.1
Noong 1997, ang text information exchange protocol HTTP version 1.1 ay nakakuha ng sarili nitong RFC. Sa oras na iyon, ang protocol ay ginamit ng mga browser sa loob ng ilang taon, at ang bagong pamantayan ay tumagal ng isa pang labinlimang. Ang protocol ay gumagana lamang sa prinsipyo ng kahilingan-tugon at pangunahing inilaan para sa paghahatid ng impormasyon sa teksto.
Ang HTTP ay idinisenyo upang tumakbo sa itaas ng TCP protocol, na tinitiyak na ang mga packet ay mapagkakatiwalaan na naihatid sa kanilang patutunguhan. Gumagana ang TCP sa pamamagitan ng pagtatatag at pagpapanatili ng maaasahang koneksyon sa pagitan ng mga endpoint at paghahati-hati ng trapiko sa mga segment. Ang mga segment ay may sariling serial number at checksum. Kung biglang hindi dumating ang isa sa mga segment o dumating na may maling checksum, hihinto ang transmission hanggang sa maibalik ang nawalang segment.
Sa HTTP/1.0, isinara ang koneksyon ng TCP pagkatapos ng bawat kahilingan. Ito ay lubhang aksaya, dahil... Ang pagtatatag ng koneksyon sa TCP (3-Way-Handshake) ay isang mabagal na proseso. Ipinakilala ng HTTP/1.1 ang keep-alive na mekanismo, na nagbibigay-daan sa iyong muling gamitin ang isang koneksyon para sa maraming kahilingan. Gayunpaman, dahil madali itong maging bottleneck, ang iba't ibang pagpapatupad ng HTTP/1.1 ay nagbibigay-daan sa maraming koneksyon sa TCP na mabuksan sa parehong host. Halimbawa, pinapayagan ng Chrome at mga kamakailang bersyon ng Firefox ang hanggang anim na koneksyon.
Ang pag-encrypt ay dapat ding iwanan sa iba pang mga protocol, at para dito, ang TLS protocol ay ginamit sa TCP, na mapagkakatiwalaan na nagpoprotekta sa data, ngunit higit pang pinataas ang oras na kinakailangan upang magtatag ng isang koneksyon. Bilang resulta, ang proseso ng pakikipagkamay ay nagsimulang magmukhang ganito:
Ilustrasyon ng Cloudflare
Kaya ang HTTP/1.1 ay nagkaroon ng maraming problema:
- Mabagal na pag-setup ng koneksyon.
- Ang data ay ipinapadala sa anyo ng teksto, na nangangahulugang ang pagpapadala ng mga larawan, video at iba pang impormasyong hindi teksto ay hindi epektibo.
- Ang isang koneksyon sa TCP ay ginagamit para sa isang kahilingan, na nangangahulugan na ang iba pang mga kahilingan ay dapat maghanap ng isa pang koneksyon o maghintay hanggang sa ilabas ito ng kasalukuyang kahilingan.
- Tanging ang pull model ang sinusuportahan. Walang nasa pamantayan tungkol sa server-push.
- Ang mga heading ay ipinadala sa teksto.
Kung ang server-push ay hindi bababa sa ipinatupad gamit ang WebSocket protocol, kung gayon ang natitirang mga problema ay kailangang harapin nang mas radikal.
Medyo modernity: HTTP/2
Noong 2012, nagsimulang magtrabaho ang Google sa SPDY (binibigkas na βmabilisβ) na protocol. Ang protocol ay idinisenyo upang malutas ang mga pangunahing problema ng HTTP/1.1 at sa parehong oras ay dapat na mapanatili ang pabalik na pagkakatugma. Noong 2015, ipinakilala ng IETF working group ang HTTP/2 specification batay sa SPDY protocol. Narito ang mga pagkakaiba sa HTTP/2:
- Binary na serialization.
- Pag-multipleks ng maraming kahilingan sa HTTP sa isang koneksyon sa TCP.
- Server-push sa labas ng kahon (nang walang WebSocket).
Ang protocol ay isang malaking hakbang pasulong. Malakas siya at hindi nangangailangan ng paglikha ng maraming koneksyon sa TCP: lahat ng mga kahilingan sa isang host ay multiplex sa isa. Iyon ay, sa isang koneksyon mayroong ilang mga tinatawag na stream, bawat isa ay may sariling ID. Ang bonus ay isang boxed server-push.
Gayunpaman, ang multiplexing ay humahantong sa isa pang pangunahing problema. Isipin na asynchronous kaming nagsasagawa ng 5 kahilingan sa isang server. Kapag gumagamit ng HTTP/2, isasagawa ang lahat ng mga kahilingang ito sa loob ng parehong koneksyon sa TCP, na nangangahulugan na kung ang isa sa mga segment ng anumang kahilingan ay nawala o natanggap nang hindi tama, ang paghahatid ng lahat ng mga kahilingan at tugon ay titigil hanggang sa nawala ang segment. naibalik. Malinaw, ang mas masahol na kalidad ng koneksyon, ang mas mabagal na HTTP/2 ay gumagana. , sa mga kondisyon kung saan ang mga nawawalang packet ay nagkakaloob ng 2% ng lahat ng mga packet, ang HTTP/1.1 sa browser ay gumaganap nang mas mahusay kaysa sa HTTP/2 dahil sa katotohanang ito ay nagbubukas ng 6 na koneksyon sa halip na isa.
Ang problemang ito ay tinatawag na "head-of-line blocking" at, sa kasamaang-palad, hindi ito posibleng lutasin kapag gumagamit ng TCP.
Larawan ni Daniel Steinberg
Bilang resulta, ang mga developer ng HTTP/2 standard ay gumawa ng mahusay na trabaho at ginawa ang halos lahat ng maaaring gawin sa application layer ng OSI model. Oras na para bumaba sa transport layer at mag-imbento ng bagong transport protocol.
Kailangan namin ng bagong protocol: UDP vs TCP
Mabilis na naging malinaw na ang pagpapatupad ng isang ganap na bagong transport layer protocol ay isang imposibleng gawain sa mga katotohanan ngayon. Ang katotohanan ay alam ng hardware o middle-box (router, firewall, NAT server...) ang tungkol sa transport layer, at ang pagtuturo sa kanila ng bago ay isang napakahirap na gawain. Bilang karagdagan, ang suporta para sa mga protocol ng transportasyon ay binuo sa kernel ng mga operating system, at ang mga kernel ay hindi rin handang magbago.
At dito, maaaring itataas ng isang tao ang kanyang mga kamay at sabihin na "Kami, siyempre, ay mag-imbento ng isang bagong HTTP/3 na may kagustuhan at courtesans, ngunit ito ay aabutin ng 10-15 taon upang maipatupad (pagkatapos ng halos oras na ito karamihan sa hardware ay magiging pinalitan)," ngunit may isa pang hindi kaya Ang halatang opsyon ay ang paggamit ng UDP protocol. Oo, oo, ang parehong protocol na ginamit namin upang ihagis ang mga file sa LAN noong huling bahagi ng nineties at unang bahagi ng XNUMXs. Halos lahat ng hardware ngayon ay maaaring gumana dito.
Ano ang mga pakinabang ng UDP sa TCP? Una sa lahat, wala kaming transport layer session na alam ng hardware. Nagbibigay-daan ito sa amin na matukoy mismo ang session sa mga endpoint at lutasin ang mga salungatan doon. Ibig sabihin, hindi kami limitado sa isa o ilang session (tulad ng sa TCP), ngunit maaari kaming lumikha ng marami sa mga ito hangga't kailangan namin. Pangalawa, ang paghahatid ng data sa pamamagitan ng UDP ay mas mabilis kaysa sa pamamagitan ng TCP. Kaya, sa teorya, maaari nating masira ang kasalukuyang bilis ng kisame na nakamit sa HTTP/2.
Gayunpaman, hindi ginagarantiya ng UDP ang maaasahang paghahatid ng data. Sa katunayan, nagpapadala lamang kami ng mga packet, umaasa na matatanggap sila ng kabilang dulo. Hindi pa natanggap? Well, walang swerte... Ito ay sapat na upang magpadala ng mga video para sa mga nasa hustong gulang, ngunit para sa mga mas seryosong bagay kailangan mo ng pagiging maaasahan, na nangangahulugang kailangan mong ibalot ang iba sa ibabaw ng UDP.
Tulad ng HTTP/2, nagsimula ang paggawa ng bagong protocol sa Google noong 2012, iyon ay, sa parehong oras nang nagsimula ang trabaho sa SPDY. Noong 2013, ipinakita ni Jim Roskind sa pangkalahatang publiko , at noong 2015 ay ipinakilala ang Internet Draft para sa standardisasyon sa IETF. Sa panahong iyon, ang protocol na binuo ng Roskind sa Google ay ibang-iba sa pamantayan, kaya ang bersyon ng Google ay nagsimulang tawaging gQUIC.
Ano ang QUIC
Una, tulad ng nabanggit na, ito ay isang wrapper sa UDP. Ang isang QUIC na koneksyon ay tumataas sa itaas ng UDP, kung saan, sa pamamagitan ng pagkakatulad sa HTTP/2, maraming stream ang maaaring umiral. Ang mga stream na ito ay umiiral lamang sa mga endpoint at inihahatid nang nakapag-iisa. Kung ang isang packet loss ay nangyari sa isang stream, hindi ito makakaapekto sa iba.
Larawan ni Daniel Steinberg
Pangalawa, ang pag-encrypt ay hindi na ipinatupad sa isang hiwalay na antas, ngunit kasama sa protocol. Binibigyang-daan ka nitong magtatag ng koneksyon at makipagpalitan ng mga pampublikong key sa iisang handshake, at nagbibigay-daan din sa iyong gamitin ang matalinong 0-RTT handshake mechanism at maiwasan ang mga pagkaantala sa handshake. Bilang karagdagan, posible na ngayong i-encrypt ang mga indibidwal na packet ng data. Pinapayagan ka nitong huwag maghintay para sa pagkumpleto ng pagtanggap ng data mula sa stream, ngunit upang i-decrypt ang mga natanggap na packet nang nakapag-iisa. Ang mode ng operasyon na ito ay karaniwang imposible sa TCP, dahil Ang TLS at TCP ay gumagana nang hiwalay sa isa't isa, at hindi malalaman ng TLS kung anong mga piraso ang tatanggalin ng data ng TCP. At samakatuwid, hindi niya maihanda ang kanyang mga segment upang magkasya ang mga ito sa mga segment ng TCP nang isa-isa at maaaring ma-decrypt nang nakapag-iisa. Ang lahat ng mga pagpapahusay na ito ay nagbibigay-daan sa QUIC na bawasan ang latency kumpara sa TCP.
Pangatlo, pinapayagan ka ng konsepto ng light streaming na i-decouple ang koneksyon mula sa IP address ng kliyente. Mahalaga ito, halimbawa, kapag lumipat ang isang kliyente mula sa isang Wi-Fi access point patungo sa isa pa, binabago ang IP nito. Sa kasong ito, kapag gumagamit ng TCP, isang mahabang proseso ang nagaganap kung saan ang mga umiiral na koneksyon sa TCP ay nag-time out at ang mga bagong koneksyon ay nilikha mula sa isang bagong IP. Sa kaso ng QUIC, ang kliyente ay patuloy na nagpapadala ng mga packet sa server mula sa isang bagong IP na may lumang stream ID. kasi Ang stream ID ay natatangi na ngayon at hindi na muling ginagamit; nauunawaan ng server na binago ng kliyente ang IP, muling ipinapadala ang mga nawawalang packet at nagpapatuloy sa komunikasyon sa bagong address.
Ikaapat, ipinatupad ang QUIC sa antas ng aplikasyon, hindi sa antas ng operating system. Ito, sa isang banda, ay nagpapahintulot sa iyo na mabilis na gumawa ng mga pagbabago sa protocol, dahil Para makakuha ng update, kailangan mo lang i-update ang library, sa halip na maghintay ng bagong bersyon ng OS. Sa kabilang banda, ito ay humahantong sa isang malakas na pagtaas sa pagkonsumo ng processor.
At sa wakas, ang mga headline. Ang compression ng header ay isa sa mga bagay na naiiba sa pagitan ng QUIC at gQUIC. Hindi ko nakikita ang punto sa paglalaan ng maraming oras para dito, sasabihin ko lang na sa bersyon na isinumite para sa standardisasyon, ang header compression ay ginawa na katulad hangga't maaari sa header compression sa HTTP/2. Maaari mong basahin ang higit pa .
Gaano ito kabilis?
Mahirap na tanong. Ang katotohanan ay hanggang sa mayroon tayong pamantayan, walang espesyal na susukatin. Marahil ang tanging istatistika na mayroon kami ay mga istatistika mula sa Google, na gumagamit ng gQUIC mula noong 2013 at noong 2016 na halos 90% ng trapikong papunta sa kanilang mga server mula sa Chrome browser ay gumagamit na ngayon ng QUIC. Sa parehong presentasyon, iniulat nila na ang mga page ay naglo-load nang humigit-kumulang 5% na mas mabilis sa pamamagitan ng gQUIC at mayroong 30% na mas kaunting mga stutter sa video streaming kumpara sa TCP.
Noong 2017, inilathala ng isang pangkat ng mga mananaliksik na pinamumunuan ni Arash Molavi Kakhki upang pag-aralan ang pagganap ng gQUIC kumpara sa TCP.
Ang pag-aaral ay nagsiwalat ng ilang mga kahinaan ng gQUIC, tulad ng kawalang-tatag sa paghahalo ng mga network packet, kasakiman (hindi patas) sa channel ng bandwidth at mas mabagal na paglipat ng maliliit (hanggang 10 kb) na mga bagay. Ang huli, gayunpaman, ay maaaring mabayaran sa pamamagitan ng paggamit ng 0-RTT. Sa lahat ng iba pang kaso na pinag-aralan, nagpakita ang gQUIC ng pagtaas ng bilis kumpara sa TCP. Mahirap pag-usapan ang mga partikular na numero dito. Mas mabuting basahin o .
Dito dapat sabihin na ang data na ito ay partikular na tungkol sa gQUIC, at hindi ito nauugnay sa pamantayang binuo. Ano ang mangyayari para sa QUIC: sikreto pa rin ito, ngunit may pag-asa na ang mga kahinaang natukoy sa gQUIC ay maisasaalang-alang at maitama.
Kaunti sa hinaharap: paano ang HTTP/3?
Ngunit dito malinaw ang lahat: hindi magbabago ang API sa anumang paraan. Ang lahat ay mananatiling eksaktong pareho sa HTTP/2. Well, kung mananatiling pareho ang API, ang paglipat sa HTTP/3 ay kailangang lutasin sa pamamagitan ng paggamit ng bagong bersyon ng library sa backend na sumusuporta sa QUIC transport. Totoo, kakailanganin mong panatilihin ang fallback sa mga lumang bersyon ng HTTP nang medyo matagal, dahil Ang Internet ay kasalukuyang hindi handa para sa isang kumpletong paglipat sa UDP.
Kung sino na ang sumusuporta
Dito kasalukuyang mga pagpapatupad ng QUIC. Sa kabila ng kakulangan ng isang pamantayan, ang listahan ay hindi masama.
Walang browser na kasalukuyang sumusuporta sa QUIC sa isang production release. Kamakailan ay mayroong impormasyon na ang suporta para sa HTTP/3 ay kasama sa Chrome, ngunit hanggang ngayon ay nasa Canary lamang.
Sa mga backend, sinusuportahan lang ng HTTP/3 ΠΈ , ngunit eksperimento pa rin. NGINX sa pagtatapos ng tagsibol 2019 , na nagsimula silang magtrabaho sa suporta sa HTTP/3, ngunit hindi pa ito natapos.
Ano ang mga problema?
Ikaw at ako ay nabubuhay sa totoong mundo, kung saan walang malaking teknolohiya ang makakaabot sa masa nang hindi nakakatugon sa pagtutol, at ang QUIC ay walang pagbubukod.
Ang pinakamahalagang bagay ay kailangan mong ipaliwanag sa browser na ang "https://" ay hindi na isang katotohanan na humahantong ito sa TCP port 443. Maaaring walang TCP. Ang Alt-Svc header ay ginagamit para dito. Pinapayagan ka nitong sabihin sa browser na ang website na ito ay magagamit din sa ganito at ganoong protocol sa ganito at ganoong address. Sa teorya, dapat itong gumana tulad ng isang alindog, ngunit sa pagsasagawa ay makikita natin ang katotohanan na ang UDP ay maaaring, halimbawa, ay ipinagbabawal sa isang firewall upang maiwasan ang mga pag-atake ng DDoS.
Ngunit kahit na ang UDP ay hindi ipinagbabawal, ang kliyente ay maaaring nasa likod ng isang NAT router na naka-configure na humawak ng isang TCP session sa pamamagitan ng IP address, at dahil gumagamit kami ng UDP, na walang hardware session, hindi hahawakan ng NAT ang koneksyon, at isang QUIC session .
Ang lahat ng mga problemang ito ay dahil sa ang katunayan na ang UDP ay hindi pa ginamit noon upang magpadala ng nilalaman sa Internet, at ang mga tagagawa ng hardware ay hindi mahulaan na ito ay mangyayari. Sa parehong paraan, hindi pa talaga naiintindihan ng mga administrator kung paano i-configure nang maayos ang kanilang mga network para gumana ang QUIC. Ang sitwasyong ito ay unti-unting magbabago, at, sa anumang kaso, ang mga naturang pagbabago ay tatagal ng mas kaunting oras kaysa sa pagpapatupad ng isang bagong transport layer protocol.
Bilang karagdagan, tulad ng inilarawan na, ang QUIC ay lubos na nagpapataas ng paggamit ng CPU. Daniel Stenberg paglago ng processor hanggang tatlong beses.
Kailan darating ang HTTP/3?
Standard sa Mayo 2020, ngunit dahil ang mga dokumentong naka-iskedyul para sa Hulyo 2019 ay nananatiling hindi natapos sa ngayon, maaari nating sabihin na ang petsa ay malamang na maibabalik.
Well, ginagamit ng Google ang gQUIC na pagpapatupad nito mula noong 2013. Kung titingnan mo ang kahilingan sa HTTP na ipinadala sa search engine ng Google, makikita mo ito:
Natuklasan
Ang QUIC ngayon ay mukhang isang medyo krudo, ngunit napaka-promising na teknolohiya. Isinasaalang-alang na sa nakalipas na 20 taon, ang lahat ng mga pag-optimize ng transport layer protocol ay pangunahing may kinalaman sa TCP, QUIC, na sa karamihan ng mga kaso ay may pinakamahusay na pagganap, ay mukhang napakahusay na.
Gayunpaman, mayroon pa ring mga hindi nalutas na mga problema na kailangang harapin sa susunod na ilang taon. Ang proseso ay maaaring maantala dahil sa katotohanan na mayroong hardware na kasangkot, na walang gustong mag-update, ngunit gayunpaman, ang lahat ng mga problema ay mukhang malulutas, at maaga o huli tayong lahat ay magkakaroon ng HTTP/3.
Ang hinaharap ay malapit na!
Pinagmulan: www.habr.com