Every other app protocol author wants to "reinvent" TCP at the application layer using UDP, cough mosh cough and 90% of game servers. Weird UDP ports are blocked, throttled and often lower priority and lower effort delivery than TCP streams (READ: packet loss and no guarantees). Instead, if they really want a reliable messaging layer, use a reliable messaging layer: nanomsg/nnm, 0mq, mqtt or similar. Then, build something solid on something already proven to scale.
Throwing away all of the problems solved by TCP improvements just invents old problems and new problems; let a messaging layer handle transport.
How does using 0mq helps me with sending the data that's updated every second and I only need the latest value?
As far as I remember, 0mq queueing policy will end up in the same situation as the TCP queueuing policy: there's no way to tell 0mq, or TCP, that "only the last sent packet matters, not the previous ones".
And the fact is that the reason to use UDP is primarily for those data streams where queuing doesn't make any sense whatsoever in the first place.
And more importantly - have you actually used nanomsg/nnm/0mq or similar yourself? All of these are variations on (re-)implementing TCP over UDP anyway. Or if you're using TCP channels - then reimplementing TCP queueing on top of OS-TCP queueuing.
QUIC is not some random application layer protocol. Google has been using it for quite some time and there's plenty of data that points to clear benefits over TCP. It is being worked upon at the IETF by people who actually have skin in the game. Please spend a little a bit of time and effort in trying to understand what problems QUIC is solving before dismissing it.
Especially when you can disable Nagle's algorithm, there often isn't a reason to use UDP. If you don't care about your data, I can see each argument for UDP, but if you do, you'll have to reimplement TCP anyway...
TCP per se doesn't allow for situations where if I know that packet A with an update U1 to a structure S hasn't yet reached the destination - then I would like to automatically discard A with U1 and send a packet B with update U2.
Essentially the issue with TCP is that it's based on queues, rather than having a callback that could simply poll the applicatio:n "hey - I couldn't yet send that data - do you have an update so that I could retry with the fresh one?"
