{"id":115269,"date":"2024-04-24T02:30:06","date_gmt":"2024-04-24T00:30:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-nginx-1-26-0-s-podderzhkoj-http-3"},"modified":"2024-04-24T02:30:06","modified_gmt":"2024-04-24T00:30:06","slug":"vypusk-nginx-1-26-0-s-podderzhkoj-http-3","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/vypusk-nginx-1-26-0-s-podderzhkoj-http-3","title":{"rendered":"Se lanza nginx 1.26.0 con soporte para HTTP\/3","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Despu\u00e9s de un a\u00f1o de desarrollo, se ha publicado una nueva rama estable del servidor HTTP de alto rendimiento y proxy multiprotocolo nginx 1.26.0, que incorpora los cambios acumulados en la rama principal 1.25.x. En adelante, todos los cambios en la rama estable 1.26 se centrar\u00e1n en solucionar errores serios y vulnerabilidades. Pronto se formar\u00e1 la rama principal nginx 1.27, donde se continuar\u00e1 desarrollando nuevas funcionalidades. Para los usuarios comunes, que no tienen la necesidad de asegurar compatibilidad con m\u00f3dulos de terceros, se recomienda utilizar la rama principal, de la cual se generan lanzamientos del producto comercial Nginx Plus cada tres meses. <\/p>\n
Seg\u00fan el informe de marzo de la empresa Netcraft, alrededor de 243 millones de sitios est\u00e1n gestionados por nginx (frente a 289 millones el a\u00f1o pasado). Nginx se utiliza en el 18.15% de todos los sitios activos (frente al 18.94% del a\u00f1o pasado, y al 20.08% hace dos a\u00f1os), lo que representa el segundo lugar en popularidad en esta categor\u00eda (la cuota de Apache es del 20.09% (frente al 20.52% del a\u00f1o pasado, y al 22.58% hace dos a\u00f1os), Cloudflare \u2014 14.12% (11.32%, 10.42%), Google \u2014 10.41% (9.89%, 8.89%). Sin embargo, al considerar todos los sitios, nginx mantiene el liderazgo con una cuota del 22.31% del mercado (frente al 25.94% del a\u00f1o pasado, y al 31.13% hace dos a\u00f1os), mientras que la cuota de Apache es del 20.17% (20.58, 23.08%), Cloudflare \u2014 11.24% (10.17, 5.49%), OpenResty (plataforma basada en nginx y LuaJIT) \u2014 7.93% (7.94%, 8.01%). <\/p>\n
Entre un mill\u00f3n de los sitios m\u00e1s visitados del mundo, la cuota de nginx es del 20.63% (hace un a\u00f1o era del 21.37%, hace dos a\u00f1os del 21.79%), Cloudflare \u2014 22.59% (hace un a\u00f1o era del 21.62%), Apache httpd \u2014 20.09% (21.18%). Seg\u00fan datos de W3Techs, nginx se utiliza en 34.3% de los sitios de los mil m\u00e1s visitados; en abril del a\u00f1o pasado ese porcentaje era del 34.5%, y hace dos a\u00f1os del 33.1%. La cuota de Apache ha disminuido del 32.2% al 30.1% en un a\u00f1o, y la cuota de Microsoft IIS ha disminuido del 5.6% al 4.8%. La cuota de Node.js ha aumentado del 2.4% al 3.2%, y la cuota de LiteSpeed ha pasado del 11.8% al 12.9%. <\/p>\n
Mejoras m\u00e1s notables a\u00f1adidas en el proceso de formaci\u00f3n de la rama principal 1.25.x: <\/p>\n
\n
Se ha a\u00f1adido el m\u00f3dulo ngx_http_v3 con soporte experimental para el protocolo HTTP\/3. Para compilar el m\u00f3dulo, existe la opci\u00f3n \u2014with-http_v3_module. HTTP\/3 define el uso del protocolo QUIC (Quick UDP Internet Connections) como transporte para HTTP\/2. QUIC es una superestructura sobre el protocolo UDP, que admite la multiplexi\u00f3n de m\u00faltiples conexiones y proporciona m\u00e9todos de cifrado equivalentes a TLS\/SSL. El protocolo fue creado en 2013 por Google como una alternativa a la combinaci\u00f3n TCP+TLS para la web, resolviendo problemas de latencia y negociaci\u00f3n de conexiones en TCP y eliminando retrasos causados por la p\u00e9rdida de paquetes durante la transmisi\u00f3n de datos.\n
Se ha a\u00f1adido una directiva separada 'http2' para habilitar selectivamente el protocolo HTTP\/2 en la vinculaci\u00f3n de servidores (puede utilizarse en bloques 'server' individuales). El par\u00e1metro 'http2' en la directiva 'listen' ha sido declarado obsoleto.\n
Se ha mejorado la protecci\u00f3n contra actividades an\u00f3malas de clientes HTTP\/2, especialmente contra ataques DoS de la clase 'Rapid Reset', en los que se crea un gran n\u00famero de flujos que se cierran simult\u00e1neamente dentro de una sola conexi\u00f3n HTTP\/2. En la configuraci\u00f3n predeterminada, tales ataques chocan con el l\u00edmite del n\u00famero de solicitudes por conexi\u00f3n 'keepalive_requests' (despu\u00e9s de cada 1000 solicitudes, la conexi\u00f3n ser\u00e1 restablecida) y con las restricciones 'limit_req'. Para una respuesta m\u00e1s r\u00e1pida al inundar solicitudes a trav\u00e9s de un gran n\u00famero de flujos, se agreg\u00f3 una restricci\u00f3n adicional que no permite, por defecto, crear m\u00e1s de 256 (2 * max_concurrent_streams) nuevos flujos en cada ciclo de procesamiento de eventos. Esta nueva restricci\u00f3n permite comenzar a bloquear solicitudes antes de alcanzar el l\u00edmite total de flujos simult\u00e1neos, por ejemplo, cuando los flujos se procesan de manera as\u00edncrona o se cierran.\n