P2P Network Tester

Why test peer-to-peer?

Most latency tools measure the path from your browser to a server (usually a low-latency datacenter with a direct backbone connection). Peer-to-peer tests are different: traffic travels through your router, your ISP, the remote ISP, and the other person's router. Dropped packets on that path are caused by congestion at your ISP, overloaded home networks, and NAT hairpin delays that no synthetic test can replicate.

What server-based pings miss

This tool is useful for diagnosing lag in video calls, gaming sessions, and remote desktop connections where traffic flows directly between participants. A server-based ping can look clean while the actual P2P path adds enough packet loss or variable delay to make a call, game, or remote session feel unstable.¹ Because the probe traffic follows the same route your real applications take, you see the congestion and jitter that actually affect your sessions rather than the favourable path to a nearby datacenter.

A bandwidth test answers a different question than this tool does. A speed test measures how much data a well-connected server can push to you in a burst: its download and upload numbers describe throughput, and its ping is a bonus measurement to the test server itself. Between two specific peers, this tool measures the stability of the path instead: delay, variation in that delay, and loss along the route your actual sessions take. Neither number predicts the other, which is why a gigabit connection can still host a stuttering call. When your speed test looks great but your calls feel bad, the peer-to-peer path is the thing left to measure, and that is exactly what this probe exercises.

WebRTC and STUN

WebRTC is the browser API behind video calls, screen sharing, and arbitrary data exchange between peers.² Under the hood, it uses ICE (Interactive Connectivity Establishment) to discover how two peers can reach each other, with STUN used for connectivity checks and mapped-address discovery.³ STUN servers are contacted briefly to discover your public IP and check whether your NAT allows incoming connections; no probe data passes through them.

How the STUN probe classifies your NAT

The STUN probe on page load reports likely NAT behavior rather than a permanent router label. Endpoint-independent mapping is friendlier to direct peer connections, while address-dependent or address-and-port-dependent mapping can make direct P2P fail and push the session toward a relay path.⁴ Briefly contacting a STUN server lets the tool observe how your router rewrites outbound packets. From that single exchange the tool can infer which mapping style your NAT is using without any persistent connection.

Seeing address-dependent or address-and-port-dependent behavior up front tells you whether a direct test with a remote partner is realistic. When that mapping style is present the session may fall back to a relay, so the probe saves you from attempting a connection that would fail partway through negotiation. This classification is specific to the moment of the test, since some routers switch behavior as their mapping table fills up.

Reading your metrics

RTT (round-trip time) is the total time for a probe packet to reach the other peer and return. Average and min/max values give a picture of baseline latency versus spikes. Jitter measures stability: low jitter means consistent delivery, and high jitter means audio and video will require buffering to compensate.⁵

What each metric tells you

Packet loss counts both simulated drops from the loss slider and real timed-out probes, which are packets that never return an echo within the timeout window. ICE Candidate Type shows whether the connection is direct on your LAN (host), traversing NAT (srflx), or relayed through a TURN server (relay).³ Seeing a relay candidate is a useful signal that NAT traversal failed and that traffic is taking a longer path through an intermediary, which usually adds latency.

The min and max RTT values help you separate brief congestion spikes from a consistently high baseline. A stable average with occasional outliers points to a transient overload somewhere on the path, whereas a consistently high minimum suggests the route itself is the bottleneck. Jitter combines with loss here: a connection with low average RTT but rising jitter is starting to show the kind of irregular delivery that breaks real-time audio and video playback.

Where you run the two sides changes what the numbers mean. Two browser windows on the same machine exercise only the local loopback path, so the RTT sits near the floor and the test can never show a real network problem; it is useful for learning the controls, not for diagnosis. Two machines on the same Wi-Fi add the wireless hop, where contention and retransmissions live; two machines on different internet connections traverse the full NAT-plus-ISP path this tool exists to test. Give the session time, too. Jitter and loss verdicts need an observation window long enough to catch periodic congestion, so let it run for several minutes rather than trusting the first ten seconds of a quiet line.

Loss and latency simulation

The simulation controls let you introduce artificial conditions to test how your application behaves under degraded network quality. Sliding the loss rate simulates a congested link, and setting artificial latency approximates a longer or more contended path. Both effects appear immediately on the sparkline so you can watch your metrics react in real time as you move the sliders.

How packet drops are simulated

Simulated drops are applied at the send layer, so the packet is never actually transmitted and the other peer never sees it. The visual effect on the chart is identical to real loss: a red marker appears at that probe position, and the loss counter increments as though the packet had vanished somewhere on the path. This lets you model the experience of running over unreliable links without leaving your desk.

Applying a fixed latency offset is useful for modelling what happens when traffic crosses a long distance or passes through a slow intermediary. A small offset of 50 to 100 milliseconds hardly registers in conversation, but combined with high loss it quickly makes a session feel sluggish and unreliable, which is a realistic picture of many mobile and satellite links.

Jitter thresholds for real-time applications

Different real-time applications tolerate jitter very differently. Opus is designed for interactive audio such as VoIP, videoconferencing, and in-game chat, with frame sizes that can range from 2.5 ms to 60 ms depending on mode and layer.⁶ That flexibility helps applications adapt to network conditions, but variable delay can still become audible when it exceeds what the receiving side can absorb. Games and remote desktop sessions can also feel uneven when packets arrive irregularly, even if average latency looks acceptable. Measuring jitter between your actual peers rather than to a datacenter reveals whether your network introduces variable delay that affects those applications.

The tool calculates jitter using the RFC 3550 exponential weighted moving average formula, the same method used by RTP endpoints in voice over IP systems.¹ This smooths momentary spikes without hiding sustained instability. If your average RTT is stable but your jitter is high, the cause is usually Wi-Fi retransmissions, CPU contention on a shared device, or bufferbloat on a home router processing multiple concurrent streams. Running the test while replicating your real usage conditions, including other active devices on the same network, gives a more accurate diagnosis than testing on an otherwise idle connection.

For raw latency, voice guidance gives the most defensible anchor. ITU-T Recommendation G.114, the one-way transmission time standard for voice, treats roughly 150 ms of one-way mouth-to-ear delay as the point where most users start noticing the lag in a conversation.⁷ This tool reports round-trip time, so the honest translation doubles that budget: an RTT hovering near 300 ms means each direction is consuming about the whole allowance before you add processing the probe cannot see. Anything comfortably below that leaves headroom. Run your own session above and compare the reported average against that voice budget, and you have a concrete answer to whether your path is good for conversation, not just a number.

When direct P2P fails: symmetric NAT

Older NAT discussions often used cone and symmetric labels, but modern UDP NAT guidance describes mapping and filtering behavior separately. Address-dependent or address-and-port-dependent mapping can make hole punching fail, which is why some direct WebRTC sessions need a TURN relay server to forward packets between peers.⁴ Corporate networks, carrier-grade NAT (CGNAT) used by mobile carriers, and some home routers running in double-NAT configurations commonly use restrictive NAT behavior. The STUN probe on the tool's first screen identifies this condition so you know whether a direct test is possible before attempting it.

When hole punching cannot succeed, the only reliable fallback is routing traffic through a TURN server, which forwards each packet between the two peers at the cost of extra latency and bandwidth. Without TURN relay support built into this tool, a session between two restrictive NATs will simply fail to connect, which mirrors the behaviour you would see in many production WebRTC applications. Recognizing this limitation before you start troubleshooting saves time and points you toward the right fix.

What your NAT type means for connecting

"NAT type" is the question most people arrive with, and the mapping styles above are the honest answer to it. RFC 4787, the IETF's behavioral requirements for UDP NATs, names the three mapping styles this probe reports, and its requirement that NATs use endpoint-independent mapping exists precisely because restrictive mapping forces applications onto relays.⁸ In plain terms: endpoint-independent mapping is the friendly case, where your router reuses the same external port for every destination, so hole punching usually succeeds; address-dependent and address-and-port-dependent mapping give you a different external port per destination, which is what breaks direct connections.

Game platforms grade the same behavior with friendlier labels. Consoles and matchmaking systems often sort players into open, moderate, or strict NAT grades, bundling mapping and filtering behavior into a single verdict; the RFC deliberately measures those separately because they answer different questions.⁸ What this probe reports is the underlying mapping behavior, which is the quantity that actually decides whether a direct peer connection can succeed. No grade is a verdict on your connection quality overall: a restrictive result explains why direct sessions struggle to connect, and the fix sits in the router's NAT behavior or a relay, not in more bandwidth.