# Networking glossary

> Plain-English definitions of the terms behind IP addresses, TLS and TCP fingerprints, DNS resolvers, NAT and network paths.

The terms behind IP addresses, DNS, TLS, TCP, NAT and network performance, explained on their own.

## IP addresses and routing

### IP address

The number that identifies a device or router interface on the internet so packets can be delivered to it. Two versions are in use side by side: IPv4 and IPv6.

### IPv4

The original internet address format: 32 bits, written as four decimal numbers such as 203.0.113.42. The roughly four billion addresses ran out, which is why most home connections share one public IPv4 address behind NAT.

### IPv6

The current address format: 128 bits, written in hexadecimal groups such as 2001:db8::1. Each network receives so many addresses that every device can have a public one of its own, without NAT.

### Public IP address

An address reachable from the whole internet, as opposed to a private one used only inside a home or office network. What a website sees as your address is your public one, usually your router's.

### CIDR (prefix length)

Classless Inter-Domain Routing notation writes a block of addresses as an address and a prefix length, such as 192.0.2.0/24: the first 24 bits are the network, the remaining bits number the hosts within it. Reference: [RFC 4632](https://www.rfc-editor.org/rfc/rfc4632).

### Subnet mask

The IPv4 way of writing a prefix length: 255.255.255.0 is the same as /24. The bits set to one belong to the network part of the address.

### Autonomous System Number (ASN)

The number of a network that runs its own routing policy on the internet, such as an ISP, a hosting company or a large enterprise. Every public address belongs to a block announced by exactly one AS, so the ASN says who operates the network behind an address.

### BGP announced prefix

The block of addresses an autonomous system tells the rest of the internet it can deliver to, through the Border Gateway Protocol. An address's announced prefix is often much larger than the block its own network uses.

### IP geolocation (GeoIP)

Estimating where an address is used from databases of which address blocks are assigned and used where. It gives a country reliably and a city often, but it is not a position: mobile and VPN addresses are typically placed at the operator's hub.

### Reverse DNS (PTR record)

The name registered for an address, looked up the other way round from a normal DNS query. ISPs often encode the address or the line type in it, which makes it useful for telling a home line from a server.

### Dual-stack

A network or device that has both an IPv4 and an IPv6 address and can use either. Most connections today are dual-stack; the browser decides which family to use for each site.

### Happy Eyeballs

The procedure browsers use on dual-stack connections: they start connecting over IPv6 and IPv4 almost at once and keep whichever answers first, with a slight preference for IPv6. It is why a site may see you over one family for one page and the other for the next. Reference: [RFC 8305](https://www.rfc-editor.org/rfc/rfc8305).

### Interface identifier

The lower 64 bits of an IPv6 address, chosen by the device itself. It can be derived from the hardware address (EUI-64), generated at random as a privacy address, or assigned by DHCPv6. Reference: [RFC 7217](https://www.rfc-editor.org/rfc/rfc7217).

### EUI-64

A way of building an IPv6 interface identifier from the device's 48-bit hardware (MAC) address by inserting two fixed bytes and flipping one bit. It exposes the hardware address, and with it the manufacturer, to everyone the device talks to; modern systems use random identifiers instead.

### MAC address (hardware address)

The 48-bit address of a network adapter, used on the local network segment rather than across the internet. Its first three bytes, the OUI, are registered to the manufacturer.

### IPv6 transition mechanisms (6to4, Teredo, 6in4)

Ways of carrying IPv6 across a network that only speaks IPv4, by wrapping IPv6 packets inside IPv4 ones. 6to4 and Teredo encode the public IPv4 address inside the IPv6 address; tunnel brokers assign a fixed prefix. A tunnelled address usually means IPv6 is not native on the line. Reference: [RFC 4380](https://www.rfc-editor.org/rfc/rfc4380).

### Time to live (TTL, hop limit)

A counter every packet starts with, which each router along the way reduces by one; a packet whose counter reaches zero is discarded. Operating systems start from fixed values (64, 128 or 255), so the value that arrives reveals both the starting value and how many routers the packet crossed.

### Hop count

The number of routers a packet crossed between two hosts. It can be measured with traceroute or inferred from how far the time to live has fallen.

### MTU (maximum transmission unit)

The largest packet a link can carry. Ethernet's is 1500 bytes; PPPoE lines, tunnels and VPNs take some of that for their own headers, so the effective size is smaller.

### Path MTU

The largest packet that gets through every link between two hosts without being split up, which is the smallest MTU on the path. Discovering it (PMTUD) relies on routers reporting oversized packets, and paths where those reports are filtered silently drop large packets. Reference: [RFC 8201](https://www.rfc-editor.org/rfc/rfc8201).

### Fragmentation

Splitting a packet too large for a link into pieces that are reassembled at the destination. IPv4 routers may fragment; IPv6 routers never do, so the sender has to keep packets within the path MTU. Many firewalls drop fragments outright.

### IPv6 extension headers

Optional headers an IPv6 packet can carry between the main header and the payload, for destination options, routing, fragments and hop-by-hop options. Many networks drop packets that use them, which breaks protocols that rely on them. Reference: [RFC 7045](https://www.rfc-editor.org/rfc/rfc7045).

### Explicit Congestion Notification (ECN)

A way for routers to signal congestion by marking packets instead of dropping them. Both ends have to agree to use it, and some middleboxes strip the marks, so whether it survives a path is worth testing. Reference: [RFC 3168](https://www.rfc-editor.org/rfc/rfc3168).

### IP identification field (IP-ID)

A number in every IPv4 header originally meant to match up fragments. How a system chooses it, counting up, at random or always zero, is a trait of its operating system.

### Flow label

A number in the IPv6 header that marks packets belonging to the same connection, so routers can spread traffic over parallel links without reordering a flow. Whether it is set at all depends on the operating system. Reference: [RFC 6437](https://www.rfc-editor.org/rfc/rfc6437).

## DNS

### DNS (Domain Name System)

The system that turns names such as example.com into addresses. Every connection to a named site starts with a DNS lookup, which makes the resolver that answers it a witness to everything you visit.

### Recursive resolver (DNS resolver)

The server that answers a device's DNS questions by asking the authoritative servers on its behalf and caching the results. It is normally run by the ISP, chosen by the user (a public resolver), or built into a VPN.

### Authoritative name server

The server that holds the actual records for a domain and answers resolvers about it. It sees which resolvers ask, and when, which is how a resolver can be detected from the outside.

### Public DNS resolver

A resolver anyone may use, run by companies such as Google (8.8.8.8), Cloudflare (1.1.1.1) or Quad9 (9.9.9.9). They answer from large pools of addresses in many locations, and most of them validate DNSSEC.

### DNS leak

DNS queries leaving through a resolver other than the one a VPN or private connection was supposed to use, revealing which sites are visited to the ISP or another party. A DNS leak test shows which resolver actually asked.

### DNSSEC

Signatures on DNS records that let a resolver check an answer has not been forged or altered. The signatures form a chain of trust from the root zone down; a resolver that validates rejects answers whose signatures do not verify. Reference: [RFC 4033](https://www.rfc-editor.org/rfc/rfc4033).

### DNSSEC validation (DO bit)

Actually checking DNSSEC signatures, as opposed to merely asking for them. A resolver sets the DO bit to request signatures, but only a validating resolver fetches the zone's public key to check them, which is the observable difference.

### QNAME minimisation

A resolver privacy measure (RFC 9156): when working down from the root, the resolver asks each name server only for the part of the name that server needs, instead of revealing the full name to everyone along the way. Reference: [RFC 9156](https://www.rfc-editor.org/rfc/rfc9156).

### 0x20 case randomisation

A resolver protection against forged answers: it randomises the letter case of the name it asks for, and a genuine answer echoes the same case. An attacker guessing answers would have to guess the case pattern too.

### DNS cookies

A lightweight token exchanged between a resolver and a name server (RFC 7873) so that off-path forgeries can be told apart from real traffic, without the cost of DNSSEC. Reference: [RFC 7873](https://www.rfc-editor.org/rfc/rfc7873).

### Source port randomisation

Sending each DNS query from a fresh random port. With a fixed port, and port 53 above all, an attacker who guesses the transaction ID can slip a forged answer into the resolver's cache, known as cache poisoning. Reference: [RFC 5452](https://www.rfc-editor.org/rfc/rfc5452).

### EDNS (Extension mechanisms for DNS)

Additions to the original DNS protocol that let a resolver announce a larger UDP answer size, request DNSSEC signatures and attach options such as cookies or the client subnet. A buffer size of 1232 bytes is the modern default. Reference: [RFC 6891](https://www.rfc-editor.org/rfc/rfc6891).

### EDNS Client Subnet (ECS)

An option with which a resolver forwards part of the asking client's network to the authoritative server, so geo-aware services can answer for the client's location instead of the resolver's. It trades some privacy for better CDN placement. Reference: [RFC 7871](https://www.rfc-editor.org/rfc/rfc7871).

### DNS TTL

The lifetime, in seconds, a record's owner allows it to be cached. Many resolvers enforce a minimum of their own and keep answers longer than asked, which delays changes but reduces load.

### DNS truncation and TCP fallback

An answer too large for one UDP packet comes back truncated, which tells the resolver to repeat the query over TCP. Paths or resolvers that cannot make that switch fail on large answers, which DNSSEC makes common.

### HTTPS record (SVCB)

A DNS record type that tells a client, before it connects, how a service can be reached: which protocols it speaks (HTTP/3, for instance), and the key needed for Encrypted Client Hello. Modern browsers ask for it alongside addresses. Reference: [RFC 9460](https://www.rfc-editor.org/rfc/rfc9460).

### DNS over HTTPS and DNS over TLS (DoH, DoT)

Sending DNS queries inside an encrypted HTTPS or TLS connection, so the network in between cannot read or alter them. The resolver at the other end still sees everything, which is why the choice of resolver matters. Reference: [RFC 8484](https://www.rfc-editor.org/rfc/rfc8484).

## TLS and client fingerprints

### TLS (Transport Layer Security)

The protocol that encrypts and authenticates connections, including every HTTPS page. TLS 1.3 is current; TLS 1.2 is still widely accepted; older versions are considered broken. Reference: [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446).

### ClientHello

The first message of a TLS handshake, in which the client lists the versions, cipher suites, extensions, key shares and application protocols it supports. Its exact contents are characteristic of the software that produced it.

### Server Name Indication (SNI)

The extension that carries the name of the site the client wants, sent in the clear so a server hosting many sites can pick the right certificate. It is what lets a network see which site is visited even though the rest is encrypted.

### Encrypted Client Hello (ECH)

An extension that encrypts the sensitive parts of the ClientHello, above all the server name, using a key published in DNS. With it, the network sees only the name of the fronting provider, not the actual site. Reference: [IETF draft](https://datatracker.ietf.org/doc/draft-ietf-tls-esni/).

### ALPN (Application-Layer Protocol Negotiation)

The extension with which the client lists the application protocols it can speak over the connection, such as h2 for HTTP/2 or http/1.1, and the server picks one during the handshake. Reference: [RFC 7301](https://www.rfc-editor.org/rfc/rfc7301).

### Cipher suite

A named combination of the algorithms a connection uses for key exchange, encryption and integrity, such as TLS_AES_128_GCM_SHA256. The client offers a list in order of preference; the server chooses.

### TLS extensions

Optional fields in the ClientHello that carry everything beyond the basics: the server name, supported versions and groups, key shares, ALPN and more. Which extensions a client sends, and in what order, is a large part of its fingerprint.

### GREASE

Random reserved values that browsers sprinkle into the ClientHello (RFC 8701) so servers keep tolerating values they do not recognise. Fingerprinting schemes strip them out before hashing. Reference: [RFC 8701](https://www.rfc-editor.org/rfc/rfc8701).

### Key exchange (key share, supported groups)

How the two ends agree on a shared secret. TLS 1.3 clients send key material for their preferred groups (X25519, P-256) in the first message, so the exchange completes in one round trip.

### Post-quantum key exchange (ML-KEM, X25519MLKEM768)

A key exchange designed to resist attack by a future quantum computer, deployed today as a hybrid of the classic X25519 and the ML-KEM lattice scheme. It matters now because traffic can be recorded today and decrypted years later. Reference: [IETF draft](https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/).

### Session resumption (PSK, 0-RTT)

Reusing the keys of an earlier connection to the same server so the handshake is shorter, or, with 0-RTT, so the client can send data in its very first flight. It also tells the server it has seen this client before.

### Certificate compression

An extension (RFC 8879) that lets the server send its certificate chain compressed, typically with brotli, saving a few kilobytes on every fresh handshake. Reference: [RFC 8879](https://www.rfc-editor.org/rfc/rfc8879).

### TLS fingerprint

An identifier computed from the shape of a client's ClientHello: which versions, ciphers, extensions and groups it offers and in what order. It identifies the TLS library and often the exact browser, independently of what the User-Agent claims, and is widely used to tell browsers from bots.

### JA3

The original TLS client fingerprint: an MD5 hash of the version, cipher suites, extensions, groups and point formats in the order the client sent them. Because modern browsers shuffle extension order, a JA3 changes between connections of the same browser. Reference: [Salesforce](https://github.com/salesforce/ja3).

### JA4

A newer TLS client fingerprint by FoxIO, written as readable parts: transport and version, the count of ciphers and extensions, the ALPN, then hashes of the sorted cipher and extension lists. Sorting makes it stable when a browser shuffles its extensions. Reference: [FoxIO](https://github.com/FoxIO-LLC/ja4).

### JA4H

FoxIO's HTTP client fingerprint: the request method, HTTP version, whether cookies and a referer were present, the language, and hashes of the header names and cookie names in order. Reference: [FoxIO](https://github.com/FoxIO-LLC/ja4).

### JA4T

FoxIO's TCP client fingerprint, taken from the SYN packet: the window size, the TCP options in the order they were sent, the maximum segment size and the window scale. It identifies the operating system's network stack. Reference: [FoxIO](https://github.com/FoxIO-LLC/ja4).

### JA4TS

The same TCP fingerprint computed from the server's SYN-ACK, so the two ends of a handshake can be compared.

### JA4L

FoxIO's light-distance fingerprint: the one-way time of the handshake converted into how far away the client can be at most, given that light in fibre covers about 200 km per millisecond. Reference: [FoxIO](https://github.com/FoxIO-LLC/ja4).

### HTTP/2 fingerprint (Akamai fingerprint)

An identifier built from what a client sends when it opens an HTTP/2 connection: its SETTINGS values, the initial flow-control window update, any PRIORITY frames and the order of the pseudo-headers. Every browser engine has its own pattern. Reference: [Akamai paper](https://www.blackhat.com/docs/eu-17/materials/eu-17-Shuster-Passive-Fingerprinting-Of-HTTP2-Clients-wp.pdf).

### Header order

The sequence in which a client sends its HTTP request headers. Browsers emit them in a fixed order that differs between engines, so the order identifies the software even when the headers themselves look ordinary.

### User-Agent

The header in which a browser names itself and its platform. It is trivial to change, which is why fingerprints computed from the TLS handshake and HTTP/2 behaviour are used to check whether it is telling the truth.

### Client Hints

A newer way for browsers to report platform, architecture, device model and brand versions in a structured form, mostly only when a site asks. Chromium browsers send them; they replace much of what the User-Agent string used to carry. Reference: [RFC 8942](https://www.rfc-editor.org/rfc/rfc8942).

## TCP and the wire

### TCP handshake (SYN, SYN-ACK, ACK)

The three packets that open a TCP connection: the client's SYN, the server's SYN-ACK and the client's ACK. The SYN carries the client's stack settings, which is why it is the packet used for passive OS fingerprinting. Reference: [RFC 9293](https://www.rfc-editor.org/rfc/rfc9293).

### Round-trip time (RTT)

How long a packet takes to reach the other end and for the reply to come back. It bounds how fast any exchange can go and, through the speed of light, how far away the other end can be.

### Jitter

How much the round-trip time varies from one packet to the next. Stable latency matters more than low latency for calls and games.

### Passive OS fingerprinting (p0f)

Guessing a host's operating system from packets it sends anyway, without probing it. The SYN's initial TTL, window size, maximum segment size and option order differ between Linux, Windows, macOS and network gear; p0f is the classic tool and signature database for this. Reference: [p0f](https://lcamtuf.coredump.cx/p0f3/).

### TCP options

Extras negotiated in the handshake: maximum segment size, window scaling, selective acknowledgements, timestamps, ECN and TCP Fast Open. Which ones a stack sends, and in what order, is part of its fingerprint.

### Maximum segment size (MSS)

The largest TCP payload a host will accept per packet, announced in the SYN. Stacks derive it from the interface MTU, so 1460 means plain Ethernet, 1452 a PPPoE line, and smaller values a tunnel or VPN in between.

### Congestion window (cwnd)

How much data a sender is willing to have in flight before waiting for acknowledgements. It starts small, grows during slow start, and is cut back when packets are lost; its size at any moment is the sender's estimate of what the path can take.

### Slow start (ssthresh)

The opening phase of a TCP connection, in which the congestion window doubles every round trip until loss occurs or the slow-start threshold is reached. Short transfers such as a web page often finish before slow start ends.

### Congestion control (CUBIC, BBR)

The algorithm a sender uses to decide how fast to transmit. CUBIC, the common default, grows until packets are lost. BBR models the bottleneck bandwidth and round-trip time instead, and tends not to fill queues. Reference: [BBR](https://research.google/pubs/bbr-congestion-based-congestion-control-2/).

### Receive window

How much data the receiver tells the sender it can accept, based on its buffer. Modern stacks grow it automatically during a transfer (autotuning); a window that never grows caps throughput on long paths.

### Window scaling

The TCP window field is only 16 bits, so both ends agree on a shift factor in the handshake to advertise larger windows. Without it, throughput on a high-latency path is capped at 64 kB per round trip. Reference: [RFC 7323](https://www.rfc-editor.org/rfc/rfc7323).

### Delayed acknowledgement

A receiver holding back its acknowledgement briefly, hoping to combine it with data going the other way or to acknowledge two segments at once. Typical delays are 40 to 200 ms and are characteristic of the operating system.

### Retransmission (RTO, SACK, DSACK)

Sending data again when its acknowledgement does not arrive in time. Selective acknowledgements (SACK) tell the sender exactly which pieces are missing; a DSACK reports a duplicate, which reveals a retransmission that was not needed. Reference: [RFC 2018](https://www.rfc-editor.org/rfc/rfc2018).

### TCP timestamps

An option that stamps every segment with a counter, used for round-trip measurement and protection against wrapped sequence numbers. The rate the counter ticks at is a trait of the stack, and an unrandomised counter reveals the machine's uptime.

### TCP_INFO

The Linux kernel's report on a live socket: round-trip time and its variance, congestion window, retransmissions, delivery rate, the peer's window and more. A server can read it for any connection it holds, which a reverse proxy in between would hide. Reference: [tcp(7)](https://man7.org/linux/man-pages/man7/tcp.7.html).

### TLS record

The unit in which TLS wraps encrypted data. How a TLS stack chops a request into records, and their sizes, is another small trait of the software that produced them.

### Middlebox

Any device on the path that inspects or rewrites traffic beyond plain routing: a NAT, a firewall, a proxy, a load balancer. Middleboxes rewrite TTLs, strip TCP options and ECN marks, and are the usual reason a fingerprint looks inconsistent.

### Packet capture

Recording packets as they arrive at a network interface, with their exact timing and headers. It shows what a connection really looked like on the wire, independently of what either end's software reports.

## NAT, paths and QUIC

### NAT (Network Address Translation)

A router rewriting the private addresses of the devices behind it into its own public address, and keeping a table of which port belongs to which device. It lets a whole household share one IPv4 address, at the cost of making inbound connections hard. Reference: [RFC 4787](https://www.rfc-editor.org/rfc/rfc4787).

### Carrier-grade NAT (CGNAT)

NAT performed by the ISP, so that many customers share one public IPv4 address. It hands each subscriber a block of ports, and a device behind it is behind two NATs in a row, which hurts peer-to-peer connections. Reference: [RFC 6888](https://www.rfc-editor.org/rfc/rfc6888).

### STUN

A protocol with which a device asks a server what public address and port its packets appear to come from. It is how WebRTC discovers the address to hand to a peer, and how NAT behaviour is measured. Reference: [RFC 8489](https://www.rfc-editor.org/rfc/rfc8489).

### NAT mapping behaviour (cone NAT, symmetric NAT)

Whether a NAT gives a device the same external port for every destination (endpoint-independent, a cone NAT) or a different one per destination (endpoint-dependent, a symmetric NAT). The first lets two devices behind NATs connect directly; the second usually needs a relay. Reference: [RFC 4787](https://www.rfc-editor.org/rfc/rfc4787).

### Port allocation

How a NAT picks external ports: preserving the device's own port, counting up, or drawing them at random. A fixed block of ports is the signature of carrier-grade NAT.

### WebRTC (ICE)

The browser API for real-time calls and peer-to-peer data. To connect peers it gathers all the addresses a device has, local and public, which is why WebRTC can reveal an address that the web traffic itself does not use, a classic VPN leak. Reference: [RFC 8445](https://www.rfc-editor.org/rfc/rfc8445).

### Traceroute

Mapping the routers on a path by sending packets with increasing time-to-live values and recording which router reports each one expiring. A reverse traceroute runs from the server back towards the client, showing the return path, which can differ from the forward one.

### ICMP

The protocol routers and hosts use for control messages: echo (ping), time exceeded (what traceroute relies on) and destination unreachable, including the packet-too-big message that path MTU discovery depends on. Filtering it breaks more than ping. Reference: [RFC 792](https://www.rfc-editor.org/rfc/rfc792).

### MPLS

A technique carriers use to forward packets along pre-set paths by label rather than by address. Routers inside an MPLS tunnel can quote their label stack in a time-exceeded reply, which makes the tunnel visible in a traceroute.

### QUIC

A transport protocol built on UDP that combines the jobs of TCP and TLS: encrypted from the first packet, with multiplexed streams and a faster handshake. HTTP/3 runs on it. Because it is encrypted, middleboxes cannot inspect or alter it the way they do TCP. Reference: [RFC 9000](https://www.rfc-editor.org/rfc/rfc9000).

### HTTP/3

The version of HTTP that runs over QUIC instead of TCP. A browser learns a server supports it through an Alt-Svc header or an HTTPS DNS record, then switches on a later connection. Reference: [RFC 9114](https://www.rfc-editor.org/rfc/rfc9114).

### Alt-Svc

A response header with which a server announces that the same service is available over another protocol or port, typically HTTP/3 on UDP 443. The browser remembers it and may use it for the next connection. Reference: [RFC 7838](https://www.rfc-editor.org/rfc/rfc7838).

### QUIC transport parameters

The limits a QUIC endpoint announces at the start of a connection: how much data it will buffer, how many streams it allows, how long it keeps an idle connection. Each browser announces its own set, which makes them a fingerprint of the QUIC stack.

### QUIC connection ID

An identifier QUIC packets carry so a connection survives a change of address or port, for instance when a phone moves from Wi-Fi to mobile data. Its length is chosen by each endpoint.

### DPLPMTUD

Path MTU discovery done by the transport itself, by sending padded probes of increasing size and seeing which are acknowledged, rather than relying on routers' ICMP messages. QUIC uses it; it works on paths where ICMP is filtered. Reference: [RFC 8899](https://www.rfc-editor.org/rfc/rfc8899).

## Browser, device and privacy

### Browser fingerprint

A combination of what a browser reveals about itself and its device, such as the user agent, languages, screen size, time zone, fonts, GPU and canvas rendering, that is often unique enough to recognise a browser again without cookies.

### Canvas fingerprint

A hash of how the browser draws a small piece of text and shapes onto a hidden canvas. Font rendering and graphics drivers differ enough between machines that the result is stable per device and different across devices.

### WebGL renderer (GPU string)

The name of the graphics adapter and driver the browser exposes through WebGL. It is one of the strongest single identifiers a page can read, which is why some browsers blur it.

### Network Information API

A browser API that reports a rough classification of the connection (2g to 4g), an estimated bandwidth, a round-trip estimate and whether data saver is on. Only Chromium browsers implement it, and the values are deliberately coarse.

### Resource Timing

The browser API that records the timing of each request it made: DNS lookup, TCP connect, TLS handshake and time to first byte. It is the client's own view of the connection, which can be compared with what the server measured. Reference: [W3C](https://www.w3.org/TR/resource-timing/).

### Do Not Track

A header a browser could send to ask sites not to track the user. It was never enforced and most browsers have removed it; its successor is Global Privacy Control.

### VPN and proxy detection

Telling whether a connection comes directly from a user's own network or through a VPN, proxy or relay. No single check is conclusive; what works is comparing independent signals: the address's network type and published relay ranges, the operating system implied by the TCP stack against the browser's claim, the distance implied by the round trip against the address's location, the time zone of the device, and what WebRTC and the DNS resolver reveal.

## Performance

### Latency

The delay between sending something and it arriving, usually measured as a round trip. It is set by distance and the number of devices in the path, and it cannot be bought down the way bandwidth can.

### Bufferbloat

Latency that appears only when the connection is busy, caused by oversized buffers in a router or modem filling up and holding packets in a queue. It is what makes a video call stutter while something else is downloading, and it is measured as the latency added under load. Reference: [bufferbloat.net](https://www.bufferbloat.net/projects/bloat/wiki/Introduction/).

### Throughput and goodput

Throughput is how many bytes cross a link per second; goodput is how many of those are useful data once retransmissions and headers are taken out. A short transfer from a single server measures neither reliably, because TCP is still in slow start for most of it.

### Pacing

Spreading a sender's packets evenly over time instead of sending a window's worth in a burst. Paced traffic fills queues less; the spacing of arriving packets hints at which congestion control the sender uses.

### Clock offset

The difference between a device's clock and a reference clock, measured by timing a round trip and assuming both directions took equally long. The accuracy is about half the round trip.

---

Canonical page: https://ip-tools.eu/glossary · API documentation: https://ip-tools.eu/docs/api.md · All pages: https://ip-tools.eu/llms.txt