5 EL NIVEL DE TRANSPORTE EN INTERNET

Transcripción

1 5 EL NIVEL DE TRANSPORTE EN INTERNET Autr: Rgeli Mntañana 5 EL NIVEL DE TRANSPORTE EN INTERNET INTRODUCCIÓN Primitivas del servici de transprte La interfaz sckets ELEMENTOS DE PROTOCOLOS DE TRANSPORTE Establecimient de una cnexión Terminación de una cnexión Cntrl de fluj y de buffers Multiplexación Recuperación de caídas LOS PROTOCOLOS DE TRANSPORTE DE LA INTERNET: TCP Y UDP TCP (Transprt Cntrl Prtcl) La cabecera de segment TCP Tamañ de segment y fragmentación Fluj de dats en TCP Intercambi de infrmación en TCP Gestión de cnexión TCP Estads de TCP Cnexines medi abiertas y timer de keepalive Plítica de transmisión de TCP Prblemas de paquetes pequeñs Algritm de Nagle Síndrme de la ventana tnta y slución de Clark Cntrl de cngestión en TCP Gestión de timers en TCP Opcines del prtcl TCP UDP (User Datagram Prtcl) EJERCICIOS SOLUCIONES

2 Redes de Ordenadres 5.1 INTRODUCCIÓN El nivel de transprte se encarga de suministrar el servici de transprte de bits a las aplicacines. Éstas funcinan generalmente según el paradigma cliente-servidr, pr el cual una aplicación (cliente) tma la iniciativa y slicita ls servicis a la tra (servidr). Cm ya sabems la cmunicación 'peer t peer' entre ds entidades del nivel de transprte curre en realidad gracias a ls servicis frecids pr el nivel de red. Mientras que el nivel de red se cupa de reslver ls prblemas prpis de la tplgía de ésta (rutas y cngestión fundamentalmente) el nivel de transprte sól existe en las ds entidades extremas de la cmunicación, pr l que también se le llama nivel hst-hst extrem a extrem. El nivel de transprte n es cnsciente, ni debe serl, de la manera cm físicamente están intercnectads ls ds hsts, que puede ser pr una LAN, una WAN una cmbinación de múltiples redes de ambs tips. La unidad básica de intercambi de infrmación a nivel de enlace se denmina trama (prque ls dats van 'rdeads' de infrmación de cntrl pr delante y pr detrás). En el nivel de red esta unidad básica se cnce cm paquete. N existe un términ equivalente para la unidad de transferencia de infrmación en el nivel de transprte; a falta de mejr alternativa utilizarems para este fin el términ OSI TPDU (Transprt Prtcl Data Unit); en la Internet se suele utilizar el términ mensaje en el cas de UDP (servici n rientad a cnexión), y segment en el de TCP (servici rientad a cnexión), per esta nmenclatura n es cmpartida pr trs prtcls de transprte. Generalmente las aplicacines requieren que el nivel de transprte les garantice la entrega de ls dats al destinatari, sin errres, pérdidas ni dats duplicads; para que est sea psible el nivel de transprte frecerá nrmalmente un servici rientad a cnexión, cn retransmisines en cas necesari. Este es el cas pr ejempl del prtcl TCP de Internet, utilizad en muchas aplicacines cm FTP (File Transfer Prtcl, transferencia de fichers), SMTP (Simple Mail Transfer Prtcl, crre electrónic), HTTP (HyperText Transfer Prtcl, usad en tráfic Web), etc. En casines las aplicacines se cnfrman - inclus prefieren- un servici mens fiable en el que ls mensajes se envían sin pedir cnfirmación, de frma independiente uns de trs. Este tip de servici se suministra nrmalmente cn un prtcl n rientad a cnexión. El prtcl UDP de Internet es un ejempl de este tip de servici. Entre ls cass en que se quiere un servici de este tip se encuentran pr ejempl las aplicacines en tiemp real ya que en ese cas n se quiere incurrir en el retard prpi de un prtcl rientad a cnexión. Al igual que en Internet en OSI también hay ds prtcls de transprte, un rientad a cnexión y un n rientad a cnexión. La tabla 5.1 muestra ls más imprtantes prtcls de nivel de red y de transprte de Internet y sus crrespnidentes prtcls OSI. Tip de prtcl Internet OSI Nivel de red IP (Internet Prtcl) CLNP (CnnectinLess Netwrk Prtcl) Ruting intern OSPF (Open Shrtest Path First) IS-IS ( Intermediate System t Intermediate System) Ruting extern BGP (Brder Gateway Prtcl) IDRP (InterDmain Ruting Prtcl) Nivel de transprte, rientad TCP (Transmissin Cntrl TP4 (Transprt Prtcl clase 4) a cnexión Nivel de transprte, n rientad a cnexión Prtcl) UDP (User Datagram Prtcl) TP0 (Transprt Prtcl clase 0) Tabla Crrespndencia de prtcls Internet y OSI a nivel de red y de transprte Nrmalmente las entidades del nivel de transprte se implementan cm prcess en el sistema perativ del hst, bien prcess de usuari. El sistema perativ puede ser mnusuari multiusuari. En 5-2

3 El Nivel de Transprte en Internet muchs cass el hst tiene una sla instancia del nivel de red, y una sla del de transprte, per muchas de ls niveles superires (aplicación sesión); el nivel de transprte se encarga de mutiplexar el tráfic recibid de las diversas entidades de nivel superir en una única cnexión a través del nivel de red. Ls prtcls de transprte n rientads a cnexión, cm UDP, sn prtcls muy sencills, que existen únicamente para permitir la crrecta cnexión de la capa de aplicación y la de red; actúan cm una capa de adaptación bastante primitiva. Pr est la mayría de nuestra discusión se centrará en ls prtcls rientads a cnexión, a ls que ns referirems implícitamente la mayr parte del tiemp Primitivas del servici de transprte En un servici de transprte básic rientad a cnexión (CONS) la secuencia de primitivas pdría ser alg cm l siguiente: PRIMITIVA TPDU PRIMITIVA TPDU CLIENTE ENVIADA SERVIDOR ENVIADA Listen (blquead) Cnnect (blquead) Receive Send (blquead) Petición cnexión Dats Receive Discnnect Petición descnexión Receive Send (blquead) Receive Send (blquead) Cnexión aceptada Dats (libera cnexión) Receive Discnnect Petición descnexión (libera cnexión) Listen (blquead) La interfaz sckets Cm ya vims en el tema 1 la interfaz utilizada entre ls diferentes niveles de un mism sistema n frma parte de un prtcl de cmunicacines. Ds sistemas necesitan acrdar las reglas que seguirá la cmunicación entre ells en cada un de ls niveles, per la frma cm se realiza la cmunicación vertical, es decir, la que curre dentr de un sistema es asunt intern que n incumbe a ls prtcls. Esa cmunicación vertical se realiza nrmalmente mediante las denminadas APIs (Applicatin Prgramming Interfaces). Aunque n requerida pr las cmunicacines, la estandarización de las APIs cmprta uns beneficis evidentes pr la psibilidad de aprvechar sftware entre sistemas diferentes. Est es especialmente ciert en el nivel de transprte, ya que es aquí dnde interaccinarán más prgramas diferentes, crrespndientes a las diversas aplicacines que se desarrllen. Muchas implementacines de TCP/IP dispnen de una API para prgramación aplicacines denminada sckets (literalmente enchufes, aunque nunca se utiliza esta denminación). Ls sckets se intrdujern cn el sistema perativ UNIX BSD 5-3

4 Redes de Ordenadres (Berkeley Sftware Distributin) en La interfaz sckets es multiprtcl, sprta TCP, UDP y trs prtcls. Aun cuand n frman parte de ningún estándar ficial ni están recgids en ningún RFC, ls sckets sn la API más extendida en prgramación de aplicacines TCP/IP y frman un estándar 'de fact'. Existen implementacines para muchs sistemas perativs n UNIX, e inclus en cass en que el sistema perativ n ls incrpra suele haber una librería de rutinas sckets que permite adaptar prgramas cn relativa facilidad. Pr ejempl, la interfaz WinSck permite adaptar aplicacines MS Windws sbre diversas implementacines de TCP/IP. Al n ser un estándar puede haber pequeñas diferencias entre implementacines, pr l que es cnveniente dispner siempre de la dcumentación crrespndiente al sftware que se utiliza. La filsfía básica de ls sckets deriva directamente del sistema de entrada/salida de UNIX, cn ampliacines que permiten pr ejempl a un prces servidr pnerse 'a la escucha'. Algunas de las rutinas generan y envían las TPDUs a partir de sus arguments; éstas (las TPDUs) sí frman parte del prtcl, pr l que deben de ser cnfrmes cn el estándar crrespndiente. 5.2 ELEMENTOS DE PROTOCOLOS DE TRANSPORTE Al cuparse de la cmunicación extrem a extrem punt a punt, el nivel de transprte se parece en alguns aspects al nivel de enlace. Así pr ejempl, entre ls asunts de ls que nrmalmente habrá de cuparse se encuentran el cntrl de errres (incluyend mensajes perdids duplicads) y el cntrl de fluj. Aunque las técnicas que se aplican sn parecidas, existen imprtantes diferencias entre ambs mtivadas pr el hech de que en el nivel de enlace hay sól un hil físic ( su equivalente) entre las ds entidades cmunicantes, mientras que en el nivel de transprte hay tda una red. Las mayres diferencias entre el nivel de transprte y el de enlace sn las siguientes: El retard que se bserva en el nivel de transprte es nrmalmente much mayr y sbre td más variable (mayr jitter) que en el de enlace. En el nivel de enlace el medi físic entre las ds entidades tiene una capacidad de almacenamient de infrmación nrmalmente muy reducida y siempre la misma; en el de transprte ls ruters intermedis pueden tener una capacidad cnsiderable y esta puede variar cn el estad de la red. En el nivel de enlace se asegura que las tramas llegarán al receptr en el mism rden que han salid del emisr (salv que se pierdan, en cuy cas n llegarán); en el nivel de transprte est es ciert sl cuand se utiliza un servici rientad a cnexión en el nivel de red; si se utiliza un servici n rientad a cnexión el receptr pdría recibir ls dats en rden distint al de emisión. En el nivel de enlace las ds entidades se 'ven' directamente (supniend una cmunicación dúplex); a veces inclus de frma permanente, pr ejempl en una cmunicación síncrna tip HDLC están cntinuamente emitiend la secuencia ; est permite que el emisr sepa en td mment si el receptr está perativ, y el receptr sabe que ls dats recibids crrespnden tds a una misma sesión del emisr. En el nivel de transprte la cmunicación es indirecta; el emisr pdría enviar dats, quedar fuera de servici y más tarde entrar en funcinamient tra vez; si n se adptan las medidas prtunas el receptr pdría recibir tds ess dats sin siquiera percatarse de que crrespnden a ds sesines distintas del emisr (inclus pdrían pertenecer a ds usuaris distints). Recrdems que en el mdel OSI cada nivel presta sus servicis al nivel superir a través del SAP (Service Access Pint), cada un de ls cuales es identificad pr una dirección. Pr ejempl en Internet la dirección SAP pr la que el nivel de red accede al servici es la dirección IP del hst, que hems vist en el tema anterir. La dirección SAP pr la que el nivel de transprte accede al servici de red está frmada pr el camp prtcl del datagrama IP (6 para TCP y 17 para UDP, pr ejempl). A su vez el nivel de transprte frece sus servicis al nivel de aplicación a través de uns SAPs específics, que en el 5-4

5 El Nivel de Transprte en Internet cas de Internet sn ls denminads prts puerts. Ests puerts se denminan también TSAPs (Transprt Service Acces Pint). Para que un prces cliente de un hst pueda cmunicar cn un prces servidr en tr hst haciend us de ls servicis de su nivel de transprte es precis que cnzca el TSAP crrespndiente en el hst de destin. Nrmalmente esta infrmación frma parte del estándar del prtcl, pr l que es universalmente cncid y cualquier cliente que l desee sabe que TSAP debe utilizar para acceder a dich servidr. En cambi el TSAP del cliente n necesita ser cncid pr trs usuaris y puede ser diferente para cada cnexión Establecimient de una cnexión En principi para establecer una cnexión el cliente emite una TPDU de petición de cnexión, y el servidr respnde cn una TPDU de aceptación; a partir de ese mment puede empezar el intercambi de dats. Sin embarg cuand analizams el prces de cnexión cn mayr detalle encntrams diverss prblemas que pueden presentarse y que hay que prever. Recrdems que en el nivel de transprte puede haber una gran fluctuación (a veces del rden de segunds) en el tiemp que tardan en llegar las TPDUs a su destin; las TPDUs pueden perderse llegar duplicadas, ya que si el emisr n recibe cnfirmación reenviará la misma TPDU pasad el timeut. Imaginems que el cliente intercambia una serie de TPDUs cn el servidr, y cuand ya ha terminad la transacción cierra la sesión; segunds mas tarde de algún rincón de la red aparecen la misma secuencia de TPDUs del cliente duplicadas que llegan al servidr de nuev; éste realizaría la misma transacción tra vez, cn efects psiblemente desastrss 1. Para evitar este tip de prblemas se utiliza para establecer la cnexión el mecanism cncid cm salud a tres vías (three-way handshake). La idea es que el servidr sól aceptará la cnexión después de haber pedid al cliente cnfirmación de que desea realizarla. En principi est pr sí sl n resuelve nuestr prblema, ya que cabría pensar que después de la TPDU de petición inicial duplicada la red le entregue al servidr la TPDU de cnfirmación, también retrasada. La slución a este prblema es la siguiente: tant el cliente cm el servidr utilizan un prtcl de ventana deslizante para el enví de las TPDUs, para l cual emplean un númer de secuencia; a diferencia del númer de secuencia que vims en el nivel de enlace, el del nivel de transprte emplea rangs muy amplis (pr ejempl en TCP el númer de secuencia se almacena en un camp de 32 bits, cn l que es un númer módul 2 32 ). Tant el cliente cm el servidr eligen de frma aleatria pseudaleatria el valr inicial del númer de secuencia que van a utilizar, cada un pr separad para cada sentid de la cmunicación. El cliente infrma al servidr en su primera TPDU del númer de secuencia elegid; pr su parte el servidr le respnde en tra TPDU cn el númer de secuencia elegid pr él, incluyend en ésta un ACK piggybacked de la TPDU recibida. De esta frma si el servidr recibe una TPDU de petición de cnexión vieja respnderá cn una TPDU al cliente en la que pndrá en el camp ACK el númer de secuencia recibid; cuand la respuesta llegue al cliente éste verá que ese númer n crrespnde cn ninguna cnexión que él tuviera pendiente de cnfirmación, pr l que rechazará la cnexión; el servidr pr su parte esperará recibir en el camp ACK de la siguiente TPDU un valr que crrespnda cn el que él ha enviad en la anterir. La técnica de ls númers de secuencia aleatris evita también el riesg de que un prces cliente que cae pr algún mtiv (pr ejempl pr un fall de crriente) utilice la misma cnexión cuand reaparece más tarde, ya que nrmalmente el nuev prces intentará utilizar un númer de secuencia diferente. Esta es una medida de seguridad ya que el nuev prces cliente pdría pertenecer a tr usuari; supngams pr ejempl que al inici de la cnexión se realiza una identificación cn clave usuari/passwrd ante el servidr, en tal cas el nuev cliente pdría acceder a tds ls recurss del usuari anterir sin identificarse. Generalmente se establece una vida máxima para las TPDUs en la red; de esta frma se reduce el riesg de recibir duplicads retrasads. Cuand un sistema cae y vuelve a arrancar se recmienda esperar al 1 Si pr ejempl la transacción cnsiste en la transferencia de diner entre cuentas bancarias se realizarían ds trasferencias en vez de una. 5-5

6 Redes de Ordenadres mens el tiemp de vida de las TPDUs antes de activar el nivel de transprte; de esta manera es impsible que una TPDU de la sesión anterir pueda aparecer pr alguna parte cuand se inicia la sesión nueva. En Internet pr ejempl el tiemp de vida máxim recmendad de las TPDUs es de 2 minuts, y se cntrla mediante el camp TTL en el datagrama IP. Una vez establecids ls númers de secuencia es psible utilizar para el intercambi de TPDUs cualquier prtcl de ventana deslizante. A diferencia del nivel de enlace, dnde el prtcl se basa en numerar tramas, en el nivel de transprte se suelen numerar bytes, ya que el tamañ de las TPDUs puede ser muy variable. Para las retransmisines se puede utilizar tant retrces n cm repetición selectiva Terminación de una cnexión Una cnexión puede terminarse de frma simétrica asimétrica. La terminación asimétrica es unilateral, es decir un de ls ds hsts decide terminar y termina la cnexión en ambs sentids. En la terminación simétrica cada hst crta la cnexión únicamente en el sentid en el que emite dats; pdems cnsiderar la terminación simétrica cm ds circuits simplex dnde cada un es cntrlad pr el emisr. La terminación asimétrica se cnsidera anrmal y puede prvcar la pérdida de infrmación, ya que cuand un hst ha enviad la TPDU de descnexión ya n acepta más dats; entretant el tr hst pdría haber enviad una TPDU de dats que n será aceptada. En la terminación simétrica -la más nrmal- el hst 1 'invita' al hst 2 a descnectar mediante una TPDU DISCONNECT REQUEST; el hst 2 respnde cn tra DISCONNECT REQUEST, a la cual el hst 1 respnde cn una TPDU ACK y cierra la cnexión; el hst 2 cerrará la cnexión al recibir el ACK. Pr este mecanism se asegura que n se pierden TPDUs 'en ruta' ya que ambs hsts tienen avis previ de la descnexión y dan su cnfrmidad explícitamente. Este mecanism supne el intercambi de tres mensajes de frma análga al prces de cnexión, pr l que también se denmina salud a tres vías (aunque quizá debería llamarse despedida a tres vías ); n existe frma fiable de terminar la cnexión en mens mensajes sin crrer el riesg de perder dats. Si se pierde alguna de las TPDUs de descnexión el mecanism del salud atres vías falla pues ls hsts se quedan esperand eternamente la respuesta. Para evitar est se utiliza un mecanism de timeuts que resuelve el prblema reenviand la TPDU perdida si se trata de un DISCONNECT REQUEST, cerrand la cnexión pr timeut cuand l que se ha perdid es el ACK. En el Tanenbaum Fig aparece una relación de ls cass 'patlógics' que pueden currir y cm se resuelven. Existen muchas circunstancias que pueden prvcar que una cnexión se quede medi abierta, es decir abierta sól pr un lad. Pr ejempl, un hst puede quedar fuera de servici sin previ avis y el tr, que tenía una cnexión abierta cn él, quedar a la espera sin saber que ha currid. Para reslver estas situacines se prevé nrmalmente un tiemp máxim durante el cual una cnexión puede estar abierta sin tráfic; pasad ese tiemp ls hsts se envian mensajes de prueba (denminads keep-alive en TCP) para cmprbar que el tr lad aún respnde. Ls valres de timeut para el enví de mensajes keep-alive sn increíblemente grandes (la dcumentación de TCP sugiere 2 hras cm valr pr defect). Un valr muy pequeñ pdría prvcar que un fall mmentáne en la red cerrara cnexines a nivel de transprte, perdiend así la principal ventaja de las redes de datagramas. Analicems ahra que curre si ds hsts tienen establecida una cnexión entre ells y falla la red que ls une. En el cas de utilizar un servici rientad a cnexión (X.25, ATM) generalmente la sesión termina de manera abrupta, pues la vía de cmunicación (el circuit virtual) ha desaparecid y para restaurar la cmunicación habrá que restablecer el circuit, presumiblemente pr un camin físic diferente. En el cas de utilizar un servici de red n rientad a cnexión (IP, OSI CLNP) la red reencaminará ls datagramas pr una ruta alternativa (supniend que exista) pr l que l únic que el nivel de transprte detectará es la pérdida de unas pcas TPDUs, per la cnexión n se crtará Cntrl de fluj y de buffers 5-6

7 El Nivel de Transprte en Internet El cntrl de fluj en el nivel de transprte es fundamental, ya que la velcidad cn que ls dats llegan al receptr puede ser muy variable al intervenir multitud de factres. Cm ya hems dich se suelen utilizar prtcls de ventana desilzante. Mientras que en el nivel de enlace se asignaba de manera estática un espaci de buffers a cada cnexión, en el nivel de transprte esta estrategia n es adecuada, pues el númer de cnexines simultáneas puede variar muchísim al n haber una interfaz física asciada a cada cnexión. Pr este mtiv la asignación de espaci para buffers en el nivel de transprte tiene ds características singulares que le diferencian del nivel de enlace. En primer lugar el espaci de buffers es cmún y cmpartid pr tdas las cnexines, entrantes y salientes. En segund lugar el repart del espaci entre las cnexines activas se hace de frma dinámica de acuerd cn las necesidades; una cnexión cn pc tráfic recibirá mens asignación que una cn much tráfic. En td mment cada cnexión tiene asignad un espaci para emisión y un para recepción; el espaci de emisión está cupad cn TPDUs pendientes de ser enviadas de cnfirmación; el espaci de recepción tiene una parte cupada cn TPDUs recibidas pendientes de ser aceptadas pr el nivel de aplicación, y tra libre reservada para TPDUs que puedan llegar del tr hst. Otra diferencia respect al nivel de enlace estriba en que, mientras que el tamañ de las tramas suele ser cnstante para una cnexión física dada, el tamañ de las TPDUs puede ser muy variable. Para ptimizar la utilización del espaci se asignan segments de buffer de lngitud variable. Para una máxima flexibilidad en este sentid tant ls númers de secuencia cm ls tamañs de ventana cuentan generalmente bytes, n TPDUs. La parte de buffer que el receptr tiene reservada para TPDUs que puedan llegarle es anunciada al emisr regularmente, para que éste sepa que cantidad de dats esta dispuest a aceptar el receptr. Este espaci puede fluctuar much cn el tiemp en función de la actividad que tenga esa y el rest de cnexines que mantenga el hst. Cn este md de funcinamient el receptr realmente cntrla la situación, ya que si indica una ventana cer el emisr tendrá que esperar y n enviarle dats mientras el receptr n le anuncie una ventana mayr. Veams un ejempl sencill de cm funcinaría una sesión TCP: HOST 1 HOST 2 Seq=1000,Win=4000 Seq=1500,Ack=1001,Win=4000 Seq=1001,Ack=1501,dats(1000) Seq=1501,Ack=2001,dats(1000) Seq=2001,Ack=2501,dats(1000) Seq=3001,Ack=2501,dats(1000) Seq=4001,Ack=2501,dats(1000) blquead Seq=2501,Ack=5001,Win=0 esperand Seq=2501,Ack=5001,Win=2000 Seq=5001,Ack=2501,dats(1000) Seq=2501,Ack=6001,Win= Supngams ahra que en el ejempl anterir se hubiera perdid la cuarta TPDU enviada de hst1 a hst2 (la que aparece en cursiva); en ese cas el hst-2 n habría enviad el ACK 5001, y el hst-1, al agtar el timeut crrespndiente a esa TPDU la habría reenviad; funcinand cn repetición selectiva la secuencia sería la siguiente: 5-7

8 Redes de Ordenadres HOST 1 HOST 2 Seq=1000,Win=4000 Seq=1500,Ack=1001,Win=4000 Seq=1001,Ack=1501,dats(1000) Seq=1501,Ack=2001,dats(1000) Seq=2001,Ack=2501,dats(1000) Seq=3001,Ack=2501,dats(1000) (perdida) Seq=4001,Ack=2501,dats(1000) Seq=2501,Ack=3001 Seq=3001,Ack=2501,dats(1000) (reenviada pr timeut) blquead Seq=2501,Ack=5001,Win=0 esperand Seq=2501,Ack=5001,Win=2000 Seq=5001,Ack=2501,dats(1000) Seq=2501,Ack=6001,Win=3000 En cas de funcinar cn retrces n las csas habrían sid ligeramente diferentes: HOST 1 HOST 2 Seq=1000, Win=4000 Seq=1500,Ack=1001, Win=4000 Seq=1001, Ack=1501,dats(1000) Seq=1501,Ack=2001,dats(1000) Seq=2001,Ack=2501,dats(1000) Seq=3001,Ack=2501,dats(1000) (perdida) Seq=4001,Ack=2501,dats(1000) (ignrada) Seq=2501,Ack=3001 Seq=3001,Ack=2501,dats(1000) (reenviada pr timeut) Seq=2501,Ack=4001 Seq=4001,Ack=2501,dats(1000) (reenviada pr timeut) blquead Seq=2501,Ack=5001,Win=0...esperand... Seq=2501,Ack=5001,Win=2000 Seq=5001,Ack=2501,dats(1000) Seq=2501,Ack=6001,Win=3000 En redes n rientadas a cnexión ls datagramas (y pr tant las TPDUs) pueden llegar desrdenads, pr l que el nivel de transprte debe estar preparad para recibir númers de secuencia desrdenads (siempre y cuand se encuentren dentr del rang crrespndiente a la ventana vigente en ese mment) Multiplexación En las redes públicas de cnmutación de paquetes (X.25, frame relay y ATM), que sn rientadas a cnexión, el usuari paga pr cada circuit virtual, l cual estimula a utilizar el mínim númer de circuits psible. Generalmente es el nivel de transprte el encargad en ests cass de multiplexar la diferentes cnexines slicitadas pr el nivel de aplicación en una única cnexión a nivel de red; dich en 5-8

9 El Nivel de Transprte en Internet terminlgía OSI el nivel de transprte presenta diferentes TSAPs sbre un únic NSAP. Est se cnce cm multiplexación hacia arriba, ya que vist en el mdel de capas supne que varias direccines del nivel de transprte cnfluyan en una única dirección del nivel de red. También en redes n rientadas a cnexión (IP ISO CLNP) el nivel de transprte suele cuparse de multiplexar el tráfic de las diferentes aplicacines y usuaris (cada aplicación puede estar siend utilizada pr varis usuaris) en una única dirección a nivel de red. Existen tras situacines en las que interesa hacer multiplexación en sentid puest. Supngams pr ejempl el cas de un servidr al que para mejrar su rendimient se le han instalad ds interfaces de red, pr ejempl ds cntrladres Ethernet; supngams que el servidr utiliza TCP/IP, y psee pr tant una dirección IP para cada interfaz. El servidr esta dedicad a una única aplicación, pr l que utiliza un únic puert. En este cas necesitams hacer multiplexación hacia abaj. En casines, debid a la frma cm funcinan ls prtcls cm se reparte la capacidad dispnible, la multiplexación hacia abaj es interesante inclus cuand hay una sla interfaz física cn la red; pr ejempl, si el prtcl a nivel de transprte n utiliza ventana deslizante sin parada y espera el crear varias cnexines a nivel de transprte para un mism usuari del nivel de aplicación permite aprvechar ls tiemps de espera que prduce el prtcl. También sería útil la multiplexación si el algritm de repart de recurss se basa en ls usuaris del nivel de transprte; presentand varias cnexines btendrems mejr rendimient (seguramente cn detriment de ls demás usuaris) Recuperación de caídas Ya hems vist el tip de medidas preventivas que se adptan para evitar que cuand una instancia del nivel de transprte en un hst cae y se levanta mas tarde n sea psible recuperar la cnexión previamente establecida, y haya que crear una nueva. Est es una medida de seguridad fundamental para evitar incnsistencias en la infrmación y access n autrizads. Otr prblema imprtante es que curre cuand cae td un hst, l cual prvca la caída simultánea del nivel de transprte y el nivel de aplicación. Supngams pr ejempl que un cliente está realizand una serie de actualizacines en una base de dats, cada una de ellas cntenida en una TPDU; a cada transacción el servidr respnde cn un ACK indicand que ha efectuad la peración crrespndiente. En un determinad mment el servidr cae, rearrancand a cntinuación; pdems cncluir que si el cliente ha recibid el ACK es que la actualización se ha efectuad, y si n n, per cm la actualización y el enví del ACK sn sucess cnsecutivs y n simultánes siempre currirá un primer y el tr después; cualquiera que sea el rden elegid siempre pdrá currir que el hst caiga entre ambs events, cn l que tendrems bien una actualización efectuada y n ntificada, una ntificación enviada al cliente de una actualización n realizada. Este tip de prblemas sl puede reslverse a nivel de aplicación mediante una psterir verificación de l que realmente ha currid. 5.3 LOS PROTOCOLOS DE TRANSPORTE DE LA INTERNET: TCP Y UDP Cm ya hems cmentad existen ds prtcls de transprte en la Internet: TCP es fiable, rientad a cnexión cn cntrl de fluj, y UDP es n fiable (sin cnfirmación) n rientad a cnexión y sin cntrl de fluj. La TPDU de TCP se denmina segment, y la de UDP mensaje también datagrama UDP. TCP prevé una cmunicación full dúplex punt a punt entre ds hsts, n hay sprte para tráfic multicast. En UDP la cmunicación es simplex (aunque bviamente un datagrama UDP puede ser respndid pr el receptr cn tr); en UDP es psible el tráfic multicast bradcast. El prtcl TCP es much más cmplej que UDP. 5-9

10 Redes de Ordenadres TCP (Transprt Cntrl Prtcl) Recrdems que el nivel de transprte debe frecer algún mecanism que permita distinguir a que aplicación van dirigids ls dats, l que hems denminad ls TSAPs. En TCP ls TSAPs se denminan prts puerts. En sentid estrict una cnexión entre ds entidades usuarias del nivel de transprte queda identificada pr ls TSAPs en ls que cnectan cada una (pdems pensar en el TSAP cm el cnectr telefónic, diríams entnces que una cnversación telefónica queda perfectamente especificada pr ls númers de teléfn de las ds rsetas dnde están enchufads ls aparats cn ls que se está habland). Recrdarems que un TSAP en Internet está especificad pr: Dirección dnde 'cnecta' el nivel de red: dirección IP de ls ds hsts Dirección dnde cnecta el nivel de transprte (camp prtcl del datagrama IP): nrmalmente TCP ya que UDP al ser n rientad a cnexión n puede establecer cnexines. Dirección dnde cnecta el nivel de aplicación: est es el puert. Dad que la cnexión en el nivel de transprte siempre se suele realizar cn el prtcl TCP este dat es innecesari y se suele mitir. Sin embarg en un mism hst un númer de prt puede ser utilizad simultáneamente pr una aplicación para UDP y pr tra para TCP; est n plantea ningún cnflict ya que sn TSAPs diferentes. Así pues, una cnexión de ds entidades usuarias del nivel de transprte se especifica pr la cmbinación: Dirección IP hst 1 + prt hst 1 + dirección IP hst 2 + prt hst 2 El prt es un númer enter entre 0 y Pr cnveni ls númers 0 a 1023 están reservads para el us de servicis estándar, pr l que se les denmina puerts bien cncids well-knwn prts. Cualquier númer pr encima de 1023 está dispnible para ser utilizad libremente pr ls usuaris. Ls valres vigentes de ls puerts bien cncids se pueden cnsultar pr ejempl en el web de la IANA (Internet Assigned Number Authrity) En la tabla 5.2 se recgen alguns de ls más habituales. Puert Aplicación Descripción 9 Discard Descarta tds ls dats recibids (para pruebas) 19 Chargen Intercambia cadenas de caracteres (para pruebas) 20 FTP-Data Transferencia de dats FTP 21 FTP Diálg en transferencia de fichers 23 TELNET Lgn remt 25 SMTP Crre electrónic 110 POP3 Servidr de crre 119 NNTP News Tabla Alguns ejempls de puerts 'bien cncids' de TCP El Tanenbaum, cm trs librs de text, dice (pag. 523 y 526) que ls puerts bien cncids sn ls que están pr debaj del 256; sin embarg el estándar establece que están reservads para este fin tds ls valres pr debaj de Para cmprender la relación entre ls puerts y las cnexines en TCP veams un ejempl cncret: supngams que cinc usuaris desde un hst de dirección IP inician una sesión de lgn remt (Telnet) hacia el hst de dirección ; cada un de ells ejecutará en su hst un prgrama telnet cliente que abrirá una cnexión cn el servidr Telnet (puert 23) en el tr; las cnexines establecidas pdrían ser pr ejempl: 5-10

11 El Nivel de Transprte en Internet Usuari 1: cn Usuari 2: cn Usuari 3: cn Usuari 4: cn Usuari 5: cn Aquí hems emplead la ntación dirección IP. Puert para identificar el scket 2 ; cada cnexión queda identificada de frma n ambigua pr ls ds sckets que cnecta. Obsérvese que la asignación de puerts para ls clientes se hace pr simple rden de llegada a partir del primer númer de puert n reservad. En el servidr tdas las cnexines utilizan el puert 23 (pues tdas acceden al mism prces, el servidr telnet); en cambi en el cliente cada usuari es un prces diferente y utiliza un puert distint. Cmplicand un pc más el ejempl anterir pdríams imaginar que el hst cliente estuviera 'multihmed', es decir que tuviera ds interfaces físicas (pr ejempl ds tarjetas LAN) y pr tant tuviera ds direccines IP; supngams que ls usuaris utilizan ambas interfaces alternativamente, en ese cas las cnexines pdrían ser: Usuari 1: cn Usuari 2: cn Usuari 3: cn Usuari 4: cn Usuari 5: cn Pr tr lad el hst cliente pdría simultáneamente a las sesines telnet enviar datagramas UDP al servidr. Aunque en este cas n se establece una cnexión (pues se trata de un servici CLNS) hay un puert de rigen y un de destin; pdría haber datagramas que tuvieran cm puert de rigen el 1024 en el hst y cm destin el 23 en ; est n causaría ninguna ambigüedad ya que el camp prtcl de la cabecera IP permitiría distinguir ambs tips de paquetes entregand cada un al servici crrespndiente del nivel de transprte en el hst de destin La cabecera de segment TCP La cabecera de un segment TCP tiene la estructura que se muestra en la tabla La denminación scket empleada para la cmbinación IP.puert es la misma que la de las APIs utilizadas en UNIX para acceder a ls servici TCP. 5-11

12 Redes de Ordenadres Camp Lngitud (bits) Puert rigen 16 Puert destin 16 Númer de secuencia 32 Númer de ACK 32 Lngitud de cabecera TCP 4 Reservad 4 CWR (Cngestin Windw Reduced) 1 ECE (ECN Ech) 1 URG (Urgent) 1 ACK (Acknwledgement) 1 PSH (Push) 1 RST (Reset) 1 SYN (Synchrnize) 1 FIN (Finish) 1 Tamañ de ventana 16 Checksum 16 Punter de dats urgentes 16 Opcines 0, 32, 64, Dats (65495 bytes) Tabla Estructura de la cabecera de un segment TCP Puert rigen y puert destin: identifican ls puerts que se van a utilizar en cada hst para cmunicar cn las aplicacines que intercambian dats. Númer de secuencia: indica el númer de secuencia que crrespnde en la cnexión al primer byte que se envía en el camp dats de ese segment. Númer de ACK: indica el númer de secuencia del primer byte del próxim segment que se espera recibir del tr lad. Lngitud de cabecera TCP: especifica la lngitud en palabras de 32 bits, excluid el camp dats (el camp pcines hace que dicha lngitud pueda variar). A cntinuación hay 4 bits n utilizads, seguids pr ch flags indicadres de un bit de lngitud cada un: CWR: Cngestin Windw Reduced. Tiene que ver cn el cntrl de cngestión de IP que n describirems aquí ECE: ECN Ech (ECN=Explicit Cngestin Ntificatin). Tiene que ver cn el cntrl de cngestión de IP que n describirems aquí. URG (urgent): sirve para indicar que el segment cntiene dats urgentes; en ese cas el camp punter de dats urgentes cntiene la dirección dnde terminan ésts. ACK (acknwledgement): indica que en este segment el camp Númer de ACK tiene el significad habitual (númer del próxim byte que se espera recibir), de l cntrari carece de significad. En la práctica el bit ACK esta a 1 siempre, except en el primer segment enviad pr el hst que inicia la cnexión. PSH (push): indica que el segment cntiene dats PUSHed. Est significa que deben ser enviads rápidamente a la aplicación crrespndiente, sin esperar a acumular varis segments. RST (reset): se usa para indicar que se debe abrtar una cnexión prque se ha detectad un errr de cualquier tip; pr ejempl una terminación unilateral de una cnexión que se ha 5-12

13 El Nivel de Transprte en Internet recibid un segment cn un valr inadecuad del númer de secuencia númer de ACK, psiblemente prducid pr un duplicad retrasad de un intent de cnexión. SYN (synchrnize): este bit indica que se está estableciend la cnexión y está puest sól en el primer segment enviad pr cada un de ls ds hsts en el inici de la cnexión. FIN (finish): indica que n se tienen más dats que enviar y que se quiere cerrar la cnexión. Para que una cnexión se cierre de manera nrmal cada hst ha de enviar un segment cn el bit FIN puest. Tamañ de ventana: indica la cantidad de bytes que se está dispuest a aceptar del tr lad en cada mment. Se supne que se garantiza una cantidad suficiente de espaci en buffers. Mediante este parámetr el receptr establece un cntrl de fluj sbre el caudal de dats que puede enviar el emisr. Checksum: sirve para detectar errres en el segment recibid; ests pdrían ser debids a errres de transmisión n detectads, a falls en ls equips (pr ejempl en ls ruters) a prblemas en el sftware (pr ejempl reensamblad incrrect de fragments). Recrdems que el datagrama IP cntenía un checksum, per aquel sl cmprendía la infrmación de cabecera y además ese checksum desaparece en IPv6. El algritm utilizad en TCP es el mism que el de IP: sumar tds ls camps de 16 bits usand aritmética de cmplement a 1 y calcular el cmplement a 1 del resultad, per en este cas el checksum se hace sbre td el segment, incluids ls dats, n sól sbre la infrmación de cabecera. Para el cálcul del checksum se antepne al segment una pseudcabecera que incluye la dirección IP de rigen y destin, el prtcl de transprte utilizad (TCP en este cas) y la lngitud del segment. La pseudcabecera (así denminada prque sól se utiliza en el cálcul, per n frma parte del segment) permite a TCP cmprbar que n ha habid errres en la transmisión a nivel IP (detectar pr ejempl cuand un segment ha sid entregad al hst equivcad). Punter de dats urgentes: indica el final de ésts, ya que el segment pdría cntener dats n urgentes. TCP n marca el principi de ls dats urgentes, es respnsabilidad de la aplicación averiguarl. El camp pcines habilita un mecanism pr el cual es psible incluir extensines al prtcl. Entre las más interesantes se encuentran las siguientes: Tamañ máxim de segment Us de repetición selectiva (en vez de retrces n) Us de NAK (acuse de recib negativ en cas de n recepción de un segment) Us de ventana mayr de 64 Kbytes mediante el emple de un factr de escala De las pcines hablarems más adelante Tamañ de segment y fragmentación TCP divide ( agrupa) ls mensajes recibids del nivel de aplicación en TPDUs denminadas segments; en el mment de establecer la cnexión cada hst infrma al tr del máxim tamañ de segment que está dispuest a aceptar; este tamañ deberá ser cm mínim de 536 bytes, crrespndiente nrmalmente a un datagrama IP de 576 bytes mens 20 bytes de cabecera IP y 20 de cabecera TCP (la lngitud de segment se refiere a la parte de dats de TCP). Un segment TCP siempre se transprta en un datagrama IP. Cuand la red ha de fragmentar en algún punt un datagrama IP el datagrama sigue fragmentad el rest del viaje hasta el hst de destin; una vez allí el nivel de red se cupa de juntar tds ls fragments en su buffer y recnstruir el datagrama riginal, del cual extrae entnces el segment riginal y l pasa a TCP; si un de ls fragments se pierde el nivel de red del receptr será incapaz de recnstruir el datagrama riginal, y pr tant descartará, una vez expirad el TTL, tds ls fragments recibids y n pasará ninguna parte de ese segment al nivel de transprte; TCP agtará el timer, detectará el segment faltante y pedirá retransmisión al emisr. Pr tant cuand un fragment de un datagrama se pierde tds ls fragments se retransmiten nuevamente; 5-13

14 Redes de Ordenadres el prces se repite hasta que tds ls fragments cnsiguen llegar crrectamente al receptr. También puede suceder que la fragmentación se prduzca ya en el hst emisr del segment, en cuy cas realizará fragmentad td el trayect. El Tanenbaum tercera edición dice (pag. 525): Un segment que es demasiad grande para una red pr la que debe transitar puede ser dividid en múltiples segments pr un ruter. Cada nuev segment btiene su prpia cabecera TCP e IP, cn l que la fragmentación pr ruters aumenta el verhead ttal (prque cada segment adicinal añade 40 bytes de infrmación de cabecera extra). El párraf anterir cntiene varis errres que es precis aclarar. En primer lugar ls ruters n analizan ni prcesan segments, sin paquetes datagramas; pr tant tampc fragmentan segments, sin paquetes; cada paquete-fragment recibe una cabecera IP prpia, per n una nueva cabecera TCP; mas aun, el nivel de red ni siquiera analiza al fragmentar un paquete si l que cntiene es un segment TCP, un datagrama UDP cualquier tra csa (pdría ser un mensaje ICMP, pr ejempl). Pr tant el verhead añadid pr la fragmentación n es de 40 bytes pr fragment (20 de la cabecera IP y 20 de la TCP), sin de 20 (mas el crrespndiente a la infrmación de cntrl de las tramas adicinales que se prduzcan a nivel de enlace). El nivel de transprte n se ve en abslut invlucrad en el prces de fragmentación y reensamblad de ls paquetes, que sól afecta al nivel de red en el ruter ( hst) que realiza la fragmentación y en el hst al que va destinad el datagrama, que es el que efectúa el reensamblad. Afrtunadamente el párraf erróne ha sid suprimid en la cuarta edición del libr (pág. 536). En casines el hst emisr emplea la técnica de descubrimient de la MTU del trayect Path MTU discvery (MTU=Maximum Transfer Unit) para averiguar el tamañ de datagrama máxim que puede utilizar, cn l que puede generar en rigen ls datagramas de tamañ aprpiad evitand así la fragmentación en ruta. Para ell el hst emisr envía un datagrama del tamañ máxim que pretende utilizar cn el bit DF (Dn't Fragment) puest; si el datagrama llega a su destin deducirá que td el trayect sprta esa MTU; en cas cntrari el hst emisr recibirá un mensaje ICMP Destinatin Unreachable generad pr el ruter dnde se prduzca el rechaz. En muchas implementacines el mensaje ICMP de rechaz vendrá acmpañad de una indicación del tamañ de MTU máxim que se habría tlerad en esa red, para facilitar así al hst emisr la labr de tante. Cuand est n curra el hst emisr tendrá que deducir ese tamañ máxim a partir de una búsqueda binaria, hasta dar cn el tamañ adecuad y reintentará cn un datagrama más pequeñ, hasta cnseguir que llegue. En IPv6 la técnica de Path MTU discvery es bligatria, ya que la fragmentación en ruta n está permitida Fluj de dats en TCP Ls segments, al viajar en datagramas IP, pueden perderse, llegar desrdenads duplicads. Es respnsabilidad de TCP reslver tds ests prblemas y generar un fluj de bits fiable para el nivel de aplicación. Cada segment es acmdad el sl en un datagrama, si bien lueg puede tener que ser fragmentad para su enví, cm hems vist en el apartad anterir. Nunca se cmbinan en un segment dats pertenecientes a ds cnexines TCP diferentes. Las aplicacines que cmunican haciend us de ls servicis que frece TCP n tienen cnciencia de la existencia de segments datagramas. Desde su punt de vista el servici de transprte que frece TCP es de un fluj cntinu de bits (stream), cm si hubiera un hil físic que las cmunicara. Si la aplicación emisra desea que la infrmación sea transmitida a la aplicación receptra en mensajes discrets deberá incluir ls delimitadres adecuads, ya que n hay ninguna garantía de que TCP genere un segment pr cada escritura que la aplicación efectúe en su buffer. TCP puede tmarse la libertad de agrupar varias escrituras de la aplicación en su buffer en un mism segment, trcear una escritura en varis dependiend del tamañ de ésta, del MSS elegid y de las circunstancias. Pr ejempl el TCP emisr pdría decidir retener varis mensajes recibids de la aplicación si ésts sn muy pequeñs para agruparls y crear segments mayres usand así la red de manera más eficiente. Para pder enviar dats priritaris y respnder ante situacines urgentes existen ds mecanisms extrardinaris pr ls que las aplicacines pueden indicar a TCP su dese de enviar rápidamente dats al tr extrem. 5-14

15 El Nivel de Transprte en Internet Un de ells es el denminad indicadr PUSH. Cuand una aplicación desea que ls dats entregads a TCP salgan enseguida, sin esperar más dats de la aplicación, l indica pniend a 1 el indicadr PUSH; este indicadr se utiliza pr ejempl cuand en una transferencia FTP se envía el últim segment, cuand en una sesión telnet el usuari pulsa la tecla return 3 ; en ests cass si n se utilizara PUSH se crrería el riesg de que TCP se quedara esperand mas dats de la aplicación para cnstruir un segment mayr. El tr mecanism de enví rápid de dats se denmina dats urgentes, y cm su nmbre indica es aún más expeditiv que el anterir. Pr ejempl en una sesión telnet se utiliza este prcedimient para enviar ls caracteres DEL, CTRL-C, cuand se pulsa la tecla BREAK ATTN. En ests cass n sl se desea enviar cuant antes ls caracteres recién tecleads, sin que se quiere que ests pasen pr delante de cualesquiera trs que hubiera pendientes de enviar a la aplicación y se le entreguen a ésta sin esperar a que ls slicite (pr ejempl para abrtar una ejecución en marcha cuand ésta n espera leer dats). La existencia de dats Pushed y de dats urgentes se indica mediante ls crrespndientes bits indicadres flags en la cabecera TCP. En el cas de dats urgentes se indica además el punt en el segment dnde terminan ésts; es respnsabilidad de la aplicación averiguar en que punt del segment empiezan ls dats urgentes Intercambi de infrmación en TCP El intercambi de segments en TCP se desarrlla de acuerd cn un prtcl de ventana deslizante cn un númer de secuencia de 32 bits. El númer de secuencia cuenta bytes transmitids, pr l que la secuencia se reinicia cada 4 GB (equivalentes a 4,3 minuts en una línea SDH de 155 Mb/s, supniend que tda la capacidad útil de la línea se utilizara para esa cnexión TCP). TCP utiliza ACK piggybacked, pr l que en la cabecera de cada segment hay prevists ds camps de 32 bits, un para el númer de secuencia y tr para el númer de ACK. El camp númer de secuencia indica el númer del primer byte transmitid dentr de ese segment. El camp ACK indica el númer del primer byte que se espera recibir en el siguiente segment ( sea se sigue el estil del camp 'next' en HDLC). En la práctica el ACK piggybacked raramente se aprvecha ya que la mayría de las aplicacines generan tráfic muy asimétric; nrmalmente un de ls ds TCP se ve ligad a enviar muchs segments vacís cn el únic fin de infrmar al emisr que ls dats han sid recibids. El mecanism nrmal de funcinamient de TCP es retrces n, aunque también puede utilizarse repetición selectiva si las ds entidades participantes l sprtan y l negcian al iniciar la cnexión. Cada segment enviad incluye un tamañ de ventana en el que el receptr anuncia la cantidad de dats que está dispuest a recibir. De esta frma el receptr puede ejercer cntrl de fluj sbre el emisr. El tamañ de ventana es un camp de 16 bits, pr l que el valr máxim es de 64 Kbytes Gestión de cnexión TCP El mecanism utilizad en TCP para establecer una cnexión es el de salud a tres vías. Un prces nrmal sería el siguiente: TCP en HOST 1 TCP en HOST 2 3 En realidad esta afirmación sl es crrecta cuand se utiliza telnet cn ec lcal; en la mayría de ls cass el telnet utiliza ec remt, es decir el telnet remt (servidr) ha de prcesar l que se teclea carácter a carácter, realizand la representación en pantalla si prcede. Cuand se funcina cn ec remt el telnet cliente pne el bit PUSH para cada carácter que se teclea. Aunque es much mens eficiente que el ec lcal el ec remt es hy en dia la frma de funcinamient más habitual, ya que muchs editres de pantalla cmpleta (el vi pr ejempl) necesitan ec remt para funcinar crrectamente. 5-15

16 Redes de Ordenadres Envía SYN (SEQ=x) Recibe SYN cn ACK Envía (SEQ=x+1,ACK=y+1) Recibe SYN Infrma a la aplicación La aplicación acepta la cnexión Envía SYN (SEQ=y, ACK=x+1) Recibe ACK En el primer segment el hst 1 indica al hst 2 que desea establecer una cnexión (bit SYN puest) y le infrma del númer de secuencia que ha elegid (x); el hst 2 le respnde cn tr segment en el que acepta la cnexión (bit SYN puest) y le indica el númer de secuencia que él ha elegid para las transmisines en el sentid cntrari (y); además le acusa recib de su númer de secuencia al indicarle en el ACK que el próxim byte que espera recibir de él es x + 1. Hst 1 respnde cn un tercer mensaje en el que acusa recib del númer de secuencia de hst 2. En este ejempl hems supuest el cas más simple de establecimient de una cnexión. El Hst 1 pdría incluír ya en ess primers segments dats dirigids a la aplicación; est está permitid siempre y cuand ls dats sean retenids pr el TCP receptr hasta que la aplicación crrespndiente decida si acepta la cnexión. Una vez establecida la cnexión puede empezar el intercambi de infrmación; cada lad puede enviar dats al tr de frma independiente, sin necesidad de que el tr le crrespnda cn más dats. Nrmalmente si fluyen dats en ambs sentids ls ACK irán incluids ( piggybacked ) en ls segments de vuelta, per si el tráfic discurre predminantemente en un sentid (cm es l nrmal) se prducirán segments vacís cn el únic fin de acusar recib de ls envís. Ls valres de SEQ y ACK se van incrementand a medida que prgresa la transmisión. Ls valres de ventana anunciads pr cada hst permiten al tr cncer la dispnibilidad que tiene de recibir dats. El númer de secuencia inicial es elegid pr cada hst de frma pseudaleatria. El RFC 793, que describe el estándar TCP, recmiendan utilizar para est un cntadr que se incremente en una unidad cada 4 s, aprximadamente; est se puede cnseguir fácilmente basándse en algún relj del sistema. Cn este algritm el númer de secuencia se da la vuelta cada 4 hras 46 minuts, aprximadamente. Esta frma de elegir el númer de secuencia inicial reduce la prbabilidad de que si un de ls ds hsts cae y rearranca pueda cincidir el númer de secuencia nuev cn el viej, l cual pdría prducir que se tmaran cm válids segments duplicads retrasads, que el TCP del tr lad cntinuara dialgand cn el nuev prces cm si fuera el viej. Para aumentar aún más la seguridad el estándar recmienda que se garantice una separación mínima en el timep de 2 minuts desde que cae un TCP hasta que se levanta el nuev, para asegurar de esa frma que n pueden aparecer en el TCP de destin duplicads retrasads que puedan mezclarse en la nueva cnexión (2 minuts es un valr máxim bastante nrmal del parámetr TTL tiemp de vida, que fija el tiemp máxim que un datagrama puede estar pululand pr la red antes de desaparecer). Para cmprender hasta que punt es imprtante la n cincidencia de númers de secuencia entre sesines imaginems la siguiente situación: ds usuaris X e Y mantienen ambs una cnexión telnet desde la máquina a la máquina ; en un primer mment sus cnexines sn: Usuari X: cn Usuari Y cn y 1025 sn ls puerts utilizads pr ls prcess clientes telnet en y 23 es el puert utilizad pr el prces servidr telnet en Supngams ahra que el hst (cliente) cae y se levanta a cntinuación, y que ls ds usuaris reanudan sus respectivas sesines telnet (que han quedad medi abiertas en el servidr) per ahra se cnecta Y antes que X. Las cnexines antiguas han desaparecid, y dad que ls puerts se asignan pr rden de llegada ahra se asignarían en rden invers: Usuari X: cn

17 El Nivel de Transprte en Internet Usuari Y cn En cndicines nrmales ls clientes telnet intentarán abrir nuevas cnexines, cn l que el servidr cerrará las antiguas. Per si de alguna frma ls clientes telnet entraran en las cnexines viejas del servidr sin cerrarlas cada usuari entraría directamente en la sesión del tr sin necesidad de identificarse cn la cntraseña crrespndiente, l cual evidentemente n es aceptable. La utilización de númers de secuencia grandes y aleatris suministra un ciert nivel de seguridad ante estas situacines. Para terminar una cnexión TCP se utiliza nrmalmente el prcedimient simétric del salud a tres vías, en el cual cada lad cierra su parte de frma independiente cm si se tratara de una cnexión simplex. El intercambi de mensajes típic es el siguiente: HOST 1 HOST 2 La aplicación cierra la cnexión Envía FIN (SEQ=x,ACK=y) Recibe ACK Recibe FIN cn ACK Envía (SEQ=x+1,ACK=y+1) Recibe FIN Envía (SEQ=y,ACK=x+1) Infrma a la aplicación La aplicación cierra la cnexión Envía FIN (SEQ=y, ACK=x+1) Recibe ACK Estads de TCP El sftware ( prces) TCP de un hst puede mantener en un mment dad múltiples cnexines simultáneas cn hmólgs suys en trs hsts. Para cada una de esas cnexines TCP cnserva en td mment infrmación del estad en que se encuentra (pr ejempl cnexión establecida, pendiente de establecer n cnexión). La secuencia de estads que se suceden en el establecimient de una cnexión TCP en un servidr aparece en la tabla 5.4, mientras que la tabla 5.5 ns muestra la secuencia equivalente en el cas de un cliente. Estad del servidr Event Descripción CLOSED LISTEN SYN-RECEIVED ESTABLISHED La aplicación en el servidr hace una apertura pasiva El TCP del servidr recibe un SYN, devuelve un SYN/ACK El TCP del servidr recibe un ACK Estad (fictici) en que se encuentra una cnexión antes de existir El servidr espera una cnexión del cliente El servidr espera un ACK El ACK ha sid recibid y la cnexión se ha establecid Tabla Secuencia de estads que curren en el establecimient de una cnexión TCP en un servidr 5-17

18 Redes de Ordenadres Estad del cliente Event Descripción CLOSED SYN-SENT ESTABLISHED La aplicación cliente slicita una cnexión. El TCP del cliente envía un SYN El TCP cliente recibe SYN/ACK y envía ACK Estad (fictici) en que se encuentra una cnexión antes de existir El TCP cliente ha enviad un SYN al servidr La transferencia de dats puede cmenzar Tabla Secuencia de estads que curren en el establecimient de una cnexión TCP en un cliente Una vez en el estad ESTABLISHED ambs TCP permanecerán así hasta que se inicie el prcedimient de cierre de la cnexión. En cndicines nrmales cualquiera de ls ds prcess puede iniciar la descnexión enviand un segment cn el bit FIN puest; la secuencia de estads en el TCP que inicia la descnexión es la que se muestra en la tabla 5.6, mientras que la tabla 5.7 muestra la secuencia de estads en el TCP que es invitad a cerrar la cnexión. Estad del TCP que cierra la cnexión ESTABLISHED FIN-WAIT-1 FIN-WAIT-2 TIME-WAIT CLOSED Event La aplicación lcal slicita cerrar TCP envía FIN/ACK TCP recibe un ACK TCP recibe FIN/ACK. Envía ACK Descripción El TCP lcal está esperand respuesta del tr lad. En este punt aún pueden llegar dats válids. El TCP lcal ha recibid un ACK del tr lad, per n un FIN. Se siguen aceptand ls dats que pudieran llegar del tr lad La cnexión se mantiene en el limb ante la psibilidad de recibir aun dats duplicads un FIN duplicad. El tiemp de espera es igual al dble del tiemp de vida de un segment Se brra tda la infrmación relativa a esta cnexión. Tabla Secuencia de estads que curren en el cierre de una cnexión TCP en el hst que inicia la descnexión 5-18

19 El Nivel de Transprte en Internet Estad del TCP 'invitad' a cerrar ESTABLISHED CLOSE-WAIT LAST-ACK CLOSED Event TCP recibe FIN/ACK TCP envía un ACK La aplicación lcal cierra la cnexión TCP envía FIN/ACK TCP recibe un ACK Descripción Ha llegad un FIN TCP espera a que su aplicación cierre la cnexión. La aplicación pdría aún enviar más dats TCP Está esperand el ACK final Se brra tda la infrmación sbre la cnexión Tabla Secuencia de estads que curren en el cierre de una cnexión TCP en el hst que es invitad a terminar la cnexión Ls nmbres utilizads en estas tablas crrespnden cn ls empleads en el RFC 793, y en muchas implementacines de TCP. El cmand netstat -an, que permite examinar el estad de las cnexines existentes en un hst UNIX, utiliza esta misma nmenclatura Cnexines medi abiertas y timer de keepalive En principi el estándar TCP n establece el requerimient de que una cnexión TCP tenga un tráfic mínim para permanecer establecida. Cabría pensar en la psibilidad de que una cnexión TCP estuviera abierta durante días sin transmitir ni un sl segment, y en principi n habría razón para terminarla. En la práctica est supne que si en una cnexión desaparece un de ls ds TCP el tr pdría quedar eternamente esperand dándse l que se denmina una cnexión medi abierta. Si td funcinara cm es debid las cnexines medi abiertas nunca deberían currir, puest que cada TCP debería cerrar rdenadamente sus cnexines. Per a veces ls prcess TCP terminan de frma abrupta, n dand tiemp al cierre rdenad de sus cnexines; est es especialmente cmún en tiemps recientes a partir de la prliferación de ls rdenadres persnales cnectads directamente a Internet en ls que el usuari cn frecuencia n termina ls prcess de la frma crrecta, descnecta de la red su rdenadr dejand las cnexines medi abiertas en el tr lad. Esas cnexines medi abiertas cnsumen recurss inútilmente, pr l que es cnveniente establecer algún mecanism pr el cual un TCP pueda sndear periódicamente sus cnexines para cmprbar que el tr lad aún está perativ; si el TCP de una cnexión deja de respnder durante un númer determinad de mensajes de snde se cnsidera que esa cnexión está medi abierta y se prcede a cerrarla de la frma mas civilizada psible, liberand así ls recurss que está utilizand. Ls mensajes de snde sn l que se cnce cm mensajes keep-alive y la peridicidad cn la que se prducen viene fijada pr el parámetr denminad timer de keepalive. Ls mensajes de keepalive fuern añadids a psteriri al TCP, y se implementan de una frma muy sencilla: el TCP envía un segment que repite el últim byte enviad; el TCP receptr n pasará este byte a la aplicación, per debe generar un segment de ACK; cn est el emisr ya sabe que su interlcutr está perativ. Ls keepalive se suelen implementar en servidres, que sn ls que mas sufren el prblema de las cnexines medi abiertas. Pr la frma cm se implementan ls mensajes de keepalive funcinan aun cuand el TCP remt n implemente keepalive, ya que se emplea una característica que frma parte del funcinamient estándar de TCP. El mecansim de keepalive n debe ser tan estrict que una pérdida mmentánea de cenctividad prduzca el cierre de una cnexión TCP, ya que en una red cm Internet es fundamental permitir que las csas funcinen aun cuand haya falls mmentánes en el nivel de red, que sabems que n es fiable. El timer de keepalive puede tener valres en trn a ls ds minuts; ls tiemps recmendads para crtar una cnexión TCP inactiva pueden llegar a ser de hasta ds hras. 5-19

20 Redes de Ordenadres Plítica de transmisión de TCP Cm ya hems cmentad, el receptr en una transmisión TCP anuncia regularmente el tamañ de ventana que tiene dispnible para que el emisr sepa cuants dats más puede enviarle. Cuand un receptr tiene llen su buffer anuncia una ventana de 0 bytes, cn l que el emisr queda blquead hasta nueva rden. Existen ds circunstancias en las que cn ventana cer (ventana cerrada) el emisr puede enviar dats. Una es cuand se presentan dats urgentes; ests siempre deben ser aceptads pr el receptr, ya que se supne que n pueden esperar. La tra excepción es que el emisr puede siempre enviar un segment de un byte de dats, para frzar al receptr a devlver un ACK y así cmprbar cual es la situación; est evita situacines de blque que de tr md pdrían prducirse pr la pérdida de segments ACK en la red. La peridicidad cn la que el emisr tantea al receptr cn segments de un byte para cmprbar que su ventana sigue cerrada se fija cn el parámetr cncid cm timer de persistencia. Salv pr l requerid en el bit PUSH en dats urgentes, ls emisres TCP pueden rganizarse ls envís cm mejr les cnvenga. TCP pdría pr ejempl decidir agrupar la infrmación que recibe de la aplicación para enviar segments mas grandes y así reducir el verhead de prces y de cabeceras que supne el enví de segments pequeñs. Inclus el us del bit PUSH n garantiza la inmediata expedición de un segment, en situacines de veradera cngestión el TCP puede decidir ignrar el bit Push y agrupar varis mensajes de la aplicación en el mism segment Prblemas de paquetes pequeñs Algritm de Nagle Un cas extrem de baja eficiencia se prduce cuand la aplicación en el lad del emisr genera un byte de dats cada vez; imaginems pr ejempl l que curre cuand se efectúa una cnexión telnet mediante una emulación de terminal ANSI (VT100 similar); muchs prgramas, cm pr ejempl el editr vi de UNIX, necesitan para funcinar crrectamente que el hst remt prcese cada carácter que se teclea, pr l que es precis utilizar el md de ec remt mediante el cual el hst remt se encarga de representar en pantalla cada carácter que se teclea. En estas cndicines pr cada tecla pulsada la aplicación envía a TCP ls caracteres un a un; en principi TCP debería enviar cada carácter en un segment cnteniend 20 bytes de cabecera al cual el nivel de red añadiría 20 de la cabecera IP; ese segment TCP recibe a cntinuación su crrespndiente segment vací (es decir sin dats) cn el ACK del anterir. Cm la representación en pantalla en el hst lcal se realiza a través del hst remt instantes más tarde la aplicación del sistema remt (el servidr telnet) respnde cn el ec del carácter pulsad, que es de nuev un datagrama IP de 41 bytes, a l cual el hst cliente respnde cn tr datagrama IP de 40 bytes que cntiene tr segment ACK vací; en ttal se transfieren 162 bytes para ds caracteres transmitids, l cual da una eficiencia del 1,2% (2/162) (y aquí n hems cnsiderad la infrmación de cntrl del nivel de enlace, tramas Ethernet pr ejempl, que añadiría aún más verhead). Para evitar estas situacines la mayría de las implementacines de TCP fijan un timeut de 500 mseg antes de enviar un ACK vací; si en ese tiemp se genera algún tráfic de vuelta el ACK puede viajar piggybacked en él; pr ejempl en nuestr cas salv que el hst estuviera muy cargad la aplicación telnet respndería antes de 500 mseg y el ACK pdría viajar en el mism segment que lleva el carácter de vuelta; de esta frma la eficiencia mejra ya que se suprime un ACK; la eficiencia sería entnces del 1,6 % (2/122). Para mejrar aún más la eficiencia en estas situacines se utiliza l que se cnce cm el algritm de Nagle. La idea es muy simple: cuand el tráfic de la aplicación llega al TCP en bytes un pr un se envía el primer en un segment y se retienen ls demás hasta recibir el ACK crrespndiente al byte enviad; una vez recibid el ACK se envía un segment cn tds ls bytes que hubiera pendientes y se empieza a acumular de nuev hasta recibir el siguiente ACK. También se envía un segment si el númer de caracteres acumulads en el buffer es igual a la mitad de la ventana, al máxim tamañ del segment. 5-20