On September 11, 2020 9:05:29 AM UTC, Marco Mellia <marco.mellia@polito.it> wrote:

Ciao Giacomo,

Una precisazione - ci sono decine di articoli scientifici che dicono che dal punto di vista delle prestazioni QUIC non migliora il page load time (e indici simili). Per l’utente - se va bene - non cambia nulla dal punto di vista prestazioni. Sopratutto per quelle pagine che scaricano molte risorse da fonti diverse.

Grazie mille della correzione, Marco. Cercherò di approfondire, ma se potessi condividere qualche riferimento specifico, sarei felice di leggerlo. Mi sorprende che l'integrazione dell'handshake TLS in quello di QUIC, il ripristino delle connessioni senza round trip e l'uso di stream indipendenti per le diverse risorse non riducano percepibilmente i tempi di scaricamento. In effetti questo potrebbe integrarsi bene con una novità introdotta da Google nella sua offerta cloud: il sistema di reverse proxy integrato per permettere ai sistemi di sorveglianza di bypassare ads-blocker e simili. In questo modo la connessione QUIC al reverse proxy verrebbe condivisa, fornendo un vantaggio competitivo a chi lo adotta, producendo pagine più veloci solo per i fornitori di contenuti che scelgono di abilitarlo, ma rallentando gli altri. Analogamente a quanto avverrebbe con AMP, d'altro canto. Insomma, un modo per rafforzare sempre di più il proprio potere di mercato (e quello di colossi simili) rallentando indirettamente tutti gli altri. D'altronde è tutto Open Washed^W Source! Comunque è certamente un tema che devo approfondire. Grazie ancora! Giacomo PS: Non è divertente che proprio uno degli architetti di QUIC abbia scritto e fatto approvare dalla Internet Architecture Board questo RFC https://www.rfc-editor.org/rfc/rfc8890 ? Forse voleva scrivere "The Internet is for End Useds"! Dannati correttori automatici! :-D