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.

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.

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.

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.