Sovint ens trobem que diversos usuaris d'una mateixa xarxa accedim als mateixos llocs d'Internet per consultar les mateixes coses, per estalviar malgastar la connexió cap a l'exterior i per incrementar la velocitat de navegació hi ha la possibilitat d'usar eines basades en l'ús dels principis de cache (presents en molts elements tecnològics) com a magatzems d'informació gestionats de forma automàtica per servir el contingut de les peticions http i ftp demanades pels navegadors de la manera més ràpida possible.

Aquest servei es pot estructurar en una jerarquia (nivell superior que serveix nodes inferiors i aquests a altres, etc.) de forma que el trànsit a Internet s'optimitzi al màxim i els usuaris gaudeixin d'una connexió a la Web més fluida.

Primer nivell de cache: el navegador de l'estació de treball

El nivell més bàsic de cache l'incorporen els navegadors Web, reservant un espai de memòria i disc per a les pàgines, per poder presentar més ràpidament les peticio més sol·licitades, llegint-les directament de la RAM o del disc dur.

D'una forma força 'rústica' permet controlar el refresc de les pàgines fent una comparació de les emmagatzemades localment amb les originals que es troben a l'exterior.

Normalment només hi ha tres opcions:

1. "Mai" - No compara mai les pàgines, pot presentar informació 'caducada', la navegació és directa del disc dur i molt ràpida a partir de la primera descàrrega inicial.
2. "Sempre" - Sempre fa una comparació amb l'exterior per evitar rebre informació 'caducada'. La velocitat de la cache no s'aprofita gaire, doncs sempre cal esperar una resposta inicial de l'exterior per verificar la pàgina.
3. "Un cop per sessió" - Quan accedim a les pàgines per primera vegada fa una comparació amb l'exterior. Si en la mateixa sessió hi tornem a accedir no es farà cap més comparació. La velocitat és força bona i s'aprofita molt la cache.

El comportament del Navegador pot canviar 'radicalment' si triem una opció o una altra, normalment per defecte tindrem activada l'opció "Un cop per sessió".

Segon nivell de cache en una Xarxa Local

Es vol aconseguir que els ordinadors de la LAN, quan volen accedir a la Web, usin una sola màquina que disposi del magatzem de cache en la seva memòria i disc dur.

Millora la versió dels navegadors en molts punts:

• Treballa amb uns algoritmes molt elaborats per decidir de forma automàtica si cal refrescar o no algun dels objectes que té emmagatzemats.
• Manté una cache de la resolució de noms (DNS), evitant noves peticions per pàgines ja visitades.
• Permet crear jerarquies amb les caches d'altres xarxes per aprofitar al màxim els objectes emmagatzemats i actualitzats més propers.
• Els objectes 'aconseguits' per la cache des d'un dels navegadors de la xarxa, queden a disposició de tots els altres, incrementant el nombre d'encerts en les peticions dels diferents ordinadors a les mateixes URL.

Això ho podem aconseguir amb l'aplicació Squid sobre un Linux.

Tercer nivell i superiors: jerarquia de caches

Les aplicacions de cache en xarxa demostren tota la seva potència quan formen part d'una jerarquia.

Un proxy A pot relacionar-se amb un altre B fent-li de:

Pare (parent) - Normalment el proxy Pare el trobem 'per sobre' de la nostra xarxa local i l'utilitzem per aprofitar al màxim la seva connexió de xarxa i el seu magatzem.

El proxy B demanarà tots els objectes al seu pare i en el cas que no els tingui emmagatzemats haurà d'anar-los a buscar i lliurar-los al seu 'fill'.

Aquesta relació permet aprofitar des d'un sol punt diferents línies d'accés a Internet, només enllaçant el nostre proxy fill amb un pare col·locat a cadascuna d'aquestes línies.

Germà (sibling) - Aquesta relació permet compartir el contigut de la cache en disc entre els proxy de la mateixa xarxa.

El proxy B demanarà als seus germans l'objecte que vol servir a l'usuari, si un dels germans el té en el magatzem li donarà, en cas de no tenir-lo, haurà de ser el proxy B qui l'hagi de recollir directament d'Internet.

Aquesta relació fa possible 'aprofitar' el contigut d'una cache propera sense 'embrutar' la seva connexió amb l'exterior. S'utilitza en els casos que els administradors de la xarxa on hi ha aquest proxy no vulguin que totes les peticions dels altres surtin a través de la seva connexió Internet.

Requeriments a nivell dels clients

Per poder 'treballar' amb el proxy-cache només cal dotar als clients d'un 'Navegador Web' on es pugui configurar l'accés a través d'aquest tipus de servei.

La majoria de 'clients Web' ho permeten, amb dues opcions:

Configuració manual: normalment present a tots els navegadors del mercat. Cal indicar el nom (o la IP) del servidor proxy i el Port (canal per on el servidor dóna aquest servei) per a cadascun dels protocols.

Per exemple, la configuració manual d'un navegador 'estàndard' pot ser:

Protocol    Host           Port
HTTP        192.168.0.2    8080
FTP         192.168.0.2    8080

També podem indicar que no s'utilitzi el proxy per adreces locals.

Configuració automàtica: Es tracta d'una seqüència d'ordres en Javascript que el navegador llegeix cada cop que es posa en marxa i que estableix una sèrie de normes de l'accés via proxy cache.

Uns exemples del fitxer proxy.pac :

function FindProxyForURL (url,host) 
  {  
  if ((url.substring(0,5)!= "http:") && 
      (url.substring(0,4) != "ftp:") && 
      (url.substring(0,7) != "gopher:")) { 
       return "DIRECT"; 
      } 
          if (isPlainHostName(host) ||  
              shExpMatch(host,"192.168.*") || 
              shExpMatch(host,"127.*") || 
             (url.substring(11,23) == "xtec.es:8800")) 
              return "DIRECT"; 
          else  
              return "PROXY 192.168.0.2:8080; PROXY proxy.xtec.es:8080; DIRECT"; 
} 

Aquest altre exemple inclou una drecera per a l'accés directe a les pàgines de gencat.net, permet alleugerir el treball amb les aplicacions de gestió que usem a la feina, i per evitar alguns problemes en l'accés des dels proxy squid fills al correu Web que ofereix la XTEC i l'EDU365.

function FindProxyForURL (url,host)
        { if ((url.substring(0,5) != "http:") &&
              (url.substring(0,6) != "https:") &&
              (url.substring(0,4) != "ftp:") &&
              (url.substring(0,7) != "gopher:")) {
              return "DIRECT";
              }
          if (isPlainHostName(host) ||
          shExpMatch(host,"192.168.*") ||
          shExpMatch(host,"127.*") ||
          dnsDomainIs(host,"correu.edu365.com") ||
          dnsDomainIs (host,".intranet") ||
          (url.substring(11,23) == "xtec.es:8800") ||
           dnsDomainIs (host,"xat.edu365.com") ||
          dnsDomainIs (host,".gencat.net")  ||
          dnsDomainIs (host,".gencat.es")) {
              return "DIRECT";
              } 
          else
              return "PROXY 192.168.0.2:8080; PROXY proxy.xtec.es:8080; DIRECT";
        }

El primer 'if' d'aquest fitxer obliga al navegador a accedir directament (o sigui sense demanar-ho al proxy) si a la URL no es demana cap protocol que l'Squid reconegui.

El segon bloc 'if - else', evita que es demanin al proxy continguts que no val la pena desar a la cache, per exemple si accedim al contingut del propi servidor, a pàgines de les màquines de la xarxa local, a serveis 'especials' com per exemple el correu web pel port 8800, etc.

La resta de continguts que no compleixen cap dels punts del primer bloc, es direccionen directament a l'Squid, seguint la pauta de l'últim paràgraf.

En el cas que el proxy 192.168.0.2 no respongui, el navegador intentarà utilitzar el proxy.guifi.net, si aquest també falla canviarà el tipus d'accés, connectant directament a Internet sense que l'usuari hagi canviat cap opció del navegador.

Més informació a http://squid-docs.sourceforge.net/latest/html/x1187.html

Aquest fitxer proxy.pac que conté aquestes ordres s'ha de col·locar dins un servidor Web que tingui configurat el tipus mime:

application/x-ns-proxy-autoconfig pac

contra l'extensió 'pac' dins el fitxer mime.types

i els navegadors hi han de poder accedir mitjançant una URL que cal incloure dins la seva configuració.

Per exemple, la configuració automàtica d'un navegador 'estàndard' inclourà:

URL del fitxer de configuració automàtica = http://www.guifi.net/proxy.pac

El seus avantatges més clars respecte la configuració manual són:

• Permet direccionar l'accés directe a dominis que així ho requereixin. La configuració manual es regeix per la configuració interna del proxy, molt més rígida.
• Permet configurar l'accés a través del proxy més òptim per a cada connexió, encaminant els clients de forma transparent. Si es volgués fer amb la configuració manual l'usuari hauria de saber quin és el proxy més adient i caldria canviar el 'host' i potser també el 'port' dins les opcions del navegador.
• En cas de fallada del proxy principal, permet definir altres equips de reserva i si aquests també 'cauen', estableix la connexió de forma directa a Internet sense cap intervenció de l'usuari. Amb la connexió manual, si el proxy falla l'usuari ha de desactivar-lo o si coneix les dades del proxy 'de reserva' ha de reflexar-ho dins la configuració del navegador.

Relació amb altres caches, treball en jerarquia

Una de les seves millors prestacions és la facilitat de crear jerarquies de caches, per aprofitar al màxim el contingut i les connexions exteriors de tot el conjunt dels proxy d'una mateixa xarxa.

Podem fer que els proxy-cache d'una LAN tingun un sol 'pare' el host proxy.guifi.net. Aquest enllaç el defineix a la línia:
cache_peer proxy.guifi.net parent 8080 0 no-query no-digest default
composada per:

• El nom o adreça IP de l'equip amb el que ens volem enllaçar (proxy.guifi.net).
• El tipus de relació:
• Pare (parent), aquest proxy ens donarà l'objecte que li demanem, tant si el té a la cache com si no. En molts casos ha d'anar a buscar-lo a Internet i el lliurarà al seu fill. Podrem utilitzar un proxy d'un nivell de xarxa superior, com a pare, sempre que el seu administrador ens doni permís per utilitzar la seva línia externa.
• Germà (sibling), aquest proxy només ens donarà l'objecte que li demanem si el té a la cache, mai sortirà a l'exterior a cercar res per als seus 'germans'.

És recomanable per als proxy de la mateixa xarxa que estiguin al mateix nivell (veïns). En aquest cas no cal tenir el permís per utilitzar la seva connexió amb l'exterior.

• El port pel que serveix les peticions HTTP (8080).
• El port pel que serveix les peticions ICP (0 = desactivat), protocol amb transport UDP que permet interrogar prèviament als diferents 'pares' per saber quin d'ells té l'objecte que l'usuari ens demana.

En aquest cas, el fet de tenir un sol 'pare' fa recomanable desactivar-ho per evitar peticions innecessàries.

• Els paràmetres opcionals de la relació
• -- no-query, desactiva la petició de paquets ICP a aquest pare.
• -- no-digest, desactiva la petició del fitxer de digest, innecesari treballant amb un sol pare.
• -- default, utilitza aquest pare com a últim recurs si no té l'objecte demanat.

Dins el fitxer squid.conf.default hi ha una descripció dels altres paràmetres opcionals que poden aplicar-se depenent de la relació 'pactada' entre els proxy.