Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Caddy compatibility for zeroserve: 3x throughput and 70% lower latency

su3.io

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency

#31

Post by iknowstuff »

cmgbhm wrote: post #21
embedding-shape wrote: post #14

Earlier quoted context omitted.

Here it attempts to read my personal certificate that sits in the browser that I use for filling my taxes and do government stuff, suspicious indeed.

That’s likely just the side effect of supporting mtls. Mutual TLS came around at the same time as Microsoft did implicit network auth. Seemed magical at the time and so hare brained for eons of problems. The user side tls never caught on in most circles and still has the ancient sharp edges

Could probably buff it with passkeys these days

https://www.passkeyprf.com/

Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency

#32

Post by naturalmovement »

embedding-shape wrote: post #14
1a527dd5 wrote: post #10

Anyone else got a really weird Chorme pop-up asking which cert to use for su3.io:443? Very bizarre, never seen that before. Thumbprints: - 60949a09aab8677f87a0b9eda7099a03ca510fb3 - 1b146798f0dc93773247e86312f1b730c4eeebb3

Here it attempts to read my personal certificate that sits in the browser that I use for filling my taxes and do government stuff, suspicious indeed.

That's literally how client certificates work.

It's not attempting to "read" anything, nor is it the least bit suspicious or malicious.

Your browser was asked if it would like to present a certificate to authenticate, and you were prompted to choose one if you please. You can also hit cancel as client auth can be optional and the server will either serve you the page or a 401/403.

It's like being asked to show ID to enter a pub, you can either show one or decline, and they may or may not let you enter based on that transaction.

Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency

#33

Post by [deleted] »

mook wrote: post #22
embedding-shape wrote: post #14

Earlier quoted context omitted.

Here it attempts to read my personal certificate that sits in the browser that I use for filling my taxes and do government stuff, suspicious indeed.

That's because the client certificate interface in browsers is supremely dumb. It always just lists all certificates you have, with very little context in the UI, and hopes that's good enough. I believe that's part of the reason client certificates are not poplar; having actual users deal with that is terrible, and the browsers (in practice, Chrome because of its overwhelming market share) isn't incentivized to fix i…

[deleted]

Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency

#35

Post by jarym »

codingjoe wrote: post #18

"Caddy compatible" minus everything that matters, like ACME and plugins. And NGINX still steals the show. Not everything needs to be rewritten.

Agree on lack of ACME but the codebase is far cleaner than nginx. In theory it'd be easier to audit?

Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency

#36

Post by chucky_z »

miladyincontrol wrote: post #28
augunrik wrote: post #4

I am surprised how well nginx holds up?!

I mean, nginx dang well should? This is just an incredibly synthetic http(s)/1.1 test for what its worth. Like you totally could turn off garbage collection for caddy especially since this is only testing incredibly short single response queries that would never need GC. Shockingly you would actually get better performance than either nginx or zeroserve, but like the uselessness of this benchmark it'd mean nothing to…

Unfortunately that is likely untrue. Try it yourself, Go with GC disabled isn’t some magic bullet for performance as much as I’d like it to be.

Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency

#37

Post by chucky_z »

ianm218 wrote: post #30
Thaxll wrote: post #24

Another vibe coded, dead in 6 month Rust project. People that trully need performance are not going to use a random server that has 0 support/ track record.

Isn't there a chicken and egg problem where projects need to start with 0 track record? Nginx had zero track record at one point as well

Nginx was developed to scale a lot of Russian sites, starting with Rambler. As a second point, Envoy was made by Lyft. A lot of web server OSS goes back to big (at the time) corps.

Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency

#38

Post by bastawhiz »

The idea of jit compilation of a web server in a small project is pretty terrifying to me. The attack surface here is enormous.

And for what? My back end on a single host isn't pumping at 35k qps. If each request is 500 bytes, 35k qps is nearly 20mbps sustained with zero other io (in each direction). And this is using only two threads!

I think you'd be hard pressed to find an application where this is meaningfully useful versus just scaling horizontally. On a box that can run many threads in parallel, Caddy still vastly exceeds my ability to respond to pretty much any useful traffic. It's optimizing for a metric that wasn't a bottleneck in the first place.

Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency

#39

Post by eptcyka »

bastawhiz wrote: post #38

The idea of jit compilation of a web server in a small project is pretty terrifying to me. The attack surface here is enormous. And for what? My back end on a single host isn't pumping at 35k qps. If each request is 500 bytes, 35k qps is nearly 20mbps sustained with zero other io (in each direction). And this is using only two threads! I think you'd be hard pressed to find an application where this is meaningfully us…

Except CDNs, where it is.

Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency

#40

Post by Avamander »

mook wrote: post #22
embedding-shape wrote: post #14

Earlier quoted context omitted.

Here it attempts to read my personal certificate that sits in the browser that I use for filling my taxes and do government stuff, suspicious indeed.

That's because the client certificate interface in browsers is supremely dumb. It always just lists all certificates you have, with very little context in the UI, and hopes that's good enough. I believe that's part of the reason client certificates are not poplar; having actual users deal with that is terrible, and the browsers (in practice, Chrome because of its overwhelming market share) isn't incentivized to fix i…

Servers can communicate their preference in terms of CAs they want. But the UX in browsers is unbelievably horrible for no good reason.

Not only is it difficult for an user to make a proper selection, it's also hard to fix a wrong one. The error pages are also terrible. There's no way for the site owner to request that when the navigation to the (auth) page fails, redirect back. Nope, no way to do error handling without some really clever iframe stuff and even then it's way too opaque.

God forbid you have to deal with CORS + mTLS.

Post reply on HN