10 ms·
Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency
- thecodrr 7y agoWOW. This is such a fascinating project. (near) zero latencies are relatively hard to achieve especially over network connections. Will definitely try this out once I get the time. Oh and thanks for the various pre-built client libraries, will definitely come in useful.
- vvanders 7y agoUsing the term "zero" is not the best choice. UDP packets have the same latency as TCP packets, you're just saving the handshake. Games and VoIP still have latency, they're usually structured such the data loss and duplicate responses are normal and handled appropriately.
- huhtenberg 7y agoGood stuff. Could use some asserts and checks for NULL here and there, but overall it's a nicely organized C code (and with proper bracing and indentation style :)). Always a pleasure to read through something like this.
- edoo 7y agoActually it has the wrong indentation style. Should be tabs left spaces right. I run tab width of 3 in my editors. To each their own, if you use tabs left of course.
- saagarjha 7y ago> I run tab width of 3 in my editors. That’s certainly a strange choice, but you do you I guess…
- jhare 7y agoWell then you're also "wrong" for 3 spaces. Student project, and spaces/tabs argument is for teenagers. edit: root comment here is mentioning NULL checks and actually being helpful
- deleted 7y ago[deleted]
- fitzn 7y agoI read the README. It certainly makes some trade-offs! :) Sounds like it was a fun exercise.
- nickphx 7y agoImpressive work, thanks for sharing.
- jaimex2 7y agoFinding a use case for this would be tricky... 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.
- vvanders 7y agoYou can already do this with WebRTC, you just need and implementation that won't fall back to TCP if the UDP negotiation fails.
- penagwin 7y agoWait webrtc uses udp? Is this new? I thought there was no way to send udp packets through client side Javascript?
- vvanders 7y agoYup, it's been a while since I read the spec but I believe it leaves the transport up to what can be negotiated for maximum compatibility. If you handle the SDP and SCTP handshake you can force it to only use UDP via SCTP. Chrome and FF both support it today.
- mr_luc 7y agoYeah with WebRTC data channels can be UDP! It's just -- and this may be mildly out of date -- EXTREMELY hard to find a server-side setup that will let you do all of what the browsers now support with WebRTC. My recollection from the last time I skipped across this topic was: there are 1 or 2 heavyweight open source projects that mostly focus on the video aspects but also supported data channel stuff, and then one lightweight C and one lightweight Go project that supported everything, and you were mostly out of luck otherwise. I remember the last time I checked, a year ago or so, pieces of what's required being worked on in recent OTP releases in BEAM-land. Hmmm ... time to check again.
- fulafel 7y agoThere is no raw udp or tcp access from browser js, just higher lwvel protocols that are implemented over tcp or udp.
- sneak 7y agoI am reminded of statsd. I like this, though, as it generalizes more. Cool hack! 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.
- flyGuyOnTheSly 7y agoIs this only possible if the server you are communicating with is setup to work with ff-proxy in the first place, I imagine? I can't just start using this and get no handshake confirmations from any website's rest api can I?
- loeg 7y agoThe server doesn't need anything special. You could indeed just start using this and fire-and-forget REST API requests.
- bweitzman 7y agoWhat would be the use case of this versus say making an HTTP request over TCP in a background thread?
- aeyes 7y agoWell obviously you don't need to maintain a background thread and a connection so you would be able to send out much more data using the same resources by offloading the TCP workload to the proxy. 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.
- Matthias247 7y agoUntil you get some decent amount of load on the system. Then the background thread will still make progress. And the UDP/Proxy approach will only have failing requests, because the loss of any single UDP packet will make the request fail (there are no retries). 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.
- ElijahLynn 7y ago"Zero Latency"?
- fourmyle 7y agoDidn't even read it after seeing that in the headline
- deleted 7y ago[deleted]
- dspillett 7y ago"I didn't bother to listen, but I think it is wrong so there" is never really a useful discussion position. The linked page describes a fairly specific set of needs that the claim is effectively true for, though only from the client's point of view.
- ycombobreaker 7y agoAnything (hardware or software) in the network stack advertising "zero latency" is a lie. The idea or implementation may have merit, but it is best to avoid opening with a trivial impossibility.
- why_only_15 7y agoi don't think most people read "zero latency" and think literally 0 ns of latency, because, as you said, it is trivially impossible. If you read any length of documentation you will see how the latency is orders of magnitude less than sending it out directly. That's close enough to zero latency for me.
- dspillett 7y agoYes. Like the random access latency of NVMe SSDs, It isn't zero, but it is practically zero compared to more "traditional" storage tech.
- zekrioca 7y agoThe second figure could have shown the client receiving the HTTP response to its request. Also, isn't HTTP/3 (QUIC) already supporting something like this?
- jkarneges 7y agoNeat! FF Proxy reminds me of one of my projects ( https://github.com/fanout/zurl https://github.com/fanout/zurl ), but more extreme since the sender uses raw UDP. It seems like it would be great for remote use by lightweight senders. Maybe low power devices emitting stats? 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. :)
- deleted 7y ago[deleted]
- pankake 7y agoI dont know why more web servers are not using UDP by default and only go TCP when the client or content needs it. For example, sites like youtube - the videos must be streamed to us, why not the site itself? Only when I want the client to definitley know it sent data (a banking transaction, an amazon order) but for the vast majority of sites UDP bi-di should be fine. Can you imagine the amount of bandwidth saved around the world in aggregate? TCP should be restricted based on content classification.
- rlpb 7y agoUDP does not have congestion or flow control.
- deleted 7y ago[deleted]
- czbond 7y agoThis is very cool. I had to write something in the near realm a few year ago, and love your implementation.
- cosmotic 7y agoThis doesn't just magically remove the latency. * 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.
- kstenerud 7y agoIt's about SENDING requests with "zero latency", not about completing http operations with zero 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.
- geocar 7y ago> 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.
- ComodoHacker 7y ago>a use case for this Logging/analytics?
- 29athrowaway 7y agoUDP doesn't implement: - 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.
- W4ldi 7y agoI think the author is aware of that. I think it's more an easy way to 'udp-fy' existing tcp services and only update the client to use udp
- bullen 7y agoI'm going to sacrifice my karma for this: the solution is not to make TCP use UDP, but instead to allow TCP to behave like UDP by giving it the option to ignore out-of-order. All operatives have flawed implementaions of this, but we need it to be in the TCP RFC.
- mbreese 7y agoWouldn’t out of order TCP require whole new client libraries as well. All the TCP client code expects well ordered packets. So if you’re doing that, might as well go all the way to a new protocol. Which isn’t this then QUIC? I’m not familiar enough with either to know what the practical differences would be between QUIC and out of order TCP.
- eps 7y agoGiven MTU fragmentation this is not a very bright idea. It will basically require another framing protocol on top of TCP to make it even remotely usable.
- easytiger 7y ago> zero latency > Docker
- eeZah7Ux 7y agomeh
- leoedin 7y agoI wonder if the author wrote this with something in mind? 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.
- jeroenhd 7y agoFor that stuff protocols such as CoAP might be more useful as it's a standard with pretty much the same benefits but less custom code. 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.
- stevemadere 7y agoThis would be a great DOS attack tool!