4 ms·

Oh hey HN. This is in the Caddy 2.6 beta already: https://github.com/caddyserver/caddy/releases/tag/v2.6.0-beta.3 https://github.com/caddyserver/caddy/releases/

by mholt 4y ago

Oh hey HN. This is in the Caddy 2.6 beta already: https://github.com/caddyserver/caddy/releases/tag/v2.6.0-beta.3 https://github.com/caddyserver/caddy/releases/tag/v2.6.0-bet... - please try it out! Thanks to Marten Seemann for maintaining the quic-go library we use. (I still haven't heard whether Go will add HTTP/3 to the standard library.) Caddy 2.6 should be the first stable release of a general-purpose server to support and enable standardized HTTP/3 by default. HTTP versions can be toggled on or off. (Meaning you can serve only HTTP/3 exclusively if you're hard-core.) PS. Caddy 2.6 will be our biggest release since 2.0. My draft release notes are about 23 KB. We're looking at huge performance improvements and powerful new features like events, virtual file systems, HTTP 103 Early Hints, and a lot of other enhancements I'm excited to show off on behalf of our collaborators!

asb 4y ago
I've just moved over to Caddy and had a really good experience in doing so (thank you to you and all the other Caddy contributors!). One thing that stuck out to me during setup is that it seemed surprising to see gzip encoding not enabled by default. Wouldn't it make sense for a server that enables https by out of the box with zero configuration and soon supports http3 to also gzip by default?
- mholt 4y ago
  Good question! When I first announced Caddy in 2015 and the server got busy, it started downloading everything as .gz files. (facepalm) (good ol' days) But that's just a fun story, not actually the reason we don't enable it by default... The tricky thing about enabling features by default is that turning them off is awkward in config. And while we like to have "magic" in Caddy, we don't like too much magic. Plus, gzip performance in Go is less good (but more memory-safe) than it is in C and assembly. Klauspost's flate implementation is very fast and that's the one we use. But even with a super-fast implementation, gzip requires memory and CPU that busy servers may be in short supply of. So it's opt-in for now. We can always change it later; going the other way is harder. (Caddy also supports serving pre-compressed files, if enabled! And starting with Caddy 2.6, those can be teleported at the speed of electricity to HTTP clients using sendfile. HTTPS also sees faster file serving in 2.6 due to optimized copying.) See also: https://serverfault.com/questions/296770/why-arent-features-like-gzip-enabled-by-default-on-many-webservers https://serverfault.com/questions/296770/why-arent-features-...
  - asb 4y ago
    Thanks for the response! I'd imagined reasoning along those lines. I'd perhaps expect that people anticipating such high load that gzipping output is problematic would be investing enough time in server setup to review and tweak these options. And for everyone else, compression by default is a good starting point. Moving from Nginx (HTTP2 off by default) to Caddy (HTTP2 on by default) you'd already need to review your setup if running a highly trafficked site to ensure any reverse proxied servers can handle the additional request load due to multiplexing. But it's obviously a trade-off and there's lots to weigh up...
  - hsbauauvhabzb 4y ago
    Why was gzipping everything a facepalm? Performance?
    - francislavoie 4y ago
      It was making the browser download files with the .gz extension, instead of serving the content in a way that the browser would display. TL;DR it was broken at the time. But it was a very long time ago.
  - layer8 4y ago
    If gzip is enabled, is the gzipped version of a static file cached in memory, or is it gzipped anew for each request?
    - mholt 4y ago
      Caddy doesn't cache responses by default, but you can enable caching with the cache plugin: https://github.com/caddyserver/cache-handler/ https://github.com/caddyserver/cache-handler/
      - oynqr 4y ago
        Does this apply to static file serving? Although I suppose relying on the OS cache might be enough.
- JZerf 4y ago
  In addition to the reasons that mholt mentioned in response to your question, enabling HTTP/GZIP compression could possibly be less secure for some web server configurations due to things like the BREACH attack. See https://en.wikipedia.org/wiki/HTTP_compression#Security_implications https://en.wikipedia.org/wiki/HTTP_compression#Security_impl... and https://en.wikipedia.org/wiki/BREACH https://en.wikipedia.org/wiki/BREACH for more info. I might be wrong but I don't think that current web serving protocols mitigate an attack like this. It might be better to default to safe settings that don't use HTTP/GZIP compression even if it might slow things down for the time being.
  - thadt 4y ago
    Eh, it's not just current web serving protocols. Any protocol where: - An application uses compression - An attacker is able to supply chosen data to it - The application compresses the attacker's data and static secret data together - The attacker is able to monitor the size of the compressed data - This can be repeated by the attacker a number of times will be vulnerable to having its secret data stolen by techniques like BREACH. If you want your secret data to stay secret, don't compress it with attacker chosen plaintext where the resulting size could be monitored.
fariszr 4y ago
Absolutely awesome! I have recently gave Caddy a shot, and immediately loved it!. I am a bit worried about the performance deficit compared to apache or Nginx, but none of my servers really have reached the scale where it actually matters. Its unfortunate that there is no dynamic brotli support, but oh well, a trade off I'm willing to make. One of things that aren't clear to me are Caddy plugins. How big of an affect do they have on peformance? Are plugins a core part of Caddy's usage? Or are they just exist to cover some edge cases? I'm thinking of using the caddy-filter and caddy-crowdsec-bouncer plugins.
- francislavoie 4y ago
  Having plugins installed has no performance incursion at all (because they don't run unless configured), but using them will, of course affect performance. But it depends on the plugin and what it does. You have to do your own benchmarking to see what effect they have to performance. Everyone has different needs and configs, so it's not possible to give authoritative benchmarks. Just try it out and see. Regarding brotli, there is a plugin you can try if you'd like https://github.com/ueffel/caddy-brotli https://github.com/ueffel/caddy-brotli, but brotli's on-the-fly performance is not that good. It works well if you pre-compress you assets though, and you can serve those with the file_server directive's precompressed option.
  - deleted 4y ago
    [deleted]
- mholt 4y ago
  Glad you liked it! Caddy's performance is competitive with nginx, but there are too many dimensions to discuss here. I guarantee that for most people, your web server will not be your bottleneck. Dynamic brotli is expensive, as brotli compression is inefficient. There are no optimized Go implementations of this yet. But Caddy can serve precompressed brotli files without any separate plugins. What do you mean by "what affect do [plugins] have on performance"? All features in Caddy are plugins, some just come installed by default: https://caddyserver.com/docs/architecture https://caddyserver.com/docs/architecture -- even its HTTP server is a plugin. (All plugins are compiled in natively.)
purim 4y ago
Does Caddy have the same issue with configuration spaghetti problem with Traefik? How does it differ from Traefik's model?
- mholt 4y ago
  I'm not super familiar with Traefik, but if you're talking about using container labels for config, no, Caddy's config is given as a JSON document through a REST API. The CLI can let you use config files if you prefer. Or the Caddyfile is a more human-friendly format that Caddy supports by default. You can actually use any config format you want if there's a config adapter for it: https://caddyserver.com/docs/config-adapters https://caddyserver.com/docs/config-adapters
- robk 4y ago
  Caddy is vastly vastly better in this regard. Traefik config files drive me insane when rewriting anything.
todotask 4y ago
Planning on trying Caddy 2.6 one of these day to see how much improvement it can make over other web servers, maybe CentmindMod would be interested in it. We all are aware local vs real world benchmark are differ.
- francislavoie 4y ago
  Caddy v2.6 is making huge improvements here. See https://github.com/caddyserver/caddy/pull/5022 https://github.com/caddyserver/caddy/pull/5022 But also, please don't take benchmarks like this as gospel. Run your own benchmarks, on your own hardware, with your own config. Someone else's config may not be ideal for your usecase.
- mholt 4y ago
  So you want to benchmark the network?
  - todotask 4y ago
    On a VPS, but no doubt that running Go app directly is more performant, I could use Go for serving static contents as well.
    - mholt 4y ago
      I have done that test. Go is not significantly faster than Caddy for serving static content.

by mholt 4y ago

asb 4y ago

I've just moved over to Caddy and had a really good experience in doing so (thank you to you and all the other Caddy contributors!). One thing that stuck out to me during setup is that it seemed surprising to see gzip encoding not enabled by default. Wouldn't it make sense for a server that enables https by out of the box with zero configuration and soon supports http3 to also gzip by default?

mholt 4y ago
Good question! When I first announced Caddy in 2015 and the server got busy, it started downloading everything as .gz files. (facepalm) (good ol' days) But that's just a fun story, not actually the reason we don't enable it by default... The tricky thing about enabling features by default is that turning them off is awkward in config. And while we like to have "magic" in Caddy, we don't like too much magic. Plus, gzip performance in Go is less good (but more memory-safe) than it is in C and assembly. Klauspost's flate implementation is very fast and that's the one we use. But even with a super-fast implementation, gzip requires memory and CPU that busy servers may be in short supply of. So it's opt-in for now. We can always change it later; going the other way is harder. (Caddy also supports serving pre-compressed files, if enabled! And starting with Caddy 2.6, those can be teleported at the speed of electricity to HTTP clients using sendfile. HTTPS also sees faster file serving in 2.6 due to optimized copying.) See also: https://serverfault.com/questions/296770/why-arent-features-like-gzip-enabled-by-default-on-many-webservers https://serverfault.com/questions/296770/why-arent-features-...
- asb 4y ago
  Thanks for the response! I'd imagined reasoning along those lines. I'd perhaps expect that people anticipating such high load that gzipping output is problematic would be investing enough time in server setup to review and tweak these options. And for everyone else, compression by default is a good starting point. Moving from Nginx (HTTP2 off by default) to Caddy (HTTP2 on by default) you'd already need to review your setup if running a highly trafficked site to ensure any reverse proxied servers can handle the additional request load due to multiplexing. But it's obviously a trade-off and there's lots to weigh up...
- hsbauauvhabzb 4y ago
  Why was gzipping everything a facepalm? Performance?
  - francislavoie 4y ago
    It was making the browser download files with the .gz extension, instead of serving the content in a way that the browser would display. TL;DR it was broken at the time. But it was a very long time ago.
- layer8 4y ago
  If gzip is enabled, is the gzipped version of a static file cached in memory, or is it gzipped anew for each request?
  - mholt 4y ago
    Caddy doesn't cache responses by default, but you can enable caching with the cache plugin: https://github.com/caddyserver/cache-handler/ https://github.com/caddyserver/cache-handler/
    - oynqr 4y ago
      Does this apply to static file serving? Although I suppose relying on the OS cache might be enough.
JZerf 4y ago
In addition to the reasons that mholt mentioned in response to your question, enabling HTTP/GZIP compression could possibly be less secure for some web server configurations due to things like the BREACH attack. See https://en.wikipedia.org/wiki/HTTP_compression#Security_implications https://en.wikipedia.org/wiki/HTTP_compression#Security_impl... and https://en.wikipedia.org/wiki/BREACH https://en.wikipedia.org/wiki/BREACH for more info. I might be wrong but I don't think that current web serving protocols mitigate an attack like this. It might be better to default to safe settings that don't use HTTP/GZIP compression even if it might slow things down for the time being.
- thadt 4y ago
  Eh, it's not just current web serving protocols. Any protocol where: - An application uses compression - An attacker is able to supply chosen data to it - The application compresses the attacker's data and static secret data together - The attacker is able to monitor the size of the compressed data - This can be repeated by the attacker a number of times will be vulnerable to having its secret data stolen by techniques like BREACH. If you want your secret data to stay secret, don't compress it with attacker chosen plaintext where the resulting size could be monitored.

fariszr 4y ago

Absolutely awesome! I have recently gave Caddy a shot, and immediately loved it!. I am a bit worried about the performance deficit compared to apache or Nginx, but none of my servers really have reached the scale where it actually matters. Its unfortunate that there is no dynamic brotli support, but oh well, a trade off I'm willing to make. One of things that aren't clear to me are Caddy plugins. How big of an affect do they have on peformance? Are plugins a core part of Caddy's usage? Or are they just exist to cover some edge cases? I'm thinking of using the caddy-filter and caddy-crowdsec-bouncer plugins.

francislavoie 4y ago
Having plugins installed has no performance incursion at all (because they don't run unless configured), but using them will, of course affect performance. But it depends on the plugin and what it does. You have to do your own benchmarking to see what effect they have to performance. Everyone has different needs and configs, so it's not possible to give authoritative benchmarks. Just try it out and see. Regarding brotli, there is a plugin you can try if you'd like https://github.com/ueffel/caddy-brotli https://github.com/ueffel/caddy-brotli, but brotli's on-the-fly performance is not that good. It works well if you pre-compress you assets though, and you can serve those with the file_server directive's precompressed option.
- deleted 4y ago
  [deleted]
mholt 4y ago
Glad you liked it! Caddy's performance is competitive with nginx, but there are too many dimensions to discuss here. I guarantee that for most people, your web server will not be your bottleneck. Dynamic brotli is expensive, as brotli compression is inefficient. There are no optimized Go implementations of this yet. But Caddy can serve precompressed brotli files without any separate plugins. What do you mean by "what affect do [plugins] have on performance"? All features in Caddy are plugins, some just come installed by default: https://caddyserver.com/docs/architecture https://caddyserver.com/docs/architecture -- even its HTTP server is a plugin. (All plugins are compiled in natively.)

purim 4y ago

Does Caddy have the same issue with configuration spaghetti problem with Traefik? How does it differ from Traefik's model?

mholt 4y ago
I'm not super familiar with Traefik, but if you're talking about using container labels for config, no, Caddy's config is given as a JSON document through a REST API. The CLI can let you use config files if you prefer. Or the Caddyfile is a more human-friendly format that Caddy supports by default. You can actually use any config format you want if there's a config adapter for it: https://caddyserver.com/docs/config-adapters https://caddyserver.com/docs/config-adapters
robk 4y ago
Caddy is vastly vastly better in this regard. Traefik config files drive me insane when rewriting anything.

todotask 4y ago

Planning on trying Caddy 2.6 one of these day to see how much improvement it can make over other web servers, maybe CentmindMod would be interested in it. We all are aware local vs real world benchmark are differ.

francislavoie 4y ago
Caddy v2.6 is making huge improvements here. See https://github.com/caddyserver/caddy/pull/5022 https://github.com/caddyserver/caddy/pull/5022 But also, please don't take benchmarks like this as gospel. Run your own benchmarks, on your own hardware, with your own config. Someone else's config may not be ideal for your usecase.
mholt 4y ago
So you want to benchmark the network?
- todotask 4y ago
  On a VPS, but no doubt that running Go app directly is more performant, I could use Go for serving static contents as well.
  - mholt 4y ago
    I have done that test. Go is not significantly faster than Caddy for serving static content.