leibold
Premium,MVM
join:2002-07-09
Sunnyvale, CA
clubs: 
| reply to tonymontana
Re: Sufficient Server?
said by tonymontana  :what type of impact if any would this have on our PVC? You don't describe the topology change well enough to answer that question properly.
Possibility 1.: the 7 remote locations currently make direct Internet access through their ISP connection and only traffic targeted for the main office traverses the PVC. By changing the Internet access from the remote sites to go through the main office traffic through the PVCs will increase. Whether or not squid is used at the main office is completely irrelevant in this case since even cached content will go repeatedly through the PVCs. The only way to reduce some of the traffic increase would be squid caches at all the remote locations. The effectiveness of that would depend on the type of Internet accesses made. Some Internet content is really not cacheable, much more Internet content is marked not cacheable to cause browsers to always download the latest ads!
Possibility 2: the only Internet access for the remote sites is already only by going through the main office network. In this case there will be no increase in traffic on the PVCs and by caching static content on the squid server you will reduce some Internet bandwidth for the main office Internet connection.
said by tonymontana : i've never setup squid before how well does it handle https sessions It handles them really well, but there are a few things you should be aware off:
- secure content from https sessions is not cached. The main reason to use the proxy is therefore not valid with https sessions. It is still commonly done because squid also provides logging and access controls which are still meaningful even without caching. However if you don't need logging or access controls, why bother squid with the https traffic ?
- there are two ways a browser can use a proxy server for a SSL (https) connection. The common way is to use the CONNECT request which establishes a transparent pipe between browser and destination server. In this case squid only passes the bytes back and forth and does not attempt any interpretation of their content (which would be rather difficult since they are encrypted). Encryption/decryption takes place in the browser and the web server and does not involve the proxy server. However it is also possible for squid to terminate SSL connections. This is less common and as far as I know works by the browser making normal GET/POST requests with a https url. In that scenario the traffic between browser and proxy server is unprotected (usually not an issue since it is on the local lan especially if it is switched ethernet). More importantly the task of encryption and decryption moves from the browser to the proxy server. If several users make SSL connections in that way it would result in significant cpu load on the proxy server. I'm not aware off any modern browser that does not support the CONNECT method, but perhaps some may fall back to the second method if CONNECT does not work (perhaps because you decided to block certain sites? In that case be sure to block all request methods and not just CONNECT).
P.S.: Be prepared to be amazed how quickly your squid cache grows!
--
Got some spare cpu cycles ? Join Team Helix or Team Starfire! |
