3.2.1. Servei no fiable - ()
3.2.2. Datagrama UDP - () - Ampliació 
()
3.2.3. Funcions i aplicacions - () - Ampliació ()
3.1. Principis de la comunicació d'extrem a extrem
3.1.1. Extrem a extrem - ()
3.1.2. Ports - ()
3.2. Protocols de datagrames d'usuari (UDP)
3.2.1. Servei no fiable - ()
3.2.2. Datagrama UDP - () - Ampliació ()
3.2.3. Funcions i aplicacions - () - Ampliació ()
3.3. Protocol de control de la transmissió (TCP)
3.3.1. Servei fiable - ()
3.3.2. Mecanismes per a la fiabilitat - ()
3.3.3. El protocol TCP - ()
3.3.4. El format del segment - ()
3.3.5. Establiment de la connexió - ()
3.3.6. Atacs clasics del TCP - (?)
3.3.7. La maquina d'estats - ()
3.3.8. Utilitats - ()
()
Al parlar de TCP/IP, fem referència a una sèrie de regles que permeten una comunicació d’extrem a extrem entre dues aplicacions que es troben en màquines diferents.
Una aplicació origen d’un host pot encapsular les dades a enviar en paquets d’un cert tamany, enviar-les a través dels diferents dispositius o routers que configuren la xarxa, indicant una direcció origen i una direcció destí per aquest paquet(extrems de la comunicació) i realitzant la posterior entrega.
De fet IP ja permetia enviar un datagrama al seu destí, però no es preocupava de quin era el receptor final de manera concreta (ja sigui un cert usuari, aplicació...). Amb els protocols d’extrem a extrem, les aplicacions es tracten de manera independent a l’hora de rebre missatges o d’enviar-los.
Per a que aquests servei d’entrega de paquets resulti suficientment fiable, ens haurem d’encarregar de programar-ho o fer us d’un protocol que incorpori aquesta funcionalitat. Com em dit al principi, TCP/IP permet la comunicació extrem a extrem i, a més, proporciona dos mecanismes o protocols: TCP i UDP. Aquests dos protocols els explicarem en aquest tema, només comentar que TCP aporta fiabilitat en l’entrega de paquets, cosa que UDP no contempla.
Fonts:
Apunts de classe http://neo.lcc.uma.es/evirtual/cdd/tutorial/transporte/Intro.html
[15/05] ()
En principi podem arribar a pensar que les aplicacions són el darrer destí dels missatges peró un PC pot executar diferents aplicacions a la vegada per tant solament la IP per l'adreçament no serà suficient.La primera impresió que podem tenir és utilitzar PIDs (identificadors de processos) peró el seu ús pot generar els següents problemes:
Pot generar problemes ja que els processos es creen i es destrueixen dinàmicament.
Per satisfer les nostres necessitats hauriem de de poder substituir els processos sense notificació a l'origen.
Una altra exigencia és que necessitem conèixer (identificar) la funció (aplicació) sense saber el procés que la realitza.
Si un programa és multifunció és imperatiu notificar a l'origen quina funció s'ha de triar.
Per evitar aquests conflictes en lloc de pensar en un programa destí
podriem pensar en que cada host te uns punts de destí abstractes que
reben els noms de Ports de protocol els quals s'identifiquen amb un nombre senser de 16 bits (4 bytes).
Per
aque els processos puguin usar aquests ports els SO ofereixien una
interficie i uns mecanismes específics. Aquestes interfícies són cues
que el SO asigna a cada port per guardar els missatges que li arriben,
on l'accès és normalment síncron, es a dir, que el procès queda
bloquejat si llegeix les dades d'una cua buida.
Assignació restringida: Aquests ports reben el nom de well-known i tenen el rang dels nombres sensers [1...1023]. Son ports comuns per a tots els hosts i reservats per a serveis específics. Per poder asignar-los s'ha de tenir privilegis.
Aplicació de clients: Són ports d'assignació lliure i dinàmica. El rang va del [1024...65535].
A nivell de capa de trasport existeix una triada important:
()
UDP (User Datagram Protocol) ofereix un mecanisme primari de comunicació per enviar i rebre datagrames a les aplicacions:
|
Aplicació |
|
UDP |
|
IP |
UDP utilitza els números de port per distingir l'aplicació a la qual van destinats els datagrames.
Ofereix el mateix servei d'entrega de datagrames no fiable i sense connexió que IP:
No hi ha ACKs per assegurar que el datagrama ha arribat.
No s'ordenen els missatges.
No es controla el flux d'informació entre els hosts.
Es a dir, els missatges es poden perdre, duplicar o arribar fora d'ordre. Llavors, per a qué serveix UDP?
UDP
es una petita ampliació d'IP que permet identificar l'aplicació de
destí, és a dir, un datagrama UDP es el mateix que un d'IP amb els
ports i poc mes.
Al no tenir ninguna mena de control d'errors, la responsabilitat de tractar-los recau sobre l'aplicació.
Normalment no es fa, degut a que si volem fiabilitat farem servir TCP. Però existeixen excepcions, com TFTP.
Les aplicacions que necessiten fiabilitat i que utilitzen UDP solen
anar bé en xarxes locals, de gran fiabilitat, però no en grans
internets. UDP es tan fiable com la xarxa que és a sota.
Cas TFTP, fiabilitat sobre UDP
Hem parlat que les aplicacions que volen fiabilitat solen recórrer a
TCP, però perqué una aplicació com TFTP (Trivial File Transfer
Protocol) s'implementa amb UDP?
Podríem caure a l'error que com que el TFTP es sol executar a una
LAN, UDP ja ofereix suficient fiabilitat. Però, no sería mes fiable
fer-ho amb TCP? I també sería mes senzill fer els programes, ja que no
hauríem d'implementar el control d'errors, ja ho faría TCP.
La raó s'explica amb el principal us de TFTP: transmetre una imatge de BOOT.
El moment d'execució de TFTP sol ser una màquina sense disc o sense
sistema operatiu, que agafa les dades del servidor TFTP. Això fa que el
client TFTP estigui quasi sempre implementat a un xip (la BIOS,
normalment), i sigui aquesta implementació la que rebi l'imatge. TCP es
un sistema molt complicat d'implementar, mentre que UDP es moltísim mes
senzill. Perque no doni problemes s'ha implementat una mínima
fiabilitat, perquè no es perdin ni es dupliquin dates, però bàsica, de
manera que sigui senzilla d'implementar a un xip.
Fonts: apunts i ampliacions de classe.
()
Els missatges UDP es diuen datagrames d'usuari (User Datagram Protocol). Tenen una capçalera de 8 bytes seguida de les dades:
|
0 .. 15 |
|
Port origen UDP |
|
Port destí UDP |
|
Longitud |
|
Checksum UDP |
|
D |
Port d'origen: Port UDP de protocol on respondre. És opcional, i si no s'hutilitza ha de ser 0. Port de destí: Port UDP de protocl utilitzat per desmultiplexar el datagrama quan arribi al destí. Longitud del missatge: Bytes del datagrama UDP, incloent tot, capçelera i dades d'usuari. El valor mínim es 8 bytes. Checksum UDP: Aquest es un camp opcional. Si no s'utilitza s'ha de posar a 0. Per calcular el ckecksum es crea una pseudo-capçalera (que no s'envia) per a verificar la integritat de les dades de la capçalera:
|
0 .. 7 |
8..15 |
|
IP origen | |
|
IP destí | |
|
zeros |
Protocol |
|
Longitud UDP | |
IP d'origen i IP de destí: Les adreçes.
Protocol: ID del protocol, en aquest cas, UDP, 17.
Longitud: Longitud del datagrama UDP original, sense comptar aquesta pseudo-capçalera.
Segons el que acabem de veure sobre el Checksum, el fet de que UDP
requereixe saber les adreçeses IP d'orígen i destinació trenca el
concepte de protocols en capes, viola la premisa bàsica de separació de
la funcionalitat en les capes de protocols. Es fa així per qüestions
pràctiques, de rendiment.
Realment UDP prepara tot el datagrama IP i el passa a IP perequé acabi d'omplir-lo.
Fonts: apunts i ampliacions de classe.
Ampliació ()
Raons per utilitzar UDP en comtes de TCP:
No hi ha establiment de la conexió: TCP utilitza el 'three-way handshake' per establir la conexió abanç de començar a transferir dades. El servei DNS, per exemple, utilitza UDP, ja que es mes ràpid. No fa falta establir una conexió perquè el tràfic de dades entre el client i el servidor serà molt petit. Amb TCP sería mes lent.
No existeix estat de la conexió: Tcp controla l'estat de la conexió, mentres que Udp no ho fa. Això permet estalviar buffers d'enviament i rebuda, paràmetres de control d'estat, etc. Per tant, una aplicació que utilitzi UDP podrà mantenir mes clients simultaneament que una amb Tcp.
La capçalera és mes petita: UDP només necessita 8 bytes en la seva capçalera, mentres que TCP en necessita 20. Per tant, és mes ràpid.
()
()
3.2.3 FUNCIONS I APLICACIONS
Les funcionament bàsic de UDP comença quan una aplicació vol enviar un missatge a una altra aplicació destí. UDP rep aquest missatge i crea el datagrama d’usuari que contindrà el missatge. Es possible que s’hagi de calcular el checksum (generalment es fa), i finalment el protocol udp passa el datagrama a IP per a que continui procesant-lo.
Per a poder enviar missatges UDP, és necessari obtenir un port per saber a quina aplicació van dirigits. L’aplicació obté un port del sistema operatiu i aquest li assigna una cua per a tots els missatges que vagin dirigits a aquest port. Si la cua està plena, el missatge es descarta. Si no existeix la cua, a més a més de descartar el missatge, es notificarà amb un missatge ICMP d’error.
Entre les múltiples aplicacions que pot tenir el protocol udp, normalment ens trobem que aquest protocol s’utilitza per comunicacions en les quals preval la velocitat en front de la fiabilitat. A més, proporciona independència entre les aplicacions. Aquí en tenim alguns exemples:
Jocs en xarxa
Streaming d’àudio i vídeo
NFS (Network File System) Munta particions en màquines remotes, permetent centralitzar fitxers i accedir a ells de manera continua.
NIS (Network Information Service) Manté comptes d’usuari mitjançant la xarxa.
VoIP (Veu sobre IP)
Fonts: apunts de classe.
Ampliació ()
Exemples de situacions on és mes apropiat un servei no orientat a connexions:
Aplicacions que no requereixin una fiabilitat total i no puguin tolerar el retard produit pels ACKs i les retransmissions TCP. Com s'ha comentat abanç, transmissió de vídeo o audio en temps real.
Aplicacions que, per la seva propia naturalesa, requereixin únicament l'enviament d'1 o 2 missatges. Exemples d'aquestes aplicacions serien: sincronització de rellotges (NTP), consultes al servidor de noms (DNS), missatges de gestió de la red (SNMP), etc. En el DNS no es considera necessari un transport fiable, ja que si es perd el datagrama l'aplicació el reenvía. Pel que fa a NTP o SNMP, la pèrdua d'un datagrama tampoc es important, ja que la informació s'està actualitzant a intervals regulars (per exemplo cada 10 minuts).
Quan es vulgui fer enviaments multidestí (multicast o broadcast). En aquest cas, només sería possible amb un protocol no orientat a connexió, ja que els protocols orientats a connexió son punt a punt (a TCP no es possible establir connexions multipunt).
()
[17/05] ()
El protocol que ens ofereix un servei de flux fiable entre les aplicacions és el TCP (Transmission Control Protocol) que està dissenyat per ser de propòsit general.
Fins al moment habiem vist un servei no fiable de lliurament de missatges, l'UDP
amb l'ús del qual els datagrames podien ser destruïts o perduts deguts
a errors de trasmisió, fallides d'algun HW... i arribar fora d'ordre,
endarrerits o duplicats. Tampoc obligaba a que l'emissor i elr eceptor
tinguessin la amteixa velocitat de porcessament de missatges provocant
a que es perdessint molts mossatges. Per tot això al protocol UDP se li
diu que es un servei de flux no fiable.
Si
volem un servei fiable en un volum d'enviament de dades elevat, a més
de controlar aquestes característiques de l'UDP, s'haurà de controlar
l'aplicació però això té inconvenients:
El mateix codi de control hauria d'estar repetit en moltes aplicacions.
S'haurien de coneixer molts detalls tècnics per poder programar les aplicacions dels hosts.
Per tant a nivell de sistema operatiu necessitem mecanismes que ens
asegurin la trasmissió de bytes, es a dir, necessitem algun mecanisme
de proposit general (no 'sha de fer res per a que funcioni) que permeti
la trasmisió fiable de dades a nivell del nostre sistema operatiu (TCP).
TCP (servei de trasmisió fiable) té 5 propietats importants. Són les següents:
Orientació a flux
Connexió
Transferència amb buffer
Flux no estructurat
Connexió bidireccional (full duplex)
Quan parlem de Orientació a flux
ens referim a que quan enviem dades entre apliacions, les dades s'han
de veure com un únic flux de bytes, es a dir, que el flux (missatge)
que parteix de l'aplicació que usem com a origen de la comunicació ha
d'arribar a l'apliació destí exactament igual. Això ha de succeir sempre.
Per a que es pugui dur a
terme la comunicació explicada en el punt anterior s'ha d'establir una
connexió, es a dir, per a que hi hagi una transferencia de les dades en
flux s'ha d'establir una connexió on els extrems de la
trasferencia/connexió hi han d'estar d'acord. Aquests extrems seran
avisats si en algun moment i per alguna causa la comunicació falla. De
supervisar aquesta comunicació s'encargarà el protocol TCP, es a dir,
el protocol TCP s'assegurarà de que tot vagi correctament.
En aquesta comunicació/connexió hi hauran tres fases bàsiques. Són les següents:
Establiment de connexió: Per establir la connexió s'utilitza un procés el qual rep el nom de negociació en 3 passes (3-way handshake). Una apliació obra un socket en un port de tipus TCP i espera escoltant pel port noves conexions. Aquesta part de la comunicació la durà a terme el Servidor. En la part de la comunicació del client envia un bit de control dins del segment TCP (SYN) el qual te la finalitat de sincronitzar la comunicació, el servidor contestaria amb una senyal de SYN-ACK i el client tornaria a contestar al servidor amb una senyal ACK.
Transferència de dades: Durant la trasferencia de les dades diferents mecanismes (utilitazació d'un nombre de seqüència per ordenar els segments TCP implicats en la comunicació i detectar duplicacions de paquets, aplicació de checksums per detectar errors y utilització de temporitzadors per detectar perdues i endarreriments) determinen la fiabilitat i la consistencia del protocol TCP.
Alliberament de la connexió: Per alliberar la connexió s'utilitza un procés el qual rep el nom de negociació en 4 passes (4-way handshake). Amb aquest procés s'acaba la connexió independement en cada extrem. Amb això el que es vol dir, quan una de les dues parts implicades en la comunicació es decideix a tallar-la, envia un paquet de FI que en l'altre extrem de la comunicació respondran amb un ACK generan així un parell de paquets FIN-ACK per a la desconexió.
Per transferir en aquest
protocol (TCP) la apliació de l'origen li passa informació al software
del protocol que és qui decidirà quan enviar-les. Per dur aterme aquest
sistema és necessari un estructura on guardar les dades abans de
enviar-les. Aquesta estructura serà un buffer. Aquests buffers han de ser blocants
pel que fa la lectura/escriptura, es a dir, si el buffer està ple la
escruptura es blocarà i si pel contrari esta buit serà la lectura del
buffer la que serà blocada.
Exsiteixen dues condicions més per al bon funcionament de la transferència. Una es l'existencia d'un mecanisme de push
el qual obliga a enviar les dades que hi hagin en el buffer. La segona
és que el protocol ha d'aturar l'emissor si el receptor no dóna l'abast
a rebre dades. Així ens assegurem que el buffer no es desbordi.
En aquesta propietat ens ve a dir que l'estructura de les dades es poc important ja que el servei solament veu bytes. L'estructura l'ha de modelitzar les ampliacions (origen i destí) que les hagin d'utilitzar previ acord de la estructura. Tot aquest procés s'ha de realitzar abans de la comunicació.
El servei del flux ens ha
de permetre trasmetre bidireccionalment, es a dir, en els dos sentits
de la comunicació i fer transferencies simultanies.
Pel
que fa el paper de l'apliació en aquest tipus de connexió les
apliacions veuen dos fluxes diferents de daes, es a dir, dos fluxes
independents els quals tene direccions contraries (una per a portar el
control de la comunicació i una altra per dur les dades de l'origen al
destí i viceversa).
NOTA: Esmentar
que aquesta part es molt més ampliable però trepitjaria molta feina
dels meus companys, ja que aquest punt de teoria te un caire
notablement introductori als punts següents.
Fonts:
http://www.wikipedia.org
http://www.babel7.com (aquesta web ho explica però de forma més col.loquial)
Trasparencies de classe
índex
()
Mecanismes per a la fiabilitat
El protocolo IP no ofrece
fiabilidad. En cambio TCP tiene técnicas para garantizar la entrega
completa y ordenada de datagramas. Se usa la técnica de la ventana
deslizante o la confirmación positiva con retransmisión.
Confirmación positiva con retransmisión
Este mecanismo funciona
así: El emisor envía los datagramas y inicializa un timer. El
destinatario envía un ACK cuando llega un datagrama para que el emisor
sepa que ha recibido el datagrama correctamente. El emisor no envía más
datagramas hasta que reciba el mensaje ACK. Si no lo recibe antes de la
finalización del timer, vuelve a enviar los datos inicializando el
timer de nuevo. Los datagramas mensajes de ACK tienen número. De esta
manera se evita que haya datos duplicados.
Un inconveniente es que el
emisor no puede enviar más datos mientras espera el ACK. De esto
resulta una perdida de tiempo bastante grande.
Ventana deslizante
Funcionamiento en general:
Este mecanismo tiene un mejor rendimiento del ancho de banda que el mecanismo anterior. También usa ACKs, pero el emisor puede enviar más que un datagrama sin esperar el ACK. Los datagramas se guardan en un buffer.
La ventana deslizante
defina un numero máximo de datagramas que se pueden enviar sin recibir
el ACK. El dibujo muestra 12 datagramas siguientes:
La ventana se mueve hacia la derecha, cuando recibe el ACK del primer elemento (en el dibujo es el datagrama 4). Un ACK con el número n significa que se han recibido todos los datagramas hasta el datagrama n. Así se asegura que todos los datagramas, por cuales la ventana ha pasado, se han recibido correctamente. El emisor y el receptor ambos usan la ventana deslizante. El emisor para saber si hace falta retransmitir un datagrama y el receptor para saber cuales ya han llegado. Si el tamaño de la ventana es 1, es igual al mecanismo anterior. Si el tamaño es infinito, es igual a transmisión sin confirmación
porque nunca no se reenvía un datagrama. Aumentando el tamaño se puede
mejorar la velocidad así que no hay tiempo de espera. Pero si la
ventana es demasiado grande, ya no hay mejoras de la velocidad, se
gasta más memoria y el número de datagramas, que llegan fuera del
orden, crece.
Adaptación TCP:
Debido a las características de TCP el algoritmo es diferente. Usa el sistema de confirmaciones acumulativas: Los ACKs de TCP no se refieren a datagramas sino a bytes del flujo de datos. El ACK del receptor contiene información sobre el prefijo más grande que ha recibido sin errores indicando el byte que quiere recibir del flujo. Una desventaja de este mecanismo es que el receptor no sabe que partes recibe el receptor. Por otra parte es fácil crear los ACKs y no hay ambigüedades.
Como se vé en el dibujo se usan tres punteros. Un puntero para indicar el inicio de la ventana [LastByteAcked/LastByteRead], un puntero para indicar el ultimo byte escrito/recibido [LastByteWritten/LastByteRcvd] y un puntero para indicar el final de los bytes enviados [LastByteSent] o bien el proximo byte que quiere recibir el receptor [NextByteExpected].
Fuentes:
http://www.gestiopolis.com/recursos6/Docs/Ger/sistema-de-informacion-tcp.pdf
http://en.wikipedia.org/wiki/Sliding_window
http://www.freesoft.org/CIE/Course/Section4/5.htm
http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html#SW
transparencias de la asignatura
()
3.3.3. El protocol TCP
TCP és un dels principals protocols de les xarxes tcp/ip que, com a principal característica, proporciona un servei fiable de flux de dades entre processos (garanteix que les dades es transmeten i arriben de forma correcta a la seva destinació).
TCP especifica en quin format s’han d’enviar les dades (i les confirmacions) i s’ajuda d’una sèrie de procediments per portar a terme la seva funció. Per exemple, per saber l’ordre dels paquets enviats, utilitza numeros de seqüencia que identifiquen el paquet de manera única i ens dona informació de l’ordre d’arribada de les dades. També s’encarrega de eliminar paquets duplicats i reenviar paquets que s’han perdut.
El protocol TCP és un protocol orientat a conexió, es a dir, s’encarrega de les transferencies de dades entre els extrems de la connexió (endpoints) fins a les aplicacions d’usuari finals. TCP també utilitza ports per poder diferenciar a quina d’aquestes aplicacions van destinades les dades enviades. Si tenim una parella (ip, port) podem conèixer de manera concreta quina és l’aplicació destinàtaria. Si afegim que TCP permet l’utilització d’un mateix port per a més d’una connexió simultànea, és pot afirmar que TCP és un protocol de transmissió de dades que permet connexions concurrents snse haver d’adjudicar un port local únic.
Al ser un protocol orintat a connexió, per poder realitzar una comunicació entre dos endpoints, aquests extrems s’han de posar d’acord entre ells. Si un extrem espera rebre una petició de connexió, comunicarà a TCP i al seu S.O. que espera l’arribada d’aquesta petició des d’algun sistema remot. Llavors, l’S.O li assignarà un port per a poder comunicar-se amb l’altre extrem. Aquest tipus d’apertura de connexió s’anomena apertura pasiva. Si l’apertura és activa, s’envia la petició de connexió a un port que té establerta una apertura passiva.
Per aprofitar l’amplada de banda de la connexió, TCP s’ajuda de dues finestres per cada un dels endpoints, una per l’enviament de paquets i una per la recepció, possibilitant la comunicació simultànea en els dos sentits (full-duplex). Aquest fet permet l’enviament de tantes dades com el tamany de la finestra, evitant haver d’esperar la confirmació de cada un dels paquets per poder enviar el següent.
Si tenim aquesta finestra, podem enviar tots els paquets de dins de la finestra.
Al rebre l’ACK del paquet 1, podem desplaçar la finestra.
El funcionament del protocol TCP es pot dividir en tres etapes:
1. Establiment o apertura de la connexió.
2. Transmissió fiable de dades utilitzant procediments de confirmació i control de flux.
3. Alliberament de la connexió
Fonts:
http://ditec.um.es/laso/docs/tut-tcpip/3376c212.html
Apunts de classe
[18/05] ()
3.3.4. EL FORMAT DEL SEGMENT TCP
El segment TCP és la
unitat bàsica d'informació del protocol, als segments s'envia la
informació que s'intercanvien el receptor i l'emissor.
Els segments TCP s'utilitzen per:
Establir connexions.
Transferir dades.
Enviar confirmacions.
Anunciar mides de finestres
TCP utilitza el piggybacking (ó superposició) amb cada segment que s'envia es pot incluir la confirmació (ACK) de l'últim missatge rebut, llavors les confirmacions en un sentit poden anar en un segment de dades del sentit invers.
El segment TCP té una capçalera i una part de dades, el format del segment és el que indica la figura següent:
Tots els camps excepte el de dades (Data) formen part de la capçalera, al camp de dades es on es guarden les dades del missatge, la resta de camps són camps de control, aquests camps són:
Source Port (Port d'origen) - 16 bits: Conté el port que identifica la aplicació de l'extrem origen.
Destinatio Port (Port d'origen) - 16 bits: Conté el port que identifica la aplicació de l'extrem destí.
Sequence number (Número de seqüència) - 32 bits: Identifica el primer byte del camp de dades, es a dir, és la posició on comença el flux de dades del segment de l'emissor (a TCP no s'enumeren segments, sinò bytes), al principi de la connexió s'assigna un número de seqüencia inicial (Initial Sequence Number, ISN) i a partir d'aquest número TCP numera els bytes següents consecutivament.
Acknowledgment number (Número de confirmació) - 32 bits: És el número del byte que s'espera rebre després (el següent segment que ha d'enviar l'altre extrem). Aquest número s'envia per piggybacking amb les dades, quan al segment s'activa el bit d'ACK a la capçalera llavors l'altre extrem te en compte el número de seqüència ACK, que lìndicarà el següent byte que està disposat a rebre, si restem 1 al número d'ACK tindrem el número de seqüència de l'últim byte rebut.
Header length (Longitud de la Capçalera) - 4 bits: Indica la longitud de la capçalera, aquest número ha de ser un múltiple de 32 bytes, la longitud depén del camp d'opcions, si el segment no té cap opció (segment típic) la capálera es de 20bytes, i pot arribar a mesurar 60 bytes. Serveix per saber on comencen les dades.
Reserved (Reservat) - 6 bits: Aquest camp està reservat per usos futurs, i s'inicialitza a ceros.
Code Bits (Codi) - 6 bits: És un codi per determinar el contingut i el propòsit del segment, hi ha 6 indicadors independents (i pot contenir més d'un):
URG: Indica que les dades son urgents, i ens diu el camp amb l’apuntador d’urgent és vàlid.
ACK: Serveix per avisar de que el camp de confirmació (Acknowledgment number) és vàlid.
PSH: Invoca la funció PUSH del protocol pel segment, es a dir, avisa al receptor que ha d'entregar a l'aplicació totes les dades que estàn a la memòria intermitja de recepció sense esperar a completarlos amb dades adicionals.
RST: Fa un reset a la connexió, es a dir, talla la connexió (per exemple, per un problema a la seqüencia de bytes).
SYN: S'utilitza per inciar una connexió y per sincronitzar els números de seqüència (perquè els dos extrems sapiguen amb quin número de seqüència comencen).
FIN: S'utilitza per avisar a l'altre extrem de que l'emissor ha arribat al final del flux de dades i que, per tant, vol acabar la connexió.
Window (Finestra) - 16 bits: Indica la mida de la finestra en bytes, s'utilitza en el fluxe de ventana lliscant. Aquest camp sempre està actiu, inclús quan el segment no porta dades. Aquest número pot anar canviant segons el segment (a diferència dels protocols a nivell d'enllaç).
Checksum - 16 bits: Aquest camp s'utilitza per trobar errors, per calcular-lo s'utilitza el mateix procediment que al protocol UDP.
Urgent (Apuntador Urgent) - 16 bits: Indica que les dades que envia l'origen son urgents, el camp conté l'últim byte de les dades urgents, per exemple si el número de seqüència és 1000 i l'urgent pointer indica 200, significa que els bytes del 1000 al 1200 són urgents. Aquest camp només te sentit si el bit de control URG està actiu. Un exemple d'utilització podría ser en la transmissió d'un fitxer gran (per exemple una pel·licula), si volem aturar la connexió volem que s'aturi just en el moment, no després. Les aplicacions telnet, rlogin o ftp utilitzen aquest camp.
Options - 32 bits: Aquest camp permet afegir camps a la capçalera TCP, es poden afegir les següents opcions:
Timestamp: S'utilitza per marcar el temps en el que s'ha retransmet el segment, s'usa per poder monitoritzar els retards que tenen els segments desde l'origen al destí.
Es pot utilitzar per augmentar el tamany de la finestra.
Indica el tamany màxim del segment o MSS (Maximum Segment Size) que el receptor està preparat per rebre. És l'opció més utilitzada.
MSS:
Els segments poden tenir
mides diferents, però els extrems han d'acordar una mida màxima (MSS).
Aquesta mida es molt important per aconseguir una bona utilització de
la xarxa.
Escollir un MSS no es
trivial, si és molt petit hi ha infrautilització de la xarxa, per tant,
quant més gran sigui el MSS millor perque les capçaleres IP i TCP
s'amortitzen més, però si es massa gran (i la MTU petita) caldrà
fragmentar el datagrama IP, i això pot portar problemes, perquè si un
datagrama es perd el segment no es pot recuperar, així que no interessa
escollir MSS més grans que la MTU, en general, voldrem un MSS igual al
MTU, si els extrems no estàn a la mateixa xarxa hem de trobar el MTU
mínim (usant, per exemple, el MTU discovery path, que es un mecanisme
de búsqueda per averiguar quina és la MTU més petita desde l'origen
fins el destí, i utilitzar com MSS aquest valor menys els 40 bytes de
les capçaleres IP i TCP). Si no podem trobar el MTU mínim es pot agafar
536 (576 menys les capçaleres), que és el valor estàndard.
Trobar el MSS òptim és
difícil perquè la majoria d'implementacions TCP no tenen mecanismes per
descobrir les MTU, i perquè les rutes entre els hots poden canviar
dinàmicament, també depén de les capçaleres dels protocols de baix
nivell.
A la pràctica l'emissor i el receptor es solen avisar dels respectius MTU i s'agafa el més petit.
FONTS:
Transparències assignatura.
http://www.uoc.edu/masters/cat/img/922.pdf
http://web.tiscali.it/vadamohome/networks/parte2/liv4.htm
()
3.3.5 ESTABLIMENT DE LA CONNEXIÓ
L'establiment d'una connexió a TCP es basa en el three way handshake, aquest mètode diu que es necessiten 3 missatges per a que els dos extrems de la connexió es sincronitzin per l'enviament de dades.
Pel que fa a quin dels exterms s'encarrega d'iniciar la connexió, normalment un dels extrems es passiu i l'altre és el que inicia la connexió amb l'enviament del primer missatge. No obstant, això no vol dir que el que inicia la connexió sigui el master i l'extrem passiu sigui slave sino que una vegada s'ha establert la connexió els dos extrems tenen les mateixes prioritats, no hi ha master ni slave ja que tots dos poden enviar i rebre dades com explicarem a continuació.
A TCP s'estableix una connexió full duplex, es a dir, els dos extrems poden fer d'emisor i de receptor a l'hora ja que es crea un canal per a cada flux de dades. En el primer canal, la màquina 1 emet les dades i la màquina 2 fa de receptor, el segon canal s'usa per a l'enviament de les dades per part de la màquina 2 cap a la màquina 1.
Als missatges per l'establiment de la connexió intervenen els bits de SYN i ACK i els camps de seq i ack on s'indicaran els números de sequència dels dos fluxos de dades. Més concretament, l'establiment de la connexió es realitza de la següent manera:
Al primer missatge amb el bit SYN actiu i ACK=0, el camp de sequència seq=x on x és un número aleatori entre 0 i 2^32-1, aquest será el número de sequència de la comunicació que anirà de la màquina 1 (és qui estableix la connexió) a la màquina 2 (màquina receptora de les dades).
Al segon missatge els bits SYN i ACK estan activats, el camps ack = x+1, que serveix per a que la màquina 2 confirmi el número de sequència propossat per la màquina 1. A aquest missatge la màquina 2 tria a l'atzar el seu número de seqüencia per l'enviament de dades amb seq=y.
Al tercer missatge el bit SYN=0 i ACK està activat, en aquest missatge la màquina 1 el número de seqüència que proposa la màquina 1 per establir el flux de dades en el que la màquina 1 rebrà les dades enviades per la màquina 2, ack=y+1, seq=x+1.
Figura: Establiment de la connexió.
El quart missatge seria l'enviament de les dades. Una vegada establerta la connexió els números de seqüència s'utilitzen per identificar les dades que s'envien i per la seva confirmació. Cal destacar que durant tota la connexió els segments (missatges) que s'intercanvien els extrems per l'enviament de les dades, són els mateixos que s'usen per l'establiment de la connexió, el que ens permet enviar dades durant l'establiment de la connexió.
Podem afirmar que TCP és un protocol de transferència fiable si els números de sequència estan ben definits ja que no hi ha possibilitat d'incoherència entre emisor i receptor.
Three way handshake ens garanteix completament que els dos extrems estan preparats per enviar i rebre dades i el que és molt important també, els extrems saben que l'altre exterm està també preparat.
Análisi del protocol de desconnexió
Durant l'establiment de la connexió podem tenir diversos problemes relacionats amb la pèrdua i duplicació dels missatges.
Si es perd el primer o segon segment no hi ha cap problema ja que quan s'exaureix el temps de timeout es tornen a reenviar.
Es pot donar el cas que el primer missatge es rebi bé però la confirmació es perdi, aleshores al cap d'un temps el primer es torna a enviar i el tindrem duplicat, en aquest cas es descarta i es torna a enviar la confirmació perduda.
Si es perdés el tercer segment, es a dir, el ack que envia la màquina 1, ens trobaríem en el mateix cas que abans, el SYN es reenviaria. Com està duplicat la màquina 1 el descartaria i tornaria a enviar el ack perdut.
()
()
TANCAMENT DE LA CONNEXIÓ
Habitualment es segueix un protocol gracefully per tancar una connexió, es a dir, normalment es fa de forma ordenada. No obstant existeix un cas especial de desconnexió mitjatzant reset (desconnexió abrupta).
Protocol de desconnexió ordenada
Una vegada s'han enviat les dades entre els extrems s'ha de tancar la connexió. Com hem vist anteriorment, una connexió TCP té dos fluxs simulatnis per tant la desconnexió s'haurà de fer per a cada flux. En el cas de la desconnexió ordenada els bits FIN i ACK seràn els que intervindran.
Quan en un sentit s'acaba el flux de dades, esperem a rebre l'últim ack i aleshores enviem un segment amb el bit FIN=1, una vegada a arrivat aquest a l'extrem, aquest no acceptarà cap més segment de dades que arrivin en aquest sentit. L'extrem receptor del FIN, confirma que l'ha rebut amb un segment ACK=1. A continuació continua enviant les dades que li queden pendents (l'extrem que ha enviat el FIN pot continuar rebent les dades ja que aquest flux l'ha de tancar l'altre), quan les ha enviat, al igual que en l'altre cas, espera a rebre els ack's pendents i a continuació envia un FIN, l'altre el confirma i la connexió queda tancada en ambdos sentits.
Analitzant el protocol de desconnexió, entre el primer i el segon FIN hi ha com a mínim un segment, en el cas que l'altre extrem no tinguès dades pendents d'enviar i el segon no tingués ack's pendents de rebre. Aquest segment tindria el camp ACK=1 per confirmar la rebuda del primer FIN.
Anàlisi del protocol de desconnexió
Si es perd un segment de FIN, després d'un temps prudencial (timeout) es torna a reenviar, d'igual forma que si es perd el primer ACK.
Es pot donar el cas que el FIN es rebi bé però que pasat el timeout no hagi arrivat l'ACK a l'emisor, aleshores el FIN es reenviarà i arriva duplicat al destí, en aquest cas es descarta i es torna a enviar l'ACK.
Si es perd el darrer ACK, que és l'ultim segment de la comunicació, el FIN no es torna a enviar ja que seria una mica perillós. Si es produeix aquest cas simplement es dóna per bo i es tanca la connexió.
Desconnexió abrupta
Com a norma general aquest mètode no s'usa, s'utilitza el protocol de desconnexió ordenada. No obstant hi ha casos excepcionals en els que és necessari una desconnexió immediata, en aquest cas enviarem un segment amb el bit RST=1 (reset activat).
Quan l'extrem rep aquest segment talla la connexió sense esperar la confirmació de les dades ni tampoc es preocupa si té dades pendents per enviar, sino que talla la connexió automàticament. En aquest moment s'alliberen els recursos ocupats i es tallen els dos fluxs de comunicació.
En aquest cas TCP informa a l'aplicació que hi ha hagut un reset ja que es tracta d'un fet excepcional.
()
[19/05] ()
SYN flooding:
És un atac de tipus DoS (Denial of Service - Denegació de Servei), el que fan es colapsar la màquina per què no pugui rebre ni enviar res.
S’envien moltes peticions
d’establiment de connexió (segments SYN) al mateix computador. El
receptor té un espai limitat per a mantenir peticions simultànies. Quan
aquest espai s’acaba no s’accepten més.
Una
possible solució és augmentar el número de peticions simultànies que es
poden mantenir, o detectar si un mateix odinador està enviant SYN's
molt sovint.
RST flooding:
També es un atac de tipus DoS i d'acabament de connexions actives.
S’envien segments amb el bit RST activat, llavors les connexions establertes al ordinador víctima acaben. Si l’atac és continuat no es poden establir de noves perquè hi ha un flooding de la màquina i aconsegueix un DoS.
Segrest de sessions:
Consisteix en aconseguir segrestar una sessió (o una finestra X). S'analitza el tràfic TCP que hi ha entre dues màquines per veure els números de seqüènica que s'estan utuilitzant, llavors es substitueixen els missatges de veritat per uns nous amb el mateix número de seqüència amb les dades que es vulguin. S’utilitza normalment per executar comandes arbitraries en sessions ja autentificades.
Per poder fer-ho el programa que fa l'atac ha de poder averiguar el núm de seqüència correcte, per evitar això quan s'inicia una connexió, es generen números de seqüència pseudo-aletòris amb algorismes lo més complexes possibles.
Smurf:
Es de tipus DoS. El programa que ataca envia un ping amb la IP de la victima como source i amb la direcció de broadcast com direcció destí, llavors, com a resposta, tothom farà un ping a la víctima saturant-la de connexions.
Una xarxa pot ser víctima d'un smurf si fa forwards de boradcast.
Fraggle:
Es semblant al Smurf però fa servir UDP i utilitza el servei d'ECHO per saturar a la víctima.
Snork:
El Snork itilitza el servei d'ECHO i la funció chargen que genera caràcters aleatòris per colapsar la víctima.
Ping Of Death:
Fa un ECHO request i se li posen uns bytes de més al segment, quan es construeix el datagrama IP el segment no cap al datagrama i hi ha una part que es perd, però a la capçalera del datagrama continua posant el tamany (núm. de bytes) de tot el ECHO request sencer. Llavors, quan arriba el datagrama s'agafen bytes de més que no te el datagrama (fent cas a la capçalera), els bytes que agafa son els bytes qualsevol que hi hagi a memòria fent que succeeixin coses rares al SO totalment aleatòries intentant interpretar el missatge, quan això pasa uns quants cops el SO acaba petant.
Fonts:
Transparències i apunts de la assignatura.
índex
()
El protocol TCP es representable mitjançant un automata d’11 estats:
Tancat: No s’ha realitzat cap operació d’obertura de connexió.
Temps-espera: Estat que espera un cert temps per a que l’equip remot rebi l’ACK de la petició de tancament de la connexió.
Tancant: espera un ack corresponent al ultim FI de la connexió
Fi-espera-2: Es queda en aquest estat si quan un costat de la connexió envia l’ACK corresponent a un FI i es retrasa en l’enviament del seu FI
Fi-espera-1: Entrem quan s’inicia l’operació de tancament de connexió.
Espera-tancament: Espera motivada per una petició de tancament.
Ultim-Ack: Espera l’ack d’una petició de tancament de connexió.
Establerta: És l’estat més normal de les parts de la connexió. La connexió es troba oberta.
Syn-enviat: Espera resposta davant una petició de connexió.
Syn-rebut: Espera la confirmació de la resposta a la petició.
Escoltant: Espera la petició d’obertura pasiva.
Fonts:
Apunts de classe
http://www.it.uniovi.es/material/informatica/uvieu/sistemas/redesComputadores/rso13-tcp.pdf
()
netstat:
L’aplicació netstat ens permet veure les connexions actuals en la propia màquina, indicant l’estat en que es troben i els bytes en cua:
# netstat -tan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:22 127.0.0.1:3276 ESTAB.
tcp 0 0 127.0.0.1:3276 127.0.0.1:22 ESTAB.
El paràmetre t serveix per sel·leccionar les connexions TCP.
El paràmetre u serveix per sel·leccionar les connexions UDP.
El paràmetre a serveix per sel·leccionar tots els estats de les connexions, "LISTEN", "ESTABLISHED", "IDLE"...
El paràmetre n serveix perquè no intenti mostrar els noms de les màquines, sinò les IPs.
TCP fingerprint:
El estàndard TCP deixa oberts molts casos (no especifica que s’ha de fer). Examinant la resposta d’un host a aquests casos podem esbrinar quin és el seu sistema operatiu. # TEST DESCRIPTION: # Tseq is the TCP sequenceability test # T1 is a SYN packet with a bunch of TCP options to open port # T2 is a NULL packet w/options to open port # T3 is a SYN|FIN|URG|PSH packet w/options to open port # T4 is an ACK to open port w/options # T5 is a SYN to closed port w/options # T6 is an ACK to closed port w/options # T7 is a FIN|PSH|URG to a closed port w/options # PU is a UDP packet to a closed port
En un principi es feia amb un programa anomenat queso, desenvolupat a Espanya. El projecte es va abandonar però nmap l'ha incorporat.
El programa nmap, a part de fer moltes altres coses, ens ofereix la signatura d’un host i ens diu a quin SO pot pertanyer.
Fonts: