Tema 8. Funcionamiento A Nivel de Transporte

Conceptos bsicos para la administracin de redes Administracin de Redes Escuela Profesional de Ciencias de la Computacin Universidad Nacional de Ingeniera
TEMA 8. FUNCIONAMIENTO A NIVEL DE TRANSPORTE

8.1. Antes De Comenzar
En esta unidad didctica, tocaremos el tema del nivel de transporte en Internet! del nivel de transporte
"eremos el funcionamiento del nivel de transporte de los componentes protocolos #ue intervienen en $l! %ablaremos sobre como se reali&a en encaminamiento a nivel de transporte, as como la manera en #ue se produce la activacin de la cone'in! (ambi$n trataremos temas tan importantes, como la liberacin de la cone'in o el control del flu)o de las t$cnicas conocidas con el nombre de buffering el Multiplexing! En cuanto al nivel de transporte en Internet, vamos a conocer como se reali&a el proceso del encaminamiento, pero tambi$n de protocolos tan importantes como TCP o UDP* as como los procesos de la activacin de la cone'in, liberacin de la cone'in o la poltica de trasmisin el control de la gestin!
8.2. El N !el De Trans"orte

El nivel de transporte, es el cora&n de toda la )erar#ua de protocolos! +u tarea es la de proveer un transporte confiable efica& del ,ost de origen a a#uel de destino, independientemente de la red utili&ada! -ste es el nivel en el #ue se gestiona por primera ve&, de aba)o ,acia arriba, una conversacin directa* es decir sin intermediarios, entre origen destino! .e esto se deriva #ue el soft/are del nivel de transporte, slo est presente sobre los ,osts, no en los enrutadores de la subred de comunicacin! 0os ser! # os "r n# "ales o$re# %os "or el n !el %e trans"orte a los niveles superiores, son varios tipos de transporte de la informacin entre una transport entity 1entidad de transporte2 sobre un host su peer entity 1entidad par2 sobre otro ,ost! Naturalmente, tales servicios son reali&ados por el nivel de transporte a trav$s de los servicios, para ello ofrecidos por el nivel de red!
Prof. Manuel Castillo Cara
As como ,a dos tipos de servicios de nivel de red, tambi$n ,a dos servicios a nivel transporte3 Ser! # os $ a&les or enta%os a la #one' (n, tpicos de este nivel! Ser! # os %ata)ram, poco usados en este nivel! Estos son mu similares, como caractersticas, a a#uellos correspondientes del nivel de red, tienen las mismas venta)as desventa)as! 4Pero entonces, por #u$ duplicar las cosas en dos niveles diversos5 El ,ec,o es #ue el usuario, #ue accede a los servicios de red desde lo alto, no tiene ning6n control sobre la subred de comunicacin, #uiere en todo caso ciertas garantas de servicio, por e)emplo, el traslado correcto de un e'pediente, es decir, de los datos #ue lo componen! Por lo tanto, tales garantas tienen #ue ser provistas fuera de la subred, por lo #ue tienen #ue residir en un nivel superior a a#uel del nivel de red! En sustancia, el nivel de transporte permite ofrecer un servicio ms fiable de lo #ue la subred es capa& de proporcionar! Adems, tiene otro ob)etivo importante, a#uel de aislar los niveles superiores de los detalles implementados de la subred de comunicacin! +e consigue esto, ofreciendo un con)unto de primitivas 1#ue definicin los servicios2, simples de utili&ar e independientes de los servicios de los niveles de aba)o! Esto por#ue mientras slo pocas personas programan componentes soft/are #ue usan los servicios de nivel de red, muc,as desarrollan aplicaciones de red, #ue se basan sobre los servicios de nivel de transporte! Un 6ltimo aspecto concierne a la posibilidad de especificar el *oS 1Quality of Service 7 Calidad de Servicio2 deseado! Esto en particular se adapta sobre todo a los servicios connection oriented 1orientados a la cone'in2, en los #ue el solicitante puede especificar e'igencias como el m'imo retraso para la activacin de la cone'in* t,roug,put re#uerido* m'imo retraso de trnsito admitido* tasa de error tolerado* tipo de proteccin de accesos no autori&ados a los datos en trnsito! En este escenario, las peer entity 1entidades pares2, encaminan una fase de negociacin para ponerse de acuerdo sobre el 8o+, tambi$n en funcin de la calidad de los servicios del nivel de red de #ue disponen* cuando el acuerdo es alcan&ado, es vlido durante toda la cone'in! Por otro lado, las "r m t !as %e %e$ n # (n %el ser! # o, se encargan de definir el modo de acceder a los servicios del nivel! (picamente son pro ectadas de modo #ue esconden los detalles de la subred, es ms, de modo #ue son independientes de cual#uier subred, son fciles de usar! Por e)emplo, $ste puede ser un con)unto tpico de funciones primitivas3
Por e)emplo, consideramos los siguientes fragmentos de cdigo de una aplicacin cliente9servidor3
Estos dos fragmentos son capaces de llevar adelante un dilogo sin errores, si el servicio utili&ado es fiable, #ue es lo normal, ignorando completamente todo cuanto concierne a la mecnica de la comunicacin!
8.+. Proto#olos De N !el Trans"ort

0os protocolos de nivel de transporte, sobre la base de los cuales se implementan los servicios, se parecen en algunos aspectos a los de nivel enlace de datos! En efecto se ocupan, entre otras cosas, tambi$n del control de los errores, control del flu)o reorgani&ar los TPDU o UDTP 1Transport Protocol Data Unit o Unidades de Datos del Protocolo de Transporte2! Pero ,a tambi$n importantes diferencias, la principal es #ue en el nivel de enlace de datos, entre los peer entity 1entidades pares2 ,a un canal individual de comunicacin* en el nivel de transporte est por medio la subred de comunicacin! Esto implica #ue, a nivel de transporte, es necesario direccionar e'plcitamente al destinatario #ue es ms complicado establecer la cone'in! 0a red tiene una capacidad de memori&acin, por lo #ue los TPDU pueden saltar fuera cuando el destino menos se lo espera! El buffering control de flu)o, re#uieren un aproc,e diferente #ue en el nivel de enlace de datos, a causa del n6mero mu variable de cone'iones #ue se pueden tener de momento en momento!
8.,. En#am nam ento

Cuando se #uiere activar una cone'in, se tiene obviamente #ue precisar con #uien se desea conectar! Por lo tanto, se tiene #ue decidir como est ,ec,a la direccin de nivel de transporte, denominado TSAP a%%ress 1Transport Service Access Point address Servicio de Transporte de Direcci n de Acceso a un Punto 2! (picamente un TSAP address, tiene la forma 1NSAP a%%ress, informacin suplementaria2! Por e)emplo, en Internet un TSAP address, o sea una direccin TCP o UDP, tiene la forma 1IP a%%ress3 port nu!ber Direcci n "P# $%!ero del puerto2, dnde "P address es el $SAP address el port nu!ber, es la informacin suplementaria! Este mecanismo de formacin de las direcciones de los TSAP, tiene la venta)a de determinar implcitamente la direccin del nivel de red de usarla para establecer la cone'in! En ausencia de tal mecanismo, resulta necesario #ue la ar#uitectura prevea un servicio para efectuar el !apping 1mapeado2 entre las direcciones de nivel de transporte las correspondientes direcciones del nivel de red!
8.-. A#t !a# (n De La Cone' (n

Esta operacin parece fcil pero no lo es, por#ue la subred puede perder o duplicar, a causa de retrasos internos, los pa#uetes! Por e)emplo, a causa de repetidos retrasos en el envo de los AC. 1confirmacin2 puede suceder #ue sean duplicados sucesivamente lleguen en perfecto orden a destino todos los pa#uetes anteriormente generados en el curso de una cone'in! Por cierto, los AC. 1confirmaciones2 son pe#ue:os mensa)es de aviso de peticin de envo de ms pa#uetes, indicando tambi$n el orden del 6ltimo #ue ,a recibido, #ue son emitidos por el receptor ,acia el emisor de los datos!
Imaginemos las consecuencias de tal inconveniente si el ob)etivo de tal cone'in ,ubiera sido la solicitud a un banco, de transferir mil millones de euros, sobre la cuenta de un persona)e de dudosa ,onestidad! El problema de fondo reside en la posible e'istencia de duplicados retrasados #ue llegan a destino muc,o despu$s de ,aber partido! ;a sabemos #ue, una ve& #ue la cone'in est establecida, cual#uier protocolo es apto para el ob)etivo! En efecto, durante el establecimiento 1 setup2 de la cone'in las entidades pares #ue se van a conectar 1peer entity2, se ponen de acuerdo sobre el n6mero inicial de secuencia, por lo tanto los duplicados retrasados no son aceptados! 0o mismo ocurre para solucionar el problema de los duplicados, relativos a la fase de activacin de la cone'in! E'iste una solucin para esto 6ltimo, desarrollada por (omlinson en <=>? denominada three9&ay handsha'ing! El protocolo funciona as, el solicitante manda un TPDU de tipo conn(re)uest con un n6mero ' propuesto como principio de la secuencia! A su ve& el destinatario manda un TP.U de tipo AC. 1confirmacin2 conteniendo la confirmacin de x, las propuesta de un propio n6mero de inicio secuencia! El solicitante manda un TPDU de tipo datos, conteniendo los primeros datos del dilogo la confirmacin de ! 0os valores x e y pueden ser generados, por e)emplo, e'plotando el relo) de sistema, para obtener valores diversos cada ve&! En ausencia de errores, el funcionamiento es el siguiente3
+i llega a destino un duplicado de la peticin de activacin, el destinatario contesta como antes, pero el remitente, #ue sabe #ue no ,a solicitado una segunda cone'in, le informa del error3
+i por fin llegan al destinatario, sea un duplicado de la peticin de activacin #ue un duplicado del primer TPDU de datos, la situacin es la siguiente3
En efecto en este caso el remitente enva un rec,a&o a la respuesta del destinatario, por#ue sabe #ue no ,a solicitado una segunda cone'in, como en el caso anterior* el destinatario descarta el TPDU de datos, por#ue esto produce un AC* 1confirmacin2 relativo a un n6mero de secuencia, +, precedente no a#uel 1y2 #ue $l buscaba enviar!
8./. L &era# (n De Una Cone' (n

Asignar una cone'in es ms simple #ue establecerla, pero en todo caso alg6n pe#ue:o problema tambi$n ,a en esta fase! En este conte'to, conceder la cone'in, significa #ue la entidad de transporte remueve las informaciones sobre la cone'in de las propias tablas e informa al usuario de nivel superior #ue la cone'in est cerrada! %a dos tipos de cone'iones3
As m0tr #a!9 Este caso est e)emplificado por el sistema telefnico, cuando una de
los dos partes @se mete aba)oA, se cierra enseguida la cone'in! Esto puede llevar a la p$rdida de datos, en particular de todos a#uellos #ue la otra parte ,a enviado no ,an llegado todava!
S m0tr #a!9 En este segundo caso se considera la cone'in como una pare)a de
cone'iones unidireccionales, #ue deben ser concedidas independientemente! Por tanto, a lo largo de una direccin pueden todava fluir datos, aun#ue la cone'in a lo largo de la otra direccin ,a a sido cerrada! 0a liberacin sim$trica es 6til cuando un proceso sabe e'actamente cuntos datos tiene #ue enviar, por lo tanto puede decidir autnomamente cuando conceder su cone'in en salida! +i en cambio las dos entidades #uieren estar de acuerdo antes de conceder la cone'in, un modo de alcan&ar el ob)etivo podra ser $ste3
.esgraciadamente las cosas no son tan simples, ,a acerca de esto un problema famoso, el "ro&lema %e las %os arma%as! 0a definicin del problema es la siguiente, los dos e)$rcitos #ue componen la armada A, son cada uno ms d$bil #ue el e)$rcito #ue constitu e la armada B! 0a armada A, es en cambio en su con)unto ms fuerte #ue la armada B* pero los dos e)$rcitos de la armada A slo pueden vencer si atacan al mismo tiempo! Adems, los mensa)es entre los e)$rcitos de la armada A, son llevados por mensa)eros #ue tienen #ue atravesar el territorio de la armada B, Prof. Manuel Castillo Cara
dnde pueden ser capturados! 4Cmo ,acen para ponerse de acuerdo los e)$rcitos de la armada A sobre la ,ora del ata#ue5 Una posibilidad es la siguiente, el comandante del e)$rcito < manda el mensa)e @atacamos a medianoc,e! 4Estis de acuerdo5A El mensa)e llega, un oC de respuesta parte llega a destino pero el comandante del e)$rcito D titubea por#ue no puede estar seguro #ue su respuesta ,a a llegado! +e podra pensar en resolver el problema con un paso ms, o sea con un three9&ay handsha'e! 0a llegada de la respuesta del e)$rcito D tiene #ue ser a su ve& confirmada! Pero a,ora #ui$n titubea es el comandante del e)$rcito <, por#ue si tal confirmacin se pierde, la armada D no sabr #ue su confirmacin a la propuesta de atacar ,a llegado, por lo tanto no atacar! A:adir posteriores pasos, no a uda, por#ue siempre ,a un mensa)e de confirmacin #ue es el 6ltimo, #ui$n lo enva no puede estar seguro #ue ,a a llegado! Por lo tanto, no e'iste solucin! +i a,ora reempla&amos la frase @atacamos la armada BA con @liberamos la cone'in@, vemos #ue se arriesga efectivamente de no liberar nunca una cone'in! Por suerte, liberar una cone'in es menos crtico #ue atacar a una armada enemiga! Por tanto, alg6n riesgo se puede asumir! Un protocolo de tipo three9&ay handsha'ing, enri#uecido con la gestin del timeout es considerado adecuado, aun#ue no infalible! El remitente manda un disconn(re)uest , si no llega respuesta dentro de un tiempo preestablecido o ti!eout, lo manda de nuevo por un m'imo de n vueltos* apenas llega una respuesta 1disconn(re)uest2, concede la cone'in en entrada manda un AC* de confirmacin* si no llega ninguna respuesta, despu$s del 6ltimo ti!eout, concede igualmente la cone'in en entrada* el destinatario, cuando recibe el disconn(re)uest, ,ace partir un tempori&ador, manda a su ve& un disconn(re)uest espera el acC de confirmacin! Cuando llega el AC* o vence el tempori&ador, concede la cone'in en entrada! Normalmente el funcionamiento es el siguiente3
+i se pierde el AC*3
+i en cambio se pierde la respuesta a la primera propuesta de cierre, suponiendo #ue el timeout del destinatario sea muc,o ms amplio #ue el del remitente3
En fin, se puede perder la respuesta a la primera propuesta de cierre propuestas de cierre3
en todas las sucesivas
El protocolo fracasa si todas las transmisiones de disconn(re)uest del peer entity #ue inicia el procedimiento se pierden! En tal caso, ella concede la cone'in, pero la otra entity no se entera la tiene abierta! El resultado es un half9open connection! Un modo para solucionar el problema, es #ue las partes concedan una cone'in cuando pasa un cierto la'o de tiempo, por e)emplo EF segundos, sin #ue lleguen datos! Naturalmente, en tal caso, los procesos tienen #ue intercambiarse los du!!y TPDU, es decir los TPDU vacos, con una cierta frecuencia* aun#ue no ,a necesidad de comunicar algunas, para evitar #ue la cone'in caiga!
8.1. Control De Fl23o 4 52$$er n)

En algunos aspectos, el control de flu)o a nivel de transporte es parecido al del nivel enlace de datos! Es necesario un mecanismo, como la gestin de un sliding &indo& 1ventana desli&ante2, para evitar #ue el destinatario sea inundado de TPDU! Pero tambi$n ,a importantes diferencias, como #ue el nivel de enlace de datos no tiene ning6n servicio donde apo arse, e'cepto la transmisin fsica! El nivel de transporte en cambio, usa los servicios del nivel de red, #ue pueden ser fiables o no, por lo tanto puede organi&arse! El n6mero de cone'iones de enlace de datos, es relativamente pe#ue:o 1uno por lnea fsica2 estable en el tiempo, mientras las cone'iones de transporte son potencialmente muc,as de n6mero ampliamente variable en el tiempo! 0as dimensiones de los TPDU son mu variables! +i el nivel de transporte slo cuenta con servicios de nivel de red de tipo datagra!, la entidad de transporte naciente, tiene #ue mantener en un buffer los TPDU enviados ,asta #ue no son confirmados, como se ,ace en el nivel de enlace de datos! 0a entidad de
transporte de destino puede tambi$n no mantener los buffer especficos para cada cone'in, pero slo un pool global 1reserva global2* cuando llega un (P.U, si no ,a espacio en el pool, no lo acepta! ;a #ue el remitente sabe #ue la subred puede perder pa#uetes, probar a transmitir el TPDU ,asta #ue llegue la confirmacin! 0o peor de todo, es #ue se pierde un poco de eficiencia! Por el contrario, donde sean disponibles servicios de red de tipo confiable, pueden darse otras posibilidades para el nivel de transporte! +i el remitente sabe #ue el destinatario siempre tiene espacio disponible en los buffer, por lo tanto siempre es capa& de aceptar los datos #ue le llegan, puede evitar mantener $l, los buffer, puesto #ue lo #ue enva, llegando indudablemente a destino* siempre es aceptado por el destinatario! +i no ,a esta garanta, el remitente tiene #ue mantener en todo caso los buffer, puesto #ue el destinatario recibir seguramente los TPDU enviados, pero podra no estar en grado de aceptarlos! Un problema asociado al buffering es como administrarlo, vista la gran variabilidad de dimensin de los TPDU! Un pool de buffer 1reserva de buffer2 todos iguales es poco apto, puesto #ue comporta un derroc,e de espacio para los TPDU de pe#ue:as dimensiones complicaciones para a#uellos grandes! Un pool de buffer de dimensiones variables es ms complicado de gestionar, pero es muc,o ms efica&! Una seleccin individual, ms bien grande, para cada cone'in, administrado circularmente, apto para cone'iones incmodas, comporta derroc,e de espacio para a#uellos con poco cambio de datos! En general, dada la gran variabilidad de condiciones #ue se pueden verificar, conviene adoptar reglas diferentes para cada caso! Para gestionar de la me)or manera estas situaciones, por costumbre los protocolos de nivel de transporte permiten a los peer entity ponerse de acuerdo con antelacin, al inicio de la cone'in, sobre los mecanismos de buferi+aci n para usar! Adems, a menudo la gestin de la dimensin de las ventanas desli&antes es desacoplada por la gestin de los AC*,s, veremos el caso de TCP!
8.8. M2lt "le' n)

Una importante oportunidad es la #ue ofrece el !ultiplexing de las conversaciones del nivel de transporte, sobre a#uellas del nivel de red! +i las cone'iones del nivel de red, en una red #ue las ofrece, son difciles de instituir, entonces es conveniente transportar muc,as conversaciones de transporte sobre una 6nica cone'in de red! A este fenmeno se le conoce con el nombre de 2"6ar% m2lt "le' n)!
Por el contrario, si se #uiere conseguir una banda superior a a#uella permitida a una cone'in individual de red, entonces se puede ganar banda repartiendo la conversacin de transporte sobre ms cone'iones de red! A esto se le conoce con el nombre de downward multiplexing! Eso puede ser 6til, por e)emplo, en una situacin dnde la subred aplica al nivel de red un control de flu)o sliding &indo& 1ventana desli&ante2, con n6meros de secuencia de G bites* el canal fsico es de sat$lite! +uponiendo #ue la dimensin de los pa#uetes sea de <DG b tes, el remitente puede enviar a lo sumo DG 9 < pa#uetes cada ?HF microsegundos, por lo tanto tiene a disposicin una banda de HGH Cbps, aun#ue la banda del canal sat$lite es tpicamente <FF veces ms grande! +i la conversacin de transporte es subdividida en, por e)emplo, <F cone'iones de red, podr disponer de una banda <F veces ma or!
8.7. El N !el De Trans"orte En Internet

El nivel de transporte de Internet est basado en dos protocolos3 TCP 1Trans!ission Control Protocol2 RIC >=J, <<DD <JDJ UDP 1User Data Protocol2 RIC >EG! Este segundo protocolo, es de ,ec,o IP con la a:adidura de un breve encabe&amiento, provee un servicio de transporte en datagramas, por lo tanto no fiable! 0o veremos brevemente a continuacin! El protocolo TCP ,a sido pro ectado para proveer un flu)o de b tes fiables, de origen a destino, sobre una red no confiable! Por lo tanto, ofrece un servicio fiable connection oriented 1orientado a la cone'in2, se ocupa de3 Aceptar datos del nivel de aplicacin partirlos en segmentos, el nombre usado por los TPDU 1dimensin m'ima EH Kb tes, tpicamente cerca de <!?FF b tes2, consignarlos al nivel de red, recibir segmentos del nivel de red, reponerlos en orden, eliminando agu)eros duplicados* entregar los datos, en orden, al nivel de aplicacin! Es un servicio full9duplex con gestin de AC* control del flu)o!
8.7.1. En#am nam ento

0os servicios de TCP, se consiguen creando cone'iones de nivel de transporte identificada por una pare)a de puntos de acceso soc'et! Cada soc'et tiene un soc'et nu!ber #ue consta de la pare)a3 "P address Port nu!ber! El soc'et nu!ber constitu e el TSAP! 0os port number tienen <E bites! A#uellos menores de D?E son los llamados puertos bien conocidos 1&ell9'no&n port2 estn reservados por los servicios estndares! Por e)emplo3
Cuando las cone'iones (CP, #ue son full duplex point to point, son identificadas por la pare)a de soc'et nu!ber a las dos e'tremidades, es posible #ue sobre un host individual, ms cone'iones sean certificadas localmente sobre el mismo soc'et nu!ber!
0as conexiones TCP, transportan un flu)o de b tes, no de mensa)es* los confines entre mensa)es no son ni definidos ni preservados! Por e)emplo, si el proceso remitente, del nivel de aplicacin, enva H blo#ues de ?<D b tes, a#uel destinatario puede recibir3 G @tro&os@ de D?E b tes* < @tro&o@ de D!FHG b tes*!!! +on las entidades (CP, #uienes piensan en subdividir el flu)o en llegada del nivel de aplicacin en segmentos, a transmitirlos a recombinarlos en un flu)o #ue es consignado al nivel aplicacin de destino! %a en todo caso la posibilidad, para el nivel aplicacin, de for&ar el envo inmediato de datos* eso causa el envo de un flag urgent 1se:al de urgencia2 #ue, cuando llega de la otra parte, ,ace #ue la aplicacin sea interrumpida se dedica a e'aminar los datos urgentes!
8.7.2. El Proto#olo TCP

0as caractersticas ms importantes son las siguientes3 cada b te del flu)o TCP est numerado con un n6mero de orden a JD bits, usado bien por el control de flu)o #ue por la gestin de los ACK* un segmento TCP no puede superar los E?!?J? b te! Un segmento TCP est formado de un ,eader, #ue a su ve& est constituida de una parte fi)a de DF b te, una parte opcional los datos para transportar! (CP usa un mecanismo de sliding &indo& 1ventana desli&ante2 de tipo go9bac'9n 1volver atrs tras n2 con ti!eout! +i esto sucede, el segmento se retransmite! Lbservar #ue las dimensiones de la ventana desli&ante los valores de los AC* son e'presados en n6mero de byte, no en n6mero de segmentos!
0os campos del ,eader tienen las siguientes funciones3

Source port y Destination Port 1P2erto Or )en 8 Dest no2!9 Identifican los end
point 1puntos finales2, locales a los dos ,ost, de la cone'in! Identifica un servicio con un n6mero entero de F a E??J?, por e)emplo, el correo electrnico es el puerto D?! 0a direccin IP a:adida al puerto nos da un soc'et #ue es un TSAP 1Transport Service Access Point2!
Sequence number 1n9mero %e se#2en# a2!9 Indica en una comunicacin completa,
#u$ segmento o parte es la actual! Es decir, el n6mero de orden del primer b te contenido en el campo de datos!
A#: number ;n9mero %e #on$ rma# (n<!9 Indica #u$ byte o segmento se espera
recibir enseguida, lo cual es una confirmacin del byte o fragmento anterior! Es decir, el n6mero de orden del pr'imo b te esperado!
TCP header length 1lon) t2% %el en#a&eza%o TCP2!9 Indica cuntas palabras de JD
bits forman el encabe&ado, como son tres bits, puede ,aber de F a > palabras, lo cual se usa para saber dnde comien&an los datos!
=ona s n n n)9n te'to!9 0uego ,allamos E bits #ue no tienen uso,
#ue no se ,an usado por ms de die& a:os, lo cual algunos autores atribu en al buen dise:o de (CP, pero 4Realmente no se usa, los militares #u$ dicen5 urgencia tiene significado para este segmento!
Bit URG!9 < si urgent pointer es usado, F en caso contrario! Indica si el apuntador de Bit C!!9 < si el AC* nu!ber es vlido, F en caso contrario! Indica si el n6mero de
confirmacin tiene significado para este segmento!

Bit PS"!9 .atos urgentes, pushed data! Indica si este segmento debe entregarse de
inmediato sin pasar a un buffer!

Bit RST#9 Indica #ue la cone'in debe reiniciarse por#ue se present alg6n problema
ma or, por e)emplo, #ue un nodo se da: se #uiere comen&ar desde cero!
Bit S$%!9 Usado en la fase de setup 1establecimiento2 de la cone'in3 El par
1S-$./0 AC*.12 indica la primitiva Cone'in +olicitada es Cone'in Aceptada!

Bit &'%!9 Indica #ue el emisor,
el par 1 S-$./0 AC*./2
slo el emisor a no va a enviar ms datos #ue desea terminar con la cone'in! Pero puede suceder #ue a6n transitan segmentos ,acia el destino, esos segmentos tendrn un n6mero de secuencia menor al segmento #ue contiene el 2"$./! de dimensin variable! Mindo/ si&e dice cuntos b tes pueden ser enviados a partir de a,, incluido, #ue es confirmado con el AC* nu!ber! Un valor cero significa3 parados por un tiempo, reanudndose cuando llegue otro AC* nu!ber igual con un valor de &indo& si+e diferente de cero!
(indow si)e 1Lon) t2% %e !entana2!9 El control de flu)o es de tipo sliding &indo&
Chec*sum 1Ca%ena %e C>e?2eo2!9 Parecido a a#uel de IP* el clculo inclu e un
pseudo,eader! Permite verificar #ue el encabe&ado, los datos un encabe&ado interno a la cadena de c,e#ueo est$n correctos! El algoritmo usado consiste en ir sumando cada <E bits en complementos a unos luego tomar el complemento a unos del resultado de la suma, lo cual da la cadena de c,e#ueo! El receptor debe obtener un cero al sumar todo, si no, el segmento est da:ado!
Urgent pointer 1A"2nta%or %e 2r)en# a2!9 Indicador de los datos urgentes! Es
interpretado si el 3it U45./! Entonces este apuntador contiene el n6mero de b te a partir del n6mero de secuencia en donde ,a datos urgentes 1como una interrupcin2, lo cual permite #ue a no se procesen datos in6tilmente!
+ptions 1O"# ones2!9 +irven para #ue se implanten nuevas facilidades en el
protocolo #ue no se contemplaron en el dise:o original de TCP! Por e)emplo, un uso com6n es #ue con las opciones se indica el tama:o m'imo de segmento entre dos nodos! En el clculo del chec'su! tambi$n entra un pseudoheader, en abierta violacin de la )erar#ua, puesto #ue el nivel TCP en este clculo opera sobre direcciones "P!
El pseudoheader no es transmitido, pero precede conceptualmente al header! +us campos tienen las siguientes funciones3
Por otro lado, cabe remarcar #ue una cone'in tpica en (CP, donde N<Nnodo <, NDNnodoD, sera3
<! N1@S4N1 +E8N' 2 9O N2 D! N2@S4N1 +E8N , ACKN'P< 2 9O N1, J! N1@S4N1 +E8N'P<, ACKN P< 2 9O N2!
Esta conversacin se conoce como a ,emos comentado anteriormente, t>ree 6a8 >an%s>a:e! En el intercambio de mensa)es de control para crear terminar una cone'in, (CP puede caer en varios estados3
8.7.+. A#t !a# (n De La Cone' (n

Para ello se usa el three9&ay handsha'e visto anteriormente! Una de las dos partes, decimos el servidor, e)ecuta dos primitivas, listen67 despu$s accept12, #uedando as en espera de una solicitud de cone'in sobre un determinado port nu!ber, cuando esa llega, aceptndola! 0a otra parte, un client, e)ecuta la primitiva connect 67, especificando host, port nu!ber otros parmetros como la dimensin m'ima de los segmentos, para establecer la cone'in* tal primitiva causa el envo de un segmento TCP con el bit s n a uno el bit acC a cero! Cuando tal segmento llega a destino, el entit del nivel de transporte controla si ,a un proceso en escuc,a sobre el port nu!ber en cuestin! +i no ,a nadie en escuc,a, enva un segmento de respuesta con el bit 4ST a uno, para rec,a&ar la cone'in* de otro modo, entrega el segmento llegado al proceso en escuc,a* si este acepta la cone'in, el entity enva un segmento de confirmacin, con ambos bites S-$ AC* a uno, seg6n el siguiente es#uema!
0os valores de ' e son obtenidos de los hosts sobre la base de sus relo)es de sistema* el valor se incrementa en una unidad cada H microsegundos!
8.7.,. L &era# (n De La Cone' (n

0a liberacin de la cone'in ocurre considerando la cone'in full9duplex como una pare)a de cone'iones si!plex independientes, se desarrolla del siguiente modo! Cuando una de las dos partes no tiene nada ms #ue transmitir, manda un fin* cuando esto es confirmado, la cone'in en salida es concedida! Cuando tambi$n la otra parte completa el mismo procedimiento concede la cone'in en otra direccin, la cone'in full9duplex acaba! Para evitar el problema de los J e)$rcitos se usan los tempori&adores, programados al doble de la vida m'ima de un pa#uete! El protocolo de gestin de las cone'iones se representa com6nmente como una m#uina a estados acabados! -sta es una representacin mu usada en el campo de los protocolos, por#ue permite definir, con cierta facilidad sin ambigQedad, tambi$n protocolos mu comple)os!
8.7.-. PolAt #a De Transm s (n

0a idea de fondo es la siguiente, la dimensin de las ventanas desli&antes no est relacionada estrec,amente con los AC*,s, como sucede ,abitualmente, pero es adaptada continuamente a trav$s de un dilogo entre destino origen! En particular, cuando el destino enva un acC de confirmacin, tambi$n dice cuntos b tes pueden ser enviados posteriormente! En el e)emplo #ue sigue, los peer entity se ,an acordado preventivamente sobre un buffer de HK en destino!
Aun#ue recibe &in.1, el remitente puede enviar en todo caso, datos urgentes, solicitudes de reenvo del 6ltimo AC* enviado!
8.7./. Control De Con)est (n

El protocolo (CP asume #ue, si los acC no vuelven a tiempo, eso sea debido a la congestin de la subred antes #ue a errores de transmisin, puesto #ue las modernas lneas de transmisin son mu fiables! Por lo tanto, (CP est preparado para afrontar dos tipos de problemas, por un lado, la escase& de buffer en destino por otro, la congestin de la subred! Cada uno de los problemas, es administrado por una ventana especifica mantenida por el remitente3 la ventana del buffer del receptor 1a#uella del e)emplo anterior2 la ventana de congestin, #ue representa cunto se puede enviar sin causar congestin! El remitente se regula sobre la ms pe#ue:a de las dos! 0a congestion &indo& 1ventana de congestin2 es administrado de este modo! El valor inicial, es igual a la dimensin del m'imo segmento usado en la cone'in* cada ve& #ue un acC vuelve atrs a tiempo, la ventana se duplica, ,asta un valor threshold, inicialmente igual a EH Kb tes, despu$s de lo #ue aumenta linealmente en un segmento a la ve&! Cuando se verifica un ti!eout por un segmento, el valor de threshold viene programado con la mitad de la dimensin de la ventana de congestin* la dimensin de la ventana de congestin es programada con la dimensin del m'imo segmento usado en la cone'in! "eremos a,ora un e)emplo, con segmentos de dimensin < Kb tes, t,res,old a JD Kb tes la ventana de congestin, alcan&ando HF Kb tes3
8.7.1. El Proto#olo UDP

El nivel de transporte, proporciona tambi$n un protocolo no conectado no fiable, 6til para enviar datos sin establecer cone'iones, por e)emplo para aplicaciones cliente9servidor! El ,eader de un segmento UDP es mu simple3
0a funcin de clculo del chec'su! 1cadena de c,e#ueo2 puede ser desactivada, tpicamente en el caso de trfico a tiempo real, como vo& vdeo, por lo #ue es generalmente ms importante mantener una elevada tasa de llegada de los segmentos antes #ue evitar los e'tra:os errores #ue pueden ocurrir!

Tema 8. Funcionamiento A Nivel de Transporte

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tema 8. Funcionamiento A Nivel de Transporte

Încărcat de

Drepturi de autor:

Formate disponibile

Conceptos bsicos para la administracin de redes Administracin de Redes Escuela Profesional de Ciencias de la Computacin Universidad Nacional de Ingeniera

TEMA 8. FUNCIONAMIENTO A NIVEL DE TRANSPORTE

8.2. El N !el De Trans"orte

Prof. Manuel Castillo Cara

Prof. Manuel Castillo Cara

Prof. Manuel Castillo Cara

8.+. Proto#olos De N !el Trans"ort

8.,. En#am nam ento

8.-. A#t !a# (n De La Cone' (n

Prof. Manuel Castillo Cara

Prof. Manuel Castillo Cara

8./. L &era# (n De Una Cone' (n

Prof. Manuel Castillo Cara

Prof. Manuel Castillo Cara

En fin, se puede perder la respuesta a la primera propuesta de cierre propuestas de cierre3

en todas las sucesivas

8.1. Control De Fl23o 4 52$$er n)

8.8. M2lt "le' n)

Prof. Manuel Castillo Cara

Prof. Manuel Castillo Cara

8.7. El N !el De Trans"orte En Internet

8.7.1. En#am nam ento

8.7.2. El Proto#olo TCP

0os campos del ,eader tienen las siguientes funciones3

Sequence number 1n9mero %e se#2en# a2!9 Indica en una comunicacin completa,

confirmacin tiene significado para este segmento!

inmediato sin pasar a un buffer!

1S-$./0 AC*.12 indica la primitiva Cone'in +olicitada es Cone'in Aceptada!

el par 1 S-$./0 AC*./2

Chec*sum 1Ca%ena %e C>e?2eo2!9 Parecido a a#uel de IP* el clculo inclu e un

Urgent pointer 1A"2nta%or %e 2r)en# a2!9 Indicador de los datos urgentes! Es

Prof. Manuel Castillo Cara

8.7.+. A#t !a# (n De La Cone' (n

8.7.,. L &era# (n De La Cone' (n

8.7.-. PolAt #a De Transm s (n

Prof. Manuel Castillo Cara

8.7./. Control De Con)est (n

Prof. Manuel Castillo Cara

8.7.1. El Proto#olo UDP

Prof. Manuel Castillo Cara

S-ar putea să vă placă și

Checsum 1Ca%ena %e C>e?2eo2!9 Parecido a a#uel de IP el clculo inclu e un