On 05/04/11 21:40, Víctor José Hernández Gómez wrote:
El 05/04/11 10:31, Amos Jeffries escribió:
On 05/04/11 20:01, Víctor José Hernández Gómez wrote:
Dear squid users,
we remember to have measured the percentage of bandwitch devoted to SSL
in our squid installation, and it was about 10 percent of total traffic.
SSL is not cacheable, and I think its use is increasing. I wonder if
there is any experience with squid software using SSL engines (hardware
devices) via openssl to get a better behaviour (that is, better
perfomance) of SSL traffic.
What do you think Squid would do with such hardware? HTTPS traffic is
encrypted/decrypted by the client and server. Squid just shuffles their
pre-encrypted bytes to and fro.
I thought that --enable-ssl and --with-openssl compilation options would
provide squid with the ability to use openssl functions to treat SSL
traffic. In such a case, operating with hardware instead of software
would accelerate squid. I see that is not the case.
They do. For the traffic which is destined directly to Squid
(https_port) and out of Squid (from plain-HTTP requests with https://
URL), and for ssl-bump manipulations.
But not for CONNECT tunnels, which is what browsers usually wrap HTTPS
inside.
Any other idea regarding SSL treatment would be very welcome (parameter
tuning either on SO, squid, or openssl, etc..)
If Squid is peritted to see the HTTP reuqets inside the SSL they are
usually as cacheable as non-SSL requests.
Please help us encourage the browser developers to make SSL links to a
trusted SSL-enabled proxy and pass the requests to it. Then we can all
benefit from improved HTTPS speeds.
For now the tunneling Squid perform as good as non-caching proxies. Or
in situations where ssl-bump feature can be used they work slower but
with cache HITs being possible.
Thank you for your help.
Welcome.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.6
