Implementing a Content Caching Strategy

---

WHAT’s IN THIS ARTICLE: 

Introduction

Appspace utilizes open technologies wherever possible to ensure maximum flexibility for our customers. To this end, Appspace has not created a bespoke caching solution and does not sell or support caching nodes. Each customer’s goals, network, and environments are unique; therefore there is no single solution that will work in all situations.

The following recommendations should be viewed as a starting point and are intended to be used as a guide. Every customer’s situation will be different and these recommendations should be modified by the customer’s networking and web server teams to meet their specific needs.

Many customers would like a solution to locally cache content that is served by the Appspace platform. The most common reasons for this include more efficient ingress bandwidth utilization, increased speed of content delivery, and improved security.

A single element in a caching solution is known as a caching node. A caching solution or content proxy may consist of one or multiple caching nodes. If there are multiple nodes, it is possible for them to work together or individually (without knowledge of each other). If the nodes work together, they can form a network of caches. Caching can occur at multiple levels, including at a single network-wide cache tree, or on a hierarchy of site-level caches within a geographically distributed network. Content caching is equally applicable to cloud-based and on-prem deployments.

This guide will not provide a detailed discussion of caches or reverse proxies. This guide will focus on how these technologies can be applied in concert with the Appspace platform. There are many freely available guides that discuss how these technologies work and can provide architectural guidance

Goals

The typical goals for implementing this solution include:

• Enabling more efficient network utilization by decreasing bandwidth egress costs from Appspace and decreasing ingress traffic to a customer’s network. This is achieved by minimizing the number of times any single piece of content is loaded from the internet to the targeted network, which is especially useful in a geographically distributed network with bandwidth-constrained local networks such as in branches or stores.
• Improving access time by shortening the network distance the content must travel when requested. Since content is served from the caching node and not the Internet, multiple network hops are removed and all traffic stays within the customer’s managed network.
• Reducing security risk surfaces by eliminating the globally distributed Appspace CDN. While extremely secure as a solution, the Appspace CDN is a public attack surface. A local content caching solution, paid for and managed by the customer, can replace the Appspace global CDN and eliminate one attack surface for extremely sensitive implementations.
• Minimizing the cost and increasing the reliability of a caching solution by utilizing highly deployed and publicly available tools. Our solution is based on highly popular software components.

Solution Overview

The Appspace recommended solution utilizes these readily available, well-proven, and highly scalable off-the-shelf software components:

• Linux operating system
• Apache web server 

We recommend using a number of caching nodes which may be deployed across a network. These nodes may be dedicated to servicing specific local networks (branch office, store, etc), combined into load balanced groups, and/or organized hierarchically. The simplest scenario consists of a single caching node on the network edge. Here is a simple diagram showing a single caching node and Appspace network traffic. 

More nodes can be added for each geographical or logical network location.

Appspace Networking Discussion

Appspace has three general categories of network communications:

1. Console: The Appspace console is a conventional web application, which runs in a browser for the creation and publishing of content through the Appspace platform. It communicates with a web server using HTTPS. This traffic is not affected by a caching solution.
2. App signaling: The Appspace App on a device is registered with an Appspace server and is configured with the server’s hostname. The app uses HTTPS to make API calls to retrieve and submit control information such as player settings, content listings, schedules, and health status. This traffic is not affected by a caching solution.
3. App content retrieval: The Appspace App on a device is configured with the Appspace server’s hostname for app signaling. By default, this hostname is also used for fetching content, however, it can be overridden to support a CDN. The caching solution discussed herein is specifically for app content retrieval traffic.

Content Proxy/Caching Node Hostname Explanation

A reverse caching server can expose one of the following two types of hostnames:

• The source server’s hostname while keeping the URLs the same for cached or source content.
• The caching server’s hostname while making the cached URL different from the source URL.

The Appspace platform utilizes the second approach, exposing a different hostname for the caching server and a different URL for the cached content. A reverse caching proxy software has many settings to control storage usage, bandwidth management, and such, which can be applied according to customer’s preference.

Implementing a Caching Strategy

To implement a caching strategy, the following steps are required (explained in detail in sections below):

1. Implement a single caching node, or constellation of nodes (content proxy), directed to Appspace.
2. Configure the network for DNS, SSL certificates, and other security settings.
3. Configure the Appspace App to retrieve content from the content proxy.

Content Proxy/Caching Node Setup

Reverse Proxy Recommendation

The solution that Appspace recommends for simplicity and reliability is Apache on Linux. The reverse proxy should meet the following requirements:

• Be accessible over the local network by hostname.
• (recommended) Support the HTTPS protocol.
• (required for HTTPS) Provide a SSL certificate trusted by endpoint devices.
• Support whitespace (%20) character in URLs.
• Interpret first path component in the request URL as an external web server hostname.
• Strip first path component from the URL.
• Relay content requests to the external Appspace server hostname.
• Provide access to hostnames in the following domains and their subdomains: 

• Cache responses in local storage.
• Perform cache cleanup to maintain free storage space. 

Apache on Linux or Windows

Apache is a powerful and popular open source web server software that can be deployed on Linux or Windows. The solution discussed here assumes Linux based deployments, however, it should work equally well on Windows, if that is preferred.

Network and Security Setup

SSL considerations

Reverse caching servers integrate into existing networks and fully utilize SSL capabilities. Reverse caching proxies terminate SSL connections and interpret request data. Because they operate on their own hostname, they need to have a separate certificate for this hostname.

[Client]  ---> [https://cache.customer.com/] ---> [Appspace]
    ^---------------------^       ^--------------------^
              SSL                           SSL

Appspace App Configuration

The Appspace App retrieves content using a URL that will be set when the device is registered with the Appspace platform. This address can be overridden to direct the app to an external content source, which could be a content caching node. All other Appspace traffic will continue to be directed to the default Appspace address. To override the content source location, these two addresses must be modified via device properties:

• CDN hostname
• CDN health verification URL (a ping URL)

When this option is used, the Appspace client will verify the CDN by pinging the ping URL. If successful, the client will begin downloading all content from the new CDN. Should this verification fail, the Appspace client will fall back to downloading content from the original Appspace CDN. The Appspace App will continue to retrieve timestamps, content scripts, device tasks, and alerts from Appspace directly.

To configure the device to use this proxy server, add the following device properties and value:

• Player.CDN.Service = https://<appspace-cache-host-name>/{{appspaceContentHost}}
• Player.CDN.pingfile = app/shared/images/nexusheader/header_appspace.png

Be sure to replace <appspace-cache-host-name> with the hostname of your caching server, but keep the {{appspaceContentHost}} component intact, as it will be automatically substituted with the proper Appspace server hostname based on the device’s configuration.

 

App Support

The HTML5-based Appspace App supports this functionality on all certified devices. This function is also supported on legacy Cisco DMP-4310, DMP-4400, and EDGE-300/340 devices. However, the legacy DirectX-based Appspace App does not support fetching content via an external CDN or caching node.

Conclusion

Please reach out to your Appspace representative to engage in a deeper discussion around configuration recommendations and best practices.