Versin 2.4 del Servidor HTTP Apache
Versin 2.4 del Servidor HTTP Apache
Idiomas disponibles: fr
Esta es la gua para configurar HTTP/2 en Apache httpd. sta caracterstica est lista en producin as que es de esperar que las interfaces y las directivas se mantengan consistentes en cada verin.
El protocolo HTTP/2 HTTP/2 en Apache httpd Compilar httpd con soporte HTTP/2 Configuracin bsica Configuracin MPM Clientes Herramientas tiles para depurar HTTP/2 Server Push "Early Hints"
HTTP/2 es la evolucin del protocolo de la capa de aplicacin con ms xito, HTTP. Se centra en hacer un uso ms eficiente de los recursos de red. No cambia la caracterstica fundamental de HTTP, la semntica. Todava hay olicitudes, respuestas, cabeceras y todo los elementos tpicos de HTTP/1. As que, si ya conoce HTTP/1, tambin conoce el 95% de HTTP/2.
Se ha escrito mucho sobre HTTP/2 y de cmo funciona. La norma ms estndar es, por supuesto, su RFC 7540 ( tambin disponible en un formato ms legible, YMMV). As que, ah encontrar toda la especificacin del protocolo.
Pero, como con todos los RFC, no es ideal como primera lectura. Es mejor entender primero qu se quiere hacer y despus leer el RFC sobre cmo hacerlo. Un documento mucho mejor con el que empezar es http2 explicado por Daniel Stenberg, el autor de curl. Tambin est disponible cada vez en un mayor nmero lenguajes!
Si le parece demasiado largo, o no lo ha leido, hay algunos trminos y elementos a tener en cuenta cuando lea este documento:
El protocolo HTTP/2 se implementa con su propio mdulo httpd, llamado acertadamente mod_http2. Incluye el set completo de caractersticas 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 travs de una solicitud inicial HTTP/1.
Una caracterstica de HTTP/2 que ofrece capacidades nuevas para desarrolladores de web es Server Push. Vea esa seccin para saber como su aplicacin web puede hacer uso de ella.
mod_http2 necesita al menos la versin 1.2.1 de libnghttp2 instalada en su sistema.
Cuando usted ejecuta ./configure en el cdigo fuente de Apache HTTPD, necesita indicarle '--enable-http2' como una opcin adicional para activar la compilacin de este mdulo. Si su libnghttp2 est ubicado en una ruta no habitual (cualquiera que sea en su sistema operativo), puede indicar su ubicacin con '--with-nghttp2=<path>' para ./configure.
Aunque puede que eso sirva para la mayora, habr quien prefiera un nghttp2 compilado estticamente para este mdulo. Para ellos existe la opcin --enable-nghttp2-staticlib-deps. Funciona de manera muy similar a como uno debe enlazar openssl estticamente para mod_ssl.
Hablando de SSL, necesita estar al tanto de que la mayora de los navegadores hablan HTTP/2 solo con URLs https:. As que necesita un servidor con soporte SSL. Pero no solo eso, necesitar una librera SSL que de soporte a la extensin ALPN. Si usa OpenSSL, necesita al menos la versin 1.0.2.
Cuando tiene un httpd compilado con mod_http2 necesita una configuracin bsica para activarlo. Lo primero, como con cualquier otro mdulo de Apache, es que necesita cargarlo:
Loodule http2_module modules/mod_http2.so
La segunda directiva que necesita aadir a la configuracin 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 dnde 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.
Es necesario configurar SSLCipherSuite con una suite segura de cifrado TLS. La versin actual de mod_http2 no fuerza ningn cifrado pero la mayora 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 comn cuando se configura httpd con HTTP/2 por primera vez, as que por favor tenga en cuenta que debe evitar largas sesiones de depuracin! 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 tambin es relevante. Por defecto, el primero es el protocolo preferido. Cuando un cliente ofrece mltiples opciones, la que est ms 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 slo 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 ms respecto al orden: el cliente tambin 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 slo el orden de preferencia del cliente ser decisorio.
Una ltima cosa: cuando usted configura los protocolos no se comprueba si son correctos o estn bien escritos. Puede mencionar protocolos que no existen, as que no hay necesidad de proteger <IfModule> de comprobacin.
Para ms consejos avanzados de configuracin, vea la como gestionar multiples hosts con el mismo certificado.
HTTP/2 est soportado en todos los mdulos de multi-proceso que se ofrecen con httpd. Aun as, si usa el mpm prefork, habr restricciones severas.
En mod_http2 solo procesar una solicitud cada vez por conexin. Pero los clientes, como los navegadores, enviarn muchas solicitudes al mismo tiempo. Si una de ellas tarda mucho en procesarse (o hace un sondeo que dura ms de la cuenta), las otras solicitudes se quedarn atascadas.
prefork hoy en da solo se escoge si ejecuta motores de proceso que no estn preparados para multi-hilo, p.ej. fallar con ms de una solicitud.
Si su configuracin lo soporta, hoy en da event es el mejor mpm que puede usar.
Si realmente est obligado a usar H2MinWorkers para hacerlo posible. Sin embargo, si esto falla, es bajo su cuenta y riesgo.
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 cmo otros servidores, estn 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 ms verstil es curl.
La primera herramienta a mencionar es por supuesto curl. Por favor asegrese de que su versin soporta HTTP/2 comprobando sus Caractersticas:
$ 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
Y para una inspeccin en gran profundidad wireshark.
El paquete nghttp2 tambin incluye clientes, tales como:
Chrome ofrece logs detallados de HTTP/2 en sus conexiones a travs de la pgina especial de net-internals. Tambin hay una extensin interesante para Chrome y Firefox con la que visualizar cuando su navegador usa HTTP/2.
El protocolo HTTP/2 permite al servidor hacer PUSH de respuestas a un cliente que nunca las solicit. El tono de la conversacin es: "Aqu tiene una solicitud que nunca envi y la respuesta llegar pronto..."
Pero hay restricciones: el cliente puede deshabilitar esta caracterstica y el servidor entonces solo podr hacer PUSH en una solicitud que hizo previamente del cliente.
La intencin es permitir al servidor enviar recursos que el cliente seguramente vaya a necesitar, p. ej. un recurso css o javascript que pertenece a una pgina html que el cliente solicit, un grupo de imgenes 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 cancelacin previa de tales solicitudes, pero aun as se malgastan recursos.
Resumiendo: no hay una estrategia mejor sobre cmo usar esta caracterstica de HTTP/2 y todo el mundo est experimentando con ella. As que, cmo 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 conexin soporta PUSH, estos dos recursos se enviarn al cliente. Como desarrollador web, puede configurar estas cabeceras o bien directamente en la respuesta de su aplicacin 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 parmetro 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 ms:
El mdulo mantiene un registro de lo que se ha enviado con PUSH para cada conexin (hashes de URLs, bsicamente) y no har PUSH del mismo recurso dos veces. Cuando la conexin se cierra, la informacin es descartada.
Hay gente pensando cmo 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 ms importante que influye en la respuesta que se enva, es la solicitud que se simul. La url de solicitud de un PUSH es dada por la aplicacin, pero de donde vienen las cabeceras de la peticin? por ejemplo si el PUSH pide una cabecera accept-language y si es as, con qu valor?
Httpd mirar la peticin original (la que origin el PUSH) y copiar las siguientes cabeceras a las peticiones PUSH: -agent, accept, accept-encoding, accept-language, cache-control.
Todas las otras cabeceras son ignorados. Las cookies tampoco sern copiadas. Impulsar los recursos que requieren una cookie para estar presente no funcionar. Esto puede ser una cuestin de debate. Pero a menos que esto se discuta ms claramente con el navegador, evitemos el exceso de precaucin y no expongamos las cookies donde podran o no ser visibles.
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 ms 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 aplicacin web.
Si la directiva H2Push est dehabilitada, la respuesta 103 se le enviar al cliente.
Idiomas disponibles: fr