Aplicacions i Serveis Telemàtics. Práctica 2. Protocolos de transporte en la arquitectura TCP/IP:

Transcripción

1 Aplicacions i Serveis Telemàtics Práctica 2 Protocolos de transporte en la arquitectura TCP/IP: Transmission Control Protocol (TCP) y User Datagram Protocol (UDP) Anna Calveras, Jordi Casademont, Josep Paradells 1. TRANSMISSION CONTROL PROTOCOL: TCP COMPORTAMIENTO DEL TCP EN CONDICIONES ESPECIALES: Segmentos RESET Transferencia de información en condiciones especiales MECANISMOS DE TCP PARA OFRECER FIABILIDAD TCP Y LA VENTANA DESLIZANTE RTT Y TIMEOUTS TCP Y LA CONGESTIÓN Inicio lento o Slow Start Algoritmo de Prevención de la Congestión ó Congestion Avoidance Combinación de Slow Start y Congestion Avoidance Mejoras a los mecanismos DESARROLLO DE LA PRÁCTICA ESTUDIO PREVIO EJERCICIOS EN EL LABORATORIO Ejercicio 1: Reintentos de conexión Ejercicio 2: Estudio del backoff del TCP

2 1. Transmission Control Protocol: TCP TCP es un protocolo orientado a conexión y fiable. Específicamente, se dice que TCP proporciona un servicio de transporte de un flujo de bytes, orientado a conexión, fiable Comportamiento del TCP en condiciones especiales: Segmentos RESET En general, TCP envía un segmento RESET siempre que recibe un segmento que no parece ser correcto para la conexión que tenía establecida. Un caso bien conocido en el que se envía un segmento RESET es cuando se intenta realizar una conexión a un puerto no activo de un servidor (un puerto no activo significa que no hay ninguna aplicación que esté escuchando en ese puerto de ese servidor). En este caso, el servidor responde al segmento SYN con un segmento RST. Aunque hay ocasiones que el servidor puede programarse para que actué de otra forma. OLtro ejemplo es el mostrado a continuación. En la Figura 1 y Figura 2 puede verse el ejemplo de una transferencia de fichero entre un cliente y un servidor. En este ejemplo, el cliente aborta la conexión mediante el envío de un RST. Figura 1. Intercambio de segmentos entre cliente y servidor 2

3 Figura 2. Detalle del segmento de RESET Transferencia de información en condiciones especiales En la fase de transferencia de la información, los extremos TCP intercambian datos de usuario de forma fiable extremo a extremo. Vamos a destacar a continuación algunos aspectos relevantes en esta fase de la comunicación. El flag PSH Los segmentos TCP que transportan datos de usuario suelen llevar activado el flag de push (PSH) aunque no es estrictamente necesario. Recordemos que el flag PSH indica que los datos de ese segmento y los datos que hayan sido almacenados anteriormente deben ser pasados a la aplicación receptora lo antes posible. Se puede dar el caso que varios segmentos que transportan datos no lleven activado el flag PSH; el TCP receptor almacenará esos datos pero no los entregará a la aplicación receptora hasta que reciba un segmento con el PSH activado. Sin embargo, la mayoría de implementaciones TCP activan el flag de PSH en cada segmento que transporta datos, haciéndolos disponibles a la aplicación inmediatamente. El flag URG y el campo Urgent Pointer El flag URG y el campo Urgent Pointer se utilizan cuando se desea enviar datos que se suponen que no pertenecen al flujo normal de bytes, sino que son datos urgentes. Estos bytes urgentes se insertan en medio del flujo normal de bytes, activando el flag URG y estableciendo el campo Urgent Pointer de la cabecera de 3

4 TCP a un valor que sumado con el valor del campo de número de secuencia de la cabecera de TCP se obtiene el número de secuencia del último byte de los datos urgentes. La especificación original de TCP no deja claro si el Urgent Pointer debe apuntar al último byte de los datos urgentes o al byte que sigue al último byte urgente. Aunque documentos posteriores aclararon que el Urgent Pointer debe apuntar al último byte urgente, la mayoría de implementaciones de TCP (derivadas de la realizada en Berkeley) continúan utilizando la interpretación equivocada. En Linux es posible indicar en qué forma se desea que funcione el Urgent Pointer variando el valor de la variable /proc/sys/net/ipv4/tcp_stdurg. Si el valor de esta variable es 0 se utiliza la interpretación de Berkeley, si vale 1 se utiliza la interpretación del estándar. TCP no especifica mucho más sobre los datos urgentes, así no hay forma de saber cuándo se inician los bytes urgentes en el flujo de datos. Es la aplicación la que debe saber cómo extraer los datos urgentes Mecanismos de TCP para ofrecer fiabilidad La pregunta que nos hacemos es, cómo puede un protocolo proporcionar un servicio de transferencia fiable sobre un sistema de comunicaciones no fiable? Una de las técnicas más utilizadas es el ARQ (Automatic Repeat Request) o petición de retransmisión automática. En ARQ, el receptor informa al emisor del éxito o fracaso de la última transmisión, a través de una trama de reconocimiento. Los reconocimientos pueden ser positivos (reconocimiento de éxito) y negativos (reconocimiento de errores en la trama recibida). No todos los protocolos utilizan simultáneamente ambos tipos de reconocimiento. Por ejemplo TCP sólo utiliza reconocimientos positivos y cuando hay errores no envía nada, utilizando temporizadores para las retransmisiones. En la Figura 3 se muestra la transmisión de dos tramas con reconocimiento. Este sistema se conoce con el nombre de Stop & Wait porque después de enviar un paquete, el emisor debe parar de transmitir y esperar la recepción del reconocimiento. Obsérvese que el tiempo efectivo utilizado para transmitir una trama es desde el inicio de la transmisión de la trama hasta que se recibe el reconocimiento. En este caso la eficiencia de transmisión es baja, puesto que el hecho de que el emisor deba esperar el reconocimiento le imposibilita para seguir transmitiendo. Figura 3. Mecanismo Stop & Wait Concretamente TCP proporciona fiabilidad utilizando los siguientes mecanismos: Los datos de la aplicación son fragmentados en lo que TCP considera que es el mejor tamaño para ser transmitidos. Esta unidad de datos se denomina segmento. La unidad máxima de transferencia de TCP se denomina MSS (Maximum Segment Size). Normalmente se adecua a la MTU (Maximum Transmission Unit) de la interfaz. Por ejemplo, en Ethernet tenemos un a MTU por defecto de

5 bytes. Si IP está usando la mínima cabecera (20 bytes), entonces las MSS es de 1480 bytes, con lo que si la cabecera de TCP, como veremos más adelante, mínima es también de 20 bytes, entonces los datos a transportar por TCP en cada segmento serán de 140 bytes. Cuando TCP envía un segmento, inicia un temporizador, esperando que el otro extremo reconozca la recepción correcta del segmento enviado. Si el reconocimiento no ha sido recibido cuando el temporizador ya ha expirado, el extremo transmisor vuelve a enviar el mismo segmento. Cuando TCP recibe un segmento de datos, envía un reconocimiento al extremo que lo ha enviado. Este reconocimiento se denomina ACK (Acknowledge). Podemos decir por tanto que TCP funciona con un mecanismo de confirmación positiva. En la Figura 4 se representa este mecanismo particularizando para un segmento enviado y para un reconocimiento por cada segmento recibido. Cabe destacar también que la mayoría de implementaciones de TCP no envían un reconocimiento por cada paquete recibido, sino para cada dos. Este mecanismo lo analizaremos más adelante. Figura 4. Esquema básico del mecanismo de confirmación de TCP. TCP incluye un checksum de la cabecera y los datos cuyo propósito es detectar cualquier modificación de los datos en tránsito. Si el checksum recibido es incorrecto, el segmento TCP se descarta silenciosamente (dado que TCP utiliza un mecanismo de confirmación positiva) y no se reconoce. Se espera que el temporizador del TCP del extremo opuesto expire y se lo vuelva a enviar (retransmisión). Podemos ver este mecanismo en la Figura 5. Figura 5. Esquema básico del mecanismo de retransmisión de TCP. 5

6 Dado que los segmentos TCP viajan encapsulados en datagramas IP, y dado que los datagramas IP pueden llegar desordenados, los segmentos TCP pueden llegar desordenados. El TCP del extremo receptor reordena, si es necesario, los segmentos recibidos y entrega, a la aplicación, los datos en el orden correcto. TCP controla esta reordenación mediante los números de secuencia de los segmentos. Dado que los datagramas IP pueden llegar duplicados, TCP debe descartar los segmentos TCP duplicados. Al igual que en el punto anterior, TCP controla esta reordenación mediante los números de secuencia de los segmentos. TCP también proporciona control de flujo. Los extremos TCP tienen una cantidad finita de espacio de almacenamiento. El extremo TCP receptor indica al extremo TCP emisor cuánto espacio de almacenamiento tiene para los datos recibidos. De esta forma se previene que un dispositivo cuyo ritmo de generación de datos es alto pueda superar la capacidad de recibir y procesar datos del ordenador receptor. El sistema que utiliza TCP para proporcionar fiabilidad se engloba en los llamados protocolos de ventana deslizante para dotarle además de eficiencia TCP y la ventana deslizante Supongamos que modificamos el algoritmo de manera que el emisor pueda tener como máximo F tramas no reconocidas. El emisor podrá enviar como máximo F tramas sin recibir reconocimiento de ellas. F se denomina el tamaño de la ventana y en cuanto reciba el reconocimiento de la primera trama, podrá enviar una nueva trama, y así sucesivamente. Este es el caso representado en la Figura 6, para un tamaño de ventana F = 3. Figura 6. Esquema de envío y reconocimiento. El hecho de utilizar ventana deslizante implica que las tramas de información deben ir numeradas para que los reconocimientos indiquen mediante este número qué trama ha sido recibida correcta. Es importante destacar que en un sistema de ventana deslizante, no es necesario enviar una trama de reconocimiento por cada trama de datos. Se puede reconocer con una sola trama de reconocimiento varias tramas de datos teniendo en cuenta que si se han enviado 3 tramas de datos y se reconoce la trama 3, entonces, de forma automática, quedan reconocidas la 1 y la 2. Esta es una propiedad que utiliza TCP en sus 6

7 reconocimientos y se denomina reconocimientos acumulativos (un ACK no reconoce solamente el segmento recibido sino todos los anteriores). Es habitual que en una comunicación entre dos ordenadores, cada uno de ellos actúe simultáneamente de emisor y receptor, ya que la información suele fluir tanto en un sentido como en el otro. Cabe notar que TCP es un protocolo full dúplex. Para aumentar la eficiencia, el paquete de información incluye un campo utilizado para reconocimiento, evitándose el tener que enviar tramas de reconocimiento y de información diferentes cuando ambas tramas viajan en el mismo sentido. A esta técnica se le conoce con el nombre de piggybacking. TCP utiliza un mecanismo especializado de ventana deslizante con objeto de mejorar la eficiencia de transmisión y realizar un control de flujo. En la Figura 7 podemos ver como desliza la ventana sobre los datos a enviar. Figura 7. Ventana deslizante. Como se ha comentado anteriormente, TCP ve los datos de usuario como un flujo de bytes que divide en segmentos para ser transmitidos. Por esta razón TCP no numera los segmentos sino los octetos transmitidos y a su vez, los reconocimientos reconocen octetos recibidos y no segmentos recibidos. En TCP el tamaño de ventana indica el número de octetos que pueden ser recibidos y el receptor indica al emisor, en cada trama enviada, qué tamaño de ventana tiene disponible para recibir el siguiente segmento, realizando, de esta manera, el control de flujo. Si se indica un tamaño de ventana 0, el emisor deja de enviar segmentos hasta que recibe otro paquete indicando un tamaño de ventana distinto de RTT y Timeouts En el funcionamiento de TCP y el mecanismo de ventana deslizante visto anteriormente se indica que TCP realiza un reconocimiento positivo de los segmentos que ha recibido correctamente. Si el segmento se recibe con errores, el TCP receptor lo ignora. Al cabo de un cierto tiempo (timeout) el TCP emisor lo retransmite. El cálculo del timeout se realiza de forma dinámica para cada conexión TCP que se establece ya que las condiciones de transmisión pueden cambiar por diversas razones, como por ejemplo la congestión de la red o los diferentes caminos seguidos por los datagramas IP para diferentes conexiones remotas. 7

8 El cálculo del timeout se basa en el cálculo del RTT (Round Trip Time). El RTT, definido de forma genérica, es el tiempo que tarda un paquete en ir del emisor hasta el receptor sumado al tiempo que tarda en llegar la confirmación del receptor al emisor. TCP calcula el RTT de dos formas diferentes (aunque complementarias): 1. TCP inicia un temporizador cuando se envía un byte (aleatorio) que viaja en un segmento. Cuando TCP recibe el ACK del segmento donde viajaba el byte detiene el temporizador y obtiene el RTT. 2. Una segunda forma de calcular el RTT es a través de una opción de TCP, el timestamp. El TCP emisor incluye una marca temporal (timestamp) como opción del TCP. El TCP receptor copia la marca temporal recibida en el segmento de reconocimiento enviado. De esta forma el TCP emisor puede calcular el RTT de forma más sencilla que el caso anterior. El RTT que se utiliza para calcular el tiempo de timeout corresponde a un valor medio obtenido con los diferentes cálculos de RTT durante la misma conexión. El timeout (RTO) se calcula de forma proporcional al valor obtenido teniendo en cuenta tanto la media de las medidas de RTT (RTS: Round Trip Sample) como su desviación. En la Figura 8 puede verse una retransmisión. Figura 8. Retransmisión de paquetes perdidos al cabo de RTO. 8

9 1.5. TCP y la Congestión Cuando se definió e implementó TCP, las redes existentes presentaban como problema principal una baja fiabilidad, es decir, la presencia de errores era la característica limitante del comportamiento eficiente de la red. Las situaciones de congestión, causa principal del deterioro del comportamiento de las redes actuales, no fueron tenidas en cuenta y, por ello, no se especificó mecanismo alguno para su control. Con el tiempo, sin embargo, se han ido desarrollando una serie de algoritmos con ese propósito: Inicio lento o Slow Start Esta estrategia se basa en el siguiente principio de equilibrio en la conexión: "ʺla tasa a la cual deberían inyectarse nuevos paquetes en la red es la tasa a la que llegan nuevos reconocimientos"ʺ. Esta afirmación indica que TCP es un protocolo auto sincronizado ya que utiliza los reconocimientos como marcas para inyectar nuevos paquetes en la red. Cuando no hay segmentos en tránsito, como en el inicio de una conexión o tras una expiración del temporizador de retransmisión, no existen ACK que permitan activar tal comportamiento; para conseguir que los paquetes fluyan son necesarios ACK que lo permitan y para tener ACK es necesario un flujo de paquetes. El mecanismo de Inicio Lento permite incrementar gradualmente la cantidad de datos en tránsito. Es el impulso inicial necesario para conseguir llevar la conexión al estado de equilibrio. Este mecanismo utiliza una nueva ventana llamada ventana de congestión (cwnd) de manera que en cada momento, el emisor puede enviar el mínimo número de segmentos de entre la cantidad permitida por la ventana de control de flujo y la permitida por la ventana de congestión. Esto significa que el algoritmo de Inicio Lento dejará de tener efecto una vez que cwnd alcance el tamaño de la ventana del receptor (siempre y cuando no se haya producido antes una pérdida de paquetes que inicie de nuevo el algoritmo). El algoritmo opera de la siguiente forma: Al iniciarse una nueva conexión o al reiniciarse debido a una pérdida, inicializa cwnd a un segmento: cwnd=1 Cada vez que se recibe un ACK incrementa en una unidad cwnd: cwnd++ Si, por ejemplo, el receptor envía un reconocimiento por cada segmento recibido, el emisor enviará 1 segmento durante el primer RTT, 2 segmentos durante el segundo, 4 durante el tercero y así sucesivamente. Esto provoca un incremento exponencial de la ventana, ya que con cada reconocimiento recibido el emisor puede enviar dos paquetes: uno debido al propio ACK (la ventana se desliza un segmento hacia la derecha) y otro por la apertura de la ventana exigida por el mecanismo de Inicio Lento. Respecto a este inicio lento hay propuestas para solucionar los inconvenientes que este mecanismo tiene en el inicio de la comunicación, permitiendo una apertura más rápida de la ventana de congestión. Las técnicas propuestas tienen importancia en transferencias cortas en las que la fase de inicio es relevante en la comunicación. La Figura 9 muestra la evolución del número de secuencia (packets) y de reconocimiento (acks) módulo 90 (expresado en segmentos), de una transferencia ftp sobre un enlace de 10 Mbps, un retardo de propagación de 15 milisegundos, y un tamaño de paquete de 1500 octetos. En estas condiciones el tamaño de ventana óptimo para la transmisión es de 27 segmentos. Puede observarse que al inicio de la trasferencia, el crecimiento de la ventana es exponencial (correspondiente a la fase de inicio lento). Una vez se ha alcanzado el tamaño máximo de ventana, se mantendrá su valor máximo hasta que se produzca una retransmisión. 9

10 Figura 9. Flujo de paquetes y reconocimientos Algoritmo de Prevención de la Congestión ó Congestion Avoidance Este algoritmo persigue adaptar la transferencia a la situación de la red en cada momento, reaccionando ante posibles estados de congestión. Puesto que TCP asume que las pérdidas de paquetes son debidas a congestión, TCP interpreta una expiración del temporizador de retransmisión (timeout) como un síntoma claro de congestión. Cuando esto ocurre, se lleva a cabo un estrechamiento exponencial de la ventana que consiste en reducir su tamaño a la mitad. Por contra, cuando la red no pierde paquetes, este algoritmo propone un ensanchamiento lineal de la ventana que permita la adaptación progresiva a la nueva situación descongestionada aprovechando al máximo el ancho de banda disponible. El algoritmo opera de la siguiente manera: Cuando ocurre un timeout, asigna a cwnd la mitad del tamaño de la ventana actual: cwnd = W/2 Este es el estrechamiento exponencial ya comentado. Cada vez que llega un reconocimiento de nuevos datos, incrementa cwnd en 1/cwnd (es decir, se incrementa 1 segmento por ventana completa transmitida): cwnd= cwnd + 1/cwnd Este es el ensanchamiento lineal ya comentado. Teniendo en cuenta que el número de ACK que puede recibir el receptor durante el tiempo de ida y vuelta es, como máximo, cwnd (donde cwnd es el tamaño en segmentos de la ventana de congestión), el incremento máximo en el tamaño de la ventana durante un RTT será de un segmento. 10

11 Combinación de Slow Start y Congestion Avoidance Inicio Lento y Prevención de la Congestión son algoritmos totalmente independientes, no obstante, en la práctica, se implementan de manera conjunta. El algoritmo combinado mantiene dos variables para el control de la congestión: una ventana de congestión (cwnd) y un valor umbral (ssthresh) que permite conmutar entre los dos algoritmos. Su funcionamiento es el siguiente: Inicialmente: cwnd = 1 ssthres = Wmax (tamaño máximo de la ventana de transmisión) Cuando ocurre un timeout, la mitad del tamaño actual de la ventana (y como mínimo dos segmentos) se guarda en la variable ssthresh: ssthresh=w/2 Este es el estrechamiento exponencial típico de Prevención de la Congestión. Asigna a cwnd un único segmento: cwnd=1 Esto indica el comienzo de Inicio Lento. La llegada de un ACK que reconoce datos nuevos, incrementa el valor de cwnd según el siguiente procedimiento: o o Si cwnd ssthresh significa que estamos en Inicio Lento por lo que incrementamos cwnd en una unidad. Si cwnd > ssthresh significa que estamos en Prevención de la Congestión por lo que incrementamos cwnd en 1/cwnd. El emisor siempre envía el mínimo entre cwnd y la ventana de control de flujo o transmisión. Crecimiento de la ventana de congestión (segmentos) Retransmisión Tiempo (RTT) Figura 10. Algoritmos de Inicio Lento y Prevención de la Congestión. 11

12 La Figura 10 muestra la evolución de la ventana de congestión para los algoritmos de Inicio Lento y Prevención de la Congestión. En este ejemplo, el umbral de congestión se encuentra en 32 segmentos (línea discontinua), a partir del cual se pasa de la fase de Inicio Lento (crecimiento exponencial) a la fase de Prevención de la Congestión (crecimiento lineal). También puede apreciarse como tras una retransmisión, el umbral de congestión se reduce a la mitad de la ventana de congestión y se inicia otra vez el proceso. Los algoritmos de control de la congestión son adecuados para este tipo de situaciones, pero no lo son en el caso de redes móviles en las que el principal problema es la pérdida de paquetes debido a errores o desconexiones en la comunicación. En las redes móviles interesa que los errores se recuperen de la forma más rápida posible, y sin interactuar con la transmisión, ya que este tipo de errores son ajenos al protocolo. Es decir, el hecho de reducir el flujo de datos que el emisor puede insertar a la red no hace más que retrasar la recuperación de la transmisión y no por ello se reducirá la tasa de pérdidas Mejoras a los mecanismos A medida que las redes y los protocolos van evolucionando, se van incorporado nuevos mecanismos, que tienen el propósito de mejorar el comportamiento del protocolo. En concreto los mecanismos de retransmisión y recuperación rápida detallados a continuación, intentan optimizar y ajustar los algoritmos descritos anteriormente para adecuar el protocolo TCP a situaciones de congestión y pérdidas en general, y ayudarlo así a recuperarse más rápidamente de las mismas. Los mecanismos de congestión actúan a posteriori, es decir, una vez detectada la pérdida o presunta pérdida de un segmento. Esto representa que no se intentará solucionar el problema hasta transcurridos RTO segundos. La primera de las mejoras propuesta que está presente en la mayoría de implementaciones, aprovecha la recepción de reconocimientos duplicados (aquellos que consecutivamente reconocen al mismo segmento, es decir contienen el mismo número de secuencia). De esta forma se activa la retransmisión de un segmento presuntamente perdido antes de que expire su temporizador de retransmisión. Este algoritmo se conoce como Retransmisión Rápida ó Fast Retransmit. La recepción de un ACK duplicado puede ser debida las siguientes situaciones: La red desordena paquetes y, en consecuencia, es posible que el receptor haya enviado un reconocimiento duplicado ante la llegada de un segmento que no sigue la secuencia normal. Hay que tener en cuenta que todas las implementaciones modernas de TCP generan, inmediatamente, un ACK duplicado al recibir un segmento fuera de orden. Se ha perdido algún segmento de datos tanto por errores del canal o por problemas de congestión. En este caso el TCP recibe segmentos fuera de orden y en consecuencia genera ACK duplicados. Se ha producido un pico de retardo en la red, es decir, el tiempo de ida y vuelta de un paquete se ha incrementado repentinamente provocando la expiración del temporizador de retransmisión del emisor con la consiguiente retransmisión del segmento conflictivo. Puesto que el segmento en cuestión ya había sido recibido correctamente, la recepción de su réplica provoca la generación de un ACK duplicado. Esta situación se producirá básicamente en casos de congestión. El emisor, sin embargo, no sabe a cuál de estas razones responde la recepción del ACK duplicado. Experimentalmente se ha comprobado que no resulta apropiado precipitar la retransmisión ante la recepción del primer ni el segundo reconocimiento duplicado en redes que desordenan paquetes, ya que puede tratarse de un simple problema de reordenación de rápida solución. Por esta razón, la mayoría de implementaciones de TCP activan el mecanismo de Retransmisión Rápida al recibir el tercer ACK duplicado. Cuando éste llega, 12

13 el emisor no espera a la expiración del temporizador sino que retransmite, inmediatamente, el segmento que demanda el reconocimiento e inicia el algoritmo de Inicio Lento. Este mecanismo, pensado para situaciones de congestión, es también muy adecuado para las situaciones en las que la pérdida es debida a errores en la comunicación, ya que en el mejor de los casos se retransmitirá el paquete perdido antes que en implementaciones sin este mecanismo. Además de la retransmisión de los datos perdidos, los algoritmos contra la congestión reducen la ventana de transmisión, para dar tiempo a la red que se recupere de ésta. El algoritmo combinado de Inicio Lento y Prevención de la Congestión da una solución muy drástica a los problemas de congestión, pudiendo degradar de forma innecesaria el comportamiento de TCP frente a estas situaciones. El hecho de cerrar la ventana de congestión a un único segmento después de la pérdida de datos y empezar un inicio lento no parece adecuado ni en los casos de congestión ni en los casos de errores. Analizando con más detalle el mecanismo propuesto anteriormente, puede ampliarse basándonos en el hecho que un ACK duplicado no sólo indica que ha habido un problema en la red, sino que también confirma que un paquete ha abandonado la red y ha sido recibido correctamente por el TCP en el otro extremo. Esto es así puesto que el receptor sólo puede generar un ACK como respuesta a la llegada de un paquete. No hay necesidad, por tanto, de poner en marcha Inicio Lento y reducir así drásticamente el número de paquetes inyectados en la red. Este algoritmo se conoce como Retransmisión Rápida con Recuperación Rápida ó Fast Retransmit with Fast Recovery, y opera como sigue: Cuando llega el tercer ACK duplicado se retransmite el segmento perdido y: ssthresh= cwnd/2 cwnd=ssthresh + 3 Con cada nuevo ACK duplicado recibido, se incrementa cwnd en una unidad y se transmite un nuevo paquete si lo permite el valor de cwnd. Cuando se recibe el primer ACK que reconoce nuevos datos, se asigna a cwnd el valor de ssthresh (es decir la mitad del valor que tenía la ventana de congestión cuando se produjo la congestión). 13

14 2. Desarrollo de la práctica Esta práctica es la continuación de la anterior por lo que se utilizará el mismo entorno virtual y las mismas herramientas. Figura 11. Entorno virtual del laboratorio Estudio Previo 1. Busque información del mecanismo de repetición selectiva de TCP (SACK TCP) y responda a las siguientes preguntas: Describa el mecanismo. Qué ventajas e inconvenientes plantea frente al mecanismo de ventana deslizante Go- Back- N? Cuándo se negocia el uso de SACK? Qué estructura tiene esta opción? 2. Busque información del mecanismo de TimeStamp de TCP y responda a las siguientes preguntas: Describa el mecanismo. Qué ventajas e inconvenientes plantea al mecanismo de estimación de RTT y consecuentemente al valor del RTO de TCP? Cuándo se negocia el uso de TimeStamp? Qué estructura tiene esta opción? En los ejercicios posteriores se analizará el tráfico TCP capturado en el ejercicio 1 de la práctica anterior. Para ello recuperaremos el fichero trazas- 1.cap. El propio analizador nos proporciona buenas herramientas para el análisis de tráfico de TCP. En este ejercicio también aprenderemos a utilizar estas herramientas. 14

15 3. Abra el fichero trazas- 1.cap con el analizador de protocolos. En caso de que no tenga el Wireshark en su ordenador personal instáleselo. 4. Seleccione el primer paquete TCP capturado y visualice el Graph Analysis en el menú Statitstics > Flow Graph > TCP flow. Esta representación gráfica permite observar de forma resumida el flujo TCP entre el cliente y el servidor. Además, al seleccionar un mensaje en el gráfico, se accede directamente al detalle del segmento TCP. 5. Identifique las tres fases en el intercambio entre el cliente y el servidor. 6. Determine el % del tiempo que representa el establecimiento y el cierre de la conexión en esta transferencia. TCP three way handshake: 7. Identifique el primer segmento TCP de la conexión en el intercambio a tres bandas, que establece la conexión entre el cliente y el servidor y conteste a las siguientes preguntas: a) Determine la longitud del segmento TCP b) Determine el valor del número de segmento inicial en valor absoluto en el sentido de cliente a servidor. Para ello puede ir al menú Edit>preferences>Protocols>TCP> y desmarcar el campo Relative Sequence Number and window scaling o pasar el valor hexadecimal del campo a un valor binario. c) Qué relación encuentra entre el Sequence Number y el ACK Number? d) Determine el valor inicial de la ventana de transmisión e) Determine los flags activos, explicar su significado. f) Determine qué opciones se negocian y cuáles son los valores propuestos. 8. Identifique el segundo segmento TCP de la conexión en el intercambio a tres bandas, que establece la conexión entre el cliente y el servidor y conteste a las siguientes preguntas: a) Determine el tiempo transcurrido entre la captura del primer y el segundo segmento. Para ello puede posicionarse en el primer segmento capturado y con el botón de la derecha del ratón seleccionar la opción Set Time Reference (toggle). Observe que se corresponde aproximadamente con el retardo impuesto de 1.2 segundos entre el cliente y el servidor. b) Determine el valor de la ventana de transmisión. Es igual o diferente del anterior? Qué sentido tiene cada uno? Pueden mantenerse valores diferentes? 15

16 c) Determine los flags activos y explique su significado. d) Determine los siguientes valores: Sequence Number, ACK Number. Qué relación tienen con los obtenidos anteriormente? e) Analice si hay alguna opción diferente a los paquetes anteriores. 9. Identifique el último segmento del tree way handshhake y conteste a las siguientes preguntas:. a) Determine los siguientes valores: Sequence Number, ACK Number. Explique su significado y la relación que guardan con los anteriores b) Determine la longitud del segmento TCP. es diferente a los anteriores? Por qué? Fase de transferencia: 10. Observe el intercambio de segmentos en esta fase y determine: a) La longitud de los segmentos que transportan datos. b) Determine la longitud de los segmentos de reconocimiento. c) Determine qué flags están activos y explique su significado. d) Existe algún segmento con opciones en esta fase? Para qué se utiliza? Fase de cierre: 11. Observe el intercambio de segmentos en esta fase y determine: a) Identifique el primer segmento con el flag de FIN activado. Puede usar un filtro de visualización (tcp.flags.fin==1) Quién envía este segmento? Por qué? b) Identifique el segundo segmento con el flag de FIN activado. Quién envía este segmento? Por qué? c) Por qué debemos cerrar la conexión en ambos sentidos? 2.2. Ejercicios en el laboratorio Para lanzar el entorno virtual siga las indicaciones del profesor que seguramente son los siguientes si no ha cambiado alguna configuración del laboratorio: Entre en la máquina softx con usuario y password master1. Inicie el Vbox. Para ello ir al menú Aplicacions>Eines de sistema>oracle VirtualBox 16

17 Ahora ya puede iniciar los nodos necesarios, que en esta práctica son únicamente client1 y serv3. La máquina servidora no tiene entorno gráfico a diferencia del cliente que sí lo tiene. En la máquina serv3 si queremos tener más de un terminal abierto podemos conmutar de uno a otro con la teclas Alt F1, Alt F2 y así sucesivamente. En el caso de que el VirtualBox no pueda ejecutar alguna máquina virtual deberá copiar el contenido del PenDrive subministrado por el profesor excepto el fichero VirtualBox.xml en el directorio /var/tmp/. Seguidamente copiar el fichero VirtualBox.xml en ~/.VirtualBox/. Si el directorio no existe créelo. Finalmente cambie los permisos de los ficheros que ha copiado: chmod -R 777 directorio chmod 666 fichero Ejercicio 1: Reintentos de conexión En este ejercicio vamos a estudiar el número máximo de reintentos de conexión (y el intervalo entre ellos) que un cliente TCP puede realizar a un servidor que no responde o que no ha recibido la petición de conexión. 12. Elimine el retardo introducido entre cliente y servidor ejecutando en la máquina serv3: sudo tc qdisc del dev eth0 root netem delay 1200ms y añada otro de 50s. 13. Capture el tráfico cuando el cliente accede al servicio web de la máquina servidora en el puerto Para ello escriba en el navegador web :8080 a) Se ha podido establecer la comunicación? Por qué? Visualizar el Graph Analysis. b) Ahora añada un retardo de 20s en el servidor y reintente la conexión. Cuál es el número máximo de reintentos que puede hacerse antes de desestimar la conexión? c) Cuál es el intervalo entre reintentos? d) Compurebe si coincide con el valor configurado. Concretamente consulte el valor de las variables: tcp_syn_retries: Number of times initial SYNs for a TCP connection attempt will be retransmitted. This value should not be more than 255. This is only the timeout for outgoing connections. e) El problema reside en que el ordenador cree que el servidor ya no se encuentra conectado a la red y no llega a utilizar el número máximo de reintentos. Intente conectarse desde la máquina real (no la virtual) a otro ordenador externo que sepa que está apagado (con mucha probabilidad el estará apagado) y capture los paquetes en el interfaz eth0 (consejo: añada un filtro a la dirección IP escogida). Qué ocurre ahora? 17

18 Ejercicio 2: Estudio del backoff del TCP En este ejercicio se propone ver el efecto del backoff exponencial en una transmisión TCP. Realizaremos una transferencia de ficheros entre el cliente y el servidor. Una vez estemos en la fase de transferencia se deberá emular una desconexión en la transferencia. Consulte si tiene alguna regla del comando tc instalada en el interfaz de red y bórrela. Para realizar la consulta: sudo tc qdisc show Ahora añada pérdidas en el mismo: sudo tc qdisc add dev eth0 root netem loss 100% Con esta instrucción perdemos todo el tráfico que llega al serv3. Para volver a recibir correctamente el tráfico, ejecutaremos en el servidor: sudo tc qdisc del dev eth0 root netem loss 100% 14. Ejecute ambas instrucciones en el servidor para que después podamos pasar de una instrucción a otra con las teclas de forma rápida. 15. En la máquina cliente añadiremos un retardo de 500 milisegundos. Ejecute la siguiente instrucción en la máquina cliente: sudo tc qdisc add dev eth0 root netem delay 500ms 16. Genere un fichero de gran tamaño (5 Mbytes) en la máquina cliente: dd if=/dev/zero of=fichero5 bs=1024 count= Active la captura de tráfico del interfaz vboxnet0 y realice la transferencia entre ambas máquinas. Esta transferencia tardará aproximadamente 60 segundos en realizarse. Antes de que finalice deberá ejecutar en el servidor la instrucción para que se pierda la conexión entre el cliente y el servidor (paso descrito anteriormente). Desde client1 ejecute: put fichero5 18. Durante la transferencia, emule la pérdida de conexión durante aproximadamente 3 minutos. Recupere la conexión entre el cliente y el servidor (paso descrito anteriormente). 19. En ese instante visualice el analizador y mida aproximadamente cuanto tiempo transcurre entre que se recupera la conexión y se envía desde la máquina cliente un segmento. Espere a que termine la trasferencia del fichero (visualizando la consola de ftp). Guarde las trazas capturadas en el fichero trazas- 5.cap. 20. Utilice la herramienta de Time Sequence graph para visualizar la transferencia. Para ello seleccione un segmento TCP de la comunicación en el que se transporten datos y acceda al menú 18

19 Statistics>TCP Stream Graph>Time Sequence Graph Stevens (para realizar un zoom+ utilice la rueda del ratón, para un zoom- SHIFT + rueda del ratón). 21. Comente el gráfico obtenido respondiendo a las siguientes preguntas: a) Determine el valor del RTO en la primera retransmisión. b) Podemos observar en las trazas de la máquina client1 el algoritmo de backoff exponencial de TCP. Qué valores del RTO puede obtener de las trazas? Qué relación existe entre valores consecutivos? c) Puede determinar el valor máximo del RTO? d) Analizando el tiempo que transcurre entre que se dispone de conexión y se reanuda la transmisión. Discuta qué ventajas y desventajas se tienen con este mecanismo. Analice los casos de problemas con congestión y errores o desconexiones de los enlaces. 19