[HN Gopher] Apache Traffic Server
___________________________________________________________________
Apache Traffic Server
Author : nuerow
Score : 156 points
Date : 2021-11-02 10:30 UTC (1 days ago)
(HTM) web link (trafficserver.apache.org)
(TXT) w3m dump (trafficserver.apache.org)
| Semaphor wrote:
| Discussion in 2016 [0]
|
| My impression from the comments is, that at least back then, it
| could be faster than things like Nginx or Varnish
|
| [0]: https://news.ycombinator.com/item?id=10983331
| youngtaff wrote:
| AFAIK Netlify uses Apache Traffic Server for their 'CDN'
|
| (Vercel uses nginx)
| dig1 wrote:
| Although haproxy and nginx cover (for me) almost all use-cases I
| had to deal with (with OpenResty [1] as a backup), I see one
| place where ATS could shine: plugins. From examples [2], C API
| looks sane and well documented, and this is very important if you
| want to add some custom stuff inside your proxy server without
| losing your hair. And no, lua isn't the solution here ;)
|
| Those who had to deal with nginx plugins, I feel your pain...
|
| [1] https://openresty.org/en/
|
| [2]
| https://github.com/apache/trafficserver/tree/master/example/...
| VWWHFSfQ wrote:
| > And no, lua isn't the solution here
|
| why wouldn't Lua be a solution here?
| otterley wrote:
| Too slow for a proxy cache of ATS's caliber/audience.
| VWWHFSfQ wrote:
| I find that hard to believe. As far as I know,
| Nginx/Lua/LuaJIT still powers almost all of CloudFlares
| edge services.
|
| [1] https://blog.cloudflare.com/pushing-nginx-to-its-limit-
| with-...
|
| [2] https://blog.cloudflare.com/cloudflares-new-waf-
| compiling-to...
| lrem wrote:
| If YouTube finally off Python? ;)
| fanf2 wrote:
| As I understand it, Cloudflare's major use of LuaJIT was
| for their WAF, and they have recently rewritten it in
| Rust https://blog.cloudflare.com/new-cloudflare-waf/
| crazy5sheep wrote:
| Oh, this brought back a lot of good memory in Yahoo. This thing
| was originally called YTS, it has a very flexible plugin system,
| the caching functionality was pretty good and easy to use at the
| time.
| Thaxll wrote:
| Looks recent, at first I thought it was webserver from the
| 90's...
| Aachen wrote:
| Not sure if this is what you're thinking of, but to be clear,
| this isn't _the_ Apache web server (aka apache httpd or
| apache2).
| nuerow wrote:
| > _Looks recent, at first I thought it was webserver from the
| 90 's..._
|
| Well, old ideas are indeed new once everyone forgets they were
| a thing. Nowadays CDNs and edge caches and web accelerators are
| seeing a resurgence, and in practice they can mean having an
| instance of Apache Traffic Server deployed somewhere.
| cstivers1978 wrote:
| This was originally "Yahoo! Traffic Server", was developed by
| Yahoo! in the early 2000's and was used in part to power Yahoo!
| CDN. At the time Yahoo! relied on Akamai and its own network.
| cduzz wrote:
| It was developed by inktomi[1]; inktomi was acquired by yahoo
| in the one of the great extinction events of the early
| internet.
|
| [1]https://en.wikipedia.org/wiki/Inktomi
| mrweasel wrote:
| I kinda forgot the Traffic Server existed. I remember we looked
| at it 10 years ago for a project, but just went with nginx
| instead. I don't think we ever really saw the point in Traffic
| Server, and I still don't. That might just be because it solves
| a set of problems I don't deal with.
| [deleted]
| lumanaughty14 wrote:
| Almost everyone is an end user of Apache Traffic Server without
| really knowing it. It is used by Yahoo, Apple, Comcast,
| Wikipedia, AT&T, Cox and many other companies.
|
| Some companies that use it at very large scale don't like to talk
| about what technologies they use.
| therein wrote:
| Yup LinkedIn and Apple uses it very extensively. So is Yahoo.
|
| Been to many ATS meetups, even worked on atscppapi years ago.
| Very robust plugin capabilities.
| linsomniac wrote:
| While I'm a big fan of haproxy, Apache, and nginx, I will say I
| also very much like trafficserver as a cache. Compared to squid,
| which I've always wanted to like but never really have, it is
| much easier to set up, and it's proven to be very reliable in our
| use.
|
| Specifically, I install it, point it at a large raw disk
| partition, and drop in my config files (largely consisting of
| routing rules for where to get the origin based on the request),
| and trafficserver just goes to town. It's a perfect use case for
| the ephemeral storage on virtual instances.
| tyingq wrote:
| Lots of choices in the this space... - this tool
| (apache traffic server) - regular apache can
| proxy/cache/route - nginx - traefik - haproxy
| - envoy - kong - ...more
|
| Then it also somewhat intersects with less directly related
| things in other spaces, like squid, varnish, istio, and so on.
|
| Is there some document somewhere that goes over the choices,
| overlaps, etc?
| CameronNemo wrote:
| Istio is primarily just a wrapper around Envoy, no?
| handrous wrote:
| Which of those can proxy TCP, as opposed to HTTP? Haproxy can.
| johnchristopher wrote:
| Traefik too.
| trebecks wrote:
| nginx too
| http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html
| nuerow wrote:
| > _Is there some document somewhere that goes over the choices,
| overlaps, etc?_
|
| I believe Apache Traffic Server doesn't really compete with the
| likes of nginx or traefik. Apache Traffic Server is a HTTP
| caching server/web accelerator, thus it's specialized for
| caching HTTP requests and consequently it's simpler to deploy
| and configure. With that in mind, it competes with the likes of
| Squid[1] or Varnish[2].
|
| [1] http://www.squid-cache.org/
|
| [2] https://varnish-cache.org/
| IronWolve wrote:
| I've used varnish in the past with cdn's, never had an issue
| so I have not tried other cashing/load balancing products.
|
| Internally use squid with rules for non routed internal
| network addresses.
|
| Sounds like lots of newer products out there, maybe even
| better products, but you sometimes just stay with whats
| working due to time/budgets.
|
| Would really be interested in articles with benchmarks,
| pros/cons, etc on different products. Wonder why not many
| websites doing this for content? Sounds like a good market
| that needs filled.
| tyingq wrote:
| It does support routing via SNI. And of course, people do use
| nginx (and other tools) just as proxy caches. That's sort of
| what I was getting at, lots of overlap and sub-niches.
| thatwasunusual wrote:
| Varnish?
| sciurus wrote:
| Why do you describe it as less directly related to squid and
| varnish? I haven't worked with ATS before, but it's
| documentation describes it as "a high-performance web proxy
| cache that improves network efficiency and performance by
| caching frequently-accessed information at the edge of the
| network" which makes it seem to fill a similar role as them.
| tyingq wrote:
| Yes, you're right, though that sort of goes to my question :)
| jcims wrote:
| Anyone know how it might compare to Neflix Zuul
| laurencerowe wrote:
| Zuul is a proxy not a caching proxy IIRC.
| linsomniac wrote:
| Subject should be changed to "Apache Traffic Server Security
| Fixes" or similar.
|
| Looks like the "News" is that Nov 2 they released 8.1.3 and 9.1.1
| with "security fixes". However, after digging for half an hour I
| can't tell what the nature of the security fix is. Changelogs and
| issues related to these releases don't highlight any particular
| security issues or what the impacts are.
| nuerow wrote:
| > _Subject should be changed to "Apache Traffic Server Security
| Fixes" or similar._
|
| I submitted the link before the new release with security fixes
| was announced, without that in mind. Moreover, the link points
| to the project page and not the release. I submitted because I
| found the project interesting but somewhat low-key, and I
| thought people like me would find it interesting.
| linsomniac wrote:
| Fair enough, but I stand by that the news is that there's a
| security fix.
| nuerow wrote:
| Yes, I agree. Happy accident and all.
___________________________________________________________________
(page generated 2021-11-03 23:01 UTC)