mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 18:18:55 +00:00
19d954c76c
In order to implement GSO in `connlib`, we opted for an approach where packets of the same length are being appended to a buffer. Each of these buffers is the sent to the kernel in a single syscall, which drastically decreases the per-packet overhead of syscalls and therefore improves performance. Within `connlib` itself, we prioritise control-protocol associated packets over tunnel traffic. The idea here is that even under high-load, we want to ensure that STUN probes between the peers and to the relays are sent in a timely manner. Failing to send these probes results in a false-positive detection of a lost connection because the `connlib`'s internal state uses timeouts to detect such situations. Despite processing the packets itself in a timely manner, it is still possible that they get delayed depending on which order the get flushed to the socket. This order is currently non-deterministic because `GsoQueue` uses a `HashMap` internally and when accessing the batched-together datagrams, we just access it via `iter_mut`. To fix this, we use a `BTreeMap` instead and explicitly define the `Key` to start with the `segment_size` field. As a result, entries within the `BTreeMap` will be sorted ascending by `segment_size` (i.e. the size of individual packets within the batch). Packets of smaller size are more likely to be control messages like STUN binding requests or TURN messages to the relays for managing allocations. By sorting the map explicitly, we ensure that if the UDP socket is ready to send, we flush out these messages first before moving on to bigger packets such as the ones containing (more likely) WireGuard data messages.
Rust development guide
Firezone uses Rust for all data plane components. This directory contains the Linux and Windows clients, and low-level networking implementations related to STUN/TURN.
We target the last stable release of Rust using rust-toolchain.toml.
If you are using rustup, that is automatically handled for you.
Otherwise, ensure you have the latest stable version of Rust installed.
Reading Client logs
The Client logs are written as JSONL for machine-readability.
To make them more human-friendly, pipe them through jq like this:
cd path/to/logs # e.g. `$HOME/.cache/dev.firezone.client/data/logs` on Linux
cat *.log | jq -r '"\(.time) \(.severity) \(.message)"'
Resulting in, e.g.
2024-04-01T18:25:47.237661392Z INFO started log
2024-04-01T18:25:47.238193266Z INFO GIT_VERSION = 1.0.0-pre.11-35-gcc0d43531
2024-04-01T18:25:48.295243016Z INFO No token / actor_name on disk, starting in signed-out state
2024-04-01T18:25:48.295360641Z INFO null
Benchmarking on Linux
The recommended way for benchmarking any of the Rust components is Linux' perf utility.
For example, to attach to a running application, do:
- Ensure the binary you are profiling is compiled with the
releaseprofile. sudo perf record -g --freq 10000 --pid $(pgrep <your-binary>).- Run the speed test or whatever load-inducing task you want to measure.
sudo perf script > profile.perf- Open profiler.firefox.com and load
profile.perf
Instead of attaching to a process with --pid, you can also specify the path to executable directly.
That is useful if you want to capture perf data for a test or a micro-benchmark.