tcp/ip: els protocols de la xarxa internet - formador · en particular, el protocol ip en la...

TCP/IP:els protocols de la xarxa InternetJosé M. Barceló OrdinasJordi Íñigo Griera

P03/05064/00972

© Universitat Oberta de Catalunya • P03/05064/00972 TCP/IP: els protocols de la xarxa Internet

Índex

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

Objectius ..................................................................................................... 7

1. Estructura de protocols a Internet ................................................. 9

1.1. Protocols d’Internet .......................................................................... 10

1.2. Encapsulament ................................................................................. 11

2. Xarxes d’accés a Internet .................................................................. 13

2.1. Accés telefònic: el PPP ...................................................................... 13

2.1.1. Compressió de les capçaleres ................................................ 15

2.1.2. MTU ....................................................................................... 15

2.2. Accés ADSL ....................................................................................... 16

2.3. Accés LAN: el protocol Ethernet ....................................................... 18

2.3.1. Format de la trama Ethernet ................................................. 18

2.3.2. Adreces LAN .......................................................................... 21

3. L’IP (Internet protocol) ....................................................................... 23

3.1. Adreces IP .......................................................................................... 23

3.1.1. Màscares de xarxa .................................................................. 25

3.1.2. Adreces de propòsit especial ................................................. 25

3.2. El format del paquet IP ..................................................................... 26

3.2.1. Fragmentació ......................................................................... 30

3.3. Encaminament i encaminadors ....................................................... 31

3.3.1. La taula d’encaminament ..................................................... 32

4. L’ARP (address resolution protocol) ............................................... 35

5. L’ICMP (Internet control message protocol) .................................. 37

5.1. Missatges ICMP ................................................................................. 37

5.2. El programa ping ............................................................................. 38

5.3. El programa traceroute ................................................................. 40

5.4. Missatge de readreçament ................................................................ 42

6. Protocols del nivell de transport .................................................... 44

7. L’UDP (user datagram protocol) ...................................................... 47

8. El TCP (transmission control protocol) .......................................... 49

8.1. El TCP proporciona fiabilitat ............................................................ 49

8.2. Format del segment TCP .................................................................. 50

© Universitat Oberta de Catalunya • P03/05064/00972 TCP/IP: els protocols de la xarxa Internet

8.3. Establiment de la connexió .............................................................. 55

8.4. Terminació de la connexió ............................................................... 57

8.5. Diagrama d’estats del TCP ................................................................ 60

8.6. Transferència de la informació ......................................................... 61

8.6.1. Transmissió de dades interactives ......................................... 62

8.6.2. Transmissió de dades de gran volum. Control de flux

per finestra lliscant ................................................................ 63

8.6.3. Temporitzadors i retransmissions ......................................... 68

Resum .......................................................................................................... 74

Exercicis d’autoavaluació ...................................................................... 77

Solucionari ................................................................................................. 78

Glossari ........................................................................................................ 80

Bibliografia ................................................................................................ 81

Annexos ....................................................................................................... 82


Introducció

El que es coneix com a xarxa Internet és un conjunt heterogeni de xarxes in-

terconnectades. És precisament la capacitat de fer homogeni el que de fet és

heterogeni el que ha catapultat la xarxa Internet al seu estatus actual.

Els protocols que distingeixen la xarxa Internet com una unitat són l’IP* i el

TCP**. De fet, aquests són només dos d’entre la mitja dotzena de protocols que

es necessiten per a fer funcionar la xarxa Internet, però són els més impor-

tants. Per aquest motiu, a tots en conjunt se’ls anomena normalment pila

(stack) TCP/IP (en anglès TCP/IP protocol suite).

Evolució històrica de la xarxa Internet

La xarxa ARPANET* dels EUA és la precursora de la xarxa Internet actual. Des del 1969,ARPANET va finançar la interconnexió de nodes de commutació de paquets mitjançantlínies punt a punt dedicades. Durant la primera dècada de funcionament va permetre aun gran conjunt d’investigadors desenvolupar i perfeccionar les tècniques per a la gestiói l’ús de les xarxes de commutació de paquets. Cap al 1979, la pila TCP/IP es comença aperfilar com el conjunt de protocols de futur de la xarxa i, al final del 1982 tots els nodesd’ARPANET ja havien adoptat el TCP/IP.

Ràpidament, ARPANET esdevé el nus d’interconnexió principal d’altres xarxes de dades,sobretot de les acadèmiques. Els ordinadors militars, que també havien format part de laxarxa inicial i del seu desenvolupament, se n’escindeixen i en formen una de pròpia (laMILNET). A mitjan anys vuitanta, l’èxit del TCP/IP queda demostrat pel fet que la novaxarxa de commutació de paquets per a la recerca de l’NSF* dels EUA finança l’NSFNET.Amb el temps, totes les xarxes acadèmiques, primerament les dels EUA, després les d’Eu-ropa i més tard les de la resta del món, s’acabaran connectant a aquesta xarxa. La xarxade xarxes, Internet, començà el seu creixement vertiginós –gairebé explosiu– cap al 1986.

A principi dels anys noranta, les principals universitats ja formaven part d’Internet i,quan el boom d’Internet es preveia que es frenaria perquè la majoria de les universitatsja s’hi havien connectat, les empreses van començar a veure el potencial de la xarxa,primer com a mitjà d’interconnexió i, una mica més tard, com a eina de màrqueting(el 1993 apareix l’HTTP*, el protocol del WWW**).

El creixement actual d’Internet es manté imparable, i comencen a sorgir els primers pro-blemes. La xarxa Internet pateix certes limitacions en la seva especificació actual que po-den fer que aquest creixement s’hagi d’aturar en un futur no gaire llunyà si no s’hi fancanvis importants. En particular, el protocol IP en la versió actual, la 4 (IPv4), limita elnombre d’estacions que es poden connectar a Internet a 232 (uns 4.000 milions d’esta-cions). Si bé el nombre d’estacions actual (el 1998) és d’uns 40 milions, la manera d’assig-nar les adreces d’Internet fa que hi hagi moltes adreces que a la pràctica són inutilitzables.Actualment, es considera que l’única solució a llarg termini serà l’actualització de tots elscomponents de la xarxa en la versió nova, la 6 (IPv6 o IPng, IP next generation).

The next generation

Les versions 1, 2, 3 i 5 de l’IP no s’han fet servir mai. Internet, des del seu inici com aARPANET, ha adoptat la versió 4. Actualment, es parla de la versió nova com la versiónext generation (en honor a la sèrie de televisió Star Trek: the next generation) en lloc de dir-li versió 5, que seria el normal si no fos perquè un document de l’IAB (Internet Architec-ture Board) va confondre tothom dient que la nova versió seria la 7.

Sigui com sigui, els quatre primers bits de tots els paquets que circulen per Internet són 0100,és a dir, 4, per a indicar la versió IP que els defineix. Els nous paquets hauran de començarper quatre bits diferents, que òbviament no poden ser next generation. Aquests quatre bits ini-cials seran 0110, és a dir, 6.

* IP és la sigla d’Internet protocol.** TCP és la sigla de transmission

control protocol.

* ARPANET és l’acronim d’advanced research projects

agency network.

* NSF es la sigla de National ScienceFoundation.

* HTTP és la sigla d’hyper-texttransfer protocol.

** WWW és la sigla de world wide web.


Avui dia, el protocol TCP/IP s’utilitza fins i tot en xarxes homogènies com les

que podem trobar, per exemple, en una empresa privada. La disponibilitat de

moltes aplicacions que funcionen sobre TCP/IP fa que aquests protocols es fa-

cin servir com a connexió entre sistemes locals. Per a identificar aquests casos,

ha fet fortuna el nom Intranet. En general parlarem simplement de xarxes

TCP/IP quan no vulguem especificar si tenim connexió a Internet o no.


Objectius

En aquest mòdul didàctic, l’estudiant trobarà els recursos necessaris per a as-

solir els objectius següents:

1. Aprendre el funcionament de les xarxes d’accés a Internet (accés LAN i ac-

cés per xarxa telefònica).

2. Entendre els fonaments del funcionament dels protocols d’encaminament

(IP, ARP i ICMP): l’adreçament, el mapatge d’adreces i el control de congestió.

3. Saber en quins principis es basen els protocols de control de la transmissió

punt a punt (TCP i UDP).

4. Conèixer algunes utilitats d’ús comú que permeten investigar empírica-

ment les interioritats de la xarxa.


1. Estructura de protocols a Internet

El model Internet gira a l’entorn del protocols TCP/IP. De fet, podríem con-

siderar que el model de la xarxa Internet consta només de quatre parts o

nivells, és a dir, tot el que hi ha sota l’IP, l’IP, el TCP i tot el que hi ha sobre

el TCP:

1) Nivell de xarxa: normalment és format per una xarxa LAN, o WAN (de

connexió punt a punt) homogènia. Tots els equips connectats a Internet im-

plementen aquest nivell. Tot el que es troba per sota de l’IP és el nivell de xarxa

física o, simplement, nivell de xarxa.

2) Nivell IP o nivell Internet (nivell d’Internetworking): dóna unitat a tots

els membres de la xarxa i, per tant, és el que permet que tots es puguin in-

terconnectar, independentment de si s’hi connecten mitjançant línia telefò-

nica, ISDN o una LAN Ethernet. L’adreçament i l’encaminament són les

seves principals funcions. Tots els equips connectats a Internet implementen

aquest nivell.

3) Nivell TCP o nivell de transport: dóna fiabilitat a la xarxa. El control

de flux i d’errors es porta a terme principalment dins aquest nivell, que no-

més és implementat pels equips usuaris de la xarxa Internet o pels termi-

nals d’Internet. Els equips de commutació (encaminadors o routers) no el

necessiten.

4) Nivell d’aplicació: engloba tot el que hi ha per sobre del TCP; és el nivell

que correspon a les aplicacions que utilitzen Internet: clients i servidors de

WWW, correu electrònic, FTP, etc. es troben dins aquest nivell, que només és

implementat pels equips usuaris de la xarxa Internet o els terminals d’Inter-

net. Els equips de commutació no el fan servir.

Lectura complementària

Per a aprofundir en els protocols d’Internet, vegeu els apartats 1.4, 1.10 i 29.3 de l’obra següent:

D.E. Comer (1995).“Principles, Protoccols and Architecture” Internetworkingwith TCP/IP (volum I). Hertfordshire: Prentice Hall.

Vegeu els encaminadors, o nodes de commutació, en el subapartat 3.3 d’aquest mòdul didàctic.


Només els equips terminals implementen tots els nivells; els equips intermedis

únicament implementen el nivell de xarxa i el nivell IP:

Ja hem vist els conceptes bàsics del nivell de xarxa en el mòdul anterior, però

ara n’ampliarem alguns (sobretot els que estan relacionats amb l’adreçament).

Del nivell d’aplicació, en parlarem a bastament en altres mòduls d’aquesta as-

signatura. En aquest mòdul, veurem la part central del model Internet, estudi-

arem en primer lloc l’IP i després el TCP.

1.1. Protocols d’Internet

En cadascun dels nivells de la xarxa exposats trobem protocols diferents. La

situació relativa de cada protocol en els diferents nivells es mostra en la figura

següent:


S’ha de tenir en compte que el concepte nivell no existeix a Internet. Aquest

concepte es fa servir en altres models de xarxa, com ara l’OSI. De totes mane-

res, com que és un concepte útil, en aquest mòdul l’utilitzarem per a plantejar

l’estudi dels diferents protocols de la manera següent:

• Primerament estudiarem certs aspectes bàsics del nivell de xarxa (en el cas

particular de les LAN Ethernet i també en els accessos per línia punt a punt

amb el protocol PPP o amb ADSL).

• Després ens centrarem en l’IP i els protocols que hi col·laboren: ARP i

ICMP.

• Finalment analitzarem els protocols TCP i UDP.

1.2. Encapsulament

Caldrà saber, per exemple, quines implicacions té el fet que un protocol com

el TCP, com es veu a la figura del subapartat anterior, vagi sobre un altre pro-

tocol, l’IP, i que l’IP vagi, al seu torn, sobre Ethernet.

Cadascun d’aquests protocols funciona amb unes estructures fonamentals que

genèricament es coneixen com a PDU*. En cada nivell, però, s’utilitzen noms

diferents per a anomenar el que, de fet, té funcions equivalents:

• Les PDU Ethernet o PPP s’anomenen trames.

• Les PDU del nivell d’interconnexió (IP o ARP) s’acostumen a denominar

paquets*.

• En el nivell de transport, es parla de segments en TCP, i de datagrames en

UDP.

• En nivells superiors que fan servir UDP, normalment s’utilitza la paraula

PDU (SNMP-PDU, per exemple). En el cas del TCP, el servei que dóna a les

aplicacions és el flux de bytes sense estructura (byte stream). Per tant, el con-

cepte PDU deixa de tenir sentit en el nivell superior a TCP.

Encara no hem respost, però, a la pregunta inicial. El resultat dels diferents encap-

sulaments en cada nivell és que, quan el nivell superior decideix transmetre certa

informació, es provoca una cascada de PDU que va descendint fins al nivell infe-

rior, que finalment és el que transmet físicament els bits que en resulten.

Longitud de la trama necessària per a transmetre un byte d’informació

Vegem, a tall d’exemple, l’emulació de terminal que efectua el programa telnet i elprotocol que porta el mateix nom. Imaginem que premem una tecla sobre la finestradel programa telnet. Aquesta acció arriba en forma d’un byte únic al nivell TCP. Elnivell TCP encapsula aquest byte en un segment TCP, que tindrà una capçalera de 20bytes i un contingut que serà el byte corresponent a la tecla premuda. Aquests 21 bytes

Vegeu el model OSI en l’apartat 3 del mòdul didàctic “Conceptes bàsics de les xarxes de comunicacions” d’aquesta assignatura.

* PDU es la sigla de protocol data units.

* Les PDU ICMP, però, generalments’anomenen missatges, segurament

perquè viatgen en paquets IP.

Telnet està disponible a tots els sistmes operatius habituals.


es transportaran dins un paquet IP que generalment formarà un paquet amb 20 bytesde capçalera més el contingut ja esmentat de 21 bytes. Aquest paquet de 41 bytes anirà,al seu torn, dins una trama que el transportarà pel suport físic de transmissió. Si el su-port de transmissió és una línia telefònica amb un mòdem i utilitzem PPP, el resultatpot ser que hi afegim 8 bytes més.

Tot junt, en resulta una trama de 49 bytes (8 + 20 + 20 + 1) de longitud per a transmetre’nun de sol. La figura següent mostra aquesta estructura a:

Un exemple aclaridor del gràfic ésel de les típiques nines russes.


2. Xarxes d’accés a Internet

Les xarxes d'accés a Internet més habituals són la xarxa telefònica (per mò-

dem) que es fa servir, sobretot, en l'àmbit domèstic, l'ADSL* que, tot i que uti-

litza la infraestructura d'accés de la xarxa telefònica, no es pot dir que vagi

sobre la línia telefònica, i l'Ethernet.

1) En accessos mitjançant la xarxa telefònica i, en general, en accessos mit-

jançant xarxes commutades (incloent-hi l’accés per l’XDSI), se sol utilitzar el

protocol PPP*.

Si bé durant molt de temps s’han emprat l’SLIP* i el CSLIP**, actualment s’han

deixat pràcticament de banda en favor del PPP, que té més flexibilitat (permet

gestionar automàticament certs paràmetres IP i multiplexar, dins la mateixa

connexió, diferents protocols d’interconnexió, a part de l’IP) i és més fiable

(disposa de CRC en cada trama).

2) En LAN, el protocol que s’utilitza en més del 90% dels casos és l’Ethernet.

Nosaltres ens centrarem només en els detalls de l’adreçament d’aquest proto-

col, ja que això és l’únic que afecta la manera de funcionar de l’IP.

Gairebé tots els protocols de LAN que componen el 10% restant (IEEE802.3

CSMA/CD, IEEE802.5 Token Ring, etc.) utilitzen una estructura d’adreçament

idèntica a la d’Ethernet. De fet, podríem parlar de compatibilitat en l’adre-

çament, ja que l’assignació d’adreces es fa globalment per a totes les LAN es-

mentades i la gestiona l’IEEE*.

2.1. Accés telefònic: el PPP

Els camps indicador (flag), adreça i control estan fixats als valors de la figura an-

terior. El camp adreça té el valor 11111111, que és el de difusió o broadcast en

El PPP és fonamentalment un protocol derivat de l’HDLC* per a conne-

xions balancejades (HDLC-ABM**). El format de la trama PPP es repre-

senta en la figura següent:

* ADSL és la sigla de línia d’abonat digital asimètrica (asymetric digital

subscriber line).

* PPP és la sigla de point-to-point protocol.

* SLIP és la sigla de serial line Internetprotocol.

** CSLIP és la sigla de compressedSLIP.

* IEEE és la sigla d’Institute of Electric and Electronic Engineers.

* HDLC és la sigla de high-level data link protocol.

** HDLC-ABM és la sigla d’HDLC-asynchronous balanced mode.Aquest protocol és descriu a

l’assignatrua i Estructura de bases de dades

Com que el camp de control...

... està fixat (sempre val 3), el PPP no distingeix els dife-rents tipus de trames. Totes són d’informació, no hi ha con-firmacions ni trames d’establi-ment d’enllaç (és un protocol no orientat a connexió).


la major part de protocols (per exemple, en tots els HDLC). Això vol dir que

aquest camp (com el de control) no s’utilitza. La seva utilització en el PPP no-

més es pot justificar pel possible ús de targetes HDLC genèriques per a conne-

xions PPP. Com qualsevol protocol HDLC, ha d’aplicar el mecanisme de

transparència d’inserció de zeros (bit stuffing).

El PPP especifica una variant orientada a caràcter (els protocols de la família

HDLC són orientats a bit), que és la que més es fa servir en enllaços mitjançant

mòdem (un contraexemple serien les connexions mitjançant l’XDSI).

L’important és el que transporten les trames PPP. El mateix estàndard defineix

la multiplexació de diferents protocols, que es distingiran per mitjà del camp

tipus. Els que ens interessen són els següents:

• LCP*: és el protocol encarregat de fer el test de l’enllaç, el control de la con-

nexió i la gestió de l’enllaç.

• Protocols de xarxa: són trames que encapsulen paquets de nivell supe-

rior com ara IP. Però també poden transportar NETBEUI, AppleTalk,

Decnet, etc.

• NCP*: és el protocol que s’utilitza per a tasques de gestió dels protocols de

xarxa que transporta l’enllaç. En el cas de l’IP, permet que un dels terminals

assigni l’adreça d’Internet a l’altre i configuri els diferents paràmetres de la

xarxa (encaminador, màscara, etc.).


Si es fa servir el PPP sobre un enllaç orientat a caràcter, el mecanisme de transparència és diferent del que hem explicat. El podeu consultar en l’obra següent:W.R. Stevens (1994). TCP/IPIllustrated (volum 1: “The Protocols”). Wilmington: Addison-Wesley.

* LCP és la sigla de link control protocol.

* NCP és la sigla de network control protocol.


2.1.1. Compressió de les capçaleres

Com ja hem vist, la piràmide de PDU provoca ineficiències en la transmis-

sió, sobretot en protocols com Telnet, que sovint envien blocs molt curts

d’informació. A més, el PPP s’ha utilitzat en enllaços telefònics que funci-

onen a velocitats màximes teòriques d’entre 9.600 bps (mòdems norma

V.32) i 33.600 bps (mòdems norma V.34). Això fa que aquesta ineficiència

sigui encara més greu.

Velocitats de transmissió de dades amb Telnet

Si s’utilitza Telnet, per a enviar un caràcter (d’1 byte) hem d’enviar 8 + 20 + 20 + 1 = 49bytes. Amb un mòdem de 9.600 bps, si féssim servir missatges de 8 bits de longitud més 1bit d’arrencada i 1 bit de parada, podríem transmetre:

9.600 / (1 + 8 + 1) = 960 caràcters/segon

Amb les limitacions imposades per les capçaleres, només podrem transmetre:

960 · (1 / 49) = 19,5 caràcters/segon.

Certament, ningú no és capaç de mecanografiar tan ràpid. Però no hem de perdre de vistaque l’enllaç pot ser compartit per altres connexions (transferència de fitxers, consulta delweb, etc.).

La compressió de capçaleres Van Jacobson millora considerablement aquest

problema. Aquest tipus de compressió es basa en el fet que en un accés a In-

ternet amb PPP, normalment no hi haurà gaires connexions TCP simultànies.

La compressió Van Jacobson permet mantenir una taula de fins a 16 connexions

simultànies TCP/IP, a les quals assignarà 16 identificadors diferents. Com que

la major part dels camps de les dues capçaleres TCP/IP no varien durant el

transcurs d’una mateixa connexió, n’hi ha prou de tenir entre 3 i 5 bytes de

capçalera per a cada paquet (combinant PPP i TCP/IP) per a mantenir un fun-

cionament correcte de la connexió. El guany en eficiència de la transmissió és

prou important.

Per a saber exactament quin guany s’aconsegueix, ens caldrà saber quina lon-

gitud poden tenir les trames PPP.

Mitjançant l’LCP també es poden obtenir altres millores com, per exemple,

l’eliminació dels camps de control i d’adreça.

2.1.2. MTU

Molts protocols tenen una longitud màxima de transmissió. Aquesta longitud

màxima, que anomenarem MTU*, està determinada per diferents factors se-

gons el cas. En el PPP (que és el que ara ens interessa), trobem un protocol de-

rivat de l’HDLC. L’HDLC no imposa cap límit en l’MTU de les trames; en

teoria, les podríem fer tan llargues com la probabilitat d’error ens permeti (la

probabilitat d’error en un dels bits de la trama no hauria de ser gaire alta).

* MTU és la sigla de maximumtransfer unit.


Hi ha, però, un factor que limitarà l’MTU més que no pas els límits imposats

pels protocols: el confort de la connexió. S’ha demostrat que, en connexions

en temps real (com ara una connexió Telnet), l’usuari ha de rebre una reacció

a les seves accions en una dècima de segon com a màxim. Retards superiors

provoquen cansament i fan la sensació que “la màquina va lenta”, que tots

hem experimentat alguna vegada.

Si pensem que dins la mateixa connexió en podem tenir multiplexades altres

de transferència (com FTP o web), ens trobarem que els paquets de les aplica-

cions en temps real, que solen ser curts, s’han d’esperar al darrere dels paquets

de longitud màxima que es fan servir en les aplicacions que tenen una taxa de

transmissió elevada (suposarem que els paquets de l’aplicació en temps real te-

nen preferència sobre altres que prèviament estiguessin a la cua de sortida).

L’única manera de fer que una aplicació estàndard de transferència utilitzi pa-

quets més petits és reduir l’MTU de la connexió. En el cas del PPP, si prenem

com a referència un mòdem de 28.800 bps, tenim que un paquet d’una dèci-

ma de segon de durada tindria els bytes següents:

33.600 bps · (0,1 s) · (1 byte / 8 bits) = 420 bytes.

En connexions PPP tindrem, doncs, l’MTU entre 250 i 500 bytes. Amb mò-

dems que disposin de compressió, els valors que obtindrem poden augmentar.

Mòdems per a línia telefònica

Les velocitats de transmissió dels mòdems estàndard són 9.600 bps (V.32), 14.400 bps(V.32bis) i 33.600 bps (V.34).

Normalment, els mòdems disposen de dispositius electrònics per a comprimir i descompri-mir dades. Els estàndards V.42bis i MNP9 fan compressions de fins a 1:4, amb la qual cosapoden assolir velocitats de transmissió efectiva de fins a 134.400 bps (V.34 + V.42bis) en si-tuacions favorables.

Hi ha mòdems (els que segueixen l’estàndard V.90) que poden assolir velocitats de fins a56 kbps. En realitat no són mòdems en el sentit estricte, ja que necessiten que a l’altreextrem de la línia hi hagi un còdec connectat a una línia digital.

2.2. Accés ADSL

Si bé l’accés a Internet per mòdem mitjançant PPP ha estat la manera habitual

de connexió per part dels usuaris domèstics i les petites empreses durant la pri-

mera “dècada Internet”, sembla que això canviarà i en la segona “dècada In-

ternet” s'adoptaran sistemes que facilitin la connexió permanent. La connexió

per mòdem ocupa la línia de telèfon de l’abonat i, el que encara és pitjor, es-

tableix una trucada durant un temps indefinit.

L’ADSL representa una solució a aquest problema, ja que, d’una banda (tot i

que utilitza el cablejat de la línia telefònica, el bucle d’abonat), la línia telefò-

nica queda lliure per a trucades mentre s'està connectat a Internet i, de l'altra,

la connexió no consumeix recursos de la xarxa telefònica, ja que, quan el se-


nyal arriba a la centraleta, s'extreu del bucle d’abonat i passa a la xarxa IP de

l'operadora.

L'encaminador que hi ha al domicili de l’usuari, normalment, ofereix una con-

nexió Ethernet equivalent a un concentrador, la qual cosa permet que l’abo-

nat connecti més d’un ordinador mitjançant la línia ADSL.

Per a permetre que la línia telefònica convisqui amb la connexió a Internet

permanent, es fa una divisió de l’espectre: la part baixa continua ocupada

pel canal de veu (fins a 4 kHz) i, a partir d’aquí, se situa l’espectre de la co-

dificació ADSL (amb la limitació pròpia del parell de fils). El sistema és bi-

direccional: reserva l’espectre baix per a la sortida a la xarxa, i la resta, per

a l’entrada:

Normalment, no es pot arribar als 1,1 MHz que indica la figura, ja que la qua-

litat del parell de fils és molt variable (clima, longitud, edat, etc.), per la qual

cosa s'utilitza una codificació adaptativa: els dos sentits del canal es dividei-

xen en subbandes de 4 kHz independents (DMT, discrete multitone) que es co-

difiquen (en realitat, es modulen) amb procediments gairebé idèntics als

utilitzats pels mòdems tradicionals. Amb això, s’aconsegueixen trenta-dos ca-

nals de sortida i fins a 256 d’entrada, amb una capacitat de 60 kbps cadascun

d’aquests –modulats en QAM (quadrature amplitude modulation), com els mò-

dems telefònics– que, acumulats, donen un màxim de 1,92 Mbps d’entrada i

15,36 Mbps de sortida.

Algunes operadores, ...

... per a aprofitar millor línies dolentes, utilitzen una variant de l’estàndard que permet la transmissió bidireccional amb els dos canals a la mateixabanda.

Aquesta solució, tot i que ne-cessita DCE més cars, permet d’aprofitar línies amb pitjors condicions i/o obtenir-ne velo-citats més altes.


De totes maneres, les millors connexions no aconsegueixen aprofitar correc-

tament els canals superiors i es considera que el límit màxim de sortida és de

8 Mbps. A més, les operadores no acostumen a oferir connexions tant ràpides,

la qual cosa fa que no es pugui assolir el límit teòric.

Els protocols utilitzats dins de l’ADSL depenen de l’operadora i no estan defi-

nits per l’estàndard. Entre els possibles protocols per a l’ADSL tenim l'ATM i el

mateix PPP.

2.3. Accés LAN: el protocol Ethernet

Segurament la simplicitat d’aquest protocol de xarxa, i no les seves prestacions

teòriques, ha fet que sigui el més utilitzat en xarxes d’àrea local pràcticament

des que DEC, Intel i Xerox van establir un estàndard (de facto) per a LAN amb

control d’accés al medi CSMA/CD, basant-se en una arquitectura similar des-

envolupada els anys setanta per Xerox.

Configuració de la targeta de xarxa en mode promiscu

Un dels casos en què una estació no rebutja les trames amb adreces diferents de la seva ésquan l’estació configura la targeta de xarxa en mode promiscu. En aquest mode, la targetainhabilita la seva capacitat de filtratge i llegeix totes les trames que passen per la xarxa. Equipsque normalment funcionen en aquest mode són els ponts (bridges, sistemes destinats a la in-terconnexió de LAN), els analitzadors de trànsit (o analitzadors de xarxa) o els commutadors(switches). No obstant això, gairebé totes les targetes es poden configurar en mode promiscu,cosa que sovint és aprofitada pels lladres d’informació (hackers) per a llegir i copiar informa-ció interessant que viatgi per la LAN (principalment contrasenyes).

2.3.1. Format de la trama Ethernet

La manera de conèixer les principals característiques de la trama Ethernet és

veure els diferents camps que la formen, que són els següents:

Hi ha un principi que es compleix en totes les xarxes d’àrea local: allò

que una estació transmet és rebut per totes les altres. Una estació sap

quan una trama li va destinada perquè llegeix totes les que li arriben i

comprova l’adreça de destinació. Ha de rebutjar totes les trames amb

adreces que no siguin la seva. Però també hi ha excepcions, i en alguns

casos les estacions també han de capturar trames dirigides a adreces es-

pecials (com les multicast i les broadcast).


a) Preàmbul: està format per 64 bits, alternativament 0 i 1. Els dos últims són 11.

Això genera un senyal quadrat que permet als terminals sincronitzar adequada-

ment els rellotges de sincronisme de bit. Els dos últims bits assenyalen on comen-

ça la trama (sincronisme de trama). La seva forma és idèntica en totes les trames.

Nosaltres obviarem la seva presència en la resta de l’explicació, ja que només són

un senyal per a marcar l’inici de la trama.

b) Adreça d’origen: porta l’adreça física o adreça MAC del transmissor de la

trama. Són 48 bits diferents per a qualsevol terminal de la xarxa Ethernet.

c) Adreça de destinació: porta l’adreça MAC del destinatari especificada de

la mateixa manera (en el mateix format) que l’adreça d’origen. En aquest cas,

però, tenim tres tipus d’adreces possibles: unicast, multicast i broadcast.

d) Tipus: indica el tipus de contingut del camp de dades que porta la trama*.

Permet multiplexar diferents protocols dins una mateixa LAN. Xerox actualit-

za regularment la llista de protocols registrats (Xerox Public Ethernet Packet

Type). Més endavant veurem les varietats de protocols d’Ethernet per a conèi-

xer les variants d’Ethernet semicompatibles i saber com afecta la seva coexis-

tència a la manera com Ethernet ha hagut de definir el camp tipus.

Activitat

• Doneu una ullada a la llista dels protocols registrats per a fer-vos una idea de la quan-titat de protocols de xarxa (els superiors a Ethernet) que hi ha.

e) Dades: fa referència al format del camp de dades. Les restriccions sobre la

mena de dades que pot transportar Ethernet són les següents:

• La longitud de les dades ha de ser múltiple de 8 bits, és a dir, Ethernet trans-

porta la informació en bytes. Això no és cap impediment, ja que els bits els

envien sistemes que normalment treballen amb bytes o múltiples de bytes.

• A l’igual de PPP, Ethernet té limitada la longitud màxima d’informació

transportable per la trama (MTU). En aquest cas, l’MTU és de 1.500 bytes.

Aquesta limitació té com a objectiu evitar que una estació monopolitzi la

LAN.

• El camp de dades ha de tenir com a mínim 46 bytes de longitud*. Això és

degut al fet que la trama mínima Ethernet ha de tenir 64 bytes (512 bits).

Es considera que les trames inferiors són resultat de col·lisions i són obvia-

des pels receptors.

Aquest problema no es planteja en la variant d’Ethernet IEEE802.3, ja que

aquest protocol disposa d’un camp de longitud i un altre de farciment

* Les trames que transporten paquets IP porten un 0x0800.

* Per a Gigabit Ethernet, aquest mínim és de 512 bytes.


(padding) que permeten transmetre dades de fins a 1 byte de longitud, tot

i que la longitud que físicament es transmet continua essent de 64 bytes.

Activitat

• Imagineu què passaria si una estació volgués enviar un fitxer d’1 GB per la LAN dinsuna sola trama.

f) CRC: és un codi de redundància cíclica de 32 bits (CRC-32) per a la detecció

d’errors. Abasta tota la trama a excepció del preàmbul. Les trames que no te-

nen un CRC correcte s’ignoren (com les trames de menys de 64 bytes i les que

no són múltiples de 8 bits).

Tipus de medis físics a Ethernet

Ethernet s’ha anat adaptant a les necessitats dels temps ampliant els subestàndards de ni-vell físic. A continuació mostrem una llista dels estàndards més utilitzats:

• 10Base2: abast de 185 m, o 925 m amb repetidors, però amb coaxial prim, flexible ibarat (per això, durant molts anys aquesta xarxa s’ha anomenat Cheapernet). Encaraque actualment es tendeix gradualment a deixar-lo de banda en favor de 10BaseT –queés molt més fiable–, milions de terminals a tot el món estan connectats amb Ethernet-10Base2. S’utilitza sobretot en topologies en bus.

• 10BaseT: connexió en estrella de les estacions a un nus central (concentrador o hub)mitjançant parell trenat; la distància màxima de l’estació al concentrador és de 100 m.La distància màxima entre estacions s’aconsegueix encadenant quatre concentradors,i és de 500 m.

Representa una millora important respecte als estàndards anteriors, ja que se centralit-zen en un sol punt la gestió i el monitoratge de l’estat de tota la LAN. A més, amb lestopologies en bus, el mal funcionament d’una estació podia comportar el bloqueig detota la xarxa. Amb 10BaseT, una mala connexió d’un terminal és detectada pel con-centrador, que simplement la desconnecta i indica que l’enllaç a l’estació està tallat oinactiu (amb un llum vermell, per exemple).

• 10BaseF: similar a 10BaseT, però, en lloc de parell trenat, utilitza fibra òptica (normal-ment multimode), amb què s’aconsegueix un abast molt més gran (fins a 2 km).

• 100BaseT i 100BaseF: similars a 10BaseT i 10BaseF, respectivament, però funcio-nen a 100 Mbps. A causa del protocol de control d’accés al medi CSMA/CD, l’abastes redueix molt (100 m entre estació i concentrador, sense possibilitat d’encadenarconcentradors).

• Gigabit Ethernet: les variants més comunes són 1000 BaseT, sobre cablejat de courecategoria 5 (equivalent al necessari per a 100 BaseT) i 1000 BaseSX, sobre fibra. Té elmateix abast que 100BaseT, 100 m.

• 10 Gigabit Ethernet: actualització d’Ethernet per al segle XXI.

Variants del protocol Ethernet

Des de mitjan anys vuitanta, Ethernet ha conviscut amb una variant similar anome-nada IEEE802.3 o ISO8802.3. Són estàndards establerts per organitzacions reconegudes(l’IEEE i l’ISO) dedicades a la normalització (estàndard de jure). Durant un temps es vapensar que l’IEEE802.3 acabaria substituint l’Ethernet original (també anomenada Et-hernet-DIX, en honor a DEC, Intel i Xerox), que no podia transmetre trames arbitràri-ament petites. Els protocols que treballen sobre Ethernet-DIX coneixen aquestalimitació i omplen la trama fins a ocupar els 46 bytes d’informació.

L’IEEE802.3 introdueix un camp de longitud (en la mateixa posició en què Ethernetté el camp de tipus) que permet saber quants bytes útils conté el camp de dades. Si lalongitud no arriba als 46 bytes mínims, s’omple amb bytes (indefinits) fins a arribar-hi. El receptor només ha de llegir el camp de longitud per a extreure’n la informacióvàlida. El concepte de tipus d’Ethernet (és a dir, la coexistència de diferents protocols


per sobre d’Ethernet/IEEE802.3) es delega a un protocol associat: l’IEEE802.2, proto-col d’enllaç que es pot fer servir en l’IEEE802.3 i en altres protocols de LAN i que téunes funcions similars a les de l’HDLC.

Com que en el nivell físic ambdós estàndards són totalment compatibles, ens podríempreguntar si poden coexistir trames Ethernet-DIX i IEEE802.3 dins una mateixa LAN. Laresposta és que sí i que no alhora.

Fixeu-vos que tots els camps de la trama Ethernet i de la 802.3 són del mateix format ivolen dir el mateix, a excepció del camp de tipus (Ethernet) i de longitud (802.3). Els po-dríem distingir sempre que vigiléssim que cap tipus Ethernet no fos equivalent a una lon-gitud vàlida de 802.3. Els tipus amb valors inferiors a 1.500 (0x5DC en hexadecimal) espoden confondre amb longituds vàlides.

Això, òbviament, no es podia tenir en compte en l’Ethernet-DIX original, ja que és ante-rior a l’IEEE802.3. Per això va aparèixer una addenda a la norma Ethernet-DIX, conegudacom a Ethernet-DIX-II, que elimina els identificadors de protocols per sota de 0x0600(1.536 en decimal). Avui dia sovint dins una mateixa LAN trobem trames Ethernet-DIX-II i trames IEEE802.3.

L’IP pot anar sobre qualsevol dels dos estàndards, encara que gairebé ningú no tria la pos-sibilitat d’encapsular-lo sobre l’IEEE802.3. El parell de protocols IEEE802.3 + 802.2 s’uti-litza en alguns dels sistemes operatius de xarxa apareguts els anys vuitanta com, perexemple, l’IPX de Novell i el NETBEUI de Microsoft.

2.3.2. Adreces LAN

Les adreces LAN estan dividides en diferents camps, com es pot veure en la fi-

gura següent:


La meitat menys significativa de l’adreça (els bits del 2 al 23), assignada per

l’IEEE a cada fabricant de manera fixa, és l’OUI*. Aquest, quan fabrica les tar-

getes, programa (en ROM) l’adreça completa, que està formada per l’OUI més

una part variable que el mateix fabricant assigna individualment per a cada

targeta: l’OUA**.

Hi ha dos bits de l’OUI que sempre són zero quan es tracta de l’adreça d’origen:

el bit multicast (M) i el bit local (L). El bit L no s’utilitza gairebé mai i, per tant,

el considerarem sempre a zero.

Tant l’adreça de destinació com la d’origen de la trama tenen el mateix for-

mat, amb l’única diferència que l’adreça de destinació també pot ser de tipus

multicast (bit M = 1). En aquest cas, el número que porta no es refereix a una

estació en particular, sinó que s’adreça a un grup d’estacions. Cadascuna de

les estacions coneix el grup o grups als quals està adscrita. Generalment, ca-

dascun dels grups es refereix a grups d’estacions que comparteixen una ma-

teixa aplicació o un mateix protocol. En l’IP, l’únic grup multicast Ethernet

rellevant és el broadcast.

Representació d’una adreça Ethernet

Sobre paper, les adreces LAN s’escriuen en hexadecimal, separant els bytes amb dos puntsi escrivint primer el byte menys significatiu, per exemple:

08:00:00:10:97:00

El primer byte (que és el menys significatiu) és sempre divisible per quatre en adreces nomulticast que tenen els bits M i L a 0.

El grup broadcast és especial, en el sentit que, per defecte, totes les estacions hi

pertanyen; per tant, és una manera de difondre informació simultàniament a

totes les estacions. El concepte de broadcast no és exclusiu d’Ethernet, sinó que

és comú a molts altres protocols de LAN i WAN (també a l’IP). Posar tots els

bits de l’adreça a 1 és la manera més habitual de representar l’adreça broadcast,

i és la que utilitzen les LAN (FF:FF:FF:FF:FF:FF).

* OUI és la sigla d’organizationalunique identifier.

** OUA és la sigla d’organizationalunique address.

Trames Ethernet multicast

No és del tot cert que l’únic grup multicast Ethernet relle-vant sigui el broadcast.La xarxa Internet disposa del protocol IGMP (Internetgroup multicast protocol),que també treballa sobre tra-mes Ethernet multicast.


3. L’IP (Internet protocol)

L’IP és del tipus best effort (podríem traduir-ho com ‘amb la millor intenció’, o ‘qui

fa el que pot no està obligat a més’). Evidentment, quan utilitzem una xarxa no

sempre ens podem conformar amb aconseguir que la informació arribi si la xarxa

pot. És aquí on intervé el TCP, que és responsable de fer que la informació arribi

en les condicions de fiabilitat desitjades.

Diferents filosofies dels protocols d’Internet

Hem vist protocols amb una filosofia similar a la del best effort: els protocols de LAN, comEthernet, etc. Hi ha detractors acèrrims i també defensors incondicionals d’aquesta filosofia,i segurament tots dos grups tenen una part de raó. La xarxa X.25 és un exemple gairebé opo-sat a aquesta filosofia que dóna als seus usuaris uns nivells de fiabilitat i flexibilitat raonable-ment elevats, gràcies a la utilització de la commutació de paquets amb circuits virtuals.

Certament, la història dóna la raó als defensors de la filosofia best effort, ja que l’X.25 ac-tualment es considera gairebé una tecnologia obsoleta, mentre que l’IP està de moda. Lesraons s’han de buscar, com sempre, en el cost. La filosofia IP permet implementar xarxesamb un cost mínim: penseu que el TCP només s’ha d’implementar als terminals de la xar-xa, i no en els nodes de commutació. Per tant, els nodes de commutació IP són molt méssimples que els d’X.25.

3.1. Adreces IP

Abans d’entrar en l’estudi del protocol en si, destacarem un punt important,

tant de l’IP com de la xarxa Internet: les adreces.

Per a representar una adreça, se sol escriure els 4 bytes en decimal i separats

per punts. Per exemple:

147.83.153.100

IP i TCP són un parell de protocols ben compenetrats. L’IP és un pro-

tocol d’interconnexió de xarxa orientat a datagrama. Per tant, no dis-

posa del concepte de circuit virtual, de manera que no és capaç de

recuperar trames perdudes, ni de garantir que les trames es lliuraran

en l’ordre correcte –ja que els paquets poden seguir camins diferents

i, per tant, patir retards diferents–, ni que el ritme de recepció sigui

l’adequat perquè el receptor processi convenientment les dades.

Les adreces IP són úniques per a cada màquina. Per a ser precisos, cada

adreça és única per a cadascuna de les interfícies de xarxa IP de cada mà-

quina. Si una màquina té més d’una interfície de xarxa, necessitarà una

adreça IP per a cadascuna. Les adreces IP tenen una longitud de 32 bits

(4 bytes).

Vegeu el protocol TCP a l’apartat 8 d’aquest mòdul didàctic.

Adreces Ethernet contra adreces IP

Curiosament, les adreces IP són més curtes que les Ether-net. Aquest error pot ser el talód’Aquil·les d’Internet a princi-pis d’aquest segle a causa del límit que imposa al nombred’estacions que s’hi poden connectar.

Per a completar aquesta informació,podeu consultar l’annex 4 d’aquest mòdul didàctic.


Per a aconseguir que no hi hagi cap adreça igual, Internet disposa d’una orga-

nització anomenada Internet Network Information Center o InterNIC que es de-

dica a aquesta tasca. Actualment, aquesta entitat delega la responsabilitat de

l’assignació d’adreces a entitats regionals. Les adreces s’assignen per grups o

xarxes, no individualment.

Els tipus de xarxes que tenen cabuda a Internet es distingeixen per la quantitat

d’estacions que poden suportar, i són els següents:

1) Les xarxes de classe A reserven el primer byte com a identificador de xarxa i

els tres restants com a identificadors d’estació. El primer bit del primer byte val 0;

per tant, a Internet només hi pot haver 128 xarxes de classe A (amb 224 estacions

cadascuna com a màxim). Fa molt temps que ja no en queda cap per assignar.

2) Les xarxes de classe B tenen 16 bits per a cada camp. Els dos primers bytes

de l’identificador de xarxa valen 10; per tant, hi ha 16.384 (214) xarxes de, a

tot estirar, 65.536 estacions. De classe B, no en queda cap per assignar.

3) Finalment, les xarxes de classe C reserven 24 bits per a l’identificador de

xarxa (amb els tres primers bits valent 110) i els 8 restants són per a l’identifi-

cador d’estació.

Una vegada coneixem una adreça, és fàcil saber si correspon a una xarxa de

classe A, B o C, si sabem que les codificacions es fan com en la figura següent:

L’adreça comentada abans (147.83.153.100) és de classe B. Fixeu-vos, també,

que en la figura anterior no hi ha cap adreça que comenci per tres uns. Aques-

tes adreces (anomenades classe D i classe E) són de propòsit especial i no s’as-

signen a màquines concretes.

CIDR (Classless Inter-Domain Routing)

L’espai d’adreces s’està exhaurint a marxes forçades, i si bé hi ha tècniques relacionadesamb la seguretat que ajuden a mitigar aquest problema, per exemple, NAT que s’explicaa l’annex 4 d’aquest mòdul didàctic, el fet d’utilitzar el concepte de “classe” ha agreujatel problema: algunes corporacions que han reservat una xarxa classe A o B, però nomésn’han aprofitat una petita part, han deixat sense un bon tros de l’espai d’adreces a la restade Internet. Actualment, enlloc de donar xarxes classe C (de les altres, ja no en queden)el que es fa es donar grups més grans (tècnicament, se’n podrien donar de més petites,però no es fa) limitats per màscares intermitges entre la classe B i la C. Per exemple, sialgú vol una xarxa d’un miler d’adreces necessita quatre xarxes de classe C. Enlloc de do-nar-li aquestes quatre xarxes independents, se li dóna una màscara de 22 bits: en queden10 per a adreces de terminal, la qual cosa permet 1.024 terminals.

El primer byte

El primer byte ho és en el sentitque és el primer que s’envia a la xarxa. Com que aquest és considerat el byte de més pes, es diu que el protocol TCP/IP téordenació big endian.

El nombre real de xarxes

En realitat, hi ha menys xarxes i menys estacions de les que hem calculat aquí, atès que al-gunes adreces estan reservadesper a usos especials, com ani-rem veient.

Per a completar aquesta informació,podeu consultar l’annex 2 d’aquest mòdul didàctic.


3.1.1. Màscares de xarxa

Quan un administrador de sistemes rep l’assignació de gestionar un conjunt

d’adreces, pot necessitar configurar internament diferents LAN amb aquest

conjunt. És per això que el mecanisme per a distingir diferents xarxes (LAN)

entre si no es pot basar exclusivament en els bits identificadors de classe que

hem comentat anteriorment.

El concepte màscara és cabdal per a la comprensió del funcionament de les

xarxes IP, permet a una estació decidir si la destinació a la qual ha de transme-

tre un paquet es troba dins la mateixa xarxa d’àrea local que ella o si, per con-

tra, es troba en una LAN remota i, per tant, n’ha de delegar la transmissió a

algun equip de la seva mateixa LAN (l’encaminador) perquè s’encarregui de fer

arribar el paquet a la seva destinació.

Totes les estacions d’una mateixa xarxa d’àrea local han d’utilitzar el mateix

identificador de xarxa i totes les estacions han de tenir la mateixa màscara.

Adreces d’estacions connectades a la mateixa xarxa

Si tenim dues estacions amb les adreces 147.83.153.100 i 147.83.153.200, podemdeduir que estan interconnectades directament (per una LAN) si la màscara de la sevaxarxa és 255.255.255.0, i també deduirem que no estan connectades amb la mateixaLAN si la màscara és, per exemple, 255.255.255.128.

Notació alternativa de la màscara

Una notació alternativa és donar el nombre de bits 1 de la màscara. Així, doncs, la màscara255.255.255.0 és una màscara de 24 bits i la 255.255.255.128 és una màscara de 25 bits.

A vegades, podem veure una adreça amb l’afegit de la màscara; per exemple:

147.83.153.100/24

Aquesta notació, però, només és útil per a màscares amb 1 consecutius.

3.1.2. Adreces de propòsit especial

Hi ha diferents adreces especials. Nosaltres exposarem a continuació només

les més importants:

• Adreça de xarxa: les adreces de xarxa s’expressen amb l’adreça que tindria

qualsevol estació seva i amb tots els bits de l’identificador d’estació a zero.

La màscara de xarxa és el mecanisme que ens permetrà aconseguir

més flexibilitat. Mitjançant una màscara de 32 bits, definirem els bits

que identifiquen la xarxa (bits a 1) i els que identifiquen l’estació

(bits a 0). Normalment els bits 1 i els 0 són consecutius, però no ne-

cessàriament.

Tot seguit definim de nou el concepte identificador de xarxa, adaptant-

lo a la màscara: l’identificador de xarxa és la porció d’adreça IP que en-

caixa amb els bits 1 de la màscara.


Per exemple, la xarxa en què es troba l’estació 147.83.153.100/24 és la

147.83.153.0/24 i la xarxa en què es troba l’estació 147.83.153.200/25

és la 147.83.153.128/25.

• Adreça 127.0.0.1 (loopback): adreça no vàlida per als paquets IP. El progra-

mari de xarxa la utilitza per a transmetre paquets a la màquina local (de fet,

els paquets no són transmesos, sinó que són lliurats a la destinació pel ma-

teix sistema operatiu). En realitat, els tres bytes de l’identificador d’estació

són irrellevants*. Aquesta adreça només té interès a l’hora de programar

aplicacions; els sistemes de xarxa no veuran mai que cap paquet viatgi pel

cable amb aquesta adreça com a origen o destinació.

• Adreça 255.255.255.255 (broadcast): només és vàlida com a adreça de

destinació d’un paquet. S’utilitza per a transmetre paquets a totes les esta-

cions localitzades dins la mateixa LAN que la màquina d’origen. Hi ha una

versió equivalent, que és el broadcast dirigit. En aquest segon cas, el paquet

és rebut per totes les màquines d’una LAN especificada per l’identificador

de xarxa. L’identificador d’estació ha de ser tot 1.

Broadcast local i remot

Per a enviar un broadcast a la xarxa 147.83.153.0 amb la màscara 255.255.255.0 (o147.83.153.0/24) podem fer servir l’adreça 255.255.255.255 si som dins la xarxa147.83.153.0 o bé la 147.83.153.255 si som en una estació remota. El primer cas, l’ano-menem broadcast local, i el segon, broadcast remot.

Per tant, amb 16 bits d’estació no tenim 216 estacions possibles, sinó 216− 2. La que tétots els bits a 0 i la que els té a 1 no són adreces vàlides per a estacions.

3.2. El format del paquet IP

* Així, l’adreça 127.0.3.87 és equivalent a la 127.0.0.1.

Vegeu altres adreces de propòsit especial en l’Annex 2 d’aquest mòdul didàctic.


A continuació, descrivim els camps que formen el paquet IP:

• Versió: sempre val quatre (0100), pels paquets de la versió actual (IPv4).

• Longitud de la capçalera: dóna la longitud de la capçalera en paraules de

32 bits (4 bytes). Per tant, la capçalera ha de tenir un nombre de bytes múl-

tiple de 4. A més, limita la longitud de la capçalera a 60 bytes (15 · 4), ja

que 15 és el màxim que es pot expressar amb quatre dígits binaris. Si no hi

ha camp d’opcions, la capçalera té 20 bytes; per tant, el camp en aquest cas

valdria 5 (5 · 4 bytes = 20 bytes).

• Tipus de servei: aquest camp es troba dividit en diversos subcamps. Permet

demanar un tracte especial per al paquet i rarament s’implementa.

• Longitud total del paquet: dóna la longitud total del paquet (capçalera in-

closa) en bytes. Com que aquest camp és de 16 bits, un paquet IP no pot

tenir més de 65.535 bytes (216 − 1).

Tipus de servei

El camp tipus de servei permet definir dues variables:• El nivell de prioritat (de l’1

al 8).

• El tipus de qualitat aplicable al contingut (retard baix, velocitat alta, fiabilitat alta, cost baix...).


• Identificació del paquetIdentificació del paquet: conté un identificador que és diferent per a cada

paquet que genera l'estació.

• Indicadors (flags) i posició d’aquest fragment: aquests camps permeten

gestionar la fragmentació de paquets.

• Temps de vida o TTL (Time To Live): indica el nombre màxim d’encami-

nadors que pot travessar el paquet. S’utilitza per a evitar que un paquet pu-

gui quedar donant voltes indefinidament dins la xarxa en cas que hi hagi

algun problema en lliurar-lo. Cada encaminador decrementa el camp en

un. Quan un d’ells detecta un paquet amb TTL = 1, l’elimina i envia a qui

l’ha emès un missatge d’error mitjançant un missatge ICMP.

• Protocol: identifica el tipus de protocol que transporta el paquet. Els valors

més comuns dels diferents tipus de protocols són els següents:

TCP 6

UDP 17

ICMP 1

Vegeu la fragmentació en el subapartat 3.2.1 d’aquest mòdul didàctic.


• Checksum: fa el control d’errors a la capçalera. El camp de dades no queda

protegit per cap checksum; és responsabilitat dels usuaris de l’IP (TCP, UDP,

etc.) el control dels possibles errors en el seu contingut.

Algorisme de càlcul del checksum

El checksum (o comprovació per addició) és bàsicament la suma aritmètica dels bytes dela capçalera agrupats de dos en dos (si el resultat necessita més de 16 bits, se sumen elsbits sobrants al mateix resultat).

Aquest algorisme, si bé és fàcil i ràpid de calcular, no es caracteritza perquè tingui unesgrans qualitats per a la detecció d’errors. Això, sumat al fet que el contingut de l’IP no téchecksum i a altres factors (com ara que molts sistemes no calculen el checksum dels pa-quets UDP), demostra que en el món d’Internet no hi ha un interès especial per la detec-ció d’errors. Sovint aquest ha estat un argument al qual s’han agafat els detractors delprotocol IP per a atacar-lo.

La detecció d’errors dins el camp d’informació és responsabilitat de qui entra la informa-ció. Els usuaris més habituals de l’IP són els protocols TCP, UDP i ICMP, i tots protegeixenla informació amb un camp addicional de checksum.

Activitat

• Busqueu errors possibles que passarien inadvertits a l’algorisme checksum.

• Adreça d’origen IP: identifica la màquina que ha generat el paquet.

• Adreça de destinació IP: identifica la màquina a la qual va destinat el paquet.

Vegeu una implementació en llenguatge C de l’algorisme checksum en l’annex 3 d’aquest mòdul didàctic.


• Opcions: hi ha diferents serveis assignats a aquest camp, però normalment

no s’utilitzen. En comentarem alguns quan parlem de l’ICMP. Sigui com

sigui, la longitud total està limitada a 40 bytes (15 · 4 − 20).

3.2.1. Fragmentació

Els paquets IP van sempre inserits en trames de nivell d’enllaç o MAC. Uns

exemples que ja hem vist són els protocols PPP i Ethernet.

Una estació, quan transmet un paquet IP, coneix l’MTU de la seva interfície

de xarxa, i està restringida a transmetre paquets IP que es puguin transmetre

per la seva interfície a la xarxa.

Si el paquet passa per un encaminador connectat a una xarxa amb una MTU in-

ferior a la mida del paquet, cal fragmentar-lo. Els fragments resultants de l’opera-

ció són paquets com qualsevol altre, però que tenen les característiques següents:

• Tots els fragments que provenen d’un paquet fragmentat tenen el mateix

identificador de paquet en les respectives capçaleres IP.

• Tots els fragments indiquen amb el camp posició d’aquest fragment a quin

byte correspon el primer byte de dades del fragment dins el paquet origi-

nal. El primer fragment té un zero en aquest camp.

• El bit + del camp indicadors és 1 en tots els fragments a excepció de l’últim,

que, per això se sol anomenar n’hi ha més.

La resta de camps de la capçalera es copia íntegrament del paquet original als

fragments que resulten de la fragmentació, excepte l’indicador de longitud del

paquet i el checksum, que s’han de tornar a calcular.

Exemple

En una Ethernet, el paquet mà-xim que pot transmetre una estació és de 1.500 bytes.


En principi podríem suposar que, quan els fragments tornen a una xarxa amb

una MTU suficient, l’encaminador que els rep els reunifica. Però no es fa així,

en primer lloc perquè la llei no escrita d’Internet segons la qual l’encaminador

ha de fer la mínima feina necessària no es compliria; en segon lloc (i més im-

portant), perquè ningú no garanteix que tots els fragments segueixin el mateix

camí. L’única capaç de recompondre els fragments és l’estació de destinació.

L’estació de destinació, quan rep un fragment, reserva prou memòria per a allotjar

el paquet IP més gran possible (65.535 bytes), ja que no té manera de saber quina

és la mida del paquet original. A partir d’aquí, engega un temporitzador* i comen-

ça a recol·lectar els fragments segons el seu identificador. Quan s’han rebut tots

els fragments es lliura el paquet a l’aplicació (protocol) corresponent. En cas que

el temporitzador salti, es descarten tots els fragments arribats fins aquell moment.

El nivell superior (TCP) és el responsable de demanar una retransmissió quan con-

vingui, ja que l’IP no té cap mecanisme per a demanar-la.

Paquets no fragmentables

Dins el camp indicadors hi ha dos bits més que no hem comentat: l’un no es fa servir il’altre, el DF (Don’t Fragment), especifica que el paquet no s’ha de fragmentar. Si calguésfragmentar-lo, el paquet seria descartat i s’enviaria un missatge ICMP indicant l’error al’estació originadora del paquet. Usualment, s’activa el bit DF només quan la fragmen-tació no és desitjable com, per exemple, quan enviem paquets a estacions amb la pilaTCP/IP implementada en ROM, ja que llavors s’implementa només una mínima partde la funcionalitat de TCP/IP.

3.3. Encaminament i encaminadors

Les atribucions principals dels encaminadors són interconnectar dues o més sub-

xarxes IP i encarregar-se d’encaminar el trànsit destinat a estacions remotes.

Cada encaminador de la xarxa Internet ha de ser capaç de decidir (en una frac-

ció de segon) a on ha de dirigir un paquet basant-se exclusivament en l’adreça

de destinació, i en el coneixement que té de la xarxa i de la seva posició (la de

l’encaminador) dins Internet. De fet, cada encaminador no decideix la ruta

sencera del paquet, sinó només el tros de ruta en què participa: el salt (hop)

següent. Entre l’origen i la destinació tenim un nombre variable de salts, i en

cadascun participen un parell de encaminadors (l’emissor i el receptor del pa-

quet) a excepció del primer i l’últim, en què participen les estacions emissora

i transmissora, respectivament. Les connexions entre encaminadors, o bé en-

tre encaminador i estació terminal, les componen LAN o enllaços punt a punt.

* Aquest temporitzador permet detectar la pèrdua d’un fragment

pel camí i, per tant, la pèrdua de la memòria reservada.


En la figura anterior, podem veure un paquet IP que travessa tres xarxes d’àrea

local. En cadascuna el paquet va encapsulat dins una trama d’un tipus adient a

la subxarxa que travessa (en el dibuix podrien ser tres LAN Ethernet). Les adreces

d’origen i de destinació del nivell LAN en cada tram són diferents. En canvi,

l’adreça d’origen i la de destinació de cada paquet IP no varien. La situació plan-

teja dos problemes, i per a resoldre’ls cal fer els passos següents:

• Esbrinar quina és la correspondència entre adreces IP i MAC (només en els

casos en què l’enllaç entre els encaminadors sigui una LAN). Això ens per-

metrà enviar els paquets IP a un encaminador malgrat que el paquet IP no

en tingui l’adreça. El mapatge IP-MAC s’efectua de manera automàtica mit-

jançant el protocol ARP.

• Decidir en cada moment quin és l’encaminador següent (el salt següent).

3.3.1. La taula d’encaminament

L’encaminament es fa a partir de taules d’encaminament que disposen d’in-

formació limitada però suficient per a permetre la interconnexió de totes les

subxarxes que componen Internet. Cada equip connectat a una xarxa IP ne-

cessita una taula d’encaminament.

Taules d’encaminament

Aquestes taules s’introdueixen dins l’encaminador normalment mitjançant un terminalque s’hi connecta directament (consola). També hi ha protocols que permeten que lestaules s’actualitzin automàticament quan es detecten canvis de topologia. Els més utilit-zats són el RIP (routing information protocol) i l’OSPF (open shortest path first).

L’encaminador decideix la ruta dels paquets consultant la seva taula d’enca-

minament. Les estacions terminals també necessiten una taula d’encamina-

ment, encara que només sigui per a poder descobrir si s’estan comunicant amb

una estació local de la LAN (i, per tant, s’hi poden comunicar directament) o

si el paquet IP ha d’anar a una estació remota (connectada a una altra LAN) i,

per tant, l’han de deixar en mans de l’encaminador.

Taula d’encaminament d’una estació amb una única interfície

Comencem estudiant la taula d’encaminament d’una estació connectada a

una LAN (adreça 147.83.153.103/24) amb una única targeta Ethernet. Nor-

malment, una taula d’encaminament disposa també d’informació sobre les

“qualitats” de cadascuna de les rutes descrites, que no apareixen en l’exemple:

Taula d’encaminament de l’estació

Adreça Màscara Encaminador Interfície

1 147.83.153.103 255.255.255.255 127.0.0.1 Loopback

2 127.0.0.0 255.0.0.0 127.0.0.1 Loopback

Vegeu el protocol ARP en l’apartat 4 d’aquest mòdul didàctic.


Aquesta és una taula típica que podem trobar en una estació connectada a In-

ternet. Les files de la taula o regles es consulten no en l’ordre en què la coman-

da route ens els presenta, sinó en ordre de màscara decreixent (en primer lloc

les entrades amb 32 bits, etc.). De les entrades que formen la taula, en cal dir

el següent:

La primera entrada i la segona permeten transmetre paquets IP a les adreces

147.83.153.103 i a totes les adreces que comencin per 127 (fixeu-vos en la

màscara de les dues entrades). En tots dos casos els paquets s’envien a la inter-

fície virtual loopback (la interfície amb què es coneix l’ordinador local des del

mateix ordinador local). Cap dels paquets que s’encamini amb alguna

d’aquestes dues regles no sortirà mai a la xarxa: serà curtcircuitat directament

pel sistema operatiu i serà lliurat al procés de destinació sense que arribi mai a

cap targeta de comunicacions.

• La tercera entrada, la prendran tots els paquets destinats a la xarxa local.

El camp encaminador és el mateix que l’adreça local, la qual cosa vol dir

que no es delegarà la seva transmissió a cap encaminador.

• La quarta entrada té una importància relativa, indica que els broadcasts IP

es restringiran a la xarxa local.

• La cinquena entrada (0.0.0.0/0) permet a l’estació comunicar-se amb es-

tacions remotes. Fixeu-vos que la màscara no té cap bit a 1. Aquesta és la

ruta per defecte. L’encaminador establert per a accedir a estacions remotes

queda identificat en la taula amb l’adreça 147.83.153.5.

Tota aquesta informació es calcula a partir de tres dades que s’introdueixen en

la configuració de xarxa:

1) L’adreça local (en l’exemple: 147.83.153.103).

2) La màscara de la LAN local (en l’exemple: 255.255.255.0).

3) L’adreça de l’encaminador (en l’exemple: 147.83.153.5).

En casos més complexos (més d’una interfície d’accés a Internet, més d’un en-

caminador a la xarxa local, etc.), la informació s’haurà de modificar amb la co-

manda route. També hi ha altres mecanismes que no requereixen la

intervenció humana i que permeten descobrir encaminadors que no s’han

configurat prèviament mitjançant el protocol ICMP.

Taula d’encaminament de l’estació


3 147.83.153.0 255.255.255.0 147.83.153.103 ether0

4 255.255.255.255 255.255.255.255 147.83.153.103 ether0

5 0.0.0.0 0.0.0.0 147.83.153.5 ether0

Interfície

Una interfície és una targeta de connexió física a la xarxa. Exemples d’interfície serien una targeta Ethernet (per exemple, l’Ether0) o un port sèrie. En l’exemple veiem una interfície loopback, que és un cas especial, com veurem en el text. Per a saber quines interfícies hi ha disponibles en un siste-ma, en UNIX o en Windows NTnomés cal invocar la comanda:$ ifconfig,i en Windows 95: C:> winipcfg

La comanda route

En una estació podem consul-tar i modificar la taula d’enca-minament utilitzant la comanda route. Per a visualit-zar-la en UNIX, podem fer: $ routeEn MSWindow: C:> route printPer a afegir o treure entrades podem fer servir la comanda route amb els paràmetres add o del.


Activitat

• Mireu la taula d’encaminament del vostre ordinador mitjançant la comanda route.Consulteu l’ajuda disponible en el sistema operatiu (en UNIX feu man route, i enMSWindows, route/?).

En un encaminador, les taules d’encaminament tenen més entrades que les

d’una estació, però el funcionament és el mateix que hem vist en el cas ante-

rior. Vegeu-ne una que connecta la xarxa 147.83.153.0/24 amb l’exterior mit-

jançant la xarxa 147.83.30.0/24:

Pràcticament no hi observem res de nou. Simplement s’han duplicat les entra-

des específiques d’interfície. L’encaminador també té una entrada per defecte.

En aquest cas, tot el trànsit no destinat a les dues xarxes a les quals està direc-

tament connectat s’encamina cap a un altre encaminador situat a la xarxa

147.83.30.0 (el 147.83.30.1).

Activitat

• Penseu si tots els encaminadors d’Internet tenen una ruta per defecte i raoneu-ho. Ima-gineu què passa quan enviem un paquet a una estació d’una xarxa inexistent (perexemple a l’estació 10.0.1.1).

Taula d’encaminament de l’encaminador


1 147.83.153.5 255.255.255.255 127.0.0.1 Loopback

2 147.83.30.2 255.255.255.255 127.0.0.1 Loopback

3 127.0.0.0 255.0.0.0 127.0.0.1 Loopback

4 147.83.153.0 255.255.255.0 147.83.153.5 ether1

5 147.83.30.0 255.255.255.0 147.83.30.2 ether0

6 255.255.255.255 255.255.255.255 147.83.153.5 ether1

7 0.0.0.0 0.0.0.0 147.83.30.1 ether0

Vegeu la manera de representar les adreces de xarxes inexistents en l’annex 2 d’aquest mòdul didàctic.


4. L’ARP (address resolution protocol)

L’ARP és l’encarregat de fer la resolució automàtica del mapatge entre adre-

ces MAC.

Quan efectuem la transmissió d’un paquet entre dues estacions locals d’una

mateixa LAN, ho fem indicant a l’aplicació corresponent només l’adreça IP.

Per exemple, si des de 147.83.153.103 ens volem connectar a 147.83.153.100,

farem el següent:

El sistema identifica l’adreça física de destinació de les trames a les quals han

d’anar els paquets IP que genera l’aplicació telnet* mitjançant una taula que

mapa les adreces d’un nivell (IP) amb les de l’altre (MAC). Aquesta taula s’ano-

mena cau ARP. Vegem-ne un exemple:

Mitjançant l’única interfície del sistema, es coneix el mapatge MAC-IP de la

mateixa targeta de xarxa (entrada 1) i el d’una altra màquina (entrada 2). Si bé

aquesta taula es pot modificar manualment (amb la comanda arp), el més

normal és que aquestes entrades apareguin automàticament, per obra de

l’ARP.

L’ARP entra en funcionament en el moment en què el nivell necessita trans-

metre un paquet IP destinat a una adreça IP de la qual es desconeix el mapatge

MAC. En l’exemple de connexió anterior (telnet), i utilitzant també la cau ARP

que hem mostrat, abans que el protocol telnet enviï un sol paquet, el sistema

necessita esbrinar l’adreça MAC. Dins la cau ARP, no hi ha aquesta entrada;

per tant, cal actualitzar-la.

Actualització de la cau ARP

L’ARP i la cau ARP es poden considerar com un servei únic que, des del punt de vista del’IP, presenta un servei: tornar una adreça MAC a partir d’una adreça IP. El subsistemabuscarà dins la cau i tornarà el contingut que hi trobi. En cas que faci falta un valor queno hi sigui, s’endegarà el procés de recerca de la informació mitjançant el protocol ARP,per a actualitzar la cau i atendre la petició.

$ telnet 147.83.153.100

* telnet és una aplicació d’ús comú per a l’accés a estacions

remotes.


L’ARP es basa en dos únics paquets que van encapsulats directament sobre tra-

mes Ethernet (tipus Ethernet: 0x0806):

• La petició ARP: transporta l’adreça IP de la qual es vol conèixer l’adreça

MAC. Com que precisament no se’n coneix l’adreça MAC, la trama ha de

dur com a adreça de destinació l’adreça broadcast (FF:FF:FF:FF:FF:FF). Totes

les estacions locals de la LAN processen aquestes trames, però només la

posseïdora de l’adreça IP demanada ha de contestar. Per tal de minimitzar

els accessos a la LAN, el receptor de la petició ARP també actualitza la seva

cau (si li cal) amb el mapatge @IP - @MAC de l’originador de la petició.

• La resposta ARP: comunica l’adreça MAC a qui l’ha demanat (és el paquet

resposta de l’anterior). De fet, el format és gairebé irrellevant, perquè l’únic

interessant és la trama MAC i, particularment, la seva adreça d’origen.

La taula ARP s’anomena cau perquè, de fet, actua com una memòria auxiliar

que evita la consulta de la informació a la LAN mentre se’n tingui una còpia

local. Pot semblar que la consulta ARP no hauria de ser gaire freqüent, ja que

al cap de cert temps tota la informació es trobaria dins la cau. Cal saber, però,

que les entrades caduquen al cap d’un període de temps relativament breu (en-

tre un i uns quants minuts, segons el sistema).

Activitat

• Imagineu el que podria passar si les entrades de la cau ARP no caduquessin. Us pot ser-vir d’ajut pensar en la reconfiguració d’adreces.

Alguns usos alternatius d’interès de l’ARP són els següents:

• ARP innecessari (gratuitous-ARP): s’utilitza quan una estació arrenca per a sa-

ber si hi ha alguna altra estació que està fent servir la seva mateixa adreça IP.

Mitjançant una petició ARP, pot preguntar qui té la seva adreça IP (un con-

flicte d’aquest tipus podria deixar les dues estacions “fora de combat”).

• ARP subsidiari (proxy-ARP): es fa servir en situacions en què un encamina-

dor divideix una subxarxa sense que les estacions ni l’encaminador que els

connecta a Internet modifiquin la seva màscara. Aquesta tècnica, tot i no

ser gaire ortodoxa, s’aplica freqüentment quan l’encaminador d’una xarxa

privada es connecta a Internet mitjançant una xarxa aliena (un proveïdor

d’Internet, per exemple).

Activitats

• En l’apartat 3.3 hem deixat una pregunta sense contestar: com pot una estació enviarun paquet a una estació remota (per exemple, seguint la ruta per defecte de l’encami-nador) si el paquet no pot portar l’adreça MAC de l’estació de destinació? Feu una llistadels paquets que viatgen per la xarxa i penseu quines són les entrades de la cau ARPque hi intervenen.

• Consulteu la cau ARP d’algun sistema que tingueu a l’abast (UNIX o MS) mitjançantarp -a. Comproveu quines opcions té disponibles.

Lecturescomplementàries

No mostrarem el format dels paquets ARP, atès que no aporten gaire més informació. Podeu trobar el format del paquet i els usos alternatius de l’ARP en les obres següents:

D.E. Comer (1995). Internetworking with TCP/IP(volum 1: “Principles, Protocols and Architecture”).Hertfordshire: Prentice Hall.

W.R. Stevens (1994). TCP/IP Illustrated (volum 1: “The Protocols”). Wilmington: Addison-Wesley.


5. L’ICMP (Internet control message protocol)

5.1. Missatges ICMP

Els missatges ICMP viatgen dins de paquets IP (al contrari del que ocorria amb

els paquets ARP), en el camp de dades amb el camp protocol de la capçalera

igual a 1. El format del missatge presentat en la figura següent ens facilitarà

l’estudi dels diferents usos del paquet ICMP:

Hi ha tretze tipus de missatges ICMP en ús actualment, i cap a una trentena de

subtipus identificats amb el camp codi.

La qüestió de si l’ICMP és un protocol, o si més aviat és una eina que

utilitza el protocol IP per a notificar errors, genera molta polèmica. El

cert és que l’ICMP és el mecanisme bàsic per a la gestió de les diferents

incidències que poden ocórrer en una xarxa IP.

Tipus Codi Descripció Classe

0 0 Respostqa d'eco (echo reply) Petició

8 0 Petició d'eco (echo request) Petició

3 0-15

Destinació inabastable (unreachable destination)

Els diferents codis permeten definir si el que no es pot abastar és la subxarxa (0, 6, 9, 11), l'estació (1, 7, 10, 12), el protocol (2), o el port (3) i els motius

Error

4 0 Petició de control de flux (source quench) Error

5 0-3 Readreçament Error

9 0 Publicació de rutes Petició

El camp Protocol de la capçalera és igual a 1


L’última columna ens permet distingir missatges ICMP de notificació d’error

de missatges que són part d’una petició (la petició o la resposta). Aquesta dis-

tinció és important, ja que els missatges d’error ICMP no poden generar altres

missatges d’error ICMP. Particularment, no es generen missatges d’error en

resposta als paquets o missatges següents:

• Els missatges d’error ICMP.

• Un paquet IP destinat a una adreça broadcast (sigui un broadcast IP o un

broadcast MAC).

• Un fragment que no sigui el primer.

• Una adreça d’origen que no identifica una única estació. Per exemple, l’adreça

d’origen vàlida 0.0.0.0 o l’adreça d’origen no vàlida 255.255.255.255

Fixeu-vos que en qualsevol d’aquestes situacions es podrien provocar respos-

tes en cascada que podrien afectar greument la xarxa.

Pedaços

Desgraciadament, no totes les implementacions TCP/IP han tingut en compte les excep-cions que hi ha en la generació de missatges d’error, i alguns usuaris desaprensius hanexplotat aquests problemes per a bloquejar sistemes i xarxes remotes. A més, de tant entant es descobreixen noves excepcions que poden afectar els nostres sistemes.

Els fabricants de sistemes operatius publiquen regularment pedaços (patch) que perme-ten solucionar els problemes (les vulnerabilitats) que s’han descobert des de la data depublicació de l’última versió.

5.2. El programa ping

El programa ping permet descobrir si una estació es troba activa o no, simple-

ment fent el següent:

La instrucció ping envia un missatge ICMP del tipus 8 (petició d’eco) amb la

destinació indicada. El receptor de la petició ha de respondre amb una res-

Tipus Codi Descripció Classe

10 0 Petició de rutes Petició

11 0-1 El temps de vida ha expirat (time exceeded) Error

12 0-1 Capçalera IP incorrecta Error

13 0 Petició d'hora Petició

14 0 Resposta d'hora (en mil·lisegons des de la mitjanit) Petició

17 0 Petició de la màscara de la subxarxa Petició

18 0 Resposta de la màscara de la subxarxa Petició

$ ping <adreça_IP_destinació>


posta d’eco (ICMP tipus 0), i, quan el ping la rep, indica en pantalla que l’es-

tació remota està activa*.

En sistemes multitasca hi pot haver més d’una petició en curs. Per tal de saber

a quin dels programes ping s’ha de lliurar la resposta, cada ping assigna

l’identificador del procés ping als missatges generats. El camp identificador de

seqüència permet al ping enviar diferents paquets i identificar-ne les respostes

(ping –l en MSWindows i ping en UNIX*). El camp de dades permet afegir

una cadena arbitrària de bytes a la petició d’eco (ping –s en UNIX i ping –l

en MSWindows). La resposta ha de dur una còpia d’aquests bytes.

Activitat

• Practiqueu l’ús del programa ping. Comproveu quins retards màxims es donen a In-ternet. Feu-ho a diferents hores del dia.

Amb el ping tenim altres opcions disponibles. Particularment, l’opció de me-

morització de rutes (record route o RR)*. Aquesta opció no es reflecteix en cap

dels camps del missatge ICMP, sinó que es troba dins la mateixa capçalera IP,

en el camp d’opcions.

Les diferents opcions que hi ha disponibles a la capçalera s’identifiquen mit-

jançant el primer byte del camp d’opcions de la capçalera IP:

* Evidentment la instrucció s’hauria de dir ping-pong.

* En diferents versions d’UNIX els paràmetres poden canviar. En cas

de dubte, feu man ping.

* La sintaxi de l’opció RR en UNIX ésping –R i en MSWindows, ping –r.


Si l’originador vol activar l’opció RR, el primer byte ha de ser 7. En totes les

opcions el primer byte indica el tipus, i el segon, la longitud en bytes de l’op-

ció. En aquest cas sempre es demana el màxim possible, que és 39 bytes, ja

que el camp següent té un byte (punter), al qual segueix una cadena de

camps de 4 bytes (que són les adreces IP trobades). El camp punter s’inicialit-

za a 4, i dins els 4 bytes següents es guarda l’adreça de l’estació en què exe-

cutem el ping.

Cada encaminador ha de mirar dins els paquets IP (ICMP o no) per a veure si

tenen l’opció RR activada. En cas que un encaminador trobi un paquet amb

aquesta opció activada, modifica la posició apuntada pel punter amb la seva

adreça (normalment l’adreça de sortida de l’encaminador) i incrementa el va-

lor del punter en quatre unitats. Quan torna el missatge de resposta d’eco, s’hi

ha afegit una llista amb tots els salts que ha hagut de fer el paquet (tant d’ana-

da com de tornada).

El camp d’opcions té limitacions de mida: només té 36 bytes disponibles

(39 - 3) per a guardar adreces IP. Com que cada adreça ocupa 4 bytes, només

hi ha espai per a 9 adreces IP. Això, afegit al fet que no tots els encamina-

dors comproven si hi ha opcions dins els paquets IP, o no actualitzen l’op-

ció RR, fa poc útil aquest tipus de ping en el món real.

Activitat

• Comproveu la ruta a diferents destinacions mitjançant un ping amb l’opció de me-morització de rutes. Valoreu si la comprovació d’aquesta opció està gaire estesa.

5.3. El programa traceroute

El programa traceroute permet trobar les rutes entre un origen i una desti-

nació sense cap de les limitacions del ping -R (ping -r en MSWindows).

Utilitza un mecanisme bastant enginyós basat en missatges genèrics ICMP (i

no els específics petició d’eco i resposta d’eco del ping).

El funcionament es basa en l’explotació de dos missatges ICMP:

1) Temps de vida esgotat (time-exceeded): quan un encaminador rep un pa-

quet, a part de les tasques primordials d’encaminament, ha de reduir en una

unitat el valor del camp TTL de la capçalera IP.

En cas que el valor (després de la reducció) sigui zero, el paquet s’ha d’elimi-

nar. Aquesta eliminació, però, no és silenciosa, sinó que l’encaminador res-

ponsable n’envia una notificació a l’originador del paquet mitjançant un

missatge ICMP tipus 11 i codi 0 (temps de vida esgotat).

Aquest paquet ICMP conté la capçalera del paquet IP que s’ha eliminat i els

primers 8 bytes del seu contingut (segurament la capçalera UDP o els primers

bytes de la capçalera TCP).

Vegeu els detalls de la capçalera dels missatges IP en el subapartat 3.2 d’aquest mòdul didàctic.

En MSWindows traceroute rep el nom de tracert.


2) Port inabastable (unreachable-port): quan una estació rep un datagrama

UDP o un segment TCP destinat a un port que la màquina no escolta, respon

amb un missatge d’error de port inabastable (tipus 3 amb codi 3).

El programa traceroute simplement ha d’enviar paquets a la destinació

amb TTL seqüencialment ascendents: el paquet (independentment del ti-

pus que sigui) que tingui el TTL = 1 serà rebutjat pel primer encaminador,

el que tingui TTL = 2 ho serà pel segon, i així consecutivament. Cadascun

dels encaminadors tornarà un missatge ICMP “temps de vida esgotat”, una

pista del tot suficient perquè l’originador esbrini el camí que han seguit

tots els paquets.

Quan el missatge arriba a la destinació, ha de tornar algun missatge per a

saber que la seqüència ha finalitzat. Per norma general, el missatge serà

“port inabastable” si el missatge enviat era un datagrama UDP a un port no

usat, o bé una resposta d’eco si el que s’ha tramès són paquets ICMP de pe-

tició d’eco.

Implementacionsdels traceroute

Les implementacions d’UNIX provades utilitzen un datagra-ma UDP destinat a un port ele-vat (per a minimitzar la probabilitat que hi hagi un servei usant el port). El tracert de Windows fa servirprecisament missatges ICMP echo-request.


Activitats

• Utilitzeu el programa traceroute (tracert en MSWindows) per a descobrir els ca-mins que segueixen els paquets fins a diferents destinacions.

• Mireu quants salts hi ha des de la vostra màquina fins a www.nasa.gov i calculeu quinnombre de paquets hi ha a la cua de sortida dels diferents encaminadors. Comproveuquines són les àrees més carregades. Feu-ho a diferents hores del dia i fixeu-vos en lesdiferents zones horàries que travessa el traceroute.

• Proveu què passa si ens connectem a un port no servit. Per exemple, connecteu-vos alport TCP 1234 (ho podeu fer amb telnet localhost 1234). Heu de considerar quel’aplicació telnet en Windows95 no admet el segon argument (ho heu de provar enUNIX o bé en Windows NT).

5.4. Missatge de readreçament

És normal que els sistemes es connectin a Internet només configurant la seva

adreça IP, la màscara de la LAN i l’encaminador que gestiona la comunicació

remota. Quan hi ha més d’un encaminador a la LAN local, l’encaminador que

hem configurat a l’estació detecta que rep paquets que en realitat haurien

d’anar a algun altre dels encaminadors de la mateixa LAN.

A aquest efecte, els encaminadors disposen del missatge ICMP de readreça-

ment (redirect), que actua de la manera següent:

1) L’estació envia un paquet a l’encaminador que té configurat (A). L’encami-

nador A descobreix que la ruta millor passa per emprar l’encaminador B.

2) L’encaminador A encamina el paquet cap a l’encaminador B.

3) Notifica a l’estació que modifiqui la seva taula d’encaminament.

Fixeu-vos que l’encaminador continua encaminant els paquets normalment

(pas 2). Encara que l’estació no fes cas del missatge ICMP de readreçament

(pas 3), continuaria tenint connectivitat amb l’exterior, però, si li fa cas, mi-

llorarà el rendiment del sistema.

Vegeu aplicacions alternatives a telnet en l’annex 1 d’aquest mòdul didàctic.


Quan una estació obeeix un ICMP de readreçament, la seva taula d’encamina-

ment queda convenientment actualitzada. La comanda route ens pot donar

alguna pista de si aquest fenomen té lloc.


6. Protocols del nivell de transport

L’objectiu principal del nivell de transport és actuar d’interfície entre els ni-

vells orientats a l’aplicació i els nivells orientats a la xarxa de la jerarquia de

protocols (tant OSI com TCP/IP).

El nivell de transport oculta als nivells alts del sistema el tipus de tecnologia

(xarxa) al qual està connectat el terminal. La figura següent descriu el posicio-

nament del nivell de transport respecte a la resta de nivells:

Per a introduir els protocols del nivell de transport, ens centrem en la jerarquia

de protocols TCP/IP. En aquesta jerarquia es defineixen dos protocols de trans-

port: l’UDP i el TCP. L’UDP és no orientat a la connexió, mentre que el TCP és

orientat a la connexió.

En el cas de la jerarquia TCP/IP, es defineixen dues adreces que relacionen el

nivell de transport amb els nivells superior i inferior:

• L’adreça IP, que ja coneixem, és l’adreça que identifica un subsistema dins

una xarxa.

• El port identifica l’aplicació que requereix la comunicació.

Per a identificar les diferents aplicacions, els protocols TCP/IP marquen

cada paquet (o unitat d’informació) amb un identificador de 16 bits ano-

menat port.

La veritable utilitat dels ports és que permeten multiplexar aplicacions sobre

protocols del nivell de transport. Això significa que un mateix protocol de

Recordeu

Els terminals poden estar con-nectats tant a una xarxa d’àrealocal (LAN) com a una xarxa de gran abast (WAN), i inter-connectats per mitjà del proto-col d’Internet

Més endavant tornarem a parlar d’aquest punt.


transport porta informació de diferents aplicacions i aquestes són identifica-

des pel port.

Una aplicació pot establir una comunicació per mitjà de la jerarquia de proto-

cols TCP/IP.

Els protocols del nivell d’aplicació poden ser els següents:

• FTP (file transfer protocol) per a la transferència de fitxers.• HTTP (hipertext transfer protocol) base del WWW.• SMTP (simple mail transfer protocol) per al correu electrònic.• SNMP (simple network management protocol) per a la gestió de la xarxa.

Si alguna aplicació que corre en un terminal vol establir una comunicació

amb un servidor o amb un altre terminal, ha d’utilitzar un protocol de trans-

port: el TCP o l’UDP. Com que la destinació es pot trobar en una xarxa remo-

ta, els protocols de transport necessiten el protocol Internet per a poder

arribar al terminal o servidor remot.

Per tant, quan s’estableix la comunicació, no tan sols és essencial conèixer el

port que identifica l’aplicació de destinació, sinó també l’adreça IP que iden-

tifica el terminal o servidor dins el conjunt de xarxes.

Com podeu observar en la figura anterior, les aplicacions fan servir un dels dos

protocols de transport per a comunicar-se amb equips remots. Perquè un pro-

tocol d’aplicació es pugui comunicar amb un altre del mateix nivell situat en

un terminal remot, li ha de transmetre un flux de bytes. Aquest flux de bytes

és encapsulat pels protocols del nivell de transport.

El conjunt de bytes que transmet el nivell de transport TCP s’anomena

segment TCP, mentre que el conjunt de bytes que transmet el protocol

de transport UDP s’anomena datagrama UDP.


Dues aplicacions es comuniquen seguint el model client/servidor. En una con-

nexió és típic que una aplicació (el client) iniciï una comunicació demanant

una informació a una altra aplicació (el servidor). Pensem en un ordinador

que està connectat a una LAN i té assignada una adreça IP. Suposem que

aquest ordinador actua com a servidor de correu electrònic, a més de com a

servidor de noms. Un client connectat a Internet que sol·licita resoldre un

nom necessita conèixer l’adreça IP assignada a aquest ordinador i el port que

identifica l’aplicació servidor que resol noms.

El client necessita conèixer totes dues adreces perquè el servidor estarà con-

nectat a una xarxa i, per tant, tindrà una adreça IP que ha de ser coneguda per-

què es pugui establir una comunicació amb aquesta màquina remota. Aquesta

comunicació s’aconsegueix per mitjà de l’IP. Però, un cop aconseguida la co-

municació, el servidor ha de ser capaç d’identificar l’aplicació amb què es vol

comunicar el client entre les moltes que corren: servidor de noms, servidor de

correu electrònic, etc.

El client coneix l’adreça IP d’origen (la seva), l’adreça IP de destinació (la del

servidor) i el seu port d’origen (identifica l’aplicació client). Però també ha de

conèixer el número (port de destinació) que identifica l’aplicació desitjada en

el servidor, i ho fa mitjançant els anomenats ports coneguts (well-known port).

Exemple

Els valors de ports coneguts per a aplicacions que fan servir l’UDP són els següents:

• Port 7 per al servidor d’eco.• Port 53 per al servidor de noms (DNS*).• Port 69 per al protocol de transferència de fitxers trivial (TFTP**).

I alguns valors de ports coneguts per a aplicacions que fan servir el TCP són els següents:

• Ports 20 i 21 per al protocol de transferència de fitxers de dades i de control respecti-vament.

• Port 23 per al Telnet Remote Login.• Port 80 per a l’HTTP.

Evidentment, el servidor no necessita conèixer a priori el port d’origen, ja que

es limita a respondre a qualsevol petició de qualsevol client. El client informa

en la unitat de dades de protocol (PDU) del nivell de transport (o bé un data-

grama UDP o bé un segment TCP) dels ports d’origen i de destinació, de ma-

nera que el servidor coneixerà el port d’origen un cop hagi rebut una petició.

Un port conegut (well-known port) és un port (número) reservat que

identifica una aplicació coneguda.Els ports coneguts són assignats perIANA (Internet Assigned Numbers

Authority).

* DNS és la sigla de domain name server.

** TFTP és la sigla de trivial file transfer protocol.


7. L’UDP (user datagram protocol)

L’UDP és un protocol no orientat a la connexió, de manera que no propor-

ciona cap tipus de control d’errors ni de flux, tot i que utilitza mecanismes

de detecció d’errors. En cas de detectar un error, l’UDP no lliura el datagrama

a l’aplicació, sinó que el descarta.

Cal recordar que per sota l’UDP està fent servir l’IP, que també és un protocol

no orientat a la connexió. Per tant, es va pensar a definir un protocol del nivell

de transport que permetés que l’aplicació explotés aquest tipus de caracterís-

tiques i que fos com més simple i senzill millor.

La simplicitat de l’UDP fa que sigui ideal per a aplicacions que requereixen

pocs retards (per exemple aplicacions en temps real). L’UDP també és ideal per

als sistemes que no poden implementar un sistema tan complex com el TCP.

La figura següent mostra la unitat de dades del protocol UDP i el seu encapsu-

lament en un datagrama IP. Cada operació de sortida d’un datagrama UDP

provoca la generació d’un datagrama IP:

Les característiques més importants de l’UDP són les següents:

• No garanteix la fiabilitat, és a dir, no es té la seguretat que cada datagrama

UDP transmès arribarà a la seva destinació; és un protocol best-effort: l’UDP

fa tot el que pot per a transferir els datagrames de la seva aplicació, però no

en garanteix el lliurament.

No orientat a comunicació

L’UDP és un protocol no orien-tat a la connexió. Això vol dir que cada datagrama UDP exis-teix independentment de la resta de datagrames UDP.

Vegeu el TCP , un protocol orientat a connexió i molt més complex que l’UDP, en l’apartat 8 d’aquest mòdul didàctic.


• No preserva la seqüència de la informació que li proporciona l’aplicació.

Com que està en mode datagrama i utilitza un protocol per sota com l’IP,

que també està en mode datagrama, l’aplicació pot rebre la informació des-

ordenada. L’aplicació ha d’estar preparada perquè hi hagi datagrames que

es perdin, arribin amb retard o s’hagin desordenat.

El datagrama UDP consta d’una capçalera i un cos per a encapsular les dades.

La capçalera consta dels elements següents:

• Els camps port d’origen i port de destinació, que identifiquen les aplica-

cions en els terminals d’origen i de destinació. Cada port té 16 bits.

• El camp longitud indica la longitud, en octets, del datagrama UDP incloent-

hi la capçalera UDP (és la diferència de la longitud del datagrama IP menys

la capçalera IP). Com que la longitud màxima d’un datagrama IP és de

65.535 bytes, amb una capçalera estàndard de 20 bytes, la longitud màxi-

ma d’un datagrama UDP és de 65.515 bytes.

• El camp checksum (16 bits) és opcional i protegeix tant la capçalera com

les dades UDP (cal recordar que el checksum del datagrama IP només co-

breix la capçalera IP). Quan l’UDP rep un datagrama i determina que hi ha

errors, el descarta i no el lliura a cap aplicació.

Càlcul del checksum en l’UDP

El càlcul del checksum en l’UDP és molt semblant al càlcul del checksum en l’IP (suma encomplement en uns de paraules de 16 bits), amb la particularitat que la longitud del da-tagrama UDP pot ser parella o imparella. En cas que sigui imparella, se li afegeix un 0 alfinal del datagrama a fi de calcular el checksum (aquest 0 no es transmet). Per a calcularel checksum, l’UDP fa servir una pseudocapçalera de 12 bytes amb alguns dels camps IP.Aquesta pseudocapçalera no es transmet; l’UDP només la utilitza per a calcular el check-sum i li serveix per a comprovar que la informació que li dóna l’IP sigui realment per a ell.

Com hem vist, l’UDP no proporciona un lliurament d’informació segur i fiable a

l’aplicació. Però hi pot haver aplicacions, per exemple, interessades a transmetre

informació en mode multicast o broadcast (a un grup d’usuaris o a tots els usuaris

de la xarxa). En aquest cas, sí que té sentit enviar la informació a molts receptors

sense esperar una resposta de tots, de manera que és ideal disposar d’un protocol

de transport simple i senzill no orientat a la connexió com l’UDP.

D’altra banda, algú es podria preguntar quin avantatge presenta l’UDP respec-

te a l’IP, és a dir, per què s’ha de fer servir l’UDP si l’IP també ofereix una con-

nexió en mode datagrama. La resposta és que l’UDP ofereix un servei de

multiplexació a les aplicacions que l’IP no ofereix.

Exemple

Què passa si diferents aplicacions es volen comunicar amb altres aplicacions en màqui-nes remotes sense utilitzar un servei fiable com el TCP?

L’IP identifica l’estació remota, però, com es poden identificar les aplicacions destinacióen l’estació remota? La solució consisteix a utilitzar l’UDP i a fer servir les adreces portper a multiplexar la informació. Amb l’adreça port és possible identificar quina és l’apli-cació de destinació en l’estació remota.

Mida dels buffersde les aplicacions

Hi ha moltes aplicacions que li-miten la mida dels seus buffersde transmissió i recepció per sota de la mida màxima d’un datagrama UDP. Per exemple, és típic trobar aplicacions que proporcionen, per defecte, mi-des màximes del datagrama UDP de 8.192 bytes. Aquest valor prové de la quantitat de dades de l’usuari que l’NFS (network file system) pot llegir oescriure per defecte.


8. El TCP (transmission control protocol)

Com hem vist, l’UDP no garanteix el lliurament de la informació que li pro-

porciona una aplicació. Tampoc no reordena la informació en cas que arribi

en un ordre diferent de l’ordre en què s’ha transmès. Hi ha aplicacions que no

poden tolerar aquestes limitacions. Per a superar-les, el nivell de transport pro-

porciona un protocol anomenat TCP.

8.1. El TCP proporciona fiabilitat

Per a proporcionar un servei fiable a l’aplicació, el TCP es basa en els principis

següents:

1) Transmissió lliure d’error. El TCP ha de lliurar a l’aplicació de destinació

exactament la mateixa informació que li va lliurar l’aplicació d’origen. De fet,

es tracta d’un lliurament “gairebé lliure” d’errors, ja que n’hi pot haver que un

mecanisme de detecció d’errors no pugui detectar.

2) Garantia de lliurament de la informació. El TCP garanteix que tota la in-

formació transmesa per l’aplicació d’origen es lliurarà a l’aplicació de destina-

ció. En cas que això no sigui possible, el TCP ha d’avisar l’aplicació.

3) Garantia de manteniment de la seqüència de transmissió. El TCP garan-

teix que lliurarà el flux d’informació en el mateix ordre en què li va ser lliurat

per l’aplicació d’origen.

4) Eliminació de duplicats. El TCP garanteix que només lliurarà una còpia

de la informació transmesa a l’aplicació de destinació. En cas que rebi còpies

a causa del funcionament de la xarxa o dels protocols que s’implementen per

sota del nivell de transport, el TCP les eliminarà.

Les propietats següents del TCP garanteixen un servei de lliurament fiable de

la informació:

a) El TCP defineix fluxos (stream oriented): l’aplicació organitza les dades d’in-

formació en fluxos (streams) de bits estructurats en bytes. En conseqüència, el

receptor passa a la seva aplicació el mateix flux de bytes que l’aplicació d’ori-

gen ha passat al TCP. D’altra banda, l’aplicació no té cap manera d’indicar al

El TCP proporciona fiabilitat a l’aplicació, és a dir, garanteix el lliurament

de tota la informació en el mateix ordre en què ha estat transmesa per

l’aplicació d’origen. Per a aconseguir aquesta fiabilitat, el TCP proporciona

un servei orientat a la connexió amb un control de flux i errors.


TCP els límits en què vol transferir la informació: és el TCP el que decideix en

cada moment quants bytes transfereix en un segment.

b) El TCP està orientat a la connexió: té una fase d’establiment de la conne-

xió, una fase de transmissió de dades i una fase de desconnexió.

c) El TCP fa servir el concepte de buffered transfer: quan es transfereix in-

formació, el TCP divideix els fluxos de dades (bytes) que li passa l’aplicació

en trossos de la mida que li convingui. El TCP decideix la mida dels seg-

ments tant si l’aplicació genera un byte d’informació com si genera fluxos

de gran dimensió. En el primer cas, el TCP pot esperar que la memòria in-

termèdia estigui més plena abans de transferir la informació, o bé la pot

transferir immediatament (mecanisme push). En cas que els fluxos siguin

molt grans, el TCP pot dividir la informació en mides més petites abans de

transferir-los.

d) El TCP utilitza una connexió full duplex: la transferència d’informació és

en tots dos sentits. L’aplicació veu dos fluxos independents. En cas que

l’aplicació tanqui un dels fluxos, la connexió passa a ser half duplex. Això vol

dir que un dels extrems (el que no ha tancat la connexió) pot continuar en-

viant informació pel canal, mentre que l’altre extrem (el que ha tancat la

connexió) es limita a reconèixer la informació. De totes maneres, no és nor-

mal trobar aquest cas. El més habitual és que, si un extrem tanca la connexió,

l’altre també la tanqui.

8.2. Format del segment TCP

La unitat d’informació del protocol TCP s’anomena segment TCP. El format

del segment TCP és el següent:


El segment TCP consta d’una capçalera i un cos per a encapsular dades. La cap-

çalera consta dels camps següents:

a) El camp port d’origen , identifica l’aplicació en el terminal d’origen.

b) El camp port de destinació , identifica l’aplicació en el terminal de des-

tinació.

c) El camp número de seqüència , identifica el primer byte del camp de da-

des. En el TCP no es numeren segments, sinó bytes. Per tant, el número de

seqüència identifica el primer byte de les dades que envia el segment: al co-

mençament de la connexió s’assigna un número de seqüència inicial (ISN,

de l’anglès initial sequence number), a partir del qual el TCP numera els bytes

consecutivament.

d) El camp número ACK . El TCP reconeix dades mitjançant la tècnica de

piggybacking. En activar un bit de la capçalera (el bit ACK), el TCP té en compte

el número de seqüència ACK que indica a l’altre extrem TCP el proper byte que


està disposat a rebre. Dit d’una altra manera, el número ACK menys un indica

el darrer byte reconegut.

e) El camp longitud de la capçalera indica la longitud de la capçalera, que

pot ser variable. La longitud típica és de 20 bytes, però, si el TCP fa servir el

camp d’opcions, pot arribar a una longitud màxima de 60 bytes. D’aquesta

manera, el TCP sap on comencen les dades.

f) El camp reservat, tal com indica el seu nom, està reservat i s’inicialitza amb

zeros.

g) El camp control, està format per sis indicadors independents, cada un dels

quals assenyala una funció específica del protocol quan està actiu (a 1):


• URG: indica que hi ha dades urgents (i el camp urgent pointer indica la

quantitat de dades urgents que hi ha en el segment).

• ACK: quan aquest bit està actiu, el camp número ACK indica el byte se-

güent que espera rebre la connexió TCP. Si aquest bit no està actiu, el camp

número ACK no té cap significat per al TCP.

• PSH: invoca la funció push en el protocol. Aquesta funció diu al receptor

que lliuri a l’aplicació totes les dades que tingui disponibles en la memòria

intermèdia de recepció sense esperar a completar-les amb dades addicio-

nals. D’aquesta manera, les dades no esperen en la memòria intermèdia re-

ceptora fins a completar un segment de dimensió màxima.

• RST: fa un reset de la connexió.

• SYN: s’utilitza per a iniciar una connexió i també serveix per a resincronitzar

els números de seqüència.

• FIN: indica que el transmissor ha acabat la connexió.

h) El camp finestra indica quants bytes componen la finestra de transmissió

del protocol de control de flux per finestra lliscant. A diferència dels protocols

del nivell d’enllaç, en què la finestra és constant i compta trames, en el TCP la

finestra és variable i compta bytes. Amb cada segment transmès, un extrem

TCP adverteix l’altre extrem de la quantitat de dades que està disposat a rebre

en cada moment. D’aquesta manera, l’extrem que rep un segment actualitza

la mida de la seva finestra de transmissió.

i) El camp checksum s’utilitza per a detectar errors.

Atenció

No s’ha de confondre amb l’in-dicador URG, que indica que l’aplicació ha assenyalat una porció del segment com a urgent.


j) El camp urgent pointer té sentit quan el bit de control URG està actiu, in-

dica que les dades que envia l’origen són urgents i identifica el darrer byte del

camp de dades que també ho és. El receptor processa aquestes dades tan ràpi-

dament com pot. L’aplicació és la que indica que aquestes dades són urgents i

ho sap perquè el TCP li ho indica en la recepció.

Agunes aplicacions que fan servir l’urgent pointer són, per exemple, telnet, rlogin oftp. En la llibreria de sockets, el tràfic urgent s’anomena tràfic fora de banda (out of band).

k) El camp opcions TCP permet afegir camps a la capçalera per a fer les ope-

racions següents:

• Marcar el temps (timestamp) en què es va transmetre el segment i així po-

der monitorar els retards que experimenten els segments des de l’origen

fins a la destinació.

• Augmentar la mida de la finestra.

• Indicar la mida màxima del segment (MSS*) que l’origen està preparat per

a rebre. Per tant, el receptor no li pot transmetre segments per damunt

d’aquest valor.

La mida màxima del segment TCP transmès s’especifica durant l’establiment de la con-nexió i defineix la màxima longitud de dades que el TCP enviarà.

Activitat

• Quina és la mida d’un datagrama IP en funció d’MSS?

Solució

Si la mida de les dades TCP és MSS, caldrà afegir-hi 20 bytes de la capçalera TCP més 20 bytesde la capçalera IP (tenint en compte les capçaleres bàsiques sense opcions). Això vol dir quela longitud del datagrama IP serà d’MSS 1 40 bytes (sempre assumint que tant el TCP com l’IPno utilitzen els seus camps d’opcions).

Si no s’especifica la mida màxima durant la transmissió del segment SYN, s’agafen perdefecte 536 bytes (la mida per defecte d’un datagrama IP és de 576 bytes, menys els 40bytes de les capçaleres IP i TCP).

Per exemple,...

... si el número de seqüència indica 1.000 i l’urgent pointerindica 200, vol dir que els bytesdel 1.000 al 1.200 es conside-ren urgents. A partir del 1.201,les dades es tornen a conside-rar normals.

En el mòdul “Aplicacions Internet” d’aquesta assignatura, podeu veure exemples de com es fan servir les aplicacions telnet, rlogini ftp.

* MSS és la sigla de maximumsegment size.


El fet de triar l’MSS no és trivial. En general, com més gran sigui l’MSS, millor,

ja que les capçaleres IP i TCP s’amortitzen més. Però si l’MTU és petita, caldrà

fragmentar el datagrama IP (és a dir, el segment TCP); per tant, normalment

no interessa triar MSS més grans que l’MTU. En aquest cas, hi ha diferents pos-

sibilitats:

1) Buscar l’MTU local de la xarxa a la qual està connectada l’estació i assumir

que, si hi ha MTU més petites fins a la destinació, hi haurà fragmentació.

2) Utilitzar un mecanisme de cerca per a esbrinar quina és l’MTU més petita des

de l’origen fins a la destinació* i utilitzar com a MSS l’MTU més petita menys els

40 bytes de capçaleres IP i TCP.

8.3. Establiment de la connexió

Per a establir una connexió, el TCP utilitza el protocol three-way handshake.

Aquest protocol necessita tres segments TCP per a poder establir la connexió.

Considerem que el servidor està en un estat d’escolta, anomenat listen, i que

el client vol establir una connexió amb el servidor. El TCP de la màquina client

iniciarà la petició de connexió TCP, que serà contestada pel TCP de la màqui-

na servidor.

Perquè el client TCP pugui establir una connexió TCP amb el servidor, se se-

gueixen aquests passos:

1) Petició de la connexió

El TCP client envia un segment de petició de connexió al servidor. Aquest seg-

ment, que s’anomena segment SYN perquè té activat el bit SYN en el camp con-

trol de la capçalera del segment TCP, especifica el número de seqüència inicial

TCP del client (ISN).

Vegeu l’MTU en el subapartat 2.1.2 d’aquest mòdul didàctic.

* Aquest mecanisme s’anomena, en anglès, MTU discovery path.

Segment SYN

Aquest segment especifica mésparàmetres, com ara el port del servidor al qual es vol con-nectar el client, i acostuma a especificar també la mida màxima del segment (MSS) que el client transmetrà.


El número de seqüència inicial es tria a l’atzar. La raó és molt senzilla. Hi ha

paquets que poden sobreviure a la xarxa un cop s’ha tancat la connexió TCP

(fins i tot si ha estat a causa d’una caiguda del sistema). Cal assegurar-se que

una connexió nova tria un número de seqüència inicial que no existeixi. El

TCP recomana utilitzar un número de seqüència inicial basat en una variable

que s’incrementa una quantitat x cada y temps (per exemple, a 4.4BSD hi ha

un comptador que s’incrementa cada 8 ms).

Si el sistema cau, passats uns segons torna a estar en marxa i immediatament

s’estableix una connexió nova utilitzant el mateix port i la mateixa adreça IP, es

podria interpretar que els segments TCP que han quedat retardats en la xarxa i

que ja existien abans de la caiguda de la màquina, pertanyen a la connexió no-

va, cosa que provocaria la confusió i el mal funcionament d’aquesta connexió.

Això passaria fins i tot independentment del número de seqüència inicial triat.

A fi de protegir-se d’aquesta situació, es combinen dues tècniques: l’una con-

sisteix a triar el número de seqüència inicial de manera aleatòria i l’altra és

l’anomenada quiet time, que consisteix que el TCP no crea cap connexió nova

després d’un rebot de màquines fins que no transcorre un temps determinat

anomenat MSL* o temps de vida màxima d’un segment. D’aquesta manera, s’as-

segura que no rebrà segments antics d’altres connexions.

L’MSL depèn de la implementació, però els valors normals són, aproximadament, 30 segons,1 minut o 2 minuts. De totes maneres, hi ha moltes implementacions que no tenen encompte aquesta situació, ja que consideren que un rebot de màquines dura més temps quel’MSL.

2) Confirmació de la connexió

El servidor respon a la petició d’establiment de la connexió amb un segment

SYN que indica el número de seqüència inicial que utilitzarà.

Aquest segment conté també un reconeixement (ACK) del segment SYN del client

que indica l’ISN del client més 1 (el número de seqüència inicial del client més 1).

Cal recordar que el TCP numera els ACK amb el número de seqüència del proper byte queespera rebre (en aquest cas el servidor espera que el proper byte enviat pel client serà J + 1).En la figura anterior, seria el segment SYN (K), ACK ( J + 1), en què K és l’ISN triat pel TCPservidor.

3) Reconeixement de la connexió

El client reconeix el segment SYN (K) del servidor amb un reconeixement que

conté l’ISN servidor més 1. En la figura anterior, seria el segment ACK (K + 1).

Es diu que qui envia el primer segment SYN (en aquest cas el client) fa una

obertura activa (active open), mentre que qui rep el primer segment SYN i

envia el proper segment SYN (en aquest cas el servidor) fa una obertura pas-

siva (passive open).

* MSL és la sigla de maximumsegment lifetime.


Es pot donar el cas que tots dos extrems efectuïn una obertura activa en el mateix

moment. Aquesta situació s’anomena obertura simultània (simultaneous open).

Ara ja s’ha establert la connexió entre el client i el servidor.

Monitoratge de l’establiment d’una connexió utilitzant el programa tcpdump

Utilitzarem el programa tcpdump per a veure com funciona el protocol d’establimentd’una connexió.

Assumim que ens hem connectat a una màquina anomenada argos i fem un rlogin a lamàquina helios.

Les primeres línies que obtenim amb el tcpdump són les següents:

La interpretació de les línies és la següent:

1) argos, des del port 1.023, envia a helios una petició de connexió per mitjà d’un seg-ment SYN. El número de seqüència inicial (ISN) triat per argos és el 3.541.904.332, i argosanuncia que pot rebre 31.744 bytes sense reconèixer-los i que espera rebre segments ambuna mida màxima de 1.460 bytes.

2) helios respon amb un segment SYN triant com a ISN el número 548.133.143 i res-pon amb un ACK amb el byte següent que espera rebre d’argos, el 3.541.904.333(3.541.904.332 + 1). Anuncia que pot rebre 8.760 bytes i que espera rebre segmentsamb una mida màxima de 1.460 bytes.

3) argos reconeix el segment SYN amb un segment en què espera rebre el byte548.133.144 (548.133.143 + 1). argos torna a advertir que està disposat a rebre fins a31.744 bytes.

A continuació començaria l’intercanvi d’informació entre el client i el servidor (perexemple peticions de login, contrasenya, prompt de la màquina, etc.).

Activitat

• Utilitzeu el programa tcpdump per a veure l’establiment d’una connexió. Amb aquestafinalitat, establiu una connexió amb aplicacions diferents (telnet, ftp, rlogin, etc.)i monitoreu la connexió. Observeu els segments d’inici de la connexió, el valor del nú-mero de seqüència inicial, el del número ACK inicial i la mida de la finestra.

8.4. Terminació de la connexió

Quan la transferència de la informació ha acabat, el TCP disposa d’un protocol

de terminació de la connexió per a tancar-la.

En una connexió TCP full duplex, en què les dades flueixen en tots dos sen-

tits, independents l’un de l’altre, qualsevol connexió s’ha de tancar indepen-

dentment.

argos % rlogin helios

• 15:56:54.796091 argos.1023 > helios.login: S 3541904332:3541904332 (0) win 31744 <mss 1460>

• 15:56:54.796091 helios.login > argos.1023: S 548133143:548133143 (0) ack 33541904333 win 8760 <mss 1460>

• 15:56:54.796091 argos.1023 > helios.login: . ack 548133144 win31744

En l’annex 1 d’aquest mòdul didàctic podeu trobar una descripciódel programa tcpdump.

Cal recordar...

... que un sistema orientat a la connexió efectua una fase d’establiment de la connexió, una fase de transferència de la informació i una fase de tancament de la connexió.


Cal tenir en compte que tant el client com el servidor poden tancar la con-

nexió. Però la situació normal és que l’aplicació client iniciï la petició de

connexió i tingui, possiblement, un usuari interactiu que li’n demani el tan-

cament per mitjà, per exemple, d’una instrucció*. Per tant, suposem que és

el client qui demana tancar la connexió (si fos el servidor, seria similar). Els

passos que se segueixen són aquests:

1) El client envia un segment TCP del tipus FIN amb el número de seqüència

corresponent ( J). Això vol dir que a partir d’aquest moment no hi haurà més

dades que flueixin en aquest sentit (client → servidor).

2) El servidor envia una confirmació del tancament per mitjà d’un ACK amb

el número de seqüència rebut més 1 ( J + 1).

El TCP servidor indica a la seva aplicació que el client tanca la connexió.

L’aplicació servidor indica al seu TCP que la tanqui tot seguit.

3) El servidor envia un segment TCP del tipus FIN al client amb el número de

seqüència corresponent (K).

4) El TCP client respon automàticament amb un ACK (K + 1).

Es diu que qui envia el primer segment FIN (en aquest cas el client) fa un tan-

cament actiu (active close), mentre que qui el rep (en aquest cas el servidor) fa

un tancament passiu (passive close).

Cal remarcar que la connexió que efectua el tancament actiu entra en un

estat anomenat TIME_WAIT, de manera que haurà d’esperar un temps (ge-

* En un telnet aquesta instrucció seria un logout, en un ftp seria

fent un bye, etc.

Un segment FIN...

... s’anomena així perquè té ac-tivat el bit FIN en el camp con-trol de la capçalera del segment TCP.


neralment una o dues vegades l’MSL) abans de tornar a fer servir el mateix

port. El més habitual és que sigui el client qui efectua el tancament actiu.

Com que els clients acostumen a utilitzar ports locals efímers, aquest temps

d’espera no els afecta. En canvi, si és el servidor qui efectua el tancament

actiu, ens podem trobar que no es pugui reinicialitzar durant 1 o 2 minuts.

I això passa perquè el servidor utilitza ports coneguts que no es poden tor-

nar a reassignar fins que no acaba el procediment quiet time i se surt de l’es-

tat TIME_WAIT.

Pot passar que només tanqui la connexió (sortida de dades) un dels ex-

trems, mentre que l’altre (recepció) es manté obert. Aquesta situació s’ano-

mena half-close, tot i que hi ha poques aplicacions que se n’aprofitin. El

més normal és que totes dues aplicacions tanquin els seus canals de comu-

nicacions. I també es pot donar el cas que dos extrems efectuïn un tanca-

ment actiu. Aquest situació s’anomena tancament simultani (simultaneous

close).

Monitoratge de la terminació d’una connexió utilitzant el programa tcpdump

Utilitzarem el programa tcpdump per a veure com funciona el protocol de terminació dela connexió. Assumim que en l’rlogin de l’exemple d’establiment de la connexió heliosfa un logout (demana el tancament de la connexió).

Les línies que obtenim amb el tcpdump són les següents:

La interpretació és la següent:

1) helios envia un segment amb l’indicador F (FIN). El número de seqüència és el 1.417 i en-via 0 bytes de dades. Espera rebre el byte 41 d’argos i adverteix una finestra de 8.760 bytes.

2) argos envia un reconeixement per mitjà d’un segment amb ACK 1.418 (1.417 + 1) i ad-verteix una finestra de 31.744 bytes.

3) Ara li toca a argos tancar la seva connexió TCP. Amb aquesta finalitat, envia un seg-ment amb l’indicador F (FIN) a helios. El número de seqüència és el 41 (és el que esperaràhelios) i envia 0 bytes de dades. Adverteix una finestra de 31.744 bytes.

4) helios rep el segment, el reconeix amb l’ACK numerat com a 42 (41 + 1) i adverteix unafinestra de 8.760 bytes.

helios ha efectuat un tancament actiu, mentre que argos ha efectuat un tancament passiu.

Activitat

• Utilitzeu el programa tcpdump per a veure el tancament d’una connexió. Amb aquestafinalitat, establiu una connexió amb diferents aplicacions (telnet, rlogin, etc.) i su-perviseu-la.

helios % logout

15:57:01.616091 helios.login > argos.1023: F 1417: 1417 (0) ack41 win 8760

15:57:01.616091 argos.1023 > helios.login: .ack 1418 win 31744

15:57:01.616091 argos.1023 > helis.login: F 41:41 (0) ack 58031744

15:57:01.616091 helios.login > argos.1023: .ack 42 win 8760


Podeu trobar una secció dedicada a aquest tema al llibre:

W.R. Stevens (1994). TCP/IPIllustrated (volum 1: “The Protocols”, cap. 19, pàg. 252, impressió 1998). Wilmington: Addison-Wesley.

Nota

La notació de números de se-qüència i números ACK s’esta-bleix a partir de l’ISN, és a dir, un número de seqüència 1.417indica un número de seqüèn-cia ISN + 1.417.


8.5. Diagrama d’estats del TCP

En el diagrama d’estats del TCP, es descriuen els diferents estats pels quals pas-

sa una connexió des del seu establiment fins a la seva terminació, incloent-hi

l’etapa de transferència de la informació. Els noms dels estats TCP són els ma-

teixos que es poden consultar amb una crida al sistema netstat.

L’estat ESTABLISHED es correspon amb la transferència de la informació. La

resta dels estats es corresponen amb l’establiment i la terminació de la conne-

xió, tenint en compte totes les maneres possibles d’establir i tancar una con-

nexió en el TCP. Els símbols SYN, RST, FIN i ACK es corresponen amb els bits

d’indicació de la capçalera TCP.

Un exemple de com s’interpreta aquest diagrama seria el protocol de termina-

ció d’una connexió, en què ja vam veure que l’extrem TCP que demanava el

tancament efectuava un tancament actiu. Això significa que passaria de l’estat

ESTABLISHED a l’estat FIN_WAIT_1 enviant un segment FIN.


W.R. Stevens (1994). “The Protocols” TCP/IP Illustrated(vol. 1, impressió 1998). Wilmington: Addison-Wesley.


Des d’aquí pot passar a un dels tres estats que descriuen com es pot fer un tan-

cament actiu segons com es tanqui la connexió:

• Amb un tancament simultani (simultaneous close), passa a CLOSING.

• Amb la recepció d’un ACK, passa a FIN_WAIT_2, on espera rebre un FIN.

• Amb la recepció d’un FIN i un ACK, passa a TIME_WAIT, on espera dues

vegades l’MSL abans d’alliberar el port.

Ja hem vist que l’extrem TCP que rep un FIN fa un tancament passiu. Per tant,

passa de l’estat ESTABLISHED a l’estat CLOSE_WAIT enviant els indicadors

ACK i FIN corresponents per a acabar la connexió.

La fase d’establiment també es pot seguir fàcilment per mitjà del diagrama

d’estats, tenint en compte quin extrem fa el tancament actiu i quin fa el tan-

cament passiu.

Activitat

• Utilitzeu el programa netstat per a veure l’estat de les connexions TCP que tingueuen aquest moment. En cas que no tingueu cap aplicació en la xarxa, connecteu-vos aalgun servidor amb el web, feu un ftp o un telnet a alguna màquina.

8.6. Transferència de la informació

Un cop establerta la connexió, el TCP pot començar la transferència de seg-

ments TCP en tots dos sentits. Per a transmetre informació de manera fiable,

el TCP implementa protocols de control d’errors i de flux. Els passos que se-

gueix el TCP per a transferir la informació són els següents:

1) Quan el TCP envia dades, manté un temporitzador (timeout) fins que rep

un reconeixement (ACK) del receptor. Si el temporitzador salta, el TCP retrans-

met les dades.

2) Quan el TCP rep un segment de dades, envia un reconeixement. Aquest re-

coneixement es pot retornar retardat (no immediatament) si el TCP ho consi-

dera necessari.

3) Si un segment rebut és incorrecte (el checksum ho indica), el TCP descarta

el segment i no hauria d’enviar la informació. De fet, com que el TCP utilitza

la tècnica de piggybacking (aprofita els segments de dades que viatgen en sentit

contrari), el que fa és retornar un segment amb el mateix número d’ACK que

havia reconegut la darrera vegada. El transmissor veurà un ACK amb un nú-

mero repetit i assumirà que no li reconeixen la informació*.

En cas que no tingués dades per a enviar en sentit contrari, el TCP pot enviar

un segment que no contingui informació (amb un camp de dades de zero

Vegeu l’MSL en el subapartat 8.4 d’aquest mòdul didàctic.

* Aquest número s’anomena ACKduplicat.


bytes). Aquest segment tindria l’indicador ACK activat i reconeixeria els bytes

pertinents en el camp número d’ACK. Cal observar que el número de seqüència

no s’hauria incrementat, ja que no envia dades.

4) Si els segments arriben desordenats (per sota hi ha l’IP, que és no orientat a la

connexió), el TCP reordena els segments i passa les dades (bytes) correctament or-

denades a l’aplicació. Si rep segments duplicats, el TCP descarta les còpies.

5) Com que el TCP té una memòria limitada, és necessari que efectuï un con-

trol de flux. Amb aquesta finalitat, cada extrem avisa de les dades que està dis-

posat a rebre en cada moment utilitzant el camp de finestra (es tracta d’un

mecanisme de finestra lliscant basat en bytes que explicarem més endavant).

El tipus d’informació que cal enviar es pot dividir en dades interactives* i da-

des de gran volum o bulk data**. La diferència entre aquestes rau en la quanti-

tat d’informació que es transmet. Les dades interactives transmeten pocs bytes

d’informació (entorn de 10), mentre que les dades de gran volum transmeten

gran quantitat de dades (ocupen la totalitat de la mida del segment TCP). Cal

tenir en compte que no és el mateix carregar la xarxa amb paquets petits d’in-

formació que amb paquets grans. El TCP pot aplicar en cada cas tècniques di-

ferents de manera automàtica, per a aprofitar la xarxa al màxim.

8.6.1. Transmissió de dades interactives

En aquest tipus de comunicació, és normal enviar poques dades. En una aplica-

ció del tipus Telnet, per exemple, un usuari client podria executar el comanda-

ment d’UNIX ls i obtenir un llistat d’un directori per part del servidor. En

aquesta transferència d’informació intervenen pocs bytes des de l’origen (client)

fins a la destinació (servidor) i es fan servir conjuntament dues tècniques per a

obtenir un aprofitament millor de la xarxa:

• Reconeixements retardats.

• Algorisme de Nagle.

Reconeixements retardats

En aquest tipus de transferència, és normal que el TCP no enviï els reconeixe-

ments ACK immediatament després de rebre les dades, sinó que estigui un

temps esperant que hi hagi dades per a enviar en sentit contrari. D’aquesta

manera, pot utilitzar la tècnica piggybacking i enviar el reconeixement encap-

sulat en les dades que retornen al client.

És possible que el servidor s’estalviï d’enviar un segment que només reco-

neix, però que no conté dades. És típic que el TCP esperi (utilitza un tempo-

ritzador) uns 200 ms per si hi ha dades per a transmetre abans d’enviar

* Per exemple, les que transmeten aplicacions com ara telnet o

rlogin.** Per exemple, les que transmeten

aplicacions com ara correu electrònic o ftp.


l’ACK. Un cop ha transcorregut aquest temps, el TCP reconeix les dades re-

budes fins al moment amb un segment de dades, si té dades per a enviar en

sentit contrari (piggybacking), o amb un segment sense dades (el número de

seqüència no varia). En qualsevol dels dos casos, l’indicador ACK estarà ac-

tivat i el número ACK reconeixerà les dades pertinents.

El TCP retarda els ACK fins a 200 ms per a aprofitar millor la tècnica de

piggybacking.

Algorisme de Nagle

Moltes vegades un client té molt poques dades per a enviar (per exemple, només

1 byte). El TCP ha d’enviar un segment només amb 1 byte de dades i amb 20 bytes

de capçalera TCP. A més, l’IP hi afegeix 20 bytes més de capçalera, cosa que dóna

un total de 40 bytes de control i 1 de dades. Si es transmeten molts segments

d’aquest tipus, l’eficiència és molt baixa. Una solució a aquesta baixa eficiència de

transmissió és aplicar l’algorisme de Nagle.

Fent servir l’algorisme de Nagle, una connexió TCP només pot tenir un seg-

ment de mida petita (pocs bytes) sense que s’hagi reconegut; és a dir, només

hi pot haver un únic segment de mida petita viatjant per la xarxa (en vol). La

resta dels segments de mida petita no es poden transmetre fins que l’ACK del

segment petit que està viatjant per la xarxa hagi arribat.

Així, els segments que estan esperant per a ser transmesos s’emmagatzemen

fins que es rep l’ACK del segment en vol. Quan l’ACK del segment en vol arri-

ba, la connexió TCP pot enviar un segment que contingui totes les dades em-

magatzemades fins aquest moment, formant un segment més gran.

L’algorisme de Nagle funciona quan els retards en la xarxa són grans, és a dir, si

la connexió travessa una WAN. En cas que la connexió sigui local, en una LAN,

és difícil que s’apliqui aquest algorisme a causa de l’alta velocitat de la xarxa.

De vegades, és interessant desinhibir l’algorisme de Nagle, ja que l’aplicació no

pot esperar. El moviment del ratolí en X Windows System provoca segments pe-

tits. Aquests moviments del ratolí s’han de lliurar sense retards perquè l’usuari

interactiu no ho noti. Les llibreries de sockets han de permetre, activant indi-

cadors , desinhibir l’algorisme de Nagle*.

8.6.2. Transmissió de dades de gran volum. Control de flux

per finestra lliscant

En les comunicacions en què s’envia una gran quantitat de dades de gran vo-

lum (correu electrònic, transferències FTP, etc.), com que les memòries inter-

mèdies de recepció es poden omplir, és necessari un protocol de finestra

lliscant (sliding window) per a controlar el flux de dades.

* En la llibreria de sockets,l’indicador que desinhibeix

l’algorisme de Nagle és el TCP_NODELAY.


El TCP efectua un control de flux per finestra lliscant, amb la diferència, res-

pecte als protocols del nivell d’enllaç, que en el TCP la finestra de transmissió

és variable.

La idea és que cada extrem TCP regula la quantitat de dades que l’altre extrem

pot transmetre. Amb aquesta finalitat, cada extrem TCP avisa, cada vegada

que envia un segment, a l’extrem oposat de la finestra que pot acceptar en

aquest moment. El TCP parell actualitza la seva finestra de transmissió d’acord

amb aquest valor.

Mentre que el TCP transmissor marca els bytes que ha transmès amb un número

de seqüència, el TCP receptor recull els bytes que rep i els reconeix (generalment

mitjançant la tècnica de piggybacking) amb un ACK. Els reconeixements ACK es-

pecifiquen sempre el número de seqüència del proper octet que el receptor es-

pera rebre.

El TCP només activa un temporitzador de retransmissions que reprograma

quan rep un reconeixement o quan salta el temporitzador. Més endavant veu-

rem com el TCP programa el temporitzador de retransmissions. La capçalera

del segment TCP especifica tres paràmetres essencials en el funcionament del

protocol de finestra lliscant:

• El número de seqüència, que indica a la seva connexió oposada el primer

byte de dades que conté el segment transmès.

• El número de reconeixement (número ACK), que indica a la seva conne-

xió oposada el proper byte que espera rebre i, per tant, el darrer byte rebut

correctament. Cal recordar que el TCP és bidireccional i que un segment

TCP reconeix, mitjançant piggybacking, les dades que rep amb un ACK que

ha d’estar numerat.

• La finestra, que indica a la seva connexió oposada la mida de la memòria

intermèdia de recepció i, per tant, la mida de la finestra que el transmissor

ha d’utilitzar.

Activitat

• Assumim que un extrem client TCP ha triat el 28.325 com a número de seqüència ini-cial (ISN), mentre que l’extrem servidor TCP ha triat com a ISN el 12.555. Què indicaun segment client TCP amb número de seqüència 29.201, número ACK 12.655 i fines-tra 1.024?

Un reconeixement reconeix posicions de bytes en el flux de dades fins

a la darrera posició que ha rebut correctament, sense tenir en compte el

segment al qual pertanyen.


Solució

El número de seqüència indica que el client ja ha transmès des del byte 28.325 finsal byte 29.200 (875 bytes en total) i que en aquest segment transmetrà a partir delbyte 29.201. El número ACK indicarà al servidor que el client ha rebut correctamentfins al byte 12.654 i que espera rebre a partir del 12.655. La finestra indica al servidorque el client només pot acceptar 1.024 bytes abans de confirmar-los. Per tant, el ser-vidor TCP actualitzarà la seva finestra de transmissió a 1.024.

A fi d’estudiar el mecanisme de finestra lliscant, analitzarem un cas senzill. As-

sumirem que ja s’ha establert la connexió i s’han assignat els ISN per a tots dos

extrems.

En la figura següent, podem veure com funcionaria el protocol de finestra

lliscant per al TCP transmissor. El TCP receptor li ha indicat que està dis-

posat a rebre 7 bytes. Per tant, la finestra de transmissió del TCP transmis-

sor és de 7 bytes.

Podem interpretar la finestra lliscant de la manera següent:

1) El TCP ja ha enviat bytes fins al número de seqüència 1.003. D’aquests

bytes, el TCP receptor li n’ha reconegut fins al 999; manquen per reconèixer-

li els bytes 1.000 a 1.003.

2) Com que la finestra de transmissió és de 7 bytes i n’ha transmès 4, el TCP

encara pot transmetre 3 bytes abans d’exhaurir-la (bytes 1.004 a 1.006).

3) El TCP només podrà transmetre del byte 1.007 en endavant en els casos se-

güents:

• Si el TCP receptor li reconeix els bytes a partir del 1.000, de manera que el

límit esquerre de la finestra es mourà cap a la dreta.


• Si el TCP receptor li adverteix d’una finestra superior a 7, de manera que el

límit dret de la finestra es mourà cap a la dreta.

• Una combinació de les dues solucions anteriors.

Com podeu observar, el TCP receptor pot advertir una nova finestra de trans-

missió. Cada vegada que reconegui dades, avisarà de la nova finestra que està

disposada a rebre. El TCP transmissor actualitzarà aquesta nova finestra.

Alguns punts que podem resumir de la figura de la finestra lliscant són els se-

güents:

• Si el límit esquerre ateny el límit dret, es diu que la finestra val zero (zero

window). Això fa que el transmissor aturi l’enviament de dades.

• Es recomana que el TCP transmissor no encongeixi la finestra de trans-

missió.

• Hem de distingir el fet que la finestra s’encongeixi (el límit dret es mou cap

a l’esquerra) del fet que la finestra disminueixi de mida (s’adverteix una fi-

nestra més petita però el límit dret no es mou cap a l’esquerra).

Diferència entre encongiment i disminució de mida de la finestra

Suposem una finestra de 7 bytes com en la figura de la finestra lliscant. El receptor reco-neix els bytes 1.000 a 1.003 i adverteix una finestra de 5 bytes. Com podeu deduir, el lí-mit esquerre val ara 1.004; el límit dret, 1.008 (s’ha mogut cap a la dreta), i la novafinestra, 5. En aquest cas, la finestra de recepció s’ha reduït, però no s’ha encongit.

En canvi, si el receptor només reconeix 1 byte (el byte 1.000) i adverteix una finestrad’1 byte, el transmissor es trobarà amb un problema. Una finestra d’1 byte significa quenomés en podia haver transmès 1 (el 1.001), però ja n’havia transmès 3, incloent-hi elreconegut (del 1.000 al 1.003). Per tant, el receptor s’ha d’assegurar d’advertir almenystants bytes com el transmissor li pot haver enviat amb la finestra anterior. Si nomésreconeix 1 byte, la finestra advertida ha de ser de 6 bytes; si reconeix els 4 bytes, aquestaha de ser, almenys, de 3 bytes, ja que el transmissor ja els podria haver transmès.

Exemple de funcionament del protocol de finestra lliscant

Utilitzarem el programa tcpdump per a veure com funciona el protocol de finestra llis-cant. Assumim que hem efectuat un rlogin d’argos a helios (argos % rlogin helios)i ja estem connectats a helios. Un cop som a helios, executem el comandament ls. Aquest

La finestra pot experimentar tres tipus de moviments:

1) La finestra es tanca en moure’s el límit esquerre cap a la dreta quan

les dades enviades són reconegudes.

2) La finestra s’obre en moure’s el límit dret cap a la dreta i permet que

el TCP enviï més dades. Aquesta obertura té lloc quan el receptor allibe-

ra espai de la seva memòria i pot advertir una nova finestra.

3) La finestra s’encongeix quan el límit dret es mou cap a l’esquerra.


retorna per sortida estàndard el llistat de directoris del directori de l’usuari (home directory) enhelios que ocupen 811 caràcters (representa l’enviament de 811 bytes).

Les línies que obtenim amb el programa tcpdump (numerades de l’1 al 13) són les següents:

La interpretació d’aquestes línies és la següent: argos ja ha enviat 36 bytes, mentre quehelios ja n’ha enviat 595 (informació que tots dos han intercanviat des del començamentde la connexió, com poden ser logins, usernames, etc.). Deduïm aquesta informació de laprimera línia de l’exemple.

1) argos envia el caràcter ‘l’. L’indicador P assenyala PUSH. El número de seqüènciaavança de 37 a 38.

2) helios retorna un eco del caràcter ‘l’. El seu número de seqüència avança de 596 a 597i reconeix el byte rebut (ACK = 37 + 1 = 38).

3) argos reconeix l’eco: ACK = 597 + 1 = 598.

4) argos envia el caràcter ‘s’. El número de seqüència avança de 38 a 39. L’ACK no reco-neix res perquè val igual que abans: ACK = 597.

5) helios fa un eco que ocupa 3 bytes (BS* + 1 + s). El número de seqüència avança tresposicions (de 597 a 600) i reconeix el caràcter ‘s’ , ja que ACK = 38 + 1 = 39.

6) argos reconeix l’eco amb un ACK = 600.

7) argos envia el retorn de carro (CR). El número de seqüència avança una posició.

8) helios fa un eco del CR i, a més, retorna un altre CR seguit d’un LF*. Això significal’enviament de 3 bytes. Reconeix el CR, ja que ACK = 40.

9) argos reconeix aquests tres caràcters.

helios % ls

1) 15:56:59.506091 argos.1023 > helios.login: P 37:38 (1)ack 596win 31744

2) 15:56:59.516091 helios.login > argos.1023: P 596:597 (1) ack38 win 8760

3) 15:56:.59.526091 argos.1023 > helios.login: .ack 597 win31744


5) 15:56:59.856091 helios.login > argos.1023: : P 597:600 (3) ack39 win 8760

6) 15:56:59.866091 argos.1023 > helios.login: .ack 600 win 31744






12) 15:57:00.166091 helios.login > argos.1023: P 658:1414 (756)ack 40 win 8760

13) 15:57:00.176091 argos.1023 > helios.login: .ack 1414 win31744

Recordeu

PUSH indica al receptor que passi les dades immediatamenta l’aplicació, és a dir, que no les deixi durant un temps en la memòria intermèdia de recepció).

* BS és la sigla de back space.

* LF és la sigla de line feed.


10) helios respon a ‘ls’ enviant 55 dels 811 bytes que ha d’enviar. El número de seqüènciaavança de 603 a 658. L’ACK resta a 40.

11) argos reconeix aquests 55 bytes enviant un ACK de 659.

12) helios transmet la resta dels 811 bytes, és a dir, 756 bytes.

13) argos reconeix aquests bytes avançant l’ACK a 1.414.

Com podem veure en aquest exemple, el TCP divideix la informació a enviar en dos seg-ments: un segment de 55 bytes i un altre de 756 bytes. Cal remarcar que rlogin enviaels comandaments caràcter a caràcter i, a més, l’aplicació remota fa un eco d’aquests ca-ràcters. Per això en les primeres línies s’envia primer la ‘l’, després la ‘s’, després el retornde carro, etc. El que ens interessa d’aquest exemple és veure com avancen les finestres enemetre i en reconèixer bytes. Per tant, no justificarem per què rlogin retorna ecos ni perquè afegeix un caràcter LF al retorn de carro.

8.6.3. Temporitzadors i retransmissions

El TCP activa fins a quatre temporitzadors de diferent tipus per a aconseguir

un lliurament fiable de la informació. En aquest subapartat ens centrarem úni-

cament en el temporitzador de retransmissions o RTO*.

Cal recordar que tant els segments com els reconeixements es poden perdre

durant la transmissió, de manera que cal utilitzar un temporitzador de retrans-

missions.

Com ja hem esmentat, el temporitzador es programa cada vegada que es rep

un reconeixement, o bé quan salta perquè el reconeixement no ha arribat a

temps (o, simplement, no ha arribat).

El més lògic seria activar el temporitzador de retransmissió en el temps d’ana-

da i tornada (RTO = RTT). Però és evident que els retards que experimenten els

segments són variables: si s’activa l’RTO a l’RTT que ha experimentat el seg-

ment anterior, no es pot assegurar que aquest segment no tingui un retard su-

perior i que el temporitzador no salti abans de temps. Hi ha diferents

alternatives per a programar el temporitzador que explicarem tot seguit:

• Algorisme de retransmissió adaptatiu

• Algorisme de Jacobson per a calcular l’RTO

• Algorisme de Karn

• Algorisme slow start

• Algorisme congestion avoidance

• Temporitzador keepalive

Definim el temps d’anada i tornada o RTT* com el temps que trans-

corre des que es transmet un segment fins que és reconegut (l’ACK tor-

na al transmissor). L’RTT es pot mesurar restant l’instant en què el TCP

transmissor emet el segment i l’instant en què rep l’ACK.

* RTO és la sigla de retransmissiontime out.

* RTT és la sigla de round trip time.


Algorisme de retransmissió adaptatiu

S’utilitza una estimació de l’RTT que tingui en compte l’RTT mesurat i el seu

últim valor estimat de l’RTT. El nou RTT estimat (Est_RTT) es calcula de la ma-

nera següent:

Est_RTT = α · Est_RTT + (1 -α) · M_RTT.

Es recomana que el temporitzador valgui:

RTO = β · Est_RTT.

El problema d’aquesta aproximació és que no té en compte les fluctuacions de

l’RTT. Això fa que hi hagi més retransmissions de les necessàries. Per a solucio-

nar aquest problema, es va proposar un estimador de l’RTT que tingués en

compte la variància de l’RTT.

Algorisme de Jacobson per a calcular l’RTO

Aquest algorisme millora el càlcul del temporitzador de l’algorisme de re-

transmissió adaptatiu. Jacobson va proposar calcular el temporitzador de

retransmissions RTO utilitzant la mitjana i la variància de l’RTT.

Tenim que MRTT és la mitjana estimada de l’RTT i que SRTT és la desviació es-

tàndard estimada. D’aquesta manera, el temporitzador tindrà en compte les

fluctuacions en el retard que pot experimentar un segment en travessar equips

intermedis en una xarxa. L’algorisme consisteix en els passos següents:

Podem notar que el càlcul de la mitjana MRTT és equivalent a l’estimador adap-

tatiu, amb la diferència que g = (1 - α) i α pren un valor diferent. Finalment, el

temporitzador s’actualitza com una funció de la mesura i de la desviació estàn-

dard (o variància, ja que estan relacionades) de l’RTT:

RTO = MRTT + 2 · SRTT per al primer temporitzador.

RTO = MRTT + 4 · SRTT a partir del primer temporitzador.

Algorisme de Karn

Quan el temporitzador salta, el segment es retransmet i el TCP reprograma

el temporitzador. Suposem que a continuació es rep un ACK. El TCP no té

manera de saber a qui pertany (al primer segment o a la seva retransmissió),

M_RTT és l’últim RTT mesurat (M_RTT o Measured RTT) i α és un

factor el valor del qual es recomana que sigui 0,9 (el 90% del valor de la

nova estimació prové de l’última estimació de l’RTT i el 10% restant,

de l’última mesura de l’RTT).

β és el factor de variació del retard i es recomana que valgui 2.

Les variables MRTT i SRTTs’inicialitzen a 0 i 3 segons

respectivament, i el valor de gés 1/8 i el de h és 1/4.


ja que l’ACK només indica el proper byte que espera rebre. Aquesta situació

s’anomena problema d’ambigüitat en les retransmissions i afecta la mane-

ra de recalcular l’RTO, ja que aquest depèn de les mesures de l’RTT que fem.

És a dir, hem de pensar que un dels paràmetres que s’utilitza per a calcular el

valor del temporitzador és la mesura del temps d’anada i tornada (M_RTT). Si

per a mesurar l’RTT, el TCP fa servir l’ACK que arriba després d’haver retrans-

mès un o diferents segments i es produeix un problema d’ambigüitat en les re-

transmissions, el TCP pot computar valors que no són reals amb la situació

actual de la xarxa. Per a evitar això, s’utilitza l’algorisme de Karn.

L’algorisme de Karn diu que l’RTO només es recalcularà mitjançant una esti-

mació de l’RTT (és a dir, utilitzant un algorisme com el de Jacobson) si el reco-

neixement pertany a un segment no retransmès. Quan es produeix una

retransmissió, es fa servir un algorisme de back-off exponencial per a doblar el

valor del temporitzador.

L’algorisme de back-off dobla el valor de l’últim RTO fins a un límit de 64 segons.

Quan es rebi un ACK d’un segment que no s’ha retransmès, es torna a prendre

una mesura de l’RTT i s’aplica novament l’algorisme de Jacobson. Experimen-

talment, s’ha comprovat que aquest algorisme funciona molt bé fins i tot quan

la xarxa experimenta moltes pèrdues de dades.

Algorisme slow start

Moltes vegades el transmissor comença emetent el major nombre de segments

possible (tants com li permet la seva finestra). Un cop ha exhaurit la finestra,

el transmissor espera que el receptor li reconegui les dades i l’adverteix de no-

ves finestres per a continuar funcionant i emetre més dades. Però en una xarxa

hi ha equips intermedis (encaminadors, commutadors, etc.) que es poden

congestionar. Per tant, no podran emmagatzemar tanta informació com el

transmissor està emetent.

Els equips intermedis es poden congestionar per moltes raons: per exemple, a causa d’unencaminador amb enllaços d’entrada a alta velocitat i enllaços de sortida a baixa veloci-tat, o amb una CPU lenta o amb memòria intermèdia petita.

També cal tenir en compte que l’encaminador, a més de retransmetre la informació, l’had’encaminar. Per tant, no tan sols ha de processar els datagrames IP que rep, sinó que devegades ha de computar algorismes d’encaminament.

És molt possible que aquests equips, per a descongestionar-se (tenen les me-

mòries intermèdies completes), descartin datagrames IP. Al capdavall, per da-

munt de l’IP hi ha un protocol de retransmissions (TCP) que retransmetrà tota

la informació que no hagi arribat a la seva destinació.

El problema ve quan el TCP s’adona que la informació no ha arribat a la seva

destinació (els datagrames IP amb aquesta informació han estat descartats per

l’encaminador) i torna a retransmetre la finestra. L’encaminador es torna a


trobar amb la mateixa situació, o fins i tot pitjor*, i torna a descartar datagra-

mes IP d’aquesta connexió.

L’encaminador necessita alleujar la congestió, és a dir, que les connexions no

li enviïn gaires datagrames IP i així tingui temps de recuperar-se. Un algorisme

que el TCP pot implementar per a evitar congestionar els equips intermedis de

la xarxa és l’slow start.

L’algorisme slow start permet que el transmissor incrementi el nombre de seg-

ments que cal transmetre exponencialment cada vegada que rebi un reconei-

xement. El transmissor comença transmetent un sol segment.

L’slow start defineix una segona finestra a la qual anomena finestra de congestió.

L’algorisme funciona de la manera següent:

1) La finestra de congestió s’inicialitza al valor d’un segment de mida màxima

(MSS bytes).

2) Cada vegada que es rep un ACK, la finestra de congestió s’incrementa en

un segment (en MSS bytes).

3) El transmissor pot emetre el mínim entre la finestra de transmissió i la fi-

nestra de congestió.

D’aquesta manera, el transmissor no enviarà inicialment tota la seva finestra

de transmissió. A mesura que rep l’ACK, assumeix que no hi ha congestió i in-

crementa lentament la quantitat de dades que cal transmetre.

La finestra de transmissió és un control de flux imposat pel receptor, mentre

que la finestra de congestió és un control de flux imposat pel transmissor. Cal

tenir en compte que l’increment de la finestra de congestió és exponencial.

Inicialment, val un segment. Quan el transmissor rep un ACK, incrementa la

finestra de congestió a dos segments. Ara rebrà 2 ACK, de manera que la podrà

incrementar a quatre segments. I així contínuament.

Algorisme congestion avoidance

L’algorisme slow start evita que es congestioni un equip intermedi que no està

congestionat inicialment. Però això no és suficient per a evitar la congestió:

en algun moment la finestra de congestió serà més gran que la finestra de

transmissió, de manera que el TCP sempre transmetrà tota la seva finestra. Si

l’equip intermedi es congestiona, s’ha de disminuir el nombre de segments

que cal transmetre i tornar a aplicar un algorisme com l’slow start.

*La raó d’aquest empitjorament és que l’encaminador rep de nou els datagrames de les connexions que

havia rebutjat i tots al mateix temps, la qual cosa no l’ajuda a

eliminar la congestió.

Quan l’algorisme slowstart...

... incrementa la finestra de congestió en un segment, el que fa és considerar un seg-ment com el nombre de bytes que ocupa un segment de mida màxima.


Sabrem que hi ha congestió quan el receptor no reconegui les dades. Això vol

dir que el temporitzador de retransmissió saltarà perquè no ha arribat un ACK

o perquè ha arribat un ACK amb el mateix número que l’anterior (se l’anome-

na ACK duplicat).

L’algorisme de congestion avoidance redueix la finestra de congestió a la meitat

cada vegada que es perd un segment, i redueix la congestió en la xarxa. Per a

fer-ho, defineix un llindar (threshold) i treballa conjuntament amb l’slow start

de la manera següent:

• El TCP inicialitza el llindar (threshold) a 65.535 bytes i la finestra de congestió

a un segment (MSS bytes). El transmissor inicialment està en estat slow start.

• El transmissor envia dades d’acord amb l’algorisme slow start.

• Si el transmissor detecta congestió (el temporitzador salta o rep un ACK du-

plicat), actualitza el valor del llindar a la meitat del valor de la finestra de

congestió que hi ha en aquest moment, però mai per sota de dos segments,

i reinicialitza la finestra de congestió a un segment tornant a l’estat slow

start:

threshold = max(2, MSS (finestra de congestió) / 2)

• Quan rep un ACK, ha d’incrementar el valor de la finestra de congestió te-

nint en compte les situacions següents:

– Si la finestra de congestió és més petita o igual que el llindar, el transmissor

està en un estat de congestion avoidance i la finestra de congestió s’incre-

menta en 1 segment cada vegada que es rep un ACK. L’increment és expo-

nencial, ja que es correspon amb l’algorisme slow start.

– Si la finestra de congestió és més gran o igual que el llindar, el transmissor

està en un estat de congestion avoidance i la finestra de congestió s’incre-

menta en 1/(finestra de congestió) cada vegada que es rep un ACK, de ma-

nera que l’increment és lineal.

Temporitzador keepalive

Quan una connexió TCP no disposa de dades per a emetre, no s’envia cap ti-

pus d’informació (per exemple, de control) entre el client i el servidor. Això

vol dir que la connexió pot restar hores o dies oberta si l’aplicació no la tanca.

Es podria donar el cas que la màquina hagi caigut, o hagi rebotat, en un dels

extrems i que l’altre no se n’hagi adonat perquè no hi ha hagut cap tipus d’in-

tercanvi d’informació entre els extrems. El temporitzador keepalive no forma

part de l’especificació TCP, tot i que és interessant saber què fa, ja que hi ha

algunes versions TCP que l’implementen. Es recomana que sigui l’aplicació la

Recordeu...

... que un ACK duplicat és un segment amb el mateix nú-mero ACK que el segment an-terior.

Keepalive

El valor per defecte del tempo-ritzador és de dues hores, tot i que es pot activar amb un al-tre valor.


que activi aquest temporitzador si li interessa. Si no hi ha activitat durant dues

hores (valor del temporitzador keepalive), el servidor envia un segment de pro-

va al client.

Es poden donar quatre situacions:

• Si el client encara corre, respon, i el servidor reinicialitza el temporitzador

keepalive dues hores després. Si durant aquestes dues hores hi ha intercanvi

de dades, el temporitzador es reinicialitza dues hores després d’aquest.

• Si el TCP client ha caigut i no ha rebotat, el servidor envia fins a deu seg-

ments de proves cada 75 segons. Si no rep resposta, el servidor tanca la con-

nexió.

• Si la màquina client ha caigut i ha rebotat, el servidor rebrà una resposta

perquè tanqui la connexió.

• El client està corrent, però no és assequible (per exemple, ha caigut algun

encaminador i no hi ha manera d’arribar-hi). Aquesta situació és equiva-

lent a la segona, ja que el servidor no té manera de saber si el client no és

assequible a causa d’una fallada de la xarxa o d’una caiguda de la màquina.

Si la màquina client simplement ha rebotat, el procés aplicació client haurà

tancat la connexió TCP enviant un segment FIN al servidor.


Resum

L’objectiu principal d’aquest mòdul didàctic ha estat introduir els protocols

que s’utilitzen en la xarxa Internet. Aquests protocols són, en el nivell d’inter-

connexió, l’IP i associats, i en el nivell de transport, l’UDP i el TCP.

S’ha posat especialment l’èmfasi en l’encapsulament de la informació i la

seva relació amb els protocols orientats al nivell de xarxa (per exemple, PPP i

Ethernet).

Un dels punts més importants en l’estudi d’Internet és l’adreçament. Cada in-

terfície en la xarxa Internet ha de tenir una adreça IP que la identifiqui en la

xarxa. Aquesta adreça ha de ser única. Les adreces IP no identifiquen només

les interfícies de la xarxa, sinó que també identifiquen la xarxa o subxarxa a la

qual pertany la interfície. D’aquesta manera, és possible encaminar els data-

grames IP d’un encaminador a un altre utilitzant la identificació de xarxa de

l’adreça IP.

A més del protocol IP, en el nivell d’interconnexió es defineixen diferents pro-

tocols associats a IP. Entre els més significatius hi ha l’ARP, per al mapatge

d’adreces IP en adreces físiques, o l’ICMP, per a comunicar missatges d’errors

i altres condicions que requereixen l’atenció del protocol IP.

L’objectiu principal del nivell de transport és lliurar la informació als nivells

orientats a l’aplicació en els extrems de la xarxa. En la jerarquia de protocols

TCP/IP es defineixen dos protocols de transport:

1) L’UDP, que és un protocol no orientat a la connexió. Per tant, no efectua

cap control d’errors ni de flux. Si un datagrama UDP arriba equivocat (l’UDP

utilitza un codi detector d’errors), l’UDP el descarta i no el lliura a l’aplicació.

Aquesta haurà de ser capaç de respondre a aquest tipus de servei o haurà d’as-

sumir la pèrdua de la informació. Aquest tipus de servei pot ser útil en aplica-

cions en temps real, en què és més important que la informació arribi quan li

pertoca, és a dir, amb un retard delimitat, que no pas que se’n perdi una part.

2) El TCP, que és un protocol orientat a la connexió. Hi haurà una fase d’es-

tabliment de la connexió (l’anomenat procediment three-way handshake), una

fase de transmissió de la informació i una fase de terminació de la connexió.

El TCP lliurarà la informació a l’aplicació totalment lliure d’errors. Per a acon-

seguir-ho, necessita efectuar un control d’errors i de flux. El TCP utilitza un

codi detector d’errors conjuntament amb un protocol de retransmissions per

a recuperar la informació errònia. Com que les memòries intermèdies de recep-

ció es poden desbordar, el TCP fa servir un control de flux per finestra lliscant.


El TCP ha de dimensionar correctament els temporitzadors de retransmissió.

Hi ha diferents algorismes, entre els quals destaca el de Jacobson, basat en una

estimació de l’RTT (temps d’anada i tornada de la informació entre els extrems

TCP), i el càlcul de la mesura i la variància de l’RTT. També hem estudiat els

algorismes que el TCP utilitza per a alleujar la congestió en la xarxa: slow start

i congestion avoidance.


Exercicis d’autoavaluació

1. Enviem 8.192 bytes travessant quatre encaminadors (assumim que els encaminadors sóndel tipus store and forward, cada un dels quals connectat a una línia telefònica T1 a 1.544.000bps). Considerem que el temps de propagació entre el primer i l’últim encaminador és unaconstant K.a) Quin és el temps màxim per a transmetre la informació si la longitud del segment de dadesés de 4.096 bytes?b) Quin és el temps màxim per a transmetre la informació si la longitud del segment de dadesés de 512 bytes?

2. Quan s’estableix una connexió entre les estacions argos i helios, té lloc el procés següent:

El primer temporitzador d’argos s’inicialitza a 6 segons. Determineu quant valen el segon i eltercer temporitzador d’argos.

3. Un TCP transmissor ha advertit, durant l’establiment d’una connexió, un MSS de 512 bytesi durant la transferència de la informació adverteix una finestra de 512 bytes. Un TCP receptoradverteix finestres de 2.048 bytes. Dibuixeu un diagrama de temps en què es percebi l’algoris-me slow start.

15:56:54.796091 argos.1023 > helios.login S 3541904332: 3641904331 (0)win 31744 <mss 1460>



15:57:13.797035 helios.login > argos.1023 S 548133143: 548133143 (0)ack 34519043333 win 8760 <mss 1460>

15:56:54.797035 argos.1023 > helios.login .ack 548133144 win 31744

Nota

Aquest exercici té com a finalitat esbrinar si és millor utilitzar segments grans o petits en la transmisió de dades, i està proposat a:

W.R. Stevens (1994).


Solucionari

Exercicis d’autoavaluació

1.

a) En el primer cas, utilitza segments amb un MSS igual a 4.096 bytes. Per tant, necessita dossegments. Cal afegir a aquests segments els 40 bytes de capçalera TCP i IP. Per tant, els enca-minadors transmetran paquets de (4.096 1 40) bytes. Com que apliquem la tècnica d’store andforward, per a transmetre un paquet necessitem aquest temps:

El temps que es necessita per a transmetre la totalitat de la informació serà la propagació més elnombre de paquets (n), més el nombre d’enllaços (E) menys 1 per la transmissió. Hi ha n = 2 pa-quets i el nombre d’enllaços és de E =3. Això significa el següent:

TTOTAL = K + (n + E - 1) · T4.096 = K + 4 · T4.096 = K + 85,6 ms.

b) Si els segments tenen un MSS de 512 bytes, aleshores hi haurà 16 paquets (n = 16). El tempsde transmisió de cada paquet serà el següent:

En total trigarem:

TTOTAL = K + (n + E − 1) · T512 5 = K + 18 · T512 = K + 52,2 ms.

Per tant, el retard total, si utilitzem un MSS més petit, és més petit que si en fem servir un demés gran. Però això no vol dir que sigui millor enviar segments amb MSS petits. Hi ha altresfactors que argumenten que, encara que el retard sigui més petit, “costa” més enviar moltspaquets petits que pocs de grans. La reducció del cost en enviar paquets grans s’aconsegueixen els costos associats a la xarxa, com ara la relació entre la mida de les dades i la capçalera,les decisions d’encaminament (com més paquets, més decisions) i el cost del procés en elsprotocols (com més paquets, més interrupcions).

Hi ha autors que estan a favor de mides grans i d’altres que estan a favor de mides petites.

2. El primer Tout està inicialitzat a 6 segons. De les traces del tcpdump podem deduir que elservidor en helios no respon i que el temporitzador ha saltat. argos ha retransmès una peticióde connexió i activa el temporitzador mitjançant l’algorisme de Karn, és a dir, mitjançantl’algorisme de back off per a calcular el nou valor del Tout:

T’out = 2 Tout = 12 s.

T4.0964.096 40+( ) 8 bits⋅1.544.000 bits/s

------------------------------------------------------ 21 4 ms.,= =

T512512 40+( ) 8 bits⋅1.544.000 bits/s------------------------------------------------ 2 9 ms.,= =


helios no respon a la segona petició d’argos. Per tant, després de 12 segons, el temporitzadorsalta i argos torna a retransmetre la petició de connexió. Ara torna a utilitzar l’algorisme deback off per a calcular el temporitzador. Això significa que Tout valdrà el següent:

T’’out = 2 · T’out = 24 s.

3. El diagrama de temps en què es representa l’algorisme slow start per la transimissió indi-cada és el següent:

Com es pot observar, l’slow start comença enviant un segment de mida MSS. Inicialment, lafinestra de congestió és igual a MSS (512 bytes) i la finestra de transmissió té una longitud de2.048 bytes. La seqüència d’esdeveniments és la següent:

a) El TCP transmissor envia un segment de mida MSS = 512 bytes. El TCP receptor reconeixaquests 512 bytes amb un ACK.

b) L’slow start incrementa la seva finestra de congestió a dos segments:

Finestra de congestió = 2 · MSS = 1.024 bytes.

Pot enviar el mínim entre la finestra de congestió i la finestra de transmissió. Això significaque pot enviar 1.024 bytes. Com que la mida màxima dels segments és de 512 bytes, alesho-res transmet dos segments. El TCP receptor reconeix aquests 1.024 bytes amb un ACK.

c) L’ACK reconeix dos segments; per tant, l’slow start pot incrementar la finestra de con-gestió en un segment per cada un dels ACK que rep. Encara que físicament només rebiun sol ACK, aquest val per dos. Per tant, la finestra de congestió augmenta de dos seg-ments a quatre:



Ara pot transmetre el mínim entre la finestra de congestió i la finestra de transmissió. Aixòsignifica que pot transmetre 2.048 bytes dividits en quatre segments de mida màxima. El re-ceptor reconeix aquests quatre segments amb un ACK.

d) El TCP transmissor rep un ACK que val per quatre segments. Incrementa la finestra de con-gestió a 8 segments:


Però la finestra de transmissió continua valent 2.048 bytes. Això vol dir que no pot transme-tre més de 2.048 bytes, és a dir, quatre segments de mida màxima.

Glossari

address resolution protocol m Vegeu ARP

ARP m Protocol per al mapatge automàtic d’adreces MAC amb adreces IP.en address resolution protocol

bridge m Vegeu pont.

commutador m Equip per a la interconnexió de terminals d’una mateixa LAN. N’hi ha al-gun tipus que permet la interconnexió de diferents concentradors.en switch

concentrador m Equip per a la interconnexió de terminals d’una mateixa LAN. Tots elsequips interconnectats mitjançant un concentrador pertanyen a un mateix domini de col·li-sió.en hub

Ethernet m Estàndard de facto parcialment compatible amb l’IEEE802.3. Tots dos utilitzenl’algorisme CSMA/CD 1 –persistent a 10 Mbps o 100 Mbps. Ethernet (xarxa d’èter) fa al·lusiótant al fet que antigament es creia que l’espai que separava els astres estava format per unmaterial (èter) capaç de transportar la llum, com al fet que l’arquitectura de la seva xarxacompetidora, la Token Ring, necessitava bastants més elements, a part de l’èter.

firewall m Vegeu tallafocs.

hacker m Individu (en argot) que es dedica a entrar en sistemes aliens mitjançant la xarxa,aprofitant defectes de la seva configuració o gestió, o bé defectes dels sistemes que la compo-nen.

hub m Vegeu concentrador.

ICMP m Protocol de nivell de xarxa emprat només per a tasques de gestió del nivell de xarxa.en Internet control message protocol

IEEE m Associació dels EUA dedicada, entre altres coses, a tasques d’estandardització.en Institute of Electric and Electronic Engineers

Institute of Electric and Electronic Engineers m Vegeu IEEE.

Internet control message protocol m Vegeu ICMP.

Internet protocol m Vegeu IP.

IP m Protocol de nivell de xarxa utilitzat a Interneten Internet protocol

initial sequence number m Vegeu ISN.

integrated services digital network f Vegeu XDSI.

ISN m Número de seqüència inicial que és assignat al començament de la connexió. A partird’aquest moment, el TCP numera els bytes consecutivament a partir d’aquest número.en initial sequence number

LAN f Xarxa d’àrea local.en local area network

local area network f Vegeu LAN.


MAC m Protocol de control d’accés al medi utilitzat per les estacions d’una mateixa xarxad’àrea local com, per exemple, Ethernet o IEEE802.5 (Token Ring).en medium access control

maximum segment size f Vegeu MSS.

medium access control m Vegeu MAC.

MSS f Defineix a longitud màxima de dades que el TCP enviarà. S’especifica durant l’establi-ment de la connexió.en maximum segment size

pont m Tipus de commutador utilitzat per a interconnectar les LAN.en bridge

read only memory f Vegeu ROM.

ROM f Memòria només de lectura utilitzada per a emmagatzemar dades i/o programes petits.en read only memory

switch m Vegeu commutador.

tallafocs m Encaminador amb capacitat de filtratge de paquets d’acord amb unes regles es-tablertes. Aquestes regles es defineixen en cada instal·lació d’acord amb els problemes de se-guretat de la xarxa en què s’instal·la.en firewall

XDSI f Xarxa digital de serveis integrats.en integrated services digital network

Bibliografia

Chapman, D.B.; Zwicky, E.D. (1995). Building Internet Firewalls. Sebastopol: O’Reilly &Associates, Inc.

Comer, D.E. (1995). “Principles, Protocols and Architecture”. Internetworking with TCP/IP(volum 1). Hertfordshire: Prentice Hall.

Stevens, W.R. (1994). “The Protocols”. TCP/IP Illustrated (volum I, impressió 1998).Wilmington: Addison-Wesley.

Thomas, S.A. (1996). IPng and the TCP/IP protocols, implementing the next generation Internet.Nova York: John Wiley & Sons, Inc.

Wright, G.R.; Stevens, W.R. (1995). “The implementation”. TCP/IP Illustrated (volum II).Wilmington: Addison-Wesley.


Annexos

Annex 1

Aplicacions esmentades en el text

1) Aplicacions estàndard

A continuació mostrem les aplicacions estàndard que s’han explicat en aquest mòdul didàc-tic i indiquem els sistemes en què es poden trobar i quines utilitats tenen:

• ping [UNIX, NT, MSWindows]: mitjançant paquets ICMP (del tipus petició d’eco i respos-ta d’eco) permet saber si una màquina està funcionant o no i tenir una idea de quin és elretard d’anada i tornada (round-trip). També permet saber per quines màquines passa el pa-quet fins que arriba a destinació. Per a aquesta funció, va més bé el programa traceroute,a causa de les limitacions inherents als paquets ICMP.

• traceroute [UNIX, NT: tracert, MSWindows: tracert]: permet esbrinar la ruta quese segueix des de l’equip local fins a una destinació qualsevol d’Internet. Marca els retardsque hi ha a cadascun dels nodes que cal travessar. Es basa en el camp TTL del paquet IP iels missatges ICMP time-to-live-exceeded. Aquesta aplicació no està disponible en algunesdistribucions d’UNIX; sí que es pot aconseguir com a programa de lliure distribució (free-ware) en codi font (llenguatge C).

• arp [UNIX, NT, MSWindows]: permet consultar i modificar la taula ARP (cau ARP) d’unamàquina.

• route [UNIX, NT, MSWindows]: serveix per a consultar i modificar la taula d’encamina-ment IP d’una màquina connectada a Internet.

• ifconfig [UNIX, NT: ipconfig, MSWindows: ipconfig]: permet consultar l’estat deles targetes de xarxa disponibles en el sistema local.

• netstat [UNIX, NT, MSWindows]: dóna estadístiques dels protocols TCP i UDP. Permetllistar els ports que s’escolten. Mostra l’estat en què es troben els sockets TCP. Si voleu unllistat de tots els sockets actius i ports oberts, feu netstat -a, i, si us interessen altres va-riants, consulteu l’ajuda (netstat -help en Windows, o man netstat en UNIX).

• telnet [UNIX, NT, MSWindows]: ofereix, a part de la principal emulació de terminal,connectar i experimentar els protocols ASCII.

2) Aplicacions no estàndard

• netcat [UNIX, NT, MSWindows (freeware-llenguatge C)]: aquesta aplicació ens permetutilitzar connexions TCP i UDP des de la línia de comandes (per exemple, transmetre unfitxer) o comprovar quins ports té oberts una determinada màquina, entre altres serveis.El seu autor és Hobbit.

• tcpdump [UNIX (freeware-llenguatge C)]: permet analitzar el trànsit de la xarxa mitjançantconnexió (LAN o punt a punt). Al contrari del que el seu nom indica, és capaç d’interpretarels paquets no solament a nivell TCP, sinó també a nivell IP, xarxa, i aplicació (per a apli-cacions comunes). És una eina imprescindible per a qualsevol administrador de sistemes,tot i que no aparegui en les distribucions de les diferents variants d’UNIX. El codi és delliure distribució. Els seus autors són Van Jacobson, Craig Leres i Steven McCanne, de laUniversitat de Califòrnia, tot i que el programa en què es basava l’original, l’Etherfind, erapropietat de Sun Microsystems i es distribuïa dins SunOS.

A continuació es comenten els diferents resultats que pot mostrar el programa tcpdump.

3) El programa tcpdump

El programa tcpdump permet capturar i filtrar paquets que travessen una interfície de xarxaque s’ha activat en mode promiscu (tots els paquets que passen pel medi són capturats i fil-trats). Els paquets són processats per un programari especial que només pot executar el super-usuari (root) de la màquina.

Per a veure com funcionen els diferents protocols, donem exemples de les traces que treu eltcpdump durant l’establiment o la terminació de la connexió.

Per a veure com funciona aquesta comanda, es pot fer servir la instrucció man d’UNIX (o LI-NUX). En aquest annex donem un exemple del significat de la traça del tcpdump.

Més informació

En els sistemes UNIX podreu trobar més informació utilit-zant la comanda man. Per exemple, per a saber més de-talls de la comanda routed’UNIX podeu executar:

$ man route

En MSWindows, podeu obte-nir més informació d’algunes comandes afegint /? com a ar-gument:

C:> route /?

Drets d’accés

Totes les comandes que es mostren dins aquest annex es-tan parcialment o totalment li-mitades a ser emprades per tots els usuaris a excepció del superusuari (root en UNIX o Administrator en MSWin-dowsNT).

MSWindows95/98 és menys escrupolós en aquest aspecte.

Nota

En LAN, el tcpdump posa la targeta de xarxa en mode promiscu. Això vol dir que tot el tràfic de la xarxa és visible, amb la qual cosa qualsevol usuari malintencionat (un hac-ker) en pot fer mal ús. Per tant, el tcpdump i altres eines simi-lars o derivades del tcpdump,conegudes com detectors (sniffers) es pot considerar comuna eina potencialment peri-llosa. De fet, el que és arriscat és no utilitzar almenys un dels tres mecanismes de protecció més importants contra els detectors: xifratge, xifratge i xifratge.


El format general de sortida del tcpdump és el següent:

El significat dels components del format són els següents:

• data: aquest component ens dóna l’hora en què es va produir l’esdeveniment en formathora:minuts:segons.microsegons (o mil·lisegons, segons la resolució del rellotge).

• src i dst: són les adreces IP i els ports TCP/UDP de les connexions de font i de destinació.

• flags: són una combinació dels possibles indicadors d’un segment/datagrama TCP/UDP:S (SYN), F (FIN), P (PUSH), R (RST) i ‘.’ (que significa que no hi ha indicadors).

• data-sqno: descriu el número de seqüència de la porció de dades.

• ack: és el número de seqüència del byte següent que espera rebre l’altre extrem TCP/UDP.

• window: és la mida de la finestra que el receptor adverteix al transmissor.

• urgent: indica que hi ha dades urgents en aquest segment/datagrama.

• options: són les opcions TCP que acostumen a estar entre claudàtors del tipus < >; perexemple, la mida màxima del segment (per exemple, <mss 1.024>).

Suposem que fem un rlogin des de la màquina argos (font) fins a la màquina helios (desti-nació). El programa tcpdump ens retornarà el següent:

La primera línia indica el següent:

a) L’esdeveniment té lloc a les 12:34:23.165439.

b) El seu origen és la màquina argos amb el port 1.024. La seva destinació és la màquina heliosamb el port login.

c) L’indicador S assenyala que és un segment de SYN (per exemple per un inici de connexió).

d) Adverteix un número de seqüència 7.838.437 i consumeix fins a aquest número. Cal ob-servar que el tcpdump escriu el número inicial i el final del número de seqüència de dades,i, entre parèntesis, la diferència indicant la longitud del camp de dades (en aquest cas 0 bytes,ja que és un segment de petició de connexió). Per tant, indica entre parèntesis la longitud delsegment de dades. Aquest número de seqüència és absolut. Les sortides següents del tcpdumpindicaran els números de seqüència relatius a l’inicial. Per exemple, en comptes d’indicar7.838.437: 7.838.450, (13) en notació absoluta, indicarà 1:13, (13) en notació relativa a l’ISN(es compleix que valor absolut és igual a l’ISN més el valor relatiu). El mateix s’aplica als nú-meros de seqüència de l’ACK.

e) Adverteix una finestra de 4.096 bytes.

f) Hi ha una petició de mida màxima de segment de 1.024 bytes.

La segona línia indica el següent:

a) L’origen és la màquina helios amb el port login. El destí és la màquina argos amb elport 1.023.

b) L’indicador S assenyala que és un segment de SYN (per exemple, per a un inici de connexió).

c) Indica el número de seqüència inicial 453.534.

d) Reconeix amb un ACK el byte següent que espera del transmissor, el 7.838.438 (és a dir,7.838.437 + 1), ja que els va rebre correctament fins al 7.838.437).

Data src> dst: flag data-sqno ack window urgent options

• 12:34:23.165439 argos.1023 > helios.login: S 7838437: 7838437 (0)win 4096 <mss 1024>

• 12:34:23.165439 helios.login > argos.1023: S 453534: 453534 (0)ack7838438 win 4096 <mss 1024>


e) Adverteix una finestra de 4.096 bytes.

f) Hi ha una petició de mida màxima de segment de 1.024 bytes.

El programa tcpdump permet escoltar, de manera senzilla, tot el que passa a la xarxa. Admettota una sèrie d’indicadors per a filtrar només les adreces IP de font o de destinació que podeninteressar, o el tipus de protocol que es vol escoltar (TCP, UDP, ARP, etc.). També admet in-dicadors per a obtenir el camp de dades, per a filtrar un nombre fix de segments, etc. Per aveure totes les possibles opcions que permet el programa tcpdump s’utilitza la comanda man.


Annex 2

Adreces especials

Les adreces especials més importants són les següents:

• Adreça 0.0.0.0: assenyala el mateix ordinador que l’envia. Té dues funcions bàsiques:

– Aparèixer com a adreça d’origen en paquets IP generats per estacions sense adreça IPassignada. Normalment només hi surt mentre l’estació tracta d’esbrinar la seva adreçamitjançant protocols com el RARP (reverse address resolution protocol), el BOOTP (bootstrapprotocol) o el DHCP (dynamic host configuration protocol).

– Servir al programari de gestió d’encaminament per a indicar la ruta per defecte.

• Totes les adreces d’aquests rangs:

– 10.0.0.0/8

– De la 172.16.0.0/16 a la 172.31.0.0/16.

– De la 192.168.0.0/24 a la 192.168.255.0/24.

Aquestes adreces, que corresponen respectivament a xarxes de classe A, B i C, no sónassignades per Internet, ni mai ho seran. S’utilitzen en xarxes que no és previst que esconnectin directament a Internet, però que, en cas que s’hi connectessin, no es vol queles seves adreces es confonguessin amb altres d’estacions que sí que són a Internet.Exemples d’això són estacions parcialment connectades a la xarxa, no mitjançant en-caminadors, sinó mitjançant proxies o firewalls.

• Adreces de classe D, des de la 224.0.0.0 fins a la 239.255.255.255: es reserven per al trànsitmulticast IP.

• Adreces de classe E: es reserven per a assignar-les a nous serveis.


Annex 3

L’algorisme checksum

Els protocols IP i TCP fan servir, entre altres, un senzill checksum per a la detecció d’errors.Aquesta és una versió de l’algorisme checksum:

u_short checksum(u_short * addr,int len){

int aux_len = len;u_short *aux_addr = addr;u_short res;int sum = 0;

while(aux_len > 1){sum+ = *aux_addr++;aux_len- = 2;}

if(aux_len == 1)sum+ = *(u_char) *aux_addr;

sum = (sum>>16) + (sum & 0xffff);sum+ = (sum>>16);res = ~sum;

return res;}


Annex 4

NAT (network address translation)

La NAT (‘traducció d’adreces de xarxa’) permet que els ordinadors d’una LAN tinguin accéstransparent a l’exterior sense haver de tenir adreces Internet vàlides externament. Això potser útil per a abaratir costos (la tarifa s'estableix per adreces) o per aprofitar millor el recursescàs “adreça”.

La NAT s’implementa en els encaminadors o en els tallafocs que donen accés a la xarxa (perexemple, els encaminadors ADSL) per ocultar a l’exterior els ordinadors de la xarxa local.

Reunir en una sola adreça més d’un ordinador pot semblar inviable perquè, tot i que els pa-quets sortints no tindrien problema (tots durien la mateixa adreça d’origen), els paquets deresposta no tindrien manera de retornar a l’ordinador correcte, ja que l’adreça no seria unadiscriminació suficient. Per a solucionar aquest problema, es discriminen els ordinadors in-terns a partir dels ports del nivell de transport (independentment que sigui TCP o UDP). L’en-caminador recorda l’adreça interna corresponent a cada port que ha emprat a la sortida.

tcp/ip: els protocols de la xarxa internet - formador · en particular, el protocol ip en la...

Documents