lkarsten

4ksb

I applaud the effort to hate on "smart" middleware proxies!

That being said, author gets no points for namedropping random distributed systems algorithms and using tcp keepalives (2 hours minimum!) as an argument against TLS terminating proxies.

Is there a reason to (as he says) "fully implement the protocol" in the proxy? I battled with websockets through Pound last week, and it simply doesn't work because the author took a non-postel stand on protocol specifics.

Having a protocol agnostic proxy like hitch (previously stud) fixed that without losing functionality, and I expect it to age better as well.

Hi jamwt. We haven't forgotten your(?) excellent work on stud!

Both changes.rst and the man page explain where Hitch came from.

Hitch has seen significant changes since we forked stud 0.3.2, for example proper reload/sighup support, an improved configuration format, and OCSP stapling. Running it on a large scale (cert/ip -wise) also works better now.

If you're ever in our parts of the world, let us know and we'll buy you some beers/coffee/$beverage and tell you all about how your old project is doing.

HTTP/2 is on the way.

On linux netem can help you do something similar. It is also faster, better tested, has more features and so on.

I guess an argument can be made about the user interface, as tc is a nightmare. :-)

Thanks for the data point.

The reason is pretty simple: LibreSSL isn't available/packaged on the distributions we care about, and we don't have the will, money or knowledge to do it ourselves. (with my VS hat on)

We are positive to merging any code changes necessary to get it running with libressl though.

How do you think the CPU usage would be with 10kB buffer sizes? And since we're throwing numbers out in the air, why stop at 10kB? If we reduce to 1k, that should give us MUCH MOR connections!!11.

Let me ask a leading question: how much of this do you think is openssl overhead?

Please consider optimising for a real usage scenario, not some fantasy benchmarking setup.

Yes, doing hard crypto for all users has costs. Welcome to the real world. :-)

Advantages are that it is faster, and that it is a small and simple program that does a single thing well.

Congratulations, you have rediscovered a problem described in a 14 year old RFC: http://tools.ietf.org/html/rfc3135

Good news, I'm told they are planning an east coast event in the spring.

Every site has something that can be cached. Images, js, headers, popular product lists, etc.

If a specific page item can be cached is really up to if the backend application takes cookie state into account when the page item is made.

The Varnish default of not caching anything when cookies are present is because we have no idea if the backend writes "Welcome back, krat0sprakhar!" when it sees the username in an incoming cookie. Sending that item to every user would be unfortunate.

Other than that, I'd recommend you evaluate your needs and not just pick a technology. If your page response times are low enough already, and your backends/appservers scale to as many concurrent buyers you think you need, you're good without Varnish/caching.

I'll let the right people know. Thanks for the feedback.

For most users it is a 5-10 minute job, no sweat.

You are not.