To retrieve an object from the Akamai Intelligent Platform™, users must connect to an Akamai Edge server. The server must apply a set of rules to the request, and then either locate the object in its cache or retrieve it from the origin.
Connecting to an Akamai Edge Server
Fundamentally, the Akamai Intelligent Platform improves user experience by serving your content from an Akamai edge server that is physically close to the user, no matter where in the world that user is. This is why there are so many servers in the Akamai Intelligent Platform.
In order for a user to retrieve your content from an Akamai edge server close to that user, when the user makes a request to www.example.com, somehow that request needs to arrive at the Akamai edge server instead of at www.example.com. This re-routing of requests is done via DNS, the Domain Name System. Customers often publish their content at an Akamai hostname, for example www.example.com.edgesuite.net. When the browser looks up this hostname, the user’s DNS server will contact Akamai’s DNS servers. Akamai DNS servers are typically deployed in layers: the first layer is named a Top Level Name Server (TLNS), which talk to the lower layers which are composed of Low Level Name Servers (LLNS).
Our TLNS servers will try to locate an Akamai server deployment near the user. The user’s DNS server is used as a proxy for the actual location of the user. Once a server deployment has been chosen, the TLNS server will provide a pointer to the LLNS server within that deployment.
The user’s DNS server will then contact the LLNS server in order to learn the IP address of the edge server in that deployment which can serve the customer’s content.
After learning the IP address of an edge server, the user will open a connection to that server and request the content.
When an edge server gets a request from a user, it applies a set of rules that describe how to process the content the edge server receives from the origin. Those rules are named metadata, as they describe not the content itself, but rules about how to manage your content.
Basic metadata rules must define:
- if the content should be cached
- how long it should be cached
- how to check with the origin web server to detect changes in the content
In addition, metadata may also provide additional features, such as:
- customizing or restricting content based on the geographic location of the user
- authenticating users
- optimizing the route between the edge server and the origin server to improve performance
- increasing reliability by providing fault tolerance
Locating an object
The edge server will check its local cache as well as the caches of other machines in the server deployment to see if the requested object has been seen before. If the object is found, the edge server will verify that the object is not stale and will serve it to the user.
If the object is found in the cache but it is stale, the edge server will contact another Akamai deployment or the origin to see if a newer version has been uploaded.
Origin retrieval and tiered distribution
When an edge server gets a request for an object that it hasn’t yet seen, it will download it from either another Akamai deployment or the origin. The customer’s metadata determines whether the edge contacts the origin directly, or if it applies some sort of tiered distribution hierarchy.
Tiered distribution is used to provide greater origin offload by allowing many Akamai edge deployments to go forward to a smaller set of deployments which in turn go forward to the origin. In the case of Akamai’s Site Shield product, the Customer’s IT department can program the IP addresses of these top-tier machines into their firewall and block access to their network from all other Internet hosts.
At this point, caching rules are applied to the object and the requested bytes are delivered to the user.