QUIC protokoloak proposatutako estandar baten egoera jaso du.

Internet Engineering Task Force-k (IETF), Interneteko protokoloen eta arkitekturaren garapenaz arduratzen dena, QUIC protokoloaren RFC amaitu du eta erlazionatutako zehaztapenak argitaratu ditu RFC 8999 (bertsioaren araberako protokoloaren propietateak), RFC 9000 (garraioa). UDP baino gehiago), RFC 9001 (QUIC komunikazio kanalaren TLS enkriptatzea) eta RFC 9002 (pilaketa kontrola eta pakete-galeren detekzioa datu-transmisioan zehar).

RFCek "Proposatutako Estandarra" egoera jaso zuten, eta ondoren, RFCri estandar zirriborro baten egoera (Draft Standard) egoera emateko lanak hasiko dira, hau da, protokoloaren guztiz egonkortzea eta egindako iruzkin guztiak kontuan hartuta. HTTP/3 protokoloa, QUIC protokoloaren erabilera HTTP/2rako garraio gisa definitzen duena, zirriborroaren zehaztapen fasean dago oraindik, baina laster behin betiko estandarizatuko du IETFk.

Aurreikuspenen arabera, QUIC estandarizazioak bultzada emango dio protokolo hau gehiago hartzeko, baita horretan oinarritutako luzapenen garapenari ere, hala nola WebTransport (nabigatzaile baten eta zerbitzari baten artean datuak bidali eta jasotzeko teknologia) eta MASQUE. (SOCKS eta HTTP CONNECT-en gaitasunak hedatzen dituen konexio-proxy teknologia, eta HTTPS QUIC bidez garraio gisa erabiltzen duena).

Gogora dezagun QUIC (Quick UDP Internet Connections) protokoloa Google-k garatu duela 2013tik Weberako TCP+TLS konbinazioaren alternatiba gisa, TCPn konexioen konfigurazio eta negoziazio denbora luzeen arazoak konpontzeko eta atzerapenak ezabatuz. datuak transferitzean paketeak galtzen dira. QUIC UDP protokoloaren luzapena da, hainbat konexio multiplexatzea onartzen duena eta TLS/SSL-ren baliokideak diren enkriptatze-metodoak eskaintzen dituena. IETF estandarraren garapenean, aldaketak egin ziren protokoloan, eta bi adar paralelo sortu ziren, bata HTTP/3rako, eta bigarrena Google-k onartzen duena (Chrome-k bi aukerak onartzen ditu, eta Firefoxek IETF bertsioa onartzen du) .

QUIC-en ezaugarri nagusiak:

  • TLSren antzeko segurtasun handia (funtsean QUIC-ek TLS UDPren gainean erabiltzeko gaitasuna ematen du);
  • Fluxuaren osotasunaren kontrola, paketeak galtzea saihestuz;
  • Konexio bat berehala ezartzeko gaitasuna (0-RTT, kasuen % 75ean, gutxi gorabehera, datuak konexioa konfiguratzeko paketea bidali eta berehala transmititu daitezke) eta eskaera bat bidali eta erantzuna jaso arteko atzerapen minimoak eskaintzea (RTT, Joan-etorriko Denbora);
  • Pakete bat birtransmititzean sekuentzia-zenbaki ezberdin bat erabiltzea, jasotako paketeak identifikatzeko anbiguotasuna saihesten duena eta denbora-muga kentzen duena;
  • Pakete bat galtzeak hari lotutako korrontearen entregari bakarrik eragiten dio eta ez du geldiarazten datuen bidalketa uneko konexioaren bidez transmititutako korronte paraleloetan;
  • Erroreak zuzentzeko eginbideak, galdutako paketeen birtransmisioaren ondoriozko atzerapenak murrizten dituztenak. Erroreak zuzentzeko kode bereziak erabiltzea pakete mailan, galdutako datu-paketeen birtransmisioa behar duten egoerak murrizteko.
  • Bloke kriptografikoen mugak QUIC paketeen mugekin lerrokatzen dira, eta horrek pakete-galeren eragina murrizten du ondorengo paketeen edukiak deskodetzeko;
  • TCP ilarak blokeatzeko arazorik ez;
  • Konexio-identifikatzailerako euskarria, bezero mugikorrentzako birkonexioa ezartzeko behar den denbora murrizten duena;
  • Konexio-pilaketak kontrolatzeko mekanismo aurreratuak konektatzeko aukera;
  • Norabide bakoitzeko iragarpenaren iragarpen teknikak erabiltzen ditu paketeak tasa optimoetan bidaltzen direla ziurtatzeko, pilatuta egotea eta paketeak galtzea ekiditeko;
  • Errendimenduaren eta errendimenduaren igoera nabarmena TCPrekin alderatuta. YouTube bezalako bideo-zerbitzuetarako, QUIC-ek bideoak ikustean birbuffering-eragiketak % 30 murrizten dituela frogatu da.

Iturria: opennet.ru

Gehitu iruzkin berria