Como siempre estamos a la vanguardia de las nuevas tecnolog\u00edas, nos aseguramos de que todo el sitio web y administraci\u00f3n de Kinsta se ejecute en HTTP\/2 y nuestra\u00a0infraestructura basada en Google Cloud<\/a> soporta HTTP\/2 para todos nuestros clientes Este extenso recurso de informaci\u00f3n explica HTTP\/2 para usuarios finales, desarrolladores y empresas que buscan la innovaci\u00f3n. Desde informaci\u00f3n b\u00e1sica hasta temas m\u00e1s avanzados, aprender\u00e1 todo lo que necesita saber sobre HTTP\/2.<\/p>\n HTTP<\/a> fue propuesto originalmente por Tim Berners-Lee<\/a>, el pionero de la Red Mundial que dise\u00f1\u00f3 el protocolo de aplicaci\u00f3n teniendo en mente la simplicidad de alto nivel para realizar las funciones de comunicaci\u00f3n de datos entre servidores y clientes Web.<\/p>\n La primera versi\u00f3n documentada de HTTP fue lanzada en 1991 como HTTP0.9, que luego condujo a la introducci\u00f3n oficial y reconocimiento de HTTP1.0 en 1996. HTTP1.1 seguida en 1997 y desde entonces ha recibido pocas mejoras iterativas.<\/p>\n En febrero de 2015, el IETF<\/a> (Grupo de Trabajo de Ingenier\u00eda de Internet) un Grupo de Trabajo HTTP revis\u00f3 y desarroll\u00f3 la segunda versi\u00f3n de la aplicaci\u00f3n en forma de protocolo HTTP\/2. En mayo de 2015, la especificaci\u00f3n HTTP\/2 aplicaci\u00f3n oficialmente fue estandarizada en respuesta al protocolo SPDY<\/a> compatible con HTTP. El argumento HTTP\/2 vs SPDY contin\u00faa a lo largo de la gu\u00eda.<\/p>\n El debate HTTP\/2 vs HTTP1 debe proceder con una breve gu\u00eda sobre el t\u00e9rmino protocolo utilizado frecuentemente en este recurso. Un protocolo es un conjunto de reglas que rigen los mecanismos de comunicaci\u00f3n de datos entre los clientes (por ejemplo, navegadores web utilizados por los usuarios de internet para solicitar informaci\u00f3n) y servidores (las m\u00e1quinas que contengan la informaci\u00f3n solicitada).<\/p>\n Los protocolos generalmente consisten de tres partes principales: Encabezado, carga \u00fatil y pie de p\u00e1gina. El Encabezado colocado antes de la carga \u00fatil contiene informaci\u00f3n tal como las direcciones de origen y destino, as\u00ed como otros detalles (como el tama\u00f1o y tipo) con respecto a la carga \u00fatil. La carga \u00fatil es la informaci\u00f3n transmitida mediante el protocolo. El pie sigue la carga y funciona como un campo de control para enrutar las solicitudes de cliente-servidor a los destinatarios, junto con el encabezado para asegurar que la carga \u00fatil se transmita libres de errores.<\/p>\n El sistema es similar al servicio de correo. La carta (Carga \u00fatil) se inserta en un sobre (Encabezado) con direcci\u00f3n de destino escrita en ella y sellada con pegamento y sello (pie de p\u00e1gina) antes de que se expidan. Excepto que la transmisi\u00f3n de informaci\u00f3n digital en forma de 0s y 1s no es tan sencillo y requiere una nueva dimensi\u00f3n de innovaci\u00f3n en respuesta a aumentar los avances tecnol\u00f3gicos que surgen con el crecimiento explosivo del uso de internet.<\/p>\n Protocolo HTTP constaba inicialmente de comandos b\u00e1sicos: GET, para recuperar la informaci\u00f3n del servidor y POST, para entregar la informaci\u00f3n solicitada por el cliente. Este sencillo y aparentemente aburrido conjunto de algunos comandos para obtener datos y enviar una respuesta esencialmente establecieron las bases para la construcci\u00f3n de otros protocolos de red. El protocolo es otra iniciativa destinada a mejorar la experiencia y eficacia del usuario de internet, necesit\u00e1ndose aplicaci\u00f3n HTTP\/2 para mejorar la presencia en l\u00ednea.<\/p>\n Desde sus inicios a principios de los a\u00f1os noventa, HTTP ha visto s\u00f3lo unas pocas grandes revisiones. La versi\u00f3n m\u00e1s reciente, HTTP1.1 ha servido al mundo cibern\u00e9tico durante m\u00e1s de 15 a\u00f1os. Las p\u00e1ginas Web en la actual era de actualizaciones en informaci\u00f3n din\u00e1mica, formatos de contenido multimedia intensivos en recursos y excesiva inclinaci\u00f3n hacia el rendimiento web han colocado a las tecnolog\u00edas de protocolo antiguas en la categor\u00eda de legado. Estas tendencias exigen importantes HTTP\/2 cambios para mejorar la experiencia de internet.<\/p>\n El objetivo principal de la investigaci\u00f3n y el desarrollo de una nueva versi\u00f3n de HTTP se centra alrededor de tres cualidades raramente asociadas con un \u00fanico protocolo de red sin requerir tecnolog\u00edas de redes adicionales de alto rendimiento, simplicidad y solidez. Estos objetivos se logran mediante la introducci\u00f3n de funciones que reducen la latencia en la tramitaci\u00f3n de las solicitudes del navegador con t\u00e9cnicas como la multiplexaci\u00f3n, la compresi\u00f3n, la priorizaci\u00f3n y la solicitud de inserci\u00f3n de servidor.<\/p>\n Mecanismos tales como el control de flujo, manejo de errores y actualizaci\u00f3n funcionan como mejoras para el protocolo HTTP para desarrolladores para asegurar un alto rendimiento y flexibilidad de aplicaciones basadas en web.<\/p>\n El sistema colectivo permite a los servidores responder eficientemente con m\u00e1s contenido que originalmente solicitado por los clientes, eliminando la intervenci\u00f3n del usuario para solicitar informaci\u00f3n continuamente hasta que el sitio web est\u00e9 completamente cargado en el navegador web. Por ejemplo, la capacidad de inserci\u00f3n del servidor con HTTP\/2 permite a los servidores responder con una p\u00e1gina llena de contenidos distintos de la informaci\u00f3n ya disponible en la cache del navegador. La compresi\u00f3n eficiente de archivos de encabezado HTTP minimiza el exceso de protocolo para mejorar el rendimiento con cada solicitud del explorador y la respuesta del servidor.<\/p>\n Los cambios a HTTP\/2 est\u00e1n dise\u00f1ados para mantener la interoperabilidad y compatibilidad con las ventajas HTTP1.1. HTTP\/2 se espera aumenten con el tiempo sobre la base de experimentos del mundo real y su capacidad para abordar cuestiones relacionadas con el rendimiento real en comparaci\u00f3n en el mundo real con HTTP1.1 impactar\u00e1 en gran medida su evoluci\u00f3n a largo plazo.<\/p>\n \u00ab\u2026No estamos sustituyendo todo el HTTP – los m\u00e9todos, c\u00f3digos de estado, y la mayor\u00eda de los encabezados que se utilizan hoy en d\u00eda ser\u00e1n los mismos. En su lugar, estamos redefiniendo la forma en que se usa \u00aben el cable\u00bb de modo que sea m\u00e1s eficiente, y por lo que es m\u00e1s suave con el propio internet\u2026\u00bbMark Nottingham<\/a>, Presidente del Grupo de trabajo IETF HTTP y miembro de la W3C TAG.\u00a0\u00a0Fuente<\/a><\/p><\/blockquote>\n Es importante se\u00f1alar que la nueva versi\u00f3n de HTTP viene como una extensi\u00f3n de su predecesor y no se espera que reemplace HTTP1.1 en ning\u00fan momento pronto. La aplicaci\u00f3n de HTTP\/2 no permitir\u00e1 soporte autom\u00e1tico para todos los tipos de cifrado disponibles con HTTP1.1, pero sin duda abre la puerta a mejores alternativas de cifrado adicionales o actualizaciones de compatibilidad en el futuro cercano. Sin embargo, comparaciones de caracter\u00edsticas tales como HTTP\/2 vs HTTP1 y SPDY vs HTTP\/2 presentan s\u00f3lo el \u00faltimo protocolo de aplicaci\u00f3n como el ganador en t\u00e9rminos de rendimiento, seguridad y confiabilidad por igual.<\/p>\n HTTP1.1 estaba limitado a procesar solamente una solicitud pendiente por conexi\u00f3n TCP, obligando a los exploradores a utilizar m\u00faltiples conexiones TCP para procesar varias solicitudes simult\u00e1neamente.<\/p>\n Sin embargo, el uso de demasiadas conexiones TCP en paralelo lleva a congesti\u00f3n TCP que causa la monopolizaci\u00f3n injusta de los recursos de la red. Los navegadores Web utilizando varias conexiones para procesar peticiones adicionales ocupan una proporci\u00f3n mayor de los recursos de red disponibles, por lo tanto, degradan el rendimiento de la red para otros usuarios.<\/p>\n Emitir varias solicitudes desde el navegador tambi\u00e9n provoca la duplicaci\u00f3n de datos en cables de transmisi\u00f3n de datos, lo que a su vez requiere protocolos adicionales para extraer la informaci\u00f3n deseada, libre de errores en los nodos finales.<\/p>\n La industria del internet fue naturalmente obligada a piratear estas limitaciones, con pr\u00e1cticas tales como domain sharding, Concatenaci\u00f3n, datos en l\u00ednea y spriting, entre otros. El uso ineficaz de las conexiones TCP con HTTP1.1 subyacente tambi\u00e9n conduce a la priorizaci\u00f3n de recursos pobres, provocando una degradaci\u00f3n del rendimiento exponencial conforme las aplicaciones web crecen en t\u00e9rminos de complejidad, funcionalidad y alcance.<\/p>\n La web ha evolucionado mucho m\u00e1s all\u00e1 de la capacidad del legado de tecnolog\u00edas de redes basadas en HTTP. Las cualidades esenciales de HTTP1.1 desarrolladas hace m\u00e1s de una d\u00e9cada han abierto las puertas a muchas embarazosas lagunas de seguridad y rendimiento.<\/p>\n El Cookie Hack por ejemplo, permite a los ciberdelincuentes reutilizar una sesi\u00f3n de trabajo anterior para comprometer las contrase\u00f1as de las cuentas de transacci\u00f3n porque HTTP1.1 no proporciona ninguna facilidad de tiempo fuera de sesi\u00f3n de identidad. Mientras que los problemas de seguridad similares seguir\u00e1n atormentando a HTTP\/2, el nuevo protocolo de aplicaci\u00f3n est\u00e1 dise\u00f1ado con mejores capacidades de seguridad tales como la mejora en la aplicaci\u00f3n de las nuevas caracter\u00edsticas de TLS<\/a>.<\/p>\n Secuencia de fotogramas de formato de texto bi-direccional enviadas a trav\u00e9s del protocolo HTTP\/2 intercambiados entre el servidor y el cliente se conocen como \u00abflujos\u00bb. Iteraciones anteriores del protocolo HTTP eran capaces de transmitir s\u00f3lo una secuencia a la vez junto con cierto tiempo de retardo entre cada transmisi\u00f3n de flujo.<\/p>\n Recibir toneladas de contenido multimedia a trav\u00e9s de secuencias individuales enviadas una por una es ineficiente y consume recursos. Los cambios a HTTP\/2 han ayudado a establecer una nueva capa binaria de enmarcado para abordar estas preocupaciones.<\/p>\n Esta capa permite al cliente y al servidor HTTP desintegrar la carga hacia la peque\u00f1a secuencia de fotogramas entrelazados, independiente y administrable. Esta informaci\u00f3n es luego montada en el otro extremo.<\/p>\n Los formatos de marco binario permiten el intercambio de m\u00faltiples, secuencias abiertas al mismo tiempo, independientes, bi-direccional es sin latencia entre secuencias sucesivas. Este enfoque presenta una matriz de beneficios de HTTP\/2 explicados a continuaci\u00f3n:<\/p>\n Con esta capacidad, los paquetes de datos desde m\u00faltiples flujos son esencialmente desiguales y transmitidos a trav\u00e9s de una \u00fanica conexi\u00f3n TCP. Estos paquetes se dividen entonces en el extremo receptor y se presentan como flujos de datos individuales. Transmitir varias solicitudes paralelas simult\u00e1neamente utilizando HTTP versi\u00f3n 1.1 o anterior requiere m\u00faltiples conexiones TCP, que inherentemente crean cuellos de botella en el rendimiento global de la red, a pesar de transmitir m\u00e1s flujos de datos con mayor rapidez.<\/p>\n\n Esta capacidad permite que el servidor env\u00ede informaci\u00f3n en cache adicional al cliente que no es solicitada, pero anticipada en futuras solicitudes. Por ejemplo, si el cliente solicita el recurso X y se entiende que el recurso Y se hace referencia con el archivo solicitado, el servidor puede elegir empujar a Y junto con X en lugar de esperar a una petici\u00f3n del cliente apropiada.<\/p>\n El cliente coloca el recurso empujado Y en su cache para su uso futuro. Este mecanismo ahorra un viaje de ida y vuelta de solicitud-respuesta y reduce la latencia de la red. Server Push se introdujo originalmente en el protocolo SPDY de Google. Identificadores Stream que contienen pseudo encabezados tales como :ruta permiten al servidor iniciar el empuje para la informaci\u00f3n que se puede almacenar en la cache. El cliente debe permitir expl\u00edcitamente al servidor empujar recursos cacheables con HTTP\/2 o terminar corrientes empujadas con un identificador de secuencia espec\u00edfica.<\/p>\n Otros cambios de HTTP\/2, tales como Server Push actualiza de forma proactiva o invalida la cache del cliente y tambi\u00e9n es conocida como \u201cCache Push\u00bb. Las consecuencias a largo plazo centran alrededor de la capacidad de servidores para identificar posibles recursos capaces de empuje que el cliente realmente no quiere.<\/p>\n La implementaci\u00f3n de HTTP\/2 ofrece desempe\u00f1o significativo de recursos empujados, junto con otros beneficios de HTTP\/2 explicados a continuaci\u00f3n:<\/p>\n Capacidades de Push similares ya est\u00e1n disponibles con capacidades t\u00e9cnicas sub\u00f3ptimas de Inlining to Push para empujar las respuestas del servidor, mientras que Server Push presenta una soluci\u00f3n de nivel de protocolo para evitar complejidades con hacks de optimizaci\u00f3n secundarios a las capacidades b\u00e1sicas del protocolo de las aplicaciones en s\u00ed.<\/p>\n El HTTP\/2 multiplexa y prioriza la corriente de datos empujados para garantizar un mejor rendimiento de la transmisi\u00f3n tal como se ha visto con otros flujos de datos de solicitud-respuesta. Como un mecanismo de seguridad integrado, el servidor debe estar autorizado para empujar los recursos de antemano.<\/p>\n La \u00faltima versi\u00f3n de HTTP ha evolucionado significativamente en t\u00e9rminos de capacidades y atributos tales como la transformaci\u00f3n de un texto de protocolo a un protocolo binario. HTTP1.x sol\u00eda procesar los comandos de texto para completar ciclos de solicitud-respuesta. HTTP\/2 utilizar\u00e1 comandos binarios (en 1s y 0s) para ejecutar las mismas tareas. Este atributo facilita complicaciones con el encuadre y simplifica la implementaci\u00f3n de comandos que estaban confusamente mezclados debido a los comandos que contienen el texto y espacio opcional.<\/p>\n Aunque probablemente tardar\u00e1 m\u00e1s esfuerzos para leer binario en comparaci\u00f3n con comandos de texto, es m\u00e1s f\u00e1cil para la red generar y analizar marcos disponibles en formato binario. La sem\u00e1ntica actual permanece inalterada.<\/p>\n Los navegadores utilizando implementaci\u00f3n HTTP\/2 convertir\u00e1n los mismos comandos de texto en binario antes de transmitirlos por la red. La capa de enmarcado binaria no es compatible con HTTP1.x para clientes y servidores y un factor clave para una mejora significativa del rendimiento sobre SPDY y HTTP1.x. Utilizando comandos binarios para habilitar ventajas empresariales claves para empresas de internet y los negocios en l\u00ednea como se detalla con beneficios de HTTP\/2 explicados a continuaci\u00f3n:<\/p>\n La implementaci\u00f3n de HTTP\/2 permite que el cliente proporcione preferencia a determinadas corrientes de datos. Aunque el servidor no est\u00e1 obligado a seguir estas instrucciones del cliente, el mecanismo permite al servidor de la red optimizar la asignaci\u00f3n de recursos basada en las necesidades del usuario final.<\/p>\n La priorizaci\u00f3n de flujo funciona con dependencias y peso asignado a cada secuencia. Aunque todas las secuencias son inherentemente dependientes una de la otra, excepto que los flujos dependientes tambi\u00e9n se les asigna peso entre 1 y 256. Los detalles de los mecanismos de priorizaci\u00f3n de flujo a\u00fan son objeto de debate.<\/p>\n En el mundo real, sin embargo, rara vez el servidor tiene el control sobre los recursos como el CPU y las conexiones de bases de datos. La complejidad de la implementaci\u00f3n en s\u00ed impide que los servidores acomoden solicitudes prioritarias de flujo. La investigaci\u00f3n y desarrollo en esta \u00e1rea es particularmente importante para el \u00e9xito a largo plazo de HTTP\/2, ya que el protocolo es capaz de procesar varios flujos de datos con una \u00fanica conexi\u00f3n TCP.<\/p>\n Esta capacidad puede conducir a la llegada simult\u00e1nea de las peticiones al servidor que realmente difieren en t\u00e9rminos de prioridad, desde la perspectiva del usuario final. Mantener las solicitudes de procesamiento de flujo de datos sobre una base aleatoria socava la eficacia y experiencia de usuario final prometida por cambios a HTTP\/2. Al mismo tiempo, un inteligente y ampliamente adoptado mecanismo de prioridad de flujo presenta ventajas de HTTP\/2 explicadas como sigue:<\/p>\n Entregando una experiencia de usuario web de \u00faltima gama requiere sitios web ricos en contenido y gr\u00e1ficos. El protocolo de aplicaci\u00f3n HTTP es stateless, lo que significa que cada solicitud de cliente debe incluir tanta informaci\u00f3n como la que necesita el servidor para realizar la operaci\u00f3n deseada. Este mecanismo hace que los flujos de datos transporten varios marcos repetitivos de informaci\u00f3n tal que el servidor no tiene que almacenar informaci\u00f3n de anteriores solicitudes de cliente.<\/p>\n En el caso de sitios web que sirven contenido multimedia rico, los clientes empujan varios marcos de encabezado casi id\u00e9nticos que conducen a la latencia y el consumo innecesario de los limitados recursos de la red. Una mezcla de prioridades de los flujos de datos no puede alcanzar los est\u00e1ndares de desempe\u00f1o deseado de paralelismo sin optimizar este mecanismo.<\/p>\n La implementaci\u00f3n de HTTP\/2 resuelve estos problemas con la capacidad de comprimir gran n\u00famero de marcos de encabezados redundantes. Utiliza la especificaci\u00f3n HPACK como un m\u00e9todo sencillo y seguro para la compresi\u00f3n del encabezado. Tanto el cliente como el servidor mantiene una lista de los encabezados utilizados en las anteriores solicitudes de cliente-servidor.<\/p>\n HPACK comprime el valor individual de cada encabezado antes de transferirla al servidor, que luego busca la informaci\u00f3n codificada en la lista de valores de encabezado previamente transferidas para reconstruir toda la informaci\u00f3n del encabezado. La compresi\u00f3n de encabezado HPACK para la implementaci\u00f3n de HTTP\/2 presenta enormes ventajas de rendimiento, incluidos algunos beneficios de HTTP\/2 que se explican a continuaci\u00f3n:<\/p>\n La sem\u00e1ntica de la aplicaci\u00f3n subyacente de HTTP incluyendo los c\u00f3digos de estado de HTTP, URIs, metodolog\u00edas y ficheros de encabezado permanecen iguales en la \u00faltima iteraci\u00f3n del HTTP\/2. HTTP\/2 se basa en SPDY, la alternativa de Google a http1.x. Las verdaderas diferencias radican en los mecanismos utilizados para procesar solicitudes de cliente-servidor. La siguiente tabla identifica algunas \u00e1reas de similitudes y mejoras entre HTTP1.x, SPDY y HTTP\/2:<\/p>\nEsta Gu\u00eda Resalta los Siguientes Aspectos Clave de HTTP\/2:<\/h3>\n
\n
<\/a>\u00bfQu\u00e9 es HTTP\/2?<\/h2>\n
![\"Cronograma](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http-timeline.png\")
\u00bfQu\u00e9 Es un Protocolo?<\/h3>\n
![\"Correo](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/mail-http2.png\")
<\/a>El <\/b>Objetivo de Crear HTTP\/2<\/h2>\n
![\"website](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/website-basic.png\" "\\"Internet")
![\"Cifrado](\"https:\/\/kinsta.com\/wp-content\/themes\/kinsta\/images\/learn\/what-is-http2\/encryption.png\" "\\"HTTP\/2")
<\/a>\u00bfQu\u00e9 Estaba Mal con HTTP1.1?<\/h2>\n
![\"](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http-requests.png\")
![\"El](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-domain-sharding.png\" "\\"HTTP\/2")
<\/a>Actualizaciones de las Caracter\u00edsticas de HTTP\/2\u00a0<\/span><\/h2>\n
Flujos multiplexados<\/h3>\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-streams.png\")
\n
HTTP\/2 Server Push<\/h3>\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-push.png\")
\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-authorized.png\")
Protocolos Binarios<\/h3>\n
![\"Protocolos](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/binary-protocols-2.png\")
\n
Priorizaci\u00f3n de Flujo<\/h3>\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-weight.png\")
\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-page-load.png\")
Compresi\u00f3n de Encabezado Stateful<\/h3>\n
![\"Compresi\u00f3n](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-hpack-compression.png\")
\n
<\/a>Similitudes con HTTP1.x y SPDY<\/h2>\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-https.png\")
![\"Cifrado](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-encryption.png\")
![\"Velocidad](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/internet-speed.jpg\")
![\"Mejoras](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-performance-improvements.jpg\")
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2_mobile.png\")
![\"La](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/internet-price-drop.png\")
![\"Mapa](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/bandwidth-map.png\")
![\"El](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/mobile-first.png\")
![\"Seguridad](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-security.png\")
![\"Ventajas](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-seo-advantages.png\")
![\"Gr\u00e1fico](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-comparison.png\")
![\"Soporte](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-browser-support.png\")
![\"Soporte](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-nginx-apache-support.png\")
![\"Agregar](\"https:\/\/kinsta.com\/wp-content\/uploads\/2015\/04\/add-lets-encrypt-certificate.png\" "\\"Add")