Protokol QUIC dobio je status predloženog standarda

Radna grupa za internet inženjering (IETF), koja je odgovorna za razvoj internet protokola i arhitekture, finalizirala je RFC za QUIC protokol i objavila povezane specifikacije pod identifikatorima RFC 8999 (svojstva protokola nezavisna od verzije), RFC 9000 (transport preko UDP), RFC 9001 (TLS enkripcija QUIC komunikacionog kanala) i RFC 9002 (kontrola zagušenja i detekcija gubitka paketa tokom prenosa podataka).

RFC-ovi su dobili status “Predloženog standarda”, nakon čega će početi rad na davanju RFC statusa nacrta standarda (Draft Standard), što zapravo znači potpunu stabilizaciju protokola i uzimanje u obzir svih datih komentara. HTTP/3 protokol, koji definiše upotrebu QUIC protokola kao transporta za HTTP/2, još je u fazi izrade specifikacije, ali će uskoro biti konačno standardizovan od strane IETF-a.

Očekuje se da će standardizacija QUIC-a dati podsticaj širem usvajanju ovog protokola, kao i razvoju ekstenzija zasnovanih na njemu, kao što su WebTransport (tehnologija za slanje i primanje podataka između pretraživača i servera) i MASQUE (tehnologija proxy povezivanja koja proširuje mogućnosti SOCKS-a i HTTP CONNECT-a, i koristi HTTPS preko QUIC-a kao transport).

Podsjetimo, QUIC (Quick UDP Internet Connections) protokol razvija Google od 2013. godine kao alternativu TCP+TLS kombinaciji za Web, rješavajući probleme s dugim vremenom podešavanja i pregovaranja veza u TCP-u i eliminirajući kašnjenja kada paketi se gube tokom prijenosa podataka. QUIC je proširenje UDP protokola koje podržava multipleksiranje više veza i pruža metode šifriranja ekvivalentne TLS/SSL-u. Tokom razvoja standarda IETF, u protokolu su unete izmjene, što je dovelo do pojave dvije paralelne grane, jedne za HTTP/3, a druge koju podržava Google (Chrome podržava obje opcije, a Firefox podržava IETF verziju) .

Ključne karakteristike QUIC-a:

  • Visoka sigurnost, slična TLS-u (u stvari, QUIC pruža mogućnost korištenja TLS-a preko UDP-a);
  • Kontrola integriteta toka kako bi se spriječio gubitak paketa;
  • Mogućnost trenutnog uspostavljanja veze (0-RTT, u približno 75% slučajeva podaci se mogu prenijeti odmah nakon slanja paketa za podešavanje veze) i obezbjeđivanje minimalnih kašnjenja između slanja zahtjeva i prijema odgovora (RTT, Round Trip Time);
  • Korištenje različitog broja sekvence prilikom ponovnog slanja paketa, čime se izbjegava dvosmislenost u identifikaciji primljenih paketa i otklanja vremensko ograničenje;
  • Gubitak paketa utiče samo na isporuku toka koji je sa njim povezan i ne zaustavlja isporuku podataka u tokovima koji se prenose paralelno preko trenutne veze;
  • Alati za ispravljanje grešaka koji minimiziraju kašnjenja zbog ponovnog prijenosa izgubljenih paketa. Upotreba posebnih kodova za ispravljanje grešaka na nivou paketa kako bi se smanjile situacije koje zahtijevaju ponovni prijenos izgubljenih paketnih podataka.
  • Granice kriptografskih blokova su usklađene sa granicama QUIC paketa, što smanjuje uticaj gubitka paketa na dekodiranje sadržaja sledećih paketa;
  • Nema problema sa blokiranjem TCP reda;
  • Podrška za ID veze za smanjenje vremena ponovnog povezivanja za mobilne klijente;
  • Mogućnost povezivanja naprednih mehanizama za kontrolu preopterećenja konekcije;
  • Korištenje tehnika predviđanja propusnog opsega u svakom smjeru kako bi se osigurao optimalan intenzitet slanja paketa, sprječavajući prelazak u stanje zagušenja, u kojem dolazi do gubitka paketa;
  • Značajno povećanje performansi i propusnosti u odnosu na TCP. Za video usluge kao što je YouTube, pokazalo se da QUIC smanjuje operacije rebaferiranja prilikom gledanja videa za 30%.

izvor: opennet.ru

Dodajte komentar