> Please, if you can't use SSL+TCP for text chat and keep it real time
They could have, but QUIC is "better" for their use cases. In many ways, it's like an improved version of TCP. It runs on top of UDP simply
because routers, firewalls, etc. often only speak TCP and UDP. From the FAQ:
> it is unlikely to see significant adoption of client-side TCP changes in less than 5-15 years. QUIC allows us to test and experiment with new ideas,
> and to get results sooner. We are hopeful that QUIC features will migrate into TCP and TLS if they prove effective.
> You can outright lose data. Your packets can arrive out of order. It's okay with video data where a hiccup only makes a few missing pixels,
> but with text, that's a terrible idea.
Unless of course the protocol you're running over UDP handles that stuff, just like TCP handles that stuff.
Normally, it's a bad idea to use UDP to run a protocol that has in-order packets, guaranteed delivery, etc. because TCP already gives you that.
Why re-invent TCP? Unless you're going to spend a few million dollars on R&D to make your UDP-based protocol actually be better than TCP,
you should just use TCP.
That "unless you're going to spend a few million dollars on R&D" is the key here. Google DID make the investment, so the protocol actually does
work better for the particular use than TCP does.