asi_2251_c02_ud2

Serveis de xarxaEduard Canet i Ricart

Administració de xarxes d'àrea local

Administració de xarxes d'àrea local Serveis de xarxa

Índex

Introducció ............................................................................................... 5

Objectius ................................................................................................... 8

1. Serveis de configuració de xarxa ...................................................... 9

1.1. El servei DHCP ............................................................................ 9

1.1.1. Configuració d’un equip de xarxa ................................... 10

1.1.2. Tipus d’assignacions d’adreces IP .................................. 10

1.1.3. Què és el protocol DHCP ................................................. 12

1.1.4. El model funcional del protocol DHCP .......................... 12

1.1.5. El client DHCP .................................................................. 17

1.1.6. El servidor DHCP ............................................................. 18

1.1.7. Configuració DHCP .......................................................... 20

1.2. El sistema de noms de domini DNS ......................................... 21

1.2.1. Evolució del sistema de noms ......................................... 22

1.2.2. Elements del sistema de noms de domini .................... 22

1.2.3. Els noms de domini d’Internet ....................................... 24

1.2.4. Servidors, zones i delegacions ......................................... 24

1.2.5. La resolució de noms ....................................................... 25

1.2.6. Base de dades DNS: zones i registres de recurs ............ 29

1.2.7. Configuració DNS ............................................................. 36

1.2.8. El client: resolver, /etc/hosts, nsswitch ......................... 37

1.2.9. El protocol DNS ................................................................ 38

1.2.10.Eines per comprovar el funcionament

d’un servidor DNS ............................................................ 39

2. Serveis d'FTP, TFTP, HTTP i CUPS ............................................... 40

2.1. El servei de transferència de fitxers FTP ................................. 40

2.1.1. Tipus de clients i servidors .............................................. 41

2.1.2. Funcionament del servei FTP ......................................... 43

2.1.3. Especificació del protocol FTP ........................................ 44

2.1.4. Ordres del client FTP ....................................................... 46

2.1.5. Aplicacions FTP ................................................................ 47

2.1.6. Seguretat: SFTP i FTPS .................................................... 47

2.1.7. Exemple de connexió FTP ............................................... 48

2.2. El servei de transferència trivial de fitxers TFTP ................... 49

2.2.1. Especificació del protocol TFTP ..................................... 50

2.2.2. Exemple de connexió TFTP ............................................ 52

2.3. El servei HTTP ............................................................................ 53

2.3.1. Especificació del protocol HTTP ..................................... 54

2.3.2. Memòria cau ..................................................................... 57

2.3.3. HTTP segur: HTTPS ......................................................... 57

Administració de xarxes d'àrea local Serveis de xarxa

2.3.4. Proxy servers .................................................................... 58

2.3.5. Exemple de connexió HTTP ............................................ 60

2.4. El servei d’impressió en xarxa.................................................... 61

2.4.1. Components de la impressió en xarxa ........................... 62

2.4.2. Procediments de configuració en xarxa ......................... 64

2.4.3. Protocols d’impressió ....................................................... 65

2.4.4. El servidor CUPS .............................................................. 67

2.4.5. Administració de CUPS ................................................... 68

3. Serveis de correu: SMTP, POP, IMAP, NEWS ............................... 72

3.1. El servei de correu SMTP ........................................................... 72

3.1.1. El format dels missatges (RFC 822) ............................... 75

3.1.2. Funcionament del protocol SMTP .................................. 78

3.1.3. Ordres/respostes SMTP ................................................... 79

3.1.4. Els tipus MIME ................................................................. 82

3.2. El servei POP ............................................................................... 86

3.2.1. El model POP3 .................................................................. 87

3.2.2. Funcionament del POP3 .................................................. 88

3.3. El servei IMAP ............................................................................. 91

3.3.1. Model IMAP ...................................................................... 92

3.3.2. Funcionament IMAP ........................................................ 95

3.4. El servei de notícies NNTP ........................................................ 98

3.4.1. Descripció general ............................................................ 99

3.4.2. Especificació NNTP .......................................................... 101

Administració de xarxes d'àrea local 5 Serveis de xarxa

Introducció

En el crèdit d’Administració de xarxes d’àrea local, el futur administrador

de xarxes aprendrà a mantenir i administrar adequadament xarxes d’ordi-

nadors i els serveis que ofereixen, a administrar els recursos de persistèn-

cia de fitxers, l’accés remot i la seguretat.

Aquesta unitat didàctica (“Serveis de xarxa”) mostra com l’administrador

pot establir serveis que permeten configurar automàticament les dades de

connexió dels equips i el domini al qual pertanyen. També s’explica com

l’administrador pot posar en funcionament i mantenir actualitzats servi-

dors que proporcionin diferents serveis (com el servei de transferència de

fitxers, continguts web, correu, impressió, etc.), i com es configuren

equips per actuar de clients i fer ús d’aquests serveis.

En el nucli d’activitat “Serveis de configuració de xarxa” s’explicarà el fun-

cionament dels protocols DHCP i DNS. El servei DHCP (dynamic host

configuration protocol o protocol de configuració dinàmica d’equips) per-

met la configuració d’adreces IP, màscares, passarel·les per defecte i mol-

tes altres opcions de configuració de manera totalment dinàmica. A cada

equip, se li ha de proporcionar un identificador i la informació necessària

per poder treballar en xarxa i poder accedir a altres equips i altres xarxes.

El servei DNS (domain name system o sistema de noms de domini) per-

met la resolució de noms de domini en adreces IP i a la inversa. La “mà-

gia” amb la qual un usuari indica un nom de domini i s’obté l’adreça

corresponent a aquest domini és obra del DNS.

En el nucli d’activitat “Serveis d’FTP, TFTP, HTTP i CUPS” es tractarà

dels serveis que han fet Internet més popular com són el servei HTTP (el

Web) i el servei FTP (baixada de fitxers). S’hi descriuran altres serveis

com el TFTP, que permet la baixada trivial de fitxers, els servidors proxy

i els mecanismes d’impressió en xarxa.

El serveis FTP i TFTP permeten penjar i baixar fitxers a la xarxa. L’FTP

utilitza TCP, que permet l’accés tant d’usuaris identificats com d’usuaris

anònims. El TFTP utilitza UDP sense confiança i és usat per a baixades en

àrees locals.

El servei més popular avui en dia a Internet és el servei web que utilitza

l’HTTP. La seva popularitat, que es basa en el tractament d’hipertext que

ha acabat incloent vídeo, àudio i multimèdia en general (hipermèdia), l’ha

convertit en una eina a l’abast de tothom. El servei de proxy server és un


servei HTTP que proporciona capacitats de cache i filtratge dels contin-

guts web que sol·liciten els clients.

El servei d’impressió CUPS permet la gestió de servidors d’impressió de

xarxa. Permet publicar impressores en xarxa, accedir a impressores remo-

tes, i definir opcions globals per a tots els usuaris, i particulars per a cada

usuari. Gestiona cues d’impressió d’una sola impressora o de grups d’im-

pressores anomenats classes. Permet polítiques d’autenticació d’usuari,

de xifratge i de seguretat en la transmissió d’informació.

Per oferir seguretat, integritat i confidencialitat als serveis que originària-

ment no en proporcionen, s’han desenvolupat tècniques com SSL i TLS,

que permeten parlar dels serveis HTTPS i FTPS. També han sorgit altres

protocols com l’SSH, que permeten un model de transferència d’informa-

ció xifrada.

En el nucli d’activitat “Servei de correu: SMTP, POP, IMAP i NEWS” s’es-

tudiaran tots els elements que tenen a veure amb el servei de correu. En

el servei de correu diferencia molt clarament entre el mecanisme de

transport dels missatges i els missatges. El mecanisme de transport dels

missatges és el protocol SMTP i és independent del format i el contingut

del missatge. Els missatges originals eren text net ASCII de 7 bits, però ac-

tualment es permet tot tipus de contingut en un missatge. Això és possible

gràcies als tipus MIME que descriuen els missatges.

El protocol POP proporciona un mecanisme d’accés remot per baixar d’un

servidor de correu tots els missatges de l’usuari a un equip local. Un pro-

tocol de recerca remota de correu més evolucionat és el protocol IMAP,

que permet accedir i gestionar el correu i les seves bústies directament en

el servidor.

La immensa popularitat del WWW i la utilització de llistes de correu han

fet perdre importància al servei de notícies news. Basat en el protocol

NNTP, el servei de notícies permetia publicar articles com qui publica

anuncis en un tauler d’anuncis. És un mecanisme per fer pública i com-

partir informació sense que calgui indicar els destinataris.


Objectius

En acabar la unitat didàctica, heu de ser capaços del següent:

1. Automatitzar la configuració de xarxa dels equips utilitzant proto-

cols de configuració de xarxa com DHCP.

2. Dissenyar i implementar un mecanisme d’identificació públic (lo-

cal a intranet o global a Internet) dels equips de la xarxa utilitzant

noms de domini amb el servei DNS.

3. Implantar serveis de xarxa per a la transferència de fitxers i con-

tingut hipermèdia com són els serveis FTP, HTTP, proxy i TFTP.

4. Establir mecanismes d’impressió compartida en xarxa per als usu-

aris, aplicant configuracions personalitzades i gestió de cues.

5. Proporcionar servei de correu als usuaris de la xarxa i permetre’n

l’accés remot.

6. Analitzar el trànsit de xarxa per validar el funcionament esperat.

Monitorar els ports i el contingut de les comunicacions.

7. Gestionar serveis del sistema independentment de la seva funció.

8. Interpretar els procediments que garanteixen la seguretat, la in-

tegritat i la confidencialitat de la informació d’usuari en un siste-

ma de xarxa.

9. Dissenyar procediments que facilitin l’explotació dels recursos

compartits de la xarxa i automatitzin les tasques d’administració

de la xarxa.

10. Relacionar les necessitats de comunicació, accés de dades i docu-

ments d’una organització amb els serveis de comunicació de dades

públiques i privades existents i el cost que representa.

11. Identificar, per mitjà del programa de diagnosi, les causes de fun-

cionament anòmal del sistema i les actuacions que se’n derivin.

12. Definir els criteris i les mesures de caràcter preventiu que s’han

d’aplicar per mantenir operatius els equips i el sistema de comu-

nicació.


1. Serveis de configuració de xarxa

L’administrador de xarxa té la tasca de configurar els equips que la com-

ponen. Això significa configurar els servidors, equips clients, concentra-

dors, encaminadors, etc. Cada equip de la xarxa s’ha d’identificar amb

l'adreça IP corresponent i màscara de xarxa, i generalment disposarà d’un

camí d’accés a Internet. Tant els usuaris com els serveis requeriran l’accés

a d’altres equips identificant-los pel nom de domini en lloc de per l'adreça

IP, més difícil de recordar. Fer això equip per equip resultaria una feina

feixuga i repetitiva si no es disposés de serveis de xarxa que la faciliten.

El servei DHCP permet la configuració d’adreces IP, màscares, passa-

rel·les per defecte i moltes altres opcions de configuració de manera total-

ment dinàmica.

El servei DNS permet la resolució de noms de domini convertint-los en

adreces IP i a la inversa. La "màgia" amb què un usuari indica un nom de

domini i obté l’adreça corresponent a aquest domini és obra del DNS.

1.1. El servei DHCP

El servei DHCP proporciona un mecanisme de configuració centralitzat

dels equips de la xarxa. En lloc de configurar un per un els equips de xarxa

amb adreces i valors estàtics, un servidor DHCP anirà assignant als equips

clients els valors que els corresponguin. Aquesta assignació es fa per un

període de temps finit, passat el qual caldrà renovar-se.

Els principals avantatges d’utilitzar DHCP són, d'una banda, evitar conflic-

tes d’adreces IP, adreces repetides i adreces errònies. Passar equip per

equip a canviar la configuració és molt més pesat i propens a l’error que

fer-ho editant un sol fitxer de configuració en el servidor DHCP. D'altra

banda, poder fer l’administració centralitzada representa un estalvi de

temps i de feina.

La concessió dinàmica d’adreces IP i altres paràmetres de configuració de

xarxa es realitza per a un període de temps determinat, que varia en fun-

ció de les necessitats del client i del servidor.

El servei DHCP simplifica l’administració de la configuració dels

equips de xarxa fent-la centralitzada, dinàmica i amb concessions

per períodes de temps finits.

DHCP i DNS

DHCP és l’acrònim de dynamic host configuration protocol, en català, protocol de configuració dinàmica d’equips.

DNS és l’acrònim de domain name system, en català, sistema de noms de domini.

Avantatges DHCP

El servei DHCP té diversos avantatges:

• Evita errors i conflictes IP.

• Centralitza l’administració.

• Estalvia temps.

• Simplifica l’administració.


Exemples d’ús del servei DHCP

Els següents són alguns exemples d’ús del servei DHCP:

• En una biblioteca que admet connexions Wi-Fi, els clients obtindran concessions per a un tempsreduït, per exemple, minuts.

• Un usuari d’Internet que rep al seu equip de casa una adreça IP dinàmica del seu proveïdor d’ac-cés a Internet (ISP) tindrà una concessió que segurament serà per hores.

• En la xarxa corporativa d’una empresa que s’ha configurat dinàmicament usant DHCP, elsequips rebran concessions dinàmiques per períodes de temps molt llargs, per exemple, dies.

1.1.1. Configuració d’un equip de xarxa

Qualsevol equip que pertany a una xarxa requereix que es configuri amb

uns paràmetres mínims que són l’adreça IP, la màscara i la porta d’enllaç

per defecte. L’adreça IP identifica l’equip de manera única, i la màscara

permet determinar la xarxa o subxarxa en què es troba l’equip. Amb

aquests dos paràmetres n’hi ha prou per tenir connectivitat en la xarxa. Si

es vol disposar d’accés fora de la xarxa pròpia (per exemple, a Internet o a

la resta de la xarxa corporativa) cal definir també la porta d’enllaç prede-

terminada. A part de la configuració bàsica, els equips poden necessitar (i

de fet ho necessiten) més paràmetres de configuració com, per exemple:

el nom del host, el servidor DNS, el fitxer d’iniciació a baixar, etc.

Aquest procés de configuració cal que es faci per a cada equip de la xarxa.

Fer-lo manualment implica configurar equip per equip sense cometre er-

rades en teclejar les adreces i les màscares. Qualsevol canvi en l’estructura

de la xarxa, com per exemple redefinir les subxarxes o modificar algunes

adreces IP, significa tornar a configurar manualment els equips implicats.

És evident que tota aquesta feinada no és agradable per a l’administrador

de xarxa (i és molt avorrida!). Tant si la xarxa corporativa consta de pocs

equips com de molts, cal una solució que permeti automatitzar la configu-

ració de xarxa de cada equip de manera centralitzada.

Com a administradors de xarxa, la gestió centralitzada que ens proporcio-

na DHCP ens permet modificar la xarxa afegint, eliminant i redefinint,

equips amb un cost mínim.

1.1.2. Tipus d’assignacions d’adreces IP

Cada equip de xarxa té assignada una adreça IP que l’identifica de manera

única dins la xarxa. La composició de l’adreça IP i la màscara determina la

Les opcions de configuració de xarxa es poden assignar a cada equip

estàticament o es poden configurar de manera dinàmica utilitzant

DHCP.

L’inconvenient de la configuració estàtica

La configuració estàtica implica configurar els equips un a un. Fins i tot encara que es tingui accés remot als equips (per Telnet o SSH), com que cal modificar la configuració de xarxa no es pot fer assegut des de l’equip de l’administrador sinó que cal anar equip per equip a modificar la configuració.


xarxa o subxarxa a la qual pertany. A més a més es configuren altres parà-

metres de xarxa com la porta d’enllaç predeterminada, servidors DNS,

etc. Això es pot configurar manualment anant equip per equip i introduint

aquesta informació.

Quan la configuració de xarxa d’un equip no es fa manualment i localment

en l’equip sinó que es rep per mitjà d’un servidor DHCP, es diu que l’equip

utilitza una IP dinàmica. Per realitzar configuracions de xarxa dinàmica-

ment caldran un o més servidors de DHCP (a manera de redundància) que

proporcionaran la configuració als equips clients (els que cal configurar).

Per tant, serà una estructura client-servidor. Les adreces IP dinàmiques

que rep el client les podem classificar en dues categories: assignació dinà-

mica de rang i assignació fixa.

El servidor DHCP disposa d’un rang d’adreces que pot assignar als clients

que demanen una adreça IP. Quan el servidor assigna una adreça qualse-

vol del rang al client (a l’atzar) es tracta d’una assignació dinàmica de

rang. El client no sap quina adreça IP tindrà i no hi ha manera de predir

quina adreça se li concedirà en una futura configuració. A cada nova assig-

nació, l’adreça IP pot ser diferent.

Una assignació fixa es produeix quan el servidor DHCP sempre assigna la

mateixa adreça al client. Per assignar sempre la mateixa adreça IP al client

cal que el servidor pugui identificar inequívocament el client (per l’adreça

MAC). El servidor disposa d’una taula amb les correspondències entre les

adreces MAC i les adreces IP fixes.

Els avantatges de disposar d’una IP fixa són que la vostra identificació

a Internet (la vostra adreça IP) no varia i tothom us pot identificar sem-

pre per la mateixa IP. Podeu proporcionar serveis a altres equips, els

clients us identifiquen sempre amb la mateixa adreça sense haver de

recordar en cada moment quina adreça IP teniu avui (com passa en el

cas d’IP dinàmica).

Quan l’adreça IP i els altres paràmetres necessaris de configuració

de la xarxa es configuren equip per equip, manualment, es diu que

tenen IP estàtica.

Quan la configuració de xarxa d’un equip es rep per mitjà d’un ser-

vidor DHCP es diu que utilitza una adreça IP dinàmica. Aquesta

adreça pot variar dins d’un rang d’adreces disponibles per al servi-

dor DHCP o pot ser fixa.

Reconfiguració d’una xarxa

Imagineu la diversió de l’administrador d’una xarxa corporativa de 1.000 equips amb adreces estàtiques quan cal reconfigurar-la en un cap de setmana.

MAC

Cada interfície de xarxa s’identifica de manera única físicament per l'adreça MAC (media acces control, adreça d’accés al medi).

DNS dinàmic

Hi ha serveis de DNS dinàmic (DDNS) que permeten assignar un nom de domini a equips amb adreça IP dinàmica.


1.1.3. Què és el protocol DHCP

El servei DHCP és un servei del tipus client-servidor que proporciona

la configuració de xarxa als clients que ho sol·liciten. Proporciona els

paràmetres bàsics de xarxa com l’adreça IP, la màscara de xarxa i la

porta d’enllaç, i també d’altres paràmetres necessaris per a una conne-

xió en una xarxa IP. Es tracta d’un protocol de la capa d’aplicació del

model TCP/IP.

La configuració dinàmica d’equips de xarxa es va iniciar amb el proto-

col BOOTP (BOOT strap protocol, protocol d’arrencada). Un protocol

més bàsic que principalment permetia definir l’adreça IP, la màscara

de xarxa i la passarel·la per defecte per al client. El protocol BOOTP

(RFC 951, any 1985) és un protocol pensat per proporcionar automàti-

cament la IP a clients de xarxa en el procés d’arrencada. Originària-

ment s’utilitzava per a estacions de treball sense disc que obtenien la

configuració de xarxa del protocol BOOTP i també obtenien el nom d’un

fitxer d’arrencada que s'havia de baixar per mitjà del TFTP, que usual-

ment era el sistema operatiu.

El BOOTP va donar pas al protocol DHCP, que n’és una evolució amb mol-

tes més prestacions. El DHCP sorgeix l’octubre del 1993 a través de l'RFC

1531. Ràpidament evoluciona per mitjà de diverses RFC, com l'RFC 1541

el mateix any 1993, que serà substituïda per l'RFC 2131 el març del 1997.

Aquest document és la base del protocol DHCP actual. A grans trets, el

protocol es descriu en l'RFC 2131 per a xarxes Ipv4, el conjunt d’opcions

de configuració de DHCP es descriuen en l'RFC 2132, i l’especificació de

DHCP per a xarxes Ipv6 és en l'RFC 3315.

1.1.4. El model funcional del protocol DHCP

El protocol DHCP descriu el diàleg que es produeix entre client i servidor

per a la concessió de configuracions IP. En una xarxa amb configuració

d’equips dinàmica, un o més servidors DHCP escoltaran les peticions dels

clients en el port 67. Els clients DHCP sol·licitaran al servidor DHCP una

configuració IP, i començarà un procés de negociació que ha d’acabar (si

tot va bé) amb la concessió d’una adreça IP al client. Els servidors parlen

al port 68 dels clients.

El protocol DHCP està basat en l’arquitectura de serveis client-

servidor i utilitza com a transport el protocol UDP de la pila de

protocols TCP/IP. El servidor DHCP es comunica amb els client

utilitzant paquets UDP, que rep en el seu port 67 i envia al port

68 del client.

L'RFC 951 és el document base que descriu el protocol BOOTP.

RFC de DHCP

Principals RFC dedicades a DHCP:

• RFC 2131. Març 1997. DHCP dynamic host configuration protocol.

• RFC 2132. DHCP options.

• RFC 3396. Encoding long options.

• RFC 4361. No especific client identifications for dhcpv4.

• RFC 3315. DHCPv6 dinamic host configuration protocol Ipv.

Ports DHCP

El protocol DHCP utilitza UDP en la capa de transport. Utilitza dos ports:

• Port 67, on escolta el servidor.

• Port 68, on escolta el client.


La negociació que s’estableix es pot definir a grans trets de la manera

següent:

1) El client sol·licita una adreça IP (de fet, una configuració de xarxa).

2) El servidor mira les adreces IP disponibles dins del rang d’adreces di-

nàmiques de què disposa per concedir i n’ofereix una al client.

3) Si el client l’accepta, envia una sol·licitud al servidor per fer-la seva.

4) Si al servidor li sembla bé, accepta la petició del client i li confirma que

pot utilitzar aquesta IP que li concedeix per un període de temps limitat.

La concessió de l’adreça IP és per un període de temps establert pel servi-

dor. Això significa que, transcorregut aquest període, el client haurà de re-

negociar la concessió en un procés similar al descrit anteriorment. En la

figura 1 es pot veure el diàleg de quatre fases client-servidor.

El procés real, però, és més detallat. El podem repassar: consta principal-

ment de quatre parts: la petició del client o discovery, l’oferta del servidor

o offer, l’acceptació de l’adreça IP pel client o request, i la confirmació del

servidor o acknowledgement. A part d’aquest tipus de missatges, el protocol

DHCP en defineix d’altres com el de petició d’informació o information i

el d’alliberament de l’adreça IP o releasing.

Els següents són els tipus de paquets DHCP:

• DHCP discover.

• DHCP offer.

• DHCP request.

• DHCP ack / DHCP nack.

• DHCP decline.

• DHCP release.

• DHCP information.

DHCP discover

En un procés de configuració IP d’un client de DHCP el paquet DHCP dis-

cover és el primer que s’envia. L’envia el client per tal de demanar una

configuració IP a algun servidor. Generalment, el client s'acaba d’inicialit-

zar i vol obtenir una configuració dinàmica de xarxa. El client no sap a qui-

na xarxa pertany (no té adreça IP ni màscara de xarxa) i tampoc sap quins

servidors DHCP hi ha en la xarxa (si n’hi ha algun).

Per tant, el client genera un paquet de difusió (broadcast) destinat a tots

els equips de la xarxa on sol·licita una configuració IP. En la xarxa pot ha-

UDP en les transmissions DHCP

L’intercanvi d’informació entre client i servidor no és gaire gran (poc volum de dades) i no requereix un flux permanent (una conversa continuada). És per això que el protocol que s’utilitza en les transmissions DHCP és l’UDP.

Figura 1. Model funcional del protocolDHCP

Broadcast

Una difusió o broadcast s’adreça a la IP 255.255.255.255 o a l’adreça MAC FF:FF:FF:FF que és acceptada per tots els equips.


ver-hi cap, un o més d’un servidors DHCP per atendre aquesta petició. És

responsabilitat de l’administrador de xarxes configurar correctament l’es-

tructura i els serveis de xarxa de forma que si defineix clients de DHCP hi

hagi servidors DHCP que atenguin les seves peticions.

DHCP offer

En rebre una sol·licitud de configuració d’un client (DHCP discovery), un

servidor DHCP mira d’atendre-la proporcionant una IP del rang d’adreces

dinàmiques que gestiona (hi pot haver més d’un servidor DHCP en la ma-

teixa xarxa).

El servidor tracta d’assignar una IP del conjunt o rang (també anomenat

pool) d’adreces dinàmiques que gestiona al client. Per fer-ho, ha de mirar

quines de les adreces li queden lliures i disponibles per concedir al client.

Cada vegada que el servidor concedeix una IP a un client, ho anota en un

fitxer de registre de les concessions efectuades. Cada vegada que finalitza

una concessió, el servidor pot tornar a utilitzar la IP per a un altre client.

El mecanisme que utilitza el servidor per escollir la IP dins del conjunt

d’adreces IP disponibles varia en funció del programa de servidor que

s’utilitzi. A més a més es poden configurar innumerables opcions del ser-

vidor per establir com s'han de fer les concessions. Un cas típic és el de les

adreces fixes. A un determinat client sempre se li assigna la mateixa IP.

Per això cal disposar de la llista d’adreces MAC dels clients als quals es vol

assignar una IP fixa.

El servidor selecciona una IP disponible i la reserva per al client (encara

no està assignada). Tot seguit envia un paquet DHCP offer (unidestinació

o unicast) al client amb tota la informació de configuració requerida.

L’adreça IP i MAC origen identifiquen el servidor que fa l'oferta. El desti-

natari s’indica per la seva adreça MAC (que és coneguda). El camp IP del

destinatari és l’adreça IP que el servidor ofereix (penseu que el client en-

cara no té IP). Un altre concepte important és per quant de temps es rea-

litza la concessió. El paquet inclou més camps per completar la resta de

configuració de xarxa, per exemple, la porta d’enllaç per defecte, els servi-

dors DNS, etc.

DHCP request

Quan el client rep una oferta de configuració IP per part d’un servidor, la

pot acceptar o rebutjar. Si el client no accepta l’oferta, simplement realit-

Tota concessió (o lease) DHCP és per un període determinat de

temps i un cop transcorregut cal renovar-la.

Diversos servidors DHCP

Es pot configurar més d’un servidor DHCP tant per a còpia de seguretat o backup com per incrementar el rendiment en compartir la càrrega de les peticions.

Tipus d’adreçament

Hi ha diversos tipus d’adreçament:

• Unidestinació o unicast: a un equip

• Multidestinació multicast: a un conjunt d’equips

• De difusió o broadcast: a tothom.


zarà un DHCP discovery de nou. Això és suficient perquè el servidor s’ado-

ni que l'oferta ha estat rebutjada.

Si el client accepta l’oferta, ho ha de comunicar al servidor. El mecanisme

per fer-ho és mitjançant un paquet DHCP request enviat un altre cop per

difusió. A hores d’ara, el client encara no disposa de l’adreça IP per utilit-

zar-la. El servidor l’ha reservat però encara no ha donat el sí definitiu per-

què sigui concedida al client.

El motiu pel qual el client demana quedar-se la concessió (DHCP request)

que ha rebut utilitzant difusió és fer públic a tothom de la xarxa que ha ac-

ceptat una oferta d’un servidor DHCP concret. Recordeu que la petició del

client es fa per difusió i, per tant, pot rebre ofertes de diferents servidors

DHCP. Quan accepta una de les ofertes, no ha de dir res als altres servi-

dors que ha refusat. Simplement fent pública quina oferta accepta, la res-

ta de servidors DHCP entenen que la seva oferta s’ha rebutjat.

DHCP acknowledgement (DHCPACK/DHCPNACK)

L'últim pas en una negociació DHCP bàsica el realitza el servidor quan fi-

nalment autoritza la concessió enviant el paquet DHCPACK (DHCP akc-

nowledgement). A partir d’aquest moment, el client sí pot fer ús de

l’adreça IP i de la configuració de xarxa rebuda. DHCPACK inclou tota la

informació referent a la durada de la concessió i les dades necessàries per

gestionar quan expira.

El servidor anotarà en el registre de concessions la que acaba de realitzar

i detallarà tots els aspectes d'aquesta, en especial el temps de concessió.

El paquet d’acceptació de la concessió DHCPACK és un paquet unidesti-

nació adreçat a la MAC del client. Recordeu que el client encara no disposa

d’una adreça IP vàlida, en disposarà en rebre el DHCPACK.

Quan un servidor DHCP detecta que la IP que havia reservat per a un client

i que li anava a concedir ja està en ús, el servidor envia al client un paquet

DHCPNACK i indica la no-autorització de la concessió. El client que rep

un DHCPNACK ha de tornar a iniciar tot el procés de negociació comen-

çant un altre cop pel DHCP discovery.

Com és possible que algun equip de la xarxa utilitzi una adreça IP que for-

ma part del conjunt d’adreces IP dinàmiques que reparteix el servidor

DHCP? La resposta és senzilla: perquè hi ha algun equip mal configurat.

DHCP decline

Per la seva part, el client també pot examinar l’adreça IP oferta pel servi-

dor per comprovar si està en ús o no. Pot fer altres proves per veure si li

ACK i NACK

ACK i NACK són dos acrònims usuals en el món de la informàtica que signifiquen confirmació (acceptació) i no-conformitat (refús) respectivament.

Exemple de mala configuració d’un equip

Un exemple de mala configuració és la d’un equip que s’ha engegat amb una adreça IP estàtica errònia que se solapa amb les adreces IP que reparteix el servidor. El mecanisme usat per comprovar si l’adreça IP ja està essent utilitzada és fer un ping. Si ningú no respon és que està lliure.


sembla correcta o no l’oferta rebuda del servidor. Per exemple, en el cas

de renovació d’una IP el client pot rebre una IP diferent a la que utilitza i

no li interessa. En aquests casos, el client pot enviar un paquet DHCP de-

cline al servidor per indicar que la seva oferta ha estat rebutjada.

DHCP release

Quan un client ja no necessita més l’ús de la configuració IP que ha rebut,

la pot alliberar enviant al servidor un paquet DHCP release. En fer-ho, el

servidor afegeix l’adreça IP al conjunt d’adreces dinàmiques que té dispo-

nibles. També fa l’anotació pertinent en el registre de concessions (leases)

per indicar que ha finalitzat l’ús de l’adreça. De totes maneres, molt sovint

el client no pot arribar a emetre aquest paquet perquè és apagat per l’usu-

ari sense deixar temps al sistema per alliberar la IP.

DHCP information

En tot moment el client pot sol·licitar més informació sobre la configura-

ció de xarxa al servidor utilitzant un paquet DHCP information. En el pa-

quet DHCP offer que el servidor envia al client, consten les informacions

generals de configuració de xarxa que es trameten en l’oferta: adreça IP,

màscara de xarxa, porta d’enllaç predeterminada, servidor DNS, fitxer a

baixar i molts altres paràmetres que poden estar configurats per enviar-se

en l'oferta. El client pot tornar a demanar al servidor la informació

d’aquests paràmetres o pot sol·licitar informació per a la configuració

d’altres paràmetres (WINS, NetBIOS, hostname, etc.). El client només

pot realitzar una petició d’informació DHCP information al servidor un

cop ja està configurat.

Petició de renovació/concessió d’una IP concreta

Els procés de quatre fases usual de DHCP consistent en discovery/offer/

request/ack es produeix quan el client sol·licita una IP de nou. Sabem que

les concessions són per a un interval de temps, passat el qual cal que el

client en demani la renovació. El procés de renovació és simplificat. El client

demana continuar usant la mateixa IP amb un paquet DHCP request, i el

servidor li concedeix o no amb els paquets DHCP ACK/NACK.

Un altre cas és un client que demana usar (renovar) una adreça IP que el

servidor no li pot concedir (està en ús, no és del rang que gestiona, etc.).

En aquesta situació, el servidor envia un DHCP NACK.

Atacs al funcionament de DHCP

Com tot servei de xarxa, el servidor DHCP és susceptible de patir atacs

mal intencionats. L’atac més fàcil i clàssic és el DoS o de denegació de ser-

macchange

L’ordre GNU macchange permet (mascarade) emmascarar l’adreça MAC pròpia. Compte! No feu dolenteries.


vei. Consisteix a inundar de peticions un servidor per tal de saturar-lo i

bloquejar-ne el funcionament. Un client pot realitzar innumerables peti-

cions DHCP discovery fingit que és clients diferents (emmascarant la

seva MAC) amb la intenció d’esgotar les adreces IP disponibles del servidor

o simplement amb la intenció de sobrecarregar-lo amb tantes peticions que

no doni l’abast a atendre-les o que ho faci lentament.

Un altre tipus d’atac consisteix a falsejar la informació que s’envia al client.

Recordem que el client fa una sol·licitud d’IP en forma de difusió (broadcast)

i la seva petició pot ser atesa per un o més servidors DHCP. Un dels servi-

dors DHCP pot ser un atacant que intentarà proporcionar informació de

configuració falsa al client. Per exemple indicant un servidor DNS també

maliciós. Aquest pot falsejar les identitats de les màquines de la xarxa i,

quan el client s’adreça a la seva entitat bancària, el servidor DNS en realitat

li ha proporcionat una IP d’una màquina que falseja la de l’entitat bancària.

Perillós, oi?

Per posar remei a la inseguretat en la comunicació client-servidor DHCP,

el protocol permet utilitzar mecanismes d’autenticació i xifratge. Aquests

mecanismes queden fora de l’abast d’aquesta explicació.

Conflictes amb les adreces IP

Un dels principals motius per utilitzar DHCP és simplificar el procés de

configuració de xarxa i minimitzar els conflictes per encavalcament

d’adreces IP. Per desgràcia, això no garanteix que no es puguin produir

conflictes. Per exemple, ens podem trobar en situacions en què dues mà-

quines diferents tinguin la mateixa IP per una simple mala configuració

del servidor DHCP. Un altre cas típic és el d'un client que s’ha configurat

ell mateix una IP estàtica quan en la xarxa ja hi havia un equip que utilit-

zava la mateixa adreça IP assignada pel servidor DHCP.

Un problema habitual per als administradors poc experimentats és de-

finir una configuració de xarxa local al client (hostname, servidor DNS,

porta d’enllaç a utilitzar, etc.) però demanar l’adreça IP dinàmicament.

La configuració dinàmica no és solament la IP i la màscara, sinó que el

servidor DHCP pot proporcionar altres paràmetres de xarxa que sobre-

escriuran els que el client tenia definits localment (aquest és l’objectiu

de DHCP!).

1.1.5. El client DHCP

Un equip client DHCP és un equip que sol·licita la IP i altres paràmetres

de configuració de xarxa a un servidor DHCP en lloc de tenir-los definits

localment en l’equip.

Tipus d’atacs DNS

Clients no autoritzats: accés a servidors DNS per part de clients no autoritzats.

Servidors no autoritzats: servidors DNS impostors que suplanten els vertaders servidors.

La configuració rebuda per DHCP sobreescriu la configuració local del client.


Si connecteu el vostre equip informàtic a la xarxa Internet per mitjà

d’un ISP, segurament rebreu una IP dinàmica del vostre proveïdor.

Quan es realitzava una trucada telefònica amb mòdem i usant el proto-

col PPP (point to point protocol, protocol punt a punt), el proveïdor

proporcionava una IP dinàmica. Si utilitzeu ADSL i un encaminador o

router, segurament l'encaminador us proporciona una IP dinàmica pri-

vada a l’ordinador de casa. Al mateix temps, l'encaminador obté una IP

dinàmica pública del proveïdor. Aquestes adreces IP dinàmiques són fi-

xes (sempre les mateixes) o dinàmiques de rang (pot ser qualsevol IP

del conjunt d’adreces IP que té disponibles per concedir el servidor

DHCP).

El client DHCP ha de tenir en funcionament un dimoni (daemon) en-

carregat de la gestió de les tasques DHCP per part del client. El progra-

ma client realitza la part de negociació encarregada al client (DHCP

discovery, request) i també porta un registre de les concessions (lea-

ses) rebudes. Aquest registre és el que utilitza el client per tornar a de-

manar la mateixa IP que tenia anteriorment. Un cop rebuda la

concessió, el programa client queda "adormit", pendent de tornar-se a

executar automàticament quan calgui renegociar la concessió. Sense

intervenció de l’usuari, el programa client s’activa i segueix el procedi-

ment necessari per renegociar l’adreça IP cada cop que el temps de la

concessió s’exhaureix.

Els programes client varien d’un sistema operatiu a un altre, i la manera

d’executar-los també. Generalment es disposa d’un client executable en

mode text o ordres i d’una interfície gràfica (GUI, graphics user interface

o interfície gràfica d’usuari) per a la configuració. No cal dir que els siste-

mes Windows tendeixen a la configuració gràfica usant finestres i a la con-

figuració i execució interna d’amagat de l’usuari. Normalment, en els

sistemes GNU/Linux, la configuració es fa usant fitxers de text com a op-

cions en l’ordre d’execució. La interfície gràfica acostuma a ser un frontal

(front-end) per cridar l'ordre. Segons sigui el sistema operatiu es pot con-

sultar el fitxer de registre de les concessions rebudes pel client, el fitxer

de concessions, més o menys detalladament.

Generalment el programa client es pot configurar per definir-ne el com-

portament en la comunicació amb el servidor, informació a demanar, in-

formació a proporcionar al servidor, opcions per defecte, etc.

1.1.6. El servidor DHCP

L’administrador de xarxa és l'encarregat de pensar la ubicació del servidor

o servidors DHCP en l’estructura corporativa. Com més complicada sigui

la topologia de la xarxa, més difícil en serà la gestió. Una xarxa corporativa

IP pública / IP privada

La diferència entre una IP pública i una IP privada és que la pública és visible per a tots els equips d’Internet, mentre que la privada és visible només dins de la pròpia xarxa local.


bàsica pot disposar d’un únic servidor DHCP que ofereix els seus serveis

a tots els equips de la xarxa. Els clients poden estar en una mateixa sub-

xarxa o en diverses subxarxes, però totes amb connectivitat amb el servi-

dor DHCP. Aquest també pot ser l’esquema d’una xarxa privada a casa, on

un encaminador (el de l'ISP, per exemple) proporciona el servei DHCP a

tots els ordinadors de la casa.

Si la xarxa corporativa creix i passa a tenir subxarxes segmentades amb ta-

llafocs les unes de les altres, la configuració del servidor DHCP es compli-

ca. Si es vol continuar amb un únic servidor per a tota la xarxa, caldrà que

els tallafocs (firewalls) deixin passar els paquets DHCP entre les subxar-

xes i el servidor. Una altra opció és posar un servidor DHCP per a cada sub-

xarxa o grups de subxarxes. Fent-ho així, l’administració de cada servidor

és més senzilla però hi ha més servidors a administrar. Una xarxa amb

una casuística completa és la que té diversos servidors DHCP per a diver-

ses parts de la xarxa i tallafocs entre clients i servidors que han de perme-

tre el pas de paquets DHCP.

Si el servidor DHCP és l’encarregat de donar adreces IP als clients, qui li

proporciona una adreça IP a ell? O bé un altre servidor DHCP (i podríem

tornar a fer la mateixa pregunta indefinidament) o bé l’administrador.

Usualment, en una xarxa corporativa el servidor DHCP utilitza una IP es-

tàtica definida per l’administrador. Això li permet estar sempre disponi-

ble per als clients amb la mateixa IP i no el fa dependre d’un altre servidor

extern.

Hi ha diversos programes servidors DHCP, en mode text, en mode gràfic,

en mode "màgic" (no es veu què fan) i en mode Unix (tot basat en fitxers

de text). Cada administrador treballa amb les seves eines preferides. Les

tasques bàsiques per aprendre a utilitzar un servidor DHCP són observar/

llistar la configuració actual, activar/aturar el servei, modificar la configu-

ració, monitorar els logs (registre de successos del servei).

Com la majoria de serveis de xarxa, el servei DHCP és un servei que s’exe-

cuta en segon pla en forma de dimoni. El servidor DHCP sempre està en-

gegat escoltant en el port 67 les peticions que rep dels clients. Quan rep

una petició entrant, el programa executable del servidor DHCP la proces-

sa i posa en marxa tot el mecanisme DHCP pertinent per tornar a escoltar

noves peticions. De fet, el servidor sempre escolta peticions i les processa

simultàniament (segons la configuració).

Els fitxers del registre del servei, on s’anoten les concessions, permeten

mantenir la informació encara que el servei s’aturi o que el servidor s’apa-

gui. En tornar a engegar es llegiran de nou els fitxers de registres per tal

de saber quines són les concessions que s’havien realitzat.

Els fitxers de logs (successos) recullen els esdeveniments que es volen monitorar.

Els fitxers de concessions permeten mantenir la coherència de l’assignació d’adreces IP entre aturades del servei.


1.1.7. Configuració DHCP

Per configurar el servei DHCP primer cal saber observar i manipular la

configuració de xarxa existent:

1) Observar/llistar la configuració de xarxa actual.

2) Comprovar l’estat del servei de xarxa.

3) Activar/desactivar el servei de xarxa.

4) Monitorar el servei i el procés del servidor.

Les tasques principals per configurar un servidor DHCP són les següents:

• Instal·lar el programari del servidor DHCP.

• Activar/desactivar el servei de DHCP.

• Observar/llistar la configuració actual del servidor DHCP.

• Modificar la configuració del servidor DHCP.

• Monitorar els logs del servei DHCP i els fitxers de registre de les con-

cessions (leases).

La configuració dels clients DHCP consisteix en el següent:

• Configurar el client per rebre dinàmicament una adreça IP. Mecanis-

me d’activar/desactivar.

• Sol·licitar/renegociar una nova IP del servidor DHCP.

• Observar/llistar el fitxer de registre de les concessions rebudes.

• Activar/desactivar el servei de xarxa en el client.

Un exemple de fitxer de configuració del servei DHCP és el que es mostra

a continuació.

#a) opcions globals del servidor DHCP (usuals)ddns-update-style interim;ignore client-updates;

# b) definició de la xarxa per a la que s’ofereix el servei DHCPsubnet 192.168.0.0 netmask 255.255.255.0 {

# opcions genèriques per tots els equips de la xarxaoption routers 192.168.0.1;option subnet-mask 255.255.255.0;option domain-name "domain.org";option domain-name-servers 192.168.1.1;

# definició del rang de ips dinàmiques a usar # i dels temps de les concessionsrange dynamic-bootp 192.168.0.128 192.168.0.254;default-lease-time 21600;max-lease-time 43200;

# c) Opcions d’equips individuals# el servidor ns obté sempre una adreça fixa basada en MAChost ns {

next-server marvin.redhat.com;hardware ethernet 12:34:56:78:AB:CD;fixed-address 207.175.42.254;

}}


En aquest fitxer de configuració es pot veure que hi ha tres àmbits dife-

rents de definició:

1) Opcions globals en el servidor DHCP. Són opcions que indiquen al ser-

vidor la seva manera d’actuar. També són opcions generals que cal aplicar

a totes les concessions que es realitzin, independentment de la xarxa o

equip que siguin.

2) Definicions i opcions de xarxa. Es defineixen tantes xarxes diferents

com subxarxes ha d’atendre el servidor. Cada definició de subxarxa consta

de la IP de la xarxa i la màscara corresponent. Entre claus s’indiquen totes

les opcions específiques per a les concessions de les adreces IP correspo-

nents a aquesta subxarxa. Una opció característica és indicar el rang (o pool)

d’adreces dinàmiques a usar, la porta d’enllaç predeterminada, el servidor

de noms, etc.

3) Opcions d’equips individuals. Dins d’una subxarxa es poden definir op-

cions per a equips individuals. Cal identificar els equips per la seva adreça

MAC i, entre claus, indicar les opcions que els són específiques. Això per-

met assignar adreces fixes dinàmicament (equivalent al protocol BOOTP)

usant les opcions de maquinari Ethernet i fixed-address.

Les opcions globals de configuració DHCP es poden definir amb valors di-

ferents dins d’una xarxa en concret, i dins d’un equip també es poden de-

finir opcions amb valors diferents als definits per la xarxa o globalment.

Tal com passa en els llenguatges de programació, preval el valor més in-

tern, el de host sobre el de xarxa i el de xarxa per sobre del global.

1.2. El sistema de noms de domini DNS

El sistema de noms de domini DNS (domain name system) proporciona

un mecanisme eficaç per fer la resolució de noms de domini a adreces IP.

Com a usuaris (humans) ens és més fàcil adreçar-nos a un nom de domini

(de host, de web, de servidor de correu, etc.) utilitzant un text identificatiu

(per exemple, www.fpoberta.net) que no pas a l’adreça IP pertinent (per

exemple, 213.73.40.230). El servei DNS no solament permet fer la resolu-

ció de noms de domini a adreces IP sinó també la resolució inversa. És a

dir, a partir d'una IP esbrinar-ne el nom de domini.

El servei DNS proporciona independència del nom de domini respecte a

la IP. Així un domini pot canviar d’IP de manera transparent per als usua-

ris del domini. Fins i tot és usual que un domini s’identifiqui amb més

d’una IP com a mesura de redundància contra la caiguda del sistema o

com a balanceig de càrregues. Altres serveis proporcionats pel DNS són la

identificació dels servidors de correu d’un domini, dels host, etc.


1.2.1. Evolució del sistema de noms

El problema d’identificar els equips es produeix des de bon principi de

l’existència de les xarxes d'ordinadors i no és específic de les xarxes TCP/IP.

Cal un mecanisme en “llenguatge humà” per identificar els equips de la

xarxa. En especial els que proporcionen serveis als altres equips i usuaris.

En la xarxa inicial ARPANET, els equips ja rebien un nom. Aquests noms

es feien públics per mitjà d’un fitxer centralitzat que contenia els noms de

tots els equips de la xarxa i la seva identificació. Aquest fitxer era el fitxer

hosts.txt (en sistemes Linux, conegut com a /etc/hosts).

En una xarxa petita es pot generar un fitxer amb el nom i identificador IP

de tots els host, centralitzat en un servidor, i encarregar-se de distribuir

còpies d’aquest fitxer a tots els equips de la xarxa. Però aquest model de

coneixement no és escalable. Si la xarxa creix és impossible de mantenir.

Utilitzar aquest model significaria que hi ha un equip que centralitza els

noms de tots els host d’Internet en un sol fitxer! D'altra banda, també sig-

nificaria que aquest fitxer s'ha de repartir entre tots els equips d’Internet

perquè sàpiguen com es diuen els altres equips. Evidentment cal una altra

solució.

1.2.2. Elements del sistema de noms de domini

El servei DNS permet identificar qualsevol equip en la xarxa i assegurar-

se que no hi ha col·lisions, és a dir, noms duplicats. Es basa en una es-

tructura jeràrquica de noms en forma d’arbre on l’arrel és el node o do-

mini arrel del qual deriven tots els altres nodes. Aquest es divideix en

altres dominis com, per exemple, .com, .edu, .org, .cat, etc. Al seu torn,

cada domini es pot dividir en altres subdominis i així successivament.

Les rutes s’indiquen començant pel subdomini més intern cap al node

arrel (mail.fpoberta.net).

El 1983 sorgeix el domain name system (DNS) per aportar una so-

lució escalable i pràctica. El DNS es basa en una base de dades de

noms de domini jeràrquica i distribuïda. Jeràrquica perquè s’orga-

nitza en una estructura de dominis que es poden compondre de sub-

dominis que també es poden dividir en subdominis i així fins a 127

nivells (originàriament). Aquests dominis són gestionats per servidors

DNS responsables de cada zona. És una base de dades distribuïda per-

què la informació no està tota junta en un sol repositori central sinó

que la informació es troba repartida per parts en els servidors DNS

d’Internet. Cada servidor DNS autoritari conté la base de dades de

la seva zona.

ARPANET

ARPANET és la xarxa de commutació de paquets que va desenvolupar el Departament de Defensa dels Estats Units i que va ser la predecessora d’Internet.

Problemes d’actualització d’una xarxa

Imagineu els problemes que es presenten en voler fer arribar un mateix fitxer a tots els hosts. Hi haurà inconsistències amb equips que han rebut l’actualització i altres que no. El trànsit de copiar el fitxer en cada equip. Un nou equip a Internet vol dir escriure de nou el fitxer i tornar-lo enviar a tothom!

Arbres dels sistemes DNS i de fitxers

El sistema de noms de domini té una estructura similar a l’arbre que s’utilitza per representar un sistema de fitxers. La diferència rau en el fet que les rutes dels sistemes de fitxers s’indiquen des de l’arrel fins al node (per exemple, /etc/bind/bind.conf), i en canvi en el DNS les rutes s’indiquen del node a l’arrel (ns1.fpoberta.net).


Els nodes s’identifiquen per un text (el nom de domini) que no es pot repetir

en el mateix nivell, però sí en altres llocs de l’arbre de l’espai de noms. El ma-

teix passa amb els fitxers: no hi pot haver dos fitxers amb el mateix nom en

el mateix directori, però sí en ubicacions diferents. Un domini és el node in-

dicat i tota la resta de l’arbre que penja d’aquest node (penseu en l’exemple

d’un directori: si es vol copiar un directori, s’entén que està format pel mateix

directori i tots els subdirectoris que conté). S'entén per espai de noms el con-

junt de tots els dominis que formen l’arbre DNS.

Dominis d’alt nivell

Els següents són exemples de dominis d’alt nivell d’alguns països:

• CAT: Catalunya.• AD: Andorra.• AQ: Antàrtida.• GB: Gran Bretanya.• UK: Regne Unit.• IM: illa de Man.• MS: Montserrat.• PF: Polinèsia Francesa.• PS: autoritat palestina.

L’estructura en arbre (jeràrquica) de l’espai de noms proporciona un me-

canisme d’identificació únic d’un domini. No pot existir cap domini que

tingui exactament el mateix nom absolut FQDN (full qualified domain

name o nom de domini complet). Els dominis es llegeixen des del node a

l’arrel. Així un domini que correspongui al departament d’administració

de l’organització FP-Oberta dins del domini net s’identifica, per exemple,

com a admin.fpoberta.net. Si ens fixem en el domini anterior, veurem

que acaba en punt, és una manera d’indicar el domini arrel. El domini ar-

rel es defineix com un domini sense etiqueta, o millor amb la cadena buida

com a etiqueta. Això provoca que els dominis que s’indiquin de manera ab-

soluta acabin amb el caràcter punt.

Un domini absolut o FQDN és el que inclou tots els nodes des del domini

fins a l’arrel (inclosa en forma de punt final). Un domini relatiu no inclou

El sistema de noms de domini d’Internet DNS utilitza els elements

següents:

• Espai de noms. El conjunt de tots els dominis (l’arbre).

• Domini. Text identificatiu d’un domini.

• FQDN. Nom de domini absolut començant pel node i acabant en

l’arrel.

• Domini absolut. (FQDN) els dominis absoluts acaben en punt (.).

• Domini relatiu. Nom de domini sense qualificar.

• Domini arrel. Domini del qual deriven tots els altres. S’indica

amb un punt o amb la cadena buida.

Caràcters en els noms de domini

L’estàndard DNS indica que els noms de domini han de ser de seixanta-quatre caràcters com a màxim, i només poden incloure caràcters llatins, dígits del 0 al 9 i el guió. Les majúscules i minúscules són indiferents.

Hi ha mecanismes com l’IDNA (an internationalized domain name o noms de domini internacionalitzats) per permetre utilitzar altres alfabets en els noms de domini.

El punt final en els noms de domini

La majoria de vegades escrivim els dominis com si fossin absoluts, però són relatius al node arrel perquè no posem el punt final. Un altre cop es pot fer l’analogia amb les rutes relatives i les rutes absolutes del sistema de fitxers.


l’arrel i pot ser relatiu al domini actual. Per exemple, dins del domini de

l'FP-Oberta el domini inf (del departament d’informàtica) és un nom rela-

tiu que fa referència al nom absolut inf.fpoberta.net.

1.2.3. Els noms de domini d’Internet

A Internet els noms de dominis segueixen una estructura basada en els

seus inicis però que ha anat evolucionant. El node arrel es va dividir en un

conjunt de subdominis anomenats TLD (top level domains o dominis

d’alt nivell). Aquests dominis eren com, edu, gov, mil, org, net i int. Pos-

teriorment se’n van afegir d’altres com cat, name, biz, info, pro, aero,

coop i museum. Es volien organitzar els dominis per funcionalitat posant

les empreses en els .com, les organitzacions en els .org, etc. Es va veure,

però, la necessitat de poder agrupar els dominis de manera geogràfica i

van sorgit els famosos identificadors de país. Per a cada país es va generar

un TLD de dos caràcters utilitzant el ja existent estàndard internacional

ISO 3166 (els famosos .es, .fr, etc.).

Els servidors arrel són crucials per al funcionament del DNS, ja que conei-

xen tots els dominis de primer nivell. Han d’admetre un gran volum de

consultes i per això n’existeixen tretze repartits per tot el món. A més a

més, d’aquests tretze, alguns tenen rèpliques en diversos continents uti-

litzant un sistema anomenat anycast.

1.2.4. Servidors, zones i delegacions

De bon començament sabem que el sistema de noms de domini està basat

en una arquitectura client-servidor en què els clients faran preguntes del

tipus “quina IP té aquest domini?”, i els servidors miraran de contestar-

les. Els servidors de noms DNS són els programes que emmagatzemen i

gestionen la informació en la base de dades d’una part de l’espai de noms

anomenada zona.

Primerament hem de descriure què és una zona. Una zona és part de l’es-

pai de noms de domini gestionada per un o més servidors DNS. Els servi-

dors que gestionen la zona tenen informació completa sobre la zona i es

diu que tenen autoritat respecte a ella. De bon principi podríem pensar

que un servidor DNS gestiona un domini i que una zona és el mateix que

un domini, però això ho ha de ser necessàriament així. Un domini es divi-

deix en subdominis per facilitar-ne l’administració, i cada part administra-

da per un (o més) servidor DNS és una zona. El domini és l’arbre de l’espai

de noms, i la zona és la part de l’arbre administrada per un servidor de

noms de domini concret. En la figura 2 es pot veure un espai de noms amb

quatre zones i catorze dominis.

Origen dels noms de domini

Si ens fixem en els primers dominis d’alt nivell, estaven basats en una visió estatunidenca del món (de fet la xarxa ARPANET base de l’actual Internet era seva). En estendre Internet globalment i aparèixer dominis d’alt nivell geogràfics, moltes organitzacions es van registrar en més d’un domini (per exemple, empresa.com i empresa.cat).

Exemple d’administració de subdomini

El domini .net és administrat per una entitat que gestiona la zona .net. Aquest domini conté el subdomini fpoberta.net, però ha delegat l’administració d’aquest subdomini a l'FP-Oberta. Els administradors de l'FP-Oberta disposen d’un servidor que gestiona el seu domini com una zona.

El domini .net és l’arbre que inclou tots els dominis que en deriven, també el fpoberta.net. Però la zona .net i la zona fpoberta.net no són la mateixa zona. Són administrades per entitats diferents.


Figura 2. Exemple de zones i dominis

En la figura es poden veure tants dominis com requadres de lletres agrupats en quatre zones. El nom de domini corresponent a cada zona (s’anomenen segons el seu node superior) és A, B.A, C.A, I.C.A. Cada una d’aquestes quatre zones tindrà un (o més) servidors DNS per gestionar-la.

En general podem dir que una zona conté la informació completa dels

equips que formen el domini corresponent a la zona i dels equips dels sub-

dominis que no s’hagin delegat. Aquesta informació s’emmagatzema en la

base de dades de zona.

Delegar l’administració d’un subdomini no és més que passar l’autoritat

sobre aquest subdomini a una altra entitat (a uns altres servidors DNS).

Aquesta entitat és la responsable de l’administració de la zona delegada.

Té tota l’autoritat per fer i desfer al seu criteri. La zona pare perd el con-

trol administratiu de la zona delegada i simplement apunta als servidors

de noms de la zona delegada per obtenir informació quan la requereix.

L’estàndard que defineix el DNS estableix que cal configurar dos o més

servidors autoritaris per a cada zona anomenats servidor primari i servi-

dor secundari. El motiu és proporcionar un mecanisme de redundància,

robustesa, rendiment i còpia de seguretat. Si el servidor de noms falla i és

únic, possiblement la xarxa caurà, serà inoperativa.

1.2.5. La resolució de noms

Tot sovint en les aplicacions d’usuari i de sistema s’accedeix a recursos pel

seu nom de domini. Per exemple, un client web requereix una determina-

da pàgina web, un navegador de fitxers vol accedir a unes carpetes d’una

màquina remota que s’identifiquen pel nom de domini, el sistema ha de

validar l’usuari contra un servidor LDAP remot, etc. En cada un d’aquests

Els servidors primari i secundari són autoritat. Només el primari té

els fitxers de zona. El secundari n’obté una còpia per transferència. Podeu trobar més informació sobre els mecanismes de transferència entre servidors primaris i secundaris, i sobre el concepte de servidor autoritari, en la secció “Annexos” del web del crèdit.

!!


casos caldrà resoldre una pregunta del tipus aquest domini a quina IP

correspon? Aquesta pregunta no la responen les aplicacions individual-

ment (el navegador web, el client d’autenticació...) sinó que utilitzen el re-

solver per fer-ho.

El resolver és la part client de l’arquitectura client-servidor del DNS. Ha

d’atendre les necessitats de les aplicacions, confeccionar una consulta o

query, fer-la a un servidor DNS, obtenir la resposta i passar-la a l’aplicació

pertinent. El resolver no és usualment una aplicació sinó un conjunt de

biblioteques de funcions. Les aplicacions clients es compilen i enllacen

conjuntament amb aquestes biblioteques.

La resolució

El mecanisme de resolució de noms DNS consta d’un client o resolver que

realitzarà les consultes (o querys) a resoldre a un servidors DNS.

Sempre hi ha un camí a un domini existent partint del node arrel. Quan

un servidor és consultat sobre un domini que desconeix (no és de la seva

zona ni té la resposta en la cache) pot escalar la pregunta a un servidor

de l’arrel (root name server). Això significa que els servidors arrel són

crucials per al funcionament del DNS.

Exemple de resolució de noms DNS

Quina IP té el domini ns1.fpoberta.net? Si un estudiant australià intenta esbrinar això des del seuservidor de noms de Sindney, probablement acabarà preguntant a un dels nodes arrel per aquestdomini. El node arrel desconeix el host ns1 del domini de l'FP-Oberta, però sí que coneix tots elsdominis de primer nivell (TLD). Proporcionarà una llista amb els servidors de noms del domini .net.Preguntant a algun d’aquests servidors (del domini .net) s’obtindrà la llista de servidors DNS del do-mini fpoberta.net. Preguntant als servidors d’aquest domini s'obtindrà la IP del host ns1 pel qual eldomini fpoberta.net és autoritari (forma part de la seva zona).

Recursió i iteració

Quan el client o resolver emet una consulta al servidor DNS local (el ser-

vidor de noms que té configurat), aquest la pot tractar de manera recursi-

Si el servidor disposa de la informació perquè forma part de la base de

dades de la seva zona, emetrà una resposta autoritativa. Si disposa de

la resposta perquè la té emmagatzemada temporalment (en un procés

anomenat cache) també emetrà la resposta però aquest cop de manera

no autoritativa. Si no té informació del domini buscat, el servidor pot

fer a altres servidors la mateixa consulta en un procés que pot ser re-cursiu o iteratiu. Sempre existeix un camí per trobar el domini buscat

que és preguntar als nodes arrel (root servers) de l’espai de noms de

domini. Partint dels nodes arrel i recorrent l’arbre cap avall, es pot ar-

ribar al domini buscat, si és que existeix.


va o iterativa. De fet, el client resolver ja farà la consulta indicant si

exigeix una resposta recursiva o iterativa. La diferència entre un mode i

l’altre és com ha d’actuar el servidor DNS per obtenir la resposta quan no

la té en la seva base de dades d’informació.

Un servidor pot emetre les respostes següents:

1) La dada que li han sol·licitat.

2) Ha localitzat el domini però no es disposa de la dada sol·licitada. Cal te-

nir en compte que es poden sol·licitar altres dades a part de la IP del do-

mini (per exemple, quins servidors de correu té el domini).

3) El domini sol·licitat no existeix.

Recursió

Quan un servidor rep una consulta del client mira la base de dades local

de la seva zona. Si existeix la informació sol·licitada la retorna. Si la dada

no forma part de la seva zona, però la té emmagatzemada en cache (per

què ja ha realitzat amb anterioritat un consulta similar i ha emmagatze-

mat temporalment la resposta) també la retorna. Si la dada no forma part

del seu espai de noms ni es troba en la cache, el mode recursiu mana al

servidor anar preguntant recursivament a altres servidors, apropant-se

més a cada pas al domini sol·licitat. Si el servidor no coneix cap servidor

més proper al domini buscat a qui preguntar, acaba preguntant als servi-

dors de l’arrel.

Exemple de recursió

Si es consulta el domini www.inf.fpoberta.net i el servidor desconeix aquest domini, intentarà con-

tactar amb un servidor de noms del domini inf.fpoberta.net. Si tampoc sap com adreçar-se a aquest

domini, intentarà contactar amb un servidor de noms de domini fpoberta.net. Un altre cop si el des-

coneix provarà de localitzar un servidor pel domini .net. Si tampoc és el cas, es posarà en contacte

amb un servidor de noms de l’arrel. Un cop en l’arrel, sempre és possible accedir al domini buscat

descendint per l’arbre de dominis.

Si tots els processos recursius acabessin preguntant als nodes arrel,

aquests se saturarien. El servidor que ha rebut la consulta del resolver

pregunta al node més proper al domini buscat. Si coneix algun servidor de

noms més proper, li pregunta i s’evita d’anar a l’arrel.

En mode iteratiu el servidor retorna la millor resposta possible ba-

sada en la seva informació local, sense preguntar a ningú més. En

el mode recursiu el servidor intenta trobar la resposta preguntant a

tants altres servidors com calgui per tal d’obtenir-la.


Una altra manera d’evitar la sobrecàrrega dels nodes arrel és l’ús de la in-

formació emmagatzemada de consultes anteriors, que es desa localment

en la cache del servidor.

Imagineu un alumne de Sydney estudiant de l'FP-Oberta que genera una

consulta al servidor de noms del seu ISP australià per identificar el domini

www.int.fpoberta.net. Probablement el servidor desconeix aquest domini

i tots els més propers, .inf.fpoberta.net i fpoberta.net. Però segurament

en la cache (per altres consultes) té la llista de servidors de noms autori-

taris del domini .net. Serà a un d’aquests servidors (i no un node arrel) a

qui farà la consulta que li permetrà accedir descendentment al domini

buscat.

Per tant, en el procés recursiu el servidor de noms que rep la consulta

del resolver ha de tornar una resposta que pot procedir de la seva base

de dades de zona, del cache, o de les respostes finals que ha obtingut

preguntant recursivament a altres servidors més propers al domini a

consultar.

Fixeu-vos que un servidor que rep una consulta recursiva del resolver té la

feina d’esbrinar per ell la resposta. Podria repetir la mateixa consulta al

servidor més proper fent-la recursiva en lloc d'iterativa. Això exigiria a l’al-

tre servidor fer tota la feina. Aquest plantejament, tot i que possible, es

considera abusiu.

Iteració

En mode iteratiu, un servidor dóna la millor resposta possible basant-se

en la pròpia informació (base de dades de zones locals i del cache). En cap

cas consulta cap altre servidor. Si no disposa de la resposta, lliura una llis-

ta amb els servidors més propers al domini que es busca. La llista pot ser

d'un o més servidors i és tasca del servidor que ha fet la consulta decidir a

quin d’ells tornar a preguntar (en el cas recursiu).

Les consultes iteratives són usualment de servidor a servidor, però no del

resolver al servidor. Si el resolver fes una consulta iterativa a un servidor,

significaria que quan la resposta fos una referència a un altre servidor el

resolver hauria de fer una altra consulta. Generalment, els resolver no te-

nen aquesta capacitat, simplement fan una consulta recursiva al servidor

que tenen configurat i és aquest el que ha de fer tota la feina per obtenir

la resposta.

Usualment el client consulta el seu DNS de manera recursiva, i els

servidors es consulten entre ells de manera iterativa.

Consulta d’informació delegada

Si es consulta l’adreça www.inf.fpoberta.net i el servidor que rep la consulta és el servidor de noms del domini fpoberta.net, aquest no pregunta cap amunt (a .net o a l’arrel) sinó que obté de la seva pròpia base de dades la llista dels servidors de noms autoritaris de la zona delegada inf.fp-oberta.net, als quals preguntarà per obtenir una resposta.

Els nodes arrel no accepten consultes recursives per evitar l’abús i la seva saturació.

http://www.inf.fp-oberta.net


Resolució inversa

El DNS proporciona un mecanisme per obtenir el nom de domini a què

correspon una adreça IP. Aquest mecanisme, anomenat resolució inversa,

es basa en un domini especial anomenat IN-ADDR.ARPA. Hi ha protocols

de xarxa que requereixen una resolució inversa correcta per funcionar bé

i sovint s’utilitza com a mesura de seguretat per verificar l’existència de

l’adreça IP en un domini.

S’ha ideat un domini de nom IN-ADDR.ARPA que permet representar

en forma de nom de domini totes les adreces IP possibles. El format

són etiquetes numèriques del 0-255 que representen cada octet d’un IP.

Les etiquetes dels octets es concatenen en ordre invers i se’ls afegeix

el sufix IN-ADDR.ARPA. Un nom de domini amb quatre etiquetes d’octets

correspon a un host, un nom de domini amb menys etiquetes correspon

a una xarxa.

1.2.6. Base de dades DNS: zones i registres de recurs

El sistema de noms de domini és una base de dades jeràrquica i distribuïda

en què cada servidor de noms gestiona la informació corresponent a la

zona de la qual és autoritari. Cada zona conté informació dels hosts que la

formen. La informació de zona s’emmagatzema en forma de registre de

recurs o resource record (RR). Hi ha la informació que permet identificar

cada nom de domini amb l’adreça IP corresponent, anomenat forward

mapping o resolució directa. També conté la informació per identificar

cada adreça IP amb el nom de domini corresponent, anomenat reverse

mapping o resolució inversa. La informació de zones conté altres informa-

cions que permeten identificar els servidors DNS autoritaris per la zona,

els servidors de correu, etc.

El client resolver fa una consulta recursiva al seu servidor DNS lo-

cal. Si el servidor DNS disposa de la resposta la torna (pot ser de la

seva zona i serà una resposta autoritativa, o pot tenir-la en cache i

serà no autoritativa). Si no disposa de la resposta, consulta iterati-

vament altres servidors apropant-se al domini buscat. Cada servidor

que consulta iterativament li pot proporcionar la resposta (autorita-

tiva o no) si la coneix, o una llista de servidors DNS autoritatius per

al domini indicat.

El conjunt dels registres de recurs de totes les zones de l’espai de noms

formen la base de dades distribuïda jeràrquica del sistema DNS.

Un host amb l’adreça IP 192.168.1.24 correspon al domini 24.1.168.192.IN-ADDR.ARPA.

La xarxa 172.16.32.0/24 correspon al domini ARPA següent: 32.16.172.IN-ADDR.ARPA.


La configuració d’una zona s’emmagatzema en un conjunt de fitxers ano-

menat fitxers de zona. L’especificació del DNS diu com han de ser aquests

fitxers de zona i com s’hi han de descriure els registres de recurs.

En qualsevol zona hi haurà almenys els fitxers de zona següents:

• Un fitxer amb les associacions dels noms de domini a adreces IP.

Aquest fitxer defineix la resolució directa.

• Un fitxer per a cada subxarxa amb l’associació de cada adreça IP al seu

nom de domini canònic. Defineix la resolució inversa.

• Un fitxer amb la definició de la resolució inversa del loopback.

• Un fitxer amb la descripció dels nodes arrel d’Internet.

Un cop els fitxers de zona contenen tots els registres de recurs necessaris

cal configurar el servidor de noms perquè utilitzi aquests fitxers. Si bé la

configuració dels fitxers de zona és estàndard (definida per l’especificació

DNS), la configuració del servidor depèn del programa que s’utilitzi.

Cada fitxer de zona conté un conjunt d’entrades que comencen en la pri-

mera columna, i cada una defineix un registre de recurs (RR). Els més

usuals són SOA, NS, A, CNAME, PTR i MX. L’ordre en què apareixen és in-

diferent però usualment és el mateix que apareix en els exemples. Cada

línia té el format domini classe [ttl] tipus rdata:

• domini és el nom de domini que s’està definint,

• classe, actualment, només pren el valor IN per Internet.

• ttl és un camp opcional que descriu el temps de vida que cal emmagat-

zemar aquest registre en cache.

• tipus és el tipus d'RR que s’està definint.

• rdata és el valor que s’associa al nom de domini que es defineix.

Tot i que en cada registre de recurs es pot definir un TTL (time to live o

temps de vida propi), el més usual és definir un TTL genèric per a totes

les entrades del fitxer de zona en lloc de fer-ho una a una. El servidor

BIND 9 utilitza la directiva $TTL (per exemple: $ttl1 1h) per indicar el

temps que els altres servidors de noms han de guardar en la seva cache les

respostes d’aquest servidor (una hora en l’exemple).

Registre SOA

El registre de recurs SOA o start of authority (inici de definició de zona

amb autoritat) diu que el fitxer de zona on es troba és la millor font de da-

des per a la zona, que el servidor de noms és autoritari per la zona. Acos-

Aprofitar fitxers de zona

Els fitxers de zona de descripció del loopback i dels nodes arrel són pràcticament iguals per a totes les zones, de manera que usualment es copien d’una zona ja existent en lloc d’escriure’ls de nou.

Aplicacions DNS

Hi ha diverses aplicacions que proporcionen el servei de servidor de noms. La més famosa, estesa i utilitzada és el BIND (Berkleley I N D). En la versió BIND 9 s’utilitza un fitxer de configuració anomenat /etc/named.conf per configurar el servidor i indicar-li quins són i on es troben els fitxers de zona.

En la secció “Annexos” del web d’aquest crèdit trobareu altres tipus de recursos RR. També es poden trobar en l’especificació DNS.

!!


tuma a ser el primer RR que hi ha en el fitxer de zona tot i que no és

obligatori. Per cada fitxer de zona hi ha d’haver només un registre SOA.

Un registre SOA té el format nomDomini. IN SOA nsPrimari. admin.ns-

Primari. (opcions-slaves). Un exemple seria el següent:

La descripció de cada camp és la següent:

• nomDomini. indica el nom del domini que s’està definint i pel qual el

servidor de noms és autoritari. Fixeu-vos en el punt al final del nom del

domini, és important posar-lo.

• IN indica que la classe és Internet.

• SOA descriu que és un registre de recurs tipus SOA.

• nsPrimari. és el nom del host servidor de noms primari per a aquesta

zona. Un altre cop pareu atenció al punt del final.

• admin.nsPrimari. és l’adreça de correu electrònic de l’administrador

del servidor de noms de domini, amb el format usuari.servidor. El pri-

mer punt que separa el nom d’usuari i el nom del servidor cal interpre-

tar-lo com si fos una @ (usuari@servidor).

• opcions-slaves són paràmetres que s’indiquen entre parèntesis i que

serveixen per definir com ha de ser la comunicació entre el servidor

primari (o master) i els servidors secundaris (o slaves). A grans trets

s’indiquen els conceptes següents:

– Serial. El número de sèrie de la versió de les dades. A cada canvi de

les dades de la zona, el número s’incrementa.

– Refresh. Temps a transcórrer entre cada refresc de dades del servi-

dor secundari.

– Retry. Temps d’espera per tornar a intentar un refresc si el servidor

secundari ha fallat en l’intent d’actualitzar les seves dades del servi-

dor primari.

– Expire. Temps a partir del qual les dades del servidor secundari es

consideren sense autoritat si no s’han refrescat abans.

– Minimum. Valor del TTL dels camps per defecte. Recordeu que a

cada camp s'hi pot assignar un TTL específic. Segons la versió del ser-

inf.fpoberta.net. IN SOA ns1.inf.fpoberta.net. admin.ns1.inf.fpoberta.net. ( 1h 3h 1h 1w 1h )

Punt final en el nom de domini

Posar, o no, el punt al final d’un nom de domini és important. Si acaba amb punt és un nom de domini absolut. Si acaba sense, és un nom relatiu i s'hi afegirà el domini per defecte al final.


vidor indicarà el TTL de les respostes negatives (negative caching),

ja que el temps TTL es defineix per la directiva $TTL.

Registre NS

El registre de recurs NS o name server (servidor de noms) defineix un servi-

dor de noms autoritatiu per a la zona. Hi haurà tantes entrades NS com ser-

vidors de noms autoritatius hi ha en la zona. L’estàndard DNS en recomana

almenys dos (un de primari o master i un de seguretat secundari o slave).

Un registre NS consta dels camps nomDomini. IN NS nameServer.. Un

exemple seria aquest:


• nomDomini. indica el nom del domini que s’està definint.


• NS descriu que es tracta d’un tipus de registre de recurs en què es de-

fineix un servidor de noms.

• nameServer. és el nom del servidor de noms. Fixeu-vos un altre cop que

tant nomDomini. Com nameServer. acaben en un punt per indicar

que són noms de domini absoluts o FQDN.

Registre A

Un registre de recurs A o Address (Adreça) associa un nom de host a una

adreça IP (resolució directa). Per cada nom de host de la xarxa caldrà dis-

posar d’una entrada on s'associï el nom del host a la seva adreça IP.

Un registre A consta dels camps nomHost. IN A IP.. Un exemple seria aquest:


• nomHost. indica el nom del host que s’està definint.


• A descriu que es tracta d’un tipus de registre de recurs de definició

d’adreça IP.

• IP és l’adreça IP assignada al host.

Fixem-nos un altre cop que nomHost. acaba en punt per indicar el seu

FQDN. Un host pot tenir més d’una IP assignada al mateix nom de host i

s’anomena multi-homed. Simplement caldrà que hi hagi un registre A per

inf.fpoberta.net. IN NS ns1.inf.fpoberta.net.

mahatma.inf.fpoberta.net. IN A 192.168.0.2


a cada adreça IP. Constarà del mateix nom de host a l’esquerra de la defi-

nició, i la corresponent adreça IP a la dreta. Per exemple:

Registre CNAME

Els registres de recurs CNAME o canonical name (nom canònic) associen

un àlies a un nom canònic.

Un registre CNAME consta dels camps nomHost. IN CNAME hostCano-

nicalName.|IP. Un exemple seria aquest:


• nomHost. indica el nom de l'àlies que s’està definint.


• CNAME descriu que es tracta d’un registre de recurs de definició d’un

àlies.

• hostCanonicalName | IP és el nom de host canònic al qual s’assigna

l’àlies. Fixeu-vos un altre cop que és un FQDN i acaba en punt. General-

ment, els registres CNAME tenen a la part dreta de la definició un nom

canònic, però hi de vegades caldrà indicar-hi una adreça IP. Penseu en

un host multi-homed amb múltiples adreces IP que a més a més té ali-

es. Si la definició fos pel nom canònic del host, no se sabria quina de les

adreces IP correspon a l’àlies. En aquests casos, el CNAME apunta a

una adreça IP.

La resolució dels àlies s'obté buscant l’entrada de l’àlies en el fitxer de zo-

na. Amb l’entrada CNAME s’obté el nom canònic corresponent a l’àlies.

Un altre cop es torna a buscar en el fitxer de zona, ara el nom canònic. Una

entrada de tipus A proporcionarà la IP corresponent (alies --> CNAME --

superserver.dom.com. IN A 10.0.0.1 superserver.dom.com. IN A 10.0.0.2

Els noms definits en els registres de tipus A són noms canònics. Un

host es pot identificar per més d’un nom, però només un és el nom

canònic (original), la resta són àlies. Els noms canònics es definei-

xen amb el tipus de registre A. Els àlies es defineixen amb el tipus

de registre CNAME.

ftp.inf.fpoberta.net. IN CNAME mahatma.inf.fpoberta.net.tftp.inf.fpoberta.net. IN CNAME 192.168.0.2

Exemple de host multi-homed

Es vol posar l’àlies super1 i super2 a cada una de les IP del host superserver.com (un host que té dues adreces IP assignades a aquest nom). Les entrades CNAME serien les següents:

super1.dom.com. IN CNAME 10.0.0.1.

super2.dom.com. IN CNAME 10.0.0..2.


> nom canònic --> A --> IP). Un àlies mai pot aparèixer a la part dreta

d’una definició de registre de recurs.

Registre PTR

Un registre de recurs PTR o pointer (punter) associa una adreça IP al nom

de host pertinent (resolució inversa). Cal una entrada PTR per a cada in-

terfície de xarxa de la zona.

Un registre PTR consta dels camps ipInversa.in-addr.arpa. PTR hostCa-

nonicalName. Un exemple seria aquest:


• ipInversa.in-addr.arpa. indica l’adreça IP escrita en forma de domini

in-addr.arpa per poder fer la resolució inversa. Les adreces IP s’es-

criuen al revés quan formen part del domini in-addr.arpa. Així una IP

192.168.20.2 s’escriu “2.20.168.192.in-addr.arpa.”.


• PTR descriu que es tracta d’un registre de recurs de definició de la re-

solució inversa d’una adreça IP.

• hostCanonicalName. és el nom de host FQDN assignat a l’adreça IP. El

nom del host ha de ser per força el nom canònic. No hi pot haver dues

definicions de la mateixa IP amb noms diferents (àlies), només de la IP

al nom canònic.

Registre MX

Un registre MX mail echanger (servidor de correu email) defineix un ser-

vidor de correu. Es pot posar una entrada MX per a cada servidor de cor-

reu però no és obligatori que n’hi hagi cap.

Un registre MX consta dels camps nomDomini. IN MX num mailServer.

Un exemple seria aquest:


• nomDomini. indica el nom del domini que s’està definint.


2.20.168.192.in-addr.apra. IN PTR mahatma.inf.fp-oberta.net.

inf.fp-oberta.net. IN MX 10 ns1.inf.fp-oberta.net.


• MX descriu que es tracta d’un registre de recurs on es defineix un ser-

vidor de correu per a aquest domini.

• num és un valor numèric que expressa el grau de preferència d’aquest

servidor de correu respecte a altres servidors de correu del domini. El

valor més baix és el que es prefereix més. Són valors arbitraris que de-

fineix l’administrador de xarxes.

• mailServer. correspon al nom FQDN del servidor de correu que s’està

definint.

Les dues llistes següents mostren exemples dels fitxers de configuració

per a la resolució directa i la resolució inversa de la zona fpoberta.net.

En el primer es defineixen dos servidors de nom, un encaminador, una

impressora i dos host. El primer dels servidors de noms també fa les

funcions de servidor de correu, web i FTP.

En la llista següent es pot veure com es defineix una entrada PTR per a

cada nom canònic definit en la resolució directa.

;Exemple de fitxer de zona fpoberta.net$TTL 3Dfpoberta.net. IN SOA ns1.fpoberta.net. admin.fpoberta.net. {

23 ; serial8H ; refresh2H ; retry 4W ; expire1D); minimum ttlNS ns1.fpoberta.net.NS ns2.fpoberta.net.MX 10 correu.fpoberta.net.

ns1.fpoberta.net. A 192.168.0.5; servidor amb 2 ipA 172.16.20.5

ns2.fpoberta.net.A 192.168.0.7; servidor dns slaverouter A 192.168.0.1; router. Nom relatiucorreu CNAME ns1 ; alias correuwww CNAME ns1 ; alias webftp CNAME ns1 ; alias ftphp-7200c A 192.168.0.2 ; impressorapc01 A 192.168.0.50pc01 A 192.168.0.51

; Zona 0.168.0.in-addr.arpa.;Exemple de fitxer de zona inversa fpoberta.net; correspon a la xarxa 192.168.0.0/24$TTL 3Dfpoberta.net. IN SOA ns1.fpoberta.net. admin.fpoberta.net. {

23 ; serial8H ; refresh2H ; retry 4W ; expire1D);minimum ttlNS ns1.fpoberta.net.

5 PTR ns1.fpoberta.net.7 PTR ns2.fpoberta.net.


1.2.7. Configuració DNS

Els fitxers de zona contenen els registres de recurs que formen la base de

dades de la zona. Cal configurar el servidor de noms per indicar-li quins

són i on són aquests fitxers. Cada administrador anomena els fitxers com

li plau o seguint l’estil marcat per l’aplicació servidor DNS que utilitza. Un

exemple és anomenar els fitxers de zona amb el format db.nomDomini

per al fitxer de resolució directa, i db.ipXarxa per a la resolució inversa

per a cada xarxa de la zona. El fitxer de la zona corresponent a la resolució

inversa del loopback s’anomena db.127.0.0, i el fitxer amb la informació

dels nodes arrel s’anomena db.cache.

Independentment de l’aplicació que s’utilitzi com a servidor de noms, cal-

drà configurar-la per dir-li on són aquests fitxers, com es diuen, si fan la

funció de servidor autoritari per a la zona o no, si fan la funció de primari

o secundari i d’altres opcions possibles.

L’aplicació actualment més usada és l’aplicació BIND que es configura

mitjançant un fitxer anomenat /etc/named.conf. La manera d’indicar a

BIND 9 quin és el directori per defecte on es troben els fitxers de configu-

ració és options { directory “/var/named”; }.

Per cada fitxer de zona caldrà definir una entrada al fitxer de configuració

de BIND indicant el nom de la zona, el tipus i el nom del fitxer.

La sintaxi seria zone “nom_zona” in { type master|slave|hint; file

“nom_fitxer_zona”; }. Un exemple de configuració de zona podria ser aquest:


• zone nomZona. Com es pot veure en l’exemple es defineix una zona

corresponent al domini int.fpoberta.net.

• type master|slave|hint. El servidor serà primari (master) i autoritatiu

per a aquesta zona. El camp tipus pot prendre els valors master, slave

i hint que signifiquen el següent:

– master. El servidor és amb autoritat per a aquesta zona i gestiona els

fitxers de zona.

1 PTR router.fpoberta.net.2 PTR hp-7200c.fpoberta.net.50 PTR pc01.fpoberta.net.51 PTR pc02.fpoberta.net.

Exemple de configuració del servidor de noms

Si tenim una zona que es compon d’una única xarxa 192.168.20.0/24 amb el nom de domini inf.fpoberta.net caldran cinc fitxers de zona:

a) El fitxer de resolució directa db.inf.fp-oberta.net.

b) El fitxer de resolució inversa db.192.168.20.

c) El fitxer de resolució inversa del loopback db.127.0.0.

d) El fitxer amb la informació dels nodes arrel del DNS, db.cache.

zone inf.fpoberta.net in { type master; file “db.inf.fpoberta.net”; }.


– slave. El servidor és autoritari per a la zona però obté les dades de la

zona del primari o master.

– hint. Indica que es tracta de la informació corresponent als servidors

de noms de la zona arrel. Aquesta informació té un tractament espe-

cial diferent del de les altres zones.

• file nom_fitxer_zona. Indica el fitxer amb els registres de recurs de la

zona. En l’exemple és el fitxer db.inf.fpoberta.net.

Cal posar especial atenció en la definició dels fitxers de zona per a la reso-

lució inversa, utilitzant per exemple la xarxa 192.168.20.0/24. La zona

s’anomena 20.168.192.in-addr.arpa i el fitxer de zona db.192.168.20. El

nom del fitxer conté l’adreça de xarxa en l’ordre natural, però el domini té

els octets invertits perquè forma part del domini in-addr.arpa.

1.2.8. El client: resolver, /etc/hosts, nsswitch

Un equip client que vol resoldre un nom de host té diferents maneres de fer-

ho. Es pot fer localment mitjançant un fitxer de hosts (típicament el /etc/

hosts) o distribuïdament usant DNS (el resolver). De fet, es poden aplicar

tots dos mètodes conjuntament indicant-ne la precedència en algun fitxer de

configuració del sistema (en sistemes Unix, el fitxer /etc/nsswitch.conf).

Resolver

El resolver és la part client del sistema de noms de dominis DNS, que està

organitzat en una estructura client-servidor. Cada resolver implementa

les seves opcions però n’hi que són suficientment genèriques com per des-

criure-les. En la majoria de sistemes Unix, aquestes opcions es defineixen

en el fitxer /etc/resolv.conf.

Les següents són les directives del fitxer /etc/resolv.conf:

• Domain (local domain name o nom de domini local) indica el nom de

domini del host al qual pertany el resolver, serveix per completar els

noms de domini que no són qualificats (FQDN). Per exemple, amb el

valor de domain inf.fpoberta.net., si es vol resoldre pc30 (un nom de

host no qualificat) se li afegirà el nom de domini indicat; per tant, s’in-

tentarà resoldre pc30.inf.fpoberta.net. Generalment, la directiva do-

main és excloent de la directiva search.

• Search permet modificar el comportament per defecte indicant explí-

citament la llista de dominis a aplicar. El primer d’ells és aplicat com

el nom del domini local (local domain name) i és per això que la direc-

tiva search és excloent de la directiva domain. Si per exemple s’utilitza

search inf.fpoberta.net inf.uoc.net fpoberta.net per resoldre el nom de

Criteri de resolució

Per defecte, quan cal resoldre un nom de host (i no s’ha especificat la directiva search), el resolver fa el següent: si el nom de host inclou un punt (pc30.inf) mira de resoldre’l tal qual i, si no pot, hi aplica el nom de domini (pc30.inf.inf.fpoberta.net.). Si el nom de host no conté cap punt (pc30), primer s’afegeix el domini i es mira de resoldre (pc30.inf.fpoberta.net.), i si no es troba es mira de resoldre tal qual (pc30).


host pc30, s’aplicarà cada domini seqüencialment pc30.inf-fpober-

ta.net, pc30.inf.uoc.net i pc30.fpoberta.net.

• Nameserver permet especificar el servidor de noms a utilitzar. Se’n poden

indicar fins a tres per si no hi ha accés al servidor. El resolver intenta con-

nectar amb el primer servidor, i si ho aconsegueix realitza les consultes a

aquest servidor. Si el servidor no és accessible intenta el següent, i així

també per a l’últim. Fixeu-vos que disposar de tres servidors de noms no

significa que si el primer no pot respondre la consulta es repeteix la ma-

teixa consulta al següent. En general, els servidors de noms no restringei-

xen l’accés de manera que qualsevol host hi pot realitzar consultes.

nsswitch

Un host que vol fer la resolució d’un nom pot optar per fer-la localment

amb el fitxer hosts o usant DNS amb el resolver. De fet, els pot utilitzar

tots dos, simplement ha d’indicar en quin ordre. En els sistemes Unix hi

ha el fitxer de configuració /etc/nsswitch.conf, que entre altres coses

permet configurar l’ordre de les resolucions de noms.

Una entrada tipus hosts: dns files indica que primer es mira de resoldre el

nom per DNS i si no es pot es busca al fitxer de hosts local. Una entrada

tipus hosts: files dns indica que primerament es buscarà en el fitxer de

hosts local i posteriorment el DNS. Aquesta opció acostuma a ser més uti-

litzada si es permet que un host pugui personalitzar els noms del seu en-

torn i tinguin precedència sobre els noms del DNS.

Fitxer de hosts

En tot sistema sempre es pot personalitzar els noms dels host mitjançant

un fitxer local, generalment anomenat hosts (/etc/hosts en sistemes

Unix). És un fitxer de text net que conté una entrada per línia del tipus ip

nom_canònic alias1 alias2 ... aliasn. Per a una IP determinada es defineix

el seu nom canònic (nom únic identificatiu) i altres noms que actuen com

a àlies del nom canònic. Per exemple, 192.168.0.1 server.inf.fp-ober-

ta.net server machine.

El fitxer de host es pot utilitzar en un entorn de xarxa petit, però no es pot

escalar a grans xarxes. Caldria posar dins el fitxer els noms de tots els host

de la xarxa i copiar el fitxer en cada host. Justament per evitar aquesta di-

ficultat, es va desenvolupar el sistema DNS.

1.2.9. El protocol DNS

El servei de noms de domini utilitza el protocol DNS per fer les consultes

i les respostes. Es tracta d’un protocol de capa d’aplicació que pot utilitzar

Servidor de noms d’una altra organització

Es poden configurar els host perquè utilitzin el servidor de noms d’una altra organització (perquè és més ràpid, per estalviar-se feina, etc.), però no és una bona pràctica.


tant UDP com TCP en la capa de transport. Usualment, tant les consultes

del client com les respostes del servidor es poden encabir en un datagra-

ma (512 bytes) i s’utilitza UDP (de fet, generalment es diu que el DNS usa

UDP). Però si la informació a transmetre és àmplia (per exemple, una res-

posta amb una llista amb molta informació), la comunicació es passa a

TCP automàticament. Un altre cas en què la informació és TCP és quan

es realitza la transferència d’informació d’una zona entre servidors prima-

ris i secundaris. El servidor DNS utilitza el port privilegiat 53.

1.2.10. Eines per comprovar el funcionament d’un servidor DNS

Hi ha diverses eines per comprovar el funcionament d’un servidor DNS, i

les més usuals són nsloockup, dig i host. El procés de revisió el podríem

basar en els apartats següents:

1) Comprovar que el servei està en funcionament.

2) Comprovar un nom local del domini. Provar-lo sense qualificar, quali-

ficat amb punt al final i sense. Exemples:

• nsloockup server ns1.inf.fpoberta.net

• nsloockup server.inf.fpoberta.net ns1.inf.fpoberta.net

• nsloockup server. ns1.inf.fpoberta.net

• nsloockup server.ins.fpoberta.net. ns1.inf.fpoberta.net

1) Comprovar un nom de domini remot, fora del domini que s’està provant.

Per exemple: nsloockup www.uoc.net ns1.inf.fp-oberta.net

2) Comprovar des d’un servidor remot un nom de domini local en la nos-

tra zona. Cal que la zona estigui integrada en l’altre espai de noms. És a

dir, cal una zona pare que hagi delegat en el domini que s’està revisant.

Per exemple: nsloockup mahatma <nom_ns_de un proveidor ISP>. Si es

vol, es pot crear un subdomini en la zona i delegar, i el domini pare ha de

permetre resoldre noms del domini fill.

El protocol DNS és usualment UDP però pot ser TCP i UDP. Es trac-

ta d’un protocol de capa d’aplicació i utilitza el port 53.


2. Serveis d'FTP, TFTP, HTTP i CUPS

Els serveis FTP i TFTP permeten penjar i baixar fitxers en la xarxa. L'FTP

utilitza TCP i proporciona confiabilitat en les transferències. Permet l’ac-

cés tant d’usuaris identificats com d’usuaris anònims. El TFTP utilitza

UDP i és un mecanisme sense confiabilitat, però molt usat per a baixades

en àrees locals. Els clients lleugers o els sistemes que s'inicien de xarxa

utilitzen TFTP per transferir la informació.

El servei més popular avui en dia a Internet és el servei web que utilitza

HTTP. La seva popularitat basada en el tractament d’hipertext que ha

acabat incloent vídeo, àudio i multimèdia en general (hipermèdia) l’ha

convertit en una eina a l’abast de tothom. L’ús dels navegadors web i

HTTP ha eclipsat molts dels altres protocols d’Internet, que han acabat

veient com les seves funcionalitats s’integren en el servei web (els usuaris

baixen fitxers pel web en lloc de per l'FTP). El proxy server és un servei

HTTP que proporciona capacitats de cache i filtratge dels continguts

web que sol·liciten els clients.

El servei d’impressió CUPS permet la gestió de servidors d’impressió de

xarxa. Permet publicar impressores en xarxa, accedir a impressores remo-

tes, i definir opcions globals per a tots els usuaris i particulars per a cada

usuari. Gestiona cues d’impressió d’una sola impressora o de grups d’im-

pressores anomenats classes. Permet polítiques d’autenticació d’usuari,

de xifratge i de seguretat en la transmissió d’informació.

Per oferir seguretat, integritat i confidencialitat als serveis que originària-

ment no en proporcionen, s’han desenvolupat tècniques com l'SSL i TLS

que permeten parlar dels serveis HTTPS i FTPS. També han sorgit altres

protocols com l'SSH que permeten un model de transferència d’informa-

ció xifrada.

2.1. El servei de transferència de fitxers FTP

L'FTP (file transport protocol o protocol de transferència de fitxers) és

el protocol que proporciona el servei de transferència de fitxers més

àmpliament usat. Es basa en una arquitectura client-servidor i utilitza

el protocol de transport TCP. Permet la transferència de fitxers de

qualsevol tipus entre dos equips. El servidor actua a mode de repositori

de fitxers, i el client s’hi connecta per baixar (download) o penjar

(upload) fitxers.

Per obtenir més informació sobre l’especificació del protocol FTP en l'RFC 959, aneu a la secció “Adreces d’interès” del web d’aquest crèdit.

!!


La necessitat d’un mecanisme de transferència de fitxers sorgeix des de

bon principi a Internet i ja el 1980 hi ha la primera especificació d'FTP.

L’octubre del 1985 apareix l’RFC 959, que és la base del protocol actual. A

aquest RFC, se n’han afegit d’altres posteriorment per incorporar segure-

tat, internacionalització, etc. Tractant-se d’un protocol tan "vell", no és es-

trany que l'FTP sigui un protocol insegur; de fet, la majoria de protocols

originaris d’Internet ho són (HTTP, SMTP, FTP, etc.).

Una de les virtuts del model FTP és que permet la transferència de fitxers

(també modificar, esborrar, afegir, etc.) independentment de la platafor-

ma i del sistema de fitxers on resideixen. És a dir, l'FTP amaga els detalls

d’implementació. Un client (que funcioni amb sistema operatiu Unix, per

exemple) baixa un fitxer de text d’un servidor FTP sense saber el tipus de

màquina ni el tipus de sistema de fitxers del servidor (servidor IBM per

exemple). El servidor transfereix el fitxer independentment del sistema

de fitxers del client.

La debilitat principal del protocol FTP és la falta de seguretat. Tot el flux

de dades viatja en text net, sense encriptar, fins i tot els noms d’usuari i

les contrasenyes. Això ha obligat a adoptar noves estratègies per proporcio-

nar confidencialitat a les transmissions.

2.1.1. Tipus de clients i servidors

El servidor FTP és una màquina que executa un programari determinat

que proporciona el servei FTP a clients FTP. Usualment en entorns Unix

aquest programa és un dimoni (daemon) anomenat FTPD. En funció del

tipus d’usuaris que permet connectar i de l'àmbit d’accés que permet, el

podem classificar de maneres diferents.

El protocol FTP (file transfer protocol o protocol de transferència

de fitxers) és un protocol TCP que permet la transferència de fitxers

en ambdós sentits entre un client i un servidor.

Els objectius del servei FTP són els següents:

• Compartir fitxers tant de dades com de programes.

• Permetre continuar amb les transferències de fitxers encara que

s’interrompin (reprendre les baixades).

• Transferir dades de manera eficient i fiable.

Seguretat de la xarxa

En els orígens d’Internet, els usuaris eren part implicada i no els va passar pel cap que hi hagués usuaris amb esperit “d’atacar” altres sistemes.


Segons el tipus de clients que accepta, podem classificar els servidors FTP

de la manera següent:

• Usuari identificat. El servidor requereix un nom d’usuari i una contra-

senya vàlida per accedir al servei FTP. Els comptes de per usuari es po-

den gestionar directament per l’aplicació del servidor o es pot delegar

l’autenticació al sistema operatiu.

• Accés anònim. Un servidor que permet accessos anònims permet que

qualsevol usuari pugui accedir al repositori de fitxers. Usualment cal

indicar com a nom d’usuari anonymous i com a contrasenya s’accep-

ta qualsevol text, però per convenció s’escriu el correu electrònic de

l’usuari.

Segons l’àmbit del servei que proporciona, podem classificar els servidors

FTP de la manera següent:

• Servidor públic. Molts servidors FTP a Internet ofereixen servei

d’accés anònim a mode de repositoris de programari perquè els usua-

ris el puguin utilitzar. N’hi ha que actuen com a mirrors (miralls, rè-

pliques) d’altres repositoris per tal d’apropar les baixades a l’usuari.

Aquest servei és usualment de només de lectura (pel client) i s’ubica

sovint en el directori /var/ftp o /var/ftp/pub en sistemes Unix.

• Servidor corporatiu. Els serveis FTP no cal oferir-los per força a Inter-

net, l’administrador de xarxa configura el servidor FTP per oferir els

serveis als equips que creu oportuns. Dins d’una xarxa corporativa es

pot disposar d’un o més servidors FTP que permeten l’accés als usuaris

de la xarxa (tant a usuaris identificats com a usuaris anònims dins de

la xarxa corporativa).

Evidentment, el servidor FTP pot combinar els models anteriors i propor-

cionar accés tant a usuaris identificats com a usuaris anònims, i pot dife-

renciar els recursos que ofereix en funció de si són usuaris interns de la

xarxa corporativa o d’Internet.

El client FTP és el programari que s’utilitza per establir una connexió amb

el servidor per tal de poder baixar o penjar fitxers en el servidor. El client

pot llistar, modificar i afegir fitxers en el servidor a més d’altres accions,

sempre que estigui autoritzat. L’aplicació client pot ser basada en text o

en un entorn gràfic, però en tot cas ha de poder establir una connexió amb

el servidor.

La connexió FTP es pot indicar mitjançant un URL del tipus: ftp://servi-

dor/fitxer on fitxer pot incloure una trajectòria. De fet, l'URL pot ser

Alguns servidors FTP permeten l’accés anònim acceptant qualsevol nom d’usuari i qualsevol contrasenya.

Exemple de mirror

Si us voleu baixar un GNU/Linux Live per al pen drive o memòria USB, en lloc de contactar el servidor de Fedora, ho podeu fer en un mirror de Rediris (més proper).

URL

URL és l’acrònim de uniform resource locator, en català identificador uniforme de recursos. Sovint és usat com a sinònim d'URI, uniform resource identifier (identificador uniforme de recursos).


més detallat: ftp://usuari:contrassenya@servidor:port/fitxer,

en què s’indica l’usuari i la contrasenya, el servidor, el port d’accés i el fitxer

a accedir. En determinats sistemes operatius es pot usar aquesta sintaxi en

la línia d'ordres per indicar un fitxer remot igual que es faria per indicar un

fitxer local.

Servei: stand-alone/xinetd

En el servei stand-alone, el servidor escolta per si mateix les connexions entrants. En el servei xi-netd o inetd el servidor està dins d’un superservei de xarxa. Inetd és un superdimoni de xarxa queescolta connexions entrants de diferents protocols i executa el dimoni del servei corresponent enrebre una connexió. Xinetd n’és la versió millorada.

2.1.2. Funcionament del servei FTP

L'FTP és un protocol d’aplicació basat en TCP/IP que utilitza TCP com

a capa de transport. El servidor escolta connexions entrants de clients

pel port 21 i inicia una sessió si l’autentificació s’estableix correcta-

ment. El servidor pot funcionar com un servei per si mateix (stand-alo-

ne) o pot estar configurat per funcionar dins d’un superservei de xarxa

com, per exemple, inetd i xinetd. Si funciona en mode de servei propi

és el servidor qui escolta les connexions entrants i les atén. Si s’executa

dins del superservei de xarxa, aquest és qui detecta les connexions en-

trants i activa el dimoni de l'FTP perquè les atengui; un cop ateses, el

dimoni de l'FTP acaba i torna a ser el superservidor de xarxa qui es que-

da escoltant.

L’accés als recursos del servidor varia usualment en funció de si el client

és un client anònim o un client identificat. Els clients identificats poden

navegar per l'estructura de fitxers segons els seus permisos. Els clients

anònims usualment estan engabiats (chroot) en una part de l’arbre de fit-

xers i no en poden sortir. Usualment, el servidor fa correspondre el direc-

tori de publicació (/var/ftp o /var/ftp/pub en sistemes Unix) amb el

directori arrel (/) d’accés del client. El client pot descendir a partir

d’aquest punt, però no pot anar a directoris superiors.

Chroot

En sistemes Linux, chroot és una utilitat o una tècnica consistent a “engabiar” serveis en una partdel disc com si fos el disc sencer. De manera que es fa correspondre un directori particular (on hiha el servei) a una arrel de disc virtual. Els usuaris del servei creuen que naveguen per tot el disc,però en realitat estan “engabiats” en una estructura virtual.

El servidor proporciona un repositori de fitxers i una aplicació que

permet que els clients es connectin i facin ús dels fitxers (penjar i

baixar). L’URL per accedir a un fitxer per FTP es pot expressar així:

ftp://usuari:contrasenya@servidor:port/fitxer.

El port 21 és el port del canal de control. El port 20 és el port del canal de dades.

Tipus de client

Hi ha dos tipus de clients:

• Identificat: té accés al sistema de fitxers complet.

• Anònim: és engabiat en un punt de l’arbre de fitxers.


El mode en què es transfereixen els fitxers entre el client i el servidor pot

ser de tipus diferents, els dos més importants són aquests:

• ASCII. El fitxer es transmet caràcter a caràcter. Els caràcters han de

correspondre al codi de caràcters bàsic ASCII. Si el fitxer conté caràc-

ters ASCII no vàlids la transferència fallarà. Per tant, es tracta d’un

mode vàlid únicament per transferir text net. El receptor farà les con-

versions de caràcter necessàries per desar les dades en el format que

requereixi.

• Binary (binari). Quan el mode de transferència és binari, el fitxer s’en-

via bit a bit sense cap interpretació de cap mena. És el mode que cal

usar per transmetre programes, imatges, vídeo, so, dades binàries, etc.

2.1.3. Especificació del protocol FTP

El protocol FTP és un protocol de capa d’aplicació basat en TCP com a

capa de transport. Utilitza el port 21 per al canal de control, i el port 20 per

al canal de dades, i és un dels pocs protocols actuals que encara utilitzen

més d’un port per a la comunicació. El port 21 s’utilitza com a canal de co-

municació entre client i servidor. És per on es transmeten les ordres, però

no els fitxers. Aquests es transmeten per una connexió diferent, per un ca-

nal diferent, que en principi utilitza el port 20 del servidor.

Tant en el client com en el servidor hi ha dues entitats clarament diferen-

ciades:

• Intèrpret del protocol. És l'encarregat de l’intercanvi d'ordres i respos-

tes entre client i servidor. Utilitza el canal de control establert entre el

port de sortida del client i el port 21 on escolta el servidor. És l’encar-

regat d’interpretar les ordres de l’aplicació client convertint-les en ins-

truccions del protocol FTP, executar-les en el servidor i retornar les

respostes al client. No s’encarrega de la transferència de fitxers.

• Transferència de dades. És la part encarregada d’intercanviar els

fitxers i directoris entre client i servidor. En el funcionament bàsic,

el canal de dades s’estableix entre un nou port del client (port dinà-

mic i específic per a la transmissió del fitxer) i el port 20 (ftp-data)

del servidor.

La connexió TCP del canal de dades entre client i servidor es pot establir

de dues maneres diferents:

• Mode actiu. Generalment és el mode per defecte. Abans de fer una sol·li-

citud al servidor que impliqui transferir dades pel canal de dades, el client

ASCII

ASCCII és l’acrònim d’american standard code for information interchange, en català codi estàndard americà per a l’intercanvi d’informació.

Format del salt de línia

Imagineu el típic problema del salt de línia que varia segons el sistema operatiu. El servidor, per exemple, envia text amb LF com a salt de línia (usa Unix) i el receptor els desa com a CR+LF (que és el format usat pel seu sistema operatiu no Unix).

Modes de connexió FTP

El canal de dades entre client i servidor es pot establir en dos modes diferents:

• Actiu. El client indica quin és el seu port dinàmic. El servidor usa el 20. El servidor fa la nova connexió. Ordre PORT del protocol.

• Passiu. El servidor indica quin és el seu port dinàmic en lloc del 20. El client fa la nova connexió. Ordre PASV del protocol.


indica al servidor el port dinàmic que utilitzarà. Per tant, el canal de dades

s’estableix entre aquest port dinàmic del client i el port 20 del servidor.

Servidor i client estableixen una nova connexió TCP per aquest canal.

• Mode passiu. El client fa una sol·licitud de mode passiu al servidor.

Aquest respon enviant el seu port dinàmic, per on s’establirà el canal

de dades (en lloc del port 20). Llavors el client inicia una nova connexió

TCP entre un port dinàmic nou seu i el port dinàmic del servidor.

Aquest és el canal de dades.

En resum, podríem dir que el client es posa en contacte amb el servidor

connectant-se al port 21. Mitjançant aquest canal de comunicació, client i

servidor governen tota la sessió FTP. Les baixades de fitxers es realitzen

per una altra connexió que es pot crear i destruir al llarg de la sessió (per

exemple, per cada baixada o segons els períodes d’inactivitat). En la figura

3 es pot veure l’esquema de connexió i els ports entre un client i un servi-

dor FTP.

Figura 3. Model funcional del protocol FTP

El protocol FTP descriu diferents categories d’ordres que el client pot rea-

litzar (no les confongueu amb les ordres concretes de l’aplicació client).

Aquestes s’agrupen en tres grups:

1) Ordres de control d’accés. Les que gestionen l’accés al servei FTP. Per

exemple, inici i finalització de la sessió, validació de l’usuari i la contrase-

nya, canvis de directori i de sistemes de fitxers, etc.


2) Ordres de paràmetres de transferència. Gestionen les opcions relacio-

nades amb la transferència de fitxers com, per exemple, el mode de trans-

ferència binari o ASCCI, els ports, el mode passiu o no passiu, etc.

3) Ordres de servei FTP. Són les ordres d’allò que es vol fer en una sessió

FTP com, per exemple, baixar un fitxer, penjar-lo, modificar-ne el nom,

afegir-lo, etc.

Per a cada ordre del client, el servidor emet una resposta pel canal de con-

trol en què indica l’estatus de l’execució de l’ordre rebuda. Per exemple,

el client envia el seu usuari i contrasenya, el servidor els valida i retorna

una resposta ok. Si l’ordre implica la transferència de dades aquesta es rea-

litza pel canal de dades.

El protocol FTP defineix un conjunt de respostes FTP consistents en un

codi numèric de tres xifres i un text descriptiu de la resposta, com per

exemple 250 Directory successfully changed. Tot el diàleg client-ser-

vidor té forma d’ordres i respostes.

2.1.4. Ordres del client FTP

Un client FTP es pot connectar molt fàcilment des del mode d’ordres de

la majoria de sistemes operatius, únicament ha de realitzar l’ordre: ftp

servidor i automàticament s’inicia una connexió entre el client i el servi-

dor indicat. Usualment, l’aplicació client permet un ús interactiu i es po-

den obrir i tancar sessions, i treballar-hi, en diferents servidors al gust del

client. A continuació teniu un exemple de sessió client.

El client disposa de les ordres FTP que el servidor implementi. No ne-

cessàriament s’implementen totes les ordres descrites en el protocol

FTP. A més a més pot disposar d’altres ordres si el client i el servidor

permeten extensions del protocol (coses que fan de més a més). Les or-

dres més usuals són get, mget, put i mput per baixar i penjar fitxers;

cd i ls per canviar i llistar directoris; ascii i binary per indicar el

mode de transferència; !ordre per executar una ordre de sistema ope-

ratiu en el servidor; i help per mostrar la llista d’ordres. A continuació

es mostra la llista d’ordres que implementa el servidor al qual s’ha con-

nectat.

Ordres i respostes FTP

En el document RFC 959 hi ha la llista d’ordres i la taula de codis/missatges de resposta del protocol FTP. Aquest document és l’especificació de l'estàndard FTP.

$ ftp ftp.uoc.net # iniciar una sessió al servidor ftp.uoc.net # .. accions ftp i quit per sortir

$ ftp # engegar l’aplicació client> open ftp.rediris.es # connectar al servidor ftp de rediris> get carta.txt # descarregar-se el fitxer carta.txt> quit # finalitzar la sessió al servidor catual> open servidor_nou # iniciar una connexió a un altre servidor

Ús del servei FTP

L’ús del servei FTP exigeix una bona gimnàstica mental, ja que l’usuari ha de ser conscient en tot moment de quin és el seu sistema d’arxius local i quin és el sistema d’arxius remot. La majoria d’ordres tenen una versió per afectar el sistema de fitxers local (lcd, per exemple) i per afectar el sistema de fitxers remot (cd).


2.1.5. Aplicacions FTP

Hi ha moltes aplicacions FTP en el mercat, tant per a clients com per a servi-

dors. Al mateix temps hi ha versions de text i gràfiques per a cada cas. Hi ha

moltes aplicacions que són d’ús públic i que es poden baixar gratuïtament.

En sistemes GNU/Linux, la majoria proporcionen l’aplicació client ftp o

lftp (lftp és una versió més nova i simple). També disposen d’una aplica-

ció servidor, que és la que proporciona GNU, anomenada vsftpd (very se-

cure ftp daemon o dimoni ftp molt segur).

Una de les eines més usades per fer baixades FTP de repositoris públics

són els navegadors web. Els navegadors web permeten utilitzar el protocol

FTP per realitzar baixades però no proporcionen totes les prestacions que

pot arribar a donar un client FTP específic. Per accedir a un servidor FTP

amb un navegador, n’hi ha prou d’indicar l'URL el protocol i el servidor al

qual es vol accedir (per exemple: ftp://ftp.rediris.es).

2.1.6. Seguretat: SFTP i FTPS

Igual que la majoria de protocols inicials d’Internet, l'FTP es va desenvolupar

en un clima de fraternitat i bon rotllo i no incorpora cap mecanisme de segu-

retat i xifratge. Això significa que tot el seu trànsit pot ser monitorat i els nom

d’usuari i contrasenya de connexió poden ser capturats. L'RFC 2228 FTP se-

curity extensions (extensions de seguretat per a l'FTP) intenta afegir al pro-

tocol FTP autenticació, integritat i confidencialitat.

Hi ha múltiples alternatives a l'FTP bàsic que permeten treballar amb se-

guretat. Les principals són aquestes dues:

• FTPS. Es tracta d'FTP sobre SSL (secure socket layer o capa de sòcol

segur) o sobre TLS (transport layer security o seguretat en la capa de

ftp> help Commands may be abbreviated. Commands are: ! debug mdir sendport site $ dir mget put size account disconnect mkdir pwd status append exit mls quit struct ascii form mode quote system bell get modtime recv sunique binary glob mput reget tenex bye hash newer rstatus tick case help nmap rhelp trace cd idle nlist rename type cdup image ntrans reset user chmod lcd open restart umask close ls prompt rmdir verbose cr macdef passive runique ? delete mdelete proxy send

Aplicacions FTP recomanables

Més que fer una enumeració de les aplicacions FTP actuals, us suggerim que consulteu per Internet quines aplicacions estan “de moda” i esbrineu les característiques que les diferencien.

Amb qualsevol monitoritzadorde xarxa, com per exemple Wireshark, es pot veure el contingut del trànsit FTP.

SSH

SSH és l’acrònim de secure shell (en català, intèrpret d'ordres segur). L'SSH proporciona la capacitat d’efectuar sessions remotes segures.


transport). La capa de transport segura proporciona a l'FTP el mateix

grau de seguretat que proporciona a l'HTTPS (HTTP secure). La feina

d’encriptació i autenticació la realitza l'SSL o TLS, i l'FTP simplement

funciona sobre ells.

• SFTP. És la utilitat d’FTP segura corresponent al paquet Open SSH. A

part de la coneguda utilitat SSH, el paquet aporta les utilitats SCP (se-

cure copy, còpia segura) i SFTP entre altres. L'SFTP aporta les matei-

xes característiques de seguretat que han fet de l'SSH una de les eines

més usades.

2.1.7. Exemple de connexió FTP

Tot el diàleg client-servidor té forma d’ordres i respostes, tal com es pot

veure a continuació on es realitza una connexió FTP i s’executen diverses

ordres.

Ordre ports comanda/resposta[root@portatil ~]# ftp localhost

c49962 – s21 ...establiment de la conneció TCP... s21 – c4992 Connected to localhost (127.0.0.1). s21 – c4992 220 (vsFTPd 2.0.5)

Name (localhost): anonymous c4992 – s21 ... enviar el nom d’usuari al servidor...

USER anonymous <CRLF>s21 – c4992 331 Please specify the password.

Password: c49962 – s21 ... enviar el password al servidor...

PASS [email protected] – c4992 230 Login successful. s21 – c4992 Remote system type is UNIX. s21 – c4992 Using binary mode to transfer files.

ftp> cd pubc49962 – s21 ... canviar al directori pub...

CWD pub s21 – c4992 250 Directory successfully changed.

ftp> dirc49962 – s21 ... indicar el port dinàmic client ...

PORT 127,0,0,1,137,108 <CRLF> s21 – c49962 200 Port command succesfullc49962 – s21 ... llistar el directori ...

LIST <CRLF> * s20 – c35180 ... establiment connexió canal dades...* c35180 – s20 ... connexió TCP client/servidor...

s21 – c49962 150 Here comes the directory listing * s20 – c35180 total 2

-rw-r--r-- 1 0 0 110 May 31 12:15 llistat -rw-r--r-- 1 0 0 362047 Feb 23 16:12 services ... tancament de la connexió de dades...

s21 – c4992 226 Directory send OK.ftp> get carta.txt

c49962 – s21 ... descarregar el fitxer carta.txt...c49962 – s21 ... demanar el mode passiu al server...

PASVs21 – c49962 227 Entering Passive Mode (127,0,0,1,142,120).c49962 – s21 RETR carta.txt


Mode actiu i mode passiu

Per activar el mode passiu s’utilitza l’ordre PORT A, B, C, D, PH, PL.

El client indica el seu port de dades especificant la pròpia adreça IP: A.B.C.D i el port. El port s’indicaen dos octets PL i PH tals que el número del port correspon a l’expressió port = PH × 256 + PL.

Per activar el mode passiu s’utilitza l’ordre PASV.

El client sol·licita al servidor treballar en mode passiu. El servidor respon quin és el seu port de da-des (que usarà en lloc del port 20). Emet una resposta amb la informació (A, B, C, D, PH, PL) queindica la IP del servidor (A.B.C.D) i el port del servidor en el format port = PH × 256 + PL (el valordel port s’obté dels octets PL i PH aplicant l’expressió indicada).

2.2. El servei de transferència trivial de fitxers TFTP

El protocol TFTP (trivial file transport protocol o protocol trivial de transfe-

rència de fitxers) proporciona un servei de transferència de fitxers més bàsic

i elemental que l'FTP. Es basa en la simplicitat, no permet l’autenticació dels

usuaris ni incorpora cap mecanisme de seguretat. Només permet les opera-

cions de lectura (baixar fitxers) i d’escriptura (penjar fitxers). No es poden

llistar els repositoris ni navegar per l’estructura del sistema de fitxers.

Quina és la utilitat d’un protocol de transferència de fitxers tan elemen-

tal? El TFTP va ser ideat per baixar fitxers en entorns simples com, per

exemple, la iniciació d’estacions de treball sense sistema operatiu. En

aquest tipus d’entorns encara no hi ha el programari necessari per perme-

tre transferències de fitxers més complexes usant FTP.

Les utilitats del protocol TFTP són les següents:

• Inicialitzar estacions de treball sense disc, permetent carregar el siste-

ma operatiu per TFTP.

• Desar i baixar configuracions, especialment fitxers de configuració de

xarxa, d'encaminadors, d’arrencada de sistemes, etc.

• Iniciar instal·lacions de sistemes operatius per xarxa. Els equips (amb

disc o sense) es baixen per la xarxa per TFTP el programari d’instal·la-

ció del sistema operatiu.

s21 – c49962 150 Opening BINARY mode data connection for carta.txt (110 bytes)

* c435181 – s36472 ... establiment connexió canal dades...* s36472 – c435181 ... connexió TCP client/servidor...* ... transferència del contingut del fitxer...* ... tancament de la connexió de dades...

s21 – c4992 226 File send OKftp> quit

c49962 – s21 QUIT <CRLF>s21 – c49962 221 Goodbye.

El protocol trivial de transferència de fitxers TFTP únicament per-

met les operacions bàsiques de penjar i baixar fitxers, i no incorpora

cap mecanisme d’identificació.

Per obtenir més informació sobre l’especificació del protocol TFTP en els RFC 783 i 1350, aneu a la secció “Adreces d’interès” del web del crèdit.

!!

TFTP + PXE

Molts xips ROM de les targetes de xarxa permeten arrencar amb el protocol PXE (pre-execution environment o entorn de preexecució), que permet obtenir per mitjà del DHCP una configuració de xarxa, i per mitjà del TFTP un fitxer executable de sistema operatiu.

Sovint les configuracions dels encaminadors es desen i recuperen per mitjà del TFTP.


Atès que TFTP no incorpora cap mecanisme d’identificació de l’usuari, els

repositoris de dades del TFTP són públics. Usualment, en sistemes GNU/

Linux aquests repositoris es troben en el directori /tftpboot. Qualsevol

client TFTP pot accedir al contingut d’aquest repositori i les accions que

pot realitzar dependran dels permisos de lectura i escriptura que determi-

ni l’administrador. En tot cas, ha de quedar clar que l’administrador no té

altra manera de filtrar l’accés en funció dels usuaris clients que atorgant

el permís de lectura, o de lectura i escriptura, als fitxers i directoris.

2.2.1. Especificació del protocol TFTP

El protocol TFTP es descriu en l'RFC 1350 del juliol del 1992, que actualit-

za l'RFC 783 del juny del 1981. Es tracta d’un protocol de capa d’aplicació

que utilitza UDP en la capa de transport. No existeix un flux de dades

(stream) com en el protocol FTP (que usa TCP) sinó que s’envien datagra-

mes de 512 bytes com a màxim.

Els protocols basats en UDP no realitzen lliurament garantit dels datagra-

mes de dades que transporten. La fiabilitat s’implementa en TFTP mitjan-

çant temporitzadors d’espera. Quan s’envia un datagrama, s’inicialitza un

comptador temporal, i abans que expiri s’ha de rebre la confirmació. Si no

és així, l'emissor dóna el datagrama per perdut i el retransmet.

El servidor TFTP utilitza el port 69 per escoltar les peticions entrants dels

clients. Si el servidor pot atendre la sol·licitud (una lectura o escriptura và-

lida), respon al client indicant un nou port (superior a 1023) per on es farà

la transferència del fitxer i per on passarà el trànsit de les transferències

d’aquesta sessió del client. És a dir, el servidor escolta en el port 69, però

les transferències de fitxers s’efectuen per un altre port del servidor, es-

pecífic per a cada connexió amb un client. La figura 4 mostra l’esquema de

comunicació entre un client i un servidor.

Figura 4. Model funcional del protocol TFTP

El protocol TFTP es caracteritza per utilitzar UDP en la capa de transport i el port 69 per a les comunicacions.


El protocol TFTP defineix els tipus de paquets següents:

• RRQ (read request o petició de lectura). El client l’envia per sol·licitar

al servidor el fitxer a baixar i el mode a utilitzar.

• WRQ (write request o petició d’escriptura). El client l’envia al servidor

per indicar el nom del fitxer a transferir i el mode.

• DATA (dades). Blocs de dades de 512 bytes amb el contingut del fitxer.

L’últim bloc no ha de ser necessàriament de 512 bytes (últim fragment).

• ACK (acknowledgement o confirmació). S’envia per indicar la confir-

mació de la recepció d’un paquet.

• Error (error). Indica que s’ha produït un error. En l'RFC 1350 es pot

consultar el significat dels valors d’error existents.

El diàleg TFTP entre client i servidor per realitzar una baixada s’estableix

de la manera següent:

1) El client envia una petició RRQ al servidor al port 69. Fixeu-vos que no

hi ha diàleg client/servidor i que no es realitza una petició/resposta. No

s’estableix cap connexió abans de la transferència (model UDP).

2) El servidor envia DATA o ERR al client. Si no pot atendre la petició del

client (nom de fitxer incorrecte, permisos inadequats, sistema de fitxers ple,

etc.) envia un paquet ERR. Si pot atendre la petició del client envia un bloc de

dades amb un datagrama de tipus DATA. Fixeu-vos que és aquest mateix pa-

quet (el DATA o l'ERRA) el que fa la funció de confirmació de la petició ante-

rior. La resposta del servidor sempre s'adreça al mateix port del client (amb

el qual ha iniciat el diàleg). Però, en la primera resposta, el servidor fa saber

al client el seu nou port per on espera rebre les dades del client (els ACK de

confirmació o les dades DATA si es tracta d’una escriptura).

3) El client confirma el datagrama de dades rebut enviant un ACK.

4) El procés del pas 2 i 3 es repeteix per tants blocs de dades com calgui en-

viar. L’últim bloc de dades enviat pel servidor serà menor de 512 bytes i això

permetrà al client saber que és l’últim bloc i que la transmissió ha finalitzat.

El procés de transferència d’un fitxer del client al servidor és similar:

1) El client envia una petició WRQ.

2) El servidor verifica la viabilitat de l’operació i respon amb ACK o amb

ERR. En l’ACK indica el seu nou port per on espera rebre les dades del fit-


xer que el client enviarà. El mecanisme per indicar el port és tan senzill

com posar aquest nou port com a port origen en el datagrama.

3) El client envia un datagrama DATA per a cada bloc de dades en què

fragmenta el fitxer.

4) El servidor envia els ACK o ERR corresponents.

2.2.2. Exemple de connexió TFTP

Tot el diàleg client-servidor té forma d’ordres i respostes, tal com es pot

veure en l'exemple següent de sessió TFTP. Es realitza una connexió TFTP

per mitjà d’un telnet al port 69 d’un servidor TFTP, i es baixa un fitxer i

se'n penja un altre.

Amb Wireshark es monitora el trànsit de la mateixa sessió. Us mostrem

l'extracte següent:

$tftp localhosttftp> verbosetftp> tracetftp> status

Connected to 127.0.0.1. Mode: netascii Verbose: on Tracing: on Rexmt-interval: 5 seconds, Max-timeout: 25 seconds

tftp> get hola.txt getting from 127.0.0.1:hola.txt to hola.txt [netascii] sent RRQ <file=hola.txt, mode=netascii> received DATA <block=1, 85 bytes> Received 85 bytes in 0.9 seconds [774 bit/s]

tftp> put nou.doc carta.txt putting nou.doc to 127.0.0.1:carta.txt [netascii] sent WRQ <file=carta.txt, mode=netascii> received ACK <block=0> sent DATA <block=1, 72 bytes> received ACK <block=1> Sent 72 bytes in 0.5 seconds [1140 bit/s]

tftp> quit

1) client servidor TFTP Read Request, File: hola.txt, Transfer type: netasciiUDP, Src Port: filenet-rmi (32771), Dst Port: tftp (69) TFTProtocol Opcode: Read Request (1) Source File: hola.txt Type: netascii 2) servidor client TFTP Data Packet, Block: 1 (last) UDP, Src Port: filenet-pa (32772), Dst Port: filenet-rmi (32771) TFTP Opcode: Data Packet (3) Block: 1 Data (85 bytes) 3) client servidor TFTP Acknowledgement, Block: 1 UDP, Src Port: filenet-rmi (32771), Dst Port: filenet-pa (32772) TFTP Opcode: Acknowledgement (4) Block: 1 4) client servidor TFTP Write Request, File: carta.txt, Transfer type: netasciiUDP, Src Port: filenet-rmi (32771), Dst Port: tftp (69) TFTP Opcode: Write Request (2) DESTINATION File: carta.txt Type: netascii

Wireshark

Wireshark és una aplicació de monitoratge del trànsit de xarxa que permet capturar i observar elscontinguts de les trames de la xarxa. És una eina excel·lent per aprendre el funcionament dels protocols.

Trace

Les opcions trace i verbose permeten fer un seguiment del protocol des del client, monitorant les ordres del protocol que es realitzen i les respostes del servidor.


2.3. El servei HTTP

El protocol HTTP (hypertext transfer protocol o protocol de transferèn-

cia d’hipertetx) és un protocol de capa d’aplicació que proporciona trans-

ferència de documents d’hipertetx al web. El protocol HTTP és

omnipresent, el World Wide Web (WWW) permet baixar multimèdia, hi-

pertext i altres tipus de dades.

L'HTTP està basat en un esquema client-servidor en què el client es con-

necta al port 80 del servidor i fa una sol·licitud (una pàgina web, per exem-

ple), i el servidor emet la resposta corresponent i tanca la connexió. És per

això que es tracta d’un protocol sense estat. La connexió entre client i ser-

vidors sovint s’inicia i es tanca en cada petició/resposta. L'HTTP utilitza

habitualment el protocol de transport TCP per obtenir fiabilitat en la co-

municació.

L’especificació actual del protocol HTTP és la 1.1 corresponent al docu-

ment RFC 2616 del juny del 1999 (que descriu l’estàndard). L'HTTP sor-

geix als anys noranta com a protocol per transferir documents hipermèdia

"en cru" per Internet (versió 0.9). La versió HTTP 1.0 (RFC 1945) permet

el pas de missatges utilitzant un format tipus MIME (usat en el transport

de correu). Originàriament, el contingut dels documents a transferir era

text, però amb la popularització del WWW s’ha acabat convertint en un

protocol de transport de contingut multimèdia i no únicament hipertext.

A més a més, l'HTTP s’utilitza sovint com a protocol de comunicacions en-

tre clients i altres sistemes d’Internet diferents del WWW, com per exem-

ple NEWS, WAIS, SMTP, NNTP, FTP, Ghoper, proxies, etc., per tal

d’accedir a aquests recursos.

En parlar de HTTP ens vénen immediatament al cap els navegadors web

(tipus Mozilla, Firefox, etc.) que permeten visualitzar, des d’entorns grà-

5) servidor client TFTP Acknowledgement, Block: 0 UDP, Src Port: filenet-pa (32772), Dst Port: filenet-rmi (32771) TFTP Opcode: Acknowledgement (4) Block: 0 6) client servidor TFTP Data Packet, Block: 1 (last) UDP, Src Port: filenet-rmi (32771), Dst Port: filenet-pa (32772) TFTP Opcode: Data Packet (3) Block: 1 Data (72 bytes) 7) servidor client TFTP Acknowledgement, Block: 1 UDP, Src Port: filenet-pa (32772), Dst Port: filenet-rmi (32771) TFTP Opcode: Acknowledgement (4) Block: 1

L'HTTP (hypertext transfer protocol o protocol de transferència

d’hipertetx) és un protocol de capa d’aplicació que proporciona

transferència de documents d’hipertetx a la web. Utilitza un meca-

nisme client-servidor al port 80 basat en TCP.

Per obtenir més informació sobre l’especificació del protocol HTTP en els RFC 1945 i RFC 2616, aneu a la secció “Adreces d’interès” del web del crèdit.

!!

L'HTTP és un protocol sense estat i no orientat a la connexió permanent.

MIME

MIME (multipurpose Internet mail extension o extensió de propòsit múltiple per al correu) és el mecanisme utilitzat per descriure el contingut dels fitxers, saber si són una imatge, un full de càlcul, un executable, etc., i permetre al navegador obrir l’aplicació pertinent.


fics, contingut d’hipertext i multimèdia, també anomenat hipermèdia. De

fet, però, també existeixen navegadors en mode text (no gràfics) especia-

litzats per contingut únicament de text (per exemple el Lynx). Habitual-

ment usem els navegadors per obtenir contingut HTTP, però la majoria de

navegadors poden accedir a recursos d’altres tipus.

Per accedir als documents publicats en el WWW o a documents interns de

la xarxa corporativa, cal un mecanisme d’adreçament universal. L'URI

(uniform resource identifier o identificador uniforme de recursos) és el

mecanisme d’identificació de recursos universal i té la sintaxi sche-

ma:identifier (esquema:identificador). L’esquema descriu la sintaxi uti-

litzable per l’identificador i pot ser http, https, ftp, ghoper entre d’altres.

Identificador permet determinar el recurs concret dins d’aquest esquema.

Usualment, en HTTP s’utilitza un subconjunt de l'URI anomenat URL

(uniform resource locator, localitzador uniforme de recursos) per localit-

zar un recurs http. Així, en les barres de navegació trobem les típiques

URL http://www.uoc.es o ftp://ftp.rediris.es per exemple.

2.3.1. Especificació del protocol HTTP

El protocol HTTP estructura el diàleg client/servidor en un esquema molt

bàsic de petició/resposta. Fins a la versió HTTP 1.0, cada petició/resposta

implicava una connexió que s’obria i es tancava en finalitzar la resposta.

Amb les millores introduïdes en la versió HTTP 1.1, s’introdueix un meca-

nisme de connexions persistents. La connexió establerta es pot mantenir

un temps oberta per realitzar més peticions dins de la mateixa connexió

(per exemple, baixar altres components que estan en la pàgina).

El protocol HTTP és un protocol sense estat (statless), ni client ni servidor

mantenen un estat de sessió a nivell de protocol. Segurament us heu con-

nectat a un servidor de correu web (webmail) i heu establert una sessió

d’usuari mentre consulteu el correu. Aquesta sessió no s’implementa a ni-

vell del protocol d’aplicació HTTP sinó que és problema del desenvolupa-

dor web mantenir l’estat dels usuaris. Això es fa generalment utilitzant

tècniques com l’ús de cookies (galetes d’informació), passant paràmetres

per l’URL, amb camps ocults (típic dels formularis), etc.

La identificació de recursos es realitza mitjançant URI, URL o URN

segons correspongui. La seva sintaxi és la següent:

URI = uniform resource identifier (esquema:identificador)

URL = uniform resource locator (http://www.escoladeltreball.org)

URN = uniform resource name (ietf:rfc:2616)

URI

Sovint s’utilitza indistintament URI i URL tot i que no són el mateix. Un URI es pot classificar com un URL, un URN o ambdós. L'URI permet identificar elements globalment, l'URL localitzar-los i l'URN proporciona un mecanisme d’assignació de noms únic.

Connexions persistents

Les connexions persistents permeten que els múltiples elements d’una pàgina web (que es troben en fitxers diferents) es puguin baixar sense que calgui una connexió per a cada element.


Request (petició)

El diàleg HTTP s’inicia quan un client fa una petició (usualment, d’una pà-

gina web) a un servidor (usualment al port 80). Aquest missatge de petició

consta d’una primera línia anomenada línia de petició, seguit de capçale-

res, una línia en blanc i el cos de la petició:

• Línia de petició. La primera línia d’una petició sempre té la mateixa es-

tructura, per exemple: GET /docums/fitxa.html HTTP/1.1. El primer

camp és el mètode a usar, GET significa 'petició'. El camp següent és el

document a obtenir, i el tercer camp indica la versió del protocol HTTP

que s’utilitza. Aquesta primera línia ha d’acabar sempre amb els caràc-

ters CRLF.

• Headers (capçaleres). A continuació es troben les capçaleres de la pe-

tició. Les capçaleres permeten descriure opcions del client i opcions

preferibles del servidor. Per exemple, el client pot indicar el sistema

operatiu i el navegador que utilitza, i el servidor ho pot tenir en compte

a l’hora d’efectuar la resposta. Hi ha multitud de capçaleres i es reco-

mana consultar el document RFC 2616 (que descriu l’estàndard HTTP)

per ampliar-ne la informació. La capçalera Host és obligatòria en HTTP

1.1 i indica l'URL del servidor al qual s'adreça la petició.

• CRLF (línia en blanc). Una línia en blanc separa la part de capçaleres

de la petició de la part del cos. Aquest mecanisme està manllevat del

format dels missatges de correu, on també s’utilitza una línia en blanc

per separar les capçaleres del cos dels missatges.

• Body (cos). El cos del missatge és opcional i no s’utilitza usualment en

les peticions.

Mètodes

Les peticions HTTP contenen en el primer camp de la primera línia un

mètode. Aquest acostuma a ser GET o POST en les peticions, però hi ha

més mètodes:

• HEAD. Igual que GET però únicament se sol·licita la capçalera del do-

cument. S’utilitza per comprovar l’existència del document.

• GET. Petició al servidor per obtenir el document sol·licitat.

L'HTTP és un protocol sense estat que usualment tanca la connexió

per a cada petició/resposta.

Components d’una petició

Els components d’un missatge de petició HTTP són quatre:

• Línia de petició.

• Capçaleres.

• CRLF.

• Cos.

Diferència entre HTTP/1.0 i HTTP/1.1

Una de les diferències entre HTTP/1.0 i HTTP/1.1 és que en HTTP/1.1 hi ha una capçalera obligatòria (Host: <nom_servidor>), i en HTTP/1.0 no n’hi ha cap d’obligatòria. Això permet saber al servidor si la petició és per a ell, i permet implementar seus virtuals.


• POST. Envia al servidor informació que ha d’incorporar al recurs des-

tinació especificat. Un ús habitual és en els formularis, on les dades es

passen per POST perquè el servidor les incorpori en el document des-

tinació indicat.

• PUT. Permet posar en el servidor el document indicat. En lloc de bai-

xar un document, és un mètode per penjar un document en el servidor.

• DELETE. Elimina el document indicat del servidor. Si es deixa, és clar.

• TRACE. El servidor retorna com a missatge una còpia del missatge tal

com li ha arribat. És molt útil per al monitoratge del servei per part del

client, ja que pot veure quines transformacions ha patit la seva petició

en creuar passarel·les o gateways, proxies, etc.

• OPTIONS. És una sol·licitud d’informació de les opcions de transferèn-

cia del servidor. El servidor contesta indicant quines són les seves ca-

pacitats.

Response (resposta)

El servidor respon a les peticions del client amb missatges que tenen una

estructura similar a les peticions. Consten d’una primera línia anomena-

da línia d’estatus, seguit de les capçaleres, una línia en blanc i la resposta,

que va al final:

• Línia d’estatus. La primera línia d’una resposta té sempre un format com

HTTP/1.1 403 Accés prohibit. El primer camp indica el protocol HTTP

usat. El segon camp és un valor numèric de tres dígits que indica el tipus

de resposta donada. Hi ha una llista exhaustiva de cada valor d’estaus i el

seu significat. L’últim camp és un text descriptiu de l’estatus.

• Headers (capçaleres). La resposta conté totes les capçaleres que el ser-

vidor consideri oportú incloure.

• CRLF. Una línia en blanc separa les capçaleres del cos de la resposta.

• Body (cos). El cos de la resposta es troba en el body. Si s’ha sol·licitat una

pàgina web, el contingut a mostrar es troba aquí (tota la pàgina web, no us

confongueu amb les etiquetes HEADER i BODY del llenguatge HTML).

Estatus

Les respostes contenen un primer camp amb un valor numèric d’estatus.

En el document RFC 2616 es pot trobar la llista completa, però segons

quin sigui el primer dígit es pot fer la classificació següent:

• 1xx: informació genèrica.

• 2xx: acció amb èxit (successful).


• 3xx: redirecció.

• 4xx: error del client.

• 5xx: error del servidor.

2.3.2. Memòria cau

Usualment els navegadors client utilitzen memòria cau (cache memory)

per accelerar l’accés a la informació. El client pot indicar la mida de la me-

mòria destinada (usualment, megabytes) i la política a seguir per emma-

gatzemar les pàgines. Abans de sol·licitar una pàgina al servidor, el

navegador comprova si aquesta es troba ja en la memòria cau. Si és així la

serveix i s'estalvia l’accés per xarxa al servidor.

Els servidors poden incloure en les respostes HTTP capçaleres que indi-

quen la política a seguir amb la pàgina respecte a la memòria cau. Per

exemple, hi ha pàgines que no s’han de poder desar en la memòria cau,

com les que contenen la identificació de l’usuari (usuari i contrasenya),

dades de formularis dinàmics, dades bancàries, etc. Una tècnica habitual

dels programadors web és enviar aquestes pàgines caducades de manera

que la memòria cau del navegador no les emmagatzema.

2.3.3. HTTP segur: HTTPS

El protocol HTTP pateix els mateixos problemes de seguretat que els seus

companys d’inici d’Internet (FTP, TFTP, SMTP, etc.). Tota la informació viat-

ja en text net i és fàcilment monitorable per altres. Quan un usuari es connec-

ta en una web i indica l’usuari i la contrasenya, aquest text viatja sense cap

mena de protecció i qualsevol el pot capturar. Si les dades que es transmeten

són dades bancàries, llistes d’amistats íntimes o qualsevol tipus de dada que

es vol mantenir privada, no es pot usar HTTP així com així.

El primer mecanisme de seguretat que es va implementar per a HTTP va

ser el protocol SSL (secure socket layer o capa de sòcol segur) desenvolu-

pat per Netscape. L'SSL proporciona una capa entre la capa de transport

TCP i la capa d’aplicació HTTP en què les dades viatgen xifrades. L'HTTPS

solament és un esquema URI que indica la utilització de HTML més algun

mecanisme de transport xifrat com SSL o TLS.

El protocol SSL es va enviar a l'IETF (Internet Engineering Task Force,

Equip d’Enginyeria d’Internet, l’òrgan rector d’Internet) per a l'estan-

Quan s’utilitza HTTP sobre un protocol xifrat com SSL o TCL s’ano-

mena HTTPS (secure HTTP). Utilitza el port 443.

Quanta memòria cau utilitza el navegador que feu servir?


dardització i després de diversos canvis va sorgir el protocol TLS (trasn-

port layer security, capa de transport segura). El TLS proporciona

condicions iguals de confidencialitat i autenticació en les transmissions

HTTP que SSL.

Un dels avantatges de l’HTTPS és que permet la confidencialitat entre

tots dos extrems de la comunicació encara que només sigui un dels ex-

trems el que s’ha autenticat. Aquest model és molt pràctic en la web on

usualment un client anònim compra en una web autenticada. Quan es

volen pagar els bitllets d’avió, interessa que les dades de la targeta de

crèdit viatgin xifrades i que el receptor sigui la companyia aèria i no un

web fals.

L’ús dels certificats no és exclusiu per autenticar el servidor. Si cal, els clients

poden ser autenticats. Per exemple, una web pot requerir per al seu accés

que els clients disposin del certificat que els atorga aquest dret (expedit,

per exemple, per la mateixa entitat).

2.3.4. Proxy servers

La comunicació client/servidor que realitza el protocol HTTP no sem-

pre és directa. Sovint el trànsit passa a través d'intermediaris que no es

limiten simplement a encaminar el trànsit. Un servidor proxy és un in-

termediari entre client i servidor que atén les peticions dels clients i

les passa al servidor en nom seu, tot retornant la resposta del servidor

al client. En aquest procés pot realitzar modificacions i filtratges. Un

proxy server tant pot ser un servidor com una aplicació amb aquesta

finalitat.

El servidor proxy rep peticions del client i les passa al servidor. En

aquest procés, si cal, pot modificar la petició del client. La resposta del

servidor la fa arribar al client, però també la pot modificar si li cal. So-

vint el servidor proxy pot respondre a la petició del client directament

sense consultar el servidor perquè emmagatzema les respostes ante-

riors en memòria cau. Si pot respondre la petició del client directament

de la seva memòria cau s’evita la connexió al servidor. En la figura 5 es

pot veure l’esquema de funcionament d’una connexió client/servidor

proxy.

Un servidor proxy fa d’intermediari entre el client i el servidor i filtra

el trànsit segons les polítiques establertes. Respon a les peticions

del client de la pròpia memòria cau si disposa de la pàgina en cache

i evita sol·licitar-la al servidor.

L'HTTPS garanteix el trànsit de dades xifrat i el certificat del servidor, “en principi”, autentica el web.


Figura 5. Model funcional de l'HTTP proxy

Els servidors proxy es poden encadenar i hi ha un protocol anomenat

ICAP (Internet content adaptation protocol, protocol d’Internet d’adap-

tació de contingut) per comunicar-se entre ells. En un primer nivell els

propis navegadors efectuen la funció de cache (cau) emmagatzemant

pàgines en la seva memòria cau. A partir del client es poden encadenar

diversos proxy en la xarxa, el del departament de l’empresa, el de l’em-

presa, etc. Per exemple, el mateix ISP (Internet service provider o prove-

ïdor d’Internet) també en pot establir un pel qual passa el trànsit dels seus

clients.

Una qüestió importantíssima és com es fa el monitoratge i confidencialitat

del trànsit que passa per un proxy. Usualment aquest registra informació

detallada del trànsit, com la IP, l’hora, les pàgines visitades, etc. Als usua-

ris no els agrada que un altre pugui disposar del registre de totes les acti-

vitats que han realitzat en el web. Molts usuaris, però, no saben que el seu

trànsit s’enregistra perquè no saben que el seu trànsit passa per un servi-

dor proxy (per exemple, els de l'ISP).

Tipus de servidors proxy

Hi ha moltes classificacions dels servidors proxy segons la funció, ubica-

ció, etc. Molts dels tipus comparteixen característiques o són sinònims

d’altres. Aquí només en destacarem tres:

1) Web proxy cache (servidor proxy cau web). Servidor proxy centrat

en el trànsit web. Serveix respostes emmagatzemades (en la memòria

cau) de consultes anteriors del mateix client o de diferents clients. Això

permet incrementar la velocitat de resposta, ja que no cal fer la consulta

de nou al servidor. Al mateix temps incrementa l’amplada de banda en evi-

tar fer la consulta de nou. Usualment incorpora la possibilitat de filtrar el

trànsit, impedint l’accés a determinades URI que formen part d’una llista

negra (blacklist).

2) Filtering web proxy (servidor proxy de filtratge). Disposa d’un alt

grau de capacitat de filtratge amb un nivell de granularitat del control

Granuralitat

Es diu que el nivell de granuralitat en el control d’accés és molt detallat quan es vol indicar que es pot configurar amb molt detall el que es permet i no es permet fer. Un exemple de poca granularitat és prohibir tot el trànsit web de sortida. Un exemple de granularitat elevada és permetre a en Pere accés a Internet de 10:45 a 11:15 però només a pàgines en català.


d’accés molt detallat. Efectua un fort control del trànsit, determina el

grau d’accés, pot requerir autenticació per l’accés a la web, emmagatzema

logs detallats, control antivirus, etc. Les característiques de filtratge es

tornen més exigents en clients com, per exemple, escoles, on cal evitar

l’ús de webs de continguts no acadèmics o per a majors d’edat.

3) Intercepting proxy server (servidor proxy intermediari o transparent).

Es tracta d’un servidor proxy transparent per a l’usuari, que no sap que

existeix. De fet, l’usuari adreça les seves peticions al que creu que és un

gateway (porta d’enllaç predeterminada) o un servidor HTTP, i en realitat

el trànsit s'adreça al servidor proxy. Com que el client no ha de configurar

res d’especial, no se n’adona.

Des del punt de vista del client podem dir que hi ha servidors proxy fixos

i transparents:

• Proxies fixos. Per disposar d’accés a Internet, el client ha de configurar

la seva connexió directament a Internet o mitjançant un proxy. Si és

mitjançant un proxy cal indicar-ne l'adreça i altres opcions de configu-

ració. Aquest és un cas molt usual en empreses i escoles. El client sap

que el seu trànsit passa pel proxy (i que és enregistrat).

• Proxies transparents. El client creu que disposa d’una connexió direc-

ta a Internet (així ho configura en el navegador, per exemple), però en

realitat tot el seu trànsit s’encamina a un proxy. Com que el client no

ha configurat res d’especial, no té manera de veure si la seva empresa

o el seu ISP fan passar el trànsit per un servidor proxy.

2.3.5. Exemple de connexió HTTP

Tot el diàleg client/servidor té forma d’ordres i respostes, com es pot veure

en l'exemple següent de connexió HTTP/1.0 al servidor local. Aquí es rea-

litza una connexió HTTP per mitjà d’un Telnet al port 80 d’un servidor

HTTP per fer una petició GET d’una pàgina web.

[root@portatil ~]# telnet localhost 80Trying 127.0.0.1...Connected to localhost.Escape character is ‘^]’.GET /index.html HTTP/1.0

HTTP/1.1 200 OKDate: Sat, 31 May 2008 19:37:47 GMTServer: Apache/2.2.8 (Fedora)Last-Modified: Sat, 31 May 2008 19:35:26 GMTETag: "1c0629-c1-44e8bdd3c9b80"Accept-Ranges: bytesContent-Length: 193Connection: close


En l’exemple anterior es pot fer un seguiment dels elements que interve-

nen en una comunicació http. La petició client és una petició GET, seguida

d’una línia en blanc i sense cos (el GET no en requereix). La resposta del

servidor comença amb una primera línia d’estatus (el valor 200 indica ok),

seguida de vuit capçaleres i finalment el cos. El cos de la resposta és la pà-

gina web HTNL que visualitzarà el navegador.

En l'exemple següent el client demana al servidor quines són les ordres

que implementa.

2.4. El servei d’impressió en xarxa

Parlem de servei d’impressió en xarxa quan en una xarxa disposem

d’impressores de xarxa gestionades per un o més servidors d’impres-

sió, que ofereixen els seus serveis als altres equips o clients d’impres-

sió. Els protocols d’impressió en xarxa han evolucionat, des dels

estàndards originals LPD/LPR de BSD i LP de System V, fins a l’estàn-

dard actual d’impressió CUPS, utilitzat per la majoria de sistemes ope-

ratius.

El CUPS permet la gestió de cues d'impressió formades per impressores

o classes (grups d’impressores). També permet la creació de diverses ins-

tàncies d’una impressora (amb opcions diferents per a cada instància).

Content-Type: text/html; charset=UTF-8

<html><head><title>Prova</title></head><body><h1>Aixo es una prova de pagina web</h1><p>aqui es pot escriure un pararaf amb contingut molt mes interessant que aquest</p></body></html>

Connection closed by foreign host.

[root@portatil ~]# telnet localhost 80Trying 127.0.0.1...Connected to localhost.Escape character is ‘^]’.OPTIONS /index.html HTTP/1.0

HTTP/1.1 200 OKDate: Sat, 31 May 2008 19:42:06 GMTServer: Apache/2.2.8 (Fedora)Allow: GET,HEAD,POST,OPTIONS,TRACEContent-Length: 0Connection: closeContent-Type: text/html; charset=UTF-8


Les opcions es poden definir globalment per a tots els usuaris i es poden

redefinir de manera particular per a cada usuari. Implementa mecanis-

mes per publicar les impressores i per descobrir les impressores remotes

d’altres servidors. Utilitza un llenguatge descriptiu per descobrir les carac-

terístiques pròpies de cada impressora.

En estar basat en el protocol IPP (que es basa en HTTP/1.0), el CUPS per-

met mecanismes autenticació, seguretat i xifratge. Es poden establir polí-

tiques d’accés i quotes d’impressió als usuaris.

2.4.1. Components de la impressió en xarxa

En l’entorn de la llar, tothom identifica clarament els components neces-

saris per imprimir: cal una impressora connectada a l’ordinador. Aquest

model, però, no és escalable en l'àmbit empresarial, on no té sentit dispo-

sar d’una impressora per a cada equip. Ni se’n pot assumir el cost ni és ne-

cessari per al rendiment. Si les xarxes van sorgir per compartir recursos

entre usuaris i equips, el recurs d’impressió és un dels més utilitzats a

l’hora de compartir. És per això que no cal confondre el model d’impressió

local que tenim a casa (equip + impressora) amb el model d’impressió en

xarxa. La figura 6 mostra un exemple amb impressores locals, impresso-

res de xarxa i servidors d’impressió.

Figura 6. Esquema d’un sistema d’impressió en xarxa

El servidor d’impressió CUPS utilitza el protocol IPP per comuni-

car-se i està implementat per a la majoria de sistemes operatius.

Permet l'autenticació i xifratge, publicació i descobriment d’impres-

sores i una administració web fàcil i compacta.

IPP és l’acrònim d’Internet printing protocol o protocol d’impressió d’Internet.


Segurament la millor manera de començar a entendre el funcionament de

la impressió en xarxa és descriure’n el model i detallar els components

que hi intervenen:

• Impressora local no compartida. Impressora connectada directament

a un host utilitzant algun tipus de connector local com els ports USB,

en sèrie, en paral·lel o IEEE 1394, per exemple. És el cas habitual de la

impressora que tenim a casa connectada al nostre equip. És una im-

pressora local des del punt de vista de la connexió física. Si l’equip on

està connectada no comparteix la impressora en la xarxa, llavors fa una

funció purament local en l’equip.

• Impressora local compartida en xarxa. Impressora que físicament

està connectada localment a un equip utilitzant algun dels ports lo-

cals (USB, en paral·lel, etc.). L’equip permet la utilització comparti-

da de la impressora amb altres equips actuant com a servidor

d’impressió.

• Impressora de xarxa. Impressora connectada directament a la xarxa

com un node més de la xarxa. Per tant, disposa d’adreça MAC i IP prò-

pia, i és accessible per la xarxa per TCP/IP. Les impressores de xarxa

disposen d’una targeta interna que els permet la connexió a la xarxa di-

rectament per mitjà d’un connector RJ45 o utilitzen altres mecanismes

com l’anomenat JetDirect.

• JetDirect. Aparell desenvolupat per HP (Hewlett-Packard) que cons-

ta d’un connector RJ45 que permet connectar-lo com un node més a

la xarxa (amb MAC i IP pròpia) i un o més ports paral·lels on es con-

necten impressores de xarxa. Per tant, permet fer de connector con-

vertint impressores no preparades per treballar en xarxa en

impressores de xarxa.

• Servidor d’impressió. El servidor d’impressió és l’equip encarregat de

gestionar una o més impressores (en principi, connectades localment)

i les cues d’impressió corresponents (una o més) de cada impressora.

El model bàsic és un equip amb una impressora connectada localment

que executa un programari que permet compartir la impressora amb

els altres equips de la xarxa. El servidor d’impressió pot tenir connec-

tades localment múltiples impressores. De fet, també pot tenir connec-

tades impressores remotes (de xarxa) i utilitzar-les també de servidor

d’impressió. El servidor d’impressió és l'equip que ofereix serveis d’im-

pressió a altres equips.

• Client d’impressió. És l'equip que utilitza els serveis prestats pels ser-

vidors d’impressió per poder imprimir.


• Cua d’impressió. Els servidors d’impressió gestionen les cues d’impressió

de cada impressora de xarxa. Una cua d’impressió s’identifica amb un

nom i va lligada a una impressora i a unes propietats determinades de la

impressora i de la cua. Per exemple, en una mateixa impressora làser d’al-

tes prestacions es pot generar una cua d’impressió de baixa prioritat i poca

resolució amb accés per als alumnes, i una altra cua d’impressió d’alta qua-

litat i prioritat elevada per als professors. Les cues d’impressió accepten

els jobs (treballs) que reben i els posen en llista d’espera (cua o memòria

intermèdia) per imprimir-los a mesura que finalitza el job l’anterior.

• Job (treball d’impressió). S’anomena job el treball d’impressió que

s’envia a imprimir a una cua d’impressió. El servidor d’impressió ac-

cepta jobs d’altres equips dirigits a les cues d’impressió que gestiona.

Un job consta usualment de les dades a imprimir, un nom, un identifi-

cador únic, la data i hora, la prioritat, l’usuari propietari del job, el nom-

bre de còpies, la mida en bytes, etc.

• Impressora. Dispositiu que permet imprimir en paper imatges i/o textos.

Hi ha diverses tecnologies d’impressió com, per exemple, matricials, de

tinta, làser, etc. També hi ha les anomenades MFP (multifunction prin-

ter o impressores multifuncionals), que permeten al mateix temps actuar

d’escàner i de fax, reconèixer targetes amb imatges i vídeo, etc.

• Controlador d’impressió. Com és usual en la informàtica, cada aparell o

dispositiu (device) requereix el controlador (driver) corresponent. Per tal

de poder utilitzar les capacitats d’impressió d’una impressora cal disposar

del programari que la gestiona, el seu controlador de dispositiu. Usual-

ment es disposa d’un CD amb els controladors corresponents en comprar

l’aparell, però també hi ha multitud de controladors genèrics ja incorpo-

rats en els mateixos sistemes operatius i servidors d’impressió.

2.4.2. Procediments de configuració en xarxa

El servidor d’impressió és l'equip que ofereix serveis d’impressió a

altres equips. Una impressora de xarxa pot ser una impressora di-

rectament connectada a la xarxa o una impressora compartida per

mitjà d’un servidor d’impressió. El client d’impressió utilitza els

serveis prestats pel servidor d’impressió.

Una impressora pot estar connectada localment a un equip i oferir

servei únicament a aquest equip (impressora local de l’equip). Si

l’equip al qual està connectada la comparteix per ser utilitzada per

altres hosts, llavors el host actua com a servidor d’impressió, i la im-

pressora és una impressora en xarxa.


Per establir un servei d’impressió en xarxa caldrà instal·lar i configurar

impressores, i configurar els servidors d’impressió per poder proporcio-

nar aquest servei als clients. Els procediments a seguir són els següents:

• Impressora en xarxa. Si es disposa d’una impressora en xarxa (amb tar-

geta de xarxa pròpia o mitjançant JetDirect) caldrà instal·lar i configu-

rar la impressora. Proporcionar-li una adreça IP, la màscara de xarxa,

el nom de host i la resta d’opcions de xarxa que siguin necessàries

(DHCP, DNS, etc.). També caldrà definir les opcions globals d’impres-

sió (mida del paper, tipus de lletra, doble cara, etc.). Els equips clients

que vulguin utilitzar aquesta impressora la poden configurar com una

impressora local més. Fixeu-vos que la impressora és remota (no està

connectada a cap port local del client) però des del punt de vista lògic

serà una impressora local més.

• Impressora local en un servidor d’impressió. Si la impressora es con-

necta localment a un equip (és més barat utilitzar connexions locals de

tipus USB que de xarxa), caldrà instal·lar i configurar la impressora en

l’equip. S'haurà d'endollar al port pertinent (USB, en paral·lel, en sèrie

o IEEE 1394) i fer la configuració de programari en l’equip, tot carre-

gant els controladors adequats i establint les opcions globals de la im-

pressora. Tot seguit, si l’equip ha d’actuar com a servidor d’impressió

caldrà configurar-lo per tal d’oferir aquest servei.

• Impressora remota en un servidor d’impressió. Qualsevol impressora

de xarxa es pot connectar a un equip com una impressora local tot i ser

remota. A més a més, qualsevol host pot fer de servidor d’impressió

oferint les seves impressores locals (i remotes) als altres hosts. Per

tant, qualsevol host pot fer de servidor d’impressió, tant de les impres-

sores que té connectades directament a algun dels seus ports, com

d'impressores remotes que té connectades com si fossin locals.

2.4.3. Protocols d’impressió

En sistemes Unix, el protocol d’impressió local i remot més utilitzat és

l'LPD/LPR (line printer daemond / line printer remote o dimoni d’im-

pressió local/impressió remota) de la universitat de Berkeley (BSD Unix).

Utilitza lpd com a dimoni d’impressió i l’ordre lpr per enviar treballs a

imprimir. Les ordres característiques són: lpd, lpr, lpq, lprm i lpc. El di-

Un servidor de xarxa ofereix als altres host fer ús de les cues d’im-

pressió que gestiona. Aquestes cues d’impressió poden correspon-

dre a impressores connectades físicament a algun dels ports locals

del servidor o a impressores remotes de xarxa.


moni lpd gestiona les cues i els treballs d’impressió i accepta missatges de

les ordres lpq, lpr, lprm i lpc. També accepta missatges TCP/IP d’altres

equips remots que implementen el protocol LPD.

La comunitat Unix s’ha dividit durant molts anys entre el sistema d’im-

pressió anterior i el que proporciona l'Unix System V. De fet, no només

pel que respecta als temes d’impressió sinó amb moltes de les opcions

d'estructuració del sistema hi ha aquestes dues famílies o maneres de fer,

les de BSD Unix (Universitat de Berkeley) i les de Unix System V (Solaris,

SCO, etc.). Les ordres usuals en l'Unix System V printing system (sistema

d’impressió de System V) són lp, lpstat, cancel, lpadmin i lpmove.

Per evitar aquesta dualitat, molts sistemes Unix i Linux proporcionen su-

port a tots dos conjunts d’ordres tot i que en realitat només implementen

un dels sistemes d’impressió.

En sistemes Microsoft s’utilitza el protocol network printing protocol

(protocol d’impressió de xarxa), que permet compartir impressores i que els

clients es connectin a impressores remotes compartides per altres equips.

Un protocol molt usat per permetre a clients Windows connectar-se a im-

pressores d’equips no Windows és el protocol Samba. També permet a clients

no Windows connectar-se a impressores compartides del Windows simu-

lant ser equips clients Windows.

Un conjunt d’empreses i organismes format principalment per Novell, Xerox

i IETF (Internet Engineering Task Force, comitè d’Internet) es van proposar

crear un protocol d’impressió remota que fos àmpliament utilitzat, que fun-

cionés sobre TCP/IP i proporcionés capacitats d’autenticació, control d’accés,

encriptació, etc. Aquest protocol s’anomena IPP (Internet printing protocol,

protocol d’impressió d’Internet) i es basa en l'HTTP/1.0. Ha rebut moltes crí-

tiques perquè no és un protocol construït de nou sinó basat en (funciona so-

bre) l'HTTP. Possiblement això el fa més lent i pesat, però li proporciona un

avantatge importantíssim: l'HTTP ja està provat i disposa de tot! Per exem-

ple, el protocol IPP no ha de desenvolupar l’encriptació per ell mateix sinó

que utilitza l’encriptació creada per a l'HTTP (SSL i TLS).

Els sistemes principals d’impressió en xarxa són l'LPD/LPR, LP Sys-

tem V, SMB, IPP i CUPS.

IPP (Internet printing protocol o protocol d’impressió d’Internet)

és el protocol desenvolupat entre d’altres per l'IETF per convertir-

se en un estàndard d’impressió a Internet. Es basa en l'HTTP/1.0 i

proporciona mecanismes de seguretat.

SMB/CIFS contra SAMBA

El protocol de compartició de fitxers Windows és SMB/CIFS, i SAMBA és la versió de programari lliure que imita aquests protocols.

SMB és l’acrònim de server message block o bloc de missatges de servidor. Mentre que CIFS ho és de common Internet file system o sistema de fitxers d’Internet. Aquest protocol és l’evolució de l'SMB (el substitueix). Mentre que SAMBA és una implementació de programari lliure de l'SMB/CIFS.


De fet, però, l’estàndard que s’ha imposat com a servidor d’impressió és

el CUPS (common Unix printing system o sistema comú d’impressió en

Unix). El CUPS utilitza IPP i proporciona una interfície web d’adminis-

tració molt fàcil d’usar. Imita la implementació de l'LPD/LPR de Berke-

ley i de System V en la interfície però amb una implementació interna

diferent.

2.4.4. El servidor CUPS

CUPS (common Unix printing system o sistema comú d’impressió en

Unix) és el sistema d’impressió més utilitzat en l’actualitat en sistemes ti-

pus Unix i Mac. La majoria de distribucions Linux el porten com a servidor

d’impressió, com també els sistemes operatius Macintosh. El CUPS va ser

desenvolupat per l’empresa Easy Software Products el 1997/99 i actual-

ment està sota llicència GNU.

Un dels objectius del CUPS era unificar els sistemes d’impressió en Unix

i superar la divisió existent entre el sistema del BSD Unix de Berkeley i

l'Unix System V. És per això que presenta una interfície a nivell d’ordres

compatible amb tots dos sistemes (es poden usar les ordres lp i lpr indis-

tintament), però la implementació interna és pròpia del CUPS. Un altre

objectiu és que pugui ser usat per diferents sistemes operatius. En l’actua-

litat hi ha programari del CUPS per distribucions Linux, Unix, Windows i

Macintosh. El CUPS utilitza el protocol IPP per a l’administració de les

impressores, classes, cues i treballs d’impressió i, per tant, proporciona

mecanismes de seguretat i autenticació.

El sistema d’impressió CUPS disposa d’una interfície web d’administració

molt pràctica i d'ús senzill que permet generalitzar el mecanisme d’admi-

nistració a qualsevol sistema. L’administració per web es realitza de la ma-

teixa manera independentment del sistema operatiu i del servidor.

Els fabricants d’impressores i de controladors de dispositius (drivers) ge-

neren controladors d’impressió per al sistema CUPS. El CUPS permet

configurar els drivers de les impressores utilitzant PPD (PostScript prin-

ter description o llenguatge de descripció d’impressores PostScript), un

llenguatge de descripció d’impressores que descriu totalment les caracte-

rístiques i capacitats que tenen.

El sistema d’impressió CUPS (common Unix printing system o sis-

tema comú d’impressió en Unix) utilitza IPP i proporciona una in-

terfície web d’administració molt fàcil d’usar. A nivell d’interfície de

text imita tant la implementació de Berkeley –lpr– com la de Sys-

tem V –lp–.


El CUPS s’estructura en tres components:

• Scheduler (planificador de tasques). És la part encarregada de la gestió i

administració del servei d’impressió i dels treballs d’impressió. Els usua-

ris interactuen amb el planificador de tasques enviant treballs d’impressió

mitjançant les ordres d’usuari o per l'administració web. Utilitza l'IPP com

a protocol de comunicacions i converteix les peticions d’altres protocols

(com, per exemple, LPD/LPR) a aquest protocol. S’encarrega de la gestió

de la interfície de l’administració web, dels fitxers de configuració de

CUPS, del registre de logs, de l’arrencada i parada del servidor, etc. També

realitza els processos d’autenticació, gestió de les classes i els jobs.

• Filter system (sistema de filtratge). Els treballs d’impressió que són ac-

ceptats pel planificador de tasques es destinen al sistema de filtratge.

L’objectiu és poder convertir molts diferents formats d’entrada de dades

en un format de sortida adequat per a la impressora. Per fer-ho utilitza

una sèrie de filtres que processen la informació segons el seu MIME type

(tipus MIME de format de dades) i la converteixen al format requerit.

• Back-end. El back-end és l’encarregat de fer arribar la informació a im-

primir a la impressora. Les dades es poden enviar a la impressora per

camins diferents i el back-end és l’encarregat de fer-ne la gestió. Si la

impressora és local, el back-end hi pot accedir per USB, en sèrie, en pa-

ral·lel, o pel port IEEE 1394. Si la impressora és remota el back-end hi

accedeix per l'IPP, JetDirect, LPD, SMB, etc.

2.4.5. Administració de CUPS

El servei d’impressió CUPS permet una administració molt completa per

tres mitjans diferents:

1) Les ordres en mode text.

2) La interfície gràfica d’administració d’impressió que proporciona el

sistema operatiu.

3) L’administració web.

De tots, el més fàcil i pràctic d’utilitzar és l'administració web, que a més

a més proporciona un mecanisme d’administració únic entre sistemes

operatius diferents (la interfície sempre és la mateixa).

La majoria de distribucions Unix i Linux incorporen el servidor CUPS per

defecte. Si no és així, caldria instal·lar-lo seguint el procediment habitual

segons el sistema operatiu de què es tracti.

El cor del servei CUPS és el dimoni cupsd que escolta en el port 515 (el

mateix port de l'LPD). L’administrador web del servei CUPS és accessible

pel localhost al port 631 per a l’administració local. Si s’activa l’adminis-


tració remota, es pot administrar fàcilment qualsevol servidor d’impres-

sió per web simplement indicant la ubicació http://ip-servidor-o-

nom:631. La figura 7 mostra la pantalla inicial d’administració web de

CUPS, des d’on es pot realitzar tota l’administració.

Figura 7. Administració web del servidor CUPS

Evidentment, cada sistema operatiu proporciona en el seu entorn gràfic

l’aplicació corresponent per a la gestió d’impressió. Les capacitats que

proporciona són similars a les que s’obtenen en mode ordres per web. Evi-

dentment, el format de l’aplicació gràfica (GUI graphics user interface o

interfície gràfica d’usuari) varia segons el sistema, distribució, escriptori

Gnome, escriptori KDE, etc. Per exemple, en Fedora l’aplicació que per-

met la gestió gràfica de CUPS és diu system-config-printer. La figura 8

mostra l’aplicació gràfica d’administració de CUPS.

Figura 8. Administració del servidor CUPS des del GUISegons la distribució Linuxi segons l’escriptori que utilitzeu, l’administració CUPS GUI tindrà un aspecte diferent.


A més a més, CUPS proporciona un ampli ventall d’ordres per gestionar

la impressió des del mode ordres del sistema operatiu. Tot el que es pot

administrar gràficament i pel web es pot administrar per mitjà d’ordres.

A grans trets, l’administració del servei CUPS s’estructura en les adminis-

tracions següents:

• Administració general del servidor CUPS.

• Administració d’impressores i instàncies.

• Administració de classes.

• Administració de treballs d’impressió.

Els objectius del sistema d’impressió CUPS són els següents:

• Sistema:

– Publicar impressores, classes i instàncies.

– Descobrir automàticament impressores publicades per altres sistemes.

– Detectar automàticament les capacitats de les impressores desco-

bertes.

– Proporcionar mecanismes d’autenticació i xifratge. Permetre esta-

blir polítiques d’accés i quotes d’impressió.

– Definir opcions globals d’impressió i permetre que es redefineixin

particularment per a cada usuari.

• Usuari:

– Permetre a l’usuari enviar treballs d’impressió a una cua d’impressió.

– Permetre a l’usuari determinar l’estatus d’un treball d’impressió o

d’una impressora.

Les ordres més importants del servidor CUPS organitzades per pri-

vilegis i funcionalitat són les següents:

• Ordres de configuració del servidor: cupsd(8), cups-lpd(8),

cups-polld(8), cups-addsmb(8).

• Ordres d’administració d’impressores, classes i treballs:

accept(8), reject(8), cupsenable(8), cupsdisable(8),

lpadmin(8), lpmove(8).

• Ordres d’usuari: lp(1), lpr(1), lpoptions(1), lpstat(1),

lppasswd(1), cancel(1), lpq(1), lprm(1).

Els fitxers principals de configuració de CUPS són cupsd.conf(5),

printers.conf(5), classes.conf(5) i client.conf(5).

En la secció “Annexos” del web d’aquest crèdit, trobareu informació sobre el sistema d’impressió CUPS.

!!


– Permetre a l’usuari cancel·lar treballs d’impressió.

– Permetre a l’usuari descobrir les capacitats d’una impressora.

– Definir cada usuari les pròpies opcions d’impressió.


3. Serveis de correu: SMTP, POP, IMAP, NEWS

En molts conceptes, el correu electrònic imita el funcionament del correu

postal. És un sistema distribuït que permet als usuaris enviar missatges a

un destinatari final. El correu electrònic ha tingut una important evolució

des dels primers sistemes que únicament podien intercanviar missatges

de text ASCCII fins als correus electrònics amb continguts multimèdia

d’avui en dia.

En el servei de correu es diferencia molt clarament entre el mecanisme

de transport dels missatges i els missatges. El mecanisme de transport

dels missatges és el protocol SMTP i és independent del format i el con-

tingut del missatge. Els missatges originals eren en text net ASCII de 7

bits, però actualment es permet tot tipus de contingut en un missatge.

Això és possible gràcies als tipus MIME que descriuen els missatges.

El mateix disseny del sistema de correu ha evolucionat a mesura que ha

evolucionat la tecnologia a Internet. En el model bàsic de transport usant

SMTP, s’exigeix que el receptor disposi de connexió permanent a Internet

i es connecti al servidor de correu localment per tal de consultar-lo. Quan

els usuaris tenen accés a Internet per un ISP, volen poder baixar tot el cor-

reu de cop i poder examinar-lo un cop tancada la connexió (per no pagar

trucada telefònica). El protocol POP proporciona aquest mecanisme per

baixar d’un servidor de correu tots els missatges de l’usuari.

Un cop Internet es popularitza i s’abaixen els costos de connexió, l’usuari

s’acostuma a baixar el correu des de llocs diferents, però té l’inconvenient

que el correu li queda repartit per diverses màquines (usant el correu

POP). Cal un mecanisme que permeti accedir i gestionar el correu i les

bústies directament en el servidor. El protocol IMAP proporciona aquest

mecanisme.

La immensa popularitat del WWW i la utilització de llistes de correu han

fet perdre importància al servei de notícies news. Basat en el protocol

NNTP, el servei de notícies permetia publicar articles com qui publica

anuncis en un tauler d’anuncis. És un mecanisme per fer públic i compar-

tir informació sense que calgui indicar els destinataris.

3.1. El servei de correu SMTP

El servei de correu electrònic és un dels primers serveis que es van utilit-

zar en les xarxes i un dels més populars a Internet. Ha tingut una impor-


tant evolució des dels primers sistemes que podien intercanviar

únicament missatges de text ASCCII (7 bits) fins als portals web usats per

milions d’usuaris per intercanviar correu amb continguts multimèdia.

El 1982 es van desenvolupar els estàndards que defineixen el correu electrò-

nic, els quals es descriuen en el document RFC 821, que explica el protocol de

transmissió, i el document RFC 822, que descriu el format dels missatges.

Aquests dos estàndards han evolucionat i actualment s’utilitzen els docu-

ments RFC 2821 i RFC 2822. A més a més, per permetre missatges multimè-

dia s’ha definit l’estàndard MIME corresponent al document RFC 2231.

En molts conceptes, el correu electrònic imita el funcionament del correu

postal. És un sistema distribuït que permet als usuaris enviar missatges a

un destinatari final. Per aconseguir-ho hi intervenen diversos agents que

es descriuen a continuació:

• MUA (mail user agent o agent de correu d’usuari). L’usuari utilitza un

MUA per redactar, rebre i manipular correus electrònics. Un MUA és un

programari que permet aquestes capacitats que poden ser aplicacions en

línia d’ordres (com, per exemple, l’ordre Unix mail), aplicacions de text

(com, per exemple, mutt, pine, etc.), interfícies gràfiques (com thunder-

bird) i portals de correu web (com Gmail, Yahoo, etc.). L’usuari interactua

usualment amb un MUA i és aquest el que lliurarà el missatge al sistema

de transport (SMTP) per fer-lo arribar al destinatari en el cas d’enviar cor-

reu, o bé el MUA obtindrà el missatge d’una bústia de correu (on l’ha dipo-

sitat l'SMTP) i el mostrarà a l’usuari en cas de recepció de correu.

• MTA (mail transport agent o agent de transport de correu). L’agent

de transport de correu és l’encarregat de transportar els missatges al

destinatari indicat. Aquesta tasca correspon al protocol SMTP. L'MTA

rep el missatge d’un MUA i s’encarrega del seu transport fins al desti-

natari final. Generalment realitzen la funció de client/servidor o emis-

sor/receptor al mateix temps. La funció que es realitza en cada cas es

descriu a continuació:

– MTA client SMTP (emissor). S’anomena client de correu o emissor

(segons l’arquitectura client-servidor) el servidor SMTP (fixeu-vos en

L’especificació original distingeix molt clarament entre el mecanis-

me de transport dels missatges i els missatges. El mecanisme de

transport dels missatges és el protocol SMTP (simple mail trans-port protocol o protocol simple de transport de correu) i és indepen-

dent del format i el contingut del missatge. El missatge es compon

del sobre (o envelop) i el contingut, que al mateix temps el formen

les capçaleres i el cos del missatge.

Per obtenir més informació sobre l’especificació del protocol SMTP en els RFC 821, 822, 2821 i 2822, aneu a la secció “Adreces d’interès” del web del crèdit.

!!

Podeu esbrinar més coses de l’estàndard MIME consultant el subapartat “Els tipus MIME” d’aquest mateix nucli d’activitat.

!!

Ambigüitat dels agents del sistema de correu

Els agents que intervenen en el sistema de correu electrònic tot sovint fan més d’un paper, fet que provoca ambigüitat en la definició de cada un.

Servidor SMTP

Sovint el programari de servidor SMTP (com, per exemple, sendmail) fa tant la funció de client (emissor de missatges) com la de servidor (receptor de missatges).


l’ambigüitat) que envia el correu cap al destinatari. És qui envia el

correu utilitzant el protocol SMTP. Estableix les connexions amb els

servidors/receptors SMTP.

– MTA servidor SMTP (receptor). S’anomena servidor de correu o re-

ceptor el programari de servidor SMTP que rep els missatges de correu

entrant i els lliura a la bústia del destinatari si es tracta d’un lliurament

local, o els reenvia a un altre servidor SMTP si va destinat a un sistema

remot. Fixeu-vos, per tant, que el fet que un receptor MTA rebi un cor-

reu no significa que el missatge hagi arribat al destinatari final.

• MDA (mail delivery agent o agent de lliurament de correu). Un ele-

ment extra en l’estructura de correu són els MDA. Són els encarregats

de fer el lliurament final del missatge en la bústia del destinatari. En

el procés poden realitzar diverses accions segons un conjunt de regles

definibles. Un exemple d'MDA és el programa procmail, que permet

filtrar els missatges entrants posant-los en una bústia o una altra, es-

borrant-los, marcant-los com a correu brossa (spam), fent-ne còpies,

reenviant-los a altres bústies i a altres destinataris, etc. Usualment, en

sistemes de correu que no disposen d'MDA, és el mateix MTA qui dipo-

sita el missatge en la bústia del destinatari final.

• Adreça de correu. Els usuaris que volen utilitzar el sistema de correu

electrònic han de disposar d’una bústia de correu en un servidor de cor-

reu. Els missatges s’adrecen per la xarxa utilitzant la ja coneguda no-

menclatura usuari@domini-servidor-correu, que es llegeix compte de

correu de l’usuari tal en el domini qual. Així, per exemple, a un usuari

amb un compte de correu de nom pere en el domini fp-oberta.cat se li

poden adreçar missatges a l’adreça [email protected].

• Bústies de correu o mail box. Els usuaris tenen bústies de correu en un

servidor de correu. Quan el servidor de correu MTA rep un missatge

destinat a un usuari amb compte de correu en el propi servidor, el di-

posita en la bústia de correu corresponent (si no hi ha un MDA pel

mig). Fixeu-vos que dipositar el missatge en la bústia de l’usuari no ga-

ranteix que l’usuari el llegeixi, cal un altre pas que és la recuperació del

missatge de l’usuari de la seva bústia de correu. Aquest pas es realitza

des d’un MUA i sovint empra protocols com POP o IMAP, fora de

l’abast de les explicacions del correu SMTP.

• Llistes de correu i àlies. Els àlies i les llistes de correu es tradueixen a

adreces de comptes de correu. Si la llista de correu es gestiona local-

ment el MUA local l’expandirà en el conjunt d’adreces d’usuari corres-

ponents i enviarà el correu electrònic a cada un. Si la llista d’usuaris és

remota, s’envia el correu electrònic al sistema remot i serà l'MTA re-

mot el que l’expandirà i enviarà un correu electrònic a cada membre de

Exemple d'MDA

Podem trobar un exemple de lliurament (delivery) en el fitxer .forward que indica els comptes de correu on reenviar els missatges que rep un usuari en un sistema Unix.

@ (at)

@ correspon al significat at en anglès o a en català. Usualment es diu usuari@màquina (usuari a la màquina tal), però no necessàriament el nom de domini correspon al nom de màquina. És més correcte dir usuari@domini.

Per exemple, [email protected] indica el compte de correu d’en Pere en la màquina gmail.com, però de fet no hi ha cap màquina que es digui així, sinó que és el compte de correu d’en Pere en el domini gmail.com. En realitat, el Gmail té multitud de màquines que responen a aquest domini.


la llista. Fixeu-vos que si la llista conté usuaris d’altres dominis de cor-

reu (on sigui del món) farà arribar una còpia a aquests usuaris.

El model funcional del protocol SMTP que mostra els elements que inter-

venen en una comunicació d’aquest tipus es pot veure en la figura 9.

Figura 9. Model funcional del protocol SMTP

Per tant, vist en conjunt, un MUA (thunderbird per exemple) serveix a

l’usuari per crear un correu electrònic, i el MUA lliura el missatge a l'MTA del

sistema (per exemple, sendmail) perquè el faci arribar al destinatari final.

Usant l'SMTP, l'MTA s’encarrega de fer el lliurament en el sistema final (pot

ser amb una connexió directa o mitjançant diversos MTA) i el missatge es di-

posita en la bústia de correu del receptor. El receptor, quan ho considera

oportú, retroba els missatges de la bústia utilitzant un MUA i un mecanisme

d’accés adequat (per exemple, thunderbird i el protocol POP o IMAP).

3.1.1. El format dels missatges (RFC 822)

El protocol SMTP s’encarrega del transport de missatges de correu amb

independència del format i del contingut. Els missatges es componen de

diferents elements que es descriuen entre l’especificació SMTP (corres-

ponent al document RFC 821) i l'especificació pròpia dels missatges d’In-

ternet (document RFC 822).

Podem desglossar el missatge en els elements següents:

• Sobre o envelop. Com passa en el correu postal, per fer arribar un mis-

satge cal un sobre on s’indiqui el destinatari i el remitent. L’especifica-

ció d'SMTP (document RFC 821) descriu, com a sobre, el conjunt de

Correu web

El correu web té un funcionament similar al correu electrònic. Un usuari del Gmail utilitza com a MUA el web de Gmail per enviar un missatge a un usuari de Yahoo. El Gmail transfereix el missatge per SMTP al servidor de correu de Yahoo i el missatge es diposita en la bústia del destinatari. Aquest, quan li sembla, consulta el correu utilitzant la pàgina web de Yahoo com a MUA.

Exemples de programes que implementen SMTP: Sendmail, Exim, Postfix, MS Echange Server, etc.

Els camps FROM i RCPT del sobre no porten dos punts (:), i si que en porten les capçaleres FROM i RCPT del contingut.


dades necessàries per al transport del missatge (emissor, receptor, prio-

ritat, nivell de seguretat, etc.). Generalment, el sobre consta única-

ment del camp FROM (emissor) i el camp RCPT (receptor). L'MTA

utilitza el sobre per encaminar el missatge. De fet, la separació entre

sobre i contingut és confusa i l'MTA obté les dades del sobre a partir de

les capçaleres del contingut.

• Contingut. El contingut d’un missatge és el que està descrit en el docu-

ment RFC 822 “Format d’un missatge”. Tot contingut consta d’un conjunt

de capçaleres o headers, una línia en blanc i un cos o body del missatge:

– Capçaleres o headers. El contingut del missatge conté capçaleres del

tipus clau: valor cada una en una línia independent.

– Línia en blanc. Les capçaleres se separen del cos del missatge amb

una línia en blanc.

– Cos del missatge. El cos del missatge conté el missatge que es vol fer

arribar al receptor. L’especificació inicial només permet text ASCII

de 7 bits (sense símbols internacionals). El cos del missatge s’acaba

amb una línia que conté a l’inici únicament un punt.

Les capçaleres descrites en l’especificació inicial tenen per objectiu poder

descriure clarament l'emissor i el receptor o receptors del missatge, i la

data, i permetre identificar el missatge entre altres. En l'exemple següent

es poden veure els elements que formen el contingut i les capçaleres

usuals d’un correu electrònic.

Aquestes són algunes de les capçaleres estàndard:

• From. Indica l’adreça de correu de l'emissor del missatge.

• Sender. Adreça de qui ha enviat el missatge. No s’utilitza si qui ha en-

viat el missatge és el mateix que el From. Serveix per diferenciar entre

qui envia el missatge físicament i en nom de qui ho fa.

Són exemples de capçaleres From:, To:, Date:, Subject:, etc.

Received: by 10.100.195.12 with HTTP; Sun, 11 May 2008 10:11:38 -0700 (PDT)Message-ID: <[email protected]>Date: Sun, 11 May 2008 19:11:38 +0200From: "Pere Puig" <[email protected]>To: [email protected]: =?ISO-8859-1?Q?Exemple_de_missatge_de_correu_amb_capçaleresDelivered-To:[email protected]

Hola,Això és un exemple de missatge de correuconté les capçaleres usuals.S’ha generat des de la web de gmail i s’envia també a gmail.

Pere


• To i Cc. Els camps To i Cc serveixen per indicar els destinataris del mis-

satge. La idea original és posar un destinatari en el To i la resta en el

Cc, però amb la utilització dels MUA actuals i la utilització de llistes

d’usuaris, generalment, es posen tots els destinataris en el To.

• Bcc. Prové de blind carbon copy o còpia oculta. S’indiquen els destina-

taris que han de rebre el missatge però que no han d’aparèixer en la

llista de destinataris. És per evitar que els altres destinataris sàpiguen

qui n’ha rebut una còpia.

• Reply-to. Indica l’adreça de retorn del missatge al remitent. L’emissor pot

voler que, si el missatge es retorna o es respon, l’adreça a la qual es dirigeix

la resposta sigui diferent de la indicada en el From. És útil per concentrar

les respostes en un compte de correu quan l’emissor en té més d’un.

• Received. Cada MTA que processa un missatge afegeix una entrada de

tipus received en el missatge. És una manera de realitzar el seguiment

o traçabilitat dels MTA pels quals ha passat el missatge. La informació

afegida descriu l’emissor (from) i el receptor (by), el mecanisme físic

(via), l’identificador del missatge (id) i la data i hora (date).

• Date. Indica la data i hora en què s’ha generat el missatge. Hi afegeix

el primer MTA que rep el missatge del MUA.

• Message-ID. Identificador únic del missatge. Cada missatge s’ha de po-

der referenciar de manera única en tot el món. Això permet que les res-

postes indiquin a quin missatge es refereixen. S’utilitzen els noms de

domini i un identificador numèric únic que genera l'MTA que rep el

missatge per enviar.

• Subject. Descriu el propòsit del missatge o assumpte. És un petit text

explicatiu.

• In-reply-to. Quan un missatge és una resposta a un missatge anterior,

aquest camp indica a quin missatge original es fa referència.

• Keywords. Llista separada per comes de paraules clau descriptives del

missatge.

• Comments. Text de comentari del missatge que no interfereix en el

contingut.

• References. Quan un missatge fa referència a altres missatges ante-

riors, es poden indicar mitjançant aquesta capçalera.

• Encrypted. Indica el tipus de xifratge que s’ha utilitzat per xifrar el mis-

satge. L’especificació del format dels missatges de correu (descrita en


el document RFC 822) no indica cap tipus de xifratge, simplement re-

serva una capçalera per indicar-ne el tipus.

• Return-path. Identifica el camí de retorn cap a l’origen. Aquesta infor-

mació l’ha de posar l'MTA receptor i actualment està en desús, de ma-

nera que normalment conté l’adreça de l'emissor.

• X-<userDefinied>. Els usuaris poden crear les pròpies capçaleres amb

el nom que vulguin però començant per X-. D’aquesta manera s’asse-

gura que si apareixen noves capçaleres oficials en el futur, no xocaran

amb capçaleres definides pels usuaris (ja que aquestes han de comen-

çar totes per X-).

3.1.2. Funcionament del protocol SMTP

El funcionament del protocol SMTP imita el correu postal en molts aspec-

tes. L'SMTP és un protocol d’emmagatzemament i enviament igual que

les cartes, que es lliuren a una oficina postal, d’allà a una altra i així fins a

arribar al destinatari final. De fet, les cartes es lliuren a la bústia del des-

tinatari final i és aquest el que les ha de recollir.

En l’esquema original en què es va desenvolupar l'SMTP, una organitza-

ció disposa d’un servidor SMTP (un MTA) que rep correu electrònic de

fora de l’organització i el diposita en les bústies de correu locals del ser-

vidor. També recull el correu intern de l’organització i el canalitza per

enviar-lo fora.

Cada organització disposa d’una o més màquines encarregades de gestio-

nar el correu. Així, quan s’envia un correu electrònic a l’usuari pere@fp-

oberta.cat, cal que l’organització o domini fp-oberta.cat disposi de màqui-

nes que fan la funció de servidors de correu. ¿Com trobarà l'SMTP a quin

servidor de correu ha de lliurar els correus electrònics destinats a un do-

mini? Utilitzant el protocol DNS (domain name system, sistema de noms

de domini) obtindrà la màquina o màquines que fan la funció de servidors

de correu del domini.

El client SMTP o emissor estableix una connexió TCP amb el port 25 del

servidor SMTP o receptor. En una mateixa connexió l'emissor pot enviar

un o més missatges al receptor. Si el mateix missatge va destinat a diver-

sos receptors del sistema final, el missatge s’envia un sol cop i l'MTA re-

ceptor ja l’expandirà per a cada destinatari.

El servidor SMTP és una aplicació distribuïda que permet enviar mis-

satges electrònics. Utilitza el protocol de transport TCP i el port 25.

Push

Es diu que l'SMTP és un protocol que fa push (lliurament) però no pull (agafar). Els usuaris finals han d’usar altres mecanismes per accedir remotament als seus comptes de correu.

MX

En la base de dades d’un servidor DNS, els equips que fan de servidors de correu d’un domini s’identifiquen per les entrades tipus MX. Si un domini no disposa d’entrades MX s’utilitza el host que defineix el domini.


El client SMTP o emissor disposa d’una cua de missatges per enviar i una

llista de destinataris per a cada missatge. Els destinataris poden ser en

destinacions diferents (evidentment) i, per tant, li caldrà connectar-se als

diferents servidors de destinació per tal de fer-los arribar els missatges.

Quan un destinatari no és accessible, el missatge es pot tornar a posar en

la cua de missatges pendents d’enviar o es pot descartar (segurament des-

prés de diferents intents infructuosos) tot intentant notificar l'emissor.

Avui en dia el servidor de correu pot ser a qualsevol lloc del món i no cal

que cada organització en tingui d’un. Es pot utilitzar el del proveïdor ISP

o el de qualsevol servei extern de correu (per exemple, Google ofereix el

servei d’externalitzar el correu a empreses tot mantenint el domini propi

de l’empresa). Això significa que el servidor SMTP ha de verificar si accep-

ta o no peticions d’enviar correu d’un client. Es pot verificar el client mit-

jançant l'IP o mitjançant altres mecanismes d’autenticació i seguretat.

Evidentment, disposar d’un servidor SMTP que accepta peticions de

clients sense verificar qui són és una porta oberta a permetre correu brossa.

Normalment els servidors SMTP restringeixen qui pot fer ús del servei

(quins clients) i a quines destinacions.

Un cop un servidor SMTP accepta un correu electrònic per fer-ne el lliu-

rament (d’un MUA com el thunderbird per exemple) tot validant que ac-

cepta rebre correus electrònics d’aquest client, estableix una connexió

TCP al port 25 del servidor SMTP destinatari (ha obtingut l’adreça IP fent

la resolució DNS de la part del domini de l’adreça de correu).

3.1.3. Ordres/respostes SMTP

L'emissor sempre porta el control de la comunicació i inicia la connexió

amb el receptor. El diàleg consisteix en un intercanvi d’ordres i respostes

que segueixen les especificacions de Telnet:

• Ordres. Les ordres són codis de quatre caràcters i arguments opcionals

separats per espais i acabats amb <CRLF> (HELO, MAIL, DATA, etc.).

Per a cada ordre es rep una resposta del receptor.

• Respostes. Les respostes són codis numèrics de tres dígits, un espai i

un missatge descriptiu que pot variar segons la implementació.

Un diàleg bàsic entre emissor i receptor SMTP seria el següent:

• HELO domini / EHLO domini. Un cop connectat, l'emissor s'ha d’iden-

tificar amb l’ordre HELO i indicar el domini al qual es connecta. Actual-

ment els servidors SMTP utilitzen extensions i l’ordre preferida per

identificar-se és EHLO.

Llistes negres de servidors de correu

Els servidors de correu que accepten tot tipus de correus electrònics de tots els clients a totes les destinacions es posen en llistes negres perquè poden ser generadors de correu brossa.

Correu brossa o spam

S'anomena correu brossa el correu no desitjat o no sol·licitat. És un correu que es rep insistentment i que bombardeja les bústies dels usuaris de manera mecànica.


• MAIL FROM: <emissor>. Identifica l'emissor del missatge i genera la

capçalera FROM del missatge. El receptor valida que l'emissor sigui un

usuari vàlid, és a dir, que accepti missatges d’aquest origen. Si no el va-

lida envia una resposta denegant-ho. Els equips amb el relay configu-

rat per permetre enviar missatges de tothom són els principals

generadors de correu brossa.

• RCPT TO <destinatari>. Indica el destinatari del missatge. Aquesta

ordre es pot repetir tantes vegades com destinataris tingui el missatge.

També cal que el receptor accepti el destinatari, que pot ser un desti-

natari local, o que accepti fer el reenviament si és un destinatari remot.

Aquesta ordre genera la capçalera TO en el missatge.

• DATA. Indica que a continuació s’enviarà el missatge. Tot el que es

transmet a continuació és el contingut del missatge, que finalitzarà en

trobar una línia que només inclou un punt (.<CRLF>). El contingut se-

gueix les especificacions del document RFC 822, per tant, pot contenir

capçaleres a l’inici, una línia en blanc a manera de separador i el cos.

No es pot enviar un missatge (l’ordre DATA) fins que el receptor no ha

confirmat que accepta almenys un destinatari. Això evita transmetre

missatges que es descartarien en la destinació.

• QUIT. L’emissor envia l’ordre per indicar al receptor que vol finalitzar

la comunicació. El receptor confirma la recepció i llavors tots dos po-

den finalitzar la transmissió.

En l'exemple següent podeu veure un diàleg client/servidor SMTP mitjan-

çant ordres i respostes Telnet.

[root@portatil ~]# telnet www.escola.org 25 Trying 22.170.21.168... Connected to www.escola.org. Escape character is ‘^]’. 220 escola.org ESMTP Sendmail 8.13.8/8.13.8; Sat, 26 Apr 2008 19:56:05 +0200 EHLO escola.org 250-escola.org Hello 106.Red-71-92-14.dynamicIP.rima-tde.net 71.92.14.106], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 10000000 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN 250-DELIVERBY 250 HELP

MAIL FROM: [email protected] 250 2.1.0 [email protected]... Sender ok RCPT TO: [email protected] 250 2.1.5 [email protected]... Recipient ok


Amb els camps MAIL FROM i RCPT TO, el protocol SMTP obté les dades

necessàries per generar el sobre o envelop.

A part de les ordres bàsiques mostrades anteriorment hi ha més ordres en

el protocol SMTP, com ara les següents:

• RSET. L'emissor pot interrompre l’enviament de missatges amb

aquesta ordre.

• NOOP. Aquesta ordre no fa res, però força el receptor a enviar una res-

posta afirmativa. És un mecanisme per confirmar que la connexió en-

cara és oberta.

• HELP. Fa una llista de les ordres que implementa el servidor. Els ser-

vidors SMTP no implementen necessàriament totes les ordres descri-

tes pel protocol.

• VRFY <destinatari>. L'emissor pot verificar l’existència del destina-

tari.

• EXPN <destinatari>. Permetrà a l'emissor verificar l’existència d’una

llista de correu i obtenir-ne la llista dels membres.

• SEND, SOML, SAML. Aquestes ordres permeten enviar els missatges

tant a les bústies de correu com als terminals.

• TURN. Permet intercanviar els papers entre emissor i receptor. El re-

ceptor hi ha d’estar d’acord.

Els servidors SMTP no implementen necessàriament totes les ordres, hi

ha un conjunt d’ordres mínim definit pel protocol que tot servidor SMTP

ha d’implementar.

DATA 354 Enter mail, end with "." on a line by itself hola, aquest és un missatge de prova per enviar un email usant telnet al servidor smtp de l’escola. s’envia una copia a dos usuaris locals al servidor. S’ha denegat fer relaying i enviar una còpia a l’exterior pere . 250 2.0.0 m3QHu5B3012660 Message accepted for delivery

QUIT221 2.0.0 escola.org closing connection Connection closed by foreign host.

El conjunt d’ordres mínim que ha d’implementar un servidor SMTP

ha de ser el següent:

HELO <domini> MAIL FROM: <emissor>

RCPT TO: <destinatari> DATA

RSET NOOP

QUIT

Ordres SMTP

Per obtenir la llista d’ordres del protocol podeu consultar el document RFC 2821. Atès un servidor concret, podeu consultar les ordres que implementa amb l’ordre HELP.


El protocol SMTP permet treballar amb missatges ASCCI de 8 bits i amb

extensions del protocol, és a dir, afegir als servidors SMTP funcionalitats

extres segons el programari de servidor utilitzat. El client pot sol·licitar al

receptor la llista de les extensions que implementa i fer-li saber que les vol

utilitzar. El mecanisme és que el client enviï un EHLO <domini> en lloc

de l'HELO estàndard. Si el receptor implementa extensions respondrà

afirmativament i en farà una llista, si no les implementa respondrà nega-

tivament. Llavors l’emissor pot fer un HELO estàndard.

Les respostes es poden classificar en quatre grans grups. El primer dí-

git del codi numèric de tres dígits de la resposta indica al grup al qual

pertany:

1) Positiva (2). L’acció que ha sol·licitat l’emissor és acceptada pel recep-

tor. L'emissor pot fer una nova sol·licitud.

2) Intermèdia positiva (3). L’acció sol·licitada s’ha acceptat però està sus-

pesa pendent de rebre informació addicional que l'emissor haurà de pro-

porcionar.

3) Negativa transitòria (4). La sol·licitud no s’ha acceptat i l’acció no s’ha

realitzat, però es tracta d’un error temporal i es pot tornar a intentar més

tard. L'emissor pot tornar a fer la sol·licitud més endavant.

4) Negativa pertinent (5). L’ordre no s’ha realitzat i, per tant, la sol·licitud

no ha estat acceptada.

3.1.4. Els tipus MIME

Els missatges de correu segueixen el format definit en el document RFC

822 (actualment, RFC 2822), que únicament permet missatges de text net

ASCCI de 7 bits. No es permeten els caràcters accentuats, caràcters inter-

nacionals (ASCCI de 8 bits) i molt menys la transferència de dades binà-

ries com imatges, àudio, aplicacions, PDF, etc. Però tot això i més s’envia

avui en dia per correu electrònic, com?

El juny del 1992 es va definir el que es coneix com a MIME (multipurpose

Internet mail extension o extensió de correu d’Internet per a ús múltiple)

en l'RFC 1341, i que actualment ha evolucionat en els RFC 2045 i RFC

2049. El MIME utilitza missatges RFC 822 però afegint una estructura al

cos del missatge i regles de codificació per a missatges no ASCII. El gran

avantatge del MIME és que permet seguir utilitzant les mateixes eines

d'SMTP que fins ara, només cal modificar els MUA perquè apliquin MI-

ME. A l'MTA el cos del missatge li és absolutament indiferent (i, per tant,

pot estar codificat), només utilitza el sobre.


El MIME es basa en tres elements per permetre qualsevol tipus de con-

tingut en un missatge de correu:

• Capçaleres MIME. Es creen cinc noves capçaleres de correu per defi-

nir informació del cos del missatge. No totes són obligatòries.

• Formats de contingut. Es defineixen diferents formats de contingut

que permeten als MUA receptors interpretar el contingut de manera

adequada, i saber si reben un full de càlcul, un vídeo, etc.

• Esquemes de codificació de transferència. Es realitza una transforma-

ció de les dades a un format manipulable per al transport SMTP (que

només permet caràcters ASCII de 7 bits).

Podeu veure els components d’un missatge amb contingut MIME en

l'exemple següent.

From [email protected] Fri Jun 13 17:26:31 2008 Return-Path: <[email protected]> Received: from tftp.server.cat (localhost [127.0.0.1]) by tftp.server.cat (8.14.1/8.14.1) with ESMTP id m5DFQTH7003922 for <[email protected]>; Fri, 13 Jun 2008 17:26:30 +0200 Received: (from root@localhost) by tftp.server.cat (8.14.1/8.14.1/Submit) id m5DFQSIq003918 for [email protected]; Fri, 13 Jun 2008 17:26:28 +0200 Date: Fri, 13 Jun 2008 17:26:27 +0200 From: root <[email protected]> To: [email protected] Subject: missatge amb atchment Message-ID: <[email protected]> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Status: O

--zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline

misatge de root a l’usuari pere conte adjunt un pdf i jpeg adeu!

--zYM0uCDKw75PZbzx Content-Type: application/pdf Content-Disposition: attachment; filename="informatica_AX_ud2.pdf" Content-Transfer-Encoding: base64 ... output suprimit (contingut del pdf codificat en base64) ...--zYM0uCDKw75PZbzx Content-Type: image/jpeg Content-Disposition: attachment; filename="cd15_11_puerto-madrin.jpg" Content-Transfer-Encoding: base64 ... output suprimit (contingut del jpeg codificat en base64) ...--zYM0uCDKw75PZbzx--


Capçaleres MIME

Les cinc capçaleres que defineix l’especificació MIME aporten informació

del contingut del missatge. Aquestes capçaleres són les següents:

• MIME-version. Identifica el tipus MIME del missatge. Si indica 1.0 es

tracta d’un missatge MIME, si no, es tracta d’un missatge ASCII.

• Content-description. És un text que descriu el tipus de contingut. No

és obligatori i no té cap funcionalitat més que la merament descriptiva.

• Content-ID. Identifica el contingut de manera única igual que ho fa el

camp Message-ID.

• Content-transfer-encoding. Mecanisme de codificació utilitzat en el

missatge per poder-lo transmetre. El contingut que no és ASCII de 7

bits es codifica per poder ser transmès.

• Content-type. Descriu el tipus de contingut segons la taula de MIME ty-

pes. Això permet a un MUA obrir l’aplicació pertinent per gestionar el con-

tingut. Si, per exemple, el tipus és image/jpeg permet al MUA saber que

en pot manipular el contingut amb una aplicació de gestió d’imatges.

Tipus MIME

Es defineix un conjunt de tipus i subtipus MIME amb un esquema tipus/

subtipus. Originàriament es van definir els set tipus que es descriuen a

continuació, però en l’actualitat hi ha multitud de tipus/subtipus MIME:

• text/native. Text net en format ASCII de 7 bits.

• multipart/<subtipus>. El missatge conté múltiples parts indepen-

dents. Un delimitador (o boundary) indica la separació de cada part.

El delimitador és únic i no a apareix en el cos de les parts. El delimita-

dor es troba a l’inici i al final de cada part i comença amb dos guions.

L’última part acaba amb un delimitador que comença amb dos guions

i acaba amb dos guions. Cada part pot ser qualsevol cosa!

• multipart/mixed. Múltiples parts, en ordre. És a dir, les parts s’han de

mostrar en el receptor en l’ordre indicat.

• multipart/parallel. Múltiples parts. No es defineix cap ordre.

• multipart/alternative. Les parts són versions alternatives del mateix

contingut en ordre creixent de fidelitat. El receptor escull la més apro-

piada. Per exemple, un text s’envia com a text net en una primera part


i com a PDF en una segona; si el receptor no disposa de PDF podrà usar

la part en text net.

• multipart/digest. Cada part és un missatge de correu individual. S'uti-

litza quan un correu electrònic conté diferents correus electrònics en a

l'interior (per exemple, reenviaments).

• message/rfc822. El cos és un missatge de correu complet, amb capçale-

res i cos. Pot ser un missatge MIME tot i que el nom digui rfc822.

• message/partial. Permet fragmentar un missatge llarg en diferents

missatges. Cada fragment ha de disposar d’un identificador, número

de fragment i nombre total de fragments.

• message/external body. Les dades del cos del missatge no estan en el

missatge sinó que cal baixar-les a part. En la capçalera Content-Type es

descriu el tipus de contingut i el tipus d’accés, que pot ser FTP, TFTP,

anon-FTP (FTP anònim), local-file, AFI i mail-server. Per exemple, el

contingut pot ser una imatge no inclosa en el missatge sinó que cal bai-

xar d’un servidor FTP.

• image/jpeg. Imatge codificada JPEG.

• image/gif. Imatge GIF.

• video/mpeg. Vídeo en format MPEG (moving picture experts group,

grup d’experts d’imatges en moviment).

• audio/basic. Àudio en format estàndard.

• application/postscript. Dades binàries en format PostScript, per exem-

ple, PDF.

• application/octet-stream. Dades binàries.

Codificació de transferència

Les dades binàries i els caràcters internacionals (que no pertanyen al con-

junt ASCII de 7 bits) no es poden enviar per correu electrònic. Per poder-

ho fer cal codificar-los en un altre format. L’especificació MIME defineix

els tipus de codificacions següents:

• 7bit. Indica que les dades es transfereixen en ASCII de 7 bits. No es

realitza cap codificació.

• 8bit. No es realitza cap codificació i les dades es transmeten en ASCII

de 8 bits. Evidentment, cal que receptor i emissor permetin la transfe-

rència a 8 bits (una extensió d'SMTP).


• Binary. Es transmeten les dades en binari tal com són, sense cap codi-

ficació ni control de la longitud de les línies. Si s’envien dades en binari

(en cru) no es garanteix que la transmissió sigui correcta.

• X-token. Indica la utilització d’un esquema de codificació de transport

no estàndard, un esquema propi. Emissor i receptor han de compartir

aquest esquema de codificació.

• Quoted-printable. Quan la majoria de caràcters del missatge són impri-

mibles excepte uns pocs, és més eficient utilitzar aquesta codificació

que base64. Aquest esquema codifica els caràcters no imprimibles amb

un igual i el codi hexadecimal del caràcter. Es garanteix que les línies

tenen una longitud no superior a setanta-sis caràcters mitjançant salts

de línia reversibles.

• Base64. És l’esquema de codificació més usat per a la transferència

d’informació binària. Converteix l’entrada en un conjunt de caràcters

imprimibles i, per tant, immunes al transport per SMTP. Consta d’un

conjunt de seixanta-quatre caràcters imprimibles i un més de farci-

ment (2 ^ 6 = 65 caràcters). Cada 24 bits de l’entrada binària (3 bytes)

es codifica en quatre blocs de 6 bits. A cada bloc de 6 bits correspon un

caràcter imprimible que es posa en 1 byte. Per tant, per cada 24 bits

d’entrada binària, s’utilitzen 32 bits de transmissió.

3.2. El servei POP

En el model de transport de correu SMTP s’exigeix que el receptor disposi

de connexió permanent a Internet. Està pensat per a correu entre organit-

zacions connectades a Internet i que disposen d’un servidor de correu que

conté les bústies dels usuaris locals de l’organització. Això obliga l’usuari

a treballar localment en el servidor per accedir a les seves bústies. Però,

en popularitzar-se Internet, sorgeix el problema dels usuaris que hi acce-

deixen per ISP i que no tenen connexió permanent (per exemple, amb mò-

dem). Com poden disposar del servei de correu?

S’idea un mecanisme per a accés remot als comptes de correu, de manera

que l’usuari es connecta quan vol (no permanent), accedeix a la bústia de cor-

reu per recuperar els missatges i finalitza la connexió. POP3 i IMAP són pro-

tocols que permeten l’accés remot de clients a les bústies de correu.

POP3 (post office protocol o protocol d’accés simple a les bústies decorreu) és un protocol de capa d’aplicació de la pila de protocols

TCP/IP (port 110) definit en l'RFC 1939. Permet a un client de cor-

reu (MUA) obtenir remotament el correu dipositat en la bústia de

correu de l’usuari en un servidor de correu POP3.

POP3 és la versió actual del protocol POP. Usarem tots dos noms indistintament.

POP3, similar al correu postal

El POP3 és un mecanisme similar al correu postal. El carter deixa les cartes a la nostra bústia i les recollim quan ens sembla.


Normalment, l’usuari utilitza una aplicació client de POP3 (per exemple,

Thunderbird) i baixa el correu del servidor POP. Els missatges que es bai-

xen es desen en la màquina de l’usuari (localment) i s’esborren del servi-

dor (es pot configurar si s’esborren o no). Finalment es tanca la connexió.

3.2.1. El model POP3

El POP3 és un protocol que permet l’accés remot a les bústies de correu

dels usuaris, com també ho és l'IMAP. Ni el POP3 ni l'IMAP transporten el

correu, aquesta funció la fa el protocol SMTP. Podeu veure el model fun-

cional del protocol POP en la figura 10, en què un usuari amb el seu MUA

baixa el correu del servidor mitjançant POP o IMAP.

Figura 10. Model funcional del protocol SMTP

Com la majoria de serveis de xarxa a Internet, el protocol POP3 s’estruc-

tura seguint l’esquema client/servidor. Aquests són els agents que interve-

nen en una comunicació POP3:

• MUA (mail user agent o agent d’usuari de correu). L’usuari interactua

amb un agent d’usuari per accedir al correu mitjançant POP3. Són agents

d’usuari programes com Thunderbird, Getmail, Ftchmail, MS Outlook Ex-

press, Eudora, Gmail, etc. Com es pot veure en la llista, les aplicacions

MUA poden ser de text, gràfiques i, fins i tot, pel web. Aquestes aplicacions

incorporen el programari necessari per actuar de clients POP3.

• Client POP3. La part pròpiament encarregada de comunicar amb el

servidor POP3 per obtenir els missatges de la bústia de correu de l’usuari

és el client POP3. Client i servidor POP3 parlen un llenguatge comú

que és el protocol POP3.

Fragmentació del correu

Si l’usuari baixa correu POP des de màquines diferents, el correu li queda fragmentat, desat localment en cada màquina el que s’hi ha baixat.

Accés POP3 al correu web

Molts correus web o webmails permeten baixar correu d’altres web usant el protocol POP3 o IMAP. Per exemple, des del Gmail es poden baixar missatges de Yahoo.


• Servidor POP3. Per poder implementar l’accés remot al correu cal dis-

posar d’un servidor POP3 en funcionament. Aquest servidor POP3 conté

les bústies dels usuaris o hi accedeix. Els missatges es reben mitjançant

SMTP, i és un MTA o un MDA qui els diposita en la bústia. El servidor

POP3 atén les peticions dels clients POP3 per baixar el correu.

Un concepte que ajuda a diferenciar el funcionament de POP3 i IMAP és

que en l’esquema de POP3 es considera que l’emmagatzematge del correu

es realitza en l’usuari. El servidor acumula els missatges nous i aquests

baixen tots a l’usuari i s’eliminen del servidor. Per tant, és responsabilitat

de l’usuari com els gestiona. Si bé és cert que els missatges es poden desar

en el servidor (sense esborrar), no hi ha eines per gestionar-los, tots estan

en una mateixa carpeta o folder. El servidor POP3 ofereix poques funcio-

nalitats: baixar missatges, baixar les capçaleres i esborrar els missatges.

Una sessió POP3 passa per tres estats clarament diferenciats:

1) Autorització. Un cop feta la connexió TCP/IP pel port 110 entre el

client i el servidor POP3, s’entra en l’estat d’autorització. Cal que el client

s’identifiqui davant del servidor POP3 indicant el compte d’usuari i la

contrasenya.

2) Transacció. Un cop el client ha estat autoritzat pel servidor, s’entra en

l’estat de transacció. En aquest estat el client demana accions (ordres) al

servidor i aquest les atén. És a dir, en aquest estat el client es baixa el cor-

reu, marca missatges per esborrar, demana les capçaleres dels missatges,

en fa una llista per ordre, etc. El client finalitza l’estat de transacció utilit-

zant l’ordre quit.

3) Actualització. El servidor entra en l’estat d’actualització en rebre l’or-

dre quit del client. Elimina els missatges marcats per esborrar (fins ara no

s’havien eliminat) i envia un ok al receptor. Ara tots dos ja poden finalitzar

la comunicació.

3.2.2. Funcionament del POP3

El funcionament generalitzat del protocol POP3 és que el client fa una

connexió TCP/IP al port 110 del servidor, es baixa el correu i tanca la con-

nexió. En aquest procés, client i servidor passen per tres estats (autoritza-

ció, transacció i actualització) i s’intercanvien ordres i respostes seguint el

model de diàleg de Telnet:

• Ordres. Les ordres POP3 són ordres de text de quatre caràcters se-

guides d’espais i els arguments que requereixin. Finalitzen amb un

<crlf>.


• Respostes. Les respostes POP3 són una cadena de caràcters que co-

mença per +OK o -ERR més una descripció. Les respostes afirmatives

comencen per +OK, i les d’error per -ERR.

Tot seguit es mostra una llista de les ordres utilitzables en el protocol

POP3 agrupades segons l’estat:

1) Autorització

• USER nomUsuari. El client s’identifica davant del servidor POP indi-

cant el nom d’usuari, que ha de correspondre a una bústia de correu del

servidor POP.

• PASS password. El client s’ha d’autenticar indicant un nom d’usuari i

una contrasenya vàlids. L’ordre pass permet indicar aquesta contrase-

nya en text net.

• APOP nomUsuari password-md5. Per proporcionar més seguretat en

el procés d’autorització, l’usuari pot fer servir l’ordre APOP que té com

a arguments el nom d’usuari i la contrasenya encriptada usant una fun-

ció resum o hash com, per exemple, MD5.

2) Transacció

• STAT. Amb aquesta ordre l’usuari demana l’estat de la seva bústia. El

servidor retorna el nombre de missatges que conté i el total de bytes

que ocupa.

• LIST [msg]. Llista els missatges o un missatge concret. No llista el con-

tingut sinó que llista per a cada missatge el seu número de missatge i

el nombre de bytes que ocupa.

• RETR msg. Baixa un missatge concret del servidor al client. Els missat-

ges es poden indicar pel número de missatge.

• DELE msg. Marca el missatge indicat per ser esborrat. No s’esborra

immediatament, només es marca, l’esborrament es produeix en l’estat

final d’actualització. En els MUA que actuen de clients POP, és típic

permetre configurar si es deixen els missatges en el servidor o s’elimi-

nen. Usualment s’eliminen perquè només hi quedin els nous.

• NOOP. Aquesta ordre no fa res, però força el servidor a emetre una res-

posta positiva. Serveix per comprovar que la connexió encara és oberta.

• RSET. Si es realitza aquesta ordre abans de passar a l’estat d’actualit-

zació, RSET desmarca tots els missatges que estaven marcats per es-

borrar.

Baixar missatges del servidor POP3

Alguns MUA bàsics baixen tots els missatges del servidor de cop. Si en el servidor es deixen els missatges ja llegits, es tornen a baixar cada cop.


• TOP msg nLin. En lloc de baixar tot un missatge sencer com fa l’ordre RE-

TR, l’ordre TOP permet baixar les línies inicials d’un missatge. Baixa les

capçaleres i les nLin línies inicials. Aquesta ordre és útil per baixar només

les capçaleres (remitents, assumptes, etc.) i per filtrar els missatges a bai-

xar i marcar-los per esborrar ja directament sense baixar-los.

• UIDL [msg]. Els missatges s’identifiquen dins de la línia pel seu núme-

ro d’ordre (com fa l’ordre LIST), però el número d’ordre d’un missatge

pot variar entre connexions si s’esborren els precedents. Per tal de po-

der identificar de manera única un missatge independentment de la

posició que ocupa, es pot usar el UID. El UID és únic per a cada missat-

ge en una bústia. L’ordre UIDL llista tots els uids i el seu número d’or-

dre o només el d’un missatge en concret.

• QUIT. L’ordre quit indica al servidor que el client vol finalitzar la con-

nexió. El servidor passa de l’estat de transacció al d’actualització.

3) Actualització

En aquest estat no hi ha ordres. El servidor elimina els missatges marcats per

esborrar, emet una resposta positiva al client, i tots dos tanquen la connexió.

L'exemple següent correspon a un diàleg mitjançant Telnet entre client i

servidor usant el protocol POP, on es poden veure les ordres i respostes

del protocol.

[root@portatil ~]# telnet localhost 110 Trying 127.0.0.1... Connected to localhost. Escape character is ‘^]’. +OK POP3 localhost 2007a.104 server ready USER pere +OK User name accepted, password please PASS pere +OK Mailbox open, 1 messages

STAT +OK 1 480 NOOP +OK No-op to you too! LIST +OK Mailbox scan listing follows 1 480 . RETR 1 +OK 480 octets Return-Path: <[email protected]> Received: from tftp.server.cat (localhost [127.0.0.1]) by tftp.server.cat (8.14.1/8.14.1) with ESMTP id m5DI4ig8005681 for [email protected]; Fri, 13 Jun 2008 20:06:12 +0200 Date: Fri, 13 Jun 2008 20:04:44 +0200 From: root <[email protected]> Message-Id: <[email protected]> Status:


Hi ha diverses implementacions de servidors POP i cada una implementa

un conjunt d’ordres i extensions pròpies. L’especificació POP3 requereix

que s’implementin almenys les ordres següents: STAT, LIST, RETR, DE-

LE, NOOP, REST.

3.3. El servei IMAP

IMAP (Internet message access protocol o protocol d’accés a missatges

d’Internet) és un protocol de capa d’aplicació del model TCP/IP que pro-

porciona a l’usuari accés remot a la seva bústia de correu. L'IMAP sorgeix

com a resposta al problema d’accedir al correu des de diferents ordinadors

utilitzant POP.

El POP és un protocol pensat per baixar el correu del servidor al PC lo-

cal de l’usuari i poder-lo manipular després sense connexió a Internet.

Usant POP es considera que el correu resideix en l’equip de l’usuari,

que baixa tot el correu de cop cada vegada que es connecta al servidor

de correu. Quan els usuaris es van acostumar a consultar el correu re-

motament, ho van començar a fer des d’equips diferents: a casa, a la

feina, de vacances, etc. Cada cop que ho feien deixaven part del seu cor-

reu en llocs diferents. El que s’ha baixat a casa no es pot consultar a la

feina, etc. Un cop els usuaris es van acostumar a disposar de connexió

d’Internet més assíduament, calia un mecanisme més evolucionat d’ac-

cés remot al correu.

L'IMAP fa un enfocament diferent, els missatges de correu es dipositen en

el servidor, i és en el servidor on s’emmagatzemen estructurats en carpe-

tes (o folders o mailbox) i on es manipulen. L’usuari els pot baixar local-

ment, però com a còpia temporal. Per tant, tota la gestió dels missatges de

correu té lloc en el servidor. Això fa de l'IMAP un protocol més complex

que el POP.

aquest es un email qualsevol el text s’escriu fins acabar amb una linia que només conté un punt .

QUIT +OK Sayonara Connection closed by foreign host.

L'IMAP és un protocol de capa d’aplicació de la pila de protocols

TCP/IP (port 143) definit en el document RFC 1064. Permet a un cli-

ent de correu (MUA) obtenir remotament el correu dipositat en la

bústia de correu de l’usuari en un servidor de correu IMAP.

Ni l'IMAP ni el POP són protocols de transmissió de correu. Usualment és el protocol SMTP qui fa aquesta funció.

Per obtenir més informació sobre l’especificació del protocol IMAP en els RFC 1064 i 3501, aneu a la secció “Adreces d’interès” del web d’aquest crèdit.

!!


L'IMAP sorgeix al 1986 amb el nom d'interim mail acces protocol, que en

la versió següent es canvia per interactive mail access protocol (docu-

ment RFC 1064), que posteriorment es canviarà per Internet mail acces

protocol. L’evolució actual és IMAP versió 4 revisió 1 (març 2003) corres-

ponent al document RFC 3501 (del qual també s’han fet actualitzacions i

extensions) que s’ha creat sota els auspicis de l’IETF.

El protocol IMAP està pensat per tenir en el servidor tot el correu de l’usuari

organitzat en carpetes jeràrquiques de manera indefinida. Es permet

la manipulació remota de les carpetes i els missatges. Es poden crear, mo-

dificar i suprimir carpetes i missatges. Els missatges no s’esborren si no

ho indica explícitament l’usuari. A més a més, aporta la funcionalitat de

cerca i filtratge de missatges directament en el servidor. És a dir, no cal

baixar els missatges per buscar-ne els que compleixen unes condicions de-

terminades. Permet l’accés concurrent de diversos usuaris a la mateixa

bústia, i el servidor pot notificar l’arribada de correu nou. Els missatges

multipart es poden baixar parcialment, es poden buscar parts i baixar no-

més les que interessin. Tots els missatges i les bústies tenen indicadors

d’estat que descriuen, per exemple, si el missatge s’ha llegit, contestat, si

és nou, etc.

3.3.1. Model IMAP

Com la majoria de serveis de xarxa a Internet, el protocol IMAP s’estruc-

tura seguint l’esquema client/servidor. Aquests són els agents que interve-

nen en una comunicació IMAP:

• MUA (mail user agent o agent d’usuari de correu). L’usuari interactua

amb un agent d’usuari per accedir al correu mitjançant l'IMAP. Són

agents d’usuari programes com el Thunderbird, Getmail, Fetchmail,

MS Outlook Express, Eudora, Gmail, etc. Com es pot veure en la llista

de les aplicacions MUA, poden ser de text, gràfiques i, fins i tot, pel

web. Aquestes aplicacions incorporen el programari necessari per ac-

tuar com a clients IMAP.

• Client IMAP. La part pròpiament encarregada de comunicar amb el

servidor IMAP per obtenir els missatges de la bústia de correu de l’usuari

és el client IMAP. Client i servidor IMAP parlen un llenguatge comú

que és el protocol IMAP.

• Servidor IMAP. Per implementar l’accés remot al correu cal disposar

d’un servidor IMAP en funcionament. Aquest servidor IMAP conté les

bústies dels usuaris o hi accedeix. Els missatges es reben per SMTP i

és un MTA o un MDA qui els diposita en la bústia. El servidor IMAP

atén les peticions dels clients IMAP per gestionar el correu.

Difusió del servei IMAP

Avui en dia l'IMAP està molt estès, però no és estrany trobar servidors ISP i portals de correu web que permeten baixar el correu únicament mitjançant el POP.


Teniu el model funcional del protocol IMAP en la figura 11, on es veu que

un usuari mitjançant el seu MUA es baixa el correu del servidor amb el

POP o IMAP.

Figura 11. Model funcional del protocol IMAP

En el protocol IMAP es detallen quatre estats clarament diferenciats:

1) No autenticat. Quan s’estableix la connexió TCP/IP entre el client i el

servidor s’entra en aquest estat. El client s’ha d’autenticar davant del ser-

vidor, acreditant ser un usuari vàlid. Per fer-ho indicarà el nom d’usuari i

la contrasenya.

2) Autenticat. Un cop autenticat i abans de poder manipular missat-

ges, ha de seleccionar la carpeta (o bústia o folder o mailbox) amb la

qual operarà. En aquest estat pot manipular les carpetes (crear, esbor-

rar, modificar i veure l’estat) però no els missatges fins que no se n’ha

seleccionada una.

3) Seleccionat. Un cop s’ha seleccionat una carpeta amb èxit, s’entra en

aquest estat, que permet la manipulació dels continguts de la carpeta.

4) Logout. En aquest estat es procedeix a tancar la connexió. S'hi pot ar-

ribar tant per petició del client com per decisió unilateral del servidor.

El servidor IMAP emmagatzema permanentment tots els missatges de

l’usuari. Per fer-ho utilitza un sistema de carpetes (o bústies) jeràrquiques

i atributs que descriuen tant l’estat de les bústies com dels missatges:

• Carpetes (mailbox). Hi ha una bústia o mailbox que és la de l’usuari.

Dins d’aquesta bústia, s’hi poden crear carpetes que s’indiquen de ma-


nera relativa igual que amb els directoris d’una estructura de fitxers.

Les carpetes disposen almenys de dos atributs:

– Next UID (UID següent). Indica el valor UID que s’assignarà al mis-

satge següent que arribi.

– UID Validity Value (UIDVALIDITY). És un valor d’identificador

únic assignat a la carpeta seleccionada. La combinació de nom de car-

peta UIDVALIDITY i UID identifiquen de manera perpètua un mis-

satge en el servidor.

• Atributs de missatge. Els missatges tenen atributs que s’emmagatze-

men en les pròpies bústies que en faciliten la gestió:

– UID. Identificador únic del missatge. És un número de 32 bits que

s’assigna ascendentment a mesura que arriben missatges (no neces-

sàriament correlatiu). Això permet al servidor saber, en una bústia,

a partir de quin número de missatge hi ha els missatges nous (en

POP això no és possible)

– Número de seqüència. Número de seqüència relatiu del missatge

dins de la bústia (de 1 a n per a n missatges). Els números de seqüèn-

cia s’assignen correlativament segons el UID en ordre ascendent i

varien en esborrar-se i afegir-se nous missatges.

– Indicadors. Els indicadors o flags (banderes) informen de l’estat del

missatge. Per exemple, si s’ha llegit, esborrat, etc. Els indicadors

són: Seen (llegit), Answered (respost), Flagged (marcat), Deleted (es-

borrat), Draft (esborrany) i Recent (nou).

– Data interna. Data i hora d’arribada del missatge al servidor IMAP

(no és la data i hora de l’emissió del missatge que hi ha en la capça-

lera Date).

– Longitud. Nombre de bytes del missatge.

– Estructura del sobre. Representació analitzada de les capçaleres del

missatge.

– Estructura del cos. Representació analitzada de l’estructura MIME

del cos del missatge.

– Parts de text del missatge. Per permetre la cerca de les diferents

parts de text del missatge. Es pot fer l’accés segons la part de capça-

leres, cos, part del cos MIME i capçalera MIME.


3.3.2. Funcionament IMAP

El funcionament generalitzat del protocol IMAP és que el client fa una

connexió TCP/IP al port 143 del servidor i s’inicia un diàleg entre el client

i el servidor, en què tant el client com el servidor poden prendre la ini-

ciativa. En aquest procés se succeeixen els quatre estats del protocol

IMAP (no autenticat, autenticat, seleccionat i logout) i s’intercanvien

ordres i respostes seguint el model de diàleg de Telnet:

• Ordres. Les ordres IMAP són ordres de text que inclouen un tag inicial

(o etiqueta curta), l’ordre i els seus arguments. Cada ordre comença

amb una etiqueta inicial diferent per diferenciar-la de les altres ordres.

Quan el servidor emeti la resposta final de l’ordre i indiqui si s’ha rea-

litzat correctament o no, ho farà mostrant l'etiqueta de l’ordre a la qual

respon. Per exemple, es pot usar a001 per a la primera ordre, a002 per

a la segona, etc. El client pot enviar ordres sense esperar a que finalit-

zin les precedents.

• Respostes. El servidor pot enviar dades al client tant com a resposta a

una ordre com de manera unilateral (per exemple, per informar que hi

ha correu nou). El client ha d’estar en tot moment a punt per rebre

aquestes dades. Que el servidor enviï dades al client no significa que

l’execució de l’ordre del client hagi finalitzat. Només es dóna per fina-

litzada quan el servidor emet una resposta amb la mateixa etiqueta que

l’ordre del client. El servidor pot processar una ordre abans d’acabar de

processar l’ordre anterior.

Tot seguit es fa una llista de les ordres utilitzables en el protocol IMAP

agrupades segons l’estat:

1) Qualsevol estat (ordres generals)

• Capability. Llista les capacitats del servidor. Permet al client saber qui-

nes són les prestacions del servidor.

• Noop. No fa res, exigeix resposta afirmativa del servidor. Permet al client

saber si encara es manté la connexió.

• Logout. Notificació del client al servidor per fer-li saber que vol finalit-

zar la connexió.

2) No autenticat

• Authenticate tipus. Indica al servidor el mecanisme d’autenticació a

utilitzar.

Diferència entre POP i IMAP

En el protocol POP, el servidor només pot respondre a peticions del client, però no pot prendre la iniciativa. En el protocol IMAP sí.


• Login user password. El client s’identifica davant del servidor indicant

el login i la contrasenya. El format variarà (text net, hash MD5, etc.)

segons el tipus d’autenticació utilitzat.

3) Autenticat

• Select bústia. Selecciona la bústia amb què ha d'operar. En fer-ho, el

servidor emet una resposta no etiquetada en què informa dels atributs

(flags) de la bústia, del nombre de missatges que conté (exists) i del

nombre de missatges recents (recent). També pot indicar el número

del primer missatge no llegit (nseen) i la llista de flags que es poden

modificar (permanentflags).

• Examine bústia. Realitza la mateixa funció que l’ordre Select però no-

més de lectura.

• Create bústia. Crea la bústia amb el nom indicat.

• Delete bústia. Esborra la bústia indicada.

• Rename bústia nomNou. Permet modificar el nom de la bústia assig-

nant-li un nom nou.

• Subscribe bústia. Les bústies poden estar actives o no actives. Les bús-

ties s’activen amb l’ordre Subscribe.

• Unsubcribe bústia. Permet desactivar una bústia.

• List bústia criteri. Llista les bústies que compleixen el criteri indicat

dins de la bústia seleccionada.

• Lsub bústia criteri. Realitza la mateixa funció que l’ordre anterior però

només per a les bústies actives.

• Status bústia atributs. Permet conèixer l’estat d’una bústia per mitjà

dels seus atributs. Els atributs són els següents:

– MESSAGE: nombre de missatges dins la bústia;

– RECENT: nombre de missatges recents (nous);

– UIDNEXT: UID que s’assignarà al missatge nou següent que arribi a

la bústia;

– UIDVALIDITY: valor de UID de la bústia;

– UNSEEN: nombre de missatges no llegits.

• Append bústia [atributs] [data-hora] literal. Permet afegir un text li-

teral al final de la bústia com si es tractés d’un missatge nou. El missat-

ge s’afegeix amb la data, hora i atributs indicats.

Avantatge de l’IMAP respecte al POP

Un dels avantatges de l’IMAP respecte al POP és que el servidor sap a partir de quin número de missatge hi ha els missatges nous (recent).


4) Seleccionat

• Check. El client sol·licita al servidor que es faci un punt de control de

la bústia en un moment determinat.

• Close. Tanca la bústia i elimina tots els missatges que conté que tenen

l’indicador d’esborrament (deleted) activat.

• Expugne. Permet esborrar els missatges que tenen l’atribut d’esborra-

ment (deleted) activat sense que calgui tancar la bústia.

• Search [charset] criteri. Permet buscar missatges dins de la bústia que

compleixen el criteri de cerca indicat.

• Fetch dades atributsRecuperació. Permet recuperar un conjunt de

missatges totalment o parcialment segons els atributs de recuperació

indicats.

• Store conjuntMissatges atributs. Permet alterar les dades d’atributs

associats a un conjunt de missatges en una bústia.

• Copy conjuntMissatges bústia. Copia un conjunt de missatges al final

de la bústia indicada.

• UID ordre. Retorna l’UID d’un missatge. S’utilitza conjuntament amb

les ordres COPY, FETCH, STORE o SEARCH per retornar els UID ma-

nipulats.

5) Experimental

• X<ordre>. Es poden desenvolupar ordres experimentals fora de l'es-

pecificació IMAP. Per fer-ho cal que les ordres comencin amb XnomCo-

manda. D’aquesta manera s’evita que es produeixin conflictes amb

ordres futures.

En l'exemple següent es pot veure tot el diàleg client/servidor d’una sessió

IMAP utilitzant Telnet.

[root@portatil ~]# telnet localhost 143 Trying 127.0.0.1... Connected to localhost. Escape character is ‘^]’. * OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS STARTTLS] localhost IMAP4rev1 2007a.403 at Sat, 14 Jun 2008 13:16:47 +0200 (CEST) a003 LOGIN pere pere a003 OK [CAPABILITY IMAP4REV1 LITERAL+ IDLE UIDPLUS NAMESPACE CHILDREN MAILBOX-REFERRALS BINARY UNSELECT ESEARCH WITHIN SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User pere authenticated


3.4. El servei de notícies NNTP

El servei de notícies (servei news o NNTP) està pensat per proporcionar

una funcionalitat similar als taulers d’anuncis, on tothom pot publicar i

llegir els missatges que hi ha penjats. En molts aspectes s’assembla al

servei de correu electrònic, però els diferencia que aquí no cal especifi-

car un destinatari. L’objectiu que persegueix l'NNTP (network news

transfer protocol, o protocol de transferència d’articles, o també news)

és difondre articles arreu del món per tal que els usuaris els pugin llegir,

sense que qui els publica n'hagi d’enviar una còpia als destinataris. Els

articles es publiquen en servidors de news que els propaguen a altres ser-

vidors. Els clients que volen accedir als articles utilitzen un client news

per connectar per NNTP amb els servidors locals o remots. Els articles

s’organitzen en grups de notícies segons la temàtica, àmbit territorial,

etc., per facilitar-ne la cerca.

El servei de notícies es coneix indistintament com a servei news, servei

NNTP o servei Usenet. Usenet és el nom de la xarxa original sobre Unix

en què es va basar el primer servei de notícies. Utilitzava l'UUCP (Unix to

Unix copy protocol, o protocol de còpia d’Unix a Unix) per copiar els arti-

cles d’una màquina Unix a una altra. Els usuaris feien connexions locals

a004 SELECT inbox * 4 EXISTS * NO Mailbox vulnerable - directory /var/spool/mail must have 1777 protection * 4 RECENT * OK [UIDVALIDITY 1213385060] UID validity status * OK [UIDNEXT 6] Predicted next UID * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags * OK [UNSEEN 1] first unseen message in /var/spool/mail/pere * NO Mailbox vulnerable - directory /var/spool/mail must have 1777 protection a004 OK [READ-WRITE] SELECT completeda005 FETCH 1 rfc822.text * 1 FETCH (RFC822.TEXT {63} exemple de missatge de la usuaria anna a l’usuari pere adeu ) a005 OK FETCH completeda006 LOGOUT * BYE portatil IMAP4rev1 server terminating connection a006 OK LOGOUT completed

L'NNTP és un protocol pensat per a la distribució, consulta, cerca i

publicació d’articles usant TCP (port 119) i basat en el model client/

servidor.


(mitjançant trucada telefònica) als servidors locals per accedir i dipositar

els articles.

El protocol NNTP es descriu originàriament en el document RFC 977 del

febrer del 1986. La versió actual correspon al document RFC 3977 de l’oc-

tubre del 2006. El format dels articles es descriu en el document RFC 1036

del desembre de 1987 i es basa principalment en el mateix format que els

missatges de correu (document RFC 822). També es pot fer servir l'IMAP

per gestionar el servei de notícies.

Els serveis de notícies NNTP estan en retrocés a causa del gran èxit del

servei web (HTTP) a Internet. Cada cop s’utilitzen menys els servidors de

notícies, i més els fòrums web, que proporcionen una funcionalitat equi-

valent.

3.4.1. Descripció general

Hi ha diversos mecanismes per distribuir articles d'informació a usua-

ris repartits per Internet. Potser el més evident és el correu electrònic

mitjançant les llistes de distribució o Internet mailing lists. L’usuari

envia l’article per correu electrònic a una llista d’usuaris que creu que

hi estaran interessats. L’inconvenient d’aquest model és l’ús ineficient

de l’amplada de banda de la xarxa. Cal enviar una còpia a cada destina-

tari. A més a més es poden produir duplicacions, els usuaris pertanyen

a diverses llistes i el reben diverses vegades, canvien d’ubicació, de cor-

reu electrònic, etc. No hi ha un mecanisme de selecció de què es pro-

paga i de què es vol rebre.

El servei de notícies és una evolució millorada del servei Usenet original

que funcionava sobre UUCP network. Aquest mecanisme obligava els usua-

ris a realitzar una connexió als servidors Unix amb servei de notícies per

iniciar-hi una sessió local i així poder accedir als articles. Usualment es

tractava de connexions per mòdem amb trucada telefònica al servidor i

exigia a l’usuari disposar d’un compte d’usuari en la màquina.

El servei de notícies NNTP utilitza un repositori central d’emmagatzema-

ment d’articles que es distribueix descentralitzadament amb altres servi-

dors. L’arquitectura client-servidor permet als usuaris connectar-se als

servidors per gestionar els articles.

L'NNTP utilitza el model client/servidor:

• Client. El client demana l’article que vol veure al servidor (en lloc de

baixar-los tots). Client i servidor parlen en llenguatge NNTP. L’aplica-

ció client normalment és un programari lector/generador d’articles.

Per obtenir més informació sobre l’especificació del protocol NNTP en els RFC 977, 1036 i 3977 aneu a la secció “Adreces d’interès” del web d’aquest crèdit.

!!


• Servidor. El servidor rep i envia notícies als subscriptors i dels subs-

criptors, i en propaga a altres servidors. En el servidor hi ha programari

que permet als subscriptors seleccionar els ítems que vol. Hi ha meca-

nismes d’indexació, selecció, referències creuades i expiració. El servi-

dor ofereix servei a una àrea d’influència com una LAN, un campus,

ciutat, país, etc. Normalment, el servidor és un programari que treballa

en background (segon pla) normalment en forma de dimoni. Els arti-

cles sovint s’emmagatzemen en alguna mena de spool (cua) on els

subscriptors accedeixen per obtenir-ne i dipositar-ne. Hi ha la figura de

l'slave server (servidor esclau) que manté una memòria cau de notícies

per donar servei a la seva àrea.

Tot seguit es descriuran els elements i funcions que prenen part en el ser-

vei de notícies:

• Distribució. Usenet UUCP (model antic) utilitzava la distribució d’arti-

cles per inundació de host a host. Es feien còpies de tot a tots els hosts,

evidentment amb una utilització ineficient dels recursos. Amb l'NNTP

es fa la selecció de què es vol rebre, enviar i a qui. El subscriptor dema-

na la llista de novetats i baixa el que li interessa (no tot). El client tam-

bé informa el servidor dels articles que vol publicar, i el servidor els

accepta si no són duplicats (pot filtrar). No es garanteix que un article

arribi a tots els servidors del món ni a un de concret. S’eviten els bucles

controlant el camí per on es distribueixen els articles. No hi ha un únic

repositori mundial dels articles sinó que formen una base de dades dis-

tribuïda (com la informació DNS).

• Articles. Un article o news és un text que un subscriptor publica en un

servidor per tal que altres usuaris el puguin llegir (tipus tauler d’anun-

cis). Els articles porten associat un temps d’expiració (publicació per

un període de temps limitat) que pot indicar el redactor, el servidor o

el moderador. Per facilitar la cerca d’informació, els articles s’organit-

zen en grups segons el tema de manera jeràrquica. Un article pot per-

tànyer a diversos temes. La nomenclatura dels grups és de major nivell

a nivell més concret separats per punt, per exemple: comp.os.linux (or-

dinadors, sistemes operatius, Linux).

• Administració d’articles i grups. Els articles i els grups que hi ha a

Usenet poden ser administrats per un o més moderadors. Hi ha grups

sense administració, grups en què les decisions es prenen assembleà-

riament i grups moderats. El moderador decideix si permet la publica-

ció de l’article o no, i en pot decidir la data d’expiració. A Usenet hi ha

En el protocol NNTP només els articles no duplicats i desitjats són

transferits.


regles i votacions per decidir la gestió (creació, eliminació, modifica-

ció) de grups de notícies a nivell global.

• Grups. Els articles publicats en el sistema de notícies es van organitzar

jeràrquicament en grups. Es van definir set grups en el nivell principal

que posteriorment van ser vuit, corresponents als següents:

– Comp: temes relacionats amb la informàtica

– Misc: altres temes no classificables en els altres apartats

– News: articles sobre el mateix sistema de notícies

– Rec: activitats recreatives, aficions, jocs, etc.

– Sci: temes científics

– Soc: temes socials, culturals i humanístics

– Talk: debats, opinions, discussions

– Humanities: discussions de temes d’humanitats, literatura, filosofia

Hi ha una jerarquia alternativa a l'estàndard en què hi ha grups que

no es podien crear en la jerarquia oficial. Una mena de grup sense

normes:

– Alt: jerarquia alternativa a l'oficial, que conté de tot i sense normes.

3.4.2. Especificació NNTP

L'NNTP és un protocol basat en TCP que utilitza el port 119. Com tots els

protocols “vells” d’Internet, no ofereix cap mena de xifratge ni privacitat

en la informació que transporta. Es pot utilitzar NNTP per sobre d'SSL

(que podem anomenar NNTPS), la qual cosa permet connexions segures.

Utilitza el port 563.

Format dels articles NNTP

El format dels articles NNTP es basa en el document RFC 1036 de Usenet.

Al seu torn, aquest format es basa en el format dels missatges de correu

(document RFC 822). És a dir, els articles de Usenet són conceptualment

similars als correus electrònics. Els articles tenen una estructura basada

en un conjunt de capçaleres, una línia en blanc de separació (CRLF) i el

cos o text de l’article (igual que els correus electrònics).

El sistema NNTP exigeix una sèrie de capçaleres concretes que han de te-

nir els articles. Aquestes capçaleres són les següents:

• From. Adreça de correu electrònic del generador de l’article.

• Date. Dia i hora de creació de l’article.

• Newsgroups. Llista de grups als quals s’ha d’enviar l’article. Un article

pot pertànyer a més d’un grup. L’aplicació client, en llegir un article en


un grup, automàticament marca com a llegit el mateix article en els al-

tres grups.

• Subject. Tema de què tracta l’article.

• Message-ID. Identificador únic de l’article.

• Path. Llista de servidors pels quals ha passat l’article. Això permet als

servidors evitar bucles no enviant els articles a servidors que ja l’han

rebut. Cada servidor s'afegeix a l’inici del Path.

A més a més l’especificació descrita en el document RFC 1036, NNTP de-

fineix un conjunt de capçaleres addicionals que es poden utilitzar. Com ha

passat amb el correu, inicialment els articles es basaven en text, però avui

en dia el seu contingut també pot ser binari.

A continuació, podeu veure un exemple d’un article publicat en el sistema

news.

Ordres/respostes de NNTP

El format d’ordres/respostes que utilitza l'NNTP és similar i es basa en el

format del protocol Telnet. El servidor de notícies accepta les ordres dels

clients i actua d’interfície per a l’accés a la base de dades d’articles.

• Ordres. Cada ordre correspon a una ordre de text per línia, consistent

en el nom de l’ordre, els arguments si calen, i un CRLF final. Les línies

de les ordres estan limitades a un màxim de 512 caràcters.

• Respostes de text. S’entén per resposta de text la transmissió d’un ar-

ticle. Només es pot produir una resposta de text després d’una resposta

d’estatus que informa que a continuació s’enviarà una resposta de text.

El text és un conjunt de línies acabades cada una amb un CRLF. Es

dóna per finalitzada la resposta en trobar una línia que conté única-

ment un punt a l’inici i el CRLF a continuació. Si el cos del text conté

alguna línia que comença amb punt, s’encapsula afegint un altre punt

a l’inici (que el programa client eliminarà).

• Respostes d’estatus. Les respostes d’estatus indiquen el resultat de

l’execució de l’última ordre rebuda del client. Consisteixen en un codi

From: Chris Mitchell <[email protected]>Subject: Re: Personal search pageDate: 1998/03/30Message-ID: <[email protected]>#1/1Content-Transfer-Encoding: 7bitContent-Type: text/plain; charset=us-asciiOrganization: Intuitive SpecialtiesMime-Version: 1.0Newsgroups: comp.infosystems.search

Jorn Barger wrote: a startup page with my most frequent links (incl many local...


numèric de tres dígits i un text descriptiu. Les respostes de text (els ar-

ticles) són per mostrar en el terminal de l’usuari, les respostes d’esta-

tus són per ser processades pel programari client. El primer dígit del

codi numèric de les respostes indica el tipus de missatge, el segon dígit

indica la categoria de la resposta. Els tipus de missatges són els se-

güents:

– 1xx: missatge informatiu.

– 2xx: ordre realitzada correctament.

– 3xx: ordre realitzada correctament; a continuació s’envia una respos-

ta de text.

– 4xx: ordre correcta però no s’ha pogut executar.

– 5xx: ordre incorrecta, inexistent o error greu.

asi_2251_c02_ud2

Documents