Ho guardato SPDY per migliorare le prestazioni, in particolare con SSL a pieno sito. Capisco la maggior parte di ciò che fa, ma non ho avuto il tempo di farlo e di fare una revisione completa di esso. Cosa dovrei sapere prima di abilitarlo? Ci sono delle implicazioni sulla sicurezza di cui dovrei essere a conoscenza?
SPDY è stato segnalato come vulnerabile a Attacco CRIME , ma questo verrà rattoppato nella prossima versione del protocollo . Le specifiche dei cookie HTTP target CRIME, quindi il protocollo fisso farà qualcosa di speciale quando si comprimono i cookie (vale a dire, non comprimerà i cookie con il resto delle intestazioni, ma utilizzerà un canale dedicato per trasportare i valori del cookie, con un codice specifico che dichiara "lo stesso cookie di prima").
Come regola generale, la crittografia perde i dati lunghezza e la compressione (qualsiasi tipo di compressione) rende la lunghezza dipendente dal byte di dati valori , aumentando così la perdita di informazioni . La crittografia e la compressione non si combinano bene. Personalmente raccomanderei non di attivare SPDY per HTTPS. Per il semplice HTTP, tuttavia, andare avanti; non renderà le cose peggiori dal punto di vista della sicurezza rispetto al semplice fatto di usare un semplice HTTP.
Sarebbe interessante raccogliere alcuni dati concreti sui vantaggi effettivi della larghezza di banda di SPDY. Google si è inizialmente vantato di rendere il caricamento delle pagine "più veloce del 55%", ma questo era in condizioni di laboratorio . I veri e propri speed-up possono variare abbastanza ampiamente sul tipo di richiesta che il sito gestisce. Come al solito, non vi è alcun problema di prestazioni se non dimostrato da misure univoche.
SPDY utilizza necessariamente TLS, dal momento che il traffico non criptato viene così frequentemente distrutto da proxy HTTP benintenzionati. Ciò significa che SPDY è ampiamente incompatibile con le sedi che impiegano proxy che intercettano e decodificano il traffico TLS.
SPDY diminuisce il sovraccarico del traffico HTTP; quindi le applicazioni che richiedono un sacco di piccole richieste HTTP vedrebbero un grande aumento della velocità, casi d'uso che coinvolgono un piccolo numero di richieste di grandi dimensioni potrebbero vedere un minor livello di velocità, se del caso.
Chrome v21 disabilita la compressione dell'intestazione in SPDY a causa del cookie CRIME problema di compressione, quindi è teoricamente immune da quel particolare attacco di qualche tempo fa. Presumibilmente ci sarebbe stata una correzione più elegante / permanente in v22 o v23, ma non ho i changelog da confrontare. Chrome è attualmente in v24.
È improbabile che rimangano problemi noti relativi alla sicurezza; come meglio può dimostrare la mia ricerca, sei sicuro con SPDY come lo sei con HTTPS - qualunque cosa tu voglia prendere che significhi.
Se hai un sito web "normale" con la raccolta di risorse standard, SPDY probabilmente non fornirà più di qualche decina di millisecondi di accelerazione. Quindi in quel caso non ne vale la pena. Ma se si dispone di un'applicazione altamente interattiva AJAX-pesante con molte piccole query e aggiornamenti che vengono spostati in giro, SPDY fornisce una soluzione elegante per l'interferenza di disaccoppiamento naturale impedenza e HTTP.
Anche se è vero che le versioni del protocollo SPDY precedenti alla 4 (ancora in corso) sono vulnerabili all'attacco CRIME, non è noto che le implementazioni effettive del browser di SPDY siano vulnerabili. Firefox attualmente disabilita semplicemente la compressione dell'intestazione della richiesta e Google Chrome inserisce ciascun cookie nel proprio gruppo Huffman. Adam Langley fornisce ulteriori dettagli nel suo post sul blog .
Se hai HTTPS abilitato per tutto il sito, usare SPDY dovrebbe essere una vittoria molto considerevole. Tieni presente che quando la ricerca di Google passa a utilizzare SSL per impostazione predefinita, nonostante il costo di HTTPS, in realtà era più veloce per i browser con capacità SPDY (come Google Chrome).