Googles uitgangspunten voor QUIC

Websites bestaan uit veel kleine elementen (zoals afbeeldingen, CSS-bestanden, scripts), die allemaal apart en vaak van verschillende servers geladen moeten worden. Omdat elke afzonderlijke toegang tijd kost (het opbouwen van een TCP-verbinding, het versturen van het HTTP-request, het wachten op het antwoord), wil je eigenlijk alle HTTP-requests tegelijkertijd kunnen versturen. Dat idee zit bijvoorbeeld in HTTP 2.0.

Maar HTTP 2.0 is bij het opbouwen van TLS-verbindingen net zo langzaam als HTTP 1.1 en net zo gevoelig voor overdrachtsfouten. Als je namelijk meerdere logische HTTP-verbindingen via één TCP-verbinding afhandelt, is dat vanuit het oogpunt van TCP dan een enkele datastroom. Als er dan een overdrachtsfout optreedt, vraagt de TCP-stack van de client het gemiste pakket opnieuw bij de server op.

Het duurt dan even voor die aangekomen is. In de tussentijd komen er wel andere pakketten binnen. Die kan de TCP-stack van de client echter pas aan de browser doorgeven als ook het opnieuw opgevraagde pakket aangekomen is. Dat remt alle logische HTTP-verbindingen af (head-of-line blocking). Een oplossing is dan om voor elke HTTPverbinding een eigen TCP-verbinding op te bouwen. Maar dat kost resources bij de server. Daarom wil Google alle problemen met een nieuw protocol oplossen: het opbouwen van alle overdrachtslagen moet in één keer gebeuren (verbinding, versleuteling, HTTP), plus end-to-endversleuteling en meerdere van elkaar onafhankelijke logische HTTP-verbindingen.

QUIC combineert in essentie eigenschappen van TCP, TLS en HTTP tot één transportlaag voor HTTP. Voor HTTP-requests en -responses gebruikt QUIC dan afzonderlijke streams.