Measure the local TCP forwarding path before optimizing the public tunnel path
eBPF SOCKMAP and SK_MSG redirection can reduce work in eligible Linux TCP forwarding paths, but they solve a narrower problem than public ingress. This guide builds a benchmarking method that separates application time, local reverse-proxy overhead, host TCP behavior, and Localtonet tunnel latency. We explain what SOCKMAP can redirect, what it cannot replace, how to construct comparable tests, and when a conventional reverse proxy remains the better engineering choice. The goal is not to assume that kernel socket redirection is faster, but to produce measurements that show whether local forwarding is important enough to optimize.
📋 What's in this guide
Start with the complete ingress data path
A public TCP request reaching a Linux application can cross several independently measurable stages. The remote test client first reaches a public endpoint. With Localtonet, our client application on the Linux device maintains an outbound connection to a Localtonet relay server, so the workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The relay path delivers traffic through that client to the configured local IP address and port.
What happens after traffic reaches the local target depends on the host architecture. The target might be the application itself, a user-space reverse proxy, a sidecar, or another local forwarding component. A proxy may accept one TCP connection, inspect or transform data, open another connection to the application, and copy bytes between those sockets. That local work is distinct from the internet path and the Localtonet relay path.
This distinction matters because an end-to-end benchmark reports the sum of several costs. It may include remote network delay, relay transit, Localtonet client processing, local proxy work, application scheduling, application processing, and the benchmark client itself. If the test reports only one end-to-end number, it cannot identify which stage changed.
The experiment therefore needs multiple boundaries. A direct local application test establishes the host-side floor for the chosen workload. A conventional proxy test measures the deployed user-space forwarding path. A SOCKMAP-enabled test measures the eligible accelerated path. Finally, a remote test through Localtonet measures the complete public workflow. These are related measurements, but they are not interchangeable.
A response measured from a remote client includes every stage between that client and the application. Record local baselines alongside the public result. Avoid simply subtracting two medians, because queueing, connection reuse, CPU contention, and internet conditions may differ between separate runs.
What SOCKMAP and SK_MSG actually optimize
SOCKMAP is an eBPF map type that stores references to sockets. SOCKHASH serves a related purpose with hash-based keys. A control-plane program identifies eligible sockets and places them in the selected map. An attached socket-layer eBPF program can then evaluate data associated with those sockets and, when its rules match, redirect messages to another socket.
An SK_MSG program runs on the message path for sockets participating in the map. Its logic can pass, drop, or redirect eligible data. Redirection happens at the socket layer, which can avoid parts of a conventional local forwarding journey. This makes it relevant when two compatible TCP endpoints are on the same Linux host and a forwarding design can safely associate the correct source and destination sockets.
SOCKMAP is not a public listener, tunnel relay, reverse-proxy configuration language, service discovery system, or complete connection manager. Something still has to accept connections, select an upstream, establish or identify the corresponding socket, update the map, remove stale entries, and handle errors. The data-plane program is only one part of a usable implementation.
| Path or component | Primary role | What the experiment establishes |
|---|---|---|
| Direct loopback TCP | Connect directly to the application on the same host | Provides a local baseline without the tested reverse-proxy hop |
| Conventional reverse proxy | Accept connections and forward data through user space | Shows the cost and behavior of the production-style proxy path |
| SOCKMAP with SK_MSG redirection | Redirect eligible messages between mapped sockets | Tests whether socket-layer redirection improves this exact local flow |
| Localtonet TCP tunnel | Provide public TCP reachability to a configured local IP and port | Measures the complete remote path when tested from an external client |
The scope is TCP. It should not be generalized to UDP, and SOCKMAP does not replace Localtonet TCP ingress. Our tunnel provides public reachability through an outbound client connection. SOCKMAP, when used successfully, optimizes an eligible local TCP forwarding path after traffic has reached the Linux host.
It also does not make application processing faster. If the service spends most of its time querying a database, waiting for another service, performing cryptographic work, or handling lock contention, reducing local forwarding overhead may produce little visible end-to-end change.
An SK_MSG pass verdict does not automatically guarantee that a custom accelerated architecture will behave like the original proxy. The control plane must define what happens when a socket is missing, a map update fails, a program cannot attach, or a redirect is rejected. Validate the fallback path explicitly rather than assuming that it is equivalent.
Prepare a controlled Linux benchmarking lab
Use a disposable or non-production Linux host for the first implementation. Loading eBPF programs, managing socket maps, and changing the forwarding path require privileges and can affect traffic handled by the tested processes. The exact privilege model depends on the kernel, system configuration, security policy, container runtime, and loader. Do not grant broad production privileges merely to make an experiment run.
Kernel support must be checked on the actual machine. A version string alone is not sufficient because distributions can enable, disable, or backport features. Confirm that the running kernel exposes the required BPF map type, program type, helpers, and attach mechanisms for the chosen implementation. Also verify that the selected loader and its object format are compatible with the host.
Basic inventory can begin with read-only inspection:
uname -r
bpftool version
bpftool feature probe kernelThe feature probe may require additional privilege to report complete results. Its output varies with the installed bpftool and kernel. Record the raw output with the benchmark artifacts instead of reducing compatibility to a single kernel-version assumption.
Required lab roles
A useful lab has an application server, a conventional local proxy or forwarding process, a SOCKMAP control plane and eBPF program, a local load generator, and a remote load generator. Keep the application and workload unchanged across test variants. If changing from the reverse proxy to the accelerated path also changes request parsing, buffering, connection pooling, or protocol behavior, the result no longer isolates socket redirection.
Choose a workload before measuring
Define the workload in a manifest that can be repeated. At minimum, record the request and response sizes, whether connections are reused, the number of concurrent connections, run duration, warm-up duration, application behavior, CPU placement, proxy configuration, kernel identity, eBPF object identity, and Localtonet target. Values should be selected for the application being studied rather than presented as universal defaults.
Use more than one workload shape. Small request and response exchanges can expose per-message latency and scheduling overhead. Sustained streams emphasize throughput and CPU efficiency. Connection-heavy tests measure setup and teardown behavior, which may not benefit in the same way as an established-socket data path. A realistic application transaction shows whether a low-level improvement survives application processing.
Loading and attaching the program depends on the specific source tree, loader, map layout, socket-discovery mechanism, kernel, and deployment model. This guide does not invent a generic loader command. Use a reviewed implementation whose documented commands match its code, and preserve the exact source revision and build instructions in the experiment record.
Build a reproducible baseline before enabling redirection
A benchmark should begin with correctness, not performance. The direct application, conventional proxy, and accelerated route must produce equivalent application-level results. Test both directions of a bidirectional exchange where the protocol requires them. Verify clean connection close, half-close behavior if the application uses it, timeout handling, and multiple simultaneous connections.
Freeze the environment and workload
Record the host, kernel, CPU policy, application build, proxy build, eBPF implementation revision, payloads, concurrency, connection behavior, warm-up period, and test duration. Stop unrelated scheduled work where operationally safe.
Measure direct local TCP
Point the local generator directly at the application listener. Verify response integrity and collect latency, throughput, CPU, context-switch, and error measurements. This is the local reference, not a promise of achievable tunneled performance.
Measure the conventional proxy path
Send the identical workload to the existing reverse proxy or forwarding process. Confirm that its upstream is the same application endpoint and preserve its normal security and protocol settings.
Enable and prove SOCKMAP redirection
Start the reviewed control plane, load the verified eBPF object, populate the required socket map, and attach the documented SK_MSG program. Confirm attachment and map membership using that implementation's supported inspection method. Collect redirect, pass, drop, miss, and error counters when available.
Repeat the same local workload
Run the same payloads, connection model, concurrency, warm-up, and duration. Repeat trials and interleave proxy and accelerated runs so thermal changes, background load, and cache state do not consistently favor one variant.
Force failure and validate fallback
Exercise documented failure conditions such as an absent map entry, control-plane restart, or rejected setup. Confirm whether traffic safely follows the conventional path, fails closed, or terminates according to the design. Record recovery time and any request loss.
Direct loopback is a reference rather than an automatic winner. The proxy may provide required behavior that direct access omits, including protocol validation, authentication, routing, logging, rate controls, or connection management. The accelerated path must be compared against the same required behavior, not against a stripped-down path that would be unacceptable in production.
Inspect TCP state during each test. The standard socket inspection utility can expose connection state and TCP details without changing the traffic path:
ss -tinCapture process-level CPU and system counters with tools already approved for the host. Use the same collection interval and scope for every variant. Observability itself has overhead, so do not profile one path heavily while leaving another uninstrumented.
Measure more than average requests per second
Throughput alone can conceal latency regressions, unfairness, or high CPU consumption. Average latency can conceal long-tail stalls. A credible result includes the distribution of completed operations, resource consumption, failures, and evidence that the intended forwarding path was active.
| Metric | Why it matters | How to interpret it |
|---|---|---|
| Median latency | Describes the typical completed operation | Useful for central tendency, but insufficient without tail percentiles |
| High-percentile latency | Reveals queueing, scheduling stalls, and occasional slow operations | Compare distributions across repeated trials rather than one isolated value |
| Throughput | Shows useful work completed per unit of time | Confirm that the generator and client machine are not the bottleneck |
| CPU time | Tests whether the path reduces host processing cost | Report system and user CPU by relevant process and, where possible, for the host |
| Context switches | Helps characterize scheduling and user-space forwarding activity | A change is supporting evidence, not proof by itself that redirection worked |
| Errors and resets | Protects against trading correctness for speed | Any improvement accompanied by corruption, drops, or connection failures is suspect |
| Redirect counters | Shows whether eligible traffic used the eBPF path | Correlate counter changes with completed requests and map membership |
| Fallback events | Shows how frequently acceleration was unavailable | Frequent misses may eliminate the practical value of the optimization |
Report raw values and uncertainty, not only percentage improvement. Use multiple trials and retain each trial separately. Randomize or alternate the order of variants. If the first run is consistently colder than later runs, define and document a warm-up phase rather than deleting inconvenient data after the fact.
Connection reuse deserves special attention. SK_MSG operates on data associated with established sockets participating in the map. A workload dominated by opening and closing connections can spend much of its time outside the steady-state redirected message path. Measure persistent connections and connection-heavy traffic separately rather than blending them into one result.
Payload size also changes what dominates. Tiny exchanges amplify fixed per-operation costs. Large streams may be limited by memory bandwidth, application copying, flow control, or the benchmark generator. Real request processing can dwarf both. A useful conclusion names the workload for which the improvement appeared instead of claiming that SOCKMAP makes all local ingress faster.
Add Localtonet as the public ingress stage
Add remote access only after the local variants are correct and repeatable. This keeps a tunnel result from concealing a broken or inconsistent host-side comparison. With Localtonet, the client runs on the device that can reach the selected local service. For this experiment, a TCP tunnel is the appropriate family because the tested target is raw TCP.
The Localtonet setup follows our standard tunnel lifecycle. Current authentication tokens and relay server choices must come from the dashboard. Do not copy a device token into benchmark logs, source repositories, command history, screenshots, or shared result files.
Install and run the Localtonet client
Run the Localtonet client on the Linux device that can reach the benchmark listener. The listener may be the direct application or the selected forwarding endpoint, depending on the test variant.
Authenticate or select the benchmark device
Use the device-specific authentication token through the supported product workflow. Treat the token as a secret and never place it in published benchmark material.
Select an available relay server
Choose from the relay servers or regions currently available in the Localtonet dashboard. Record the selection privately with the test metadata, but do not hardcode assumed server codes in reusable instructions.
Create the TCP tunnel configuration
Configure the tunnel to point to the local IP address and port of the variant under test. Use the same application workload and change only the local target when comparing direct, proxy, and accelerated paths.
Start the tunnel and test the assigned endpoint
Creating a tunnel does not mean it is running. Start it, then connect the remote generator to the assigned public host and port. The endpoint remains available only while the selected device is connected and the tunnel is running.
Stop or delete the tunnel after testing
Stop the tunnel when the benchmark window ends. Delete configurations that are no longer required so the lab does not retain unnecessary public exposure.
Place the remote generator on a different network from the Linux host. A same-host connection to the public endpoint does not represent a normal external path and may introduce routing behavior that is difficult to interpret. Keep the remote client location stable across comparisons, and run the public tests close together in time.
There are two especially useful Localtonet comparisons. First, target the application directly to obtain the end-to-end public result without the tested local proxy. Second, target the proxy or accelerated ingress listener. The difference between these distributions indicates whether the local forwarding layer remains visible within the complete remote experience.
The local test is best for detecting small host-side differences. The remote Localtonet test shows whether those differences matter in the complete public workflow. Internet variation may make a real microsecond-scale local improvement difficult to observe remotely, which is itself an operationally useful result.
Preserve application authentication and authorization, use least privilege, restrict the service where supported by the surrounding architecture, and avoid tunneling an administrative or unauthenticated listener merely for convenience. SOCKMAP does not add authentication, and a tunnel must not be treated as permission to bypass organizational network policy.
Interpret the results without overstating them
If the conventional proxy is materially slower locally and the accelerated path approaches the direct baseline while preserving correctness, CPU efficiency, policy, and fallback behavior, the host forwarding layer is a credible optimization target. The result still applies only to the tested kernel, implementation, traffic shape, and application architecture.
If the local difference is measurable but disappears through public ingress, the relay and wide-area network are not necessarily defective. The public path may simply contain more variability than the optimized host segment. In that case, SOCKMAP could still improve host capacity or CPU cost even if a remote user cannot detect a latency change. Evaluate both user-facing latency and infrastructure efficiency.
If direct, proxy, and accelerated local paths perform similarly, optimize elsewhere. Profile application processing, storage, upstream dependencies, lock contention, serialization, or connection management. Kernel complexity is difficult to justify when the target layer is not a meaningful contributor.
If the accelerated path wins only when important proxy features are disabled, the comparison is not production-equivalent. Reintroduce required controls and test again. Performance is not a valid substitute for authentication, protocol validation, routing correctness, auditability, or safe failure behavior.
When to retain a conventional reverse proxy
Keep the conventional proxy when it owns behavior the accelerated design does not reproduce safely. Examples can include application-aware routing, protocol normalization, authentication integration, detailed request logs, mature timeout handling, traffic shaping, upstream health management, or operational controls already understood by the team. Which features apply depends on the selected proxy and configuration, so inventory the deployed behavior rather than assuming it is a simple byte copier.
A hybrid architecture may also be appropriate. The conventional proxy can remain the control and policy point while an eligible established-socket data path is accelerated. That design is valuable only if it is supported by the specific implementation and if misses and failures return to a well-tested safe path.
Account for security and observability boundaries
Moving data at a different kernel hook changes what existing monitoring tools can see. Packet captures on a physical interface are not a complete observation point for local socket redirection. Even loopback packet observations may not represent data that follows the accelerated path. Build observability at the layer where decisions are made, including map state, attach state, redirect verdicts, misses, drops, control-plane events, socket lifecycle, and application-level success.
eBPF verifier acceptance is an important safety mechanism, but it is not proof that a program implements the intended policy. Review map keys, socket association, cleanup, concurrency, namespace assumptions, and failure handling. A logically incorrect program can pass verification while redirecting traffic to the wrong eligible socket.
Treat the loader and control plane as privileged components. Limit who can replace the eBPF object, change map entries, or alter attachment state. Preserve object identity and configuration in the benchmark record without publishing credentials or sensitive endpoint details. If containers are involved, document the relevant network and process namespaces because visibility and socket ownership can differ from the host view.
Public access remains a separate boundary. Localtonet supplies reachability to the configured local TCP target, but the application remains responsible for its protocol-level access controls. Stop the tunnel when the test is complete, and do not leave diagnostic services exposed.
| Risk | Failure mode | Recommended validation |
|---|---|---|
| Incorrect socket association | Messages reach the wrong connection or tenant | Test concurrent distinct payloads and verify end-to-end identity |
| Silent acceleration miss | Traffic works but never uses the intended path | Correlate map state and redirect counters with each run |
| Unsafe fallback | Control-plane failure causes drops or bypasses policy | Inject documented failures and verify explicit behavior |
| Reduced packet visibility | Existing packet-based monitoring misses redirected data | Add socket-layer and application-level telemetry |
| Unnecessary public exposure | A diagnostic or unauthenticated service becomes reachable | Target only the intended listener and stop the tunnel after use |
Troubleshoot incorrect or inconclusive results
The eBPF program will not load
Preserve the complete verifier output. Check actual kernel capabilities with the installed tooling, confirm that the object was built for the intended architecture and loader, and verify that the required map and program types are available. Do not respond by granting unrestricted privileges without understanding which capability or policy blocked the operation.
Traffic works, but performance does not change
First prove that redirection happened. Check attachment state, map membership, and implementation-specific counters. Then determine whether the workload is dominated by connection setup, application work, payload copying elsewhere, or client saturation. A working request can still be following the conventional path.
Local results vary between runs
Look for CPU frequency changes, thermal throttling, background jobs, interrupt placement, competing containers, memory pressure, and inconsistent warm-up. Interleave variants instead of running every baseline first and every accelerated trial later. Report the distribution across runs rather than selecting the best result.
Remote results are noisy
Keep the remote generator and selected Localtonet relay consistent, shorten the time between paired trials, and increase the number of repeated observations without overwhelming the service. Compare local measurements collected during the same window. Do not infer host forwarding cost from a single remote round trip.
The direct target works, but the Localtonet endpoint does not
Confirm that the Localtonet client device is connected, the TCP tunnel is started, and the configured local IP address and port are reachable from that client device. Remember that creating a tunnel is not the same as starting it. Also verify that the application is listening on the intended address and that its own access policy accepts the connection.
Fallback causes resets or mixed responses
Stop performance testing and resolve correctness first. Review how socket pairs are created, inserted, removed, and replaced. Test control-plane restart, connection close, stale map entries, and concurrent connections. A fast path that cannot preserve connection identity and error behavior is not ready for public ingress.
Frequently asked questions
Does SOCKMAP replace a Localtonet TCP tunnel?
No. With Localtonet, our client establishes an outbound connection to a relay and provides a public host and port for the configured local TCP service. SOCKMAP operates on eligible sockets inside the Linux host. It does not provide public ingress, a relay endpoint, or internet reachability by itself.
Can SK_MSG redirection accelerate UDP traffic?
This workflow is specifically about compatible TCP sockets and must not be generalized to UDP. Localtonet supports separate TCP, UDP, and combined UDP/TCP tunnel families, but a SOCKMAP TCP experiment does not establish a UDP optimization result.
Will SOCKMAP automatically make an application faster?
No. It can optimize an eligible local socket-forwarding path. It does not accelerate application logic, database queries, storage, remote dependencies, or unrelated network segments. Measure the direct application, conventional proxy, accelerated route, and complete public path before drawing a conclusion.
Is direct loopback TCP the correct production target?
Not necessarily. Direct loopback is a useful performance reference, but it may omit routing, authentication, validation, logging, timeout handling, and other required proxy behavior. A production comparison must retain the controls the service actually needs.
Why might a strong local improvement disappear in the remote benchmark?
The remote measurement includes internet transit, relay transit, client processing, host forwarding, and application time. Variation in the wider path can be larger than the optimized local component. The optimization may still reduce host CPU or increase capacity even when remote latency does not change detectably.
How do I prove that traffic used the accelerated path?
Verify that the intended program is attached, the expected sockets are present in the map, and redirect counters increase during the run. Correlate those signals with application-level request completion. Successful traffic alone is not proof because a conventional or fallback path may also work.
Does an SK_MSG pass result guarantee safe fallback?
No. Safe fallback depends on the complete architecture, including socket state, control-plane behavior, proxy topology, and policy enforcement. Test missing entries, loader failure, control-plane restart, stale sockets, and connection closure to establish what the system actually does.
Should the Localtonet tunnel target the application or the proxy?
Test both when the security architecture permits it. Targeting the application provides an end-to-end reference without the evaluated proxy hop. Targeting the proxy or accelerated listener measures the intended deployment path. Do not expose a direct application listener if doing so would remove required authentication or policy controls.
Measure your Linux ingress path with Localtonet
Establish the direct, proxy, and SOCKMAP baselines locally, then use a Localtonet TCP tunnel to test the same service from an external network without configuring inbound router port forwarding. Keep the tunnel active only for the required test window and preserve application-level access controls.
Get Started Free →
