Glossary

302 content routing
HTTP Content Routing.
astats (stats_over_http)
An ATS plugin that allows you to monitor vitals of the ATS server. See Cache Monitoring.
Cache Group

A group of caching HTTP proxy servers that together create a combined larger cache using consistent hashing. Traffic Router treats all servers in a Cache Group as though they are in the same Physical Location, though they are in fact only in the same general area. A Cache Group has one single set of geographical coordinates even if the cache servers that make up the Cache Group are actually in Physical Locations. The cache servers in a Cache Group are not aware of the other cache servers in the group - there is no clustering software or communications between cache servers in a Cache Group.

There are two basic types of Cache Groups: EDGE_LOC and MID_LOC (“LOC” being short for “location” - a holdover from when Cache Groups were called “Cache Locations). Traffic Control is a two-tiered system, where the clients get directed to the Edge-tier (EDGE_LOC) Cache Group. On cache miss, the cache server in the Edge-tier Cache Group obtains content from a Mid-tier (MID_LOC) Cache Group, rather than the origin, which is shared with multiple Edge-tier Cache Groups. Edge-tier Cache Groups are configured to have a single “parent” Cache Group, but in general Mid-tier Cache Groups have many “children”.

Note

Often the Edge-tier to Mid-tier relationship is based on network distance, and does not necessarily match the geographic distance.

See also

A Cache Group serves a particular part of the network as defined in the coverage zone file. See The Coverage Zone File and ASN Table for details.

Consider the example CDN in Fig. 36. Here some country/province/region has been divided into quarters: Northeast, Southeast, Northwest, and Southwest. The arrows in the diagram indicate the flow of requests. If a client in the Northwest, for example, were to make a request to the Delivery Service, it would first be directed to some cache server in the “Northwest” Edge-tier Cache Group. Should the requested content not be in cache, the Edge-tier server will select a parent from the “West” Cache Group and pass the request up, caching the result for future use. All Mid-tier Cache Groups (usually) answer to a single origin that provides canonical content. If requested content is not in the Mid-tier cache, then the request will be passed up to the origin and the result cached.

An illustration of Cache Group hierarchy

Fig. 36 An example CDN that shows the hierarchy between four Edge-tier Cache Groups, two Mid-tier Cache Groups, and one Origin

cache server

The main function of a CDN is to proxy requests from clients to origin servers and cache the results. To proxy, in the CDN context, is to obtain content using HTTP from an origin server on behalf of a client. To cache is to store the results so they can be reused when other clients are requesting the same content. There are three types of proxies in use on the Internet today:

  • Reverse Proxy: Used by Traffic Control for Edge-tier cache servers.
  • Forward Proxy: Used by Traffic Control for Mid-tier cache servers.
  • Transparent Proxy: These are not used by Traffic Control. If you are interested you can learn more about transparent proxies on wikipedia.
consistent hashing
See the Wikipedia article; Traffic Control uses consistent hashing when using HTTP Content Routing for the edge tier and when selecting parents in the mid tier.
content routing
Directing clients (or client systems) to a particular location or device in a location for optimal delivery of content See also HTTP Content Routing and DNS Content Routing.
Coverage Zone File
Coverage Zone Map
The CZM or CZF is a file that maps network prefixes to Cache Groups. Traffic Router uses the CZM to determine what Cache Group is closest to the client. If the client IP address is not in this CZM, it falls back to geographic mapping, using a MaxMind GeoIP2 database to find the client’s location, and the geographic coordinates from Traffic Ops for the Cache Group. Traffic Router is inserted into the HTTP retrieval process by making it the authoritative DNS server for the domain of the CDN Delivery Service. In the example of the reverse proxy, the client was given the http://www-origin-cache.cdn.com/foo/bar/fun.html URL. In a Traffic Control CDN, URLs start with a routing name, which is configurable per-Delivery Service, e.g. http://foo.mydeliveryservice.cdn.com/fun/example.html with the chosen routing name foo.
Delivery Service

Delivery Services are often referred to a reverse proxy “remap rule” that exists on Edge-tier cache servers. In most cases, a Delivery Service is a one-to-one mapping to an FQDN that is used as a hostname to deliver the content. Many options and settings regarding how to optimize the content delivery exist, which are configurable on a Delivery Service basis. Some examples of these Delivery Servicesettings are:

  • Cache in RAM, cache on disk, or do not cache at all.
  • Use DNS or HTTP Content routing.
  • Limits on transactions per second and bandwidth.
  • Protocol (HTTP or HTTPS).
  • Token-based authentication settings.
  • Header rewrite rules.

Since Traffic Control version 2.1, Delivery Services can optionally be linked to a Profile, and have Parameters associated with them. One example of a feature that uses Delivery Service Parameters is the Multi Site Origin configuration. Delivery Services are also for use in allowing multiple Tenants to coexist in the Traffic Control CDN without interfering with each other, and to keep information about their content separated.

Division
A group of Regions.
Edge
Edge-tier
Edge-tier cache
Edge-tier cache server
Closest to the client or end-user. The edge tier is the tier that serves the client, edge caches are caches in the edge tier. In a Traffic Control CDN the basic function of the edge cache is that of a reverse proxy.
forward proxy

A forward proxy acts on behalf of the client such that the origin server is (potentially) unaware of the proxy’s existence. All Mid-tier cache servers in a Traffic Control based CDN are forward proxies. In a forward proxy scenario, the client is explicitly configured to use the the proxy’s IP address and port as a forward proxy. The client always connects to the forward proxy for content. The content provider does not have to change the URL the client obtains, and is (potentially) unaware of the proxy in the middle.

If a client uses a forward proxy to request the URL http://www.origin.com/foo/bar/fun.html the resulting chain of events follows.

  1. To retrieve http://www.origin.com/foo/bar/fun.html, the client sends an HTTP request to the forward proxy.

    #509 Client Requests Content from its Forward Proxy
    GET http://www.origin.com/foo/bar/fun.html HTTP/1.1
    Host: www.origin.com
    

    Note

    In this case, the client requests the entire URL instead of just the path as is the case when using a reverse proxy or when requesting content directly from the origin server.

  2. The proxy verifies whether the response for http://www-origin-cache.cdn.com/foo/bar/fun.html is already in the cache. If it is not in the cache:

    1. The proxy sends the HTTP request to the origin.

      #510 The Forward Proxy Requests Content from the Origin Server
      GET /foo/bar/fun.html HTTP/1.1
      Host: www.origin.com
      
    2. The origin server responds with the requested content.

      #511 The Origin Server’s Response
      HTTP/1.1 200 OK
      Date: Sun, 14 Dec 2014 23:22:44 GMT
      Server: Apache/2.2.15 (Red Hat)
      Last-Modified: Sun, 14 Dec 2014 23:18:51 GMT
      ETag: "1aa008f-2d-50a3559482cc0"
      Content-Length: 45
      Connection: close
      Content-Type: text/html; charset=UTF-8
      
      <!DOCTYPE html><html><body>This is a fun file</body></html>
      
    3. The proxy sends this on to the client, optionally adding a Via: header to indicate that the request was serviced by proxy.

      #512 The Forward Proxy’s Response to the Client
      HTTP/1.1 200 OK
      Date: Sun, 14 Dec 2014 23:22:44 GMT
      Last-Modified: Sun, 14 Dec 2014 23:18:51 GMT
      ETag: "1aa008f-2d-50a3559482cc0"
      Content-Length: 45
      Connection: close
      Content-Type: text/html; charset=UTF-8
      Age: 0
      Via: http/1.1 cache01.cdn.kabletown.net (ApacheTrafficServer/4.2.1 [uScSsSfUpSeN:t cCSi p sS])
      Server: ATS/4.2.1
      
      <!DOCTYPE html><html><body>This is a fun file</body></html>
      

    If, however, the requested content was in the cache the proxy responds to the client with the previously retrieved result

    #513 The Forward Proxy Sends the Cached Response
    HTTP/1.1 200 OK
    Date: Sun, 14 Dec 2014 23:22:44 GMT
    Last-Modified: Sun, 14 Dec 2014 23:18:51 GMT
    ETag: "1aa008f-2d-50a3559482cc0"
    Content-Length: 45
    Connection: close
    Content-Type: text/html; charset=UTF-8
    Age: 99711
    Via: http/1.1 cache01.cdn.kabletown.net (ApacheTrafficServer/4.2.1 [uScSsSfUpSeN:t cCSi p sS])
    Server: ATS/4.2.1
    
    <!DOCTYPE html><html><body>This is a fun file</body></html>
    
geo localization or geo routing
Localizing clients to the nearest caches using a geo database like the one from Maxmind.
Health Protocol
The protocol to monitor the health of all the caches. See Health Protocol.
localization
Finding location on the network, or on planet earth
Mid
Mid-tier
Mid-tier cache
Mid-tier cache server
The tier above the edge tier. The mid tier does not directly serves the end-user and is used as an additional layer between the edge and the origin. In a Traffic Control CDN the basic function of the mid cache is that of a forward proxy.
origin
origin server
The source of content for the CDN. Usually a redundant HTTP/1.1 webserver.
ORT
The “Operational Readiness Test” script that stitches the configuration configured in Traffic Portal and generated by Traffic Ops into the cache servers. See Configuring Traffic Server for more information.
Parameter
Typically refers to a line in a configuration file, but in practice can represent any arbitrary configuration option
parent
The parent(s) of a cache server is/are the cache server(s) belonging to either the “parent” or “secondary parent” Cache Group(s) of the Cache Group to which the cache server belongs. For example, in general it is true that an Edge-tier cache server has one or more parents which are Mid-tier cache servers.
Physical Location
A pair of geographic coordinates (latitude and longitude) that is used by Cache Groups to define their location. This information is used by Traffic Router to route client traffic to the geographically nearest Cache Group.
Profile

A Profile is, most generally, a group of Parameters that will be applied to a server. Profiles are typically re-used by all Edge-Tier cache servers within a CDN or Cache Group. A Profile will, in addition to configuration Parameters, define the CDN to which a server belongs and the “Type” of the profile - which determines some behaviors of Traffic Control components. The allowed “Types” of Profiles are not the same as Types, and are maintained as a PostgreSQL “Enum” in traffic_ops/app/db/migrations/20170205101432_cdn_table_domain_name.go. The only allowed values are:

UNK_PROFILE
A catch-all type that can be assigned to anything without imbuing it with any special meaning or behavior
TR_PROFILE

A Traffic Router Profile.

Warning

For legacy reasons, the names of Profiles of this type must begin with CCR_ or TR_. This is not enforced by the Traffic Ops API or Traffic Portal, but certain Traffic Control operations/components expect this and will fail to work otherwise!

TM_PROFILE

A Traffic Monitor Profile.

Warning

For legacy reasons, the names of Profiles of this type must begin with RASCAL_ or TM_. This is not enforced by the Traffic Ops API or Traffic Portal, but certain Traffic Control operations/components expect this and will fail to work otherwise!

TS_PROFILE

A Traffic Stats Profile

Warning

For legacy reasons, the names of Profiles of this type must begin with TRAFFIC_STATS. This is not enforced by the Traffic Ops API or Traffic Portal, but certain Traffic Control operations/components expect this and will fail to work otherwise!

TP_PROFILE

A Traffic Portal Profile

Warning

For legacy reasons, the names of Profiles of this type must begin with TRAFFIC_PORTAL. This is not enforced by the Traffic Ops API or Traffic Portal, but certain Traffic Control operations/components expect this and will fail to work otherwise!

INFLUXDB_PROFILE

A Profile used with InfluxDB, which is used by Traffic Stats.

Warning

For legacy reasons, the names of Profiles of this type must begin with INFLUXDB. This is not enforced by the Traffic Ops API or Traffic Portal, but certain Traffic Control operations/components expect this and will fail to work otherwise!

RIAK_PROFILE

A Profile used for each Riak server in a Traffic Stats cluster.

Warning

For legacy reasons, the names of Profiles of this type must begin with RIAK. This is not enforced by the Traffic Ops API or Traffic Portal, but certain Traffic Control operations/components expect this and will fail to work otherwise!

SPLUNK_PROFILE

A Profile meant to be used with Splunk servers.

Warning

For legacy reasons, the names of Profiles of this type must begin with SPLUNK. This is not enforced by the Traffic Ops API or Traffic Portal, but certain Traffic Control operations/components expect this and will fail to work otherwise!

ORG_PROFILE

Origin Profile.

Warning

For legacy reasons, the names of Profiles of this type must begin with MSO, or contain either ORG or ORIGIN anywhere in the name. This is not enforced by the Traffic Ops API or Traffic Portal, but certain Traffic Control operations/components expect this and will fail to work otherwise!

KAFKA_PROFILE

A Profile for Kafka servers.

Warning

For legacy reasons, the names of Profiles of this type must begin with KAFKA. This is not enforced by the Traffic Ops API or Traffic Portal, but certain Traffic Control operations/components expect this and will fail to work otherwise!

LOGSTASH_PROFILE

A Profile for Logstash servers.

Warning

For legacy reasons, the names of Profiles of this type must begin with LOGSTASH_. This is not enforced by the Traffic Ops API or Traffic Portal, but certain Traffic Control operations/components expect this and will fail to work otherwise!

ES_PROFILE

A Profile for ElasticSearch servers.

Warning

For legacy reasons, the names of Profiles of this type must begin with ELASTICSEARCH. This is not enforced by the Traffic Ops API or Traffic Portal, but certain Traffic Control operations/components expect this and will fail to work otherwise!

ATS_PROFILE

A Profile that can be used with either an Edge-tier or Mid-tier cache server` (but not both, in general).

Warning

For legacy reasons, the names of Profiles of this type must begin with EDGE or MID. This is not enforced by the Traffic Ops API or Traffic Portal, but certain Traffic Control operations/components expect this and will fail to work otherwise!

Tip

A Profile of the wrong type assigned to a Traffic Control component will (in general) cause it to function incorrectly, regardless of the Parameters assigned to it.

Danger

Nearly all of these Profile types have strict naming requirements, and it may be noted that some of said requirements are prefixes ending with _, while others are either not prefixes or do not end with _. This is exactly true; some requirements need that _ and some may or may not have it. It is our suggestion, therefore, that for the time being all prefixes use the _ notation to separate words, so as to avoid causing headaches remembering when that matters and when it does not.

Region
A group of Physical Locations.
reverse proxy

A reverse proxy acts on behalf of the origin server such that the client is (potentially) unaware it is not communicating directly with the origin. All Edge-tier cache servers in a Traffic Control CDN are reverse proxies. To the end user a Traffic Control-based CDN appears as a reverse proxy since it retrieves content from the origin server, acting on behalf of that origin server. The client requests a URL that has a hostname which resolves to the reverse proxy’s IP address and, in compliance with the HTTP 1.1 specification (RFC 2616), the client sends a Host: header to the reverse proxy that matches the hostname in the URL. The proxy looks up this hostname in a list of mappings to find the origin hostname; if the hostname of the Host: header is not found in the list, the proxy will send an error (usually either 404 Not Found or 503 Service Unavailable as appropriate) to the client. If the supplied hostname is found in this list of mappings, the proxy checks its cache, and when the content is not already present, connects to the origin to which the requested Host: maps requests the path of the original URL, providing the origin hostname in the Host header. The proxy then stores the URL in its cache and serves the contents to the client. When there are subsequent requests for the same URL, a caching proxy serves the content out of its cache - provided Cache Control Headers and Revalidation are satisfied - thereby reducing latency and network traffic.

To insert a reverse proxy into a typical HTTP 1.1 request and response flow, the reverse proxy needs to be told where the origin server can be reached (and which origin to use for a given request when it’s configured to proxy requests for multiple origins). In ATS this is handled by adding rules to the remap.config configuration file. The content owner must inform the clients, by updating the URL, to receive the content from the cache and not from the origin server directly. For example, clients might be instructed to request content from http://www-origin-cache.cdn.com which points to a reverse proxy for the actual origin located at http://www.origin.com.

Now, if the client requests /foo/bar/fun.html from the reverse proxy the sequence of events is as follows. is given the URL http://www-origin-cache.cdn.com/foo/bar/fun.html (note the different hostname) and when attempting to obtain that URL, the following occurs:

  1. The client sends a DNS request to the LDNS to resolve the name www-origin-cache.cdn.com to an IP address.

  2. The LDNS finds an IP address for www-origin-cache.cdn.com e.g. 55.44.33.22.

  3. The client sends an HTTP request for /foo/bar/fun.html to the IP address.

    #514 Client Requests Content from the Reverse Proxy
    GET /foo/bar/fun.html HTTP/1.1
    Host: www-origin-cache.cdn.com
    
  4. The reverse proxy finds out the URL of the true origin - in the case of ATS this is done by looking up www-origin-cache.cdn.com in its remap rules - and finds that it is www.origin.com.

  5. The proxy checks its cache to see if the response for GET /foo/bar/fun.html HTTP/1.1 from www.origin.com is already in the cache.

  6. If the response is not in the cache:

    1. The proxy sends the request to the actual origin

      #515 Reverse Proxy Requests Content from the Origin Server
      GET /foo/bar/fun.html HTTP/1.1
      Host: www.origin.com
      
    2. The origin server responds with the requested content

      #516 Response from the Origin Server
      HTTP/1.1 200 OK
      Date: Sun, 14 Dec 2014 23:22:44 GMT
      Server: Apache/2.2.15 (Red Hat)
      Last-Modified: Sun, 14 Dec 2014 23:18:51 GMT
      ETag: "1aa008f-2d-50a3559482cc0"
      Content-Length: 45
      Connection: close
      Content-Type: text/html; charset=UTF-8
      
      <!DOCTYPE html><html><body>This is a fun file</body></html>
      
    3. The proxy sends the response on to the client, optionally adding a Via: header to indicate that the request was serviced by proxy.

      #517 Resulting Response from the Reverse Proxy to the Client
      HTTP/1.1 200 OK
      Date: Sun, 14 Dec 2014 23:22:44 GMT
      Last-Modified: Sun, 14 Dec 2014 23:18:51 GMT
      ETag: "1aa008f-2d-50a3559482cc0"
      Content-Length: 45
      Connection: close
      Content-Type: text/html; charset=UTF-8
      Age: 0
      Via: http/1.1 cache01.cdn.kabletown.net (ApacheTrafficServer/4.2.1 [uScSsSfUpSeN:t cCSi p sS])
      Server: ATS/4.2.1
      
      <!DOCTYPE html><html><body>This is a fun file</body></html>
      

    If, however, the response was already in the cache - and still valid according to the Cache Control Headers and Revalidation - the proxy responds to the client with the previously retrieved result.

    #518 The Reverse Proxy Provides a Cached Response
    HTTP/1.1 200 OK
    Date: Sun, 14 Dec 2014 23:22:44 GMT
    Last-Modified: Sun, 14 Dec 2014 23:18:51 GMT
    ETag: "1aa008f-2d-50a3559482cc0"
    Content-Length: 45
    Connection: close
    Content-Type: text/html; charset=UTF-8
    Age: 39711
    Via: http/1.1 cache01.cdn.kabletown.net (ApacheTrafficServer/4.2.1 [uScSsSfUpSeN:t cCSi p sS])
    Server: ATS/4.2.1
    
    <!DOCTYPE html><html><body>This is a fun file</body></html>
    
Role
Permissions Roles define the operations a user is allowed to perform, and are currently an ordered list of permission levels.
Snapshot
Previously called a “CRConfig” or “CRConfig.json” (and still called such in many places), this is a rather large set of routing information generated from a CDN’s configuration and topology.
Status
A Status represents the current operating state of a server. The default Statuses made available on initial startup of Traffic Ops are related to the Health Protocol and are explained in that section.
Tenant
Users are grouped into Tenants (or Tenancies) to segregate ownership of and permissions over Delivery Services and their resources. To be clear, the notion of Tenancy only applies within the context of Delivery Services and does not apply permissions restrictions to any other aspect of Traffic Control.
Type
A Type defines a type of some kind of object configured in Traffic Ops. Unfortunately, that is exactly as specific as this definition can be.