Resumen

  • El borrador inicial del grupo HTTPBIS, fechado en noviembre de 2012, se titulaba «SPDY Protocol» y advertía que sus reglas aún estaban sujetas a decisiones colectivas.
  • El IETF aprobó HTTP/2 y HPACK en febrero de 2015 tras cambios sustanciales. Chrome anunció que reemplazaría SPDY y NPN por HTTP/2 y ALPN.

Un prototipo con nombre propio llega a la mesa

El primer borrador de HTTPBIS llevaba en la portada el nombre SPDY Protocol. Su capa de tramas ofrecía flujos simultáneos, prioridades y compresión; otra capa conservaba un sentido parecido al de HTTP para las aplicaciones. La nota editorial decía que el texto era un punto de partida provisional. Google había puesto código en funcionamiento. El grupo de trabajo tenía que decidir qué conservar.

Según el balance del IETF de febrero de 2015, hubo seis reuniones intermedias y pruebas entre sucesivos borradores. Sus responsables contaron más de 200 asuntos de diseño, 17 borradores y 30 implementaciones. Son cifras del proceso de estandarización; la adopción en sitios web requeriría otra medición. El formato, la compresión y la relación con la semántica de HTTP cambiaron antes de que se aprobasen HTTP/2 y HPACK.

La compresión presentó la cuenta

El RFC 7541 recuerda que SPDY comprimía cabeceras con DEFLATE. El ataque CRIME mostró un riesgo de seguridad de ese método. HPACK definió otro compresor con memoria acotada y menor exposición a ataques conocidos. El RFC 7540, publicado en mayo de 2015, fijó el identificador h2 para negociar HTTP/2 sobre TLS mediante ALPN. Siguieron existiendo los flujos múltiples, pero el contrato técnico era distinto.

Chrome anunció en febrero de 2015 soporte para HTTP/2 y la futura retirada de SPDY y NPN. Una actualización del propio anuncio señaló Chrome 51. El registro fechado de esa versión precisaría cuándo se completó la retirada. El prototipo abrió la puerta; el estándar decidió la arquitectura que quedó detrás.

Fuentes