Apache Trafficserver

Tuesday November 01, 2016

The Apache Traffic Server Project’s Next Chapter

By Bryan Call, Apache Traffic Server PMC Chair, Yahoo Distinguished Software Engineer

Last week, the ATS Community held a productive and informative Apache Traffic Server (ATS) Fall Summit, hosted by LinkedIn in Sunnyvale CA. At a hackathon during the Summit, we fixed bugs, cleaned up code, users were able to spend time with experts on ATS and have their questions answered, and the next release candidate for ATS 7.0.0 was made public. There were talks on operations, new and upcoming features, and supporting products. More than 80 people registered for the event and we had a packed room with remote video conferencing.

I have been attending the ATS Summits since their inception in 2010 and have had the pleasure of being involved with the Apache Traffic Server Project for the last nine years. I was also part of the team at Yahoo that open sourced the code to Apache. Today, I am honored to serve as the new Chair and VP of the ATS Project, having been elected to the position by the ATS community a couple weeks ago [1].

Traffic Server was originally created by Inktomi and distributed as a commercial product. After Yahoo acquired Inktomi, Yahoo open sourced Traffic Server and submitted it to the Apache Incubator in July 2009.

Since graduating as Apache Traffic Server (an Apache Top-Level Project as of April 2010), many large and small companies use it for caching and proxying HTTP requests. ATS supports HTTP/2, HTTP/1.1, TLS, and many other standards. The Apache Committers on the project are actively involved with the Internet Engineering Task Force (IETF) – whose mission it is to “make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet” – to make sure ATS is able to support the latest standards going forward.

Many companies have greatly benefited from the open sourcing of ATS; numerous industry colleagues and invested individuals have improved the project by fixing bugs and adding features, tests, and documentation. An example is Yahoo, which uses ATS for nearly all of its incoming HTTP/2 and HTTP/1.1 traffic. It is a common layer that all users go through before making a request to the origin server. Having a common layer has made it easier for Yahoo to deploy security fixes and updates extremely quickly. ATS is used as a caching proxy in locations worldwide and is also used to proxy requests for dynamic content from remote locations through already-established persistent connections. This decreases the latency for users when their cacheable content can be served, and connection establishments can be made to a nearby server.

The ATS PMC and I will focus on continuing to increase the ATS user base and having more developers contribute to the project. The ATS community welcomes other companies’ contributions and enhancements to the software through a well-established process with Apache. Unlike other commercial products, ATS has no limits or restrictions with accepting open source contributions.

Moving forward, we would also like to focus on three specific areas of ATS as a means of increasing the user base, while maintaining the performance advantage of the server: ease of use, features, and stability.

I support the further simplification of the configuration of ATS to make it so that end users can quickly get a server up with little effort. Common requirements should be easy to configure, while continuing to allow users to write custom plugins for more advanced requirements.

Adding new features to ATS is important and there are a lot of new drafts and standards currently being worked on in IETF with HTTP, TLS, and QUIC that will improve user experience. ATS will need to continue to support the latest standards that allow deployments of ATS to decrease the latency for the users. Having our developers attend the IETF meetings and participate in the decision-making is key to our ability to keep on top of these latest developments.

Stability is a fundamental requirement for a proxy server. Since all the incoming HTTP/2 and HTTP/1.1 traffic is handled by the server, it must be stable and resilient. We are continually working on improving our continuous integration and testing. We are making it easier for developers to write testing and run tests before making contributions to the code.

The ATS community is a welcoming group of people that encourages contributions and input from users, and I am excited to help lead the Project into its next chapter. Please feel free to join the mailing lists, attend one of our events such as the recent ATS Summit, or jump on IRC to talk to the users and developers of this project. We invite you to learn more about ATS at http://trafficserver.apache.org.

Monday September 21, 2015

Fall 2015 Apache Traffic Server Summit (Nov 15-17th)

The ATS community is pleased to announce the next Apache Traffic Server Summit. This time, we’ll be hosting this event at the Yahoo! Campus in Sunnyvale, California. The dates are

Sunday November 15th: Hackathon / Bug bashing / get-together
Monday November 16th: First day Summit with presentations from various teams
Tuesday November 17th: Second day Summit, focusing more on discussion items and designs

Everyone is very, very welcome to participate in this event, and there are no fees (however, we ask everyone to RSVP, see below). Previous Summits have been a good mix of system administration topics around ATS, advanced topics of usage and problems, as well as future discussions around direction and features of ATS.

Request: We are looking for people to present topics for the Monday - Tuesday events. If you have something ATS related to share, or something to discuss / propose / analyze, please submit a proposal with a Subject and 1-2 paragraph description. Send such proposals to 


Proposal does not have to be code related, in fact, some of the most interesting and popular topics from previous Summits have been around ATS use cases. The deadline for submissions is October 15st, 2015.

Finally, please RSVP on this page (which is still work in progress, we’ll update the schedule as we get the proposals submitted).:


Wednesday November 20, 2013

Traffic Server Documentation now officially on ReadTheDocs

Today we have officially moved Apache Traffic Server's documentation over to Read the Docs.

We have worked for quite some time now to move all of our documentation to Sphinx and into the git repository. This makes it simpler for both developers and users to contribute documentation updates.

Perhaps my favourite feature of RTD is how versatile they are. We now build the HTML with the Reference documentation from the same source we build the man pages. We can output epub and PDF, which you can download from the site. Best of all: It looks perfect on mobile devices.

Enjoy our new docs: http://trafficserver.readthedocs.org/

Wednesday September 04, 2013

Custom logs and identifying remap rules

In a recent project we worked on, we needed to add a custom log which also had to identify which exactly remap rule triggered. I think this is probably a worthwhile feature to add to ATS (see https://issues.apache.org/jira/browse/TS-2181), but there's an easy way using existing plugins to accomplish this. Using (for example) the header_filter.so standard plugin, you can setup a config for each remap rule that you wish to identify.

    map http://www.example.com http://x.example.com @plugin=header_filter.so @pparam=id_a.config 

Where id_a.config contains simply

        @MapID =a_mapping= 

 In a custom log, you can then log this as


Voila! The trick here is that headers with the @ prefix are considered internal to ATS, and are removed before sending to servers or User-Agents.

Friday August 30, 2013

v4.0.1 is finally here!

The Apache Traffic Server community is extremely pleased to announce the immediate availability of our next major release, v4.0.1! This is the culmination of a years worth of work on features and bug fixes. Some fun facts about this release:

  • There are contributions from 59 individuals
  • Over 1,300 commits
  • 446 Jira tickets were closed

Upgrading from v3.0 or v3.2 to v4.0 should be done with care, since the cache is not backwards compatible. This means upgrading will cause the cache to be reinitialized. More details is available at the Upgrade to v4.0 wiki page. There's a number of new features in this release, the highlights from the Wiki includes: 

  • Assign URLs to specific storage units.
  • HTTP transaction buffering control
  • CPU thread affinity
  • Cache empty documents
  • Fast Range: request handling
  • More plugin and remap overridable configurations
  • Lifecycle hooks for plugins
  • A couple of new plugins, including a gzip plugin

Finally, this release marks a new milestone in how we will manage future release. This is documented in our new release proposal, please take a look at it, but the basic points are

  • We follow strict Semantic Versioning, ever release within a major version is guaranteed to be API, ABI, cache and functionally backward compatible.
  • We promise to bump major version at the most once per year (annually)
  • We will produce minor releases on a strict quarterly schedule: May, August, November and February.
  • The Git master branch is intended to be kept stable and releasable at all times. This implies that master can be seen as the daily current development release, and there are no more official development releases.

On the behalf of the entire Apache Traffic Server community, we hope you find this release to be useful and rock solid!

Tuesday July 30, 2013

Apache Traffic Server v3.2.5 Released

The Apache Software Foundation and the Apache Traffic Server project are pleased to announce the release of Apache Traffic Server v3.2.5.

This is primarily a maintenance release, fixing minor SSL issue, as well as some build issues to make our package maintainers lives easier. We encourage Traffic Server users to upgrade - and everybody else to try it out!

The source code is immediately available for download.

Thursday June 27, 2013

Squid binary log with unmapped URL

The Squid log format that we have by default in Traffic Server is a standard format that works well for proxies. It's also well supported by existing log analyzers etc. However, in some cases, where you map many domains to one origin server, the logs produced aren't particularly useful. Why? Because the default Squid log format logs the remapped URL, and not the original client URL. There is of course an easy way to fix this, using our custom log formats.

  1. Disable the original Squid log format, and enable the custom logs.
  2. Create the new Squid log format in logs_xml.config

Details below!

-- Leif


CONFIG proxy.config.log.logging_enabled INT 3
CONFIG proxy.config.log.custom_logs_enabled INT 1
CONFIG proxy.config.log.squid_log_enabled INT 0 


  <Name = "squid_unmapped"/>
  <Format = "%<cqtq> %<ttms> %<chi> %<crc>/%<pssc> %<psql> %<cqhm> %<cquuc> %<caun> %<phr>/%<pqsn> %<psct> %<xid>"/>

  <Format = "squid_unmapped"/>
  <Filename = "squid"/>
  <Mode = "binary"/>

Saturday June 22, 2013

How Comcast built a CDN using Traffic Server

At the 2013 Content Delivery Summit, Jan van Doorn gave a really interesting talk about how Comcast built an open source content delivery network with Apache Traffic Server at its core. Both the video of the talk and the slides are online.

In the talk, Jan covers the major parts of the Comcast CDN: the cache, configuration management, content routing and utilization monitoring. This is a great overview for anyone who is interested in building a CDN. There's enough open source out there that this should be practical for almost any organization.

The static tiered caching support that Comcast developed for this project landed in the Traffic Server 3.3.4 release, so you can experiment with it today.

Saturday May 25, 2013

BarCamp in Denver, July 9-10th

From the mailing lists announcements:

It's our pleasure to announce the next US Apache Traffic Server BarCamp! 
It will be held in downtown Denver, gracefully hosted by Comcast. It's a 
two day event, going all day from July 9th to July 10th. We will work on 
code, share experiences, come up with clever ideas, and help anyone who 
has questions or problems. This is a "DevOps" event, so even if you are 
not a hard-code C++ template wizard, you can participate (so I'm 
definitely going to be there).

Please RSVP to zwoop@apache.org before June 15th, we'll send more 
details with directions etc. once we have a better idea how many people 
are participating. A few of us living in Denver can help with 
accommodations  and travel to and from the airport as necessary.


-- The Traffic Server PMC

Friday May 03, 2013

Apache Traffic Server over 4% market share

Thanks to Go Daddy switching from IIS to Apache Traffic Server (good choice!) we're now at around 4.2% market share according to Netscraft's latest survey. We're combined with Apache in general, so we helped Apache gain one of the largest market share increases in recent history. The study is available at http://news.netcraft.com/archives/2013/05/03/may-2013-web-server-survey.html.

Monday February 11, 2013

Traffic Server hackathon at ApacheCon 2013

ApacheCon will be hosting the conference hackathon on Monday February 25th, and the Traffic Server team will be there. There will be almost a dozen Traffic Server committers in attendance. We will be discussing the Traffic Server feature roadmap, hacking on bugs and generally trying to make Traffic Server better. Come by and tell us about your favorite bug (or feature)!

Sunday January 13, 2013

Traffic Server at ApacheCon NA 2013

[Read More]

Saturday December 15, 2012

Choosing an Open Source Proxy

Leif previously posted about his talk at Lisa 2012. I hope that everyone who was able to attend enjoyed it and learned something about the open source web proxy ecosystem. For everyone else, here are the slides, which are pretty interesting. If I ever find any video of the talk, I'll post that as well.

Usenix LISA 2012 - Choosing a Proxy from Leif Hedstrom

Wednesday December 05, 2012

Rolling the D2O: Choosing an Open Source HTTP Proxy Server

In a week or so, I'll be presenting a talk at Usenix LISA '12, titled "Rolling the D20: Choosing an Open Source HTTP Proxy Server". The talk is an attempt to educate the audience not only in what technologies are out there, but also how to pick and choose one that's right for their problem. This will obviously include Apache Traffic Server, but of course other prominent proxies such as Varnish, Squid and Nginx will be examined. I'm hoping to see some of you there, and I'd be very interested to learn more about what is good (and bad) with the current state of affairs when it comes to proxies and caches.

Wednesday November 21, 2012

Arno Töll is a new Traffic Server committer

We are welcoming another committer to the Traffic Server community today. Arno Töll has been working hard on packaging Traffic Server for Debian. Distribution packaging is very important because it really makes it easier for people to try out a piece of software. Arno's blog post introducing Traffic Server is probably the best article I have seen for new Traffic Server users, http://daemonkeeper.net/735/apache-trafficserver-the-better-web-cache/ .



Hot Blogs (today's hits)

Tag Cloud