La próxima versión de HTTP no usará TCP [ENG]

En sus continuos esfuerzos por agilizar las redes web, Google ha estado trabajando en un protocolo de red experimental llamado QUIC: "Quick UDP Internet Connections". QUIC abandona TCP, en su lugar utiliza su protocolo hermano UDP (User Datagram Protocol). [...] La Internet Engineering Task Force (IETF), el grupo de la industria que colabora en el diseño de protocolos de red, ha estado trabajando para crear una versión estandarizada de QUIC, que actualmente se desvía significativamente de la propuesta original de Google.

[#2 --352386--]

Hagamos un nuevo stándard.

[#3 Trigonometrico]

A mi esto me suena a una explosión de nuevos bugs y a una pérdida de privacidad para conocer que es lo que miramos en Internet sin precedentes.

[#4 flixter]

#1 ¿Ein? ¿Estas seguro de que SSL no va sobre TCP?

[#5 --515017--]

Pues de TCP a UDP tampoco es que haya muchas diferencias... A ver, básicamente eliminan el tráfico generado por ACKs y otros paquetes de control. Pero de ahí a que sea muchísimo mejor...

[#6 manuelpepito]

#3 A mi lo que realmente me preocupa es que pasa con los puertos del Emule

[#7 --358834--]

Que yo sepa http no gestiona el uso de tcp. Salvo que ahora la capa 7 del OSI de ISO se conecte directamente con la capa 3. Como me mola decir osi de iso

[#8 --358834--]

#5 Si fuese mucho mejor, hace tiempo que todo se haría bajo UDP. UDP como bien dices ahorra tráfico pero a costa de mayor inseguridad. Inseguridad por corrupción de paquetes en la transmisión e inseguridad porque es infinitamente más fácil hacerle un mim a udp que a tcp (cortar la comunicación en medio de una 'conversación' entre 2 terminales y suplantar a uno de ellos sin que ninguno de los dos lo note)

[#9 Dene]

#7 eso!

[#10 redscare]

WTF??? Es difícil poner tantas cosas mal en una sola frase, ahí te reconozco el mérito.

[#11 vomitologo]

Excelente! Un paso más hacia un Internet descentralizado. Que la gente se vaya dando cuenta de que su seguridad digital es importante.

[#12 nexus5]

#4 Hay protocolos que si( PPTP que es TCP 1723), y protocolos que no, (UDP 400, 4500 para IPSec)

Edito: Me he confundido, he contestado a VPN, en vez de SSL

[#13 redscare]

#2 Obligatory XKCD. Pero coñas aparte parece bastante opcional. Si servidor y navegador lo soportan, se usa. Y sino pues hace downgrade a TCP.  

[#14 dospuntoswq]

#6 Nada. El protocolo TCP no se va a eliminar. Simplemente que cuando cliente y servidor sean compatibles con el nuevo protocolo negociarán (se dice así) mejorar a HTTP 3. Es lo mismo que pasa con HTTP 2

[#15 redscare]

#7 Correcto. Pero con esto quieren suplir las carencias de UDP (ordenación de paquetes y resto de historias) metiendo lógica adicional en HTTP. De ahí la relación.

[#16 xizor]

Bueno, SCTP iba a desbancar a TCP, así que supongo que este se tendrá que poner a la cola

[#17 dospuntoswq]

#8 No se trata de que sea mejor a peor. TCP se creó para solucionar ciertos problemas que ya no son tan habituales.
En un paquete UDP puedes meter lo que quieras, cifrado o no. Incluso podrías montar una mixnet!

[#18 LeDYoM]

#16 A la pila, querras decir.

[#19 demostenes]

El modelo de capas OSI a la mierda
Yo propongo algo mejor que usar UDP y es mandar los ceros y unos usando videos de gatitos. Total es lo que busca la gente. ¿Para que tanto protocolo?

[#20 orangutan]

#7 Eso de osi de iso no se aplica en la práctica, no existe la capa 7. Son capas TCP/IP

[#21 Ohtar]

#20 Decir "Eso de Osi de ISO" mola más aún que decir "OSI de ISO"

[#22 Jokessoℝ]

webs en streaming.Y ya no seremos internautas, seremos putos televidentes definitivamente.

[#23 --589369--]

#19 El modelo de capas OSI a la mierda

Por qué dices eso?

[#24 mandelbr0t]

#1 TCP está pensado y diseñado para cuando las conexiones eran una kk y de 10 paquetes perdías 3. Ahora no tiene sentido manejar la redundancia que lleva a ese nivel de red.
UDP es una auténtica maravilla de velocidad y fiabilidad en las conexiones actuales. Cualquier VPN que se precie va sobre UDP.

#2 UDP es tan viejo como TCP

[#25 foxaxel]

#5 Nooo que va, tampoco muchas

Más que las diferencias te pediría que contases un poco las similitudes entre ambos, para acabar antes digo.

[#26 redscare]

#11 No lo has entendido

[#27 demostenes]

#23 Porque si se usa UDP para transmitir datos, el chequeo y corrección de errores de transmisión de datos deja de estar en la capa de protocolo de comunicación para pasar a la capa de aplicación. La aplicación no debería encargarse de eso, bastante tiene con interpretar los datos como para encima verificar si son correctos.

[#28 --515017--]

#25 Estoy como para acordarme de lo que estudié hace 18 años
Pero vamos: es.diffen.com/tecnologia/TCP-vs-UDP

[#29 anv]

Estemmm... el udp es un protocolo pensado para cuando la pérdida de paquetes no es importante.
Por ejemplo, si estoy transmitiendo una comunicación telefónica, y un paquete falla, no tengo tiempo de retransmitirlo. Si lo mando de nuevo no me sirve de nada. Es preferible que el que está recibiendo escuche un silencio en lugar del paquete perdido a que el paquete llegue más tarde y suene como un ruido en medio de la conversación.

Cualquier intento de usar UDP para tráfico que no pueda perderse implicará agregar al UDP un método para verificar la llegada de paquetes y reenviarlos cuando no lleguen, cosa que ya tiene implementada el TCP.

Pero bueno, si quieren reinventar la rueda, quién soy yo para decir si no les saldrá mejor...

[#30 foxaxel]

#28 No si ya se nota porque para mi se parecen como un huevo a una castaña

[#31 --164239--]

El udp tiene alguna ventaja oculta, es más hackeable en los routers, un servidor web puede hacerles perrerías para conseguir conexiones p2p entre clientes que ahora quieren estandarizar para videoconferencias dentro del browser.
Jilipolleces que se eliminarían con TCP y ipv6 y eliminando el uso de NAT como elemento de seguridad.
Pero bueno, poco van a rascar con UDP respecto a HTTP2.

[#32 --38521--]

#3 Hasta donde yo se, no hay diferencias en la privacidad de UDP y TCP.

Ambos pueden ir cifrados con los metodos X Y Z o no.

[#33 ralph]

#24 UDP fiabilidad???

a UDP se la suda la fiabilidad... es una de sus característiscas... por eso es rápido... él manda paquetes y ahí acabó su trabajo...

Y lo de que no tiene sentido TCP... no sé por qué lo piensas...

[#34 ralph]

#19 No veo por qué... la gran ventaja de OSI es que puedes hacer que otra capa haga el trabajo de la "anterior"...

[#35 --38521--]

#8 Se supone que tienes una capa de seguridad con TLS/DTLS, con lo cual no puedes hacer un mitm, por mucho que sea UDP.

Si no me estoy equivocando, que puede ser, la capa de TCP y UDP, basicamente no se encarga de la seguridad/privacidad en absoluto. Es trabajo de otras capas superiores.

[#36 Ferk]

#30 Depende del marco de referencia.
Es como decir que comer con cuchara y comer con tenedor son totalmente diferentes. O que el rojo y el azul son diametralmente opuestos.

Obviamente son diferentes.. pero dependiendo de como uses los cubiertos, o de como combines los colores al final el resultado no necesariamente va a cambiar mucho, por lo tanto puede ser que no importe demasiado.

Obviamente si profundizas hasta dos huevos idénticos tienen diferencias que los hace ser totalmente distintos al ser huevos individuales.

[#37 --571567--]

#35 ¿Entonces TCP genera números aleatorios para las secuencias porque si? Por mencionar algo.

[#38 --38521--]

#37 Entiendo que esos mecanismos de numeros de secuencia, claves temporales de sesion y demas los plantean implementar en una capa superior.

Al final tendran que re-implementar buena parte de lo que hace TCP, supongo que su idea es hacerlo mas eficiente de esta forma, pero habra que verlo para creerlo.

[#39 --571567--]

#27 Ya ves, menuda perdida de tiempo; de qué le sirve a torrent por ejemplo comprobar los hashes?

[#40 Avantasia]

#4 SSL va normalmente sobre TCP, es lo suyo, pero por poder podría ir sobre UDP , es un protocolo de una capa superior, por definición no puede ser dependiente de un protocolo específico de una inferior, si fuera así se trataría del mismo protocolo o de una extensión o una ampliación de un protocolo.
De hecho la noticia implica eso, que va a ir sobre QUIC, que es en parte más parecido a UDP que a TCP, así que no es una locura, se puede implementar las características que te interesen en cualquier capa.
Como nota, esta noticia y otras que han pasado más o menos desapercibidas, como que los navegadores empezarán en breve a usar DNS sobre HTTP, o cómo se ha hecho la implementación de HTTP/2 entre google y chrome.. es curioso como se está implementando todo cada vez más a nivel de aplicación,está claro que estas compañías están poniéndose las pilas y Google tiene una posición privilgiada a nivel de red al tener un porcentaje enorme de las conexiones HTTP tanto en cliente como en servidor, pero no se si esto será positivo a largo plazo, por la centralización, ¿alguien se lo ha planteado? bueno, es una reflexión tanto técnica como filosófica, si alguien quiere comentar adelante.

[#41 flixter]

#40 Coincido contigo en todo, pero no estabamos discutiendo sobre si "SSL puede ir sobre UDP", sinó si "SSL va sobre TCP". De momento todo esto no dejan de ser pruebas de concepto y tal, a ver en qué va a quedar todo.... Pero sí que es un momento super interesante para provar cosas nuevas

[#42 Avantasia]

#24 Bueno, si me permites discrepo en un par de cosas.

Una ya ha te la dicho #24, UDP no es fiable, otra cosa es que la conexión sea fiable y no te haga falta corrección de errores, en cuyo caso la fiabilidad que aporta TCP se convierte en una sobrecarga innecesaria.

Por otra parte TCP no sólo es fiabilidad, es muchas cosas más, desde flags que no se pueden implementar en UDP, que te permiten controlar sesiones, aplicar QoS, informar a la aplicación de eventualidades en la transmisión, controlar la cogestión, o adaptar el flujo de dato a las circunstancias del momento, o algo tan simple como reordenar (numerar) los segmentos.

O haces todo eso en alguna otra capa, o usas TCP, a veces no hace falta reinventar la rueda y TCP hace su trabajo bien, y NO es lento, obviamente entre la sobrecarga de alguna función y los ACK .. pero oye, si no lo hace TCP lo tendrá que hacer el protocolo de turno en aplicación, sesión, en enlace (puedes poner x25 chiste de viejuno), pero en algún sitio tendrás que confirmar, comprobar etc.. lo hará ese procolo mejor que TCP? pues a saber. Decir que es más lenta una VPN o una aplicación cualquiera sobre TCP o sobre UDP sin tener más datos es un poco aventurado, y aunque lo sea la diferencia puede no ser tan tan grande.

Otra cosa, hay VPNs "que se precian" que usan TCP, por ejemplo una VPN de OpenVPN te permite elegir TCP o UDP, en otros casos usan UDP pero porque no hay más cojones porque hay que atravesar la mierda de NAT (esto si que es un cáncer), por ejemplo las VPN con IPSec te crees que usan UDP por algo más que porque es necesario en situaciones como las de NAT o firewalls? pues no, ni TCP ni UDP.

[#43 Avantasia]

#41 pruebas de concepto nada, hace unos años lo probaron en vivo si usabas Chrome y te conectabas a google capturabas con el wireshark y veías las conexiones QUIC en vez de las TCP que esperabas (además esto me pasó dando una clase de redes en medio de un ejercicio que propuse y me quedé a cuadros ) , quiero decir.. esto ya funciona

[#44 llorencs]

#7 Sino recuerdo mal, TCP eran 5 capas. Las 7 capas no existen en ninguna implementación.

Hace años que di redes y ya no me acuerdo.

[#45 Avantasia]

#8 ¿Infinitamente más fácil por qué? es exactamente igual de fácil hace un MitM en una conexión TCP que en una UDP, exactamente.
Vi tu comentario de abajo sobre los números de secuencia, pero la finalidad de estos es evitar inyectar un paquete en una conexión existente y por ejemplo, hacer un reset y joder las conexiones ya establecidas.
Pero vamos no evita el MitM ni lo hace más difícil, ojala pero date cuenta que en ese caso el del medio va a generar nuevos números de secuencia para cada extremo.

[#46 Avantasia]

#7 Bueno según el modelo TCP/IP (OSI no es el único modelo), que además tiene más sentido en la práctica, la capa de aplicación se conecta directamente con la de transporte (que por cierto es la 4, no la 3, la 3 es red/internet)
Tiene más sentido porque en el navegador se implementan sesión, presentación y aplicación de OSI, así que es todo aplicación y pista, desde el punto de la red para que complicarse más.

[#47 tul]

#14 esperate y no corras, no creo que tarden en aparecer los operadores que unicamente oferten este nuevo protocolo y te capen todos lo demas.

[#48 Avantasia]

#16 y SPDY

[#49 Avantasia]

#27 ¿No debería ocuparse de eso por qué? se hará en donde sea más eficiente, si total ahora mismo (salvo que tengas una tarjeta de red con TCP Offload, que son las caras ) el trabajo de TCP lo está haciendo el mismo dispositivo que lo va a hacer después, la CPU de tu ordenador.
Si realmente el rendimiento de esto es mejor que el de TCP y lo hace el mismo dispositivo, pues win-win, que eso no lo se eh, habrá que verlo en la práctica, solo digo que en principio no hay una capa óptima para encargarse de algo siempre y cuando todo el stack tenga sentido, no duplique funciones, se complemente y sea eficiente.

[#51 Avantasia]

#29 Por que os empeñais en que esa es la única diferencia entre TCP y UDP, pero no puede estar más alejado de la realidad.
La cabecera de TCP son entre 20 y 60 bytes, de estos solo 8 bytes son secuencia y ACK, que es en lo que os centráis.
La cabecera de UDP son 8 bytes.

Si yo implemento UDP y le sumo un método de verificación en aplicación (que no tiene por qué ser de seq-ack), tengo bastante margen para optimizar como ves si no me interesan el resto de flags y opciones de TCP.

[#52 Avantasia]

#31 Que? quiero llorar :_(

[#53 anv]

#51 Claro, tienes razón. Lo que pasa es que al UDP hay que sumarle bastantes cosas para ponerlo al nivel de fiabilidad del TCP. Puede que ahorres un poco pero con las velocidades actuales no se si se justifica el cambio.

[#54 prejudice]

Por fin tendremos websockets sobre UDP

[#55 Avantasia]

#53 No solo es la velocidad o el throughput total, sino la forma de hacer las cosas, por ejemplo el método de TCP para gestionar los ACKs, el tamaño de ventana etc (que además la implementación en cada SO es diferente!!), no suele ser óptimo en términos de latencia.
Por lo que vi en las especificaciones de QUIC, también multiplexa conexiones (como HTTP/2) evitando el hol-blocking.
Claro la velocidad importa y los bits que se ahorran, pero no todo es eso, yo decía lo de las cabeceras más para mostrar visualmente que hay mucho más que los acks y los seq que por los bits en si

[#56 anv]

#55 Pues tal vez entonces lo ideal sería crear un protocolo nuevo. Eso permitiría aprovecharlo en otras cosas a demás de http.

[#57 flixter]

#43 "Esto funciona" quiere decir: en un 0.8% de los servidores de la web (como se indica en wikipedia). Para mí, hasta que no haya una masa crítica... O sea: nos hemos acostumbrado a que o los desarrolladores (google, mozilla, etc.) nos enchufan funcionalidades experimentales, o las pedimos nosotros para probar, pero que dichas funcionalidades esten disponibles para el público no implica que dejen de ser "pruebas de concepto".

[#58 Avantasia]

#56 Claro que si, pero se han adelantado a quienes más les beneficia, que es en este caso es Google. Y es que tiene además la oportunidad, tanto en el lado del cliente como en el del servidor, de hacerlo a escala mundial en cuanto quieran, por lo tanto pueden y lo hacen, lo veo razonable, yo también lo haría .. además al implementarse en las capas superiores lo hacen sin tener que esperar a que se implemente en los dispositivos intermedios, que sería lo que pasaría si quisiéramos directamente reemplazar TCP por un protocolo mejor.
Ejemplo claro, pero hay muchos más: IPv6, oh que guay, un procolo nuevo y seguro que reemplaza totalmente a IPv4, con muchas funcionalidades y que se pueden aplicar a muchas cosas, pero por ser de capa 3 hay que esperar a que todos los dispositivos intermedios lo implementen a cojones, y en esto los carriers, el middle mile, al que no le interesa invertir más en algo que ya funciona para ellos, frena el desarrollo.

[#59 dospuntoswq]

#47 Tu operador no te da una conexión a HTTP3, te la da a Internet. Capar TCP no aporta nada a la operadora que no sea perder clientes.

[#60 tul]

#59 tu dales tiempo, ademas seguro que te ofrecen un suculento descuento del 5% y la borregada pica en masa.

[#61 demostenes]

#49 Pues sí, duplicará funciones, porque sólo un protocolo, el http/3 será sin comprobación de datos y el resto sí.
A mi me rechina que el Chrome o el Firefox se encarguen de verificar que el paquete ha sido bien transmitido. Y me rechina tener que meter toda una capa http para verificar si los datos se transmiten correctamente, en lugar de confiarlo a una pila TCP/IP. Eso dificulta la creación de un cliente http/3.
#27 La comprobación de hashes de torrent no es una verificación de comunicación sino una autenticación de contenido. Se usa para distinguir contenidos con el mismo nombre, no que el contenido haya sido transmitido correctamente.
#19 Puedes hacerlo pero... ¿debes hacerlo?

[#62 mandelbr0t]

#42 De acuerdo en casi todo menos en el tema de velocidad. Si tienes una openvpn prueba a ponerla sobre UDP y pruebas velocidad antes y después, vas a alucinar.

[#63 provotector]

Google y su afán por reinventar las cosas que ya existen, hacerlas más complicadas y peores. Como AMP, go o kotlin...

[#64 Avantasia]

#62 A ver, es evidente que va a ir algo mejor, por muy poco que sea, después de todo aunque solo sea por el overhead estás perdiendo ancho de banda efectivo, por no decir que en el caso de la VPN estarías parte del tiempo encapsulando TCP sobre (muchas cosas más sobre) TCP con lo absurdo que eso es, pero aún así sin tener más datos asegurar que la diferencia en velocidad es extraordinaria a mi me parece bastante aventurado, habría que ver el entorno, la fiabilidad de la conexión, la existencia de QoS, de IDS o firewalls, el tipo de datos que envías por la VPN, etc..

Seguramente habrá diferencia de velocidad? pues seguramente, pero ni creo que sea tan grande ni creo que se pueda generalizar los resultados, estamos hablando de que a 1500 bytes el segmento, la diferencia de tamaño de las cabeceras de TCP y UDP es de un 0,08%, aunque se enviara un ACK por cada segmento, que no es así, sería un 4% de pérdida de throughput total, pero con la ventana deslizante y el piggybacking será infinitamente menos, pero vamos a ponernos en lo peor... yo no llamaría a esa diferencia "alucinante", no por lo menos lo suficientemente grande como para descartar la alternativa sin más información.

Vamos, que no todo es tan absoluto

[#65 --164239--]

#52 Por que quieres llorar? No lo has entendido?

[#66 Avantasia]

#65 Pues no, la verdad es que no

[#67 --164239--]

#66 ok, pues pregunta y ya está.
Solo decía que udp tiene una ventaja oculta a parte de las evidentes y es el control de los routers.
Con udp un webserver puede agujerear los routers y eludir el NAT de los clientes (con la colaboración de ellos), por ejemplo para conseguir que dos clientes de un webserver hablen entre ellos sin necesidad de ningún server intermedio. Esto lo hace ahora mismo google con su standard webrtc para el browser especificamente con su librería ice. Si el udp está capado normalmente ya se necesita un servidor turn intermedio y los costes se disparan.

[#68 --148836--]

#24 Ein ¿Fiabilidad UDP? ¿Justo un transporte de datagramas no fiable?
hombre para audio, vídeo o velocidad sin más (NFS etc.), donde la complejidad asociada a TCP redunda en un coste de eficiencia, pues se puede usar UDP.
Pero fiable UDP...
es rápido eso sí.

[#69 hinan]

#24 Aunque TCP no esté implementado sobre UDP, podría perfectamente.

[#70 Sandler]

#12 eso iba a responderte, he tenido que leerlo dos veces

[#71 hinan]

#27 y los routers no podrán gestionar las sesiones.

[#72 Avantasia]

#67 vale, ahora es entendible, pero bueno que eso no es una ventaja del udp ni es que sea hackeable en los routers sino que aprovechando la implementación de nat mas habitual se podría conseguir eso... Pero vamos en webrtc que es él ejemplo que poner se usa normalmente como una opción, pero prácticamente nunca como la única, en el caso de web donde el p2p es anecdotico nadie querría tener eso como único elemento de conectividad en su servidor web, vamos digo yo, porque perdería con bastante probabilidad a un % de sus clientes.

Por cierto la vpn que estoy utilizando también usa un método parecido (zerotier una sdn/vpn brutal y la técnica es udp hole punching, al que le molen las redes que se mire la doc de este proyecto que es una delicia), también lo usa como opción a y si no funciona recurre a un relay.

En lo de ipv6 y eliminar nat 100% de acuerdo, pero entonces ya no hablaríamos de usar tcp o udp sino muchos otros protocolos de transporte que hoy en día no tienen cabida por la mierda de nat.

[#73 hinan]

#39 Garantía de integridad, hay mucho enemigo suelto.

[#74 --571567--]

#73 Estaba siendo irónico jajaja

[#75 CoolCase]

#33 Del hecho el UDP es bueno para streaming y directos precisamente por lo que dices donde prima el tiempo real y no importa que se pierda algo de información.

[#76 Trigonometrico]

#22 A ver si el fascismo al final no va a ser tan bueno...