Directing requests to delivery nodes
A CDN can direct requests through DNS arrangements or HTTP redirection to selected delivery nodes. Selection also depends on footprint and capabilities rather than always using one fixed destination.
RFC 7336 describes interconnection and delegation, while RFC 8008 supplies footprint and capability semantics. These interfaces do not require every CDN to share one internal architecture.
Hits and origin acquisition
A node can answer from a reusable stored response; a miss requires acquisition from an upstream service or origin. Interconnected CDNs can add acquisition layers rather than always contacting the original publisher directly.
HTTP freshness and validation govern reuse. Updating the origin does not magically rewrite every copy; expiration, validation and invalidation behavior determine which version a user receives.
One URL can have response variants. If an origin selects language through Accept-Language and declares Vary: Accept-Language, reuse must account for that request field rather than URL alone. A missing matching variant requires validation or an appropriate upstream response; Vary: * never supplies an ordinary matching cache entry. Variant selection does not itself authorize sharing user-private content.
Delivery and content boundaries
Delivery is more than copying files. Shared-cache storage and reuse must respect cache controls, authentication and request matching; popularity does not authorize sharing user-specific responses.
A nearby node can reduce some network delay without accelerating origin computation or first acquisition. Diagnosing a slow request requires distinguishing a cache hit, upstream retrieval and origin processing.