Cosa significa multiplexing in HTTP / 2

Qualcuno potrebbe spiegare il multiplexing in relazione a HTTP / 2 e come funziona?

In parole povere, il multiplexing consente al browser di attivare più richieste contemporaneamente sulla stessa connessione e di ricevere le richieste in qualsiasi ordine.

E ora per la risposta molto più complicata ...

Quando carichi una pagina web, scarica la pagina HTML, vede che ha bisogno di CSS, JavaScript, un carico di immagini ... ecc.

Sotto HTTP / 1.1 puoi scaricare solo uno di quelli alla volta sulla tua connessione HTTP / 1.1. Quindi il tuo browser scarica l'HTML, quindi richiede il file CSS. Quando viene restituito, richiede il file JavaScript. Quando viene restituito, richiede il primo file immagine ... ecc. HTTP / 1.1 è fondamentalmente sincrono: una volta inviata una richiesta, sei bloccato finché non ottieni una risposta. Ciò significa che la maggior parte delle volte il browser non sta facendo molto, poiché ha lanciato una richiesta, è in attesa di una risposta, quindi avvia un'altra richiesta, quindi attende una risposta ... ecc. Ovviamente siti complessi con molti JavaScript richiedono che il browser esegua molte elaborazioni, ma ciò dipende dal JavaScript scaricato, quindi, almeno all'inizio, i ritardi ereditati da HTTP / 1.1 causano problemi. In genere il server non è

Quindi uno dei problemi principali sul web oggi è la latenza di rete nell'invio delle richieste tra browser e server. Possono essere solo decine o forse centinaia di millisecondi, il che potrebbe non sembrare molto, ma si sommano e sono spesso la parte più lenta della navigazione sul Web, soprattutto perché i siti Web diventano più complessi e richiedono risorse extra (mentre stanno ottenendo) e l'accesso a Internet è sempre più via mobile (con una latenza più lenta rispetto alla banda larga).

Ad esempio, diciamo che ci sono 10 risorse che la tua pagina web deve caricare dopo che l'HTML è stato caricato (che è un sito molto piccolo per gli standard odierni poiché più di 100 risorse sono comuni, ma lo manterremo semplice e seguiremo questo esempio). E diciamo che ogni richiesta impiega 100 ms per viaggiare attraverso Internet al server web e viceversa e il tempo di elaborazione a entrambe le estremità è trascurabile (diciamo 0 per questo esempio per semplicità). Dato che devi inviare ogni risorsa e attendere una risposta alla volta, questo richiederà 10 * 100 ms = 1.000 ms o 1 secondo per scaricare l'intero sito.

Per aggirare questo problema, i browser di solito aprono più connessioni al server web (in genere 6). Ciò significa che un browser può inviare più richieste contemporaneamente, il che è molto meglio, ma a costo della complessità di dover configurare e gestire più connessioni (che influisce sia sul browser che sul server). Continuiamo l'esempio precedente e diciamo anche che ci sono 4 connessioni e, per semplicità, diciamo che tutte le richieste sono uguali. In questo caso puoi dividere le richieste su tutte e quattro le connessioni, quindi due avranno 3 risorse da ottenere e due avranno 2 risorse per ottenere totalmente le dieci risorse (3 + 3 + 2 + 2 = 10). In tal caso, il caso peggiore è 3 round volte o 300 ms = 0,3 secondi: un buon miglioramento, ma questo semplice esempio non include il costo di configurazione di tali connessioni multiple,

HTTP / 2 ti consente di inviare più richieste sullo stessoconnessione - quindi non è necessario aprire più connessioni come sopra. Quindi il tuo browser può dire "Dammi questo file CSS. Dammi quel file JavaScript. Dammi immagine1.jpg. Dammi immagine2.jpg ... Etc." per utilizzare appieno un'unica connessione. Ciò ha l'ovvio vantaggio in termini di prestazioni di non ritardare l'invio di quelle richieste in attesa di una connessione gratuita. Tutte queste richieste si fanno strada attraverso Internet al server in (quasi) parallelo. Il server risponde a ciascuno e poi iniziano a tornare indietro. In effetti è ancora più potente di così in quanto il server web può rispondere a loro in qualsiasi ordine voglia e inviare i file in un ordine diverso, o addirittura suddividere ogni file richiesto in pezzi e mescolare i file insieme.problema di blocco dell'head of line ). Il browser web ha quindi il compito di rimettere insieme tutti i pezzi. Nel migliore dei casi (supponendo che non ci siano limiti di larghezza di banda - vedi sotto), se tutte e 10 le richieste vengono attivate praticamente contemporaneamente in parallelo e ricevono risposta immediata dal server, ciò significa che in pratica hai un round trip o 100 ms o 0,1 secondi, per scarica tutte le 10 risorse. E questo non ha nessuno degli svantaggi che più connessioni avevano per HTTP / 1.1! Questo è anche molto più scalabile man mano che le risorse su ogni sito web crescono (attualmente i browser aprono fino a 6 connessioni parallele sotto HTTP / 1.1 ma dovrebbe crescere man mano che i siti diventano più complessi?).

Questo diagramma mostra le differenze e c'è anche una versione animata .

Nota: HTTP / 1.1 ha il concetto di pipelining che consente anche di inviare più richieste contemporaneamente. Tuttavia, dovevano ancora essere restituiti nell'ordine in cui erano stati richiesti, nella loro interezza, quindi neanche lontanamente buono come HTTP / 2, anche se concettualmente è simile. Per non parlare del fatto che è così scarsamente supportato sia dai browser che dai server che viene utilizzato raramente.

Una cosa evidenziata nei commenti sottostanti è l'impatto della larghezza di banda su di noi qui. Ovviamente la tua connessione Internet è limitata da quanto puoi scaricare e HTTP / 2 non risolve questo problema. Quindi, se quelle 10 risorse discusse negli esempi precedenti sono tutte immagini di qualità di stampa massiccia, saranno comunque lente da scaricare. Tuttavia, per la maggior parte dei browser Web, la larghezza di banda è un problema minore della latenza. Quindi, se queste dieci risorse sono piccoli elementi (in particolare risorse di testo come CSS e JavaScript che possono essere compressi con gzip per essere minuscole), come è molto comune sui siti Web, la larghezza di banda non è davvero un problema: è l'enorme volume di risorse che spesso è il problema e HTTP / 2 cerca di risolverlo. Questo è anche il motivo per cui la concatenazione viene utilizzata in HTTP / 1.1 come un'altra soluzione alternativa, quindi ad esempio tutti i CSS sono spesso uniti in un unico file:anti-pattern sotto HTTP / 2 - anche se ci sono argomenti contro la completa eliminazione).

Per dirla come un esempio del mondo reale: supponi di dover ordinare 10 articoli da un negozio per la consegna a domicilio:

• HTTP / 1.1 con una connessione significa che devi ordinarli uno alla volta e non puoi ordinare l'elemento successivo finché non arriva l'ultimo. Puoi capire che ci vorrebbero settimane per superare tutto.

• HTTP / 1.1 con più connessioni significa che puoi avere un numero (limitato) di ordini indipendenti in movimento allo stesso tempo.

• HTTP / 1.1 con pipelining significa che puoi chiedere tutti e 10 gli elementi uno dopo l'altro senza aspettare, ma poi arrivano tutti nell'ordine specifico che hai richiesto. E se un articolo è esaurito, devi aspettare prima di ricevere gli articoli che hai ordinato dopo, anche se gli articoli successivi sono effettivamente disponibili! Questo è un po 'meglio ma è ancora soggetto a ritardi e diciamo che la maggior parte dei negozi non supporta comunque questo modo di ordinare.

• HTTP / 2 significa che puoi ordinare i tuoi articoli in qualsiasi ordine particolare, senza ritardi (come sopra). Il negozio li spedirà non appena sono pronti, quindi potrebbero arrivare in un ordine diverso da quello che hai richiesto e potrebbero persino dividere gli articoli in modo che alcune parti di quell'ordine arrivino per prime (quindi meglio di sopra). In definitiva questo dovrebbe significare che 1) ottieni tutto più velocemente e 2) puoi iniziare a lavorare su ogni articolo non appena arriva ("oh non è così bello come pensavo, quindi potrei voler ordinare anche qualcos'altro o invece" ).

Ovviamente sei ancora limitato dalle dimensioni del furgone del tuo postino (la larghezza di banda), quindi potrebbero dover lasciare alcuni pacchi all'ufficio di smistamento fino al giorno successivo se sono pieni per quel giorno, ma questo è raramente un problema rispetto al ritardo nell'effettivo invio dell'ordine di andata e ritorno. La maggior parte della navigazione sul Web comporta l'invio di lettere minuscole avanti e indietro, piuttosto che pacchetti ingombranti.

Spero che aiuti.

Risposta semplice ( fonte ):

Multiplexing significa che il tuo browser può inviare più richieste e ricevere più risposte "raggruppate" in una singola connessione TCP. Quindi il carico di lavoro associato alle ricerche DNS e agli handshake viene salvato per i file provenienti dallo stesso server.

Risposte complesse / dettagliate:

Guarda la risposta fornita da @BazzaDP.

Il multiplexing in HTTP 2.0 è il tipo di relazione tra il browser e il server che utilizza una singola connessione per fornire più richieste e risposte in parallelo, creando molti frame individuali in questo processo.

Il multiplexing si allontana dalla rigida semantica richiesta-risposta e consente relazioni uno-a-molti o molti-a-molti.

Richiedi multiplexing

HTTP / 2 può inviare più richieste di dati in parallelo su una singola connessione TCP. Questa è la funzionalità più avanzata del protocollo HTTP / 2 perché consente di scaricare file Web in modo asincrono da un server. La maggior parte dei browser moderni limita le connessioni TCP a un server. Ciò riduce il tempo di andata e ritorno aggiuntivo (RTT), rendendo il caricamento del sito Web più veloce senza alcuna ottimizzazione e rende superfluo lo sharding del dominio.

Poiché la risposta di @Juanma Menendez è corretta mentre il suo diagramma è confuso, ho deciso di migliorarlo, chiarendo la differenza tra multiplexing e pipelining, le nozioni che sono spesso fuse.

Pipelining (HTTP / 1.1)

Più richieste vengono inviate sulla stessa connessione HTTP. Le risposte vengono ricevute nello stesso ordine. Se la prima risposta richiede molto tempo, le altre devono attendere in fila. Simile al pipeling della CPU in cui un'istruzione viene recuperata mentre un'altra viene decodificata. Più istruzioni sono in volo contemporaneamente, ma il loro ordine viene mantenuto.

Multiplexing (HTTP / 2)

Più richieste vengono inviate sulla stessa connessione HTTP. Le risposte vengono ricevute in ordine arbitrario. Non è necessario attendere una risposta lenta che blocca gli altri. Simile all'esecuzione di istruzioni fuori ordine nelle moderne CPU.

Si spera che l'immagine migliorata chiarisca la differenza: