SPDY è diverso da multiplexing http su connessioni keep alive

HTTP 1.1 supporta le connessioni keep alive, le connessioni non vengono chiuse fino a quando viene inviato "Connection: close".SPDY è diverso da multiplexing http su connessioni keep alive

Quindi, se il browser, in questo caso, firefox ha rete.http.pipelining abilitata e network.http.pipelining.maxrequest aumentato non ha lo stesso effetto alla fine?

So che queste impostazioni sono disabilitate perché per alcuni siti web questo potrebbe aumentare il carico ma penso che una semplice bandiera di intestazione http potrebbe dire al browser che stai usando il multiplexing e questo problema può essere risolto più facilmente.

Non sarebbe più semplice modificare le impostazioni predefinite nei browser piuttosto che inventare un nuovo protocollo che aumenti la complessità soprattutto nei server http?

fonte

2012-04-28 codeassembly

SPDY utilizza la compressione stateful su richiesta e risposta intestazioni. –

Questo fa una grande differenza (specialmente per la normale compressione che hai già in SSL)? – Thilo

http può anche usare la compressione con gzip, quasi tutti i browser la supportano, e le intestazioni di solito sono troppo piccole per importare – codeassembly

SPDY ha una serie di vantaggi che vanno al di là di quanto HTTP pipelining può offrire, che sono descritte nel SPDY whitepaper:

Con pipelining, il server deve ancora restituire il risposte una alla volta nell'ordine sono stati richiesti Questo può essere un problema se il client richiede una risorsa generata dinamicamente prima di una che è statica: il server non può inviare nessuna delle "facili" risposte statiche finché non ne viene generato e inviato uno generato dinamicamente. Con SPDY, le risposte possono essere restituite in ordine o in parallelo mentre vengono generate, riducendo il tempo totale di ricezione di tutte le risorse.
Come hai notato nella tua domanda, non tutti i server sono in grado di gestire il pipelining: non è solo carico, alcuni server si comportano in modo errato quando il client richiede il pipelining. Usare un'intestazione per indicare che è corretto fare il pipelining è troppo tardi per ottenere il massimo beneficio: stai già ricevendo la prima risposta a quel punto, quindi mentre puoi usarlo nelle connessioni future è già troppo tardi per questo.
SPDY comprime le intestazioni utilizzando un algoritmo specifico per tale attività (stateful e con conoscenza di ciò che è normalmente nelle intestazioni HTTP); mentre sì, SSL include già la compressione, solo comprimerli con deflate non è altrettanto efficiente. La maggior parte delle richieste HTTP non ha corpi e solo una breve riga GET, quindi le intestazioni costituiscono praticamente l'intera richiesta: qualsiasi compressione che si può ottenere è un miglioramento. Molte risposte sono anche piccole rispetto alle intestazioni.
SPDY consente ai server di inviare risposte aggiuntive senza che il client le richieda. Ad esempio, un server potrebbe iniziare a rinviare il CSS per una pagina insieme all'HTML originale, prima che il client abbia avuto la possibilità di ricevere e analizzare il codice HTML per determinare l'URL del foglio di stile. Ciò può accelerare ulteriormente i carichi di pagina, eliminando la necessità per il client di analizzare effettivamente l'HTML prima di richiedere altre risorse necessarie per il rendering della pagina. Supporta anche una versione meno pesante della larghezza di banda di questa funzione in cui può "suggerire" quali risorse potrebbero essere necessarie e consentire al cliente di decidere: questo consente, ad esempio, ai clienti che non si preoccupano delle immagini di non disturbarsi richiederli, ma i clienti che desiderano visualizzare le immagini possono comunque richiedere le immagini utilizzando gli URL indicati senza dover attendere l'HTML.
Altre cose: vedere la risposta di William Chan per ancora di più.

fonte

2012-04-28 09:57:03 Torne

Non è il server a spingere la stessa funzione che stai descrivendo in # 4? –

Sì, lo è. Modificato. :) – Torne

Il numero 2 non è corretto in quanto la prima connessione necessita del contenuto (HTML) per sapere cosa deve ricevere successivamente. Durante l'analisi di HTML, il pipelining è quindi già in vigore. – Lothar

HTTP pipelining è suscettibile di testa a livello di transazione HTTP che SPDY linea di blocco (http://en.wikipedia.org/wiki/Head-of-line_blocking) ha solo testa della linea di blocco a il livello di trasporto, grazie al suo uso del multiplexing.
Il pipelining HTTP presenta problemi di distribuzione. Vedere http://tools.ietf.org/html/draft-nottingham-http-pipeline-01 che descrive una serie di soluzioni alternative ed euristiche per attenuarlo.SPDY come implementato in natura non presenta questo problema poiché viene generalmente distribuito su SSL (porta 443) utilizzando NPN (http://technotes.googlecode.com/git/nextprotoneg.html) per negoziare il supporto SPDY. SSL è fondamentale, poiché impedisce agli intermediari di interferire.
SPDY ha una compressione di intestazione. Vedere http://dev.chromium.org/spdy/spdy-whitepaper che illustra alcuni risultati di benchmark dei vantaggi della compressione dell'intestazione. Ora, è utile notare che la larghezza di banda è sempre meno un problema (vedere http://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/), ma è anche utile ricordare che la larghezza di banda è ancora la chiave per i dispositivi mobili. Controlla https://developers.google.com/speed/articles/spdy-for-mobile che mostra quanto sia utile SPDY per i dispositivi mobili.
SPDY supporta funzionalità come server push. Vedere http://dev.chromium.org/spdy/spdy-best-practices per i modi in cui utilizzare server push per migliorare la cache dei contenuti e ridurre ancora i viaggi di andata e ritorno.
La pipelining HTTP ha una semantica di errore non definita. Quando il server chiude la connessione, come fai a sapere quali richieste sono state elaborate con successo? Questo è uno dei motivi principali per cui POST e altre richieste non identi che non sono consentite sulle connessioni con pipeline. SPDY fornisce semantica per cancellare singoli flussi sulla stessa connessione e ha anche un frame GOAWAY che indica l'ultimo flusso da elaborare correttamente.
Il pipelining HTTP ha difficoltà, spesso a causa degli intermediari, nel consentire la realizzazione di condotte profonde. Questo (oltre a molti altri motivi come il blocco HoL) significa che è ancora necessario utilizzare più connessioni TCP per ottenere la massima parallelizzazione. L'utilizzo di più connessioni TCP significa che le informazioni sul controllo della congestione non possono essere condivise, che i contesti di compressione non possono essere condivisi (come SPDY fa con le intestazioni), è peggio per Internet (più costoso per intermediari e server).