QUIC

De la Viquipèdia, l'enciclopèdia lliure
Model TCP/IP
per capes
Xarxes informàtiques
  • Vegeu aquesta plantilla

QUIC (pronunciat "ràpid") és un protocol de xarxa de propòsit general de capa de transport dissenyat inicialment per Jim Roskind a Google, implementat i desplegat el 2012, anunciat públicament el 2013 a mesura que s'ampliava l'experimentació, i descrit en una reunió de l'IETF. QUIC és utilitzat per més de la meitat de totes les connexions des del navegador web Chrome als servidors de Google.[1] Microsoft Edge (un derivat del navegador de codi obert Chromium) [2][3] i Firefox [4] ho admeten. Safari implementa el protocol, però no està habilitat per defecte.[5]

Encara que el seu nom es va proposar inicialment com l'acrònim de "Quick UDP Internet Connections", l'ús de la paraula QUIC per part de l'IETF no és un acrònim; és simplement el nom del protocol. QUIC millora el rendiment de les aplicacions web orientades a la connexió que actualment utilitzen TCP.[6] Això ho fa mitjançant l'establiment d'una sèrie de connexions multiplexades entre dos punts finals utilitzant el protocol de datagrama d'usuari (UDP) i està dissenyat per obsoler TCP a la capa de transport per a moltes aplicacions, guanyant així al protocol el sobrenom ocasional de "TCP/2".

QUIC funciona conjuntament amb les connexions multiplexades HTTP/2, permetent que múltiples fluxos de dades arribin a tots els punts finals de manera independent i, per tant, independentment de les pèrdues de paquets que impliquen altres fluxos. En canvi, HTTP/2 allotjat al Protocol de control de transmissió (TCP) pot patir retards de bloqueig de cap de línia de tots els fluxos multiplexats si algun dels paquets TCP es retarda o es perd.

Els objectius secundaris de QUIC inclouen la reducció de la latència de connexió i transport i l'estimació de l'ample de banda en cada direcció per evitar la congestió. També mou els algorismes de control de congestió a l'espai d'usuari en ambdós punts finals, en lloc de l'espai del nucli, que s'afirma que permetrà que aquests algorismes millorin més ràpidament. A més, el protocol es pot ampliar amb la correcció d'errors cap endavant (FEC) per millorar encara més el rendiment quan s'esperen errors, i això es considera el següent pas en l'evolució del protocol. S'ha dissenyat per evitar l'ossificació del protocol de manera que es mantingui evolucionable, a diferència del TCP, que ha patit una ossificació important.

Encaixada de mans de QUIC en comparació amb TCP amb TLS1.2

El juny de 2015, es va presentar un esborrany d'Internet d'una especificació per a QUIC a l' IETF per a l'estandardització.[7] El 2016 es va establir un grup de treball QUIC [8] L'octubre de 2018, els grups de treball HTTP i QUIC de l'IETF van decidir conjuntament anomenar el mapeig HTTP a través de QUIC " HTTP/3 " abans de convertir-lo en un estàndard mundial. El maig de 2021, l'IETF va estandarditzar QUIC , amb el suport de RFC 9989, RFC 9001 i RFC 9002.[9] DNS-over-QUIC és una altra aplicació.

Rerefons[modifica]

El protocol de control de transmissió, o TCP, té com a objectiu proporcionar una interfície per enviar fluxos de dades entre dos punts finals. Les dades es lliuren al sistema TCP, que garanteix que les dades arribin a l'altre extrem exactament de la mateixa forma, o la connexió indicarà que existeix una condició d'error.[10]

Per fer-ho, TCP divideix les dades en paquets de xarxa i afegeix petites quantitats de dades a cada paquet. Aquestes dades addicionals inclouen un número de seqüència que s'utilitza per detectar paquets que es perden o arriben fora d'ordre, i una suma de verificació que permet detectar els errors dels paquets de dades. Quan es produeix algun problema, TCP utilitza la sol·licitud de repetició automàtica (ARQ) per dir al remitent que torni a enviar el paquet perdut o danyat.[11]

Característiques[modifica]

QUIC pretén ser gairebé equivalent a una connexió TCP però amb una latència molt reduïda. Ho fa principalment mitjançant dos canvis que es basen en la comprensió del comportament del trànsit HTTP.[12]

HTTP/1Transport Layer SecurityTransmission Control ProtocolHTTP/2TLS 1.2Transmission Control ProtocolHTTP/3TLS 1.3QUICUser Datagram ProtocolInternet Protocol
Protocol stack of HTTP/3 compared to HTTP/1.1 and HTTP/2

El primer canvi és reduir molt la sobrecàrrega durant la configuració de la connexió. Com que la majoria de connexions HTTP exigiran TLS, QUIC fa que l'intercanvi de claus de configuració i protocols admesos sigui part del procés inicial d'enllaç. Quan un client obre una connexió, el paquet de resposta inclou les dades necessàries perquè els paquets futurs utilitzin el xifratge. Això elimina la necessitat de configurar la connexió TCP i després negociar el protocol de seguretat mitjançant paquets addicionals. Altres protocols es poden atendre de la mateixa manera, combinant diversos passos en un sol parell sol·licitud-resposta. Aquestes dades es poden utilitzar tant per a les sol·licituds següents a la configuració inicial, com per a sol·licituds futures que, d'altra manera, es negociarien com a connexions separades.[13]

Aplicacions[modifica]

QUIC es va desenvolupar tenint en compte HTTP i HTTP/3 va ser la seva primera aplicació.[14][15] DNS-over-QUIC és una aplicació de QUIC per a la resolució de noms, que proporciona seguretat per a les dades transferides entre resolutors similars a DNS-over-TLS. L'IETF també està desenvolupant una aplicació de QUIC per fer un protocol de túnel segur.[15] XMPP s'ha adaptat experimentalment per utilitzar QUIC.[16] Una altra aplicació és SMB over QUIC, que, segons Microsoft, pot oferir una "VPN SMB" sense afectar l'experiència de l'usuari.[17] Els clients SMB utilitzen TCP de manera predeterminada i intentaran QUIC si l'intent de TCP falla o si requereixen QUIC intencionadament.

Referències[modifica]

  1. ↑ Lardinois, Frederic. «Google Wants To Speed Up The Web With Its QUIC Protocol» (en anglès). TechCrunch, 18-04-2015. [Consulta: 25 octubre 2016].
  2. ↑ Mackie, Kurt. «Microsoft Embracing Native QUIC in Newer Windows OSes and Edge Browser» (en anglès americà). Redmond Magazine. [Consulta: 8 maig 2022].
  3. ↑ Christopher Fernandes. «Microsoft to add support for Google's QUIC fast internet protocol in Windows 10 Redstone 5» (en anglès), April 3, 2018. [Consulta: 8 maig 2020].
  4. ↑ Dragana Damjanovic. «QUIC and HTTP/3 Support now in Firefox Nightly and Beta» (en anglès). Mozilla, 16-04-2021. [Consulta: 11 octubre 2021].
  5. ↑ «The state of QUIC and HTTP/3 2020» (en anglès). www.fastly.com, 10-09-2020. [Consulta: 21 octubre 2020].
  6. ↑ Lardinois, Frederic. «Google Wants To Speed Up The Web With Its QUIC Protocol» (en anglès). TechCrunch, 18-04-2015. [Consulta: 25 octubre 2016].
  7. ↑ «Google Will Propose QUIC As IETF Standard» (en anglès). InfoQ. [Consulta: 25 octubre 2016].
  8. ↑ «QUIC - IETF Working Group» (en anglès). datatracker.ietf.org. [Consulta: 25 octubre 2016].
  9. ↑ «QUIC is now RFC 9000» (en anglès americà). www.fastly.com, 27-05-2021. [Consulta: 28 maig 2021].
  10. ↑ Bright, Peter. «The next version of HTTP won't be using TCP» (en anglès). Arstechnica, 12-11-2018.
  11. ↑ Bright, Peter. «The next version of HTTP won't be using TCP» (en anglès). Arstechnica, 12-11-2018.
  12. ↑ Bright, Peter. «The next version of HTTP won't be using TCP» (en anglès). Arstechnica, 12-11-2018.
  13. ↑ Bright, Peter. «The next version of HTTP won't be using TCP» (en anglès). Arstechnica, 12-11-2018.
  14. ↑ Bishop, Mike. «HTTP/3 and QUIC: Past, Present, and Future» (en anglès). Akamai, 21-06-2021.
  15. ↑ 15,0 15,1 Duke, Martin. «A new era in Internet transport» (en anglès). IETF, 03-06-2021.
  16. ↑ Burtrum, Travis. «XEP-0467: XMPP over QUIC» (en anglès), 13-07-2022.
  17. ↑ Pyle, Ned. «SMB over QUIC» (en anglès americà). learn.microsoft.com, 27-06-2023. [Consulta: 29 juny 2023].
Obtingut de «https://ca.wikipedia.org/w/index.php?title=QUIC&oldid=32683676»