Overview

Improve your response time, while reducing server load and bandwidth needs by caching and reusing frequently-requested web pages, images, and web service calls.

Easily add keep-alive, filter or anonymize content requests, or add load balancing by adding a proxy layer.

Scales well on modern SMP hardware, handling 10s of thousands of requests per second.

APIs to write your own plug-ins to do anything from modifying HTTP headers to handling ESI requests to writing your own cache algorithm.

Handling over 400TB a day at Yahoo! both as forward and reverse proxies, Apache Traffic Server is battle hardened. Also visit our Customers page for some of our corporate users and supporters.

Learn More

Get Support

Having trouble with builds, configurations or are you getting errors you don’t understand? Subscribe to our Users Mailing List or join our #traffic-server channel on The ASF Slack workspace to get help! Use your @apache.org email address to automatically join. If you need a workspace invitation, contact us on our devevelop mailing list, or ask any ASF committer.

Can’t get your plugin to work? Have questions about the ATS code? Or maybe you have suggestions for improvements or new features? Get help from developers or start a discussion on our dev discussion list.

Report or confirm bugs or try out the latest patches from our Bug Tracker

Learn how to ask good questions, create useful bug reports and how to apply patches.

Get Involved

Subscribe and help out on the users Mailing List or simply share your usecase or experience. For sometimes speedier responses check out our Slack channel #traffic-server on The ASF Slack workspace.

Impress developers or help others by participating on our dev discussion list or follow the latest development on our commits list.

Report issues or bring patches to our Bug Tracker

Visit our wiki to see a list of Projects we are currently working on.

Learn how to create patches to the code or the documentation and how to debug Apache Traffic Server.

We’ve tagged github issues that have a low entrance barrier.

Web Resources

Installing, configuring and administrating Apache Traffic Server

Developing Apache Traffic Server plug-ins and how the code works

A running list of your most common questions

Collaboration and interesting topics around the project

Apache Traffic Server

Apache Traffic Server – модульный высокопроизводительный веб-сервер и кэширующий прокси-сервер, сравнимый по возможностям с nginx и Squid. Создан в Inktomi как коммерческий продукт Inktomi Traffic Server. Позже Inktomi была приобретена компанией Yahoo!, и Apache Traffic Server широко использовался для основных веб-сервисов Yahoo! (Sports, Mail, Finance). В июле 2009 Yahoo! передала программу с исходными текстами в проект Инкубатор Apache. 21 апреля 2010, статус Apache Traffic Server был повышен до полноценного проекта (TLP).

Производительность Apache Traffic Server может достигать 200 тысяч запросов в секунду на небольших объектах, хранящихся в кэше. На выставке Cloud Computing Expo 2009, представители Yahoo! заявили, что Apache Traffic Server обслуживает около 400 Тб трафика ежедневно, используя для этого всего 150 серверов. В Yahoo! Apache Traffic Server используется для публикации статического контента (изображения, JavaScript, CSS, HTML) и передачи запросов на динамический контент к классическим веб-серверам, таким как Apache HTTP Server.

Поддерживаемые протоколы Apache Traffic Server

Apache Traffic Server поддерживает следующие протоколы:

WCCP (Web Cache Communication Protocol);
HTTP/1.1
IPv4, IPv6

Основные области применения и особенности Apache Traffic Server

Уменьшение времени ответа, снижение нагрузки на сервер и сокращения внутреннего трафика за счёт повторного использования и кэширования отдачи часто запрашиваемых веб-страниц, изображений и обращений к веб-сервисам.

Поддержка keep-alive, фильтрации и анонимизации запросов контента, использования в качестве балансировщика нагрузки.

Высокая степень масштабируемости на современных многоядерных системах, способность обрабатывать на обычном оборудовании десятков тысяч запросов в секунду.

Доступен API для разработки плагинов, расширяющих функциональность, способных решать различные задачи, такие как изменение HTTP-заголовков и содержимого отдаваемого контента или создания обработчиков c реализацией поддержки новых протоколов.

Система проверена в промышленной эксплуатации и используется для отдачи сотен терабайт трафика.

Installing Traffic Server¶

Supported Platforms¶

Traffic Server Versioning¶

Before you get started with Traffic Server you may have to decide which version you want to use. Traffic Server follows the Semantic Versioning guidelines.

A complete version number is made of a version-triplet: MAJOR.MINOR.PATCH .

As of v4.0.0, there are no longer any development (or unstable) releases. All releases are considered stable and ready for production use. Releases within a major version are always upgrade compatible. More details are available on the New Release Processes wiki page.

Sometimes we speak of trunk, master or HEAD, all of which are used interchangeably. Trunk and master, or sometimes TIP or HEAD, refer to the latest code in a Git version control system (also referred to as a repository or Git repo). Master is always kept releasable, and compatible with the current major release version. Incompatible changes are sometimes committed on a next-major release branch; for example, we have the 5.0.x branch where changes incompatible with 4.x are managed.

Binary Distributions¶

Building From Source¶

Retrieving Tarballs¶

Compressed archives of the source code for Traffic Server are available on the official website’s Downloads page. From there you may select the version most appropriate for your needs. The Traffic Server project does not provide binary downloads.

Cloning from Version Control¶

Traffic Server uses a public Git repository for version control. This repository will also provide the most cutting edge source code if you wish to test out the latest features and bug fixes.

We do also have a GitHub Mirror that you may use to submit pull requests. However, it may not be entirely up-to-date, and you should always refer to our official project Git repository for the very latest state of the source code.

Build Dependencies¶

In order to build Traffic Server from source you will need the following development tools and libraries installed:

gcc (>= 4.3 or clang > 3.0)

openssl (libssl-dev for Ubuntu 16.04)

pcre (libpcre3-dev for Ubuntu 16.04)

flex (for TPROXY)

curses (for traffic_top)

curl (for traffic_top)

If you’re building from a git clone, you’ll also need:

build-essential (for Ubuntu)

libtool (for Ubuntu)

Layouts¶

Preparing the Source Tree¶

If you are building from a checkout of the Git repository, you will need to prepare the source tree by regenerating the configuration scripts. This is performed by running:

At the base directory of your local clone.

Configuration Options¶

Traffic Server uses the standard configure script method of configuring the source tree for building. A full list of available options may always be obtained by running the following in the base directory of your unpackaged archive or Git working copy:

A configure script will be generated from configure.ac which may now be used to configure the source tree for your build.

By default, Traffic Server will be built to use the nobody user and group. You may change this with the —with-user argument to configure :

If dependencies are not in standard paths ( /usr/local or /usr ), you may need to pass options to configure to account for that:

Most configure path-options accept a format of “INCLUDE_PATH:LIBRARY_PATH”:

Once the source tree has been configured, you may proceed on to building with the generated Makefiles. The make check command may be used to perform sanity checks on the resulting build, prior to installation, and it is recommended that you use this.

With the source built and checked, you may now install all of the binaries, header files, documentation, and other artifacts to their final locations on your system.

Finally, it is recommended that you run the regression test suite. Please note that the regression tests will only be successful with the default layout.

Start Traffic Server¶

To start Traffic Server manually, issue the trafficserver command, passing in the subcommand start . This command starts all the processes that work together to process Traffic Server requests as well as manage, control, and monitor the health of the Traffic Server system.

The traffic_ctl provides a quick way of viewing Traffic Server statistics and configuring the Traffic Server system via a command-line interface.

traffic_ctl commands take the following form:

For a list of traffic_ctl commands, enter:

Please note that traffic_ctl, while a fine tool for administrators, is a poor choice for automation, especially that of monitoring. See our chapter on monitoring for how to do that more efficiently and effectively.

Stop Traffic Server¶

To stop Traffic Server, always use the trafficserver command, passing in the attribute stop . This command stops all the Traffic Server processes ( traffic_manager and traffic_server). Do not manually stop processes, as this can lead to unpredictable results.

Getting Started¶

Introduction¶

Apache Traffic Server™ provides a high-performance and scalable software solution for both forward and reverse proxying of HTTP/HTTPS traffic, and may be configured to run in either or both modes simultaneously. This Getting Started guide explains the basic steps an administrator new to Traffic Server will need to perform to get the software up and running in a minimal configuration as quickly as possible.

Example Scenario¶

In this guide, we will use the fictional company Acme Widgets as a basis for the configuration examples. Acme Widgets has a product brochure website (assumed to reside at the domain www.acme.com ) that performs very poorly. The content management software they chose takes an unbearable amount of time to generate pages on every request and their engineering team has chosen Traffic Server as a caching proxy layer to improve site performance.

Separately, Acme Widgets has decided to use Traffic Server to help improve the performance of their office’s Internet access, which is hobbled by their reliance on an aging leased line and certain employees’ predilection for extracurricular web browsing.

Terminology¶

This guide uses some terms which may be unfamiliar to administrators new to proxy servers.

The server which generates the content you wish to proxy (and optionally cache) with Traffic Server. In a forward proxy configuration, the origin server may be any remote server to which a proxied client attempts to connect. In a reverse proxy configuration, the origin servers are typically a known set of servers for which you are using Traffic Server as a performance-enhancing caching layer.

A reverse proxy appears to outside users as if it were the origin server, though it does not generate the content itself. Instead, it intercepts the requests and, based on the configured rules and contents of its cache, will either serve a cached copy of the requested content itself, or forward the request to the origin server, possibly caching the content returned for use with future requests.

A forward proxy brokers access to external resources, intercepting all matching outbound traffic from a network. Forward proxies may be used to speed up external access for locations with slow connections (by caching the external resources and using those cached copies to service requests directly in the future), or may be used to restrict or monitor external access.

A transparent proxy may be either a reverse or forward proxy (though nearly all reverse proxies are deployed transparently), the defining feature being the use of network routing to send requests through the proxy without any need for clients to configure themselves to do so, and often without the ability for those clients to bypass the proxy.

For a more complete list of definitions, please see the Glossary .

Installation¶

As with many other software packages, you may have the option of installing Apache Traffic Server™ from your operating system distribution’s packages, or compiling and installing from the source code yourself. Distribution packages may lag behind the current stable release of Traffic Server, sometimes by a significant amount. While we will cover briefly the packages required for common operating system distributions, the remainder of this guide will be assuming the latest stable release of Traffic Server when discussing configuration parameters and available features.

Installing From Distribution Packages¶

It is recommended that you install from source code, as described in the section below, rather than rely on your distribution’s packages if you wish to have access to the latest features and fixes in Traffic Server.

Ubuntu¶

The Canonical repositories up through, and including, Utopic Unicorn only provide Traffic Server v3.2.x.

RHEL / CentOS¶

Traffic Server is available through the EPEL repositories. If you do not have those configured on your machine yet, you must install them first with the following:

Ensuring that you replace the release number with a value that is appropriate for your system. Once you have EPEL installed, you may install Traffic Server itself.

OmniOS (illumos)¶

OmniOS (an illumos-based distribution) provides the Traffic Server package in its public OmniTI-MS publisher.

The latest release published, at the time of this writing, is Traffic Server v4.2.1.

Installing From Source Code¶

To install from source code, you will need to have the following tools and libraries on the machine used to build Traffic Server:

gcc (>= 4.3 or clang > 3.0)

flex (for TPROXY)

curses (for traffic_top)

curl (for traffic_top)

To build Traffic Server from a Git clone (the method we will be using in this guide), you will also need the following:

In this guide, Traffic Server will be built to use the default nobody user and group and will be installed to /opt/ts . It is assumed that all of the dependencies are located in standard paths. If this is not the case, you may need to use the appropriate —with-

options as detailed in the output of ./configure —help .

Clone the repository (you may skip this if you have downloaded an archive of the source code to build a specific official release of Traffic Server instead of the HEAD from source control):

Change to the cloned (or unarchived) directory:

If you have cloned the repository from Git, you will need to generate the configure script before proceeding:

Configure the source tree:

Build Traffic Server with the generated Makefiles, and test the results:

Install Traffic Server to the configured location:

Optionally, you may find it prudent to run the regression tests on your newly installed Traffic Server:

Configuration¶

We will be tackling two separate configuration scenarios in the following sections. The first is the most common application of a performance-enhancing caching proxy for externally-facing websites, a transparent and caching reverse proxy which forwards all requests presented to it to a single origin address and caches the responses based on their cache control headers (as well as some simple heuristics for specific content types when cache control headers are not present).

The second configuration we will review is a very basic transparent forward proxy, typically used in situations where you either need to improve the performance of a local network’s use of external resources, or you wish to have the capability of monitoring or filtering the traffic.

Configuring A Reverse Proxy¶

A minimal reverse proxy configuration requires changes to only a few configuration files, which will all be located in the /opt/ts/etc/trafficserver directory if you have configured your installation per the instructions in Installing From Source Code above.

For these examples, we will be assuming that Traffic Server is running on the same host machine as the origin website. This is not a requirement, and you may choose to run Traffic Server on an entirely different host, even connected to entirely different networks, as long as Traffic Server is able to reach the origin host.

Enable Reverse Proxying¶

Within the records.config configuration file, ensure that the following settings have been configured as shown below:

Enables caching of proxied HTTP requests.

Enables reverse proxying support.

This setting requires that a remap rule exist before Traffic Server will proxy the request and ensures that your proxy cannot be used to access the content of arbitrary websites (allowing someone of malicious intent to potentially mask their identity to an unknowing third party).

This setting causes Traffic Server to keep the Host: client request header intact which is necessary in cases where your origin servers may be performing domain-based virtual hosting, or taking other actions dependent upon the contents of that header.

This configures Traffic Server to bind itself to the port 8080 for HTTP traffic, for both IPv4 and IPv6.

Configure Origin Location¶

The previous settings enable reverse proxying (and prevent flagrant abuse of it), but now Traffic Server needs to know what to proxy. This is achieved by writing remap rules, which make use of the core Configuration Remap Plugin . For our Getting Started guide’s Acme Widgets example scenario, we have very simple needs and want little more than to proxy all requests to our single origin server. This is accomplished with the following rule added to the remap.config configuration:

With this mapping rule, all paths that Traffic Server receives with a Host: header of www.acme.com will be proxied to localhost:80 . For instance, a request for http://www.acme.com/foo/bar will be proxied to http://localhost:80/foo/bar , while requests with other Host: headers will be rejected.

It is worth pausing at this point to note that in a reverse proxying scenario, it is Traffic Server itself which should be responding to HTTP requests made to your public domain. While you first configure and evaluate whether Traffic Server will meet your needs, your origin server will continue to reside at the public-facing domain name on the default ports, should you move your Traffic Server configuration into production your DNS records for the domain(s) you wish to proxy and cache should resolve to the host(s) running Traffic Server (in the event that you run it on a separate host from your origin). Your origin should be accessible at a different address (or bind to different ports if you are running both your origin service and Traffic Server on the same host) and should no longer receive requests sent to the primary domain on its default ports.

In our Acme Widgets scenario, they ultimately decide to deploy Traffic Server at which point, since they are running both Traffic Server and their origin web server on the same host, they reconfigure their origin service to listen on port 8080 instead of the default, and change Traffic Server to bind to 80 itself. Updating the remap is thus required, and it should now be:

Now all requests made to www.acme.com are received by Traffic Server which knows to proxy those requests to localhost:8080 if it cannot already serve them from its cache. Because we enabled pristine host headers earlier, the origin service will continue to receive Host: www.acme.com in the HTTP request.

If Acme Widgets decides to use Traffic Server to reverse proxy a second domain static.acme.com with a different origin server than the original, they need to make further changes, as a new remap line needs to be added to handle the additional domain:

If they also decide to have requests to www.acme.com with paths that start with /api to a different origin server. The api origin server shouldn’t get the /api , they will remap it away. And, since the above remap rules catch all paths, this remap rule needs to be above it:

With this remap rule in place, a request to http://www.acme.com/api/example/foo will be proxied to http://api-origin.acme.com/example/foo .

Finally, if Acme Widgets decides to secure their site with https, they will need two additional remap rules to handle the https requests. Traffic Server can translate an inbound https request to an http request to origin. So, they would have additional remap rules like:

This will require installing a certificate, and adding a line to ssl_multicert.config . Assuming the cert has the static.acme.com alternate name, and that cert should be presented by default:

Further information about configuring Traffic Server for TLS can be found SSL Termination section of the documentation.

Adjust Cache Parameters¶

The default Traffic Server configuration will provide a 256 MB disk cache, located in var/trafficserver/ underneath your install prefix. You may wish to adjust either or both of the size and location of this cache. This is done with the storage.config configuration file. In our example, Acme Widgets has dedicated a large storage pool on their cache server which is mounted at /cache . To use this, and to disable the default cache storage setting, the following will be the sole entry in storage.config :

Changes to the cache configuration require a restart of Traffic Server.

You may also wish to use raw devices, or partition your cache storage. Details on these features may be found in the Proxy Cache Configuration section of the Administrator’s Guide.

Final Configurations¶

Once completed, the following configuration files for Acme Widgets contain the following entries: