UDPspeeder: FEC Tunneling for Lossy High-Latency Links

What UDPspeeder Solves and Who It Is For

UDPspeeder addresses a specific network pain: high-latency links with packet loss, such as satellite connections, congested Wi-Fi, or long-distance intercontinental routes. On such links, TCP throughput collapses because every lost packet triggers retransmission and window reduction. UDP applications suffer from missing datagrams. UDPspeeder applies forward error correction (FEC) to reconstruct lost packets at the receiving end, without waiting for retransmission. The project targets Linux users who control both endpoints: desktop Linux, Android devices, OpenWRT routers, and Raspberry Pi. For Windows and macOS, the README points to a virtual machine image, which is a heavier path. The core audience is network engineers and self-hosters who run their own servers and want to improve connection quality on a known-bad link. It is not a general-purpose VPN; it is a tunnel that boosts whatever UDP traffic you push through it.

The Mechanism: Reed-Solomon FEC in a UDP Tunnel

The core mechanism is Reed-Solomon coding, a well-known erasure code. The README explains that by adding t check symbols to data, a Reed-Solomon code can correct up to t known erasures. UDPspeeder applies this at the packet level: it takes a group of original packets, computes redundant packets, and sends both. The receiving side uses the redundant packets to reconstruct any lost originals. The -f parameter controls the ratio, for example -f20:10 sends 10 redundant packets for every 20 original packets. This is a direct trade-off: you spend extra bandwidth to reduce loss. The README claims that with well-tuned parameters, you can reduce IP or UDP/ICMP packet loss to less than 0.01%, and improve TCP latency and single-thread download speed. The key is that FEC works without round trips, which is why it helps on high-latency links where retransmission is expensive. The tunnel itself is a simple UDP proxy: the client listens on a local port, forwards to the server, and the server forwards to the target service. The FEC happens in between.

Running It: Commands and Configuration

Getting UDPspeeder running is straightforward from the README. You download a binary release from GitHub. Then you run two processes, one on the server and one on the client. The server command is: ./speederv2 -s -l0.0.0.0:4096 -r 127.0.0.1:7777 -f20:10 -k "passwd". The client command is: ./speederv2 -c -l0.0.0.0:3333 -r44.55.66.77:4096 -f20:10 -k "passwd". This makes the client's UDP port 3333 equivalent to the server's port 7777, with FEC applied. The -f20:10 option is the FEC ratio. The -k option enables simple XOR encryption, which is not strong encryption but adds a basic obfuscation. There is also a --fifo option that lets you send commands to a running instance through a named pipe. For example, you can echo fec 19:9 > fifo.file to change the FEC ratio dynamically, or echo mtu 1100, echo timeout 5, echo queue-len 100, and echo mode 0. This dynamic tuning is useful because the optimal ratio depends on the actual loss rate, which can change over time. The README notes that common options like -k must be the same on both sides.

Improving All Traffic: The OpenVPN Combination

UDPspeeder alone only improves UDP traffic. The README is explicit: if you want to improve TCP and ICMP as well, you need to combine it with a UDP-based VPN. The recommended setup is UDPspeeder plus OpenVPN, L2TP, or ShadowVPN. The idea is that you establish a VPN connection over UDP, and that UDP stream goes through the UDPspeeder tunnel. The FEC then protects the VPN's UDP packets, which in turn carry your TCP or ICMP traffic. The README links to a configuration guide in the wiki for OpenVPN. This is a significant architectural point: UDPspeeder is not a full solution for all traffic by itself. It requires an additional layer. The benefit is that you get FEC protection for all protocols without modifying the TCP stack. The cost is complexity: you now run VPN software and the tunnel, and you have to tune both. The README also mentions using udp2raw together with UDPspeeder to counter UDP throttling by ISPs, which adds another layer of complexity.

Limitations and Failure Modes

The most obvious limitation is bandwidth overhead. FEC sends redundant packets, so you consume more bandwidth than the original stream. The -f20:10 ratio means 50% overhead. If your link is bandwidth-constrained, this is a direct cost. The README does not quantify the trade-off beyond saying it is 'at the cost of additional bandwidth.' Another limitation is that the FEC ratio is static unless you use the fifo interface. If the loss rate changes, you must manually adjust. There is no adaptive algorithm. Also, the README does not describe how UDPspeeder handles packet reordering or jitter, which can be as damaging as loss on some links. The project has not had a release since February 2023, so it may not be actively maintained. The build date in the usage output shows 2018, which suggests the code is stable but not evolving. For Windows and macOS users, the virtual machine image is a heavy requirement; it is not a native solution. Finally, the simple XOR encryption is not a security feature; do not rely on it for confidentiality.

Alternatives: tinyfecVPN and udp2raw

The README itself points to two related projects. tinyfecVPN is a lightweight high-performance VPN with UDPspeeder's FEC function built in. That means you get the FEC benefit and a VPN in one process, which removes the need to run two separate layers. If your goal is to protect all traffic, tinyfecVPN might be simpler. The trade-off is that tinyfecVPN is a VPN, so it has its own configuration and possibly more overhead. udp2raw is a different tool: it tunnels UDP traffic over a fake TCP connection to bypass UDP throttling by ISPs. It does not provide FEC. The README suggests using udp2raw together with UDPspeeder, which means you can combine both: FEC for loss and TCP-like encapsulation for QoS. That is a more complex setup but addresses two different problems. The choice depends on whether your primary issue is loss or UDP throttling. If it is loss, UDPspeeder alone or tinyfecVPN is enough. If it is throttling, udp2raw is the relevant tool.

Maintenance, License, and Upgrade Cost

UDPspeeder is licensed under the MIT License, which is permissive and allows commercial use, modification, and redistribution with attribution. There is no copyleft obligation. The project's last release was 20230206.0, pushed on February 7, 2023. The default branch is branch_libev, which indicates it uses the libev event loop library. The maintenance cost is low if you use the prebuilt binaries, but you need to ensure compatibility with your system's libev and kernel. The README does not provide build instructions, only binary download links. If you need to compile from source, you will have to figure out dependencies yourself. The upgrade path is straightforward: download a new binary and replace the old one. The configuration options are command-line based, so upgrading does not require config file changes. However, the lack of recent releases suggests the project may be in maintenance mode. There is no mention of automated updates or a package manager integration, so you must manually track releases. For a production deployment, you should test the binary on your specific Linux distribution before relying on it.

Editorial conclusion

Adopt UDPspeeder if you control both ends of a lossy, high-latency link, need to improve UDP or can wrap it with a UDP-based VPN for TCP/ICMP, and you have the bandwidth budget for redundancy. Do not use it if your link is not lossy, if you cannot afford extra bandwidth, or if you expect a zero-configuration solution. Before deploying, verify your exact packet loss rate, test different -f ratios like 20:10, and check the wiki for OpenVPN integration details. The project's last release is from 2023, so confirm it still builds on your kernel and libev version.

Official sources

1. Official README
2. Project repository
3. Release notes