Your users will get more loyal and your revenue will increase with a super-fast site.

Our CDN Network is able to transmit the customer’s content in a more efficient manner to his users via serving that content through the HTTP Large platform and achieving maximum productivity. The network has been optimized to allow data to quickly move between where it is stored and the point-of-presence (POP) closest to the user that requested it. At the same time a copy of the requested content may be stored on that POP. This process is known as caching. Once content has been cached, all future requests for that content from that region can be delivered directly from that POP. This removes the need to retrieve the data from the origin server. The following diagram demonstrates how content is delivered via the CDN to a user.


CDN Data Delivery

1. This data delivery process starts with a user's request for content. This request is directed to the POP closest to the user.

2. An edge server in that POP will check whether the requested content has been previously cached.

• Cached: The asset is instantly served up to that user. In the diagram, the dashed white lines indicate the users that are able to take advantage of a previously cached asset and thus are able to enjoy even faster downloads.
• Not Cached: The POP will forward the request to the appropriate CDN or customer origin server. The origin server will respond with the requested content.

3. The requested asset is delivered via the POP from step 1 to the use that requested it.

• In the above diagram, there are four users requesting content. These users are located close to Seattle and Atlanta. The Seattle and Atlanta users will receive the asset through the Seattle POP and Atlanta POP, respectively. This is represented by orange lines in the diagram. Sending an asset through our network and bypassing traditional Internet communication routes ensures the efficient transmission of your asset and reduced bandwidth load on your network.
• The last leg involved in the delivery of the requested content requires the user’s ISP to deliver the asset from our POP. This is indicated by white lines in the above diagram.

4. The requested asset may then be cached on the POP that received and fulfilled the request. This allows that POP to immediately fulfill future requests for that asset without having to forward the request to the origin server.

There are two types of caching that can take place when an asset is routed through our CDN, which are edge server and user agent (e.g., web browser) caching. Edge server caching determines whether the requested asset will be cached for a particular POP and for how long. This type of caching determines when an edge server on that POP will check for a new version from the origin server. User agent caching determines whether the requested asset will be cached on a web browser and for how long. By default, this type of caching determines when a user agent (e.g., browser) will revalidate the cached asset with the edge server.

If an asset’s headers do not prohibit caching, then the default behavior is to cache it on our POPs and on each user agent (e.g., web browser) that requests it according to the asset's Cache-Control and Expires header information. If an asset does not have header information, then it will be assigned a TTL of 7 days (i.e., Cache-Control: max-age=604800) when it is cached on our edge servers and by the user agents that requested it. The customer can override this default behavior by manually caching and purging assets from our POPs or through the use of HTTP Rules Engine.

Once the asset has been cached on a POP, all future requests that originate from the region served by that POP will be served directly from that POP while the asset is fresh. Once the asset’s TTL has expired, then an edge server from that POP will revalidate the asset with the origin server. If the asset has not been modified, then the header information for the cached asset on the edge server and the user agent that requested it will be updated. Otherwise, a new version of the asset will be retrieved and cached on the edge server and the user agent.

If a user requests an asset that has not been previously cached on the corresponding POP, then an edge server will retrieve it from the origin server. The entire asset will then be cached on that edge server provided that its headers do not prohibit caching, regardless of whether the user performed an HTTP range request or aborted their download. By automatically retrieving and caching the entire asset, future requests for that asset will not require an edge server on that POP to download it again from the customer’s origin server while the asset is still fresh. This functionality reduces the load on the origin server and allows future requests to be served from cache. This ensures the speedy delivery of the customer’s content to his users.

By default, an asset is not cached on our edge servers until it is requested by a user. This means that the first user in a particular region to request an asset will cause the corresponding edge server to request it from the origin server. After which, the asset will remain cached on that edge server until it is automatically or manually purged. Therefore, the first user to request a particular asset will take slightly longer to retrieve it than all other subsequent customers. If the customer has a large event or content that becomes simultaneously available to a large volume of end-users (e.g., a new movie release), then it might be helpful to load all media content on our edge servers.

Requests that contain a query string can be cached differently. The customer can choose to cache these types of assets in one of three different ways. Each cache method is explained below.



By default, no-cache or unique-cache mode cannot be used with Token-Based Authentication. This means that if the customer has protected at least one folder with Token-Based Authentication, then the only cache method that will be available from the MCC is standard-cache. Likewise, if he has configured query string caching to use no-cache or unique-cache mode, then he will not be allowed to protect a folder with Token-Based Authentication.

Another way to override the default cache behavior is to overwrite the cache headers assigned to the customer’s assets. This can be accomplished through HTTP Rules Engine. This feature allows the customer to create custom rules that can be used to handle how our edge servers cache and grant access to assets requested through HTTP-based platforms.