Inihayag ng Google ilang araw na ang nakakaraan nagsimula na ito sa ang paglalagay ng HTTP / 3 at IETF QUIC sa Chrome at sa anunsyo, sinabi niya na inaasahan niya ang pag-update na ito na magdadala ng ilang karagdagang mga pagpapabuti sa pagganap, lalo na sa suporta para sa QUIC.
Ang QUIC ay isang bagong network transport protocol na pinagsasama ang mga tampok ng TCP, TLS at marami pa. Ang HTTP / 3 ang pinakabagong bersyon ng HTTP, ang protocol na nagdadala ng karamihan sa trapiko sa web. Gumagana lamang ang HTTP / 3 sa QUIC.
Ang Internet Engineering Task Force, o IETF, ay nagpakilala ng HTTP / 2 noong 2015 at ang isa sa malalaking pagpapahusay na ginawa nito ay ang suporta para sa multiplexing.
Gayunpaman, ginamit nito ang TCP bilang transport protocol at ang mga mekanismo ng pagbawi ng pagkawala sa TCP, kaya't ang mga nawalang packet ay maaari pa ring maging sanhi ng pagkaantala sa lahat ng mga aktibong transaksyon.
Sa pamamagitan ng pag-aampon ng QUIC, ang HTTP / 3 ay maaaring karagdagang mapabuti ang proseso ng paglipat, dahil ang mga nawalang packet sa kasong ito ay nakakaapekto lamang sa mga direktang apektadong transaksyon.
Sa katunayan, Ang QUIC ay orihinal na binuo ng Google at unang inihayag noong 2013. Simula noon, ang protokol ay dumating sa edad at kasalukuyang responsable para sa pagdala ng isang ikatlo ng trapiko ng Google.
Pagkatapos, noong 2015, ang pagbuo ng QUIC ay ipinasa sa mga kamay ng IETF, ang pamantayang katawan na responsable sa pagpapanatili ng mga Internet protocol. Pinagbuti ng IETF ang QUIC na may maraming mga pagbabago. Sa ngayon, mayroong dalawang magkatulad, ngunit magkakaibang mga protokol, na kung saan ay: Google QUIC at IETF QUIC.
Inanunsyo ng Google na palaging gumagamit ito ng sarili nitong bersyon ng QUIC, ngunit ang kanyang koponan ng QUIC ay kasangkot din sa pagpapatupad ng pagmamay-ari na bersyon ng IEFT. "Nagsagawa kami ng mga makabuluhang pagsisikap na mai-evolve ang Google QUIC sa nakaraang limang taon upang makasabay sa mga pagbabagong ginawa ng IETF, at ang kasalukuyang pinakabagong bersyon ng Google QUIC ay maraming pagkakatulad sa IETF QUIC," binabasa ng post sa blog. Mula sa Google, at saka, nilinaw na ang ilang mga bagay ay nawawala pa rin.
Bilang isang halimbawa, sa ngayon karamihan sa mga gumagamit ng Chrome ay hindi maaaring makipag-usap sa mga server ng IETF QUIC nang hindi pinapagana ang ilang mga pagpipilian sa linya ng utos. Gayundin, Idinagdag ng Google na natagpuan na ngayon na ang IETF QUIC ay makabuluhang lumalagpas sa HTTP kumpara sa TLS 1.3 kumpara sa TCP.
Sa partikular, sinabi ng kumpanya na ang latency ng search engine ng Google ay nabawasan ng higit sa 2%. Ang buffering time ng YouTube ay nabawasan ng higit sa 9%. Bilang karagdagan, ang pagganap ng kliyente ay tumaas ng higit sa 3% sa mga desktop computer.
Sa mga mobile phone, tumaas ang pagganap ng customer ng higit sa 7%. Ang mga ito at iba pang mga kadahilanan ay nasa likod ng paglipat ng Chrome sa QUIC na bersyon ng IETF. "Ikinalulugod naming ipahayag na inilalabas ng Chrome ang suporta para sa IETF QUIC (partikular, ang h3-29 na pilot na bersyon).
Ngayon, halos 25% ng mga gumagamit ng matatag na bersyon ng Chrome ang gumagamit ng h3-29, at plano naming dagdagan ang bilang na ito sa mga darating na linggo sa pamamagitan ng patuloy na pagsubaybay sa data ng pagganap, "sinabi ng kumpanya sa post sa blog nito.
"Aktibong susuportahan ng Chrome ang parehong IETF QUIC h3-29 at ang bersyon ng Google QUIC (Q050) upang maglaan ng oras para sa mga server na sumusuporta sa Q050 upang mag-upgrade sa IETF QUIC," dagdag niya. Hindi pa sinusuportahan ng Chrome m85 ang IETF QUIC 0-RTT at inaasahan ng Google na mas mahusay ang pagganap na ito kapag naglabas ito ng suporta para sa IETF QUIC 0-RTT sa mga susunod na buwan. Gayundin, dahil ang mga bersyon ng IETF QUIC na 30 at 31 ay hindi naglalaman ng mga pagbabago na maaaring masira ang pagiging tugma, hindi plano ng kumpanya na baguhin ang identifier na "over-the-wire".
Nangangahulugan ito na ay magpapatuloy na subaybayan ang mga pagbabago sa bersyon ng IETF, ngunit ang ipapatupad bilang h3-29 / 0xff00001d.
Samakatuwid, inirekomenda nito na patuloy na suportahan ng mga server ang h3-29 hanggang sa makumpleto ang mga huling RFC kung nais nilang makipag-ugnay sa Chrome. Gayunpaman, kung ang IETF ay gumawa ng mga pagbabago na sumisira sa pagiging tugma sa isang hinaharap na proyekto, ibabalik ng Chrome ang desisyon na iyon.
Fuente: https://blog.chromium.org