Perché il pipelining è disattivato nei browser moderni?

Question

Molti, se non tutti i browser moderni non utilizzano le richieste HTTP pipeline. In teoria il pipelining dovrebbe accelerare le richieste riducendo il numero di round trip necessari per recuperare un sito web.

Secondo lo standard HTTP, tutti i server devono gestire le richieste pipeline, quindi il problema non dovrebbe essere in mancanza di supporto sui server.

Ho riscontrato alcuni problemi di sicurezza, come un attacco DoS di livello 7 se un client invia il maggior numero possibile di richieste pipeline a un URL a prestazioni elevate per il server, ignorando tutte le risposte che potrebbero essere ricevute.

Questo sarebbe un motivo per disattivare il supporto pipeline sul server (violando lo standard), ma non riesco a trovare alcun motivo per disattivarlo sui client.

Tuttavia, è attivato per impostazione predefinita sui browser Android e sui dispositivi mobili Chrome.

Perché Chrome, Firefox, IE, Opera e Safari non utilizzano le richieste HTTP pipeline nella loro versione desktop (e talvolta mobile)? Qual è il loro ragionamento dietro la disattivazione?

Answer 1

pipelining è disattivata per i seguenti motivi:

• Firefox:

Il problema più grande è stato francamente capo della linea di blocco e il suo impatto sulle prestazioni e la robustezza. Gli oleodotti Naïve semplicemente peggiorano le prestazioni.

• Chrome:

L'opzione per abilitare il pipelining è stato rimosso da Chrome, in quanto vi sono noti bug che si infrangono e front-of-coda di blocco problemi noti. Ci sono anche un gran numero di server e middlebox che si comportano male e incoerentemente quando il pipelining è abilitato. Fino a quando questi non saranno risolti, si raccomanda che nessuno usi il pipelining. Al momento, è necessario creare una build personalizzata di Chromium.

In generale:

Buggy deleghe sono ancora comuni e queste portano a comportamenti strani e irregolari che gli sviluppatori Web non possono prevedere e diagnosticare con facilità.

Il pipelining è complesso da implementare correttamente: la dimensione della risorsa che viene trasferita, l'RTT effettivo che verrà utilizzato, così come l'effettiva larghezza di banda, hanno un'incidenza diretta sul miglioramento fornito dalla pipeline. Senza saperlo, i messaggi importanti potrebbero essere ritardati da quelli non importanti. La nozione di importante si evolve anche durante il layout della pagina! Il pipelining HTTP porta quindi a un miglioramento marginale solo nella maggior parte dei casi.

Il pipelining è soggetto allo HOL problem.

HTTP/2 offre un'alternativa: la capacità

con HTTP/1.x, il browser ha limitato a sfruttare i dati di priorità di cui sopra: il protocollo non supporta il multiplexing, e non c'è modo di comunicare la priorità della richiesta al server. Invece, deve fare affidamento sull'uso di connessioni parallele, che consente il parallelismo limitato di un massimo di sei richieste per origine. Di conseguenza, le richieste vengono accodate al client fino a quando non è disponibile una connessione, che aggiunge una latenza di rete non necessaria. In teoria, HTTP Pipelining ha cercato di risolvere parzialmente questo problema, ma in pratica non è riuscito ad ottenere l'adozione.

HTTP/2 risolve queste inefficienze: l'accodamento delle richieste e il blocco della linea di testa sono eliminati perché il browser può inviare tutte le richieste nel momento in cui vengono scoperte e il browser può comunicare le preferenze di prioritizzazione del flusso tramite dipendenze e pesi dello stream, consentendo al server di ottimizzare ulteriormente la consegna della risposta.

Un proxy può essere usato così:

Si può provare qualcosa che ho fatto per accelerare Konqueror in KDE3. Non ero soddisfatto del fatto che Konqueror non avesse pipeline HTTP, quindi dopo alcune ricerche, ho installato Polipo come proxy HTTP/HTTPS/FTP locale e ho impostato Konqueror per usarlo (localhost sulla porta 8123 se ricordo male). Oltre al pipelining HTTP, Polipo ha anche migliorato il caching, e dato che era un proxy, potevo impostare ogni browser per usarlo e il caching sarebbe stato condiviso tra i browser. (Questo significa anche che è una buona idea disabilitare il caching indipendente di ciascun browser.)

Riferimenti

• Mozilla Bug 264354 – Enable HTTP pipelining by default

• HTTP Pipelining - The Chromium Projects

• Chromium Issue 364557: Remove pipelining code from Chrome

• Understanding Connection Limits and New Proxy Connection Limits in WinInet and Internet Explorer – Http Client Protocol Issues (and other fun stuff I support)

• HTTPS and Keep-Alive Connections – IEInternals

• Changes in WinHttp on Windows 7 and onwards wrt HTTP/1.0 – HTTPContext

• Content-Length and Transfer-Encoding Validation in the IE10 Download Manager – IEInternals

• Use Sensible Long-Lived Cache headers – IEInternals

• Web Performance : 2015 : March | Akamai Community

• WebSockets, caution required!

• HTTP: HTTP/2 - High Performance Browser Networking (O'Reilly)

• HTTP Pipelining - Not So Fast...(Nor Slow!) – Guy's Pod

• Persistent Connection Behavior of Popular Browsers

• Connection management in HTTP/1.x - HTTP | MDN

• Download Resumption in Internet Explorer – IEInternals

• Networking Improvements in IE10 and Windows 8 – IEInternals

• Konqueror very slowly (KDE4) • KDE Community Forums

• HTTP Optimization: Multiple TCP Connections and Pipelining

• SpeedGuide :: Internet Explorer, Chrome, Firefox Web Browser Tweaks