Tcp/ip deprecated

based google as always innovating

Attached: quic_example.png (997x536, 46.48K)

whats the overhead

TCP/IP overhead on standard MTU is like 5.5% making a 1gbps connection max out at around 945mbps.

Its too risky
If it failed the whole internet would go down

google already tested and
>If it failed the whole internet would go down
>implying that would be bad

generally higher overhead due to how it works, but can be optimized to just barely beat standards TLS+TCP

Attached: 1652164720943.png (715x318, 26.45K)

>Rebranded UDP
bruh

What's the price? The rest of our data? Automatic block from the entire internet if your opinions aren't up to the latest SJW specs? I don't trust google for shit anymore.

holy shit, imagine being this braindead

How does that work?

it's actually great, they built on top of udp for legacy reasons, you can't just patch an entire infrastructure

>it's actually great, they built on top of udp for legacy reasons, you can't just patch an entire infrastructure
Yeah but what's the point?
Why not use UDP instead then?

If the internet went down for just a day there'd be like multiple billion of dollars worth of damage

>trust us or we'll shame you on the internet
By all means, continue, it's very convincing. I'm sick of google's influence, and so should everyone else be.

>there'd be like multiple billion of dollars worth of damage
And that happening to the current system would be bad because...

>multiple billion of dollars worth of damage
Nobody dies
No physical damage
Not my problem

Attached: 1652800454851.gif (220x369, 663.58K)

>Why not use UDP instead then?
it's not connection-oriented, quic has reliable data transfer, etc.

only works for "unreliable" (yes they call it that way) data streaming across the internet that needs high bandwidth and low latency. Like Cloud Gaming or video chats

>deprecated
not really, TCP will never be deprecated. middlewares have made sure that it's impossible to replace.
QUIC manages to get through ~95% of the middlewares of the internet, which is pretty good compared to any other TCP alternative that was ever proposed, but not good enough to permit a widespread adoption for it.

Attached: 1635302967619.png (512x468, 189.42K)

>t.cp

Attached: 1640052116220.png (483x470, 183.71K)

they built on top of udp just because of middleware

Has it been adopted yet?

QUIC in 0-RTT mode is less secure.

>quic ACK

This is a classic case of if it aint broken don't fix it but lets do it anyways

yeah, but its still not good enough
TCP traffic gets through virtually 100% of middlewares, while there is a relevant amount of QUIC traffic that gets blocked for one reason or another

Attached: 1627612770048.jpg (770x600, 74.59K)

>only works for "unreliable" (yes they call it that way) data streaming across the internet that needs high bandwidth and low latency. Like Cloud Gaming or video chats
It uses a handshake that is already encrypted, removing the need for the tls separated rtt, if you connected recently to the server you can skip the need for the handshake with the 0-rtt, which can be useful for that.

Attached: quic.png (1600x477, 63.16K)

>why would an instantaneous economic crisis be bad
Because then you won't be able to afford your weekly Funko pops anymore

Im not going to use anything introduced by Google

it would be bad for google
so expect this technology to vanish

>Im not going to use anything introduced by Google
it's just a fucking protocol, chill dude.

>based google as always innovating
QUIC/HTTP3 exists for some time now, I think first implementations started about five years ago?
It is a good idea because it's impossible to tweak client TCP parameters when connection is unstable. UDP-incapsulated TCP allows to tweak them dynamically, server-side.

0-rtt is used if the client already established a tls connection before with the server, it's not insecure