{"id":104306,"date":"2022-06-07T09:36:47","date_gmt":"2022-06-07T07:36:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/protokol-http-3-0-poluchil-status-predlozhennogo-standarta"},"modified":"2022-06-07T09:36:47","modified_gmt":"2022-06-07T07:36:48","slug":"protokol-http-3-0-poluchil-status-predlozhennogo-standarta","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/protokol-http-3-0-poluchil-status-predlozhennogo-standarta","title":{"rendered":"El protocolo HTTP\/3.0 recibi\u00f3 el estatus de est\u00e1ndar propuesto","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
El Comit\u00e9 IETF (Internet Engineering Task Force), encargado del desarrollo de protocolos y arquitectura de Internet, ha completado la formaci\u00f3n de la RFC para el protocolo HTTP\/3.0 y ha publicado las especificaciones relacionadas con los identificadores RFC 9114 (protocolo) y RFC 9204 (tecnolog\u00eda de compresi\u00f3n de encabezados QPACK para HTTP\/3). La especificaci\u00f3n HTTP\/3.0 ha recibido el estatus de \"Est\u00e1ndar Propuesto\", tras lo cual se comenzar\u00e1 a trabajar para otorgarle a la RFC el estatus de est\u00e1ndar borrador (Draft Standard), lo que significa, de hecho, la completa estabilizaci\u00f3n del protocolo y la consideraci\u00f3n de todos los comentarios emitidos. Al mismo tiempo, se han publicado versiones actualizadas de especificaciones para los protocolos HTTP\/1.1 (RFC 9112) y HTTP\/2.0 (RFC 9113), as\u00ed como documentos que definen la sem\u00e1ntica de las solicitudes HTTP (RFC 9110) y los encabezados de control de cach\u00e9 HTTP (RFC 9111). <\/p>\n
El protocolo HTTP\/3 define el uso del protocolo QUIC (Quick UDP Internet Connections) como transporte para HTTP\/2. QUIC es una capa 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, abordando problemas de tiempos altos de establecimiento y negociaci\u00f3n de conexiones en TCP y eliminando retrasos por p\u00e9rdida de paquetes durante la transmisi\u00f3n de datos.
<\/center> <\/p>\n
Actualmente, el soporte de QUIC y HTTP\/3.0 ya est\u00e1 implementado en todos los navegadores web populares (en Chrome, Firefox y Edge, el soporte para HTTP\/3 est\u00e1 habilitado por defecto, mientras que en Safari requiere activar la configuraci\u00f3n \"Advanced > Experimental Features > HTTP\/3\"). En el lado del servidor, las implementaciones de HTTP\/3 est\u00e1n disponibles para nginx (en una rama separada y en forma de un m\u00f3dulo separado), Caddy, IIS y LiteSpeed. La red de entrega de contenido Cloudflare tambi\u00e9n proporciona soporte para HTTP\/3. <\/p>\n
Caracter\u00edsticas principales de QUIC: <\/p>\n
\n
Alta seguridad, similar a TLS (de hecho, QUIC permite el uso de TLS sobre UDP); <\/li>\n
Control de integridad del flujo, previniendo la p\u00e9rdida de paquetes; <\/li>\n
Posibilidad de establecer conexi\u00f3n de inmediato (0-RTT, en aproximadamente el 75% de los casos, los datos se pueden transmitir inmediatamente despu\u00e9s de enviar el paquete de establecimiento de conexi\u00f3n) y asegurar m\u00ednimas latencias entre el env\u00edo de la solicitud y la recepci\u00f3n de la respuesta (RTT, Round Trip Time);
<\/center> <\/li>\n
El uso de un n\u00famero de secuencia diferente al retransmitir un paquete, lo que permite evitar ambig\u00fcedades al determinar los paquetes recibidos y eliminar los tiempos de espera; <\/li>\n
La p\u00e9rdida de paquetes afecta solo a la entrega de la corriente asociada y no detiene la entrega de datos en las corrientes que se transmiten en paralelo a trav\u00e9s de la conexi\u00f3n actual; <\/li>\n
Mecanismos de correcci\u00f3n de errores que minimizan la latencia debido a la retransmisi\u00f3n de paquetes perdidos. Uso de c\u00f3digos especiales de correcci\u00f3n de errores a nivel de paquete para reducir situaciones que requieren la retransmisi\u00f3n de datos de un paquete perdido. <\/li>\n
Los l\u00edmites de los bloques criptogr\u00e1ficos est\u00e1n alineados con los l\u00edmites de los paquetes QUIC, lo que reduce el impacto de la p\u00e9rdida de paquetes en la decodificaci\u00f3n del contenido de los siguientes paquetes; <\/li>\n
Ausencia de problemas de bloqueo de la cola TCP; <\/li>\n
Soporte para un identificador de conexi\u00f3n que permite reducir el tiempo de establecimiento de una nueva conexi\u00f3n para clientes m\u00f3viles; <\/li>\n
Capacidad de conectar mecanismos avanzados de control de congesti\u00f3n de la conexi\u00f3n; <\/li>\n
Uso de t\u00e9cnicas de predicci\u00f3n de ancho de banda en cada direcci\u00f3n para asegurar la intensidad \u00f3ptima de env\u00edo de paquetes, evitando caer en un estado de congesti\u00f3n donde se observa la p\u00e9rdida de paquetes; <\/li>\n
Incremento significativo en el rendimiento y la capacidad de transmisi\u00f3n en comparaci\u00f3n con TCP. Para servicios de video como YouTube, la implementaci\u00f3n de QUIC ha demostrado reducir las operaciones de rebuffering al ver videos en un 30%. <\/ul>\n
Entre los cambios en la especificaci\u00f3n HTTP\/1.1, se destaca la prohibici\u00f3n del uso aislado del s\u00edmbolo de retorno de carro (CR) fuera del cuerpo de contenido, es decir, en los elementos del protocolo el s\u00edmbolo CR solo puede usarse junto con el s\u00edmbolo de salto de l\u00ednea (CRLF). El algoritmo de composici\u00f3n de solicitudes en trozos se ha mejorado para simplificar la separaci\u00f3n de los campos adjuntos y la secci\u00f3n de encabezados. Se han a\u00f1adido recomendaciones para el manejo de contenido ambiguo para bloquear ataques del tipo \"HTTP Request Smuggling\", que permiten infiltrarse en el contenido de las solicitudes de otros usuarios en el flujo entre el frontend y el backend. <\/p>\n
En la actualizaci\u00f3n de la especificaci\u00f3n HTTP\/2.0, se define claramente el soporte para TLS 1.3. La categor\u00eda de esquema de priorizaci\u00f3n definida se ha trasladado a obsoleto, as\u00ed como los campos asociados en los encabezados. Se ha declarado obsoleto un mecanismo de actualizaci\u00f3n de conexi\u00f3n que no se populariz\u00f3 con HTTP\/1.1. Se han reducido los requisitos para la verificaci\u00f3n de nombres de campos y valores. Se han propuesto para su uso ciertos tipos de marcos y par\u00e1metros que anteriormente estaban reservados. Se han definido m\u00e1s claramente los campos de encabezado prohibidos relacionados con la conexi\u00f3n. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"El](\"\/wp-content\/uploads\/2022\/06\/0821fd634337ac1f1cc0924abb4f55dc.jpg\")
<\/center> <\/p>\n![\"El](\"\/wp-content\/uploads\/2022\/06\/d416668e500fd2b79304fa0b13f793e3.jpg\")
<\/center> <\/li>\n