El próximo HTTP/3 supondrá el fin del protocolo TCP
La IETF (Internet Engineering Task Force) ha publicado información
sobre lo que será el nuevo protocolo de transferencia de hypertexto que
tanto usamos a diario, cuando accedemos a sitios web. HTTP/3 ya no usará
TCP nunca más. En su lugar se ejecutará sobre el protocolo QUIC.
La IETF ha estado desde 2016 trabajando a fondo con una versión global del protocolo alumbrado por Google, y finalmente ha sido este año cuando ha decidido incluirlo en la nueva versión HTTP/3.
Sin embargo, la versión QUIC de la IETF ya es diferente de lo que se pensó en el diseño del protocolo original.
El cometido del protocolo QUIC es buscar simplicidad y velocidad
mientras se intenta mantener un nivel de seguridad apropiado, gracias al
cifrado ofrecido por TLS 1.3.
Lo que se ha hecho es bucar un medio más eficiente en cuanto a establecimiento de conexión y transferencia de datos. Según Google, los handshakes (saludos) de QUIC requieren 0 roundtrips para enviar la carga del mensaje, comparado con el estandar de 1 a 3 roundtrips requeridos con la combinación TLS + TCP.
Solamente el 1,2% de las webs soporta QUIC por el momento, normalmente se trata de sitios web con mucho tráfico. Por supuesto es el caso para casi todos los servicios que ofrece Google.
Un trabajo de Robert Lychev en 2015 dejó entrever algunas debilidades en el protocolo. Por ejemplo, se puede mermar su rendimiento con ataques como el de Server Config Replay.
Esto afectaría al rendimiento, aunque por fortuna de momento no tenemos constancia de afectaciones a la integridad o la confidencialidad, según los propios test realizados por Google y la IETF.
Si quieres saber más sobre este protocolo, que vendrá adoptado por la próxima iteración de HTTP, HTTP/3, puedes consultar estas fuentes:
El protocolo QUIC fue elaborado conceptualmente por Google en 2012 y tiene como objetivo mejorar tanto la seguridad como el rendimiento ofrecido por Transmission Control Protocol, sobre todo lo segundo.
¿Qué es Quic y sus diferencias con TCP?
Quick UDP Internet Connections (Quic, para los amigos) es un protocolo de capa de transporte que se basa en el multiplexado de conexions UDP. De hecho, QUIC utiliza esta combinación:TCP + TLS + SDPY sobre UDPEsto lo hace con varias mejoras respecto a la actual implementación de TCP.
La IETF ha estado desde 2016 trabajando a fondo con una versión global del protocolo alumbrado por Google, y finalmente ha sido este año cuando ha decidido incluirlo en la nueva versión HTTP/3.
Sin embargo, la versión QUIC de la IETF ya es diferente de lo que se pensó en el diseño del protocolo original.
Lo que se ha hecho es bucar un medio más eficiente en cuanto a establecimiento de conexión y transferencia de datos. Según Google, los handshakes (saludos) de QUIC requieren 0 roundtrips para enviar la carga del mensaje, comparado con el estandar de 1 a 3 roundtrips requeridos con la combinación TLS + TCP.
Un roundtrip es, en oposición a lo que tarda en enviarse o recibirse un mensaje entre un origen y un destino, el tiempo o saltos que requieren el circuito completo. Esto es, el mensaje inicial con su consiguiente respuesta.Ya sabemos que TCP es un protocolo muy antiguo y nunca ha sobresalido por su eficiencia o baja latencia de envío. Dado que cada vez utilizamos anchos de banda mayores, era cuestión de tiempo buscarle un sustituto. No se trata re reinventar la rueda, sino de hacer el protocolo más eficiente.
Solamente el 1,2% de las webs soporta QUIC por el momento, normalmente se trata de sitios web con mucho tráfico. Por supuesto es el caso para casi todos los servicios que ofrece Google.
¿Es seguro QUIC?
El primer desarrollo de QUIC contenía su propio cifrado, pero era algo temporal hasta que el protocolo TLS 1.3 estuviera listo para reemplazarlo, algo que se acordó con la IETF. En palabras de sus desarrolladores:QUIC se basa en un saludo combinado de criptografía y transporte para minimizar la latencia al establecer la conexión.Por definición, con este protocolo todo estará cifrado de serie. Sin embargo no está exento de sus propios riesgos teóricos.
Un trabajo de Robert Lychev en 2015 dejó entrever algunas debilidades en el protocolo. Por ejemplo, se puede mermar su rendimiento con ataques como el de Server Config Replay.
Esto afectaría al rendimiento, aunque por fortuna de momento no tenemos constancia de afectaciones a la integridad o la confidencialidad, según los propios test realizados por Google y la IETF.
Si quieres saber más sobre este protocolo, que vendrá adoptado por la próxima iteración de HTTP, HTTP/3, puedes consultar estas fuentes:
Fuente: ProtegerMiPC
Comentarios
Publicar un comentario