<-
Apache > Servidor HTTP > Documentación > Versión 2.4 > How-To / Tutoriales

Guía HTTP/2

Idiomas disponibles:  en  |  es  |  fr 

Esta es la guía para configurar HTTP/2 en Apache httpd. Ésta característica est?lista en produción as?que es de esperar que las interfaces y las directivas se mantengan consistentes en cada verión.

Support Apache!

Consulte también

top

El protocolo HTTP/2

HTTP/2 es la evolución del protocolo de la capa de aplicación con más éxito, HTTP. Se centra en hacer un uso más eficiente de los recursos de red. No cambia la característica fundamental de HTTP, la semántica. Todavía hay olicitudes, respuestas, cabeceras y todo los elementos típicos de HTTP/1. As? que, si ya conoce HTTP/1, también conoce el 95% de HTTP/2.

Se ha escrito mucho sobre HTTP/2 y de cómo funciona. La norma más estándar es, por supuesto, su RFC 7540 ( también disponible en un formato más legible, YMMV). As?que, ah?encontrar?toda la especificación del protocolo.

Pero, como con todos los RFC, no es ideal como primera lectura. Es mejor entender primero qu?/em> se quiere hacer y después leer el RFC sobre cómo hacerlo. Un documento mucho mejor con el que empezar es http2 explicado por Daniel Stenberg, el autor de curl. ¡También est?disponible cada vez en un mayor número lenguajes!

Si le parece demasiado largo, o no lo ha leido, hay algunos términos y elementos a tener en cuenta cuando lea este documento:

  • HTTP/2 es un protocolo binario, al contrario que HTTP 1.1 que es texto plano. La intención para HTTP 1.1 es que sea legible (por ejemplo capturando el tráfico de red) mientras que para HTTP/2 no. Más información en el FAQ oficial ¿Por qu?es binario HTTP/2?
  • h2 es HTTP/2 sobre TLS (negociación de protocolo a través de ALPN).
  • h2c es HTTP/2 sobre TCP.
  • Un frame es la unidad más pequeña de comunicación dentro de una conexión HTTP/2, que consiste en una cabecera y una secuencia de octetos de longitud variable estructurada de acuerdo con el tipo de frame. Más información en la documentación oficial Sección de Capa de Frame.
  • Un stream es un flujo bidireccional de frames dentro de una conexión HTTP/2. El concepto correspondiente en HTTP 1.1 es un intercambio de mensajes de solicitud/respuesta. Más información en la documentación oficial Sección Capa de Stream.
  • HTTP/2 es capaz de llevar múltiples streams de datos sobre la misma conexión TCP, evitando la clásica solicitud lenta "head-of-line blocking" de HTTP 1.1 y evitando generar múltiples conexiones TCP para cada solicitud/respuesta (KeepAlive parche?el problema en HTTP 1.1 pero no lo resolvi?completamente).
top

HTTP/2 en Apache httpd

El protocolo HTTP/2 se implementa con su propio módulo httpd, llamado acertadamente mod_http2. Incluye el set completo de características descritas por el RFC 7540 y soporta HTTP/2 sobre texto plano (http:), as?como conexiones seguras (https:). La variante de texto plano se llama 'h2c', la segura 'h2'. Para h2c permite el modo direct y el Upgrade: a través de una solicitud inicial HTTP/1.

Una característica de HTTP/2 que ofrece capacidades nuevas para desarrolladores de web es Server Push. Vea esa sección para saber como su aplicación web puede hacer uso de ella.

top

Compilar httpd con soporte HTTP/2

mod_http2 usa la librería nghttp2como su implementación base. Para compilar mod_http2 necesita al menos la versión 1.2.1 de libnghttp2 instalada en su sistema.

Cuando usted ejecuta ./configure en el código fuente de Apache HTTPD, necesita indicarle '--enable-http2' como una opción adicional para activar la compilación de este módulo. Si su libnghttp2 est?ubicado en una ruta no habitual (cualquiera que sea en su sistema operativo), puede indicar su ubicación con '--with-nghttp2=<path>' para ./configure.

Aunque puede que eso sirva para la mayoría, habr?quien prefiera un nghttp2 compilado estáticamente para este módulo. Para ellos existe la opción --enable-nghttp2-staticlib-deps. Funciona de manera muy similar a como uno debe enlazar openssl estáticamente para mod_ssl.

Hablando de SSL, necesita estar al tanto de que la mayoría de los navegadores hablan HTTP/2 solo con URLs https:. As?que necesita un servidor con soporte SSL. Pero no solo eso, necesitar?una librería SSL que de soporte a la extensión ALPN. Si usa OpenSSL, necesita al menos la versión 1.0.2.

top

Configuración básica

Cuando tiene un httpd compilado con mod_http2 necesita una configuración básica para activarlo. Lo primero, como con cualquier otro módulo de Apache, es que necesita cargarlo:

LoadModule http2_module modules/mod_http2.so

La segunda directiva que necesita añadir a la configuración de su servidor es:

Protocols h2 http/1.1

Esto permite h2, la variante segura, para ser el protocolo preferido de las conexiones en su servidor. Cuando quiera habilitar todas las variantes de HTTP/2, entonces simplemente configure:

Protocols h2 h2c http/1.1

Dependiendo de dónde pone esta directiva, afecta a todas las conexiones o solo a las de ciertos host virtuales. La puede anidar, como en:

Protocols http/1.1
<VirtualHost ...>
    ServerName test.example.org
    Protocols h2 http/1.1
</VirtualHost>

Esto solo permite HTTP/1, excepto conexiones SSL hacia test.example.org que ofrecen HTTP/2.

Escoger un SSLCipherSuite seguro

Es necesario configurar SSLCipherSuite con una suite segura de cifrado TLS. La versión actual de mod_http2 no fuerza ningún cifrado pero la mayoría de los clientes si lo hacen. Encaminar un navegador hacia un servidor con h2 activado con una suite inapropiada de cifrados forzar?al navegador a rehusar e intentar conectar por HTTP 1.1. Esto es un error común cuando se configura httpd con HTTP/2 por primera vez, ¡as?que por favor tenga en cuenta que debe evitar largas sesiones de depuración! Si quiere estar seguro de la suite de cifrados que escoja, por favor evite los listados en la Lista Negra de TLS para HTTP/2.

El orden de los protocolos mencionados también es relevante. Por defecto, el primero es el protocolo preferido. Cuando un cliente ofrece múltiples opciones, la que est?más a la izquierda ser?la escogida. En

Protocols http/1.1 h2

el protocolo preferido es HTTP/1 y siempre ser?seleccionado a menos que el cliente sólo soporte h2. Puesto que queremos hablar HTTP/2 con clientes que lo soporten, el orden correcto es:

Protocols h2 h2c http/1.1

Hay algo más respecto al orden: el cliente también tiene sus propias preferencias. Si quiere, puede configurar su servidor para seleccionar el protocolo preferido por el cliente:

ProtocolsHonorOrder Off

Hace que el orden en que usted escribi?los Protocols sea irrelevante y sólo el orden de preferencia del cliente ser?decisorio.

Una última cosa: cuando usted configura los protocolos no se comprueba si son correctos o están bien escritos. Puede mencionar protocolos que no existen, as?que no hay necesidad de proteger Protocols con ningún <IfModule> de comprobación.

Para más consejos avanzados de configuración, vea la sección de módulos sobre dimensionamiento y como gestionar multiples hosts con el mismo certificado.

top

Configuración MPM

HTTP/2 est?soportado en todos los módulos de multi-proceso que se ofrecen con httpd. Aun as? si usa el mpm prefork, habr? restricciones severas.

En prefork, mod_http2 solo procesar?una solicitud cada vez por conexión. Pero los clientes, como los navegadores, enviarán muchas solicitudes al mismo tiempo. Si una de ellas tarda mucho en procesarse (o hace un sondeo que dura más de la cuenta), las otras solicitudes se quedarán atascadas.

mod_http2 no evitar?este límite por defecto. El motivo es que prefork hoy en día solo se escoge si ejecuta motores de proceso que no están preparados para multi-hilo, p.ej. fallar?con más de una solicitud.

Si su configuración lo soporta, hoy en día event es el mejor mpm que puede usar.

Si realmente est?obligado a usar prefork y quiere multiples solicitudes, puede configurar la directiva H2MinWorkers para hacerlo posible. Sin embargo, si esto falla, es bajo su cuenta y riesgo.

top

Clientes

Casi todos los navegadores modernos dan soporte a HTTP/2, pero solo en conexiones SSL: Firefox (v43), Chrome (v45), Safari (since v9), iOS Safari (v9), Opera (v35), Chrome para Android (v49) e Internet Explorer (v11 en Windows10) (Fuente).

Otros clientes, as?cómo otros servidores, están listados en la wiki de Implementaciones, entre ellos, implementaciones para c, c++, common lisp, dart, erlang, haskell, java, nodejs, php, python, perl, ruby, rust, scala y swift.

Muchos de las implementaciones de clientes que no son navegadores soportan HTTP/2 sobre texto plano, h2c. La más versátil es curl.

top

Herramientas útiles para depurar HTTP/2

La primera herramienta a mencionar es por supuesto curl. Por favor asegúrese de que su versión soporta HTTP/2 comprobando sus Características:

    $ curl -V
    curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4
    Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...] 
    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2
    

Notas sobre Mac OS homebrew

brew install curl --with-openssl --with-nghttp2

Y para una inspección en gran profundidad wireshark.

El paquete nghttp2 también incluye clientes, tales como:

  • nghttp - util para visualizar la frames de HTTP/2 y tener una mejor idea de como funciona el protocolo.
  • h2load - útil para hacer un stress-test de su servidor.

Chrome ofrece logs detallados de HTTP/2 en sus conexiones a través de la página especial de net-internals. También hay una extensión interesante para Chrome y Firefox con la que visualizar cuando su navegador usa HTTP/2.

top

Server Push

El protocolo HTTP/2 permite al servidor hacer PUSH de respuestas a un cliente que nunca las solicit? El tono de la conversación es: "Aqu?tiene una solicitud que nunca envi?y la respuesta llegar?pronto..."

Pero hay restricciones: el cliente puede deshabilitar esta característica y el servidor entonces solo podr?hacer PUSH en una solicitud que hizo previamente del cliente.

La intención es permitir al servidor enviar recursos que el cliente seguramente vaya a necesitar, p. ej. un recurso css o javascript que pertenece a una página html que el cliente solicit? un grupo de imágenes a las que se hace referencia en un css, etc.

La ventaja para el cliente es que ahorra tiempo para solicitudes que pueden tardar desde unos pocos milisegundos a medio segundo, dependiendo de la distancia entre el cliente y el servidor. La desventaja es que el cliente puede recibir cosas que ya tiene en su cache. Por supuesto que HTTP/2 soporta cancelación previa de tales solicitudes, pero aun as?se malgastan recursos.

Resumiendo: no hay una estrategia mejor sobre cómo usar esta característica de HTTP/2 y todo el mundo est?experimentando con ella. As?que, ¿cómo experimenta usted con ella en Apache httpd?

mod_http2 busca e inspecciona las cabeceras de respuesta Link con cierto formato:

Link </xxx.css>;rel=preload, </xxx.js>; rel=preload

Si la conexión soporta PUSH, estos dos recursos se enviarán al cliente. Como desarrollador web, puede configurar estas cabeceras o bien directamente en la respuesta de su aplicación o configurar su servidor con:

<Location /xxx.html>
    Header add Link "</xxx.css>;rel=preload"
    Header add Link "</xxx.js>;rel=preload"
</Location>

Si quiere usar enlaces con preload sin activar un PUSH, puede usar el parámetro nopush, como en:

Link </xxx.css>;rel=preload;nopush

o puede desactivar PUSH para su servidor por completo con la directiva

H2Push Off

Y hay más:

El módulo mantiene un registro de lo que se ha enviado con PUSH para cada conexión (hashes de URLs, básicamente) y no har?PUSH del mismo recurso dos veces. Cuando la conexión se cierra, la información es descartada.

Hay gente pensando cómo un cliente puede decirle al servidor lo que ya tiene, para evitar los PUSH de esos elementos, pero eso algo muy experimental ahora mismo.

Otro borrador experimental que ha sido implementado en mod_http2 es el Campo de Cabecera Accept-Push-Policy en la que un cliente puede, para cada solicitud, definir qu?tipo de PUSH acepta.

Puede que PUSH no siempre lance la peticion/respuesta/funcionamiento que uno espera. Hay varios estudios sobre este tema en internet, que explican el beneficio y las debilidades de como diferentes funcionalidades del cliente y de la red influyen en el resultado. Por Ejemplo, que un servidor haga "PUSH" de recursos, no significa que el navegador vaya a usar dichos datos.

Lo más importante que influye en la respuesta que se envía, es la solicitud que se simul? La url de solicitud de un PUSH es dada por la aplicación, pero ¿de donde vienen las cabeceras de la petición? por ejemplo si el PUSH pide una cabecera accept-language y si es as? ¿con qu?valor?

Httpd mirar?la petición original (la que origin?el PUSH) y copiar?las siguientes cabeceras a las peticiones PUSH: user-agent, accept, accept-encoding, accept-language, cache-control.

Todas las otras cabeceras son ignorados. Las cookies tampoco serán copiadas. Impulsar los recursos que requieren una cookie para estar presente no funcionar? Esto puede ser una cuestión de debate. Pero a menos que esto se discuta más claramente con el navegador, evitemos el exceso de precaución y no expongamos las cookies donde podrían o no ser visibles.

top

"Early Hints"

Una alternativa de "Pushear" recursos es mandar una cabecera Link al cliente antes que la respuesta est?lista. Esto usa una caracteristica de HTTP que se llama "Early Hints" y est?descrita en la RFC 8297.

Para poder usar esto, necesita habilitarlo explicitamente en el servidor via

H2EarlyHints on

(No est?habilitado por defecto ya q ue algunos navegadores más antiguos se caen con dichas respuestas.)

si esta funcionalidad esta activada, puede usar la directiva H2PushResource para que lance "Early hints" y recursos mediante push:

<Location /xxx.html>
    H2PushResource /xxx.css
    H2PushResource /xxx.js
</Location>

Esto lanzar?una respuesta "103 Early Hints" a un cliente tan pronto como el servidor comience a procesar la solicitud. Esto puede ser mucho antes que en el momento en que se determinaron los primeros encabezados de respuesta, dependiendo de su aplicación web.

Si la directiva H2Push est? habilitada, esto comenzar?el PUSH justo después de la respuesta 103. Sin embargo, si la directiva H2Push est?dehabilitada, la respuesta 103 se le enviar?al cliente.

Idiomas disponibles:  en  |  es  |  fr 

top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
°×С½ã͸ÌØÆÚÆÚ