> > Pois é galera, aqui no trabalho, levantaram a ideia de que colocando > um proxy reverso SSL, a porta 443 seria cacheada e os formulários como > .css, .js, etc.. seriam cacheados no squid sendo utilizado desta forma > e isto aceleraria a resposta do site para o usuário. Eu discordei, > falei que desconheço qualquer funcionalidade do squid que consiga > realizar cache de sites SSL. > Buscando no site do squid, encontrei esta parte: > http://wiki.squid-cache.org/ConfigExamples/Reverse/SslWithWildcardCertifiate > Onde é possível colocar os certificados para serem gerenciados pelo > squid, mas até onde entendi, ele não faz cache de SSL, e sim dá a > vantagem de se ter um tipo de redundância em sites SSL que serão > "protegidos" pelo squid, mas não faria cache de SSL. > Será que é isto mesmo? Se for, porque utilizaria um proxy reverso SSL > para acelerar a conexão se ele não fizer cache de SSL? >
Por que não utilizar um nginx no front-end? Nginx é um web server com suporte a SSL, proxy reverso, cache em memória (pode até realizar consultas diretas a memcache) ou cache em disco, além do uso de recursos ser na ordem de 10% de um apache default Outro webserver lightweight interessantes é o lighttpd (usado pelo meebo) que também suporte proxy reverso a seguinte configuração seria interessante: front: lighttpd+nginx com ssl configurado e os arquivos estáticos (.js, .png, .css, ...) back: servidores HTTP somente tratando conteudo dinamico. Att, Mosconi ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
