He estado buscando en SPDY para obtener un mayor rendimiento, especialmente con SSL de sitio completo. Entiendo la mayor parte de lo que hace, pero no he tenido tiempo de revisarlo por completo. ¿Qué debo saber al respecto antes de habilitarlo? ¿Hay alguna implicación de seguridad que deba tener en cuenta?
Se ha informado que SPDY es vulnerable a Ataque de CRIMEN , pero esto será parcheado en la próxima versión del protocolo . Los detalles específicos de las cookies HTTP objetivo de CRIME, por lo que el protocolo fijo hará algo especial al comprimir las cookies (es decir, no comprimirá las cookies con el resto de los encabezados; en su lugar, utilizará un canal dedicado para transportar los valores de las cookies, con un código específico que indica "la misma cookie que anteriormente").
Como regla general, el cifrado pierde datos longitud , y la compresión (cualquier tipo de compresión) hace que la longitud dependa de los bytes de datos valores , lo que aumenta la fuga de información . El cifrado y la compresión no se mezclan bien juntos. Personalmente recomendaría no activar SPDY para HTTPS. Para HTTP simple, sin embargo, continúe; no empeorará las cosas en cuanto a seguridad que el mero hecho de usar HTTP simple.
Sería interesante recopilar algunos datos concretos sobre los beneficios reales de ancho de banda de SPDY. Google inicialmente se jactó de hacer que la página se cargara "55% más rápido", pero esto era en condiciones de laboratorio . Los incrementos de velocidad reales pueden variar bastante en función del tipo de solicitud que maneja el sitio. Como de costumbre, no hay problema de rendimiento a menos que se demuestre con medidas inequívocas.
SPDY necesariamente usa TLS, ya que el tráfico no cifrado se maneja con frecuencia por proxies HTTP bien intencionados. Esto significa que SPDY es en gran parte incompatible con las ubicaciones que emplean proxies que interceptan y descodifican el tráfico TLS.
SPDY reduce la sobrecarga del tráfico HTTP; por lo tanto, las aplicaciones que involucran muchas solicitudes HTTP pequeñas verán una gran aceleración, los casos de uso que involucren una pequeña cantidad de solicitudes grandes verán una aceleración menor, en su caso.
Chrome v21 inhabilita la compresión del encabezado en SPDY debido a la cookie CRIME problema de compresión, por lo que es teóricamente inmune a ese ataque en particular desde hace algún tiempo. Supuestamente iba a haber una solución más elegante / permanente en v22 o v23, pero no tengo los registros de cambios para comparar. Chrome se encuentra actualmente en v24.
Es poco probable que haya problemas conocidos relacionados con la seguridad; lo mejor que mi investigación puede mostrar, estás tan seguro con SPDY como con HTTPS, sea lo que sea que quieras decir.
Si tiene un sitio web "normal" con la colección de activos estándar, SPDY probablemente no proporcionará más de unas pocas docenas de milisegundos de aceleración. Así que en ese caso no merece la pena. Pero si tiene una aplicación de AJAX muy interactiva con muchas consultas y actualizaciones pequeñas, SPDY ofrece una solución elegante para la interactividad de desajuste de impedancia natural y HTTP.
Si bien es cierto que las versiones del protocolo SPDY anteriores a 4 (aún en curso) son vulnerables al ataque CRIME, no se sabe que las implementaciones reales de SPDY en el navegador sean vulnerables. Actualmente, Firefox simplemente simplemente desactiva la compresión del encabezado de solicitud, y Google Chrome coloca cada cookie en su propio grupo Huffman. Adam Langley entra en más detalles en su publicación del blog sobre el tema .
Si tiene HTTPS habilitado en todo el sitio, entonces usar SPDY debería ser una ganancia considerable. Tenga en cuenta que cuando la búsqueda de Google cambió a utilizar SSL de forma predeterminada, a pesar del costo de HTTPS, en realidad fue más rápido para los navegadores compatibles con SPDY (como Google Chrome).