Jitter is the second-order behaviour of a network path. RTT tells you the average; jitter tells you how much that average wiggles. In RFC 3550 (RTP, July 2003) jitter is formally defined as a smoothed estimate of inter-packet arrival variance. For HTTP-based streaming, jitter shows up as variation in segment download time and is absorbed by the player's buffer. For WebRTC and other real-time protocols, jitter has to be absorbed by a much smaller jitter buffer (typically 20–200 ms), and excess jitter directly causes audio/video glitches.
The two main sources of jitter are queueing in network devices (bufferbloat) and competing flows on the same link. Wi-Fi and cellular links typically have much higher jitter than wired Ethernet because of MAC-layer retries and shared spectrum. Modern smart routers and AQM (Active Queue Management, e.g. CoDel, fq_codel) try to keep jitter bounded by dropping packets early rather than letting buffers fill, but most consumer networks still suffer significant jitter under load.
For streaming design, jitter sets the lower bound on jitter buffer size. WebRTC stacks typically run a 60–200 ms adaptive jitter buffer; pushing it lower causes glitches, pushing it higher adds latency. HLS and DASH players hide jitter by holding several segments — a non-issue for VOD but a real constraint for low-latency live. Telemetry should always include jitter alongside RTT, because a network can have a clean average RTT and still feel terrible if its tail is jittery.
