* I presume the case here is the proxy is close to the server so the handshake is faster and thus the single benefit of this setup, although that's not at all what's illustrated.
* The illustrations show the request taking longer with the proxy, although maybe the two diagrams aren't to scale
* The originating UDP packet could get lost and the client would never know
The author could improve the latency by prepping the TCP connection before the request comes in, giving a significant reduction in latency.
And yes, you get no confirmation, and no reply.
I must admit I'm hard pressed to come up with a use case for this. You could just as easily do a regular HTTP request on a separate thread and throw away the result to get "zero latency" fire-and-forget behavior.
I do this quite often, and creating another thread might be easy to code, but it's harder on capacity planning and management. It's also hard to gossip utilisation of a shared network link across a cluster, so e.g. if requests are infrequently sourced, I may want to permit a pool of 500k concurrent output HTTP requests across the entire cluster, but I don't want to give every machine a mere 10k outgoing since busy endpoints would be starved by unbusy ones (and my network link would have plenty of spare capacity). Managing all that could be a full time job if I went down the "easy" path of just creating another thread.
Using UDP means if there is network congestion, messages just get dropped and I don't waste more network and CPU traffic by sending retransmits. I have retries further up the chain anyway for other reasons, so it makes sense to me to have less code and reuse what I've already got.
Quic already does this end to end.
The only use case I can think of might be gaming. If you had a HTTP/Websockets based game you wanted to cut latency down on you could have the FF proxy hosted near the game server.
I can tell you a real life use case that already exists because I built this exact thing already (though a closed-source version): satellite internet terminals.
With satellite internet, uplink (upload) is generally more complicated than downlink (download). This is because a terminal can just passively listen for packets intended for him, but with uplink you have to make sure you only transmit in your designated time slot.
Because uplink is more complicated than downlink, more often than not uplink will get in a degraded or broken state, while downlink is still operational.
Now say I get a call from a customer service rep saying a customer's terminal is stuck in a degraded state. How can I recover it? TCP (and therefore HTTP) is a no-go because it requires uplink to be fully functional. So I can't visit the terminal's embedded webserver or issue commands to the HTTP API.
However, using a udp to tcp proxy like this, I can issue commands to the terminal's HTTP API "blindly" which it will then execute to (hopefully) recover itself. This can also be done with other "one-way" protocols like SNMP.
I don't mean to sound smug, but I'm the author of the Jackbox Games multiplayer servers, I regularly handle hundreds of thousands of simultaneous websocket connections from players' phones. I can't for the life of me find a server implementation of webrtc data channels that I would actually put into production. I've seen a few blog posts with toy examples, but nothing that is ready for production. It sounds nice in theory, but try actually finding a production-ready server implementation of WebRTC data channels. I would LOVE to find a documented example of doing client-server communication with WebRTC data channels (a Go implementation on the server specifically). I've found no such thing. Every few months I search and don't find such a thing, and I don't need the extra few ms of latency improvement badly enough that it would be worth the engineering time to author it myself. If you know of one that's actually ready for primetime, I'd love to hear about it.
edit: after writing this comment, I did some snooping around since I haven't snooped around on this topic in a few months, this looks promising, unclear how widely used people are using it for production work: https://github.com/pion/webrtc
If the service you are sending data to is unavailable, you wouldn't get any backpressure from it.
Think of a monitoring or log system where you might want to send out millions of datapoints but you can afford to lose some, in return you don't have to worry about the system not being reachable.
I can only see being interesting if you have a workload which requires sending small requests that fit into one or a couple of datagrams.
Fire and forget logging to HTTP endpoints would be pretty useful for IoT sensors. You'd have a lot less code and could potentially save significant power. You obviously lose the ability to guarantee data arrived, but that's probably not important for all sensor situations.
It's even possible to translate CoAP directly into HTTP using a proxy such as Squid.
There's also MQTT, which was basically designed for IoT sensor reporting. This has even more supported libraries and has been around for ages.
The UDP proxy system has the benefit of not being able to fall victim to classic UDP amplification vulnerabilities (send a packet with a spoofed source and have the response bounce back), but it does allow an unsuspecting proxy server to turn into a HTTP-based DDoS. You can send a single packet towards a server and the server automatically does a full TCP handshake and payload delivery for you! That's a lot of extra traffic.
I'd stick with known protocols for IoT stuff instead of this. At least the risks have been analysed and firewalls can (should) be easily configurable to block outgoing DDoS attacks in the worst case. The same is not really true for this.
It will basically require another framing protocol on top of TCP to make it even remotely usable.
edit: root comment here is mentioning NULL checks and actually being helpful
That’s certainly a strange choice, but you do you I guess…
P.S. good to see the comment, "TODO: filter out private IP ranges". I was going to suggest this but it seems you already know. :)
* for sufficiently large values of zero
They've basically discovered TCP Performance Enhancing Proxies, used for decades for space communications.
The claim seems correct with those caveats, though is a bit "click baity" without them.
I wonder if it would be worth making this embeddable into an existing web framework for Python or Go, so that the existing service could receive UDP requests. Then again, that's what 0RTT is for so it might be a little wheel-reinventy.
Games and VoIP still have latency, they're usually structured such the data loss and duplicate responses are normal and handled appropriately.
I can't just start using this and get no handshake confirmations from any website's rest api can I?
> Docker
- Reliable delivery
- Ordering
- Congestion control
- Flow control
...and a large list of RFCs that I'll never ever read.
If you are delivering a document (like a webpage or an API response), or transferring files, you want these things.
If you are doing real-time stuff, like video, voice, real-time games... and you just need the most recent information, that's where UDP shines.
Can you imagine the amount of bandwidth saved around the world in aggregate?
TCP should be restricted based on content classification.
