Apache HTTPD con SPDY 3.1

SPDY 3.1 ha sido lanzado hace un time. Google ha donado el proyecto mod_spdy a apache ( https://code.google.com/p/mod-spdy/ ). ¿Es posible usar SPDY 3.1 con Apache Httpd?

El problema es que Chrome 40.x eliminó la compatibilidad con SPDY / 3 y sólo admite SPDY / 3.1, pero el module mod_spdy para Apache sólo admite SPDY / 3, por lo que básicamente no SPDY para usuarios de Chrome si utiliza Apache como server web.

mod_spdy se encuentra actualmente en un mal estado en el que Google o Apache lo están manteniendo después de que Google lo donó a la Asf. Recientemente, Google hizo la statement de que eliminará el soporte de SPDY de Chrome a principios de 2016, pero lo que se olvidó de decir que empezaron a soltar versiones anteriores de SPDY (incluyendo SPDY / 3) (me gustan estas declaraciones parcialmente verdaderas por cierto) , por lo que básicamente si estás en Apache entonces para tus usuarios de Chrome no puedes proporcionar SPDY antes de implementar SPDY / 3.1 tú mismo.

Entonces, ¿cómo fue eso para "no hacer mal"? Todos los derechos reservados

Ver detalles: https://groups.google.com/forum/#!topic/mod-spdy-discuss/FPEj0zG5I0Y y https://code.google.com/p/mod-spdy/issues/detail?id=100&colspec = ID% 20Type% 20Status% 20Priority% 20Owner% 20Summary% 20Stars

Una opción que podría considerar es cambiar a Nginx y utilizar la implementación SPDY / 3.1 por allí.

Mod_spdy de Google funciona en Apache 2.2, pero el puerto 2.4 tenía algunos problemas, hay un hilo en él ya.

He encontrado una descripción de cómo alguien logró comstackrlo, pero aún no lo he probado.

Como no puedo comentar, debido a la falta de reputación, tendré que responder, aunque podría ser como "fuera de tema" como la respuesta de alexus fue.

He encontrado la descripción, hoppy mencionado hace unos días y con éxito lo consiguió trabajando. Muy directamente, si alguien está interesado en probarlo. Aunque debo mencionar, que esto tristemente sólo agrega soporte SPDY / 3 a mi dominio y no el SPDY / 3.1 en cuestión.

Chrome 36 y Firefox 31.4 ESR se conectan a este dominio de testing con éxito a través de SPDY / 3. (Utilizando el indicador SPDY AddOns para Firefox y Chrome). Qualys SSL Labs confirma que el server tiene soporte para SDPY / 3 y SPDY / 2.

Al conectarse a google.com con esas versiones del browser, los indicadores SPDY me dicen que SPDY / 3.1 está en uso.

Pero en Chrome 40 & 41 y Firefox 36+ el indicador SPDY permanece gris, mientras que se conecta a mi dominio de testings. Conectando google.com ambos browseres dicen, la connection ya está usando HTTP / 2. Así que no sólo Chrome, sino también Firefox ya droped SPDY 3.0 Soporte.

Creo que esto es un poco desafortunado. Sysadmins, tratando de apoyar la mejor experiencia posible y el protocolo de apoyo son un poco atropellado, el trabajo invertido fue para nada.

Para finalmente responder a la pregunta de este hilo: No. A mí parece que, usted no obtendrá una forma alguna "oficial" SPDY / 3.1 Apoyo para apache2 todavía. Como se puede leer en github , no lo hablan todavía. Y como este "todavía" es ya alnetworkingedor de medio año de edad, me imagino, no viene. Así como alexus mencionado, uno debe pegarse a HTTP / 2. Mantenga un ojo en esta página github donde espero apache2 aparecerá muy pronto.

Y finalmente el "pero" -parte. 😉 Podrías deshacer el cambio, enlazé a, y recompile el mod_spdy, por lo que ofrece SPDY / 3.1. Con mi máquina de testing de alguna manera parece funcionar, pero tengo algunos problemas con Firefox diciendo que el server OCSP necesita probar más tarde, que se fueron 5 minutos más tarde. Pero realmente no sé si los browseres están cayendo de alguna manera a SPDY / 3 pero mostrando el SPDY / 3.1 negociado o algo. No confío en esta configuration ahora mismo y necesito hacer algunas testings adicionales. Así que para responder a la pregunta del hilo de nuevo: Sí, tal vez! 🙂 Si se adhieren a la descripción de lúpulo dio y cambiar algunas líneas de código y comstackr de nuevo. Parece que de alguna manera funciona, pero realmente no lo recomendaría ahora mismo.

En realidad, estaba probando SPDY3.1 sin quitar las especificaciones de cabecera 3.1, desde el origen antes de comstackr.

Todo funcionaba bien, excepto POST, y cargas de files con PHP-FPM. Además, aunque no había detalles sobre ello en el logging de errores, hubo una caída del 30% en el tráfico. Por supuesto, puede ser una coincidencia, pero el post y los problemas son definitivamente reales.

Se probó en un server con aproximadamente 200 000 páginas vistas / día.

Lo siento, si es poco fuera de tema, pero ni siquiera me molestaría, ya que Google está abandonando SPDY y avanzar hacia HTTP / 2:

Chromium Blog: Hola HTTP / 2, Adiós SPDY