#44369 Ah good.
Bueno yo agradeco todas las participaciones porque son los unicos data point de feedback que tienes. Eso y el numero de viewers... Que obviamente ira bajando a la que pasen 30 min o asi XD
No se, es un tema interesante el de quic. Por ejemplo, que libreria es mejor? Que diferencias hay entre ellas?
https://github.com/aws/s2n-quic
https://github.com/quinn-rs/quinn
https://github.com/cloudflare/quiche
https://github.com/mozilla/neqo
Cuales son las implicaciones y casos de uso en el mundo real de usar quic? Las unicas empresas que tienen estos datos son Google, AWS, Mozilla, Cloudflare y similares... En teoria va de puta madre porque lo estan usando y escalando, pero la gente que no tenemos acceso a ese trafico no podemos experimentar a ciegas. Pero luego la diferencia practica entre http1 y http2 no fue tan grande para muchas cosas. Depende del caso de uso. Streaming + mobile es la clave y seguramente para http3 lo seguira siendo.
Y la mayoria de webservers populares aun no implementan http3, porque son una puta porqueria lo primero, y lo segundo porque la gente que los mantiene son unos fperos, y tercero porque como la gente de a pie no entiende los pros/cons de http3 sobre http1 y http2 no aprietan para que lo implementen.
Esta claro que cualquier empresa moviendo +X miles de req/s ya vera beneficios, ya sea a nivel user => ALB, como a nivel microservicio.
Aqui por ejemplo hay details: https://aws.amazon.com/blogs/security/introducing-s2n-quic-open-source-protocol-rust/ + https://www.debugbear.com/blog/http3-quic-protocol-guide
Si tuviese un webserver escrito en http3 podria correr mis simulaciones yo mismo en mi serie.
Yo veo mucho beneficio a parte de los obvios en como he comentado a nivel de peticiones internas entre nodos distribuidos y side cars por ejemplo, eso seguro que va a mejorar por el tema de first byte o head of line blocking. Va a permitir tener politicas de balanceo, retries, teardown/tearup mucho mas agresivas. Algo que te tarda 5 minutos en estar ready para prod puedes tenerlo en 20 segundos. algo que ahora estas orchestrando y secuenciando con quic vas a poder tirar y reiniciar todo sin preocuparte en el orden de arranque.
Sobre esto ultimo, edito, ha dia de hoy la mayoria de estas cosas ya van con udp si son posible. pero podrias mover codigo de application a quic level gracias a pasar de udp a quic y tener mejor codigo interoperable. que es lo que siempre explico. que es lo que han hecho al pasar cosas de http2 a quic.
si en lugar de tener k8s que es programar a nivel de http, tu programas a nivel de quic y haces que las herramientas hablen este protocolo de un nivel inferior, vas a tener mejor rendimiento y eficiencia YYYY ademas vas a tener un monton de funcionalidades e interoperabilidad que trabajando a alto nivel no vas a poder tener. que por estas cosas tcp y udp llevan usandose toda la vida. hay tanta networking construida que todo se puede re utilizar. de esta manera no tendrias mil abstracciones llamandose entre ellas a nivel de aplicacion, sino que tendrias a nivel de protocolo una serie de bloques basicos re utilizables y componibles que a parte de ir mas rapido serian mas flexibles.
esto ultimo es el motivo por el cual unix gano a multics y el porque se dice que kubernetes es un multics contemporaneo. un os distribuido mal hecho.
