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.
I suspect it's due to my mobile operator doing traffic shaping / QoS that deprioritizes UDP VPN.
In contrast, connecting to OpenVPN over TCP was a huge improvement. Not at all what I expected.
I'd bet that switching your VPN server port to 443 would solve the problem, since HTTP/3 runs on 443/udp.
I think it’s specifically the resemblance to the clickbaity writing style that Twitter threads and LinkedIn and Facebook influencer posts are written in, presumably optimized for engagement/social media virality. I’m not totally sure what I want instead, I’m pretty sure I’ve seen the same tactics used in writing I admired, but probably much more sparingly?
What is it that makes tptacek’s writing or Cloudflare’s blog etc so much more readable by comparison? Is it just variety? Maybe these tactics should be reserved for intro paragraphs (of the article but also of individual sections/chapters might be fine too) to motivate you to read on, whereas the meat of the article (or section) should have more substance and less clickbaiting hooks?
This paragraph has both:
> The symptom is familiar: a stream that occasionally "locks up" briefly before catching up, jitter in audio or video, or a latency spike that appears to come from nowhere, a "hang" in the application when it gets blocked waiting for a packet. It comes from a single packet forcing the entire pipeline to pause. The underlying network recovered quickly; TCP's ordering guarantee is what made it visible.
So does this!
> WireGuard's protocol is a fundamentally different design point. It's stateless — there's no connection to establish upfront, no session to track, and no certificate authority in the picture. Two keys, a compact handshake, and you're encrypting. And unlike TLS, WireGuard's cryptographic choices are fixed: Noise_IKpsk2 for key exchange, ChaCha20-Poly1305 for authenticated encryption. There's nothing to misconfigure.
- "Why This Matters"
- "That's accurate, but it's only half the answer — and the less interesting half"
- "this isn't an edge case. It's routine."
I'm at the point, I would just rather read something somebody actually wrote even if it's not grammatically perfect and has lots of spelling mistakes.