Port 862: TWAMP — Where network performance gets measured, not claimed

Port 862 carries TWAMP (Two-Way Active Measurement Protocol), a protocol that measures network performance by sending synthetic test packets between two devices and analyzing what comes back.

Network performance claims are cheap. "Our network is fast" means nothing without measurement. TWAMP exists to provide evidence—actual numbers for delay, jitter, and packet loss between two points on a network.

Port 862 does something unusual: it carries two different protocols on the same port number. TCP port 862 handles TWAMP-Control (session setup and management). UDP port 862 receives TWAMP-Test packets (the actual measurements). Same port, different transports, different purposes.

What TWAMP Does

TWAMP measures round-trip network performance. A Session-Sender fires test packets across the network to a Session-Reflector, which bounces them back with timestamps. The Sender analyzes the round-trip to calculate:

• Round-trip delay — How long packets take to go there and back
• Jitter — Variation in delay (consistency matters as much as speed)
• Packet loss — What percentage of packets never returned

These metrics reveal whether a network path is actually delivering the performance it claims to deliver. TWAMP is commonly used to verify SLA (Service Level Agreement) compliance—the contractual promises ISPs make about network quality.

How TWAMP Works

TWAMP operates through two distinct protocols that work together:¹

TWAMP-Control runs on TCP port 862. A Control-Client opens a connection to a Server to negotiate test parameters, start test sessions, and stop them when finished. The TCP connection ensures reliable session management.²

TWAMP-Test runs on UDP. The Session-Sender fires timestamped test packets to the Session-Reflector, which adds its own timestamps and sends them back. UDP is preferred because it has minimal overhead and won't distort the measurements with TCP's reliability mechanisms (retransmissions would skew delay measurements).³

The architecture is simple: two hosts, four logical roles (Control-Client, Server, Session-Sender, Session-Reflector), and continuous measurement. The measurements are active, not passive—TWAMP generates its own traffic rather than analyzing existing flows. This gives you control over what gets measured and when.

The History

TWAMP emerged from OWAMP (One-Way Active Measurement Protocol), which measured network performance in a single direction. One-way measurements are more precise in some ways, but they require synchronized clocks on both ends—a practical headache.

TWAMP, standardized in RFC 5357 (October 2008), added two-way measurements.¹ Round-trip measurements don't require clock synchronization, and the remote endpoint can be as simple as an echo function. This made TWAMP easier to deploy widely.

Originally, both TCP and UDP port 862 were assigned to TWAMP-Control. But that created a problem: test sessions run on UDP, not TCP. In March 2019, RFC 8545 reassigned UDP port 862 from the control protocol to the test protocol.⁴ Now the port allocations match how TWAMP actually operates.

TWAMP Light

RFC 5357 also defined TWAMP Light in Appendix I—a stateless variant where test parameters are preconfigured instead of negotiated via TWAMP-Control.¹ No control session needed. The Session-Sender and Session-Reflector already know what test packets to expect and how to handle them.

TWAMP Light trades flexibility for simplicity. It's useful in environments where control-plane overhead is undesirable or where endpoints can't maintain state.

Why Port 862 Matters

Network performance isn't abstract. A video call stutters when jitter is high. File transfers stall when packet loss climbs. Cloud applications feel sluggish when delay increases. TWAMP turns those experiences into numbers.

Port 862 is where those numbers get generated. Every test session measures the gap between what a network promises and what it delivers. The protocol doesn't optimize performance—it reveals it. What happens after that is up to the engineers watching the measurements.

Security Considerations

TWAMP test traffic is unauthenticated by default in its simplest form. An attacker could inject false test packets or impersonate a Session-Reflector, corrupting measurements. RFC 5357 defines authenticated and encrypted modes using shared secrets and HMAC-SHA1.¹

TWAMP can also be abused for network reconnaissance (mapping paths and endpoints) or amplification attacks (if reflectors aren't properly rate-limited). Proper access control and authentication are essential.

Related Ports

• Port 861 — OWAMP-Control (TCP), the one-way measurement protocol that preceded TWAMP⁴
• Port 863 — Unassigned (no neighboring relationship, just the next port number)

Checking Port 862

To see if something is listening on port 862:

Linux/macOS:

sudo lsof -i :862
sudo netstat -tulpn | grep :862

Windows:

netstat -ano | findstr :862

If you see a TWAMP server or network monitoring tool, port 862 is actively measuring network performance. If nothing's listening, no measurement sessions are running.