[josh3736]

This is a clever reuse of WireGuard's cryptographic design, and may indeed make sense as a way to slap some low-overhead encryption on top of your app's existing UDP packets.

However, it's definitely not a replacement for TCP in the way the article implies. WireGuard-the-VPN works because the TCP inside of it handles retransmission and flow control. Going raw WireGuard means that's now entirely up to you.

So this might be a good choice if you're doing something realtime where a small number of dropped packets don't particularly matter (such as the sensor updates the article illustrates).

But if you still need all your packets in order, this is probably a bad idea. Instead, I'd consider using QUIC (HTTP/3's UDP protocol), which brings many of the benefits here (including migration of connections across source IP address and no head-of-line-blocking between streams multiplexed inside the connection) without sacrificing TCP's reliability guarantees. And as the protocol powering 75% of web browsing¹, is a pretty safe choice of transport.

¹ https://blog.apnic.net/2025/06/17/a-quic-progress-report/

[mlhpdx]

> However, it's definitely not a replacement for TCP in the way the article implies.

UDP isn’t TCP and that’s kind of the point. For a large number of use cases the pain TLS imparts isn’t worth it.

QUIC is flexible and fabulous, but heavyweight and not fit for light hardware. it also begs the question “If the browser supported raw UDP what percent of traffic would use it?”

[josh3736]

Sure, but this article spends paragraphs talking about the (real) problems with TCP, then suggests that the solution is a UDP-based transport with WireGuard-ish crypto.

…but there's a giant guaranteed-and-ordered-delivery-sized hole in that argument, which is my point. The article never addresses what you lose when going from TCP to UDP. You can't just swap out your app's TCP-based comms with this and call it a day; you're now entirely responsible for dealing with packet loss, order, and congestion if that's important to your application. Why DIY all that if you could just use QUIC?

Granted I haven't personally tried to run QUIC on embedded hardware, so I can't speak to its weight, but I do see someone did it¹ on an ESP32 (ngtcp2 + wolfSSL), so it can be done with < 300 kB of RAM.

I wonder how much RAM this WireGuard-based approach requires. The implementation here is in .NET, so not exactly appropriate for light hardware either.

Regarding browser support for UDP, you'll never get raw UDP for obvious reasons, but the WebTransport API² gives you lowish-level access to UDP-style (unreliable and unordered) datagrams with server connections, and I believe WebRTC can give you those semantics with peers.

¹ https://www.emqx.com/en/blog/can-esp32-run-mqtt-over-quic

² https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor...