Speed up delivery of your non-static content and refine the performance of your web application.

Web applications deal with information that are generated from a database or they are driven by user interaction. The dynamic nature of this type of content makes caching impractical, since an asset previously generated by a web application would never be requested again. A major tool in the arsenal of a CDN is to cache assets close to the clients that are requesting it and thereby bypassing the data retrieval from an origin server for subsequent requests. Since caching is impractical for web applications, they cannot take full advantage of the capabilities provided by our CDN-solutions. In this type of environment Application Delivery Network (ADN) stands out.

Despite of the fact, that dynamic content cannot be effectively cached, ADN finds other ways through which to speed up data delivery to the customer’s clients. It is able to cardinally reduce the amount of time that it takes to communicate with the origin server by optimizing each of the following items:

• Network path
• Server communication
• RFC-compliant protocol communication.

These optimizations allow our dedicated servers to transmit dynamic data at a much faster rate than traditional Internet data routes or even our CDN service can accomplish.

If the customer’s web application also contains static content, then he has the choice to either accelerate that content through ADN or to take advantage of our CDN services (i.e., HTTP Large or the HTTP Small platforms). Using ADN for all of the customer’s content will ensure that his entire site is configured for data delivery optimally. Alternatively, using our CDN services to deliver static content allows the customer to take advantage of caching to reduce the distance that his data must go without incurring the additional cost of premium ADN service. Either way, our services create an environment where the customer can accelerate his entire site and thus produce faster load times for his clients.

Before assets can be served at an accelerated rate to the customer’s users, they must first be retrieved from a web server. The customer can either retrieve assets from his own web server (i.e., customer origin server) or on a storage server in our CDN (i.e., CDN origin server).

A typical ADN configuration involves a customer origin server. This is due to the fact that the customer’s dynamic content is typically generated by code processed by his own web server. Since his content is constantly being updated, it makes sense to point the ADN Gateway directly to his customer origin server.

Content can also be retrieved from a CDN origin server. The main advantage of a CDN origin server is that this type of server is inside our CDN network. The customer’s data is no longer susceptible to network issues due to denial of service attacks or high traffic volume. This guarantees that the data will be available for distribution to the customer’s clients. Additionally, since the data does not have to be retrieved from a location outside our network, it can be delivered even faster to the customer’s clients. However, this type of configuration is only recommended for static content. Taking advantage of ADN to accelerate static content will ensure that the customer’s entire site is quickly delivered to his clients.

Whenever an asset is requested for the ADN platform, it will undergo the following procedure:

• Request
• Security
• Check for Cached Content (POP) ( Check for Content Freshness (POP))
• Retrieval, Delivery, and Caching

Request:
Before an asset can be delivered to a client, a request must be made to an edge server that resides on one of our POPs. This request will be handled by the point-of-presence (POP) closest to that client. This ensures that a minimal amount of time will be required to establish a connection between the client and the edge server.

Security:
The first check performed by an edge server in a POP is to find out whether the requested content has been secured. The following methods for securing the customer’s content are offered:

• Country Filtering
• Token-Based Authentication
• HTTP Rules Engine

If the request fails to meet any of the above security requirements, then our edge servers will deny the request and no additional steps will be taken.

Content can be secured by directory that is allowed by Country Filtering. If the requested content resides in a secured directory, then the location of the user requesting the content determines whether the request will be authorized. If the request is denied, then the HTTP client will receive a 403 Forbidden status code.

If the requested content has been secured through Token-Based Authentication, then an edge server will look for a token value in the query string. If it finds one, then the token value will be decrypted according to the encryption key(s) specified for the ADN platform. A check will then be performed to see whether the HTTP client (e.g., browser) meets the specified requirements.

By default, an HTTP client will receive a 403 Forbidden status code when any of the following is true for an asset protected by Token-Based Authentication:

• The CDN or edge CNAME URL did not include a token value in the query string.
• The specified token was invalid. This occurs for tokens generated using an invalid encryption key or an invalid parameter was used when generating an encryption key.
• The HTTP client did not meet the token requirements.

HTTP Rules Engine is a powerful tool that can be used for a variety of purposes. One feature provided in this tool is "Deny Access (403)." This feature will return a 403 Forbidden status code to the HTTP client whenever a user-defined set of conditions are met.

Check for Cached Content (POP):
If the requested asset passes all of the above security requirements, then a check is performed to see whether the asset is currently cached on the POP handling the request.
If a cached version of the requested asset is found on the POP handling the request, then a check for content freshness will be performed.

Retrieval, Delivery, and Caching:
A default ADN configuration does not cache content and therefore a cached version of the requested content should not be found. In this scenario, requests will be handled as following:

• The POP closest to the client will forward the request to an ADN Gateway server.
• The ADN Gateway server will forward the request to the origin server.
• The origin server will respond with the requested content.
• The ADN Gateway server will forward the response to an edge server on the POP closest to the client.
• Once the edge server starts receiving the asset from the ADN Gateway, the edge server will immediately start delivering it to the client that requested it.

Before assets can be served through our CDN to the customer’s users, they must first be retrieved from a web server. This type of server is known as an origin server, since it is the origin or source of the content that will be delivered to the customer’s users.

ADN Gateway servers are responsible for ensuring efficient data delivery between the CDN and the customer origin servers.

The customer origin server should be optimized for use with ADN. This primarily involves configuring your customer origin server to keep connections alive. There are two ways through which a customer origin server can maintain a connection alive, which are through a web server and through the OS.

For the purpose of fulfilling requests, our edge servers require access to all servers associated with a customer origin configuration. So the customer must ensure that his firewall allows access to all of the IP addresses listed on the Customer Origin page.

Our CDN storage solution allows the storage of content on our storage servers (i.e., CDN origin servers). Content stored in this manner can also be delivered at a quicker rate by taking advantage of the many optimizations that ADN provides. The customers should keep in mind that these types of servers have already been configured to provide optimal data delivery performance when used in conjunction with ADN. As a result, the customer can simply upload his assets to the CDN origin server without having to perform any additional configuration.

The URL to the location on a CDN origin server where the customer’s assets reside can be masked through the use of a Canonical Name (CNAME) record and an edge CNAME.

By default, an asset is not cached on either the ADN Gateway or our edge servers. As a result, requests are always forwarded from our network to an origin server and then returned back to a client via our network.

The customer is provided with an API that he can use to automatically load assets to all of our POPs.

As by default, content requested through the ADN platform is not cached, it is not necessary to purge content for this platform. However, the default caching behavior can be overridden through HTTP Rules Engine.

When there is a newer version of an asset that is available to the customer’s users, he may wish to purge his content. And the customer is provided with a Web Services REST API that he can use to automatically purge content and/or folders from all of our POPs. The Web Services REST API allows to quickly send multiple purge requests.

Also cached assets can be purged manually from our ADN Gateway and edge servers through the Purge/Load page. And the customer is provided with a log of the most recent purge and load requests on that very page.

The customer can save on bandwidth costs and reduces the amount of time that it takes for his users to download his content by using compression. An asset can be compressed either by an origin server or an edge server.

Origin Server Compression


Edge Server Compression