Administrators’ Guide¶

Traffic Server as a Web Proxy Cache¶

As a web proxy cache, Traffic Server receives user requests for web content as those requests travel to the destined web server (origin server). If Traffic Server contains the requested content, then it serves the content directly. If the requested content is not available from cache, then Traffic Server acts as a proxy: it obtains the content from the origin server on the user’s behalf and also keeps a copy to satisfy future requests.

Traffic Server provides explicit proxy caching, in which the user’s client software must be configured to send requests directly to Traffic Server. Explicit proxy caching is described in the Explicit Proxy Caching chapter.

Traffic Server as a Reverse Proxy¶

As a reverse proxy, Traffic Server is configured to be the origin server to which the user is trying to connect (typically, the origin server’s advertised hostname resolves to Traffic Server, which acts as the real origin server). The reverse proxy feature is also called server acceleration. Reverse proxy is described in more detail in Reverse Proxy and HTTP Redirects.

Traffic Server in a Cache Hierarchy¶

Traffic Server can participate in flexible cache hierarchies, in which Internet requests not fulfilled from one cache are routed to other regional caches, thereby leveraging the contents and proximity of nearby caches. In a hierarchy of proxy servers, Traffic Server can act either as a parent or a child cache to other Traffic Server systems or to similar caching products.

Traffic Server supports ICP (Internet Cache Protocol) peering. Hierarchical caching is described in more detail in Hierarchical Caching.

Deployment Limitations¶

There’s a number of deployment options that Traffic Server does not support right out of the box. Such funcionality may be implemented in a plugin, but in some cases Traffic Server’s internal APIs or architectural restrictions won’t make it easy:

• Load Balancing - note that there is an experimental plugin for this: Balancer Plugin.

The Traffic Server Cache¶

The Traffic Server cache consists of a high-speed object database called the object store. The object store indexes objects according to URLs and associated headers. Using sophisticated object management, the object store can cache alternate versions of the same object (perhaps in a different language or encoding type). It can also efficiently store very small and very large objects, thereby minimizing wasted space. When the cache is full, Traffic Server removes stale data to ensure that the most requested objects are readily available and fresh.

Traffic Server is designed to tolerate total disk failures on any of the cache disks. If the disk fails completely, then Traffic Server marks the entire disk as corrupt and continues to use remaining disks. If all of the cache disks fail, then Traffic Server switches to proxy-only mode. You can partition the cache to reserve a certain amount of disk space for storing data for specific protocols and origin servers. For more information about the cache, see Configuring the Cache.

The RAM Cache¶

Traffic Server maintains a small RAM cache that contains extremely popular objects. This RAM cache serves the most popular objects as fast as possible and reduces load on disks, especially during temporary traffic peaks. You can configure the RAM cache size to suit your needs; for detailed information, refer to Changing the Size of the RAM Cache.

The Host Database¶

The Traffic Server host database stores the domain name server (DNS) entries of origin servers to which Traffic Server connects to fulfill user requests. This information is used to adapt future protocol interactions and optimize performance. Along with other information, the host database tracks:

• DNS information (for fast conversion of hostnames to IP addresses)
• The HTTP version of each host (so advanced protocol features can be used with hosts running modern servers)
• Host reliability and availability information (so users will not wait for servers that are not running)

The DNS Resolver¶

Traffic Server includes a fast, asynchronous DNS resolver to streamline conversion of hostnames to IP addresses. Traffic Server implements the DNS resolver natively by directly issuing DNS command packets rather than relying on slower, conventional resolver libraries. Since many DNS queries can be issued in parallel and a fast DNS cache maintains popular bindings in memory, DNS traffic is reduced.

Traffic Server Processes¶

Traffic Server contains three processes that work together to serve requests and manage/control/monitor the health of the system. The three processes are described below:

• The traffic_server process is the transaction processing engine of Traffic Server. It is responsible for accepting connections, processing protocol requests, and serving documents from the cache or origin server.

• The traffic_manager process is the command and control facility of the Traffic Server, responsible for launching, monitoring, and reconfiguring the traffic_server process. The traffic_manager process is also responsible for the proxy autoconfiguration port, the statistics interface, cluster administration, and virtual IP failover.

  If the traffic_manager process detects a traffic_server process failure, it instantly restarts the process but also maintains a connection queue of all incoming requests. All incoming connections that arrive in the several seconds before full server restart are saved in the connection queue and processed in first-come, first-served order. This connection queueing shields users from any server restart downtime.

• The traffic_cop process monitors the health of both the traffic_server and traffic_manager processes. The traffic_cop process periodically (several times each minute) queries the traffic_server and traffic_manager process by issuing heartbeat requests to fetch synthetic web pages. In the event of failure (if no response is received within a timeout interval or if an incorrect response is received), traffic_cop restarts the traffic_manager and traffic_server processes.

The figure below illustrates the three Traffic Server processes.

Illustration of the three Traffic Server Processes

Administration Tools¶

Traffic Server offers the following administration options:

• The Traffic Line command-line interface is a text-based interface from which you can monitor Traffic Server performance and network traffic, as well as configure the Traffic Server system. From Traffic Line, you can execute individual commands or script a series of commands in a shell.
• The Traffic Shell command-line interface is an additional command-line tool that enables you to execute individual commands that monitor and configure the Traffic Server system.
• Various configuration files enable you to configure Traffic Server through a simple file-editing and signal-handling interface. Any changes you make through Traffic Line or Traffic Shell are automatically made to the configuration files as well.
• Finally there is a clean C API which can be put to good use from a multitude of languages. The Traffic Server Admin Client demonstrates this for Perl.