Anda di halaman 1dari 7

CAPTULO 2 PROTOCOLO DE CONTROL DE TRANSPORTE TCP

2.1 INTRODUCCIN.
El Protocolo de Control de Transporte (TCP, por sus siglas en ingls) [1] es un protocolo usado en la Capa de Transporte; y creado como parte del conjunto de protocolos TCP/IP. Est pensado para ser utilizado como un protocolo del tipo fiable, usado en redes de comunicacin de computadoras por intercambio de paquetes, y en un sistema interconectado de tales redes.

2.2 DEFINICIN DE FUNCIONES.


El propsito principal de TCP consiste en proporcionar un servicio de conexin fiable y seguro entre pares de procesos. Para proporcionar este servicio el sistema de comunicacin requiere de mecanismos en las siguientes reas: a) Transferencia bsica de datos b) Fiabilidad c) Control de flujo d) Multiplexamiento e) Conexiones f) Prioridad y seguridad

2.2.1 Transferencia bsica de datos.


TCP debe ser capaz de transferir un flujo continuo de datos en cada sentido entre sus usuarios. Los datos que llegan desde el nivel de aplicacin son empaquetados en una unidad funcional denominada segmento. Estos segmentos son transmitidos a travs del protocolo de nivel de internet. En general, el protocolo TCP deciden cundo bloquear y enviar datos segn su propia conveniencia.

2.2.2 Fiabilidad.
El mdulo TCP debe poder recuperar los datos que se corrompan, pierdan, dupliquen, o se entreguen desordenados por el sistema de comunicacin del nivel de internet. Esto se consigue asignando un nmero de secuencia a cada segmento transmitido, y exigiendo un acuse de recibo al mdulo TCP receptor. Si no se recibe la confirmacin de la entrega dentro de un cierto plazo de expiracin prefijado, los datos se

retransmiten. En el receptor, se utilizan los nmeros de secuencia para ordenar correctamente los segmentos que puedan haber llegado desordenados y para eliminar los segmentos duplicados. La corrupcin de datos se maneja aadiendo un campo de suma de control (checksum) a cada segmento transmitido. Los segmentos recibidos son comprobados en el receptor, descartndose los segmentos con errores binarios, y pidiendo su retransmisin.

2.2.3 Control de Flujo.


TCP proporciona al receptor un medio para controlar la cantidad de datos enviados por el emisor. Esto se consigue devolviendo un valor de "ventana" con cada segmento recibido, indicando el rango de nmeros de secuencia aceptables ms all del ltimo segmento recibido con xito. La ventana indica el nmero de octetos que se permite que el emisor transmita antes de que reciba el siguiente permiso.

2.2.4 Multiplexacin.
Para permitir que muchos procesos dentro de un nico host utilicen simultneamente las posibilidades de comunicacin del protocolo, este identifica los flujos de datos entre la Capa de Transporte y de aplicacin segn el puerto de servicio (SAP, Service Access Point) usado por la aplicacin. De igual forma, el SAP usado por el nivel host-a-red (direccin IP), identifica al host dentro de la red. A esta dupla de SAPs (puerto y direccin IP) se le denomina socket1. Un socket puede ser usado por ms de una conexin, permitiendo la multiplexacin de datos entre el nivel de red/internet y la Capa de Transporte. Las conexiones entre host son realizadas por los socket de emisor y de destino, definindose esta es forma nica por la cuaterna socket inicio/socket destino. La fiabilidad y los mecanismos de control de flujo descritos anteriormente exigen que los mdulos de TCP inicialicen y mantengan una informacin de estado para cada flujo de datos. La combinacin de esta informacin, incluyendo las direcciones de los conectores, los nmeros de secuencia y los tamaos de las ventanas, se denomina una conexin. Cada conexin queda especificada de forma nica por un par de sockets que corresponden a las entidades en comunicacin. Tcnicamente, se debera usar tambin el SAP entre el nivel de transporte y el nivel de internet. Este SAP se denomina campo del protocolo, y sirve para identificar el protocolo usado en el nivel de red. Corresponde a un byte dentro de la cabecera del paquete IP. Pero como por definicin UDP no establece conexiones, se asume tcitamente que todas las conexiones usan el protocolo TCP, por lo que ste valor se omite de la definicin del socket.
1

Cuando dos host desean comunicarse, sus protocolos TCP deben establecer primero una conexin (inicializar la informacin de estado en cada lado). Cuando la comunicacin se ha completado, la conexin se termina o cierra con la intencin de liberar recursos para otros usos. Como las conexiones tienen que establecerse entre hosts no fiables y sobre un sistema de comunicacin no fiable a nivel de internet, se utiliza un mecanismo de acuerdo que usa nmeros de secuencia basados en tiempos de reloj para evitar una inicializacin errnea de las conexiones.

2.2.5 Prioridad y seguridad


Las aplicaciones usuarias de TCP pueden indicar el nivel de seguridad y prioridad de su comunicacin. sta informacin se traspasa al mdulo TCP y se ve reflejada en la cabecera TCP, donde se emplean diferentes grupos de bytes como banderas tanto para los host en comunicacin como para los host intermedios. Se emplean valores por defecto cuando estas caractersticas no se necesiten.

2.3 DESCRIPCIN FUNCIONAL. 2.3.1 Segmentacin de datos.


El protocolo TCP divide los datos recibidos desde nivel de aplicacin en unidades denominadas segmentos. Los segmentos se componen de una cabecera de 24 bytes, y de una zona de carga til de largo variable. La cabecera del mdulo son agrupaciones de bytes que tienen informacin de las entidades que establecen la comunicacin, el estado actual de la conexin, y los datos transportados en la zona de carga. La zona de carga es donde los datos a transportar se almacenan. Su tamao es variable, y depende de la capacidad de los host de manejar diferentes tamaos de segmentos.

2.3.2 Numeracin de los segmentos.


Cada segmento a enviar por una conexin es numerado de forma correlativa. Para cada conexin el mdulo TCP inicia la secuencia con un nmero diferente, elegido de forma aleatoria, tomando como referencia su reloj interno. El nmero de secuencia de un segmento es transportado en la cabecera del segmento TCP. Los nmeros de secuencia permiten al protocolo TCP intercambiar informacin respecto del arribo de segmentos. La cabecera de cada segmento TCP tiene un campo donde se inserta el nmero de segmento transportado, y un campo donde

indica el nmero de secuencia del ltimo segmento recibido. De esta manera, el protocolo TCP informa al transmisor de la llegada correcta de los segmentos. La confirmacin as obtenida se denomina ACK.

2.3.3 Tiempo de espera para retrasmisin (RTO).


Al momento de enviar un segmento, el protocolo TCP inicia un reloj con una cuenta decreciente. Al valor de este reloj se le denomina Retransmit Timeout. Indica el tiempo que el protocolo TCP esperar para recibir el ACK del segmento. Si no se recibe el ACK antes que el tiempo se acabe, o se recibe despus, el mdulo asume que el segmento se ha perdido en la red y debe ser retransmitido.

2.3.4 Transporte de los segmentos sobe un paquete IP.


Los segmentos son traspasados al nivel de internet, donde son encapsulados en un paquete IP para su viaje por la red. Por cada segmento se crea un paquete IP diferente, ya que dentro de cada paquete IP slo pueden existir datos de un segmento TCP. En ningn caso viajar en un mismo paquete IP ms de un segmento. Tampoco se combinan en un segmento datos provenientes de dos conexiones TCP diferentes. Al momento de establecer la conexin, cada host informa al otro del mximo tamao de segmento que est dispuesto a aceptar. El protocolo TCP tratar de armar segmentos de mximo tamao, para una mejor utilizacin de la red. La informacin del mximo segmento permitido slo es vlida para los host en conexin y no para los nodos intermedios. Por tanto, puede ocurrir que en algn sector de red por la que pasan los paquetes no se acepten estos valores, fragmentado los paquetes IP por los nodos intermedios. La fragmentacin debe y es invisible para los host finales, y no altera el valor del mximo segmento permitido informado al principio de la conexin. Es tarea del protocolo IP decidir cundo se debe fragmentar un paquete IP. Si es necesario fragmentarlo, el mdulo IP extrae el segmento TCP dentro del paquete, lo entrega al nivel TCP del host, quien lo devuelve fragmentado al nivel de red, volvindose a encapsular cada fragmento en un paquete IP. El segmento entonces viaja fragmentado hasta el host de destino, donde el nivel de red del receptor se encarga de juntar todos los fragmentos en su buffer, reconstruir el segmento original, y entregarlo no fragmentado al host de destino. Si uno de las partes del segmento original se pierde, el nivel de red del receptor ser incapaz de reconstruirlo, y por tanto descartar, una vez expirado el tiempo de vida del paquete IP, todos los fragmentos recibidos y no pasar ninguna parte de ese segmento al nivel de transporte. Cuando esto ocurre, la confirmacin no llega al mdulo TCP trasmisor, se acaba el tiempo de vida del segmento, se detecta el segmento faltante, y se retransmite al emisor. Por tanto, cuando un fragmento de un paquete se pierde todos los fragmentos se retransmiten nuevamente; el proceso se repite hasta que todos los fragmentos consiguen llegar correctamente al receptor.

2.4 MANEJO Y CONTROL DE LA CONGESTIN. 2.4.1 Congestin en TCP


Se produce congestin en un enlace de comunicacin de datos cuando la carga existente sobrepasa la capacidad de transporte [3]. La congestin puede deberse a diferentes factores, la mayora de ellos externos tanto al protocolo TCP como a los host en comunicacin. Lo importante es que el protocolo TCP debe ser capaz de identificar y manejar la congestin. Supngase el caso que el protocolo TCP no incluyera ningn mecanismo de control en situaciones de congestin. Dado que el receptor anuncia un ventana de recepcin con espacio disponible, el emisor inyectar paquetes en la red al ritmo que se lo permita su conexin fsica. Cuando los paquetes lleguen a la parte congestionada de la red, sta no podr aceptar todo el trfico entrante. Los nodos2 intermedios empezarn a acumular paquetes IP3 en sus buffers, y cuando estos se llenen los descartarn. En el lado del protocolo TCP receptor se recibirn solo una parte de los segmentos, por lo que o bien se devolvern segmentos ACK acusando el no recibo de los segmentos, o bien sencillamente no se enviarn los ACK y se esperar que el emisor reenve los segmentos al llegar agotarse el RTO. En cualquier caso el emisor tiene que reenviar datos, ya que los segmentos descartados en ruta son intiles, y cargan innecesariamente las lneas por las que pasan. Este trfico intil sumado al reenvo de los segmentos podra propagar el problema a zonas de la red que en principio no tenan congestin, aumentando as la magnitud del problema y disminuyendo an ms el rendimiento. Este efecto se denomina colapso de congestin (congestin collapse) y puede llegar a dejar toda una red completamente fuera de servicio.

2.4.2 Ventana de recepcin informada TCP.


En una conexin TCP, el receptor anuncia regularmente el tamao de ventana que tiene disponible, de manera que el emisor sepa cuantos datos ms puede enviarle. Este valor se denomina ventana de recepcin informada TCP, y corresponde a la cantidad de datos recibidos (en bytes) que pueden ser recibidos en el buffer de recepcin de la conexin. Antes de enviar una cantidad determinada de datos, el host emisor debe esperar un segmento TCP que confirme la recepcin de los segmentos ya enviados, y actualice del tamao de ventana de recepcin informada por parte del receptor. Cuando

Para efectos de este documento, se denomina host a los equipos que estn en comunicacin directa usando el protocolo TCP, mientras que los nodos corresponden a los equipos intermedios por los que pasa la conexin. Todos los segmentos TCP son encapsulados en paquetes IP durante su transmisin.
3

un receptor tiene lleno su buffer anuncia una ventana de cero bytes, con lo que el emisor queda bloqueado hasta nueva orden. Supngase un receptor que comienza con un tamao de ventana X, recibe Y bytes, entonces su tamao de ventana ser (X-Y). El transmisor slo podr mandar un tamao mximo de datos de (X-Y) bytes. Existen dos circunstancias en las que el emisor puede enviar datos con ventana cero. Una es cuando se presentan datos urgentes; estos siempre deben ser aceptados por el receptor, ya que se supone que no pueden esperar. La otra excepcin es que el emisor puede siempre enviar un segmento de un byte de datos, consultando por el estado de la ventana, ante lo cual el receptor debe devolver un segmento ACK para actualizar el valor de la ventana.

2.4.3 Ventana de congestin del emisor TCP.


Para poder auto regularse de manera efectiva, el TCP emisor maneja una ventana de congestin, que le indica que cantidad de datos puede inyectar en la red en un momento dado. Dicha ventana acta simultneamente a la ventana de recepcin. En cada momento el emisor transmitir el valor mnimo entre la ventana de recepcin informada y la ventana de congestin, para asegurarse de que no satura al receptor y que tampoco provoca o contribuye a agravar una situacin de congestin en la red. Mientras que la ventana de recepcin informada TCP es notificada al emisor por el receptor, la ventana de congestin es calculada por el transmisor a partir de la cantidad de retransmisiones que tiene que realizar. Cuando no se produce ninguna retransmisin, el protocolo TCP en el host transmisor aumenta paulatinamente el tamaos de la ventana, hasta llegar al punto donde falla algn segmento, momento en el cual reduce su valor. Generalmente la ventana de congestin crece lenta y gradualmente, mientras que la reduccin se lleva a cabo de manera drstica4.

2.4.4 Clculo del RTO


Cuando los segmentos transmitidos se descartan debido a congestin, el receptor debe retransmitirlos al agotarse el temporizador del segmento. Para un funcionamiento eficiente de TCP es fundamental que tiempo de espera para la retransmisin sea el adecuado a cada conexin; si es demasiado alto se esperar innecesariamente por ACK que nunca llegarn, y si es demasiado bajo se producirn reenvos innecesarios de segmentos correctamente recibidos.

El tamao de la ventana de congestin vara segn el criterio AIMD (additive increase/multiplicative decrease) el cual establece un crecimiento aditivo mientras que aplica un decremento multiplicativo.

La eleccin de valores adecuados de temporizador es mucho ms compleja en la Capa de Transporte que en el nivel de enlace. Adems de las fluctuaciones naturales debidas a las diferencias en capacidad y retardo de unas conexiones a otras, la Capa de Transporte debe hacer frente a oscilaciones debidas a la presencia de elementos intermedios adems de situaciones de congestin que estn fuera de su control. An en ausencia de congestin, los host intermedios pueden tener largas colas de paquetes que atender, los enlaces pueden ser de diversas velocidades, y hasta la ruta puede variar, incluso durante una misma conexin. La nica forma de establecer valores adecuados del temporizador de retransmisin en la Capa de Transporte es utilizar algoritmos auto adaptativos, que dinmicamente ajusten los valores al estado de la red, segn ste sea percibido por la Capa de Transporte en el host emisor. Para estimar un valor razonable del RTO, el protocolo TCP mide lo que tardan en llegar los ACK de los segmentos enviados. El protocolo TCP supone que estos tiempos son una buena estimacin del tiempo de viaje de ida de los segmentos, y el tiempo de viaje del ACK correspondiente. A la suma de ambos tiempos de viaje se le denomina Tiempo de Viaje Redondo (RTT, Round Trip Time), siendo valor la base para el clculo el valor del temporizador de retransmisin [5]. El valor medio del RTT (denominado MRTT) se estima mediante la frmula iterativa 2-1, donde RTT[i] es el tiempo de ida y vuelta medido para el ltimo ACK recibido:

MRTT i MRTT i 1 1 RTT i

(2-1)

El parmetro permite ajustar el peso o la importancia que se quiere dar al ltimo valor frente a los anteriores; con un valor pequeo se consigue que los valores anteriores tengan poca relevancia, adaptndose as a situaciones cambiantes con rapidez. Con valores grandes se reacciona ms lentamente; de esta forma puede ajustarse el grado de 'inercia' de MRTT. En TCP, el valor de normalmente es 7/8. En esencia lo que calcula esta frmula es una media aritmtica ponderada de los valores de RTT, dndoles un peso relativo inversamente proporcional a su antigedad (cuanto ms viejo menos importante).

Anda mungkin juga menyukai