DEV Community: Илья Федотов

# Receive buffers and flow control in Rust multiplexer

Илья Федотов — Sat, 26 Sep 2026 13:24:35 +0000

Take a 1 MiB receive window. A peer sends 256 KiB, leaving 768 KiB of credit. The receiver takes that buffer out of its queue and starts writing it to a socket. The socket stalls.

The queue is empty, but the buffer still occupies 256 KiB. Returning credit at that point would let replacement data arrive while the write was still pending.

BibaVPN keeps those bytes accounted for until write_all() completes. This is part of the TCP multiplexer in my experimental Rust tunnel, which carries several logical streams through a shared WebSocket connection.

Conceptual receive path. The independent pumps separate socket writes from shared record dispatch; all streams still share the outer TCP transport.

A mux record starts with a nine-byte header:

Offset       0                 4       5                 9
             +-----------------+-------+-----------------+---------+
             | stream_id       | flags | payload_length  | payload |
             | u32, big-endian | u8    | u32, big-endian |         |
             +-----------------+-------+-----------------+---------+

The decoder checks the declared payload length and rejects trailing bytes. Once decoded, the stream ID tells the receiver where to dispatch the record. The flags identify operations such as OPEN, DATA, CLOSE, RST, and WIN.

Writing directly to a destination socket from the shared reader would make every stream depend on that destination's speed. Instead, the implementation keeps per-stream receive state and separate pumps for the two directions. Its optional, negotiated byte-credit extension controls how much data can remain outstanding.

Here is the 256 KiB example through one complete receive cycle:

Worked example in negotiated credit mode. No other data arrives during this sequence; the empty queue triggers publication of the accumulated credit after the write.

The relevant operations in tcp_mux_flow.rs are ordered like this:

write.write_all(&data).await?;
let len = data.len();
drop(data);
flow.consumed(len);

The window-update logic follows those operations. It batches consumed bytes and publishes credit when the accumulated amount reaches one eighth of the receive limit, or when the queue is empty. While the socket write is pending, the buffer remains charged to the stream.

There is a second limit at session level. Each admitted stream reserves its local receive allowance against a 64 MiB logical receive budget:

Local receive window	Reservations that fit in 64 MiB
1 MiB	64
2 MiB	32
3 MiB	21
4 MiB	16

These are admission-budget calculations. Process memory also includes retained allocations, output queues, TLS state, tasks, and other overhead.

bytes::Bytes makes the allocation detail worth checking. A short slice can retain the allocation from which it was taken:

Backing allocation: 8 KiB
+-------------------------------------------------------------+
| header / padding | payload slice | unused capacity           |
+-------------------------------------------------------------+
                     ^^^^^^^^^^^^^
                     visible bytes

Keeping the slice can keep the entire allocation alive.

Counting only slice.len() can therefore understate memory retained by queued data. The receive implementation includes compaction and backing-allocation accounting alongside its logical byte limits.

Closing has a related lifetime problem. A client may finish sending its request while it still expects a response. In negotiated mode, CLOSE is directional: the other pump can continue. Legacy mode keeps its older behavior of closing both directions.

None of the per-stream accounting changes TCP's ordered delivery. Packet loss on one outer connection can still delay data for every logical stream carried by it. Separate receive queues address slow destination sockets inside the application; outer transport loss remains shared.

For code review, the useful places to start are Flow::enqueue, Flow::receive, Flow::consumed, and the downlink write loop. Together they show when a buffer enters the accounting, who owns it while a write is blocked, and when the peer gets permission to send more.

Source code, protocol documentation, and tests: BibaVPN on GitHub.

What 255 bytes of padding can and can’t do for an encrypted tunnel

Илья Федотов — Sat, 26 Sep 2026 12:28:28 +0000

BibaVPN, adaptive padding selects a target of roughly 900–1400 bytes for the first seven inner frames. Set max_pad to 64, send a 100-byte payload, and the resulting frame is 169 bytes. The target was 1,200; the padding budget ran out at 64.

Here is where those numbers come from.

BibaVPN is my experimental SOCKS5/HTTP CONNECT tunnel, written in Rust, with a TLS + WebSocket transport to a server on your own VPS. Its inner frame format reserves five bytes for the header:

Byte offset    0       1       2       3       4       5 ...
             +-------+-----------------------+-------+------------------+
             | ver   | payload length (u24)  | pad N | padding | payload|
             +-------+-----------------------+-------+------------------+
                 1 B           3 B              1 B     N B      L B

Total inner frame size = 5 + N + L

The padding length is a u8, so this layer can add at most 255 bytes. The configured max_pad can reduce that further.

Calculated example, before encryption and outer transport overhead. The upper bar shows the actual frame; the lower bar compares it with the selected target.

The three modes share that byte budget:

Mode	How it chooses padding
`random`	Uniform random amount from zero through `max_pad`.
`http-buckets`	Select a size bucket, vary its target by about ±5%, then clamp the required padding.
`adaptive`	Select larger targets for the first seven frames, then targets around 128–512 bytes; clamp the required padding.

The clamp in frame.rs is:

let need = target_total
    .saturating_sub(base)
    .min(usize::from(max_pad));

base includes the header. If the payload already exceeds the selected target, saturating_sub returns zero. There is no fragmentation or shrinking in this calculation.

For a fixed target of 1,200 bytes and max_pad = 64, the arithmetic looks like this:

Payload	With header	Padding added	Resulting inner frame
100 B	105 B	64 B	169 B
1,150 B	1,155 B	45 B	1,200 B
1,500 B	1,505 B	0 B	1,505 B

The names of the modes describe the size-selection heuristic. Whether the resulting traffic resembles HTTP requires a capture and a comparison. The inner frame still passes through encryption, WebSocket framing, TLS records, and TCP segmentation before it appears on the wire.

For the PSK data path, the boundaries look like this:

inner payload
     |
     v
padded inner frame       <-- sizes calculated above
     |
     v
PSK encryption wrapper
     |
     v
WebSocket / TLS / TCP    <-- network capture observes this traffic

A capture without TLS keys does not expose the WebSocket payload. It does expose traffic direction, timing, volume, and encrypted record lengths. Those are the properties the shaping settings aim to influence.

The timing controls have their own limits. In the current multiplexer writer, the artificial-delay branch excludes DATA and window updates:

if command.flags != MUX_FLAG_DATA && command.flags != MUX_FLAG_WIN {
    // Apply the configured timing controls here.
}

Delaying every DATA fragment would accumulate quickly. Five thousand serialized waits of 20 ms would add 100 seconds of waiting. That is an illustrative calculation; it is not a measured transfer time. Delaying window updates would also hold back a sender that is waiting for permission to transmit more bytes.

Dummy frames are another setting. They create traffic without application data, which consumes bandwidth even during otherwise quiet periods. Their cadence matters as much as their size: periodic dummy traffic can introduce a pattern of its own.

The code gives us the frame-size limits and the points where delays are applied. Establishing whether a setting helps against a particular classifier still requires network measurements. These examples explain the implementation; they do not establish a DPI-bypass result.

Source code and protocol documentation: BibaVPN on GitHub.

I built a self-hosted DPI-resistant tunnel over TLS + WebSocket in Rust

Илья Федотов — Sat, 20 Jun 2026 14:32:32 +0000

I built BibaVPN for one reason: I did not want to hand traffic to a third-party VPN provider.

It is a self-hosted SOCKS5 / HTTP CONNECT tunnel over TLS + WebSocket, with a Rust core and Android/Desktop clients.

Some users in Russia, Iran, and China use it to get around network blocks through their own VPS.

The project is small on purpose. It is not trying to be a full private network stack. It is meant for private, self-hosted access in restrictive environments.

GitHub: https://github.com/Eljaja/BibaVPN